Subject: [sipcore] geo URI and conveyance: conclusion?

From: "Thomson, Martin" <[email-masked]>
Date: Mon, 26 Jul 2010 21:28:15 +0800

I missed the conclusions regarding geo URI.  I got the bit where we decided that we needed to have _some_ text, but I'm not sure what we decided what the text might look like.

Help me?

---

From: Alexander Mayrhofer <[email-masked]>
Date: Mon, 26 Jul 2010 16:05:30 +0200

> I missed the conclusions regarding geo URI.  I got the bit 
> where we decided that we needed to have _some_ text, but I'm 
> not sure what we decided what the text might look like.

Adding "geo:" to SIP Location Conveyance was actually one of the first
applications that came to my mind when i started the draft. I'm more
than happy to help with the text - i'm in Maastricht for the whole week
for face to face discussions.

Alex

---

From: "Richard L. Barnes" <[email-masked]>
Date: Mon, 26 Jul 2010 16:27:38 +0200

I was afraid that Alex would notice :)

The concern here is about privacy, since the geo URI scheme doesn't  
include GEOPRIV-like rules.  In fact, the privacy part of RFC 5870 has  
the following text:
"
However, if a 'geo' URI is used in a context where it identifies the  
location of a Target, it becomes part of a Location Object and is  
therefore subject to GEOPRIV rules. Therefore, when 'geo' URIs are put  
into such contexts, the privacy requirements of RFC 3693 MUST be met.
"

So in order to use a geo URI in SIP, we would need to do something  
about privacy rules.  The only easy approach that occurs to me is to  
specify fixed rules that come along with putting a GEO URI in a  
Geolocation header.  Suggested text:
"
Including a "geo:" URI in a Geolocation header associates that  
location with the entity that originated the SIP message, making it in  
effect a Location Object in the terms of RFC 3693. In particular,  
there is a need for such location objects to have privacy rules that  
accompany the object.  A "geo:" URI in a Geolocation header is  
assigned a default set of privacy rules, equivalent to the default  
rules in RFC 4119:
   o retransmission-allowed: false
   o retention-expires: 24 hours from time of transmission
   o ruleset-reference: null
   o note-well: null
"

On Jul 26, 2010, at 4:05 PM, Alexander Mayrhofer wrote:

> _______________________________________________
> sipcore mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/sipcore

---

From: "Thomson, Martin" <[email-masked]>
Date: Mon, 26 Jul 2010 22:36:09 +0800

That was precisely the same conclusion that I came to.  It’s not especially flexible and we enter the realm of policy definition when we do so.  I advise caution.

From: Richard L. Barnes [mailto:[email-masked]]
Sent: Monday, 26 July 2010 4:28 PM
To: Alexander Mayrhofer
Cc: Thomson, Martin; [email-masked]
Subject: Re: [sipcore] geo URI and conveyance: conclusion?

The concern here is about privacy, since the geo URI scheme doesn't include GEOPRIV-like rules.  In fact, the privacy part of RFC 5870 has the following text:
"
However, if a 'geo' URI is used in a context where it identifies the location of a Target, it becomes part of a Location Object and is therefore subject to GEOPRIV rules. Therefore, when 'geo' URIs are put into such contexts, the privacy requirements of RFC 3693 MUST be met.
"

So in order to use a geo URI in SIP, we would need to do something about privacy rules.  The only easy approach that occurs to me is to specify fixed rules that come along with putting a GEO URI in a Geolocation header.  Suggested text:
"
Including a "geo:" URI in a Geolocation header associates that location with the entity that originated the SIP message, making it in effect a Location Object in the terms of RFC 3693. In particular, there is a need for such location objects to have privacy rules that accompany the object.  A "geo:" URI in a Geolocation header is assigned a default set of privacy rules, equivalent to the default rules in RFC 4119:
  o retransmission-allowed: false
  o retention-expires: 24 hours from time of transmission
  o ruleset-reference: null
  o note-well: null
"

Alex
_______________________________________________
sipcore mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/sipcore

