Subject: [sipcore] Geolocation Call

From: Adam Roach - SIPCORE Chair <[email-masked]>
Date: Thu, 10 Feb 2011 17:18:10 -0600

The phone call today had exactly one topic of discussion: Syntax and 
semantics of the SIP header field or fields associated with geolocation 
conveyance.

Of those on the call, there was unanimous agreement to go with what Paul 
characterized as "Option #5" in his earlier email on the topic. To 
summarize this option:

    * We will define a "Geolocation" header field, which can contain one
      or more location values.
    * A SIP message may contain zero or more Geolocation header fields.
    * We will define a "Geolocation-Routing" header field, which
      contains either "yes" or "no".
    * The "Geolocation-Routing" header field can appear at most once in
      a SIP message.
    * In the absence of a "Geolocation-Routing" header field,
      intermediaries are to assume a value of "no".

The specific ANBF that defines these two header fields is:

    Geolocation-header = "Geolocation" HCOLON locationValue
                         *( COMMA locationValue )
   locationValue      =  LAQUOT locationURI RAQUOT
                           *(SEMI geoloc-param)
    locationURI        =  sip-URI / sips-URI / pres-URI
                          / http-URI / HTTPS-URI
                           / cid-url ; (from RFC 2392)
                           / absoluteURI ; (from RFC 3261)
   geoloc-param       =  generic-param;  (from RFC 3261)

    Georouting-header  = "Geolocation-Routing" HCOLON
                         ( "yes" / "no" / gen-value )

---

From: Adam Roach <[email-masked]>
Date: Thu, 10 Feb 2011 17:24:14 -0600

[as chair]

Somehow, Thunderbird cut off the remainder of this message. It was 
supposed to continue after the ABNF with:

If there are no objections to these changes on this mailing list, then 
the authors will produce a new version of the document early next week 
reflecting these decisions. The plan is to issue a two-week working 
group last call period immediately after publication.

/a

On 2/10/11 5:18 PM, Adam Roach - SIPCORE Chair wrote:
> semantics of the SIP header field or fields associated with 
> geolocation conveyance.
>
> Of those on the call, there was unanimous agreement to go with what 
> Paul characterized as "Option #5" in his earlier email on the topic. 
> To summarize this option:
>
> _______________________________________________
> sipcore mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/sipcore

---

From: "Richard L. Barnes" <[email-masked]>
Date: Thu, 10 Feb 2011 15:29:31 -0800

This looks good to me.  Onward!

On Feb 10, 2011, at 3:24 PM, Adam Roach wrote:

> [as chair]
> 
> Somehow, Thunderbird cut off the remainder of this message. It was supposed to continue after the ABNF with:
> 
> If there are no objections to these changes on this mailing list, then the authors will produce a new version of the document early next week reflecting these decisions. The plan is to issue a two-week working group last call period immediately after publication.
> 
> /a
> 
>> The phone call today had exactly one topic of discussion: Syntax and semantics of the SIP header field or fields associated with geolocation conveyance.
>> 
>> Of those on the call, there was unanimous agreement to go with what Paul characterized as "Option #5" in his earlier email on the topic. To summarize this option:
>>

---

From: "Thomson, Martin" <[email-masked]>
Date: Fri, 11 Feb 2011 11:06:52 +0800

Ship it.

On 2011-02-11 at 10:29:31, Richard L. Barnes wrote:
> > If there are no objections to these changes on this mailing list,
> then the authors will produce a new version of the document early next
> week reflecting these decisions. The plan is to issue a two-week
> working group last call period immediately after publication.
> >

---

From: "Elwell, John" <[email-masked]>
Date: Fri, 11 Feb 2011 08:32:33 +0100

Sorry I was unable to make the call, but looks good to me.

John 

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Adam Roach - 
> SIPCORE Chair
> Sent: 10 February 2011 23:18
> To: SIPCORE (Session Initiation Protocol Core) WG
> Subject: [sipcore] Geolocation Call
> 
> geolocation

