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

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

Hi Paul,

That's an excellent summary of the stakeholders.

                 Source
                    |  \
                   ?|    \ ?
                    |      \
  Publisher/ --- Server --- Watcher
  Presentity      (PA)

Assuming that the publisher wants to do the dereference (and they are able to [1]), we have nothing further to do.  We don't need to build a mechanism.  The publisher can implement this policy as they see fit.

So, the presentity publishes a reference to the presence server.

The pertinent questions are:

 (A) does the presentity have any say in where the reference is resolved?

 (B) does the watcher have any say in where the reference is resolved?

Any preference for (A) is expressed in a PUBLISH and that any preference for (B) is expressed in a SUBSCRIBE (most probably).  Obviously, the server has the final say: it can choose to pass the reference on - forcing the watcher to dereference - or it can do the dereference itself.

So, why would the publisher ask the server to dereference?  Maybe it knows something of the watchers, or maybe it wants to protect the reference (c.f. location URIs and the possession model).  That second reason is a good reason to have a means to fail the publish if the server is unwilling or unable.  The Require header I proposed does this, but there might be other ways to achieve the same effect.

So why would the watcher ask the server to dereference?  The simplest reason is: it doesn't want to do the work itself.

Why would the server not want to dereference?  The idea that it doesn't want the extra work doesn't really fit with it being a presence server.  After all, a large part of its reason for being is to offload work from watcher and publisher.

So, all this more or less leads me to think that having the server dereference is the most sensible option.  Obviously, server policy can override this or the server might be unable to dereference.

I do think that it might make sense to have an option where the server failing to dereference doesn't prevent the watcher from attempting to do so.  If the server doesn't support the feature, the server decides not dereference, or the server encounters an error while trying, ... then the reference is passed on the watcher.  

That leads me to conclude that there is no benefit in having the watcher request that a reference is resolved.  If the watcher receives a reference, it knows that there's nothing it could have done to have this dereferenced for it.

Cheers,
--Martin

[1] This isn't always the case: <http://tools.ietf.org/html/draft-ietf-ecrit-rough-loc>, though for many presence use cases I doubt it will be a factor.

> -----Original Message-----
> From: Paul Kyzivat [mailto:pkyzivat at cisco.com]
> Sent: Friday, 30 October 2009 12:33 AM
> To: Thomson, Martin
> Cc: James M. Polk; Miguel A. Garcia; geopriv at ietf.org; sipcore at ietf.org
> Subject: Re: [sipcore] draft-garcia-geopriv-indirect-publish
> 
> 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
> >