From mailman-admin@ietf.org Sat Mar 1 10:10:24 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA07788 for ; Sat, 1 Mar 2003 10:10:24 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h21FJQp23520 for ; Sat, 1 Mar 2003 10:19:26 -0500 Date: Sat, 01 Mar 2003 10:19:26 -0500 Message-ID: <20030301151926.26394.78134.Mailman@www1.ietf.org> Subject: ietf.org mailing list memberships reminder From: mailman-owner@www1.ietf.org To: ldapext-archive@ietf.org X-No-Archive: yes X-Ack: no Sender: mailman-admin@ietf.org Errors-To: mailman-admin@ietf.org X-BeenThere: mailman@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk This is a reminder, sent out once a month, about your ietf.org mailing list memberships. It includes your subscription info and how to use it to change it or unsubscribe from a list. You can visit the URLs to change your membership status or configuration, including unsubscribing, setting digest-style delivery or disabling delivery altogether (e.g., for a vacation), and so on. In addition to the URL interfaces, you can also use email to make such changes. For more info, send a message to the '-request' address of the list (for example, ldapext-request@ietf.org) containing just the word 'help' in the message body, and an email message will be sent to you with instructions. *************************************************************************** Note Well All statements related to the activities of the IETF and addressed to the IETF are subject to all provisions of Section 10 of RFC 2026, which grants to the IETF and its participants certain licenses and rights in such statements. Such statements include verbal statements in IETF meetings, as well as written and electronic communications made at any time or place, which are addressed to * the IETF plenary session, * any IETF working group or portion thereof, * the IESG, or any member thereof on behalf of the IESG, * the IAB or any member thereof on behalf of the IAB, * any IETF mailing list, including the IETF list itself, any working group or design team list, or any other list functioning under IETF auspices, * the RFC Editor or the Internet-Drafts function Statements made outside of an IETF meeting, mailing list or other function, that are clearly not intended to be input to an IETF activity, group or function, are not subject to these provisions. *************************************************************************** If you have questions, problems, comments, etc, send them to mailman-owner@www1.ietf.org. Thanks! Passwords for ldapext-archive@lists.ietf.org: List Password // URL ---- -------- ldapext@ietf.org LxAC https://www1.ietf.org/mailman/options/ldapext/ldapext-archive%40lists.ietf.org From ldapext-admin@ietf.org Fri Mar 7 15:48:26 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA01291 for ; Fri, 7 Mar 2003 15:48:26 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h27Kx6O06852; Fri, 7 Mar 2003 15:59:06 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h27Kk4O05697 for ; Fri, 7 Mar 2003 15:46:04 -0500 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA28867; Fri, 7 Mar 2003 15:33:52 -0500 (EST) Message-Id: <200303072033.PAA28867@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; CC: ldapext@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Date: Fri, 07 Mar 2003 15:33:52 -0500 Subject: [ldapext] I-D ACTION:draft-zeilenga-ldapbis-strmatch-02.txt Sender: ldapext-admin@ietf.org Errors-To: ldapext-admin@ietf.org X-BeenThere: ldapext@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: LDAP Extension Working Group List-Post: List-Help: List-Subscribe: , --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Internationalized String Matching Rules for X.500 Author(s) : K. Zeilenga Filename : draft-zeilenga-ldapbis-strmatch-02.txt Pages : 16 Date : 2003-3-7 The existing X.500 Directory Service technical specifications do not precisely define how string matching is to be performed. This has lead to a number of interoperability problems. This document provides string preparation profiles for standard syntaxes and matching rules defined in X.520. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-zeilenga-ldapbis-strmatch-02.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. 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-zeilenga-ldapbis-strmatch-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-zeilenga-ldapbis-strmatch-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. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2003-3-7143812.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-zeilenga-ldapbis-strmatch-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-zeilenga-ldapbis-strmatch-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-3-7143812.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ Ldapext mailing list Ldapext@ietf.org https://www1.ietf.org/mailman/listinfo/ldapext From ldapext-admin@ietf.org Fri Mar 7 15:48:31 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA01323 for ; Fri, 7 Mar 2003 15:48:31 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h27Kx1O06824; Fri, 7 Mar 2003 15:59:01 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h27KjHO05679 for ; Fri, 7 Mar 2003 15:45:17 -0500 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA28571; Fri, 7 Mar 2003 15:33:06 -0500 (EST) Message-Id: <200303072033.PAA28571@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; CC: ldapext@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Date: Fri, 07 Mar 2003 15:33:06 -0500 Subject: [ldapext] I-D ACTION:draft-zeilenga-ldap-ext-03.txt Sender: ldapext-admin@ietf.org Errors-To: ldapext-admin@ietf.org X-BeenThere: ldapext@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: LDAP Extension Working Group List-Post: List-Help: List-Subscribe: , --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Considerations for LDAP Extensions Author(s) : K. Zeilenga Filename : draft-zeilenga-ldap-ext-03.txt Pages : 13 Date : 2003-3-7 The Lightweight Directory Access Protocol (LDAP) is extensible. It provides mechanisms for adding new operations, extending existing operations, and expanding system schema. This document discusses considerations for designers of LDAP extensions. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-zeilenga-ldap-ext-03.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. 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-zeilenga-ldap-ext-03.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-zeilenga-ldap-ext-03.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. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2003-3-7143646.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-zeilenga-ldap-ext-03.txt --OtherAccess Content-Type: Message/External-body; name="draft-zeilenga-ldap-ext-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-3-7143646.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ Ldapext mailing list Ldapext@ietf.org https://www1.ietf.org/mailman/listinfo/ldapext From ldapext-admin@ietf.org Fri Mar 7 15:48:47 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA01380 for ; Fri, 7 Mar 2003 15:48:47 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h27KxFO06897; Fri, 7 Mar 2003 15:59:15 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h27KkXO05731 for ; Fri, 7 Mar 2003 15:46:33 -0500 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA29037; Fri, 7 Mar 2003 15:34:22 -0500 (EST) Message-Id: <200303072034.PAA29037@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; CC: ldapext@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Date: Fri, 07 Mar 2003 15:34:22 -0500 Subject: [ldapext] I-D ACTION:draft-zeilenga-ldapbis-strmatch-02.txt Sender: ldapext-admin@ietf.org Errors-To: ldapext-admin@ietf.org X-BeenThere: ldapext@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: LDAP Extension Working Group List-Post: List-Help: List-Subscribe: , --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Internationalized String Matching Rules for X.500 Author(s) : K. Zeilenga Filename : draft-zeilenga-ldapbis-strmatch-02.txt Pages : 16 Date : 2003-3-7 The existing X.500 Directory Service technical specifications do not precisely define how string matching is to be performed. This has lead to a number of interoperability problems. This document provides string preparation profiles for standard syntaxes and matching rules defined in X.520. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-zeilenga-ldapbis-strmatch-02.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. 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-zeilenga-ldapbis-strmatch-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-zeilenga-ldapbis-strmatch-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. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2003-3-7152252.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-zeilenga-ldapbis-strmatch-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-zeilenga-ldapbis-strmatch-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-3-7152252.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ Ldapext mailing list Ldapext@ietf.org https://www1.ietf.org/mailman/listinfo/ldapext From ldapext-admin@ietf.org Tue Mar 18 14:56:05 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA26809 for ; Tue, 18 Mar 2003 14:56:05 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2IK9bO14235; Tue, 18 Mar 2003 15:09:37 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2IK0DO12957 for ; Tue, 18 Mar 2003 15:00:13 -0500 Received: from monster.redynet.com.ar (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA26408 for ; Tue, 18 Mar 2003 14:42:40 -0500 (EST) Received: (qmail 52439 invoked from network); 18 Mar 2003 19:54:18 -0000 Received: from unknown (HELO hch.com.ar) (smtp.hch@200.69.31.132) by monster.redynet.com.ar with SMTP; 18 Mar 2003 19:54:18 -0000 Message-ID: <3E777768.FBFFF2D6@hch.com.ar> Date: Tue, 18 Mar 2003 16:45:45 -0300 From: Hugo Roberto COLOMBO Reply-To: hugo@hch.com.ar X-Mailer: Mozilla 4.79 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: ldapext@ietf.org Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Content-Transfer-Encoding: 8bit Subject: [ldapext] I have a question. Sender: ldapext-admin@ietf.org Errors-To: ldapext-admin@ietf.org X-BeenThere: ldapext@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: LDAP Extension Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Dear Sir/Madame I`m facing a trouble when I want to look for a LDAP Group members names, I can`t search for it? If You have any advice o guideline IŽll be ver gratefull with You. from now Thank You. Hugo Roberto COLOMBO _______________________________________________ Ldapext mailing list Ldapext@ietf.org https://www1.ietf.org/mailman/listinfo/ldapext From ldapext-admin@ietf.org Tue Mar 18 15:13:34 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA28250 for ; Tue, 18 Mar 2003 15:13:34 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2IKR7O15184; Tue, 18 Mar 2003 15:27:07 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2IKQLO15108 for ; Tue, 18 Mar 2003 15:26:21 -0500 Received: from netscape.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA27574 for ; Tue, 18 Mar 2003 15:08:49 -0500 (EST) Received: from judge.mcom.com (judge.nscp.aoltw.net [10.169.8.47]) by netscape.com (8.10.0/8.10.0) with ESMTP id h2IKB2m05513 for ; Tue, 18 Mar 2003 12:11:02 -0800 (PST) Received: from netscape.com ([10.178.176.10]) by judge.mcom.com (Netscape Messaging Server 4.15) with ESMTP id HBYO2F01.DQW; Tue, 18 Mar 2003 12:11:03 -0800 Message-ID: <3E777D4E.9070201@netscape.com> Date: Tue, 18 Mar 2003 15:10:54 -0500 From: mcs@netscape.com (Mark C Smith) Organization: Netscape Communications Corp. User-Agent: Mozilla/5.0 (X11; U; SunOS sun4u; en-US; rv:1.3b) Gecko/20030211 X-Accept-Language: English/United States [en-US],English [en] MIME-Version: 1.0 To: hugo@hch.com.ar CC: ldapext@ietf.org Subject: Re: [ldapext] I have a question. References: <3E777768.FBFFF2D6@hch.com.ar> In-Reply-To: <3E777768.FBFFF2D6@hch.com.ar> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h2IKQMO15109 Sender: ldapext-admin@ietf.org Errors-To: ldapext-admin@ietf.org X-BeenThere: ldapext@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: LDAP Extension Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Hugo Roberto COLOMBO wrote: > Dear Sir/Madame > > > I`m facing a trouble when I want to look for a LDAP Group members > names, I can`t search for it? > If You have any advice o guideline IŽll be ver gratefull with You. > from now Thank You. > > Hugo Roberto COLOMBO The mailing list you posted to (ldapext@ietf.org) is for discussion of extensions to the LDAP standards. If your question is specific to one product, you should post your question to a product-specific mailing list. If not, you might try posting to the ldap@umich.edu list (which is a general LDAP related discussion list). But in any case you will need to provide more information about what you are trying to do before anyone will be able to help you. -- Mark Smith Netscape Directory Product Development My words are my own, not my employer's. _______________________________________________ Ldapext mailing list Ldapext@ietf.org https://www1.ietf.org/mailman/listinfo/ldapext From ldapext-admin@ietf.org Thu Mar 27 16:52:16 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA21101 for ; Thu, 27 Mar 2003 16:52:16 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2RMCeO26239; Thu, 27 Mar 2003 17:12:40 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2RMBjO26211 for ; Thu, 27 Mar 2003 17:11:45 -0500 Received: from netscape.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA21034 for ; Thu, 27 Mar 2003 16:49:45 -0500 (EST) Received: from judge.mcom.com (judge.nscp.aoltw.net [10.169.8.47]) by netscape.com (8.10.0/8.10.0) with ESMTP id h2RLq7n26968 for ; Thu, 27 Mar 2003 13:52:07 -0800 (PST) Received: from netscape.com ([10.169.192.79]) by judge.mcom.com (Netscape Messaging Server 4.15) with ESMTP id HCFGQU02.Q08 for ; Thu, 27 Mar 2003 13:52:06 -0800 Message-ID: <3E837286.90309@netscape.com> Date: Thu, 27 Mar 2003 16:52:06 -0500 From: mcs@netscape.com (Mark C Smith) Organization: Netscape Communications Corp. User-Agent: Mozilla/5.0 (X11; U; SunOS sun4u; en-US; rv:1.3b) Gecko/20030211 X-Accept-Language: English/United States [en-US],English [en] MIME-Version: 1.0 To: ldapext@ietf.org Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [ldapext] BER encoding of PasswordPolicyResponseValue? Sender: ldapext-admin@ietf.org Errors-To: ldapext-admin@ietf.org X-BeenThere: ldapext@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: LDAP Extension Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Someone asked me this week what the correct BER encoding is for a PasswordPolicyResponseValue (from http://www.ietf.org/internet-drafts/draft-behera-ldap-password-policy-06.txt). The ASN.1 from section 5.2 of the I-D is: PasswordPolicyResponseValue ::= SEQUENCE { warning [0] CHOICE OPTIONAL { timeBeforeExpiration [0] INTEGER (0 .. maxInt), graceLoginsRemaining [1] INTEGER (0 .. maxInt) } error [1] ENUMERATED OPTIONAL { passwordExpired (0), accountLocked (1), changeAfterReset (2), passwordModNotAllowed (3), mustSupplyOldPassword (4), invalidPasswordSyntax (5), passwordTooShort (6), passwordTooYoung (7), passwordInHistory (8) } } Notice that the warning element is both OPTIONAL (with a context specific tag of 0) and a CHOICE with embedded context specific tags (0 timeBeforeExpiration and 1 for graceLoginsRemaining). Normally, a CHOICE is encoded simply as whatever element as chosen, e.g., if timeBeforeExpiration is chosen one would just encode an INTEGER with a context specific primitive tag of 0. But the tag associated with the outer element (warning) also needs to be included so the decoder can tell that a warning element was included (remember, it is optional). What is the right way to encode this? One ASN.1 compiler I used encoded the warning element as a constructed element that contains one integer (which allows two tags to be encoded, one associated with the constructed/container element and one with the integer itself). Is that the right thing to do? Can any of the ASN.1 experts out there help? Thanks. -Mark Smith Netscape _______________________________________________ Ldapext mailing list Ldapext@ietf.org https://www1.ietf.org/mailman/listinfo/ldapext From ldapext-admin@ietf.org Thu Mar 27 19:34:57 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA28538 for ; Thu, 27 Mar 2003 19:34:57 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2S0tCO05888; Thu, 27 Mar 2003 19:55:14 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2S0sfO05849 for ; Thu, 27 Mar 2003 19:54:42 -0500 Received: from adacel.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA28491 for ; Thu, 27 Mar 2003 19:32:39 -0500 (EST) Received: from nexus.adacel.com (Not Verified[10.32.240.1]) by adacel.com with MailMarshal (v5,0,3,91) id ; Fri, 28 Mar 2003 11:33:54 +1100 Received: (qmail 4073 invoked from network); 28 Mar 2003 00:31:49 -0000 Received: from unknown (HELO osmium) (10.32.24.165) by nexus.adacel.com with SMTP; 28 Mar 2003 00:31:49 -0000 Reply-To: From: "Steven Legg" To: "'Mark C Smith'" , Subject: RE: [ldapext] BER encoding of PasswordPolicyResponseValue? Date: Fri, 28 Mar 2003 11:34:57 +1100 Message-ID: <002b01c2f4c1$dc978c20$a518200a@osmium.mtwav.adacel.com.au> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook 8.5, Build 4.71.2377.0 X-MimeOLE: Produced By Microsoft MimeOLE V4.72.2120.0 Importance: Normal In-Reply-To: <3E837286.90309@netscape.com> Content-Transfer-Encoding: 7bit Sender: ldapext-admin@ietf.org Errors-To: ldapext-admin@ietf.org X-BeenThere: ldapext@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: LDAP Extension Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Mark, Mark C Smith wrote: > Someone asked me this week what the correct BER encoding is for a > PasswordPolicyResponseValue (from > http://www.ietf.org/internet-drafts/draft-behera-ldap-password-policy-06.txt ). > > The ASN.1 from section 5.2 of the I-D is: > > PasswordPolicyResponseValue ::= SEQUENCE { > warning [0] CHOICE OPTIONAL { > timeBeforeExpiration [0] INTEGER (0 .. maxInt), > graceLoginsRemaining [1] INTEGER (0 .. maxInt) } > error [1] ENUMERATED OPTIONAL { > passwordExpired (0), > accountLocked (1), > changeAfterReset (2), > passwordModNotAllowed (3), > mustSupplyOldPassword (4), > invalidPasswordSyntax (5), > passwordTooShort (6), > passwordTooYoung (7), > passwordInHistory (8) } } First up, there are syntax errors in this type definition. It should read: PasswordPolicyResponseValue ::= SEQUENCE { warning [0] CHOICE { timeBeforeExpiration [0] INTEGER (0 .. maxInt), graceLoginsRemaining [1] INTEGER (0 .. maxInt) } OPTIONAL, error [1] ENUMERATED { passwordExpired (0), accountLocked (1), changeAfterReset (2), passwordModNotAllowed (3), mustSupplyOldPassword (4), invalidPasswordSyntax (5), passwordTooShort (6), passwordTooYoung (7), passwordInHistory (8) } OPTIONAL } > Notice that the warning element is both OPTIONAL (with a context > specific tag of 0) and a CHOICE with embedded context specific tags (0 > timeBeforeExpiration and 1 for graceLoginsRemaining). > Normally, a CHOICE > is encoded simply as whatever element as chosen, e.g., if > timeBeforeExpiration is chosen one would just encode an INTEGER with a > context specific primitive tag of 0. But the tag associated with the > outer element (warning) also needs to be included so the decoder can > tell that a warning element was included (remember, it is optional). > What is the right way to encode this? If the tag default is IMPLICIT TAGS then the encoding is as you've stated above. The implicit tagging suppresses the universal tag of the INTEGER, but there is no universal tag (or length) for CHOICE and implicit tagging never applies to a CHOICE. With IMPLICIT tags the warning element, when present, is encoded as [constructed 0] length [primitive 0] length integer-value-octets With EXPLICIT tags the warning element, when present, is encoded as [constructed 0] length [constructed 0] length [primitive UNIVERSAL 2] length integer-value-octets > One ASN.1 compiler I used encoded the warning element as a constructed > element that contains one integer (which allows two tags to > be encoded, > one associated with the constructed/container element and one with the > integer itself). Is that the right thing to do? Yes, if the tag default is IMPLICIT TAGS, though the draft doesn't say whether EXPLICIT or IMPLICIT tagging should apply. Regards, Steven > Can any of the ASN.1 > experts out there help? > > Thanks. > > -Mark Smith > Netscape > > > _______________________________________________ > Ldapext mailing list > Ldapext@ietf.org > https://www1.ietf.org/mailman/listinfo/ldapext > _______________________________________________ Ldapext mailing list Ldapext@ietf.org https://www1.ietf.org/mailman/listinfo/ldapext From ldapext-admin@ietf.org Thu Mar 27 19:50:26 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA29013 for ; Thu, 27 Mar 2003 19:50:26 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2S1B5O07591; Thu, 27 Mar 2003 20:11:05 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2S1AKO07551 for ; Thu, 27 Mar 2003 20:10:20 -0500 Received: from prv-mail20.provo.novell.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA28981 for ; Thu, 27 Mar 2003 19:48:17 -0500 (EST) Received: from INET-PRV-MTA by prv-mail20.provo.novell.com with Novell_GroupWise; Thu, 27 Mar 2003 17:50:38 -0700 Message-Id: X-Mailer: Novell GroupWise Internet Agent 6.5.0 Date: Thu, 27 Mar 2003 17:50:14 -0700 From: "Jim Sermersheim" To: , , Subject: RE: [ldapext] BER encoding of PasswordPolicyResponseValue? Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit Sender: ldapext-admin@ietf.org Errors-To: ldapext-admin@ietf.org X-BeenThere: ldapext@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: LDAP Extension Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Thanks Steven, Ludo or I will fix the ASN.1, and likely produce a normative appendix containing the full ASN.1, wherein we'll declare IMPLICIT TAGS. Jim >>> "Steven Legg" 3/27/03 5:34:57 PM >>> Mark, Mark C Smith wrote: > Someone asked me this week what the correct BER encoding is for a > PasswordPolicyResponseValue (from > http://www.ietf.org/internet-drafts/draft-behera-ldap-password-policy-06.txt ). > > The ASN.1 from section 5.2 of the I-D is: > > PasswordPolicyResponseValue ::= SEQUENCE { > warning [0] CHOICE OPTIONAL { > timeBeforeExpiration [0] INTEGER (0 .. maxInt), > graceLoginsRemaining [1] INTEGER (0 .. maxInt) } > error [1] ENUMERATED OPTIONAL { > passwordExpired (0), > accountLocked (1), > changeAfterReset (2), > passwordModNotAllowed (3), > mustSupplyOldPassword (4), > invalidPasswordSyntax (5), > passwordTooShort (6), > passwordTooYoung (7), > passwordInHistory (8) } } First up, there are syntax errors in this type definition. It should read: PasswordPolicyResponseValue ::= SEQUENCE { warning [0] CHOICE { timeBeforeExpiration [0] INTEGER (0 .. maxInt), graceLoginsRemaining [1] INTEGER (0 .. maxInt) } OPTIONAL, error [1] ENUMERATED { passwordExpired (0), accountLocked (1), changeAfterReset (2), passwordModNotAllowed (3), mustSupplyOldPassword (4), invalidPasswordSyntax (5), passwordTooShort (6), passwordTooYoung (7), passwordInHistory (8) } OPTIONAL } > Notice that the warning element is both OPTIONAL (with a context > specific tag of 0) and a CHOICE with embedded context specific tags (0 > timeBeforeExpiration and 1 for graceLoginsRemaining). > Normally, a CHOICE > is encoded simply as whatever element as chosen, e.g., if > timeBeforeExpiration is chosen one would just encode an INTEGER with a > context specific primitive tag of 0. But the tag associated with the > outer element (warning) also needs to be included so the decoder can > tell that a warning element was included (remember, it is optional). > What is the right way to encode this? If the tag default is IMPLICIT TAGS then the encoding is as you've stated above. The implicit tagging suppresses the universal tag of the INTEGER, but there is no universal tag (or length) for CHOICE and implicit tagging never applies to a CHOICE. With IMPLICIT tags the warning element, when present, is encoded as [constructed 0] length [primitive 0] length integer-value-octets With EXPLICIT tags the warning element, when present, is encoded as [constructed 0] length [constructed 0] length [primitive UNIVERSAL 2] length integer-value-octets > One ASN.1 compiler I used encoded the warning element as a constructed > element that contains one integer (which allows two tags to > be encoded, > one associated with the constructed/container element and one with the > integer itself). Is that the right thing to do? Yes, if the tag default is IMPLICIT TAGS, though the draft doesn't say whether EXPLICIT or IMPLICIT tagging should apply. Regards, Steven > Can any of the ASN.1 > experts out there help? > > Thanks. > > -Mark Smith > Netscape > > > _______________________________________________ > Ldapext mailing list > Ldapext@ietf.org > https://www1.ietf.org/mailman/listinfo/ldapext > _______________________________________________ Ldapext mailing list Ldapext@ietf.org https://www1.ietf.org/mailman/listinfo/ldapext _______________________________________________ Ldapext mailing list Ldapext@ietf.org https://www1.ietf.org/mailman/listinfo/ldapext From ldapext-admin@ietf.org Fri Mar 28 09:33:03 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA29720 for ; Fri, 28 Mar 2003 09:33:03 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2SErpO08788; Fri, 28 Mar 2003 09:53:51 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2SEqFO08707 for ; Fri, 28 Mar 2003 09:52:15 -0500 Received: from netscape.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA29591 for ; Fri, 28 Mar 2003 09:29:55 -0500 (EST) Received: from judge.mcom.com (judge.nscp.aoltw.net [10.169.8.47]) by netscape.com (8.10.0/8.10.0) with ESMTP id h2SEWGR27751 for ; Fri, 28 Mar 2003 06:32:16 -0800 (PST) Received: from netscape.com ([10.169.192.75]) by judge.mcom.com (Netscape Messaging Server 4.15) with ESMTP id HCGR1T02.S3R; Fri, 28 Mar 2003 06:32:17 -0800 Message-ID: <3E845CF0.2090406@netscape.com> Date: Fri, 28 Mar 2003 09:32:16 -0500 From: mcs@netscape.com (Mark C Smith) Organization: Netscape Communications Corp. User-Agent: Mozilla/5.0 (X11; U; SunOS sun4u; en-US; rv:1.3b) Gecko/20030211 X-Accept-Language: English/United States [en-US],English [en] MIME-Version: 1.0 To: steven.legg@adacel.com.au CC: ldapext@ietf.org Subject: Re: [ldapext] BER encoding of PasswordPolicyResponseValue? References: <002b01c2f4c1$dc978c20$a518200a@osmium.mtwav.adacel.com.au> In-Reply-To: <002b01c2f4c1$dc978c20$a518200a@osmium.mtwav.adacel.com.au> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: ldapext-admin@ietf.org Errors-To: ldapext-admin@ietf.org X-BeenThere: ldapext@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: LDAP Extension Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Thank you for your helpful response. One follow up question: in the absence of any indication, the default in ASN.1 is EXPLICIT tagging, right? I suspect many LDAP extension documents intend to use IMPLICIT (which for example is specified in Appendix A of RFC 2251) but that fact may not be mentioned. One example: http://www.ietf.org/internet-drafts/draft-ietf-ldapext-ldapv3-vlv-09.txt -Mark Steven Legg wrote: >Mark, > >Mark C Smith wrote: > > >>Someone asked me this week what the correct BER encoding is for a >>PasswordPolicyResponseValue (from >> >> >> >http://www.ietf.org/internet-drafts/draft-behera-ldap-password-policy-06.txt >). > > >>The ASN.1 from section 5.2 of the I-D is: >> >> PasswordPolicyResponseValue ::= SEQUENCE { >> warning [0] CHOICE OPTIONAL { >> timeBeforeExpiration [0] INTEGER (0 .. maxInt), >> graceLoginsRemaining [1] INTEGER (0 .. maxInt) } >> error [1] ENUMERATED OPTIONAL { >> passwordExpired (0), >> accountLocked (1), >> changeAfterReset (2), >> passwordModNotAllowed (3), >> mustSupplyOldPassword (4), >> invalidPasswordSyntax (5), >> passwordTooShort (6), >> passwordTooYoung (7), >> passwordInHistory (8) } } >> >> > >First up, there are syntax errors in this type definition. >It should read: > > PasswordPolicyResponseValue ::= SEQUENCE { > warning [0] CHOICE { > timeBeforeExpiration [0] INTEGER (0 .. maxInt), > graceLoginsRemaining [1] INTEGER (0 .. maxInt) } OPTIONAL, > error [1] ENUMERATED { > passwordExpired (0), > accountLocked (1), > changeAfterReset (2), > passwordModNotAllowed (3), > mustSupplyOldPassword (4), > invalidPasswordSyntax (5), > passwordTooShort (6), > passwordTooYoung (7), > passwordInHistory (8) } OPTIONAL } > > > > >>Notice that the warning element is both OPTIONAL (with a context >>specific tag of 0) and a CHOICE with embedded context specific tags (0 >>timeBeforeExpiration and 1 for graceLoginsRemaining). >>Normally, a CHOICE >>is encoded simply as whatever element as chosen, e.g., if >>timeBeforeExpiration is chosen one would just encode an INTEGER with a >>context specific primitive tag of 0. But the tag associated with the >>outer element (warning) also needs to be included so the decoder can >>tell that a warning element was included (remember, it is optional). >>What is the right way to encode this? >> >> > >If the tag default is IMPLICIT TAGS then the encoding is as >you've stated above. The implicit tagging suppresses the universal tag >of the INTEGER, but there is no universal tag (or length) for CHOICE >and implicit tagging never applies to a CHOICE. > >With IMPLICIT tags the warning element, when present, is encoded as > > [constructed 0] length [primitive 0] length integer-value-octets > >With EXPLICIT tags the warning element, when present, is encoded as > > [constructed 0] length [constructed 0] length > [primitive UNIVERSAL 2] length integer-value-octets > > > >>One ASN.1 compiler I used encoded the warning element as a constructed >>element that contains one integer (which allows two tags to >>be encoded, >>one associated with the constructed/container element and one with the >>integer itself). Is that the right thing to do? >> >> > >Yes, if the tag default is IMPLICIT TAGS, though the draft doesn't say >whether EXPLICIT or IMPLICIT tagging should apply. > >Regards, >Steven > _______________________________________________ Ldapext mailing list Ldapext@ietf.org https://www1.ietf.org/mailman/listinfo/ldapext From ldapext-admin@ietf.org Fri Mar 28 21:24:43 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA29135 for ; Fri, 28 Mar 2003 21:24:43 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2T2jXO29268; Fri, 28 Mar 2003 21:45:33 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2T2i6O29231 for ; Fri, 28 Mar 2003 21:44:06 -0500 Received: from prv-mail20.provo.novell.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA29090 for ; Fri, 28 Mar 2003 21:21:32 -0500 (EST) Received: from INET-PRV-MTA by prv-mail20.provo.novell.com with Novell_GroupWise; Fri, 28 Mar 2003 19:23:55 -0700 Message-Id: X-Mailer: Novell GroupWise Internet Agent 6.5.0 Date: Fri, 28 Mar 2003 19:23:27 -0700 From: "Jim Sermersheim" To: , Cc: Subject: Re: [ldapext] BER encoding of PasswordPolicyResponseValue? Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit Sender: ldapext-admin@ietf.org Errors-To: ldapext-admin@ietf.org X-BeenThere: ldapext@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: LDAP Extension Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit I bet you're right. (Now where is that LDAP extensions guidelines document...?) >>> Mark C Smith 3/28/03 7:32:16 AM >>> Thank you for your helpful response. One follow up question: in the absence of any indication, the default in ASN.1 is EXPLICIT tagging, right? I suspect many LDAP extension documents intend to use IMPLICIT (which for example is specified in Appendix A of RFC 2251) but that fact may not be mentioned. One example: http://www.ietf.org/internet-drafts/draft-ietf-ldapext-ldapv3-vlv-09.txt -Mark Steven Legg wrote: >Mark, > >Mark C Smith wrote: > > >>Someone asked me this week what the correct BER encoding is for a >>PasswordPolicyResponseValue (from >> >> >> >http://www.ietf.org/internet-drafts/draft-behera-ldap-password-policy-06.txt >). > > >>The ASN.1 from section 5.2 of the I-D is: >> >> PasswordPolicyResponseValue ::= SEQUENCE { >> warning [0] CHOICE OPTIONAL { >> timeBeforeExpiration [0] INTEGER (0 .. maxInt), >> graceLoginsRemaining [1] INTEGER (0 .. maxInt) } >> error [1] ENUMERATED OPTIONAL { >> passwordExpired (0), >> accountLocked (1), >> changeAfterReset (2), >> passwordModNotAllowed (3), >> mustSupplyOldPassword (4), >> invalidPasswordSyntax (5), >> passwordTooShort (6), >> passwordTooYoung (7), >> passwordInHistory (8) } } >> >> > >First up, there are syntax errors in this type definition. >It should read: > > PasswordPolicyResponseValue ::= SEQUENCE { > warning [0] CHOICE { > timeBeforeExpiration [0] INTEGER (0 .. maxInt), > graceLoginsRemaining [1] INTEGER (0 .. maxInt) } OPTIONAL, > error [1] ENUMERATED { > passwordExpired (0), > accountLocked (1), > changeAfterReset (2), > passwordModNotAllowed (3), > mustSupplyOldPassword (4), > invalidPasswordSyntax (5), > passwordTooShort (6), > passwordTooYoung (7), > passwordInHistory (8) } OPTIONAL } > > > > >>Notice that the warning element is both OPTIONAL (with a context >>specific tag of 0) and a CHOICE with embedded context specific tags (0 >>timeBeforeExpiration and 1 for graceLoginsRemaining). >>Normally, a CHOICE >>is encoded simply as whatever element as chosen, e.g., if >>timeBeforeExpiration is chosen one would just encode an INTEGER with a >>context specific primitive tag of 0. But the tag associated with the >>outer element (warning) also needs to be included so the decoder can >>tell that a warning element was included (remember, it is optional). >>What is the right way to encode this? >> >> > >If the tag default is IMPLICIT TAGS then the encoding is as >you've stated above. The implicit tagging suppresses the universal tag >of the INTEGER, but there is no universal tag (or length) for CHOICE >and implicit tagging never applies to a CHOICE. > >With IMPLICIT tags the warning element, when present, is encoded as > > [constructed 0] length [primitive 0] length integer-value-octets > >With EXPLICIT tags the warning element, when present, is encoded as > > [constructed 0] length [constructed 0] length > [primitive UNIVERSAL 2] length integer-value-octets > > > >>One ASN.1 compiler I used encoded the warning element as a constructed >>element that contains one integer (which allows two tags to >>be encoded, >>one associated with the constructed/container element and one with the >>integer itself). Is that the right thing to do? >> >> > >Yes, if the tag default is IMPLICIT TAGS, though the draft doesn't say >whether EXPLICIT or IMPLICIT tagging should apply. > >Regards, >Steven > _______________________________________________ Ldapext mailing list Ldapext@ietf.org https://www1.ietf.org/mailman/listinfo/ldapext _______________________________________________ Ldapext mailing list Ldapext@ietf.org https://www1.ietf.org/mailman/listinfo/ldapext From ldapext-admin@ietf.org Fri Mar 28 21:41:57 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA29415 for ; Fri, 28 Mar 2003 21:41:57 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2T325O29662; Fri, 28 Mar 2003 22:02:05 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2T31pO29647 for ; Fri, 28 Mar 2003 22:01:51 -0500 Received: from pretender.boolean.net (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA29367 for ; Fri, 28 Mar 2003 21:39:16 -0500 (EST) Received: from nomad.OpenLDAP.org (kurt@localhost [127.0.0.1]) by pretender.boolean.net (8.12.8/8.12.8) with ESMTP id h2T2fYBT008306; Sat, 29 Mar 2003 02:41:34 GMT (envelope-from Kurt@OpenLDAP.org) Message-Id: <5.2.0.9.0.20030328182539.02a4b100@127.0.0.1> X-Sender: kurt@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Date: Fri, 28 Mar 2003 18:39:30 -0800 To: "Jim Sermersheim" From: "Kurt D. Zeilenga" Subject: Re: [ldapext] BER encoding of PasswordPolicyResponseValue? Cc: , , In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: ldapext-admin@ietf.org Errors-To: ldapext-admin@ietf.org X-BeenThere: ldapext@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: LDAP Extension Working Group List-Post: List-Help: List-Subscribe: , At 06:23 PM 3/28/2003, Jim Sermersheim wrote: >I bet you're right. (Now where is that LDAP extensions guidelines >document...?) I can add something to draft-zeilenga-ldap-ext about this... but maybe it *might* be appropriate to cover this in the revision of Section 5.1 of RFC 2251. Loosely speaking, values of controls and extended operations are elements of LDAP and hence subject to Section 5.1 requirements. I suggest someone suggest some text to LDAPBIS. Alternatively (or maybe, additionally), this can be covered in draft-zeilenga-ldap-ext. I'd welcome text suggestions. Kurt >>>> Mark C Smith 3/28/03 7:32:16 AM >>> >Thank you for your helpful response. > >One follow up question: in the absence of any indication, the default >in >ASN.1 is EXPLICIT tagging, right? I suspect many LDAP extension >documents intend to use IMPLICIT (which for example is specified in >Appendix A of RFC 2251) but that fact may not be mentioned. One >example: > >http://www.ietf.org/internet-drafts/draft-ietf-ldapext-ldapv3-vlv-09.txt > > >-Mark > > >Steven Legg wrote: > >>Mark, >> >>Mark C Smith wrote: >> >> >>>Someone asked me this week what the correct BER encoding is for a >>>PasswordPolicyResponseValue (from >>> >>> >>> >>http://www.ietf.org/internet-drafts/draft-behera-ldap-password-policy-06.txt > >>). >> >> >>>The ASN.1 from section 5.2 of the I-D is: >>> >>> PasswordPolicyResponseValue ::= SEQUENCE { >>> warning [0] CHOICE OPTIONAL { >>> timeBeforeExpiration [0] INTEGER (0 .. maxInt), >>> graceLoginsRemaining [1] INTEGER (0 .. maxInt) } >>> error [1] ENUMERATED OPTIONAL { >>> passwordExpired (0), >>> accountLocked (1), >>> changeAfterReset (2), >>> passwordModNotAllowed (3), >>> mustSupplyOldPassword (4), >>> invalidPasswordSyntax (5), >>> passwordTooShort (6), >>> passwordTooYoung (7), >>> passwordInHistory (8) } } >>> >>> >> >>First up, there are syntax errors in this type definition. >>It should read: >> >> PasswordPolicyResponseValue ::= SEQUENCE { >> warning [0] CHOICE { >> timeBeforeExpiration [0] INTEGER (0 .. maxInt), >> graceLoginsRemaining [1] INTEGER (0 .. maxInt) } >OPTIONAL, >> error [1] ENUMERATED { >> passwordExpired (0), >> accountLocked (1), >> changeAfterReset (2), >> passwordModNotAllowed (3), >> mustSupplyOldPassword (4), >> invalidPasswordSyntax (5), >> passwordTooShort (6), >> passwordTooYoung (7), >> passwordInHistory (8) } OPTIONAL } >> >> >> >> >>>Notice that the warning element is both OPTIONAL (with a context >>>specific tag of 0) and a CHOICE with embedded context specific tags >(0 >>>timeBeforeExpiration and 1 for graceLoginsRemaining). >>>Normally, a CHOICE >>>is encoded simply as whatever element as chosen, e.g., if >>>timeBeforeExpiration is chosen one would just encode an INTEGER with >a >>>context specific primitive tag of 0. But the tag associated with the >>>outer element (warning) also needs to be included so the decoder can >>>tell that a warning element was included (remember, it is optional). >>>What is the right way to encode this? >>> >>> >> >>If the tag default is IMPLICIT TAGS then the encoding is as >>you've stated above. The implicit tagging suppresses the universal >tag >>of the INTEGER, but there is no universal tag (or length) for CHOICE >>and implicit tagging never applies to a CHOICE. >> >>With IMPLICIT tags the warning element, when present, is encoded as >> >> [constructed 0] length [primitive 0] length integer-value-octets >> >>With EXPLICIT tags the warning element, when present, is encoded as >> >> [constructed 0] length [constructed 0] length >> [primitive UNIVERSAL 2] length integer-value-octets >> >> >> >>>One ASN.1 compiler I used encoded the warning element as a >constructed >>>element that contains one integer (which allows two tags to >>>be encoded, >>>one associated with the constructed/container element and one with >the >>>integer itself). Is that the right thing to do? >>> >>> >> >>Yes, if the tag default is IMPLICIT TAGS, though the draft doesn't >say >>whether EXPLICIT or IMPLICIT tagging should apply. >> >>Regards, >>Steven >> > >_______________________________________________ >Ldapext mailing list >Ldapext@ietf.org >https://www1.ietf.org/mailman/listinfo/ldapext >_______________________________________________ >Ldapext mailing list >Ldapext@ietf.org >https://www1.ietf.org/mailman/listinfo/ldapext _______________________________________________ Ldapext mailing list Ldapext@ietf.org https://www1.ietf.org/mailman/listinfo/ldapext From ldapext-admin@ietf.org Sat Mar 29 01:51:05 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA03431 for ; Sat, 29 Mar 2003 01:51:05 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2T7CDO20853; Sat, 29 Mar 2003 02:12:13 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2T78FO15338 for ; Sat, 29 Mar 2003 02:08:15 -0500 Received: from prv-mail20.provo.novell.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA03230 for ; Sat, 29 Mar 2003 01:45:36 -0500 (EST) Received: from INET-PRV-MTA by prv-mail20.provo.novell.com with Novell_GroupWise; Fri, 28 Mar 2003 23:47:58 -0700 Message-Id: X-Mailer: Novell GroupWise Internet Agent 6.5.0 Date: Fri, 28 Mar 2003 23:47:32 -0700 From: "Jim Sermersheim" To: Cc: , , Subject: Re: [ldapext] BER encoding of PasswordPolicyResponseValue? Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit Sender: ldapext-admin@ietf.org Errors-To: ldapext-admin@ietf.org X-BeenThere: ldapext@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: LDAP Extension Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit I'd love to do this, but the fact is, values of controls and extended operations are OCTET STRING types. It's entirely up to the control or extended operation specification to define the format of the octets (4.1.11 and 4.12). I believe it would be inappropriate to say anything other than "if the control (or extended operation) specification defines the format of the control value using ASN.1, it SHOULD also specify that encoding be in accordance with the rules in 5.1". Even that, I feel is stretching things a bit. Otherwise the protocol begins to take on aspects of an extension guide. Jim >>> "Kurt D. Zeilenga" 3/28/03 7:39:30 PM >>> At 06:23 PM 3/28/2003, Jim Sermersheim wrote: >I bet you're right. (Now where is that LDAP extensions guidelines >document...?) I can add something to draft-zeilenga-ldap-ext about this... but maybe it *might* be appropriate to cover this in the revision of Section 5.1 of RFC 2251. Loosely speaking, values of controls and extended operations are elements of LDAP and hence subject to Section 5.1 requirements. I suggest someone suggest some text to LDAPBIS. Alternatively (or maybe, additionally), this can be covered in draft-zeilenga-ldap-ext. I'd welcome text suggestions. Kurt >>>> Mark C Smith 3/28/03 7:32:16 AM >>> >Thank you for your helpful response. > >One follow up question: in the absence of any indication, the default >in >ASN.1 is EXPLICIT tagging, right? I suspect many LDAP extension >documents intend to use IMPLICIT (which for example is specified in >Appendix A of RFC 2251) but that fact may not be mentioned. One >example: > >http://www.ietf.org/internet-drafts/draft-ietf-ldapext-ldapv3-vlv-09.txt > > >-Mark > > >Steven Legg wrote: > >>Mark, >> >>Mark C Smith wrote: >> >> >>>Someone asked me this week what the correct BER encoding is for a >>>PasswordPolicyResponseValue (from >>> >>> >>> >>http://www.ietf.org/internet-drafts/draft-behera-ldap-password-policy-06.txt > >>). >> >> >>>The ASN.1 from section 5.2 of the I-D is: >>> >>> PasswordPolicyResponseValue ::= SEQUENCE { >>> warning [0] CHOICE OPTIONAL { >>> timeBeforeExpiration [0] INTEGER (0 .. maxInt), >>> graceLoginsRemaining [1] INTEGER (0 .. maxInt) } >>> error [1] ENUMERATED OPTIONAL { >>> passwordExpired (0), >>> accountLocked (1), >>> changeAfterReset (2), >>> passwordModNotAllowed (3), >>> mustSupplyOldPassword (4), >>> invalidPasswordSyntax (5), >>> passwordTooShort (6), >>> passwordTooYoung (7), >>> passwordInHistory (8) } } >>> >>> >> >>First up, there are syntax errors in this type definition. >>It should read: >> >> PasswordPolicyResponseValue ::= SEQUENCE { >> warning [0] CHOICE { >> timeBeforeExpiration [0] INTEGER (0 .. maxInt), >> graceLoginsRemaining [1] INTEGER (0 .. maxInt) } >OPTIONAL, >> error [1] ENUMERATED { >> passwordExpired (0), >> accountLocked (1), >> changeAfterReset (2), >> passwordModNotAllowed (3), >> mustSupplyOldPassword (4), >> invalidPasswordSyntax (5), >> passwordTooShort (6), >> passwordTooYoung (7), >> passwordInHistory (8) } OPTIONAL } >> >> >> >> >>>Notice that the warning element is both OPTIONAL (with a context >>>specific tag of 0) and a CHOICE with embedded context specific tags >(0 >>>timeBeforeExpiration and 1 for graceLoginsRemaining). >>>Normally, a CHOICE >>>is encoded simply as whatever element as chosen, e.g., if >>>timeBeforeExpiration is chosen one would just encode an INTEGER with >a >>>context specific primitive tag of 0. But the tag associated with the >>>outer element (warning) also needs to be included so the decoder can >>>tell that a warning element was included (remember, it is optional). >>>What is the right way to encode this? >>> >>> >> >>If the tag default is IMPLICIT TAGS then the encoding is as >>you've stated above. The implicit tagging suppresses the universal >tag >>of the INTEGER, but there is no universal tag (or length) for CHOICE >>and implicit tagging never applies to a CHOICE. >> >>With IMPLICIT tags the warning element, when present, is encoded as >> >> [constructed 0] length [primitive 0] length integer-value-octets >> >>With EXPLICIT tags the warning element, when present, is encoded as >> >> [constructed 0] length [constructed 0] length >> [primitive UNIVERSAL 2] length integer-value-octets >> >> >> >>>One ASN.1 compiler I used encoded the warning element as a >constructed >>>element that contains one integer (which allows two tags to >>>be encoded, >>>one associated with the constructed/container element and one with >the >>>integer itself). Is that the right thing to do? >>> >>> >> >>Yes, if the tag default is IMPLICIT TAGS, though the draft doesn't >say >>whether EXPLICIT or IMPLICIT tagging should apply. >> >>Regards, >>Steven >> > >_______________________________________________ >Ldapext mailing list >Ldapext@ietf.org >https://www1.ietf.org/mailman/listinfo/ldapext >_______________________________________________ >Ldapext mailing list >Ldapext@ietf.org >https://www1.ietf.org/mailman/listinfo/ldapext _______________________________________________ Ldapext mailing list Ldapext@ietf.org https://www1.ietf.org/mailman/listinfo/ldapext From ldapext-admin@ietf.org Mon Mar 31 00:17:46 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA13840 for ; Mon, 31 Mar 2003 00:17:46 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2V5dUO26290; Mon, 31 Mar 2003 00:39:31 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2V5X7O25379 for ; Mon, 31 Mar 2003 00:33:07 -0500 Received: from prv-mail20.provo.novell.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA13684 for ; Mon, 31 Mar 2003 00:09:31 -0500 (EST) Received: from INET-PRV-MTA by prv-mail20.provo.novell.com with Novell_GroupWise; Sun, 30 Mar 2003 22:11:55 -0700 Message-Id: X-Mailer: Novell GroupWise Internet Agent 6.5.0 Date: Sun, 30 Mar 2003 22:11:20 -0700 From: "Jim Sermersheim" To: , Cc: , , Subject: RE: [ldapext] BER encoding of PasswordPolicyResponseValue? Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit Sender: ldapext-admin@ietf.org Errors-To: ldapext-admin@ietf.org X-BeenThere: ldapext@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: LDAP Extension Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit I agree, but I also note that there's not even a requirement for control values to be described using ASN.1. >>> "Ramsay, Ron" 3/30/03 9:14:04 PM >>> I think all ASN.1 for a control should be in the form of an ASN.1 module instead of just snippets of ASN.1. RFC 2251 does just this in an appendix. -----Original Message----- From: Jim Sermersheim [mailto:jimse@novell.com] Sent: Saturday, 29 March 2003 17:48 To: Kurt@OpenLDAP.org Cc: steven.legg@adacel.com.au; ldapext@ietf.org; mcs@netscape.com Subject: Re: [ldapext] BER encoding of PasswordPolicyResponseValue? I'd love to do this, but the fact is, values of controls and extended operations are OCTET STRING types. It's entirely up to the control or extended operation specification to define the format of the octets (4.1.11 and 4.12). I believe it would be inappropriate to say anything other than "if the control (or extended operation) specification defines the format of the control value using ASN.1, it SHOULD also specify that encoding be in accordance with the rules in 5.1". Even that, I feel is stretching things a bit. Otherwise the protocol begins to take on aspects of an extension guide. Jim >>> "Kurt D. Zeilenga" 3/28/03 7:39:30 PM >>> At 06:23 PM 3/28/2003, Jim Sermersheim wrote: >I bet you're right. (Now where is that LDAP extensions guidelines >document...?) I can add something to draft-zeilenga-ldap-ext about this... but maybe it *might* be appropriate to cover this in the revision of Section 5.1 of RFC 2251. Loosely speaking, values of controls and extended operations are elements of LDAP and hence subject to Section 5.1 requirements. I suggest someone suggest some text to LDAPBIS. Alternatively (or maybe, additionally), this can be covered in draft-zeilenga-ldap-ext. I'd welcome text suggestions. Kurt >>>> Mark C Smith 3/28/03 7:32:16 AM >>> >Thank you for your helpful response. > >One follow up question: in the absence of any indication, the default >in >ASN.1 is EXPLICIT tagging, right? I suspect many LDAP extension >documents intend to use IMPLICIT (which for example is specified in >Appendix A of RFC 2251) but that fact may not be mentioned. One >example: > >http://www.ietf.org/internet-drafts/draft-ietf-ldapext-ldapv3-vlv-09.txt > > >-Mark > > >Steven Legg wrote: > >>Mark, >> >>Mark C Smith wrote: >> >> >>>Someone asked me this week what the correct BER encoding is for a >>>PasswordPolicyResponseValue (from >>> >>> >>> >>http://www.ietf.org/internet-drafts/draft-behera-ldap-password-policy-06.txt > >>). >> >> >>>The ASN.1 from section 5.2 of the I-D is: >>> >>> PasswordPolicyResponseValue ::= SEQUENCE { >>> warning [0] CHOICE OPTIONAL { >>> timeBeforeExpiration [0] INTEGER (0 .. maxInt), >>> graceLoginsRemaining [1] INTEGER (0 .. maxInt) } >>> error [1] ENUMERATED OPTIONAL { >>> passwordExpired (0), >>> accountLocked (1), >>> changeAfterReset (2), >>> passwordModNotAllowed (3), >>> mustSupplyOldPassword (4), >>> invalidPasswordSyntax (5), >>> passwordTooShort (6), >>> passwordTooYoung (7), >>> passwordInHistory (8) } } >>> >>> >> >>First up, there are syntax errors in this type definition. >>It should read: >> >> PasswordPolicyResponseValue ::= SEQUENCE { >> warning [0] CHOICE { >> timeBeforeExpiration [0] INTEGER (0 .. maxInt), >> graceLoginsRemaining [1] INTEGER (0 .. maxInt) } >OPTIONAL, >> error [1] ENUMERATED { >> passwordExpired (0), >> accountLocked (1), >> changeAfterReset (2), >> passwordModNotAllowed (3), >> mustSupplyOldPassword (4), >> invalidPasswordSyntax (5), >> passwordTooShort (6), >> passwordTooYoung (7), >> passwordInHistory (8) } OPTIONAL } >> >> >> >> >>>Notice that the warning element is both OPTIONAL (with a context >>>specific tag of 0) and a CHOICE with embedded context specific tags >(0 >>>timeBeforeExpiration and 1 for graceLoginsRemaining). >>>Normally, a CHOICE >>>is encoded simply as whatever element as chosen, e.g., if >>>timeBeforeExpiration is chosen one would just encode an INTEGER with >a >>>context specific primitive tag of 0. But the tag associated with the >>>outer element (warning) also needs to be included so the decoder can >>>tell that a warning element was included (remember, it is optional). >>>What is the right way to encode this? >>> >>> >> >>If the tag default is IMPLICIT TAGS then the encoding is as >>you've stated above. The implicit tagging suppresses the universal >tag >>of the INTEGER, but there is no universal tag (or length) for CHOICE >>and implicit tagging never applies to a CHOICE. >> >>With IMPLICIT tags the warning element, when present, is encoded as >> >> [constructed 0] length [primitive 0] length integer-value-octets >> >>With EXPLICIT tags the warning element, when present, is encoded as >> >> [constructed 0] length [constructed 0] length >> [primitive UNIVERSAL 2] length integer-value-octets >> >> >> >>>One ASN.1 compiler I used encoded the warning element as a >constructed >>>element that contains one integer (which allows two tags to >>>be encoded, >>>one associated with the constructed/container element and one with >the >>>integer itself). Is that the right thing to do? >>> >>> >> >>Yes, if the tag default is IMPLICIT TAGS, though the draft doesn't >say >>whether EXPLICIT or IMPLICIT tagging should apply. >> >>Regards, >>Steven >> > >_______________________________________________ >Ldapext mailing list >Ldapext@ietf.org >https://www1.ietf.org/mailman/listinfo/ldapext >_______________________________________________ >Ldapext mailing list >Ldapext@ietf.org >https://www1.ietf.org/mailman/listinfo/ldapext _______________________________________________ Ldapext mailing list Ldapext@ietf.org https://www1.ietf.org/mailman/listinfo/ldapext _______________________________________________ Ldapext mailing list Ldapext@ietf.org https://www1.ietf.org/mailman/listinfo/ldapext From ldapext-admin@ietf.org Mon Mar 31 00:25:36 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA14033 for ; Mon, 31 Mar 2003 00:25:36 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2V5lhO26628; Mon, 31 Mar 2003 00:47:43 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2V5fsO26430 for ; Mon, 31 Mar 2003 00:41:54 -0500 Received: from adacel.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA13849 for ; Mon, 31 Mar 2003 00:18:17 -0500 (EST) Received: from nexus.adacel.com (Not Verified[10.32.240.1]) by adacel.com with MailMarshal (v5,0,3,91) id ; Mon, 31 Mar 2003 15:19:12 +1000 Received: (qmail 27089 invoked from network); 31 Mar 2003 05:17:08 -0000 Received: from unknown (HELO osmium) (10.32.24.165) by nexus.adacel.com with SMTP; 31 Mar 2003 05:17:08 -0000 Reply-To: From: "Steven Legg" To: "'Mark C Smith'" Cc: Subject: RE: [ldapext] BER encoding of PasswordPolicyResponseValue? Date: Mon, 31 Mar 2003 15:20:38 +1000 Message-ID: <002601c2f745$44c8ce50$a518200a@osmium.mtwav.adacel.com.au> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook 8.5, Build 4.71.2377.0 Importance: Normal In-Reply-To: <3E845CF0.2090406@netscape.com> X-MimeOLE: Produced By Microsoft MimeOLE V4.72.2120.0 Content-Transfer-Encoding: 7bit Sender: ldapext-admin@ietf.org Errors-To: ldapext-admin@ietf.org X-BeenThere: ldapext@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: LDAP Extension Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Mark, Mark C Smith wrote: > One follow up question: in the absence of any indication, the > default in > ASN.1 is EXPLICIT tagging, right? The default for a module definition with an empty TagDefault is EXPLICIT tagging, but for a fragment of ASN.1 that is not wrapped in a module definition no particular kind of tagging can be assumed. The ASN.1 standards don't recognize a standalone type definition as valid use of the notation. The tagging issue needs to be addressed by either providing a module definition, perhaps as a normative annex, or by an explicit statement in the specification. In theory we should also be saying something about the extensibility of any standalone ASN.1 type definition, but this only becomes a critical concern if PER is being used. X.500 has long had a presumption of extensibility. Regards, Steven > I suspect many LDAP extension > documents intend to use IMPLICIT (which for example is specified in > Appendix A of RFC 2251) but that fact may not be mentioned. > One example: > > http://www.ietf.org/internet-drafts/draft-ietf-ldapext-ldapv3- > vlv-09.txt > > -Mark > > > Steven Legg wrote: > > >Mark, > > > >Mark C Smith wrote: > > > > > >>Someone asked me this week what the correct BER encoding is for a > >>PasswordPolicyResponseValue (from > >> > >> > >> > >http://www.ietf.org/internet-drafts/draft-behera-ldap-passwor > d-policy-06.txt > >). > > > > > >>The ASN.1 from section 5.2 of the I-D is: > >> > >> PasswordPolicyResponseValue ::= SEQUENCE { > >> warning [0] CHOICE OPTIONAL { > >> timeBeforeExpiration [0] INTEGER (0 .. maxInt), > >> graceLoginsRemaining [1] INTEGER (0 .. maxInt) } > >> error [1] ENUMERATED OPTIONAL { > >> passwordExpired (0), > >> accountLocked (1), > >> changeAfterReset (2), > >> passwordModNotAllowed (3), > >> mustSupplyOldPassword (4), > >> invalidPasswordSyntax (5), > >> passwordTooShort (6), > >> passwordTooYoung (7), > >> passwordInHistory (8) } } > >> > >> > > > >First up, there are syntax errors in this type definition. > >It should read: > > > > PasswordPolicyResponseValue ::= SEQUENCE { > > warning [0] CHOICE { > > timeBeforeExpiration [0] INTEGER (0 .. maxInt), > > graceLoginsRemaining [1] INTEGER (0 .. maxInt) } > OPTIONAL, > > error [1] ENUMERATED { > > passwordExpired (0), > > accountLocked (1), > > changeAfterReset (2), > > passwordModNotAllowed (3), > > mustSupplyOldPassword (4), > > invalidPasswordSyntax (5), > > passwordTooShort (6), > > passwordTooYoung (7), > > passwordInHistory (8) } OPTIONAL } > > > > > > > > > >>Notice that the warning element is both OPTIONAL (with a context > >>specific tag of 0) and a CHOICE with embedded context > specific tags (0 > >>timeBeforeExpiration and 1 for graceLoginsRemaining). > >>Normally, a CHOICE > >>is encoded simply as whatever element as chosen, e.g., if > >>timeBeforeExpiration is chosen one would just encode an > INTEGER with a > >>context specific primitive tag of 0. But the tag associated with the > >>outer element (warning) also needs to be included so the decoder can > >>tell that a warning element was included (remember, it is optional). > >>What is the right way to encode this? > >> > >> > > > >If the tag default is IMPLICIT TAGS then the encoding is as > >you've stated above. The implicit tagging suppresses the > universal tag > >of the INTEGER, but there is no universal tag (or length) for CHOICE > >and implicit tagging never applies to a CHOICE. > > > >With IMPLICIT tags the warning element, when present, is encoded as > > > > [constructed 0] length [primitive 0] length integer-value-octets > > > >With EXPLICIT tags the warning element, when present, is encoded as > > > > [constructed 0] length [constructed 0] length > > [primitive UNIVERSAL 2] length integer-value-octets > > > > > > > >>One ASN.1 compiler I used encoded the warning element as a > constructed > >>element that contains one integer (which allows two tags to > >>be encoded, > >>one associated with the constructed/container element and > one with the > >>integer itself). Is that the right thing to do? > >> > >> > > > >Yes, if the tag default is IMPLICIT TAGS, though the draft > doesn't say > >whether EXPLICIT or IMPLICIT tagging should apply. > > > >Regards, > >Steven > > > > _______________________________________________ > Ldapext mailing list > Ldapext@ietf.org > https://www1.ietf.org/mailman/listinfo/ldapext > _______________________________________________ Ldapext mailing list Ldapext@ietf.org https://www1.ietf.org/mailman/listinfo/ldapext From ldapext-admin@ietf.org Mon Mar 31 01:05:52 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA14719 for ; Mon, 31 Mar 2003 01:05:51 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2V6OoO28735; Mon, 31 Mar 2003 01:24:50 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2V4ZDO21975 for ; Sun, 30 Mar 2003 23:35:13 -0500 Received: from ausyms50.ca.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA12560 for ; Sun, 30 Mar 2003 23:11:37 -0500 (EST) content-class: urn:content-classes:message Subject: RE: [ldapext] BER encoding of PasswordPolicyResponseValue? Date: Mon, 31 Mar 2003 14:14:04 +1000 MIME-Version: 1.0 Message-ID: Content-Type: text/plain; charset="iso-8859-1" X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 Thread-Topic: [ldapext] BER encoding of PasswordPolicyResponseValue? Thread-Index: AcL1v8Df1lukIQp6QHa8htBBrtrDTgBe7yoA From: "Ramsay, Ron" To: "Jim Sermersheim" , Cc: , , Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h2V4ZDO21976 Sender: ldapext-admin@ietf.org Errors-To: ldapext-admin@ietf.org X-BeenThere: ldapext@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: LDAP Extension Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit I think all ASN.1 for a control should be in the form of an ASN.1 module instead of just snippets of ASN.1. RFC 2251 does just this in an appendix. -----Original Message----- From: Jim Sermersheim [mailto:jimse@novell.com] Sent: Saturday, 29 March 2003 17:48 To: Kurt@OpenLDAP.org Cc: steven.legg@adacel.com.au; ldapext@ietf.org; mcs@netscape.com Subject: Re: [ldapext] BER encoding of PasswordPolicyResponseValue? I'd love to do this, but the fact is, values of controls and extended operations are OCTET STRING types. It's entirely up to the control or extended operation specification to define the format of the octets (4.1.11 and 4.12). I believe it would be inappropriate to say anything other than "if the control (or extended operation) specification defines the format of the control value using ASN.1, it SHOULD also specify that encoding be in accordance with the rules in 5.1". Even that, I feel is stretching things a bit. Otherwise the protocol begins to take on aspects of an extension guide. Jim >>> "Kurt D. Zeilenga" 3/28/03 7:39:30 PM >>> At 06:23 PM 3/28/2003, Jim Sermersheim wrote: >I bet you're right. (Now where is that LDAP extensions guidelines >document...?) I can add something to draft-zeilenga-ldap-ext about this... but maybe it *might* be appropriate to cover this in the revision of Section 5.1 of RFC 2251. Loosely speaking, values of controls and extended operations are elements of LDAP and hence subject to Section 5.1 requirements. I suggest someone suggest some text to LDAPBIS. Alternatively (or maybe, additionally), this can be covered in draft-zeilenga-ldap-ext. I'd welcome text suggestions. Kurt >>>> Mark C Smith 3/28/03 7:32:16 AM >>> >Thank you for your helpful response. > >One follow up question: in the absence of any indication, the default >in >ASN.1 is EXPLICIT tagging, right? I suspect many LDAP extension >documents intend to use IMPLICIT (which for example is specified in >Appendix A of RFC 2251) but that fact may not be mentioned. One >example: > >http://www.ietf.org/internet-drafts/draft-ietf-ldapext-ldapv3-vlv-09.txt > > >-Mark > > >Steven Legg wrote: > >>Mark, >> >>Mark C Smith wrote: >> >> >>>Someone asked me this week what the correct BER encoding is for a >>>PasswordPolicyResponseValue (from >>> >>> >>> >>http://www.ietf.org/internet-drafts/draft-behera-ldap-password-policy-06.txt > >>). >> >> >>>The ASN.1 from section 5.2 of the I-D is: >>> >>> PasswordPolicyResponseValue ::= SEQUENCE { >>> warning [0] CHOICE OPTIONAL { >>> timeBeforeExpiration [0] INTEGER (0 .. maxInt), >>> graceLoginsRemaining [1] INTEGER (0 .. maxInt) } >>> error [1] ENUMERATED OPTIONAL { >>> passwordExpired (0), >>> accountLocked (1), >>> changeAfterReset (2), >>> passwordModNotAllowed (3), >>> mustSupplyOldPassword (4), >>> invalidPasswordSyntax (5), >>> passwordTooShort (6), >>> passwordTooYoung (7), >>> passwordInHistory (8) } } >>> >>> >> >>First up, there are syntax errors in this type definition. >>It should read: >> >> PasswordPolicyResponseValue ::= SEQUENCE { >> warning [0] CHOICE { >> timeBeforeExpiration [0] INTEGER (0 .. maxInt), >> graceLoginsRemaining [1] INTEGER (0 .. maxInt) } >OPTIONAL, >> error [1] ENUMERATED { >> passwordExpired (0), >> accountLocked (1), >> changeAfterReset (2), >> passwordModNotAllowed (3), >> mustSupplyOldPassword (4), >> invalidPasswordSyntax (5), >> passwordTooShort (6), >> passwordTooYoung (7), >> passwordInHistory (8) } OPTIONAL } >> >> >> >> >>>Notice that the warning element is both OPTIONAL (with a context >>>specific tag of 0) and a CHOICE with embedded context specific tags >(0 >>>timeBeforeExpiration and 1 for graceLoginsRemaining). >>>Normally, a CHOICE >>>is encoded simply as whatever element as chosen, e.g., if >>>timeBeforeExpiration is chosen one would just encode an INTEGER with >a >>>context specific primitive tag of 0. But the tag associated with the >>>outer element (warning) also needs to be included so the decoder can >>>tell that a warning element was included (remember, it is optional). >>>What is the right way to encode this? >>> >>> >> >>If the tag default is IMPLICIT TAGS then the encoding is as >>you've stated above. The implicit tagging suppresses the universal >tag >>of the INTEGER, but there is no universal tag (or length) for CHOICE >>and implicit tagging never applies to a CHOICE. >> >>With IMPLICIT tags the warning element, when present, is encoded as >> >> [constructed 0] length [primitive 0] length integer-value-octets >> >>With EXPLICIT tags the warning element, when present, is encoded as >> >> [constructed 0] length [constructed 0] length >> [primitive UNIVERSAL 2] length integer-value-octets >> >> >> >>>One ASN.1 compiler I used encoded the warning element as a >constructed >>>element that contains one integer (which allows two tags to >>>be encoded, >>>one associated with the constructed/container element and one with >the >>>integer itself). Is that the right thing to do? >>> >>> >> >>Yes, if the tag default is IMPLICIT TAGS, though the draft doesn't >say >>whether EXPLICIT or IMPLICIT tagging should apply. >> >>Regards, >>Steven >> > >_______________________________________________ >Ldapext mailing list >Ldapext@ietf.org >https://www1.ietf.org/mailman/listinfo/ldapext >_______________________________________________ >Ldapext mailing list >Ldapext@ietf.org >https://www1.ietf.org/mailman/listinfo/ldapext _______________________________________________ Ldapext mailing list Ldapext@ietf.org https://www1.ietf.org/mailman/listinfo/ldapext _______________________________________________ Ldapext mailing list Ldapext@ietf.org https://www1.ietf.org/mailman/listinfo/ldapext From ldapext-admin@ietf.org Mon Mar 31 10:29:23 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA11235 for ; Mon, 31 Mar 2003 10:29:23 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2VFpPO12670; Mon, 31 Mar 2003 10:51:29 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2VFo7O12624 for ; Mon, 31 Mar 2003 10:50:07 -0500 Received: from netscape.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA11137 for ; Mon, 31 Mar 2003 10:26:17 -0500 (EST) Received: from judge.mcom.com (judge.nscp.aoltw.net [10.169.8.47]) by netscape.com (8.10.0/8.10.0) with ESMTP id h2VFSeR02837 for ; Mon, 31 Mar 2003 07:28:40 -0800 (PST) Received: from netscape.com ([10.178.168.45]) by judge.mcom.com (Netscape Messaging Server 4.15) with ESMTP id HCMDNT00.XA8; Mon, 31 Mar 2003 07:28:41 -0800 Message-ID: <3E885EA9.9010007@netscape.com> Date: Mon, 31 Mar 2003 10:28:41 -0500 From: mcs@netscape.com (Mark C Smith) User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.3) Gecko/20030312 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Jim Sermersheim CC: Kurt@openldap.org, steven.legg@adacel.com.au, ldapext@ietf.org Subject: Re: [ldapext] BER encoding of PasswordPolicyResponseValue? References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: ldapext-admin@ietf.org Errors-To: ldapext-admin@ietf.org X-BeenThere: ldapext@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: LDAP Extension Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Jim Sermersheim wrote: >I'd love to do this, but the fact is, values of controls and extended >operations are OCTET STRING types. It's entirely up to the control or >extended operation specification to define the format of the octets >(4.1.11 and 4.12). I believe it would be inappropriate to say anything >other than "if the control (or extended operation) specification defines >the format of the control value using ASN.1, it SHOULD also specify that >encoding be in accordance with the rules in 5.1". Even that, I feel is >stretching things a bit. Otherwise the protocol begins to take on >aspects of an extension guide. > I think a statement like you suggest that references section 5.1 would be a reasonable thing to add to the protocol document. I think it will do more harm than good to allow control authors to use different encoding approaches (but if someone can come up with a real world example where following 5.1 is unacceptable in a control, I will change my mind). I think current practice is to follow 5.1, but we just don't have that requirement written down anywhere. -Mark _______________________________________________ Ldapext mailing list Ldapext@ietf.org https://www1.ietf.org/mailman/listinfo/ldapext From ldapext-admin@ietf.org Mon Mar 31 10:48:43 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA12002 for ; Mon, 31 Mar 2003 10:48:43 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2VGB5O14814; Mon, 31 Mar 2003 11:11:05 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2VGA5O14726 for ; Mon, 31 Mar 2003 11:10:05 -0500 Received: from pretender.boolean.net (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA11860 for ; Mon, 31 Mar 2003 10:46:15 -0500 (EST) Received: from nomad.OpenLDAP.org (kurt@localhost [127.0.0.1]) by pretender.boolean.net (8.12.8/8.12.8) with ESMTP id h2VFmbBT028693; Mon, 31 Mar 2003 15:48:37 GMT (envelope-from Kurt@OpenLDAP.org) Message-Id: <5.2.0.9.0.20030331073512.01a49ff0@127.0.0.1> X-Sender: kurt@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Date: Mon, 31 Mar 2003 07:45:56 -0800 To: "Jim Sermersheim" From: "Kurt D. Zeilenga" Subject: Re: [ldapext] BER encoding of PasswordPolicyResponseValue? Cc: , , In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: ldapext-admin@ietf.org Errors-To: ldapext-admin@ietf.org X-BeenThere: ldapext@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: LDAP Extension Working Group List-Post: List-Help: List-Subscribe: , At 10:47 PM 3/28/2003, Jim Sermersheim wrote: >I'd love to do this, but the fact is, values of controls and extended >operations are OCTET STRING types. Yes, but as LDAP extensions are defining "LDAP protocol elements", I think it is reasonable to say that this SHALL apply to control and extended operation values which are described in term of ASN.1 and encoded using BER (as described in 5.1) unless the technical specification defining the LDAP protocol element explicitly states otherwise. I encourage extension authors to include to define the term BER-encoded as follows. Protocol elements are described using ASN.1 [X.680]. The term "BER-encoded" means the element is to be encoded using the Basic Encoding Rules [X.690] under the restrictions detailed in Section 5.1 of [RFC2251]. Kurt _______________________________________________ Ldapext mailing list Ldapext@ietf.org https://www1.ietf.org/mailman/listinfo/ldapext From ldapext-admin@ietf.org Mon Mar 31 11:47:54 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA13905 for ; Mon, 31 Mar 2003 11:47:54 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2VHA9T19640; Mon, 31 Mar 2003 12:10:09 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2VGKhO15503 for ; Mon, 31 Mar 2003 11:20:43 -0500 Received: from gate.ggr.co.uk (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA12196 for ; Mon, 31 Mar 2003 10:56:53 -0500 (EST) Received: (uucp@localhost) by gate.ggr.co.uk; Mon, 31 Mar 2003 17:02:13 +0100 (BST) Received: from uk-stv-mhub4.ggr.co.uk(147.184.2.4) by gb-stv-fw2.ggr.co.uk via smap (V5.5) id xma026697; Mon, 31 Mar 03 17:01:24 +0100 Received: from ukz1096.ggr.co.uk (ukz1096.ggr.co.uk [147.184.4.13]) by mailhub2.ggr.co.uk; Mon, 31 Mar 2003 16:58:30 +0100 (BST) Received: from 147.184.5.46 by ukz1096.ggr.co.uk with ESMTP (Tumbleweed MMS SMTP Relay (MMS v4.7)); Mon, 31 Mar 2003 16:58:31 +0100 X-Server-Uuid: a21d4586-8527-11d5-a7f9-0090279a6d0c Received: by ukz792.ggr.co.uk with Internet Mail Service (5.5.2654.89) id ; Mon, 31 Mar 2003 16:58:30 +0100 Message-ID: <91FDFD5BC5A0D3119785080009DC7CCF029310E6@it1msg04.italy.glaxo> From: "Voglmaier, Reinhard Erich" To: "'ldapext@ietf.org'" Date: Mon, 31 Mar 2003 16:58:20 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2654.89) X-WSS-ID: 1296BA2D209475-01-01 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [ldapext] Physician Object Class Sender: ldapext-admin@ietf.org Errors-To: ldapext-admin@ietf.org X-BeenThere: ldapext@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: LDAP Extension Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Dear All, I am currently working on porting a ldap database from a version installed on a very old openldap to a recent one. This ldap database should hold information about physicians subscribed to our web site. Since the old version used the slap.at.conf / slapd.oc.conf style configuration it did not require OID's. My job therefore is to understand how to extend an existing object class in order to have a physician object class. I think it would be handy to have such an object class available as standard. Therfore my question are: 1) somebody knows of such an object class just existing somewhere ? 2) is it worthwhile to invest efforts in standardization ? Thanx a lot for any advice Reinhard E. Voglmaier _______________________________________________ Ldapext mailing list Ldapext@ietf.org https://www1.ietf.org/mailman/listinfo/ldapext From ldapext-admin@ietf.org Mon Mar 31 19:50:37 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA04825 for ; Mon, 31 Mar 2003 19:50:37 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h311AWK01252; Mon, 31 Mar 2003 20:10:32 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3117XK01105 for ; Mon, 31 Mar 2003 20:07:33 -0500 Received: from prv-mail20.provo.novell.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA04623 for ; Mon, 31 Mar 2003 19:43:34 -0500 (EST) Received: from INET-PRV-MTA by prv-mail20.provo.novell.com with Novell_GroupWise; Mon, 31 Mar 2003 17:45:59 -0700 Message-Id: X-Mailer: Novell GroupWise Internet Agent 6.5.0 Date: Mon, 31 Mar 2003 17:45:23 -0700 From: "Jim Sermersheim" To: Cc: , , Subject: Re: [ldapext] BER encoding of PasswordPolicyResponseValue? Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit Sender: ldapext-admin@ietf.org Errors-To: ldapext-admin@ietf.org X-BeenThere: ldapext@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: LDAP Extension Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Ok, it seems that group consensus is moving in favor of this kind of wording, so let it be done. But.. my example used SHOULD, and this example uses SHALL (MUST). MUST may break some existing implementations. I'm willin g to use MUST/SHALL wording if group consensus agrees. Note also, that 5.1 in Protocol doesn't say anything about the extensibility of the ASN.1. It only talks about the BER encoding. Basically, I need to reconcile this between Sections 4 (Elements of Protocol), 4.1.11 (Controls), 4.12 (Extended Operations), and 5.1 (Protocol Encoding). Jim >>> "Kurt D. Zeilenga" 3/31/03 8:45:56 AM >>> At 10:47 PM 3/28/2003, Jim Sermersheim wrote: >I'd love to do this, but the fact is, values of controls and extended >operations are OCTET STRING types. Yes, but as LDAP extensions are defining "LDAP protocol elements", I think it is reasonable to say that this SHALL apply to control and extended operation values which are described in term of ASN.1 and encoded using BER (as described in 5.1) unless the technical specification defining the LDAP protocol element explicitly states otherwise. I encourage extension authors to include to define the term BER-encoded as follows. Protocol elements are described using ASN.1 [X.680]. The term "BER-encoded" means the element is to be encoded using the Basic Encoding Rules [X.690] under the restrictions detailed in Section 5.1 of [RFC2251]. Kurt _______________________________________________ Ldapext mailing list Ldapext@ietf.org https://www1.ietf.org/mailman/listinfo/ldapext From ldapext-admin@ietf.org Mon Mar 31 20:00:15 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA05138 for ; Mon, 31 Mar 2003 20:00:15 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h311K7K01662; Mon, 31 Mar 2003 20:20:07 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h311HeK01541 for ; Mon, 31 Mar 2003 20:17:40 -0500 Received: from pretender.boolean.net (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA04969 for ; Mon, 31 Mar 2003 19:53:40 -0500 (EST) Received: from nomad.OpenLDAP.org (kurt@localhost [127.0.0.1]) by pretender.boolean.net (8.12.8/8.12.8) with ESMTP id h310u1BT032611; Tue, 1 Apr 2003 00:56:01 GMT (envelope-from Kurt@OpenLDAP.org) Message-Id: <5.2.0.9.0.20030331165249.020eade8@127.0.0.1> X-Sender: kurt@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Date: Mon, 31 Mar 2003 16:53:33 -0800 To: "Jim Sermersheim" From: "Kurt D. Zeilenga" Subject: Re: [ldapext] BER encoding of PasswordPolicyResponseValue? Cc: , , In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: ldapext-admin@ietf.org Errors-To: ldapext-admin@ietf.org X-BeenThere: ldapext@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: LDAP Extension Working Group List-Post: List-Help: List-Subscribe: , Ee need to move this discussion to the LDAPBIS list for their consideration. Thanks, Kurt At 04:45 PM 3/31/2003, Jim Sermersheim wrote: >Ok, it seems that group consensus is moving in favor of this kind of >wording, so let it be done. But.. my example used SHOULD, and this >example uses SHALL (MUST). MUST may break some existing implementations. >I'm willin g to use MUST/SHALL wording if group consensus agrees. > >Note also, that 5.1 in Protocol doesn't say anything about the >extensibility of the ASN.1. It only talks about the BER encoding. >Basically, I need to reconcile this between Sections 4 (Elements of >Protocol), 4.1.11 (Controls), 4.12 (Extended Operations), and 5.1 >(Protocol Encoding). > >Jim > >>>> "Kurt D. Zeilenga" 3/31/03 8:45:56 AM >>> >At 10:47 PM 3/28/2003, Jim Sermersheim wrote: >>I'd love to do this, but the fact is, values of controls and extended >>operations are OCTET STRING types. > >Yes, but as LDAP extensions are defining "LDAP protocol elements", >I think it is reasonable to say that this SHALL apply to control and >extended operation values which are described in term of ASN.1 and >encoded using BER (as described in 5.1) unless the technical >specification defining the LDAP protocol element explicitly states >otherwise. > >I encourage extension authors to include to define the >term BER-encoded as follows. > Protocol elements are described using ASN.1 [X.680]. The term > "BER-encoded" means the element is to be encoded using the Basic > Encoding Rules [X.690] under the restrictions detailed in > Section 5.1 of [RFC2251]. > >Kurt > >_______________________________________________ >Ldapext mailing list >Ldapext@ietf.org >https://www1.ietf.org/mailman/listinfo/ldapext _______________________________________________ Ldapext mailing list Ldapext@ietf.org https://www1.ietf.org/mailman/listinfo/ldapext