requirement
Click on the red underlined text to get to the source
... EMSD Requirements and Goals ...
...
The requirements and goals driving design of EMSD protocol are
enumerated below.
...
... options, so the solution cannot require every feature to be a
part of every message. Likewise, usage will emerge that is not
currently recognized as a requirement. The solution must be
extendible enough to handle new, emerging requirements.
...
... currently recognized as a requirement. The solution must be
extendible enough to handle new, emerging requirements.
11. Secure: provide the same level of security ...
... and should converge based on a set of open protocols that
address the efficiency requirements adequately;
o that existing Internet email ...
... delivery protocols which address
requirements specific to a particular user's environment are likely
to be developed. Such diversity on the edges of the network ...
... segments.
There is no requirement that any message-segment content be of
maximum length allowed by ESROS for connectionless transmission;
...
...
The convention of (O) "OPTIONAL", (D) "DEFAULT", (C) "CONDITIONAL"
and (M) "MANDATORY" which express requirements for presence of
information is used in this section.
...
... ESRO) involves 3 transmissions (in typical cases).
The key requirement driving the design of EMSD is efficiency. It was
determined that the at least 3 fold gains in efficiency justifies the
deviation from the SMTP ...
... 5 transmissions as it is the case with QMTP.
The key requirement driving the design of EMSD is Efficiency. It was
determined that elimination of the extra 2 transmissions that are an
inherent characteristic of TCP ...
... Bradner, S., "Key words for use in RFCs to indicate requirement levels", BCP 14, RFC 2119, March 1997. ...