[Date Prev][Date Next] [Chronological] [Thread] [Top]

Re: Empty IA5String




Kurt,

Kurt D. Zeilenga wrote:
At 06:40 PM 11/10/2004, Steven Legg wrote:


Kurt,

Kurt D. Zeilenga wrote:

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


Kurt,

Kurt D. Zeilenga wrote:


At 07:26 PM 11/9/2004, Steven Legg wrote:



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.

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.

No, I believe that LDAPprep should be able to output a zero-length string given a non-zero-length input string.

I disagree. I believe it LDAPprep must be idempotent.

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.

Okay, idempotency is a good thing.



That is,
      LDAPprep(LDAPprep(x)) = LDAPprep(x)
be true for all X.

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.


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

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.


Now, if LDAPprep(x) == "" only for x == "", then LDAPprep 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
LDAPprep("") != LDAPprep(" ").

No longer true without the "only".

Regards,
Steven





Regards,
Steven


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.

Not enough to ensure idempotence.


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.



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.

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

Not enough to ensure idempotence.



Regards,
Steven