From ldapext-bounces@ietf.org Sun Oct 16 17:29:01 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ERG3x-0004OO-Hy; Sun, 16 Oct 2005 17:29:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ERG3w-0004OJ-2l for ldapext@megatron.ietf.org; Sun, 16 Oct 2005 17:29:00 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA25216 for ; Sun, 16 Oct 2005 17:28:52 -0400 (EDT) Received: from highlandsun.propagation.net ([66.221.212.168]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ERGF5-0006Vt-D8 for ldapext@ietf.org; Sun, 16 Oct 2005 17:40:34 -0400 Received: from [127.0.0.1] (highlandsun.com [66.221.212.169]) by highlandsun.propagation.net (8.13.3/8.13.3) with ESMTP id j9GLSi0b015825 for ; Sun, 16 Oct 2005 15:28:46 -0600 Message-ID: <4352C613.3070908@highlandsun.com> Date: Sun, 16 Oct 2005 14:28:51 -0700 From: Howard Chu User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a1) Gecko/20050925 SeaMonkey/1.1a MIME-Version: 1.0 To: ldapext@ietf.org References: <425E68F6.4020702@highlandsun.com> In-Reply-To: <425E68F6.4020702@highlandsun.com> Content-Type: multipart/mixed; boundary="------------080204030009070302080101" X-Spam-Score: 0.0 (/) X-Scan-Signature: b93f0dc9ddba0752e520e7aa9e82b4eb Subject: [ldapext] Representing LDAP protocol in LDAP X-BeenThere: ldapext@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: LDAP Extension Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ldapext-bounces@ietf.org Errors-To: ldapext-bounces@ietf.org This is a multi-part message in MIME format. --------------080204030009070302080101 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit I've attached an initial draft of the LDAP Logging schema we're using in OpenLDAP 2.3. This is my first try writing with the XML tools, so I'd like to get comments early before submitting to the RFC Editor. The intended category is Informational; I'm not seeing that in the output even though I've specified it in the XML source. (Any tips on making it behave? Using xml2rfc from xml.resource.org...) -- -- Howard Chu Chief Architect, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc OpenLDAP Core Team http://www.openldap.org/project/ --------------080204030009070302080101 Content-Type: text/plain; name="draft-chu-ldap-logschema-xx.txt" Content-Disposition: inline; filename="draft-chu-ldap-logschema-xx.txt" Content-Transfer-Encoding: 7bit Network Working Group H. Chu Internet-Draft Symas Corp. Expires: April 19, 2006 October 16, 2005 A Schema for Logging the LDAP Protocol draft-chu-ldap-logschema-01.txt Status of this Memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. 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 will expire on April 19, 2006. Copyright Notice Copyright (C) The Internet Society (2005). Abstract In order to facilitate remote administration and auditing of LDAP server operation, it is desirable to provide the server's operational logs themselves as a searchable LDAP directory. These logs may also be used as a persistent change log to support various replication mechanisms. This document defines a schema that may be used to represent all of the requests that have been processed by an LDAP server. It may be used by various applications for auditing, flight recorder, replication, and other purposes. Chu Expires April 19, 2006 [Page 1] Internet-Draft LDAP Log Schema October 2005 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . 3 2. Conventions . . . . . . . . . . . . . . . . . . . . . 4 3. Syntaxes . . . . . . . . . . . . . . . . . . . . . . . 5 3.1. Control Syntax . . . . . . . . . . . . . . . . . . . . 5 4. Attribute Types . . . . . . . . . . . . . . . . . . . 6 4.1. General Attribute Types . . . . . . . . . . . . . . . 6 4.2. Request-specific Attribute Types . . . . . . . . . . . 6 5. Object Classes . . . . . . . . . . . . . . . . . . . . 9 5.1. Basic Audit Object Classes . . . . . . . . . . . . . . 9 5.2. Request-Specific Object Classes . . . . . . . . . . . 9 5.3. Generic Container Class . . . . . . . . . . . . . . . 10 6. Discussion of Schema . . . . . . . . . . . . . . . . . 11 6.1. AuditObject . . . . . . . . . . . . . . . . . . . . . 11 6.2. AuditContainer . . . . . . . . . . . . . . . . . . . . 12 6.3. Request-Specific Discussion . . . . . . . . . . . . . 12 7. Examples . . . . . . . . . . . . . . . . . . . . . . . 15 8. Security Considerations . . . . . . . . . . . . . . . 16 9. Normative References . . . . . . . . . . . . . . . . . 16 Appendix A. IANA Considerations . . . . . . . . . . . . . . . . . 18 Author's Address . . . . . . . . . . . . . . . . . . . 19 Intellectual Property and Copyright Statements . . . . 20 Chu Expires April 19, 2006 [Page 2] Internet-Draft LDAP Log Schema October 2005 1. Introduction In a widely distributed network with multiple LDAP servers, it is desirable to be able to audit and monitor the operation of each server remotely, using the same tools that are normally used to interact with the LDAP servers. Using a standardized logging format in LDAP allows LDAP queries to be used to generate server usage statistics with little effort. This document describes a set of object classes that can be used to represent any LDAP operation. The object classes are intended to represent a complete record of all of the parameters of an operation. The log not only allows clients to see what operations were executed on a given server, but also to easily regenerate and re-issue a sequence of operations to aid in testing situations. The sequence of write operations recorded in the log can also be used by various replication mechanisms. Chu Expires April 19, 2006 [Page 3] Internet-Draft LDAP Log Schema October 2005 2. Conventions Imperative keywords defined in [RFC2119] are used in this document, and carry the meanings described there. Chu Expires April 19, 2006 [Page 4] Internet-Draft LDAP Log Schema October 2005 3. Syntaxes 3.1. Control Syntax A value of the Control syntax represents an LDAP Control as used by a client or server. It consists of the numeric OID of the Control, the Boolean criticality flag, and an optional OctetString containing the Control value. The definition given here merely repeats the definition of Controls in [RFC2251]. The Abstract Syntax Notation One (ASN.1 [X680]) definition of this syntax is as follows: Control ::= SEQUENCE { controlType LDAPOID, criticality BOOLEAN DEFAULT FALSE, controlValue OCTET STRING OPTIONAL } The following is an LDAP syntax description [RFC2252] suitable for publication in the subschema. ( LOG_SCHEMA_SYN.1 DESC 'Control' ) Chu Expires April 19, 2006 [Page 5] Internet-Draft LDAP Log Schema October 2005 4. Attribute Types 4.1. General Attribute Types These attributes are common to all of the LDAP request records. ( LOG_SCHEMA_AT.1 NAME 'reqDN' DESC 'Target DN of request' EQUALITY distinguishedNameMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.12 SINGLE- VALUE ) ( LOG_SCHEMA_AT .2 NAME 'reqStart' DESC 'Start time of request' EQUALITY generalizedTimeMatch ORDERING generalizedTimeOrderingMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.24 SINGLE-VALUE ) ( LOG_SCHEMA_AT .3 NAME 'reqEnd' DESC 'End time of request' EQUALITY generalizedTimeMatch ORDERING generalizedTimeOrderingMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.24 SINGLE-VALUE ) ( LOG_SCHEMA_AT .4 NAME 'reqType' DESC 'Type of request' EQUALITY caseIgnoreMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 SINGLE-VALUE ) ( LOG_SCHEMA_AT .5 NAME 'reqSession' DESC 'Session ID of request' EQUALITY caseIgnoreMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 SINGLE- VALUE ) ( LOG_SCHEMA_AT .6 NAME 'reqResult' DESC 'Result code of request' EQUALITY integerMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.27 SINGLE- VALUE ) ( LOG_SCHEMA_AT .7 NAME 'reqAuthzID' DESC 'Authorization ID of requestor' EQUALITY distinguishedNameMatch SYNTAX OMsDN SINGLE-VALUE ) ( LOG_SCHEMA_AT .8 NAME 'reqControls' DESC 'Request controls' EQUALITY objectIdentifierFirstComponentMatch SYNTAX LOG_SCHEMA_SYN.1 X-ORDERED 'VALUES' ) ( LOG_SCHEMA_AT .9 NAME 'reqRespControls' DESC 'Response controls of request' EQUALITY objectIdentifierFirstComponentMatch SYNTAX LOG_SCHEMA_SYN.1 X-ORDERED 'VALUES' ) 4.2. Request-specific Attribute Types These attributes are specific to a single type of LDAP request. ( LOG_SCHEMA_AT .10 NAME 'reqMethod' DESC 'Bind method of request' EQUALITY caseIgnoreMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 SINGLE- VALUE ) Chu Expires April 19, 2006 [Page 6] Internet-Draft LDAP Log Schema October 2005 ( LOG_SCHEMA_AT .11 NAME 'reqAssertion' DESC 'Compare Assertion of request' SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 SINGLE-VALUE ) ( LOG_SCHEMA_AT .12 NAME 'reqNewRDN' DESC 'New RDN of request' EQUALITY distinguishedNameMatch SYNTAX OMsDN SINGLE-VALUE ) ( LOG_SCHEMA_AT .13 NAME 'reqNewSuperior' DESC 'New superior DN of request' EQUALITY distinguishedNameMatch SYNTAX OMsDN SINGLE-VALUE ) ( LOG_SCHEMA_AT .14 NAME 'reqDeleteOldRDN' DESC 'Delete old RDN' SYNTAX 1.3.6.1.4.1.1466.115.121.1.7 SINGLE-VALUE ) ( LOG_SCHEMA_AT .15 NAME 'reqMod' DESC 'Modifications of request' SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 EQUALITY caseIgnoreMatch SUBSTR caseIgnoreSubstringsMatch ) ( LOG_SCHEMA_AT .16 NAME 'reqScope' DESC 'Scope of request' SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 SINGLE-VALUE ) ( LOG_SCHEMA_AT .17 NAME 'reqFilter' DESC 'Filter of request' SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 SINGLE-VALUE ) ( LOG_SCHEMA_AT .18 NAME 'reqAttr' DESC 'Attributes of request' SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 ) ( LOG_SCHEMA_AT .19 NAME 'reqEntries' DESC 'Number of entries returned' SYNTAX 1.3.6.1.4.1.1466.115.121.1.27 SINGLE-VALUE ) ( LOG_SCHEMA_AT .20 NAME 'reqSizeLimit' DESC 'Size limit of request' SYNTAX 1.3.6.1.4.1.1466.115.121.1.27 SINGLE-VALUE ) ( LOG_SCHEMA_AT .21 NAME 'reqTimeLimit' DESC 'Time limit of request' SYNTAX 1.3.6.1.4.1.1466.115.121.1.27 SINGLE-VALUE ) ( LOG_SCHEMA_AT .22 NAME 'reqAttrsOnly' DESC 'Attributes and values of request' SYNTAX 1.3.6.1.4.1.1466.115.121.1.7 SINGLE-VALUE ) ( LOG_SCHEMA_AT .23 NAME 'reqData' DESC 'Data of extended request' SYNTAX 1.3.6.1.4.1.1466.115.121.1.40 SINGLE-VALUE ) ( LOG_SCHEMA_AT .24 NAME 'reqId' DESC 'ID of Request to Abandon' SYNTAX 1.3.6.1.4.1.1466.115.121.1.27 SINGLE-VALUE ) ( LOG_SCHEMA_AT .25 NAME 'reqMessage' DESC 'Error text of request' SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 SINGLE-VALUE ) ( LOG_SCHEMA_AT .26 NAME 'reqVersion' DESC 'Protocol version of Bind request' SYNTAX 1.3.6.1.4.1.1466.115.121.1.27 SINGLE-VALUE ) Chu Expires April 19, 2006 [Page 7] Internet-Draft LDAP Log Schema October 2005 ( LOG_SCHEMA_AT .27 NAME 'reqDerefAliases' DESC 'Disposition of Aliases in request' SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 SINGLE-VALUE ) ( LOG_SCHEMA_AT .28 NAME 'reqReferral' DESC 'Referrals returned for request' SUP labeledURI ) ( LOG_SCHEMA_AT .29 NAME 'reqOld' DESC 'Old values of entry before request completed' SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 ) Chu Expires April 19, 2006 [Page 8] Internet-Draft LDAP Log Schema October 2005 5. Object Classes 5.1. Basic Audit Object Classes This is the basic class containing attributes common to all of the LDAP requests. The following object classes all inherit from this class. ( LOG_SCHEMA_OC .1 NAME 'auditObject' DESC 'OpenLDAP request auditing' SUP top STRUCTURAL MUST ( reqStart $ reqType $ reqSession ) MAY ( reqDN $ reqAuthzID $ reqControls $ reqRespControls $ reqEnd $ reqResult $ reqMessage $ reqReferral ) ) These object classes are used to aggregate read operations and write operations under common parent classes. ( LOG_SCHEMA_OC .2 NAME 'auditReadObject' DESC 'OpenLDAP read request record' SUP auditObject STRUCTURAL ) ( LOG_SCHEMA_OC .3 NAME 'auditWriteObject' DESC 'OpenLDAP write request record' SUP auditObject STRUCTURAL ) 5.2. Request-Specific Object Classes Each LDAP Request has its own object class containing all of the attributes needed to represent an instance of the request. ( LOG_SCHEMA_OC .4 NAME 'auditAbandon' DESC 'Abandon operation' SUP auditObject STRUCTURAL MUST reqId ) ( LOG_SCHEMA_OC .5 NAME 'auditAdd' DESC 'Add operation' SUP auditWriteObject STRUCTURAL MUST reqDN $ reqMod ) ( LOG_SCHEMA_OC .6 NAME 'auditBind' DESC 'Bind operation' SUP auditObject STRUCTURAL MUST reqDN $ reqMethod $ reqVersion ) ( LOG_SCHEMA_OC .7 NAME 'auditCompare' DESC 'Compare operation' SUP auditReadObject STRUCTURAL MUST reqDN $ reqAssertion ) ( LOG_SCHEMA_OC .8 NAME 'auditModify' DESC 'Modify operation' SUP auditWriteObject STRUCTURAL MUST reqDN $ reqMod $ reqOld ) ( LOG_SCHEMA_OC .9 NAME 'auditModDN' DESC 'ModDN operation' SUP auditWriteObject STRUCTURAL MUST ( reqDN $ reqNewRDN $ reqDeleteOldRDN ) MAY reqNewSuperior ) ( LOG_SCHEMA_OC .10 NAME 'auditSearch' DESC 'Search operation' SUP auditReadObject STRUCTURAL MUST ( reqDN $ reqScope $ reqAttrsonly ) Chu Expires April 19, 2006 [Page 9] Internet-Draft LDAP Log Schema October 2005 MAY ( reqFilter $ reqAttr $ reqEntries $ reqSizeLimit $ reqTimeLimit ) ) ( LOG_SCHEMA_OC .11 NAME 'auditExtended' DESC 'Extended operation' SUP auditObject STRUCTURAL MAY reqData ) ( LOG_SCHEMA_OC .12 NAME 'auditDelete' DESC 'Delete operation' SUP auditWriteObject STRUCTURAL MAY reqOld ) 5.3. Generic Container Class This object class may be used for the parent entry of the log records. ( LOG_SCHEMA_OC .0 NAME 'auditContainer' DESC 'AuditLog container' SUP top STRUCTURAL MAY ( cn $ reqStart $ reqEnd ) ) Chu Expires April 19, 2006 [Page 10] Internet-Draft LDAP Log Schema October 2005 6. Discussion of Schema 6.1. AuditObject 1. reqDN: the distinguished name of the entry the request applies to. In the case of a ModDN request, the reqDN gives the DN of the entry before it was modified. In the case of a Search request, the reqDN is the base DN of the search. Syntax: DN 2. reqStart: the time the request began on the server. reqEnd: the time the request completed on the server. The timestamps MUST have high enough resolution to ensure that the reqStart values are unique. The values for reqEnd MUST also be unique, although overlap of reqStart and reqEnd values is allowed. Servers SHOULD use one of reqStart or reqEnd as the log records' RDN. Either choice will allow records to be read in ascending order, although the two alternatives may produce different orders. In cases where the server clocks do not provide sufficient resolution, a simple counter may be used in the fractional seconds part to distinguish multiple events occurring within the same second. Syntax: GeneralizedTime 3. reqType: the type of request. One of: "abandon", "add", "bind", "compare", "delete", "modify", "moddn", "search", or "extended{OID}". For Extended requests, the numeric objectIdentifier of the request is included in the string. Syntax: DirectoryString 4. reqSession: an implementation-defined value that is constant for all operations occurring within a Bind/Unbind sequence. Syntax: DirectoryString 5. reqResult: the LDAP result code for a completed Request. This value is omitted for Requests which have no defined result (e.g. Abandon and Unbind) and also for Requests which were Abandoned or otherwise did not run to completion. Syntax: Integer 6. reqMessage: the textual error message accompanying the result, if any. Syntax: DirectoryString 7. reqReferral: any referrals that accompanied the result. They are in the standard LDAP URI format [RFC2255]. Syntax: DirectoryString Chu Expires April 19, 2006 [Page 11] Internet-Draft LDAP Log Schema October 2005 8. reqAuthzID: the Authorization Identity used to perform the request. This will usually be the same as the reqDN of the Bind request with matching reqSession, but may be altered by various Controls and other processing. Syntax: DN 9. reqControls: the set of Request Controls accompanying a request. reqRespControls: the set of Response Controls accompanying a request result. Each value represents a single Control. Note that since Controls are transmitted as an ordered Sequence, the X-ORDERED 'VALUES' [XORDERED]schema extension is used here to preserve their ordering. Syntax: Control 6.2. AuditContainer reqStart: the timestamp of the first (oldest) record in the log. reqEnd: the timestamp of the last (newest) record in the log. Syntax: GeneralizedTime 6.3. Request-Specific Discussion 6.3.1. Abandon reqId: the ID of a request to Abandon. Syntax: Integer 6.3.2. Bind reqMethod: the Bind method. Either "Simple" or "SASL/" where "" is the specific SASL mechanism requested. Syntax: DirectoryString reqVersion: the protocol version of the request. Syntax: Integer 6.3.3. Compare reqAssertion: the Attribute Value Assertion (AVA) of the request. The AVA is encoded according to the rules in [RFC2254]. Syntax: DirectoryString 6.3.4. ModDN reqNewRDN: the new RDN of the request. Syntax: DN reqNewSuperior: the new Superior DN of the request. Chu Expires April 19, 2006 [Page 12] Internet-Draft LDAP Log Schema October 2005 Syntax: DN reqDeletedOldRDN: the deleteOldRDN value of the request. Syntax: Boolean 6.3.5. Add and Modify reqMod: The modifications of the request. The encoding is defined by the following grammar, using the ABNF notation defined in [RFC0822]. mod = attr ":" modop attr = AttributeDescription from [RFC2251] modop = add / delete / replace / increment add = "+" sp value delete = "-" [ sp value ] replace = "=" [ sp value ] increment = "#" sp value sp = " " value = AttributeValue from [RFC2251] Note that Add requests will only use the add modop format. Syntax: DirectoryString reqOld: the previous values of a modified attribute. The encoding is of the form attr ":" sp value, using the same definitions as for reqMod above. Syntax: DirectoryString 6.3.6. Delete reqOld: the previous values of a deleted entry. The encoding is as given above. Syntax: DirectoryString 6.3.7. Search reqScope: the scope of the Search request. One of "base", "one", "subtree", or "subordinate". Syntax: DirectoryString Chu Expires April 19, 2006 [Page 13] Internet-Draft LDAP Log Schema October 2005 reqDerefAliases: the derefAliases parameter of the Search request. One of "never", "searching", "finding", or "always". Syntax: DirectoryString reqSizeLimit: the size limit of the request. reqTimeLimit: the time limit of the request. Syntax: Integer reqAttrsOnly: the typesOnly parameter of the request. Syntax: Boolean reqFilter: the Search filter, encoded according to [RFC2254]. Syntax: DirectoryString reqAttr: the specific attributes requested, if any. Syntax: DirectoryString reqEntries: the total number of entries returned for this request. Syntax: Integer 6.3.8. Extended reqData: the data accompanying the request, if any. Syntax: OctetString Chu Expires April 19, 2006 [Page 14] Internet-Draft LDAP Log Schema October 2005 7. Examples To be filled in later... Chu Expires April 19, 2006 [Page 15] Internet-Draft LDAP Log Schema October 2005 8. Security Considerations Servers implementing this scheme SHOULD NOT allow the logs to be generally readable. Extensive information about the existence and content of data, as well as the usage patterns associated with the data, will be present in the log and should only be made available to trusted users. The structure of the log does not prevent fine-grained access controls from being used, although the rules will be necessarily longer than they would be in the primary database. E.g., while a single rule to deny access to the userPassword attribute would suffice in the primary database, two rules would be needed in the log - one to deny access to the reqOld attribute with values userPassword:*, and one to deny access to the reqMod attribute with values userPassword:*. Servers implementing this scheme should disallow write access to the log container object and all entries contained within. 9. Normative References [RFC0822] Crocker, D., "Standard for the format of ARPA Internet text messages", STD 11, RFC 822, August 1982. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC2251] Wahl, M., Howes, T., and S. Kille, "Lightweight Directory Access Protocol (v3)", RFC 2251, December 1997. [RFC2252] Wahl, M., Coulbeck, A., Howes, T., and S. Kille, "Lightweight Directory Access Protocol (v3): Attribute Syntax Definitions", RFC 2252, December 1997. [RFC2254] Howes, T., "The String Representation of LDAP Search Filters", RFC 2254, December 1997. [RFC2255] Howes, T. and M. Smith, "The LDAP URL Format", RFC 2255, December 1997. [RFC3383] Zeilenga, K., "Internet Assigned Numbers Authority (IANA) Considerations for the Lightweight Directory Access Protocol (LDAP)", BCP 64, RFC 3383, September 2002. [X680] International Telecommunications Union, "Abstract Syntax Notation One (ASN.1): Specification of basic notation", ITU-T Recommendation X.680, July 2002. Chu Expires April 19, 2006 [Page 16] Internet-Draft LDAP Log Schema October 2005 [XORDERED] Chu, H., "Ordered Values in LDAP", a work in progress draft-chu-ldap-orderedvalues-xx.txt. Chu Expires April 19, 2006 [Page 17] Internet-Draft LDAP Log Schema October 2005 Appendix A. IANA Considerations In accordance with [RFC3383] (what needs to be done here?) . Currently we are using OpenLDAP_Experimental = 1.3.6.1.4.1.4203.666 LOG_SCHEMA = OpenLDAP_Experimental.11.5 LOG_SCHEMA_AT = LOG_SCHEMA.1 LOG_SCHEMA_OC = LOG_SCHEMA.2 LOG_SCHEMA_SYN = LOG_SCHEMA.3 Chu Expires April 19, 2006 [Page 18] Internet-Draft LDAP Log Schema October 2005 Author's Address Howard Chu Symas Corp. 18740 Oxnard Street, Suite 313A Tarzana, California 91356 USA Phone: +1 818 757-7087 Email: hyc@symas.com Chu Expires April 19, 2006 [Page 19] Internet-Draft LDAP Log Schema October 2005 Intellectual Property Statement The IETF takes no position regarding the validity or scope of any Intellectual Property Rights 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; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat 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 implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. Disclaimer of Validity This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM 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. Copyright Statement Copyright (C) The Internet Society (2005). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. Acknowledgment Funding for the RFC Editor function is currently provided by the Internet Society. Chu Expires April 19, 2006 [Page 20] --------------080204030009070302080101 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ldapext mailing list Ldapext@ietf.org https://www1.ietf.org/mailman/listinfo/ldapext --------------080204030009070302080101-- From ldapext-bounces@ietf.org Mon Oct 17 06:44:38 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ERSTu-0000Ds-0h; Mon, 17 Oct 2005 06:44:38 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ERSTr-0000Db-TA for ldapext@megatron.ietf.org; Mon, 17 Oct 2005 06:44:35 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA02923 for ; Mon, 17 Oct 2005 06:44:27 -0400 (EDT) Received: from highlandsun.propagation.net ([66.221.212.168]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ERSf9-00014M-3b for ldapext@ietf.org; Mon, 17 Oct 2005 06:56:17 -0400 Received: from [127.0.0.1] (highlandsun.com [66.221.212.169]) by highlandsun.propagation.net (8.13.3/8.13.3) with ESMTP id j9HAiJnW030740 for ; Mon, 17 Oct 2005 04:44:20 -0600 Message-ID: <4353808B.9010304@highlandsun.com> Date: Mon, 17 Oct 2005 03:44:27 -0700 From: Howard Chu User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a1) Gecko/20050925 SeaMonkey/1.1a MIME-Version: 1.0 To: ldapext@ietf.org Subject: Re: [ldapext] Representing LDAP protocol in LDAP References: <425E68F6.4020702@highlandsun.com> <4352C613.3070908@highlandsun.com> In-Reply-To: <4352C613.3070908@highlandsun.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.2 (/) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 Content-Transfer-Encoding: 7bit X-BeenThere: ldapext@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: LDAP Extension Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ldapext-bounces@ietf.org Errors-To: ldapext-bounces@ietf.org Howard Chu wrote: > I've attached an initial draft of the LDAP Logging schema we're using in > OpenLDAP 2.3. This is my first try writing with the XML tools, so I'd > like to get comments early before submitting to the RFC Editor. The > intended category is Informational; I'm not seeing that in the output > even though I've specified it in the XML source. (Any tips on making it > behave? Using xml2rfc from xml.resource.org...) The XML source as well as the text and HTML output are temporarily available here: http://24.126.120.178/~hyc/. The corresponding implementation is in the current OpenLDAP CVS. -- -- Howard Chu Chief Architect, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc OpenLDAP Core Team http://www.openldap.org/project/ _______________________________________________ Ldapext mailing list Ldapext@ietf.org https://www1.ietf.org/mailman/listinfo/ldapext From ldapext-bounces@ietf.org Tue Oct 18 11:55:35 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ERtoN-0000yu-RR; Tue, 18 Oct 2005 11:55:35 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ERtoN-0000yp-0P for ldapext@megatron.ietf.org; Tue, 18 Oct 2005 11:55:35 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA11447 for ; Tue, 18 Oct 2005 11:55:26 -0400 (EDT) Received: from lucius.provo.novell.com ([137.65.81.172]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ERtzu-0001ta-SU for ldapext@ietf.org; Tue, 18 Oct 2005 12:07:32 -0400 Received: from INET-PRV1-MTA by lucius.provo.novell.com with Novell_GroupWise; Tue, 18 Oct 2005 09:55:19 -0600 Message-Id: <4354C6E9.0703.006F.0@novell.com> X-Mailer: Novell GroupWise Internet Agent 7.0 Date: Tue, 18 Oct 2005 09:55:09 -0600 From: "Steve Trottier" To: "Howard Chu" , Subject: Re: [ldapext] Representing LDAP protocol in LDAP References: <425E68F6.4020702@highlandsun.com> <4352C613.3070908@highlandsun.com> In-Reply-To: <4352C613.3070908@highlandsun.com> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Spam-Score: 0.0 (/) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f Content-Transfer-Encoding: 7bit Cc: X-BeenThere: ldapext@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: LDAP Extension Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ldapext-bounces@ietf.org Errors-To: ldapext-bounces@ietf.org Howard, This seem well thought out and obviously an improvement (at least for auditing purposes) to the older changelog mechanism in use by several other directories. Is there a standard way to discover if this LDAP Logging mechanism is in use in a particular directory? I.e, will there be an entry in the rootDSE indicating the DN of the auditContainer in use? Or would a potential consumer of this information search the directory looking for entries that have the objectclass of interest? Also, is this feature on by default in OpenLDAP 2.3? Is its use configurable? Thanks, Steve Trottier Sr. Software Engineer Novell, Inc. http://www.novell.com/ >>> Howard Chu 10/16/2005 3:28:51 pm >>> I've attached an initial draft of the LDAP Logging schema we're using in OpenLDAP 2.3. This is my first try writing with the XML tools, so I'd like to get comments early before submitting to the RFC Editor. The intended category is Informational; I'm not seeing that in the output even though I've specified it in the XML source. (Any tips on making it behave? Using xml2rfc from xml.resource.org...) -- -- Howard Chu Chief Architect, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc OpenLDAP Core Team http://www.openldap.org/project/ _______________________________________________ Ldapext mailing list Ldapext@ietf.org https://www1.ietf.org/mailman/listinfo/ldapext From ldapext-bounces@ietf.org Tue Oct 18 12:30:25 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ERuM5-0004vD-Hw; Tue, 18 Oct 2005 12:30:25 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ERuM3-0004v5-Nq for ldapext@megatron.ietf.org; Tue, 18 Oct 2005 12:30:23 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA13168 for ; Tue, 18 Oct 2005 12:30:15 -0400 (EDT) Received: from highlandsun.propagation.net ([66.221.212.168]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ERuXc-0002ki-Qa for ldapext@ietf.org; Tue, 18 Oct 2005 12:42:21 -0400 Received: from [127.0.0.1] (highlandsun.com [66.221.212.169]) by highlandsun.propagation.net (8.13.3/8.13.3) with ESMTP id j9IGUB2P032660; Tue, 18 Oct 2005 10:30:12 -0600 Message-ID: <43552317.3000700@highlandsun.com> Date: Tue, 18 Oct 2005 09:30:15 -0700 From: Howard Chu User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a1) Gecko/20050925 SeaMonkey/1.1a MIME-Version: 1.0 To: Steve Trottier Subject: Re: [ldapext] Representing LDAP protocol in LDAP References: <425E68F6.4020702@highlandsun.com> <4352C613.3070908@highlandsun.com> <4354C6E9.0703.006F.0@novell.com> In-Reply-To: <4354C6E9.0703.006F.0@novell.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.2 (/) X-Scan-Signature: e8a67952aa972b528dd04570d58ad8fe Content-Transfer-Encoding: 7bit Cc: ldapext@ietf.org X-BeenThere: ldapext@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: LDAP Extension Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ldapext-bounces@ietf.org Errors-To: ldapext-bounces@ietf.org Steve Trottier wrote: > Howard, Hi Steve, > This seem well thought out and obviously an improvement (at least for > auditing purposes) to the older changelog mechanism in use by several > other directories. > > Is there a standard way to discover if this LDAP Logging mechanism is > in use in a particular directory? I.e, will there be an entry in the > rootDSE indicating the DN of the auditContainer in use? Or would a > potential consumer of this information search the directory looking for > entries that have the objectclass of interest? Good questions. There is currently no formal mechanism to advertise the availability of this feature. I realize that's a hole here. My preference would be to provide an operational attribute for the root entry of a naming context that gives the DN of the container. Alternatively it could be a collective attribute returned for all entries under the naming context. Since we can configure multiple databases in the server, and each database could be logging to different destinations, just listing the DN of a container in the rootDSE doesn't provide enough information. (I.e., you need to know which log goes with which subtree / naming context.) > > Also, is this feature on by default in OpenLDAP 2.3? Is its use > configurable? The feature is not on by default, it's implemented in a separate overlay module. There are a few simple options to configure it, e.g. you can configure it to log only a subset of operation types. You can view the current manpage for the overlay here http://24.126.120.178/~hyc/man/man5/slapo-accesslog.5 By the way, the XORDERED draft that this document references is now also available. http://24.126.120.178/~hyc/draft-chu-ldap-xordered-xx.txt > > Thanks, > > Steve Trottier > Sr. Software Engineer > Novell, Inc. http://www.novell.com/ > >>>> Howard Chu 10/16/2005 3:28:51 pm >>> > I've attached an initial draft of the LDAP Logging schema we're using > in > OpenLDAP 2.3. This is my first try writing with the XML tools, so I'd > > like to get comments early before submitting to the RFC Editor. The > intended category is Informational; I'm not seeing that in the output > even though I've specified it in the XML source. (Any tips on making it > > behave? Using xml2rfc from xml.resource.org...) > -- -- Howard Chu Chief Architect, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc OpenLDAP Core Team http://www.openldap.org/project/ _______________________________________________ Ldapext mailing list Ldapext@ietf.org https://www1.ietf.org/mailman/listinfo/ldapext From ldapext-bounces@ietf.org Tue Oct 18 19:08:06 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ES0Yw-000168-LA; Tue, 18 Oct 2005 19:08:06 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ES0Yv-00014L-Ds for ldapext@megatron.ietf.org; Tue, 18 Oct 2005 19:08:05 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA05766 for ; Tue, 18 Oct 2005 19:07:56 -0400 (EDT) Received: from lucius.provo.novell.com ([137.65.81.172]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ES0kW-0007Vw-M2 for ldapext@ietf.org; Tue, 18 Oct 2005 19:20:06 -0400 Received: from INET-PRV1-MTA by lucius.provo.novell.com with Novell_GroupWise; Tue, 18 Oct 2005 17:07:54 -0600 Message-Id: <43552C4B.0703.006F.0@novell.com> X-Mailer: Novell GroupWise Internet Agent 7.0 Date: Tue, 18 Oct 2005 17:07:42 -0600 From: "Steve Trottier" To: "Howard Chu" , Subject: Re: [ldapext] Representing LDAP protocol in LDAP References: <425E68F6.4020702@highlandsun.com> <4352C613.3070908@highlandsun.com> <4354C6E9.0703.006F.0@novell.com> <43552317.3000700@highlandsun.com> In-Reply-To: <43552317.3000700@highlandsun.com> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Spam-Score: 0.2 (/) X-Scan-Signature: 769a46790fb42fbb0b0cc700c82f7081 Content-Transfer-Encoding: 7bit Cc: X-BeenThere: ldapext@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: LDAP Extension Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ldapext-bounces@ietf.org Errors-To: ldapext-bounces@ietf.org Thank you for those answers. Regarding where to put the operational attribute with the DN of the audit container, I think either (or both) would work. The preferred method would depend on what a client's purpose would be in reading the audit information. If you wanted to see all accesses or writes to a particular entry in the directory, then your second suggestion of the attribute being available on all entries under a naming context would be helpful because you could read the value of the container directly from the entry of interest. If, however, your purpose in reading the audit information was to replicate or synchronize directory data, then you would probably just want a quick way to find which container or containers you should poll for updates. Searching the rootDSE for naming contexts and then the naming contexts for their audit containers would work well in that case. Interestingly, these two methods are very similar to the current methods of finding a subschemasubentry, which makes sense. >>> Howard Chu 10/18/2005 10:30:15 am >>> ... There is currently no formal mechanism to advertise the availability of this feature. I realize that's a hole here. My preference would be to provide an operational attribute for the root entry of a naming context that gives the DN of the container. Alternatively it could be a collective attribute returned for all entries under the naming context. Since we can configure multiple databases in the server, and each database could be logging to different destinations, just listing the DN of a container in the rootDSE doesn't provide enough information. (I.e., you need to know which log goes with which subtree / naming context.) > > Also, is this feature on by default in OpenLDAP 2.3? Is its use > configurable? The feature is not on by default, it's implemented in a separate overlay module. There are a few simple options to configure it, e.g. you can configure it to log only a subset of operation types. You can view the current manpage for the overlay here http://24.126.120.178/~hyc/man/man5/slapo-accesslog.5 By the way, the XORDERED draft that this document references is now also available. http://24.126.120.178/~hyc/draft-chu-ldap-xordered-xx.txt _______________________________________________ Ldapext mailing list Ldapext@ietf.org https://www1.ietf.org/mailman/listinfo/ldapext From ldapext-bounces@ietf.org Wed Oct 19 04:23:29 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ES9EP-00066U-HC; Wed, 19 Oct 2005 04:23:29 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ES9EN-000660-4W for ldapext@megatron.ietf.org; Wed, 19 Oct 2005 04:23:27 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA29326 for ; Wed, 19 Oct 2005 04:23:19 -0400 (EDT) Received: from marlin.sxip.com ([199.60.48.20] helo=mail1.sxip.com ident=root) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ES9Q4-0003ML-Mm for ldapext@ietf.org; Wed, 19 Oct 2005 04:35:33 -0400 Received: from [192.168.1.34] (host-212-18-224-126.static.mailbox.co.uk [212.18.224.126]) (authenticated bits=0) by mail1.sxip.com (8.13.1/8.13.1) with ESMTP id j9J8NJYi008721 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for ; Wed, 19 Oct 2005 01:23:21 -0700 (PDT) (envelope-from merrells@sxip.com) Mime-Version: 1.0 (Apple Message framework v734) Content-Transfer-Encoding: 7bit Message-Id: Content-Type: text/plain; charset=US-ASCII; format=flowed To: ldapext@ietf.org From: John Merrells Date: Wed, 19 Oct 2005 09:23:17 +0100 X-Mailer: Apple Mail (2.734) X-Scanned-By: MIMEDefang 2.51 on 199.60.48.141 X-Spam-Score: 0.0 (/) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 Content-Transfer-Encoding: 7bit Subject: [ldapext] Invitation to join the Digital Identity Exchange IETF mailing list X-BeenThere: ldapext@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: LDAP Extension Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ldapext-bounces@ietf.org Errors-To: ldapext-bounces@ietf.org Hello, We'd like to invite you to join the IETF mailing list for discussion of protocols and schema for exchange of digital identity information. For background information this keynote address delivered at OSCON 2005 presents the vision we wish to realize: http://www.identity20.com/media/OSCON2005/ And, these 'laws of identity' define the properties of an acceptable user-centric identity information architecture: http://www.identityblog.com/stories/2005/07/25/thelaws.html To subscribe to the mailing list send an email with the message body 'subscribe' to: dix-request@ietf.org In addition there will be a meeting held at the next IETF, November 5-11 in Vancouver. This will be an opportunity to discuss digital identity issues face to face, and to consider whether the IETF should formally consider protocols for exchange of digital identity information. We'd like to welcome you to join us in Vancouver for that conversation. John Merrells _______________________________________________ Ldapext mailing list Ldapext@ietf.org https://www1.ietf.org/mailman/listinfo/ldapext From ldapext-bounces@ietf.org Thu Oct 27 00:19:49 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EUzEz-0002A5-Ou; Thu, 27 Oct 2005 00:19:49 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EUzEw-00026Z-VE for ldapext@megatron.ietf.org; Thu, 27 Oct 2005 00:19:47 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA21395 for ; Thu, 27 Oct 2005 00:19:30 -0400 (EDT) Received: from eagle.unknowndns.net ([221.133.206.175] ident=[U2FsdGVkX197biERvD6pCZDGKpjeBqq5MKs7ws+UCSg=]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EUzSE-0006gN-7D for ldapext@ietf.org; Thu, 27 Oct 2005 00:33:31 -0400 Received: from cust3103.vic01.dataco.com.au ([202.63.62.31] helo=[192.168.1.159]) by eagle.unknowndns.net with esmtpa (Exim 4.52) id 1EUzES-0000nQ-Uk; Thu, 27 Oct 2005 14:19:17 +1000 Message-ID: <43605543.1060002@eB2Bcom.com> Date: Thu, 27 Oct 2005 14:19:15 +1000 From: Andrew Sciberras Organization: eB2Bcom User-Agent: Mozilla Thunderbird 1.0.7 (Windows/20050923) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Jim Sermersheim , hyc@symas.com References: In-Reply-To: X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - eagle.unknowndns.net X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [47 12] X-AntiAbuse: Sender Address Domain - eB2Bcom.com X-Spam-Score: 0.6 (/) X-Scan-Signature: 386e0819b1192672467565a524848168 Cc: Ldapext Subject: [ldapext] Re: I-D ACTION:draft-sermersheim-ldap-csn-02.txt X-BeenThere: ldapext@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: andrew.sciberras@eB2Bcom.com List-Id: LDAP Extension Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0358020340==" Sender: ldapext-bounces@ietf.org Errors-To: ldapext-bounces@ietf.org --===============0358020340== Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Hi Guys,


