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

From: Robert Sparks <[email-masked]>
Date: Thu, 25 Sep 2008 16:21:39 -0500

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

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

---

From: Robert Sparks <[email-masked]>
Date: Thu, 25 Sep 2008 16:25:15 -0500

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

---

From: Robert Sparks <[email-masked]>
Date: Thu, 25 Sep 2008 16:28:04 -0500

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: Julian Reschke <[email-masked]>
Date: Fri, 26 Sep 2008 14:19:37 +0200

Hi,

here are some comments about the usage of HTTP (I have to point out that 
I made these before :-).

1) I think it's unwise to marshall error messages with a status of 200.

2) It's not totally clear why the protocol relies on POST (an unsafe 
method), when it's really just a query mechanism. Was GET with 
parameters really considered?

3) The examples still include the URI scheme (and authority) in the 
request line.

4) There's still an example with an invalid HTTP status line ("1.x")

5) The use of Accept headers (both Accept and Accept-Charset) seems to 
be both confusing and useless.

BR, Julian

---

From: "Tschofenig, Hannes (NSN - FI/Espoo)" <[email-masked]>
Date: Fri, 26 Sep 2008 15:58:30 +0300

>Hi,
>
>here are some comments about the usage of HTTP (I have to 
>point out that I made these before :-).
>

A perfectly fine mechanism when the error is not at the HTTP layer but
at the application running on top of HTTP. 

>
>2) It's not totally clear why the protocol relies on POST (an 
>unsafe method), when it's really just a query mechanism. Was 
>GET with parameters really considered?

Why do you think POST is unsafe in this application? 

Ciao
Hannes

---

From: Julian Reschke <[email-masked]>
Date: Fri, 26 Sep 2008 15:06:05 +0200

> at the application running on top of HTTP. 

Well yes, if you use HTTP just for tunneling.

However, tunneling has drawbacks; for instance you loose the inherent 
HTTP semantics for error responses (consider cacheability, or all the 
interesting additional information 4xx/5xx messages can carry, such as 
authentication triggers, detection of broken payload, or temporary 
server unavailability).

> Why do you think POST is unsafe in this application? 

It isn't in *this* application, but it is in general in HTTP.

This spec uses HTTP as transport, and thus I think it would be good to 
use it in the best possible way. For instance, when you use existing 
HTTP libraries (and I assumed that's what you want), by using POST you 
loose the ability to automatically follow redirects.

BR, Julian

---

From: "Thomson, Martin" <[email-masked]>
Date: Sun, 28 Sep 2008 18:56:48 -0500

With regards to the use of POST, the action performed does not meet the "safe" criteria.  As a result of the request, the server may be required to perform certain actions.  The most significant being the taking of measurements and the creation of temporary resources (the location URI).

(It is safer to assume that the request is not idempotent either, particularly where location URIs are involved.)

Cheers,
Martin

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On
> Behalf Of Julian Reschke
> Sent: Friday, 26 September 2008 11:06 PM
> To: Tschofenig, Hannes (NSN - FI/Espoo)
> Cc: GEOPRIV
> Subject: Re: [Geopriv] WGLC: draft-ietf-geopriv-http-location-delivery-
> 09.txt
> 

------------------------------------------------------------------------------------------------
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: Henning Schulzrinne <[email-masked]>
Date: Sun, 28 Sep 2008 20:43:46 -0400

On Sep 28, 2008, at 7:56 PM, Thomson, Martin wrote:

> With regards to the use of POST, the action performed does not meet  
> the "safe" criteria.  As a result of the request, the server may be  
> required to perform certain actions.  The most significant being the  
> taking of measurements and the creation of temporary resources (the  
> location URI).
>

That doesn't seem any different than what a web server does for a POST  
in almost all web server deployments I'm familiar with. They routinely  
involve database storage, cookie generation and various back-end  
operations, such as consulting databases or issuing internal remote  
procedure calls.

> (It is safer to assume that the request is not idempotent either,  
> particularly where location URIs are involved.)
>

---

From: "Thomson, Martin" <[email-masked]>
Date: Sun, 28 Sep 2008 19:52:44 -0500

> From: Henning Schulzrinne [mailto:[email-masked]]
> Sent: Monday, 29 September 2008 10:44 AM
> To: Thomson, Martin
> Cc: Julian Reschke; Tschofenig, Hannes (NSN - FI/Espoo); GEOPRIV

Indeed, but not consistent with the "safe" behaviour expected for a GET.

---

From: Julian Reschke <[email-masked]>
Date: Mon, 29 Sep 2008 09:14:50 +0200

> With regards to the use of POST, the action performed does not meet the "safe" criteria.  As a result of the request, the server may be required to perform certain actions.  The most significant be…

That is a safe request from the HTTP point of view.

> (It is safer to assume that the request is not idempotent either, particularly where location URIs are involved.)

Could you elaborate on this? The only URI that I see (at least in the 
simple case) is the request URI.

BR, Julian

---

From: "Thomson, Martin" <[email-masked]>
Date: Mon, 29 Sep 2008 17:56:44 -0500

Hi Julian,

A HELD request can result in the creation of a URI (and the associated resource).  This URI can be used by the requester to pass to others who are able to retrieve location information using the URI.  Hence: location URI.

I based my conclusion on the definition of a "safe" method from RFC 2616, which admittedly isn't entirely clear:

   In particular, the convention has been established that the GET and
   HEAD methods SHOULD NOT have the significance of taking an action
   other than retrieval.

The creation of a location URI is, by any definition, a side-effect.  It's also possible that it can't be known a priori by the requester.  Given the nature of a HELD request, a location URI may be explicitly requested, but it may be as a result of a decision at the server that the client cannot be aware of.  The default request of locationType=any could result in the creation of a location URI if server policy dictated this.

When choosing POST, the idempotence characteristic was more significant in coming to the conclusion.  While it is possible that an implementations could create location URIs and provide the same URI in response to subsequent responses, this is not required.

Cheers,
Martin

> From: Julian Reschke [mailto:[email-masked]]
> Sent: Monday, 29 September 2008 5:15 PM
> To: Thomson, Martin
> Cc: Tschofenig, Hannes (NSN - FI/Espoo); GEOPRIV

---

From: Julian Reschke <[email-masked]>
Date: Tue, 30 Sep 2008 01:24:37 +0200

>    HEAD methods SHOULD NOT have the significance of taking an action

...and which goes on saying:

"Naturally, it is not possible to ensure that the server does not 
generate side-effects as a result of performing a GET request; in fact, 
some dynamic resources consider that a feature. The important 
distinction here is that the user did not request the side-effects, so 
therefore cannot be held accountable for them."

> The creation of a location URI is, by any definition, a side-effect.  It's also possible that it can't be known a priori by the requester.  Given the nature of a HELD request, a location URI may be…

In which case the user didn't ask for that side-effect, right?

> ...

BR, Julian

---

From: "Thomson, Martin" <[email-masked]>
Date: Mon, 29 Sep 2008 18:41:48 -0500

The user did ask for that side-effect, or at least had to be prepared for that side-effect.

In any case, Lisa's point that idempotence is more important than "safe"-ness (if I've interpreted her correctly), is more to the point.

Cheers,
Martin

> Sent: Tuesday, 30 September 2008 9:25 AM
> To: Thomson, Martin
> The default request of locationType=any
> could result in the creation of a location URI if server policy
> dictated this.
>

---

From: Julian Reschke <[email-masked]>
Date: Wed, 01 Oct 2008 09:10:53 +0200

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