Subject: Re: [Simple] New Indirect publication draft

From: Qian Sun <[email-masked]>
Date: Mon, 03 Mar 2008 10:38:12 +0800

In a controlled environment the authorization things could be done in the third party (such as LCP), not by the Presence Server.  If you do not delegate publications task to the LCP, the LCP would not disclose your location information without your permission. This kind of delegation has nothing to do with Presence Server.

Qian

-----Original Message-----
From: Miguel Garcia [mailto:[email-masked]] 
Sent: Friday, February 29, 2008 6:27 PM
To: Qian Sun
Cc: 'Salvatore Loreto'; 'Tschofenig Hannes (NSN - FI/Espoo)'; 'SIMPLE mailing list'; 'Henning Schulzrinne'
Subject: Re: [Simple] New Indirect publication draft

If we going to do third party publications, for sure we need a mechanism 
for controlling authorization. Honestly, no matter whether you are in a 
controlled environment (such as the OMA architecture) or not. I wouldn't 
like that my operator suddenly starts disclosing my location information 
  without my permission, just because this information is coming from a 
trusted source.

Furthermore. We have discussed the issue of how we will need a mechanism 
for the end user to provide publication authorization rules. This will 
control the rules, but at the end of the day, if the LCP server does not 
want to provide the location information to the presence server, then 
such information won't be present in the PIDF.

In other words. We need a mechanism at the user's disposal for 
controlling when and how these indirect publications are done. The 
proposal to use third party publication is lame, IMHO, for privacy reasons.

/Miguel

Qian Sun wrote:
> Hi,
> 
> Maybe we do not need the mechanism for authorizing external parties to do publications on your behalf, if the Presence Server trusts the PNA (or other AS).
> In OMA, the IM server may directly publish the on/off status of presentity to the Presence Server without the authorization mechanism.
> 
> Qian
> 
> -----Original Message-----
> From: Salvatore Loreto [mailto:[email-masked]] 
> Sent: Wednesday, February 27, 2008 6:55 PM
> To: Miguel Garcia
> Cc: Qian Sun; 'Tschofenig Hannes (NSN - FI/Espoo)'; 'SIMPLE mailing list'; 'Henning Schulzrinne'
> Subject: Re: [Simple] New Indirect publication draft
> 
> Hi,
> 
> in line
> 
> /Sal
> 
> Miguel Garcia wrote:
>> To make this work like you said, you will need:
>>
>> - A mechanism for authorizing external parties to do publications on 
>> your behalf. I am not sure if we have such mechanism in place.
> [Sal] I am not sure we have such mechanism, too.
> However, as other standardization bodies (3GGP and OMA) are thinking to 
> insert a PNA (Presence Network Agent) maybe we should start to think of 
> a mechanism like this.
> 
> see also this draft: 
> http://tools.ietf.org/wg/simple/draft-rosen-simple-watcher-count-00.txt
> 
> 
>> - A mechanism for instructing the presence server to switch on/off 
>> your location information towards watchers. We do have this mechanism, 
>> and it is presence authorization rules. So, if in my device I have 
>> some UI entry that indicates "toggle location information", when I act 
>> upon it, the device will change the presence authorization rules.
>>
>> What I am proposing is that the "toggle location information" in the 
>> UI will trigger a new (partial) PUBLISH from the presentity. I think 
>> it matches better with the general architecture of the presentity 
>> providing his location.
> [Sal] Of course what I am suggesting would require some form of 
> authorization mechanism, and people could start to argue about the 
> complexity of the delegation mechanism.
> However also in your proposal, you want to change in some way the 
> Presence Server behavior and let it to change/update the presence 
> information  not only when it receives a PUBLISH, but also via the 
> de-reference mechanism.
> 
>  
>> /Miguel
>>
>> Salvatore Loreto wrote:
>>> Hi Miguel,
>>>
>>> surely I am missing something,
>>> but if it is only a presence authorization rules problem, then the 
>>> presentity should in some way authorize the
>>> presence server to receive information, better location information, 
>>> from a specific LCP server
>>> and then let the LCP server directly PUBLISH presentity's location 
>>> value to Presence Server.
>>>
>>> /Sal
>>>
>>> Miguel Garcia wrote:
>>>> Hi Qian:
>>>>
>>>> Yes, an LCP server can publish the presentity's PIDF-LO to the 
>>>> presence server. The problem here is that, under normal 
>>>> circumstances, the presence server will not merge this PIDF-LO with 
>>>> the current presentity's PIDF, because the presentity didn't publish 
>>>> location information in the first place, so presumably it doesn't 
>>>> even have presence authorization rules, etc.
>>>>
>>>> /Miguel
>>>>
>>>>
>>>> Qian Sun wrote:
>>>>  
>>>>> Hi,
>>>>>
>>>>> Could  LCP Server as a presence source directly PUBLISH presentity's
>>>>> location value to Presence Server?  Presence Server can compose a 
>>>>> merged
>>>>> PIDF document including presence information from different sources.
>>>>>
>>>>> Cheers,
>>>>> Qian
>>>>>
>>>>> -----Original Message-----
>>>>> From: [email-masked] [mailto:[email-masked]] On 
>>>>> Behalf Of
>>>>> Miguel Garcia
>>>>> Sent: Monday, February 18, 2008 10:12 PM
>>>>> To: SIMPLE mailing list
>>>>> Cc: Tschofenig Hannes (NSN - FI/Espoo); Henning Schulzrinne
>>>>> Subject: [Simple] New Indirect publication draft
>>>>>
>>>>> Hi:
>>>>>
>>>>> We have just submitted a draft that discusses the issue of indirect
>>>>> publication. The first part of the draft focuses on location URIs, so,
>>>>> perhaps it is of not much interest to the SIMPLE WG.
>>>>>
>>>>> Filename:     draft-garcia-simple-indirect-presence-publish
>>>>> Revision:     00
>>>>> Title:         Indirect Presence Publication with the Session 
>>>>> Initiation Protocol(SIP)
>>>>> Creation_date:     2008-02-18
>>>>> WG ID:         Independent Submission
>>>>> Number_of_pages: 12
>>>>>
>>>>> http://www.ietf.org/internet-drafts/draft-garcia-simple-indirect-presence-pu 
>>>>>
>>>>> blish-00.txt
>>>>>
>>>>> Comments are welcome.
>>>>>
>>>>> /Miguel
>>>>>     
>>>>   
> 

