From 4bfd864f10b68b71482b35c818559068ef8d5797 Mon Sep 17 00:00:00 2001 From: Thomas Voss Date: Wed, 27 Nov 2024 20:54:24 +0100 Subject: doc: Add RFC documents --- doc/rfc/rfc4263.txt | 899 ++++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 899 insertions(+) create mode 100644 doc/rfc/rfc4263.txt (limited to 'doc/rfc/rfc4263.txt') 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] + -- cgit v1.2.3