---

From: "Elwell, John" <[email-masked]>
Date: Fri, 11 Feb 2011 12:29:41 +0100

Although my previous message indicated all is fine with this proposal, I do now have a query as to how this will manifest itself in the revised draft. See below. 

>       intermediaries are to assume a value of "no".
[JRE] This last bullet is fine, but what about where there is neither a Geolocation-Routing header field nor a Geolocation header field and the intermediary, on behalf of the UA (e.g., a location-unaware UA) inserts a Geolocation header field? I hope we are not intending to compell the intermediary to use "no".

Existing text in 4.1 states:
"If no routing-allowed parameter 
   is present in a SIP request, a SIP intermediary MAY insert this 
   value with a RECOMMENDED value of "no" by default."
This present text at least permits (even if not recommended) a value of "yes). This text at least needs some attention to talk about the Geolocation-Routing header field rather than the parameter, and in so doing we should give careful consideration to what it should say about Geolocation-Routing. I think there are two separate cases:

1. Where there is already a Geolocation header field but no Geolocation-Routing header field. In this case I don't think the intermediary should be allowed to add Geolocation-Routing (or if it does, it MUST have a value of "no").

2. Where there is neither a Geolocation header field nor a Geolocation-Routing header field. In this case, I believe it is permissible for the intermediary to insert both. I don't think even a recommendation to set the value to "no" is needed.

John

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 11 Feb 2011 08:59:18 -0500

Good catch John. I agree with your points.

	Paul

---

From: "James M. Polk" <[email-masked]>
Date: Fri, 11 Feb 2011 13:48:32 -0600

>Good catch John. I agree with your points.

Paul/John

Several comments and 1 question below

>>Although my previous message indicated all is fine with this 
>>proposal, I do now have a query as to how this will manifest itself 
>>in the revised draft. See below.
>>
>>[JRE] This last bullet is fine, but what about where there is 
>>neither a Geolocation-Routing header field nor a Geolocation header 
>>field and the intermediary, on behalf of the UA (e.g., a 
>>location-unaware UA) inserts a Geolocation header field? I hope we 
>>are not intending to compell the intermediary to use "no".
>>
>>This present text at least permits (even if not recommended) a 
>>value of "yes). This text at least needs some attention to talk 
>>about the Geolocation-Routing header field rather than the parameter,

When the parameter becomes a header, all talk about the parameter 
will convert too.

>>and in so doing we should give careful consideration to what it 
>>should say about Geolocation-Routing.

