Re: canonical_dn

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

Graham Barr <gb...@po...> wrote:
> On Wed, Jan 09, 2002 at 03:56:21PM -0000, Chris Ridd wrote:
>> 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.
> 
> From RFC2253
> 
> 4.  Relationship with RFC 1779 and LDAPv2
> 
> ...
> 
>    Implementations MUST allow an oid in the attribute type to be
>    prefixed by one of the character strings "oid." or "OID.".
> 
> ...
> 
> So IMO, it is valid to accept it, but not generate it. The oid. prefix
> is simply ignored.

Rats, I forgot about that.

Failing because the actual OID is explicitly defined to not exist would be
a little excessive...

So I agree, that DN should pass.

Cheers,

Chris