[apps-discuss] Comments on draft-ietf-appsawg-xml-mediatypes-06

[S Moonesamy <[e-mail]>]

Hi Henry,

I have a few comments on draft-ietf-appsawg-xml-mediatypes-06.

In Section 3.1:

   "XML-unaware MIME producers MUST NOT supply a charset parameter with
    an XML MIME entity unless the entity's character encoding is reliably
    known."

The title of that section is "XML MIME producers".  The above states 
a (RFC 2119) requirement for a "XML-unaware MIME producer".  Can an 
agent which is not capable of processing XML MIME entities and 
detecting the XML encoding declaration follow the requirement, and 
does the requirement even apply given that the requirements being 
specified are for XML MIME producers?

As a nit, the unless clause in the requirement (sentence) seems 
odd.  It may be simpler to set requirements for "XML-aware" MIME 
producers only.

   "XML MIME producers are RECOMMENDED to provide means for XML MIME
    entity authors to determine what value, if any, is given to charset
    parameters for their entities, for example by enabling user-level
    configuration of filename-to-Content-Type-header mappings on a file-
    by-file or suffix basis."

The "entity authors" in the above is not clear.  Is it a person or an agent?

   "The use of UTF-32 is NOT RECOMMENDED for XML MIME entities."

I suggest having a short explanation about why the use of UTF-32 is 
not recommended instead of only saying that it is not recommended.

   "XML-aware consumers MUST follow the requirements in section 4.3.3
    of [XML] that directly address this case."

This is a requirement by reference to an external specification.  I 
am listing this as it is unusual.

   "XML-unaware MIME consumers SHOULD NOT assume a default encoding in
   this case."

Would a XML-unaware MIME consumer be following this specification?

In Section 4.2:

   'Interoperability considerations:  XML has proven to be interoperable
       across both generic and task-specific applications and for import
       and export from multiple XML authoring and editing tools.
       Validating processors provide maximum interoperability.  Although
       non-validating processors may be more efficient, they are not
       required to handle all features of XML.  For further information,
       see sub-section 2.9 "Standalone Document Declaration" and section
       5 "Conformance" of [XML].'

The paragraph is about interoperability considerations.  The text 
comes out as saying that "XML is great". :-)  Are there any 
interoperability issues to consider?  That's what the reader might 
wish to know.

In Section 8.1:

   "Media subtypes that do not represent XML MIME entities
    MUST NOT be allowed to register with a '+xml' suffix."

It would be easier to say that the "+xml" suffix can only be 
registered for media subtypes that represent XML MIME entities.

Section 8.1 is about IANA registrations.  I would read it as guidance 
for IANA and people requesting a registration.  I suggest phrasing 
the relevant text from that perspective and moving that text into the 
IANA Considerations section.

In Section 8.3:

   'Registrations for new XML-based media types which do _not_ use the
    '+xml' suffix SHOULD, in specifying the charset parameter and
    encoding considerations, define them as: "Same as [charset parameter
    / encoding considerations] of application/xml as specified in RFC
    XXXX."'

Why is this a RFC 2119 "should"?

   "These registrations SHOULD also make reference to RFC XXXX in
    specifying magic numbers, base URIs, and use of the BOM."

I suggest rephrasing this as guidance and not as a RFC 2119 
recommendation.  Please note that I do not have a strong opinion 
about this as it may be a matter of style.


   "These registrations MAY reference the application/xml registration in
    RFC XXXX in specifying interoperability and fragment identifier
    considerations, if these considerations are not overridden by issues
    specific to that media type."

Why is this a RFC 2119 "may"?

I suggest moving the examples in Section 9 to an appendix.

Regards,
S. Moonesamy