As per Relevance of the word canonical, we have this rfc below:
Request For Comments: 886
Proposed Standard for Message Header
Thu Dec 15 03:37:52 1983
Marshall T.
Department of Information and Computer
University of California,
Irvine, CA 92717
MRose.UCI@Rand-
This memo proposes a standard for the ARPA Internet community.
this proposal is adopted, hosts on the ARPA Internet that do
translation would be expected to adopt and implement this standard
Request For Comments: 886 M.
Proposed Standard for Message Header Munging
This memo describes the rules that are to be used when mail
transformed from one standard format to another. The scope of
memo is limited to text messages (computer network mail,
electronic mail) that traverse the ARPA Internet. This memo is
presented as a replacement or amendment for the "Standard for
Format of ARPA Internet Text Messages", RFC822. Rather, this
focuses on a particular aspect of mail, and provides a
and practical basis for implementors of transport agents and
agents which support message munging
Although this memo has been specifically prepared for use with
822 standard, an understanding of the 822 standard is not
to make use of this memo. The remainder of this section
the reader of some key concepts presented in the 822 standard,
how they relate to the perspective of this memo
Messages are viewed as consisting of an envelope and contents.
envelope is manipulated solely by transport agents, and
the information required by the transport agents to deliver
message to its recipients. Although this memo does not
itself directly to the envelope, we shall see that some of
rules discussed later are applicable to the envelope
The contents of the message consists of a rigorously
part, known as the headers, followed by a freely formated part
called the body. The message body is completely uninteresting
us. Our emphasis is strictly on the headers of the message.
header in the message consists of a field, its value, and
terminating end-of-line sequence. The 822 standard discusses
among other things, continuation lines, the syntax that is used
distinguish between fields and values, and the syntax and
of the values of various fields. For our part, we shall
ourselves only with the notion that the headers section consists
one or more headers, which are divided into one or more field/
pairs
The term "message munging" refers to the actions taken by
transport or user agent to transform the contents of a message
conformance with one standard format to another. The 822
refers to this as "Network-Specific Transformation". Other
might be "header munging" or "mail filtering". Regardless of
term used, the key notion is that this action transforms a
from its current format (the source message) to the
required by the target standard. A "munging agent", for
purposes of this memo, is an entity which performs message munging
A munging agent may be part of either a transport or user agent
Page 1
Request For Comments: 886 M.
Proposed Standard for Message Header Munging
As more networks connect into the ARPA Internet community,
users will exchange computer mail messages with other
hosts. Although the 822 standard must be strictly adhered to
mail that traverses the ARPA Internet, other networks might
internally adopt this standard. It is nevertheless desirable
permit mail to flow between hosts which internally conform to
standard and those which do not. The 822 standard is very clear
indicate that
"This standard is NOT intended to dictate the internal
used by sites, the specific message system features that
are expected to support, or any of the characteristics of
interface programs that create or read messages."
This plainly states that even hosts within the ARPA Internet,
opt to use a different standard than 822 for their internal use
but they are expressly required to use the 822 standard
transferring mail to other hosts in the ARPA Internet. As such,
is not difficult to imagine message munging becoming a
activity among transport and user agents
There are other reasons why message munging may become a
practice. An example from CSnet will serve here. The CSnet
provide authorized access for mail services to the ARPA
for the CSnet phonenet sites. CSnet sites are not registered
the NIC, and hence are often absent from the host tables of
Internet sites. As a result, addresses for mailboxes on
phonenet sites are unknown to ARPA Internet sites. From an
Internet site, it would be impossible to send messages to
addresses, since the local transport agent has no handle on
destination hosts of the phonenet mailboxes. Obviously,
replying to a such a message is simply not possible. To solve
problem, the transport agents on the CSnet relays perform
munging on mail destined for the ARPA Internet. Phonenet
of the form "mbox@host" are transformed to "mbox.host@relay",
"relay" is the ARPA Internet host name of the relay performing
transformation. Other addresses are left alone. Agents
the ARPA Internet are now able to process these addresses,
the host-part is a known ARPA Internet host
The source-routing solution to this problem will hopefully
replaced by domain handling when domains are implemented in the
Internet. When this is the case, phonenet addresses of the
"mbox@host" will become "mbox@host.CSNET". Despite this change
(which cannot help but be for the better, as the use
source-routing leads to a plethora of problems), message
will still occur as it will most likely be necessary to add
names during message transmission (see section 6.2.2 of the 822
Page 2
Request For Comments: 886 M.
Proposed Standard for Message Header Munging
standard).
For an alternate reason, consider that it is not unlikely for
to wish to transform mail from their archives which conforms to
older standard to the current standard. There could be
reasons for this, although a common one would be that a user
to re-introduce the message into the transport system.
the aged message was perfectly valid when it was composed (e.g.,
the days of the 733 standard), it might no longer conform to
current standard (i.e., 822). In this case, a user agent
have to perform message munging, in order to make the
acceptable to the local transport agent
To summarize, even under the most "homogeneous" of environments
message munging will still be required on the part of transport
user agents, under certain conditions
Section 3.4.10 of the 822 standard briefly discusses the topic
"Network-Specific Transformations". In short, the 822
envisions a message traversing net-A to reach net-B as
through three phases
o
The message is made to conform to net-A's
o Transformation
Net-A's idiosyncrasies are removed and the message
conforms to the 822
o
The message is made to conform to net-B's
This memo concerns itself solely with this section of the 822
standard. The 822 standard presents end-of-line sequences as
example of an area where transformation might occur. Although
is a valid concern, our emphasis deals with constructs of
semantics: fields and structured field values
Page 3
Request For Comments: 886 M.
Proposed Standard for Message Header Munging
This memo does not specify the particular transformation rules
should be used when munging a message from one standard to another
Rather, this memo attempts to make clear the policies that are
be followed when implementing any munging agent for the
Internet. The derivation of the formulas specific to
munging between two given standards is left to the implementors
such munging systems or to the writers of future RFCs. As such
this memo can be considered to present the philosophy
conceptual basis of message munging in the ARPA Internet
NOTE: It is critical that this position be understood.
actual policies used by domain-specific munging agents
completely beyond the scope of this memo
For ease of explanation, some of the examples in this memo
message munging between the ARPA Internet and the
distribution network as an example. This memo should NOT
considered to specify how this particular munging activity
take place. Instead, this context has been chosen for
familiarity and simplicity
Message
A munging agent concerns itself with transforming a message
conformance with a source standard to a message in conformance with
target standard. This transformation occurs at various levels.
of these are presented here
o Field
For two standards, some fields may convey identical
but have different names. As standards progress,
example, the names of fields may change, but the presence
those fields and their contents continue to have the
meaning. For example, prior to 822 standard, some
considered the Remailed- prefix to have semantics
to the 822 standard's Resent- prefix. In this circumstance
one aspect of message munging would be to simply
the field names
o Value
The value of certain fields may be viewed as
Page 4
Request For Comments: 886 M.
Proposed Standard for Message Header Munging
structured components. The syntax and semantics of
components may differ significantly between two formats.
this circumstance, one aspect of message munging would be
transform components from one representation to another
o Field/Value
The semantics of a given header in a particular standard
not be directly expressed using a single header from
standard. In this circumstance, one aspect of message
would be to map the field/value of a header in the
message to any number of headers in the target message (
vice-versa). As expected, further complication could
by performing value transformation in addition to one-to-
or many-to-one field transformation
o Header
Some standards may require that fields appear in a
order in the headers part of the message. Others make
requirements as to the order in which the fields appear.
this circumstance, one aspect of message munging from
latter to the former standard would be to capture the
information from the source message in order to construct
first field of the target message. As expected,
complication could result by requiring several field/values
consulted in the source message before sufficient context
present to construct the first field of the target message
Page 5
Request For Comments: 886 M.
Proposed Standard for Message Header Munging
Canonical
Fundamental to the activity of transformation is the notion of
canonical form. For a given message standard, each field
structured field value may be thought of as an object with
particular semantics that is representable by one or more strings
That is, each of these strings has an identical semantics, as
all refer to the same object. For example, in terms of the 822
standard, the two
The Protocol Police
NetSer@
are semantically equivalent. For the purposes of this memo,
fully-qualified canonical form of an object is thought of as
simplest string that represents the full and complete meaning of
object. The meaning of "simple" is, of course, open
interpretation. In some cases, "simplest" may mean "shortest".
other cases, a longer, but unabbreviated string may be "simpler
than a shorter string. Regardless of this, a canonical form is
representation of an object. This representation contains
smallest amount of information required to fully describe
meaning of the object
It is not difficult to determine what a canonical form
describe for different objects. In terms of the 822 standard,
following should be considered as minimal definitions of
forms
object specifies
------ --------- --------
field field-name
address mailbox local-
domain-
date date-time date-
time-
In terms of USENET, the following might be considered as
definitions of canonical forms
object specifies
------ --------- --------
field field-name
address mailbox
date date-time date-
time-
NOTE: This memo clearly has no authority to specify
Page 6
Request For Comments: 886 M.
Proposed Standard for Message Header Munging
minimal canonical forms for USENET. The above table is
solely for the benefit of the examples which follow
Conceptually, transformation of fields and structured field
occurs between canonical forms. That is, to transform an address
one reduces the string representing the object to its
form, to capture the essence of its meaning, and this form is
transformed, somehow, to the equivalent canonical form for
target standard. This target canonical form can later be
using a string representation
NOTE: This memo does not require that canonical forms
represented or otherwise implemented as strings. Nor
this standard require that strings be used during
transformation process. Thinking of a canonical form as
string is a convenient formalism only, not an
requirement
Page 7
Request For Comments: 886 M.
Proposed Standard for Message Header Munging
Transformation
All of the forms of message decomposition discussed above may
be viewed as transformation between canonical forms. Hence, it
becomes necessary to consider how canonical forms should
manipulated during transformation. That is, what rules are to
followed when constructing an equivalent canonical form? There
several guidelines that must be followed, that we will
in the following fashion
o Preservation of
All attempts must be made to preserve all
contained in the original canonical form. This
can be highly useful to the recipients of munged messages
Obviously, for two widely-differing formats, this may not
possible. For example, some standards may not have a
addressing notation such as the one present in the 822
standard, e.g., the
List: Support@UCI, ZOTnet@UCI
might not be permitted. If one were to consider membership
a group as part of an address' canonical form, then
portion of the canonical form could not be transformed to
other standard
The 822 standard supports a liberal commenting
which might prove quite useful in preserving information
Implementors may wish to consider capturing the
information in commentary text. For example, if the
mark@cbosgd.UUCP (Mark Horton
had the USENET canonical
user:
route: ucbvax!ihnp4!
and if the corresponding 822 canonical
local-part: ucbvax!ihnp4!cbosgd!
domain-part: USENET.
then it would not be unreasonable for an implementation
output this canonical form
"mark@cbosgd.UUCP"
Page 8
Request For Comments: 886 M.
Proposed Standard for Message Header Munging
NOTE: Implementors should exercise extreme caution
using a policy such as this. Information placed
commentary delimiters must still conform to the
standard at the syntactic level
Note however that in the above example, the
information "(Mark Horton)" was discarded. This practice
strongly discouraged. Although the canonical form for
object does not rely on commentary information as a
part, implementors are encouraged to preserve this
whenever possible
Finally, preservation of information requires preservation
case at all costs. Only under the most restrictive
circumstances should an implementation change the case of
strings output for a canonical form
o Re-
Ideally, the target message should have the exact
and vertical padding as the source message. Because a
representing the source canonical form of an object may not
of the same length as the string representing the
canonical form, the number of characters on each physical
logical line in the headers may be different
The 822 standard supports a header folding convention
permits long field/value pairs to be represented on more
one physical line. When a new canonical form is output to
target message, it is possible that the resulting field/
pair may be longer than the number of characters
antiquated display devices can present on a single line.
822 standard suggests 65 or 72 characters-per-line as a
for this limitation. Although not required, message
agents may re-fold headers if (and only if) this limitation
exceeded. Note however that under no circumstances should
header be re-folded if it was not munged. Refolding
munging may occur on behalf of some transport or user agent
but it may not occur on behalf of a munging agent. Put
simply, this memo does not authorize or forbid such activity
although it does discourage it
o Error
The preceding discussion has made been under the
that the objects composing the field/value pairs of the
message have conformed to the source standard. It is
unfortunate reality that this may not be the case. In fact
Page 9
Request For Comments: 886 M.
Proposed Standard for Message Header Munging
for those standards which are poorly specified (if at all),
determining that an object is improperly constructed might
quite difficult. In addition, it is possible,
hopefully extremely improbable that a target canonical
does not exist for a particular source canonical form.
these cases, munging agents must be able to recover
At this point, we introduce two extension fields for the 822
standard. As such, these fields are hereby designated
"reserved" and may not be used for other purposes.
fields are
Illegal-
Illegal-
The syntax of these fields is as follows
munge-field =
"Illegal-Field" ":" *
/ "Illegal-Object" ":" *
munge-object =
valid will be presented later
The semantics of these fields are as follows
An Illegal-Field header should be introduced when
header-line which does not conform to the source standard
found in the source message. Illegal-Field should be
only when a header-line is so poorly formed as to
recognition of the field in the header-line. For example,
the line lacks a colon, or has a poorly formed field-name
then it should not be output to the target message and a
header-line should be introduced in its place.
header-line has Illegal-Field as its field and contains
offending line as its value. Illegal-Field should not be
if the field can be identified, but the value is
formed
An Illegal-Object header should be introduced when an
in the source message can not be parsed into a canonical form
or if the canonical form it represents has no
target canonical form. The offending object should not
output to the target message in the header-line in which
occurs. If the header-line now contains no objects, then
header-line should not be output to the target message
well. Then, an Illegal-Object field should be introduced
the target message. The value of this Illegal-Object
should at the very minimum contain the name of the field
contained the object, the object in question, and
Page 10
Request For Comments: 886 M.
Proposed Standard for Message Header Munging
explanation as to why the object was illegal. Alternately
the value of this Illegal-Object field should consist of
entire header-line (field and value) that contained the
in question along with an explanation as to why the object
illegal
NOTE: In the circumstance where multiple objects
in a single header-line in the source message, and one
those objects is determined to be illegal, the
policy used in determining how much information can
considered to be "uncorrupted" is left to
implementors. Munging agents which use
parsers may attempt to recover in mid-stream (so
speak) and continue parsing objects on the header-line
Other agents may wish to continue recover with the
header-line in the source message. Regardless of
policy used, the agent must present the contents of
entire header-line in the associated Illegal-
header
Implementations should not take extraordinary measures
perform syntax/semantics checking of the source message --
only those fields which must be examined should be
checked. This memo strongly discourages any
examination. It is not the intention of this memo to
that composing agents should produce messages which do
conform to the source standard. A composing agent should
expect a munging agent to enforce adherence to the
standard
o Introduction of
Munging agents are authorized to introduce a "Received"
into the target message when a message is transformed
NOTE: Adding a "Received" header is entirely optional
This memo strongly recommends that this header
introduced whenever some munging (translation of
and/or dates) occurs
NOTE: Although this memo does not specify the
that the introduced header should have in relation to
other fields in the target message, it is
recommended that the introduced header be grouped
the other "Received" headers, at the very beginning
the message
When introducing a "Received" field, three phrases, which
normally optional in such a field, should be specified by
munging agent. These are
Page 11
Request For Comments: 886 M.
Proposed Standard for Message Header Munging
"from" domain # the source
"by" domain # the target
"with" protocol # the munging agent's
For example, suppose we have a munging agent on the UCI host
and that this agent services a USENET/ARPA boundary. When
UCI host gets a message from the USENET domain for the
domain, the following happens: First, the UCI mailsystem
prepend the header
Received: from nma by UCI with UUCP; 15 Dec 83 03:53:00
Second, the munging agent, when transforming the message
would prepend the header
Received: from USENET by ARPA with UCI; 15 Dec 03:54:00
Finally, the UCI mailsystem would then deliver the message
the appropriate ARPA mailsystem, which in turn would
the header
Received: from UCI by ISIF with SMTP; 15 Dec 83 03:55:00
This example might be a bit clearer if the domains
qualified a bit more. The first three lines of the
could look like this
Received: from UCI.ARPA by ISIF.ARPA; 15 Dec 83 03:55:00
Received: from USENET by ARPA with UCI; 15 Dec 03:54:00
Received: from nma.USENET by UCI.USENET; 15 Dec 83 03:53:00
The key point to notice is that the munging agent used
"from" and "by" clauses to denote the domain boundary that
crossed, and used the "with" clause to denote itself.
the agent is munging the message according to some set
transformation rules, it is actually using a "mail protocol",
and as such is justified in identifying itself in the "with
clause
Page 12
Request For Comments: 886 M.
Proposed Standard for Message Header Munging
Objects of
At present, only three types of objects are of interest: fields
addresses, and dates. In the context of the 822 standard
header-lines containing the following fields are to be viewed
appropriate for transformation
Address Fields: From, Sender, Reply-To, To, cc, Bcc
and any of these fields with the Resent-
Date Fields: Date, Resent-
Hence the definition of munge-object, in 822 terms, is
munge-object =
"From
/ "Sender
/ "Reply-To
/ "To
/ "cc
/ "Bcc
/ "Resent-From
/ "Resent-Sender
/ "Resent-Reply-To
/ "Resent-To
/ "Resent-cc
/ "Resent-Bcc
/ "Date
/ "Resent-Date
NOTE: The list of munge-objects is extensible. For
purposes of this memo, the above fields are defined as
MINIMUM list of munge-objects for the 822 standard
Implementors are encouraged to introduce other fields to
list of munge-objects as their munging agents require.
additions should also be registered with the revisions of
memo as they gain popularity
For the purposes of the remainder of this memo, an
header-line is defined as any header-line in the source
whose field component is one of the fields listed above as
address field. Further, a date header-line is defined as
header-line in the source message whose field component is one
the fields listed above as an date field
If address munging is performed, then all addresses contained
all address header-lines must be munged. It is expressly
to perform address munging on the source message and
performing address munging on every address header-line. Further
it is expressly forbidden to munge some, but not all, of
addresses in any address header-line. All addresses in all of
Page 13
Request For Comments: 886 M.
Proposed Standard for Message Header Munging
message's address header-lines must be address munged. If
munging is not performed, then these header-lines need not
considered for munging
A similar requirement is made for date munging. If date munging
performed, then all instances of header-lines whose field is
or Resent-Date must be fully date munged
NOTE: Certain fields are to be excluding from munging of
sort, all munging agents must preserve their contents exactly
At present, there is one such field: "Received". This
of this field should ALWAYS be preserved for trace
debugging purposes
Page 14
Request For Comments: 886 M.
Proposed Standard for Message Header Munging
D.H. Crocker, "Standard for the Format of ARPA Internet
Messages", RFC 822, (August, 1982).
M.R. Horton, "Standard for the Interchange of USENET Messages",
850, (June, 1983).
M.T. Rose, "Achieving Interoperability between two Domains --
Connecting the ZOTnet and UUCP Computer Mail Networks",
Report Number 201, Department of Information and Computer Science
University of California, Irvine, (January, 1983).
P.V. Mockapetris, "Domain Names -- Concepts and Facilities",
882, (November, 1983).
Page 15
Request For Comments: 886 M.
Proposed Standard for Message Header Munging
Minimal Canonical
This memo defines the minimal canonical forms for the 822 standard
Implementations may wish to augment these forms with
information that may be present in the source message. An
example suggested that group membership might be part of
address' canonical form. Further, since the 822 standard
routes to be specified in addresses, e.g.,
Fred Rated <@ISI-Troll.ARPA,@UCI-750a.UCI: FRated@UCI-750b
Perhaps they too should be considered part of the 822 address
canonical form
This memo makes no such requirement, if implementations wish
make use of this additional information, then they are free to
so. This practice is neither encouraged nor discouraged. In
the spirit of this memo is to require those minimal
required by the 822 standard, nothing more
Page 16
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
