Subject: [apps-discuss] I-D Action: draft-ietf-appsawg-xml-mediatypes-07.txt

From: [email-masked]
Date: Thu, 06 Feb 2014 10:36:42 -0800

A New Internet-Draft is available from the on-line Internet-Drafts directories.
 This draft is a work item of the Applications Area Working Group Working Group of the IETF.

        Title           : XML Media Types
        Authors         : Henry S. Thompson
                          Chris Lilley
	Filename        : draft-ietf-appsawg-xml-mediatypes-07.txt
	Pages           : 31
	Date            : 2014-02-06

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.

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-appsawg-xml-mediatypes/

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-ietf-appsawg-xml-mediatypes-07

A diff from the previous version is available at:
http://www.ietf.org/rfcdiff?url2=draft-ietf-appsawg-xml-mediatypes-07

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

---

From: [email-masked] (Henry S. Thompson)
Date: Fri, 07 Feb 2014 12:13:52 +0000

As usual, a disposition of comments against the previous draft is
available at

  http://www.w3.org/XML/2012/10/3023bis/06-comments.html

and an author's diff is at

  http://www.w3.org/XML/2012/10/3023bis/draft-ietf-appsawg-xml-mediatypes-07_diff.html

This draft has few changes from version 6, almost all as a result of a
review by Larry Masinter, for which thanks.

The only change even close to substantive is a summary RECOMMENDATION
near the beginning of section 3, Encoding Considerations, which says

  The use of UTF-8, without a BOM, is RECOMMENDED for all XML MIME entities.

See the 06-comments document for a summary of the discussion about
this.

The level of comments on this draft has shifted from substantive to
rhetorical/editorial, and I think it's now pretty much fully-baked.
I'd very much welcome some endorsements of its readiness, so that we
can move it up and out of here.

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: Tim Bray <[email-masked]>
Date: Sat, 8 Feb 2014 11:46:01 -0800

Disclosure: This is the first draft of xml-mediatypes I’ve read in years,
so probably is a little lacking in context.

2.2: “[UNICODE] defines three "encoding forms", which are independent of
serialization” - what does “independent of serialization” mean?  I think
the UTF-* are actually serializations of unicode codepoints.  I suppose
UTF-16 is sort-of semi-independent of serialization, but UTF-8 never is.

2nd last para of 3.1, beginning “XML MIME producers are RECOMMENDED to
provide means for XML MIME entity authors to determine what value” baffles
me.  I just read it 3 times and I don’t get it.   Could we have an example
or something?  I also think I disagree with my guess as what it’s trying to
say.  I tend to think the tools are going to do a better job of figuring
out the right charset labeling than your typical document author.

The crucial “ this specification sets the priority as follows:” indented
para in 3.2.  I think a little more is needed. The crucial corner case is
when you’ve got a MIME-header charset that is just wrong but an XML-aware
receiver can in fact sort things out based on the encoding declaration.
 What does being “authoritative” mean concretely? Is it the RFC’s
recommendation that the receiver SHOULD refuse to parse the the XML even
though it could?  If so, we should say so explicitly.

Then in the example in 9.8, draft says “all processors will treat the
enclosed entity as iso-8859-1 encoded.   That is, the "UTF-8" encoding
declaration will be ignored.”  Is this really true in practice?  I suspect
not; so perhaps you should say “all processors which conform to this
specification will”.  Hm, or perhaps the real issue is that in this case,
you can’t predict what will happen; some implementations will ignore the
MIME header, others will drop-kick the XML because of the inconsistency.

Section 3.3 typo, “thatUTF-16”, space needed, also “entitiesnot” in the
same sentence.

Also some spacing problems in the NOTE: in 8.1

On Fri, Feb 7, 2014 at 4:13 AM, Henry S. Thompson <[email-masked]> wrote:

> _______________________________________________
> apps-discuss mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/apps-discuss
>

---

From: [email-masked] (Henry S. Thompson)
Date: Mon, 10 Feb 2014 10:07:29 +0000

> so probably is a little lacking in context.

Thanks for taking the time to review.

> UTF-16 is sort-of semi-independent of serialization, but UTF-8 never is.

The three encoding forms (UTF-8, -16 and -32) allow for at least 7
serializations between them.  And the text does go on to say that
UTF-8 has only one serialization.  So I don't think there's anything
wrong here, and it is following the UNICODE spec itself.

> or something?

Sure, sorry if this was obscure.  I was trying to avoid having to give
an application-specific example, but .htaccess AddType or IIS Mime
type configuration is what this is about.  I'll try to improve this.

> I also think I disagree with my guess as what it’s trying to

Really?  Neither of the above-mentioned tools will do the 'right'
thing with my XHTML by default, for example.

> receiver can in fact sort things out based on the encoding declaration.