In order to ensure that the UTF8String in the ChangeSequenceNumber type is encoded correctly (when or if BER is used), it should be defined as being:

UTF8String ::= [UNIVERSAL 12] IMPLICIT OCTET STRING -- UTF-8 encoded.


Regards,
Andrew Sciberras


Internet-Drafts@ietf.org wrote: 
A New Internet-Draft is available from the on-line Internet-Drafts directories.


	Title		: The LDAP Change Sequence Number
	Author(s)	: H. Chu, J. Sermersheim
	Filename	: draft-sermersheim-ldap-csn-02.txt
	Pages		: 16
	Date		: 2005-10-26
	
This document defines a syntax schema element for the Lightweight 
Directory Access Protocol ([LDAP]) which is used to hold a Change 
Sequence Number (CSN). In general, a change sequence number 
represents the place and time that a directory entity was changed. It 
may be used by various attributes for various LDAP replication, and 
synchronization applications.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-sermersheim-ldap-csn-02.txt

To remove yourself from the I-D Announcement list, send a message to 
i-d-announce-request@ietf.org with the word unsubscribe in the body of the message.  
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce 
to change your subscription settings.


Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-sermersheim-ldap-csn-02.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt


Internet-Drafts can also be obtained by e-mail.

Send a message to:
	mailserv@ietf.org.
In the body type:
	"FILE /internet-drafts/draft-sermersheim-ldap-csn-02.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.
		
		
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.
  

_______________________________________________
I-D-Announce mailing list
I-D-Announce@ietf.org
https://www1.ietf.org/mailman/listinfo/i-d-announce


--===============0358020340== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ldapext mailing list Ldapext@ietf.org https://www1.ietf.org/mailman/listinfo/ldapext --===============0358020340==--