I have thought that once this parameter elevates to a header, the 
text needs to 'list' more about what it does and what it means 
depending on whether or not there is a Geolocation-Routing header 
value and what it is set to (i.e., yes or no or absent (but not null 
- which won't be allowed), so I'm with you.

>>I think there are two separate cases:
>>
>>1. Where there is already a Geolocation header field but no 
>>Geolocation-Routing header field. In this case I don't think the 
>>intermediary should be allowed to add Geolocation-Routing (or if it 
>>does, it MUST have a value of "no").

I agree, and this is consistent with what's in the draft now by it 
saying the default when not present is "no".

>>2. Where there is neither a Geolocation header field nor a 
>>Geolocation-Routing header field. In this case, I believe it is 
>>permissible for the intermediary to insert both. I don't think even 
>>a recommendation to set the value to "no" is needed.

This one is more dicey, but I think I agree with you.

if there is neither header is present, this absolutely allows an 
intermediary to insert location. But here's the question/dicey part - 
is the default policy from the UAC still "no".

Some might say this is true even without a Geolocation header in the 
original SIP request from the UAC.

Others might say that because the original UAC didn't include a 
Geolocation-Routing header = "no" that this leaves it up in the air 
for downstream intermediaries to insert the header with either a "no" or "yes".

This more of less motivates the original UAC to include the 
Geolocation-Routing header even if it doesn't include a Geolocation 
header just to make sure it's policy of "no" is included downstream 
(at least until one of the 2 existing permissions is required to 
process the request). What is in this paragraph is implied. Question 
to you (and others) - should this be stated informally (but certainly 
not normatively)?  I'd hate for this not to be clear in some 
implementations for customers (individual or administrative) not to 
have the chance to configure one way or the other.

James

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 11 Feb 2011 15:30:14 -0500

below

On 2/11/2011 2:48 PM, James M. Polk wrote:

>>> permissible for the intermediary to insert both. I don't think even a
>>> recommendation to set the value to "no" is needed.
>
> intermediary to insert location. But here's the question/dicey part - is
> the default policy from the UAC still "no".
>
> Geolocation-Routing header = "no" that this leaves it up in the air for
> downstream intermediaries to insert the header with either a "no" or "yes".
>
> header just to make sure it's policy of "no" is included downstream (at
> least until one of the 2 existing permissions is required to process the
> request). What is in this paragraph is implied. Question to you (and
> others) - should this be stated informally (but certainly not
> normatively)? I'd hate for this not to be clear in some implementations
> for customers (individual or administrative) not to have the chance to
> configure one way or the other.

I hope this doesn't open up old wounds we would rather not revisit...

What is the *reason* that someone might specify that routing 
should/should not be allowed to use the geoloc info???

ISTM this is based on the reason that the geoloc info was inserted in 
the header at all.
- I want this routed normally, and want the recipient to
   have this location info available

- I inserted this location info, at least in part, for the purpose
   of getting the request routed based on the location.

It seems that ultimately then this is driven by whoever inserts the 
location info. That would argue that if the UAC inserted nothing about 
location, and something downstream did, then the inserter ought to have 
the opportunity to decide whether the purpose is for routing or not.

If the UAC inserted *some* geoloc info, then it has made the decision of 
the purpose for it. And in that case an intermediary inserting 
additional location info needs to honor the intent.

Bottom line - I am agreeing with both of you.

	Thanks,
	Paul

---

From: "Elwell, John" <[email-masked]>
Date: Mon, 14 Feb 2011 12:09:02 +0100

> [mailto:[email-masked]] On Behalf Of Paul Kyzivat
> Sent: 11 February 2011 20:30
> To: James M. Polk
> Cc: [email-masked]
> Subject: Re: [sipcore] Geolocation Call
> 
> below
> 
[JRE] Yes, that was my reasoning.

John

---

From: "James M. Polk" <[email-masked]>
Date: Mon, 14 Feb 2011 17:22:44 -0600

>should/should not be allowed to use the geoloc info???

the existing "routing-allowed" header parameter is a bit of a 
mislabeling. It doesn't mean "routing" in the L3 or L7 sense of the 
word, it means "do I (the recipient of this SIP request have 
permission to view the locally available - or via a dereference 
transaction that I perform - geolocation information within this SIP 
request. If "routing-allowed" is set to "=yes", then I have 
permission to view it and to send the geolocation information to a 
3rd party (as many as I want or as many times as I want). If 
"routing-allowed" is set to "=no", I do not have permission to view 
or dereference any geolocation information directly or indirectly 
related to this SIP request, *and* I do not have permission to 
transmit this location blob to a 3rd party at any time.

Based on the above, I think your first "ISTM" point is a little off, 
but understandably so. It should have "only the recipient" in there, 
and then it's accurate.

the second point is correct as is.

>ISTM this is based on the reason that the geoloc info was inserted 
>in the header at all.
>location info.

or the policy flag (which is the Geolocation-Routing: header, which 
can be inserted without there being a Geolocation: header)

>  That would argue that if the UAC inserted nothing about location, 
> and something downstream did, then the inserter ought to have the 
> opportunity to decide whether the purpose is for routing or not.

I agree with this, unless there is a "Geolocation-Routing: no" header 
flag setting the policy for location handling for all downstream 
inband signaling elements.

>If the UAC inserted *some* geoloc info, then it has made the 
>decision of the purpose for it. And in that case an intermediary 
>inserting additional location info needs to honor the intent.
>

but do you agree now?

James

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 15 Feb 2011 09:07:38 -0500

On 2/14/2011 6:22 PM, James M. Polk wrote:
> word, it means "do I (the recipient of this SIP request have permission
> to view the locally available - or via a dereference transaction that I
> perform - geolocation information within this SIP request. If
> "routing-allowed" is set to "=yes", then I have permission to view it
> and to send the geolocation information to a 3rd party (as many as I
> want or as many times as I want). If "routing-allowed" is set to "=no",
> I do not have permission to view or dereference any geolocation
> information directly or indirectly related to this SIP request, *and* I
> do not have permission to transmit this location blob to a 3rd party at
> any time.

Hmm. I thought it was a rule about whether the geoloc info could be used 
to make retargeting decisions. So, IIUC now, you are saying this has to 
do with routing of the geoloc info, not routing of the message 
containing it. Is that right? (Of course, routing the message containing 
it has the effect of routing the geoloc info too.)

> Based on the above, I think your first "ISTM" point is a little off, but
> understandably so. It should have "only the recipient" in there, and
> then it's accurate.
>
> or the policy flag (which is the Geolocation-Routing: header, which can
> be inserted without there being a Geolocation: header)
>
>> That would argue that if the UAC inserted nothing about location, and
>> something downstream did, then the inserter ought to have the
> flag setting the policy for location handling for all downstream inband
> signaling elements.
>
>
>> If the UAC inserted *some* geoloc info, then it has made the decision
>> of the purpose for it. And in that case an intermediary inserting

Your clarification doesn't alter my conclusion.

	Thanks,
	Paul

---

From: "James M. Polk" <[email-masked]>
Date: Tue, 15 Feb 2011 17:36:15 -0600

At 08:07 AM 2/15/2011, Paul Kyzivat wrote:

>Hmm. I thought it was a rule about whether the geoloc info could be 
>used to make retargeting decisions.

correct, but that's secondary. The primary concern is whether or not 
SIP intermediaries, as LRs, are even allowed to view (or dereference) 
location in the message. If they can (i.e., "Geolocation-Routing: 
yes"), then they view this information to make routing decisions. If, 
OTOH, "Geolocation-Routing: no" and that intermediary believes (as 
much as a machine can 'believe') it has to be able to use the 
location information of the Target to make a proper routing decision, 
the intermediary must respond with a 424 (Bad Location Information) 
response including the following:

   Geolocation-Error: 202 "Permission to Route based on Location
                           Information"

This should bubble up to the UI to allow that Target's user to agree 
(or not) to reveal their location information to that (and all) SIP 
intermediaries for use in making good routing decisions of the 
subsequent SIP request.

Does this make sense?

So, the answer is yes, it has to do with the actual routing of the 
message, but that's a secondary concern to the revelation of the 
Target's location information (i.e., it's a little more complicated 
than you originally put it).

>So, IIUC now, you are saying this has to do with routing of the 
>geoloc info, not routing of the message containing it. Is that right?

No, it's a viewability flag for the contained location, then with 
permission to view the Target's location information, it's making a 
good routing decision based on that location information.

Let me know if I've confused you with this explanation.

James

>(Of course, routing the message containing it has the effect of 
>routing the geoloc info too.)
>

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 15 Feb 2011 19:43:38 -0500

trimming...

On 2/15/2011 6:36 PM, James M. Polk wrote:

> correct, but that's secondary. The primary concern is whether or not SIP
> intermediaries, as LRs, are even allowed to view (or dereference)
> location in the message. If they can (i.e., "Geolocation-Routing: yes"),
> then they view this information to make routing decisions. If, OTOH,
> "Geolocation-Routing: no" and that intermediary believes (as much as a
> machine can 'believe') it has to be able to use the location information
> of the Target to make a proper routing decision, the intermediary must
> respond with a 424 (Bad Location Information) response including the
> following:
>
> This should bubble up to the UI to allow that Target's user to agree (or
> not) to reveal their location information to that (and all) SIP
> Target's location information (i.e., it's a little more complicated than
> you originally put it).
>
>> So, IIUC now, you are saying this has to do with routing of the geoloc
>> info, not routing of the message containing it. Is that right?
>
> permission to view the Target's location information, it's making a good
> routing decision based on that location information.

