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

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.
> 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
> 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 Wednesday, 17 October 2007 15:15:59 UTC