Subject: Feedback for draft-nottingham-http-link-header-03

From: Eran Hammer-Lahav <[email-masked]>
Date: Tue, 2 Dec 2008 00:33:10 -0700

I like this draft a lot, especially how the new focus is on the link relationship instead of the Link header.

> 1.  Introduction
>
>    This document defines typed link relations, independent of the
>    context they occur in.  It does so by clarifying the status of the

I think 'context' needs to be clarified to mean 'content type' or 'transport'. Without the next sentence, this seems to imply that instances of the Link header are not context-sensitive, which they are (resource, representation, etc.).

> 4.  Link Relation Types
>
>    Relation types are not to be confused with media types [RFC4288];
>    they do not identify the format of the representation that results
>    when the link is dereferenced.  Rather, they only describe how the
>    current context is related to another resource.

I think it should also clarify the fact that 'type' is non-authoritative but informative (suggestion, hint). In addition, it should state that 'type' should not be used to imply relationship as is often the case with single-use content-types (favicon is one example). It seems many people find the distinction between 'rel' and 'type' confusing and the spec should make it clear how the parameters relate to each other.

>
> 5.  The Link Header Field
>
>        Link           = "Link" ":" #link-value

The '#' operator is not defined in the referenced ABNF provided (it is defined in the original spec).

>    Each link-value conveys one target URI inside angle brackets ("<>").
>    If it is relative, it MUST be resolved as per [RFC3986].  Note that
>    because it is conveyed in a header, base URIs from content are not
>    applied to it.

Just confirming that URI-Reference can be an empty string, i.e.: Link: <>; rel="something". It is needed for using links with URI-templates [1] where the link value is constructed using a template that does not fit in the URI-Reference space (using a link header extension).

>    The context of links conveyed in the Link header field is the
>    representation that the header is part of.

This makes sense since the header is provided in the context of the representation. However, is there a way to indicate that a link is persistent across representations and is not representation-specific? Do 404 and 303 considered representations?

>    Each link-value MUST have at least one "rel" or "rev" parameter whose
>    value indicates the relation type.  If the "rel" parameter is used,
>    it indicates that the link's direction for that relation type is
>    outbound; if the "rev" parameter is used, the given relation type's
>    direction is inbound.

Is 'rev' considered as authoritative as 'rel' (as in, 'type' is non-authoritative, just a hint)? Forward looking links using 'rel' are clearly authoritative as they indicate the view-point of the resource, which has the authority to declare its own perceive links to other resources. However, 'rev' can go both ways. It seems to be semantically equivalent to an identical 'rel' coming from the linked resource. For example:

Resource A: Link: <http://example.com/b>; rel="friend"
Resource B: Link: <http://example.com/a>; rev="friend"

If the two are semantically identical, 'rev' must be non-authoritative as it serves as a hint as to what another resource view the relationship as: "A declares B to be <<its friend>>, B hints that A <<declares B its friend>>". However, if 'rev' is meant to be authoritative, the two links above cannot be semantically the same, as they read: "A declares B to be <<its friend>>, B declares that A <<consider it a friend>>". The question is, is 'rev' simply an implied 'rel' from the other direction (and so, non-authoritative), or 'rev' is a reverse "opinion" of 'rel' which is completely relative to the resource regardless of any actual 'rel' from the other direction (and so, authoritative).

EHL

[1] http://lists.w3.org/Archives/Public/www-talk/2008NovDec/0006.html

---

From: Julian Reschke <[email-masked]>
Date: Tue, 02 Dec 2008 08:43:22 +0100

Eran Hammer-Lahav wrote:
> ...

RFC 2616, Section 2.1.

> ...

Sorry? If the URI-Reference is empty, then the target URI is the one of 
the context.

If you want to introduce an extension point for URI templates, we'll 
need to specify it explicitly.

> ...

BR, Julian

---

From: Eran Hammer-Lahav <[email-masked]>
Date: Tue, 2 Dec 2008 00:47:28 -0700

> is defined in the original spec).

Yep. You are right. Missed it.

> > Just confirming that URI-Reference can be an empty string, i.e.:
> Link: <>; rel="something". It is needed for using links with URI-
> templates [1] where the link value is constructed using a template that
> does not fit in the URI-Reference space (using a link header
> extension).
>

Where? In this spec? I don't think Link should directly deal with URI-templates (would save me a lot of work but still, not really the general-purpose use-case this spec seems to address). But if you don't think there is a simple way to extend link to support templates, we should discuss it now.

EHL

---

From: Julian Reschke <[email-masked]>
Date: Tue, 02 Dec 2008 09:11:26 +0100

> Where? In this spec? I don't think Link should directly deal with URI-templates (would save me a lot of work but still, not really the general-purpose use-case this spec seems to address). But if y…

Well, right now there's no extension point; the target does not allow 
templating, and a parameter can't override it (recipients will ignore 
extension parameters they don't understand).

One potential solution would be to state that if a link target that is 
not a syntactically valid URI-reference is reserved for future 
extensions (so clients ignore it for now).

