Subject: Re: [sipcore] draft-ietf-sipcore-location-conveyance-04

From: Paul Kyzivat <[email-masked]>
Date: Tue, 26 Oct 2010 21:36:02 -0400

I took a quick look at the new version, and it seems to have cleanup a 
lot. But there *still* seems to be a problem with the syntax. (Interplay 
between ABNF and text.) From the text, I find:

    The placement of the "routing-allowed" header field parameter,
    strongly encouraged by [RFC5606], is outside the locationValue, and
    MUST always be last in the header field value. The routing-allowed
    parameter MUST be present, even when no locationValue is present.

This is questionably supported by the ABNF:

    Geolocation-header = "Geolocation" HCOLON Geolocation-value
    Geolocation-value  = ( locationValue [ COMMA locationValue ] )
                         / routing-param
    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)
    routing-param      =  "routing-allowed" EQUAL "yes" / "no"

It only works if you presume that there are separate occurrences of 
GeoLocation-header in the message, one with just locations, another with 
just the routing-param. The routing-param certainly can't be "last in 
the header field value" except in the degenerate sense, since it must be 
first and only in a Geolocation-header.

Below are some specific cases - both valid and invalid. In each case I 
show some headers bracketed by "...". That is intended to mean other 
headers in a message, but all in the same message. (And when I show 
multiple headers, there could be other non-geoloc headers interleaved.)

* The following are legal according to the above, and probably within 
expected usage:

...
Geolocation: cid:[email-masked]
Geolocation: routing-allowed=yes
...

...
Geolocation: cid:[email-masked],cid:[email-masked]
Geolocation: routing-allowed=yes
...

...
Geolocation: routing-allowed=no
...

* IIUC the following are allowed by the above both syntactically and 
according to the text, but is presumably not *intended* to be valid. 
(Its legal because the in each instance of Geolocation-header its last.)

...
Geolocation: routing-allowed=no
Geolocation: routing-allowed=yes
...

The following is also allowed - I don't know if its intended or not:

...
Geolocation: routing-allowed=yes
Geolocation: cid:[email-masked],cid:[email-masked]
...

* The following is allowed by the ABNF though disallowed by the text:

...
Geolocation: cid:[email-masked],cid:[email-masked]
Geolocation: cid:[email-masked]
...

* The following is *not* allowed by the ABNF. I suspect it might be 
intended to be valid, but I'm far from sure about it:

...
Geolocation: cid:[email-masked],routing-allowed=yes
...

In addition to that, the text is very explicit that:

    The routing-allowed
    parameter MUST be present, even when no locationValue is present.

but then it says:

    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.

So its required, but we have rules to follow if its missing. But I don't 
understand how it *can* be required, since the sender of the request may 
not understand/support Geolocation and so won't include it. ISTM that in 
reality its only *required* if the is a locationValue present, and is 
otherwise optional. In that case, an intermediary that adds a 
locationValue not only MAY, but presumably MUST add a missing 
routing-param if it adds a locationValue.

I have never understood why the routing-param is required to be last. 
And as my examples show, its difficult/impossible to enforce this in ABNF.

	Thanks,
	Paul

---

From: "Thomson, Martin" <[email-masked]>
Date: Wed, 27 Oct 2010 12:06:55 +0800

> And as my examples show, its difficult/impossible to enforce this in

If "routing-allowed" is mandatory, it IS possible:

    Geolocation-header = "Geolocation" HCOLON Geolocation-value
    Geolocation-value  = [ locationValue [ COMMA locationValue ] COMMA ]
                         routing-param

It's a little strange, but it does work.  Especially if you also add text that states there can be only one GeoLocation header?

(The other thing that I find strange is the fact that there can be zero, one or two locationValue parts.  This is confusing for computer scientists who can only count: zero, one, many.)

--Martin

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 27 Oct 2010 08:53:42 -0400

I was going to suggest alternative ABNF in my prior posting, but I ran 
out of time and wanted to send it. So here is a proposal:

    Geolocation-header = "Geolocation" HCOLON Geolocation-value
			*( COMMA Geolocation-value)
    Geolocation-value  = locationValue / routing-param
    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)
    routing-param      =  "routing-allowed" EQUAL "yes" / "no"

