Prohibiting mapping of PVALID characters

[Kenneth Whistler]

> > Depending on local needs, this conversion may involve coding
> > conversions. The conversion may also involve mapping some
> > characters; however, such mapping MUST NOT be applied to any
> > character that has a type of PVALID, regardless of the local
> > needs.
> > 
> > The problem with this is that it makes a MUST-level
> > requirement that is begging to be broken ("our needs for
> > mapping are greater than our needs for conformance to the
> > RFC"). But it might be the best we can do.

The other problem with this is that it might cause implementers'
heads to explode when they realize that normalization to NFC
is required (MUST), and normalization is also a character
mapping, and as a matter of course maps some PVALID characters
to other PVALID characters: <a, combining-acute> ==> <a-acute>, 
etc.

So unless the protocol document defines "mapping" somehow
more restrictively to mean "the kinds of mappings we don't
want in the protocol, i.e., case mappings, *compatibility*
normalization mappings, etc., as opposed to the kinds
of mappings we *require* in the protocol, i.e. *canonical*
normalization mappings", I see this as just introducing
more potential for confusion in the protocol statement.

> 
> Yes, that is probably the right place and just about the right
> text (assuming the WG wants to do anything at all).   The reason
> why I suggested SHOULD was to avoid making a MUST-level
> requirement that, as you put it, is begging to be broken.  But
> MUST may still be the best answer, if only because SHOULD would
> probably require an explanation that the WG might have some
> difficulty agreeing on.

And MUST introduces a difficulty in distinguishing why
NFC normalization is good, but all other kinds of mappings
that might impact a PVALID character are bad.

I don't see how introducing this change to the text is
going to help anybody.

--Ken