Hi James,
some inline comments.
On 26/10/2009 18:41, James M. Polk wrote:
Currently, and pretty much since whatever version of
http://www.ietf.org/internet-drafts/draft-ietf-sipcore-location-conveyance-01.txt
has existed in whatever WG it happened to reside in at the time,
Location Conveyance using SIP has included the use of PUBLISH to convey
location as a message body, or as a location URI since about, or before
2005. I fail to see or read what you want in your doc that cannot be
covered in SIP Location Conveyance.
I understand that the Geolocation header has quite a few similarities
with what is proposed in the draft. I don't think the Geolocation
header has means to indicate the presence server "you should
de-reference the location and insert it in a presence document to be
offered to watchers".
hmmm... it's this a policy choice between the presentity and the
presence server (i.e., what to have the PS pass on as a reference, and
what the PS dereferences to pass on only as a value)? How can't that be
a policy between the PA and PS (including which references to leave as
references, and which are dereferenced and sent by the PS as a value)?
At the moment the draft is not ambitious to have the PS passing the
reference to the watcher. This might be something to look at it a
bit later, but so far, the only ambition is that the PS
de-references the location and adds it to the PIDF that is offered to watchers.
In that sense, this mechanism (policy notification of which URIs it
receives from the PA need to be dereferenced) ought to be general, and
not limited to location. I can see one argument being "the PA should
include with the URI reference whether or not to do this deference", but
that can lead to mistakes - as then each URI the PS receives has to look
for the indication -- which is always an extension to how the URI is
sent to the PS in the first place. That's clumbersome IMO.
Therefore, IMO, this shouldn't be
- a new SIP header
- with or without a new option-tag
- an indication to each way a PS receives a URI
but, rather, more general.
The issue that has to be watched out for is when 2 or more URIs get sent
to the PS and only a subset needs this dereference treatment.
I think I concur with you, except the level of ambition, as I said before.
I cannot figure out how you claim usage of the Geolocation is too
limiting.
I have several criticism to the use of a SIP header to convey this
information. Indirect location is just a particular case of a general
solution, which is, a presentity wants to publish some information by
reference not by value. Location is the more straight forward example,
but we should try to find a general solution.
I'm not really understanding this example. If a PA wants to have a
watcher get a URI, then the PA sends a URI to the PS. If the PA wants to
have the watcher get a value, the PA sends a value to the PS *or* the PA
sends a URI to the PS and the PS dereferences the URI to be able to send
a value to a watcher.
To me this is a function the PS knows to do when it receives certain
URIs (i.e., reference types). Receiving a Location URI could be one such
situation.
I agree with your analysis.
I wonder if there is another issue -- shouldn't the PS determine when to
send the reference vs. a value mostly based on who is asking for the
information?
This is discussed before, we are building from the ground, and the
first step is to make the PS to dereference the location URI.
Passing the URI is something for which don't have requirements at
the moment, so will analyze whether is worth doing it once we have
solved our main problem.
