When presenting a multipart/references body part, the mail reader
first scans all of the components contained within. Then it presents
This is very onerous in certain environments, where spool space is limited
or disk performance is suspect. In transferring an AppleDouble file, I
might wind up writing each part of the file, and then copying one part into
another when the message finally got around to telling me what I was
dealing with.
Good point. (Any ideas as to how to make it work better?)
---------
Required parameters: start
What is the improvement of being able to designate some later part as the
master part, rather than just using the first one?
I'm not sure there is one. It might be better to simply use the first (or
last) one.
---------
Troost's "content-disposition" documents.
No provision is made for the filename parameter of content-disposition.
This leaves us with no accepted way to hint at a filename, since 1521
deprecates name=. That's easily remedied by un-deprecating it, I suppose.
How do we specify that a body part should really be written to a file, not
displayed to the user? content-disposition allowed that; I don't see how
this does, unless the "start" part (could I nominate "control" instead of
"start"?) is known to the mailer. It seems to me that learning new types
is "hard", whereas simply looking for a fixed header value is "easy".
I understand people are working on proposals for file transfer body parts; my
idea was that the base file could go in an appropriately typed MIME body part,
and all of the out-of-band information necessary for file transfer could go in
a file-transfer body part that referenced the first part. Presumably the file
name information would be included with the other out-of-band info.
But whatever the mechanism, I agree that we still need a way to specify a file
name.
---------
multipart/references ; start=D {
A: [body-part-A]
B: [body-part-B]
C: [body-part-C]
D: multipart/alternative {
application/foo (which references A, B, and C internally)
multipart/mixed
message/external-body; access-type=internal; content-id=A
message/external-body; access-type=internal; content-id=B
message/external-body; access-type=internal; content-id=C
}
}
Nit: in part D, shouldn't the application/foo come last, as the "most
preferred" part?
yep.
---------
How would I represent a file in AppleDouble using this scheme? Assuming a
benign (instead of pathological) ordering, I guess something like:
multipart/references ; start=A {
A: application/appledouble
<the resource fork is part B.>
<the data fork is part C.>
B: application/applefile
C: image/gif
}
So I need "appledouble" (which describes the start section), and
"applefile" to do what I need to do. You will ALWAYS need to define at
least two types for each composite type; one that describes what sort of
composite type it is and how the parts fit together, and one for the
"extra" or "optional" information.
AppleDouble may be an unusual case, because both the data and the resource
fork are well-defined as separate entities. For another example, a file
transfer might look like this:
multipart/references; start=A {
A: application/file-xfer
<the actual contents of the file are in part B>
<other information about the file>
B: image/gif (or other appropriate mime type)
}
---------
How do I represent the fact that some of the data parts are optional, and
that the mailer shouldn't bother the user if it doesn't understand them?
Must I ALWAYS make the start part be multipart/alternative?
multipart/references ; start=A {
A: multipart/alternative {
message/external-body; access-type=internal; content-id=C
application/appledouble
<the resource fork is part B.>
<the data fork is part C.>
}
B: application/octet-stream
C: image/gif
}
Under header-set, I accomplish what I need with far less mechanism:
multipart/header-set {
application/applefile
image/gif
}
This seems to me a lot easier to deal with, at least for my problem. I can
see that references might work better for other problems.
The multipart/alternative + multipart/mixed + message/external-body "internal"
lets the sender specify *which* parts should be displayed if it can't deal
with the primary start part of the multipart/references. It makes for ugly
MIME, but (I believe) it introduces very little new implementation overhead.
(only the "internal" part is new, and it is just a veneer on top of
"local-file").
Sometimes you may not want the individual contents to be displayed, or want
only certain ones to be displayed. Part of it depends on whether the
individual contents are useful by themselves. (but if they weren't, would
they have real MIME types? hmmm.)
thanks for your comments.
Keith