---

From: "James M. Polk" <[email-masked]>
Date: Mon, 26 Jul 2010 10:10:36 -0500

At 08:28 AM 7/26/2010, Thomson, Martin wrote:
>I missed the conclusions regarding geo URI.  I got the bit where we 
>decided that we needed to have _some_ text, but I'm not sure what we 
>decided what the text might look like.
>
>Help me?

I believe the agreement in the room was to explicitly avoid it (i.e., 
"MUST NOT appear in the Geolocation header value (i.e., 
locationValue)"). As it's too close to being a data-URL (per Adam).

James

---

From: Alexander Mayrhofer <[email-masked]>
Date: Mon, 26 Jul 2010 17:17:34 +0200

> locationValue)"). As it's too close to being a data-URL (per Adam).

I wasn't in the room for the discussion. But i have to disagree that the
geo: URI scheme is "close to being a data-URL". While the data: URI
scheme has opaque semantics by definition, the geo: URI was specifically
developed to have precise and unambigious semantics associated with its
components, and a lot of time was spent on this.

So, if "too close to data-URL" translates into "lack of semantics", than
this is definitely true for the data: scheme, but definitely not for the
geo: scheme.

Alex

---

From: "Richard L. Barnes" <[email-masked]>
Date: Mon, 26 Jul 2010 17:47:26 +0200

I wouldn't say it was explicitly ruled out.  We just noticed that it  
was inconsistent with the requirements RFC 3693/5808 in this context.   
What we're discussing now is how to make GEO URIs satisfy those  
requirements.

On Jul 26, 2010, at 5:10 PM, James M. Polk wrote:

