RE: 1xx Clarification

I've been watching this discussion, and have several observations, and
a (so far personal) conclusion:

1) HTTP lacks a notification mechanism.  The RTSP people, for example,
have a real requirement for this ability, and everyone doing cooperative
work has identified this as a basic need.  I agree.  Certainly the protocols
I've worked on in the past found notification an essential part of the
protocol, and if HTTP 1.X is to be extended further, this is a necessity.

2) Larry has identified a problem with using 1XX responses for this;
in particular, distinguising one generated as a normal part of the
protocol transaction (i.e. the client is expecting it may get such
a response), vs. one generated completely asynchronously.  Getting
a client confused due to a race condition is a "bad thing" in my opinion.

3) It is probably not nice to send such asynchronous notifications to
clients not expecting them.  The way we handled this in the X protocol
was by having the client express interest in (a class of) an event type.
If the client doesn't know about the event type, he won't ask about it,
and therefore won't recieve event types they don't expect/understand.

This is telling me that while subverting 1XX responses for notifications
and other items is possible, it is probably wrong to shoehorn it into
1XX responses and probably a real kludge to do so. Confusing
responses with events will generate no end of confusion, particularly
since HTTP/1.X lacks any sort of request # in the response to allow
for bookkeeping between which request generated what response.  (A fundamental
lack in HTTP; sigh...).

My conclusion:

HTTP needs an "Event" mechanism, separate from 1XX responses (after all,
they are "responses", and clients can expect them at particular points
in the conversation).

I think the cleanest way to do this is to define a new set of response
codes as "event codes".  Such events could be sent asynchronously to
any client which has "selected" that event type (and not sent to clients
that don't select them.), for as long as that connection is established.
Clients that don't know about events won't see them.

I think the way to make progress quickly here is for someone to write
up a short ID on the topic, with the intent of going to proposed standard
with the HTTP/1.1 draft standard.  I expect this should only take
a couple pages, and solve a bunch of people's problems.

Any volunteers?
				- Jim Gettys

Received on Thursday, 17 April 1997 10:58:57 UTC