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