Re: [RFC] Information headers in HTTP

On Tuesday 19 June 2007, Stefanos Harhalakis wrote:
> Thank you for your reply. Please have a look at this:
>
> http://lists.kde.org/?l=kfm-devel&m=118223261027319&w=2
>
> I believe that this answers almost everything, except from the last 
one:
> >    - All headers that you add to HTTP cause overhead. The time zone
> > is rarely needed, but it takes up bandwidth all the time. (The same
> > goes for anything else you might want to know about the client
> > side:
> >      name of user, OS, amount of RAM, free disk space, whether
> >      there is a printer, name of the user's mother...)

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.

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. 

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

>
> This is the main reason that the Information Headers were suggested.
> This way the HTTP protocol will be able to be extended and there will
> be no overhead unless it is required.

And Bert and I are telling you that there are already different 
frameworks out there that tell how to do it.
>
> > Timezone is in the P3P Base dataschema for a good reason as it can
> > be relevant for privacy. It is in the variable category as it is
> > most privacy relevant together with other data transmitted. I think
> > there are better ways to transmit or use timezone data, so having
> > them in the http header doesn't look like the best idea. CC/PP or
> > UAProf would be the preferred methods. Those can also be
> > complemented with P3P to know what the data is used for etc...
>
> What I'm proposing may be able to be regulated by P3P. As far as I
> understand, P3P only describes the data the server collects and their
> intended usage. The proposal clearly says that clients must not send
> information without asking or letting the user prevent it.
>
> Does the proposal conflict with the P3P?

If TZ is sent with every GET, it conflicts with the safezone 
requirements of P3P. This is solved in CC/PP
http://www.w3.org/TR/CCPP-trust/
http://www.cs.kent.ac.uk/pubs/2002/1553/

>
> I'd like to clarify that the Timezone header[4] was the original idea.
> The information headers are another (distinct) one. If accepted, the
> timezone information could be sent using the information headers
> on-demand. Thus the two of them should not be confused.

Please keep in mind that since 1997 a _lot_ of people tried to extend 
HTTP and failed (including W3C's HTTP-NG). So the suggestion is that 
the needed metadata passes by a different mechanism. You can try to 
change HTTP, but I do not give you high probability of success.

1.http://www.w3.org/Protocols/HTTP-NG/Activity.html
2.http://www.ietf.org/html.charters/geopriv-charter.html
3.http://www.w3.org/Mobile/
4.http://www.ietf.org/internet-drafts/draft-sharhalakis-httptz-02.txt

I hope that helps you understand the resistance :)

Best, 
-- 
Rigo Wenning            W3C/ERCIM
Staff Counsel           Privacy Activity Lead
mail:rigo@w3.org        2004, Routes des Lucioles
http://www.w3.org/      F-06902 Sophia Antipolis