From ldapext-admin@ietf.org Fri Feb 13 01:49:30 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA11588 for ; Fri, 13 Feb 2004 01:49:30 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ArX8H-0006TJ-74; Fri, 13 Feb 2004 01:49:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ArWb7-0003oF-BD for ldapext@optimus.ietf.org; Fri, 13 Feb 2004 01:14:45 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA10466 for ; Fri, 13 Feb 2004 01:14:41 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ArWb0-0003JK-00 for ldapext@ietf.org; Fri, 13 Feb 2004 01:14:38 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1ArWa1-0003Dv-00 for ldapext@ietf.org; Fri, 13 Feb 2004 01:13:38 -0500 Received: from gunsmoke.adacel.com.au ([210.11.130.7] helo=adacel.com) by ietf-mx with esmtp (Exim 4.12) id 1ArWZ3-000358-00 for ldapext@ietf.org; Fri, 13 Feb 2004 01:12:37 -0500 Received: from nexus.adacel.com (Not Verified[10.32.240.1]) by adacel.com with NetIQ MailMarshal (v5.5.5.9) id ; Fri, 13 Feb 2004 17:03:10 +1100 Received: (qmail 6305 invoked from network); 13 Feb 2004 06:12:05 -0000 Received: from unknown (HELO shylock) (10.32.24.166) by nexus.adacel.com with SMTP; 13 Feb 2004 06:12:05 -0000 Reply-To: From: "Andrew Sciberras" To: "'Bruce Bergeson'" Cc: "Ldapext $E-mail$" Subject: RE: [ldapext] draft-bergeson-uddi-ldap-schema-02.txt Date: Fri, 13 Feb 2004 17:12:03 +1100 Message-ID: <001c01c3f1f8$4d41b0c0$a618200a@mtwav.adacel.com.au> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_001D_01C3F254.80B228C0" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook 8.5, Build 4.71.2377.0 In-Reply-To: <~B000204a17.0020353c.mml.2196142817@prv-mail20.provo.novell.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Importance: Normal X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.4 required=5.0 tests=AWL,HTML_30_40,HTML_MESSAGE autolearn=no version=2.60 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: , This is a multi-part message in MIME format. ------=_NextPart_000_001D_01C3F254.80B228C0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Hi, > We have updated the draft http://www.ietf.org/internet-drafts/draft-bergeson-uddi-ldap-schema-02.txt > based on a round of initial reviews and we want to progress it to RFC status. > Before requesting the Area Director to initiate a last call, we wanted to see if anyone has any further feedback. >Bruce, Kent, and Vijay. So, do you plan to release an '03' version of this draft before requesting a last call? I guess I'm curious as to whether my comments (sent to the list on 19/12/03, see below) have been taken into consideration. Cheers, Andrew Sciberras Software Engineer Adacel Technologies Ltd 250 Bay Street Brighton t. 8530 7844 m. 0412 098 771 >G'Day, >Just some comments regarding 'LDAP Schema for UDDI'. >Section 5.2 >The equality matching rule for a distingushed name cannot be a >caseIgnoreMatch. >For the following attributes: >* uddiName >* uddiServiceKey >* uddiBindingKey >It is explicitly stated that the values of this attribute may not be blank. >The other attributes with a DirectoryString string syntax do not carry >this statement. I'm not sure what this is implying, but I feel that I should >note that none of the DirectoryString attributes are permitted to have a >blank value. >Section 5.17 >"When saving a new uddiBusinessService structure, pass an empty >uddiServiceKey value" >Section 5.18 >"When saving a new uddiBindingTemplate structure, pass an empty >uddiBindingKey value" >These would be strictly illegal since a DirectoryString must have at least >one character. >Section 5.41 >I don't think you intended to have a boolean syntax for this attribute >Since this attribute contains an integer, perhaps an Integer syntax with an >integerMatch equality rule would be more appropriate? >Section 5.43 >Purhaps a Boolean syntax with a booleanMatch would be more appropriate? >[RFC3377], [RFC2829], [RFC2830], are not listed in the Normative >References, but are present within the document. ------=_NextPart_000_001D_01C3F254.80B228C0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi,

> We have updated the = draft http://www.ietf.org/internet-drafts/draft-bergeson-uddi-ldap-s= chema-02.txt=20

> based on a round of = initial=20 reviews and we want to progress it to RFC status.

> Before requesting the = Area=20 Director to initiate a last call, we wanted to see if anyone has any = further=20 feedback.
>Bruce, Kent, and=20 Vijay.

So, do you plan to release an '03' = version=20 of this draft before requesting a last call?

I guess I'm curious as to whether = my=20 comments (sent to the list on 19/12/03, = see=20 below) have been taken into consideration.

Cheers,

Andrew=20 Sciberras &nbs= p;
Software=20 Engineer
Adacel Technologies Ltd
250 Bay Street Brighton
t. = 8530=20 7844
m. 0412 098 771

>G'Day,
>Just some comments regarding 'LDAP = Schema=20 for UDDI'.

>Section 5.2
>The equality matching rule for a=20 distingushed name cannot be a
>caseIgnoreMatch.

>For the following=20 attributes:
>* = uddiName
>* uddiServiceKey
>* uddiBindingKey

>It is explicitly stated = that the=20 values of this attribute may not be blank.
>The other attributes with a = DirectoryString=20 string syntax do not = carry
>this statement. I'm not sure what = this is=20 implying, but I feel that I should
>note that none of the = DirectoryString=20 attributes are permitted to have a
>blank value.

>Section 5.17
>"When saving a new = uddiBusinessService=20 structure, pass an empty
>uddiServiceKey value"
>Section 5.18
>"When saving a new = uddiBindingTemplate=20 structure, pass an empty
>uddiBindingKey value"
>These would be strictly illegal = since a=20 DirectoryString must have at least
>one character.

>Section 5.41
>I don't think you intended to have = a boolean=20 syntax for this attribute
>Since=20 this attribute contains an integer, perhaps an Integer syntax with = an
>integerMatch equality rule would = be more=20 appropriate?

>Section 5.43
>Purhaps a Boolean syntax with a = booleanMatch=20 would be more appropriate?

>[RFC3377], [RFC2829], = [RFC2830],=20 are not listed in the Normative
>References, but are present within = the=20 document.

