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

From: [email-masked] (Henry S. Thompson)
Date: Wed, 16 Oct 2013 14:26:03 +0100

internet-drafts writes:

> 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
> 	Author(s)       : Henry S. Thompson
>                           Chris Lilley
> 	Filename        : draft-ietf-appsawg-xml-mediatypes-03.txt
> 	Pages           : 27
> 	Date            : 2013-10-16
>
> 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-03

A thorough exposition of all comments received on the previous draft,
and their resolution, is available at

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

Many thanks to the commentators, particularly Julian Reschke and Erik
Wilde, for careful reading and helpful input.

An author-markup-based diff is available at

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

This is much easier to read than the IETF auto-generated one.

Please note in particular that a significant addition has been made to
section 3.6 [1], to address the fact that the XML spec. itself defers
to this spec. to define the precedence of charset parameter, BOM and
XML encoding declaration.

The key new paragraph reads:

  All processors SHOULD treat a BOM (Section 4) as authoritative if it
  is present in an XML MIME entity.  In the absence of a BOM (Section
  4), all processors SHOULD treat the charset parameter as
  authoritative.  Section 4.3.3 of the [XML] specification does _not_
  make it an error for the charset parameter and the XML encoding
  declaration to be inconsistent.

Comments on this section, and wider review, would be very welcome.

ht

[1] http://tools.ietf.org/html/draft-ietf-appsawg-xml-mediatypes-03#section-3.6
-- 
       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: "Murray S. Kucherawy" <[email-masked]>
Date: Thu, 17 Oct 2013 00:12:58 -0700

Colleagues,

This one has already finished WGLC, but saw very little in the way of
reviews during.  There's been some good activity since, so I'm hoping we
can move this along soon.  Could we get those who commented before to chime
in again to indicate they've ready the revision and either have more
feedback, or think it's ready to progress?  And a few others?

Thanks,
-MSK, APPSAWG co-chair & document shepherd

On Wed, Oct 16, 2013 at 6:26 AM, Henry S. Thompson <[email-masked]> wrote:

> [1]
> http://tools.ietf.org/html/draft-ietf-appsawg-xml-mediatypes-03#section-3.6
> --
> _______________________________________________
> apps-discuss mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/apps-discuss
>

---

From: [email-masked] (Henry S. Thompson)
Date: Tue, 22 Oct 2013 16:13:56 +0100

I've produced a new draft, with only one (moderately large) change,
agreed in discussion with my fellow editor Chris Lilley.  I've missed
the official cutoff for publishing new drafts before Berlin, so please
see

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

for substantial clarifications to the rework of Section 3.6 _Charset
considerations_ given in version -03.

Any existing reviewing work on any _other_ section based on version
-03 is still relevant, as no other section has changed in any
significant way.

Note also accordingly that the diffs in the above -04_diff.html are
still against version -02.

Thanks,

ht

---

From: Ned Freed <[email-masked]>
Date: Sun, 27 Oct 2013 13:40:54 -0700 (PDT)

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

The new charset material looks fine to me.

> still against version -02.

A few additional comments, all fairly minor.

In section 3, there are a couple of places where it says "The media types
application/xml and text/xml MUST NOT be used". Would it make sense to
include the +xml suffix as something that MUST NOT be used?

The material at the end of Section 9.2 is arguably a little too important
to relegate to an example. The obvious place to move it would be to Section
3.2.

Ther probably should be a pointer at the end of Section 3.6 to the examples
in Section 9.

There's a missing period on the last sentence of Section 9.8.

The IANA Considerations in Section 10 need to list the types being registered
here.

That's it!

				Ned

---

From: Julian Reschke <[email-masked]>
Date: Mon, 28 Oct 2013 14:27:28 +0100

> [1] http://tools.ietf.org/html/draft-ietf-appsawg-xml-mediatypes-03#section-3.6

I will probably have to re-read the new document to review what's left 
to do (please post a new draft early next week when ID submission re-opens).

One thing I noticed is that we now have informative references to 
HTTPbis, and normative references to RFC 2616. It should be the other 
way round (so the normative  refs should be updated for HTTPbis, and if 
they can't this might be a problem either in this spec or HTTPbis, in 
which case it needs to be reported ASAP due to IETF LC).

Best regards, Julian