rfc3367.txt

RFC 的详细文档！

                  </dataset>
                  <dataset id="i2">
                     <property name="dataseturi">
                      urn:oid:1.2.3.4.666.10.9.8.7.6
                     </property>
                  </dataset>
             </service>
             <service id="i3">
                <serviceuri>http://serverfarm.acmecorp.com</serviceuri>
             </service>
             <service id="i4">
                 <serviceuri>http://servers.acmecorp.co.uk</serviceuri>
                 <dataset id="i5">
                     <property name="dataseturi">
                       urn:oid:1.2.3.4.666.5.4.3.1
                     </property>
                 </dataset>
             </service>
             <resourcedescriptor>
                       <commonname>Fidonet</commonname>
                       <id>1333459455</id>
                       <resourceuri>http://www.fidonet.ca</resourceuri>
                       <serviceref ref="i0" /><datasetref ref="i1" />
                       <description>This is ye olde Canadian
                        Fidonet</description>
             </resourcedescriptor>
             <resourcedescriptor>
                       <commonname>Fidonet</commonname>
                       <id>1333459455</id>
                       <resourceuri>http://host:port/bla</resourceuri>
                       <serviceref ref="i3" />
                       <description>An old Fidonet node</description>
             </resourcedescriptor>
             <referral>
                 <serviceref ref="i0" /><datasetref ref="i2" />
             </referral>
        </results>



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


   </cnrp>

4.2.4 Status Messages

4.2.4.1 Status of CNRP, Not the Transport

   The status messages defined here are only applicable to operations
   defined by CNRP itself.  If some feature or operation is defined by
   the transport (security via HTTP, mail failure via SMTP, etc.), then
   any status messages about that operation MUST be sent in accordance
   with that transport's reporting mechanism and not via CNRP.

4.2.4.2 Codes and Description

   A Status object indicates a message to the client in the results set.
   The object encapsulates two values: a status code and a description.
   The description can contain a textual description of the status being
   communicated.  In many cases, additional diagnostic information can
   also be included.  No attempt is made to standardize the description
   of a given status code since the only programmatic element that
   matters is the actual code.

   A status message can also specify which other CNRP element it refers
   to by including a reference to the ID of the element in question.
   For example, if a Service block has an ID of "i2" and a status
   message refers to that block, then it can put that ID in its ref
   attribute.

            <status code="x.y.z" ref="i2">
                 The CNRP foo.com database is temporarily unreachable
            </status>

4.2.4.3 Status Codes

   The organization of status codes is taken from RFC 1893 [10] which
   structures its codes in the form of x.yyy.zzz.  Taken from RFC 1893
   is the ABNF for the codes:

             status-code = class "." subject "." detail
             class = "2"/"3"/"4"/"5"
             subject = 1*3digit
             detail = 1*3digit









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


   The top level codes denote levels of severity of the status:

   o  1.X.X Informational

      *  The information conveyed by the code has no bearing or
         indication of the success or failure of any request.  It is
         strictly for informational purposes only.

   o  2.X.X Success

      *  The request was processed and results were returned.  In most
         cases, this status class won't be sent since actual results
         themselves denote success.  In other cases, results were
         returned but some information needs to be returned to the
         client.

   o  3.X.X Partial Success

      *  The request was processed and results were returned.  In this
         case though, some values sent with the request were either
         invalid or ignored but in a way that the server still considers
         the response to be a successful one and not indicative of any
         true error condition.

   o  4.X.X Transient Failure

      *  The request was valid as sent, but some temporary event
         prevents the successful completion of the request and/or
         sending of the results.  Sending in the future may be possible.

   o  5.X.X Permanent Failure

      *  A permanent failure is one which is not likely to be resolved
         by re-sending the request in its current form.  Some change to
         the request or the destination must be made for successful
         request.

   The second level codes denote the subject of the status messages.
   This value applies to each of the five classifications.  The subject
   sub-code, if recognized, must be reported even if the additional
   detail provided by the detail sub-code is not recognized.  The
   enumerated values for the subject sub-code are:









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


   o  X.0.X Other or Undefined Status


      *  No specific information is available about what subject class
         this message belongs to.

   o  X.1.X Query Related

      *  Any status related to some specific way in which the query was
         encoded or its values with the exception of properties.

   o  X.2.X Service Related

      *  Any status related to the service in which this server is
         cooperating in providing.

   Appendix B contains a list of all predefined status codes

