Subject: Empty IA5String

From: Hallvard B Furuseth <[email-masked]>
Date: Sun, 7 Nov 2004 22:42:49 +0100

[Syntaxes] section 3.3.15 says an IA5 String may be empty.

Why is that, when Directory String and Printable String may not?
If anyone knows, maybe a note should be added to explain.

[Strprep] section 2 says:

  This process is intended to act upon non-empty character strings.  If
  the string to prepare is empty, this process is not applied and the
  assertion is evaluated to Undefined.

Since an IA5 String can be empty, why shouldn't two empty IA5 Strings
match each other?

-- 
Hallvard

---

From: Steven Legg <[email-masked]>
Date: Tue, 09 Nov 2004 09:41:29 +1100

Hallvard,

> Why is that, when Directory String and Printable String may not?

The Directory String and Printable String syntaxes derive from syntaxes
in X.520 that have been constrained to have at least one character.
The IA5 String syntax does not have a counterpart in X.520 so it doesn't
need to be constrained for interoperability reasons.

> Since an IA5 String can be empty, why shouldn't two empty IA5 Strings

Clearly there is an incompatibility. The working group needs to decide whether to
restrict IA5 String to at least one character, or to allow empty strings to
compare true.

Regards,
Steven

---

From: Hallvard B Furuseth <[email-masked]>
Date: Tue, 9 Nov 2004 14:19:03 +0100

Steven Legg writes:
> (...)
> The working group needs to decide whether to restrict IA5 String to at
> least one character, or to allow empty strings to compare true.

My vote from an LDAP viewpoint would be minimal change, i.e. do not
disallow empty IA5 Strings.

OTOH, if an X.500 implementor wants to support IA5 String, maybe the
reason why X.500 requires 1+ characters in the other string syntaxes,
also would make the same restriction preferable in IA5 String?

-- 
Hallvard

---

From: John McMeeking <[email-masked]>
Date: Tue, 9 Nov 2004 07:47:45 -0600

On a personal note, I've always found the notion of an zero-length value
hard to digest.  I could really use a real world example (not in the
drafts, just to help me accept the concept) where a zero-length value has a
different meaning than no value.

Otherwise, from the perspective of not breaking existing implementations
(or applications), since zero-length values are valid for several syntaxes
(distinguished name, octet string, IA5 string), unless someone can make a
good argument for zero-length values being an error in the current RFC, I
don't think we should change it.

John  McMeeking

---

From: Hallvard B Furuseth <[email-masked]>
Date: Tue, 9 Nov 2004 15:28:32 +0100

John McMeeking writes:
> On a personal note, I've always found the notion of an zero-length
> value hard to digest.  I could really use a real world example (not in
> the drafts, just to help me accept the concept) where a zero-length
> value has a different meaning than no value.

I can give you what might have become a real-world example at our site
if Directory Strings could be zero-length:  A 'vacation message'
attribute which the mail system would check.  If the attribute was
present, the mail system would send a vacation message in response to
incoming messages, with a standard initial text + the optional
user-supplied message.

As it is, we ended up another boolean attribute which means 'there is an
active vacation message', and only use the vacation attribute if the
boolean is TRUE.

Except for that, I have no problem with empty attributes in general.
The presence of a value - or of an attribute - is information.  Its
contents is some other information, and its format depends on the
application.  Empty strings are rare, but not useless.  Think of an
empty DN, for example.  (Yes, I know that does not have string syntax.)

-- 
Hallvard

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Tue, 09 Nov 2004 09:50:29 -0500

>incoming messages, with a standard initial text + the optional

Use an " " to indicate no user-supplied message...

---

From: Hallvard B Furuseth <[email-masked]>
Date: Tue, 9 Nov 2004 15:57:26 +0100

> Use an " " to indicate no user-supplied message...

We could have, but it's a hack.  And it would complicate things a bit
if the software were to be upgraded to give a different standard message
depending on whether or not there is a user-supplied message.
(It says something about "here is a message from the user:".)