------=_NextPart_000_001D_01C3F254.80B228C0-- _______________________________________________ Ldapext mailing list Ldapext@ietf.org https://www1.ietf.org/mailman/listinfo/ldapext From ldapext-admin@ietf.org Thu Feb 19 04:22:32 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA08289 for ; Thu, 19 Feb 2004 04:22:32 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AtkNd-0007lg-4V; Thu, 19 Feb 2004 04:22:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Atcul-0001wi-O4 for ldapext@optimus.ietf.org; Wed, 18 Feb 2004 20:23:46 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA05864 for ; Wed, 18 Feb 2004 20:23:41 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Atcuj-0007My-00 for ldapext@ietf.org; Wed, 18 Feb 2004 20:23:41 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Atctq-0007Ii-00 for ldapext@ietf.org; Wed, 18 Feb 2004 20:22:47 -0500 Received: from gunsmoke.adacel.com.au ([210.11.130.7] helo=adacel.com) by ietf-mx with esmtp (Exim 4.12) id 1Atcsu-0007AD-00 for ldapext@ietf.org; Wed, 18 Feb 2004 20:21:49 -0500 Received: from nexus.adacel.com (Not Verified[10.32.240.1]) by adacel.com with NetIQ MailMarshal (v5.5.5.9) id ; Thu, 19 Feb 2004 12:12:41 +1100 Received: (qmail 4008 invoked from network); 19 Feb 2004 01:21:16 -0000 Received: from unknown (HELO shylock) (10.32.24.166) by nexus.adacel.com with SMTP; 19 Feb 2004 01:21:16 -0000 Reply-To: From: "Andrew Sciberras" To: , , Cc: "Ldapext $E-mail$" Date: Thu, 19 Feb 2004 12:21:14 +1100 Message-ID: <038b01c3f686$ab87f350$a618200a@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 V6.00.2800.1165 Importance: Normal X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Subject: [ldapext] RE:draft-behera-ldap-password-policy-07.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: , Content-Transfer-Encoding: 7bit Just some comments regarding the draft: LDAP Ext mailing list's email address should be ldapext@ietf.org LDAP should be spelt out (ie. Lightweight Directory Access Protocol) before the acronym is used. There is no mention as what LDAP Version this applies to. Is it unusable for LDAPv2? or does that just eliminate the use of controls? Section 2.1 >The password policy defined in this document can be applied to any >attribute holding a user's password used for an authenticated LDAP >bind operation. Not limited to bind. Compare can be used for authenticating as well. >This policy is typically applied to the userPassword attribute in >the case of the LDAP simple authentication method [RFC-2251] or the >case of password based SASL [RFC-2222] authentication such as CRAM- >MD5 [RFC-2195] and HTTP-Digest [RFC-Digest]. Might need to be a little careful with the mention of HTTP-Digest. I'll just qualify this statement with the fact that I don't have too much knowledge of SASL or HTTP-Digest. That being said, I believe that it may be encouraged (or at least stated) that a digest of the username, realm and password could be stored instead of the password itself. I truly have no idea regarding the impact this has when a password policy is applied to this data, but weird things may happen. For example, a change in the realm, whilst retaining the same password, would result in a different hash. Effectively making the password policy think that the password has been changed and avoiding History restrictions. Length and Quality checking become unenforceable. Section 3.2 I would avoid referring to the userPassword attribute as the password policy is flexible enough to be applied to a variety of attributes. Section 4.3.1 >Since the password policy could apply to several attributes used to >store passwords, each of the above operational attributes must have >an option to specify which pwdAttribute is applies to. s/is/it/ Section 4.3.3, 6.1.1 A 0 value for generalizedTime is mentioned. This is impossible as 0 is not a valid value. We use 0000010100Z. Section 4.3.8 >This attribute holds a flag to indicate (when TRUE) that the >password has been reset and therefore must be changed by the user on >first authentication. In what way is it restricted to the first authentication? Practically, following the instructions for a bind operation, a person could bind many times without ever changing their password. Section 5. Add the following statement, or something similar: "Servers implementing the Password Policy controls SHOULD publish 1.3.6.1.4.1.42.2.27.8.5.1 as a value of 'supportedControl' [RFC2252] in their root DSE." Section 5.1 >The controlType is 1.3.6.1.4.1.42.2.27.8.5.1 and the criticality >MUST be FALSE. There is no controlValue. Why must the criticality be false? Suppose I would like to set up my clients to only perform LDAP operations against directories that recognise the LDAP Password Policy control. To do this, I would send my LDAP Request with a Password Policy control and set the criticality to TRUE. Therefore, my clients will only have their operations processed if the directory recognises the password policy control. Alternatively, one could just check the directory's supportedControl to identify if the password policy control is supported. I fully recognise that the intention of the control is to make the server aware that the client is able to handle a response control, but I still think that the criticality of the control should be left upto the client. Section 5.2 >PasswordPolicyResponseValue ::= SEQUENCE { > warning [0] CHOICE { > timeBeforeExpiration [0] INTEGER (0 .. maxInt), > graceLoginsRemaining [1] INTEGER (0 .. maxInt) } OPTIONAL > error [1] ENUMERATED { Your missing a comma after OPTIONAL. > insufficientPasswordQuality (5), >The insufficientPasswordQuality error is set when a >password doesn't pass quality checking. Just as an aside, the encodings from BER (and DER, PER, etc.) remain the same even though the name of the enumerated choice has changed. However, the encoded data from XML based encoding rules (RXER (XED) and XER (ITU)) will be different after such a name change is made. Section 6. >The server SHOULD enforce that the password attribute subject to a >password policy as defined in this document, contains one and only >one password value. How do you suggest that the server enforce such a rule? Throw away additional values? Return an unwillingToPerform error on modifications that will result in multiple password values? Section 6.1.2B Page 17 >The server MUST then disallow all operations issued by this >user except modify password, bind, unbind, abandon and >StartTLS extended operation. Compare? Section 6.1.2D Page 18 and 6.4.2C >If the pwdExpirationWarned attribute is present and has a >time value, the warning time is the value of the >pwdExpirationWarned attribute plus the value of the >pwdExpireWarning attribute minus the current time. WarningTime = pwdExpirationWarned + pwdExpireWarning - Current Time >If the pwdExpirationWarned attribute is not present, the >server MUST subtract the current time from the time stored >in pwdChangedTime to arrive at the password's age. If the >age is greater than the value of the pwdMaxAge attribute >minus the value of the pwdExpireWarning attribute, the >server MUST set the current time as the value of the >pwdExpirationWarned attribute, and the warning time is the >value of pwdMaxAge minus the password's age. PasswordAge = pwdChangeTime - CurrentTime WarningTime = pwdMaxAge - PasswordAge Firstly, I believe that the calculation of the PasswordAge is incorrect. I think that the pwdChangeTime should be subtracted from the current time. Following the warning time calculation steps described in the draft can also lead to misleading results. The example below will illustrate a scenario where this is the case. pwdMaxAge = 100 seconds. pwdExpireWarning = 50 seconds. The user binds when the password is 80 seconds old. PasswordAge = 80. WarningTime = (pwdMaxAge - PasswordAge) = 20 seconds. At this stage the user has been told that their password will expire in 20 seconds. User binds again in 5 seconds time. (I.e. PasswordAge = 85 seconds). Since the pwdExpirationWarned is now present we calculate the warning time differently. WarningTime = (pwdExpirationWarned + pwdExpireWarning - CurrentTime) = (pwdExpirationWarned - CurrentTime) + pwdExpireWarning = (-5) + 50 = 45 The user is now told that their password will expire in 45 seconds. Our implementation of the password policy will simply return pwdExpireWarning as the first warning time value. Section 6.1.2B (Page 20) >If the number of these failures is greater or equal to the >pwdMaxFailure attribute, the server MUST lock the account >by setting the value of the pwdAccountLockedTime attribute >to the current time. After locking the account, the server >MUST send a bindResponse to the client with the >resultCode: unwillingToPerform (53), and MUST include the >passwordPolicyResponse in the controls field of the >bindResponse message with the error: accountLocked (1). I do not think that the return code should be unwillingToPerform. In this scenario, the user has got their password wrong and this incorrect attempt has made the number of failures exceed the pwdMaxFailure limit. In this case the reason why the operation (BIND) is going to fail is because of the incorrect password. The fact that the number of bind failures has exceeded a policy limit is just a consequence of that. For this reason I believe that the resultCode should be invalidCredentials. Section 6.2.9 If an administrator is modifying the password then we should not remove the pwdReset attribute. This scenario is likely, because the definition that you provide in Section 3.2 states that: "In this document, the term "modify password operation" refers to any operation that is used to add or modify a password attribute." The description provides no constraints on who is performing the modify password operation. Section 6.3.2B >If the server is unable to check the length (due to a hashed >password or otherwise), the value of pwdCheckSyntax MUST be >evaluated. If the value is 1, operation MUST continue. If the >value is 2, the server MUST send an addResponse to the client >with the resultCode: constraintViolation (19), and MUST >include the passwordPolicyResponse in the controls field of >the addResponse message with the error: passwordTooShort (5). A passwordTooShort error code here seems inappropriate. Since the server could not determine the length due to the syntax of the password wouldn't it be more appropriate to use a invalidPasswordQuality error code. Section 6.3 You need a Step 4. Set the pwdReset value to TRUE. Section 6.4.2A How about removing the pwdAccountLockedTime attribute in the doc somewhere? I think that sections 6.4.2A and 6.1.2A are prime locations. Section 6.4.2D >If the result of the compare operation is false, the server MUST >do the following: >D. If no errors were returned, the server MUST send a >compareResponse with the resultCode: compareTrue (6), and >MUST include the passwordPolicyResponse with nothing in >the SEQUENCE. Section D above is related to the fact that the compare was false. The server should therefore return compareFalse. 7.1.2. >The user is binding for the first time after the directory >administrator set the password. In this scenario, the client >SHOULD prompt the user to change his password immediately. > >resultCode: success (0) >passwordPolicyResponse: error: changeAfterReset (2) This scenario will occur for every single bind until the password has been changed. Section 7.5 >For operations other than bind, unbind, abandon, search or StartTLS, >the client MUST check the following result code and control to >determine if the user needs to change the password immediately. I don't think that search should be in there. Section 8 An administrativeRole operational attribute (as defined in RFC36720) must be specified for the password policy. I also think that this draft should contain a 'Known Limitation'(or similar) section. A few things off the top of my head: * Password Attribute must only contain one value * No consideration for password attributes with options Eg, if I have the attributes userPassword;x-unix and userPassword;x-windows with different passwords for different reasons. How do I set up individual policies? * Password policy cannot be applied to X.500 attributes whose syntax don't have an LDAP specific encoding. Cheers, Andrew Sciberras Software Engineer Adacel Technologies Ltd _______________________________________________ Ldapext mailing list Ldapext@ietf.org https://www1.ietf.org/mailman/listinfo/ldapext From ldapext-admin@ietf.org Thu Feb 19 09:44:32 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA20611 for ; Thu, 19 Feb 2004 09:44:32 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AtpPF-0003i5-C6; Thu, 19 Feb 2004 09:44:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AtpOU-0003cO-84 for ldapext@optimus.ietf.org; Thu, 19 Feb 2004 09:43:14 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA20562 for ; Thu, 19 Feb 2004 09:43:11 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AtpOS-0000Ka-00 for ldapext@ietf.org; Thu, 19 Feb 2004 09:43:12 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AtpNZ-0000Go-00 for ldapext@ietf.org; Thu, 19 Feb 2004 09:42:17 -0500 Received: from e5.ny.us.ibm.com ([32.97.182.105]) by ietf-mx with esmtp (Exim 4.12) id 1AtpMf-00009T-00 for ldapext@ietf.org; Thu, 19 Feb 2004 09:41:21 -0500 Received: from northrelay04.pok.ibm.com (northrelay04.pok.ibm.com [9.56.224.206]) by e5.ny.us.ibm.com (8.12.10/8.12.2) with ESMTP id i1JEefJr450650; Thu, 19 Feb 2004 09:40:41 -0500 Received: from d27ml001.rchland.ibm.com (d01av04.pok.ibm.com [9.56.224.64]) by northrelay04.pok.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id i1JEeeJk055588; Thu, 19 Feb 2004 09:40:41 -0500 In-Reply-To: <038b01c3f686$ab87f350$a618200a@mtwav.adacel.com.au> Subject: Re: [ldapext] RE:draft-behera-ldap-password-policy-07.txt To: jimse@novell.com, ludovic.poitou@sun.com, prasantabehera@yahoo.com Cc: "Ldapext $E-mail$" X-Mailer: Lotus Notes Release 6.0.2CF1 June 9, 2003 Message-ID: From: John McMeeking Date: Thu, 19 Feb 2004 08:40:32 -0600 X-MIMETrack: Serialize by Router on d27ml001/27/M/IBM(Release 6.5.1|January 21, 2004) at 02/19/2004 08:40:35 AM MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 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: , wrote on 02/18/2004 07:21:14 PM: > Just some comments regarding the draft: > Section 5.1 > >The controlType is 1.3.6.1.4.1.42.2.27.8.5.1 and the criticality > >MUST be FALSE. There is no controlValue. > Why must the criticality be false? > Suppose I would like to set up my clients to only perform LDAP operations > against directories that recognise the LDAP Password Policy control. To do > this, I would send my LDAP Request with a Password Policy control and set > the criticality to TRUE. Therefore, my clients will only have their > operations processed if the directory recognises the password policy > control. > Alternatively, one could just check the directory's supportedControl to > identify if the password policy control is supported. > I fully recognise that the intention of the control is to make the server > aware that the client is able to handle a response control, but I still > think that the criticality of the control should be left upto the client. Following the discussions related to control criticality in ldapbis, I think this document should only contain recommendations for criticality. It might be appropriate to say that if the client is intended to interoperate with servers that do not support password policy, it is recommended that the control criticality be FALSE. > > Section 6.1.2B Page 17 > >The server MUST then disallow all operations issued by this > >user except modify password, bind, unbind, abandon and > >StartTLS extended operation. > Compare? Not compare. I think the intent is to allow operations needed by the user to change his password. Compare is used by other applications (not under the user's identity) to authenticate a user to the application. > Section 6.2.9 > If an administrator is modifying the password then we should not remove the > pwdReset attribute. > This scenario is likely, because the definition that you provide in Section > 3.2 states that: > "In this document, the term "modify password operation" refers to any > operation that is used to add or modify a password attribute." > The description provides no constraints on who is performing the modify > password operation. There are cases where password changes are processed through an applicatiuon that runs under some administrative identity; the user does not have authority to change his entry directly. I believe password policy should still apply in such cases and behave much like the user was changing his own password. It is possible that such changes could be "safe" changes. Since we can get to step 9 in lots of ways, the pwdreset processing needs to be expanded: If the password change is a safe modify, the pwdreset attribute is removed. If the password is changed by an administrator, the pwdreset attribute is set according to the "password change after reset policy": pwdreset is set to TRUE if this policy is in effect, and removed if this policy is not in effect. > Section 7.5 > >For operations other than bind, unbind, abandon, search or StartTLS, > >the client MUST check the following result code and control to > >determine if the user needs to change the password immediately. > > I don't think that search should be in there. And I would expect that the client SHOULD check the result code and control for the bind operation. > Cheers, > > Andrew Sciberras > Software Engineer > Adacel Technologies Ltd > > > _______________________________________________ > Ldapext mailing list > Ldapext@ietf.org > https://www1.ietf.org/mailman/listinfo/ldapext John McMeeking _______________________________________________ Ldapext mailing list Ldapext@ietf.org https://www1.ietf.org/mailman/listinfo/ldapext From ldapext-admin@ietf.org Thu Feb 19 10:07:28 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA21812 for ; Thu, 19 Feb 2004 10:07:28 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AtplU-0000Df-OC; Thu, 19 Feb 2004 10:07:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Atpkm-0008T8-Sz for ldapext@optimus.ietf.org; Thu, 19 Feb 2004 10:06:17 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA21678 for ; Thu, 19 Feb 2004 10:06:13 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Atpkk-0001c3-00 for ldapext@ietf.org; Thu, 19 Feb 2004 10:06:14 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Atpjn-0001Xy-00 for ldapext@ietf.org; Thu, 19 Feb 2004 10:05:17 -0500 Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by ietf-mx with esmtp (Exim 4.12) id 1Atpil-0001Sx-00 for ldapext@ietf.org; Thu, 19 Feb 2004 10:04:11 -0500 Received: from odin.France.Sun.COM ([129.157.174.8]) by nwkea-mail-2.sun.com (8.12.10/8.12.9) with ESMTP id i1JF3ZdO017311; Thu, 19 Feb 2004 07:03:36 -0800 (PST) Received: from Sun.COM (dhcp-gnb07-211-108 [129.157.211.108]) by odin.France.Sun.COM (8.11.7p1+Sun/8.10.2/ENSMAIL,v2.2) with ESMTP id i1JF3ZP14794; Thu, 19 Feb 2004 16:03:35 +0100 (MET) Message-ID: <4034D010.9010308@Sun.COM> Date: Thu, 19 Feb 2004 16:02:40 +0100 From: Ludovic Poitou Organization: SUN Microsystems User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en-us, en MIME-Version: 1.0 To: andrew.sciberras@adacel.com CC: prasantabehera@yahoo.com, jimse@novell.com, "Ldapext (E-mail)" References: <038b01c3f686$ab87f350$a618200a@mtwav.adacel.com.au> In-Reply-To: <038b01c3f686$ab87f350$a618200a@mtwav.adacel.com.au> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Subject: [ldapext] Re: draft-behera-ldap-password-policy-07.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: , Content-Transfer-Encoding: 7bit Andrew, Thanks for your comments. See some answers inlined... Andrew Sciberras wrote: >Just some comments regarding the draft: > > >LDAP Ext mailing list's email address should be ldapext@ietf.org > > > Fixed >LDAP should be spelt out (ie. Lightweight Directory Access Protocol) before >the acronym is used. > > > Ok >There is no mention as what LDAP Version this applies to. Is it unusable for >LDAPv2? or does that just eliminate the use of controls? > > > I'll add a clarification but LDAPv2 has been moved to Historical status... >Section 2.1 > > >>The password policy defined in this document can be applied to any >>attribute holding a user's password used for an authenticated LDAP >>bind operation. >> >> > >Not limited to bind. Compare can be used for authenticating as well. > > > >>This policy is typically applied to the userPassword attribute in >>the case of the LDAP simple authentication method [RFC-2251] or the >>case of password based SASL [RFC-2222] authentication such as CRAM- >>MD5 [RFC-2195] and HTTP-Digest [RFC-Digest]. >> >> >Might need to be a little careful with the mention of HTTP-Digest. > > The term HTTP-Digest has been replaced by DIGEST-MD5 in the -07 draft... >I'll just qualify this statement with the fact that I don't have too much >knowledge of SASL or HTTP-Digest. >That being said, I believe that it may be encouraged (or at least stated) >that a digest of the username, realm and password could be stored instead of >the password itself. >I truly have no idea regarding the impact this has when a password policy is >applied to this data, but weird things may happen. >For example, a change in the realm, whilst retaining the same password, >would result in a different hash. Effectively making the password policy >think that the password has been changed and avoiding History restrictions. >Length and Quality checking become unenforceable. > > > I agree. Note that changing the realm for the server will invalidate ALL passwords, which make the use of the digest instead of the password undeployable. >Section 3.2 >I would avoid referring to the userPassword attribute as the password policy >is flexible enough to be applied to a variety of attributes. > > > Ok. >Section 4.3.1 > > >>Since the password policy could apply to several attributes used to >>store passwords, each of the above operational attributes must have >>an option to specify which pwdAttribute is applies to. >> >> >s/is/it/ > > > ok. >Section 4.3.3, 6.1.1 >A 0 value for generalizedTime is mentioned. This is impossible as 0 is not a >valid value. >We use 0000010100Z. > > Nice catch. We use 000001010000Z which is another representation of the same value. I'll change the wording to specific the generalizedTime 1st of Jan 0000, 00h00mn and give a representation of the value. > >Section 4.3.8 > > >>This attribute holds a flag to indicate (when TRUE) that the >>password has been reset and therefore must be changed by the user on >>first authentication. >> >> >In what way is it restricted to the first authentication? Practically, >following the instructions for a bind operation, a person could bind many >times without ever changing their password. > >Section 5. >Add the following statement, or something similar: >"Servers implementing the Password Policy controls SHOULD publish >1.3.6.1.4.1.42.2.27.8.5.1 as a value of 'supportedControl' [RFC2252] in >their root DSE." > > > Added to section 5.1. >Section 5.1 > > >>The controlType is 1.3.6.1.4.1.42.2.27.8.5.1 and the criticality >>MUST be FALSE. There is no controlValue. >> >> >Why must the criticality be false? >Suppose I would like to set up my clients to only perform LDAP operations >against directories that recognise the LDAP Password Policy control. To do >this, I would send my LDAP Request with a Password Policy control and set >the criticality to TRUE. Therefore, my clients will only have their >operations processed if the directory recognises the password policy >control. >Alternatively, one could just check the directory's supportedControl to >identify if the password policy control is supported. >I fully recognise that the intention of the control is to make the server >aware that the client is able to handle a response control, but I still >think that the criticality of the control should be left upto the client. > > > This is a valid requirement. I've changed the criticality to be TRUE or FALSE and removed the MUST. >Section 5.2 > > >>PasswordPolicyResponseValue ::= SEQUENCE { >>warning [0] CHOICE { >> timeBeforeExpiration [0] INTEGER (0 .. maxInt), >> graceLoginsRemaining [1] INTEGER (0 .. maxInt) } OPTIONAL >>error [1] ENUMERATED { >> >> > >Your missing a comma after OPTIONAL. > > > ok >> insufficientPasswordQuality (5), >>The insufficientPasswordQuality error is set when a >>password doesn't pass quality checking. >> >> > >Just as an aside, the encodings from BER (and DER, PER, etc.) remain the >same even though the name of the enumerated choice has changed. However, the >encoded data from XML based encoding rules (RXER (XED) and XER (ITU)) will >be different after such a name change is made. > > > Yes, but these password policy are internet-drafts, and thus subject to changes... >Section 6. > > >>The server SHOULD enforce that the password attribute subject to a >>password policy as defined in this document, contains one and only >>one password value. >> >> >How do you suggest that the server enforce such a rule? Throw away >additional values? Return an unwillingToPerform error on modifications that >will result in multiple password values? > > > > I would suggest that password attributes are defined as single-valued... I know this is not the case for userPassword. I think that servers should not throw away additional values, they should return an error... The error may be implementation specific. >Section 6.1.2B Page 17 > > >>The server MUST then disallow all operations issued by this >>user except modify password, bind, unbind, abandon and >>StartTLS extended operation. >> >> >Compare? > > > I don't think compare should be allowed. The idea is to only allow the user to modify his/her password which will require the user to be authenticated. Also I think there is an issue here with applications that are only doing authentication... And thus will never call modify. The password will be used without being changed again by the user. Somehow, there should be a mechanism to prevent this usage. >Section 6.1.2D Page 18 and 6.4.2C > > >>If the pwdExpirationWarned attribute is present and has a >>time value, the warning time is the value of the >>pwdExpirationWarned attribute plus the value of the >>pwdExpireWarning attribute minus the current time. >> >> > >WarningTime = pwdExpirationWarned + pwdExpireWarning - Current Time > > > >>If the pwdExpirationWarned attribute is not present, the >>server MUST subtract the current time from the time stored >>in pwdChangedTime to arrive at the password's age. If the >>age is greater than the value of the pwdMaxAge attribute >>minus the value of the pwdExpireWarning attribute, the >>server MUST set the current time as the value of the >>pwdExpirationWarned attribute, and the warning time is the >>value of pwdMaxAge minus the password's age. >> >> > >PasswordAge = pwdChangeTime - CurrentTime >WarningTime = pwdMaxAge - PasswordAge > >Firstly, I believe that the calculation of the PasswordAge is incorrect. > > I agree that the wording is confusing... A - B is expressed in english as remove B from A... This needs to be corrected in numerous places. >I think that the pwdChangeTime should be subtracted from the current time. > >Following the warning time calculation steps described in the draft can also >lead to misleading results. >The example below will illustrate a scenario where this is the case. > >pwdMaxAge = 100 seconds. >pwdExpireWarning = 50 seconds. >The user binds when the password is 80 seconds old. >PasswordAge = 80. >WarningTime = (pwdMaxAge - PasswordAge) = 20 seconds. >At this stage the user has been told that their password will expire in 20 >seconds. > >User binds again in 5 seconds time. (I.e. PasswordAge = 85 seconds). >Since the pwdExpirationWarned is now present we calculate the warning time >differently. > >WarningTime = (pwdExpirationWarned + pwdExpireWarning - CurrentTime) > = (pwdExpirationWarned - CurrentTime) + pwdExpireWarning > = (-5) + 50 > = 45 >The user is now told that their password will expire in 45 seconds. >Our implementation of the password policy will simply return >pwdExpireWarning as the first warning time value. > > > This is what our implementation does as well. But I think this has the side effect of effectively extending the password life beyond the specified MaxAge. The other solution is to make sure that the password expires after MaxAge (so the WarningTime whould be 15 seconds in the 2nd warning time value) and let grace logins deals with possible authentication after expiration of the password. >Section 6.1.2B (Page 20) > > >>If the number of these failures is greater or equal to the >>pwdMaxFailure attribute, the server MUST lock the account >>by setting the value of the pwdAccountLockedTime attribute >>to the current time. After locking the account, the server >>MUST send a bindResponse to the client with the >>resultCode: unwillingToPerform (53), and MUST include the >>passwordPolicyResponse in the controls field of the >>bindResponse message with the error: accountLocked (1). >> >> > >I do not think that the return code should be unwillingToPerform. In this >scenario, the user has got their password wrong and this incorrect attempt >has made the number of failures exceed the pwdMaxFailure limit. In this case >the reason why the operation (BIND) is going to fail is because of the >incorrect password. The fact that the number of bind failures has exceeded a >policy limit is just a consequence of that. >For this reason I believe that the resultCode should be invalidCredentials. > > > Correct, in that case, it should be invalidCredentials (49). >Section 6.2.9 >If an administrator is modifying the password then we should not remove the >pwdReset attribute. > > I agree... It should be set to TRUE if pwdMustChange is TRUE. >This scenario is likely, because the definition that you provide in Section >3.2 states that: >"In this document, the term "modify password operation" refers to any >operation that is used to add or modify a password attribute." >The description provides no constraints on who is performing the modify >password operation. > > > I agree... And somehow the text right makes the assumption that it is the User. I will change the wording. >Section 6.3.2B > > >>If the server is unable to check the length (due to a hashed >>password or otherwise), the value of pwdCheckSyntax MUST be >>evaluated. If the value is 1, operation MUST continue. If the >>value is 2, the server MUST send an addResponse to the client >>with the resultCode: constraintViolation (19), and MUST >>include the passwordPolicyResponse in the controls field of >>the addResponse message with the error: passwordTooShort (5). >> >> > >A passwordTooShort error code here seems inappropriate. Since the server >could not determine the length due to the syntax of the password wouldn't it >be more appropriate to use a invalidPasswordQuality error code. > > > > OK. >Section 6.3 >You need a Step 4. Set the pwdReset value to TRUE. > > > I'm not sure this is a MUST though. And it should be left out to Administrators to decide if the password must be reset or not. I've added the following text: 4. Set the pwdReset attribute. The value SHOULD be TRUE if the pwdMustChange attribute is TRUE, and FALSE otherwise. However, this may be subject to specific configuration. >Section 6.4.2A >How about removing the pwdAccountLockedTime attribute in the doc somewhere? >I think that sections 6.4.2A and 6.1.2A are prime locations. > > > Yes. Both locations updated. >Section 6.4.2D > > >>If the result of the compare operation is false, the server MUST >>do the following: >> >> > > > >>D. If no errors were returned, the server MUST send a >>compareResponse with the resultCode: compareTrue (6), and >>MUST include the passwordPolicyResponse with nothing in >>the SEQUENCE. >> >> >Section D above is related to the fact that the compare was false. The >server should therefore return compareFalse. > > > Ok. >7.1.2. > > >>The user is binding for the first time after the directory >>administrator set the password. In this scenario, the client >>SHOULD prompt the user to change his password immediately. >> >>resultCode: success (0) >>passwordPolicyResponse: error: changeAfterReset (2) >> >> > >This scenario will occur for every single bind until the password has been >changed. > > > Agree... This reminds me that some customer would like to have a specific Expiration Time for Reseted passwords (shorter than the regular pwdMaxAge). >Section 7.5 > > >>For operations other than bind, unbind, abandon, search or StartTLS, >>the client MUST check the following result code and control to >>determine if the user needs to change the password immediately. >> >> > >I don't think that search should be in there. > > > Agree >Section 8 >An administrativeRole operational attribute (as defined in RFC36720) must be >specified for the password policy. > > > I know. I've realized this when updating the text to reference RFC 3672. The document will need an IANA Consideration section as well. >I also think that this draft should contain a 'Known Limitation'(or similar) >section. A few things off the top of my head: > * Password Attribute must only contain one value > * No consideration for password attributes with options > Eg, if I have the attributes userPassword;x-unix and userPassword;x-windows >with different passwords for different reasons. How do I set up individual >policies? > * Password policy cannot be applied to X.500 attributes whose syntax don't >have an LDAP specific encoding. > > > > Willl think of it. >Cheers, > >Andrew Sciberras >Software Engineer >Adacel Technologies Ltd > > > Thanks again for the review and the very valuable comments. Regards, Ludovic. -- Ludovic Poitou Directory Architect. Directory Server Group, Grenoble, France Sun Microsystems Inc. Sun Microsystems requires the following notice: ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ NOTICE: This email message is for the sole use of the intended recipient(s) and may contain confidential and privileged information. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please contact the sender by reply email and destroy all copies of the original message. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ _______________________________________________ Ldapext mailing list Ldapext@ietf.org https://www1.ietf.org/mailman/listinfo/ldapext From ldapext-admin@ietf.org Thu Feb 19 19:51:34 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA07808 for ; Thu, 19 Feb 2004 19:51:34 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Atysg-0007s3-GU; Thu, 19 Feb 2004 19:51:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AtysC-0007mP-9d for ldapext@optimus.ietf.org; Thu, 19 Feb 2004 19:50:32 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA07722 for ; Thu, 19 Feb 2004 19:50:30 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AtysA-0000eg-00 for ldapext@ietf.org; Thu, 19 Feb 2004 19:50:30 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AtyrG-0000by-00 for ldapext@ietf.org; Thu, 19 Feb 2004 19:49:34 -0500 Received: from mail12.ca.com ([141.202.248.38] helo=usilms54.ca.com) by ietf-mx with esmtp (Exim 4.12) id 1Atyqk-0000Z2-00 for ldapext@ietf.org; Thu, 19 Feb 2004 19:49:02 -0500 Received: from usilms80.ca.com ([141.202.201.17]) by usilms54.ca.com with Microsoft SMTPSVC(5.0.2195.6713); Thu, 19 Feb 2004 19:49:02 -0500 Received: from ausyms81.ca.com ([155.35.201.11]) by usilms80.ca.com with Microsoft SMTPSVC(5.0.2195.6713); Thu, 19 Feb 2004 19:49:02 -0500 Received: from ausyms21.ca.com ([155.35.201.5]) by ausyms81.ca.com with Microsoft SMTPSVC(5.0.2195.6713); Fri, 20 Feb 2004 11:48:59 +1100 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Fri, 20 Feb 2004 11:48:59 +1100 Message-ID: <1395B4B334FCC143B36AF788E68B63810110AE0B@ausyms21.ca.com> Thread-Topic: [ldapext] Re: draft-behera-ldap-password-policy-07.txt Thread-Index: AcP2+hT4ch2JiK1bRKqiqNn4/zQN4AAT1usw From: "Ramsay, Ron" To: "Ludovic Poitou" Cc: X-OriginalArrivalTime: 20 Feb 2004 00:48:59.0464 (UTC) FILETIME=[53A81C80:01C3F74B] X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Subject: [ldapext] Clarification of draft-behera-ldap-password-policy-07.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: , Content-Transfer-Encoding: quoted-printable Hi Ludovic, I am seeking clarification regarding when the password-policy control = response is returned. The -06 draft Section 5.1 says it is returned = "when appropriate" and Section 5.2 says it is returned with "the = following operation responses...." Is it expected that the response control is a. always returned if the request control was present b. only returned if a status needs to be signalled c. returned if the operation is one of bind, modify, add, compare, or d. only returned if the operation is one of bind, modify, add, compare = and a status needs to be signalled? When can we expect draft -07 to be published> Thanks, Ron _______________________________________________ Ldapext mailing list Ldapext@ietf.org https://www1.ietf.org/mailman/listinfo/ldapext From ldapext-admin@ietf.org Thu Feb 19 20:59:30 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA11299 for ; Thu, 19 Feb 2004 20:59:30 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AtzwS-0005Ls-V5; Thu, 19 Feb 2004 20:59:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Atzw8-0005LX-VN for ldapext@optimus.ietf.org; Thu, 19 Feb 2004 20:58:41 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA11263 for ; Thu, 19 Feb 2004 20:58:38 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Atzw6-0005uE-00 for ldapext@ietf.org; Thu, 19 Feb 2004 20:58:38 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AtzvA-0005qv-00 for ldapext@ietf.org; Thu, 19 Feb 2004 20:57:41 -0500 Received: from mail12.ca.com ([141.202.248.38] helo=usilms54.ca.com) by ietf-mx with esmtp (Exim 4.12) id 1Atzuq-0005no-00 for ldapext@ietf.org; Thu, 19 Feb 2004 20:57:20 -0500 Received: from usilms81.ca.com ([141.202.201.51]) by usilms54.ca.com with Microsoft SMTPSVC(5.0.2195.6713); Thu, 19 Feb 2004 20:57:20 -0500 Received: from ausyms81.ca.com ([155.35.201.11]) by usilms81.ca.com with Microsoft SMTPSVC(5.0.2195.6713); Thu, 19 Feb 2004 20:57:20 -0500 Received: from ausyms21.ca.com ([155.35.201.5]) by ausyms81.ca.com with Microsoft SMTPSVC(5.0.2195.6713); Fri, 20 Feb 2004 12:57:17 +1100 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [ldapext] Clarification of draft-behera-ldap-password-policy-07.txt Date: Fri, 20 Feb 2004 12:57:16 +1100 Message-ID: <1395B4B334FCC143B36AF788E68B63810110AEFB@ausyms21.ca.com> Thread-Topic: [ldapext] Clarification of draft-behera-ldap-password-policy-07.txt Thread-Index: AcP3T3uexkfHWCaoREa0kdmDS/qClQABIeYg From: "Ramsay, Ron" To: Cc: "Ldapext (E-mail)" X-OriginalArrivalTime: 20 Feb 2004 01:57:17.0172 (UTC) FILETIME=[DE14BB40:01C3F754] X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable 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: quoted-printable Thanks, Andrew. It seems to come down to two paradigms: 1) Always return a response control in response to a request control if = password policy has been used (like the server-side sorting control) 2) Only return a response control if one of the fields is present. As, I guess, it is not a client's business to be asking HOW they were = authenticated, 2) would seem to do the trick. Ron -----Original Message----- From: Andrew Sciberras [mailto:andrew.sciberras@adacel.com] Sent: Friday, 20 February 2004 12:18 To: Ramsay, Ron Cc: Ldapext (E-mail) Subject: RE: [ldapext] Clarification of draft-behera-ldap-password-policy-07.txt Hi Ron, >Hi Ludovic, Although this wasn't addressed to me, i'll chuck in my $0.02 worth... >I am seeking clarification regarding when the password-policy >control response is returned. The -06 draft Section 5.1 says >it is returned "when appropriate" and Section 5.2 says it is >returned with "the following operation responses...." The ambiguity in when the control should be returned has been brought up before. I'm not sure what the status of official archives of this mailling list = are, but if you go to this page: http://news.gmane.org/gmane.ietf.ldapext and scroll down to the 2nd of September, 2003, you'll see the = discussion. I'm not certain that this matter was resolved, however it may have been decided that the purpose of the control was to convey additional error/warning messages for the client. This is inline with your point 'b', below. My personal preference would be point 'a'. Always return the control; populate it with information if required. Some ambiguity still exists though, because: * the control is still returned at times (bind & compare) without any information. * 5.2 states that the control will be returned with add operations = (maybe others aswell), however this is not always the case. > >Is it expected that the response control is >a. always returned if the request control was present >b. only returned if a status needs to be signalled >c. returned if the operation is one of bind, modify, add, compare, or >d. only returned if the operation is one of bind, modify, add, >compare and a status needs to be signalled? >When can we expect draft -07 to be published> 18/02/04 >Thanks, > >Ron Cheers, Andrew. _______________________________________________ Ldapext mailing list Ldapext@ietf.org https://www1.ietf.org/mailman/listinfo/ldapext From ldapext-admin@ietf.org Fri Feb 20 06:07:31 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA15379 for ; Fri, 20 Feb 2004 06:07:31 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Au8Uo-0005Zb-FO; Fri, 20 Feb 2004 06:07:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Au8Uj-0005X4-Ea for ldapext@optimus.ietf.org; Fri, 20 Feb 2004 06:06:57 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA15355 for ; Fri, 20 Feb 2004 06:06:53 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Au8Uf-0004yb-00 for ldapext@ietf.org; Fri, 20 Feb 2004 06:06:53 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Au8Tt-0004w2-00 for ldapext@ietf.org; Fri, 20 Feb 2004 06:06:06 -0500 Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by ietf-mx with esmtp (Exim 4.12) id 1Au8T9-0004rc-00 for ldapext@ietf.org; Fri, 20 Feb 2004 06:05:19 -0500 Received: from odin.France.Sun.COM ([129.157.174.8]) by nwkea-mail-1.sun.com (8.12.10/8.12.9) with ESMTP id i1KB470J017288; Fri, 20 Feb 2004 03:04:08 -0800 (PST) Received: from Sun.COM (dhcp-gnb07-211-108 [129.157.211.108]) by odin.France.Sun.COM (8.11.7p1+Sun/8.10.2/ENSMAIL,v2.2) with ESMTP id i1KB47P02679; Fri, 20 Feb 2004 12:04:07 +0100 (MET) Message-ID: <4035E971.2000506@Sun.COM> Date: Fri, 20 Feb 2004 12:03:13 +0100 From: Ludovic Poitou Organization: SUN Microsystems User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Ramsay, Ron" CC: ldapext@ietf.org References: <1395B4B334FCC143B36AF788E68B63810110AE0B@ausyms21.ca.com> In-Reply-To: <1395B4B334FCC143B36AF788E68B63810110AE0B@ausyms21.ca.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Subject: [ldapext] Re: Clarification of draft-behera-ldap-password-policy-07.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: , Content-Transfer-Encoding: 7bit -07 has been published. -08 intends to be published in April or May. As for the clarification, my quick answer would be: always return when the request control is present. But I need to put some more thoughts on this. Regards, Ludovic. Ramsay, Ron wrote: >Hi Ludovic, > >I am seeking clarification regarding when the password-policy control response is returned. The -06 draft Section 5.1 says it is returned "when appropriate" and Section 5.2 says it is returned with "the following operation responses...." > >Is it expected that the response control is >a. always returned if the request control was present >b. only returned if a status needs to be signalled >c. returned if the operation is one of bind, modify, add, compare, or >d. only returned if the operation is one of bind, modify, add, compare and a status needs to be signalled? > >When can we expect draft -07 to be published> > >Thanks, > >Ron > > > -- Ludovic Poitou Directory Architect. Directory Server Group, Grenoble, France Sun Microsystems Inc. Sun Microsystems requires the following notice: ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ NOTICE: This email message is for the sole use of the intended recipient(s) and may contain confidential and privileged information. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please contact the sender by reply email and destroy all copies of the original message. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ _______________________________________________ Ldapext mailing list Ldapext@ietf.org https://www1.ietf.org/mailman/listinfo/ldapext From ldapext-admin@ietf.org Mon Feb 23 19:43:33 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA05197 for ; Mon, 23 Feb 2004 19:43:33 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AvQf7-0006A3-4n; Mon, 23 Feb 2004 19:43:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AvQeg-00069s-AI for ldapext@optimus.ietf.org; Mon, 23 Feb 2004 19:42:34 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA05174 for ; Mon, 23 Feb 2004 19:42:32 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AvQee-000162-00 for ldapext@ietf.org; Mon, 23 Feb 2004 19:42:32 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AvQdi-000135-00 for ldapext@ietf.org; Mon, 23 Feb 2004 19:41:35 -0500 Received: from mail17.ca.com ([155.35.248.106] helo=ausyms50.ca.com) by ietf-mx with esmtp (Exim 4.12) id 1AvQdB-0000xb-00 for ldapext@ietf.org; Mon, 23 Feb 2004 19:41:02 -0500 Received: from ausyms21.ca.com ([155.35.201.5]) by ausyms50.ca.com with Microsoft SMTPSVC(5.0.2195.6713); Tue, 24 Feb 2004 11:40:30 +1100 x-mimeole: Produced By Microsoft Exchange V6.0.6547.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Tue, 24 Feb 2004 11:40:30 +1100 Message-ID: <1395B4B334FCC143B36AF788E68B63810112A3A0@ausyms21.ca.com> Thread-Topic: Clarification of draft-behera-ldap-password-policy-07.txt Thread-Index: AcP3oWDpgX/BSYHbSbiJILBuiHGNjACzFR6w From: "Ramsay, Ron" To: "Ludovic Poitou" Cc: , "McDonald, Justin" X-OriginalArrivalTime: 24 Feb 2004 00:40:30.0273 (UTC) FILETIME=[CDCEBB10:01C3FA6E] X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Subject: [ldapext] RE: Clarification of draft-behera-ldap-password-policy-07.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: , Content-Transfer-Encoding: quoted-printable Thanks, we've picked up the new draft. On another matter, there is an error code 'accountLocked' which we would = normally set if the user had exceeded their password retry count. = However, we also have the capability of administratively locking the = account and it would be helpful if we could distinguish the two cases, = perhaps by: accountSuspended, /* password retries exceeded */ accountLocked /* administrator has disabled this account */ or accountLocked and accountDisabled? Thanks, Ron -----Original Message----- From: Ludovic Poitou [mailto:ludovic.poitou@Sun.COM] Sent: Friday, 20 February 2004 22:03 To: Ramsay, Ron Cc: ldapext@ietf.org Subject: Re: Clarification of draft-behera-ldap-password-policy-07.txt -07 has been published. -08 intends to be published in April or May. As for the clarification, my quick answer would be: always return when=20 the request control is present. But I need to put some more thoughts on=20 this. Regards, Ludovic. Ramsay, Ron wrote: >Hi Ludovic, > >I am seeking clarification regarding when the password-policy control = response is returned. The -06 draft Section 5.1 says it is returned = "when appropriate" and Section 5.2 says it is returned with "the = following operation responses...." > >Is it expected that the response control is >a. always returned if the request control was present >b. only returned if a status needs to be signalled >c. returned if the operation is one of bind, modify, add, compare, or >d. only returned if the operation is one of bind, modify, add, compare = and a status needs to be signalled? > >When can we expect draft -07 to be published> > >Thanks, > >Ron > > =20 > --=20 Ludovic Poitou Directory Architect. Directory Server Group, Grenoble, France Sun Microsystems Inc. Sun Microsystems requires the following notice: ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ NOTICE: This email message is for the sole use of the intended recipient(s) and may contain confidential and privileged information. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please contact the sender by reply email and destroy all copies of the original message. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ _______________________________________________ Ldapext mailing list Ldapext@ietf.org https://www1.ietf.org/mailman/listinfo/ldapext From ldapext-admin@ietf.org Tue Feb 24 02:26:33 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA04376 for ; Tue, 24 Feb 2004 02:26:33 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AvWx8-0003jD-VV; Tue, 24 Feb 2004 02:26:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AvWwv-0003f2-31 for ldapext@optimus.ietf.org; Tue, 24 Feb 2004 02:25:49 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA04319 for ; Tue, 24 Feb 2004 02:25:46 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AvWwr-0004PO-00 for ldapext@ietf.org; Tue, 24 Feb 2004 02:25:45 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AvWvy-0004MJ-00 for ldapext@ietf.org; Tue, 24 Feb 2004 02:24:51 -0500 Received: from mail17.ca.com ([155.35.248.106] helo=ausyms50.ca.com) by ietf-mx with esmtp (Exim 4.12) id 1AvWvE-0004E7-00 for ldapext@ietf.org; Tue, 24 Feb 2004 02:24:04 -0500 Received: from ausyms21.ca.com ([155.35.201.5]) by ausyms50.ca.com with Microsoft SMTPSVC(5.0.2195.6713); Tue, 24 Feb 2004 18:23:33 +1100 x-mimeole: Produced By Microsoft Exchange V6.0.6547.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Tue, 24 Feb 2004 18:23:33 +1100 Message-ID: <1395B4B334FCC143B36AF788E68B63810114420D@ausyms21.ca.com> Thread-Topic: Clarification of draft-behera-ldap-password-policy-07.txt Thread-Index: AcP3oWDpgX/BSYHbSbiJILBuiHGNjADBObpg From: "Ramsay, Ron" To: "Ludovic Poitou" Cc: X-OriginalArrivalTime: 24 Feb 2004 07:23:33.0987 (UTC) FILETIME=[1C6CA330:01C3FAA7] X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Subject: [ldapext] RE: Clarification of draft-behera-ldap-password-policy-07.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: , Content-Transfer-Encoding: quoted-printable There is another issue that needs clarification, but I don't know if = this has been raised before. The ASN.1 specifications of the request and response control appear in = the document as pieces of ASN.1 and not a 'module'. This leaves some = doubt regarding whether tags are IMPLICIT or EXPLICIT. We are using the = same default as the LDAP v3 module, namely IMPLCIT TAGS. It is not = possible for two implementations to interwork if they are not using the = same default tagging method. (The ASN.1 can be made independent of the = tagging default by using the actual words EXPLICIT and IMPLICIT in hte = ASN.1, but I would think it enough to note which metho dis assumed.) Ron -----Original Message----- From: Ludovic Poitou [mailto:ludovic.poitou@Sun.COM] Sent: Friday, 20 February 2004 22:03 To: Ramsay, Ron Cc: ldapext@ietf.org Subject: Re: Clarification of draft-behera-ldap-password-policy-07.txt -07 has been published. -08 intends to be published in April or May. As for the clarification, my quick answer would be: always return when=20 the request control is present. But I need to put some more thoughts on=20 this. Regards, Ludovic. Ramsay, Ron wrote: >Hi Ludovic, > >I am seeking clarification regarding when the password-policy control = response is returned. The -06 draft Section 5.1 says it is returned = "when appropriate" and Section 5.2 says it is returned with "the = following operation responses...." > >Is it expected that the response control is >a. always returned if the request control was present >b. only returned if a status needs to be signalled >c. returned if the operation is one of bind, modify, add, compare, or >d. only returned if the operation is one of bind, modify, add, compare = and a status needs to be signalled? > >When can we expect draft -07 to be published> > >Thanks, > >Ron > > =20 > --=20 Ludovic Poitou Directory Architect. Directory Server Group, Grenoble, France Sun Microsystems Inc. Sun Microsystems requires the following notice: ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ NOTICE: This email message is for the sole use of the intended recipient(s) and may contain confidential and privileged information. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please contact the sender by reply email and destroy all copies of the original message. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ _______________________________________________ Ldapext mailing list Ldapext@ietf.org https://www1.ietf.org/mailman/listinfo/ldapext From ldapext-admin@ietf.org Wed Feb 25 12:09:41 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA00269 for ; Wed, 25 Feb 2004 12:09:41 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aw2Wr-0002rB-Hj; Wed, 25 Feb 2004 12:09:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aw1xF-0007Ro-Ax for ldapext@optimus.ietf.org; Wed, 25 Feb 2004 11:32:15 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA27185 for ; Wed, 25 Feb 2004 11:32:10 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Aw1xD-0004wr-00 for ldapext@ietf.org; Wed, 25 Feb 2004 11:32:11 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Aw1uH-0004EH-00 for ldapext@ietf.org; Wed, 25 Feb 2004 11:29:38 -0500 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1Aw1rN-0003Xj-01 for ldapext@ietf.org; Wed, 25 Feb 2004 11:26:09 -0500 Received: from prv-mail20.provo.novell.com ([137.65.81.122]) by mx2.foretec.com with esmtp (Exim 4.24) id 1Aw1a4-0000vB-LT for ldapext@ietf.org; Wed, 25 Feb 2004 11:08:16 -0500 Received: from INET-PRV-MTA by prv-mail20.provo.novell.com with Novell_GroupWise; Wed, 25 Feb 2004 09:07:43 -0700 Message-Id: X-Mailer: Novell GroupWise Internet Agent 6.5.2 Beta Date: Wed, 25 Feb 2004 09:07:26 -0700 From: "Bruce Bergeson" To: Cc: , "Kent Boogert" , "Vijay KN" Subject: RE: [ldapext] draft-bergeson-uddi-ldap-schema-02.txt Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="=__PartF2D3832E.2__=" X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.5 required=5.0 tests=AWL,HTML_MESSAGE,WEIRD_QUOTING autolearn=no version=2.60 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: , This is a MIME message. If you are reading this text, you may want to consider changing to a mail reader or gateway that understands how to properly handle MIME multipart messages. --=__PartF2D3832E.2__= Content-Type: multipart/alternative; boundary="=__PartF2D3832E.3__=" --=__PartF2D3832E.3__= Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Hello, We do plan on updating the draft with an '03' version. I have modified the draft based on your comments and attached the latest. I am waiting for one more reviewer to complete his work before the update. Thanks for your input. Below each suggestion I have outlined the actions taken. Regards,-Bruce >>> "Andrew Sciberras" 2/12/04 11:12:03 PM >>>Hi, > We have updated the draft http://www.ietf.org/internet-drafts/draft-bergeson-uddi-ldap-schema-02.txt > based on a round of initial reviews and we want to progress it to RFC status. > Before requesting the Area Director to initiate a last call, we wanted to see if anyone has any further feedback. >Bruce, Kent, and Vijay.So, do you plan to release an '03' version of this draft before requesting a last call?I guess I'm curious as to whether my comments (sent to the list on 19/12/03, see below) have been taken into consideration. Cheers,Andrew Sciberras Software Engineer Adacel Technologies Ltd 250 Bay Street Brighton t. 8530 7844 m. 0412 098 771 >G'Day, >Just some comments regarding 'LDAP Schema for UDDI'.>Section 5.2 >The equality matching rule for a distinguished name cannot be a >caseIgnoreMatch.Changed equality matching rule to distinguishedNameMatch.>For the following attributes: >* uddiName >* uddiServiceKey >* uddiBindingKey>It is explicitly stated that the values of this attribute may not be blank. >The other attributes with a DirectoryString string syntax do not carry >this statement. I'm not sure what this is implying, but I feel that I should >note that none of the DirectoryString attributes are permitted to have a >blank value.For uddiName. This was an early attempt to describe the must relationship of this attribute type definition to its containing object class definition. I have removed the sentence.For uddiServiceKey. This is referring to an uddiServiceKey used in an UDDI inquiry operation. Changed to: If a uddiServiceKey is received via an inquiry operation, the key values may not be blank.For uddiBindingKey. This is referring to an uddiBindingKey used in an UDDI inquiry operation. Changed to: If an uddiBindingKey is received via an inquiry operation, the key values may not be blank.>Section 5.17 >"When saving a new uddiBusinessService structure, pass an empty >uddiServiceKey value" >Section 5.18 >"When saving a new uddiBindingTemplate structure, pass an empty >uddiBindingKey value" >These would be strictly illegal since a DirectoryString must have at least >one character.This describes the UDDI create operations data structure. The UDDI server must generate the appropriate key value to pass to the LDAP server.>Section 5.41 >I don't think you intended to have a boolean syntax for this attribute >Since this attribute contains an integer, perhaps an Integer syntax with an >integerMatch equality rule would be more appropriate?Changed to: SYNTAX 1.3.6.1.4.1.1466.115.121.1.27 EQUALITY integerMatch>Section 5.43 >Perhaps a Boolean syntax with a booleanMatch would be more appropriate?Yes. Changed to: SYNTAX 1.3.6.1.4.1.1466.115.121.1.7 EQUALITY booleanMatch>[RFC3377], [RFC2829], [RFC2830], are not listed in the Normative >References, but are present within the document.I added [RFC2829], [RFC2830] to the Normative References and changed [RFC3377] to [LDAPv3]. --=__PartF2D3832E.3__= Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

