An interesting idea. I wonder whether you could appropriate fields from other RFC 2822-like header specifications. I also wonder whether the disparate purposes you’re suggesting for this information wouldn’t be better as separate fields.
The name X-Respond-By could perhaps be better named
X-Respond-Before, since “by” could be taken to
indicate the person who responds.
automatic expiry of messages whose deadlines have passed, possibly with an acknowledgement issued to the sender
Wouldn’t this be more clearly specified as the
Expires field from HTTP? (Obviously, in an email message
header, the field would be named X-Expires until
standardised.)
delayed delivery of messages until they are due
This doesn’t match with the semantic of “respond before:
timestamp”. (Perhaps a linguistic issue; I’ve noticed
English-language “by” and “until” are a common cause of confusion
for native speakers of German.) It seems you want a semantic of
“don’t respond until after: timestamp”. I suggest
X-Delay-Until or X-Respond-After for this
purpose.
prioritisation of message display within the user agent to highlight messages which require action.
This seems to be the best fit for the proposed semantic of
“respond before: timestamp”. In light of the above, I’d
rename this to X-Respond-Before, since that allows the
meaning to be clearer.
So, for the purposes you’ve specified, I would suggest the following fields:
X-Respond-Before: *timestamp*X-Respond-After: *timestamp*X-Expires: *timestamp*
—bignose
As I already wrote to Madduck per e-mail (and he added it on the main page), there already is Reply-By field, listed in RFC4021 (which is a list of officially registered mail header fields). There does not seem to be any respond-after, but I’m not sure it makes any sense (as the response will stay around). And an expires field does exist and is called ‘Expires’ (with obsolete vairant ‘Expiry-Date’).
—Jan Hudec
