Network Working Group E. Dixon
Internet-Draft H. Franklin
Expires: January 7, 2002 J. Kint
Invisible Worlds, Inc.
G. Klyne
Baltimore Technologies
D. New
S. Pead
M. Rose
Invisible Worlds, Inc.
July 9, 2001
The APEX Option Party Pack, Part Deux!
draft-ietf-apex-party-02
Status of this Memo
This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on January 7, 2002.
Copyright Notice
Copyright (C) The Internet Society (2001). All Rights Reserved.
Abstract
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".
Dixon, et. al. Expires January 7, 2002 [Page 1]
Internet-Draft The APEX Option Party Pack, Part Deux! July 2001
Table of Contents
1. The attachOverride Option . . . . . . . . . . . . . . . . . 3
2. The dataTiming Option . . . . . . . . . . . . . . . . . . . 5
2.1 Upper-Bounds on Delivery . . . . . . . . . . . . . . . . . . 6
2.1.1 Final Hop Report . . . . . . . . . . . . . . . . . . . . . . 7
2.1.2 Timing Error Report . . . . . . . . . . . . . . . . . . . . 9
2.2 Reporting on Delayed Delivery . . . . . . . . . . . . . . . 11
2.2.1 Transient Timing Report . . . . . . . . . . . . . . . . . . 12
3. The hold4Endpoint Option . . . . . . . . . . . . . . . . . . 14
4. Initial Registrations . . . . . . . . . . . . . . . . . . . 16
4.1 Registration: The attachOverride Option . . . . . . . . . . 16
4.2 Registration: The dataTiming Option . . . . . . . . . . . . 16
4.3 Registration: The hold4Endpoint Option . . . . . . . . . . . 16
5. The APEX Party Pack DTD . . . . . . . . . . . . . . . . . . 17
6. Security Considerations . . . . . . . . . . . . . . . . . . 18
References . . . . . . . . . . . . . . . . . . . . . . . . . 19
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 19
A. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 21
B. IANA Considerations . . . . . . . . . . . . . . . . . . . . 22
C. Revision History . . . . . . . . . . . . . . . . . . . . . . 23
C.1 Changes from draft-ietf-apex-party-01 . . . . . . . . . . . 23
C.2 Changes from draft-ietf-apex-party-00 . . . . . . . . . . . 23
Full Copyright Statement . . . . . . . . . . . . . . . . . . 24
Dixon, et. al. Expires January 7, 2002 [Page 2]
Internet-Draft The APEX Option Party Pack, Part Deux! July 2001
1. The attachOverride Option
Section 4.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]).
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 ...
Dixon, et. al. Expires January 7, 2002 [Page 3]
Internet-Draft The APEX Option Party Pack, Part Deux! July 2001
+-------+ +-------+
| | <----- 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 />
Dixon, et. al. Expires January 7, 2002 [Page 4]
Internet-Draft The APEX Option Party Pack, Part Deux! July 2001
2. The dataTiming Option
Section 4.2 contains the APEX option registration for the
"dataTiming" option. This option contains a "dataTiming" element
(c.f., Section 5).
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 delay 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);
and,
o a "statusResponse" message (c.f., Section 5.1 of [1]) to be
generated if data is not delivered within a finite amount of time
as specified using the "reportAfter" attribute (Section 2.2).
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".
Dixon, et. al. Expires January 7, 2002 [Page 5]
Internet-Draft The APEX Option Party Pack, Part Deux! July 2001
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).
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 invokved 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.
Dixon, et. al. Expires January 7, 2002 [Page 6]
Internet-Draft The APEX Option Party Pack, Part Deux! July 2001
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
Dixon, et. al. Expires January 7, 2002 [Page 7]
Internet-Draft The APEX Option Party Pack, Part Deux! July 2001
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='2000' />
</option>
<data-content Name='Content'>
<statusResponse transID='86'>
<destination identity='barney@example.com'>
<reply code='250' />
</destination>
</statusResponse>
</data-content>
</data>
S: <ok />
Dixon, et. al. Expires January 7, 2002 [Page 8]
Internet-Draft The APEX Option Party Pack, Part Deux! July 2001
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
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 ...
Dixon, et. al. Expires January 7, 2002 [Page 9]
Internet-Draft The APEX Option Party Pack, Part Deux! July 2001
+-------+ +-------+
| | <------- 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 />
Dixon, et. al. Expires January 7, 2002 [Page 10]
Internet-Draft The APEX Option Party Pack, Part Deux! July 2001
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 [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.
Dixon, et. al. Expires January 7, 2002 [Page 11]
Internet-Draft The APEX Option Party Pack, Part Deux! July 2001
2.2.1 Transient Timing 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 transient success
indicator
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 ...
Dixon, et. al. Expires January 7, 2002 [Page 12]
Internet-Draft The APEX Option Party Pack, Part Deux! July 2001
+-------+ +-------+
| | <------- 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 />
Dixon, et. al. Expires January 7, 2002 [Page 13]
Internet-Draft The APEX Option Party Pack, Part Deux! July 2001
3. The hold4Endpoint Option
Section 4.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.
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.
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 ...
Dixon, et. al. Expires January 7, 2002 [Page 14]
Internet-Draft The APEX Option Party Pack, Part Deux! July 2001
+-------+ +-------+
| | <----- 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 />
Dixon, et. al. Expires January 7, 2002 [Page 15]
Internet-Draft The APEX Option Party Pack, Part Deux! July 2001
4. Initial Registrations
The APEX option registration template is defined in Section 7.1 of
[1].
4.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
4.2 Registration: The dataTiming Option
Option Identification: dataTiming
Present in: APEX's "data" element
Contains: dataTiming (c.f., Section 5)
Processing Rules: c.f., Section 2
Contact Information: c.f., the "Authors' Addresses" section of this
memo
4.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
Dixon, et. al. Expires January 7, 2002 [Page 16]
Internet-Draft The APEX Option Party Pack, Part Deux! July 2001
5. 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"
"http://xml.resource.org/profiles/APEX/apex-party.dtd">
%APEXPARTY;
-->
<!ENTITY % APEXCORE PUBLIC "-//IETF//DTD APEX CORE//EN"
"http://xml.resource.org/profiles/APEX/apex-core.dtd">
%APEXCORE;
<!--
DTD data types:
entity syntax/reference example
====== ================ =======
milli-seconds
MILLISECS 0..2147483647 60000
-->
<!ENTITY % MILLISECS
"CDATA">
<!ELEMENT dataTiming EMPTY>
<!ATTLIST dataTiming
noLaterThan %MILLISECS; "0"
returnTrip %MILLISECS; "0"
reportAfter %MILLISECS; "0"
reportErrors
(true|false) "false">
Dixon, et. al. Expires January 7, 2002 [Page 17]
Internet-Draft The APEX Option Party Pack, Part Deux! July 2001
6. 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).
Dixon, et. al. Expires January 7, 2002 [Page 18]
Internet-Draft The APEX Option Party Pack, Part Deux! July 2001
References
[1] Rose, M., Klyne, G. and D. Crocker, "The Application Exchange
Core", draft-ietf-apex-core-04 (work in progress), July 2001.
[2] Newman, D., "Deliver By SMTP Service Extension", RFC 2852, June
2000.
Authors' Addresses
Eric Dixon
Invisible Worlds, Inc.
131 Stony Circle
Suite 500
Santa Rosa, CA 95401
US
Phone: +1 707 578 2350
EMail: edixon@invisible.net
URI: http://invisible.net/
Huston Franklin
Invisible Worlds, Inc.
131 Stony Circle
Suite 500
Santa Rosa, CA 95401
US
Phone: +1 707 578 2350
EMail: huston@invisible.net
URI: http://invisible.net/
Jay Kint
Invisible Worlds, Inc.
131 Stony Circle
Suite 500
Santa Rosa, CA 95401
US
Phone: +1 707 578 2350
EMail: jkint@invisible.net
URI: http://invisible.net/
Dixon, et. al. Expires January 7, 2002 [Page 19]
Internet-Draft The APEX Option Party Pack, Part Deux! July 2001
Graham Klyne
Baltimore Technologies
1310 Waterside
Arlington Business Park
Theale, Reading RG7 4SA
UK
Phone: +44 118 903 8000
EMail: gk@acm.org
Darren New
Invisible Worlds, Inc.
131 Stony Circle
Suite 500
Santa Rosa, CA 95401
US
Phone: +1 707 578 2350
EMail: dnew@invisible.net
URI: http://invisible.net/
Scott Pead
Invisible Worlds, Inc.
131 Stony Circle
Suite 500
Santa Rosa, CA 95401
US
Phone: +1 707 578 2350
EMail: spead@invisible.net
URI: http://invisible.net/
Marshall T. Rose
Invisible Worlds, Inc.
131 Stony Circle
Suite 500
Santa Rosa, CA 95401
US
Phone: +1 707 578 2350
EMail: mrose@invisible.net
URI: http://invisible.net/
Dixon, et. al. Expires January 7, 2002 [Page 20]
Internet-Draft The APEX Option Party Pack, Part Deux! July 2001
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 [2].
Dixon, et. al. Expires January 7, 2002 [Page 21]
Internet-Draft The APEX Option Party Pack, Part Deux! July 2001
Appendix B. IANA Considerations
The IANA makes the registrations specified in Section 4.
Dixon, et. al. Expires January 7, 2002 [Page 22]
Internet-Draft The APEX Option Party Pack, Part Deux! July 2001
Appendix C. Revision History
C.1 Changes from draft-ietf-apex-party-01
o A page-break was fixed.
C.2 Changes from draft-ietf-apex-party-00
o When terminating an association due to processing the
"attachOverride" option, the "code" attribute of the terminate
operation must be supplied.
o A small number of typos were corrected.
Dixon, et. al. Expires January 7, 2002 [Page 23]
Internet-Draft The APEX Option Party Pack, Part Deux! July 2001
Full Copyright Statement
Copyright (C) The Internet Society (2001). 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.
Dixon, et. al. Expires January 7, 2002 [Page 24]
