Re: [Geopriv] PIDF-LO Profile thoughts and a way forward

From: Henning Schulzrinne ^lt;>
Date: Fri Aug 10 2007 - 10:28:21 EDT

I'm in favor of option (2) simply because I don't see the separation.
Presence information will be used by end points to obtain their own
location, so we'll have to deal with this. I have also made proposals
and sent text showing that this isn't particularly onerous. As I have
demonstrated, there is also a serious danger of making decisions that
simply won't work for the more general case.

Plus, probably 2/3 of the profile document is concerned with general
location encoding issues, not ordering.

I'm happy to provide text and comment on proposals that address this
issue. I suspect that this will take about a paragraph of
description, mainly to deal with the case that there's a device or
person element.


On Aug 8, 2007, at 10:00 PM, Winterbottom, James wrote:

> Hi All,
> One of the actions that came out of the meeting in Chicago was for
> people with opinions about PIDF-LO profile to go away and read the
> Presence Data Model RFC-4479. I have gone away and read this now and
> have come back not seeing how this helps address the issue of which
> location to use for routing a call.
> Let me give some background of where PIDF-LO profile had it roots.
> Several years ago now NENA started work on a migratory standard for
> emergency VoIP calls. This basically said, lets assume that the call
> originates in the VoIP world, but has to terminate at legacy
> circuit-switched PSAPs. We looked for location formats and objects and
> decided, for better or worse, to use the PIDF-LO. It has some nice
> characteristics about it, but because it is flexible and extensible
> presence document when you want a definitive answer for something
> it can
> be really hard to get one. This latter point is stressed
> consistently in
> RFC-4479 with comments like "... resolution of ambiguity is best
> left to
> the watcher that consumes the document". So I wrote a very basic
> set of
> rules (note 4479 wasn't out at this point and PIDF-LO was still a
> draft)
> that would the NENA i2 routing node, the VPC, to pick a location
> out of
> a PIDF-LO document to use for routing.
> This was the birth of PIDF-LO profile. It was extended to address
> common
> geodetic shapes that people might require, but the basic profile
> was set
> to allow a downstream consumer of location to have no doubt about
> where
> the upstream user of a device was.
> Having a document that describes generally how location can be used in
> presence documents is an admirable to thing to want. It is not,
> however,
> the purpose for which PIDF-LO profile was written, and modifying
> profile to address specifically this would mean that its initial
> intent
> would not be served, leaving us with a serious deficiency with regards
> to using PIDF-LO in routing applications.
> I therefore have two proposals for the WG to consider.
> 1) We leave PIDF-LO profile as it is, and address specifically the
> routing aspect. A second document is commissioned purely for
> addressing
> the open presence profile concerns (my preference).
> 2) We try and address both the routing aspect and general presence
> concerns in the same document.
> Please provide comments as I want to get this document closed.
> Cheers
> James
> ----------------------------------------------------------------------
> --------------------------
> This message is for the designated recipient only and may
> contain privileged, proprietary, or otherwise private information.
> If you have received it in error, please notify the sender
> immediately and delete the original. Any unauthorized use of
> this email is prohibited.
> ----------------------------------------------------------------------
> --------------------------
> [mf2]
> _______________________________________________
> Geopriv mailing list

Geopriv mailing list
Received on Fri, 10 Aug 2007 10:28:21 -0400

This archive was generated by hypermail 2.1.8 : Fri Aug 10 2007 - 10:30:22 EDT