Re: LAST CALL, "HTTP State Management Mechanism (Rev1) " to Propo

"David W. Morris" <dwm@xpasc.com> wrote:
>On Wed, 16 Jul 1997, Dave Kristol wrote:
>
>> At 11:27 PM -0700 7/14/97, David W. Morris wrote:
>> [hisresponses to my responses to his comments to the above I-D, with
>> additional comments by me on comments by Foteos Macrides]
>> 
>> 
>> >> > An earlier comment was made about quotes in the "Port" attribute,
>> >> > but I think there are additional problems with the syntax as
>> >> > specified and suggest that:
>> >> >
>> >> > ::                 |       "Port" [ "=" <"> 1#port-list <"> ]
>> >> > :: port-list       |       1#DIGIT
>> >> >
>> >> > be replaced with:
>> >> >
>> >> >                    |       "Port" [ "=" portnum | <"> 1#portnum <"> ]
>> >> >    portnum         =       1*DIGIT
>> >> >
>> >> > If I correctly understand RFC2068 syntax, 1#X means 1 or more
>> >> > occurances of X delimited by commas. My changes fix the "="
>> >> > in port-list, the 1#DIGIT in port list and make the quotes
>> >> > optional for the single port case.
>> 
>> You're absolutely right about my having botched the syntax.  I'll have to
>> fix this up.  Thanks!
>> 
>> Concerning making the quotes optional for a single port number:  I accept
>> Foteos's argument that it's easy to handle.  I'll allow that in the spirit
>> of "be liberal in what you accept", an implementation may want to handle it
>> that way, but I still think it's a really bad idea for the syntax to be
>> *specified* that way.  Apart from making the syntax (marginally) more
>> complex, the (proposed) syntax above invites errors of omission, where a
>> server goes from sending a single port number to sending more than one and
>> the implementor has to remember to add quotes to get it right.
>
>I actually believed you had intended the quotes to be optional ... my
>main concern was getting the syntax right so on the quotes I'm satisfied
>with whatever you choose because I think the port=xxxx case would not be
>used since it is exactly the same case as 'port' with no value.

	My statements about that concerned the comments/explanation section
of the draft, which I think could be improved in the interest of promoting
successful implementation of the specs.  I had interpreted the specs,
themselves, to be making quoting of the port value mandatory in all cases
where a value is present.  My suggestion was to state that explicitly, with
words, in the comments/explanations sections.  Dave Morris' statements, above,
in effect are confirmation that an explicit statement about this in the
comments/explanation section would help avoid confusion about what the
specs, themselves, actually intend.

	I was not suggesting that the quoting be made optional.  I was
cautioning that implementors include "sanity checks" to cope with the
possibility that the value is not quoted, despite that requirement.
The absence of quoting is highly likely, IMHO, as a carryover from the
"historical" implementations.

	The principle that a browser should be liberal in what it accepts
is unavoidable on today's Web.  But that principle should not apply to IETF
specs, themselves.  The comments/explanations sections should include
"Note that some UAs incorrectly ..." caveats to assist implementors in
coping with today's Web, but the specs themselves should not waffle on
what is correct versus incorrect.


>> Concerning Foteos's suggestion about reserving the attribute name
>> "CommentURL", sure.  Concerning CommentURL itself, I'll think about that
>> some more.  The risk in adding it is that supporting it has implications
>> for browsers and browser vendors, and they haven't seemed too keen about
>> RFC 2109 (and successors) as it is.
>
>But I don't recall a vendor objection to the suggestion. If I were the
>vendor, I'd like this one because it would be a real value add to handle
>it well and I believe it's a real win for users.

	I similarly did not perceive vendor objections to the suggestion,
just a word of caution about not getting caught in a loop of cookie
exchanges when retrieving the comments.  That's simple to deal with in
any decent implementation.  The discussion turned to one about a PEP
or PEP-like extension, which is a good idea, and hopefully will be
forthcoming, but is not an alternative to the commentURL.

	If you do not include commentURL, with the ability to bring charset
and language negotiation into play, then the criticism still stands that
the comment attribute, whose value must conform to header constraints, does
not adequately accomodate i18n concerns.  Please address that criticism.
The comment, in effect, is trying to stick a body in a header.  That
can't be done adequately, in contrast to a commentURL.


>> Concerning Foteos's suggestion that all the attribute names be reserved
>> from use as cookie NAMEs, it's unnecessary.  The cookie NAME=VALUE always
>> comes first in the Set-Cookie2 header, so you can always distinguish it
>> from any attributes.
>
>Yeah, I scratched my head on that one for a long time before I concluded 
>I could see no reason for breakage if the attribute names weren't 
>reserved.

	I was not suggesting that Versions 1 cookie attributes be
designated as reserved.  Of course that's nonsense.  I was suggesting
that the comments/explanations sections state explicitly, as an aid
to successful and reliable implementation of this spec, that use of
the new, Version 1 cookie attributes as names for "historical" cookies
in "historical" Set-Cookie headers (as opposed to "modern" Set-Cookie2
headers) is "ill-advised".  Has anyone besides the Lynx folks actually
tried to implement this based on the draft as it presently stands?  No
offense intended, honest, but it's as muddled as this discussion about
it, particularly when trying to cope with that ill-advised combinatorial
requirement.  Frankly, that will be a bigger impediment to it's successful
deployment than any media spin being generated by some vendors.  The
concerns about invasion of privacy on the Web are not going to just
go away due to media spin.  Whatever might be the present plans of some
vendors, no one can foresee what market forces, or perhaps legislative
forces, might change those plans.  I think it is very important for the
IETF to get out a *stable* State Management RFC that adequately addresses
the concerns about privacy which have been discussed at length in this WG,
and about which adequate, albeit not total, consensus has been reached.

				Fote

=========================================================================
 Foteos Macrides            Worcester Foundation for Biomedical Research
 MACRIDES@SCI.WFBR.EDU         222 Maple Avenue, Shrewsbury, MA 01545
=========================================================================

Received on Thursday, 17 July 1997 10:15:17 UTC