-- 
Hallvard

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Tue, 09 Nov 2004 09:37:21 -0500

>different meaning than no value.

I concur. 

>(or applications),

Which applications would we be breaking?  Is there actually
interoperability between implementor of IA5 string?

I argue that allowing empty IA5 strings might actually break
more applications.

>since zero-length values are valid for several syntaxes
>(distinguished name, octet string, IA5 string),

The problem I have with empty IA5 strings is that the
matching semantics of them is not clear, both when
comparing IA5 strings to IA5 strings, but also when
comparing IA5 strings to Directory strings.

>unless someone can make a
>good argument for zero-length values being an error in the current RFC,
>I don't think we should change it.

I believe it was the intent of designers of RFC 1274 for the
IA5String syntax to disallow empty IA5 string values.  I
believe it was their intent that IA5 string values behave
in a manner consistent with X.500 directory strings.
Note that in RFC 1274 any where that a max size limit was
stated for a value, it was listed as (1..N) not (0..N).
This implies that the when no constraint was stated, that
(1..) was intended.  Note also for all of the attributes
(mail, domain names, etc.) introduced of this syntax, empty
values are nonsense.

That is, it can be reasonable argued that it would be a
change to REMOVE the restriction implied by RFC 1274
(and possible other ISDs).

---

From: John McMeeking <[email-masked]>
Date: Tue, 9 Nov 2004 09:42:18 -0600

> interoperability between implementor of IA5 string?

I'm assuming there could be a client application that is storing
zero-length strings (IA5 String, that is) in a directory on the basis of
the current RFC's definition of zero or more characters.  If we changed the
definition of IA5 String to one or more characters, and the server vendor
changed their server implementation to match, a previously working (and
valid) application could start failing.  It could also present problems for
the server in dealing with existing entries containing what just became
illegal data.

> I argue that allowing empty IA5 strings might actually break

I agree with that.  I've seen more than a few applications that would not
work if they got a zero-length value - string or otherwise.  You could
argue that is a problem with the application not taking into consideration
that an attribute can have a zero-length value.  But you could also argue
that something (a syntax) that breaks applications in this way is poorly
designed.

John  McMeeking

---

From: Hallvard B Furuseth <[email-masked]>
Date: Tue, 9 Nov 2004 17:18:35 +0100

I'm of three minds (at least) about this...

> comparing IA5 strings to Directory strings.

I don't understand.  With stringprep that is currently so, but that's
why we are still working on it...

Pre-stringprep I don't see any problem with comparing IA5 with IA5.

I can see comparing empty IA5 with Directory String could be a problem
if caseIgnoreMatch or whatever expects non-empty strings.  On the other
hand, caseIgnoreMatch cannot be used with IA5 String values according to
[syntaxes].  On the third limb, I believe LDAP implementations have been
lax about that (maybe because it was only said somewhere in X.500, not
in the LDAP standard).

> in a manner consistent with X.500 directory strings.

What the original intent was doesn't seem to relevant by now, but it
does seem likely that implementors will have implemented them to be
consistent with the other syntaxes.

> (1..) was intended.

Why so?

> (and possible other ISDs).

Yes.

-- 
Hallvard

---

From: Leif Johansson <[email-masked]>
Date: Tue, 09 Nov 2004 19:16:48 +0100

> active vacation message', and only use the vacation attribute if the

I'd say the typical solution is that the attribute is an optional 
attribute of an objectClass indicating the function of a vacation
message. The filter is then objectClass=something rather than the
presence-filter based on the vaction attribute.

	MVH leifj

---

From: Hallvard B Furuseth <[email-masked]>
Date: Tue, 9 Nov 2004 23:23:12 +0100

Leif Johansson writes:
>To: Hallvard B Furuseth <[email-masked]>
> message.

