[apps-discuss] IANA hanges to draft-nottingham-http-link-header

Mark Nottingham <mnot@mnot.net> Thu, 23 September 2010 04:25 UTC

Return-Path: <mnot@mnot.net>
X-Original-To: apps-discuss@core3.amsl.com
Delivered-To: apps-discuss@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 19EC13A6A9A for <apps-discuss@core3.amsl.com>; Wed, 22 Sep 2010 21:25:23 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -104.69
X-Spam-Level:
X-Spam-Status: No, score=-104.69 tagged_above=-999 required=5 tests=[AWL=-2.991, BAYES_00=-2.599, GB_I_LETTER=-2, J_CHICKENPOX_44=0.6, MANGLED_MEDS=2.3, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PTXwyFLQxRE5 for <apps-discuss@core3.amsl.com>; Wed, 22 Sep 2010 21:25:19 -0700 (PDT)
Received: from mxout-07.mxes.net (mxout-07.mxes.net [216.86.168.182]) by core3.amsl.com (Postfix) with ESMTP id 7C77C3A69C5 for <discuss@apps.ietf.org>; Wed, 22 Sep 2010 21:25:17 -0700 (PDT)
Received: from chancetrain-lm.mnot.net (unknown [118.209.171.160]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id 2ADE322E1F4; Thu, 23 Sep 2010 00:25:38 -0400 (EDT)
From: Mark Nottingham <mnot@mnot.net>
Content-Type: multipart/mixed; boundary=Apple-Mail-17--181425568
Date: Thu, 23 Sep 2010 14:25:35 +1000
Message-Id: <D92B699E-32AA-4CD8-94B8-469296A4D48B@mnot.net>
To: HTTP Working Group <ietf-http-wg@w3.org>, Apps Discuss <discuss@apps.ietf.org>, Atom-Syntax Syntax <atom-syntax@imc.org>
Mime-Version: 1.0 (Apple Message framework v1081)
X-Mailer: Apple Mail (2.1081)
Subject: [apps-discuss] IANA hanges to draft-nottingham-http-link-header
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: General discussion of application-layer protocols <apps-discuss.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/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, 23 Sep 2010 04:25:23 -0000

Draft-nottingham-http-link-header <https://datatracker.ietf.org/doc/draft-nottingham-http-link-header/> has been the AUTH48 state for a few weeks, pending resolution of some issues with IANA.

It turns out that the text specifying interactions between the Designated Experts and IANA was too constraining; furthermore, the specification of a one-off registry XML format doesn't work well with IANA's toolchain for managing registries.

As a result, I'm proposing removal of some text, as part of the AUTH48 process. Alexey (the responsible AD) has asked me to communicate this to the various stakeholder communities for feedback.

I've attached the proposed RFC, with a diff available at <http://www.mnot.net/test/link-diff.html>. Note that the diff also incorporates editorial changes from the RFC Editor. 

The changes under discussion here are:

1) Removal of the following paragraph from section 6.2.1, "Registering Link Relation Types":

   When a registration request is successful, the Designated Expert(s)	 		
   will update the registry XML file (using the format described in	 		
   Appendix A including the MIT license) and send it to the [TBD-2]@	 		
   ietf.org mailing list (which SHOULD NOT be centrally archived, so as	 		
   to avoid load issues from automated agents, and only accept posts	 		
   from the Designated Expert(s)), so that implementers interested in	 		
   receiving a machine-readable registry can do so.  Simultaneously,	 		
   they will send a text (not XML) version of the registry to IANA for	 		
   publication.	 		

2) Removal of Appendix A in its entirety. 

Instead, the Designated Experts will inform IANA of new entries, and they will be produced and published as normal on the IANA Web site. I.e., they will be available in text, HTML and XML -- the latter using the same format as other registries (for an example, see <http://www.iana.org/assignments/aaa-parameters/aaa-parameters.xml>). 

3) Adding the following to the beginning of section 6.2, "Link Relation Type Registry":

   The underlying registry data (e.g., the XML file) must include
   Simplified BSD License text as described in Section 4.e of the Trust
   Legal Provisions (<http://trustee.ietf.org/license-info>).

One open question is the issue of whether an announcement list is still necessary, since the registry data will be available from the Web site. However, this does not necessarily need to be specified in the RFC itself; the registry page can advertise the list if people would like one.

Feedback appreciated; Alexey will be able to use that as input to the next steps.

Regards,


--
Mark Nottingham     http://www.mnot.net/