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

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

Hi Hans-Joerg,

Yes, your suggestion and my later one are certainly headed in
the same general direction.  I see one difficulty with yours and
one mostly-aesthetic issue.

The difficulty: 
While it has been abused in the past and probably will be in the
future, multipart/alternative is intended to mean that the
following body parts are equivalent.  Under most circumstances,
that is "pick one and ignore the others".  Without violating the
design principle, I think the closest one could get to your
model would be (adding closing boundaries to be extra-clear)

+ multipart/mixed; boundary="--foo--"
++ multipart-alternative; boundary="--bar--"
+++ text/plain (newsletter)
+++ text/html (newsletter)
   --bar--
++ text/json+ld (structured data(*)
   --foo--

inelegant, but no new content-type structure other than
"text/json+ld".

If you look at the above, the argument for a separate/new
multipart type would be that there would be exactly two body
parts -- payload ("newsletter" in this case) and structured data
description.  With multipart/mixed as above (or your overloading
multipart/alternative) it might make sense to put the
text/json+ld body part first, because otherwise the reading MUA
would have to somehow know to look ahead to the last body part
to figure out what is going on.  Such an "examine all of the
body parts before doing anything" requirement comes close to an
incompatible change.  It would be an incompatible change for any
reading MUA that interprets multipart/alternative as either
"present the first acceptable one and ignore the rest" or "look
through the collection for the preferred content-type and, if it
is not found, do something" rather than "inspect all of them and
then make a preference-ranked decision".  If my memory of the
MIME spec is correct, any of those would be an acceptable
implementation choice.  By contrast, a new multipart/structured
type would both tell the reading MUA up-front what is going on
and could be defined with a particular order of required or
optional component body parts.

The probably-aesthetic issue is that comments are supposed to be
optional, purely descriptive, and not carry any semantic
meaning.  If I correctly understand the reasons for a structured
data setup, some of those descriptions might carry significant
information.  If that is not true, use of comments (as in your
examples) would be fine. If it is, then there is a strong case
for something like
    ";" ... "descr=" <something-maybe-itself-structured>
rather than comments.

best,
   john


--On Thursday, March 9, 2023 14:35 +0100 Hans-Joerg Happel
<[e-mail]> wrote:

> Hi John,
> 
> thanks for joining in.
> 
> Regarding your suggestion, I think this looks quite similar to
> he one I made in my mail from Feb 17th, suggesting, e.g.:
> 
> + multipart-alternative
> ++ text/plain (newsletter)
> ++ text/html (newsletter)
> ++ text/json+ld (structured data(*))
> 
> One point here is that I'd argue "text/json+ld", "text/turtle"
> and "rdf-xml" could be used as existing mime types of RDF
> structured data representations. However, one might need (for
> other cases besides the multipart-alternative example below) a
> way to denote if "text/json+ld" is intended as a normal
> attachment or as carrying structured data.
> 
> If I understand you correct, that's what you refer to as
> "adding a "description" parameter".
> 
> A novel "application/structured" type, as you suggest below,
> would not require that clarification and be open for other
> structured data formats than RDF (unclear, if this is strictly
> necessary?). I am not sure if/for what reason a new
> multipart-type would be required?
> 
> Best,
> Hans-Joerg
> 
> (*) I added this comment for clarification
> 
> On 04.03.23 04:55, John C Klensin wrote:
>> 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