Subject: [Tools-discuss] UTF-8 box characters with wavy lines in XML2RFC v3 draft

From: Tom Pusateri <[email-masked]>
Date: Tue, 5 Nov 2019 20:21:09 -0500

Hi,
	As a follow up to DKG’s comments about v3 submissions and UTF-8 box characters, we recently submitted this draft.

We did get the new v3 HTML version referenced in the document datatracker if you click the “status” link below, you will see the first HTML link is the new version.
We also got the old HTML version using the htmlized link in the document datatracker. This seems unnecessary to me.

But below, you see two htmlized links in the outgoing email and neither of these refer to the new v3 HTML version.

I would like to see both of these links removed and replaced with a link to the v3 HTML version in the announcement email.

Also, note how the box characters in the v3 HTML version end up are unaligned? There is probably something going wrong here in the CSS or maybe our source but I’m not sure what. Maybe we’re not using the correct vertical bar? Any help on that would be appreciated so we don’t get wavy lines.

Thanks,
Tom

> Begin forwarded message:
> 
> From: [email-masked]
> Subject: New Version Notification for draft-pusateri-dnsop-update-timeout-04.txt
> Date: November 4, 2019 at 11:27:24 AM EST
> To: "Tim Wattenberg" <[email-masked]>, "Tom Pusateri" <[email-masked]>
> 
> 
> A new version of I-D, draft-pusateri-dnsop-update-timeout-04.txt
> has been successfully submitted by Tim Wattenberg and posted to the
> IETF repository.
> 
> Name:		draft-pusateri-dnsop-update-timeout
> Revision:	04
> Title:		DNS TIMEOUT Resource Record
> Document date:	2019-11-04
> Group:		Individual Submission
> Pages:		17
> URL:            https://www.ietf.org/internet-drafts/draft-pusateri-dnsop-update-timeout-04.txt
> Status:         https://datatracker.ietf.org/doc/draft-pusateri-dnsop-update-timeout/
> Htmlized:       https://tools.ietf.org/html/draft-pusateri-dnsop-update-timeout-04
> Htmlized:       https://datatracker.ietf.org/doc/html/draft-pusateri-dnsop-update-timeout
> Diff:           https://www.ietf.org/rfcdiff?url2=draft-pusateri-dnsop-update-timeout-04
> 
> Abstract:
>   This specification defines a new DNS TIMEOUT resource record (RR)
>   that associates a lifetime with one or more zone resource records.
>   It is intended to be used to transfer resource record lifetime state
>   between a zone's primary and secondary servers and to store lifetime
>   state during server software restarts.
> 
> 
> 
> 
> Please note that it may take a couple of minutes from the time of submission
> until the htmlized version and diff are available at tools.ietf.org.
> 
> The IETF Secretariat
>

---

From: Adam Roach <[email-masked]>
Date: Tue, 5 Nov 2019 20:33:13 -0600

While v3 allows Unicode characters, it's not a free-for-all 
anything-goes permission. RFC 7997 outlines the nine very narrowly 
scoped ways that Unicode can be used in v3 documents. I can't find one 
that covers the use in your draft. Which one do you think applies?

/a

On 11/5/19 7:21 PM, Tom Pusateri wrote:
> Hi,
> As a follow up to DKG’s comments about v3 submissions and UTF-8 box 
> characters, we recently submitted this draft.
>
> We did get the new v3 HTML version referenced in the document 
> datatracker if you click the “status” link below, you will see the 
> first HTML link is the new version.
> We also got the old HTML version using the htmlized link in the 
> document datatracker. This seems unnecessary to me.
>
> But below, you see two htmlized links in the outgoing email and 
> neither of these refer to the new v3 HTML version.
>
> I would like to see both of these links removed and replaced with a 
> link to the v3 HTML version in the announcement email.
>
> Also, note how the box characters in the v3 HTML version end up are 
> unaligned? There is probably something going wrong here in the CSS or 
> maybe our source but I’m not sure what. Maybe we’re not using the 
> correct vertical bar? Any help on that would be appreciated so we 
> don’t get wavy lines.
>
> Thanks,
> Tom
>
>> Begin forwarded message:
>>
>> *From: [email-masked] <mailto:[email-masked]>
>> *Subject: **New Version Notification for 
>> draft-pusateri-dnsop-update-timeout-04.txt*
>> *Date: *November 4, 2019 at 11:27:24 AM EST
>> *To: *"Tim Wattenberg" <[email-masked] 
>> <mailto:[email-masked]>>, "Tom Pusateri" <[email-masked] 
>> <mailto:[email-masked]>>
>>
>>
>> Name:draft-pusateri-dnsop-update-timeout
>> Revision:04
>> Title:DNS TIMEOUT Resource Record
>> Document date:2019-11-04
>> Group:Individual Submission
>> Pages:17
>> URL: 
>> https://www.ietf.org/internet-drafts/draft-pusateri-dnsop-update-timeout-04.txt
>> Status: 
>> https://datatracker.ietf.org/doc/draft-pusateri-dnsop-update-timeout/
>> Htmlized: 
>> https://tools.ietf.org/html/draft-pusateri-dnsop-update-timeout-04
>> Htmlized: 
>> https://datatracker.ietf.org/doc/html/draft-pusateri-dnsop-update-timeout
>> Diff: 
>> https://www.ietf.org/rfcdiff?url2=draft-pusateri-dnsop-update-timeout-04
>>
>> Abstract:
>> until the htmlized version and diff are available at tools.ietf.org 
>> <http://tools.ietf.org>.
>>
>> The IETF Secretariat
>>
>
>
> ___________________________________________________________
> Tools-discuss mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tools-discuss
>
> Please report datatracker.ietf.org and mailarchive.ietf.org
> bugs at http://tools.ietf.org/tools/ietfdb
> or send email to [email-masked]
>
> Please report tools.ietf.org bugs at
> http://tools.ietf.org/tools/issues
> or send email to [email-masked]

