Re: comments on draft-ietf-http-state-man-mec-04.txt

>  > I'd prefer not to have " (Rev1)" in the title.
>
>I thought it was desirable to distinguish this from RFC 2109.

That should be done in the abstract (and it is, as I recall).
I think the draft should contain exactly what the final RFC will
contain, aside from the Status section and Header/Footer.

>  > A comment should be included regarding support (or non-support) of IPv6
>  > addresses [we got pinged on this for the URI draft].
>
>Can you suggest wording?  I wanted to avoid specifying syntax for either,
>and I chose the neutral term "numeric IP addresses" to (try to) imply both.
>(I also seem to remember that the proposed text representation of IPv6
>addresses conflicts with URI syntax....)

I don't know what to suggest.  What happens when a cookie includes an IPv6
address (or is that even possible)?

>  > In general, I find the terminology section more confusing than useful,
>  > even though I do know what is intended.  I find it unlikely that anyone
>  > not involved in the mailing list discussions would have a clue as to
>  > what is being described.  It would be better to postpone the description
>  > of hostname dot comparison until it can be described as part of the
>  > matching algorithm.
>
>YMMV.  I prefer to put the terms in one place so someone can find them
>easily if they need to.  It's a bit like the HTTP specification -- you
>can't really understand this section until you understand the whole thing.

Terms, yes -- algorithms, no.  The hostname dot comparison doesn't make
any sense without the context for why the hostname dot comparison exists.

>When I first wrote this section, about 20 months ago, I was trying to
>anticipate concerns that implementers might have about how much of a
>burden cookies would be to running a server.  I was trying to make a
>point that the support was relatively localized.  In "the old days",
>cookies got handled by CGIs, and only those CGIs that needed cookies
>needed to support them.  Newer servers may provide built-in support
>("more sophisticated...") for cookies, but that support isn't essential
>to their support.
>
>Your description is correct from the HTTP point of view, of course.

I should have also mentioned that I was reading it from that view.
I like implementation advice, but it needs to be clear what the
protocol requirements are as opposed to how one might use them.
A proposed standard needs to define the interface and avoid defining
the application.

>  > Unless you wish to define the precedence of "|" in your BNF, each
>  > of the set-cookie-av need to be grouped in parentheses.
>
>Obviously the typography dictates the precedence. :-)  Seriously, do
>you think there's anything confusing in the current format?  I fear that
>adding ()'s will make it harder to understand, not easier.  Also,
>traditionally, alternation is lowest precedence after '=', no?

It is in the EBNF defined by the drums WG.  I tried to avoid such implied
things in the HTTP specs, though I note that a few are in RFC 2068.
So, I suppose you are correct.  I'm just one of those programmers who
likes to put parentheses around conditions, I guess.

>  > >The origin server should send the following additional HTTP/1.1 response
>  > >headers, depending on circumstances:
>  > >
>  > >   * To suppress caching of the Set-Cookie2 header: Cache-control: no-
>  > >     cache="set-cookie2".
>  > 
>  > This type of example should not be allowed to break across a line.
>  > There are many other areas where the text translation needs to be
>  > fixed for a final draft.
>
>I agree.  It's strange -- I've got hyphenation disabled in the (nroff/troff)
>source.  I guess that only controls intra-word hyphenation.  (I wonder if I
>can even persuade nroff/troff not to break around '-'.)

Nope, from very painful man-page-writing experience.  I suggest line breaks.

....Roy

Received on Friday, 14 November 1997 15:50:03 UTC