RE: Allowing sip: in location header not good

At 06:25 PM 7/20/2006 -0400, Brian Rosen wrote:
>Dueling authors.  Pistols at 40 paces?  Have you a second?
>
>Remind me what the religious argument against pull is?

Jon Peterson had the strongest opinion on the list, but there were several 
opinions at the Paris meeting, including Rohan (especially brutal about 
this point) and Dean.

Most seemed to hang on the idea that our doc is all about "conveying" - 
which means giving or showing something else what I have.

SUB and NOT have to do with me receiving what your location is, which is 
not conveying, by definition.

Before Paris, our doc (dear co-author  :-) discussed both conveying and 
receiving location.  I can't remember who from the SIMPLE WG got on me for 
trying to have SUB/NOT or PUBLISH in our ID.


>I'm conveying location by reference using an IETF procedure designed
>expressly to convey location: presence.

I think if you looked at this, you'd likely see that I push my presence 
location up to a compositor server, and others subscribe to that server to 
learn my presence.  Those others are pulling my location from the compositor.

>Whether I get one NOTIFY or
>multiple ones can't possibly matter to the sip protocol, the Location
>header, the security considerations or anything else I can think of.

...except the pov of the document (being about conveying).


>Look at it this way: suppose I were to say if you use sip/sips, you MUST set
>Expiry to zero.

Then, I think, the Geopriv folks will say that LoST cannot then take that 
location (in or out of a PIDF-LO) and send it to a LoST server - because it 
was distributed after the <retransmission-allowed> flag was set to "no"....

>That's plain and simple location by reference.

I completely understand the idea, but I think we may have unearthed another 
problem in the last 24 hours.

If the INVITE has a PIDF-LO with this element

         <retransmission-allowed>no</retransmission-allowed>

Can a ESRP (emergency services routing proxy that does the LoST query for 
the PSAP URI) send location anywhere?  Geopriv might say no, because it 
violates one of its "priv" rules. Now what? Do we make an exception?  We 
have to get their buy-in for this. We don't have it yet.

>You get a
>URI, you send it using a defined protocol to a server, it sends you a PIDF.

..-LO

>If you buy that, what in the document prevents me from allowing any value I
>want in Expiry?

The <retransmission-allowed> is a binary value: yes or no, not a hop-count 
field... this may have us in a pickle in this use case, even if most don't 
believe it's a problem.

At the end of the day, I think we should have

         allowed-scheme = 'cid' / 'http' / 'https' / 'pres'

                 (and I'm not so sure about 'pres')

until the location-retreavel ID is written that extends this document 
(which will define how to SUBSCRIBE/NOTIFY and PUBLISH location).

I'm fine with defining the additional sematics surrounding how to use HTTP 
and HTTPS (i.e. with request type and so on), as I consider that part of 
the dereferencing part of conveyance.

That said, once you have SUBSCRIBE, you have tracking with multiple 
NOTIFYs, and that's an event package that isn't proposed yet, because it 
needs to have a timing interval and a trigger on what is considered a 
move.  This would be a more general use-case that Rohan's movement trigger 
event package ID.


>Brian
>
>
>
> > -----Original Message-----
> > From: James M. Polk [mailto:[email protected]]
> > Sent: Thursday, July 20, 2006 5:59 PM
> > To: Brian Rosen; 'Thomson, Martin'; [email protected]
> > Subject: RE: [Sip] Allowing sip: in location header not good
> >
> > At 12:19 PM 7/20/2006 -0400, Brian Rosen wrote:
> > >There is a point to limiting what can be sent in the Location header to
> > >specific protocols which has received adequate review in both sip and
> > >geopriv.
> > >
> > >So, here is my concrete proposal:
> > >Location       = "Location" HCOLON location-param *(COMMA location-param)
> > >location-param = LAQUOT allowed-scheme HCOLON ":" ( hier-part / opaque-
> > part
> > >) RAQUOT *( SEMI loc-param ) ; hier-part and opaque-part from 3261
> > >allowed-scheme = 'cid' / 'http' / 'https' / 'sip' / 'sips' / 'prez'
> > >loc-param      = 'location-dereference-protocol=' deref-protocol /
> > >generic-param
> > >deref-protocol = token
> >
> > I'm still not a fan of using 'sip' here. 'sip' or 'sips' means using
> > SUBSCRIBE and that's a PULL mechanism in this scenario; i.e. the UAC
> > that's
> > subscribing to another SIP element is not using its location to do
> > anything
> > (that will come back in the NOTIFY).  The UAC (in the SUB transaction) in
> > this scenario is PULLING another UA's location from somewhere, and that's
> > not "Location Conveyance" - which is what I got hammered on in the Paris
> > meeting.
> >
> > Clear consensus from that meeting was that this document describes PUSHING
> > my UAC's location to somewhere else.
> >
> > Using HTTP(S) to fetch (presumably with a GET request) my
> > location-by-reference once from a server is not a pull, it is a
> > Content-Indirection operation, which is a fake of a PUSH, IMO.
> >
> > Using a SUBSCRIBE, you are always receiving something in the NOTIFY.  If
> > "location" is what's returned in that NOTIFY, this is a "Location
> > Retreaval" PULL, and against what the Paris meeting said to do, and is for
> > another document, a PULL mechanism document that hasn't been written yet.
> >
> > Therefore, I recommend we remove sip: and sips: from the BNF above.  I'm
> > still thinking about what to do about the 'pres' proposal.
> >
> > Adam's scenario (on the mike in Montreal) about using SUBSCRIBE to a
> > weather service did not have Adam's location coming back in the NOTIFY, so
> > that use-case doesn't apply to this discussion (but is a great use-case!)
> >
> > comments
> >
> > James

_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use [email protected] for questions on current sip
Use [email protected] for new developments on the application of sip