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

["James M. Polk" <jmpolk at cisco.com>]

Miguel

I saw Martin's note to the WG just after I sent this note to the 
WG... bad timing, eh?  ;-)

comments in-line below

At 02:54 AM 10/26/2009, Miguel A. Garcia 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".

hmmm... it's this a policy choice between the presentity and the 
presence server (i.e., what to have the PS pass on as a reference, 
and what the PS dereferences to pass on only as a value)?  How can't 
that be a policy between the PA and PS (including which references to 
leave as references, and which are dereferenced and sent by the PS as 
a value)?

In that sense, this mechanism (policy notification of which URIs it 
receives from the PA need to be dereferenced) ought to be general, 
and not limited to location. I can see one argument being "the PA 
should include with the URI reference whether or not to do this 
deference", but that can lead to mistakes - as then each URI the PS 
receives has to look for the indication -- which is always an 
extension to how the URI is sent to the PS in the first 
place.  That's clumbersome IMO.

Therefore, IMO, this shouldn't be

- a new SIP header
- with or without a new option-tag
- an indication to each way a PS receives a URI

but, rather, more general.

The issue that has to be watched out for is when 2 or more URIs get 
sent to the PS and only a subset needs this dereference treatment.



> > 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.

I'm not really understanding this example. If a PA wants to have a 
watcher get a URI, then the PA sends a URI to the PS.  If the PA 
wants to have the watcher get a value, the PA sends a value to the PS 
*or* the PA sends a URI to the PS and the PS dereferences the URI to 
be able to send a value to a watcher.

To me this is a function the PS knows to do when it receives certain 
URIs (i.e., reference types).  Receiving a Location URI could be one 
such situation.

I wonder if there is another issue -- shouldn't the PS determine when 
to send the reference vs. a value mostly based on who is asking for 
the information?


> 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.

You're proposing have this indication solely in a message body?

This appears to me to be overkill just to get a flag from a PA to a PS.

I could be wrong though...


> 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 ,

I left how who would be confused -- the issue is RFC 2616 (HTTP) has 
a "Location" header already, and that's why I had to change Location 
Conveyance to a Geolocation header.  I didn't like it, but have 
gotten used to it.

> > 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.

yes to the last part.


> /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