Remove LDUP drafts until someone steps to the plate

This commit is contained in:
Kurt Zeilenga 2001-06-08 01:40:35 +00:00
parent 3db30340b7
commit 35efcbcd22
7 changed files with 0 additions and 7672 deletions

View File

@ -1,340 +0,0 @@
Extended Operations for Framing LDAP Operations
Internet-Draft
Intended Category: Standards Track
Expires: September 10, 2000
Ellen Stokes
IBM Corporation
Roger Harrison
Novell, Inc.
Gordon Good
Netscape Communications Corp.
March 10, 2000
Extended Operations for Framing LDAP Operations
Filename: draft-ietf-ldup-framing-00.txt
Table of Contents
1. Status of this Memo.............................................2
2. Abstract........................................................2
3. Overview........................................................2
4. Protocol element definitions....................................3
4.1 StartFramedProtocolRequest Extended Operation...................3
4.2 StartFramedProtocolResponse Extended Operation..................3
4.3 EndFramedProtocolRequest Extended Operation.....................4
4.4 EndFramedProtocolResponse Extended Operation....................4
5. Acknowledgments.................................................5
6. References......................................................5
7. Author's Addresses..............................................5
Stokes, Harrison and Good [Page 1]
Internet-Draft LDUP Workgroup March 10, 2000
1. Status of this Memo
This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that other
groups may also distribute working documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet- Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
.
This Internet Draft expires September 10, 2000.
2. Abstract
Certain types of LDAP applications can benefit from the ability to
specify the beginning and end of a related group of operations. For
example, the LDUP multimaster update protocol [ARCHITECTURE] requires
that two servers agree to begin a session to transfer pending
replication updates. This document provides a framework for
constructing protocols that feature a framed set of related
operations. It defines a pair of LDAPv3 extended operations that
provide begin-end framing, and a pair of extended operations used to
respond the begin-end framing operations. The nature of the actual
LDAP operations carried inside these framing operations is not
specified in this document.
All protocol elements described here are LDAP Version 3 extended
operations. LDAP Version 3 is described in RFC 2251 [LDAPv3].
Certain terms used in this document are defined in the document "LDAP
Replication Architecture" [ARCHITECTURE].
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", and "MAY" in this document are
to be interpreted as described in RFC 2119 [KEYWORDS].
3. Overview
This document describes two LDAPv3 Extended Operations that are used
to signal the beginning and end of a set of grouped operations, and
Stokes, Harrison and Good [Page 2]
Internet-Draft LDUP Workgroup March 10, 2000
two LDAPv3 extended operations that are used to respond to these
operations. These extended operations provide a framework that may be
used when developing a protocol that requires begin-end framing.
4. Protocol element definitions
4.1 StartFramedProtocolRequest Extended Operation
The StartFramedProtocolRequest extended operation indicates that the
initiator wishes to begin transmission of a set of related LDAP
operations. The requestValue of the StartFramedProtocolRequest
extended operation contains an OID that describes the specific framed
protocol being initiated, and a protocol-specific payload.
An LDAPv3 Extended Request is defined in [LDAPv3] as follows:
ExtendedRequest ::= [APPLICATION 23] SEQUENCE {
requestName [0] LDAPOID,
requestValue [1] OCTET STRING OPTIONAL
}
The requestName portion of the StartFramedProtocolRequest must be the
OID "2.16.840.1.113719.1.142.100.1".
The requestValue of the StartFramedProtocolRequest must be set to the
BER-encoding of the following:
StartFramedProtocolRequestValue ::= SEQUENCE {
framedProtocolOID LDAPOID,
framedProtocolPayload OPTIONAL OCTET STRING
}
The parameters in the requestValue of the StartFramedProtocolRequest
are:
- framedProtocolOID: An OID that uniquely identifies the protocol
framed by this operation. - framedProtocolPayload: An octet
string that contains protocol-specific
information.
4.2 StartFramedProtocolResponse Extended Operation
The StartFramedProtocolResponse extended operation is sent in
response to a StartFramedProtocolResponse extended operation.
An LDAPv3 Extended Response is defined in [LDAPv3] as follows:
Stokes, Harrison and Good [Page 3]
Internet-Draft LDUP Workgroup March 10, 2000
ExtendedResponse ::= [APPLICATION 24] SEQUENCE {
COMPONENTS of LDAPResult,
responseName [10] LDAPOID OPTIONAL,
response [11] OCTET STRING OPTIONAL
}
The responseName of the StartFramedProtocolResponse must be the OID
"2.16.840.1.113719.1.142.100.2".
The response of the StartFramedProtocolResponse is set to the BER-
encoding of a protocol-specific response.
4.3 EndFramedProtocolRequest Extended Operation
The EndFramedProtocolRequest extended operation indicates the end a
set of related LDAP operations. The requestValue of the
EndFramedProtocolRequest extended operation contains a protocol-
specific payload.
An LDAPv3 Extended Request is defined in [LDAPv3] as follows:
ExtendedRequest ::= [APPLICATION 23] SEQUENCE {
requestName [0] LDAPOID,
requestValue [1] OCTET STRING OPTIONAL
}
The requestName of the EndFramedProtocolRequest must be the OID
"2.16.840.1.113719.1.142.100.4".
The requestValue of the EndFramedProtocolRequest is set to the BER-
encoding of a protocol-specific response.
4.4 EndFramedProtocolResponse Extended Operation
The EndFramedProtocolResponse extended operation is sent in response
to an EndFramedProtocolRequest.
An LDAPv3 Extended Response is defined in [LDAPv3] as follows:
ExtendedResponse ::= [APPLICATION 24] SEQUENCE {
COMPONENTS of LDAPResult,
responseName [10] LDAPOID OPTIONAL,
response [11] OCTET STRING OPTIONAL
}
The responseName of the EndFramedProtocolResponse must be the OID
"2.16.840.1.113719.1.142.100.5".
Stokes, Harrison and Good [Page 4]
Internet-Draft LDUP Workgroup March 10, 2000
The response of the EndFramedProtocolResponse is set to the BER-
encoding of a protocol-specific response.
5. Acknowledgments
The authors gratefully acknowledge the contributions of the IETF LDUP
working group.
6. References
[KEYWORDS]
S. Bradner, "Key Words for use in RFCs to Indicate Requirement Lev-
els", Harvard University, RFC 2119, March 1997.
[ARCHITECTURE]
J. Merrells, E. Reed, U. Srinivasan, "LDAP Replication Architec-
ture", Internet-Draft, draft-ietf-ldup-model-02.txt, October 1999.
[LDAPv3]
M. Wahl, S. Kille, T. Howes, "Lightweight Directory Access Protocol
(v3)", RFC 2251, December 1997.
7. Author's Addresses
Ellen Stokes
IBM
11400 Burnet Rd
Austin, TX 78758
USA
EMail: stokes@austin.ibm.com
phone: +1 512 838 3725
fax: +1 512 838 0156
Roger Harrison
Novell, Inc.
122 E. 1700 S.
Provo, UT 84606
USA
EMail: roger_harrison@novell.com
Phone: +1 801 861 2642
Gordon Good
Netscape Communications Corp.
501 E. Middlefield Rd.
Mailstop MV068
Stokes, Harrison and Good [Page 5]
Internet-Draft LDUP Workgroup March 10, 2000
Mountain View, CA 94043
USA
EMail: ggood@netscape.com
Phone: +1 650 937-3825
Appendix A - Complete ASN.1 Definition
StartFramedProtocolRequest ::= ExtendedRequest
StartFramedProtocolRequestValue ::= SEQUENCE {
framedProtocolOID LDAPOID,
framedProtocolPayload OPTIONAL OCTET STRING
}
StartFramedProtocolResponse ::= ExtendedResponse
EndFramedProtocolRequest ::= ExtendedRequest
EndFramedProtocolResponse ::= ExtendedResponse
Full Copyright Statement
Copyright (C) The Internet Society (1999). All Rights Reserved.
This document and translations of it may be copied and furnished to oth-
ers, and derivative works that comment on or otherwise explain it or
assist in its implementation may be prepared, copied, published and dis-
tributed, in whole or in part, without restriction of any kind, provided
that the above copyright notice and this paragraph are included on all
such copies and derivative works. However, this document itself may not
be modified in any way, such as by removing the copyright notice or
references to the Internet Society or other Internet organizations,
except as needed for the purpose of developing Internet standards in
which case the procedures for copyrights defined in the Internet Stan-
dards process must be followed, or as required to translate it into
languages other than English.
The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns.
This document and the information contained herein is provided on an "AS
IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK
FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT
LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT
INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FIT-
NESS FOR A PARTICULAR PURPOSE.
Stokes, Harrison and Good [Page 6]

