Subject: [sipcore] Does SIP Presence imply Geolocation?

From: Brian Rosen <[email-masked]>
Date: Fri, 13 Nov 2009 16:27:43 -0500

In geopriv, there is a discussion of using Geolocation in the NOTIFY from
the presence event package.  James Polk thinks that in a presence NOTIFY, if
the presence PIDF includes a PIDF-LO, then the NOTIFY MUST have a
Geolocation header, with a cid pointing to the PIDF that comes as a result
of the presence event package.

I suggest that this is not correct, and that I think attempts to combine
presence and geolocation would actually require TWO PIDFs, one for the
presence event package response and the other for the Geolocation header.  I
don't think combining them makes much sense, but if you did, I think you
would need two bodies and multipart.  James doesn't agree and thinks the
presence event return and the cid on the Geolocation header would be the
same mime part.

James asserts that ANY use of SIP with location requires Geolocation.  I do
not agree and claim presence is an independent use of SIP, with its own
mechanisms.

We would like sipcore's opinion of this.

Brian

---

From: "Sanjay Sinha (sanjsinh)" <[email-masked]>
Date: Sun, 15 Nov 2009 22:16:39 -0600

I think Geolocation is part of rich presence information. In fact, there
is a location element in RPID RFC 4480, and I think geolocation as
adding more information to it in terms of civic location etc.

Hence I also agree with James view that it should be in the same body as
PIDF.

Sanjay 

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On
> Behalf Of Brian Rosen
> Sent: Saturday, November 14, 2009 2:58 AM
> To: [email-masked]
> Subject: [sipcore] Does SIP Presence imply Geolocation?
> 
> _______________________________________________
> sipcore mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/sipcore

---

From: "Tschofenig, Hannes (NSN - FI/Espoo)" <[email-masked]>
Date: Mon, 16 Nov 2009 09:02:42 +0200

Hi Brian,  

>In geopriv, there is a discussion of using Geolocation in the 
>NOTIFY from the presence event package.  James Polk thinks 
>that in a presence NOTIFY, if the presence PIDF includes a 
>PIDF-LO, then the NOTIFY MUST have a Geolocation header, with 
>a cid pointing to the PIDF that comes as a result of the 
>presence event package.

If you extend this idea beyond location then with every extension one
would have to define a new header field that indicates what extension is
in the PIDF.  

This clearly does not seem to be desirable. 

>I suggest that this is not correct, and that I think attempts 
>to combine presence and geolocation would actually require TWO 
>PIDFs, one for the presence event package response and the 
>other for the Geolocation header.  I don't think combining 
>them makes much sense, but if you did, I think you would need 
>two bodies and multipart.  James doesn't agree and thinks the 
>presence event return and the cid on the Geolocation header 
>would be the same mime part.

Combining presence and geolocation makes a lot of sense. Wasn't this the
core idea of reusing PIDF in the first place? See
http://www.ietf.org/rfc/rfc4079.txt

Why would one need two PIDFs? Why wouldn't you just put the location and
presence information in a single PIDF?

>
>James asserts that ANY use of SIP with location requires 
>Geolocation.  I do not agree and claim presence is an 
>independent use of SIP, with its own mechanisms.

I agree with you here. 

>We would like sipcore's opinion of this.

Ciao
Hannes

---

From: Brian Rosen <[email-masked]>
Date: Mon, 16 Nov 2009 09:48:36 -0500

Just speculate that someone wanted to put a Geolocation header on the NOTIFY
from a presence subscription.

I'm not sure why you would want to do that, but let's say you did.

Would you then expect there to be one PIDF or two?

Would you expect that the location in the Geolocation header was always that
of the presentity?

I think if you combine Geolocation and the presence NOTIFY, that the uses
are totally independent.  You make no assumptions on the connection between
the Geolocation header target and the presentity.

Brian

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 16 Nov 2009 10:02:47 -0500

Brian,

> Would you then expect there to be one PIDF or two?

This is an interesting case. It is the first that exhibits a possibility 
I had considered when we were discussing the body handling draft - that 
one body part can serve two purposes.

On one hand, the body of the notify is satisfying the subscribe request.
OTOH, the body of the notify can be referenced from a Geolocation header.

That would be the case if indeed you *wanted* the same body part for 
both. If not, then you you would need two body parts - one with C-D of 
'render' for the NOTIFY content, and another, with C-D by-reference for 
the Geolocation.

	Paul

---

From: Brian Rosen <[email-masked]>
Date: Mon, 16 Nov 2009 10:16:29 -0500

