I believe I instigated the creation of a new URI scheme for HELD.
That's not to say, however, that I or the IESG required that solution
-- to elaborate on what Martin said, I raised some issues, and the URI
scheme was added after my review, but other solutions might work
instead of new URI schemes.
The discussions started in a bar in San Diego (unminuted). After that
there was list email. The issues that I was trying to help the WG
address:
- When an HTTP URI is found in an email, blog, etc, the operating
system launches a Web browser. However, a Web browser doesn't know
how to formulate a HELD request, and even if it did know how, it
wouldn't know when/whether.
- When location URIs appear in another context -- let's say, another
protocol or a data format -- it can be helpful to be able to limit
what kind of URIs appear in that context. Limiting by saying "These
URIs must be of this URI scheme" is an easy way to do so.
Both of these problems can be solved in other ways besides defining a
new URI scheme.
That said, a new URI scheme does help with both problems, and it does
highlight the issue that most regular HTTP requests (e.g. a GET
without a body) are not standardized or interoperable under HELD. It
should be OK to use a new URI scheme in the target of an HTTP request,
after all that's a well-defined point of HTTP extensibility in theory,
and I'm not aware of major client or server library limitations that
would prevent use in practice. If it has to be made explicit in the
document that defines the URI schemes, so be it -- I believe it was
implicit but obvious.
I'm aware of the W3C TAG recommendations on new URI schemes. Their TR
says " Good practice: Reuse URI schemes. A specification SHOULD reuse
an existing URI scheme (rather than create a new one) when it provides
the desired properties of identifiers and their relation to resources."
Some of their notes say for example: "You need to demonstrate there is
a bar for URIs [new schemes] doing what you want or there is a huge
value add". We can debate whether this example is a big value-add and
whether the HTTP URI fails to express that a client needs to do a
custom GET request, but given those caveats and the lack of an
official IESG or IETF position on this, I believe there's some
consistency between W3C TAG recommendations and IETF usage, and
potentially this specific usage.
Lisa
On Aug 5, 2008, at 4:23 PM, 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.
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.
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.)
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.
Cheers,
Martin
------------------------------------------------------------------------------------------------
This message is for the designated recipient only and may
contain privileged, proprietary, or otherwise private information.
If you have received it in error, please notify the sender
immediately and delete the original. Any unauthorized use of
this email is prohibited.
------------------------------------------------------------------------------------------------
[mf2]
_______________________________________________
Ietf@xxxxxxxx
https://www.ietf.org/mailman/listinfo/ietf
_______________________________________________
Ietf@xxxxxxxx
https://www.ietf.org/mailman/listinfo/ietf