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

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

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

-----Original Message-----
From: Henrik Frystyk Nielsen [mailto:frystyk@w3.org] 
Sent: Monday, May 18, 1998 7:24 AM
To: Paul Leach; hardie@nic.nasa.gov; Josh Cohen; Yaron Goland; Scott
Cc: Larry Masinter; jg@w3.org
Subject: Notes from HTTP Mandatory Editor's meeting, May 15, 1998

PS: I CC Larry and Jim again so you can see the status as well. Larry, how
do you think we should bring up the issues from last meeting wrt end-to-end
and interactions with the Expect header field?


	Ted, Henrik, Yaron


	Closing remaining issues on list


Next Meeting:

	The last meeting in getting Mandatory out the door is

		Time: Friday, May 22, 15.30-16.30ET (12.30-13.30PT)
		Location: +1 617 252 1038 (no access code)


Item 4 510 INFO

It is for the particular extension to define a mechanism for sending back
information about required extensions. Turn the SHOULD into a MAY but *if*
the server includes metainformation in the response about the required
extension then it SHOULD describe ALL extensions required to get to the
resource. It's a all or nothing kind of thing.

Status: ready for last call


We think there was a misunderstanding in the discussion on the mailing
list. It is not a so much a question of defining the lifetime of an
extension as it is "if an application doesn't speak this, then when can I
try again to see if it has learned?".

- Extension identifiers MUST never be used for something else than
identifying a particular extension

- It is for the application to determine/decide when and how often to ask
where another application speaks a certain extension. OPTIONS can for
example be used for doing this.

Status: ready for last call


- Since the IANA registry is in a mess wrt URI names then we need to make
clear what we mean with "relative URIs are resolved to the IANA registry".
It is clear that we don't want to provide conventions for naming the IANA

- Potential problem with ":" in short names if they are not URIs. Should at
least make clear that tokens MUST be valid URIs - absolute or relative.

- We have three possibilities for solving this issue:

	- Ignore it and say that IANA will help us to resolve short names.
	  We should get this via the ADs before agreeing on this
	- Refer to the registry draft by Palme. As far as we know,
	  the MIME header registry moved into the drumps group.
	- If not an absolute URI then it must be registered in
	  the IANA RFC space

ACTION: Ted to follow up on status of header field registry in drums
Status: open


Maybe talking about two different things. Make it into a MUST NOT reuse
existing prefixes and explain that some extension can be repeated down the
message line. This is for example the case for many proxy specific

Status: ready for last call


Not dealt with.

Comments before I update the issues list?


Henrik Frystyk Nielsen,
World Wide Web Consortium
Received on Monday, 18 May 1998 13:45:48 UTC

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