[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kfm-devel
Subject:    Re: [RFC] HTTP timezone
From:       Stefanos Harhalakis <v13 () priest ! com>
Date:       2007-06-13 14:46:07
Message-ID: 200706131746.08127.v13 () priest ! com
[Download RAW message or body]

On Wednesday 13 June 2007 10:46, Bert Bos wrote:
> I think this is not a good idea, for more or less the same reasons
> cookies, Referer and User-Agent headers are not good ideas, viz.:
>
>    - The information is privacy sensitive. The server has no right to
>      this information, unless the user explicitly wants to give it.

That's what the draft says in the security considerations section.

>    - The identifier of a page is the URL. That's what you store in a
>      bookmark, what you copy and paste, print on a billboard or send to
>      friends. But, if the page depends on other headers than the URL,
>      such bookmarks fail.

Not exactly: Accept-Language, Cookies, Referrer, Javascript, browser 
identifier, frames support plus all dynamically generated web pages.

>    - I travel a lot, use computers in other countries than where I am
>      physically, and I don't want to know what time zones all those
>      machines are configured for. I'd hate to get different content just
>      because I use one device rather than another.

You will only see times in the local time of each place. Of course you can 
decide not to change the timezone of your laptop (if you use one) and keep 
the same timezone settings.

>    - If a page's content can differ based on the user's time zone, the
>      user should be able to choose what time zone he wants the
>      information for. He may want it for a different time zone than where
>      he currently is, and he may want to try out different ones.

I believe that's an implementation/client/interface issue. 

>    - The header is redundant. Everything on the client-side that might
>      influence the content of a page can be (and should be) in the URL or
>      in the authentication headers (in case the content is protected).

Already answered (I think).

>    - I don't know (and I'm not online to check), but if time zone
>      information is currently not a category in P3P, it would need to be
>      added there first.

I was not aware of P3P but why not? This will not have anything to do with 
this draft.

>    - There are generic techniques for client profiles that don't need a
>      new header for every new piece of client-side information: see CC/PP
>      and UAProf. (I think content should *not* depend on client-side
>      information other than the URL, but these techniques exist, mostly
>      because of underpowered mobile phones, so better to re-use existing
>      techniques than add new ones.)

I didn't knew about CC/PP and UAProf either. After looking at them a bit, I'd 
like to ask you whether you are sure that they are capable of providing this 
information?

>    - 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 cannot argue with that. Still I strongly believe that this is something that 
the Internet needs. Time information is a core part of all of our 
communications just like the language is. As a web user, a web application 
programmer and a sysadmin I'm 100% convinced that correct time representation 
is required. I've experienced this need for the first time about 4 years 
before now and all this time I could really use this option.

[prev in list] [next in list] [prev in thread] [next in thread] 

Configure | About | News | Add a list | Sponsored by KoreLogic