RE: MUST use Content-Base
Jim Gettys (jg@pa.dec.com)
Thu, 8 Jan 1998 07:39:25 -0800
> 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