Re: [Xml-sg-cmt] <u> notation - Fwd: AUTH48: RFC-to-be 9290 <draft-ietf-core-problem-details-08> for your review

John R Levine <johnl@taugh.com> Wed, 07 September 2022 07:36 UTC

Return-Path: <johnl@taugh.com>
X-Original-To: xml-sg-cmt@ietfa.amsl.com
Delivered-To: xml-sg-cmt@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9F392C1524D7 for <xml-sg-cmt@ietfa.amsl.com>; Wed, 7 Sep 2022 00:36:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.107
X-Spam-Level:
X-Spam-Status: No, score=-7.107 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_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, 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 (2048-bit key) header.d=iecc.com header.b=S5CXvVhD; dkim=pass (2048-bit key) header.d=taugh.com header.b=1AgnO037
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 Mr1E2hhj1LSZ for <xml-sg-cmt@ietfa.amsl.com>; Wed, 7 Sep 2022 00:36:49 -0700 (PDT)
Received: from gal.iecc.com (gal.iecc.com [IPv6:2001:470:1f07:1126:0:43:6f73:7461]) (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 ABFE8C1524D1 for <xml-sg-cmt@ietf.org>; Wed, 7 Sep 2022 00:36:49 -0700 (PDT)
Received: (qmail 2743 invoked from network); 7 Sep 2022 07:36:46 -0000
DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:references:mime-version:content-type:content-transfer-encoding; s=ab5.63184a0e.k2209; bh=EzBbvGTop9ZCl0IkpmFenUJNxx8dzlKxs6CFEvM6U2I=; b=S5CXvVhDBlOGWkmTQ4diezR8jfIJLjEUHcHYNFSbOiBypfzncNxI/Xf2ivjsS4JxJdFYDiT9OMIhe3YxUx4pH4SZnoHNe5KPGOoUopK/V2oWrLqZ2wvICj2aHwwk6q8epw/UZx5/e2m5qqRIH67E2s9LrmTK+Rahlb5WNZAbbTA46hi89iPu2dkC3BfdD/aK1JApAhba+T18LOgbUAoRbwBI63oSjG43myQVvG1DVrGSAEvkzreiVokrsgre6Mxk2McWDxnb5pKUadYvAkD2Vmi5FMEz0fjAdQ/3Kth9KVGpevY+fjgjCMlkEIHR/c+AEmQWKYn+iq3QzdGJp4nSlA==
DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:cc:subject:in-reply-to:references:mime-version:content-type:content-transfer-encoding; s=ab5.63184a0e.k2209; bh=EzBbvGTop9ZCl0IkpmFenUJNxx8dzlKxs6CFEvM6U2I=; b=1AgnO037oLkzA8IOxLORrOX0zSoO5GGxwFu10Xauvz8tgjxCamcJJ3vz5Am2/IcXFY32YVMpalqF7YzJlV2y5YW6zCTaNdw3p4WivFhMwKIq1RRsr2yAQnS1MMuJmiNS2t7+Dbp28tBdaGNzF8GVW9nik0HvquBFZn3r5oLhxQPif1P/tpIE4CTHDK/37POIpKeE5O2cm16RF2m9fj88dtbWfYxN5AlJ+UVPJslQUqOdPPoWUwAbemcThaX3hctiLqLEP620Qf/FLrH5XrBBBBZBnZ40Cr1S58VrzvEfdZ2hJa1KEK0szCHR9KN6osCAAjm/r2G8+idfQWORLGPS6Q==
Received: from ary.local ([IPv6:2001:470:1f07:1126::78:696d:6170]) by imap.iecc.com ([IPv6:2001:470:1f07:1126::78:696d:6170]) with ESMTPS (TLS1.3 ECDHE-RSA AES-256-GCM AEAD) via TCP6; 07 Sep 2022 07:36:46 -0000
Received: by ary.local (Postfix, from userid 501) id 16F1F49161B6; Wed, 7 Sep 2022 09:36:43 +0200 (CEST)
Received: from localhost (localhost [127.0.0.1]) by ary.local (Postfix) with ESMTP id B29D54916198; Wed, 7 Sep 2022 09:36:43 +0200 (CEST)
Date: Wed, 07 Sep 2022 09:36:43 +0200
Message-ID: <92ab595e-8bf7-03b3-b9ab-528c6326c0eb@taugh.com>
From: John R Levine <johnl@taugh.com>
To: Sandy Ginoza <sginoza@amsl.com>, Peter Saint-Andre <stpeter@stpeter.im>
Cc: xml-sg-cmt@ietf.org, Jay Daley <exec-director@ietf.org>
X-X-Sender: johnl@ary.local
In-Reply-To: <5847681C-8F6D-49E8-9871-7FD7536EF891@amsl.com>
References: <40DB4CD3-2D93-4481-BFB6-7F374A4128B6@tzi.org> <C85FD612-32C6-4CB5-885D-46E96C8AE7A4@amsl.com> <f0ba3eb4-f606-6b65-86fc-c234b12d42a9@stpeter.im> <5847681C-8F6D-49E8-9871-7FD7536EF891@amsl.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="UTF-8"; format="flowed"
Content-Transfer-Encoding: 8bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/xml-sg-cmt/8wLOK6si2YtQzXvsrPmS-6p4e64>
Subject: Re: [Xml-sg-cmt] <u> notation - Fwd: AUTH48: RFC-to-be 9290 <draft-ietf-core-problem-details-08> for your review
X-BeenThere: xml-sg-cmt@ietf.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: Working list for the xml and style guide change management team <xml-sg-cmt.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/xml-sg-cmt>, <mailto:xml-sg-cmt-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/xml-sg-cmt/>
List-Post: <mailto:xml-sg-cmt@ietf.org>
List-Help: <mailto:xml-sg-cmt-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/xml-sg-cmt>, <mailto:xml-sg-cmt-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 07 Sep 2022 07:36:54 -0000

> As always, thanks for your quick reply!  I ended up including the team directly on my reply to Carsten, as we’re unable to get the output he wants.  Perhaps you or others will have other ideas about how to do that.

Hi from France.  I agree with Peter, this will have to do.

One of the topics for the RSWG is expanding the text character set but 
even when we do that, I would want to be careful about RTL text since 
we've seen how confusing it can be.


>> On Sep 6, 2022, at 3:00 PM, Peter Saint-Andre <stpeter@stpeter.im> wrote:
>>
>> This seems fine to me, although the "NEW:" text is not yet in the PDF file (I suppose it will be in your forthcoming update).
>>
>> On 9/6/22 3:50 PM, Sandy Ginoza wrote:
>>> Hi Team,
>>> Please see Carsten's reply below; our understanding is that the display we see of the XML file in emacs is application-specific, and that it's OK to proceed. Please let us know if you believe otherwise.
>>> Please note that there is some urgency here in that I will be posting an updated document today and expect the author approvals to follow quickly.
>>> Thanks,
>>> Sandy
>>>> Begin forwarded message:
>>>>
>>>> *From: *Carsten Bormann <cabo@tzi.org <mailto:cabo@tzi.org>>
>>>> *Subject: **Re: AUTH48: RFC-to-be 9290 <draft-ietf-core-problem-details-08> for your review*
>>>> *Date: *September 1, 2022 at 1:10:09 AM PDT
>>>> *To: *Sandy Ginoza <sginoza@amsl.com <mailto:sginoza@amsl.com>>
>>>> *Cc: *RFC Editor <rfc-editor@rfc-editor.org <mailto:rfc-editor@rfc-editor.org>>, "core-chairs@ietf.org <mailto:core-chairs@ietf.org>" <core-chairs@ietf.org <mailto:core-chairs@ietf.org>>, Thomas Fossati <thomas.fossati@arm.com <mailto:thomas.fossati@arm.com>>, "auth48archive@rfc-editor.org <mailto:auth48archive@rfc-editor.org>" <auth48archive@rfc-editor.org <mailto:auth48archive@rfc-editor.org>>, Jaime Jiménez <jaime@iki.fi <mailto:jaime@iki.fi>>, "core-ads@ietf.org <mailto:core-ads@ietf.org>" <core-ads@ietf.org <mailto:core-ads@ietf.org>>
>>>>
>>>> Hi Sandy,
>>>>
>>>>
>>>>> On 31. Aug 2022, at 23:15, Sandy Ginoza <sginoza@amsl.com <mailto:sginoza@amsl.com>> wrote:
>>>>>
>>>>> Hi Carsten,
>>>>>
>>>>> Note that this is my fault as Megan is on vacation.  I delayed replying while we tested the updated version of xml2rfc to correct the PDF display of the Hebrew string.  It seems the PDF glitch (issue #873) has been fixed - please confirm, as our copy (from PDF) & paste experience is not what we expect.
>>>>>
>>>>> See https://www.rfc-editor.org/authors/rfc9290.pdf <https://www.rfc-editor.org/authors/rfc9290.pdf>
>>>>
>>>> This indeed looks good now.
>>>>
>>>>> Regarding the example from A.3 in the attached screenshot.
>>>>> At this point, 2 questions:
>>>>>
>>>>> 1) Does it seem odd to you that the source file (rfc9290.xml) contains the string in the reverse of how it is rendered in the publication formats? To be exact:
>>>>> The desired string: שָׁלוֹם
>>>>> (which we see in the TXT, HTML, and PDF)
>>>>> The reversed string: םולש
>>>>> (which we see in the sourcecode elements and u element of the XML file)
>>>>
>>>> I’m not sure I’m seeing the same here you do (see screenshot below).  But that is pretty natural in this space...
>>>>
>>>> The HTML (and thus PDF) publication formats pick up the “strong directional” nature of the Hebrew characters and switch to RTL rendering.
>>>> This is certainly odd to readers that are not familiar with mixed LTR/RTL rendering, but it is the way the RTL writing systems operate.
>>>>
>>>> Whether your plaintext editor picks up RTL information from the characters or not depends on the editor.
>>>> If it does (e.g., Emacs does), moving the cursor *forward* (often done with the cursor-right key) may go *left* on the Hebrew part, which is the telltale sign of RTL support.
>>>> (If the editor tries to hide the RTL presentation by stepping you in geometric sequence, like the Apple Mail compose editor does, selecting a part straddling the RTL/LTR boundary may be the only way to tell.)
>>>>
>>>>> 2) For clarity, would it sense to walk through the string character by character, or do you prefer the current form? In other words, what do you think of changing from
>>>>> string (names, nums)
>>>>> to
>>>>> char (name, num), char (name, num), char (name, num), char (name, num)
>>>>> For example, please see:
>>>>> https://www.rfc-editor.org/v3test/rfc9290_A3test.html#appendix-A.3-7 <https://www.rfc-editor.org/v3test/rfc9290_A3test.html#appendix-A.3-7>
>>>>
>>>> I like the direction [pun not intended] of this change.
>>>>
>>>> But I would like to make it clear that the sequence of writing the characters is orthogonal to the presentation as LTR or RTL text:
>>>>
>>>> OLD:
>>>> The following example shows how the Hebrew-language string is represented, where in the rtldirection, each character is: "ש" (HEBREW LETTER SHIN, U+05E9), "ל" (HEBREW LETTER LAMED, U+05DC),"ו" (HEBREW LETTER VAV, U+05D5), "ם" (HEBREW LETTER FINAL MEM, U+05DD). Note the rtl direction expressed by setting the third element in the array to "true”.
>>>>
>>>> NEW:
>>>> The following example shows how the Hebrew-language string "שלום" is represented, where in direction of reading, the sequence of characters is: "ש" (HEBREW LETTER SHIN, U+05E9), "ל" (HEBREW LETTER LAMED, U+05DC),"ו" (HEBREW LETTER VAV, U+05D5), "ם" (HEBREW LETTER FINAL MEM, U+05DD). Note the rtl direction expressed by setting the third element in the array to "true”.
>>>>
>>>> Because of the brutal way in which xml2rfc enforces its narrow understanding of RFC 7997, you may need to push the first “שלום” into artwork (which would allow getting rid of the quotes).
>>>>
>>>> Grüße, Carsten
>>>>
>>>>
>>>>
>>>>
>>>>>
>>>>>
>>>>> Thank you.
>>>>> RFC Editor/sg
>>>>>
>>>>> <Screen Shot 2022-08-31 at 1.37.02 PM.png>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>> On Aug 31, 2022, at 7:34 AM, Carsten Bormann <cabo@tzi.org <mailto:cabo@tzi.org>> wrote:
>>>>>>
>>>>>> Megan,
>>>>>>
>>>>>> let me briefly note that our two approvals have not made it yet to https://www.rfc-editor.org/auth48/rfc9290 <https://www.rfc-editor.org/auth48/rfc9290> — just in case this is slowing down the process.
>>>>>>
>>>>>> Grüße, Carsten
>>>>>>
>>>>>>
>>>>>>> On 2022-08-23, at 11:04, Thomas Fossati <thomas.fossati@arm.com <mailto:thomas.fossati@arm.com>> wrote:
>>>>>>>
>>>>>>> On Monday, 22 August 2022 at 22:45, Carsten Bormann <cabo@tzi.org <mailto:cabo@tzi.org>> wrote:
>>>>>>>> After repairing the PDF glitch and the typo, and possibly addressing
>>>>>>>> the above nits, I believe that RFC9290-to-be will be ready for
>>>>>>>> publication.
>>>>>>>
>>>>>>> +1
>>>>>>>
>>>>>>> Cheers, t
>>>>>>>
>>>>>>>
>>>>>>> IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.
>>>>>
>>>>
>>
>> --
>> Xml-sg-cmt mailing list
>> Xml-sg-cmt@ietf.org
>> https://www.ietf.org/mailman/listinfo/xml-sg-cmt
>
>

Regards,
John Levine, johnl@taugh.com, Taughannock Networks, Trumansburg NY
Please consider the environment before reading this e-mail. https://jl.ly