I think the problem here is the characterization of this proposal
as an end-to-end QoS-assurance mechanism rather than just a way
that trusted and authenticated parties can request priority
handling of important messages through those parts of the mail
system that trust their credentials and are willing to do that.
Nicely put. I agree. However, let's remember that it is this discussion that
has characterized the draft in this way, not the draft itself.
And let's also remember that there are all sorts of ways to skin the
authorization cat and authentication is but one means to that end. We have
ample experience authorizing relay in a variety of ways, including hacks like
so-called POP-before-SMTP (shudder). There's no reason to expect that similar
tricks, or possibly very different tricks, could be used with priority.
If we're trying to do the end-to-end QoS, I have huge doubts about
our being able to make that happen. We'd not only have to
rigidly define the various levels of service, we'd also have to
solve the general cross-realm trust problem. (And then we'd have
to get people to deploy something that they probably couldn't
understand how to use.)
In general you may well be right. But it may be possible to build services with
enhanced capabilities that operate on a subset of our infrastructure using
these tools as a starting point.
OTOH, If we're just trying to design a standard interface to a
general-purpose mechanism for requesting priority handling
among mutually consenting parties, that's much easier, and IMHO