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(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf