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