[precis] some open issues

[Peter Saint-Andre <[e-mail]>]

This morning I reviewed all of the PRECIS-related I-Ds. Here are some
issues that seem open to me.

1. types of identifiers

The problem statement document cites draft-iab-identifier-comparison
regarding types of identifiers (i.e., absolute, definite, and indefinite
identifiers). However, the framework document and the profile documents
do not mention different identifier types.

2. case preservation

The problem statement document mentions the need to specify whether an
application protocol preserves case. However, the framework document
does not require profile documents to specify whether they preserve
case, nor does it provide guidelines or mechanisms for doing so.

3. mapped to nothing

The problem statement document mentions the possibility of mapping
characters to nothing, as was done in some stringprep profiles. However,
the framework document does not provide guidelines or mechanisms for
doing so.

4. string classes

The problem statement document mentions five possible string classes,
corresponding roughly to (a) domain names, (b) usernames, (c) secrets,
(d) protocol strings, and (e) string blobs. Clearly, (a) is covered by
IDNA2008. However, the framework document now covers only (b) via the
NameClass and (d) via the FreeClass, because it removed the SecretClass
and never included a blob-class of some sort. Do we need to bring these
into alignment?

5. blobs

Following up on (4), do we need to define a BlobClass, or would such a
class be an absolute identifier requiring only byte-for-byte comparison
(and thus not need PRECIS-based comparison rules)?

6. FreeClass

The framework document mentions two possible uses of the FreeClass:
passphrases and nicknames. However, one could argue that passphrases
could be handled by the replacement for SASLprep (Alexey and I will
publish version 00 of that I-D today) and one could also argue that
nicknames could be handled by a separate PRECIS profile (see recent
discussion in the SIMPLE WG). This makes me wonder if we really need to
define the FreeClass in the framework document (which then makes me
wonder if we might want to define the NameClass in a separate document,
leaving the framework as truly just the framework itself -- however I do
think it's helpful to define one string class up front so that we can
show folks how it's done).

7. normalization

The problem statement document notes that NFKC might still be
appropriate for some kinds of strings (e.g., because it handles the
width issue for full-width and half-width code points), but we seem to
have assumed that NFC is the right choice unless proved otherwise.
Perhaps we need to provide stronger guidelines here.

I also have some thoughts about the XMPP resourcepart profile, but I'll
post about that on the XMPP WG list.

Peter

-- 
Peter Saint-Andre
https://stpeter.im/