W3C home > Mailing lists > Public > public-html@w3.org > November 2010

ACTION-127 (IANA rel regs that are currently deferred)

From: Julian Reschke <julian.reschke@gmx.de>
Date: Fri, 19 Nov 2010 14:27:15 +0100
Message-ID: <4CE67B33.7050509@gmx.de>
To: "public-html@w3.org" <public-html@w3.org>
Hi,

during TPAC, the question was asked why the IANA Designated Experts do 
not simply register relations that aren't "finished" yet, and update 
when appropriate (see 
<http://www.w3.org/2010/11/04-html-wg2-minutes.html#action04> and 
<http://www.w3.org/html/wg/tracker/issues/127>).

The answer below is with my Designated Expert hat on (but I haven't 
really consulted with the other designated experts yet).

First of all, it's not totally clear why it does matter. The Designated 
Experts run an issue tracker, so as soon as a registration request is 
received and has not been rejected, the link relation name essentially 
is reserved.

See <http://paramsr.us/tracker/>...

Of the registration requests from this WG, currently eight haven't been 
registered yet, for various reasons:

1) first, index, last, up: there's a related open WG issue 
(<http://www.w3.org/html/wg/tracker/issues/118>), and a change Proposal 
on the table to drop those 
(<http://lists.w3.org/Archives/Public/public-html/2010Nov/0042.html>)

2) external, sidebar, tag: the descriptions of these relation types 
either are totally vague or do not seem to reflect reality (there are 
various open bugs about those).

3) pingback: this actually is a link relation defined somewhere else, 
and the Designated Expert wasn't convinced that the reference satisfies 
the registration requirement (*).

Best regards, Julian

(*) See 
<http://greenbytes.de/tech/webdav/rfc5988.html#rfc.section.6.2.1>, 
referencing <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].
Received on Friday, 19 November 2010 13:34:43 UTC

This archive was generated by hypermail 2.3.1 : Thursday, 29 October 2015 10:16:07 UTC