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

"David W. Morris" <dwm@aimnet.com> wrote:
>On Sun, 13 Jul 1997, Dave Kristol wrote:
>
>> David W. Morris wrote:
>> > 
>> > I have a number of remaining concerns with the HTTP State Management
>> > Mechanism draft-02. They range from editorial and clarity to
>> > functional. I'll sumarize the functional concerns and then step
>> > thru the draft with detailed comments and/or suggestions.
>> 
>> [I'm still on vacation, so I'll do my best to respond.  Please attribute
>> stupid remarks from me to my brain's not being fully engaged. :-) ]
>> 
>> > 
>> > Functional Concerns:
>> > 
>> >   1.  The cookie/cookie2 interoperational requirement that clients
>> >       clients merge the values from two cookie/cookie2 and servers
>> >       split the values present unnecessary implementation complexity
>> >       and opportunity for errors to conver a transition interval
>> >       and to save small amount of network traffic. More below.
>> 
>> I think we've been through this discussion before, and we've rejected
>> the alternatives
>
>Well, there merge rules must be new since 2109 since the requirement stems
>from the change to cookie2.  When I reviewed the earlier draft and
>objected to the rules, I recall two responses, one which supported my
>position and one which indirectly blamed the requirement on a large
>network service which felt the overhead would be too great. The parent
>company has since made it quite clear that they have no intent of
>supporting cookie2 proposal so their objection would seem moot.  In any
>case I have a real hard time accepting the overhead argument since the
>duplicate is only required on the first encounter with a client and
>perhaps not even then if the server site cares enough about overhead
>to check the UserAgent string as has become tradition and in fact is 
>well supported by Microsoft's ASP support for sites which use IIS or PWS.

	For what it's worth, here's some "implementation experience" on
that.  The draft has a parenthetical statement:

	"(Obviously the Set-Cookie and Set-Cookie2 headers must
	  both contain the same number of cookies.)"

It might be interpreted as a requirement that they MUST be the same
number, but not necessarily.  The draft's examples all have Set-Cookie2
and Set-Cookie cookies in the same order, but there is no clear MUST
about that either.  The Lynx implementation does not depend on either
(not because of anything in or not in the draft, but because I personally
wouldn't assume they'll always be the same number and in the same order,
even if they MUST be).


>> >   4.  There was a significant amount of interest/support for the
>> >       CommentURL as a better mechanism for communication between
>> >       the server and the user.
>> 
>> My take on the discussion was that the opinions were mixed.  Granted
>> there is merit in the proposal, there are also concerns.  You would have
>> to establish rules about cookies in CommentURL, etc.
>> 
>> I would like to table CommentURL to a followup to (the followup to) RFC
>> 2109.  (I made no further comments about your CommentURL remarks here.)

	The Lynx implementation includes handling of a commentURL
attribute.  It addresses the criticism, otherwise not addressed, that
the comment attribute, by itself, does not accommodate i18n concerns.
If the comment also can be sought via a URL, charset and language
negotiation can be brought into play.  The Canadian freenets probably
are still the largest Lynx user base (well into the six digits) and
whether the comment is in English or French is an important factor
there.  It's also an important matter for our CJK user base.  Could
the RFC at least designate commentURL as a reserved name (not to be used
as a cookie name)?  It also might be helpful to state explicitly in the
comments/explanations that use of expires as a Version 1 cookie name,
or max-age, version, port, and discard as Version 0 cookie names, is
ill-advised (I know, "That goes without saying!", and those to whom it
should be said probably won't ever read the RFC. :)  While tabled, I
guess sites which want to use it can do a User-Agent check for Lynx
(and any other browsers which implement it).


				Fote

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

Received on Tuesday, 15 July 1997 17:19:32 UTC