For a vacation message by itself, yes.  Not when it's part of an
object class for mail handling in general.  Spam and virus filtering,
forwarding, IMAP server, maildrop, etc.

> The filter is then objectClass=something rather than the

-- 
Hallvard

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Tue, 09 Nov 2004 17:39:52 -0500

>(It says something about "here is a message from the user:".) 

No more than "".  In either case, you attaching additional
semantics on to values.

---

From: Steven Legg <[email-masked]>
Date: Wed, 10 Nov 2004 11:26:20 +1100

Hallvard,

> also would make the same restriction preferable in IA5 String?

Speaking as an X.500 implementor, I don't see any technical reason why
string syntaxes have to have a non-zero length. I guess the X.500 designers
thought zero-length strings weren't particularly useful so they disallowed
them.

Zero-length strings haven't caused me any problems, nor has comparing
IA5String values to DirectoryString values. That is probably because the
string preparation that I currently use effectively produces an unconstrained
UniversalString, which can be zero length. I don't assume that the result
of the string preparation has to be a valid value of the original string type.
Having two empty strings compare true is the natural extrapolation of the
most obvious way to compare two strings of characters.

By the way, I've encountered clients that want to store zero-length DirectoryStrings.
It's totally bogus, but third-party vendors can be stubborn about making changes
when their application "works with other directory servers", so for our customer's
sake we need to provide workarounds.

For the record, I don't care whether IA5 String syntax is constrained to have
at least one character. However, I increasingly believe that stringprep should
be able to produce a zero-length string as input to a matching function.

Regards,
Steven

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Wed, 10 Nov 2004 11:34:38 -0500

>be able to produce a zero-length string as input to a matching function. 

I assume what you mean here is that you are increasing
believing that LDAPprep should be redesigned to accept
as input an zero-length string and output a zero-length
string for this input.

This would require a major redesign of the algorithm.

If the designers of a particular matching rule desires
that zero-length input strings be matched as X strings
(where X is either a zero-length string or a particular
non-zero-length string, e.g. " "), the specification for
that rule should say something like:
        For non-zero-length input strings, the string
        is to prepared in accordance with LDAPprep.
        For zero-length input strings, no preparation
        is done.  The input string is used directly.
or:
        If the input string is zero-length, the string
        is matched as if X was inputted.  For input
        strings which are non-zero-length, the input
        string is prepared in accordance with LDAPprep
        before being compared.

I don't think we should undertake a redesign LDAPprep
to handle zero-length input string.

---

From: Hallvard B Furuseth <[email-masked]>
Date: Wed, 10 Nov 2004 17:41:35 +0100

> This would require a major redesign of the algorithm.

Why?  Just put the zero-length shortcut you gave at the top of

-- 
Hallvard

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Wed, 10 Nov 2004 12:54:56 -0500

>stringprep algorithm instead of in the matching rule(s) which uses it:

Even if we presume that the proper LDAPprep("") output is "",
specifying this in the I-D would require significant revision
of the text.  And, if we presume that LDAPprep("") output for
some character string matching rules is not "", the I-D would
require significant redesign.

In short, LDAPprep was designed for X.520-based matching rules.
It wasn't designed to handle empty inputs and redesigning it
to handle such inputs is, IMO, non-trivial.

However, before we consider any change to LDAPprep, we first
must reach consensus the semantics of empty values in IA5
Strings.  I note as well that I intend to argue that IA5
Strings, as specified in RFC 1274, were intended to be
non-empty and expected in many to be non-empty and that by
allowing non-empty values in IA5 string will lead to far
more problems than it will resolve.

Kurt

---

From: Leif Johansson <[email-masked]>
Date: Wed, 10 Nov 2004 19:43:29 +0100

> forwarding, IMAP server, maildrop, etc.

If you want to be able to indicate the presence of a feature with
an optional attribute, yes that is exactly how you do it. Object-
classes are you friend. Orthagonal design is good.

	MVH leifj

---

