From 4bfd864f10b68b71482b35c818559068ef8d5797 Mon Sep 17 00:00:00 2001 From: Thomas Voss Date: Wed, 27 Nov 2024 20:54:24 +0100 Subject: doc: Add RFC documents --- doc/rfc/rfc3342.txt | 1235 +++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 1235 insertions(+) create mode 100644 doc/rfc/rfc3342.txt (limited to 'doc/rfc/rfc3342.txt') diff --git a/doc/rfc/rfc3342.txt b/doc/rfc/rfc3342.txt new file mode 100644 index 0000000..c8b3181 --- /dev/null +++ b/doc/rfc/rfc3342.txt @@ -0,0 +1,1235 @@ + + + + + + +Network Working Group G. Klyne +Request for Comments: 3342 Clearswift Corporation +Category: Standards Track M. Rose + Dover Beach Consulting, Inc. + M. Schwartz + Code On The Road, LLC + E. Dixon + H. Franklin + J. Kint + D. New + S. Pead + July 2002 + + + The Application Exchange (APEX) Option Party Pack, Part Deux! + +Status of this Memo + + This document specifies an Internet standards track protocol for the + Internet community, and requests discussion and suggestions for + improvements. Please refer to the current edition of the "Internet + Official Protocol Standards" (STD 1) for the standardization state + and status of this protocol. Distribution of this memo is unlimited. + +Copyright Notice + + Copyright (C) The Internet Society (2002). All Rights Reserved. + +Abstract + + Application Exchange (APEX), at its core, provides a best-effort + application-layer datagram service. Options are used to alter the + semantics of the core service. This memo defines various options to + change the default behavior of APEX's "relaying mesh". + + + + + + + + + + + + + + + + + +Klyne, et. al. Standards Track [Page 1] + +RFC 3342 The Application Exchange (APEX) Party Pack July 2002 + + +Table of Contents + + 1. The attachOverride Option . . . . . . . . . . . . . . . . . 2 + 2. The dataTiming Option . . . . . . . . . . . . . . . . . . . 3 + 2.1 Upper-Bounds on Delivery . . . . . . . . . . . . . . . . . . 4 + 2.1.1 Final Hop Report . . . . . . . . . . . . . . . . . . . . . . 5 + 2.1.2 Timing Error Report . . . . . . . . . . . . . . . . . . . . 7 + 2.2 Reporting on Delayed Delivery . . . . . . . . . . . . . . . 8 + 2.2.1 Transient Timing Report . . . . . . . . . . . . . . . . . . 9 + 3. The hold4Endpoint Option . . . . . . . . . . . . . . . . . . 10 + 4. The dataHopping Option . . . . . . . . . . . . . . . . . . . 13 + 5. Initial Registrations . . . . . . . . . . . . . . . . . . . 15 + 5.1 Registration: The attachOverride Option . . . . . . . . . . 15 + 5.2 Registration: The dataTiming Option . . . . . . . . . . . . 16 + 5.3 Registration: The hold4Endpoint Option . . . . . . . . . . . 16 + 5.4 Registration: The dataHopping Option . . . . . . . . . . . . 16 + 6. The APEX Party Pack DTD . . . . . . . . . . . . . . . . . . 17 + 7. Security Considerations . . . . . . . . . . . . . . . . . . 18 + References . . . . . . . . . . . . . . . . . . . . . . . . . 18 + A. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 19 + B. IANA Considerations . . . . . . . . . . . . . . . . . . . . 19 + Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 20 + Full Copyright Statement . . . . . . . . . . . . . . . . . . 22 + +1. The attachOverride Option + + Section 5.1 contains the APEX option registration for the + "attachOverride" option. + + The default behavior of the APEX relaying mesh, in the absence of + processing options, is to allow at most one application to attach as + a particular endpoint, on a "first come, first served" basis. The + "attachOverride" option provides gives preference to the current + application trying to attach. + + If this option is present in the "attach" operation (c.f., Section + 4.4.1 of [1]) and if any application is already attached as the + specified endpoint, that endpoint has its attachment terminated + (c.f., Section 4.4.3 of [1]) concurrently with processing of that + "attach" operation. The "code" attribute of the resulting + "terminate" operation is set to 556. + + Note that any data being expected by the previously-attached + application may instead be delivered to the last application to + successfully attach. Accordingly, applications should take care to + properly deal with incoming data having unrecognized transaction- + identifiers (c.f., Section 6.1.1 of [1]). + + + + +Klyne, et. al. Standards Track [Page 2] + +RFC 3342 The Application Exchange (APEX) Party Pack July 2002 + + + This option provides for a new attachment to automatically terminate + any existing attachment for the same endpoint. For example, this + might be helpful when a new attachment is required from a different + device while a previously-used device is still attached e.g., + + +-------+ +-------+ + | | -- attach -----> | | + | appl. | | relay | + | #1 | <--------- ok -- | | + +-------+ +-------+ + + C: + S: + + ... some time later appl #2 starts on a different computer ... + + +-------+ +-------+ + | | <----- attach -- | | + +-------+ | | | appl. | + | | <-- terminate -- | relay | -- ok ---------> | #2 | + | appl. | | | +-------+ + | #1 | -- ok ---------> | | + +-------+ +-------+ + + C: + + S: + + C: overriden + S: + +2. The dataTiming Option + + Section 5.2 contains the APEX option registration for the + "dataTiming" option. This option contains a "dataTiming" element + (c.f., Section 6). + + The default behavior of the APEX relaying mesh is "immediate, best + effort", and expects that all relays and endpoints are able to + process and transfer data without delay -- in the absence of + processing options, if a relay is unavailable, then data is silently + dropped. The "dataTiming" option provides for controlled queuing + delays in processing, whilst providing reasonable deterministic + behavior for the originator. + + + + + + +Klyne, et. al. Standards Track [Page 3] + +RFC 3342 The Application Exchange (APEX) Party Pack July 2002 + + + There are two types of delays addressed by the "dataTiming" option: + + o delays in transit through the relaying mesh, possibly due to + intermittent or slow connections, or congested relays; and, + + o delays because the intended endpoint is not available to receive + the data, when used in conjunction with the hold4Endpoint option + (Section 3). + + Accordingly, the "dataTiming" option allows for: + + o data to be discarded if not delivered within a finite amount of + time as specified using the "noLaterThan" attribute (Section 2.1); + + o a "statusResponse" message (c.f., Section 5.1 of [1]) to be + generated if data is not delivered within a known amount of time + as specified using the "reportAfter" attribute (Section 2.2); and, + + o an upper limit on the amount of time for the "statusResponse" + message to be delivered using the "returnTrip" attribute (Section + 2.1.1), after which the sender may presume the message to be lost. + + This option does not provide any functionality with respect to the + priority of the data. Nor does this option have any effect on other + parts of the relaying process. + + Further, note that because this option is processed on a per-hop + basis, the originator must set the "targetHop" attribute to the value + "all" and the "mustUnderstand" attribute to the value "true". + +2.1 Upper-Bounds on Delivery + + The "noLaterThan" attribute of the "dataTiming" option provides for + control over delays that may occur in transit through the relaying + mesh or to the recipient endpoint. + + If this option is present in the "data" operation (c.f., Section + 4.4.4 of [1]) and the value of the "noLaterThan" attribute is non- + zero, then: + + o For Step 5.2 of Section 4.4.4.1 of [1]: + + Immediately prior to sending the data to the next relay, the value + of the "noLaterThan" attribute is adjusted to reflect the + processing time of the data at the local relay (e.g., the time + required to determine the next relay, to successfully issue a + "bind" operation, and then be ready to immediately issue a "data" + operation). + + + +Klyne, et. al. Standards Track [Page 4] + +RFC 3342 The Application Exchange (APEX) Party Pack July 2002 + + + If the value of the "noLaterThan" attribute becomes less than or + equal to zero, an error in processing has occurred, the data + element is not sent to the next relay, and if the "reportErrors" + attribute is true, the APEX report service is invoked to send a + timing error report. + + o For Step 5.3 of Section 4.4.4.1 of [1]: + + If the relay does not receive an "ok" element from the recipient + endpoint within the number of milli-seconds indicated by the value + of the "noLaterThan" attribute, an error in processing has + occurred, and if the "reportErrors" attribute is true, the APEX + report service is invoked to send a timing error report. + + Otherwise, if the data is successfully transmitted to the + recipient, and the "returnTrip" attribute is non-zero, the APEX + report service is invoked to send a final hop report. + + Note that in some cases, a relay may be able to predict this outcome + without actually connecting to the next relay; if so, a timing error + report may be sent without connecting to the next relay. + +2.1.1 Final Hop Report + + If the APEX report service (c.f., Section 6.2 of [1]) is invoked to + send a final hop report, it issues a data operation with: + + o its originator identifying the report service associated with the + issuing relay + + o its recipient identifying the endpoint address of the originator + associated with the "dataTiming" option + + o a new "dataTiming" option having: + + * its "noLaterThan" attribute equal to the "returnTrip" attribute + of the original "dataTiming" option + + * and no other attributes present + + o its content consisting of a "statusResponse" element having: + + * its "transID" attribute equal to the "transID" attribute of the + "dataTiming" option + + * and identifying the original recipient with a permanent success + indicator + + + + +Klyne, et. al. Standards Track [Page 5] + +RFC 3342 The Application Exchange (APEX) Party Pack July 2002 + + + For example: + + +-------+ +-------+ + | | -- data -------> | | + | relay | | appl. | + | | <--------- ok -- | #2 | + +-------+ +-------+ + + C: + + + + + S: + + +-------+ +-------+ + | | <------- data -- | | + | appl. | | relay | + | #1 | -- ok ---------> | | + +-------+ +-------+ + + C: + + + + + + + + + + + + S: + + + + + + + + + + + +Klyne, et. al. Standards Track [Page 6] + +RFC 3342 The Application Exchange (APEX) Party Pack July 2002 + + +2.1.2 Timing Error Report + + If the APEX report service (c.f., Section 6.2 of [1]) is invoked to + send a timing error report, it issues a data operation with: + + o its originator identifying the report service associated with the + issuing relay + + o its recipient identifying the endpoint address of the originator + associated with the "dataTiming" option + + o its content consisting of a "statusResponse" element having: + + * its "transID" attribute equal to the "transID" attribute of the + "dataTiming" option + + * and identifying the original recipient with a permanent failure + indicator + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Klyne, et. al. Standards Track [Page 7] + +RFC 3342 The Application Exchange (APEX) Party Pack July 2002 + + + For example: + + +-------+ +-------+ + | | -- data -------> | | + | appl. | | relay | + | | <--------- ok -- | | + +-------+ +-------+ + + C: + + + + + S: + + ... some time later ... + + +-------+ +-------+ + | | <------- data -- | | + | appl. | | relay | + | | -- ok ---------> | | + +-------+ +-------+ + + C: + + + + + + + + + + + S: + +2.2 Reporting on Delayed Delivery + + The "reportAfter" attribute of the "dataTiming" option provides for + the originator to be notified if delivery is delayed beyond a + specified time. Delivery of the data is not affected. Note that if + the value of the "noLaterThan" attribute is non-zero, then it + provides the operational upper-bounds for the "reportAfter" + attribute. + + + + +Klyne, et. al. Standards Track [Page 8] + +RFC 3342 The Application Exchange (APEX) Party Pack July 2002 + + + If this option is present in the "data" operation (c.f., Section + 4.4.4 of [1]) and the value of the "reportAfter" attribute is non- + zero, then: + + o For Step 5.2 of Section 4.4.4.1 of [1]: + + Immediately prior to sending the data to the next relay, the value + of the "reportAfter" attribute is adjusted to reflect the + processing time of the data at the local relay (e.g., the time + required to determine the next relay, to successfully issue a + "bind" operation, and then be ready to immediately issue a "data" + operation). + + If the value of the "reportAfter" attribute becomes less than or + equal to zero, then its value is set to zero and the APEX report + service is invoked to send a transient timing report; regardless, + the data element is sent to the next relay. + + o For Step 5.3 of Section 4.4.4.1 of [1]: + + If the relay does not receive an "ok" element from the recipient + endpoint within the number of milli-seconds indicated by the value + of the "reportAfter" attribute, then its value is set to zero and + the APEX report service is invoked to send a transient timing + report. + +2.2.1 Transient Timing Report + + If the APEX report service (c.f., Section 6.2 of [1]) is invoked to + send a transient timing report, it issues a data operation with: + + o its originator identifying the report service associated with the + issuing relay + + o its recipient identifying the endpoint address of the originator + associated with the "dataTiming" option + + o its content consisting of a "statusResponse" element having: + + * its "transID" attribute equal to the "transID" attribute of the + "dataTiming" option + + * and identifying the original recipient with a transient success + indicator + + + + + + + +Klyne, et. al. Standards Track [Page 9] + +RFC 3342 The Application Exchange (APEX) Party Pack July 2002 + + + For example: + + +-------+ +-------+ + | | -- data -------> | | + | appl. | | relay | + | #1 | <--------- ok -- | | + +-------+ +-------+ + + C: + + + + + S: + + ... some time later ... + + +-------+ +-------+ + | | <------- data -- | | + | relay | | relay | + | #n-1 | -- ok ---------> | #n | + +-------+ +-------+ + + C: + + + + + + + + + + + S: + +3. The hold4Endpoint Option + + Section 5.3 contains the APEX option registration for the + "hold4Endpoint" option. + + The default behavior of the APEX relaying mesh, in the absence of + processing options, is to silently drop data for a recipient if its + endpoint isn't attached. The "hold4Endpoint" option provides for + data to be queued if the recipient endpoint is not attached. + + + +Klyne, et. al. Standards Track [Page 10] + +RFC 3342 The Application Exchange (APEX) Party Pack July 2002 + + + If this option is present in the "data" operation (c.f., Section + 4.4.4 of [1]), and the value of the "hold4Endpoint" attribute is true + then: + + o For Step 5.3 of Section 4.4.4.1 of [1]: + + If the recipient's endpoint is not currently attached, the relay + will queue the data waiting for an application to attach as that + endpoint. + + Note that in the absence of an upper-bounds on delivery, such as + limits provided by the dataTiming option (Section 2), the data will + be queued indefinitely for the endpoint. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Klyne, et. al. Standards Track [Page 11] + +RFC 3342 The Application Exchange (APEX) Party Pack July 2002 + + + For example: + + +-------+ +-------+ + | | -- data -------> | | + | appl. | | relay | + | #1 | <--------- ok -- | | + +-------+ +-------+ + + C: + + + + + S: + + ... some time later the recipient's endpoint attaches ... + + +-------+ +-------+ + | | <----- attach -- | | + | | | | + | | -- ok ---------> | | + | relay | | appl. | + | | -- data -------> | #2 | + | | | | + | | <--------- ok -- | | + +-------+ +-------+ + + C: + + S: + + C: + + + + + S: + + + + + +Klyne, et. al. Standards Track [Page 12] + +RFC 3342 The Application Exchange (APEX) Party Pack July 2002 + + +4. The dataHopping Option + + To detect misconfigurations that cause forwarding loops in the APEX + relaying mesh, the APEX pubsub service re-introduces a mechanism + similar to the IP TTL [2] mechanism, in the form of an APEX option. + Section 5.4 contains the APEX option registration for the + "dataHopping" option. + + If this option is present in the "data" operation (c.f., Section + 4.4.4 of [1]) and the value of the "noMoreThan" attribute is non- + zero, then: + + o For Step 5.2 of Section 4.4.4.1 of [1]: + + Immediately prior to sending the data to the next relay, the value + of the "noMoreThan" attribute is reduced by 1. + + If the value of the "noMoreThan" attribute becomes less than or + equal to zero, an error in processing has occurred, the data + element is not sent to the next relay, and if the "reportErrors" + attribute is true, the APEX report service is invoked to send an + error report. + + Further, note that because this option is processed on a per-hop + basis, the originator must set the "targetHop" attribute to the value + "all" and the "mustUnderstand" attribute to the value "true". + + If the APEX report service (c.f., Section 6.2 of [1]) is invoked to + send an error report, it issues a data operation with: + + o its originator identifying the report service associated with the + issuing relay + + o its recipient identifying the endpoint address of the originator + associated with the "dataHopping" option + + o its content consisting of a "statusResponse" element having: + + * its "transID" attribute equal to the "transID" attribute of the + "dataHopping" option + + * and identifying the original recipient with a permanent failure + indicator + + + + + + + + +Klyne, et. al. Standards Track [Page 13] + +RFC 3342 The Application Exchange (APEX) Party Pack July 2002 + + + For example: + + +-------+ +-------+ + | | -- data -------> | | + | appl. | | relay | + | | <--------- ok -- | #1 | + +-------+ +-------+ + + C: + + + + + S: + +-------+ +-------+ + | | -- data -------> | | + | relay | | relay | + | #1 | <--------- ok -- | #2 | + +-------+ +-------+ + + C: + + + + + S: + + + + + + + + + + + + + + + + + + + +Klyne, et. al. Standards Track [Page 14] + +RFC 3342 The Application Exchange (APEX) Party Pack July 2002 + + + relay #2 determines that further relaying is necessary: + + +-------+ +-------+ + | | <------- data -- | | + | relay | | relay | + | #1 | -- ok ---------> | #2 | + +-------+ +-------+ + + C: + + + + + + + + + + + S: + +5. Initial Registrations + + The APEX option registration template is defined in Section 7.1 of + [1]. + +5.1 Registration: The attachOverride Option + + Option Identification: attachOverride + + Present in: APEX's "attach" element + + Contains: nothing + + Processing Rules: c.f., Section 1 + + Contact Information: c.f., the "Authors' Addresses" section of this + memo + + + + + + + + + + + + + +Klyne, et. al. Standards Track [Page 15] + +RFC 3342 The Application Exchange (APEX) Party Pack July 2002 + + +5.2 Registration: The dataTiming Option + + Option Identification: dataTiming + + Present in: APEX's "data" element + + Contains: dataTiming (c.f., Section 6) + + Processing Rules: c.f., Section 2 + + Contact Information: c.f., the "Authors' Addresses" section of this + memo + +5.3 Registration: The hold4Endpoint Option + + Option Identification: hold4Endpoint + + Present in: APEX's "data" element + + Contains: nothing + + Processing Rules: c.f., Section 3 + + Contact Information: c.f., the "Authors' Addresses" section of this + memo + +5.4 Registration: The dataHopping Option + + Option Identification: dataHopping + + Present in: APEX's "data" element + + Contains: dataHopping (c.f., Section 6) + + Processing Rules: c.f., Section 4 + + Contact Information: c.f., the "Authors' Addresses" section of this + memo + + + + + + + + + + + + + +Klyne, et. al. Standards Track [Page 16] + +RFC 3342 The Application Exchange (APEX) Party Pack July 2002 + + +6. The APEX Party Pack DTD + + + + + + + + + + + + + + + + + + + + +Klyne, et. al. Standards Track [Page 17] + +RFC 3342 The Application Exchange (APEX) Party Pack July 2002 + + +7. Security Considerations + + Consult [1]'s Section 11 for a discussion of security issues. + + In addition: + + o The dataTiming option (Section 2) may be used to expose private + network topology. Accordingly, an administrator may wish to + choose to disable this option except at the ingress/egress points + for its administrative domain. + + o The hold4Endpoint option (Section 3) may be used to facilitate + denial-of-service attacks. Accordingly, an administrator may wish + to impose administrative limits on this attribute (e.g., always + require that the "dataTiming" option also be present with a + short-lived "noLaterThan" attribute). + +References + + [1] Rose, M., Klyne, G. and D. Crocker, "The Application Exchange + Core", RFC 3340, July 2002. + + [2] Postel, J., "Internet Protocol", STD 5, RFC 791, September + 1981. + + [3] Newman, D., "Deliver By SMTP Service Extension", RFC 2852, June + 2000. + + + + + + + + + + + + + + + + + + + + + + + + +Klyne, et. al. Standards Track [Page 18] + +RFC 3342 The Application Exchange (APEX) Party Pack July 2002 + + +Appendix A. Acknowledgements + + The authors gratefully acknowledge the contributions of Chris Newman + and Bob Wyman. Further, the dataTiming option is similar in function + to "Deliver By" SMTP service extension defined by Dan Newman in [3]. + +Appendix B. IANA Considerations + + The IANA completed the registrations specified in Section 5. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Klyne, et. al. Standards Track [Page 19] + +RFC 3342 The Application Exchange (APEX) Party Pack July 2002 + + +Authors' Addresses + + Graham Klyne + Clearswift Corporation + 1310 Waterside + Arlington Business Park + Theale, Reading RG7 4SA + UK + + Phone: +44 11 8903 8903 + EMail: Graham.Klyne@MIMEsweeper.com + + + Marshall T. Rose + Dover Beach Consulting, Inc. + POB 255268 + Sacramento, CA 95865-5268 + US + + Phone: +1 916 483 8878 + EMail: mrose@dbc.mtview.ca.us + + + Michael F. Schwartz + Code On The Road, LLC + + EMail: schwartz@CodeOnTheRoad.com + URI: http://www.CodeOnTheRoad.com + + + Eric Dixon + + EMail: edixon@myrealbox.com + + + Huston Franklin + + EMail: huston@franklin.ro + + + Jay Kint + + EMail: d20@icosahedron.org + + + + + + + + +Klyne, et. al. Standards Track [Page 20] + +RFC 3342 The Application Exchange (APEX) Party Pack July 2002 + + + Darren New + 5390 Caminito Exquisito + San Diego, CA 92130 + US + + Phone: +1 858 350 9733 + EMail: dnew@san.rr.com + + + Scott Pead + + EMail: spead@fiber.net + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Klyne, et. al. Standards Track [Page 21] + +RFC 3342 The Application Exchange (APEX) Party Pack July 2002 + + +Full Copyright Statement + + Copyright (C) The Internet Society (2002). All Rights Reserved. + + This document and translations of it may be copied and furnished to + others, and derivative works that comment on or otherwise explain it + or assist in its implementation may be prepared, copied, published + and distributed, in whole or in part, without restriction of any + kind, provided that the above copyright notice and this paragraph are + included on all such copies and derivative works. However, this + document itself may not be modified in any way, such as by removing + the copyright notice or references to the Internet Society or other + Internet organizations, except as needed for the purpose of + developing Internet standards in which case the procedures for + copyrights defined in the Internet Standards process must be + followed, or as required to translate it into languages other than + English. + + The limited permissions granted above are perpetual and will not be + revoked by the Internet Society or its successors or assigns. + + This document and the information contained herein is provided on an + "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING + TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING + BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION + HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF + MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. + +Acknowledgement + + Funding for the RFC Editor function is currently provided by the + Internet Society. + + + + + + + + + + + + + + + + + + + +Klyne, et. al. Standards Track [Page 22] + -- cgit v1.2.3