rfc2654.txt

来自「著名的RFC文档,其中有一些文档是已经翻译成中文的的.」· 文本 代码 · 共 1,348 行 · 第 1/4 页

Hedberg, et al.               Experimental                      [Page 6]

RFC 2654           Tagged Index Object for use in CIP        August 1999


            "unique" - every object in the Dataset has to have a unique
            value for a specific attribute in the index. A example of
            such a attribute could be the distinguishedName attribute.
            This method is also optional.

   -    "securityoption": Whether and how the supplier server should
        sign and encrypt the update before sending it to the consumer
        server.  Options for this version of the specification are:

            "none" - the update is sent in plaintext

            "PGP/MIME": the update is digitally signed and encrypted
            using PGP [9]

            "S/MIME": the update is digitally signed and encrypted using
            S/MIME [10]

            "SSLv3": the update is digitally signed and encrypted using
            an SSLv3 connection [11]

            "Fortezza": the update is digitally signed and encrypted
            using Fortezza [5]

   It is recommended that the "PGP/MIME" option be used when exchanging
   sensitive information across public networks, and both the supplier
   and consumer have PGP keys. The "Fortezza" option is intended for use
   in environments where security protocols are based on Fortezza-
   compatible devices. The "S/MIME" option can be used with both the
   supplier and consumer have RSA keys and can make use of the PKCS
   protocols defined in the S/MIME specification. The "SSLv3" option can
   be used when both the supplier and consumer have access to SSL
   services, have server certificates, and can mutually authenticate
   each other.

   -    Security Credentials: The long-term cryptographic credentials
        used for key exchange and authentication of the consumer and
        supplier servers, if a security option was selected.  For
        "PGP/MIME," this will be the trusted public keys of both
        servers.  For "Fortezza," this will be the certificate paths of
        both servers to a common point of trust. For "S/MIME" and
        "SSLv3" these will be the certificates of the supplier and
        consumer.









Hedberg, et al.               Experimental                      [Page 7]

RFC 2654           Tagged Index Object for use in CIP        August 1999


        Note that if the index server maintains the information that
        would appear in the agreement in a directory according to the
        definitions in [7], then no real formal agreement between the
        two parties needs to be put in place, and the information that
        is required for communication between the two index servers is
        derived automatically from the directory.

4.2. Content Type

   The update consists of a MIME object of type application/cip-index-
   object.  The parameters are:

      "type": this has value "application/index.obj.tagged".

      "dsi": the DSI (if any) from the agreement.

      "base-uri". A set of URIs, separated by spaces. In each URI, the
      hostname/portno must be distinct, and based on the "supplier" part
      of the agreement.

   The payload is mostly textual data but may include bytes with the
   high bit set.  The originating information server should set the
   content-transfer-encoding as appropriate for the information included
   in the payload.

   This object may be encapsulated in a wrapper content (such as
   multipart/signed) or be encrypted as part of the security procedures.
   The resulting content can the distributed, for example via electronic
   mail.  For example,


   From: [e-mail] Date: Thu, 16 Jan 1997 13:50:37 -0500
   Message-Id: <[e-mail]>;
   To: [e-mail]       <<-- from consumer server address

   Reply-to: [e-mail]
   MIME-Version: 1.0
   Content-Type: application/index.obj.tagged;
   dsi=1.3.6.1.4.1.1466.85.85.1.2.3.4.5.6.7.8.9.10.11.12.13.14.15.16;
   base-uri="ldap://sup.com/dc=sup,dc=com ldap://alt.com/dc=sup,dc=com"


   The payload is series of CRLF-terminated lines. The payload is UTF-8.
   Some supplier servers may only be able to generate the printable US-
   ASCII subset of UTF-8, but all consumer servers must be able to
   handle the full range of Unicode characters when decoding the
   attribute values (in the "attr-value" field in the BNF below).




Hedberg, et al.               Experimental                      [Page 8]

RFC 2654           Tagged Index Object for use in CIP        August 1999


