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.
if we deprecate the group syntax we will wind up reinventing it.
Perhaps whatever we then invent will be used.
I don't know why groups aren't used. Perhaps it's because people have
little use for the concept, or perhaps there's some detail about their
syntax. In the latter case, a reinvention might succeed where groups
haven't.
many people don't know about them. some MUAs make it difficult to
support groups because they're trying to make it easy to input one
address at a time.
(822 address field syntax may be a culprit here. what with phrases,
angle brackets, quoting rules, comments, etc. (and encoded-words which
were added later) it's too baroque to expect ordinary people to type it
in correctly. and yet when MUAs try to insulate that syntax from the
users, it robs senders of the power to express things like the _roles_
of recipients or why they're being sent the message.)
this proposal strikes me as one of the form: since people won't
adhere to RFC X, presumably because they don't bother to read it
fully, let's write RFC Y that tells them to do something else.
More like "... let's write RFC Y telling other people that they
shouldn't expect anyone to adhere to RFC X".
(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? (or maybe I learned so long ago that address fields need to
be lexically analyzed left-to-right and parsed right-to-left that I've
almost forgotten that phrases and group syntax complicate parsing for
those who haven't yet realized that.)
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? is it in reading and
understanding the RFCs or in implementing them? 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?