Browse Prior Art Database

Thoughts on the mail protocol proposed in RFC 524 (RFC0539)

IP.com Disclosure Number: IPCOM000003649D
Original Publication Date: 1973-Jul-07
Included in the Prior Art Database: 2000-Sep-13
Document File: 3 page(s) / 6K

Publishing Venue

Internet Society Requests For Comment (RFCs)

Related People

D. Crocker: AUTHOR [+2]

Abstract

Generally, we feel that the protocol is extremely rich. We also feel that there are some minor and some major problems.

This text was extracted from a ASCII document.
This is the abbreviated version, containing approximately 47% of the total text.

Network Working Group D. Crocker (UCLA-NMC)

Request For Comment: #539 J. Postel (UCLA-NMC)

NIC 17644 July 9, 1973

References: 524

Thoughts on the Mail Protocol Proposed in RFC 524

Generally, we feel that the protocol is extremely rich. We also feel

that there are some minor and some major problems.

The minor points first:

1. and are not explained until the formal syntax. It

would be more convenient, if they were explained sooner.

2. The Proposed is a bad thing, since it is the Telnet Go-

Ahead, which should not be used by higher level protocols.

3. The default SIGNATURE should be the sign-on or ident of the

author(s).

4. The Disposition INTERRUPT would be more useful if it had

author/clerk-assigned "levels". Currently mail would be either

urgent or not. With levels (say 1 to 10), the sender could rate the

degree of urgency.

There would be no precise defined meaning to any of these

levels, merely the opportunity for a subjective evaluation by

the sender. The receiver (process or person) may do whatever

they wish with the information.

A user could thereby direct a receiving process to notify him

immediately of Priority 5 or higher Short mail or any Priority

10 mail immediately, but defer notification of any other mail.

(Length is discussed later in this note.)

5. Also, we would like the word, "INTERRUPT", to be changed to

URGENT or PRIORITY

6. In keeping with offering the sender the opportunity to 'rate' his

mail, we would like to allow him the chance to warn the receiver of

the size of the mail. This could be a byte count and/or an

imprecise SHORT/MEDIUM/LONG. Again, the receiver may use this

information as he/it sees fit.

7. The ID command seems confusing.

If I am a clerk and sending to someone on another host, that

host may ask me to 'prove' my identity by using an ID. How can

the Sigma-7 at UCLA-NMC know WHITE's id? He does not have one on

the Sigma, but certainly should be able to send mail to us

there.

8. How do ACK's, Progress Reports, or Replies work when there is no

Reference Serial number?

9. Please include the distinction between Static and Dynamic

attributes as part of the formal syntax.

10. Though hosts must be allowed to require a login, before they

will accept mail, would like the Protocol document to reflect a

negative attitude towards such a requirement.

11. In describing defaults,...