RE: [ldapext] draft-bergeson-uddi-ldap-schema-02.txt

"Bruce Bergeson" <BBERG@novell.com> Wed, 25 February 2004 17:09 UTC

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 <ldapext-archive@lists.ietf.org>; 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 <ldapext@ietf.org>; 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: <s03c65df.057@prv-mail20.provo.novell.com>
X-Mailer: Novell GroupWise Internet Agent 6.5.2 Beta
Date: Wed, 25 Feb 2004 09:07:26 -0700
From: Bruce Bergeson <BBERG@novell.com>
To: andrew.sciberras@adacel.com
Cc: ldapext@ietf.org, Kent Boogert <KBOOGERT@novell.com>, Vijay KN <KNVIJAY@novell.com>
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: <https://www1.ietf.org/mailman/listinfo/ldapext>, <mailto:ldapext-request@ietf.org?subject=unsubscribe>
List-Id: LDAP Extension Working Group <ldapext.ietf.org>
List-Post: <mailto:ldapext@ietf.org>
List-Help: <mailto:ldapext-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/ldapext>, <mailto:ldapext-request@ietf.org?subject=subscribe>

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" <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-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].