There's nothing this document, or any processor, can do to always get
it right when there is conflicting encoding information.  The overall
aim of section 3 is to focus on MIME, and to push hard on the
proposition that a charset parameter should only be supplied if it is
known to be correct.  It is then consistent to say that when it _is_
present (and there is no BOM), it is authoritative.

> though it could?  If so, we should say so explicitly.

No -- 'authoritative' means 'answers the question "how to determine
the encoding with which to attempt to process the entity"'.  So the
RFC is telling you how to process the entity, which is its job, after
all.

> specification will”.

I could make it 'conformant processors', but the whole point of a
media type specification is to describe the behaviour of conformant
processors. . .

>  Hm, or perhaps the real issue is that in this case, you can’t
> predict what will happen; some implementations will ignore the MIME
> header, others will drop-kick the XML because of the inconsistency.

In practice, that's right.  The crucial point, as section 3 concludes
by emphasising, this whole problem _only_ arises when a non-conforming
_producer_ has screwed up.  The primary thrust of the spec is to
clarify what producers must to, so that the practical relevance of the
impossibility of consumers getting it right is minimised.

> Also some spacing problems in the NOTE: in 8.1

Thanks, will be fixed in next draft.

ht

---

From: Tim Bray <[email-masked]>
Date: Tue, 11 Feb 2014 10:53:54 -0800

> wrong here, and it is following the UNICODE spec itself.

The sentence “[UNICODE] defines three "encoding forms", which are
independent of serialization, namely UTF-8, UTF-16 and UTF-32. ” is really
horribly misleading. UTF-8 is a serialization. UTF-16 and -32 are not
independent of serialization in the slightest, you can’t process them
successfully unless you know whether you’re looking at the _LE or _BE
serializations.  How about something like

[UNICODE] defines several “encoding forms”, namely UTF-8, UTF-16, and
UTF-32.  UTF-8 is a serialization. Note that UTF-16 XML documents may be
serialised into MIME entities in ... [also loses the information-free
sentence about the spec following the “precedent”]

> thing with my XHTML by default, for example.

Ah, I got it finally; as the other thread said, what this is *really*
talking about is configuring your web server and so on.  So this is OK,
except for I think the word “author” is misleading since document authors
shouldn’t be expected to understand Unicode encodings or webserver
considerations.   So maybe something like:

XML MIME producers are RECOMMENDED to provide means to control what value,
if any, is given to charset parameters for XML MIME entities, for example
by enabling Web server configuration of filename-to-Content-Type-header
mappings on a file- by-file or suffix basis.

> RFC is telling you how to process the entity, which is its job, after

RIght, but it feels bizarre and sort of against the spirit of Postel’s law
to remain completely silent about what happens when there are conflicts.  I
suggest you simply say that in the case of conflict, interoperability can
suffer since the observed behavior of receiving software is unpredictable.
 This reinforces your central thrust, which is: Don’t do this.

> media type specification is to describe the behaviour of conformant

It bothers me that the assertion, as stated, is simply wrong, and I don’t
think RFCs should contain assertions which are empirically false.   It’s
fairly common in the RFCs that I say to note that conformant
implementations will do thus and so.

---

From: [email-masked] (Henry S. Thompson)
Date: Fri, 14 Feb 2014 14:03:12 +0000

Tim Bray writes:

> [wrt 2.2]
> How about something like

How about

  [UNICODE] defines three "encoding forms", namely UTF-8, UTF-16, and
  UTF-32. As UTF-8 can only be serialized in one way, the only possible
  label for UTF-8-encoded documents when serialised into MIME entities
  is "utf-8".  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".

and add the following (removing the earlier verrsion from 3.1), per my
reply to SM:

  UTF-32 has four potential serializations, of which only two
  (UTF-32BE and UTF-32LE) are given names in in [UNICODE]. Support
  for the various serializations varies widely, and security concerns
  about their use have been raised.  The use of UTF-32 is NOT
  RECOMMENDED for XML MIME entities.

> mappings on a file- by-file or suffix basis.

Thanks, that works.

>  This reinforces your central thrust, which is: Don’t do this.

OK - will do, by clarifying that by 'authoritative' is meant 'do it
this way', while acknowledging that this will not (cannot) _always_ do
the 'right' thing.

> implementations will do thus and so.

Happy to make the change.  Will see if it is needed/feels right in
other examples.

ht

---

From: Tim Bray <[email-masked]>
Date: Fri, 14 Feb 2014 08:15:26 -0800

>   (optionally) "utf-16" or "utf-16le".

Excellent.

> this way', while acknowledging that this will not (cannot) _always_ do

Fair enough. Do consider mentioning unpredictable behavior, I’ve found that
useful in explaining why something is a good idea, and in this case it has
the virtue of being true.