feedback on ISSUE-27 survey feedback, Re: ISSUE-27: rel-ownership - Straw Poll for Objections

On 17.03.2011 17:36, Paul Cotton wrote:
> ISSUE-27: rel-ownership - Straw Poll for Objections
> ...

In 
<http://www.w3.org/2002/09/wbs/40318/issue-27-objection-poll/results>, 
Tantek writes:

> 1. TLDR. Understanding/use/participation in the registry defined in RFC 5988 is far too difficult, and frankly, inaccessible due to the length and cryptic/technical/jargon wording of http://tools.ietf.org/html/rfc5988

Handwaving. Let's quote <http://tools.ietf.org/html/rfc5988#section-6.2.1>:

6.2.1. Registering New Link Relation Types


    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.

    Note that relation types can be registered by third parties, if the
    Designated Expert determines that an unregistered relation type is
    widely deployed and not likely to be registered in a timely manner.

    The registration template is:

    o  Relation Name:

    o  Description:

    o  Reference:

    o  Notes: [optional]

    o  Application Data: [optional]

    Registration requests should be sent to the link-relations@ietf.org
    mailing list, marked clearly in the subject line (e.g., "NEW RELATION
    - example" to register an "example" relation type).

    Within at most 14 days of the request, the Designated Expert(s) will
    either approve or deny the registration request, communicating this
    decision to the review list and IANA.  Denials should include an
    explanation and, if applicable, suggestions as to how to make the
    request successful.

    Decisions (or lack thereof) made by the Designated Expert can be
    first appealed to Application Area Directors (contactable using
    app-ads@tools.ietf.org email address or directly by looking up their
    email addresses on http://www.iesg.org/ website) and, if the
    appellant is not satisfied with the response, to the full IESG (using
    the iesg@iesg.org mailing list).

    IANA should only accept registry updates from the Designated
    Expert(s), and should direct all requests for registration to the
    review mailing list.

...which is exactly one page of text.

See also the guidance at <http://paramsr.us/link-relation-types/>. (yes, 
that's in the CP).

> 2. Empty promises / hidden work. The Change Proposal uses the phrase "Nothing prevents us ..." and these show holes. Every such encouragement to do something indicates known shortcomings in use of IANA/RFC5988 and some amount of hidden work in order to make this a workable solution.

...which is also the case for other proposals. I also note the 
Microformats Wiki has suddenly acquired new information that wasn't 
around last Thursday.

All of the three proposals/registries can and will be improved once we 
have consensus on where to proceed.

> 3. Misleading / out of touch. The proposal says "requirements for registration are low" - this is misleading or fails to understand the audience for adding rel values. Understanding/following RFC5988 is *not* a low requirement, e.g. see 1. above, rather it is quite onerous and demanding of a high level of technical comprehension and patience, making it inaccessible to perhaps most web authors, many of whom have proposed rel value in microformats.

I disagree that this the case.

In the end, we want both completeness and accuracy. Just because some 
solution makes it easier to add things doesn't mean that the result is 
better (unless you're *only* looking for a way to avoid name collisions).

> 4. Too many steps. The HTML5 editor had difficulty with the number of steps required with RFC5988 rel registrations. There is no documented short list of the steps to take, web form to use, etc.

Yes, there is. It's in both the spec and the help page mentioned above.

The number of steps depends on the registration template; if the only 
concern is to "prove" that the registry doesn't work than of course it's 
possible to prove your point.

Mike Smith (thanks!) retried, and didn't have near as many "problems" as 
Ian.

> 5. No provisional registration. There is no mechanism for simple brainstorm proposal documentation of in-development rel values, e.g. for the purpose of easier discovery for collaborative development and collision avoidance.

You can send an email, and the DEs will be happy to enter the registry 
as "pending" with a pointer to the discussion venue.

> 6. Apparent dependency on email. RFC5988 says "sent to the link-relations@ietf.org mailing list" - email is a primitive tool for this, and given that there are known solutions using wikis, web forms etc. those should be preferred.

This seems to be a matter of taste.

If Wikis and Web Forms are so much better than why is the HTML WG doing 
it's business by email?

> 7. Designated Expert bottleneck. RFC5988 says "the Designated Expert(s) will either approve or deny the registration request" whereas it is much more desirable to simply have any/all attempted registrations be public in some sort of provisional or brainstorm status by default, and only then optionally acted upon by experts.

See above. The registrations *are* public, both because the mailing list 
has a public archive, and because the DEs use a public tracking tool.

> 8. Failure to cite original/active specs. RFC5988 "Initial Registry Contents" lists for example "license" which links to RFC4946 which itself fails to cite the *actual* rel-license specification from which it took a snapshot: http://microformats.org/wiki/rel-license.

This is a result of "license" being included from the Atom registry. I 
agree that we should adjust/synchronize.

> 9. Failure to perform even trivial research/linking. The RFC5988 entry for "payment" says "Notes: this relation type registration did not indicate a reference." Googling "rel payment" returns the microformats draft for rel-payment: http://microformats.org/wiki/rel-payment which should have been referenced by RFC5988. This real world example is indicative of a process/thoroughness breakdown.

No, it just shows that the DEs did not go and questioned existing 
registrations adopted from Atom; I believe back then this was the right 
thing in able to replace the Atom link registry.

See also 8. - if the registration is wrong/incomplete, we should fix it. 
This requires feedback from those "in the know", just like any community 
effort.

Note that there are similar problems in the registry at microformats.org 
-- for instance, I do not see any entry for "describedby".

> 10. Unfriendly to / misleading regarding microformats. The proposal says "a stable document (e.g., a W3C Note, IETF RFC, publication on microformats.org)." and yet NONE of the entries on http://www.iana.org/assignments/link-relations/ reference microformats.org specs/drafts for those rel values which were/are developed and maintained on microformats.org like: license, nofollow, payment, tag.

As far as I can tell, nobody has tried to register these four relations 
with a reference to microformats.org. I hear you saying that this 
shouldn't be needed, but that's a separate discussion. The statement is 
about what's considered a suitable spec, but it still requires 
*somebody* to actually request the registration.

Note that the registrations for "nofollow" and "tag" point to the HTML5 
spec, which *itself* doesn't cite microformats.org. Should the DEs have 
rejected the registration requests?


Best regards, Julian

PS: chairs, please consider this feedback when deciding on ISSUE-27.

Received on Monday, 4 April 2011 21:19:46 UTC