Re: $reply_prefix

[Jean Louis]

* Vincent Lefevre  [2022-01-14 12:20]:
> On 2022-01-14 11:05:14 +0300, Jean Louis wrote:
> > I do not see anything that is "against" the RFC5322.
> 
> You misread it. See my other replies.
> 
> > It MAY, and it MAY NOT. There is no strict rule to it.
> 
> Indeed, it doesn't say "MAY NOT", so that "Re: " is not forbidden.
> But this does not mean that other prefixes are allowed.

Quite contrary, my understanding is that it implies that anything is
allowed in the Subject: line. That is foundation of basic freedom for
people to choose how their subject line should or would be.

Better file bug report on that RFC because what kind of standard it
is when it just provides vague instructions with "MAY". It was
capitalized with intention for people to understand that "MAY" implies
"OR MAY NOT".

The point and conclusion is all written in the RFC, this mutt settings
is just fine. It may be there and may be not. RFC says it.

Anything is allowed anyway. But personally I think it is not
necessary, because there is name of the Subject field which is
"Subject: " -- so that alone duplicates the meaning of "in re" in
Lating. It is bug in the RFC. Just ignore it.

> > The true Lating meaning of "Re: " is hardly known to public,
> > IMHO.
> 
> I don't think there really need to know. It is common, standard, and
> people know that it is used in replies, and that's sufficient.

I don't agree. Anything in a computer program should be very
accessible and understandable to computer user. Anything else is lack
of accessibility. If person does not know what is "Forwarding Email"
that function will never be used. If people do not understand what
means "Re: " which became evident as fact worldwide, then they start
replacing it with their own language.

Intention with that RFC was to make a standard. But standard shall be
made based on people's needs, not on RFC writer needs. Even RFC
authors are trying to make best decisions, after some time new
decisions come and new RFCs are enacted. This is because standards are
and should be based for people, not for individual capricious
authors. While it was good idea in beginning to use "Re: " even the
english speaking population does not know Latin, and they think it is
reply to. Meanings are not quite same.

Being robotics to comply to some paper policy which is not policy,
and which could not be implemented properly over time is waste of
time. Do what people do, adopt people's consensus.

> > Thus RFC5322 does not contribute to overall understanding. It remains
> > as capricious decision by Latin language speaker who introduced it in
> > the document. It does not represent international consent.
> 
> The point is technical. Without a standard prefix, you could get
> accumulated ones, as it occurs in practice due to MUAs not following
> the RFC.

It is definitely disturbing to see "Re: Re: Re: " in subject lines.


Jean

Take action in Free Software Foundation campaigns:
https://www.fsf.org/campaigns

In support of Richard M. Stallman
https://stallmansupport.org/

Re: $reply_prefix

[Jean Louis]

* Tapani Tarvainen  [2022-01-14 10:20]:
> On Thu, Jan 13, 2022 at 08:20:55PM -0800, Kevin J. McCarthy (ke...@8t8.us) 
> wrote:
> 
> > I've been told other prefixes are often used in some lists, and the
> > practice is getting more common.
> 
> Other prefixes have also long been used by some non-English speakers
> and lists. While it does have its downsides, I also understand the
> need, and I would like to conform to such customs in order to avoid
> accumulating mixed prefixes.
> 
> So I would like to have mutt allow changing the reply prefix, even if
> it is arguably against RF5322.

I do not see anything that is "against" the RFC5322.

First the quote from RFC5322: https://datatracker.ietf.org/doc/html/rfc5322

