Report on testing of the link relations registry

INTENT OF TEST

My goal in this exercise was to determine whether the Web Linking
specification's IANA Link Relations Registry would be suitable for use
in HTML, in particular whether it could supplant the current Wiki
placeholder. Of particular concern were whether the W3C and WHATWG
would be able to use the registry to document real-world use of the
rel="" attribute in HTML, and whether third parties could register
keywords that they invent and use, so as to avoid potential clashes
with multiple simultaneous inventions.


TEST DIARY

Not knowing off-hand how to registry a new rel value, I searched
Google for "rel registry". This returned a number of results, in
particular:

   http://www.iana.org/assignments/link-relations.html

   http://wiki.whatwg.org/wiki/RelExtensions

The second one was a wiki, to which it was trivial to add a rel value.
However, it was not the rel registry in question.

The first was a plain text file (the ".html" file redirects to it). I
couldn't find any link to a form or anything to register a new
relation or a new field. There was a reference to
"RFC-nottingham-http-link-header-10", but no link.

I tried Googling "RFC-nottingham-http-link-header-10". This led me to:

   https://datatracker.ietf.org/doc/draft-nottingham-http-link-header/

This is a 27 page document. A quick glance at the table of contents
was unhelpful, but a scan through the document revealed section
"6.2.1. Registering new Link Relation Types", which for some reason is
not in the table of contents.

I decided to try to register the first keyword in the HTML5 spec. It
is already in the registry, but with a much less detailed definition
(referencing HTML4). It also requires new fields to be properly
registered, so the first step is to register new fields.

The first fields I decided to try to register were whether the keyword
was allowed on a and area, and whether the keyword was allowed on
link. So I went back to the IETF page referenced above, and looked for
a section for registering new fields. The closest I found from a quick
scan was "6.2.1. Registering new Link Relation Types". This section
says to fill in the following template:

 o Application Name:
 o Description:
 o Default Value:
 o Notes: [optional]

...and to send it to "[TBD]@ietf.org" with the subject line "NEW APP
DATA".

