[rfc-i] only sort of about issue: canonical formats

Ole Jacobsen ole at cisco.com
Fri Jun 1 11:42:36 PDT 2012


I like your example because it addresses at least one point that seems
relevant to our RFC discussion: pagination. When the text was copied 
into the book, starting on page 370 and continuing on page 371, the
original pagination (assuming for the sake of argument there was any)
was "lost" or at least "reordered", but since the document starts with
a (hopefully unambiguous) title, it doesn't matter, we can point to
the item in question, either as a stand-alone document or as an entry
in a book with or without page numbers.

One point about graphics: When authors submit articles for publication
in my journal, I typically ask for some kind of source file (plain 
text or Word most usually) as well as a "pretty" PDF file where the
graphics are included in the right places vis a vis the text. If the
graphics files are included separately, I ask that the figure captions
be included both in the graphics file itself and in the text, just to
avoid and mis-placement of the graphics. Copy editors tell me that
the text SHOULD (or maybe MUST) refer to the graphics in some way 
("...as shown in Figure 1 ..." or "...as shown in Figure 1 below ..."
If we were to switch from ASCII art to some more modern form of 
drawings, I think it would be important to insist that the caption
and title be somehow retained with the graphic file(s) to avoid any

Meta-comment: I read most of my e-mail using pine, or actually alpine, 
a decidedly text-only mail program. This means that I cannot see any 
formatting, color, style and indeed graphics in any message received 
unless I take special steps. This is mostly fine and mostly doesn't 
cause any confusion because I *know* that there exist a "richer" 
version of the message that I can display if I so choose. I can 
imagine doing exactly the same thing with an RFC. If my device is 
unable to display anything other than US ASCII, I can still read the 
text and (maybe) the ASCII art depending on how badly it has been 
reflowed etc.

I agree with PHB that ASCII art is a very limiting and annoying format 
to have to deal with and I would hope that we could find some way to
incorporate "real" graphics. I don't buy the argument that we (the 
IETF and the rest of the RFC "clientelle") only deal with things that
can be expressed fully with words, especially since the scope of the
IETF seems to be constantly expanding. As I have said before, I see
no reason why it should not be possible---or would not be helpful---
to be able to include a diagram/pinout/spec for something like a
connector even if "we" are not the party that defines the connector.


Ole J. Jacobsen
Editor and Publisher,  The Internet Protocol Journal
Cisco Systems
Tel: +1 408-527-8972   Mobile: +1 415-370-4628
E-mail: ole at cisco.com  URL: http://www.cisco.com/ipj
Skype: organdemo

More information about the rfc-interest mailing list