Subject: Re: [Geopriv] draft agenda: GEOPRIV @ IETF 70

From: "Stark, Barbara" <[email-masked]>
Date: Wed, 21 Nov 2007 12:16:56 -0500

Robert,
I think the HELD identity extensions is important. It's needed for LIS to LIS communication, which is critical where the entity who assigns the public IP address is not the same as the access provider. 
Barbara

----- Original Message -----
From: Robert Sparks <[email-masked]>
To: GEOPRIV <[email-masked]>
Sent: Tue Nov 20 15:09:03 2007
Subject: [Geopriv] draft agenda: GEOPRIV @ IETF 70

Folks -

We have 2.5 hrs in Vancouver (Friday morning). Based on our chartered  
work, list discussions, and agenda requests, here's the agenda I'm  
planning to follow:

15m	Administrivia	Chairs
30m	http-location-delivery	Mary (<- Lets finish this one!)
20m	Finishing geopriv-policy	Hannes/Cullen
30m	LIS Discovery	James W
10m	l7lcp-ps	Hannes
20m	pidf-lo-dynamic	Henning
15m	dhcp-lbyr-uri-option	James P
10m	civicaddresses-austria	Karl
20m	Uncertainty and Confidence	James W
10m	HELD Dereference	James W

As usual, we have many other requests to talk about other things -  
please take those to the list for now.

This is a draft agenda and we can change it. Let me know if you think  
I've missed something important.

RjS

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

*****

The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential, proprietary, and/or privileged material. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon this information by persons or entities other than the intended recipient is prohibited. If you received this in error, please contact the sender and delete the material from all computers. GA623

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

---

From: "Marc Linsner" <[email-masked]>
Date: Wed, 21 Nov 2007 12:54:14 -0500

Barbara,
 
Remind me again why this can't be accomplished by putting the identifier in
the uri?  ex: [email-masked]
 
Thanks,
 
-Marc-

  _____  

From: Stark, Barbara [mailto:[email-masked]] 
Sent: Wednesday, November 21, 2007 12:17 PM
To: [email-masked]; [email-masked]
Subject: Re: [Geopriv] draft agenda: GEOPRIV @ IETF 70

Robert,
I think the HELD identity extensions is important. It's needed for LIS to
LIS communication, which is critical where the entity who assigns the public
IP address is not the same as the access provider.
Barbara

----- Original Message -----
From: Robert Sparks <[email-masked]>
To: GEOPRIV <[email-masked]>
Sent: Tue Nov 20 15:09:03 2007
Subject: [Geopriv] draft agenda: GEOPRIV @ IETF 70

Folks -

15m     Administrivia   Chairs

RjS

*****

The information transmitted is intended only for the person or entity to
which it is addressed and may contain confidential, proprietary, and/or
privileged material. Any review, retransmission, dissemination or other use
of, or taking of any action in reliance upon this information by persons or
entities other than the intended recipient is prohibited. If you received
this in error, please contact the sender and delete the material from all
computers. GA623

---

From: "Winterbottom, James" <[email-masked]>
Date: Wed, 21 Nov 2007 14:42:04 -0600

Marc,

Suppose the identifier is a MAC address, since this has no formal URI
representation  then what?

Suppose HELD is bound to a transport other than HTTP, such as in
http://tools.ietf.org/html/draft-thomson-geopriv-held-beep-01, how are
the parameters simply added to the URI? Does it even make sense to do
so?

http://www.ietf.org/internet-drafts/draft-ietf-geopriv-l7-lcp-ps-06.txt
indicates that identifiers other than IP address will be required in
some scenarios.

http://www.ietf.org/internet-drafts/draft-ietf-ecrit-phonebcp-03.txt
identifies the need, in some situations, for an outbound proxy to insert
location on-behalf-of the calling device. In this situation using HELD
requires a formal way to express how the Device is being identified, and
what the identifier represents.

Please read the draft
http://tools.ietf.org/html/draft-winterbottom-geopriv-held-identity-exte
nsions-04 before jumping on to the attack.

There are several architectures and deployments well underway that
require this work. The ABNF definitions in the extensions draft have
applicability beyond just HELD. I don't see a need to delay this work
further.

Cheers

James

________________________________

From: Marc Linsner [mailto:[email-masked]] 
Sent: Thursday, 22 November 2007 4:54 AM
To: 'Stark, Barbara'; [email-masked]; [email-masked]
Subject: RE: [Geopriv] draft agenda: GEOPRIV @ IETF 70

Barbara,

Remind me again why this can't be accomplished by putting the identifier
in the uri?  ex: [email-masked]

Thanks,

-Marc-

	
________________________________

	Robert,
	I think the HELD identity extensions is important. It's needed
for LIS to LIS communication, which is critical where the entity who
assigns the public IP address is not the same as the access provider.
	Barbara
	
	----- Original Message -----
	From: Robert Sparks <[email-masked]>
	To: GEOPRIV <[email-masked]>
	Sent: Tue Nov 20 15:09:03 2007
	Subject: [Geopriv] draft agenda: GEOPRIV @ IETF 70
	
	Folks -
	
	We have 2.5 hrs in Vancouver (Friday morning). Based on our
chartered 
	work, list discussions, and agenda requests, here's the agenda
I'm 
	planning to follow:
	
	15m     Administrivia   Chairs
	
	As usual, we have many other requests to talk about other things
- 
	please take those to the list for now.
	
	This is a draft agenda and we can change it. Let me know if you
think 
	I've missed something important.
	
	RjS

	*****

	The information transmitted is intended only for the person or
entity to which it is addressed and may contain confidential,
proprietary, and/or privileged material. Any review, retransmission,
dissemination or other use of, or taking of any action in reliance upon
this information by persons or entities other than the intended
recipient is prohibited. If you received this in error, please contact
the sender and delete the material from all computers. GA623

------------------------------------------------------------------------------------------------
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]
_______________________________________________
Geopriv mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/geopriv

---

From: <[email-masked]>
Date: Wed, 21 Nov 2007 15:45:22 -0500

For the record,

I concur with Barbara on the importance of the held-identity-extensions draft. Having a timeslot on the agenda in Vancouver would be appreciated.

Thanks,

Guy Caron

De : Stark, Barbara [mailto:[email-masked]] 
Envoyé : 21 novembre 2007 12:17
À : [email-masked]; [email-masked]
Objet : Re: [Geopriv] draft agenda: GEOPRIV @ IETF 70

Robert,

----- Original Message -----
From: Robert Sparks <[email-masked]>
To: GEOPRIV <[email-masked]>
Sent: Tue Nov 20 15:09:03 2007
Subject: [Geopriv] draft agenda: GEOPRIV @ IETF 70

Folks -

15m     Administrivia   Chairs

RjS

*****

---

From: Hannes Tschofenig <[email-masked]>
Date: Wed, 21 Nov 2007 21:54:14 +0100

Hi Marc,

I am interested in the case where the SIP obtains location information 
and/or a LbyR from the LIS. I believe that the two entities, namely the 
SIP proxy and the LIS, will not be co-located in realistic deployments. 
A simple protocol is needed. The HELD identity extension document 
provides this functionality.

Ciao
Hannes

Marc Linsner wrote:
> ------------------------------------------------------------------------
>

---

From: "James M. Polk" <[email-masked]>
Date: Wed, 21 Nov 2007 15:25:55 -0600

James

You can reply without being so incredibly defensive, can't you?

At 02:42 PM 11/21/2007, Winterbottom, James wrote:
>Content-class: urn:content-classes:message
>Content-Type: multipart/alternative;
>         boundary="----_=_NextPart_001_01C82C7E.FAF514D5"
>
>Marc,
>
>Suppose the identifier is a MAC address, since this has no formal 
>URI representation  then what?
><http://tools.ietf.org/html/draft-thomson-geopriv-held-beep-01>http://tools.ietf.org/html/draft-thomson-geopriv-held-beep-01, 
>how are the parameters simply added to the URI? Does it even make 
>sense to do so?
>
><http://www.ietf.org/internet-drafts/draft-ietf-geopriv-l7-lcp-ps-06.txt>http://www.ietf.org/internet-drafts/draft-ietf-geopriv-l7-lcp-ps-06.txt 
><http://www.ietf.org/internet-drafts/draft-ietf-ecrit-phonebcp-03.txt>http://www.ietf.org/internet-drafts/draft-ietf-ecrit-phonebcp-03.txt 
>identifies the need, in some situations, for an outbound proxy to 
>insert location on-behalf-of the calling device. In this situation 
>using HELD requires a formal way to express how the Device is being 
>identified, and what the identifier represents.
>
>Please read the draft 
><http://tools.ietf.org/html/draft-winterbottom-geopriv-held-identity-extensions-04>http://tools.ietf.org/html/draft-winterbottom-geopriv-held-identity-extensions-04 
>before jumping on to the attack.
>
>applicability beyond just HELD. I don't see a need to delay this work further.
>
>Cheers
>James
>
>
>----------
>Remind me again why this can't be accomplished by putting the 
>identifier in the uri?  ex: 
><mailto:[email-masked]>[email-masked]
>
>Thanks,
>
>-Marc-
>
>
>
>
>----------
>I think the HELD identity extensions is important. It's needed for 
>LIS to LIS communication, which is critical where the entity who 
><https://www1.ietf.org/mailman/listinfo/geopriv>https://www1.ietf.org/mailman/listinfo/geopriv
>
>*****
>
>dissemination or other use of, or taking of any action in reliance 
>upon this information by persons or entities other than the intended 
>recipient is prohibited. If you received this in error, please 
>contact the sender and delete the material from all computers. GA623
>
>
>
>

---

From: "James M. Polk" <[email-masked]>
Date: Wed, 21 Nov 2007 15:30:53 -0600

At 02:54 PM 11/21/2007, Hannes Tschofenig wrote:
>Hi Marc,
>
>I am interested in the case where the SIP obtains location 
>information and/or a LbyR from the LIS. I believe that the two 
>entities, namely the SIP proxy and the LIS, will not be co-located 
>in realistic deployments. A simple protocol is needed. The HELD 
>identity extension document provides this functionality.

To a UA, so does
http://www.ietf.org/internet-drafts/draft-polk-geopriv-dhcp-lbyr-uri-option-02.txt

>>From: Stark, Barbara [mailto:[email-masked]] Sent: Wednesday, 
>>November 21, 2007 12:17 PM
>>chartered work, list discussions, and agenda requests, here's the 
>>agenda I'm planning to follow:
>>
>>15m     Administrivia   Chairs
>>think I've missed something important.
>>
>>RjS
>>
>>

---

From: "Winterbottom, James" <[email-masked]>
Date: Wed, 21 Nov 2007 15:33:14 -0600

Hi James,

Sorry, I was just trying to present the use-case and document the
existing requirements. Comes about as a force of habit with this WG...
*8)

Cheers
James

> -----Original Message-----
> From: James M. Polk [mailto:[email-masked]]
> Sent: Thursday, 22 November 2007 8:26 AM
> To: Winterbottom, James; Marc Linsner; Stark, Barbara;
> [email-masked]; [email-masked]
> ><http://tools.ietf.org/html/draft-thomson-geopriv-held-beep-
> 01>http://tools.ietf.org/html/draft-thomson-geopriv-held-beep-01,
> ><http://www.ietf.org/internet-drafts/draft-ietf-geopriv-l7-lcp-ps-
>
06.txt>http://www.ietf.org/internet-drafts/draft-ietf-geopriv-l7-lcp-ps-
> 06.txt
> ><http://www.ietf.org/internet-drafts/draft-ietf-ecrit-phonebcp-
> 03.txt>http://www.ietf.org/internet-drafts/draft-ietf-ecrit-phonebcp-
> 03.txt
> ><http://tools.ietf.org/html/draft-winterbottom-geopriv-held-identity-
>
extensions-04>http://tools.ietf.org/html/draft-winterbottom-geopriv-held
-
> identity-extensions-04
><https://www1.ietf.org/mailman/listinfo/geopriv>https://www1.ietf.org/m
ai
> lman/listinfo/geopriv
>-----------------------------------------------------------------------
--
> -----------------------
>-----------------------------------------------------------------------
--
> -----------------------

---

From: "James M. Polk" <[email-masked]>
Date: Wed, 21 Nov 2007 15:52:11 -0600

Well then, this WG voted in Prague for a layer 3 LbyR delivery 
mechanism, yet you voiced strong opposition for my draft which 
proposes this in DHCP, which is a protocol Geopriv already has 2 
Standards Track RFCs supporting.  I personally heard your loud hum 
against moving this ID forward as a WG item, because you want a more 
detailed architecture supporting how DHCP can deliver a URI to an 
endpoint. This is something neither RFC 3825 or RFC 4776 have in 
place, yet this ID is burdened with this responsibility in your 
mind.  I don't think there's precedent for that opinion.

You even said you don't think anything in DHCP should progress in 
another email.

So, we're left to this little problem of the WG agreeing in Prague a 
DHCP solution is necessary for this WG, and you acting against 
anything DHCP (contrary to the WG's existing wishes).

I say all this, because the WG thinks there is a use-case for DHCP to 
do this, and I have this document  (just like you mention below)
http://www.ietf.org/internet-drafts/draft-polk-geopriv-dhcp-lbyr-uri-option-02.txt
with one remaining open issue (I added your request for a "Valid-for" 
timer) - it's your mandate it include an architecture (unlike the 
other DHCP RFCs have from this group) that doesn't involve a DHCP 
Protocol, so what's the difference? Should I take this personal too? 
As a force of habit with this WG?

BTW - wrt this revised ID -- I know I have to work specifying how to 
prevent less trustworthy URI types from being allowed.  I'm working 
with the APPS AD on this.

James

At 03:33 PM 11/21/2007, Winterbottom, James wrote:
> > ><http://tools.ietf.org/html/draft-thomson-geopriv-held-beep-> 
> > ><http://www.ietf.org/internet-drafts/draft-ietf-geopriv-l7-lcp-ps->
> > ><http://www.ietf.org/internet-drafts/draft-ietf-ecrit-phonebcp-> 
> > ><http://tools.ietf.org/html/draft-winterbottom-geopriv-held-identity->

---

From: Robert Sparks <[email-masked]>
Date: Wed, 21 Nov 2007 15:53:00 -0600

Hi folks -

For _every_ post you send to this list, please look at the subject  
line and make sure it's still on topic.

