The Application Exchange (APEX) Option Party Pack, Part Deux!
RFC 3342
Document | Type |
RFC - Historic
(July 2002; No errata)
Was draft-ietf-apex-party (apex WG)
|
|
---|---|---|---|
Authors | Eric Dixon , Marshall Rose , Jay Kint , Darren New , Michael Schwartz , Graham Klyne , Huston Franklin , Eric Dixon | ||
Last updated | 2015-10-14 | ||
Stream | IETF | ||
Formats | plain text html pdf htmlized bibtex | ||
Stream | WG state | (None) | |
Document shepherd | No shepherd assigned | ||
IESG | IESG state | RFC 3342 (Historic) | |
Consensus Boilerplate | Unknown | ||
Telechat date | |||
Responsible AD | Ned Freed | ||
IESG note | Responsible: Finished | ||
Send notices to | (None) |
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., +-------+ +-------+Show full document text