RE: [Geopriv] SIP lbyr location deref usingdraft-mahy-geopriv-sip-loc-pkg-02.txt

From: Brian Rosen ^lt;br@brianrosen.net>
Date: Sun Jul 15 2007 - 14:35:22 EDT

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
Received on Sun, 15 Jul 2007 14:35:22 -0400

This archive was generated by hypermail 2.1.8 : Sun Jul 15 2007 - 14:35:40 EDT