Common Name Resolution Protocol (CNRP)
Extracted elements (28)
Query properties are treated as 'hints' rather than strict SQL-style WHERE clauses. The server makes a best-effort to return results closest to the selection criteria; there is no guarantee that all results match all hints. This is intentional to support relevance-ranking services and internationalization.
String equivalence rules for matching a query common name against a resource are deliberately excluded from the CNRP protocol specification because they are language- and service-dependent, tied to relevance-ranking algorithms, and thus treated as a service differentiator rather than a protocol concern.
The Dataset concept enables separation of resolution from data, allowing one CNRP service to resolve common names on behalf of another service or multiple services, and allowing the same dataset to be served by two distinct CNRP services. Dataset declaration and use are completely optional for protocol compliance.
The XML DTD in Section 5 is definitive; the XML fragments elsewhere in the document are illustrative examples only. In any discrepancy between descriptive prose and the DTD, the DTD wins.
Rigorous loop detection requires tracking visited nodes as (serviceuri, dataseturi) pairs. Servers that do not support datasets send status 3.1.3 (marking the entire service as visited for all datasets); servers that support only one dataset at a time send 3.1.4 (marking only the first serviceuri/dataseturi pair as visited).
The special wildcard value '*' in a property means all admissible values for that typed property, enabling ordered preference lists (e.g., de-DE, then fr-FR, then any language). This value is only applicable to properties, not to the CommonName element itself.
A Service object is uniquely identified through the serviceuri tag, which MUST be included. A Service MUST have at least one Server that responds on the default CNRP port so that a client can obtain the initial Service object.
All generic CNRP clients and servers MUST support the HTTP transport on the default CNRP port of 1096. Special-purpose CNRP applications that never need HTTP bootstrapping MUST define how to find the appropriate server/port/protocol.
All URIs used within the CNRP protocol MUST adhere to the 'absoluteURI' production found in the ABNF of RFC 2396. CNRP does not define the semantics of a Base and is not capable of expressing the 'URI-Reference' production.
Core properties (CommonName, ID, resourceURI, description) are the minimal set that all CNRP services MUST support to reach CNRP compliance; they define the base level of interoperability between all services.
Custom properties MUST be registered with IANA. If a property or type is not registered with IANA, it must start with 'x-'. Types are scoped to a given property; if a new property is defined, a new type MUST be defined even if the value set is identical to an existing type.
In cases where transports use MIME Media Types (HTTP and SMTP), the CNRP payload MUST use the 'application/cnrp+xml' media type. Since CNRP always uses UTF-8, there is no charset attribute for this media type.
Status code 2.1.0 (Query succeeded) MUST be returned when there were no results that matched the query; the lack of results is not an error but a successful statement about the common name.
Status messages about features or operations defined by the transport (e.g., security via HTTP, mail failure via SMTP) MUST be sent in accordance with that transport's reporting mechanism and not via CNRP status codes.
The ResourceDescriptor object MUST always include the resourceURI property, which is an absoluteURI identifying the Internet resource being described.
XML queries and responses MUST be encoded as UTF-8. Interfaces that present or accept protocol elements in other representations are responsible for accurate transcoding.
The Dataset object represents a uniquely identified set of CN-to-URI mappings, identified via the dataseturi property. A service can contain zero or more datasets; any service has an implicit 'default dataset' used when no dataset is specified in a query.
The Query object encapsulates all query components. A Query cannot be empty and must contain either exactly one common name or exactly one ID, plus optional custom properties. Multiple different properties are ANDed; multiple instances of the same property are ORed.
The Referral object is a placeholder for un-fetched results from a different service or dataset. It contains a Service object reference and optional properties, enabling hierarchical resolution and joining of multiple resolution services without server-side chaining.
The ResourceDescriptor object describes an Internet resource and MUST include the resourceURI property. It may also contain commonname, ID, description, language, geography, category, and custom properties, plus a serviceRef element indicating its service of origin.
The Results object is a container for CNRP results including ResourceDescriptors, Status messages, Referrals, and Schema. Results from a single CNRP service are ordered by decreasing relevance; aggregated results from multiple services cannot be globally ordered.
The ServiceQuery object is a subclass of Query that supports dynamic discovery of a CNRP service's capabilities. Its response includes the Service object with property schema, service schema, query schema, and resourcedescriptor schema; returning the Service with serviceuri alone constitutes minimal compliant implementation.
IANA will maintain registries for CNRP well-known properties (requiring property name, default type, and description), property types (requiring type name, applicable properties, and description), and status messages (requiring the X.Y.ZZZ code and brief description). All registrations are on a First Come First Served basis with no expert review.
The media type 'application/cnrp+xml' is registered with IANA. It has no required or optional parameters; since CNRP always uses UTF-8, there is no charset attribute. The media type is a proper subset of the XML 1.0 specification.
Three security threats are identified: man-in-the-middle attacks (mitigated by transport-level authentication/encryption or XML signature methods from XMLDSIG), malicious agents spoofing a Service object (mitigated by signing the Service object so clients can verify its authenticity), and DoS attacks enabled by the added level of indirection in resolution.
Status codes follow the RFC 1893 structure: class '.' subject '.' detail, where class is 2/3/4/5 (success through permanent failure), subject is 1-3 digits indicating the category, and detail is 1-3 digits with specifics. The subject sub-code MUST be reported if recognized even if the detail sub-code is not.
The HTTP transport uses the POST method to the '/' path with both Content-Type and Accept headers set to 'application/cnrp+xml'. The request body and response body are the CNRP XML document; all HTTP 1.1 features are allowed.
The Range property uses type 'start-length' with two integers separated by a dash (e.g., '1-5'), where the first integer is the starting record number and the second is the count of records to return.