 |
 |
 |
 |
|
 |
|
 |
|
 |
|
 |
|
|
|
|
|
|
|
|
|
|
|
|
Location Event Package:I support the introduction of a new event package, different from presence, to return
presence information. There are several reasons to have a different event package, among them:- LIS and Presence servers could be separate and then there would be a need to specify communication between them whenever a location request is received by a presence server; or we should specify how
to route the location request to LIS instead of Presence- LIS server can be present in a network that does not have any Presence server; in this scenario LIS
server could be overloaded with Presence requests, it doesn't support at all - LIS bring Lawful requirements to meet, where a Presence server does not. Moreover the location-package draft:- reuses the location response and error message from HELD, and I think is a clever idea. - define the What (the form of location) capability that is not present in the loc-filter draft, and also the When capability seems to be slightly different from what is defined in loc-filter. - the extension point is also another important capability that give the possibility to reuse what we already
have in loc-filter.So I do believe we have to progress this draft, and I am ready to give my help on it.
- Loc-filters:I have already send out a couple of days ago a mail where I have provided some comments and expressed my support both to the draft in general and to the idea of include in the draft filters
related to the quality (confidence/uncertainty).I have also other comments/suggestion to provide to this document, but I'll do in a different mail.
In my view the definition of new event package for location doesn't diminish the need of Loc-Filter,
even because the location-package make possible use Loc-Filter. what we should avoid is an overlap between the two drafts. -Location-get draft:I have also read this draft, and I should say that (if I understood it correctly) it only listen the set of filter that a *geopriv seeker* could specify in order to get specific pieces of location information. In a certain way it is a guideline (a requirement draft) for Location filter draft and having a clear view of
what a *geopriv seeker" could specify will help the progress of Loc-Filter /Sal James M. Polk wrote:
At 03:32 PM 7/18/2008, Brian Rosen wrote:I oppose the notion of another event package beyond presence to return a PIDF (containing, in this context, a PIDF-LO).I agree with this, given that this is what we agree to in IETF69 (Chicago).draft-ietf-geopriv-loc-filters was Rohan's ID that was supposed to have died abruptly based on this same Chicago decision, because he proposed an alternate event package to Presence, called "Location".What draft-polk-sip-location-get does is specify how SIP is used to both- solicit (the opposite of Conveyance) a location from another entity, and- to dereference a Conveyed locationURI (which is part of Conveyance)Both functions are done exactly the same way in draft-polk-sip-location-get.This ID also proposes a set of filters be created to specify which pieces of location information an entity (presence watcher, or geopriv seeker) wants to learn about another entity's location.This to me, which is summarized by Brian below, is a combination of the functionality of what both Brian's ID (was Rohan's and was supposed to have died) and James's IDs, therefore I believe draft-polk-sip-location-get should be the one to move forward - since it answers the part of Rohan's ID that agrees with the Chicago decision (while omitting what the Chicago decision didn't want going forward), and the part of James's direction (the set of filters specifying some of the different pieces of location information).At the same time, draft-polk-sip-location-get satisfies both how to subscribe to solicit and how to dereference a location URI. Neither of the others do both of these, that I have read.BTW -- draft-ietf-geopriv-loc-filters was never written to be a general purpose SIP dereference specification -- which is needed to complete the work started in Conveyance (that was there, until the Paris meeting actually, when it was split off).draft-ietf-geopriv-loc-filters is about triggered movement in and out of buildings.I the only capability draft-winterbottom-sip-location-package-00 offers over presence+loc-filters that I can see is the ability to specify the "what",i.e. the form of location. If this is desirable, we can add it to loc-filter. I must confess that I have had a very hard time understanding whatpolk-sip-location-get does. It appears to define filters for the presence package, somewhat like loc-filters, but there are some additions that are unclear to me (filter 1 filters on presentities, but unless the subscriptionURI is a list, there is only one presentity, but it doesn't say it's forlists, and if it is for lists, why do we need a filter on the list?). Many of the other filters seem to duplicate what is in loc-filters. There is nojustification offered for why an alternative to loc-filters is needed. I think we should continue working on loc-filters, adding a filter for "what" and not consider the other proposals. Brian > -----Original Message-----> From: geopriv-bounces at ietf.org [mailto:geopriv-bounces at ietf.org] On Behalf> Of Robert Sparks > Sent: Friday, July 18, 2008 4:07 PM > To: GEOPRIV > Cc: SIP IETF; sipping LIST > Subject: [Geopriv] Items of cross group interest > > This message is heavily crossposted. It is set to reply-to geopriv. > If you manually reply-to, please reply there. > > There are some questions about how to best provide location for some > applications. To date, the answer from GEOPRIV has been to use > Presence as defined by SIMPLE and extended by GEOPRIV. (We've spent > time arguing that in GEOPRIV more than once). > > There are some new proposals, perhaps with new information, that push > at that answer again, and in some cases, if they move forward, its not > clear what the best venue to vet them in is. But we have to start > somewhere, and the plan at the moment is to have a framing discussion > in GEOPRIV. > > Please review the following drafts, comment on the GEOPRIV list if you > have an opinion, and plan to attend this section of the GEOPRIV > meeting if you have an interest in how the conversation turns out. > > ------ > Location events/filters > draft-ietf-geopriv-loc-filters-02.txt > draft-winterbottom-sip-location-package-00.txt > draft-polk-sip-location-get-00.txt > _______________________________________________ > Geopriv mailing list > Geopriv at ietf.org > https://www.ietf.org/mailman/listinfo/geopriv _______________________________________________ Geopriv mailing list Geopriv at ietf.org https://www.ietf.org/mailman/listinfo/geopriv_______________________________________________ Geopriv mailing list Geopriv at ietf.org https://www.ietf.org/mailman/listinfo/geopriv
_______________________________________________ Geopriv mailing list Geopriv at ietf.org https://www.ietf.org/mailman/listinfo/geopriv