Primarily we need to concentrate on getting out what we have.
regards
Keith
> -----Original Message-----
> From: geopriv-bounces@ietf.org
> [mailto:geopriv-bounces@ietf.org] On Behalf Of James M. Polk
> Sent: Monday, October 26, 2009 5:49 PM
> To: Brian Rosen; Miguel Garcia; Thomson, Martin
> Cc: geopriv@ietf.org; sipcore@ietf.org
> Subject: Re: [Geopriv] [sipcore] draft-garcia-geopriv-indirect-publish
>
> At 08:43 AM 10/26/2009, Brian Rosen wrote:
> >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-indir
> ect-publish-01.
> > >> txt
> > >>
> > >>
> > >> Currently, and pretty much since whatever version of
> > >>
> >
> http://www.ietf.org/internet-drafts/draft-ietf-sipcore-location-convey
> > ance-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
>
_______________________________________________
Geopriv mailing list
Geopriv@ietf.org
https://www.ietf.org/mailman/listinfo/geopriv
