RE: Straw-man charter

> The working group will refine RFC2616 to:

See below (RFC2617 too)...

>    * Incorporate errata

Add 'and updates' -- it's my impression that several other RFCs
update HTTP or attempt to clarify it, and these updates should
be incorporated. (WebDAV?)

>    * Improve editorial quality

>    * Clarify conformance requirements and targets

I don't know what 'and targets' means. How about just
'Clarify conformance requirements'?

>    * Eliminate ambiguities where they affect interoperability

How about just 'Remove ambiguities'? (As per previous
comments). And it is hubris to believe you can
eliminate them. 

>    * Document the extensibility model of HTTP

How about  'Clarify methods and requirements for extensibility'? 
I think there's a model there, it's just unclear. The
new document should reference the HTTP header registry,
for example.
 
>    * Add implementation advice (e.g., deprecating problematic  
> optional features, if necessary)

I think this is two separate bullets:

     * Remove or deprecate features that are not widely
       implemented interoperability and are not well specified.

and

     * Where necessary, add implementation advice

(Lots of implementation advice doesn't below in the spec.)

>    * Update to reflect current IETF practice

I'm not sure what this means, exactly, or why it is a goal
rather than a means. I suggest removing it from the charter.

>    * Identify mandatory-to-implement security mechanisms

I think, alas, it is necessary to update RFC2617, since the
two documents go together. And I think the goal should be
to address security in the context of HTTP's most common
application, namely 'web browsing'.  I'm not quite sure
how to rewrite this bullet. Best I can do for now is:

     * Identify security mechanisms appropriate
       (and mandatory to implement) for common applications
       of HTTP, including web browsing.

> 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.  It should  
> not introduce new features or capabilities to HTTP, except where  
> doing so is necessary to improve interoperability.

I think 'improve' is too low a bar. And 'necessary to
achieve interoperability' seems a bit far-fetched, since
there's lots of interoperable HTTP today. I think taking out
the entire 'except where' clause is a good idea.

If you really want to allow new features or capabilities,
then take the whole feature out of base HTTP, and
put it in a separate Proposed Standard document
(using the now clarified extensibility mechanism).

> The Working Group's sole specification deliverable is a 
> document that is suitable to supersede RFC2616.

  'The Working Group's deliverables are a set of documents
  suitable to supersede RFCs 2616 and 2617.'

I understand the desire to avoid mission creep, but there might
be additional documents (e.g., Informational documents for
lengthier implementation advice, or Experimental or Proposed
Standard documents for solutions to currently poorly
specified features). But there's always the possibility of
revising the charter to include those, as necessary.
 
> Additionally, the working group may produce one or more test suites  
> for HTTP conformance, if there is sufficient interest.

I don't think this belongs in the charter as a deliverable
of 'the working group', and 'if there is sufficient interest'
means that it isn't really an IETF activity. 

If you want to say anything about test suites, how about:

 'The working group should review (and may document) 
 test suites for HTTP conformance, as they are made
 available.'

There is an extensive published literature on HTTP
implementation, conformance, operational behavior 
and performance. I'm not sure it belongs in the charter,
but I would think that an annotated bibliography
of _relevant_ documents would be a good thing to have.

> Goals and Milestones:
> Sep 2007 - First HTTP Revision Internet Draft
> Dec 2007 - IETF 70 Meeting, TBD
> Mar 2008 - IETF 71 Meeting, TBD
> Apr 2008 - Request Last Call for HTTP Revision
> Jul 2008 - IETF 72 Meeting, TBD
> Aug 2008 - Submit HTTP Revision to IESG for consideration as a  
> Proposed Standard

Internet Standard.  (Note that a single Internet Standard
may consist of several documents.)


Larry
-- 
http://larry.masinter.net

Received on Tuesday, 6 March 2007 14:36:43 UTC