Internet Info 1997 December/Internet_Info_CD-ROM_Walnut_Creek_December_1997.iso/ietf/http/http-minutes-97aug.txt

Text File | 1997-10-10 | 51KB | 1,168 lines

These are the *DRAFT* http minutes of the Munich IETF, edited by
Larry Masinter. Many thanks to Koen Holtman, Martin Du"rst and
Chantelle Cooper, who provided timely drafts of their notes and minutes.
Send all complaints to the editor.

Monday, August 11

The group focused on the issues in the issue list
        http://www.w3.org/pub/WWW/Protocols/HTTP/Issues/
Numbers in [brackets] are the issue number in the issue list.

The 08 version of http/1.1 draft did not appear in the
internet drafts directory before the meeting; the Internet
Drafts editor had problems processing last minute submissions.

[1] 301-302, [2] VERSION, [3] RE-VERSION were discussed Monday,
but see notes on Tuesday session.

[4] REDIRECTS (How many redirects required?)
We discussed the issue of the limit on the number of redirects which
a server can expect a client to implement. Proposal:
this belonged in an application profile (of HTTP, HTML, etc.) and not
in the HTTP spec, which should have mandatory (SHOULD, MUST)
redirects removed and replaced with an implementation note.

[5] LINK_HEADER
There seems to be a conflict between HTML and HTTP regarding the
interpretation of Link header. Resolution: Remove the Link
header from the main HTTP/1.1 spec. Dan Connolly will submit an
Draft to align HTTP and HTML definitions of this header.
The draft may proceed on standards track independently.

[6] CONTENT-ENCODING
The room seemed to be happy with the proposed resolution;
also, it seems to be consistent with Apache & MSIE implementations.

[7] CACHING-CGI
We got into this state because some origin servers might have counted
on the (simple optimization) that proxies (usually) didn't cache
URLs with queries or /cgi/ in them. But this was never part of the
specification. We concluded that the new text in the -08
revision (requiring caches to treat responses as uncacheable based on
some patterns in the request URL) should not stay as a requirement.
Jim Gettys will revert the requirements for treating responses as
uncacheable to those in the 2068 RFC.  He may rework the new URL
pattern text into an implementation note.

[8] WARNINGS
Klaus Weide sent comments to the mailing list which should be
responded to. There are several issues that are left to be resolved.

[10] OPTIONS
(See notes discussion on Tuesday)

[11] DATE-IF-MODIFIED, [12] 403VS404: these were declared
'editorial', see next draft for proposed wording.

[13] PUT-RANGE
Proposed resolution: warn that using PUT with byte ranges
is dangerous and not compatible with 1.0 or servers that don't
accept-ranges.
The WEBDAV group worked on this, but seem to have decided
that it was too complex. It was reported that Paul Leach
Paul Leach will submit a proposal soon; the WG will wait
and see how complex Paul's proposal might be.

[14] HOST
Jim Gettys will draft proposed text, to the effect
("Proxy can add, but not rewrite")

[15] AGE-CALCULATION
This issue has been debated at length. Jeff Mogul will ubmit an internet
draft countering the position on this issue taken in Roy Fielding's
draft. Once we have two drafts, we will evaluate them and decide.

[16] RE-AUTHENTICATION-REQUESTED
Should there be a revalidation request code? This needs mailing
list discussion. It's marked as 'drafting'.

[17] SAFE [18] UAHINT
Given the current status, Keith Moore's suggested these be released as
Experimental RFCs. Larry Masinter will initiate this.

[19] AUTH-CHUNKED
The proposed fix is in draft 08, and ready for last call.

[20] REQUIRE-DIGEST
There needs to be some way to require that Digest authentication
be used. The draft has been issued is ready for last call; John
Franks had comments which need to be responded to.

[21] PROXY-REDIRECT
There was a lot of discussion about security and privacy issues,
and the 08 draft does not address these issues.
In particular, the scope restrictions in 305 processing are not
restrictive enough, and alternative scoping rules are needed.
There may be a privacy concern with respect to redirection of
client requests to other servers without informing or asking
the user for consent.
There's a security difficulty with a permanent redirection to a proxy
without user recognition or consent.

Yaron Goland had doubts about defining the 306 functionality inside
HTTP; formats different from the Set-Proxy header format may be
more appropriate as a means of reconfiguring client caches.
It was decided to continue this discussion outside the meeting.

[25] PROXY-LENGTH
The content-length additions to the 08 draft caused some
self-contradictions. Koen Holtman will send a message about
this to the mailing list.

[34] QUOTED-BACK ([32] COMMENT)
A compatibility note seemed to be missing from the 08 draft.
Jim Gettys will add this note, with appropriate cross-referencing.

[204] DISPOSITION RFC 1806
Keith Moore's Content-Disposition document, which is currently in the
RFC pipeline, doesn't mention the HTTP usage or syntax.
Larry Masinter and Keith will put together a paragraph to be added
to the C-D draft, either before or after it goes to RFC.

[59] CLOSE (Who should close the connection?)
Jim Gettys promised a revised internet draft soon.

[201] REQUIREMENTS (Need table of requirements like RFC 1122 and 1123)
We discussed creating the index of HTTP requirements. The requirements
table can also serve as a checklist to document independent
implementations for each HTTP/1.1 feature.

We discussed having a 'HTTP/1.1 interoperability test' event,
as a means of documenting compliance and getting implementor
feedback about remaining problems. There was a lot of interest.
Quentin Clark offered to help organize this, in order to be
able to report on the results of interoperability by the Dec 97
IETF.

[**] Basic/Digest
There was some confusion about the status of Basic & Digest
authentication
in the -08 draft. The goal is to keep "HTTP/1.1" as two documents,
one on the main protocol and a separate draft on "authentication",
but that both would be required for compliance with HTTP/1.1.

