Re: canonical_dn

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

Graham Barr <gb...@po...> wrote:
> On Wed, Jan 09, 2002 at 08:28:08AM -0000, Chris Ridd wrote:
>> Graham Barr <gb...@po...> wrote:
>> > On Sun, Jan 06, 2002 at 01:57:37PM +0100, Peter Marschall wrote:
>> >> Sorry, 
>> >> 
>> >> a few small errors in my last mail's listings.
>> >> Here's the corrected version
>> > 
>> > Can you get it so that it will pass the t/01canon.t testcase ? Also can
>> > explode_dn share the same code ?
>> > 
>> > Graham.
>> > 
>> > 
>> 
>> There are some other DN test cases at:
>> 
>> 	<http://www.openldap.org/ietf/ldapbis/dn.txt>
> 
> Thanks,
> 
> After adding those the only failure we have is in accepting the following
> bad DNs, although I am not convinced that they are all bad.
> 
> OID.1.1=jsmith // invalid attribute type name
> 
>   why ? is 1.1 an invalid OID ?

OIDs in attribute types don't have an "OID." prefix.

The DN should be "1.1=jsmith"

The BNF in RFC 2253 doesn't permit "." in attribute types unless the entire
attribute type is an OID.

It is a valid OID, but defined by X.208 to not exist.

> UID=jsmith, DC=example, DC=net // spaces
> 
>   I dont think this is bad. Th RFC states that you should accept spaces
> around the ,s

Agreed. It is bad in the sense that an implementation shouldn't generate
it, but it must be able to parsed it.

> UID=jsmith;DC=example;DC=net  // semi-colons
> 
>   The RFC states that implementations should allow for the use of a ;
>   instead of a ,

Ditto.

> 
> CN="John Smith",DC=example,DC=net  // quotes
> 
>   Again, the RFC states that values may be surrounded with "s

Ditto.

> 01.1=jsmith // invalid numeric OID
> 
>   This one could be easily fixed as we just change \d+ to [0-9]\d*
>   but I dont really feel the need.

Given the number of DNs containing OIDs as attribute types (approx 0) I
concur.

> Graham.
> 

Cheers,

Chris