Issues for discussion for Thursday 20 at 1pm EDT

[Christine Tomlinson <chris.tomlinson@sun.com>]

0) OASIS timeline, spec requirements, quorums and voting

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

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

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

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

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

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

8) 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?

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

10) Given that we're including support for "raw"
DsmlRequest/DsmlResponse elements in DSMLv2, I no longer see a
compelling reason to
support model="async" envelopes.  (See my mail titled "Proposed DSML 2
schema changes," dated 8/7/2001 for background on
model="async".)  I.e., it seems rational that async transports would use
DsmlRequest/DsmlResponse elements, and request-response
transports (like the SOAP and LDIF-replacement transports) would use
DsmlEnvelopeRequest/DsmlEnvelopeResponse elements (in an
implied model="sync" mode).
 
Does anyone object to my withdrawing my proposed model attribute on
DsmlEnvelopeRequest envelopes and asserting all envelopes are
request-response?

11) SOAP FAULT definition - should a SOAP Fault be used to provide a
hint to the recipient that an DSML proper error occurred or should a
SOAP Fault only be used when some NON-DSML thing goes wrong? The W3C
SOAP committee doesn't provide any guidance prohibiting the use of SOAP
FAULT for hinting.

12) Besides schema, the other interoperability concern I have is in the
organization of the namespace.  Directory vendors differ in the kind of
namespace organization they support, and customers differ in how they
set
up a namespace.  LDAP applications can traverse the namespace, but it is
a
complicated process often requiring a number of LDAP queries to find key
objects, and a particular namespace traversal logic may not work for all
LDAP implementations or all customer deployments. I think it is
undesirable
to require this kind of logic in a DSML v2 application, which might
reside,
for example, in a small pervasive device.

I suggest that we remedy this in DSML v2.  (I am sure this will be a
controversial point.)  I suggest that all DSML v2 implementations ought
to
support certain external entities in the specification of DNs, which:

%this;    -- Corresponds to the DN of the authenticated identity that
sent
the DSML v2 request.  This entity is useful for a user (who may not know
his DN, or may not use it to authenticate to the DSML v2 server) to
retrieve information about himself/herself; or for a device to retrieve
information about itself.  Of course, it may happen that there is no DN
for
the authenticated identity, in which case "unknown object" would be
returned as an error.

%personQueryRoot;  -- the base DN where the authenticated identity
(perhaps
anonymous) that sent the request may find person entries.  The person
entries may not be immediately under this base DN, but this describes
the
starting point for a subtree search.

%personCreateRoot;  -- the base DN where the authenticated identity that
sent the request may create person entries.  The person entries are to
be
created immediately under this base DN.

%groupOfNamesQueryRoot;  -- the base DN where the authenticated identity
(perhaps anonymous) that sent the request may find or create groups.
(Each
*QueryRoot is a starting point for a subtree search.)

%groupOfNamesCreateRoot;  -- the base DN where the authenticated
identity
that sent the request may create groups.

%physicalDeviceQueryRoot;  -- the base DN where the authenticated
identity
(perhaps anonymous) that sent the request may find physical device
entries.

%physicalDeviceCreateRoot;  -- the base DN where the authenticated
identity
that sent the request may create physical device entries.

%logicalDeviceQueryRoot;   -- the base DN where the authenticated
identity
(perhaps anonymous) that sent the request may find logical device
entries.

%logicalDeviceCreateRoot;   -- the base DN where the authenticated
identity
that sent the request may create logical device entries.

%servicesQueryRoot;  -- the base DN where the authenticated identity
(perhaps anonymous) that sent the request may find service
location/description information.

%servicesCreateRoot;  -- the base DN where the authenticated identity
that
sent the request may create service location/description information.

Via the use of these external entities, we can eliminate the need for
namespace traversal logic from many and perhaps most DSML v2
applications.
The DTD would specify URIs that return values for each of these external
entities.  I believe we want to specify a closed and short list of which
external entities are to be supported, and I suggest the list specified
in
this note.

13) One .xsd or two? Should we have a base.xsd and a separate batch.xsd
(Sun proposal) or a single dsmlv2.xsd (baseline proposal)

14) wording of compliance?

(1) A DSMLv2-compliant entity is an element of type dsmlEnvelopeRequest,
dsmlEnvelopeResponse, dsmlRequest, or dsmlResponse
that satisfies the rules (XML schema and other guidelines) to be
published in the working group's specification.
[Jeff Parham] Noticeably absent is the searchResponse from Sun's
batch.xsd.  I don't yet see the need for it, but if necessary we can
revise this later to include it.

(2) One or more DSMLv2-compliant entities may be embedded in an XML
document.

(3) The DSMLv2 transports being defined by this working group -- the
file (LDIF replacement) transport and the SOAP transport -- require
dsmlEnvelopeRequest or dsmlEnvelopeResponse as the document type.

(4) The flow and focus of the DSMLv2 specication will continue to be on
interactions that utilize the dsmlEnvelopeRequest and
dsmlEnvelopeResponse as root documents. Interactions that do not utilize
the dsmlEnvelopeRequest and
dsmlEnvelopeResponse elements may be detailed in future transport
specifications, allowing for maximum flexibility in these
yet-to-be-defined transports while letting the working group concentrate
on refining and giving examples for the already-defined transports.

(5) The scope of the DSMLv2 working group is to deliver a specification
detailing the DSMLv2 grammar (dsmlEnvelopeRequest,
dsmlEnvelopeResponse, dsmlRequest, and dsmlResponse and their contents),
the file transport, and the SOAP transport.  Work
beyond this scope -- additional transports, entities, etc. -- is left to
individual vendors and future versions of the DSML specification.