[RFC] HTTP Information Request

[Stefanos Harhalakis-2]

  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.




Network Working Group                                      S. Harhalakis
Internet-Draft                                       TEI of Thessaloniki
Intended status: Standards Track                           June 16, 2007
Expires: December 18, 2007


                      Timezone Information in HTTP
                   draft-sharhalakis-httpinfo-00.txt

Status of this Memo

   By submitting this Internet-Draft, each author represents that any
   applicable patent or other IPR claims of which he or she is aware
   have been or will be disclosed, and any of which he or she becomes
   aware will be disclosed, in accordance with Section 6 of BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups.  Note that
   other groups may also distribute working documents as Internet-
   Drafts.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/ietf/1id-abstracts.txt.

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html.

   This Internet-Draft will expire on December 18, 2007.

Copyright Notice

   Copyright (C) The IETF Trust (2007).














Harhalakis              Expires December 18, 2007               [Page 1]

Internet-Draft        Timezone Information in HTTP             June 2007


Abstract

   This document defines a set of information-exchanging HTTP headers as
   an optional improvement to HTTP dialogs.  Server side application
   using those headers will be able to request additional information
   from HTTP clients.  This way the HTTP protocol is extended to support
   optional on-demand additional headers that can be send from clients
   when requested.

   An extensible communications framework that can be used by future
   documents is described.  The ABNF description of the corresponding
   headers is provided.







































Harhalakis              Expires December 18, 2007               [Page 2]

Internet-Draft        Timezone Information in HTTP             June 2007


Discussion

   Discussion about this document takes place in http-wg mailing list
   (ietf-http-wg@...).


Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  4
     1.1.  Purpose  . . . . . . . . . . . . . . . . . . . . . . . . .  4
     1.2.  Requirements . . . . . . . . . . . . . . . . . . . . . . .  4
     1.3.  Terminology  . . . . . . . . . . . . . . . . . . . . . . .  4
   2.  Definition . . . . . . . . . . . . . . . . . . . . . . . . . .  6
     2.1.  Protocol definition  . . . . . . . . . . . . . . . . . . .  6
     2.2.  Header syntax  . . . . . . . . . . . . . . . . . . . . . .  6
     2.3.  Proxy considerations . . . . . . . . . . . . . . . . . . .  7
   3.  Security Considerations  . . . . . . . . . . . . . . . . . . .  8
     3.1.  Client side  . . . . . . . . . . . . . . . . . . . . . . .  8
     3.2.  Server side  . . . . . . . . . . . . . . . . . . . . . . .  8
   4.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . .  9
   5.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 11
     5.1.  Normative  . . . . . . . . . . . . . . . . . . . . . . . . 11
     5.2.  Informative  . . . . . . . . . . . . . . . . . . . . . . . 11
   Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 12
   Intellectual Property and Copyright Statements . . . . . . . . . . 13


























Harhalakis              Expires December 18, 2007               [Page 3]

Internet-Draft        Timezone Information in HTTP             June 2007


1.  Introduction

1.1.  Purpose

   Web based application are exploiting the HTTP protocol to achieve
   better results and provide additional capabilities.  Every now and
   then, server side applications introduce additional needs from HTTP
   clients.  Current HTTP behavior does not provide a basis for clients
   to offer additional information upon request (on-demand).  The HTTP
   protocol could be further extended by providing such a framework.

   This document addresses this need by describing a method and a set of
   headers to be used in HTTP [RFC2616] so that server side application
   may request additional information from clients.

   By providing support for on-demand offering of information from
   clients, the HTTP protocol will be able to be further extended
   without adopting additional headers that will be always exchanged.
   This will result in smaller client requests.  Apart from that,
   willing clients will be able to provide a central management facility
   for information that will be send to server-side.  Using such a
   client, users will be able to have better (centralized) control of
   information that will be send to servers and may experience better
   server side services that will take advantage of the additionally
   provided information.

