File: rfc3341.txt

package info (click to toggle)
doc-rfc 20181229-2
  • links: PTS, VCS
  • area: non-free
  • in suites: buster
  • size: 570,944 kB
  • sloc: xml: 285,646; sh: 107; python: 90; perl: 42; makefile: 14
file content (1459 lines) | stat: -rw-r--r-- 46,675 bytes parent folder | download | duplicates (5)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
452
453
454
455
456
457
458
459
460
461
462
463
464
465
466
467
468
469
470
471
472
473
474
475
476
477
478
479
480
481
482
483
484
485
486
487
488
489
490
491
492
493
494
495
496
497
498
499
500
501
502
503
504
505
506
507
508
509
510
511
512
513
514
515
516
517
518
519
520
521
522
523
524
525
526
527
528
529
530
531
532
533
534
535
536
537
538
539
540
541
542
543
544
545
546
547
548
549
550
551
552
553
554
555
556
557
558
559
560
561
562
563
564
565
566
567
568
569
570
571
572
573
574
575
576
577
578
579
580
581
582
583
584
585
586
587
588
589
590
591
592
593
594
595
596
597
598
599
600
601
602
603
604
605
606
607
608
609
610
611
612
613
614
615
616
617
618
619
620
621
622
623
624
625
626
627
628
629
630
631
632
633
634
635
636
637
638
639
640
641
642
643
644
645
646
647
648
649
650
651
652
653
654
655
656
657
658
659
660
661
662
663
664
665
666
667
668
669
670
671
672
673
674
675
676
677
678
679
680
681
682
683
684
685
686
687
688
689
690
691
692
693
694
695
696
697
698
699
700
701
702
703
704
705
706
707
708
709
710
711
712
713
714
715
716
717
718
719
720
721
722
723
724
725
726
727
728
729
730
731
732
733
734
735
736
737
738
739
740
741
742
743
744
745
746
747
748
749
750
751
752
753
754
755
756
757
758
759
760
761
762
763
764
765
766
767
768
769
770
771
772
773
774
775
776
777
778
779
780
781
782
783
784
785
786
787
788
789
790
791
792
793
794
795
796
797
798
799
800
801
802
803
804
805
806
807
808
809
810
811
812
813
814
815
816
817
818
819
820
821
822
823
824
825
826
827
828
829
830
831
832
833
834
835
836
837
838
839
840
841
842
843
844
845
846
847
848
849
850
851
852
853
854
855
856
857
858
859
860
861
862
863
864
865
866
867
868
869
870
871
872
873
874
875
876
877
878
879
880
881
882
883
884
885
886
887
888
889
890
891
892
893
894
895
896
897
898
899
900
901
902
903
904
905
906
907
908
909
910
911
912
913
914
915
916
917
918
919
920
921
922
923
924
925
926
927
928
929
930
931
932
933
934
935
936
937
938
939
940
941
942
943
944
945
946
947
948
949
950
951
952
953
954
955
956
957
958
959
960
961
962
963
964
965
966
967
968
969
970
971
972
973
974
975
976
977
978
979
980
981
982
983
984
985
986
987
988
989
990
991
992
993
994
995
996
997
998
999
1000
1001
1002
1003
1004
1005
1006
1007
1008
1009
1010
1011
1012
1013
1014
1015
1016
1017
1018
1019
1020
1021
1022
1023
1024
1025
1026
1027
1028
1029
1030
1031
1032
1033
1034
1035
1036
1037
1038
1039
1040
1041
1042
1043
1044
1045
1046
1047
1048
1049
1050
1051
1052
1053
1054
1055
1056
1057
1058
1059
1060
1061
1062
1063
1064
1065
1066
1067
1068
1069
1070
1071
1072
1073
1074
1075
1076
1077
1078
1079
1080
1081
1082
1083
1084
1085
1086
1087
1088
1089
1090
1091
1092
1093
1094
1095
1096
1097
1098
1099
1100
1101
1102
1103
1104
1105
1106
1107
1108
1109
1110
1111
1112
1113
1114
1115
1116
1117
1118
1119
1120
1121
1122
1123
1124
1125
1126
1127
1128
1129
1130
1131
1132
1133
1134
1135
1136
1137
1138
1139
1140
1141
1142
1143
1144
1145
1146
1147
1148
1149
1150
1151
1152
1153
1154
1155
1156
1157
1158
1159
1160
1161
1162
1163
1164
1165
1166
1167
1168
1169
1170
1171
1172
1173
1174
1175
1176
1177
1178
1179
1180
1181
1182
1183
1184
1185
1186
1187
1188
1189
1190
1191
1192
1193
1194
1195
1196
1197
1198
1199
1200
1201
1202
1203
1204
1205
1206
1207
1208
1209
1210
1211
1212
1213
1214
1215
1216
1217
1218
1219
1220
1221
1222
1223
1224
1225
1226
1227
1228
1229
1230
1231
1232
1233
1234
1235
1236
1237
1238
1239
1240
1241
1242
1243
1244
1245
1246
1247
1248
1249
1250
1251
1252
1253
1254
1255
1256
1257
1258
1259
1260
1261
1262
1263
1264
1265
1266
1267
1268
1269
1270
1271
1272
1273
1274
1275
1276
1277
1278
1279
1280
1281
1282
1283
1284
1285
1286
1287
1288
1289
1290
1291
1292
1293
1294
1295
1296
1297
1298
1299
1300
1301
1302
1303
1304
1305
1306
1307
1308
1309
1310
1311
1312
1313
1314
1315
1316
1317
1318
1319
1320
1321
1322
1323
1324
1325
1326
1327
1328
1329
1330
1331
1332
1333
1334
1335
1336
1337
1338
1339
1340
1341
1342
1343
1344
1345
1346
1347
1348
1349
1350
1351
1352
1353
1354
1355
1356
1357
1358
1359
1360
1361
1362
1363
1364
1365
1366
1367
1368
1369
1370
1371
1372
1373
1374
1375
1376
1377
1378
1379
1380
1381
1382
1383
1384
1385
1386
1387
1388
1389
1390
1391
1392
1393
1394
1395
1396
1397
1398
1399
1400
1401
1402
1403
1404
1405
1406
1407
1408
1409
1410
1411
1412
1413
1414
1415
1416
1417
1418
1419
1420
1421
1422
1423
1424
1425
1426
1427
1428
1429
1430
1431
1432
1433
1434
1435
1436
1437
1438
1439
1440
1441
1442
1443
1444
1445
1446
1447
1448
1449
1450
1451
1452
1453
1454
1455
1456
1457
1458
1459






