- From: James M Snell <jasnell@gmail.com>
- Date: Wed, 17 Oct 2007 08:15:31 -0700
- 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