On org-syntax and IANA MIME type registration

On org-syntax and IANA MIME type registration

[Timothy]

[-- Attachment #1: Type: text/plain, Size: 1520 bytes --]

Hi All,

With the recent mention of the text/org mime type, and registering it as an IANA
in-tree MIME type in particular, I’d like to draw attention to this part of
<https://www.rfc-editor.org/rfc/rfc6838.html#section-3.1>:

> When review is required, a change request may be denied if it renders entities
> that were valid under the previous definition invalid under the new definition.

While the org-syntax document is a work in progress to accurately describe the
current state of affairs, there are currently supported syntactic elements that
I think are broadly seen as “would be nice if we didn’t do that”. For example:
the special switch syntax in babel headers, and support for $-maths.

This does make me wonder if we should actually try to register a slightly
different org-syntax to “what org-mode parses”, without these elements that we
now think we’re better off without, but have org-mode still parse them.

My thinking is we don’t want to lock ourselves into a situation where we would
/like/ to deprecate certain syntax over the long term, but are unable to do so
without diverging from the IANA-registered specification, and can’t register the
change in syntax because of the paragraph I’ve quoted.

All the best,
Timothy

-- 
Timothy (‘tecosaur’/‘TEC’), Org mode contributor.
Learn more about Org mode at <https://orgmode.org/>.
Support Org development at <https://liberapay.com/org-mode>,
or support my work at <https://liberapay.com/tec>.

Re: On org-syntax and IANA MIME type registration

[Ihor Radchenko]

[CCing Wes Hardaker]

Timothy <orgmode@tec.tecosaur.net> writes:

> With the recent mention of the text/org mime type, and registering it as an IANA
> in-tree MIME type in particular, I’d like to draw attention to this part of
> <https://www.rfc-editor.org/rfc/rfc6838.html#section-3.1>:
>
>> When review is required, a change request may be denied if it renders entities
>> that were valid under the previous definition invalid under the new definition.

AFAIU from the other instances of word "entities" in the document, it
refers to files of Org type. So, the above is meant that previously
valid Org documents cannot become invalid.

> While the org-syntax document is a work in progress to accurately describe the
> current state of affairs, there are currently supported syntactic elements that
> I think are broadly seen as “would be nice if we didn’t do that”. For example:
> the special switch syntax in babel headers, and support for $-maths.

I do not think that $-math or switches are significant enough to render
Org mode documents invalid. They are minor changes.

> This does make me wonder if we should actually try to register a slightly
> different org-syntax to “what org-mode parses”, without these elements that we
> now think we’re better off without, but have org-mode still parse them.

Maybe for $...$, but not for switches. We may instead make the syntax
description broad enough to allow switches without explicitly describing
how they should be interpreted.

> My thinking is we don’t want to lock ourselves into a situation where we would
> /like/ to deprecate certain syntax over the long term, but are unable to do so
> without diverging from the IANA-registered specification, and can’t register the
> change in syntax because of the paragraph I’ve quoted.

I don't think that it is going to be a major problem.

-- 
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at <https://orgmode.org/>.
Support Org development at <https://liberapay.com/org-mode>,
or support my work at <https://liberapay.com/yantar92>