Network Working Group                                          C. Newman
Internet Draft: Network Byte Order                              Innosoft
Document: draft-newman-network-byte-order-00.txt           February 1999


                           Network Byte Order


Status of this memo

     This document is an Internet-Draft and is in full conformance with
     all provisions of Section 10 of RFC 2026.

     Internet-Drafts are working documents of the Internet Engineering
     Task Force (IETF), its areas, and its working groups.  Note that
     other groups may also distribute working documents as
     Internet-Drafts.

     Internet-Drafts are draft documents valid for a maximum of six
     months and may be updated, replaced, or obsoleted by other
     documents at any time.  It is inappropriate to use Internet-Drafts
     as reference material or to cite them other than as "work in
     progress."

     The list of current Internet-Drafts can be accessed at
     http://www.ietf.org/ietf/1id-abstracts.txt.

     The list of Internet-Draft Shadow Directories can be accessed at
     http://www.ietf.org/shadow.html.

Abstract

     This memo defines the term "network byte order" and explains why it
     should be used in IETF protocols and media types.

. Terminology Used in this Document

     The key words "SHOULD" and "SHOULD NOT" in this document are to be
     interpreted as described in "Key words for use in RFCs to Indicate
     Requirement Levels" [KEYWORDS].

     A byte is the smallest natural grouping of bits that can be
     directly addressed by hardware.  Modern hardware and network
     protocols use 8-bit bytes, also known as octets.







Newman                    Expires August 1999                   [Page 1]

Internet Draft             Network Byte Order              February 1999


. Definition of Network Byte Order

     When a number is too large to fit in a single byte, multiple bytes
     are used to encode that number.  When such numbers are sent over a
     byte-oriented protocol (e.g., TCP is 8-bit-byte oriented) an order
     for the bytes must be selected so both ends interpret the numbers
     in the same way independent of CPU architecture.  When the bytes
     which make up such multi-byte numbers are ordered from most
     significant byte to least significant byte, that is called "network
     byte order" or "big endian."

     For example, take the unsigned hexidecimal number 0xFEEDFACE
     (decimal 4,277,009,102).  If this is sent as a sequence of 8-bit
     bytes using network byte order (big endian), the sequence would be:
     0xFE, 0xED, 0xFA, 0xCE.  In little endian (least significant byte
     to most significant byte), this would be: 0xCE, 0xFA, 0xED, 0xFE.

. Byte Order Recommendations

     The following byte ordering options have been used in protocols or
     media types in the past:

     (1) Network byte order only.

     (2) Little endian only.

     (3) Run-time selection between (1) or (2)

     The arguments for (3) are that it allows the machine to send/write
     multi-byte numbers without an encoding step, and in a homogenous
     environment no time need be spent doing byte reversal.  In practice
     (3) has often been a failure.  It adds a negotiation step and
     creates two variants of the same protocol or media type which have
     to be tested independently (and often aren't, so things break).

     A well-known case of (3) is the TIFF media type [TIFF].  Versions
     of TIFF software were released which only handled one of the two
     byte orders.  Because of this, most modern TIFF software gives the
     user a choice between the two TIFF variants and calls them "Mac
     format" (big endian) and "PC format" (little endian) in an attempt
     to make the problem partially comprehensible.  In this case, (3)
     resulted in interoperability problems, extra user interface
     development work and user confusion.  Even the risk of such serious
     consequences outweighs the minor benefits used to promote (3),
     therefore run-time byte-order selection SHOULD NOT be used.

     The choice between (1) and (2) is arbitrary given that the cost of
     byte reversal on modern processors is negligible.  However, IETF



Newman                    Expires August 1999                   [Page 2]

Internet Draft             Network Byte Order              February 1999


     protocols and media types SHOULD use network byte order both for
     consistancy with existing IETF work, and also to take advantage of
     the network-byte-order macros (ntohl, htonl, ntohs, htons) present
     in the majority of TCP libraries.

. Security Considerations

     Security sensitive code which allowed selectable byte order would
     have two code paths to verify for correctness rather than one.
     Otherwise byte-order has no impact on security.

. Multinational Considerations

     Some coded character sets [CHAR-POLICY] have more codepoints than
     would fit in a byte.  When a multi-byte character encoding scheme
     is used, the byte order issues in this memo apply to that encoding.
     An octet-based character encoding scheme such as UTF-8 [UTF-8] can
     avoid the issue.

. References

     [CHAR-POLICY] Alvestrand, H., "IETF Policy on Character Sets and
     Languages", RFC 2277, UNINETT, January 1998.

     [TIFF] Parsons, G., Rafferty, J., Zilles, S., "Tag Image File
     Format (TIFF) - image/tiff MIME Sub-type Registration", RFC 2302,
     Northern Telecom, March 1998.

     [KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate
     Requirement Levels", RFC 2119, Harvard University, March 1997.

     [UTF-8] Yergeau, F. "UTF-8, a transformation format of ISO 10646",
     RFC 2279, Alis Technologies, January 1998.

. Author's Address

     Chris Newman
     Innosoft International, Inc.
     1050 Lakes Drive
     West Covina, CA 91790 USA

     Email: chris.newman@innosoft.com









Newman                    Expires August 1999                   [Page 3]