idnits 2.17.1
draft-etal-apex-party-01.txt:
Checking boilerplate required by RFC 5378 and the IETF Trust (see
https://trustee.ietf.org/license-info):
----------------------------------------------------------------------------
** Looks like you're using RFC 2026 boilerplate. This must be updated to
follow RFC 3978/3979, as updated by RFC 4748.
Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt:
----------------------------------------------------------------------------
== No 'Intended status' indicated for this document; assuming Proposed
Standard
Checking nits according to https://www.ietf.org/id-info/checklist :
----------------------------------------------------------------------------
** The document seems to lack an Introduction section.
** The document seems to lack separate sections for Informative/Normative
References. All references will be assumed normative when checking for
downward references.
Miscellaneous warnings:
----------------------------------------------------------------------------
== The copyright year in the RFC 3978 Section 5.4 Copyright Line does not
match the current year
-- The document seems to lack a disclaimer for pre-RFC5378 work, but may
have content which was first submitted before 10 November 2008. If you
have contacted all the original authors and they are all willing to grant
the BCP78 rights to the IETF Trust, then this is fine, and you can ignore
this comment. If not, you may need to add the pre-RFC5378 disclaimer.
(See the Legal Provisions document at
https://trustee.ietf.org/license-info for more information.)
-- The document date (May 16, 2001) is 8373 days in the past. Is this
intentional?
Checking references for intended status: Proposed Standard
----------------------------------------------------------------------------
(See RFCs 3967 and 4897 for information about using normative references
to lower-maturity documents in RFCs)
== Outdated reference: A later version (-06) exists of
draft-ietf-apex-core-01
** Downref: Normative reference to an Historic draft: draft-ietf-apex-core
(ref. '1')
Summary: 4 errors (**), 0 flaws (~~), 3 warnings (==), 2 comments (--).
Run idnits with the --verbose option for more detailed information about
the items above.
--------------------------------------------------------------------------------
2 Network Working Group E. Dixon
3 Internet-Draft H. Franklin
4 Expires: November 14, 2001 J. Kint
5 Invisible Worlds, Inc.
6 G. Klyne
7 Baltimore Technologies
8 D. New
9 S. Pead
10 M. Rose
11 Invisible Worlds, Inc.
12 May 16, 2001
14 The APEX Option Party Pack, Part Deux!
15 draft-etal-apex-party-01
17 Status of this Memo
19 This document is an Internet-Draft and is in full conformance with
20 all provisions of Section 10 of RFC2026.
22 Internet-Drafts are working documents of the Internet Engineering
23 Task Force (IETF), its areas, and its working groups. Note that
24 other groups may also distribute working documents as Internet-
25 Drafts.
27 Internet-Drafts are draft documents valid for a maximum of six months
28 and may be updated, replaced, or obsoleted by other documents at any
29 time. It is inappropriate to use Internet-Drafts as reference
30 material or to cite them other than as "work in progress."
32 The list of current Internet-Drafts can be accessed at
33 http://www.ietf.org/ietf/1id-abstracts.txt.
35 The list of Internet-Draft Shadow Directories can be accessed at
36 http://www.ietf.org/shadow.html.
38 This Internet-Draft will expire on November 14, 2001.
40 Copyright Notice
42 Copyright (C) The Internet Society (2001). All Rights Reserved.
44 Abstract
46 APEX, at its core, provides a best-effort application-layer datagram
47 service. Options are used to alter the semantics of the core
48 service. This memo defines various options to change the default
49 behavior of APEX's "relaying mesh".
51 Table of Contents
53 1. The attachOverride Option . . . . . . . . . . . . . . . . . 3
54 2. The dataTiming Option . . . . . . . . . . . . . . . . . . . 5
55 2.1 Upper-Bounds on Delivery . . . . . . . . . . . . . . . . . . 6
56 2.1.1 Final Hop Report . . . . . . . . . . . . . . . . . . . . . . 7
57 2.1.2 Timing Error Report . . . . . . . . . . . . . . . . . . . . 9
58 2.2 Reporting on Delayed Delivery . . . . . . . . . . . . . . . 11
59 2.2.1 Transient Timing Report . . . . . . . . . . . . . . . . . . 12
60 3. The hold4Endpoint Option . . . . . . . . . . . . . . . . . . 14
61 4. Initial Registrations . . . . . . . . . . . . . . . . . . . 16
62 4.1 Registration: The attachOverride Option . . . . . . . . . . 16
63 4.2 Registration: The dataTiming Option . . . . . . . . . . . . 16
64 4.3 Registration: The hold4Endpoint Option . . . . . . . . . . . 16
65 5. The APEX Party Pack DTD . . . . . . . . . . . . . . . . . . 17
66 6. Security Considerations . . . . . . . . . . . . . . . . . . 18
67 References . . . . . . . . . . . . . . . . . . . . . . . . . 19
68 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 19
69 A. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 21
70 B. IANA Considerations . . . . . . . . . . . . . . . . . . . . 22
71 C. Changes from draft-etal-apex-party-00 . . . . . . . . . . . 23
72 Full Copyright Statement . . . . . . . . . . . . . . . . . . 24
74 1. The attachOverride Option
76 Section 4.1 contains the APEX option registration for the
77 "attachOverride" option.
79 The default behavior of the APEX relaying mesh, in the absence of
80 processing options, is to allow at most one application to attach as
81 a particular endpoint, on a "first come, first served" basis. The
82 "attachOverride" option provides gives preference to the current
83 application trying to attach.
85 If this option is present in the "attach" operation (c.f., Section
86 4.4.1 of [1]) and if any application is already attached as the
87 specified endpoint, that endpoint has its attachment terminated
88 (c.f., Section 4.4.3 of [1]) concurrently with processing of that
89 "attach" operation.
91 Note that any data being expected by the previously-attached
92 application may instead be delivered to the last application to
93 successfully attach. Accordingly, applications should take care to
94 properly deal with incoming data having unrecognized transaction-
95 identifiers (c.f., Section 6.1.1 of [1]).
97 This option provides for a new attachment to automatically terminate
98 any existing attachment for the same endpoint. For example, This
99 might be helpful when a new attachment is required from a different
100 device while a previously-used device is still attached e.g.,
102 +-------+ +-------+
103 | | -- attach -----> | |
104 | appl. | | relay |
105 | #1 | <--------- ok -- | |
106 +-------+ +-------+
108 C:
109 S:
111 ... some time later appl #2 starts on a different computer ...
113 +-------+ +-------+
114 | | <----- attach -- | |
115 +-------+ | | | appl. |
116 | | <-- terminate -- | relay | -- ok ---------> | #2 |
117 | appl. | | | +-------+
118 | #1 | -- ok ---------> | |
119 +-------+ +-------+
121 C:
122
123
124 S:
126 C:
127 S:
129 2. The dataTiming Option
131 Section 4.2 contains the APEX option registration for the
132 "dataTiming" option. This option contains a "dataTiming" element
133 (c.f., Section 5).
135 The default behavior of the APEX relaying mesh is "immediate, best
136 effort" and expects that all relays and endpoints are able to process
137 and transfer data without delay -- in the absence of processing
138 options, if a relay is unavailable then data is silently dropped.
139 The "dataTiming" option provides for controlled queuing delays in
140 processing, whilst providing reasonable deterministic behavior for
141 the originator.
143 There are two types of delay addressed by the "dataTiming" option:
145 o delays in transit through the relaying mesh, possibly due to
146 intermittent or slow connections, or congested relays; and,
148 o delays because the intended endpoint is not available to receive
149 the data, when used in conjunction with the hold4Endpoint option
150 (Section 3).
152 Accordingly, the "dataTiming" option allows for:
154 o data to be discarded if not delivered within a finite amount of
155 time as specified using the "noLaterThan" attribute (Section 2.1);
156 and,
158 o a "statusResponse" message (c.f., Section 5.1 of [1]) to be
159 generated if data is not delivered within a finite amount of time
160 as specified using the "reportAfter" attribute (Section 2.2).
162 This option does not provide any functionality with respect to the
163 priority of the data. Nor does this option have any effect on other
164 parts of the relaying process.
166 Further, note that because this option is processed on a per-hop
167 basis, the originator must set the "targetHop" attribute to the value
168 "all" and the "mustUnderstand" attribute to the value "true".
170 2.1 Upper-Bounds on Delivery
172 The "noLaterThan" attribute of the "dataTiming" option provides for
173 control over delays that may occur in transit through the relaying
174 mesh or to the recipient endpoint.
176 If this option is present in the "data" operation (c.f., Section
177 4.4.4 of [1]) and the value of the "noLaterThan" attribute is non-
178 zero, then:
180 o For Step 5.2 of Section 4.4.4.1 of [1]:
182 Immediately prior to sending the data to the next relay, the value
183 of the "noLaterThan" attribute is adjusted to reflect the
184 processing time of the data at the local relay (e.g., the time
185 required to determine the next relay, to successfully issue a
186 "bind" operation, and then be ready to immediately issue a "data"
187 operation).
189 If the value of the "noLaterThan" attribute becomes less than or
190 equal to zero, an error in processing has occurred, the data
191 element is not sent to the next relay, and if the "reportErrors"
192 attribute is true, the APEX report service is invokved to send a
193 timing error report.
195 o For Step 5.3 of Section 4.4.4.1 of [1]:
197 If the relay does not receive an "ok" element from the recipient
198 endpoint within the number of milli-seconds indicated by the value
199 of the "noLaterThan" attribute, an error in processing has
200 occurred, and if the "reportErrors" attribute is true, the APEX
201 report service is invoked to send a timing error report.
203 Otherwise, if the data is successfully transmitted to the
204 recipient, and the "returnTrip" attribute is non-zero, the APEX
205 report service is invoked to send a final hop report.
207 2.1.1 Final Hop Report
209 If the APEX report service (c.f., Section 6.2 of [1]) is invoked to
210 send a final hop report, it issues a data operation with:
212 o its originator identifying the report service associated with the
213 issuing relay
215 o its recipient identifying the endpoint address of the originator
216 associated with the "dataTiming" option
218 o a new "dataTiming" option having:
220 * its "noLaterThan" attribute equal to the "returnTrip" attribute
221 of the original "dataTiming" option
223 * and no other attributes present
225 o its content consisting of a "statusResponse" element having:
227 * its "transID" attribute equal to the "transID" attribute of the
228 "dataTiming" option
230 * and identifying the original recipient with a permanent success
231 indicator
233 For example:
235 +-------+ +-------+
236 | | -- data -------> | |
237 | relay | | appl. |
238 | | <--------- ok -- | #2 |
239 +-------+ +-------+
241 C:
242
243
244
246
247
248
249 S:
251 +-------+ +-------+
252 | | <------- data -- | |
253 | appl. | | relay |
254 | #1 | -- ok ---------> | |
255 +-------+ +-------+
257 C:
258
259
260
262
263
264
265
266
267
268
269
270
271
272 S:
274 2.1.2 Timing Error Report
276 If the APEX report service (c.f., Section 6.2 of [1]) is invoked to
277 send a timing error report, it issues a data operation with:
279 o its originator identifying the report service associated with the
280 issuing relay
282 o its recipient identifying the endpoint address of the originator
283 associated with the "dataTiming" option
285 o its content consisting of a "statusResponse" element having:
287 * its "transID" attribute equal to the "transID" attribute of the
288 "dataTiming" option
290 * and identifying the original recipient with a permanent failure
291 indicator
293 For example:
295 +-------+ +-------+
296 | | -- data -------> | |
297 | appl. | | relay |
298 | | <--------- ok -- | |
299 +-------+ +-------+
301 C:
302
303
304
306
307
308
309 S:
311 ... some time later ...
313 +-------+ +-------+
314 | | <------- data -- | |
315 | appl. | | relay |
316 | | -- ok ---------> | |
317 +-------+ +-------+
319 C:
320
321
322
323
324
325
326
327
328
329
330 S:
332 2.2 Reporting on Delayed Delivery
334 The "reportAfter" attribute of the "dataTiming" option provides for
335 the originator to be notified if delivery is delayed beyond a
336 specified time. Delivery of the data is not affected. Note that if
337 the value of the "noLaterThan" attribute is non-zero, then it
338 provides the operational upper-bounds for the "reportAfter"
339 attribute.
341 If this option is present in the "data" operation (c.f., Section
342 4.4.4 of [1]) and the value of the "reportAfter" attribute is non-
343 zero, then:
345 o For Step 5.2 of Section 4.4.4.1 of [1]:
347 Immediately prior to sending the data to the next relay, the value
348 of the "reportAfter" attribute is adjusted to reflect the
349 processing time of the data at the local relay (e.g., the time
350 required to determine the next relay, to successfully issue a
351 "bind" operation, and then be ready to immediately issue a "data"
352 operation).
354 If the value of the "reportAfter" attribute becomes less than or
355 equal to zero, then its value is set to zero and the APEX report
356 service is invoked to send a transient timing report; regardless,
357 the data element is sent to the next relay.
359 o For Step 5.3 of Section 4.4.4.1 of [1]:
361 If the relay does not receive an "ok" element from the recipient
362 endpoint within the number of milli-seconds indicated by the value
363 of the "reportAfter" attribute, then its value is set to zero and
364 the APEX report service is invoked to send a transient timing
365 report.
367 2.2.1 Transient Timing Report
369 If the APEX report service (c.f., Section 6.2 of [1]) is invoked to
370 send a timing error report, it issues a data operation with:
372 o its originator identifying the report service associated with the
373 issuing relay
375 o its recipient identifying the endpoint address of the originator
376 associated with the "dataTiming" option
378 o its content consisting of a "statusResponse" element having:
380 * its "transID" attribute equal to the "transID" attribute of the
381 "dataTiming" option
383 * and identifying the original recipient with a transient success
384 indicator
386 For example:
388 +-------+ +-------+
389 | | -- data -------> | |
390 | appl. | | relay |
391 | #1 | <--------- ok -- | |
392 +-------+ +-------+
394 C:
395
396
397
399
400
401
402 S:
404 ... some time later ...
406 +-------+ +-------+
407 | | <------- data -- | |
408 | relay | | relay |
409 | #n-1 | -- ok ---------> | #n |
410 +-------+ +-------+
412 C:
413
414
415
416
417
418
419
420
421
422
423 S:
425 3. The hold4Endpoint Option
427 Section 4.3 contains the APEX option registration for the
428 "hold4Endpoint" option.
430 The default behavior of the APEX relaying mesh, in the absence of
431 processing options, is to silently drop data for a recipient if its
432 endpoint isn't attached. The "hold4Endpoint" option provides for
433 data to be queued if the recipient endpoint is not attached.
435 If this option is present in the "data" operation (c.f., Section
436 4.4.4 of [1]), and the value of the "hold4Endpoint" attribute is true
437 then:
439 o For Step 5.3 of Section 4.4.4.1 of [1]:
441 If the recipient's endpoint is not currently attached, the relay
442 will queue the data waiting for an application to attach as that
443 endpoint.
445 Note that in the absence of an upper-bounds on delivery, such as
446 limits provided by the dataTiming option (Section 2), the data will
447 be queued indefinitely for the endpoint.
449 For example:
451 +-------+ +-------+
452 | | -- data -------> | |
453 | appl. | | relay |
454 | #1 | <--------- ok -- | |
455 +-------+ +-------+
457 C:
458
459
460
461
463
464
465
466 S:
468 ... some time later the recipient's endpoint attaches ...
470 +-------+ +-------+
471 | | <----- attach -- | |
472 | | | |
473 | | -- ok ---------> | |
474 | relay | | appl. |
475 | | -- data -------> | #2 |
476 | | | |
477 | | <--------- ok -- | |
478 +-------+ +-------+
480 C:
481
482
483 S:
485 C:
486
487
488
489
491
492
493
494 S:
496 4. Initial Registrations
498 The APEX option registration template is defined in Section 7.1 of
499 [1].
501 4.1 Registration: The attachOverride Option
503 Option Identification: attachOverride
505 Present in: APEX's "attach" element
507 Contains: nothing
509 Processing Rules: c.f., Section 1
511 Contact Information: c.f., the "Authors' Addresses" section of this
512 memo
514 4.2 Registration: The dataTiming Option
516 Option Identification: dataTiming
518 Present in: APEX's "data" element
520 Contains: dataTiming (c.f., Section 5)
522 Processing Rules: c.f., Section 2
524 Contact Information: c.f., the "Authors' Addresses" section of this
525 memo
527 4.3 Registration: The hold4Endpoint Option
529 Option Identification: hold4Endpoint
531 Present in: APEX's "data" element
533 Contains: nothing
535 Processing Rules: c.f., Section 3
537 Contact Information: c.f., the "Authors' Addresses" section of this
538 memo
540 5. The APEX Party Pack DTD
542
552
554 %APEXCORE;
556
565
567
568
575 6. Security Considerations
577 Consult [1]'s Section 11 for a discussion of security issues.
579 In addition:
581 o The dataTiming option (Section 2) may be used to expose private
582 network topology. Accordingly, an administrator may wish to
583 choose to disable this option except at the ingress/egress points
584 for its administrative domain.
586 o The hold4Endpoint option (Section 3) may be used to facilitate
587 denial-of-service attacks. Accordingly, an administrator may wish
588 to impose administrative limits on this attribute (e.g., always
589 require that the "dataTiming" option also be present with a short-
590 lived "noLaterThan" attribute).
592 References
594 [1] Rose, M., Klyne, G. and D. Crocker, "The Application Exchange
595 Core", draft-ietf-apex-core-01 (work in progress), May 2001.
597 [2] Newman, D., "Deliver By SMTP Service Extension", RFC 2852, June
598 2000.
600 Authors' Addresses
602 Eric Dixon
603 Invisible Worlds, Inc.
604 131 Stony Circle
605 Suite 500
606 Santa Rosa, CA 95401
607 US
609 Phone: +1 707 578 2350
610 EMail: edixon@invisible.net
611 URI: http://invisible.net/
613 Huston Franklin
614 Invisible Worlds, Inc.
615 131 Stony Circle
616 Suite 500
617 Santa Rosa, CA 95401
618 US
620 Phone: +1 707 578 2350
621 EMail: huston@invisible.net
622 URI: http://invisible.net/
624 Jay Kint
625 Invisible Worlds, Inc.
626 131 Stony Circle
627 Suite 500
628 Santa Rosa, CA 95401
629 US
631 Phone: +1 707 578 2350
632 EMail: jkint@invisible.net
633 URI: http://invisible.net/
634 Graham Klyne
635 Baltimore Technologies
636 1310 Waterside
637 Arlington Business Park
638 Theale, Reading RG7 4SA
639 UK
641 Phone: +44 118 903 8000
642 EMail: gk@acm.org
644 Darren New
645 Invisible Worlds, Inc.
646 131 Stony Circle
647 Suite 500
648 Santa Rosa, CA 95401
649 US
651 Phone: +1 707 578 2350
652 EMail: dnew@invisible.net
653 URI: http://invisible.net/
655 Scott Pead
656 Invisible Worlds, Inc.
657 131 Stony Circle
658 Suite 500
659 Santa Rosa, CA 95401
660 US
662 Phone: +1 707 578 2350
663 EMail: spead@invisible.net
664 URI: http://invisible.net/
666 Marshall T. Rose
667 Invisible Worlds, Inc.
668 131 Stony Circle
669 Suite 500
670 Santa Rosa, CA 95401
671 US
673 Phone: +1 707 578 2350
674 EMail: mrose@invisible.net
675 URI: http://invisible.net/
677 Appendix A. Acknowledgements
679 The authors gratefully acknowledge the contributions of Chris Newman;
680 further, the dataTiming option is similar in function to "Deliver By"
681 SMTP service extension defined by Dan Newman in [2].
683 Appendix B. IANA Considerations
685 The IANA makes the registrations specified in Section 4.
687 Appendix C. Changes from draft-etal-apex-party-00
689 o Rename the "roundTrip" attribute to "returnTrip".
691 o Update the examples to reflect milli-seconds instead of seconds.
693 o Remove "targetHop='all'" from "hold4Endpoint" examples.
695 o Various typos.
697 Full Copyright Statement
699 Copyright (C) The Internet Society (2001). All Rights Reserved.
701 This document and translations of it may be copied and furnished to
702 others, and derivative works that comment on or otherwise explain it
703 or assist in its implementation may be prepared, copied, published
704 and distributed, in whole or in part, without restriction of any
705 kind, provided that the above copyright notice and this paragraph are
706 included on all such copies and derivative works. However, this
707 document itself may not be modified in any way, such as by removing
708 the copyright notice or references to the Internet Society or other
709 Internet organizations, except as needed for the purpose of
710 developing Internet standards in which case the procedures for
711 copyrights defined in the Internet Standards process must be
712 followed, or as required to translate it into languages other than
713 English.
715 The limited permissions granted above are perpetual and will not be
716 revoked by the Internet Society or its successors or assigns.
718 This document and the information contained herein is provided on an
719 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
720 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
721 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
722 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
723 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
725 Acknowledgement
727 Funding for the RFC Editor function is currently provided by the
728 Internet Society.