4.2.5 Referral

   A Referral object in the results set is a place holder for un-fetched
   results from a different service and possibly dataset.  Referrals
   typically occur when a CNRP server knows of another service capable
   of providing relevant results for the query and wants to notify the
   client about this possibility.  The client can decide whether it
   wants to follow the referral and resolve the extra results by
   contacting the referred-to service using the information contained
   within the Referral object (a Service object and possible
   properties).  The Referral is a simple mechanism to enable
   hierarchical resolution as well as to join multiple resolution
   services together.




















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


   <results>
        <service id="i0">
             <serviceuri>http://cnrp.bar.com/</serviceuri>
             <dataset id="i1">
                <property name="dataseturi">
                  urn:oid:1.3.6.1.4.1.782.1
                </property>
             </dataset>
             <dataset id="i2">
                <property name="dataseturi">
                  urn:oid:1.3.6.1.4.1.782.2
                </property>
             </dataset>
        </service>
        <resourcedescriptor>
             <commonname>bmw</commonname>
             <id>foo.com:234364</id>
             <resourceuri>http://www.bmw.de/</resourceuri>
             <serviceref ref="i0" /><datasetref ref="i1" />
             <description>BMW Motorcycles, International</description>
             <property name="language" type="iso646">de-DE</property>
        </resourcedescriptor>
        <referral>
             <serviceref ref="i0" /><datasetref ref="i2" />
        </referral>
   </results>

   Like other CNRP objects, a referral can be further described using
   custom properties.  Like a resourcedescriptor, a referral can have an
   ID attribute that is used by a status message to talk about a
   particular referral block.

4.2.5.1 Loop Detection and Dataset Handling in Servers

   Referrals in CNRP can be handled in three ways:

   o  application specific,

   o  as hints only,

   o  rigorous loop detection.

   In the first two cases, the behavior of the client, when it receives
   a referral, is not defined in this memo.  The client can chase the
   referral in such a way as to treat it as a hint only.  In this case,
   datasets may or may not be handled.  Loop detection can be nothing
   more than, "Have I talked to this hostname before?" or "Stop after
   the 3rd referral".  These two cases are most likely to apply to



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


   simple or constrained implementations where the clients and servers
   have some a priori knowledge of their capabilities.  Without such
   knowledge there is too much ambiguity vis-a-vis services and datasets
   for clients to do reliable loop detection.

   The last case is where the client expects to talk to multiple servers
   that may know nothing about each other.  This case expresses the
   basic semantics of what a server should tell a client if it
   understands datasets or referrals.  Since a referral specifies the
   exact dataset to which it is referring, a node in the list of visited
   nodes is made up of a serviceuri and a dataseturi.  Both of these
   values need to be considered during loop detection.  In the case
   where a service does not support datasets, the visited node is made
   up of the service and the 'default dataset'.

   The major thing to remember when doing loop detection across servers
   is that some servers may not understand datasets at all, while others
   specifically rely on them.  To help determine how loop detection
   nodes should be marked, three specific status messages have been
   defined:

   The 3.1.3 (Datasets not supported) status message is used to denote
   that the server does not support datasets at all.  It is sent in
   response to a query containing datasets.  The client should consider
   that the server ignored the datasets and the client should consider
   this node to have been visited for all possible datasets (including
   the 'default' dataset).

   The 3.1.4 (First dataset only supported) status message is used by a
   server to indicate the situation where a client has included several
   dataseturis in its query and the server can only support one at a
   time.  In this case, the server is explicitly stating that it used
   the first dataseturi only.  The client should consider that only the
   first dataseturi specified was processed correctly.  The client
   should consider that the remaining datasets in the query were ignored
   completely.  They would need to be sent individually as referrals if
   the client really cares about those results.  Only the first
   serviceuri/dataseturi pair should be marked as visited.

   The 3.1.5 (This dataset not supported) status message is used to
   indicate that a specific dataseturi sent in a query by a client is
   not supported by the server.  This serviceuri/dataseturi pair should
   be considered as visited by the client.  If this message is sent in
   reply to a query specifying multiple datasets, the client should
   behave the same as if it received the 3.1.3 message from above.  It
   should be considered bad form for a server to send this status
   message back in response to a query with multiple datasets because it
   is ambiguous.



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