Subject: Re: [Geopriv] WGLC: draft-ietf-geopriv-http-location-delivery-09.txt

From: "Thomson, Martin" <[email-masked]>
Date: Wed, 1 Oct 2008 17:07:26 -0500

Hi Julian,

This shouldn't be a problem.  All atomic XML schema data types that have a whiteSpace facet (and anyURI and dateTime do) have a value for this facet of collapse.  This means that any conforming processor removes leading and trailing white space.

The whitespace was introduced to conform to the line length restrictions of the RFC format without having a negative impact on the readability of the draft.

Cheers,
Martin

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On
> Behalf Of Julian Reschke
> Sent: Wednesday, 1 October 2008 5:11 PM
> To: GEOPRIV
> Subject: Re: [Geopriv] WGLC: draft-ietf-geopriv-http-location-delivery-
> 09.txt
> 
> Hi,
> 
> here's another nit.
> 
> In the examples, I see several cases where whitespace is used where it
> may not be allowed (I may be wrong, maybe the XSD allows it somehow).
> Examples:
> 
> 
> <locationURI>https://ls.example.com:9768/357yc6s64ceyoiuy5ax3o
>            </locationURI>
>            <locationURI>sip:[email-masked]
>            </locationURI>
> 
>               <retention-expiry>2007-05-25T12:35:02+10:00
>               </retention-expiry>
> 
> BR, Julian
> _______________________________________________
> Geopriv mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/geopriv

------------------------------------------------------------------------------------------------
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://www.ietf.org/mailman/listinfo/geopriv

---

From: Julian Reschke <[email-masked]>
Date: Thu, 02 Oct 2008 08:56:57 +0200

> This shouldn't be a problem.  All atomic XML schema data types that have a whiteSpace facet (and anyURI and dateTime do) have a value for this facet of collapse.  This means that any conforming pro…

OK.

You may want to call out that fact explicitly, as I would be surprised 
if all recipients actually use an XML Schema aware parser *and* turn on 
schema validation. If they don't, and receive unexpected whitespace, 
interoperability may suffer.

BR, Julian

---

From: Robert Sparks <[email-masked]>
Date: Thu, 2 Oct 2008 10:16:21 -0500

