Registering a new URI scheme
by Uche Ogbuji
For many applications it may be useful to define private URI schemes or at least schemes that have not been blessed by the full consideration of the IETF. Recently we have had occasion to consider a special scheme for resources in a 4Suite repository instance. Mike Brown and I set out to figure out how best to do this. Here are some notes from that effort that might be helpful to others with the same need.
> I too am leaning heavily towards ftss://user:pass@host:ftrpcport/.
> Yes it is strictly bogus, but unless we are willing to register a
> protocol, we have a choice between bogosity and file:.
> I think all the options of using file: are too confusing and/or
> limiting. Ergo, I'd rather be somewhat bogus with the ftss: scheme.
> As I said, I don't forsee any interop problems, because that scheme
> would never be used outside repo context.
Why is it bogus?
> Well, I might be wrong. I thought you can't just invent your own
> top-level scheme.
Research into scheme name selection followed, leading me to post
http://lists.w3.org/Archives/Public/uri/2002Dec/0006.html. So far, we got a
response from Dan Connolly, but no definitive advice as to choosing a good
scheme name. It seems the process of giving the IANA authority over
vendor-specific scheme names has stalled indefinitely, so we can probably
squat on whatever we want as long as we publish an Internet Draft about it for
the IETF. If they pick it up again, they'd probably want us to use vnd.ft.ftss
or vnd.fourthought.ftss rather than just ftss. So do we play nice or use the
We quickly found RFC 2717, and in particular section 3.3 which covers "Alternative Trees". From this section:
While public exposure and review of a URL scheme created in an
alternative tree is not required, using the IETF Internet-Draft
mechanism for peer review is strongly encouraged to improve the
quality of the specification. RFC publication of alternative tree
URL schemes is encouraged but not required. Material may be
published as an Informational RFC by sending it to the RFC Editor
(please follow the instructions to RFC authors, RFC 2223 ).
The defining document for an alternative tree may require public
exposure and/or review for schemes defined in that tree via a
mechanism other than the IETF Internet-Draft mechanism.
URL schemes created in an alternative tree must conform to the
generic URL syntax, RFC 2396. The tree's defining document may set
forth additional syntax and semantics requirements above and beyond
those specified in RFC 2396.
All new URL schemes SHOULD follow the Guidelines for URL Schemes, set
forth in RFC 2718 .
We also found URIs, URLs, and URNs: Clarifications and Recommendations 1.0, which introduces a dichotomy I hadn't heard of before: between a "Classical" and a "Contemporary" view of URI space partitioning.
We found Dan Connolly's informal index of URI addressing schemes. In particular, see the section on Registration of naming schemes.
I try to maintain an informal index of schemes...
but I find it disheartening. It seems that I find a handful
of unregistered schemes every day. I feel obliged to note
the schemes here in email@example.com and invite the developers
to register their schemes, but I don't often get around to it.
Help with that sort of thing is much appreciated.
Hmm... here's a bit of advice: whatever you end up doing, please
write a one-page internet draft about it.
Why not http:// ?
A half-serious question: Why not just use the http scheme? In RDF contexts, http URIs represent pretty much anything, whether or not the HTTP protocol is involved.
Why not http:// ?
These URIs are meant for actual retrieval in 4Suite. They are not opaque strings, as Namespace and RDF URIs are (and as URIs are in other areas).