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

From: Tschofenig, Hannes ^lt;>
Date: Mon Aug 13 2007 - 03:23:25 EDT

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. (*)


(*): 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 []
> Gesendet: Donnerstag, 9. August 2007 04:00
> An:
> Betreff: [Geopriv] PIDF-LO Profile thoughts and a way forward
> 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

Geopriv mailing list
Received on Mon, 13 Aug 2007 09:23:25 +0200

This archive was generated by hypermail 2.1.8 : Mon Aug 13 2007 - 03:25:21 EDT