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.
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?
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".
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?
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. Or do you have this in mind:
multipart/references ; start=A {
A: application/appledouble
<the resource fork is part B.>
<the data fork is part C.>
B: application/octet-stream
C: image/gif
}
Here the identity of part B is totally encapsulated in part A. This avoids
the need to register a type for B, but I'm uneasy about having the part
itself unlabelled.
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.
--
Steve Dorner, Qualcomm Inc.
Sometimes it's easier to let your cockatoo eat your shoes
than to hear him scream.