rfc886.txt

RFC 相关的技术文档

	 portion of the canonical form could not be transformed to the
	 other standard.

	 The 822 standard supports a liberal commenting convention
	 which might prove quite useful in preserving information.
	 Implementors may wish to consider capturing the original
	 information in commentary text.  For example, if the USENET
	 address

		[e-mail] (Mark Horton)

	 had the USENET canonical of

		 user:  mark
	        route:  ucbvax!ihnp4!cbosgd

	 and if the corresponding 822 canonical was

	   local-part:	ucbvax!ihnp4!cbosgd!mark
	  domain-part:	USENET.UCI

	 then it would not be unreasonable for an implementation to
	 output this canonical form as

		"[e-mail]" <ucbvax!ihnp4!cbosgd![e-mail]>


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



	      NOTE:  Implementors should exercise extreme caution in
	      using a policy such as this.  Information placed between
	      commentary delimiters must still conform to the target
	      standard at the syntactic level.

	 Note however that in the above example, the commentary
	 information "(Mark Horton)" was discarded.  This practice is
	 strongly discouraged.  Although the canonical form for an
	 object does not rely on commentary information as a necessary
	 part, implementors are encouraged to preserve this information
	 whenever possible.

	 Finally, preservation of information requires preservation of
	 case at all costs.  Only under the most restrictive of
	 circumstances should an implementation change the case of the
	 strings output for a canonical form.


    o Re-Formatting

	 Ideally, the target message should have the exact horizontal
	 and vertical padding as the source message.  Because a string
	 representing the source canonical form of an object may not be
	 of the same length as the string representing the target
	 canonical form, the number of characters on each physical and
	 logical line in the headers may be different.

	 The 822 standard supports a header folding convention which
	 permits long field/value pairs to be represented on more than
	 one physical line.  When a new canonical form is output to the
	 target message, it is possible that the resulting field/value
	 pair may be longer than the number of characters that
	 antiquated display devices can present on a single line. The
	 822 standard suggests 65 or 72 characters-per-line as a metric
	 for this limitation.  Although not required, message munging
	 agents may re-fold headers if (and only if) this limitation is
	 exceeded.  Note however that under no circumstances should a
	 header be re-folded if it was not munged.  Refolding without
	 munging may occur on behalf of some transport or user agent,
	 but it may not occur on behalf of a munging agent.  Put more
	 simply, this memo does not authorize or forbid such activity,
	 although it does discourage it.


    o Error Recovery

	 The preceding discussion has made been under the assumption
	 that the objects composing the field/value pairs of the source
	 message have conformed to the source standard. It is an
	 unfortunate reality that this may not be the case. In fact,


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


	 for those standards which are poorly specified (if at all),
	 determining that an object is improperly constructed might be
	 quite difficult.  In addition, it is possible, though
	 hopefully extremely improbable that a target canonical form
	 does not exist for a particular source canonical form.  In
	 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 as
	 "reserved" and may not be used for other purposes.  These
	 fields are:

		Illegal-Field
		Illegal-Object

	 The syntax of these fields is as follows:

		munge-field =
		     "Illegal-Field"	":" *text
		  /  "Illegal-Object"	":" *text

		munge-object =
		     <a "field-name", the exact field-names which are
		      valid will be presented later>

	 The semantics of these fields are as follows:

	 An Illegal-Field header should be introduced when a
	 header-line which does not conform to the source standard is
	 found in the source message.  Illegal-Field should be used
	 only when a header-line is so poorly formed as to prevent
	 recognition of the field in the header-line.  For example, if
	 the line lacks a colon, or has a poorly formed field-name,
	 then it should not be output to the target message and a new
	 header-line should be introduced in its place.  This
	 header-line has Illegal-Field as its field and contains the
	 offending line as its value.  Illegal-Field should not be used
	 if the field can be identified, but the value is poorly
	 formed.

	 An Illegal-Object header should be introduced when an object
	 in the source message can not be parsed into a canonical form,
	 or if the canonical form it represents has no corresponding
	 target canonical form.  The offending object should not be
	 output to the target message in the header-line in which it
	 occurs.  If the header-line now contains no objects, then the
	 header-line should not be output to the target message as
	 well.  Then, an Illegal-Object field should be introduced into
	 the target message.  The value of this Illegal-Object field
	 should at the very minimum contain the name of the field that
	 contained the object, the object in question, and an


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


	 explanation as to why the object was illegal.  Alternately,
	 the value of this Illegal-Object field should consist of the
	 entire header-line (field and value) that contained the object
	 in question along with an explanation as to why the object was
	 illegal.

	      NOTE:  In the circumstance where multiple objects exist
	      in a single header-line in the source message, and one of
	      those objects is determined to be illegal, the actual
	      policy used in determining how much information can be
	      considered to be "uncorrupted" is left to the
	      implementors.  Munging agents which use sophisticated
	      parsers may attempt to recover in mid-stream (so to
	      speak) and continue parsing objects on the header-line.
	      Other agents may wish to continue recover with the next
	      header-line in the source message.  Regardless of the
	      policy used, the agent must present the contents of the
	      entire header-line in the associated Illegal-Object
	      header.

	 Implementations should not take extraordinary measures to
	 perform syntax/semantics checking of the source message --
	 only those fields which must be examined should be rigorously
	 checked.  This memo strongly discourages any additional
	 examination.  It is not the intention of this memo to suggest
	 that composing agents should produce messages which do not
	 conform to the source standard.  A composing agent should not
	 expect a munging agent to enforce adherence to the source
	 standard.


    o Introduction of Information

	 Munging agents are authorized to introduce a "Received" header
	 into the target message when a message is transformed.

	      NOTE:  Adding a "Received" header is entirely optional.
	      This memo strongly recommends that this header be
	      introduced whenever some munging (translation of addresses
	      and/or dates) occurs.

	      NOTE:  Although this memo does not specify the position
	      that the introduced header should have in relation to the
	      other fields in the target message, it is strongly
	      recommended that the introduced header be grouped with
	      the other "Received" headers, at the very beginning of
	      the message.

	 When introducing a "Received" field, three phrases, which are
	 normally optional in such a field, should be specified by the
	 munging agent.  These are:


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



		"from" domain		# the source domain
		"by"   domain		# the target domain
		"with" protocol		# the munging agent's host

	 For example, suppose we have a munging agent on the UCI host,
	 and that this agent services a USENET/ARPA boundary.  When the
	 UCI host gets a message from the USENET domain for the ARPA
	 domain, the following happens:  First, the UCI mailsystem would
	 prepend the header:

	   Received: from nma by UCI with UUCP; 15 Dec 83 03:53:00 PST

	 Second, the munging agent, when transforming the message,
	 would prepend the header:

	   Received: from USENET by ARPA with UCI; 15 Dec 03:54:00 PST

	 Finally, the UCI mailsystem would then deliver the message to
	 the appropriate ARPA mailsystem, which in turn would prepend
	 the header:

	   Received: from UCI by ISIF with SMTP; 15 Dec 83 03:55:00 PST

	 This example might be a bit clearer if the domains were
	 qualified a bit more.  The first three lines of the message
	 could look like this:

	   Received: from UCI.ARPA by ISIF.ARPA; 15 Dec 83 03:55:00 PST
	   Received: from USENET by ARPA with UCI; 15 Dec 03:54:00 PST
	   Received: from nma.USENET by UCI.USENET; 15 Dec 83 03:53:00 PST

	 The key point to notice is that the munging agent used the
	 "from" and "by" clauses to denote the domain boundary that was
	 crossed, and used the "with" clause to denote itself.  Since
	 the agent is munging the message according to some set of
	 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. Rose
