From: Knut Magnus Aasrud <km@aasrud.com>

Signed-off-by: Knut Magnus Aasrud <km@aasrud.com>
---
Since applications MUST merely check for `.m2dir` and `.m2store`, we
can only STRONGLY RECOMMEND they keep them empty. Also, I think it is
worth rephrasing a bit to clarify that this is in the name of forward
compatibility.

 index.md | 16 ++++++++--------
 1 file changed, 8 insertions(+), 8 deletions(-)

diff --git a/index.md b/index.md
index d589623..1ceb996 100644
--- a/index.md
+++ b/index.md
@@ -74,10 +74,10 @@ m2dir-compliant applications.
 An m2store root **must** contain an empty marker file `.m2store` to enable
 discovery by other m2dir-compatible applications.

-The `.m2store` marker file **must** be empty. However, applications should
-merely check for the file's presence. Future versions of the spec may use the
-marker file's content, e.g. to indicate support for a revised version of the
-spec.
+The `.m2store` marker file is **strongly recommended** to be empty. However,
+applications **must** merely check for the file's presence, as future versions
+of the spec may use the marker file's content, e.g. to indicate support for new
+functionality.

 ## Default delivery target
 [default]: #default-delivery-target
@@ -151,10 +151,10 @@ example require that the user explicitly specify the remote mailbox.
 A directory that stores emails in m2dir format according to this specification
 **must** contain a marker file `.m2dir`.

-The `.m2dir` marker file **must** be empty. However, applications **must**
-merely check for the file's presence. Future versions of the spec may use the
-marker file's content, e.g. to indicate support for a revised version of the
-spec.
+The `.m2dir` marker file is **strongly recommended** to be empty. However,
+applications **must** merely check for the file's presence, as future versions
+of the spec may use the marker file's content, e.g. to indicate support for new
+functionality.

 Every file in the m2dir represents an email. Files starting with a period (`.`)
 **must** be ignored, unless they are specified in this document.
--
2.44.0

On 4/12/24 10:47 AM, km@aasrud.com wrote:
> From: Knut Magnus Aasrud <km@aasrud.com>
> 
> Signed-off-by: Knut Magnus Aasrud <km@aasrud.com>
> ---
> Since applications MUST merely check for `.m2dir` and `.m2store`, we
> can only STRONGLY RECOMMEND they keep them empty. Also, I think it is
> worth rephrasing a bit to clarify that this is in the name of forward
> compatibility.
> 
>   index.md | 16 ++++++++--------
>   1 file changed, 8 insertions(+), 8 deletions(-)
> 
> diff --git a/index.md b/index.md
> index d589623..1ceb996 100644
> --- a/index.md
> +++ b/index.md
> @@ -74,10 +74,10 @@ m2dir-compliant applications.
>   An m2store root **must** contain an empty marker file `.m2store` to enable
>   discovery by other m2dir-compatible applications.
> 
> -The `.m2store` marker file **must** be empty. However, applications should
> -merely check for the file's presence. Future versions of the spec may use the
> -marker file's content, e.g. to indicate support for a revised version of the
> -spec.
> +The `.m2store` marker file is **strongly recommended** to be empty. However,
> +applications **must** merely check for the file's presence, as future versions
> +of the spec may use the marker file's content, e.g. to indicate support for new
> +functionality.

Not entirely sure about the must -> strongly recommended part. I mean, 
this is getting a bit philosophical, but even if nothing _reads_ the 
file, it's still fair to say that an application creating that file 
_must_ keep it empty, to not mess with potential future extensions?

> Not entirely sure about the must -> strongly recommended part. I mean, 
> this is getting a bit philosophical, but even if nothing _reads_ the 
> file, it's still fair to say that an application creating that file 
> _must_ keep it empty, to not mess with potential future extensions?

That is true, but then a future version of m2dir that has something in 
the dotfiles would not be backwards compatible. By using STRONGLY 
RECOMMENDED, we don't need to break compatibility if something like this 
is added in the future.

Say, m2dir 1.0 STRONGLY RECOMMENDS to keep the files empty, but an 
application that supports it chooses to put some random data there. m2dir 
bumps to 1.1 and adds a version tag in the dotfiles. That application 
broke the recommendation and is therefore limited to only supporting 1.0. 
However, any application written for 1.1 would also support 1.0. That is 
not the case if MUST is used.

On Tue, 16 Apr 2024, at 11:18, Knut Magnus Aasrud wrote:
>> Not entirely sure about the must -> strongly recommended part. I mean, 
>> this is getting a bit philosophical, but even if nothing _reads_ the 
>> file, it's still fair to say that an application creating that file 
>> _must_ keep it empty, to not mess with potential future extensions?
>
> That is true, but then a future version of m2dir that has something in 
> the dotfiles would not be backwards compatible. By using STRONGLY 
> RECOMMENDED, we don't need to break compatibility if something like this 
> is added in the future.
>
> Say, m2dir 1.0 STRONGLY RECOMMENDS to keep the files empty, but an 
> application that supports it chooses to put some random data there. m2dir 
> bumps to 1.1 and adds a version tag in the dotfiles. That application 
> broke the recommendation and is therefore limited to only supporting 1.0. 
> However, any application written for 1.1 would also support 1.0. That is 
> not the case if MUST is used.

Perhaps the right wording here is "For v1.0, this file MUST be empty. Its
contents are reserved for use in a future version".

-- 
Hugo