Negotiation issue list

Here is a list of negotiation issues, which I propose for addition to
the HTTP Working Group Issue list.  I compiled this list using several
sources.

Part 1) below mentions some resolved issues first.  I included most of
these to record some `general framework' things the caching and
content negotiation subgroups seem to have consensus on.

Koen.

----snip---

1) Negotiation in general.

 - Is negotiation desirable?

   Status: Yes, most people want it, though it is not expected that it
   will be used soon for more than 5% of all resources.

 - How long will we have to live with user-agent negotiation?

   Status: Feature negotiation will make this obsolete, we hope to
   have a feature negotiation mechanism usable for most of the things
   that user-agent negotiation is used for now within half a year or
   so.

 - What kinds of negotiation will be possible under HTTP/1.1?

   Status: Resources can be 

     1) un-negotiated: there is only one version of the content

     2) negotiable as in draft-holtman-http-negotiation-00.txt,
        the Alternates header specifies all available alternates,
        the user agent allows the user to select another alternate if
        desired.

     3) negotiable with a Vary header.  The origin server has multiple
        variants, and selects one based on, for example, the contents
        of the user-agent header in the request.  There is no standard
        mechanism to allow the user to select other variants.

   Type 3 is to be used in cases where use of type 2 is not possible
   for some reason.

 - May servers send responses that are not acceptable according to the
   Accept* headers in the request?

   Status: Yes.  They may, but they should not.

 - Should there be mechanisms that prevent the re-sending of long
   response bodies in type 2 and 3 negotiation if these bodies
   are already in cache?

   Status: Most people want such mechanisms to be defined, but do not
   want to require implementation in all web software.  Roy doubts
   whether these mechanisms are needed [At least that is what I gather
   from his comments--KH].

 - What will such an optimisation mechanism look like?

   Status: draft-holtman contains a mechanism for type 2 negotiation.
   Work is being done on defining a mechanism for type 3 negotiation.
   Roy Fielding has proposed a Content-ID scheme that would be as
   powerful as, but simpler than, than both these mechanisms.  See the
   end of
   http://www.ics.uci.edu/pub/ietf/http/hypermail/1996q1/0415.html and
   responses to that message.

 - Won't negotiation have n^2 interactions with caching, so that we
   have to define loads of special rules?
 
   Status: No.  Both type 2 and type 3 negotiation introduce some
   extra requirements on caches, but it has proven to be possible to
   add negotiation without introducing n^2 special cases.

 - Does "Content-Language: mi, en" specify that the content is
   intended for both audiences that speak Maori and audiences that
   speak English, or for an audience that speaks both Maori and
   English?

   Status: The HTTP/1.1-01 draft seems to contradict itself on this.
   The first alternative is used in the section about
   Content-Language, the second in Accept-Language.  Consensus is that
   the first alternative is the right one?

 - What do the "mirror" and "name" forms in the URI header say exactly?

   Status: These reflect a mechanism that is current practice on the
   CERN server.  No complete description of this mechanism has been
   posted to http-wg [at least I do not remember such a posting--KH].


2) draft-holtman-http-negotiation-00.txt:

 - Should the Alternates header have an optional {"user-agent-prefix"
   quoted-string} attribute for user agent based negotiation?

   Status: probably not.

 - Must negotiation on Content-Encoding be part of the content
   negotiation process?  Content-Encoding is transparent to the end 
   user, so it has little to do with quality values.

   Status: It would be save to leave it in.  Leave it in?

 - Strength of origin server restriction that prevents spoofing using
   Location headers: if Location headers values are restricted more,
   this makes it more difficult to make negotiable resources, but it
   makes it easier to make spoof-free shared servers.  What is the
   optimal balance?

   Status: Unresolved, probably a bit weaker than what is now in
   draft-holtman.


3) Feature negotiation:

 - Do we want negotiation on HTML features?

   Status: Yes

 - Do we want negotiation on non-HTML features like the ability to
   display images on a color screen?

   Status: Yes

 - How many feature identifiers do we expect there to be?

   Status: lots and lots, the rule is to register everything people
   propose.

 - Who will register features?

   Status: IANA?

 - Can we make a feature negotiation mechanism that does not put
   pressure on browsers to send long lists of features in every
   request?

   Status: Yes, Koen Holtman will write up a specification of such a
   mechanism.

Received on Tuesday, 27 February 1996 13:20:31 UTC