Hello,

We do plan on updating the draft with an = '03' version. I have modified the

draft based on your comments and attached&n= bsp;the latest. I am = waiting for one

more reviewer to complete his work before the = update. Thanks for your = input.

Below each suggestion I have outlined the actions = taken.

Regards,

-Bruce

>>> = "Andrew Sciberras" <andrew.sciberras@adacel.com> 2/12/04 11:12:03 PM = >>>

Hi,

> We have updated the = draft http://www.ietf.org/internet-drafts/draft-bergeson-udd= i-ldap-schema-02.txt

> based on a round of = initial reviews and we want to progress it to RFC status. <= /SPAN>

> Before requesting the = Area Director to initiate a last call, we wanted to see if anyone has any = further feedback.
>Bruce, Kent, and Vijay.

So, do you plan to release = an '03' version of this draft before requesting a last call?

I guess I'm curious as to = whether my comments (sent to the list on 19/12/03, see below) have been = taken into consideration.

Cheers,

Andrew Sciberras
Software = Engineer
Adacel Technologies Ltd
250 Bay Street Brighton
t. 8530 = 7844
m. 0412 098 771

>G'Day,
>Just some = comments regarding 'LDAP Schema for UDDI'.

>Section 5.2
>The = equality matching rule for a distinguished name cannot be a
>caseIgno= reMatch.

Changed equality matching rule to = distinguishedNameMatch.

>For the following attributes:<= BR>>* uddiName
>* uddiServiceKey
>* uddiBindingKey

>It is explicitly stated that = the values of this attribute may not be blank.
>The other attributes = with a DirectoryString string syntax do not carry
>this = statement. I'm not sure what this is implying, but I feel that I should
= >note that none of the DirectoryString attributes are permitted to have = a
>blank value.

For uddiName. This was an = early attempt to describe the must relationship of this attribute type = definition to its containing object class definition. I have = removed the sentence.

For uddiServiceKey. This is = referring to an uddiServiceKey used in an UDDI inquiry operation. = ; Changed to: If a uddiServiceKey is received via an inquiry operation, = the key values may not be blank.

For uddiBindingKey. This is = referring to an uddiBindingKey used in an UDDI inquiry operation. = Changed to: If an uddiBindingKey is received via an = inquiry operation, the key values may not be blank.

>Section 5.17
>"When = saving a new uddiBusinessService structure, pass an empty
>uddiServic= eKey value"
>Section 5.18
>"When saving a new uddiBindingTempla= te structure, pass an empty
>uddiBindingKey value"
>These = would be strictly illegal since a DirectoryString must have at least
>= ;one character.

This describes the UDDI create = operations data structure. The UDDI server must generate = the appropriate key value to pass to the LDAP server.

>Section 5.41
>I don't = think you intended to have a boolean syntax for this attribute
>Since= this attribute contains an integer, perhaps an Integer syntax with = an
>integerMatch equality rule would be more appropriate?<= /SPAN>

Changed to: SYNTAX 1.3.6.1.4.= 1.1466.115.121.1.27 EQUALITY integerMatch

>Section 5.43
>Perhaps a = Boolean syntax with a booleanMatch would be more appropriate?

Yes. Changed to: SYNTAX = 1.3.6.1.4.1.1466.115.121.1.7 EQUALITY booleanMatch

>[RFC3377], [RFC2829], = [RFC2830], are not listed in the Normative
>References, but are = present within the document.

I added [RFC2829], [RFC2830] = to the Normative References and changed [RFC3377] to [LDAPv3].

