Subject: Empty IA5String

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Wed, 10 Nov 2004 13:39:43 -0500

It's my opinion that IA5 String values should have
non-zero length.  Non-zero length values were
explicitly precluded for many attributes of
IA5String syntax (see RFC 1274).  Removing this
restriction would cause breaking.

It is debatable whether RFC 1274 implied a general
restriction that IA5 String values be non-empty,
however it seems most agree that it not clear what
the semantics an empty value would have.

Those in favor of allowing empty IA5 values have
primarily argued that the empty value is useful
to represent no values.  Traditionally, in X.500,
no value is represented by having no values.
Some have also that an application could regard
empty values as being a "default" value.
Traditionally, " " has been used for such purposes.

In either case, it likely that many clients would
not regard an empty string as having one of these
semantics, but as simply being invalid.  That is,
an zero-length 'foo' attribute is far more likely
to be regards as an invalid foo than as either no foo
or a default foo or some other foo.

I also note that a number of programming languages
do not handle well zero-length values, often be confused
as no value.

For these reasons, I suggest that the IA5 string syntax
be revised to preclude zero-length values.

Kurt

---

From: Mark Smith <[email-masked]>
Date: Wed, 10 Nov 2004 16:45:58 -0500

> restriction would cause breaking.

And it may break some LDAP implementations, especially some client 
applications, if zero length strings are disallowed.  But that is just a 
guess; I don't think we really know.

> the semantics an empty value would have.

I agree there is no consensus on what semantics an empty value would 
have.  We would need consensus on matching (and I do not think that 
would be very difficult to achieve).

> Traditionally, " " has been used for such purposes.

I can't say I have seen " " used much (but it seems like a reasonable 
choice if zero-length strings are not allowed).

> or a default foo or some other foo.

Agreed.  The real question to me is "Do we have clients that rely on 
using zero length strings?"  Because if we, and if the older 
specifications allowed them, them I see no reason to break them just 
because we have now introduced the concept of string prep.  Clearly some 
implementations will have trouble with zero-length strings, but that 
could be fixed over time.

> do not handle well zero-length values, often be confused

Really?  I think it is possible in any decent programming language to 
distinguish between a zero length string and no string at all.  Maybe I 
only use good languages or maybe I am forgetting something.

> be revised to preclude zero-length values.

I think we need more data before reaching a conclusion.  Hopefully this 
thread will generate it.

-Mark