[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [dsml] DSML V2 Extensibility
John, Yes, I think we need to schedule a call and discuss a possible 2.1. Winston >>> John McGarvey <mcgarvey@us.ibm.com> 3/26/2003 11:42:37 AM >>> Jim, Winston, These seem to me to be valid and serious concerns. So ... what do we do about them? Do we need to convene a DSML 2.1 working group? Regards, John John McGarvey IBM directory architect 919-877-4892 or t/l 254-4892 "Winston Bumpus" <wbumpus@novell.com> on 03/26/2003 02:04:18 PM To: "<DSML version 2" cc: "Jim Sermersheim" <JIMSE@novell.com> Subject: [dsml] DSML V2 Extensibility 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
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]