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

["Thomson, Martin" <[e-mail]>]

Hi James,

Looks like we've got most of the big stuff out of the way.

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

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

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.

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.

> >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.  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 "geolocation" 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? 

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.

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

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

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

> Thanks for reading this so quickly and providing comments (seriously)

Thanks for being responsive in return :)

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