3.6.5.  Informational Fields

   The informational fields are all optional.  The "Subject:" and
   "Comments:" fields are unstructured fields as defined in section
   2.2.1, and therefore may contain text or folding white space.  The
   "Keywords:" field contains a comma-separated list of one or more
   words or quoted-strings.

   subject =   "Subject:" unstructured CRLF

   comments=   "Comments:" unstructured CRLF

   keywords=   "Keywords:" phrase *("," phrase) CRLF

   These three fields are intended to have only human-readable content
   with information about the message.  The "Subject:" field is the most
   common and contains a short string identifying the topic of the
   message.  When used in a reply, the field body MAY start with the
   string "Re: " (an abbreviation of the Latin "in re", meaning "in the
   matter of") followed by the contents of the "Subject:" field body of
   the original message.  If this is done, only one instance of the
   literal string "Re: " ought to be used since use of other strings or
   more than one instance can lead to undesirable consequences.  The
   "Comments:" field contains any additional comments on the text of the
   body of the message.  The "Keywords:" field contains a comma-
   separated list of important words and phrases that might be useful
   for the recipient.

It MAY, and it MAY NOT. There is no strict rule to it.

The true Lating meaning of "Re: " is hardly known to public,
IMHO. Latin language may be said to be hardly international in the
context of email transmission.

RFC in general are not hard rules to be followed, yet those represent
invitation to agreements between people and communication relations.

Internationally, people are using various localized versions for
decades already.

List of email subject abbreviations - Wikipedia
https://en.wikipedia.org/wiki/List_of_email_subject_abbreviations

People already misunderstand what "Re: " is meant to be:
https://en.wikipedia.org/wiki/List_of_email_subject_abbreviations#Standard_prefixes

Thus RFC5322 does not contribute to overall understanding. It remains
as capricious decision by Latin language speaker who introduced it in
the document. It does not represent international consent.


-- 
Thanks,
Jean Louis

Take action in Free Software Foundation campaigns:
https://www.fsf.org/campaigns

Re: $reply_prefix

[Vincent Lefevre]

On 2022-01-13 19:41:12 -0800, Will Yardley wrote:
> On Thu, Jan 13, 2022 at 09:42:27PM -0500, John Hawkinson wrote:
> > Although my personal preference is that this is not a knob Mutt needs,
> > I am cognizant that some other popular MUAs use "RE: " rather than
> > "Re: " and while that looks horrid to my eye, it is not obviously
> > violative of RFC5322 and some might like Mutt to be configurable to
> > match.
> [...] 
> > Perhaps language from RFC5322 Sec. 3.6.5 should be imported into the
> > documentation for $reply_prefix, but even that is oddly permissive
> > ("When used in a reply, the field body MAY start with the string "Re:
> > "") and it would be weird to change it to MUST, but I suppose wcould.
>  
> I looked this up as well -- since it's a "MAY", I would agree that the
> change probably does _not_ technically violate the RFC.

The context is about the subject of a topic:

  The "Subject:" field is the most common and contains a short string
  identifying the topic of the message.

So, the subject is not expected to change in a reply, otherwise the
reply will be regarded as a different topic. What the RFC says is
that there is an exception: "Re: " may be added before the contents
of the "Subject:" field body of the original message. I suppose that
the alternative is to leave the subject as is, without any prefix
(note that the "In-Reply-To:" header is sufficient to indicate that
this is a reply).

> While it does mention the "undesirable consequences" of people using
> other prefixes from deduplication problems, e.g.,
> 
>  AW: Re: RE: RE: AW: Some subject line
> 
> and that in the case where it is present "only one instance ... ought to
> be used", it doesn't specifically say that other prefixes couldn't be
> used.

Using another string breaks something like a "should". Though this
is not strictly forbidden, this is regarded as a bad choice.

Imagine that any language (including those in a non-Latin script)
would like to use its own reply prefix, and the complexity to handle
that...

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Re: $reply_prefix

[Vincent Lefevre]

On 2022-01-13 21:25:27 -0800, Kevin J. McCarthy wrote:
> On Thu, Jan 13, 2022 at 11:57:37PM -0500, John Hawkinson wrote:
> > One is confined to the content of a message and the other affects
> > critical message metadata that is often displayed in abbreviated form.
> 
> "Critical message metadata" that is (*ahem*) gently suggested via MAY in the
> RFC.

See my other reply. "MAY" is just because "Re: " is allowed instead of
nothing. Otherwise there is the sentence with "ought".

> However, I am listening, and if the general consensus is that this option is
> a bad idea, I will back it out.

OK, thanks.

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Re: $reply_prefix

[Vincent Lefevre]

On 2022-01-14 11:05:14 +0300, Jean Louis wrote:
> I do not see anything that is "against" the RFC5322.

You misread it. See my other replies.

> It MAY, and it MAY NOT. There is no strict rule to it.

Indeed, it doesn't say "MAY NOT", so that "Re: " is not forbidden.
But this does not mean that other prefixes are allowed.

> The true Lating meaning of "Re: " is hardly known to public,
> IMHO.

I don't think there really need to know. It is common, standard, and
people know that it is used in replies, and that's sufficient.

> Latin language may be said to be hardly international in the
> context of email transmission.

Well, just a word. But note that it is not forbidden to use something
else for display, just like what is done for the standard headers
"From", "To", etc.

> People already misunderstand what "Re: " is meant to be:
> https://en.wikipedia.org/wiki/List_of_email_subject_abbreviations#Standard_prefixes

What is said is that people may misunderstand the origin of "Re".
I also thought that this was an abbreviation of "Reply" (instead
of the Latin origin). This did not prevent me from knowing what
it means in practice.

> Thus RFC5322 does not contribute to overall understanding. It remains
> as capricious decision by Latin language speaker who introduced it in
> the document. It does not represent international consent.

The point is technical. Without a standard prefix, you could get
accumulated ones, as it occurs in practice due to MUAs not following
the RFC.

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Re: $reply_prefix

[Vincent Lefevre]

On 2022-01-14 09:49:12 +0100, Fredrik Gustafsson wrote:
> That's already the case. For example in Sweden, "Sv:" is used instead of
> "Re:". This is not a mutt decision and
> the decision is already made for us. We can like it or dislike it.

Fortunately most people do not use it. In my mail archives, I can see
only one message with "Sv:" in the subject, and one can see a start
of accumulation of prefixes:

  Subject: Sv: Re: Motion 31: V04.2 Revision of proposed Level 1 text

and that was in an international mailing-list (note that there were
no replies to this message).

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Re: $reply_prefix

[Fredrik Gustafsson]

Den fre 14 jan. 2022 kl 09:38 skrev Vincent Lefevre :

> Imagine that any language (including those in a non-Latin script)
> would like to use its own reply prefix, and the complexity to handle
> that...
>

That's already the case. For example in Sweden, "Sv:" is used instead of
"Re:". This is not a mutt decision and
the decision is already made for us. We can like it or dislike it.

/Fredrik

Re: $reply_prefix

[Vincent Lefevre]

On 2022-01-14 09:10:19 +0200, Tapani Tarvainen wrote:
> On Thu, Jan 13, 2022 at 08:20:55PM -0800, Kevin J. McCarthy (ke...@8t8.us) 
> wrote:
> 
> > I've been told other prefixes are often used in some lists, and the
> > practice is getting more common.
> 
> Other prefixes have also long been used by some non-English speakers
> and lists. While it does have its downsides, I also understand the
> need, and I would like to conform to such customs in order to avoid
> accumulating mixed prefixes.

In any case, "Re: " is allowed by RFC 5322, thus must be recognized
by all MUAs, so that its use will avoid accumulating mixed prefixes.
If other MUAs don't recognize "Re: ", complain to them; but to
mitigate that, $reply_regexp can already be used. Alternatively,
Mutt could offer the choice not to use a prefix at all, as allowed
by the RFC (the "Re: " is optional).

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Re: Mutt on ubuntu 20

[Derek Martin]

On Fri, Jan 14, 2022 at 03:19:39AM +0100, Vincent Lefevre wrote:
> On 2022-01-13 15:36:04 -0600, Derek Martin wrote:
> > So...  The only difference between this and hdrdefault is that
> > hdrdefault's order does not matter.  This is a very minor difference,
> > and the distinction disappears so long as you provide the "." rule
> > first,
> 
> This would mean that it would not be possible to change the default
> header color from a running Mutt.

No it doesn't; use uncolor, then enter the rules in the correct order.

I'm well aware doing that would be dumb, but it IS possible.  It would
be far more sensible to just restart Mutt with the updated config,
which is what any reasonable person would do, and which is necessary
in any case to make the change permanent.  This is such an uncommon
case that considering it seems silly, but regardless, it's false.

> Currently, my header color settings do not depend on any order as they
> are mutually exclusive

That's possible, if your rules are very carefully crafted; but it's
not generally true as Mutt's regex rules are inherently ordered, and
if it is true in your case it is specific to your rules, not Mutt's
functionality generally.  But it's irrelevant; the config language not
having the precise semantics you personally prefer does not change the
fact that you STILL CAN achieve the same result without the default
keyword.

Redundant.

> > just as you must already do with send-hook and every other
> 
> I don't use send-hook (and other hooks) on "color header".

That's not what I'm saying.

# apply a default folder hook
folder-hook . set x=foo
# other folders
folder-hook work set x=bar
folder-hook ice-cream set x=baz
...

The . rule must come first.  There is no default folder-hook.  The
necessity of ordering has precedence in Mutt and is inherent in any
case.

And yes, ice cream definitely deserves its own mail folder. =8^)