---

From: Tom Pusateri <[email-masked]>
Date: Tue, 5 Nov 2019 21:39:04 -0500

We were told on this list that box characters were allowed in artwork.

Tom

> On Nov 5, 2019, at 9:33 PM, Adam Roach <[email-masked]> wrote:
> 
> While v3 allows Unicode characters, it's not a free-for-all anything-goes permission. RFC 7997 outlines the nine very narrowly scoped ways that Unicode can be used in v3 documents. I can't find one that covers the use in your draft. Which one do you think applies?
> 
> /a
> 
>>> From: [email-masked] <mailto:[email-masked]>
>>> To: "Tim Wattenberg" <[email-masked] <mailto:[email-masked]>>, "Tom Pusateri" <[email-masked] <mailto:[email-masked]>>
>>> 
>>> 
>>> URL:            https://www.ietf.org/internet-drafts/draft-pusateri-dnsop-update-timeout-04.txt <https://www.ietf.org/internet-drafts/draft-pusateri-dnsop-update-timeout-04.txt>
>>> Status:         https://datatracker.ietf.org/doc/draft-pusateri-dnsop-update-timeout/ <https://datatracker.ietf.org/doc/draft-pusateri-dnsop-update-timeout/>
>>> Htmlized:       https://tools.ietf.org/html/draft-pusateri-dnsop-update-timeout-04 <https://tools.ietf.org/html/draft-pusateri-dnsop-update-timeout-04>
>>> Htmlized:       https://datatracker.ietf.org/doc/html/draft-pusateri-dnsop-update-timeout <https://datatracker.ietf.org/doc/html/draft-pusateri-dnsop-update-timeout>
>>> Diff:           https://www.ietf.org/rfcdiff?url2=draft-pusateri-dnsop-update-timeout-04 <https://www.ietf.org/rfcdiff?url2=draft-pusateri-dnsop-update-timeout-04>
>>> 
>>> Abstract:
>>> until the htmlized version and diff are available at tools.ietf.org <http://tools.ietf.org/>.
>>> 
>>> The IETF Secretariat
>>> 
>> 
>> 
>> 
>> [email-masked] <mailto:[email-masked]>
>> https://www.ietf.org/mailman/listinfo/tools-discuss <https://www.ietf.org/mailman/listinfo/tools-discuss>
>> 
>> bugs at http://tools.ietf.org/tools/ietfdb <http://tools.ietf.org/tools/ietfdb>
>> or send email to [email-masked] <mailto:[email-masked]>
>> 
>> http://tools.ietf.org/tools/issues <http://tools.ietf.org/tools/issues>
>> or send email to [email-masked] <mailto:[email-masked]>
>

---

From: Adam Roach <[email-masked]>
Date: Tue, 5 Nov 2019 22:46:40 -0600

> We were told on this list that box characters were allowed in artwork.

That's not on my radar. I'll let Heather (copied) chime in with her 
perspective.

In any case, the *general* problem you're running into is that many 
monospaced fonts don't include much more than the basic accented Latin 
character set, and this results in substituting glyphs from other fonts 
(rather than rendering tofu or the questionmark "replacement character") 
that are of a different width than the fixed one used by the font in 
question.

This is why, had the question come up generally, I would have pushed 
back on the notion of using box characters in diagrams [1]: even if it 
works okay on your system, it's likely to fail on someone's.

The *specific* problem you're running into is that Roboto Mono (or 
whatever your system uses as the default monospace font if you don't 
have Roboto Mono installed) doesn't contain "▶", and so it's getting 
pulled in from some other font, where it's wider.

