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