I've had my fill of this pointless argument.  Especially pointless
since I'm not actually advocating removing it.

-- 
Derek D. Martinhttp://www.pizzashack.org/   GPG Key ID: 0xDFBEAD02
-=-=-=-=-
This message is posted from an invalid address.  Replying to it will result in
undeliverable mail due to spam prevention.  Sorry for the inconvenience.



signature.asc
Description: PGP signature

Re: $reply_prefix

[Eike Rathke]

Hi,

On Friday, 2022-01-14 14:36:13 +0300, Jean Louis wrote:

> > > It MAY, and it MAY NOT. There is no strict rule to it.
> > 
> > Indeed, it doesn't say "MAY NOT", so that "Re: " is not forbidden.
> > But this does not mean that other prefixes are allowed.
> 
> Quite contrary, my understanding is that it implies that anything is
> allowed in the Subject: line. That is foundation of basic freedom for
> people to choose how their subject line should or would be.
> 
> Better file bug report on that RFC because what kind of standard it
> is when it just provides vague instructions with "MAY". It was
> capitalized with intention for people to understand that "MAY" implies
> "OR MAY NOT".

Suggested reading:
https://datatracker.ietf.org/doc/html/rfc2119
specifically
https://datatracker.ietf.org/doc/html/rfc2119#section-5