-- 
Miguel A. Garcia           tel:+358-50-4804586
Nokia Siemens Networks     Espoo, Finland

_______________________________________________
Simple mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/simple

---

From: Miguel Garcia <[email-masked]>
Date: Mon, 03 Mar 2008 14:35:55 +0200

Qian:

You are assuming a model where the presence server will accept 
indiscriminate publications from any other party without authorization. 
This is far from the Internet model where the presence server should be 
authenticating publication of presence, so, I don't think we need to 
discuss that model in the list.

/Miguel

---

From: Salvatore Loreto <[email-masked]>
Date: Tue, 04 Mar 2008 18:08:53 +0200

Hi Miguel,

see in line

Sal

Miguel Garcia wrote:
> If we going to do third party publications, for sure we need a 
> mechanism for controlling authorization. Honestly, no matter whether 
> you are in a controlled environment (such as the OMA architecture) or 
> not. I wouldn't like that my operator suddenly starts disclosing my 
> location information  without my permission, just because this 
> information is coming from a trusted source.
[Sal] I agree, in a third party publications a mechanism for controlling 
authorization is necessary.
IMO it is necessary not only for location information but for all the 
presence information.
>
> Furthermore. We have discussed the issue of how we will need a 
> mechanism for the end user to provide publication authorization rules. 
> This will control the rules, but at the end of the day, if the LCP 
> server does not want to provide the location information to the 
> presence server, then such information won't be present in the PIDF.
>
[Sal] My idea was slightly different,
instead of the UA requesting a URI to the LCP server, then provide that 
URI to the Presence Server and finally let the Presence Server asking 
the LCP server to perform a PUBLISH request towards the Presence Server,
just let the UA requesting the LCP server to perform a PUBLISH request 
towards the Presence Server.

Of course there should be also scenario where the UA completely delegate 
a LCP to perform PUBLISH of location information, but this is another story

Sal

