Subject: Re: [apps-discuss] Getting 3023bis, a.k.a. draft-ietf-appsawg-xml-mediatypes, moving

From: [email-masked] (Henry S. Thompson)
Date: Wed, 01 May 2013 11:13:16 +0100

Rushforth, Peter writes:

> Section 8.
>
> Suggest to remove the recommendation to register media types with +xml
> suffix.  Suggest to add recommendation for a 'profile' parameter for application/xml,
> as is being done for atom : http://tools.ietf.org/html/draft-wilde-atom-profile-01

I have to say I'm not inclined to go that way.  There is a _very_
large installed base, particularly of application/xhtml+xml and
application/rdf+xml.  There are around 100 registered
application/xxx+xml media types registered _outside_ the
vnd... sub-space, and another 200 or so there.  We recently spent a
lot of time getting both the general approach to registering
structured suffixes and their uses [1] and using that approach to
clean up / document existing practices [2], including the +xml case.

Introducing an alternative profile-based approach at this point would
just confuse things, IMO.

> Suggest to remove reference to Appendix A.  Remove Appendix A,
> also. All of that stuff is not the business of this RFC, but is the
> responsibility of the registration procedure, in my opinion.

What do people think?  Appendix A [3] is "Why Use the '+xml' Suffix
for XML-Based MIME Types?" and is carried over nearly unchanged from
RFC3023 [4].  Maybe it was needed 12 years ago but is no longer
relevant/necessary/useful?

> Suggest to remove discussion of hypertext linking.  XML does not
> include hypermedia affordances, so there is a disconnect between
> what can be expected in application/xml vs. what is discussed in
> this RFC.  If an XML vocabulary contains XLinks, let that vocabulary
> register its own media type.  Also, relative to the discussion of
> XLinks in that section, the web is not limited to XML documents
> (heck they hardly even exist on the web), so perhaps XLink itself
> needs an update to allow linking to non-XML representations.

This comment regards a list in section 8 "A Naming Convention for
XML-Based Media Types" [5] which is introduced as follows:

  Some areas where 'generic' processing is useful include:

and has among 7 bullet points the following:

  * Browsing - An XML browser can display any XML document with a
    provided [CSS] or [XSLT] style sheet, whatever the vocabulary of
    that document.

  * Hypertext linking - [XLink] hypertext linking is designed to
    connect any XML documents, regardless of vocabulary.

It seems to me these statements are both true, but the second is
indeed weaker, because there are no generic XLink tools as far as I'm
aware, and indeed it's not clear what they would be.  I'm inclined to
replace this with reference to a _different_ link-related standard,
namely XInclude, for which generic support _does_ exist.  Something
along the line of

   * Transclusion - [XInclude] is designed to support transclusion of
     XML or text into arbitrary XML documents, regardless of
     vocabulary.

Thanks for your input,

ht

[1] http://tools.ietf.org/html/rfc6838
[2] http://tools.ietf.org/html/rfc6839
[3] http://tools.ietf.org/html/draft-lilley-xml-mediatypes-00#appendix-A
[4] http://tools.ietf.org/html/rfc3023#appendix-A
[5] http://tools.ietf.org/html/draft-lilley-xml-mediatypes-00#section-8
[XInclude] http://www.w3.org/TR/xinclude/
-- 
       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: "Martin J. Dürst" <[email-masked]>
Date: Wed, 01 May 2013 21:13:36 +0900

> just confuse things, IMO.

I fully agree. The proposal comes *extremely* late and without any 
justification.

> relevant/necessary/useful?

Yes. Please remove Appendix A, then add RFC 3023 as an informational 
reference and point to its Appendix A as "historical reading".

More comments hopefully coming soon.

Regards,   Martin.

---

From: "Rushforth, Peter" <[email-masked]>
Date: Wed, 1 May 2013 14:40:38 +0000

> -----Original Message-----
> From: Henry S. Thompson [mailto:[email-masked]] 
> Sent: May 1, 2013 06:13
> To: Rushforth, Peter
> Cc: [email-masked]
> Subject: Re: [apps-discuss] Getting 3023bis, a.k.a. 
> draft-ietf-appsawg-xml-mediatypes, moving
> 
> Rushforth, Peter writes:
> 
> > Section 8.
> >
> > suffix.  Suggest to add recommendation for a 'profile' 
> parameter for 
> > application/xml, as is being done for atom : 
> > http://tools.ietf.org/html/draft-wilde-atom-profile-01
> 
> I have to say I'm not inclined to go that way.  There is a 
> _very_ large installed base, particularly of 
> application/xhtml+xml and application/rdf+xml.  There are 
> around 100 registered application/xxx+xml media types 
> registered _outside_ the vnd... sub-space, and another 200 or 
> so there.  We recently spent a lot of time getting both the 
> general approach to registering structured suffixes and their 
> uses [1] and using that approach to clean up / document 
> existing practices [2], including the +xml case.
> 
> Introducing an alternative profile-based approach at this 
> point would just confuse things, IMO.

