Hi Julian, Thanks for your review. >Hi, > >I've read this document a few weeks ago, and I'm very >concerned that it apparently wasn't reviewed by the HTTP and >URI community. The document has received review from folks in the Application Area. In fact, the technical advisor for the group is Lisa. A lot of the suggestions came from the Applications Area. > >I'm going to comment only on a few topics. I believe there are >more things that need fixing, but let's focus on the important >things first. > >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. They are resolved liked normallly HTTP URIs. They point to location information. > >I also noticed that IANA missed the fact that there are new >URI schemes to be registered >(<https://datatracker.ietf.org/idtracker/draft-ietf-geopriv-htt >p-location-delivery/comment/80799/>). Thanks for the pointer. > >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? > >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. Ciao Hannes > > >Best regards, > >Julian > > >_______________________________________________ >Ietf mailing list >Ietf@xxxxxxxx >https://www.ietf.org/mailman/listinfo/ietf > _______________________________________________ Ietf@xxxxxxxx https://www.ietf.org/mailman/listinfo/ietf