W3C home > Mailing lists > Public > ietf-http-wg-old@w3.org > January to April 1998

RE: MUST use Content-Base

From: Yaron Goland <yarong@microsoft.com>
Date: Sat, 10 Jan 1998 17:35:00 -0800
Message-Id: <3FF8121C9B6DD111812100805F31FC0D0E7269@red-msg-59.dns.microsoft.com>
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
It would make us broken because of the following scenario:

A server recieves a GET from a client, the request is marked HTTP/1.1. The
server now knows it is dealing with a 1.1 client. So, no problem, according
to the HTTP/1.1 Draft Standard a 1.1 client MUST honor the content-base
header. So the server sends down a content-base expecting that the body will
be interpreted using the content-base header to resolve relative URIs. Of
course now the wrong thing will happen, the IE client will NOT honor the
content-base header because it is based on the proposed standard where
content-base is a MAY and the whole situation falls apart.

So therefore changing the MAY to MUST breaks HTTP/1.1 proposed standard
compliant implementations which choose to honor the may, as is their right,
by ignoring the header.

			Yaron

> -----Original Message-----
> From:	jg@pa.dec.com [SMTP:jg@pa.dec.com]
> Sent:	Thursday, January 08, 1998 12:56 PM
> To:	Yaron Goland
> Cc:	jg@pa.dec.com; 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: 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 Sunday, 11 January 1998 18:10:14 EST

This archive was generated by hypermail pre-2.1.9 : Wednesday, 24 September 2003 06:33:10 EDT