rfc3367.txt

RFC 的详细文档！

Network Working Group                                            N. Popp
Request for Comments: 3367                                   M. Mealling
Category: Standards Track                                 VeriSign, Inc.
                                                              M. Moseley
                                                           Netword, Inc.
                                                             August 2002


                 Common Name Resolution Protocol (CNRP)

Status of this Memo

   This document specifies an Internet standards track protocol for the
   Internet community, and requests discussion and suggestions for
   improvements.  Please refer to the current edition of the "Internet
   Official Protocol Standards" (STD 1) for the standardization state
   and status of this protocol.  Distribution of this memo is unlimited.

Copyright Notice

   Copyright (C) The Internet Society (2002).  All Rights Reserved.

Abstract

   People often refer to things in the real world by a common name or
   phrase, e.g., a trade name, company name, or a book title.  These
   names are sometimes easier for people to remember and type than URLs.
   Furthermore, because of the limited syntax of URLs, companies and
   individuals are finding that the ones that might be most reasonable
   for their resources are being used elsewhere and so are unavailable.
   For the purposes of this document, a "common name" is a word or a
   phrase, without imposed syntactic structure, that may be associated
   with a resource.

   This effort is about the creation of a protocol for client
   applications to communicate with common name resolution services, as
   exemplified in both the browser enhancement and search site
   paradigms.  Although the protocol's primary function is resolution,
   it is also intended to address issues of internationalization and
   localization.  Name resolution services are not generic search
   services and thus do not need to provide complex Boolean query,
   relevance ranking or similar capabilities.  The protocol is a simple,
   minimal interoperable core.  Mechanisms for extension are provided,
   so that additional capabilities can be added.







Popp, et. al.               Standards Track                     [Page 1]

RFC 3367         Common Name Resolution Protocol (CNRP)      August 2002


Table of Contents

   1.      Introduction . . . . . . . . . . . . . . . . . . . . . . .  3
   2.      Important Notes  . . . . . . . . . . . . . . . . . . . . .  4
   2.1     Terminology  . . . . . . . . . . . . . . . . . . . . . . .  4
   2.2     DTD is Definitive  . . . . . . . . . . . . . . . . . . . .  4
   2.3     Uniform Resource Identifiers . . . . . . . . . . . . . . .  5
   3.      Interaction Model  . . . . . . . . . . . . . . . . . . . .  5
   3.1     Services, Servers, Datasets and Referrals  . . . . . . . .  5
   3.2     Requests and Responses . . . . . . . . . . . . . . . . . .  5
   3.3     Transport Independence . . . . . . . . . . . . . . . . . .  6
   3.4     Character encoding . . . . . . . . . . . . . . . . . . . .  6
   3.5     Queries  . . . . . . . . . . . . . . . . . . . . . . . . .  7
   3.6     Hints  . . . . . . . . . . . . . . . . . . . . . . . . . .  7
   4.      Object Model . . . . . . . . . . . . . . . . . . . . . . .  8
   4.1     Properties . . . . . . . . . . . . . . . . . . . . . . . .  8
   4.1.1   Core properties  . . . . . . . . . . . . . . . . . . . . .  8
   4.1.2   Abstract and custom properties . . . . . . . . . . . . . .  9
   4.1.3   Base properties  . . . . . . . . . . . . . . . . . . . . .  9
   4.1.4   Common name string encoding and equivalence rules  . . . . 11
   4.2     Objects  . . . . . . . . . . . . . . . . . . . . . . . . . 11
   4.2.1   Query  . . . . . . . . . . . . . . . . . . . . . . . . . . 11
   4.2.1.1 Logical operations within a Query  . . . . . . . . . . . . 12
   4.2.2   Results  . . . . . . . . . . . . . . . . . . . . . . . . . 13
   4.2.2.1 ResourceDescriptor . . . . . . . . . . . . . . . . . . . . 13
   4.2.3   Service  . . . . . . . . . . . . . . . . . . . . . . . . . 14
   4.2.3.1 Datasets . . . . . . . . . . . . . . . . . . . . . . . . . 14
   4.2.3.2 Servers  . . . . . . . . . . . . . . . . . . . . . . . . . 16
   4.2.4   Status Messages  . . . . . . . . . . . . . . . . . . . . . 19
   4.2.4.1 Status of CNRP, Not the Transport  . . . . . . . . . . . . 19
   4.2.4.2 Codes and Description  . . . . . . . . . . . . . . . . . . 19
   4.2.4.3 Status Codes . . . . . . . . . . . . . . . . . . . . . . . 19
   4.2.5   Referral . . . . . . . . . . . . . . . . . . . . . . . . . 21
   4.2.5.1 Loop Detection and Dataset Handling in Servers . . . . . . 22
   4.2.6   Discoverability: ServiceQuery and Schema . . . . . . . . . 24
   5.      XML DTD for CNRP . . . . . . . . . . . . . . . . . . . . . 26
   6.      Examples . . . . . . . . . . . . . . . . . . . . . . . . . 28
   6.1     Service Description Request  . . . . . . . . . . . . . . . 28
   6.2     Sending A Query and Getting A Response . . . . . . . . . . 29
   7.      Transport  . . . . . . . . . . . . . . . . . . . . . . . . 30
   7.1     HTTP Transport . . . . . . . . . . . . . . . . . . . . . . 30
   7.2     SMTP Transport . . . . . . . . . . . . . . . . . . . . . . 31
   8.      Registration: application/cnrp+xml . . . . . . . . . . . . 31
   9.      Security Considerations  . . . . . . . . . . . . . . . . . 32
   10.     IANA Considerations  . . . . . . . . . . . . . . . . . . . 32
           References . . . . . . . . . . . . . . . . . . . . . . . . 33