Things are already confused, I think partly because of the +xml convention.

The intent of using any parameter (not just the 'profile' parameter) 
is to expose, without obscuring the type/subtype, while adding additional optional 
identifying characteristics to the media type.  

I think that was actually the intent of the initial registration of the +xml 
convention.  I have used a content negotiation library [1] which
does a nice job of ignoring or recognizing parameters as appropriate,
but doesn't support +suffix in any way.   Web browsers don't
support the +xml convention either, so it seems that although it may
be too late for those media types mentioned above, it is
not too late for future media types to take advantage of standard
facilities.  In the end the mime type string is an identifier, so
it won't hurt those media types above to continue being known as they are
'+xml' and all, but it might be wiser to get future XML media type
registrations off on the right track.

[1] https://groups.google.com/forum/?fromgroups#!forum/mimeparse-dev

> 
> > Suggest to remove reference to Appendix A.  Remove Appendix 
> A, also. 
> > All of that stuff is not the business of this RFC, but is the 
> What do people think?  Appendix A [3] is "Why Use the '+xml' 
> Suffix for XML-Based MIME Types?" and is carried over nearly 
> unchanged from
> RFC3023 [4].  Maybe it was needed 12 years ago but is no 
> longer relevant/necessary/useful?
> 
> > include hypermedia affordances, so there is a disconnect 
> between what 
> > can be expected in application/xml vs. what is discussed in 
> this RFC.  
> > If an XML vocabulary contains XLinks, let that vocabulary 
> register its 
> > own media type.  Also, relative to the discussion of XLinks in that 
> > section, the web is not limited to XML documents (heck they hardly 
> > even exist on the web), so perhaps XLink itself needs an update to 
> > allow linking to non-XML representations.
> 
> This comment regards a list in section 8 "A Naming Convention 
> for XML-Based Media Types" [5] which is introduced as follows:
> 
> It seems to me these statements are both true, but the second 
> is indeed weaker, because there are no generic XLink tools as 
> far as I'm aware, and indeed it's not clear what they would 
> be.  I'm inclined to replace this with reference to a 
> _different_ link-related standard, namely XInclude, for which 
> generic support _does_ exist.  Something along the line of
> 

Actually, my main point is that application/xml does not imply any of
this processing, unless the registration for that media type (which is
the subject of this draft, right?)  explicitly
calls out the applicable specifications as being implied.  I don't
*think* that is the intention of the registration.  I *think* that 
application/xml is intended to imply is what the least common denominator of
what can be considered to be xml.  So, for example, namespaces are not in scope.
Nor is XLink, XInclude, <?xml-stylesheet?> etc etc etc.

What is left?  Very very limited application semantics, if I understand the
intent of XML i.e. perhaps only what is implied by the proverbial "XML Processor".

Regards,
Peter Rushforth

---

From: Ned Freed <[email-masked]>
Date: Wed, 01 May 2013 13:44:47 -0700 (PDT)

> just confuse things, IMO.

I strongly agree. We're currently seeing a large number of registrations
coming in and momentum seems to be building. The absolute last thing we should
be doing is making changes that break that. We have seen the effect of such
changes in the past; it was not good.

				Ned

---

From: "Martin J. Dürst" <[email-masked]>
Date: Fri, 17 May 2013 19:59:12 +0900

I have finally completed a full review of 
draft-ietf-appsawg-xml-mediatypes-00. Here are my findings:

Technically, this document is in good shape. It describes actual 
practice that's widely established.

But I'm sorry to say that this document is pretty much unreadable, in 
particular for those who we want to read it. The reason for this is that 
it contains a huge amount of historical ballast and (for most readers) 
unnecessary justifications.

I think it should not be too difficult to remedy this problem, and it 
will help the average reader, which which I mean somebody who wants to 
publish or consume an XML document, or define a Mime type with a +xml 
suffix.

I'll try to point out the main changes that I'd start with below; I may 
be able to give more help, but next week looks busy.

> More comments hopefully coming soon.

Removing the current Appendix A and pointing to it in RFC 3023 is the 
first and biggest step. I didn't realize this, but currently, RFC 3023 
is listed as normative, which is really strange.

Next, let's start from the start. The abstract says:

                                                         XML MIME
    entities are currently exchanged via the HyperText Transfer Protocol
    on the World Wide Web, are an integral part of the WebDAV protocol
    for remote web authoring, and are expected to have utility in many
    domains.

This sounds like text from 1997 (XML was finalized in 1998). I don't 
think there is any need in this document to explain how widely XML is used.

In the Intro, paragraphs can either be shortened or just removed. In 
particular, the paragraphs starting with "Although XML is a subset of 
the Standard Generalized Markup Language" and "Since XML is an integral 
part of the WebDAV Distributed Authoring Protocol" can just be cut. 
These were important for RFC 3023, in order to convince people who might 
not have heard about XML, or may not have known that the IETF was 
already using XML (in WebDAV), or confused it with SGML, but these days, 
that's not a problem at all.

