Re: [sipcore] location-conveyance-03 just submitted

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

At 07:09 PM 7/13/2010, Thomson, Martin wrote:
>Hi James,
>
>Looks like we've got most of the big stuff out of the way.

very cool to hear (err, read)!


> > >Content indirection has some interesting benefits.  It's a good idea.
> >
> > it has always been in Conveyance, but might have been lost in the
> > clutter.
>
>The 4483 reference was less explicit than your new Section 4.5.

fair point


>James (W) and I have been discussing the 
>implications of this, and there is one note that 
>might need revisiting in light of this.
>
>The mechanism for location by reference requires 
>access to request bodies.  For intermediaries, 
>this is OK, because of the new mechanism that 
>you have developed.  However, the following text 
>in Section 4.1 is probably now out of date:
>
>    A SIP intermediary MAY add a Geolocation header field if one is not
>    present - for example, when a user agent does not support the
>    Geolocation mechanism but their outbound proxy does and knows their
>    Location...

This text is actually new, though the meaning was 
present in previous versions. What this means is 
that if a SIP request does not have a Geolocation 
header value, one *MAY* (i.e., more like _can_, 
but not all the way) be added by a SIP 
intermediary (i.e., proxy, b2bua, sbc, 
etc).  This last description is important -- as 
proxies cannot legally (per any RFC) 
add/modify/delete a MIME part (part), a b2bua or 
sbc can.  Many enterprise SIP systems are built 
around b2buas as their call servers - expressly 
for this capability (and for many other reasons 
too). This document isn't advocating or 
recommending intermediaries insert a Geolocation 
header value when one is not present in a 
received SIP request, but this doc makes it possible, that's all.

>
> > >I have some comments that includes one major issue.
> > >
> > >The major issue:
> > >
> > >The limitation to _one_ location value has
> > >undeniable benefits.  It also prevents the
> > >conveyance of location value and reference together.
>...
> > >Jon's original response to this was to push the
> > >composition problem to the PIDF-LO.  That could be done,
> >
> > that is what's done, there is no 'could'. The
> > text surrounding Figure 4 states this, and the
> > example in 5.2 explains this is the example
> > albeit showing two composed values from different sources.
>
>The composition scenario is a valid one, but it 
>still has the inherent limitations of location 
>by value - you can't get updates.

correct, not without possessing a location URI of 
the Target. But, that's what the geopriv-filters 
ID is for, defining how to subscribe to a Target 
(or its compositor server) to ask for current location of the Target.


>The use case is basically: route based on the 
>value, but provide a reference so that a PSAP 
>can get better location information later; that 
>is, updated or more accurate location.  That's 
>not possible if the UAC does the dereference: 
>the location information becomes fixed.

"...UAC does the dereference"? Do you mean to 
understand that the UAC inserts location towards 
an intermediary, gets a rejection 424, with the 
intermediary's version of where the UAC is - 
possibly as a location URI, and has to 
dereference that URI to compose the now dual location MIME body?

This is not how we mean for you to have read the section.

We mean to have the intermediary do the 
dereference (if one is needed) and compose in the 
SIP 424 response a MIME body with both the 
server's version or both locations of the Target, 
and for that dual location single presence 
document to be copied into the next SIP request 
from that UAC (towards that same intermediary).

Also, we do a little dance around idea - in text 
- the concept of us not expecting the 
intermediary receiving a 911 or 112 style 
emergency call from ever returning a 424 
rejection. We say we expect, but can't say this 
normatively, that the intermediary will become a 
b2bua for that call setup and compose (or 
overwrite) the location in the SIP request and 
forward that towards a PSAP/emergency call center.

I think this is inconsistent with the phonebcp, which will need to be fixed.

Does this make sense?


>There are multiple ways to address this 
>problem.  One idea - that may be a bad one, I 
>don't know yet - is to add a reference to a 
>Content-Location header in combination with the 
>PIDF-LO value.  The other was to add PIDF extensions for indirection.

I don't know what a "Content-Location" header is, 
but given that Jon created the PIDF-LO, and was 
instrumental in this Conveyance rewrite, he's 
proposing the above be the solution.


