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

From: [email-masked]
Date: Mon, 08 Jul 2013 05:15:58 -0700

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)       : Chris Lilley
                          MURATA Makoto
                          Alexey Melnikov
                          Henry S. Thompson
	Filename        : draft-ietf-appsawg-xml-mediatypes-02.txt
	Pages           : 27
	Date            : 2013-07-08

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

   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.

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

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

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

---

From: [email-masked] (Henry S. Thompson)
Date: Mon, 08 Jul 2013 13:25:45 +0100

>  This draft is a work item of the Applications Area Working Group Working Group of the IETF.

A brief Disposition of Comments is available at

  http://localhost/ht/WWW/XML/2012/10/3023bis/01-comments.html

A clean diff from -01 is available at

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

The big changes are a substantial shrinking and re-structuring of the
Examples section, and the incorporation of a 6838-style registration
of the '+xml' suffix, intended to update the one in 6839.

I hope we're getting close to a final version here -- I'd welcome
discussion at the upcoming F2F (although I can't be there :-(.

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: Erik Wilde <[email-masked]>
Date: Mon, 08 Jul 2013 14:26:59 +0200

hello.

>     when those media types represent XML MIME entities.

maybe this is simply out of scope, but since i recently noticed that XSD 
never got around to defining its own media type: what about including a 
registration for XSD in this draft? DTDs are covered, RNG has its own 
types, and it would be useful in general if XSD had a well-defined media 
type as well.

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: Bjoern Hoehrmann <[email-masked]>
Date: Mon, 08 Jul 2013 16:11:08 +0200

>  http://localhost/ht/WWW/XML/2012/10/3023bis/01-comments.html

You mean <http://www.w3.org//XML/2012/10/3023bis/01-comments.html>.
I note that the document fails to declare that it's UTF-8 encoded.

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

I note it says "Updates: 4289" but does not reference RFC 4289 anywhere.
It seems odd that UTF-16 is a normative reference but UTF-8 is not. The
UTF-16 reference should probably be non-normative.
-- 
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: Bjoern Hoehrmann <[email-masked]>
Date: Mon, 08 Jul 2013 16:14:22 +0200

>types, and it would be useful in general if XSD had a well-defined media 

People are welcome to register types as they see fit, but there is no
reason to piggyback unrelated types in this specification.
-- 
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: [email-masked] (Henry S. Thompson)
Date: Mon, 08 Jul 2013 16:06:36 +0100

Bjoern Hoehrmann writes:

>>...

Oops -- thanks!

> I note that the document fails to declare that it's UTF-8 encoded.

Fixed.

> I note it says "Updates: 4289" but does not reference RFC 4289 anywhere.

Ah, another orphan.  Thanks, I'll get rid of that, and the entry in
the Informative References section.

> UTF-16 reference should probably be non-normative.

This could go either way.  I judged that this sentence:

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

amounted to a normative appeal to RFC2781, but that there was nothing
like that for ISO-8859 (or ASCII).   But I don't feel strongly about
this either way --- anyone else?

ht

---

From: Bjoern Hoehrmann <[email-masked]>
Date: Mon, 08 Jul 2013 17:32:45 +0200

>this either way --- anyone else?

The RFC 2119 keywords should only be used when removing them would also
remove a requirement. That does not seem to be the case in this text, it
just recites a requirement spelled out in RFC 2781. So this should not
be a "MUST NOT" (make it lowercase or replace with cannot or "is not
usable" or something).
-- 
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: Tony Hansen <[email-masked]>
Date: Mon, 08 Jul 2013 12:06:20 -0400

On 7/8/2013 11:32 AM, Bjoern Hoehrmann wrote:
> The RFC 2119 keywords should only be used when removing them would
> also remove a requirement. That does not seem to be the case in this
> text, it just recites a requirement spelled out in RFC 2781. So this
> should not be a "MUST NOT" (make it lowercase or replace with cannot
> or "is not usable" or something). 

Just a nit: Making it lowercase does not remove its 2119 meaning.

    Tony Hansen

---

From: Barry Leiba <[email-masked]>
Date: Mon, 8 Jul 2013 15:18:08 -0400

> Just a nit: Making it lowercase does not remove its 2119 meaning.

Just a nit: That's not what at least a good portion of the sitting ADs think.

Barry

---

From: SM <[email-masked]>
Date: Tue, 09 Jul 2013 00:31:15 -0700

Hi Bjoern,
>be a "MUST NOT" (make it lowercase or replace with cannot or "is not

The "MUST NOT" could be changed to lower case as it describes a 
requirement from RFC 2781.  The reference would still be normative.

Regards,
-sm