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

[Paul Kyzivat <pkyzivat at cisco.com>]

I agree that this is something where a general solution would be preferable.

There are a number of parties involved in this:
- the publisher
- the presence server
- the watcher
- the true source of the information

(Some of the above may be collocated.)

If there is a deref to be done, it can potentially be done in any of 
those places, except the source. The *policy* about where it should be 
done might also be set in any of those places. And there are competing 
interests about that. For instance:

- the source wants to minimize derefs. Depending on the particular
  data and the typical access patterns for that data, choosing a
  particular one of the other parties to do the deref may minimize
  the number of derefs. (But probably the source has too little info
  about the usage to make the choice even if it could.)

- the publisher, if it isn't collocated with the source, may want
  to delegate the deref to save itself work.

- the presence server may also want to delegate the deref to either
  the publisher or the watcher to save itself work. But in other
  cases its role in life is to offload the publisher and the watcher,
  so it might be willing to take on the work.

- the watcher also may want to delegate this work to one of the
  other parties to offload itself. But in other cases it may *want*
  the opportunity to do the deref itself so that it can get more
  timely values than it would otherwise.

So, I think  general solution is going to require some sort of 
negotiation between all the parties about who assumes this 
responsibility. Seems like an interesting and non-trivial problem.

	Thanks,
	Paul

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.
>
> > 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.  In many cases, the watcher wont be interested in doing this themselves.  This is just one aspect we need to consider in the solution.
>
> 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.  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.  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.
>
> Once we've sorted out the basics, maybe we can see how the Geolocation header fits.
>  
> > 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.
>
> --Martin
>
> > James
> >
> >
> >
> >
> > > /Miguel
> > >
> > > --
> > > Miguel A. Garcia
> > > +34-91-339-3608
> > > Ericsson Spain
>
> _______________________________________________
> sipcore mailing list
> sipcore at ietf.org
> https://www.ietf.org/mailman/listinfo/sipcore