Re: [Ieprep] Discussion of Internet-Draft for SMTP priorities

Janet P Gunn <> Mon, 12 June 2006 18:07 UTC

Received: from [] ( by with esmtp (Exim 4.43) id 1Fpqp2-0008AC-5T; Mon, 12 Jun 2006 14:07:32 -0400
Received: from [] ( by with esmtp (Exim 4.43) id 1Fpqp0-00089w-IE for; Mon, 12 Jun 2006 14:07:30 -0400
Received: from ([]) by with esmtp (Exim 4.43) id 1Fpqoz-0002Wg-93 for; Mon, 12 Jun 2006 14:07:30 -0400
Received: from ( []) by (Switch-3.1.6/Switch-3.1.7) with ESMTP id k5CI7ODx019789; Mon, 12 Jun 2006 14:07:25 -0400 (EDT)
In-Reply-To: <>
Subject: Re: [Ieprep] Discussion of Internet-Draft for SMTP priorities
To: Michael Schmeing <>
X-Mailer: Lotus Notes 652HF83 November 04, 2004
Message-ID: <>
From: Janet P Gunn <>
Date: Mon, 12 Jun 2006 14:07:22 -0400
X-MIMETrack: Serialize by Router on AMER-GW09/SRV/CSC(Release 6.5.3|September 14, 2004) at 06/12/2006 02:06:26 PM
MIME-Version: 1.0
X-Spam-Score: 0.8 (/)
X-Scan-Signature: f4c2cf0bccc868e4cc88dace71fb3f44
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Internet Emergency Preparedness Working Group <>
List-Unsubscribe: <>, <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
Content-Type: multipart/mixed; boundary="===============0725518012=="

I have a bunch of detailed comments, which I am still working on, but I
also have some high level questions/comments, which I will include here.

This ID clearly addresses a set of email requirements (not fully documented
here) tied to the US DoD.

While they haven't been set down yet, it is anticipated that there will be
a set of priority requirements for NS/EP (National Security and Emergency
Preparedness) email, which are likely to be somewhat different from the
military requirements.  And I expect there will be other requirements from
other parts of the world.

It would be nice if we had a more general solution, which could encompass a
variety of related but distinct requirements.

The SIP RPH (RFC4412) (on which the IEPREP WG had significant input) has a
more general structure which allows it to encompass both the (pre-emption
based) MLPP functionality and the (queuing based)GETS/WPS/ETS
functionality, by the use of (IANA registered) namespaces.

Is there a reason why we couldn't do something analogous for email?

Some of the specific areas where there might be  different requirements:

This draft focuses on “rapid delivery”  or “order of delivery” rather than
“high probability of delivery”.  In fact, it stipulates that, for some
priority levels, if the email cannot be delivered “with priority”, it
should be rejected (see section 6.5.7).  I can think of many situations
where it is better to continue with non-priority delivery than to reject an

There might be circumstances in which "preemption" of  current email
transmissions is not desired, but "moving high priority emails to the front
of the queue" IS desirable.  It would be nice if the mechanism could
support both approaches.

I understand the rationale for limiting the size of the high priority
emails, but I can think of situations where other mechanisms might be a
more appropriate way to make sure that  the overall "high priority" volume
remains low.

Current implementations of  MLPP, eMLPP, WPS, and RPH use 0 to represent
the high priority group, with, etc representing successively lower
priorities.  What is the rationale for turning this upside down and using 0
to represent "non-priority"?

Why would the fact that a message is unclassified imply that it is lower
priority?  I don't see the correlation.




This is a PRIVATE message. If you are not the intended recipient, please
delete without copying and kindly advise us by e-mail of the mistake in
delivery. NOTE: Regardless of content, this e-mail shall not operate to
bind CSC to any order or other contract unless pursuant to explicit written
agreement or government initiative expressly permitting the use of e-mail
for such purpose.
Ieprep mailing list