ISSUE-27, was: Report on testing of the link relations registry

On 16.08.2010 10:55, Anne van Kesteren wrote:
> On Mon, 16 Aug 2010 10:50:57 +0200, Julian Reschke
> <julian.reschke@gmx.de> wrote:
>> As far as I can tell, the simplest approach is to write an Internet
>> Draft and submit it to the RFC Editor for publication as Informational
>> RFC. (*)
>>
>> BR, Julian
>>
>> (*) Anyone interested: I'll be more than happy to help with the
>> mechanics. Also: I'd do it myself if I had an interesting relation to
>> register, and also it wouldn't make sense if I did the testing of the
>> registry because of the other hat I'm wearing.
>
> If this is indeed what is required I tend to agree with Ian that the
> registry -- like many IANA registries unfortunately -- will be somewhat
> unhelpful in practice and not match reality.

I did not say that it is required. I just stated what I think is the 
easiest approach, and it would be interesting to understand why you 
think this barrier is high by any means.

For the record, what the spec says is:

>    Relation types are registered on the advice of a Designated Expert
>    (appointed by the IESG or their delegate), with a Specification
>    Required (using terminology from [RFC5226]).
>
>    The requirements for registered relation types are described in
>    Section 4.1.
>
>    Registration requests consist of the completed registration template
>    below, typically published in an RFC or Open Standard (in the sense
>    described by [RFC2026], Section 7).  However, to allow for the
>    allocation of values prior to publication, the Designated Expert may
>    approve registration once they are satisfied that a specification
>    will be published.

(<http://tools.ietf.org/html/draft-nottingham-http-link-header-10#section-6.2.1>)

"Specification Required" is defined in RFC 5226 as:
>       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].

(<http://tools.ietf.org/html/rfc5226#section-4.1>).

Best regards, Julian

Received on Monday, 16 August 2010 09:03:37 UTC