Re: LC-2009, LC-2010, LC-2011: Link element

Jo Rabin wrote:
>>  Now I see what you mean. I don't like the example as it re-introduces
> And then again, I'm sorry to say that I don't much like the idea of
> 
> <link rel="alternate" media="screen"
>     href="http://example.mobi?media=screen" />
> 
> because I think that dereferencing that URI would result in a 301 
> redirect to http://example.mobi because that is the canonical URI and 
> you would quite definitely want to use that one as a bookmark.
> 
> Also although trivial to implement, this doesn't seem to me to be an 
> established convention. So I think it would be hard to recommend it as 
> "best practice".

Well, it wouldn't result in a 301 redirect in practice because 
dereferencing http://example.mobi would then return the handheld version 
of the document in our example. Linking back to the canonical URI from 
the representation returned by http://example.mobi?media=screen can be 
done using existing mechanisms:
  <link rev="alternate" href="http://example.mobi" />
... using "rev" instead of "rel". But there again, although trivial to 
implement, that's a non-existing practice, and no browser would bookmark 
the canonical URI in that case.

Anyway, let me try to reformulate the whole thing once more, because I 
fear I still don't grab something in there. Sorry for the lengthy mail.


What we know / What is imposed
-----
Three cases in content adaptation:
1/ only one resource URI for all the representations
2/ one URI per representation and the server redirects the user to the 
appropriate URI
3/ a mix of 1/ and 2/: one URI per class of representations (whatever 
that class may be)

The choice of representations may be a consequence of the HTTP headers 
used for the request or the result of a direct user choice, but I don't 
think that makes a hell of a difference for our needs.

The classes that may be advertised through linking mechanism are limited 
to the media types available.

According to the RFC 3986 section 4.4, the only thing one can do with 
the linking mechanism is:
- advertise what *this* particular representation of the resource's URI 
is about
- advertise that other representations are available at *other* URIs 
(cases 2 and 3 above)

The linking mechanism in itself cannot explain that the representation 
was returned as a consequence of a user's choice or as a consequence of 
content negociation based on HTTP headers.

The Vary HTTP header tells anyone on the HTTP line that there are 
multiple representations available at a given URI based on e.g the 
User-Agent header, the Accept header, and so on.


What we want for CT
-----
We basically want to extend the linking mechanism to 1/ above, and be 
able to say:
- this is the screen representation of this resource
- I also have a (bag of) handheld representation(s) of this resource at 
the same URI

... or the exact opposite:
- this is the handheld representation of this resource
- I also have a (bag of) screen representation(s) of this resource at 
the same URI


Why we want that for CT
-----
That's precisely what I don't really understand.
What can the different actors do with this info?

Regular user agents can't do anything with that, since there is no way 
to know how the other representations may be retrieved (same URI)

CT-proxies could use that information in two ways:
  a) to detect that they incorrectly changed the values of HTTP headers 
whereas they shouldn't have. Using the Vary HTTP header should be enough 
to carry the same info. It's not semantically equivalent: a response 
served with a "Vary: User-agent" HTTP header does not entail that there 
is a handheld representation of the resource available, but it should 
trigger the original-http-headers mode of CT-proxies, which is what we want.
  b) to know that they could "try" with other HTTP headers values, but 
that's the same as the above point on user agents: there is no way to 
tell how to tweak the request to retrieve the other representations.


In an HTML page:
- the absence of any link element doesn't tell anything
- the presence of a:
    <link rel="alternate" media="screen" href="" />
... is a clear flag that says "I'm a screen representation of this 
resource". It's also a good clue that there exists different 
representations, even when there isn't any other link. That seems to be 
a good "warning" signal.
- the presence of a:
    <link rel="alternate" media="handheld" href="" />
... is another clear flag that says "I'm a handheld representation of 
this resource".
- the presence of a:
    <link rel="alternate" media="handheld" 
href="http://example.mobi?media=handheld" />
... says there is a handheld representation available at the given URI, 
but one may even consider this last use as being useless, because the 
server should

In short, from a narrow CT-proxy perspective, the real use is that of a 
screen/handheld flag, and the presence of any flag is a good clue that 
there are probably other representations available at the same URI that 
match other media types. Mentioning the last use in the guidelines 
simply is a way to have belt and braces in case the content provider 
wants to follow the TAG's advice and link its representations together.


Viewed from a global architectural point of view
----
The solution detailed in the TAG finding is not extraordinary 
well-suited to the mobile world, where there are typically many 
representations available, dynamically generated. The overhead to link 
the representations together is simply too much. The canonical 
representation cannot link to the other ones. And the granularity of the 
classes that may be defined is not enough anyway. We raised these points 
to the TAG.

Besides, it doesn't work properly, because in practice no existing user 
agent currently manages the link back to the canonical URI correctly for 
bookmarking purposes.


That's a pity, but I still don't see the need to create new mechanisms 
for Content Transformation uses.

Francois.

Received on Friday, 19 September 2008 16:32:31 UTC