Thomson, Martin wrote:
Hi Hannes, Julian,
...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 ...
Interesting, looking forward to understand the reasons.
Martin, can you provide a bit of background here?
...
I'm impartial on the topic of URI schemes. The URI scheme was added on request after IESG review. There were concerns about the loss of contextual information relating to the URI when used in contexts outside the context of the Device-LIS exchange.
Well. There's definitively a total disconnect between that IESG
recommendation, and the W3C TAG's point of view (see ongoing discussion
on the TAG mailing list about the "xri" scheme).
It would be good when both organizations could come up with consistent
answers.
If a new URI scheme is defined, it needs to state what it identifies,
and how it is resolved. If it identifies an HTTP resource, and
resolution is done via HTTP, then it seems to me you don't need it.
This URI scheme seems to fall into the same category as Apple's iCal and
iTunes related schemes, which aren't registered URI schemes for a reason.
Assuming that the URI is necessary... The reason to go with the full URI on the request line is to ensure that the server is able to distinguish between a held[s]: URI and a matching http[s]: URI. Without this, the server potentially does not know the difference.
If the server is supposed to be able to differentiate (why?), then the
URI identifies something else.
I'm not sure what problem you want to solve here. Could you elaborate?
Isn't the custom MIME type + conneg totally sufficient?
Besides, how are you going to deploy this? What libraries allow you to
put the full URI into the request line? How do you plan to deploy
software that knows about the URI scheme?
Without the absolute URI, there is the possibility that held: and http: URIs could be considered equivalent. In fact, there would be no meaningful difference when it comes to the protocol exchange, as you rightly pointed out. (I'll note that this isn't the only difference that is important, and certainly wasn't a factor in the discussions that lead to the introduction of the new scheme.)
Yes.
Using an absolute URI is not common practice in HTTP for anything other than requests to proxies. However, RFC 2616 requires that servers understand and support absolute URIs (Sec. 5.1.2). In my experience, this is a safe thing to assume; HTTP servers generally treat the URI sensibly.
That's true. So:
1) If the URI scheme is not equivalent to http(s), what's the
difference? What is the resource being identified?
2) How do you intend to deploy the software that knows about this URI
scheme?
BR, Julian
_______________________________________________
Ietf@xxxxxxxx
https://www.ietf.org/mailman/listinfo/ietf