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

From: Josh Cohen (joshco@microsoft.com)
Date: Mon, May 18 1998


Message-ID: <8B57882C41A0D1118F7100805F9F68B502D2CC7F@red-msg-45.dns.microsoft.com>
From: Josh Cohen <joshco@microsoft.com>
To: "'ietf-http-ext@w3.org'" <ietf-http-ext@w3.org>
Date: Mon, 18 May 1998 10:45:48 -0700
Subject: FW: Notes from HTTP Mandatory Editor's meeting, May 15, 1998



-----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
Lawrence
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?

Attendees:

	Ted, Henrik, Yaron

Agenda:

	Closing remaining issues on list

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

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)

Minutes

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

Item 5 EXTENSION LIFETIME
-------------------------

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

Item 6 IANA REGISTRY
--------------------

- 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
registry.

- 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

Item 7 REPEATED EXTENSIONS
--------------------------

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
extensions.

Status: ready for last call

Item 8 MANDATORY_RESPONSE
-------------------------

Not dealt with.

Comments before I update the issues list?

Henrik

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