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

This is something that will need to be dealt with somehow.  After all, if we're talking location, then it does change.

That's actually a motivation for doing this: the presentity/publisher doesn't want to deal with changing values and having to continually publish.  For one, it might be pointless because none of their watchers are even interested in the updates.

The "dereference" operation could be something quite sophisticated, like a presence subscription.  That's all up to the presence server.  It has a number of options:

 - Dereference on publish, which equivalent in many respects to having the presentity do the dereference, so this adds little value

 - Dereference on update, where the information is retrieved each time a watcher subscribes

 - Dereference based on information in the retrieved presence data, such as expiry times or timestamps

 - Dereference periodically, where the time is based on local policy or based on the intervals provided by watchers

 - Dereference more intelligently by considering event-rate controls from watchers, the filters that they provide and consolidate all these into the one subscription (assuming that this is possible, say the reference is a pres: URI) or either attempt to poll in an optimum way to meet these targets

Obviously, there are quite a number of ways this could be done.  Obviously, the options that are more efficient and provide a better view of the presence state to watchers are more difficult to implement.

I'm happy to let the presence server decide on what to do, but we should probably have some sort of discussion in the draft that describes the choices that are available and some of the implications of each.  That should be sufficient.  

Giving the presentity/publisher or watcher a means to control this doesn't seem helpful - for the watcher, they can use subscription event rate control and filters to influence the server, but it's up to the presence server implementation and policy how those are acted upon.

--Martin

> -----Original Message-----
> From: Paul Kyzivat [mailto:pkyzivat@cisco.com]
> Sent: Friday, 30 October 2009 11:03 AM
> To: Thomson, Martin
> Cc: James M. Polk; Miguel A. Garcia; geopriv@ietf.org; sipcore@ietf.org
> Subject: Re: [sipcore] draft-garcia-geopriv-indirect-publish
> 
> Martin,
> 
> I pretty much agree.
> There may be other considerations if the deref'ed answer varies with
> time. If the server always derefs, then for the watcher to get a new
> value it must query the server again. If the watcher gets a reference
> frmo the server, then it can query the source.
> 
> Is that a useful distinction? Probably not, and least not often.
> The work of doing so will probably not be that different for the
> watcher, except it may get back more data than it wants.
> 
> In the interest of simplicity, I think the distinction can be ignored.
> 
> 	Thanks,
> 	Paul
> 
> Thomson, Martin wrote:
> > 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@cisco.com]
> >> Sent: Friday, 30 October 2009 12:33 AM
> >> To: Thomson, Martin
> >> Cc: James M. Polk; Miguel A. Garcia; geopriv@ietf.org;
> sipcore@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@ietf.org
> >>> https://www.ietf.org/mailman/listinfo/sipcore
> >>>
> >