Re: [precis] some open issues

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

On 3/5/12 10:11 AM, Andrew Sullivan wrote:
> Hi Peter,
> 
> On Mon, Mar 05, 2012 at 09:34:31AM -0700, Peter Saint-Andre wrote:
>> 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.
> 
> This came up more than once in discussion, however, so I presume
> 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.

>> 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.
> 
> 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.

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?)

>> 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?
> 
> 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. 

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

> The other two
> are in framework-01 (I just checked).

Yes.

>> 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)?
> 
> We concluded previously that we did not need it.

And I agree with that conclusion.

Peter

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