Re: [RFC] Information headers in HTTP

On Wednesday 20 June 2007 11:44, Rigo Wenning wrote:
> I think you're missing to answer the point about CC/PP and UAProf.
>
> Let me say that there is still the HTTP NG[1] proposal where you would
> extend HTTP with namespaces. But this was never implemented AFAIK.
> Secondly, CC/PP is exactly developed for your use cases as timezone and
> location is part of the device properties. Including it plain into HTTP
> does not make too much sense IMHO as it ignores the work going on in
> geopriv[2] e.g. and also in the Mobile Web Initiative[3] that are all
> supposed to streamline device properties between the server and the
> client.

  OK. I just read part of CC/PP and I believe that I finally understand what 
exactly you're talking about. Thanks a lot for your comments! You're right. 
CC/PP does or is able to do many (or all) of the things I'm describing.

  Still I have some questions regarding CC/PP. As far as i understand, CC/PP 
currently describes mostly constant user agent capabilities. There are 
properties that depend on the user and not on the client. For example, age, 
sex, name etc. Is CC/PP apropriate for transfering this kind of information?

  Also, CC/PP says:
"It does not define how the profile is transferred, nor does it specify what 
CC/PP attributes must be generated or recognized". 
Is there a document that describes how CC/PP should be transfered when using 
HTTP? (I didn't find anything)

  As far as i understand it, it dictates that clients must always send a 
complete record that includes their data. What I'm proposing (with 
Information Headers) is a method for the server side to request specific data 
from a visiting client. The client will then be able to respond with those 
data after asking the user. This may include all sort of information (common 
or not) that a person enters when visiting various web pages (Name, Address, 
Credit Card number, Country, Telephone, Organization, etc). It is even 
possible to have an element that requests a CC/PP profile (I said profile 
twice?).

  I believe that the main difference is that the server side will be able to 
request further client information on demand instead of letting the client 
guess what it is required.

> So just inventing a new HTTP Header for every imaginable property or
> metadata (here timezone) that one could imagine in this world does not
> scale, is therefor not practical and is also at odds with the
> underlying architecture. Bert wanted to be somewhat diplomatic about
> it.

  I agree with that and that's why I suggested the Information Request 
(without understanding the CC/PP). As for the diplimacy, please... be rude... 
educate me... brutaly and in public ((c) someone from the LKML) :-)
Personaly, I like/prefer straight answers...

> So the suggestion is that you dive into either the suggestion of
> conveying the TZ in the URI itself or look into CC/PP.

  OK. Lets postpone the Timezone issue. Any comments regarding the Information 
Request?

Received on Wednesday, 20 June 2007 17:20:08 UTC