IETF Logo Mail Archive

Re: [link-relations] NEW APP DATA

Ian Hickson <ian@hixie.ch> Wed, 21 July 2010 21:03 UTC

Return-Path: <ian@hixie.ch>
X-Original-To: link-relations@core3.amsl.com
Delivered-To: link-relations@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B691E3A6B78 for <link-relations@core3.amsl.com>; Wed, 21 Jul 2010 14:03:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.373
X-Spam-Level:
X-Spam-Status: No, score=-2.373 tagged_above=-999 required=5 tests=[AWL=0.226, BAYES_00=-2.599]
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 j33W10ADwpfc for <link-relations@core3.amsl.com>; Wed, 21 Jul 2010 14:03:38 -0700 (PDT)
Received: from looneymail-a1.g.dreamhost.com (caibbdcaaaaf.dreamhost.com [208.113.200.5]) by core3.amsl.com (Postfix) with ESMTP id 68C2A3A6BBE for <link-relations@ietf.org>; Wed, 21 Jul 2010 14:03:37 -0700 (PDT)
Received: from ps20323.dreamhostps.com (ps20323.dreamhost.com [69.163.222.251]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by looneymail-a1.g.dreamhost.com (Postfix) with ESMTP id A292215D577 for <link-relations@ietf.org>; Wed, 21 Jul 2010 14:03:52 -0700 (PDT)
Date: Wed, 21 Jul 2010 21:03:52 +0000
From: Ian Hickson <ian@hixie.ch>
To: link-relations@ietf.org
In-Reply-To: <4C3EC34C.6070209@gmx.de>
Message-ID: <Pine.LNX.4.64.1007212057560.24444@ps20323.dreamhostps.com>
References: <Pine.LNX.4.64.1007142313280.24444@ps20323.dreamhostps.com> <75A9B632-BED0-41C6-8042-EF93E7146235@mnot.net> <Pine.LNX.4.64.1007150746170.24444@ps20323.dreamhostps.com> <4C3EC34C.6070209@gmx.de>
Content-Language: en-GB-hixie
Content-Style-Type: text/css
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset="US-ASCII"
Subject: Re: [link-relations] NEW APP DATA
X-BeenThere: link-relations@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: <link-relations.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/link-relations>, <mailto:link-relations-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/link-relations>
List-Post: <mailto:link-relations@ietf.org>
List-Help: <mailto:link-relations-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/link-relations>, <mailto:link-relations-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 21 Jul 2010 21:03:42 -0000

On Thu, 15 Jul 2010, Julian Reschke wrote:
> On 15.07.2010 09:54, Ian Hickson wrote:
> > ...
> > The registration process doesn't mention a specification requirement, so
> > I'm not sure exactly what to provide here.
> 
> <http://greenbytes.de/tech/webdav/draft-nottingham-http-link-header-10.html#rfc.section.6.3>:
> 
>    Application data is registered on the advice of a Designated Expert
>    (appointed by the IESG or their delegate), with a Specification
>    Required (using terminology from [RFC5226]).
> 
> <http://tools.ietf.org/html/rfc5226#section-4.1>:
> 
>       Specification Required - Values and their meanings must be
>             documented in a permanent and readily available public
>             specification, in sufficient detail so that interoperability
>             between independent implementations is possible.  When used,
>             Specification Required also implies use of a Designated
>             Expert, who will review the public specification and
>             evaluate whether it is sufficiently clear to allow
>             interoperable implementations.  The intention behind
>             "permanent and readily available" is that a document can
>             reasonably be expected to be findable and retrievable long
>             after IANA assignment of the requested value.  Publication
>             of an RFC is an ideal means of achieving this requirement,
>             but Specification Required is intended to also cover the
>             case of a document published outside of the RFC path.  For
>             RFC publication, the normal RFC review process is expected
>             to provide the necessary review for interoperability, though
>             the Designated Expert may be a particularly well-qualified
>             person to perform such a review.
> 
>             Examples: Diffserv-aware TE Bandwidth Constraints Model
>             Identifiers [RFC4124], TLS ClientCertificateType Identifiers
>             [RFC4346], ROHC Profile Identifiers [RFC4995].

It's not clear to me if the quotes above were intended to answer my 
question or were just helpful background, but since no other reply has 
been forthcoming, I should reiterate that I have no idea what is needed as 
part of the registration of fields in terms of a specification.

Would an equivalent of this section but for this registry be suitable?:

   http://www.whatwg.org/specs/web-apps/current-work/complete.html#other-link-types

Any help would be most welcome. I thought I had completed the template as 
described in the "Link Relation Application Data Registry" section.

-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'

v2.23.0 | Report a Bug | By Email