OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

dsml message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]


Subject: All quiet on the oasis-open front


(Partly to check the list is working, and partly to stimulate some 
discussion!)

I would like the next version of DSML to clarify precisely what is 
meant by directory attributes and values, as the definitions in DSML 
1.0 are basically too vague and don't correctly model what directories 
do. This makes DSML 1.0 effectively unusable in many environments.

For example, DSML 1.0 cannot properly represent the following 
attributes from an LDIF fragment:

cn;binary:: FAtIZWxsbyB3b3JsZA==
jpegPhoto:: <lots of base 64>
jpegPhoto;binary:: <lots more base 64, but not the same as above>
userCertificate;binary:: <lots of different base 64>

The closest DSML 1.0 can get is with the encoding attribute on 
<dsml:value>, but this only controls how the value is embedded into the 
XML file.

The fix would be, I think, to require that the name attribute on 
<dsml:attr> be the complete LDAPv3 attribute description, ie it 
includes all those funny things like ;binary (from RFC 2251) and 
;lang-de (from RFC 2596).

It also isn't clear how DSML 1.0 would work with non-LDAPv3 
directories. eg an LDAPv2 directory requires that many string values 
are encoded using T.61 and not UTF-8. How should the T.61 string be 
encoded in the XML?

Cheers,

Chris



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]


Powered by eList eXpress LLC