Tuesday 8/12
---------------

CONTENT NEGOTIATION
Koen Holtman gave an overview of the current Transparent CN drafts
(draft-ietf-http-negotiation-03.txt, draft-ietf-http-rvsa-v10-02.txt),
and the history, goals, and test implementations.

Jim Gettys noted that the "Alternates" header, and the feature
tag registration mechanism might progress faster outside of the
rest of TCN. We decided to split draft-ietf-http-negotiation-03.txt
into two drafts, one with the Alternates header which might move
to Proposed Standard while the rest of TCN can move to Experimental
status.

We discussed the feature registration drafts
(draft-ietf-http-feature-reg-02.txt,
draft-ietf-http-feature-scenarios-01.txt).  It has wide
applicability and should go to BCP. Some questions, such as "should
features be URLs?" and "are the types used the right ones?" may need
further examination.

Ted Hardie and Graham Klyne will expand the current
draft-ietf-http-negotiate-scenario-01.txt into a more general
requirement and scenarios document that will cover other cases of
feature and capability negotiation; it will likely become
an Informational RFC.

There is interest in forming a 'negotiation subgroup', which
may continue working independent of HTTP-WG.

[2] VERSION [3] RE-VERSION (Version number returned by servers)
There was an offline discussion Monday afternoon, reported
on Tuesday.

RFC 2145 might need clarification of the result of the interactions
between CGI scripts, proxies, servers; old CGI scripts working
with new servers.

The entity (or "message payload") version number should supercede
the server's version number. The HTTP versioning requirements
in RFC2145 will probably not cause problems for proxies.
Some language should be added to the 1.1 spec to make it more clear
what proxies should do, and what they cannot be expected to do,
when upgrading and downgrading responses between 1.1 and 1.0.
It was suggested that a proxy's cache entries be upgraded
to the highest version of the client request & server response,
as a solution to the ambiguity of labelling cache entries.


[1] 301-302 (Problems with redirecting requests.)
Josh Cohen reported on the conclusions of an offline discussion.
302's historical use has not been changed by most servers and
script writers to the new definition in RFC 2068.

The text in the -08 draft should be changed, either by
    a) reverse the meanings of 302 & 303
    b) Deprecate 302 and add 307
The consensus of the meeting was to take path (a).
The issue will be raised on the mailing list.

[**] PEP discussion
Discussion of Henrik's new draft of 14 July centered around
the question of how much complexity is needed for
 a) querying about the availability of protocol extensions
 b) negotiating on and detecting the use of protocol extensions

Yaron Goland said that the current PEP spec was so complex that he
feared that lots of people would only implement subsets, with the
subset implementations ending up being incompatible with each other.

Some alternatives to PEP were discussed:
 - the proposed OPTIONS mechanism
 - the old Mandatory header field mechanism
 - an IANA-based header field name registry

OPTIONS is not a subset of PEP capabilities, and isn't intended to be.

It was the general feeling that something simpler than PEP might well
be sufficient for meeting the HTTP protocol extension needs of the
internet community, but that the WG did not have sufficient data to
know for sure.  Jim Gettys asserted that most potential users of PEP
were not in contact with the HTTP-WG.

Some people reported that the JEPI initiative, which was planning to
use PEP, is basically `dead'.  Someone from the RTSP group reported
that they had implemented a subset of PEP, and that it could be
possible that the RTSP needs would also be satisfied by OPTIONS or the
Mandatory header.

Jim Gettys said that he felt that header clashes due to independently
developed protocol extension were a real potential problem, and that
the the http-wg ought to address this problem in some way, either with
PEP or with something else.  Koen Holtman remarked that the current
and previous PEP drafts caused their own header clash problems because
they basically allocated all remaining header field names for potential
use by PEP, and that this would have to be fixed if work on PEP were to
be continued.

Keith Moore remarked that, from a distance, it looked to him as if PEP
was a solution in search of a problem, and that PEP review might be
out of scope for HTTP-WG.

[10] OPTIONS
Josh Cohen reported on his motivation for proposing the OPTIONS
mechanism: he discovered that he needed it when specifying the proxy
redirect mechanisms.  There is an urgent need for a mandatory HTTP/1.1
extensions discovery mechanism, and that it should be bundled with the
main HTTP/1.1 spec. Josh wanted to keep the mechanism very simple,
so that quick progress could be made, and feared that having a general
registration mechanism in addition to the `RFC=' and `HDR=' vocabulary
in the current options draft would slow things down too much.

