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

From: Rohan Mahy ^lt;rohan@ekabal.com>
Date: Sun Jul 15 2007 - 13:52:46 EDT

Hi,

On Jul 14, 2007, at 2:49 PM, Hannes Tschofenig wrote:
> 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.

"JUST" ...
That's a very dangerous word.

Please have a look at my email to Brian.

>> 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.

Hopefully you read the draft. It is quite short.

Getting "raw" location is EXACTLY what my presence server wants to
get from my LIS. This is EXACTLY why I proposed a new event package
for this specific purpose.

To be VERY clear, the event package I proposed would only be used to
dereference location-only URIs. We would continue to use the
presence event package to get the authenticated, authorized, and
possibly filtered, hidden, and obfuscated presence and embedded
location associated with a PRESENTITY from a PRESENCE AGENT (one
which is probably what the industry colloquially calls a presence
server).

>> 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.

Well perhaps we could use the message-summary event package to get
raw location too! I can "just" put "application/pidf+xml" in the
Accept header in the SUBSCRIBE right? Of course this idea is absurd
because the event package has the WRONG SEMANTICS.

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

Please read my response to Brian.

>> 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.

What is described in section 3.6 of location conveyance is not a
dereferencing scheme as described in draft-marshall-geopriv-lbyr-
requirements. This section hopelessly confuses location included with
bonafide presence (ability to communicate), from raw location that
contains no information about the ability to communicate.

thanks,
-rohan

>> 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 Sun, 15 Jul 2007 10:52:46 -0700

This archive was generated by hypermail 2.1.8 : Sun Jul 15 2007 - 13:53:10 EDT