Another one would be to use a different header, such as Link-Template, 
defined in version 00 of the draft 
(<http://tools.ietf.org/html/draft-nottingham-http-link-header-00#section-5>).

Personally, I'd like to see this move ahead without any dependency on 
URI templates.

BR, Julian

---

From: Eran Hammer-Lahav <[email-masked]>
Date: Tue, 2 Dec 2008 01:35:58 -0700

> extensions (so clients ignore it for now).

This looks like the more promising option.

> (<http://tools.ietf.org/html/draft-nottingham-http-link-header-

The problem with that is the lack of equal treatment this whole draft is trying to establish for Link header/element. This will also stand in the way of the new suggestion to simplify /site-meta to switch to a simple text document with Link header records (with the "Link: " stripped).

> Personally, I'd like to see this move ahead without any dependency on

I agree. There is urgent need in getting this spec finalized and the templates discussion is far from conclusion. But there are enough compelling reasons to bake into this spec support for such future extensions. I think the suggestion to ignore non-compliant URIs is the best option, and I would prefer to see it indicated in the ABNF, but if not, a simple clarification would suffice.

EHL

---

From: Mark Nottingham <[email-masked]>
Date: Wed, 3 Dec 2008 12:31:51 +1100

A separate header is by far the best way to do this.

On 02/12/2008, at 7:35 PM, Eran Hammer-Lahav wrote:

> The problem with that is the lack of equal treatment this whole  
> draft is trying to establish for Link header/element. This will also  
> stand in the way of the new suggestion to simplify /site-meta to  
> switch to a simple text document with Link header records (with the  
> "Link: " stripped).
>
> I agree. There is urgent need in getting this spec finalized and the  
> templates discussion is far from conclusion. But there are enough  
> compelling reasons to bake into this spec support for such future  
> extensions. I think the suggestion to ignore non-compliant URIs is  
> the best option, and I would prefer to see it indicated in the ABNF,  
> but if not, a simple clarification would suffice.
>
> EHL
>

--
Mark Nottingham     http://www.mnot.net/

---

From: Eran Hammer-Lahav <[email-masked]>
Date: Tue, 2 Dec 2008 18:36:40 -0700

(adding www-talk for /site-meta comments)

A separate header is easily workable, but will require a different approach to the proposed simplified /site-meta text format. It cannot be a list of Link headers without the "Link: " prefix and still support this kind of extension.

EHL

On 12/2/08 5:31 PM, "Mark Nottingham" <[email-masked]> wrote:

---

From: Mark Nottingham <[email-masked]>
Date: Wed, 3 Dec 2008 12:37:53 +1100

On 02/12/2008, at 6:33 PM, Eran Hammer-Lahav wrote:
> I think 'context' needs to be clarified to mean 'content type' or  
> 'transport'. Without the next sentence, this seems to imply that  
> instances of the Link header are not context-sensitive, which they  
> are (resource, representation, etc.).

I'm not sure what you're getting at here; this sentence isn't talking  
about the Link header at all...

> I think it should also clarify the fact that 'type' is non- 
> authoritative but informative (suggestion, hint). In addition, it  
> should state that 'type' should not be used to imply relationship as  
> is often the case with single-use content-types (favicon is one  
> example). It seems many people find the distinction between 'rel'  
> and 'type' confusing and the spec should make it clear how the  
> parameters relate to each other.

Yes - type needs to be defined in prose as well.

> This makes sense since the header is provided in the context of the  
> representation. However, is there a way to indicate that a link is  
> persistent across representations and is not representation- 
> specific? Do 404 and 303 considered representations?

*sigh* this is the tricky bit; HTTPbis has at least one open issue on  
this. I believe the current position is that all messages have  
entities, and all entities are representations, the trick being that  
the representation isn't always of the resource which the request was  
sent to; sometimes it's an "anonymous" representation.

> Is 'rev' considered as authoritative as 'rel' (as in, 'type' is non- 
> authoritative, just a hint)? Forward looking links using 'rel' are  
> clearly authoritative as they indicate the view-point of the  
> resource, which has the authority to declare its own perceive links  
> to other resources. However, 'rev' can go both ways. It seems to be  
> semantically equivalent to an identical 'rel' coming from the linked  
> resource. For example:
>
> If the two are semantically identical, 'rev' must be non- 
> authoritative as it serves as a hint as to what another resource  
> view the relationship as: "A declares B to be <<its friend>>, B  
> hints that A <<declares B its friend>>". However, if 'rev' is meant  
> to be authoritative, the two links above cannot be semantically the  
> same, as they read: "A declares B to be <<its friend>>, B declares  
> that A <<consider it a friend>>". The question is, is 'rev' simply  
> an implied 'rel' from the other direction (and so, non- 
> authoritative), or 'rev' is a reverse "opinion" of 'rel' which is  
> completely relative to the resource regardless of any actual 'rel'  
> from the other direction (and so, authoritative).

This draft isn't attempting to establish a framework for semantics or  
trust, and I'm tempted to take out anything that might imply this...

---

From: Eran Hammer-Lahav <[email-masked]>
Date: Wed, 3 Dec 2008 01:45:31 -0700

> about the Link header at all...

Link header is just one instance of 'typed link relations'. The first time read this, before reading the next sentence, I was a bit confused as to what you meant by 'context'. It might just be my expectations from reading the previous draft which was about Link headers.

> sent to; sometimes it's an "anonymous" representation.

For my use cases, I can live with the application specifying how this should be handled.

> trust, and I'm tempted to take out anything that might imply this...

I think at a minimum it needs to clearly define the relationship between 'rel' and 'rev'. This is why I liked it better when 'rev' was dropped. If you only have 'rel', you can express 'rev' with another 'rel' value, and that will solve my issue. If you keep both, I can't see how you can avoid explaining their relationship to one another as listed in the example above.

EHL

---

From: Phil Archer <[email-masked]>
Date: Wed, 03 Dec 2008 09:53:41 +0000

I'd just like to jump in on one point:

Eran Hammer-Lahav wrote:
[..]
> I think at a minimum it needs to clearly define the relationship between 'rel' and 'rev'. This is why I liked it better when 'rev' was dropped. If you only have 'rel', you can express 'rev' with an…

I just wrote out an argument for why I felt it was important to keep 
rev... and realised that my own arguments convinced me that it probably 
isn't needed for HTTP Link after all. The arguments over the relative 
authority and semantics of rel and rev links is pretty compelling.

And yet, and yet... I would still be concerned to see it go because it 
is *really* useful in RDFa. HTML 5 has dropped rev for the link element 
and if the tide is against keeping rev in HTTP Link then the impression 
being given might be that rev is deprecated everywhere. Even though that 
is not what is being said or implied here, it could lead to future 
confusion.

Phil.

-- 

Phil Archer
w. http://philarcher.org/

---

From: Mark Nottingham <[email-masked]>
Date: Wed, 3 Dec 2008 21:39:05 +1100

I think the key is to define the semantics of rel vs. rev well enough  
that a relation doesn't necessarily have to say something about them,  
but that it still can without conflicting.

Yes, that's a fine line to walk.

On 03/12/2008, at 8:53 PM, Phil Archer wrote:

>> I think at a minimum it needs to clearly define the relationship  
>> between 'rel' and 'rev'. This is why I liked it better when 'rev'  
>> was dropped. If you only have 'rel', you can express 'rev' with  
>> another 'rel' value, and that will solve my issue. If you keep  
>> both, I can't see how you can avoid explaining their relationship  
>> to one another as listed in the example above.
>
> rev... and realised that my own arguments convinced me that it  
> probably isn't needed for HTTP Link after all. The arguments over  
> the relative authority and semantics of rel and rev links is pretty  
> compelling.
>
> And yet, and yet... I would still be concerned to see it go because  
> it is *really* useful in RDFa. HTML 5 has dropped rev for the link  
> element and if the tide is against keeping rev in HTTP Link then the  
> impression being given might be that rev is deprecated everywhere.  
> Even though that is not what is being said or implied here, it could  
> lead to future confusion.
>
> Phil.
>
> -- 
>
> Phil Archer

---

From: Mark Nottingham <[email-masked]>
Date: Wed, 3 Dec 2008 21:42:40 +1100

On 03/12/2008, at 7:45 PM, Eran Hammer-Lahav wrote:

> Link header is just one instance of 'typed link relations'. The  
> first time read this, before reading the next sentence, I was a bit  
> confused as to what you meant by 'context'. It might just be my  
> expectations from reading the previous draft which was about Link  
> headers.

OK, I'll try to re-read with a fresh eye and see if I can clarify.

> another 'rel' value, and that will solve my issue. If you keep both,  
> I can't see how you can avoid explaining their relationship to one  
> another as listed in the example above.

I think the issue here is more around trust than just semantics; i.e.,  
you need to know the source of the statement to evaulate it. The thing  
is, that's really defined by the context of use; i.e., if you're  
working from within some wonderful semantic framework, you might be  
able to trust inbound links.

So, if this were defined by the application, would you be more happy?  
The effect on *this* spec, I think, would be that the link *header*  
section would say that rev links aren't necessarily authoritative.

Make sense?s

---

From: Phil Archer <[email-masked]>
Date: Wed, 03 Dec 2008 10:57:15 +0000

Mark Nottingham wrote:
>> Link header is just one instance of 'typed link relations'. The first 
>> time read this, before reading the next sentence, I was a bit confused 
>> as to what you meant by 'context'. It might just be my expectations 
>> from reading the previous draft which was about Link headers.
> 
>> between 'rel' and 'rev'. This is why I liked it better when 'rev' was 
>> dropped. If you only have 'rel', you can express 'rev' with another 
>> 'rel' value, and that will solve my issue. If you keep both, I can't 
>> see how you can avoid explaining their relationship to one another as 
>> listed in the example above.
> 
> 
> is, that's really defined by the context of use; i.e., if you're working 
> from within some wonderful semantic framework, you might be able to 
> trust inbound links.
> 

Makes sense to me, yes. The problem is that HTTP is generally seen as 
authoritative (the thrust of 
http://www.w3.org/2001/tag/doc/mime-respect) so this spec will need to 
be clear that applications should treat an inbound (rev) link is an 
exception to this. That might be too close to going against a TAG 
finding for some??

-- 

Phil Archer

---

From: Mark Nottingham <[email-masked]>
Date: Wed, 3 Dec 2008 22:09:24 +1100

On 03/12/2008, at 9:57 PM, Phil Archer wrote:

> Makes sense to me, yes. The problem is that HTTP is generally seen  
> as authoritative (the thrust of http://www.w3.org/2001/tag/doc/mime-respect) 
>  so this spec will need to be clear that applications should treat  
> an inbound (rev) link is an exception to this. That might be too  
> close to going against a TAG finding for some??

Nah, that's just in the context of Content-Type (which stretches to  
include encoding).

---

From: Julian Reschke <[email-masked]>
Date: Wed, 03 Dec 2008 12:29:04 +0100

> section would say that rev links aren't necessarily authoritative.

Not sure. What would that achieve?

Why would you trust

   rel=author

more then

   rev=made

?

In general, the level of trust for a relation exposed with a resource 
probably depends *both* on the resource and the link relation being 
used, not the fact whether it's exposed as "rel" or "rev".

Best regards, Julian

---

From: Eran Hammer-Lahav <[email-masked]>
Date: Wed, 3 Dec 2008 10:59:06 -0700

> From: Williams, Stuart (HP Labs, Bristol) [mailto:[email-masked]]
> Sent: Wednesday, December 03, 2008 7:20 AM
>
> Hello Mark,
>
> [just dipping into the achive and found this between you and Eran]
>
> > > This makes sense since the header is provided in the context of
> > > the representation. However, is there a way to indicate that a
> > > link is persistent across representations and is not
> > > representation- specific? Do 404 and 303 considered representations?
> >
> > *sigh* this is the tricky bit; HTTPbis has at least one open issue
> > on this. I believe the current position is that all messages have
> > the representation isn't always of the resource which the request
> > was sent to; sometimes it's an "anonymous" representation.
>
> Oh dear... I think we need to be clear about the whether the relations
> being conveyed in Link: headers are intended to hold between resources
> or between the conveyed representation and whatever the target URI
> refers to.

The current draft is pretty clear that the link is between the conveyed representation of the resource, but what is not clear is to what. Let's assume 'type' is not present in a Link header. This means the on one side of the relationship we have a representation while on the other side we have a resource (as no representation is specified). This gets more complex if we bring 'type' back in.

My current understanding of 'type' is nothing more than a hint. Something to help user-agents better choose the links that serve their needs. Because one resource has no authority to define the content type of another, this 'hint' interpretation is appropriate. But when considering this discussion, 'type' might very well turn out to define the representation of the linked resource the relationship is between.

For example, the response to GET /resource/1:

Content-type: text/html
Link: <http://example.com/resource/2>; rel="next"; type="text/html"

Can mean, this is a link between:

1. /resourse/1 and /resource/2
2. the text/html representation of /resource/1 and (any representation of) /resource/2 3. the text/html representation of /resource/1 and the text/html representation of /resource/2

If /resource/2 does not support the text/html representation, then #3 means a broken link, just as if /resource/2 would return a 404 with no additional useful information.

> Personnally, my hope is that the relations are regarded as holding
> between the resources that are referenced by URIs (as opposed to one
> party to the relation being a more ephemeral representation or message
> being conveyed).

I agree both on simplicity grounds but also because once links are attached to the context of specific representations, it opens up the can of worms above, where the link may or may not be symmetric (one side representation and the other resource). And as demonstrated above, it put the meaning of 'type' in question.

> Of course the question is what resource supplies the context,
> particularly in the case of a response that carries a "Content-
> Location:" header that carries a different URI from that in the
> request.
>
> It seems to me that candidate choices for the context resource are:
>
> a) the resource referenced in the request line of the corresponding
> HTTP request.
> b) the resource referenced in a Content-Location: header returned in
> the same response.
>
> are there any other candidates?
>
> Does one take a) as the default and allow b) if present to override
> a), or simply stick with the original request URI.
>
> Simplicity suggests just a) and that if you want to find out about
> links associated with the resource reference by a "Content-Location:"
> then you go ask there.

