This looks cool! Some random questions/suggestions from a bystander:
I agree that this is work that should be pursued.
* I would be happier with two separate variables for the RFC 2822
"display name" and the "address". Having both the name and the mail
address would fill up my entire cell phone display. Maybe keep
$from$ as is, and add $from-address$ and $from-name$.
I agree that multiple variables of this sort are a good idea. Additionally,
there probably needs to be some defensive text about not using Sender:,
Resent-From:, and Reply-to: fields here.
Q: Is it intended to exclude legacy address forms by using the term
"display name"? Perhaps no parsing of From: was intended. I.e.:
foo(_at_)bar (foo bar) rather than "foo bar" <foo(_at_)bar>.
More generally, "display name" is RFC 2822 terminology, not RFC 822
terminology. We know from experience that if you leave this unspecified people
will do odd things like use comment suffixes rather than a prefix phrase and
other gross things. I think the way to go at this point is to not try to
support all the legacy stuff.
So the reference needs to be to RFC 2822, not RFC 822, and it needs to be clear
that "display name" is a clearly defined construct there.
* Are $subject$, $text$ etc QP/CTE-decoded?
There's also the whole issue of encoded-words and character sets. I think the
way to go is for this document to be clear that the notification material it
creates is in UTF-8, and that encoded-word and content decoding should be done
as part of these substitution operations.
The text[n] construct is also fairly problematic. For example, what happens
when the cut off falls in the middle of a line terminator? What happen when the
number fall in the middle of a multibyte character?
A line-oriented construct would avoid these issues, however, it wouldn't
necessarily work right with message services that have limited text capacity.
* Security consideration additions:
The risk of creating mail loops must be considered, many instant
messaging systems (e.g. ICQ) have capabilities to forward the
notification by Internet Mail if you're not online. Unless somehow
prevented, this might easily cause huge workload for the servers
involved.
One way to address this would be to allow implementations to ignore
notification requests based on a telltale indicator that the message
is itself a notification.
There's also the issue of denotify support. Plenty of notification
schemes don't have the concept of undoing a notification. So it has
to be clear that it is legal for denotification to be a no-op.
* Is the draft really copyright 1999? :) There are some control
characters (^M) in it as well. Also perhaps update RFC 82{1,2} ->
RFC 282{1,2}.
And add the various documents cited to the bibliography.
Ned