Re: Digest Auth (fwd)

> > This group is a bit two faced. A couple weeks a go, a prominant
> > member was chastising folks who might be publishing a server and
> > calling it HTTP/1.1 before the very stable draft is really approved
> > by the IETF. Now we are complaining because one or more other
> > software publishers chose not to deliver software matching a spec
> > about which discussion had gotten very hot and might be expected
> > to be an unstable implementation target.
> >
> > C'mon folks we can't have it both ways!
> 
> You are missing the point.  Digest can and should have been
> implemented in HTTP/1.0 as the experiment that it was -- whether
> or not it is stable only affects the allocation of limited resources. 

I disagree, because of the nature of "experimental" features.  The
particular case we're talking about (I believe) is the case where
Digest was implemented, and pulled because the spec showed signs 
of destabilization.  With the final release of the servers in 
question rapidly approaching, we decided it would be better to play
it safe and remove support until the spec was stable than to keep
the support in and saddle everyone with an experimental 
implementation for a long time.  If a spec shows signs of
instability, and a product is scheduled to ship a final release,
it is not prudent to release an experimental feature in a release
product.  Haven't specs gotten bit by experimental features with
large user bases before?  Currently I'm thinking of the Host:
header, which I believe was appending the port number in Navigator,
and some discussion came up to remove the port number.  Even if
the spec did change, now experimental behavior has to be expected
and dealt with because users will be sending it.  We decided to be
prudent and wait for the spec to calm down rather than etch 
experimental behavior into a final release.  (Note that I can only
speak for the server side.)

> In contrast, we are using the label "HTTP/1.1" to indicate minimum
> compliance to a specific proposed standard, and you cannot indicate
> minimum compliance to something which is still subject to change.
> Any future change to HTTP's minimum compliance will now require a
> change to the HTTP version, since that is how the version stuff is
> supposed to work. 

The point I would like to make is that non-finalized specs are 
risky for a final release of a product.  The situation does bear
some similarity in that this is a case where a released product would
be advertising that it does features involved in a non-finalized
spec, and if the spec changes, the product becomes non-compliant.
Similarly, if we had released an implementation of digest auth
at the time when we had it done, and the spec had changed, then
we would become non-compliant with the later drafts, and that
behavior would have to be dealt with for interoperability.  We
chose not to risk being the black sheep.  As to why we haven't
revisited that decision after it happened, then it's more of a
resource issue, which will undoubtedly be looked at again for
the next release.

> My concern is that the WG as a whole needs to understand the
> meaning of HTTP-version, and when the version number should change,
> since that understanding is central to the protocol's extensibility.

My concern is simply that I think if Digest goes to a must, then
it should be done for the right reasons.  People have brought up
valid reasons why it should be a must.  I don't think it's right
to make it a must in order to force people who would not otherwise
implement digest auth to implement it.  Using that argument weakens
an otherwise strong argument by making it look political.
	--MLM
-- 
      ---- mlm@netscape.com * http://www.netscape.com/people/mlm/ ----

Received on Thursday, 29 August 1996 15:45:27 UTC