Subject: [Sip] Allowing sip: (or prez:) in the location header

From: "Brian Rosen" <[email-masked]>
Date: Wed, 19 Jul 2006 18:45:38 -0400

Suppose we allowed sip: or prez: as the location header URI.  The resolution
of this scheme would be "subscribe to presence".

Note that if you asked for immediate expiration (0), you will get the
immediate NOTIFY.  This constitutes one reasonable way to provide
location-by-reference.  It is a form of "pull" (you send a SUBSCRIBE, you
get one NOTIFY in return with the PIDF-LO).  If your subscription has a
longer expiration, it is a form of "push", and you might want to have a
filter to limit how many pushes you get.

Note that normally, presence provides identity as well as location.  It may
be that in some uses for the Location header, such as a location based
routing, the identity information is not appropriate.  The policy of the
presence server for that use may be to only return the LO part of the PIDF.
Also note that the form of the URI itself could inadvertently provide
identity information (prez:[email-masked]), which might not be
desirable.  If the idea to allow sip: and prez: is acceptable in the
Location header URI, the text would contain a discussion of this issue.

Brian

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

---

From: "Thomson, Martin" <[email-masked]>
Date: Wed, 19 Jul 2006 18:35:45 -0500

Brian,

Yes, you can use a sip: or pres: URI to retrieve location by-reference.  It works.  Yes, you can use a pull method to retrieve the information; that's a feature of SUBSCRIBE/NOTIFY.  I see no reason to prevent this, but you don't actually have to document every possible retrieval method.

Identity might be a problem, but that can be addressed by the use of unlinked pseudonyms.  This is not specific to the dereference method.  The same problem exists no matter how you resolve location - or are you suggesting that the sip: or pres: URIs dereference to a PIDF-LO, but other forms would not?  Clearly, that problem already exists with the cid: URL and should exist with the https: URL.

What I take from this is that you need to have text that explains the impact of the association between identity and location.  Those concerns are largely covered by other GEOPRIV documents, but there is no harm in being explicit.

Cheers,
Martin

> -----Original Message-----
> From: Brian Rosen [mailto:[email-masked]]
> Sent: Thursday, 20 July 2006 8:46 AM
> To: [email-masked]
> Subject: [Sip] Allowing sip: (or prez:) in the location header
> 

------------------------------------------------------------------------------------------------
This message is for the designated recipient only and may
contain privileged, proprietary, or otherwise private information.  
If you have received it in error, please notify the sender
immediately and delete the original.  Any unauthorized use of
this email is prohibited.
------------------------------------------------------------------------------------------------
[mf2]

---

From: "Brian Rosen" <[email-masked]>
Date: Wed, 19 Jul 2006 20:01:54 -0400

I think we are going to be explicit about what is allowed to be in the
Location header, and not use AbsoluteURI.  We think something DOES have to
document every possible retrieval mechanism and discuss the geopriv privacy
issues and how they are dealt with.  That is precisely what we propose.
We'll define some of them in location-conveyance, and specify how a
standards track document adds more possibilities.

Please note that we don't want a lot of possibilities here; every
dereferencer has to implement all choices.

Incidentally, I think we will specify in the language that an extension to
the allowed URIs in a Location header is NOT a SIP extension, and does not
come under the 3427 process.   This would allow geopriv, for example, to
define the L7 protocol, and if it has a location-by-reference construction
with a dereferencing procedure, it would be allowed to add to the methods
listed in location-conveyance without running through 3427.  That language,
since it is part of sip-location, would have to be acceptable to
sip/sipping.

Agree that the identity issues of URL construction are generic and can be
treated in the text as generic, not tied to any particular scheme.  It may
be more likely in prez:, simply because the default type of uri is an AoR,
which almost always has identity data.

Brian

