Minutes from Second HTTP session at IETF-40

Larry, all --

This is my transcript of the second session, and some abbreviated
"minutes." I did not take minutes for the first session on Monday,
though. I think we should submit Josh Cohen's slides as a separate
part of the proceeding rather than part of the (limited to 6-pages)
minutes.

HTTP-WG is dead, Long live HTTP!, Rohit Khare

========================================================== 
Minutes of the Dec 10th HTTP-WG meeting 
Reported by Rohit Khare, UC Irvine

The second session reported on the myriad HTTP-related activities
which will continue outside HTTP-WG, as well as the remainder of the
ISSUES list. In the previous days, there had been new meetings and
developments related to 1) interoperabilty of 1.1. implementations; 2)
closure on Authentication; 3) Privacy on the Web; 4) cookies; 5)
content-negotiation; 6) and extensions to 1.1.

To advance to DRAFT standard, the group needs to stabilize updates to
2068 and document at least two independent, interoperable
implementations of each feature -- not applications which support
every feature, not just shipping products. The previous night, a
half-dozen client, server, and proxy developers sat down with the
chair and editor to walk through the MUSTs and MUST NOTs section by
section. The main insight was that we'll need much more systematic
support to document the hundreds of requirements in HTTP/1.1. Caching,
in particular, seems to be the most fraught with difficulty. Scott
Lawrence agreed to continue his (very useful) Thursday testing bees;
and there was a survey of interest in face-to-face implementation
bake-offs or conference calls.

2069 had one concern raised that Digest does not work well with
proxies and not at all across multiple servers. Paul Leach will soon
post to the list a small tweak which addresses both (and issue a new
I-D?).

User Services sponsored a BOF on Web Privacy. April Marine reported
the broad support for investigating the nexus of trust issues around
the Web. A detailed charter awaits debate, though, on
web-priv@nasa.gov. A second BOF is projected for LA.

David Kristol, editor of the cookie spec, reported that a small group
of developers reviewed the outstanding issues with state management
and found one technical and one political problem left. Technically,
domain matching does not work with flat (intranet) domains where
"foo." is an FQDN. The latter is user notification of cookies from
unverifiable transactions -- should people be tracked by an external
source of inline images or applets or audio?

Recipient Feature Profile (nee content-negotiation), weaves together
extensibility threads from HTTP, printing, faxing, mail, and many
other application-layer protocols.Ted Hardie reported the conviction
the group will set up a registry as quickly as possible. Then, it may
tackle aggregation of features and a prototypical example of how to
store profiles within LDAP, etc.

The Extensions team reported a strawman charter for 1) producing an
FYI document of guidance on adding features, headers, and methods to
HTTP, 2) extending error response codes, 3) and simplifying PEP and
OPTIONS into a reliable extension hook. It is NOT an HTTP/1.2
group. Josh Cohen and Scott Lawrence will chair and edit,
respectively, an investigation into how-to-extend, not what-to-extend.

Finally, Jim Gettys continued working through the ISSUES
list. RE-VERSION: Henry Sanders will redocument the justification for
upgrading proxy connections to the highest supported version to the
list. PUT-RANGE is demoted as problematic (caches observe only a
subset of edits) and insufficient (can't insert or remove
ranges). This functionality will become PATCH in WebDAV, and hence
discouraged or forbidden in HTTP/1.1

This concluded the final meeting of the HTTP Working Group. Up next:
W3C has been working on experiments for HTTP-NG, which had a BOF at
39th IETF and will surely be heard from in 1998.

==========================================================
Transcript of the second HTTP session, Dec 10th 
Reported by Rohit Khare, UC Irvine.

Reports on interoperability check, webpriv, state, extend, conneg,
issues on digest, closing plans (the very,very, very last meeting
ever!)


========== 
Frankenstein's Bride (JG)

JG: for DRAFT, we MUST show two INDEPENDENT IMPLEMENTATIONS of EACH
FEATURE which are INTEROPERABLE -- not products which implement ALL,
not necc. SHIPPING, either.

Keith concurs.

But, there are a lot of MAYs, SHOULDs, and so on.

After last night, I know how to proceed. We need something like
Mogul's requirements I-D. Even if it doesn't become Informational
RFC. JG appeals for volunteers to contribute time and technology to
manage this survey.

