Subject: Re: [apps-discuss] Working Group Last Call: draft-ietf-appsawg-xml-mediatypes

From: [email-masked] (Henry S. Thompson)
Date: Tue, 17 Sep 2013 12:32:58 +0100

At 22:52 13-08-2013, Murray S. Kucherawy wrote:

> A gentle reminder that this WGLC is in effect, closing in a few
> days.  To date there have been no comments or reviews on the WGLC at
> all.  It will be hard for me to argue that consensus exists without
> at least a few reviews on the record.

This reminder produced only one reply, with what I believe are
essentially editorial suggestions.  _Please_ can we get a few more
reviews, even if they are just "Yes, it's time to take this forward".

This RFC documents a moderately important part of the Web
infrastructure, and its predecessor is out-of-date and indeed
misleading in important ways, so we really do need to get it out the
door.

Thanks,

ht
-- 
       Henry S. Thompson, School of Informatics, University of Edinburgh
      10 Crichton Street, Edinburgh EH8 9AB, SCOTLAND -- (44) 131 650-4440
                Fax: (44) 131 650-4587, e-mail: [email-masked]
                       URL: http://www.ltg.ed.ac.uk/~ht/
 [mail from me _always_ has a .sig like this -- mail without it is forged spam]

---

From: Julian Reschke <[email-masked]>
Date: Tue, 17 Sep 2013 17:04:21 +0200

On 2013-07-29 10:08, Murray S. Kucherawy wrote:
> This note begins a Working Group Last Call for draft-ietf-appsawg-xml-mediatypes, ending on Friday, August 16.  Please provide reviews and comments on this list or privately to the authors as soon as possible.
>
> -MSK, APPSAWG co-chair and document shepherd
> _______________________________________________
> apps-discuss mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/apps-discuss

Checking reference nits using 
<http://greenbytes.de/tech/webdav/rfc2629xslt/rfc2629xslt.html#checking-references>:

> Normative References:
> RFC2045: [DRAFT STANDARD] ok
> RFC2046: [DRAFT STANDARD] ok
> RFC2119: [BEST CURRENT PRACTICE] (-> BCP0014) ok
> RFC2616: [DRAFT STANDARD] ok
> RFC2781: [INFORMATIONAL] ok
> RFC3986: [INTERNET STANDARD] (-> STD0066) ok
> RFC3987: [PROPOSED STANDARD] ok
> RFC6657: [PROPOSED STANDARD] ok
> RFC6838: [BEST CURRENT PRACTICE] (-> BCP0013) ok
> RFC6839: [INFORMATIONAL] ok
> xmlbase: document unknown
> REC-xml: [Description] ok
> REC-xml: [Description] ok
> REC-XPointer-Element: document unknown
> REC-XPointer-Framework: document unknown
> XPtrReg: not checked

For all the W3C documents, I recommend to pull in the <reference> 
elements from 
<http://greenbytes.de/tech/webdav/rfc2629xslt/w3c-references.html> -- 
this makes the format consistent and enables automatic up-to-date checking.

> Informative References:
> ASCII: not checked
> REC-CSS2: [Description] ok
> HTTPbis: not checked

This should either be dropped as not being relevant, or be an actual 
up-to-date Internet Draft reference to draft-ietf-httpbis-p2-semantics-23.

> ISO8859: not checked
> RFC1557: [INFORMATIONAL] ok
> RFC2130: [INFORMATIONAL] ok
> RFC2376: [INFORMATIONAL] obsoleted by RFC3023
> RFC2703: [INFORMATIONAL] ok
> RFC3023: not checked
> RFC3629: [INTERNET STANDARD] (-> STD0063) ok
> RFC3977: [PROPOSED STANDARD] ok
> RFC4289: [BEST CURRENT PRACTICE] (-> BCP0013) ok
> RFC5321: [DRAFT STANDARD] ok
> RFC6152: [INTERNET STANDARD] (-> STD0071) ok
> TAGMIME: not checked
> xhtml1: document unknown

Best regards, Julian

---

From: Erik Wilde <[email-masked]>
Date: Tue, 17 Sep 2013 11:04:19 -0700

hello.

> misleading in important ways, so we really do need to get it out the

it would be great to see this getting published. if there's anything i 
can do to help, please let me know.

(and i still think it would be nice to have media types for XSD and 
maybe sneak them in this way, but maybe that's more counter-productive 
for this to be finished than it is helpful... :-)

thanks and cheers,

dret.

