Re: [apps-discuss] Getting 3023bis, a.k.a. draft-ietf-appsawg-xml-mediatypes, moving (Henry S. Thompson) Wed, 01 May 2013 10:13 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id EFD2C21F8C30 for <>; Wed, 1 May 2013 03:13:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -6.599
X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id cgdKQ89mum6G for <>; Wed, 1 May 2013 03:13:27 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 2C85D21F8C08 for <>; Wed, 1 May 2013 03:13:26 -0700 (PDT)
Received: from ( []) by (8.13.8/8.13.4) with ESMTP id r41ADHfG027375; Wed, 1 May 2013 11:13:17 +0100 (BST)
Received: from ( []) by (8.14.4/8.14.4) with ESMTP id r41ADEs0016866; Wed, 1 May 2013 11:13:15 +0100
Received: from (localhost []) by (8.14.4/8.14.4) with ESMTP id r41ADGRk021029; Wed, 1 May 2013 11:13:16 +0100
Received: (from ht@localhost) by (8.14.4/8.14.4/Submit) id r41ADG8H021018; Wed, 1 May 2013 11:13:16 +0100
X-Authentication-Warning: ht set sender to using -f
To: "Rushforth\, Peter" <>
References: <> <>
From: (Henry S. Thompson)
Date: Wed, 01 May 2013 11:13:16 +0100
In-Reply-To: <> (Peter Rushforth's message of "Tue\, 30 Apr 2013 19\:20\:53 +0000")
Message-ID: <>
User-Agent: Gnus/5.101 (Gnus v5.10.10) XEmacs/21.5-b32 (linux)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Edinburgh-Scanned: at with MIMEDefang 2.60, Sophie, Sophos Anti-Virus, Clam AntiVirus
X-Scanned-By: MIMEDefang 2.60 on
Cc: "" <>
Subject: Re: [apps-discuss] Getting 3023bis, a.k.a. draft-ietf-appsawg-xml-mediatypes, moving
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: General discussion of application-layer protocols <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 01 May 2013 10:13:32 -0000

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 :

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

> 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

Thanks for your input,


       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:
 [mail from me _always_ has a .sig like this -- mail without it is forged spam]