comments in-line
At 04:06 AM 10/27/2009, Miguel A. Garcia wrote:
>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.
watchers SUBSCRIBE to a PS to get presentity state information, right?
If true, then the NOTIFY can carry the Geolocation header-value with
a location URI as the answer to the watcher for (geographically)
where the presentity is - provided it has been authorized to receive
such information. This isn't hard.
This to, can be added to SIP Location Conveyance (if the SIPCORE WG
agrees with this addition).
>>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.
it seems - since you do not have requirements to send the watcher a
location URI for a presentity's location that the PS dereferencing
will always happen. If true, then this appears to me to be a fixed
policy - for the time being (i.e., until something else tells the PS
to do something different) - to *always* dereference any location URI
it receives from a presentity in a PUBLISH. To me, the PS doesn't
need to be told to do anything, since only one action can occur
(i.e., to dereference).
If you agree with the above, why do you need a flag telling the PS to
do anything other than a default action (i.e., to dereference the
location URI) and send the location value to authorized watchers?
It feels like you are forcing this to be an explicit instruction
instead of a default implicit action to always be done until told to
do something else (like send a location URI - which could require a
flag at some future date).
Why not have the following rule cover what you want
the recommended policy be to dereference any location URI
received in a Geolocation header-value (in a PUBLISH) from
a presentity, to give to authorized watchers.
This seems to cover what you want.
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.
>>>So, if we agree to pursue a general solution for publication of
>>>presence information by reference, then I find difficult to think of a
>>>solution based on a new or existing SIP header. Instead, we should be
>>>looking at the XML body, either to an extension to the existing one or
>>>a new XML body that.
>>
>>You're proposing have this indication solely in a message body?
>>
>>This appears to me to be overkill just to get a flag from a PA to a PS.
>>
>>I could be wrong though...
>
>Well, at the moment all solution spaces are open. If we want to make
>something general enough, it cannot be done at the SIP level, so we
>should be looking at ways to do it at the XML level. Using and XML
>diff document (XML Patch operations) might be a way to move forward.
>We are currently investigating this track.
As stated above, I believe you are wanting a default action for the
PS to dereference location URIs to provide location values to
watchers, without a choice in the matter (of giving out a location
URI to a watcher instead). This seems like a policy choice that can
be stated as a recommendation or a should (both 2119 strength) in an
existing document, until you determine the time has come for the
requirement to send a watcher the location URI instead of a value.
James
>/Miguel
>
>--
>Miguel A. Garcia
>+34-91-339-3608
>Ericsson Spain
_______________________________________________
Geopriv mailing list
Geopriv@ietf.org
https://www.ietf.org/mailman/listinfo/geopriv
