RE: [dsml] DSMLv2-draft10

[Jeff Parham <jeffparh@windows.microsoft.com>]

> I don't read that out of RFC 2251.

Which part?  4.1.4 states that the AttributeType can be a textual name
(e.g., "cn") or an OID (e.g., "2.5.4.10").  4.1.5 states that an
AttriubuteDescription is an AttributeType followed by an optional
sequence of options.  This implies "2.5.4.10;binary" is a valid
AttributeDescription.

>  "AttributeDescriptionValue" sounds like the value of an
"AttributeDescription", while here it connotes either an
AttributeDescription or a NumericOID. Same mistake as calling it OID
(but reverse). How about something more neutral, like
AttributeIdentifier?

DSMLv2 AttributeDescriptionValue (and our previous "OID") is the syntax
for an LDAP AttributeDescription.  DSMLv2 AttributeDescription is the
element that has a name attribute, where the value of the name attribute
is AttributeDescriptionValue.

-J

-----Original Message-----
From: Rob Weltman [mailto:rew@worldspot.com] 
Sent: Thursday, November 08, 2001 7:34 AM
To: Jeff Parham
Cc: dsml@lists.oasis-open.org
Subject: Re: [dsml] DSMLv2-draft10


Jeff Parham wrote:

> 

> 6. In reading Rob's 11/7 mail, it struck me that we have been 
> confusing

> AttributeType with AttributeDescription.  The former is the basic LDAP

> attribute name -- e.g., "cn".  The latter is an AttributeType followed

> by an optional sequence of options; e.g., "userCertificate;binary".  
> An

> attribute description could even take the form of "2.5.4.10;binary",



  I don't read that out of RFC 2251.





> which was not allowed in the draft9 dsmlv2.xsd.  In the ASN.1 
> encoding,

> there are no references to AttributeType -- all references are to 
> either

> AttributeDescription (our "OID") or LDAPOID (our "NumericOID").  Given

> our imminent vote, rather than continue to iterate on an appropriate

> regex I propose the following changes:



  The terminology in the spec and schema had me confused (OID = NMTOKEN
| NumericOID), too.



 

> 6a. In the schema, change "OID" to "AttributeDescriptionValue" to

> reinforce the fact that this represents an AttributeDescription not an

> AttributeType.



  "AttributeDescriptionValue" sounds like the value of an
"AttributeDescription", while here it connotes either an
AttributeDescription or a NumericOID. Same mistake as calling it OID
(but reverse). How about something more neutral, like
AttributeIdentifier?





> 6b. In the schema, relax AttributeDescriptionValue syntax to be

> xsd:string.



  Well, I'd rather have it be strictly defined:



<xsd:simpleType name="AttributeIdentifier">

        <xsd:union memberTypes="NumericOID AttributeDescription"/>

</xsd:simpleType>

<xsd:simpleType name="AttributeDescription">

        <xsd:restriction base="xsd:string">

                <xsd:pattern
value="(([0-2](\.[0-9]+)+)|([a-zA-Z]+([a-zA-Z0-9]|[-])*)(;([a-zA-Z0-9]|[
-])+)*"/>

        </xsd:restriction>

</xsd:simpleType>



  or something like that. That maps to the LDAPv3 restrictions.





> 6c. In the schema, change the type of the matchingRule value to be an

> explicit xsd:string, as it is neither an AttributeDescriptionValue nor

> a

> NumericOID.  (RFC2251 gives examples of "caseIgnoreIA5Match" and

> "1.3.6.1.4.1.453.33.33".)  The RFC2251 ASN.1 enconding breaks the 
> syntax

> out as a separate syntax also (distinct from AttributeDescription,

> LDAPOID, etc.).



  Yeah, neither RFC 2251 nor 2252 specify constraints as to the contents
of a matchingRule. I would have thought they would be the same as for
AttributeDescription | LDAPOID, but that is not stated.



 

> 6d. In the spec, add the following text to section 2:  "Except where

> noted otherwise, the DSMLv2 grammar follows the same rules as the LDAP

> grammar, even if those rules are not explicitly expressed in the 
> DSMLv2

> schema - for example, a DSMLv2 AttributeDescription can contain only

> those characters allowed by LDAP."



  The example would not be necessary if the schema definition for
AttributeDescription was rigorous, as suggested above.



 

> 7. Removed searchResponse as an explicitly allowed top-level element 
> in

> the schema, since we're not using it as such in the normative 
> bindings.

> (This doesn't prevent future bindings from allowing it or other 
> elements

> to be top-level.)



  My preference (expressed earlier) would have been that searchRequest
and searchResponse were explicitly allowed as top-level elements and in
the normative bindings, and removed from BatchRequests and
DSMLResponses.



Rob