RFC5895 and UTS46 ?

[John C Klensin]

--On Monday, October 25, 2010 17:39 -0600 Peter Saint-Andre
<stpeter at stpeter.im> wrote:

> On 10/25/10 5:26 PM, =JeffH wrote:
>> Are RFC5895 and UTS46 mutually-exclusive? I.e. one should
>> adhere to one or the other, but not "mix" the two? Or the
>> converse?
> 
> First of all, neither of these is officially part of IDNA.
> 
> However, as I understand it, they are two ways of doing the
> same thing, so use one or the other but not both.

FWIW, if "officially" means "normative parts of the Standard",
yes.  And yes.

I would suggest that they are philosophically somewhat different
in addition to being "two ways of doing the same thing".  At the
risk of getting myself in trouble and with the understanding
that I had very little to do with the development of either
document, 5895 is a specification of a mapping model going
forward and suitable for use in new kinds of applications as
well as older ones.  UTS46 is more concerned with backwards
compatibility and comes down squarely on one side of an old
philosophical argument in  the IETF (and standards development
processes more generally).  In the case of IDNA, that argument
can be seen as being about whether, how, and how long one should
try to support, or make concessions to, a practice the community
has decided is undesirable despite the observations that it
occurs in the wild and that some people are dependent on it.   

Someone who believes that the practice, even if it violates the
earlier standards or associated guidelines, has to be supported
forever, would take one position on that.  Others might be
inclined to say that an undesirable practice is an undesirable
practice and that it is in the interest of the community to stop
such practices as quickly and unambiguously as possible, even by
making things that used to work suddenly stop working.   Most
sensible people find positions somewhere in between those
extremes, but there are lots of positions in between the
extremes and hence lots of room for disagreement about what
should be done.

     john