Re: Straw-man charter for http-bis

[Chris Newman <[e-mail]>]

Here's my take as AD on some of the interesting topics in this thread:

1. HTTP Digest Authentication

The SASL WG appears to have decided that SASL DIGEST-MD5 is not a useful 
authentication mechanism for a number of technical reasons.  I would be 
uncomfortable having a WG spend a lot of time refining the existing HTTP Digest 
mechanism based on that experience.  However, documenting the i18n behavior of 
deployed implementations sounds like a sensible thing to do.

2. HTTP Security

Phishing demonstrates that HTTP's present security mechanisms are not adequate 
to meet some important requirements of the present users of the protocol.  I 
would be uncomfortable moving HTTP from Draft Standard to Standard given this 
situation.  It's likely that new work on HTTP security mechanisms (as outlined 
by draft-hartman-webauth-phishing) is necessary.  However, even with the 
present security situation, I have no doubt that RFC 2616 is widely useful and 
improving the technical clarity of the base specification is good work that 
would benefit the Internet community.  The minimum work necessary to make a 
draft standard revision of the base specification complete would be to clearly 
document the limitations of the presently deployed HTTP security mechanisms and 
the fact they are not adequate for all situations.  Beyond that I consider it 
inappropriate to hold publication of a useful revision hostage to new security 
engineering work.  That opinion may not be shared by others on the IESG. 
Regardless, I would very much like to see forward progress on the HTTP security 
situation.

3. One vs. Two WGs

I would support the formation of two separate WGs: HTTP and HTTP security as 
the people who have appropriate expertise for those efforts are not identical. 
Indeed I'd be uncomfortable with a single WG that was both revising 2616 and 
designing new HTTP security mechanisms as the latter may be helped by the 
attention of security experts that likely have no interest in the former.

4. Specification Rewrite

Because the IETF process gives quite a bit of control to the document editor 
and design teams, our process allows an alternate editor to produce a competing 
specification and ask for a WG consensus call to adopt that competing 
specification.  This is discussed in the following IESG Note:
   <http://www.ietf.org/IESG/STATEMENTS/Design-Teams.txt>
>From discussions here, I suspect it's unlikely an alternate specification would 
be adopted by the WG in this case, especially because it might drop the target 
status from draft to proposed for the reasons Keith mentioned.  However, this 
is an important mechanism the keep the process open.

                - Chris Newman
                Applications Area Director