rfc886.txt

RFC 相关的技术文档

Request For Comments:  886 












	     Proposed Standard for Message Header Munging


		       Thu Dec 15 03:37:52 1983


			   Marshall T. Rose

	    Department of Information and Computer Science
		   University of California, Irvine
			   Irvine, CA 92717

			 MRose.UCI@Rand-Relay




    This memo proposes a standard for the ARPA Internet community. If
    this proposal is adopted, hosts on the ARPA Internet that do message
    translation would be expected to adopt and implement this standard.


























Request For Comments:  886 					 M. Rose
Proposed Standard for Message Header Munging			     UCI



			     Introduction

    This memo describes the rules that are to be used when mail is
    transformed from one standard format to another.  The scope of this
    memo is limited to text messages (computer network mail, or
    electronic mail) that traverse the ARPA Internet.  This memo is not
    presented as a replacement or amendment for the "Standard for the
    Format of ARPA Internet Text Messages", RFC822.  Rather, this memo
    focuses on a particular aspect of mail, and provides a conceptual
    and practical basis for implementors of transport agents and user
    agents which support message munging.

    Although this memo has been specifically prepared for use with the
    822 standard, an understanding of the 822 standard is not required
    to make use of this memo.  The remainder of this section reminds
    the reader of some key concepts presented in the 822 standard, and
    how they relate to the perspective of this memo.

    Messages are viewed as consisting of an envelope and contents.  The
    envelope is manipulated solely by transport agents, and contains
    the information required by the transport agents to deliver the
    message to its recipients.  Although this memo does not address
    itself directly to the envelope, we shall see that some of the
    rules discussed later are applicable to the envelope.

    The contents of the message consists of a rigorously structured
    part, known as the headers, followed by a freely formated part,
    called the body.  The message body is completely uninteresting to
    us.  Our emphasis is strictly on the headers of the message.  Each
    header in the message consists of a field, its value, and a
    terminating end-of-line sequence.  The 822 standard discusses,
    among other things, continuation lines, the syntax that is used to
    distinguish between fields and values, and the syntax and semantics
    of the values of various fields.  For our part, we shall concern
    ourselves only with the notion that the headers section consists of
    one or more headers, which are divided into one or more field/value
    pairs.

    The term "message munging" refers to the actions taken by a
    transport or user agent to transform the contents of a message from
    conformance with one standard format to another.  The 822 standard
    refers to this as "Network-Specific Transformation".  Other phrases
    might be "header munging" or "mail filtering".  Regardless of the
    term used, the key notion is that this action transforms a message
    from its current format (the source message) to the structure
    required by the target standard.  A "munging agent", for the
    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. Rose
