The Application Exchange (APEX) Option Party Pack, Part Deux!
RFC 3342

Document Type RFC - Historic (July 2002; No errata)
Last updated 2015-10-14
Stream IETF
Formats plain text pdf html 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