Popp, et. al.               Standards Track                     [Page 2]

RFC 3367         Common Name Resolution Protocol (CNRP)      August 2002


   A.      Appendix A: Well Known Property and Type Registration
           Templates  . . . . . . . . . . . . . . . . . . . . . . . . 35
   A.1     Properties . . . . . . . . . . . . . . . . . . . . . . . . 35
   A.2     Types  . . . . . . . . . . . . . . . . . . . . . . . . . . 35
   B.      Status Codes . . . . . . . . . . . . . . . . . . . . . . . 37
   B.1     Level 1 (Informative) Codes  . . . . . . . . . . . . . . . 37
   B.2     Level 2 (Success) Codes  . . . . . . . . . . . . . . . . . 38
   B.3     Level 3 (Partial Success) Codes  . . . . . . . . . . . . . 38
   B.4     Level 4 (Transient Failure) Codes  . . . . . . . . . . . . 40
   B.5     Level 5 (Permanent Failures) Codes . . . . . . . . . . . . 40
           Authors' Addresses . . . . . . . . . . . . . . . . . . . . 41
           Full Copyright Statement . . . . . . . . . . . . . . . . . 42

1. Introduction

   Services are arising that offer a mapping from common names to
   Internet resources (e.g., as identified by a URI).  These services
   often resolve common name categories such as company names, trade
   names, or common keywords.  Thus, such a resolution service may
   operate in one or a small number of categories or domains, or may
   expect the client to limit the resolution scope to a limited number
   of categories or domains.  For example, the phrase "Internet
   Engineering Task Force" is a common name in the "organization"
   category, as is "Moby Dick" in the book category.

   Two classes of clients of such services are being built, browser
   improvements and web accessible front-end services.  Browser
   enhancements modify the "open" or "address" field of a browser so
   that a common name can be entered instead of a URL.  Internet search
   sites integrate common name resolution services as a complement to
   search.  In both cases, these may be clients of back-end resolution
   services.  In the browser case, the browser must talk to a service
   that will resolve the common name.  The search sites are accessed via
   a browser.  In some cases, the search site may also be the back-end
   resolution service, but in others, the search site is a front-end to
   a collection of back-end services.

   This effort is about the creation of a protocol for client
   applications to communicate with common name resolution services, as
   exemplified in both the browser enhancement and search site
   paradigms.  Name resolution services are not generic search services
   and thus do not need to provide complex Boolean query, relevance
   ranking or similar capabilities.  The protocol is a simple, minimal
   interoperable core.  Mechanisms for extension are provided, so that
   additional capabilities can be added.






Popp, et. al.               Standards Track                     [Page 3]

