Subject: [precis] some open issues

From: Peter Saint-Andre <[email-masked]>
Date: Mon, 05 Mar 2012 09:34:31 -0700

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/

---

From: Andrew Sullivan <[email-masked]>
Date: Mon, 5 Mar 2012 12:11:57 -0500

Hi Peter,

> case, nor does it provide guidelines or mechanisms for doing so.

This came up more than once in discussion, however, so I presume
people still think it's important.

> the framework document does not provide guidelines or mechanisms for

Some of the reviews indicated that there are existing stringprep
profiles in use that map to nothing.  If we're going to say that this
is deprecated, we need to state it outright.

> and never included a blob-class of some sort. Do we need to bring these

The working copy text that Marc and I are working on has DomainClass,
NameClass, and FreeClass in it.  NameClass is defined to be like
IDNA2008, which means that framework shouldn't have it.  The other two
are in framework-01 (I just checked).

> (and thus not need PRECIS-based comparison rules)?

We concluded previously that we did not need it.

Best,

A

-- 
Andrew Sullivan
[email-masked]

---

From: Joe Hildebrand <[email-masked]>
Date: Mon, 05 Mar 2012 10:41:02 -0700

> case, nor does it provide guidelines or mechanisms for doing so.

Suggestion: if the protocol is going to preserve case, the registrar for
that identifier SHOULD NOT allow registration of two identifiers that case
fold to the same thing (deliberate hand-wave over how you compare the
case-folded versions).

-- 
Joe Hildebrand

---

From: Peter Saint-Andre <[email-masked]>
Date: Wed, 07 Mar 2012 13:30:57 -0700

> fold to the same thing (deliberate hand-wave over how you compare the

Yes, taking "registrar" broadly (e.g., an IM service that enables you to
create accounts is functioning as a registrar).

Peter

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

---

From: Peter Saint-Andre <[email-masked]>
Date: Wed, 07 Mar 2012 13:55:05 -0700

> people still think it's important.

Right. The question is whether we need a way to signal that somehow
(ick) or whether, as Joe says, we can leave it up to entities which
function as "registrars" in a given application protocol.

> is deprecated, we need to state it outright.

I looked at this when working on the SASLprepbis spec with Alexey. The
text there currently says:

   2.  (MAPPING 2) Characters from the "M" category defined under
       Section 6.13 MUST be mapped to nothing (this category includes
       all of the "characters commonly mapped to nothing" from Appendix
       B.1 of [STRINGPREP]), except U+1806 MONGOLIAN TODO SOFT HYPHEN).

Instead of handling this via mapping, we could say that the "M" category
is DISALLOWED for that profile. That seems more in line with the Tao of
PRECIS. (Can we be said to have a Tao yet?)

> IDNA2008, which means that framework shouldn't have it. 

I assume you mean "DomainClass" in the second sentence.

> The other two

Yes.

> We concluded previously that we did not need it.

And I agree with that conclusion.

Peter

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

---

From: Joe Hildebrand <[email-masked]>
Date: Wed, 07 Mar 2012 13:57:23 -0700

> create accounts is functioning as a registrar).

That was my intent, "registrar" being the entity that controls allocation
for a given set of identifiers.

-- 
Joe Hildebrand

---

From: Andrew Sullivan <[email-masked]>
Date: Wed, 7 Mar 2012 16:00:25 -0500

> function as "registrars" in a given application protocol.

Well, the reason for it is, I guess, obvious; but in case anyone
hasn't been following: a lot of protocols have the idea of
case-insensitive matching.  This is trivial in ASCII and at least hard
in everything else.  If case is never preserved, then we don't have to
worry about it.  If case is preserved but also relevant for matching,
then we don't actually need to worry about it either.  But if case is
preserved but matching is supposed to be case-insensitive, then
everything hurts.  I'm ok with punting this to the individual
protocols, but I think at the very least we need to explain in some
detail why they need to make a decision (and maybe suggest what it
ought to be).

> PRECIS. (Can we be said to have a Tao yet?)

That's certainly what IDNA2008 did, and I'm not opposed.

> I assume you mean "DomainClass" in the second sentence.

Yes, sorry.

A

-- 
Andrew Sullivan
[email-masked]

---

From: Peter Saint-Andre <[email-masked]>
Date: Wed, 07 Mar 2012 14:01:04 -0700

On 3/5/12 9:34 AM, Peter Saint-Andre wrote:

Replying to myself on the topics Andrew and Joe didn't mention...

> show folks how it's done).

Now that I think about it some more, I think we do need FreeClass, which
other specs will then profile. See for instance Section 3 of
draft-melnikov-precis-saslprepbis and draft-saintandre-precis-nickname.

> Perhaps we need to provide stronger guidelines here.

Looking at the framework document again, I'm reminded that we prefer NFC
because that's what RFC 5198 recommends. However, there still might be
profiles that would prefer NFKC -- e.g., that's what I did in the 00
version of draft-saintandre-precis-nickname because it seemed
appropriate there to reduce the possibility of confusion.

Peter

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

---

From: Peter Saint-Andre <[email-masked]>
Date: Wed, 07 Mar 2012 14:15:10 -0700

> detail why they need to make a decision (and maybe suggest what it

Yes, that seems quite reasonable.

Peter

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