The last several messages posted to _this_ topic are going to be  
really hard to find in the archive later.

RjS

---

From: "Winterbottom, James" <[email-masked]>
Date: Wed, 21 Nov 2007 16:25:21 -0600

James,

You are spot in when you say I don't believe that DHCP is a suitable
mechanism for providing location information. I don't! That aside, there
are specifications that provide this, and some require corrections.

None of this stops the legitimacy of needing identity extensions in
HELD, both for the Device to assist the LIS, and for proxies to specify
a Target identity to the LIS. Clear use cases exist and requirements for
this are specified. What is the big deal?

I don't believe that I have suggested that your draft be removed form
the agenda to make way for presenting identity extensions, so I am not
sure that I understand your overly defensive response. Perhaps we don't
need 30 minutes for LIS Discovery, I am hoping that there isn't a lot of
contention in this draft at all.

I would point that LbyR over DHCP was not the only new thing to come out
of the Prague meeting, LIS to LIS requirements came out of the L7 LCP
problem statement to be specified in their own document as this was
something that the WG was interested in. Steve Norreys and I wrote this
draft, and it has had very little feedback or air time.

Given the volume of drafts in georpiv, I have personally co-authored 13,
I would suggest that an Interim meeting is in order to address some of
these issues (late January in Australia is lovely).

Cheers
James 

> Sent: Thursday, 22 November 2007 8:52 AM
><mailto:[email-masked]>[email-masked]
for
chartered
I'm
-
think
--
--

---

From: "Marc Linsner" <[email-masked]>
Date: Wed, 21 Nov 2007 17:28:51 -0500

James,
 
In-line....

  _____  

From: Winterbottom, James [mailto:[email-masked]] 
Sent: Wednesday, November 21, 2007 3:42 PM
To: Marc Linsner; Stark, Barbara; [email-masked]; [email-masked]
Subject: RE: [Geopriv] draft agenda: GEOPRIV @ IETF 70

Marc,

[email-masked]
<mailto:macaddressofmarclinsnersworkstation-00-01-6C-CB-DF-01@accessprovider
.net> 

IMO, formalization of such is not required as entities passing such
information have established relationships and can negotiate syntax via that
relationship.  If in fact it's standardized, it creates an attack vector.

Suppose HELD is bound to a transport other than HTTP, such as in
http://tools.ietf.org/html/draft-thomson-geopriv-held-beep-01, how are the
parameters simply added to the URI? Does it even make sense to do so? 

Hmm....HELD = HTTP enabled location discovery is bound to a transport other
than HTTP?

http://www.ietf.org/internet-drafts/draft-ietf-geopriv-l7-lcp-ps-06.txt
indicates that identifiers other than IP address will be required in some
scenarios. 

LCP = location configuration protocol. Configuration of a host, not SP OSS
boxes.  Where draft-ietf-geopriv-http-location-delivery-03.txt does not work
is spelled out in that draft.  The draft works in ALL scenarios except
tunnels.  I'll accept that the security/privacy required by 3693/4 is met as
is, but not with extensions.

 Not all requirements have technical solutions.  The phonebcp is attempting
to state that it's possible for a proxy to insert location, it doesn't
provide or require the 'how'.

Please read the draft
http://tools.ietf.org/html/draft-winterbottom-geopriv-held-identity-extensio
ns-04 before jumping on to the attack. 

Yes, this drafts opens up several ways for someone other than a target to
gain knowledge of some other target's location. 

There are several architectures and deployments well underway that require
this work. The ABNF definitions in the extensions draft have applicability
beyond just HELD. 

I realize Barbara's concern and offered an alternative, asking why it
doesn't solve her use case.  To state there are 'several' more adds nothing
to this thread. 

    I don't see a need to delay this work further. 

That's a surprise.

-Marc-

Cheers

James

  _____  

Barbara,

Thanks,

-Marc-

  _____  

Robert,

----- Original Message -----
From: Robert Sparks <[email-masked]>
To: GEOPRIV <[email-masked]>
Sent: Tue Nov 20 15:09:03 2007
Subject: [Geopriv] draft agenda: GEOPRIV @ IETF 70

Folks -

15m     Administrivia   Chairs

RjS

*****

----------------------------------------------------------------------------
--------------------
----------------------------------------------------------------------------
--------------------
[mf2]

---

From: "Marc Linsner" <[email-masked]>
Date: Wed, 21 Nov 2007 17:28:51 -0500

Hannes,

> information and/or a LbyR from the LIS. I believe that the 
> two entities, namely the SIP proxy and the LIS, will not be 
> co-located in realistic deployments. 
> A simple protocol is needed. The HELD identity extension 
> document provides this functionality.
> 

How?

-Marc-

---

From: Hannes Tschofenig <[email-masked]>
Date: Wed, 21 Nov 2007 23:40:01 +0100

What are you guys discussing about?

We started with the use case of the HELD identity extension. I have no 
clue how this relates to DHCP.
I believe that this thread has the potential to quickly go into the 
wrong direction. Let's spend our time on reading the huge number of 
GEOPRIV documents...

Ciao
Hannes

Winterbottom, James wrote:
>>> existing requirements. Comes about as a force of habit with this
>>>       
> WG...
>   
>>> *8)
>>>
>>> Cheers
>>> James
>>>
>>>
>>>
>>>       
>> 06.txt>http://www.ietf.org/internet-drafts/draft-ietf-geopriv-l7-lcp-ps
>>     
> -
>   
>>>> 06.txt
>>>>         
>>>>> indicates that identifiers other than IP address will be required
>>>>>           
> in
>   
>>>>> some scenarios.
>>>>>
>>>>> insert location on-behalf-of the calling device. In this
>>>>>           
> situation
>   
>>>>> using HELD requires a formal way to express how the Device is
>>>>>           
> being
>   
>> extensions-04>http://tools.ietf.org/html/draft-winterbottom-geopriv-hel
>>     
> d
>   
>>> -
>>>       
>>>> identity-extensions-04
>>>>         
>>>>> There are several architectures and deployments well underway
>>>>>           
> that
>   
>>>>> require this work. The ABNF definitions in the extensions draft
>>>>>           
> have
>   
>>>>> applicability beyond just HELD. I don't see a need to delay this
>>>>>           
> work
>   
>>>> further.
>>>>         
>>>>> Cheers
>>>>> James
>>>>>
>>>>>
>>>>> ----------
>>>>> assigns the public IP address is not the same as the access
>>>>>           
> provider.
>   
>>>>> Barbara
>>>>>
>>>>> proprietary, and/or privileged material. Any review,
>>>>>           
> retransmission,
>   
>>>>> dissemination or other use of, or taking of any action in
>>>>>           
> reliance
>   
>>>>> upon this information by persons or entities other than the
>>>>>           
> intended
>   
>>>>> contact the sender and delete the material from all computers.
>>>>>           
> GA623
>   
>>>>>
>>>>>
>>>>>           
>>>>> contain privileged, proprietary, or otherwise private
>>>>>           
> information.
>

---

From: "Winterbottom, James" <[email-masked]>
Date: Wed, 21 Nov 2007 16:41:29 -0600

I totally agree, I was as thunderstruck as you.

> From: Hannes Tschofenig [mailto:[email-masked]]
> Sent: Thursday, 22 November 2007 9:40 AM
> To: Winterbottom, James
> Cc: James M. Polk; Marc Linsner; Stark, Barbara; [email-masked];
> [email-masked]
> Subject: Re: [Geopriv] In response to..
> 
http://www.ietf.org/internet-drafts/draft-polk-geopriv-dhcp-lbyr-uri-
> >> option-02.txt
> ------------------------
> ------------------------

---

From: "Winterbottom, James" <[email-masked]>
Date: Wed, 21 Nov 2007 16:41:48 -0600

Marc,

In-line

[email-masked]
<mailto:macaddressofmarclinsnersworkstation-00-01-6C-CB-DF-01@accessprov
ider.net> 

IMO, formalization of such is not required as entities passing such
information have established relationships and can negotiate syntax via
that relationship.  If in fact it's standardized, it creates an attack
vector.

	[AJW] You are entitled to your opinion, though I fail to see how
a standardized way of expressing an identifier leads to attack vectors.
In my experience non-standard or poorly defined ways of expressing
things simply leads to interoperability problems. Either something is a
URI or it isn't. If it is, it should have a formal specification that
can be referenced. 

Hmm....HELD = HTTP enabled location discovery is bound to a transport
other than HTTP?

LCP = location configuration protocol. Configuration of a host, not SP
OSS boxes.  Where draft-ietf-geopriv-http-location-delivery-03.txt does
not work is spelled out in that draft.  The draft works in ALL scenarios
except tunnels.  I'll accept that the security/privacy required by
3693/4 is met as is, but not with extensions.

[AJW] I am not sure that understand what you are trying to say here at
all. I see it as quite legitimate for a device to provide additional
identity information that might assist a LIS in location determination.
Providing the LIS can validate this information, where does the security
issue come form, and why isn't this pertinent to an LCP?

	

 Not all requirements have technical solutions.  The phonebcp is
attempting to state that it's possible for a proxy to insert location,
it doesn't provide or require the 'how'.

[AJW] PRECISELY, but this requirement does have a technical solution,
and it can be accomplished with an identity extension in HELD. 

	Please read the draft

Yes, this drafts opens up several ways for someone other than a target
to gain knowledge of some other target's location. 

[AJW] It also provides ways for a device to provide additional
information about itself to the LIS to help speed things up.

	There are several architectures and deployments well underway
that require this work. The ABNF definitions in the extensions draft
have applicability beyond just HELD. 

I realize Barbara's concern and offered an alternative, asking why it
doesn't solve her use case.  To state there are 'several' more adds
nothing to this thread. 

That's a surprise.

[AJW] So you agree that this work should proceed then?

-Marc-

	Cheers

	James

	Barbara,

	Remind me again why this can't be accomplished by putting the
identifier in the uri?  ex: [email-masked]

	Thanks,

	-Marc-

		

		Robert,
		I think the HELD identity extensions is important. It's
needed for LIS to LIS communication, which is critical where the entity
who assigns the public IP address is not the same as the access
provider.
		Barbara
		
		----- Original Message -----
		From: Robert Sparks <[email-masked]>
		To: GEOPRIV <[email-masked]>
		Sent: Tue Nov 20 15:09:03 2007
		Subject: [Geopriv] draft agenda: GEOPRIV @ IETF 70
		
		Folks -
		
		We have 2.5 hrs in Vancouver (Friday morning). Based on
our chartered 
		work, list discussions, and agenda requests, here's the
agenda I'm 
		planning to follow:
		
		15m     Administrivia   Chairs
		30m     http-location-delivery  Mary (<- Lets finish
this one!)
		
		As usual, we have many other requests to talk about
other things - 
		please take those to the list for now.
		
		This is a draft agenda and we can change it. Let me know
if you think 
		I've missed something important.
		
		RjS

		*****

		The information transmitted is intended only for the
person or entity to which it is addressed and may contain confidential,
proprietary, and/or privileged material. Any review, retransmission,
dissemination or other use of, or taking of any action in reliance upon
this information by persons or entities other than the intended
recipient is prohibited. If you received this in error, please contact
the sender and delete the material from all computers. GA623

---

From: Hannes Tschofenig <[email-masked]>
Date: Wed, 21 Nov 2007 23:42:46 +0100

Tomorrow I will send you a message flow how a SIP proxy requests 
location information and a URI for usage with SIP Location Conveyance.
I am already too tired today.

Ciao
Hannes

---

From: "James M. Polk" <[email-masked]>
Date: Wed, 21 Nov 2007 17:47:16 -0600

I am not holding back your HELD efforts, especially now that the WG 
has agreed with rough consensus HELD should move forward in 
Geopriv.  I believe the WG is in the same position of rough consensus 
regarding DHCP, of which, this is the last of the 3 documents to 
address what can be placed in a Geolocation header as far as location 
is concerned (i.e., it has Geo in 3825, and civic in 4776, but lacks 
a URI this WG so adamantly believes should be a choice).

BTW - I have to be in Barcelona in late January, which apparently is 
also quite nice (at least I hope it is).

