(Status: need to reconcile with URNs, Namespaces and Registries and newer DDDS)
Use cases: "link relations", RDF nodes, HTTP nodes
One way a standard can facilitate evolution is to allow for extensibility in some of the protocol elements it uses, an extension is made by adding a new values for a protocol element, which element was not part of the protocol or language at the time the specification was written.
Some protocol elements used in a language or protocol allow values which act as identifiers: determining the meaning those values requires information which is specified independently. In some cases, an identifier might come from a fixed set of values (e.g., identifiers for the days of the week). But in many cases,extensibility is accomplished by adding a new value with associated meaning.
The Web uses many protocol elements which are identifiers. (For example, character entities in HTML, content-types, uri schemes, color names, host names, HTTP headers. see Appendix A for a more complete list.)
There are many different methods used for managing identifiers, and the choice is often a controversial element of the design of a language or protocol and the speficiation for it. Some of the differences are well-justified, but others are artifacts of history.
This section discusses considerations when designing a protocol element which uses identifiers. make sure the process for extending a standard needs to have similar characteristics as the standard itself, in terms of "fair" and "transparent", make sure the registry is as long-lived as the specifications that use it, avoid problems of trademark, spam, denial of service, ..., and Identifier length (Some protocols and languages are sensitive to the space usage and compressibility of long strings used as identifiers; in such cases, identifier length is a consideration)
There are a variety of ways for allocating identifiers and the meaning associated with them:
What are the processes for designing and deploying extensions?
(this section is intended to give a broad evaluation of the categories against the evaluation criteria; also still an outline of notes ...)
In Specification: Low cost of implementation extension, higher cost of specification update, fairness depends on same standards process as anything else, long lifetime, transition from implementation to specification is painful but that's what standards are about.
Registry: (see Section Registries below for 'best pratices' when this is the right choice). Cost of setting up registry, managing it, expert review, benefit of avoiding interactions, fairness issues, trademark & spam. Allows using numbers and meaningless values to avoid trademark spam, and difficulties of internationalization.
Using URIs: Example: RDF. Meaning is discovered by httpRange14. Low cost (no registration process, might require maintaining URI. Very timely. Transition unnecessary. Lifetime up to lifetime of URI. Very fair. Hard to misuse because no registry. Preferred method, modulo longevity of URIs. Note that URN allows naming a registry as a URI.
Vendor Prefix: (example from CSS. Transition path difficulties outlined in [ref]
URI-named namespace: XML namespaces, RDF (?).
Finding.DefineExtensibility: Extensibility and evolution must be planned and provided for in specifications that become standards. Standards that use identifiers should also specify the expected behavior of compliant implementations when confronted with unrecognized identifiers; for example, to distinguish between "must understand" and "must ignore" for unrecognized identifiers. Without also constraining implementation behavior, the fact that the specification might be extensible will not translate into an effective way of allowing implementations to evolve.
Finding.AvoidRegistries: (Non-IANA registries have a problem with the long-term viability and control of the registry over, say, a 20 year period. Avoiding registries or using IANA seem preferable for the long term. In the short-term, using a Wiki seems like it's ok? Whether or not you use a registry with some gatekeeping and review may depend on the cost of extensibility... if it's low, then use a URI or vendor prefix. if it's high, use In Specification. In the middle, use a Registry with review. ) See recent Understanding URI Hosting Practice as Support for Documentation Discovery as evolution of httpRange-14.