I think a) is the right choice and not just for simplicity. The current response has no authority over the link relationships of the other resource identified by the Content-location header.

EHL

---

From: "Williams, Stuart (HP Labs, Bristol)" <[email-masked]>
Date: Wed, 3 Dec 2008 18:03:24 +0000

Hello Eran,

Responses in line below.

> -----Original Message-----
> From: Eran Hammer-Lahav [mailto:[email-masked]]
> Sent: 03 December 2008 16:47
> To: Williams, Stuart (HP Labs, Bristol)
> Subject: RE: Feedback for draft-nottingham-http-link-header-03
>
> The current draft is pretty clear that the link is between
> the conveyed representation of the resource, but what is not
> clear is to what.

[As I read toward the end I see that we are largely in agreement about how we think things should be - however I started on this response thinking that we were more in disagreement - in particular that you thought that at least one end of a link is grounded in a representation - it is evident later that you don't think that is how things should be.]

I have to say that I do not get such clarity from the draft. From the get-go it seems to be about relations between pairs of resources and not between some ephemeral representation of a resource and some (usually) other resource.

eg:
"1.  Introduction

   A means of indicating the relationships between documents on the Web,
                             ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
   as well as indicating the type of those relationships, has been
   available for some time in HTML [W3C.REC-html401-19991224], and more
   recently in Atom [RFC4287].  These mechanisms, although conceptually
   similar, are separate.  However, links between resources need not be
                                    ^^^^^^^^^^^^^^^^^^^^^^^
   format-specific; it can be useful to have typed links that are
   independent of the format, especially when a resource has
   representations in multiple formats."

There may be resources that repeatedly emit 'identical' representations or select from the same set of equivalent representation (conneg) but I truely hope that what are speaking about is relations or links between resources.

The draft heads off into vagueness when it starts to speak of "contex of use". I think that the simple fix would be to say that the requested resource *is* the context of use or indeed to drop the notion of "context of use" and just speak of plainly about the relation being between the requested resource and the link target - much more direct and less fluffy.

> Let's assume 'type' is not present in a
> Link header. This means the on one side of the relationship
> we have a representation while on the other side we have a
> resource (as no representation is specified). This gets more
> complex if we bring 'type' back in.

The HTTP request contains a resource reference; the link target contains a resource reference. The link: stated relation or rev is claimed to exist between those two resources (modulo handling of "Content-Location:"). What could be simpler.

You'll see my concerns about 'type' expressed in my question on "metadata-discovery@googlegroups". It's clear to me that you, as I, think that its role is advisory - otherwise were have a much more complicated situation where there relation becomes a cross-product of two identifiers - the rel or rev and the type. Honestly, I think that 'type' should be depricated from the Link: header spec - though I'm sure that others would disagree.

>
> My current understanding of 'type' is nothing more than a
> hint. Something to help user-agents better choose the links
> that serve their needs. Because one resource has no authority
> to define the content type of another, this 'hint'
> interpretation is appropriate. But when considering this
> discussion, 'type' might very well turn out to define the
> representation of the linked resource the relationship is between.

Well on the whole web architecture does not give you the granularity to speak about specific resource representations (either by time or by format). The trick it pulls is to allow generic resources to conneg to more specific resources (eg. http://www.w3.org/Icons/w3c_home connegs to .gif or .png or ... and reports that it has done so in a Content-Location: header). In this way we can avoid thinking of representations having URIs (they don't - sure you could assign one so that you could talk about it - but you'd have to promote it to being a resource if you wanted to make it accessible) - you assign different URI to the different conneg'd variant *resources*.

> 1. /resourse/1 and /resource/2
yes

> 2. the text/html representation of /resource/1 and (any representation of) /resource/2
I hope not.

> 3. the text/html representation of /resource/1 and the text/html representation of /resource/2
Likewise, I hope not

> If /resource/2 does not support the text/html representation,
> then #3 means a broken link, just as if /resource/2 would
> return a 404 with no additional useful information.

It is IMO both correct and much simpler to regard the relation as holding between resources and push representations down as just an artifact that exposes a view on the state of a resource.

> I agree both on simplicity grounds but also because once
> links are attached to the context of specific
> representations, it opens up the can of worms above, where
> the link may or may not be symmetric (one side representation
> and the other resource). And as demonstrated above, it put
> the meaning of 'type' in question.

Ok... I think we're probably in loud agreement.

> > Does one take a) as the default and allow b) if present to override a),
> > or simply stick with the original request URI.
> >
> I think a) is the right choice and not just for simplicity.
> The current response has no authority over the link
> relationships of the other resource identified by the
> Content-location header.

Ah... one could view the conneg action as having made a hidden redirection to the specific resource and that he given response originates from the more specific resource as opposed to the requested resource. I have checked through the details - so it might be possible to find cases that allow us to conclude that that would be a flawed thing to think - eg a header listing the available representation formats that is consistent with the requested resource, but would clearly be a superset of what the more specific resource could provide.

So I think b) could be justified - but I think just a) because how else would you be able to ensure that the requested resource is the subject(rel) or object(rev) of a link assertion - particularly if your aim is to find metadata about that subject resource. The b) view would repeatedly mask the requested resource as the subject/object of link relations and you'd only be able to find out about its close friends.

> EHL

Stuart
--
Hewlett-Packard Limited registered Office: Cain Road, Bracknell, Berks RG12 1HN
Registered No: 690597 England

---

From: Subbu Allamaraju <[email-masked]>
Date: Wed, 3 Dec 2008 11:26:44 -0800

