Re: [Nmh-workers] semantics of mhshow -type and -part

[David Levine]

Paul F. wrote:

> hi -- i'm working on fixing yet another irregularity in the
> operation of mhshow_multi_internal() which is keeping it from
> displaying some parts of specific unusually constructed messages.

Yes, they're unusually constructed.  And various unusual forms
seem to be becoming more common.

> in doing so, i want to be sure that i don't do the wrong thing with
> the -part and -type options.
>
> my question is this: should specifying -part and/or -type options
> cause nmh to display all matching parts, regardless of
> multipart/alternative semantics ?

I don't think so, based on these excerpts from RFC 2046 §5.1.4,
which defines multipart/alternative:

   In particular, each of the body parts is an "alternative" version
   of the same information.

   Systems should choose the "best" type based on the local
   environment and references, in some cases even through user
   interaction.

   What is most critical, however, is that the user not automatically
   be shown multiple versions of the same data.

> but what should "mhshow -type text" do, where the subtype is
> unspecified?

Show the "best" version of a multipart/alternative that has
one or more text subpart(s).  I think; see below.

> the current git version of nmh shows just part 1.1. (i
> don't have an older install handy to check 1.6 or 1.5.)

I believe that it's always done that.

> my current (new) code shows all three text parts.  my feeling is
> that the latter behavior is correct,

I disagree.

> if "multipart/alternative" is changed to either "multipart/related"
> or "multipart/parallel", then current git shows all three parts.

Good, that's what it's supposed to do.

> also, when using multiple -part options on the above message (i.e.
> "mhshow -part 1.1 -part 1.3") then both (or all three) specified
> parts are shown.

I'm fine with that, too.  The user asks for specific parts, so they
should get them.

> the bug i'm actually fixing is with the following message, generated
> by iCloud.  using "mhshow -type text/plain" will show only part 2,
> and using "mhshow -part 1.2" will show nothing at all (other than
> the header).  i.e., part 1.2 is undisplayable.
>
>  msg part  type/subtype              size description
> 7280       multipart/mixed           3645
>      1     multipart/alternative     3184
>      1.1   multipart/related         1867
>      1.1.1 text/html                 1629
>      1.2   text/plain                1002
>      2     text/plain                 127
>
> the problem has to do with the notions of success/failure that
> percolate through mhshow_multi_internal().  i've fixed the issue, i
> think, but it has led to my initial question.  in the case of this
> message, again, what should "mhshow -type text" show?  should it
> ignore the notion of "alternative" and show 1.1.1, 1.2, and 2?

No.

> or should it show just one of 1.1.1 or 1.2?

Yes, because they're alternatives.  It should also show part 2,
because that's in a multipart/mixed with part 1.

On the other hand, I'd be fine with leaving things as they are.
Doesn't plain "mhshow" show one of part 1.1.1 or part 1.2, then
part 2?

>  likewise, what should "mhshow -part 1.1.1 -part 1.2" show?

Exactly those parts.

David