-- 
erik wilde | mailto:[email-masked]  -  tel:+1-510-2061079 |
            | UC Berkeley  -  School of Information (ISchool) |
            | http://dret.net/netdret http://twitter.com/dret |

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Tue, 17 Sep 2013 11:10:19 -0700

On Tue, Sep 17, 2013 at 11:04 AM, Erik Wilde <[email-masked]> wrote:

> it would be great to see this getting published. if there's anything i can
> do to help, please let me know.
>
>
How about a review of the version that was last-called earlier this
summer?  ;-)

-MSK

---

From: Dave Cridland <[email-masked]>
Date: Tue, 17 Sep 2013 20:49:15 +0100

A quick review.

Top of page 6, inside §3, there's a slightly mangled paragraph:

      The top-level media type "text" has some restrictions on MIME
      entities and they are described in [RFC2045] and [RFC2046].  In
      particular, for transports other than HTTP [RFC2616] or HTTPS
      (which uses a MIME-like mechanism).  the UTF-16 family, UCS-4, and
      UTF-32 are not allowed However, section 4.3.3 of [XML] says:

Beyond the apparent mangling, I'm pretty sure that nothing prevents the use
of UTF-16 in a text/xml within email, as long as it has a suitable
Content-Transfer-Encoding for the transmission path (ie, base64, probably).
The encoding considerations in §3.1, which §3.2 points to, seem to agree
with me.

I think what it's trying to say is that an XML document using UTF-16
encoding will by definition have NUL octets, and these are not allowed
unencoded along 7- or 8-bit transmission paths, and therefore must be
encoded using Base64 on non-binary paths.

§11

I don't know if it's worthwhile discussing XML based attacks such as the
Billion Laughs attack; I don't think it'd hurt.

Otherwise, all looks good to my eyes.

---

From: Julian Reschke <[email-masked]>
Date: Tue, 17 Sep 2013 22:22:01 +0200

On 2013-07-29 10:08, Murray S. Kucherawy wrote:
> ...

Here's my late feedback (IETF, interim meetings, vacation, etc pp):

Updates: 4289, 6839 (if approved)

Really?

    Major differences from [RFC3023] are alignment of charset handling
    for text/xml and text/xml-external-parsed-entity with application/
    xml, the addition of XPointer and XML Base as fragment identifiers
    and base URIs, respectively, mention of the XPointer Registry, and
    updating of many references.

I don't think this needs to be in the Abstract. Also, references are 
discouraged here because the abstract should be usable stand-alone. So 
maybe move into the Introduction.

    document entities  The media types application/xml or text/xml MAY be
       used

s/used/used./

    Application/xml and application/xml-external-parsed-entity are
    recommended.  Compared to [RFC2376] or [RFC3023], this specification
    alters the charset handling of text/xml and text/xml-external-parsed-
    entity, treating them no differently from the respective application/
    types.  The reasons are as follows:

s/Application/application/

Also, avoid lowercase "recommended" it it's not a "RECOMMENDED".

       Conflicting specifications regarding the character encoding have
       caused confusion.  On the one hand, [RFC2046] specifies "The
       default character set, which must be assumed in the absence of a
       charset parameter, is US-ASCII.", [RFC2616] Section 3.7.1, defines
       that "media subtypes of the 'text' type are defined to have a
       default charset value of 'ISO-8859-1'", and [RFC2376] as well as
       [RFC3023] specify the default charset is US-ASCII.

I think this just repeats history already captureed in RFC 6557. Do we 
really need to repeat it over here?

       The current situation, reflected in this specification, has been
       simplified by [RFC6657] updating [RFC2046] to remove the US-ASCII
       default.  Furthermore, in accordance with [RFC6657]'s other
       recommendations, [HTTPbis] changes [RFC2616] by removing the
       ISO-8859-1 default and not defining any default at all.

This is a bit misleading as the change in httpbis predates RFC6657 
significantly.

It would be helpful if the reference to 2045/6 would be a bite more 
specific.

I'd also prefer to get rid of all RFC2616 references except when 
referring to the specification's history.

    However, developers of such media types are STRONGLY RECOMMENDED to
    use this specification as a basis for their registration.  In
    particular, the charset parameter, if used, MUST agree with the in-
    band XML encoding of the XML entity, as described in Section 3.6, in
    order to enhance interoperability.

There's no "STRONGLY" keyword. In general, I'd avoid to use BCP14 
keywords for recommendations to people.

    Encoding considerations:  This media type MAY be encoded as
       appropriate for the charset and the capabilities of the underlying
       MIME transport.  For 7-bit transports, data in either UTF-8 or

