Subject: [RFC] HTTP Information Request

From: Stefanos Harhalakis <[email-masked]>
Date: Sat, 16 Jun 2007 14:27:16 +0300

Here is a more formal proposal for the 'Client Information' message I've 
sent 3 days before. After examining the 'Timezone Information' feedback I 
came to the conclusion that we need something like this. 

  This draft is not submitted yet since I would like to first send it here. I 
hope that you'll be interrested in this and that you'll find it usefull.

---

From: Stefanos Harhalakis <[email-masked]>
Date: Tue, 19 Jun 2007 21:12:23 +0300

On Saturday 16 June 2007, Stefanos Harhalakis wrote:
>   This draft is not submitted yet since I would like to first send it here.
> I hope that you'll be interrested in this and that you'll find it usefull.

  I'm sorry if I'm annoying you by insisting on this but I really want to know 
whether the not-a-single-reply means 'go-on' or 'that's a bad idea'...

---

From: Henrik Nordstrom <[email-masked]>
Date: Tue, 19 Jun 2007 21:41:22 +0200

> whether the not-a-single-reply means 'go-on' or 'that's a bad idea'...

For one thing you posted the message on a Saturday, and it's only
Tuesday today..

Personally I am missing a list of information tokens clients should be
expected to support.  We have talked about the timezone. What else do
you have in mind that this mechanism should be used for. It's a bit hard
to discuss the mechanism without a few use cases to back it up..

Also see the negotiation a little problematic as it relies on the client
keeping track of prior preferences of the server, but it's no worse than
cookies so I don't mind much.. authors using the feature just have to
learn how to get it negotiated proper.

Regards
Henrik

---

From: Stefanos Harhalakis <[email-masked]>
Date: Tue, 19 Jun 2007 23:14:33 +0300

> For one thing you posted the message on a Saturday, and it's only

  You're right... Sorry :-)

> to discuss the mechanism without a few use cases to back it up..

  I believe such an option may partially change the way web works. Some 
information I think of:

* Timezone
* Location
* Sex
* Interests
* Screen/window size
* Mood :-)
* Age/DoB
* Computer-related Technical Level
* Accessibility requirements
* Anything that can personalize a page or a service, or automate transactions

  Even thought this may seem as providing excessive information, I believe 
that one will be able to perform some common tasks without having to create 
accounts for storing personal preferences.

  The applications of this can be very usefull to google for example to 
improve its targeted advertisements, to online shops to offer better 
suggestions, to web applications to display different error messages and 
become more accessible etc...

  It will also alleviate the HTTP from possible unneeded future header 
additions (at least the Timezone header :-) and reduce the transmited headers 
since they will need to be send on-demand. Even the Accept-Language could be 
changed.

> learn how to get it negotiated proper.

  Since the support of it is completely optional I don't believe that it is a 
problem.

  Once again, thanks a lot for replying!

---

From: "Larry Masinter" <[email-masked]>
Date: Thu, 21 Jun 2007 10:27:33 -0700

This proposal seems to fall into the same trap that most proposed
HTTP extensions fall into: there's no motivation to deploy this
in clients because most servers don't support it, and no motivation
to deploy this in servers, because most clients don't support it.

Unless you have a better story for how this will get deployed,
its mainly an academic exercise.

Things might have been different when HTTP 1.0 or 1.1 were
being developed, but that's not the case now.

That's the general problem. The specific problem with this
is that it's a kind of reverse content negotiation, and many
of the features you're thinking of (e.g., screen/window size,
accessibility requirements) fit into the framework of media
negotiation, and the others might, with a bit of stretching
(e.g., "timezone" as a media feature meaning "content
appropriate for someone in the named timezone", or, more
likely, locale.)  In most cases, we talked about the combination
of client characteristics, capabilities and preferences,
which seems to cover almost all of your tokens.

There's been a great deal of work in this area, most of
it not deployed (for reasons above), e.g.,

http://www.imc.org/ietf-medfree/ in IETF and
http://www.w3.org/TR/CCPP-ra/ 
http://www.zurich.ibm.com/ucp/

In general, media negotiation in HTTP hasn't been successful,
see note & following discussion:

http://www.alvestrand.no/pipermail/ietf-types/2006-April/001707.html 

Larry
-- 
http://larry.masinter.net

---

From: "Larry Masinter" <[email-masked]>
Date: Thu, 21 Jun 2007 10:33:22 -0700

I left out the most recent group which I've seen trying
to tackle vocabularies for device characteristics,
preferences and capabilities:

http://www.w3.org/2005/MWI/DDWG/ 

"The nice thing about registries is that there are
so many of them to choose from"

---

From: David Morris <[email-masked]>
Date: Thu, 21 Jun 2007 14:37:14 -0700 (PDT)

