buclin@si.di.epfl.ch (Bertrand Buclin) (11/28/88)
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 86huitema@jerry.inria.Fr (Christian Huitema) (11/29/88)
Regarding the ``Trace'' mapping, I must confess that Mailway did not follow Steve's recommendation. Actually, we are building up the ``trace'' field from the ``Received:'' lines -- seems much more natural. More precisely, the ``Received'' lines contain a host-name and a date; we map the host name to a PRMD ID: either the PRMD to which the host belong, when a mapping exists, or the PRMD of the gateway which serves the host, otherwise. Then, we ``pack'' the traces by removing all duplicat occurences of a PRMD, keeping only the earliest date as ``date of arrival''; the action is always set to ``relayed''. We are indeed loosing some information. This is due to the limited syntax of the Trace field in 1984-P1; it will be very naturally overcomed with 1988 P1, where we will be able to use the ``internal trace'' field, at least for the last PRMD. In my opinion, the solution described in the RFC-987 is not implementable: it leads to using invalid ADMD names, and thus forbids the relaying of the message to a public ADMD. Christian Huitema
S.Kille@CS.UCL.AC.UK (Steve Kille) (02/02/89)
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
S.Kille@CS.UCL.AC.UK (Steve Kille) (02/02/89)
>From: Christian Huitema <huitema@fr.atlas.aristote.inria.jerry> >To: ifip-gtwy-request@gov.llnl.tis >Subject: Re: Some problems with RFC 987 >Date: 31 Nov 88 09:20:13+0100 >Regarding the ``Trace'' mapping, I must confess that Mailway did not follow >Steve's recommendation. Actually, we are building up the ``trace'' field >from the ``Received:'' lines -- seems much more natural. Tut tut >More precisely, the ``Received'' lines contain a host-name and a date; we >map the host name to a PRMD ID: either the PRMD to which the host belong, when >a mapping exists, or the PRMD of the gateway which serves the host, otherwise. >Then, we ``pack'' the traces by removing all duplicat occurences of a PRMD, >keeping only the earliest date as ``date of arrival''; the action is always >set to ``relayed''. The packing is sensible, and would need to be done. 987 should have said this. >We are indeed loosing some information. This is due to the limited syntax >of the Trace field in 1984-P1; it will be very naturally overcomed with >1988 P1, where we will be able to use the ``internal trace'' field, at least >for the last PRMD. I agree about internal trace - this will be a big help. >In my opinion, the solution described in the RFC-987 is not implementable: >it leads to using invalid ADMD names, and thus forbids the relaying of the >message to a public ADMD. 987 is certainly implementable! It will also be consistent with X.400. I agree that it might cause interoperability problems with those who have a restricive view of the world (PTTs in particular). >Christian Huitema I am still not sure about this one. The practicalities of this mean that: 1) You discard most of the inforamtion in the trace fields in order to squeeze into the legal format. 2) You then throw all bar one of these fields away, picking the first or last date (in practice, most items will map to either your own MD, or will not have a mapping to an MD and so still map to your own). You might as well specify discarding the information. However, I fear that you are right about the effect of the 897 mapping. It will be rejected by some ADMDs, and cause other implementations to break. Catch 22 Steve