From: Leif Johansson <[email-masked]>
Date: Wed, 10 Nov 2004 19:45:31 +0100

> thought zero-length strings weren't particularly useful so they disallowed

Speaking as someone who writes ldap clients in perl, java and other
modern languages (i.e not c) I have to disagree. Empty strings, while
possible, create nothing but headaches.

	MVH leifj

---

From: Steven Legg <[email-masked]>
Date: Thu, 11 Nov 2004 09:47:48 +1100

Kurt,

> as input an zero-length string and output a zero-length

No, I believe that LDAPprep should be able to output a zero-length
string given a non-zero-length input string. There are steps within
LDAPPrep that remove various insignificant characters. It should be
allowed to produce a zero-length string when it turns out that all the
characters are insignificant.

> This would require a major redesign of the algorithm.

I don't see why. There are internal steps where an empty string is replaced by
a single space. Just take those bits out.

I think the current description of the matching semantics in [syntaxes] is
compatible with zero-length strings being output by LDAPprep, but it would
be worth me adding some text to point out that zero-length strings can be
output by LDAPprep, and to formally state that two empty strings match.

> to handle zero-length input string.

Allowing it to produce a zero-length output string is enough.

Regards,
Steven

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Wed, 10 Nov 2004 18:12:00 -0500

At 05:47 PM 11/10/2004, Steven Legg wrote:

>string given a non-zero-length input string.

I disagree.  I believe it LDAPprep must be idempotent. That is,
        LDAPprep(LDAPprep(x)) = LDAPprep(x)
be true for all X.

>There are steps within
>I don't see why.
>There are internal steps where an empty string is replaced by

Not enough to ensure idempotence.

>Allowing it to produce a zero-length output string is enough.

Not enough to ensure idempotence.

---

From: Steven Legg <[email-masked]>
Date: Thu, 11 Nov 2004 10:18:47 +1100

Kurt,

Kurt D. Zeilenga wrote:
> of the text.

I don't see it. Which of the steps in LDAPprep would be broken if the
output of the previous step (or the original input) happened to be a
zero-length string ?

 > And, if we presume that LDAPprep("") output for

LDAPprep already has internal steps that replace an empty string with " ",
so why isn't this cause for a significant redesign ?

Regards,
Steven

---

From: Steven Legg <[email-masked]>
Date: Thu, 11 Nov 2004 10:30:26 +1100

Kurt,

Another data point ...

Component matching allows any string matching rule to be applied to any
string component of any ASN.1 type. There is nothing to prevent those
string components having zero length. We might be able to force the
IA5 String syntax to have at least one character but we can't do the
same for every string component of every ASN.1 type.

Regards,
Steven

---

From: Steven Legg <[email-masked]>
Date: Thu, 11 Nov 2004 10:40:56 +1100

Kurt,

Kurt D. Zeilenga wrote:
> I disagree.  I believe it LDAPprep must be idempotent.

Any particular technical reason why ?

 > That is,

I think LDAPprep should be able to produce zero-length output and you
think LDAPprep should be idempotent - both of us are satisfied if the
input to LDAPprep is permitted to be a zero-length string.

Regards,
Steven

---

From: Rici Lake <[email-masked]>
Date: Wed, 10 Nov 2004 20:06:45 -0500

> same for every string component of every ASN.1 type.

Very true. This is (amongst) the reasons I consider the generalised
use of stringprep to be unfortunate. Of course, one could define
string matching rules which are just like the current ones but do
not use stringprep, or use another profile. In fact, I believe that
will be necessary given the concerns I outlined a couple of days ago.

On a related note, it is not clear that the non-significant characters
being deleted by stringprep are all that non-significant.

I don't know whether or not this is a problem, but: it is legal to 
follow
a character of class C with a combining character (class M). For
example, the following is a legal Unicode sequence: U+0041 U+200B U+0301
(CAPITAL A, ZERO WIDTH SPACE, COMBINING ACUTE ACCENT)