>
> /Miguel
>
> Qian Sun wrote:
>> Hi,
>>
>> Maybe we do not need the mechanism for authorizing external parties 
>> to do publications on your behalf, if the Presence Server trusts the 
>> PNA (or other AS).
>> In OMA, the IM server may directly publish the on/off status of 
>> presentity to the Presence Server without the authorization mechanism.
>>
>> Qian
>>
>> From: Salvatore Loreto [mailto:[email-masked]] Sent: 
>> Wednesday, February 27, 2008 6:55 PM
>> To: Miguel Garcia
>> However, as other standardization bodies (3GGP and OMA) are thinking 
>> to insert a PNA (Presence Network Agent) maybe we should start to 
>> think of a mechanism like this.
>>
>> see also this draft: 
>>> your location information towards watchers. We do have this 
>>> mechanism, and it is presence authorization rules. So, if in my 
>>> device I have some UI entry that indicates "toggle location 
>>> information", when I act upon it, the device will change the 
>>> presence authorization rules.
>>>
>>>> presence server to receive information, better location 
>>>> information, from a specific LCP server
>>>>> circumstances, the presence server will not merge this PIDF-LO 
>>>>> with the current presentity's PIDF, because the presentity didn't 
>>>>> publish location information in the first place, so presumably it 
>>>>> doesn't even have presence authorization rules, etc.
>>>>>
>>>>> /Miguel
>>>>>
>>>>>
>>>>> Qian Sun wrote:
>>>>>  
>>>>>> Hi,
>>>>>>

---

From: Qian Sun <[email-masked]>
Date: Wed, 05 Mar 2008 10:34:56 +0800

Hi,

Yes, it is not suitable for Internet model. So I just say "In a controlled environment":)

There are still three ways to go:
1) Indirect publication
2) Publication authorization rules, just like the presence authorization rules for Subscription (Common policy)
3) A more general delegation mechanism, not only for PUBLISH, but also for INVITE, MESSAGE etc. Sometimes the third party may initiate a call or send a MESSAGE on another user's behalf. The delegation information should be delivered in these SIP messages. This is kind of similar to REFER mechanism, but here we need not a REFER message to trigger the delegated action (such as INVITE).

Opinions?

Qian

-----Original Message-----
From: Miguel Garcia [mailto:[email-masked]] 
Sent: Monday, March 03, 2008 8:36 PM
To: Qian Sun
Cc: 'Salvatore Loreto'; 'Tschofenig Hannes (NSN - FI/Espoo)'; 'SIMPLE mailing list'; 'Henning Schulzrinne'
Subject: Re: [Simple] New Indirect publication draft

Qian:

/Miguel

---

From: Miguel Garcia <[email-masked]>
Date: Wed, 05 Mar 2008 09:32:10 +0200

> towards the Presence Server.

Sal,

If you support emergency calls, you need to get your location 
information. If you get this location information with an indirect 
reference, how can you make usage of this information if you want to 
publish it? Isn't that easy to simply pass the reference embedded in 
your presence information to the presence server?

You are proposing to do an orthogonal mechanism that does not re-use the 
information you've got already: the location reference. I would like to 
understand what is the advantage, because honestly I don't see it.

/Miguel

---

From: Miguel Garcia <[email-masked]>
Date: Wed, 05 Mar 2008 09:49:04 +0200

> 3) A more general delegation mechanism, not only for PUBLISH, but also for INVITE, MESSAGE etc. Sometimes the third party may initiate a call or send a MESSAGE on another user's behalf. The delegat…

The last one needs to find the use cases. And I don't know how this will 
fit into the general architecture for SIP services.

/Miguel

---

From: Salvatore Loreto <[email-masked]>
Date: Wed, 05 Mar 2008 12:30:44 +0200

Hi Miguel

> your presence information to the presence server?
well in this scenario of course you have to find an easy way to make 
usage of this information, no question.
even if, I do not think it is, let me say, efficient to relay on a 
presence server in an emergency scenario

/Sal

>
> You are proposing to do an orthogonal mechanism that does not re-use 
> the information you've got already: the location reference. I would 
> like to understand what is the advantage, because honestly I don't see 
> it.
>
> /Miguel
>

---

From: "Brian Rosen" <[email-masked]>
Date: Wed, 5 Mar 2008 15:16:34 -0500

Why do you need to PUBLISH the data?

The reference could be one of two things:
1) A SIP reference that returns a PIDF
2) A HELD reference that returns a PIDF

In case 1) there is no problem.  The LIS, which is a presence server, has
the value.

If it's case 2, then for an emergency call, we just send the reference, not
a PIDF.  We don't publish.  The conveyance mechanism allows this.

The same is true for all location based routing.  Take a call to Pizza Hut.
The location reference is sent in the SIP INVITE.  A proxy uses LoST to
route, first doing a dereference to get a value.  The right Pizza Hut gets
the call, does it's own dereference and dispatches it's driver.  No publish.

Where is the use case where some entity gets a reference, and has to do a
publish?  I think in all such use cases, if there are any, the entity that
has the reference can dereference it and publish the result.