Hi Eran,

> The current draft is pretty clear that the link is between the  
> conveyed representation of the resource, but what is not clear is to  
> what. Let's assume 'type' is not present in a Link header. This  
> means the on one side of the relationship we have a representation  
> while on the other side we have a resource (as no representation is  
> specified). This gets more complex if we bring 'type' back in.

When type is missing, the server is not providing any hint, and the  
client can resort to conneg.
> 2. the text/html representation of /resource/1 and (any  
> representation of) /resource/2 3. the text/html representation of / 
> resource/1 and the text/html representation of /resource/2

It is just (1) with the type being a hint to the media type of that  
resource.

> If /resource/2 does not support the text/html representation, then  
> #3 means a broken link, just as if /resource/2 would return a 404  
> with no additional useful information.

I don't think the type provides such a guarantee.
> I agree both on simplicity grounds but also because once links are  
> attached to the context of specific representations, it opens up the  
> can of worms above, where the link may or may not be symmetric (one  
> side representation and the other resource). And as demonstrated  
> above, it put the meaning of 'type' in question.

HTML/Atom link elements offer the same kind of flexibility. The source  
is a representation, and the target could be one of the following:

a. A different representation of the same resource
b. Another resource
c. A specific representation of another resource.

Subbu
---
http://subbu.org

---

From: Eran Hammer-Lahav <[email-masked]>
Date: Wed, 3 Dec 2008 16:34:18 -0700

Either they have a clear meaning or they don't. If the interaction between rel and rev is application specific, what is the value of having rev in the spec? It doesn't help with interop.

For example, if the response to GET /resource/2 is:
Link: <http://example.com/resource/1>; rev="next"

It can either be the *same* as a GET /resource/1 returns:
Link: <http://example.com/resource/2> rel="next"

OR

Can be equally expressed like this (in response to GET /resource/2):
Link: <http://example.com/resource/1>; rel="rev/next"
Where a 'rev/' prefix means the same rel but inbound.

To leave the choice between these interpretations two up to each application seems to void the benefit of having both rel and rev. I think the second interpretation is the right one, which calls for dropping 'rev'.

EHL

On 12/3/08 2:39 AM, "Mark Nottingham" <[email-masked]> wrote:

---

From: Mark Nottingham <[email-masked]>
Date: Thu, 4 Dec 2008 13:45:43 +1100

That's just syntactic sugar...

On 04/12/2008, at 10:34 AM, Eran Hammer-Lahav wrote:

> Either they have a clear meaning or they don’t. If the interaction  
> between rel and rev is application specific, what is the value of  
> having rev in the spec? It doesn’t help with interop.
>
> Link: <http://example.com/resource/1>; rev=”next”
>
> Link: <http://example.com/resource/2> rel=”next”
>
> OR
>
> Link: <http://example.com/resource/1>; rel=”rev/next”
> Where a ‘rev/’ prefix means the same rel but inbound.
>
> To leave the choice between these interpretations two up to each  
> application seems to void the benefit of having both rel and rev. I  
> think the second interpretation is the right one, which calls for  
> dropping ‘rev’.
>
> EHL
>
>

---

From: Mark Nottingham <[email-masked]>
Date: Thu, 4 Dec 2008 14:05:31 +1100

On 04/12/2008, at 1:56 PM, Drummond Reed wrote:

> [disclaimer: I’m new to the rel/rev discussion so ignore all this if  
> I’m treading on well-worn territory.]
>
> I agree that if both “rel” and “rev” are included for outbound and  
> inbound links, respectively, their semantics must be uniform for all  
> applications.

Ideally, agreed. However, the problem is that defining the difference  
between inbound and outbound is difficult to do with great precision,  
unless you do it in the confines of a full framework for semantics on  
the Web. That seems like overkill to the greatest degree for this,  
which is why I suggested keeping it a *bit* fuzzy.

The important thing to decide here is what needs to go in *this* spec,  
realising that other specs can add things to it.

>  I also agree that the semantics of being able to assert both  
> outbound and inbound links are very useful (with my OASIS XDI TC co- 
> chair hat on I’d be shot if I said anything else – XDI RDF lives and  
> breaths by such statements).
>
> But I honestly don’t know how useful it is specifically for HTTP  
> Link headers. I don’t have enough experience there.
>
> What I can offer is this perspective on the two solutions I see  
> being discussed in the thread below (Solution #1 being to keep both  
> “rel” and “rev” and clearly define the semantics of each to be the  
> directionality of the relation, and Solution #2 being what Eran  
> suggests to keep only “rel” and put the semantics defining  
> directionlity _in the relation URI_.)

That's a non-starter; already-defined relations don't do this, current  
practice doesn't do this, and although rev isn't widely used, it is  
used in some places.

> So in the HTTP/HTML Web world where the vast majority of URIs today  
> are opaque, keeping “rel” and “rev” seems a little cleaner if you  
> want to keep the ability to express both outbound and inbound links.

Agreed.

---

From: "Drummond Reed" <[email-masked]>
Date: Wed, 3 Dec 2008 18:56:45 -0800

[disclaimer: I'm new to the rel/rev discussion so ignore all this if I'm
treading on well-worn territory.]

I agree that if both "rel" and "rev" are included for outbound and inbound
links, respectively, their semantics must be uniform for all applications.

I also agree that the semantics of being able to assert both outbound and
inbound links are very useful (with my OASIS XDI TC co-chair hat on I'd be
shot if I said anything else - XDI RDF lives and breaths by such
statements).

But I honestly don't know how useful it is specifically for HTTP Link
headers. I don't have enough experience there.

What I can offer is this perspective on the two solutions I see being
discussed in the thread below (Solution #1 being to keep both "rel" and
"rev" and clearly define the semantics of each to be the directionality of
the relation, and Solution #2 being what Eran suggests to keep only "rel"
and put the semantics defining directionlity _in the relation URI_.)

Both approaches work, but there's a huge difference in how the semantics are
expressed (more on that below). However I don't believe it should have
anything to do with authority (the thread quoted below Eran's reply). To
illustrate that I'd just put it in terms of a graph model (not necessarily
an RDF graph model - I think the following would apply to any directed graph
model):

* Any node of the graph with URI X can declare that it has an outgoing arc
or an incoming arc, i.e., "I have an outbound arc of relation type Y to the
node with URI Z" and "I have an inbound arc of relation type Y from the node
with URI Z". The authority for node X _is_ authoritative for both of those
statements, and they stand independent of any statement from the authority
for node Z.

* That doesn't mean both of those statements are true. The first one - the
statement of an outbound link - is a priori true because the node is the
source of the link. The second one - the statement of an inbound link -
_might_ be true. If you trust statements from the authority for node X, you
can stop there. If you don't trust that authority (or you like to trust but
verify ;-), you can verify by finding out if the authority for node Z makes
the inverse statement, i.e. "I have an outbound arc of relation type Y with
the node at URI X." We've been dealing with that kind of trust verification
in XRI resolution for a few years now.

So it's valid for any node make statements about both outbound and inbound
arcs to that node - and both types are particularly useful from a discovery
perspective, and can be verified as necessary by consuming applications. So
that would argue in favor of keeping the ability to express both outbound
and inbound links in Link headers.

Now about the difference in how it's done.

* Doing it with separate attributes for the relation type URI is clean and
doesn't affect the semantics of the relation type URI at all. But it
requires both "rel" and "rev".

* Doing it with just "rel" and putting the semantics in the relation type
URI is theortically more elegant because then you only need one attribute.
However it has two challenges. The first is that URIs don't currently carry
such semantics. Eran's suggestion of using rel="rev/next", i.e.:

.would imply the semantics that the string "rev/{some-relative-URI}" mean
the inverse arc of the relation defined by {some-relative-URI}. That's a
cool idea, but it puts semantics into what otherwise are opaque identifiers.
(The reason I'm sympathetic to this approach is that this is exactly what
XRI syntax was create for - establishing shared semantics for URIs. In fact
XDI RDF has even defined an XRI prefix for other XRIs that does exactly what
Eran suggests. But XRIs only work when the base URI establishes an XRI
context, and I doubt you want to require all link relations to be XRIs ;-)

