Re: text/calendar vs application/ics
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.
Re: text/calendar vs application/ics
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
Re: text/calendar vs application/ics
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/mixed14K 1 multipart/alternative 12K 1.1 text/calendar 1263 1.2 text/html 8233 1.3 text/plain1173 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
Re: text/calendar vs application/ics
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, p...@foxharp.boston.ma.us (arlington, ma, where it's 32.7 degrees)
Re: text/calendar vs application/ics
Conrad Hughes 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 Description: PGP signature
Re: text/calendar vs application/ics
>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
Re: text/calendar vs application/ics
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, p...@foxharp.boston.ma.us (arlington, ma, where it's 34.5 degrees)
Re: text/calendar vs 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/*? 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
Re: text/calendar vs application/ics
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
Re: text/calendar vs application/ics
>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
Re: text/calendar vs application/ics
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/mixed24K
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/plain5132
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
multipart/mixed24K
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/plain5132
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:
<1140016141.1576230379946.JavaMail.root@ip-10-192-12-144.ec2.internal>
From: Meetup
Sender: i...@meetup.com
To: biz_nmh_work...@xrad.org
Subject: See you at: blah
MIME-Version: 1.0
Date: Fri, 13 Dec 2019 00:00:00 + (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
Meetup
Blah.
--=_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--
Re: text/calendar vs application/ics
>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
Re: text/calendar vs application/ics
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.
