>I agree that we need a generalized way to indicate indirect presence
>publish, and would not want to see a specialized mechanism for location.
>
>I do think we could add a parameter to Geolocation which was instructions to
>the presence server to fetch the location and include it in the presence
>notifications, which would be much better than a new header just for that,
>but a generalized indirect publish would be better IMO.
yeah -- I can add a Geolocation header parameter that is only valid
in PUBLISH to have the PS dereference the location URI and only send
values to watchers.
That said -- I'm wondering if this is such a general purpose
mechanism in which the PA will always know the watcher needs to get a
location value? I can imagine a policy in the PS determining whether
the watcher gets a location URI or a value, perhaps based on who the
watcher is.
Therefore, unless corrected, I'm more inclined to make this
indication (from PA to PS) up to the local policy within the PS as to
whether it wants to do this function, or pass on the location URI.
Is this agreeable?
That said - my other note on this questions whether this ought to go
in every different way a reference is sent from a PA to PS (i.e.,
extending each way a reference is done). Location Conveyance is
really easy because this is still an ID, but other specs are more concrete.
James
>Brian
>
>
>On 10/26/09 3:54 AM, "Miguel Garcia" <Miguel.A.Garcia@ericsson.com> 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".
> >
> >>
> >> 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.
> >>
> >>
_______________________________________________
Geopriv mailing list
Geopriv@ietf.org
https://www.ietf.org/mailman/listinfo/geopriv
