text/calendar vs application/ics

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
14 messages Options
Reply | Threaded
Open this post in threaded view
|

text/calendar vs application/ics

Conrad Hughes
When I mhshow a message with a text/calendar attachment, it's inlined
using mhical; if the attachment type is changed to application/ics, it's
suppressed instead.  I'm using the latest mhn.defaults from the git
repo, which contains

  mhshow-show-text/calendar: mhical -infile %F
  mhshow-show-application/ics: mhical -infile %F

.. any idea where I should be looking for something else that might
differentiate the two?

Conrad

Reply | Threaded
Open this post in threaded view
|

Re: text/calendar vs application/ics

Ralph Corderoy
Hi Conrad,

> When I mhshow a message with a text/calendar attachment, it's inlined
> using mhical; if the attachment type is changed to application/ics,
> it's suppressed instead.

May we have the output of `mhlist -verbose' for those two emails?

--
Cheers, Ralph.

Reply | Threaded
Open this post in threaded view
|

Re: text/calendar vs application/ics

Ken Hornstein-2
In reply to this post by Conrad Hughes
>When I mhshow a message with a text/calendar attachment, it's inlined
>using mhical; if the attachment type is changed to application/ics, it's
>suppressed instead.

Wait, is application/ics a valid type?  Even the calendar invites I get
from the Microsoft world seem to be text/calendar.

But, I am wondering if the issue is not the MIME type, but the disposition.
MIME parts with a disposition of "attachment" are not displayed by
mhshow by default.

--Ken

Reply | Threaded
Open this post in threaded view
|

Re: text/calendar vs application/ics

Conrad Hughes
In reply to this post by Ralph Corderoy
Ralph> May we have the output of `mhlist -verbose' for those two emails?

It's one email, just editing back and forth between the two (I was
trying to reduce to the core problem):

   msg part  type/subtype              size description
  3507       multipart/mixed            24K
               boundary="----=_Part_4723_1712151815.1576230379945"
       1     multipart/alternative      21K
               boundary="----=_Part_4724_2115414819.1576230379946"
       1.1   text/html                  16K
               charset="UTF-8"
       1.2   text/plain                5132
               charset="UTF-8"
       2     application/ics           1499
               name="meetup.ics"
               method="PUBLISH"
               charset="UTF-8"

vs (above is broken, below displays as desired):

   msg part  type/subtype              size description
  9999       multipart/mixed            24K
               boundary="----=_Part_4723_1712151815.1576230379945"
       1     multipart/alternative      21K
               boundary="----=_Part_4724_2115414819.1576230379946"
       1.1   text/html                  16K
               charset="UTF-8"
       1.2   text/plain                5132
               charset="UTF-8"
       2     text/calendar             1450
               name="meetup.ics"
               method="PUBLISH"
               charset="UTF-8"

.. differences between the two on `strace mhshow` include

  - The extracted temp file has a .ics suffix for text/calendar, but not
    for application/ics — but I can change this with mhn.defaults, and
    it makes no difference.

  - The text/calendar tempfile has \n line endings, while the
    application/ics one has \r\n line endings — even though this is the
    exact same base64-encoded content for both: the only difference is
    the Content-Type.

As to whether application/ics is a valid type Ken: meetup.com at least
generates them copiously, so valid or not, they're real unfortunately.

The part *is* an attachment, but when it's a text/calendar attachment it
would appear that mhshow defaults to displaying it.

I attach an example email below.

C.

Message-ID: <[hidden email]>
From: Meetup <[hidden email]>
Sender: [hidden email]
To: [hidden email]
Subject: See you at: blah
MIME-Version: 1.0
Date: Fri, 13 Dec 2019 00:00:00 +0000 (UTC)
Content-Type: multipart/mixed;
        boundary="----=_Part_4723_1712151815.1576230379945"

------=_Part_4723_1712151815.1576230379945
Content-Type: multipart/alternative;
        boundary="----=_Part_4724_2115414819.1576230379946"

------=_Part_4724_2115414819.1576230379946
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

Blah.

------=_Part_4724_2115414819.1576230379946
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: 7bit

<html>
  <head>
    <title>Meetup</title>
  </head>
  <body>
    Blah.
  </body>
</html>

------=_Part_4724_2115414819.1576230379946--

------=_Part_4723_1712151815.1576230379945
Content-Type: application/ics; name=meetup.ics; method=PUBLISH;
        charset=UTF-8
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename=meetup.ics

