Path: utzoo!utgpu!watmath!clyde!att!osu-cis!tut.cis.ohio-state.edu!bloom-beacon!apple!bionet!agate!helios.ee.lbl.gov!lll-tis!si.di.epfl.ch!buclin
From: buclin@si.di.epfl.ch (Bertrand Buclin)
Newsgroups: comp.protocols.iso.x400.gateway
Subject: Some problems with RFC 987
Message-ID: <169:buclin@si.di.epfl.ch>
Date: 27 Nov 88 17:43:00 GMT
Sender: root@tis.llnl.gov
Distribution: inet
Organization: The Internet
Lines: 115
Approved: post-x400-gateway@tis.llnl.gov


  Here is the list of problems I encountered with RfC-987. Some of them may
  seems of minor importance, but I think they may be discussed.

1. X.400 components and RFC-822 field ordering

  RFC-987 states that ordering within P2.Heading and P1.UMPDUEnvelope
  should reflect ordering within the RFC 822 header when converting a
  message from RFC-822 world to X.400. In the reverse gateway, no
  assumption is made on this ordering. Furthermore, I know of no X.400 UA
  which take care of this ordering. Is this ordering absolutely necessary ?

  In some cases, it is impossible to guaranty it. For example with
  P1.RecipientInfo, default values are set accordingly to 822-P1
  informations. But if a P1-Recipient field figures in the header part,
  this field will be completed and won't figure at the right place
  (accordingly to field ordering) in the P1.UMPDUEnvelope. Furthermore,
  RFC-822 fields are mapped either in P1 or P2 components. Because of this
  layering, a strict ordering can't be maintained.

  In a private maile exchange, Steve Kille already agreed that ordering has
  not a lot of reasons to be retained.
  
2. X400-Trace: field

  In the mapping of this field, RFC-987 mark the action component as
  optional :

  x400-trace = global-id ";"
               "arrival" date-time
	       [ "deferred" date-time ]
	       [ "action" action ]		      ; <--
	       [ "converted" "(" encoded-info ")" ]
	       [ "previous" global-id ]

  X.411 (3.4.1.5) mention the TraceInformation.action component as
  mandatory and with no default value. CCITT X.400-Series Implentor's Guide
  (Geneva, 3-oct-1986) enforce this requirment by giving exact rules on
  TraceInformation.action useage, especially for loop detection.

  I'm afraid that some simple RFC-987 gateway will discard each optional
  component and thus introduce erroneous header fields. 

3. Mapping of RFC-822 Received: field.

  RFC-987 states to map the sending host with all other informations
  enclosed between parenthesis to the AdministrationDomainName of a
  P1.DomainSuppliedInfo component (RFC987, 5.1). CCITT X.400-Series
  Implementor's Guide (agreed in Geneva, 3 oct. 1986) fixes to 16
  characters the string length for Admd name (Pragmatic constraints, 4.2).
  The mapping proposed will quite in every case overcome this limitation...
  Since the reverse mapping will not map TraceInformation to Received:, I
  think the additional data enclosed in parentheses may be dropped. 
  
4. RFC-822 From: field

  RFC-822 (4.1, 4.4.1) allows several mailboxes to figures in a From: field.
  If no Sender: field is present in the message, RFC 987 ask to map to
  P2.originator. I believe the mapping to P2.Heading.authorizingUsers must
  also occur when serveral mailboxes are present in a From: field, an no
  P2.Heading.originator component is generated.

5. RFC-822 References: field

  RFC-822 declares the syntax of References: field as follows :

  optional-field = ...
                   / "References" ":" *(phrase / msg-id)
	           ...

  When a reference is a phrase, RFC 987 doesn't at all handle this case. Is
  this phrase simply discarded or should it be mapped to
  P2.IPMessageId.PrintableString ? In the latter case, does the gateway
  generated the ORname, or omit it ?

6. P1.ExtensionIdentifier

  RFC-987 (4.4.1) states that P1.ExtensionIdentifier should be set
  automatically by the X.400 system. But it is a required component and an
  MTA should reject the MPDU if this component is absent. Thus, clearly the
  value must be generated by the gateway. 

7. Multiple P2.BodyPart

  RFC-987 states to use the mapping defined by Rose ad Stefferud in
  [Rose85b] to separate the P2.BodyParts in the single RFC 822 message
  body. The reference given points to an unpublished document (as far as I
  know). Do you have heard of this mapping ? If yes, which is it ?

8. Default RFC-822 mailbox to ORName mapping

  RFC 987, 4.2.3, stage 2.3 ask to build the rest of an unparsable, or ill
  formed, address in the local MD agreed manner. I would like to use the
  conversion tables (as redefined in RFC 1026, appendix F) to implement
  this. One way of doing should be to insert in the mapping table a line
  with an empy domain-syntax part. Of course, this line should not figure
  in international distributed tables, but should be set up by the gateway
  operator.

10. P1.TraceInformation

  When mapping a message coming through X.400 from a RFC 987 gateway (i.e.
  following the route RFC-822->X.400->RFC-822), the first trace component
  will be the incarnation of the RFC-822 Date: field of the original
  message. RFC 987 doesn't state if, when mapping the TraceInformation to
  X400-Trace fields, care should be taken to discard this first component. 


Bertrand Buclin                          BITnet       : BUCLIN@CLSEPF51.Bitnet
Computing Services                       EAN,Internet : Buclin@Elma.Epfl.CH
Computer Science Department              SPAN/HEPnet  : ELMA::BUCLIN (20.34)
Swiss Federal Institute of Technology    PSI : PSI%022846911008::ELMA::BUCLIN
CH-1015 Lausanne                         X400: S=Buclin;OU=Si;ORG=Di;
					       PRMD=Epfl;ADMD=Arcom;C=CH
Tel : +21 / 693 25 86