MIXER body mapping: mapping to/from IPMS.MessageBody.parameters
David Wilson <D.Wilson@isode.com> Fri, 04 April 1997 15:25 UTC
Received: from cnri by ietf.org id aa15987; 4 Apr 97 10:25 EST
Received: from ietf.org by CNRI.Reston.VA.US id aa10790; 4 Apr 97 10:25 EST
Received: from ietf.org by ietf.org id aa15979; 4 Apr 97 10:25 EST
Received: from woozle.isode.com by ietf.org id aa15975; 4 Apr 97 10:25 EST
Received: from isode.com (actually sirius.isode.com) by woozle.isode.com with SMTP (local); Fri, 4 Apr 1997 16:21:59 +0100
X-Mailer: exmh version 1.6.7 5/3/96
To: iesg@ietf.org, ietf-mixer@innosoft.com
cc: Harald.T.Alvestrand@uninett.no, S.Kille@isode.com, D.Wilson@isode.com
Subject: MIXER body mapping: mapping to/from IPMS.MessageBody.parameters
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Date: Fri, 04 Apr 1997 16:21:56 +0100
Message-ID: <27288.860167316@isode.com>
Sender: iesg-request@ietf.org
From: David Wilson <D.Wilson@isode.com>
There is a problem with draft-ietf-mixer-bodymap-06.txt Section 6.5. This specifies that when mapping between message/rfc822 content type and IPMS.MessageBodyPart that MTS Abstract service mappings are used between the RFC-822 headings and the IPMS.MessageBodyPart.parameters. The problem is that the main MIXER document does not give all the required mappings, as the mapping is actually partly to and from the MTA abstract service. Various RFC-822 heading fields will be lost in mapping to the MTS abstract service, as these are mapped to the MTA abstract service. The most noticable are the trace fields and the Date field. The last is the most important, the submission time of a message can be important. The other trace information is less important. The value of the Date field can be carried in the message-parameters.delivery-envelope.message-submission-time However, this requires that the delivery-envelope be included, and there are other mandatory elements, namely content-type, originator-name and this-recipient-name. The content-type can be set to P22 or P2 (as appropriate for the enclosed MessageBodyPart). However, there may be no information that can be used for the address fields. Therefore a defined 'null' address is needed. We suggest /RFC-822=unknown(a)MHS/ The use of an ORName containing no attributes was discussed, but this may break some implementations. Therefore I suggest the following: If there is a Date field present in the heading, then the IPMS.MessageBodyPart.delivery-envelope must be generated. If there are no heading fields that can be used to generate the values of the elements originator-name and this-recipient-name, then the special address above is used. If there is no X400-Content-Type field in the heading, then the value 2 or 22, as appropriate for the IPM is used as the value of the element content-type. In mapping from IPMS.MessageBodyPart.delivery-envelope, if the originator-name is the special address, then X400-Originator is not generated, and if the element this-recipient-name is the special address, then X400-Recipients is not generated. regards David Wilson D.Wilson@isode.com Isode Ltd. Tel: +44 181 332 9091 http://www.isode.com Fax: +44 181 332 9019
- MIXER body mapping: mapping to/from IPMS.MessageB… David Wilson