> The point and conclusion is all written in the RFC, this mutt settings
> is just fine. It may be there and may be not. RFC says it.

https://datatracker.ietf.org/doc/html/rfc5322#section-3.6.5
| When used in a reply, the field body MAY start with the
| string "Re: " (an abbreviation of the Latin "in re", meaning "in the
| matter of") followed by the contents of the "Subject:" field body of
| the original message.

A "Re: " in a reply is optional. It does not say that anything else may
prefix the original Subject.

  Eike

-- 
OpenPGP/GnuPG encrypted mail preferred in all private communication.
GPG key 0x6A6CD5B765632D3A - 2265 D7F3 A7B0 95CC 3918  630B 6A6C D5B7 6563 2D3A
Use LibreOffice! https://www.libreoffice.org/


signature.asc
Description: PGP signature

Re: $reply_prefix

[Derek Martin]

On Fri, Jan 14, 2022 at 09:37:06AM +0100, Vincent Lefevre wrote:
> On 2022-01-13 19:41:12 -0800, Will Yardley wrote:
> > On Thu, Jan 13, 2022 at 09:42:27PM -0500, John Hawkinson wrote:
> > > Perhaps language from RFC5322 Sec. 3.6.5 should be imported into the
> > > documentation for $reply_prefix, but even that is oddly permissive
> > > ("When used in a reply, the field body MAY start with the string "Re:
> > > "") and it would be weird to change it to MUST, but I suppose wcould.
> >  
> > I looked this up as well -- since it's a "MAY", I would agree that the
> > change probably does _not_ technically violate the RFC.
> 
> The context is about the subject of a topic:
> 
>   The "Subject:" field is the most common and contains a short string
>   identifying the topic of the message.
> 
> So, the subject is not expected to change in a reply, otherwise the
> reply will be regarded as a different topic. What the RFC says is
> that there is an exception: "Re: " may be added before the contents
> of the "Subject:" field body of the original message. I suppose that
> the alternative is to leave the subject as is, without any prefix
> (note that the "In-Reply-To:" header is sufficient to indicate that
> this is a reply).

FWIW, I agree 100% with this interpretation as well.

-- 
Derek D. Martinhttp://www.pizzashack.org/   GPG Key ID: 0xDFBEAD02
-=-=-=-=-
This message is posted from an invalid address.  Replying to it will result in
undeliverable mail due to spam prevention.  Sorry for the inconvenience.



signature.asc
Description: PGP signature

Re: $reply_prefix

[Derek Martin]

On Fri, Jan 14, 2022 at 04:27:10PM -0600, Derek Martin wrote:
> On Thu, Jan 13, 2022 at 09:25:27PM -0800, Kevin J. McCarthy wrote:
> > On Thu, Jan 13, 2022 at 11:57:37PM -0500, John Hawkinson wrote:
> > > Kevin J. McCarthy  wrote on Thu, 13 Jan 2022
> > > at 23:20:55 EST in :
> > > 
> > > > I've been told other prefixes are often used in some lists, and the 
> > > > practice
> > > > is getting more common.  Why not give users the option to adjust it, if 
> > > > they
> > > > deem it appropriate, for some lists?
> > > 
> > > The reason not to is that the knob encourages the proliferation of
> > > alternative prefixes and that is bad for everyone.
> > 
> > I think we'll have to disagree about what encouragement is, then.  IMHO the
> > option enables, but doesn't encourage.
> 
> "Hey, this software has a knob to enable the thing I was just thinking
> I should do.  Must be OK!"

Er, I meant to say (explicitly) that providing a feature to enable
users' bad ideas is certainly a form of encouragment.  At the very
least, it can be considered indirect encouragment.

-- 
Derek D. Martinhttp://www.pizzashack.org/   GPG Key ID: 0xDFBEAD02
-=-=-=-=-
This message is posted from an invalid address.  Replying to it will result in
undeliverable mail due to spam prevention.  Sorry for the inconvenience.



signature.asc
Description: PGP signature

Re: $reply_prefix

[Derek Martin]

On Thu, Jan 13, 2022 at 09:25:27PM -0800, Kevin J. McCarthy wrote:
> On Thu, Jan 13, 2022 at 11:57:37PM -0500, John Hawkinson wrote:
> > Kevin J. McCarthy  wrote on Thu, 13 Jan 2022
> > at 23:20:55 EST in :
> > 
> > > I've been told other prefixes are often used in some lists, and the 
> > > practice
> > > is getting more common.  Why not give users the option to adjust it, if 
> > > they
> > > deem it appropriate, for some lists?
> > 
> > The reason not to is that the knob encourages the proliferation of
> > alternative prefixes and that is bad for everyone.
> 
> I think we'll have to disagree about what encouragement is, then.  IMHO the
> option enables, but doesn't encourage.

"Hey, this software has a knob to enable the thing I was just thinking
I should do.  Must be OK!"

-- 
Derek D. Martinhttp://www.pizzashack.org/   GPG Key ID: 0xDFBEAD02
-=-=-=-=-
This message is posted from an invalid address.  Replying to it will result in
undeliverable mail due to spam prevention.  Sorry for the inconvenience.



signature.asc
Description: PGP signature

Re: $reply_prefix

[Derek Martin]

On Fri, Jan 14, 2022 at 11:05:14AM +0300, Jean Louis wrote:
>The "Subject:" field is the most common and contains a short
>string identifying the topic of the message.  When used in a
>reply, the field body MAY start with the string "Re: " (an
>abbreviation of the Latin "in re", meaning "in the matter of")
>followed by the contents of the "Subject:" field body of the
>original message.  If this is done, only one instance of the
>literal string "Re: " ought to be used since use of other strings
>or more than one instance can lead to undesirable consequences.

> It MAY, and it MAY NOT. There is no strict rule to it.

Not so.  As another poster attempted to point out, "MAY" (all caps)
has a very specific meaning in RFCs. However even in standard English,
the same meaning applies here.  The RFC names exactly one thing
that MAY be done, specifically in the context of subject lines in
replies--only that one thing (starting the subect string with the
expressly stated string "Re:") may be done... You can choose to NOT do
that thing, but this does not give you permission to do any other
random thing you like.

Secondly even ignoring that, your interpretation makes zero sense in
the context of what follows, where it discusses the handling of (quite
specifically) the "Re:" strings from multiple replies... but not
random other strings.

> Thus RFC5322 does not contribute to overall understanding. It remains
> as capricious decision by Latin language speaker who introduced it in
> the document. It does not represent international consent.

Again, no.  Latin phrases and abbreviations are present in formal
writing of most languages on Earth, and typically in formal writing
and acadamia their usage is expected and even required, in some
circumstances.  Latin is typically (still) used in such contexts
probably largely out of custom, but because it formerly was the
ubiquitous common language of acadamia, and the many such
abbreviations are short, precise, and generally commonly understood by
educated people of all nations and languages.

-- 
Derek D. Martinhttp://www.pizzashack.org/   GPG Key ID: 0xDFBEAD02
-=-=-=-=-
This message is posted from an invalid address.  Replying to it will result in
undeliverable mail due to spam prevention.  Sorry for the inconvenience.



signature.asc
Description: PGP signature

Re: $reply_prefix

[Derek Martin]

On Fri, Jan 14, 2022 at 09:10:19AM +0200, Tapani Tarvainen wrote:
> On Thu, Jan 13, 2022 at 08:20:55PM -0800, Kevin J. McCarthy (ke...@8t8.us) 
> wrote:
> 
> > I've been told other prefixes are often used in some lists, and the
> > practice is getting more common.
> 
> Other prefixes have also long been used by some non-English speakers
> and lists. 

Indeed, which is why the RFC exists.  But it has long been a design
principle of Mutt that it should emit only output which conforms to
the RFCs, in keeping with the robustness principle:  "Be lenient in
what you accept, but strict in what you emit."  When other mail
clients (or mail users) do not adhere to that, Mutt is not at fault.

I realize there is an element of "tilting at windmills" to this, but,
if you run into such cases which cause issues, your complaint should
be with tthose users or mail clients, not Mutt, since Mutt obeys the
rules.


-- 
Derek D. Martinhttp://www.pizzashack.org/   GPG Key ID: 0xDFBEAD02
-=-=-=-=-
This message is posted from an invalid address.  Replying to it will result in
undeliverable mail due to spam prevention.  Sorry for the inconvenience.



signature.asc
Description: PGP signature

Re: $reply_prefix

[Derek Martin]

On Fri, Jan 14, 2022 at 03:26:36AM +0100, Vincent Lefevre wrote:
> I strongly disagree with the addition of $reply_prefix
> (commit 9c1ce59874ce1c8e97d0c5bd71847596dafb1d50), as this is
> contrary to RFC 5322, and non-standard prefixes are annoying
> in practice and not necessarily recognized by other users.
> 
> Sure, a user could already change it manually (or automatically
> with things like wrappers), but he should not be encouraged to
> do so (in particular by making this automatic). End users are not
> necessarily aware of RFCs and technical issues behind some choices.

I wholeheartedly agree.  I'm pretty sure I already said that
somewhere... or at least meant to. :)

-- 
Derek D. Martinhttp://www.pizzashack.org/   GPG Key ID: 0xDFBEAD02
-=-=-=-=-
This message is posted from an invalid address.  Replying to it will result in
undeliverable mail due to spam prevention.  Sorry for the inconvenience.



signature.asc
Description: PGP signature