I don't understand the "MAY" here.

    Published specification:  Extensible Markup Language (XML) 1.0 (Fifth
       Edition) [XML], Extensible Markup Language (XML) 1.1 (Second
       Edition) [XML1.1].

OK, so I can use the same media type for both XML 1.0 and 1.1. However, 
the way this is phrased makes it appear as if XML 1.1 is somehow more 
... recent when in fact it was a dead-end.

I recommend dropping the references about 1.1 from everywhere, and just 
have a single place that points out that what's said about 1.0 is also 
true for 1.1.

    Interoperability considerations:  XML DTDs have proven to be
       interoperable by DTD authoring tools and XML browsers, among
       others.

What is an "XML browser"? If this is about web browsers I really have my 
doubts that they work interoperably :-)

    The charset parameter MUST only be used, when the charset is reliably
    known and agrees with the in-band XML encoding declaration.  This

s/used,/used/

Also, what if there is no in-band declaration?

    authoritatively the charset of the XML MIME entity.  The charset
    parameter can also be used to provide protocol-specific operations,
    such as charset-based content negotiation in HTTP.

That's misleading. charset-based content negotiation happens by use of 
Accept-Encoding, bot the charset parameter.

    There are several reasons that the charset parameter is optionally
    allowed.  First, recent web servers have been improved so that users

That text is 12 years old. We may want to drop or rephrase it :-)

    can specify the charset parameter.  Second, [RFC2130] (informative)
    specifies that the recommended specification scheme is the "charset"
    parameter.

That refers to a document from 1996. Is this really relevant here?

    On the other hand, it has been argued that the charset parameter
    should be omitted and the mechanism described in Appendix F of [XML]
    (which is non-normative) should be solely relied on.  This approach
    would allow users to avoid configuration of the charset parameter; an
    XML document stored in a file is likely to contain a correct encoding
    declaration or BOM (if necessary), since the operating system does
    not typically provide charset information for files.  If users would
    like to rely on the in-band XML encoding declaration or BOM and/or to
    conceal charset information from non-XML processors, they can omit
    the parameter.

This now is really the recommended approach, no? Maybe the whole of 
3.6.1 should be removed then.

    Uniform Resource Identifiers (URIs) may contain fragment identifiers
    (see Section 3.5 of [RFC3986]).  Likewise, Internationalized Resource
    Identifiers (IRIs) [RFC3987] may contain fragment identifiers.

s/may/can/

Also, the reference to RFC3987 really doesn't add anything useful here.

    See Section 8.1 for additional rquirements which apply when an XML-
    based MIME media type follows the naming convention '+xml'.

s/rquirenents/requirements/

    If [XPointerFramework] and [XPointerElement] are inappropriate for
    some XML-based media type, it SHOULD NOT follow the naming convention
    '+xml'.

Really? Why not? What about application/xhtml+xml?

    When a URI has a fragment identifier, it is encoded by a limited
    subset of the repertoire of US-ASCII [ASCII] characters, as defined
    in [RFC3986].  When an IRI contains a fragment identifier, it is
    encoded by a much wider repertoire of characters.  The conversion
    between IRI fragment identifiers and URI fragment identifiers is
    presented in Section 7 of [RFC3987].

I recommend to drop the IRI specific part. This is not specific to XML 
types.

    Note that the base URI may be embedded in a different MIME entity,
    since the default value for the xml:base attribute may be specified
    in an external DTD subset or external parameter entity.

s/may/might/ s/may/can/

    application/xml, application/xml-external-parsed-entity, and
    application/xml-dtd, text/xml and text/xml-external-parsed-entity are
    to be used with [XML]  In all examples herein where version="1.0" is

s/[XML]/[XML]./

    This specification recommends the use of a naming convention (a
    suffix of '+xml') for identifying XML-based MIME media types,

s/MIME// (there may be more instances of this)

    whatever their particular content may represent, in line with the

What is the "whatever their particular content may represent" about?

    When a new media type is introduced for an XML-based format, the name
    of the media type SHOULD end with '+xml'.  This convention will allow

Which may be in conflict with the SHOULD NOT I complained about earlier 
on :-)

       NOTE: Section 14.1 of HTTP [RFC2616] does not support Accept
       headers of the form "Accept: */*+xml" and so this header MUST NOT
       be used in this way.  Instead, content negotiation [RFC2703] could
       potentially be used if an XML-based MIME type were needed.

