Re: [sipcore] draft-ietf-sipcore-location-conveyance-04

["Elwell, John" <[e-mail]>]

Yes, 4 looks good, but I could live with 1.

John

> -----Original Message-----
> From: [e-mail]
> [mailto:[e-mail]] On Behalf Of Anders Kristensen
> Sent: 28 October 2010 05:53
> To: [e-mail]
> Subject: Re: [sipcore] draft-ietf-sipcore-location-conveyance-04
>
> I haven't really followed the discussion closely but I'll say this
> anyway. Many header fields are of a form similar to Geolocation,
> essentially lists of URI, and allow for parameters. But I think the
> parameters are pretty much always associated with individual
> entries in
> the list and may be present for more than one.
>
>  From what I can tell, in the case of Geolocation, the
> routing-allowed
> param is not really attached to any particular entry in the list
> suggesting that maybe it doesn't belong in the same header field. I
> think that's the thinking that lead Paul to options 4 or 5 which seem
> much preferable to me. That allows Geolocation to fit the text in RFC
> 3261 that talks about combining header fields:
>
>     Specifically, any SIP
>     header whose grammar is of the form
>
>        header  =  "header-name" HCOLON header-value *(COMMA
> header-value)
>
>     allows for combining header fields of the same name into a comma-
>     separated list.
>
> Granted, there's no rule that says that header fields with
> comma-separated values *must* fit the above grammar but ISTM
> that it's a
> pretty established pattern which is worth observing.
>
> Thanks,
> Anders
>
> On 10/27/2010 9:10 PM, James M. Polk wrote:
> > At 06:50 PM 10/27/2010, Paul Kyzivat wrote:
> >> I have a bunch inline here.
> >
> > I'll say ;-)
> >
> >> This supersedes my earlier suggested ABNF change.
> >
> > ack
> >
> >
> >> On 10/27/2010 2:32 PM, James M. Polk wrote:
> >>> Paul
> >>>
> >>> in-line
> >>>
> >>> At 08:36 PM 10/26/2010, Paul Kyzivat wrote:
> >>>> I took a quick look at the new version, and it seems to
> have cleanup a
> >>>> lot. But there *still* seems to be a problem with the syntax.
> >>>> (Interplay between ABNF and text.) From the text, I find:
> >>>>
> >>>> The placement of the "routing-allowed" header field parameter,
> >>>> strongly encouraged by [RFC5606], is outside the
> locationValue, and
> >>>> MUST always be last in the header field value. The
> routing-allowed
> >>>> parameter MUST be present, even when no locationValue is present.
> >>>>
> >>>> This is questionably supported by the ABNF:
> >>>>
> >>>> Geolocation-header = "Geolocation" HCOLON Geolocation-value
> >>>> Geolocation-value = ( locationValue [ COMMA locationValue ] )
> >>>> / routing-param
> >>>
> >>> the above, I believe - but am open to be corrected by
> those better at
> >>> ABNF syntax that I, says
> >>>
> >>> - the Geolocation header can optionally have one or more
> locationValues
> >>> - which are where the location URIs go
> >>
> >> The above says *a* Geolocation header can have
> >> - one or two locationValues
> >> - OR one routing-param
> >>
> >> (The slash means OR)
> >>
> >> But it doesn't state that the Geolocation header itself can appear
> >> only once. And obviously if the goal is to have a
> locationValue AND a
> >> routing-param in the message, then with the above syntax
> at least TWO
> >> Geolocation headers will be required.
> >>
> >>> - but that the Geolocation header *will* have a routing-param
> >>> - which is the "routing-allowed" paramter that RFC 5606
> wanted included
> >>
> >> Since the slash means OR, it doesn't mean it *will*.
> >>
> >>> The text of the ID then says that only zero, one or two
> locationValues
> >>> are allowed, which we all agreed to in Maastricht (in SIPCORE and
> >>> ECRIT/GEOPRIV).
> >>>
> >>>> locationValue = LAQUOT locationURI RAQUOT
> >>>> *(SEMI geoloc-param)
> >>>> locationURI = sip-URI / sips-URI / pres-URI
> >>>> / http-URI / HTTPS-URI
> >>>> / cid-url ; (from RFC 2392)
> >>>> / absoluteURI ; (from RFC 3261)
> >>>> geoloc-param = generic-param; (from RFC 3261)
> >>>> routing-param = "routing-allowed" EQUAL "yes" / "no"
> >>>>
> >>>> It only works if you presume that there are separate
> occurrences of
> >>>> GeoLocation-header in the message, one with just
> locations, another
> >>>> with just the routing-param.
> >>>
> >>> I don't get that part of your point, but I guess Martin's
> next message
> >>> says I need to add a "COMMA" after the ']' but before the
> ')'. Would
> >>> this satisfy your issue?
> >>
> >> Adding the COMMA and removing the slash would require the
> >> routing-param, and would separate it from the
> location-value. But then
> >> if you only wanted the routing-param without any locationValues you
> >> would have to write:
> >>
> >> Geolocation:,routing-allowed=no
> >>
> >> which is at least a bit weird, which I think is what Martin meant.
> >>
> >>>> The routing-param certainly can't be "last in the header
> field value"
> >>>> except in the degenerate sense, since it must be first
> and only in a
> >>>> Geolocation-header.
> >>>
> >>> If the routing-param was intended to be first, wouldn't
> it appear first
> >>> on this line?
> >>
> >> My point was that the syntax as written only allows
> routing-param by
> >> itself in a geolocation-header. E.g.
> >>
> >> Geolocation:routing-allowed=no
> >>
> >> It can't share a single Geolocation header with a
> locationValue. Hence
> >> it is *both* first and last in that header.
> >>
> >>>> Geolocation-value = ( locationValue [ COMMA locationValue ] )
> >>>> / routing-param
> >>>
> >>> but it doesn't, so I'm confused.
> >>
> >> Again, the slash means OR. So you have:
> >>
> >> Geolocation-value = ( locationValue [ COMMA locationValue ] )
> >> OR
> >> Geolocation-value = routing-param
> >>
> >> (Though you can't write it that way in ABNF.
> >>
> >>>> Below are some specific cases - both valid and invalid.
> In each case I
> >>>> show some headers bracketed by "...". That is intended
> to mean other
> >>>> headers in a message, but all in the same message. (And
> when I show
> >>>> multiple headers, there could be other non-geoloc
> headers interleaved.)
> >>>>
> >>>> * The following are legal according to the above, and
> probably within
> >>>> expected usage:
> >>>>
> >>>> ...
> >>>> Geolocation: cid:[e-mail]
> >>>> Geolocation: routing-allowed=yes
> >>>> ...
> >>>>
> >>>> ...
> >>>> Geolocation: cid:[e-mail],cid:[e-mail]
> >>>> Geolocation: routing-allowed=yes
> >>>> ...
> >>>>
> >>>> ...
> >>>> Geolocation: routing-allowed=no
> >>>> ...
> >>>>
> >>>> * IIUC the following are allowed by the above both
> syntactically and
> >>>> according to the text, but is presumably not *intended*
> to be valid.
> >>>> (Its legal because the in each instance of Geolocation-header its
> >>>> last.)
> >>>>
> >>>> ...
> >>>> Geolocation: routing-allowed=no
> >>>> Geolocation: routing-allowed=yes
> >>>> ...
> >>>>
> >>>> The following is also allowed - I don't know if its
> intended or not:
> >>>>
> >>>> ...
> >>>> Geolocation: routing-allowed=yes
> >>>> Geolocation: cid:[e-mail],cid:[e-mail]
> >>>> ...
> >>>>
> >>>> * The following is allowed by the ABNF though disallowed
> by the text:
> >>>>
> >>>> ...
> >>>> Geolocation: cid:[e-mail],cid:[e-mail]
> >>>> Geolocation: cid:[e-mail]
> >>>> ...
> >>>>
> >>>> * The following is *not* allowed by the ABNF. I suspect
> it might be
> >>>> intended to be valid, but I'm far from sure about it:
> >>>>
> >>>> ...
> >>>> Geolocation: cid:[e-mail],routing-allowed=yes
> >>>> ...
> >>>
> >>> to get this above example "allowed", would I correct the
> existing ABNF
> >>> to be
> >>>
> >>>> Geolocation-value = ( locationValue [ COMMA
> locationValue ] COMMA )
> >>>> / routing-param
> >>>
> >>> ?
> >>
> >> No. *That* would allow all of the following but not the
> example above:
> >>
> >> Geolocation: cid:[e-mail],
> >> Geolocation: cid:[e-mail],cid:[e-mail],
> >> Geolocation: routing-allowed=yes
> >>
> >>>> In addition to that, the text is very explicit that:
> >>>>
> >>>> The routing-allowed
> >>>> parameter MUST be present, even when no locationValue is present.
> >>>>
> >>>> but then it says:
> >>>>
> >>>> If no routing-allowed parameter
> >>>> is present in a SIP request, a SIP intermediary MAY insert this
> >>>> value with a RECOMMENDED value of "no" by default.
> >>>>
> >>>> So its required, but we have rules to follow if its
> missing. But I
> >>>> don't understand how it *can* be required, since the
> sender of the
> >>>> request may not understand/support Geolocation and so
> won't include it.
> >>>
> >>> What we're trying to do here is explicitly give
> instructions to SIP
> >>> intermediary implementers to include the routing-allowed
> parameter if
> >>> one isn't present, with a default value of =no.
> >>
> >> I went back and reread the section containing this text. It is in a
> >> section explicitly about this header. So on reflection I
> suppose the
> >> "MUST be present" was intended to imply "in the
> Geolocation *header".
> >> I took it to mean "in the request".
> >>
> >> Requiring it to be in the header only makes sense if there
> can be at
> >> most one header. And then it only makes sense if the
> syntax is altered
> >> to allow both the routing-parameter and the locationValue
> in the same
> >> header.
> >>
> >>>> ISTM that in reality its only *required* if the is a
> locationValue
> >>>> present, and is otherwise optional.
> >>>
> >>> which is how most would read it if ...
> >>>
> >>>> If no routing-allowed parameter
> >>>> is present in a SIP request, a SIP intermediary MAY insert this
> >>>> value with a RECOMMENDED value of "no" by default.
> >>>
> >>> ... weren't present in the document. But, there is no
> permission to
> >>> allow SIP intermediaries to add the routing-allowed
> parameter, which we
> >>> wanted to cover.
> >>
> >> I'm still confused. Let me state what I think you are after:
> >>
> >> - a request may or may not contain a Geolocation header
> >> - a request may not contain more than one Geolocation header
> >
> > of what you have, this one is one I hadn't considered
> important, but if
> > that gets everything aligned, then I'm all for adding it in.
> >
> >> - a Geolocation header MUST contain a routing-param
> >> - a Geolocation header Must contain zero, one, or two
> locationValues
> >> - you prefer the routing-param to be the last field in the header
> >> - a proxy MAY add a Geolocation header if one is not present
> >> (in which case it MUST include a routing-param)
> >> - a proxy MAY add a locationValue to an existing Geolocation header
> >> if it doesn't already have two locationValues. (And I guess it
> >> could add two if there initially were none.)
> >>
> >> And you would like ABNF that is consistent with the above.
> >
> > with the one caveat, yes.
> >
> >
> >> I'm going to give you some alternatives that should all be
> >> syntactically correct. I'll give you one that meets the above, and
> >> some others that may be more appealing variations. Then we can see
> >> which people prefer.
> >>
> >> 1) The following tries to meet the requirements I spelled
> out above:
> >>
> >> Geolocation-header = "Geolocation" HCOLON Geolocation-value
> >> Geolocation-value = locationValue [ COMMA locationValue]
> >> COMMA routing-param
> >> / routing-param
> >
> > I hadn't even thought that was possible, but seeing it, I'm amazed I
> > didn't try it
> >
> > (i.e., it's another classic "I could've had a v8" moment)...
> >
> > I'm not as smart as you, Paul <:-|
> >
> >> locationValue = LAQUOT locationURI RAQUOT
> >> *(SEMI geoloc-param)
> >> locationURI = sip-URI / sips-URI / pres-URI
> >> / http-URI / HTTPS-URI
> >> / cid-url ; (from RFC 2392)
> >> / absoluteURI ; (from RFC 3261)
> >> geoloc-param = generic-param; (from RFC 3261)
> >> routing-param = "routing-allowed" EQUAL "yes" / "no"
> >>
> >> This must be accompanied by text stating that there MUST be at most
> >> one Geolocation-header in a request.
> >
> > you've sold me on this one (and yes, I examined all the
> others before
> > jumping on this first one!). Do others have strong opinions
> about why
> > not #1?
> >
> > thank you for this!
> >
> > James
> >
> >
> >> 2) The following is similar to (1), but allows more than two
> >> 'locationValue's
> >>
> >> Geolocation-header = "Geolocation" HCOLON Geolocation-value
> >> Geolocation-value = *(locationValue COMMA) routing-param
> >> locationValue = LAQUOT locationURI RAQUOT
> >> *(SEMI geoloc-param)
> >> locationURI = sip-URI / sips-URI / pres-URI
> >> / http-URI / HTTPS-URI
> >> / cid-url ; (from RFC 2392)
> >> / absoluteURI ; (from RFC 3261)
> >> geoloc-param = generic-param; (from RFC 3261)
> >> routing-param = "routing-allowed" EQUAL "yes" / "no"
> >>
> >> The same wording is required with it
> >>
> >> 3) The following is a copy from my earlier posting:
> >>
> >> Geolocation-header = "Geolocation" HCOLON Geolocation-value
> >> *( COMMA Geolocation-value)
> >> Geolocation-value = locationValue / routing-param
> >> locationValue = LAQUOT locationURI RAQUOT
> >> *(SEMI geoloc-param)
> >> locationURI = sip-URI / sips-URI / pres-URI
> >> / http-URI / HTTPS-URI
> >> / cid-url ; (from RFC 2392)
> >> / absoluteURI ; (from RFC 3261)
> >> geoloc-param = generic-param; (from RFC 3261)
> >> routing-param = "routing-allowed" EQUAL "yes" / "no"
> >>
> >> The above is overly forgiving, in that it permits zero or more
> >> locationURIs and zero or more routing-params. That then needs to be
> >> tightened up with text. I think the text needs to say,
> more or less:
> >>
> >> - if there are any locationURIs in a sip request,
> >> then a routing-param MUST be present in the request
> >> - there MUST NOT be more than one routing-param present in a
> >> sip request.
> >> - there MUST NOT be more than two locationURIs in a sip request
> >> (if there is really a reason for such a restriction)
> >>
> >> 4) The following is a more radical change:
> >>
> >> Geolocation-header = "Geolocation" HCOLON locationValue
> >> [ COMMA locationValue ]
> >> locationValue = LAQUOT locationURI RAQUOT
> >> *(SEMI geoloc-param)
> >> locationURI = sip-URI / sips-URI / pres-URI
> >> / http-URI / HTTPS-URI
> >> / cid-url ; (from RFC 2392)
> >> / absoluteURI ; (from RFC 3261)
> >> geoloc-param = generic-param; (from RFC 3261)
> >>
> >> Georouting-header = "Geolocation-Routing" HCOLON
> >> ( "yes" / "no" / gen-value )
> >>
> >> This one needs to be accompanied by text stating that each of
> >> Geolocation-header and Georouting-header may appear at most once
> >> in a request, and that if Georouting-header is absent it defaults
> >> to "no".
> >>
> >> 5) A more lenient variant on (4):
> >>
> >> Geolocation-header = "Geolocation" HCOLON locationValue
> >> *( COMMA locationValue )
> >> locationValue = LAQUOT locationURI RAQUOT
> >> *(SEMI geoloc-param)
> >> locationURI = sip-URI / sips-URI / pres-URI
> >> / http-URI / HTTPS-URI
> >> / cid-url ; (from RFC 2392)
> >> / absoluteURI ; (from RFC 3261)
> >> geoloc-param = generic-param; (from RFC 3261)
> >>
> >> Georouting-header = "Geolocation-Routing" HCOLON
> >> ( "yes" / "no" / gen-value )
> >>
> >> This one needs to be accompanied by text stating that
> >> Georouting-header may appear at most once in a request, and that
> >> if Georouting-header is absent it defaults to "no".
> >>
> >> (The Geolocation-header can appear zero or more times.)
> >>
> >> This is only preferred to (4) if more than two locationValues
> >> are acceptable. ISTM that once we allowed two, allowing more
> >> makes sense, with the same limitations imposed with two - that
> >> its up to the recipient to figure out which to use.
> >>
> >> Of the above, I technically and esthetically prefer (5) - or (4) if
> >> the limitation to two URIs is important. I see no reason
> to *require*
> >> the routing-param if the default is understood to be "no".
> >>
> >> Pragmatically I think I prefer (1) - its the least
> variation from what
> >> has been recently discussed that, IMO, makes any sense.
> >>
> >>
> >>>> In that case, an intermediary that adds a locationValue
> not only MAY,
> >>>> but presumably MUST add a missing routing-param if it adds a
> >>>> locationValue.
> >>>
> >>> We can get there (i.e., allow this) without stating this
> is a MUST,
> >>> can't we?
> >>
> >>>> I have never understood why the routing-param is
> required to be last.
> >>>
> >>> maybe it doesn't need to be, but it certainly is easier for
> >>> monitoring/reading human to find if it is last when
> looking at a decode.
> >>>
> >>>> And as my examples show, its difficult/impossible to
> enforce this in
> >>>> ABNF.
> >>>>
> >>>> Thanks,
> >>>> Paul
> >>>
> >
> > _______________________________________________
> > sipcore mailing list
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/sipcore
> >
> _______________________________________________
> sipcore mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/sipcore
>