Subject: WG Review: HyperText Transport Protocol Bis (httpbis)

From: IESG Secretary <[email-masked]>
Date: Thu, 11 Oct 2007 13:15:01 -0400

A new IETF working group has been proposed in the Application Area.  
The IESG has not made any determination as yet.  The following draft 
charter was submitted, and is provided for informational purposes only.  
Please send your comments to the IESG mailing list ([email-masked]) by 
October 17.

+++

HyperText Transport Protocol Bis (httpbis)
===========================================

Current Status: Proposed Working Group

Chairs:
TBD

Application Area Director(s):
Chris Newman <[email-masked]>
Lisa Dusseault <[email-masked]>

Mailing list:
http://lists.w3.org/Archives/Public/ietf-http-wg/

Description:

> HTTP is one of the most successful and widely-used protocols on the
> Internet today. However, its specification has several editorial
> issues. Additionally, after years of implementation and extension,
> several ambiguities have become evident, impairing interoperability
> and the ability to easily implement and use HTTP.
>
> The working group will refine RFC2616 to:
> * Incorporate errata and updates (e.g., references, IANA
> registries, ABNF)
> * Fix editorial problems which have led to misunderstandings of
> the specification
> * Clarify conformance requirements
> * Remove known ambiguities where they affect interoperability
> * Clarify existing methods of extensibility
> * Remove or deprecate those features that are not widely
> implemented and also unduly affect interoperability
> * Where necessary, add implementation advice
> * Document the security properties of HTTP and its associated
> mechanisms (e.g., Basic and Digest authentication, cookies, TLS) for
> common applications
>
> In doing so, it should consider:
> * Implementer experience
> * Demonstrated use of HTTP
> * Impact on existing implementations and deployments
>
> The Working Group must not introduce a new version of HTTP, and
> should not introduce new features or capabilities to HTTP.
>
> The Working Group's specification deliverables are:
> * A document that is suitable to supersede RFC 2616
> * A document cataloguing the security properties of HTTP
>
> Goals and Milestones:
> Nov 2007 - First HTTP Revision Internet Draft
> Dec 2007 - IETF 70 Meeting, Vancouver, BC, CA
> Feb 2008 - First HTTP Security Properties Internet Draft
> Mar 2008 - IETF 71 Meeting, Philadelphia, PA, USA
> Jun 2008 - Request Last Call for HTTP Revision
> Jul 2008 - IETF 72 Meeting, TBD
> Jul 2008 - Request Last Call for HTTP Security Properties
> Oct 2008 - Submit HTTP Revision to IESG for consideration as a Draft
> Standard
> Oct 2008 - Submit HTTP Security Properties to IESG for consideration
> as Informational

---

From: Ted Hardie <[email-masked]>
Date: Thu, 11 Oct 2007 10:54:27 -0700

I strongly support the formation of this working group.  I believe that
the charter below represents appropriate scope.  A minor concern is this

> > should not introduce new features or capabilities to HTTP.

"New features of capabilities to HTTP" is, sadly, somewhat ambiguous,
as there is some disagreement about the extension model for HTTP
(use of new methods vs. use of new MIME types, as an example).  Rather
than getting into that rat hole, I would suggest tightening this to say
something like:

"The Working Group must not introduce a new version of HTTP and
is not tasked with producing new methods, headers, or extension
mechanisms."

		regards,
			Ted Hardie

At 1:15 PM -0400 10/11/07, IESG Secretary wrote:
>_______________________________________________
>IETF-Announce mailing list
>[email-masked]
>https://www1.ietf.org/mailman/listinfo/ietf-announce

---

From: Lisa Dusseault <[email-masked]>
Date: Fri, 12 Oct 2007 10:28:31 -0700

Along with input on the charter, I'd appreciate suggestions,  
nominations and maybe even arm-twisting for finding chairs and editors.

thanks,
Lisa

---

From: Paul Hoffman <[email-masked]>
Date: Sun, 14 Oct 2007 13:56:32 -0400

