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

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.

> Concerning remarks about requiring FQHN:  I'll have to think this through
> 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 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.

> 
> 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.

Dave Morris