As per Relevance of the word keywords, we have this rfc below:
Network Working Group D.
Request for Comments: 1154 R.
Prime Computer, Inc
April 1990
Encoding Header Field for Internet
1. Status of the
This RFC proposes an elective experimental Encoding header field
permit the mailing of multi-part, multi-structured messages
The use of Encoding updates RFC 1049 (Content-Type), and is
suggested update to RFCs 1113, 1114, and 1115 (Privacy Enhancement
[4,7,8].
Distribution of this memo is unlimited
2.
RFC 822 [2] defines an electronic mail message to consist of
parts, the message header and the message body, separated by
apparently blank line
The Encoding header field permits the message body itself to
further broken up into parts, each part also separated from the
by an apparently blank line
Thus, conceptually, a message has a header part, followed by one
more body parts, all separated by blank lines
Each body part has an encoding type. The default (no Encoding
in the header) is a message body of one part of type "text".
3. The Encoding
The Encoding field consists of one or more subfields, separated
commas. Each subfield corresponds to a part of the message, in
order of that part's appearance. A subfield consists of a
count, a keyword defining the encoding, and optional
relevant only to the specific encoding. The line count is
in the last subfield
3.1. Format of the Encoding
The format of the Encoding field is
Robinson & Ullmann [Page 1]
RFC 1154 Encoding Header Field for Internet Messages April 1990
[ [], ]* [] []
where
:= a decimal
:= a single alphanumeric token starting with an
:= keyword-dependent
3.2.
The line count is a decimal number specifying the number of
lines in the part. Parts are separated by a blank line, which is
included in the count of either the proceeding or following part
Because a count always begins with a digit and a keywords
begins with an letter, it is always possible to determine if
count is present. (The count is first because it is the
information of interest when skipping over the part.)
The count is not required on the last or only part
3.3.
The keyword defines the encoding type. The keyword is a
single word name for the encoding type. The keywords are not case
sensitive
The list of standard keywords is intended to be the same as the
used for the Content-Type: header described in [6]. This
proposes additions to the list. Implementations can then
"Content-Type" as an alias of "Encoding", which will always have
one body part
3.4.
The optional information is used to specify additional keyword
specific information needed for interpreting the contents of
encoded part. It is any sequence of tokens not containing a comma
3.5. Encoding Version
In general, version numbers for encodings, when not
available within the contents of the encoded information, will
handled as options
3.6.
Comments enclosed in parentheses may, of course, be inserted
in the Encoding field. Mail reading systems may pass the comments
Robinson & Ullmann [Page 2]
RFC 1154 Encoding Header Field for Internet Messages April 1990
their clients. Comments must not be used by mail reading systems
content interpretation; that is the function of options
4.
This section describes some of the defined encodings used
As with the other keyword-defined parts of the header
standard, extensions in the form of new keywords are expected
welcomed. Several basic principles should be followed in
encodings
- The keyword should be the most common single word name for
encoding, including acronyms if appropriate. The intent is
different implementors will be likely to choose the same name
the same encoding
- Keywords not be too general: "binary" would have been a
choice for the "hex" encoding
- The encoding should be as free from unnecessary
as possible, except when conforming to an existing standard,
which case there is nothing that can be done
- The encoding should, if possible, use only the 7 bit
printing characters if it is a complete transformation of a
document (e.g., "hex" or "uuencode"). If it is essentially a
format, the full range may be used. If there is an
standard, the character set may already be defined
Keywords beginning with "X-" are permanently reserved
implementation-specific use. No standard registered encoding
will ever begin with "X-".
4.1.
This indicates that the message is in no particular encoded format
but is to be presented to the user as is
The full range of the ASCII character set is used. The message
expected to consist of lines of reasonable length (less than 1000
characters).
On some transport services, only the 7 bit subset of ASCII can
used. Where full 8 bit transparency is available, the text
assumed to be ISO 8859-1 [3] (ASCII-8).
Robinson & Ullmann [Page 3]
RFC 1154 Encoding Header Field for Internet Messages April 1990
4.2.
This encoding indicates that the body part is itself in the format
an Internet message, with its own header part and body part(s).
"message" body part's message header may be a full internet
header or it may consist only of an Encoding field
Using the message encoding on returned mail makes it practical for
mail reading system to implement a reliable resending function,
the mailer generates it when returning contents. It is also
in a "copy append" MUA operation
Message encoding is also used when mapping to X.400 to
recursively included X.400 P2 messages
4.3.
The encoding indicates that the body part contains binary data
encoded as 2 hexadecimal digits per byte, highest significant
first
Lines consist of an even number of hexadecimal digits. Blank
are not permitted. The decode process must accept lines with
2 and 1000 characters, inclusive
4.4.
EVFU (Electronic Vertical Format Unit) specifies that each
begins with a one-character "channel selector". The original
was to select a channel on a paper tape loop controlling the printer
This encoding is sometimes called "FORTRAN" format. It is the
output format of FORTRAN programs on a number of computer systems
The legal characters are '0' to '9', '+', '-', and space.
correspond to the 12 rows (and absence of a punch) on a
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
0 skip a line, i.e., double-
+ over-print the preceeding
- skip 2 lines, i.e., triple-
(space) print on the next line, single-
Robinson & Ullmann [Page 4]
RFC 1154 Encoding Header Field for Internet Messages April 1990
4.5.
The EDI (Electronic Document Interchange) keyword indicates that
message or part is a business document, formatted according to
X12 or related standards
The first word after the EDI keyword indicates the
interchange standard
A message containing a note and 2 X12 purchase orders might have
encoding of
Encoding: 17 TEXT, 146 EDI X12, 69 EDI X12
4.6. X.400
The Encoding header field provides a mechanism for mapping multi-
messages between CCITT X.400 [1] and RFC 822.
The X.400 keyword specifies a section that is converted from an X.400
body part type not known to the gateway, or not corresponding to
useful internet encoding
If the message transits another gate, or if the receiving user
the appropriate software, it can be decoded and used
The X.400 keyword is followed by a second token indicating the
used. The simplest form is "X.400 HEX", with the complete X.409
encoding of the body part in hexadecimal. More compact is "X.400
3/4", using the 3-byte to 4-character encoding as specified in
1113, section 4.3.2.4.
4.7.
The uuencode keyword specifies a section consisting of the output
the uuencode program supplied as part of uucp
4.8.
The encrypted keyword indicates that the section is encrypted
the methods in RFC 1115 [8]. This replaces the possible use of
934 [5] encapsulation
[1] International Telegraph and Telephone Consultative Committee
"Data Communication Networks: Message Handling Systems", In
Recommendations X.400 to X.430, VIIIth Plenary Assembly, Malaga
Robinson & Ullmann [Page 5]
RFC 1154 Encoding Header Field for Internet Messages April 1990
Torremolinos, 1984, Fascicle VIII.7 ("Red Book").
[2] Crocker, D., "Standard for the Format of ARPA Internet
Messages", RFC 822, University of Delaware, August 1982.
[3] International Organization for Standardization, "
processing - 8-bit single-byte coded graphic character sets -
Part 1: Latin alphabet No. 1", ISO 8859-1, ISO, 1987.
[4] Linn, J., "Privacy Enhancement for Internet Electronic Mail:
I -- Message Encipherment and Authentication Procedures",
1113, IAB Privacy Task Force, August 1989.
[5] Rose, M., and E. Stefferud, "Proposed Standard for
Encapsulation", RFC 943, University of Delaware and NMA,
1985.
[6] Sirbu, M., "Content-type Header Field for Internet Messages",
1049, CMU, March 1988.
[7] Kent, S., and J. Linn, "Privacy Enhancement for
Electronic Mail: Part II -- Certificate-Based Key Management",
RFC 1114, IAB Privacy Task Force, August 1989.
[8] Linn, J., "Privacy Enhancement for Internet Electronic Mail:
III -- Algorithms, Modes, and Identifiers", RFC 1115, IAB
Task Force, August 1989.
Security
Security issues are not addressed in this memo
Authors'
David Robinson 10-30
Prime Computer, Inc
500 Old Connecticut
Framingham, MA 01701
Phone: +1 508 879 2960 x1774
Email: DRB@Relay.Prime.
Robert Ullmann 10-30
Prime Computer, Inc
500 Old Connecticut
Framingham, MA 01701
Robinson & Ullmann [Page 6]
RFC 1154 Encoding Header Field for Internet Messages April 1990
Phone: +1 508 879 2960 x1736
Email: Ariel@Relay.Prime.
Robinson & Ullmann [Page 7]
if you see any problems within the linking, don't worry be happy,
this is version 0.1 of the Relevance System and you gotta expect some crappy subroutines sometimes,
just be content we did not write this in Java, which would have made this "bigger and better" HAHAHHA.
RFC documents can be found at I.E.T.F.
Relevance System Copyright © 2002 Spectrum WorldResearch
other technical nosh by ServerMasters Corporation
collaboration of BobX
