- From: Larry Masinter <masinter@parc.xerox.com>
- Date: Thu, 20 Nov 1997 22:26:56 PST
- To: Yaron Goland <yarong@microsoft.com>
- Cc: http-wg%cuckoo.hpl.hp.com@hplb.hpl.hp.com
I don't want to deep end on process, but ... > ... Any changes we are making should only > be to fix known problems yes > and should only be done in a way such that RFC 2068 > compliant programs will remain compliant with the draft version of the > standard. This is desirable but not a requirement. If RFC 2068 is broken, then we can fix it. (I don't think that applies to either Accept-TE or extra error codes.) > This means that all new optional features, such as Accept-TE, do not get > included in the draft standard. It's preferable to undock anything that can be, especially if it isn't necessary to fix a design error. > This means that any features that are not backwards compatible, such as > changing basic auth syntax or putting in more than 3 digit error codes, with > RFC 2068 do not get included in the draft standard. Backward compatibility isn't a requirement officially, although 'consensus' is unlikely without it. I think what's best is to deal with the issues on their merits. > This means that any features that have not been independently implemented by > at least two vendors do not get included in the draft standard. To be precise, 'implementors' don't have to be 'vendors'. > Moving from Proposed to Draft is not a chance to put in new features that we > now realize are useful based on our experience with RFC 2068. That's right. We've mainly 'undocked' these extra features. > This is only > a chance to fix known problems, yes > in a backwards compatible way. when possible. > If you want > to add a new optional feature, write up an RFC and put it on standards > track. I agree 100%. This is preferable. > If you want to put in a new mandatory feature or change expected > protocol behavior then rev the protocol number. If necessary; revving the protocol number is really only necessary if it improves compatibility. > But if a proposed change > fails any of the previous three tests then it has no business being put into > the draft standard. The header/trailer issue is something where 2068 proposed something but it was unclear. Accept-TE seemed like a way to deal with the trailer issue as well as hit a few other needs. I'm wary of putting it in the main spec, especially since it's optional, but moving it forward independently seems like a good idea. Similarly, the error-code draft was not being proposed as a part of the HTTP/1.1 spec, but as an independent draft. We're trying to tie up the loose ends, and this is one of them. Please state your opinion on the issues! It's easy to deep-end on this process stuff. Do you like "Accept-TE" or not? If you don't like it, why not? We may still need to put it in a separate draft, but: Yaron, I couldn't tell, from your message, whether you approved or disapproved of the Accept-TE concept. Larry
Received on Thursday, 20 November 1997 22:29:57 UTC