Re: Changes to the spec

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