Please send in message noting that you are OK with this change (or  
not, if that's not the case).

RjS

On Sep 25, 2008, at 4:21 PM, Robert Sparks wrote:

> Folks:
>
> As most of you know, the resolution of the IETF LC comments on draft- 
> ietf-geopriv-http-location-delivery resulted in the change of a  
> design decision this group previously agreed to. Many of you  
> participated in the discussions leading to that resolution, but we  
> need to make sure the group as a whole agrees with this change (and  
> capture this discussion in the record).
>
> Specifically, the protocol in the current version of the document:
> http://tools.ietf.org/html/draft-ietf-geopriv-http-location- 
> delivery-09
> uses the http: URI scheme - the heldref schemes have been removed.
>
> We have spent time before discussing using the http: URI scheme or  
> creating a new one.
> My recollection of those conversations were that either path would  
> be acceptable, each would result in different things we needed to  
> make sure we covered in the document, and that there was a  
> preference at the time for making a new scheme.
>
> So, given the change based on IETF LC feedback, in addition to  
> making sure we're still Ok as a group with using the http: URI  
> scheme, we need to look and see if we've missed anything we really  
> need to talk about when we're using that scheme.
>
> This is a 1-week WGLC.
>
> Please review this version of the document and respond to the list  
> with your comments no later than Friday Oct 3.
>
> If you feel you need more time for this discussion, let me know and  
> I will extend the deadline.
>
> RjS
>

---

From: Richard Barnes <[email-masked]>
Date: Thu, 02 Oct 2008 11:40:51 -0400

It is true that HELD would give incorrect results if used through a 
SOCKS server (it would return the location of the SOCKS server instead 
of that of the client).

I agree that a sentence for SOCKS similar to the one we have now for 
tunnels is necessary, but possibly not sufficient.  If clients are going 
to make exceptions to SOCKS, wouldn't they need some sort of criterion 
by which to decide?  Is this a good reason to re-introduce the HELD(S) 
URI scheme(s)?

--Richard

Robert Sparks wrote:
> Through Cullen, I've heard some concern that we need to explicitly call 
> out that the protocol in this document could lead to surprising results 
> if used through a SOCKS server.
> 
> We already have text discussing what happens when you use the protocol 
> through a tunnel. Would it be sufficient to add a sentence discussing 
> SOCKS there?

---

From: Richard Barnes <[email-masked]>
Date: Thu, 02 Oct 2008 11:56:56 -0400

To augment my previous suggestion that we re-introduce HELD(S) URIs, I 
would additionally suggest that these URIs be defind ONLY for referring 
to HELD resources, as defined by this document -- *not* for use in the 
<locationURI> element.  That is, the HELD URI as specified in this 
document would be for configuration only, not dereference.  A future 
document dealing with dereference could extend the definition of the 
HELD URI or define a new scheme (e.g., "heldref:" as before).

I believe this was the primary issue that arose before with URIs: That 
the document specified how to write one down and put it in a 
<locationURI> element, but not how to dereference it.

--Richard

Richard Barnes wrote:
>> Through Cullen, I've heard some concern that we need to explicitly 
>> call out that the protocol in this document could lead to surprising 
>> results if used through a SOCKS server.
>>

---

From: "Mary Barnes" <[email-masked]>
Date: Thu, 2 Oct 2008 11:10:21 -0500

I'm confused - you say that the HELD URI in this doc is "for
configuration only", but then you say we need to describe "how to
deference it" wrt the <location> URI element. 

We've already been down this road (either way) and this we've previously
done it both ways and we've flip-flopped on this once already in terms
of where to define the URIs.  If we describe how to dereference in base
HELD and define the lbyr URI in base HELD, we then have a normative
reference to the dereference document (or we need to pull a whole lot
into this document). 

Mary. 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Richard Barnes
Sent: Thursday, October 02, 2008 10:57 AM
To: Robert Sparks
Cc: GEOPRIV
Subject: Re: [Geopriv] Working through SOCKS (Was: WGLC:
draft-ietf-geopriv-http-location-delivery-09.txt)

--Richard

> tunnels is necessary, but possibly not sufficient.  If clients are 
> going to make exceptions to SOCKS, wouldn't they need some sort of 
> criterion by which to decide?  Is this a good reason to re-introduce 
> the HELD(S) URI scheme(s)?
> 
> --Richard
> 
> 
> Robert Sparks wrote:
>> We already have text discussing what happens when you use the 
>> protocol through a tunnel. Would it be sufficient to add a sentence 
>> discussing SOCKS there?

---

From: Richard Barnes <[email-masked]>
Date: Thu, 02 Oct 2008 12:52:24 -0400

I meant that last sentence in the opposite way to how you read it: That 
this document should *not* say that a HELD URI can go in a <locationURI> 
element.  Then it doesn't have to say how to dereference.

I think this is a new path relative to the ones we've been down, which 
IIRC were the following (in chronological order):
1. (<=-05) Define "held" for <locationURI> AND for configuration
2. (-06, -07) Define "helds" for <locationURI> AND for configuration
3. (-08) Define "heldref" for <locationURI>, not for configuration
4. (-09) No URIs at all

What I'm proposing is
4. (*) Define "held"/"helds" for configuration, not <locationURI>

Does that make sense?  Practically, all it amounts to is removing the 
last paragraph from Section 8, or perhaps replacing it with a note 
saying that the URI defined here is not suitable for a <locationURI>, 
but may be made so by a future extension.

I'll send text off-list.

--Richard

---

From: Robert Sparks <[email-masked]>
Date: Thu, 2 Oct 2008 12:53:14 -0500

On Oct 2, 2008, at 10:40 AM, Richard Barnes wrote:

> SOCKS server (it would return the location of the SOCKS server  
> instead of that of the client).
>
> criterion by which to decide?

How is this different from the tunnel situations the document already  
discusses?

> Is this a good reason to re-introduce the HELD(S) URI scheme(s)?
>
>
> --Richard
>
>
> Robert Sparks wrote:
>> call out that the protocol in this document could lead to  
>> surprising results if used through a SOCKS server.

---

From: Richard Barnes <[email-masked]>
Date: Thu, 02 Oct 2008 14:16:34 -0400

It seems to me to be the reverse of the other tunneling situation, at 
least sometimes:  With  a VPN or other tunnel, the HELD client is 
choosing whether or not to do HELD based on the presence/absence of the 
tunnel.  Many HTTP clients (browsers in particular), on the other hand, 
choose whether or not to use SOCKS on a per-request basis, so their 
choice is whether or not to do tunneling based on the presence or 
absence of HELD.

So perhaps what the text should do is address two use cases:
1. If HELD client must use SOCKS for all connections (e.g., because of 
local network policy), then it MUST NOT HELD because it will give bad 
results.
2. If a HELD client can choose whether or not to use SOCKS on a 
particular TCP connection, then it MUST NOT use SOCKS for HELD 
connections.

The second situation presupposes that the HELD client can tell when it 
is opening a HELD connection, which can be difficult if the HELD client 
handles other protocols as well (e.g., with a Java URLConnection, or in 
a browser).  In this context, where connections are usually requested by 
URI, it makes sense to use the URI scheme to disambiguate.  Thus, if we 
think that clients will need to distinguish HELD from non-HELD 
connections, e.g. to make decisions about SOCKS, then we should probably 
add the HELD URI scheme back to the document (with the caveats I 
mentioned earlier, namely *not* for <locationURI>).

--Richard

---

From: Marc Linsner <[email-masked]>
Date: Thu, 02 Oct 2008 15:04:54 -0400

Richard,

What about the man-in-the-middle-intercept-port80 boxes?

BTW, I tend to think of proxies more like nats than tunnels.

-Marc-

---

From: Richard Barnes <[email-masked]>
Date: Thu, 02 Oct 2008 15:20:30 -0400

That's my case 1, where the HELD client has no choice.  You're right 
that the MITM scenario is exactly like the scenario when there's a NAT 
in the path -- either way, the client shouldn't do HELD because he's 
likely to get bad stuff (or he should accept that he's going to get the 
proxy/NAT's location).  Hence Robert's original suggestion to add 
similar text to the NAT/VPN/tunnel text, which is still a good idea.

Case 2 is entirely different -- it assumes that the host is able to 
choose whether or not to use a proxy.  In that case, the host needs some 
criterion to decide, and a URI scheme fits the bill.

--Richard

---

From: Marc Linsner <[email-masked]>
Date: Thu, 02 Oct 2008 16:38:40 -0400

Richard,

OK, my comments were to draw the conversation away from 'SOCKS' specifically
and point out the pure HTTP (intercept) proxies.  The thread kept talking
SOCKS only and in my experience SOCKS is always known to the client, whereas
some implementations of HTTP proxies are unknown to the client.

So I believe there are 3 cases:

1) SOCKS proxy is known by the client.
2) HTTP proxy is known by the client.
3) HTTP proxy is unknown by the client.