This syntax is consistent with 3261 section 7.3:

    Specifically, any SIP header whose grammar is of the form

       header  =  "header-name" HCOLON header-value *(COMMA header-value)

    allows for combining header fields of the same name into a comma-
    separated list.

(That means there is an equivalence between multiple occurrences of the 
header, and a single header with multiple fields.)

(I would prefer to have a separately named header for the routing-param, 
but I think we are too far down the river to make that change now.)

The above is overly forgiving, in that it permits zero or more 
locationURIs and zero or more routing-params. That then needs to be 
tightened up with text. I think the text needs to say, more or less:

- if there are any locationURIs in a sip request,
   then a routing-param MUST be present in the request
- there MUST NOT be more than one routing-param present in a
   sip request.
- there MUST NOT be more than two locationURIs in a sip request
   (if there is really a reason for such a restriction)

Actually the MUST requirement on the routing-param also seems 
unmotivated to me. Why not just a default of routing-allowed=no?

	Thanks,
	Paul

---

From: "James M. Polk" <[email-masked]>
Date: Wed, 27 Oct 2010 13:32:09 -0500

Paul

in-line

At 08:36 PM 10/26/2010, Paul Kyzivat wrote:
>I took a quick look at the new version, and it seems to have cleanup 
>a lot. But there *still* seems to be a problem with the syntax. 
>(Interplay between ABNF and text.) From the text, I find:
>

the above, I believe - but am open to be corrected by those better at 
ABNF syntax that I, says

- the Geolocation header can optionally have one or more locationValues
        - which are where the location URIs go

- but that the Geolocation header *will* have a routing-param
        - which is the "routing-allowed" paramter that RFC 5606 wanted included

The text of the ID then says that only zero, one or two 
locationValues are allowed, which we all agreed to in Maastricht (in 
SIPCORE and ECRIT/GEOPRIV).

>GeoLocation-header in the message, one with just locations, another 
>with just the routing-param.

I don't get that part of your point, but I guess Martin's next 
message says I need to add a "COMMA" after the ']' but before the 
')'. Would this satisfy your issue?

>The routing-param certainly can't be "last in the header field 
>value" except in the degenerate sense, since it must be first and 
>only in a Geolocation-header.

If the routing-param was intended to be first, wouldn't it appear 
first on this line?

>    Geolocation-value  = ( locationValue [ COMMA locationValue ] )

but it doesn't, so I'm confused.

>Below are some specific cases - both valid and invalid. In each case 
>I show some headers bracketed by "...". That is intended to mean 
>other headers in a message, but all in the same message. (And when I 
>show multiple headers, there could be other non-geoloc headers interleaved.)
>
>* The following are legal according to the above, and probably 
>within expected usage:
>
>...

to get this above example "allowed", would I correct the existing ABNF to be

>    Geolocation-value  = ( locationValue [ COMMA locationValue ] COMMA )
>                         / routing-param

?

>So its required, but we have rules to follow if its missing. But I 
>don't understand how it *can* be required, since the sender of the 
>request may not understand/support Geolocation and so won't include it.

What we're trying to do here is explicitly give instructions to SIP 
intermediary implementers to include the routing-allowed parameter if 
one isn't present, with a default value of =no.

>ISTM that in reality its only *required* if the is a locationValue 
>present, and is otherwise optional.

which is how most would read it if ...

>    value with a RECOMMENDED value of "no" by default.

... weren't present in the document. But, there is no permission to 
allow SIP intermediaries to add the routing-allowed parameter, which 
we wanted to cover.

>In that case, an intermediary that adds a locationValue not only 
>MAY, but presumably MUST add a missing routing-param if it adds a 
>locationValue.

We can get there (i.e., allow this) without stating this is a MUST, can't we?

>I have never understood why the routing-param is required to be last.

maybe it doesn't need to be, but it certainly is easier for 
monitoring/reading human to find if it is last when looking at a decode.

---

From: "James M. Polk" <[email-masked]>
Date: Wed, 27 Oct 2010 13:35:22 -0500

