Re: [I18ndir] Writing direction

Patrik Fältström <patrik@frobbit.se> Wed, 18 May 2022 04:58 UTC

Return-Path: <patrik@frobbit.se>
X-Original-To: i18ndir@ietfa.amsl.com
Delivered-To: i18ndir@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C1DD4C15EB2A; Tue, 17 May 2022 21:58:03 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.096
X-Spam-Level:
X-Spam-Status: No, score=-7.096 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=frobbit.se
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id n2zqFhtvHQRp; Tue, 17 May 2022 21:58:00 -0700 (PDT)
Received: from mail.frobbit.se (mail.frobbit.se [85.30.129.176]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 82050C15E6DC; Tue, 17 May 2022 21:57:59 -0700 (PDT)
Received: from [192.168.131.24] (h-155-4-15-233.A163.priv.bahnhof.se [155.4.15.233]) by mail.frobbit.se (Postfix) with ESMTPSA id 5AE06216AE; Wed, 18 May 2022 06:57:56 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=frobbit.se; s=mail; t=1652849876; bh=itrgciY5KcvlCNVdfNlbBh9H02v1epDj+Mfs3mtpuTA=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=isEyH6H0x9W0PQcHkMAjAL8WKwgK2LOndH/nRLjzN5TYc3LdzMONA5tRJvGPs8UFW Ce6Ya8FTJvoDZe3/LvO9OJ9hGnrA1/e0wkz9ePMjx8/LZsiLufxG+yUv2g6UJ1R5Mm lr5WniHwD7ozAfuvB7kLue0aQRdc18o9DFpvf/io=
From: Patrik Fältström <patrik@frobbit.se>
To: John C Klensin <john-ietf@jck.com>
Cc: i18ndir@ietf.org, art-ads@ietf.org
Date: Wed, 18 May 2022 06:57:55 +0200
X-Mailer: MailMate (1.14r5895)
Message-ID: <CA6F6D68-D83F-46CC-B949-218915ACD116@frobbit.se>
In-Reply-To: <F3072E6B0F1EF9E2951E4D3D@PSB>
References: <4C4A249559BA1E86B17E53FE@PSB> <D59F50F7-A266-48F3-AA78-DA46023033BD@frobbit.se> <39F2CBAA1F19DB765CC59369@PSB> <F6E64852-5CA0-432C-90D3-9DA7D3CCCE69@frobbit.se> <F3072E6B0F1EF9E2951E4D3D@PSB>
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="=_MailMate_35D703B4-A412-4376-A6F0-3C54AF7054A3_="; micalg="pgp-sha512"; protocol="application/pgp-signature"
Archived-At: <https://mailarchive.ietf.org/arch/msg/i18ndir/jvp1veZUoPS8Mz3mg7hkBBNnaUE>
Subject: Re: [I18ndir] Writing direction
X-BeenThere: i18ndir@ietf.org
X-Mailman-Version: 2.1.34
Precedence: list
List-Id: Internationalization Directorate <i18ndir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/i18ndir>, <mailto:i18ndir-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/i18ndir/>
List-Post: <mailto:i18ndir@ietf.org>
List-Help: <mailto:i18ndir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/i18ndir>, <mailto:i18ndir-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 18 May 2022 04:58:03 -0000

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