File diff suppressed because it is too large Load Diff

File diff suppressed because it is too large Load Diff

View File

@ -1,895 +0,0 @@
LDUP Replication Update Protocol
Internet-Draft
Intended Category: Standards Track
Expires: September 10, 2000
Ellen Stokes
IBM Corporation
Gordon Good
Netscape Communications Corp.
March 10 2000
The LDUP Replication Update Protocol
Filename: draft-ietf-ldup-protocol-01.txt
Table of Contents
1. Status of this Memo.............................................2
2. Abstract........................................................2
3. Overview of Protocol............................................2
4. High-level Description of Protocol Flow.........................3
4.1 Supplier-initiated incremental replication protocol.............3
4.2. Consumer-initiated replication protocol......................4
5. Replication protocol element definitions........................5
5.1 StartFramedProtocolRequest Extended Operation...................5
5.2 StartFramedProtocolResponse Extended Operation..................6
5.3 ReplicationUpdate Extended Operation............................7
5.3.1 UniqueIdentifier.............................................8
5.3.2 ReplicationPrimitive.........................................8
5.3.2.1 AddEntryPrimitive.........................................8
5.3.2.2 MoveEntryPrimitive........................................9
5.3.2.3 RenameEntryPrimitive......................................9
5.3.2.4 RemoveEntryPrimitive......................................9
5.3.2.5 AddAttributeValuePrimitive................................10
5.3.2.6 RemoveAttributeValuePrimitive.............................10
5.3.2.7 RemoveAttributePrimitive..................................10
5.4 EndFramedProtocolRequest Extended Operation.....................11
5.5 EndFramedProtocolResponse Extended Operation....................11
5.6 ReplicationUpdateResponse Extended Operation....................12
6. Semantics of Full and Incremental Update protocols..............13
7. Summary of response codes.......................................13
8. Implications for log-based and state-based servers..............13
9. Replication of access control and schema information............13
10. Security Considerations.........................................14
11. Glossary of Terms...............................................14
12. Acknowledgments.................................................14
13. References......................................................14
14. Author's Addresses..............................................15
Stokes and Good [Page 1]
Internet-Draft LDUP Workgroup March 10 2000
1. Status of this Memo
This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that other
groups may also distribute working documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet- Drafts as reference
material or to cite them other than as "work in progress."
To view the list Internet-Draft Shadow Directories, see
http://www.ietf.org/shadow.html.
This Internet Draft expires September 10, 2000.
2. Abstract
The protocol described in this document is designed to allow one LDAP
server to replicate its directory content to another LDAP server. The
protocol is designed to be used in a replication configuration where
multiple updatable servers are present. Provisions are made in the
protocol to carry information that allows the server receiving
updates to apply a total ordering to all updates in the replicated
system. This total ordering allows all replicas to correctly resolve
conflicts that arise when LDAP clients submit changes to different
servers that later replicate to one another.
All protocol elements described here are LDAP Version 3 extended
operations. LDAP Version 3 is described in RFC 2251 [LDAPv3].
Certain terms used in this document are defined in the document "LDAP
Replication Architecture" (draft-ietf-ldup-model-00.txt).
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", and "MAY" in this document are
to be interpreted as described in RFC 2119 [KEYWORDS].
3. Overview of Protocol
The LDAP Replication Architecture [ARCHITECTURE] describes the
overall approach used in ensuring consistency of multiple updatable
replicas of directory content. The protocol described in this
document implements the approach desribed in that document.
Stokes and Good [Page 2]
Internet-Draft LDUP Workgroup March 10 2000
LDAP Version 3 extended operations are used to carry replicated
content from one server to another. The extended operations defined
in this document are used to initiate and end a replication session,
and to exchange updates. These updates carry with them information
that allows the receiving server to apply a total ordering to all of
the updates in a replicated system. All servers that receive
replication updates apply a consistent set of update resolution
policies, described in [URP]. Consistent application of the update
resolution policies ensures that all replicas eventually converge and
contain the same directory data.
This protocol is based upon the extended operations defined in
[FRAMING].
This protocol is intended to meet the requirements set forth in
[REQ].
4. High-level Description of Protocol Flow
The following section provides a high-level overview of the
replication protocol. Throughout this section, the supplier server is
indicated by the letter "S" and the consumer server by the letter
"C". The construct "S -> C" indicates that the supplier is sending an
LDAPv3 extended operation to the consumer, and "C -> S" indicates
that the consumer is sending an LDAPv3 extended operation to the
supplier.
4.1 Supplier-initiated incremental replication protocol
S -> C: LDAP bind operation (identity and credentials
used are implementation-defined)
C -> S: Bind response
S -> C: StartFramedProtocolRequest LDAPv3 extended
operation. The parameters are:
1) The OID for the LDUP incremental replication protocol or the
LDUP total update protocol, depending on whether an incremental
or complete refresh of the replica is to be performed.
2) A protocol-specific payload containing:
a) The root of replicated area (unambiguously
identifies the replicated area)
b) The supplier's replicaID
c) The protocol initiation type - Supplier-Initiated
in this case.
C -> S: StartFramedProtocolResponse LDAPv3 extended operation. The
Stokes and Good [Page 3]
Internet-Draft LDUP Workgroup March 10 2000
parameters are:
1) A protocol-specific payload containing:
a) A response code (see section 7)
b) An optional update vector that is included
if and only if the response code is REPL_SUCCESS.
S -> C: The supplier may send zero or more ReplicationUpdate LDAPv3
extended operations. The parameters are:
1) The UUID of the entry being updated
2) One or more Replication Primitives (The supplier
may send as many of these as required to bring
the consumer up to date)
C -> S: At any time, the consumer may send an unsolicited
ReplicationUpdateResponse LDAPv3 extended operation. The
parameters are:
1) An optional update vector. If sent, this indicates that
the consumer has committed all updates whose CSNs are
covered by the transmitted update vector [see glossary
for a definition of "covered by"].
2) An optional AbortUpdate boolean flag. If a supplier
receives a ReplicationUpdateResponse from a consumer with
the AbortUpdate flag set to true, the supplier server MUST
immediately cease sending updates and terminate its
connection to the consumer.
S -> C: After all required updates have been sent to the consumer, the
supplier sends an EndFramedProtocolRequest LDAPv3 extended
operation.
C -> S: The consumer responds by sending an EndFramedProtocolResponse
LDAPv3 extended operation, and then closes the connection.
4.2. Consumer-initiated replication protocol
C -> S: LDAP bind operation (identity and credentials
used are implementation-defined)
S -> C: Bind response
C -> S: StartFramedProtocolRequest LDAPv3 extended
operation. The parameters are:
1) The OID for the LDUP incremental replication protocol or the
LDUP total update protocol, depending on whether an incremental
Stokes and Good [Page 4]
Internet-Draft LDUP Workgroup March 10 2000
or complete refresh of the replica is to be performed.
2) A protocol-specific payload containing:
a) The root of replicated area (unambiguously
identifies the replicated area)
b) The consumer's replicaID
c) The protocol initiation type - Consumer-Initiated
in this case.
S -> C: StartFramedProtocolResponse LDAPv3 extended operation. The
parameters are:
1) A protocol-specific payload containing:
a) A response code (see section 7)
S -> C: The supplier server disconnects from the consumer server,
and then connects to the consumer, beginning a Supplier-
Initiated protocol session (see section 4.1).
5. Replication protocol element definitions
5.1 StartFramedProtocolRequest Extended Operation
The StartFramedProtocolRequest extended operation is sent by a replication
initiator to a server to indicate that a replication session should
commence. For supplier-initiated replication, the supplier sends this
extended operation to the replication consumer to indicate that a
replication session should commence. For consumer-initiated
replication, the consumer sends this extended operation to the
replication supplier to indicate that the supplier should initiate a
replication session to the consumer as soon as possible.
The StartFramedProtocolRequest extended operation is defined
in [FRAMING]. When signaling the beginning of a replication
session, then requestValue of the StartFramedProtocolRequest
is set to the following:
requestValue ::= SEQUENCE {
framedProtocolOID LDAPOID,
framedProtocolPayload OPTIONAL OCTET STRING
}
The framedProtocolOID of the StartReplicationRequest must be the OID
for the LDUP incremental replication protocol,
2.16.840.1.113719.1.142.1.4.3, or the LDUP total update protocol,
2.16.840.1.113719.1.142.1.4.4. See section 7 for information on the
semantic behavior of these update protocols. Implementations MUST
support the two update protocols defined in this document.
Stokes and Good [Page 5]
Internet-Draft LDUP Workgroup March 10 2000
The framedProtocolPayload of the StartFramedProtocolRequestValue must
be set to the BER-encoding of the following:
framedProtocolPayload ::= SEQUENCE {
replicaRoot LDAPDN,
replicaID LDAPString,
replicationInitiator ENUMERATED {
supplier (0),
consumer (1)
}
}
The parameters in the framedProtocolPayload of the
StartFramedProtocolRequestValue are:
- replicaRoot: the distinguished name of the entry at the top of
the replicated area, and uniquely identifies the unit of
replication.
- replicaID: the replica identifier of the replication initiator.
Each replica of a given replicated area is identified by a unique
identifier, described in [ARCHITECTURE].
- replicationInitiator: used to differentiate between a supplier-
initiated session and a consumer-initiated session. If the
replicationInitiator contains the enumerated value <supplier>,
then the initiator is the supplier, and the receiver of this
operation should prepare to receive a set of replication updates
(or should reject the operation is replication updates are not
permitted for some reasonm, perhaps due to access control
restrictions). If the replicationInitiator contains the
enumerated value <consumer>, then the receiver should prepare to
establish a supplier-initiated replication session with the
consumer as soon as possible, updating the replicated are given by
replicaRoot and using the update protocol given by
replicationProtocolOID.
5.2 StartFramedProtocolResponse Extended Operation
The StartFramedProtocolResponse extended operation is sent in
response to a StartFramedProtocolRequest extended operation.
For a supplier-initiated session, the response field of the
StartFramedProtocolResponse extended response indicates that the
consumer is or is not prepared to accept a set of updates. If the
consumer is prepared to accept updates, it sends a response field
containing a success code and the consumer's replica update vector.
If the consumer is unwilling or unable to accept updates, it sends a
Stokes and Good [Page 6]
Internet-Draft LDUP Workgroup March 10 2000
response field containing an error code.
For a consumer-initiated session, the response field of the
StartFramedProtocolResponse extended respons indicates that the
supplier is or is not prepared to send a set of updates to the
consumer. If the supplier is prepared to send updates to the
consumer, it sends a response field containing a success code. If the
supplier is unwilling or unable to send updates to the consumer, it
sends a response field containing an error code. In both cases, the
supplier disconnects from the consumer. If the supplier sent a
success code to the consumer, it opens a connection to the consumer
as soon as possible and initiates a supplier-initiated replication
session.
The StartFramedProtocolResponse extended operation is defined in
[FRAMING]. When responding to a StartFramedProtocolRequest signaling
the beginning of an LDUP replication session, the response field of
the StartFramedProtocolResponse is set to the following:
StartFramedProtocolResponseValue ::= SEQUENCE {
responseCode LDUPResponseCode,
replicaUpdateVector Attribute,
}
LDUPResponseCodes are defined in section 8.
The replicaUpdateVector contains a replica update vector, as defined
in [INFOMOD]. The update vector is encoded as a normal LDAP
attribute, defined in [LDAPv3].
5.3 ReplicationUpdate Extended Operation
The ReplicationUpdate extended operation carries a set of replication
primitives that represent the desired final state of a single entry.
The ReplicationUpdate extended operation is defined as follows:
An LDAPv3 Extended Request is defined in [LDAPv3] as follows:
ExtendedRequest ::= [APPLICATION 23] SEQUENCE {
requestName [0] LDAPOID
requestValue [1] OCTET STRING OPTIONAL
}
The requestName of the ReplicationUpdate must be the OID
2.16.840.1.113719.1.142.100.3.
Stokes and Good [Page 7]
Internet-Draft LDUP Workgroup March 10 2000
The requestValue of the ReplicationUpdate must be set to the BER-
encoding of the following:
requestValue ::= SEQUENCE {
uniqueID UniqueIdentifier,
updates SET OF ReplicationPrimitive
}
5.3.1 UniqueIdentifier
The Distinguished Name of an entry may be changed (by renaming the
entry), or the entry may not have a distinguished name (if it was
deleted). The Unique Identifier provides an immutable name,
independent of the current name or deletion status, for an entry. All
replicated operations address entries by their Unique Identifiers.
UniqueIdentifier ::= LDAPString
5.3.2 ReplicationPrimitive
A ReplicationPrimitive carries a single assertion about the the final
state of an entry, attribute, or attribute value. There are seven
types of primitives.
ReplicationPrimitive ::= CHOICE {
addEntryPrimitive AddEntryPrimitive,
moveEntryPrimitive MoveEntryPrimitive,
renameEntryPrimitive RenameEntryPrimitive,
removeEntryPrimitive RemoveEntryPrimitive,
addAttributeValuePrimitive AddAttributeValuePrimitive,
removeAttributeValuePrimitive RemoveAttributeValuePrimitive,
removeAttributePrimitive RemoveAttributePrimitive
}
Each primitive applies to the entry referred to by the
uniqueIdentifier in the enclosing ReplicationUpdate extended
operation.
Each primitive carries an lLDAPChangeSequenceNumber that is used by
the consumer server to correctly resolve update conflicts. [URP]
describes the update reconciliation procedures.
5.3.2.1 AddEntryPrimitive
The AddEntryPrimitive is used to add a new entry.
AddEntryPrimitive ::= [APPLICATION 0] SEQUENCE {
Stokes and Good [Page 8]
Internet-Draft LDUP Workgroup March 10 2000
csn lDAPChangeSequenceNumber,
superior UniqueIdentifier,
rdn RelativeLDAPDN
}
Parameters of the AddEntryPrimitive are:
- csn: The change sequence number of the primitive.
- superior: The unique identifier of the superior (parent) entry.
- rdn: The relative distinguished name of the new entry.
5.3.2.2 MoveEntryPrimitive
The MoveEntryPrimitive is used to move an entry to a new location in
the DIT.
MoveEntryPrimitive ::= [APPLICATION 1] SEQUENCE {
csn lDAPChangeSequenceNumber,
superior UniqueIdentifier
}
Parameters of the MoveEntryPrimitive are:
- csn: The change sequence number of the primitive.
- superior: The unique identifier of the new superior (parent)
entry.
5.3.2.3 RenameEntryPrimitive
The RenameEntryPrimitive is used to change the RDN of an entry.
RenameEntryPrimitive ::= [APPLICATION 2] SEQUENCE {
csn lDAPChangeSequenceNumber,
rdn RelativeLDAPDN
}
Parameters of the RenameEntryPrimitive are:
- csn: The change sequence number of the primitive.
- rdn: The new relative distinguished name of the entry.
5.3.2.4 RemoveEntryPrimitive
The RemoveEntryPrimitive is used to delete an entry from the DIT.
Stokes and Good [Page 9]
Internet-Draft LDUP Workgroup March 10 2000
RemoveEntryPrimitive ::= [APPLICATION 3] SEQUENCE {
csn lDAPChangeSequenceNumber
}
Parameters of the RemoveEntryPrimitive are:
- csn: The change sequence number of the primitive.
5.3.2.5 AddAttributeValuePrimitive
The AddAttributeValuePrimitive is use to add a new attribute value to
an entry.
AddAttributeValuePrimitive ::= [APPLICATION 4] SEQUENCE {
csn lDAPChangeSequenceNumber,
type AttributeDescription,
value AttributeValue
}
Parameters of the AddAttributeValuePrimitive are:
- csn: The change sequence number of the primitive.
- type: The type of the attribute being added.
- value: The value being added. Multiple values are not permitted.
5.3.2.6 RemoveAttributeValuePrimitive
The RemoveAttributeValuePrimitive is used to remove a particular
attribute value from an entry.
RemoveAttributeValuePrimitive ::= [APPLICATION 5] SEQUENCE {
csn lDAPChangeSequenceNumber,
type AttributeDescription,
value AttributeValue
}
Parameters of the RemoveAttributeValuePrimitive are:
- csn: The change sequence number of the primitive.
- type: The type of the attribute being removed.
- value: The value being removed. Multiple values are not
permitted.
5.3.2.7 RemoveAttributePrimitive
Stokes and Good [Page 10]
Internet-Draft LDUP Workgroup March 10 2000
The RemoveAttributePrimitive is used to remove an attribute and all
its values from an entry.
RemoveAttributePrimitive ::= [APPLICATION 6] SEQUENCE {
csn lDAPChangeSequenceNumber,
type AttributeDescription
}
Parameters of the RemoveAttributePrimitive are:
- csn: The change sequence number of the primitive.
- type: The type of the attribute being removed.
5.4 EndFramedProtocolRequest Extended Operation
The EndFramedProtocolRequest extended operation is sent from the
replication supplier to the replication consumer to indicate the end
of the sequence of replication updates. In the event that the
supplier is sending a total update, the requestValue field of the
EndFramedProtocolRequest extended operation contains a replica update
vector. The consumer server must replace its replica update vector,
if present, with the one provided by the supplier. In the event that
the supplier is sending an incremental update, the replica update
vector is absent.
The EndFramedProtocolRequest extended operation is defined in
[FRAMING]. When used to signal the termination of an LDUP incremental
or total update session, the requestValue field of the
EndFramedProtocolRequest is set to the following:
requestValue ::= SEQUENCE {
replicaUpdateVector Attribute OPTIONAL,
returnConsumerUpdateVector BOOLEAN
}
If returnConsumerUpdateVector is TRUE, the consumer server must
return its current update vector to the supplier in the response
field of the EndFramedProtocolResponse extended response (defined in
section 5.5). Typically, the supplier will request the consumer's
update vector for read-only replicas, since the read-only replica
will never initiate a replication session, and will therefore never
have the opportunity to provide its update vector to other servers.
5.5 EndFramedProtocolResponse Extended Operation
Stokes and Good [Page 11]
Internet-Draft LDUP Workgroup March 10 2000
The EndFramedProtocolResponse extended operation is defined in
[FRAMING]. It is used to respond to a EndFramedProtocolRequest. The
response field of the EndFramedProtocolResponse extended operation is
set to the following:
response ::= SEQUENCE {
replicaUpdateVector Attribute OPTIONAL
}
The replicaUpdateVector contains the consumer's current replica
update vector, and is optional. The consumer server should only send
the replicaUpdateVector if requested by the supplier server in the
EndReplicationRequest extended operation.
5.6 ReplicationUpdateResponse Extended Operation
The ReplicationUpdateResponse extended operation is sent, unsolicited,
by a consumer to a supplier when the consumer wishes the supplier to
stop sending updates.
An LDAPv3 extended response is defined in [LDAPv3] as follows:
ExtendedResponse ::= [APPLICATION 24] SEQUENCE {
COMPONENTS of LDAPResult,
responseName [10] LDAPOID OPTIONAL,
response [11] OCTET STRING OPTIONAL
}
The responseName of the ReplicationUpdateResponse must be the OID [OID
to be assigned].
The response field of the ReplicationUpdateResponse must be set to the
BER-encoding of the following:
response ::= SEQUENCE {
replicaUpdateVector Attribute OPTIONAL
abortUpdate BOOLEAN
}
The parameters of the ReplicationUpdateResponse are:
- An optional update vector. If sent, this indicates that the consumer
has committed all updates whose CSNs are covered by the transmitted
update vector [see glossary for a definition of "covered by"]. - An
optional AbortUpdate boolean flag. If a supplier receives a
ReplicationUpdateResponse from a consumer with the AbortUpdate flag set
to true, the supplier server MUST immediately cease sending updates and
terminate its connection to the consumer.
Stokes and Good [Page 12]
Internet-Draft LDUP Workgroup March 10 2000
6. Semantics of Full and Incremental Update protocols
[To be written]
7. Summary of response codes
The following list describes the response codes that may be included in
the StartFramedProtocolResponse, EndFramedProtocolResponse, and
ReplicationUpdateResponse extended operations.
LDUPResponseCode ::= SEQUENCE {
resultCode ENUMERATED {
success (0),
operationsError (1),
protocolError (2),
insufficientAccessRights (50),
busy (51),
excessiveCSNSkew (200),
other (80) },
errorMessage LDAPString }
The meanings of the response codes are as follows:
success..................... As defined in [LDAPv3].
operationsError............. As defined in [LDAPv3].
protocolError............... As defined in [LDAPv3].
insufficientAccessRights.... Access denied. The identity that the
initiator provided in the bind request does
not have sufficient privileges to perform
the operation.
busy........................ The replica is temporarily unable to accept
updates.
excessiveCSNSkew............ The consumer server has detected that the
CSNs being generated by the supplier are
too small (perhaps because the supplier's
clock was set back). Updates from the
supplier will not be applied.
other....................... Some other error occurred.
8. Implications for log-based and state-based servers
To be written, or possibly incorporated into [ARCHITECTURE].
9. Replication of access control and schema information
To be written, or possibly incorporated into [ARCHITECTURE].
Stokes and Good [Page 13]
Internet-Draft LDUP Workgroup March 10 2000
10. Security Considerations
To be written.
11. Glossary of Terms
Covered by: We say that a CSN is "covered by" an update vector if and
only if the CSN is less than or equal to the component of the update
vector corresponding to the replica ID in the CSN. In other words,
given a CSN with components <t,S,r,s> and an update vector with CSNs
<t0,S0,r0,s0>,<t1,S1,r1,s1>...<tn,Sn,Rn,sn>, then the CSN is covered
by the RUV if and only if one of the following holds for some value
i:
a) r = ri and t < ti
b) r = ri and t = ti and S < Si
c) r = ri and t = ti and S = Si and s < si
12. Acknowledgments
To be written.
13. References
[ARCHITECTURE]
J. Merrells, E. Reed, U. Srinivasan, "LDAP Replication Architec-
ture", Internet-Draft, draft-ietf-ldup-model-02.txt, October 1999.
[FRAMING]
E. Stokes, G. Good, "Extended Operations for Framing LDAP Bulk
Update Operations", Internet-Draft, draft-ietf-ldup-framing-00.txt,
March 2000.
[INFOMOD]
E. Reed, "LDAP Replication Information Model", Internet-Draft,
draft-reed-ldup-infomod-00.txt, June 1999.
[KEYWORDS]
S. Bradner, "Key Words for use in RFCs to Indicate Requirement Lev-
els", Harvard University, RFC 2119, March 1997.
[LDAPv3]
M. Wahl, S. Kille, T. Howes, "Lightweight Directory Access Protocol
Stokes and Good [Page 14]
Internet-Draft LDUP Workgroup March 10 2000
(v3)", RFC 2251, December 1997.
[REQ]R. Weiser, E. Stokes, "LDAP V3 Replication Requirements",
Internet-Draft, draft-ietf-ldup-replica-req-02.txt, October 1999.
[URP]S. Legg, A. Payne, "LDUP Update Reconciliation Procedures",
Internet-Draft, draft-ietf-ldup-urp-02.txt, October 1999.
14. Author's Addresses
Ellen Stokes
IBM
11400 Burnet Rd
Austin, TX 78758
USA
EMail: stokes@austin.ibm.com
phone: +1 512 838 3725
fax: +1 512 838 0156
Gordon Good
Netscape Communications Corp.
501 E. Middlefield Rd.
Mailstop MV068
Mountain View, CA 94043
USA
EMail: ggood@netscape.com
Phone: +1 650 937-3825
15. Document Revision History
(This section will be removed prior to this document's publication
as a proposed standard)
Differences between draft-ietf-ldup-protocol-00.txt and
draft-ietf-ldup-protocol-01.txt:
1) The document was reworked to use the ldup framed protocol
draft [FRAMING].
Appendix A - Complete ASN.1 Definition
To be written.
Full Copyright Statement
Copyright (C) The Internet Society (1999). All Rights Reserved.
Stokes and Good [Page 15]
Internet-Draft LDUP Workgroup March 10 2000
This document and translations of it may be copied and furnished to oth-
ers, and derivative works that comment on or otherwise explain it or
assist in its implementation may be prepared, copied, published and dis-
tributed, in whole or in part, without restriction of any kind, provided
that the above copyright notice and this paragraph are included on all
such copies and derivative works. However, this document itself may not
be modified in any way, such as by removing the copyright notice or
references to the Internet Society or other Internet organizations,
except as needed for the purpose of developing Internet standards in
which case the procedures for copyrights defined in the Internet Stan-
dards process must be followed, or as required to translate it into
languages other than English.
The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns.
This document and the information contained herein is provided on an "AS
IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK
FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT
LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT
INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FIT-
NESS FOR A PARTICULAR PURPOSE.
Stokes and Good [Page 16]

