rfc3367.txt

RFC 的详细文档！

   Any interfaces electing to present/accept protocol elements in other
   representations are responsible for accurate transcoding for use in
   CNRP protocol elements, per the above provisions.











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


3.5 Queries

   Queries are sent by the client to the server.  There are two types of
   queries.

   1.  A `special' initial query that establishes the schema for a
       particular CNRP database and communicates that to the client.
       The CNRP client will send this query, and in turn receive an XML
       document defining the query properties that the database
       supports.  (In CNRP, XML [8] is used to define and express all
       objects.)  This query is called the 'servicequery' in the DTD.
       In the case where a client does not know anything about the
       Service, the client MAY assume that it can at least issue the
       request via HTTP.

   2.  A `standard' query, which is the submission of the CNRP search
       string to the database.  The query will conform to the schema
       that MAY have been previously retrieved from the service.

   There will be a set of query properties, listed below, treated as
   hints by the server.  Note: a CNRP database will accept any correctly
   encoded CNRP query property; the extent to which a query result is
   responsive to those properties is a service differentiator.  The base
   properties that are always supported are common name, language,
   geography, category, and range (start and length of the result set).
   CNRP allows database service providers to create unique data types
   and expose them to any CNRP client via the CNRP schema XML documents.

3.6 Hints

   A hint is an assertion by the user about himself, herself or itself
   and the context in which he/she/it is operating.  There is no data
   type `hint'; a hint is expressed within the structure of the query
   itself and is limited or enabled by the richness of the defined query
   namespace.  In effect, a query and any property within it is a hint.

   For example, the "language" property can be given as a hint in a
   query; this may be used to order search results.  If one wants
   results first in US English followed by European French and finally
   South American Spanish, the following can be included in the query:

      <property name="language" type="rfc1766">en-US</property>

      <property name="language" type="rfc1766">fr-FR</property>

      <property name="language" type="rfc1766">sp-MX</property>





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


   Note that the property statements say nothing about whether the
   language is primary, secondary, etc.  In this example, the ordering
   of the statement controls that--the first statement, being first,
   means that US English is the primary language.  The second statement
   specifies the second region/language, and so on.  *But this is only
   an example.*  The extent to which hints are supported (or not) is a
   service differentiator.

   The fact that a hint exists does not mean that a CNRP database must
   respond to it.  This best-effort approach is similar to relevance
   ranking in a search engine (high precision, low recall); hints are
   similar to a search engine's selection criteria.  CNRP services will
   attempt to return the results "closest" to the selection criteria.
   This is quite different from a SQL database approach where a SQL
   query returns the entire results set and each result in the set must
   match all the requirements expressed by the qualifier (the SQL WHERE
   clause).

4. Object Model

4.1 Properties

   In CNRP, objects are property lists.  A property is a named
   attribute.  A property also has a well-defined type.  Some properties
   can be part of the query or the results list or both.  For
   simplicity, CNRP is limiting property values to string values.

4.1.1 Core Properties

   CNRP introduces a set of core properties.  Core properties are the
   minimal set of properties that all CNRP services MUST support in
   order to reach CNRP compliance.  Hence, the core properties define
   the level of interoperability between all CNRP services.  The core
   properties are:

   1.  CommonName: the common name associated with a resource.

   2.  ID: an opaque string that serves as a unique identifier for a
       result from a Service (typically a database ID).  The ID is not
       globally unique, nor necessarily persistent (e.g., between
       queries at a given Service).

   3.  resourceURI: An 'absoluteURI' as defined in the collected ABNF
       found in RFC 2396 [3].

   4.  description: A free text description of the resource.





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


4.1.2 Abstract and Custom Properties

   In addition to core properties, CNRP introduces the notion of
   abstract properties.  The abstract property element provides schema
   extensibility beyond the core properties.  The notion of abstract
   property is extremely important in CNRP since it enables a wider
   range of CNRP based services than those based on the core properties.

   To create concrete custom properties, a CNRP service must define a
   property name and a property type.  Therefore, there are really two
   ways to create a custom property.  The first way is to create a new
   property name and define at least one type for it.  Another way is to
   extend an existing property by defining a new type.  The "geography"
   property discussed in the next section is an example of a multi-type
   property.  Note that a type is only applicable to the property it is
   defined for.  If a new property is defined, a new type MUST be
   defined even though the value set for that type may be identical to
   an existing type for an existing property.  In other words, types are
   scoped to a given property.  Custom properties MUST be registered
   with IANA.  Details about the registration process for new properties
   can be found in Section 10.

   For example, let us assume that a CNRP service specialized on online
   books would like to introduce the ISBN property of type "number".
   This property would encapsulate the ISBN number of the book online
   and would have he following XML representation:

      <property name="isbn" type="number">92347231</property>

4.1.3 Base Properties

   Illustrating the use of abstract property to extend the core schema,
   CNRP also defines a set of custom properties called base properties.
   In order to keep the requirements extremely simple, these properties
   are not mandatory to implement to reach CNRP compliance.  Although,
   these properties are not required, it is expected that many services,
   especially large ones, will implement them.  An equally important
   goal for introducing additional properties is to provide a results
   filtering mechanism.  This is a requirement for large namespaces that
   contain several million names.











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


   The base properties and their types are defined in Appendix A but
   listed here for clarity:

   o  Language:
      The language associated with a resource.  The default type of this
      property is 'RFC1766' and the vocabulary is drawn from the list of
      languages in RFC 1766 [4].  If RFC 1766 is updated, then the
      values listed in the updated version are also valid for this type.

   o  Geography:
      The geographical region or location associated with a resource.
      Some of the possible types are listed below.  See Appendix A for a
      complete list of types specified by this document.

      *  'freeform': a free form expression for a geographical location
         (e.g., "palo alto in california").

      *  'ISO3166-1': geographical region expressed using a standard
         country code as defined by ISO3166-1 (e.g., "US").

      *  'ISO3166-2': value = a geographical region expressed using a
         standard region and country codes as defined by ISO3166-2
         (e.g., "US-CA").

      *  'lat-long': the latitude and longitude of a geographical
         location.

   o  Category:
      The category associated with a resource.  There are large numbers
      of possible types for this property.  Two possible ones are:

      1.  'freeform': a free form expression for a category (e.g.,
          "movies").

      2.  'NAICS': The North American Industry Code System.

   o  Range:
      The range is a results set control property.  The range property
      is used to specify the starting point and the length of a results
      set (e.g., I want 5 records starting at the 10th record).  It
      should only ever have one type but, in the interest of
      extensibility and consistency, others can be created if there is a
      need.  The default type is 'start-length' which takes the form of
      two integers separated by a dash.  The first integer is the
      starting number and the second is the number of values to include.






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


   o  Dataseturi: An absoluteURI (as defined in [3] that identifies a
      defined set of Common Names and associated data.

   Note: For many properties the default "type" is "freeform".  The free
   form type value is important because it allows very simple user
   interface where the user can enter a value in a text field.  It is up
   to the service to interpret the value correctly and take advantage of
   it to increase the relevance of results (using specialized
   dictionaries for instance).

4.1.4 Common Name String Encoding and Equivalence Rules

   CNRP specifies that common name strings should be encoded using UTF-
   8.  CNRP does not specify any string equivalence rules for matching a
   common name in the query against a common name of a Resource.  String
   equivalence rules are language and service dependent.  They are
   specific to relevance ranking algorithms, hence treated as CNRP
   services.  Consequently, string equivalence rules are not part of the
   CNRP protocol specification.  For example, the query member:

      <commonname>bmw</commonname>

   should be read as a selection criterion for a resource with a common
   name LIKE (similar to) the string "bmw" where the exact definition of
   the LIKE operator is intuitive, yet specific to the queried CNRP
   service.

   It is also important to note that XML treats whitespace as a special
   case in many situations.  In some cases, it collapses whitespace into
   a single space.  Both client and server Implementors are warned to
   reference the XML standard for the various ramifications of using
   whitespace in queries and/or results.

4.2 Objects

4.2.1 Query

   The Query object encapsulates all the query components such as
   CommonName, ID, and any properties.  A Query cannot be empty.  A
   Query must contain either one and only one common name, or one and
   only one ID.  A Query can also contain the custom properties defined
   by a specific CNRP service.









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


   For example, a query for the first 5 resources whose common name is
   like "bmw" would be expressed as:

   <query>
           <commonname>bmw</commonname>
           <property name="range" type="start-length">1-5</property>
   </query>

4.2.1.1 Logical Operations Within a Query

   The Query syntax is extremely simple.  CNRP does not extensively
   support Boolean logic operator such as OR, AND or NOT.  However,
   there exist two implicit logical operations that can be expressed
   through the Query object and its properties.  First, a query with
   multiple property-value pairs implicitly expresses an AND operation
   on the query terms.  For instance, the CNRP query to request all the
   resources whose common name is like "bmw", AND whose language is
   "German" can be expressed as:

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