draft-iab-rfc-use-of-pdf-02.txt		draft-iab-rfc-use-of-pdf-latest.txt
	Network Working Group T. Hansen, Ed.		Network Working Group T. Hansen, Ed.
	Internet-Draft AT&T Laboratories		Internet-Draft AT&T Laboratories
	Intended status: Informational L. Masinter		Intended status: Informational L. Masinter
	Expires: November 18, 2016 M. Hardy		Expires: January 8, 2025 M. Hardy
	Adobe		Adobe
	May 17, 2016		July 7, 2024
	PDF for an RFC Series Output Document Format		PDF for an RFC Series Output Document Format
	draft-iab-rfc-use-of-pdf-02		draft-iab-rfc-use-of-pdf-latest
	Abstract		Abstract
	This document discusses options and requirements for the PDF		This document discusses options and requirements for the PDF
	rendering of RFCs in the RFC Series, as outlined in RFC 6949. It		rendering of RFCs in the RFC Series, as outlined in RFC 6949. It
	also discusses the use of PDF for Internet-Drafts, and available or		also discusses the use of PDF for Internet-Drafts, and available or
	needed software tools for producing and working with PDF.		needed software tools for producing and working with PDF.
	Status of this Memo		Status of This Memo
	This Internet-Draft is submitted in full conformance with the		This Internet-Draft is submitted in full conformance with the
	provisions of BCP 78 and BCP 79.		provisions of BCP 78 and BCP 79.
	Internet-Drafts are working documents of the Internet Engineering		Internet-Drafts are working documents of the Internet Engineering
	Task Force (IETF). Note that other groups may also distribute		Task Force (IETF). Note that other groups may also distribute
	working documents as Internet-Drafts. The list of current Internet-		working documents as Internet-Drafts. The list of current Internet-
	Drafts is at http://datatracker.ietf.org/drafts/current/.		Drafts is at https://datatracker.ietf.org/drafts/current/.
	Internet-Drafts are draft documents valid for a maximum of six months		Internet-Drafts are draft documents valid for a maximum of six months
	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."
	This Internet-Draft will expire on November 18, 2016.		This Internet-Draft will expire on January 8, 2025.
	Copyright Notice		Copyright Notice
	Copyright (c) 2016 IETF Trust and the persons identified as the		Copyright (c) 2024 IETF Trust and the persons identified as the
	document authors. All rights reserved.		document authors. All rights reserved.
	This document is subject to BCP 78 and the IETF Trust's Legal		This document is subject to BCP 78 and the IETF Trust's Legal
	Provisions Relating to IETF Documents		Provisions Relating to IETF Documents
	(http://trustee.ietf.org/license-info) in effect on the date of		(https://trustee.ietf.org/license-info) in effect on the date of
	publication of this document. Please review these documents		publication of this document. Please review these documents
	carefully, as they describe your rights and restrictions with respect		carefully, as they describe your rights and restrictions with respect
	to this document. Code Components extracted from this document must		to this document. Code Components extracted from this document must
	include Simplified BSD License text as described in Section 4.e of		include Simplified BSD License text as described in Section 4.e of
	the Trust Legal Provisions and are provided without warranty as		the Trust Legal Provisions and are provided without warranty as
	described in the Simplified BSD License.		described in the Simplified BSD License.
	Table of Contents		Table of Contents
	1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
	2. Choosing PDF versions and Standards . . . . . . . . . . . . . 3		2. Choosing PDF versions and Standards . . . . . . . . . . . . . 3
	3. Options and Requirements for PDF RFCs . . . . . . . . . . . . 4		3. Options and Requirements for PDF RFCs . . . . . . . . . . . . 4
	3.1. "Visible" Requirements . . . . . . . . . . . . . . . . . . 4		3.1. "Visible" Requirements . . . . . . . . . . . . . . . . . 4
	3.1.1. General Visible Requirements . . . . . . . . . . . . . 4		3.1.1. General Visible Requirements . . . . . . . . . . . . 5
	3.1.2. Page Size, Margins . . . . . . . . . . . . . . . . . . 5		3.1.2. Page Size, Margins . . . . . . . . . . . . . . . . . 5
	3.1.3. Headers and Footers . . . . . . . . . . . . . . . . . 5		3.1.3. Headers and Footers . . . . . . . . . . . . . . . . . 5
	3.1.4. Paragraph Numbering . . . . . . . . . . . . . . . . . 5		3.1.4. Paragraph Numbering . . . . . . . . . . . . . . . . . 5
	3.1.5. Paged Content Layout . . . . . . . . . . . . . . . . . 6		3.1.5. Paged Content Layout . . . . . . . . . . . . . . . . 6
	3.1.6. Typeface Choices . . . . . . . . . . . . . . . . . . . 6		3.1.6. Typeface Choices . . . . . . . . . . . . . . . . . . 6
	3.1.7. Hyphenation and Line Breaks . . . . . . . . . . . . . 7		3.1.7. Hyphenation and Line Breaks . . . . . . . . . . . . . 7
	3.1.8. Hyperlinks . . . . . . . . . . . . . . . . . . . . . . 7		3.1.8. Hyperlinks . . . . . . . . . . . . . . . . . . . . . 8
	3.1.9. Similarity to Other Outputs . . . . . . . . . . . . . 8		3.1.9. Similarity to Other Outputs . . . . . . . . . . . . . 8
	3.2. "Invisible" Options and Requirements . . . . . . . . . . . 9		3.2. "Invisible" Options and Requirements . . . . . . . . . . 10
	3.2.1. Internal Text Representation . . . . . . . . . . . . . 9		3.2.1. Internal Text Representation . . . . . . . . . . . . 10
	3.2.2. Unicode Support . . . . . . . . . . . . . . . . . . . 10		3.2.2. Unicode Support . . . . . . . . . . . . . . . . . . . 11
	3.2.3. Image Processing (Artwork) . . . . . . . . . . . . . . 10		3.2.3. Image Processing (Artwork) . . . . . . . . . . . . . 11
	3.2.4. Text Description of Images (Alt-Text) . . . . . . . . 10		3.2.4. Text Description of Images (Alt-Text) . . . . . . . . 11
	3.2.5. Metadata Support . . . . . . . . . . . . . . . . . . . 11		3.2.5. Metadata Support . . . . . . . . . . . . . . . . . . 12
	3.2.6. Document Structure Support . . . . . . . . . . . . . . 11		3.2.6. Document Structure Support . . . . . . . . . . . . . 12
	3.2.7. Embedded Files . . . . . . . . . . . . . . . . . . . . 11		3.2.7. Embedded Files . . . . . . . . . . . . . . . . . . . 12
	3.3. Digital Signatures . . . . . . . . . . . . . . . . . . . . 12		3.3. Digital Signatures . . . . . . . . . . . . . . . . . . . 13
	4. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12		4. References . . . . . . . . . . . . . . . . . . . . . . . . . 14
	4.1. References . . . . . . . . . . . . . . . . . . . . . . . . 12		4.1. References . . . . . . . . . . . . . . . . . . . . . . . 14
	4.2. Informative References . . . . . . . . . . . . . . . . . . 13		4.2. Informative References . . . . . . . . . . . . . . . . . 14
	Appendix A. History and Current Use of PDF with RFCs and		Appendix A. History and Current Use of PDF with RFCs and
	Internet-Drafts . . . . . . . . . . . . . . . . . . . 14		Internet-Drafts . . . . . . . . . . . . . . . . . . 16
	A.1. RFCs . . . . . . . . . . . . . . . . . . . . . . . . . . . 14		A.1. RFCs . . . . . . . . . . . . . . . . . . . . . . . . . . 16
	A.2. Internet-Drafts . . . . . . . . . . . . . . . . . . . . . 14		A.2. Internet-Drafts . . . . . . . . . . . . . . . . . . . . . 16
	Appendix B. Paged Content Layout Quality . . . . . . . . . . . . 15		Appendix B. Paged Content Layout Quality . . . . . . . . . . . . 16
	Appendix C. Tooling . . . . . . . . . . . . . . . . . . . . . . . 15		Appendix C. Tooling . . . . . . . . . . . . . . . . . . . . . . 17
	C.1. PDF Viewers . . . . . . . . . . . . . . . . . . . . . . . 15		C.1. PDF Viewers . . . . . . . . . . . . . . . . . . . . . . . 17
	C.2. Printers . . . . . . . . . . . . . . . . . . . . . . . . . 16		C.2. Printers . . . . . . . . . . . . . . . . . . . . . . . . 17
	C.3. PDF Generation Libraries . . . . . . . . . . . . . . . . . 16		C.3. PDF Generation Libraries . . . . . . . . . . . . . . . . 18
	C.4. Typefaces . . . . . . . . . . . . . . . . . . . . . . . . 16		C.4. Typefaces . . . . . . . . . . . . . . . . . . . . . . . . 18
	C.5. Other Tools . . . . . . . . . . . . . . . . . . . . . . . 16		C.5. Other Tools . . . . . . . . . . . . . . . . . . . . . . . 18
	Appendix D. Acknowledgements . . . . . . . . . . . . . . . . . . 17		Appendix D. Acknowledgements . . . . . . . . . . . . . . . . . . 19
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 17		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 19
	1. Introduction		1. Introduction
	The RFC Series is evolving, as outlined in [RFC6949]. Future		The RFC Series is evolving, as outlined in [RFC6949]. Future
	documents will use a canonical format, XML, with renderings in		documents will use a canonical format, XML, with renderings in
	various formats, including PDF.		various formats, including PDF.
	Because PDF has a wide range of capabilities and alternatives, not		Because PDF has a wide range of capabilities and alternatives, not
	all PDFs are "equal". For example, visually similar documents could		all PDFs are "equal". For example, visually similar documents could
	consist of scanned or rasterized images, or include text layout		consist of scanned or rasterized images, or include text layout
	skipping to change at page 9, line 33 ¶		skipping to change at page 10, line 16 ¶
	PDF offers a number of features which improve the utility of PDF		PDF offers a number of features which improve the utility of PDF
	files in a variety of workflows, at the cost of extra effort in the		files in a variety of workflows, at the cost of extra effort in the
	xml2rfc conversion process; the tradeoffs may be different for the		xml2rfc conversion process; the tradeoffs may be different for the
	RFC editor production of RFCs and for Internet-Drafts.		RFC editor production of RFCs and for Internet-Drafts.
	3.2.1. Internal Text Representation		3.2.1. Internal Text Representation
	The contents of a PDF file can be represented in many ways. The PDF		The contents of a PDF file can be represented in many ways. The PDF
	file could be generated:		file could be generated:
	o as an image of the visual representation, such as a JPEG image of		o as an image of the visual representation, such as a JPEG image of
	the word "IETF". That is, there might be no internal		the word "IETF". That is, there might be no internal
	representation of letters, words or paragraphs at all.		representation of letters, words or paragraphs at all.
	o placing individual characters in position on the page, such as		o placing individual characters in position on the page, such as
	saying "put an 'F' here", then "put an 'T' before it", then "put		saying "put an 'F' here", then "put an 'T' before it", then "put
	an 'E' before that", then "put an 'I' before that" to render the		an 'E' before that", then "put an 'I' before that" to render the
	word "IETF". That is, there might be no internal representation		word "IETF". That is, there might be no internal representation
	of words or paragraphs at all.		of words or paragraphs at all.
	o placing words in position on the page, such as keeping the word		o placing words in position on the page, such as keeping the word
	"IETF" would be kept together. That is, there might be no		"IETF" would be kept together. That is, there might be no
	internal representation of paragraphs at all.		internal representation of paragraphs at all.
	o ensuring that the running order of text in the content stream		o ensuring that the running order of text in the content stream
	matches the logical reading order. That is, a sentence such as		matches the logical reading order. That is, a sentence such as
	'The Internet Engineering Task Force (IETF) supports the		'The Internet Engineering Task Force (IETF) supports the
	Internet.' would be kept together as a sentence, and multiple		Internet.' would be kept together as a sentence, and multiple
	sentences within a paragraph would be kept together.		sentences within a paragraph would be kept together.
	All of these end up with essentially the same visual representation		All of these end up with essentially the same visual representation
	of the output. However, each level has tradeoffs for auxiliary uses,		of the output. However, each level has tradeoffs for auxiliary uses,
	such as searching or indexing, commenting and annotation, and		such as searching or indexing, commenting and annotation, and
	accessibility (text-to-speech). Keeping the running order of text in		accessibility (text-to-speech). Keeping the running order of text in
	the content stream in the proper order supports all of these		the content stream in the proper order supports all of these
	auxiliary uses.		auxiliary uses.
	In addition, the "role map" feature of PDF (<http://help.adobe.com/		In addition, the "role map" feature of PDF
	en_US/acrobat/X/pro/using/		(<http://help.adobe.com/en_US/acrobat/X/pro/using/
	WS58a04a822e3e50102bd615109794195ff-7cd8.w.html>) would additionally		WS58a04a822e3e50102bd615109794195ff-7cd8.w.html>) would additionally
	allow for the mapping of the logical tags found in the original XML		allow for the mapping of the logical tags found in the original XML
	into tags in the PDF.		into tags in the PDF.
	Recommendations:		Recommendations:
	o Text in content streams should follow the XML document's logical		o Text in content streams should follow the XML document's logical
	order (in the order of tags) to the extent possible. This will		order (in the order of tags) to the extent possible. This will
	provide optimal reuse by software that does not understand Tagged		provide optimal reuse by software that does not understand Tagged
	PDF. (PDF/UA requires this.)		PDF. (PDF/UA requires this.)
	o It might be possible to use the "role map" annotation to capture		o It might be possible to use the "role map" annotation to capture
	enough of the xml2rfc source structure, to the point where it is		enough of the xml2rfc source structure, to the point where it is
	possible to reconstruct the XML source structure completely.		possible to reconstruct the XML source structure completely.
	However, there is not a compelling case to do so over embedding		However, there is not a compelling case to do so over embedding
	the original XML, as described in Section 3.2.7.		the original XML, as described in Section 3.2.7.
	3.2.2. Unicode Support		3.2.2. Unicode Support
	PDF itself does not require use of Unicode. Text is represented as a		PDF itself does not require use of Unicode. Text is represented as a
	sequence of glyphs which then can be mapped to Unicode.		sequence of glyphs which then can be mapped to Unicode.
	skipping to change at page 10, line 31 ¶		skipping to change at page 11, line 22 ¶
	possible to reconstruct the XML source structure completely.		possible to reconstruct the XML source structure completely.
	However, there is not a compelling case to do so over embedding		However, there is not a compelling case to do so over embedding
	the original XML, as described in Section 3.2.7.		the original XML, as described in Section 3.2.7.
	3.2.2. Unicode Support		3.2.2. Unicode Support
	PDF itself does not require use of Unicode. Text is represented as a		PDF itself does not require use of Unicode. Text is represented as a
	sequence of glyphs which then can be mapped to Unicode.		sequence of glyphs which then can be mapped to Unicode.
	Recommendations:		Recommendations:
	PDF files generated must have the full text, as it appears in the		PDF files generated must have the full text, as it appears in the
	original XML.		original XML.
	Unicode normalization may occur.		Unicode normalization may occur.
	Text within SVG for SVG images should also have Unicode mappings.		Text within SVG for SVG images should also have Unicode mappings.
	Alt-text for images should also support Unicode.		Alt-text for images should also support Unicode.
	3.2.3. Image Processing (Artwork)		3.2.3. Image Processing (Artwork)
	The XML allows both ASCII art and SVG to be used for artwork.		The XML allows both ASCII art and SVG to be used for artwork.
	Recommendations:		Recommendations:
	If both ASCII art and SVG are available for a picture, the SVG		If both ASCII art and SVG are available for a picture, the SVG
	artwork should be the preferred over the ASCII artwork.		artwork should be the preferred over the ASCII artwork.
	ASCII artwork must be rendered using a monospace font.		ASCII artwork must be rendered using a monospace font.
	3.2.4. Text Description of Images (Alt-Text)		3.2.4. Text Description of Images (Alt-Text)
	Guidelines for accessibility of PDF		Guidelines for accessibility of PDF <http://www.w3.org/TR/WCAG20-
	<http://www.w3.org/TR/WCAG20-TECHS/PDF1.html> recommend that images,		TECHS/PDF1.html> recommend that images, formulas, and other non-text
	formulas, and other non-text items provide textual alternatives,		items provide textual alternatives, using the '/Alt' Tag in PDF to
	using the '/Alt' Tag in PDF to provide human-readable text that can		provide human-readable text that can be vocalized by text-to-speech
	be vocalized by text-to-speech technology.		technology.
	Recommendation: Any alt-text for artwork and figures available in the		Recommendation: Any alt-text for artwork and figures available in the
	XML source should be stored using the PDF /Alt property. Internet		XML source should be stored using the PDF /Alt property. Internet
	draft authors and the RFC editor should ensure inclusion of alt-text		draft authors and the RFC editor should ensure inclusion of alt-text
	for all SVG or images, within the XML source.		for all SVG or images, within the XML source.
	3.2.5. Metadata Support		3.2.5. Metadata Support
	Metadata encodes information about the document authors, the document		Metadata encodes information about the document authors, the document
	series, date created, etc. Having this metadata within the PDF file		series, date created, etc. Having this metadata within the PDF file
	skipping to change at page 11, line 40 ¶		skipping to change at page 12, line 36 ¶
	navigation aid.		navigation aid.
	The section structure of an RFC can be mapped into the PDF elements		The section structure of an RFC can be mapped into the PDF elements
	for the document structure. This will allow the bookmark feature of		for the document structure. This will allow the bookmark feature of
	PDF readers to be used to quickly access sections of the document.		PDF readers to be used to quickly access sections of the document.
	Recommendation: The section structure of an RFC should be mapped into		Recommendation: The section structure of an RFC should be mapped into
	the PDF elements for the document structure. This would include		the PDF elements for the document structure. This would include
	section headings for the boilerplate sections such as the Abstract,		section headings for the boilerplate sections such as the Abstract,
	Status of the Document, Table of Contents, and Author Addresses, plus		Status of the Document, Table of Contents, and Author Addresses, plus
	the obvious section headings that are normally included in the Table		the obvious section headings that are normally included in the
	of Contents. If possible, this should be done in a way that the same		Table of Contents. If possible, this should be done in a way that
	fragment identifiers for the HTML version of the RFC will work for		the same fragment identifiers for the HTML version of the RFC will
	the PDF version.		work for the PDF version.
	3.2.7. Embedded Files		3.2.7. Embedded Files
	PDF has the capability of including other files; the files may be		PDF has the capability of including other files; the files may be
	labeled both by a media type and a role, the AFRelationship key		labeled both by a media type and a role, the AFRelationship key
	[PDFA3]. In this way, the PDF file acts also as a container.		[PDFA3]. In this way, the PDF file acts also as a container.
	Embedded content may be compressed.		Embedded content may be compressed.
	Many PDF viewers support the ability to view and extract embedded		Many PDF viewers support the ability to view and extract embedded
	skipping to change at page 13, line 7 ¶		skipping to change at page 14, line 14 ¶
	4. References		4. References
	4.1. References		4.1. References
	[PDF] ISO, "Portable document format -- Part 1: PDF 1.7",		[PDF] ISO, "Portable document format -- Part 1: PDF 1.7",
	ISO 32000-1, 2008.		ISO 32000-1, 2008.
	Also available free from Adobe.		Also available free from Adobe.
	[XMP] ISO, "Extensible metadata platform (XMP) specification --
	Part 1: Data model, serialization and core properties",
	ISO 16684-1, 2012.
	Not available free, but there are a number of descriptive
	resources, e.g., <http://en.wikipedia.org/wiki/
	Extensible_Metadata_Platform>
	[PDFA2] ISO, "Electronic document file format for long-term		[PDFA2] ISO, "Electronic document file format for long-term
	preservation -- Part 2: Use of ISO 32000-1 (PDF/A-2).",		preservation -- Part 2: Use of ISO 32000-1 (PDF/A-2).",
	ISO 19005-2, 2011.		ISO 19005-2, 2011.
	[PDFA3] ISO, "Electronic document file format for long-term		[PDFA3] ISO, "Electronic document file format for long-term
	preservation -- Part 3: Use of ISO 32000-1 with support		preservation -- Part 3: Use of ISO 32000-1 with support
	for embedded files (PDF/A-3)", ISO 19005-3, 2012.		for embedded files (PDF/A-3)", ISO 19005-3, 2012.
	[PDFUA] ISO, "Electronic document file format enhancement for		[PDFUA] ISO, "Electronic document file format enhancement for
	accessibility -- Part 1: Use of ISO 32000-1 (PDF/UA-1)",		accessibility -- Part 1: Use of ISO 32000-1 (PDF/UA-1)",
	ISO 19005-3, 2012.		ISO 19005-3, 2012.
	4.2. Informative References		[XMP] ISO, "Extensible metadata platform (XMP) specification --
			Part 1: Data model, serialization and core properties",
	[RFC2346] Palme, J., "Making Postscript and PDF International",		ISO 16684-1, 2012.
	RFC 2346, DOI 10.17487/RFC2346, May 1998,
	<https://www.rfc-editor.org/info/rfc2346>.
	[RFC6949] Flanagan, H. and N. Brownlee, "RFC Series Format		Not available free, but there are a number of descriptive
	Requirements and Future Development", RFC 6949,		resources, e.g., <http://en.wikipedia.org/wiki/
	DOI 10.17487/RFC6949, May 2013,		Extensible_Metadata_Platform>
	<https://www.rfc-editor.org/info/rfc6949>.
	[RFC7322] Flanagan, H. and S. Ginoza, "RFC Style Guide", RFC 7322,		4.2. Informative References
	DOI 10.17487/RFC7322, September 2014,
	<https://www.rfc-editor.org/info/rfc7322>.
	[I-D.flanagan-nonascii]		[I-D.flanagan-nonascii]
	Flanagan, H., "The Use of Non-ASCII Characters in RFCs",		Flanagan, H., "The Use of Non-ASCII Characters in RFCs",
	draft-flanagan-nonascii-06 (work in progress),		draft-flanagan-nonascii-06 (work in progress), November
	November 2015, <https://datatracker.ietf.org/doc/html/		2015, <https://datatracker.ietf.org/doc/html/draft-
	draft-flanagan-nonascii-06>.		flanagan-nonascii-06>.
	[I-D.flanagan-rfc-css]		[I-D.flanagan-rfc-css]
	Flanagan, H., "CSS Requirements for RFCs",		Flanagan, H., "CSS Requirements for RFCs", draft-flanagan-
	draft-flanagan-rfc-css-04 (work in progress),		rfc-css-04 (work in progress), September 2015,
	September 2015, <https://datatracker.ietf.org/doc/html/		<https://datatracker.ietf.org/doc/html/draft-flanagan-rfc-
	draft-flanagan-rfc-css-04>.		css-04>.
	[I-D.hardy-pdf-mime]		[I-D.hardy-pdf-mime]
	Hardy, M., Masinter, L., Markovic, D., Johnson, D., and M.		Hardy, M., Masinter, L., Markovic, D., Johnson, D., and M.
	Bailey, "The application/pdf Media Type",		Bailey, "The application/pdf Media Type", draft-hardy-pdf-
	draft-hardy-pdf-mime-05 (work in progress), February 2017,		mime-05 (work in progress), February 2017,
	<https://datatracker.ietf.org/doc/html/		<https://datatracker.ietf.org/doc/html/draft-hardy-pdf-
	draft-hardy-pdf-mime-05>.		mime-05>.
	[I-D.hildebrand-html-rfc]		[I-D.hildebrand-html-rfc]
	Hildebrand, J. and P. Hoffman, "HyperText Markup Language		Hildebrand, J. and P. Hoffman, "HyperText Markup Language
	Request For Comments Format", draft-hildebrand-html-rfc-10		Request For Comments Format", draft-hildebrand-html-rfc-10
	(work in progress), August 2015, <https://		(work in progress), August 2015,
	datatracker.ietf.org/doc/html/		<https://datatracker.ietf.org/doc/html/draft-hildebrand-
	draft-hildebrand-html-rfc-10>.		html-rfc-10>.
	[I-D.housley-rfc-and-id-signatures]		[I-D.housley-rfc-and-id-signatures]
	Housley, R., "Digital Signatures on RFC and Internet-Draft		Housley, R., "Digital Signatures on RFC and Internet-Draft
	Documents", draft-housley-rfc-and-id-signatures-03 (work		Documents", draft-housley-rfc-and-id-signatures-03 (work
	in progress), June 2016, <https://datatracker.ietf.org/		in progress), June 2016,
	doc/html/draft-housley-rfc-and-id-signatures-03>.		<https://datatracker.ietf.org/doc/html/draft-housley-rfc-
			and-id-signatures-03>.
	URIs		[RFC2346] Palme, J., "Making Postscript and PDF International",
			RFC 2346, DOI 10.17487/RFC2346, May 1998,
			<https://www.rfc-editor.org/info/rfc2346>.
	[1] <https://sourceforge.net/projects/sourcesans.adobe/		[RFC6949] Flanagan, H. and N. Brownlee, "RFC Series Format
	?source=directory>		Requirements and Future Development", RFC 6949,
			DOI 10.17487/RFC6949, May 2013,
			<https://www.rfc-editor.org/info/rfc6949>.
	[2] <https://sourceforge.net/projects/sourceserifpro.adobe/		[RFC7322] Flanagan, H. and S. Ginoza, "RFC Style Guide", RFC 7322,
	?source=directory>		DOI 10.17487/RFC7322, September 2014,
			<https://www.rfc-editor.org/info/rfc7322>.
	[3] <https://sourceforge.net/projects/sourcecodepro.adobe/		4.3. URIs
	?source=drectory>
	[4] <https://www.rosettatype.com/Skolar>		[1] https://sourceforge.net/projects/
			sourcesans.adobe/?source=directory
	[5] <https://www.google.com/get/noto/>		[2] https://sourceforge.net/projects/
			sourceserifpro.adobe/?source=directory
			[3] https://sourceforge.net/projects/
			sourcecodepro.adobe/?source=drectory
			[4] https://www.rosettatype.com/Skolar
			[5] https://www.google.com/get/noto/
	Appendix A. History and Current Use of PDF with RFCs and Internet-		Appendix A. History and Current Use of PDF with RFCs and Internet-
	Drafts		Drafts
	NOTE: this section is meant as an overview to give some background.		NOTE: this section is meant as an overview to give some background.
	A.1. RFCs		A.1. RFCs
	The RFC series has for a long time accepted Postscript renderings of		The RFC series has for a long time accepted Postscript renderings of
	RFCs, either in addition to or instead of the text renderings of		RFCs, either in addition to or instead of the text renderings of
	skipping to change at page 15, line 16 ¶		skipping to change at page 16, line 29 ¶
	rendering of RFCs. Usually, this has been a print of the text file		rendering of RFCs. Usually, this has been a print of the text file
	that does not take advantage of any of the broader PDF functionality,		that does not take advantage of any of the broader PDF functionality,
	unless there was a Postscript version of the RFC, which would then be		unless there was a Postscript version of the RFC, which would then be
	used by the RFC editor to generate the PDF.		used by the RFC editor to generate the PDF.
	A.2. Internet-Drafts		A.2. Internet-Drafts
	In addition to PDFs generated and published by the RFC editor, the		In addition to PDFs generated and published by the RFC editor, the
	IETF tools community has also long supported PDF for Internet-Drafts.		IETF tools community has also long supported PDF for Internet-Drafts.
	Most RFCs start with Internet-Drafts, edited by individual authors.		Most RFCs start with Internet-Drafts, edited by individual authors.
	The Internet-Drafts submission tool at		The Internet-Drafts submission tool at https://datatracker.ietf.org/
	https://datatracker.ietf.org/submit/ accepts PDF and Postscript files		submit/ accepts PDF and Postscript files in addition to the
	in addition to the (required) text submission and (currently		(required) text submission and (currently optional) XML. If a PDF
	optional) XML. If a PDF wasn't submitted for a particular version of		wasn't submitted for a particular version of an Internet-Draft, the
	an Internet-Draft, the tools would generate one from the Postscript,		tools would generate one from the Postscript, HTML, or text.
	HTML, or text.
	Appendix B. Paged Content Layout Quality		Appendix B. Paged Content Layout Quality
	The process of creating a paged document from running text typically		The process of creating a paged document from running text typically
	involves ensuring that related material is present on the same page		involves ensuring that related material is present on the same page
	together, and that artifacts of pagination don't interfere with easy		together, and that artifacts of pagination don't interfere with easy
	reading of the document. Typical high-quality layout processors do		reading of the document. Typical high-quality layout processors do
	several things:		several things:
	Widow and Orphan Management: Widows and orphans		Widow and Orphan Management: Widows and orphans
	(<https://en.wikipedia.org/wiki/Widows_and_orphans>) should be		(<https://en.wikipedia.org/wiki/Widows_and_orphans>) should be
	avoided automatically (unless the entire paragraph is only one		avoided automatically (unless the entire paragraph is only one
	line). Ensure that a page break does not occur after the first		line). Ensure that a page break does not occur after the first
	line of a paragraph (orphans), if necessary, using slightly longer		line of a paragraph (orphans), if necessary, using slightly longer
	page sizes. Similarly, ensure that a page break does not occur		page sizes. Similarly, ensure that a page break does not occur
	before the last line of a paragraph (widows).		before the last line of a paragraph (widows).
	Keep Section Heading Contiguous: Do not insert a page break		Keep Section Heading Contiguous: Do not insert a page break
	immediately after a section heading. If there isn't room on a		immediately after a section heading. If there isn't room on a
	page for the first (two) lines of a section after the section		page for the first (two) lines of a section after the section
	heading, insert a page break before the heading.		heading, insert a page break before the heading.
	Avoid Splitting Artwork: Figures should not be split from figure		Avoid Splitting Artwork: Figures should not be split from figure
	titles. If possible, keep the figure on the same page as the		titles. If possible, keep the figure on the same page as the
	(first) mention of the figure.		(first) mention of the figure.
	Headers for Long Tables after Page Breaks: Another common option in		Headers for Long Tables after Page Breaks: Another common option in
	producing paginated documents is to include the column headings of		producing paginated documents is to include the column headings of
	a table if the table cannot be displayed on a single page.		a table if the table cannot be displayed on a single page.
	Similarly, tables should not be split from the table titles.		Similarly, tables should not be split from the table titles.
	keepWithNext and keepWithPrevious: The XML attributes of		keepWithNext and keepWithPrevious: The XML attributes of
	"keepWithNext" and "keepWithPrevious" should be followed whenever		"keepWithNext" and "keepWithPrevious" should be followed whenever
	possible.		possible.
	Whitespace Preservation: The XML entities such as NBSP and NBHYPHEN		Whitespace Preservation: The XML entities such as NBSP and NBHYPHEN
	should be followed as directed whenever possible.		should be followed as directed whenever possible.
	Appendix C. Tooling		Appendix C. Tooling
	This section discusses tools for viewing, comparing, creating,		This section discusses tools for viewing, comparing, creating,
	manipulating, transforming PDF files, including those currently in		manipulating, transforming PDF files, including those currently in
	use by the RFC editor and Internet-Drafts, as well as outlining		use by the RFC editor and Internet-Drafts, as well as outlining
	available PDF tools for various processes.		available PDF tools for various processes.
	skipping to change at page 16, line 44 ¶		skipping to change at page 18, line 11 ¶
	While almost all viewers also support printing of PDF files, printing		While almost all viewers also support printing of PDF files, printing
	is one of the most important use cases for PDFs. Some printers have		is one of the most important use cases for PDFs. Some printers have
	direct PDF support.		direct PDF support.
	C.3. PDF Generation Libraries		C.3. PDF Generation Libraries
	Because the xml2rfc format is a unique format, software for		Because the xml2rfc format is a unique format, software for
	converting XML source documents to the various formats will be		converting XML source documents to the various formats will be
	needed, including PDF generation.		needed, including PDF generation.
	One promising direction is suggested in <http://greenbytes.de/tech/		One promising direction is suggested in
	webdav/rfc2629xslt/rfc2629xslt.html#output.pdf.fop>: using XSLT to		<http://greenbytes.de/tech/webdav/rfc2629xslt/
	generate XSL-FO which is then processed by a formatting object		rfc2629xslt.html#output.pdf.fop>: using XSLT to generate XSL-FO which
	processor such as Apache FOP.		is then processed by a formatting object processor such as Apache
			FOP.
	Several libraries are also available for generating PDF signatures.		Several libraries are also available for generating PDF signatures.
	The choice of library to use for xml2pdf will depend on many factors:		The choice of library to use for xml2pdf will depend on many factors:
	programming language, quality of implementation, quality of PDF		programming language, quality of implementation, quality of PDF
	generated, support, cost, availability, and so forth.		generated, support, cost, availability, and so forth.
	C.4. Typefaces		C.4. Typefaces
	This section is intended to discuss available typefaces that might		This section is intended to discuss available typefaces that might
	satisfy requirements. Some openly available fixed-width typefaces		satisfy requirements. Some openly available fixed-width typefaces
	skipping to change at page 17, line 11 ¶		skipping to change at page 18, line 27 ¶
	Several libraries are also available for generating PDF signatures.		Several libraries are also available for generating PDF signatures.
	The choice of library to use for xml2pdf will depend on many factors:		The choice of library to use for xml2pdf will depend on many factors:
	programming language, quality of implementation, quality of PDF		programming language, quality of implementation, quality of PDF
	generated, support, cost, availability, and so forth.		generated, support, cost, availability, and so forth.
	C.4. Typefaces		C.4. Typefaces
	This section is intended to discuss available typefaces that might		This section is intended to discuss available typefaces that might
	satisfy requirements. Some openly available fixed-width typefaces		satisfy requirements. Some openly available fixed-width typefaces
	(without extensive Unicode support, however) include:		(without extensive Unicode support, however) include:
	o Source Sans [1]		o Source Sans [1]
	o Source Serif Pro [2]		o Source Serif Pro [2]
	o Source Code Pro [3]		o Source Code Pro [3]
	A font that looks promising for its broad Unicode support is
	Skolar [4], but it requires licensing. Another potentially useful		A font that looks promising for its broad Unicode support is Skolar
	set of typefaces is the Noto [5] family from Google.		[4], but it requires licensing. Another potentially useful set of
			typefaces is the Noto [5] family from Google.
	C.5. Other Tools		C.5. Other Tools
	In addition to generating and viewing PDF, other categories of PDF		In addition to generating and viewing PDF, other categories of PDF
	tools are available and may be useful both during specification		tools are available and may be useful both during specification
	development and for published RFCs. These include tools for		development and for published RFCs. These include tools for
	comparing two PDFs, checkers that could be used to validate the		comparing two PDFs, checkers that could be used to validate the
	results of conversion, reviewing and commentary tools that attach		results of conversion, reviewing and commentary tools that attach
	annotations to PDF files, and digital signature creation and		annotations to PDF files, and digital signature creation and
	validation.		validation.
	skipping to change at page 17, line 36 ¶		skipping to change at page 19, line 8 ¶
	validation.		validation.
	Validation of an arbitrary author-generated PDF file would be quite		Validation of an arbitrary author-generated PDF file would be quite
	difficult; there are few PDF validation tools. However, if RFCs and		difficult; there are few PDF validation tools. However, if RFCs and
	Internet-Drafts are generated by conversion from XML via xml2rfc,		Internet-Drafts are generated by conversion from XML via xml2rfc,
	then explicit validation of PDF and adherence to expected profiles		then explicit validation of PDF and adherence to expected profiles
	would mainly be useful to ensure that xml2rfc has functioned		would mainly be useful to ensure that xml2rfc has functioned
	properly.		properly.
	Recommendations:		Recommendations:
	o Discourage (but allow) submission of a PDF representation for		o Discourage (but allow) submission of a PDF representation for
	Internet-Drafts. In most cases, the PDF for an Internet-Draft		Internet-Drafts. In most cases, the PDF for an Internet-Draft
	should be produced automatically when XML is submitted, with an		should be produced automatically when XML is submitted, with an
	opportunity to verify the conversion.		opportunity to verify the conversion.
	Appendix D. Acknowledgements		Appendix D. Acknowledgements
	The input of the following people is gratefully acknowledged: Nevil		The input of the following people is gratefully acknowledged: Nevil
	Brownlee (ISE), Brian Carpenter, Chris Dearlove, Martin Duerst,		Brownlee (ISE), Brian Carpenter, Chris Dearlove, Martin Duerst,
	Heather Flanagan (RSE), Joe Hildebrand, Paul Hoffman, Duff Johnson,		Heather Flanagan (RSE), Joe Hildebrand, Paul Hoffman, Duff Johnson,
	Ted Lemon, Sean Leonard, Henrik Levkowetz, Julian Reschke, Adam		Ted Lemon, Henrik Levkowetz, Julian Reschke, Adam Roach, Leonard
	Roach, Leonard Rosenthol, Alice Russo, Robert Sparks, Andrew		Rosenthol, Alice Russo, Robert Sparks, Andrew Sullivan, and Dave
	Sullivan, and Dave Thaler.		Thaler.
	Authors' Addresses		Authors' Addresses
	Tony Hansen (editor)		Tony Hansen (editor)
	AT&T Laboratories		AT&T Laboratories
	200 Laurel Ave. South		200 Laurel Ave. South
	Middletown, NJ 07748		Middletown, NJ 07748
	USA		USA
	Email: tony@att.com		Email: tony@att.com
End of changes. 53 change blocks.
	117 lines changed or deleted		140 lines changed or added
This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/