[rfc-i] draft-iab-rfcformatreq-01: fixed-width != ASCII

Heather Flanagan (RFC Series Editor) rse at rfc-editor.org
Thu Jan 24 17:35:34 PST 2013

On 1/23/13 8:38 AM, Brian E Carpenter wrote:
> On 23/01/2013 14:57, Paul Hoffman wrote:
>> On Jan 23, 2013, at 12:37 AM, Brian E Carpenter <brian.e.carpenter at gmail.com> wrote:
>>>> So, the fact that the RFC Editor currently publishes in a monospaced
>>>> font has historic weight but is not actually a documented requirement.
>>> Yes, but it's a de facto requirement (as Nico says, strongly implied
>>> by the use of ASCII art).
>> No, it is not. 
> Apparently I was unclear. It is a de facto requirement today for today's
> canonical format**. It isn't a de jure requirement, in the sense that no
> version of style guide actually states it.
>> It is a requirement *for ASCII art only*. In a display format that supports multiple fonts, monospace is only needed there (and maybe for headings that are centered in renderers that are width-dependent).
>>> I think it's a de facto requirement and I'm pretty sure we're proposing
>>> to drop it.
>> Some of us have proposed to drop it where it is not needed.
> Sure. That's a very reasonable proposal if we want to continue to
> use ASCII art, but as Wes says it would call for a metadata tag.
> My point is that the draft is silent on this point and IMHO it shouldn't be.

I have a few concerns: Given that individuals can set their preferences
for font for many of the potential Publication formats discussed, I
hesitate to declare that RFCs must be read in any particular named font.
 I also feel that any discussion on the pro's and con's of any given
font is the kind of bike shedding that will not help this discussion in
any way.  So, I propose to have the existing requirement listed in the
draft to cover the question of font at this time:

      *  Fixed-width fonts and non-reflowable text are required for
         ASCII-art sections, source code examples, and other places
         where strict alignment is required.

I think that provides the necessary implementation guidance needed for a
Canonical format.  For Publication formats, we may end up having a
slightly longer conversation.



More information about the rfc-interest mailing list