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

Re: Empty IA5String



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.

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

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



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