Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!ames!lll-winken!ncis.llnl.gov!CS.UCL.AC.UK!S.Kille
From: S.Kille@CS.UCL.AC.UK (Steve Kille)
Newsgroups: comp.protocols.iso.x400.gateway
Subject: Re: Some problems with RFC 987
Message-ID: <24060.602356858@UK.AC.UCL.CS>
Date: 1 Feb 89 17:20:58 GMT
References: <169:buclin@si.di.epfl.ch>
Sender: daemon@ncis.llnl.gov
Distribution: inet
Organization: The Internet
Lines: 158
Approved: post-x400-gateway@tis.llnl.gov

Here are some comments on your comments

 >From:  buclin@ch.epfl.di.si
 >To:    ifip-gtwy@gov.llnl.tis
 >Subject: Some problems with RFC 987
 >Date:  27 Nov 88 15:43 +0100

 >
 >  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.

 Official - this restriction should definitely not be in RFC 987
 
 >  
 >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. 

 I don't think that this will be a serious problem.  I prefer to stick to
the protocol, as use of implementor's guide is not mandatory (however
sensible).  An RFC 987 gateway which discarded an action value would not be
conforming to the spec.

 >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. 
 >  

 This is a good point, but I claim that 987 does not violate protocol.
 If it busts implementations - tough.  The mapping of trace is not very
satisfactory, but is is hard to do better - the place where it has to go is
the wrong shape.  I must admit to dislike throwing information away -
particularly trace information.
 
 >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.

 This combination is not legal in 822!  (i.e. out of scope)

 >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 ?

 You are correct.  Should do as for In-Reply-To (pas in text if not the
mappable syntax)

 >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. 

 Well, this is really philosophical.  It will come mcuh cleaner in the 1988
stuff.

 >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 ?

RFC 934

 >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.

I don't think that this helps.  If there is a formal mapping, this can be
defined cleanly according to RFC 1026.  This mechanism is to deal with
cases where there are no definitions (with luck, this should be a minority
of addresses).

 >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. 

 I don't think that it should be discarded.  There is more information in
this field than the date (in particular the originating MD).  Don't want to
discard this.

 >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


Steve