In section 3 (XML Media Types), a lot of work is needed to disentangle 
what readers need to know (think about readers in 5 or 10 years) on the 
one hand, and rationale and historical background on the other hand 
(which becomes less and less important when moving to the future). The 
paragraph starting with "Within the XML specification", for example, 
several times switches between actual spec text (MAY/MUST/...) and notes.

Section 3.1, application/xml Registration: The text about the optional 
charset parameter is way too long to stay in this registration, and is 
referenced from many other places. I'd separate it out into a separate 
section, and just put a pointer to that section from the template. 
Again, as elsewhere, sort out the normative stuff from the 
rationale/history.

Section 3.6: A Summary is a good idea in a descriptive text, but putting 
additional MUSTs there is a bad idea. This probably just shows that the 
text up to here wasn't able to capture some essentials, which should be 
fixed at the source, not cleaned up afterwards with a summary.

Section 8: Same problems all over again. There is a lot of justification 
for why "+xml" may be needed. This may have been appropriate when the 
idea of a +xml suffix was first introduced, but that was 10 or more 
years ago.

8.1: It would be great if this document provided a template for +xml 
registrations, with the usual pointers already filled in (and lots of 
[add/change as appropriate] or so notices).

Similar problems in the security section, for example this piece of text:
    Use of XML is expected to be varied, and widespread.  XML is under
    scrutiny by a wide range of communities for use as a common syntax
    for community-specific metadata.
That was 10 or 15 years ago. Please let's rewrite this.

I have more comments on details, but I first wanted to get out this 
appeal for a general rewrite to move away from a historic/justificatory 
writing style to a simple and short spec that answers the direct 
questions of readers and stays readable in the future. I'm happy to 
contribute if help is needed.

Regards,   Martin.

---

From: "Rushforth, Peter" <[email-masked]>
Date: Thu, 23 May 2013 12:23:37 +0000

Ned,

Leaving registration considerations aside for a moment, if I want to 
create a media type which is more specific than application/xml 
for my application, is it better to use 

application/xml;profile="urn:my.app" 
or 
application/vnd.my.app+xml ?

Because this library https://code.google.com/p/mimeparse/, available in
8 programming languages, supports parsing the former as XML, but not the
latter.  I haven't really looked at other libraries, but I think I may
have landed on that one because the implementation of MIME in java did 
not manage negotiation concerns (I don't remember).

Also, browsers (that I have used anyway) will parse the former as XML, 
but not the latter.  Same for html, which is potentially quite useful, IMHO.

Are there libraries available which support parsing application/vnd.my.app+xml
as XML?  I don't think there's anything wrong with this notation, since it does
identify the media type semantics, but it doesn't give me fallback behaviour
at least in any running code I've seen.

Thanks
Peter Rushforth

> From: Ned Freed [mailto:[email-masked]] 
> Sent: May 1, 2013 16:45
> To: [email-masked]
> Cc: Rushforth, Peter; [email-masked]
> > > Suggest to remove the recommendation to register media types with 
> > > +xml suffix.  Suggest to add recommendation for a 'profile' 
> > > parameter for application/xml, as is being done for atom : 
> > application/xxx+xml media types registered _outside_ the vnd... 
> > sub-space, and another 200 or so there.  We recently spent a lot of 
> > time getting both the general approach to registering structured 
> > suffixes and their uses [1] and using that approach to clean up / 
> > document existing practices [2], including the +xml case.
> 
> I strongly agree. We're currently seeing a large number of 
> registrations coming in and momentum seems to be building. 
> The absolute last thing we should be doing is making changes 
> that break that. We have seen the effect of such changes in 
> the past; it was not good.
> 
> 				Ned
>

---

From: Ned Freed <[email-masked]>
Date: Thu, 23 May 2013 09:41:03 -0700 (PDT)

> application/vnd.my.app+xml ?

The latter, unquestionably.

> latter.

Sorry, one library demonstates diddley-sqaut. And while it's nice to support
default handling of entities as XML, it's hardly a requirement.

What is a requirement is the ability to have different handling for different
types of entities. And MIME dispatch capabilities are invariably capable of
operating on the conent type. This is the case in hundreds if not thousands of
different pieces of code. So having a proper type label gives you the ability
to process different sorts of entities differently.

It's also true that a some of them support dispatching on parameter values.
But definitely not all. In fact I'd go so far as to say that most do not.

And yes, most don't support default handling of media type suffixes either. But
that's hardly surprising given they were properly standardized less than a year
ago.

>  I haven't really looked at other libraries, but I think I may

> but not the latter.  Same for html, which is potentially quite useful, IMHO.

Again, the ability to be able to default to parsing XML is a nice to have
feature. Nothing more. I'll also note that the rules for content type
definitiions are very clear that the type and subtype are what you register as
specifying the sort of entity you'r dealing with. As such, absent a willingness
to reopen the recently revised rules for how type registration work, which I
very much doubt is on the table, your proposal here is a total nonstarter.

				Ned