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

From: Hannes Tschofenig ^lt;Hannes.Tschofenig@gmx.net>
Date: Sun Jul 15 2007 - 16:03:17 EDT

A LIS is not a presence server. That's fine. But this terminology aspect
is pretty irrelevant for this discussion.

Dawson, Martin wrote:
> I think that Rohan is saying that the LIS is not a presence server. I
> agree with him. So something other than a presence package for
> subscribing to a location feed is more appropriate.
>
> Cheers,
> Martin
>
> -----Original Message-----
> From: Brian Rosen [mailto:br@brianrosen.net]
> Sent: Monday, 16 July 2007 4:35 AM
> To: 'Rohan Mahy'
> Cc: 'GEOPRIV'; rjs@estacado.net
> Subject: RE: [Geopriv] SIP lbyr location
> derefusingdraft-mahy-geopriv-sip-loc-pkg-02.txt
>
> Rohan
>
> I am sorry, but I'm baffled. I read your answer twice and can't make
> heads
> or tails over it. There is something in your head that isn't coming
> through.
>
> So far as I can tell, you have not offered a single technical argument.
> Using presence to return a PIDF with location works for all uses your
> event
> package does. Nothing in the presence RFCs even suggests that using
> presence in the way we are talking about is wrong.
>
> You argue that we have built up some conventions on how we use presence,
> so
> far, that this use would not conform to. I'll give you that, but I
> don't
> see any harm, and I see considerable good, in having a somewhat richer
> notion of presence. Specifically, any single aspect of presence could
> have
> some separate mechanism for getting it if all you wanted was that one
> thing.
> But I think the notion that we should invent a separate event package
> for
> each doesn't make any sense, and I don't see why location should be
> different.
>
> I am particularly confused by the presence server that subscribes
> discussion. Are you thinking that there is a problem with a "real" (in
> your
> eyes) presence server subscribing to an access networks presence server
> so
> that the "real" presence server can provide location? That's the only
> way I
> can interpret what you said. I can't think of any other reason a
> presence
> server would need to subscribe. If that's it, then the "real" presence
> server is a presence aggregator, which I think we'll see a lot of and
> should
> not be at all worried about it. "Real" presence requires aggregation of
> multiple service providers who provide a subset of presence for one
> service.
> To aggregate, the aggregator subscribes to the service presence system
> to
> build a composite view. This case is EXACTLY that; the access network
> operates a genuine presence system. It's just that the only really
> interesting tags in the PIDF are the PIDF-LO tags. So what? Why is
> that in
> any way not in the spirit of presence? Why is the notion that a "real"
> presence server might have to subscribe to another to build up a more
> complete picture of the user offend you?
>
> Brian
>
>
>> -----Original Message-----
>> From: Rohan Mahy [mailto:rohan@ekabal.com]
>> Sent: Sunday, July 15, 2007 1:53 PM
>> To: Brian Rosen
>> Cc: Rohan Mahy; 'Rohan Mahy'; 'Hannes Tschofenig'; 'GEOPRIV';
>> rjs@estacado.net
>> Subject: Re: [Geopriv] SIP lbyr location deref
>>
> usingdraft-mahy-geopriv-
>
>> sip-loc-pkg-02.txt
>>
>> Hi Brian,
>>
>> On Jul 14, 2007, at 2:12 PM, Brian Rosen wrote:
>>
>>> I'm sorry, I am confused. Perhaps you could expand on some of this:
>>>
>> Before I start, let me point out that so far there is no *technical*
>> objection to defining a new location event package. I think everyone
>> will have to concede that the approach I described will work. I also
>> cannot imagine any harm being caused if we decide to define a new
>> location event package.
>>
>> All the objections that have been raised against defining a new event
>> package are that we already have an event package that some claim can
>> be bended and blended to our purposes. All around me I hear folks
>> say "we can *just* use the presence event package", or "using the
>> presence event package is obvious and trivial". I think we have been
>> talking about this for so long that many of us assume that the
>> problem is trivial without having bothered to examine all the
>> problems associated.
>>
>> Also, just because you can do a thing, it does not mean that you
>> should. I think it is very important that each event package has a
>> crisp set of semantics. Having a few extra event packages than if we
>> try to maximally conserve them is a good thing.
>>
>> Below I will raise (again) the legitimate technical and semantic
>> objections I have to reusing the presence event package.
>>
>>
>>> 1. How you do dereferencing: you are given a sip uri. You
>>> subscribe to it.
>>> It immediately returns a PIDF. The PIDF has location in it.
>>> Depending on
>>> the filter parameters, you may get location (presence) updates.
>>>
>> We agree that the dereferencer sends a SUBSCRIBE request to the
>> location URI. I think this dereferencing should use a dedicated
>> event package. I feel that using the presence event package is
>> inappropriate and harmful for conveying *raw* location.
>>
>>
>>> 2. Is there a rule somewhere that says that a presence URI has to
>>> be an AoR?
>>> I don't recall one. Is there some problem with an arbitrary string
>>> used to
>>> identify which presentity you want presence for? For example, if
>>> it was a
>>> hash of a telephone number, would that run afoul of some
>>> specification?
>>>
>> I think it is sensible that a presence URI should be able to provide
>> presence data.
>> When generating a location reference, the LIS/LCS will need to
>> generate a location URI. This URI must not be a pres: URI because
>> the URI would not provide any PRESENCE data (information about the
>> ability of the presentity to communicate) and certainly by my
>> definition, the URI does not even refer to a PRESENTITY.
>>
>> As for using an AOR for presence data, we have tradition and
>> deployment experience to guide us.
>> The traditional usage of the presence event package is to subscribe
>> to presence information about a presentity. Also traditionally in SIP/
>> SIMPLE systems this subscription is sent to an AOR. Deployed
>> implementations either operate a presence server (presence agent co-
>> located with a proxy server), or they fork subscriptions to multiple
>> edge presence agents. In both cases, the Request URI in the SUBSCRIBE
>> is an AOR that can also be used to communicate with the presentity.
>>
>>
>>> 3. I am mightily confused by "requires the thing that runs as a
>>> presence
>>> server to *generate* SUBSCRIBE requests". See item 1 above. You
>>> subscribe
>>> to the URI you are given, it returns presence-with-location. Where
>>> am I
>>> losing you?
>>>
>> Sorry. That was not especially clear. Lets not use any pronouns.
>> Pronouns will make an ambiguous sentence even more ambiguous.
>>
>> Lets say that provider.net operates a SIP-based presence service.
>> For convenience, I will use the term "presence server" to mean a
>> centralized, data-center set of nodes that act as PRESENCE AGENTs and
>> perform presence aggregation, policy, authorization, and filtering.
>> The presence server at sip:provider.net expects to receive SUBSCRIBE
>> and PUBLISH requests for the presence event package, and SUBSCRIBE
>> requests for watcher info. The presence server at provider.net
>> combines all the raw information it has for the PRESENTITY Alice and
>> composes a handful of presence documents: one each for neutral state,
>> any buddy, coworkers, and close friends.
>>
>> The provider.net presence server follows a traditional, well-
>> understood industry definition of one type of "presence-server". A
>> key simplicity of defining the role of a presence server is that is
>> receives presence subscriptions and publications and generates
>> notifications for its active subscriptions.
>>
>> I think it is terribly confusing and very sloppy semantics to now
>> have a "presence-server" also generate subscribe requests to the very
>> same presence event package. "But Mommy, I thought a presence-server
>> *received* subscribe requests? Yes, dear *usually* it does, but
>> *this* presence server is *different*"
>>
>>
>>> 4. The presence server will get PUBLISH requests, although I expect
>>> quite a
>>> few Location Information Servers who have presence interfaces to
>>> get the
>>> information through another protocol. However, the case where an
>>> endpoint
>>> has a GPS chip and PUBLISHES his location to his presence server
>>> should also
>>> be common.
>>>
>> An endpoint that generates its own location should be able to
>> disclose it in the context of presence or not. Sending a presence
>> publication with embedded location is fine. The presentity better be
>> very sure that the presence server understands whether it needs to
>> further filter that location. Here is one of the ambiguities of
>> using the presence event package.
>>
>> Case 1. The target wants to do its own filtering. It obfuscates or
>> fuzzes its location appropriately and then incorporates it in a
>> presence publication. The presence server only has to know if a
>> specific watcher is allowed to get the location object.
>>
>> Case 2. The target provides completely raw unprocessed location to
>> the presence server. The presence server does location-based
>> filtering based on the raw location on a watcher-by-watcher basis.
>>
>> I am sure you can imagine errors where confusing these two cases can
>> lead to leaking private information or sending friends to the wrong
>> location.
>>
>>
>>> 5. I'll admit that we need somewhat different filter
>>> characteristics for
>>> location than for other presence data. You want a filter that is
>>> something
>>> like "send me an update when location changes by x-amount, but
>>> don't send
>>> more than y updates per second/minute/hour/day". However, it
>>> really is a
>>> filter, and I *think* that's a pretty straightforward extension to
>>>
> the
>
>>> presence filter mechanism.
>>>
>> We already have a working group item for a filter mechanism: draft-
>> ietf-geopriv-loc-filters-01
>> This is not an extension to presence filtering, it is a standalone
>> filter format that is a very straightforward example of the RFC 3265
>> event package filter concept. It would work with both presence and/
>> or a separate location event package.
>>
>>
>>
>> The reason I think a new event package is appropriate is that the
>> semantics would be clearer.
>>
>> In addition, I think the following are additional compelling
>> technical or semantic reasons to use a separate package.
>>
>> 1) We could make a clear distinction by package between processed
>> (presence) and raw (location). This would avoid ambiguities and
>> disclosure errors.
>>
>> 2) Caller preferences/Callee Capabilities routing by event package
>> would work much more effectively.
>>
>> 3) The traditional authentication and authorization of presence
>> subscriptions (dynamic user-based prompting) is different from the
>> authentication and authorization mechanisms used for location (metro-
>> ticket or pre-existing trust).
>>
>> 4) Watcher info is not as essential for location-only subscriptions.
>>
>> 5) Avoid the confusion of presence servers subscribing to pseudo-
>> presence.
>>
>> 6) By definition, the information we are subscribing to is not
>> presence (ability to communicate), it is location information. The
>> name and definition of the package should match its actual use.
>>
>> thanks,
>> -rohan
>>
>>
>>
>>
>>> Brian
>>>
>>>
>>>> -----Original Message-----
>>>> From: Rohan Mahy [mailto:rohan.mahy@gmail.com]
>>>> Sent: Saturday, July 14, 2007 4:08 PM
>>>> To: Hannes Tschofenig
>>>> Cc: GEOPRIV; rjs@estacado.net; Rohan Mahy
>>>> Subject: Re: [Geopriv] SIP lbyr location deref usingdraft-mahy-
>>>> geopriv-
>>>> sip-loc-pkg-02.txt
>>>>
>>>> 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.
>>>>
>>>> What would you do instead? Clearly you need some description of
>>>>
> how
>
>>>> to do the dereferencing. 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.
>>>>
>>>> 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.
>>>>
>>>> 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?
>>>>
>>>> thanks,
>>>> -rohan
>>>>
>>>> [1]
>>>> https://lis892.provider.net/loc/P3hFzgeePiRpDS6/lexMhHPfO
>>>> +kAsRKSe61DDB/YFG
>>>> U=
>>>> [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
>>>>
>
>
>
> _______________________________________________
> Geopriv mailing list
> Geopriv@ietf.org
> https://www1.ietf.org/mailman/listinfo/geopriv
>
> ------------------------------------------------------------------------------------------------
> 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@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 22:03:17 +0200

This archive was generated by hypermail 2.1.8 : Sun Jul 15 2007 - 16:04:03 EDT