Does the current draft really addresses the necessary option/extension
discovery scenarios?  For example, what if a server does not implement
some SHOULDs in an RFC? Which SHOULDs are ignored?
Yaron Goland noted that WEBDAV defined three levels of compliance,
so that the `RFC=' mechanism in the current options draft would not be
sufficient for WEBDAV discovery needs.

Larry Masinter (not speaking as the chair) noted that OPTIONS
defined yet another name space, and that the namespace of options
could probably use the proposed feature tag registry, and asked
the working group to consider whether this was desirable. For that
matter, the namespace could be shared with PEP extensions.


Koen Holtman cautioned against rushing out a mechanism too quickly,
without careful consideration of all details.

We agreed to finish work on OPTIONS quickly, and consider it as part of
the HTTP/1.1 spec or as a separate draft.

[***] Query Internationalization

Martin Du"rst briefly reviewed the issues in internationalization
of web form submission, and the possible solutions, as recorded in
his recent internet drafts.  This issue goes beyond HTTP, but
the proposed the proposed solution involves a negotiation mechanism
based on a HTTP header (Query-UTF-8).

Those interested should discuss this issue on the
[e-mail] mailing list.

[***] Status codes sharing
Johnathan Rosenberg was going to present draft-schulzrinne-http...
but was missing from the room; we wound up not discussing the issue.

[***] State Management

  [--] Cookie Comment/CommentURL

The working group mailing list seemed to have been filled with
discussion
of the Comment-URL feature.

Larry Masinter gave his (personal) views on the comment and commentURL
mechanisms. While it is a very good thing for service authors to
inform users about the cookie-related privacy policies of the site,
the comment and commentURL mechanisms are not the appropriate
mechanisms to convey this information, and that these mechanisms
should be removed from the draft.  There was some agreement on
removing comment and commentURLs from the audience.

Koen Holtman said that, lacking a concrete proposal for an alternative
means of conveying the information, he did not mind if comment and
commentURLs stayed in.

 [--] Set-Cookie2

There's some concern that discussion of the technical protocol in
RFC 2109 was being held up due to concern about the privacy
considerations and provisions in it. The objection to RFC 2109
is that it does not reflect current practice. Yaron Goland
asserted that the changes in 2109 from Netscape's first cookie
spec are not wanted and will not be implemented.

Larry Masinter suggested separating the draft into two parts,
although releasing them simultaneously. One part would discuss
the protocol, and the other draft would discuss the privacy
considerations.

Dan Jaye reported on his recent revision of the trust-state draft: he
said he would mail draft-ietf-jaye-trust-state-01.txt to the list
soon (an attempt to mail it before the meeting failed).  Dan Jaye and
Yaron Goland asserted that implementers wanted to use PICS-based
cookie labeling as a privacy technology, and not the proposals in the
state management draft.  Yaron Goland said that, in his opinion, the
effort on revising the Set-Cookie2 based state management draft should
be stopped.  In stead, the http-wg should concentrate on writing a
standard which documents the current Cookie header practice, limiting
itself to security issues.  In his opinion, the http-wg should not try
to decide on privacy mechanisms, but instead document whatever privacy
mechanisms the browser implementers would end up using.

It was noted that Cookies as used in practice present a security
issue since they are used for authentication, and might represent
passwords in the clear.

[**] WG SCHEDULE & MILESTONES
Larry Masinter led a discussion of the WG schedule.  The goal is to
move HTTP/1.1 to draft standard in November 1997.  The content
negotiation work should also be completed in November 1997.
It was suggested that we could complete work on every document
outside of the main non-HTTP/1.1 working items (for example TCN,
state management) before the next IETF meeting in December.
Closing the WG at or before the December 1997 IETF meeting is
not realistic.  Ongoing implementation efforts and planned
interoperability tests may lead to additional HTTP/1.1 issues, and it
is unlikely that the http-wg will be able to close all these issues
before December.

Current schedule:
  07/97: Hit metering to Proposed
  08/97: additional drafts
  09/97: additional drafts
  11/97: HTTP/1.1 -> Draft Standard
         Content negotiation drafts -> Experimental

The working group meeting ended with an announcement of the
HTTP-NG requirements BOF on Thursday.
From - Wed Sep 10 16:05:28 1997
Received: from ietf.org by ietf.org id aa13267; 7 Sep 97 20:39 EDT
Received: from alpha.Xerox.COM by ietf.org id aa13263; 7 Sep 97 20:39 EDT
Received: from casablanca.parc.xerox.com ([13.2.16.111]) by alpha.xerox.com with SMTP id <54525(2)>; Sun, 7 Sep 1997 17:39:03 PDT
Received: from bronze ([13.2.17.210]) by casablanca.parc.xerox.com with SMTP id <71811>; Sun, 7 Sep 1997 17:38:46 PDT
Message-ID: <[e-mail]>
Date: Sun, 7 Sep 1997 17:38:30 PDT
Sender:[e-mail]
From: Larry Masinter <[e-mail]>
Organization: Xerox PARC
X-Mailer: Mozilla 4.01 [en] (Win95; U)
MIME-Version: 1.0
To: [e-mail]
Subject: Minutes, HTTP working group, Munich IETF Aug 11-12
X-Priority: 3 (Normal)
Content-Type: multipart/mixed; boundary="------------9B4DD868F14BE582055CBFEE"
Status:
X-Mozilla-Status: 8001

This is a multi-part message in MIME format.
--------------9B4DD868F14BE582055CBFEE
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

These are the minutes of the HTTP working group meetings at the Munich
IETF, August 11-12, 1997, edited by Larry Masinter, based on minutes
reported by Koen Holtman, Martin Du"rst and Chantelle Cooper.

Monday, August 11

The group focused on the issues in the issue list
        http://www.w3.org/pub/WWW/Protocols/HTTP/Issues/
Numbers in [brackets] are the issue number in the issue list.

The 08 version of http/1.1 draft did not appear in the
internet drafts directory before the meeting; the Internet
Drafts editor had problems processing last minute submissions.

[1] 301-302, [2] VERSION, [3] RE-VERSION were discussed Monday,
but see notes on Tuesday session.

[4] REDIRECTS (How many redirects required?)
We discussed the issue of the limit on the number of redirects which
a server can expect a client to implement. Proposal:
this belonged in an application profile (of HTTP, HTML, etc.) and not
in the HTTP spec, which should have mandatory (SHOULD, MUST)
redirects removed and replaced with an implementation note.

[5] LINK_HEADER
There seems to be a conflict between HTML and HTTP regarding the
interpretation of Link header. Resolution: Remove the Link
header from the main HTTP/1.1 spec. Dan Connolly will submit an
Draft to align HTTP and HTML definitions of this header.
The draft may proceed on standards track independently.

[6] CONTENT-ENCODING
The room seemed to be happy with the proposed resolution;
also, it seems to be consistent with Apache & MSIE implementations.

[7] CACHING-CGI
We got into this state because some origin servers might have counted
on the (simple optimization) that proxies (usually) didn't cache
URLs with queries or /cgi/ in them. But this was never part of the
specification. We concluded that the new text in the -08
revision (requiring caches to treat responses as uncacheable based on
some patterns in the request URL) should not stay as a requirement.
Jim Gettys will revert the requirements for treating responses as
uncacheable to those in the 2068 RFC.  He may rework the new URL
pattern text into an implementation note.

[8] WARNINGS
Klaus Weide sent comments to the mailing list which should be
responded to. There are several issues that are left to be resolved.

[10] OPTIONS
(See notes discussion on Tuesday)

[11] DATE-IF-MODIFIED, [12] 403VS404: these were declared
'editorial', see next draft for proposed wording.

[13] PUT-RANGE
We discussed whether we should deal with this issue at all,
or merely forbid PUT with a byte range in HTTP/1.1.
Proposed resolution: warn that using PUT with byte ranges
is dangerous and not compatible with 1.0 or servers that don't
accept-ranges.
The WEBDAV group worked on this, but seem to have decided
that it was too complex.
Paul Leach will submit a proposal soon; the WG will wait
and see how complex Paul's proposal might be.

[14] HOST
Jim Gettys will draft proposed text, to the effect
("Proxy can add, but not rewrite")

[15] AGE-CALCULATION
This issue has been debated at length. Jeff Mogul will ubmit an internet
draft countering the position on this issue taken in Roy Fielding's
draft. Once we have two drafts, we will evaluate them and decide.

[16] RE-AUTHENTICATION-REQUESTED
Should there be a revalidation request code? This needs mailing
list discussion. It's marked as 'drafting'.

[17] SAFE [18] UAHINT
Given the current status, Keith Moore's suggested these be released as
Experimental RFCs. Larry Masinter will initiate this.

[19] AUTH-CHUNKED
The proposed fix is in draft 08, and ready for last call.

[20] REQUIRE-DIGEST
There needs to be some way to require that Digest authentication
be used. The draft has been issued is ready for last call; John
Franks had comments which need to be responded to.

[21] PROXY-REDIRECT
There was a lot of discussion about security and privacy issues,
and the 08 draft does not address these issues.
In particular, the scope restrictions in 305 processing are not
restrictive enough, and alternative scoping rules are needed.
There may be a privacy concern with respect to redirection of
client requests to other servers without informing or asking
the user for consent.
There's a security difficulty with a permanent redirection to a proxy
without user recognition or consent.

Yaron Goland had doubts about defining the 306 functionality inside
HTTP; formats different from the Set-Proxy header format may be
more appropriate as a means of reconfiguring client caches.
It was decided to continue this discussion outside the meeting.

[25] PROXY-LENGTH
The content-length additions to the 08 draft caused some
self-contradictions. Koen Holtman will send a message about
this to the mailing list.

[34] QUOTED-BACK ([32] COMMENT)
A compatibility note seemed to be missing from the 08 draft.
Jim Gettys will add this note, with appropriate cross-referencing.

[204] DISPOSITION RFC 1806
Keith Moore's Content-Disposition document, which is currently in the
RFC pipeline, doesn't mention the HTTP usage or syntax.
Larry Masinter and Keith will put together a paragraph to be added
to the C-D draft, either before or after it goes to RFC.

[59] CLOSE (Who should close the connection?)
Jim Gettys promised a revised internet draft soon.

[201] REQUIREMENTS (Need table of requirements like RFC 1122 and 1123)
We discussed creating the index of HTTP requirements. The requirements
table can also serve as a checklist to document independent
implementations for each HTTP/1.1 feature.

We discussed having a 'HTTP/1.1 interoperability test' event,
as a means of documenting compliance and getting implementor
feedback about remaining problems. There was a lot of interest.
Quentin Clark offered to help organize this, in order to be
able to report on the results of interoperability by the Dec 97
IETF.

[**] Basic/Digest
There was some confusion about the status of Basic & Digest
authentication
in the -08 draft. The goal is to keep "HTTP/1.1" as two documents,
one on the main protocol and a separate draft on "authentication",
but that both would be required for compliance with HTTP/1.1.

Tuesday 8/12
---------------

CONTENT NEGOTIATION
Koen Holtman gave an overview of the current Transparent CN drafts
(draft-ietf-http-negotiation-03.txt, draft-ietf-http-rvsa-v10-02.txt),
and the history, goals, and test implementations.

Jim Gettys noted that the "Alternates" header might progress faster
outside of the rest of TCN. We decided to split
draft-ietf-http-negotiation-03.txt into two drafts, one with the
Alternates header which might move to Proposed Standard while the
rest of TCN can move to Experimental status.

We discussed the feature registration drafts
(draft-ietf-http-feature-reg-02.txt,
draft-ietf-http-feature-scenarios-01.txt).  It has wide
applicability and should go to BCP. Some questions, such as "should
features be URLs?" and "are the types used the right ones?" may need
further examination.

Ted Hardie and Graham Klyne will expand the current
draft-ietf-http-negotiate-scenario-01.txt into a more general
requirement and scenarios document that will cover other cases of
feature and capability negotiation; it will likely become
an Informational RFC.

There is interest in forming a 'negotiation subgroup', which
may continue working independent of HTTP-WG.

[2] VERSION [3] RE-VERSION (Version number returned by servers)
There was an offline discussion Monday afternoon, reported
on Tuesday.

RFC 2145 might need clarification of the result of the interactions
between CGI scripts, proxies, servers; old CGI scripts working
with new servers.

The entity (or "message payload") version number should supercede
the server's version number. The HTTP versioning requirements
in RFC2145 will probably not cause problems for proxies.
Some language should be added to the 1.1 spec to make it more clear
what proxies should do, and what they cannot be expected to do,
when upgrading and downgrading responses between 1.1 and 1.0.
It was suggested that a proxy's cache entries be upgraded
to the highest version of the client request & server response,
as a solution to the ambiguity of labelling cache entries.


[1] 301-302 (Problems with redirecting requests.)
Josh Cohen reported on the conclusions of an offline discussion.
302's historical use has not been changed by most servers and
script writers to the new definition in RFC 2068.

The text in the -08 draft should be changed, either by
        a) reverse the meanings of 302 & 303
        b) Deprecate 302 and add 307
The consensus of the meeting was to take path (a).
The issue will be raised on the mailing list.

[**] PEP discussion
Discussion of Henrik's new draft of 14 July centered around
the question of how much complexity is needed for
 a) querying about the availability of protocol extensions
 b) negotiating on and detecting the use of protocol extensions

Yaron Goland said that the current PEP spec was so complex that he
feared that lots of people would only implement subsets, with the
subset implementations ending up being incompatible with each other.

Some alternatives to PEP were discussed:
 - the proposed OPTIONS mechanism
 - the old Mandatory header field mechanism
 - an IANA-based header field name registry

OPTIONS is not a subset of PEP capabilities, and isn't intended to be.

It was the general feeling that something simpler than PEP might well
be sufficient for meeting the HTTP protocol extension needs of the
internet community, but that the WG did not have sufficient data to
know for sure.  Jim Gettys asserted that most potential users of PEP
were not in contact with the HTTP-WG.

Some people reported that the JEPI initiative, which was planning to
use PEP, is basically `dead'.  Someone from the RTSP group reported
that they had implemented a subset of PEP, and that it could be
possible that the RTSP needs would also be satisfied by OPTIONS or the
Mandatory header.

