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".
>
> 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.
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.
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 ,
> 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.
/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
