Subject: [Xml-sg-cmt] using non-ASCII chars to draw artwork

From: Alice Russo <[email-masked]>
Date: Tue, 15 Mar 2022 09:46:00 -0700

Greetings,
(An item from yesterday's agenda that we didn't get to.)

Re:
> Unnecessary UTF-8 in figures
> See for instance:
> https://www.ietf.org/archive/id/draft-ietf-lamps-samples-08.html#section-2.5

Is it OK to keep this in the RFC? If not, will approach it w/ the author as follows; please let us know if you prefer otherwise.  

Seems RFC 7997 (Section 3 "Rules for the Use of Non-ASCII Characters" <https://www.rfc-editor.org/rfc/rfc7997.html#section-3>) doesn't list this as an acceptable use. Pretty sure this is the first case we've seen of using non-ASCII chars to draw.

Perhaps:
[rfced] FYI, in the two artworks in Section 2.5, we have replaced the non-ASCII
characters (e.g., U+2554 BOX DRAWINGS DOUBLE DOWN AND RIGHT) with ASCII characters
because RFC 7997 does not include this as an acceptable use on non-ASCII characters
in RFCs. 

Please review the updated artwork. where the replacement is, e.g.,

+==============+    +-------------------+
|| ca.rsa.crt  ||-->| alice.encrypt.crt |
+==============+    +-------------------+

Thanks,
Alice

---

From: Robert Sparks <[email-masked]>
Date: Tue, 15 Mar 2022 13:12:21 -0500

I continue to believe that we should replace the proscription against 
non-ascii UTF-8, and would like to see it happen as close to immediately 
as we can make it happen.

What we should have instead is a policy of "reasonable use", and I think 
this is a reasonable use.

(Of course, we'll have to talk about who gets to decide what's 
reasonable, but I think we're well on the path to "RPC in consultation 
with the Stream Managers with the RSAB as a fallback).

RjS

On 3/15/22 11:46 AM, Alice Russo wrote:
> Is it OK to keep this in the RFC? If not, will approach it w/ the 
> author as follows; please let us know if you prefer otherwise.
>
> Seems RFC 7997 (Section 3 "Rules for the Use of Non-ASCII Characters" 
> <https://www.rfc-editor.org/rfc/rfc7997.html#section-3>) doesn't list 
> this as an acceptable use. Pretty sure this is the first case we've 
> seen of using non-ASCII chars to draw.
>
> Perhaps:

---

From: "John R Levine" <[email-masked]>
Date: 15 Mar 2022 15:45:28 -0400

> non-ascii UTF-8, and would like to see it happen as close to immediately as 
> we can make it happen.
>
> What we should have instead is a policy of "reasonable use", and I think this 
> is a reasonable use.

Personally, I think it's reasonable, but I also do not know what people 
use to read text RFCs and do not know how those characters look in those 
applications.

Most of the programs I use render them just fine, but the text editor I 
use doesn't.

Regards,
John Levine, [email-masked], Taughannock Networks, Trumansburg NY
Please consider the environment before reading this e-mail. https://jl.ly

---

From: Alice Russo <[email-masked]>
Date: Tue, 15 Mar 2022 14:24:36 -0700

[Added RPC team for awareness.]

Based on the replies from Robert and John, sounds like they suggest proceeding w/ the original (non-ASCII chars to draw artwork). Sounds like John agrees w/ changing to the following policy; so, is this for 7997bis?
>> What we should have instead is a policy of "reasonable use"

As far as display, text looks OK only in some viewers. The arrows in PDF look bad. (Looks OK in HTML.) Sample files:
https://www.rfc-editor.org/v3test/artworktest.txt
https://www.rfc-editor.org/v3test/artworktest.pdf#section-2.5
https://www.rfc-editor.org/v3test/artworktest.html#section-2.5

Thanks,
Alice

> On Mar 15, 2022, at 12:45 PM, John R Levine <[email-masked]> wrote:
> 
>> I continue to believe that we should replace the proscription against non-ascii UTF-8, and would like to see it happen as close to immediately as we can make it happen.
>> 
>> What we should have instead is a policy of "reasonable use", and I think this is a reasonable use.
> 
> Personally, I think it's reasonable, but I also do not know what people use to read text RFCs and do not know how those characters look in those applications.
> 
> Most of the programs I use render them just fine, but the text editor I use doesn't.
> 
> Regards,
> -- 
> Xml-sg-cmt mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/xml-sg-cmt
>

---

From: Robert Sparks <[email-masked]>
Date: Tue, 15 Mar 2022 17:19:54 -0500

Fwiw, the arrow has the same issue in the html - the fonts don't line 
those characters up as cleanly as you would expect.

view the html and magnify to your browser's max (using command-+ if 
you're on a mac).

RjS

---

From: "John R Levine" <[email-masked]>
Date: 15 Mar 2022 18:37:30 -0400

> Fwiw, the arrow has the same issue in the html - the fonts don't line those 
> characters up as cleanly as you would expect.
>
> view the html and magnify to your browser's max (using command-+ if you're on 
> a mac).

If he really cares how it looks, he should use an <artset> and do an SVG 
version for the HTML and PDF rendering.  And keep in mind that there is no 
guarantee that the characters in any particular fixed pitch font will line 
up the way he expects.

My concern is that there's way too much "it looks fine to me" in this 
discussion.

Regards,

---

From: Robert Sparks <[email-masked]>
Date: Tue, 15 Mar 2022 20:19:09 -0500

On 3/15/22 5:37 PM, John R Levine wrote:
> If he really cares how it looks, he should use an <artset> and do an 
> SVG version for the HTML and PDF rendering.  And keep in mind that 
> there is no guarantee that the characters in any particular fixed 
> pitch font will line up the way he expects.
>
yeah - I'm seeing that.