Brian 

> From: [email-masked] [mailto:[email-masked]] On Behalf
> Of Miguel Garcia
> Sent: Wednesday, March 05, 2008 2:32 AM
> To: Salvatore Loreto
> Cc: 'Henning Schulzrinne'; 'Tschofenig Hannes (NSN - FI/Espoo)'; 'SIMPLE
> mailing list'

---

From: Miguel Garcia <[email-masked]>
Date: Thu, 06 Mar 2008 09:26:22 +0200

Inline discussion.

> Why do you need to PUBLISH the data?

Well, I don't *need*, but I may *want* to publish my location in presence.

> a PIDF.  We don't publish.  The conveyance mechanism allows this.

And here is the analogy. For emergency calls you can send the reference, 
location conveyance allows you to do it, but if it is presence, I cannot 
currently do it. I could publish other references (see CIPID, RFC 4482), 
but not location references.

> has the reference can dereference it and publish the result.

Right, the current method is to de-reference the  location and publish 
it. Isn't that insane? I get my own location (as a reference), which I 
don't really care. But when I want to publish to my authorized list of 
buddys, I need to de-reference it, and embed it into my presence 
information, and do the publication. This is a waste of bandwidth.

If we compare with CIPID, it is like if I were de-referencing my 
<homepage>, <icon>, <map>, etc. elements and getting their values into 
the PIDF. Quite inefficient, I would say. I want to do with location 
information the same I would do with CIPID elements.

/Miguel

---

From: "Brian Rosen" <[email-masked]>
Date: Thu, 6 Mar 2008 12:45:03 -0500

Okay, I think I see the issue.  You didn't describe the real problem.

Presence always sends values.  If the LIS supplies a reference, it has to be
dereferenced every time you send a presence update.  In fact, unless we get
some kind of an event notification, HELD is useless for this application;
you would have to poll at some interval to use it.

So, for this use case, given current protocol directions, the reference has
to be a sip reference.  That's okay; the real presence server is then
aggregating presence from the LIS (which is itself a presence server).

However, in that case, the PS should subscribe to the LIS to get updates,
and send presence updates as a result.  For that to work, the PS has to get
the reference, and then we ask, how does it get it? Then you need something
like what you proposed so the PS can learn the SIP URI to subscribe to at
the LIS.

Brian

> Sent: Thursday, March 06, 2008 2:26 AM
> To: Brian Rosen
> Cc: 'Salvatore Loreto'; 'Henning Schulzrinne'; 'Tschofenig Hannes (NSN -
> FI/Espoo)'; 'SIMPLE mailing list'
> Behalf
> the

---

From: Miguel Garcia <[email-masked]>
Date: Thu, 06 Mar 2008 20:28:10 +0200

Hi Brian:

This is what we the authors initially thought when we started the draft.

Now, more recently, we thought that there is one more alternative. So, 
rather than the presence server de-referencing the location and 
embedding it into the PIDF, it's also possible for the Presence Server 
to pass the reference along to watchers, in a similar manner as CIPID.

This last alternative has some advantages and disadvantages. Advantages: 
Watchers will dereference the presentity's location at the time they 
need it. So they will always get the most current location of the 
presentity. Furthermore, if a watcher does not want to know the 
presentity's location, it won't dereference it, so we don't contaminate 
the access network with extra unneeded bits.

But then Hannes kindly reminded me that the presence server might have 
policy that depends on the presentity's location, so, just for policy 
reasons the presence server might need to dereference it.

I hope I can show some slides in Philly about these scenarios.

/Miguel

---

From: "Brian Rosen" <[email-masked]>
Date: Thu, 6 Mar 2008 14:38:42 -0500

I don't think that kind of indirect makes sense.  The whole idea of presence
was you get a NOTIFY when presence changes.  Location is presence
information; you get a NOTIFY when location changes.

You can ask for filters (don't tell me unless it changes by "this" much),
but I don't think presence should be seen of as a way to distribute URIs to
other information that itself is presence information.

We also believed that, in general, the LIS would only be allowed to supply
presence to the PS or the presentity. Then the user has ONE place to
instantiate watcher policy.  If there is this level of indirection, the LIS
has to have complex user watcher policy, as does the PS.

Brian

> Sent: Thursday, March 06, 2008 1:28 PM
> To: Brian Rosen
> >>> If it's case 2, then for an emergency call, we just send the
> reference,
> >> not
> >>> Where is the use case where some entity gets a reference, and has to
> do
> >> a