The second challenge is that it changes the semantics of the "rel" attribute
itself in comparison to other specs like HTML that use it. As I understand
it, in those specs, "rel" always means "outbound link" and "rev" (when used)
means "inbound link".

So in the HTTP/HTML Web world where the vast majority of URIs today are
opaque, keeping "rel" and "rev" seems a little cleaner if you want to keep
the ability to express both outbound and inbound links.

Hope this helps,

=Drummond 

  _____  

From: Eran Hammer-Lahav [mailto:[email-masked]] 
Sent: Wednesday, December 03, 2008 3:34 PM
To: Mark Nottingham; Phil Archer
Cc: [email-masked]; Drummond Reed
Subject: Re: Feedback for draft-nottingham-http-link-header-03

Either they have a clear meaning or they don't. If the interaction between
rel and rev is application specific, what is the value of having rev in the
spec? It doesn't help with interop.

OR

To leave the choice between these interpretations two up to each application
seems to void the benefit of having both rel and rev. I think the second
interpretation is the right one, which calls for dropping 'rev'.

EHL

---

From: Eran Hammer-Lahav <[email-masked]>
Date: Wed, 3 Dec 2008 23:33:03 -0700

I really like the explanation below. It solves my dilemma with having both rel/rev. Hopefully we can incorporate something just like that but either way I don't have an objection to both anymore (not that it was blocking in any way before).

EHL

From: Drummond Reed [mailto:[email-masked]]
Sent: Wednesday, December 03, 2008 6:57 PM
To: Eran Hammer-Lahav; 'Mark Nottingham'; 'Phil Archer'
Cc: [email-masked]
Subject: RE: Feedback for draft-nottingham-http-link-header-03

[disclaimer: I'm new to the rel/rev discussion so ignore all this if I'm treading on well-worn territory.]

I agree that if both "rel" and "rev" are included for outbound and inbound links, respectively, their semantics must be uniform for all applications.

I also agree that the semantics of being able to assert both outbound and inbound links are very useful (with my OASIS XDI TC co-chair hat on I'd be shot if I said anything else - XDI RDF lives and breaths by such statements).

But I honestly don't know how useful it is specifically for HTTP Link headers. I don't have enough experience there.

What I can offer is this perspective on the two solutions I see being discussed in the thread below (Solution #1 being to keep both "rel" and "rev" and clearly define the semantics of each to be the directionality of the relation, and Solution #2 being what Eran suggests to keep only "rel" and put the semantics defining directionlity _in the relation URI_.)

Both approaches work, but there's a huge difference in how the semantics are expressed (more on that below). However I don't believe it should have anything to do with authority (the thread quoted below Eran's reply). To illustrate that I'd just put it in terms of a graph model (not necessarily an RDF graph model - I think the following would apply to any directed graph model):

* Any node of the graph with URI X can declare that it has an outgoing arc or an incoming arc, i.e., "I have an outbound arc of relation type Y to the node with URI Z" and "I have an inbound arc of relation type Y from the node with URI Z". The authority for node X _is_ authoritative for both of those statements, and they stand independent of any statement from the authority for node Z.

* That doesn't mean both of those statements are true. The first one - the statement of an outbound link - is a priori true because the node is the source of the link. The second one - the statement of an inbound link - _might_ be true. If you trust statements from the authority for node X, you can stop there. If you don't trust that authority (or you like to trust but verify ;-), you can verify by finding out if the authority for node Z makes the inverse statement, i.e. "I have an outbound arc of relation type Y with the node at URI X." We've been dealing with that kind of trust verification in XRI resolution for a few years now.

So it's valid for any node make statements about both outbound and inbound arcs to that node - and both types are particularly useful from a discovery perspective, and can be verified as necessary by consuming applications. So that would argue in favor of keeping the ability to express both outbound and inbound links in Link headers.

* Doing it with separate attributes for the relation type URI is clean and doesn't affect the semantics of the relation type URI at all. But it requires both "rel" and "rev".

* Doing it with just "rel" and putting the semantics in the relation type URI is theortically more elegant because then you only need one attribute. However it has two challenges. The first is that URIs don't currently carry such semantics. Eran's suggestion of using rel="rev/next", i.e.:

...would imply the semantics that the string "rev/{some-relative-URI}" mean the inverse arc of the relation defined by {some-relative-URI}. That's a cool idea, but it puts semantics into what otherwise are opaque identifiers. (The reason I'm sympathetic to this approach is that this is exactly what XRI syntax was create for - establishing shared semantics for URIs. In fact XDI RDF has even defined an XRI prefix for other XRIs that does exactly what Eran suggests. But XRIs only work when the base URI establishes an XRI context, and I doubt you want to require all link relations to be XRIs ;-)

The second challenge is that it changes the semantics of the "rel" attribute itself in comparison to other specs like HTML that use it. As I understand it, in those specs, "rel" always means "outbound link" and "rev" (when used) means "inbound link".

So in the HTTP/HTML Web world where the vast majority of URIs today are opaque, keeping "rel" and "rev" seems a little cleaner if you want to keep the ability to express both outbound and inbound links.

Hope this helps,

=Drummond

________________________________

OR

EHL

---

From: Ian Hickson <[email-masked]>
Date: Sat, 6 Dec 2008 02:44:49 +0000 (UTC)

On Wed, 3 Dec 2008, Phil Archer wrote:
> 
> HTML 5 has dropped rev for the link element and if the tide is against 
> keeping rev in HTTP Link then the impression being given might be that 
> rev is deprecated everywhere.

Eran asked me to chime in here to give some background on why HTML5 drops 
the "rev" attribute.

It basically boils down to reducing author confusion. As can be seen from 
this thread, even people quite familiar with Web standards and semantics 
have trouble defining exactly what it means. We did some research and 
found a quite startling situation: the most common value for rev="" in the 
HTML pages we examined was rev="made", which is equivalent to 
rel="author", and the second most common value was rev="stylesheet", which 
is a typo. The remaining values were so too rare to examine. Further 
evidence that there was confusion: rel="made" was a common rel="" value, 
though it is likely that in most cases it should have been rev="made" or 
rel="author".

What we concluded from this was that despite the feature (rev="") being 
available for a decade or more, authors don't need it, and don't 
understand it.

We can help authors by making this that they usually misuse invalid, 
because then the validators will catch their errors. (Right now, an HTML4 
validator can't strictly say that rev="stylesheet" was an error, and so 
the error goes undetected even by authors using QA tools.)

The data was published here:
   http://code.google.com/webstats/2005-12/linkrels.html

(More recent but unpublished studies have shown similar results in larger 
and more recent datasets.)

The above was weighed against the (currently mostly theoretical) need for 
rev="" in various fields, such as RDFa, some Microformats, and so on, but 
on the balance we decided that the immediate help to authors was worth 
more to authors and users than these use cases. Helping with this was the 
realisation that rel="" values could always be minted in a way that was 
equivalent to rev="". For example, if someone had rel="foobar" and really 
wanted rev="foobar" to be available too, they could instead just define 
and use rel="rev-foobar".

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

---

From: "Drummond Reed" <[email-masked]>
Date: Fri, 5 Dec 2008 21:53:25 -0800

> On Friday, 5 Dec 2008, Ian Hickson wrote:
> 

It seems like a reasonable conclusion relative to HTML authoring.

> and use rel="rev-foobar".

Some recent feedback on Link Header highlights a serious issue with that
workaround. Even if HTML5 drops "rev", it doesn't change the semantics
established in HTML4, RDFa, and other uses that "rel" and "rev" assert
outbound and inbound links, respectively. So to start saying that _some_
uses of "rel" can assert inbound links by inserting special semantics _into
the value_ of the attribute would appear to invite a real semantic mess.

Much better to either: a) drop support for "rev" but leave "rel"
unambiguously asserting outbound links, or b) define a whole new attribute
that explicitly takes link directionality semantics out of the attribute
definition and puts them into the attribute value.

=Drummond

---

From: Eran Hammer-Lahav <[email-masked]>
Date: Fri, 5 Dec 2008 23:20:02 -0700