Yeah, I guess I would agree that if you WANTED them to be the same, there
isn't any reason to force two body parts.

This is strictly up to the notifier: there isn't any way to ask for that.

Again, this seems to me to be a very weird and rare case: normally, there
would be no reason to have a Geolocation header on a Presence NOTIFY.

I gather you agree with me that Presence NOTIFY with PIDF-LO doesn't require
a Geolocation header as James would assert.

Brian

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 16 Nov 2009 10:29:19 -0500

> This is strictly up to the notifier: there isn't any way to ask for that.

Right. This is effectively an optional optimization on the part of the 
notifier.

> would be no reason to have a Geolocation header on a Presence NOTIFY.

The question of when it would be appropriate to put a geolocation header 
in a presence notify at all, and especially referencing the presence 
body of the notify, is interesting. IIUC, doing so would assert that the 
location there is the location of *notifier*, not the presentity. Right? 
So sharing the body would only work if the notifier and the presentity 
are one and the same, or at least geographically collocated.

> a Geolocation header as James would assert.

I haven't been following the discussion closely.
But the presence notify and the geolocation header have distinct 
purposes, so it should be possible to use them separately or together,
and if together, referencing the same body part or different body parts.

	Thanks,
	Paul

---

From: "DRAGE, Keith (Keith)" <[email-masked]>
Date: Mon, 16 Nov 2009 16:53:27 +0100

Let's look at it from different direction.

Does the location form part of the presence information or not.

If the location forms part of the information being provided for presence, then it belongs in the presence information, i.e. in the presence event package.

If the location provision and usage is intended to be orthogonal to presence, then a Geolocation header should be provided. 

I agree in a NOTIFY for presence, it is likely to be presence related.

regards

Keith

> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Paul Kyzivat
> Sent: Monday, November 16, 2009 3:29 PM
> To: Brian Rosen
> Cc: [email-masked]
> Subject: Re: [sipcore] Does SIP Presence imply Geolocation?
> 
> 
> 
> Brian Rosen wrote:
> > Yeah, I guess I would agree that if you WANTED them to be the same, 
> > there isn't any reason to force two body parts.
> > 
> Right. This is effectively an optional optimization on the 
> part of the notifier.
> 
> > Again, this seems to me to be a very weird and rare case: normally, 
> > there would be no reason to have a Geolocation header on a 
> Presence NOTIFY.
> 
> The question of when it would be appropriate to put a 
> geolocation header in a presence notify at all, and 
> especially referencing the presence body of the notify, is 
> interesting. IIUC, doing so would assert that the location 
> there is the location of *notifier*, not the presentity. Right? 
> So sharing the body would only work if the notifier and the 
> presentity are one and the same, or at least geographically 
> collocated.
> 
> > I gather you agree with me that Presence NOTIFY with 
> PIDF-LO doesn't 
> > require a Geolocation header as James would assert.
> 
> But the presence notify and the geolocation header have 
> distinct purposes, so it should be possible to use them 
> separately or together, and if together, referencing the same 
> body part or different body parts.
> 
> 	Thanks,
> 	Paul
> 
> > Brian
> > 
> > 
> >>> Just speculate that someone wanted to put a Geolocation header on 
> >>> the NOTIFY from a presence subscription.
> >>>
> >> This is an interesting case. It is the first that exhibits a 
> >> possibility I had considered when we were discussing the body 
> >> handling draft - that one body part can serve two purposes.
> >>
> >> both. If not, then you you would need two body parts - one 
> with C-D 
> >> of 'render' for the NOTIFY content, and another, with C-D 
> >> by-reference for the Geolocation.
> >>
> >> Paul
> >>
> >>> Would you expect that the location in the Geolocation header was 
> >>> always that of the presentity?
> >>>
> >>> I think if you combine Geolocation and the presence 
> NOTIFY, that the 
> >>> uses are totally independent.  You make no assumptions on the 
> >>> connection between the Geolocation header target and the 
> presentity.
> >>>
> >>> Brian
> >>>
> >>>
> >>>
> >>>>> NOTIFY from the presence event package.  James Polk 
> thinks that in 
> >>>>> a presence NOTIFY, if the presence PIDF includes a 
> PIDF-LO, then 
> >>>>> the NOTIFY MUST have a Geolocation header, with a cid 
> pointing to 
> >>>>> the PIDF that comes as a result of the presence event package.
> >>>> If you extend this idea beyond location then with every 
> extension 
> >>>> one would have to define a new header field that indicates what 
> >>>> extension is in the PIDF.
> >>>>
> >>>>> I suggest that this is not correct, and that I think 
> attempts to 
> >>>>> combine presence and geolocation would actually require 
> TWO PIDFs, 
> >>>>> one for the presence event package response and the 
> other for the 
> >>>>> Geolocation header.  I don't think combining them makes much 
> >>>>> sense, but if you did, I think you would need two bodies and 
> >>>>> multipart.  James doesn't agree and thinks the presence event 
> >>>>> return and the cid on the Geolocation header would be the same 
> >>>>> mime part.
> >>>> Combining presence and geolocation makes a lot of sense. Wasn't 
> >>>> this the core idea of reusing PIDF in the first place? See 
> >>>> Why would one need two PIDFs? Why wouldn't you just put the 
> >>>> location and presence information in a single PIDF?
> >>>>

