Re: Net::LDAP::Util::canonical_dn

[Chris R. <chr...@me...>]

Graham Barr <gb...@po...> wrote:
> On Thu, Mar 15, 2001 at 12:00:19PM -0600, Clif Harden wrote:
>> It may be the easy way out, but I think it is the best option. It gives
>> the user the choice on how the data is present back to him.
> 
> I agree.
> 
>> > What default should we have? ;-) We'd want to preserve the existing
>> > interface (I guess) so we need a default.
>> 
>> 
>> I think the default should be the current way perl-ldap handles the data,
>> encode => none.  If the user does not care about encoding no changes
>> to his software would be needed.
>> 
>> If the user wants the canonicalizer, encode => canonical.
>> If the user wants base 64, encode => base64.  Would this require the perl
>> base64 module?
>> 
>> 
>> I have no idea how much coding work this would be.
> 
> 
> this seems quite reasonable, and would not be too difficult to do.

OK.

>> As I was writing this message I thought of something we need
>> to comprehend.
>> 
>> Mark Wilcox put dumping data in XML format, how is our encoding 
>> going to affect these methods.  I am sure we will need to add 
>> attribute tags specifing the encoding method used on the data
>> if the data is encoded.  
> 
> In DSML the DN is base64 encoded if it contains special characters
> and then it is flagged as such (IIRC).

I don't think that changing the LDIF export will (or should) affect the
DSML export. Except possibly we might want to add a similar 'encode'
argument to DSML::new(). But I'm not sure what we might let people encode
to, and since people who don't pay money to Oasis aren't now permitted to
participate in fixing the bugs in the DSML spec (grr) I really don't know
what to suggest.

I'm sure you can also use the normal SGML/XML entity names for special
characters, like &amp; and &lt; and so on. Or even &#nn;. (Just committed a
trivial fix to the DSML code that does this normalization, btw.)

> Graham.

Cheers,

Chris