Network Working Group                                            M. Rose
Request for Comments: 3341                  Dover Beach Consulting, Inc.
Category: Standards Track                                       G. Klyne
                                                  Clearswift Corporation
                                                              D. Crocker
                                             Brandenburg InternetWorking
                                                               July 2002


             The Application Exchange (APEX) Access Service

Status of this Memo

   This document specifies an Internet standards track protocol for the
   Internet community, and requests discussion and suggestions for
   improvements.  Please refer to the current edition of the "Internet
   Official Protocol Standards" (STD 1) for the standardization state
   and status of this protocol.  Distribution of this memo is unlimited.

Copyright Notice

   Copyright (C) The Internet Society (2002).  All Rights Reserved.

Abstract

   This memo describes the Application Exchange (APEX) access service,
   addressed as the well-known endpoint "apex=access".  The access
   service is used to control use of both the APEX "relaying mesh" and
   other APEX services.

Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  2
   2.  Use and Management of Access Information . . . . . . . . . . .  3
   2.1 Querying Access Information  . . . . . . . . . . . . . . . . .  3
   2.2 Retrieval of Access Information  . . . . . . . . . . . . . . .  4
   2.3 Update of Access Information . . . . . . . . . . . . . . . . .  5
   3.  Format of Access Entries . . . . . . . . . . . . . . . . . . .  9
   3.1 Finding the Appropriate Entry: Matching Owners and Actors  . . 11
   3.2 Creating and Updating Access Entries . . . . . . . . . . . . . 14
   4.  The Access Service . . . . . . . . . . . . . . . . . . . . . . 14
   4.1 Use of XML and MIME  . . . . . . . . . . . . . . . . . . . . . 15
   4.2 The Query Operation  . . . . . . . . . . . . . . . . . . . . . 16
   4.3 The Get Operation  . . . . . . . . . . . . . . . . . . . . . . 17
   4.4 The Set Operation  . . . . . . . . . . . . . . . . . . . . . . 18
   4.5 The Reply Operation  . . . . . . . . . . . . . . . . . . . . . 20
   5.  Registration: The Access Service . . . . . . . . . . . . . . . 20
   6.  The Access Service DTD . . . . . . . . . . . . . . . . . . . . 21



Rose, et. al.               Standards Track                     [Page 1]

RFC 3341     The Application Exchange (APEX) Access Service    July 2002


   7.  Security Considerations  . . . . . . . . . . . . . . . . . . . 23
       References . . . . . . . . . . . . . . . . . . . . . . . . . . 23
       Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 24
   A.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 25
       Full Copyright Statement . . . . . . . . . . . . . . . . . . . 26

1. Introduction

   This memo describes an access service that is built upon the APEX [1]
   "relaying mesh".  The APEX access service is used to control use of
   both the relaying mesh and other APEX services.

   APEX, at its core, provides a best-effort datagram service.  Within
   an administrative domain, all relays must be able to handle messages
   for any endpoint within that domain.  APEX services are logically
   defined as endpoints but given their ubiquitous semantics they do not
   necessarily need to be associated with a single physical endpoint.
   As such, they may be provisioned co-resident with each relay within
   an administrative domain, even though they are logically provided on
   top of the relaying mesh, i.e.,

      +----------+     +----------+    +----------+    +---------+
      |   APEX   |     |   APEX   |    |   APEX   |    |         |
      |  access  |     | presence |    |  report  |    |   ...   |
      | service  |     |  service |    | service  |    |         |
      +----------+     +----------+    +----------+    +---------+
           |                |               |               |
           |                |               |               |
   +----------------------------------------------------------------+
   |                                                                |
   |                            APEX core                           |
   |                                                                |
   +----------------------------------------------------------------+

   That is, applications communicate with an APEX service by exchanging
   data with a "well-known endpoint" (WKE).

   APEX applications communicate with the access service by exchanging
   data with the well-known endpoint "apex=access" in the corresponding
   administrative domain, e.g., "apex=access@example.com" is the
   endpoint associated with the access service in the "example.com"
   administrative domain.

   Note that within a single administrative domain, the relaying mesh
   makes use of the APEX access service in order to determine if an
   originator is allowed to transmit data to a recipient (c.f., Step 5.3
   of Section 4.4.4.1 of [1]).




Rose, et. al.               Standards Track                     [Page 2]

RFC 3341     The Application Exchange (APEX) Access Service    July 2002