Proposed Standard for Message Header Munging			     UCI


			  Objects of Interest

    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 as
    appropriate for transformation:

     Address Fields:	From, Sender, Reply-To, To, cc, Bcc,
			and any of these fields with the Resent- prefix

	Date Fields:	Date, Resent-Date

    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 the
	 purposes of this memo, the above fields are defined as the
	 MINIMUM list of munge-objects for the 822 standard.
	 Implementors are encouraged to introduce other fields to the
	 list of munge-objects as their munging agents require.  These
	 additions should also be registered with the revisions of this
	 memo as they gain popularity.

    For the purposes of the remainder of this memo, an address
    header-line is defined as any header-line in the source message
    whose field component is one of the fields listed above as an
    address field.  Further, a date header-line is defined as any
    header-line in the source message whose field component is one of
    the fields listed above as an date field.

    If address munging is performed, then all addresses contained in
    all address header-lines must be munged.  It is expressly forbidden
    to perform address munging on the source message and without
    performing address munging on every address header-line.  Further,
    it is expressly forbidden to munge some, but not all, of the
    addresses in any address header-line.  All addresses in all of the


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


    message's address header-lines must be address munged. If address
    munging is not performed, then these header-lines need not be
    considered for munging.

    A similar requirement is made for date munging.  If date munging is
    performed, then all instances of header-lines whose field is Date
    or Resent-Date must be fully date munged.

	 NOTE:  Certain fields are to be excluding from munging of any
	 sort, all munging agents must preserve their contents exactly.
	 At present, there is one such field: "Received".  This contents
	 of this field should ALWAYS be preserved for trace and
	 debugging purposes.








































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



			     Bibliography

    D.H. Crocker, "Standard for the Format of ARPA Internet Text
    Messages", RFC 822, (August, 1982).

    M.R. Horton, "Standard for the Interchange of USENET Messages", RFC
    850, (June, 1983).

    M.T. Rose, "Achieving Interoperability between two Domains --
    Connecting the ZOTnet and UUCP Computer Mail Networks", Technical
    Report Number 201, Department of Information and Computer Science,
    University of California, Irvine, (January, 1983).

    P.V. Mockapetris, "Domain Names -- Concepts and Facilities", RFC
    882, (November, 1983).





































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



			      Appendices


			Minimal Canonical Forms

    This memo defines the minimal canonical forms for the 822 standard.
    Implementations may wish to augment these forms with additional
    information that may be present in the source message.  An earlier
    example suggested that group membership might be part of an
    address' canonical form.  Further, since the 822 standard permits
    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 to
    make use of this additional information, then they are free to do
    so.  This practice is neither encouraged nor discouraged. In short
    the spirit of this memo is to require those minimal components
    required by the 822 standard, nothing more.






























Page 16