Early Feb is American Football (the old shaped one) Super Bowl (i.e., 
championship game, which should be a holiday as far as I'm concerned).

That said, I don't disagree with you regarding the need for an 
interim before Philly or in the spring before the next IETF.

---

From: "James M. Polk" <[email-masked]>
Date: Wed, 21 Nov 2007 17:48:59 -0600

At 04:40 PM 11/21/2007, Hannes Tschofenig wrote:
>We started with the use case of the HELD identity extension. I have 
>no clue how this relates to DHCP.

but the Subject line says neither...

(just an observation)

---

From: "James M. Polk" <[email-masked]>
Date: Wed, 21 Nov 2007 17:52:20 -0600

>location information and a URI for usage with SIP Location Conveyance.

Location Conveyance does not define how any entity retrieves location 
- so this flow should be interesting.

BTW - I don't consider a dereference "location retrieval", that's conveyance.

---

From: "Dawson, Martin" <[email-masked]>
Date: Wed, 21 Nov 2007 18:54:47 -0600

Isolating the first point - which appears to be a "highlight objection"
to the identity extension functionality, with a focus on security

The HELD identity extension supports three key sets of functionality

1.	The option for a target device which is also the HELD client to
provide additional information to facilitate location determination - or
provide for more accurate location determination. E.g. the device uses
LLDP to determine the connected switch/port and provides that with the
request or the device can provide RFID data as part of a specific site
location network.
2.	For one LIS to communicate information to another LIS where
location determination is performed co-operatively between LIS elements.
E.g an ISP LIS which provides the L2TP tunnel identifier to a DSL
infrastructure provider LIS so that it can correlate it with the BRAS
circuit, associated DSLAM termination, and corresponding residential
street address.
3.	For a trusted application to request location on-behalf-of a
legacy device which lacks native location-capability. E.g. an enterprise
VoIP environment with legacy IP handsets with no internal location
request capability - the call server can request the LIS to provide the
location of the IP address associated with the phone.

If I understand your proposition, all of these things can be done in
proprietary ways and that this is inherently more secure - correct me if
I misinterpreted the comment. While I don't see how the security
argument can be quantified (sounds like security through obscurity), my
view is that industry standardisation is very important for all of these
functions, security can definitely be addressed (and even in proprietary
ways if desired) very effectively, and any notional security concerns
associated with standardising this approach don't outweigh the benefits
in terms of interoperability and speed of implementation across many
access networks.

Cheers,

Martin

From: Marc Linsner [mailto:[email-masked]] 
Sent: Thursday, 22 November 2007 9:29 AM
To: Winterbottom, James; [email-masked]
Subject: RE: [Geopriv] draft agenda: GEOPRIV @ IETF 70

James,

In-line....

	Sent: Wednesday, November 21, 2007 3:42 PM
	To: Marc Linsner; Stark, Barbara; [email-masked];
[email-masked]
	Subject: RE: [Geopriv] draft agenda: GEOPRIV @ IETF 70

	Marc,

	Suppose the identifier is a MAC address, since this has no
formal URI representation  then what? 

	

	 

	Please read the draft

	 

That's a surprise.

-Marc-

	Cheers

	James

	Barbara,

	Thanks,

	-Marc-

		

		Robert,
		
		----- Original Message -----
		From: Robert Sparks <[email-masked]>
		To: GEOPRIV <[email-masked]>
		Sent: Tue Nov 20 15:09:03 2007
		Subject: [Geopriv] draft agenda: GEOPRIV @ IETF 70
		
		Folks -

		15m     Administrivia   Chairs

		
		RjS

		*****

---

From: "Winterbottom, James" <[email-masked]>
Date: Wed, 21 Nov 2007 20:20:03 -0600

Hi James,

I think your position below is at odds with NENA and most folks I talk
to.
I agree that the area is a little grey though.

.

---

From: "Dawson, Martin" <[email-masked]>
Date: Wed, 21 Nov 2007 22:16:41 -0600

With respect to the following point:

[JW] Suppose HELD is bound to a transport other than HTTP, such as in
http://tools.ietf.org/html/draft-thomson-geopriv-held-beep-01, how are
the parameters simply added to the URI? Does it even make sense to do
so? 

[ML] Hmm....HELD = HTTP enabled location discovery is bound to a
transport other than HTTP?

[ML] I realize Barbara's concern and offered an alternative, asking why
it doesn't solve her use case.  To state there are 'several' more adds
nothing to this thread. 

Very early in the piece, when the first HELD draft was submitted, we
were encouraged to specify alternative bindings for the protocol. It's
been observed a few times that the protocol name contains an epithet
that isn't strictly applicable any longer - but there was a body of
opinion that said keep the name for continuity and that's what has
happened. Nevertheless the wisdom of proposing other bindings has
certainly become evident to the authors since then.

In your basic device-LIS interaction, HTTP is good - it's easy to
implement and plays nicely in the considerable majority of networks.
Similarly, using it for dereferencing is good for the same reasons -
reaching a LIS behind an operator firewall is easy on the network
operator's IS policies if it comes in on HTTP. However, when it comes to
LIS-LIS traffic between elements within an operator environment or, in
particular, between operator environments HTTP has certain performance
characteristics that militate against its use for such a high volume
"trunk" link.

Actually we find this is the case with the OMA MLP protocol
specification as well. MLP is based on HTTP - for the same sorts of
reasons described above. In a model where there are many arbitrary
location application clients using the gateway location server, HTTP
makes sense. However, it turns out in practice that a standard
implementation is for an operator to have an application middleware
platform (which binds network functions such as location, SMS,
voice-response, etc.) together as application building blocks.
Applications are then hosted on this middleware and all the location
gateway sees is the middleware host as a single client which is trunking
many, and frequent, requests toward it on a single HTTP session. Each of
these requests has different response time requirements but the nature
of HTTP is such that the response to a request cannot be provided until
the responses to previous requests have been sent. This leads to an
unfortunate sub-optimal latency effect because responses cannot be
arbitrarily interleaved with requests.

The OMA solution to this is to define an asynchronous response model
using HTTP. Requests come in from the client and are acknowledged
immediately. When the response is cooked, the gateway becomes the HTTP
client and pushes the result back to the application. Correlation is
done using a transaction ID.

This is quite unattractive from an implementation perspective and
highlights the fact that certain implementation models benefit from
alternative transport protocols being available. In the case of HELD,
such "trunking" scenarios are better served by using BEEP as the
transport/session protocol than using HTTP.

So - after all those words - that is why relying on an informal
convention for URI encoding is not satisfactory - it assumes a
particular binding. Having the application protocol support the
semantics explicitly is more robust. And, as a final question, why
doesn't the use of such a convention for URI construction invite the
same sort of security issues that are being ascribed to the identity
extension?

Cheers,

Martin

James,

In-line....

	Marc,

	

	 

	Please read the draft

	 

That's a surprise.

-Marc-

	Cheers

	James

	Barbara,

	Thanks,

	-Marc-

		

		Robert,
		
		----- Original Message -----
		From: Robert Sparks <[email-masked]>
		To: GEOPRIV <[email-masked]>
		Sent: Tue Nov 20 15:09:03 2007
		Subject: [Geopriv] draft agenda: GEOPRIV @ IETF 70
		
		Folks -

		15m     Administrivia   Chairs

		
		RjS

		*****

---

From: Hannes Tschofenig <[email-masked]>
Date: Thu, 22 Nov 2007 09:58:03 +0100

Here is the promised message flow.

Consider a SIP INVITE message that arrives at the proxy. It does not 
contain location information

   INVITE sips:[email-masked] SIP/2.0
   Via: SIP/2.0/TLS pc33.atlanta.example.com
     ;branch=z9hG4bK74bf9
   Max-Forwards: 70
   To: Bob <sips:[email-masked]>
   From: Alice <sips:[email-masked]>;tag=9fxced76sl
   Call-ID: [email-masked]
   Accept: application/sdp
   CSeq: 31862 INVITE
   Contact: <sips:[email-masked]>

   ...SDP goes here as the only message body

Now, assume that a the proxy does location based routing and also wants 
to allow the location recipient to obtain the location information.
It constructs a HELD request:

<?xml version="1.0"?>
<locationRequest xmlns="urn:ietf:params:xml:ns:geopriv:held">
    <locationType exact="true">
     any
     locationURI
    </locationType>
</locationRequest>

The LIS returns a response with a civic address and the  LbyR.

<?xml version="1.0"?>
<locationResponse xmlns="urn:ietf:params:xml:ns:geopriv:held">

          <locationUriSet expires="2006-01-01T13:00:00">
          <locationURI>https://ls.example.com:9768/357yc6s64ceyoiuy5ax3o
          </locationURI>
          <locationURI>sips:[email-masked]
          </locationURI>
         </locationUriSet>
         <presence xmlns="urn:ietf:params:xml:ns:pidf:geopriv10"
                entity="pres:[email-masked]">
         <tuple id="lisLocation">
          <status>
          <geopriv>
             <ca:civicAddress
              xmlns:ca="urn:ietf:params:xml:ns:pidf:geopriv10:civicAddr"
              xml:lang="en-au">
              <ca:country>AU</ca:country>
              <ca:A1>NSW</ca:A1>
              <ca:A3>Wollongong</ca:A3>
              <ca:A4>Gwynneville</ca:A4>
              <ca:STS>Northfield Avenue</ca:STS>
              <ca:LMK>University of Wollongong</ca:LMK>
              <ca:FLR>2</ca:FLR>
              <ca:NAM>Andrew Corporation</ca:NAM>
              <ca:PC>2500</ca:PC>
              <ca:BLD>39</ca:BLD>
              <ca:SEAT>WS-183</ca:SEAT>
              <ca:POBOX>U40</ca:POBOX>
             </ca:civicAddress>
           </location-info>
           <usage-rules>
             <retransmission-allowed>false</retransmission-allowed>
             <retention-expiry>2007-05-25T12:35:02+10:00
             </retention-expiry>
           </usage-rules>
           <method>Wiremap</method>
           </geopriv>
          </status>
          <timestamp>2007-05-24T12:35:02+10:00</timestamp>
        </tuple>
        </presence>
       </locationResponse>

Based on the location by value the SIP proxy routes the call. It also 
attaches a LbyR to the outgoing SIP message.

   INVITE sips:[email-masked] SIP/2.0
   Via: SIP/2.0/TLS pc33.atlanta.example.com
     ;branch=z9hG4bK74bf9
   Max-Forwards: 70
   To: Bob <sips:[email-masked]>
   From: Alice <sips:[email-masked]>;tag=9fxced76sl
   Call-ID: [email-masked]
   Geolocation: <sips:[email-masked]>
     ;inserted-by=proxy.atlanta.example.com ;recipient=endpoint   
   Accept: application/sdp
   CSeq: 31862 INVITE
   Contact: <sips:[email-masked]>

   ...SDP goes here as the only message body

When the location recipient receives the message it runs a dereferencing 
step.

Does my example make sense?

Ciao
Hannes

---

From: Salvatore Loreto <[email-masked]>
Date: Thu, 22 Nov 2007 11:37:00 +0200

Hi Hannes,

in my view the flow is clear and correct, 
or at least it is how I aspect it to work.

ciao
Sal

---

From: Hannes Tschofenig <[email-masked]>
Date: Thu, 22 Nov 2007 10:58:23 +0100

In my previous mail I made a mistake and forgot to include the identity 
extension. Without the identity extension the described message flow 
wouldn't work.

Here is the updated message flow.

Now, assume that a the proxy does location based routing and also wants 
to allow the location recipient to obtain the location information. The 
request contains the HELD identity extension containing the IP address 
of UA sending the SIP INVITE message.

<?xml version="1.0"?>
<locationRequest xmlns="urn:ietf:params:xml:ns:geopriv:held">
   <locationType exact="true">
    any
    locationURI
   </locationType>
   <heldDevice xmlns="urn:ietf:params:xml:ns:geopriv:held:id">
     <uri>ip:IPv4+192.0.2.5</uri>
   </heldDevice>
</locationRequest>

<?xml version="1.0"?>

Ciao
Hannes

---

From: "Winterbottom, James" <[email-masked]>
Date: Thu, 22 Nov 2007 04:01:56 -0600

Yes. This is good, thanks Hannes.

> Sent: Thursday, 22 November 2007 8:58 PM
> To: [email-masked]
> Subject: [Geopriv] Message Flow, again
> 
The

---

From: "Brian Rosen" <[email-masked]>
Date: Thu, 22 Nov 2007 22:42:11 -0500

It makes sense but is really problematic.  It points out a pretty serious
flaw in proxy assertion:  since the location obtained from dereferencing may
not be what was used for routing, the recipient doesn't really know why it
got the message.
 
In an end system version of this, the end system should add the value and
the reference, marking the value as the one the routing was based on.  The
proxy can't do that. Ugh.

Please don't do proxy insertion of references; it's going to cause a lot of
confusion.  We'll have to allow it.  It's going to be ugly.

Suppose it's the emergency case, the call is correctly routed based on the
initial location to a PSAP, but when the PSAP dereferences a newer, more
accurate location is reported, and the result is a different PSAP should get
the call.

The original PSAP wants to know what happened: was it a routing error or a
location error?  Who knows?  The PSAP would have to get to the proxy, the
proxy would have to have archived the location it used for routing, etc.

Yuck.  Just don't do it.

Brian

> Sent: Thursday, November 22, 2007 3:58 AM
> To: [email-masked]
> Subject: [Geopriv] Message Flow
>

---

From: "Brian Rosen" <[email-masked]>
Date: Thu, 22 Nov 2007 22:50:42 -0500

Reminder that this only works in lots of possible, but generally hard to
achieve circumstances (which IMS in a mobile environment, for an emergency
call, with the E-CSCF in the visited network manages to get right).

1. The IP address seen by the proxy has to actually relate to the location
of the endpoint.  At a proxy, this is VERY hard to assure.  All the text
about no VPNs or NATs applies, and you usually don't even know if the device
is on an access network that stands a chance of making it happen.  This
means it wouldn't work, for example, on the Internet, or in an IMS wireline
network without a guaranteed relationship with the access network.

2. There has to be a relation between the proxy and the LIS.  The LIS should
not hand out location unless it really knows who is asking

3. The proxy has to know when to do this.  In the example given, there is no
indication that the proxy should insert location.  Generally, a proxy
shouldn't add location except under some conditions that warrant it.

Brian

> Sent: Thursday, November 22, 2007 5:02 AM
> To: Hannes Tschofenig; [email-masked]
> Subject: RE: [Geopriv] Message Flow, again
>

---

From: "Dawson, Martin" <[email-masked]>
Date: Thu, 22 Nov 2007 22:24:38 -0600

This happens with cellular E911 today - particularly where the MSC uses
the cell ID for routing but the SMLC-determined location is what is
passed to the ALI (even as the initial location). The PSAP doesn't
actually see the cell-based routing information.

I'm not aware it causes any heartburn - it does with respect to
cell-based routing not being very accurate; but not with respect to
there being a mismatch with respect to the "presumed" routing associated
with the delivered location.

This "routing anomaly" won't span more than adjacent PSAP boundaries and
such anomalies can just as easily occur with the routing algorithm in
one LoST/VPC implementation versus another - how percentage overlaps of
uncertainty and routing region boundaries are handled for example. I
can't see this as a "serious flaw" - the recipient doesn't really know
why it got the message anyway.

It's not like PSAPs can be expected to have visibility of the routing
algorithm used; I'm even doubtful that they will have a way to run a
routing test on a given area of uncertainty. I suspect that the scenario
you mention is just as likely to become a useful standard explanation
for why a call may appear misrouted. That is, "the more accurate
location we received is probably just different than the one used for
routing" (while it's probably just as likely to be because of different
implementations of routing logic). Whether it's a problem or not will
depend on how frequently it occurs. I expect VoIP to have a much better
routing accuracy performance than cellular currently has regardless.

Cheers,
Martin

-----Original Message-----
From: Brian Rosen [mailto:[email-masked]] 
Sent: Friday, 23 November 2007 2:42 PM
To: 'Hannes Tschofenig'; [email-masked]
Subject: RE: [Geopriv] Message Flow

It makes sense but is really problematic.  It points out a pretty
serious
flaw in proxy assertion:  since the location obtained from dereferencing
may
not be what was used for routing, the recipient doesn't really know why
it
got the message.
 
In an end system version of this, the end system should add the value
and
the reference, marking the value as the one the routing was based on.
The
proxy can't do that. Ugh.

Please don't do proxy insertion of references; it's going to cause a lot
of
confusion.  We'll have to allow it.  It's going to be ugly.