2. Use and Management of Access Information

   Access information is organized around access entries, each of which
   contains:

   o  an owner: an APEX address with which the entry is associated;

   o  an actor: an APEX address that is granted permission to perform
         some action in the context of the owner;

   o  a list of actions; and,

   o  a timestamp indicating when the service last created or modified
         the access entry.

   The access entry for a given owner controls access to a potentially
   large range of different APEX services, such as data delivery, access
   control, and presence information.  In addition, Section 4.5 of [1]
   discusses APEX access policies that govern such activities as peer
   authentication, message relaying, and so on.

   Management of access information falls into three categories:

   o  applications may query the access service to see if one or more
      actions are allowed;

   o  applications may retrieve access information associated with an
      owner/actor combination; and,

   o  applications may modify (i.e., create, replace, or delete) access
      information associated with an owner/actor combination.

   Each is now described in turn.

2.1 Querying Access Information

   When an application wants to determine whether one or more actions
   are allowed for an owner/actor combination, it sends a "query"
   element to the service, e.g.,

       +-------+                  +-------+
       |       | -- data -------> |       |
       | appl. |                  | relay |
       |       | <--------- ok -- |       |
       +-------+                  +-------+






Rose, et. al.               Standards Track                     [Page 3]

RFC 3341     The Application Exchange (APEX) Access Service    July 2002


     C: <data content='#Content'>
            <originator identity='fred@example.com' />
            <recipient identity='apex=access@example.com' />
            <data-content Name='Content'>
                <query owner='fred@example.com' transID='1'
                       actor='barney@example.com'
                       actions='core:data presence:subscribe' />
            </data-content>
        </data>
     S: <ok />

   The service immediately responds with either an allow or deny
   operation containing the same transaction-identifier, where "allow"
   means that all of the actions listed in the query are permitted,
   e.g.,

                                    +-------+                  +-------+
                                    |       | <------- data -- |       |
                                    | relay |                  |access |
                                    |       | -- ok ---------> |  svc. |
                                    +-------+                  +-------+

       C: <data content='#Content'>
              <originator identity='apex=access@example.com' />
              <recipient identity='fred@example.com' />
              <data-content Name='Content'>
                  <allow transID='1' />
              </data-content>
          </data>
       S: <ok />

   or

       C: <data content='#Content'>
              <originator identity='apex=access@example.com' />
              <recipient  identity='fred@example.com' />
              <data-content Name='Content'>
                  <deny transID='1' />
              </data-content>
          </data>
       S: <ok />

2.2 Retrieval of Access Information

   When an application wants to retrieve the access entry associated
   with an owner/actor combination (typically in preparation for
   updating that access information), it sends a "get" element to the
   service, e.g.,



Rose, et. al.               Standards Track                     [Page 4]

RFC 3341     The Application Exchange (APEX) Access Service    July 2002


       +-------+                  +-------+
       |       | -- data -------> |       |
       | appl. |                  | relay |
       |       | <--------- ok -- |       |
       +-------+                  +-------+

     C: <data content='#Content'>
            <originator identity='fred@example.com' />
            <recipient identity='apex=access@example.com' />
            <data-content Name='Content'>
                <get transID='2'
                     owner='fred@example.com'
                     actor='*@example.com' />
            </data-content>
        </data>
     S: <ok />

   The service immediately responds with a set operation containing the
   access entry and the same transaction-identifier, e.g.,

                                  +-------+                  +-------+
                                  |       | <------- data -- |       |
                                  | relay |                  |access |
                                  |       | -- ok ---------> |  svc. |
                                  +-------+                  +-------+

     C: <data content='#Content'>
            <originator identity='apex=access@example.com' />
            <recipient identity='fred@example.com' />
            <data-content Name='Content'>
                <set transID='2'>
                    <access owner='fred@example.com'
                            actor='*@example.com'
                            actions='core:data presence:subscribe'
                            lastUpdate='2000-05-14T13:02:00-08:00' />
                </set>
            </data-content>
        </data>
     S: <ok />

2.3 Update of Access Information

   When an application wants to create or modify an access entry
   associated with an owner/actor combination, it sends a "set" element
   to the service containing the new access entry, e.g.,






Rose, et. al.               Standards Track                     [Page 5]

RFC 3341     The Application Exchange (APEX) Access Service    July 2002


       +-------+                  +-------+
       |       | -- data -------> |       |
       | appl. |                  | relay |
       |       | <--------- ok -- |       |
       +-------+                  +-------+

     C: <data content='#Content'>
            <originator identity='wilma@example.com' />
            <recipient identity='apex=access@example.com' />
            <data-content Name='Content'>
                <set transID='1'>
                    <access owner='fred@example.com'
                            actor='*@example.com'
                            actions='core:data presence:subscribe'
                            lastUpdate='2000-05-14T13:02:00-08:00' />
                </set>
            </data-content>
        </data>
     S: <ok />

   Note that Step 4 of Section 4.4 requires that the "lastUpdate"
   attribute of an access entry be supplied in order to update that
   entry; accordingly, applications must successfully retrieve an access
   entry prior to trying to modify that entry.  (Naturally,
   administrators should ensure that applications authorized to modify
   an access entry are also authorized to retrieve that entry.)

   The service immediately responds with a reply operation containing
   the same transaction-identifier, e.g.,

                                  +-------+                  +-------+
                                  |       | <------- data -- |       |
                                  | relay |                  |access |
                                  |       | -- ok ---------> |  svc. |
                                  +-------+                  +-------+

     C: <data content='#Content'>
            <originator identity='apex=access@example.com' />
            <recipient identity='wilma@example.com' />
            <data-content Name='Content'>
                <reply code='250' transID='1' />
            </data-content>
        </data>
     S: <ok />

   Note that Steps 6.2 and 9.2 of Section 4.4 require that the access
   service update the "lastUpdate" attribute of an access entry when it
   is created or modified.



