📄 rfc1505.txt
字号:
Network Working Group A. Costanzo
Request for Comments: 1505 AKC Consulting
Obsoletes: 1154 D. Robinson
Computervision Corporation
R. Ullmann
August 1993
Encoding Header Field for Internet Messages
Status of this Memo
This memo defines an Experimental Protocol for the Internet
community. It does not specify an Internet standard. Discussion and
suggestions for improvement are requested. Please refer to the
current edition of the "IAB Official Protocol Standards" for the
standardization state and status of this protocol. Distribution of
this memo is unlimited.
IESG Note
Note that a standards-track technology already exists in this area
[11].
Abstract
This document expands upon the elective experimental Encoding header
field which permits the mailing of multi-part, multi-structured
messages. It replaces RFC 1154 [1].
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . 3
2. The Encoding Field . . . . . . . . . . . . . . . . . 3
2.1 Format of the Encoding Field . . . . . . . . . . . 3
2.2 <count> . . . . . . . . . . . . . . . . . . . . . 4
2.3 <keyword> . . . . . . . . . . . . . . . . . . . . 4
2.3.1 Nested Keywords . . . . . . . . . . . . . . . . 4
2.4 Comments . . . . . . . . . . . . . . . . . . . . . 4
3. Encodings . . . . . . . . . . . . . . . . . . . . . 5
3.1 Text . . . . . . . . . . . . . . . . . . . . . . . 5
3.2 Message . . . . . . . . . . . . . . . . . . . . . 6
3.3 Hex . . . . . . . . . . . . . . . . . . . . . . . 6
3.4 EVFU . . . . . . . . . . . . . . . . . . . . . . . 6
3.5 EDI-X12 and EDIFACT . . . . . . . . . . . . . . . 7
3.6 FS . . . . . . . . . . . . . . . . . . . . . . . 7
3.7 LZJU90 . . . . . . . . . . . . . . . . . . . . . . 7
3.8 LZW . . . . . . . . . . . . . . . . . . . . . . . 7
Costanzo, Robinson & Ullmann [Page 1]
RFC 1505 Encoding Header Field August 1993
3.9 UUENCODE . . . . . . . . . . . . . . . . . . . . . 7
3.10 PEM and PEM-Clear . . . . . . . . . . . . . . . . 8
3.11 PGP . . . . . . . . . . . . . . . . . . . . . . . 8
3.12 Signature . . . . . . . . . . . . . . . . . . . 10
3.13 TAR . . . . . . . . . . . . . . . . . . . . . . 10
3.14 PostScript . . . . . . . . . . . . . . . . . . . 10
3.15 SHAR . . . . . . . . . . . . . . . . . . . . . . 10
3.16 Uniform Resource Locator . . . . . . . . . . . . 10
3.17 Registering New Keywords . . . . . . . . . . . . 11
4. FS (File System) Object Encoding . . . . . . . . . 11
4.1 Sections . . . . . . . . . . . . . . . . . . . . 12
4.1.1 Directory . . . . . . . . . . . . . . . . . . 12
4.1.2 Entry . . . . . . . . . . . . . . . . . . . . 13
4.1.3 File . . . . . . . . . . . . . . . . . . . . . 13
4.1.4 Segment . . . . . . . . . . . . . . . . . . . 13
4.1.5 Data . . . . . . . . . . . . . . . . . . . . . 14
4.2 Attributes . . . . . . . . . . . . . . . . . . . 14
4.2.1 Display . . . . . . . . . . . . . . . . . . . 14
4.2.2 Comment . . . . . . . . . . . . . . . . . . . 15
4.2.3 Type . . . . . . . . . . . . . . . . . . . . . 15
4.2.4 Created . . . . . . . . . . . . . . . . . . . 15
4.2.5 Modified . . . . . . . . . . . . . . . . . . . 15
4.2.6 Accessed . . . . . . . . . . . . . . . . . . . 15
4.2.7 Owner . . . . . . . . . . . . . . . . . . . . 15
4.2.8 Group . . . . . . . . . . . . . . . . . . . . 16
4.2.9 ACL . . . . . . . . . . . . . . . . . . . . . 16
4.2.10 Password . . . . . . . . . . . . . . . . . . . 16
4.2.11 Block . . . . . . . . . . . . . . . . . . . . 16
4.2.12 Record . . . . . . . . . . . . . . . . . . . . 17
4.2.13 Application . . . . . . . . . . . . . . . . . 17
4.3 Date Field . . . . . . . . . . . . . . . . . . . 17
4.3.1 Syntax . . . . . . . . . . . . . . . . . . . . 17
4.3.2 Semantics . . . . . . . . . . . . . . . . . . 17
5. LZJU90: Compressed Encoding . . . . . . . . . . . 18
5.1 Overview . . . . . . . . . . . . . . . . . . . . 18
5.2 Specification of the LZJU90 compression . . . . 19
5.3 The Decoder . . . . . . . . . . . . . . . . . . 21
5.3.1 An example of an Encoder . . . . . . . . . . . 27
5.3.2 Example LZJU90 Compressed Object . . . . . . . 33
6. Alphabetical Listing of Defined Encodings . . . . 34
7. Security Considerations . . . . . . . . . . . . . 34
8. References . . . . . . . . . . . . . . . . . . . . 34
9. Acknowledgements . . . . . . . . . . . . . . . . . 35
10. Authors' Addresses . . . . . . . . . . . . . . . . 36
Costanzo, Robinson & Ullmann [Page 2]
RFC 1505 Encoding Header Field August 1993
1. Introduction
STD 11, RFC 822 [2] defines an electronic mail message to consist of
two parts, the message header and the message body, separated by a
blank line.
The Encoding header field permits the message body itself to be
further broken up into parts, each part also separated from the next
by a blank line. Thus, conceptually, a message has a header part,
followed by one or more body parts, all separated by apparently blank
lines. Each body part has an encoding type. The default (no
Encoding field in the header) is a one part message body of type
"Text".
The purpose of Encoding is to be descriptive of the content of a mail
message without placing constraints on the content or requiring
additional structure to appear in the body of the message that will
interfere with other processing.
A similar message format is used in the network news facility, and
posted articles are often transferred by gateways between news and
mail. The Encoding field is perhaps even more useful in news, where
articles often are uuencoded or shar'd, and have a number of
different nested encodings of graphics images and so forth. In news
in particular, the Encoding header keeps the structural information
within the (usually concealed) article header, without affecting the
visual presentation by simple news-reading software.
2. The Encoding Field
The Encoding field consists of one or more subfields, separated by
commas. Each subfield corresponds to a part of the message, in the
order of that part's appearance. A subfield consists of a line count
and a keyword or a series of nested keywords defining the encoding.
The line count is optional in the last subfield.
2.1 Format of the Encoding Field
The format of the Encoding field is:
[ <count> <keyword> [ <keyword> ]* , ]*
[ <count> ] <keyword> [ <keyword> ]*
where:
<count> := a decimal integer
<keyword> := a single alphanumeric token starting with an alpha
Costanzo, Robinson & Ullmann [Page 3]
RFC 1505 Encoding Header Field August 1993
2.2 <count>
The line count is a decimal number specifying the number of text
lines in the part. Parts are separated by a blank line, which is not
included in the count of either the preceding or following part.
Blank lines consist only of CR/LF. Count may be zero, it must be
non-negative.
It is always possible to determine if the count is present because a
count always begins with a digit and a keyword always begins with a
letter.
The count is not required on the last or only part. A multi-part
message that consists of only one part is thus identical to a
single-part message.
2.3 <keyword>
Keyword defines the encoding type. The keyword is a common single-
word name for the encoding type and is not case-sensitive.
Encoding: 107 Text
2.3.1 Nested Keywords
Nested keywords are a series of keywords defining a multi-encoded
message part. The encoding keywords may either be an actual series
of encoding steps the encoder used to generate the message part or
may merely be used to more precisely identify the type of encoding
(as in the use of the keyword "Signature").
Nested keywords are parsed and generated from left to right. The
order is significant. A decoding application would process the list
from left to right, whereas, an encoder would process the Internet
message and generate the nested keywords in the reverse order of the
actual encoding process.
Encoding: 458 uuencode LZW tar (Unix binary object)
2.4 Comments
Comments enclosed in parentheses may be inserted anywhere in the
encoding field. Mail reading systems may pass the comments to their
clients. Comments must not be used by mail reading systems for
content interpretation. Other parameters defining the type of
encoding must be contained within the body portion of the Internet
message or be implied by a keyword in the encoding field.
Costanzo, Robinson & Ullmann [Page 4]
RFC 1505 Encoding Header Field August 1993
3. Encodings
This section describes some of the defined encodings used. An
alphabetical listing is provided in Section 6.
As with the other keyword-defined parts of the header format
standard, new keywords are expected and welcomed. Several basic
principles should be followed in adding encodings. The keyword
should be the most common single word name for the encoding,
including acronyms if appropriate. The intent is that different
implementors will be likely to choose the same name for the same
encoding. Keywords should not be too general: "binary" would have
been a bad choice for the "hex" encoding.
The encoding should be as free from unnecessary idiosyncracies as
possible, except when conforming to an existing standard, in which
case there is nothing that can be done.
The encoding should, if possible, use only the 7 bit ASCII printing
characters if it is a complete transformation of a source document
(e.g., "hex" or "uuencode"). If it is essentially a text format, the
full range may be used. If there is an external standard, the
character set may already be defined. Keywords beginning with "X-"
are permanently reserved to implementation-specific use. No standard
registered encoding keyword will ever begin with "X-".
New encoding keywords which are not reserved for implementation-
specific use must be registered with the Internet Assigned Numbers
Authority (IANA). Refer to section 3.17 for additional information.
3.1 Text
This indicates that the message is in no particular encoded format,
but is to be presented to the user as-is.
The text is ISO-10646-UTF-1 [3]. As specified in STD 10, RFC 821
[10], the message is expected to consist of lines of reasonable
length (less than or equal to 1000 characters).
On some older implementations of mail and news, only the 7 bit subset
of ISO-10646-UTF-1 can be used. This is identical to the ASCII 7 bit
code. On some mail transports that are not compliant with STD 10,
RFC 821 [10], line length may be restricted by the service.
Text may be followed by a nested keyword to define the encoded part
further, e.g., "signature":
Encoding: 496 Text, 8 Text Signature
Costanzo, Robinson & Ullmann [Page 5]
RFC 1505 Encoding Header Field August 1993
An automated file sending service may find this useful, for example,
to differentiate between and ignore the signature area when parsing
the body of a message for file requests.
3.2 Message
This encoding indicates that the body part is itself in the format of
an Internet message, with its own header part and body part(s). A
"message" body part's message header may be a full Internet message
header or it may consist only of an Encoding field.
Using the message encoding on returned mail makes it practical for a
mail reading system to implement a reliable automatic resending
function, if the mailer generates it when returning contents. It is
also useful in a "copy append" MUA (mail user agent) operation.
MTAs (mail transfer agents) returning mail should generate an
Encoding header. Note that this does not require any parsing or
transformation of the returned message; the message is simply
appended un-modified; MTAs are prohibited from modifying the content
of messages.
Encoding: 7 Text (Return Reason), Message (Returned Mail)
3.3 Hex
The encoding indicates that the body part contains binary data,
encoded as 2 hexadecimal digits per byte, highest significant nibble
first.
Lines consist of an even number of hexadecimal digits. Blank lines
are not permitted. The decode process must accept lines with between
2 and 1000 characters, inclusive.
The Hex encoding is provided as a simple way of providing a method of
encoding small binary objects.
3.4 EVFU
EVFU (electronic vertical format unit) specifies that each line
begins with a one-character "channel selector". The original purpose
was to select a channel on a paper tape loop controlling the printer.
This encoding is sometimes called "FORTRAN" format. It is the
default output format of FORTRAN programs on a number of computer
systems.
Costanzo, Robinson & Ullmann [Page 6]
RFC 1505 Encoding Header Field August 1993
The legal characters are '0' to '9', '+', '-', and space. These
correspond to the 12 rows (and absence of a punch) on a printer
control tape (used when the control unit was electromechanical).
The channels that have generally agreed definitions are:
1 advances to the first print line on the next page
0 skip a line, i.e., double-space
+ over-print the preceeding line
- skip 2 lines, i.e., triple-space
(space) print on the next line, single-space
3.5 EDI-X12 and EDIFACT
The EDI-X12 and EDIFACT keywords indicate that the message or part is
a EDI (Electronic Document Interchange) business document, formatted
according to ANSI X12 or the EDIFACT standard.
A message containing a note and 2 X12 purchase orders might have an
encoding of:
Encoding: 17 TEXT, 146 EDI-X12, 69 EDI-X12
3.6 FS
The FS (File System) keyword specifies a section consisting of
encoded file system objects. This encoding method (defined in
section 4) allows the moving of a structured set of files from one
environment to another while preserving all common elements.
3.7 LZJU90
The LZJU90 keyword specifies a section consisting of an encoded
binary or text object. The encoding (defined in section 5) provides
both compression and representation in a text format.
3.8 LZW
The LZW keyword specifies a section consisting of the data produced
by the Unix compress program.
3.9 UUENCODE
The uuencode keyword specifies a section consisting of the output of
the uuencode program supplied as part of uucp.
Costanzo, Robinson & Ullmann [Page 7]
RFC 1505 Encoding Header Field August 1993
⌨️ 快捷键说明
复制代码
Ctrl + C
搜索代码
Ctrl + F
全屏模式
F11
切换主题
Ctrl + Shift + D
显示快捷键
?
增大字号
Ctrl + =
减小字号
Ctrl + -