Re: [dsml] DSMLv2-draft10

[Rob Weltman <robw@worldspot.com>]

Jeff Parham wrote:
> 
> > I don't read that out of RFC 2251.

  I hadn't meant to include that, but anyway...

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

RFC 2251 is ambiguous in that it says:

"An AttributeType takes on as its value the textual string associated
with that AttributeType in its specification."

  But what is the "textual string"? The textual name or the OID or both?
It later says:

"A specification may also assign one or more textual names for an
attribute type."

  It doesn't refer to an OBJECT IDENTIFIER as a "textual string"
anywhere. As a matter of fact, the only time "textual" is used in the
RFC is for the textual attribute name and for errorMessage.

   But it is possible the authors intended for "textual string" in this
case to mean either the "textual name" or the "OBJECT IDENTIFIER", in
which case "2.5.4.10;binary" would be a valid AttributeDescription, so I
accomodated that possibility in the definition of AttributeIdentifier.


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

  OK. It can use the strict definition I supplied (the union of textual
name and OID, potentially followed by options.

Rob

> 
> -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
> 
> ----------------------------------------------------------------
> To subscribe or unsubscribe from this elist use the subscription
> manager: <http://lists.oasis-open.org/ob/adm.pl>