From: Graham B. <gb...@po...> - 2001-03-08 11:23:18
|
On Thu, Mar 08, 2001 at 11:04:06AM -0000, Chris Ridd wrote: > Let's see, what canonicalisation does canonical_dn do.. > > * it lowercases values that are # followed by hex, > * it lowercases types that start with an OID, > * it backslashifies RFC 2253-magic characters, > * it backslash and hex encodes 0x00-0x1f and 0x7f-0xff characters, > * it surrounds values with leading/trailing/multiple spaces with quotes. > > (Actually, that last part is not permitted by RFC 2253. You should replace > those spaces with "\20" or "\ ". I suspect "\20" would be safer especially > at the end of a string, to avoid someone simply ripping trailing spaces off > and leaving the string ending with a dangling slash.) 2253 also no longer requires the escaping of multiple spaces within a value. > Those canonicalisations look OK to me. Have I missed any others? canonical_dn also reorders the parts of multi-part RDNs Graham. |
From: Chris R. <chr...@me...> - 2001-03-08 12:44:12
|
Graham Barr <gb...@po...> wrote: > On Thu, Mar 08, 2001 at 11:04:06AM -0000, Chris Ridd wrote: > >> Let's see, what canonicalisation does canonical_dn do.. >> >> * it lowercases values that are # followed by hex, >> * it lowercases types that start with an OID, >> * it backslashifies RFC 2253-magic characters, >> * it backslash and hex encodes 0x00-0x1f and 0x7f-0xff characters, >> * it surrounds values with leading/trailing/multiple spaces with quotes. >> >> (Actually, that last part is not permitted by RFC 2253. You should >> replace those spaces with "\20" or "\ ". I suspect "\20" would be safer >> especially at the end of a string, to avoid someone simply ripping >> trailing spaces off and leaving the string ending with a dangling slash.) > > 2253 also no longer requires the escaping of multiple spaces within > a value. Yes, that appears to be an RFC 1779-ism. >> Those canonicalisations look OK to me. Have I missed any others? > > canonical_dn also reorders the parts of multi-part RDNs So it does. I suspect this will be OK for most servers that support multi-ava RDNs. It also upper-cases attribute types. > Graham. > I reckon it would be OK to call canonicalise_dn in the LDIF _write_cmd, but perhaps only in the case where the DN has a char that is not a 'SAFE-UTF8-CHAR', as per RFC 2849. Cheers, Chris |
From: Graham B. <gb...@po...> - 2001-03-08 13:11:30
|
On Thu, Mar 08, 2001 at 12:45:42PM -0000, Chris Ridd wrote: > Graham Barr <gb...@po...> wrote: > > On Thu, Mar 08, 2001 at 11:04:06AM -0000, Chris Ridd wrote: > > > >> Let's see, what canonicalisation does canonical_dn do.. > >> > >> * it lowercases values that are # followed by hex, > >> * it lowercases types that start with an OID, Actually it removes the leading oid. caharacters if the type is an oid > It also upper-cases attribute types. Yes. > I reckon it would be OK to call canonicalise_dn in the LDIF _write_cmd, but > perhaps only in the case where the DN has a char that is not a > 'SAFE-UTF8-CHAR', as per RFC 2849. Well as we don't really handle UTF8 that wee yet (because perl does not either) I will go with the regexp [\x00-\x1f\x7f-\xff] Graham. |
From: Chris R. <chr...@me...> - 2001-03-09 09:17:40
Attachments:
ldif.patch
|
Graham Barr <gb...@po...> wrote: > On Thu, Mar 08, 2001 at 12:45:42PM -0000, Chris Ridd wrote: >> Graham Barr <gb...@po...> wrote: >> > On Thu, Mar 08, 2001 at 11:04:06AM -0000, Chris Ridd wrote: >> > >> >> Let's see, what canonicalisation does canonical_dn do.. >> >> >> >> * it lowercases values that are # followed by hex, >> >> * it lowercases types that start with an OID, > > Actually it removes the leading oid. caharacters if the type is > an oid > >> It also upper-cases attribute types. > > Yes. > >> I reckon it would be OK to call canonicalise_dn in the LDIF _write_cmd, >> but perhaps only in the case where the DN has a char that is not a >> 'SAFE-UTF8-CHAR', as per RFC 2849. > > Well as we don't really handle UTF8 that wee yet (because perl does not > either) I will go with the regexp [\x00-\x1f\x7f-\xff] > > Graham. > OK. The attached patch does the moddn stuff from Kartik, adds newsuperior functionality, and canonicalises DNs when they are 'unsafe'. Sing out anyone if they can see a dreadful flaw in this; otherwise I'll integrate it in a couple of days. Cheers, Chris |
From: Kurt D. Z. <Ku...@Op...> - 2001-03-10 03:15:25
|
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 |
From: Chris R. <chr...@me...> - 2001-03-15 13:41:22
|
"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 |