DSML V2 Extensibility

["Winston Bumpus" <wbumpus@novell.com>]

All, 

I am passing this along from Jim Sermersheim at Novell.


Some colleagues and myself have been reviewing the DSML2 spec
(specifically the xsd file), we have identified a number of issues
having to do with extensibility that we are either confused or worried
about: They all have to do with extensibility in one way or another,
the
first is a general issue, and the second and third deal specifically
with controls, extended op's, and attribute values. Please feedback
any
light or suggestions you may have.

1) DSML extensibility.

The LDAP protocol is extensible in three ways: a) Extended Operations,
b) Operation Controls, c) extensions to the ASN.1. This issue has to
do
with c.
The LDAP ASN.1 elements may be extended without a revision to the
protocol. This is strongly implied in RFC2251 Section 4 (In order to
support future extensions to this protocol, clients and servers MUST
ignore elements of SEQUENCE encodings whose tags they do not
recognize.). This has been made more explicit and more well defined in
draft-ietf-ldapbis-protocol-xx.txt Section 4 (In order to support
future
Standards Track extensions to this protocol, extensibility is implied
where it is allowed (per ASN.1).), and also in the ASN.1 of the
protocol
(EXTENSIBILITY IMPLIED).

The DSML specification has chosen to view certain LDAP ASN.1 elements
as XML attributes rather than XML elements. This is a concern where
those ASN.1 elements are extensible. It has also chosen to split
elements within an ASN.1 SEQUENCE into XML attributes and elements.

I worry that as LDAP is extended, in standard ways, that it will be
difficult for DSML to be extended. For this purpose, ideally, DSML
should not have defined a fixed XML schema, but rather should have
defined rules for converting the LDAP ASN.1 to XML Schema, and then
using those rules, produced a reference XML schema for LDAP. If this
had
been done, it would be easy to adapt to future extensions. Basically,
the conversion rules would apply to any new ASN.1 elements, thus the
extensions would automatically be applicable to DSML. This doesn't
appear to be the path taken however, so there is the concern that DSML
is more static than LDAP. I cannot find language in the DSML spec that
specifically addresses future extensions, and how a DSML protocol peer
is to handle them.

For purposes of illustration, I'll give some example of legal LDAP
extensions, that I believe would be problematic in DSML:
First a simple one:

Current ASN.1 for a Matching Rule Assertion
        MatchingRuleAssertion ::= SEQUENCE { 
                matchingRule    [1] MatchingRuleId OPTIONAL, 
                type            [2] AttributeDescription OPTIONAL, 
                matchValue      [3] AssertionValue, 
                dnAttributes    [4] BOOLEAN DEFAULT FALSE }

Current XSD for the same
	<xsd:complexType name="MatchingRuleAssertion">
		<xsd:sequence>
			<xsd:element name="value" type="DsmlValue"/>
		</xsd:sequence>
		<xsd:attribute name="dnAttributes" type="xsd:boolean"
use="optional" default="false"/>
		<xsd:attribute name="matchingRule" type="xsd:string"
use="optional"/>
		<xsd:attribute name="name"
type="AttributeDescriptionValue" use="optional"/>
	</xsd:complexType>

Imaginary future extension to the ASN.1
        MatchingRuleAssertion ::= SEQUENCE { 
                matchingRule    [1] MatchingRuleId OPTIONAL, 
                type            [2] AttributeDescription OPTIONAL, 
                matchValue      [3] AssertionValue, 
                dnAttributes    [4] BOOLEAN DEFAULT FALSE,
                value           [5] CHOICE {
                       a [0] SomeThing,
                       b [1] SomeOtherThing }}

Before this extension can be made available via DSML, I assume someone
will need to work with OASIS to define a similar extension because
there
are no automatic rules that can be applied. Also, because the original
DSML chose to use a different name for matchValue, it cannot use the
new
"value" name. I'm not sure what a DSML extension definition would look
like to allow the above extension.

Here's a real-world example. Something akin to this extension is
currently being discussed in the IETF:
Current ASN.1
        ModifyRequest ::= [APPLICATION 6] SEQUENCE { 
                object          LDAPDN, 
                modification    SEQUENCE OF SEQUENCE { 
                        operation       ENUMERATED { 
                                                add     (0), 
                                                delete  (1), 
                                                replace (2) }, 
                        modification    AttributeTypeAndValues } }
Future ASN.1
        ModifyRequest ::= [APPLICATION 6] SEQUENCE { 
                object          LDAPDN, 
                modification    SEQUENCE OF SEQUENCE { 
                        operation       ENUMERATED { 
                                                add     (0), 
                                                delete  (1), 
                                                replace (2),
                                                test    (3) }, 
                        modification    AttributeTypeAndValues,
                        assertion       Filter } }

Alternate Future ASN.1
        ModifyRequest ::= [APPLICATION 6] SEQUENCE { 
                object          LDAPDN, 
                modification    SEQUENCE OF SEQUENCE { - empty
sequence
if modificationEX is used --
                        operation       ENUMERATED { 
                                                add     (0), 
                                                delete  (1), 
                                                replace (2) }, 
                        modification    AttributeTypeAndValues },
                modificationEx  SEQUENCE OF CHOICE OPTIONAL {
                        add     [0] AttributeTypeAndValues,
                        delete  [1] AttributeTypeAndValues,
                        replace [2] AttributeTypeAndValues,
                        test    [3] Filter } } }

I don't think it would be too hard to extend in the first in DSML (add
a new operation enumeration value called "test", and a new element to
the sequence). I'm not sure about the alternate. The sad thing is,
someone has to examine it, and write an extension document (if there's
a
provision for that)

2) The next issue has to do with the other extensibility mechanisms
(Extended Operations, and Controls). This is a request to open a
dialog
on standardizing an encoding when the extension data (payload) has an
ASN.1 definition. As I understand it, current implementations
typically
BER encode Control or Extended Operation data, and then base64 encode
that and send the base64 as a base64binary.

This undermines the readability features of DSML. It would be much
better, when there is an ASN.1 definition for the payload of an
extension (which is almost always the case), to send the payload as
XML.
I suspect thought has been put into this (using xer or some other),
but
I'm not aware of the outstanding problems and issues. Is there any
active work in progress to address this?

3) The last one is similar to the second one, but has to do with
attribute values (DsmlValue). This is defined as either a string,
base64, or URI. In LDAP, all syntaxes have ASN.1 definitions (or
should), and many syntaxes (though not all) have string encodings. I
assume that syntaxes with string encodings are transmitted over DSML
with the LDAP string encodings. This is fine, I guess, but it seems
unfortunate that some of the more cumbersome complex syntaxes are
transmitted as LDAP strings, rather than encoded as XML (for example:
the LDAP syntax for facsimileTelephoneNumber would be more readable if
encoded as XML rather than the LDAP string encoding). 

I also assume that complex syntaxes that lack a string representation
are BER encoded, and then encoded and sent as base64binary. This is
not
good, as these values cannot be read or easily diagnosed. For the same
reasons as in #2, it would be good to have a standard set of ASN.1 to
XML Schema conversion rules, so these values could be XML encoded. 

Finally, new LDAP transport encodings may and will be defined for
syntaxes. Some new encodings may be able to be encoded as xsd:string,
but others will likely beg for an XML representation, so I wonder if
xsd:anyType would have been better here to allow for future expansion.


Thanks,
Jim Sermersheim
jimse@novell.com