>  . . .

This probably means not creating any new security mechanisms, but 
there is great interest in new security mechanisms for HTTP. Please 
consider adding "current" before "security properties" in the 
charter, but it is no big deal if you don't.

--Paul Hoffman, Director
--VPN Consortium

---

From: James M Snell <[email-masked]>
Date: Sun, 14 Oct 2007 12:39:34 -0700

IESG Secretary wrote:
>> [snip]

I would prefer that the latter also be a MUST NOT.

- James

---

From: Mark Nottingham <[email-masked]>
Date: Mon, 15 Oct 2007 15:55:00 +1000

>> * A document cataloguing the security properties of HTTP

The intent here was not to limit these deliverables to standalone  
RFCs, if the WG decides to publish multiple documents; this should be  
clarified if felt necessary.

Cheers,

--
Mark Nottingham       [email-masked]

---

From: "Frank Ellermann" <[email-masked]>
Date: Mon, 15 Oct 2007 11:01:50 +0200

Paul Hoffman wrote:
 
> Please consider adding "current" before "security properties"
> in the charter, but it is no big deal if you don't.

+1  It's not exactly clear what the charter says wrt 2617bis.

 Frank

---

From: "Mark Baker" <[email-masked]>
Date: Mon, 15 Oct 2007 12:38:36 -0400

> HyperText Transport Protocol Bis (httpbis)

Nobody has said it yet, so I might as well ... HTTP is a transfer
protocol, not a transport protocol.

Cheers,

Mark.
-- 
Mark Baker.  Ottawa, Ontario, CANADA.         http://www.markbaker.ca
Coactus; Web-inspired integration strategies  http://www.coactus.com

---

From: Mark Nottingham <[email-masked]>
Date: Tue, 16 Oct 2007 09:11:30 +1000

How did *that* get in there? :)

---

From: Lisa Dusseault <[email-masked]>
Date: Tue, 16 Oct 2007 15:14:11 -0700

I believe some run-time judgement may be needed on whether new  
features are really new, really features, and really "must not" be  
done.  If we decided that the "Foo" header was unclear or  
misimplemented, but fixing that header directly broke some proxies,  
what might be done?  Without adding new functionality, we could add a  
new "Foo2" header to with clearer syntax, options or implementation  
instructions  The new header could be used backwards-compatibly with  
the old one if both were used; implementations could prefer the new  
header but fall back to the old one.

Does a new header that provides clarity without adding any new  
functionality constitute a "new feature"?   I don't want to get into  
that semantic argument just because the charter says "MUST not  
introduce new features", however desirable and however related to  
existing functionality.  I'd like to have the argument about whether  
something is worthwhile and improves interoperability and maintains  
backwards-compatibility on its own merits.  I recommend we have the  
charter discourage new features, but without forbidding something in  
a way we may regret.

Lisa

---

From: "Roy T. Fielding" <[email-masked]>
Date: Tue, 16 Oct 2007 16:25:44 -0700

I would prefer that the IESG decide whether or not RFC 2616 needs
to be updated by a working group.  I would prefer that it not make
any technical decisions for that working group through the
imposition of charter constraints.

We do need a scope requirement that the resulting work products
of the WG be compatible with HTTP/1.1 as defined in RFC 2616+2617
(with allowance for the known errata).  However, I think the WG
can avoid running itself into the ground by keeping to a reasonable
discussion of what works and only specifying what is known to
be implemented in practice, letting the normal WG procedures
rein in the discussion to things HTTP/1.1.

In contrast, I think this part of the proposed charter

> should not introduce new features or capabilities to HTTP.

goes beyond that and makes a technical decision on what is best
for the evolution of HTTP before the WG even starts.  I don't
think that's why we have charters.  The WG can make that decision.

In any case, I have mostly completed the task of splitting
RFC 2616 into separate documents and am firmly convinced that
a complete rewrite of the document is worthwhile even if we
make no changes to the resulting protocol.

   http://labs.apache.org/webarch/http/draft-fielding-http/

