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

From: "Winterbottom, James" <[email-masked]>
Date: Wed, 8 Aug 2007 21:00:13 -0500

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 PIDF-LO
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
[email-masked]
https://www1.ietf.org/mailman/listinfo/geopriv

---

From: Henning Schulzrinne <[email-masked]>
Date: Fri, 10 Aug 2007 10:28:21 -0400

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.

Henning

---

From: "Tschofenig, Hannes" <[email-masked]>
Date: Mon, 13 Aug 2007 09:23:25 +0200

Hi James, 
Hi all, 

I am trying to catch-up with my mail.

I just wanted to state that the text written by James below refers to the history of the rules and not to the history of the profiling of the GML-based location usage in RFC 4119. 

Regarding the way forward with the rules: I prefer option (1) with the text Henning proposed some time ago. 
Here is the text Henning proposed on the 18th July:
I have no problem having conditional text that says something like "For applications that require that only one location is delivered, the following additional considerations apply...". Location conveyance or whatever application that falls into that category (which I actually doubt in the particular case), could then simply refer to the "Section [Single-Location] of RFC4119bis applies here". 
<<<<

It will, however, be necessary to consider RFC 4479 since it essentially updates RFC 4119 with regard to the placement of location information within a presence document. (*) 

Ciao
Hannes

(*): RFC 4479 is another good example where different working groups work on one subject without most participants in one WG (in this case GEOPRIV) actually knowing that RFC 4479 has an impact for RFC 4119. 

> -----Ursprüngliche Nachricht-----
> Von: ext Winterbottom, James [mailto:[email-masked]] 
> Gesendet: Donnerstag, 9. August 2007 04:00
> An: [email-masked]
> Betreff: [Geopriv] PIDF-LO Profile thoughts and a way forward
> 
> Hi All,
>