On Wed, Dec 31, 2014 at 08:54:00AM +0100, Patrik Fältström wrote:
What I think is then needed is for this case:
1. A simple explanation what you really is talking about
What is the requirement on whom regarding normalization/mapping/whatever?
The I-D in question defines a URI scheme for PKCS#11 resources some of
whose naming attributes are character strings which PKCS#11 says should
be UTF-8. PKCS#11 (*not* an Internet standard) does not say anything
about form. Should this I-D say anything about form?
IMO the most it should say is "PKCS#11 doesn't specify a canonical form
for these labels, therefore the application may need to canonicalize
prior to comparing them". The alternative is to say nothing.
PKCS#11 is an API. PKCS#11 apps might "interoperate" using PKCS#11 URIs
communicated over, e.g., IPC (or plain old cut-n-paste).
PKC#11 URI _templates_ might well be exchanged far and wide, but still
not really as a part of a network protocol.
The tricky part regarding choice of normalization (together with
selection of code points allowed) is of course whether false positives
or false negatives is the most troublesome event when trying to do
matching.
This can be true even if we say nothing.
Let me just be clear here, I am very much in favor of specifications
that say that "server side matching" should NOT do normalization, as
that give most freedom for the applications that use whatever
Where this works for filesystems, it is by accident: because input
methods "agree" on a canonical form for inputs.
As you know it actually doesn't work that well for filesystems:
"clients" (e.g., a program using a POSIX open() function) don't do
anything about normalization. Neither do C library/run-time system call
stubs. Neither do kernels. Neither do <pick networked fs protocol>
clients. They just don't. Why would they? These systems have lineages
much older than Unicode.
For IDNA, of course, the DNS client application has to canonicalize.
IOW, what to do depends on the application. For filesystems I say: be
form-preserving-form-insensitive. For IDNA there's no choice but to go
with clients-must-normalize. Each app will be different.
mechanism is defined. But, that to me set requirements on "client
side" to do the right thing (for example like in IDNA2008 only be
allowed to use certain code points).
So, given your choice on server side matching, what are the
requirements on client side?
There's no network protocol here. There's an API and applications
interoperating over IPC ("cut-n-paste").
Of course, the issues are the same, it's just that there's no "server"
to consider. It's all as good as "clients". Unlike IDNA, it's all
UTF-8, all the time, so that form-insensitive can work.
Nico
--