[rfc-i] verifying where we do/don't have consensus

Martin Rex mrex at sap.com
Mon Jun 4 21:54:29 PDT 2012

Heather Flanagan (RFC Series Editor) wrote:
> To be clear, the canonical source format for RFC is currently nroff.

Is the nroff source that the RFC editor uses to produce the TXT documents
available online/for download somewhere?

While "groff -Thtml rfcXXXX.nroff > rfcXXXX.html" does not currently
produce any of the bold and URL/crossreferences that rfcmarkup produces,
it will create reflowable text.

> Regarding consensus, the table format on the wiki
> (http://www.rfc-editor.org/rse/wiki/doku.php?id=formatreq) may be easier
> for some to read, but to both summarize and keep the thread
> self-contained for posterity, here's my understanding to date, organized
> by where I think we have versus where we have not reached consensus:
>   [...]
> (Side note: reaching consensus on what we want != reaching consensus on
> how to do it)
> Consensus NOT reached due to disagreement or lack of discussion
> | Need broader character encoding for author names    |  **No**    |
> [RSE] would note that at least one TLD registrar (AFNIC) is beginning to
> register domain names with diacritical marks and these will eventually
> show up in references and author's addresses; a potential compromise is
> to limit what characters are allowed, such as to the list allowed by DNS
> domain registrars.      |

There is no problem with allowing inclusion of non-ASCII author names
in the author(!) section, as long as each Author is required to also
provide a transliteration of his/her name with ASCII-only characters.
The Author must pick such a canonical and least-offending transliteration
so that *every* other IETF participant will be able to type this name
on his keyboard (being able to write in English is a pre-requisite
for actively participating IETF Email discussions).

EMail addresses MUST be provided in all-ASCII letters, so they can be read,
understood and entered by all IETFers and used with all EMail software.

(The number one reason why telephone works internationally is that the
 whole world has standardized on using arabic digits & glyphs.)

> | Need to be able to include non-ASCII graphics/images   |  **No**  |
> [RSE] graphics, whether ASCII or other, have complications when
> considering resizeability (see small device request)   |

They also have complication when rendering in text-only environments,
they can not be grepped, they're harder to discuss, more prone to

Graphics are fine when optional for non-normative, illustrative
purposes and coupled with the requirement that the document remains
clear, accurate and meaningful when the graphic image is not rendered,
e.g. when the device/environment does not support rendering it.

> | Want broader character encoding for body of document  |  **No**  |   |
> | Want the ability to denote protocol examples using the character sets
> those examples support  |  **No**   |   |

As above, a broader character encoding would be OK for non-normative,
illustrative purposes coupled with the requirement that the document
remains clear, accurate and meaningful when the non-ASCII characters
are not rendered, e.g. because the device/environment does not support
those codepoints.  

> | Want the ability to semantically tag some document info, at least
> authors' names and references  |  **No**  |  |

There should not be a problem with some authoring tools providing
additional meta-info for that as long as this does *NOT* become
a requirement for the submission format.

> | Want to be able to include equations |  **No**   |   |
> | Want to be able to view equations  |  **No**  |    |

It is extremely hard to see a use case for typesetting of equations.
In most cases, equations in RFCs will have to be converted into program
source code, so writing the equations in ASCII makes it *much* easier
to put them in code, copy&paste RFC text containing them into souce
code comments and into EMail discussion.

> | Want to be able to tag ownership/source of comments  |  **No**  |  |

Should this have been a problem in the past for the communication
between document co-authors and the RFC-Editor, then this might
be OK as optional meta-data to distinguish _only_ between official document
co-authors responsible for specific parts/sections of a document.

Trying to attribute words, expressions, sentences or paragraphs to
specific contributors is near impossible to get right whenever proposals
for replacement text are the result of elaborate mailing list discussions.
So I think the latter ought not appear as meta-data in the submission format.

> | Need to be able to see non-ASCII graphics/images    |  **No**  |       |

Not necessary, since these MUST be merely for illustration (eye-candy).

> | Want intelligent html-style linking within references  |  **No**  |   |

Not necessary.  Cross-referencing needs to be crystal clear so that
it can be recognized by textual pattern matching just like rfcmarkup
does it today.

> | Want the RFC to be suitable for small screens/mobile devices  | 
> **No**  |     |

By creating alternative output formats that those small devices are more
accustomed to render (like reflowing text to accomodate their small
screens), a significant part of the alleged problems will disappear.

> | Want a more flexible line length  |  **No**  |    |

Alternative output formats will allow flowing text to
arbitrary line lengths.

> | Want a single document to view (should not have to jump between two
> documents for complete information)  |  **No**  |     |

DEFINITELY just one single document (and file) for document submission
and canonical representation.


More information about the rfc-interest mailing list