rfc3367.txt

RFC 的详细文档！

   </query>

   Note however, that because the server is only trying to best match
   the Query criteria, there is no guarantee that all or any of the
   resources in the results match both requirements.

   In addition, CNRP allows the client to express a logical OR by
   specifying multiple values for the same property within the Query.
   For example, the logical expression:

      property = value1 OR property = value2 OR property = valueN

   Will be expressed as:

   <property>value1</property>
   <property>value2</property>
   <property>valueN</property>

   So if there are different properties expressed, CNRP ANDs them; if
   there are multiples instances of the same property expressed, CNRP
   ORs them.






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


   It is important to underline that this form is only applicable to
   properties (with the exception of the CommonName itself which, even
   though it is a property, is the entire point of the query).  In
   particular, logical OR operations on the common name are not
   supported.  Note that the ordering or the property-value pairs in the
   query implies a precedence.  As a consequence, CNRP also introduces
   one special string value: "*".  Not surprisingly, "*" means all
   admissible values for the typed property.  For example, the following
   query requests all the resources whose common name is like BMW and
   whose language is preferably in German or French or any other
   language.

   <query>
        <commonname>bmw</commonname>
        <property name="language" type="rfc1766">de-DE</property>
        <property name="language" type="rfc1766">fr-FR</property>
        <property name="language" type="rfc1766">*</property>
   </query>

4.2.2 Results

   The results object is a container for CNRP results.  The type of
   objects contained in Results can be: ResourceDescriptor, Error,
   Referral and Schema.  Results from a CNRP service are ordered by
   decreasing relevance.  When the results set contains results from
   multiple CNRP services, the results can no longer be ordered (since
   relevance ranking is specific to a given service).  In that case,
   however, note that results originating from the same service remain
   ordered.