The U+0301 is a "defective combining sequence" (which is specifically 
legal,
despite the use of the word defective). Simply deleting the U+200B will
result in a non-canonical string; map-to-nothing therefore has to happen
earlier (which is does, so that's ok). This turns the above sequence 
into
U+00C1 (CAPITAL A WITH ACUTE).

Arguably, the original input was "bogus", but it is, I believe,
typographically meaningful, since the ZWS is allowed to expand
during justification, and is additionally a word-break character.
Unicode has some odd corners.

The insignificant character deletion which occurs in LDAPprep is
post-normalization, and therefore could theoretically create
non-NFKC normalised strings, if for example a telephone number
were allowed to contain non-IA5 characters. (Is there a reason
why NFKC was chosen rather than NFKD, by the way? I would have
thought that NFKD would be computationally simpler -- even though
the normalised strings are larger -- and I don't see how there
could be any difference in the equivalence classes generated.)

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Wed, 10 Nov 2004 20:28:49 -0500

>so why isn't this cause for a significant redesign ? 

Well, as I noted to Hallvard, how much redesign would be
needed depends on the particular matching semantics we're
trying to provide.  I heard that some want:
        LDAPprep("") != LDAPprep(X) for all X != ""

Others seem to want:
        LDAPprep("") == LDAPprep(" ")

others may want something else.

My comment about "significant redesign" was based in part
on what I though folks were wanting.  But beyond that, I
note that regardless of what different behavior we might
want from the current behavior, significant additional
engineering would likely be required to produce that
behavior.  Simply tweaking a step can have a number of
non-desirable side effects.  It's not something I want
to do without very good reason.

Kurt

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Wed, 10 Nov 2004 20:38:30 -0500

>same for every string component of every ASN.1 type. 

Understood.

It would have been nice if IA5String would not have been
used directly in RFC 1274, but instead something like:
        CosineIA5String ::= IA5String SIZE (1..max)
but it didn't.

Kurt

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Wed, 10 Nov 2004 21:16:59 -0500

>Any particular technical reason why ?

Stringprep algorithms are idempotent by design.  Though
we've added two additional steps, these steps should
ensure that this property is maintained.

In absence of idempotence, one could have caseExactMatch(X, Y)
evaluate to FALSE even though Y is the string LDAPprep(X).

Also, without idempotence implementations would have to be
very careful in what they did without output values.

There are likely some security considerations here as well.

>input to LDAPprep is permitted to be a zero-length string.

No.  Because one of the key aspects of being idempotent is
that every possible out be a valid per the syntax of the
input.

Now, if LDAPprep(x) == "" only for x == "", then LDAPprep
would be truly idempotent.  However, this implies that
LDAPprep("") != LDAPprep(" ").

---

From: Steven Legg <[email-masked]>
Date: Thu, 11 Nov 2004 16:18:51 +1100

Kurt,

> There are likely some security considerations here as well.

Okay, idempotency is a good thing.

> that every possible out be a valid per the syntax of the

But if the input is permitted to be a zero length string and the output
is potentially a zero-length string then isn't every possible output a
valid input ?

You seem to be conceptually linking the syntax of the output of LDAPprep
with the syntax of the attribute value that provided the input. That doesn't
need to be the case.

> would be truly idempotent.

There's no "only" about it. LDAPprep is still idempotent for any x != ""
where LDAPprep(x) == "". For example, assuming empty output and input strings
are allowed and no internal steps are replacing empty strings with " ",
LDAPprep("   ") == "" == LDAPprep(LDAPprep("   ")).

 > However, this implies that

No longer true without the "only".

Regards,
Steven

---

From: Michael Ströder <[email-masked]>
Date: Thu, 11 Nov 2004 08:48:20 +0100

Leif,

> classes are you friend. Orthagonal design is good.

Note that for security reasons it might not appropriate in some cases to 
give someone or a process write access to the multi-valued object class 
attribute. Therefore it is not always possible to indicate the presence 
of a feature by presence of an auxiliary object class.

But maybe I misunderstood you...

Ciao, Michael.

---

From: Leif Johansson <[email-masked]>
Date: Thu, 11 Nov 2004 15:28:34 +0100

> But maybe I misunderstood you...

Read and write access is independent!

	MVH leifj

---

From: Hallvard B Furuseth <[email-masked]>
Date: Thu, 11 Nov 2004 15:51:33 +0100

I'm not sure which situation you are thinking of, but I hope it isn't
ours.

>>> classes are you friend. Orthagonal design is good.

That would give us 11 or so object classes, one for each optional
feature in the mail system, just so we could use LDAP to store mail
information.  Most mail objects would need at least 5-6 object classes.
*Not* good.  I haven't seen many schemas that follow that philosophy
either.

> Read and write access is independent!

If a user wants to add a vacation message which requires that he also
adds an object class, he must have write access to add that object
class.  He might not have write access to modify all of his own entry.
One could of course make the attribute optional in the object class and
add it to all entries, but then the presence of the object class can't
be used as a 'send a vacation message' flag.
(Not our situation; our LDAP directory is read-only for the users.  But
I expect that's what Michael refers to.)

-- 
Hallvard

---

From: Hallvard B Furuseth <[email-masked]>
Date: Thu, 11 Nov 2004 16:18:34 +0100

> same for every string component of every ASN.1 type.

Can that be explained briefly, or can you suggest some parts of rfc3687
to read to see what's going on?  I'd rather not read 42 pages of RFC
just to follow this thread.

At the moment I'm kind of hoping I've misunderstood you completely -
currently I'm wondering: (No need to reply to the following if the
explanation is just that I misunderstand:-)

Why should an empty string be treated as a valid Directory String,
instead of having the comparison return Undefined or an error?

More generally, if one can pass any string to any matching rule
regardless of the expected syntax (is that assertion syntax or attribute
syntax?), why should e.g. numericStringMatch("xx123", "123") be treated
as anything sensible, with a defined result?

Are IA5 String, Printable String and Numeric String defined in terms of
an 8-bit encoding (e.g. UTF-8) in ASN.1?  Otherwise, when using
caseIgnoreIA5Match, numericStringMatch or telephoneNumberMatch to
compare an attribute component with an 8-bit assertion value, which
character encoding is that assertion value presumed to use?  (I expect
the attribute component's syntax provides the component's character
encoding.)

-- 
Hallvard

---

From: Leif Johansson <[email-masked]>
Date: Thu, 11 Nov 2004 17:17:58 +0100

> *Not* good.  I haven't seen many schemas that follow that philosophy

Not only is it good schema design it is based on good OO design
principles: Use interfaces (which is exactly what an aux object class
is) and in the case of LDAP polymorphism to expose specific features
to applications.

I don't believe you can show me a deployed schema which actually relies
on empty IA5Strings. In fact as I have noted elsewhere in this thread
most client libraries could not distinguish empty strings from an absent
attribute-value.

> class.  He might not have write access to modify all of his own entry.

Value-based ACL:s are supportet in many implementations. Give the user
right to add the specific object class value.

In any case I believe that your example fails to clearly show that 0-
length IAString values are ok where 0-length DirectoryStrings are not.

I.e if I were to accept your example as an argument I could construct
another example based on an attribute which required the DirectoryString
syntax (some form of a name for instance) but which, because of the
size-restrictions on DirectoryString, would not be a valid schema.

To convince me you need to construct an example which does not make
sense when the syntax is a DirectoryString! I dare you to come up with
that :-)

	MVH leifj

