RFC2045第五张第一节 Content-type的表示

用RFC822里的扩展BNF范式，Content-type的定义如下：

content := "Content-Type" ":" type "/" subtype
                *(";" parameter)
                ;type和subtype要配对
                ; 字母大小写不敏感

     type := discrete-type / composite-type

     discrete-type := "text" / "image" / "audio" / "video" /
                      "application" / extension-token

     composite-type := "message" / "multipart" / extension-token

     extension-token := ietf-token / x-token

     ietf-token := <An extension token defined by a standards-track RFC and registered
                    with IANA.>
      即将成为标准的RFC文档定义的和在IANA注册过的扩展标记

     x-token := <The two characters "X-" or "x-" followed, with
                 no intervening white space, by any token>
      “X”和“x”后面紧跟除了空格以外的所有标记

     subtype := extension-token / iana-token

     iana-token := <A publicly-defined extension token. Tokens
                    of this form must be registered with IANA
                    as specified in RFC 2048.>
     一个公开定义的扩展标记，这种标记必须已经在IANA注册了，在RFC2048里有专门的描述。

     parameter := attribute "=" value

     attribute := token
                ;type和subtype要配对
                ; 字母大小写不敏感

     value := token / quoted-string

     token := 1*<any (US-ASCII) CHAR except SPACE, CTLs,
                 or tspecials>

     tspecials :=  "(" / ")" / "<" / ">" / "@" /
                   "," / ";" / ":" / "/" / <">
                   "/" / "[" / "]" / "?" / "="
                ;type和subtype要配对
                ; 字母大小写不敏感

subtype在Content-type是必须的，并且没有默认值。
在content-type里type，subtype，参数名称是大小写不敏感的，但是参数值是大小写敏感的，
定义一种新的subtype的过程并不是要程做一个限制非常严格的机制，而是一个简单的事情，只需要公布他的定义和用途。

因此还有两种方法定义新的subtype

1，在两个代理之间，可以定义一些私有的值(以X-开头)，只是这些值不能标准化或者注册。
2，想IANA申请新的类型。