Rose, et. al.               Standards Track                     [Page 6]

RFC 3341     The Application Exchange (APEX) Access Service    July 2002


   The service also immediately sends a set operation to the owner
   attribute associated with the access entry, e.g.,

                                  +-------+                  +-------+
                                  |       | <------- data -- |       |
                                  | relay |                  |access |
                                  |       | -- ok ---------> |  svc. |
                                  +-------+                  +-------+

     C: <data content='#Content'>
            <originator identity='apex=access@example.com' />
            <recipient identity='fred@example.com' />
            <data-content Name='Content'>
                <set transID='1'>
                    <access owner='fred@example.com'
                            actor='*@example.com'
                            actions='core:data presence:subscribe'
                            lastUpdate='2000-05-14T23:02:00-08:00' />
                </set>
            </data-content>
        </data>
     S: <ok />

   When an application wants to delete the access entry associated with
   an owner/actor combination, it sends a "set" element to the service
   omitting the permitted actions, e.g.,

       +-------+                  +-------+
       |       | -- data -------> |       |
       | appl. |                  | relay |
       |       | <--------- ok -- |       |
       +-------+                  +-------+

     C: <data content='#Content'>
            <originator identity='wilma@example.com' />
            <recipient identity='apex=access@example.com' />
            <data-content Name='Content'>
                <set transID='2'>
                    <access owner='fred@example.com'
                            actor='*@example.com'
                            lastUpdate='2000-05-14T13:02:00-08:00' />
                </set>
            </data-content>
        </data>
     S: <ok />






Rose, et. al.               Standards Track                     [Page 7]

RFC 3341     The Application Exchange (APEX) Access Service    July 2002


   The service immediately responds with a reply operation containing
   the same transaction-identifier, e.g.,

                                  +-------+                  +-------+
                                  |       | <------- data -- |       |
                                  | relay |                  |access |
                                  |       | -- ok ---------> |  svc. |
                                  +-------+                  +-------+

     C: <data content='#Content'>
            <originator identity='apex=access@example.com' />
            <recipient identity='wilma@example.com' />
            <data-content Name='Content'>
                <reply code='250' transID='2' />
            </data-content>
        </data>
     S: <ok />

   The service also immediately sends a set operation to the owner
   attribute associated with the access entry, e.g.,

                                  +-------+                  +-------+
                                  |       | <------- data -- |       |
                                  | relay |                  |access |
                                  |       | -- ok ---------> |  svc. |
                                  +-------+                  +-------+

     C: <data content='#Content'>
            <originator identity='apex=access@example.com' />
            <recipient identity='fred@example.com' />
            <data-content Name='Content'>
                <set transID='2'>
                    <access owner='fred@example.com'
                            actor='*@example.com'
                            lastUpdate='2000-05-14T13:02:00-08:00' />
                </set>
            </data-content>
        </data>
     S: <ok />

   Because there are no actions associated with this access entry, the
   owner knows that the entry has been deleted.

   Note that because access control supported limited wildcarding of
   actors, deleting an access entry for a particular owner/actor
   combination, may modify, rather than remove, permission.  Because of
   this, a special action, "all:none", is used.




Rose, et. al.               Standards Track                     [Page 8]

RFC 3341     The Application Exchange (APEX) Access Service    July 2002


   For example, consider these two access entries:

       <access owner='fred@example.com'
               actor='barney@example.com'
               actions='core:data presence:subscribe presence:watch'
               lastUpdate='2000-05-14T13:20:00-08:00' />

       <access owner='fred@example.com'
               actor='*@example.com'
               actions='core:data'
               lastUpdate='2000-05-14T13:20:00-08:00' />

   Deleting the first access entry will not remove all permissions for
   for the actor "barney@example.com".

   Instead, the first access entry should be modified thusly:

       <access owner='fred@example.com'
               actor='barney@example.com'
               actions='all:none'
               lastUpdate='2000-05-14T13:20:00-08:00' />

3. Format of Access Entries

   Each administrative domain is responsible for maintaining one or more
   "access entries" for each of its endpoints and associated
   subaddresses (regardless of whether those addresses are currently
   attached to the relaying mesh).

   A separate access entry is required for each actor or group of actors
   for whom access permission is specified.  Section 6 defines the
   syntax for access entries.  Each access entry has an "owner"
   attribute, an "actor" attribute, an "actions" attribute, a
   "lastUpdate" attribute, and no content:

   o  the "owner" attribute specifies the address (endpoint or
      subaddress) associated with the access entry;

   o  the "actor" attribute specifies an entity or group of entities for
      whom access permissions are specified, as described below;

   o  the "actions" attribute specifies the permissions granted to the
      actor in the context of the owner; and,

   o  the "lastUpdate" attribute specifies the date and time that the
      service last created or modified the access entry.





Rose, et. al.               Standards Track                     [Page 9]