At 11:06 PM 10/26/2010, Thomson, Martin wrote:
>It's a little strange, but it does work.  Especially if you also add 
>text that states there can be only one GeoLocation header?
>
>(The other thing that I find strange is the fact that there can be 
>zero, one or two locationValue parts.

The pre-Maastricht proposal was to limit to zero or one 
locationValue, but that blew up Richard's rough-loc ID (which defines 
a coarse location for routing, and accurate location for endsystems). 
This is why we made the compromise of allowing a second 
locationValue. If we allow 'many', we need to bloat the doc with all 
that "inserter=" and "inserted-by" crud, and we don't want that, do we?

james

>This is confusing for computer scientists who can only count: zero, 
>one, many.)
>
>--Martin

---

From: "James M. Polk" <[email-masked]>
Date: Wed, 27 Oct 2010 13:49:26 -0500

At 07:53 AM 10/27/2010, Paul Kyzivat wrote:
>I was going to suggest alternative ABNF in my prior posting, but I 
>ran out of time and wanted to send it. So here is a proposal:
>

this is what I had before -04, and was told to correct it to what is in -04.

I'm getting so many corrections (i.e., what I currently have is 
considered wrong by someone), I can't tell who's more knowledgeable about this.

Paul, since you're WGC, I'm going to go with this until your (or 
Adam) tell me how to change it.

In other words, it has to come through either of you before I change 
what's in the next version, no matter who tells me (other than my 
co-conspirators writting this).

>(That means there is an equivalence between multiple occurrences of 
>the header, and a single header with multiple fields.)
>
>(I would prefer to have a separately named header for the 
>routing-param, but I think we are too far down the river to make 
>that change now.)
>

that is the default value already in text, but we want to limit this 
to avoid any possible misinterpretation which allows a person's 
(i.e., Target's) location to inadvertently be advertised to any and 
possibly all 3rd parties.

James

>>It's a little strange, but it does work.  Especially if you also 
>>add text that states there can be only one GeoLocation header?
>>
>>zero, one or two locationValue parts.  This is confusing for 
>>computer scientists who can only count: zero, one, many.)
>>
>>--Martin

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 27 Oct 2010 19:50:29 -0400

I have a bunch inline here.
This supersedes my earlier suggested ABNF change.

On 10/27/2010 2:32 PM, James M. Polk wrote:
>> lot. But there *still* seems to be a problem with the syntax.

The above says *a* Geolocation header can have
- one or two locationValues
- OR one routing-param

(The slash means OR)

But it doesn't state that the Geolocation header itself can appear only 
once. And obviously if the goal is to have a locationValue AND a 
routing-param in the message, then with the above syntax at least TWO 
Geolocation headers will be required.

> - which is the "routing-allowed" paramter that RFC 5606 wanted included

Since the slash means OR, it doesn't mean it *will*.

> The text of the ID then says that only zero, one or two locationValues
> are allowed, which we all agreed to in Maastricht (in SIPCORE and
> ECRIT/GEOPRIV).
>
> I don't get that part of your point, but I guess Martin's next message
> says I need to add a "COMMA" after the ']' but before the ')'. Would
> this satisfy your issue?

Adding the COMMA and removing the slash would require the routing-param, 
and would separate it from the location-value. But then if you only 
wanted the routing-param without any locationValues you would have to write:

Geolocation:,routing-allowed=no

which is at least a bit weird, which I think is what Martin meant.

>> The routing-param certainly can't be "last in the header field value"
>> except in the degenerate sense, since it must be first and only in a
>> Geolocation-header.
>
> If the routing-param was intended to be first, wouldn't it appear first
> on this line?

My point was that the syntax as written only allows routing-param by 
itself in a geolocation-header. E.g.

Geolocation:routing-allowed=no

It can't share a single Geolocation header with a locationValue. Hence 
it is *both* first and last in that header.

> but it doesn't, so I'm confused.

Again, the slash means OR. So you have:

  Geolocation-value = ( locationValue [ COMMA locationValue ] )
OR
  Geolocation-value = routing-param

