[rfc-i] only sort of about issue: canonical formats
Ole Jacobsen
ole at cisco.com
Fri Jun 1 11:42:36 PDT 2012
John,
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
confusion.
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
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