> > >The structure of the Geolocation-Error header
> > >description is a little odd.  It seems that you
> > >are trying to describe *classes* of error and
> > >specific errors at the same time.  Separating
> > >these concerns might make this easier to explain and understand.
> >
> > the errors are in categories, of which, only one
> > category has more than one error code(the 3XX category about
> > permissions).
>
>I understand, my concern was that the 
>description of the classes didn't make it 
>sufficiently clear that each of the 1xx, 2xx and 
>4xx classes had a single error code in them.

oh... yeah, I think I agree (even without looking 
back at it). That's been at the back of my mind 
since Jon whacked another section that I wrote in 
an early version of this -03. I was meaning to 
get back to that.  I'll make it clear that each 
are classes, where each x00 error code has a text 
string that's clearly understood (similar to 
what's there in the IANA section now). I'll make 
it clearer that how more error codes can be added to each category too.

>By combining the definition of that single error 
>code with the definition of the class that 
>contained them, it makes it hard to distinguish 
>what description applies to just the code, and 
>what applies to the class as a whole.
>
> > >The draft doesn’t really justify the existence
> > >of the "geolocaocation" option tag.
> >
> > what would justify it?
> >
> > the purpose of an option-tag is the ability to
> > indicate support for an extension (whether
> > optional or required), and to respond with
> > whether or not an extension is supported or
> > unsupported. This indication can be quite
> > important for communicating SIP elements to
> > understand support for (or not). I'm confused...
>
>Why is indicating support for (or requirement 
>of) this particular feature important?  If a UAC 
>includes the header, is that not sufficient 
>indication of support?  What reason might a UAC 
>have for requiring that the UAS supports the feature?

any other SIP request where understanding that 
the location of the UAC is vitally important to 
properly process the request is another.

for example, 911 is one I believe.

But calling Pizza Hut's national URI, I might 
require that UAS to understand where I am in 
order to take my order, or reject my request.  A 
more likely scenario is for a roadside towing 
service that I don't have a prior relationship 
with. I would want to not call again to those 
that don't understand 'location', and only call those that do in the future.


>One justification for Supported might be that it 
>is not possible to send 424 without some prior 
>acknowledgement that the code is understood by 
>the UAC.  That might be sufficient.

hmm... sounds good to me. I'll add it. Thanks!


> > >Section 5 should show an example use of content
> > >indirection for a location URI.
> >
> > I'll talk to my co-authors about this, as they
> > are the ones limiting the number of examples  ;-)
>
>Just a request - though it seemed like a fairly 
>major omission.  In comparison (and this might 
>just be my perspective) the composition example seems less significant.

less significant... I'm not sure how to take that 
(as there is more than one way it might go).

Two of us felt it important that there be an 
example of a composed single MIME body for some 
readers.  Are you suggesting, that you feel the 
composed dual value body is of less value than one value and one reference?

>
> > this might be a good point. I'll talk to my
> > co-authors about breaking up section 3 into sub-sections (1 per
> > Figure).
>
>That would help a lot, I think.  Thanks.
>
> > >The examples in Section 5 are not schema-valid
> >
> > this is quite possible. This was a bit cobbled together.
>
>They were almost perfect.  I've corrected the 
>two examples and added them to the bottom of 
>this email.  I've validated these and made sure 
>that they don't have excessively long lines :)

a BIG thank you for this!!


> > >"black phone" is a little jargon-y.
> >
> > it's certainly known inside the voice/telephony world.
>
>Sure.  That doesn't make it any less jargon-y though.

I guess it's also pre-Blackberry, and we don't 
want anyone getting mad... I'll work on it.


> > >More amusing was the idea that your
> > >characterisation of a person was as a "non-IP device".
> >
> > many readers misunderstand when talking about
> > Alice, it's one of her electronic devices that
> > SIP communicates with, not her directly.
>
>That's an important distinction, but not one 
>that I would have inferred from the 
>text.  Perhaps you meant to say: "non-IP device 
>(a personal device such as a black phone)".

that would work. I'll make the change


> > Thanks for reading this so quickly and providing comments (seriously)
>
>Thanks for being responsive in return :)

Thanks again

James


