>Please only make further enhancements to location conveyance after
>seeking endorsement of the sipcore list.
fair -- I was just imagining how it could be done, not that I was
going to do this.
I'm more concerned about a newly proposed SIP header that recreates
at least part of what the SIP Geolocation header can do.
>Primarily we need to concentrate on getting out what we have.
I agree.
James
>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