The key question is what interoperability value does 'rev' add vs. the potential confusion is might cause (I am not trying to imply an answer here). The way I understand is, Link header was defined in RFC 2068 and dropped in 2616 due to lack of implementations and experience using it during that time period. The reason it is being brought back now is because between ATOM, HTML, and some experimentations with the Link header, it seems like we have gained the experience needed to define it as part of the protocol. Using the overall logic, is there sufficient experience using 'rev' values to include it in the current proposal (again, asking not implying)?

EHL

> Sent: Friday, December 05, 2008 9:53 PM
> To: 'Ian Hickson'; 'Phil Archer'
> Cc: [email-masked]; Eran Hammer-Lahav; 'Mark Nottingham'

---

From: "Drummond Reed" <[email-masked]>
Date: Fri, 5 Dec 2008 23:04:24 -0800

Eran asks a really good question and I don't have the experience to answer.
I'm coming from an XDI RDF perspective where the ability to express both
inbound and outbound links is very useful. But I understand how tricky and
confusing such semantics are for authors who are not steeped in that type of
stuff.

My only input is: a) if "rev" is going to be useful anywhere, it's in
discovery, and b) if "rev" is dropped, keep "rel" to just outbound links.

=Drummond 

> Sent: Friday, December 05, 2008 10:20 PM
> To: Drummond Reed; 'Ian Hickson'; 'Phil Archer'
> Cc: [email-masked]; 'Mark Nottingham'
> The key question is what interoperability value does 'rev' add vs. the
> potential confusion is might cause (I am not trying to imply an answer
> here). The way I understand is, Link header was defined in RFC 2068 and
> dropped in 2616 due to lack of implementations and experience using it
> during that time period. The reason it is being brought back now is
> because between ATOM, HTML, and some experimentations with the Link
> header, it seems like we have gained the experience needed to define it as
> part of the protocol. Using the overall logic, is there sufficient
> experience using 'rev' values to include it in the current proposal
> (again, asking not implying)?
> 
> EHL
> 
>

---

From: "Roy T. Fielding" <[email-masked]>
Date: Sat, 6 Dec 2008 00:14:15 -0800

On Dec 5, 2008, at 9:53 PM, Drummond Reed wrote:
> outbound and inbound links, respectively.

Umm, no, they don't assert inbound links.  The only deployed value
for rev (rev="Made") defines a link from this representation of a
resource to its maker.  The only thing directional about it is the
relation name itself, which implies an out relation, but it is the
relation that is reversed by rev=name, not the link.  In your words,
rev asserts an inbound relationship as an outbound link.

The semantics of most relation names do imply that an inverse
relationship must also be true.  However, that applies to both
rel and rev.  For example, "X rel=parent Y" implies that the
relation "X is a child of Y" is true even if there is no
corresponding link (a link on representation of Y that
explicitly says "Y rel=child X").

IIRC, the rationale for having both rel and rev was because
restricting the names to a unidirectional set of relations
would reduce their number (as opposed to minting the relation names
in pairs). In practice, however, that didn't work.  People don't
communicate that way -- they mint new relation names all the time.
And they don't do it in generalities. In fact, rev=made and
rel=author do not mean the same thing: we are far better off
if we encourage people to use more specific, easily understood
relations like "author", "artist", "composer", "sculptor",
and so on.  Programs can infer the inverse and superset
relations.

It is far easier to change the software to infer more generic
relations with inverse tables and implications than it is to
change how people choose to communicate.

I would prefer that rev be deprecated (parsed without error
but discouraged in documentation and validation).

....Roy

---

From: Phil Archer <[email-masked]>
Date: Sat, 06 Dec 2008 08:30:22 +0000

> discovery, and b) if "rev" is dropped, keep "rel" to just outbound links.

+1

However, Hixie's argument against rev actually highlights my unease 
about dropping it from HTTP Link. It's the same basic argument used by 
the WHAT WG to decide whether to keep or remove features in HTML 5. On 
the surface it's an attractive one: if no one uses a feature properly, 
or worse, where a feature is used it's generally used improperly, then 
it should probably be dropped. The flaw with the argument is that it can 
only ever lead to a diminishing feature set and imposes restrictions on 
current and future use cases.

Yes, the use of rev in RDFa is still largely theoretical on account of 
RDFa still being relatively new, but if you handicap it by giving the 
impression that rev /in general/ is deprecated then you weaken the 
thrust of the community here which, as I understand it, is doing its 
level best to improve discovery and semantics.

For me the semantics of rel and rev are clear enough - the only 
difference between them being that rel is outbound and rev is inbound. 
There is, however, a much greater difference in the trust one might wish 
to put in those links - and trust is a human quality not easily encoded 
in bytes. Take these examples:

Link: </styles.css>; rel="stylesheet"; is something an agent has little 
reason not to trust as the likelihood of it being true is high and the 
consequence of it being false is small. It is effectively an assertion 
by the resource creator that the stylesheet should be applied to it.

The following relationship is not so dissimilar.

Link: <http://cool_for_kids.example.org>; rev="recommends";

It's an assertion by the resource creator that a third party has 
recommended it for kids. A user agent would be wise to check with 
cool_for_kids.example.org before taking the assertion as true - but the 
direction doesn't alter the basic fact that the resource creator is 
making the assertion in both links.

To emphasise this a little, try these two:

Link: <foo.bar> rel="describedby";
Link: <foo.bar> rev="describes";

Here the rel/rev values are the inverse of each other so that in effect 
the same relationship is being asserted in two different ways and there 
is no obvious reason to put more weight in one rather than the other.

Most Links will use rel, not rev, but if we can clearly articulate the 
semantics as being equal and opposite, whilst making it clear that this 
says nothing about trust, then perhaps we can retain rev and leave the 
door open to future possibilities.

POWDER can live without rev in HTTP Link, but my gut feeling is that it 
should stay if possible.

Phil.

---

From: Mark Nottingham <[email-masked]>
Date: Sat, 6 Dec 2008 20:50:40 +1100

My own use case for this type of link is that I want to define an  
"invalidates" relation, whereby if it's a rel, it says "when this  
resource's state changes, it invalidates cached responses from that  
one", and whereby if it's a rev, it means "when that resource's state  
changes, it invalidates cached responses from this one."

Early experience with users mirrors what Ian and Roy are talking  
about; namely, that the distinction (a single letter) often confuses  
or is overlooked. I'm happy to define "invalidates" and "invalidated- 
by". I.e., while it's replacing an inbound link, it stands as an  
outbound link on its own (I'm not thrilled with the 'rev-*' solution).

Stepping back, though, I think the key question is whether the link  
framework (which is what the draft has become) should support inbound  
links. Right now, it's in an awkward state where it allows some  
applications (Atom being the most notable one, and it looks like HTML5  
is going to fall into this boat too) to only allow one type of link.

If we disallow inbound links (i.e., take them out of the prose, but as  
Roy says, still allow them in the syntax, for compatibility), we'll  
avoid this confusion and also gain some consistency between the  
serialisations. The only apparent loss is that of inbound links, and  
if I had to characterise the discussion I've seen so far, it's that  
their proponents think that they'd be *nice* to have, but I don't see  
anybody lying down in the road to save inbound links; indeed, when we  
re-added them, it was based on one or two people saying as much, IIRC.

Have I missed something? Otherwise it looks like we're moving towards  
taking 'rev' out (but still allowing it as a link-extension  
syntactically). Note that we're still going to update to say that rel  
links are resource->resource.

> lead to future confusion.

Since the re-casting of the draft to talk about a framework for typed  
linked generically, I think this is now indeed what is being said,  
with the caveat that others (including the Semantic Web world) can  
build on top of it if they wish. Given the uncertainty / confusion  
around this kind of link for the layman, I personally think that's  
appropriate.

Cheers,

---

From: Ian Hickson <[email-masked]>
Date: Sat, 6 Dec 2008 10:18:58 +0000 (UTC)

On Fri, 5 Dec 2008, Drummond Reed wrote:
> unambiguously asserting outbound links [...]

In HTML5, <link> can only assert outbound links. The rel="" attribute 
merely gives the kind of link (e.g. an external resource with particular 
processing requirements, or a hyperlink with certain semantics).

(We can't really define inbound links with HTML for two reasons: one is 
that we don't really have a way for the user agents to know that the links 
exist if they aren't outbound, since user agents tend to work on a 
per-document basis; the other is that even if we had a mechanism, we 
couldn't trust other documents to assert links on a document because it 
would be too heavily abused for spamming, phishing, and the like.)

On Sat, 6 Dec 2008, Phil Archer wrote:
> 
> It's the same basic argument used by the WHAT WG to decide whether to 
> keep or remove features in HTML 5. On the surface it's an attractive 
> one: if no one uses a feature properly, or worse, where a feature is 
> used it's generally used improperly, then it should probably be dropped. 
> The flaw with the argument is that it can only ever lead to a 
> diminishing feature set and imposes restrictions on current and future 
> use cases.

It demonstrably doesn't lead to a diminishing feature set, just look at 
the size of HTML5. :-)