> From: Thomson, Martin [mailto:[email-masked]]
> Sent: Wednesday, July 19, 2006 7:36 PM
> To: Brian Rosen; [email-masked]
> Subject: RE: [Sip] Allowing sip: (or prez:) in the location header
> 
> Brian,
> 
> Yes, you can use a sip: or pres: URI to retrieve location by-reference.
> It works.  Yes, you can use a pull method to retrieve the information;
> that's a feature of SUBSCRIBE/NOTIFY.  I see no reason to prevent this,
> but you don't actually have to document every possible retrieval method.
> 
> Identity might be a problem, but that can be addressed by the use of
> unlinked pseudonyms.  This is not specific to the dereference method.  The
> same problem exists no matter how you resolve location - or are you
> suggesting that the sip: or pres: URIs dereference to a PIDF-LO, but other
> forms would not?  Clearly, that problem already exists with the cid: URL
> and should exist with the https: URL.
> 
> What I take from this is that you need to have text that explains the
> impact of the association between identity and location.  Those concerns
> are largely covered by other GEOPRIV documents, but there is no harm in
> being explicit.
> 
> Cheers,
> Martin
>

---

From: "Thomson, Martin" <[email-masked]>
Date: Wed, 19 Jul 2006 19:33:17 -0500

There is a difference between using ABNF to limit what is possible and providing a baseline for implementations.

I was happy with the original proposal.  That is, define the header to include AbsoluteURI and say that implementations MUST implement https and cid.  I had assumed that the https derefence would be as simple as the dereference method for the following: <https://ietf.org/>.  Extra functionality/flexibility in dereferencing will actually be useful in some cases.

So here is my concrete proposal:

The ABNF defines a location URI as the following:

Location       = "Location" HCOLON location-param *(COMMA location-param)
location-param = LAQUOT absoluteURI RAQUOT *( SEMI generic-param )

This is a copy and paste of the Alert-Info header ABNF from RFC 3261.  This follows the principle of least surprise.

Then we have text that says something to this effect:

  "Implementations MUST support the cid: URL [ref] for location by-value and the https: URL [ref] for location by-reference.  The https: URI MUST be accessible using an HTTP GET method.  Any URI that is included in this header MUST dereference to a PIDF-LO document (with a MIME-type of "application/pidf+xml")."

  "Parameters MAY be included to indicate additional features of the URI; for instance, with an https: URI, parameters could indicate that a POST to the URI with a request body provides the requester additional control over the information.  However, the requester MUST be able to use an HTTP GET request if this additional functionality is not supported."

You can then setup a registry for parameters with IANA, following the standard form for those things.  I will let the SIP folks make the call on avoiding 3427 process, but it's not a bad idea.1

Cheers,
Martin

> Sent: Thursday, 20 July 2006 10:02 AM
> To: Thomson, Martin; [email-masked]
> > > Note that normally, presence provides identity as well as location.
> It
> > > may
> > ------------------------------------------------------------------------
> --
> > ----------------------
> > ------------------------------------------------------------------------
> --
> > ----------------------
> > [mf2]
>

---

From: Hannes Tschofenig <[email-masked]>
Date: Thu, 20 Jul 2006 11:32:47 +0200

Hi Brian,

in a previous mail discussion you told me that we should not create new 
requirements on the fly.

We are very early in the discussion about the Subscription URI concept 
in the Geopriv-L7 design team. It will take much longer to discuss it. 
It would make more sense to compile a separate draft, if someone wants it.

In the location conveyance document I would like to see a simple HTTPS 
based mechanism (if you think that the proxy behavior belongs into this 
document). This would prevent further delaying the document.

Ciao
Hannes

---

From: "James M. Polk" <[email-masked]>
Date: Thu, 20 Jul 2006 16:59:24 -0500

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

---

From: "James M. Polk" <[email-masked]>
Date: Thu, 20 Jul 2006 18:19:41 -0500

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.

> > From: James M. Polk [mailto:[email-masked]]
> > Sent: Thursday, July 20, 2006 5:59 PM
> > To: Brian Rosen; 'Thomson, Martin'; [email-masked]
> > Subject: RE: [Sip] Allowing sip: in location header not good
> >

---

From: "Thomson, Martin" <[email-masked]>
Date: Thu, 20 Jul 2006 18:55:44 -0500

I don't think that you need to preclude the use of SIP here, but there are a lot of things that need to be considered before SUB/NOT are allowed.

That is to say - the location conveyance document doesn't cover its use, and nothing else does...yet.  When someone does a using-protocol specification for SUB/NOT, then we have a place to describe how to use sip[s]: in the Location header.

Fact is - I don't think that we have ANY using-protocol defined, hence the problems we are having in deciding what goes in the header.

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

A pres: URI is in effect a sip[s]: URI for these purposes.

Cheers,
Martin

---