Regarding RFC 2617 (HTTP Authentication), the HTTP WG (if we are
to have one) should be tasked with specifying all of HTTP.  The
previous experience of splitting HTTP security into a separate area
was an unmitigated disaster, for which we are still paying the
price of passwords in the clear, and I would prefer that the IETF
learn from that experience instead of repeating it.

HTTP access authentication needs to be specified by the people
who implement it, not by people who want to implement something
else instead.  I welcome those efforts to research, develop, and
deploy non-HTTP security mechanisms within other working groups
of the IETF without hindering the correct specification of an
update to RFC 2617 as it has been implemented by hundreds of
vendors, along with the specification of any new (Experimental)
authentication schemes that might fit within the extensible
framework defined by 2617.  I don't see any need for separate
working groups and, more importantly, believe it would be harmful
to try and progress HTTP along the standards track without
recognizing the protocol's dependency on HTTP authentication.

Cheers,

Roy T. Fielding                            <http://roy.gbiv.com/>
Chief Scientist, Day Software              <http://www.day.com/>

---

From: Mark Nottingham <[email-masked]>
Date: Wed, 17 Oct 2007 09:57:28 +1000

> think that's why we have charters.  The WG can make that decision.

I disagree; one of the functions of a good charter is to scope the  
work, so that participants understand what they've committed to do.  
It's a very effective tool for avoiding known ratholes. While the  
established procedures usually end in the correct result, it takes a  
lot of time to wade through all of the "I'd like to add a X header/ 
method/feature to HTTP" requests (as we see very often on the http  
list), and that can impede the progress of the WG. Letting people  
know that this is not the place that you take your favourite new  
protocol extension to is a good thing for both sides.

I'm fine with "should not introduce new features" here, by the way  
(i.e., I'm not holding out for "must not"). I just think the WG needs  
some guidance about the proposed scope of the group. I haven't yet  
heard anyone say that HTTP/1.2 or 2.0 is a good idea, and many have  
said it's a bad idea.

WRT authentication: I agree with most of what you say; it's just that  
such work would likely be on a much different timescale than revising  
2616. Re-chartering to do it afterwards has been discussed.

Cheers,

--
Mark Nottingham     http://www.mnot.net/

---

From: "Roy T. Fielding" <[email-masked]>
Date: Tue, 16 Oct 2007 18:06:36 -0700

On Oct 16, 2007, at 4:57 PM, Mark Nottingham wrote:
> It's a very effective tool for avoiding known ratholes.

The scope of the work is HTTP/1.1.

> While the established procedures usually end in the correct result,  
> it takes a lot of time to wade through all of the "I'd like to add  
> a X header/method/feature to HTTP" requests (as we see very often  
> on the http list), and that can impede the progress of the WG.  
> Letting people know that this is not the place that you take your  
> favourite new protocol extension to is a good thing for both sides.

We will get those requests anyway.  We get them right now, without
a group of any kind.  The charter proposal says that we can't do
anything constructive regarding those requests.  Without it, the
WG simply needs to make a decision with regard to how to handle
such requests.  The decision could be as simple as "please defer
any such discussion until after ..." or "we don't have that on our
agenda right now, but if you submit an individual draft we will
consider adding it to our agenda at the next meeting (or not)".

I received the same kind of request for HTTP when we were focused
on HTTP/1.0 "current practice".  John Franks wanted to add a Host
header field.  It was obviously needed, though it took much longer
for the WG to agree on the solution (the original one) than it
should have taken.  Should we have told him that it is out of
scope at the IETF until after the HTTP working group had concluded
(three years later)?