If so, then maybe the name of the header field used to transmit the flag 
should be renamed to something more suggestive of its meaning. I guess 
that wouldn't be a radical last minute change, since this will be the 
first time it has its own header field name.

	Thanks,
	Paul

---

From: "Peterson, Jon" <[email-masked]>
Date: Tue, 15 Feb 2011 20:12:10 -0500

How did we start down this rabbit hole? See RFC5606, especially section 3.5:

   When "Location-Routing-Allowed" is set to "Yes", the Rule Maker is
   indicating permission to use the included LI for location-based
   routing.  When "Location-Routing-Allowed" is set to "No", the
   originator is indicating that this use is not permitted.  "Location-
   Routing-Allowed" being set to "No" has no protocol-level mechanism
   for enforcement of this behavior; like the PIDF-LO <retransmission-
   allowed> being set to "no", it is a way for the Rule Maker to express
   a preference to the SIP elements, which are LI recipients.  It may,
   however, present a significant optimization.  Where a location-by-
   reference is included with "Location-Routing-Allowed" set to "No",
   the SIP elements along the path know that they do not need to attempt
   to dereference the location information; this is significantly faster
   than attempting the dereference and being denied at the
   authentication stage.
I wouldn't advise reading any more into this Geolocation-Routing header than the semantics of "location-routing-allowed" above. It is not intended to be some kind of security mechanism that would prevent a proxy from reading location information (we have other ways to do that). It does however resolve the ambiguity of SIP proxies "retransmitting" location information by merely forwarding requests, which in a strict reading of RFC4119 could easily be inferred. Setting a "routing-allowed" bit of some kind clarifies that the Ruler Maker doesn't mind retransmission (even when "retransmission-allowed" is set to "no" at a PIDF level) as long as it takes place as in the context of normal SIP operations, be it bare forwarding, retargeting or what have you.