4.3.  Tagged Index BNF

   The Tagged Index object has the following grammar, expressed in
   modified BNF format:

   index-object = 0*(io-part SEP) io-part
   io-part      = header SEP schema-spec SEP index-info
   header       = version-spec SEP update-type SEP this-update SEP
                   last-update context-size name-space SEP
   version-spec = "version:" *SPACE "x-tagged-index-1"
   update-type  = "updatetype:" *SPACE ( "total" |
                  ( "incremental" [*SPACE "tagbased"|"uniqueIDbased" ] )
   this-update  = "thisupdate:" *SPACE TIMESTAMP
   last-update  = [ "lastupdate:" *SPACE TIMESTAMP SEP]
   context-size = [ "contextsize:" *SPACE 1*DIGIT SEP]
   schema-spec  = "BEGIN IO-Schema" SEP 1*(schema-line SEP)
                  "END IO-Schema"
   schema-line  = attribute-name ":" token-type
   token-type   = "FULL" | "TOKEN" | "RFC822" | "UUCP" | "DNS"
   index-info   = full-index | incremental-index
   full-index   = "BEGIN Index-Info" SEP 1*(index-block SEP)
                  "END Index-Info"
   incremental-index = 1*(add-block | delete-block | update-block)
   add-block    = "BEGIN Add Block" SEP 1*(index-block SEP)
                  "END Add Block"
   delete-block = "BEGIN Delete Block" SEP 1*(index-block SEP)
                  "END Delete Block"
   update-block = "BEGIN Update Block" SEP
                  0*(old-index-block SEP)
                  1*(new-index-block SEP)
                  "END Update Block"
   old-index-block = "BEGIN Old" SEP 1*(index-block SEP)
                  "END Old"
   new-index-block = "BEGIN New" SEP 1*(index-block SEP)
                  "END New"
   index-block  = first-line 0*(SEP cont-line)
   first-line   = attr-name ":" *SPACE taglist "/" attr-value
   cont-line    = "-" taglist "/" attr-value
   taglist      = tag 0*("," tag) | "*"
   tag          = 1*DIGIT ["-" 1*DIGIT]
   attr-value   = 1*(UTF8)
   attr-name    = 1*(NAMECHAR)
   TIMESTAMP    = 1*DIGIT
   NAMECHAR     = DIGIT | UPPER | LOWER | "-" | ";" | "."
   SPACE        = <ASCII space, %x20>;
   SEP          = (CR LF) | LF
   CR           = <ASCII CR, carriage return, %x0D>;
   LF           = <ASCII LF, line feed, %x0A>;



Hedberg, et al.               Experimental                      [Page 9]

RFC 2654           Tagged Index Object for use in CIP        August 1999


   DIGIT        = "0" | "1" | "2" | "3" | "4" | "5" | "6" | "7" |
                  "8" | "9"

   UPPER        = "A" | "B" | "C" | "D" | "E" | "F" | "G" | "H" |
                  "I" | "J" | "K" | "L" | "M" | "N" | "O" | "P" |
                  "Q" | "R" | "S" | "T" | "U" | "V" | "W" | "X" |
                  "Y" | "Z"
   LOWER        = "a" | "b" | "c" | "d" | "e" | "f" | "g" | "h" |
                  "i" | "j" | "k" | "l" | "m" | "n" | "o" | "p" |
                  "q" | "r" | "s" | "t" | "u" | "v" | "w" | "x" |
                  "y" | "z"

   US-ASCII-SAFE  = %x01-09 / %x0B-0C / %x0E-7F
                   ;; US-ASCII except CR, LF, NUL
   UTF8           = US-ASCII-SAFE / UTF8-1 / UTF8-2 / UTF8-3
                             / UTF8-4 / UTF8-5
   UTF8-CONT      = %x80-BF
   UTF8-1         = %xC0-DF UTF8-CONT
   UTF8-2         = %xE0-EF 2UTF8-CONT
   UTF8-3         = %xF0-F7 3UTF8-CONT
   UTF8-4         = %xF8-FB 4UTF8-CONT
   UTF8-5         = %xFC-FD 5UTF8-CONT

   The set of characters allowed to appear in the attr-name field is
   limited to the set of characters used in LDAP and WHOIS++ attribute
   names.  For other services that have attribute name character sets
   that are larger than these, those services should create a profile
   that maps the names onto object identifiers, and the sequence of
   digits and periods is used by those services in creating the attr-
   name fields for their Tagged Index Objects.

   It is worth mentioning that updates to a index based in tagged index
   objects MUST be performed in the order specified by the tagged index
   object itself.

4.3.1.  Header Descriptions

   The header section consists of one or more "header lines".  The
   following header lines are defined:

      "version": This line must always be present, and have the value
      "x-tagged-index-1" for this version of the specification.

      "updatetype": This line must always be present.  It takes as the
      value either "total" or "incremental".  The first update sent by a
      supplier server to a consumer server for a DSI must be a "total"
      update.




Hedberg, et al.               Experimental                     [Page 10]

RFC 2654           Tagged Index Object for use in CIP        August 1999


      "thisupdate": This line must always be present. The value is the
      number of seconds from 00:00:00 UTC January 1, 1970 at which the
      supplier constructed this update.

      "lastupdate": This line must be present if the "updatetype" list
      has the value "incremental".  The value is the number of seconds
      from 00:00:00 UTC January 1, 1970 at which the supplier
      constructed the previous update sent to the consumer.  This field
      allows the consumer to determine if a previous update was missed

      "contextsize": This line may be present at the supplier's option.
      The value is a number, which is the approximate total number of
      entries in the subtree.  This information is provided for
      statistical purposes only.

4.3.2.  Tokenization Types

   The Tagged Index Object inherits the "TOKEN" scheme for tokenization
   as specified in [2].  In addition, there are several other
   tokenization schemes defined for the Tagged Index Object.
    The following table presents these schemes and what character(s) are
   used to delimit tokens.

        Token Type      Tokenization Characters
        FULL    none
        TOKEN   white space, "@"
        RFC822  white space, ".", "@"
        UUCP    white space, "!"
        DNS     any character note a number, letter, or "-"

4.3.3.  Tag Conventions

   In the tag list, multiple consecutive tags may be shortened by using
   "#-#".  For example, the list "3,4,5,6,7,8,9,10" may be shortened to
   "3-10".  Tags are to be applied to the data on a per entry level.
   Thus, if two index lines in the same index object contain the same
   tag, then those two lines always refer to the same "record" in the
   directory.  In LDAP terminology, the two lines would refer to the
   same directory object.  Additionally if two index lines in the same
   index object contain different tags, then it is always the case that
   those two lines refer back to different records in the directory. The
   meaning of '*' in the tag position is that that specific token apears
   in every record in the directory.

   The tag applied to the same underlying record in two separate
   transmissions of a full-index may be different.  Thus, receiving
   index servers should make no assumptions about the values of the tags
   across index object boundaries.



Hedberg, et al.               Experimental                     [Page 11]

RFC 2654           Tagged Index Object for use in CIP        August 1999


4.4. Incremental Indexing

   The tagged index object format supports the ability of information
   servers to distribute only delta index data, rather than distributing
   total index information each time.  This scenario, known as
   incremental indexing supports three basic types of operations: add,
   delete and replace.  If the incremental updatetype is specified in
   the tagged index object, then the index object contains a snapshot of
   only the changes that have been made since the index object specified
   in the lastupdate header was distributed.  If the receiving index
   server did not receive that index object, it should request a total
   index object.  If the CIP protocol supports it, the index server may
   request the specific index object that it missed.

   If the tagged index object contains an Add Block, then the lines in
   the Add Block refer to new records that were added to the information
   base of the transmitting index server.  It can be guaranteed that
   those records did not exist in any previously received tagged index
   object, and the receiving index server can insert this index
   information in the index that it already maintains for the
   transmitting index server.

   If the tagged index object contains a Delete Block, then the
   structure of the Delete Block depends on how the consistency is
   maintained;

   -  "completeRecord": all the tokens connected to the record to be
      deleted has to be included, the tag used to connect tokens in this
      message has no relation to tags used in previously sent tagged
      index objects.

   -  "uniqueIDBased": only the unique identifier has to be defined.

   -  "tagBased": all the tokens connected to the record has to be
      included but then preceded by the tag used for this specific
      record in the preceding set of the last full update and the there
      on following incremental updates.

   If the tagged index object contains an Update Block, then the lines
   in the Update Block refer to records that were changed in the
   information base of the transmitting index server. Again the specific
   content of the block depends on how the consistency is maintained.

   -  "completeRecord": All the tokens representing the old version of
      the record as well as the new ones has to be included.

   -  "uniqueIDBased": The unique ID has to be included together with
      the tokens that have changed.



Hedberg, et al.               Experimental                     [Page 12]