-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
On Friday, July 17 at 12:18 PM, quoth lee:
> Is there an RFC that defines how a MUA is supposed to deal with such
> multipart messages? RFC 2183 seems to (reasonably) say only a
> minimum about what MUAs should do.
Not that I know of... The closest I can find is RFC 1521, which says:
It may be the case that some user agents, if they can recognize
more than one of the formats, will prefer to offer the user the
choice of which format to view. This makes sense, for example, if
mail includes both a nicely-formatted image version and an
easily-edited text version. What is most critical, however, is
that the user not automatically be shown multiple versions of the
same data. Either the user should be shown the last recognized
version or should be given the choice.
Granted, this is talking about presentation of the CONTENTS of the
multipart/alternative sub-entities, but I think it applies to
summaries of that content as well (i.e. "attachment counts"). In other
words, I think the suggestion here is to count attachments from only
ONE of the alternatives, not from all of the alternatives, because to
count attachments in ALL of the alternatives is equivalent to being
show multiple versions of the same data.
Of course, this is complicated by the preceeding paragraph:
In the case where one of the alternatives is itself of type
"multipart" and contains unrecognized sub-parts, the user agent
may choose either to show that alternative, an earlier
alternative, or both.
It doesn't say what to do if multiple alternatives are of type
"multipart", and showing "both" seems to directly contradict "what is
most critical" a mere few sentences later.
~Kyle
- --
Preach the Gospel at all times and when necessary use words.
-- St. Francis of Assisi
-----BEGIN PGP SIGNATURE-----
Comment: Thank you for using encryption!
iQIcBAEBCAAGBQJKYMlsAAoJECuveozR/AWebUsP/1KhmB/AjnTqQSFJPF/th+Qf
X4+kbao9m2xMNSE2pcpT/3eZwyk886gCXsgWfxtA2I78/9In32UTeg2YkNROIAHX
BT26rSd3rZMqTAL/5yKyWs5jAcz4NlRES0nCd6UIpS5vk9lNqEFWjhMz/n58UsUo
xtiR7PjCEc5fVwTRH5ukN7GKoTdc5rzzmsn8wuehIdTPTbvJOA/9oWaGP8mhXpow
X0ak3i4JKBQEfpn1J6lJJFe0FE4Rguex60EdqinWWMqgRL4nmU/I4uNf+sd4KRQt
G+6z84bkm1EqQFms6+7DYuP9NTaYMQw1NLfdb5fdbrSFYmi6G9YRgJvy5g86tWKZ
dG3/SGyKdzwbvdyIBGo+UJdTqkgI72JtUrBWjjr0ULmKWZg6kmd4nGh/d8p0CzSH
A6u9iW9XsVjokXTBTHD1ggswJJrllfLXqaiRK45sHjHRBHJUA5bWayGCdeFywfKz
l0KrbtuCTlBxg6VMErRKTd4rVYIYlDhaKX0ooC+rrwbbWxRjo7U9BIkyUU11a8tx
KDotd4SKy2gw75pkc10+nWPaVwAVDnqZAclUz4Oe6V1BK+X9Pn4Sv2srMgw8MEin
6P0s389ZFRNKRMlU2PkvE2Op9zv8r7Odjx4GgUKXXG0+HGHv1goVeNKNWCB/LXyA
t1v7bcaptJpkJKCQPqSU
=U5rt
-----END PGP SIGNATURE-----
