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.