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.
>
>
>> 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.
/Miguel
--
Miguel A. Garcia
+34-91-339-3608
Ericsson Spain
_______________________________________________
Geopriv mailing list
Geopriv@ietf.org
https://www.ietf.org/mailman/listinfo/geopriv
