[ldapext] draft-bergeson-uddi-ldap-schema-05.txt

Andrew Sciberras <andrew.sciberras@eB2Bcom.com> Fri, 21 January 2005 00:59 UTC

Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA02828 for <ldapext-archive@lists.ietf.org>; Thu, 20 Jan 2005 19:59:49 -0500 (EST)
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Crn42-0003a1-FL; Thu, 20 Jan 2005 19:54:14 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Crn0R-0002wj-Fj for ldapext@megatron.ietf.org; Thu, 20 Jan 2005 19:50:31 -0500
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA02332 for <ldapext@ietf.org>; Thu, 20 Jan 2005 19:50:24 -0500 (EST)
Received: from cust3103.vic01.dataco.com.au ([202.63.62.31] helo=amos.eb2bcom.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CrnG3-0001z8-5O for ldapext@ietf.org; Thu, 20 Jan 2005 20:06:46 -0500
Received: from [192.168.1.159] (10.1.2.225) by amos.eb2bcom.com (7.1.016.1) (authenticated as andrew.sciberras) id 41B79F8B00003676; Fri, 21 Jan 2005 11:58:54 +1100
Message-ID: <41F0522E.3000603@eB2Bcom.com>
Date: Fri, 21 Jan 2005 11:51:58 +1100
From: Andrew Sciberras <andrew.sciberras@eB2Bcom.com>
Organization: eB2Bcom
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.5) Gecko/20041217
X-Accept-Language: en-au, en-gb, en
MIME-Version: 1.0
To: bruce.bergeson@novell.com
Content-Type: text/plain; charset="UTF-8"; format="flowed"
Content-Transfer-Encoding: quoted-printable
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 10ba05e7e8a9aa6adb025f426bef3a30
Content-Transfer-Encoding: quoted-printable
Cc: Ldapext <ldapext@ietf.org>
Subject: [ldapext] draft-bergeson-uddi-ldap-schema-05.txt
X-BeenThere: ldapext@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
Reply-To: andrew.sciberras@eB2Bcom.com
List-Id: LDAP Extension Working Group <ldapext.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/ldapext>, <mailto:ldapext-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/ldapext>
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>
Sender: ldapext-bounces@ietf.org
Errors-To: ldapext-bounces@ietf.org
Content-Transfer-Encoding: quoted-printable

Hi Bruce,

Just a few comments on this revision of the draft. They're mainly 
editorial.

> 3.1 businessEntity 
> A businessEntity is represented in the directory by the attributes 
>    uddiBusinessKey, uddiAuthorizedName, uddiOperator, 
>    uddiDiscoveryURLs, uddiName, uddiDescription, uddiIdentifierBag, 
>    uddiCategoryBag, and uddiv3DigitalSignature, along with 
>    corresponding v3 keys viz. uddiv3BusinessKey, as defined in section 
>    5.  

I think you mean section 4. It depends if you are talking about the 
definition of the attributes or the uddiBusinessEntity object class.
If your talking about the attributes, then it should be section 4. If 
your talking about the objectClass, then the subsequent statement in 
this section indicating that businessEntity is defined in section 6 is 
contradictory.


>    The mandatory attribute, uddiBusinessKey, contains the unique 
>    identifier for a given instance of a businessEntity. 
The above statement implies that there is only one manitory attribute, 
when there are actually two. I'm not sure whether the intent of the 
statement is to talk about all manditory attributes, or just this 
partcular one... So, I would either replace the first word "The" with 
"A", or go on to talk abot the second mandatory attribute as well.

(This applies to other references made in section 3 of this draft).


>    businessEntity's definition is given in Section 6.  
I think you mean section 5.


> 3.4.1 Representation in the Directory 
> ...    
>    The mandatory attribute, 
>    uddiTModelKey, contains the unique identifier for a given instance 
>    of a tModel. 
>     
Again, this is not the only mandatory attribute.

> 3.5.1 Representation in the Directory 
> ...    
>    The mandatory 
>    attribute, uddiUUID, contains the unique identifier for a given 
>    instance of a publisherAssertion. 
As above.


> 4.11 uddiSortCode 
Due to the nature of this attribute, would it be beneficial to including 
an ordering rule?


> 4.35 uddiv3DigitalSignature 
I'm not sure whether you'd be using the directory to do comparisons of 
such signatures, however if this is the case, then I would recommend a 
caseExactMatch instead of the caseIgnoreMatch.
Since this attribute is not single valued, it may be possible that two 
different signatures (which differ in case) will not be able to be added 
to the attribute since your equality matching rule ignores case.


> 5.37 uddiv3EntityModificationTime 
This should be section 4.37


> 4.39 uddiv3SubscriptionFilter
>  ...
> ( IANA-ASSIGNED-OID.4.39 NAME 'uddiv3SubscriptionFilter' 
>      DESC 'UDDIv3 Subscription Filter� 

replace the ? with a '
(This applies to 4.43 and 4.30 as well)



Sections 4.37, 4.42, 4.45 and 4.46 use a generalizedTime syntax and a 
caseIgnoreMatch matching rule. These should be a generalizedTimeMatch 
matching rule.


Regards,
_________________________________________
Andrew Sciberras
eB2Bcom - Software Engineer

_______________________________________________
Ldapext mailing list
Ldapext@ietf.org
https://www1.ietf.org/mailman/listinfo/ldapext