Re: [Geopriv] Items of cross group interest
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Geopriv] Items of cross group interest
At 04:26 AM 7/20/2008, Salvatore Loreto wrote:
>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.
so, having read the thread through Brian's message early on 7/22, I
have a simple observation Salvatore, you want the separate event
package to route the SIP SUBSCRIBE correctly, the rest is just
attempting to justify this core requirement.
I don't agree with your requirement - and Brian has already said why,
but let me add -- that if you have a SIP request routing problem, an
event package name differentiation shouldn't be relied upon to make
the routing decision.
>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.
gee, but here are two points from why you like the location-package
draft that this draft also does
> - 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 "clever" errorring that the location-package draft shouldn't
exist, because everything should be based on what the SIP subscriber
understands, which is a SIP response - which is stated in RFC 3265
and 4661 already (which are nearly complete as is). The Location-get
draft will expand this list (probably only slightly) to exactly what
should be done by the subscriber UAC for each type of location based
error. Taking the "actionable" view that is done in Location
Conveyance, which the Geopriv WG already blessed.
so, that's half of your stated 4 ideas that are covered by the
Location-get draft, yet you didn't mention them. Plus 1 of the 4
ideas that shouldn't be done in the first place.
Admittedly, I have to think about what you say about your last
capability, "the extension point", before considering incorporating
it into the Location-get draft.
>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 specis-ascii"; Format="flowed"
Sender: geopriv-bounces at ietf.org
Errors-To: geopriv-bounces at ietf.org
At 04:26 AM 7/20/2008, Salvatore Loreto wrote:
>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.
so, having read the thread through Brian's message early on 7/22, I
have a simple observation Salvatore, you want the separate event
package to route the SIP SUBSCRIBE correctly, the rest is just
attempting to justify this core requirement.
I don't agree with your requirement - and Brian has already said why,
but let me add -- that if you have a SIP request routing problem, an
event package name differentiation shouldn't be relied upon to make
the routing decision.
>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.
gee, but here are two points from why you like the location-package
draft that this draft also does
> - 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 "clever" errorring that the location-package draft shouldn't
exist, because everything should be based on what the SIP subscriber
understands, which is a SIP response - which is stated in RFC 3265
and 4661 already (which are nearly complete as is). The Location-get
draft will expand this list (probably only slightly) to exactly what
should be done by the subscriber UAC for each type of location based
error. Taking the "actionable" view that is done in Location
Conveyance, which the Geopriv WG already blessed.
so, that's half of your stated 4 ideas that are covered by the
Location-get draft, yet you didn't mention them. Plus 1 of the 4
ideas that shouldn't be done in the first place.
Admittedly, I have to think about what you say about your last
capability, "the extension point", before considering incorporating
it into the Location-get draft.
>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" coufy 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 what
>>>polk-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 subscription
>>>URI is a list, there is only one presentity, but it doesn't say it's for
>>>lists, 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 no
>>>justification 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
>>> > sld 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 what
>>>polk-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 subscription
>>>URI is a list, there is only one presentity, but it doesn't say it's for
>>>lists, 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 no
>>>justification 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 startomewhere, 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
_______________________________________________
Geopriv mailing list
Geopriv at ietf.org
https://www.ietf.org/mailman/listinfo/geopriv
>>> > 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
_______________________________________________
Geopriv mailing list
Geopriv at ietf.org
https://www.ietf.org/mailman/listinfo/geopriv
Note: Messages sent to this list are the opinions of the senders and do not imply endorsement by the IETF.