Jim Gettys said that he felt that header clashes due to independently
developed protocol extension were a real potential problem, and that
the the http-wg ought to address this problem in some way, either with
PEP or with something else.  Koen Holtman remarked that the current
and previous PEP drafts caused their own header clash problems because
they basically allocated all remaining header field names for potential
use by PEP, and that this would have to be fixed if work on PEP were to
be continued.

Keith Moore remarked that, from a distance, it looked to him as if PEP
was a solution in search of a problem, and that PEP review might be
out of scope for HTTP-WG.

[10] OPTIONS
Josh Cohen reported on his motivation for proposing the OPTIONS
mechanism: he discovered that he needed it when specifying the proxy
redirect mechanisms.  He felt an urgent need for a mandatory HTTP/1.1
extensions discovery mechanism, and that it should be bundled with the
main HTTP/1.1 spec. Josh wanted to keep the mechanism very simple,
so that quick progress could be made, and feared that having a general
registration mechanism in addition to the `RFC=' and `HDR=' vocabulary
in the current options draft would slow things down too much.

Does the current draft really addresses the necessary option/extension
discovery scenarios?  For example, what if a server does not implement
some SHOULDs in an RFC? Which SHOULDs are ignored?
Yaron Goland noted that WEBDAV defined three levels of compliance,
so that the `RFC=' mechanism in the current options draft would not be
sufficient for WEBDAV discovery needs.

Larry Masinter (not speaking as the chair) noted that OPTIONS
defined yet another name space, and that the namespace of options
could probably use the proposed feature tag registry, and asked
the working group to consider whether this was desirable. For that
matter, the namespace could be shared with PEP extensions.


Koen Holtman cautioned against rushing out a mechanism too quickly,
without careful consideration of all details.

We agreed to finish work on OPTIONS quickly, and consider it as part of
the HTTP/1.1 spec or as a separate draft.

[***] Query Internationalization

Martin Du"rst briefly reviewed the issues in internationalization
of web form submission, and the possible solutions, as recorded in
his recent internet drafts.  This issue goes beyond HTTP, but
the proposed the proposed solution involves a negotiation mechanism
based on a HTTP header (Query-UTF-8).

Those interested should discuss this issue on the
[e-mail] mailing list.

[***] Status codes sharing
Johnathan Rosenberg was going to present draft-schulzrinne-http...
but was missing from the room; we wound up not discussing the issue.

[***] State Management

  [--] Cookie Comment/CommentURL

The working group mailing list seemed to have been filled with
discussion of the Comment-URL feature.

Larry Masinter gave his (personal) views on the comment and commentURL
mechanisms. While it is a very good thing for service authors to
inform users about the cookie-related privacy policies of the site,
the comment and commentURL mechanisms are not the appropriate
mechanisms to convey this information, and that these mechanisms
should be removed from the draft.  There was some agreement on
removing comment and commentURLs from the audience.

Koen Holtman said that, lacking a concrete proposal for an alternative
means of conveying the information, he did not mind if comment and
commentURLs stayed in.

 [--] Set-Cookie2

There's some concern that discussion of the technical protocol in
RFC 2109 was being held up due to concern about the privacy
considerations and provisions in it. The objection to RFC 2109
is that it does not reflect current practice. Yaron Goland
asserted that the changes in 2109 from Netscape's first cookie
spec are not wanted and will not be implemented.

Larry Masinter suggested separating the draft into two parts,
although releasing them simultaneously. One part would discuss
the protocol, and the other draft would discuss the privacy
considerations.

Dan Jaye reported on his recent revision of the trust-state draft: he
said he would mail draft-ietf-jaye-trust-state-01.txt to the list
soon (an attempt to mail it before the meeting failed).  Dan Jaye and
Yaron Goland asserted that implementers wanted to use PICS-based
cookie labeling as a privacy technology, and not the proposals in the
state management draft.  Yaron Goland said that, in his opinion, the
effort on revising the Set-Cookie2 based state management draft should
be stopped.  In stead, the http-wg should concentrate on writing a
standard which documents the current Cookie header practice, limiting
itself to security issues.  In his opinion, the http-wg should not try
to decide on privacy mechanisms, but instead document whatever privacy
mechanisms the browser implementers would end up using.

It was noted that Cookies as used in practice present a security
issue since they are used for authentication, and might represent
passwords in the clear.

[**] WG SCHEDULE & MILESTONES
Larry Masinter led a discussion of the WG schedule.  The goal is to
move HTTP/1.1 to draft standard in November 1997.  The content
negotiation work should also be completed in November 1997.
It was suggested that we could complete work on every document
outside of the main non-HTTP/1.1 working items (for example TCN,
state management) before the next IETF meeting in December.
Closing the WG at or before the December 1997 IETF meeting is
not realistic.  Ongoing implementation efforts and planned
interoperability tests may lead to additional HTTP/1.1 issues, and it
is unlikely that the http-wg will be able to close all these issues
before December.

Current schedule:
  07/97: Hit metering to Proposed
  08/97: additional drafts
  09/97: additional drafts
  11/97: HTTP/1.1 -> Draft Standard
         Content negotiation drafts -> Experimental

The working group meeting ended with an announcement of the
HTTP-NG requirements BOF on Thursday.
--------------9B4DD868F14BE582055CBFEE
Content-Type: message/rfc822
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

Received: from alpha.xerox.com ([13.1.64.93]) by casablanca.parc.xerox.com with SMTP id <71811>; Sun, 7 Sep 1997 09:51:35 PDT
Received: from casablanca.parc.xerox.com ([13.2.16.111]) by alpha.xerox.com with SMTP id <53626(2)>; Sun, 7 Sep 1997 09:51:32 PDT
Received: by casablanca.parc.xerox.com id <71811>; Sun, 7 Sep 1997 09:51:21 PDT
To: <[e-mail]>
From: The Post Office <[e-mail]>
Sender: [e-mail]
Subject: Delivery problems with your mail
Cc: The Post Office <[e-mail]>
Message-Id: <97Sep7.095121pdt."71811"@casablanca.parc.xerox.com>
Date: Sun, 7 Sep 1997 09:51:21 PDT

A copy of your message is being returned to you due to difficulties
encountered while attempting to deliver your mail.

The following errors occurred during message delivery processing:


<hold NS:iesg.org/cname [e-mail] 65534>: expired after 3 days, problem was: domain name service at destination failed

----------  Original Message  ----------
external
rcvdfrom bronze.parc.xerox.com ([13.1.100.114])
with SMTP
from <[e-mail]>
to <[e-mail]>
to <[e-mail]>
Message-ID: <[e-mail]>
Date: Thu, 04 Sep 1997 10:32:07 -0700
From: Larry Masinter <[e-mail]>
Organization: Xerox PARC
X-Mailer: Mozilla 4.01 [en] (Win95; U)
MIME-Version: 1.0
To: [e-mail]
CC: [e-mail]
Subject: (revised) Minutes, HTTP Working Group, Munich IETF Aug 11-12
X-Priority: 3 (Normal)
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

These are the minutes of the HTTP working group meetings at the Munich
IETF, August 11-12, 1997, edited by Larry Masinter, based on minutes
reported by Koen Holtman, Martin Du"rst and Chantelle Cooper.

Monday, August 11

The group focused on the issues in the issue list
        http://www.w3.org/pub/WWW/Protocols/HTTP/Issues/
Numbers in [brackets] are the issue number in the issue list.

The 08 version of http/1.1 draft did not appear in the
internet drafts directory before the meeting; the Internet
Drafts editor had problems processing last minute submissions.

[1] 301-302, [2] VERSION, [3] RE-VERSION were discussed Monday,
but see notes on Tuesday session.

[4] REDIRECTS (How many redirects required?)
We discussed the issue of the limit on the number of redirects which
a server can expect a client to implement. Proposal:
this belonged in an application profile (of HTTP, HTML, etc.) and not
in the HTTP spec, which should have mandatory (SHOULD, MUST)
redirects removed and replaced with an implementation note.

[5] LINK_HEADER
There seems to be a conflict between HTML and HTTP regarding the
interpretation of Link header. Resolution: Remove the Link
header from the main HTTP/1.1 spec. Dan Connolly will submit an
Draft to align HTTP and HTML definitions of this header.
The draft may proceed on standards track independently.

[6] CONTENT-ENCODING
The room seemed to be happy with the proposed resolution;
also, it seems to be consistent with Apache & MSIE implementations.

[7] CACHING-CGI
We got into this state because some origin servers might have counted
on the (simple optimization) that proxies (usually) didn't cache
URLs with queries or /cgi/ in them. But this was never part of the
specification. We concluded that the new text in the -08
revision (requiring caches to treat responses as uncacheable based on
some patterns in the request URL) should not stay as a requirement.
Jim Gettys will revert the requirements for treating responses as
uncacheable to those in the 2068 RFC.  He may rework the new URL
pattern text into an implementation note.

[8] WARNINGS
Klaus Weide sent comments to the mailing list which should be
responded to. There are several issues that are left to be resolved.

[10] OPTIONS
(See notes discussion on Tuesday)

[11] DATE-IF-MODIFIED, [12] 403VS404: these were declared
'editorial', see next draft for proposed wording.

[13] PUT-RANGE
We discussed whether we should deal with this issue at all,
or merely forbid PUT with a byte range in HTTP/1.1.
Proposed resolution: warn that using PUT with byte ranges
is dangerous and not compatible with 1.0 or servers that don't
accept-ranges.
The WEBDAV group worked on this, but seem to have decided
that it was too complex.
Paul Leach will submit a proposal soon; the WG will wait
and see how complex Paul's proposal might be.

[14] HOST
Jim Gettys will draft proposed text, to the effect
("Proxy can add, but not rewrite")

[15] AGE-CALCULATION
This issue has been debated at length. Jeff Mogul will ubmit an internet
draft countering the position on this issue taken in Roy Fielding's
draft. Once we have two drafts, we will evaluate them and decide.

[16] RE-AUTHENTICATION-REQUESTED
Should there be a revalidation request code? This needs mailing
list discussion. It's marked as 'drafting'.

[17] SAFE [18] UAHINT
Given the current status, Keith Moore's suggested these be released as
Experimental RFCs. Larry Masinter will initiate this.

[19] AUTH-CHUNKED
The proposed fix is in draft 08, and ready for last call.

[20] REQUIRE-DIGEST
There needs to be some way to require that Digest authentication
be used. The draft has been issued is ready for last call; John
Franks had comments which need to be responded to.

[21] PROXY-REDIRECT
There was a lot of discussion about security and privacy issues,
and the 08 draft does not address these issues.
In particular, the scope restrictions in 305 processing are not
restrictive enough, and alternative scoping rules are needed.
There may be a privacy concern with respect to redirection of
client requests to other servers without informing or asking
the user for consent.
There's a security difficulty with a permanent redirection to a proxy
without user recognition or consent.

Yaron Goland had doubts about defining the 306 functionality inside
HTTP; formats different from the Set-Proxy header format may be
more appropriate as a means of reconfiguring client caches.
It was decided to continue this discussion outside the meeting.

[25] PROXY-LENGTH
The content-length additions to the 08 draft caused some
self-contradictions. Koen Holtman will send a message about
this to the mailing list.

[34] QUOTED-BACK ([32] COMMENT)
A compatibility note seemed to be missing from the 08 draft.
Jim Gettys will add this note, with appropriate cross-referencing.

[204] DISPOSITION RFC 1806
Keith Moore's Content-Disposition document, which is currently in the
RFC pipeline, doesn't mention the HTTP usage or syntax.
Larry Masinter and Keith will put together a paragraph to be added
to the C-D draft, either before or after it goes to RFC.

[59] CLOSE (Who should close the connection?)
Jim Gettys promised a revised internet draft soon.

[201] REQUIREMENTS (Need table of requirements like RFC 1122 and 1123)
We discussed creating the index of HTTP requirements. The requirements
table can also serve as a checklist to document independent
implementations for each HTTP/1.1 feature.

We discussed having a 'HTTP/1.1 interoperability test' event,
as a means of documenting compliance and getting implementor
feedback about remaining problems. There was a lot of interest.
Quentin Clark offered to help organize this, in order to be
able to report on the results of interoperability by the Dec 97
IETF.

[**] Basic/Digest
There was some confusion about the status of Basic & Digest
authentication
in the -08 draft. The goal is to keep "HTTP/1.1" as two documents,
one on the main protocol and a separate draft on "authentication",
but that both would be required for compliance with HTTP/1.1.

Tuesday 8/12
---------------

CONTENT NEGOTIATION
Koen Holtman gave an overview of the current Transparent CN drafts
(draft-ietf-http-negotiation-03.txt, draft-ietf-http-rvsa-v10-02.txt),
and the history, goals, and test implementations.

Jim Gettys noted that the "Alternates" header might progress faster
outside of the rest of TCN. We decided to split
draft-ietf-http-negotiation-03.txt into two drafts, one with the
Alternates header which might move to Proposed Standard while the
rest of TCN can move to Experimental status.

We discussed the feature registration drafts
(draft-ietf-http-feature-reg-02.txt,
draft-ietf-http-feature-scenarios-01.txt).  It has wide
applicability and should go to BCP. Some questions, such as "should
features be URLs?" and "are the types used the right ones?" may need
further examination.

Ted Hardie and Graham Klyne will expand the current
draft-ietf-http-negotiate-scenario-01.txt into a more general
requirement and scenarios document that will cover other cases of
feature and capability negotiation; it will likely become
an Informational RFC.

There is interest in forming a 'negotiation subgroup', which
may continue working independent of HTTP-WG.

[2] VERSION [3] RE-VERSION (Version number returned by servers)
There was an offline discussion Monday afternoon, reported
on Tuesday.

RFC 2145 might need clarification of the result of the interactions
between CGI scripts, proxies, servers; old CGI scripts working
with new servers.

The entity (or "message payload") version number should supercede
the server's version number. The HTTP versioning requirements
in RFC2145 will probably not cause problems for proxies.
Some language should be added to the 1.1 spec to make it more clear
what proxies should do, and what they cannot be expected to do,
when upgrading and downgrading responses between 1.1 and 1.0.
It was suggested that a proxy's cache entries be upgraded
to the highest version of the client request & server response,
as a solution to the ambiguity of labelling cache entries.


[1] 301-302 (Problems with redirecting requests.)
Josh Cohen reported on the conclusions of an offline discussion.
302's historical use has not been changed by most servers and
script writers to the new definition in RFC 2068.

The text in the -08 draft should be changed, either by
        a) reverse the meanings of 302 & 303
        b) Deprecate 302 and add 307
The consensus of the meeting was to take path (a).
The issue will be raised on the mailing list.

[**] PEP discussion
Discussion of Henrik's new draft of 14 July centered around
the question of how much complexity is needed for
 a) querying about the availability of protocol extensions
 b) negotiating on and detecting the use of protocol extensions

Yaron Goland said that the current PEP spec was so complex that he
feared that lots of people would only implement subsets, with the
subset implementations ending up being incompatible with each other.

Some alternatives to PEP were discussed:
 - the proposed OPTIONS mechanism
 - the old Mandatory header field mechanism
 - an IANA-based header field name registry

OPTIONS is not a subset of PEP capabilities, and isn't intended to be.

It was the general feeling that something simpler than PEP might well
be sufficient for meeting the HTTP protocol extension needs of the
internet community, but that the WG did not have sufficient data to
know for sure.  Jim Gettys asserted that most potential users of PEP
were not in contact with the HTTP-WG.

Some people reported that the JEPI initiative, which was planning to
use PEP, is basically `dead'.  Someone from the RTSP group reported
that they had implemented a subset of PEP, and that it could be
possible that the RTSP needs would also be satisfied by OPTIONS or the
Mandatory header.

