RE: new draft of DSMLv2 core

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

Many good proposals here -- responses inlined.

Thanks,
-J

-----Original Message-----
From: Christine Tomlinson [mailto:chris.tomlinson@sun.com] 
Sent: Tuesday, August 14, 2001 3:35 PM
To: DSML version 2
Subject: new draft of DSMLv2 core


Attached is a draft with many changes to cleanup the proposed core. The
changes to the previous version are:

1) simplified definitions of Control and Extended Ops to include
references out to any external XML chunks - why imply ASN.1 BER encoding
of common controls?
[Jeff Parham] Ultimately these fields have to be BER encoded before they
can be represented using LDAP.  How are you proposing that an arbitrary
piece of XML be BER-encoded?

2) abstracted the requestID and controls into DsmlMessage and defined
the requests and responses as extensions of that.
[Jeff Parham] Agreed.

3) defined ExtendedResponse as an extension of LDAPResult
[Jeff Parham] Agreed.

4) defined OID (union of NumericOID and xsd:NMTOKEN). Used for attribute
descriptions, etc.
[Jeff Parham] If the intent is to mold the XML schema to guarantee that
the "OID" (an RFC 2251 AttributeDescription?) is valid according to RFC
2251, it doesn't seem like this goes far enough -- e.g., xsd:NMTOKEN is
a superset of the RFC 2251 textual AttributeDescription.  As a general
rule, it makes sense to me to define the low-level DSML grammar to allow
whatever an RFC 2251/LDAP C API client expresses, leaving it up to the
LDAP server to enforce any additional restrictions on the data.  Since
in this example the further restrictions on AttributeDescription are
today enforced by the LDAP server rather than the LDAP client, it makes
sense to me to continue with that model in DSML and state that an
AttributeDescription is simply an xsd:string (analogous to RFC 2251's
OCTET STRING definition).

5) corrected minOccurs to =0 for "attr" element of Modify per RFC 2251
[Jeff Parham] Agreed.

6) defined DsmlValue to capture three cases: utf-8, binary, and URI
references. DsmlValue referenced from DsmlAttr, DsmlModifyAttr,
MatchingRuleAssertion, AttributeValueAssertion, SubstringFilter.
[Jeff Parham] While I can see value in having the XML parser do all the
transformation work automatically when reading values, my concern with
this is that it adds another level of structure to every value.  I.e.,
rather than
	<value>555-1234</value>
or
	<value encoding="base64">RFNNTHYyLjAgcm9ja3MhIQ==</value>
we would have 
	<value><utf8>555-1234</utf8></value>
or
	<value><binary>RFNNTHYyLjAgcm9ja3MhIQ==</binary></value>
This is also a divergence from DSMLv1 (the source of the value
representation in the baseline proposal).

7) fixed Compare to have AttributeValueAssertion for "attr"
[Jeff Parham] Agreed.

8) fixed definition of SubstringFilter to account for unbounded
occurrences of initial, any, and final - per RFC 2251
[Jeff Parham] I'm a little concerned about, say, a DSML gateway's
ability to synthesize an LDAP filter using the LDAP C API from a DSML
request that includes multiple initial or final elements.  It seems we
have two choices: put maxOccurs="1" for intial and final in the DSMLv2
schema or force DSML gateways written to the LDAP C API to generate a
syntax error upon receipt of a Filter with more than one initial or
final.  The former seems more appropriate to me.

9) fixed BindRequest to just have the DN of the principal. The idea is
that only the DN is needed at the DSMLv2 level since we will specify
that authentication is performed in the transport binding.
[Jeff Parham] Agreed.

   -- see separate note on DSML and security from Christine Tomlinson
and Mark Wahl --

10) added abandonRequest - omission
[Jeff Parham] Agreed.

11) defined DsmlDN/DslmRDN - used in the obivious places
[Jeff Parham] Agreed.

12) deleted the ObjectClass construction - discuss on telecon,
rationale: if needed consider XPath/XLink; missing general approach to
self contained schema without consideration of document level
[Jeff Parham] I'd like to better understand the rationale for this
proposed change.  This would be a divergence from DSMLv1.

13) defined 'attributes' in SearchRequest to as an XML sequence of
AttributeDescription elements rather than RFC2255 ',' (comma) separated
list in keeping with Filter.
[Jeff Parham] Agreed.

14) made SearchResultEntry, SearchResultReference, and SearchResultDone
top level
[Jeff Parham] Agreed for DsmlResponse.  Agreed for DsmlEnvelopeResponse
if we intend to maintain the model="async" ability -- I'll send separate
mail on this.

15) defined errorResponse to incorporate 'local' errors such as
'notAttempted', 'couldNotConnect', and 'connectionClosed'
[Jeff Parham] To be sure I understand, is the intent that communication
errors that occur between DSMLv2 gateways and LDAP servers will never be
returned inside xyzResponse elements -- they will come back as
errorResponse elements regardless of the request type?  If so, I'm
concerned about removing the correlation between xyzRequest and
xyzResponse.  What's the motivation for this model?

16) added ExtensionTypeID to incorporate either NumericOID or anyURI for
controlType, ExtendedRequest/Response type
[Jeff Parham] Can you explain the intended use of URIs in this context?

17) corrected minOccurs to ="1" for Filter. corrected min/maxOccurs to
="1" on FilterGroup
[Jeff Parham] Agreed.

18) ensured that 'desc' is used uniformly for all occurrences where an
attribute description is called for
[Jeff Parham] While it seems valuable to standardize this, this runs
counter to two different objectives:
	(1) maintaining naming consistency with RFC 2251 such that
intended element usage is clear, and
	(2) maintaining consistency with DSMLv1 (which used "name" to
refer to AttributeDescriptions) where no real technical motivator exists
to do otherwise.
Since using "name" as in (2) also achieves standardization of the term,
it seem we should choose (1) or (2) instead.  I favor (1) since it's
unambiguous and is consistent with other naming choices we've made.

19) moved scope, derefAliases, sizeLimit, timeLimit, typesOnly in
SearchRequest to attributes for conciseness
[Jeff Parham] Agreed.

20) changed name DsmlModifyAttr to DsmlModificiation - align with ASN.1
nomenclature
[Jeff Parham] Agreed.

21) included minOccurs="0" on 'value' of DsmlModification
[Jeff Parham] Agreed.

22) moved all DNs, RDNs, and booleans to attributes on ModifyDNRequest -
conciseness
[Jeff Parham] Agreed.

Christine Tomlinson
Mark Wahl
Nigel Jacobs
Sun Microsystems << File: DSMLv2B.xsd >>