|
RFC Home |
Full RFC Index |
Recent RFCs |
RFC Standards |
Best Current Practice |
RFC Errata |
1 April RFC |
|
||||||
|
IETF RFC 577
Mail Priority Last modified on Thursday, January 7th, 2010 Permanent link to RFC 577 Search GitHub Wiki for RFC 577 Show other RFCs mentioning RFC 577 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 |