Re: COMMENT: LAST CALL comment

http-wg@cuckoo.hpl.hp.com writes:

>Larry Masinter:
>>
>>> COMMENT: LAST CALL
>>   The clarification in the mail archive will be accepted.
>
>This does not give me enough information about the proposal.
>
>Is the last call about allowing \) in comments, or also about allowing
>\" in quoted-strings (which is really the QUOTED-BACK issue)?

I'm confused too.  The description URL in the issues table is the same
for both COMMENT and QUOTED-BACK, yet the statuses are different - last
call for the former, open for the latter.

>If it is about the second thing too, I object to the proposed
>resolution. See for example
>http://www.ics.uci.edu/pub/ietf/http/hypermail/1996q4/0396.html .

I share Koen Holtman's concern about HTTP 1.0 not allowing
backslash-enquoted characters, but RFC 2068 is quite clear in its intent.
According to section 2.2 "Basic Rules", pp. 17:

  "A string of text is parsed as a single word if it is quoted using
   double-quote marks.

          quoted-string  = ( <"> *(qdtext) <"> )

          qdtext         = <any TEXT except <">>

   The backslash character ("\") may be used as a single-character quoting

   mechanism only within quoted-string and comment constructs.

          quoted-pair    = "\" CHAR"

There's clearly a contradiction between the BNF and the text, and as I
can find no references in the RFC to "quoted-pair", I'm inclined to
agree with Roy Fielding that the BNF is in error.  The change in stance
between HTTP 1.0 and 1.1 on backslash-enquoting is quite clear in the
text, and the BNF for "quoted-pair" is new in HTTP 1.1.  Thank goodness
comments are only legal within Server, User-Agent, and Via fields!

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
mis-comparing tags that would be equal after dequoting (e.g., "a \b c"
vs.  "a b c").

Interestingly, allowing quoted-pairs withing quoted-strings would bring
HTTP's definition of media-type parameters back in line with MIME's.
MIME relies on the RFC 822 definintion of quoted-string, which allows
quoted-pairs, and "value" is defined in both HTTP and MIME as "token |
quoted-string".

Ross Patterson
Sterling Software, Inc.
VM Software Division

Received on Wednesday, 4 June 1997 08:40:44 UTC