It does result in features being trimmed, though. That's a good thing; it 
reduces featuritis and keeps the language focused on important things.

> is no obvious reason to put more weight in one rather than the other.

Right, it isn't clear to me what rev="" really brings to the table. As you 
show here, pretty much any "inbound" relationship can be described as an 
"outbound" relationship (in the extreme case by just minting a new value 
with "rev-" on the front and defining it as such).

> door open to future possibilities.

There are many, many features we could add with that justification. Is it 
enough? For HTML5, it hasn't been.

Anyway, I'm not trying to make any recommendations for HTTP or for the 
Link: header itself, just trying to give some background on what went into 
the current decision for HTML5. Hopefully that will help one way or the 
other.

Cheers,

---

From: Julian Reschke <[email-masked]>
Date: Sat, 06 Dec 2008 12:01:06 +0100

Mark Nottingham wrote:
> serialisations. The only apparent loss is that of inbound links, and if 
> I had to characterise the discussion I've seen so far, it's that their 
> proponents think that they'd be *nice* to have, but I don't see anybody 
> lying down in the road to save inbound links; indeed, when we re-added 
> them, it was based on one or two people saying as much, IIRC.
> 

So how would that work precisely?

If "rev" is taken out, the presence of a "rel" parameter becomes 
mandatory, right?

In that case, "rev" can not be introduced as an extension anymore -- 
either headers using "rev" would need to *also* contain a "rel" value to 
stay valid (breaking the intended semantics), or would need to be 
invalid in that they do not contain the "rel" parameter.

So it seems that "rev" can not be introduced as an *extension* at a 
later point, it would be a major change of the specification.

If "rev" is to be taken out, the spec should state that the semantics of 
links without "rel" is undefined, and that future specifications can 
change that.

That being said, I think the semantics of "rev" are clear enough; so I 
would recommend keeping it but maybe to add language discouraging its 
use for now.

BR, Julian

---

From: Mark Nottingham <[email-masked]>
Date: Sat, 6 Dec 2008 22:17:36 +1100

On 06/12/2008, at 10:01 PM, Julian Reschke wrote:

> Mark Nottingham wrote:
>> ...
>> If we disallow inbound links (i.e., take them out of the prose, but  
>> as Roy says, still allow them in the syntax, for compatibility),  
>> we'll avoid this confusion and also gain some consistency between  
>> the serialisations. The only apparent loss is that of inbound  
>> links, and if I had to characterise the discussion I've seen so  
>> far, it's that their proponents think that they'd be *nice* to  
>> have, but I don't see anybody lying down in the road to save  
>> inbound links; indeed, when we re-added them, it was based on one  
>> or two people saying as much, IIRC.
>> Have I missed something? Otherwise it looks like we're moving  
>> towards taking 'rev' out (but still allowing it as a link-extension  
>> syntactically). Note that we're still going to update to say that  
>> rel links are resource->resource.
>> ...
>
> either headers using "rev" would need to *also* contain a "rel"  
> value to stay valid (breaking the intended semantics), or would need  
> to be invalid in that they do not contain the "rel" parameter.

... or rel would need to no longer be required. In 2068, neither rel  
nor rev was required...

> If "rev" is to be taken out, the spec should state that the  
> semantics of links without "rel" is undefined, and that future  
> specifications can change that.

Yes, I think that's roughly where we're at.

> That being said, I think the semantics of "rev" are clear enough; so  
> I would recommend keeping it but maybe to add language discouraging  
> its use for now.

Hmm. Defining it but discouraging its use?

To be clear -- I don't have strong feelings one way or another.  
However, I do think that rev is one of the more tentative parts of the  
spec as it sits.

Cheers,

---

From: Julian Reschke <[email-masked]>
Date: Sat, 06 Dec 2008 12:32:34 +0100

Mark Nottingham wrote:
>> either headers using "rev" would need to *also* contain a "rel" value 
>> to stay valid (breaking the intended semantics), or would need to be 
> ... or rel would need to no longer be required. In 2068, neither rel nor 
> rev was required...

Indeed, nor in HTML4.

Interesting enough, HTML4 even says in 
<http://www.w3.org/TR/html4/struct/links.html#h-12.3.1>:

"12.3.1 Forward and reverse links

The rel and rev attributes play complementary roles -- the rel attribute 
specifies a forward link and the rev attribute specifies a reverse link.

Consider two documents A and B.

Document A:       <LINK href="docB" rel="foo">

Has exactly the same meaning as:

Document B:       <LINK href="docA" rev="foo">

Both attributes may be specified simultaneously."

(Note the last sentence)

>> If "rev" is to be taken out, the spec should state that the semantics 
>> of links without "rel" is undefined, and that future specifications 
>> can change that.
> 
> To be clear -- I don't have strong feelings one way or another. However, 
> I do think that rev is one of the more tentative parts of the spec as it 
> sits.
> ...

Understood.

We should consider the cost of both proposals. The point I'm trying to 
make is that re-adding "rev" at a later point of time is more complex 
than simply adding an extension. So my personal preference (not based on 
any real world use cases, I admit) is to keep it, but to explain the 
potential issues.

BR, Julian

---

From: "Drummond Reed" <[email-masked]>
Date: Sun, 7 Dec 2008 20:59:28 -0800

> On December 06, 2008 12:14 AM Roy T. Fielding wrote:
>

Now I'm confused. Julian Reschke in his message quoted from the HTML4 spec
<http://www.w3.org/TR/html4/struct/links.html#h-12.3.1>:

**********

(Note the last sentence)
***********

That matches my understanding of rel and rev - if resource A has a link to
resource B (a link being "an arc of some kind connecting the two resource
nodes"), a rel attribute on that link describes an arc from A to B, and a
rev attribute on that link describes an arc from B to A.

Do I have that wrong?

=Drummond

---

From: "Roy T. Fielding" <[email-masked]>
Date: Sun, 7 Dec 2008 23:52:16 -0800

> <http://www.w3.org/TR/html4/struct/links.html#h-12.3.1>:

Yes, that is wrong, though we can blame it entirely on the befuddled
HTML4.  I did not participate in HTML4 and largely ignore what it says
(especially in regards to HTTP and URI).  Contrast the above with the
definitions in RFC1866 (HTML2):

     REL
             The REL attribute gives the relationship(s) described by
             the hyperlink. The value is a whitespace separated list
             of relationship names. The semantics of link
             relationships are not specified in this document.

     REV
             same as the REL attribute, but the semantics of the
             relationship are in the reverse direction. A link from A
             to B with REL="X" expresses the same relationship as a
             link from B to A with REV="X". An anchor may have both
             REL and REV attributes.

Relationships are reversible.  Links (and <a href>), OTOH, are not;
their purpose is to define an explicit link and there is no implication
that the target has a corresponding explicit link even if the reverse
semantics are true.  If you think about what hypertext means and what
a browser actually does with links, it should be clear that the HTML4
definition is nonsense.

....Roy

---

From: Mark Nottingham <[email-masked]>
Date: Tue, 9 Dec 2008 23:18:38 +1100

Hi Roy,

That's an extraordinarily subtle distinction (and I still haven't  
thought through its impact if we act upon it).

Is your preference still to keep rev out of the spec?

I only hear Julian making an argument to keep rev, and it doesn't seem  
like an urgent one.

---

From: Yves Lafon <[email-masked]>
Date: Tue, 9 Dec 2008 07:39:49 -0500 (EST)

On Tue, 9 Dec 2008, Mark Nottingham wrote:

>
> Hi Roy,
>
> That's an extraordinarily subtle distinction (and I still haven't thought 
> through its impact if we act upon it).
>
> I only hear Julian making an argument to keep rev, and it doesn't seem like 
> an urgent one.

