Re: [sipcore] Review of draft-ietf-sipcore-location-conveyance-00 sections 1 to 3

["James M. Polk" <[e-mail]>]

At 01:07 PM 7/2/2009, Elwell, John wrote:
>James,
>
>Thanks for attending to my comments. Just some remarks on the ones you
>queried.
>
> > >- "It is possible, and it fact, planned in certain
> > >    circumstances to have SIP requests routed based on the
> > location of
> > >    the target. This means SIP servers can be location recipients. If
> > >    this is not desired by a location inserter - the act of including
> > >    location into this request, then a separate indication
> > is given in
> > >    the Geolocation header it this usage is allowed."
> > >I am not sure what the last sentence means - a "location inserter" is
> > >not an "act of including location into this request".
> >
> > the inserter term does come out of the blue, so I'll clarify this, as
> > it is an important point.
>[JRE] Sorry, perhaps my comment was not clear, but the way the sentence
>is constructed suggests that "a location server" is "the act of
>including...". I don't have a problem with the term "inserter", but with
>the words that follow and the general sentence construction.

that makes more sense now, thanks


> >
> > >I think what might
> > >be undesirable is not the fact that SIP servers can be location
> > >recipients, but the fact that they might use location information for
> > >routing.
> >
> > you do not like the idea of servers routing a request based on the
> > contained location?
>[JRE] My comment is misunderstood. I am talking about what the inserter
>does not desire. I believe the text is trying to cover the case where
>the location inserter does not desire that location be used for routing.

thanks again


> >
> > can you clarify, please
>[JRE] I hope my explanations above are clear.

yep


> >
> > if you do feel this way, then I disagree with you, as this is central
> > to emergency services and other source based routing (i.e., directing
> > the message based on where the UAC is, instead of what the
> > destination address is).
> >
> > >I think the last sentence should be rewritten something like
> > >this.
> > >   "The location inserter is able to include a separate
> > indication in the
> > >Geolocation header field to denote whether routing on the
> > basis of the
> > >target's location is permitted."
> >
> > regardless of hte above, this sentence is not wrong, and does make a
> > good point, so I'll look at including it.
> >
> >
> > >If we do this, then the last sentence seems to follow on
> > nicely from the
> > >first sentence, and the second sentence seems to get in the way, so
> > >delete the second sentence. If we really need to retain the second
> > >sentence, at least change "SIP servers" to "SIP proxies"
> > (since a UAS is
> > >also a SIP server).
> >
> > wrt proxies vs. servers -- I tried to account for there being B2BUAs
> > at the same place as proxies would be, to attempt to get them to
> > behave in nearly identical ways based on this spec.
>[JRE] SIP RFCs have traditionally not specified B2BUA behaviour (whether
>or not that is good, I don't wish to debate here). Also, if you do want
>to include B2BUAs, you would need to make it more clear, e.g., define
>server as meaning proxy or B2BUA (maybe redirect too, I guess). On the
>other hand, a UAS, although it is a server, cannot route, so maybe my
>point is moot.

yeah - I know this is a tough one, and someone else said making this 
small change to "server" does give one more leverage to mean more 
than proxy if the discussion goes that way (anywhere). theoretically, 
we cannot really do anything about b2buas, but this is a - perhaps 
vein - attempt to include them in the discussion to keep them 
behaving, while not getting into the argument of calling them out and 
having to explain that (which would be an endless argument from 
someone who wants to dig in their heels).


> > >- " LbyR refers to a UA
> > >    including a location URI in a SIP request header field
> > which can be
> > >    dereferenced by a Location Recipient to receive Alice's Location
> > >    Object, in the form of a PIDF-LO."
> > >The header field is not dereferenced, it is the location URI that is
> > >dereferenced.
> >
> > this is an artifact of the acronym "LbyR" being considered an
> > archiecture by the Geopriv WG for about a year (some still feel it
> > is), where I believe LbyR is just a location URI.  This is an attempt
> > to have the Geopriv folks understand that the Location URI, which is
> > the Geolocation header value is used to dereference the
> > Target's location.
>[JRE] I agree, but my original complaint still holds, i.e., it is the
>URI that is dereferenced, not the header field.

I agree, and will make it clear by saying it's the header value that 
is used to make the dereference

>The header field
>contains more than just the URI.
>
> >
> > >I would suggest (also making other parts of the sentence
> > >more generic):
> > >    "LbyR refers to a Location Server
> > >    including in the header of a SIP request a location URI
> > that can be
> > >    dereferenced by a Location Recipient to receive a Location
> > >    Object, in the form of a PIDF-LO, representing the Target's
> > >location."
> >
> > interesting suggestion... connecting the UAC as the Target that's
> > really acting as a Location Server. While true, this might confuse
> > SIP specific folks.  Then again, maybe not - given that what you
> > state above is accurate.
>[JRE] The point I was trying to make is that we also allow a proxy to be
>a Location Server, i.e., to insert the location. Location Server is
>therefore more accurate than UA.

you're right, and I was clarifying that the target - if that's the 
UAC that created the PIDF-LO and inserted it in the SIP request - is 
also a Location Server.  I'll make this clear on all accounts.


> > >- "or on an external server (LbyR)"
> > >It is not clear what "external" is relative to. Change to:
> > >   "or on a server (LbyR)"
> >
> > it is meant to emphasize that LbyR is a location URI pointing towards
> > the location record that does not reside on the location target
> > itself (even if the target is an LS), it is on another entity.
> > perhaps I do not need to make this point.
>[JRE] It is not clear to me, so I would indeed prefer to remove
>"external".

ok, I will.

Thanks again!

James


>John