Subject: [Geopriv] Items of cross group interest

From: Robert Sparks <[email-masked]>
Date: Fri, 18 Jul 2008 15:07:03 -0500

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
[email-masked]
https://www.ietf.org/mailman/listinfo/geopriv

---

From: "Brian Rosen" <[email-masked]>
Date: Fri, 18 Jul 2008 16:32:37 -0400

I oppose the notion of another event package beyond presence to return a
PIDF (containing, in this context, a PIDF-LO).

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: [email-masked] [mailto:[email-masked]] 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
>

---

From: "James M. Polk" <[email-masked]>
Date: Fri, 18 Jul 2008 16:55:57 -0500

>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.

---

From: Salvatore Loreto <[email-masked]>
Date: Sun, 20 Jul 2008 12:26:56 +0300

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:
> pieces of location information an entity (presence watcher, or geopriv 
> seeker) wants to learn about another entity's location.
>
> subscribe to solicit and how to dereference a location URI. Neither of 
> the others do both of these, that I have read.
>

---

From: "Brian Rosen" <[email-masked]>
Date: Sun, 20 Jul 2008 10:35:28 -0400

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. 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.  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.

We can address differences in what the filters provide, but I don't yet see
any advantage in defining a new event package.

Brian

> From: Salvatore Loreto [mailto:[email-masked]]
> 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:

---

From: "Winterbottom, James" <[email-masked]>
Date: Sun, 20 Jul 2008 20:28:07 -0500

Hi Brian,

I totally disagree with your position on this as I don't think the basic
presence event package does cover some of the things that you need to be
able to do with location. For example I can't implement the example in
appendix 1 of the location package draft without fundamentally
re-interpreting how filters are intended to work, that is, inclusion or
exclusion. They don't support a "soft" inclusion.

If it is URIs that you are concerned about then we could simply
introduce a new URI type for this function of that it is clear what the
intended use of the URI is.

Sal is absolutely right that a LIS supporting this functionality doesn't
want the rest of the presence baggage and nor should it need to worry
about it. A new URI and event package is the best way to make this
happen in an unambiguous way.

Cheers
James

> Of Brian Rosen
> Sent: Monday, 21 July 2008 12:35 AM
> To: 'Salvatore Loreto'; 'James M. Polk'
> Cc: 'GEOPRIV'
> None of the reasons you offer seem to create a requirement which is
not
> met
> if it came in an LCP or geolocation header, then the only useful part
of
> the
> We can address differences in what the filters provide, but I don't
yet
> see
> > 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.
> > >> I oppose the notion of another event package beyond presence to
> return
> > a
> > > 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
geopriv
> > >> package, somewhat like loc-filters, but there are some additions
that
> > >> are
> > >> 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
> > >> I think we should continue working on loc-filters, adding a
filter
> for
> > >> > From: [email-masked]
[mailto:[email-masked]] On
> > >> Behalf
> > >> > 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
> > >> > Please review the following drafts, comment on the GEOPRIV list
if
> > you

------------------------------------------------------------------------------------------------
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]

---

From: Salvatore Loreto <[email-masked]>
Date: Mon, 21 Jul 2008 12:40:38 +0300

Hi Brian,

thanks for the answer, see my comments in line

Sal

Brian Rosen wrote:
> 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;
> 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
right, but you can use the location package to forward the request to 
the right server
>>>> I oppose the notion of another event package beyond presence to return
>>>>         
>> a
>>     
>>>> URI is a list, there is only one presentity, but it doesn't say it's
>>>>         
>> for
>>     
>>>>> From: [email-masked] [mailto:[email-masked]] On
>>>>>           
>>>> Behalf
>>>>         
>>>>> Of Robert Sparks
>>>>> at that answer again, and in some cases, if they move forward, its
>>>>>           
>> not
>>     
>>>>> Please review the following drafts, comment on the GEOPRIV list if
>>>>>           
>> you
>>

---

From: Salvatore Loreto <[email-masked]>
Date: Mon, 21 Jul 2008 12:50:18 +0300

I don't think we need a URI type for this function,
in my view a different event package from the presence one is enough.

what we really have to solve is:
the routing problem;
cover some of the things that are location specific and the presence 
event package doesn't cover.

Sal