We spent 60-90 minutes polling each section around the dinner
table. Got through section 3. I'm more worried about the caching
section, where less work has been done.

Alternate solution is a f2f 2day retreat. I don't have the time
myself. Phone confs may help, 1-2 hrs at a time. We need to figure out
a process to satisfy IESG docs.

LM: we don't need too many people. Just two examples, remember.

Keith: we want assurneg, or, RFP (Recipient Feature Profile) (Ted Hardie)

We believe we can make progress quickly (by LA) on feature
registration.

Ted reported a slew of disposition decisions for existing drafts (see
conneg minutes).

Decision to setup registry *quickly*. Then the group will tackle
groups of features, to abbreviate lists.

Finally, creating at least one prototypical example of how to store
this information (e.g. in LDAP). This may or may not survive
charter-bashing and App AD advice.

LM: What's the earliest you can imagine advancing Informational? TH:
as soon as mid-January. Join the list NOW!

====== 
Extensions (Josh Cohen)

[he has HTML slides which should be available soon:
http://www.clock.org/~mutex/ietf ]

Theres a draft already out on transactional http. JC: That's right:
we're going to cite LOTS of examples of extensions to justify these
generic rules.

Kristol: I think people forget about interaction with proxies in
general. I'd like it explicitly considered (in the first part of the
outline).

Jim Whitehead: Based on my experience reading PEP, I had to read it
and talk to Henrik to figure it out. I think that we need a
REQUIREMENTS document. JC: I agree, we need to spend some time looking
at PEP.

JG calls upon Henrik to change RK's original naming of PEP.

Keith: there's no formal requirment for a BOF; we can just
proceeed. Because of our stds. liason requirements, we may need a
feedback cycle for "IESG is thinking of creating a WG".

JC: I hope this doesn't cause mission creep.

Keith: there's no requirement that we have to answer all these pieces
of feedback. It's just a week to notify people.

The new mailing list will be created and announced on the http-wg
list.

LM: calls for supporting Schulzrinne's extened error codes in this
group. Keith concurs; JG says the arguments against on http-wg were
really bogus.

JC agrees to add it to the charter.

======== 
The ISSUES List Rides Again....

JG resumes walking through the issues list.

-------
JG asks why RE-VERSION was called for.

Henry Sanders: If you DON'T upgrade the request, you'll get a
lower-version answer for your cache -- a subsequent 1.1 request CAN'T
be satisfied from a 1.0 cached response. 1.0 requests can be answered
from 1.1 responses. Richer responses can always be used to answer
simpler queries.
 
JG asks Henry to post his cogent answer to the list. Then, RE-VERSION
will be closed.

LM: How many people here believe there will be a 1.2?

Lots of "50-50" hands up.

------
PUT-RANGE

JG calls for discussion, not resolution (since Leach isn't here).

YG defends: the use might be in a proxy which updates a byterange of
its CACHED copy at the same time it passes back to the origin. I think
this is bad because of 1) in WebDAV, many proxies may have partial
views of the update changes. So, you'd have to recheck e-tags to
update caches -- and redownload all that material. 2) more to the
point, editing ususally adds and removes material, which put-range
does not do.

YG, discussing with PL, resolves that the WebDAV group's PATCH method
should split off to handle this.

LM, JG: likely outcome is to take put-range OUT. The draft will say
"don't do put with byteranges"

LM: the convincing argument I heard is that it requires a robust
version number to detect the feature: a server that did PUT but not
byteranges, would REPLACE the whole resource. That's why it should be
forbidden, not discouraged.

JG: right now it's unspecified in the RFC, so now we need to add
language discouraging this.

----
RANGE WITH CONTENTCODING and TRAILER FIELDS to LAST CALL.

==========
CONCLUSION

LM's best estimate is that 20 more issues will be raised from the
interoperability testing. But regardless, this is the LAST
meeting. Scott Lawrence commits to continuing Thursday
interoperability tests until such time as testing becomes
uninteresting. mailing list will remain open indefinitely (or until
Standard status 2 years from now). You can also expect NG
efforts. Currently, it's at W3C, which is not closed, but not public,
either. In the long-term it will become a draft and proposal to IETF.

And there was much rejoicing... off to the bar.

Received on Thursday, 11 December 1997 02:38:54 UTC