W3C home > Mailing lists > Public > ietf-http-wg@w3.org > October to December 2007

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

From: James M Snell <jasnell@gmail.com>
Date: Wed, 17 Oct 2007 08:15:31 -0700
Message-ID: <47162713.1010007@gmail.com>
To: Lisa Dusseault <lisa@osafoundation.org>
CC: iesg@ietf.org, ietf-http-wg@w3.org

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

This archive was generated by hypermail 2.3.1 : Tuesday, 1 March 2016 11:10:43 UTC