RFC 3367         Common Name Resolution Protocol (CNRP)      August 2002


   Several other issues, while of importance to the deployment of common
   name resolution services, are outside of the resolution protocol
   itself and are not in the initial scope of the proposed effort.
   These include discovery and selection of resolution service
   providers, administration of resolution services, name registration,
   name ownership, and methods for creating, identifying or insuring
   unique common names.

   For the purposes of this document, a "common name" is a word or a
   phrase, without imposed syntactic structure, that may be associated
   with a resource.  These common names will be used primarily by
   humans, as opposed to machine agents.  A common name "resolution
   service" handles these associations between common names and data
   (resources, information about resources, pointers to locations,
   etc.).  A single common name may be associated with different data
   records, and more than one resolution service is expected to exist.
   Any common name may be used in any resolution service.

   Common names are not URIs (Uniform Resource Identifiers) in that they
   lack the syntactic structure imposed by URIs; furthermore, unlike
   URNs, there is no requirement of uniqueness or persistence of the
   association between a common name and a resource.  (Note: common
   names may be expressed in a URI, the syntax for which is described in
   RFC 3368 [9].)

   This document will define a protocol for the parameterized resolution
   necessary to make common names useful.  "Resolution" is defined as
   the retrieval of data associated (a priori) with descriptors that
   match the input request.  "Parameterized" means the ability to have a
   multi-property descriptor.  Descriptors are not required to provide
   unique identification, therefore 0 or more records may be returned to
   meet a specific input query.

2. Important Notes

2.1 Terminology

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in RFC 2119 [7].

2.2 DTD is Definitive

   The descriptive portions of this document contain pieces of XML that
   are *illustrative examples only*.  Section 5 of this document
   contains the XML DTD for CNRP, which is definitive.  If any
   discrepancies are found, the DTD wins.




Popp, et. al.               Standards Track                     [Page 4]

RFC 3367         Common Name Resolution Protocol (CNRP)      August 2002


2.3 Uniform Resource Identifiers

   All URIs used within the CNRP protocol MUST adhere to the
   'absoluteURI' production found in the ABNF of [3].  CNRP does not
   define the semantics of a Base and therefore is not capable of
   expressing the 'URI-Reference' production.

3. Interaction Model

3.1 Services, Servers, Datasets and Referrals

   CNRP assumes a particular interaction model where a generalized
   "service" provides common name resolution at one or more actual
   "servers".  If the data contained in all its servers is identical
   (mirrors), the service need not identify any particular subset of
   data.  If, however, the service provides different collections of
   data through different servers (e.g., subsets, specialized
   collections, etc.), it SHOULD indicate what subsets of its data that
   each server offers.  This is done by using URIs to uniquely
   disambiguate one dataset from another.  If the service offers a copy
   of a collection of data on agreement with a foreign service, the
   foreign service SHOULD provide a dataset URI to allow the collection
   to be identified as related to its own offerings.

   CNRP supports the concept of referrals.  This is where a server can
   know that another Service exists, within the same Service or
   elsewhere, that can provide further answers to a particular query but
   decides to forward that fact onto the client instead of chaining the
   query for the client.  A referral is sent along with the rest of the
   results from a server (if any).  Referrals to a service SHOULD
   indicate the particular dataseturi that triggered the referral, if it
   is known.  See Section 4.2.5 for details on referrals and loop
   detection.

3.2 Requests and Responses

   The protocol consists of a simple request/response mechanism.  A
   client sends one of a few types of requests to a server which
   responds with the results of that request.  All requests and
   responses are encoded with XML [8] using the DTD found in Section 5.
   There are two types of requests.  One is a general query for a
   common-name.  The other is a request for an object that describes the
   service and its capabilities.  There is only one type of response
   which is a set of results.  Results can contain actual result items,
   referrals and/or status messages.






Popp, et. al.               Standards Track                     [Page 5]

RFC 3367         Common Name Resolution Protocol (CNRP)      August 2002


3.3 Transport Independence

   CNRP is completely encapsulated within its XML definition, and is
   therefore transport-independent in its specification.  However,
   clients need to have a clearly defined means of bootstrapping a
   connection with a server.

   It is possible to define special-purpose applications that use CNRP
   but which never need the HTTP bootstrapping method outlined below;
   those applications MUST define how to find the appropriate
   server/port/protocol.  CNRP servers dedicated to those applications
   may provide service only on the ports/transport protocols defined by
   the application.

   All other (generic) CNRP clients and servers MUST support the HTTP
   (Section 7.1) transport on the default CNRP port of 1096.

   Note that a particular service may choose to change to a different
   transport or port via statements within a CNRP service description
   request, but with initial contacts between a client and a server
   being over HTTP on port 1096.  For a short explanation of how CNRP
   employs HTTP, see Section 7.1 of this document.  If other transports
   are used, they MUST be handled over a port other than the default
   CNRP port.

3.4 Character Encoding

   To guarantee interoperability, the following provisions apply:

   o  XML queries and responses MUST be encoded as UTF-8.

      Note: As in any XML document, numeric character references may be
      used.

   o  The encoding of characters in the CNRP URI is based on UTF-8; for
      details, please see [9].