Re: [I18ndir] Writing direction

[Asmus Freytag <[e-mail]>]

On 5/17/2022 9:57 PM, Patrik Fältström wrote:
> On 18 May 2022, at 0:23, John C Klensin wrote:
>
>> But there is barely any place to put language and no place to put direction. What do you suggest we do?" Probably we need to try to answer the question and, at least so far, a directionality extension to the BCP47 code system is the least horrible possible answer I've been able to come up with, the need to climb in and have a close encounter with those rats
>>
>> notwithstanding.
> Ok, obviously without knowing the complete context here I would say that first of all the big problem is mixing protocol parameters with display. I call this "leakage". We see this in DNS where a domain name is visible to the user. We see it in other parts of a URI, an email address etc. Oh, email address is a perfect example. It does have a "free text" name, and then an address. But many people want to use their name as an email address which leads to collisions and other things. This while applications that only show the name have similar security risks like text that is a link that people click on might have a destination that is not what the end user guesses or believes.
>
> To the "free text".
>
> To me there are two issues here:
>
> 1. Display is very important to the end user. We have the context within which the sender of the text has, and the context of the receiver of the text. If a text is to be displayed we even without talking about general directionality (that do impact rendering) we have the issue of mixing two contexts. Even if I have some clue about i18n I have very to no knowledge about the same text, same script, same language is possible to display with different directionality. I believe some asian scripts can do this, and for example hebrew. So the first question is what problem is to be solved. I guess it is "to have the receiver understand what general directionality the sender of the text decides". The receiver can then display in whatever directionality context the sender wants.
>
> 2. Second question is whether general directionality is a degree of freedom that is really needed in this protocol. I think it is really really really important to agree this *is* important. And I mean that it is much more important than deciding that "the free text in this protocol has a directionality context that is R2L", or L2R for that matter. I.e. that this protocol element (because it is a protocol element after all, even if the element contains "free text"). If the string is short, I claim one can create a string with the help of directionality is like if the general directionality was the opposite of what the general directionality is.
>
> 3. If the answer to the second question is that one can absolutely not have a given directionality, I still think one should not give up. One can still say that "the directionality of the free text element is R2L", with the addition "if the free text element is to be a L2R context, then the first character of the element MUST be U+2066 "Left-To-Right Isolate".
>
> 4. If 3 is too ugly, then I do not see any other solution than to also have a protocol parameter instead of embedding the directionality in the first character in the free text protocol element, be a separate protocol element.
>
> You can not both throw away the butter, eat the cookie and have coffee.
>
>     Patrik
>
Patrik,

embedding bidi controls into protocol text data is ugly, because they 
end up, sooner or later, embedded in the plain-text backbone of an HTML 
page. (I'm sure that's a law that's already named by someone out there).

It's better to have out of band information to allow the consumer to 
either add controls or markup when embedding text, depending on the 
destination (and depending, even, on whether the destination's 
directionality matches or disagrees).

Unlike all the other presentational markup that exists to affect 
text-layout, the bidi direction is special in that it affects things 
like the order of first and last name or any other elements where "order 
in the sentence" affects the meaning (and not just the appearance) of 
the text.

Mixed Hebrew and English written LTR is effectively a different "writing 
system" from mixed Hebrew and English written RTL. It is this "writing 
system" aspect that might have a place in a language tag.

The fact that the difference 'only' shows up when displaying text to the 
user is not as strong an argument about it being presentational as one 
might think. A user can compare two strings, one presented horizontally, 
and one vertically without ambiguity. A user cannot compare two strings 
with unknown directionality settings and know that they are 
unambiguously equal. Only a computer with access to the backing store 
can do that.

What are the types of texts that show up in IETF protocols?

If there are only identifiers and no items like the typical metadata 
fields, then, yes, I don't see the use case. However, even for short 
"free-text" metadata items I can see issues with imputing directionality 
from either the code points themselves or the default direction of a 
language.

A./