---

From: Brian Rosen <[email-masked]>
Date: Mon, 16 Nov 2009 11:14:06 -0500

I don't think that works.

If I use Geolocation to pass you a location URI which is a SIP URI, then to
dereference that, you need to subscribe to Presence to get the PIDF.  That
isn't directly related to presence.

Brian

On 11/16/09 10:53 AM, "DRAGE, Keith (Keith)" <[email-masked]>
wrote:

> If the location forms part of the information being provided for presence,
> then it belongs in the presence information, i.e. in the presence event
> package.
> 
> If the location provision and usage is intended to be orthogonal to presence,
> then a Geolocation header should be provided.
>

---

From: "James M. Polk" <[email-masked]>
Date: Mon, 16 Nov 2009 12:28:41 -0600

>would have to define a new header field that indicates what extension is

I don't really think that's the case, not unless there were already a 
document defining how to use presence event package in that way

>This clearly does not seem to be desirable.

this wouldn't make sense, but SIP Location Conveyance has called out 
using the Geolocation header value in a NOTIFY within a dereference 
transaction for a number of years *and* has mandated using the 
presence event package for each of these years to accomplish this. 
Brian admitted to me the dereference transaction is the primary 
purpose of the loc-filters draft (which doesn't include the 
Geolocation header value).

---

From: Peter Saint-Andre <[email-masked]>
Date: Tue, 17 Nov 2009 11:03:27 -0700

On 11/16/09 12:02 AM, Tschofenig, Hannes (NSN - FI/Espoo) wrote:

> Combining presence and geolocation makes a lot of sense. 

I'm not so sure. :) FWIW, in the XMPP community we actively discourage
people from including "rich presence" information in presence updates,
because we see that as overloading of core data about availability for
communication. We concluded that it is inappropriate for me to receive a
presence update when a new song starts on your music player, you walk 3
meters to the north, etc., because I might not care about what tune
you're listening to, you might not want me to know your location, etc.
And in general presence is already a very chatty technology without
introducing a lot more triggers for presence updates. Yes, techniques
like composition and filtering are essentially another way to work
around the problem (I'm not saying that the XMPP approach is the one
true path to presence!). However, no matter how you slice it there are
always challenges involved in adding presence and "rich presence" together.

My two cents...

Peter

-- 
Peter Saint-Andre
https://stpeter.im/

---

From: "Thomson, Martin" <[email-masked]>
Date: Tue, 24 Nov 2009 10:47:39 +0800

(Not wanting to invoke the necromantic arts, but this warranted clarification.)

> IIUC, doing so would assert that the

The presentity identifier in the referenced PIDF-LO document would identify the subject.  We discussed this at some length in Stockholm (privately) and there was a general view that we wouldn't be specifying any relationship to the entities in SIP signalling.

I know, that's a bit weak, but that's largely intentional.  Brian and James were both involved, so they may provide further clarification.

Cheers,
--Martin

(For the record, I side with Brian's interpretation.)

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 24 Nov 2009 09:07:34 -0500

> I know, that's a bit weak, but that's largely intentional.  Brian and James were both involved, so they may provide further clarification.

I'm sure you guys are more informed of this than I am, so I will defer.

But if the geolocation header simply says: "here is a location - who its 
the location *of* is included in the location body", rather than "here 
is the location of the sender of this message", then what is a proxy 
that want to route by location (say for 911) to do if the identity of 
the presentity in the location info doesn't match that of the caller? 
Should it ignore it for routing purposes?

(That of course isn't relevant to the case where this came up. A 
geolocation in a presence notify couldn't be used to route the request, 
since it is in-dialog.)