4.2.2.1 ResourceDescriptor

   The ResourceDescriptor object describes an Internet resource (e.g., a
   Web page, a person, any object identified by a URI).  Therefore, the
   ResourceDescriptor MUST always include the resourceURI property.  The
   ResourceDescriptor can also contain the commonname, URI, ID (the ID
   of this entry in the service's database), description, language,
   geography, and category of the resource.  A ResourceDescriptor can
   also be augmented using custom properties and can reference a service
   object to indicate its origin (using the serviceRef element).  As
   with referrals, a resourcedescriptor block can also contain an ID
   attribute that is used by a status message to refer to a particular
   resourcedescriptor.  Be careful not to confuse this ID with the id
   tag itself which refers to the database id of the actual database
   entry.






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


   <results>
        <service id="i0">
             <serviceuri>http://cnrp.bar.com/</serviceuri>
        </service>
        <resourcedescriptor id="i1">
             <commonname>bmw</commonname>
             <id>foo.com:234364</id>
             <resourceuri>http://www.bmw.de/</resourceuri>
             <serviceref ref="i0" />
             <description>BMW Motorcycles, International</description>
             <property name="language" type="rfc1766">de-DE</property>
        </resourcedescriptor>
        <referral>
             <serviceref ref="i0" />
        </referral>
   </results>

4.2.3 Service

   The Service object provides an encapsulation of an instance of a CNRP
   service.  A service is uniquely identified through the serviceuri tag
   which MUST be included in the Service object.  A Service object MAY
   include a a brief textual description of the service.  It MAY include
   datasets, servers and custom properties.

   <service>
        <serviceuri>http://cnrp.foo.com</serviceuri>
        <description>foo.com is a CNRP service specialized on cocktail
           recipes</description>
   </service>

   The service object MAY also be extended by including existing
   properties to further describe the service.  For instance, a service
   that focuses on French companies could be expressed as:

   <service>
        <serviceuri>http://cnrp.foo.com</serviceuri>
        <property name="category" type="freeform">companies</property>
        <property name="geography" type="ISO3166-1">FR</property>
   </service>

4.2.3.1 Datasets

   The dataset object represents a set of CN-to-URI mappings.  For
   example, the database of AOL keywords and their URIs constitute a
   dataset.  The dataset object allows a CNRP implementation to uniquely
   identify the database(s) of mappings that it resolves.  In that
   respect, the notion of dataset allows a separation between resolution



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


   and data, providing the mechanism for a CNRP service to resolve
   common-names on behalf of another CNRP service or even multiple
   services.  Conversely, the same dataset can be served by two distinct
   CNRP services.  Since a CNRP service can resolve names within one or
   more datasets, the service object can contain one or more dataset
   objects (zero if the dataset is not formally declared).

   Within the service object, a dataset is uniquely defined using the
   dataseturi property.  Other properties, such as language and
   description, can describe the dataset further.  Like the service
   object, the dataset object has an ID attribute associated with it
   that is unique within a particular XML message.  Like the service
   object's ID attribute, this ID is used by resourcedescriptors and
   referrals to specify which service and/or dataset they came from or
   are referring to.

   Any service can be said to have a 'default dataset' which is the
   dataset that considered to have been used if a server simply responds
   to a client's query that didn't contain a dataset.  The 'default
   dataset' can also be said to be the only dataset that is used by
   Services that don't support datasets at all.  This concept is useful
   for clients that intend on doing rigorous loop detection by way of
   keeping a list of visited service/dataset nodes.

   This example illustrates how the service object would look as it
   defines two datasets:

   <service id="i0">
    <serviceuri>http://acmecorp.com</serviceuri>
    <dataset id="i1">
      <property name="dataseturi">
         urn:oid:1.2.3.4.666.5.4.3.1
      </property>
      <property name="language">en-us</property>
      <property name="language">en-gb</property>
    </dataset>
    <dataset id="i2">
      <property name="dataseturi">
         urn:oid:1.2.3.4.666.10.9.8.7.6
      </property>
      <property name="language">fr</property>
    </dataset>
   </service>

   The dataseturi property can also be used within the query as a hint
   to the service for the dataset within which the commonname should be
   resolved:




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


   <query>
      <commonname>toys r us</commonname>
      <property name="dataseturi">urn:oid:1.2.3.4.666.5.4.3.1</property>
   </query>

   It is important to note that resolution rules (i.e., string
   equivalence, relevance ranking, etc.) are likely to be dataset
   specific.  This is true even if the resolution is provided by the
   same service.

   Another use of the dataseturi property is in a referral.  In that
   case, the datasetref tag is used to pinpoint a specific dataset
   within the service.

   <referral>
      <serviceref ref="i0" /><datasetref ref="i1" />
   </referral>

   While the concept of datasets is important for services wishing to
   make their data available via other services, it is important to
   remember that the declaration and use of datasets is completely
   optional.  Compliance with the CNRP protocol does not require a
   service object to define or reference any dataset object.  The only
   requirement for compliance is that a client and/or server know the
   format of the particular XML tags and deal with them syntactically.
   If it chooses to ignore them, then this is well within its rights.

4.2.3.2 Servers

   The service object also encapsulates a list of server objects.  The
   server object is used to describe a CNRP server or set of servers.  A
   server is identified through its serveruri.  The URI used to identify
   a server is not a CNRP URI [9], but instead, is a URI of the scheme
   used as the CNRP transport mechanism.  I.e., for a CNRP server that
   will communicate via the HTTP protocol to the host foo.com on port
   6543, the serveruri would be http://foo.com:6543.  If some other
   information is required in order for the correct transport to be
   used, then that information can be communicated via other properties.
   Note that a Service MUST have at least one Server that responds on
   the default CNRP port in order for a client to get the initial
   Service object.

   A server can serve one or more datasets declared by its service.  The
   served databases are specified using the dataseturi property.  As for
   other objects, a server can be further described using descriptive
   properties such as geography and description.  The following XML
   completes the service definition from the previous example by
   defining two CNRP servers.  One server is located in the US and the



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


   other is located in France.  The US server is specialized and only
   serves the French dataset.

     <servers>
        <server>
           <serveruri>cnrp://router.us.widgetco.com:4321</serveruri>
           <property name="geography" type="ISO3166-1">US</property>
        </server>
        <server>
           <serveruri>cnrp://router.fr.acmeco.com:4321</serveruri>
           <property name="geography" type="ISO3166-1">FR</property>
        </server>
     </servers>

   As we will see in a following section, the Service object can contain
   Schema objects.  These Schema objects fully describe the query and
   response interfaces implemented by a CNRP service.  In that regard,
   the Service object is essential to discoverability.  It constitutes
   the main entry point for a CNRP client to dynamically discover the
   capabilities of a resolution service.  For that purpose, the Service
   object can be returned as part of the response to any resolution
   query.  Furthermore, the Service object is the dedicated response to
   the specialized servicequery (see Section 4.2.6).

   Another use of Service is for other objects to indicate their CNRP
   service of origin.  System messages, referrals and
   resourcedescriptors can include a reference to their Service object.
   For example, imagine a CNRP service that acts as a proxy for multiple
   CNRP services.  For example, it is a requirement that CNRP allows
   aggregation of results from different sources.  Consider one such
   CNRP service that acts as a proxy for multiple CNRP services.  In
   this mode, the proxy service contacts each CNRP sub-service in
   parallel or serially.  Then, the proxy combines the individual result
   sets into a unique response returned to the CNRP client.  Since the
   aggregate result set contains resourcedescriptors from different
   services, the proxy adds a servicereference tag within each
   individual result to indicate their service of origin.  In the event
   one of the referred services resolves names within multiple datasets,
   it is possible for these objects to refer to a specific dataset
   within the service by using the datasetref tag.  This example is of a
   hybrid result set with resourcedescriptors referencing their service
   and dataset of origin:









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


   <?xml version="1.0"?>
   <!DOCTYPE cnrp PUBLIC "-//IETF//DTD CNRP 1.0//EN"
       "http://ietf.org/dtd/cnrp-1.0.dtd">
   <cnrp>
        <results>
             <service id="i0">
                  <serviceuri>http://acmecorp.com</serviceuri>
                  <dataset id="i1">
                     <property name="dataseturi">
                      urn:oid:1.2.3.4.666.5.4.3.1
                     </property>