I don't think the current draft is all that is required to implement
all services that you might be interested in. What I think we have
though is a new tool. There is no method for indicating priority in the
smtp envelope, or a means of adjusting it (other that rewriting header
fields - yuck).
So this mechanism gives the transfer capability.
Given that, you can build on it. For instance the military STANAG
4406/ACP-123 precedence fields should be mapped to a priority value,
but we didn't think that was appropriate for this draft. It can be
specified in another document how those values should be mapped to the
SMTP extension, and they can those mappings can then be controlled by the
bodies intersted in those mappings.
Whilst a message might start out as high priority, it may get
downgraded on its path (list expansion being one case) or upgraded
maybe (reaching its latest delivery time). I'd rather not specify those
mechanisms here, they can be built up in other documents.
Similarly, you might well come up with authenticated senarios for real
life deployment at ISPs or major switching hubs, they can also use this
basic mechanism.
If we have the tool available, we can build solutions around it, hence
the draft tries to stay as simple and focused as possible.
For us it gives us the tools to solve some military senarios whilst being
generic enough to provide other solutions (or at least thats the goal).
Julian.