- From: Lisa Dusseault <lisa@osafoundation.org>
- Date: Tue, 16 Oct 2007 15:14:11 -0700
- To: James M Snell <jasnell@gmail.com>
- Cc: iesg@ietf.org, ietf-http-wg@w3.org
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 Tuesday, 16 October 2007 22:14:35 UTC