On Tue, 19 Jun 2007, Stefanos Harhalakis wrote:

...
> * Anything that can personalize a page or a service, or automate transactions
...

There has been a concern in the past that too many benign details about a
user could be come a unique signature identifing individuals when they don't
expect to be identified. I worry much more about abuse of seemingly benign
data than overt identifiers.

Dave Morris

---

From: Mark Nottingham <[email-masked]>
Date: Fri, 22 Jun 2007 13:32:03 +1000

In the linked message, you say:

> I think we should deprecate HTTP content negotiation, if only to
> make it clear to people reading the spec that it doesn't really
> work that way in practice.

Seems like some explanatory text, at the least, might help people  
understand this feature a bit better.

--
Mark Nottingham     http://www.mnot.net/

---

From: "Larry Masinter" <[email-masked]>
Date: Thu, 21 Jun 2007 23:54:18 -0700

I'm willing to take a stab at writing some text if this gets
on the issues list.

Larry

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Mark Nottingham
Sent: Thursday, June 21, 2007 8:32 PM
To: [email-masked]
Cc: HTTP Working Group
Subject: Re: [RFC] HTTP Information Request

---

From: Harhalakis Stefanos <[email-masked]>
Date: Fri, 22 Jun 2007 09:59:36 +0000

On Friday 22 June 2007 00:37, David Morris wrote:
> user could be come a unique signature identifing individuals when they
> don't expect to be identified. I worry much more about abuse of seemingly
> benign data than overt identifiers.

Consider this:

  You visit an on-line shop. You make your order and its time to fill your 
address etc. A popup informs you that the site requests your name, address, 
telephone, etc. You select that you want to sent your name and address but 
not your telephone. Since all or part of the information submission must be 
approved by the user, it cannot be abused. After all, logging in with a 
username/password provides a far more easier to implement user tracking 
oportunity.

---

From: Eric Lawrence <[email-masked]>
Date: Fri, 22 Jun 2007 03:20:12 -0700

In the IE4/IE5 timeframe, Internet Explorer had this feature-- it was called the Profile Assistant.  http://msdn2.microsoft.com/en-us/library/ms533032.aspx

As I understand it, the feature was never very popular.  From a technology perspective, I don't think the implementation (HTML attributes) had any problems that implementation at the HTTP-level would have resolved.

Eric Lawrence
Program Manager
Internet Explorer
Want to view and tamper with HTTP(S) traffic?
Try http://www.fiddler2.com

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Harhalakis Stefanos
Sent: Friday, June 22, 2007 3:00 AM
To: David Morris
Cc: [email-masked]
Subject: Re: [RFC] HTTP Information Request

Consider this:

---

From: Stefanos Harhalakis <[email-masked]>
Date: Fri, 22 Jun 2007 13:26:45 +0300

> to deploy this in servers, because most clients don't support it.

I don't wont to think like this because:
a) this way noone will ever change anything in HTTP except from Microsoft
b) the only certain way to fail is not to try
c) the web has changed a lot during the last 2 years

> its mainly an academic exercise.

I strongly believe that this will interest eshops, google and microsoft. It is 
a framework that may change the way we interact with the world wide web.

> is that it's a kind of reverse content negotiation, and many

I don't think of it as content negotiation. It is more abstract and can be 
described as on-demand information submission. What the information will be 
is up to everyone's imagination. Preferences and device description is just a 
part of it. User information is another.

Consider two types of information:
a) Fixed - Timezone, CC/PP etc
b) User defined - Name, address, hobbies, etc

> http://www.zurich.ibm.com/ucp/

Are these comparable with what I'm proposing? I'm talking about content 
negotiation. Just for sending client side information on demand.

> see note & following discussion:

OK. Lets forget the 'media'. Do you believe that this is not a good thing to 
have or that people (companies and clients) will not be interested in?

---

From: Stefanos Harhalakis <[email-masked]>
Date: Fri, 22 Jun 2007 13:31:04 +0300

Consider this:

---

From: Stefanos Harhalakis <[email-masked]>
Date: Fri, 22 Jun 2007 14:04:58 +0300

On Friday 22 June 2007 13:20, Eric Lawrence wrote:
> In the IE4/IE5 timeframe, Internet Explorer had this feature-- it was
> called the Profile Assistant. 
> http://msdn2.microsoft.com/en-us/library/ms533032.aspx
>
> As I understand it, the feature was never very popular.  From a technology
> perspective, I don't think the implementation (HTML attributes) had any
> problems that implementation at the HTTP-level would have resolved.

  Indeed that was very usefull but if i understand it correctly it was also 
proprietary. Do you believe that if it was something standard it would also 
fail? 

  Apart from that, various aspects of the proposal could be used by major 
content or advertisement providers since all of them could propose their own 
extensions depending on their view of WWW.