idnits 2.17.1 draft-mrose-apex-core-03.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 separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 966: '...sRequest" option MUST NOT be present i...' Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 1440 has weird spacing: '...rminate ok ...' == Line 1522 has weird spacing: '...itiates con...' == Line 1540 has weird spacing: '... code mea...' -- 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 (February 25, 2001) is 8460 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) -- Looks like a reference, but probably isn't: 'RFC-0822' on line 1415 -- Looks like a reference, but probably isn't: 'RFC-1034' on line 1418 == Unused Reference: '10' is defined on line 1621, but no explicit reference was found in the text -- No information found for draft-drums-msg-fmt - is the name correct? -- Possible downref: Normative reference to a draft: ref. '2' ** Obsolete normative reference: RFC 2396 (ref. '5') (Obsoleted by RFC 3986) -- Possible downref: Normative reference to a draft: ref. '9' -- Possible downref: Normative reference to a draft: ref. '10' Summary: 4 errors (**), 0 flaws (~~), 6 warnings (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group M.T. Rose 3 Internet-Draft Invisible Worlds, Inc. 4 Expires: August 26, 2001 G. Klyne 5 Content Technologies Limited 6 D.H. Crocker 7 Brandenburg Consulting 8 February 25, 2001 10 The Application Exchange Core 11 draft-mrose-apex-core-03 13 Status of this Memo 15 This document is an Internet-Draft and is in full conformance with 16 all provisions of Section 10 of RFC2026. 18 Internet-Drafts are working documents of the Internet Engineering 19 Task Force (IETF), its areas, and its working groups. Note that other 20 groups may also distribute working documents as Internet-Drafts. 22 Internet-Drafts are draft documents valid for a maximum of six months 23 and may be updated, replaced, or obsoleted by other documents at any 24 time. It is inappropriate to use Internet-Drafts as reference 25 material or to cite them other than as "work in progress." 27 The list of current Internet-Drafts can be accessed at 28 http://www.ietf.org/ietf/1id-abstracts.txt. 30 The list of Internet-Draft Shadow Directories can be accessed at 31 http://www.ietf.org/shadow.html. 33 This Internet-Draft will expire on August 26, 2001. 35 Copyright Notice 37 Copyright (C) The Internet Society (2001). All Rights Reserved. 39 Abstract 41 This memo describes APEX, an extensible, asynchronous message 42 relaying service for application layer programs. 44 Table of Contents 46 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . 4 47 1.1 Overview . . . . . . . . . . . . . . . . . . . . . . . . . 5 48 1.2 Architecture at a Glance . . . . . . . . . . . . . . . . . 6 49 2. Service Principles . . . . . . . . . . . . . . . . . . . . 8 50 2.1 Modes of Operation . . . . . . . . . . . . . . . . . . . . 8 51 2.2 Naming of Entities . . . . . . . . . . . . . . . . . . . . 9 52 3. Service Provisioning . . . . . . . . . . . . . . . . . . . 10 53 3.1 Connection Establishment . . . . . . . . . . . . . . . . . 10 54 3.2 Authentication . . . . . . . . . . . . . . . . . . . . . . 10 55 3.3 Authorization . . . . . . . . . . . . . . . . . . . . . . 10 56 3.4 Confidentiality . . . . . . . . . . . . . . . . . . . . . 10 57 3.5 Relaying Integrity . . . . . . . . . . . . . . . . . . . . 11 58 3.6 Traffic Analysis . . . . . . . . . . . . . . . . . . . . . 11 59 4. The APEX . . . . . . . . . . . . . . . . . . . . . . . . . 12 60 4.1 Use of XML and MIME . . . . . . . . . . . . . . . . . . . 12 61 4.2 Profile Identification and Initialization . . . . . . . . 14 62 4.3 Message Syntax . . . . . . . . . . . . . . . . . . . . . . 14 63 4.4 Message Semantics . . . . . . . . . . . . . . . . . . . . 15 64 4.4.1 The Attach Operation . . . . . . . . . . . . . . . . . . . 15 65 4.4.2 The Bind Operation . . . . . . . . . . . . . . . . . . . . 17 66 4.4.3 The Terminate Operation . . . . . . . . . . . . . . . . . 19 67 4.4.4 The Data Operation . . . . . . . . . . . . . . . . . . . . 20 68 4.4.4.1 Relay Processing of Data . . . . . . . . . . . . . . . . . 22 69 4.4.4.2 Application Processing of Data . . . . . . . . . . . . . . 23 70 4.5 APEX Access Policies . . . . . . . . . . . . . . . . . . . 24 71 4.5.1 Access Policies in the Endpoint-Relay Mode . . . . . . . . 25 72 4.5.2 Access Policies in the Relay-Relay Mode . . . . . . . . . 26 73 5. APEX Options . . . . . . . . . . . . . . . . . . . . . . . 27 74 5.1 The statusRequest Option . . . . . . . . . . . . . . . . . 29 75 6. APEX Services . . . . . . . . . . . . . . . . . . . . . . 34 76 6.1 Use of the APEX Core DTD . . . . . . . . . . . . . . . . . 35 77 6.1.1 Transaction-Identifiers . . . . . . . . . . . . . . . . . 35 78 6.1.2 The Reply Operation . . . . . . . . . . . . . . . . . . . 36 79 6.2 The Report Service . . . . . . . . . . . . . . . . . . . . 37 80 7. Registration Templates . . . . . . . . . . . . . . . . . . 38 81 7.1 APEX Option Registration Template . . . . . . . . . . . . 38 82 7.2 APEX Service Registration Template . . . . . . . . . . . . 38 83 8. Initial Registrations . . . . . . . . . . . . . . . . . . 39 84 8.1 Registration: The APEX Profile . . . . . . . . . . . . . . 39 85 8.2 Registration: The APEX Service-Selector for GSTN . . . . . 39 86 8.3 Registration: The statusRequest Option . . . . . . . . . . 40 87 8.4 Registration: The Report Service . . . . . . . . . . . . . 40 88 9. DTDs . . . . . . . . . . . . . . . . . . . . . . . . . . . 41 89 9.1 The APEX Core DTD . . . . . . . . . . . . . . . . . . . . 41 90 9.2 The Report Service DTD . . . . . . . . . . . . . . . . . . 44 91 10. Reply Codes . . . . . . . . . . . . . . . . . . . . . . . 45 92 11. Security Considerations . . . . . . . . . . . . . . . . . 46 93 References . . . . . . . . . . . . . . . . . . . . . . . . 47 94 Authors' Addresses . . . . . . . . . . . . . . . . . . . . 47 95 A. Acknowledgements . . . . . . . . . . . . . . . . . . . . . 49 96 B. IANA Considerations . . . . . . . . . . . . . . . . . . . 50 97 C. Changes from IMXP . . . . . . . . . . . . . . . . . . . . 51 98 Full Copyright Statement . . . . . . . . . . . . . . . . . 52 100 1. Introduction 102 Network applications can be broadly distinguished by five operational 103 characteristics: 105 o server push or client pull; 107 o synchronous (interactive) or asynchronous (batch); 109 o time-assured or time-insensitive; 111 o best-effort or reliable; and, 113 o stateful or stateless. 115 For example: 117 o the world-wide web is a pull, synchronous, time-insensitive, 118 reliable, stateless service; whilst 120 o Internet mail is a push, asynchronous, time-insensitive, best- 121 effort (without DSN), stateless service. 123 Messaging applications vary considerably in their operational 124 requirements. For example, some messaging applications require 125 assurance of timeliness and reliability, whilst others do not. 127 These features come at a cost, in terms of both infrastructural and 128 configuration complexity. Accordingly, the underlying service must be 129 extensible to support different requirements in a consistent manner. 131 This memo defines a core messaging service that supports a range of 132 operational characteristics. The core service supports a variety of 133 tailored services for both user-based and programmatic exchanges. 135 1.1 Overview 137 APEX provides an extensible, asynchronous message relaying service 138 for application layer programs. 140 APEX, at its core, provides a best-effort datagram service. Each 141 datagram, simply termed "data", is originated and received by APEX 142 "endpoints" -- applications that dynamically attach to the APEX 143 "relaying mesh". 145 The data transmitted specifies: 147 o an originating endpoint; 149 o an opaque content (via a URI-reference); 151 o one or more recipient endpoints; and, 153 o zero or more options. 155 Options are used to alter the semantics of the the service, may occur 156 on a per-recipient or per-data basis, and may be processed by either 157 a single or multiple relays. 159 Additional APEX services are provided on top of the relaying mesh; 160 e.g., access control and presence information. 162 APEX is specified, in part, as a BEEP[1] "profile". Accordingly, many 163 aspects of APEX (e.g., authentication) are provided within the BEEP 164 core. Throughout this memo, the terms "peer", "initiator", 165 "listener", "client", and "server" are used in the context of BEEP. 166 In particular, Section 2.1 of the BEEP core memo discusses the roles 167 that a BEEP peer may perform. 169 When reading this memo, note that the terms "endpoint" and "relay" 170 are specific to APEX, they do not exist in the context of BEEP. 172 1.2 Architecture at a Glance 174 The APEX stack: 176 +-------------+ 177 | APEX | an APEX process is either: 178 | process | 179 +-------------+ - an application attached as an APEX 180 | | endpoint; or, 181 | APEX | 182 | | - an APEX relay 183 +-------------+ 184 | | APEX services are realized as applications 185 | BEEP | having a special relationship with the APEX 186 | | relays in their administrative domain 187 +-------------+ 188 | TCP/IP | 189 +-------------+ 190 | ... | 191 +-------------+ 193 The APEX entities: 195 administrative domain #1 administrative domain #2 196 +----------------------------+ +----------------------------+ 197 | +------+ | | +------+ | 198 | | | | | | | | 199 | | appl | | | | appl | | 200 | | | | | | | | 201 | +......+ +------+ | | +------+ +......+ | 202 | | | | | | | | | | | | 203 | |end- | |relay | | | |relay | |end- | | 204 | | point| | | | | | | | point| | 205 | +------+ +------+ | | +------+ +------+ | 206 | | | | | | | | | | | | 207 | | APEX | | APEX | | | | APEX | | APEX | | 208 | | | | | | | | | | | | 209 | +------+ +------+ | | +------+ +------+ | 210 | || || || | | || || || | 211 | ============= ================ ============= | 212 +----------------------------+ +----------------------------+ 214 | <---- APEX relaying mesh ----> | 216 Note: relaying between administrative domains is configured 217 using SRV RRs. Accordingly, the actual number of 218 relays between two endpoints is not fixed. 220 2. Service Principles 222 2.1 Modes of Operation 224 APEX is used in two modes: 226 endpoint-relay: in which the endpoint is always the BEEP initiator of 227 the service, whilst relays are always the BEEP listeners. In this 228 context, applications attach as endpoints, and then the 229 transmission of data occurs. 231 relay-relay: in which relays typically, though not necessarily, 232 reside in different administrative domains. In this context, 233 applications bind as relays, and then the transmission of data 234 occurs. 236 In the endpoint-relay mode, an endpoint (BEEP initiator) may: 238 o attach as one or more endpoints; 240 o send data to other endpoints; 242 o receive data from other endpoints; and, 244 o terminate any of its attachments. 246 A relay (BEEP listener), in addition to servicing requests from a 247 BEEP initiator, may: 249 o terminate any of the endpoint's attachments; 251 o deliver data from other endpoints; and, 253 o indicate the delivery status of data sent earlier by the endpoint. 255 In the relay-relay mode, a relay (BEEP listener or initiator) may: 257 o bind as one or more administrative domains; 259 o send data; 261 o receive data; and, 263 o terminate any bindings. 265 2.2 Naming of Entities 267 Endpoints are named using the "addr-spec" syntax specified in Section 268 3.4.1 of [2], i.e., the familiar "local@domain" syntax. 270 Using the service-selector convention of RFC 2846[3], all endpoint 271 identities having a local-part starting with "apex=" are reserved for 272 use by APEX services registered with the IANA. 274 Relays, although not named, serve of behalf of administrative 275 domains, as identified by a FQDN, e.g., "example.com". 277 In APEX, "endpoints" and "relays" are the fundamental entities. APEX 278 is carried over BEEP, which has the "peer" as its fundamental entity. 279 The relationship between BEEP peer entities and APEX endpoint and 280 relay entities are defined by APEX's Access Policies (Section 4.5). 282 3. Service Provisioning 284 3.1 Connection Establishment 286 The SRV algorithm[4] is used to determine the IP/TCP addressing 287 information assigned to the relays for an administrative domain: 289 service: "apex-edge" (for the endpoint-relay mode), or "apex-mesh" 290 (for the relay-relay mode); 292 protocol: "tcp"; and, 294 domain: the administrative domain. 296 3.2 Authentication 298 Authentication is a matter of provisioning for each BEEP peer (c.f., 299 Section 4.5). 301 An APEX relay might be provisioned to allow a BEEP peer identity to 302 coincide with a given endpoint identity. For example, a relay in the 303 "example.com" administrative domain may be configured to allow a BEEP 304 peer identified as "fred@example.com" to be authorized to attach as 305 the APEX endpoint "fred@example.com". 307 3.3 Authorization 309 Authorization is a matter of provisioning for each BEEP peer (c.f., 310 Section 4.5). 312 Typically, a relay requires that its BEEP peer authenticate as a 313 prelude to authorization, but an endpoint usually does not require 314 the same of its BEEP peer. 316 3.4 Confidentiality 318 Confidentiality is a matter of provisioning for each BEEP peer. 320 Typically, any data considered sensitive by an originating endpoint 321 will have its content encrypted for the intended recipient 322 endpoint(s), rather than relying on hop-by-hop encryption. Similarly, 323 an originating endpoint will sign the content if end-to-end 324 authentication is desired. 326 3.5 Relaying Integrity 328 Data are relayed according to SRV entries in the DNS. Accordingly, 329 relaying integrity is a function of the DNS and the applications 330 making use of the DNS. Additional assurance is provided if the BEEP 331 initiator requires that the BEEP listener authenticate itself. 333 3.6 Traffic Analysis 335 Hop-by-hop protection of data transmitted through the relaying mesh 336 (endpoint identities and content) is afforded at the BEEP level 337 through the use of a transport security profile. Other traffic 338 characteristics, e.g., volume and timing of transmissions, is not 339 protected from third-party analysis. 341 4. The APEX 343 Section 8.1 contains the BEEP profile registration for APEX. 345 4.1 Use of XML and MIME 347 Each BEEP payload exchanged via APEX consists of an XML document and 348 possibly an arbitrary MIME content. 350 If only an XML document is sent in the BEEP payload, then the mapping 351 to a BEEP payload is straight-forward, e.g., 353 C: MSG 1 2 . 111 39 354 C: Content-Type: application/beep+xml 355 C: 356 C: 357 C: END 359 Otherwise, if an arbitrary MIME content is present, it is indicated 360 by a URI-reference[5] in the XML control document. The URI-reference 361 may contain an absolute-URI (and possibly a fragment-identifier), or 362 it may be a relative-URI consisting only of a fragment-identifier. 363 Arbitrary MIME content is included in the BEEP payload by using a 364 "multipart/related"[6], identified using a "cid" URL[7], and the XML 365 control document occurs as the start of the "multipart/related", 366 e.g., 368 C: MSG 1 1 . 42 1234 369 C: Content-Type: multipart/related; boundary="boundary"; 370 C: start="<1@example.com>"; 371 C: type="application/beep+xml" 372 C: 373 C: --boundary 374 C: Content-Type: application/beep+xml 375 C: Content-ID: <1@example.com> 376 C: 377 C: 378 C: 379 C: 380 C: 381 C: --boundary 382 C: Content-Type: image/gif 383 C: Content-Transfer-Encoding: binary 384 C: Content-ID: <2@example.com> 385 C: 386 C: ... 387 C: --boundary-- 388 C: END 390 Because BEEP provides an 8bit-wide path, a "transformative" Content- 391 Transfer-Encoding (e.g., "base64" or "quoted-printable") should not 392 be used. Further, note that MIME[8] requires that the value of the 393 "Content-ID" header be globally unique. 395 If the arbitrary MIME content is itself an XML document, it may be 396 contained with the control document directly, and identified using a 397 URI-reference consisting of only a fragment-identifier, e.g., 399 C: MSG 1 1 . 42 295 400 C: Content-Type: application/beep+xml 401 C: 402 C: 403 C: 404 C: 405 C: 406 C: 407 C: 408 C: 409 C: 410 C: 411 C: 412 C: 413 C: END 415 4.2 Profile Identification and Initialization 417 The APEX is identified as 419 http://xml.resource.org/profiles/APEX 421 in the BEEP "profile" element during channel creation. 423 No elements are required to be exchanged during channel creation; 424 however, in the endpoint-relay mode, the BEEP initiator will 425 typically include an "attach" element during channel creation, e.g., 427 428 429 ]]> 431 432 434 Similarly, in the relay-relay mode, the BEEP initiator will typically 435 include an "bind" element during channel creation, e.g., 437 438 439 ]]> 441 442 444 4.3 Message Syntax 446 Section 9.1 defines the BEEP payloads that are used in the APEX. 448 4.4 Message Semantics 450 4.4.1 The Attach Operation 452 When an application wants to attach to the relaying mesh as a given 453 endpoint, it sends an "attach" element to a relay, e.g., 455 +-------+ +-------+ 456 | | -- attach -----> | | 457 | appl. | | relay | 458 | | <--------- ok -- | | 459 +-------+ +-------+ 461 C: 462 S: 464 or 466 +-------+ +-------+ 467 | | -- attach -----> | | 468 | | | | 469 | | <--------- ok -- | | 470 | appl. | | relay | 471 | | -- attach -----> | | 472 | | | | 473 | | <--------- ok -- | | 474 +-------+ +-------+ 476 C: 477 S: 478 C: 479 S: 481 or 483 +-------+ +-------+ 484 | | -- attach -----> | | 485 | appl. | | relay | 486 | | <------ error -- | | 487 +-------+ +-------+ 489 C: 490 S: access denied 492 The "attach" element has an "endpoint" attribute, a "transID" 493 attribute, and contains zero or more "option" elements: 495 o the "endpoint" attribute specifies the endpoint that the 496 application wants to attach as; 498 o the "transID" attribute specifies the transaction-identifier 499 associated with this operation; and, 501 o the "option" elements, if any, specify additional processing 502 options (Section 5). 504 When a relay receives an "attach" element, it performs these steps: 506 1. If the transaction-identifier refers to a previous, non- 507 terminated operation on this BEEP channel, an "error" element 508 having code 555 is returned. 510 2. If the relay is in a different administrative domain than this 511 endpoint, an "error" element having code 553 is returned. 513 3. If the application is not authorized to attach as this endpoint 514 (c.f., Section 4.5.1), an "error" element having code 537 is 515 returned. 517 4. If any options are present, they are processed. 519 5. If another application has already attached as this endpoint, an 520 "error" element having code 554 is returned. 522 6. Otherwise, the application is bound as this endpoint, and an "ok" 523 element is returned. 525 4.4.2 The Bind Operation 527 When an application wants to identify itself as a relay, it sends a 528 "bind" element to another relay, e.g., 530 +-------+ +-------+ 531 | | -- bind -------> | | 532 | relay | | relay | 533 | #1 | <--------- ok -- | #2 | 534 +-------+ +-------+ 536 C: 537 S: 539 or 541 +-------+ +-------+ 542 | | -- bind -------> | | 543 | | | | 544 | | <--------- ok -- | | 545 | relay | | relay | 546 | #1 | -- bind -------> | #2 | 547 | | | | 548 | | <--------- ok -- | | 549 +-------+ +-------+ 551 C: 552 S: 553 C: 554 S: 556 or 558 +-------+ +-------+ 559 | | -- bind -------> | | 560 | relay | | relay | 561 | #1 | <------ error -- | #2 | 562 +-------+ +-------+ 564 C: 565 S: access denied 567 The "bind" element has a "relay" attribute, a "transID" attribute, 568 and contains zero or more "option" elements: 570 o the "relay" attribute specifies the administrative domain on whose 571 behalf the application wants to serve; 573 o the "transID" attribute specifies the transaction-identifier 574 associated with this operation; and, 576 o the "option" elements, if any, specify additional processing 577 options (Section 5). 579 When a relay receives an "bind" element, it performs these steps: 581 1. If the transaction-identifier refers to a previous, non- 582 terminated operation on this BEEP channel, an "error" element 583 having code 555 is returned. 585 2. The relay performs the SRV algorithm[4] for the desired 586 administrative domain (i.e., using a service of "apex-mesh" and a 587 protocol of "tcp"). For each domain name returned by the 588 algorithm, the corresponding IP address(es) are retrieved using 589 the DNS. The relay compares the application's IP address and TCP 590 port number to the corresponding IP addresses and TCP port 591 numbers found using the SRV algorithm. If none match, an "error" 592 element having code 537 is returned. 594 3. If the application is not authorized to bind on behalf of this 595 administrative domain (c.f., Section 4.5.2), an "error" element 596 having code 537 is returned. 598 4. If any options are present, they are processed. 600 5. Otherwise, the application is accepted as serving this 601 administrative domain, and an "ok" element is returned. 603 4.4.3 The Terminate Operation 605 When an application or relay wants to release an attachment or 606 binding, it sends a "terminate" element, e.g., 608 +-------+ +-------+ 609 | | -- terminate --> | | 610 | appl. | | relay | 611 | | <--------- ok -- | | 612 +-------+ +-------+ 614 C: 615 S: 617 or 619 +-------+ +-------+ 620 | | -- terminate --> | | 621 | appl. | | relay | 622 | | <------ error -- | | 623 +-------+ +-------+ 625 C: 626 S: unknown transaction-identifier 628 or 630 +-------+ +-------+ 631 | | <-- terminate -- | | 632 | appl. | | relay | 633 | | -- ok ---------> | | 634 +-------+ +-------+ 636 C: 637 S: 639 The "terminate" element has a "transID" attribute and no content. 641 When an application or relay receives a "terminate" element, it 642 performs these steps: 644 1. If the transaction-identifier does not refer to a previous 645 unterminated operation on this BEEP channel, an "error" element 646 having code 550 is returned. 648 2. Otherwise, the application is no longer bound as an endpoint or a 649 relay, and an "ok" element is returned. 651 4.4.4 The Data Operation 653 When an application or relay wants to transmit data over the relaying 654 mesh, it sends a "data" element, e.g., 656 +-------+ +-------+ 657 | | -- data -------> | | 658 | appl. | | relay | 659 | #1 | <--------- ok -- | | 660 +-------+ +-------+ 662 C: 663 664 665 666 S: 668 or 670 +-------+ +-------+ 671 | | -- data -------> | | 672 | appl. | | relay | 673 | #1 | <------ error -- | | 674 +-------+ +-------+ 676 C: 677 678 679 680 S: access denied 682 or 684 +-------+ +-------+ 685 | | -- data -------> | | 686 | relay | | appl. | 687 | | <--------- ok -- | #2 | 688 +-------+ +-------+ 690 C: 691 692 693 694 S: 696 The "data" element has a "content" attribute, and contains an 697 "originator" element, one or more "recipient" elements, zero or more 698 "option" elements, and, optionally, a "data-content" element: 700 o the "content" attribute is a URI-reference that specifies the 701 contents of the data (c.f., Section 4.1); 703 o the "originator" element refers to the endpoint sending the data; 705 o each "recipient" element refers to an endpoint destination for the 706 data; 708 o the "option" elements, if any, specify additional processing 709 options (Section 5), termed per-data options; and, 711 o the "data-content" element, if present, specifies a nested XML 712 entity using a URI fragment-identifier as the value of the 713 "content" attribute. 715 The "originator" element has an "identity" attribute, and contains 716 zero or more option elements: 718 o the "identity" attribute specifies the sending endpoint; and 720 o the "option" elements, if any, specify additional processing 721 options for the originator, termed per-originator options. 723 Each "recipient" element has an "identity" attribute, and contains 724 zero or more option elements: 726 o the "identity" attribute specifies the destination endpoint; and 728 o the "option" elements, if any, specify additional processing 729 options for this recipient, termed per-recipient options. 731 4.4.4.1 Relay Processing of Data 733 When a relay receives a "data" element, it performs these steps: 735 1. If the BEEP client is not authorized to originate or relay data 736 on behalf of the "originator" endpoint (c.f., Section 4.5), an 737 "error" element having code 537 is returned. 739 2. If any per-data options are present, they are processed. 741 3. An "ok" element is returned. 743 4. If any per-originator options are present, they are processed. 745 5. For each recipient: 747 1. If any per-recipient options are present, they are processed. 749 2. If the recipient endpoint is not in the administrative domain 750 associated with the relay, then an APEX session is 751 established to a relay that accepts data for the recipient's 752 administrative domain, and a new "data" element, containing 753 that "recipient" element and all applicable options, is sent 754 to that relay. 756 If no errors (e.g., an APEX session can not be established) 757 occur during processing, and if the recipient's relay returns 758 an "ok" element, then the recipient is considered to be 759 successfully processed. 761 3. Otherwise, if the recipient endpoint is in the same 762 administrative domain as the relay, the APEX access service 763 must check that the originator endpoint is allowed to 764 communicate with the recipient endpoint (the recipient's 765 access entry[9] must contain a "core:data" token for the 766 originator), and the recipient endpoint must be currently 767 attached. 769 If so, a new "data" element, containing only that "recipient" 770 element, is sent to the corresponding application. If the 771 recipient's endpoint returns an "ok" element, then the 772 recipient is considered to be successfully processed. 774 Note that an implementation may choose to optimize its behavior by 775 grouping multiple recipients in a single "data" element that is 776 subsequently transmitted. It may do so providing that the 777 optimization retains these semantics and any other semantics related 778 to per-data and per-recipient options. 780 Finally, note that a relay receiving a "data" element from an 781 application may be configured to add domain-specific options. 783 4.4.4.2 Application Processing of Data 785 When an application receives a "data" element, it performs these 786 steps: 788 1. If any per-data or per-originator options are present, they are 789 not processed (but may be noted). 791 2. For each recipient: 793 1. If any per-recipient options are present, they are not 794 processed (but may be noted). 796 2. If the application is not attached as the recipient endpoint, 797 then an error in processing has occurred. 799 3. Otherwise, the "data" element is further processed in an 800 application-specific manner, and the recipient is considered 801 to be successfully processed. 803 3. If no recipients could be successfully processed, an "error" 804 element is returned; otherwise, an "ok" element is returned. 806 4.5 APEX Access Policies 808 Access to APEX is provided by the juxtaposition of: 810 o authenticating as a BEEP peer; 812 o attaching as an APEX endpoint or binding as an APEX relay; and, 814 o being listed as an actor by the APEX access service (c.f., [9]). 816 Each of these activities occurs according to the policies of the 817 relevant administrative domain: 819 o each administrative domain is responsible for keeping its own 820 house in order through "local provisioning"; and, 822 o each administrative domain decides the level of trust to associate 823 with other administrative domains. 825 4.5.1 Access Policies in the Endpoint-Relay Mode 827 o When an application wants to attach to the relaying mesh, local 828 provisioning maps BEEP peer identities to allowed APEX endpoints 829 (c.f., Step 3 of Section 4.4.1). 831 Typically, the identity function is used, e.g., if an application 832 authenticates itself as the BEEP peer named as "fred@example.com", 833 it is allowed to attach as the APEX endpoint named as 834 "fred@example.com". 836 Using the subaddress-specification convention of RFC 2846[3], an 837 application authorized to attach as a given APEX endpoint is also 838 authorized to attach as any sub-address of that APEX endpoint, 839 e.g., an application authorized to attach as the APEX endpoint 840 "fred@example.com" is also authorized to attach as the APEX 841 endpoint "fred/appl=wb@example.com". 843 o When an application wants to send data, local provisioning maps 844 attached endpoints to allowed originators (c.f., Step 1 of Section 845 4.4.4.1). 847 Typically, the identity function is used, e.g., if an application 848 attaches as the APEX endpoint named as "fred@example.com", it is 849 allowed to send data originating from the same APEX endpoint. 850 However, other policies are permissible, for example, the 851 administrative domain may allow the application attached as the 852 APEX endpoint named as "wilma@example.com" to send data 853 originating as either "wilma@example.com" or "fred@example.com". 855 o Finally, when a relay is delivering to an endpoint within its own 856 administrative domain, it consults the recipient's access entry 857 looking for an entry having the originator as an actor (c.f., Step 858 5.3 of Section 4.4.4.1). 860 4.5.2 Access Policies in the Relay-Relay Mode 862 o When an application wants to bind as a relay on behalf of an 863 administrative domain, in addition to Step 2 of Section 4.4.2, 864 local provisioning may map BEEP peer identities to allowed APEX 865 relays (c.f., Step 3). 867 If so, then typically the identity function is used. e.g., if an 868 application authenticates itself as the BEEP peer named as 869 "example.com", it is allowed to bind as a relay on behalf of the 870 administrative domain "example.com". 872 o When a relay is sending data, no access policies, per se, are 873 applied. 875 o When a relay is receiving data, local provisioning maps BEEP peer 876 identities to allowed originators (c.f., Step 1 of Section 877 4.4.4.1). 879 Typically, the identity function is used, e.g., if a relay 880 authenticates itself as being from the same administrative domain 881 as the originator of the data, then the data is accepted. 883 In addition, some relays may also be configured as "trusted" 884 intermediaries, so that if a BEEP peer authenticates itself as 885 being from such a relay, then the data is accepted. 887 5. APEX Options 889 APEX, at its core, provides a best-effort datagram service. Options 890 are used to alter the semantics of the core service. 892 The semantics of the APEX "option" element are context-specific. 893 Accordingly, the specification of an APEX option must define: 895 o the identity of the option; 897 o the context in which the option may appear; 899 o what content, if any, is contained within the option; and, 901 o the processing rules for the option. 903 An option registration template (Section 7.1) organizes this 904 information. 906 An "option" element is contained within either a "data", 907 "originator", or "recipient" element, all of which are termed the 908 "containing" element. The "option" element has several attributes and 909 contains arbitrary content: 911 o the "internal" and the "external" attributes, exactly one of which 912 is present, uniquely identify the option; 914 o the "targetHop" attribute specifies which relays should process 915 the option; 917 o the "seeNoEvil" attribute specifies whether the option, if 918 unrecognized, may be safely ignored; 920 o the "transID" attribute specifies a transaction-identifier for the 921 option; and, 923 o the "localize" attribute, if present, specifies one or more 924 language tokens, each identifying a desirable language tag to be 925 used if textual diagnostics are returned to the originator. 927 The value of the "internal" attribute is the IANA-registered name for 928 the option. If the "internal" attribute is not present, then the 929 value of the "external" attribute is a URI or URI with a fragment- 930 identifier. Note that a relative-URI value is not allowed. 932 The "targetHop" attribute specifies which relay(s) should process the 933 option: 935 this: the option applies to this relay, and must be removed prior 936 to transmitting the containing element. 938 final: the option applies to this relay, only if the the relay is 939 able to transmit the containing element directly to the recipient. 941 all: the option applies to this relay and is retained for the 942 next. 944 Note that a final relay does not remove any options as it transmits 945 the containing element directly to the recipient. 947 The "seeNoEvil" attribute specifies whether the relay may ignore the 948 option if it is unrecognized, and is consulted only if the 949 "targetHop" attribute indicates that the option applies to that 950 relay. If the option applies, and if the value of the "seeNoEvil" 951 attribute is "false", and if the relay does not "understand" the 952 option, then this is considered a processing error. 954 5.1 The statusRequest Option 956 Section 8.3 contains the APEX option registration for the 957 "statusRequest" option. 959 If this option is present, then each applicable relay sends a 960 "statusResponse" message to the originator. This is done by issuing a 961 data operation whose originator is the report service associated with 962 the issuing relay, whose recipient is the endpoint address of the 963 "statusRequest" originator, and whose content is a "statusResponse" 964 element. 966 A "statusRequest" option MUST NOT be present in any data operation 967 containing a "statusResponse" element. 969 Consider these examples: 971 +-------+ +-------+ 972 | | -- data -------> | | 973 | appl. | | relay | 974 | #1 | <--------- ok -- | | 975 +-------+ +-------+ 977 C: 978 979 980 983 S: 985 +-------+ +-------+ 986 | | -- data -------> | | 987 | relay | | appl. | 988 | | <--------- ok -- | #2 | 989 +-------+ +-------+ 991 C: 992 993 994 997 S: 999 +-------+ +-------+ 1000 | | <------- data -- | | 1001 | appl. | | relay | 1002 | #1 | -- ok ---------> | | 1003 +-------+ +-------+ 1005 C: 1006 1007 1008 1009 1010 1011 1012 1013 1014 1015 1016 S: 1018 or 1020 +-------+ +-------+ 1021 | | -- data -------> | | 1022 | appl. | | relay | 1023 | #1 | <--------- ok -- | | 1024 +-------+ +-------+ 1026 C: 1027 1028 1029 1032 S: 1034 +-------+ +-------+ 1035 | | <------- data -- | | 1036 | appl. | | relay | 1037 | #1 | -- ok ---------> | | 1038 +-------+ +-------+ 1040 C: 1041 1042 1043 1044 1045 1046 unknown endpoint 1047 identity 1048 1049 1050 1051 1052 S: 1054 or 1056 +-------+ +-------+ 1057 | | -- data -------> | | 1058 | appl. | | relay | 1059 | #1 | <--------- ok -- | #1 | 1060 +-------+ +-------+ 1062 C: 1063 1064 1065 1068 S: 1069 +-------+ +-------+ 1070 | | -- data -------> | | 1071 | relay | | relay | 1072 | #1 | <--------- ok -- | #2 | 1073 +-------+ +-------+ 1075 C: 1076 1077 1078 1081 S: 1083 +-------+ +-------+ 1084 | | -- data -------> | | 1085 | relay | | appl. | 1086 | #2 | <--------- ok -- | #2 | 1087 +-------+ +-------+ 1089 C: 1090 1091 1092 1095 S: 1096 +-------+ +-------+ 1097 | | <------- data -- | | 1098 | relay | | relay | 1099 | #1 | -- ok ---------> | #2 | 1100 +-------+ +-------+ 1102 C: 1103 1104 1105 1106 1107 1108 1109 1110 1111 1112 1113 S: 1115 +-------+ +-------+ 1116 | | <------- data -- | | 1117 | appl. | | relay | 1118 | #1 | -- ok ---------> | #1 | 1119 +-------+ +-------+ 1121 C: 1122 1123 1124 1125 1126 1127 1128 1129 1130 1131 1132 S: 1134 Note that a trace of a data's passage through the relaying mesh can 1135 be achieved by setting the "targetHop" attribute to "all". 1137 6. APEX Services 1139 APEX, at its core, provides a best-effort datagram service. Within an 1140 administrative domain, all relays must be able to handle messages for 1141 any endpoint within that domain. APEX services are logically defined 1142 as endpoints but given their ubiquitous semantics they do not 1143 necessarily need to be associated with a single physical endpoint. As 1144 such, they may be provisioned co-resident with each relay within an 1145 administrative domain, even though they are logically provided on top 1146 of the relaying mesh, i.e., 1148 +----------+ +----------+ +----------+ +---------+ 1149 | APEX | | APEX | | APEX | | | 1150 | access | | presence | | report | | ... | 1151 | service | | service | | service | | | 1152 +----------+ +----------+ +----------+ +---------+ 1153 | | | | 1154 | | | | 1155 +----------------------------------------------------------------+ 1156 | | 1157 | APEX core | 1158 | | 1159 +----------------------------------------------------------------+ 1161 That is, applications communicate with an APEX service by exchanging 1162 data with a "well-known endpoint" (WKE). 1164 For example, APEX applications communicate with the report service by 1165 exchanging data with the well-known endpoint "apex=report" in the 1166 corresponding administrative domain, e.g., "apex=report@example.com" 1167 is the endpoint associated with the report service in the 1168 "example.com" administrative domain. 1170 The specification of an APEX service must define: 1172 o the WKE of the service; 1174 o the syntax and sequence of messages exchanged with the service; 1176 o what access control tokens are consulted by the service. 1178 A service registration template (Section 7.2) organizes this 1179 information. 1181 Finally, note that within a single administrative domain, the 1182 relaying mesh makes use of the APEX access service in order to 1183 determine if an originator is allowed to transmit data to a recipient 1184 (c.f., Step 5.3 of Section 4.4.4.1) 1186 6.1 Use of the APEX Core DTD 1188 The specification of an APEX service may use definitions found in the 1189 APEX core DTD (Section 9.1). For example, the reply operation 1190 (Section 6.1.2) is defined to provide a common format for responses. 1192 6.1.1 Transaction-Identifiers 1194 In using APEX's transaction-identifiers, note the following: 1196 o In the endpoint-relay and relay-relay modes, transaction- 1197 identifiers are meaningful only during the lifetime of a BEEP 1198 channel. 1200 For example, when an application issues the attach operation, the 1201 associated transaction-identifier has meaning only within the 1202 context of the BEEP channel used for the attach operation. When 1203 the BEEP connection is released, the channel no longer exists and 1204 the application is no longer attached to the relaying mesh. 1206 o In contrast, when an application communicates with an APEX 1207 service, transaction-identifiers are often embedded in the data 1208 that is sent. This means that transaction-identifiers are 1209 potentially long-lived. 1211 For example, an application may attach as an endpoint, send data 1212 (containing an embedded transaction-identifier) to a service, and, 1213 some time later, detach from the relaying mesh. Later on, a second 1214 application may attach as the same endpoint, and send data of its 1215 own (also containing embedded transaction-identifiers). 1216 Subsequently, the second application may receive data from the 1217 service responding to the first application's request and 1218 containing the transaction-identifier used by the first 1219 application. 1221 To minimize the likelihood of ambiguities with long-lived 1222 transaction-identifiers, the values of transaction-identifiers 1223 generated by applications should appear to be unpredictable. 1225 6.1.2 The Reply Operation 1227 Many APEX services make use of a reply operation. Accordingly, 1228 Section 9.1 contains a definition of a "reply" element that can be 1229 used for this purpose. 1231 The "reply" element has a "code" attribute, a "transID" attribute, an 1232 optional "xml:lang" attribute, and may contain arbitrary textual 1233 content: 1235 o the "code" element specifies a three-digit reply code (c.f., 1236 Section 10); 1238 o the "transID" attribute specifies the transaction-identifier 1239 corresponding to this reply; 1241 o the "xml:lang" attribute, if present, specifies the language that 1242 the element's content is written in; and, 1244 o the textual content is a diagnostic (possibly multiline) which is 1245 meaningful to implementers, perhaps administrators, and possibly 1246 even users. 1248 6.2 The Report Service 1250 Section 8.4 contains the APEX service registration for the report 1251 service: 1253 o Within an administrative domain, the service is addressed using 1254 the well-known endpoint of "apex=report". 1256 o Section 9.2 defines the syntax of the operations exchanged with 1257 the service. 1259 o A consumer of the service does not initiate communications with 1260 the service. 1262 o The service initiates communications by sending data containing 1263 the "statusResponse" operation. 1265 If a relay processes a "statusRequest" option (Section 5.1), then it 1266 sends data to the originator containing a "statusResponse" element 1267 (Section 9.2). 1269 The "statusResponse" element has a "transID" attribute and contains 1270 one or more "destination" elements: 1272 o the "transID" attribute specifies the value contained in the 1273 "statusRequest" option; and, 1275 o each "destination" element has an "identity" attribute and 1276 contains a "reply" element: 1278 * the "identity" attribute specifies the recipient endpoint that 1279 is being reported on; and, 1281 * the "reply" element (Section 6.1.2) specifies the delivery 1282 status of that recipient. 1284 7. Registration Templates 1286 7.1 APEX Option Registration Template 1288 When an APEX option is registered, the following information is 1289 supplied: 1291 Option Identification: specify the NMTOKEN or the URI that 1292 authoritatively identifies this option. 1294 Present in: specify the APEX elements in which the option may appear. 1296 Contains: specify the XML content that is contained within the 1297 "option" element. 1299 Processing Rules: specify the processing rules associated with the 1300 option. 1302 Contact Information: specify the postal and electronic contact 1303 information for the author of the profile. 1305 7.2 APEX Service Registration Template 1307 When an APEX service is registered, the following information is 1308 supplied: 1310 Well-Known Endpoint: specify the local-part of an endpoint identity, 1311 starting with "apex=". 1313 Syntax of Messages Exchanged: specify the elements exchanged with the 1314 service. 1316 Sequence of Messages Exchanged: specify the order in which data is 1317 exchanged with the service. 1319 Access Control Tokens: specify the token(s) used to control access to 1320 the service (c.f., [9]). 1322 Contact Information: specify the postal and electronic contact 1323 information for the author of the profile. 1325 8. Initial Registrations 1327 8.1 Registration: The APEX Profile 1329 Profile Identification: http://xml.resource.org/profiles/APEX 1331 Messages exchanged during Channel Creation: "attach", "bind" 1333 Messages starting one-to-one exchanges: "attach", "bind", 1334 "terminate", or "data" 1336 Messages in positive replies: "ok" 1338 Messages in negative replies: "error" 1340 Messages in one-to-many exchanges: none 1342 Message Syntax: c.f., Section 9.1 1344 Message Semantics: c.f., Section 4.4 1346 Contact Information: c.f., the "Authors' Addresses" section of this 1347 memo 1349 8.2 Registration: The APEX Service-Selector for GSTN 1351 Service-Selector Name: APEX 1353 Description of Use: Specifies endpoints for registered APEX services 1354 on the host indicated by the address' domain name, c.f., Section 6 1356 Security Considerations: The definition of a service-related endpoint 1357 does not introduce security concerns, per se; however, because the 1358 defined endpoints are service control points, the nature of 1359 messages sent to them may introduce security concerns 1361 Contact Information: c.f., the "Authors' Addresses" section of this 1362 memo 1364 8.3 Registration: The statusRequest Option 1366 Option Identification: statusRequest 1368 Present in: APEX's "data" and "recipient" elements 1370 Contains: nothing 1372 Processing Rules: c.f., Section 5.1 1374 Contact Information: c.f., the "Authors' Addresses" section of this 1375 memo 1377 8.4 Registration: The Report Service 1379 Well-Known Endpoint: apex=report 1381 Syntax of Messages Exchanged: c.f., Section 9.2 1383 Sequence of Messages Exchanged: c.f., Section 6.2 1385 Access Control Tokens: none 1387 Contact Information: c.f., the "Authors' Addresses" section of this 1388 memo 1390 9. DTDs 1392 9.1 The APEX Core DTD 1394 1404 1406 %BEEP; 1408 1427 1428 1429 1430 1431 1445 1446 1450 1451 1455 1456 1459 1460 1463 1464 1467 1468 1471 1473 1474 1476 1477 1481 1482 1487 1490 1491 1499 9.2 The Report Service DTD 1501 1511 1513 %APEXCORE; 1515 1529 1531 1534 1535 1538 10. Reply Codes 1540 code meaning 1541 ==== ======= 1542 250 transaction successful 1544 421 service not available 1546 450 requested action not taken 1548 451 requested action aborted 1550 454 temporary authentication failure 1552 500 general syntax error (e.g., poorly-formed XML) 1554 501 syntax error in parameters (e.g., non-valid XML) 1556 504 parameter not implemented 1558 530 authentication required 1560 534 authentication mechanism insufficient 1562 535 authentication failure 1564 537 action not authorized for user 1566 538 authentication mechanism requires encryption 1568 550 requested action not taken 1570 553 parameter invalid 1572 554 transaction failed (e.g., policy violation) 1574 555 transaction already in progress 1576 11. Security Considerations 1578 Consult Section 3 and Section 4.5 for a discussion of security 1579 issues, e.g., relaying integrity. In addition, since APEX is a 1580 profile of the BEEP, consult [1]'s Section 9 for a discussion of 1581 BEEP-specific security issues. 1583 In addition, the statusRequest option (Section 5.1) may be used to 1584 expose private network topology. Accordingly, administrators may wish 1585 to choose to disable this option except at the ingress/egress points 1586 for their domain. 1588 References 1590 [1] Rose, M.T., "The Blocks Extensible Exchange Protocol Core", 1591 draft-ietf-beep-framework-11 (work in progress), January 2001. 1593 [2] Resnick, P., "Internet Message Format", draft-drums-msg-fmt-09 1594 (work in progress), September 2000. 1596 [3] Allocchio, C., "GSTN Address Element Extensions in E-mail 1597 Services", RFC 2846, June 2000. 1599 [4] Gulbrandsen, A., Vixie, P. and L. Esibov, "A DNS RR for 1600 specifying the location of services (DNS SRV)", RFC 2782, 1601 February 2000. 1603 [5] Berners-Lee, T., Fielding, R.T. and L. Masinter, "Uniform 1604 Resource Identifiers (URI): Generic Syntax", RFC 2396, August 1605 1998. 1607 [6] Levinson, E., "The MIME Multipart/Related Content-type", RFC 1608 2387, August 1998. 1610 [7] Levinson, E., "Content-ID and Message-ID Uniform Resource 1611 Locators", RFC 2392, August 1998. 1613 [8] Freed, N. and N. Borenstein, "Multipurpose Internet Mail 1614 Extensions (MIME) Part One: Format of Internet Message Bodies", 1615 RFC 2045, November 1996. 1617 [9] Rose, M.T., Klyne, G. and D.H. Crocker, "The APEX Access 1618 Service", draft-mrose-apex-access-02 (work in progress), 1619 December 2000. 1621 [10] Rose, M.T., Klyne, G. and D.H. Crocker, "The APEX Presence 1622 Service", draft-mrose-apex-presence-03 (work in progress), 1623 February 2001. 1625 Authors' Addresses 1627 Marshall T. Rose 1628 Invisible Worlds, Inc. 1629 1179 North McDowell Boulevard 1630 Petaluma, CA 94954-6559 1631 US 1633 Phone: +1 707 789 3700 1634 EMail: mrose@invisible.net 1635 URI: http://invisible.net/ 1637 Graham Klyne 1638 Content Technologies Limited 1639 1220 Parkview 1640 Arlington Business Park 1641 Theale, Reading RG7 4SA 1642 UK 1644 Phone: +44 118 930 1300 1645 EMail: gk@acm.org 1647 David H. Crocker 1648 Brandenburg Consulting 1649 675 Spruce Drive 1650 Sunnyvale, CA 94086 1651 US 1653 Phone: +1 408 246 8253 1654 EMail: dcrocker@brandenburg.com 1655 URI: http://www.brandenburg.com/ 1657 Appendix A. Acknowledgements 1659 The authors gratefully acknowledge the contributions of: Harald 1660 Alvestrand, Eric Dixon, Darren New, Chris Newman, and Scott Pead. 1662 Appendix B. IANA Considerations 1664 The IANA registers "APEX" as a standards-track BEEP profile, as 1665 specified in Section 8.1. 1667 The IANA registers "apex" as a GSTN service-selector, as specified in 1668 Section 8.2. 1670 The IANA maintains a list of: 1672 o APEX options, c.f., Section 7.1; and, 1674 o APEX services, c.f., Section 7.2. 1676 For each list, the IESG is responsible for assigning a designated 1677 expert to review the specification prior to the IANA making the 1678 assignment. As a courtesy to developers of non-standards track APEX 1679 options and services, the mailing list apexwg@invisible.net may be 1680 used to solicit commentary. 1682 The IANA makes the registrations specified in Section 8.3 and Section 1683 8.4. 1685 Appendix C. Changes from IMXP 1687 o s/IMXP/APEX/g 1689 o Clarify the notion of co-residence for APEX services. 1691 o Change data's originator from an attribute to an element. 1693 o Change addr-spec reference from RFC 822 to [2]. 1695 o Move the section on "IANA Considerations" to an appendix. 1697 Full Copyright Statement 1699 Copyright (C) The Internet Society (2001). All Rights Reserved. 1701 This document and translations of it may be copied and furnished to 1702 others, and derivative works that comment on or otherwise explain it 1703 or assist in its implementation may be prepared, copied, published 1704 and distributed, in whole or in part, without restriction of any 1705 kind, provided that the above copyright notice and this paragraph are 1706 included on all such copies and derivative works. However, this 1707 document itself may not be modified in any way, such as by removing 1708 the copyright notice or references to the Internet Society or other 1709 Internet organizations, except as needed for the purpose of 1710 developing Internet standards in which case the procedures for 1711 copyrights defined in the Internet Standards process must be 1712 followed, or as required to translate it into languages other than 1713 English. 1715 The limited permissions granted above are perpetual and will not be 1716 revoked by the Internet Society or its successors or assigns. 1718 This document and the information contained herein is provided on an 1719 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 1720 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 1721 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 1722 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 1723 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1725 Acknowledgement 1727 Funding for the RFC Editor function is currently provided by the 1728 Internet Society.