>> decided that we needed to have _some_ text, but I'm not sure what  
>> we decided what the text might look like.
>>
>> Help me?
>
> I believe the agreement in the room was to explicitly avoid it  
> (i.e., "MUST NOT appear in the Geolocation header value (i.e.,

---

From: "James M. Polk" <[email-masked]>
Date: Mon, 26 Jul 2010 11:02:53 -0500

I'm not fighting you, but that's not how I remember the exchange 
between Jon and Adam.

james

---

From: "Richard L. Barnes" <[email-masked]>
Date: Mon, 26 Jul 2010 18:07:43 +0200

After chatting with Martin and Alex, here's another possibility:

Clearly, a client that is capable of sending a GEO URI can just as  
well send a PIDF-LO document with the same information (in a lot more  
bits).  So we can view the use of a GEO URI as an optimization, for  
those times when you don't need what PIDF-LO offers.  Given  that  
interpretation, you could basically say "use a GEO URI if you don't  
want any contraints, otherwise generate a PIDF-LO".  Suggested text:
"
Clients embedding location in a SIP message by value typically do so  
by embedding a PIDF-LO message body and adding CID URI to the  
Geolocation header.  In some cases, a location value can be expressed  
much more compactly using a GEO URI [RFC5870], namely when the  
following two conditions apply:
1. The location being expressed is a point (optionally with an  
uncertainty radius), and
2. The client does not wish to express privacy preferences.
When used with the SIP Geolocation header, a GEO URI is equivalent to  
a PIDF-LO document with the following contents:
    o Entity: From address of SIP message
    o Location information: Point or circle equivalent to GEO URI (see  
[RFC5870] for translation)
    o Privacy rules:
       o retransmission-allowed: true
       o retention-expiry: unlimited (any date very far in the future)
       o ruleset-reference: null
       o note-well: null
A client that wishes to express more restrictive privacy rules than  
these defaults should create a PIDF-LO document encoding these rules,  
and include the PIDF-LO document in the SIP message (rather than a GEO  
URI).
"

On Jul 26, 2010, at 4:27 PM, Richard L. Barnes wrote:

> include GEOPRIV-like rules.  In fact, the privacy part of RFC 5870  
> has the following text:
> "
> therefore subject to GEOPRIV rules. Therefore, when 'geo' URIs are  
> put into such contexts, the privacy requirements of RFC 3693 MUST be  
> met.
> "
>
> location with the entity that originated the SIP message, making it  
> in effect a Location Object in the terms of RFC 3693. In particular,

---

From: "Thomson, Martin" <[email-masked]>
Date: Tue, 27 Jul 2010 00:12:28 +0800

A pseudonym would suffice for the entity.  There is no need to say that the entity identified in the From header is at that location, only that the location is relevant to the request.

--Martin

From: Richard L. Barnes [mailto:[email-masked]]
Sent: Monday, 26 July 2010 6:08 PM
To: Alexander Mayrhofer; [email-masked]; Thomson, Martin
Subject: Re: [sipcore] geo URI and conveyance: conclusion?

Clearly, a client that is capable of sending a GEO URI can just as well send a PIDF-LO document with the same information (in a lot more bits).  So we can view the use of a GEO URI as an optimization, for those times when you don't need what PIDF-LO offers.  Given  that interpretation, you could basically say "use a GEO URI if you don't want any contraints, otherwise generate a PIDF-LO".  Suggested text:
"
Clients embedding location in a SIP message by value typically do so by embedding a PIDF-LO message body and adding CID URI to the Geolocation header.  In some cases, a location value can be expressed much more compactly using a GEO URI [RFC5870], namely when the following two conditions apply:
1. The location being expressed is a point (optionally with an uncertainty radius), and
2. The client does not wish to express privacy preferences.
When used with the SIP Geolocation header, a GEO URI is equivalent to a PIDF-LO document with the following contents:
   o Entity: From address of SIP message
   o Location information: Point or circle equivalent to GEO URI (see [RFC5870] for translation)
   o Privacy rules:
      o retransmission-allowed: true
      o retention-expiry: unlimited (any date very far in the future)
      o ruleset-reference: null
      o note-well: null
A client that wishes to express more restrictive privacy rules than these defaults should create a PIDF-LO document encoding these rules, and include the PIDF-LO document in the SIP message (rather than a GEO URI).
"

Alex

---

From: Adam Roach <[email-masked]>
Date: Mon, 26 Jul 2010 23:04:18 +0200

It's not entirely different from what we were talking about, but it's 
not the main thrust, either. At least, not with respect to the point *I* 
was trying to make.

The analogy I was making with "data:" URLs was an attempt to debunk the 
notion that the syntactic use of "anyURI" somehow implicitly allowed the 
use of a "geo:" URI. The comparison I made was to the myriad header 
fields in SIP that allow any URI -- such as Alert-Info -- but for which 
it would be patently ridiculous to include a "data:" URL.

/a

---

From: "James M. Polk" <[email-masked]>
Date: Tue, 27 Jul 2010 03:25:40 -0500

Adam

So what are you saying?

You seems to be implying something, but I can't tell if it's what I 
said, what Martin said or something in between?

Can you give one clarifying statement about what you understand this 
issue to be solved as?

James

At 04:04 PM 7/26/2010, Adam Roach wrote:

>  It's not entirely different from what we were talking about, but 
> it's not the main thrust, either. At least, not with respect to the 
> point *I* was trying to make.
>
>The analogy I was making with "data:" URLs was an attempt to debunk 
>the notion that the syntactic use of "anyURI" somehow implicitly 
>allowed the use of a "geo:" URI. The comparison I made was to the 
>myriad header fields in SIP that allow any URI -- such as Alert-Info 
>-- but for which it would be patently ridiculous to include a "data:" URL.
>
>/a
>

---

From: Adam Roach <[email-masked]>
Date: Tue, 27 Jul 2010 10:32:12 +0200

A clearer summary of what I'm trying to say: if you expect "geo:" URIs 
to be used in SIP location conveyance, you'll need to explicitly add 
text saying so.

The bit about them being forbidden was based on assertions from people 
who know far more about geopriv than I do -- they asserted that it 
lacked the "priv" half of "geopriv," and therefore wasn't appropriate. 
Martin (or Richard, I can't recall) has proposed some ways this might be 
fixable, and I have no opinion on that topic.

/a