Re: [Geopriv] Items of cross group interest

From: Salvatore Loreto ^lt;salvatore.loreto@ericsson.com>
Date: Mon Jul 21 2008 - 08:56:37 EDT

well of course I use the domain part of the URI if the URI is something
like xyzabc@lis.example.com
but I am considering the scenario where the URI is xyzabc@example.com.

there could be several good reason why I don't want to disclosure my
domain configuration

Sal

Brian Rosen wrote:
> You use the domain of the URI to route it correctly, the same as any other
> sip URI.
>
> Brian
>
>
>> -----Original Message-----
>> From: Salvatore Loreto [mailto:salvatore.loreto@ericsson.com]
>> Sent: Monday, July 21, 2008 5:41 AM
>> To: Brian Rosen
>> Cc: 'James M. Polk'; 'GEOPRIV'
>> Subject: Re: [Geopriv] Items of cross group interest
>>
>> Hi Brian,
>>
>> thanks for the answer, see my comments in line
>>
>> Sal
>>
>> Brian Rosen wrote:
>>
>>> Salvatore
>>>
>>> None of the reasons you offer seem to create a requirement which is not
>>>
>> met
>>
>>> by the existing presence event package. You can create a LIS which is
>>> independent of a real presence system and use the same event package for
>>> both. The URIs would be different, but the syntax and semantics is the
>>> same.
>>>
>> in such scenario, my concern is on how to route the request to the right
>> server:
>> if the syntax and semantics of the URIs is the same, and the event
>> package is the same "presence"
>> how the request will be delivered to the right server?
>> how any proxy in the network will be able to discriminate if to forward
>> a request to an *independent* LIS
>> or to a real presence system?
>>
>>> You know "what kind" of URI you have by the method you got it;
>>> if it came in an LCP or geolocation header, then the only useful part of
>>>
>> the
>>
>>> PIDF you get is the PIDF-LO.
>>>
>> I completely agree on this point, the UA of course know "what kind" of
>> URI is using, because it knows what method it used to get it.
>> However, the problem is in the SUBSCRIBE request and in forward it.
>>
>>
>>> In fact, with the location-package URI, you
>>> can't tell by looking at the URI whether you should use presence or
>>> location-package; you use the same information to decide.
>>>
>>>
>> right, but you can use the location package to forward the request to
>> the right server
>>
>>> We can address differences in what the filters provide, but I don't yet
>>>
>> see
>>
>>> any advantage in defining a new event package.
>>>
>>> Brian
>>>
>>>
>>>
>>>
>>>> -----Original Message-----
>>>> From: Salvatore Loreto [mailto:salvatore.loreto@ericsson.com]
>>>> Sent: Sunday, July 20, 2008 5:27 AM
>>>> To: James M. Polk
>>>> Cc: Brian Rosen; 'GEOPRIV'
>>>> Subject: Re: [Geopriv] Items of cross group interest
>>>>
>>>> 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 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@ietf.org [mailto:geopriv-bounces@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@ietf.org
>>>>>>> https://www.ietf.org/mailman/listinfo/geopriv
>>>>>>>
>>>>>>>
>>>>>> _______________________________________________
>>>>>> Geopriv mailing list
>>>>>> Geopriv@ietf.org
>>>>>> https://www.ietf.org/mailman/listinfo/geopriv
>>>>>>
>>>>>>
>>>>> _______________________________________________
>>>>> Geopriv mailing list
>>>>> Geopriv@ietf.org
>>>>> https://www.ietf.org/mailman/listinfo/geopriv
>>>>>
>>>>>
>>>>>
>>>
>>>
>
>
>

_______________________________________________
Geopriv mailing list
Geopriv@ietf.org
https://www.ietf.org/mailman/listinfo/geopriv
Received on Mon, 21 Jul 2008 15:56:37 +0300

This archive was generated by hypermail 2.1.8 : Mon Jul 21 2008 - 08:56:50 EDT