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

"Rushforth, Peter" <Peter.Rushforth@NRCan-RNCan.gc.ca> Wed, 01 May 2013 14:40 UTC

Return-Path: <Peter.Rushforth@NRCan-RNCan.gc.ca>
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8D58C21F9D58 for <apps-discuss@ietfa.amsl.com>; Wed, 1 May 2013 07:40:46 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.599
X-Spam-Level:
X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0AJ97AO7-fvb for <apps-discuss@ietfa.amsl.com>; Wed, 1 May 2013 07:40:41 -0700 (PDT)
Received: from nrcan.gc.ca (s-bsc-edge1.nrcan.gc.ca [132.156.238.13]) by ietfa.amsl.com (Postfix) with ESMTP id 2266421F9D4D for <apps-discuss@ietf.org>; Wed, 1 May 2013 07:40:40 -0700 (PDT)
Received: from S-BSC-CAS2.nrn.nrcan.gc.ca (132.156.238.12) by S-BSC-EDGE1.nrcan.gc.ca (132.156.238.13) with Microsoft SMTP Server (TLS) id 14.2.342.3; Wed, 1 May 2013 10:40:39 -0400
Received: from S-BSC-MBX1.nrn.nrcan.gc.ca ([169.254.1.97]) by S-BSC-CAS2.nrn.nrcan.gc.ca ([fe80::48d4:f168:78ba:d4e8%19]) with mapi id 14.02.0342.003; Wed, 1 May 2013 10:40:38 -0400
From: "Rushforth, Peter" <Peter.Rushforth@NRCan-RNCan.gc.ca>
To: "Henry S. Thompson" <ht@inf.ed.ac.uk>
Thread-Topic: [apps-discuss] Getting 3023bis, a.k.a. draft-ietf-appsawg-xml-mediatypes, moving
Thread-Index: AQHORlR+p5lvmsgOhkKRAnibf94qrZjwR3zw
Date: Wed, 1 May 2013 14:40:38 +0000
Message-ID: <1CD55F04538DEA4F85F3ADF7745464AF249DD068@S-BSC-MBX1.nrn.nrcan.gc.ca>
References: <f5b38u89jiz.fsf@calexico.inf.ed.ac.uk> <1CD55F04538DEA4F85F3ADF7745464AF249DAECA@S-BSC-MBX1.nrn.nrcan.gc.ca> <f5bzjwf57pf.fsf@calexico.inf.ed.ac.uk>
In-Reply-To: <f5bzjwf57pf.fsf@calexico.inf.ed.ac.uk>
Accept-Language: en-CA, en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [132.156.238.22]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: "apps-discuss@ietf.org" <apps-discuss@ietf.org>
Subject: Re: [apps-discuss] Getting 3023bis, a.k.a. draft-ietf-appsawg-xml-mediatypes, moving
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: General discussion of application-layer protocols <apps-discuss.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/apps-discuss>
List-Post: <mailto:apps-discuss@ietf.org>
List-Help: <mailto:apps-discuss-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 01 May 2013 14:40:46 -0000

 

> -----Original Message-----
> From: Henry S. Thompson [mailto:ht@inf.ed.ac.uk] 
> Sent: May 1, 2013 06:13
> To: Rushforth, Peter
> Cc: apps-discuss@ietf.org
> Subject: Re: [apps-discuss] Getting 3023bis, a.k.a. 
> draft-ietf-appsawg-xml-mediatypes, moving
> 
> 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.

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

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