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.
For those interested in the 4Suite design issues that motivated this quest, see threads starting at [1], [2],
and [3]
. Mike Brown summarized results of discussion in [4]. Note the folloing quotes:
> 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 short name?
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 [3]). 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 [2].
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.
Mike Brown posted a query to uri@w3.org and got this response from from Dan Connolly. From Connolly’s response:
I try to maintain an informal index of schemes... http://www.w3.org/Addressing/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 uri@w3.org 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. http://www.ietf.org/ietf/1id-guidelines.txt
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.
If this is a bad idea, do the same arguments against it also apply to RDF usage?
-m
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).
And I think you're a bit mixed up on "RDF usage". RDF is neutral on what sorts of URIs you use. People use UUIDs and other such URNs all the time. The FOAF people use mailto:. I think the point you're trying to make, which is not really pertinent to this discussion, is the philosophical one of what sort of URI to use for an abstract entity. I have long held that there is no "right" answer to this, and that using a dereferenceable HTTP URI is no worse than using some fancy special URI scheme. The only important matter is that ther is agreement.
But again, this is entirely irrelevant to this blog.