Suppose it's the emergency case, the call is correctly routed based on
the
initial location to a PSAP, but when the PSAP dereferences a newer, more
accurate location is reported, and the result is a different PSAP should
get
the call.

The original PSAP wants to know what happened: was it a routing error or
a
location error?  Who knows?  The PSAP would have to get to the proxy,
the
proxy would have to have archived the location it used for routing, etc.

Yuck.  Just don't do it.

Brian

---

From: "Winterbottom, James" <[email-masked]>
Date: Thu, 22 Nov 2007 23:15:17 -0600

To be clear then Brian,

Are you saying never do it (Phone BCP needs updating to remove this
option)?
Do it carefully (Identity extensions is required)?

Cheers
James

> Sent: Friday, 23 November 2007 2:51 PM
> To: Winterbottom, James; 'Hannes Tschofenig'; [email-masked]
> 3. The proxy has to know when to do this.  In the example given, there
is
> no
> > ----------------------
> > ----------------------

---

From: Hannes Tschofenig <[email-masked]>
Date: Fri, 23 Nov 2007 08:47:53 +0100

Hi Brian,

I am trying to make sense out of what you said.

> not be what was used for routing, the recipient doesn't really know why it
Consider an emergency service use case. The Location Recipient very well 
knows why it got location information.
I am not sure what you mean by "location obtained from dereferencing may 
not be what was used for routing".
Let me try to guess: The dereferencing procedure might reveal more 
precise location information or more up-to-date location of the Target. 
Do you really think that this is a problem?

> proxy can't do that. Ugh.
There is obviously a difference between the end host doing the job and 
the proxy doing it. There is no difference between the two approaches.

> confusion.  We'll have to allow it.  It's going to be ugly.
Have you ever had a chance to look at the IMS emergency services 
specification. That's what being used even thought the usage of SIP 
Location Conveyance for the communication beyond the E-CSCF.

> accurate location is reported, and the result is a different PSAP should get
That happens.

What is the alternative?

> proxy would have to have archived the location it used for routing, etc.
I would rather want to get the call established soon rather than waiting 
a long time for accurate location information to show up at the end host.

You might have also realized that there is no question about end host 
and  proxy adding  location information. These architectural choices are 
already cast in stone based on the way how existing SIP communication 
models work.

Ciao
Hannes

---

From: Hannes Tschofenig <[email-masked]>
Date: Fri, 23 Nov 2007 09:01:55 +0100

Hi Brian

Brian Rosen wrote:
> of the endpoint.  At a proxy, this is VERY hard to assure. 
Not if the proxy is in the access network.

>  All the text
> about no VPNs or NATs applies,
You know that the NAT case is not a problem.
The VPN aspect is not a problem either in the deployment environments 
where people are going to use this.

>  and you usually don't even know if the device
> is on an access network that stands a chance of making it happen.
In the environments we are looking at this is the case.

>   This
In the IMS there is an association with the access network.
> not hand out location unless it really knows who is asking
That's true. The HELD identity document states this assumption.
The SIP Location Conveyance document does not call this out explicitly 
since it is only about "conveyance" (as I got told by you and James when 
I raised these issues).

> shouldn't add location except under some conditions that warrant it.
That's completely true. I omitted the "emergency services" related 
components. This was another one of my comments to the SIP Location 
Conveyance document and both of you were happy with my suggestion to 
provide an explicit indication in the SIP SAML document since it is 
needed there anyway.When we consider cases outside the emergency 
services use case then this explicit marking would be used.

In summary, I am totally surprised about your comments. The 
functionality of the proxy adding LbyRs is in the SIP Location 
Conveyance specification for a long time already. We know how some 
deployments are going to use this type of emergency services architecture.
In the past I have stated that we should capture some of the 
architectural issues since everyone was so extremely keen on documenting 
them for HELD as well. This proposal was rejected. I was fine with it.

Now, after years it looks like that this would be something entirely 
new. In another mail you want to delay the Phone BCP work to incorporate 
Location Hiding because "otherwise the emergency services architecture 
will not get deployed". With this work you are suddenly totally 
unrealistic. The functionality of allowing a proxy to retrieve location 
information is essentially all over the place for emergency services and 
also documented in the Phone BCP / ECRIT framework document. Are you 
expecting this to be changed?

Ciao
Hannes

>>> In my previous mail I made a mistake and forgot to include the
>>>       
>> identity
>>     
>>> Now, assume that a the proxy does location based routing and also
>>>       
>> wants
>>     
>>> When the location recipient receives the message it runs a
>>>       
>> dereferencing
>>     
>>> step.
>>>

---

From: Hannes Tschofenig <[email-masked]>
Date: Fri, 23 Nov 2007 09:07:38 +0100

The interesting thing is that Phone BCP wasn't quite clear on the 
support for this deployment with the version we had a IETF#69. Then, we 
had a discussion about it and the support for the deployment mode was 
clarified and described quite clearly with the Phone BCP re-write for 
IETF#70.

Hence, I am not sure what we are arguing here about.

