RFC 
 3342 
 TOC 
Network Working GroupG. Klyne
Request for Comments: 3342Clearswift Corporation
Category: Standards TrackM. 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 © 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".


 RFC 
 3342 
 TOC 

Table of Contents

1.  The attachOverride Option
2.  The dataTiming Option
    2.1.  Upper-Bounds on Delivery
        2.1.1.  Final Hop Report
        2.1.2.  Timing Error Report
    2.2.  Reporting on Delayed Delivery
        2.2.1.  Transient Timing Report
3.  The hold4Endpoint Option
4.  The dataHopping Option
5.  Initial Registrations
    5.1.  Registration: The attachOverride Option
    5.2.  Registration: The dataTiming Option
    5.3.  Registration: The hold4Endpoint Option
    5.4.  Registration: The dataHopping Option
6.  The APEX Party Pack DTD
7.  Security Considerations
8.  References
Appendix A.  Acknowledgements
Appendix B.  IANA Considerations
§  Authors' Addresses
§  Intellectual Property and Copyright Statements




 TOC 

1.  The attachOverride Option

Section 5.1 (Registration: The attachOverride Option) 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 [RFC3340] (Rose, M., Klyne, G., and D. Crocker, “The Application Exchange Core,” July 2002.)) and if any application is already attached as the specified endpoint, that endpoint has its attachment terminated (c.f., Section 4.4.3 of [RFC3340] (Rose, M., Klyne, G., and D. Crocker, “The Application Exchange Core,” July 2002.)) 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 [RFC3340] (Rose, M., Klyne, G., and D. Crocker, “The Application Exchange Core,” 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: <attach endpoint='fred@example.com' transID='1' />
  S: <ok />










... some time later appl #2 starts on a different computer ...

                               +-------+                  +-------+
                               |       | <----- attach -- |       |
    +-------+                  |       |                  | appl. |
    |       | <-- terminate -- | relay | -- ok ---------> |   #2  |
    | appl. |                  |       |                  +-------+
    |   #1  | -- ok ---------> |       |
    +-------+                  +-------+

            C: <attach endpoint='fred@example.com' transID='2'>
                   <option internal='attachOverride' transID='3' />
               </attach>
            S: <ok />

  C: <terminate transID='1' code='556'>overriden</terminate>
  S: <ok />


 TOC 

2.  The dataTiming Option

Section 5.2 (Registration: The dataTiming Option) contains the APEX option registration for the "dataTiming" option. This option contains a "dataTiming" element (c.f., Section 6 (The APEX Party Pack DTD)).

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.

There are two types of delays addressed by the "dataTiming" option:

Accordingly, the "dataTiming" option allows for:

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".



 TOC 

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 [RFC3340] (Rose, M., Klyne, G., and D. Crocker, “The Application Exchange Core,” July 2002.)) and the value of the "noLaterThan" attribute is non-zero, then:

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.



 TOC 

2.1.1.  Final Hop Report

If the APEX report service (c.f., Section 6.2 of [RFC3340] (Rose, M., Klyne, G., and D. Crocker, “The Application Exchange Core,” July 2002.)) is invoked to send a final hop report, it issues a data operation with:

For example:

                               +-------+                  +-------+
                               |       | -- data -------> |       |
                               | relay |                  | appl. |
                               |       | <--------- ok -- |   #2  |
                               +-------+                  +-------+

  C: <data content='cid:1@example.com'>
         <originator identity='fred@example.com' />
         <recipient identity='barney@example.com' />
         <option internal='dataTiming' targetHop='all'
                 mustUnderstand='true' transID='86'>
             <dataTiming noLaterThan='10000' returnTrip='20000' />
         </option>
     </data>
  S: <ok />

    +-------+                  +-------+
    |       | <------- data -- |       |
    | appl. |                  | relay |
    |   #1  | -- ok ---------> |       |
    +-------+                  +-------+

  C: <data content='#Content'>
         <originator identity='apex=report@example.com' />
         <recipient identity='fred@example.com' />
         <option internal='dataTiming' targetHop='all'
                 mustUnderstand='true' transID='99'>
             <dataTiming noLaterThan='20000' />
         </option>
         <data-content Name='Content'>
             <statusResponse transID='86'>
                 <destination identity='barney@example.com'>
                     <reply code='250' />
                 </destination>
             </statusResponse>
         </data-content>
     </data>
  S: <ok />


 TOC 

2.1.2.  Timing Error Report

If the APEX report service (c.f., Section 6.2 of [RFC3340] (Rose, M., Klyne, G., and D. Crocker, “The Application Exchange Core,” July 2002.)) is invoked to send a timing error report, it issues a data operation with:

For example:

    +-------+                  +-------+
    |       | -- data -------> |       |
    | appl. |                  | relay |
    |       | <--------- ok -- |       |
    +-------+                  +-------+

  C: <data content='cid:1@example.com'>
         <originator identity='fred@example.com' />
         <recipient identity='barney@example.com' />
         <option internal='dataTiming' targetHop='all'
                 mustUnderstand='true' transID='86'>
             <dataTiming noLaterThan='6000' reportErrors='true' />
         </option>
     </data>
  S: <ok />











