Re: Re: Unicode categories

John C Klensin wrote:
>>From the standpoint of the IETF, or anyone else worried about a
> piece of protocol that must support many applications, the
> problem is a little different.  Some of the recent developments
> in automatic updating tools notwithstanding, IDNA (and its
> supporting tables) are designed to be embedded in and used from
> clients.  Many of those clients, and the associated operating
> systems, have been historically updated only when the machine in
> which they run is replaced.   That argues for an extremely
> conservative view of protocol design and compatibility, with
> very high thresholds for justifying incompatible changes of any
> sort.  From that viewpoint, the differences between 0.01%
> changes and 5% changes is like measures of being partially
> pregnant: perhaps helpful in some types of risk assessment, but
> less so in making the next design decision.  

While the facts are all true (clients only updated rarely, and
protocol stability being important), I somewhat disagree with the
conclusion. Design decisions need to take all these things into
account, but on a factual basis, not a moral one. E.g. if a protocol
change is known to potentially break existing clients, but the
number of actual clients being broken is also known to be small,
the protocol change might still be acceptable. Likewise if the
impact of "breakage" would be "small".

In the context of IDNA, I would conclude that upgrading to a
newer Unicode version in IDNA would do no significant harm, even
if it is, strictly speaking, an incompatible protocol change.
Existing clients must be considered, but in doing so, the effects
of a proposed change to such clients must also be considered -
not in a theoretical way, but trying the changes on a real
existing client. For IDNA, it seems likely that the existing
clients would not change in any user-visible way, and that
the behaviour change in artificial cases should be considered
acceptable.

That said, I also believe that upgrading to a newer Unicode
version would do little good. Additional characters are likely
of little use to the broad masses, as font support etc. is still
lacking. If certain new characters are of high interest to IDNA
users, I expect registrars to weaken the "AllowUnassigned"
setting of "false" to, say, "AllowUnassignedAsPerLatestUnicodeSpec" -
independent of what any RFC says.

Regards,
Martin