Re: Signalling to proxies

Thanks Phil.

A small footnote:

 > 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


This is all very well when the pages of the desktop site and the pages 
of a mobile site map in some kind of way, but Best Practice would seem 
to indicate that they very often shouldn't. I think that as you go on to 
say, it's better to deal with pragmatics, especially when the theory is 
itself up for grabs.

Jo


On 03/11/2008 16:03, Phil Archer wrote:
> 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.
>>>
>>>
>>
> 
>

Received on Tuesday, 4 November 2008 01:01:26 UTC