1999 November 15,

Linda Driver wrote:

I'd like to revisit the issue of sending multiple APDUs in a single mail message.

In section 6.10.3 of the IPIG profile, it states: "A single mail message may contain multiple APDUs, each in a single body part."

At an earlier IPIG meeting, a question was raised whether anyone had actually implemented this requirement. No one had (or at least no one knew of anyone who had done so).

Has anyone implemented it since then? If not, I would like to propose that we drop the requirement. Although we have not experienced much difficulty with lost email messages, quite frankly, if a message is lost, I'd rather it contain a single APDU and not five or ten.

Arguments in favor? Arguments against?

----------------------------------------------------------

Art Zemon:

I'll go one step farther. I am in favor of mandating one APDU per message.

----------------------------------------------------------

We at Ameritech agree with Linda and Art, and propose that there be only one MIME attachment per message.

----------------------------------------------------------

OCLC also agrees that a single MIMI attachment per message is desirable.

Since this change would require a modification of the profile, has anyone determined how we should go about formally proposing and approving such changes to the profile (and to the guidelines when they are approved)?

----------------------------------------------------------

Just for the record, we don't normally send MIME messages with multiple parts. If we receive a MIME message with multiple parts and more then one of those APDU's generate an error condition, we would then create a MIME message with multiple parts each containing a SOER. So it would be assumed that if one sends a multipart MIME message, they could recieve one.

As for a solution, couldn't something go in the guidelines recommending that all MIME messages contain only one APDU?

----------------------------------------------------------

Mark Wilson

(and a mess it is)

TLC does not have a problem with this limit either.

The change is not as difficult as it may appear - those who have implemented receipt of multiple parts need only "forgive" anyone who sends such a MIME package. The real issue, and the only one that might require code changes are those applications that already send out multiple parts in a MIME message.

The only problem is for applications that can't receive such packages. And if you dont ask and i dont tell ...

My belief is that we do not, or if we do, can cease doing so immediately.

I do not know anyone else who as implemented multiple MIME parts (FD??).

Thus, even if it is difficult to ammend the profile (and other amendments will be forthcoming with experience) it is easy to have a unanimous PRIVATE agreement that no-one will SEND such messages.

I would rather see a profile amendment but can live with a private agreement, so long as it is unanamous.

Oddly enough, I though we had decided not to permit multiple parts -- no advantage in doing so and complicates code -- way back at one of our meeting in Dupont Circle.

----------------------------------------------------------