My understanding of rev is also that it reverse the relationship type, not 
the link, or the authority doing the claim. If we get rid of rev, people 
will have to define the two ways (like "bigger" _and_ "smaller", instead 
of just "bigger"). Not really a big issue.
So if you think it clarifies things, then drop rev.

-- 
Baroula que barouleras, au tiéu toujou t'entourneras.

         ~~Yves

---

From: "Roy T. Fielding" <[email-masked]>
Date: Tue, 9 Dec 2008 13:37:03 -0800

> through its impact if we act upon it).

Well, <http://tools.ietf.org/html/draft-nottingham-http-link- 
header-03> says

    Each link-value MUST have at least one "rel" or "rev" parameter  
whose
    value indicates the relation type.  If the "rel" parameter is used,
    it indicates that the link's direction for that relation type is
    outbound; if the "rev" parameter is used, the given relation type's
    direction is inbound.

which is wrong.  The distinction isn't subtle if you think about what
Link defines and how agents are supposed to act on that information.

We should remove the mistaken usage of "outbound" and "inbound" and
the definition of rev should be in section 4 (and deprecated because
experience has shown that reversing semantics is less understandable
by people than choosing inverse relation names).

> Is your preference still to keep rev out of the spec?

No, my preference is to leave it in but deprecate its use.

Also, I note the following:

    If the relation-type is a relative URI, its base URI MUST be
    considered to be "http://www.iana.org/assignments/relation/", and  
the
    corresponding value MUST be present in the link relation registry.

A MUST here requires that implementations look-up the registry to
confirm the entry.  Nobody wants that.  There is no need for these
requirements -- the base is a statement of fact, and the semantics
are necessarily concluded from that fact.  It should just say:

    The URI-reference(s) within relation-type are parsed relative to
    the base URI of <http://www.iana.org/assignments/relation/>.
    A relation-type value that is not an absolute URI [RFC3986] is
    therefore presumed to be a relative reference to the corresponding
    relation within the IANA relation registry [cite].  If no such
    registered relation exists or the reference is malformed, then
    the relation is undefined.  Implementations SHOULD ignore relation
    names that they do not understand or have no need to process.

....Roy

---

From: Mark Nottingham <[email-masked]>
Date: Wed, 10 Dec 2008 10:35:31 +1100

> No, my preference is to leave it in but deprecate its use.

I think I agree, as long as we can illustrate it well.

The RDF folks should note, though, that REV isn't the link they're  
looking for, AIUI.

Agreed.

I'll start work on -04.

---

From: Mark Nottingham <[email-masked]>
Date: Wed, 10 Dec 2008 16:31:49 +1100

It's proving difficult to define rev in a meaningful way that's  
specific to the Link header without accommodating it in section 4 (or  
alternatively, directly in the registry, although I'm not terribly  
fond of going in that direction), especially since there are  
apparently conflicting uses of it in HTML2 and HTML4.

My inclination is to accommodate it syntactically as a link-extension  
and note the problem in the Using Link in HTML4 appendix, but not to  
try to define its semantics. Is this what you had in mind? Otherwise,  
could you (or someone else) please provide some straw-man text to  
discuss?

---

From: Mark Nottingham <[email-masked]>
Date: Wed, 10 Dec 2008 16:37:35 +1100

BTW, this is the text I have currently;

In section 5:

       <t>Normally, the relation type of a link is conveyed in the  
"rel" parameter's value. The "rev" parameter has also been used for this
	purpose historically by some formats, and is included here for  
compatibility with those uses, but its use is not encouraged nor defined
	by this specification.</t>

In the HTML appendix:

	  <t>HTML4 also has a "rev" parameter for links that allows a link's  
relation to be reversed. The Link header
		has a "rev" parameter to allow the expression of these links in HTTP  
headers, but its use is not encouraged,
		due to the confusion this mechanism causes as well as conflicting  
interpretations among HTML versions.</t>

---

From: Julian Reschke <[email-masked]>
Date: Wed, 10 Dec 2008 10:28:11 +0100

Mark Nottingham wrote:
>         has a "rev" parameter to allow the expression of these links in 
> HTTP headers, but its use is not encouraged,
>         due to the confusion this mechanism causes as well as 
> conflicting interpretations among HTML versions.</t>
> ...

OK, it seems I'm missing something here. Could somebody explain to me, 
what the conflicting interpretations are, and which we prefer (and why?)?

HTML2 (<http://tools.ietf.org/html/rfc1866#section-5.7.3>):

     REL

     REV

HTML4 (<http://www.w3.org/TR/html4/struct/links.html#rev-link>):

   12.3.1 Forward and reverse links

   The rel and rev attributes play complementary roles -- the rel
   attribute specifies a forward link and the rev attribute specifies a
   reverse link.

   Both attributes may be specified simultaneously.

Best regards, Julian

---

From: Mark Nottingham <[email-masked]>
Date: Wed, 10 Dec 2008 20:51:07 +1100

I though I had it, but I don't; Roy's explanation made sense, but his  
interpretation of HTML2 links -- AIUI -- contradicts the example in  
HTML2's REV definition.

Roy?

On 10/12/2008, at 8:28 PM, Julian Reschke wrote:

>
> Mark Nottingham wrote:
>> ...
>>      <t>HTML4 also has a "rev" parameter for links that allows a  
>> link's relation to be reversed. The Link header
>>        has a "rev" parameter to allow the expression of these links  
>> in HTTP headers, but its use is not encouraged,
> OK, it seems I'm missing something here. Could somebody explain to  
> me, what the conflicting interpretations are, and which we prefer  
> (and why?)?
>

---

From: Yves Lafon <[email-masked]>
Date: Wed, 10 Dec 2008 06:01:15 -0500 (EST)

On Wed, 10 Dec 2008, Julian Reschke wrote:

> OK, it seems I'm missing something here. Could somebody explain to me, what 
> the conflicting interpretations are, and which we prefer (and why?)?
>

In that case, it's not a reversed link, but still a normal forward link, 
but it expressed a reversed relationship.
A: link rel="bigger than" B
is the same relation as
B: link rev="smaller than" A

Same relation, but different links (and different authority claiming the 
relationship between both A and B).
In the HTML4 example, it's reverse and forward links, so the links are 
supposed equivalent, so not only the relation is equivalent, but also the 
link.
I prefer far more the "relationship equivalence" as defined in HTML2.

         ~~Yves

---

From: "Roy T. Fielding" <[email-masked]>
Date: Wed, 10 Dec 2008 13:19:30 -0800

On Dec 10, 2008, at 3:01 AM, Yves Lafon wrote:

>>>         has a "rev" parameter to allow the expression of these  
>>> links in HTTP headers, but its use is not encouraged,
> In that case, it's not a reversed link, but still a normal forward  
> link, but it expressed a reversed relationship.
> Same relation, but different links (and different authority  
> claiming the relationship between both A and B).
> In the HTML4 example, it's reverse and forward links, so the links  
> are supposed equivalent, so not only the relation is equivalent,  
> but also the link.

Yep.  The HTML2 definition is correct but easily misunderstood because
"expresses the same relationship" does not mean "is the same link".
What it should have said is that rev reverses the relationship  
semantics,
e.g., rev=made is equivalent to rel=creator.  Both define a link from  
A to B.

....Roy

---

From: Mark Nottingham <[email-masked]>
Date: Thu, 11 Dec 2008 10:54:51 +1100

Right, OK; that's the subtle bit. Julian, make sense?

On 11/12/2008, at 8:19 AM, Roy T. Fielding wrote:

> e.g., rev=made is equivalent to rel=creator.  Both define a link  
> from A to B.
>
> ....Roy
>

---

From: Julian Reschke <[email-masked]>
Date: Thu, 11 Dec 2008 09:44:33 +0100

> Right, OK; that's the subtle bit. Julian, make sense?

It *is* about trust, right?

(1)  A -rev-> B

implies the same relation as

(2)  B -rel-> A

*but* it's A making the statement; just because A makes a claim about a 
rev link doesn't necessarily that B agrees about that (and will expose 
the link as well).

So the problem with the language in HTML4 is that it uses the term 
"reverse link" instead of "reverse (link) relation"?

BR, Julian