IETF Logo Mail Archive

Re: [link-relations] NEW APP DATA

Julian Reschke <julian.reschke@gmx.de> Thu, 15 July 2010 08:14 UTC

Return-Path: <julian.reschke@gmx.de>
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 4C2D73A6897 for <link-relations@core3.amsl.com>; Thu, 15 Jul 2010 01:14:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.855
X-Spam-Level:
X-Spam-Status: No, score=-3.855 tagged_above=-999 required=5 tests=[AWL=-1.256, 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 5lkcmbGc3+is for <link-relations@core3.amsl.com>; Thu, 15 Jul 2010 01:14:05 -0700 (PDT)
Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by core3.amsl.com (Postfix) with SMTP id D1B553A67ED for <link-relations@ietf.org>; Thu, 15 Jul 2010 01:14:04 -0700 (PDT)
Received: (qmail invoked by alias); 15 Jul 2010 08:14:13 -0000
Received: from p508FD8A0.dip.t-dialin.net (EHLO [192.168.178.33]) [80.143.216.160] by mail.gmx.net (mp050) with SMTP; 15 Jul 2010 10:14:13 +0200
X-Authenticated: #1915285
X-Provags-ID: V01U2FsdGVkX19Xl7Nv+K5Xh4xXCDWrXtg4HotaOsHCaG4Y0Ggpsm 5E1O7xUxORDpzm
Message-ID: <4C3EC34C.6070209@gmx.de>
Date: Thu, 15 Jul 2010 10:14:04 +0200
From: Julian Reschke <julian.reschke@gmx.de>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.1.10) Gecko/20100512 Lightning/1.0b1 Thunderbird/3.0.5
MIME-Version: 1.0
To: Ian Hickson <ian@hixie.ch>
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>
In-Reply-To: <Pine.LNX.4.64.1007150746170.24444@ps20323.dreamhostps.com>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
X-Y-GMX-Trusted: 0
Cc: link-relations@ietf.org
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: Thu, 15 Jul 2010 08:14:08 -0000

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

v2.23.0 | Report a Bug | By Email