idnits 2.17.1 draft-newman-network-byte-order-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. Miscellaneous warnings: ---------------------------------------------------------------------------- == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (February 1999) is 9201 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Possible downref: Non-RFC (?) normative reference: ref. 'IEN-137' ** Obsolete normative reference: RFC 2302 (ref. 'TIFF') (Obsoleted by RFC 3302) ** Obsolete normative reference: RFC 2279 (ref. 'UTF-8') (Obsoleted by RFC 3629) Summary: 6 errors (**), 0 flaws (~~), 2 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group C. Newman 3 Internet Draft: Network Byte Order Innosoft 4 Document: draft-newman-network-byte-order-01.txt February 1999 6 Network Byte Order 8 Status of this memo 10 This document is an Internet-Draft and is in full conformance with 11 all provisions of Section 10 of RFC 2026. 13 Internet-Drafts are working documents of the Internet Engineering 14 Task Force (IETF), its areas, and its working groups. Note that 15 other groups may also distribute working documents as 16 Internet-Drafts. 18 Internet-Drafts are draft documents valid for a maximum of six 19 months and may be updated, replaced, or obsoleted by other 20 documents at any time. It is inappropriate to use Internet-Drafts 21 as reference material or to cite them other than as "work in 22 progress." 24 The list of current Internet-Drafts can be accessed at 25 http://www.ietf.org/ietf/1id-abstracts.txt. 27 The list of Internet-Draft Shadow Directories can be accessed at 28 http://www.ietf.org/shadow.html. 30 Abstract 32 This memo defines the term "network byte order" and explains why it 33 should be used in IETF protocols and media types. 35 1. Terminology Used in this Document 37 The key words "SHOULD" and "SHOULD NOT" in this document are to be 38 interpreted as described in "Key words for use in RFCs to Indicate 39 Requirement Levels" [KEYWORDS]. 41 A byte is the smallest natural grouping of bits that can be 42 directly addressed by hardware. Modern hardware and network 43 protocols use 8-bit bytes, also known as octets. 45 1.1. Background and Motivation 47 The document "ON HOLY WARS AND A PLEA FOR PEACE" [IEN-137] written 48 in 1980 argues that the industry should settle on a single byte 49 order. Since then, the IETF has largely settled on a single byte 50 order known as "Network Byte Order" and this memo is intended to 51 record that rough concensus. Unfortunately, the "holy war" 52 continues among CPU manufacturers. 54 2. Definition of Network Byte Order 56 When a number is too large to fit in a single byte, multiple bytes 57 are used to encode that number. When such numbers are sent over a 58 byte-oriented protocol (e.g., TCP is 8-bit-byte oriented) an order 59 for the bytes must be selected so both ends interpret the numbers 60 in the same way independent of CPU architecture. When the bytes 61 which make up such multi-byte numbers are ordered from most 62 significant byte to least significant byte, that is called "network 63 byte order" or "big endian." 65 For example, take the unsigned hexidecimal number 0xFEEDFACE 66 (decimal 4,277,009,102). If this is sent as a sequence of 8-bit 67 bytes using network byte order (big endian), the sequence would be: 68 0xFE, 0xED, 0xFA, 0xCE. In little endian (least significant byte 69 to most significant byte), this would be: 0xCE, 0xFA, 0xED, 0xFE. 71 3. Byte Order Recommendations 73 The following byte ordering options have been used in protocols or 74 media types in the past: 76 (1) Network byte order only. 78 (2) Little endian only. 80 (3) Run-time selection between (1) or (2) 82 In practice, run-time selection has often been a failure. It adds 83 a negotiation step and creates two variants of the same protocol or 84 media type which have to be tested independently (and often aren't, 85 so things break). 87 A well-known case of (3) is the TIFF media type [TIFF]. Versions 88 of TIFF software were released which only handled one of the two 89 byte orders. Because of this, most modern TIFF software gives the 90 user a choice between the two TIFF variants and calls them "Mac 91 format" (big endian) and "PC format" (little endian) in an attempt 92 to make the problem partially comprehensible. In this case, (3) 93 resulted in interoperability problems, extra user interface 94 development work and user confusion. Even the risk of such serious 95 consequences outweighs the minor benefits used to promote (3), 96 therefore run-time byte-order selection SHOULD NOT be used. 98 The choice between (1) and (2) is arbitrary given that the cost of 99 byte reversal on modern processors is normally negligible. 100 However, IETF protocols and media types SHOULD use network byte 101 order both for consistancy with existing IETF work, and also to 102 take advantage of the network-byte-order macros (ntohl, htonl, 103 ntohs, htons) present in the majority of TCP libraries. 105 3.1. Example Exception to Recommendations 107 In certain exceptional circumstances (usually involving high speed 108 networks and/or low speed processors), the cost of byte reversal 109 when sharing data between two little-endian machines may outweigh 110 the cost of developing, testing and maintaining the two codepaths 111 necessary for run-time selection of byte order. 113 3.2. Network Bit Order 115 For certain low-level protocols or compression-oriented media 116 types, bit-order may be an issue. When possible, big-endian is 117 encouraged for consistancy with Network Byte Order. 119 4. Security Considerations 121 Security sensitive code which allowed selectable byte order would 122 have two code paths to verify for correctness rather than one. 123 Otherwise byte order has no impact on security. 125 5. Multinational Considerations 127 Some coded character sets [CHAR-POLICY] have more codepoints than 128 would fit in a byte. When a multi-byte character encoding scheme 129 is used, the byte order issues in this memo apply to that encoding. 130 An octet-based character encoding scheme such as UTF-8 [UTF-8] can 131 avoid the issue. 133 6. References 135 [CHAR-POLICY] Alvestrand, H., "IETF Policy on Character Sets and 136 Languages", RFC 2277, UNINETT, January 1998. 138 [IEN-137] Cohen, D., "ON HOLY WARS AND A PLEA FOR PEACE", IEN 137, 139 USC/ISI, April 1980. 141 [TIFF] Parsons, G., Rafferty, J., Zilles, S., "Tag Image File 142 Format (TIFF) - image/tiff MIME Sub-type Registration", RFC 2302, 143 Northern Telecom, March 1998. 145 [KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate 146 Requirement Levels", RFC 2119, Harvard University, March 1997. 148 [UTF-8] Yergeau, F. "UTF-8, a transformation format of ISO 10646", 149 RFC 2279, Alis Technologies, January 1998. 151 7. Author's Address 153 Chris Newman 154 Innosoft International, Inc. 155 1050 Lakes Drive 156 West Covina, CA 91790 USA 158 Email: chris.newman@innosoft.com