RE: MUST use Content-Base

>  From: Yaron Goland <yarong@microsoft.com>
>  Date: Thu, 8 Jan 1998 11:45:59 -0800 
>  To: "'jg@pa.dec.com'" <jg@pa.dec.com>
>  Cc: Henrik Frystyk Nielsen <frystyk@w3.org>,
>          Foteos Macrides
>  	 <MACRIDES@SCI.WFBR.EDU>, koen@win.tue.nl,
>          http-wg%cuckoo.hpl.hp.com@hplb.hpl.hp.com
>  Subject: RE: MUST use Content-Base
>  
>  To be clear, I fully understand that RFC 2068 was a proposed, not draft,
>  standard. As such it is subject to changes and bug fixes. The point I am
>  trying to make is that we should go to great pains to ensure that nothing we
>  do in going from proposed to draft will render proposed based
>  implementations unusable.

Sure.  That is the point of IETF standards track processes...

>  
>  If we raise content-base to a MUST then we make my client unusable. A
>  server, seeing my client's claim to be HTTP/1.1, will think it can rely upon
>  sending a content-base and having it read and processed. That will not be
>  the case with my client. My client will ignore the header and the result
>  will be something other than what the server expected. Thus changing
>  content-base from may to MUST results in my client doing the "wrong" thing
>  vis a vie the standard. Hence my client has been defined, by fiat, as
>  broken.
>  

If what you do is ignore the header, then you are no worse off than any 
HTTP/1.0 client.  I don't see this as a very serious problem, as a result.
If you implemented it, and did something different, then we'd have a bigger
problem.

But we aren't declaring anyone's implementation broken here; we're declaring 
the specification broken here.  The spec wasn't clear that the intent was 
that everyone implement Content Base.  So I disagree with the assertion 
that you are "broken".  The fault isn't in the code, it it's the specification 
that's busted.  Not the first time, and (unfortunately) probably not
the last time.

>  To repeat, if we are to convince companies to implement proposed standards
>  then we must go as far as possible to ensure that moving to draft doesn't
>  render their implementation broken. Sometime, I understand, this is totally
>  unavoidable. That is the risk of implementing a proposed standard. But this
>  case is not one of those instances.
> 

I'd like to understand the consequences of different possible courses of action.
 
>  			Yaron
>  
>  PS Is it appropriate to get into a conversation about why content-base is
>  just a bad idea, from a design point of view? There was a reason why we
>  didn't implement it.
>  

Yes, though it sure would have been better to raise it as an issue last year.
We wouldn't be having this mail exchange if it had been.

If the right solution is to remove it from the spec, (and have an independent
document for a replacement for Content-Base), that is another possible course
of action, for example.  Let's explore the possible solutions...

>  > -----Original Message-----
>  > From:	jg@pa.dec.com [SMTP:jg@pa.dec.com]
>  > Sent:	Thursday, January 08, 1998 7:39 AM
>  > To:	Yaron Goland
>  > Cc:	Henrik Frystyk Nielsen; Foteos Macrides; koen@win.tue.nl;
>  > http-wg%cuckoo.hpl.hp.com@hplb.hpl.hp.com
>  > Subject:	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
--
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 13:04:26 UTC