1.2.  Requirements

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in [RFC2119].

   An implementation is not compliant if it fails to satisfy one or more
   of the MUST or REQUIRED level requirements.  An implementation that
   satisfies all the MUST or REQUIRED level and all the SHOULD level
   requirements is said to be "unconditionally compliant"; one that
   satisfies all the MUST level requirements but not all the SHOULD
   level requirements is said to be "conditionally compliant".

1.3.  Terminology

   This document uses the following terms:

   HTTP client
      Every client of the HTTP protocol.  Commonly referred to as a web
      browser.





Harhalakis              Expires December 18, 2007               [Page 4]

Internet-Draft        Timezone Information in HTTP             June 2007


   HTTP header
      A HTTP header as described in [RFC2616].

   Information element
      A title that identifies some information.

   Information request
      The full list of requested information elements.

   The HTTP header specifications of this document are presented in the
   augmented Backus-Naur Form that is described in [RFC2616].








































Harhalakis              Expires December 18, 2007               [Page 5]

Internet-Draft        Timezone Information in HTTP             June 2007


2.  Definition

2.1.  Protocol definition

   Server side applications MAY use the Information Request (I-RQ)
   header to request additional information from HTTP clients.  Those
   applications MUST NOT assume that clients will respond to their
   requests nor that clients support the I-R header.

   Client side applications MAY support the server side I-RQ.  Those
   clients MAY respond to I-RQ with one or more Information Provide
   (I-PR) headers.  This action will require an additional and almost
   identical HTTP request to be sent that will include the additional
   headers.  Clients that respond to I-RQ MUST inform the server side
   application when they are denying one or more I-RQ with an
   Information Deny (I-DN) header.

   Clients MAY cache per domain/path I-RQ and automatically send I-PR
   headers without waiting for an I-RQ.  Clients SHOULD update their
   cache upon receipt of an I-RQ.  This will ensure that they will not
   send unneeded data for more than one requests.

2.2.  Header syntax

   For the purposes of this document, the following HTTP headers are
   defined:


       information-request  =  "Information-Request" ":" i-rq i-param
       i-rq                 =  i-element *( "," i-element )
       i-element            =  ALPHA *ALNUM   ; No LWS
       i-param              =  *( ";" i-param-av )
       i-param-av           =  "Domain" "=" value
                            /  "Path" "=" value
                            /  "Secure"
                            ;  As in cookies
       ALNUM                =  ALPHA / DIGIT

       information-provide  =  "Information-Provide" ":" i-pr
       i-pr                 =  i-pr-one *( "," i-pr-one )
       i-pr-one             =  i-element "=" value

       information-deny     =  "Information-Deny" ":" i-dn
       i-dn                 =  i-element *( "," i-element )

   Where:





Harhalakis              Expires December 18, 2007               [Page 6]

Internet-Draft        Timezone Information in HTTP             June 2007


   value      A value as defined in HTTP State Management Mechanism
              [RFC2109].

   LWS        Linear White Space as described in [RFC2616].

   Usage of i-param is the same as in cookie-av described in [RFC2109].
   Same grammar and semantics apply.

2.3.  Proxy considerations

   HTTP proxy servers MUST NOT alter this information.

   Server side scripts that produce customized results based on the I-PR
   information MUST return an appropriate "Vary" header as specified in
   paragraph 14.44 of [RFC2616].




































Harhalakis              Expires December 18, 2007               [Page 7]

Internet-Draft        Timezone Information in HTTP             June 2007


3.  Security Considerations

3.1.  Client side

   Part or all of the additional provided information may include
   personal information.  Documents that define the provided information
   MUST provide security considerations that characterize the additional
   information.  HTTP clients MUST NOT provide sensitive information to
   servers without letting the user prevent it.  Clients MUST either ask
   for user permission or provide options for preventing them from
   providing the additional information.  The latter is RECOMMENDED.
   HTTP clients MUST provide secure defaults that protect user privacy.

