Subject: Re: bug#68687: [PATCH] Use text/org media type

From: Stefan Kangas <[email-masked]>
Date: Thu, 1 Feb 2024 23:09:42 -0800

Max Nikulin <[email-masked]> writes:

> On 01/02/2024 03:00, Stefan Kangas wrote:
>> Max Nikulin writes:
>>> +++ b/lisp/net/mailcap.el
>>> @@ -989,7 +989,8 @@ (defvar mailcap-mime-extensions
>>>       (".jpe"   . "image/jpeg")
>>>       (".jpeg"  . "image/jpeg")
>>>       (".webp"  . "image/webp")
>>> -    (".org"   . "text/x-org"))
>>> +    ;; May be overridden by application/vnd.lotus-organizer in /etc/mime.types.
>>> +    (".org"   . "text/org"))
>
> Org files are plain text files and have no specific signature that would
> allow tools like libmagic to unambiguously distinguish them from other
> text files. Rare files have explicit "# -*- mode: org-mode -*-" header.
> So there is no other way besides file name extensions when a message is
> composed or a file is served by a HTTP server. Clients should rely on
> the Content-Type header.

So old mailers will still use "Content-Type: text/x-org", and it is
therefore premature to remove that entry.

I'm not sure about the urgency in starting to send out "text/org" at
this stage.  It will just lead to old versions of Emacs displaying org
attachments incorrectly in more cases, I think?

So why not:

 1. Add support for _receiving_ "text/org" in Emacs 30
 2. Wait with _sending_ "text/org" until it is formally accepted by IANA

?

In Emacs <29, perhaps Org mode could update the relevant variables to
include "text/org", too?

>> Is it
>> documented somewhere how to override that system configuration in Emacs?
>
> Create ~/.mime.types. Debian's variant suggests it in the
> /etc/mime.types header.

Is that documented somewhere in our documentation?

>> But thinking about this more, why not do that unconditionally for users?
>> Lotus Organizer is dead, long gone, and not really relevant to anyone,
>> certainly not to the overwhelming majority of Emacs users.
>
> Ideally text/org should be registered in IANA, so all applications could
> use consistent mapping. Prerequisites have been discussed already.

Yes, that would be best.  While waiting for that to happen, why not do
what I proposed (override it unconditionally in Emacs)?  It should be
more useful for Emacs users, if nothing else.

Taking a step back, how sure are we that IANA will accept this?  Do they
typically accept taking over a previous designation?