Jim Gettys said that he felt that header clashes due to independently
developed protocol extension were a real potential problem, and that
the the http-wg ought to address this problem in some way, either with
PEP or with something else.  Koen Holtman remarked that the current
and previous PEP drafts caused their own header clash problems because
they basically allocated all remaining header field names for potential
use by PEP, and that this would have to be fixed if work on PEP were to
be continued.

Keith Moore remarked that, from a distance, it looked to him as if PEP
was a solution in search of a problem, and that PEP review might be
out of scope for HTTP-WG.

[10] OPTIONS
Josh Cohen reported on his motivation for proposing the OPTIONS
mechanism: he discovered that he needed it when specifying the proxy
redirect mechanisms.  He felt an urgent need for a mandatory HTTP/1.1
extensions discovery mechanism, and that it should be bundled with the
main HTTP/1.1 spec. Josh wanted to keep the mechanism very simple,
so that quick progress could be made, and feared that having a general
registration mechanism in addition to the `RFC=' and `HDR=' vocabulary
in the current options draft would slow things down too much.

Does the current draft really addresses the necessary option/extension
discovery scenarios?  For example, what if a server does not implement
some SHOULDs in an RFC? Which SHOULDs are ignored?
Yaron Goland noted that WEBDAV defined three levels of compliance,
so that the `RFC=' mechanism in the current options draft would not be
sufficient for WEBDAV discovery needs.

Larry Masinter (not speaking as the chair) noted that OPTIONS
defined yet another name space, and that the namespace of options
could probably use the proposed feature tag registry, and asked
the working group to consider whether this was desirable. For that
matter, the namespace could be shared with PEP extensions.


Koen Holtman cautioned against rushing out a mechanism too quickly,
without careful consideration of all details.

We agreed to finish work on OPTIONS quickly, and consider it as part of
the HTTP/1.1 spec or as a separate draft.

[***] Query Internationalization

Martin Du"rst briefly reviewed the issues in internationalization
of web form submission, and the possible solutions, as recorded in
his recent internet drafts.  This issue goes beyond HTTP, but
the proposed the proposed solution involves a negotiation mechanism
based on a HTTP header (Query-UTF-8).

Those interested should discuss this issue on the
[e-mail] mailing list.

[***] Status codes sharing
Johnathan Rosenberg was going to present draft-schulzrinne-http...
but was missing from the room; we wound up not discussing the issue.

[***] State Management

  [--] Cookie Comment/CommentURL

The working group mailing list seemed to have been filled with
discussion of the Comment-URL feature.

Larry Masinter gave his (personal) views on the comment and commentURL
mechanisms. While it is a very good thing for service authors to
inform users about the cookie-related privacy policies of the site,
the comment and commentURL mechanisms are not the appropriate
mechanisms to convey this information, and that these mechanisms
should be removed from the draft.  There was some agreement on
removing comment and commentURLs from the audience.

Koen Holtman said that, lacking a concrete proposal for an alternative
means of conveying the information, he did not mind if comment and
commentURLs stayed in.

 [--] Set-Cookie2

There's some concern that discussion of the technical protocol in
RFC 2109 was being held up due to concern about the privacy
considerations and provisions in it. The objection to RFC 2109
is that it does not reflect current practice. Yaron Goland
asserted that the changes in 2109 from Netscape's first cookie
spec are not wanted and will not be implemented.

Larry Masinter suggested separating the draft into two parts,
although releasing them simultaneously. One part would discuss
the protocol, and the other draft would discuss the privacy
considerations.

Dan Jaye reported on his recent revision of the trust-state draft: he
said he would mail draft-ietf-jaye-trust-state-01.txt to the list
soon (an attempt to mail it before the meeting failed).  Dan Jaye and
Yaron Goland asserted that implementers wanted to use PICS-based
cookie labeling as a privacy technology, and not the proposals in the
state management draft.  Yaron Goland said that, in his opinion, the
effort on revising the Set-Cookie2 based state management draft should
be stopped.  In stead, the http-wg should concentrate on writing a
standard which documents the current Cookie header practice, limiting
itself to security issues.  In his opinion, the http-wg should not try
to decide on privacy mechanisms, but instead document whatever privacy
mechanisms the browser implementers would end up using.

It was noted that Cookies as used in practice present a security
issue since they are used for authentication, and might represent
passwords in the clear.

[**] WG SCHEDULE & MILESTONES
Larry Masinter led a discussion of the WG schedule.  The goal is to
move HTTP/1.1 to draft standard in November 1997.  The content
negotiation work should also be completed in November 1997.
It was suggested that we could complete work on every document
outside of the main non-HTTP/1.1 working items (for example TCN,
state management) before the next IETF meeting in December.
Closing the WG at or before the December 1997 IETF meeting is
not realistic.  Ongoing implementation efforts and planned
interoperability tests may lead to additional HTTP/1.1 issues, and it
is unlikely that the http-wg will be able to close all these issues
before December.

Current schedule:
  07/97: Hit metering to Proposed
  08/97: additional drafts
  09/97: additional drafts
  11/97: HTTP/1.1 -> Draft Standard
         Content negotiation drafts -> Experimental

The working group meeting ended with an announcement of the
HTTP-NG requirements BOF on Thursday.


--------------9B4DD868F14BE582055CBFEE--