... some time later ...
    +-------+                  +-------+
    |       | <------- data -- |       |
    | appl. |                  | relay |
    |       | -- ok ---------> |       |
    +-------+                  +-------+

  C: <data content='#Content'>
         <originator identity='apex=report@example.com' />
         <recipient identity='fred@example.com' />
         <data-content Name='Content'>
             <statusResponse transID='86'>
                 <destination identity='barney@example.com'>
                     <reply code='550' />
                 </destination>
             </statusResponse>
         </data-content>
     </data>
  S: <ok />


 TOC 

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.

If this option is present in the "data" operation (c.f., Section 4.4.4 of [RFC3340] (Rose, M., Klyne, G., and D. Crocker, “The Application Exchange Core,” July 2002.)) and the value of the "reportAfter" attribute is non-zero, then:



 TOC 

2.2.1.  Transient Timing Report

If the APEX report service (c.f., Section 6.2 of [RFC3340] (Rose, M., Klyne, G., and D. Crocker, “The Application Exchange Core,” July 2002.)) is invoked to send a transient timing report, it issues a data operation with:

For example:

    +-------+                  +-------+
    |       | -- data -------> |       |
    | appl. |                  | relay |
    |   #1  | <--------- ok -- |       |
    +-------+                  +-------+

  C: <data content='cid:1@example.com'>
         <originator identity='fred@example.com' />
         <recipient identity='barney@example.com' />
         <option internal='dataTiming' targetHop='all'
                 mustUnderstand='true' transID='86'>
             <dataTiming reportAfter='60000' />
         </option>
     </data>
  S: <ok />











... some time later ...
                               +-------+                  +-------+
                               |       | <------- data -- |       |
                               | relay |                  | relay |
                               |  #n-1 | -- ok ---------> |   #n  |
                               +-------+                  +-------+

  C: <data content='#Content'>
         <originator identity='apex=report@example.com' />
         <recipient identity='fred@example.com' />
         <data-content Name='Content'>
             <statusResponse transID='86'>
                 <destination identity='barney@example.com'>
                     <reply code='350' />
                 </destination>
             </statusResponse>
         </data-content>
     </data>
  S: <ok />


 TOC 

3.  The hold4Endpoint Option

Section 5.3 (Registration: The hold4Endpoint Option) 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.

If this option is present in the "data" operation (c.f., Section 4.4.4 of [RFC3340] (Rose, M., Klyne, G., and D. Crocker, “The Application Exchange Core,” July 2002.)), and the value of the "hold4Endpoint" attribute is true then:

Note that in the absence of an upper-bounds on delivery, such as limits provided by the dataTiming option (The dataTiming Option), the data will be queued indefinitely for the endpoint.

For example:

    +-------+                  +-------+
    |       | -- data -------> |       |
    | appl. |                  | relay |
    |   #1  | <--------- ok -- |       |
    +-------+                  +-------+

  C: <data content='cid:1@example.com'>
         <originator identity='fred@example.com' />
         <recipient identity='barney@example.com' />
         <option internal='hold4Endpoint' />
         <option internal='dataTiming' targetHop='all'
                 mustUnderstand='true' transID='86'>
             <dataTiming noLaterThan='60000' />
         </option>
     </data>
  S: <ok />





... some time later the recipient's endpoint attaches ...
                               +-------+                  +-------+
                               |       | <----- attach -- |       |
                               |       |                  |       |
                               |       | -- ok ---------> |       |
                               | relay |                  | appl. |
                               |       | -- data -------> |   #2  |
                               |       |                  |       |
                               |       | <--------- ok -- |       |
                               +-------+                  +-------+

  C: <attach endpoint='barney@example.com' transID='2'>
         <option internal='attachOverride' transID='3' />
     </attach>
  S: <ok />

  C: <data content='cid:1@example.com'>
         <originator identity='fred@example.com' />
         <recipient identity='barney@example.com' />
         <option internal='hold4Endpoint' />
         <option internal='dataTiming' targetHop='all'
                 mustUnderstand='true' transID='86'>
             <dataTiming noLaterThan='18000' />
         </option>
     </data>
  S: <ok />


 TOC 

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 (Postel, J., “Internet Protocol,” September 1981.) [RFC0791] mechanism, in the form of an APEX option. Section 5.4 (Registration: The dataHopping Option) 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 [RFC3340] (Rose, M., Klyne, G., and D. Crocker, “The Application Exchange Core,” July 2002.)) and the value of the "noMoreThan" attribute is non-zero, then:

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 [RFC3340] (Rose, M., Klyne, G., and D. Crocker, “The Application Exchange Core,” July 2002.)) is invoked to send an error report, it issues a data operation with:

