RE: Submission of HTTP Extension Framework (Mandatory)

O.k. O.k... I know.. RTFM. I'm sorry.

Regarding the 102 vs header. My situation is this: If I can't use mandatory
through 1.0 proxies then I can't use mandatory. Which would suck. So lets
have ourselves a compromise. If you use 102 then you are done, you had done
your duty, everything is cool. However, If you decide to use a header
instead (we will support both in the spec) then you MUST include both
pragma: No-Cache and Cache-Control: No-Cache on the response. You MUST use a
header any time a 1.0 proxy or client is involved. This sucks but it is
better then rendering mandatory useless for the next five years or so. I
think this is better than the ACK idea because ACK means that all such
requests are uncacheable forever.

BTW I think Roy is right regarding OPTIONS as the real solution. The only
problem is that an annoying number of people still don't want to pay that
single round trip price. Which I think is a nonsence argument because if you
are using a mandatory extension you are already in weirdoville anyway. What
we really need are some common rules for how to cache information you get
back from an OPTIONS call. 

BTW, an edge case that still is worth thinking about is what happens if you
do an OPTIONS, a server claims support and then two or three days later you
still assume support is there but the server crashed and was brought back up
with an older version that doesn't support your extension any longer? Major
major ick.

			Yaron


-----Original Message-----
From: Yaron Goland 
Sent: Tuesday, August 11, 1998 9:42 PM
To: 'Henrik Frystyk Nielsen'; ietf-http-ext@w3.org
Subject: RE: Submission of HTTP Extension Framework (Mandatory)


It is often the case that one needs to dumb down a 1.1 method to get through
a 1.0 proxy. However, if a mandatory request doesn't include any c-* headers
and is otherwise properly formatted why should the server be forced to
reject it on the sole basis that it was received from a 1.0 client as
required by rule 2 in section 5?

Many server side extension APIs do not provide support for sending 1xx
responses. As such it would make implementing Mandatory harder by requiring
a 102 response as specified by rule 5 in section 5. Why not just add a
header to the 200 response such as "man-confirm:" which means "I did
understand your mandatory header(s)"?

If one receives a response to a DELETE with a mandatory header on it,
treating the body as if it were application/octet-stream does not provide
any help in determining what has actually happened as a result of the DELETE
method. I believe section 6 needs to use more restrictive language of the
form "The server MUST NOT send back mandatory headers on the response unless
some form of negotiation has already occured which specifically allows it."

If Keith stays true to form he is going to give you grief over making the
URIs resolvable. He is going to ask you very pointed questions about how you
deal with load when you have a whole bunch of people trying to resolve this
URI. I think we are actually o.k. because resolution is not required for
operation, rather it is a way for someone to figure out what some random
mandatory extension they have never seen before is. Thus, since the URI is
not really usable by an automated process, the over all load should be
manageable.

Also, as much as I like to get referenced you never actually use [10]
anywhere in the spec so it should be removed.

		Yaron



-----Original Message-----
From: Henrik Frystyk Nielsen [mailto:frystyk@w3.org]
Sent: Friday, August 07, 1998 10:56 AM
To: ietf-http-ext@w3.org
Subject: Submission of HTTP Extension Framework (Mandatory)



I have written up the closures of all the outstanding issues listed at

	http://www.w3.org/Protocols/HTTP/ietf-http-ext/Issues/

and included them in an updated HTTP Extension Framework draft which is
available from

	http://www.w3.org/Protocols/HTTP/ietf-http-ext/

in various formats (I am submitting it now).

I am not aware that this group is meeting at the Chicago IETF nor what the
exact status is of the Working Group itself. Is this a Working Group or not?

However, after having closed all remaining issues, I believe we are
actually done with this draft unless issues not already described in the
issues list come up. Therefore, I urge you to look it over carefully and
send any comments to this list.

Thanks!

Henrik




--
Henrik Frystyk Nielsen,
World Wide Web Consortium
http://www.w3.org/People/Frystyk

Received on Wednesday, 12 August 1998 01:00:39 UTC