💾 Archived View for gemini.bortzmeyer.org › rfc-mirror › rfc577.txt captured on 2022-01-08 at 20:40:44.
⬅️ Previous capture (2021-11-30)
-=-=-=-=-=-=-
Network Working Group D. Crocker
Request for Comments: 577 UCLA-NMC
NIC: 19356 October 1973
References: RFC 524, 539, 555
Mail Priority
In RFC 539 (NIC--17644,3d:gy) Postel and I suggested that mail
senders be allowed to assign a degree of priority to their mail.
White (RFC 555--17993,6c:gy) objected to defining shades of urgency,
without having their effects upon the Mail Protocol server also
defined.
If priority levels were to be assigned by automata, I would agree
with Jim. Unfortunately, the human sender of the mail will usually
be the one to assign the priority, and humans will not be consistent
in that assignment.
Also unfortunately, the concept of urgency is an integral part of
communication. If it weren't, we could ignore its inclusion into the
MP.
Since distinctions in urgency are useful (necessary?) and since
humans will be the ones assigning specific degrees of urgency
(thereby making it impossible for server processes to automatically
do the "right thing" in response), we suggested only including the
INFORMATION as part of the protocol. Let the human and server-
process receivers decide between themselves how the server-process
should deal with that information.
Now that I have argued all that, let me suggest interpretations for
urgency values. This is so that programmers can have automata-
generated mail (e.g., notification of the status of previously sent
mail) carry reasonable urgency values:
10 Phone in the middle of the night, if necessary.
9
8 Deliver to user's terminal NOW.
7
6 Deliver to user's terminal only if user is at "exec"
level.
5
4 Deliver immediately after sign-on or before sign-off.
3
2 Deliver into standard mailbox.
1
0 Junk Mail
Crocker [Page 1]
RFC 577 Mail Priority October 1973
[ This RFC was put into machine readable form for entry ]
[ into the online RFC archives by Martin Lyngvig 7/99 ]
Crocker [Page 2]