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 www-international@w3.org 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: <34134906.80A4359C@parc.xerox.com> Date: Sun, 7 Sep 1997 17:38:30 PDT Sender:minutes-request@ietf.org From: Larry Masinter Organization: Xerox PARC X-Mailer: Mozilla 4.01 [en] (Win95; U) MIME-Version: 1.0 To: minutes@ietf.org 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 www-international@w3.org 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: From: The Post Office Sender: mailer-daemon@parc.xerox.com Subject: Delivery problems with your mail Cc: The Post Office 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: : 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 to to Message-ID: <340EF097.22D8F421@parc.xerox.com> Date: Thu, 04 Sep 1997 10:32:07 -0700 From: Larry Masinter Organization: Xerox PARC X-Mailer: Mozilla 4.01 [en] (Win95; U) MIME-Version: 1.0 To: minutes@iesg.org CC: http-wg@cuckoo.hpl.hp.com 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 www-international@w3.org 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--