RFC 3342 (rfc3342) - Page 3 of 22

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

Alternative Format: Original Text Document

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
< Previous
Next >