Winterbottom, James wrote:
>> Reminder that this only works in lots of possible, but generally hard
>>     
> to
>   
>> achieve circumstances (which IMS in a mobile environment, for an
>>     
> emergency
>   
>> 1. The IP address seen by the proxy has to actually relate to the
>>     
> location
>   
>> of the endpoint.  At a proxy, this is VERY hard to assure.  All the
>>     
> text
>   
>>>> extension. Without the identity extension the described message
>>>>         
> flow
>   
>>>> wouldn't work.
>>>>
>>>> Consider a SIP INVITE message that arrives at the proxy. It does
>>>>         
> not
>   
>>>> to allow the location recipient to obtain the location
>>>>         
> information.
>   
>>> The
>>>       
>>>> request contains the HELD identity extension containing the IP
>>>>         
> address
>   
>>>> Based on the location by value the SIP proxy routes the call. It
>>>>         
> also
>

---

From: "Brian Rosen" <[email-masked]>
Date: Fri, 23 Nov 2007 12:19:47 -0500

We're actually trying to get things better than they are now.  We're giving
the PSAP a lot more data to figure out what is happening.  The accuracy
requirements are going up.  The incidence of "quick fix" is improving. 

It does cause heartburn, but they have no way to deal with it now.  We're
trying to give them information.  In a well organized country you won't see
many anomalies in the route data between adjacent PSAPs.  Ideally, there
won't be any, but I wouldn't presume perfect data.    

If the endpoint did it, the PSAP would have the data.  If a proxy does it,
they won't.  It's a problem.  We are going to have to allow it, so I'm not
arguing that we're banning proxy assertion of location.  I am suggesting
this is another reason why it should be rare.

Brian

> From: Dawson, Martin [mailto:[email-masked]]
> Sent: Thursday, November 22, 2007 11:25 PM
> To: Brian Rosen; Hannes Tschofenig; [email-masked]

---

From: "Brian Rosen" <[email-masked]>
Date: Fri, 23 Nov 2007 12:20:29 -0500

I am saying do it carefully.  More text in PhoneBCP is required.

We can't eliminate it.

Brian

> Sent: Friday, November 23, 2007 12:15 AM

---

From: "Brian Rosen" <[email-masked]>
Date: Fri, 23 Nov 2007 12:26:42 -0500

> Sent: Friday, November 23, 2007 2:48 AM
> To: Brian Rosen
> Cc: [email-masked]
> Subject: Re: [Geopriv] Message Flow
> 
> Hi Brian,
> 
It doesn't know why it got the call.  The location it has says some other
PSAP should have gotten the call.  If the endpoint got location, the value
it used for routing would be in the call signaling, marked correctly.

> Do you really think that this is a problem?
Yes, that is the case.  Yes, I think it's a problem, because the PSAP
doesn't know why the call was misrouted.  If the endpoint did the routing,
the location it used would be in the call signaling, and the PSAP can
determine that the call was routed correctly for the data the endpoint had
(or not, as the case may be).

> the proxy doing it. There is no difference between the two approaches.
I'm pointing out a difference between them.  In the endpoint route, the PSAP
knows the location used for routing.  In the proxy case, it doesn't.

> Location Conveyance for the communication beyond the E-CSCF.
Yes, and I don't like it.  We may want to have the E-CSCF act as a B2BUA and
insert a body.

> > accurate location is reported, and the result is a different PSAP should
When the endpoint routes, it puts the location used for routing in the
signaling. 

> already cast in stone based on the way how existing SIP communication
Of course.  I'm pointing out yet another problem in trying to get proxies to
add location.

---

From: "Brian Rosen" <[email-masked]>
Date: Fri, 23 Nov 2007 12:36:16 -0500

> Sent: Friday, November 23, 2007 3:02 AM
> To: Brian Rosen
> Cc: 'Winterbottom, James'; [email-masked]
> Subject: Re: [Geopriv] Message Flow, again
> 
> Hi Brian
> 
> Brian Rosen wrote:
That is the IMS mobile case, but there are few other proxies that know they
are in the access network.  In general, with a VPN, you can't tell.  Note
that it does NOT work with an IMS wireline case where nomadic use is
permitted.

> You know that the NAT case is not a problem.
Sure it is, depending on where the NAT is.  A great example is a NAT in a
multi-site enterprise.  Depending on where the NAT is in relation to the
LIS, the NAT can be very problematic.  It's often not a problem in a
residential broadband deployment until you get to the point where you want
interior building location data.  Then it is problem.

> where people are going to use this.
If we restrict the use of proxy insertion to a situation where the proxy is
in the access network, fine, but we have no such restriction.

> In the environments we are looking at this is the case.
Only in an IMS mobile deployment.  We aren't restricting to such a case.

> In the IMS there is an association with the access network.
Yes.  IMS in a mobile network works.  I said that up front.

> since it is only about "conveyance" (as I got told by you and James when
Yes.  Probably need more text in phonebcp and framework

> is no
The emergency case is covered.  The non-emergency case is not.

> them for HELD as well. This proposal was rejected. I was fine with it.
We can have text in phonebcp that covers this.  It's not really a conveyance
problem. 

> expecting this to be changed?
We probably need more text in phonebcp and framework for the emergency case.

I'm not sure we need it somewhere else, unless there was some more general
location architecture work.  There isn't any, and this item probably doesn't
rise to the level where we need a new document just for that.

---

From: Hannes Tschofenig <[email-masked]>
Date: Fri, 23 Nov 2007 19:22:37 +0100

Hi Brian,

a few comments below:

> knows the location used for routing.  In the proxy case, it doesn't.

Well. That's not entirely correct if you consider the context draft in 
addition. It allows you to indicate to what the reference points.
http://tools.ietf.org/wg/geopriv/draft-winterbottom-geopriv-held-context-01.txt

> Yes, and I don't like it.  We may want to have the E-CSCF act as a B2BUA and
Or a DATA URI. That was proposed and rejected....

> When the endpoint routes, it puts the location used for routing in the

For the architectures we are talking about this is not really the 
alternative. You know that.

> Of course.  I'm pointing out yet another problem in trying to get proxies to
To be honest, there are also problems when the end host gets the 
location information. Just consider the entire debate about location 
signing.

Ciao
Hannes

---

From: "Winterbottom, James" <[email-masked]>
Date: Fri, 23 Nov 2007 15:23:07 -0600

Sorry Hannes, let me clarify.

I read Brian's email and found it to be quite circular.
The result of it all I think boils down to:

We make an explicit statement saying that proxies can't do this. This is
a bury your head in the sand approach because we know people are going
to do this.

Or

We say yes this is doable, and make it happen. The identity extensions
document allows this to happen for HELD.

Cheers
James

> Sent: Friday, 23 November 2007 7:08 PM
> To: Winterbottom, James
> Cc: Brian Rosen; [email-masked]
> >> about no VPNs or NATs applies, and you usually don't even know if
the
> >> device
> >> 2. There has to be a relation between the proxy and the LIS.  The
LIS
> >> should

---

From: "Brian Rosen" <[email-masked]>
Date: Fri, 23 Nov 2007 19:18:17 -0500

> http://tools.ietf.org/wg/geopriv/draft-winterbottom-geopriv-held-context-
No, that is not sufficient.  The PSAP (or any location recipient) can't do
anything that would get it the location the proxy got.

> Or a DATA URI. That was proposed and rejected....
We were advised it wouldn't fly in the IESG.  If you want to re-raise the
issue, Henning would be happy.

> alternative. You know that.
Require it to be a B2BUA and put in the body?

> location information. Just consider the entire debate about location
In general, a location recipient can't trust a proxy.  I'll admit it's got a
higher probability of being correct.  I want location signing or some
equivalent.

Brian

---

From: "Winterbottom, James" <[email-masked]>
Date: Fri, 23 Nov 2007 22:37:34 -0600

Brian,

Inline.

> Sent: Saturday, 24 November 2007 11:18 AM
> To: 'Hannes Tschofenig'
> Cc: [email-masked]
> > >> There is obviously a difference between the end host doing the
job
> > > I'm pointing out a difference between them.  In the endpoint
route,
> > PSAP
> > http://tools.ietf.org/wg/geopriv/draft-winterbottom-geopriv-held-
> context-
> > 01.txt
[AJW] This is not true. The proxy can request a snapshot location which
means that the reference will always point to the same location.

---

From: Hannes Tschofenig <[email-masked]>
Date: Sat, 24 Nov 2007 09:53:34 +0100

Hi Brian,

Brian Rosen wrote:
>>> I'm pointing out a difference between them.  In the endpoint route, the
>>>       
>> PSAP
>>     
How come?

In fact you could even request two URIs. One URI that points to the 
location that was obtained exactly that the time when the routing 
decision had to be made.
Another URI would point to the most recent location of the Target.

Alternatively, the PSAP could issue two types of derefencing requests:
* give me the location when the reference was created (this is the one 
used for routing)
* give me the current location of the end point.

>>> Yes, and I don't like it.  We may want to have the E-CSCF act as a B2BUA
>>>       
>> and
>>     
>>> insert a body.
>>>
>>>       
As we know already, nothing really flies in the IESG.
I just recall the Geolocation policy document -- it fly for a while then 
it crashed.

> Require it to be a B2BUA and put in the body?
When you skip the idea of sending location information to the end point 
and focus on the proxy case only then there are obviously a number of 
choices.
One is to use a B2BUA, another one is to use a DATA URI.

>>>> and  proxy adding  location information. These architectural choices
>>>>         
>> are
>>     
>>> Of course.  I'm pointing out yet another problem in trying to get
>>>       
>> proxies to
>>     
>>> add location.
>>>
>>>
>>>       

When you use a LbyR then the security of it is as good as location 
signing (just less complicated given that you have to use an LbyR anyway).

Ciao
Hannes

---

From: "Brian Rosen" <[email-masked]>
Date: Sat, 24 Nov 2007 22:00:18 -0500

But that wouldn't let the recipient get updated location, right?  So it
wouldn't generally be useful.  To be useful, it would have to have both a
snapshot and a "regular" reference, send both and mark them appropriately.

The context draft doesn't match the syntax of -conveyance, which means we
have information loss from the proxy to the recipient.  That means "mark
them appropriately" is hard.

Brian

> Sent: Friday, November 23, 2007 11:38 PM
> To: Brian Rosen; Hannes Tschofenig
> Cc: [email-masked]

---

From: "Winterbottom, James" <[email-masked]>
Date: Sun, 25 Nov 2007 03:18:59 -0600

Why?

I would just create 2 contexts, one snapshot, one not. Mark the snapshot
one as the one used-for-routing, and include the second URI for updates.

I am remain unconvinced however that it actually matters if the PSAP
gets a slightly different location. Can you indicate what the
significant impact is?

Cheers
James 

> Sent: Sunday, 25 November 2007 2:00 PM
> To: Winterbottom, James; 'Hannes Tschofenig'
> Cc: [email-masked]
> > > > Well. That's not entirely correct if you consider the context
draft

---

From: Henning Schulzrinne <[email-masked]>
Date: Sun, 25 Nov 2007 19:19:00 -0500

> I just recall the Geolocation policy document -- it fly for a while  
> then it crashed.

In general, I find these arguments as to what the IESG will and will  
not do rather pointless (and worse). It's a new variation of the old  
rhetorical device of appealing to authority and doesn't seem to fit  
well into a peer-based organization. It's also a variation of the old  
anticipatory obedience practiced in feudal societies, where the peons  
and noble men tried to guess what the king might like and not like.  
Made it easy for the king, since they didn't actually have to do  
anything or justify their actions... (Reference to the old saying by  
Dave Clark intentional.)

The problem here is a pretty good example of doing trade-off  
engineering. There doesn't seem to be single technique that works in  
all circumstances or has only positive attributes, including, for  
example, simplicity, reliability, statelessness and trace-ability.

Henning

---

From: "Marc Berryman" <[email-masked]>
Date: Mon, 26 Nov 2007 07:13:17 -0600

Re: "I am remain unconvinced however that it actually matters if the
PSAP
gets a slightly different location. Can you indicate what the
significant impact is?"

The location has a major impact on the proper emergency responders to
send to the "call", just being on the other side of a two-lane road
often makes a difference due to taxation boundaries.

Having only a slightly different location could make the difference
between sending a heavy rescue or water rescue rather than a singe EMS
or pumper fire truck.

Maybe I am taking James comment out of context, but at the PSAP LOCATION
MATTERS.

Marc Berryman

-----Original Message-----
From: Winterbottom, James [mailto:[email-masked]] 
Sent: Sunday, November 25, 2007 3:19 AM
To: Brian Rosen; Hannes Tschofenig
Cc: [email-masked]
Subject: RE: [Geopriv] Message Flow

Why?

Cheers
James 

draft

---

From: "Marc Linsner" <[email-masked]>
Date: Mon, 26 Nov 2007 08:37:10 -0500

Hannes,

In-line.... 

....snip......

> 
> Now, assume that a the proxy does location based routing and 
> also wants to allow the location recipient to obtain the 
> location information. The request contains the HELD identity 
> extension containing the IP address of UA sending the SIP 
> INVITE message.
> 

....snip......

I'll ask the same question again.  Why doesn't a LbyR dereference provide
the same?

Example: [email-masked]'

-Marc-

---

From: "Dawson, Martin" <[email-masked]>
Date: Mon, 26 Nov 2007 07:40:03 -0600

Hi Marc,

Yes - the comment is out of context.

The (very long-winded) question is:

If the location used for routing is determined some number of seconds
earlier and possibly to less precision than the location that is
actually provided at the PSAP, and given there is some subset of
circumstances where the caller may have moved sufficiently from the
point in time at which the location for routing was determined and the
time that the location provided to the PSAP was determined that the
latter may represent a different route, would this represent a major
flaw in the architecture?

Would the PSAP do a dynamic "reassessment of routing" to see whether the
uncertainty associated with the provided location should have resulted
in the call coming to them?

In whatever (I would expect quite small) proportion of calls that this
situation would occur in, would it cause a major issue for dealing with
or assessing the call, or would the assumption simply be that perhaps
the caller moved sufficiently in the elapsed seconds to cross the
routing boundary?

Note that this has nothing to do with whether the call gets to the PSAP
or a different one. It's just a question of whether the recipient PSAP
gets the actual location that was used for routing versus one that was
determined at the time of call receipt. How complex should the
architecture/implementation be in order that the location for routing is
also provided? How big can the cost be and still provide a cost-benefit?

Cheers,
Martin

-----Original Message-----
From: Marc Berryman [mailto:[email-masked]] 
Sent: Tuesday, 27 November 2007 12:13 AM
To: Winterbottom, James; Brian Rosen; Hannes Tschofenig
Cc: [email-masked]
Subject: RE: [Geopriv] Message Flow

Marc Berryman

-----Original Message-----
From: Winterbottom, James [mailto:[email-masked]] 
Sent: Sunday, November 25, 2007 3:19 AM
To: Brian Rosen; Hannes Tschofenig
Cc: [email-masked]
Subject: RE: [Geopriv] Message Flow

Why?

Cheers
James 

draft

---

From: "Dawson, Martin" <[email-masked]>
Date: Mon, 26 Nov 2007 07:42:51 -0600

I'm not sure you meant to ask the question you did.

Location by reference would require the device to consult the LIS to get
the reference which was then used by the proxy to dereference with. The
scenario under discussion is where the device doesn't have any native
ability to interact with a LIS so it can't provide a reference for the
proxy to use.

Cheers,
Martin

-----Original Message-----
From: Marc Linsner [mailto:[email-masked]] 
Sent: Tuesday, 27 November 2007 12:37 AM
To: 'Hannes Tschofenig'; [email-masked]
Subject: RE: [Geopriv] Message Flow, again

Hannes,

In-line.... 

....snip......

....snip......

I'll ask the same question again.  Why doesn't a LbyR dereference
provide
the same?

-Marc-

---

From: "Dawson, Martin" <[email-masked]>
Date: Mon, 26 Nov 2007 07:48:32 -0600

That's very true - and, when it comes to confidence (which specifies the
percentage of times the actual location will be in the area of
uncertainty), the value doesn't even have to be constrained by the
physical network characteristics. It's also about the statistical
behaviour of the user population - and how usable the whole coverage
area is.

If 99% of users spend 99% of their time within a 1% area of the
coverage, then the location server may even be configured to provide a
much smaller location result than that defined by the RF characteristics
of the network but still provide a quite good value of confidence...
however variable the coverage may be.

Cheers,
Martin

-----Original Message-----
From: Dawson, Martin [mailto:[email-masked]] 
Sent: Tuesday, 27 November 2007 12:40 AM
To: Marc Berryman; Winterbottom, James; Brian Rosen; Hannes Tschofenig
Cc: [email-masked]
Subject: RE: [Geopriv] Message Flow

Hi Marc,

Cheers,
Martin

-----Original Message-----
From: Marc Berryman [mailto:[email-masked]] 
Sent: Tuesday, 27 November 2007 12:13 AM
To: Winterbottom, James; Brian Rosen; Hannes Tschofenig
Cc: [email-masked]
Subject: RE: [Geopriv] Message Flow

Marc Berryman

-----Original Message-----
From: Winterbottom, James [mailto:[email-masked]] 
Sent: Sunday, November 25, 2007 3:19 AM
To: Brian Rosen; Hannes Tschofenig
Cc: [email-masked]
Subject: RE: [Geopriv] Message Flow

Why?

Cheers
James 

draft

---

From: "Marc Berryman" <[email-masked]>
Date: Mon, 26 Nov 2007 07:49:22 -0600

Martin,
 I do appreciate your (long-winded) response as it puts your comment
into context.
For your example I would think that the location determination used for
routing is not a major flaw, actually it is not a flaw but simply a
manner in which to route on the best available information.

I would think the PSAP would indeed to a "dynamic reassessment" based on
any new information and / or the uncertainty associated with the
location. This is exactly what happens today with a wireless call, so no
problem there. 

I would prefer we make the architecture/implementation as cost effective
and simple as possible, we can always tweak it later if needed.

Thanks for taking the time to provide the response.

Marc B

-----Original Message-----
From: Dawson, Martin [mailto:[email-masked]] 
Sent: Monday, November 26, 2007 7:40 AM
To: Marc Berryman; Winterbottom, James; Brian Rosen; Hannes Tschofenig
Cc: [email-masked]
Subject: RE: [Geopriv] Message Flow

Hi Marc,

Cheers,
Martin

-----Original Message-----
From: Marc Berryman [mailto:[email-masked]] 
Sent: Tuesday, 27 November 2007 12:13 AM
To: Winterbottom, James; Brian Rosen; Hannes Tschofenig
Cc: [email-masked]
Subject: RE: [Geopriv] Message Flow

Marc Berryman

-----Original Message-----
From: Winterbottom, James [mailto:[email-masked]] 
Sent: Sunday, November 25, 2007 3:19 AM
To: Brian Rosen; Hannes Tschofenig
Cc: [email-masked]
Subject: RE: [Geopriv] Message Flow

Why?

Cheers
James 

draft

---

From: "Marc Linsner" <[email-masked]>
Date: Mon, 26 Nov 2007 11:08:14 -0500

Martin, 

> I'm not sure you meant to ask the question you did.

No, it's the right question.

> 
> Location by reference would require the device to consult the 
> LIS to get the reference which was then used by the proxy to 
> dereference with. The scenario under discussion is where the 
> device doesn't have any native ability to interact with a LIS 
> so it can't provide a reference for the proxy to use.
> 

Is it through some divine intervention that the proxy can assemble the HELD
LCP request including the proposed identity extensions but can't put
together the suggested URI?

-Marc-

---

From: "Stark, Barbara" <[email-masked]>
Date: Mon, 26 Nov 2007 14:04:00 -0500

I think I'm finally caught up on this thread. That's what I get for
sending an email and then leaving on holiday for 5 days.

Anyway, I believe that within the context of HTTP, that the ID could be
provided either in the uri or as an extension. I don't know enough about
BEEP and other potential protocols to understand how URIs function in
the context of those protocols.

The major reason I like the extensions proposal is because it exists.
It's been thought through, and submitted as a personal draft. The "make
it part of the URI" proposal hasn't been documented. I don't have
anything that suggests how to identify IDs (PVC, IP address, etc.), and
how to delimit multiple IDs, etc. It's hard for me to compare the two
proposals, without the URI approach being fully documented.

I do know that I need for the ISP LIS to be able to send the access
provider LIS exactly the HELD parameters that the device used when
querying it. This means I do need HELD.

A bird in the hand...

Barbara

-----Original Message-----
From: Marc Linsner [mailto:[email-masked]] 
Sent: Monday, November 26, 2007 11:08 AM
To: 'Dawson, Martin'; [email-masked]
Subject: RE: [Geopriv] Message Flow, again

Martin, 

> so it can't provide a reference for the proxy to use.

Is it through some divine intervention that the proxy can assemble the
HELD
LCP request including the proposed identity extensions but can't put
together the suggested URI?

-Marc-

*****

The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential, proprietary, and/or privileged material. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon this information by persons or entities other than the intended recipient is prohibited. If you received this in error, please contact the sender and delete the material from all computers. GA625

---

From: "James M. Polk" <[email-masked]>
Date: Mon, 26 Nov 2007 13:26:56 -0600

Hannes

>I think your position below is at odds with NENA and most folks I talk

Then I would say they do not really understand SIP, nor have they 
really read SIP Location Conveyance.

>I agree that the area is a little grey though.

You are wrong, and this isn't grey at all.  SIP Location Conveyance, 
the document, *DOES*NOT* define how to seek someone else's location, EVER.

Location-by-reference has location sent to the intended Location 
Recipient ONCE. If SIP or Presence is used for dereferencing, this 
occurs in the NOTIFY request, which is CONVEYING location to the 
Location Recipient.  This is the only time actual location is in any 
message, and with an LbyR, it is sent indirectly in the initial 
request (or UPDATE), but it is still SENT.

I'm not sure how much clearer I, as the document author, can state this.

I don't care what NENA (no offense), or any other organization says 
in this regard. The document is about conveying which, in English, 
this means sending out or transmitting or telling, not seeking and learning.

To put this simply, Location Conveyance does not give rules for Alice 
to seek and 'go get' Bob's location.  It does provide rules for how 
Alice tells Bob her location (by-value and by-reference).

The SIP WG and Jon Peterson, the RAI AD, are very clear on this 
separation of what SIP Conveyance is accomplishing.

This document has been around for 4 years now, and it has said this 
explicitly since IETF63 (Paris), without change.

---

From: Hannes Tschofenig <[email-masked]>
Date: Mon, 26 Nov 2007 20:52:39 +0100

I guess you wanted to respond to James rather than me. I know what the 
SIP Location Conveyance document since I reviewed it several times.

> I don't care what NENA (no offense), or any other organization says in 
> this regard. The document is about conveying which, in English, this 
> means sending out or transmitting or telling, not seeking and learning.
>

---

From: "Winterbottom, James" <[email-masked]>
Date: Mon, 26 Nov 2007 14:14:08 -0600

Hi Marc,

Actually I think your response supports my argument.
The PSAP would prefer to have the most accurate location presented to
it, and not necessarily the location that was used to route the call to
it.

Cheers
James

> > The context draft doesn't match the syntax of -conveyance, which
means
> we
> > > > No, that is not sufficient.  The PSAP (or any location
recipient)
> > > can't do

---

From: "Winterbottom, James" <[email-masked]>
Date: Mon, 26 Nov 2007 15:04:05 -0600

I'm James but to me your response isn't clear at all.
I shall go through it and ask questions if you don't mind.

By your definition, if the reference is a held URI, then dereference is
retrieval because it is being sort 

> the document, *DOES*NOT* define how to seek someone else's location,
EVER.

[AJW] So, by this statement does it allow it?
If you send a SIP or pres location URI to someone, and they can
subscribe to that location URI then you do define how to acquire someone
else's location. Indeed I would argue that this is a planned use. If
this is not to be allowed then you should have explicit statements in
the document saying that the subscription mechanism is only applicable
to a URI that references your own location.

> Recipient ONCE.

[AJW] I don't understand this statement at all. Are you saying that all
location URIs may only be used once? That all only one notify is ever
sent to the recipient?

 If SIP or Presence is used for dereferencing, this
> Location Recipient.

[AJW] I can equally argue that a NOTIFY should not be sent to me unless
I subscribe for it first, which is an explicit request to "retrieve"
location.

  This is the only time actual location is in any
> request (or UPDATE), but it is still SENT.
[AJW] I think that this is saying that sending a location URI is
conveyance. I fully agree with this statement.

> this means sending out or transmitting or telling, not seeking and

[AJW] Yes, which would exclude a NOTIFY sent in response to at least the
initial SUBSCRIBE since that involves a seek. It would also exclude HELD
or HTTP URIs since they are always seek. Hopefully this clarifies the
absurdity, and why conveyance in the wider community has come to mean
from Target to Recipient, and retrieval is used from LIS to Recipient. 

--
--

---

From: Hannes Tschofenig <[email-masked]>
Date: Mon, 26 Nov 2007 22:07:50 +0100

Hi all,

we had many terminology discussions in this group about conveyance, 
location retrieval, Using Protocols, etc.

All these discussions lead to absolutely NOTHING. We did not learn 
anything new. It was just a complete waste of time. We aren't even left 
with good terminology*.

Maybe it is time to throw some of the old (and not so well defined) 
terms aboard and develop better onces (if someone has the energy). Btw, 
Richard has already taken the first step to re-work the terminology and 
the architecture, see 
http://tools.ietf.org/wg/geopriv/draft-barnes-geopriv-lo-sec-01.txt

Ciao
Hannes

(*): Together with Henning we tried to write a tutorial about GEOPRIV 
and we noticed that the GEOPRIV requirements RFC (that outlines also 
architectural parts) is very much outdated and does not help to present 
a solid story.

---

From: "Thomson, Martin" <[email-masked]>
Date: Mon, 26 Nov 2007 15:50:45 -0600

Actually Marc, I think that you are mistaking a URI for a location reference.  What you are talking about there is an OBO.  Alternatively, it's a yet-undefined protocol - that is, the protocol indicated by an 'ip:' URI that yields location information.

---

From: "Dawson, Martin" <[email-masked]>
Date: Mon, 26 Nov 2007 15:55:37 -0600

Actually "location conveyance" is about any application protocol sending
a piece of location information (value or reference) from one peer to
another for some purpose within the scope that application. To this
extent the existence of the location information is peripheral to the
fact of the application protocol. Conveyance is between any two entities
- it doesn't matter if the location represents either signalling peer,
the location of some other entity or, indeed, whether it's describing
the location of a specific entity at all.

Location retrieval on the other hand is about the process of one
signalling peer specifically asking for the location of some target. In
this case the location information is the specific subject of the
signalling exchange and there is no other application context in which
it is subject to interpretation. Doing a dereference is definitely a
location retrieval and trying to regard it as something else is a
slippery slope to confusion.

SIP conveyance may have been written with the intention of it supporting
a conveyance context. As soon as it's used to do an actual location
acquisition request, then it's being used for location retrieval.
Neither the name of the spec nor the intent of the writer can somehow
change that fact.

Cheers,
Martin

-----Original Message-----
From: Winterbottom, James [mailto:[email-masked]] 
Sent: Tuesday, 27 November 2007 8:04 AM
To: James M. Polk; Hannes Tschofenig; Marc Linsner
Cc: [email-masked]
Subject: RE: [Geopriv] draft agenda: GEOPRIV @ IETF 70

--
--

---

From: "Dawson, Martin" <[email-masked]>
Date: Mon, 26 Nov 2007 15:57:22 -0600

And, even then, it's a yet-undefined protocol whose purpose is
apparently to provide OBO functionality...

-----Original Message-----
From: Thomson, Martin [mailto:[email-masked]] 
Sent: Tuesday, 27 November 2007 8:51 AM
To: Marc Linsner; Hannes Tschofenig; [email-masked]
Subject: RE: [Geopriv] Message Flow, again

Actually Marc, I think that you are mistaking a URI for a location
reference.  What you are talking about there is an OBO.  Alternatively,
it's a yet-undefined protocol - that is, the protocol indicated by an
'ip:' URI that yields location information.

provide

---

From: "James M. Polk" <[email-masked]>
Date: Mon, 26 Nov 2007 16:03:26 -0600

>retrieval because it is being sort

no, this is where you seem to go in a wrong direction and continue 
down that path for all your other comments.

Take the SIP flow

      Alice                 Location Server                      Bob
        |                                                         |
        |        INVITE w/ Location-by-Reference URI              |
        |-------------------------------------------------------->|
        |                          |                              |
        |                       200 (OK)                          |
        |<--------------------------------------------------------|
        |                          |                              |
        |                          |  SUBSCRIBE to LbyR URI       |
        |                          |<-----------------------------|
        |                          |  200 (OK)                    |
        |                          |----------------------------->|
        |                          |                              |
        |                          |  NOTIFY   w/ PIDF-LO         |
        |                          |----------------------------->|
        |                          |  200 (OK)                    |
        |                          |<-----------------------------|
        |                          |                              |

            Figure 2. Location-by-Reference and Dereferencing

This is Figure 2 on page 19 of
http://www.ietf.org/internet-drafts/draft-ietf-sip-location-conveyance-09.txt

This is what SIP calls Content Indirection, and is a Standards Track 
RFC already (RFC4483).

In Alice's INVITE above, she doesn't provide Bob with her Location, 
she provides him with a reference to her location.

The scheme of the URI provided by Alice informs Bob which protocol he 
uses to dereference the remotely stored (location) information.

If the LbyR is a sip:, sips:, or pres: URI, Bob uses an RFC3265 
defined SUBSCRIBE request to the remote node that has the (location) 
information ALICE is sending Bob.  The key is Alice is still sending 
Bob her (location) information at this point.

If that subscription is accepted, the remote node will reply with a 
200 OK response.  Once the server has the (location) information, 
which may not be right away in all cases  (in SIP), the remote node 
(the LIS in this case) sends the location-by-value in an RFC 3265 
defined NOTIFY request.  This is the completion of Alice *sending* 
Bob her location.  This is how SIP works.

I'm sorry if you disagree with this, but you'll have to bring that up 
with the entire SIP WG/community if you want that changed.

>else's location.

yes, but this is still sending location, not going out and getting 
their location.

>Indeed I would argue that this is a planned use. If

Huh?.... no

Conveyance is all about sending or pushing location from a sending 
entity to a receiving entity.  If Alice sends an LbyR URI to Bob, he 
hasn't YET received her location, because it has not been 
dereferenced.  Dereferencing a received URI is part of the 
multi-transaction conveyance process.

>location URIs may only be used once?

No, I'm saying the LbyR is only in on request message from Alice to 
Bob.  Alice doesn't include her actual location with an LbyR.

>That all only one notify is ever sent to the recipient?

The number of NOTIFYs is a function of the type of subscription the 
SUBSCRIBE requested (which was accepted).

Conveyance has no limit on this, on purpose, and this was agreed to 
in the Geopriv meeting in Chicago explicitly.

>I subscribe for it first, which is an explicit request to "retrieve"

I agree with you here. A NOTIFY with location-by-value needs to have 
an active subscription, initiated by a SUBSCRIBE.

>conveyance. I fully agree with this statement.

but Location hasn't been conveyed until the Location Recipient 
dereferences the LbyR URI (part of the SUB/NOT transactions in SIP)

>initial SUBSCRIBE since that involves a seek.

NOTIFY is a request message in SIP.  A 200 OK is the successful 
response to a SUBSCRIBE that creates a subscription.  After this 200 
OK, the SIP entity sends a NOTIFY containing the results of the 
subscription.  There are many forms of subscriptions BTW, including 
"one time only", "fixed duration", "pending", "refreshed when state 
information changes", "refresh at agreed to time interval", etc...

>It would also exclude HELD

see the flow above

it is all about getting the actual location-by-value to the Location 
Recipient, sometimes that's directly in the first message, and 
sometimes that indirectly via a dereferenceable URI... it's still "conveyance".

---

From: "Marc Linsner" <[email-masked]>
Date: Mon, 26 Nov 2007 17:08:38 -0500

Martin,

The omission of protocol is/was on purpose.

-Marc- 

> 
> Actually Marc, I think that you are mistaking a URI for a 
> location reference.  What you are talking about there is an 
> OBO.  Alternatively, it's a yet-undefined protocol - that is, 
> the protocol indicated by an 'ip:' URI that yields location 
> information.
> 
> > > wants to allow the location recipient to obtain the location 
> > > information. The request contains the HELD identity extension 
> > > containing the IP address of UA sending the SIP INVITE message.
> > >
> > provide the same?

---

From: "Dawson, Martin" <[email-masked]>
Date: Mon, 26 Nov 2007 16:56:45 -0600

So - to cut to the chase - you're proposition is that no formal
specification for performing OBO ever be defined; it should forever be
informal and be left to mutual convention on a per-implementation basis?

In which case, really, we just need to seek consensus on whether that is
the preferred approach or whether there should be a formal
specification?

Cheers,
Martin

-----Original Message-----
From: Marc Linsner [mailto:[email-masked]] 
Sent: Tuesday, 27 November 2007 9:09 AM
To: Thomson, Martin; [email-masked]
Subject: RE: [Geopriv] Message Flow, again

Martin,

-Marc-

---

From: "James M. Polk" <[email-masked]>
Date: Mon, 26 Nov 2007 17:29:26 -0600

At 03:55 PM 11/26/2007, Dawson, Martin wrote:
>another for some purpose within the scope that application.

I agree with this above, and sometimes shorten SIP Location 
Conveyance to either Location Conveyance or just Conveyance.

That said, Conveying a LbyR is conveying indirection location, 
necessitating a dereference signal from the Location Recipient to 
have the actual location conveyed to them.

In SIP, this conveyance is done in the message body of a SIP request, 
which is location-by-value

*OR*

from a NOTIFY after the Location Recipient subscribes to the entity 
within the LbyR URI.  The NOTIFY does not create the subscription. A 
SUBSCRIBE does, which is a SIP request.  The NOTIFY is also a SIP 
request - and not a response.

>To this
>signalling peer specifically asking for the location of some target.

If I want to search for your location, Martin, getting your location 
is retrieval.

In SIP Indirection, fetching for location at a received LbyR URI you 
sent to me is *not* retrieval, it is conveyance - since it is still 
part of the set of transactions involved in conveyance (of an LbyR URI).

This is the wrong list to bring this up, since both the 
sip-location-conveyance is not a Geopriv WG item, and Geopriv has 
little to nothing to do with the signaling.

>In

Well.... SIP Location Conveyance has existed since 2003, before NENA 
became involved in the IETF.  When did you start or respond to a 
thread that stated this definition on the SIP list?

>acquisition request, then it's being used for location retrieval.

I disagree exactly here, as a function of timing.  If a SIP request 
contains a LbyR as a means of one entity telling another entity a 
location, the dereference is part of that transaction process, and 
it's still conveyance.

If one entity out-of-the-blue dereferences an LbyR to a server that 
wasn't just sent to the dereferencing entity, this is retrieval, and 
SIP Location Conveyance does not cover that scenario.

If this is too confusing, I can easily take all text related to LbyR 
out of the SIP Location Conveyance ID before it progresses further... 
you tell me which you want

>Neither the name of the spec nor the intent of the writer can somehow

How about the intent of the spec, by the direction of the relevant 
Area Director on this exact topic (at IETF63 (Paris)), but in that other WG?

Search the archives

---

From: "Dawson, Martin" <[email-masked]>
Date: Mon, 26 Nov 2007 17:44:31 -0600

You're suggesting that location-by-reference is a two step *conveyance*
process. I actually consider it to be more sensibly a two step
*retrieval* process.

If requesting a reference isn't a retrieval (since no location is
provided) and doing the dereference isn't retrieval either, then you are
suggesting that no retrieval happened at all. What's important, really,
is whether the actual location provided is as the result of a
determination of location being given. If you're actually talking about
a location reference that points to some other sort of function, then
I'd agree with you. In the context of this discussion, however, it's a
retrieval operation.

