Several issues were left unresolved in Santa Fe. Now that the
next to final version of the specification is out, comments on those
unfinished items is solicited. The unresolved issues are
1) ExternalBody/External Reference syntax
2) Compression (transfer encoding or attribute)
3) Message Integrity Check
4) Internal Reference in Rich Text
I eagerly await proposed text for the compression and MIC.
I would like to propose some changes to the external reference subtype
as currently specified in the document. As specified, external-body
is a expandable, open ended mechanism for retreiving data from an
external source. I think this is the wrong model for several reasons.
1) The mechanism for the use of parameters for general functional
extension is not as well defined as it is for content-sub-types. No
registration mechanism has been defined for attribute pairs.
2) I believe this functionality should be under Application rather
than Message. I'm not sure why we need the overhead of an 822 message
just to include a pointer to say an external audio file.
3) The current syntax is unfriendly to old-style users. (Me! until my
systems guy installs a MIME system)
I'd prefer a sequence of sub-types which closely parallel existing
access mechanisms. Here is my cut by example rather than rigorous
Content-Type: Multipart/Alternative; boundary = "achoo"
name = "internet-drafts/draft-ietf-822ext-messagebodies-02.txt",
site = "ftp.nisc.sri.com",
user = "anonymous",
password = "guest",
expiration = "unknown"
(The body of the content-type includes the message to send to get
Subject: MailRequest randomalphanumeric
When a new access method is defined, a new subtype is recorded with
IANA explaining how to use it. I prefer this to the use of a new
attribute which is defined only by assumption of the parameters needed
by that method, or by a separate RFC. I'd like to avoid the need to
begin registring attributes.