idnits 2.17.1 draft-odell-srfp-00.txt: ** The Abstract section seems to be numbered Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Cannot find the required boilerplate sections (Copyright, IPR, etc.) in this document. Expected boilerplate is as follows today (2024-04-27) according to https://trustee.ietf.org/license-info : IETF Trust Legal Provisions of 28-dec-2009, Section 6.a: This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 2: Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 3: This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. 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. ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. == 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 a Security Considerations section. ** 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.) Miscellaneous warnings: ---------------------------------------------------------------------------- -- 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 (October 1996) is 10056 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) No issues found here. Summary: 9 errors (**), 0 flaws (~~), 1 warning (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group Mike O'Dell 3 Internet-Draft UUNET Technologies 4 October 1996 6 The Simple Record Framing Protocol 8 10 1. Status of this Memo 12 This document is an Internet-Draft. Internet-Drafts are working 13 documents of the Internet Engineering Task Force (IETF), its areas, 14 and its working groups. Note that other groups may also distribute 15 working documents as Internet-Drafts. 17 Internet-Drafts are draft documents valid for a maximum of six months 18 and may be updated, replaced, or obsoleted by other documents at any 19 time. It is inappropriate to use Internet-Drafts as reference 20 material or to cite them other than as ``work in progress.'' 22 To learn the current status of any Internet-Draft, please check the 23 1id-abstracts.txt listing contained in the Internet-Drafts Shadow 24 Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe), 25 munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or 26 ftp.isi.edu (US West Coast). 28 2. Abstract 30 The Simple Record Framing Protocol (SRFP) is designed to provide a 31 common, light-weight protocol for sending record-structured data of 32 possibly indeterminate size over a reliable (TCP) connection. It is 33 designed to be a "nickel's worth of presentation layer" which can be 34 incorporated into a simple library to prevent reinvention of wheels. 36 3. Introduction 38 The Simple Record Framing Protocol is intended to fill a void in the 39 current Internet architecture - the need for a common, light-weight 40 protocol for sending record-structured data on a single reliable 41 connection such as that provided by TCP. 43 To be sure, other schemes for exchanging record-oriented data are 44 used presently used in the Internet. For example, FTP has a record 45 mode, SNMP uses ASN.1, NFS uses XDR, and any number of private 46 protocols have been invented for applications requiring this service. 48 The goal of SFRP is to provide a common, interoperable record framing 49 protocol which is flexible enough to solve a useful set of common 50 problems (but certainly not all of them) while remaining simple and 51 light-weight enough that alternatives will be developed only in the 52 face of genuine functional need. 54 As a wise man once said, "It is sometimes more important to know what 55 you are not than it is to know what you are." The requirements for 56 SRFP bear this in mind. 58 4. Overview 60 The job of SRFP is to frame the transfer of records over a reliable 61 connection such as that provided by TCP. It is *not* intended to 62 describe those records in any manner other than their length. It 63 especially does not describe the structure of the records, nor does 64 it arrange for any kind of representation conversion. To this end, 65 SRFP has no negotiation mechanism. Any agreements about non-default 66 sizes or limits needed by the application must be made by the 67 application before initiating SRFP on the channel. 69 When SRFP is running on a channel, the data stream consists of 70 segments, each of which is a block of payload data described by a 4- 71 byte header. The SRFP header marks the beginning of a segment and 72 carries the size of the payload block in bytes so that the header of 73 the next segment may be located. 75 When the record size is equal to or less-than the maximum operating 76 payload block size, a record goes in one segment. If the record 77 exceeds the maximum payload block size, especially if the application 78 needs to demark boundaries in streams of indeterminate length, the 79 "record" is fragmented into multiple segments for transmission. Note 80 that the fragments need not be of equal or maximal size, and a 81 payload block size of zero is explicitly allowed. Any segment 82 carries data for at most one record - records never span segment 83 boundaries. 85 One example of an indeterminate-length stream is a printer jobstream 86 being created in real-time. The size of such a "record" can only be 87 known at the end after it has finished. Another example might be 88 interleaving control and file transfers over a single TCP connection. 89 The control information is one "record" while the file contents 90 following it is another "record". 92 To handle records fragmented into multiple segments, SRFP provides 93 both a segment payload byte count and a separate End-Of-Record (EOR) 94 indication. EOR is set in the last segment of a record and indicates 95 that the last payload byte of the block is the last byte of the 96 record. EOR is always set in the last segment of a record, even when 97 it is also the first segment. If the payload length is zero, then 98 EOR is effective immediately, ie, it is equivalent to the previous 99 block containing the EOR indicator. 101 SRFP provides a baseline convention for the default maximum segment 102 size which all implementations must be prepared to accept. 103 Applications are free to use a larger block size if agreed upon 104 before starting SRFP, but any such negotiation is the province of the 105 application. SRFP does not assist, but it will oblige. 107 SRFP also carries an End-Of-Session marker which can be used to 108 provide a robust "clean close" without dealing with half-closed TCP 109 channels. 111 5. Header Structure 113 The SRFP segment header consists of 4 bytes. The first two bytes 114 contain control information and the second two are an unsigned 16 bit 115 number sent in Network Standard Byte Order. 117 Byte 1: 118 1....... Must be one 119 .vvv.... Version - 001b is version 1 120 ....rr.. Reserved - Must be zero 121 ......S. End-of-Session marker 122 .......R End-of-Record marker 124 Byte 2: 125 rrrrrrrr Reserved - must be zero 127 Byte 3: 128 Most significant byte of unsigned Length 130 Byte 4: 131 Least significant byte of unsigned Length 133 Operation of SRFP is simple. Records are sent as one or more segments 134 with the unsigned 16-bit Length field in the header indicating the 135 length of the segment payload block. The record terminates with the 136 segment where the EOR bit is set, with the end coming AFTER the bytes 137 indicated by the Length field in the header. 139 The most common case is a record sent as a single segment. In this 140 case EOR and the total record size are indicated in the same segment 141 with the complete payload. 143 The other case is transfer of multi-segment records which consist of 144 some number of segments with the last segment showing EOR. Note that 145 a segment payload length of Zero is explicitly allowed, thereby 146 providing for transmission of a bare EOR bit with no additional 147 record payload in that segment. 149 There is no essential difference between the treatment of an 150 indeterminate-length record and one which is simply larger than the 151 maximum payload size of one segment. In both cases, you just keep 152 sending "more segments" until the last one which carries the EOR 153 marker. 155 6. Limitations and Conventions 157 SRFP contains no mechanism to negotiate the maximum size segments 158 which can be used; such mechanisms are deemed application-specific. 159 However, to assure a usable baseline of interoperability, all SRFP 160 implementations are required to allow segments containing 4096 bytes 161 of payload without prior arrangement. This means the segment is 162 actually 4100 bytes long including the header. How a maximum-size 163 negotiation might be made is out of the scope of this protocol. 165 7. Applications and Conclusion 167 SFRP was designed with two broad uses in mind. The first is tunneling 168 UDP-based protocols over TCP sessions. A number of useful protocols 169 are specified as running over UDP only but are, alas, equipped with 170 reliable transport machinery hopelessly tuned for small LAN 171 environments and not the global Internet. Carrying the packets over a 172 TCP connection can solve a number of operational problems without 173 requiring wholesale replumbing of the protocol. 175 The other broad usage is to make it easy to host "file transfer" type 176 protocols on a single TCP connection by making it possible to 177 reliably alternate between "control" and "transfer" modes even when 178 the transferring server cannot pre-discover the length of the "file" 179 to be transferred. 181 While SRFP makes no attempt at the general presentation problem, 182 adding just a touch of Record-boundary marking and clean session 183 close capability in a common protocol can prevent a lot of needless 184 reinvention and gratuitous incompatibility. That is precisely the 185 niche of SRFP. 187 8. Author's Address 189 Mike O'Dell 190 UUNET Technologies, Inc. 191 3060 Williams Drive 192 Fairfax, VA 22031 193 voice: 703-206-5890 194 fax: 703-206-5471 195 email: mo@uu.net