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

From: Erik Wilde <[email-masked]>
Date: Mon, 14 Oct 2013 21:45:44 -1000

On 2013-09-17 10:22 , Julian Reschke wrote:
> 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.
> Here's my late feedback (IETF, interim meetings, vacation, etc pp):

here's my even later feedback for draft-ietf-appsawg-xml-mediatypes

first of all, i'd like to thank julian for his very thorough review, and 
i think for all the charset-related issues, he's definitely in a much 
better position to provide feedback than i am. therefore i am supporting 
the comments julian made in his review, and my review is focusing more 
on the XML side of things.

> Network Working Group                                          C. Lilley
> Internet-Draft                                                       W3C
> Obsoletes: 3023 (if approved)                                  M. Murata
> Updates: 4289, 6839 (if approved)      International University of Japan

i guess i have the same question here as julian: why would it update RFC 
6839, instead of just referencing it? if this is just the technicality 
of RFC 6839 referencing this draft, then that would probably answer my 
question.

>    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 a convention (using the
>    suffix '+xml') for naming media types outside of these five types
>    when those media types represent XML MIME entities.

isn't that convention standardized by RFC 6839 already? i guess the 
problem is that instead of defining a registry that can be updated, any 
change to the suffixes needs to update RFC 6839? maybe rephrase this to 
say "updates the convention", because when reading this abstract, people 
knowing RFC 6839 may be wondering what's going on.

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

agree with julian that this is should not be part of the abstract. it's 
useful and probably could be easily moved to someplace else.

> 3.  XML Media Types
>    This specification standardizes three media types related to XML MIME
>    entities: application/xml (with text/xml as an alias), application/
>    xml-external-parsed-entity (with text/xml-external-parsed-entity as
>    an alias), and application/xml-dtd.  Registration information for
>    these media types is described in the sections below.

it would be useful to add application/xsd+xml in the updated spec, since 
XSD does not have its own media type.

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

s/mechanism). the/mechanism), the

i am not quite understanding the paranthesis after HTTPS. isn't HTTP 
doing exactly the same as HTTP, only over a safe transport? what does 
"which uses a MIME-like mechanism" refer to?

>    XML provides a general framework for defining sequences of structured
>    data.  In some cases, it may be desirable to define new media types
>    that use XML but define a specific application of XML, perhaps due to
>    domain-specific display, editing, security considerations or runtime
>    information.

the "perhaps" part seems a bit modest. there's quite a large set of web 
service designers thinking that unless you are exposing generic XML 
facilities (such as an XML database), you shouldn't be using a generic 
XML media type. so i would not make this sound as restricted as it is 
sounding now.

>    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 editting tools.  For

s/editting/editing/

>    Applications that use this media type:  XML is device-, platform-,
>       and vendor-neutral and is supported by a wide range of generic XML
>       tools (editors, parsers, Web agents, ...) and task-specific
>       applications.

i am not sure this needs to be spelled out, but in between generic XML 
and task-specific applications, there's a large set of generic XML-based 
formats (such as Atom) which does not really seem to fit well into this 
characterization of applications?

>          Although no byte sequences can be counted on to always be
>          present, XML MIME entities in ASCII-compatible charsets

s/charsets/character sets/

>          (including UTF-8) often begin with hexadecimal 3C 3F 78 6D 6C
>          ("<?xml"), and those in UTF-16 often begin with hexadecimal FE
>          FF 00 3C 00 3F 00 78 00 6D 00 6C or FF FE 3C 00 3F 00 78 00 6D
>          00 6C 00 (the Byte Order Mark (BOM) followed by "<?xml").  For
>          more information, see Appendix F of [XML].

maybe turn the reference [XML] into [XML1.0], so that it's always easy 
to see which version you're referencing?

>    The syntax and semantics of fragment identifiers for the XML media
>    types defined in this specification are based on the
>    [XPointerFramework] W3C Recommendation.  It allows simple names, and
>    more complex constructions based on named schemes.  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

not sure: s/conformant/conforming/

>    interpret such fragment identifiers as designating that part of the
>    retrieved representation specified by [XPointerFramework] and
>    whatever other specifications define any XPointer schemes used.
>    Conformant applications MUST support the 'element' scheme as defined

