RE: MUST use Content-Base

>  From: Yaron Goland <yarong@microsoft.com>
>  Date: Wed, 7 Jan 1998 22:00:42 -0800 
>  To: "'Henrik Frystyk Nielsen'" <frystyk@w3.org>,
>          Foteos Macrides
>  	 <MACRIDES@SCI.WFBR.EDU>, koen@win.tue.nl
>  Cc: http-wg%cuckoo.hpl.hp.com@hplb.hpl.hp.com
>  Subject: RE: MUST use Content-Base
>  
>  Nothing like defining current implementations as broken to really get
>  companies excited about the open standards process.
>  
>  	"Be standards compliant" I said. "It's an RFC" I said. Sigh...
>  
>  		Yaron
>  

Yaron,

You conformed as well as you knew how to RFC 2068.  No one said that you 
didn't.  You can with a straight face continue to claim compliance with 
2068 (and I, for one, will defend your claims for Content-Base).  Please 
also read the IETF definition of what a proposed standard is.  We are not
declaring anyone broken (except the specification, that is, which is
broken).

Unfortunately, 2068 has an ambiguity.  You are far from alone in believing 
it to be capable of multiple interpretations by well minded people with 
the best of intentions. (I certainly believe it capable of multiple 
interpretations).  Other people have the other interpretation...  Are they 
supposed to not be "standards complient"? Or are you saying that the
Microsoft implemetation is the only implementation that matters?  I
think that Netscape might have some other opinion here, for example.

In the future you'll be complient to RFC 2XXX (the sucessor to 2068) (which 
one way or the other won't have the ambiguity).  And the process ensures 
that compliance to RFC 2XXX, as a draft standard, should mean you remain 
compliant with 2068.

This is why there is interoperability testing; to find and fix problems 
in the specification, and end up with multiple INTEROPERABLE implementations 
that can be implemented from the specification successfully.  Given the 
multiple possible interpretations, and multiple implementations, it isn't 
always possible to fix a problem without someone having to change an 
implementation.

What we're trying to figure out here is what the right solution is to remove 
the abiguity, with minimum short term AND long term impact. My previous 
mail stated a PERSONAL opinion of what should happen; it is not a "done 
deal" (none has been made as yet, though I'll take one eventually if there 
is no "rough consensus", so that we make progress in a timely fashion). 
This is why I often keep quiet until relatively late in discussions on a 
topic in HTTP; I take the responsibility of trying to reflect the working 
group "rough consensus" very seriously.  I do not act against the working 
group opinions.

This having been said, we (the working group) need to figure out what the 
right solution is.  So:

1) data on what current implementations do is very useful.
2) understanding what options we have is useful
3) understanding what the consequences of following each options is useful.

Hand wringing, and worrying about whether one is "compliant" is not useful.  
Note that understanding the consequences of a change are covered in 3.

I'd like to hear from others who can help on these points, particularly
those who've implemented it.

					- Jim


--
Jim Gettys
Industry Standards and Consortia
Digital Equipment Corporation
Visting Scientist, World Wide Web Consortium, M.I.T.
http://www.w3.org/People/Gettys/
jg@w3.org, jg@pa.dec.com

Received on Thursday, 8 January 1998 07:43:28 UTC