I also doubt that it's reasonable to use a single header field to
communicate preferences for group replies, because the recipient may
need to act differently depending on _why_ that field was set, and the
recipient's UA may need to act differently (say to alert the recipient
to an exceptional condition) depending on why that field was set. But
I'm still thinking about this.
But the MFT field is clearly _capable_ of dealing with a variety of
sitations,
no, it's not _clearly_ capable, because overloading is often a Bad Idea.
Now if you want it to be evident which particular situation applies in
each case (because users may want to modify their responses accordingly),
then that is a reasonable request, and it could be tackled in various
ways, such as:
1. Invent Yet-Another-header-field
2. Add additional features to an existing field (e.g. to MFT or Reply-To),
which can be further subdivided into:
2a. Fit it into existing syntax (e.g. group syntax or comments)
2b. Add new syntax (e.g. MIME-style parameters); could hardly be added
to Reply-To, but could be OK for MFT which is not yet standardized.
Yes, I'm considering things like that. I suspect there's enough deployment
of MFT that we shouldn't change the syntax. It might be better to use a
different field name entirely if the MFT syntax were not found to be adequate.
Keith