Subject: Re: [rfc-i] Unicode in xml2rfc v3

From: Marc Petit-Huguenin <[email-masked]>
Date: Sat, 19 Dec 2020 14:43:49 -0800

On 12/19/20 1:54 PM, John Levine wrote:
> In article <[email-masked]> you write:
>> Because non-ASCII characters cannot improve a well-written RFC -- or a well-written program for that matter.
>> Graphics and diagrams in place of formal descriptions (in ASCII) are also signs of the sloppiness of the
>> authors -- or at least of the little faith they have on their implementers.
> 
> I HAVE TO ASK.  HOW DO YOU FEEL ABOUT LOWER CASE?  ASCII GOT ALONG WITHOUT IT FOR
> QUITE A WHILE.
> 

I care exclusively about specifications that can be implemented as interoperable programs.  The minimal formulation for such specifications is a dependent type, which can be always be expressed in ASCII.

I'd rather get an RFC prepared on a typewriter whose text is isomorphic to the underlying formal specification than a fancy document that is not.  AFAICT fancy documents do not make the Internet works better, whereas formal specs do.  When we'll reach that point, I may revisit my stance against hiding crappy specs under a flourish of non-ASCII symbols.

-- 
Marc Petit-Huguenin
Email: [email-masked]
Blog: https://marc.petit-huguenin.org
Profile: https://www.linkedin.com/in/petithug
_______________________________________________
rfc-interest mailing list
[email-masked]
https://www.rfc-editor.org/mailman/listinfo/rfc-interest

---

From: "John R Levine" <[email-masked]>
Date: 19 Dec 2020 20:29:58 -0500

On Sat, 19 Dec 2020, Marc Petit-Huguenin wrote:
> I care exclusively about specifications that can be implemented as 
> interoperable programs.  The minimal formulation for such specifications is a 
> dependent type, which can be always be expressed in ASCII.

I entirely agree that it makes sense to write code in ASCII.

But most of the contents of RFCs is not code, it's text, and we have 
hundreds of years of experience typesetting text.  Look at any decently 
produced book or magazine and you will see that the character set is a lot 
broader than ASCII, which makes it a lot more readable.

Regards,
John Levine, [email-masked], Taughannock Networks, Trumansburg NY
Please consider the environment before reading this e-mail. https://jl.ly
_______________________________________________
rfc-interest mailing list
[email-masked]
https://www.rfc-editor.org/mailman/listinfo/rfc-interest

---

From: Marc Petit-Huguenin <[email-masked]>
Date: Sun, 20 Dec 2020 08:39:31 -0800

On 12/19/20 5:29 PM, John R Levine wrote:
> But most of the contents of RFCs is not code, it's text, and we have hundreds of years of experience typesetting text.  Look at any decently produced book or magazine and you will see that the character set is a lot broader than ASCII, which makes it a lot more readable.
> 

I am not arguing that all text produced should be in ASCII.  In fact non-normative parts of a standard could use non-ASCII  -- I do not read these anyway because I believe that a standard should be implementable even after been stripped of all the informative parts (abstract, introduction, overview of operations, examples, any diagram that is not complete, any list that is not exhaustive, informative references, appendices).

I would even go further, in that everything produced by the IRTF stream should use the whole Unicode character set, such as they look more a paper written in LaTeX, and just forgo the text version.  These documents are meant to be read, not to be implemented, and there is really nothing that come close to a nicely typeset PDF to absorb information.

Where I draw the line is in the parts that are meant to be implemented, aka normative text.  These are to be (at least virtually) translated into a dependent type (or higher order intuitionistic logic), itself then derived into a program (aka, the stuff I am payed to produce).  To be able to do that translation I need unambiguous text, and with as little flourish as possible.  Even before adding non-ASCII characters, my observation is that the normative text in RFCs already have way too many words, and I wish that a editor specialized in the topic (not the RFC editor) would have spent time distilling these sentences to their essence.  Which in turn would make the translation explained above easier, which in turn would make the programs derived from it safer, which in turn would make the Internet works better.

Now admitting non-ASCII for some RFCs or some parts of an RFCs requires discipline so that's a dead end.  One way could be to annotate each section with a normative boolean attribute and prevent <u> (and other stuff) in a normative=true section.  That will not happen so as a fallback the <u> thing seems a good way for me to generate a plain text that replaces these with the CLDR short text (as suggested in a previous email) when preparing for printing.  I already use a patched xml2rfc (to print RFCs with pagination), so that's not a big deal.  I do not believe that the IETF Trust allows for redistribution of stripped down RFCs, so other people will not profit from that improvement.

