buclin@si.di.epfl.ch (Bertrand Buclin) (11/28/88)
Hi all, and especially Steve,
I'm writing the gateway here at EPFL. I'll share my thoughts on the
problems Nancy raised.
>>Autoforwarded-Autoforwarded-From: ...
>>Autoforwarded-Autoforwarded-To: ...
>>Autoforwarded-Autoforwarded-Autoforwarede: TRUE
>>.
>>Autoforwarded-From: ...
>>Autoforwarded-To: ...
>>Autoforwarded-Autoforwarded: TRUE
>>.
>>From: ...
>>To: ...
>>Autoforwarded: FALSE
>
> Yup!!
Here I believe, Steve, that there is a contradiction in RFC 987. You
state (RFC 987, 5.4.3) to map recursively IM-UAPDUs. In chapter 5, part
2, for the mapping of "Autoforwarded" you state that fields beginning
with the string "Autoforwarded-" should be mapped in stripping this
prefix, "BUT THAT MECHANISM DOESN'T NEST". Principles 2 and 3 are
violated. Why perform a recursive mapping from X.400 to RFC-822, and
disallow it in the other sense ?
If I strictly apply the RFC 987 specifications, all fields of the original
outermost IM-UAPDU (i.e. those with several "Autoforwared-" in front of
them) will be transmitted in the first body part of the message...
If you look at the P2.Heading contents when a forwarding is done by a UA,
you will notice only two differences with the original Heading :
- The autoforwarding indication is set
- The primary or copy recipient indication of the recipient concerned by
the forwarding operation is modified to contain the new address.
All other components are kept as they figure in the heading. (X.420,
4.2.3.1).
Applying a recursive mapping on all components of the heading will only
increase the size of the RFC-822 header with redundant informations. I
think, it would be sufficient to map only the most nested IM-UAPDU (i.e.
this conveying the very message) and discard the other P2.Headings.
To keep a trace of the forwarding, I propose to map, for each intermediate
P2.ForwardedIPMessage.DeliveryInformation, thisRecipient to a Resent-To:
field, otherRecipients to a Resent-Cc: and submission to a
Resent-Date: (See, X.411, 2.2.9, X.420, 3.2.2, 4.2.3.1). The
autoforwarded indication needs not to be mapped, since the presence of
Resent-* fields convey it. With the example Nancy gave, we will have the
following RFC-822 header :
From: greene@elde.epfl.ch
to: buclin@elma.epfl.ch
Resent-To: buclin@elde.epfl.ch
Resent-Date: ...
This will keep a rather 'clean' header, and does more correspond to
RFC-822 philosophy.
>>
>> 3. Does Autoforwarded- get prepended before P1-generated RFC822 field names
>> as well as P2-generated RFC822 fieldnames?
>>
> Yes
>
Why ? This would be correct if the components of the first
P1.UMPDUenvelope (i.e. this used to convey the very message to the first
MTA) were always accessible. The P1 components the gateway receives are
those generated by a rerouting MTA. When performing reverse gatewaying
(i.e. from RFC-822 to X.400) these fields may be lost (see my remark just
above). Furthermore, autoforwarding is a P2 layer concept, there is no
reason to apply it to P1 components. I can admit to prepend those field
which are 'replaced' by the nested IM-UAPDU Heading, but P1 components
aren't altered by P2 components...
P1 contains only one components which may reflect a forwarding operation,
it the TraceInformation sequence.
>I'm glad to see that you are taking troupble to implement ALL of the spec!
>(Most implementations claiming 987 conformance omit a good deal). I'd be
>interested on any user feedback you get wrt this feature.
I can't yet give you user feed-back, but only an implementor point of
vue. In a separate message, I'll propose you a list of problems I have
encountered. The autoforwarding mapping is the trickiest one, but some
other problems needs also a discussion.
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
S.Kille@CS.UCL.AC.UK (Steve Kille) (02/02/89)
Finally get around to these messages! I disagree with you about the auto-forwarding mechanism not nesting. However, it is very badly explained, and so we may be reading different things. This feature was slipped in quickly and at the last minute (not my suggestion). On reflection, I think that the mechanism is a bad move. I would prefer to see that if autoforwarded is true, that simply a header "AutoForwarded: TRUE" is given, and then the real message follows after a blank line. This can be treated as reversible. The reason that I asked for comments, is that my gut reaction is that use of this feature would cause confusion, rather than being useful. It is also awkwrd to implement, and so there is a temptation to omit it! Steve