You can argue all you like that you somehow have more qualifications to
have an opinion than I do but I neither accept that nor consider it any
reason to regard one opinion more correct than another.

Cheers,
Martin

-----Original Message-----
From: James M. Polk [mailto:[email-masked]] 
Sent: Tuesday, 27 November 2007 10:29 AM
To: Dawson, Martin; Winterbottom, James; Hannes Tschofenig; Marc Linsner
Cc: [email-masked]
Subject: RE: SIP Conveyance vs Retrieval

*OR*

How about the intent of the spec, by the direction of the relevant 
Area Director on this exact topic (at IETF63 (Paris)), but in that other
WG?

Search the archives

> > > > BTW - I don't consider a dereference "location retrieval",
that's
> > > > conveyance.
-
-
-------------------------
>this email is prohibited.
-------------------------

---

From: "Carl Reed OGC Account" <[email-masked]>
Date: Mon, 26 Nov 2007 18:37:55 -0700

If it makes everyone feel any better - this from the Image Geopositioning 
Service Interface standards working group in the OGC:

Relative to item 1) in my message copied below, I scanned the ASPRS
Manual of Photogrammetry fifth edition (2004) for the terms
georeferencing, geopositioning, and geolocation or similar.  As I said,
this manual does not include a dictionary of terms or even formal
definitions of any terms.  I found the terms georeferencing and
geopositioning used in different sections, with unclear meanings.  I
also found several sections where one of these terms would have fit, but
was not used.  I did not find any uses of the term geolocation or
similar.

I conclude that this Manual of Photogrammetry does not provide any
information that would help the IGS RWG in deciding what terms to use.

Arliss

FYI: Image geopositioning is about the ability to control image 
rectification from real time imagery collection systems, such as when 
digital imagery is being provided as a data stream from an Unmanned Aerial 
Vehicle (UAV).

Having said the above, ISO TC 211 does maintain a fairly extensive 
terminology database of terms used in the geospatial community.

Cheers

