Re: [I18ndir] I-D on filesystem I18N

[Asmus Freytag <[e-mail]>]

On 7/7/2020 11:06 PM, Nico Williams wrote:
> On Wed, Jul 08, 2020 at 01:36:35AM -0400, John C Klensin wrote:
>> I also think that a certain amount of respect is due to
>> established protocols that have gotten IETF consensus and broad
>> deployment.  That does not mean they can't be changed.  It does
>> not mean they are not wrong-headed either.  But it seems to me
>> that "I have an idea that I think is better" is not sufficient
> That is denigrating and completely unnecessary.  I'm not saying "I have
> an idea that I think is better".  I'm saying that the RUNNING CODE
> differs from the damned spec.
>
> Now, you can you not give a damn and let the spec and running code
> continue to differ.  Fine.  But why even bother updating the spec at all
> then?  Who cares what it says if no one bothers to implement it as
> written?
>
> We're about rough consensus, yes, but also running code damn it.
>
> You can write fiction if you like, but I'm for writing specs that
> reflect reality and have a chance in hell of improving reality.
>
> Nico

This is an interesting discussion and brings to mind two examples that 
are not IETF standards. One is HTML5 where people got tired about 
unsupported and inconsistently supported features of HTML and are giving 
the RUNNING CODE a much greater weight - even when moving forward. To 
the point that some are dissatisfied that implementations are driving 
the specification. (There are millions of details here that I don't care 
to tease apart here, I'm after a very rough analogy for the purpose of 
this discussion.)

The other is the early Unicode. Which was an absolute departure from 
existing character encodings and a bit of a clean break. As conceived 
initially, it would require a rewrite of all code, with (lossy) mapping 
to legacy encodings (but basically loss-less round trip ones) as the 
only means of interacting. Here, the inadequacies of the existing 
non-solution (character set independence) was so overwhelming that there 
was a critical mass of implementations that lined up behind the new, 
incompatible scheme.

Until someone invented the "universal adapter plate" in the form of 
UTF-8, which neatly allowed Unicode to co-exist in most character set 
independent environments and, without rewriting that code, to become 
dominant. (In doing so, they "fixed" a number of shortcomings of 
existing multi-byte encodings, not least of which are stateless and 
self-synchronizing nature of the mapping from UTF-8 to Unicode characters).

Crucially, the UTF-8 adaptation brings all the other elements of the 
Unicode departure from existing character set encodings, to wit, a fixed 
set of character properties and behaviors (such as renderings) that come 
into force any time a system treats UTF-8 as Unicode (instead of 
pass-through bytes).

Later Unicode had it's share of "fiction"; good ideas that remained 
that, like "paragraph separator" and "line separator" characters, or 
language tag characters. Some were later deprecated, which is good, some 
repurposed (for emoji flag sequences).

But Unicode also always allowed the definition of "what is a character?" 
to be broad enough to track "de-facto characters" that were defined and 
used in competing standards (compatibility characters, but also emoji 
and many other sets). And by absorbing these, preventing competing 
standards based on competing ideas of character-hood.

Now, as rough as these examples are (and I'm not suggesting we refine 
them), they indicate to me that it's not always possible to define 
a-priori what course is the best one to take. A clean break that 
requires new code to fix something may be the right answer if the 
problem is bad enough and the fix enables new capabilities.

In other cases, if a "good idea" leads to issues with interoperability 
so that nobody can rely on it, because either RUNNING CODE can't be 
changed, or the code that could adapt lacks critical mass, or 
implementers don't see the cost/benefit of change then it's a bad idea - 
even if it's been on paper for a long time. Sometimes "breaking the 
spec" to make it better match what's on the ground is the wiser approach 
(like Unicode's occasional deprecation of characters).

Trying to argue this in the abstract isn't going to resolve this issue. 
Each case has to be looked at based on its merits and the full details 
of the situation. And, like UTF-8, never count out the possibility that 
someone figures out the universal adapter plate.

A./