- From: Maciej Stachowiak <mjs@apple.com>
- Date: Thu, 22 Apr 2010 11:37:59 -0700
- To: ht@inf.ed.ac.uk (Henry S. Thompson)
- Cc: public-html@w3.org, Paul Cotton <Paul.Cotton@microsoft.com>, "noah_mendelsohn@us.ibm.com" <noah_mendelsohn@us.ibm.com>, "www-tag@w3.org" <www-tag@w3.org>
On Apr 22, 2010, at 11:25 AM, Henry S. Thompson wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Maciej Stachowiak writes: > >> <commenting with HTML WG chair hat off> > > Likewise speaking only for myself > >> I understand the desire to satisfy the MIME registration >> compatibility >> requirements. However, it looks to me like this proposed text makes >> HTML 2.0, HTML 3.2, and HTML 4.0 conforming for the text/html MIME >> type, whereas RFC2854 only allowed HTM 4.01. Are these additions >> intentional? I don't understand the purpose of expanding conformance >> relative to the previous registration to include these long-obsolete >> specifications. > > We have to be very careful with language here. IETF policy for > reregistration of media types in general, and RFC2854 in particular, > is that they have _nothing_ to say about conformance to the language > specs that they reference -- that is left to those specifications. > Furthermore, although it's fine for successive language specs > referenced by successive RFCs (re)registering a particular media type > to add/subtract/change language features, that does _not_ affect the > core commitment that documents from the earlier language versions, as > referenced in preceding media type (re)registrations, are OK to > _serve_ with the specified media type. That's _all_ that's at issue > in the media type registration. So RFC2854 says "Now you can serve > HTML 4 as text/html" as well as saying "and all that stuff you used to > be able to serve as text/html -- still OK to serve as text/html". I agree that is what IETF MIME registration policy requires, but that doesn't seem to be what RFC2854 says on the face of it. It obsoletes the previous RFCs and only mentiones HTML4.01 and XHTML1 as applicable specifications. If that is considered an error in RFC2854, then I have no problem with fixing it, so long as everyone is clear what is happening. Regards, Maciej
Received on Thursday, 22 April 2010 18:38:33 UTC