- From: Roy T. Fielding <fielding@avron.ICS.UCI.EDU>
- Date: Fri, 09 Dec 1994 18:03:40 -0800
- To: Marc VanHeyningen <mvanheyn@cs.indiana.edu>
- Cc: http-wg%cuckoo.hpl.hp.com@hplb.hpl.hp.com
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