XML Media Types
RFC 7303

Note: This ballot was opened for revision 09 and is now closed.

(Barry Leiba) Yes

(Jari Arkko) No Objection

(Alia Atlas) No Objection

(Richard Barnes) No Objection

(Benoit Claise) No Objection

Comment (2014-03-24 for -09)
I second Scott Bradner's feedback (part of in his OPS DIR review):
I think the document could benefit from pulling the various notes about incompatibilities, changes and operational issues (such as the last paragraph of appendix C) that are currently in the document into a single operational considerations section or appendix.

Regards, Benoit

Spencer Dawkins No Objection

(Adrian Farrel) No Objection

(Stephen Farrell) (was Discuss) No Objection

Comment (2014-03-25 for -09)
- 4.2: What is a "registrar" for an IANA registry?
If that is IANA, then should they really be
"encouraging" someone to do things, or shouldn't
they just be checking with experts or whatever?

- 4.3: Shouldn't you tell the RFC editor what XXXX
means?

(Brian Haberman) No Objection

(Joel Jaeggli) No Objection

(Ted Lemon) No Objection

Comment (2014-03-24 for -09)
In section 2.2, a suggestion:
OLD:
    UTF-16 XML documents, however, can be	
    serialised into MIME entities in one of two ways: either big- endian,	
    labelled (optionally) "utf-16" or "utf-16be", or little- endian,	
    labelled (optionally) "utf-16" or "utf-16le".
NEW:
    UTF-16 XML documents, however, can be	
    serialised into MIME entities in one of two ways: either big-endian,	
    labelled (optionally) "utf-16" or "utf-16be", or little- endian,	
    labelled (optionally) "utf-16" or "utf-16le".   When endianness
    is not specified in the label, it is specified in the BOM
    (see section 3.3).

The reason I suggest this is that my first reaction to this paragraph was to say "wait, there's an interoperability error here," but of course that's dealt with later in the document.   So maybe a change of this sort (I presume the exact change I suggested is incorrect) isn't needed.   I leave it to the authors to decide.

In 3.1:
   XML-aware MIME producers SHOULD supply a charset parameter and/or an
   appropriate BOM with non-UTF-8-encoded XML MIME entities which lack
   an encoding declaration, and SHOULD remove or correct an encoding
   declaration which is known to be incorrect (for example, as a result
   of transcoding).

Could you split and maybe clarify the last sentence?   E.g.:
   XML-aware MIME producers SHOULD supply a charset parameter and/or an
   appropriate BOM with non-UTF-8-encoded XML MIME entities which lack
   an encoding declaration.  Such producers SHOULD remove or correct an
   encoding declaration which is known to be incorrect (for example,
   when the encoding changes as a result of transcoding).

In 3.3:
   In addition to the MIME charset "utf-16", [RFC2781] introduces "utf-
   16le" (little endian) and "utf-16be" (big endian).  The BOM is
   prohibited in MIME entities with these labels.  When an XML MIME
   entity is encoded in "utf-16le" or "utf-16be", it MUST NOT begin with
   the BOM but SHOULD contain an in-band XML encoding declaration.
   Conversion from UTF-8 or UTF-16 (unlabelled, or labelled with
   "utf-16") to "utf-16be" or "utf-16le" MUST strip a BOM if present,
   and conversion in the other direction MUST (for UTF-16) or MAY (for
   UTF-8) add the appropriate BOM.

The second sentence substantially reduces the clarity of the paragraph, and I think it's unnecessary, since the third sentence says the same thing much more clearly.   It would also be nice if the last sentence could be split into two, one for utf-8 and one for utf-16.   Putting instructions in parentheses to distinguish between MUST and MAY seems like a desperate practice.

In 4.2:
       NOTE: Section 5.3.2 of HTTPbis [HTTPbis] does not support any form	
       of Accept header which will match only '+xml' types.  In	
       particular, Accept headers of the form "Accept: */*+xml" are not	
       allowed, and so this header MUST NOT be used for this purpose.
It's weird to put normative language in a site note.   Would it make sense to say:
       NOTE: Section 5.3.2 of HTTPbis [HTTPbis] does not support any form	
       of Accept header which will match only '+xml' types.  In	
       particular, Accept headers of the form "Accept: */*+xml" are not	
       allowed, and so this header will not work for this purpose.

Presumably this is specified in [HTTPbis] and therefore no normative statement about this restriction need be made here.   If that's not so, then this should probably not be written as a note.

There are multiple references to RFC XXXX in this document, but nothing that says what to do with these.   I presume that this is supposed to refer to the RFC number that this document is assigned, when it is assigned.   If so, should there be an RFC Editor note somewhere explaining that this substitution should done?

(Kathleen Moriarty) No Objection

(Pete Resnick) No Objection

Comment (2014-03-26 for -09)
Complete editorial nit: In the Abstract and the intro:

   This specification standardizes...
   This specification also standardizes...
   ...this specification standardizes...

Can I suggest changing those to "this document specifies"? At least in the past, the RFC Editor has often had heartburn about statements in documents that amount "this is the standard".

2.2: "The use of UTF-32 is NOT RECOMMENDED for XML MIME entities." Unfortunately, 2119 never defines "NOT RECOMMENDED", though it is obvious. You could simply switch the sentence: "XML MIME entities SHOULD NOT use UTF-32."

3.2: I think it's worth mentioning in the discussion of inconsistencies that attempting to transcode in the face of inconsistency can cause non-reversible damage. For example, if the charset parameter says "iso-8859-1" and the XML encoding says "utf-8" *and* the content *is* actually utf-8, attempting to change the supposed iso-8859-1 into something else (say, utf-8) can plausibly make it impossible to get back the original data and interpret it appropriately. (You could also mention this in 8.7 and 8.8.)

4.1: "SHOULD/MUST NOT be used". These seem kinda bogus to me. This is talking about appropriate use. I would change "SHOULD be used" to "is/are appropriate for this entity" and change "MUST NOT be used" to "are not appropriate for this entity." I can't get my head around what an exception to the SHOULD would be, or what an implementation would be thinking that needs to be told it MUST NOT use a particular type, so I don't see what all of this capitalization gets you.

Similarly, the two "RECOMMENDED"s in this section aren't protocol instructions. They're simply suggestions.

4.2:

   Media types following the naming convention '+xml' SHOULD introduce
   the charset parameter for consistency, since XML-generic processing
   applies the same program for any such media type.

I don't understand what that means. Two bits: (1) What does "introduce" mean in this context? That +xml media types should "define" or "require" a charset parameter? (2) What does "applies the same program" mean? Please clarify.

The "SHOULD" in the penultimate paragraph seems misused.

4.3:

I think all of this SHOULD-ing and RECOMMEND-ing is kind of silly. These are registration guidelines and suggestions, after all.

s/Enabling the charset parameter/Specifying the use of the charset parameter

Make sure that the RFC Editor is aware that you want to change the XXXX to the RFC number of this document.

5:

Strike the two MUSTs from the second paragraph. They're not useful.

Is the fourth paragraph putting a requirement on IETF document authors? Or W3C authors? Or authors of XML documents? It sounds like we're putting requirements on the W3C, which doesn't seem appropriate.

(Martin Stiemerling) No Objection