ietf
[Top] [All Lists]

RE: Past LC comments on draft-ietf-geopriv-http-location-delivery-08

2008-08-03 23:52:23
Hi Julian, 

thanks for the extremely quick response: 

Tschofenig, Hannes (NSN - FI/Espoo) wrote:
...
1) URI schemes

From the draft, it's totally unclear what the URI schemes 
are needed 
for. For instance, the registrations do not mention what the URIs 
actually identity, and how to resolve them.

Well. Initially, we wanted to use HTTP URI scheme but we were told 
that we shouldn't do that. Based on the advice we got we 
created a new 
URI scheme.
...

I think that's bad advice.

Either this decision should be reversed, or the specification 
needs to be updated so that it actually *defines* the URI scheme.


Like with many other areas, you ask 5 persons and get 7 opinions. 
How should a working group soliciting advice make an informed decisions?



...
2) HTTP examples

As far as I can tell, the examples in Section 11.1 are not really 
HTTP, or I'm missing explanations that would be needed to 
understand 
this.

For instance, they use heldref URIs in the Request-Line of the 
request.
Also, there's an example where a response uses the HTTP version 
number "HTTP/1.x".


How would the examples have to look like so that they are correct?

As far as I can tell,

         GET heldrefs://lis.example.com:49152/location HTTP/1.1
         Accept:application/held+xml,
             application/xml;q=0.8,
             text/xml;q=0.7
         Accept-Charset: UTF-8,*

needs to be:

         GET /location HTTP/1.1
         Host: lis.example.com:49152
         Accept:application/held+xml,
             application/xml;q=0.8,
             text/xml;q=0.7
         Accept-Charset: UTF-8,*

...which of course makes it obvious that the new URI scheme is 
totally pointless.

We just recently updated our examples from the lower one to the upper
one. Martin Thomson might provide you more background on this issue
since he also told me to update other drafts ... 

Martin, can you provide a bit of background here? 


3) Usage of HTTP

The protocol tunnels over HTTP instead of using HTTP, probably 
because it tries to be transport-agnostic. This makes only sense if 
there are other transports. Are there?

The idea was to make it protocol agnostic and at least one other 
transport has been published. Currently, the group tries to finish 
some other work before these issues may be brought up again.

Even if the answer to that is "yes", HTTP semantics should 
be obeyed; 
if the response to a request is an error message, it shouldn't be 
returned with status code 200. There's no problem using a 4xx class 
status code and returning a custom body (as we do in WebDAV).

We copied this from other documents that went through the 
IETF process. 
We got told that returning a 200 OK is fine when the problem that 
caused the error message happens to be at a different layer. So far, 
that seemed to me like a pretty good answer and seems to be inline 
with the semantic of protocol layering.
...

Is that discussion archived somewhere? Where did it happen?

I have to search through the ECRIT and GEOPRIV mailing list -- 2 lists
with a lot of mail.

Ciao
Hannes



BR, Julian

_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf

<Prev in Thread] Current Thread [Next in Thread>