3.2.  Server side

   Web based applications MUST treat all this information as user input
   that may be invalid.  Maliciously formed headers MUST be expected and
   addressed as needed.

































Harhalakis              Expires December 18, 2007               [Page 8]

Internet-Draft        Timezone Information in HTTP             June 2007


4.  IANA Considerations

   This specification requires registration of a set of Message Header
   Fields for HTTP [RFC3864]:

   Header field:  Information-Request

   Applicable protocol:  HTTP

   Status:  Experimental

   Author/change controller:
       IETF (iesg@...)
       Internet Engineering Task Force

   Specification document:
       [ this document ]



   Header field:  Information-Provide

   Applicable protocol:  HTTP

   Status:  Experimental

   Author/change controller:
       IETF (iesg@...)
       Internet Engineering Task Force

   Specification document:
       [ this document ]



   Header field:  Information-Deny

   Applicable protocol:  HTTP

   Status:  Experimental

   Author/change controller:
       IETF (iesg@...)
       Internet Engineering Task Force







Harhalakis              Expires December 18, 2007               [Page 9]

Internet-Draft        Timezone Information in HTTP             June 2007


   Specification document:
       [ this document ]

















































Harhalakis              Expires December 18, 2007              [Page 10]

Internet-Draft        Timezone Information in HTTP             June 2007


5.  References

5.1.  Normative

   [RFC2109]  Kristol, D. and L. Montulli, "HTTP State Management
              Mechanism", RFC 2109, February 1997.

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997.

   [RFC2616]  Fielding, R., Gettys, J., Mogul, J., Frystyk, H.,
              Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext
              Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999.

   [RFC3864]  Klyne, G., Nottingham, M., and J. Mogul, "Registration
              Procedures for Message Header Fields", BCP 90, RFC 3864,
              September 2004.

5.2.  Informative

   [I-D.rfc-editor-rfc2223bis]
              Reynolds, J. and R. Braden, "Instructions to Request for
              Comments (RFC) Authors", draft-rfc-editor-rfc2223bis-08
              (work in progress), July 2004.



























Harhalakis              Expires December 18, 2007              [Page 11]

Internet-Draft        Timezone Information in HTTP             June 2007


Author's Address

   Stefanos Harhalakis
   Technological Educational Institute of Thessaloniki
   Department of Information Technology
   Thessaloniki, Greece
   GR

   Email: v13@..., v13@...










































Harhalakis              Expires December 18, 2007              [Page 12]

Internet-Draft        Timezone Information in HTTP             June 2007


Full Copyright Statement

   Copyright (C) The IETF Trust (2007).

   This document is subject to the rights, licenses and restrictions
   contained in BCP 78, and except as set forth therein, the authors
   retain all their rights.

   This document and the information contained herein are provided on an
   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
   THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
   OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
   THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.


Intellectual Property

   The IETF takes no position regarding the validity or scope of any
   Intellectual Property Rights or other rights that might be claimed to
   pertain to the implementation or use of the technology described in
   this document or the extent to which any license under such rights
   might or might not be available; nor does it represent that it has
   made any independent effort to identify any such rights.  Information
   on the procedures with respect to rights in RFC documents can be
   found in BCP 78 and BCP 79.

   Copies of IPR disclosures made to the IETF Secretariat and any
   assurances of licenses to be made available, or the result of an
   attempt made to obtain a general license or permission for the use of
   such proprietary rights by implementers or users of this
   specification can be obtained from the IETF on-line IPR repository at
   http://www.ietf.org/ipr.

   The IETF invites any interested party to bring to its attention any
   copyrights, patents or patent applications, or other proprietary
   rights that may cover technology that may be required to implement
   this standard.  Please address the information to the IETF at
   ietf-ipr@....


Acknowledgment

   Funding for the RFC Editor function is provided by the IETF
   Administrative Support Activity (IASA).





Harhalakis              Expires December 18, 2007              [Page 13]