/a

____
[1] That is, absent some compelling data showing that they are generally 
available in all -- or at least the vast majority of -- popular 
fixed-width fonts. I think the current episode shows where such an 
assertion would be implausible.

---

From: Tom Pusateri <[email-masked]>
Date: Wed, 6 Nov 2019 00:30:19 -0500

> On Nov 5, 2019, at 11:57 PM, Adam Roach <[email-masked]> wrote:
> 
> That's not on my radar. I'll let Heather (copied) chime in with her perspective.
> 
> In any case, the *general* problem you're running into is that many monospaced fonts don't include much more than the basic accented Latin character set, and this results in substituting glyphs from other fonts (rather than rendering tofu or the questionmark "replacement character") that are of a different width than the fixed one used by the font in question.
> 
> This is why, had the question come up generally, I would have pushed back on the notion of using box characters in diagrams [1]: even if it works okay on your system, it's likely to fail on someone's.
> 
> The *specific* problem you're running into is that Roboto Mono (or whatever your system uses as the default monospace font if you don't have Roboto Mono installed) doesn't contain "▶", and so it's getting pulled in from some other font, where it's wider.
> 
> /a
> 
> ____
> [1] That is, absent some compelling data showing that they are generally available in all -- or at least the vast majority of -- popular fixed-width fonts. I think the current episode shows where such an assertion would be implausible.

But we completely control the HTML document and can even embed the font.  This sounds like a solvable problem.

Tom

---

From: Adam Roach <[email-masked]>
Date: Wed, 6 Nov 2019 00:09:57 -0600

> On Nov 5, 2019, at 23:30, Tom Pusateri <[email-masked]> wrote:
> 
> 
> 

Sure, and my take is that your proposed cure would be several orders of magnitude worse than the disease. The prospect of requiring specific fonts for proper HTML rendering is almost certainly not what we want.

Also, the TXT version renders incorrectly for many fonts (including the one that shows up on my laptop), and your proposal doesn’t fix it. 

/a

---

From: Carsten Bormann <[email-masked]>
Date: Wed, 6 Nov 2019 08:51:24 +0100

> Sure, and my take is that your proposed cure would be several orders of magnitude worse than the disease. The prospect of requiring specific fonts for proper HTML rendering is almost certainly not…

We already embed the font (PT Mono).

I’m not very good with the inspector, but Chrome appears to say about this draft [1]:
PT Mono—Local file(2280 glyphs)
Courier—Local file(24 glyphs)
Lucida Grande—Local file(2 glyphs)

I don’t know how to get Chrome to reveal which characters of the HTML source which glyph out of the above list.

Grüße, Carsten

[1]: https://datatracker.ietf.org/doc/html/draft-pusateri-dnsop-update-timeout

---

From: Carsten Bormann <[email-masked]>
Date: Wed, 6 Nov 2019 09:27:12 +0100

> We already embed the font (PT Mono).

…and PT Mono does contain the appropriate character, ► U+25BA BLACK RIGHT-POINTING POINTER, just not ▶ U+25B6 BLACK RIGHT-POINTING TRIANGLE.

I believe that, once the tools have stabilized, it will be easier to stay within a reasonable repertoire.  Instead of standardizing this in some rigid spec, it should be the RPC that guides the authors towards “reasonable” (and the tools should help with this).

Grüße, Carsten

---

From: Michael Richardson <[email-masked]>
Date: Wed, 06 Nov 2019 10:10:43 -0500

Tom Pusateri <pusateri=[email-masked]> wrote:
    > correct vertical bar? Any help on that would be appreciated so we don’t
    > get wavy lines.

I didn't see anything unaligned... maybe some CSS didn't load yesterday due
to the attack?

I do like how nice those diagrams look; is there a reason you didn't use box
characters for the packet layout?  I now feel that we ought have a
meta-language to generate nice packet layouts... I once worked on an ID for
such a thing.

--
Michael Richardson <[email-masked]>, Sandelman Software Works
 -= IPv6 IoT consulting =-

---

From: Michael Richardson <[email-masked]>
Date: Wed, 06 Nov 2019 10:14:38 -0500

Carsten Bormann <[email-masked]> wrote:
    > I believe that, once the tools have stabilized, it will be easier to
    > stay within a reasonable repertoire.  Instead of standardizing this in
    > some rigid spec, it should be the RPC that guides the authors towards
    > “reasonable” (and the tools should help with this).

And, at the risk of invoking https://tools.ietf.org/html/draft-iab-protocol-maintenance-04
(which clearly nobody wants to apply to email), it would be nice if our tools
were capable of doing more than the subset that the RFC-editor wants to
publish, as there are some other entities that like our approach.
(I recall GRID being one of them)