Carl

----- Original Message ----- 
From: "Hannes Tschofenig" <[email-masked]>
To: "James M. Polk" <[email-masked]>
Cc: <[email-masked]>; "Marc Linsner" <[email-masked]>
Sent: Monday, November 26, 2007 2:07 PM
Subject: [Geopriv] Religious Terminology Discussions

> Maybe it is time to throw some of the old (and not so well defined) terms 
> aboard and develop better onces (if someone has the energy). Btw, Richard 
> has already taken the first step to re-work the terminology and the 
> architecture, see 
> (*): Together with Henning we tried to write a tutorial about GEOPRIV and 
> we noticed that the GEOPRIV requirements RFC (that outlines also 
> architectural parts) is very much outdated and does not help to present a 
> solid story.
>
>
>
>
> James M. Polk wrote:
>> Location Conveyance does not define how any entity retrieves location - 
>> so this flow should be interesting.
>>
>>>>> and/or a LbyR from the LIS. I believe that the two entities, namely 
>>>>> the SIP proxy and the LIS, will not be co-located in realistic 
>>>>> deployments. A simple protocol is needed. The HELD identity extension

---

From: "Marc Linsner" <[email-masked]>
Date: Tue, 27 Nov 2007 09:04:56 -0500

Martin,

1) I believe we need strong consensus that the IETF/Geopriv is going to
support OBO.  I don't find or remember the wg agreeing on this, in fact, I
remember the opposite.

2) I was simply trying to show how one might use an aberration of an
accepted mechanism, LbyR, to accomplish the function, saving the pain of #1.

-Marc-

> Sent: Monday, November 26, 2007 5:57 PM
> To: Marc Linsner; Thomson, Martin; [email-masked]
> So - to cut to the chase - you're proposition is that no 
> formal specification for performing OBO ever be defined; it 
> should forever be informal and be left to mutual convention 
> on a per-implementation basis?
> 
> In which case, really, we just need to seek consensus on 
> whether that is the preferred approach or whether there 
> should be a formal specification?
> 
> Cheers,
> Martin
> 
> > reference.  What you are talking about there is an OBO.  
> > Alternatively, it's a yet-undefined protocol - that is, the 
> protocol 
> > indicated by an 'ip:' URI that yields location information.
> > 
> > This message is for the designated recipient only and may contain 
> > privileged, proprietary, or otherwise private information.
> immediately 
> > and delete the original.  Any unauthorized use of this email is 
> > prohibited.

---

From: Hannes Tschofenig <[email-masked]>
Date: Tue, 27 Nov 2007 15:07:17 +0100

Hi Marc,

> support OBO.  I don't find or remember the wg agreeing on this, in fact, I

SIP Location Conveyance is a form of OBO.

Ciao
Hannes

>>>>> Now, assume that a the proxy does location based 
>>>>>           
>> routing and also 
>>

---

From: "Marc Linsner" <[email-masked]>
Date: Tue, 27 Nov 2007 09:14:39 -0500

Hannes, 

> SIP Location Conveyance is a form of OBO.

IMO, since the location being conveyed belongs to the 'caller', it's not
OBO.

-Marc-

---

From: Hannes Tschofenig <[email-masked]>
Date: Tue, 27 Nov 2007 15:18:49 +0100

But the location is always about the caller, the Target in all of the 
discussed cases.
We just using different protocol variations here.

Ciao
Hannes

---

From: "Brian Rosen" <[email-masked]>
Date: Tue, 27 Nov 2007 09:19:09 -0500

Huh, how do you distinguish?

The proxy is inserting location on behalf of the caller.

What other form of OBO is there?

Brian

> Sent: Tuesday, November 27, 2007 9:15 AM
> To: 'Hannes Tschofenig'
> Cc: [email-masked]
> Subject: RE: OBO (was - RE: [Geopriv] Message Flow, again)
> 
> Hannes,
> 
> 
> >

---

From: Hannes Tschofenig <[email-masked]>
Date: Tue, 27 Nov 2007 15:22:07 +0100

You could attach the location of the SIP proxy :-)

---

From: "Marc Linsner" <[email-masked]>
Date: Tue, 27 Nov 2007 09:31:22 -0500

Brian, 

> What other form of OBO is there?

2 use cases

1) The proxy figuring out where the caller is located.
2) LIS to LIS

-Marc-

> > IMO, since the location being conveyed belongs to the 
> 'caller', it's 
> > not OBO.
> > 
> > -Marc-
> > 
> >

---

From: Hannes Tschofenig <[email-masked]>
Date: Tue, 27 Nov 2007 15:38:39 +0100

But LIS-to-LIS is also another step towards finding the location of the 
caller

---

From: "Brian Rosen" <[email-masked]>
Date: Tue, 27 Nov 2007 09:48:32 -0500

To me LIS-LIS is not OBO.

LIS-LIS is a separate problem.  I agree we have yet to undertake such work
in Geopriv.  I may be willing to look at it, depending on where we are with
our milestones. It comes after a lot of other parts I want to see finished.

Brian

> Sent: Tuesday, November 27, 2007 9:39 AM
> To: Marc Linsner
> Cc: 'Brian Rosen'; [email-masked]
> Subject: Re: OBO (was - RE: [Geopriv] Message Flow, again)
>

---

From: Hannes Tschofenig <[email-masked]>
Date: Tue, 27 Nov 2007 15:55:22 +0100

Please read the LIS-to-LIS document and tell me again why this is not OBO.

---

From: "Marc Linsner" <[email-masked]>
Date: Tue, 27 Nov 2007 09:56:21 -0500

Brian, 

> To me LIS-LIS is not OBO.

I don't what we call it.  Give a label.

Can we agree that SIP proxy location discovery and LIS to LIS are the same?

-Marc-

> 
> LIS-LIS is a separate problem.  I agree we have yet to 
> undertake such work in Geopriv.  I may be willing to look at 
> it, depending on where we are with our milestones. It comes 
> after a lot of other parts I want to see finished.
> 
> Brian
> 
> > But LIS-to-LIS is also another step towards finding the location of 
> > the caller
> > 
> > Marc Linsner wrote:
> > > Brian,
> > >
> > >

---

From: "Brian Rosen" <[email-masked]>
Date: Tue, 27 Nov 2007 10:05:52 -0500

Let's call it, uh, "LIS-LIS".
OBO is proxy (or other intermediary) insertion of location on behalf of an
endpoint.

LIS-LIS is location exchange between LIS'

Note that the "intermediary" in OBO is not a LIS.

I don't know what SIP Proxy location discovery means.  If it's how the proxy
in OBO gets location then it's something else.  Need a name for that. OBO
isn't necessarily SIP specific, so something like Intermediary Location
Discovery?

Brian

> Sent: Tuesday, November 27, 2007 9:56 AM
> To: 'Brian Rosen'
> Cc: [email-masked]
> Subject: RE: OBO
> 
> Brian,
>

---

From: "Stark, Barbara" <[email-masked]>
Date: Tue, 27 Nov 2007 10:15:57 -0500

I suspect that a protocol that is able to support LIS-LIS can also be
used to support "Intermediary Location Discovery". As a corollary, I
also suspect that it would be very difficult to design a LIS-LIS
solution that could not also be used by an "intermediary".

On the other hand, I think it would be possible for a protocol/URI
scheme that met the needs of an "intermediary", to not meet the needs of
LIS-LIS.

They aren't quite the same. But if LIS-LIS is solved, then the
"intermediary" problem will also likely be solved, for good or for bad,
and independent of whether or not that's desirable.
Barbara

-----Original Message-----
From: Brian Rosen [mailto:[email-masked]] 
Sent: Tuesday, November 27, 2007 10:06 AM
To: 'Marc Linsner'
Cc: [email-masked]
Subject: [Geopriv] RE: OBO

Let's call it, uh, "LIS-LIS".
OBO is proxy (or other intermediary) insertion of location on behalf of
an
endpoint.

I don't know what SIP Proxy location discovery means.  If it's how the
proxy
in OBO gets location then it's something else.  Need a name for that.
OBO
isn't necessarily SIP specific, so something like Intermediary Location
Discovery?

Brian

---

From: "Brian Rosen" <[email-masked]>
Date: Tue, 27 Nov 2007 10:39:50 -0500

Suppose I am an ISP and I lease services from an underlying access network.
I want to supply a LIS for my customers.  I contract with my underlying
access network to give me location for my customers. 

I run a real LIS.  My access network provider runs a real LIS.  I need to
get location for my customers.  That's LIS-LIS.  I am giving LIS to
endpoints.  That's why I want to differentiate.

In my notion of OBO, an intermediary is inserting location on behalf of an
endpoint.  To me, that's an entirely different thing.  I claim the
intermediary is not a LIS; it's getting location from a LIS and putting it
into a "call".  The proxy is a client to a LIS.  There is no client to the
intermediary.

It's okay with me if the protocols for this are the same, but I think the
use case is different, and the roles are different.

Brian

> Sent: Tuesday, November 27, 2007 9:55 AM
> To: Brian Rosen
> Cc: 'Marc Linsner'; [email-masked]

---

From: "Marc Linsner" <[email-masked]>
Date: Tue, 27 Nov 2007 10:43:29 -0500

OK, so we have two labels, I don't care.

So under the heading of Location Discovery OBO we have two items:

LIS to LIS (LIS2LIS)
SIP Proxy Location Discovery to be used for SIP Proxy Location Conveyance
OBO (SPLDtbufSPLCOBO)  :^)

-Marc-

> OBO is proxy (or other intermediary) insertion of location on 
> behalf of an endpoint.
> 
> I don't know what SIP Proxy location discovery means.  If 
> it's how the proxy in OBO gets location then it's something 
> else.  Need a name for that. OBO isn't necessarily SIP 
> specific, so something like Intermediary Location Discovery?
> 
> Brian
> 
> > Can we agree that SIP proxy location discovery and LIS to 
> LIS are the 
> > same?
> > 
> > -Marc-
> > 
> > >
> > > LIS-LIS is a separate problem.  I agree we have yet to undertake 
> > > such work in Geopriv.  I may be willing to look at it, 
> depending on 
> > > where we are with our milestones. It comes after a lot of other 
> > > parts I want to see finished.
> > >
> > > Brian
> > >
> > > > But LIS-to-LIS is also another step towards finding the 
> location 
> > > > of the caller
> > > >
> > > > Marc Linsner wrote:
> > > > > Brian,
> > > > >
> > > > >

---

From: "Roger Marshall" <[email-masked]>
Date: Tue, 27 Nov 2007 11:41:18 -0800

Hi Carl, 
Which term(s), according to this or other GIS related sources, relate
solely to a lat/lon coordinate pair, as in a specific 2-D grid-based
position?  It isn't clear to me, so I've made the following
observations/assumptions in an effort to get a common set of terms.

I scanned the ISOTC 211 (http://www.isotc211.org/) glossary, but found
terms which only came close, such as:

geodetic latitude
geodetic longitude
geographic data
coordinate set
coordinate tuple
data
data element
dataset
direct position*
point
position
spacial reference

All these are ok, yet there are many terms not found in the ISO/TC 211
glossary, but which have been popularized in industry and within some
IETF drafts, and that have been used more-or-less interchangeably.  For
the 2-D case, these include (non-exhaustive):

geographic location
geographic position
geoposition
geodetic location
geodetic position
geo location
geo position
geo
coordinate pair
coordinate location
coordinate position
lat/lon coordinates
lat/lon pair
lat/lon
x,y
...

Assuming all of the terms in this second list are trying to get at the
same thing (which I don't necessarily agree should be the case), when
comparing to the ISO/TC 211 terms, it seemed to me that the term,
'direct position', fit's best (it's possible I missed spotting a better
one).

The definition for 'direct position' seems adequate: 

"position described by a single set of coordinates within a coordinate
reference system"

...but the term itself falls short as being self-described when compared
to potential alternatives, such as: "geographic position" or "coordinate
position", either of which I would prefer when representing the
definition for 'direct position'.

-roger marshall.

> From: Carl Reed OGC Account [mailto:[email-masked]] 
> Sent: Monday, November 26, 2007 5:38 PM
> To: Hannes Tschofenig; James M. Polk
> Cc: [email-masked]; Marc Linsner
> Subject: Re: [Geopriv] Religious Terminology Discussions
> 
> If it makes everyone feel any better - this from the Image 
> Geopositioning Service Interface standards working group in the OGC:
> 
> Relative to item 1) in my message copied below, I scanned the 
> ASPRS Manual of Photogrammetry fifth edition (2004) for the 
> terms georeferencing, geopositioning, and geolocation or 
> similar.  As I said, this manual does not include a 
> dictionary of terms or even formal definitions of any terms.  
> I found the terms georeferencing and geopositioning used in 
> different sections, with unclear meanings.  I also found 
> several sections where one of these terms would have fit, but 
> was not used.  I did not find any uses of the term 
> geolocation or similar.
> 
> I conclude that this Manual of Photogrammetry does not 
> provide any information that would help the IGS RWG in 
> deciding what terms to use.
> 
> Arliss
> 
> FYI: Image geopositioning is about the ability to control 
> image rectification from real time imagery collection 
> systems, such as when digital imagery is being provided as a 
> data stream from an Unmanned Aerial Vehicle (UAV).
> 
> Having said the above, ISO TC 211 does maintain a fairly 
> extensive terminology database of terms used in the 
> geospatial community.
> 
> Cheers
> 
> Carl
> 

CONFIDENTIALITY NOTICE: The information contained in this message may be privileged and/or confidential. If you are not the intended recipient, or responsible for delivering this message to the intended recipient, any review, forwarding, dissemination, distribution or copying of this communication or any attachment(s) is strictly prohibited. If you have received this message in error, please notify the sender immediately, and delete it and all attachments from your computer and network.

---

From: "Dawson, Martin" <[email-masked]>
Date: Tue, 27 Nov 2007 15:37:28 -0600

Hi Marc,

The scenario being discussed is an OBO and the need is well recognized.
How do you suggest formalizing the decision that OBO is a valid use
case?

Once again, Marc, you are not talking about LbyR. Location by reference
involves asking the location server for a reference and then having the
actual location provided as the result of a subsequent dereference. The
scenario you are describing is just an LbyV request (in fact, an OBO
LbyV) with a parameterized URI.

Cheers,
Martin

