Keith Moore writes:
1. Mail senders SHOULD NOT generate group syntax.
maybe, maybe not. groups are useful.
They're not used...
they are used, just not terribly often. but the utility of a feature
is not directly related to the frequency of its use.
I agree with the latter sentence.
(Btw, I can think of at least three other reasons why they don't
parse groups, so I don't think that presumption is warranted.)
which are?
Some good reasons, some bad:
1. A judgment that it's better for the user to optimize the UI for the
simple case, ie. no groups visible.
2. Some people choose to support only what a set of major MUAs
generates. (Many people develop with limited time and money, and test
all that they support. Sometimes that entails making choices noone
likes.)
3. "It's ugly". You know, the RFC2047/2231 argument.
4. Some people test only with a corpus of real-world mail. Me, I have a
corpus of 1.6 million messages where groups don't occur even once. In
such a setting, it's easy for group-related bugs to slip through.
surely it's harder to read and adhere to the combination of both
RFCs X and Y? particularly when they give conflicting advice?
Specious comparison. People aren't really adhering to RFC X in the
first place.
but are we going to help the situation by giving them more to read?
or to put it another way, where is the barrier?
The primary barrier is IMO in the large number of deployed mail
parsers/readers that haven't been tested with groups, and cannot be
assumed to work.
or maybe the barrier is in trying to get so many different
implementations of a complex protocol (which doesn't support enough
features as it is) to act consistently and compatibly with one
another?
Yes...
Arnt