One document matched: draft-rfc-image-files-00.xml
<?xml version="1.0" encoding="UTF-8"?>
<!-- 00b circulated to rfc ed board list
00c developed from Aaron's comments, circulated to Jim Schaad
00d Jim's corrections, plus corrections made after Bob Braden's
notes on 20080725
00e Corrected external reference text
00f Added Acknowledgements
01 Braden hacked at it
-->
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!ENTITY rfc2119 PUBLIC ''
"http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml">
<!ENTITY rfc2223 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.2223.xml'>
<!ENTITY rfc3743 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.3743.xml'>
<!ENTITY rfc3778 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.3778.xml'>
<!ENTITY rfc4748 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.4748.xml'>]>
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<?rfc compact="yes"?>
<?rfc subcompact="no" ?>
<?rfc toc="yes"?>
<?rfc symrefs="yes"?>
<?rfc sortrefs="yes"?>
<!-- Expand crefs and put them inline -->
<?rfc comments='yes' ?>
<?rfc inline='yes' ?>
<rfc docName="draft-rfc-image-files-00.txt" ipr="full3978"
updates="2223"> <!-- category="info" ?, but note 2119 stuff -->
<front>
<title abbrev="Images in RFCs">
Images in RFCs </title>
<author initials="R." surname="Braden" fullname="Robert Braden">
<organization>USC/ISI</organization>
<address>
<postal>
<street>4676 Admiralty Way</street>
<city>Marina del Rey</city> <region>CA</region> <code>90292</code>
<country>USA</country> </postal>
<phone>+1 310 448 9173 </phone>
<email>braden@isi.edu</email>
</address>
</author>
<author initials="J.C." surname="Klensin" fullname="John C Klensin">
<organization/>
<address>
<postal>
<street>1770 Massachusetts Ave, #322</street>
<city>Cambridge</city> <region>MA</region> <code>02140</code>
<country>USA</country> </postal>
<phone>+1 617 491 5735 </phone>
<email>john-ietf@jck.com</email>
</address>
</author>
<date month="August" year="2008" day="22"/>
<keyword>RFC</keyword>
<keyword>Images</keyword>
<keyword>Pictures</keyword>
<abstract>
<t> Documents in the RFC series normally use only
plain-text ASCII characters and a fixed-width font.
However, there is sometimes a need to supplement the
ASCII text with graphics or picture images. The
historic solution to this requirement, allowing
secondary PDF and Postscript files, is seldom used
because it is awkward for authors and
publisher. This memo sugests a more
convenient scheme for
attaching authoritative diagrams, llustrations, or
other graphics to RFCs.
</t>
</abstract>
</front>
<middle>
<section title="Introduction">
<t> Published documents in the RFC series normally use
only plain-text ASCII
characters and a fixed-width font
<xref target="RFC2223"/>.
This simple convention has the
advantage of a stable encoding for which a wide variety
of tools are readily available for viewing, searching,
editing, etc..</t>
<t> Inclusion of diagrams, state machines,
and other graphics in RFC text has generally relied
on the imaginative use of ASCII characters ("ASCII artwork".)
However, in a few cases over the years, ASCII artwork has
been inadequate for images needed or desired in RFCs.
The old solution to this dilemma has been to allow
three versions of an RFC: a primary ASCII version
and secondary versions that are
encoded using PDF and Postcript. The PDF and
Postscript versions are "complete",
containing a copy of the text as well as the full images
<xref target="RFC2223"/>. The textual content and
layout of the PDF/PS version is required to match the base
version as closely as possible. However, the ASCII text
version is considered the official expression of the RFC,
and it is always normative for standards track documents.
We will refer to this
old approach as ".txt+.pdf+.ps" encoding. </t>
<t> The three versions of an RFC using .txt+.pdf+.ps encoding are
in separate files in the primary RFC repository
(http://www.rfc-editor.org/rfc/"), with suffixes
".txt", ".pdf", and ".ps". The RFC Editor
search engine returns links to all three versions
when they are present in the repository.</t>
<t> Unfortunately, the .txt+.pdf+.ps scheme has been awkward
for both editor and author, and it is error-prone, so it
has seldom been used (roughly 50 out of 5000+ RFCs).
The problem is that, in general, only the author has the
tools to prepare the PDF and Postscript versions. The RFC
Editor edits (only) the primary text version, and then
the author must incorporate all the resulting
changes into the PDF/PS version while maintaining the "look" of
the RFC to the extent possible. There is no practical way
for the RFC Editor to verify that this is done correctly,
perhaps leading to editorial errors and usually lengthening
publication time for these documents.
</t>
<t>
This memo suggests a much better
scheme for including figures, illustrations, and
graphics to an RFC. We hope that the method proposed
here will solve the image problem for RFC publication,
although the .txt+.pdf+.ps approach would still be
possible (and in any case, RFCs using the historic
scheme will continue to exist in the RFC repository
forever).</t>
</section>
<section title="A New Scheme for Images">
<t>Under our scheme, an RFC may be either a single ASCII
file as commonly used today, or a composite of two files:
an ASCII-only "base file" containing the text of the
RFC, and an "image file". When present, the image file
would be a PDF file that contained only images, captions, and
title information. Neither file of the composite
would be complete without the
other, and a reference to the RFC would be considered
a reference to both files. An RFC would then be
a logical entity whose complete representation could require
two files, base and image.</t>
<t>The base file would be formatted exactly like current
ASCII RFCs, with three minor exceptions described below.
</t>
<t>The intellectual property
boilerplate in the base file
("Rights in Contributions <xref target="RFC4748">BCP
78, RFC 4748</xref> ) would apply equally to the
image file.
An image file would contain one or more items that will
be known collectively as "figures", whether they are
actually diagrams, pictures, tables, artwork, or other
non-textual constructions.</t>
<t> This scheme was inspired by the tradition in
book publishing, where pictures, figures, or "plates"
may be grouped together following the text ("end
figures"), or even bound separately from the main body
of the text.
<!--
If the approach of this document is adopted, terms like
"the RFC" will refer to the combination of the base RFC
file and an image file if the latter is supplied. Note
that just as with the .txt+.pdf+.ps encoding, an RFC is
a logical entity whose complete representation requires
multiple files.
-->
</t>
<t>In principle, we could allow an image file to be encoded
using both PDF and Postscript, since mechanical translation is
possible in both directions. However, in the 20 years since
the adoption of the .txt+.pdf+.ps scheme, the PDF format
has become a defacto standard for electronic documents,
and readers for it are universally available. Furthermore,
PDF is being standardized as a format for document
archiving, as discussed further in the next
section. Therefore, we propose to allow only PDF for
image files, simplifying the new approach by not
including a Postscript file option.</t>
<t>An ASCII RFC traditionally uses a file name in the form of
"rfcN.txt", where N is integer RFC number without
leading zeros. The
image file that is associated with RFC number N could
be named "rfcN.img.pdf". As noted earlier, the
repository contains RFCs with file names
"rfcN.ps" and "rfcN.pdf", using the historic
.txt+.pdf+.ps scheme.</t>
</section>
<section title="Construction of the Image File">
<t>An image file would be a single PDF file, consistent
with the description in <xref target="RFC3778"/> and
defined in <xref target="ISO32000-1"/>. The
particular PDF form must be version-stable and must
not contain any external references in scripts
or otherwise. Those requirements are satisfied
by the <xref target="ISO19005-1"> PDF/A </xref>
profile. The RFC Editor may authorize other
variants of PDF in the future.</t>
<t>There is an issue of whether particular generators of
PDF that claim to satisfy PDF/A actually do so.
Future experience may require published guidelines
on PDF-generating software that claims to satisfy
PDF/A but does not.</t>
<t>Except as otherwise specified in this document, an
image file should contain only figures,
supporting labels and captions, headers, and
footers. It should not contain
explanatory text or other materials that could
reasonably be expressed in plain-text form in
the base file</t>
<t>Pages of the image file would be consecutively
numbered. The first
page number of the image file would follow the
last page number of the base RFC, exclusive of
the number of the end-of-RFC boilerplate page.
The page number of the end-of-RFC boilerplate
(in the base RFC file) would be the first page
number after those in the image file.
Each page of the image file would contain the
same headers and footers as the base file, except
for one change in the footer, suggested below.</t>
<t>Figures included in the image file would have to be
labeled in a fashion that facilitated
referencing from the base RFC. They should
normally be numeric and monotonic.
Simple consecutive integer will usually be the
best choice, but in some cases it might be
desirable to use a hierarchical scheme like:
<section #>.<fig #>. An author who
believes that another labeling scheme would
increase clarity should check with the RFC
Editor. </t>
</section>
<section title="Requirements for the Base File">
<section title="Overview">
<t>A base file would be unchanged by the presence of an image file,
except for the following.</t>
<t>
<list style="symbols">
<t>The page number of the end-of-RFC boilerplate page
would be changed to be logically one page after the
last image file page.</t>
<t>A new unnumbered "Figures" section would be required.
This is described below.
</t>
<t>For a composite RFC, a minor modification to the
first-page header of the base file and to the footers
of both base and image files could tie the two files
together. This is described below.
</t>
</list>
</t>
</section>
<section title="Figures Section">
<t>An RFC that used this scheme (and had any figures) would need to include a
Figures section in the ASCII base file.
The Figures section should immediately following the
Table of Contents, if any, and precede the
body of the document. The Figures section
should list all figures in tabular form,
indicating for each one the figure
identification, title, and page number(s).</t>
<t>The style for the Figures section has not yet been
fully specified. Here is a suggested example.</t>
<t>
<artwork>
___________________________________________________________________________
Table of Contents
1. Introduction .................................................... 1
2. Philosophy ...................................................... 7
2.1 Elements of the Internetwork System ........................ 7
2.2 Model of Operation ......................................... 8
2.3 The Host Environment ....................................... 8
(etc)
Figures
Figure 1: Protocol Layering . ..................................... 2
Figure 2: Protocol Relationships .................................. 9
Figure 3: TCP Header Format .................................. 15, *86
Figure 4: Send Sequence Space ..................................... 20
Figure 5: Receive Sequence Space .................................. 20
Figure 6: TCP Connection State Diagram ....................... 23, *87
Figure 7: Basic 3-Way Handshake for Connection Synchronization 31, *88
(etc)
*Page in Image file
(Page 1 follows)
___________________________________________________________________________
</artwork>
</t>
<t>An RFC that includes a base file may include
ASCII artwork that is
suggestive of a figure in the image file, but there is no
requirement to do so. When such an approximate figure appears
as ASCII artwork in the base file, its figure identification
and caption must match those of the corresponding figure
in the image file, and the entry in the Figures table should
specify the page numbers in both the base and image file,
In the example shown above, image file page
numbers are marked with an asterisk. Note that very
simple ASCII artwork need not appear in the image file.</t>
</section>
<section title="Formatting Changes">
<t>It would be necessary to tie the base and image files
together, to make clear they are part of one RFC. Here is an
initial suggestion for formatting, which needs further
consideration before it is adopted.</t>
<t><list>
<t>The header line "Request for Comments: nnnn" in the base file
could be changed to "Request for Comments: nnnn/Base".
For consistency, the lefthand footer could become
"RFC nnnn/Base".
The lefthand footer in the image file could then be:
"RFC nnnn/Image.
</t><t>
The following sentence could be placed in the "Status of this Memo"
section: "This RFC is a composite of this base file and a PDF
image file."
</t></list>
</t>
</section>
</section>
<section title="Submission and Processing of the Image File">
<t>If an image file is needed, it should be submitted
as an .img.pdf file along with the ASCII text file.
The image file should be submitted
without headers or footers. The RFC Editor will
overlay the image file with the appropriate headers and
footers, with correct pagination. The RFC Editor will
not normally do any editing of the image file beyond
this. If editing the base file reveals problems with
figures in the image file, the authors will be asked to
create a new image file.
</t>
</section>
<section title="Implementation Issues">
<t>This acheme has a number of implications.
<list style="numbers">
<t>
The Internet Draft repository must allow submission and
retrieval of both base and (when present) image files.</t>
<t>Internet Draft file names could be draft-...-vv.txt and
(optionally) draft-...-vv.img.pdf, where "vv" is the normal
version number. Updating either file of the composite RFC
should increase the version numbers "vv" in both files. We DO
NOT want two separate version numbers for one I-D</t>
<t>The RFC Editor would need to be able to overlay headers, footers,
and page numbers on a given image file. It is claimed that
at least Adobe Acrobat Professional includes this capability, and that it
also has limited editing capability.</t>
<t>The RFC Editor would also need a tool to verify that a given
image file satisfies the constraints of PDF/A.</t>
<t>Some RFC Editor scripts and tools would need small extensions.
</t>
<t>Some small extensions to xml2rfc to include image files would
be useful. It should generate the boilerplate with a
non-sequential page number. For example, an attribute on
<back>, might specify the number of pages of image file.
One could presumably add a mechanism to generate the Figures
section.</t>
</list>
</t>
</section>
<section title="RFC Repository File Formats">
<t>A frequent reaction to the suggestion given in this memo is some
confusion over the different file formats that appear in the
RFC repository. Here is a brief summary.</t>
<t>If a PDF image file exists along with a base ASCII RFC,
then RFCs in any other format (e.g., complete PDF files,
HTML, or Postscript) remain supplemental, with the reader
taking responsibility for assuring that they are equivalent
to the base RFC and image file. That arrangement is
identical to the relationship between traditional all-ASCII
RFCs and supplemental forms: the RFC Editor has never taken
responsibility for guaranteeing that the two are identical
in content.</t>
<t>The existing .txt.pdf files are not affected by
this proposal. The .txt.pdf files are facsimiles of .txt (base
files) in PDF, introduced to help Windows users read RFCs
online. However, Microsoft has more recently provided
an elementary ASCII editor, which probably makes the
.txt.pdf files unnecessary in any case.</t>
<t>In summary:</t>
<t>
<list style="symbols">
<t>.txt: ASCII-only file. In old scheme, complete normative file.
In new scheme, text part of composite RFC, or stand-alone
text file.</t>
<t>.ps: Old scheme -- a Postscript file that includes
figures and whose text is intended to be the same as
the normative .txt file.</t>
<t>.pdf: Old scheme -- a PDF file that includes
figures and whose text is intended to be the same as
the normative
.txt file.</t>
<t>.img.pdf: New scheme: image file part of a composite with .txt file.</t>
<t>.txt.pdf: Old scheme: Facsimile of corresponding .txt file.</t>
</list>
</t>
<t>
We note that it would be possible to combine the base and
image files into a single PDF file, which would have to
follow a naming convention to distinguish it from the
.pdf case listed above. However, we regard this an
an undesirable step away from the principle of universal
ASCII encoding of the text of the document.</t>
</section>
<section title="Internationalization Considerations">
<t>Our scheme of image files does not, and is not
intended to, support character set internationalization
for RFCs. It does not allow an author to omit the
ASCII text from the base file and instead include
the entire RFC text as
one (very large) image file.</t>
<t>
However, we should note two special cases.
<list style="numbers">
<t> RFC 3743 <xref target="RFC3743"/> on internationalized
domain names for Chinese, Japanese,, and Korean
contains a number of examples that may be
hard to follow because they can represent those characters only
in "U+nnnn" form. An image file could be used that would show
the alternative Chinese characters for the examples. This
would not diminish either the ability to search the base text
or index the document or its readability for those of us for
whom reading Chinese characters is difficult, but it should
help those who can read them.</t>
<t> Suppose that a proposed RFC contained a section
derived from Japanese text. The author might put an English
translation into that section of the base document, note that
the original was really in Japanese, and attach the Japanese as
an appendix in an image file. This should raise no
difficulties for informative documents. For normative
documents, however, the existence of the Japanese original
would raise some issues about what was actually authoritative,
which is very undesirable.</t>
</list>
</t>
</section>
<section title="Security Considerations">
<t>This specifications addresses documentation standards and
adding additional flexibility to them. It does not, in
general, raise any security issues. However, unless the
specifications of this document are carefully followed, the
image format recommended, PDF, may potentially contain
external references or scripts that could introduce security
problems. The RFC Editor and other publishers should
exercise due care to ensure that no such references or
scripts appear in the archives. </t>
</section>
<section title="IANA Considerations">
<t> This document requires no actions by the IANA.</t>
</section>
<section title="Acknowledgments" anchor="Acknowledgments">
<t> The impetus for this specification arose during a discussion during
an RFC Editorial Board meeting in the aftermath of one of the
IETF's seeming-interminable discussions about allowing RFC's in
"modern" formats. Aaron Falk made several specific suggestions
that have been reflected in the document. The RFC Editor staff
and other Editorial Board members contributed suggestions
without which this version would not have been possible.</t>
</section>
</middle>
<back>
<references title="Normative References">
<!-- &rfc2119; <!-- conformance terms -->
&rfc0020; <!-- US_ASCII definition -->
&rfc2223; <!-- RFC Guidelines -->
&rfc3778; <!-- PDF media type -->
&rfc4748; <!-- IPR -->
</references>
<references title="Informative References">
&rfc3743; <!-- internationalized names -->
<reference anchor="ISO32000-1">
<front>
<title>Document management -- Portable document format --
Part 1: PDF 1.7</title>
<author>
<organization>International Organization for
Standardization (ISO)</organization>
</author>
<date year="2008"/>
</front>
<seriesInfo name="ISO" value="32000-1:2008"/>
<!-- ISO TC171/SC2,
http://www.iso.org/iso/iso_catalogue/catalogue_tc/catalogue_detail.htm?csnumber=51502
-->
</reference>
<reference anchor="ISO19005-1">
<front>
<title>Document management -- Electronic document file
format for long-term preservation -- Part 1: Use of PDF
1.4 (PDF/A-1)</title>
<author>
<organization>International Organization for
Standardization (ISO)</organization>
</author>
<date year="2005"/>
</front>
<seriesInfo name="ISO" value="19005-1:2005"/>
<!-- ISO TC171/SC2,
http://www.iso.org/iso/iso_catalogue/catalogue_tc/catalogue_detail.htm?csnumber=38920
-->
</reference>
</references>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-23 10:05:21 |