MML multipart tag -- what does it do?

MML multipart tag -- what does it do?

[Kai Großjohann]

I think the MML multipart tag needs some more explanation.  At least
to me it's not quite clear what it does.

Okay, the examples in the emacs-mime info file are fairly clear.  But
what they leave open to interpretation: suppose I compose a message,
and the very first line of the body is a multipart tag, followed by a
couple of part tags.

What does the whole message look like that comes out?

You see, if I just put several part tags in the body, then I get a
multipart/mixed message, so maybe the same thing happens with a
multipart tag.

I kinda suspect that under some circumstances the top-level MML tag
will become the Content-Type of the whole message, whereas under some
circumstances the Content-Type of the whole message will me
multipart/mixed with the MML tags given as `children' of that.

kai
-- 
~/.signature: No such file or directory

Re: MML multipart tag -- what does it do?

[Simon Josefsson]

Kai.Grossjohann@CS.Uni-Dortmund.DE (Kai Großjohann) writes:

> Okay, the examples in the emacs-mime info file are fairly clear.  But
> what they leave open to interpretation: suppose I compose a message,
> and the very first line of the body is a multipart tag, followed by a
> couple of part tags.
> 
> What does the whole message look like that comes out?

At the top-level it's a multipart that contains a couple of parts.

> You see, if I just put several part tags in the body, then I get a
> multipart/mixed message, so maybe the same thing happens with a
> multipart tag.
> 
> I kinda suspect that under some circumstances the top-level MML tag
> will become the Content-Type of the whole message, whereas under some
> circumstances the Content-Type of the whole message will me
> multipart/mixed with the MML tags given as `children' of that.

You can't have more than one MIME part in a message without some kind
of multipart.  So if you put more than one <part> in your message, it
implicitely adds a <multipart> at the top.

Maybe what's confusing is the </part> tag -- I don't think it's ever
necessary.  Maybe because there is a close tag you might believe it's
possible to say e.g.

<part>
foo
<part>
bar
</part>
</part>

which isn't unreasonable, but it doesn't work that way.  Maybe the
Insert/Attach/etc commands shouldn't insert </part> or </multipart>,
just because they only add confusion and no semantic.

All the MML commands ends when a new command of the same type is
inserted, I think.  There's no need for </part> or </multipart>.
Maybe someone could try to come up with a counter-example..

Re: MML multipart tag -- what does it do?

[ShengHuo ZHU]

Kai.Grossjohann@CS.Uni-Dortmund.DE (Kai Großjohann) writes:

> I think the MML multipart tag needs some more explanation.  At least
> to me it's not quite clear what it does.
> 
> Okay, the examples in the emacs-mime info file are fairly clear.  But
> what they leave open to interpretation: suppose I compose a message,
> and the very first line of the body is a multipart tag, followed by a
> couple of part tags.
> 
> What does the whole message look like that comes out?
> 
> You see, if I just put several part tags in the body, then I get a
> multipart/mixed message, so maybe the same thing happens with a
> multipart tag.
> 
> I kinda suspect that under some circumstances the top-level MML tag
> will become the Content-Type of the whole message, whereas under some
> circumstances the Content-Type of the whole message will me
> multipart/mixed with the MML tags given as `children' of that.

If there are more than one top-level (implicit or explicit) parts in
the message, you will get a multipart/mixed Content-Type.

ShengHuo

Re: MML multipart tag -- what does it do?

[ShengHuo ZHU]

Simon Josefsson <jas@extundo.com> writes:


[...]

> All the MML commands ends when a new command of the same type is
> inserted, I think.  There's no need for </part> or </multipart>.
> Maybe someone could try to come up with a counter-example..

It is right for </part>, not for </multipart>.  The following example
is reasonable.

<multipart>
<multipart>
</multipart>
<multipart>
</multipart>
</multipart>

For this reason, the <mml> tag is invented to markup message/rfc822
parts.  It is similar to <part>, but need for </mml>.

ShengHuo

Re: MML multipart tag -- what does it do?

[Kai Großjohann]

On Fri, 03 Aug 2001, ShengHuo ZHU wrote:

> If there are more than one top-level (implicit or explicit) parts in
> the message, you will get a multipart/mixed Content-Type.

Hm.  So...

Either the body with its <part> and <multipart> tags is a forest or
it's a tree.  If it's a tree, then the Content-Type of the whole
message is the same as the root of the tree.

If it's a forest, then the Content-Type of the whole message is
multipart/mixed.

Is that right?

But how do we explain this to the user?

kai
-- 
~/.signature: No such file or directory

Re: MML multipart tag -- what does it do?

[Nuutti Kotivuori]

Kai Großjohann wrote:
> On Fri, 03 Aug 2001, ShengHuo ZHU wrote:
> 
>> If there are more than one top-level (implicit or explicit) parts
>> in the message, you will get a multipart/mixed Content-Type.
> 
> Hm.  So...
> 
> Either the body with its <part> and <multipart> tags is a forest or
> it's a tree.  If it's a tree, then the Content-Type of the whole
> message is the same as the root of the tree.
> 
> If it's a forest, then the Content-Type of the whole message is
> multipart/mixed.
> 
> Is that right?

Probably, if you think it like that. The check is simply:
(cont is the result of mml-parse)

,----
| (if (and (consp (car cont))
|          (= (length cont) 1))
|     (mml-generate-mime-1 (car cont))
|   (mml-generate-mime-1 (nconc (list 'multipart '(type . "mixed"))
|                               cont)))
`----

So a multipart/mixed part is added to contain the whole parse-tree if
there's more than one top level part.

> But how do we explain this to the user?

"If there is more than one toplevel part, your message is sent as a
multipart/mixed message containing the parts, otherwise the toplevel
part is the content of the message."

Atleast I can't put it better than that. In any case, the normal user
hardly understands anything about multipart/mixed, let alone something
as complicated as this.

And there is a problem on this as well. For example if the user wants
to sign his message, he adds this to the beginning of his message:

<#part sign=pgpmime>

And everything is fine when he sends normal messages. But if his
messages contain multiple parts, that above markup will only sign the
first part. He must write instead:

<#multipart sign=pgpmime>

But if he puts this in a normal message, he will get a multipart/mixed
message with just one part. And I have no idea what would happen with
a <mml> part or something.

So any ideas on how this could be made clearer?

-- Naked

Re: MML multipart tag -- what does it do?

[Florian Weimer]

Nuutti Kotivuori <nuutti.kotivuori@smarttrust.com> writes:

> And there is a problem on this as well. For example if the user wants
> to sign his message, he adds this to the beginning of his message:
> 
> <#!part sign=pgpmime>
> 
> And everything is fine when he sends normal messages. But if his
> messages contain multiple parts, that above markup will only sign the
> first part. He must write instead:
> 
> <#!multipart sign=pgpmime>

Personally, I consider the '<#!part sign=pgpmime>' stuff a completely
broken design.  IMHO, MML should as closely as possible match the MIME
structure of a message.  I still don't know why the initial proposal
for something like this:

   <#multipart type=signed>
   <#part>
   This is a signed multipart.
   </#part>
   <#part type="text/plain" filename="~/file2"
     disposition=attachment description="signed attachment">
   <#/part>
   <#/multipart>

was superseded by this odd construct.

Re: MML multipart tag -- what does it do?

[Simon Josefsson]

Florian Weimer <fw@deneb.enyo.de> writes:

> Personally, I consider the '<#!part sign=pgpmime>' stuff a completely
> broken design.  IMHO, MML should as closely as possible match the MIME
> structure of a message.  I still don't know why the initial proposal
> for something like this:
> 
>    <#multipart type=signed>
>    <#part>
>    This is a signed multipart.
>    </#part>
>    <#part type="text/plain" filename="~/file2"
>      disposition=attachment description="signed attachment">
>    <#/part>
>    <#/multipart>
> 
> was superseded by this odd construct.

