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

["Thomson, Martin" <Martin.Thomson at andrew.com>]

> why would you create a "Location"" header in SIP [...] ? 

So that we would have this debate.  It seems to have worked ;)

There were reasons for choosing "Location" that seemed valid.  I had no idea that it would cause so much confusion though.  It was never intended to be location specific (in a geopriv sense); the draft goes to great lengths to make this distinction.  But then, everyone just skims drafts, so I can see how easily we get confusion like this.

Since I updated the doc, I've been convinced that a message body is more appropriate than a header.

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

Presence agent is the term used by RFC 3903 and other presence documents.  It's the presence server (PS) in your terms.

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

Meaning we don't need a mechanism.  I'm not really interested so much in that use case.

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

Nothing preventing it, but as Paul notes, we need to be clear on what model we want.

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

We're not talking about location URIs, remember.

c.f. my upcoming response to Paul.

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

We haven't determined if there is a requirement or not.  I tend to think that there is no reason to prevent this, and there are cases where it might make sense to allow for it.
 
> >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.

It's currently a choice.  One that I'm tending away from right now, but it's still a valid choice.

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

Actually, if you read the draft, I discuss this briefly.  We can request that a server dereferences, but we can't force them.  After all, servers that don't support this feature will exist.

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

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

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