again, not sure: s/Conformant/Conforming/

>    See Section 8.1 for additional rquirements which apply when an XML-

s/rquirements/requirements/

>    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

this reads a bit odd. what about saying:

"URIs [RFC3986] are encoded in a limited subset of the repertoire of 
US-ASCII [ASCII], and therefore this encoding applies to fragment 
identifier parts of URIs as well."

an editorial note: sometime, the text is written like this:

- "For more information, see Appendix F of [XML]"

and sometimes like this:

- "a limited subset of the repertoire of US-ASCII [ASCII]"

maybe make the entire text consistent by either using references as a 
noun or not.

>    Section 5.1 of [RFC3986] specifies that the semantics of a relative
>    URI reference embedded in a MIME entity is dependent on the base URI.
>    The base URI is either (1) the base URI embedded in context, (2) the
>    base URI from the encapsulating entity, (3) the base URI from the
>    Retrieval URI, or (4) the default base URI, where (1) has the highest
>    precedence.

s/where (1) has the highest precedence./sorted by declining precedence./

>    The media type dependent mechanism for embedding the base URI in a
>    MIME entity of type application/xml, text/xml, application/xml-
>    external-parsed-entity or text/xml-external-parsed-entity is to use
>    the xml:base attribute described in detail in [XBase].

maybe rename the reference to [XMLBase] to reflect the name of the spec?

not that i think this matters in practice, but this means that it is 
impossible to use anything other than XML Base for this, right? XML 
itself really does not say anything about it, so it seems than text/xml 
goes a little bit in the direction of the infoset set, specifying 
additional (but fewer) constraints. is the intention to make this a 
MUST? if so, wouldn't it be appropriate to use normative language? and 
if not, wouldn't it be good to say that using XML Base probably is a 
Really Good Idea, but not actually required?

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

so this means that the base URI changes depending on whether the used 
XML processor is validating or not, right? maybe it would be worth 
spelling this out, because it may come as a surprise to some.

>    MIME entities by comparing the subtype to the pattern '*/*+xml'.  (Of
>    course, 4 of the 5 media types defined in this specification -- text/
>    xml, application/xml, text/xml-external-parsed-entity, and
>    application/xml-external-parsed-entity -- also represent XML MIME
>    entities while not conforming to the '*/*+xml' pattern.)

maybe: s/Of Course/For historical reasons/

>    The registration process for specific '+xml' media types is described
>    in [RFC6838] and [RFC6839].

just [RFC6838], i think.

> 8.2.  +xml Structured Syntax Suffix Registration

maybe a formality, but does it need to be registered if it has been an 
integral part of RFC 6839, and will be updated by RFC 3032bis? doesn't 
this update mean it exists without having to be registered?

>    For application... cases, if sent using a 7-bit transport (e.g.,

s/application.../application\/.../

>    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)).

s/HTTPS---text/HTTPS. text/

>    XML MIME entities contain information which may be parsed and further
>    processed by the recipient's XML system.

s/XML system/system/

>    These entities may contain
>    and such systems may permit explicit system level commands to be
>    executed while processing the data.  To the extent that an XML system

s/XML system/XML-based system/

i guess i am struggling here to understand what "XML system" is supposed 
to mean. just the XML processing parts? or the complete system that 
works with XML-based data? clarifying this upfront might help.

>    will execute arbitrary command strings, recipients of XML MIME
>    entities may be a risk.  In general, it may be possible to specify
>    commands that perform unauthorized file operations or make changes to
>    the display processor's environment that affect subsequent
>    operations.

where do these two rather specific command types (file access, display 
processor) come from? probably from resolving references within XML 
content, and trying to render it, but maybe either make that a little 
more explicit, or keep the warning more general?

>    The simplest attack involves adding declarations that break
>    validation.  Adding extraneous declarations to a list of character
>    XML-entities can effectively "break the contract" used by documents.
>    A tiny change that produces a fatal error in a DTD could halt XML
>    processing on a large scale.  Extraneous declarations are fairly
>    obvious, but more sophisticated tricks, like changing attributes from
>    being optional to required, can be difficult to track down.  Perhaps
>    the most dangerous option available to crackers is redefining default
>    values for attributes: e.g., if developers have relied on defaulted
>    attributes for security, a relatively small change might expose
>    enormous quantities of information.

