Julian,
The discourse into other services Keith and I engaged in
notwithstanding, I think that, if your draft is going to go
anywhere, it will need at least two things that are not there at
present:
(i) Either
--a requirement that the approach not be used with
authentication of the source and a description of the nature
of or conditions for that authentication (and, in Keith's
model, authorization to present a particular priority). Or
--an analysis of why originator authentication is not needed.
(ii) An analysis of how this would interact with intermediate
MTAs (e.g., the targets of lower-preference MX records that
happened to be picked up as well as any submission MTA used by
the initial (originating) MUA. Or, again, an analysis of why
that isn't a problem. For example, you could try to insist
that the option not be used where intermediate MTAs are present,
but that involves other issues. And, if you assume that
intermediate MTAs might be present, note that their presence may
have some implications for the trust relationships associated
with originator authentication and authorization.
john
--On Tuesday, June 26, 2001 2:12 PM +0100 Julian Onions
<Julian(_dot_)Onions(_at_)nexor(_dot_)co(_dot_)uk> wrote:
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.