-----Original Message-----
From: Marc Linsner [mailto:[email-masked]] 
Sent: Wednesday, 28 November 2007 1:05 AM
To: Dawson, Martin; [email-masked]
Subject: OBO (was - RE: [Geopriv] Message Flow, again)

Martin,

1) I believe we need strong consensus that the IETF/Geopriv is going to
support OBO.  I don't find or remember the wg agreeing on this, in fact,
I
remember the opposite.

2) I was simply trying to show how one might use an aberration of an
accepted mechanism, LbyR, to accomplish the function, saving the pain of
#1.

-Marc-

---

From: "Carl Reed OGC Account" <[email-masked]>
Date: Tue, 27 Nov 2007 14:42:29 -0700

Roger -

*Warning* - a bit lengthy.

Appears that you have put your finger on one of the long standing issues in the traditional GIS community! For decades, every vendor, every research project, every standards organization seems to have wanted to put their own imprint on the discipline by defining a new term instead of using a term that had been previously defined. Causes a bit of a semantic issue, doesn't it! And your list while well researched is not complete. There are other terms in use also. In the OGC, we have been able to "pin down" and agree on a number of terms and phrases, such as coordinate, coordinate pair, coordinate system, and coordinate reference system. For example, the following are from 19107 and used in all OGC and ISO standards related to geo content:

4.19
coordinate
one of a sequence of numbers designating the position of a point in N-dimensional space
NOTE In a coordinate reference system, the numbers must be qualified by units.
4.20
coordinate dimension
number of measurements or axes needed to describe a position in a coordinate system
4.21
coordinate reference system
coordinate system that is related to the real world by a datum
[ISO 19111]
4.22
coordinate system
set of (mathematical) rules for specifying how coordinates are to be assigned to points

Notice that none of these definitions refer to lat/long or a geodetic point etc. Point is handled as follows:

4.61
point
0-dimensional geometric primitive, representing a position
NOTE The boundary of a point is the empty set.

So we still need another definition:

4.26
direct position
position described by a single set of coordinates within a coordinate reference system

So, Roger, you are correct. Direct position AKA position is the best overall generic term. However, please remember that this is a generic term with regard to location in space - not just on the earth. This is why there is no reference to geo this and geo that. As a matter of fact, there are many different coordinate systems - not just a geodetic coordinate systems. There are local coordinate systems, dynamic coordinate systems, linear coordinate systems, polar coordinate systems. Hence the generality (or abstraction) of the definition for "direct position" used in ISO and the OGC. FYI, the OGC members have formed an ad-hoc group to develop a general model for all coordinate systems that could be used in the geo space.

I agree, as you point out, that it sure would be nice to have a self describing term we could all use to describe a position on the surface (or above/below) of the earth. 

The final piece of the puzzle is to be found in 19111 - Spatial Referencing by coordinates. In that document, we find:
 
4.26 
geodetic latitude 
ellipsoidal latitude 
ϕ 
angle from the equatorial plane to the perpendicular to the ellipsoid through a given point, northwards treated as positive 
4.27 
geodetic longitude 
ellipsoidal longitude 
λ 
angle from the prime meridian plane to the meridian plane of a given point, eastward treated as positive 

Now a bit of a kicker. When dealing with lat/long such as in WGS 84, the terminology used is "geographic coordinates". and "geographic coordinate reference system" or for short "geographics". In terms of other CRS, as a geometric process, in general a map projection is a set of formulae that converts geodetic latitude and longitude to plane (map) coordinates AKA planar coordinates. 

If you wish, you can download 19111 for free from the OGC web site http://portal.opengeospatial.org/files/?artifact_id=6716 . This document was written by a group of geodists and mathematicians so it can be a bit heavy going at times - but it is an excellent piece of work.

Sorry for the length posting, put as we know there is nothing simple about working with an ellipsoidal earth on flat paper - or in computers :-)

Regards

Carl

---

From: "Tatham Oddie" <[email-masked]>
Date: Wed, 28 Nov 2007 08:46:35 +1100

Um ... For those of us following along at home, can somebody throw in what
OBO stands for? It's not the most unique phrase the Google either.

Thanks,

Tatham Oddie
call:+61414275989, call:+61280113982, skype:tathamoddie,
msn:[email-masked], tatham.oddie.com.au

-----Original Message-----
From: Dawson, Martin [mailto:[email-masked]] 
Sent: Wednesday, 28 November 2007 8:37 AM
To: Marc Linsner; [email-masked]
Subject: RE: OBO (was - RE: [Geopriv] Message Flow, again)

Hi Marc,

Cheers,
Martin

-----Original Message-----
From: Marc Linsner [mailto:[email-masked]] 
Sent: Wednesday, 28 November 2007 1:05 AM
To: Dawson, Martin; [email-masked]
Subject: OBO (was - RE: [Geopriv] Message Flow, again)

Martin,

-Marc-

---

From: "Dawson, Martin" <[email-masked]>
Date: Tue, 27 Nov 2007 15:50:00 -0600

Hi Marc,

I don't agree that they are the same thing.

LIS-LIS is part of a chain of interactions associated with the location
request being serviced by the location server.

SIP proxy location is a specific use-case for location and includes the
client of the location request (the proxy). You appear to be equating
the proxy to some sort of location server as well - meaning we have a
clientless interaction presumably. Quite simply - if the location
request is being made without dependency on, or involvement from, the
target, then we have an OBO.

BTW - I tend to agree with Hannes that LIS-LIS is an OBO with the
requesting LIS acting as a client to the serving LIS and with the
subject of the request being a third party target. Nevertheless, I know
that there are other perspectives on this.

Cheers,
Martin

-----Original Message-----
From: Marc Linsner [mailto:[email-masked]] 
Sent: Wednesday, 28 November 2007 1:56 AM
To: 'Brian Rosen'
Cc: [email-masked]
Subject: [Geopriv] RE: OBO

Brian, 

Can we agree that SIP proxy location discovery and LIS to LIS are the
same?

-Marc-

---

From: "Dawson, Martin" <[email-masked]>
Date: Tue, 27 Nov 2007 15:58:56 -0600

Hi Brian,

I think the view of whether they are the same or not depends to a large
extent on whether you are looking at the end to end scenario or whether
you just focus on the individual client-server associations within the
chain.

e.g. Target request location from ISP LIS which gets location from DSL
provider LIS and the result is fed back to the client.

From an end-to-end perspective, this is clearly not an OBO - the target
originated the request itself.

However, if you focus on the specific ISP-LIS to DSLprovider-LIS
relationship, the former is asking for the location of a target other
than itself and is providing some client-identity to specify the actual
target. Looking at that relationship in isolation, it is an OBO.

I think the latter is how Hannes and I see it (though I don't wish to
put words in Hannes' mouth/email).

I think you can broaden your definition of OBO. It doesn't have to be a
use case involving "insertion". Any trusted application that asks for
the location of a target other than itself is doing an OBO; it doesn't
have to be for the purpose of inserting the location into some other
protocol stream.

Cheers,
Martin

-----Original Message-----
From: Brian Rosen [mailto:[email-masked]] 
Sent: Wednesday, 28 November 2007 2:40 AM
To: 'Hannes Tschofenig'
Cc: [email-masked]; 'Marc Linsner'
Subject: RE: OBO (was - RE: [Geopriv] Message Flow, again)

Suppose I am an ISP and I lease services from an underlying access
network.
I want to supply a LIS for my customers.  I contract with my underlying
access network to give me location for my customers. 

I run a real LIS.  My access network provider runs a real LIS.  I need
to
get location for my customers.  That's LIS-LIS.  I am giving LIS to
endpoints.  That's why I want to differentiate.

In my notion of OBO, an intermediary is inserting location on behalf of
an
endpoint.  To me, that's an entirely different thing.  I claim the
intermediary is not a LIS; it's getting location from a LIS and putting
it
into a "call".  The proxy is a client to a LIS.  There is no client to
the
intermediary.

It's okay with me if the protocols for this are the same, but I think
the
use case is different, and the roles are different.

Brian

> > LIS-LIS is a separate problem.  I agree we have yet to undertake
such
> work
> > in Geopriv.  I may be willing to look at it, depending on where we
are
> with
the

---

From: "Brian Rosen" <[email-masked]>
Date: Tue, 27 Nov 2007 17:04:21 -0500

"On Behalf Of"

> From: Tatham Oddie [mailto:[email-masked]]
> Sent: Tuesday, November 27, 2007 4:47 PM
> To: [email-masked]
> Importance: Low

---

From: "Dawson, Martin" <[email-masked]>
Date: Tue, 27 Nov 2007 16:11:21 -0600

:) Sorry Tatham...

Yes - it's On-behalf-of

That is, the target isn't making the request itself; the client is
making the request "on behalf of" the target.

You can see that it was pretty inevitable this would be reduced to OBO
if it got it to the universal maximum two syllable target... :)

Cheers,
Martin

-----Original Message-----
From: Brian Rosen [mailto:[email-masked]] 
Sent: Wednesday, 28 November 2007 9:04 AM
To: 'Tatham Oddie'; [email-masked]
Subject: RE: OBO (was - RE: [Geopriv] Message Flow, again)

"On Behalf Of"

---

From: "Marc Linsner" <[email-masked]>
Date: Tue, 27 Nov 2007 17:23:49 -0500

Martin, 

> How do you suggest formalizing the decision that OBO is a 
> valid use case?

In the IETF, discussion usually starts on the mail lists.  It's up to the
chair to deem when/if the work will be picked up by the wg.  It appears
people have simply asked to discuss the solution document that James has
contributed, ignoring the use case/requirement draft(s) he has written.

> 
> Once again, Marc, you are not talking about LbyR. Location by 
> reference involves asking the location server for a reference 
> and then having the actual location provided as the result of 
> a subsequent dereference. The scenario you are describing is 
> just an LbyV request (in fact, an OBO

Yeah, I still call it ANI too.

-Marc-

---

From: "Roger Marshall" <[email-masked]>
Date: Tue, 27 Nov 2007 14:32:56 -0800

Carl:
Thanks for your reply.  It seems that we're left with the following 3 options then:
 
i. adopt the direct position term in lieu of all other terms which relate to a coordinate pair, etc.
ii. continue to use whatever term we like - outside of OGC/ISO GIS stds.,
iii. wait until the OGC comes up with some new std. terms - then evaluate.
 
I think we'll end up doing the second, and likely, the third - though too late to do anything about published RFCs.
 
Sincerely,
 
-roger marshall.

	From: Carl Reed OGC Account [mailto:[email-masked]] 
	Sent: Tuesday, November 27, 2007 1:42 PM
	To: Roger Marshall; Hannes Tschofenig; James M. Polk
	Cc: [email-masked]; Marc Linsner
	Subject: Re: [Geopriv] Religious Terminology Discussions

	Roger -

	
	4.19
	coordinate

	4.61
	point

	4.26
	direct position

	
	 
	4.26 
	geodetic latitude 
	ellipsoidal latitude 
	ϕ 

	 
	 
	Regards

	Carl

---

From: "Winterbottom, James" <[email-masked]>
Date: Tue, 27 Nov 2007 16:33:20 -0600

Marc,

Firstly identity extension is not only for OBO, as I have pointed out,
let me see, at least 5 times.

Secondly the functionality necessary is clearly documented in:

1)
   
2) http://tools.ietf.org/html/draft-ietf-ecrit-phonebcp-03

And I suspect other documents too. I have seen NO posts to either the
ECRIT or the GEOPRIV list asking for this functionality and discussion
to be removed. Indeed, quite the converse on the geopriv list.

I am hearing 8 to 10 voices in favour of this proposal, and only one
against. Why is this argument still going on?

Cheers
James

> Sent: Wednesday, 28 November 2007 9:24 AM

---

From: "Marc Linsner" <[email-masked]>
Date: Wed, 28 Nov 2007 09:45:25 -0500

James,

Apparently I've been working under a false assumption.  Is not
draft-ietf-geopriv-http-location-delivery-03.txt the comprehensive protocol
specification that fulfills the wg project to specify a L7-LCP?

-Marc-

> Sent: Tuesday, November 27, 2007 5:33 PM
> To: Marc Linsner; Dawson, Martin; [email-masked]
> Firstly identity extension is not only for OBO, as I have 
> pointed out, let me see, at least 5 times.
> 
> And I suspect other documents too. I have seen NO posts to 
> either the ECRIT or the GEOPRIV list asking for this 
> functionality and discussion to be removed. Indeed, quite the 
> converse on the geopriv list.
> 
> I am hearing 8 to 10 voices in favour of this proposal, and 
> only one against. Why is this argument still going on?
> 
> Cheers
> James
> 
> 
>    
> 
> 
> 
> valid use 
> > In the IETF, discussion usually starts on the mail lists.  
> It's up to
> the
> > > reference involves asking the location server for a reference and 
> > > then having the actual location provided as the result of a 
> > > subsequent dereference. The scenario you are describing 
> is just an 
> > > LbyV request (in fact, an OBO

---

From: Robert Sparks <[email-masked]>
Date: Wed, 28 Nov 2007 09:01:02 -0600

-http-location-delivery is a baseline document. It is designed to  
allow extension through standards action.
Identity is a candidate for extension that the group will need to  
discuss. There are several others waiting
for us to finish the work on the core document.

Please spend the bulk of your energy getting that core document  
finished.

RjS

---

From: "Marc Linsner" <[email-masked]>
Date: Wed, 28 Nov 2007 10:25:37 -0500

Robert,

> 
> Please spend the bulk of your energy getting that core 
> document finished.
> 

No problem.

Thanks,

-Marc-

---

From: Hannes Tschofenig <[email-masked]>
Date: Wed, 28 Nov 2007 16:33:13 +0100

Hi Robert,

> Please spend the bulk of your energy getting that core document finished.
>
> RjS
based on my review I think that the http-location-delivery draft just 
needs a minor update.
Then, a WGLC should be started (ideally immediately after the IETF#70 
meeting; assuming Mary is able to quickly produce a new draft version).

Ciao
Hannes

---

From: "Winterbottom, James" <[email-masked]>
Date: Wed, 28 Nov 2007 14:28:27 -0600

I would like some changes to the way in which errors are defined, I
would like a token and an IANA registry for the error values as that
will make extensibility much easier. Otherwise I agree with Hannes.

Cheers
James

> Sent: Thursday, 29 November 2007 2:33 AM
> To: Robert Sparks
> Subject: [Geopriv] http-location-delivery
> 
> Hi Robert,
>