- From: Henry S. Thompson <ht@inf.ed.ac.uk>
- Date: Fri, 20 Apr 2012 10:09:21 +0100
- To: Tony Hansen <tony@maillennium.att.com>
- Cc: apps-discuss@ietf.org, "www-tag@w3.org List" <www-tag@w3.org>
Tony Hansen writes: > So, I'm revising my draft where I'm actually *registering* a bunch of > these structured suffixes. (draft-hansen-media-type-suffix-reg) > > What I'm thinking is that the fragment considerations section for each > should simply point at the base application/whatever > specification. That is, if application/SUFFIX has specific fragment > identifiers associated with it, then anything with +SUFFIX (e.g., > application/TYPE+SUFFIX) should accept the application/SUFFIX fragment > identifiers as well as anything specific to the given media type. > > So I've added these Fragment identifier considerations sections to the > suffixes that have an underlying media type registration. > > Media types using "+json" MUST accept any fragment identifiers > defined for "application/json". Specific media types may > identify additional fragment identifier considerations. > > I have similar text for +fastinfoset, +wbxml and +zip. > > In addition, I'm thinking draft-hansen-media-type-suffix-reg should > have an IANA considerations note to add the Fragment identifier > considerations section for +xml, with text similar to the above. If you go in that direction, please consider the fact that 3023bis _is_ once again under active development, with W3C TAG cooperation, and that something very similar to the following (slightly adapted from the previous editors' draft) will likely appear therein: When a new media type is introduced for an XML-based format, the name of the media type SHOULD end with '+xml'. This convention will allow applications that can process XML generically to detect that the MIME entity is supposed to be an XML document, verify this assumption by invoking some XML processor, and then process the XML document accordingly. Applications may match for types that represent XML MIME entities by comparing the subtype to the pattern '*/*+xml'. XML generic processing is not always appropriate for XML-based media types. For example, authors of some such media types may wish that the types remain entirely opaque except to applications that are specifically designed to deal with that media type. By NOT following the naming convention '+xml', such media types can avoid XML-generic processing. Since generic processing will be useful in many cases, however -- including in some situations that are difficult to predict ahead of time -- those registering media types SHOULD use the '+xml' convention unless they have a particularly compelling reason not to. [1] Note that these paragraphs address _more_ than just fragment identifiers. The level of "generic processing", i.e. processing appropriate to any member of a stuctured-syntax family identified by a +SUFFIX, is I think the appropriate one at which to address the mutual dependency between app/foo and app/bar+foo. ht [1] http://www.w3.org/2006/02/son-of-3023/draft-murata-kohn-lilley-xml-04.html -- Henry S. Thompson, School of Informatics, University of Edinburgh 10 Crichton Street, Edinburgh EH8 9AB, SCOTLAND -- (44) 131 650-4440 Fax: (44) 131 650-4587, e-mail: ht@inf.ed.ac.uk URL: http://www.ltg.ed.ac.uk/~ht/ [mail from me _always_ has a .sig like this -- mail without it is forged spam]
Received on Friday, 20 April 2012 09:10:14 UTC