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

[Julian Reschke <julian.reschke at gmx.de>]

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.

> ...
> > 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.

> > 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?

BR, Julian
_______________________________________________
Ietf mailing list
Ietf at ietf.org
https://www.ietf.org/mailman/listinfo/ietf