RFCs, standards, pink bunnies and flower patterns

[Mark H. Wood]

Precisely.  Once MIME enters the picture, the user agent must be
looked at as a collection of subsystems driven by the MIME structure
of the message.  None of the subsystems (other than the MIME parser)
*ever* deals with a whole message; the user agent is presented with an
assembly of bodyparts and deals each part out to the subsystem best
equipped to interpret it.

There was a previous comment asserting that various applicable
standards require certain content-types in the *message header*.  Any
such standard is broken, because the thing with which it deals may be
nested within a hierarchy of other things (with other content-types)
of any depth.

What *should* happen is that a multipart/signed or multipart/encrypted
bodypart is detected *somewhere* within a message; it is given to
gnupg or pgp or 'openssl smime' or whatever to interpret; the
interpreted content is given back to the MIME interpreter; the content
is seen to be a multipart/alternative bodypart; the user agent (for
reasons I will never understand :-) selects the text/html bodypart;
that bodypart is given to an HTML interpreter, and as text/html is
terminal w.r.t. MIME the process is complete (up to the node at which
the multipart/whatever bodypart resides).

External references from text/html bodyparts are the concern of the
HTML interpreter; the OpenPGP interpreter has already done its job.
If they are to be secured, HTTP specifies mechanisms for doing that.

It sounds like some user agents are continuing the grand tradition of
implementing MIME poorly where they bother to do so at all.  I suspect
that the sign/encrypt community's role here will be limited to
repeating, "if you would follow the specifications then it would Just
Work" until the clue is accepted.

-- 
Mark H. Wood, Lead System Programmer   mwood at IUPUI.Edu
Typically when a software vendor says that a product is "intuitive" he
means the exact opposite.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : /pipermail/attachments/20061018/9c21774d/attachment.pgp