Proposed Standard for Message Header Munging			     UCI



			      Background

    As more networks connect into the ARPA Internet community, their
    users will exchange computer mail messages with other Internet
    hosts.  Although the 822 standard must be strictly adhered to for
    mail that traverses the ARPA Internet, other networks might not
    internally adopt this standard.  It is nevertheless desirable to
    permit mail to flow between hosts which internally conform to the
    standard and those which do not.  The 822 standard is very clear to
    indicate that:

	 "This standard is NOT intended to dictate the internal formats
	 used by sites, the specific message system features that they
	 are expected to support, or any of the characteristics of user
	 interface programs that create or read messages."

    This plainly states that even hosts within the ARPA Internet, may
    opt to use a different standard than 822 for their internal use,
    but they are expressly required to use the 822 standard when
    transferring mail to other hosts in the ARPA Internet.  As such, it
    is not difficult to imagine message munging becoming a common
    activity among transport and user agents.

    There are other reasons why message munging may become a widespread
    practice.  An example from CSnet will serve here.  The CSnet relays
    provide authorized access for mail services to the ARPA Internet
    for the CSnet phonenet sites.  CSnet sites are not registered with
    the NIC, and hence are often absent from the host tables of ARPA
    Internet sites.  As a result, addresses for mailboxes on CSnet
    phonenet sites are unknown to ARPA Internet sites.  From an ARPA
    Internet site, it would be impossible to send messages to these
    addresses, since the local transport agent has no handle on the
    destination hosts of the phonenet mailboxes.  Obviously, even
    replying to a such a message is simply not possible.  To solve this
    problem, the transport agents on the CSnet relays perform message
    munging on mail destined for the ARPA Internet.  Phonenet addresses
    of the form "mbox@host" are transformed to "mbox.host@relay", where
    "relay" is the ARPA Internet host name of the relay performing the
    transformation.  Other addresses are left alone.  Agents throughout
    the ARPA Internet are now able to process these addresses, since
    the host-part is a known ARPA Internet host.

    The source-routing solution to this problem will hopefully be
    replaced by domain handling when domains are implemented in the ARPA
    Internet.  When this is the case, phonenet addresses of the form
    "mbox@host" will become "[e-mail]".  Despite this change,
    (which cannot help but be for the better, as the use of
    source-routing leads to a plethora of problems), message munging
    will still occur as it will most likely be necessary to add domain
    names during message transmission (see section 6.2.2 of the 822


Page 2

Request For Comments:  886 					 M. Rose
Proposed Standard for Message Header Munging			     UCI


    standard).

    For an alternate reason, consider that it is not unlikely for users
    to wish to transform mail from their archives which conforms to an
    older standard to the current standard.  There could be many
    reasons for this, although a common one would be that a user wishes
    to re-introduce the message into the transport system.  Although
    the aged message was perfectly valid when it was composed (e.g., in
    the days of the 733 standard), it might no longer conform to the
    current standard (i.e., 822).  In this case, a user agent would
    have to perform message munging, in order to make the message
    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 and
    user agents, under certain conditions.

    Section 3.4.10 of the 822 standard briefly discusses the topic of
    "Network-Specific Transformations".  In short, the 822 standard
    envisions a message traversing net-A to reach net-B as going
    through three phases:

	o Transformation
	  The message is made to conform to net-A's standards

	o Transformation Reversal
	  Net-A's idiosyncrasies are removed and the message now
	  conforms to the 822 standard

	o Transformation
	  The message is made to conform to net-B's standards

    This memo concerns itself solely with this section of the 822
    standard.  The 822 standard presents end-of-line sequences as an
    example of an area where transformation might occur.  Although this
    is a valid concern, our emphasis deals with constructs of higher
    semantics: fields and structured field values.
















Page 3

Request For Comments:  886 					 M. Rose
Proposed Standard for Message Header Munging			     UCI



				 Scope

    This memo does not specify the particular transformation rules that
    should be used when munging a message from one standard to another.

    Rather, this memo attempts to make clear the policies that are to
    be followed when implementing any munging agent for the ARPA
    Internet.  The derivation of the formulas specific to message
    munging between two given standards is left to the implementors of
    such munging systems or to the writers of future RFCs.  As such,
    this memo can be considered to present the philosophy and
    conceptual basis of message munging in the ARPA Internet.

	 NOTE:  It is critical that this position be understood.  The
	 actual policies used by domain-specific munging agents is
	 completely beyond the scope of this memo.

    For ease of explanation, some of the examples in this memo use
    message munging between the ARPA Internet and the USENET
    distribution network as an example.  This memo should NOT be
    considered to specify how this particular munging activity should
    take place.  Instead, this context has been chosen for its
    familiarity and simplicity.



			 Message Decomposition

    A munging agent concerns itself with transforming a message in
    conformance with a source standard to a message in conformance with a
    target standard.  This transformation occurs at various levels.  Four
    of these are presented here.


    o Field Transformation

	 For two standards, some fields may convey identical semantics
	 but have different names.  As standards progress, for
	 example, the names of fields may change, but the presence of
	 those fields and their contents continue to have the same
	 meaning.  For example, prior to 822 standard, some mailers
	 considered the Remailed- prefix to have semantics equivalent
	 to the 822 standard's Resent- prefix.  In this circumstance,
	 one aspect of message munging would be to simply substitute
	 the field names.


    o Value Transformation

	 The value of certain fields may be viewed as containing


Page 4

