Re: Last Call: draft-nottingham-http-link-header (Web Linking) to Proposed Standard

On Thu, Aug 20, 2009 at 1:55 AM, Mark Nottingham <mnot@mnot.net> wrote:

>
>  It might also be worth considering separating the Link: header and the
>> registry into two different specifications. This would also help clarify
>> how a specification should refer to the registry.
>>
>
> How do others feel about this? I'm disinclined to do so unless there's
> considerable value in it. I could see adding a new appendix suggesting
> things that new applications of linking that use this framework, however;
> would that be useful?
>

I would try to keep them separate as much as possible - the Link: header
will be long-lived compared to the bootstrapped registry and people should
know well to refer to the "real" registry (and have the benefit of seeing
how to reference it). Is it possible to mark the section to be removed on
publication? If the pertinent information will be captured by IANA anyway
then that would seem to be the preferred option - otherwise it's just cruft.


>
>  Comparing relation types case-sensitively (e.g. as in 4.2 Extension
>> Relation Types) is incompatible with HTML's processing of rel=""; I would
>> like to request that all relations always be case-insensitive.
>>
>
> Is that specific to HTML5? How does HTML5 process rel?
>

I would tend to agree with this, especially given relations should as much
as possible be generic IMO (e.g. "update" rather than "TwitterTweet") with
the type adding specificity if required. Other semantics (such as that it is
a space separated list) should also be synchronised.


>
>  The Link: header has a "rev" attribute. I would recommend dropping it for
>> consistency with HTML5; we discovered in examining typical usage that
>> people generally didn't understand how to use rev="", and it is redundant
>> with rel="" anyway. If it is kept, then please define how it works.
>> Allowing something but leaving it undefined is the worst of both worlds.
>> (The ideal would be to define how it works but not allow it, IMHO.)
>>
>
> It was included because it's in the syntax of RFC2068, but I agree that
> it's not desirable to perpetuate it. How do people feel about further
> removing it (i.e., it will be an extension, not called out explicitly in the
> syntax)?
>

I would prefer to see it removed as if it's there people will [ab]use it [
http://www.mnot.net/blog/2009/04/14/rev_canonical_bad] and we should, as
much as possible, remain in sync with HTML5. It's unfortunate that abstract
link relations haven't been defined centrally and referred to by specs like
Atom and HTML - perhaps it's too late for that now.


>  The link relations should better define how to handle interactions between
>> multiple link types, so that alternate stylesheet can be well-defined,
>> and so that we can define rel="up up up" as in HTML5.
>>
>
> I think the general consensus is that this is bad practice, but if HTML5
> wants to define semantics around cardinality, it can do so when it defines
> how that relation is interpreted within the scope of its application. I.e.,
> mapping "up up up" to specific behaviours is the job of HTML5, not the link
> framework.
>
> It's worth mentioning here that because HTML5 defines both a syntax and
> what is effectively an application of linking (roughly, "web browsing"), it
> needs to define both the syntax for links and the behaviours associated with
> them.
>

Again coming back to the point about links being defined centrally and
shared across specifications. I tend to agree that this specific example
("up up up") is ordinary and adds a good deal of unnecessary complexity to
implementations (that is, I strongly oppose it). It appears to be only
really relevant for indicating ancestry and then probably only to 2 or 3
generations so "parent", "grandparent" etc. or indeed "up2" "up3" etc. could
work better. In any case this particular example can be resolved by
following the chain. Perhaps this is something worth considering for HTML 5
as well as this represents a deviation.


>
>  The spec should clearly say which takes preference if both title= and
>> title*= are given. Also, the spec should clearly say which takes
>> preference if multiple title=, type=, etc, attributes are given.
>>
>
> Ack.
>

+1


>
>  I think for the best compatibility with legacy implementations, the spec
>> should say that there must only be one occurance of each attribute, and
>> that multiple link types in one Link: header should be listed in one
>> rel="" attribute. (That is, only allow rel="a b", not rel=a;rel=b.)
>>
>
> Do you have data to back this up? I'm concerned that this would disallow
> internationalisation of title, for example (e.g., you couldn't express both
> an english and a spanish title for a link).
>