(Though you can't write it that way in ABNF.

>> Geolocation-value = ( locationValue [ COMMA locationValue ] COMMA )

No. *That* would allow all of the following but not the example above:

  Geolocation: cid:[email-masked],
  Geolocation: cid:[email-masked],cid:[email-masked],
  Geolocation: routing-allowed=yes

> one isn't present, with a default value of =no.

I went back and reread the section containing this text. It is in a 
section explicitly about this header. So on reflection I suppose the 
"MUST be present" was intended to imply "in the Geolocation *header". I 
took it to mean "in the request".

Requiring it to be in the header only makes sense if there can be at 
most one header. And then it only makes sense if the syntax is altered 
to allow both the routing-parameter and the locationValue in the same 
header.

> allow SIP intermediaries to add the routing-allowed parameter, which we
> wanted to cover.

I'm still confused. Let me state what I think you are after:

- a request may or may not contain a Geolocation header
- a request may not contain more than one Geolocation header
- a Geolocation header MUST contain a routing-param
- a Geolocation header Must contain zero, one, or two locationValues
- you prefer the routing-param to be the last field in the header
- a proxy MAY add a Geolocation header if one is not present
   (in which case it MUST include a routing-param)
- a proxy MAY add a locationValue to an existing Geolocation header
   if it doesn't already have two locationValues. (And I guess it
   could add two if there initially were none.)

And you would like ABNF that is consistent with the above.

I'm going to give you some alternatives that should all be syntactically 
correct. I'll give you one that meets the above, and some others that 
may be more appealing variations. Then we can see which people prefer.

1) The following tries to meet the requirements I spelled out above:

    Geolocation-value  = locationValue [ COMMA locationValue]
                         COMMA routing-param

    This must be accompanied by text stating that there MUST be at most
    one Geolocation-header in a request.

2) The following is similar to (1), but allows more than two
    'locationValue's

    Geolocation-value  = *(locationValue COMMA) routing-param

    The same wording is required with it

3) The following is a copy from my earlier posting:

4) The following is a more radical change:

    Geolocation-header = "Geolocation" HCOLON locationValue
                         [ COMMA locationValue ]

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

    This one needs to be accompanied by text stating that each of
    Geolocation-header and Georouting-header may appear at most once
    in a request, and that if Georouting-header is absent it defaults
    to "no".

5) A more lenient variant on (4):

    Geolocation-header = "Geolocation" HCOLON locationValue
                         *( COMMA locationValue )

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

    This one needs to be accompanied by text stating that
    Georouting-header may appear at most once in a request, and that
    if Georouting-header is absent it defaults to "no".

    (The Geolocation-header can appear zero or more times.)

    This is only preferred to (4) if more than two locationValues
    are acceptable. ISTM that once we allowed two, allowing more
    makes sense, with the same limitations imposed with two - that
    its up to the recipient to figure out which to use.

Of the above, I technically and esthetically prefer (5) - or (4) if the 
limitation to two URIs is important. I see no reason to *require* the 
routing-param if the default is understood to be "no".

Pragmatically I think I prefer (1) - its the least variation from what 
has been recently discussed that, IMO, makes any sense.

>> In that case, an intermediary that adds a locationValue not only MAY,
>> but presumably MUST add a missing routing-param if it adds a
>> locationValue.
>

---

From: "James M. Polk" <[email-masked]>
Date: Wed, 27 Oct 2010 23:10:42 -0500

>I have a bunch inline here.

I'll say   ;-)

>This supersedes my earlier suggested ABNF change.

ack

>But it doesn't state that the Geolocation header itself can appear 
>only once. And obviously if the goal is to have a locationValue AND 
>a routing-param in the message, then with the above syntax at least 
>TWO Geolocation headers will be required.
>
>Adding the COMMA and removing the slash would require the 
>routing-param, and would separate it from the location-value. But 
>then if you only wanted the routing-param without any locationValues 
>you would have to write:
>
>It can't share a single Geolocation header with a locationValue. 
>Hence it is *both* first and last in that header.
>
>"MUST be present" was intended to imply "in the Geolocation 
>*header". I took it to mean "in the request".
>
>most one header. And then it only makes sense if the syntax is 
>altered to allow both the routing-parameter and the locationValue in 
>the same header.
>

