Re: COMMENT: LAST CALL comment

David W. Morris" <dwm@xpasc.com> writes:

>On Wed, 4 Jun 1997, Ross Patterson wrote:
>
>> Accepting Roy's assertion does, however, open one other area of concern:
>> use of the "quoted-string" BNF by other parts of the grammar.  For
>> example, entity tags are defined as "opaque-tag", and opaque-tag is
>> defined as "quoted-string".  Therefore quoted-pairs must be legal within
>> opaque-tags.  So what is the proper meaning of "opaque" - do we dequote
>> quoted-pairs within opaque-tags before comparison or not?  The former
>> changes them more into "translucent-tag"s, the latter risks
>
>THere is the syntatic quoted string and there is the value represented
>by the quoted string. I assert that the value and not the transfer
>mechanism is opaque. Before comparison of a quoted string, it must
>be transformed into its value. That is, remove the transfer encoding.

I agree, but it isn't clear that RFC 2068 does.  The only places where it
tries even slightly to define opacity are in sections 11.1 "Basic
Authentication Scheme" (pp. 66) where it says:

   "... The realm value should be considered an opaque string which
   can only be compared for equality with other realms on that server."

and 13.3.3 "Weak and Strong Validators" (pp. 84) where it says:

   "The only function that the HTTP/1.1 protocol defines on validators is
   comparison. There are two validator comparison functions, depending
   on whether the comparison context allows the use of weak validators
   or not:

   o  The strong comparison function: in order to be considered equal,
      both validators must be identical in every way, and neither may be
      weak.
   o  The weak comparison function: in order to be considered equal, both
      validators must be identical in every way, but either or both of
      them may be tagged as "weak" without affecting the result."

There's no discussion of encodings at all, and there seems to be an
implied stricture against examining or altering the opaque value.

>In the world of computer science, the principal of no suprises would
>dictate that the correct 'design' is quoted-pairs are supported.

That's an interesting definition of "no surprises", unless you mean that
a quoted-string is always treated identically, regardless of context.
I'd count processing of characters within a supposedly opaque value as
quite surprising.

>This may be a case where the minimal risk of HTTP/1.0 breakage should bow
>to the greater common good. My intuition is that there is at least as
>good a chance that the implementors of HTTP/1.0 servers and clients
>have really implemented full support for quoted pairs as restricted
>support. Full support is easier and follows other examples such as
>the C programming language.

Much of the world is neither C nor Unix, and it certainly is arguable
whether many HTTP implementers had existing RFC822-compliant lexical
analyzers to steal the quoted-string support from.  Given that HTTP 1.0
had an extremely simple quoted-string, I'll bet that any HTTP
implementations that incorrectly accept quoted-pairs can be traced to
a single code source.

In any case, opaque-tag was just a handy example.  It is one of 13
elements of the HTTP 1.1 grammar that are derived from quoted-string, and
any change to the BNF for quoted-string should be examined for unexpected
changes in them, and in elements that are derived from them.

Thanks for treating my comments seriously, this group has been a little
hot lately and I expected flames instead of discussion.

Ross Patterson
Sterling Software, Inc.
VM Software Division

Received on Wednesday, 4 June 1997 13:29:28 UTC