RFC 3341     The Application Exchange (APEX) Access Service    July 2002


   An action is specified as a service/operation pair, e.g., the action
   "presence:publish" refers to the "publish" operation of the
   "presence" service.  Two service values are reserved:

   o  "all" is used to refer to all services, e.g., "all:data"; and,

   o  "core" is used to refer to the service implemented by the relaying
      mesh, e.g., the "core:data" permission is consulted by the
      relaying mesh (c.f., Step 5.3 of Section 4.4.4.1 of [1]).

   Further, two operation values are reserved:

   o  "all" is used to refer to all operations, e.g., "presence:all";
      and,

   o  "none" is used to refer to no operations whatsoever, e.g.,
      "all:none".

      An actor is an APEX address and is specified using the "entity"
      syntax specified in Section 2.2 of [1].  However, both the "local"
      and "domain" parts may contain limited wildcarding:

      o  The "local" part is either:

      *  a literal string (e.g., "fred");

      *  a subaddress wildcard (e.g., "fred/*" or "apex=pubsub/*"); or,

      *  the value "apex=*", specifying all APEX services;

      *  the value "*", specifying any address other than an APEX
         service.

   o  The "domain" part is either:

      *  a FQDN (e.g., "example.com");

      *  a domain wildcard (e.g., "*.example.com"); or,

      *  the value "*", specifying all administrative domains.

      Note that in the case of a domain wildcard, the wildcard itself
      matches zero or more subdomains, e.g., "*.example.com" matches
      "example.com", "foo.example.com", "bar.foo.example.com", and so
      on.)






Rose, et. al.               Standards Track                    [Page 10]