Jon Peterson
NeuStar, Inc.

---

From: "Richard L. Barnes" <[email-masked]>
Date: Tue, 15 Feb 2011 21:03:54 -0500

+1 

This is a problem for which there is WG consensus on a solution, namely RFC 5606.

--Richard

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 15 Feb 2011 21:09:44 -0500

Thanks Jon. I never followed the details of all this stuff.

But looking at -05, I think the existing text is consistent with what 
you say. Of course it needs to be tweaked for the switch from parameter 
to header field. But it does seem to be all about routing of the sip, so 
I think the chosen name is ok.

	Thanks,
	Paul

On 2/15/2011 8:12 PM, Peterson, Jon wrote:
>     for enforcement of this behavior; like the PIDF-LO<retransmission-

---

From: Adam Roach <[email-masked]>
Date: Wed, 16 Feb 2011 17:02:49 -0600

[as chair]

This appears to mostly come down to what intermediaries can do when no 
"Location-Routing" field is present. What I think I've heard everyone 
agree to in this thread is:

If an intermediary inserts location into a SIP message and finds no 
"Location-Routing" header field, it may insert its own, with either 
"yes" or "no," according to its local policy. As a corollary; if a 
client doesn't insert a location but wants to suppress intermediaries 
from reading one that may be inserted later, then it explicitly adds a 
"Location-Routing: no" field.

If an intermediary finds a SIP message with a "Location" field but no 
"Location-Routing" field, it may not dereference the location.