Winterbottom, James wrote:
>> 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
>   
>> PIDF you get is the PIDF-LO.  In fact, with the location-package URI,
>>     
> you
>   
>>> 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
>   
>>> - LIS server can be present in a network that does not have any
>>>       
> Presence
>   
>>> - 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
>   
>>> So I do believe we have to progress this draft, and I am ready to
>>>       
> give
>   
>>> my help on it.
>>>
>>>
>>> - Loc-filters:
>>> and expressed my support both to the draft in general and to the
>>>       
> idea of
>   
>>> I have also other comments/suggestion to provide to this document,
>>>       
> but
>   
>>> I have also read this draft, and I should say that (if I understood
>>>       
> it
>   
>>> of filter that a *geopriv seeker* could specify in order to get
>>>       
> specific
>   
>>> In a certain way it is a guideline (a requirement draft) for
>>>       
> Location
>   
>>> what a *geopriv seeker" could specify will help the progress of Loc-
>>>       
>> Filter
>>     
>>> /Sal
>>>
>>>
>>> James M. Polk wrote:
>>>       
>>>> proposed an alternate event package to Presence, called
>>>>         
> "Location".
>   
>>>> - to dereference a Conveyed locationURI (which is part of
>>>>         
> Conveyance)
>   
>>>> This to me, which is summarized by Brian below, is a combination
>>>>         
> of
>   
>>>> draft-polk-sip-location-get should be the one to move forward -
>>>>         
> since
>   
>>>> decision (while omitting what the Chicago decision didn't want
>>>>         
> going
>   
>>>> 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
>   
>>>> general purpose SIP dereference specification -- which is needed
>>>>         
> to
>   
>>>> draft-ietf-geopriv-loc-filters is about triggered movement in and
>>>>         
> out
>   
>>>> of buildings.
>>>>
>>>>
>>>>         
>>>>> I must confess that I have had a very hard time understanding
>>>>>           
> what
>   
>>>>> justification offered for why an alternative to loc-filters is
>>>>>           
> needed.
>   
>>>>>> This message is heavily crossposted. It is set to reply-to
>>>>>>             
> geopriv.
>   
>>>>>> There are some questions about how to best provide location for
>>>>>>             
>> some
>>     
>>>>>> Presence as defined by SIMPLE and extended by GEOPRIV. (We've
>>>>>>             
> spent
>   
>>>>>> 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.
>>>>>>
>>>>>> meeting if you have an interest in how the conversation turns
>>>>>>             
> out.
>   
>>>>>> ------
>>>>>> Location events/filters

---

From: "Brian Rosen" <[email-masked]>
Date: Mon, 21 Jul 2008 08:30:20 -0400

You use the domain of the URI to route it correctly, the same as any other
sip URI.

Brian

> Sent: Monday, July 21, 2008 5:41 AM
> To: Brian Rosen
> Cc: 'James M. Polk'; 'GEOPRIV'
> >> server could be overloaded with Presence requests, it doesn't support
> at
> >> all

---

From: "Brian Rosen" <[email-masked]>
Date: Mon, 21 Jul 2008 08:34:57 -0400

Appendix A.1 shows a QoP filter. I don't see why we can't have a QoP filter
(issue a Notify when you have the specified quality).

There is no presence baggage.  The presence package is a very simple package
that returns a PIDF under specified conditions, and that's all it does.
That's all you need, as long as the filter allows you to specify the right
conditions.  I think it can.

Brian

> From: Winterbottom, James [mailto:[email-masked]]
> Sent: Sunday, July 20, 2008 9:28 PM
> To: Brian Rosen; Salvatore Loreto; James M. Polk
> Cc: GEOPRIV
> Subject: RE: [Geopriv] Items of cross group interest
> 
> Hi Brian,
>

---

From: Salvatore Loreto <[email-masked]>
Date: Mon, 21 Jul 2008 15:56:37 +0300

well of course I use the domain part of the URI if the URI is something 
like [email-masked]
but I am considering the scenario where the URI is [email-masked].

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

Sal

Brian Rosen wrote:
>>> None of the reasons you offer seem to create a requirement which is not
>>>       
>> met
>>     
>>> if it came in an LCP or geolocation header, then the only useful part of
>>>       
>> the
>>     
>>> We can address differences in what the filters provide, but I don't yet
>>>       
>> see
>>     
>>>> - LIS bring Lawful requirements to meet, where a Presence server does
>>>>         
>> not.
>>     
>>>> and also the When capability seems to be slightly different from what
>>>>         
>> is
>>     
>>>> defined in loc-filter.
>>>> and expressed my support both to the draft in general and to the idea
>>>>         
>> of
>>     
>>>>> What draft-polk-sip-location-get does is specify how SIP is used to
>>>>>           
>> both
>>     
>>>>>> I think we should continue working on loc-filters, adding a filter
>>>>>>             
>> for
>>     
>>>>>>> There are some new proposals, perhaps with new information, that
>>>>>>>               
>> push
>>

---

From: Salvatore Loreto <[email-masked]>
Date: Mon, 21 Jul 2008 16:00:52 +0300

Hi,

I have read carefully the draft and I have few comments on it:

1) in section 5.2, the last sentence is "This package, presence, does 
not define any additional parameters.", it seems "presence" should be 
changed to "loc-event".
2) in section 5.7, it is not clear how the privacy is handled.  For 
example, the location information may be transformed to reduce the 
accuracy before included in NOTIFY request.
3) in section 6, the schema defines a child element "QoP" for "what". 
But in Appendix A.1, the element name is called "quality". It is not 
consistent.
4) Sections 5.6.1.1 and 5.6.1.2 give the possibility to have an 
extension point, and in Appendix A the draft gives examples on how to 
include "QoP" and "location-filter" into the SUBSCRIBE request. Section 
6 "Schema" define the extension point as "any type" so it can be filled 
with any XML data. However  I personally think the draft should have 
strict definition on how to include QoS and filter into SUBSCRIBE message.

