Re: [Geopriv] draft-garcia-geopriv-indirect-publish

["James M. Polk" <jmpolk at cisco.com>]

Martin

comments in-line

At 12:20 AM 10/29/2009, Thomson, Martin wrote:
> Hi James,
>
> > This to, can be added to SIP Location Conveyance (if the SIPCORE WG
> > agrees with this addition).
>
> Aside from a very strong desire to see the end of SIP location 
> conveyance, all the authors on this document are in strong agreement 
> that a location-specific solution is not desirable.

ok... I think I mention that this ought to be a more generic solution 
-- but then have to ask, if the authors believe this is to be a more 
generic solution, why would you create a "Location"" header in SIP 
(especially when Henning knows full well that we (SIP folks) can't 
name anything "Location:" because of the conflict with the HTTP 
header Location)?  This seems pretty Location specific to me, unless 
I'm misreading the text in the ID for another purpose of Location: 
(I'm thinking I didn't because this is all about dereferencing a 
location URI when sent to a PS by a presentity).


> > And when you reach consensus on the requirement to send a watcher the
> > location URI instead of a location value, that will need to be
> > indicated with further work.
>
> This is sensible.  I tend to agree that we want to have the presence 
> agent able to do the dereference.

"presence agent" here means presentity or PS?

If presentity, then the dereference occurs before the SIP PUBLISH is 
sent to the PS (meaning there is no indirect location publish).

If PS, then I don't see or know about anything preventing this from 
happening in the first place.

Miguel stated to me that there is no requirement to date for a PS to 
send a location URI presentity to a watcher. This means that there 
need only be a policy in all presence servers to dereference all 
location URIs when received in a PUBLISH, to give to watchers that 
are authorized to receive a presentity's location.

>  In many cases, the watcher wont be interested in doing this 
> themselves.  This is just one aspect we need to consider in the solution.

I'm wondering why this is considered at all, since there is no 
requirement to be able to send a watcher a location URI.  The 
solution is above.


> For instance, if we extend PIDF, a presence agent that doesn't 
> support the extension would pass the reference onward unaware of its 
> special status.

I'm not sure I understand how extending a PIDF is an answer, but I 
don't fully understand Miguel's desire for a new message body for 
this - in the first place. I see problems where this can be 
misunderstood and perhaps incorrectly used in other SIP methods to 
send a location URI, which could easily require support for multipart 
message bodies that not every UAS will support (because most don't today).

> That might be a desirable attribute of a solution.  Alternatively, 
> we could provide a different body.
>
> Miguel and I are currently debating options.  We're still trying to 
> come to a common understanding on this point.  About all we agree on 
> right now is that this reference will sit in the body of the SIP 
> PUBLISH and that it will not be location-specific.

ok, so there is not going to be a new SIP Location: header. That's very good.

I'm wondering why this has to be in a separate message body though.

One option I haven't heard (admitting I'm not part of the author team 
have these discussions) is why a general policy can't exist 
specifically to presence servers to dereference any location URI 
found in the Geolocation header of a SIP PUBLISH request to give to 
authorized watchers.  This is clearly the most straightforward 
solution - knowing there is no requirement for a presence server to 
send a location URI to the watcher. Once that new requirement is 
reached, I agree something new needs to be in the PUBLISH.

But this is for location only, and if you want a more generic 
solution for situations where URIs are sent to presence servers that 
are location URIs, then perhaps something else needs to be done.

> These are both reasons against using Geolocation, which is 
> unfortunate in a way because it has a lot of the semantics we're looking for.

For location (specific) URIs, I'm not seeing how a policy at the 
presence server doesn't satisfy the current use of the Geolocation header.


> Once we've sorted out the basics, maybe we can see how the 
> Geolocation header fits.

ok

> > As stated above, I believe you are wanting a default action for the
> > PS to dereference
>
> Actually, as Miguel says, the options are still largely open.  But I 
> certainly think that having the presence agent able to dereference 
> is a desirable feature.  This might be: always dereference, 
> dereference based on presence agent policy, dereference at the 
> request of the presentity, or a combination of these.

sounds about right

James


> --Martin
>
> >
> > James
> >
> >
> >
> >
> > >/Miguel
> > >
> > >--
> > >Miguel A. Garcia
> > >+34-91-339-3608
> > >Ericsson Spain
> >