RFC 3341     The Application Exchange (APEX) Access Service    July 2002


   The following default entries are provided for each owner, but are
   overridden by an explicitly supplied entry with the same actor value:

      actor='local@domain'  actions='all:all'
      actor='apex=*@domain' actions='all:all'
      actor='apex=*@*'      actions='core:data'
      actor='*@*'           actions='all:none'

   where "local@domain" specifies the owner associated with the access
   entry.

   For example, the explicit entry

      actor='*@*'           actions='core:data'

   allows endpoints from any domain to use the relaying mesh to send
   data to the owner, but does not override the default entry for
   "apex=*@domain", which allows all APEX services in the owner's domain
   access to all actions.

   APEX endpoint names can legitimately contain the character '*', but
   access entries use '*' to indicate wildcarding.  Accordingly, the
   two-character sequence '\*' is used to avoid ambiguity in the "actor"
   attribute.  Similarly, to explicitly specify an endpoint name
   containing '\' in the "actor" attribute, the two-character sequence
   '\\' is used.

   Note that this convention is used only for the "actor" attribute of
   the "get" operation and of the "access" entry that appears in the
   "set" operation; however, this convention is not used in the "query"
   operation, as this operation does not allow wildcarding.

   For example, to specify the endpoint named as "a\b*c@example.com" in
   the "get" operation or in an "access" entry, the string
   "a\\b\*c@example.com" is used; but in the "query" operation, the
   string "a\b*c@example.com" is used.  (Of course, as name allocation
   is a local matter, these complications can be avoided by the simple
   expedient of not using endpoint names containing '*' or '\'.)

3.1 Finding the Appropriate Entry: Matching Owners and Actors

   The use of actor wildcarding makes it possible for several access
   entries to apply for a given owner/actor combination.  When
   determining which access entry to use when responding to the query
   operation, the algorithm is:

   o  Consider only those access entries that are associated with the
      given owner.



Rose, et. al.               Standards Track                    [Page 11]

RFC 3341     The Application Exchange (APEX) Access Service    July 2002


   o  Consider only those access entries in which the actor value
      matches the actor address in the query.  If the wildcard character
      ('*') is present, then it a match is possible only if each
      wildcard character can be replaced with a non-empty character
      sequence (one or more characters) to obtain a value identical to
      the address in the query.

   o  Order those remaining access entries:

      *  Use the exactness of the match with the domain part of the
         actor value as the primary key; and,

      *  Use the exactness of the match with the local part of the actor
         value as the secondary key.

   o  When matching with the domain part, an exact match is the best
      match; otherwise, the shorter the wildcard match, the higher the
      priority.

      For example, if the actor's domain is "bar.foo.example.com", a
      match against an entry of "*.foo.example.com" is better than a
      match against an entry of "*.example.com".

   o  When matching with the local part, an exact match is the best
      match; otherwise, the shorter the wildcard match, the higher the
      priority.  This is true regardless of whether the wildcarding is
      for subaddress or service.  (Note that a local part with a
      wildcard subaddress does not have a non-empty match with the same
      local part without a subaddress.)

   For example, consider these access entries:

      <access owner='fred@example.com'
              actor='wilma@example.com'
              actions='all:all'
              lastUpdate='2000-05-14T13:20:00-08:00' />
      <access owner='fred@example.com'
              actor='mr.slate@example.com'
              actions='core:data'
              lastUpdate='2000-05-14T13:20:00-08:00' />
      <access owner='fred/appl=wb@example.com'
              actor='barney/appl=wb@example.com'
              actions='core:data'
              lastUpdate='2000-05-14T13:20:00-08:00' />
      <access owner='fred@example.com'
              actor='*@example.com'
              actions='core:data presence:subscribe presence:watch'
              lastUpdate='2000-05-14T13:20:00-08:00' />



Rose, et. al.               Standards Track                    [Page 12]

RFC 3341     The Application Exchange (APEX) Access Service    July 2002


      <access owner='fred@example.com'
              actor='*@*'
              actions='core:data'
              lastUpdate='2000-05-14T13:20:00-08:00' />

   Briefly:

   o  For addresses within the "example.com" administrative domain:

   *  "fred", "wilma", and all APEX services within the "example.com"
      administrative domain are allowed access to all operations for
      "fred@example.com";

   *  "mr.slate" is allowed access only to send data through the
      relaying mesh to "fred@example.com";

   *  "barney/appl=wb" is allowed access only to send data to "fred/
      appl=wb", a subaddress of "fred@example.com"; and,

   *  any other address within the "example.com" administrative
      domain is allowed access to send data and invoke the
      "subscribe" and "watch" operations of the APEX presence service
      with respect to "fred@example.com".

   o  For any address outside the "example.com" administrative domain,
      the address is allowed access to send data, regardless of whether
      it is an APEX service.
























Rose, et. al.               Standards Track                    [Page 13]

RFC 3341     The Application Exchange (APEX) Access Service    July 2002


   Note that although the four default entries are always available, the
   explicit entry for actor "*@*" overrides the corresponding default
   entry.

3.2 Creating and Updating Access Entries

   The get and set operations are provided as a basic mechanism for
   creating and updating access rules, for which no special wildcard
   processing is performed.

   The actor value for an access entry may contain limited wildcard
   characters which have special significance only when performing a
   query operation (cf., Section 3.1).  For the purposes of retrieving
   and updating entries, actor values are treated simply as literal
   names.

4. The Access Service

   Section 5 contains the APEX service registration for the access
   service:

   o  Within an administrative domain, the service is addressed using
      the well-known endpoint of "apex=access".

   o  Section 6 defines the syntax of the operations exchanged with the
      service.

   o  A consumer of the service initiates communications by sending data
      containing a query, get, or set operation.

   o  The service replies to these operations.

   o  When an access entry is changed, the service sends a notification
      to the owner associated with the changed entry.

   An implementation of the service must maintain information about
   access entries in persistent storage.

   Consult Section 6.1.1 of [1] for a discussion on the properties of
   long-lived transaction-identifiers.











Rose, et. al.               Standards Track                    [Page 14]

RFC 3341     The Application Exchange (APEX) Access Service    July 2002


4.1 Use of XML and MIME

   Section 4.1 of [1] describes how arbitrary MIME content is exchanged
   as a BEEP [2] payload.  For example, to transmit:

       <data content='...'>
           <originator identity='fred@example.com' />
           <recipient identity='apex=access@example.com' />
       </data>

    where "..." refers to:

       <query owner='fred@example.com' transID='1'
              actor='barney@example.com'
              actions='core:data presence:subscribe' />

    then the corresponding BEEP message might look like this:

       C: MSG 1 2 . 42 1234
       C: Content-Type: multipart/related; boundary="boundary";
       C:               start="<1@example.com>";
       C:               type="application/beep+xml"
       C:
       C: --boundary
       C: Content-Type: application/beep+xml
       C: Content-ID: <1@example.com>
       C:
       C: <data content='cid:2@example.com'>
       C:     <originator identity='fred@example.com' />
       C:     <recipient identity='apex=access@example.com' />
       C: </data>
       C: --boundary
       C: Content-Type: application/beep+xml
       C: Content-ID: <2@example.com>
       C:
       C: <query owner='fred@example.com' transID='1'
       C:        actor='barney@example.com'
       C:        actions='core:data presence:subscribe' />
       C: --boundary--
       C: END











Rose, et. al.               Standards Track                    [Page 15]

RFC 3341     The Application Exchange (APEX) Access Service    July 2002


    or this:

       C: MSG 1 1 . 42 267
       C: Content-Type: application/beep+xml
       C:
       C: <data content='#Content'>
       C:     <originator identity='fred@example.com' />
       C:     <recipient identity='apex=access@example.com' />
       C:     <data-content Name='Content'>
       C:         <query owner='fred@example.com' transID='1'
       C:                actor='barney@example.com'
       C:                actions='core:data presence:subscribe' />
       C:     </data-content>
       C: </data>
       C: END

4.2 The Query Operation

   When an application wants to see if a particular operation is
   allowed, it sends a "query" element to the service.

   The "query" element has an "owner" attribute, an "actor" attribute,
   an "actions" attribute, a "transID" attribute, and no content:

   o  the "owner" attribute specifies the address associated with the
      access entry;

   o  the "actor" attribute specifies the address (without wildcarding)
      for which access permissions are queried;

   o  the "actions" attribute specifies one or more actions for which
      permission is queried; and,

   o  the "transID" attribute specifies the transaction-identifier
      associated with this operation.

   When the service receives a "query" element, we refer to the "owner"
   attribute as the "subject".  The service performs these steps:

   1. If the subject is outside this administrative domain, a "reply"
      element having code 553 is sent to the originator.

   2. If the subject does not refer to a valid address, a "reply"
      element having code 550 is sent to the originator.

   3. If the subject's access entry matching the originator does not
      contain an "access:query" token, a "reply" element having code 537
      is sent to the originator.



Rose, et. al.               Standards Track                    [Page 16]

RFC 3341     The Application Exchange (APEX) Access Service    July 2002


   4. The subject's access entry matching the actor attribute of the
      query element is selected (cf., Section 3.1).

   5. If all of the permissions in the "actions" attribute of the query
      element are contained in the selected access entry, then an
      "allow" element is sent to the originator.

   6. Otherwise, a "deny" element is sent to the originator.

   Regardless of whether an "allow", "deny", or "reply" element is sent
   to the originator, the "transID" attribute is identical to the value
   found in the "query" element sent by the originator.

4.3 The Get Operation

   Prior to creating or updating an access entry for some owner/actor
   combination, an application will usually need to retrieve any
   existing access entry.  It does so by sending a "get" element to the
   service.  In particular, a successful response returns a "lastUpdate"
   value that is necessary when sending a subsequent "set" element.

   The "get" element has an "owner" attribute, an "actor" attribute, a
   "transID" attribute, and no content:

   o  the "owner" attribute specifies the address associated with the
      access entry;

   o  the "actor" attribute specifies the address (with possible
      wildcarding) for which access permissions are retrieved; and,

   o  the "transID" attribute specifies the transaction-identifier
      associated with this operation.

   When the service receives a "get" element, we refer to the "owner"
   attribute as the "subject".  The service performs these steps:

   1. If the subject is outside this administrative domain, a "reply"
      element having code 553 is sent to the originator.

   2. If the subject does not refer to a valid address, a "reply"
      element having code 550 is sent to the originator.

   3. If the subject's access entry matching the originator does not
      contain an "access:get" token, a "reply" element having code 537
      is sent to the originator.

   4. The subject's access entry whose "actor" attribute identically
      matches the "actor" attribute of the "get" element is selected.



Rose, et. al.               Standards Track                    [Page 17]

RFC 3341     The Application Exchange (APEX) Access Service    July 2002


   5. If no such entry exists, a "reply" element having code 551 is sent
      to the originator.

   6. Otherwise, a "set" element corresponding to the selected access
      entry is sent to the originator.

   Regardless of whether a "set" or "reply" element is sent to the
   originator, the "transID" attribute is identical to the value found
   in the "get" element sent by the originator.

4.4 The Set Operation

   When an application wants to modify (i.e., create, replace, or
   delete) the access entry associated with an owner/actor combination,
   it sends a "set" element to the service.

   The "set" element has a "transID" attribute, and contains an "access"
   element:

   o  the "transID" attribute specifies the transaction-identifier
      associated with this operation; and,

   o  the "access" element contains the access entry to be created,
      replaced, or deleted.

   The "access" element has an "owner" attribute, an "actor" attribute,
   an optional "actions" attribute, an optional "lastUpdate" attribute,
   and no content:

   o  the "owner" attribute specifies the address associated with the
      access entry;

   o  the "actor" attribute specifies the address (with possible
      wildcarding) for which access permissions are specified;

   o  the "actions" attribute (present only to add or replace an entry)
      specifies one or more actions for which permission is to be
      determined; and,

   o  the "lastUpdate" attribute (present only to replace or delete an
      entry) specifies the current timestamp of the access entry that is
      to be replaced.









Rose, et. al.               Standards Track                    [Page 18]

RFC 3341     The Application Exchange (APEX) Access Service    July 2002


   When the service receives a "set" element, we refer to the "owner"
   attribute of the access element as the "subject".  The service
   performs these steps:

   1. If the subject is outside this administrative domain, a "reply"
      element having code 553 is sent to the originator.

   2. If the subject does not refer to a valid address, a "reply"
      element having code 550 is sent to the originator.

   3. If the subject's access entry matching the originator does not
      contain an "access:set" token, a "reply" element having code 537
      is sent to the originator.

   4. The subject's access entry whose "actor" attribute identically
      matches the "actor" attribute of the "set" element is selected.

   5. If no such entry exists and the "lastUpdate" attribute is present
      in the supplied "set" element, a "reply" element having code 555
      is sent to the originator.

   6. If no such entry exists and the "lastUpdate" attribute is absent
      in the supplied "set" element, then:

      1. The access entry for the owner/actor combination is created
         from the supplied "access" element.

      2. The "lastUpdate" attribute of that access entry set to the
         service's notion of the current date and time.

      3. A "reply" element having code 250 is sent to the originator.

      4. A "set" element corresponding to the newly-created access entry
         is sent to the subject's address.

   7. If the selected entry exists, but its "lastUpdate" attribute is
      not semantically identical to the "lastUpdate" attribute of the
      supplied "access" element, a "reply" element having code 555 is
      sent to the originator.

   8. If "actions" attribute of the supplied "access" element is not
      present, then:

      1. The selected entry is deleted.

      2. A "reply" element having code 250 is sent to the originator.





Rose, et. al.               Standards Track                    [Page 19]

RFC 3341     The Application Exchange (APEX) Access Service    July 2002


      3. A "set" element corresponding to the owner/actor combination,
         but lacking an "actions" attribute is sent to the subject's
         address.

   9. Otherwise:

      1. The access entry for the owner/actor combination is updated
         from the supplied "access" element.

      2. The "lastUpdate" attribute of the updated access entry is set
         to the service's notion of the current date and time (which
         should be different from the "lastUpdate" value associated with
         any replaced entry).

      3. A "reply" element having code 250 is sent to the originator.

      4. A "set" element corresponding to the newly-updated access entry
         is sent to the subject's address.

   When sending the "reply" element, the "transID" attribute is
   identical to the value found in the "set" element sent by the
   originator.

