From 4bfd864f10b68b71482b35c818559068ef8d5797 Mon Sep 17 00:00:00 2001 From: Thomas Voss Date: Wed, 27 Nov 2024 20:54:24 +0100 Subject: doc: Add RFC documents --- doc/rfc/rfc1378.txt | 899 ++++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 899 insertions(+) create mode 100644 doc/rfc/rfc1378.txt (limited to 'doc/rfc/rfc1378.txt') diff --git a/doc/rfc/rfc1378.txt b/doc/rfc/rfc1378.txt new file mode 100644 index 0000000..6780ecc --- /dev/null +++ b/doc/rfc/rfc1378.txt @@ -0,0 +1,899 @@ + + + + + + +Network Working Group B. Parker +Request for Comments: 1378 Cayman Systems + November 1992 + + + The PPP AppleTalk Control Protocol (ATCP) + +Status of this Memo + + This RFC specifies an IAB standards track protocol for the Internet + community, and requests discussion and suggestions for improvements. + Please refer to the current edition of the "IAB Official Protocol + Standards" for the standardization state and status of this protocol. + Distribution of this memo is unlimited. + +Abstract + + The Point-to-Point Protocol (PPP) [1] provides a standard method of + encapsulating Network Layer protocol information over point-to-point + links. PPP also defines an extensible Link Control Protocol, and + proposes a family of Network Control Protocols (NCPs) for + establishing and configuring different network-layer protocols. + + This document defines the NCP for establishing and configuring the + AppleTalk Protocol [3] over PPP. + + This memo is a joint effort of the AppleTalk-IP Working Group and the + Point-to-Point Protocol Working Group of the Internet Engineering + Task Force (IETF). Comments on this memo should be submitted to the + ietf-ppp@ucdavis.edu mailing list. + +Table of Contents + + 1. Introduction .......................................... 2 + 2. A PPP Network Control Protocol (NCP) for AppleTalk .... 2 + 2.1 Sending AppleTalk Datagrams ........................... 3 + 2.2 Half-Routers .......................................... 4 + 3. ATCP Configuration Options ............................ 4 + 3.1 AppleTalk-Address ..................................... 5 + 3.2 Routing-Protocol ...................................... 7 + 3.3 Suppress-Broadcasts ................................... 8 + 3.4 AT-Compression-Protocol ............................... 9 + 3.5 Server-information .................................... 10 + 3.6 Zone-Information ...................................... 12 + 3.7 Default-Router-Address ................................ 13 + APPENDICES ................................................... 14 + A. ATCP Recommended Options .............................. 14 + REFERENCES ................................................... 15 + + + +Parker [Page 1] + +RFC 1378 PPP ATCP November 1992 + + + ACKNOWLEDGEMENTS ............................................. 15 + SECURITY CONSIDERATIONS ...................................... 16 + CHAIR'S ADDRESS .............................................. 16 + AUTHOR'S ADDRESS ............................................. 16 + +1. Introduction + + PPP has three main components: + + 1. A method for encapsulating datagrams over serial links. + + 2. A Link Control Protocol (LCP) for establishing, configuring, + and testing the data-link connection. + + 3. A family of Network Control Protocols (NCPs) for establishing + and configuring different network-layer protocols. + + In order to establish communications over a point-to-point link, each + end of the PPP link must first send LCP packets to configure and test + the data link. After the link has been established and optional + facilities have been negotiated as needed by the LCP, PPP must send + NCP packets to choose and configure one or more network-layer + protocols. Once each of the chosen network-layer protocols has been + configured, datagrams from each network-layer protocol can be sent + over the link. + + The link will remain configured for communications until explicit LCP + or NCP packets close the link down, or until some external event + occurs (an inactivity timer expires or network administrator + intervention). + +2. A PPP Network Control Protocol (NCP) for AppleTalk + + The AppleTalk Control Protocol (ATCP) is responsible for configuring, + enabling, and disabling the AppleTalk protocol modules on both ends + of the point-to-point link. ATCP uses the same packet exchange + machanism as the Link Control Protocol (LCP). ATCP packets may not + be exchanged until PPP has reached the Network-Layer Protocol phase. + ATCP packets received before this phase is reached should be silently + discarded. + + The AppleTalk Control Protocol is exactly the same as the Link + Control Protocol [1] with the following exceptions: + + Frame Modifications + + The packet may utilize any modifications to the basic frame format + which have been negotiated during the Link Establishment phase. + + + +Parker [Page 2] + +RFC 1378 PPP ATCP November 1992 + + + Data Link Layer Protocol Field + + Exactly one ATCP packet is encapsulated in the Information field + of a PPP Data Link Layer frame where the Protocol field indicates + type hex 8029 (AppleTalk Control Protocol). + + Code field + + Only Codes 1 through 7 (Configure-Request, Configure-Ack, + Configure-Nak, Configure-Reject, Terminate-Request, Terminate-Ack + and Code-Reject) are used. Other Codes should be treated as + unrecognized and should result in Code-Rejects. + + Timeouts + + ATCP packets may not be exchanged until PPP has reached the + Network-Layer Protocol phase. An implementation should be + prepared to wait for Authentication and Link Quality Determination + to finish before timing out waiting for a Configure-Ack or other + response. It is suggested that an implementation give up only + after user intervention or a configurable amount of time. + + Configuration Option Types + + ATCP has a distinct set of Configuration Options, which are + defined below. + +2.1. Sending AppleTalk Datagrams + + Before any AppleTalk packets may be communicated, PPP must reach the + Network-Layer Protocol phase, and the AppleTalk Control Protocol must + reach the Opened state. + + Unless otherwise negotiated (via option 4), exactly one AppleTalk + packet is encapsulated in the Information field of a PPP Data Link + Layer frame where the Protocol field indicates type hex 0029 + (AppleTalk). + + Note that the negotiation of compression may imply the use of + different encapsulation and hence different protocol fields. These + different protocol fields imply packet types which are sub-protocols + of the base AppleTalk NCP. + + An encapsulated AppleTalk packet begins with an extended DDP + (Datagram Delivery Protocol) header -- also known as a Long DDP + header. The maximum length of a DDP datagram is 599 octets. + + Since there is no standard method for fragmenting and reassembling + + + +Parker [Page 3] + +RFC 1378 PPP ATCP November 1992 + + + AppleTalk datagrams, it is required that PPP links supporting + AppleTalk allow at least 599 octets in the information field of a + data link layer frame. + +2.2. Half-Routers + + One model for routers in [3] is two remote AppleTalk routers linked + as "half-routers" without a Node ID or Network number assigned to + either side of the link. When acting as half-routers, the only + effect on transported packets is that the hop count is incremented + when it is received over the link. Routing updates received over a + half-router link should also increment the hop count of routing table + updates. + + As part of normal operation, AppleTalk will send RTMP Routing updates + every 10 seconds. + +3. ATCP Configuration Options + + ATCP Configuration Options allow negotiation of desirable AppleTalk + parameters. ATCP uses the same Configuration Option format defined + for LCP [1], with a separate set of Options. + + The most up-to-date values of the ATCP Option Type field are + specified in the most recent "Assigned Numbers" RFC [2]. Current + values are assigned as follows: + + 1 AppleTalk-Address + + 2 Routing-Protocol + + 3 Suppress-Broadcasts + + 4 AT-Compression-Protocol + + 5 RESERVED + + 6 Server-information + + 7 Zone-information + + 8 Default-Router-Address + + + + + + + + + +Parker [Page 4] + +RFC 1378 PPP ATCP November 1992 + + +3.1. AppleTalk-Address + + Description + + This Configuration Option provides a way to negotiate the + AppleTalk network and node number to be used on the local end of + the link. It allows the sender of the Configure-Request to state + which AppleTalk-address is desired, or to request that the peer + provide the information. The peer can provide this information by + NAKing the option, and returning a valid AppleTalk-address. + + If negotiation about the remote AppleTalk-address is required, and + the peer did not provide the option in its Configure-Request, the + option SHOULD be appended to a Configure-Nak. The value of the + AppleTalk-address given must be acceptable as the remote + AppleTalk-address, or indicate a request that the peer provide the + information. + + By default, no AppleTalk address is assigned. A network or node + number specified as zero in a Configure-Request shall be + interpreted as requesting the remote end to specify a value via a + Configure-Nak. A network or node number specified as zero in a + Configure-Ack shall be interpreted as agreement that no value + exists. + + An implementation which requires that no AppleTalk addresses be + assigned (such as a intermediate system to intermediate system + "half-routing") MUST Configure-Reject all AppleTalk-Address + Configuration Options. + + An implementation which requires that AppleTalk addresses be + assigned to it (such as a end system) MUST fail configuration if + the remote side Configure-Rejects all AppleTalk-Address requests, + or fails to provide a valid value. + + If this option is negotiated, the two sides MUST negotiate a + common AppleTalk network number and two unique Appletalk node + numbers. The network number MAY be zero but the Appletalk node + numbers MUST be non-zero. Values selected for network and node + numbers must adhere to the ranges defined in [3]. + + The AppleTalk protocol, phase 2, defines the concept of "extended" + and "non-extended" networks. Extended networks can support a + large number (hundreds) of nodes, and requires multiple network + numbers and multiple zone names to be managed effectively. Non- + extended networks can only support a small number of devices, and + require only a single network number and zone name to be managed + effectively. + + + +Parker [Page 5] + +RFC 1378 PPP ATCP November 1992 + + + If a PPP link transporting AppleTalk is assigned an AppleTalk + address, it must have the "non-extended" characteristics as + defined in [3]. + + The format of the network and node data is defined to be the same + as the "AppleTalk address" in [3], chapter 3, "AppleTalk AARP + packet formats on Ethernet and token ring". + + A summary of the AppleTalk-Address Configuration Option format is + shown below. The fields are transmitted from left to right. + + 0 1 2 3 + 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Type | Length | Reserved | AT-Net | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | AT-Net | AT-Node | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + + Type + + 1 + + Length + + 6 + + Reserved + + This octet is reserved and MUST be set to zero on transmission and + ignored on reception. + + AT-Net + + The two octet AT-Net is the desired local AppleTalk network number + of the sender of the Configure-Request. This two octet quantity + represents a 16 bit unsigned number sent "network byte order" + (most significant octet first). + + AT-Node + + The one octet AT-Node is the desired local AppleTalk node ID of + the sender of the Configure-Request. + + + + + + + +Parker [Page 6] + +RFC 1378 PPP ATCP November 1992 + + +3.2. Routing-Protocol + + Description + + This Configuration Option provides a way to negotiate the use of a + specific routing protocol. In particular, "half-routers" may want + to exchange routing information using a protocol optimized for the + PPP connection. By default, AppleTalk RTMP (Routing Table + Maintenance Protocol) routing information is sent over the PPP + connection. + + By default, AppleTalk RTMP routing information is sent over the + PPP connection. + + A summary of the Routing-Protocol Configuration Option format is + shown below. The fields are transmitted from left to right. + + 0 1 2 3 + 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Type | Length | Routing-Protocol | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Data ... + +-+-+-+-+ + + + Type + + 2 + + Length + + >= 4 + + Routing-Protocol + + The Routing-Protocol field is two octets and indicates the type of + Routing-Protocol desired. This two octet quantity represents a 16 + bit number sent "network byte order" (most significant octet + first). + + Negotiation of some routing protocols implies that you will + receive packet types which transport these protocols. + + For example, negotiating AppleTalk AURP to exchange routing + information implies both sides will accept EDDP type packets, + since this is the transport type used by AURP. + + + + +Parker [Page 7] + +RFC 1378 PPP ATCP November 1992 + + + Initial values are assigned as follows: + + Value Protocol + + 0 No routing information exchange + 1 AppleTalk RTMP is used to exchange routing information + 2 AppleTalk AURP is used to exchange routing information + 3 AppleTalk ABGP is used to exchange routing information + + + Data + + The Data field is zero or more octets and contains additional data + as determined by the routing protocol indicated in the Routing- + Protocol field. + + None of the Routing-Protocol options defined here require + additional data. + +3.3. Suppress-Broadcasts + + Description + + This Configuration Option provides a way to negotiate the + suppression of AppleTalk broadcast datagrams which might otherwise + use up limitted PPP bandwidth. This Configuration Option is used + to inform the remote end that no AppleTalk broadcast datagrams of + a given DDP type should be sent. + + This option is useful when negotiated by a single end system. It + allows the local end system to request that broadcast packets + generated on a remote network not be propagated across the PPP + link. In the case of a single end system connected to a large + network, this can be used to suppress regular NBP lookups + generated by other end systems on the remote network. This will + mean that protocols such as NBP can no longer be used to find + network entities on the local system, but since the option + configuration is asymmetric, it does not inhibit the local + system's ability to find network entities on the remote network. + + By default, no AppleTalk broadcast datagrams are suppressed. Note + that this option may conflict with other options (such as Routing + Protocol). If so, the Suppress-Broadcasts option takes + precedence. + + A summary of the Suppress-Broadcasts Configuration Option format is + shown below. The fields are transmitted from left to right. + + + + +Parker [Page 8] + +RFC 1378 PPP ATCP November 1992 + + + 0 1 2 3 + 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Type | Length | DDP-Type 1 | DDP-Type 2 | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | etc... + +-+-+-+-+ + + + Type + + 3 + + Length + + >= 2 + + DDP-Types + + A vector of one or more single octet DDP type values, each of + which are to be suppressed if sent to the broadcast address. + + If no data is present (the length = 2), all broadcast packets are + to be suppressed, regardless of DDP type. + +3.4. AT-Compression-Protocol + + Description + + This Configuration Option provides a way to negotiate the use of a + specific compression protocol. By default, compression is not + enabled. + + A summary of the AT-Compression-Protocol Configuration Option format + is shown below. The fields are transmitted from left to right. + + 0 1 2 3 + 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Type | Length | AT-Compression-Protocol | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Data ... + +-+-+-+-+ + + + Type + + 4 + + + +Parker [Page 9] + +RFC 1378 PPP ATCP November 1992 + + + Length + + >= 4 + + AT-Compression-Protocol + + The AT-Compression-Protocol field is two octets and indicates the + compression protocol desired. Values for this field are always + the same as the PPP Data Link Layer Protocol field values for that + same compression protocol. + + The most up-to-date values of the AT-Compression-Protocol field + are specified in the most recent "Assigned Numbers" RFC [2]. + Current values are assigned as follows: + + + Value (in hex) Protocol + + none defined + + + Data + + The Data field is zero or more octets and contains additional data + as determined by the particular compression protocol. + +3.5. Server-information + + Description + + This Configuration Option provides a way to obtain information + about the communications server providing the remote side of the + PPP connection. + + The nature of this option is advisory only. It is provided as a + means of improving an end system's ability to provide a simple + user interface. + + A summary of the Server-Information Option format is shown below. + The fields are transmitted from left to right. + + + + + + + + + + + +Parker [Page 10] + +RFC 1378 PPP ATCP November 1992 + + + 0 1 2 3 + 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Type | Length | Server-class | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Server-implementation-id | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Server-name ... + +-+-+-+-+-+-+-+-+-+-+-+-+ + + + Type + + 6 + + Length + + >= 8 + + Server-class + + The Server-class field is two octets and indicates the class of + the communication server providing the remote end of the PPP + connection. + + Initial values are assigned as follows: + + Value Class + + 1 AppleTalk PPP Dial-in server. + + The server-implementation-id is a four byte version + id, with the first byte defined as the major + version number (1-255) and the second byte defined + as the minor version number (1-255). + + The third and fourth bytes are undefined and should + be zero. + + 2 Generic AppleTalk PPP implementation. + + The server-implementation-id is undefined and + vendor specific. + + 3 Both dial-in server and router + + + + + + +Parker [Page 11] + +RFC 1378 PPP ATCP November 1992 + + + Server-implementation-id + + The Server-implementation-id field is four octets and indicates + the version of the communication server providing the remote end + of the PPP connection. + + Server-name + + This optional field contains the "AppleTalk ASCII" name of the + server. The character codes used in "AppleTalk ASCII" are defined + in [3], appendix D, "Character codes". The length of the name is + bounded by the option length. + +3.6. Zone-Information + + Description + + This Configuration Option provides a way to obtain information + about the AppleTalk zone used for the PPP connection. + + The nature of this option is advisory only. It is provided as a + means of improving the end system's ability to provide a simple + user interface. + + A summary of the Zone-Information Option format is shown below. The + fields are transmitted from left to right. + + 0 1 2 3 + 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Type | Length | Zone-name... | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + + Type + + 7 + + Length + + >= 3 + + Zone-name + + This field contains the "AppleTalk ASCII" zone name in which the + server resides. The character codes used in "AppleTalk ASCII" are + defined in [3], appendix D, "Character codes". The length of the + name is bounded by the option length. + + + +Parker [Page 12] + +RFC 1378 PPP ATCP November 1992 + + +3.7. Default-Router-Address + + Description + + + This Configuration Option provides a way to obtain information + about a "default" Appletalk router which may be used to obtain + network information such as zone names. It is provided as a means + of obtaining the address of a router in the case both sides of the + link are end systems. + + Any AppleTalk RTMP packets received should supercede information + negotiated in this option. + + By default, no default router is present. + + A summary of the Default-Router-Address Option format is shown below. + The fields are transmitted from left to right. + + 0 1 2 3 + 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Type | Length | Reserved | AT-Net | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | AT-Net | AT-Node | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + + Type + + 8 + + Length + + 6 + + Reserved + + This octet is reserved and MUST be set to zero on transmission and + ignored on reception. + + AT-Net + + The two octet AT-Net is the AppleTalk network number of the + default router. This two octet quantity represents a 16 bit + unsigned number sent in "network byte order" (most significant + octet first). + + + + +Parker [Page 13] + +RFC 1378 PPP ATCP November 1992 + + + AT-Node + + The one octet AT-Node is the AppleTalk node ID of the default + router. + +A. ATCP Recommended Options + + The ATCP is designed to support three different modes of operation. + Each mode places constraints on the configuration options used and + the values negotiated. + + The options for server information, zone information and default + router address are "informational" options provided by one end of the + connection and are not intended to be negotiated. These options are + provided to support a higher level of service to dial-in end systems. + + The options which SHOULD be negotiated in each case are outlined + below. Any option not listed may be rejected. + +End System to Intermediate System - "dial-in" + + This mode of operation is intended to support end system dial-in. + + 1 AppleTalk-Address (required) + 2 Routing-Protocol (required, no routing protocol) + 3 Suppress-Broadcasts (optional) + 4 AT-Compression-Protocol (optional) + 6 Server-information (optional, request from end system) + + + + + + + + + + + + + + + + + + + + + + + +Parker [Page 14] + +RFC 1378 PPP ATCP November 1992 + + +Intermediate system to Intermediate system - with network number + + This mode of operation is intended to support WAN-to-WAN, i.e., + router to router, connections where the link is configured with a + network number. + + 1 AppleTalk-Address (required, nets must be zero or equal) + 2 Routing-Protocol (optional) + 3 Suppress-Broadcasts (optional) + +Intermediate system to Intermediate system - without network number + + This mode of operation is intended to support WAN-to-WAN, i.e., + router to router, connections where the link is not configured with a + network number. Routers in this mode are referred to as "half- + routers" in [3]. + + 1 AppleTalk-Address (optional, nets & nodes MUST be zero) + 2 Routing-Protocol (optional) + 3 Suppress-Broadcasts (optional, suppress all broadcasts) + +References + + [1] Simpson, W., "The Point-to-Point Protocol (PPP)", RFC 1331, + Daydreamer, May 1992. + + [2] Reynolds, J., and J. Postel, "Assigned Numbers", STD 2, RFC 1340, + USC/Information Sciences Institute, July 1992. + + [3] Sidhu G., Andrews, R., and A. Oppenheimer, "Inside AppleTalk, + Second Edition", Addison-Wesley Publishing Company, Inc., May + 1990. + +Acknowledgments + + Some of the text in this document is taken from previous documents + produced by the Point-to-Point Protocol Working Group of the Internet + Engineering Task Force (IETF). + + This document is derivative of drafts written by the following + people. Many thanks for their work, and for taking an initial stab + at the protocol: + + Steve Senum (sjs@network.com), Network Systems Corporation + Jim Muchow (muchow@anubis.network.com), Network Systems Corporation + Frank Slaughter (fgs@Shiva.COM), Shiva Corporation + + + + + +Parker [Page 15] + +RFC 1378 PPP ATCP November 1992 + + +Security Considerations + + Security issues are not discussed in this memo. + +Chair's Address + + The working groups can be contacted via the current chairs: + + Brian Lloyd + Lloyd & Associates + 3420 Sudbury Road + Cameron Park, California 95682 + + Phone: (916) 676-1147 + EMail: brian@lloyd.com + + + John Veizades + Apple Computer, Inc. + 20525 Mariani Avenue + Cupertino, CA 95014 + + Phone: (408) 996-1010 + EMail: veizades@apple.com + +Author's Address + + Questions about this memo can also be directed to: + + Brad Parker + Cayman Systems, Inc. + 26 Landsdowne Street + Cambridge, Ma 02139 + + EMail: brad@cayman.com + + + + + + + + + + + + + + + + +Parker [Page 16] + \ No newline at end of file -- cgit v1.2.3