> (i.e., I'm not holding out for "must not"). I just think the WG  
> needs some guidance about the proposed scope of the group. I  
> haven't yet heard anyone say that HTTP/1.2 or 2.0 is a good idea,  
> and many have said it's a bad idea.
>
> WRT authentication: I agree with most of what you say; it's just  
> that such work would likely be on a much different timescale than  
> revising 2616. Re-chartering to do it afterwards has been discussed.

Chartering a working group is a long and time-consuming process,
as you know well. Most people don't even bother.  In any case, if
you want to charter the "Won't make any changes to RFC 2616 aside
from editorial bits WG", then go ahead.  If you ask for an
"HTTPbis WG", then I expect it to have a charter of "Revising the
HTTP specification", not "Revising only the things listed in this
charter because we already made up our minds".

Once we open the can, the worms will come wiggling out regardless
of the charter.  I'd prefer that the decision on what to do with
those worms be made by the community of vendors within the WG, not
anyone else.

....Roy

---

From: "Frank Ellermann" <[email-masked]>
Date: Wed, 17 Oct 2007 09:16:12 +0200

Mark Nottingham wrote:

> I haven't yet heard anyone say that HTTP/1.2 or 2.0 is a good idea

Ideally, after 2616bis and 2617bis are ready (maybe even as DS), you
could take 2616bis, s/Latin-1/UTF-8/g and s/URI/IRI/g, and republish
the result as HTTP/1.2 in a 2616ter.  

> revising 2616.

After 2616bis got a proper no-nonsense ABNF I'd also like to see a
corresponding no-nonsense ABNF in a future 2617bis.  Plus the fine
print, e.g. is 2616 md5-sess really incompatible with 2831 md5-sess.

 Frank

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Wed, 17 Oct 2007 14:21:22 +0200

On Thu, Oct 11, 2007 at 01:15:01PM -0400,
 IESG Secretary <[email-masked]> wrote 

> should not introduce new features or capabilities to HTTP.

So, are SRV records, as described in
http://www.anta.net/nic/draft-andrews-http-srv-01.shtml in scope or
not? It is not a change of HTTP itself. And the lack of these records
is a big problems for Web servers hosters.

---

From: James M Snell <[email-masked]>
Date: Wed, 17 Oct 2007 08:15:31 -0700

In the case that a new header or other type of mechanism is needed, I
would think that it would be entirely possible and appropriate to draft
that up in a separate I-D.

- James

Lisa Dusseault wrote:
> I believe some run-time judgement may be needed on whether new features
> are really new, really features, and really "must not" be done.  If we
> decided that the "Foo" header was unclear or misimplemented, but fixing
> that header directly broke some proxies, what might be done?  Without
> adding new functionality, we could add a new "Foo2" header to with
> clearer syntax, options or implementation instructions  The new header
> could be used backwards-compatibly with the old one if both were used;
> implementations could prefer the new header but fall back to the old one.
> 
> that semantic argument just because the charter says "MUST not introduce
> new features", however desirable and however related to existing
> functionality.  I'd like to have the argument about whether something is
> worthwhile and improves interoperability and maintains
> charter discourage new features, but without forbidding something in a
> way we may regret.
> 
> Lisa
>

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Wed, 17 Oct 2007 17:30:01 +0200

On Wed, Oct 17, 2007 at 08:15:31AM -0700,
 James M Snell <[email-masked]> wrote 
 a message of 46 lines which said:

> In the case that a new header or other type of mechanism is needed,
> I would think that it would be entirely possible and appropriate to
> draft that up in a separate I-D.

I don't think this was Lisa's point. The proposed charter says nothing
about one I-D or several (as in Roy's proposal). But it forbids any
addition to HTTP and Lisa's point was that it is too strict and too
early.

---

From: Julian Reschke <[email-masked]>
Date: Wed, 17 Oct 2007 19:05:57 +0200

Roy T. Fielding wrote:
> ...
> ...

I believe the current charter proposal attempts to constrain what we are 
doing in order:

- to avoid future requests to invent new authentication mechanisms 
(recall the long discussion about mandatory-to-implement security),

- to avoid that the (IMHO) most important part of the activity gets 
delayed because we're getting sidetracked too much by other nice-to-have 
stuff,

- to attract contributors who may be willing to invest their time only 
if there's a chance to produce a new document within a certain amount of 
time.

Personally I really don't care *how* we manage that. Whatever we do, I 
want to be sure that we can publish one document or a set of documents 
in 12 months without *then* being asked for a mandatory-to-implement 
security mechanism.

Best regards, Julian

---

From: Sam Hartman <[email-masked]>
Date: Wed, 17 Oct 2007 13:49:28 -0400

Another important aspect of the charter scope constraint is to make
sure that if the scope is expanded to include new headers or methods,
the entire IETF community is notified so people not currently
participating in the effort can join.

As such, I believe it is appropriate for the IETF community to place
this constraint on the HTTP working group.

---

From: "Roy T. Fielding" <[email-masked]>
Date: Wed, 17 Oct 2007 11:31:38 -0700

> participating in the effort can join.

There is no scope currently.  After the IESG makes its decision, then
the approved charter is sent to the IETF community and thereby notified
of the scope by that charter.

> this constraint on the HTTP working group.

Your logic escapes me.  I think it is important for the IESG to realize
that the IETF community is not yet even fully aware that the working
group has been proposed, let alone all of the private discussions
that went into proposing that specific charter.  There are less than
one percent of current HTTP implementations represented on the old
mailing list.  When the WG is approved and people start reporting on
it as an active group rather than just a bunch of folks with an
interest, then there will be awareness and I agree that any changes
at that point would indeed require rechartering.  That's why I am
suggesting the changes now, before the charter is approved.

....Roy

---

From: Sam Hartman <[email-masked]>
Date: Wed, 17 Oct 2007 19:32:15 -0400

>>>>> "Roy" == Roy T Fielding <[email-masked]> writes:

    Roy> On Oct 17, 2007, at 10:49 AM, Sam Hartman wrote:
    >> Another important aspect of the charter scope constraint is to
    >> make sure that if the scope is expanded to include new headers
    >> or methods, the entire IETF community is notified so people not
    >> currently participating in the effort can join.

    Roy> There is no scope currently.  After the IESG makes its
    Roy> decision, then the approved charter is sent to the IETF
    Roy> community and thereby notified of the scope by that charter.

There is a proposed scope.

    >> As such, I believe it is appropriate for the IETF community to
    >> place this constraint on the HTTP working group.

    Roy> Your logic escapes me.  I think it is important for the IESG
    Roy> to realize that the IETF community is not yet even fully
    Roy> aware that the working group has been proposed, 

It is our standard process to inform the ietf community of proposed
working groups through mail to ietf-announce; that has been done.
ALso, as is our common practice, we held a BOF on this issue.  The
scope restrictions at this time were discussed at the BOF.  It is my
opinion that there was broad support in the BOF for this scope
restriction.

You are correct that many people interested in HTTP may not currently
be part of the IETF community.  However I think that there are enough
people who are part of the IETF community who desire this scope
restriction that it has community support.

---

From: "Roy T. Fielding" <[email-masked]>
Date: Wed, 17 Oct 2007 17:08:41 -0700

> opinion that there was broad support in the BOF for this scope

Sorry, I was under the impression that the reason the IESG
asks for comments on a proposed charter is so that the comments
of the community can be considered.  If you aren't interested in
making changes to the scope, then this whole part of the process
is a waste of time (aside from fixing the obvious typo in the
WG name).  Let's just skip it and do something useful instead.

> restriction that it has community support.

The IETF community is not the people who show up for IETF meetings
every four months.  It is the Internet hardware and software community
that are impacted by the RFCs that they agree to adopt.

The IESG is fully capable of deciding that my comments are less
significant than the sum of bodies who happened to show up for
a BOF and appeared to have consensus.  I wasn't there and wouldn't
know.  I can only express my opinion and spend my time working on
what interests me.

....Roy