of what you have, this one is one I hadn't considered important, but 
if that gets everything aligned, then I'm all for adding it in.

>And you would like ABNF that is consistent with the above.

with the one caveat, yes.

>I'm going to give you some alternatives that should all be 
>syntactically correct. I'll give you one that meets the above, and 
>some others that may be more appealing variations. Then we can see 
>which people prefer.
>

I hadn't even thought that was possible, but seeing it, I'm amazed I 
didn't try it

(i.e., it's another classic "I could've had a v8" moment)...

I'm not as smart as you, Paul  <:-|

>    one Geolocation-header in a request.

you've sold me on this one (and yes, I examined all the others before 
jumping on this first one!). Do others have strong opinions about why not #1?

thank you for this!

James

>Of the above, I technically and esthetically prefer (5) - or (4) if 
>the limitation to two URIs is important. I see no reason to 
>*require* the routing-param if the default is understood to be "no".
>
>Pragmatically I think I prefer (1) - its the least variation from 
>what has been recently discussed that, IMO, makes any sense.
>
>

---

From: Anders Kristensen <[email-masked]>
Date: Wed, 27 Oct 2010 21:52:37 -0700

I haven't really followed the discussion closely but I'll say this 
anyway. Many header fields are of a form similar to Geolocation, 
essentially lists of URI, and allow for parameters. But I think the 
parameters are pretty much always associated with individual entries in 
the list and may be present for more than one.

 From what I can tell, in the case of Geolocation, the routing-allowed 
param is not really attached to any particular entry in the list 
suggesting that maybe it doesn't belong in the same header field. I 
think that's the thinking that lead Paul to options 4 or 5 which seem 
much preferable to me. That allows Geolocation to fit the text in RFC 
3261 that talks about combining header fields:

    Specifically, any SIP
    header whose grammar is of the form

Granted, there's no rule that says that header fields with 
comma-separated values *must* fit the above grammar but ISTM that it's a 
pretty established pattern which is worth observing.

Thanks,
Anders

On 10/27/2010 9:10 PM, James M. Polk wrote:
>> only once. And obviously if the goal is to have a locationValue AND a
>> routing-param, and would separate it from the location-value. But then
>> if you only wanted the routing-param without any locationValues you
>> would have to write:
>>
>> "MUST be present" was intended to imply "in the Geolocation *header".
>> I took it to mean "in the request".
>>
> of what you have, this one is one I hadn't considered important, but if
> that gets everything aligned, then I'm all for adding it in.
>
>> the limitation to two URIs is important. I see no reason to *require*
>> the routing-param if the default is understood to be "no".
>>
> _______________________________________________
> sipcore mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/sipcore
>

---

From: "Elwell, John" <[email-masked]>
Date: Thu, 28 Oct 2010 12:38:16 +0200

Yes, 4 looks good, but I could live with 1.

John

> -----Original Message-----
> From: [email-masked]
> [mailto:[email-masked]] On Behalf Of Anders Kristensen
> Sent: 28 October 2010 05:53
> To: [email-masked]
> Subject: Re: [sipcore] draft-ietf-sipcore-location-conveyance-04
>
> locationValues
> >>> to get this above example "allowed", would I correct the
> existing ABNF
> >>> to be
> >>>
> > jumping on this first one!). Do others have strong opinions
> about why
> > not #1?
> >
> > thank you for this!
> >
> > James
> >
> >
> >>> We can get there (i.e., allow this) without stating this
> is a MUST,
> >>> can't we?
> >>
> >>>> And as my examples show, its difficult/impossible to
> enforce this in
> >>>> ABNF.
> >>>>
> >>>> Thanks,
> >>>> Paul
> >>>
> >

---

From: "James M. Polk" <[email-masked]>
Date: Thu, 28 Oct 2010 19:51:43 -0500

>Yes, 4 looks good, but I could live with 1.

