Re: [apps-discuss] I-D Action: draft-ietf-appsawg-xml-mediatypes-01.txt

[Bjoern Hoehrmann <[e-mail]>]

* Henry S. Thompson wrote:
>This draft has been out for a month, with only one minor comment
>appearing.  I'd like to do one more draft and try to close this out,
>so please, it would be great to get any further comments this week, so
>I can have a final draft in place for discussion in Berlin, if anyone
>wants to do that (I can't make it :-(.

I was waiting for a version that addresses Martin J. Dürst's comments.
There still seems to be a lot of cruft that needs to be removed or con-
densed, large parts of section 9 for instance. As an example, 9.19 is
on "model/x3d+xml" which does not exist even though

  http://www.web3d.org/x3d/publiclists/x3dpublic_list_archives/0609/msg00035.html

is seven years old now, and there is no point in enumerating types for
MathML, XSLT, RDF, SVG, SOAP and others as more than list items. There
are a number of problems with the references, for [SVG] for instance we
have formatting errors and the URL given leads an arbitrary SVG-related
technical report that might be SVG 1.1 Second Edition, but it might also
be an abandoned SVG 3 draft. [RFC3987] has "DUeerst". [ASCII] also has
formatting errors.

The document says it would update RFC 4288, but that has been obsoleted
by RFC 6838.

The type registration templates do not follow RFC 6838, for instance,
Author and Change Controller have been split into separate fields even
under RFC 4288 but for application/xml it is one field. That field does
not need to list all the e-mail addresses of people listed as editors
in the XML 1.0 specification. "MIME media type name" should be "Type
name", "MIME subtype name" should be "Subtype name" and so on.

The application/xml registration template does not mention XML 1.1 at
all, so it is unclear whether the type can be used for 1.1 documents.

I suspect many of the references listed as normative are not in fact
normative.

   *HST: What do we do about the registration of +xml in RFC6839?  I
   think we need to reproduce it with appropriate changes, as it
   currently references 3023, and can be simplified/clarified by
   including it here.  . .*

Including that in the document and updating RFC6839 accordingly does
seem to be a good way forward.
-- 
Björn Höhrmann · mailto:[e-mail] · http://bjoern.hoehrmann.de
Am Badedeich 7 · Telefon: [phone] · http://www.bjoernsworld.de
25899 Dagebüll · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/