W3C home > Mailing lists > Public > ietf-http-ext@w3.org > April to June 1998

FW: Notes from HTTP Mandatory Editor's meeting, May 8, 1998

From: Josh Cohen <joshco@microsoft.com>
Date: Mon, 18 May 1998 10:04:56 -0700
Message-ID: <8B57882C41A0D1118F7100805F9F68B50340A3D1@red-msg-45.dns.microsoft.com>
To: ietf-http-ext@w3.org


Scott Lawrence, Josh Cohen, Paul Leach, Yaron Goland, Henrik Frystyk

PS: Larry and Jim - I cc you as there are two issues that may affect
HTTP/1.1 - please read the discussion of item 1) and 5) below.

PPS: Josh - do you want to send out the last calls on the issues that we
closed (see minutes below)?


1) End-to-end notion in Mandatory and HTTP/1.1 (END_TO_END)
2) Unsolicited Mandatory header fields in responses (REPEATED_EXTENSIONS)
3) Extension parameters in extension declarations (DECL_PARAMETERS)
4) What does it mean for URIs to be relative to IANA? (IANA_ROOT)
5) Interactions with Expect in HTTP/1.1, rev 03 ()

Next Meeting

I have arranged for two more phone conferences:

	Friday, May 15 and 22, 1998 in the period 15.30-16.30 ET

which should be enough to get through any remaining issues and to issue a
new draft.

Issues List



1) Concensus was that the current working in Mandatory is correct. A
solution to the discussion was proposed to a) take out the current wording
in Mandatory and leave it "as defined in HTTP" and b) do one of the
following in order of preference:

     -	Make a plea to Larry and Jim that the notion of end-to-end
	is clarified in HTTP/1.1 spec as currently stated in Mandatory
     - Make a note in the (now yet written) extension guide lines
	discussing the floating notion of end-to-end.

Action: Henrik to talk to Larry and Jim.
Status: Ready for last call on mailing list

2) Was not solved - question is what to do with a mandatory header in the
response. It was mainly intended as a mechanism for avoiding "garbage on
the screen" when servers introduce new extensions. A contra argument was
that servers don't introduce new extensions without knowing whether the
client accepts them or not.

Status: Open

3) People are happy with the name space solution together with headers and
did not want another way of passing extension parameters. All unknown
extension parameters are for the mandatory extension mechanism itself and
*not* for the extension.

Status: Ready for last call on mailing list

4) As this was brought up by Ted, we postponed it to next week's meeting.

5) Problem with expect is that it can't be enforced. It is semantically
close to (and completely contained by) the C-Opt header field: A hop-by-hop
header field with an optional extension. Difference is that Expect is a
request-only header field whereas C-Opt is a general header field. Should
Expect be deprecated in favor of C-Opt?

Action: Henrik to talk to talk to Larry and Jim.
Status: Ready for last call on mailing list

Henrik Frystyk Nielsen, <frystyk@w3.org>
World Wide Web Consortium
Received on Monday, 18 May 1998 13:04:56 UTC

This archive was generated by hypermail 2.4.0 : Thursday, 1 July 2021 15:49:08 UTC