idnits 2.17.1 draft-mrose-imxp-access-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 a Security Considerations section. ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** 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 == Line 518 has weird spacing: '...itiates ser...' -- 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 (September 2000) is 8595 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) -- Possible downref: Normative reference to a draft: ref. '1' == Outdated reference: A later version (-11) exists of draft-ietf-beep-framework-02 ** Obsolete normative reference: RFC 822 (ref. '3') (Obsoleted by RFC 2822) Summary: 5 errors (**), 0 flaws (~~), 4 warnings (==), 3 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: March 2, 2001 G. Klyne 5 Content Technologies Limited 6 D.H. Crocker 7 Brandenburg Consulting 8 September 2000 10 The IMXP Access Service 11 draft-mrose-imxp-access-01 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 20 other groups may also distribute working documents as 21 Internet-Drafts. 23 Internet-Drafts are draft documents valid for a maximum of six 24 months and may be updated, replaced, or obsoleted by other documents 25 at any time. It is inappropriate to use Internet-Drafts as reference 26 material or to cite them other than as "work in progress." 28 The list of current Internet-Drafts can be accessed at 29 http://www.ietf.org/ietf/1id-abstracts.txt. 31 The list of Internet-Draft Shadow Directories can be accessed at 32 http://www.ietf.org/shadow.html. 34 This Internet-Draft will expire on March 2, 2001. 36 Copyright Notice 38 Copyright (C) The Internet Society (2000). All Rights Reserved. 40 Abstract 42 This memo describes the IMXP access service, addressed as the 43 well-known endpoint "imxp=access". The access service is used to 44 control use of both the IMXP "relaying mesh" and other IMXP services. 46 Table of Contents 48 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 49 2. Management of Access Information . . . . . . . . . . . . . . . 4 50 2.1 Retrieval of Access Information . . . . . . . . . . . . . . . 5 51 2.2 Update of Access Information . . . . . . . . . . . . . . . . . 6 52 3. Format of Access Entries . . . . . . . . . . . . . . . . . . . 7 53 4. The Access Service . . . . . . . . . . . . . . . . . . . . . . 9 54 4.1 Use of XML and MIME . . . . . . . . . . . . . . . . . . . . . 10 55 4.2 The Get Operation . . . . . . . . . . . . . . . . . . . . . . 11 56 4.3 The Set Operation . . . . . . . . . . . . . . . . . . . . . . 12 57 4.4 The Reply Operation . . . . . . . . . . . . . . . . . . . . . 14 58 5. Registration: The Access Service . . . . . . . . . . . . . . . 15 59 6. The Access Service DTD . . . . . . . . . . . . . . . . . . . . 16 60 References . . . . . . . . . . . . . . . . . . . . . . . . . . 19 61 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 19 62 A. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 20 63 B. Changes from draft-mrose-imxp-access-00 . . . . . . . . . . . 21 64 Full Copyright Statement . . . . . . . . . . . . . . . . . . . 22 66 1. Introduction 68 This memo describes a access service that is built upon the IMXP[1] 69 "relaying mesh", which, in turn, is specified as a BEEP[2] profile. 71 IMXP at its core, provides a best-effort datagram service. With the 72 exception of a co-resident IMXP report service (used for error 73 reporting), all other IMXP services are provided on top of IMXP's 74 "relaying mesh", e.g., 76 +----------+ +----------+ +----------+ 77 | IMXP | | IMXP | | | 78 | access | | presence | | ... | 79 | service | | service | | | 80 +----------+ +----------+ +----------+ 81 | | | 82 | | | 83 +------------------------------------------------+---------+ 84 | | IMXP | 85 | IMXP core | report | 86 | | service | 87 +------------------------------------------------+---------+ 89 Applications communicate with IMXP services by sending data to a 90 "well-known endpoint" (WKE). 92 The IMXP access service is used to control use of both the relaying 93 mesh and other IMXP services. Although the access service is 94 logically layered above the IMXP core, implementers may choose to 95 physically co-reside the access service with IMXP core software. 97 IMXP applications communicate with the access service by exchanging 98 data with the well-known endpoint "imxp=access" in the corresponding 99 administrative domain, e.g., "imxp=access@example.com" is the 100 endpoint associated with the access service in the "example.com" 101 administrative domain. 103 Note that within a single administrative domain, the relaying mesh 104 makes use of the IMXP access service in order to determine if an 105 originator is allowed to transmit data to a recipient (c.f., Step 106 3.3 of Section 4.4.3.1 of [1]). 108 2. Management of Access Information 110 Management of access information falls into two categories: 112 o applications may retrieve the access entry associated with an 113 endpoint; and, 115 o applications may modify the access entry associated with an 116 endpoint. 118 Each is now described in turn. 120 2.1 Retrieval of Access Information 122 When an application wants to retrieve the access entry associated 123 with an endpoint, it sends a "get" element to the service, e.g., 125 +-------+ +-------+ 126 | | -- data -------> | | 127 | appl. | | relay | 128 | | <--------- ok -- | | 129 +-------+ +-------+ 131 C: 132 133 134 135 136 137 S: 139 The service immediately responds with a set operation containing the 140 access entry and the same transaction-identifier, e.g., 142 +-------+ +-------+ 143 | | <------- data -- | | 144 | relay | |access | 145 | | -- ok ---------> | svc. | 146 +-------+ +-------+ 148 C: 149 150 151 153 155 157 158 159 160 161 162 S: 164 2.2 Update of Access Information 166 When an application wants to modify the access entry associated with 167 an endpoint, it sends a "set" element to the service, e.g., 169 +-------+ +-------+ 170 | | -- data -------> | | 171 | appl. | | relay | 172 | | <--------- ok -- | | 173 +-------+ +-------+ 175 C: 176 177 178 ... 180 181 182 S: 184 The service immediately responds with a reply operation containing 185 the same transaction-identifier, e.g., 187 +-------+ +-------+ 188 | | <------- data -- | | 189 | relay | |access | 190 | | -- ok ---------> | svc. | 191 +-------+ +-------+ 193 C: 194 195 196 197 198 199 S: 201 3. Format of Access Entries 203 Each administrative domain is responsible for maintaining an "access 204 entry" for each of its endpoints (regardless of whether those 205 endpoints are currently attached to the relaying mesh). 207 Section 6 defines the syntax for access entries. Each access entry 208 has an "owner" attribute, a "lastUpdate" attribute, and contains one 209 or more "entry" elements: 211 o the "owner" attribute specifies the endpoint associated with the 212 access entry; 214 o the "lastUpdate" attribute specifies the date and time that the 215 service last updated the access entry; and, 217 o each "entry" element specifies, with respect to the owner's 218 endpoint, an actor and zero or more allowed actions for that 219 actor. 221 Within an entry, actions are specified as service/operation pairs, 222 (e.g., "presence:publish" refers to the "publish" operation of the 223 "presence" service). To refer to all services and/or all operations, 224 the reserved value "all" is used (e.g., "all:data", "presence:all", 225 and so on). Note that the service specified as "core" is reserved 226 for use by the relaying mesh, e.g., the "core:data" action is 227 consulted by the relaying mesh (c.f., Step 3.3 of Section 4.4.3.1 of 228 [1]). 230 An actor is an IMXP endpoint and is specified using the "addr-spec" 231 syntax of RFC 822[3], i.e., "local@domain". However, both the 232 "local" and "domain" parts may contain limited wildcarding: 234 o The "local" part is either: 236 * a literal string (e.g., "fred"); or, 238 * the value "imxp=*", specifying all IMXP services; or, 240 * the value "*", specifying any endpoint other than an IMXP 241 service. 243 o The "domain" part is either: 245 * a FQDN (e.g., "example.com"); or, 247 * the value "*", specifying all administrative domains. 249 Regardless of the "entry" elements present in an access entry, four 250 additional elements are always considered to exist at the end of the 251 access entry: 253 254 255 256 258 where "local@domain" specifies the endpoint associated with the 259 access entry. 261 Ordering of "entry" elements within an access element is 262 significant: a process examining an access element selects the first 263 "entry" element that matches the actor in question. For example, 264 consider this access entry: 266 268 269 270 272 273 275 Briefly: 277 o For endpoints within the "example.com" administrative domain: 279 * "fred", "wilma", and all IMXP services, are allowed access to 280 all operations for all IMXP services; 282 * "mr.slate" is allowed access only to send data through the 283 relaying mesh; and, 285 * any other endpoint is allowed access to send data and invoke 286 the "subscribe" and "watch" operations of the IMXP presence 287 service. 289 o For any endpoint outside the "example.com" administrative domain, 290 the endpoint is allowed access to send data, regardless of 291 whether it is an IMXP service. 293 Note that although the four additional elements are always present, 294 the ordering semantics cause the final element to be unused. 296 4. The Access Service 298 Section 5 contains the IMXP service registration for the access 299 service: 301 o Within an administrative domain, the service is addressed using 302 the well-known endpoint of "imxp=access". 304 o Section 6 defines the syntax of the operations exchanged with the 305 service. 307 o A consumer of the service initiates communications by sending 308 data containing either the get or set operation. 310 o The service replies to these operations, and does not initiate 311 communications. 313 An implementation of the service must maintain information about 314 access entries in persistent storage. 316 Consult Section 6.1.1 of [1] for a discussion on the properties of 317 long-lived transaction-identifiers. 319 4.1 Use of XML and MIME 321 Section 4.1 of [1] describes how arbitrary MIME content is exchanged 322 as a BEEP payload. For example, to transmit: 324 325 326 328 where "..." refers to: 330 332 then the corresponding BEEP operation might look like this: 334 C: MSG 1 2 . 42 1234 335 C: Content-Type: multipart/related; boundary="boundary"; 336 C: start="<1@example.com>"; 337 C: type="text/xml" 338 C: 339 C: --boundary 340 C: Content-Type: text/xml 341 C: Content-ID: <1@example.com> 342 C: 343 C: 345 C: 346 C: 347 C: --boundary 348 C: Content-Type: text/xml 349 C: Content-Transfer-Encoding: binary 350 C: Content-ID: <2@example.com> 351 C: 352 C: 353 C: --boundary-- 354 C: END 356 or this: 358 C: MSG 1 1 . 42 255 359 C: Content-Type: text/xml 360 C: 361 C: 362 C: 363 C: 364 C: 365 C: 366 C: 367 C: END 369 4.2 The Get Operation 371 When an application wants to retrieve the access entry associated 372 with an endpoint, it sends a "get" element to the service. 374 The "get" element has an "owner" attribute, a "transID" attribute, 375 and no content: 377 o the "owner" attribute specifies the endpoint associated with the 378 access entry; and, 380 o the "transID" attribute specifies the transaction-identifier 381 associated with this operation. 383 When the service receives a "get" element, we refer to the "owner" 384 attribute of that element as the "subject", and the service performs 385 these steps: 387 1. If the subject is outside of this administrative domain, a 388 "reply" element having code 553 is sent as data to the 389 originator. 391 2. If the subject does not refer to a valid endpoint, a "reply" 392 element having code 550 is sent as data to the originator. 394 3. If the subject's access entry does not contain a "access:get" 395 token for the originator, a "reply" element having code 537 is 396 sent as data to the originator. 398 4. Otherwise, a "set" element, corresponding to the subject's 399 access entry, is sent as data to the originator. 401 Regardless of whether a "set" or "reply" element is sent to the 402 originator, the "transID" attribute is identical to the value found 403 in the "get" element sent by the originator. 405 4.3 The Set Operation 407 When an application wants to modify the access entry associated with 408 an endpoint, it sends a "set" element to the service. 410 The "set" element has an "owner" attribute, a "transID" attribute, 411 and contains an "access" element: 413 o the "owner" attribute specifies the endpoint to be associated 414 with the access entry; 416 o the "transID" attribute specifies the transaction-identifier 417 associated with this operation; 419 o the "timeStamp" attribute specifies the current date and time; 420 and, 422 o the "access" element contains the desired access entry for the 423 endpoint. 425 When the service receives a "set" element, we refer to the "owner" 426 attribute of that element as the "subject", and the service performs 427 these steps: 429 1. If the "owner" attribute of the "set" element doesn't match the 430 "owner" attribute of the "access" element contained in the "set" 431 element, a "reply" element having code 503 is sent as data to 432 the originator. 434 2. If the subject is outside of this administrative domain, a 435 "reply" element having code 553 is sent as data to the 436 originator. 438 3. If the subject does not refer to a valid endpoint, a "reply" 439 element having code 550 is sent as data to the originator. 441 4. If the subject's access entry does not contain a "access:set" 442 token for the originator, a "reply" element having code 537 is 443 sent as data to the originator. 445 5. If the "lastUpdate" attribute of the "set" element is not 446 semantically identical to the last update time of the subject's 447 access entry, a "reply" element having code 555 is sent as data 448 to the originator. (This allows a basic mechanism for atomic 449 updates.) 451 6. Otherwise: 453 1. The subject's access entry is updated from the "set" element. 455 2. The last update time of the access entry is set to the 456 current time. 458 3. A "reply" element having code 250 is sent as data to the 459 originator. 461 When sending the "reply" element, the "transID" attribute is 462 identical to the value found in the "set" element sent by the 463 originator. 465 4.4 The Reply Operation 467 While processing operations, the service may respond with a "reply" 468 element. Consult Sections 10.2 and 6.1.2 of [1], respectively, for 469 the syntax and semantics of the reply operation. 471 5. Registration: The Access Service 473 Well-Known Endpoint: imxp=access 475 Syntax of Messages Exchanged: c.f., Section 6 477 Sequence of Messages Exchanged: c.f., Section 4 479 Access Control Tokens: access:get, access:set 481 Contact Information: c.f., the "Authors' Addresses" section of this 482 memo 484 6. The Access Service DTD 486 496 498 %IMXPCORE; 500 510 511 531 532 536 538 539 544 548 549 553 554 558 References 560 [1] Rose, M.T., Klyne, G. and D.H. Crocker, "The IMXP", 561 draft-mrose-imxp-core-01 (work in progress), September 2000. 563 [2] Rose, M.T., "The Blocks Extensible Exchange Protocol 564 Framework", draft-ietf-beep-framework-02 (work in progress), 565 September 2000. 567 [3] Crocker, D., "Standard for the format of ARPA Internet text 568 messages", RFC 822, STD 11, Aug 1982. 570 Authors' Addresses 572 Marshall T. Rose 573 Invisible Worlds, Inc. 574 1179 North McDowell Boulevard 575 Petaluma, CA 94954-6559 576 US 578 Phone: +1 707 789 3700 579 EMail: mrose@invisible.net 580 URI: http://invisible.net/ 582 Graham Klyne 583 Content Technologies Limited 584 1220 Parkview 585 Arlington Business Park 586 Theale, Reading RG7 4SA 587 UK 589 Phone: +44 118 930 1300 590 EMail: gk@acm.org 592 David H. Crocker 593 Brandenburg Consulting 594 675 Spruce Drive 595 Sunnyvale, CA 94086 596 US 598 Phone: +1 408 246 8253 599 EMail: dcrocker@brandenburg.com 600 URI: http://www.brandenburg.com/ 602 Appendix A. Acknowledgements 604 The authors gratefully acknowledge the contributions of: Darren New 605 and Scott Pead. 607 Appendix B. Changes from draft-mrose-imxp-access-00 609 o Updated to reflect the current BEEP framework[2]. 611 Full Copyright Statement 613 Copyright (C) The Internet Society (2000). All Rights Reserved. 615 This document and translations of it may be copied and furnished to 616 others, and derivative works that comment on or otherwise explain it 617 or assist in its implementation may be prepared, copied, published 618 and distributed, in whole or in part, without restriction of any 619 kind, provided that the above copyright notice and this paragraph 620 are included on all such copies and derivative works. However, this 621 document itself may not be modified in any way, such as by removing 622 the copyright notice or references to the Internet Society or other 623 Internet organizations, except as needed for the purpose of 624 developing Internet standards in which case the procedures for 625 copyrights defined in the Internet Standards process must be 626 followed, or as required to translate it into languages other than 627 English. 629 The limited permissions granted above are perpetual and will not be 630 revoked by the Internet Society or its successors or assigns. 632 This document and the information contained herein is provided on an 633 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 634 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 635 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 636 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 637 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 639 Acknowledgement 641 Funding for the RFC editor function is currently provided by the 642 Internet Society.