QkVHSU46VkNBTEVOREFSClZFUlNJT046Mi4wClBST0RJRDotLy9NZWV0dXAvL01lZXR1cCBFdmVu
dHMgdjEuMC8vRU4KQ0FMU0NBTEU6R1JFR09SSUFOCk1FVEhPRDpQVUJMSVNICkJFR0lOOlZUSU1F
Wk9ORQpUWklEOkV1cm9wZS9Mb25kb24KVFpVUkw6aHR0cDovL3R6dXJsLm9yZy96b25laW5mby1v
dXRsb29rL0V1cm9wZS9Mb25kb24KQkVHSU46REFZTElHSFQKVFpPRkZTRVRGUk9NOiswMDAwClRa
T0ZGU0VUVE86KzAxMDAKVFpOQU1FOkJTVApEVFNUQVJUOjE5NzAwMzI5VDAxMDAwMApSUlVMRTpG
UkVRPVlFQVJMWTtCWU1PTlRIPTM7QllEQVk9LTFTVQpFTkQ6REFZTElHSFQKQkVHSU46U1RBTkRB
UkQKVFpPRkZTRVRGUk9NOiswMTAwClRaT0ZGU0VUVE86KzAwMDAKVFpOQU1FOkdNVApEVFNUQVJU
OjE5NzAxMDI1VDAyMDAwMApSUlVMRTpGUkVRPVlFQVJMWTtCWU1PTlRIPTEwO0JZREFZPS0xU1UK
RU5EOlNUQU5EQVJECkVORDpWVElNRVpPTkUKQkVHSU46VkVWRU5UCkRUU1RBTVA6MjAxOTEyMTNU
MDk0NjE5WgpEVFNUQVJUO1RaSUQ9RXVyb3BlL0xvbmRvbjoyMDIwMDEwNVQxOTAwMDAKRFRFTkQ7
VFpJRD1FdXJvcGUvTG9uZG9uOjIwMjAwMTA1VDIxMDAwMApTVEFUVVM6Q09ORklSTUVEClNVTU1B
Ulk6QmxhaApERVNDUklQVElPTjpCbGFoCk9SR0FOSVpFUjtDTj1NZWV0dXAgUmVtaW5kZXI6TUFJ
TFRPOmluZm9AbWVldHVwLmNvbQpDTEFTUzpQVUJMSUMKQ1JFQVRFRDoyMDE5MTIxMFQwMDAwMDBa
CkxPQ0FUSU9OOkJsYWgKVVJMOmh0dHBzOi8vd3d3Lm1lZXR1cC5jb20vClNFUVVFTkNFOjIKTEFT
VC1NT0RJRklFRDoyMDE5MTIxMFQwMDAwMDBaClVJRDpldmVudF9ibGFoQG1lZXR1cC5jb20KRU5E
OlZFVkVOVApFTkQ6VkNBTEVOREFSCg==

------=_Part_4723_1712151815.1576230379945--

Reply | Threaded
Open this post in threaded view
|

Re: text/calendar vs application/ics

Ken Hornstein-2
>The part *is* an attachment, but when it's a text/calendar attachment it
>would appear that mhshow defaults to displaying it.

The answer's in the mhshow(1) man page:

       By  default,  mhshow will display only the text parts of a message that
       are not marked as attachments.  This behavior can  be  changed  by  the
       -notextonly  and  -noinlineonly

Although technically I believe we shouldn't display those calendar
attachments even when they're text/calendar according to that man page,
but ... different problem.

The thinking for those defaults was that show/mhshow are for displaying
"text" content designed to be displayed on a terminal.  Stuff under
"application" is generally supposed to be input to another application.
Hence the reason that text/calendar is under the "text" media type.
You can look at mhshow(1) for more details on how to change that.

--Ken

Reply | Threaded
Open this post in threaded view
|

Re: text/calendar vs application/ics

Conrad Hughes
Ken> The answer's in the mhshow(1) man page:

Thanks Ken; so the man page says that switches like "-type" and "-part"
can "limit and reorder" what mhshow will show, but I guess what I'm
after then is *expanding*, not limiting or reordering.  Adding the
following to my .mh_profile gets me closer to this:

  mhshow: -type text -type application/ics

