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/ _______________________________________________ precis mailing list [email protected] https://www.ietf.org/mailman/listinfo/precis
