Re: [apps-discuss] I-D Action: draft-ietf-appsawg-media-type-suffix-regs-00.txt

ht@inf.ed.ac.uk (Henry S. Thompson) Thu, 17 May 2012 17:42 UTC

Return-Path: <ht@inf.ed.ac.uk>
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 3D91721F86AB; Thu, 17 May 2012 10:42:53 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.578
X-Spam-Level:
X-Spam-Status: No, score=-6.578 tagged_above=-999 required=5 tests=[AWL=0.021, 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 ajwyB2wwKADE; Thu, 17 May 2012 10:42:52 -0700 (PDT)
Received: from nougat.ucs.ed.ac.uk (nougat.ucs.ed.ac.uk [129.215.13.205]) by ietfa.amsl.com (Postfix) with ESMTP id 16FA221F869F; Thu, 17 May 2012 10:42:51 -0700 (PDT)
Received: from nutty.inf.ed.ac.uk (nutty.inf.ed.ac.uk [129.215.33.33]) by nougat.ucs.ed.ac.uk (8.13.8/8.13.4) with ESMTP id q4HHgZ1b009433; Thu, 17 May 2012 18:42:40 +0100 (BST)
Received: from calexico.inf.ed.ac.uk (calexico.inf.ed.ac.uk [129.215.24.15]) by nutty.inf.ed.ac.uk (8.13.8/8.13.8) with ESMTP id q4HHgZkC008155; Thu, 17 May 2012 18:42:35 +0100
Received: from calexico.inf.ed.ac.uk (localhost [127.0.0.1]) by calexico.inf.ed.ac.uk (8.14.4/8.14.4) with ESMTP id q4HHgZIH027810; Thu, 17 May 2012 18:42:35 +0100
Received: (from ht@localhost) by calexico.inf.ed.ac.uk (8.14.4/8.14.4/Submit) id q4HHgYgl027806; Thu, 17 May 2012 18:42:34 +0100
X-Authentication-Warning: calexico.inf.ed.ac.uk: ht set sender to ht@inf.ed.ac.uk using -f
To: internet-drafts@ietf.org
References: <20120426131912.32053.74050.idtracker@ietfa.amsl.com>
From: ht@inf.ed.ac.uk
Date: Thu, 17 May 2012 18:42:34 +0100
In-Reply-To: <20120426131912.32053.74050.idtracker@ietfa.amsl.com> (internet-drafts@ietf.org's message of "Thu, 26 Apr 2012 06:19:12 -0700")
Message-ID: <f5bmx56hfg5.fsf@calexico.inf.ed.ac.uk>
User-Agent: Gnus/5.1008 (Gnus v5.10.8) XEmacs/21.4.21 (linux)
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
X-Edinburgh-Scanned: at nougat.ucs.ed.ac.uk with MIMEDefang 2.60, Sophie, Sophos Anti-Virus, Clam AntiVirus
X-Scanned-By: MIMEDefang 2.60 on 129.215.13.205
Cc: apps-discuss@ietf.org, i-d-announce@ietf.org
Subject: Re: [apps-discuss] I-D Action: draft-ietf-appsawg-media-type-suffix-regs-00.txt
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: Thu, 17 May 2012 17:42:53 -0000

Further also to the recent review.

With my informal W3C TAG and XML Core WG hats on, I want to flag again
our concern about section 8:

8.  IANA Considerations

   See the Message Type Structured Syntax Suffix registration forms in
   Section 3 - Section 7.

   The existing Structured Syntax Suffix registration for "+xml"
   should be modified to include the following

   Fragment identifier considerations Media types using "+xml" SHOULD
                       process any fragment identifiers defined for
                       "application/xml" in the same way as defined
                       for that media type.  (At publication of this
                       document, the fragment identification syntax
                       considerations for "application/xml" are
                       defined in [RFC3023].) Specific media types
                       using "+xml" MAY identify additional fragment
                       identifier considerations, MAY define
                       processing for fragment identifiers that are
                       classed as errors for "application/xml" and MAY
                       designate fragment identifiers defined for
                       "application/xml" that SHOULD NOT be used.

RFC3023 does not, in fact, embarassingly, define a fragment
identifier syntax for application/xml documents, so this paragraph is
at best misleading.

Also, it's perhaps inappropriate to attempt to override-at-a-distance in
this way, given that this document obviously will not be documented as
superseding 3023.

The overall intent of this is clearly a Good Thing, but the timing is
tricky. . .

I will try to get some concrete information about the chances of a
getting a draft RFC intended to replace 3023 as a matter of urgency.

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: ht@inf.ed.ac.uk
                       URL: http://www.ltg.ed.ac.uk/~ht/
 [mail from me _always_ has a .sig like this -- mail without it is forged spam]