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

From: Andrew Sciberras <[email-masked]>
Date: Fri, 21 Jan 2005 11:51:58 +1100

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
[email-masked]
https://www1.ietf.org/mailman/listinfo/ldapext