Here are the completed templates I wrote, based on a quick reading of
the section cited above:

 o Application Name: HTML
 o Description: Allowed on <a> and <area>?
 o Default Value: No
 o Notes: The following values should have "Yes" for this field:
     alternate, appendix, bookmark, chapter, contents, copyright,
     first, glossary, help, index, first [sic - it's listed
     twice?], last, license, next, prev, previous, section, start,
     subsection, up

 o Application Name: HTML
 o Description: Allowed on <link>?
 o Default Value: No
 o Notes: The following values should have "Yes" for this field:
     alternate, appendix, chapter, contents, copyright, first,
     glossary, help, index, first [sic - it's listed twice?], last,
     license, next, prev, previous, section, start, subsection, up

>From out-of-band information I happened to learn that the actual
e-mail address was "link-relations@ietf.org", so I mailed the two
templates above in an e-mail to that list with the subject line "NEW
APP DATA" as suggested by the IETF document. [1]

I received a reply promptly. The reply asked for a specification. [2] It
was unclear what the specification was supposed to say, so I asked for
further clarifications. [3]

Around this time I also got an e-mail asking for an explanation of why
we would have flags defining per-element conformance for link
relations. [4] I did not realise this was a formal reply to the
registration (since it was from a different responder than the first
e-mail), and did not reply. (I did eventually reply to these questions
later on.) This same responder then also replied to my request for
clarifications, by quoting parts of the specification, but not
answering the question. [5]

After a few days, I had still not received an answer to the question,
so I asked it again. [6] A brief exchange resulted. I learnt that the
registration process actually required more than the template quoted
above, it also required a specification. Although I asked for help, I
wasn't told what this specification should define. [7][8][9]

After an interval with no further information forthcoming, I tried
writing a specification:

   http://html5.org/tools/web-apps-tracker?from=5248&to=5249

I then rewrote the registration templates as follows and tried sending
them again: [10]

 o Application Name: HTML
 o Description: Effect on a and area elements
 o Default Value: Not allowed
 o Notes: The following values should have "Hyperlink" for this
     field: alternate, appendix, bookmark, chapter, contents,
     copyright, first, glossary, help, index, first, last, license,
     next, prev, previous, section, start, subsection, up.
 o Specification: http://www.whatwg.org/specs/web-apps/current-work/complete.html#iana-registry

 o Application Name: HTML
 o Description: Effect on link elements
 o Default Value: Not allowed
 o Notes: The following values should have "Hyperlink" for this
     field: alternate, appendix, chapter, contents, copyright,
     first, glossary, help, index, first, last, license, next,
     prev, previous, section, start, subsection, up. The following
     values should have "External Resource Link" for this field:
     stylesheet.
 o Specification: http://www.whatwg.org/specs/web-apps/current-work/complete.html#iana-registry

I received a reply repeating the earlier query regarding these
proposals to which I had not replied, which I attempted to respond to.
[11][12] It was unclear, at first, whether the registration of the
fields was predicated on getting the responder to understand the
issues at hand.

The conversation with the responder continued with him explaining that
he was unconvinced that the registrations were suitable. For a long
time it continued to be unclear whether any of this actually blocked
registration, but eventually it became clear that in order to register
these fields, I would have to convince one of three people that they
are suitable. [13][14][15][16] (I don't know who the third person is;
to date I have only received responses regarding the registrations
from two people.)

One thing that came out during this discussion was the possibility
that link relations would be rejected if they were HTML-specific. [17]
For example, something specific to HTML cache manifests would likely
not be able to be used as a <link rel> value since it wouldn't work in
Atom. This is apparently a risk even if the value is already
well-established /de facto/, meaning the registry could in fact by
design fail to match deployed content.

The conversation shifted to suggesting that the HTML specification
should not use the registry to maintain information about link
relations as they apply to HTML. Since this would apparently mean that
people who wanted to use link relations with HTML would have to
register their relations twice -- once with IANA, and once with
whatever other registry mechanism HTML has, this seemed highly
suboptimal. [18] I tried to ask for clarifications, but that just led
to even more confusing responses, e.g. first referring to keywords
that weren't part of the registration, then later referring to the
Link: header for reasosn that are still unclear to me. The responder
suggested that one of the aspects of the registration (the conformance
of values in HTML for authors) should simply not be registered, and
suggested that no distinction should be made at all in another case
(whether values are valid on <link> vs <a>). This would be
incompatible with how the Web works (e.g. rel=stylesheet is only
supported on <link> and Link:, not <a>), but this argument was
dismissed with the assertion that that did not matter. [19][20][21]
[22][23][24][25][26][27]

Near the end of this exchange I gave up trying to register the fields,
concluding that we'd just have to have a parallel registry for the
HTML-specific aspects of each keyword, which would have as a
prerequisite that the keyword be registered with the IANA registry.
Since the HTTP Link: header is defined in terms of this registry,
though, it would be helpful to at least try to have some cooperation
with the registry. Thus, I tried to update the registration of the
"alternate" keyword, which the HTML spec now defines in more detail
than the registry's reference (HTML4). I picked this one since it was
the first on the list in the spec. The template was as follows:

 o Relation Name: alternate
 o Description: Gives alternate representations of the curent
   document, provides a link to a syndication feed, or modifies
   the meaning of other link relations, depending on context.
 o Reference: http://www.whatwg.org/specs/web-apps/current-work/complete.html#rel-alternate
 o Notes: (none)
 o Application Data: (none)

Before doing this I received an e-mail from one of the other gate-
keepers of the registry saying that the right way to register these
templates is to put them in the specification and then link to that,
rather than to send the templates to the list as described in the
registry's specification. [28] Therefore to register this keyword I
put the template in the spec and then sent a link to the spec to the
link-relations list. [29]

This registration was rejected but only on the basis that the W3C had
registered the keyword before, so it should again. [30] This seems a
bit surprising, since it's quite possible for relations to be updated
by different organisations later, but I updated the registration and
tried again. [31] It was rejected again (with a "non-rejection
rejection"), this time on the basis that only a reference to the
perpetually out-of-date TR/ draft would be acceptable, not the current
draft on dev.w3.org. I tried to explain why this was unreasonable but
did not get anywhere. [32][33][34][35]

I also tried registering the second of the keywords in the spec, this
time with the WHATWG spec, and the "pingback" relation, pointing to
the Pingback spec, to see whether keywords could easily be registered
without referencing a W3C document (since I expect most people
registering extensions won't be using the W3C!). [36][37]

I never received an answer regarding the "archives" keyword.

The "pingback" keyword was rejected (by a different responder) because
to register it I would have to republish the specification on some
other domain, along with the addition of the template. [38] I tried to
find out if there was any way around this that didn't involve a lot of
work, but did not get anywhere with this either. [39][40][41]


DISCUSSION

Discovery of this mechanism is difficult. I am disappointed that there
is no way to do this using a Web form rather than e-mail. We would
likely have to include elaborate informative instructions in the HTML5
spec itself, possibly with a form that automatically sends the
appropriate e-mail to the mailing list to begin the registration
procedure. This would likely lead to people not using the registry.

To register the relations we would first have to register the fields.
Unfortunately, I've been unable to do that, and the responses received
were highly unhelpful. This makes the registry essentially useless for
HTML; we would have to have a parallel registry anyway.

Furthermore, the problem of the registry requiring by policy that all
new relations apply to all uses of the "rel" attribute makes this
registry IMHO highly inappropriate for HTML. We should not limit
future extension of this language on the basis of whether such
extensions can also apply to a potentially ever-increasing number of
other environments, such as Atom. Even within HTML itself we have
found some relations only apply to some situations (e.g.
rel=stylesheet); changing this purely to work around the policy of a
registry only tangentially related to HTML seems contrary to our
principles of following reality and putting specification authors last
in the priority of constituencies.

I tried registering specific values, rather than fields, and again met
with resistance. It seems required that link types have specs (or that
specs be forthcoming) to be registered at all, which could cause
difficulties when people use values without defining them -- we
wouldn't want those cases conforming, but we'd want them registered,
to avoid conflicts (unfortunately, getting conformance added as a
field also failed, as noted earlier). Furthermore, even beyond the
need for a spec, the spec has to meet quite high non-technical
barriers, for example being published on hixie.ch or dev.w3.org isn't
enough -- but apparently an RFC containing just three lines and no
conformance criteria is sufficient.

All of these rejections -- for both the field types and the keywords
-- have been along lines that appear to me to be highly bureaucratic
and not at all in the best interests of the Web. It seemed at times
that the gatekeepers (plural: two separate people responded during the
test of the registry) are more interested in applying theoretical
policies than actually helping people either to avoid clashes with rel
values or to increase interoperability in this space.


CONCLUSION

I tried registering two fields and three keywords. Four were rejected,
despite several attempts to address the (largely bureaucratic) issues
raised, and the remaining one was ignored. The registry did not get
updated at any point.

In my opinion, the registry process utterly failed the attempt to test
the registry. It could not be used for documenting real-world values
such as rel=stylesheet, because the registry's maintainers prioritise
theoretical purity above pragmatic concerns. It could not replace the
current placeholder wiki, since we would need a parallel registry for
conformance. It could not be used by the WHATWG, since the registry
maintainers refused to register relations defined by the WHATWG. It
could not be used by the W3C, since the registry maintainers refused
to register relations defined in editor's drafts, and HTML is not
likely to be stable for many years. Finally, it could not be used by
third parties to register their potentially poorly-documented (but
actively used) link relations without excessive work, since
specifications on personal sites are not accepted and the documented
policy is to reject registrations without specifications.


REFERENCES

[1] http://www.ietf.org/mail-archive/web/link-relations/current/msg00000.html
[2] http://www.ietf.org/mail-archive/web/link-relations/current/msg00001.html
[3] http://www.ietf.org/mail-archive/web/link-relations/current/msg00003.html
[4] http://www.ietf.org/mail-archive/web/link-relations/current/msg00002.html
[5] http://www.ietf.org/mail-archive/web/link-relations/current/msg00004.html
[6] http://www.ietf.org/mail-archive/web/link-relations/current/msg00005.html
[7] http://www.ietf.org/mail-archive/web/link-relations/current/msg00006.html
[8] http://www.ietf.org/mail-archive/web/link-relations/current/msg00007.html
[9] http://www.ietf.org/mail-archive/web/link-relations/current/msg00008.html
[10] http://www.ietf.org/mail-archive/web/link-relations/current/msg00009.html
[11] http://www.ietf.org/mail-archive/web/link-relations/current/msg00010.html
[12] http://www.ietf.org/mail-archive/web/link-relations/current/msg00011.html
[13] http://www.ietf.org/mail-archive/web/link-relations/current/msg00012.html
[14] http://www.ietf.org/mail-archive/web/link-relations/current/msg00013.html
[15] http://www.ietf.org/mail-archive/web/link-relations/current/msg00014.html
[16] http://www.ietf.org/mail-archive/web/link-relations/current/msg00015.html
[17] http://www.ietf.org/mail-archive/web/link-relations/current/msg00016.html
[18] http://www.ietf.org/mail-archive/web/link-relations/current/msg00017.html
[19] http://www.ietf.org/mail-archive/web/link-relations/current/msg00018.html
[20] http://www.ietf.org/mail-archive/web/link-relations/current/msg00019.html
[21] http://www.ietf.org/mail-archive/web/link-relations/current/msg00020.html
[22] http://www.ietf.org/mail-archive/web/link-relations/current/msg00024.html
[23] http://www.ietf.org/mail-archive/web/link-relations/current/msg00029.html
[24] http://www.ietf.org/mail-archive/web/link-relations/current/msg00032.html
[25] http://www.ietf.org/mail-archive/web/link-relations/current/msg00041.html
[26] http://www.ietf.org/mail-archive/web/link-relations/current/msg00042.html
[27] http://www.ietf.org/mail-archive/web/link-relations/current/msg00045.html
[28] http://www.ietf.org/mail-archive/web/link-relations/current/msg00021.html
[29] http://www.ietf.org/mail-archive/web/link-relations/current/msg00025.html
[30] http://www.ietf.org/mail-archive/web/link-relations/current/msg00028.html
[31] http://www.ietf.org/mail-archive/web/link-relations/current/msg00033.html
[32] http://www.ietf.org/mail-archive/web/link-relations/current/msg00040.html
[33] http://www.ietf.org/mail-archive/web/link-relations/current/msg00043.html
[34] http://www.ietf.org/mail-archive/web/link-relations/current/msg00044.html
[35] http://www.ietf.org/mail-archive/web/link-relations/current/msg00046.html
[36] http://www.ietf.org/mail-archive/web/link-relations/current/msg00034.html
[37] http://www.ietf.org/mail-archive/web/link-relations/current/msg00035.html
[38] http://www.ietf.org/mail-archive/web/link-relations/current/msg00036.html
[39] http://www.ietf.org/mail-archive/web/link-relations/current/msg00037.html
[40] http://www.ietf.org/mail-archive/web/link-relations/current/msg00038.html
[41] http://www.ietf.org/mail-archive/web/link-relations/current/msg00039.html

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

Received on Sunday, 15 August 2010 01:02:50 UTC