Re: [Geopriv] SIP lbyr location deref using draft-mahy-geopriv-sip-loc-pkg-02.txt

From: Hannes Tschofenig ^lt;Hannes.Tschofenig@gmx.net>
Date: Sat Jul 14 2007 - 17:49:06 EDT

Hi Rohan,

Rohan Mahy wrote:
> Hi Hannes,
>
> Lets take the classic lbyr scenario where the target does not know its
> own location. Say that the target discovers the LIS and asks for lbyr.
> The LIS provides the target with both an http ref [1] and a sip
> reference [2]. The target passes the SIP reference to its presence
> server. The presence server subscribes to the raw location of the
> target using this new package.
So, here the disconnect starts.

We cannot the presence server just subscribe to the PIDF-LO as a
presence event package?
What it get's is a PIDF-LO. Done.

>
> What would you do instead? Clearly you need some description of how
> to do the dereferencing.

We have this since the idea of Jon was once that we just use the
presence mechanisms we have and apply them to the GEOPRIV work.

I could understand to define something new when we just carry "raw
location" -- the LO part of the PIDF-LO. This is, however, not want we
want -- at least not for the last few years.

> As I've said several times, I feel that the
> presence event package is a very poor choice because the semantics of
> the package is providing filtered presence (ability to communicate) of
> a presentity identified by its address used for communications (its
> SIP AOR such as [3]). Also, a SIP presence server role typically
> receives PUBLISH requests and SUBSCRIBE requests and generates NOTIFY
> requests for the presence event package, while a SIP deref requires
> the thing that runs as a presence server to *generate* SUBSCRIBE
> requests for this same package and correctly filter them.
But again in this example. The functionality is just that the PIDF-LO is
created and when you SUBSCRIBE to it then you receive it via a NOTIFY.
Done. There is just nothing else. Still, that does not require a new
event package.

The fact that in this case there is no PUBLISH should not cause any
troubles.

>
> In short I think this new proposed package is useful and captures the
> semantics correctly. On the other hand, the presence event package has
> the wrong semantics, the wrong identity, the wrong default privacy and
> security assumptions, and the wrong role for the job.
>
When it comes to the policy I recently suggested what should go in the
PIDF-LO per default. It might have found its way into SIP Location
Conveyance version -08.

> Finally, if you did frankenstein the presence event package, you would
> need to write a pretty beefy document describing how to profile it to
> your needs. Why not just define a new package? They don't cost
> anything?
>

Ciao
Hannes

> thanks,
> -rohan
>
> [1]
> https://lis892.provider.net/loc/P3hFzgeePiRpDS6/lexMhHPfO+kAsRKSe61DDB/YFGU=
>
> [2] sips:P3hFzgeePiRpDS6/lexMhHPfO+kAsRKSe61DDB/YFGU=@lis892.provider.net
> [3] sip:alice@example.com
>
>
> On 7/14/07, Hannes Tschofenig <Hannes.Tschofenig@gmx.net> wrote:
>> I noticed the publication of this document and I wasn't quite sure why
>> it is necessary.
>>
>> Rohan Mahy wrote:
>> > Hi,
>> >
>> > I resurrected an old draft I wrote. It is a SIP event package that
>> > could be used to deref lbyr location URIs. This proposal is in
>> > addition to whatever way we decide to deref using HTTP.
>> >
>> > The document is in the repository now as:
>> > draft-mahy-geopriv-sip-loc-pkg-02.txt
>> > If you prefer, the HTML version is at:
>> >
>> http://svn.resiprocate.org/rep/ietf-drafts/rohan/locpkg/draft-mahy-geopriv-sip-loc-pkg-02.html
>>
>> >
>> >
>> > thanks,
>> > -rohan
>> >
>> >
>> > _______________________________________________
>> > Geopriv mailing list
>> > Geopriv@ietf.org
>> > https://www1.ietf.org/mailman/listinfo/geopriv
>>
>>

_______________________________________________
Geopriv mailing list
Geopriv@ietf.org
https://www1.ietf.org/mailman/listinfo/geopriv
Received on Sat, 14 Jul 2007 23:49:06 +0200

This archive was generated by hypermail 2.1.8 : Sat Jul 14 2007 - 17:49:21 EDT