File diff suppressed because it is too large Load Diff

View File

@ -1,286 +0,0 @@
INTERNET-DRAFT
draft-ietf-ldup-subentry-03.txt
Ed Reed
Reed-Matthews, Inc.
July 13, 2000
LDAP Subentry Schema
1. Status of this Memo
This document is an Internet-Draft and is in full
conformance with all provisions of Section 10 of RFC2026.
Internet-Drafts are working documents of the Internet
Engineering Task Force (IETF), its areas, and its working
groups. Note that other groups may also distribute working
documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of
six months and may be updated, replaced, or obsoleted by
other documents at any time. It is inappropriate to use
Internet-Drafts as reference material or to cite them other
than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be
accessed at http://www.ietf.org/shadow.html.
This Internet-Draft expires on January 13, 2001.
2. Abstract
This document describes an object class called ldapSubEntry
which MAY be used to indicate operations and management
related entries in the directory, called LDAP Subentries.
This version of this document is updated with an assigned
OID for the ldapSubEntry object class.
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL",
"SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY",
and "OPTIONAL" in this document are to be interpreted as
described in RFC 2119 [RFC2119]. The sections below
reiterate these definitions and include some additional
ones.
Reed . [Page 1]
Expires January 13, 2001
INTERNET-DRAFT 13 July 2000
LDAP Subentry Schema
3. Definition
3.1 ldapSubEntry Class
( 2.16.840.1.113719.2.142.6.1.1 NAME 'ldapSubEntry'
DESC 'LDAP Subentry class, version 1'
SUP top STRUCTURAL
MAY ( cn ) )
The class ldapSubEntry is intended to be used as a super-
class when defining other structural classes to be used
as LDAP Subentries, and as the structural class to which
Auxiliary classes may be added for application specific
subentry information. Where possible, the use of Auxiliary
classes to extend ldapSubEntries is strongly preferred.
The presence of ldapSubEntry in the list of super-classes
of an entry in the directory makes that entry an LDAP
Subentry. Object classes derived from ldapSubEntry are
themselves considered ldapSubEntry classes, for the purpose
of this discussion.
LDAP Subentries MAY be named by their commonName attribute
[LDAPv3]. Other naming attributes are also permitted.
LDAP Subentries MAY be containers, unlike their [X.501]
counterparts.
LDAP Subentries MAY be contained by, and will usually be
located in the directory information tree immediately
subordinate to, administrative points and/or naming
contexts. Further (unlike X.500 subentries), LDAP
Subentries MAY be contained by other LDAP Subentries (the
way organizational units may be contained by other
organizational units). Deep nestings of LDAP Subentries
are discouraged, but not prohibited.
LDAP Subentries SHOULD be treated as "operational objects"
in much the same way that "operational attributes" are not
regularly provided in search results and read operations
when only user attributes are requested).
LDAP servers SHOULD implement the following special
handling of ldapSubEntry entries:
a) search operations which include a matching criteria
"objectclass=ldapSubEntry" MUST include entries derived
Reed . [Page 2]
Expires January 13, 2001
INTERNET-DRAFT 13 July 2000
LDAP Subentry Schema
from the ldapSubEntry class in the scope of their
operations;
b) search operations which do not include a matching
criteria "objectclass=ldapSubEntry" MUST IGNORE entries
derived from the ldapSubEntry class, and exclude them from
the scope of their operations.
The combination of SHOULD and MUST in the special handling
instructions, above, are meant to convey this: Servers
SHOULD support this special handling, and if they do they
MUST do it as described, and not some other way.
4. Security Considerations
LDAP Subentries will frequently be used to hold data which
reflects either the actual or intended behavior of the
directory service. As such, permission to read such
entries MAY need to be restricted to authorized users.
More importantly, IF a directory service treats the
information in an LDAP Subentry as the authoritative source
of policy to be used to control the behavior of the
directory, then permission to create, modify, or delete
such entries MUST be carefully restricted to authorized
administrators.
5. References
[LDAPv3] S. Kille, M. Wahl, and T. Howes, "Lightweight
Directory Access Protocol (v3)", RFC 2251, December 1997
[X.501] ITU-T Rec. X.501, "The Directory: Models", 1993
6. Copyright Notice
Copyright (C) The Internet Society (1999). All Rights
Reserved.
This document and translations of it may be copied and
furnished to others, and derivative works that comment on
or otherwise explain it or assist in its implementation may
be prepared, copied, published and distributed, in whole or
Reed . [Page 3]
Expires January 13, 2001
INTERNET-DRAFT 13 July 2000
LDAP Subentry Schema
in part, without restriction of any kind, provided that the
above copyright notice and this paragraph are included on
all such copies and derivative works. However, this
document itself may not be modified in any way, such as by
removing the copyright notice or references to the Internet
Society or other Internet organizations, except as needed
for the purpose of developing Internet standards in which
case the procedures for copyrights defined in the Internet
Standards process must be followed, or as required to
translate it into languages other than English.
The limited permissions granted above are perpetual and
will not be revoked by the Internet Society or its
successors or assigns.
This document and the information contained herein is
provided on an "AS IS" basis and THE INTERNET SOCIETY AND
THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL
WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED
TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL
NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE."
7. Acknowledgements
The use of subEntry object class to store Replica and
Replication Agreement information is due primarily to the
lucid explanation by Mark Wahl, Innosoft, of how they could
be used and extended.
The IETF takes no position regarding the validity or scope
of any intellectual property or other rights that might be
claimed to pertain to the implementation or use of the
technology described in this document or the extent to
which any license under such rights might or might not be
available; neither does it represent that it has made any
effort to identify any such rights. Information on the
IETF's procedures with respect to rights in standards-track
and standards-related documentation can be found in BCP-11.
Copies of claims of rights made available for publication
and any assurances of licenses to be made available, or the
result of an attempt made to obtain a general license or
permission for the use of such proprietary rights by
implementors or users of this specification can be obtained
from the IETF Secretariat.
Reed . [Page 4]
Expires January 13, 2001
INTERNET-DRAFT 13 July 2000
LDAP Subentry Schema
The IETF invites any interested party to bring to its
attention any copyrights, patents or patent applications,
or other proprietary rights which may cover technology that
may be required to practice this standard. Please address
the information to the IETF Executive Director.
8. Author's Address
Edwards E. Reed
Reed-Matthews, Inc.
1064 E 140 North
Lindon, UT 84042
USA
E-mail: eer@oncalldba.com
LDUP Mailing List: ietf-ldup@imc.org
LDAPEXT Mailing List: ietf-ldapext@netscape.com
Reed . [Page 5]
Expires January 13, 2001

File diff suppressed because it is too large Load Diff