.. in that it shows application/ics and message text, but I no longer
hear about other attachments — where previously an attached .jpg would
cause a "suppressed" message at the end of show's output, now there's no
mention of it.  So if that's not the right way, then is there an easy
way to get application/ics inlined like text/*?

Alternatively, is there any way of telling nmh that application/ics is
really text/calendar?

Conrad

Reply | Threaded
Open this post in threaded view
|

Re: text/calendar vs application/ics

Ken Hornstein-2
>.. in that it shows application/ics and message text, but I no longer
>hear about other attachments — where previously an attached .jpg would
>cause a "suppressed" message at the end of show's output, now there's no
>mention of it.  So if that's not the right way, then is there an easy
>way to get application/ics inlined like text/*?

We should have a richer way of specifying what content types are to
be displayed ... but we don't.  That code is kind of mess.

I guess ... from looking at the code, what we do EXACTLY is:

- Always display a text part, regardless of the disposition
- If we either have textonly set (the default) or inlineonly set (the default)
  and it is an attachment, output a marker.  Otherwise, try to display it
  (and complaint if it cannot).

So there's really no way (that I can tell right now) of doing what you
want, which is "display this particular application/ics message" but
display all others normally.

>Alternatively, is there any way of telling nmh that application/ics is
>really text/calendar?

Other than 'sed -e s#application/ics#text/calendar#', no.  I was hoping
mhfixmsg could do that, but it seems like right now it cannot (unless I
misunderstood the man page, which is always possible).

You COULD complain to meetup.com; sending out application/ics is total crap.

--Ken

Reply | Threaded
Open this post in threaded view
|

Re: text/calendar vs application/ics

Paul Fox-3
ken wrote:
 > >Alternatively, is there any way of telling nmh that application/ics is
 > >really text/calendar?
 >
 > Other than 'sed -e s#application/ics#text/calendar#', no.  I was hoping
 > mhfixmsg could do that, but it seems like right now it cannot (unless I
 > misunderstood the man page, which is always possible).

Would simply adding more entries to mhn.defaults not work?

paul
=----------------------
paul fox, [hidden email] (arlington, ma, where it's 34.5 degrees)


Reply | Threaded
Open this post in threaded view
|

Re: text/calendar vs application/ics

Ken Hornstein-2
>Would simply adding more entries to mhn.defaults not work?

Those entries already exist ... so no.

The problem is the default for mhshow is "don't try to display stuff,
unless it's text".  You can tell it to try to display everything, and it
will do that, but it won't display the part markers (which is something
Conrad wanted).  We didn't envision a case where someone wanted to treat
an application type as text.

--Ken

Reply | Threaded
Open this post in threaded view
|

Re: text/calendar vs application/ics

Michael Richardson-5
In reply to this post by Conrad Hughes

Conrad Hughes <[hidden email]> wrote:
    > When I mhshow a message with a text/calendar attachment, it's inlined
    > using mhical; if the attachment type is changed to application/ics, it's
    > suppressed instead.  I'm using the latest mhn.defaults from the git
    > repo, which contains

Are they in a multipart/alternative ?  Or something else?

    > mhshow-show-text/calendar: mhical -infile %F
    > mhshow-show-application/ics: mhical -infile %F

    > .. any idea where I should be looking for something else that might
    > differentiate the two?




signature.asc (497 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: text/calendar vs application/ics

Paul Fox-3
In reply to this post by Ken Hornstein-2
Ah, got it.  thanks.

ken wrote:
 > >Would simply adding more entries to mhn.defaults not work?
 >
 > Those entries already exist ... so no.
 >
 > The problem is the default for mhshow is "don't try to display stuff,
 > unless it's text".  You can tell it to try to display everything, and it
 > will do that, but it won't display the part markers (which is something
 > Conrad wanted).  We didn't envision a case where someone wanted to treat
 > an application type as text.
 >
 > --Ken
 >


=----------------------
paul fox, [hidden email] (arlington, ma, where it's 32.7 degrees)


Reply | Threaded
Open this post in threaded view
|

Re: text/calendar vs application/ics

David Levine-3
In reply to this post by Ken Hornstein-2
Ken writes:

> Other than 'sed -e s#application/ics#text/calendar#', no.  I was hoping
> mhfixmsg could do that, but it seems like right now it cannot

That's right.  See below for an example of where I think doing that would be less than helpful.

> You COULD complain to meetup.com; sending out application/ics is total crap.

Google sends it out, along with an (almost) identical text/calendar:

 msg part  type/subtype              size description
   0       multipart/mixed            14K
     1     multipart/alternative      12K
     1.1   text/calendar             1263
     1.2   text/html                 8233
     1.3   text/plain                1173
     2     application/ics           1295
             disposition "attachment"

The only difference between the text/calendar and application/ics content is the line endings, the same as Conrad found (\r\n in the application/ics).

David

Reply | Threaded
Open this post in threaded view
|

Re: text/calendar vs application/ics

David Levine-3
In reply to this post by Ken Hornstein-2
Ken writes:

> The thinking for those defaults was that show/mhshow are for displaying
> "text" content designed to be displayed on a terminal.  Stuff under
> "application" is generally supposed to be input to another application.

Just to note that I'm still searching for the "right" (for me) way to get
mhshow to show as much as it can, even with helper applications.  Maybe
I'll try adding -notextonly -noinlineonly to my profile and see if that
causes any pain.

David

Reply | Threaded
Open this post in threaded view
|

Re: text/calendar vs application/ics

Ralph Corderoy
In reply to this post by David Levine-3
Hi David,

> > You COULD complain to meetup.com
>
> Google sends it out, along with an (almost) identical text/calendar:

I'm seeing signs it's Apple that's spread application/ics.

--
Cheers, Ralph.