4.5 The Reply Operation

   While processing operations, the service may respond with a "reply"
   element.  Consult Sections 10.2 and 6.1.2 of [1], respectively, for
   the definition and an exposition of the syntax of the reply element.

5. Registration: The Access Service

   Well-Known Endpoint: apex=access

   Syntax of Messages Exchanged: c.f., Section 6

   Sequence of Messages Exchanged: c.f., Section 4

   Access Control Tokens: access:query, access:get, access:set

   Contact Information: c.f., the "Authors' Addresses" section of this
      memo










Rose, et. al.               Standards Track                    [Page 20]

RFC 3341     The Application Exchange (APEX) Access Service    July 2002


6. The Access Service DTD

   <!--
     DTD for the APEX access service, as of 2001-06-19

     Refer to this DTD as:

       <!ENTITY % APEXACCESS PUBLIC "-//IETF//DTD APEX ACCESS//EN" "">
       %APEXACCESS;
     -->

   <!ENTITY % APEXCORE PUBLIC "-//IETF//DTD APEX CORE//EN" "">
   %APEXCORE;

   <!--
     DTD data types:

          entity        syntax/reference     example
          ======        ================     =======
       access actor
          ACTOR         an ENDPOINT or a     *@example.com
                        wildcard

       permitted actions
          ACTIONS       a list of access     "core:any access:query"
                        tokens
     -->

   <!ENTITY  % ACTOR   "CDATA">
   <!ENTITY  % ACTIONS "NMTOKENS">

   <!--
     Synopsis of the APEX access service

       service WKE: apex=access

       message exchanges:

           consumer initiates    service replies
           ==================    ================
           query                 allow, deny, or reply
           get                   set or reply
           set                   reply

           service initiates     consumer replies
           =================     ================
           set                   (nothing)




