Re: Straw-man charter

Larry Masinter schrieb:
> 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?)

I would say WebDAV *extends* - using new headers and methods - but 
doesn't update, so I'm not sure it needs to be considered (and that 
coming from me :-).

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

Agreed. So: "Eliminate *known* ambiguities"?

> 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.

Right. And the status code registry.

> 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.

I though that refers, for instance, to the ABNF notation issue.

> 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.

I do agree that RFC2617 needs to be updated as well, but I'm not sure it 
  absolutely needs to happen at the same time, and whether the group 
working on that should be the same.

>> 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).

Wouldn't a new feature have to start as "proposed" on the standards 
track anyway?

Best regards, Julian

Received on Tuesday, 6 March 2007 15:09:38 UTC