-Marc-

---

From: Richard Barnes <[email-masked]>
Date: Thu, 02 Oct 2008 17:45:33 -0400

Actually, you can be a little more abstract than that.  In general, if 
the client is aware, possibly by manual configuration, of a middlebox 
(NAT, VPN, proxy, SOCKS, etc.) there are two cases:

1. Middlebox is unavoidable, client must change HELD behavior
2. Middlebox is avoidable, client must decide whether to transit it

The case where the client doesn't know about the middlebox is irrelevant 
for writing a standard, other than to say "here be dragons".

--Richard

---

From: Marc Linsner <[email-masked]>
Date: Thu, 02 Oct 2008 18:37:46 -0400

Richard,

My whole point was to clarify the difference between SOCKS and HTTP proxies.
In the case of a SOCKS proxy, the client ALWAYS has a choice whether to use
it or not, it's configured within the application.  In the case of HTTP
proxies, there are cases where the client has no clue such a mechanism
exists.

-Marc-

---

From: Robert Sparks <[email-masked]>
Date: Wed, 8 Oct 2008 12:34:41 -0500

The comments so far have not been conclusive. They need to be before  
we can move forward again.

I also haven't heard from many of this groups regular contributors on  
this change.

Please keep the pressure on this!

RjS

---

From: "Brian Rosen" <[email-masked]>
Date: Wed, 8 Oct 2008 16:46:37 -0400

