Re: [Sml] We've been here for quite a while

[John C Klensin <[e-mail]>]

I am not following this list, but just as an additional thought
to add to John Levine's comments on 18 February...

An alternative to structured syntax notation might be to start
thinking about a _very_ small number of additional MIME types,
probably subtypes of multipart/, that would look something
vaguely like:

 multipart/structured
    multipart/alternative (description of what is going on here,
maybe itself structured)
      text/plain 
      text/html
    application/structured (aka "what-is-this?" in easily
machine-interpretable form)

followed by 
    multipart/mixed
      (stuff)
    Or whatever the two above parts say it is.

Is that a good idea?  Maybe, maybe not.  Is it a complete idea?
Definitely not.  But things of that nature could be used, maybe
in combination with structured suffixes, to do something of what
is required.

Yet another possibility would be to either create new multipart
types (safer) or permit adding a "description" parameter to the
existing ones (I have no idea whether that would cause receiving
MUAs or mail-filtering systems to baulk, but we should probably
be at least a bit nervous about it).

None of that changes the concerns that have been expressed about
misuse, providing extra attack surfaces, or opportunities for
other bad behavior.   Some of the possibilities I see would be
plausible from a security standpoint only in the presence of
message-content authentication provided by the originator and
verified by the recipient's agents along the lines of S/MIME
with high-quality certification (PGP won't scale for the
examples given so far) .. and, after 20-odd years, I don't think
any of us should start holding our breaths for those mechanisms
to be in general use.

That said, while I think a BOF discussion is probably fine, I
think what (in order of first posting to the list) Keith, John
L., and myself are suggesting is that whatever is done should be
folded into existing mechanisms and, where they exist, existing
WGs (note that some of the above may overlap with MEDIAMAN).  In
addition to the security issues, I share what I understand to be
their concern about creating enough complexity that we don't get
consistent and interoperable implementations.  Inventing new
mechanisms that are not completely orthogonal to the existing
ones would created "which one do you believe" situations and be
almost certain to either cause trouble or be a serious
impediment to adoption.

    john