RE: All quiet on the oasis-open front

[James Tauber <JTauber@bowstreet.com>]

We will undoubtedly need to address these issues once technical discussions
begin, but for now we have a number of process issues to sort out. I will
post a separate email in a moment outlining what the principal goal of this
discussion list is over the next several weeks.

James (DSML Discussion Lead)
--
James Tauber
jtauber@bowstreet.com
Director XML Technology
Bowstreet www.bowstreet.com

> -----Original Message-----
> From: Chris Ridd [mailto:Chris.Ridd@messagingdirect.com]
> Sent: Tuesday, May 16, 2000 7:00 AM
> To: dsml@lists.oasis-open.org
> Cc: Chris.Ridd@messagingdirect.com
> 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
>