[Simple] By-reference and by-value

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

The sipcore-location-conveyance reboot discussion [1] raised an interesting problem.

( I've started this discussion on the simple WG list, since that is where I believe most presence data model expertise is likely to be concentrated.  I've bcc'd sipcore and geopriv, from which there might be interest in this discussion. )

One important feature is concurrent conveyance of location by-reference and by-value.  This is applied in different ways.

In one use case, a recipient might use this to get the location for now, and have a means of getting location for later.  This is important for emergency calling and it is fundamental to location hiding in ECRIT (draft-ietf-ecrit-location-hiding-req and draft-ietf-ecrit-rough-loc).

Jon suggests that "it is far less brittle to extend PIDF than to add this to SIP".  A claim that seems amply supported by exhibit B [2] and its persistent draft status.

I'd like to explore how we address this problem with a PIDF extension.

And...if this works out, perhaps we can also kill another bird [3] with the same stone.

The problem, as I see it, is the inclusion of presence state by reference, using a URI.  

Or, if we think of the URI as an unlinked pseudonym with associated presence state, it is the linking of that pseudonym to another entity with the intent of also linking the state.

( That last statement probably needs a bit more explanation.  In HELD, a LIS creates a location object.  The subject, or presentity, of that location object is a device. 

( For privacy reasons, we don't want to link the device identity to the location.  The device owner/rule maker might not wish for that to happen - this linkage must occur under their control.  Thus, the LIS creates an unlinked pseudonym for the device to use as the presentity identifier [4]. )

If an entity - user, device or otherwise - wishes for this information to be linked with them, they take the location information and use it in their own presence.

What this implies is that we need a way to link one presence document to another, using a URI.

You can also made a good argument that the linkage start from any of the four fundamental elements in the data model [RFC4479]: the un-typed <tuple>, <person>, <device>, or <service>.

The reference becomes the "status" of the element.  Thus, we have:

  <presence entity="pres:[e-mail]">
    <tuple id="sg89ae">
      <status>
        <br:reference>pres:[e-mail]</br:reference>
      </status>
    </tuple>
    <dm:person id="p1">
      <br:reference>pres:[e-mail]</br:reference>
    </dm:person>
    <dm:device id="pc122">
      <br:reference>pres:[e-mail]</br:reference>
      <dm:deviceID>mac:8asd7d7d70</dm:deviceID>
    </dm:device>
  </presence>

Information provided by HELD or DHCP relates to a device (HELD is clear about this, and I assume the same to be true for DHCP).  For location, the referenced document might include specific typing for the presence data that it includes, or it might be intentionally silent.

A PIDF document that includes a reference could specify type, by adding the reference to a typed element.  In this simple case, this would be <device>, but it's also possible to make a statement about a person - and their proximity to the device - by using the <person> element.

The referenced document might use typed elements.  Or, both documents could avoid explicit statements on type.  There is no real risk of confusion - even if both documents specify type, this only declares that both entities share presence data.

It's tempting to specify how this information is subsequently composited.  However, someone with far more experience in this area than I pointed out that any attempt to do so would be both destructive and futile.  Let the recipients decide how they want to structure the data.

For a presence server that receives a publish containing this data, they choose how this is presented to watchers.  There is a choice over what to provide: no information, information retrieved from the reference and composited somehow, or the URI.  Policy also has a say in this.

It would be remiss not to also address the policy concerns.  RFC 5025 (presence policy) describes provide-* rules that are used to limit what a presence recipient can see.  This is particularly important in this case.

Policy can be crafted to apply to a subscription, but the same might not be true of the reference that is thereby revealed.  From a privacy policy perspective, this is a problem.  This is especially problematic when you consider that a reference can live longer than the subscription that revealed it.

RFC 5025 has specific policy points for controlling how each presence attribute is revealed.  Geopriv-policy extends those for both of the location types.  Default is to suppress unknown attributes, which is good, but no existing element has the same potential for damage as a reference.

Thus, we need to define a <provide-reference> extension to presence policy.  Moreover, the related discussion on the implications of including this in a policy need to be made clear.  Better that than rely on <provide-unknown-attribute> and the ability of rule makers to recognize all the risks.

My intent is to submit a draft that describes how to include a reference in a PIDF document and all the consequences arising from that.

I'd be happy to hear from someone who is willing to provide assistance or even to undertake the effort themselves.

--Martin

[1] Thread head: <http://www.ietf.org/mail-archive/web/sipcore/current/msg02202.html>
[2] <http://tools.ietf.org/html/draft-ietf-sipcore-location-conveyance>
[3] <http://tools.ietf.org/html/draft-garcia-geopriv-indirect-publish> ...and by kill, I really mean it.  This effort is likely subsumed by the proposed work, though a section on the implications seems appropriate.
[4] For the same reason, our product does not use the <device> element, because that requires a linkage to device identity.