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

Heather Flanagan (RFC Series Editor) rse at rfc-editor.org
Thu May 31 08:26:29 PDT 2012


Hi all -

I leave the country and come back to over 400 messages in rfc-i.  I'm
impressed and look forward to the time when I'm familiar enough with the
community that I can effectively share my sense of humor about it all.

I think the 400+ messages contain a subtle clue that we are not entirely
in consensus on the requirements for a new format. There also seems to
be ongoing confusion regarding a canonical source format versus a
canonical display format.  To be clear, the canonical source format for
RFC is currently nroff.  If you turn in an XML file, the editors convert
it to nroff.   We keep copies of the xml files when provided, but they
are not what the canonical, authoritative, used-by-lawyers display
format is created from - that's nroff.  The canonical display format is
currently plain text ASCII.  We are  currently discussing both, with
most people focusing on the canonical display format.  That's fine, they
are interconnected issues, but I suggest being clear when you are
discussing a particular point that you be explicit when you are talking
display versus source file. 

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:

Consensus reached:
| Need to be able to update documents easily and see how they might look
when published  |  Yes  |      |
| Need to be able to create new documents by hacking away at older ones
|  Yes  |   |
| Need be able to diff versions of a draft  |  Yes  |   |
| Need format to be easily rendered in to other, potentially undefined
formats (.txt, .html, other)  |  Yes  |   |
| Need to be able to search document and document repositories with
tools such as *grep  |  Yes  |   |
| Want a more flexible line length  |  Yes  | [RSE] should be rephrased
to state want to make the new format display reasonably well on a
variety of screen sizes  |
| Need source file to be editable by both authors and RFC editors    | 
Yes  | Consensus within RFC Editor    |
| Want a single, discrete source file for a draft (not multiple files
and a make file) |  Yes  |   |
| Want a publicly available "official" conversion tool (same source file
producing the same output between I-D submission and RFC editing step)
|  Yes  |    |
| Need source format to be easily rendered in to other, potentially
undefined formats (.txt, .html, other)    |  Yes  |        |
| Need one source and display format to be the authoritative version,
suitable for legal records  |  Yes  |   |
| Need to be able to create new documents by hacking away at older ones 
|  Yes  |   |
| Need backward compatibility to recreate documents originally created
in an older version of the output tools (backward compatibility issue
doesn't apply to docs published prior to the format change)  |  Yes  |   |
| Need a long-lived file format with an open specification, i.e., such
that the community can continue to support it even if commercial support
disappears  |  Yes  |    |
| Need to be able to search document and document repositories with
tools such as *grep  |  Yes  |     |
| Need to be able to create new documents by hacking away at older ones 
|  Yes  |   |
| Want to have neat printing (intelligent pagination)  |  Yes  |  [RSE]
But there is disagreement as to what that would actually look like and
how it would be accomplished |

(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.      |
| 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)   |
| Want broader character encoding for body of document  |  **No**  |   |
| Want the ability to denote protocol examples using the character sets
those examples support  |  **No**   |   |
| Want the ability to semantically tag some document info, at least
authors' names and references  |  **No**  |  |
| Want to be able to include equations |  **No**   |   |
| Want to be able to tag ownership/source of comments  |  **No**  |  |
| Need to be able to see non-ASCII graphics/images    |  **No**  |       |
| Want intelligent html-style linking within references  |  **No**  |   |
| Want the RFC to be suitable for small screens/mobile devices  | 
**No**  |     |
| Want to be able to view equations  |  **No**  |    |
| Want a more flexible line length  |  **No**  |    |
| Want a single document to view (should not have to jump between two
documents for complete information)  |  **No**  |     |


As one might expect, I'm particularly concerned about where it feels
that consensus has not been reached.  A bit of focused discussion on
these items will be helpful.

-Heather Flanagan, RSE


More information about the rfc-interest mailing list