This requires users to know how the sign/encrypt mechanism they use
are implemented in MIME.  E.g., if you want to sign using PGP/MIME you
must write the above, if you want to encrypt with S/MIME you need to
write something completely different because S/MIME encryption doesn't
use RFC 1847.  Maybe users shouldn't need to know that.

To me it feels more user friendly that you specify that a certain part
should be signed/encrypted in the definition of that part.  OTOH users
probably never need this level of fine control anyway, they want the
whole message signed or encrypted.

OTTH I agree it's a step away from having the MML structure closely
match the MIME structure, and that might be bad.  But Gnus already
creates MIME parts implicitely (by leaving out a top-level
<multipart>, or simply using two different and non-unifiable character
sets in one part) so the rule is already broken, and I think it's for
the better.

Btw, the following works:

<multipart sign=smime>
<part>
This is a signed multipart
<part filename=~/file2 description="signed attachment">
</multipart>

Re: MML multipart tag -- what does it do?

[Florian Weimer]

Simon Josefsson <jas@extundo.com> writes:

> This requires users to know how the sign/encrypt mechanism they use
> are implemented in MIME.  E.g., if you want to sign using PGP/MIME you
> must write the above, if you want to encrypt with S/MIME you need to
> write something completely different because S/MIME encryption doesn't
> use RFC 1847.

Really?  I assumed it did, and using S/MIME in a RFC 1847 context is
indeed described in the S/MIME RFCs...

> Maybe users shouldn't need to know that.

Okay, I agree, so there's probably no other choice.

Re: MML multipart tag -- what does it do?

[Simon Josefsson]

Florian Weimer <fw@deneb.enyo.de> writes:

> Simon Josefsson <jas@extundo.com> writes:
> 
>> This requires users to know how the sign/encrypt mechanism they use
>> are implemented in MIME.  E.g., if you want to sign using PGP/MIME you
>> must write the above, if you want to encrypt with S/MIME you need to
>> write something completely different because S/MIME encryption doesn't
>> use RFC 1847.
> 
> Really?  I assumed it did, and using S/MIME in a RFC 1847 context is
> indeed described in the S/MIME RFCs...

Not for encryption.

The application/pkcs7-mime type may also contain signed data as well,
so you don't need RFC 1847 to use S/MIME fully.  (a/pkcs7-mime basicly
just contains a PKCS#7 blob, which might contain lots of stuff.)

I've no idea why.  I think it would've been trivial to take the same
approach as RFC 2015 did (the first part just being some dummy
"Version: 1" and the second everything that is in the current
application/pkcs7-mime part).  It's interesting to note that searching
the IETF S/MIME mailing list 1996-2001 for multipart/encrypted gives
one match, and it's irrelevant.  Hmm.

Also, the "mime" in "sign=pgpmime" was deliberately chosen, so that
you could support "sign=pgp" (plain PGP) via MML at some point, and
the current approach would work nicely with that.  Then we would be
able to send mail to people with Outlook with crippled PGP plugins
(which seem to be a quite large population).

Re: MML multipart tag -- what does it do?

[Lars Magne Ingebrigtsen]

Simon Josefsson <jas@extundo.com> writes:

> OTTH I agree it's a step away from having the MML structure closely
> match the MIME structure, and that might be bad.  But Gnus already
> creates MIME parts implicitely (by leaving out a top-level
> <multipart>, or simply using two different and non-unifiable character
> sets in one part) so the rule is already broken, and I think it's for
> the better.

I think the current way makes lots more sense.  MML doesn't have to
mirror the MIME structure -- it just has to express the user's wishes,
and Gnus then generates MIME that fulfills those wishes.  Users
shouldn't concern themselves with what MIME is actually generated.

-- 
(domestic pets only, the antidote for overdose, milk.)
   larsi@gnus.org * Lars Magne Ingebrigtsen