/sal

---

From: "Brian Rosen" <[email-masked]>
Date: Mon, 21 Jul 2008 09:36:43 -0400

Then you have the problem that all voice calls, instant messages, presence,
and any other event package goes to ONE hostname.  The event packages
specifically are often problematic if you always send every event
subscription through one address.  Presence is usually not the only package
implemented.

In really large systems, you don't even have all the presence subscriptions
coming to one domain; you split the presence system into multiple domains.  

Location URIs are not "well known"; the userpart should be opaque and not
have any identifying information in it.

For the most part, domains that provide LIS service aren't the same domains
that provide location service.  Really large integrated telecom carriers of
course have both broadband and calling/presence service offerings, but even
then, they are often separate domains.  

If it really has to be distinguished, try "[email-masked]"

Brian

> Sent: Monday, July 21, 2008 8:57 AM
> To: Brian Rosen

---

From: Salvatore Loreto <[email-masked]>
Date: Mon, 21 Jul 2008 22:23:41 +0300

Hi Brian,

see my comments on line

Sal

> subscription through one address.  Presence is usually not the only package
I am sorry but I don't agree at all.
it is common practice to subscribe to different events using the same 
address (e.g. AoR)
consider the scenario where I want subscribe to both Presence 
information and Registration
information, for both the event I'll use the same AoR (e.g. 
[email-masked])

so if I subscribe to the registration event package

SUBSCRIBE sip:[email-masked] SIP/2.0
Event: reg

when I subscribe to the presence event package

SUBSCRIBE sip:[email-masked] SIP/2.0
Event: presence

and in this scenario the two subscriptions don't go to the same 
hostname, because thanks to the network deployment
the proxy will forward, examining the Event header, the first to the 
Registrar Server and the second to the Presence Server.

> coming to one domain; you split the presence system into multiple domains.  
that is true, in a large domain there can be present several Presence 
servers each one taking care of a specific subdomain.
However in order to organize the network in such way I have to deploy it 
in a particular way (like in draft-ietf-simple-intradomain-federation),
but I don't think it works in location at all.
The fact that the userpart is opaque make a federation system almost 
impossible.
> have any identifying information in it.
correct!
in fact I don't think usepart part should be used to route the subscription
> then, they are often separate domains.  
sorry but I don't see the point here
> If it really has to be distinguished, try "[email-masked]"

again this doesn't work and in my opinion the definition of a new event 
package is easier to implement.

/sal
>>> You use the domain of the URI to route it correctly, the same as any
>>>       
>> other
>>     
>>> sip URI.
>>>
>>> Brian
>>>
>>>
>>>       
>>>> in such scenario, my concern is on how to route the request to the
>>>>         
>> right
>>     
>>>> server:
>>>>>>>>> From: [email-masked] [mailto:[email-masked]]
>>>>>>>>>                   
>> On
>>     
>>>>>>>>>                   
>>>>>>>> Behalf
>>>>>>>>
>>>>>>>>
>>>>>>>>                 
>>>>>>>>> Of Robert Sparks

---

From: "Brian Rosen" <[email-masked]>
Date: Tue, 22 Jul 2008 07:52:01 -0400

Hi Sal

> Registrar Server and the second to the Presence Server.
These are examples where you are using a well known AoR, and do not apply in
this case.  It is of course sometimes desirable to hand out human friendly
AoRs, and use them wherever appropriate, but the current issue is not one of
those cases.

> The fact that the userpart is opaque make a federation system almost
I disagree, but probably not worth pursuing

> in fact I don't think usepart part should be used to route the
While generally I agree, can you say why?  What would not work well?

> sorry but I don't see the point here
The ACCESS NETWORK is typically a totally separate operation from the entity
that provides calling/presence services under the same corporate umbrella.
It sometimes (but not always) has separate domains.

> package is easier to implement.
Having the top level domain of a carrier has some value in an AoR.  It's
short (because sometimes you have to type it).  It has some advertising and
marketing value, and it ties things that are related (contact addresses for
multiple services) together.  This doesn't apply, at all, to this problem.
A separate domain name would be, by far, the simplest implementation.

In this application only location processing elements pass the opaque string
around.  Your answers all make sense within services that have AoRs, but not
with location references. 