I am no HTTP expert.

I am however, a believer in being explicit, and not implicit.  I would
prefer that a URI intended to be used with HELD should have a scheme that
reflects HELD and not its underlying transport.

I further feel that a reference that must be dereferenced is different from
a HELD request to provide location (LCP query), and thus should explicitly
BE different. 

Brian

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of Robert Sparks
Sent: Wednesday, October 08, 2008 1:35 PM
To: Robert Sparks
Cc: GEOPRIV
Subject: Re: [Geopriv] WGLC:
draft-ietf-geopriv-http-location-delivery-09.txt

RjS

---

From: Richard Barnes <[email-masked]>
Date: Tue, 14 Oct 2008 17:34:05 -0400

I've taken a second look at the security considerations (Section 9.1 in
particular), and I think it squares correctly against HTTPS (RFC 2818,
Section 3.1 in particular).  Because HELD can have different bindings,
the text in HELD is more general than 2818.  But as far as I can tell,
what HELD says about the HTTP(S) binding is consistent with 2818.

The only change I would suggest is the following: RFC 2818 is a little
more specific about how the matching is done, so I would change the
following sentence:
"
In the case of the HTTP binding described above, this is exactly the
authentication described by TLS [RFC2818].
"
to this:
"
In the case of the HTTP binding described above, this is exactly the
authentication mechanism for HTTPS [RFC2818], and the client MUST follow
the matching procedure described Section 3.1 of [RFC2818].
"

--Richard

Robert Sparks wrote:
> Again through Cullen, I've heard that we need to make sure we are not 
> doing anything that's not what HTTPS specifies when we're using https: 
> URIs, particularly when we discuss how to use fields in certificates for 
> decisions.
> 
> I think the document has this right already (see section 9.1), but 
> please look at it closely for pitfalls.
> 
> RjS

---

From: Richard Barnes <[email-masked]>
Date: Tue, 14 Oct 2008 21:01:18 -0400

Hi all,

Mary, James, Martin, and I continued this discussion off-list, and came 
to agreement that
(1) Generalizing the VPN/tunnel text to cover other middleboxes, such as 
SOCKS or HTTP proxies will cover most use cases, and
(2) The decision as to whether or not to have a URI scheme for HELD LCP 
resources will be an issue for lis-discovery; HELD can move forward without.

If anyone feels that these steps do not meet the concerns over SOCKS or 
other proxies, please reply now or forever hold your peace.

--Richard

---

From: Robert Sparks <[email-masked]>
Date: Mon, 20 Oct 2008 15:32:05 -0500

The question that I'm looking to document WG consensus on is what  
scheme goes in the RURI of requests for the protocol defined in _this  
document_. The examples show http: / https:. The question is whether  
the working group
believes this should be what the protocol uses for the purposes  
defined ->in this document<- or if we should return
to an consensus to have a separate scheme.

Btw, on fast scan, I can't find where the current document normatively  
says anything about using the http: scheme. Am I missing it?

We have strong feedback that this document _does_ need to say what  
that scheme is - that the document is incomplete without it. So what,  
specifically, are we agreeing to say?

