📄 rfc3342.txt
字号:
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.,
+-------+ +-------+
| | -- 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 />
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 [Page 3]
RFC 3342 The Application Exchange (APEX) Party Pack July 2002
There are two types of delays 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);
o a "statusResponse" message (c.f., Section 5.1 of [1]) to be
generated if data is not delivered within a known amount of time
as specified using the "reportAfter" attribute (Section 2.2); and,
o an upper limit on the amount of time for the "statusResponse"
message to be delivered using the "returnTrip" attribute (Section
2.1.1), after which the sender may presume the message to be lost.
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".
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).
Klyne, et. al. Standards Track [Page 4]
RFC 3342 The Application Exchange (APEX) Party Pack July 2002
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 invoked 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.
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.
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
Klyne, et. al. Standards Track [Page 5]
RFC 3342 The Application Exchange (APEX) Party Pack July 2002
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 />
Klyne, et. al. Standards Track [Page 6]
RFC 3342 The Application Exchange (APEX) Party Pack July 2002
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
Klyne, et. al. Standards Track [Page 7]
RFC 3342 The Application Exchange (APEX) Party Pack July 2002
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' />
⌨️ 快捷键说明
复制代码
Ctrl + C
搜索代码
Ctrl + F
全屏模式
F11
切换主题
Ctrl + Shift + D
显示快捷键
?
增大字号
Ctrl + =
减小字号
Ctrl + -