RE: Signalling to proxies

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/