--=__PartF2D3832E.3__=-- --=__PartF2D3832E.2__= Content-Type: text/plain; name="draft-bergeson-uddi-ldap-schema-03.txt" Content-Disposition: attachment; filename="draft-bergeson-uddi-ldap-schema-03.txt" Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by ietf.org id LAA27188 Content-Transfer-Encoding: quoted-printable Individual Submission B. Bergeson=20 K. Boogert=20 Vijay K.Nanjundaswamy=20 Internet Draft Novell, Inc.=20 Document: draft-bergeson-uddi-ldap-schema-03.txt December, 2003=20 Intended Category: Informational Expires June, 2004=20 =20 =20 =20 LDAP Schema for UDDIv3=20 =20 =20 Status of this Memo=20 =20 This document is an Internet-Draft and is in full conformance with=20 all provisions of Section 10 of RFC2026.=20 =20 Internet-Drafts are working documents of the Internet Engineering=20 Task Force (IETF), its areas, and its working groups. Note that=20 other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of=20 six months and may be updated, replaced, or obsoleted by other=20 documents at any time. It is inappropriate to use Internet-Drafts as=20 reference material or to cite them other than as "work in progress." =20 The list of current Internet-Drafts can be accessed at=20 http://www.ietf.org/ietf/1id-abstracts.txt =20 The list of Internet-Draft Shadow Directories can be accessed at=20 http://www.ietf.org/shadow.html.=20 =20 Editorial comments may be sent to bruce.bergeson@novell.com. General=20 discussion may be directed to the LDAPEXT WG List.=20 =20 =20 1. Abstract=20 =20 This document defines the Lightweight Directory Access Protocol=20 [(LDAPv3)] Schema for representing Universal Description, Discovery=20 & Integration (UDDI) data types in an LDAP directory. It defines the=20 LDAP object class & attribute definitions and containment rules to=20 model UDDI entities, defined in the UDDI version 3 information=20 model, in an LDAPv3 compliant directory. =20 =20 =20 Table of Contents=20 1. Abstract.......................................................1=20 2. Conventions used in this document..............................2=20 3. Introduction...................................................2=20 4. Representation of UDDI Data Structures.........................2=20 5. Attribute Type Definitions.....................................5=20 6. Object Class Definitions......................................24=20 7. Name Forms....................................................28=20 8. DIT Structure Rules...........................................30=20 9. Security Considerations.......................................31=20 =20 Bergeson, Boogert & Nanjundaswamy Internet-Draft 1=20 LDAP Schema for UDDI November 2003=20 =20 =20 10. IANA Considerations..........................................32=20 11. Normative References.........................................50=20 12. Author's Addresses...........................................51=20 =20 =20 2. Conventions used in this document=20 The keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",=20 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this=20 document are to be interpreted as described in RFC 2119..=20 =20 All schema definitions are provided using [RFC2252] descriptions,=20 line-wrapped for readability only.=20 =20 =20 =20 3. Introduction=20 =20 This document defines "Lightweight Directory Access Protocol"=20 [LDAPv3] schema elements to represent the core data structures=20 identified in "Universal Description Discovery and Integration"=20 version 3 [UDDIv3] information model. This includes: a=20 businessEntity, a businessService, a bindingTemplate, a tModel, a=20 publisherAssertion and a Subscription. Portions of [UDDIv3] are=20 repeated here for clarity.=20 =20 4. Representation of UDDI Data Structures=20 =20 The information that makes up a registration in a UDDI registry=20 consists of these data structure types. This division by=20 information type provides simple partitions to assist in the rapid=20 location and understanding of the different information that makes=20 up a registration.=20 =20 The individual instance data managed by a UDDI registry are=20 sensitive to the parent/child relationships found in the schema. A=20 businessEntity object contains one or more unique businessService=20 objects. Similarly, individual businessService objects contain=20 specific instances of bindingTemplate, which in turn contains=20 information that includes pointers to specific instances of tModel=20 objects.=20 =20 It is important to note that no single instance of a core schema=20 type is ever "contained" by more than one parent instance. This=20 means that only one specific businessEntity object (identified by=20 its unique key value) will ever contain or be used to express=20 information about a specific instance of a businessService object=20 (also identified by its own unique key value).=20 =20 4.1 businessEntity=20 =20 The businessEntity object represents all known information about a=20 business or entity that publishes descriptive information about the=20 entity as well as the services that it offers. The businessEntity=20 =20 Bergeson,Boogert & Nanjundaswamy Internet-Draft 2=20 LDAP Schema for UDDI November 2003=20 =20 =20 is the top-level container that accommodates holding descriptive=20 information about a business or entity. Service descriptions and=20 technical information are expressed within a businessEntity by a=20 containment relationship.=20 =20 4.1.1 Representation in the Directory=20 =20 A businessEntity is represented in the directory by the attributes=20 uddiBusinessKey, uddiAuthorizedName, uddiOperator,=20 uddiDiscoveryURLs, uddiName, uddiDescription, uddiIdentifierBag,=20 uddiCategoryBag, and uddiv3DigitalSignature, along with=20 corresponding v3 keys viz. uddiv3BusinessKey, as defined in section=20 5. A businessEntity may contain zero or more instances of=20 uddiContact and uddiBusinessService. =20 =20 The mandatory attribute, uddiBusinessKey, contains the unique=20 identifier for a given instance of a businessEntity.=20 =20 businessEntity's definition is given in Section 6. =20 =20 4.2 businessService=20 =20 The businessService instances represent a logical business service. =20 Each businessService object is the logical child of a single=20 businessEntity object. Each businessService element contains=20 descriptive information in business terms outlining the type of=20 technical services found within each businessService instance.=20 =20 In some cases, businesses would like to share or reuse services,=20 e.g. when a large enterprise publishes separate businessEntity=20 structures. This can be established by using the businessService=20 instance as a projection to an already published businessService.=20 =20 4.2.1 Representation in the Directory=20 =20 A businessService is represented in the directory by the attributes=20 uddiBusinessKey, uddiServiceKey, uddiName, uddiDescription,=20 uddiCategoryBag, uddiIsProjection, and uddiv3DigitalSignature, along=20 with corresponding v3 keys viz. uddiv3BusinessKey &=20 uddiv3ServiceKey, as defined in section 5. A businessService may=20 contain zero or more instances of uddiBindingTemplate. The=20 mandatory attribute, uddiServiceKey, contains the unique identifier=20 for a given instance of a businessService.=20 =20 businessService's definition is given in Section 6.=20 =20 4.3 bindingTemplate=20 =20 Technical descriptions of Web services are accommodated via=20 individual contained instances of bindingTemplate objects. These=20 instances provide support for determining a technical entry point or=20 optionally support remotely hosted services, as well as a=20 lightweight facility for describing unique technical characteristics=20 =20 Bergeson,Boogert & Nanjundaswamy Internet-Draft 3=20 LDAP Schema for UDDI November 2003=20 =20 =20 of a given implementation. Support for technology and application=20 specific parameters and settings files are also supported.=20 =20 Since UDDI's main purpose is to enable description and discovery of=20 Web Service information, it is the bindingTemplate that provides the=20 most interesting technical data. With UDDIv3, bindingTemplates also=20 can have categorization information.=20 =20 Each bindingTemplate instance has a single logical businessService=20 parent, which in turn has a single logical businessEntity parent.=20 =20 4.3.1 Representation in the Directory=20 =20 A bindingTemplate is represented in the directory by the attributes=20 uddiBindingKey, uddiServiceKey, uddiDescription, uddiAccessPoint,=20 uddiHostingRedirector, uddiCategoryBag and uddiv3DigitalSignature,=20 along with corresponding v3 keys viz. uddiv3ServiceKey and=20 uddiv3BindingKey, as defined in section 5. A bindingTemplate may=20 contain zero or more instances of uddiTModelInstanceDetails. The=20 mandatory attribute, uddiBindingKey, contains the unique identifier=20 for a given instance of a bindingTemplate.=20 =20 BindingTemplate's definition is given in Section 6.=20 =20 4.4 tModel=20 =20 The tModel object takes the form of keyed metadata (data about=20 data). In a general sense, the purpose of a tModel within the UDDI=20 registry is to provide a reference system based on abstraction. =20 Thus, the kind of data that a tModel represents is pretty nebulous. =20 In other words, a tModel registration can define just about=20 anything, but in the current revision, two conventions have been=20 applied for using tModels: as sources for determining compatibility=20 and as keyed namespace references.=20 =20 The information that makes up a tModel is quite simple. There's a=20 key, a name, an optional description, and a Uniform Resource Locator=20 [URL] that points somewhere--presumably somewhere where the curious=20 can go to find out more about the actual concept represented by the=20 metadata in the tModel itself.=20 =20 4.4.1 Representation in the Directory=20 =20 A tModel is represented in the directory by the attributes=20 uddiTModelKey, uddiAuthorizedName, uddiOperator, uddiName,=20 uddiDescription, uddiOverviewDescription, uddiOverviewURL,=20 uddiIdentifierBag, uddiCategoryBag, uddiIsHidden, and=20 uddiv3DigitalSignature, along with corresponding v3 key viz.=20 uddiv3tModelKey, as defined in section 5. A tModel may also contain=20 a uddiHidden to logically delete a tModel. The mandatory attribute,=20 uddiTModelKey, contains the unique identifier for a given instance=20 of a tModel.=20 =20 =20 Bergeson,Boogert & Nanjundaswamy Internet-Draft 4=20 LDAP Schema for UDDI November 2003=20 =20 =20 tModel's definition is given in Section 6.=20 =20 4.5 publisherAssertion=20 =20 Many businesses, like large enterprises or marketplaces, are not=20 effectively represented by a single businessEntity, since their=20 description and discovery are likely to be diverse. As a=20 consequence, several businessEntity instances can be published,=20 representing individual subsidiaries of a large enterprise or=20 individual participants of a marketplace. Nevertheless, they still=20 represent a more or less coupled community and would like to make=20 some of their relationships visible in their UDDI registrations. =20 =20 4.5.1 Representation in the Directory=20 =20 A publisherAssertion is represented in the directory by the=20 attributes uddiFromKey, uddiToKey, uddiKeyedReference, and uddiUUID,=20 and uddiv3DigitalSignature, as defined in section 5. The mandatory=20 attribute, uddiUUID, contains the unique identifier for a given=20 instance of a publisherAssertion.=20 =20 publisherAssertion's definition is given in Section 6.=20 =20 4.6 Operational Information:=20 =20 With UDDIv3, the operational information associated with the core=20 UDDI data structures is maintained in a separate OperationalInfo=20 structure, so that the digital signature specified by the publisher=20 remains valid. =20 =20 The operationalInfo structure is used to convey the operational=20 information for the UDDIv3 core data structures, that is, the=20 businessEntity, businessService, bindingTemplate and tModel=20 structures. UDDIv3 OperationalInfo consists of 5 elements: created.=20 Modified, modifiedIncludingChildren, nodeId and authorizedName.=20 =20 Depending on the specific UDDIv3 core data structure, the=20 operationalInformation is represented in the directory as a=20 combination of implicit LDAP Standard Operational attributes:=20 createTimestamp and modifyTimestamp, and the following explicit=20 attributes: uddiAuthorizedName, uddiv3EntityCreationTime,=20 uddiv3EntityModificationTime and uddiv3NodeId.=20 =20 5. Attribute Type Definitions=20 =20 Note that OIDs for the attribute types in this document have not=20 been assigned. All OIDs are in brackets, , as a=20 placeholder until real OIDs are assigned.=20 =20 5.1 uddiBusinessKey=20 =20 Used in uddiBusinessEntity and uddiBusinessService. =20 =20 =20 Bergeson,Boogert & Nanjundaswamy Internet-Draft 5=20 LDAP Schema for UDDI November 2003=20 =20 =20 The uddiBusinessKey is the unique identifier for a given instance of=20 an uddiBusinessEntity. The attribute is optional for businessService=20 instances contained within a fully expressed parent that already=20 contains a businessKey value.=20 =20 If the businessService instance is rendered into Extensible Markup=20 Language [XML] and has no containing parent that has within its data=20 a businessKey, the value of the businessKey that is the parent of=20 the businessService is required to be provided. This behavior=20 supports the ability to browse through the parent-child=20 relationships given any of the core elements as a starting point.=20 The businessKey may differ from the publishing businessEntity's=20 businessKey to allow service projections.=20 =20 ( IANA-ASSIGNED-OID.4.1 NAME 'uddiBusinessKey'=20 DESC 'businessEntity unique identifier'=20 EQUALITY caseIgnoreMatch=20 SYNTAX 1.3.6.1.4.1.1466.115.121.1.15=20 SINGLE-VALUE=20 )=20 =20 5.2 uddiAuthorizedName=20 =20 The uddiAuthorizedName is the recorded name of the individual that=20 published the uddiBusinessEntity or uddiTModel data. This data is=20 generated by the controlling operator and should not be supplied=20 within save_business operations. =20 =20 With UDDIv3, this attribute is part of the =91operationalInformation=92= =20 meta-data associated with core data structures.=20 =20 ( IANA-ASSIGNED-OID.4.2 NAME 'uddiAuthorizedName'=20 DESC 'businessEntity publisher name'=20 EQUALITY distinguishedNameMatch=20 SYNTAX 1.3.6.1.4.1.1466.115.121.1.12=20 SINGLE-VALUE=20 )=20 =20 5.3 uddiOperator=20 =20 The uddiOperator is the certified name of the UDDI registry site=20 operator that manages the master copy of the uddiBusinessEntity or=20 uddiTModel. The controlling operator records this data at the time=20 data is saved. This data is generated and should not be supplied=20 within save_business or save_tModel operations.=20 =20 With UDDIv3, this field is no longer used - it is replaced by the=20 nodeId (uddiv3NodeId) attribute that is part of the=20 =91operationalInformation=92 meta-data.=20 =20 ( IANA-ASSIGNED-OID.4.3 NAME 'uddiOperator'=20 DESC 'registry site operator of businessEntitys master copy'=20 EQUALITY caseIgnoreMatch=20 =20 Bergeson,Boogert & Nanjundaswamy Internet-Draft 6=20 LDAP Schema for UDDI November 2003=20 =20 =20 SYNTAX 1.3.6.1.4.1.1466.115.121.1.15=20 SINGLE-VALUE=20 )=20 =20 5.4 uddiName=20 =20 Used in uddiBusinessEntity, uddiBusinessService and uddiTModel.=20 =20 These are the human readable names recorded for the=20 uddiBusinessEntity, uddiBusinessService, or uddiTModel, adorned with=20 a unique xml:lang value to signify the language that they are=20 expressed in. Name search is provided via find_business,=20 find_service, or find_tModel calls.=20 =20 The publishing of several names, e.g. for romanization purposes, is=20 supported. In order to signify the language that the names are=20 expressed in, they carry unique xml:lang values. Not more than one=20 name element may omit specifying its language. Names passed in this=20 way will be assigned the default language code of the registering=20 party. This default language code is established at the time that=20 publishing credentials are established with an individual Operator=20 Site. If no default language is provisioned at the time a publisher=20 signs up, the operator can adopt an appropriate default language=20 code.=20 =20 With UDDIv3, multiple values with the same language code are=20 permitted. =20 =20 ( IANA-ASSIGNED-OID.4.4 NAME 'uddiName'=20 DESC 'human readable name'=20 EQUALITY caseIgnoreMatch=20 ORDERING caseIgnoreOrderingMatch=20 SUBSTR caseIgnoreSubstringsMatch=20 SYNTAX 1.3.6.1.4.1.1466.115.121.1.15=20 )=20 =20 The xml:lang value precedes the name value with the "#" character=20 used as the separator.=20 =20 5.5 uddiDescription=20 =20 The uddiDescription is an optional repeating element of one or more=20 descriptions. One description is allowed per national language code=20 supplied. With UDDIv3, there is no restriction on the number of=20 descriptions or on what xml:lang value that they may have.=20 =20 ( IANA-ASSIGNED-OID.4.5 NAME 'uddiDescription'=20 DESC 'short description'=20 EQUALITY caseIgnoreMatch=20 SYNTAX 1.3.6.1.4.1.1466.115.121.1.15=20 )=20 =20 =20 Bergeson,Boogert & Nanjundaswamy Internet-Draft 7=20 LDAP Schema for UDDI November 2003=20 =20 =20 The xml:lang value precedes the name value with the "#" character=20 used as the separator.=20 =20 5.6 uddiDiscoveryURLs=20 =20 This is a list of Uniform Resource Locators (URLs) that point to=20 alternate, file based service discovery mechanisms. Each recorded=20 uddiBusinessEntity structure is automatically assigned a URL that=20 returns the individual uddiBusinessEntity structure. URL search is=20 provided via find_business call.=20 =20 The uddiDiscoveryURLs attribute is used to hold pointers to URL=20 addressable discovery documents. The expected retrieval mechanism=20 for URLs referenced in the data within this structure is via=20 Hypertext Transfer Protocol [HTTP] HTTP-GET operation. The expected=20 return document is not defined. Rather, a framework for establishing=20 convention is provided, and two such conventions are defined within=20 UDDI behaviors. It is hoped that other conventions come about and=20 use this structure to accommodate alternate means of discovery.=20 With UDDIv3, a new convention is defined with useType as "homepage".=20 Further, a UDDIv3 server need not generate/add a discoveryURL=20 itself, since this can invalidate the digital signature of signed=20 Business Entity saved by publishers. =20 =20 ( IANA-ASSIGNED-OID.4.6 NAME 'uddiDiscoveryURLs'=20 DESC 'URL to retrieve a businessEntity instance'=20 EQUALITY caseExactMatch=20 SYNTAX 1.3.6.1.4.1.1466.115.121.1.15=20 )=20 =20 The useType value precedes the URL value with the "#" character used=20 as the separator.=20 =20 5.7 uddiUseType=20 =20 The uddiUseType is used to describe the type of contact or address=20 in freeform text. Suggested examples for contact include "technical=20 questions", "technical contact", "establish account", "sales=20 contact", etc. Suggested examples for address include=20 "headquarters", "sales office", "billing department", etc.=20 =20 ( IANA-ASSIGNED-OID.4.7 NAME 'uddiUseType'=20 DESC 'name of convention the referenced document follows'=20 EQUALITY caseIgnoreMatch=20 SYNTAX 1.3.6.1.4.1.1466.115.121.1.15=20 SINGLE-VALUE=20 )=20 =20 5.8 uddiPersonName=20 =20 The uddiPersonName should list the name of the person or name of the=20 job role that will be available behind the contact. Examples of=20 roles include "administrator" or "webmaster". =20 =20 Bergeson,Boogert & Nanjundaswamy Internet-Draft 8=20 LDAP Schema for UDDI November 2003=20 =20 =20 =20 ( IANA-ASSIGNED-OID.4.8 NAME 'uddiPersonName'=20 DESC 'name of person or job role available for contact'=20 EQUALITY caseIgnoreMatch=20 SYNTAX 1.3.6.1.4.1.1466.115.121.1.15=20 SINGLE-VALUE=20 )=20 =20 With UDDIv3, uddiPersonName becomes multi-valued and each name can=20 have an xml:lang attribute. The xml:lang value precedes the name=20 value with the "#" character used as the separator.=20 =20 =20 5.9 uddiPhone=20 =20 Used to hold telephone numbers for the contact. This element can be=20 adorned with an optional uddiUseType attribute for descriptive=20 purposes. If more than one phone element is saved, uddiUseType=20 attributes are required on each. =20 =20 ( IANA-ASSIGNED-OID.4.9 NAME 'uddiPhone'=20 DESC 'telephone number for contact'=20 EQUALITY caseIgnoreMatch=20 SYNTAX 1.3.6.1.4.1.1466.115.121.1.15=20 )=20 =20 The useType precedes the telephone number by a separating '#' (e.g.=20 "Work Number#123 456-7890")=20 =20 5.10 uddiEMail=20 =20 Used to hold email addresses for the contact. This element can be=20 adorned with an optional uddiUseType attribute for descriptive=20 purposes. If more than one email element is saved, uddiUseType=20 attributes are required on each.=20 =20 ( IANA-ASSIGNED-OID.4.10 NAME 'uddiEMail'=20 DESC 'e-mail address for contact'=20 EQUALITY caseIgnoreMatch=20 SYNTAX 1.3.6.1.4.1.1466.115.121.1.15=20 )=20 =20 The useType precedes the email address by a separating '#' (e.g.=20 "President of the United States #president@whitehouse.gov").=20 =20 5.11 uddiSortCode=20 =20 The uddiSortCode is used to drive the behavior of external display=20 mechanisms that sort addresses. The suggested values for=20 uddiSortCode include numeric ordering values (e.g. 1, 2, 3),=20 alphabetic character ordering values (e.g. a, b, c) or the first n=20 positions of relevant data within the address.=20 =20 =20 Bergeson,Boogert & Nanjundaswamy Internet-Draft 9=20 LDAP Schema for UDDI November 2003=20 =20 =20 ( IANA-ASSIGNED-OID.4.11 NAME 'uddiSortCode'=20 DESC 'specifies an external disply mechanism'=20 EQUALITY caseIgnoreMatch=20 SYNTAX 1.3.6.1.4.1.1466.115.121.1.15=20 SINGLE-VALUE=20 )=20 =20 With UDDIv3, the sortCode attribute is deprecated because of the=20 guarantee of preserving the document Order.=20 =20 5.12 uddiTModelKey=20 =20 The uddiTModelKey is the unique identifier for a given instance of=20 an uddiTModel.=20 =20 It is also used in a KeyedReference and in Address structures. When=20 used with a keyed reference, this is the unique key to identify a=20 value-set and implies that the keyName keyValue pair in an=20 uddiIdentifier or uddiCategory Bag,are to be interpreted by the=20 value set referenced by the tModelKey. =20 =20 When used with Addressline elements, implies that the keyName=20 keyValue pair given by subsequent uddiAddressLine elements are to be=20 interpreted by the address structure associated with the tModel that=20 is referenced.=20 =20 ( IANA-ASSIGNED-OID.4.12 NAME 'uddiTModelKey'=20 DESC 'tModel unique identifier'=20 EQUALITY caseIgnoreMatch=20 SYNTAX 1.3.6.1.4.1.1466.115.121.1.15=20 SINGLE-VALUE=20 )=20 =20 5.13 uddiAddressLine=20 =20 The uddiAddressLine contains the actual address in freeform text. If=20 the address element contains a uddiTModelKey, these uddiAddressLine=20 elements are to be adorned each with an optional keyName keyValue=20 attribute pair. Together with the uddiTModelKey, keyName and=20 keyValue qualify the uddiAddressLine in order to describe its=20 meaning.=20 =20 The uddiAddressLine elements contain string data with a line length=20 limit of 80 character positions. Each uddiAddressLine element can be=20 adorned with two optional descriptive attributes, keyName and=20 keyValue. Both attributes must be present in each address line if a=20 uddiTModelKey is assigned to the address structure. By doing this,=20 the otherwise arbitrary use of address lines becomes structured.=20 Together with the address' uddiTModelKey, keyName and keyValue=20 virtually build a uddiKeyedReference that represents an address line=20 qualifier, given by the referenced uddiTModel. =20 =20 =20 Bergeson,Boogert & Nanjundaswamy Internet-Draft 10=20 LDAP Schema for UDDI November 2003=20 =20 =20 When no uddiTModelKey is provided for the address structure, the=20 keyName and keyValue attributes can be used without restrictions,=20 for example, to provide descriptive information for each=20 uddiAddressLine by using the keyName attribute. Since both the=20 keyName and the keyValue attributes are optional, address line order=20 is significant and will always be returned by the UDDI compliant=20 registry in the order originally provided during a call to=20 save_business.=20 =20 ( IANA-ASSIGNED-OID.4.13 NAME 'uddiAddressLine'=20 DESC 'address'=20 EQUALITY caseIgnoreMatch=20 SYNTAX 1.3.6.1.4.1.1466.115.121.1.15=20 )=20 =20 The keyName, keyValue, and addressData of this attribute are=20 separated by "#", (e.g. "#""#""#"). =20 The addressData is the only required portion of the attribute.=20 =20 5.14 uddiIdentifierBag=20 =20 The uddiIdentifierBag element allows uddiBusinessEntity or=20 uddiTModel structures to include information about common forms of=20 identification such as D-U-N-S_ numbers, tax identifiers, etc. This=20 data can be used to signify the identity of the uddiBusinessEntity,=20 or can be used to signify the identity of the publishing party.=20 Including data of this sort is optional, but when used greatly=20 enhances the search behaviors exposed via the find_xx messages=20 defined in the UDDI Version 2.0 API Specification [UDDI]. For a full=20 description of the structures involved in establishing an identity,=20 see UDDI Version 2.0 Data Structure Specification - Appendix A:=20 Using Identifiers.=20 =20 ( IANA-ASSIGNED-OID.4.14 NAME 'uddiIdentifierBag'=20 DESC 'identification information'=20 EQUALITY caseIgnoreMatch=20 SYNTAX 1.3.6.1.4.1.1466.115.121.1.15=20 )=20 =20 The tModel, keyName, and keyValue of this attribute are separated by=20 "#", (e.g. "#""#"). The keyValue is the=20 only required portion of the attribute.=20 =20 5.15 uddiCategoryBag=20 =20 The uddiCategoryBag element allows uddiBusinessEntity,=20 uddiBusinessService and uddiTModel structures to be categorized=20 according to any of several available taxonomy based classification=20 schemes. Operator Sites automatically provide validated=20 categorization support for three taxonomies that cover industry=20 codes (via NAICS), product and service classifications (via UNSPC)=20 and geography (via ISO 3166). Including data of this sort is=20 optional, but when used greatly enhances the search behaviors=20 =20 Bergeson,Boogert & Nanjundaswamy Internet-Draft 11=20 LDAP Schema for UDDI November 2003=20 =20 =20 exposed by the find_xx messages defined in the UDDI Version 2.0 API=20 Specification. For a full description of structures involved in=20 establishing categorization information, see UDDI Version 2.0 Data=20 Structure Specification - Appendix B: Using categorization.=20 =20 ( IANA-ASSIGNED-OID.4.15 NAME 'uddiCategoryBag'=20 DESC 'categorization information'=20 EQUALITY caseIgnoreMatch=20 SYNTAX 1.3.6.1.4.1.1466.115.121.1.15=20 )=20 =20 The tModel, keyName, and keyValue of this attribute are separated by=20 "#", (e.g. "#""#"). The keyValue is the=20 only required portion of the attribute.=20 =20 With UDDIv3, uddiBindingTemplates also supports the uddiCategoryBag=20 element and they can also be categorized according to any of several=20 available taxonomy based classification schemes.=20 =20 5.16 uddiKeyedReference=20 =20 The uddiKeyedReference is a general-purpose attribute for a name- value pair, with an additional reference to a tModel.=20 =20 ( IANA-ASSIGNED-OID.4.16 NAME 'uddiKeyedReference'=20 DESC 'categorization information'=20 EQUALITY caseIgnoreMatch=20 SYNTAX 1.3.6.1.4.1.1466.115.121.1.15=20 )=20 =20 The tModel, keyName, and keyValue of this attribute are separated by=20 "#", (e.g. "#""#"). The keyValue is the=20 only required portion of the attribute. With UDDIv3, the tModelKey=20 also becomes mandatory part of the attribute. =20 =20 Also, UDDIv3 defines KeyedReferenceGroups for CategoryBags. A=20 keyedReferenceGroup contains a tModelKey and a simple list of=20 KeyedReference structures. The uddiKeyedReference attribute will=20 support KeyedReferenceGroups by suffixing the tModelKey for=20 KEyedReferenceGroup to each of the keyedReference values associated=20 with the group.=20 e.g. to represent a keyedReference group containing a list of 2=20 keyed references, the attribute will hold the following 2 strings as=20 its values:=20 tModelKey1#KeyName1#KeyValue1#KeyedReferenceGroup1_tModelKey=20 tModelKey2#KeyName2#KeyValue2#KeyedReferenceGroup1_tModelKey=20 =20 =20 5.17 uddiServiceKey=20 =20 This is the unique key for a given uddiBusinessService. When saving=20 a new uddiBusinessService structure, pass an empty uddiServiceKey=20 value. This signifies that a UUID value is to be generated. To=20 =20 Bergeson,Boogert & Nanjundaswamy Internet-Draft 12=20 LDAP Schema for UDDI November 2003=20 =20 =20 update an existing uddiBusinessService structure, pass the UUID=20 value that corresponds to the existing service. If an uddiServiceKey=20 is received via an inquiry operation, the key values may not be=20 blank. When saving a new or updated service projection, pass the=20 uddiServiceKey of the referenced uddiBusinessService structure.=20 =20 This attribute is optional when the uddiBindingTemplate data is=20 contained within a fully expressed parent that already contains a=20 uddiServiceKey value. If the uddiBindingTemplate data is rendered=20 into XML and has no containing parent that has within its data a=20 uddiServiceKey, the value of the uddiServiceKey that is the ultimate=20 containing parent of the uddiBindingTemplate is required to be=20 provided. This behavior supports the ability to browse through the=20 parent-child relationships given any of the core elements as a=20 starting point.=20 =20 ( IANA-ASSIGNED-OID.4.17 NAME 'uddiServiceKey'=20 DESC 'businessService unique identifier'=20 EQUALITY caseIgnoreMatch=20 SYNTAX 1.3.6.1.4.1.1466.115.121.1.15=20 SINGLE-VALUE=20 )=20 =20 5.18 uddiBindingKey=20 =20 This is the unique key for a given uddiBindingTemplate. When saving=20 a new uddiBindingTemplate structure, pass an empty uddiBindingKey=20 value. This signifies that a UUID value is to be generated. To=20 update an existing uddiBindingTemplate, pass the UUID value that=20 corresponds to the existing uddiBindingTemplate instance. If an=20 uddiBindingKey is received via an inquiry operation, the key values=20 may not be blank.=20 =20 ( IANA-ASSIGNED-OID.4.18 NAME 'uddiBindingKey'=20 DESC 'bindingTemplate unique identifier'=20 EQUALITY caseIgnoreMatch=20 SYNTAX 1.3.6.1.4.1.1466.115.121.1.15=20 SINGLE-VALUE=20 )=20 =20 5.19 uddiAccessPoint=20 =20 The uddiAccessPoint element is an attribute-qualified pointer to a=20 service entry point. The notion of service at the metadata level=20 seen here is fairly abstract and many types of entry points are=20 accommodated. A single attribute is provided named URLType.=20 =20 Required attribute qualified element8. This element is a text field=20 that is used to convey the entry point address suitable for calling=20 a particular Web service. This may be a URL, an electronic mail=20 address, or even a telephone number. No assumptions about the type=20 of data in this field can be made without first understanding the=20 technical requirements associated with the Web service.=20 =20 Bergeson,Boogert & Nanjundaswamy Internet-Draft 13=20 LDAP Schema for UDDI November 2003=20 =20 =20 =20 ( IANA-ASSIGNED-OID.4.19 NAME 'uddiAccessPoint'=20 DESC 'entry point address to call a web service'=20 EQUALITY caseExactMatch=20 SYNTAX 1.3.6.1.4.1.1466.115.121.1.15=20 SINGLE-VALUE=20 )=20 =20 The URLType value precedes the accessPoint value by a separating=20 '#'.=20 =20 With UDDIv3,the =91URLType=92 attribute is replaced by a =91UseType=92= =20 attribute. Using this UseType attribute, the accessPoint attribute=20 can model a hostingRedirector or support indirection to indicate the=20 accesspoint is specified within a remotely hosted WSDL document. =20 =20 For a UDDIv3 registry that needs support UDDIv2 clients, the=20 attribute must allow representing the URLType and UseType values=20 independently. =20 =20 The UDDIv3 spec specifies the following logic for mapping values=20 between URLType and UseType: If an entity is saved with the v3=20 namespace and a v2 inquiry is made, the URLType will be returned as=20 "other". In the case when a v3 inquiry is made on an entity=20 published with the v2 namespace, the v3 useType attribute will be=20 returned as "endPoint".=20 =20 For implementations that need to explicitly model both forms, the=20 recommended format is as follows: v2URLType#v3UseType#Address=20 =20 5.20 uddiHostingRedirector=20 =20 The uddiHostingRedirector element is used to designate that a=20 uddiBindingTemplate entry is a pointer to a different=20 uddiBindingTemplate entry. The value in providing this facility is=20 seen when a business or entity wants to expose a service description=20 (e.g. advertise that they have a service available that suits a=20 specific purpose) that is actually a service that is described in a=20 separate uddiBindingTemplate record. This might occur when a service=20 is remotely hosted (hence the name of this element), or when many=20 service descriptions could benefit from a single service=20 description.=20 =20 The uddiHostingRedirector element has a single attribute and no=20 element content. The attribute is a uddiBindingKey value that is=20 suitable within the same UDDI registry instance for querying and=20 obtaining the uddiBindingDetail data that is to be used.=20 =20 More on the uddiHostingRedirector can be found in the appendices for=20 the UDDI Version 2.0 API Specification.=20 =20 Required element if uddiAccessPoint not provided. This element is=20 adorned with a uddiBindingKey attribute, giving the redirected=20 =20 Bergeson,Boogert & Nanjundaswamy Internet-Draft 14=20 LDAP Schema for UDDI November 2003=20 =20 =20 reference to a different uddiBindingTemplate. If you query a=20 uddiBindingTemplate and find a uddiHostingRedirector value, you=20 should retrieve that uddiBindingTemplate and use it in place of the=20 one containing the uddiHostingRedirector data. =20 =20 ( IANA-ASSIGNED-OID.4.20 NAME 'uddiHostingRedirector'=20 DESC 'designates a pointer to another bindingTemplate'=20 EQUALITY caseIgnoreMatch=20 SYNTAX 1.3.6.1.4.1.1466.115.121.1.15=20 SINGLE-VALUE=20 )=20 =20 With UDDIv3, the hostingRedirector is a deprecated element, since=20 its functionality is now covered by the accessPoint. For backward- compatibility, it can still be used, but it is not recommended.=20 =20 5.21 uddiInstanceDescription=20 =20 This is an optional repeating element. This is one or more language=20 qualified text descriptions that designate what role a uddiTModel=20 reference plays in the overall service description.=20 =20 ( IANA-ASSIGNED-OID.4.21 NAME 'uddiInstanceDescription'=20 DESC 'instance details description'=20 EQUALITY caseIgnoreMatch=20 SYNTAX 1.3.6.1.4.1.1466.115.121.1.15=20 )=20 =20 The xml:lang value precedes the name value with the "#" character=20 used as the separator.=20 =20 5.22 uddiInstanceParms=20 =20 The uddiInstance Parms is an Optional element of the uddiInstance.=20 Used to contain settings parameters or a URL reference to a file=20 that contains settings or parameters required to use a specific=20 facet of a uddiBindingTemplate description. If used to house the=20 parameters themselves, the suggested content is a namespace=20 qualified XML string - - using a namespace outside of the UDDI schema.=20 If used to house a URL pointer to a file, the suggested format is=20 URL that is suitable for retrieving the settings or parameters via=20 HTTP-GET.=20 =20 ( IANA-ASSIGNED-OID.4.22 NAME 'uddiInstanceParms'=20 DESC 'URL reference to required settings'=20 EQUALITY caseIgnoreMatch=20 SYNTAX 1.3.6.1.4.1.1466.115.121.1.15=20 SINGLE-VALUE=20 )=20 =20 5.23 uddiOverviewDescription=20 =20 =20 Bergeson,Boogert & Nanjundaswamy Internet-Draft 15=20 LDAP Schema for UDDI November 2003=20 =20 =20 This is optional repeating element. This language-qualified string=20 is intended to hold a short descriptive overview of how a particular=20 uddiTModel is to be used.=20 =20 ( IANA-ASSIGNED-OID.4.23 NAME 'uddiOverviewDescription'=20 DESC 'outlines tModel usage'=20 EQUALITY caseIgnoreMatch=20 SYNTAX 1.3.6.1.4.1.1466.115.121.1.15=20 )=20 =20 The xml:lang value precedes the name value with the "#" character=20 used as the separator.=20 =20 5.24 uddiOverviewURL=20 =20 This is an optional element. This string data element is to be used=20 to hold a URL reference to a long form of an overview document that=20 covers the way a particular uddiTModel specific reference is used as=20 a component of an overall web service description. The recommended=20 format for the overviewURL is a URI that is suitable for retrieving=20 the actual overview document with an HTTP GET operation, for=20 example, via a Web browser.=20 =20 ( IANA-ASSIGNED-OID.4.24 NAME 'uddiOverviewURL'=20 DESC 'URL reference to overview document'=20 EQUALITY caseExactMatch=20 SYNTAX 1.3.6.1.4.1.1466.115.121.1.15=20 SINGLE-VALUE=20 )=20 =20 With UDDIv3, uddiOverviewURL becomes multi-valued, to allow=20 representing multiple OverviewDocs within a single InstanceDetail=20 element.=20 =20 Modeling multiple OverviewDocs within an InstanceDetail element:=20 In UDDIv3, InstanceDetails element in TmodelInstanceInfo can have=20 multiple OverviewDoc=92s. In UDDIv2, we could have only 1 OverviewDoc.= =20 To retain the grouping between a set of overviewDescriptions and=20 overviewURL, we can make both OverviewDoc and OverviewURL multi- valued. And have a =91group ID=92 Prefix to each value (to group=20 OverviewDescriptions and OverviewURL). =20 =20 An example is shown below:=20 Overview Description OverviewURL=20 1#xml:lang#overviewDescription1 1#UseType#overviewURL=20 1#xml:lang#overviewDescription2 2#UseType#overviewURL=20 1#xml:lang#overviewDescription3 4#UseType#overviewURL=20 3#xml:lang#overviewDescription1=20 3#xml:lang#overviewDescription2=20 4#xml:lang#overviewDescription1=20 =20 This implies that OverviewDoc1 has 3 overview descriptions and an=20 overviewURL. OverviewDoc2 has only an overviewURL. OverviewDoc3 has=20 =20 Bergeson,Boogert & Nanjundaswamy Internet-Draft 16=20 LDAP Schema for UDDI November 2003=20 =20 =20 only 2 overviewDescriptions. OverviewDoc4 also has 1 overview=20 description and an overviewURL.=20 =20 5.25 uddiFromKey=20 =20 The uddiFromKey is a required element. This is the unique key=20 reference to the first uddiBusinessEntity the assertion is made for.=20 =20 ( IANA-ASSIGNED-OID.4.25 NAME 'uddiFromKey'=20 DESC 'unique businessEntity key reference'=20 EQUALITY caseIgnoreMatch=20 SYNTAX 1.3.6.1.4.1.1466.115.121.1.15=20 SINGLE-VALUE=20 )=20 =20 5.26 uddiToKey=20 =20 The uddiToKey is a required element. This is the unique key=20 reference to the second uddiBusinessEntity the assertion is made=20 for.=20 =20 ( IANA-ASSIGNED-OID.4.26 NAME 'uddiToKey'=20 DESC 'unique businessEntity key reference'=20 EQUALITY caseIgnoreMatch=20 SYNTAX 1.3.6.1.4.1.1466.115.121.1.15=20 SINGLE-VALUE=20 )=20 =20 5.27 uddiUUID=20 =20 The uddiUUID is a required element. This is to insure unique=20 identification of uddiContact, uddiAddress, and=20 uddiPublisherAssertion objects.=20 =20 ( IANA-ASSIGNED-OID.4.27 NAME 'uddiUUID'=20 DESC 'unique attribute'=20 EQUALITY caseIgnoreMatch=20 SYNTAX 1.3.6.1.4.1.1466.115.121.1.15=20 SINGLE-VALUE=20 )=20 =20 With UDDIv3, this attribute will also be used for unique=20 identification of Subscription feature related entities.=20 =20 5.28 uddiIsHidden=20 =20 Used to provide functionality for the delete_tModel operation. =20 Logical deletion hides the deleted tModels from find_tModel result=20 sets but does not physically delete it.=20 =20 ( IANA-ASSIGNED-OID.4.28 NAME 'uddiIsHidden'=20 DESC 'isHidden attribute'=20 EQUALITY booleanMatch=20 =20 Bergeson,Boogert & Nanjundaswamy Internet-Draft 17=20 LDAP Schema for UDDI November 2003=20 =20 =20 SYNTAX 1.3.6.1.4.1.1466.115.121.1.7=20 SINGLE-VALUE=20 )=20 =20 In case of UDDIv3, this attribute will represent the =91deleted=92=20 attribute value. =20 =20 5.29 uddiIsProjection=20 =20 Used to identify a Business Service that as a Service Projection. =20 =20 ( IANA-ASSIGNED-OID.4.29 NAME 'uddiIsProjection'=20 DESC 'isServiceProjection attribute'=20 EQUALITY booleanMatch=20 SYNTAX 1.3.6.1.4.1.1466.115.121.1.7=20 SINGLE-VALUE=20 )=20 =20 5.30 uddiLang=20 =20 Used to model the xml:lang value for the Address structure in=20 UDDIv3. =20 =20 ( IANA-ASSIGNED-OID.4.30 NAME 'uddiLang'=20 DESC 'xml:lang value in v3 Address structure=92=20 EQUALITY booleanMatch=20 SYNTAX 1.3.6.1.4.1.1466.115.121.1.7=20 SINGLE-VALUE=20 )=20 =20 The following are attribute definitions to model new elements/fields=20 in UDDIv3 information model. These attribute definitions have the=20 =91uddiv3=92 prefix to indicate that these attributes represent UDDI=20 information model elements unique to UDDIv3.=20 =20 5.31 uddiv3BusinessKey=20 =20 This is the unique UDDIv3 identifier for a given instance of=20 uddiBusinessEntity. Used in uddiBusinessEntity and=20 uddiBusinessService. =20 =20 A uddiBusinessEntity will include the uddiBusinessKey (the v2 form)=20 for unique identification by UDDIv2 clients. The uddiBusinessKey=20 (36-char) will also be the LDAP naming attribute for the=20 uddiBusinessEntity. The uddiBusinessEntity entry MAY also include=20 the uddiv3BusinessKey, the explicit v3 form key, which can be 255=20 characters long.=20 =20 ( IANA-ASSIGNED-OID.4.31 NAME 'uddiv3BusinessKey'=20 DESC 'UDDIv3 businessEntity unique identifier'=20 EQUALITY caseIgnoreMatch=20 SYNTAX 1.3.6.1.4.1.1466.115.121.1.15=20 SINGLE-VALUE=20 =20 Bergeson,Boogert & Nanjundaswamy Internet-Draft 18=20 LDAP Schema for UDDI November 2003=20 =20 =20 )=20 =20 5.32 uddiv3ServiceKey=20 =20 This is the unique UDDIv3 identifier for a given instance of=20 uddiBusinessService. Used in uddiBusinessService and=20 uddiBindingTemplate. =20 =20 A uddiBusinessService will include the uddiServiceKey (the v2 form)=20 for unique identification by UDDIv2 clients. The uddiServiceKey (36- char) will also be the LDAP naming attribute for the=20 uddiBusinessService entry. The uddiBusinessService entry MAY also=20 include the uddiv3ServiceKey, the explicit v3 form key, which can be=20 255 characters long.=20 =20 ( IANA-ASSIGNED-OID.4.32 NAME 'uddiv3ServiceKey'=20 DESC 'UDDIv3 businessService unique identifier'=20 EQUALITY caseIgnoreMatch=20 SYNTAX 1.3.6.1.4.1.1466.115.121.1.15=20 SINGLE-VALUE=20 )=20 =20 5.33 uddiv3BindingKey=20 =20 This is the unique UDDIv3 identifier for a given instance of=20 uddiBindingTemplate. =20 =20 A uddiBindingTemplate will include the uddiBindingKey (the v2 form)=20 for unique identification by UDDIv2 clients. The uddiBindingKey (36- char) will also be the LDAP naming attribute for the=20 uddiBindingTemplate entry. The uddiBindingTemplate entry MAY also=20 include the uddiv3BindingKey, the explicit v3 form key, which can be=20 255 characters long.=20 =20 ( IANA-ASSIGNED-OID.4.33 NAME 'uddiv3BindingKey'=20 DESC 'UDDIv3 BindingTemplate unique identifier'=20 EQUALITY caseIgnoreMatch=20 SYNTAX 1.3.6.1.4.1.1466.115.121.1.15=20 SINGLE-VALUE=20 )=20 =20 5.34 uddiv3TModelKey=20 =20 This is the unique UDDIv3 identifier for a given instance of an=20 uddiTModel.=20 =20 A uddiTModel will include the uddiTModelKey (the v2 form) for unique=20 identification by UDDIv2 clients. The uddiTModelKey (41-char) will=20 also be the LDAP naming attribute for the uddiTModel entry. The=20 uddiTModel entry MAY also include the uddiv3TModelKey, the explicit=20 v3 form key, which can be 255 characters long.=20 =20 ( IANA-ASSIGNED-OID.4.34 NAME 'uddiv3TModelKey'=20 =20 Bergeson,Boogert & Nanjundaswamy Internet-Draft 19=20 LDAP Schema for UDDI November 2003=20 =20 =20 DESC 'UDDIv3 TModel unique identifier'=20 EQUALITY caseIgnoreMatch=20 SYNTAX 1.3.6.1.4.1.1466.115.121.1.15=20 SINGLE-VALUE=20 )=20 =20 The tModelKey is also used in a KeyedReference and in Address=20 structures. At all places, where a tModelKey is used as a reference=20 to tModel, the v3 form of the tModel key (viz. uddiv3TModelKey) will=20 be the form used, since using the v2 form key will require=20 translating it to the v3 key by the UDDI Server and this may=20 invalidate the digital signature of the entity. =20 =20 5.35 uddiv3DigitalSignature=20 =20 The UDDIv3 v3 schema supports signing of the following UDDI elements=20 using =91XML-Signature Syntax and Processing=92 (see=20 http://www.w3.org/TR/xmldsig-core/).=20 ..businessEntity=20 ..businessService=20 ..bindingTemplate=20 ..tModel=20 ..publisherAssertion=20 =20 This uddiv3DigitalSignature attribute holds the digital signature=20 for the corresponding UDDI entity.=20 =20 ( IANA-ASSIGNED-OID.4.35 NAME 'uddiv3DigitalSignature'=20 DESC 'UDDIv3 entity digital signature'=20 EQUALITY caseIgnoreMatch=20 SYNTAX 1.3.6.1.4.1.1466.115.121.1.15=20 )=20 =20 A Signature element SHOULD be generated according to the required=20 steps of "Core Generation" in XML-Signature Syntax and Processing.=20 The signature should be calculated on the top level element that=20 will be stored by the registry as a result of the Publication API=20 call. This element, referred to as the data object in the=20 XMLSignature and Syntax specification, is the businessEntity element=20 for save_business API calls, the businessService element for=20 save_service API calls, the bindingTemplate for save_binding=20 API calls, the tModel for save_tModel API calls and the=20 publisherAssertion for set_publisherAssertions and=20 add_publisherAssertion API calls. =20 =20 The signature should be generated on the elements before they are=20 added to the body of an API call. Also, according to the signature=20 generation, all children of the element being signed are included in=20 the generation of the signature unless first excluded by application=20 of a transform. Due to the containment of service projections as=20 businessService elements within a businessEntity element, this also=20 means that changes to the projected service will render a signature=20 of the businessEntity containing the projection invalid, unless a=20 =20 Bergeson,Boogert & Nanjundaswamy Internet-Draft 20=20 LDAP Schema for UDDI November 2003=20 =20 =20 businessService element representing a service projection is=20 excluded using a transform.=20 =20 Due to the location of the sequence of Signature elements within an=20 element that is to be signed, the signature is "enveloped". As a=20 result of the enveloping of the signature, it is necessary to apply=20 at least one transformation on the signed entity to exclude the=20 signature or signature(s). The transformation selected by a=20 publisher or the XML Signature tool is specified in a Transform=20 element inside the Signature element. =20 =20 5.36 uddiv3NodeId=20 =20 This attribute contains the Node Identity for a UDDIv3 node. =20 =20 ( IANA-ASSIGNED-OID.4.36 NAME 'uddiv3NodeId'=20 DESC 'UDDIv3 Node Identifier'=20 EQUALITY caseIgnoreMatch=20 SYNTAX 1.3.6.1.4.1.1466.115.121.1.15=20 SINGLE-VALUE=20 )=20 =20 5.37 uddiv3EntityModificationTime=20 =20 This attribute is used to maintain the last modification time for a=20 UDDI entity. It is needed in context of maintaining the=20 modifiedIncludingChildren element. When a child entity (e.g.=20 uddiBindingTemplate) is updated, the parent entity (e.g.=20 uddiBusinessService) LDAP timestamp also gets updated. The=20 uddiv3EntityModificationTime attribute saves the last modification=20 time of the parent entity (uddiBusinessService in this case). =20 =20 ( IANA-ASSIGNED-OID.4.37 NAME 'uddiv3EntityModificationTime'=20 DESC 'UDDIv3 Last Modified Time for Entity'=20 EQUALITY caseIgnoreMatch=20 SYNTAX 1.3.6.1.4.1.1466.115.121.1.15=20 SINGLE-VALUE=20 )=20 =20 =20 The following attribute definitions define attributes related to=20 modeling of UDDIv3 subscription related entities in LDAP directory.=20 =20 Subscription provides clients, known as subscribers, with the=20 ability to register their interest in receiving information=20 concerning changes made in a UDDI registry. These changes can be=20 scoped based on preferences provided with the request. The=20 uddiv3Subscription object class is used to model registered UDDIv3=20 Subscriptions. =20 =20 5.38 uddiv3SubscriptionKey=20 =20 =20 Bergeson,Boogert & Nanjundaswamy Internet-Draft 21=20 LDAP Schema for UDDI November 2003=20 =20 =20 This is the unique UDDIv3 identifier for a given instance of a=20 uddiv3Subscription entity. =20 =20 ( IANA-ASSIGNED-OID.4.38 NAME 'uddiv3SubscriptionKey'=20 DESC 'UDDIv3 Subscription unique identifier'=20 EQUALITY caseIgnoreMatch=20 SYNTAX 1.3.6.1.4.1.1466.115.121.1.15=20 SINGLE-VALUE=20 )=20 =20 5.39 uddiv3SubscriptionFilter=20 =20 This attribute contains the UDDIv3 Subscription Filter, specified as=20 part of the save_subscription API i.e. the Inquiry API specified as=20 filtering criteria with a registered subscription. The filtering=20 criteria limits the scope of a subscription to a subset of registry=20 records. The get_xx and find_xx APIs are all valid choices for use=20 as a subscriptionFilter. Only one of these can be chosen for each=20 subscription.=20 =20 ( IANA-ASSIGNED-OID.4.39 NAME 'uddiv3SubscriptionFilter'=20 DESC 'UDDIv3 Subscription Filter=92=20 EQUALITY caseIgnoreMatch=20 SYNTAX 1.3.6.1.4.1.1466.115.121.1.15=20 SINGLE-VALUE=20 )=20 =20 5.40 uddiv3NotificationInterval=20 =20 This attribute contains the Notification Interval string. It is of=20 type xsd:duration and specifies how often Asynchronous change=20 notifications are to be provided to a subscriber.=20 =20 ( IANA-ASSIGNED-OID.4.40 NAME 'uddiv3NotificationInterval'=20 DESC 'UDDIv3 Notification Interval=92=20 EQUALITY caseIgnoreMatch=20 SYNTAX 1.3.6.1.4.1.1466.115.121.1.15=20 SINGLE-VALUE=20 )=20 =20 5.41 uddiv3MaxEntities=20 =20 This attribute contains the maximum number of entities to be=20 returned as part of a subscription notification. It is an integer=20 and specifies the maximum number of entities in a notification=20 returned to a subscription listener.=20 =20 ( IANA-ASSIGNED-OID.4.41 NAME 'uddiv3MaxEntities'=20 DESC 'UDDIv3 Subscription maxEntities field=92=20 EQUALITY integerMatch=20 SYNTAX 1.3.6.1.4.1.1466.115.121.1.27=20 SINGLE-VALUE=20 )=20 =20 Bergeson,Boogert & Nanjundaswamy Internet-Draft 22=20 LDAP Schema for UDDI November 2003=20 =20 =20 =20 5.42 uddiv3ExpiresAfter=20 =20 This attribute specifies the Expiry Time associated with a=20 Subscription. It is of the XML Schema type xsd:dateTime. =20 =20 ( IANA-ASSIGNED-OID.4.42 NAME 'uddiv3ExpiresAfter'=20 DESC 'UDDIv3 Subscription ExpiresAfter field=92=20 EQUALITY caseIgnoreMatch=20 SYNTAX 1.3.6.1.4.1.1466.115.121.1.15=20 SINGLE-VALUE=20 )=20 =20 =20 5.43 uddiv3BriefResponse=20 =20 This attribute is a Boolean flag for Brief Response associated with=20 a Subscription entity. It controls the level of detail returned to a=20 subscription listener. The default is "false" when omitted. When set=20 to "true," it indicates that the subscription results are to be=20 returned to the subscriber in the form of a keyBag, listing all of=20 the entities that matched the subscriptionFilter.=20 =20 ( IANA-ASSIGNED-OID.4.43 NAME 'uddiv3BriefResponse'=20 DESC 'UDDIv3 Subscription ExpiresAfter field=92=20 EQUALITY booleanMatch=20 SYNTAX 1.3.6.1.4.1.1466.115.121.1.7=20 SINGLE-VALUE=20 )=20 =20 5.44 uddiv3EntityKey=20 =20 This is the unique UDDIv3 identifier for a given instance of a core=20 UDDI data structure that is to be logged as an Obituary Entry=20 uddiv3EntityObituary. When a core UDDIv3 entity is deleted and there=20 is an active subscription registered against this UDDI entity, an=20 Obituary entry is created, in which the v3 key of the deleted entry=20 is logged as part of the uddiv3EntityKey attribute. =20 =20 ( IANA-ASSIGNED-OID.4.44 NAME 'uddiv3EntityKey'=20 DESC 'UDDIv3 Entity unique identifier'=20 EQUALITY caseIgnoreMatch=20 SYNTAX 1.3.6.1.4.1.1466.115.121.1.15=20 SINGLE-VALUE=20 )=20 =20 5.45 uddiv3EntityCreationTime=20 =20 This attribute is used to log the original Creation Time for a UDDI=20 Entity that is deleted, in the uddiv3EntityObituary entry. =20 =20 It is also used in uddiBusinessService and uddiBindingTemplate. A=20 Move BS operation needs to delete and recreate BT sub-tree due to=20 =20 Bergeson,Boogert & Nanjundaswamy Internet-Draft 23=20 LDAP Schema for UDDI November 2003=20 =20 =20 lack of support for moving a sub-tree in many LDAPv3 servers. This=20 attribute is used to save the original creation time of the BT=20 during a Move BS.=20 =20 ( IANA-ASSIGNED-OID.4.45 NAME 'uddiv3EntityCreationTime'=20 DESC 'UDDIv3 Entity Creation Time'=20 EQUALITY caseIgnoreMatch=20 SYNTAX 1.3.6.1.4.1.1466.115.121.1.15=20 SINGLE-VALUE=20 )=20 =20 5.46 uddiv3EntityDeletionTime=20 =20 This attribute is used to log the entity deletion time for a UDDI=20 Entity that is deleted, in the uddiv3EntityObituary entry. =20 =20 ( IANA-ASSIGNED-OID.4.46 NAME 'uddiv3EntityDeletionTime'=20 DESC 'UDDIv3 Entity Deletion Time'=20 EQUALITY caseIgnoreMatch=20 SYNTAX 1.3.6.1.4.1.1466.115.121.1.15=20 SINGLE-VALUE=20 )=20 =20 6. Object Class Definitions=20 =20 Note that OIDs for the object classes in this document have not been=20 assigned. All OIDs are in brackets, , as a placeholder=20 until real OIDs are assigned.=20 =20 6.1 uddiBusinessEntity=20 =20 This structural object class represents a businessEntity.=20 =20 ( IANA-ASSIGNED-OID.6.1 NAME 'uddiBusinessEntity'=20 SUP top=20 STRUCTURAL=20 MUST ( uddiBusinessKey $ =20 uddiName)=20 MAY ( uddiAuthorizedName $ =20 uddiOperator $ =20 uddiDiscoveryURLs $ =20 uddiDescription $ =20 uddiIdentifierBag $ =20 uddiCategoryBag $=20 uddiv3BusinessKey $=20 uddiv3DigitalSignature $=20 uddiv3EntityModificationTime $=20 uddiv3NodeId)=20 )=20 =20 6.2 uddiContact=20 =20 =20 Bergeson,Boogert & Nanjundaswamy Internet-Draft 24=20 LDAP Schema for UDDI November 2003=20 =20 =20 This structural object class represents a contact. It is contained=20 by an uddiBusinessEntity.=20 =20 ( IANA-ASSIGNED-OID.6.2 NAME 'uddiContact'=20 SUP top=20 STRUCTURAL=20 MUST ( uddiPersonName $ =20 uddiUUID )=20 MAY ( uddiUseType $ =20 uddiDescription $ =20 uddiPhone $ =20 uddiEMail )=20 )=20 =20 6.3 uddiAddress=20 =20 This structural object class represents an address. It is contained=20 by an uddiContact.=20 =20 ( IANA-ASSIGNED-OID.6.3 NAME 'uddiAddress'=20 SUP top=20 STRUCTURAL=20 MUST ( uddiUUID )=20 MAY ( uddiUseType $ =20 uddiSortCode $ =20 uddiTModelKey $=20 uddiv3TmodelKey $ =20 uddiAddressLine $=20 uddiLang)=20 )=20 =20 6.4 uddiBusinessService=20 =20 This structural object class represents a businessService.=20 =20 ( IANA-ASSIGNED-OID.6.4 NAME 'uddiBusinessService'=20 SUP top=20 STRUCTURAL=20 MUST ( uddiServiceKey $ =20 uddiName )=20 MAY ( uddiBusinessKey $ =20 uddiDescription $ =20 uddiCategoryBag $=20 uddiv3ServiceKey $=20 uddiv3BusinessKey $=20 uddiv3DigitalSignature $=20 uddiv3EntityCreationTime $=20 uddiv3EntityModificationTime $=20 uddiv3NodeId)=20 )=20 =20 6.5 uddiBindingTemplate=20 =20 =20 Bergeson,Boogert & Nanjundaswamy Internet-Draft 25=20 LDAP Schema for UDDI November 2003=20 =20 =20 This structural object class represents a bindingTemplate.=20 =20 ( IANA-ASSIGNED-OID.6.5 NAME 'uddiBindingTemplate'=20 SUP top=20 STRUCTURAL=20 MUST ( uddiBindingKey )=20 MAY ( uddiServiceKey $ =20 uddiDescription $ =20 uddiAccessPoint $=20 uddiHostingRedirector =20 uddiCategoryBag $=20 uddiv3BindingKey $=20 uddiv3ServiceKey $=20 uddiv3DigitalSignature $=20 uddiv3EntityCreationTime $=20 uddiv3NodeId)=20 )=20 =20 =20 6.6 uddiTModelInstanceInfo=20 =20 This structural object class represents a tModelInstanceInfo. It is=20 contained by an uddiBindingTemplate.=20 =20 ( IANA-ASSIGNED-OID.6.6 NAME 'uddiTModelInstanceInfo'=20 SUP top=20 STRUCTURAL=20 MUST ( uddiTModelKey )=20 MAY ( uddiDescription $ =20 uddiInstanceDescription $ =20 uddiInstanceParms $ =20 uddiOverviewDescription $ =20 uddiOverviewURL $=20 uddiv3TmodelKey)=20 )=20 =20 6.7 uddiTModel=20 =20 This structural object class represents a tModel.=20 =20 ( IANA-ASSIGNED-OID.6.7 NAME 'uddiTModel'=20 SUP top=20 STRUCTURAL=20 MUST ( uddiTModelKey $ =20 uddiName )=20 MAY ( uddiAuthorizedName $ =20 uddiOperator $ =20 uddiDescription $ =20 uddiOverviewDescription $ =20 uddiOverviewURL $ =20 uddiIdentifierBag $ =20 uddiCategoryBag $ =20 uddiIsHidden =20 =20 Bergeson,Boogert & Nanjundaswamy Internet-Draft 26=20 LDAP Schema for UDDI November 2003=20 =20 =20 uddiv3TModelKey $=20 uddiv3DigitalSignature $=20 uddiv3NodeId)=20 )=20 =20 6.8 uddiPublisherAssertion=20 =20 This structural object class represents a publisherAssertion.=20 =20 ( IANA-ASSIGNED-OID.6.8 NAME 'uddiPublisherAssertion'=20 SUP top=20 STRUCTURAL=20 MUST ( uddiFromKey $ =20 uddiToKey $ =20 uddiKeyedReference $ =20 uddiUUID )=20 MAY ( uddiv3DigitalSignature $=20 uddiv3NodeId)=20 )=20 =20 The following are object class definitions to model new data=20 structures needed to implement UDDIv3 information model. These=20 object class definitions have the =91uddiv3=92 prefix to indicate that= =20 these attributes represent UDDI information model elements unique to=20 UDDIv3.=20 =20 6.9 uddiv3Subscription=20 =20 This structural object class represents a Subscription entity.=20 =20 ( IANA-ASSIGNED-OID.6.9 NAME 'uddiv3Subscription'=20 SUP top=20 STRUCTURAL=20 MUST ( uddiv3SubscriptionFilter $ =20 uddiUUID)=20 MAY ( uddiAuthorizedName $ =20 uddiv3SubscriptionKey $ =20 uddiv3BindingKey $ =20 uddiv3NotificationInterval $ =20 uddiv3MaxEntities $ =20 uddiv3ExpiresAfter $ =20 uddiv3BriefResponse $ =20 uddiv3NodeId)=20 )=20 =20 6.10 uddiv3EntityObituary=20 =20 This structural object class represents an Obituary entry for and=20 stores obituary information for deleted UDDIv3 entities needed for=20 handling Subscriptions.=20 =20 ( IANA-ASSIGNED-OID.6.10 NAME 'uddiv3EntityObituary'=20 SUP top=20 =20 Bergeson,Boogert & Nanjundaswamy Internet-Draft 27=20 LDAP Schema for UDDI November 2003=20 =20 =20 STRUCTURAL=20 MUST ( uddiv3EntityKey $ =20 uddiUUID)=20 MAY ( uddiAuthorizedName $ =20 uddiv3EntityCreationTime $=20 uddiv3EntityDeletionTime $=20 uddiv3NodeId)=20 )=20 =20 7. Name Forms=20 =20 This section defines the required hierarchical structure rules and=20 naming attributes for the object classes defined in section 6.=20 =20 Note that OIDs for the structure rules in this document have not=20 been assigned. All OIDs are in brackets, , as a=20 placeholder until real OIDs are assigned.=20 =20 7.1 uddiBusinessEntityNameForm=20 =20 This name form defines the naming attribute for a businessEntity.=20 =20 ( IANA-ASSIGNED-OID.15.1 NAME 'uddiBusinessEntityNameForm'=20 OC uddiBusinessEntity=20 MUST ( uddiBusinessKey )=20 )=20 =20 7.2 uddiContactNameForm=20 =20 This name form defines the naming attribute for a contact.=20 =20 ( IANA-ASSIGNED-OID.15.2 NAME 'uddiContactNameForm'=20 OC uddiContact=20 MUST ( uddiUUID )=20 )=20 =20 7.3 uddiAddressNameForm=20 =20 This name form defines the naming attribute for an address.=20 =20 ( IANA-ASSIGNED-OID.15.3 NAME 'uddiAddressNameForm'=20 OC uddiAddress=20 MUST ( uddiUUID )=20 )=20 =20 7.4 uddiBusinessServiceNameForm=20 =20 This name form defines the naming attribute for a businessService.=20 =20 ( IANA-ASSIGNED-OID.15.4 NAME 'uddiBusinessServiceNameForm'=20 OC uddiBusinessService=20 MUST ( uddiServiceKey )=20 )=20 =20 Bergeson,Boogert & Nanjundaswamy Internet-Draft 28=20 LDAP Schema for UDDI November 2003=20 =20 =20 =20 7.5 uddiBindingTemplateNameForm=20 =20 This name form defines the naming attribute for a bindingTemplate.=20 =20 ( IANA-ASSIGNED-OID.15.5 NAME 'uddiBindingTemplateNameForm'=20 OC uddiBindingTemplate=20 MUST ( uddiBindingKey )=20 )=20 =20 7.6 uddiTModelInstanceInfoNameForm=20 =20 This name form defines the naming attribute for a=20 tModelInstanceInfo.=20 =20 ( IANA-ASSIGNED-OID.15.6 NAME 'uddiTModelInstanceInfoNameForm'=20 OC uddiTModelInstanceInfo=20 MUST ( uddiTModelKey )=20 )=20 =20 7.7 uddiTModelNameForm=20 =20 This name form defines the naming attribute for a tModel.=20 =20 ( IANA-ASSIGNED-OID.15.7 NAME 'uddiTModelNameForm'=20 OC uddiTModel=20 MUST ( uddiTModelKey )=20 )=20 =20 7.8 uddiPublisherAssertionNameForm=20 =20 This name form defines the naming attribute for a=20 publisherAssertion.=20 =20 ( IANA-ASSIGNED-OID.15.8 NAME 'uddiPublisherAssertionNameForm'=20 OC uddiPublisherAssertion=20 MUST ( uddiUUID )=20 )=20 =20 7.9 uddiv3SubscriptionNameForm=20 =20 This name form defines the naming attribute for a Subscription.=20 =20 ( IANA-ASSIGNED-OID.15.9 NAME 'uddiv3SubscriptionNameForm'=20 OC uddiv3Subscription=20 MUST ( uddiUUID )=20 )=20 =20 7.10 uddiv3EntityObituaryNameForm=20 =20 This name form defines the naming attribute for an Entity Obituary.=20 =20 ( IANA-ASSIGNED-OID.15.10 NAME 'uddiv3EntityObituary'=20 =20 Bergeson,Boogert & Nanjundaswamy Internet-Draft 29=20 LDAP Schema for UDDI November 2003=20 =20 =20 OC uddiv3EntityObituary=20 MUST ( uddiUUID )=20 )=20 =20 8. DIT Structure Rules=20 =20 This section defines the required hierarchical structure rules for=20 the object classes defined in section 6.=20 =20 Note that rule identifiers defined here show the relationship=20 between structure rules. Implementations may use different=20 identifiers but must follow the same hierarchical model.=20 =20 8.1 uddiBusinessEntityStructureRule=20 =20 ( 1=20 NAME 'uddiBusinessEntityStructureRule'=20 FORM uddiBusinessEntityNameForm=20 )=20 =20 8.2 uddiContactStructureRule=20 =20 This structure rule defines the object class containment for a=20 contact.=20 =20 ( 2=20 NAME 'uddiContactStructureRule'=20 FORM uddiContactNameForm=20 SUP ( 1 )=20 )=20 =20 8.3 uddiAddressStructureRule=20 =20 This structure rule defines the object class containment for a=20 address.=20 =20 ( 3=20 NAME 'uddiAddressStructureRule'=20 FORM uddiAddressNameForm=20 SUP ( 2 )=20 )=20 =20 8.4 uddiBusinessServiceStructureRule=20 =20 This structure rule defines the object class containment for a=20 businessService.=20 =20 ( 4=20 NAME 'uddiBusinessServiceStructureRule'=20 FORM uddiBusinessServiceNameForm=20 SUP ( 1 )=20 )=20 =20 =20 Bergeson,Boogert & Nanjundaswamy Internet-Draft 30=20 LDAP Schema for UDDI November 2003=20 =20 =20 8.5 uddiBindingTemplateStructureRule=20 =20 This structure rule defines the object class containment for a=20 bindingTemplate.=20 =20 ( 5=20 NAME 'uddiBindingTemplateStructureRule'=20 FORM uddiBindingTemplateNameForm=20 SUP ( 4 )=20 )=20 =20 8.6 uddiTModelInstanceInfoStructureRule=20 =20 This structure rule defines the object class containment for a=20 tModelInstanceInfo.=20 =20 ( 6=20 NAME 'uddiTModelInstanceInfoStructureRule'=20 FORM uddiTModelInstanceInfoNameForm=20 SUP ( 5 )=20 )=20 =20 8.7 uddiTModelStructureRule=20 =20 ( 7=20 NAME 'uddiTModelStructureRule'=20 FORM uddiTModelNameForm=20 )=20 =20 8.8 uddiPublisherAssertion=20 =20 ( 8=20 NAME 'uddiPublisherAssertionStructureRule'=20 FORM uddiPublisherAssertionNameForm=20 )=20 =20 8.9 uddiv3SubscriptionStructureRule=20 =20 ( 9=20 NAME 'uddiv3SubscriptionStructureRule'=20 FORM uddiv3SubscriptionNameForm=20 )=20 =20 8.10 uddiv3EntityObituaryStructureRule=20 =20 ( 10=20 NAME 'uddiv3EntityObituaryStructureRule'=20 FORM uddiv3EntityObituaryNameForm=20 )=20 =20 9. Security Considerations=20 =20 =20 Bergeson,Boogert & Nanjundaswamy Internet-Draft 31=20 LDAP Schema for UDDI November 2003=20 =20 =20 Storing UDDI data into the directory enables the data to be examined=20 and used outside the environment in which it was originally created. =20 The directory entry containing the UDDI data could be read and=20 modified within the constraints imposed by the access control=20 mechanisms of the directory. With UDDIv3, publishers can digitally=20 sign entries enabling registry clients to validate the integrity of=20 UDDI entries read from the UDDIv3 registry by verifying the digital=20 signature. =20 =20 Other general LDAP [LDAPv3] security considerations apply. Some of=20 the UDDI attributes like AccessPoints for services may contain=20 sensitive information. Use of strong authentication mechanisms and=20 data integrity/confidentiality services [RFC2829][RFC2830] is=20 advised.=20 =20 =20 10. IANA Considerations=20 =20 10.1. Object Identifier Registration=20 =20 It is requested that IANA register upon Standards Action an LDAP=20 Object Identifier for use in this technical specification.=20 =20 Subject: Request for LDAP OID Registration=20 Person & email address to contact for further information:=20 Bruce Bergeson =20 Specification: RFC XXXX=20 Author/Change Controller: IESG=20 Comments:=20 Identifies the UDDI schema elements=20 =20 =20 10.2. Registration of the uddiBusinessKey descriptor=20 =20 It is requested that IANA register upon Standards Action the LDAP=20 'uddiBusinessKey' descriptor.=20 =20 Subject: Request for LDAP Descriptor Registration=20 Descriptor (short name): uddiBusinessKey=20 Object Identifier: IANA-ASSIGNED-OID.4.1=20 Person & email address to contact for further information:=20 Bruce Bergeson =20 Usage: Attribute Type=20 Specification: RFC XXXX=20 Author/Change Controller: IESG=20 =20 10.3. Registration of the uddiAuthorizedName descriptor=20 =20 It is requested that IANA register upon Standards Action the LDAP=20 'uddiAuthorizedName' descriptor.=20 =20 Subject: Request for LDAP Descriptor Registration=20 Descriptor (short name): uddiAuthorizedName=20 =20 Bergeson,Boogert & Nanjundaswamy Internet-Draft 32=20 LDAP Schema for UDDI November 2003=20 =20 =20 Object Identifier: IANA-ASSIGNED-OID.4.2=20 Person & email address to contact for further information:=20 Bruce Bergeson =20 Usage: Attribute Type=20 Specification: RFC XXXX=20 Author/Change Controller: IESG=20 =20 10.4. Registration of the uddiOperator descriptor=20 =20 It is requested that IANA register upon Standards Action the LDAP=20 'uddiOperator' descriptor.=20 =20 Subject: Request for LDAP Descriptor Registration=20 Descriptor (short name): uddiOperator=20 Object Identifier: IANA-ASSIGNED-OID.4.3=20 Person & email address to contact for further information:=20 Bruce Bergeson =20 Usage: Attribute Type=20 Specification: RFC XXXX=20 Author/Change Controller: IESG=20 =20 10.5. Registration of the uddiName descriptor=20 =20 It is requested that IANA register upon Standards Action the LDAP=20 'uddiName' descriptor.=20 =20 Subject: Request for LDAP Descriptor Registration=20 Descriptor (short name): uddiName=20 Object Identifier: IANA-ASSIGNED-OID.4.4=20 Person & email address to contact for further information:=20 Bruce Bergeson =20 Usage: Attribute Type=20 Specification: RFC XXXX=20 Author/Change Controller: IESG=20 =20 10.6. Registration of the uddiDescription descriptor=20 =20 It is requested that IANA register upon Standards Action the LDAP=20 'uddiDescription' descriptor.=20 =20 Subject: Request for LDAP Descriptor Registration=20 Descriptor (short name): uddiDescription=20 Object Identifier: IANA-ASSIGNED-OID.4.5=20 Person & email address to contact for further information:=20 Bruce Bergeson =20 Usage: Attribute Type=20 Specification: RFC XXXX=20 Author/Change Controller: IESG=20 =20 10.7. Registration of the uddiDiscoveryURLs descriptor=20 =20 It is requested that IANA register upon Standards Action the LDAP=20 'uddiDiscoveryURLs' descriptor.=20 =20 Bergeson,Boogert & Nanjundaswamy Internet-Draft 33=20 LDAP Schema for UDDI November 2003=20 =20 =20 =20 Subject: Request for LDAP Descriptor Registration=20 Descriptor (short name): uddiDiscoveryURLs=20 Object Identifier: IANA-ASSIGNED-OID.4.6=20 Person & email address to contact for further information:=20 Bruce Bergeson =20 Usage: Attribute Type=20 Specification: RFC XXXX=20 Author/Change Controller: IESG=20 =20 10.8. Registration of the uddiUseType descriptor=20 =20 It is requested that IANA register upon Standards Action the LDAP=20 'uddiUseType' descriptor.=20 =20 Subject: Request for LDAP Descriptor Registration=20 Descriptor (short name): uddiUseType=20 Object Identifier: IANA-ASSIGNED-OID.4.7=20 Person & email address to contact for further information:=20 Bruce Bergeson =20 Usage: Attribute Type=20 Specification: RFC XXXX=20 Author/Change Controller: IESG=20 =20 10.9. Registration of the uddiPersonName descriptor=20 =20 It is requested that IANA register upon Standards Action the LDAP=20 'uddiPersonName' descriptor.=20 =20 Subject: Request for LDAP Descriptor Registration=20 Descriptor (short name): uddiPersonName=20 Object Identifier: IANA-ASSIGNED-OID.4.8=20 Person & email address to contact for further information:=20 Bruce Bergeson =20 Usage: Attribute Type=20 Specification: RFC XXXX=20 Author/Change Controller: IESG=20 =20 10.10. Registration of the uddiPhone descriptor=20 =20 It is requested that IANA register upon Standards Action the LDAP=20 'uddiPhone' descriptor.=20 =20 Subject: Request for LDAP Descriptor Registration=20 Descriptor (short name): uddiPhone=20 Object Identifier: IANA-ASSIGNED-OID.4.9=20 Person & email address to contact for further information:=20 Bruce Bergeson =20 Usage: Attribute Type=20 Specification: RFC XXXX=20 Author/Change Controller: IESG=20 =20 10.11. Registration of the uddiEMail descriptor=20 =20 Bergeson,Boogert & Nanjundaswamy Internet-Draft 34=20 LDAP Schema for UDDI November 2003=20 =20 =20 =20 It is requested that IANA register upon Standards Action the LDAP=20 'uddiEMail' descriptor.=20 =20 Subject: Request for LDAP Descriptor Registration=20 Descriptor (short name): uddiEMail=20 Object Identifier: IANA-ASSIGNED-OID.4.10=20 Person & email address to contact for further information:=20 Bruce Bergeson =20 Usage: Attribute Type=20 Specification: RFC XXXX=20 Author/Change Controller: IESG=20 =20 10.12. Registration of the uddiSortCode descriptor=20 =20 It is requested that IANA register upon Standards Action the LDAP=20 'uddiSortCode' descriptor.=20 =20 Subject: Request for LDAP Descriptor Registration=20 Descriptor (short name): uddiSortCode=20 Object Identifier: IANA-ASSIGNED-OID.4.11=20 Person & email address to contact for further information:=20 Bruce Bergeson =20 Usage: Attribute Type=20 Specification: RFC XXXX=20 Author/Change Controller: IESG=20 =20 10.13. Registration of the uddiTModelKey descriptor=20 =20 It is requested that IANA register upon Standards Action the LDAP=20 'uddiTModelKey' descriptor.=20 =20 Subject: Request for LDAP Descriptor Registration=20 Descriptor (short name): uddiTModelKey=20 Object Identifier: IANA-ASSIGNED-OID.4.12=20 Person & email address to contact for further information:=20 Bruce Bergeson =20 Usage: Attribute Type=20 Specification: RFC XXXX=20 Author/Change Controller: IESG=20 =20 10.14. Registration of the uddiAddressLine descriptor=20 =20 It is requested that IANA register upon Standards Action the LDAP=20 'uddiAddressLine' descriptor.=20 =20 Subject: Request for LDAP Descriptor Registration=20 Descriptor (short name): uddiAddressLine=20 Object Identifier: IANA-ASSIGNED-OID.4.13=20 Person & email address to contact for further information:=20 Bruce Bergeson =20 Usage: Attribute Type=20 Specification: RFC XXXX=20 =20 Bergeson,Boogert & Nanjundaswamy Internet-Draft 35=20 LDAP Schema for UDDI November 2003=20 =20 =20 Author/Change Controller: IESG=20 =20 10.15. Registration of the uddiIdentifierBag descriptor=20 =20 It is requested that IANA register upon Standards Action the LDAP=20 'uddiIdentifierBag' descriptor.=20 =20 Subject: Request for LDAP Descriptor Registration=20 Descriptor (short name): uddiIdentifierBag=20 Object Identifier: IANA-ASSIGNED-OID.4.14=20 Person & email address to contact for further information:=20 Bruce Bergeson =20 Usage: Attribute Type=20 Specification: RFC XXXX=20 Author/Change Controller: IESG=20 =20 10.16. Registration of the uddiCategoryBag descriptor=20 =20 It is requested that IANA register upon Standards Action the LDAP=20 'uddiCategoryBag' descriptor.=20 =20 Subject: Request for LDAP Descriptor Registration=20 Descriptor (short name): uddiCategoryBag=20 Object Identifier: IANA-ASSIGNED-OID.4.15=20 Person & email address to contact for further information:=20 Bruce Bergeson =20 Usage: Attribute Type=20 Specification: RFC XXXX=20 Author/Change Controller: IESG=20 =20 10.17. Registration of the uddiKeyedReference descriptor=20 =20 It is requested that IANA register upon Standards Action the LDAP=20 'uddiKeyedReference' descriptor.=20 =20 Subject: Request for LDAP Descriptor Registration=20 Descriptor (short name): uddiKeyedReference=20 Object Identifier: IANA-ASSIGNED-OID.4.16=20 Person & email address to contact for further information:=20 Bruce Bergeson =20 Usage: Attribute Type=20 Specification: RFC XXXX=20 Author/Change Controller: IESG=20 =20 10.18. Registration of the uddiServiceKey descriptor=20 =20 It is requested that IANA register upon Standards Action the LDAP=20 'uddiServiceKey' descriptor.=20 =20 Subject: Request for LDAP Descriptor Registration=20 Descriptor (short name): uddiServiceKey=20 Object Identifier: IANA-ASSIGNED-OID.4.17=20 Person & email address to contact for further information:=20 =20 Bergeson,Boogert & Nanjundaswamy Internet-Draft 36=20 LDAP Schema for UDDI November 2003=20 =20 =20 Bruce Bergeson =20 Usage: Attribute Type=20 Specification: RFC XXXX=20 Author/Change Controller: IESG=20 =20 10.19. Registration of the uddiBindingKey descriptor=20 =20 It is requested that IANA register upon Standards Action the LDAP=20 'uddiBindingKey' descriptor.=20 =20 Subject: Request for LDAP Descriptor Registration=20 Descriptor (short name): uddiBindingKey=20 Object Identifier: IANA-ASSIGNED-OID.4.18=20 Person & email address to contact for further information:=20 Bruce Bergeson =20 Usage: Attribute Type=20 Specification: RFC XXXX=20 Author/Change Controller: IESG=20 =20 10.20. Registration of the uddiAccessPoint descriptor=20 =20 It is requested that IANA register upon Standards Action the LDAP=20 'uddiAccessPoint' descriptor.=20 =20 Subject: Request for LDAP Descriptor Registration=20 Descriptor (short name): uddiAccessPoint=20 Object Identifier: IANA-ASSIGNED-OID.4.19=20 Person & email address to contact for further information:=20 Bruce Bergeson =20 Usage: Attribute Type=20 Specification: RFC XXXX=20 Author/Change Controller: IESG=20 =20 10.21. Registration of the uddiHostingRedirector descriptor=20 =20 It is requested that IANA register upon Standards Action the LDAP=20 'uddiHostingRedirector' descriptor.=20 =20 Subject: Request for LDAP Descriptor Registration=20 Descriptor (short name): uddiHostingRedirector=20 Object Identifier: IANA-ASSIGNED-OID.4.20=20 Person & email address to contact for further information:=20 Bruce Bergeson =20 Usage: Attribute Type=20 Specification: RFC XXXX=20 Author/Change Controller: IESG=20 =20 10.22. Registration of the uddiInstanceDescription descriptor=20 =20 It is requested that IANA register upon Standards Action the LDAP=20 'uddiInstanceDescription' descriptor.=20 =20 Subject: Request for LDAP Descriptor Registration=20 =20 Bergeson,Boogert & Nanjundaswamy Internet-Draft 37=20 LDAP Schema for UDDI November 2003=20 =20 =20 Descriptor (short name): uddiInstanceDescription=20 Object Identifier: IANA-ASSIGNED-OID.4.21=20 Person & email address to contact for further information:=20 Bruce Bergeson =20 Usage: Attribute Type=20 Specification: RFC XXXX=20 Author/Change Controller: IESG=20 =20 10.23. Registration of the uddiInstanceParms descriptor=20 =20 It is requested that IANA register upon Standards Action the LDAP=20 'uddiInstanceParms' descriptor.=20 =20 Subject: Request for LDAP Descriptor Registration=20 Descriptor (short name): uddiInstanceParms=20 Object Identifier: IANA-ASSIGNED-OID.4.22=20 Person & email address to contact for further information:=20 Bruce Bergeson =20 Usage: Attribute Type=20 Specification: RFC XXXX=20 Author/Change Controller: IESG=20 =20 10.24. Registration of the uddiOverviewDescription descriptor=20 =20 It is requested that IANA register upon Standards Action the LDAP=20 'uddiOverviewDescription' descriptor.=20 =20 Subject: Request for LDAP Descriptor Registration=20 Descriptor (short name): uddiOverviewDescription=20 Object Identifier: IANA-ASSIGNED-OID.4.23=20 Person & email address to contact for further information:=20 Bruce Bergeson =20 Usage: Attribute Type=20 Specification: RFC XXXX=20 Author/Change Controller: IESG=20 =20 10.25. Registration of the uddiOverviewURL descriptor=20 =20 It is requested that IANA register upon Standards Action the LDAP=20 'uddiOverviewURL' descriptor.=20 =20 Subject: Request for LDAP Descriptor Registration=20 Descriptor (short name): uddiOverviewURL=20 Object Identifier: IANA-ASSIGNED-OID.4.24=20 Person & email address to contact for further information:=20 Bruce Bergeson =20 Usage: Attribute Type=20 Specification: RFC XXXX=20 Author/Change Controller: IESG=20 =20 10.26. Registration of the uddiFromKey descriptor=20 =20 It is requested that IANA register upon Standards Action the LDAP=20 =20 Bergeson,Boogert & Nanjundaswamy Internet-Draft 38=20 LDAP Schema for UDDI November 2003=20 =20 =20 'uddiFromKey' descriptor.=20 =20 Subject: Request for LDAP Descriptor Registration=20 Descriptor (short name): uddiFromKey=20 Object Identifier: IANA-ASSIGNED-OID.4.25=20 Person & email address to contact for further information:=20 Bruce Bergeson =20 Usage: Attribute Type=20 Specification: RFC XXXX=20 Author/Change Controller: IESG=20 =20 10.27. Registration of the uddiToKey descriptor=20 =20 It is requested that IANA register upon Standards Action the LDAP=20 'uddiToKey' descriptor.=20 =20 Subject: Request for LDAP Descriptor Registration=20 Descriptor (short name): uddiToKey=20 Object Identifier: IANA-ASSIGNED-OID.4.26=20 Person & email address to contact for further information:=20 Bruce Bergeson =20 Usage: Attribute Type=20 Specification: RFC XXXX=20 Author/Change Controller: IESG=20 =20 10.28. Registration of the uddiUUID descriptor=20 =20 It is requested that IANA register upon Standards Action the LDAP=20 'uddiUUID' descriptor.=20 =20 Subject: Request for LDAP Descriptor Registration=20 Descriptor (short name): uddiUUID=20 Object Identifier: IANA-ASSIGNED-OID.4.27=20 Person & email address to contact for further information:=20 Bruce Bergeson =20 Usage: Attribute Type=20 Specification: RFC XXXX=20 Author/Change Controller: IESG=20 =20 10.29. Registration of the uddiIsHidden descriptor=20 =20 It is requested that IANA register upon Standards Action the LDAP=20 'uddiIsHidden' descriptor.=20 =20 Subject: Request for LDAP Descriptor Registration=20 Descriptor (short name): uddiIsHidden=20 Object Identifier: IANA-ASSIGNED-OID.4.28=20 Person & email address to contact for further information:=20 Bruce Bergeson =20 Usage: Attribute Type=20 Specification: RFC XXXX=20 Author/Change Controller: IESG=20 =20 =20 Bergeson,Boogert & Nanjundaswamy Internet-Draft 39=20 LDAP Schema for UDDI November 2003=20 =20 =20 10.30. Registration of the uddiIsProjection descriptor=20 =20 It is requested that IANA register upon Standards Action the LDAP=20 'uddiIsProjection' descriptor.=20 =20 Subject: Request for LDAP Descriptor Registration=20 Descriptor (short name): uddiIsProjection=20 Object Identifier: IANA-ASSIGNED-OID.4.29=20 Person & email address to contact for further information:=20 Bruce Bergeson =20 Usage: Attribute Type=20 Specification: RFC XXXX=20 Author/Change Controller: IESG=20 =20 10.31. Registration of the uddiLang descriptor=20 =20 It is requested that IANA register upon Standards Action the LDAP=20 'uddiLang' descriptor.=20 =20 Subject: Request for LDAP Descriptor Registration=20 Descriptor (short name): uddiLang=20 Object Identifier: IANA-ASSIGNED-OID.4.30=20 Person & email address to contact for further information:=20 Bruce Bergeson =20 Usage: Attribute Type=20 Specification: RFC XXXX=20 Author/Change Controller: IESG=20 =20 10.32. Registration of the uddiv3BusinessKey descriptor=20 =20 It is requested that IANA register upon Standards Action the LDAP=20 'uddiv3BusinessKey' descriptor.=20 =20 Subject: Request for LDAP Descriptor Registration=20 Descriptor (short name): uddiv3BusinessKey=20 Object Identifier: IANA-ASSIGNED-OID.4.31=20 Person & email address to contact for further information:=20 Bruce Bergeson =20 Usage: Attribute Type=20 Specification: RFC XXXX=20 Author/Change Controller: IESG=20 =20 10.33. Registration of the uddiv3ServiceKey descriptor=20 =20 It is requested that IANA register upon Standards Action the LDAP=20 'uddiv3ServiceKey' descriptor.=20 =20 Subject: Request for LDAP Descriptor Registration=20 Descriptor (short name): uddiv3ServiceKey=20 Object Identifier: IANA-ASSIGNED-OID.4.32=20 Person & email address to contact for further information:=20 Bruce Bergeson =20 Usage: Attribute Type=20 =20 Bergeson,Boogert & Nanjundaswamy Internet-Draft 40=20 LDAP Schema for UDDI November 2003=20 =20 =20 Specification: RFC XXXX=20 Author/Change Controller: IESG=20 =20 10.34. Registration of the uddiv3BindingKey descriptor=20 =20 It is requested that IANA register upon Standards Action the LDAP=20 'uddiv3BindingKey' descriptor.=20 =20 Subject: Request for LDAP Descriptor Registration=20 Descriptor (short name): uddiv3BindingKey=20 Object Identifier: IANA-ASSIGNED-OID.4.33=20 Person & email address to contact for further information:=20 Bruce Bergeson =20 Usage: Attribute Type=20 Specification: RFC XXXX=20 Author/Change Controller: IESG=20 =20 10.35. Registration of the uddiv3TModelKey descriptor=20 =20 It is requested that IANA register upon Standards Action the LDAP=20 'uddiv3TModelKey' descriptor.=20 =20 Subject: Request for LDAP Descriptor Registration=20 Descriptor (short name): uddiv3TModelKey=20 Object Identifier: IANA-ASSIGNED-OID.4.34=20 Person & email address to contact for further information:=20 Bruce Bergeson =20 Usage: Attribute Type=20 Specification: RFC XXXX=20 Author/Change Controller: IESG=20 =20 10.36. Registration of the uddiv3DigitalSignature descriptor=20 =20 It is requested that IANA register upon Standards Action the LDAP=20 'uddiv3DigitalSignature' descriptor.=20 =20 Subject: Request for LDAP Descriptor Registration=20 Descriptor (short name): uddiv3DigitalSignature=20 Object Identifier: IANA-ASSIGNED-OID.4.35=20 Person & email address to contact for further information:=20 Bruce Bergeson =20 Usage: Attribute Type=20 Specification: RFC XXXX=20 Author/Change Controller: IESG=20 =20 10.37. Registration of the uddiv3NodeId descriptor=20 =20 It is requested that IANA register upon Standards Action the LDAP=20 'uddiv3NodeId' descriptor.=20 =20 Subject: Request for LDAP Descriptor Registration=20 Descriptor (short name): uddiv3NodeId=20 Object Identifier: IANA-ASSIGNED-OID.4.36=20 =20 Bergeson,Boogert & Nanjundaswamy Internet-Draft 41=20 LDAP Schema for UDDI November 2003=20 =20 =20 Person & email address to contact for further information:=20 Bruce Bergeson =20 Usage: Attribute Type=20 Specification: RFC XXXX=20 Author/Change Controller: IESG=20 =20 10.38. Registration of the uddiv3EntityModificationTime descriptor=20 =20 It is requested that IANA register upon Standards Action the LDAP=20 'uddiv3EntityModificationTime' descriptor.=20 =20 Subject: Request for LDAP Descriptor Registration=20 Descriptor (short name): uddiv3EntityModificationTime=20 Object Identifier: IANA-ASSIGNED-OID.4.37=20 Person & email address to contact for further information:=20 Bruce Bergeson =20 Usage: Attribute Type=20 Specification: RFC XXXX=20 Author/Change Controller: IESG=20 =20 10.39. Registration of the uddiv3SubscriptionKey descriptor=20 =20 It is requested that IANA register upon Standards Action the LDAP=20 'uddiv3SubscriptionKey' descriptor.=20 =20 Subject: Request for LDAP Descriptor Registration=20 Descriptor (short name): uddiv3SubscriptionKey=20 Object Identifier: IANA-ASSIGNED-OID.4.38=20 Person & email address to contact for further information:=20 Bruce Bergeson =20 Usage: Attribute Type=20 Specification: RFC XXXX=20 Author/Change Controller: IESG=20 =20 10.40. Registration of the uddiv3SubscriptionFilter descriptor=20 =20 It is requested that IANA register upon Standards Action the LDAP=20 'uddiv3SubscriptionFilter' descriptor.=20 =20 Subject: Request for LDAP Descriptor Registration=20 Descriptor (short name): uddiv3SubscriptionFilter=20 Object Identifier: IANA-ASSIGNED-OID.4.39=20 Person & email address to contact for further information:=20 Bruce Bergeson =20 Usage: Attribute Type=20 Specification: RFC XXXX=20 Author/Change Controller: IESG=20 =20 10.41. Registration of the uddiv3NotificationInterval descriptor=20 =20 It is requested that IANA register upon Standards Action the LDAP=20 'uddiv3NotificationInterval' descriptor.=20 =20 =20 Bergeson,Boogert & Nanjundaswamy Internet-Draft 42=20 LDAP Schema for UDDI November 2003=20 =20 =20 Subject: Request for LDAP Descriptor Registration=20 Descriptor (short name): uddiv3NotificationInterval=20 Object Identifier: IANA-ASSIGNED-OID.4.40=20 Person & email address to contact for further information:=20 Bruce Bergeson =20 Usage: Attribute Type=20 Specification: RFC XXXX=20 Author/Change Controller: IESG=20 =20 10.42. Registration of the uddiv3MaxEntities descriptor=20 =20 It is requested that IANA register upon Standards Action the LDAP=20 'uddiv3MaxEntities' descriptor.=20 =20 Subject: Request for LDAP Descriptor Registration=20 Descriptor (short name): uddiv3MaxEntities=20 Object Identifier: IANA-ASSIGNED-OID.4.41=20 Person & email address to contact for further information:=20 Bruce Bergeson =20 Usage: Attribute Type=20 Specification: RFC XXXX=20 Author/Change Controller: IESG=20 =20 10.43. Registration of the uddiv3ExpiresAfter descriptor=20 =20 It is requested that IANA register upon Standards Action the LDAP=20 'uddiv3ExpiresAfter' descriptor.=20 =20 Subject: Request for LDAP Descriptor Registration=20 Descriptor (short name): uddiv3ExpiresAfter=20 Object Identifier: IANA-ASSIGNED-OID.4.42=20 Person & email address to contact for further information:=20 Bruce Bergeson =20 Usage: Attribute Type=20 Specification: RFC XXXX=20 Author/Change Controller: IESG=20 =20 10.44. Registration of the uddiv3BriefResponse descriptor=20 =20 It is requested that IANA register upon Standards Action the LDAP=20 'uddiv3BriefResponse' descriptor.=20 =20 Subject: Request for LDAP Descriptor Registration=20 Descriptor (short name): uddiv3BriefResponse=20 Object Identifier: IANA-ASSIGNED-OID.4.43=20 Person & email address to contact for further information:=20 Bruce Bergeson =20 Usage: Attribute Type=20 Specification: RFC XXXX=20 Author/Change Controller: IESG=20 =20 10.45. Registration of the uddiv3EntityKey descriptor=20 =20 =20 Bergeson,Boogert & Nanjundaswamy Internet-Draft 43=20 LDAP Schema for UDDI November 2003=20 =20 =20 It is requested that IANA register upon Standards Action the LDAP=20 'uddiv3EntityKey' descriptor.=20 =20 Subject: Request for LDAP Descriptor Registration=20 Descriptor (short name): uddiv3EntityKey=20 Object Identifier: IANA-ASSIGNED-OID.4.44=20 Person & email address to contact for further information:=20 Bruce Bergeson =20 Usage: Attribute Type=20 Specification: RFC XXXX=20 Author/Change Controller: IESG=20 =20 10.46. Registration of the uddiv3EntityCreationTime descriptor=20 =20 It is requested that IANA register upon Standards Action the LDAP=20 'uddiv3EntityCreationTime' descriptor.=20 =20 Subject: Request for LDAP Descriptor Registration=20 Descriptor (short name): uddiv3EntityCreationTime=20 Object Identifier: IANA-ASSIGNED-OID.4.45=20 Person & email address to contact for further information:=20 Bruce Bergeson =20 Usage: Attribute Type=20 Specification: RFC XXXX=20 Author/Change Controller: IESG=20 =20 10.47. Registration of the uddiv3EntityDeletionTime descriptor=20 =20 It is requested that IANA register upon Standards Action the LDAP=20 'uddiv3EntityDeletionTime' descriptor.=20 =20 Subject: Request for LDAP Descriptor Registration=20 Descriptor (short name): uddiv3EntityDeletionTime=20 Object Identifier: IANA-ASSIGNED-OID.4.46=20 Person & email address to contact for further information:=20 Bruce Bergeson =20 Usage: Attribute Type=20 Specification: RFC XXXX=20 Author/Change Controller: IESG=20 =20 10.48. Registration of the uddiBusinessEntity descriptor=20 =20 It is requested that IANA register upon Standards Action the LDAP=20 'uddiBusinessEntity' descriptor.=20 =20 Subject: Request for LDAP Descriptor Registration=20 Descriptor (short name): uddiBusinessEntity=20 Object Identifier: IANA-ASSIGNED-OID.6.1=20 Person & email address to contact for further information:=20 Bruce Bergeson =20 Usage: Object Class=20 Specification: RFC XXXX=20 Author/Change Controller: IESG=20 =20 Bergeson,Boogert & Nanjundaswamy Internet-Draft 44=20 LDAP Schema for UDDI November 2003=20 =20 =20 =20 10.49. Registration of the uddiContact descriptor=20 =20 It is requested that IANA register upon Standards Action the LDAP=20 'uddiContact' descriptor.=20 =20 Subject: Request for LDAP Descriptor Registration=20 Descriptor (short name): uddiContact=20 Object Identifier: IANA-ASSIGNED-OID.6.2=20 Person & email address to contact for further information:=20 Bruce Bergeson =20 Usage: Object Class=20 Specification: RFC XXXX=20 Author/Change Controller: IESG=20 =20 10.50. Registration of the uddiAddress descriptor=20 =20 It is requested that IANA register upon Standards Action the LDAP=20 'uddiAddress' descriptor.=20 =20 Subject: Request for LDAP Descriptor Registration=20 Descriptor (short name): uddiAddress=20 Object Identifier: IANA-ASSIGNED-OID.6.3=20 Person & email address to contact for further information:=20 Bruce Bergeson =20 Usage: Object Class=20 Specification: RFC XXXX=20 Author/Change Controller: IESG=20 =20 10.51. Registration of the uddiBusinessService descriptor=20 =20 It is requested that IANA register upon Standards Action the LDAP=20 'uddiBusinessService' descriptor.=20 =20 Subject: Request for LDAP Descriptor Registration=20 Descriptor (short name): uddiBusinessService=20 Object Identifier: IANA-ASSIGNED-OID.6.4=20 Person & email address to contact for further information:=20 Bruce Bergeson =20 Usage: Object Class=20 Specification: RFC XXXX=20 Author/Change Controller: IESG=20 =20 10.52. Registration of the uddiBindingTemplate descriptor=20 =20 It is requested that IANA register upon Standards Action the LDAP=20 'uddiBindingTemplate' descriptor.=20 =20 Subject: Request for LDAP Descriptor Registration=20 Descriptor (short name): uddiBindingTemplate=20 Object Identifier: IANA-ASSIGNED-OID.6.5=20 Person & email address to contact for further information:=20 Bruce Bergeson =20 =20 Bergeson,Boogert & Nanjundaswamy Internet-Draft 45=20 LDAP Schema for UDDI November 2003=20 =20 =20 Usage: Object Class=20 Specification: RFC XXXX=20 Author/Change Controller: IESG=20 =20 10.53. Registration of the uddiTModelInstanceInfo descriptor=20 =20 It is requested that IANA register upon Standards Action the LDAP=20 'uddiTModelInstanceInfo' descriptor.=20 =20 Subject: Request for LDAP Descriptor Registration=20 Descriptor (short name): uddiTModelInstanceInfo=20 Object Identifier: IANA-ASSIGNED-OID.6.6=20 Person & email address to contact for further information:=20 Bruce Bergeson =20 Usage: Object Class=20 Specification: RFC XXXX=20 Author/Change Controller: IESG=20 =20 10.54. Registration of the uddiTModel descriptor=20 =20 It is requested that IANA register upon Standards Action the LDAP=20 'uddiTModel' descriptor.=20 =20 Subject: Request for LDAP Descriptor Registration=20 Descriptor (short name): uddiTModel=20 Object Identifier: IANA-ASSIGNED-OID.6.7=20 Person & email address to contact for further information:=20 Bruce Bergeson =20 Usage: Object Class=20 Specification: RFC XXXX=20 Author/Change Controller: IESG=20 =20 10.55. Registration of the uddiPublisherAssertion descriptor=20 =20 It is requested that IANA register upon Standards Action the LDAP=20 'uddiPublisherAssertion' descriptor.=20 =20 Subject: Request for LDAP Descriptor Registration=20 Descriptor (short name): uddiPublisherAssertion=20 Object Identifier: IANA-ASSIGNED-OID.6.8=20 Person & email address to contact for further information:=20 Bruce Bergeson =20 Usage: Object Class=20 Specification: RFC XXXX=20 Author/Change Controller: IESG=20 =20 10.56. Registration of the uddiv3Subscription descriptor=20 =20 It is requested that IANA register upon Standards Action the LDAP=20 'uddiv3Subscription' descriptor.=20 =20 Subject: Request for LDAP Descriptor Registration=20 Descriptor (short name): uddiv3Subscription=20 =20 Bergeson,Boogert & Nanjundaswamy Internet-Draft 46=20 LDAP Schema for UDDI November 2003=20 =20 =20 Object Identifier: IANA-ASSIGNED-OID.6.9=20 Person & email address to contact for further information:=20 Bruce Bergeson =20 Usage: Object Class=20 Specification: RFC XXXX=20 Author/Change Controller: IESG=20 =20 10.57. Registration of the uddiv3EntityObituary descriptor=20 =20 It is requested that IANA register upon Standards Action the LDAP=20 'uddiv3EntityObituary' descriptor.=20 =20 Subject: Request for LDAP Descriptor Registration=20 Descriptor (short name): uddiv3EntityObituary=20 Object Identifier: IANA-ASSIGNED-OID.6.10=20 Person & email address to contact for further information:=20 Bruce Bergeson =20 Usage: Object Class=20 Specification: RFC XXXX=20 Author/Change Controller: IESG=20 =20 10.58. Registration of the uddiBusinessEntityNameForm descriptor=20 =20 It is requested that IANA register upon Standards Action the LDAP=20 'uddiBusinessEntityNameForm' descriptor.=20 =20 Subject: Request for LDAP Descriptor Registration=20 Descriptor (short name): uddiBusinessEntityNameForm=20 Object Identifier: IANA-ASSIGNED-OID.15.1=20 Person & email address to contact for further information:=20 Bruce Bergeson =20 Usage: Name Form=20 Specification: RFC XXXX=20 Author/Change Controller: IESG=20 =20 10.59. Registration of the uddiContactNameForm descriptor=20 =20 It is requested that IANA register upon Standards Action the LDAP=20 'uddiContactNameForm' descriptor.=20 =20 Subject: Request for LDAP Descriptor Registration=20 Descriptor (short name): uddiContactNameForm=20 Object Identifier: IANA-ASSIGNED-OID.15.2=20 Person & email address to contact for further information:=20 Bruce Bergeson =20 Usage: Name Form=20 Specification: RFC XXXX=20 Author/Change Controller: IESG=20 =20 10.60. Registration of the uddiAddressNameForm descriptor=20 =20 It is requested that IANA register upon Standards Action the LDAP=20 'uddiAddressNameForm' descriptor.=20 =20 Bergeson,Boogert & Nanjundaswamy Internet-Draft 47=20 LDAP Schema for UDDI November 2003=20 =20 =20 =20 Subject: Request for LDAP Descriptor Registration=20 Descriptor (short name): uddiAddressNameForm=20 Object Identifier: IANA-ASSIGNED-OID.15.3=20 Person & email address to contact for further information:=20 Bruce Bergeson =20 Usage: Name Form=20 Specification: RFC XXXX=20 Author/Change Controller: IESG=20 =20 10.61. Registration of the uddiBusinessServiceNameForm descriptor=20 =20 It is requested that IANA register upon Standards Action the LDAP=20 'uddiBusinessServiceNameForm' descriptor.=20 =20 Subject: Request for LDAP Descriptor Registration=20 Descriptor (short name): uddiBusinessServiceNameForm=20 Object Identifier: IANA-ASSIGNED-OID.15.4=20 Person & email address to contact for further information:=20 Bruce Bergeson =20 Usage: Name Form=20 Specification: RFC XXXX=20 Author/Change Controller: IESG=20 =20 10.62. Registration of the uddiBindingTemplateNameForm descriptor=20 =20 It is requested that IANA register upon Standards Action the LDAP=20 'uddiBindingTemplateNameForm' descriptor.=20 =20 Subject: Request for LDAP Descriptor Registration=20 Descriptor (short name): uddiBindingTemplateNameForm=20 Object Identifier: IANA-ASSIGNED-OID.15.5=20 Person & email address to contact for further information:=20 Bruce Bergeson =20 Usage: Name Form=20 Specification: RFC XXXX=20 Author/Change Controller: IESG=20 =20 10.63. Registration of the uddiTModelInstanceInfoNameForm descriptor=20 =20 It is requested that IANA register upon Standards Action the LDAP=20 'uddiTModelInstanceInfoNameForm' descriptor.=20 =20 Subject: Request for LDAP Descriptor Registration=20 Descriptor (short name): uddiTModelInstanceInfoNameForm=20 Object Identifier: IANA-ASSIGNED-OID.15.6=20 Person & email address to contact for further information:=20 Bruce Bergeson =20 Usage: Name Form=20 Specification: RFC XXXX=20 Author/Change Controller: IESG=20 =20 10.64. Registration of the uddiTModelNameForm descriptor=20 =20 Bergeson,Boogert & Nanjundaswamy Internet-Draft 48=20 LDAP Schema for UDDI November 2003=20 =20 =20 =20 It is requested that IANA register upon Standards Action the LDAP=20 'uddiTModelNameForm' descriptor.=20 =20 Subject: Request for LDAP Descriptor Registration=20 Descriptor (short name): uddiTModelNameForm=20 Object Identifier: IANA-ASSIGNED-OID.15.7=20 Person & email address to contact for further information:=20 Bruce Bergeson =20 Usage: Name Form=20 Specification: RFC XXXX=20 Author/Change Controller: IESG=20 =20 10.65. Registration of the uddiPublisherAssertionNameForm descriptor=20 =20 It is requested that IANA register upon Standards Action the LDAP=20 'uddiPublisherAssertionNameForm' descriptor.=20 =20 Subject: Request for LDAP Descriptor Registration=20 Descriptor (short name): uddiPublisherAssertionNameForm=20 Object Identifier: IANA-ASSIGNED-OID.15.8=20 Person & email address to contact for further information:=20 Bruce Bergeson =20 Usage: Name Form=20 Specification: RFC XXXX=20 Author/Change Controller: IESG=20 =20 10.66. Registration of the uddiv3SubscriptionNameForm descriptor=20 =20 It is requested that IANA register upon Standards Action the LDAP=20 'uddiv3SubscriptionNameForm' descriptor.=20 =20 Subject: Request for LDAP Descriptor Registration=20 Descriptor (short name): uddiv3SubscriptionNameForm=20 Object Identifier: IANA-ASSIGNED-OID.15.9=20 Person & email address to contact for further information:=20 Bruce Bergeson =20 Usage: Name Form=20 Specification: RFC XXXX=20 Author/Change Controller: IESG=20 =20 10.67. Registration of the uddiv3EntityObituary descriptor=20 =20 It is requested that IANA register upon Standards Action the LDAP=20 'uddiv3EntityObituary' descriptor.=20 =20 Subject: Request for LDAP Descriptor Registration=20 Descriptor (short name): uddiv3EntityObituary=20 Object Identifier: IANA-ASSIGNED-OID.15.10=20 Person & email address to contact for further information:=20 Bruce Bergeson =20 Usage: Name Form=20 Specification: RFC XXXX=20 =20 Bergeson,Boogert & Nanjundaswamy Internet-Draft 49=20 LDAP Schema for UDDI November 2003=20 =20 =20 Author/Change Controller: IESG=20 =20 =20 11. Normative References=20 =20 [LDAPv3] J. Hodges, R. Morgan, "Lightweight Directory Access=20 Protocol (v3):Technical Specification", Internet=20 Standard, September 2002, Available as RFC 3377=20 =20 [RFC2251] M. Wahl, S. Kille and T. Howes, "Lightweight Directory=20 Access Protocol (v3)", Internet Standard, December,=20 1997. =20 =20 [RFC2252] M. Wahl, A. Coulbeck, S. Kille and T. Howes, =20 "Lightweight Directory Access Protocol (v3): Attribute=20 Syntax Definitions", Internet Standard, December, 1997. =20 =20 [UDDI] UDDI.ORG, "UDDI version 2.03 Data Structure Reference,"=20 http://uddi.org/pubs/DataStructure-V2.03-Published- 20020719.htm=20 =20 "UDDI Version 2.04 API Specification",=20 http://uddi.org/pubs/ProgrammersAPI-V2.04-Published- 20020719.htm=20 =20 [UDDIv3] UDDI Version 3.0, Published Specification, 19 July 2002=20 http://uddi.org/pubs/uddi-v3.00-published-20020719.htm=20 =20 [RFC2119] S. Bradner, "Key Words for use in RFCs to Indicate=20 Requirement Levels," Internet Standard, December, 1997.=20 Available as RFC2253=20 =20 [RFC2829] M. Wahl, H. Alvestrand, J. Hodges and R. Morgan,=20 "Authentication Methods for LDAP," Internet Standard,=20 May 2000.=20 =20 [RFC2830] J. Hodges, R. Morgan and M. Wahl, "Lightweight=20 Directory Access Protocol (v3): Extension for Transport=20 Layer Security," Internet Standard, May 2000=20 =20 [uuid] Paul J. Leach, Rich Salz, "UUIDs and GUIDs", Internet=20 Draft, February 1998=20 =20 [XML] Extensible Markup Language (XML) 1.0 (Second Edition)=20 W3C Recommendation 6 October 2000=20 http://www.w3.org/TR/REC-xml=20 =20 [URL] Uniform Resource Locators as defined in =20 T. Berners-Lee et al., "Uniform Resource Identifiers=20 (URI): Generic Syntax", Internet Standard, August 1998.=20 Available as RFC 2396. =20 http://www.ietf.org/rfc/rfc2396.txt=20 =20 Bergeson,Boogert & Nanjundaswamy Internet-Draft 50=20 LDAP Schema for UDDI November 2003=20 =20 =20 =20 [HTTP] R. Fielding et al.,"Hypertext Transfer Protocol --=20 HTTP/1.1", Internet Standard, June 1999. Available as=20 RFC 2616.=20 http://www.w3.org/Protocols/rfc2616/rfc2616.txt=20 =20 =20 12. Author's Addresses=20 =20 Bruce Bergeson=20 Novell, Inc.=20 Mail Stop PRV-H411=20 1800 S Novell Place=20 Provo, UT 84606=20 =20 Phone: +1 801 861 3854=20 Email: bruce.bergeson@novell.com=20 =20 =20 Kent Boogert=20 Novell, Inc.=20 1800 S Novell Place=20 Provo, UT 84606=20 =20 Phone: +1 801 861 3212=20 Email: kent.boogert@novell.com=20 =20 =20 Vijay Nanjundaswamy=20 Novell Software Development (I) Pvt Ltd.=20 7th Mile, Hosur Road,=20 Bangalore 560068=20 India=20 =20 Phone: +11 9180 573 1858 =20 Email: knvijay@novell.com=20 =20 Bergeson,Boogert & Nanjundaswamy Internet-Draft 51=20 LDAP Schema for UDDI November 2003=20 =20 =20 Intellectual Property Rights=20 =20 The IETF takes no position regarding the validity or scope of any=20 intellectual property or other rights that might be claimed to=20 pertain to the implementation or use of the technology described in=20 this document or the extent to which any license under such rights=20 might or might not be available; neither does it represent that it=20 has made any effort to identify any such rights. Information on the=20 IETF's procedures with respect to rights in standards-track and=20 standards-related documentation can be found in BCP-11. Copies of=20 claims of rights made available for publication and any assurances=20 of licenses to be made available, or the result of an attempt made=20 to obtain a general license or permission for the use of such=20 proprietary rights by implementors or users of this specification=20 can be obtained from the IETF Secretariat.=20 =20 The IETF invites any interested party to bring to its attention any=20 copyrights, patents or patent applications, or other proprietary=20 rights which may cover technology that may be required to practice=20 this standard. Please address the information to the IETF Executive=20 Director.=20 =20 =20 Full Copyright Statement=20 =20 Copyright (C) The Internet Society (2003). All Rights Reserved.=20 =20 This document and translations of it may be copied and furnished to=20 others, and derivative works that comment on or otherwise explain it=20 or assist in its implementation may be prepared, copied, published=20 and distributed, in whole or in part, without restriction of any=20 kind, provided that the above copyright notice and this paragraph=20 are included on all such copies and derivative works. However, this=20 document itself may not be modified in any way, such as by removing=20 the copyright notice or references to the Internet Society or other=20 Internet organizations, except as needed for the purpose of=20 developing Internet standards in which case the procedures for=20 copyrights defined in the Internet Standards process must be=20 followed, or as required to translate it into languages other than=20 English.=20 =20 The limited permissions granted above are perpetual and will not be=20 revoked by the Internet Society or its successors or assigns.=20 =20 This document and the information contained herein is provided on an=20 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING=20 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING=20 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION=20 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF=20 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. =20 =20 =20 Bergeson,Boogert & Nanjundaswamy Internet-Draft 52=20 --=__PartF2D3832E.2__=-- _______________________________________________ Ldapext mailing list Ldapext@ietf.org https://www1.ietf.org/mailman/listinfo/ldapext