From: Andrew Newton <[email-masked]>
Date: Thu, 20 Jul 2006 20:53:45 -0400

On Jul 20, 2006, at 7:55 PM, Thomson, Martin wrote:
> That is to say - the location conveyance document doesn't cover its  
> use, and nothing else does...yet.  When someone does a using- 
> protocol specification for SUB/NOT, then we have a place to  
> describe how to use sip[s]: in the Location header.

I guess we've all forgotten about RFC 4079.  Here's the link:
http://www.ietf.org/rfc/rfc4079.txt

-andy

---

From: "Brian Rosen" <[email-masked]>
Date: Thu, 20 Jul 2006 20:54:35 -0400

I think that ship has sailed.  PIDF-LO is precisely defined in presence, and
we don't need any documents that further describe how location is conveyed
in a presence subscription.  All this document would do is describe how you
might go about specifying a presence uri that would be a little less general
(provide less information) than the one you would get by using the "From:"
URI.  The ruleset for this presence uri would be different from the more
general uri.  

Now, it does occur to me that if we allow sip/sips/pres, then we have a
minimal resolution protocol for location by reference.  It might be then
acceptable to drop the whole raw GET idea completely, and leave that to the
L7 protocol.  I kind of like that idea, because the raw GET is really
defining a whole new protocol and I don't think we want to, or need to, do
that in this document.  We brought it up because without at least a minimal
dereference solution, the mechanism does not meet the requirements.  A
presence subscription would do that, with no need for more.

And if we do that, we could drop the resolution-protocol parameter and
registry, because sip/sips/pres doesn't need it.

Brian

> Sent: Thursday, July 20, 2006 7:56 PM
> To: James M. Polk; Brian Rosen; [email-masked]; [email-masked]
> I don't think that you need to preclude the use of SIP here, but there are
> a lot of things that need to be considered before SUB/NOT are allowed.
> 
> That is to say - the location conveyance document doesn't cover its use,
> and nothing else does...yet.  When someone does a using-protocol
> specification for SUB/NOT, then we have a place to describe how to use
> sip[s]: in the Location header.
> 
> Fact is - I don't think that we have ANY using-protocol defined, hence the
> problems we are having in deciding what goes in the header.
> 
>

---

From: Dean Willis <[email-masked]>
Date: Thu, 20 Jul 2006 21:14:40 -0500

> registry, because sip/sips/pres doesn't need it.

Brian's words here are the first to make me say "Aha! I think we have 
something new" that I've read so far this evening. There may be some 
merit in this approach -- please consider it carefully.

--
Dean

---

From: "Thomson, Martin" <[email-masked]>
Date: Thu, 20 Jul 2006 20:51:00 -0500

Yes, I had forgotten.

That document is informational, saying that location is presence.  What I haven't gotten yet, is whether or not this document consequently implies that RFCs 3265/3859/etc... define a using protocol that meets RFC 3693 requirements.

M

> From: Andrew Newton [mailto:[email-masked]]
> Sent: Friday, 21 July 2006 10:54 AM
> To: Thomson, Martin
> Cc: James M. Polk; Brian Rosen; [email-masked]; [email-masked]
> Subject: Re: [Geopriv] RE: [Sip] Allowing sip: in location header not good
> 
>

---

From: Andrew Newton <[email-masked]>
Date: Thu, 20 Jul 2006 20:53:45 -0400

-andy

_______________________________________________
Geopriv mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/geopriv

---

From: Ted Hardie <[email-masked]>
Date: Thu, 20 Jul 2006 16:45:37 -0700

At 6:19 PM -0500 7/20/06, James M. Polk wrote:
>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.

Do you mean "send onward in the SIP signaling path" or "send to the LoST server"?

The problem here is that if the originating client has to allow all retransmission
in order to get the call through, their privacy protection has gone to nil; in
places where you have to be able to protect privacy during the emergency
call, that's a problem.  So just saying "it must be set to 'yes'" doesn't solve
the problem.  I think we really need to be able to distinguish between
using the location to route the call and forwarding the target of the call
forwarding the location; I believe that means we need to be able to break
the first out of "retransmission-allowed" into a separate permission.

My two cents,
				Ted

---

From: Ted Hardie <[email-masked]>
Date: Thu, 20 Jul 2006 16:45:37 -0700

My two cents,
				Ted