Please cite HTTPbis P2. Also, content negotiation is defined by HTTP, 
not RFC 2703.

    XML generic processing is not always appropriate for XML-based media
    types.  For example, authors of some such media types may wish that
    the types remain entirely opaque except to applications that are
    specifically designed to deal with that media type.  By NOT following
    the naming convention '+xml', such media types can avoid XML-generic
    processing.  Since generic processing will be useful in many cases,
    however -- including in some situations that are difficult to predict
    ahead of time -- those registering media types SHOULD use the '+xml'
    convention unless they have a particularly compelling reason not to.

I recommend to avoid the use of SHOULD here. Just explain the pros and cons.

    The registration process for specific '+xml' media types is described
    in [RFC6838] and [RFC6839].  The registrar for the IETF tree will

Just RFC6838, as far as I can tell.

    The use of the charset parameter is STRONGLY RECOMMENDED, since this
    information can be used by XML processors to determine
    authoritatively the charset of the XML MIME entity.  If there are
    some reasons not to follow this advice, they SHOULD be included as
    part of the registration.  As shown above, two such reasons are
    "UTF-8 only" or "UTF-8 or UTF-16 only".

That's misleading. People may read it as saying that the *presence* of 
the charset parameter is RECOMMENDED.

          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
             Section 5, where the fragment identifier resolves per the
             rules specified there, then process as specified there;

Section 5 does not define the syntax (other then referencing XPointer). 
So this is a bit hard to process.

             For fragment identifiers _not_ matching the syntax defined
             in Section 5, then process as specified in "xxx/yyy+xml".

What would be an example for this case?

    All the examples below apply to all five media types declared above
    in Section 3, as well as to any media types declared using the '+xml'
    convention.  See the XML MIME entities table (Section 3, Paragraph 2)

Well, unless that type does not define the charset parameter, right?

    This section is non-normative.  In particular, note that all "MUST"
    language herein reproduces or summarizes the consequences of
    normative statement already made above, and have no independent
    normative force.

Can we avoid the use of MUST here, then? :-)

    Content-type charset: charset="utf-8"

Maybe it would be less confusing to say: "charset specified in 
content-type:"

    printable or base64.  For an 8-bit clean transport (e.g., 8BITMIME
    ESMTP or NNTP), or a binary clean transport (e.g., HTTP), no content-
    transfer-encoding is necessary.

...as HTTP does not even define content-transfer-encoding. (same applies 
to parts below)

    As described in [RFC2781], the UTF-16 family MUST NOT be used with
    media types under the top-level type "text" except over HTTP or HTTPS
    (see section 19.4.1 of [RFC2616] for details).  Hence this example is

Not sure how that section of 2616 is relevant here.

    Omitting the charset parameter is NOT RECOMMENDED for application/...
    when used with transports other than HTTP or HTTPS---text/... SHOULD
    NOT be used for 16-bit MIME with transports other than HTTP or HTTPS
    (see discussion above (Section 9.2, Paragraph 6)).

Please avoid uppercasing not-BCP14 keywords :-)

    Since the charset parameter is provided in the Content-Type header
    and differs from the XML encoding declaration, MIME and XML
    processors will not interoperate.  MIME processors will treat the
    enclosed entity as UTF-8 encoded.  That is, the "iso-8859-1" encoding
    will be ignored.  XML processors on the other hand will ignore the
    charset parameter and treat the XML entity as encoded in iso-8859-1.

Do we have a definition of "MIME processor"?

    As described in Section 8, this specification updates the [RFC6838]
    and [RFC6839]  registration process for XML-based MIME types.

My understanding is that the registration process is defined in 6838 only.

    the most dangerous option available to crackers is redefining default

s/crackers/attackers/

    Fourth, many references are updated, and the existence and relevance
    of XML 1.1 acknowledged.  Finally, a number of justifications and

As far as I can tell, XML 1.1 is totally irrelevant...

Best regards, Julian

---

From: Bjoern Hoehrmann <[email-masked]>
Date: Tue, 17 Sep 2013 23:10:38 +0200

>encoded using Base64 on non-binary paths.

It's partly about <http://tools.ietf.org/html/rfc2046#section-4.1.1>.
-- 
Björn Höhrmann · mailto:[email-masked] · http://bjoern.hoehrmann.de
Am Badedeich 7 · Telefon: +49(0)160/4415681 · http://www.bjoernsworld.de
25899 Dagebüll · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/