Does that accurately summarize everyone's position?

If so, I don't think we need a phone call tomorrow. If anyone disagrees, 
then I'd like to use the call tomorrow to wrestle this issue to the ground.

/a

On 2/15/11 8:09 PM, Paul Kyzivat wrote:
> you say. Of course it needs to be tweaked for the switch from 
> parameter to header field. But it does seem to be all about routing of 
> the sip, so I think the chosen name is ok.
>
>     Thanks,
>     Paul
>
>> I wouldn't advise reading any more into this Geolocation-Routing 
>> header than the semantics of "location-routing-allowed" above. It is 
>> not intended to be some kind of security mechanism that would prevent 
>> a proxy from reading location information (we have other ways to do 
>> that). It does however resolve the ambiguity of SIP proxies 
>> "retransmitting" location information by merely forwarding requests, 
>> which in a strict reading of RFC4119 could easily be inferred. 
>> Setting a "routing-allowed" bit of some kind clarifies that the Ruler 
>> Maker doesn't mind retransmission (even when "retransmission-allowed" 
>> is set to "no" at a PIDF level) as long as it takes place as in the 
>> context of normal SIP operations, be it bare forwarding, retargeting 
>> or what have you.
>>
>> Jon Peterson
>> NeuStar, Inc.
>>
>>>>>> permission
>>>> yes"),
>>>>> geoloc
>>>> good

---

From: "James M. Polk" <[email-masked]>
Date: Wed, 16 Feb 2011 17:46:37 -0600

At 05:02 PM 2/16/2011, Adam Roach wrote:
>[as chair]
>
>This appears to mostly come down to what intermediaries can do when 
>no "Location-Routing" field is present. What I think I've heard 
>everyone agree to in this thread is:
>
>client doesn't insert a location but wants to suppress 
>intermediaries from reading one that may be inserted later, then it 
>explicitly adds a "Location-Routing: no" field.
>
>If an intermediary finds a SIP message with a "Location" field but 
>no "Location-Routing" field, it may not dereference the location.
>

Adam (and all)

To answer your question above - I think you have it right. I think 
the only real play (or uncertainty) is when there is no Geolocation 
header field, and what to do when there is one of the three 
possibilities for the Geolocation-Routing.

With that in mind, I have tentatively added a table in -06 of the 12 
possibilities I can think of for the combinations of Geolocation and 
Geolocation-Routing header fields, focusing on a Geolocation-Routing 
"=no", "=yes", and when no Gelocation-Routing header field is present 
(with or without a Geolocation header field).  I've come up with the 
following - that only Jon has seen so far.

I'd like to get feedback on this

- have I got everything I need in the table?
- did I miss anything?
- have I gotten anything wrong in the table?
- should I expand what I say in the Geolocation-Routing column?

and finally:
- should this table be included in -06?

