Re: [precis] some open issues

[Andrew Sullivan <[e-mail]>]

On Wed, Mar 07, 2012 at 01:55:05PM -0700, Peter Saint-Andre wrote:

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

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

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

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

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

Yes, sorry.

A


-- 
Andrew Sullivan
[e-mail]