Re: [apps-discuss] Review of draft-melnikov-smtp-priority-14

John C Klensin <john-ietf@jck.com> Tue, 05 June 2012 10:07 UTC

Return-Path: <john-ietf@jck.com>
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 248F221F868A; Tue, 5 Jun 2012 03:07:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.502
X-Spam-Level:
X-Spam-Status: No, score=-102.502 tagged_above=-999 required=5 tests=[AWL=0.097, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nbp8EAgHvxik; Tue, 5 Jun 2012 03:07:37 -0700 (PDT)
Received: from bsa2.jck.com (bsa2.jck.com [70.88.254.51]) by ietfa.amsl.com (Postfix) with ESMTP id 133DB21F867E; Tue, 5 Jun 2012 03:07:37 -0700 (PDT)
Received: from [198.252.137.7] (helo=PST.JCK.COM) by bsa2.jck.com with esmtp (Exim 4.71 (FreeBSD)) (envelope-from <john-ietf@jck.com>) id 1SbqZa-0002Ou-HI; Tue, 05 Jun 2012 06:01:10 -0400
Date: Tue, 05 Jun 2012 06:07:15 -0400
From: John C Klensin <john-ietf@jck.com>
To: ken carlberg <carlberg@g11.org.uk>
Message-ID: <1E3DCEC5990AF898F1E3582D@PST.JCK.COM>
In-Reply-To: <E503581B-E89A-4E09-B06C-CF18263F7376@g11.org.uk>
References: <6.2.5.6.2.20120521130747.0c219ab0@elandnews.com> <4FBDF199.2050300@isode.com> <4FC722A2.2050905@dcrocker.net> <4FC89931.5060201@isode.com> <4FC914DB.4000806@dcrocker.net> <4FCA6BFE.3050609@isode.com> <4FCD175D.30307@dcrocker.net> <01OGAJ8GBR2Q0006TF@mauve.mrochek.com> <F6882C013F7272CED4D345A9@PST.JCK.COM> <E503581B-E89A-4E09-B06C-CF18263F7376@g11.org.uk>
X-Mailer: Mulberry/4.0.8 (Win32)
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
Cc: Ned Freed <ned.freed@mrochek.com>, apps-discuss@ietf.org, draft-melnikov-smtp-priority.all@tools.ietf.org, iesg@ietf.org
Subject: Re: [apps-discuss] Review of draft-melnikov-smtp-priority-14
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: General discussion of application-layer protocols <apps-discuss.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/apps-discuss>
List-Post: <mailto:apps-discuss@ietf.org>
List-Help: <mailto:apps-discuss-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 05 Jun 2012 10:07:38 -0000

--On Monday, June 04, 2012 20:18 -0400 ken carlberg
<carlberg@g11.org.uk> wrote:

> 
> On Jun 4, 2012, at 7:14 PM, John C Klensin wrote:
> 
>> Yes in principle.  In practice, I've seen one set of
>> communities that have repeatedly expressed high levels of
>> demand for prioritization.  Those communities are military or
>> ones with aspirations to behave like military ones.  For those
>> communities, "messages from the General get more delivery
>> priority than those from the Lieutenant" have obvious meaning
>...
> so what you describe above is what I've called role-based
> prioritization.  its the easiest form of prioritization to
> implement and deploy because its typically associated with a
> role (sargent, general, etc.) and its generally stagnant and
> stays associated with a user or device.  several systems for
> both voice and messaging have been built over the past 50
> years or so using this form of prioritization.

Yes, but it is a little more than that.  Referring back to a
recent conversation about authentication, I note that most
military organizations have a very negative view about corporals
impersonating generals... and the means to deliver unambiguous
negative reinforcement to support that view.  Impersonating your
boss in a civilian company might get you fired, but would be
unlikely to get you shot (I can think of an exception or two,
but let's not go there).   While that isn't authentication in
the sense that we normally use the term, it can be a reasonable
surrogate for many purposes.  If this were just "role-based",
one would need to reopen the authentication and authorization
issues and to do so for inter-organizational mail.   I won't say
"impossible", but one could spend a rather long time exploring
that family of rat holes.
 
> another type of system (that I worked on about 25 years ago)
> is what I refer to as content-based prioritization, where the
> prioritization is attributed to the content of the message.
> So in this case, one could have a case where the user (or a
> proxy) decides and associates a priority based on the
> information in the message to be sent.  So in this case, you
> could have a case where the lowly Sargent trumps the General
> (kind a cool :-).  And by far, this is the hardest system to
> build/deploy because one needs to avoid the trap that Dave
> brought up earlier in that given the freedom, everyone wants
> to have the highest priority.

Sorry, the Sargent never trumps the General.  He may be sending
a message on behalf of a body that can, with that body's
authorization, or may, more generally, have authorizations the
General does not, but...

See Ned's comment, with which my experience agrees.  Also think
about whether you can make an anecdotal inference about message
and topic priority from this thread of messages.  It shows that
neither of us want to, and are assigning, "highest priority" to
handling this thread, sitting anxiously in front of our screens
waiting for the next message to arrive so it can be answered
instantly.  Now that it prioritization in the human part of the
process --message reading priority, message answering priority,
and message dispatching priority-- not in the transport part.
But the recipient generally doesn't care about the
human-versus-transport distinction.  The distinction clearly
makes no difference to the total or delivery times of a
communications round trip, etc.  I suggest that is a practical
counterexample to assertions that everyone always wants highest
priority.

Indeed, while (as far as I know) it has never been proposed as
an Internet mail extension, partially because it is best
implemented in the sending MUA or between it and the sending
Submission Server, experiments run many years ago made a
convincing case for a "sit on this message for an hour or two
before sending it out just in case I change my mind" service.
That, again, would be just the opposite from "I want highest
priority and for my message to be delivered immediately or
sooner".


> In the past few years, some communities have had to rely on
> the prioritization made available in X.400.  However, these
> and other communities wish to migrate to SMTP, hence the
> interest in produce the draft-melnikov-smtp-priority draft.
> So what i wanted to point out is that people have indeed
> worked on these systems and gained experience in the subject
> area, and we'd like to migrate this to SMTP, as opposed to
> just relying on proprietary hacks.

I'm tempted to say that, if you want the X.400 service model,
you should be looking to improve on MIXER, not SMTP.  I might
also note that that the round trip (message out, reply, message
back) time of many X.400 transactions in progress was such that
prioritization.  In practice, X.400 also needed it -- what was
it that Einar Steffrud used to say about X.400 delivery in a
millisecond world?  Days?  But, more important, there is an
authentication and authorization infrastructure built into the
X.400 model with bilateral trust agreements between management
(and hence transmission-authorizing) entities and each such
entity required to take responsibility for authentication and
authorization of anyone initiating mail.  Whether one trusts the
results of that model or not is another issue but the structure
is there.  Attempts to retrofit that structure onto Internet
mail without extensive hand waving have been rather
unsuccessful.  And that is ultimately one of the key problems
with trying to use this particular proposal between unrelated
administrative domains.

   john