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

[SM <[e-mail]>]

Hi Henry,

I have a few comments about draft-ietf-appsawg-xml-mediatypes-00.

In the Abstract:

    "XML MIME entities are currently exchanged via the HyperText Transfer
    Protocol on the World Wide Web, are an integral part of the WebDAV
    protocol for remote web authoring ..."

XML is not expanded on first use, WWW is in the expanded form, URI is 
not expanded.  I suggest looking up abbreviation guidelines to see 
what needs to be expanded and what can be used in abbreviated form.

In Section 1:

   "Similarly, XML has been used as a foundation for other media types,
    including types in every branch of the IETF media types tree.  To
    facilitate the processing of such types, media types based on XML,
    but that are not identified using application/xml (or text/xml),
    SHOULD be named using a suffix of '+xml' as described in Section 8."

The RFC 2119 SHOULD is defined after that.  I suggest removing the 
"SHOULD" and leaving it to Section to specify how such media types are named.

In Section 3:

I suggest rewriting the second paragraph in that section to separate 
the notes from what is being specified.  It took me some time to 
understand that part of the draft.

In Section 3.1:

   "If users would like to rely on the encoding declaration or BOM and
    to hide charset information from protocols, they SHOULD determine
    not to use the parameter."

I don't understand the above.  What is being recommended?

Please update the reference for 8BITMIME to RFC 6152.

What is the summary in Section 3.6 for?

In Section 5:

   "When the syntax of a fragment identifier part of any URI or IRI
    with a retrieved media type governed by this specification conforms
    to the syntax specified in [XPointerFramework], conformant
    applications MUST attempt to interpret such fragment identifiers
    as designating that part of the retrieved representation specified by
    [XPointerFramework] and whatever other specifications define any
    XPointer schemes used."

I read the "MUST attempt" as "give it a try".  I suggest rewriting 
the sentence to make the RFC 2119 requirement clear.

   "A  registry of XPointer schemes [XPtrReg] is maintained at the W3C.
    Unregistered schemes SHOULD NOT be used."

It would be easier to recommend that the schemes which are used are 
to be registered.

In Section 9.12:

   'If sent using a 7-bit transport (e.g., SMTP) or an 8-bit clean
    transport (e.g., 8BITMIME ESMTP or NNTP), the XML MIME entity
    MUST be encoded in quoted-printable or base64.'

This RFC 2119 requirement is also in Section 3.1 and Section 9.4.

There are a lot of normative references in this draft.  Why is, 
[PNG], for example normative?  I suggest going through the references 
to see what is needed and what could be moved to Informative (if the 
reference is still relevant).

I found it difficult to identify the (RFC 2119) recommendations and 
requirements as they appear in several parts of the draft (re: 
comment about Section 9.12).  I suggest making the text crisp.  This 
could be done by reformatting some parts of the draft (e.g. see 
comment about second paragraph of Section 3.1).  By the way, an 
"Obsoletes" for RFC 3023 should be added.  There is a school of 
thought about not making any normative statements in examples.  It 
could be said that examples are to be used sparingly as it distracts 
the reader from what is being specified.

 From the Abstract I read that the purpose of the draft is:

   - standardizes three media types
   - standardizes a convention
   - alignment of charset handling

I suggest having that as the focus for the draft.  I understand that 
it is difficult to make changes for a -bis.  I would consider that 
for this draft for document clarity [1].

Regards,
-sm

1. https://www.youtube.com/watch?v=JEpsKnWZrJ8