[Stefanos Harhalakis-2]

On Saturday 16 June 2007, Stefanos Harhalakis wrote:
>   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.

  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'...

[Henrik Nordstrom-5]

tis 2007-06-19 klockan 21:12 +0300 skrev Stefanos Harhalakis:

> On Saturday 16 June 2007, Stefanos Harhalakis wrote:
> >   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.
>
>   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'...

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

[Stefanos Harhalakis-2]

On Tuesday 19 June 2007, Henrik Nordstrom wrote:
> For one thing you posted the message on a Saturday, and it's only
> Tuesday today..

  You're right... Sorry :-)

> 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..

  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.

> 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.

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

  Once again, thanks a lot for replying!

[Larry Masinter]

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

[Larry Masinter]

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"

[David Morris-4]

On Tue, 19 Jun 2007, Stefanos Harhalakis wrote:

...

>
>   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

...

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

[mnot]

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.


On 22/06/2007, at 3:27 AM, Larry Masinter wrote:

>
> 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
>
>
>

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

[Larry Masinter]

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

Larry


-----Original Message-----
From: ietf-http-wg-request@... [mailto:ietf-http-wg-request@...] On
Behalf Of Mark Nottingham
Sent: Thursday, June 21, 2007 8:32 PM
To: LMM@...
Cc: HTTP Working Group
Subject: Re: [RFC] HTTP Information Request


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.


On 22/06/2007, at 3:27 AM, Larry Masinter wrote:

>
> 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
>
>
>

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

[Stefanos Harhalakis]

On Friday 22 June 2007 00:37, David Morris wrote:
> 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.

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.

[Eric Lawrence-4]

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: ietf-http-wg-request@... [mailto:ietf-http-wg-request@...] On Behalf Of Harhalakis Stefanos
Sent: Friday, June 22, 2007 3:00 AM
To: David Morris
Cc: ietf-http-wg@...
Subject: Re: [RFC] HTTP Information Request





On Friday 22 June 2007 00:37, David Morris wrote:
> 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.

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.

[Stefanos Harhalakis-2]

On Thursday 21 June 2007 20:27, Larry Masinter wrote:
> 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.

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

> Unless you have a better story for how this will get deployed,
> 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.

> That's the general problem. The specific problem with this
> 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

> 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/

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

> In general, media negotiation in HTTP hasn't been successful,
> 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?

[Stefanos Harhalakis-2]

On Friday 22 June 2007 00:37, David Morris wrote:
> 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.

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.

[Stefanos Harhalakis-2]

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.

[Stefanos Harhalakis-2]

On Thursday 21 June 2007, Larry Masinter wrote:
> 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.

Hello again after a long time...

I'm writting this email just to let you know that I'm convinced (based on all
of your comments) that:

* Content negotiation is not a good idea (tm) and most probably won't be
implemented.
* Timezone information should not be transfered because of the overhead that
introduces.

So I'll let the timezone draft to expire and will not submit the content
negotiation draft.

Thank you all for your time and your comments!

Best regards,
Harhalakis Stefanos

[mnot]

http://www.w3.org/Protocols/HTTP/1.1/rfc2616bis/issues/#i81


On 22/06/2007, at 4:54 PM, Larry Masinter wrote:

>
> I'm willing to take a stab at writing some text if this gets
> on the issues list.
>
> Larry
>
>
> -----Original Message-----
> From: ietf-http-wg-request@... [mailto:ietf-http-wg-
> request@...] On
> Behalf Of Mark Nottingham
> Sent: Thursday, June 21, 2007 8:32 PM
> To: LMM@...
> Cc: HTTP Working Group
> Subject: Re: [RFC] HTTP Information Request
>
>
> 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.
>
>
> On 22/06/2007, at 3:27 AM, Larry Masinter wrote:
>
>>
>> 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
>>
>>
>>
>
>
> --
> Mark Nottingham     http://www.mnot.net/
>
>
>

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