summaryrefslogtreecommitdiff
path: root/doc/rfc/rfc4263.txt
diff options
context:
space:
mode:
Diffstat (limited to 'doc/rfc/rfc4263.txt')
-rw-r--r--doc/rfc/rfc4263.txt899
1 files changed, 899 insertions, 0 deletions
diff --git a/doc/rfc/rfc4263.txt b/doc/rfc/rfc4263.txt
new file mode 100644
index 0000000..18aca3f
--- /dev/null
+++ b/doc/rfc/rfc4263.txt
@@ -0,0 +1,899 @@
+
+
+
+
+
+
+Network Working Group B. Lilly
+Request for Comments: 4263 January 2006
+Category: Informational
+
+
+ Media Subtype Registration for Media Type text/troff
+
+Status of This Memo
+
+ This memo provides information for the Internet community. It does
+ not specify an Internet standard of any kind. Distribution of this
+ memo is unlimited.
+
+Copyright Notice
+
+ Copyright (C) The Internet Society (2006).
+
+Abstract
+
+ A text media subtype for tagging content consisting of juxtaposed
+ text and formatting directives as used by the troff series of
+ programs and for conveying information about the intended processing
+ steps necessary to produce formatted output is described.
+
+Table of Contents
+
+ 1. Introduction................................................... 2
+ 2. Requirement Levels............................................. 3
+ 3. Scope of Specification......................................... 3
+ 4. Registration Form.............................................. 3
+ 5. Acknowledgements............................................... 8
+ 6. Security Considerations........................................ 8
+ 7. Internationalization Considerations............................ 8
+ 8. IANA Considerations............................................ 9
+ Appendix A. Examples.............................................. 10
+ A.1. Data Format............................................... 10
+ A.2. Simple Diagram............................................ 11
+ Appendix B. Disclaimers........................................... 12
+ Normative References.............................................. 13
+ Informative References............................................ 13
+
+
+
+
+
+
+
+
+
+
+
+Lilly Informational [Page 1]
+
+RFC 4263 Media Type text/troff January 2006
+
+
+1. Introduction
+
+ It is sometimes desirable to format text in a particular way for
+ presentation. One approach is to provide formatting directives in
+ juxtaposition to the text to be formatted. That approach permits
+ reading the text in unformatted form (by ignoring the formatting
+ directives), and it permits relatively simple repurposing of the text
+ for different media by making suitable alterations to the formatting
+ directives or the environment in which they operate. One particular
+ series of related programs for formatting text in accordance with
+ that model is often referred to generically as "troff", although that
+ is also the name of a particular lineage of programs within that
+ generic category for formatting text specifically for typesetter and
+ typesetter-like devices. A related formatting program within the
+ generic "troff" category, usually used for character-based output
+ such as (formatted) plain text, is known as "nroff". For the purpose
+ of the media type defined here, the entire category will be referred
+ to simply by the generic "troff" name. Troff as a distinct set of
+ programs first appeared in the early 1970s [N1.CSTR54], based on the
+ same formatting approach used by some earlier programs ("runoff" and
+ "roff"). It has been used to produce documents in various formats,
+ ranging in length from short memoranda to books (including tables,
+ diagrams, and other non-textual content). It remains in wide use as
+ of the date of this document; this document itself was prepared using
+ the troff family of tools per [I1.RFC2223] and [I2.Lilly05].
+
+ The basic format (juxtaposed text and formatting directives) is
+ extensible and has been used for related formatting of text and
+ graphical document content. Formating is usually controlled by a set
+ of macros; a macro package is a set of related formatting tools,
+ written in troff format (although compressed binary representations
+ have also been used) and using basic formatting directives to extend
+ and manage formatting capabilities for document authors. There are a
+ number of preprocessors that transform a textual description of some
+ content into the juxtaposed text and formatting directives necessary
+ to produce some desired output. Preprocessors exist for formatting
+ of tables of text and non-textual material, mathematical equations,
+ chemical formulae, general line drawings, graphical representation of
+ data (in plotted coordinate graphs, bar charts, etc.),
+ representations of data formats, and representations of the abstract
+ mathematical construct known as a graph (consisting of nodes and
+ edges). Many such preprocessors use the same general type of input
+ format as the formatters, and such input is explicitly within the
+ scope of the media type described in this document.
+
+
+
+
+
+
+
+Lilly Informational [Page 2]
+
+RFC 4263 Media Type text/troff January 2006
+
+
+2. Requirement Levels
+
+ The key words "MUST", "MUST NOT", "SHOULD", "SHOULD NOT",
+ "RECOMMENDED", and "MAY" in this document are to be interpreted as
+ described in [N2.BCP14].
+
+3. Scope of Specification
+
+ The described media type refers to input that may be processed by
+ preprocessors and by a page formatter. It is intended to be used
+ where content has some text that may be comprehensible (either as
+ text per se or as a readable description of non-text content) without
+ machine processing of the content. Where there is little or no
+ comprehensible text content, this media type SHOULD NOT be used. For
+ example, while output of the "pic" preprocessor certainly consists of
+ troff-compatible sequences of formatting directives, the sheer number
+ of individual directives interspersed with any text that might be
+ present makes comprehension difficult, whereas the preprocessor input
+ language (as described in the "Published Specification" section of
+ the registration below) may provide a concise and comprehensible
+ description of graphical content. Preprocessor output that includes
+ a large proportion of formatting directives would best be labeled as
+ a subtype of the application media type. If particular preprocessor
+ input content describes only graphical content with little or no
+ text, and which is not readily comprehensible from a textual
+ description of the graphical elements, a subtype of the image media
+ type would be appropriate. The purpose of labeling media content is
+ to provide information about that content to facilitate use of the
+ content. Use of a particular label requires some common sense and
+ judgment, and SHOULD NOT be mechanically applied to content in the
+ absence of such judgment.
+
+4. Registration Form
+
+ The registration procedure and form are specified in [I3.RFC4288].
+
+ Type name: text
+
+ Subtype name: troff
+
+ Required parameters: none
+
+ Optional parameters:
+
+ charset: Must be a charset registered for use with MIME text types
+ [N3.RFC2046], except where transport protocols are explicitly
+ exempted from that restriction. Specifies the charset of the
+ media content. With traditional source content, this will be
+
+
+
+Lilly Informational [Page 3]
+
+RFC 4263 Media Type text/troff January 2006
+
+
+ the default "US-ASCII" charset. Some recent versions of troff
+ processing software can handle Unicode input charsets; however,
+ there may be interoperability issues if the input uses such a
+ charset (see "Interoperability considerations" below).
+
+ process: Human-readable additional information for formatting,
+ including environment variables, preprocessor arguments and
+ order, formatter arguments, and postprocessors. The parameter
+ value may need to be quoted or encoded as provided for by
+ [N4.RFC2045] as amended by [N5.RFC2231] and [N6.Errata].
+ Generating implementations must not encode executable content
+ and other implementations must not attempt any execution or
+ other interpretation of the parameter value, as the parameter
+ value may be prose text. Implementations SHOULD present the
+ parameter (after reassembly of continuation parameters, etc.)
+ as information related to the media type, particularly if the
+ media content is not immediately available (e.g., as with
+ message/external-body composite media [N3.RFC2046]).
+
+ resources: Lists any additional files or programs that are
+ required for formatting (e.g., via .cf, .nx, .pi, .so, and/or
+ .sy directives).
+
+ versions: Human-readable indication of any known specific versions
+ of preprocessors, formatter, macro packages, postprocessors,
+ etc., required to process the content.
+
+ Encoding considerations:
+
+ 7bit is adequate for traditional troff provided line endings are
+ canonicalized per [N3.RFC2046]. Transfer of this media type
+ content via some transport mechanisms may require or benefit
+ from encoding into a 7bit range via a suitable encoding method
+ such as the ones described in [N4.RFC2045]. In particular,
+ some lines in this media type might begin or end with
+ whitespace, and that leading and/or trailing whitespace might
+ be discarded or otherwise mangled if the media type is not
+ encoded for transport.
+
+ 8bit may be used with Unicode characters represented as a series
+ of octets using the utf-8 charset [I4.RFC3629], where transport
+ methods permit 8bit content and where content line length is
+ suitable. Transport encoding considerations for robustness may
+ also apply, and if a suitable 8bit encoding mechanism is
+ standardized, it might be applicable for protection of media
+ during transport.
+
+
+
+
+
+Lilly Informational [Page 4]
+
+RFC 4263 Media Type text/troff January 2006
+
+
+ binary may be necessary when raw Unicode is used or where line
+ lengths exceed the allowable maximum for 7bit and 8bit content
+ [N4.RFC2045], and may be used in environments (e.g., HTTP
+ [I5.RFC2616]) where Unicode characters may be transferred via a
+ non-MIME charset such as UTF-16 [I6.RFC2781].
+
+ framed encoding MAY be used, but is not required and is not
+ generally useful with this media type.
+
+ Restrictions on usage: none
+
+ Security considerations: Some troff directives (.sy and .pi) can
+ cause arbitrary external programs to be run. Several troff
+ directives (.so, .nx, and .cf) may read external files (and/or
+ devices on systems that support device input via file system
+ semantics) during processing. Several preprocessors have similar
+ features. Some implementations have a "safe" mode that disables
+ some of these features. Formatters and preprocessors are
+ programmable, and it is possible to provide input which specifies
+ an infinite loop, which could result in denial of service, even in
+ implementations that restrict use of directives that access
+ external resources. Users of this media type SHOULD be vigilant
+ of the potential for damage that may be caused by careless
+ processing of media obtained from untrusted sources.
+
+ Processing of this media type other than by facilities that strip
+ or ignore potentially dangerous directives, and processing by
+ preprocessors and/or postprocessors, SHOULD NOT be invoked
+ automatically (i.e., without user confirmation). In some cases,
+ as this is a text media type (i.e., it contains text that is
+ comprehensible without processing), it may be sufficient to
+ present the media type with no processing at all. However, like
+ any other text media, this media type may contain control
+ characters, and implementers SHOULD take precautions against
+ untoward consequences of sending raw control characters to display
+ devices.
+
+ Users of this media type SHOULD carefully scrutinize suggested
+ command lines associated with the "process" parameter, contained
+ in comments within the media, or conveyed via external mechanisms,
+ both for attempts at social engineering and for the effects of
+ ill-considered values of the parameter. While some
+ implementations may have "safe" modes, those using this media type
+ MUST NOT presume that they are available or active.
+
+ Comments may be included in troff source; comments are not
+ formatted for output. However, they are of course readable in the
+ troff document source. Authors should be careful about
+
+
+
+Lilly Informational [Page 5]
+
+RFC 4263 Media Type text/troff January 2006
+
+
+ information placed in comments, as such information may result in
+ a leak of information, or may have other undesirable consequences.
+
+ While it is possible to overlay text with graphics or otherwise
+ produce formatting instructions that would visually obscure text
+ when formatted, such measures do not prevent extracting text from
+ the document source, and might be ineffective in obscuring text
+ when formatted electronically, e.g., as PostScript or PDF.
+
+ Interoperability considerations: Recent implementations of
+ formatters, macro packages, and preprocessors may include some
+ extended capabilities that are not present in earlier
+ implementations. Use of such extensions obviously limits the
+ ability to produce consistent formatted output at sites with
+ implementations that do not support those extensions. Use of any
+ such extensions in a particular document using this media type
+ SHOULD be indicated via the "versions" parameter value.
+
+ As mentioned in the Introduction, macro packages are troff
+ documents, and their content may be subject to copyright. That
+ has led to multiple independent implementations of macro packages,
+ which may exhibit gross or subtle differences with some content.
+
+ Some preprocessors or postprocessors might be unavailable at some
+ sites. Where some implementation is available, there may be
+ differences in implementation that affect the output produced.
+ For example, some versions of the "pic" preprocessor provide the
+ capability to fill a bounded graphical object; others lack that
+ capability. Of those that support that feature, there are
+ differences in whether a solid fill is represented by a value of
+ 0.0 vs. 1.0. Some implementations support only gray-scale output;
+ others support color.
+
+ Preprocessors or postprocessors may depend on additional programs
+ such as awk, and implementation differences (including bugs) may
+ lead to different results on different systems (or even on the
+ same system with a different environment).
+
+ There is a wide variation in the capabilities of various
+ presentation media and the devices used to prepare content for
+ presentation. Indeed, that is one reason that there are two basic
+ formatter program types (nroff for output where limited formatting
+ control is available, and troff where a greater range of control
+ is possible). Clearly, a document designed to use complex or
+ sophisticated formatting might not be representable in simpler
+ media or with devices lacking certain capabilities. Often it is
+ possible to produce a somewhat inferior approximation; colors
+ might be represented as gray-scale values, accented characters
+
+
+
+Lilly Informational [Page 6]
+
+RFC 4263 Media Type text/troff January 2006
+
+
+ might be produced by overstriking, italics might be represented by
+ underlining, etc.
+
+ Various systems store text with different line ending codings.
+ For the purpose of transferring this media type between systems or
+ between applications using MIME methods, line endings MUST use the
+ canonical CRLF line ending per [N3.RFC2046].
+
+ Published specification: [N1.CSTR54]
+
+ Applications which use this media type: The following applications in
+ each sub-category are examples. The lists are not intended to be
+ exhaustive.
+
+ Preprocessors: tbl [I7.CSTR49], grap [I8.CSTR114], pic
+ [I9.CSTR116], chem [I10.CSTR122], eqn [I11.eqn], dformat
+ [I12.CSTR142]
+
+ Formatters: troff, nroff, Eroff, sqtroff, groff, awf, cawf
+
+ Format converters: deroff, troffcvt, unroff, troff2html, mm2html
+
+ Macro packages: man [I13.UNIXman1], me [I14.me], mm
+ [I15.DWBguide], ms [I16.ms], mv [I15.DWBguide], rfc
+ [I2.Lilly05]
+
+ Additional information:
+
+ Magic number(s): None; however, the content format is distinctive
+ (see "Published specification").
+
+ File extension(s): Files do not require any specific "extension".
+ Many are in use as a convenience for mechanized processing of
+ files, some associated with specific macro packages or
+ preprocessors; others are ad hoc. File names are orthogonal to
+ the nature of the content. In particular, while a file name or
+ a component of a name may be useful in some types of automated
+ processing of files, the name or component might not be capable
+ of indicating subtleties such as proportion of textual (as
+ opposed to image or formatting directive) content. This media
+ type SHOULD NOT be assigned a relationship with any file
+ "extension" where content may be untrusted unless there is
+ provision for human judgment that may be used to override that
+ relationship for individual files. Where appropriate, a file
+ name MAY be suggested by a suitable mechanism such as the one
+ specified in [I17.RFC2183] as amended by [N5.RFC2231] and
+ [N6.Errata].
+
+
+
+
+Lilly Informational [Page 7]
+
+RFC 4263 Media Type text/troff January 2006
+
+
+ Macintosh File Type Code(s): unknown
+
+ Person & email address to contact for further information:
+ Bruce Lilly
+ blilly@erols.com
+
+ Intended usage: COMMON
+
+ Author/Change controller: IESG
+
+ Consistency: The media has provision for comments; these are
+ sometimes used to convey recommended processing commands, to
+ indicate required resources, etc. To avoid confusing recipients,
+ senders SHOULD ensure that information specified in optional
+ parameters is consistent with any related information that may be
+ contained within the media content.
+
+5. Acknowledgements
+
+ The author would like to acknowledge the helpful comments provided by
+ members of the ietf-types mailing list.
+
+6. Security Considerations
+
+ Security considerations are discussed in the media registration.
+ Additional considerations may apply when the media subtype is used in
+ some contexts (e.g., MIME [I18.RFC2049]).
+
+7. Internationalization Considerations
+
+ The optional charset parameter may be used to indicate the charset of
+ the media type content. In some cases, that content's charset might
+ be carried through processing for display of text. In other cases,
+ combinations of octets in particular sequences are used to represent
+ glyphs that cannot be directly represented in the content charset.
+ In either of those categories, the language(s) of the text might not
+ be evident from the character content, and it is RECOMMENDED that a
+ suitable mechanism (e.g., [I19.RFC3282]) be used to convey text
+ language where such a mechanism is available [I20.BCP18]. Where
+ multiple languages are used within a single document, it may be
+ necessary or desirable to indicate the languages to readers directly
+ via explicit indication of language in the content. In still other
+ cases, the media type content (while readable and comprehensible in
+ text form) represents symbolic or graphical information such as
+ mathematical equations or chemical formulae, which are largely global
+ and language independent.
+
+
+
+
+
+Lilly Informational [Page 8]
+
+RFC 4263 Media Type text/troff January 2006
+
+
+8. IANA Considerations
+
+ IANA shall enter and maintain the registration information in the
+ media type registry as directed by the IESG.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Lilly Informational [Page 9]
+
+RFC 4263 Media Type text/troff January 2006
+
+
+Appendix A. Examples
+
+A.1. Data Format
+
+ The input:
+
+ Content-Type: text/troff ; process="dformat | pic -n | troff -ms"
+
+ Here's what an IP packet header looks like:
+
+ .begin dformat
+ style fill off
+ style bitwid 0.20
+ style recspread 0
+ style recht 0.33333
+ noname
+ 0-3 \0Version
+ 4-7 IHL
+ 8-15 \0Type of Service
+ 16-31 Total Length
+ noname
+ 0-15 Identification
+ 16-18 \0Flags
+ 19-31 Fragment Offset
+ noname
+ 0-7 Time to Live
+ 8-15 Protocol
+ 16-31 Header Checksum
+ noname
+ 0-31 Source Address
+ noname
+ 0-31 Destination Address
+ noname
+ 0-23 Options
+ 24-31 Padding
+ .end
+
+ produces as output:
+
+ Here's what an IP packet header looks like:
+
+
+
+
+
+
+
+
+
+
+
+Lilly Informational [Page 10]
+
+RFC 4263 Media Type text/troff January 2006
+
+
+ +-------+-------+---------------+-------------------------------+
+ |Version| IHL |Type of Service| Total Length |
+ 0------34------78-------------1516----+-----------------------31+
+ | Identification |Flags| Fragment Offset |
+ 0---------------+-------------1516--1819----------------------31+
+ | Time to Live | Protocol | Header Checksum |
+ 0--------------78-------------1516----------------------------31+
+ | Source Address |
+ 0-------------------------------------------------------------31+
+ | Destination Address |
+ 0-----------------------------------------------+-------------31+
+ | Options | Padding |
+ 0---------------------------------------------2324------------31+
+
+A.2. Simple Diagram
+
+ The input:
+
+ Content-Type: text/troff ; process="use pic -n then troff -ms"
+
+ The SMTP design can be pictured as:
+
+ .DS B
+ .PS
+ boxwid = 0.8
+ # arrow approximation that looks acceptable in troff and nroff
+ define myarrow X A: [ move right 0.055;\
+ "<" ljust;line right ($1 - 0.1);">" rjust;\
+ move right 0.045 ]\
+ X
+ User: box ht 0.333333 "User"
+ FS: box ht 0.666667 "File" "System" with .n at User.s -0, 0.333333
+ Client: box ht 1.333333 wid 1.1 "Client\-" "SMTP" \
+ with .sw at FS.se +0.5, 0
+ "SMTP client" rjust at Client.se -0, 0.166667
+ move to User.e ; myarrow(0.5)
+ move to FS.e ; myarrow(0.5)
+ move to Client.e ; SMTP: myarrow(1.8)
+ Server: box ht 1.333333 wid 1.1 "Server\-" "SMTP" \
+ with .sw at Here.x, Client.s.y
+ box invis ht 0.5 "SMTP" "Commands/Replies" with .s at SMTP.c
+ box invis ht 0.25 "and Mail" with .n at SMTP.c
+ "SMTP server" ljust at Server.sw -0, 0.166667
+ move to Server.e.x, FS.e.y ; myarrow(0.5)
+ FS2: box ht 0.666667 "File" "System" \
+ with .sw at Server.se.x +0.5, FS.s.y
+ .PE
+ .DE
+
+
+
+Lilly Informational [Page 11]
+
+RFC 4263 Media Type text/troff January 2006
+
+
+ produces as output:
+
+ The SMTP design can be pictured as:
+
+ +-------+ +----------+ +----------+
+ | User |<-->+ | | |
+ +-------+ | | SMTP | |
+ | |Commands/Replies | |
+ +-------+ | Client- |<--------------->+ Server- | +-------+
+ | | | SMTP | and Mail | SMTP | | |
+ | File |<-->+ | | |<-->+ File |
+ |System | | | | | |System |
+ +-------+ +----------+ +----------+ +-------+
+ SMTP client SMTP server
+
+Appendix B. Disclaimers
+
+ This document has exactly one (1) author.
+
+ In spite of the fact that the author's given name may also be the
+ surname of other individuals, and the fact that the author's surname
+ may also be a given name for some females, the author is, and has
+ always been, male.
+
+ The presence of "/SHE", "their", and "authors" (plural) in the
+ boilerplate sections of this document is irrelevant. The author of
+ this document is not responsible for the boilerplate text.
+
+ Comments regarding the silliness, lack of accuracy, and lack of
+ precision of the boilerplate text should be directed to the IESG, not
+ to the author.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Lilly Informational [Page 12]
+
+RFC 4263 Media Type text/troff January 2006
+
+
+Normative References
+
+ [N1.CSTR54] Ossanna, Joseph F., "NROFF/TROFF User's Manual",
+ Computing Science Technical Report No.54, Bell
+ Laboratories, Murray Hill, New Jersey, 1976.
+
+ [N2.BCP14] Bradner, S., "Key words for use in RFCs to Indicate
+ Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+ [N3.RFC2046] Freed, N. and N. Borenstein, "Multipurpose Internet
+ Mail Extensions (MIME) Part Two: Media Types", RFC
+ 2046, November 1996.
+
+ [N4.RFC2045] Freed, N. and N. Borenstein, "Multipurpose Internet
+ Mail Extensions (MIME) Part One: Format of Internet
+ Message Bodies", RFC 2045, November 1996.
+
+ [N5.RFC2231] Freed, N. and K. Moore, "MIME Parameter Value and
+ Encoded Word Extensions: Character Sets, Languages,
+ and Continuations", RFC 2231, November 1997.
+
+ [N6.Errata] RFC-Editor errata page,
+ http://www.rfc-editor.org/errata.html
+
+Informative References
+
+ [I1.RFC2223] Postel, J. and J. Reynolds, "Instructions to RFC
+ Authors", RFC 2223, October 1997.
+
+ [I2.Lilly05] Lilly, B., "Writing Internet-Drafts and Requests For
+ Comments using troff and nroff", Work in Progress, May
+ 2005.
+
+ [I3.RFC4288] Freed, N. and J. Klensin, "Media Type Specifications
+ and Registration Procedures", BCP 13, RFC 4288,
+ December 2005.
+
+ [I4.RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO
+ 10646", STD 63, RFC 3629, November 2003.
+
+ [I5.RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H.,
+ Masinter, L., Leach, P., and T. Berners-Lee,
+ "Hypertext Transfer Protocol -- HTTP/1.1", RFC 2616,
+ June 1999.
+
+ [I6.RFC2781] Hoffman, P. and F. Yergeau, "UTF-16, an encoding of
+ ISO 10646", RFC 2781, February 2000.
+
+
+
+
+Lilly Informational [Page 13]
+
+RFC 4263 Media Type text/troff January 2006
+
+
+ [I7.CSTR49] Lesk, M. E., "TBL - A Program for Setting Tables",
+ Bell Laboratories Computing Science Technical Report
+ #49, Murray Hill, New Jersey, 1976.
+
+ [I8.CSTR114] Bentley, Jon L. and Kernighan, Brian W., "Grap - A
+ Language for Typesetting Graphs Tutorial and User
+ Manual", Computing Science Technical Report No.114,
+ AT&T Bell Laboratories, Murray Hill, New Jersey, 1991.
+
+ [I9.CSTR116] Kernighan, Brian W., "Pic - A Graphics Language for
+ Typesetting User Manual", Computing Science Technical
+ Report No.116, AT&T Bell Laboratories, Murray Hill,
+ New Jersey, 1991.
+
+ [I10.CSTR122] Bentley, Jon L., Jelinski, Lynn W., and Kernighan,
+ Brian W., "Chem - A Program for Typesetting Chemical
+ Diagrams: User Manual", Computing Science Technical
+ Report No.122, AT&T Bell Laboratories, Murray Hill,
+ New Jersey, 1992.
+
+ [I11.eqn] Kernighan, Brian W, and Cherry, Lorinda L., "A System
+ for Typesetting Mathematics", Communications of the
+ ACM 18, 182-193, 1975.
+
+ [I12.CSTR142] Bentley, Jon L. "DFORMAT - A Program for Typesetting
+ Data Formats", Computing Science Technical Report
+ No.142, AT&T Bell Laboratories, Murray Hill, New
+ Jersey, 1988.
+
+ [I13.UNIXman1] AT&T Bell Laboratories, "UNIX TIME-SHARING SYSTEM
+ (VOLUME 1) : UNIX Programmer's Manual", Holt,
+ Rinehart, & Winston, 1979
+
+ [I14.me] Allman, Eric P., "Writing Papers With NROFF Using
+ -me", USD:19, University of California, Berkeley,
+ Berkeley, California, 1997.
+
+ [I15.DWBguide] AT&T Bell Laboratories, "Unix System V Documenter's
+ Workbench User's Guide", Prentice Hall, 1989
+
+ [I16.ms] Lesk, M. E., "Typing Documents on the UNIX System:
+ Using the -ms Macros with Troff and Nroff", 1978, in
+ "UNIX TIME-SHARING SYSTEM (VOLUME 2) : UNIX
+ Programmer's Manual", Holt, Rinehart, & Winston, 1979
+
+
+
+
+
+
+
+Lilly Informational [Page 14]
+
+RFC 4263 Media Type text/troff January 2006
+
+
+ [I17.RFC2183] Troost, R., Dorner, S., and K. Moore, "Communicating
+ Presentation Information in Internet Messages: The
+ Content-Disposition Header Field", RFC 2183, August
+ 1997.
+
+ [I18.RFC2049] Freed, N. and N. Borenstein, "Multipurpose Internet
+ Mail Extensions (MIME) Part Five: Conformance Criteria
+ and Examples", RFC 2049, November 1996.
+
+ [I19.RFC3282] Alvestrand, H., "Content Language Headers", RFC 3282,
+ May 2002.
+
+ [I20.BCP18] Alvestrand, H., "IETF Policy on Character Sets and
+ Languages", BCP 18, RFC 2277, January 1998.
+
+Author's Address
+
+ Bruce Lilly
+
+ EMail: blilly@erols.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Lilly Informational [Page 15]
+
+RFC 4263 Media Type text/troff January 2006
+
+
+Full Copyright Statement
+
+ Copyright (C) The Internet Society (2006).
+
+ This document is subject to the rights, licenses and restrictions
+ contained in BCP 78, and except as set forth therein, the authors
+ retain all their rights.
+
+ This document and the information contained herein are provided on an
+ "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
+ OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
+ ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
+ INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
+ INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
+ WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
+
+Intellectual Property
+
+ The IETF takes no position regarding the validity or scope of any
+ Intellectual Property Rights or other rights that might be claimed to
+ pertain to the implementation or use of the technology described in
+ this document or the extent to which any license under such rights
+ might or might not be available; nor does it represent that it has
+ made any independent effort to identify any such rights. Information
+ on the procedures with respect to rights in RFC documents can be
+ found in BCP 78 and BCP 79.
+
+ Copies of IPR disclosures made to the IETF Secretariat and any
+ assurances of licenses to be made available, or the result of an
+ attempt made to obtain a general license or permission for the use of
+ such proprietary rights by implementers or users of this
+ specification can be obtained from the IETF on-line IPR repository at
+ http://www.ietf.org/ipr.
+
+ The IETF invites any interested party to bring to its attention any
+ copyrights, patents or patent applications, or other proprietary
+ rights that may cover technology that may be required to implement
+ this standard. Please address the information to the IETF at
+ ietf-ipr@ietf.org.
+
+Acknowledgement
+
+ Funding for the RFC Editor function is provided by the IETF
+ Administrative Support Activity (IASA).
+
+
+
+
+
+
+
+Lilly Informational [Page 16]
+