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

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.


On Oct 14, 2007, at 12:39 PM, James M Snell wrote:

> IESG Secretary wrote:
>>> [snip]
>>> The Working Group must not introduce a new version of HTTP, and
>>> should not introduce new features or capabilities to HTTP.
> I would prefer that the latter also be a MUST NOT.
> - James

Received on Tuesday, 16 October 2007 22:14:35 UTC