I saw Martin's note to the WG just after I sent this note to the
WG... bad timing, eh? ;-)
comments in-line below
At 02:54 AM 10/26/2009, Miguel A. Garcia wrote:
>James,
>
>Actually, Martin Thomson has been pushing and submitting this draft.
>We (the authors) do not agree with all the content in there, for
>which we had little time to react. So, please, take this document as
>a mechanism to generate discussion more than as the reflected
>consensus among the authors.
>
>Now, I will give you my personal thoughts below, which, as I said,
>might not match other authors'.
>
>
>On 26/10/2009 7:40, James M. Polk wrote:
>>Miguel
>>
>><I don't like sending message to 2 lists, but your ID crosses both the
>>old SIP and your targeted Geopriv WGs>
>>
>>I have concerns about your "Indirect Presence Publication with SIP" draft.
>>http://www.ietf.org/internet-drafts/draft-garcia-geopriv-indirect-publish-01.txt
>>
>>
>>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)?
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 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 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?
>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...
>If we don't agree with pursuing a general solution, then we should
>carefully look at the existing Geolocation header.
>
>>
>>Additionally, I was forced to change the Location: header to the
>>Geolocation: header due the SIP WG's conclusion it would be confused ,
I left how who would be confused -- the issue is RFC 2616 (HTTP) has
a "Location" header already, and that's why I had to change Location
Conveyance to a Geolocation header. I didn't like it, but have
gotten used to it.
>>therefore I do not believe you will be able to progress this forward for
>>that additional reason as a Location header-value.
>
>I agree with you, as I said, I don't even think the correct solution
>is to use a header at all. I think the chosen name "Location" is
>quite unfortunate due to historical reasons.
yes to the last part.
>/Miguel
>
>>
>>James
>>
>>BTW -- you use a really old reference for the Location Conveyance ID. It
>>is on the -01 version in SIPCORE now, about to be -02.
>>
>
>--
>Miguel A. Garcia
>+34-91-339-3608
>Ericsson Spain
_______________________________________________
Geopriv mailing list
Geopriv@ietf.org
https://www.ietf.org/mailman/listinfo/geopriv