What is the practical problem in using a different hostname?
* The userpart is opaque, and hard to guess.  
* You don't distribute it in a way where humans see or type it
* By design, you should not be able to infer any user identity from it
* There is no commonality desirable with other systems

---

From: "James M. Polk" <[email-masked]>
Date: Tue, 22 Jul 2008 12:02:03 -0500

At 04:26 AM 7/20/2008, Salvatore Loreto wrote:
>a need to specify communication
>Presence server; in this scenario LIS

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.

>think is a clever idea.
>present in the loc-filter draft,
>what is defined in loc-filter.
>the possibility to reuse what we already
>have in loc-filter.
>
>give my help on it.
>idea of include in the draft filters
>but I'll do in a different mail.
>
>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.

>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:
>>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).
>>
>>out of buildings.
>>> [mailto:[email-masked]] On Behalf
>>> > Of Robert Sparks

---

From: "Winterbottom, James" <[email-masked]>
Date: Tue, 22 Jul 2008 19:21:35 -0500

James,

There are two distinct use cases in location conveyance.
The first is that I need to route a message from A to B and I need
location information to do that. In this case location is, essentially,
routing information, and a SIP error is appropriate.

The second use-case is that I am sending a end-point some information in
a SIP body. The SIP body in this case is simply transporting
application-level data that will be consumed by a higher-level
application, and SIP is simply serving as a transport to achieve that.
In this case I don't believe that a SIP header is appropriate, indeed it
is a protocol layering violation to use one!

The location subscription draft that Martin, Hannes and I have written
follows the layering principles described above. Where the location
application has been unable to provide the data requested it indicates
this with an application-level error.  You will note that we had a lot
of discussion in ECRIT and Geopriv about exactly these topics with
regards to using HTTP as a transport for HELD and LoST. These are
exactly the same principles and results are that we have clean protocol
design.

Cheers
James

Behalf
> Of James M. Polk
> Sent: Wednesday, 23 July 2008 3:02 AM
> To: Salvatore Loreto
> Cc: 'GEOPRIV'
at
not.
return
both
entity,
Conveyance)
> >>
> >>Both functions are done exactly the same way in
draft-polk-sip-location-
> get.
> >>>I the only capability draft-winterbottom-sip-location-package-00
offers
> over
that
it's
list?).
> >>>of the other filters seem to duplicate what is in loc-filters.
There is
> no
needed.
for
geopriv.
some
spent
its
start
if
out.

---

From: "James M. Polk" <[email-masked]>
Date: Thu, 24 Jul 2008 01:59:43 -0500

James

Do I understand you now (from what you write here) that you have a 
competitive solution, in draft-winterbottom-sip-location-package, to 
the Location Conveyance ID -- necessitating a complete rewrite of Conveyance?

---

From: Salvatore Loreto <[email-masked]>
Date: Thu, 24 Jul 2008 21:57:19 +0300

James M. Polk wrote:
>> at all

Hi James, I do think when we standardize a protocol we should consider 
all the scenarios in this case both
the case in which Presence Server and LIS are built together but also 
the case where they are two physically separate servers.

Sal

---

From: "Winterbottom, James" <[email-masked]>
Date: Mon, 28 Jul 2008 01:02:45 -0500

Absolutely not.

I am suggesting that the SIP location error headers should not be used
when the location information is not used as part of the routing
establish or is not critical to the establishment of a session. To do so
is a layering violation.

Cheers
James

> From: James M. Polk [mailto:[email-masked]]
> Sent: Thursday, 24 July 2008 5:00 PM
> To: Winterbottom, James; Salvatore Loreto
> Cc: GEOPRIV
On
> > > >server could be overloaded with Presence requests, it doesn't
support
does
"Location".
to
of
to
> > > >>subscribe to solicit and how to dereference a location URI.
Neither
to
> > > >>>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",
what
> > > >>>polk-sip-location-get does. It appears to define filters for
the
> > > presence
filter
that
>-----------------------------------------------------------------------
--
> -----------------------
>-----------------------------------------------------------------------
--
> -----------------------

---

From: "James M. Polk" <[email-masked]>
Date: Wed, 30 Jul 2008 09:27:49 -0500

At 01:57 PM 7/24/2008, Salvatore Loreto wrote:
>>>- LIS and Presence servers could be separate and then there would 
>>>be a need to specify communication
>>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.
>
>Hi James, I do think when we standardize a protocol we should 
>consider all the scenarios in this case both
>the case in which Presence Server and LIS are built together but 
>also the case where they are two physically separate servers.

I don't understand your comment. The decision in IETF69 considered 
both scenarios, and the WG made its decision.  Do you  believe we 
need to dredge through that decision again? I haven't heard anything 
new wrt that decision, therefore, I believe that such a recent 
decision should stand without having to go over again and again