I think this has become #1 of two major open issues to address in 
Beijing (along with the supported and unsupported URI schemes and 
their respective possible error codes, as 2a and 2b).

James

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 29 Oct 2010 09:04:29 -0400

Its unclear to me how many people have opinions on this.
It certainly can be one of the discussion points.
If you like, I can make up some slides on the alternatives for use at 
the meeting.

But it will be good if we can reduce the number of alternatives between 
now and then. ISTM there are basically two decisions to make about the 
syntax:

- at most two URIs, or an unlimited number
- routing-param part of same header, or a separate header

The first of those is a real functionality discussion.
(Or a computer science discussion of whether there is a number bigger 
than one other than "many".)

The second is partly esthetic, and partly a technical issue for those 
writing sip parsers. Making it all one header causes it to be a one-off 
from a parser perspective.

	Thanks,
	Paul

On 10/28/2010 8:51 PM, James M. Polk wrote:
> Beijing (along with the supported and unsupported URI schemes and their
> respective possible error codes, as 2a and 2b).
>
> James
>
>
>> John
>>

---

From: "James M. Polk" <[email-masked]>
Date: Fri, 29 Oct 2010 14:44:44 -0500

>Its unclear to me how many people have opinions on this.

what's clear to me is people want fixed what is not subjective, i.e., 
the ABNF. From that, we do need to determine which of the 5 proposals 
you put out is the way forward.

>If you like, I can make up some slides on the alternatives for use 
>at the meeting.
>
>But it will be good if we can reduce the number of alternatives 
>between now and then. ISTM there are basically two decisions to make 
>about the syntax:
>

I agree with distilling it down to these two points wrt to the syntax.

The first point is fairly easy (I think) if we're focused on 
addressing that one (at a time).

The second point you bring up is very new (i.e., the idea of separate 
headers for these two indications). Once we focus on that idea, I 
think we can come to a conclusion without much difficulty.

A third (multipart) point to bring up is related to the first point, 
if there are multiple URIs,

   3a - do all recipients have to implement one or both URI scheme 
sets (i.e., SIP-based and HTTP-based), or just to one mandatory (and 
one should or may), or do we not mandate anything here (which has 
interoperability and effective communications implications).

   3b - aside from independent of 3a, do we specify a specific error 
code for "URI scheme not supported, send (a specific) other URI scheme".

3b is exactly what John Elwell and I have been discussing, and 
involves 5 new, very specific 4XX level errors with really no room 
for misinterpretation:

 > 401 "URI scheme not supported - send SIP:URI"
 > 402 "URI scheme not supported - send SIPS:URI"
 > 403 "URI scheme not supported - send PRES:URI"
 > 404 "URI scheme not supported - send HTTP:URI"
 > 405 "URI scheme not supported - send HTTPS:URI"

I know my coauthor will hyperventilate on this possibility because he 
wants as few error codes as is possible, but I think these are rather 
hard to argue against due to their specific meaning, and their 
actionable result (

   - the UAC either sends a new SIP request with the requested
     URI scheme, or location isn't sent because that URI scheme
     isn't available to send).

The UAC knows exactly what to do with this error, and if it doesn't 
send a location URI in the subsequent request, the UAS knows that URI 
scheme wasn't in the UAC to send.

If the UAC can send the requested URI scheme, all's fine.

The UAC can also make the choice to send a PIDF-LO (if it can) as a fall-back.

>(Or a computer science discussion of whether there is a number 
>bigger than one other than "many".)
>
>The second is partly esthetic, and partly a technical issue for 
>those writing sip parsers. Making it all one header causes it to be 
>a one-off from a parser perspective.

I wish I knew more about this during the RFC 5606 debate, as that doc 
would have said something about necessitating a new SIP header to 
accomplish what it suggested, and we wouldn't be getting into this 
topic so (stickin`) late in the game.

That said, location-conveyance is still an ID, so it's changeable- if 
we have consensus that's what's best.

I think it might not be so hard to include this new header, as it'll 
have a rule that if an LR receives a SIP request with a SIP 
Geolocation header, that LR MUST look for and obey the policy flag 
set by the Geolocation-routing header value (or whatever we call the header).

James