Re: Default Pretty Form of DNs

[Stig Venaas <Stig@OpenLDAP.org>]

On Tue, Dec 25, 2001 at 09:12:06AM +0100, Pierangelo Masarati wrote:
> > The 2.0 slapd(8) currently maintains each DN in two forms: user
> > and normalized.  The HEAD slapd(8) currently maintains each
> > DN in two forms: pretty and normalized.
> > 
> > User - is what the user (client) provided.
> > Pretty - a value-preserved representation of the DN.
> > Normalized - a value-modified representation of the DN.
> > 
> > The primary reason we have a pretty form is to so the server
> > can be "liberal in what it accepts but strict in what it
> > produces".  That is, we can accept DNs which do not conform
> > to RFC 2253 (e.g. LDAPv2 DNs) 
> 
> I'd say, right now current HEAD code accepts many DN forms
> including DCE

Thanks to both of you. I have trouble parsing what I wrote last night,
not very clear. This made things clearer to me.

> I don't have problems with minimal, partial or total escaping; 
> my concern is with providing no ambiguity with something that
> is as human readable as possible, considering that many terminals
> have problems with UTF-8.  However I think this is not an issue
> since the decision on what to escape can be delayed until
> everything works (I hope this answers Stig's notes)

What I'm trying to say, is that the normalized form we use internally,
need not be visible to humans/logs/terminals. In theory only the user
(client) provided (including what is in the database) DNs, and not the
normalized ones, need be visible externally. But if we need to display
any DNs (normalized or other), we can do necessary escaping at display
time. By display I mean logging etc. not when returned to client.

I very much agree with replacing "\," with hex-pair to ease parsing,
that should be done by pretty the way I understand it now. Externally
I think it's better to use "\,", it's more readable IMO.

> > >Unless we can parse it only once, and pass the parsed result
> > >around.
> 
> That's what I'd like to do: a 
> 
> typedef struct slap_dn {
> 	struct berval	dn_raw;
> 	struct berval	dn_pretty;
> 	struct berval	dn_normalized;
> 	LDAPDN		*dn_PRETTY;
> 	LDAPDN		*dn_NORMALIZED;
> } SlapDN_t;
> 
> with a set of functions that can perform each operation by filling 
> up the required part of structure starting by the most appropriate
> member if available, e.g. a dn_normalized can be built from dn_raw
> by parsing it or by dn_PRETTY by copying it to dn_NORMALIZED and 
> by normalizing the latter.  Then we can pass this structure instead
> of two or more bervals as we do now.

The LDAPDNs are parsed forms (AVAs grouped by RDN) I suppose. I guess
we can leave all of SlapDN_t (but dn_raw) blank at first. Code that
need one of the forms, can check if it is filled in, and if not call
the relevant functions to fill in what they need. This will be like a
cache then. Maybe it makes sense to have some wrapper code like
get_dn_normalized(SlapDN_t *) that returns the normalized form (and
computes and fills in dn_normalized if blank). We don't need to do
this now of course, we can do some optimizations and code improve-
ments later. I've been thinking of this caching for about a year now
I think, this is perhaps what you're thinking as well.

Stig