---

From: Steven Legg <[email-masked]>
Date: Fri, 12 Nov 2004 12:50:22 +1100

Hallvard,

> just to follow this thread.

Suppose that there is an attribute whose syntax is described by the
following ASN.1 type:

     SEQUENCE {
         description   UTF8String,
         parameters    Parameters
     }

It is possible through component matching to apply the caseIgnoreMatch
matching rule to just the description component of attribute values of this
syntax. The description component has no size constraint so it is permitted
to be zero-length as far as ASN.1 is concerned. That means caseIgnoreMatch
potentially has zero-length strings as input.

> instead of having the comparison return Undefined or an error?

An empty string is always illegal for a DirectoryString, but X.520 allows
caseIgnoreMatch, etc, to be applied to UTF8String (among other things) and
makes no condition about any size constraints on the UTF8String. One could
legally define an attribute whose syntax is just UTF8String without a size
constraint and use caseIgnoreMatch as its equality matching rule.
Component matching just generalizes that by allowing matching rules to
be applied to component parts of attribute values.

> syntax?),

Both. The inputs to matching rules can be an attribute value and an
assertion value, or two attribute values.

 > why should e.g. numericStringMatch("xx123", "123") be treated

It shouldn't. numericStringMatch is applied to NumericString values and
"xx123" isn't a legal value of NumericString. However numericStringMatch
is permitted by X.520 as the equality matching for an attribute with an
unconstrained NumericString as the syntax. In principle, numericStringMatch
could be applied to attribute values of zero-length.