If that is indeed the case I'd rather break legacy to provide for future
internationalisation.


>
>  Unless there are really strong use cases, I think that the anchor=
>> attribute should be dropped. In practice, implementations today ignore
>> that attribute, which would mean that, e.g., a rel=stylesheet;anchor=a
>> link would fail to have the "right" effect. If it is kept, then the right
>> behaviour for how this should integrate with style sheet linking should be
>> defined in great detail.
>>
>
> I think that at the very least, it needs to be specified that the anchor
> attribute is not used by default; i.e., specific applications of linking
> need to specify that the anchor attribute is to be used.
>
> I'm also amenable to deprecating or removing it, but would like to hear
> from others about this.
>

Unless I've missed something, most applications that need to refer to
specific parts of a document could still do so by embedding the anchor in
the href.


>
>  I would like to request that the registration mechanism be made
>> significantly simpler than the one described in the spec. For example, a
>> simple mechanism could be just to edit a wiki listing all the extensions.
>>
>
> In the IETF, IANA is the mechanism for managing registries like this.
>

In reality people are going to [ab]use the relations anyway - raising the
bar (as is no doubt required in this instance courtesy IETF
policy/precedent) runs the risk of giving up any control we may have had
over them. The WHATWG's RelExtensions wiki page [
http://wiki.whatwg.org/wiki/RelExtensions] appears to work reasonably well,
but that said I don't see much harm in having what is effectively an
unofficial testing ground for such things.


>
>  I would like to request some guidance on what HTML5 would have to do to be
>> compatible with this draft, and what benefits would come from it. There
>> are clear benefits to the Link: header section, assuming that how it fits
>> into the general Web platform is defined (as requested above). But how
>> does the registry fit into the RelExtensions registry for HTML5? How
>> should they interact?
>>
>
> If HTML5 chooses to adopt this framework, it would need to:
>  1) Define the syntax for serialising and parsing links in HTML5, using the
> terms defined in the draft (see Appendix C), and
>  2) Associate concrete behaviours with the general semantics of the
> registered link relations it finds interesting, and
>  3) Define how undefined / unrecognised relations are to be handled (with a
> heavy bias towards must-ignore), and
>  4) Optionally, define additional registered and/or extension link
> relations.
>

I'll leave you two to discuss the details but would strongly support
synchronising the specifications as much as possible. Ideally all
specifications requiring such linking would refer to a common reference but
assuming it's too late for that at this time let's do what we can on both
sides to harmonise them.

In the specific case of the RelExtensions registry it's not really required
except as an informative reference (as experimental/unofficial standards
can/should use URI relations) but as it exists and will likely continue to
exist it should be a superset of the IANA registry and refer back to it
where appropriate.

The bigger risk I see is from standards being treated as mini-registries and
having multiple standards defining a given relation. Standards incorporating
an existing relation should rather include a normative reference to the
original defining standard than re-define the relation. Accordingly,
standards defining new relations should do so discretely.


>
>  The "up", "first", "last", and "payment" types are woefully underdefined.
>> What is the expected UA behaviour when discovering a link with
>> rel=payment? What are the authoring requirements? What are the
>> implementation requirements?
>>
>
> I'd agree that "payment" is ill-defined, but most of the questions you ask
> need to be answered (once again) in the context of a particular application
> of linking, not by the registry.
>
> That said, I think it's worth discussing the relations above to see if we
> can better define them.
>

"up", "first" and "last" are likely easily defined. In the simplest sense
"payment" would appear on a product page and give a user agent a HTTP URL
with which to effect a manual payment. The utility in this instance seems
extremely limited, though in combination with a type specifying some
automated mechanism it could well be quite useful. That is, I don't see much
harm in listing generic concepts like "payment" so long as they are, in
fact, generic.

Sam