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