[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: notes on mailing binary objects
- Subject: Re: notes on mailing binary objects
- From: Steve Kille <S.Kille@xxxxxxxxxxxx>
- Date: Mon, 21 Jan 91 09:09:52 +0000
- Cc: IETF SMTP list <IETF-SMTP@xxxxxxxxxxxxxxxxxx>
- Flags: 000000000001
- In-reply-to: Your message of 18 Jan 91 16:09:49 -0500. <>
- Mto: Robert Ullmann <Ariel@com.prime.relay>
- Phone: +44-71-380-7294
There seem to be to issues wrt mailing pictures, files, etc.
1) The structure of the document
2) The encoding
If we are not careful, they will get very tangled. I propose that
they are decoupled. A neat way of doing this, is to design the
structure using ASN.1 notation, which also has the neat effect of making it
easy to ensure X.400 compatibility. The encoding can be define in a manner
appropriate for SMTP and MMM objects.
This could be done to counter problems of the baroqueness of the ASN.1 BER
(comment by Crispin) and the problems of length calculations in RFC 1154
(comment by Freed).
Here is a suggested ASN.1.
Message ::= SEQUENCE {
Heading,
SEQUENCE OF BodyPart }
Heading ::= SEQUENCE OF IA5String
-- one 822 heaader per sequence element
-- e.g., To: Robert Ullmann <Ariel@com.prime.relay>
BodyPart ::= CHOICE {
[0] Message,
[1] ExternallyDefinedBodyPart }
ExternallyDefinedBodyPart ::= SEQUENCE {
parameters [0] EXTERNAL OPTIONAL,
data EXTERNAL }
This should be clear(ish) even to those not familiar with ASN.1, execpt
perhaps for EXTERNAL. This allows binding of an Object Identifier to Data.
822 headers are used, so that this spec can be used without 987 or 1148.
The definition of ExternallyDefinedBody part is taken from X.400.
Paramters are bound separately. This simplifies the case where there is
simple data, and a number of parameters (e.g., Fax). It also allows private
parameterisation of a standard data format.
It would probably be useful to take the EXTENDED-BODY-PART-TYPE macro from
X.400 to facilitate definitions of new body parts. I think that lots of
groups on the internet would want to define body parts, and so a registry
could be started.
For example:
voice-body-part EXTENDED-BODY-PART-TYPE
PARAMETERS VoiceParameters IDENTIFIED BY id-ep-voice
DATA VoiceData
::= id-et-voice
I'll restrict myself to the structure of the message. Others can argue
about the encoding.
Steve