this of course only matters if the processing model actually uses a 
schema language that supports default values. that in itself is 
something that has been discussed for a long time in terms of benefits 
and risks. maybe it would be worth pointing out that the security 
problem only exists when a certain processing model (in this case 
defined by the choice of schema language) is chosen.

>    Apart from the structural possibilities, another option, "XML-entity
>    spoofing," can be used to insert text into documents, vandalizing and
>    perhaps conveying an unintended message.  Because XML permits
>    multiple XML-entity declarations, and the first declaration takes
>    precedence, it's possible to insert malicious content where an XML-

s/it's/it is/

kind regards,

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: Bjoern Hoehrmann <[email-masked]>
Date: Tue, 15 Oct 2013 14:28:00 +0200

>of RFC 6839 referencing this draft, then that would probably answer my 

The update to RFC 6839 is that RFC 6839 no longer defines the `+xml`
structured suffix, draft-ietf-appsawg-xml-mediatypes does that once
approved. Note that RFC 6839 took that role from RFC 3023 which it
updates for the same reason.

>knowing RFC 6839 may be wondering what's going on.

It seems s/standardizes/defines/ would address this comment.
-- 
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/

---

From: Julian Reschke <[email-masked]>
Date: Tue, 15 Oct 2013 14:43:23 +0200

> updates for the same reason.

Yes and no. RFC 6838 established an IANA registry for this, so from now 
on it's not necessary anymore to do the "update/obsolete" dance.

(I may sound like a broken record but it is weird that an RFC that 
establishes an IANA registry doesn't contain the URI of the registry).

> ...

Best regards, Julian

---

From: Bjoern Hoehrmann <[email-masked]>
Date: Tue, 15 Oct 2013 14:56:01 +0200

>on it's not necessary anymore to do the "update/obsolete" dance.

I do not know about "necessary", but if RFC 6839 contained only the
`+xml` registration I would expect draft-ietf-appsawg-xml-mediatypes
to obsolete RFC 6839 just like it obsoletes RFC 3023; but since RFC
6839 contains more than `+xml` it can only "partially obsolete" it,
and "Updates" conveys that more clearly than saying nothing.
-- 
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/

---

From: Julian Reschke <[email-masked]>
Date: Tue, 15 Oct 2013 15:03:32 +0200

> and "Updates" conveys that more clearly than saying nothing.

The point I was trying to make is that we now have a registry. The 
registry is authoritative; if we move the definition of "+xml", it's 
sufficient to simply update the registry.

Best regards, Julian

---

From: [email-masked] (Henry S. Thompson)
Date: Tue, 15 Oct 2013 18:08:22 +0100

> sufficient to simply update the registry.

I don't agree.  If we don't include 'Updates: 6839', then 6839 will
not get an 'Updated by [3023bis]', and anyone reading 6839 will be
free to conclude that it defines +xml, which would be false.

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, 15 Oct 2013 19:16:39 +0200

> free to conclude that it defines +xml, which would be false.

Anyone reading it that way would be reading it incorrectly :-)

But anyway, that's something the IESG can worry about.

Best regards, Julian

---

From: t.petch <[email-masked]>
Date: Thu, 17 Oct 2013 17:23:22 +0100

----- Original Message -----
From: "Julian Reschke" <[email-masked]>
To: "Henry S. Thompson" <[email-masked]>
Cc: "Bjoern Hoehrmann" <[email-masked]>; <[email-masked]>
Sent: Tuesday, October 15, 2013 6:16 PM
> But anyway, that's something the IESG can worry about.

Having just read about the difficulty in finding potential members of
the IESG, I think we should do what we can as a WG to make the task of
the IESG simpler, in this case by putting forward a rough consensus from
the WG.

I am with Henry on this one.  It is true that if your world revolves
around web pages, then the IANA web page will take you to the current
definition whereever that is.  But if you start with RFC, for example
with the rfc-index, and that does not mention an update to an RFC, then
you will go astray.

Comparing the two definitions, in RFC6839 and this I-D, they seem to me
like chalk and cheese, as for example in who has change control and who
the contact is, so that the RFC6839 one will be wiped from the face of
the earth; specifying 'Updates' seems the least we can do.

Tom Petch