Hangul jamo issues

[John C Klensin]

--On Wednesday, 03 January, 2007 10:22 +0100 Simon Josefsson
<simon at josefsson.org> wrote:

> John C Klensin <klensin at jck.com> writes:
> 
>>> Moreover, future Stringprep200x is not only for IDNAbis, but
>>> also for other applications like SASL. We need more inclusive
>>> Stringprep200x. 
>> 
>> Some parsimony in naming might benefit SASLprep (and other
>> Stringprep profiles).  Some of the issues are the same and the
>> same as (at least) the philosophy of the UTC "secure
>> identifiers" concept: the ability to write a word or string in
>> the relevant language does not make it a good identifier and
>>...

> There is one assumption that is often made in IDNA discussion,
> and that is that IDNA strings are assumed to contain "natural
> language", or put differently, that strings that you would
> never find in a newspaper or spoken by a human, are not worth
> consideration.

Actually, based on experience, that assumption is not a
particularly good one for IDNA either.  If the domain name
assumption were stated carefully, it would probably be that it
is desirable to accommodate natural language strings where
possible, but that many DNS names will not actually meet natural
language constraints.

However...

> That assumption doesn't hold for passwords.  The more entropy
> you can put into a password, the better.  Picking a password
> that, for some reason, never would have been part of a
> dictionary or printed in a newspaper is a _good_ idea.
 
> This is one case where I think the design goals of StringPrep
> and SASLPrep are different.  If this issue is not taken into
> consideration in the StringPrep200x design, I think SASLPrep
> will ultimately have to be forked and have a separate design.
> That would be unfortunate, since much of the work is
> duplicated.  It seems better if StringPrep allowed this, and
> when desired, the upper-level IDNA architecture disallow such
> strings.  Then SASLPrep200x may use StringPrep200x.

Strongly agree.

      john