rfc2654.txt
来自「RFC 的详细文档！」· 文本 代码 · 共 1,348 行 · 第 1/4 页
TXT
1,348 行
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: supplier@sup.com Date: Thu, 16 Jan 1997 13:50:37 -0500
Message-Id: <199701161850.NAA29295@sup.com>;
To: consumer@consumer.com <<-- from consumer server address
Reply-to: supplier-admin@sup.com
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]
⌨️ 快捷键说明
复制代码Ctrl + C
搜索代码Ctrl + F
全屏模式F11
增大字号Ctrl + =
减小字号Ctrl + -
显示快捷键?