---

From: "John R Levine" <[email-masked]>
Date: 20 Dec 2020 12:30:38 -0500

On Sun, 20 Dec 2020, Marc Petit-Huguenin wrote:
> I am not arguing that all text produced should be in ASCII.  In fact 
> non-normative parts of a standard could use non-ASCII  -- I do not read these 
> anyway because I believe that a standard should be implementable even after 
> been stripped of all the informative parts (abstract, introduction, overview 
> of operations, examples, any diagram that is not complete, any list that is 
> not exhaustive, informative references, appendices).

Let me just say that the standards documents you use appear to be very 
unlike the ones I use.  Perhaps it's applications, which have to deal with 
input from people, compared to lower level stuff.

Regards,

---

From: Carsten Bormann <[email-masked]>
Date: Sun, 20 Dec 2020 18:47:39 +0100

Hi Marc,

you describe an interesting research program.

There are quite a few challenges before something like that can be a reality.
Not that we haven’t tried [1].
Overzealous attempts at applying formal description techniques helped kill OSI [2], and I don’t want to be on the guilty side again.

Until we have made more progress on this (*), most RFCs will contain large parts that need to be understood by humans, if only because of the incredible span of subject matter that RFCs cover.  Any help we can get there is good, and making use of a capability that we now pretty much universally have, namely the use of beyond-ASCII characters, is highly indicated.

Grüße, Carsten

[1] e.g., https://doi.org/10.1016/0140-3664(80)90151-6
[2] http://www.cs.columbia.edu/~hgs/papers/2011/Dagstuhl%2011042.pdf
(*) Obviously, we already have XDR syntax, ABNF, YANG, CDDL, ...

> On 2020-12-20, at 17:39, Marc Petit-Huguenin <[email-masked]> wrote:
>

---

From: Marc Petit-Huguenin <[email-masked]>
Date: Sun, 20 Dec 2020 10:26:49 -0800

I am not arguing for the use of formal methods (at least not here, that would be in fdt@).

I am arguing that normative text can be understood as paraphrasing a formal specification (which stays invisible and in most cases nonexistent) and that concision, including using ASCII, is key for that paraphrasing.  See section IV of [1].

[1] Zave P. Experiences with protocol description. In Workshop on Rigorous Protocol Engineering (W-RiPE’11) 2011 Oct.

---

From: "John R Levine" <[email-masked]>
Date: 20 Dec 2020 13:38:41 -0500

> I am arguing that normative text can be understood as paraphrasing a formal 
> specification (which stays invisible and in most cases nonexistent) and that 
> concision, including using ASCII, is key for that paraphrasing.  See section 
> IV of [1].

Like I said, the specs you implement are quite different from the ones I 
implement.  Take a look at RFC 7489 which we are currently revising.

R's,
John

---

From: "John R Levine" <[email-masked]>
Date: 20 Dec 2020 15:33:03 -0500

> It sounds like the plan is to change idnits to warn about Unicode character usage in several categories:
>
> In running text
> In examples
> In names/contact

That's one set of possibilities.

> Perhaps an IANA registry with Expert Review?

This is not appropriate for IANA.  It's only for the use of the IETF and 
the other RFC streams.

Regards,

---

From: "Salz, Rich" <[email-masked]>
Date: Sun, 20 Dec 2020 22:12:56 +0000

>    I am arguing that normative text can be understood as paraphrasing a formal specification (which stays invisible and in most cases nonexistent) and that concision, including using ASCII, is key…

That's really strange.  I've never heard of anything like that.  So an RFC is a paraphrase of a mythical document, written using a limited subset of written language?

---

From: Marc Petit-Huguenin <[email-masked]>
Date: Sun, 20 Dec 2020 16:23:20 -0800

On 12/20/20 2:12 PM, Salz, Rich wrote:
> That's really strange.  I've never heard of anything like that.  

I believe you.

> So an RFC is a paraphrase of a mythical document, written using a limited subset of written language?
>

---

From: Marc Petit-Huguenin <[email-masked]>
Date: Sun, 20 Dec 2020 16:47:04 -0800

On 12/20/20 10:38 AM, John R Levine wrote:
> Like I said, the specs you implement are quite different from the ones I implement.  Take a look at RFC 7489 which we are currently revising.
> 

I'll prepare an example, hopefully based on 7489 (that's not my area of expertise), but with the Holidays coming that'll take a couple weeks.

In any case that is not a discussion suitable for that mailing-list, so I'll follow-up on [email-masked] instead.