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