> an 8-bit encoding (e.g. UTF-8) in ASN.1?

X.680 makes no assumption about the encoding of these character sets.
That is left to the definitions of the encoding rules. For the BER family
and the LDAP-specific encodings they are 8-bit encodings. In PER they could
be 8-bits or less. In GSER they are UTF-8, which amounts to the same thing as
8-bit. For RXER and XER they are any character encoding permitted by XML -
typically UTF-8 or UTF-16. The matching rule descriptions in the syntaxes
draft avoid tying the semantics to any particular character encoding.

 > Otherwise, when using

The assertion value arrives in the character encoding determined by
the protocol operation that carried it.

Regards,
Steven

---

From: Leif Johansson <[email-masked]>
Date: Fri, 12 Nov 2004 15:20:00 +0100

> 
> You must be disappointed with a lot of schemas out there, then.  E.g.

Yes.

---

From: Hallvard B Furuseth <[email-masked]>
Date: Fri, 12 Nov 2004 15:16:40 +0100

You must be disappointed with a lot of schemas out there, then.  E.g.
rfc2256 which has things like searchGuide, userPassword and seeAlso in
several structural classes instead of in an aux class, and it mixes
org/person names with locations with contact info, etc.

Anyway, which application_s_?  There are maybe three applications
involved: The mail system, the user interface to change one's own mail
settings, and the IMAP servers used to read mail - and they are all
configured or programmed to rely on the same schema.

> I don't believe you can show me a deployed schema which actually
> relies on empty IA5Strings.

I renamed this subthread because it no longer has anyting to do with
empty strings, only with schema design and whether to use an boolean
attribute vs. an object class.  But I can rename it back; see next
message.

-- 
Hallvard

---

From: Hallvard B Furuseth <[email-masked]>
Date: Fri, 12 Nov 2004 17:23:43 +0100

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:
> 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

---

From: John McMeeking <[email-masked]>
Date: Fri, 12 Nov 2004 11:29:39 -0600

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 <[email-masked]> wrote on 11/12/2004 10:23:43

---

From: Leif Johansson <[email-masked]>
Date: Sun, 14 Nov 2004 20:51:28 +0100

> If it makes you feel any better...

So my summary of this thread is (please correct me if I am wrong): There
doesn't seem to be interoperability around the use of empty IA5 strings.

If you agree on that there is only one way to proceed: disallow the use
of empty IA5 strings. We had a similar discussion about ;binary some
time ago with a similar outcome.

This is the ldapbis-wg. The purpouse of this group is to shepheard
ldapv3 to draft standard.

	MVH leifj