Here's the table as it currently is in the rough draft of -06:
"
   Based on the above, the following table explains the 12 known
   combinations of Geo-based header fields.

   Geo-based header combinations          Geolocation-Routing
   ----------------------------------     -------------------
   a single locationValue in a single      Implicitly set to "=no"
   Geolocation header instance within
   the same SIP request, with no
   Geolocation-Routing header present.

   more than one locationValue in a        Implicitly set to "=no"
   single Geolocation header instance
   within the same SIP request, with no
   Geolocation-Routing header present.

   more than one locationValue in more     Implicitly set to "=no"
   than one Geolocation header instance
   within the same SIP request, with no
   Geolocation-Routing header present.

   a single locationValue in a single      Explicitly set to "=no"
   Geolocation header instance within
   the same SIP request, with single
   Geolocation-Routing header-value "=no".

   more than one locationValue in a        Explicitly set to "=no"
   single Geolocation header instance
   within the same SIP request, with
   single Geolocation-Routing header-value
   "=no".

   more than one locationValue in more     Explicitly set to "=no"
   than one Geolocation header instance
   within the same SIP request, with single
   Geolocation-Routing header-value "=no".

   a single locationValue in a single      Explicitly set to "=yes"
   Geolocation header instance within the
   same SIP request, with single
   Geolocation-Routing header-value "=yes".

   more than one locationValue in a        Explicitly set to "=yes"
   single Geolocation header instance
   within the same SIP request, with
   single Geolocation-Routing header-value
   "=yes".

   more than one locationValue in more     Explicitly set to "=yes"
   than one Geolocation header instance
   within the same SIP request, with single
   Geolocation-Routing header-value "=yes".

   no Geolocation header instance within   Default Geolocation-Routing
   a SIP request, with no                  is open and can be set by a
   Geolocation-Routing header present.     downstream entity or not at
                                           all.

   no Geolocation header instance within   Location viewing policy set
   a SIP request, with single              already such
   Geolocation-Routing header-value "=no". Location viewing policy set
                                          already such that no
                                           intermediaries can view
                                           location inserted
                                           downstream.

   no Geolocation header instance within   Location viewing policy set
   a SIP request, with single              already such that if
   Geolocation-Routing header-value        location is inserted
   "=yes".                                downstream, intermediaries
                                           can maintain an open viewing
                                           of location policy or can
                                           change policy to "=no" for
                                           intermediaries further
                                           downstream.
"

James

>If so, I don't think we need a phone call tomorrow. If anyone 
>disagrees, then I'd like to use the call tomorrow to wrestle this 
>issue to the ground.
>
>/a
>
>>But looking at -05, I think the existing text is consistent with 
>>what you say. Of course it needs to be tweaked for the switch from 
>>parameter to header field. But it does seem to be all about routing 
>>of the sip, so I think the chosen name is ok.
>>
>>     Thanks,
>>     Paul
>>
>>>header than the semantics of "location-routing-allowed" above. It 
>>>is not intended to be some kind of security mechanism that would 
>>>prevent a proxy from reading location information (we have other 
>>>ways to do that). It does however resolve the ambiguity of SIP 
>>>proxies "retransmitting" location information by merely forwarding 
>>>requests, which in a strict reading of RFC4119 could easily be 
>>>inferred. Setting a "routing-allowed" bit of some kind clarifies 
>>>that the Ruler Maker doesn't mind retransmission (even when 
>>>"retransmission-allowed" is set to "no" at a PIDF level) as long 
>>>as it takes place as in the context of normal SIP operations, be 
>>>it bare forwarding, retargeting or what have you.
>>>
>>>Jon Peterson
>>>NeuStar, Inc.
>>>

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 16 Feb 2011 21:29:54 -0500

Adam,

What you say is consistent with my understanding and with what I think 
makes sense.

	Thanks,	
	Paul

---

From: "Elwell, John" <[email-masked]>
Date: Thu, 17 Feb 2011 10:55:11 +0100

I think this analysis is correct.

John 

> [mailto:[email-masked]] On Behalf Of James M. Polk
> Sent: 16 February 2011 23:47
> To: Adam Roach; Paul Kyzivat
> Cc: [email-masked]

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 18 Feb 2011 19:19:40 -0500

James,

I think your enumeration of cases is correct, but I find Adam's two 
paragraphs say the same thing in a way that is more sparing of the 
reader's time and effort.

	Thanks,
	Paul

On 2/16/2011 6:46 PM, James M. Polk wrote:
> To answer your question above - I think you have it right. I think the
> only real play (or uncertainty) is when there is no Geolocation header
> field, and what to do when there is one of the three possibilities for
> the Geolocation-Routing.
>
>>>> not intended to be some kind of security mechanism that would
>>>> "retransmission-allowed" is set to "no" at a PIDF level) as long as
>>>> it takes place as in the context of normal SIP operations, be it
>>>> bare forwarding, retargeting or what have you.
>>>>
>>>> Jon Peterson
>>>> NeuStar, Inc.
>>>>