Re: Signalling to proxies

Rotan and all,

OK, here's my best shot at this and, if you'll allow me, I'd like to 
rephrase the question slightly (using some of the HTTP/Web arch jargon 
I've picked up by taking part in this discussion).

You want to be able to look at URI u1 and discover that u2 offers a 
different representation of that resource. As Rotan recognised, that 
breaks best practice right there - if it's the same resource, the best 
solution is to have the same URI and use content negotiation (conneg) to 
get the right representation. But... that was worked out in the day when 
the choices were between things like XHTML and plain text or whatever. 
Here you'd have the same MIME type for both representations.

So let's stop worrying too much about theory and see what might work in 
practice. You want a link from a resource to point to an alternative 
representation (mobile cf. desktop for example). HTTP Link begins to 
look attractive since:

1. You don't need to parse the resource
2. It works for everything, not just HTML
3. Like HTML, you can define your own relationship types.

Yes you can.

Let's assume that u1 is http://example.com/me.html and u2 is 
http://example.com/mobile/me.html

Here's a possible HTTP Link Header that could be returned by doing an 
HTTP HEAD or GET on u1 that is conformant with the latest draft [1] of 
Mark Nottingham's work on this.

Link: <http://example.com/mobile/me.html>; 
rel="http://reltypes.mobi/mobile" type="text/html";

The rel type is defined by the URI - in this case one I've made up on 
the .mobi TLD. HTML 5 also supports URIs as values for rel. It gets a 
little more hazy when you want to register a short name - we're working 
on that with rel="describedby" soon to be a guinea pig test case at IANA 
but whether through that route or another, the consensus is that it 
shouldn't be too hard to do.

This should get round the limitation that Jo points out, that HTTP link 
doesn't support @media types.

Is POWDER a good vehicle for this kind of thing?

Hmmm... let me see. Well, it 's good for saying that everything on 
example.com/mobile is mobileOK and the converse of that is that if you 
want mobileOK resources then example.com/mobile is a good place to look. 
Saying that for every u1 there is a u2 that has '/mobile/' inserted at 
the beginning of the path is more tricky. You can't do it without some 
processing - and one way that has something like an intuitive feel to it 
(at least among techies) might be to use regex syntax.

<dr>
  <iriset>
    <includehosts>example.com</includehosts>
    <excludepathstartswith>/mobile/</excludepathstartswith>
  </iriset>

  <descriptorset>
    
<ex:hasmobilealt>s/http:\/\/www\.example.com/(.*)/http:\/\/example\.com\/mobile/$1/</ex:hasmobilealt>
  <descriptorset>
</dr>

This could be simplified if we didn't worry about hosts in the 
substitution. An optimised system could well achieve this end without 
actually using a reg ex engine of course. You'd need a vocabulary that 
defined what hasmobilealt was and how to process it but that's not 
insurmountable. And, of course, it would be independent of POWDER or 
anything else, it would just be a vocabulary. Of course, POWDER allows 
you to chop your content up into sections where the modified URI will 
and won't work, give it different substitution rules etc.

Linking from one representation to another, or metadata about it, is a 
topic that has filled hard drives with e-mail threads (Tag issues, HTTP 
303, fragment identifiers and all that) - see some collected stuff at 
[2] for example. It's a topic that goes beyond any one use case.

Whether you find POWDER useful or not, please, please don't go for a 
well known location!

Phil




[1] http://tools.ietf.org/id/draft-nottingham-http-link-header-02.txt
[2] http://esw.w3.org/topic/LinkHeader


Rotan Hanrahan wrote:
> All very enlightening, thank you, and I look forward to the detailed 
> response on Monday.
>
> Of course, what I'm interested in hearing is how to signal a site's 
> adaptability preferences, in the absence of a WKL (Well Known 
> Location) for that descriptor. This is the "discoverability" question. 
> Obviously during a HTTP interaction there is the ability to reference 
> the descriptors from within the markup, so discovery is not a problem. 
> Prior to such interaction is the challenge. I cited robots.txt not 
> because I believe it to be a technically good solution, but because it 
> is already in use and is easy to adopt. Any alternative technique 
> should be equally easy to adopt, while avoiding the challenges of 
> scalability and the need for "magic".
>
> The background to my questioning in this matter is basically one of 
> trying to establish for our many customers the current situation and 
> likely future of the relationship between content providers and 
> delivery intermediaries. The work of the CT task force is encouraging, 
> and will me more so if industry adoption follows. However, the fact 
> that we have to lean on heuristics in many cases is not so 
> encouraging, so I am trying to establish if the immediate future can 
> be improved through some deterministic means. POWDER presents one such 
> possibility, but ease of adoption will be critical. Our customers 
> already know of established practices such as robots.txt, and despite 
> its weaknesses they feel on balance that the return on investment is 
> great. A similar investment in a POWDER DR for their site would 
> presumably also return good dividends, if only we could figure out the 
> technical details (while keeping it simple).
>
> I make no apology for constantly emphasising the need for simplicity.
>
> Looking forward to Phil's enlightening comments on Monday.
>
> ---Rotan.
>
> PS Much obliged to Jo and Phil for their willingness to thrash this 
> one out.
>
>
>
> From: Phil Archer
> Sent: Fri 31/10/2008 16:23
> To: Jo Rabin
> Cc: Rotan Hanrahan; Francois Daoust; public-bpwg-ct; 
> public-powderwg@w3.org
> Subject: Re: Signalling to proxies
>
>
> I will reply properly to this thread on Monday (I'm not really working 
> today) but just a quick note on the well known location issue. The 
> problem is one of scalability. If you have a WKL for robots.txt, and 
> one for the P3P policy, and one for the CT guidelines and, and, and... 
> where does it stop? Does every bit of metadata have to have its own 
> location? How about a WKL for stylesheets? And another for RSS feeds, 
> or saying that www.example.com/mobile is where you will always find 
> the mobile-friendly representation? In such a situation there is no 
> linkage, only foreknowledge and a bit of magic involved.
>
> In this context, it was made clear to me that a WKL would not be an 
> acceptable solution for POWDER docs. The line in the charter: "This 
> last area is a vital aspect of the POWDER model but has wider 
> applicability, for example in the Evaluation and Report Language 
> [EARL], P3P's Policy Reference File [P3P] and in the functionality 
> offered by robots.txt." is a reference to this (if rather oblique).
>
> Phil.
>
> Jo Rabin wrote:
>>
>> I seem to recall that there was a discussion about specifically being 
>> chartered to find a replacement for robots.txt - maybe it never made 
>> it into the charter in the end.
>>
>> Either way I think the point is that robots.txt is to be found in the 
>> root of a Web site, but since we don't know what a Web site is (in 
>> terms  of determining from two URIs whether they belong to the same 
>> Web site or not) there isn't a clear way of determining what the URI 
>> of the root is.
>>
>> Jo
>>
>> On 31/10/2008 15:53, Rotan Hanrahan wrote:
>>> It would be interesting to see what arguments were made to say that
>>> well-known locations were "bad practice", and what criteria were 
>>> offered
>>> to assess whether an alternative would be "better". To me, 
>>> simplicity is
>>> a pretty good criterion.
>>>
>>> I went searching for the possible reference to this "concern" in the
>>> POWDER charter and linked material, but didn't find anything. Perhaps I
>>> need to look harder.
>>>
>>> ---Rotan.
>>>
>>> -----Original Message-----
>>> From: Jo Rabin [mailto:jrabin@mtld.mobi] Sent: 31 October 2008 15:03
>>> To: Rotan Hanrahan
>>> Cc: Francois Daoust; public-bpwg-ct; public-powderwg@w3.org
>>> Subject: Re: Signalling to proxies
>>>
>>>  > Thanks for the P3P reference, Francois. It further supports the
>>>  > viability of the practice of "well known locations".
>>>
>>> IIRC one of the points made to the proto-POWDER group (might even be 
>>> in the POWDER charter, actually) was that well known locations are 
>>> regarded
>>>
>>> as "bad practice" and that they needed to find some other mechanism.
>>>
>>> Jo
>>>
>>> On 31/10/2008 14:56, Rotan Hanrahan wrote:
>>>> From bitter experience, there are two rules to follow regarding the
>>>> creation of vocabularies:
>>>>
>>>> 1. You've underestimated the effort, so increase your estimate.
>>>> 2. See 1.
>>>>
>>>> To re-emphasise, I'm not suggesting that either groups copied on this
>>>> message take on board the task of addressing this issue. Nevertheless,
>>>> comments on the merits, demerits, feasibility and challenges are very
>>>> welcome, and hopefully will encourage someone somewhere to actually do
>>>> some work on it.
>>>>
>>>> Thanks for the P3P reference, Francois. It further supports the
>>>> viability of the practice of "well known locations".
>>>>
>>>> Good luck with the race to Rec (to both groups!).
>>>>
>>>> ---Rotan.
>>>>
>>>> -----Original Message-----
>>>> From: Francois Daoust [mailto:fd@w3.org] Sent: 31 October 2008 14:48
>>>> To: Rotan Hanrahan
>>>> Cc: Jo Rabin; public-bpwg-ct; public-powderwg@w3.org
>>>> Subject: Re: Signalling to proxies
>>>>
>>>> Rotan Hanrahan wrote:
>>>> [...]
>>>>> Yes, I accept that the charter prohibits the creation of new
>>>> technology,
>>>>> and I openly admit that I placed the idea into the CT forum mainly
>>>>> because the audience is right, despite the charter limitation. I
>>>> copied
>>>>> the POWDER group because I hope that this use case will get some
>>>>> prominence, and maybe through a formalised example it might actually
>>>> be
>>>>> adopted. After all, Robots is not an official standard and look how
>>>>> successful it has been.
>>>> I think there are three separate things here:
>>>>
>>>> 1/ the use of POWDER, and POWDER is indeed not an existing technology
>>>> yet.
>>>>
>>>> The CT Task Force chose to mention the use of POWDER in the "Scope for
>>>
>>>> Future Works" appendix for that reason. We felt (how naive one can 
>>>> be sometimes ;)) that going to Rec would be quick and easy and that 
>>>> we would have been slowed down by a dependency on POWDER. I'm not 
>>>> quite sure today that the Content Transformation Guidelines will 
>>>> beat POWDER
>>>
>>>> in the race to REC, but I don't think we should revisit that 
>>>> decision anyway.
>>>>
>>>>
>>>> 2/ the definition of a core vocabulary that a server could use in 
>>>> its POWDER file(s) to communicate with a content transformation 
>>>> proxy. I guess there is "new technology" and "new technology", and 
>>>> that one
>>> could
>>>> argue that a vocabulary is not exactly a new technology.
>>>>
>>>> Again, the CT Task Force decided against it because it still looks
>>> like
>>>> new technology.
>>>>
>>>> However, were this exercise be done and the results brought to our 
>>>> knowledge, I think we could reasonably (at least try to) 
>>>> incorporate them in the guidelines without triggering an apocalypse.
>>>>
>>>> That's just my personal take on this. I still think we, the CT Task 
>>>> Force, should not work on that. My real fear is that defining and 
>>>> agreeing on a core vocabulary is not an easy exercise at all. Am I too
>>>
>>>> pessimistic?
>>>>
>>>>
>>>> 3/ the definition of a well-known location to place a POWDER file. 
>>>> Probably not a big deal if it's not standardized right away,
>>> especially
>>>> since we may still use the Link element for the time being. I note the
>>>
>>>> notion of well-known locations is used by the P3P spec for example:
>>>> http://www.w3.org/TR/2002/REC-P3P-20020416/#Well_Known_Location
>>>>
>>>> Francois.
>>
>>
>


-- 

Please note my new e-mail address. My ICRA/FOSI e-mail addresses will not function after the end of November.

Phil Archer
e. phil@philarcher.org
w. http://philarcher.org/

Received on Monday, 3 November 2008 16:04:17 UTC