Rose, et. al.               Standards Track                    [Page 21]

RFC 3341     The Application Exchange (APEX) Access Service    July 2002


       access control:

           token                 target
           ==========            ======
           access:query          for "owner" of "access" element
           access:get            for "owner" of "access" element
           access:set            for "owner" of "access" element
     -->

   <!ELEMENT query       EMPTY>
   <!ATTLIST query
             owner       %ENDPOINT;        #REQUIRED
             actor       %ACTOR;           #REQUIRED
             actions     %ACTIONS;         #REQUIRED
             transID     %UNIQID;          #REQUIRED>

   <!ELEMENT get         EMPTY>
   <!ATTLIST get
             owner       %ENDPOINT;        #REQUIRED
             actor       %ACTOR;           #REQUIRED
             transID     %UNIQID;          #REQUIRED>

   <!ELEMENT set         (access)>
   <!ATTLIST set
             transID     %UNIQID;          #REQUIRED>

   <!ELEMENT allow       EMPTY>
   <!ATTLIST allow
             transID     %UNIQID;          #REQUIRED>

   <!ELEMENT deny        EMPTY>
   <!ATTLIST deny
             transID     %UNIQID;          #REQUIRED>

   <!--
     access entries
     -->

   <!ELEMENT access      EMPTY>
   <!ATTLIST access
             owner       %ENDPOINT;        #REQUIRED
             actor       %ACTOR;           #REQUIRED
             actions     %ACTIONS;         #IMPLIED
             lastUpdate  %TIMESTAMP;       #IMPLIED>







Rose, et. al.               Standards Track                    [Page 22]

RFC 3341     The Application Exchange (APEX) Access Service    July 2002


7. Security Considerations

   Consult [1]'s Section 11 for a discussion of security issues.

   In addition, timestamps issued by the the access service may disclose
   location information.  If this information is considered sensitive,
   the special timezone value "-00:00" may be used (after converting the
   local time accordingly).

References

   [1]   Rose, M., Klyne, G. and D. Crocker, "The Application Exchange
         Core", RFC 3340, July 2002.

   [2]   Rose, M., "The Blocks Extensible Exchange Protocol Core", RFC
         3080, March 2001.



































Rose, et. al.               Standards Track                    [Page 23]

RFC 3341     The Application Exchange (APEX) Access Service    July 2002


Authors' Addresses

   Marshall T. Rose
   Dover Beach Consulting, Inc.
   POB 255268
   Sacramento, CA  95865-5268
   US

   Phone: +1 916 483 8878
   EMail: mrose@dbc.mtview.ca.us


   Graham Klyne
   Clearswift Corporation
   1310 Waterside
   Arlington Business Park
   Theale, Reading  RG7 4SA
   UK

   Phone: +44 11 8903 8903
   EMail: Graham.Klyne@MIMEsweeper.com


   David H. Crocker
   Brandenburg Consulting
   675 Spruce Drive
   Sunnyvale, CA  94086
   US

   Phone: +1 408 246 8253
   EMail: dcrocker@brandenburg.com
   URI:   http://www.brandenburg.com/



















Rose, et. al.               Standards Track                    [Page 24]

RFC 3341     The Application Exchange (APEX) Access Service    July 2002


Appendix A. Acknowledgements

   The authors gratefully acknowledge the contributions of: Neil Cook,
   Darren New, Chris Newman, Scott Pead, and Bob Wyman.















































Rose, et. al.               Standards Track                    [Page 25]

RFC 3341     The Application Exchange (APEX) Access Service    July 2002


Full Copyright Statement

   Copyright (C) The Internet Society (2002).  All Rights Reserved.

   This document and translations of it may be copied and furnished to
   others, and derivative works that comment on or otherwise explain it
   or assist in its implementation may be prepared, copied, published
   and distributed, in whole or in part, without restriction of any
   kind, provided that the above copyright notice and this paragraph are
   included on all such copies and derivative works.  However, this
   document itself may not be modified in any way, such as by removing
   the copyright notice or references to the Internet Society or other
   Internet organizations, except as needed for the purpose of
   developing Internet standards in which case the procedures for
   copyrights defined in the Internet Standards process must be
   followed, or as required to translate it into languages other than
   English.

   The limited permissions granted above are perpetual and will not be
   revoked by the Internet Society or its successors or assigns.

   This document and the information contained herein is provided on an
   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Acknowledgement

   Funding for the RFC Editor function is currently provided by the
   Internet Society.



















Rose, et. al.               Standards Track                    [Page 26]