Bundle Protocol
draft-ietf-dtn-bpbis-02
The information below is for an old version of the document.
Document | Type |
This is an older version of an Internet-Draft that was ultimately published as RFC 9171.
|
|
---|---|---|---|
Authors | Scott C. Burleigh , Kevin Fall , Edward J. Birrane | ||
Last updated | 2016-01-11 | ||
Replaces | draft-dtnwg-bp | ||
RFC stream | Internet Engineering Task Force (IETF) | ||
Formats | |||
Reviews |
GENART Telechat review
(of
-21)
by Stewart Bryant
Ready w/issues
|
||
Additional resources | Mailing list discussion | ||
Stream | WG state | WG Document | |
Document shepherd | (None) | ||
IESG | IESG state | Became RFC 9171 (Proposed Standard) | |
Consensus boilerplate | Unknown | ||
Telechat date | (None) | ||
Responsible AD | (None) | ||
Send notices to | (None) |
draft-ietf-dtn-bpbis-02
Delay-Tolerant Networking Working Group S. Burleigh Internet Draft JPL, Calif. Inst. Of Technology Intended status: Standards Track K. Fall Expires: December 2015 Carnegie Mellon University / SEI E. Birrane APL, Johns Hopkins University January 11, 2016 Bundle Protocol draft-ietf-dtn-bpbis-02.txt Status of this Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English. 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 This Internet-Draft will expire on July 14, 2016. Burleigh Expires July 2016 [Page 1] Internet-Draft Proposed Revised Bundle Protocol January 20166 Copyright Notice Copyright (c) 2016 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://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. Abstract This Internet Draft presents a specification for Bundle Protocol, adapted from the experimental Bundle Protocol specification developed by the Delay-Tolerant Networking Research group of the Internet Research Task Force and documented in RFC 5050. Table of Contents 1. Introduction...................................................3 2. Conventions used in this document..............................5 3. Service Description............................................6 3.1. Definitions...............................................6 3.2. Discussion of BP concepts.................................9 3.3. Services Offered by Bundle Protocol Agents...............14 4. Bundle Format.................................................14 4.1. Bundle Processing Control Flags..........................14 4.2. Block Processing Control Flags...........................16 4.3. Identifiers..............................................16 4.3.1. Endpoint ID.........................................16 4.3.2. Node ID.............................................17 4.4. Contents of Bundle Blocks................................17 4.4.1. Primary Bundle Block................................17 4.4.2. Canonical Bundle Block Format.......................19 4.5. Extension Blocks.........................................20 4.5.1. Current Custodian...................................20 4.5.2. Flow Label..........................................20 4.5.3. Previous Node ID....................................21 4.5.4. Bundle Age..........................................21 4.5.5. Hop Count...........................................21 5. Bundle Processing.............................................21 Burleigh Expires July 2016 [Page 2] Internet-Draft Proposed Revised Bundle Protocol January 20166 5.1. Generation of Administrative Records.....................22 5.2. Bundle Transmission......................................23 5.3. Bundle Dispatching.......................................23 5.4. Bundle Forwarding........................................23 5.4.1. Forwarding Contraindicated..........................25 5.4.2. Forwarding Failed...................................26 5.5. Bundle Expiration........................................26 5.6. Bundle Reception.........................................27 5.7. Local Bundle Delivery....................................28 5.8. Bundle Fragmentation.....................................28 5.9. Application Data Unit Reassembly.........................30 5.10. Custody Transfer........................................30 5.10.1. Custody Acceptance.................................30 5.10.2. Custody Release....................................31 5.11. Custody Transfer Success................................31 5.12. Custody Transfer Failure................................31 5.13. Bundle Deletion.........................................32 5.14. Discarding a Bundle.....................................32 5.15. Canceling a Transmission................................32 6. Administrative Record Processing..............................33 6.1. Administrative Records...................................33 6.1.1. Bundle Status Reports...............................33 6.1.2. Custody Signals.....................................36 6.2. Generation of Administrative Records.....................37 6.3. Reception of Custody Signals.............................37 7. Services Required of the Convergence Layer....................38 7.1. The Convergence Layer....................................38 7.2. Summary of Convergence Layer Services....................38 8. Security Considerations.......................................38 9. IANA Considerations...........................................40 10. References...................................................40 10.1. Normative References....................................40 10.2. Informative References..................................40 11. Acknowledgments..............................................41 12. Significant Changes from RFC 5050............................41 13. Open Issues..................................................42 13.1. Application Agent.......................................42 13.2. Primary block CRC type..................................42 Appendix A. For More Information.................................43 1. Introduction Since the publication of the Bundle Protocol Specification (Experimental RFC 5050[RFC5050]) in 2007, the Delay-Tolerant Networking Bundle Protocol has been implemented in multiple programming languages and deployed to a wide variety of computing platforms for a wide range of successful exercises. This Burleigh Expires July 2016 [Page 3] Internet-Draft Proposed Revised Bundle Protocol January 20166 gt; should be the address of the person who made 3704: the last change. YYMMDD denotes the date this change was made. 3705: 3706: Example: 'yy' on a line without 'yyyy' found at line 3950: 3948: 3949: Format: 3950: <email-address> YYMMDD 3951: 3952: <email-address> should be the address of the person who 'yy' on a line without 'yyyy' found at line 3953: 3951: 3952: <email-address> should be the address of the person who 3953: made the last change. YYMMDD denotes the date this change 3954: was made. 3955: 'yy' on a line without 'yyyy' found at line 4170: 4168: 4169: Format: 4170: <email-address> YYMMDD 4171: 4172: <email-address> should be the address of the person who 'yy' on a line without 'yyyy' found at line 4173: 4171: 4172: <email-address> should be the address of the person who 4173: made the last change. YYMMDD denotes the date this change 4174: was made. 4175: 'yy' on a line without 'yyyy' found at line 4305: 4303: 4304: Format: 4305: YYMMDD 4306: 4307: YYMMDD denotes the date this route was withdrawn. 'yy' on a line without 'yyyy' found at line 4307: 4305: YYMMDD 4306: 4307: YYMMDD denotes the date this route was withdrawn. 4308: 4309: 'yy' on a line without 'yyyy' found at line 4394: 4392: 4393: Format: 4394: <email-address> YYMMDD 4395: 4396: <email-address> should be the address of the person who 'yy' on a line without 'yyyy' found at line 4397: 4395: 4396: <email-address> should be the address of the person who 4397: made the last change. YYMMDD denotes the date this change 4398: was made. 4399: +=+=+=+=+= File rfc1800.txt +=+=+=+=+= 'yy' on a line without 'yyyy' found at line 1950: 1948: The text version is sent. 1949: 1950: file /ftp/rfc/rfcnnnn.yyy where 'nnnn' is the RFC number. 1951: and 'yyy' is 'txt' or 'ps'. 1952: 'yy' on a line without 'yyyy' found at line 1951: 1949: 1950: file /ftp/rfc/rfcnnnn.yyy where 'nnnn' is the RFC number. 1951: and 'yyy' is 'txt' or 'ps'. 1952: 1953: help to get information on how to use +=+=+=+=+= File rfc1806.txt +=+=+=+=+= century found at line 8: 6: 7: Network Working Group R. Troost 8: Request for Comments: 1806 New Century Systems 9: Category: Experimental S. Dorner 10: QUALCOMM Incorporated century found at line 402: 400: 401: Rens Troost 402: New Century Systems 403: 324 East 41st Street #804 404: New York, NY, 10017 USA century found at line 408: 406: Phone: +1 (212) 557-2050 407: Fax: +1 (212) 557-2049 408: EMail: rens@century.com 409: 410: +=+=+=+=+= File rfc1807.txt +=+=+=+=+= 'yy' on a line without 'yyyy' found at line 318: 316: mandatory field. The ID field identifies the bibliographic 317: record and is used in management of these records. 318: Its format is "ID:: XXX//YYY", where XXX is the 319: publisher-ID (the controlled symbol of the publisher) 320: and YYY is the ID (e.g., report number) of the 'yy' on a line without 'yyyy' found at line 320: 318: Its format is "ID:: XXX//YYY", where XXX is the 319: publisher-ID (the controlled symbol of the publisher) 320: and YYY is the ID (e.g., report number) of the 321: publication as assigned by the publisher. This ID is 322: typically printed on the cover, and may contain slashes. 'yy' on a line without 'yyyy' found at line 767: 765: in its "ID::". 766: 767: Format: END:: XXX//YYY 768: 769: Example: END:: OUKS//CS-TR-91-123 'yy' on a line without 'yyyy' found at line 778: 776: 777: In order to avoid conflicts among the symbols of the publishing 778: organizations (the XXX part of the "ID:: XXX//YYY") it is suggested 779: that the various organizations that publish reports (such as 780: universities, departments, and laboratories) register their 2-digit found at line 348: 346: The format for ENTRY date is "Month Day, Year". The 347: month must be alphabetic (spelled out). The "Day" is a 348: 1- or 2-digit number. The "Year" is a 4-digit number. 349: 350: Format: ENTRY:: <date> 2-digit found at line 513: 511: DATE (O) -- The publication date. The formats are "Month Year" 512: and "Month Day, Year". The month must be alphabetic 513: (spelled out). The "Day" is a 1- or 2-digit number. The 514: "Year" is a 4- digit number. 515: 1900 found at line 406: 404: omitted, the record is assumed to be a new record and not 405: a revision. If the revision date is specified as 0, this 406: is assumed to be January 1, 1900 (the previous RFC, used 407: revision data of 0, 1, 2, 3, etc. this specification is for 408: programs that might process records from RFC1357). +=+=+=+=+= File rfc1815.txt +=+=+=+=+= 2000 found at line 187: 185: 8 BASIC GREEK 0370-03CF 186: 10 CYRILLIC 0400-04FF 187: 32 GENERAL PUNCTUATION 2000-206F See note 1, below. 188: 39 MATHEMATICAL OPERATORS 2200-22FF See note 1, below. 189: 44 BOX DRAWING 2500-257F +=+=+=+=+= File rfc1819.txt +=+=+=+=+= 2000 found at line 5855: 5853: 5 HelloLossFactor Number of consecutively missed HELLO 5854: messages before declaring link failure 5855: 2000 DefaultRecoveryTimeout Interval between successive HELLOs 5856: to/from active neighbors 5857: +=+=+=+=+= File rfc1831.txt +=+=+=+=+= 2000 found at line 401: 399: 7.3 Program Number Assignment 400: 401: Program numbers are given out in groups of hexadecimal 20000000 402: (decimal 536870912) according to the following chart: 403: 2000 found at line 405: 403: 404: 0 - 1fffffff defined by rpc@sun.com 405: 20000000 - 3fffffff defined by user 406: 40000000 - 5fffffff transient 407: 60000000 - 7fffffff reserved +=+=+=+=+= File rfc1848.txt +=+=+=+=+= 'yy' on a line without 'yyyy' found at line 1881: 1879: Content-Transfer-Encoding: base64 1880: 1881: AfR1WSeyLhy5AtcX0ktUVlbFC1vvcoCjYWy/yYjVj48eqzUVvGTGMsV6MdlynU 1882: d4jcJgRnQIQvIxm2VRgH8W8MkAlul+RWGu7jnxjp0sNsU562+RZr0f4F3K3n4w 1883: onUUP265UvvMj23RSTguZ/nl/OxnFM6SzDgV39V/i/RofqI= 'yy' on a line without 'yyyy' found at line 1994: 1992: U6B13vzpE8wMSVefzaCTSpXRSCh08ceVEZrIYS53/CKZV2/Sga71pGNlux8MsJpY 1993: Lwdj5Q3NKocg1LMngMo8yrMAe+avMjfOnhui49Xon1Gft+N5XDH/+wI9qxI9fkQv 1994: NZVDlWIhCYEkxd5ke549tLkJjEqHQbgJW5C+K/uxdiD2dBt+nRCXcuO0Px3yKRyY 1995: g/9BgTf36padSHuv48xBg5YaqaEWpEzLI0Qd31vAyP23rqiPhfBn6sjhQ2KrWhiF 1996: 2l3TV8kQsIGHHZUkaUbqkXJe6PEdWWhwsqCFPDdkpjzQRrTuJH6xleNUFg+CG1V+ +=+=+=+=+= File rfc1861.txt +=+=+=+=+= 'yy' on a line without 'yyyy' found at line 766: 764: 554 Error, failed (technical reason) 765: 766: 4.5.6 HOLDuntil <YYMMDDHHMMSS> [+/-GMTdifference] 767: 768: The HOLDuntil command allows for the delayed delivery of a message, 'yy' on a line without 'yyyy' found at line 1061: 1059: the current transaction should be kept in the following format: 1060: 1061: YYMMDDHHMMSS+GMT (example: 950925143501+7) 1062: 1063: +=+=+=+=+= File rfc1865.txt +=+=+=+=+= 1900 found at line 1564: 1562: 1563: START 1564: GET ITU-1900 1565: END 1566: 2000 found at line 1745: 1743: Logistics Management Institute 1744: Attn. Library 1745: 2000 Corporate Ridge 1746: McLean, Virginia, 22102-7805 1747: +=+=+=+=+= File rfc1866.txt +=+=+=+=+= 'yy' on a line without 'yyyy' found at line 1078: 1076: <div class=chapter><h1>foo</h1><p>...</div> 1077: => <H1>,"foo",</H1>,<P>,"..." 1078: xxx <P ID=z23> yyy 1079: => "xxx ",<P>," yyy 1080: Let α & β be finite sets. 'yy' on a line without 'yyyy' found at line 1079: 1077: => <H1>,"foo",</H1>,<P>,"..." 1078: xxx <P ID=z23> yyy 1079: => "xxx ",<P>," yyy 1080: Let α & β be finite sets. 1081: => "Let α & &implementation and deployment experience has demonstrated the general utility of the protocol for challenged network operations. It has also, as expected, identified opportunities for making the protocol simpler, more capable, and easier to use. The present document, standardizing the Bundle Protocol (BP), is adapted from RFC 5050 in that context. This document describes version 7 of BP. Delay Tolerant Networking is a network architecture providing communications in and/or through highly stressed environments. Stressed networking environments include those with intermittent connectivity, large and/or variable delays, and high bit error rates. To provide its services, BP may be viewed as sitting at the application layer of some number of constituent networks, forming a store-carry-forward overlay network. Key capabilities of BP include: . Custodial forwarding . Ability to cope with intermittent connectivity, including cases where the sender and receiver are not concurrently present in the network . Ability to take advantage of scheduled, predicted, and opportunistic connectivity, whether bidirectional or unidirectional, in addition to continuous connectivity . Late binding of overlay network endpoint identifiers to underlying constituent network addresses For descriptions of these capabilities and the rationale for the DTN architecture, see [ARCH] and [SIGC]. [TUT] contains a tutorial- level overview of DTN concepts. BP's location within the standard protocol stack is as shown in Figure 1. BP uses underlying "native" transport and/or network protocols for communications within a given constituent network. The interface between the bundle protocol and a specific underlying protocol is termed a "convergence layer adapter". Figure 1 shows three distinct transport and network protocols (denoted T1/N1, T2/N2, and T3/N3). Burleigh Expires July 2016 [Page 4] Internet-Draft Proposed Revised Bundle Protocol January 20166 +-----------+ +-----------+ | BP app | | BP app | +---------v-| +->>>>>>>>>>v-+ +->>>>>>>>>>v-+ +-^---------+ | BP v | | ^ BP v | | ^ BP v | | ^ BP | +---------v-+ +-^---------v-+ +-^---------v-+ +-^---------+ | Trans1 v | + ^ T1/T2 v | + ^ T2/T3 v | | ^ Trans3 | +---------v-+ +-^---------v-+ +-^---------v + +-^---------+ | Net1 v | | ^ N1/N2 v | | ^ N2/N3 v | | ^ Net3 | +---------v-+ +-^---------v + +-^---------v-+ +-^---------+ | >>>>>>>>^ >>>>>>>>>>^ >>>>>>>>^ | +-----------+ +-------------+ +-------------+ +-----------+ | | | | |<---- A network ---->| |<---- A network ---->| | | | | Figure 1: The Bundle Protocol in the Protocol Stack Model This document describes the format of the protocol data units (called "bundles") passed between entities participating in BP communications. The entities are referred to as "bundle nodes". This document does not address: . Operations in the convergence layer adapters that bundle nodes use to transport data through specific types of internets. (However, the document does discuss the services that must be provided by each adapter at the convergence layer.) . The bundle route computation algorithm. . Mechanisms for populating the routing or forwarding information bases of bundle nodes. . The mechanisms for securing bundles en-route. . The mechanisms for managing bundle nodes. 2. Conventions used in this document The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC-2119 [RFC2119]. In this document, these words will appear with that interpretation only when in ALL CAPS. Lower case uses of these words are not to be interpreted as carrying RFC-2119 significance. Burleigh Expires July 2016 [Page 5] Internet-Draft Proposed Revised Bundle Protocol January 20166 3. Service Description 3.1. Definitions Bundle - A bundle is a protocol data unit of BP, so named because negotiation of the parameters of a data exchange may be impractical in a delay-tolerant network: it is often better practice to "bundle" with a unit of data all metadata that might be needed in order to make the data immediately usable when delivered to applications. Each bundle comprises a sequence of two or more "blocks" of protocol data, which serve various purposes. Block - A bundle protocol block is one of the protocol data structures that together constitute a well-formed bundle. Bundle payload - A bundle payload (or simply "payload") is the application data whose conveyance to the bundle's destination is the purpose for the transmission of a given bundle; it is the content of the bundle's payload block. The terms "bundle content", "bundle payload", and "payload" are used interchangeably in this document. Partial payload - A partial payload is a payload that comprises either the first N bytes or the last N bytes of some other payload of length M, such that 0 < N < M. Fragment - A fragment is a bundle whose payload block contains a partial payload. Bundle node - A bundle node (or, in the context of this document, simply a "node") is any entity that can send and/or receive bundles. Each bundle node has three conceptual components, defined below: a "bundle protocol agent", a set of zero or more "convergence layer adapters", and an "application agent". Bundle protocol agent - The bundle protocol agent (BPA) of a node is the node component that offers the BP services and executes the procedures of the bundle protocol. Convergence layer adapter - A convergence layer adapter (CLA) is a node component that sends and receives bundles on behalf of the BPA, utilizing the services of some 'native' protocol stack that is supported in one of the networks within which the node is functionally located. Application agent - The application agent (AA) of a node is the node component that utilizes the BP services to effect communication for Burleigh Expires July 2016 [Page 6] Internet-Draft Proposed Revised Bundle Protocol January 20166 some user purpose. The application agent in turn has two elements, an administrative element and an application-specific element. Application-specific element - The application-specific element of an AA is the node component that constructs, requests transmission of, accepts delivery of, and processes units of user application data. Administrative element - The administrative element of an AA is the node component that constructs and requests transmission of administrative records (defined below), including status reports and custody signals, and accepts delivery of and processes any custody signals that the node receives. Administrative record - A BP administrative record is an application data unit that is exchanged between the administrative elements of nodes' application agents for some BP administrative purpose. The formats of some fundamental administrative records (and of no other application data units) are defined in this specification. Bundle endpoint - A bundle endpoint (or simply "endpoint") is a set of zero or more bundle nodes that all identify themselves for BP purposes by some common identifier, called a "bundle endpoint ID" (or, in this document, simply "endpoint ID"; endpoint IDs are described in detail in Section 4.3.1 below). Singleton endpoint - A singleton endpoint is an endpoint that always contains exactly one member. Registration - A registration is the state machine characterizing a given node's membership in a given endpoint. Any single registration has an associated delivery failure action as defined below and must at any time be in one of two states: Active or Passive. Delivery - A bundle is considered to have been delivered at a node subject to a registration as soon as the application data unit that is the payload of the bundle, together with any relevant metadata (an implementation matter), has been presented to the node's application agent in a manner consistent with the state of that registration. Deliverability - A bundle is considered "deliverable" subject to a registration if and only if (a) the bundleβ be finite sets." +=+=+=+=+= File rfc1876.txt +=+=+=+=+= 2000 found at line 103: 101: exponent. 102: 103: Since 20000000m (represented by the value 0x29) is greater 104: than the equatorial diameter of the WGS 84 ellipsoid 105: (12756274m), it is therefore suitable for use as a 2000 found at line 219: 217: 218: rwy04L.logan-airport.boston. LOC 42 21 28.764 N 71 00 51.617 W 219: -44m 2000m 220: 221: +=+=+=+=+= File rfc1880.txt +=+=+=+=+= 'yy' on a line without 'yyyy' found at line 2062: 2060: The text version is sent. 2061: 2062: file /ftp/rfc/rfcnnnn.yyy where 'nnnn' is the RFC number. 2063: and 'yyy' is 'txt' or 'ps'. 2064: 'yy' on a line without 'yyyy' found at line 2063: 2061: 2062: file /ftp/rfc/rfcnnnn.yyy where 'nnnn' is the RFC number. 2063: and 'yyy' is 'txt' or 'ps'. 2064: 2065: help to get information on how to use +=+=+=+=+= File rfc1888.txt +=+=+=+=+= 1900 found at line 859: 857: Group Leader, Communications Systems Phone: +41 22 767-4967 858: Computing and Networks Division Fax: +41 22 767-7155 859: CERN Telex: 419000 cer ch 860: European Laboratory for Particle Physics Email: brian@dxcoms.cern.ch 861: 1211 Geneva 23, Switzerland +=+=+=+=+= File rfc1889.txt +=+=+=+=+= 1900 found at line 518: 516: Wallclock time (absolute time) is represented using the timestamp 517: format of the Network Time Protocol (NTP), which is in seconds 518: relative to 0h UTC on 1 January 1900 [5]. The full resolution NTP 519: timestamp is a 64-bit unsigned fixed-point number with the integer 520: part in the first 32 bits and the fractional part in the last 32 2000 found at line 1526: 1524: v ^ 1525: ntp_sec =0xb44db705 v ^ dlsr=0x0005.4000 ( 5.250s) 1526: ntp_frac=0x20000000 v ^ lsr =0xb705:2000 (46853.125s) 1527: (3024992016.125 s) v ^ 1528: r v ^ RR(n) 2000 found at line 1535: 1533: A 0xb710:8000 (46864.500 s) 1534: DLSR -0x0005:4000 ( 5.250 s) 1535: LSR -0xb705:2000 (46853.125 s) 1536: ------------------------------- 1537: delay 0x 6:2000 ( 6.125 s) 2000 found at line 1537: 1535: LSR -0xb705:2000 (46853.125 s) 1536: ------------------------------- 1537: delay 0x 6:2000 ( 6.125 s) 1538: 1539: Figure 2: Example for round-trip time computation 2000 found at line 3182: 3180: * Big-endian mask for version, padding bit and packet type pair 3181: */ 3182: #define RTCP_VALID_MASK (0xc000 | 0x2000 | 0xfe) 3183: #define RTCP_VALID_VALUE ((RTP_VERSION << 14) | RTCP_SR) 3184: +=+=+=+=+= File rfc1890.txt +=+=+=+=+= 2000 found at line 293: 291: 292: The sampling frequency should be drawn from the set: 8000, 11025, 293: 16000, 22050, 24000, 32000, 44100 and 48000 Hz. (The Apple Macintosh 294: computers have native sample rates of 22254.54 and 11127.27, which 295: can be converted to 22050 and 11025 with acceptable quality by 2000 found at line 568: 566: 567: Sampling rate and channel count are contained in the payload. MPEG-I 568: audio supports sampling rates of 32000, 44100, and 48000 Hz (ISO/IEC 569: 11172-3, section 1.1; "Scope"). MPEG-II additionally supports ISO/IEC 570: 11172-3 Audio..."). +=+=+=+=+= File rfc1898.txt +=+=+=+=+= 'yy' on a line without 'yyyy' found at line 1271: 1269: 3rWM5Ir3ier3/7WM5Ir36+v35v73ife1jOWK94n3/7T3/ffm5uD+7N339/f39/eq3ff3 1270: 9/eFiJK5tLizsoeSmpW7uLS8/7iio7Wisfv38biio7uyufv3tfv35uH+7N3d9/exuKX3 1271: 5+z3vuu4oqO7srnsvvz8/venoqO0v7al/7iio7WisYy+iv7s3ff3p6KjtL+2pf/wi7nw 1272: 3ard3Q== 1273: $$-CyberCash-End-7Tm/djB05pLIw3JAyy5E7A==-$$ 'yy' on a line without 'yyyy' found at line 1273: 1271: 5+z3vuu4oqO7srnsvvz8/venoqO0v7al/7iio7WisYy+iv7s3ff3p6KjtL+2pf/wi7nw 1272: 3ard3Q== 1273: $$-CyberCash-End-7Tm/djB05pLIw3JAyy5E7A==-$$ 1274: 1275: ##################################################################### 'yy' on a line without 'yyyy' found at line 1328: 1326: merchant-date: 19950121100505.nnn 1327: merchant-response-code: failure/success/etc. 1328: pr-hash: 7Tm/djB05pLIw3JAyy5E7A== 1329: pr-signed-hash: 1330: a/0meaMHRinNVd8nq/fKsYg5AfTZZUCX0S3gkjAhZTmcrkp6RZvppmDd/P7lboFLFDBh 'yy' on a line without 'yyyy' found at line 1340: 1338: rHzP5YqaMnk5iRBHvwKb5MaxKXGOOef5ms8M5W8lI2d0XPecH4xNBn8BMAJ6iSkZmszo 1339: QfDeWgga48g2tqlA6ifZGp7daDR81lumtGMCvg== 1340: $$-CyberCash-End-7Tm/djB05pLIw3JAyy5E7A==-$$ 1341: 1342: ##################################################################### 'yy' on a line without 'yyyy' found at line 1474: 1472: mjD6ickhd+SQZhbRCNerlTiQGhuL4wUAxzGh8aHk2oXjoMpVzWw2EImPu5QaPEc36xgr 1473: mNz8vCovDiuy3tZ42IGArxBweasLPLCbm0Y= 1474: $$-CyberCash-End-7Tm/djB05pLIw3JAyy5E7A==-$$ 1475: 1476: ##################################################################### 'yy' on a line without 'yyyy' found at line 1482: 1480: order-id: 12313424234242 1481: merchant-amount: usd 10.00 1482: pr-hash: 7Tm/djB05pLIw3JAyy5E7A== 1483: pr-signed-hash: 1484: a/0meaMHRinNVd8nq/fKsYg5AfTZZUCX0S3gkjAhZTmcrkp6RZvppmDd/P7lboFLFDBh 'yy' on a line without 'yyyy' found at line 1490: 1488: date: 19950121100505.nnn 1489: merchant-signature: 1490: v4qZMe2d7mUXztVdC3ZPMmMgYHlBA7bhR96LSehKP15ylqR/1KwwbBAX8CEqns55UIYY 1491: GGMwPMGoF+GDPM7GlC6fReQ5wyvV1PnETSVO9/LAyRz0zzRYuyVueOjWDlr5 1492: 'yy' on a line without 'yyyy' found at line 1593: 1591: mjD6ickhd+SQZhbRCNerlTiQGhuL4wUAxzGh8aHk2oXjoMpVzWw2EImPu5QaPEc36xgr 1592: mNz8vCovDiuy3tZ42IGArxBweasLPLCbm0Y= 1593: $$-CyberCash-End-7Tm/djB05pLIw3JAyy5E7A==-$$ 1594: 1595: ##################################################################### 'yy' on a line without 'yyyy' found at line 1602: 1600: order-id: 1231-3424-234242 1601: merchant-amount: usd 10.00 1602: pr-hash: 7Tm/djB05pLIw3JAyy5E7A== 1603: pr-signed-hash: 1604: a/0meaMHRinNVd8nq/fKsYg5AfTZZUCX0S3gkjAhZTmcrkp6RZvppmDd/P7lboFLFDBh 'yy' on a line without 'yyyy' found at line 1692: 1690: mjD6ickhd+SQZhbRCNerlTiQGhuL4wUAxzGh8aHk2oXjoMpVzWw2EImPu5QaPEc36xgr 1691: mNz8vCovDiuy3tZ42IGArxBweasLPLCbm0Y= 1692: $$-CyberCash-End-7Tm/djB05pLIw3JAyy5E7A==-$$ 1693: 1694: ##################################################################### 'yy' on a line without 'yyyy' found at line 1804: 1802: mjD6ickhd+SQZhbRCNerlTiQGhuL4wUAxzGh8aHk2oXjoMpVzWw2EImPu5QaPEc36xgr 1803: mNz8vCovDiuy3tZ42IGArxBweasLPLCbm0Y= 1804: $$-CyberCash-End-7Tm/djB05pLIw3JAyy5E7A==-$$ 1805: 1806: ##################################################################### 'yy' on a line without 'yyyy' found at line 1821: 1819: response-code: failure/success/etc. 1820: order-id: 1231-3424-234242 1821: pr-hash: 7Tm/djB05pLIw3JAyy5E7A== 1822: pr-signed-hash: 1823: 8zqw0ipqtLtte0tBz5/5VPNJPPonfTwkfZPbtuk5lqMykKDvThhO0ycrfT7eXrn/hLUC 'yy' on a line without 'yyyy' found at line 1827: 1825: retrieval-reference-number: 432112344321 1826: authorization-code: a12323 1827: card-hash: 7Tm/djB05pLIw3JAyy5E7A== 1828: { 1829: card-prefix: nnxxxx [Returned if merchant is not full-PAN] 'yy' on a line without 'yyyy' found at line 1948: 1946: mjD6ickhd+SQZhbRCNerlTiQGhuL4wUAxzGh8aHk2oXjoMpVzWw2EImPu5QaPEc36xgr 1947: mNz8vCovDiuy3tZ42IGArxBweasLPLCbm0Y= 1948: $$-CyberCash-End-7Tm/djB05pLIw3JAyy5E7A==-$$ 1949: 1950: ##################################################################### 'yy' on a line without 'yyyy' found at line 1958: 1956: order-id: 12313424234242 1957: merchant-amount: usd 10.00 1958: pr-hash: 7Tm/djB05pLIw3JAyy5E7A== 1959: 1960: 'yy' on a line without 'yyyy' found at line 2050: 2048: CEUEvQhcmruopwEeehv+bejc3fDDZ23JKrbhlZ17lSvFR14PKFsi32pXFqTO0ej9GTc5 2049: L6c8nM3tI1qdHNCe0N5f7ASdKS0tYSxAYJLIR6MqPrXjNJEaRx7Vu1odMlkgrzGOV1fo 2050: 5w33BQHK3U2h+1e5zYBeHY3ZYG4nmylYYXIye4xpuPN4QU0dGrWZoImYE44QOwjd5ozl 2051: xulPBjj6cpEI/9wTwR3tpkBb4ZfYirxxnoj9JUkPK9Srv9iJ 2052: $$-CyberCash-End-7Tm/djB05pLIw3JAyy5E7A==-$$ 'yy' on a line without 'yyyy' found at line 2052: 2050: 5w33BQHK3U2h+1e5zYBeHY3ZYG4nmylYYXIye4xpuPN4QU0dGrWZoImYE44QOwjd5ozl 2051: xulPBjj6cpEI/9wTwR3tpkBb4ZfYirxxnoj9JUkPK9Srv9iJ 2052: $$-CyberCash-End-7Tm/djB05pLIw3JAyy5E7A==-$$ 2053: 2054: ##################################################################### 'yy' on a line without 'yyyy' found at line 2064: 2062: response-code: failure/success/etc. 2063: order-id: 1231-3424-234242 2064: pr-hash: 7Tm/djB05pLIw3JAyy5E7A== 2065: pr-signed-hash: 2066: IV8gWHx1f8eCkWsCsMOE3M8mnTbQ7IBBcEmyGDAwjdbaLu5Qm/bh06OX1npe2d3Hijxy 'yy' on a line without 'yyyy' found at line 2068: 2066: IV8gWHx1f8eCkWsCsMOE3M8mnTbQ7IBBcEmyGDAwjdbaLu5Qm/bh06OX1npe2d3Hijxy 2067: +X8vKcVE6l6To27u7A7UmGm+po9lCUSLxgtyqyn3jWhHZpc5NZpwoTCf2pAK 2068: card-hash: 7Tm/djB05pLIw3JAyy5E7A== 2069: card-number: 4811123456781234 2070: card-type: visa #x27;s destination endpoint is the endpoint with which the registration is associated, (b) the bundle has not yet been delivered subject to this registration, and Burleigh Expires July 2016 [Page 7] Internet-Draft Proposed Revised Bundle Protocol January 20166 (c) the bundle has not yet been "abandoned" (as defined below) subject to this registration. Abandonment - To abandon a bundle subject to some registration is to assert that the bundle is not deliverable subject to that registration. Delivery failure action - The delivery failure action of a registration is the action that is to be taken when a bundle that is "deliverable" subject to that registration is received at a time when the registration is in the Passive state. Destination - The destination of a bundle is the endpoint comprising the node(s) at which the bundle is to be delivered (as defined below). Minimum transmission group - The minimum transmission group of an endpoint is the minimum number of members of the endpoint (nodes) at which the bundle must have been delivered in order for the bundle to be considered delivered to the endpoint. Transmission - A transmission is an attempt by a node's BPA to cause copies of a bundle to be delivered at all nodes in the minimum reception group of some endpoint (the bundle's destination) in response to a transmission request issued by the node's application agent. Forwarding - To forward a bundle to a node is to invoke the services of a CLA in a sustained effort to cause a copy of the bundle to be received by that node. Discarding - To discard a bundle is to cease all operations on the bundle and functionally erase all references to it. The specific procedures by which this is accomplished are an implementation matter. Retention constraint - A retention constraint is an element of the state of a bundle that prevents the bundle from being discarded. That is, a bundle cannot be discarded while it has any retention constraints. Deletion - To delete a bundle is to remove unconditionally all of the bundle's retention constraints, enabling the bundle to be discarded. Custodian - A custodian of a bundle is a node that has determined that it will retain a copy of that bundle for an indefinite period Burleigh Expires July 2016 [Page 8] Internet-Draft Proposed Revised Bundle Protocol January 20166 of time, forwarding and possibly re-forwarding the bundle as appropriate, until it detects one of the conditions under which it may cease being a custodian of that bundle (discussed later). Taking custody - To take custody of a bundle is to become a custodian of that bundle. Accepting custody - To accept custody of a bundle is to take custody of the bundle, mark the bundle in such a way as to indicate this custodianship to nodes that subsequently receive copies of the bundle, and announce this custodianship to all current custodians of the bundle. Refusing custody - To "refuse custody" of a bundle is to notify all current custodians of that bundle that an opportunity to take custody of the bundle has been declined. Releasing custody - To release custody of a bundle is to cease to be a custodian of the bundle. 3.2. Discussion of BP concepts Multiple instances of the same bundle (the same unit of DTN protocol data) might exist concurrently in different parts of a network -- possibly in different representations and/or differing in some blocks -- in the memory local to one or more bundle nodes and/or in transit between nodes. In the context of the operation of a bundle node, a bundle is an instance (copy), in that node's local memory, of some bundle that is in the network. The payload for a bundle forwarded in response to a bundle transmission request is the application data unit whose location is provided as a parameter to that request. The payload for a bundle forwarded in response to reception of a bundle is the payload of the received bundle. In the most familiar case, a bundle node is instantiated as a single process running on a general-purpose computer, but in general the definition is meant to be broader: a bundle node might alternatively be a thread, an object in an object-oriented operating system, a special-purpose hardware device, etc. The manner in which the functions of the BPA are performed is wholly an implementation matter. For example, BPA functionality might be coded into each node individually; it might be implemented as a shared library that is used in common by any number of bundle nodes on a single computer; it might be implemented as a daemon whose Burleigh Expires July 2016 [Page 9] Internet-Draft Proposed Revised Bundle Protocol January 20166 services are invoked via inter-process or network communication by any number of bundle nodes on one or more computers; it might be implemented in hardware. Every CLA implements its own thin layer of protocol, interposed between BP and the (usually "top") protocol(s) of the underlying native protocol stack; this "CL protocol" may only serve to multiplex and de-multiplex bundles to and from the underlying native protocol, or it may offer additional CL-specific functionality. The manner in which a CLA sends and receives bundles is, again, wholly an implementation matter. The definitions of CLAs and CL protocols are beyond the scope of this specification. Note that the administrative element of a node's application agent may itself, in some cases, function as a convergence-layer adapter. That is, outgoing bundles may be "tunneled" through encapsulating bundles: . An outgoing bundle that has been encoded in some documented representation constitutes a byte array. This byte array may, like any other, be presented to the bundle protocol agent as an application data unit that is to be transmitted to some endpoint. . The original encoded bundle thus forms the payload of an encapsulating bundle that is forwarded using some other convergence-layer protocol(s). . When the encapsulating bundle is received, its payload is delivered to the peer application agent administrative element, which then instructs the bundle protocol agent to dispatch that original encoded bundle in the usual way. The purposes for which this technique may be useful (such as cross- domain security) are beyond the scope of this specification. The only interface between the BPA and the application-specific element of the AA is the BP service interface. But between the BPA and the administrative element of the AA there is a (conceptual) private control interface in addition to the BP service interface. This private control interface enables the BPA and the administrative element of the AA to direct each other to take action under specific circumstances In the case of a node that serves simply as a BP "router", the AA may have no application-specific element at all. The application- specific elements of other nodes' AAs may perform arbitrarily complex application functions, perhaps even offering multiplexed DTN communication services to a number of other applications. As with Burleigh Expires July 2016 [Page 10] Internet-Draft Proposed Revised Bundle Protocol January 20166 the BPA, the manner in which the AA performs its functions is wholly an implementation matter. Singletons are the most familiar sort of endpoint, but in general the endpoint notion is meant to be broader. For example, the nodes in a sensor network might constitute a set of bundle nodes that identify themselves by a single common endpoint ID and thus form a single bundle endpoint. *Note* too that a given bundle node might identify itself by multiple endpoint IDs and thus be a member of multiple bundle endpoints. The destination of every bundle is an endpoint, which may or may not be singleton. The source of every bundle is a node, identified by the endpoint ID for some singleton endpoint that contains that node. Upon reception, the processing of a bundle that has been received by a given node depends on whether or not the receiving node is registered in the bundle's destination endpoint. If it is, and if the payload of the bundle is non-fragmentary (possibly as a result of successful payload reassembly from fragmentary payloads, including the original payload of the newly received bundle), then the bundle is normally "delivered" to the node's application agent subject to the registration characterizing the node's membership in the destination endpoint. The minimum reception group of an endpoint may be any one of the following: (a) ALL of the nodes registered in an endpoint that is permitted to contain multiple nodes (in which case forwarding to the endpoint is functionally similar to "multicast" operations in the Internet, though possibly very different in implementation); (b) ANY N of the nodes registered in an endpoint that is permitted to contain multiple nodes, where N is in the range from zero to the cardinality of the endpoint; or (c) THE SOLE NODE registered in a singleton endpoint (in which case forwarding to the endpoint is functionally similar to "unicast" operations in the Internet). The nature of the minimum reception group for a given endpoint can typically be determined from the endpoint's ID. For some endpoint ID "schemes", the nature of the minimum reception group is fixed - in a manner that is defined by the scheme - for all endpoints identified under the scheme. For other schemes, the nature of the minimum reception group is indicated by some lexical feature of the "scheme-specific part" of the endpoint ID, in a manner that is defined by the scheme. Any number of transmissions may be concurrently undertaken by the bundle protocol agent of a given node. Burleigh Expires July 2016 [Page 11] Internet-Draft Proposed Revised Bundle Protocol January 20166 When the bundle protocol agent of a node determines that a bundle must be forwarded to a node (either to a node that is a member of the bundle's destination endpoint or to some intermediate forwarding node) in the course of completing the successful transmission of that bundle, it invokes the services of a CLA in a sustained effort to cause a copy of the bundle to be received by that node. Upon reception, the processing of a bundle that has been received by a given node depends on whether or not the receiving node is registered in the bundle's destination endpoint. If it is, and if the payload of the bundle is non-fragmentary (possibly as a result of successful payload reassembly from fragmentary payloads, including the original payload of the newly received bundle), then the bundle is normally delivered to the node's application agent subject to the registration characterizing the node's membership in the destination endpoint. Whenever, for some implementation-specific reason, a node&'yy' on a line without 'yyyy' found at line 2151: 2149: transaction: 123123213 2150: date: 19950121100505.nnn 2151: $$-CyberCash-End-7Tm/djB05pLIw3JAyy5E7A==-$$ 2152: 2153: ##################################################################### 'yy' on a line without 'yyyy' found at line 2193: 2191: by their CyberCash application... 2192: supported-versions: 08.win, 0.81win, 0.8mac 2193: $$-CyberCash-End-7Tm/djB05pLIw3JAyy5E7A==-$$ 2194: 2195: ##################################################################### 'yy' on a line without 'yyyy' found at line 2359: 2357: 2358: 2359: 35XiC9Yn8flE4Va14UxMf2RCR1B/XoV6AEd64KwPeCYyOYvwbRcYpRMBXFLyYgWM+ME1 2360: +yp7c66SrCBhW4Q8AJYQ+5j5uyO7uKyyq7OhrV0IMpRDPjiQXZMooLZOifJPmpvJ66hC 2361: VZuWMuA6LR+TJzWUm4sUP9Zb6zMQShedUyOPrtw1vkJXU1vZ5aI8OJAgUcLEitcD+dsY 'yy' on a line without 'yyyy' found at line 2360: 2358: 2359: 35XiC9Yn8flE4Va14UxMf2RCR1B/XoV6AEd64KwPeCYyOYvwbRcYpRMBXFLyYgWM+ME1 2360: +yp7c66SrCBhW4Q8AJYQ+5j5uyO7uKyyq7OhrV0IMpRDPjiQXZMooLZOifJPmpvJ66hC 2361: VZuWMuA6LR+TJzWUm4sUP9Zb6zMQShedUyOPrtw1vkJXU1vZ5aI8OJAgUcLEitcD+dsY 2362: Df4CzA00fC10POkJ58HZB/pSBfUrHAa+IqMHyZkV/HBi9TjTwmktJi+8T9orXS0jSvor 'yy' on a line without 'yyyy' found at line 2502: 2500: lw51IHbmo1Jj7H6wyNnRpEjy4tM73jcosBfGeQDHxgyH1uaiFNr2D+WvmuYo7eun2dsy 2501: Wve2O/FwicWHvkg5aDPsgOjzetsn1JCNZzbW 2502: $$-CyberCash-End-7Tm/djB05pLIw3JAyy5E7A==-$$ 2503: 2504: ##################################################################### 'yy' on a line without 'yyyy' found at line 2591: 2589: x-opaque: [if can't decrypt] 2590: 9/eFiJK5tLizsoeSmpW7uLS8/7iio7Wisfv38biio7uyufv3tfv35uH+7N3d9/exuKX3 2591: 5+z3vuu4oqO7srnsvvz8/venoqO0v7al/7iio7WisYy+iv7s3ff3p6KjtL+2pf/wi7nw 2592: 2593: ##################################################################### 'yy' on a line without 'yyyy' found at line 2653: 2651: x-opaque: [if can't decrypt] 2652: 9/eFiJK5tLizsoeSmpW7uLS8/7iio7Wisfv38biio7uyufv3tfv35uH+7N3d9/exuKX3 2653: 5+z3vuu4oqO7srnsvvz8/venoqO0v7al/7iio7WisYy+iv7s3ff3p6KjtL+2pf/wi7nw 2654: 2655: ##################################################################### +=+=+=+=+= File rfc1900.txt +=+=+=+=+= 1900 found at line 8: 6: 7: Network Working Group B. Carpenter 8: Request for Comments: 1900 Y. Rekhter 9: Category: Informational IAB 10: February 1996 1900 found at line 60: 58: Carpenter & Rekhter Informational [Page 1] 59: 60: RFC 1900 Renumbering Needs Work February 1996 61: 62: 1900 found at line 116: 114: Carpenter & Rekhter Informational [Page 2] 115: 116: RFC 1900 Renumbering Needs Work February 1996 117: 118: 1900 found at line 172: 170: Carpenter & Rekhter Informational [Page 3] 171: 172: RFC 1900 Renumbering Needs Work February 1996 173: 174: 1900 found at line 207: 205: Phone: +41 22 767-4967 206: Fax: +41 22 767-7155 207: Telex: 419000 cer ch 208: EMail: brian@dxcoms.cern.ch 209: +=+=+=+=+= File rfc1902.txt +=+=+=+=+= 'yy' on a line without 'yyyy' found at line 2027: 2025: Several clauses defined in this document use the UTC Time format: 2026: 2027: YYMMDDHHMMZ 2028: 2029: where: YY - last two digits of year 'yy' on a line without 'yyyy' found at line 2029: 2027: YYMMDDHHMMZ 2028: 2029: where: YY - last two digits of year 2030: MM - month (01 through 12) 2031: DD - day of month (01 through 31) UTCTime found at line 136: 134: BEGIN 135: TYPE NOTATION ::= 136: "LAST-UPDATED" value(Update UTCTime) 137: "ORGANIZATION" Text 138: "CONTACT-INFO" Text UTCTime found at line 152: 150: | Revisions Revision 151: Revision ::= 152: "REVISION" value(Update UTCTime) 153: "DESCRIPTION" Text 154: +=+=+=+=+= File rfc1910.txt +=+=+=+=+= 2000 found at line 1702: 1700: 1701: usecMIB MODULE-IDENTITY 1702: LAST-UPDATED "9601120000Z" 1703: ORGANIZATION "IETF SNMPv2 Working Group" 1704: CONTACT-INFO +=+=+=+=+= File rfc1917.txt +=+=+=+=+= century found at line 259: 257: should be noted that careful extrapolations of the current trends 258: suggest that the address space will be exhausted early in the next 259: century. 260: 261: 3. Problem +=+=+=+=+= File rfc1920.txt +=+=+=+=+= 'yy' on a line without 'yyyy' found at line 2174: 2172: The text version is sent. 2173: 2174: file /ftp/rfc/rfcnnnn.yyy where 'nnnn' is the RFC number. 2175: and 'yyy' is 'txt' or 'ps'. 2176: 'yy' on a line without 'yyyy' found at line 2175: 2173: 2174: file /ftp/rfc/rfcnnnn.yyy where 'nnnn' is the RFC number. 2175: and 'yyy' is 'txt' or 'ps'. 2176: 2177: help to get information on how to use 1900 found at line 851: 849: An Experimental protocol. 850: 851: 1900 - Renumbering Needs Work 852: 853: This is an information document and does not specify any +=+=+=+=+= File rfc1941.txt +=+=+=+=+= 2000 found at line 2826: 2824: 700 13th Street, NW 2825: Suite 950 2826: Washington, DC 20005 2827: Phone: 202-434-8954 2828: EMail: sellers@quest.arc.nasa.gov +=+=+=+=+= File rfc1945.txt +=+=+=+=+= 2-digit found at line 500: 498: Specific repetition: "<n>(element)" is equivalent to 499: "<n>*<n>(element)"; that is, exactly <n> occurrences of 500: (element). Thus 2DIGIT is a 2-digit number, and 3ALPHA is a 501: string of three alphabetic characters. 502: 2digit found at line 500: 498: Specific repetition: "<n>(element)" is equivalent to 499: "<n>*<n>(element)"; that is, exactly <n> occurrences of 500: (element). Thus 2DIGIT is a 2-digit number, and 3ALPHA is a 501: string of three alphabetic characters. 502: 2digit found at line 872: 870: asctime-date = wkday SP date3 SP time SP 4DIGIT 871: 872: date1 = 2DIGIT SP month SP 4DIGIT 873: ; day month year (e.g., 02 Jun 1982) 874: date2 = 2DIGIT "-" month "-" 2DIGIT 2digit found at line 874: 872: date1 = 2DIGIT SP month SP 4DIGIT 873: ; day month year (e.g., 02 Jun 1982) 874: date2 = 2DIGIT "-" month "-" 2DIGIT 875: ; day-month-year (e.g., 02-Jun-82) 876: date3 = month SP ( 2DIGIT | ( SP 1DIGIT )) 2digit found at line 876: 874: date2 = 2DIGIT "-" month "-" 2DIGIT 875: ; day-month-year (e.g., 02-Jun-82) 876: date3 = month SP ( 2DIGIT | ( SP 1DIGIT )) 877: ; month day (e.g., Jun 2) 878: 2digit found at line 879: 877: ; month day (e.g., Jun 2) 878: 879: time = 2DIGIT ":" 2DIGIT ":" 2DIGIT 880: ; 00:00:00 - 23:59:59 881: +=+=+=+=+= File rfc1967.txt +=+=+=+=+= 'yy' on a line without 'yyyy' found at line 276: 274: +-----+----....................----+ 275: 276: where: C0 and 80 are representative LZS-DCP headers; nn, xx, yy, 277: and zz are values determined by the packet's context. 278: +=+=+=+=+= File rfc1980.txt +=+=+=+=+= century found at line 301: 299: ALT="Our products"> 300: <AREA SHAPE=RECT COORDS="0,51,100,100 HREF="technology.html" 301: ALT="Technology for the next century"> 302: </MAP's BPA finds it impossible to immediately deliver a bundle that is deliverable, delivery of the bundle has failed. In this event, the delivery failure action associated with the applicable registration must be taken. Delivery failure action MUST be one of the following: . defer delivery of the bundle subject to this registration until (a) this bundle is the least recently received of all bundles currently deliverable subject to this registration and (b) either the registration is polled or else the registration is in the Active state; or . abandon delivery of the bundle subject to this registration. An additional implementation-specific delivery deferral procedure MAY optionally be associated with the registration. While the state of a registration is Passive, reception of a bundle that is deliverable subject to this registration MUST cause delivery of the bundle to be abandoned or deferred as mandated by the registration's current delivery failure action; in the latter case, any additional delivery deferral procedure associated with the registration MUST also be performed. While the state of a registration is Active, reception of a bundle that is deliverable subject to this registration MUST cause the bundle to be delivered automatically as soon as it is the next bundle that is due for delivery according to the BPA's bundle delivery scheduling policy, an implementation matter. Burleigh Expires July 2016 [Page 12] Internet-Draft Proposed Revised Bundle Protocol January 20166 Normally only registrations' registered delivery failure actions cause deliveries to be abandoned. Custody of a bundle MAY be taken only if the destination of the bundle is a singleton endpoint. Custody MAY be released only when either (a) notification is received that some other node has accepted custody of the same bundle; (b) notification is received that the bundle has been delivered at the (sole) node registered in the bundle's destination endpoint; (c) the current custodian chooses to fragment the bundle, releasing custody of the original bundle and taking custody of the fragments instead, or (d) the bundle is explicitly deleted for some reason, such as lifetime expiration. The custody transfer mechanism in BP is primarily intended as a means of recovering from forwarding failures. When a bundle arrives at a node from which it must be forwarded, but forwarding is impossible, BP must recover from this error. BP can "return" the bundle back toward some node for forwarding along some other path in the network, or else it can instead send a small "signal" bundle back to such a node, in the event that this node has retained a copy of the bundle ("taken custody") and is therefore able to re-forward the bundle without receiving a copy. Custody transfer sharply reduces the network traffic required for recovery from forwarding failures, at the cost of increased buffer occupancy and state management at the custodial nodes. Note that custodial re-forwarding can also be initiated by expiration of a timer prior to reception of a custody acceptance or refusal signal. Since the absence of a custody acceptance signal might be caused by failure to receive the bundle, rather than only a disinclination to take custody, custody transfer can additionally serve as an automated retransmission mechanism. However, because custody transfer's only remedy for loss of any part of a bundle is retransmission of the entire bundle (not just the lost portion), custody transfer is a less efficient automated retransmission mechanism than the reliable transport protocols that are typically available at the convergence layer; configuring BPAs to use reliable convergence-layer protocols between nodes is generally the best means of ensuring bundle delivery at the destination node(s). But there are some use cases (typically involving unidirectional links) in which custody transfer in BP may be a more cost-effective solution for reliable transmission between two BP agents than invoking retransmission protocols at the convergence layer. Burleigh Expires July 2016 [Page 13] Internet-Draft Proposed Revised Bundle Protocol January 20166 3.3. Services Offered by Bundle Protocol Agents The BPA of each node is expected to provide the following services to the node's application agent: . commencing a registration (registering the node in an endpoint); . terminating a registration; . switching a registration between Active and Passive states; . transmitting a bundle to an identified bundle endpoint; . canceling a transmission; . polling a registration that is in the Passive state; . delivering a received bundle. 4. Bundle Format NOTE that only the abstract structures of blocks are defined here. The specific bitstream that is emitted when a CLA sends a bundle will be dictated by the applicable bundle representation specification to which the sending and receiving nodes conform, an implementation matter. It is important to note that not all BP implementations are required to implement all bundle representation specifications. The BP implementations used to instantiate nodes in a given network must be chosen with care in order for every node to be able to exchange bundles with every other node. Bundle representation specifications are beyond the scope of this document. Each bundle SHALL be a concatenated sequence of at least two blocks. The first block in the sequence MUST be a primary bundle block, and the bundle MUST have exactly one primary bundle block. Additional bundle protocol blocks of other types MAY follow the primary block to support extensions to the bundle protocol, such as the Bundle Security Protocol [BPSEC]. Exactly one of the blocks in the sequence MUST be a payload block, and the payload block MUST be the last block in the sequence. 4.1. Bundle Processing Control Flags Bundle processing control flags assert properties of the bundle as a whole rather than of any particular block of the bundle. They are conveyed in the primary block of the bundle. The following properties are asserted by the bundle processing control flags: . The bundle is a fragment. (Boolean) Burleigh Expires July 2016 [Page 14] Internet-Draft Proposed Revised Bundle Protocol January 20166 . The bundle's payload is an administrative record. (Boolean) . The bundle must not be fragmented. (Boolean) . Custody transfer is requested for this bundle. (Boolean) . The bundle's destination endpoint is a singleton. (Boolean) . Acknowledgment by the user application is requested. (Boolean) . Status time is requested in all status reports. (Boolean) . Type of CRC that is present in the bundle's primary block. (An unsigned integer CRC type code; 0 indicates that the block contains no CRC, other valid values TBD) . Flags requesting types of status reports (all Boolean): o Request reporting of bundle reception. o Request reporting of custody acceptance. o Request reporting of bundle forwarding. o Request reporting of bundle delivery. o Request reporting of bundle deletion. If the bundle processing control flags indicate that the bundle's application data unit is an administrative record, then the custody transfer requested flag value must be zero and all status report request flag values must be zero. If the custody transfer requested flag is 1, then the source node is requesting that every receiving node accept custody of the bundle. If the bundle's source node is omitted (i.e., the source endpoint ID is the null endpoint, which has no members as discussed below), then the bundle is not uniquely identifiable and all bundle protocol features that rely on bundle identity must therefore be disabled: the bundle's custody transfer requested flag value must be zero, the "Bundle must not be fragmented" flag value must be 1, and all status report request flag values must be zero. Burleigh Expires July 2016 [Page 15] Internet-Draft Proposed Revised Bundle Protocol January 20166 4.2. Block Processing Control Flags The block processing control flags assert properties of individual bundle blocks other than the primary block. They are conveyed in the header of the block to which they pertain. The following properties are asserted by the block processing control flags: . This block must be replicated in every fragment. (Boolean) . Status report must be transmitted if this block can't be processed. (Boolean) . Block must be removed from the bundle if it can't be processed. (Boolean) . Bundle must be deleted if this block can't be processed. (Boolean) For each bundle whose bundle processing control flags indicate that the bundle's application data unit is an administrative record, the value of the "Transmit status report if block can't be processed" flag in every block of the bundle other than the primary block must be zero. 4.3. Identifiers 4.3.1. Endpoint ID The destinations of bundles are bundle endpoints, identified by text strings termed "endpoint IDs" (see Section 3.1). Each endpoint ID (EID) conveyed in any bundle block takes the form of a Uniform Resource Identifier (URI; [URI]). As such, each endpoint ID can be characterized as having this general structure: < scheme name > : < scheme-specific part, or "SSP" > The scheme identified by the < scheme name > in an endpoint ID is a set of syntactic and semantic rules that fully explain how to parse and interpret the SSP. The set of allowable schemes is effectively unlimited. Any scheme conforming to [URIREG] may be used in a bundle protocol endpoint ID. Note that, although endpoint IDs are URIs, implementations of the BP service interface may support expression of endpoint IDs in some Burleigh Expires July 2016 [Page 16] Internet-Draft Proposed Revised Bundle Protocol January 20166 internationalized manner (e.g., Internationalized Resource Identifiers (IRIs); see [RFC3987]). Note also that the representation of an EID in the bitstream that is emitted when a CLA sends a bundle will be dictated by the applicable bundle representation specification to which the sending and receiving nodes conform, an implementation matter. The endpoint ID "dtn:none" identifies the "null endpoint", the endpoint that by definition never has any members. 4.3.2. Node ID For many purposes of the Bundle Protocol it is important to identify the node that is operative in some context. As discussed in 3.1 above, nodes are distinct from endpoints; specifically, an endpoint is a set of zero or more nodes. But rather than define a separate namespace for node identifiers, we instead use endpoint identifiers to identify nodes, subject to the following restrictions: . Every node MUST be a member of at least one singleton endpoint. . The EID of any singleton endpoint of which a node is a member MAY be used to identify that node. A "node ID" is an EID that is used in this way. . A node's membership in a given singleton endpoint MUST be sustained at least until the nominal operation of the Bundle Protocol no longer depends on the identification of that node using that endpoint's ID. 4.4. Contents of Bundle Blocks This section describes the contents of the primary block in detail and the contents of all non-primary blocks in general. Rules for processing these blocks appear in Section 5 of this document. Note that supplementary DTN protocol specifications (including, but not restricted to, the Bundle Security Protocol [BPSEC]) may require that BP implementations conforming to those protocols construct and process additional blocks. 4.4.1. Primary Bundle Block The primary bundle block contains the basic information needed to forward bundles to their destinations. The fields of the primary bundle block are: Burleigh Expires July 2016 [Page 17] Internet-Draft Proposed Revised Bundle Protocol January 20166 Version: An unsigned integer value indicating the version of the bundle protocol that constructed this block. The present document describes version 7 of the bundle protocol. Bundle Processing Control Flags: The Bundle Processing Control Flags are discussed in Section 4.1 above. Destination EID: The Destination EID field identifies the bundle endpoint that is the bundle's destination, i.e., the endpoint that contains the node(s) at which the bundle is to be delivered. Source node ID: The Source node ID field identifies the bundle node at which the bundle was initially transmitted, except that Source node ID may be the null endpoint ID in the event that the bundle's source chooses to remain anonymous. Report-to EID: The Report-to EID field identifies the bundle endpoint to which status reports pertaining to the forwarding and delivery of this bundle are to be transmitted. Creation Timestamp: The creation timestamp is a pair of unsigned integers that, together with the source node ID and (if the bundle is a fragment) the fragment offset and payload length, serve to identify the bundle. The first of these integers is the bundle's creation time, while the second is the bundle's creation timestamp sequence number. Bundle creation time is the time - expressed in seconds since the start of the year 2000, on the Coordinated Universal Time (UTC) scale [UTC] - at which the transmission request was received that resulted in the creation of the bundle. Sequence count is the latest value (as of the time at which that transmission request was received) of a monotonically increasing positive integer counter managed by the source node's bundle protocol agent that may be reset to zero whenever the current time advances by one second. For nodes that lack accurate clocks (that is, nodes that are not at all moments able to determine the current UTC time to within 30 seconds), bundle creation time MUST be set to zero and the counter used as the source of the bundle sequence count MUST NEVER be reset to zero. In any case, a source Bundle Protocol Agent must never create two distinct bundles with the same source node ID and bundle creation timestamp. The combination of source node ID and bundle creation timestamp serves to identify a single transmission request, enabling it to be acknowledged by the receiving application (provided the source node ID is not the null endpoint ID). Lifetime: The lifetime field is an unsigned integer that indicates the time at which the bundle's payload will no longer be useful, encoded as a number of seconds past the creation time. When a Burleigh Expires July 2016 [Page 18] Internet-Draft Proposed Revised Bundle Protocol January 20166 bundle's age exceeds its lifetime, bundle nodes need no longer retain or forward the bundle; the bundle SHOULD be deleted from the network. The CRC field of the Primary Bundle Block is present only if the CRC type field in the block's processing flags field is non-zero. Fragment Offset: If and only if the Bundle Processing Control Flags of this Primary block indicate that the bundle is a fragment, then the Fragment Offset field SHALL be an unsigned integer indicating the offset from the start of the original application data unit at which the bytes comprising the payload of this bundle were located. If not, then the Fragment Offset field SHALL be omitted from the block. Total Application Data Unit Length: If and only if the Bundle Processing Control Flags of this Primary block indicate that the bundle is a fragment, then the Total Application Data Unit Length field SHALL be an unsigned integer indicating the total length of the original application data unit of which this bundle's payload is a part. If not, then the Total Application Data Unit Length field SHALL be omitted from the block. If and only if the CRC type in the Bundle Processing Control Flags of this Primary block is non-zero, a CRC SHALL be present the primary block. The length and nature of the CRC SHALL be as indicated by the CRC type. The CRC SHALL be computed over the concatenation of all bytes of the primary block including the CRC field itself, which for this purpose is temporarily populated with the value zero. 4.4.2. Canonical Bundle Block Format Every bundle block of every type other than the primary bundle block comprises the following fields, in this order: . Block type code, an unsigned integer. Bundle block type code 1 indicates that the block is a bundle payload block. Block type codes 2 through 9 are explicitly reserved as noted later in this specification. Block type codes 192 through 255 are not reserved and are available for private and/or experimental use. All other block type code values are reserved for future use. . Block number, an unsigned integer. The block number uniquely identifies the block within the bundle, enabling blocks (notably bundle security protocol blocks) to explicitly reference other blocks in the same bundle. Block numbers need not be in continuous sequence, and blocks need not appear in Burleigh Expires July 2016 [Page 19] Internet-Draft Proposed Revised Bundle Protocol January 20166 block number sequence in the bundle. The block number of the payload block is always zero. . Block processing control flags as discussed above. . Block data length, an unsigned integer. The block data length field contains the aggregate length of all remaining fields of the block, i.e., the block-type-specific data fields. . Block-type-specific data fields, whose nature and order are type-specific and whose aggregate length in octets is the value of the block data length field. For the Payload Block in particular (block type 1), there SHALL be exactly one block- type-specific data field, the "payload", i.e., the application data carried by this bundle. 4.5. Extension Blocks "Extension blocks> 303: +=+=+=+=+= File rfc1997.txt +=+=+=+=+= 2000 found at line 130: 128: 690 may define research, educational and commercial community values 129: that may be used for policy routing as defined by the operators of 130: that AS using community attribute values 0x02B20000 through 131: 0x02B2FFFF). 132: +=+=+=+=+= File rfc1999.txt +=+=+=+=+= 1900 found at line 14: 12: Request for Comments Summary 13: 14: RFC Numbers 1900-1999 15: 16: Status of This Memo 1900 found at line 18: 16: Status of This Memo 17: 18: This RFC is a slightly annotated list of the 100 RFCs from RFC 1900 19: through RFCs 1999. This is a status report on these RFCs. This memo 20: provides information for the Internet community. It does not specify 1900 found at line 60: 58: Elliott Informational [Page 1] 59: 60: RFC 1999 Summary of 1900-1999 January 1997 61: 62: 1900 found at line 116: 114: Elliott Informational [Page 2] 115: 116: RFC 1999 Summary of 1900-1999 January 1997 117: 118: 1900 found at line 172: 170: Elliott Informational [Page 3] 171: 172: RFC 1999 Summary of 1900-1999 January 1997 173: 174: 1900 found at line 228: 226: Elliott Informational [Page 4] 227: 228: RFC 1999 Summary of 1900-1999 January 1997 229: 230: 1900 found at line 284: 282: Elliott Informational [Page 5] 283: 284: RFC 1999 Summary of 1900-1999 January 1997 285: 286: 1900 found at line 340: 338: Elliott Informational [Page 6] 339: 340: RFC 1999 Summary of 1900-1999 January 1997 341: 342: 1900 found at line 396: 394: Elliott Informational [Page 7] 395: 396: RFC 1999 Summary of 1900-1999 January 1997 397: 398: 1900 found at line 452: 450: Elliott Informational [Page 8] 451: 452: RFC 1999 Summary of 1900-1999 January 1997 453: 454: 1900 found at line 508: 506: Elliott Informational [Page 9] 507: 508: RFC 1999 Summary of 1900-1999 January 1997 509: 510: 1900 found at line 564: 562: Elliott Informational [Page 10] 563: 564: RFC 1999 Summary of 1900-1999 January 1997 565: 566: 1900 found at line 620: 618: Elliott Informational [Page 11] 619: 620: RFC 1999 Summary of 1900-1999 January 1997 621: 622: 1900 found at line 676: 674: Elliott Informational [Page 12] 675: 676: RFC 1999 Summary of 1900-1999 January 1997 677: 678: 1900 found at line 732: 730: Elliott Informational [Page 13] 731: 732: RFC 1999 Summary of 1900-1999 January 1997 733: 734: 1900 found at line 788: 786: Elliott Informational [Page 14] 787: 788: RFC 1999 Summary of 1900-1999 January 1997 789: 790: 1900 found at line 844: 842: Elliott Informational [Page 15] 843: 844: RFC 1999 Summary of 1900-1999 January 1997 845: 846: 1900 found at line 900: 898: Elliott Informational [Page 16] 899: 900: RFC 1999 Summary of 1900-1999 January 1997 901: 902: 1900 found at line 956: 954: Elliott Informational [Page 17] 955: 956: RFC 1999 Summary of 1900-1999 January 1997 957: 958: 1900 found at line 1012: 1010: Elliott Informational [Page 18] 1011: 1012: RFC 1999 Summary of 1900-1999 January 1997 1013: 1014: 1900 found at line 1068: 1066: Elliott Informational [Page 19] 1067: 1068: RFC 1999 Summary of 1900-1999 January 1997 1069: 1070: 1900 found at line 1095: 1093: 1094: 1095: 1900 Carpenter Feb 96 Renumbering Needs Work 1096: 1097: Hosts in an IP network are identified by IP addresses, and the IP +=+=+=+=+= File rfc2000.txt +=+=+=+=+= 'yy' on a line without 'yyyy' found at line 3070: 3068: The text version is sent. 3069: 3070: file /ftp/rfc/rfcnnnn.yyy where 'nnnn' is the RFC number. 3071: and 'yyy' is 'txt' or 'ps'. 3072: 'yy' on a line without 'yyyy' found at line 3071: 3069: 3070: file /ftp/rfc/rfcnnnn.yyy where 'nnnn' is the RFC number. 3071: and 'yyy' is 'txt' or 'ps'. 3072: 3073: help to get information on how to use 1900 found at line 1264: 1262: This memo. 1263: 1264: 1999 - Request for Comments Summary RFC Numbers 1900-1999 1265: 1266: This is an information document and does not specify any 2000 found at line 8: 6: 7: Network Working Group Internet Architecture Board 8: Request for Comments: 2000 J. Postel, Editor 9: Obsoletes: 1920, 1880, 1800, 1780, 1720, February 1997 10: 1610, 1600, 1540, 1500, 1410, 1360, 2000 found at line 60: 58: Internet Architecture Board Standards Track [Page 1] 59: 60: RFC 2000 Internet Standards February 1997 61: 62: 2000 found at line 116: 114: Internet Architecture Board Standards Track [Page 2] 115: 116: RFC 2000 Internet Standards February 1997 117: 118: 2000 found at line 172: 170: Internet Architecture Board Standards Track [Page 3] 171: 172: RFC 2000 Internet Standards February 1997 173: 174: 2000 found at line 228: 226: Internet Architecture Board Standards Track [Page 4] 227: 228: RFC 2000 Internet Standards February 1997 229: 230: 2000 found at line 284: 282: Internet Architecture Board Standards Track [Page 5] 283: 284: RFC 2000 Internet Standards February 1997 285: 286: 2000 found at line 340: 338: Internet Architecture Board Standards Track [Page 6] 339: 340: RFC 2000 Internet Standards February 1997 341: 342: 2000 found at line 396: 394: Internet Architecture Board Standards Track [Page 7] 395: 396: RFC 2000 Internet Standards February 1997 397: 398: 2000 found at line 452: 450: Internet Architecture Board Standards Track [Page 8] 451: 452: RFC 2000 Internet Standards February 1997 453: 454: 2000 found at line 508: 506: Internet Architecture Board Standards Track [Page 9] 507: 508: RFC 2000 Internet Standards February 1997 509: 510: 2000 found at line 564: 562: Internet Architecture Board Standards Track [Page 10] 563: 564: RFC 2000 Internet Standards February 1997 565: 566: 2000 found at line 620: 618: Internet Architecture Board Standards Track [Page 11] 619: 620: RFC 2000 Internet Standards February 1997 621: 622: 2000 found at line 676: 674: Internet Architecture Board Standards Track [Page 12] 675: 676: RFC 2000 Internet Standards February 1997 677: 678: 2000 found at line 732: 730: Internet Architecture Board Standards Track [Page 13] 731: 732: RFC 2000 Internet Standards February 1997 733: 734: 2000 found at line 788: 786: Internet Architecture Board Standards Track [Page 14] 787: 788: RFC 2000 Internet Standards February 1997 789: 790: 2000 found at line 844: 842: Internet Architecture Board Standards Track [Page 15] 843: 844: RFC 2000 Internet Standards February 1997 845: 846: 2000 found at line 900: 898: Internet Architecture Board Standards Track [Page 16] 899: 900: RFC 2000 Internet Standards February 1997 901: 902: 2000 found at line 956: 954: Internet Architecture Board Standards Track [Page 17] 955: 956: RFC 2000 Internet Standards February 1997 957: 958: 2000 found at line 1012: 1010: Internet Architecture Board Standards Track [Page 18] 1011: 1012: RFC 2000 Internet Standards February 1997 1013: 1014: 2000 found at line 1068: 1066: Internet Architecture Board Standards Track [Page 19] 1067: 1068: RFC 2000 Internet Standards February 1997 1069: 1070: 2000 found at line 1124: 1122: Internet Architecture Board Standards Track [Page 20] 1123: 1124: RFC 2000 Internet Standards February 1997 1125: 1126: 2000 found at line 1180: 1178: Internet Architecture Board Standards Track [Page 21] 1179: 1180: RFC 2000 Internet Standards February 1997 1181: 1182: 2000 found at line 1236: 1234: Internet Architecture Board Standards Track [Page 22] 1235: 1236: RFC 2000 Internet Standards February 1997 1237: 1238: 2000 found at line 1260: 1258: A Proposed Standard protocol. 1259: 1260: 2000 - Internet Official Protocol Standards 1261: 1262: This memo. 2000 found at line 1292: 1290: Internet Architecture Board Standards Track [Page 23] 1291: 1292: RFC 2000 Internet Standards February 1997 1293: 1294: 2000 found at line 1348: 1346: Internet Architecture Board Standards Track [Page 24] 1347: 1348: RFC 2000 Internet Standards February 1997 1349: 1350: 2000 found at line 1404: 1402: Internet Architecture Board Standards Track [Page 25] 1403: 1404: RFC 2000 Internet Standards February 1997 1405: 1406: 2000 found at line 1460: 1458: Internet Architecture Board Standards Track [Page 26] 1459: 1460: RFC 2000 Internet Standards February 1997 1461: 1462: 2000 found at line 1516: 1514: Internet Architecture Board Standards Track [Page 27] 1515: 1516: RFC 2000 Internet Standards February 1997 1517: 1518: 2000 found at line 1572: 1570: Internet Architecture Board Standards Track [Page 28] 1571: 1572: RFC 2000 Internet Standards February 1997 1573: 1574: 2000 found at line 1628: 1626: Internet Architecture Board Standards Track [Page 29] 1627: 1628: RFC 2000 Internet Standards February 1997 1629: 1630: 2000 found at line 1684: 1682: Internet Architecture Board Standards Track [Page 30] 1683: 1684: RFC 2000 Internet Standards February 1997 1685: 1686: 2000 found at line 1740: 1738: Internet Architecture Board Standards Track [Page 31] 1739: 1740: RFC 2000 Internet Standards February 1997 1741: 1742: 2000 found at line 1796: 1794: Internet Architecture Board Standards Track [Page 32] 1795: 1796: RFC 2000 Internet Standards February 1997 1797: 1798: 2000 found at line 1852: 1850: Internet Architecture Board Standards Track [Page 33] 1851: 1852: RFC 2000 Internet Standards February 1997 1853: 1854: 2000 found at line 1859: 1857: Protocol Name Status RFC STD * 1858: ======== ===================================== ======== ==== === = 1859: -------- Internet Official Protocol Standards Req 2000 1 1860: -------- Assigned Numbers Req 1700 2 1861: -------- Host Requirements - Communications Req 1122 3 2000 found at line 1908: 1906: Internet Architecture Board Standards Track [Page 34] 1907: 1908: RFC 2000 Internet Standards February 1997 1909: 1910: 2000 found at line 1964: 1962: Internet Architecture Board Standards Track [Page 35] 1963: 1964: RFC 2000 Internet Standards February 1997 1965: 1966: 2000 found at line 2020: 2018: Internet Architecture Board Standards Track [Page 36] 2019: 2020: RFC 2000 Internet Standards February 1997 2021: 2022: 2000 found at line 2076: 2074: Internet Architecture Board Standards Track [Page 37] 2075: 2076: RFC 2000 Internet Standards February 1997 2077: 2078: 2000 found at line 2132: 2130: Internet Architecture Board Standards Track [Page 38] 2131: 2132: RFC 2000 Internet Standards February 1997 2133: 2134: 2000 found at line 2188: 2186: Internet Architecture Board Standards Track [Page 39] 2187: 2188: RFC 2000 Internet Standards February 1997 2189: 2190: 2000 found at line 2244: 2242: Internet Architecture Board Standards Track [Page 40] 2243: 2244: RFC 2000 Internet Standards February 1997 2245: 2246: 2000 found at line 2300: 2298: Internet Architecture Board Standards Track [Page 41] 2299: 2300: RFC 2000 Internet Standards February 1997 2301: 2302: 2000 found at line 2356: 2354: Internet Architecture Board Standards Track [Page 42] 2355: 2356: RFC 2000 Internet Standards February 1997 2357: 2358: 2000 found at line 2412: 2410: Internet Architecture Board Standards Track [Page 43] 2411: 2412: RFC 2000 Internet Standards February 1997 2413: 2414: 2000 found at line 2468: 2466: Internet Architecture Board Standards Track [Page 44] 2467: 2468: RFC 2000 Internet Standards February 1997 2469: 2470: 2000 found at line 2524: 2522: Internet Architecture Board Standards Track [Page 45] 2523: 2524: RFC 2000 Internet Standards February 1997 2525: 2526: 2000 found at line 2580: 2578: Internet Architecture Board Standards Track [Page 46] 2579: 2580: RFC 2000 Internet Standards February 1997 2581: 2582: 2000 found at line 2636: 2634: Internet Architecture Board Standards Track [Page 47] 2635: 2636: RFC 2000 Internet Standards February 1997 2637: 2638: 2000 found at line 2692: 2690: Internet Architecture Board Standards Track [Page 48] 2691: 2692: RFC 2000 Internet Standards February 1997 2693: 2694: 2000 found at line 2748: 2746: Internet Architecture Board Standards Track [Page 49] 2747: 2748: RFC 2000 Internet Standards February 1997 2749: 2750: 2000 found at line 2804: 2802: Internet Architecture Board Standards Track [Page 50] 2803: 2804: RFC 2000 Internet Standards February 1997 2805: 2806: 2000 found at line 2860: 2858: Internet Architecture Board Standards Track [Page 51] 2859: 2860: RFC 2000 Internet Standards February 1997 2861: 2862: 2000 found at line 2916: 2914: Internet Architecture Board Standards Track [Page 52] 2915: 2916: RFC 2000 Internet Standards February 1997 2917: 2918: 2000 found at line 2972: 2970: Internet Architecture Board Standards Track [Page 53] 2971: 2972: RFC 2000 Internet Standards February 1997 2973: 2974: 2000 found at line 3028: 3026: Internet Architecture Board Standards Track [Page 54] 3027: 3028: RFC 2000 Internet Standards February 1997 3029: 3030: 2000 found at line 3084: 3082: Internet Architecture Board Standards Track [Page 55] 3083: 3084: RFC 2000 Internet Standards February 1997 3085: 3086: +=+=+=+=+= File rfc2007.txt +=+=+=+=+= 2000 found at line 1156: 1154: 1155: Access-Type: gopher 1156: URL: <URL:gopher://gopher.cic.net:2000/11/hunt> 1157: 1158: Access-Type: www +=+=+=+=+= File rfc2015.txt +=+=+=+=+= 'yy' on a line without 'yyyy" are all blocks other than the primary and payload blocks. Because not all extension blocks are defined in the Bundle Protocol specification (the present document), not all nodes conforming to this specification will necessarily instantiate Bundle Protocol implementations that include procedures for processing (that is, recognizing, parsing, acting on, and/or producing) all extension blocks. It is therefore possible for a node to receive a bundle that includes extension blocks that the node cannot process. The values of the block processing control flags indicate the action to be taken by the bundle protocol agent when this is the case. The extension blocks of the Bundle Security Protocol (block types 2 and 3) are defined separately in the Bundle Security Protocol specification (work in progress). The following extension blocks are defined in the current document. 4.5.1. Current Custodian The Current Custodian block, block type 5, identifies a node that is known to have accepted custody of the bundle. The block-type- specific data of this block is the node ID of a custodian. The bundle MAY contain one or more occurrences of this type of block. 4.5.2. Flow Label The Flow Label block, block type 6, indicates the flow label that is intended to govern transmission of the bundle by convergence-layer adapters. The syntax and semantics of BP flow labels are beyond the scope of this document. Burleigh Expires July 2016 [Page 20] Internet-Draft Proposed Revised Bundle Protocol January 20166 4.5.3. Previous Node ID The Previous Node ID block, block type 7, identifies the node that forwarded this bundle to the local node; its block-type-specific data is the node ID of that node. If the local node is the source of the bundle, then the bundle MUST NOT contain any Previous Node ID block. Otherwise the bundle MUST contain one (1) occurrence of this type of block. If present, the Previous Node ID block MUST be the FIRST block following the primary block, as the processing of other extension blocks may depend on its value. 4.5.4. Bundle Age The Bundle Age block, block type 8, contains the number of seconds that have elapsed between the time the bundle was created and time at which it was most recently forwarded. It is intended for use by nodes lacking access to an accurate clock, to aid in determining the time at which a bundle's lifetime expires. The block-type-specific data of this block is an unsigned integer containing the age of the bundle (the sum of all known intervals of the bundle's residence at forwarding nodes, up to the time at which the bundle was most recently forwarded) in seconds. If the bundle's creation time is zero, then the bundle MUST contain exactly one (1) occurrence of this type of block; otherwise, the bundle MAY contain at most one (1) occurrence of this type of block. 4.5.5. Hop Count The Hop Count block, block type 9, contains two unsigned integers, hop limit and hop count. It is mainly intended as a safety mechanism, a means of identifying bundles for removal from the network that can never be delivered due to a persistent forwarding error: a bundle may be deleted when its hop count exceeds its hop limit. Procedures for determining the appropriate hop limit for a block are beyond the scope of this specification. A bundle MAY contain at most one (1) occurrence of this type of block. 5. Bundle Processing The bundle processing procedures mandated in this section and in Section 6 govern the operation of the Bundle Protocol Agent and the Application Agent administrative element of each bundle node. They are neither exhaustive nor exclusive. Supplementary DTN protocol specifications (including, but not restricted to, the Bundle Security Protocol [BPSEC]) may augment, override, or supersede the mandates of this document. Burleigh Expires July 2016 [Page 21] Internet-Draft Proposed Revised Bundle Protocol January 20166 5.1. Generation of Administrative Records All transmission of bundles is in response to bundle transmission requests presented by nodes' application agents. When required to "generate" an administrative record (such as a bundle status report or a custody signal), the bundle protocol agent itself is responsible for causing a new bundle to be transmitted, conveying that record. In concept, the bundle protocol agent discharges this responsibility by directing the administrative element of the node's application agent to construct the record and request its transmission as detailed in Section 6 below. In practice, the manner in which administrative record generation is accomplished is an implementation matter, provided the constraints noted in Section 6 are observed. Under some circumstances, the requesting of status reports could result in an unacceptable increase in the bundle traffic in the network. For this reason, the generation of status reports is mandatory only in one case, the deletion of a bundle for which custody transfer is requested. In all other cases, the decision on whether or not to generate a requested status report is left to the discretion of the bundle protocol agent. Mechanisms that could assist in making such decisions, such as pre-placed agreements authorizing the generation of status reports under specified circumstances, are beyond the scope of this specification. Notes on administrative record terminology: . A "bundle reception status report" is a bundle status report with the "reporting node received bundle" flag set to 1. . A "custody acceptance status report" is a bundle status report with the "reporting node accepted custody of bundle" flag set to 1. . A "bundle forwarding status report" is a bundle status report with the "reporting node forwarded the bundle" flag set to 1. . A "bundle delivery status report" is a bundle status report with the "reporting node delivered the bundle" flag set to 1. . A "bundle deletion status report" is a bundle status report with the "reporting node deleted the bundle" flag set to 1. . A "Succeeded" custody signal is a custody signal with the "custody transfer succeeded" flag set to 1. . A "Failed" custody signal is a custody signal with the "custody transfer succeeded" flag set to zero. . A "current custodian" of a bundle is a node identified in a Current Custodian extension block of that bundle. Burleigh Expires July 2016 [Page 22] Internet-Draft Proposed Revised Bundle Protocol January 20166 5.2. Bundle Transmission The steps in processing a bundle transmission request are: Step 1: If custody transfer is requested for this bundle transmission then the destination MUST be a singleton endpoint. If, moreover, custody acceptance by the source node is required but the conditions under which custody of the bundle may be accepted are not satisfied, then the request cannot be honored and all remaining steps of this procedure MUST be skipped. Step 2: Transmission of the bundle is initiated. An outbound bundle MUST be created per the parameters of the bundle transmission request, with the retention constraint "Dispatch pending". The source node ID of the bundle MUST be either the null endpoint ID, indicating that the source of the bundle is anonymous, or else the EID of a singleton endpoint whose only member is the node of which the BPA is a component. Step 3: Processing proceeds from Step 1 of Section 5.4. 5.3. Bundle Dispatching The steps in dispatching a bundle are: Step 1: If the bundle's destination endpoint is an endpoint of which the node is a member, the bundle delivery procedure defined in Section 5.7 MUST be followed. Step 2: Processing proceeds from Step 1 of Section 5.4. 5.4. Bundle Forwarding The steps in forwarding a bundle are: Step 1: The retention constraint "Forward pending" MUST be added to the bundle, and the bundle's "Dispatch pending" retention constraint MUST be removed. Step 2: The bundle protocol agent MUST determine whether or not forwarding is contraindicated for any of the reasons listed in Figure 12. In particular: . The bundle protocol agent MUST determine which node(s) to forward the bundle to. The bundle protocol agent MAY choose either to forward the bundle directly to its destination node(s) (if possible) or to forward the bundle to some other Burleigh Expires July 2016 [Page 23] Internet-Draft Proposed Revised Bundle Protocol January 20166 node(s) for further forwarding. The manner in which this decision is made may depend on the scheme name in the destination endpoint ID and/or on other state but in any case is beyond the scope of this document. If the BPA elects to forward the bundle to some other node(s) for further forwarding but finds it impossible to select any node(s) to forward the bundle to, then forwarding is contraindicated. o o . Provided the bundle protocol agent succeeded in selecting the node(s) to forward the bundle to, the bundle protocol agent MUST select the convergence layer adapter(s) whose services will enable the node to send the bundle to those nodes. The manner in which specific appropriate convergence layer adapters are selected is beyond the scope of this document. If the agent finds it impossible to select any appropriate convergence layer adapter(s) to use in forwarding this bundle, then forwarding is contraindicated. . Provided the bundle protocol agent succeeded in selecting the node(s) to forward the bundle to and additionally succeeded in selecting the appropriate convergence layer adapter(s), the bundle protocol agent MUST determine the applicable bundle representation by which the bundle must be encoded when sent to each such node so that the bundle will be intelligible when received by that node. The manner in which applicable bundle representations are selected is beyond the scope of this document. If the agent finds that there are no applicable bundle representations for any of the nodes to which the bundle is to be sent, then forwarding is contraindicated. Step 3: If forwarding of the bundle is determined to be contraindicated for any of the reasons listed in Figure 12, then the Forwarding Contraindicated procedure defined in Section 5.4.1 MUST be followed; the remaining steps of Section 5 are skipped at this time. Step 4: If the bundle's custody transfer requested flag (in the bundle processing flags field) is set to 1, then the custody transfer procedure defined in Section 5.10.2 MUST be followed. Step 5: For each node selected for forwarding, the bundle protocol agent MUST encode the bundle in the selected applicable representation(s) and then invoke the services of the selected convergence layer adapter(s) in order to effect the sending of the bundle to that node. Determining the time at which the bundle protocol agent invokes convergence layer adapter services is a BPA implementation matter. Determining the time at which each Burleigh Expires July 2016 [Page 24] Internet-Draft Proposed Revised Bundle Protocol January 20166 convergence layer adapter subsequently responds to this service invocation by sending the bundle is a convergence-layer adapter implementation matter. Note that: . If the bundle contains a flow label extension block then that flow label value MAY identify procedures for determining the order in which convergence layer adapters must send bundles, e.g., considering bundle source when determining the order in which bundles are sent. The definition of such procedures is beyond the scope of this specification. . If the bundle has a bundle age block, then at the last possible moment before the CLA initiates conveyance of the bundle node via the CL protocol the bundle age value MUST be increased by the difference between the current time and the time at which the bundle was received (or, if the local node is the source of the bundle, created). Step 6: When all selected convergence layer adapters have informed the bundle protocol agent that they have concluded their data sending procedures with regard to this bundle: . If the "request reporting of bundle forwarding" flag in the bundle's status report request field is set to 1, then a bundle forwarding status report SHOULD be generated, destined for the bundle's report-to endpoint ID. If the bundle has the retention constraint "custody accepted" and all of the nodes to which the bundle was forwarded are known to be unable to send bundles back to this node, then the reason code on this bundle forwarding status report MUST be "forwarded over unidirectional link"; otherwise, the reason code MUST be "no additional information". . The bundle's "Forward pending" retention constraint MUST be removed. 5.4.1. Forwarding Contraindicated The steps in responding to contraindication of forwarding are: Step 1: The bundle protocol agent MUST determine whether or not to declare failure in forwarding the bundle. Note: this decision is likely to be influenced by the reason for which forwarding is contraindicated. Step 2: If forwarding failure is declared, then the Forwarding Failed procedure defined in Section 5.4.2 MUST be followed. Burleigh Expires July 2016 [Page 25] Internet-Draft Proposed Revised Bundle Protocol January 20166 Otherwise, (a) if the bundle's custody transfer requested flag (in the bundle processing flags field) is set to 1, then the custody transfer procedure defined in Section 5.10 MUST be followed; (b) when -- at some future time - the forwarding of this bundle ceases to be contraindicated, processing proceeds from Step 5 of Section 5.4. 5.4.2. Forwarding Failed The steps in responding to a declaration of forwarding failure are: Step 1: If the bundle's custody transfer requested flag (in the bundle processing flags field) is set to 1, custody transfer failure must be handled. The bundle protocol agent MUST handle the custody transfer failure by generating a "Failed" custody signal for the bundle, destined for the bundle's current custodian(s); the custody signal MUST contain a reason code corresponding to the reason for which forwarding was determined to be contraindicated. (Note that discarding the bundle will not delete it from the network, since each current custodian still has a copy.) If the bundle's custody transfer requested flag (in the bundle processing flags field) is set to 0, then the bundle protocol agent MAY forward the bundle back to the node that sent it, as identified by the Previous Node ID block. Step 2: If the bundle's destination endpoint is an endpoint of which the node is a member, then the bundle's "Forward pending" retention constraint MUST be removed. Otherwise, the bundle MUST be deleted: the bundle deletion procedure defined in Section 5.13 MUST be followed, citing the reason for which forwarding was determined to be contraindicated. 5.5. Bundle Expiration A bundle expires when the bundle's age exceeds its lifetime as specified in the primary bundle block. Bundle age MAY be determined by subtracting the bundle's creation timestamp time from the current time if (a) that timestamp time is not zero and (b) the local node's clock is known to be accurate (as discussed in section 4.5.1 above); otherwise bundle age MUST be obtained from the Bundle Age extension block. Bundle expiration MAY occur at any point in the processing of a bundle. When a bundle expires, the bundle protocol agent MUST delete the bundle for the reason "lifetime expired": the bundle deletion procedure defined in Section 5.13 MUST be followed. Burleigh Expires July 2016 [Page 26] Internet-Draft Proposed Revised Bundle Protocol January 20166 5.6. Bundle Reception The steps in processing a bundle that has been received from another node and decoded from its serialized representation are: Step 1: The retention constraint "Dispatch pending" MUST be added to the bundle. Step 2: If the "request reporting of bundle reception" flag in the bundle's status report request field is set to 1, then a bundle reception status report with reason code "No additional information" SHOULD be generated, destined for the bundle's report-to endpoint ID. Step 3: For each block in the bundle that is an extension block that the bundle protocol agent cannot process: . If the block processing flags in that block indicate that a status report is requested in this event, then a bundle reception status report with reason code "Block unintelligible" SHOULD be generated, destined for the bundle's report-to endpoint ID. . If the block processing flags in that block indicate that the bundle must be deleted in this event, then the bundle protocol agent MUST delete the bundle for the reason "Block unintelligible"; the bundle deletion procedure defined in Section 5.13 MUST be followed and all remaining steps of the bundle reception procedure MUST be skipped. . If the block processing flags in that block do NOT indicate that the bundle must be deleted in this event but do indicate that the block must be discarded, then the bundle protocol agent MUST remove this block from the bundle. Step 4: If the bundle's custody transfer requested flag (in the bundle processing flags field) is set to 1 and the bundle has the same source node ID, creation timestamp, and (if the bundle is a fragment) fragment offset and payload length as another bundle that (a) has not been discarded and (b) currently has the retention constraint "Custody accepted", custody transfer redundancy MUST be handled; otherwise, processing proceeds from Step 5. The bundle protocol agent MUST handle custody transfer redundancy by generating a "Failed" custody signal for this bundle with reason code "Redundant reception", destined for this bundle's current custodian, and removing this bundle's "Dispatch pending" retention constraint. Step 5: Processing proceeds from Step 1 of Section 5.3. Burleigh Expires July 2016 [Page 27] Internet-Draft Proposed Revised Bundle Protocol January 20166 5.7. Local Bundle Delivery The steps in processing a bundle that is destined for an endpoint of which this node is a member are: Step 1: If the received bundle is a fragment, the application data unit reassembly procedure described in Section 5.9 MUST be followed. If this procedure results in reassembly of the entire original application data unit, processing of this bundle (whose fragmentary payload has been replaced by the reassembled application data unit) proceeds from Step 2; otherwise, the retention constraint "Reassembly pending" MUST be added to the bundle and all remaining steps of this procedure MUST be skipped. Step 2: Delivery depends on the state of the registration whose endpoint ID matches that of the destination of the bundle: . If the registration is in the Active state, then the bundle MUST be delivered subject to this registration (see Section 3.1 above) as soon as all previously received bundles that are deliverable subject to this registration have been delivered. . If the registration is in the Passive state, then the registration's delivery failure action MUST be taken (see Section 3.1 above). Step 3: As soon as the bundle has been delivered: . If the "request reporting of bundle delivery" flag in the bundle's status report request field is set to 1, then a bundle delivery status report SHOULD be generated, destined for the bundle's report-to endpoint ID. Note that this status report only states that the payload has been delivered to the application agent, not that the application agent has processed that payload. . If the bundle's custody transfer requested flag (in the bundle processing flags field) is set to 1, custodial delivery MUST be reported. The bundle protocol agent MUST report custodial delivery by generating a "Succeeded" custody signal for the bundle, destined for the bundle's current custodian(s). 5.8. Bundle Fragmentation It may at times be advantageous for bundle protocol agents to reduce the sizes of bundles in order to forward them. This might be the case, for example, if a node to which a bundle is to be forwarded is accessible only via intermittent contacts and no upcoming contact is long enough to enable the forwarding of the entire bundle. Burleigh Expires July 2016 [Page 28] Internet-Draft Proposed Revised Bundle Protocol January 20166 The size of a bundle can be reduced by "fragmenting" the bundle. To fragment a bundle whose payload is of size M is to replace it with two "fragments" -- new bundles with the same source node ID and creation timestamp as the original bundle -- whose payloads are the first N and the last (M - N) bytes of the original bundle's payload, where 0 < N < M. Note that fragments may themselves be fragmented, so fragmentation may in effect replace the original bundle with more than two fragments. (However, there is only one 'level' of fragmentation, as in IP fragmentation.) Any bundle that has any Current Custodian extension block citing any node other than the local node MUST NOT be fragmented. This restriction aside, any bundle whose primary block's bundle processing flags do NOT indicate that it must not be fragmented MAY be fragmented at any time, for any purpose, at the discretion of the bundle protocol agent. Fragmentation SHALL be constrained as follows: . The concatenation of the payloads of all fragments produced by fragmentation MUST always be identical to the payload of the fragmented bundle (that is, the bundle that is being fragmented). Note that the payloads of fragments resulting from different fragmentation episodes, in different parts of the network, may be overlapping subsets of the fragmented bundle's payload. . The primary block of each fragment MUST differ from that of the fragmented bundle, in that the bundle processing flags of the fragment MUST indicate that the bundle is a fragment and both fragment offset and total application data unit length must be provided. Additionally, the CRC of the fragmented bundle, if any, MUST be replaced in each fragment by a new CRC computed for the primary block of that fragment. . The payload blocks of fragments will differ from that of the fragmented bundle as noted above. . If the fragmented bundle is not a fragment or is the fragment with offset zero, then all extension blocks of the fragmented bundle MUST be replicated in the fragment whose offset is zero. . Each of the fragmented bundle's extension blocks whose "Block must be replicated in every fragment" flag is set to 1 MUST be replicated in every fragment. . Beyond these rules, replication of extension blocks in the fragments is an implementation matter. . If the local node is a custodian of the fragmented bundle, then the BPA MUST release custody of the fragmented bundle before fragmentation occurs and MUST take custody of every fragment. Burleigh Expires July 2016 [Page 29] Internet-Draft Proposed Revised Bundle Protocol January 20166 5.9. Application Data Unit Reassembly If the concatenation -- as informed by fragment offsets and payload lengths -- of the payloads of all previously received fragments with the same source node ID and creation timestamp as this fragment, together with the payload of this fragment, forms a byte array whose length is equal to the total application data unit length in the fragment's primary block, then: . This byte array -- the reassembled application data unit -- MUST replace the payload of this fragment. . The BPA MUST take custody of each fragmentary bundle whose payload is a subset of the reassembled application data unit, for which custody transfer is requested but the BPA has not yet taken custody. . The BPA MUST then release custody of every fragment whose payload is a subset of the reassembled application data unit, for which it has taken custody. . The "Reassembly pending" retention constraint MUST be removed from every other fragment whose payload is a subset of the reassembled application data unit. Note: reassembly of application data units from fragments occurs at the nodes that are members of destination endpoints as necessary; an application data unit MAY also be reassembled at some other node on the path to the destination. 5.10. Custody Transfer The decision as to whether or not to accept custody of a bundle is an implementation matter that may involve both resource and policy considerations. If the bundle protocol agent elects to accept custody of the bundle, then it must follow the custody acceptance procedure defined in Section 5.10.1. 5.10.1. Custody Acceptance Procedures for acceptance of custody of a bundle are defined as follows. The retention constraint "Custody accepted" MUST be added to the bundle. If the "request reporting of custody acceptance" flag in the bundle's status report request field is set to 1, a custody Burleigh Expires July 2016 [Page 30] Internet-Draft Proposed Revised Bundle Protocol January 20166 acceptance status report SHOULD be generated, destined for the report-to endpoint ID of the bundle. However, if a bundle reception status report was generated for this bundle (Step 1 of Section 5.6) but has not yet been transmitted, then this report SHOULD be generated by simply turning on the "Reporting node accepted custody of bundle" flag in that earlier report. The bundle protocol agent MUST generate a "Succeeded" custody signal for the bundle, destined for the bundle's current custodian(s). The bundle protocol agent MUST assert the new current custodian for the bundle. It does so by inserting a new Current Custodian extension block whose value is the node ID of the local node or by changing the value of an existing Current Custodian extension block to the local node ID. The bundle protocol agent MAY set a custody transfer countdown timer for this bundle; upon expiration of this timer prior to expiration of the bundle itself and prior to custody transfer success for this bundle, the custody transfer failure procedure detailed in Section 5.12 MAY be followed. The manner in which the countdown interval for such a timer is determined is an implementation matter. The bundle SHOULD be retained in persistent storage if possible. 5.10.2. Custody Release When custody of a bundle is released, the "Custody accepted" retention constraint MUST be removed from the bundle and any custody transfer timer that has been established for this bundle SHOULD be destroyed. 5.11. Custody Transfer Success Upon receipt of a ' found at line 153: 151: 152: hIwDY32hYGCE8MkBA/wOu7d45aUxF4Q0RKJprD3v5Z9K1YcRJ2fve87lMlDlx4Oj 153: eW4GDdBfLbJE7VUpp13N19GL8e/AqbyyjHH4aS0YoTk10QQ9nnRvjY8nZL3MPXSZ 154: g9VGQxFeGqzykzmykU6A26MSMexR4ApeeON6xzZWfo+0yOqAq6lb46wsvldZ96YA 155: AABH78hyX7YX4uT1tNCWEIIBoqqvCeIMpp7UQ2IzBrXg6GtukS8NxbukLeamqVW3 +=+=+=+=+= File rfc2025.txt +=+=+=+=+= UTCTime found at line 751: 749: context-id Random-Integer, -- see Section 6.3 750: pvno BIT STRING, -- protocol version number 751: timestamp UTCTime OPTIONAL, -- mandatory for SPKM-2 752: randSrc Random-Integer, 753: targ-name Name, UTCTime found at line 923: 921: context-id Random-Integer, -- see Section 6.3 922: pvno [0] BIT STRING OPTIONAL, -- prot. version number 923: timestamp UTCTime OPTIONAL, -- mandatory for SPKM-2 924: randTarg Random-Integer, 925: src-name [1] Name OPTIONAL, UTCTime found at line 2159: 2157: context-id Random-Integer, 2158: pvno BIT STRING, 2159: timestamp UTCTime OPTIONAL, -- mandatory for SPKM-2 2160: randSrc Random-Integer, 2161: targ-name Name, UTCTime found at line 2248: 2246: 2247: pvno [0] BIT STRING OPTIONAL, 2248: timestamp UTCTime OPTIONAL, -- mandatory for SPKM-2 2249: randTarg Random-Integer, 2250: src-name [1] Name OPTIONAL, UTCTime found at line 2459: 2457: 2458: Validity ::= SEQUENCE { 2459: notBefore UTCTime, 2460: notAfter UTCTime 2461: } UTCTime found at line 2460: 2458: Validity ::= SEQUENCE { 2459: notBefore UTCTime, 2460: notAfter UTCTime 2461: } 2462: UTCTime found at line 2493: 2491: signature AlgorithmIdentifier, 2492: issuer Name, 2493: thisUpdate UTCTime, 2494: nextUpdate UTCTime OPTIONAL, 2495: revokedCertificates SEQUENCE OF SEQUENCE { UTCTime found at line 2494: 2492: issuer Name, 2493: thisUpdate UTCTime, 2494: nextUpdate UTCTime OPTIONAL, 2495: revokedCertificates SEQUENCE OF SEQUENCE { 2496: userCertificate CertificateSerialNumber, UTCTime found at line 2497: 2495: revokedCertificates SEQUENCE OF SEQUENCE { 2496: userCertificate CertificateSerialNumber, 2497: revocationDate UTCTime } OPTIONAL 2498: } 2499: +=+=+=+=+= File rfc2028.txt +=+=+=+=+= 2000 found at line 320: 318: Digital Equipment Corporation 319: 1401 H Street NW 320: Washington DC 20005 321: 322: Phone: +1 202 383 5615 +=+=+=+=+= File rfc2030.txt +=+=+=+=+= 1900 found at line 321: 319: main product of the protocol, a special timestamp format has been 320: established. NTP timestamps are represented as a 64-bit unsigned 321: fixed-point number, in seconds relative to 0h on 1 January 1900. The 322: integer part is in the first 32 bits and the fraction part in the 323: last 32 bits. In the fraction part, the non-significant low order can 1900 found at line 362: 360: 64-bit field will overflow some time in 2036 (second 4,294,967,296). 361: Should NTP or SNTP be in use in 2036, some external means will be 362: necessary to qualify time relative to 1900 and time relative to 2036 363: (and other multiples of 136 years). There will exist a 200-picosecond 364: interval, henceforth ignored, every 136 years when the 64-bit field 1900 found at line 375: 373: following convention: If bit 0 is set, the UTC time is in the 374: range 1968-2036 and UTC time is reckoned from 0h 0m 0s UTC on 1 375: January 1900. If bit 0 is not set, the time is in the range 2036- 376: 2104 and UTC time is reckoned from 6h 28m 16s UTC on 7 February 377: 2036. Note that when calculating the correspondence, 2000 is not a 2000 found at line 377: 375: January 1900. If bit 0 is not set, the time is in the range 2036- 376: 2104 and UTC time is reckoned from 6h 28m 16s UTC on 7 February 377: 2036. Note that when calculating the correspondence, 2000 is not a 378: leap year. Note also that leap seconds are not counted in the 379: reckoning. +=+=+=+=+= File rfc2048.txt +=+=+=+=+= 'yy' on a line without 'yyyy' found at line 738: 736: 737: To: ietf-types@iana.org 738: Subject: Registration of MIME media type XXX/YYY 739: 740: MIME media type name: +=+=+=+=+= File rfc2050.txt +=+=+=+=+= 1900 found at line 638: 636: [RFC 1814] Gerich, E., "Unique Addresses are Good", June 1995. 637: 638: [RFC 1900] Carpenter, B., and Y. Rekhter, "Renumbering Needs Work", 639: February 1996. 640: +=+=+=+=+= File rfc2052.txt +=+=+=+=+= 1900 found at line 420: 418: Errors", RFC 1912, February 1996. 419: 420: RFC 1900: Carpenter, B., and Y. Rekhter, "Renumbering Needs Work", 421: RFC 1900, February 1996. 422: 1900 found at line 421: 419: 420: RFC 1900: Carpenter, B., and Y. Rekhter, "Renumbering Needs Work", 421: RFC 1900, February 1996. 422: 423: RFC 1920: Postel, J., "INTERNET OFFICIAL PROTOCOL STANDARDS", +=+=+=+=+= File rfc2060.txt +=+=+=+=+= 2digit found at line 3782: 3780: date ::= date_text / <"> date_text <"> 3781: 3782: date_day ::= 1*2digit 3783: ;; Day of month 3784: 2digit found at line 3785: 3783: ;; Day of month 3784: 3785: date_day_fixed ::= (SPACE digit) / 2digit 3786: ;; Fixed-format version of date_day 3787: 2digit found at line 4101: 4099: TEXT_CHAR ::= <any CHAR except CR and LF> 4100: 4101: time ::= 2digit ":" 2digit ":" 2digit 4102: ;; Hours minutes seconds 4103: +=+=+=+=+= File rfc2062.txt +=+=+=+=+= 2digit found at line 330: 328: ::= partial 329: 330: date_year_old ::= 2digit 331: ;; (year - 1900) 332: 1900 found at line 331: 329: 330: date_year_old ::= 2digit 331: ;; (year - 1900) 332: 333: date_time_old ::= <"> date_day_fixed "-" date_month "-" date_year +=+=+=+=+= File rfc2063.txt +=+=+=+=+= 2000 found at line 716: 714: 715: start time = 1 start time = 1 716: Usage record N: flow count = 2000 flow count = 2000 (done) 717: 718: start time = 1 start time = 5 2000 found at line 725: 723: 724: In the continuing flow case, the same flow was reported when its 725: count was 2000, and again at 3000: the total count to date is 3000. 726: In the OLD/NEW case, the old flow had a count of 2000. Its record 727: 2000 found at line 726: 724: In the continuing flow case, the same flow was reported when its 725: count was 2000, and again at 3000: the total count to date is 3000. 726: In the OLD/NEW case, the old flow had a count of 2000. Its record 727: 728: +=+=+=+=+= File rfc2068.txt +=+=+=+=+= 2-digit found at line 772: 770: Specific repetition: "<n>(element)" is equivalent to 771: "<n>*<n>(element)"; that is, exactly <n> occurrences of (element). 772: Thus 2DIGIT is a 2-digit number, and 3ALPHA is a string of three 773: alphabetic characters. 774: 2digit found at line 772: 770: Specific repetition: "<n>(element)" is equivalent to 771: "<n>*<n>(element)"; that is, exactly <n> occurrences of (element). 772: Thus 2DIGIT is a 2-digit number, and 3ALPHA is a string of three 773: alphabetic characters. 774: 2digit found at line 1163: 1161: asctime-date = wkday SP date3 SP time SP 4DIGIT 1162: 1163: date1 = 2DIGIT SP month SP 4DIGIT 1164: ; day month year (e.g., 02 Jun 1982) 1165: date2 = 2DIGIT "-" month "-" 2DIGIT 2digit found at line 1165: 1163: date1 = 2DIGIT SP month SP 4DIGIT 1164: ; day month year (e.g., 02 Jun 1982) 1165: date2 = 2DIGIT "-" month "-" 2DIGIT 1166: ; day-month-year (e.g., 02-Jun-82) 1167: date3 = month SP ( 2DIGIT | ( SP 1DIGIT )) 2digit found at line 1167: 1165: date2 = 2DIGIT "-" month "-" 2DIGIT 1166: ; day-month-year (e.g., 02-Jun-82) 1167: date3 = month SP ( 2DIGIT | ( SP 1DIGIT )) 1168: ; month day (e.g., Jun 2) 1169: 2digit found at line 1170: 1168: ; month day (e.g., Jun 2) 1169: 1170: time = 2DIGIT ":" 2DIGIT ":" 2DIGIT 1171: ; 00:00:00 - 23:59:59 1172: 2digit found at line 7652: 7650: 7651: warning-value = warn-code SP warn-agent SP warn-text 7652: warn-code = 2DIGIT 7653: warn-agent = ( host [ ":" port ] ) | pseudonym 7654: ; the name or pseudonym of the server adding 1900 found at line 1083: 1081: for TCP connections on that port of that host, and the Request-URI 1082: for the resource is abs_path. The use of IP addresses in URL's SHOULD 1083: be avoided whenever possible (see RFC 1900 [24]). If the abs_path is 1084: not present in the URL, it MUST be given as "/" when used as a 1085: Request-URI for a resource (section 5.1.2). 1900 found at line 8249: 8247: 8248: [24] Carpenter, B., and Y. Rekhter, "Renumbering Needs Work", RFC 8249: 1900, IAB, February 1996. 8250: 8251: [25] Deutsch, P., "GZIP file format specification version 4.3." RFC 2000 found at line 8453: 8451: o HTTP/1.1 clients and caches should assume that an RFC-850 date 8452: which appears to be more than 50 years in the future is in fact 8453: in the past (this helps solve the "year 2000" problem). 8454: 8455: +=+=+=+=+= File rfc2071.txt +=+=+=+=+= 1900 found at line 738: 736: December 1995. 737: 738: [16] Carpenter, B., and Y. Rekhter, "Renumbering Needs Work", RFC 1900, 739: February 1996. 740: +=+=+=+=+= File rfc2072.txt +=+=+=+=+= 1900 found at line 206: 204: Many discussions of renumbering emphasize interactions among 205: organizations' numbering plans and those of the global Internet 206: [RFC1900]. There can be equally strong motivations for renumbering 207: in organizations that never connect to the global Internet. 208: 1900 found at line 209: 207: in organizations that never connect to the global Internet. 208: 209: According to RFC1900, "Unless and until viable alternatives are 210: developed, extended deployment of Classless Inter-Domain Routing 211: (CIDR) is vital to keep the Internet routing system alive and to 1900 found at line 2606: 2604: February 1996. 2605: 2606: [RFC1900] Carpenter, B., and Y. Rekhter, "Renumbering Needs Work", RFC 2607: 1900, February 1996. 2608: 1900 found at line 2607: 2605: 2606: [RFC1900] Carpenter, B., and Y. Rekhter, "Renumbering Needs Work", RFC 2607: 1900, February 1996. 2608: 2609: [RPS] Alaettinoglu, C., Bates, T., Gerich, E., Terpstra, M., and C. +=+=+=+=+= File rfc2074.txt +=+=+=+=+= 2000 found at line 2041: 2039: From [RFC1831]: 2040: 2041: Program numbers are given out in groups of hexadecimal 20000000 2042: (decimal 536870912) according to the following chart: 2043: 2000 found at line 2045: 2043: 2044: 0 - 1fffffff defined by rpc@sun.com 2045: 20000000 - 3fffffff defined by user 2046: 40000000 - 5fffffff transient 2047: 60000000 - 7fffffff reserved +=+=+=+=+= File rfc2077.txt +=+=+=+=+= 'yy' on a line without 'yyyy' found at line 315: 313: Subject: model data file 314: 315: I1ZSTUwgVjEuMCBhc2NpaQojIFRoaXMgZmlsZSB3YXMgIGdlbmVyY... 316: byBDb21tdW5pY2F0aW9ucwojIGh0dHA6Ly93d3cuY2hhY28uY29tC... 317: IyB1c2VkIGluIHJvb20gMTkyICh0ZXN0IHJvb20pCiAgIAojIFRvc... +=+=+=+=+= File rfc2095.txt +=+=+=+=+= 'yy' on a line without 'yyyy' found at line 131: 129: C: A0001 AUTHENTICATE CRAM-MD5 130: S: + PDE4OTYuNjk3MTcwOTUyQHBvc3RvZmZpY2UucmVzdG9uLm1jaS5uZXQ+ 131: C: dGltIGI5MTNhNjAyYzdlZGE3YTQ5NWI0ZTZlNzMzNGQzODkw 132: S: A0001 OK CRAM authentication successful 133: 'yy' on a line without 'yyyy' found at line 161: 159: AUTHENTICATE command (or the similar POP3 AUTH command), yielding 160: 161: dGltIGI5MTNhNjAyYzdlZGE3YTQ5NWI0ZTZlNzMzNGQzODkw 162: 163: +=+=+=+=+= File rfc2096.txt +=+=+=+=+= 1900 found at line 134: 132: 133: ipForward MODULE-IDENTITY 134: LAST-UPDATED "9609190000Z" -- Thu Sep 26 16:34:47 PDT 1996 135: ORGANIZATION "IETF OSPF Working Group" 136: CONTACT-INFO 1900 found at line 147: 145: DESCRIPTION 146: "The MIB module for the display of CIDR multipath IP Routes." 147: REVISION "9609190000Z" 148: DESCRIPTION 149: "Revisions made by the OSPF WG." +=+=+=+=+= File rfc2099.txt +=+=+=+=+= 2000 found at line 14: 12: Request for Comments Summary 13: 14: RFC Numbers 2000-2099 15: 16: Status of This Memo 2000 found at line 18: 16: Status of This Memo 17: 18: This RFC is a slightly annotated list of the 100 RFCs from RFC 2000 19: through RFCs 2099. This is a status report on these RFCs. This memo 20: provides information for the Internet community. It does not specify 2000 found at line 60: 58: Elliott Informational [Page 1] 59: 60: RFC 2099 Summary of 2000-2099 March 1997 61: 62: 2000 found at line 116: 114: Elliott Informational [Page 2] 115: 116: RFC 2099 Summary of 2000-2099 March 1997 117: 118: 2000 found at line 172: 170: Elliott Informational [Page 3] 171: 172: RFC 2099 Summary of 2000-2099 March 1997 173: 174: 2000 found at line 228: 226: Elliott Informational [Page 4] 227: 228: RFC 2099 Summary of 2000-2099 March 1997 229: 230: 2000 found at line 284: 282: Elliott Informational [Page 5] 283: 284: RFC 2099 Summary of 2000-2099 March 1997 285: 286: 2000 found at line 340: 338: Elliott Informational [Page 6] 339: 340: RFC 2099 Summary of 2000-2099 March 1997 341: 342: 2000 found at line 396: 394: Elliott Informational [Page 7] 395: 396: RFC 2099 Summary of 2000-2099 March 1997 397: 398: 2000 found at line 452: 450: Elliott Informational [Page 8] 451: 452: RFC 2099 Summary of 2000-2099 March 1997 453: 454: 2000 found at line 508: 506: Elliott Informational [Page 9] 507: 508: RFC 2099 Summary of 2000-2099 March 1997 509: 510: 2000 found at line 564: 562: Elliott Informational [Page 10] 563: 564: RFC 2099 Summary of 2000-2099 March 1997 565: 566: 2000 found at line 620: 618: Elliott Informational [Page 11] 619: 620: RFC 2099 Summary of 2000-2099 March 1997 621: 622: 2000 found at line 676: 674: Elliott Informational [Page 12] 675: 676: RFC 2099 Summary of 2000-2099 March 1997 677: 678: 2000 found at line 732: 730: Elliott Informational [Page 13] 731: 732: RFC 2099 Summary of 2000-2099 March 1997 733: 734: 2000 found at line 788: 786: Elliott Informational [Page 14] 787: 788: RFC 2099 Summary of 2000-2099 March 1997 789: 790: 2000 found at line 844: 842: Elliott Informational [Page 15] 843: 844: RFC 2099 Summary of 2000-2099 March 1997 845: 846: 2000 found at line 900: 898: Elliott Informational [Page 16] 899: 900: RFC 2099 Summary of 2000-2099 March 1997 901: 902: 2000 found at line 956: 954: Elliott Informational [Page 17] 955: 956: RFC 2099 Summary of 2000-2099 March 1997 957: 958: 2000 found at line 1012: 1010: Elliott Informational [Page 18] 1011: 1012: RFC 2099 Summary of 2000-2099 March 1997 1013: 1014: 2000 found at line 1068: 1066: Elliott Informational [Page 19] 1067: 1068: RFC 2099 Summary of 2000-2099 March 1997 1069: 1070: 2000 found at line 1124: 1122: Elliott Informational [Page 20] 1123: 1124: RFC 2099 Summary of 2000-2099 March 1997 1125: 1126: 2000 found at line 1144: 1142: 1143: 1144: 2000 I.A.B. Feb 97 INTERNET OFFICIAL PROTOCOL STANDARDS 1145: 1146: This memo describes the state of standardization of protocols used in +=+=+=+=+= File rfc2101.txt +=+=+=+=+= 1900 found at line 353: 351: 352: Changing providers is just one possible reason for renumbering. 353: The informational document [RFC 1900] shows why renumbering is an 354: increasingly frequent event. Both DHCP [RFC 1541] and PPP [RFC 355: 1661] promote the use of dynamic address allocation. 1900 found at line 534: 532: solutions for renumbering sites. The need to contain the overhead 533: in a rapidly growing Internet routing system is likely to make 534: renumbering more and more common [RFC 1900]. 535: 536: The need to scale the Internet routing system, and the use of CIDR as 1900 found at line 632: 630: Protocol", RFC 1825, September 1995. 631: 632: [RFC 1900] Carpenter, B., and Y. Rekhter, "Renumbering Needs Work", 633: RFC 1900, February 1996. 634: 1900 found at line 633: 631: 632: [RFC 1900] Carpenter, B., and Y. Rekhter, "Renumbering Needs Work", 633: RFC 1900, February 1996. 634: 635: [RFC 1918] Rekhter, Y., Moskowitz, B., Karrenberg, D., de Groot, G. +=+=+=+=+= File rfc2109.txt +=+=+=+=+= 'yy' on a line without 'yyyy' found at line 1054: 1052: date value in a fixed-length variant format in place of Max-Age: 1053: 1054: Wdy, DD-Mon-YY HH:MM:SS GMT 1055: 1056: Note that the Expires date format contains embedded spaces, and that +=+=+=+=+= File rfc2116.txt +=+=+=+=+= 2000 found at line 4132: 4130: * MAIL.X-OD V2.3 4131: 4132: * MAIL.2000 V1.2, AKOM 4133: 4134: * MS-Mail 2000 found at line 5393: 5391: 1-800-257-OPEN (U.S. and Canada) 5392: 1-612-482-6736 (worldwide) 5393: FAX: 1-612-482-2000 (worldwide) 5394: EMAIL: info@cdc.com 5395: or +=+=+=+=+= File rfc2134.txt +=+=+=+=+= 2000 found at line 30: 28: 29: To: Department of Consumer and Regulatory Affairs 30: Washington, D.C. 20001 31: 32: We, the undersigned natural persons of the age of eighteen years 2000 found at line 140: 138: 8. The address, including street and number, of the initial 139: registered office of the corporation is c/o C T Corporation 140: System, 1030 15th Street, N.W., Washington, D.C. 20005, and the 141: name of its initial registered agent at such address is C T 142: Corporation System. +=+=+=+=+= File rfc2150.txt +=+=+=+=+= century found at line 2197: 2195: scholarly music resources. http://rism.harvard.edu/RISM/ 2196: 2197: Crescendo is used in the web pages at http://mcentury.citi.doc.ca 2198: along with a growing number of others. One very interesting use of 2199: Crescendo occurs on the Music Theory Online publication, a serious century found at line 3150: 3148: Joseph Aiuto 3149: Sepideh Boroumand 3150: Michael Century 3151: Kelly Cooper 3152: Lile Elam +=+=+=+=+= File rfc2151.txt +=+=+=+=+= 2000 found at line 1805: 1803: * About Hill Associates 1804: * HAI Products and Services Catalog 1805: * Datacomm/2000-ED Series 1806: * Contacting Hill Associates 1807: * Employment Opportunities 2000 found at line 2808: 2806: 2807: [23] _____, Editor, "Internet Official Protocol Standards," 2808: STD 1/RFC 2000, Internet Architecture Board, February 1997. 2809: 2810: [24] _____, "Introduction to the STD Notes," RFC 1311, USC/Information +=+=+=+=+= File rfc2156.txt +=+=+=+=+= 'yy' on a line without 'yyyy' found at line 3210: 3208: the prefix, all attributes remaining in the OR address shall be 3209: encoded on the LHS. This is to ensure a reversible mapping. For 3210: example, if there is an address /S=XX/O=YY/ADMD=A/C=NN/ and a 3211: mapping for /ADMD=A/C=NN/ is used, then /S=XX/O=YY/ is encoded 3212: on the LHS. 'yy' on a line without 'yyyy' found at line 3211: 3209: encoded on the LHS. This is to ensure a reversible mapping. For 3210: example, if there is an address /S=XX/O=YY/ADMD=A/C=NN/ and a 3211: mapping for /ADMD=A/C=NN/ is used, then /S=XX/O=YY/ is encoded 3212: on the LHS. 3213: 'yy' on a line without 'yyyy' found at line 3317: 3315: 3316: C = "XX" 3317: ADMD = "YY" 3318: O = "ZZ" 3319: "RFC-822" = "Smith(a)ZZ.YY.XX" 'yy' on a line without 'yyyy' found at line 3319: 3317: ADMD = "YY" 3318: O = "ZZ" 3319: "RFC-822" = "Smith(a)ZZ.YY.XX" 3320: 3321: This is mapped first to an RFC 822 address, and then back to the 'yy' on a line without 'yyyy' found at line 3325: 3323: 3324: C = "XX" 3325: ADMD = "YY" 3326: O = "ZZ" 3327: Surname = "Smith" UTCTime found at line 1705: 1703: "yen*{165}" 1704: 1705: 3.3.5. UTCTime 1706: 1707: Both UTCTime and the RFC 822 822.date-time syntax contain: Year, UTCTime found at line 1707: 1705: 3.3.5. UTCTime 1706: 1707: Both UTCTime and the RFC 822 822.date-time syntax contain: Year, 1708: Month, Day of Month, hour, minute, second (optional), and Timezone 1709: (technically a time differential in UTCTime). 822.date-time also UTCTime found at line 1709: 1707: Both UTCTime and the RFC 822 822.date-time syntax contain: Year, 1708: Month, Day of Month, hour, minute, second (optional), and Timezone 1709: (technically a time differential in UTCTime). 822.date-time also 1710: contains an optional day of the week, but this is redundant. With 1711: the exception of Year, a symmetrical mapping can be made between UTCTime found at line 1717: 1715: In practice, a gateway will need to parse various illegal variants 1716: on 822.date-time. In cases where 822.date-time cannot be parsed, 1717: it is recommended that the derived UTCTime is set to the value at 1718: the time of translation. Such errors may be noted in an RFC 822 1719: comment, to aid detection and correction. UTCTime found at line 1721: 1719: comment, to aid detection and correction. 1720: 1721: When mapping to X.400, the UTCTime format which specifies the 1722: timezone offset shall be used. 1723: UTCTime found at line 1745: 1743: RFC 822, as modified by RFC 1123, requires use of a four digit year. 1744: Note that the original RFC 822 uses a two digit date, which is no 1745: longer legal. UTCTime uses a two digit date. To map a year from RFC 1746: 822 to X.400, simply use the last two digits. To map a year from 1747: X.400 to RFC 822, assume that the two digit year refers to a year in +=+=+=+=+= File rfc2162.txt +=+=+=+=+= 'yy' on a line without 'yyyy' found at line 797: 795: maps into 796: 797: C=xx; ADMD=yyy; PRMD=zzz; O=ooo; OU=uuu; DD.Dnet=net; 798: DD.Mail-11=route::node::localpart; 799: 'yy' on a line without 'yyyy' found at line 806: 804: maps into 805: 806: C=xx; ADMD=yyy; PRMD=zzz; O=ooo; OU=uuu; DD.Dnet=net; 807: DD.Mail-11=node-clns::localpart; 808: 'yy' on a line without 'yyyy' found at line 812: 810: 811: xx = country code of the gateway performing the conversion 812: yyy = Admd of the gateway performing the conversion 813: zzz = Prmd of the gateway performing the conversion 814: ooo = Organisation of the gateway performing the conversion 'yy' on a line without 'yyyy' found at line 915: 913: it is connected to. In this case the mapping is trivial: 914: 915: C=xx; ADMD=yyy; PRMD=zzz; O=ooo; OU=uuu; DD.Dnet=net; 916: DD.Mail-11=route::node::localpart; 917: 'yy' on a line without 'yyyy' found at line 918: 916: DD.Mail-11=route::node::localpart; 917: 918: (see sect. 5.2 for explication of 'xx','yyy','zzz','ooo','uuu','net') 919: 920: maps into 'yy' on a line without 'yyyy' found at line 926: 924: and for DECnet/OSI addresses 925: 926: C=xx; ADMD=yyy; PRMD=zzz; O=ooo; OU=uuu; DD.Dnet=net; 927: DD.Mail-11=node-clns::localpart; 928: 'yy' on a line without 'yyyy' found at line 937: 935: described into section 5.4 apply: 936: 937: C=xx; ADMD=yyy; PRMD=www; DD.Dnet=net; 938: DD.Mail-11=route::node::localpart; 939: 'yy' on a line without 'yyyy' found at line 942: 940: maps into 941: 942: gwnode::gw%"C=xx;ADMD=yyy;PRMD=www;DD.Dnet=net; 943: DD.Mail-11=route::node::localpart;" 944: 'yy' on a line without 'yyyy' found at line 961: 959: Again for DECnet/OSI addresses: 960: 961: C=xx; ADMD=yyy; PRMD=www; DD.Dnet=net; 962: DD.Mail-11=node-clns::localpart; 963: 'yy' on a line without 'yyyy' found at line 966: 964: maps into 965: 966: gwnode::gw%"C=xx;ADMD=yyy;PRMD=www;DD.Dnet=net; 967: DD.Mail-11=node-clns::localpart;" 968: 'yy' on a line without 'yyyy' found at line 1095: 1093: maps into 1094: 1095: C=xx; ADMD=yyy; DD.Dnet=net; 1096: DD.Mail-11=route::gwnode::gw(p)(q)x400-text-address(q); 1097: 'yy' on a line without 'yyyy' found at line 1104: 1102: maps into 1103: 1104: C=xx; ADMD=yyy; DD.Dnet=net; 1105: DD.Mail-11=gwnode::gw(p)(q)x400-text-address(q); 1106: +=+=+=+=+= File rfc2167.txt +=+=+=+=+= 2digit found at line 1026: 1024: 1025: year = 4digit 1026: month = 2digit 1027: day = 2digit 1028: hour = 2digit 2digit found at line 1027: 1025: year = 4digit 1026: month = 2digit 1027: day = 2digit 1028: hour = 2digit 1029: minute = 2digit 2digit found at line 1028: 1026: month = 2digit 1027: day = 2digit 1028: hour = 2digit 1029: minute = 2digit 1030: second = 2digit 2digit found at line 1029: 1027: day = 2digit 1028: hour = 2digit 1029: minute = 2digit 1030: second = 2digit 1031: milli-second = 3digit 2digit found at line 1030: 1028: hour = 2digit 1029: minute = 2digit 1030: second = 2digit 1031: milli-second = 3digit 1032: host-name = dns-char *(dns-char / ".") 2digit found at line 3186: 3184: 3185: year = 4digit 3186: month = 2digit 3187: day = 2digit 3188: hour = 2digit 2digit found at line 3187: 3185: year = 4digit 3186: month = 2digit 3187: day = 2digit 3188: hour = 2digit 3189: minute = 2digit 2digit found at line 3188: 3186: month = 2digit 3187: day = 2digit 3188: hour = 2digit 3189: minute = 2digit 3190: second = 2digit 2digit found at line 3189: 3187: day = 2digit 3188: hour = 2digit 3189: minute = 2digit 3190: second = 2digit 3191: 2digit found at line 3190: 3188: hour = 2digit 3189: minute = 2digit 3190: second = 2digit 3191: 3192: 2000 found at line 1229: 1227: C -class rwhois.net domain host 1228: S %class domain:description:Domain information 1229: S %class domain:version:19970103101232000 1230: S %class 1231: 2000 found at line 3626: 3624: soa 000800h 3625: status 001000h 3626: xfer 002000h 3627: X 004000h 3628: +=+=+=+=+= File rfc2170.txt +=+=+=+=+= 2000 found at line 427: 425: Server: MyAgent/1.0 426: ATM-Service: CBR 427: ATM-QoS-PCR: 2000 428: Content-type: video/mpeg 429: 2000 found at line 464: 462: Server: MyAgent/1.0 ATM.address 463: ATM-Service: CBR 464: ATM-QoS-PCR: 2000 465: Content-type: video/mpeg 466: +=+=+=+=+= File rfc2179.txt +=+=+=+=+= 2000 found at line 292: 290: a setuid file anywhere in the system, including those on NFS 291: mounted partitions. 292: * "find / -group kmem -perm -2000 -print" will do the same for kmem 293: group permissions. 294: +=+=+=+=+= File rfc2182.txt +=+=+=+=+= 2000 found at line 495: 493: 494: Instead, for this example, set the primary's serial number to 495: 2000000000, and wait for the secondary servers to update to that 496: zone. The value 2000000000 is chosen as a value a lot bigger than 497: the current value, but less that 2^31 bigger (2^31 is 2147483648). 2000 found at line 496: 494: Instead, for this example, set the primary's serial number to 495: 2000000000, and wait for the secondary servers to update to that 496: zone. The value 2000000000 is chosen as a value a lot bigger than 497: the current value, but less that 2^31 bigger (2^31 is 2147483648). 498: This is then an increment of the serial number [RFC1982]. 2000 found at line 502: 500: Next, after all servers needing updating have the zone with that 501: serial number, the serial number can be set to 4000000000. 502: 4000000000 is 2000000000 more than 2000000000 (fairly clearly), and 503: 504: +=+=+=+=+= File rfc2183.txt +=+=+=+=+= century found at line 8: 6: 7: Network Working Group R. Troost 8: Request for Comments: 2183 New Century Systems 9: Updates: 1806 S. Dorner 10: Category: Standards Track QUALCOMM Incorporated century found at line 587: 585: 586: Rens Troost 587: New Century Systems 588: 324 East 41st Street #804 589: New York, NY, 10017 USA century found at line 593: 591: Phone: +1 (212) 557-2050 592: Fax: +1 (212) 557-2049 593: EMail: rens@century.com 594: 595: +=+=+=+=+= File rfc2195.txt +=+=+=+=+= 'yy' on a line without 'yyyy' found at line 131: 129: C: A0001 AUTHENTICATE CRAM-MD5 130: S: + PDE4OTYuNjk3MTcwOTUyQHBvc3RvZmZpY2UucmVzdG9uLm1jaS5uZXQ+ 131: C: dGltIGI5MTNhNjAyYzdlZGE3YTQ5NWI0ZTZlNzMzNGQzODkw 132: S: A0001 OK CRAM authentication successful 133: 'yy' on a line without 'yyyy' found at line 161: 159: AUTHENTICATE command (or the similar POP3 AUTH command), yielding 160: 161: dGltIGI5MTNhNjAyYzdlZGE3YTQ5NWI0ZTZlNzMzNGQzODkw 162: 163: +=+=+=+=+= File rfc2200.txt +=+=+=+=+= 'yy' on a line without 'yyyy' found at line 2118: 2116: The text version is sent. 2117: 2118: file /ftp/rfc/rfcnnnn.yyy where 'nnnn' is the RFC number. 2119: and 'yyy' is 'txt' or 'ps'. 2120: 'yy' on a line without 'yyyy' found at line 2119: 2117: 2118: file /ftp/rfc/rfcnnnn.yyy where 'nnnn"Succeeded" custody signal at a node that is a custodial node of the bundle identified in the custody signal, custody of the bundle MUST be released as described in Section 5.10.2. 5.12. Custody Transfer Failure Custody transfer is determined to have failed at a custodial node for that bundle when either (a) that node's custody transfer timer for that bundle (if any) expires or (b) a "Failed" custody signal for that bundle is received at that node. Burleigh Expires July 2016 [Page 31] Internet-Draft Proposed Revised Bundle Protocol January 20166 Upon determination of custody transfer failure, the action taken by the bundle protocol agent is implementation-specific and may depend on the nature of the failure. For example, if custody transfer failure was inferred from expiration of a custody transfer timer or was asserted by a "Failed" custody signal with the "Depleted storage" reason code, the bundle protocol agent might choose to re- forward the bundle, possibly on a different route (Section 5.4). Receipt of a "Failed" custody signal with the "Redundant reception" reason code, on the other hand, might cause the bundle protocol agent to release custody of the bundle and to revise its algorithm for computing countdown intervals for custody transfer timers. 5.13. Bundle Deletion The steps in deleting a bundle are: Step 1: If the retention constraint "Custody accepted" currently prevents this bundle from being discarded, then: . Custody of the node is released as described in Section 5.10.2. . A bundle deletion status report citing the reason for deletion MUST be generated, destined for the bundle's report-to endpoint ID. Otherwise, if the "request reporting of bundle deletion" flag in the bundle's status report request field is set to 1, then a bundle deletion status report citing the reason for deletion SHOULD be generated, destined for the bundle's report-to endpoint ID. Step 2: All of the bundle's retention constraints MUST be removed. 5.14. Discarding a Bundle As soon as a bundle has no remaining retention constraints it MAY be discarded. 5.15. Canceling a Transmission When requested to cancel a specified transmission, where the bundle created upon initiation of the indicated transmission has not yet been discarded, the bundle protocol agent MUST delete that bundle for the reason "transmission cancelled". For this purpose, the procedure defined in Section 5.13 MUST be followed. Burleigh Expires July 2016 [Page 32] Internet-Draft Proposed Revised Bundle Protocol January 20166 6. Administrative Record Processing 6.1. Administrative Records Administrative records are standard application data units that are used in providing some of the features of the Bundle Protocol. Two types of administrative records have been defined to date: bundle status reports and custody signals. Note that additional types of administrative records may be defined by supplementary DTN protocol specification documents. Every administrative record consists of: . Record type code (an unsigned integer for which valid values are as defined below). . Record content in type-specific format. Valid administrative record type codes are defined as follows: +---------+--------------------------------------------+ | Value | Meaning | +=========+============================================+ | 1 | Bundle status report. | +---------+--------------------------------------------+ | 2 | Custody signal. | +---------+--------------------------------------------+ | (other) | Reserved for future use. | +---------+--------------------------------------------+ Figure 2: Administrative Record Type Codes The contents of the two types of administrative records defined in the present document are described below. 6.1.1. Bundle Status Reports The transmission of 'bundle status reports' under specified conditions is an option that can be invoked when transmission of a bundle is requested. These reports are intended to provide Burleigh Expires July 2016 [Page 33] Internet-Draft Proposed Revised Bundle Protocol January 20166 information about how bundles are progressing through the system, including notices of receipt, custody transfer, forwarding, final delivery, and deletion. They are transmitted to the Report-to endpoints of bundles. Every bundle status report comprises the following fields, in this order: . Status flags. The following conditions are asserted by the bundle status report status flags (all Boolean): o Reporting node received bundle. o Reporting node accepted custody of bundle. o Reporting node forwarded the bundle. o Reporting node delivered the bundle. o Reporting node deleted the bundle. . Reason code, an unsigned integer explaining the values of the status flags. Status report reason codes are as defined below, but the list of status report reason codes provided here is neither exhaustive nor exclusive; supplementary DTN protocol specifications (including, but not restricted to, the Bundle Security Protocol [BPSEC]) may define additional reason codes. . Status times, one unsigned integer for each condition asserted by any status flag, indicating the time (as reported by the local system clock, an implementation matter) at which the indicated condition became true for this bundle. These fields are included in the status report if and only if the "Report status time" flag was set to 1 in the subject bundle's bundle processing flags. Status time is expressed in seconds since the start of the year 2000, on the Coordinated Universal Time (UTC) scale [UTC]. . Source node, the node ID of the source of the bundle whose status is being reported. . Creation timestamp, the creation timestamp of the bundle whose status is being reported. . Fragment offset, the fragment offset of the bundle whose status is being reported (omitted if omitted from the subject bundle's primary block). . Fragment length, the length of the payload of the bundle whose status is being reported (omitted if fragment offset is omitted from the subject bundle's primary block). Valid status report reason codes are defined as follows: +---------+--------------------------------------------+ | Value | Meaning | Burleigh Expires July 2016 [Page 34] Internet-Draft Proposed Revised Bundle Protocol January 20166 +=========+============================================+ | 0 | No additional information. | +---------+--------------------------------------------+ | 1 | Lifetime expired. | +---------+--------------------------------------------+ | 2 | Forwarded over unidirectional link. | +---------+--------------------------------------------+ | 3 | Transmission canceled. | +---------+--------------------------------------------+ | 4 | Depleted storage. | +---------+--------------------------------------------+ | 5 | Destination endpoint ID unintelligible. | +---------+--------------------------------------------+ | 6 | No known route to destination from here. | +---------+--------------------------------------------+ | 7 | No timely contact with next node on route. | +---------+--------------------------------------------+ | 8 | Block unintelligible. | +---------+--------------------------------------------+ | (other) | Reserved for future use. | +---------+--------------------------------------------+ Figure 3: Status Report Reason Codes Burleigh Expires July 2016 [Page 35] Internet-Draft Proposed Revised Bundle Protocol January 20166 6.1.2. Custody Signals Custody signals are administrative records that effect custody transfer operations. They are transmitted to the nodes that are the current custodians of bundles. Every custody signal comprises the following fields, in this order: . "Custody transfer succeeded" flag (Boolean). . Reason code, an unsigned integer explaining the value of the "Custody transfer succeeded" flag. Custody signal reason codes are as defined below. . Source node, the node ID of the source of the bundle for which custodial activity is being reported. . Creation timestamp, the creation timestamp of the bundle for which custodial activity is being reported. . Fragment offset, the fragment offset of the bundle for which custodial activity is being reported (omitted if omitted from the subject bundle's primary block). . Fragment length, the length of the payload of the bundle for which custodial activity is being reported (omitted if fragment offset is omitted from the subject bundle's primary block). Valid custody signal reason codes are defined as follows: +---------+--------------------------------------------+ | Value | Meaning | +=========+============================================+ | 0 | No additional information. | +---------+--------------------------------------------+ | 1 | Reserved for future use. | +---------+--------------------------------------------+ | 2 | Reserved for future use. | +---------+--------------------------------------------+ | 3 | Redundant (reception by a node that is a | | | custodial node for this bundle). | Burleigh Expires July 2016 [Page 36] Internet-Draft Proposed Revised Bundle Protocol January 20166 +---------+--------------------------------------------+ | 4 | Depleted storage. | +---------+--------------------------------------------+ | 5 | Destination endpoint ID unintelligible. | +---------+--------------------------------------------+ | 6 | No known route destination from here. | +---------+--------------------------------------------+ | 7 | No timely contact with next node on route. | +---------+--------------------------------------------+ | 8 | Block unintelligible. | +---------+--------------------------------------------+ | (other) | Reserved for future use. | +---------+--------------------------------------------+ Figure 4: Custody Signal Reason Codes 6.2. Generation of Administrative Records Whenever the application agent' is the RFC number. 2119: and 'yyy' is 'txt' or 'ps'. 2120: 2121: help to get information on how to use 2000 found at line 9: 7: Network Working Group Internet Architecture Board 8: Request for Comments: 2200 J. Postel, Editor 9: Obsoletes: 2000, 1920, 1880, 1800, 1780, June 1997 10: 1720, 1610, 1600, 1540, 1500, 1410, 1360, 11: 1280, 1250, 1200, 1140, 1130, 1100, 1083 2000 found at line 921: 919: level of standard. 920: 921: 2099 - Request for Comments Summary - RFC Numbers 2000-2099 922: 923: This is an information document and does not specify any +=+=+=+=+= File rfc2203.txt +=+=+=+=+= 2000 found at line 1096: 1094: GSS_S_GAP_TOKEN 0x00000010 1095: GSS_S_BAD_MECH 0x00010000 1096: GSS_S_BAD_NAME 0x00020000 1097: GSS_S_BAD_NAMETYPE 0x00030000 1098: GSS_S_BAD_BINDINGS 0x00040000 2000 found at line 1113: 1111: GSS_S_UNAVAILABLE 0x00100000 1112: GSS_S_DUPLICATE_ELEMENT 0x00110000 1113: GSS_S_NAME_NOT_MN 0x00120000 1114: GSS_S_CALL_INACCESSIBLE_READ 0x01000000 1115: GSS_S_CALL_INACCESSIBLE_WRITE 0x02000000 2000 found at line 1115: 1113: GSS_S_NAME_NOT_MN 0x00120000 1114: GSS_S_CALL_INACCESSIBLE_READ 0x01000000 1115: GSS_S_CALL_INACCESSIBLE_WRITE 0x02000000 1116: GSS_S_CALL_BAD_STRUCTURE 0x03000000 1117: +=+=+=+=+= File rfc2204.txt +=+=+=+=+= 'yy' on a line without 'yyyy' found at line 292: 290: available for transmission. 291: 292: Date stamp (YYMMDD) 293: 294: A file qualifier indicating the date the Virtual File was made 'yy' on a line without 'yyyy' found at line 1866: 1864: | 1 | SFIDDSN | Virtual File Dataset Name | V X(26) | 1865: | 27 | SFIDRSV1 | Reserved | F X(9) | 1866: | 36 | SFIDDATE | Virtual File Date stamp, (YYMMDD) | V X(6) | 1867: | 42 | SFIDTIME | Virtual File Time stamp, (HHMMSS) | V X(6) | 1868: | 48 | SFIDUSER | User Data | V X(8) | 'yy' on a line without 'yyyy' found at line 1895: 1893: SFIDDATE Virtual File Date stamp String(6) 1894: 1895: Format: 'YYMMDD' 6 decimal digits representing the year, month 1896: and day respectively [ISO-8601]. 1897: 'yy' on a line without 'yyyy' found at line 2394: 2392: | 1 | EERPDSN | Virtual File Dataset Name | V X(26) | 2393: | 27 | EERPRSV1 | Reserved | F X(9) | 2394: | 36 | EERPDATE | Virtual File Date stamp, (YYMMDD) | V X(6) | 2395: | 42 | EERPTIME | Virtual File Time stamp, (HHMMSS) | V X(6) | 2396: | 48 | EERPUSER | User Data | V X(8) | 'yy' on a line without 'yyyy' found at line 2429: 2427: EERPDATE Virtual File Date stamp String(6) 2428: 2429: Format: 'YYMMDD' 6 decimal digits representing the year, month 2430: and day respectively [ISO-8601]. 2431: 2000 found at line 304: 302: field. Since the ODETTE-FTP only uses this information to identify a 303: particular Virtual File it will continue to operate correctly in the 304: year 2000 and beyond. 305: 306: The User Monitor may use the Virtual File Date attribute in local 2000 found at line 308: 306: The User Monitor may use the Virtual File Date attribute in local 307: processes involving date comparisons and calculations. Any such use 308: falls outside the scope of this protocol and year 2000 handling is a 309: local implementation issue. 310: +=+=+=+=+= File rfc2227.txt +=+=+=+=+= 2000 found at line 1949: 1947: Toward the Development of Web Measurement Standards. This is a 1948: draft paper, currently available at http:// 1949: www2000.ogsm.vanderbilt.edu/novak/web.standards/webstand.html. 1950: Cited by permission of the author; do not quote or cite without 1951: permission. +=+=+=+=+= File rfc2234.txt +=+=+=+=+= 2-digit found at line 424: 422: 423: That is, exactly <N> occurrences of <element>. Thus 2DIGIT is a 424: 2-digit number, and 3ALPHA is a string of three alphabetic 425: characters. 426: 2digit found at line 423: 421: <n>*<n>element 422: 423: That is, exactly <N> occurrences of <element>. Thus 2DIGIT is a 424: 2-digit number, and 3ALPHA is a string of three alphabetic 425: characters. +=+=+=+=+= File rfc2235.txt +=+=+=+=+= 2000 found at line 862: 860: 861: 1997 862: 2000th RFC: "Internet Official Protocol Standards" 863: 864: 71,618 mailing lists registered at Liszt, a mailing list directory +=+=+=+=+= File rfc2244.txt +=+=+=+=+= 2digit found at line 3555: 3553: ;; Timestamp in UTC 3554: 3555: time-day = 2DIGIT ;; 01-31 3556: 3557: time-hour = 2DIGIT ;; 00-23 2digit found at line 3557: 3555: time-day = 2DIGIT ;; 01-31 3556: 3557: time-hour = 2DIGIT ;; 00-23 3558: 3559: time-minute = 2DIGIT ;; 00-59 2digit found at line 3559: 3557: time-hour = 2DIGIT ;; 00-23 3558: 3559: time-minute = 2DIGIT ;; 00-59 3560: 3561: time-month = 2DIGIT ;; 01-12 2digit found at line 3561: 3559: time-minute = 2DIGIT ;; 00-59 3560: 3561: time-month = 2DIGIT ;; 01-12 3562: 3563: time-second = 2DIGIT ;; 00-60 2digit found at line 3563: 3561: time-month = 2DIGIT ;; 01-12 3562: 3563: time-second = 2DIGIT ;; 00-60 3564: 3565: time-subsecond = *DIGIT 2000 found at line 2217: 2215: criteria): 2216: AND COMPARE "modtime" "+i;octet" "19951206103400" 2217: COMPARE "modtime" "-i;octet" "19960112000000" 2218: refers to all entries modified between 10:34 December 6 1995 and 2219: midnight January 12, 1996 UTC. +=+=+=+=+= File rfc2252.txt +=+=+=+=+= UTCTime found at line 1300: 1298: 1299: Values in this syntax are encoded as if they were printable strings 1300: with the strings containing a UTCTime value. This is historical; new 1301: attribute definitions SHOULD use GeneralizedTime instead. 1302: +=+=+=+=+= File rfc2261.txt +=+=+=+=+= 2000 found at line 1923: 1921: 1922: snmpFrameworkMIB MODULE-IDENTITY 1923: LAST-UPDATED "9711200000Z" -- 20 November 1997 1924: ORGANIZATION "SNMPv3 Working Group" 1925: CONTACT-INFO "WG-email: snmpv3@tis.com +=+=+=+=+= File rfc2262.txt +=+=+=+=+= 2000 found at line 818: 816: 817: snmpMPDMIB MODULE-IDENTITY 818: LAST-UPDATED "9711200000Z" -- 20 November 1997 819: ORGANIZATION "SNMPv3 Working Group" 820: CONTACT-INFO "WG-email: snmpv3@tis.com +=+=+=+=+= File rfc2264.txt +=+=+=+=+= 2000 found at line 1715: 1713: 1714: snmpUsmMIB MODULE-IDENTITY 1715: LAST-UPDATED "9711200000Z" -- 20 Nov 1997, midnight 1716: ORGANIZATION "SNMPv3 Working Group" 1717: CONTACT-INFO "WG-email: snmpv3@tis.com +=+=+=+=+= File rfc2265.txt +=+=+=+=+= 2000 found at line 554: 552: 553: snmpVacmMIB MODULE-IDENTITY 554: LAST-UPDATED "9711200000Z" -- 20 Nov 1997, midnight 555: ORGANIZATION "SNMPv3 Working Group" 556: CONTACT-INFO "WG-email: snmpv3@tis.com +=+=+=+=+= File rfc2271.txt +=+=+=+=+= 2000 found at line 1923: 1921: 1922: snmpFrameworkMIB MODULE-IDENTITY 1923: LAST-UPDATED "9711200000Z" -- 20 November 1997 1924: ORGANIZATION "SNMPv3 Working Group" 1925: CONTACT-INFO "WG-email: snmpv3@tis.com +=+=+=+=+= File rfc2272.txt +=+=+=+=+= 2000 found at line 818: 816: 817: snmpMPDMIB MODULE-IDENTITY 818: LAST-UPDATED "9711200000Z" -- 20 November 1997 819: ORGANIZATION "SNMPv3 Working Group" 820: CONTACT-INFO "WG-email: snmpv3@tis.com +=+=+=+=+= File rfc2274.txt +=+=+=+=+= 2000 found at line 1715: 1713: 1714: snmpUsmMIB MODULE-IDENTITY 1715: LAST-UPDATED "9711200000Z" -- 20 Nov 1997, midnight 1716: ORGANIZATION "SNMPv3 Working Group" 1717: CONTACT-INFO "WG-email: snmpv3@tis.com +=+=+=+=+= File rfc2275.txt +=+=+=+=+= 2000 found at line 554: 552: 553: snmpVacmMIB MODULE-IDENTITY 554: LAST-UPDATED "9711200000Z" -- 20 Nov 1997, midnight 555: ORGANIZATION "SNMPv3 Working Group" 556: CONTACT-INFO "WG-email: snmpv3@tis.com +=+=+=+=+= File rfc2280.txt +=+=+=+=+= 2000 found at line 2119: 2117: missing, they default to: 2118: 2119: flap_damp(1000, 2000, 750, 900, 900, 20000) 2120: 2121: That is, a penalty of 1000 is assigned at each route flap, the route 2000 found at line 2122: 2120: 2121: That is, a penalty of 1000 is assigned at each route flap, the route 2122: is suppressed when penalty reaches 2000. The penalty is reduced in 2123: half after 15 minutes (900 seconds) of stability regardless of 2124: whether the route is up or down. A supressed route is reused when +=+=+=+=+= File rfc2281.txt +=+=+=+=+= 1900 found at line 854: 852: Santa Clara, CA 95054 853: 854: Phone: (408) 327-1900 855: EMail: tli@juniper.net 856: 1900 found at line 863: 861: Santa Clara, CA 95054 862: 863: Phone: (408) 327-1900 864: EMail: cole@juniper.net 865: +=+=+=+=+= File rfc2287.txt +=+=+=+=+= 'yy' on a line without 'yyyy' found at line 1439: 1437: DESCRIPTION 1438: "The full path and filename of the process. 1439: For example, '/opt/MYYpkg/bin/myyproc' would 1440: be returned for process 'myyproc' whose execution 1441: path is '/opt/MYYpkg/bin/myyproc'." 'yy' on a line without 'yyyy' found at line 1440: 1438: "The full path and filename of the process. 1439: For example, '/opt/MYYpkg/bin/myyproc' would 1440: be returned for process 'myyproc' whose execution 1441: path is '/opt/MYYpkg/bin/myyproc'." 1442: ::= { sysApplElmtRunEntry 7 } 'yy' on a line without 'yyyy' found at line 1441: 1439: For example, '/opt/MYYpkg/bin/myyproc' would 1440: be returned for process 'myyproc' whose execution 1441: path is '/opt/MYYpkg/bin/myyproc'." 1442: ::= { sysApplElmtRunEntry 7 } 1443: 'yy' on a line without 'yyyy' found at line 1706: 1704: DESCRIPTION 1705: "The full path and filename of the process. 1706: For example, '/opt/MYYpkg/bin/myyproc' would 1707: be returned for process 'myyproc' whose execution 1708: path was '/opt/MYYpkg/bin/myyproc'." 'yy' on a line without 'yyyy' found at line 1707: 1705: "The full path and filename of the process. 1706: For example, '/opt/MYYpkg/bin/myyproc' would 1707: be returned for process 'myyproc' whose execution 1708: path was '/opt/MYYpkg/bin/myyproc'." 1709: ::= { sysApplElmtPastRunEntry 6 } 'yy' on a line without 'yyyy' found at line 1708: 1706: For example, '/opt/MYYpkg/bin/myyproc' would 1707: be returned for process 'myyproc' whose execution 1708: path was '/opt/MYYpkg/bin/myyproc'." 1709: ::= { sysApplElmtPastRunEntry 6 } 1710: 2000 found at line 402: 400: 401: sysApplMIB MODULE-IDENTITY 402: LAST-UPDATED "9710200000Z" 403: ORGANIZATION "IETF Applications MIB Working Group" 404: CONTACT-INFO +=+=+=+=+= File rfc2292.txt +=+=+=+=+= 2000 found at line 547: 545: #define ND_NA_FLAG_ROUTER 0x80000000 546: #define ND_NA_FLAG_SOLICITED 0x40000000 547: #define ND_NA_FLAG_OVERRIDE 0x20000000 548: #else /* BYTE_ORDER == LITTLE_ENDIAN */ 549: #define ND_NA_FLAG_ROUTER 0x00000080 +=+=+=+=+= File rfc2298.txt +=+=+=+=+= 2000 found at line 1310: 1308: Date: Wed, 20 Sep 1995 00:19:00 (EDT) -0400 1309: From: Joe Recipient <Joe_Recipient@mega.edu> 1310: Message-Id: <199509200019.12345@mega.edu> 1311: Subject: Disposition notification 1312: To: Jane Sender <Jane_Sender@huge.com> +=+=+=+=+= File rfc2300.txt +=+=+=+=+= 2000 found at line 9: 7: Network Working Group Internet Architecture Board 8: Request for Comments: 2300 J. Postel, Editor 9: Obsoletes: 2200, 2000, 1920, 1880, 1800, May 1998 10: 1780, 1720, 1610, 1600, 1540, 1500, 1410, 11: 1360, 1280, 1250, 1200, 1140, 1130, 1100, 1083 +=+=+=+=+= File rfc2308.txt +=+=+=+=+= 'yy' on a line without 'yyyy' found at line 873: 871: NS2.XX.EXAMPLE. 600 IN NXT XX.EXAMPLE. NXT A NXT SIG 872: NS2.XX.EXAMPLE. 600 IN SIG NXT ... XX.EXAMPLE. ... 873: EXAMPLE. 65799 IN NS NS1.YY.EXAMPLE. 874: EXAMPLE. 65799 IN NS NS2.YY.EXAMPLE. 875: EXAMPLE. 65799 IN SIG NS ... XX.EXAMPLE. ... 'yy' on a line without 'yyyy' found at line 874: 872: NS2.XX.EXAMPLE. 600 IN SIG NXT ... XX.EXAMPLE. ... 873: EXAMPLE. 65799 IN NS NS1.YY.EXAMPLE. 874: EXAMPLE. 65799 IN NS NS2.YY.EXAMPLE. 875: EXAMPLE. 65799 IN SIG NS ... XX.EXAMPLE. ... 876: Additional 'yy' on a line without 'yyyy' found at line 879: 877: XX.EXAMPLE. 65800 IN KEY 0x4100 1 1 ... 878: XX.EXAMPLE. 65800 IN SIG KEY ... EXAMPLE. ... 879: NS1.YY.EXAMPLE. 65799 IN A 10.100.0.1 880: NS1.YY.EXAMPLE. 65799 IN SIG A ... EXAMPLE. ... 881: NS2.YY.EXAMPLE. 65799 IN A 10.100.0.2 'yy' on a line without 'yyyy' found at line 880: 878: XX.EXAMPLE. 65800 IN SIG KEY ... EXAMPLE. ... 879: NS1.YY.EXAMPLE. 65799 IN A 10.100.0.1 880: NS1.YY.EXAMPLE. 65799 IN SIG A ... EXAMPLE. ... 881: NS2.YY.EXAMPLE. 65799 IN A 10.100.0.2 882: NS3.YY.EXAMPLE. 65799 IN SIG A ... EXAMPLE. ... 'yy' on a line without 'yyyy' found at line 881: 879: NS1.YY.EXAMPLE. 65799 IN A 10.100.0.1 880: NS1.YY.EXAMPLE. 65799 IN SIG A ... EXAMPLE. ... 881: NS2.YY.EXAMPLE. 65799 IN A 10.100.0.2 882: NS3.YY.EXAMPLE. 65799 IN SIG A ... EXAMPLE. ... 883: EXAMPLE. 65799 IN KEY 0x4100 1 1 ... 'yy' on a line without 's administrative element is directed by the bundle protocol agent to generate an administrative record with reference to some bundle, the following procedure must be followed: Step 1: The administrative record must be constructed. If the referenced bundle is a fragment, the administrative record MUST contain the fragment offset and fragment length. Step 2: A request for transmission of a bundle whose payload is this administrative record MUST be presented to the bundle protocol agent. 6.3. Reception of Custody Signals For each received custody signal that has the "custody transfer succeeded" flag set to 1, the administrative element of the Burleigh Expires July 2016 [Page 37] Internet-Draft Proposed Revised Bundle Protocol January 20166 application agent MUST direct the bundle protocol agent to follow the custody transfer success procedure in Section 5.11. For each received custody signal that has the "custody transfer succeeded" flag set to 0, the administrative element of the application agent MUST direct the bundle protocol agent to follow the custody transfer failure procedure in Section 5.12. 7. Services Required of the Convergence Layer 7.1. The Convergence Layer The successful operation of the end-to-end bundle protocol depends on the operation of underlying protocols at what is termed the "convergence layer"; these protocols accomplish communication between nodes. A wide variety of protocols may serve this purpose, so long as each convergence layer protocol adapter provides a defined minimal set of services to the bundle protocol agent. This convergence layer service specification enumerates those services. 7.2. Summary of Convergence Layer Services Each convergence layer protocol adapter is expected to provide the following services to the bundle protocol agent: . sending a bundle to a bundle node that is reachable via the convergence layer protocol; . delivering to the bundle protocol agent a bundle that was sent by a bundle node via the convergence layer protocol. The convergence layer service interface specified here is neither exhaustive nor exclusive. That is, supplementary DTN protocol specifications (including, but not restricted to, the Bundle Security Protocol [BPSEC]) may expect convergence layer adapters that serve BP implementations conforming to those protocols to provide additional services such as retransmitting data that were lost in transit, discarding bundle-conveying data units that the convergence layer protocol determines are corrupt or inauthentic, or reporting on the integrity and/or authenticity of delivered bundles. 8. Security Considerations The bundle protocol has taken security into concern from the outset of its design. It was always assumed that security services would be needed in the use of the bundle protocol. As a result, the bundle protocol security architecture and the available security services are specified in an accompanying document, the Bundle Security Burleigh Expires July 2016 [Page 38] Internet-Draft Proposed Revised Bundle Protocol January 20166 Protocol specification [BPSEC]; an informative overview of this architecture is provided in [SECO]. The bundle protocol has been designed with the notion that it may be run over networks with scarce resources. For example, the networks might have limited bandwidth, limited connectivity, constrained storage in relay nodes, etc. Therefore, the bundle protocol must ensure that only those entities authorized to send bundles over such constrained environments are actually allowed to do so. All unauthorized entities should be prevented from consuming valuable resources as soon as practicable. Likewise, because of the potentially high latencies and delays involved in the networks that make use of the bundle protocol, data sources should be concerned with the integrity of the data received at the intended destination(s) and may also be concerned with ensuring confidentiality of the data as it traverses the network. Without integrity, the bundle payload data might be corrupted while in transit without the destination able to detect it. Similarly, the data source can be concerned with ensuring that the data can only be used by those authorized, hence the need for confidentiality. Internal to the bundle-aware overlay network, the bundle nodes should be concerned with the authenticity of other bundle nodes as well as the preservation of bundle payload data integrity as it is forwarded between bundle nodes. As a result, bundle security is concerned with the authenticity, integrity, and confidentiality of bundles conveyed among bundle nodes. This is accomplished via the use of two independent security- specific bundle blocks, which may be used together to provide multiple bundle security services or independently of one another, depending on perceived security threats, mandated security requirements, and security policies that must be enforced. To provide end-to-end bundle authenticity and integrity, the Block Integrity Block (BIB) is used. The BIB allows any security-enabled entity along the delivery path to ensure the integrity of the bundle's payload or any other block other than a Block Confidentiality Block. To provide payload confidentiality, the use of the Block Confidentiality Block (BCB) is available. The bundle payload, or any other block aside from the primary block and the Bundle Security Protocol blocks, may be encrypted to provide end-to-end payload confidentiality/privacy. Burleigh Expires July 2016 [Page 39] Internet-Draft Proposed Revised Bundle Protocol January 20166 Additionally, convergence-layer protocols that ensure authenticity of communication between adjacent nodes in BP network topology SHOULD be used where available, to minimize the ability of unauthenticated nodes to introduce inauthentic traffic into the network. Bundle security MUST NOT be invalidated by forwarding nodes even though they themselves might not use the Bundle Security Protocol. In particular, while blocks MAY be added to bundles transiting intermediate nodes, removal of blocks with the 'Discard block if it can't be processed' flag unset in the block processing control flags may cause security to fail. Inclusion of the Bundle Security Protocol in any Bundle Protocol implementation is RECOMMENDED. Use of the Bundle Security Protocol in Bundle Protocol operations is OPTIONAL. 9. IANA Considerations The "dtn" and "ipn" URI schemes have been provisionally registered by IANA. See http://www.iana.org/assignments/uri-schemes.html for the latest details. Registries of scheme type numbers, extension block type numbers, and administrative record type numbers will be required. 10. References 10.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [URI] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform Resource Identifier (URI): Generic Syntax", RFC 3986, STD 66, January 2005. [URIREG] Thaler, D., Hansen, T., and T. Hardie, "Guidelines and Registration Procedures for URI Schemes", RFC 7595, BCP 35, June 2015. 10.2. Informative References [ARCH] V. Cerf et al., "Delay-Tolerant Network Architecture", RFC 4838, April 2007. Burleigh Expires July 2016 [Page 40] Internet-Draft Proposed Revised Bundle Protocol January 20166 [ASN1] "Abstract Syntax Notation One (ASN.1), "ASN.1 Encoding Rules: Specification of Basic Encoding Rules (BER), Canonical Encoding Rules (CER) and Distinguished Encoding Rules (DER)," ITU-T Rec. X.690 (2002) | ISO/IEC 8825- 1:2002", 2003. [BPSEC] Birrane, E., "Bundle Security Protocol Specification", Work In Progress, October 2015. [RFC3987] Duerst, M. and M. Suignard, "Internationalized Resource Identifiers (IRIs)", RFC 3987, January 2005. [RFC5050] Scott, M. and S. Burleigh, "Bundle Protocol Specification", RFC 5050, November 2007. [SECO] Farrell, S., Symington, S., Weiss, H., and P. Lovell, "Delay- Tolerant Networking Security Overview", Work Progress, July 2007. [SIGC] Fall, K., "A Delay-Tolerant Network Architecture for Challenged Internets", SIGCOMM 2003. [TUT] Warthman, F., "Delay-Tolerant Networks (DTNs): A Tutorial", <http://www.dtnrg.org>. [UTC] Arias, E. and B. Guinot, "Coordinated universal time UTC: historical background and perspectives" in "Journees systemes de reference spatio-temporels", 2004. 11. Acknowledgments This work is freely adapted from [RFC5050], which was an effort of the Delay Tolerant Networking Research Group. The following DTNRG participants contributed significant technical material and/or inputs to that document: Dr. Vinton Cerf of Google, Scott Burleigh, Adrian Hooke, and Leigh Torgerson of the Jet Propulsion Laboratory, Michael Demmer of the University of California at Berkeley, Robert Durst, Keith Scott, and Susan Symington of The MITRE Corporation, Kevin Fall of Carnegie Mellon University, Stephen Farrell of Trinity College Dublin, Peter Lovell of SPARTA, Inc., Manikantan Ramadas of Ohio University, and Howard Weiss of SPARTA, Inc. This document was prepared using 2-Word-v2.0.template.dot. 12. Significant Changes from RFC 5050 Points on which this draft significantly differs from RFC 5050 include the following: Burleigh Expires July 2016 [Page 41] Internet-Draft Proposed Revised Bundle Protocol January 20166 . Clarify the difference between transmission and forwarding. . Amplify discussion of custody transfer. Move current custodian to an extension block, of which there can be multiple occurrences (possible support for the MITRE idea of multiple concurrent custodians, from several years ago); define that block in this specification. . Introduce the concept of "node ID" as functionally distinct from endpoint ID, while having the same syntax. . Restructure primary block, making it immutable. Add optional CRC. . Add optional CRCs to non-primary blocks. . Add block ID number to canonical block format (to support streamlined BSP). . Add bundle age extension block, defined in this specification. . Add previous node ID extension block, defined in this specification. . Add flow label block, *not* defined in this specification. . Add hop count extension block, defined in this specification. . Clean up a conflict between fragmentation and custody transfer that Ed Birrane pointed out. . Remove representation specifications from the document, making the protocol specification representation-neutral. 13. Open Issues 13.1. Application Agent Need to add a diagram explaining how the various components of the BPA interact. 13.2. Primary block CRC type What are the best CRC options to support here? CRC-16-ARINC, CRC- 16-CCITT, CRC-16-CDMA2000, CRC-16-DECT, etc.? #x27;yyyy' found at line 882: 880: NS1.YY.EXAMPLE. 65799 IN SIG A ... EXAMPLE. ... 881: NS2.YY.EXAMPLE. 65799 IN A 10.100.0.2 882: NS3.YY.EXAMPLE. 65799 IN SIG A ... EXAMPLE. ... 883: EXAMPLE. 65799 IN KEY 0x4100 1 1 ... 884: EXAMPLE. 65799 IN SIG KEY ... . ... 2000 found at line 805: 803: $ORIGIN XX.EXAMPLE. 804: @ IN SOA NS1.XX.EXAMPLE. HOSTMATER.XX.EXAMPLE. ( 805: 1997102000 ; serial 806: 1800 ; refresh (30 mins) 807: 900 ; retry (15 mins) +=+=+=+=+= File rfc2311.txt +=+=+=+=+= 'yy' on a line without 'yyyy' found at line 269: 267: Sending agents MUST encode signing time through the year 2049 as 268: UTCTime; signing times in 2050 or later MUST be encoded as 269: GeneralizedTime. Agents MUST interpret the year field (YY) as 270: follows: if YY is greater than or equal to 50, the year is 271: interpreted as 19YY; if YY is less than 50, the year is interpreted 'yy' on a line without 'yyyy' found at line 270: 268: UTCTime; signing times in 2050 or later MUST be encoded as 269: GeneralizedTime. Agents MUST interpret the year field (YY) as 270: follows: if YY is greater than or equal to 50, the year is 271: interpreted as 19YY; if YY is less than 50, the year is interpreted 272: as 20YY. 'yy' on a line without 'yyyy' found at line 271: 269: GeneralizedTime. Agents MUST interpret the year field (YY) as 270: follows: if YY is greater than or equal to 50, the year is 271: interpreted as 19YY; if YY is less than 50, the year is interpreted 272: as 20YY. 273: 'yy' on a line without 'yyyy' found at line 272: 270: follows: if YY is greater than or equal to 50, the year is 271: interpreted as 19YY; if YY is less than 50, the year is interpreted 272: as 20YY. 273: 274: 2.5.2 S/MIME Capabilities Attribute UTCTime found at line 268: 266: 267: Sending agents MUST encode signing time through the year 2049 as 268: UTCTime; signing times in 2050 or later MUST be encoded as 269: GeneralizedTime. Agents MUST interpret the year field (YY) as 270: follows: if YY is greater than or equal to 50, the year is 1900 found at line 1972: 1970: Mountain View, CA 94043 1971: 1972: Phone: (415) 254-1900 1973: EMail: repka@netscape.com 1974: +=+=+=+=+= File rfc2312.txt +=+=+=+=+= 1900 found at line 1049: 1047: Mountain View, CA 94043 1048: 1049: Phone: (415) 254-1900 1050: EMail: jsw@netscape.com 1051: +=+=+=+=+= File rfc2326.txt +=+=+=+=+= 2digit found at line 906: 904: smpte-type = "smpte" | "smpte-30-drop" | "smpte-25" 905: ; other timecodes may be added 906: smpte-time = 1*2DIGIT ":" 1*2DIGIT ":" 1*2DIGIT [ ":" 1*2DIGIT ] 907: [ "." 1*2DIGIT ] 908: 2digit found at line 907: 905: ; other timecodes may be added 906: smpte-time = 1*2DIGIT ":" 1*2DIGIT ":" 1*2DIGIT [ ":" 1*2DIGIT ] 907: [ "." 1*2DIGIT ] 908: 909: Examples: 2digit found at line 940: 938: npt-hhmmss = npt-hh ":" npt-mm ":" npt-ss [ "." *DIGIT ] 939: npt-hh = 1*DIGIT ; any positive number 940: npt-mm = 1*2DIGIT ; 0-59 941: npt-ss = 1*2DIGIT ; 0-59 942: 2digit found at line 941: 939: npt-hh = 1*DIGIT ; any positive number 940: npt-mm = 1*2DIGIT ; 0-59 941: npt-ss = 1*2DIGIT ; 0-59 942: 943: Examples: +=+=+=+=+= File rfc2332.txt +=+=+=+=+= 1900 found at line 2839: 2837: 1620 Tuckerstown Road 3260 Jay St. 2838: Dresher, PA 19025 USA Santa Clara, CA 95054 2839: Phone: +1 215 830 0692 Phone: +1 408 327 1900 2840: EMail: dave@corecom.com EMail: bcole@jnx.com 2841: +=+=+=+=+= File rfc2353.txt +=+=+=+=+= 2000 found at line 211: 209: native IP DLC, this field is not used to convey a port number for 210: replies; moreover, the zero setting is not used. IANA has registered 211: port numbers 12000 through 12004 for use in these two fields by the 212: native IP DLC; use of these port numbers allows prioritization in the 213: IP network. For more details of the use of these fields, see 2.6.1, 2000 found at line 1694: 1692: 1693: At an intermediate HPR node, link activation failure can be reported 1694: with sense data X'08010000' or X'80020000'. At a node with route- 1695: selection responsibility, such failure can be reported with sense 1696: data X'80140001'. 2000 found at line 1841: 1839: | the same connection network. | | 1840: +--------------------------------------------------------+-------------+ 1841: | Link failure | X'80020000' | 1842: +--------------------------------------------------------+-------------+ 1843: | Route selection services has determined that no path | X'80140001' | 2000 found at line 1868: 1866: will be able to exploit routers that provide priority function. 1867: 1868: The 5 UDP port numbers, 12000-12004 (decimal), have been assigned by 1869: the Internet Assigned Number Authority (IANA). Four of these port 1870: numbers are used for ANR-routed network layer packets (NLPs) and 2000 found at line 1872: 1870: numbers are used for ANR-routed network layer packets (NLPs) and 1871: correspond to the APPN transmission priorities (network, 12001; high, 1872: 12002; medium, 12003; and low, 12004), and one port number (12000) is 1873: used for a set of LLC commands (i.e., XID, TEST, DISC, and DM) and 1874: function-routed NLPs (i.e., XID_DONE_RQ and XID_DONE_RSP). These 2000 found at line 2417: 2415: the source port number is not relevant. That is, the firewall should 2416: accept traffic with the IP addresses of the HPR/IP nodes and with 2417: destination port numbers in the range 12000 to 12004. Second, the 2418: possibility exists for an attack using forged UDP datagrams; such 2419: attacks could cause the RTP connection to fail or even introduce +=+=+=+=+= File rfc2355.txt +=+=+=+=+= 2000 found at line 1488: 1486: 0x00 Command Reject 0x10030000 1487: 1488: 0x01 Intervention Required 0x08020000 1489: 1490: 0x02 Operation Check 0x10050000 +=+=+=+=+= File rfc2361.txt +=+=+=+=+= 'yy' on a line without 'yyyy' found at line 30: 28: * video/vnd.avi; codec=XXX identifies a specific video codec (i.e., 29: XXX) within the AVI Registry. 30: * audio/vnd.wave; codec=YYY identifies a specific audio codec 31: (i.e., YYY) within the WAVE Registry. 32: 'yy' on a line without 'yyyy' found at line 31: 29: XXX) within the AVI Registry. 30: * audio/vnd.wave; codec=YYY identifies a specific audio codec 31: (i.e., YYY) within the WAVE Registry. 32: 33: Appendix A and Appendix B provides an authoritative reference for the 2000 found at line 354: 352: Compaq Computer Corporation 353: 20555 SH 249 354: Houston, TX 77269-2000 USA 355: 356: A.6 IBM CVSD 2000 found at line 1474: 1472: PO Box 582 1473: Stellenbosch Stellenbosch South Africa 1474: 27 21 888 2000 1475: 1476: A.75 DF GSM610 2000 found at line 1487: 1485: PO Box 582 1486: Stellenbosch 7600 South Africa 1487: 27 21 888 2000 1488: 1489: A.76 ISIAudio 2000 found at line 1545: 1543: 4900 Old Ironsides Drive 1544: Santa Clara, California 95054 USA 1545: (408) 492-2000 1546: 1547: A.79 Dolby AC3 SPDIF 2000 found at line 1993: 1991: A.104 DVM 1992: 1993: WAVE form Registration Number (hex): 0x2000 1994: Codec ID in the IANA Namespace: audio/vnd.wave;codec=2000 1995: WAVE form wFormatTag ID: WAVE_FORMAT_DVM 2000 found at line 1994: 1992: 1993: WAVE form Registration Number (hex): 0x2000 1994: Codec ID in the IANA Namespace: audio/vnd.wave;codec=2000 1995: WAVE form wFormatTag ID: WAVE_FORMAT_DVM 1996: Contact: 2000 found at line 3180: 3178: 707 California Street 3179: Mountain View, California 94041 USA 3180: 650-526-2000 3181: 3182: 2000 found at line 3211: 3209: 707 California Street 3210: Mountain View, California 94041 USA 3211: 650-526-2000 3212: 3213: B.83 TrueMotion 2.0 2000 found at line 3239: 3237: 707 California Street 3238: Mountain View, California 94041 USA 3239: 650-526-2000 3240: 3241: +=+=+=+=+= File rfc2368.txt +=+=+=+=+= two-digit found at line 240: 238: scheme is not a problem: those characters may appear in mailto URLs, 239: they just may not appear in unencoded form. The standard URL encoding 240: mechanisms ("%" followed by a two-digit hex number) must be used in 241: certain cases. 242: +=+=+=+=+= File rfc2373.txt +=+=+=+=+= 2digit found at line 1192: 1190: IPv4address = 1*3DIGIT "." 1*3DIGIT "." 1*3DIGIT "." 1*3DIGIT 1191: 1192: IPv6prefix = hexpart "/" 1*2DIGIT 1193: 1194: hexpart = hexseq | hexseq "::" [ hexseq ] | "::" [ hexseq ] +=+=+=+=+= File rfc2378.txt +=+=+=+=+= 2digit found at line 1078: 1076: response = code [index] [field] text CRLF 1077: 1078: code = [-] LDIG 2DIGIT ":" 1079: index = number ":" 1080: field = 1*SPACE attribute ":" 1*SPACE +=+=+=+=+= File rfc2389.txt +=+=+=+=+= 2digit found at line 133: 131: 132: error-response = error-code SP *TCHAR CRLF 133: error-code = ("4" / "5") 2DIGIT 134: 135: Note that in ABNF, strings literals are case insensitive. That +=+=+=+=+= File rfc2397.txt +=+=+=+=+= 'yy' on a line without 'yyyy' found at line 107: 105: a/TPg7JpJHxyendzWTBfX0cxOnKPjgBzi4diinWGdkF8kjdfnycQZXZeYGejmJl 106: ZeGl9i2icVqaNVailT6F5iJ90m6mvuTS4OK05M0vDk0Q4XUtwvKOzrcd3iq9uis 107: F81M1OIcR7lEewwcLp7tuNNkM3uNna3F2JQFo97Vriy/Xl4/f1cf5VWzXyym7PH 108: hhx4dbgYKAAA7" 109: ALT="Larry"> +=+=+=+=+= File rfc2400.txt +=+=+=+=+= 2000 found at line 9: 7: Network Working Group Internet Architecture Board 8: Request for Comments: 2400 J. Postel 9: Obsoletes: 2300, 2200, 2000, 1920, 1880, J. Reynolds 10: 1800, 1780, 1720, 1610, 1600, 1540, 1500, 1410, Editors 11: 1360, 1280, 1250, 1200, 1140, 1130, 1100, 1083 September 1998 +=+=+=+=+= File rfc2407.txt +=+=+=+=+= 2000 found at line 832: 830: 831: Attribute #2: 832: 0x00020004 (AF = 0, type = SA Duration, length = 4 bytes) 833: 0x00015180 (value = 0x15180 = 86400 seconds = 24 hours) 834: 2000 found at line 848: 846: 847: Attribute #4: 848: 0x00020004 (AF = 0, type = SA Duration, length = 4 bytes) 849: 0x000186A0 (value = 0x186A0 = 100000KB = 100MB) 850: +=+=+=+=+= File rfc2409.txt +=+=+=+=+= 2000 found at line 1257: 1255: Field Size: 185 1256: Group Prime/Irreducible Polynomial: 1257: 0x020000000000000000000000000000200000000000000001 1258: Group Generator One: 0x18 1259: Group Curve A: 0x0 +=+=+=+=+= File rfc2412.txt +=+=+=+=+= 2000 found at line 1689: 1687: As of early 1996, it appears that for 90 bits of cryptographic 1688: strength, one should use a modular exponentiation group modulus of 1689: 2000 bits. For 128 bits of strength, a 3000 bit modulus is required. 1690: 1691: 3. Specifying and Deriving Security Associations 2000 found at line 2761: 2759: Length (32 bit words): 6 2760: Data (hex): 2761: 02000000 00000000 00000000 00000020 00000000 00000001 2762: Generator: 2763: X coordinate: 22 (decimal) 2000 found at line 2976: 2974: 2975: [Stinson] Stinson, Douglas, Cryptography Theory and Practice. CRC 2976: Press, Inc., 2000, Corporate Blvd., Boca Raton, FL, 2977: 33431-9868, ISBN 0-8493-8521-0, 1995 2978: +=+=+=+=+= File rfc2425.txt +=+=+=+=+= 'yy' on a line without 'yyyy' found at line 1106: 1104: 9ucyBDb3JwLjEYMBYGA1UEAxMPVGltb3RoeSBBIEhvd2VzMSEwHwYJKoZIhvcNAQkBF 1105: hJob3dlc0BuZXRzY2FwZS5jb20xFTATBgoJkiaJk/IsZAEBEwVob3dlczBcMA0GCSqG 1106: SIb3DQEBAQUAA0sAMEgCQQC0JZf6wkg8pLMXHHCUvMfL5H6zjSk4vTTXZpYyrdN2dXc 1107: oX49LKiOmgeJSzoiFKHtLOIboyludF90CgqcxtwKnAgMBAAGjNjA0MBEGCWCGSAGG+E 1108: IBAQQEAwIAoDAfBgNVHSMEGDAWgBT84FToB/GV3jr3mcau+hUMbsQukjANBgkqhkiG9 +=+=+=+=+= File rfc2426.txt +=+=+=+=+= 'yy' on a line without 'yyyy' found at line 1479: 1477: MPVGltb3RoeSBBIEhvd2VzMSEwHwYJKoZIhvcNAQkBFhJob3dlc0BuZXRz 1478: Y2FwZS5jb20xFTATBgoJkiaJk/IsZAEBEwVob3dlczBcMA0GCSqGSIb3DQ 1479: EBAQUAA0sAMEgCQQC0JZf6wkg8pLMXHHCUvMfL5H6zjSk4vTTXZpYyrdN2 1480: dXcoX49LKiOmgeJSzoiFKHtLOIboyludF90CgqcxtwKnAgMBAAGjNjA0MB 1481: EGCWCGSAGG+EIBAQQEAwIAoDAfBgNVHSMEGDAWgBT84FToB/GV3jr3mcau 2-digit found at line 372: 370: and minutes (e.g., +hh:mm). The time is specified as a 24-hour clock. 371: Hour values are from 00 to 23, and minute values are from 00 to 59. 372: Hour and minutes are 2-digits with high order zeroes required to 373: maintain digit count. The extended format for ISO 8601 UTC offsets 374: MUST be used. The extended format makes use of a colon character as a 2digit found at line 379: 377: The value is defined by the following notation: 378: 379: time-hour = 2DIGIT ;00-23 380: time-minute = 2DIGIT ;00-59 381: utc-offset = ("+" / "-") time-hour ":" time-minute 2digit found at line 380: 378: 379: time-hour = 2DIGIT ;00-23 380: time-minute = 2DIGIT ;00-59 381: utc-offset = ("+" / "-Burleigh Expires July 2016 [Page 42] Internet-Draft Proposed Revised Bundle Protocol January 20166 Appendix A. For More Information Please refer comments to dtn@ietf.org. The Delay Tolerant Networking Research Group (DTNRG) Web site is located at http://www.dtnrg.org. Copyright (c) 2016 IETF Trust and the persons identified as authors of the code. All rights reserved. Redistribution and use in source and binary forms, with or without modification, is permitted pursuant to, and subject to the license terms contained in, the Simplified BSD License set forth in Section 4.c of the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info). Authors' Addresses Scott Burleigh Jet Propulsion Laboratory, California Institute of Technology 4800 Oak Grove Dr. Pasadena, CA 91109-8099 US Phone: +1 818 393 3353 Email: Scott.Burleigh@jpl.nasa.gov Kevin Fall Carnegie Mellon University / Software Engineering Institute 4500 Fifth Avenue Pittsburgh, PA 15213 US Phone: +1 412 268 3304 Email: kfall@cmu.edu Edward J. Birrane Johns Hopkins University Applied Physics Laboratory 11100 Johns Hopkins Rd Laurel, MD 20723 US Phone: +1 443 778 7423 Email: Edward.Birrane@jhuapl.edu Burleigh Expires July 2016 [Page 43]