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

Dave Kristol (dmk@research.bell-labs.com)
Mon, 17 Nov 97 16:10:24 EST 

"Roy T. Fielding" <fielding@kiwi.ics.uci.edu> wrote on Fri, 14 Nov 1997 15:33:58 -0800:
  > >  > 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.

Okay.

  > 
  > >  > 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)?

I suspect no one sends IPv6 addresses in cookies now, and probably no
user agents would know what to do with them.  But I thought the spec.
should allow them.

Last I looked (some time ago), the proposed text representation of IPv6
addresses involved ':' separators, and I think they will pose problems
for the URL syntax.  But that syntax shouldn't pose a problem in the
context of the cookie spec.

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

I think you and I will have to disagree here.  I'm trying to define
a term, "domain match", and it can't be done without describing the
algorithm.  And I do give a sense of context:  "[s]ometimes we
compare one host name with another."
  > 
  > > [...]
  > >
  > >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.

I've looked over section 4.2.1 particularly, but I'm not sure how you
would want me to recast it.  I don't believe I'm defining the
application, although I'm certainly describing the things an
application can/should/must do.  I prefer the application-centric
approach; too often I see specs. that describe all the things a
protocol can do, but I haven't a clue which ones I need to use.

Dave Kristol