[dsml] DSMLv2-draft10

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

This is an update moving forward from DSMLv2-draft9-jp.doc.  

1. Per Shon's 10/10 mail, incorporated XSD->XSI changes.

2. Per Andy's 11/6 mail issue #1, changed spec examples to match the
schema; e.g., DSMLv2 representation is
      <resultCode code="0" descr="success"/>
   not
      <resultCode descr="success">0</resultCode>

3. Per Andy's 11/6 mail issue #2, changed spec examples to match the
schema; e.g., DSMLv2 representation is
      <attributes>
         <attribute name="cn"/>
      </attributes>
   not
      <attributes>
         <attribute>cn</attribute>
      </attributes>

4. Per Andy's 11/6 mail issue #3, changed spec examples to match the
schema; i.e., DSMLv2 representation requires control values to precede
other child elements in those elements derived from DsmlMessage.

5. Per Andy's 11/6 mail issue #4, added the following text: "In bindings
(such as those described in this document) where the server generates a
SearchResponse for a SearchRequest, the server MUST associate the
requestID with the SearchResponse, not with its child elements."

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",
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:

6a. In the schema, change "OID" to "AttributeDescriptionValue" to
reinforce the fact that this represents an AttributeDescription not an
AttributeType.

6b. In the schema, relax AttributeDescriptionValue syntax to be
xsd:string.

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

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

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

8. Removed ExtensionTypeId from the schema -- it was not referenced.

Thanks,
-J

DSMLv2-draft10.doc

DSMLv2.xsd