draft-rfc-image-files-00.txt   draft-crocker-rfc-media-00.txt 
Network Working Group R. Braden RFC D. Crocker
Internet-Draft USC/ISI Internet-Draft Brandenburg InternetWorking
Updates: 2223 (if approved) J. Klensin Intended status: Standards Track August 27, 2008
Expires: February 23, 2009 August 22, 2008 Expires: February 28, 2009
Images in RFCs Media Format Choices for RFCs
draft-rfc-image-files-00.txt draft-crocker-rfc-media-00
Status of this Memo Status of this Memo
By submitting this Internet-Draft, each author represents that any By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79. aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
skipping to change at page 1, line 34 skipping to change at page 1, line 34
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on February 23, 2009. This Internet-Draft will expire on February 28, 2009.
Copyright Notice
Copyright (C) The IETF Trust (2008).
Abstract Abstract
Documents in the RFC series normally use only plain-text ASCII Documents in the RFC series normally use only plain-text ASCII
characters and a fixed-width font. However, there is sometimes a characters and a fixed-width font. However, there is sometimes a
need to supplement the ASCII text with graphics or picture images. need to supplement the ASCII text with graphics or picture images.
The historic solution to this requirement, allowing secondary PDF and The historic solution to this requirement, allowing secondary PDF and
Postscript files, is seldom used because it is awkward for authors Postscript files, is seldom used because it is awkward for authors
and publisher. This memo sugests a more convenient scheme for and publisher. This memo suggests a more convenient scheme for
attaching authoritative diagrams, llustrations, or other graphics to attaching authoritative diagrams, illustrations, or other graphics to
RFCs. RFCs. It further proposes conventions for additional input and
display formats, to improve readability. This proposal is based on
draft-rfc-image-files-00, by Braden and Klensin, and revises it as
little as possible, while expanding the goals of the effort.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. A New Scheme for Images . . . . . . . . . . . . . . . . . . . 4 1.1. Goals . . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Construction of the Image File . . . . . . . . . . . . . . . . 4 2. A New Scheme for Representation . . . . . . . . . . . . . . . 5
4. Requirements for the Base File . . . . . . . . . . . . . . . . 5 3. Construction of the Image File . . . . . . . . . . . . . . . . 6
4.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . 5 4. Requirements for the Base File . . . . . . . . . . . . . . . . 7
4.2. Figures Section . . . . . . . . . . . . . . . . . . . . . 6 4.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . 7
4.3. Formatting Changes . . . . . . . . . . . . . . . . . . . . 7 4.2. Figures Section . . . . . . . . . . . . . . . . . . . . . 7
5. Submission and Processing of the Image File . . . . . . . . . 7 4.3. Formatting Changes . . . . . . . . . . . . . . . . . . . . 8
6. Implementation Issues . . . . . . . . . . . . . . . . . . . . 7 5. Submission and Processing of the Image File . . . . . . . . . 9
7. RFC Repository File Formats . . . . . . . . . . . . . . . . . 8 6. Implementation Issues . . . . . . . . . . . . . . . . . . . . 9
8. Internationalization Considerations . . . . . . . . . . . . . 9 7. RFC Repository File Formats . . . . . . . . . . . . . . . . . 10
9. Security Considerations . . . . . . . . . . . . . . . . . . . 9 8. Internationalization Considerations . . . . . . . . . . . . . 10
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 9. Security Considerations . . . . . . . . . . . . . . . . . . . 11
11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 10 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11
12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10 11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 11
12.1. Normative References . . . . . . . . . . . . . . . . . . . 10 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 11
12.2. Informative References . . . . . . . . . . . . . . . . . . 10 Intellectual Property and Copyright Statements . . . . . . . . . . 13
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 11
Intellectual Property and Copyright Statements . . . . . . . . . . 12
1. Introduction 1. Introduction
Published documents in the RFC series normally use only plain-text Published documents in the RFC series normally use only plain-text
ASCII characters and a fixed-width font [RFC2223]. This simple ASCII characters and a fixed-width font [RFC2223]. This simple
convention has the advantage of a stable encoding for which a wide convention has the advantage of a stable encoding for which a wide
variety of tools are readily available for viewing, searching, variety of tools are readily available for viewing, searching,
editing, etc.. editing, etc.
Inclusion of diagrams, state machines, and other graphics in RFC text Inclusion of diagrams, state machines, and other graphics in RFC text
has generally relied on the imaginative use of ASCII characters has generally relied on the imaginative use of ASCII characters
("ASCII artwork".) However, in a few cases over the years, ASCII ("ASCII artwork".) However, in a few cases over the years, ASCII
artwork has been inadequate for images needed or desired in RFCs. artwork has been inadequate for images needed or desired in RFCs.
The old solution to this dilemma has been to allow three versions of The old solution to this dilemma has been to allow three versions of
an RFC: a primary ASCII version and secondary versions that are an RFC: a primary ASCII version and secondary versions that are
encoded using PDF and Postcript. The PDF and Postscript versions are encoded using PDF and Postscript. The PDF and Postscript versions
"complete", containing a copy of the text as well as the full images are "complete", containing a copy of the text as well as the full
[RFC2223]. The textual content and layout of the PDF/PS version is images [RFC2223]. The textual content and layout of the PDF/PS
required to match the base version as closely as possible. However, version is required to match the base version as closely as possible.
the ASCII text version is considered the official expression of the However, the ASCII text version is considered the official expression
RFC, and it is always normative for standards track documents. We of the RFC, and it is always normative for standards track documents.
will refer to this old approach as ".txt+.pdf+.ps" encoding. We will refer to this old approach as ".txt+.pdf+.ps" encoding.
The three versions of an RFC using .txt+.pdf+.ps encoding are in The three versions of an RFC using .txt+.pdf+.ps encoding are in
separate files in the primary RFC repository separate files in the primary RFC repository
(http://www.rfc-editor.org/rfc/"), with suffixes ".txt", ".pdf", and (http://www.rfc-editor.org/rfc/"), with suffixes ".txt", ".pdf", and
".ps". The RFC Editor search engine returns links to all three ".ps". The RFC Editor search engine returns links to all three
versions when they are present in the repository. versions when they are present in the repository.
Unfortunately, the .txt+.pdf+.ps scheme has been awkward for both 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 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, (roughly 50 out of 5000+ RFCs). The problem is that, in general,
only the author has the tools to prepare the PDF and Postscript only the author has the tools to prepare the PDF and Postscript
versions. The RFC Editor edits (only) the primary text version, and versions. The RFC Editor edits (only) the primary text version, and
then the author must incorporate all the resulting changes into the then the author must incorporate all the resulting changes into the
PDF/PS version while maintaining the "look" of the RFC to the extent 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 possible. There is no practical way for the RFC Editor to verify
that this is done correctly, perhaps leading to editorial errors and that this is done correctly, perhaps leading to editorial errors and
usually lengthening publication time for these documents. usually lengthening publication time for these documents.
This memo suggests a much better scheme for including figures, This memo suggests a much better scheme, for including figures,
illustrations, and graphics to an RFC. We hope that the method illustrations, and graphics to an RFC, as well as for maintaining a
proposed here will solve the image problem for RFC publication, single copy of base text which can be turned into multiple
although the .txt+.pdf+.ps approach would still be possible (and in presentation forms. We hope that the method proposed here will solve
any case, RFCs using the historic scheme will continue to exist in the image problem for RFC publication, although the .txt+.pdf+.ps
the RFC repository forever). approach would still be possible (and in any case, RFCs using the
historic scheme will continue to exist in the RFC repository
forever).
2. A New Scheme for Images This proposal is based on draft-rfc-image-files-00, by Braden and
Klensin, and revises it as little as possible. As an expedient, the
References section has been omitted from this initial version of the
draft.
1.1. Goals
The list of goals in the current proposal expands upon the ones of
the draft-rfc-image-files-00 proposal:
1. There is a single, master file for document text.
2. Base text is able to be edited, viewed, compared and searched
with extremely minimal set of tools, such as a classic text
editors, and the like.
3. The master file is subject to formatting constraints, to improve
readability when using simple display tools.
4. All formats use strictly open standards.
5. Any mapping from the master file to a presentation format must
only depend upon well-tested, reliable tools that are available
as open-source.
6. Multiple display forms must be supported, notably scroll-form
for screen display and paginated form for printing, as well as
classic, basic IETF ASCII paginated format.
7. Figures can be encoded in classic ASCII art and/or in a graphics
format.
8. Enhanced display formats can support basic font changes, within
IETF-defined criteria, since this can enhance readability.
9. Naming conventions tightly link additional files that are used
by the master file.
10. Changes seek to have as much automation as possible for the
technical aspects of RFC development and production.
11. Format for the master file should facilitate later revision
efforts.
2. A New Scheme for Representation
Under our scheme, an RFC may be either a single ASCII file as 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 commonly used today, or a composite of multiple files: an ASCII-only
file" containing the text of the RFC, and an "image file". When "base file" containing the text of the RFC, and one or more "image
present, the image file would be a PDF file that contained only files". The ASCII file may optionally conform to xml2rfc format.
images, captions, and title information. Neither file of the When present, the image file would be a {{standard image} file that
composite would be complete without the other, and a reference to the contains only images, captions, and title information. The base file
RFC would be considered a reference to both files. An RFC would then may contain classic "ASCII art" and refer to external image files as
be a logical entity whose complete representation could require two alternatives. An RFC which is displayed in any form other than
files, base and image. simple ASCII would then be a logical entity whose complete, or
preferred, representation could require multiple files, base and
image(s).
The base file would be formatted exactly like current ASCII RFCs, The base file may be formatted exactly like current ASCII RFCs, with
with three minor exceptions described below. three minor exceptions described below. Alternatively, it may be
formatted using xml2rfc. The xml2rfc convention is well-established
within the IETF and RFC community. It permits having a single,
textual document base, which can easily produce .txt+.pdf+.html
formats. In addition, it can contain a text-only version of art,
while using external image files, when available and appropriate to
the output form.
The intellectual property boilerplate in the base file ("Rights in The intellectual property boilerplate in the base file ("Rights in
Contributions BCP 78, RFC 4748 [RFC4748] ) would apply equally to the Contributions BCP 78, RFC 4748 [RFC4748] ) would apply equally to the
image file. An image file would contain one or more items that will image file. An image file would contain one or more items that will
be known collectively as "figures", whether they are actually be known collectively as "figures", whether they are actually
diagrams, pictures, tables, artwork, or other non-textual diagrams, pictures, tables, artwork, or other non-textual
constructions. constructions.
This scheme was inspired by the tradition in book publishing, where This scheme was inspired by the tradition in book publishing, where
pictures, figures, or "plates" may be grouped together following the pictures, figures, or "plates" may be grouped together following the
skipping to change at page 4, line 45 skipping to change at page 6, line 4
.pdf+.ps scheme, the PDF format has become a defacto standard for .pdf+.ps scheme, the PDF format has become a defacto standard for
electronic documents, and readers for it are universally available. electronic documents, and readers for it are universally available.
Furthermore, PDF is being standardized as a format for document Furthermore, PDF is being standardized as a format for document
archiving, as discussed further in the next section. Therefore, we archiving, as discussed further in the next section. Therefore, we
propose to allow only PDF for image files, simplifying the new propose to allow only PDF for image files, simplifying the new
approach by not including a Postscript file option. approach by not including a Postscript file option.
An ASCII RFC traditionally uses a file name in the form of An ASCII RFC traditionally uses a file name in the form of
"rfcN.txt", where N is integer RFC number without leading zeros. The "rfcN.txt", where N is integer RFC number without leading zeros. The
image file that is associated with RFC number N could be named image file that is associated with RFC number N could be named
"rfcN.img.pdf". As noted earlier, the repository contains RFCs with "rfcN.{image name}.{image format extension}". As noted earlier, the
file names "rfcN.ps" and "rfcN.pdf", using the historic .txt+.pdf+.ps repository already contains RFCs with file names "rfcN.ps" and
scheme. "rfcN.pdf", using the historic .txt+.pdf+.ps scheme.
3. Construction of the Image File 3. Construction of the Image File
An image file would be a single PDF file, consistent with the Each image would be in a single {image format} file, containing only
description in [RFC3778] and defined in [ISO32000-1]. The particular that image and consistent with the description in [RFC3778] and
PDF form must be version-stable and must not contain any external defined in [ISO32000-1]. The particular {image format} form must be
references in scripts or otherwise. Those requirements are satisfied version-stable and must not contain any external references in
by the PDF/A [ISO19005-1] profile. The RFC Editor may authorize scripts or otherwise. The RFC Editor authorizes the set of {image
other variants of PDF in the future. formats} that are permitted for use.
There is an issue of whether particular generators of PDF that claim There is an issue of whether particular generators of {image format}
to satisfy PDF/A actually do so. Future experience may require that claim to satisfy {image format standards} actually do so.
published guidelines on PDF-generating software that claims to Future experience may require published guidelines on PDF-generating
satisfy PDF/A but does not. software that claims to satisfy {image format}{image format} but does
not.
Except as otherwise specified in this document, an image file should Except as otherwise specified in this document, an image file should
contain only figures, supporting labels and captions, headers, and contain only a single figure, supporting labels and captions,
footers. It should not contain explanatory text or other materials headers, and footers. It should not contain explanatory text or
that could reasonably be expressed in plain-text form in the base other materials that could reasonably be expressed in plain-text form
file in the base file
Pages of the image file would be consecutively numbered. The first For xml2rfc output that produces .html or .pdf, images are produced
page number of the image file would follow the last page number of inline and are consecutively numbered.
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 For .txt output, pages of the image files would be consecutively
file) would be the first page number after those in the image file. numbered. The first page number of the image file would follow the
Each page of the image file would contain the same headers and last page number of the base RFC, exclusive of the number of the end-
footers as the base file, except for one change in the footer, of-RFC boilerplate page. The page number of the end-of-RFC
suggested below. 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.
Figures included in the image file would have to be labeled in a Figures included in the image file would have to be labeled in a
fashion that facilitated referencing from the base RFC. They should fashion that facilitated referencing from the base RFC. They may be
normally be numeric and monotonic. Simple consecutive integer will numeric and monotonic or it may use textual image names. Simple
usually be the best choice, but in some cases it might be desirable consecutive integer will usually be the best choice, but in some
to use a hierarchical scheme like: <section #>.<fig #>. An author cases it might be desirable to use a hierarchical scheme like:
who believes that another labeling scheme would increase clarity <section #>.<fig #>. An author who believes that another labeling
should check with the RFC Editor. scheme would increase clarity should check with the RFC Editor.
4. Requirements for the Base File 4. Requirements for the Base File
4.1. Overview 4.1. Overview
A base file would be unchanged by the presence of an image file, A base file would be unchanged by the presence of an image file,
except for the following. except for the following.
o The page number of the end-of-RFC boilerplate page would be o For .txt format, the page number of the end-of-RFC boilerplate
changed to be logically one page after the last image file page. page would be changed to be logically one page after the last
image file page.
o A new unnumbered "Figures" section would be required. This is o A new unnumbered "Figures" section would be required. This is
described below. described below.
o For a composite RFC, a minor modification to the first-page header o 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 of the base file and to the footers of both base and image files
could tie the two files together. This is described below. could tie the additional files together. This is described below.
4.2. Figures Section 4.2. Figures Section
An RFC that used this scheme (and had any figures) would need to An RFC that used this scheme (and had any figures) would need to
include a Figures section in the ASCII base file. The Figures include a Figures section in the ASCII base file. The Figures
section should immediately following the Table of Contents, if any, section should immediately following the Table of Contents, if any,
and precede the body of the document. The Figures section should and precede the body of the document. The Figures section should
list all figures in tabular form, indicating for each one the figure list all figures in tabular form, indicating for each one the figure
identification, title, and page number(s). identification, title, and page number(s).
The style for the Figures section has not yet been fully specified. The style for the Figures section has not yet been fully specified.
Here is a suggested example. Here is a suggested example.
___________________________________________________________________________ _________________________________________________________________
Table of Contents Table of Contents
1. Introduction .................................................... 1 1. Introduction ............................................... 1
2. Philosophy ...................................................... 7 2. Philosophy ................................................. 7
2.1 Elements of the Internetwork System ........................ 7 2.1 Elements of the Internetwork System ................... 7
2.2 Model of Operation ......................................... 8 2.2 Model of Operation .................................... 8
2.3 The Host Environment ....................................... 8 2.3 The Host Environment .................................. 8
(etc) (etc)
Figures Figures
Figure 1: Protocol Layering . ..................................... 2 Figure 1: Protocol Layering . ................................ 2
Figure 2: Protocol Relationships .................................. 9 Figure 2: Protocol Relationships ............................. 9
Figure 3: TCP Header Format .................................. 15, *86 Figure 3: TCP Header Format ............................. 15, *86
Figure 4: Send Sequence Space ..................................... 20 Figure 4: Send Sequence Space ................................ 20
Figure 5: Receive Sequence Space .................................. 20 Figure 5: Receive Sequence Space ............................. 20
Figure 6: TCP Connection State Diagram ....................... 23, *87 Figure 6: TCP Connection State Diagram .................. 23, *87
Figure 7: Basic 3-Way Handshake for Connection Synchronization 31, *88 Figure 7: Basic 3-Way Handshake for Connection
Synchronization ................................31, *88
(etc) (etc)
*Page in Image file *Page in Image file
(Page 1 follows) (Page 1 follows)
___________________________________________________________________________ __________________________________________________________________
An RFC that includes a base file may include ASCII artwork that is 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 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 to do so. When such an approximate figure appears as ASCII artwork
in the base file, its figure identification and caption must match in the base file, its figure identification and caption must match
those of the corresponding figure in the image file, and the entry in 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 the Figures table should specify the page numbers in both the base
and image file, In the example shown above, image file page numbers and image file, In the example shown above, image file page numbers
are marked with an asterisk. Note that very simple ASCII artwork are marked with an asterisk. Note that very simple ASCII artwork
need not appear in the image file. need not appear in the image file.
4.3. Formatting Changes 4.3. Formatting Changes
It would be necessary to tie the base and image files together, to 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 make clear they are part of one RFC. Here is an initial suggestion
for formatting, which needs further consideration before it is for formatting, which needs further consideration before it is
adopted. adopted.
The header line "Request for Comments: nnnn" in the base file The header line "Request for Comments: nnnn" in the base file could
could be changed to "Request for Comments: nnnn/Base". For be changed to "Request for Comments: nnnn/Base". For consistency,
consistency, the lefthand footer could become "RFC nnnn/Base". the lefthand footer could become "RFC nnnn/Base". The lefthand
The lefthand footer in the image file could then be: "RFC nnnn/ footer in the image file could then be: "RFC nnnn/ {Image Name}.
Image.
The following sentence could be placed in the "Status of this The following sentence could be placed in the "Status of this Memo"
Memo" section: "This RFC is a composite of this base file and a section: "This RFC is a composite of this base file and {image
PDF image file." format} image files."
5. Submission and Processing of the Image File 5. Submission and Processing of the Image File
If an image file is needed, it should be submitted as an .img.pdf If a image files are needed, they should be submitted as a .{image
file along with the ASCII text file. The image file should be name>.{image format} files along with the ASCII text file. The image
submitted without headers or footers. The RFC Editor will overlay files should be submitted without headers or footers. The RFC Editor
the image file with the appropriate headers and footers, with correct will overlay the image file with the appropriate headers and footers,
pagination. The RFC Editor will not normally do any editing of the with correct pagination. The RFC Editor will not normally do any
image file beyond this. If editing the base file reveals problems editing of the image file beyond this. If editing the base file
with figures in the image file, the authors will be asked to create a reveals problems with figures in the image file, the authors will be
new image file. asked to create a new image file.
6. Implementation Issues 6. Implementation Issues
This acheme has a number of implications. This scheme has a number of implications.
1. The Internet Draft repository must allow submission and retrieval 1. The Internet Draft repository must allow submission and retrieval
of both base and (when present) image files. of both base and (when present) image files.
2. Internet Draft file names could be draft-...-vv.txt and 2. Internet Draft file names could be draft-...-vv.txt and
(optionally) draft-...-vv.img.pdf, where "vv" is the normal (optionally) draft-...-vv.{image name}.{image format}, where "vv"
version number. Updating either file of the composite RFC should is the normal version number. Updating any file of the composite
increase the version numbers "vv" in both files. We DO NOT want RFC should increase the version numbers "vv" in both files. We
two separate version numbers for one I-D DO NOT want two separate version numbers for one I-D
3. The RFC Editor would need to be able to overlay headers, footers, 3. 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 and page numbers on a given image file. It is claimed that at
least Adobe Acrobat Professional includes this capability, and least Adobe Acrobat Professional includes this capability, and
that it also has limited editing capability. that it also has limited editing capability.
4. The RFC Editor would also need a tool to verify that a given 4. The RFC Editor would also need a tool to verify that a given
image file satisfies the constraints of PDF/A. image file satisfies the constraints of {image format}.{image
format}.
5. Some RFC Editor scripts and tools would need small extensions. 5. Some RFC Editor scripts and tools would need small extensions.
6. Some small extensions to xml2rfc to include image files would be 6. xml2rfc already supports external image files, as an adjunct to,
useful. It should generate the boilerplate with a non-sequential or replacement of, textual art and is used when available, for
page number. For example, an attribute on <back>, might specify .html and .pdf formats..
the number of pages of image file. One could presumably add a
mechanism to generate the Figures section.
7. RFC Repository File Formats 7. RFC Repository File Formats
A frequent reaction to the suggestion given in this memo is some A frequent reaction to the suggestion given in this memo is some
confusion over the different file formats that appear in the RFC confusion over the different file formats that appear in the RFC
repository. Here is a brief summary. repository. Here is a brief summary.
If a PDF image file exists along with a base ASCII RFC, then RFCs in If a {image format} image file exists along with a base ASCII RFC,
any other format (e.g., complete PDF files, HTML, or Postscript) then RFCs in any other format (e.g., complete {image format} files,
remain supplemental, with the reader taking responsibility for HTML, or Postscript) remain supplemental, with the reader taking
assuring that they are equivalent to the base RFC and image file. responsibility for assuring that they are equivalent to the base RFC
That arrangement is identical to the relationship between traditional and image file. That arrangement is identical to the relationship
all-ASCII RFCs and supplemental forms: the RFC Editor has never taken between traditional all-ASCII RFCs and supplemental forms: the RFC
responsibility for guaranteeing that the two are identical in Editor has never taken responsibility for guaranteeing that the two
content. are identical in content.
The existing .txt.pdf files are not affected by this proposal. The The existing .txt.pdf files are not affected by this proposal. The
.txt.pdf files are facsimiles of .txt (base files) in PDF, introduced .txt.pdf files are facsimiles of .txt (base files) in PDF, introduced
to help Windows users read RFCs online. However, Microsoft has more to help Windows users read RFCs online. However, Microsoft has more
recently provided an elementary ASCII editor, which probably makes recently provided an elementary ASCII editor, which probably makes
the .txt.pdf files unnecessary in any case. the .txt.pdf files unnecessary in any case.
In summary: In summary:
o .txt: ASCII-only file. In old scheme, complete normative file. o .txt: ASCII-only file. In old scheme, complete normative file.
In new scheme, text part of composite RFC, or stand-alone text In new scheme, text part of composite RFC, or stand-alone text
file. file.
o .ps: Old scheme -- a Postscript file that includes figures and o .ps: Old scheme -- a Postscript file that includes figures and
whose text is intended to be the same as the normative .txt file. whose text is intended to be the same as the normative .txt file.
o .pdf: Old scheme -- a PDF file that includes figures and whose o .pdf: Old scheme -- a PDF file that includes figures and whose
text is intended to be the same as the normative .txt file. text is intended to be the same as the normative .txt file.
o .img.pdf: New scheme: image file part of a composite with .txt o .{image name}.{image format}: New scheme: image file(s) part of a
file. composite with .txt or xml2rfc file.
o .txt.pdf: Old scheme: Facsimile of corresponding .txt file. o .txt.pdf: Old scheme: Facsimile of corresponding .txt file.
We note that it would be possible to combine the base and image files 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 into a single PDF file, which would have to follow a naming
convention to distinguish it from the .pdf case listed above. 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.
8. Internationalization Considerations 8. Internationalization Considerations
Our scheme of image files does not, and is not intended to, support Our scheme of image files does not, and is not intended to, support
character set internationalization for RFCs. It does not allow an character set internationalization for RFCs. It does not allow an
author to omit the ASCII text from the base file and instead include author to omit the ASCII text from the base file and instead include
the entire RFC text as one (very large) image file. the entire RFC text as one (very large) image file.
However, we should note two special cases. However, we should note two special cases.
skipping to change at page 10, line 5 skipping to change at page 11, line 32
image file. This should raise no difficulties for informative image file. This should raise no difficulties for informative
documents. For normative documents, however, the existence of documents. For normative documents, however, the existence of
the Japanese original would raise some issues about what was the Japanese original would raise some issues about what was
actually authoritative, which is very undesirable. actually authoritative, which is very undesirable.
9. Security Considerations 9. Security Considerations
This specifications addresses documentation standards and adding This specifications addresses documentation standards and adding
additional flexibility to them. It does not, in general, raise any additional flexibility to them. It does not, in general, raise any
security issues. However, unless the specifications of this document security issues. However, unless the specifications of this document
are carefully followed, the image format recommended, PDF, may are carefully followed, the image format recommended, {image format},
potentially contain external references or scripts that could may potentially contain external references or scripts that could
introduce security problems. The RFC Editor and other publishers introduce security problems. The RFC Editor and other publishers
should exercise due care to ensure that no such references or scripts should exercise due care to ensure that no such references or scripts
appear in the archives. appear in the archives.
10. IANA Considerations 10. IANA Considerations
This document requires no actions by the IANA. This document requires no actions by the IANA.
11. Acknowledgments 11. Acknowledgments
The impetus for this specification arose during a discussion during Author's Address
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.
12. References
12.1. Normative References
[RFC2223] Postel, J. and J. Reynolds, "Instructions to RFC Authors",
RFC 2223, October 1997.
[RFC3778] Taft, E., Pravetz, J., Zilles, S., and L. Masinter, "The
application/pdf Media Type", RFC 3778, May 2004.
[RFC4748] Bradner, S., "RFC 3978 Update to Recognize the IETF
Trust", BCP 78, RFC 4748, October 2006.
12.2. Informative References
[ISO19005-1]
International Organization for Standardization (ISO),
"Document management -- Electronic document file format
for long-term preservation -- Part 1: Use of PDF 1.4
(PDF/A-1)", ISO 19005-1:2005, 2005.
[ISO32000-1]
International Organization for Standardization (ISO),
"Document management -- Portable document format -- Part
1: PDF 1.7", ISO 32000-1:2008, 2008.
[RFC3743] Konishi, K., Huang, K., Qian, H., and Y. Ko, "Joint
Engineering Team (JET) Guidelines for Internationalized
Domain Names (IDN) Registration and Administration for
Chinese, Japanese, and Korean", RFC 3743, April 2004.
Authors' Addresses
Robert Braden
USC/ISI
4676 Admiralty Way
Marina del Rey, CA 90292
USA
Phone: +1 310 448 9173
Email: braden@isi.edu
John C Klensin Dave Crocker
1770 Massachusetts Ave, #322 Brandenburg InternetWorking
Cambridge, MA 02140 675 Spruce Drive
Sunnyvale, CA 94086
USA USA
Phone: +1 617 491 5735 Phone: +1.408.246.8253
Email: john-ietf@jck.com Email: dcrocker@bbiw.net
Full Copyright Statement Full Copyright Statement
Copyright (C) The IETF Trust (2008). Copyright (C) The IETF Trust (2008).
This document is subject to the rights, licenses and restrictions This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors contained in BCP 78, and except as set forth therein, the authors
retain all their rights. retain all their rights.
This document and the information contained herein are provided on an This document and the information contained herein are provided on an
skipping to change at line 502 skipping to change at page 13, line 44
attempt made to obtain a general license or permission for the use of attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr. http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at this standard. Please address the information to the IETF at
ietf-ipr@ietf.org. ietf-ipr@ietf.org.
Acknowledgment
Funding for the RFC Editor function is provided by the IETF
Administrative Support Activity (IASA).
 End of changes. 38 change blocks. 
196 lines changed or deleted 211 lines changed or added

This html diff was produced by rfcdiff 1.35. The latest version is available from http://tools.ietf.org/tools/rfcdiff/