Re: Irrelevant empty IA5String (was: vacation message & schema design)

[John McMeeking <jmcmeek@us.ibm.com>]

Hallvard,

If it makes you feel any better...

Within our development teams, we haven't been able to agree on empty
strings.  It will probably be decided by our customers, and it probably
won't make any difference what the RFC eventually says.

On the one hand, we have seen lots of directory entries littered with empty
strings because of poorly designed applications that inadvertantly added
empty strings for values that were not entered on a user interface or as a
consequence of improperly handling deleting a value on the user interface.
But it worked and nobody noticed.

I've never seen a LDAP user interface that distinguished between an empty
string and a missing attribute.  But I have seen some applications break
when they encounter these entries (maybe they were poorly designed, too).

So I wish V3 had never allowed empty strings, and I wish our servers had
never allowed them.

On the other hand we have a small number of customers - invariably large
customers - who intentionally use empty strings.  They're not my customers,
so I don't know what the reason is.  And since the V3 standards allow empty
strings for IA5 String and our implementation doesn't particulary
distinguish between Directory String and IA5 String, it is hard to say "you
can't do that".

But...  V3 did allow empty strings, and some customers have written
applications that rely on them, and some customers are blithely unaware
that critical applications may be inadvertantly putting empty strings in
the directory - applications that would break if the server rejected empty
strings.

Personally, I'd like to reject empty strings.  But I know that if we do
that (or some alternatives that have been considered by our teams) it will
have to be done in such a way that when a customer calls at 2:00 AM
Saturday morning because a critical app just broke after his Friday night
upgrade,  we'll have to be able to get him a "fix" on Sunday.  "Your
application violates some RFC" will not be an acceptable answer.


John  McMeeking


Hallvard B Furuseth <h.b.furuseth@usit.uio.no> wrote on 11/12/2004 10:23:43
AM:

> I feel a little silly keeping on about this subthread, arguing about a
> position I'm not even sure I support (allowing empty IA5 Strings).  So,
> for the record: I don't know what would be best in that regard.  I would
> have preferred string types to allow empty values in general, and I
> don't buy several of the arguments against, but consistency with the
> other string types is a good argument against allowing it for IA5String.
> OTOH, it sounds to me like Stringprep should support empty strings
> anyway.
>
>
> So the rest is only about why empty strings might be good, if anyone is
> interested.
>
> Leif Johansson writes:
> > I don't believe you can show me a deployed schema which actually relies
> > on empty IA5Strings.
>
> Certainly not, since we use OpenLDAP - which rejects empty IA5Strings.
>
> John asked for an example of an empty string being different from an
> absent string, and I gave two: Empty vacation messages, and empty DNs.
> That's all.  In the case of empty vacation messages, I would think it's
> fairly obvious that the natural way to represent empty user input is
> with an empty string, and that anything else is a workaround.
>
> The arguments against empty strings apply equally well against empty DNs
> - LDAP could have defined the root DN to be represented as " ", but it
> doesn't.  It would have been more cumbersome to handle, but that's all.
> The reason I mentioned an empty string as meaning "no default message"
> is precisely because many languages and config systems treat empty
> strings as False.  So again, an empty string would be easier than " ",
> but no more than that.
>
> If there is some syntax (e.g. like DNs), which is defined elsewhere and
> known to clients to the string, one may have fewer options about
> inserting hacks like that in LDAP.  One could use Octet String - but
> lose functionality like caseIgnoreMatch.
>
> BTW, a third example of empty strings is empty passwords.  Which are
> allowed for userPassword (Syntax Octet String), and definitely different
> from not having a userPassoword.
>
> > In fact as I have noted elsewhere in this thread most client libraries
> > could not distinguish empty strings from an absent attribute-value.
>
> Such libraries are buggy, since DNs and octet strings may be empty.  The
> only libraries I have tried - Perl Net::LDAP, python-ldap and the LDAP C
> API - work correctly, at least the way I've used them.
>
> Ignoring an empty value in a list of values sounds like a strange bug in
> any case.  And I'm wondering which clients you have had this trouble
> with, unless you have servers which allows empty strings.  If they do,
> then disallowing them does introduce incompatibilities.  (Yes, I'm
> curious if you are sitting on an argument _for_ empty IA5 String:-)
>
> --
> Hallvard