E.1 GENERAL. 497E.1.1 Scope. 497E.1.2 Applicability. 497E.2 APPLICABLE DOCUMENTS. 497E.2.1 General. 497E.2.2 Government documents. 497E.2.2.1 Specifications, standards, and handbooks. 497E.2.2.2 Other Government documents, drawings, and publications. 498E.2.3 Non-Government publications. 498E.2.4 Order of precedence. 498E.3 DEFINITIONS. 498E.3.1 Standard definitions and acronyms. 498E.3.2 Abbreviations and acronyms. 498E.4 GENERAL REQUIREMENTS 499E.4.1 Introduction. 499E.4.1.1 Required HF subnetwork protocols. 500E.4.1.2 Support for Internet applications. 500E.4.1.3 Security. 501E.4.2 Electronic mail transfer. 502E.4.2.1 Mail transfer within HF networks. 502E.4.2.2 Mail retrieval by call-in users. 502E.4.3 Digital imagery transfer. (not yet standardized) 502E.4.4 Digital voice operation. (not yet standardized) 502E.4.5 Other applications. 502E.5 DETAILED REQUIREMENTS. 502E.5.1 Introduction. 502E.5.2 Electronic mail protocols. 503E.5.2.1 HF mail transfer protocol. 503E.184.108.40.206 HMTP command grouping. 503E.220.127.116.11 HMTP over TCP. 503E.18.104.22.168 HMTP without TCP. 503E.5.2.2 HF mail retrieval protocols. 503E.5.3 Digital imagery protocol. 503E.5.4 Digital voice protocol. 504E.5.5 Radio facsimile protocol. 504E.6 NOTES. 504
FIGURE E-1. HF application interoperation. 499FIGURE E-2. Application interoperation via internet gateway. 500FIGURE E-3. Application-layer mail gateway. 501
This appendix contains the requirements for the prescribed protocols
and directions for the implementation and use of various communications
applications in HF radio networks.
Applications provide advanced technical capabilities of automated
HF radio. None of the features and functions described in this
appendix are mandatory requirements for the user in the acquisition
of an HF radio system. However, if the user requires the features
and functions described herein, they shall be provided in accordance
with the technical parameters specified in this appendix.
The documents listed in this section are specified in sections
E.3, E.4, and E.5 of this standard. This section does not include
documents cited in other sections of this standard or recommended
for additional information or as examples. While every effort
has been made to ensure the completeness of this list, document
users are cautioned that they must meet all specified requirements
documents cited in sections E.3, E.4, and E.5 of this standard,
whether or not they are listed.
The following specifications, standards, and handbooks form a
part of this document to the extent specified herein. Unless
otherwise specified, the issues of these documents are those listed
in the issue of the Department of Defense Index of Specifications
and Standards (DoDISS) and supplement thereto, cited in the solicitation.
|FED-STD-1037||Telecommunications: Glossary of Telecommunication Terms|
Unless otherwise indicated, copies of federal and military specifications,
standards, and handbooks are available from the Naval Publications
and Forms Center, ATTN: NPODS, 5801 Tabor Avenue, Philadelphia,
The following other Government documents, drawings, and publications form a part of this document to the extent specified herein. Unless otherwise specified, the issues are those cited in the solicitation.
The following documents form a part of this document to the extent
specified herein. Unless otherwise specified, the issues of the
documents which are DoD adopted are those listed in the issues
of the DODISS cited in the solicitation. Unless otherwise specified,
the issues of the documents not listed in the DODISS are the issues
of the documents cited in the solicitation (see 6.3).
|RFC-854||Telnet Protocol specification|
|RFC-821||Simple Mail Transfer Protocol|
|RFC-959||File Transfer Protocol|
|RFC-1651||SMTP Service Extensions|
|RFC-1730||Internet Message Access Protocol - Version 4|
|RFC-1854||SMTP Service Extensions for Command Pipelining|
|RFC-1939||Post Office Protocol - Version 3|
|RFC-2068||Hypertext Transfer Protocol - HTTP/1.1|
(Internet documents may be obtained by anonymous file transfer
protocol (ftp) from nis.nsf.net or nic.ddn.mil.)
In the event of a conflict between the text of this document and
the references cited herein, the text of this document takes precedence.
Nothing in this document, however, supersedes applicable laws
and regulations unless a specific exemption has been obtained.
The abbreviations and acronyms used in this document are defined
below. Those listed in the current edition of FED-STD-1037 have
been included for the convenience of the reader.
|ALE||automatic link establishment|
|ALM||automatic link maintenance|
|ARQ||automatic repeat request|
|FTP||file transfer protocol|
|HMTP||HF mail transport protocol|
|HTTP||hypertext transfer protocol|
|IMAP4||Internet Mail Access Protocol - version 4|
|NSAP||network service access point|
|PDU||protocol data unit|
|POP3||Post Office Protocol - version 3|
|SMTP||simple mail transfer protocol|
|TCP||transmission control protocol|
|UDP||user datagram protocol|
Figure E-1 illustrates the relationship of application-layer protocols
to the protocols defined elsewhere in this standard. Interoperation
among applications in use at different stations requires that
the applications and all supporting protocols at the stations
interoperate. Performance will then be determined by how well
the protocol stacks work with each other and with the HF medium.
To simplify the task of ensuring interoperability among applications using the HF medium, a small number of protocols is approved for use with the application protocols specified in this appendix. Systems that implement any application from this appendix shall use the following protocols to convey the corresponding application protocol data units (PDUs) over the HF medium:
When an HF subnetwork is connected to other subnetworks using
the Internet Protocol (IP) suite, Internet applications can use
the resulting Internet as illustrated in figure E-2. For Internet
applications, the third-generation link-layer suite (shown in
figure E-2) will generally provide higher performance than the
When a host computer is connected to the Internet via an HF network
(e.g., HF Host in
figure E-2), most Internet applications will call upon the Transmission Control Protocol (TCP) or the User Datagram Protocol (UDP) for end-to-end transport service to the distant Internet Host. These two protocols, in turn, require the services of IP for routing packets through the Internet. HF network designers should be aware of several potential performance problems that arise when TCP and IP are used in an HF network:
a. The two protocols together add 40 bytes of overhead to each application PDU sent.
b. TCP connection setup requires an additional three-way handshake after the link establishment handshake and data link protocol startup. Each link turnaround consumes at least three interleaver times; when the MIL-STD-188-110 serial-tone modem is using its 4.8 s interleaver, this three-way handshake will add at least 43 s to the time to establish a link (at least 58 s if the data rate is 75 bps).
c. The TCP congestion avoidance mechanisms can significantly
reduce throughput each time the HF data link throughput changes
For electronic mail (e-mail) transport through HF networks, an application-layer mail gateway can be employed at the boundary of the HF network that will eliminate the need for TCP within the HF network (see figure E-3). However, interactive applications (e.g., remote terminals, file
transfer, and web browsing) will generally require the use of
Figures E-1, E-2, and E-3 show optional encryption of application
data. If Communications Security (COMSEC) is implemented in this
way, the control information conveyed to lower layers shall bypass
encryption using an approved method. Link layer encryption may
also be used. Further COMSEC considerations are beyond the scope
of this appendix.
An HF e-mail system will be found to comply with this appendix
if it conveys e-mail through HF networks using the required HF
subnetwork protocols (see Required HF subnetwork protocols above)
and the HF Mail Transfer Protocol (HMTP) described in E.5.2.1
(HF Mail Transfer Protocol).
Mail shall be transferred within HF networks using HMTP, except
as provided in the next paragraph. Wherever possible, application-layer
mail gateways (see figure E-3) shall be employed to translate
between SMTP and HMTP at the boundaries of the HF subnetwork,
so that TCP is not used to convey mail over HF links.
When connectivity to a user is too infrequent to use HMTP to push
messages to that user's host computer, a mail drop should be created
at a host that can usually be reached by that user over a single
HF link. One of the mail retrieval protocols from E.5.2.2 (HF
mail retrieval protocols) shall be used to pull mail from the
mail drop host to the user's host.
Interactive applications such as file transfer and hypertext transfer
(in support of the worldwide web) shall employ the usual Internet
application protocols for those applications:
|File transfer||File Transfer Protocol (FTP)||RFC-959|
|Hypertext transfer||Hypertext Transfer Protocol (HTTP)||RFC-2068|
TCP shall be implemented at the client and server hosts that support
these applications. IP and related protocols shall be implemented
at client and server hosts and at subnetwork gateways (often termed
"routers") that interconnect HF subnetworks with other
figure E-2). Neither TCP nor IP is needed at other HF nodes.
The functions supported by the protocols specified in this section
are optional. However, when the functionality provided by one
of these protocols is required, that protocol shall be implemented
as specified to provide that functionality.
The HMTP shall be used to "push" email messages
through HF networks from one mail server to the next. The Post
Office Protocol version 3 (POP3) or the Internet Mail Access Protocol
version 4 (IMAP4) shall be used within HF networks to retrieve
("pull") email messages from servers.
The HF Mail Transfer Protocol (HMTP) is an extended version of
the Simple Mail Transfer Protocol (SMTP). HMTP clients and servers
shall implement SMTP in accordance with RFC 821, the SMTP service
extension ("EHLO") protocol in accordance with RFC 1651,
and command pipelining in accordance with RFC 1854.
When connected to a server that supports command pipelining, HMTP clients shall group commands to the maximum extent permitted in RFC 1854:
a. All setup commands, including RSET (if required), MAIL, RCPT, and DATA, for each message shall be sent as a single group.
b. Multiple messages sent to a single server
shall be chained by appending the setup commands for each subsequent
message to the message body of the preceding message.
When connected to a server that does not support command pipelining,
HMTP clients shall execute SMTP in its basic interlocked mode
in accordance with RFC 821.
When HMTP uses TCP transport services, it shall listen on TCP
port 25 (the well-known SMTP port), and, in general, use TCP in
the same manner as does SMTP.
When TCP is not used to transport HMTP data, the HMTP server shall
listen for calls on network service access point (NSAP) 8 of the
HF subnetwork service.
When a user is usually not reachable (i.e., the user connects
sporadically to pick up email), HMTP will not be appropriate
for delivery of mail to that user. In such cases, POP3
in accordance with RFC 1939 or IMAP4 in accordance with RFC 1730
shall be used to retrieve mail from a mail drop server (see E.4.2.2).
Messages sent by such users shall be conveyed to the server
(not yet standardized)
(not yet standardized)
(not yet standardized)