Request For Comments:  886 					 M. Rose
Proposed Standard for Message Header Munging			     UCI


	 structured components.  The syntax and semantics of these
	 components may differ significantly between two formats.  In
	 this circumstance, one aspect of message munging would be to
	 transform components from one representation to another.


    o Field/Value Combination

	 The semantics of a given header in a particular standard may
	 not be directly expressed using a single header from another
	 standard.  In this circumstance, one aspect of message munging
	 would be to map the field/value of a header in the source
	 message to any number of headers in the target message (or
	 vice-versa).  As expected, further complication could result
	 by performing value transformation in addition to one-to-many
	 or many-to-one field transformation.


    o Header Ordering

	 Some standards may require that fields appear in a particular
	 order in the headers part of the message.  Others make no
	 requirements as to the order in which the fields appear.  In
	 this circumstance, one aspect of message munging from the
	 latter to the former standard would be to capture the essential
	 information from the source message in order to construct the
	 first field of the target message. As expected, further
	 complication could result by requiring several field/values be
	 consulted in the source message before sufficient context is
	 present to construct the first field of the target message.























Page 5

Request For Comments:  886 					 M. Rose
Proposed Standard for Message Header Munging			     UCI



			    Canonical Forms

    Fundamental to the activity of transformation is the notion of a
    canonical form.  For a given message standard, each field and
    structured field value may be thought of as an object with a
    particular semantics that is representable by one or more strings.
    That is, each of these strings has an identical semantics, as they
    all refer to the same object.  For example, in terms of the 822
    standard, the two strings

	The Protocol Police <NetSer@UCI>

	NetSer@UCI

    are semantically equivalent.  For the purposes of this memo, a
    fully-qualified canonical form of an object is thought of as the
    simplest string that represents the full and complete meaning of an
    object.  The meaning of "simple" is, of course, open to
    interpretation.  In some cases, "simplest" may mean "shortest".  In
    other cases, a longer, but unabbreviated string may be "simpler"
    than a shorter string. Regardless of this, a canonical form is a
    representation of an object.  This representation contains the
    smallest amount of information required to fully describe the
    meaning of the object.

    It is not difficult to determine what a canonical form should
    describe for different objects.  In terms of the 822 standard, the
    following should be considered as minimal definitions of canonical
    forms:

	object		specifies	contains
	------		---------	--------
	field		field-name	name
	address		mailbox		local-part
					domain-part
	date		date-time 	date-part
					time-part

    In terms of USENET, the following might be considered as minimal
    definitions of canonical forms:

	object		specifies	contains
	------		---------	--------
	field		field-name	name
	address		mailbox		user
					route
	date		date-time 	date-part
					time-part

	 NOTE:  This memo clearly has no authority to specify the


Page 6

Request For Comments:  886 					 M. Rose
Proposed Standard for Message Header Munging			     UCI


	 minimal canonical forms for USENET.  The above table is listed
	 solely for the benefit of the examples which follow.

    Conceptually, transformation of fields and structured field values
    occurs between canonical forms.  That is, to transform an address,
    one reduces the string representing the object to its canonical
    form, to capture the essence of its meaning, and this form is then
    transformed, somehow, to the equivalent canonical form for the
    target standard.  This target canonical form can later be output
    using a string representation.

	 NOTE:  This memo does not require that canonical forms be
	 represented or otherwise implemented as strings.  Nor does
	 this standard require that strings be used during the
	 transformation process. Thinking of a canonical form as a
	 string is a convenient formalism only, not an implementational
	 requirement.




































Page 7

Request For Comments:  886 					 M. Rose
Proposed Standard for Message Header Munging			     UCI



			 Transformation Rules

    All of the forms of message decomposition discussed above may now
    be viewed as transformation between canonical forms.  Hence, it now
    becomes necessary to consider how canonical forms should be
    manipulated during transformation.  That is, what rules are to be
    followed when constructing an equivalent canonical form?  There are
    several guidelines that must be followed, that we will characterize
    in the following fashion:


    o Preservation of information

	 All attempts must be made to preserve all information
	 contained in the original canonical form.  This information
	 can be highly useful to the recipients of munged messages.
	 Obviously, for two widely-differing formats, this may not be
	 possible.  For example, some standards may not have a group
	 addressing notation such as the one present in the 822
	 standard, e.g., the notation

		List: Support@UCI, ZOTnet@UCI;

	 might not be permitted.  If one were to consider membership in
	 a group as part of an address' canonical form, then this