ietf-822
[Top] [All Lists]

Re: Understanding response protocols

2004-09-17 09:48:43

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