For example:

    +-------+                  +-------+
    |       | -- data -------> |       |
    | appl. |                  | relay |
    |       | <--------- ok -- |   #1  |
    +-------+                  +-------+

  C: <data content='cid:1@example.com'>
         <originator identity='appl=pubsub/topic=fred@example.com' />
         <recipient identity='barney@example.com' />
         <option internal='dataHopping' targetHop='all'
                 mustUnderstand='true' transID='86'>
             <dataHopping noMoreThan='2' reportErrors='true' />
         </option>
     </data>
  S: <ok />
                               +-------+                  +-------+
                               |       | -- data -------> |       |
                               | relay |                  | relay |
                               |   #1  | <--------- ok -- |   #2  |
                               +-------+                  +-------+

  C: <data content='cid:1@example.com'>
         <originator identity='appl=pubsub/topic=fred@example.com' />
         <recipient identity='barney@example.com' />
         <option internal='dataHopping' targetHop='all'
                 mustUnderstand='true' transID='86'>
             <dataHopping noMoreThan='1' reportErrors='true' />
         </option>
     </data>
  S: <ok />

relay #2 determines that further relaying is necessary:

    +-------+                  +-------+
    |       | <------- data -- |       |
    | relay |                  | relay |
    |   #1  | -- ok ---------> |   #2  |
    +-------+                  +-------+

  C: <data content='#Content'>
         <originator identity='apex=report@example.com' />
         <recipient identity='appl=pubsub/topic=fred@example.com' />
         <data-content Name='Content'>
             <statusResponse transID='86'>
                 <destination identity='barney@example.com'>
                     <reply code='550' />
                 </destination>
             </statusResponse>
         </data-content>
     </data>
  S: <ok />


 TOC 

5.  Initial Registrations

The APEX option registration template is defined in Section 7.1 of [RFC3340] (Rose, M., Klyne, G., and D. Crocker, “The Application Exchange Core,” July 2002.).



 TOC 

5.1.  Registration: The attachOverride Option

Option Identification:
attachOverride
Present in:
APEX's "attach" element
Contains:
nothing
Processing Rules:
c.f., Section 1 (The attachOverride Option)
Contact Information:
c.f., the "Authors' Addresses" section of this memo


 TOC 

5.2.  Registration: The dataTiming Option

Option Identification:
dataTiming
Present in:
APEX's "data" element
Contains:
dataTiming (c.f., Section 6 (The APEX Party Pack DTD))
Processing Rules:
c.f., Section 2 (The dataTiming Option)
Contact Information:
c.f., the "Authors' Addresses" section of this memo


 TOC 

5.3.  Registration: The hold4Endpoint Option

Option Identification:
hold4Endpoint
Present in:
APEX's "data" element
Contains:
nothing
Processing Rules:
c.f., Section 3 (The hold4Endpoint Option)
Contact Information:
c.f., the "Authors' Addresses" section of this memo


 TOC 

5.4.  Registration: The dataHopping Option

Option Identification:
dataHopping
Present in:
APEX's "data" element
Contains:
dataHopping (c.f., Section 6 (The APEX Party Pack DTD))
Processing Rules:
c.f., Section 4 (The dataHopping Option)
Contact Information:
c.f., the "Authors' Addresses" section of this memo


 TOC 

6.  The APEX Party Pack DTD

<!--
  DTD for the APEX option party pack, as of 2001-05-14


  Refer to this DTD as:

    <!ENTITY % APEXPARTY PUBLIC "-//IETF//DTD APEX PARTY//EN" "">
    %APEXPARTY;
  -->


<!ENTITY % APEXCORE PUBLIC "-//IETF//DTD APEX CORE//EN"
%APEXCORE;


<!--
  DTD data types:

       entity        syntax/reference     example
       ======        ================     =======
    hopcount
        HOPS         0..255               17

    milli-seconds
        MILLISECS    0..2147483647        60000
  -->

<!ENTITY  % HOPS     "CDATA">
<!ENTITY  % MILLISECS
                      "CDATA">


<!ELEMENT dataHopping EMPTY>
<!ATTLIST dataHopping
          noMoreThan  %HOPS;            "0"
          reportErrors
                      (true|false)      "false">

<!ELEMENT dataTiming  EMPTY>
<!ATTLIST dataTiming
          noLaterThan %MILLISECS;       "0"
          returnTrip  %MILLISECS;       "0"
          reportAfter %MILLISECS;       "0"
          reportErrors
                      (true|false)      "false">


 TOC 

7.  Security Considerations

Consult [RFC3340] (Rose, M., Klyne, G., and D. Crocker, “The Application Exchange Core,” July 2002.)'s Section 11 for a discussion of security issues.

In addition:



 TOC 

8. References

[RFC3340] Rose, M., Klyne, G., and D. Crocker, “The Application Exchange Core,” RFC 3340, July 2002.
[RFC0791] Postel, J., “Internet Protocol,” STD 5, RFC 791, September 1981 (TXT).
[RFC2852] Newman, D., “Deliver By SMTP Service Extension,” RFC 2852, June 2000 (TXT).


 TOC 

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 [RFC2852] (Newman, D., “Deliver By SMTP Service Extension,” June 2000.).



 TOC 

Appendix B.  IANA Considerations

The IANA completed the registrations specified in Section 5 (Initial Registrations).



 TOC 

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


 TOC 

Full Copyright Statement

Intellectual Property

Acknowledgment