RE: HTTP in problem statement action

Thanks Magnus.

 

How do you see this fitting with the suggestion under ISSUE-217 that
this whole section be somehow run in with section 1?

 

Jo

 

(Trackbot this was ACTION-554)

 

________________________________

From: Magnus Lonnroth [mailto:mml@drutt.com] 
Sent: 12 September 2007 07:43
To: Jo Rabin
Cc: public-bpwg-ct@w3.org
Subject: HTTP in problem statement action

 

ACTION: Magnus to draft a passage on possible use of existing HTTP
headers with examples

I actually think I said "HTTP protocol" not "HTTP headers", and for the
sake of saving time, I'll stick with the existing example which is
rather good. Here's a restructuring of section 2 of the problem
statement (starting right after the note). 




Techniques need to be identified or designed to enable the following:

*      Identify what representations are available for a resource.

o     Indicate a user's or site designer's intent to intermediary
proxies.

o     Identify specifically tailored content in a response.

o     Enable site designers to provide content transformation hints to
intermediary proxies, e.g. to identify the "most important" parts of a
resource.

o     Elaborate an origin server's description of a resource (WDR, label
etc.) to allow intermediaries to adjust the description of the
properties of the resource when accessed via those intermediaries.

*      Identify all actors in the delivery context so that they can find
out about each other

o     Identify the originating user agent and its capabilities to
intermediary proxies and the origin server

o     Identify an intermediary proxy's capabilities (including
transformation capabilities) to other intermediary proxies and the
origin server

o     While providing accurate user agent information, work effectively
with an origin server that is unaware of the negotiation techniques
described above, and so avoid that server responding that it does not
support a user agent.

If necessary note the need for a consistent representation of device and
intermediary capabilities.

*      Enable user control of the experience - e.g. deciding whether
they want the desktop or mobile experience when there is a choice,
noting that while it is important to make assumptions about the user's
context to try to provide an appropriate experience, those assumptions
may be wrong.

Examples of technologies and techniques that will be further
investigated include, but are not limited to:

*      The HTTP protocol, which in itself provides several mechanisms
that are very likely to be useful (should HTTP extensions also be
investigated?). In particular to promote awareness of the
"Cache-Control: no-transform
<http://tools.ietf.org/html/rfc2616#section-14.9.5> " HTTP directive, or
other mechanism for allowing content authors to prohibit transformation
of a resource by intermediaries.

*      The POWDER protocol, which provide mechanisms for describing
resources using RDF and OWL. More generally, ascertaining that a
representation of a resource is suitable for the user's delivery context
either because the resource has been so described or from the nature of
the representation of the resource.

*      The work of the W3C MWI DDWG <http://www.w3.org/2005/MWI/DDWG/>
relating to definition of device capabilities.

The impact of content transformation on security needs to be considered
and any recommendations made. In particular, consideration needs to be
given to the possibility of "man in the middle" security attacks.

The implications of operations such as advert insertion and similar
changes to original content needs to be considered and any
recommendations made. 







-- 
Magnus Lonnroth
CTO, EVP Engineering
Drutt Corporation