S.Kille@cs.ucl.ac.UK (Steve Kille) (02/26/91)
The key point of 1148 was to preserve service, not to add function to 822. Reversible encoding of DRs. I don't think that this is worth the effort (987 DRs were more easily reversible. In 1148, based on experience, we shifted to a more user-oriented representation). This is only critical when 822 is used to interconnect X.400 systems. This is not so common. MMM extensions of RFC 822. I do not want to put this into 1148. If it is really needed in the 822 world, this should be defined as an RFC. RFC 1148bis will referene the most appropriate RFC for encapsulating messages and encoded body parts. Currently this is RFC 934. Thus, I am happy to see this work - just that 1148 is not the right place for it. RFC 1158 is not, as it stands, as suitable. It does not map all of the X.400 functionality (esp. 88 extensibility). 934 is more portable. The IETF-SMTP group is currently disucssing extensions of 822 to support Multimedia messages. I hope that they will carefully addres the issue of X.400 compatability. Steve
harald.alvestrand@elab-runit.sintef.no (02/27/91)
Steve, one total miss: I referred to RFC 1158. I should have said 1154. So much for not checking my numbers before posting. To your point: You claim that RFC 1154 (I think you understood me!) does not cover X.400/88 extensibility. I quote: > RFC 1158 is not, as it stands, as suitable. It does not map all of the > X.400 functionality (esp. 88 extensibility). 934 is more portable. Given that you can have a header saying Content: 1123 X400 3/4 meaning that there is a single body part consisting of 1123 lines of 3/4 encoding, giving the complete ASN.1 encoding of the body part (section 4.6 of RFC 1154), and that any X.400/88 extended body part may be uniquely identified by its encoding bytes, which include the object identifier identifying it, I fail to see the reason why it should not be possible to handle all bodies. As for header extensibility, I thought 1148 was *supposed* to cover that :-) I have also read 934 (thanks for the tip!) and fail to see how it can be used for identifying body parts or their encoding. It separates them, yes, and covers the case for forwarded IP-messages with IA5 body parts, but how does it cover anything except IA5? Still looking for clarification.... Harald Tveit Alvestrand Harald.Alvestrand@elab-runit.sintef.no C=no;PRMD=uninett;O=sintef;OU=elab-runit;S=alvestrand;G=harald +47 7 59 70 94
harald.alvestrand@elab-runit.sintef.no (Harald Tveit Alvestrand) (02/28/91)
AHA! INSIGHT!
I have made the mistake of reading RFC934 as saying "mail headers" where
it actually said "headers".
When I want to make a body part, I would put it something like this:
From: Me
To: You
Subject: RFC934 demo
This is the boilerplate text
----------------------
Content: G3Fax
AXRlkJSD\Ofin wnear gnkjafng poaeijrg| okafg| aijr|oiwh
a|orinpoaergnm |oerng|o enrg|kja e
{kjaenrgpoienrpgo ijaerfok
----------------------
You understood that this was a body, and not an embedded message, did you?
Have I read RFC934 correctly now?
(If this is the case, I switch to thinking that RFC-1148bis should refer
to RFC934. I am, after all, a pragmatist)
Harald Tveit Alvestrand