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 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 ). 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... 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 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. http://www.ietf.org/ietf/1id-guidelines.txt