Marc VanHeyningen writes: > Kindly show me where the MIME RFC requires conforming implementations to > check the registry; I can't seem to find it in my copy. RFC 1521, Section 4: content := "Content-Type" ":" type "/" subtype *(";" parameter) ; case-insensitive matching of type and subtype type := "application" / "audio" / "image" / "message" / "multipart" / "text" / "video" / extension-token ; All values case-insensitive extension-token := x-token / iana-token iana-token := <a publicly-defined extension token, registered with IANA, as specified in appendix E> x-token := <The two characters "X-" or "x-" followed, with no intervening white space, by any token> A BNF defines how a conforming application should *parse* the input. RFC 1521 specifies that the parser should declare a syntax error if the MIME type is not registered with IANA. RFC 1590 only changed the registration procedure -- it did not change the MIME requirements. Naturally, no mail application I know of is stupid enough to implement this requirement -- they generally just check the ~/.mailcap for any token/token types. HTTP doesn't care what the actual content-type is of the object-body. All it cares about is that the Content-Type header can be parsed, and thus it gives the only valid parsing rule possible for HTTP. > The HTTP spec should, at bare minimum, mention these issues and encourage > registration of types that are employed. It already mentions these issues and includes explicit reference to how media types are registered. I will attempt to elaborate on the finer details, but the decision HAS been made that HTTP is not a MIME-conformant application. ......Roy Fielding ICS Grad Student, University of California, Irvine USA <fielding@ics.uci.edu> <URL:http://www.ics.uci.edu/dir/grad/Software/fielding>Received on Friday, 9 December 1994 18:19:47 UTC
This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:16:10 UTC