XML Media Types
draft-ietf-appsawg-xml-mediatypes-10

[Ballot comment]
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.

[Ballot discuss]

- 4.2: I'd like someone to explain the hand over to w3c
for +xml and what that means, just to check I get it.
I'm sure I'll clear this point on the call.

[Ballot comment]

- 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?

[Ballot comment]
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?

[Ballot comment]
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?

[Ballot comment]
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?

[Ballot comment]
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?

[Ballot comment]
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

IESG/Authors/WG Chairs:

IANA has reviewed draft-ietf-appsawg-xml-mediatypes-09.  Authors should review the comments and/or questions below.  Please report any inaccuracies and respond to any questions as soon as possible.

We received the following comments/questions from the IANA's reviewer:

Upon approval, this document requests that IANA complete three actions.

First, three media types are to be added to the applications media type registry located at:

http://www.iana.org/assignments/media-types/

The three media types to be added are:

xml
xml-external-parsed-entity
xml-dtd

Second, two media types are to be added to the text media type registry located at:

http://www.iana.org/assignments/media-types/

The two media types to be added are:

xml
xml-external-parsed-entity
xml-dtd

Third, in the Structured Syntax Suffix Registry located at:

http://www.iana.org/assignments/media-type-structured-suffix/

the first entry (the entry for Extensible Markup Language) in the registry is to be completely replaced as follows:

Name: Extensible Markup Language (XML)
+suffix: +xml
Reference: [ RFC-to-be ]
Encoding considerations: Depending on the character encoding used, XML MIME entities can consist of 7bit, 8bit or binary data [RFC6838]. For 7-bit transports, 7bit data, for example US-ASCII-encoded data, does not require content-transfer-encoding, but 8bit or binary data, for example UTF-8 or UTF-16 data, MUST be content- transfer-encoded in quoted-printable or base64. For 8-bit clean transport (e.g. 8BITMIME ESMTP [RFC6152] or NNTP [RFC3977]), 7bit or 8bit data, for example US-ASCII or UTF-8 data, does not require content-transfer-encoding, but binary data, for example data with a UTF-16 encoding, MUST be content-transfer-encoded in base64. For binary clean transports (e.g. BINARY ESMTP [RFC3030] or HTTP), no content-transfer-encoding is necessary (or even possible, in the case of HTTP) for 7bit, 8bit or binary data.
Fragment identifier considerations: Registrations which use this '+xml' convention MUST also make reference to [ RFC-to-be ], specifically Section 5 of that document, in specifying fragment identifier syntax and semantics, and they MAY restrict the syntax to a specified subset of schemes, except that they MUST NOT disallow barenames or 'element' scheme pointers. They MAY further require support for other registered schemes. They also MAY add additional syntax (which MUST NOT overlap with [ http://www.w3.org/TR/2003/REC-xptr-framework-20030325/ ] syntax) together with associated semantics, and MAY add additional semantics for barename XPointers which, as provided for in Section 5 of [ RFC-to-be ], will only apply when [ RFC-to-be ] does not define an interpretation.

In practice these constraints imply that for a fragment identifier addressed to an instance of a specific "xxx/yyy+xml" type, there are three cases:

For fragment identifiers matching the syntax defined in [ http://www.w3.org/TR/2003/REC-xptr-framework-20030325/ ], where the fragment identifier resolves per the rules specified there, then process as specified there;

For fragment identifiers matching the syntax defined in [ http://www.w3.org/TR/2003/REC-xptr-framework-20030325/ ], where the fragment identifier does _not_ resolve per the rules specified there, then process as specified in "xxx/yyy+xml";

For fragment identifiers _not_ matching the syntax defined in [ http://www.w3.org/TR/2003/REC-xptr-framework-20030325/ ], then process as specified in "xxx/ yyy+xml". A fragment identifier of the form "xywh?0,120,320,240", as defined in [ http://www.w3.org/TR/2012/REC-media-frags-20120925/ ], which might be used in a URI for an XML-encoded image, would fall in this category.

Interoperability considerations: Same as Section 9.1 of [ RFC-to-be ]. And also Section 3 of [ RFC-to-be ], for guidelines on the use of the 'charset' parameter.

Security considerations: See Section 10 of [ RFC-to-be ].

Contact: Henry S. Thompson, Chris Lilley

Author: Henry S. Thompson, Chris Lilley

Change controller: The XML specification is a work product of the World Wide Web Consortium's XML Core Working Group. The W3C has change control over [ RFC-to-be ].

IANA understands that these three actions are the only ones required to be completed upon approval of this document.

Note:  The actions requested in this document will not be completed
until the document has been approved for publication as an RFC. This message is only to confirm what actions will be performed.

The following Last Call announcement was sent out:

From: The IESG
To: IETF-Announce
CC:
Reply-To: ietf@ietf.org
Sender:
Subject: Last Call:  (XML Media Types) to Proposed Standard


The IESG has received a request from the Applications Area Working Group
WG (appsawg) to consider the following document:
- 'XML Media Types'
  as Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action. Please send substantive comments to the
ietf@ietf.org mailing lists by 2014-03-17. Exceptionally, comments may be
sent to iesg@ietf.org instead. In either case, please retain the
beginning of the Subject line to allow automated sorting.

Abstract

  This specification standardizes three media types -- application/xml,
  application/xml-external-parsed-entity, and application/xml-dtd --
  for use in exchanging network entities that are related to the
  Extensible Markup Language (XML) while defining text/xml and text/
  xml-external-parsed-entity as aliases for the respective application/
  types.  This specification also standardizes the '+xml' suffix for
  naming media types outside of these five types when those media types
  represent XML MIME entities.


Note that this document has normative references to eight W3C documents,
as well as two Informational RFCs.  The Informational RFCs are:
1. RFC 2781, "UTF-16, an encoding of ISO 10646"
2. RFC 6839, "Additional Media Type Structured Syntax Suffixes"

Both of those documents should be added to the downref registry (http://trac.tools.ietf.org/group/iesg/trac/wiki/DownrefRegistry) after this last
call completes.


The file can be obtained via
http://datatracker.ietf.org/doc/draft-ietf-appsawg-xml-mediatypes/

Once IESG discussion begins, it can be tracked via
http://datatracker.ietf.org/doc/draft-ietf-appsawg-xml-mediatypes/ballot/

No IPR declarations have been submitted directly on this I-D.

1. Summary

The document shepherd is Murray Kucherawy.
The responsible Area Director is Barry Leiba.

This document updates (and thus replaces) the text of RFC3023, which defined
three XML media types.  Proposed Standard status is appropriate for this work.

2. Review and Consensus

The document received review from several APPSAWG participants as well as their
counterparts in the W3C.  There is good consensus to post the draft, though there
was one unsustained objection about the potential for harm.  The document did go
through a period of neglect by the authors, and there was WG attrition (empty
WGLCs), but we recently managed to drive it to the point of being publication-ready.

The unsustained objection was from this message:

http://www.ietf.org/mail-archive/web/apps-discuss/current/msg10890.html

Many of the issues identified in that message were addressed in the -06 version
of the draft.  The issue that remained is the choice to make file contents
override protocol elements.  There was no support from other participants that
this is a concern that needed to be addressed in the document; to confirm this,
I specifically asked a couple of people expert in the field (Mark Nottingham,
Larry Masinter) and they felt there was no need for concern.  In early February,
2014, I inquired of the author of that message as to his position, and he conceded
that he appears to be in the rough and thus has not pressed the point further.

It would be nice to have an active XML Directorate from which to request a review
but that seems to have been dormant for a long time.  An early request to AppsDir
for a review was made but it appears this never occurred, though the likely suspects
all took part in the discussion in the WG anyway so this was not pursued.

3. Intellectual Property

There have been no IPR disclosures in the WG, and the authors have affirmed that
they are in compliance with BCPs 78 and 79.

4. Other Points

The document has normative references to RFC2781 (Informational), RFC6839
(Informational),  and a total of eight W3C documents.

The IANA Considerations section looks sound.  It does make reference to "RFC XXXX" which
is meant to be this document when published; this could be better noted for the
RFC Editor in the text.

1. Summary

The document shepherd is Murray Kucherawy.
The responsible Area Director is Barry Leiba.

This document updates (and thus replaces) the text of RFC3023, which defined
three XML media types.  Proposed Standard status is appropriate for this work.

2. Review and Consensus

The document received review from several APPSAWG participants as well as their
counterparts in the W3C.  There is good consensus to post the draft, though there
was one unsustained objection about the potential for harm.  The document did go
through a period of neglect by the authors, and there was WG attrition (empty
WGLCs), but we recently managed to drive it to the point of being publication-ready.

It would be nice to have an active XML Directorate from which to request a review
but that seems to have been dormant for a long time.  An early request to AppsDir
for a review was made but it appears this never occurred, though the likely suspects
all took part in the discussion in the WG anyway so this was not pursued.

3. Intellectual Property

There have been no IPR disclosures in the WG, and the authors have affirmed that
they are in compliance with BCPs 78 and 79.

4. Other Points

The document has normative references to RFC2781 (Informational), RFC6839
(Informational),  and a total of eight W3C documents.

The IANA Considerations section looks sound.  It does make reference to "RFC XXXX" which
is meant to be this document when published; this could be better noted for the
RFC Editor in the text.