[rfc-i] Some proposed updates

Phillip Hallam-Baker phill at hallambaker.com
Thu Mar 5 09:28:08 PST 2020

I am currently working on using XML2RFCv3 to write a set of drafts using
some fairly involved cryptography math. The HTML presentation vastly
improves readability but this naturally leads to discovery of 'issues'. I
know we don't have an ad with plenary authority at the moment but I think
it is useful to keep track for when we do.

1) Input of math

Neither Markdown nor Word are remotely comfortable for
inputting mathematical formulas. Consider the following:

f(x) = x^2 + 4

To present that properly we should render the f and x in italics and the
rest in normal font. So if like me you have multiple equations with
convoluted subscripts, etc., it is a pain in the pattotie. So next time I
get round to working on my tool, I am planning to drop in support for LaTeX
style equations. Writing $f(x) = x^2 + 4$ should cause the text inside the
$$ braces to be rendered as math.

This does not affect the spec of course, I am raising it here so that
Carsten, myself and anyone else making tools can possibly work out a common

2) Presentation of proofs.

I frequently write out proofs:

errors = (code).(more code)
   = more.code.code
   = more.code^2

i.e. e = mc^2

Right now, the only ways to do this is with tables or(ab)using <dl> lists

<dt>errors</dt><dd>= (code).(more code)</dd>
    <dd> = more.code.code </dd>
    <dd> = more.code <sup>2</sup></dd>

I think we should have proper markup for this:

<lhs>errors</ lhs >=<rhs>(code).(more code)</rhs>
    =<rhs>more.code.code </rhs>
< proof >

In addition to specifying the left and right hand sides, I would like to be
able to specify the side conditions and proof rules applied.

3) Math characters.

I still haven't seen a list of which characters are supported/unsupported.
It seems that the card suit characters are supported but not commonly used
math symbols like circle-plus, circle-cross, arrows, thus, etc.

The number of special characters used in Z and VDM are not actually very
large but they are really important. We certainly don't need every UNICODE
math symbol but we do need more than we have at the moment to express
formal methods notations.


4) SVG-Tiny is obsolete and will be deprecated shortly.

We should drop SVG-Tiny and use SVG as the basis for diagrams. We can still
apply the same restrictions on the use of color but SVG is the standard,
SVG-Tiny is about to be deprecated. There is only one major vendor
supporting it and only in one product.

SVG-Tiny does not support the features used to create arrows on lines by
almost every drawing tool in use. It is not reasonable to demand that
people make use of an arbitrary subset of a standard that is obsolete.
There are no tools that support SVG-Tiny that do not support full SVG.

I have looked on the list discussions and absolutely nobody raised the
severely restricted support in SVG-Tiny when diagrams were discussed. So I
fail to see any group decision or consensus on this point.

5) There should be more structure for citations to scholarly journals.

The current <reference> structure was written for the ASCII text style.
Slapping a journal article reference in <annotation> worked. Now that we
have italics in the output, that is insufficient to produce the generally
accepted presentation forms.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.rfc-editor.org/pipermail/rfc-interest/attachments/20200305/62e17a5b/attachment.html>

More information about the rfc-interest mailing list