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

[Hallvard B Furuseth <h.b.furuseth@usit.uio.no>]

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