(I think I've seen agreement that what appears in a <locationURI>  
stanza might be different and that we don't have to declare that in  
this document, but that's not the question being asked).

If I've misunderstood what you were saying, please try it again a  
different way.

RjS

On Oct 14, 2008, at 8:01 PM, Richard Barnes wrote:

> Hi all,
>
> Mary, James, Martin, and I continued this discussion off-list, and  
> came to agreement that
> (1) Generalizing the VPN/tunnel text to cover other middleboxes,  
> such as SOCKS or HTTP proxies will cover most use cases, and
> (2) The decision as to whether or not to have a URI scheme for HELD  
> LCP resources will be an issue for lis-discovery; HELD can move  
> forward without.
>
> If anyone feels that these steps do not meet the concerns over SOCKS  
> or other proxies, please reply now or forever hold your peace.
>
> --Richard
>
>
>
> Richard Barnes wrote:
>> I meant that last sentence in the opposite way to how you read it:  
>> That this document should *not* say that a HELD URI can go in a  
>> <locationURI> element.  Then it doesn't have to say how to  
>> dereference.
>> I think this is a new path relative to the ones we've been down,  
>> which IIRC were the following (in chronological order):
>> Does that make sense?  Practically, all it amounts to is removing  
>> the last paragraph from Section 8, or perhaps replacing it with a  
>> note saying that the URI defined here is not suitable for a  
>> <locationURI>, but may be made so by a future extension.
>> I'll send text off-list.
>> --Richard
>> Mary Barnes wrote:
>>>> It is true that HELD would give incorrect results if used through  
>>>> a SOCKS server (it would return the location of the SOCKS server  
>>>> instead
>>>
>>>> of that of the client).
>>>>
>>>> I agree that a sentence for SOCKS similar to the one we have now  
>>>> for tunnels is necessary, but possibly not sufficient.  If  
>>>> clients are going to make exceptions to SOCKS, wouldn't they need  
>>>> some sort of criterion by which to decide?  Is this a good reason  
>>>> to re-introduce the HELD(S) URI scheme(s)?
>>>>
>>>> --Richard
>>>>
>>>>
>>>> Robert Sparks wrote:
>>>>> Through Cullen, I've heard some concern that we need to  
>>>>> explicitly call out that the protocol in this document could  
>>>>> lead to surprising results if used through a SOCKS server.
>>>>>
>>>>> protocol through a tunnel. Would it be sufficient to add a  
>>>>> sentence discussing SOCKS there?

---

From: "Mary Barnes" <[email-masked]>
Date: Mon, 20 Oct 2008 18:43:13 -0500

Section 8 of the -09 does discuss the HTTP binding.  So, I'm not sure
what your remaining concern is. 

This proposal (of not defining a URI scheme for LIS discovery in this
document) is consistent with what I thought was consensus for the
changes that went into -09 per this thread:
http://www.ietf.org/mail-archive/web/geopriv/current/msg06234.html

LIS Discovery is a normative dependency for this document, so I don't
see a problem with the lack of specificity of the URI for the LIS in
this document, which is why I thought that was okay. 

And, here's a summary of what URI definitions have been in and out of
the document since the -04:
-04 (WGLC version) single URI - http .  Registered an HTTP URN for held.

-05 (WGLC comments):  single URI  - held: .  Intent was for helds: only
(at this point)
-06 (2nd WGLC comments).  Single URI  - helds:
-07 (PROTO Review comments):  No change to URIs!!  Just nit fixes and
removing text in Device/VPN section per Issue 1 discussed at IETF-71. 
-08 (Sec-dir/Gen-ART IETF-LC comments - confusion over whether URI was
for deref or LIS. Agreed change after much discussion:  Two URIs for
deref (non-secure/secure). The idea was LIS discovery would define the
LIS URI that is returned - heldref/heldrefs  
-09 (Post-IETF 73/Post IETF-LC version). No URIs defined in this doc. 

The latter being what we're proposing stays the same. If we need a URI
for LIS discovery, we define it in that document (note: this was the
proposal in the thread "Round 2: Editor's Proposal.." on June 25th):
http://www.ietf.org/mail-archive/web/geopriv/current/msg05837.html

So, other than some nits identified and the text around not using SOCKS,
I think that's all the changes being proposed for the -10. 

That all said, we did originally have a registration of a URN defined
for HTTP for HELD in the -04 (and previous versions - it was in there
from day 1) - is that what you're asking about? 

Regards,
Mary.

-----Original Message-----
From: Robert Sparks [mailto:[email-masked]] 
Sent: Monday, October 20, 2008 3:32 PM
To: Richard Barnes
Cc: Barnes, Mary (RICH2:AR00); GEOPRIV
Subject: Re: [Geopriv] Working through SOCKS (Was: WGLC:

The question that I'm looking to document WG consensus on is what scheme
goes in the RURI of requests for the protocol defined in _this
document_. The examples show http: / https:. The question is whether the
working group believes this should be what the protocol uses for the
purposes defined ->in this document<- or if we should return to an
consensus to have a separate scheme.

We have strong feedback that this document _does_ need to say what that
scheme is - that the document is incomplete without it. So what,
specifically, are we agreeing to say?

(I think I've seen agreement that what appears in a <locationURI> stanza
might be different and that we don't have to declare that in this
document, but that's not the question being asked).

RjS

On Oct 14, 2008, at 8:01 PM, Richard Barnes wrote:

> (1) Generalizing the VPN/tunnel text to cover other middleboxes, such 
> as SOCKS or HTTP proxies will cover most use cases, and
>> 1. (<=-05) Define "held" for <locationURI> AND for configuration 2. 
>> (-06, -07) Define "helds" for <locationURI> AND for configuration 3. 
>> (-08) Define "heldref" for <locationURI>, not for configuration 4. 
>> (-09) No URIs at all What I'm proposing is 4. (*) Define 
>> "held"/"helds" for configuration, not <locationURI> Does that make 
>> sense?  Practically, all it amounts to is removing the last paragraph

>> from Section 8, or perhaps replacing it with a note saying that the 
>> URI defined here is not suitable for a <locationURI>, but may be made

>> so by a future extension.
>> I'll send text off-list.
>> --Richard
>> Mary Barnes wrote:
>>> We've already been down this road (either way) and this we've 
>>> previously done it both ways and we've flip-flopped on this once 
>>> already in terms of where to define the URIs.  If we describe how to

>>> dereference in base HELD and define the lbyr URI in base HELD, we 
>>> then have a normative reference to the dereference document (or we 
>>> need to pull a whole lot into this document).
>>> Mary.
>>> To augment my previous suggestion that we re-introduce HELD(S) URIs,

>>> I would additionally suggest that these URIs be defind ONLY for 
>>> referring to HELD resources, as defined by this document -- *not* 
>>> for use in the <locationURI> element.  That is, the HELD URI as 
>>> specified in this document would be for configuration only, not 
>>> dereference.  A future document dealing with dereference could 
>>> extend the definition of the HELD URI or define a new scheme (e.g., 
>>> "heldref:" as before).
>>>

>>>> for tunnels is necessary, but possibly not sufficient.  If clients 
>>>> are going to make exceptions to SOCKS, wouldn't they need some sort

>>>> of criterion by which to decide?  Is this a good reason to 
>>>> re-introduce the HELD(S) URI scheme(s)?
>>>>
>>>> --Richard
>>>>
>>>>
>>>> Robert Sparks wrote:

---

From: Richard Barnes <[email-masked]>
Date: Tue, 21 Oct 2008 09:41:36 +0200

Robert,

I think you're correct that the scheme of the RURI is not specified  
(NB: This is also a different problem from SOCKS).  I wasn't aware of  
this guidance that the RURI should be specified.  Could you provide a  
pointer?

--Richard

On Oct 20, 2008, at 10:32 PM, Robert Sparks wrote:

> scheme goes in the RURI of requests for the protocol defined in  
> _this document_. The examples show http: / https:. The question is  
> whether the working group
> Btw, on fast scan, I can't find where the current document  
> normatively says anything about using the http: scheme. Am I missing  
> it?
>
> that scheme is - that the document is incomplete without it. So  
> what, specifically, are we agreeing to say?
>
>> If anyone feels that these steps do not meet the concerns over  
>> SOCKS or other proxies, please reply now or forever hold your peace.
>>
>> --Richard
>>
>>
>>
>> Richard Barnes wrote:
>>>> previously
>>>>> It is true that HELD would give incorrect results if used  
>>>>> through a SOCKS server (it would return the location of the  
>>>>> SOCKS server instead
>>>>
>>>>> of that of the client).
>>>>>
>>>>> clients are going to make exceptions to SOCKS, wouldn't they  
>>>>> need some sort of criterion by which to decide?  Is this a good  
>>>>> reason to re-introduce the HELD(S) URI scheme(s)?
>>>>>
>>>>> --Richard
>>>>>
>>>>>
>>>>> Robert Sparks wrote:

---

From: "Mary Barnes" <[email-masked]>
Date: Thu, 23 Oct 2008 14:46:25 -0500

Okay, we've had very little response to the proposed way forward
discussion:
http://www.ietf.org/mail-archive/web/geopriv/current/msg06315.html

I will summarize the planned changes to get any final feedback, noting
that there are no changes to the decision to NOT define any HELD
specific URIs in this document:

1) Per my last note in my response to Robert's comments in the above
thread, we will add back the registration of a URN for HTTP  - bringing
back section 11.1.2 from the -04 (that was really an error on my part
when we remove the new URI schemas from this document):
http://tools.ietf.org/id/draft-ietf-geopriv-http-location-delivery-04.tx
t

2) Generalizing the VPN/tunnel text in section 4.1.1 to cover other
"middleboxes", such 
as SOCKS servers or HTTP proxy servers to address the SOCKS issue that
was raised.
Thus, I will change the section title to read: "Device and NATs, VPNs
and other intermediaries" and change the text to something like the
following for the first (and subsequent) paragraphs:
OLD:
   To minimize the impact of VPNs, Devices should perform their HELD
   query prior to establishing a VPN tunnel. It is RECOMMENDED that
   discovery [I-D.ietf-geopriv-lis-discovery] and an initial query are
   performed before establishing the VPN.  If a Device performs the HELD
   query after establishing the VPN tunnel the Device may receive
   inaccurate location information.

NEW:
   To minimize the impact of connections or tunnels setup for security
purposes or to traverse middleboxes, 
   Devices that connect to servers such as VPN servers, SOCKS servers
and HTTP proxy servers
   should perform their HELD query to the LIS prior to establishing a
connection to other servers.
   It is RECOMMENDED that discovery [I-D.ietf-geopriv-lis-discovery] and
an initial query are
   performed before establishing any connections or tunnels to other
servers.  
   If a Device performs the HELD query after establishing the
connections or tunnels to 
   other servers, the Device may receive inaccurate location
information.

3) Miscellaneous editorial nit fixes. 

4) Fixes to examples per this thread: 
http://www.ietf.org/mail-archive/web/geopriv/current/msg06239.html

And per items 3) and 4) of this thread with Julian
http://www.ietf.org/mail-archive/web/geopriv/current/msg06265.html 

Note: that later discussion on other items did not result in any changes
AFAIK. 

5) Add a note wrt to whitespaces in examples per Julian's suggestion in
this thread:
http://www.ietf.org/mail-archive/web/geopriv/current/msg06282.html

I will be making the changes no later than early next week (likely after
-00 deadline). 

So, please provide any final comments before early next week.

Regards,
Mary.