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

-----Original Message-----
From:	David W. Morris []
Sent:	Thursday, July 17, 1997 2:20 AM
To:	Dave Kristol
Cc:; Foteos Macrides
Subject:	Re: LAST CALL, "HTTP State Management Mechanism (Rev1) " to 

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, 
> additional comments by me on comments by Foteos Macrides]
> >> > An earlier comment was made about quotes in the "Port" 
> >> > 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 
> Foteos's argument that it's easy to handle.  I'll allow that in the 
> 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 
> *specified* that way.  Apart from making the syntax (marginally) 
> 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 
with whatever you choose because I think the port=xxxx case would not 
used since it is exactly the same case as 'port' with no value.

> Concerning remarks about requiring FQHN:  I'll have to think this 
> more carefully when I get back from vacation.

Sounds fair to me ... you've been working hard enough from vacation.

> Concerning Foteos's suggestion about reserving the attribute name
> "CommentURL", sure.  Concerning CommentURL itself, I'll think about 
> some more.  The risk in adding it is that supporting it has 
> for browsers and browser vendors, and they haven't seemed too keen 
> RFC 2109 (and successors) as it is.

But I don't recall a vendor objection to the suggestion. If I were 
vendor, I'd like this one because it would be a real value add to 
it well and I believe it's a real win for users.

All of the web site and software developers I have spoken to on this 
would love the opportunity to provide a link to explain what and why 
they are doing what they are doing to help address the spread of 
misinformation (particularly by the media)  This would be a big win 
for everyone...

> Concerning Foteos's suggestion that all the attribute names be 
> from use as cookie NAMEs, it's unnecessary.  The cookie NAME=VALUE 
> comes first in the Set-Cookie2 header, so you can always distinguish 
> from any attributes.

Yeah, I scratched my head on that one for a long time before I 
I could see no reason for breakage if the attribute names weren't

Dave Morris

Received on Thursday, 17 July 1997 10:39:21 UTC