Re: [Geopriv] [sipcore] draft-garcia-geopriv-indirect-publish

["DRAGE, Keith (Keith)" <drage at alcatel-lucent.com>]

Please only make further enhancements to location conveyance after seeking endorsement of the sipcore list.

Primarily we need to concentrate on getting out what we have.

regards

Keith 

> -----Original Message-----
> From: geopriv-bounces at ietf.org 
> [mailto:geopriv-bounces at 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 at ietf.org; sipcore at 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 at 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 at ietf.org
> https://www.ietf.org/mailman/listinfo/geopriv
>