perl-ldap-dev

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

[Clif H. <cl...@di...>]

> 
> Clif Harden <cl...@di...> wrote:
> >> 
> >> "Kurt D. Zeilenga" <Ku...@Op...> wrote:
> >> > I'm not sure this discussion applies to presentation of
> >> > server returned results in LDIFv1, but I suggest that when
> >> > presenting search results in LDIF entry format that the
> >> > returned DN be presented "as is" if possible, otherwise
> >> > base64 encoded.  It's kind of nasty for APIs to muck with
> >> > returned values without applications specifically
> >> > asking for such mucking.
> >> > 
> >> > Kurt
> >> > 
> >> 
> >> OK, that's a vote for base-64 encoding, which was what I was doing
> >> originally. Graham thinks keeping the DNs readable is more important.
> >> 
> >> Does anyone else have other comments?
> >> 
> >> Cheers,
> >> 
> >> Chris
> >> 
> >> 
> > 
> 
> Hi Clif,


Hi!


> 
> > I prefer the following.
> > 
> > If the DN is readable then the DN is printed as a readable string, 
> > if the DN has unreadable characters in it then printed as an
> > encoded string.
> 
> OK, assuming the LDIF interpretation (or stricter) of 'readable'. But how
> do we encode it, using the canonicalizer, or a simpler and less 'damaging'
> base64 encode?


Most of the tools I use encode in base64.  I do not know what to say
about a DN canonicalizer just yet, I know that it is needed.


> 
> > How about giving the user an encode option. 
> 
> That's the easy way out :-)

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.

> 
> 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.


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.  


Since I forgot to copy the perl-ldap list on my first response to you,
I have included the perl-ldap list on this reply.

Regards,

Clif 

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

[Graham B. <gb...@po...>]

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.

> 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).

Graham.


> 
> 
> Since I forgot to copy the perl-ldap list on my first response to you,
> I have included the perl-ldap list on this reply.
> 
> Regards,
> 
> Clif 
> 
> 

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

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

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

Chris Ridd <chr...@me...> wrote:
> 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.

I've added support for setting this behaviour in the constructor (and
documented it). The revised revised (:-) patch is attached.

Cheers,

Chris