Hangul jamo issues

[Simon Josefsson]

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
> reducing potential confusion in identifier matching is generally
> A Good Thing.  So I don't think that pointing out what is done
> in a writing system is, by itself, justification for arguing for
> more inclusion in Stringprep.   Second, while we have been
> assuming that IDNA200x and SASLprep200x will use essentially the
> same profile of Stringprep, that is not a hard requirement: if
> the needs are different and the differences are important (and
> we can explain why), then we might end up with different
> profiles.

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.

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.

/Simon