Re: The issue of mime parsing

Stefan Karrmann:
> I prefer to keep IM2k simple (and correctly working, cf. sendmail).

I could not agree more.

Stefan Karrmann:
> If the IM2k-message is MIME/multipart with MIME/external-body contents
> it will be small and the MUA can download the external bodies as the
> recipient likes it.

This is exactly my argument for mandating the use of *only*
MIME/external-body for the body parts. Are there any arguments
for allowing generic MIME?

Now, if only MIME/external-body is allowed, then your "ISP-IM2000
message data" would never contain any actual message content. To
eliminate one unnessecary round of traffic we could simply take your
message field structure to be the *notification* field structure.

The workflow would then be:
  1. Notification (using something like your field structure).
  2. Receivers MUA parses the notification including the
     "external-body-only MIME" data (the manifest).
  3. Receivers MUA fetches any body parts it wants and displays them.

This is compared to (I belive this is your picture; feel free to
correct me):
  1. Notification (using some really simple field structure).
  2. Recivers MUA parses the notification and fetches
     a message that uses your message field structure.
  3. Recivers MUA parses the message, including any generic MIME
     in the body part and displays the content.
  4. If the sender has chosen to include some parts as
     MIME/external-body the receivers MUA may also download
     and display them.

I honestly belive the first solution to be the more simple one.

I recently realized that this simplified workflow was described in an
email from Andrew Rutherford forwarded to the list by Clemens Fischer
in the context of using SIP as a notification protocol [25 Mar 2003
14:53:20]. (Andrew, I'm sorry if missing this the first time made me
re-discuss the wheel...)

//Rickard