[rfc-i] Big Picture and RFC format

Phillip Hallam-Baker hallam at gmail.com
Fri Jun 1 10:15:44 PDT 2012


I am not that bothered by the ability to support diagrams PROVIDED THAT WE
GET RID OF ALL ASCII ART

I mean it. ASCII art sucks rocks. It is totally incomprehensible to
decipher and takes hours to create and the arguments over it are worse.

I can accept the argument that we don't need ANY diagrams ever. But those
ASCII art monstrosities have to go.

The only decent ASCII art is the famous 'figure 1' from the DEC support
guide.


If the people who are saying 'we don't need diagrams' are then going to
suggest that we can make do with ASCII art then I think its quite clear
that they are making a silly argument.

On Thu, May 31, 2012 at 12:38 PM, Heather Flanagan (RFC Series Editor) <
rse at rfc-editor.org> wrote:

> On 5/31/12 9:18 AM, Ole Jacobsen wrote:
> >
> > Before we can measure consensus I would like to see a "bigger picture"
> > discussion of what it is exactly we are trying to achieve. It has been
> > suggested, for example, that "real graphics," (maybe line drawings as
> > the ones found in patent applications) are "highly desirable," but I
> > have not seen much discussion about this as functional "requirement"
> > (and I use that word loosely). Instead, I see a lot of detailed
> > technical discussion about HTML, XML and the like, all important
> > stuff, but to me these are "engineering details" and not overall
> > design and architecture discussions.
> >
>
> Hi Ole,
>
> I think this is reasonable.  I actually started to write down something
> along these lines for myself, and I still consider it a work in
> progress.  I'm still learning new things about how the Series has been
> used and could be used.
>
> Here are the notes I have for myself, currently in progress on the RSE
> wiki.  Is this the kind of information you are looking for?
>
> ---
> The RFC Series has been in existence for over 40 years. During much of
> that time, the limitations of character set, line and page length, and
> graphics restrictions of RFC documents met the most immediate needs of
> the majority of authors and readers. As technology changed, new formats
> that allowed for a richer set of features when editing, reading,
> searching, and displaying documents came in to use and tools were
> created to convert the plain ASCII documents in to other desired formats
> such as HTML, PDF, and Microsoft Word. While the converted versions of
> the RFC are widely available, the canonical display format remains the
> plain text, ASCII, line-printer structured one. The canonical source
> format is nroff.
>
> Canonical source and display versions of an RFC exists for several reasons:
>
>  * to provide verification of the content of a RFC in case
> inconsistencies are created when a document is converted to another
> format or mirrored to another location
>  * to verify the final content of a document in cases of legal dispute
>  * to aid in the conversion of the RFC in to formats requested by the
> community
>
> The very basic format of RFC source and display documents have two
> persistent characteristics that are considered by the RFC Series Editor
> to be critical to the RFC Series, including:
>
>  * persistence (tools to read, edit, and print the documents remain
> easily accessible to everyone)
>  * convertibility (the plain text version is simple to convert to other
> formats)
>
> That said, the very simple nature of the current display format in
> particular introduces a variety of limitations, the list of which has
> grown as changes in technology create new expectations:
>
>  * ASCII art is considered by some to be a major limitation in
> expressing visually-oriented information
>  * the internationalization of the authorship and the Internet is
> introducing characters not possible in plain ASCII
>  * the more common forms of display (web pages, smaller devices) make
> the limitations of page and line length a hindrance to the reading of an
> RFC
>
> So, the community and the RFC Editor have decided to review the
> canonical format of the RFC series and discuss whether it needs to
> change to address those limitations and, if change is required, what the
> change should look like.
> _______________________________________________
> rfc-interest mailing list
> rfc-interest at rfc-editor.org
> https://www.rfc-editor.org/mailman/listinfo/rfc-interest
>



-- 
Website: http://hallambaker.com/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.rfc-editor.org/pipermail/rfc-interest/attachments/20120601/59e7f582/attachment.htm>


More information about the rfc-interest mailing list