>
> > James
> >
> >
> > >--Martin
>
>Example from 5.1:
>
>   <presence
>       xmlns="urn:ietf:params:xml:ns:pidf"
>       xmlns:gp="urn:ietf:params:xml:ns:pidf:geopriv10"
>       xmlns:gbp="urn:ietf:params:xml:ns:pidf:geopriv10:basicPolicy"
>       xmlns:cl="urn:ietf:params:xml:ns:pidf:geopriv10:civicAddr"
>       xmlns:gml="http://www.opengis.net/gml"
>       xmlns:dm="urn:ietf:params:xml:ns:pidf:data-model"
>       entity="pres:[e-mail]">
>     <dm:device id="target123-1">
>       <gp:geopriv>
>         <gp:location-info>
>           <gml:location>
>             <gml:Point srsName="urn:ogc:def:crs:EPSG::4326">
>               <gml:pos>32.86726 -97.16054</gml:pos>
>             </gml:Point>
>           </gml:location>
>         </gp:location-info>
>         <gp:usage-rules>
>           <gbp:retransmission-allowed>false
>           </gbp:retransmission-allowed>
>           <gbp:retention-expiry>2010-07-30T20:00:00Z
>           </gbp:retention-expiry>
>         </gp:usage-rules>
>         <gp:method>802.11</gp:method>
>       </gp:geopriv>
>       <dm:deviceID>mac:1234567890ab</dm:deviceID>
>       <dm:timestamp>2010-07-28T20:57:29Z</dm:timestamp>
>     </dm:device>
>   </presence>
>
>Example 5.2:
>
>   <presence
>       xmlns="urn:ietf:params:xml:ns:pidf"
>       xmlns:gp="urn:ietf:params:xml:ns:pidf:geopriv10"
>       xmlns:gbp="urn:ietf:params:xml:ns:pidf:geopriv10:basicPolicy"
>       xmlns:dm="urn:ietf:params:xml:ns:pidf:data-model"
>       xmlns:cl="urn:ietf:params:xml:ns:pidf:geopriv10:civicAddr"
>       xmlns:gml="http://www.opengis.net/gml"
>       entity="pres:[e-mail]">
>     <dm:device id="target123-1">
>       <gp:geopriv>
>         <gp:location-info>
>           <gml:location>
>             <gml:Point srsName="urn:ogc:def:crs:EPSG::4326">
>               <gml:pos>32.86726 -97.16054</gml:pos>
>             </gml:Point>
>           </gml:location>
>         </gp:location-info>
>         <gp:usage-rules>
>           <gbp:retransmission-allowed>false
>           </gbp:retransmission-allowed>
>           <gbp:retention-expiry>2010-07-30T20:00:00Z
>           </gbp:retention-expiry>
>         </gp:usage-rules>
>         <gp:method>802.11</gp:method>
>       </gp:geopriv>
>       <dm:deviceID>mac:1234567890ab</dm:deviceID>
>       <dm:timestamp>2010-07-28T20:57:29Z</dm:timestamp>
>     </dm:device>
>     <dm:person id="target123">
>       <gp:geopriv>
>         <gp:location-info>
>           <cl:civicAddress>
>             <cl:country>US</cl:country>
>             <cl:A1>Texas</cl:A1>
>             <cl:A3>Colleyville</cl:A3>
>             <cl:RD>Treemont</cl:RD>
>             <cl:STS>Circle</cl:STS>
>             <cl:HNO>3913</cl:HNO>
>             <cl:FLR>1</cl:FLR>
>             <cl:NAM>Haley's Place</cl:NAM>
>             <cl:PC>76034</cl:PC>
>           </cl:civicAddress>
>         </gp:location-info>
>         <gp:usage-rules>
>           <gbp:retransmission-allowed>false
>           </gbp:retransmission-allowed>
>           <gbp:retention-expiry>2010-07-30T20:00:00Z
>           </gbp:retention-expiry>
>         </gp:usage-rules>
>         <gp:method>triangulation</gp:method>
>       </gp:geopriv>
>       <dm:timestamp>2010-07-28T12:28:04Z</dm:timestamp>
>     </dm:person>
>   </presence>