W3C home > Mailing lists > Public > ietf-http-wg-old@w3.org > May to August 1996

Re: draft-ietf-http-pep-02

From: Ted Hardie <hardie@merlot.arc.nasa.gov>
Date: Thu, 22 Aug 1996 12:11:06 -0700 (PDT)
Message-Id: <199608221911.MAA04790@merlot.arc.nasa.gov>
To: rohit@w3.org, http-wg%cuckoo.hpl.hp.com@hplb.hpl.hp.com, linehan@watson.ibm.com
X-Mailing-List: <http-wg@cuckoo.hpl.hp.com> archive/latest/1449

On a general note, I would like to have some information on how PEP
would work with the current state management proposals.  In
particular, I can see a fair number of situations in which sites would
want to use cookies to keep track of which clients had already
negotiated certain protocol extensions.  There has already been a fair
amount of discussion about how cookies and caches will interact; will
those interactions stay the same if part of the state being managed
relates to protocol extensions?

Mark writes: 
>3. I (still) wish there were a matrix discussing the
>meaning of each parameter (str, scope, via, for, params) for each
>type of header (Protocol, Protocol-Request, Protocol-Info, and
>Protocol-Query).  I think some of the cells may be meaningless, and
>others may have ambiguous meanings.  I think the exercise of filling
>in such a matrix may bring clarity to this proposal.

I, too, would like to see us develop a matrix, but a broader one,
about when we can expect to use which methods for what negotiations.
My current understanding is:

Upgrade: Used to change versions of "vanilla" HTTP .

Transparent Negotiation: Used to negotiate resource alternatives,
based on "vanilla" HTTP headers.

PEP: Used to negotiate custom extensions to HTTP; these extensions
may transform a resource, alter delivery methods, and require
specific ordering of successive transformations/actions.

Obviously, each of these can interact with the others.  What do you
do, for example, when a client requests a resource which would
produce a List response, but where a PEP extension would allow the
delivery of a custom response?  My guess would be to return the list
response with a Protocol-Info: header, but it would be nice to see
some of this worked out.

It would probably be a bit easier for the working group to see
these interactions if we had a specification draft, as well as
a discussion-oriented draft.  Do you have one in the works now,
and if so when can we expect it?

					Ted Hardie
					NASA Science Internet
Received on Thursday, 22 August 1996 12:53:06 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 14:40:18 UTC