-
Notifications
You must be signed in to change notification settings - Fork 0
/
xep-0079.xml
1303 lines (1280 loc) · 67.1 KB
/
xep-0079.xml
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
<?xml version='1.0' encoding='UTF-8'?>
<!DOCTYPE xep SYSTEM 'xep.dtd' [
<!ENTITY % ents SYSTEM 'xep.ent'>
%ents;
]>
<?xml-stylesheet type='text/xsl' href='xep.xsl'?>
<xep>
<header>
<title>Advanced Message Processing</title>
<abstract>This specification defines an XMPP protocol extension that enables entities to request, and servers to perform, advanced processing of XMPP message stanzas, including reliable data transport, time-sensitive delivery, and expiration of transient messages.</abstract>
&LEGALNOTICE;
<number>0079</number>
<status>Draft</status>
<type>Standards Track</type>
<sig>Standards</sig>
<dependencies>
<spec>XMPP Core</spec>
<spec>XEP-0030</spec>
<spec>XEP-0082</spec>
</dependencies>
<supersedes>
<spec>XEP-0023</spec>
</supersedes>
<supersededby/>
<shortname>amp</shortname>
<schemaloc>
<ns>amp</ns>
<url>http://www.xmpp.org/schemas/amp.xsd</url>
</schemaloc>
<schemaloc>
<ns>amp#errors</ns>
<url>http://www.xmpp.org/schemas/amp-errors.xsd</url>
</schemaloc>
<schemaloc>
<ns>feature</ns>
<url>http://www.xmpp.org/schemas/amp-feature.xsd</url>
</schemaloc>
<registry/>
&linuxwolf;
&stpeter;
<revision>
<version>1.2</version>
<date>2005-11-30</date>
<initials>psa</initials>
<remark>Consolidated and generalized security considerations.</remark>
</revision>
<revision>
<version>1.1</version>
<date>2005-10-19</date>
<initials>psa</initials>
<remark>Reversed the meaning of conditions other than expire-at (per list discussion); correctly specified stream feature.</remark>
</revision>
<revision>
<version>1.0</version>
<date>2004-10-11</date>
<initials>psa</initials>
<remark>Per a vote of the Jabber Council, advanced to a status of Draft.</remark>
</revision>
<revision>
<version>0.12</version>
<date>2004-09-09</date>
<initials>lw</initials>
<remark>Relaxed server-to-server requirements; clarified discovery rules; removed expire-in condition.</remark>
</revision>
<revision>
<version>0.11</version>
<date>2004-08-25</date>
<initials>lw/psa</initials>
<remark>Specified that the timestamp for an expire-at condition must be a UTC DateTime per XEP-0082; provided further explanation regarding expire-at and expire-in conditions.</remark>
</revision>
<revision>
<version>0.10</version>
<date>2004-07-14</date>
<initials>lw/psa</initials>
<remark>Changes to address Council feedback: clarified error handling and provided error examples; specified that server should validate all rule semantics before returning an error; specified that service discovery information can be cached (not necessary to send disco query before dispatching each message); added "forward" and "gateway" to values of "deliver" condition to handle redirection of messages to alternate XMPP addresses and non-XMPP systems respectively; more clearly specified processing rules for "expire-in" condition; changed milliseconds to seconds for "expire-in"; made explicit that partial JID-matching is not included for "match-resource" condition; added clarifying note to security consideration regarding "deliver" condition; corrected values of per-hop from [yes|no] to [true|false]; changed "standard" conditions to "defined" conditions and mandated that they should be supported; changed "http://jabber.org/protocol/amp#std-actions" namespace to "http://jabber.org/protocol/amp#errors".</remark>
</revision>
<revision>
<version>0.9</version>
<date>2004-04-25</date>
<initials>psa</initials>
<remark>Editorial review: clarified some matters in the text; fully defined the XMPP Registrar Considerations.</remark>
</revision>
<revision>
<version>0.8</version>
<date>2004-01-20</date>
<initials>lw</initials>
<remark>Reorganized for Editorial preferences; revised error conditions to properly align with XMPP-Core</remark>
</revision>
<revision>
<version>0.7</version>
<date>2003-12-10</date>
<initials>lw</initials>
<remark>Incorported changes requested from Standards list discussions: Changed entity-to-server discovery behavior; s2s discovery behavior; Expanded application-specific error conditions; Reorganized for better presentation; Changed "per-hop" to apply to the entire ruleset; Fixed minor typos and missteps</remark>
</revision>
<revision>
<version>0.6</version>
<date>2003-10-15</date>
<initials>lw</initials>
<remark>Changed disco behavior; Changed schema to reflect customizations</remark>
</revision>
<revision>
<version>0.5.1</version>
<date>2003-09-20</date>
<initials>lw</initials>
<remark>Fixed many typos</remark>
</revision>
<revision>
<version>0.5</version>
<date>2003-08-28</date>
<initials>lw</initials>
<remark>Renamed to "amp" (thanks stpeter!); Added information about the original addressing; Added requirement for id attribute in &MESSAGE;; Restricted behavior within the "Security Considerations";</remark>
</revision>
<revision>
<version>0.4</version>
<date>2003-06-23</date>
<initials>lw</initials>
<remark>Completely rewritten to better account for various suggested usage details and requirements; Completely reorganized to better codify the protocol(s) and their possible uses; Added more conditions; Added more actions; Added common usage scenarios</remark>
</revision>
<revision>
<version>0.3</version>
<date>2003-04-21</date>
<initials>lw</initials>
<remark>Clarified client-side processing; Removed semantics scope; Clarified "fail" action; Moved existing "use-cases" into "Usage" section in "Overview"; Added more relevant use cases; Added XMPP-style error conditions</remark>
</revision>
<revision>
<version>0.2</version>
<date>2003-04-15</date>
<initials>psa</initials>
<remark>Added XML Schema (with author's assistance).</remark>
</revision>
<revision>
<version>0.1</version>
<date>2003-04-15</date>
<initials>lw</initials>
<remark>Initial version.</remark>
</revision>
</header>
<section1 topic='Introduction' anchor='intro'>
<p>This document defines a protocol that enables an end-point entity to specify additional delivery semantics for an XMPP <message/> stanza. This protocol is typically used by clients to inform the receiving server how to deliver a particular stanza, such as providing an expiration time or a resource-matching strategy.</p>
<section2 topic='Motivation' anchor='intro-motivation'>
<p>The built-in delivery semantics for <message/> stanzas (defined in &xmppcore; and, for instant messaging applications, also in &xmppim;) are adequate for most current applications. However, there are various cases where more stringent delivery semantics are necessary. The most common cases discussed in this document are:</p>
<ul>
<li>Reliable data transport -- the sender requires notification (positive and/or negative) of message delivery.</li>
<li>Time-sensitive messages -- the message is valid only until a certain date and time.</li>
<li>Transient messages -- the message should not be stored offline for later delivery.</li>
</ul>
</section2>
<section2 topic='Concepts' anchor='intro-concepts'>
<p>This protocol is mostly handled by the server or servers processing the <message/>. The protocol consists of a list of rules, with conditions and actions for each rule. Upon receipt of an appropriately marked message, the server interprets the rules in the order they are received, looking for met conditions. When a condition is met, the action for that rule is executed, and message processing stops.</p>
<p>Each rule is flagged for the scope it applies to, whether it be the overall route, or for each hop in the route. Additionally, while this document defines a default set of conditions and actions, the protocol is extensible enough to allow for more to be defined in the future.</p>
<p>The namespace for the protocol is "http://jabber.org/protocol/amp".</p>
</section2>
<section2 topic='Prerequisites' anchor='intro-prereq'>
<p>In order for this protocol to function properly, the containing &MESSAGE; stanza MUST possess an 'id' attribute, and the value of the 'id' attribute MUST NOT be an empty string. The server MUST include this 'id' attribute value with any response back to the sender; this enables servers and clients to properly relate the initial request with any subsequent alert, error, or notification.</p>
</section2>
</section1>
<section1 topic='Process Flows' anchor='process'>
<section2 topic='Sender-to-Server' anchor='process-s2s'>
<p>The following use case flow describes the interaction between the sender and a server. As illustrated below, this interaction is actually rather simple:</p>
<ol>
<li>Sender determines support (E1)</li>
<li>Sender specifies appropriate rules and sends message to server (E1,E2)</li>
<li>Sender awaits any protocol-specific responses (UCE)</li>
</ol>
<ul>
<li><cite>E1:</cite> The server does not support this protocol (UCE unsuccessfully)</li>
<li><cite>E2:</cite> The server does not support one or more specified rule conditions/actions (UCE unsuccessfully)</li>
</ul>
<section3 topic='Discovery' anchor='process-s2s-disco'>
<p>Sending entities that wish to use AMP SHOULD discover support for this protocol (using &xep0030;) along the intended path. Typically, this would involve sending disco#info queries to the sending entity's own server and the server of the intended recipient. The results of these queries MAY be cached for up to 24 hours, unless otherwise expired.</p>
<p>If a server supports Advanced Message Processing, it MUST report that by including a service discovery feature of "http://jabber.org/protocol/amp" in the service discovery information result that it returns to the requesting entity.</p>
<example caption="Initial Service Discovery information request"><![CDATA[
<iq from='northumberland@shakespeare.lit/westminster'
to='shakespeare.lit'
type='get'>
<query xmlns='http://jabber.org/protocol/disco#info'/>
</iq>
]]></example>
<example caption="Service Discovery information response"><![CDATA[
<iq from='shakespeare.lit'
to='northumberland@shakespeare.lit/westminster'
type='result'>
<query xmlns='http://jabber.org/protocol/disco#info'>
<identity name='Shakespeare IM' category='im' type='server'/>
...
<feature var='http://jabber.org/protocol/amp'/>
...
</query>
</iq>
]]></example>
<p>A server SHOULD also maintain a service discovery node named "http://jabber.org/protocol/amp", at which it advertises the individual actions and conditions it supports. If an entity needs to determine whether the server supports individual actions and conditions, it SHOULD send a service discovery information request to that node; the server then MUST either return the list of supported actions and conditions or return an error such as &feature;. (Note: If the server does not provide information for this disco node, the requesting entity MUST assume that all actions and conditons are supported for each reported action set or condition set.)</p>
<p>Each supported action shall be reported as a feature using the following format:</p>
<code>http://jabber.org/protocol/amp?action={action}</code>
<p>Each supported condition shall be reported as a feature using the following format:</p>
<code>http://jabber.org/protocol/amp?condition={condition}</code>
<p>The following examples show the request-response flow for information about individual actions and conditions (note the inclusion of the 'node' attribute).</p>
<example caption="Request for information about individual actions and conditions"><![CDATA[
<iq from='northumberland@shakespeare.lit/westminster'
to='shakespeare.lit'
type='get'>
<query xmlns='http://jabber.org/protocol/disco#info'
node='http://jabber.org/protocol/amp'/>
</iq>
]]></example>
<example caption="Response for individual actions and conditions"><![CDATA[
<iq from='shakespeare.lit'
to='northumberland@shakespeare.lit/westminster'
type='result'>
<query xmlns='http://jabber.org/protocol/disco#info'
node='http://jabber.org/protocol/amp'>
<identity name='Shakespeare IM AMP Support' category='im' type='server'/>
...
<feature var='http://jabber.org/protocol/amp'/>
<feature var='http://jabber.org/protocol/amp?action=drop'/>
<feature var='http://jabber.org/protocol/amp?action=error'/>
<feature var='http://jabber.org/protocol/amp?action=notify'/>
<feature var='http://jabber.org/protocol/amp?condition=deliver'/>
<feature var='http://jabber.org/protocol/amp?condition=expire-at'/>
<feature var='http://jabber.org/protocol/amp?condition=match-resource'/>
...
</query>
</iq>
]]></example>
</section3>
<section3 topic='Specifying Semantics' anchor='process-s2s-semantics'>
<p>Once support is determined, the sender can attach the desired delivery semantics to the message:</p>
<example caption='A message with AMP semantics'><![CDATA[
<message
from='northumberland@shakespeare.lit'
id='richard2-4.1.247'
to='kingrichard@royalty.england.lit'>
<body>My lord, dispatch; read o'er these articles.</body>
<amp xmlns='http://jabber.org/protocol/amp'>
<rule condition='expire-at'
action='drop'
value='2004-01-01T00:00:00Z'/>
</amp>
</message>
]]></example>
<p>The semantics are defined as a set of <rule/> elements within the <amp/> root element. Each <rule/> declares the condition to trigger on and the action to execute if triggered.</p>
<p>By default, the ruleset applies only to the "edge servers": those servers to which the sending and receiving entities are connected. (Note: For the purposes of Advanced Message Processing, "server" is defined as in <cite>XMPP Core</cite> and does not include any internal components, such as connection managers, that may provide functionality within a server implementation or installation.)</p>
<p>The ruleset MAY be applied to all server-to-server "hops" along the route from the sending and receiving entities by adding the "per-hop' attribute to the <amp/> element. The value of this attribute is either "true" (apply rules to all hops) or "false" (follow default behavior, i.e., apply rules at the edge servers only).</p>
<example caption='Another message with AMP semantics'><![CDATA[
<message
from='northumberland@shakespeare.lit'
id='richard2-4.1.247'
to='kingrichard@royalty.england.lit'>
<body>My lord, dispatch; read o'er these articles.</body>
<amp xmlns='http://jabber.org/protocol/amp'
per-hop='true'>
<rule condition='expire-at'
action='drop'
value='2004-01-01T00:00:00Z'/>
</amp>
</message>
]]></example>
<p>For examples of validation failure, refer to the <link url="#errors">Error Handling</link> section of this document.</p>
<p>Note: Even if "per-hop" processing is requested, each server in the route MUST ignore rules that cannot apply to it; the <link url="#conditions-def">Defined Conditions</link> outline if they can be applied per-hop.</p>
</section3>
</section2>
<section2 topic='Server Processing' anchor='process-server'>
<p>Server operation is where the bulk of the work is performed. Upon receiving a message with an AMP extension, the server performs the following flow:</p>
<ol>
<li>Validate the semantics (E1, E2).</li>
<li>Determine the default behavior.</li>
<li>Process rules until condition is met.
<ul>
<li>If a condition is met, execute that rule's action</li>
<li>If no conditions are met, perform "default" behavior for message</li>
</ul>
</li>
<li>Execute determined action (UCE) (E3).</li>
</ol>
<ul>
<li><cite>E1:</cite> The provided semantics (condition and/or action) are not supported or valid (UCE unsuccessfully)</li>
<li><cite>E2:</cite> The requested semantics are not acceptable (UCE unsuccessfully)</li>
<li><cite>E3:</cite> The next server does not support this protocol (UCE unsuccessfully)</li>
</ul>
<section3 topic='Validating Semantics' anchor='process-server-semantics'>
<p>Validation can take many forms, but at the very least the server MUST verify that it understands each of the rule conditions and actions, and that the condition contents are appropriate. The server MAY also refuse to accept certain combinations of conditions and actions, for example if they present a risk of violating security policies. If the semantics are not valid, supported, or acceptable, the server MUST reply with an error specifying the rule(s) that are at issue. The server SHOULD validate all the semantics before returning an error. For syntax and examples of error handling related to validation failure, refer to the <link url="#errors">Error Handling</link> section of this document.</p>
</section3>
<section3 topic='Determine Default Action' anchor='process-server-default'>
<p>This step is essentially what a server normally does, except that it does not actually perform the action. This determines what would happen to the message if there were no semantics attached (such as dispatch to another server or store offline). At this point, the server SHOULD also calculate any timing or calendar requirements (if applicable).</p>
</section3>
<section3 topic='Process Rules' anchor='process-server-rules'>
<p>At this step, the server processes the attached semantics. The server MUST process the rules serially, and in the order they are presented within the <amp/> element. As soon as a rule's condition is met, processing ends with that action overriding the default action determined earlier (unless the action permits continued processing).</p>
</section3>
<section3 topic='Execute Determined Action' anchor='process-server-execute'>
<p>Once all rules have been processed or otherwise accounted for, the server executes the action determined at this point.</p>
<p>A server SHOULD NOT dispatch a &MESSAGE; stanza with AMP semantics to another server unless it knows that the next server supports AMP (this SHOULD be discovered via <cite>Service Discovery</cite> and MAY be cached to avoid delivery delays). If the next server does not support AMP, the current server replies to the original sender with a &e503; error condition. Otherwise this flow starts again for the server to which the message has been dispatched.</p>
</section3>
<section3 topic='Return Event' anchor='process-server-event'>
<p>If the determined action involves returning an event (alert, error, or notification) to the sender, a server MUST send a &MESSAGE; stanza to the sender containing the rule that was met. This &MESSAGE; stanza MUST include the original value of the 'id' attribute and SHOULD NOT contain the non-AMP contents (e.g., &BODY; child) originally included by the sender.</p>
</section3>
</section2>
</section1>
<section1 topic='Conditions and Actions' anchor='conditionsactions'>
<p>The preceding sections of this document define the general behavior regarding AMP. This section outlines how <rule/> action and condition sets are specified. It also provides defined action and condition sets; these action and condition sets SHOULD be supported by any implementation of Advanced Message Processing, but support for any given action or condition set it not required. (Note: The action and condition sets defined herein may be supplemented in the future via registration of additional action and condition sets with the XMPP Registrar.)</p>
<section2 topic='Rule Condition Guidelines' anchor='conditions-guide'>
<p>The definition of a <rule/> condition MUST provide the following information:</p>
<ul>
<li>Define a namespace governing the condition set</li>
<li>Define the condition:
<ul>
<li>Define the 'condition' attribute value</li>
<li>Specify if the "per-hop" flag applies</li>
<li>Define the syntax/format of the 'value' attribute value</li>
<li>Define how the "value" is interpreted to meet a condition</li>
</ul>
</li>
</ul>
</section2>
<section2 topic='Rule Action Guidelines' anchor='actions-guide'>
<p>The definition of a <rule/> action MUST provide the following information:</p>
<ul>
<li>Define a namespace governing the action set</li>
<li>Define the action:
<ul>
<li>Define each 'action' attribute value</li>
<li>Define the expected behavior if the <rule/> is triggered</li>
</ul>
</li>
</ul>
</section2>
<section2 topic='Defined Conditions' anchor='conditions-def'>
<p>The condition defines how or when a particular rule is triggered. The value of the condition attribute determines what the contents of the <rule/> mean.</p>
<p>The following conditions are defined by this document and SHOULD be supported by any implementation.</p>
<p>In the following sections, the terms "content" and "contents" refers to the XML character data contained by the <rule/> element.</p>
<section3 topic='deliver' anchor='conditions-def-deliver'>
<p>The "deliver" condition is used to ensure delivery (or non-delivery) in one of five ways:</p>
<ol>
<li>Directly to the specified address or account over XMPP</li>
<li>Delayed to offline storage (for later delivery via XMPP)</li>
<li>Forwarded to an alternate address or account over XMPP</li>
<li>Indirectly to an alternate address or account through a gateway to a non-XMPP system</li>
</ol>
<p>This condition is met based on what the processor would do with the message at the moment of receipt, as follows:</p>
<table caption='"deliver" values'>
<tr>
<th>Value</th>
<th>Description</th>
</tr>
<tr>
<td>direct</td>
<td>The message would be immediately delivered to the intended recipient or routed to the next hop.</td>
</tr>
<tr>
<td>forward</td>
<td>The message would be forwarded to another XMPP address or account.</td>
</tr>
<tr>
<td>gateway</td>
<td>The message would be sent through a gateway to an address or account on a non-XMPP system.</td>
</tr>
<tr>
<td>none</td>
<td>The message would not be delivered at all (e.g., because the intended recipient is offline and message storage is not enabled).</td>
</tr>
<tr>
<td>stored</td>
<td>The message would be stored offline for later delivery to the intended recipient.</td>
</tr>
</table>
<p>This condition MAY be applied to each "hop" in the server route.</p>
</section3>
<section3 topic='expire-at' anchor='conditions-def-expireat'>
<p>The "expire-at" condition is used to ensure delivery before an absolute point in time. Naturally, this does not <em>guarantee</em> <note>Guarantee is a strong word. This document defines methods for making message delivery more reliable within certain bounds, but does not pretend that such methods provide any form of guaranteed delivery.</note> that the message will not be delivered after that time from the sender's perspective, since this document does not assume that all machine clocks (e.g., for all servers along the delivery route) are synchronized. However, in order to help ensure that this condition is met correctly, servers that implement this document (or the machines that host such servers) SHOULD use the Network Time Protocol (&rfc1305;) to keep in sync with established time authorities. Note also that expire-at functionality becomes less reliable the closer the expire-at time is to the present (e.g., the sender will receive less reliable delivery of a message speciifying an expire-at time two seconds in the future than of a message specifying an expire-at time two hours or two days in the future).</p>
<p>The content of the 'value' attribute specifies some point after the exact moment the message is sent; the content MUST be a DateTime as specified in &xep0082;, and the timezone MUST be UTC.</p>
<p>The condition is met if the message would be delivered to the recipient after the specified datetime. To determine the datetime to compare to, the processor first determines if and when a message can be dispatched (e.g. not stored offline). The processor then records this datetime, and compares it with the specified datetime. If the current datetime is on or after that specified, the condition is met.</p>
<p>This condition MAY be applied to each "hop" in the server route.</p>
</section3>
<section3 topic='match-resource' anchor='conditions-def-match'>
<p>The "match-resource" condition is used to restrict delivery based on the resource identifier of the recipient JID.</p>
<p>The defined values for this condition are:</p>
<table caption='"match-resource" values'>
<tr>
<th>Value</th>
<th>Description</th>
<th>Example</th>
</tr>
<tr>
<td>any</td>
<td>Destination resource matches any value, effectively ignoring the intended resource.</td>
<td>"home/laptop" matches "home", "home/desktop" or "work/desktop"</td>
</tr>
<tr>
<td>exact</td>
<td>Destination resource exactly matches the intended resource.</td>
<td>"home/laptop" only matches "home/laptop" and not "home/desktop" or "work/desktop"</td>
</tr>
<tr>
<td>other</td>
<td>Destination resource matches any value except for the intended resource.</td>
<td>"home/laptop" matches "work/desktop", "home" or "home/desktop", but not "home/laptop"</td>
</tr>
</table>
<p>The condition is met if the resource for the actual destination JID matches the intended JID using the above rules. For instance, if a message is intended for "romeo@montague.net/work" with the "match-resource" condition of "exact", the condition is met if the message can be immediately delivered only to "romeo@montague.net/work".</p>
<p>For purposes of this condition, an intended JID with no resource has the following behavior:</p>
<ul>
<li>If the value is "exact", the condition is met only if the server would deliver to a destination JID without a resource identifier (e.g., a &xep0045; room or offline storage).</li>
<li>If the value is "other", the condition is met only if the server would not deliver to a destination JID without a resource identifier.</li>
</ul>
<p>This condition MUST NOT be applied to each "hop" in the server route, only at the edge servers. If an <amp/> element includes this condition and also indicates that it should be processed per hop, this <rule/> shall be ignored.</p>
<p>Note: By design, this protocol does not include support for partial resource matching (which would stipulate, for example, that the resource identifiers "home/laptop" and "homeboy" both match "home").</p>
</section3>
</section2>
<section2 topic='Defined Actions' anchor='actions-def'>
<p>The action defines what occurs when a particular rule is triggered. The value of the action attribute determines the behavior if the rule's condition is met.</p>
<p>The following actions are defined by this document.</p>
<section3 topic='alert' anchor='actions-def-alert'>
<p>The "alert" action triggers a reply &MESSAGE; stanza to the sending entity. This &MESSAGE; stanza MUST contain the element <amp status='alert'/>, which itself contains the <rule/> that triggered this action. In all other respects, this action behaves as "drop".</p>
<example caption='Alert Response'><![CDATA[
<message from='hamlet.lit'
to='bernardo@hamlet.lit/elsinore'
id='chatty2'>
<amp xmlns='http://jabber.org/protocol/amp'
status='alert'
from='bernardo@hamlet.lit/elsinore'
to='francisco@hamlet.lit'>
<rule action='alert' condition='deliver' value='stored'/>
</amp>
</message>
]]></example>
</section3>
<section3 topic='drop' anchor='actions-def-drop'>
<p>The "drop" action silently discards the message from any further delivery attempts and ensures that it is not placed into offline storage. The drop MUST NOT result in other responses.</p>
</section3>
<section3 topic='error' anchor='actions-def-error'>
<p>The "error" action triggers a reply &MESSAGE; stanza of type "error" to the sending entity. The &MESSAGE; stanza's <error/> child MUST contain a <failed-rules xmlns='http://jabber.org/protocol/amp#errors'/> error condition, which itself contains the rules that triggered this action.</p>
<example caption='Error Response'><![CDATA[
<message from='hamlet.lit'
to='bernardo@hamlet.lit/elsinore'
type='error'
id='chatty2'>
<amp xmlns='http://jabber.org/protocol/amp'
status='error'
to='bernardo@hamlet.lit/elsinore'
from='francisco@hamlet.lit'>
<rule action='error' condition='deliver' value='stored'/>
</amp>
<error type='modify' code='500'>
<undefined-condition xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'/>
<failed-rules xmlns='http://jabber.org/protocol/amp#errors'>
<rule action='error' condition='deliver' value='stored'/>
</failed-rules>
</error>
</message>
]]></example>
<p>Note that the error SHOULD be of type "modify", and the general error condition SHOULD be <undefined-condition xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'/>.</p>
</section3>
<section3 topic='notify' anchor='actions-def-notify'>
<p>The "notify" action triggers a reply &MESSAGE; stanza to the sending entity. This &MESSAGE; stanza MUST contain the element <amp status='notify'/>, which itself contains the <rule/> that triggered this action. Unlike the other actions, this action does not override the default behavior for a server. Instead, the server then executes its default behavior after sending the notify.</p>
<example caption='Notify Response'><![CDATA[
<message from='hamlet.lit'
to='bernardo@hamlet.lit/elsinore'
id='chatty2'>
<amp xmlns='http://jabber.org/protocol/amp'
status='notify'
to='bernardo@hamlet.lit/elsinore'
from='francisco@hamlet.lit'>
<rule action='notify' condition='deliver' value='stored'/>
</amp>
</message>
]]></example>
</section3>
</section2>
<section2 topic='Description of Condition/Action Combinations' anchor='description'>
<p>In general, a rule can be read as "do {action} if {condition} is true for {value}"; however, to facilitate understanding, this section describes the various condition/action combinations in plain English.</p>
<section3 topic='Deliver Rules' anchor='description-deliver'>
<p>When the condition is "deliver", the rules can be described as follows:</p>
<table caption='Deliver Rules'>
<tr>
<th>Action</th>
<th>Value</th>
<th>Description</th>
</tr>
<tr>
<td>alert</td>
<td>direct</td>
<td>Return an alert if the message would be delivered directly.</td>
</tr>
<tr>
<td>alert</td>
<td>forward</td>
<td>Return an alert if the message would be forwarded to another XMPP address.</td>
</tr>
<tr>
<td>alert</td>
<td>gateway</td>
<td>Return an alert if the message would be delivered to a non-XMPP address through a gateway.</td>
</tr>
<tr>
<td>alert</td>
<td>none</td>
<td>Return an alert if no delivery is possible.</td>
</tr>
<tr>
<td>alert</td>
<td>stored</td>
<td>Return an alert if the message would be stored offline for later delivery via XMPP.</td>
</tr>
<tr>
<td>drop</td>
<td>direct</td>
<td>Drop the message if it would be delivered directly.</td>
</tr>
<tr>
<td>drop</td>
<td>forward</td>
<td>Drop the message if it would be forwarded to another XMPP address.</td>
</tr>
<tr>
<td>drop</td>
<td>gateway</td>
<td>Drop the message if it would be delivered to a non-XMPP address through a gateway.</td>
</tr>
<tr>
<td>drop</td>
<td>none</td>
<td>Drop the message if no delivery is possible.</td>
</tr>
<tr>
<td>drop</td>
<td>stored</td>
<td>Drop the message if it would be stored offline for later delivery via XMPP.</td>
</tr>
<tr>
<td>error</td>
<td>direct</td>
<td>Return an error if the message would be delivered directly.</td>
</tr>
<tr>
<td>error</td>
<td>forward</td>
<td>Return an error if the message would be forwarded to another XMPP address.</td>
</tr>
<tr>
<td>error</td>
<td>gateway</td>
<td>Return an error if the message would be delivered to a non-XMPP address through a gateway.</td>
</tr>
<tr>
<td>error</td>
<td>none</td>
<td>Return an error if no delivery is possible.</td>
</tr>
<tr>
<td>error</td>
<td>stored</td>
<td>Return an error if the message would be stored offline for later delivery via XMPP.</td>
</tr>
<tr>
<td>notify</td>
<td>direct</td>
<td>Return a notification if the message would be delivered directly.</td>
</tr>
<tr>
<td>notify</td>
<td>forward</td>
<td>Return a notification if the message would be forwarded to another XMPP address.</td>
</tr>
<tr>
<td>notify</td>
<td>gateway</td>
<td>Return a notification if the message would be delivered to a non-XMPP address through a gateway.</td>
</tr>
<tr>
<td>notify</td>
<td>none</td>
<td>Return a notification if no delivery is possible.</td>
</tr>
<tr>
<td>notify</td>
<td>stored</td>
<td>Return a notification if the message would be stored offline for later delivery via XMPP.</td>
</tr>
</table>
</section3>
<section3 topic='Expire-at Rules' anchor='description-expire-at'>
<p>When the condition is "expire-at", the rules can be described as follows:</p>
<table caption='Expiration Rules'>
<tr>
<th>Action</th>
<th>Description</th>
</tr>
<tr>
<td>alert</td>
<td>Return an alert if the message would be delivered after the specified timestamp.</td>
</tr>
<tr>
<td>drop</td>
<td>Drop the message if it would be delivered after the specified timestamp.</td>
</tr>
<tr>
<td>error</td>
<td>Return an error if the message would be delivered after the specified timestamp.</td>
</tr>
<tr>
<td>notify</td>
<td>Return a notification if the message would be delivered after the specified timestamp.</td>
</tr>
</table>
</section3>
<section3 topic='Match-resource Rules' anchor='description-match-resource'>
<p>When the condition is "match-resource", the rules can be described as follows:</p>
<table caption='Resource Matching Rules'>
<tr>
<th>Action</th>
<th>Value</th>
<th>Description</th>
</tr>
<tr>
<td>alert</td>
<td>any</td>
<td>Return an alert if the message would be delivered to any resource.</td>
</tr>
<tr>
<td>alert</td>
<td>exact</td>
<td>Return an alert if the message would be delivered to the exact resource.</td>
</tr>
<tr>
<td>alert</td>
<td>other</td>
<td>Return an alert if the message would be delivered to a resource other than that specified.</td>
</tr>
<tr>
<td>drop</td>
<td>any</td>
<td>Drop the message if it would be delivered to any resource.</td>
</tr>
<tr>
<td>drop</td>
<td>exact</td>
<td>Drop the message if it would be delivered to the exact resource.</td>
</tr>
<tr>
<td>drop</td>
<td>other</td>
<td>Drop the message if it would be delivered to a resource other than that specified.</td>
</tr>
<tr>
<td>error</td>
<td>any</td>
<td>Return an error if the message would be delivered to any resource.</td>
</tr>
<tr>
<td>error</td>
<td>exact</td>
<td>Return an error if the message would be delivered to the exact resource.</td>
</tr>
<tr>
<td>error</td>
<td>other</td>
<td>Return an error if the message would be delivered to a resource other than that specified.</td>
</tr>
<tr>
<td>notify</td>
<td>any</td>
<td>Return a notification if the message would be delivered to any resource.</td>
</tr>
<tr>
<td>notify</td>
<td>exact</td>
<td>Return a notification if the message would be delivered to the exact resource.</td>
</tr>
<tr>
<td>notify</td>
<td>other</td>
<td>Return a notification if the message would be delivered to a resource other than that specified.</td>
</tr>
</table>
</section3>
</section2>
</section1>
<section1 topic='Formal Description' anchor='formal'>
<section2 topic='<amp/> Root Element' anchor='formal-root'>
<p>All delivery semantics are encapsulated in the <amp/> element. This element contains one or more <rule/> elements specifying the specific rules to process. It can optionally possess attributes about the current status, the original sender and recipient, and route applicability.</p>
<p>The 'status' attribute specifies the reason for this <amp/> element. When specifying semantics to be applied (client to server), this attribute MUST NOT be present. When replying to a sending entity regarding a met condition, this attribute MUST be present and SHOULD be the value of the 'action' attribute for the triggered rule. (Note: Individual action definitions MAY provide their own requirements.)</p>
<p>The 'from' attribute specifies the original sender of the containing &MESSAGE; stanza. This attribute MUST be specified for any &MESSAGE; stanza sent from a supporting server, regardless of the recipient. It SHOULD NOT be specified otherwise. The value of the 'from' attribute MUST be the full JID (node@domain/resource) of the sender for the original &MESSAGE; stanza.</p>
<p>The 'to' attribute specifies the original (intended) recipient of the containing &MESSAGE; stanza. This attribute MUST be specified for any &MESSAGE; stanza sent from a supporting server, regardless of the recipient. It SHOULD NOT be specified otherwise. The value of the 'to' attribute MUST be the full JID (node@domain/resource) of the intended recipient for the original &MESSAGE; stanza.</p>
<p>The 'per-hop' attribute flags the contained ruleset for processing at each server in the route between the original sender and original intended recipient. This attribute MAY be present, and MUST be either "true" or "false". If not present, the default is "false".</p>
</section2>
<section2 topic='<rule/> Element' anchor='formal-rule'>
<p>Each semantic rule is specified with a <rule/> element. This element possesses attributes for the condition, value, and action.</p>
<p>The 'action' attribute defines the result for this rule. This attribute MUST be present, and MUST be either a value defined in the <link url="#actions-def">Defined Actions</link> section, or one registered with the XMPP Registrar.</p>
<p>The 'condition' attribute defines the overall condition this rule applies to. This attribute MUST be present, and MUST be either a value defined in the <link url="#conditions-def">Defined Conditions</link> section, or one registered with the XMPP Registrar.</p>
<p>The 'value' attribute defines how the condition is matched. This attribute MUST be present, and MUST NOT be an empty string (""). The interpretation of this attribute's value is determined by the 'condition' attribute.</p>
</section2>
</section1>
<section1 topic='Example Scenarios' anchor='examples'>
<section2 topic='Reliable Data Transport' anchor='examples-reliabledata'>
<p>The &MESSAGE; stanza is nearly ideal for data transport, but to ensure reliability it is often desirable that such messages not be delivered to any resource but that specified. To facilitate this, the sending entity includes a <rule action='drop' condition='match-resource' value='other'/> (if failure notification is unnecessary) or <rule action='error' condition='match-resource' value='other'/> (if failure notification is required). The following example illustrates this using &xep0047;:</p>
<example caption='Sending a message for reliable data transport'><![CDATA[
<message to='francisco@hamlet.lit/pda'
from='bernardo@hamlet.lit/elsinore'
id='ibb1'>
<data xmlns='http://jabber.org/protocol/ibb' sid='mySID' seq='0'>
qANQR1DBwU4DX7jmYZnncmUQB/9KuKBddzQH+tZ1ZywKK0yHKnq57kWq+RFtQdCJ
WpdWpR0uQsuJe7+vh3NWn59/gTc5MDlX8dS9p0ovStmNcyLhxVgmqS8ZKhsblVeu
IpQ0JgavABqibJolc3BKrVtVV1igKiX/N7Pi8RtY1K18toaMDhdEfhBRzO/XB0+P
AQhYlRjNacGcslkhXqNjK5Va4tuOAPy2n1Q8UUrHbUd0g+xJ9Bm0G0LZXyvCWyKH
kuNEHFQiLuCY6Iv0myq6iX6tjuHehZlFSh80b5BVV9tNLwNR5Eqz1klxMhoghJOA
</data>
<amp xmlns='http://jabber.org/protocol/amp' per-hop='true'>
<rule action='error' condition='expire-at' value='2004-09-10T08:33:14Z'/>
<rule action='error' condition='match-resource' value='other'/>
</amp>
</message>
]]></example>
<p>In the above case, the sender would receive an error reply if the message could not be delivered specifically to "francisco@hamlet.lit/pda" by the specified time. For example, if the intended resource went offline before the message could be delivered, the processing server would return the following error:</p>
<example caption='Failed reliable data transport message'><![CDATA[
<message from='hamlet.lit'
to='bernardo@hamlet.lit/elsinore'
id='ibb1'>
<amp xmlns='http://jabber.org/protocol/amp'
from='bernardo@hamlet.lit/elsinore'
to='francisco@hamlet.lit/pda'>
<rule action='error' condition='match-resource' value='other'/>
</amp>
<error type='modify' code='500'>
<undefined-condition xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'/>
<failed-rules xmlns='http://jabber.org/protocol/amp#errors'>
<rule action='error' condition='match-resource' value='other'/>
</failed-rules>
</error>
</message>
]]></example>
</section2>
<section2 topic='Time-Sensitive Messages' anchor='examples-time'>
<p>Time-sensitive messages are a frequent occurrence in some environments (e.g., front-office personnel routinely notify others of "events" such as guests, unexpected refreshments, and ad-hoc gatherings). To send a time-sensitive message, the sending entity includes a <rule action='drop' condition='expire-at'/> with the time when the event is to occur:</p>
<example caption='Sending a time-sensitive message'><![CDATA[
<message to='linuxwolf@outer-planes.net'
from='receptionist@outer-planes.net'
id='alert849'>
<subject>Guest Alert!</subject>
<body>
There will be clients in the conference room today around 1 PM!
As always, be courteous and quiet nearby...
</body>
<amp xmlns='http://jabber.org/protocol/amp'>
<rule action='drop' condition='expire-at' value='2003-06-23T23:00:00Z'/>
</amp>
</message>
]]></example>
<p>In the above case, the server for "linuxwolf@outer-planes.net" would not deliver the message once 23:00 UTC (3:00 PM Pacific Daylight Time) has passed.</p>
</section2>
<section2 topic='Transient Messages' anchor='examples-transient'>
<p>Transient messages are messages that should never be stored offline. To send a transient message, the sending entity includes a <rule action='drop' condition='deliver' value='stored'/>:</p>
<example caption='Sending a transient message'><![CDATA[
<message to='francisco@hamlet.lit'
from='bernardo@hamlet.lit/elsinore'
type='chat'
id='chatty1'>
<body>Who's there?</body>
<amp xmlns='http://jabber.org/protocol/amp'>
<rule action='drop' condition='deliver' value='stored'/>
</amp>
</message>
]]></example>
<p>Alternatively, the sending entity includes a <rule action='alert' condition='deliver' value='stored'/> to be alerted instead of having the message silently dropped:</p>
<example caption='Sending a transient message (requesting alert)'><![CDATA[
<message to='francisco@hamlet.lit'
from='bernardo@hamlet.lit/elsinore'
type='chat'
id='chatty2'>
<body>Who's there?</body>
<amp xmlns='http://jabber.org/protocol/amp'>
<rule action='alert' condition='deliver' value='stored'/>
</amp>
</message>
]]></example>
<example caption='Sender alerted regarding transient message'><![CDATA[
<message from='hamlet.lit'
to='bernardo@hamlet.lit/elsinore'
id='chatty2'>
<amp xmlns='http://jabber.org/protocol/amp'
status='alert'
from='bernardo@hamlet.lit/elsinore'
to='francisco@hamlet.lit'>
<rule action='alert' condition='deliver' value='stored'/>
</amp>
</message>
]]></example>
</section2>
</section1>
<section1 topic='Error Handling' anchor='errors'>
<section2 topic='Conditions' anchor='errors-conditions'>
<p>To simplify the discussion of error conditions, this document uses the following mappings between namespace URIs and namespace prefixes (note: this mapping is provided only for the purpose of simplifying the discussion and is not intended for use within the protocol itself).</p>
<table caption='Namespace Mappings'>
<tr>
<th>Prefix</th>
<th>URI</th>
</tr>
<tr>
<td>xmpp</td>
<td>urn:ietf:params:xml:ns:xmpp-stanzas</td>
</tr>
<tr>
<td>msg</td>
<td>http://jabber.org/protocol/amp</td>
</tr>
<tr>
<td>err</td>
<td>http://jabber.org/protocol/amp#errors</td>
</tr>
</table>
<p>The following table shows the possible error conditions in relation to general AMP rules and conditions as well as the <link url="#actions-def">Defined Actions</link>.</p>
<table caption='Error conditions'>
<tr>
<th>General Condition</th>
<th>Error Type</th>
<th>Specific Condition</th>
<th>Description</th>
</tr>
<tr>
<td><xmpp:bad-request/></td>
<td>modify</td>
<td><msg:unsupported-actions/></td>
<td>One or more rule's specified actions are not supported. The element <msg:unsupported-actions/> contains the <rule/> elements that specify the unsupported actions.</td>
</tr>
<tr>
<td><xmpp:bad-request/></td>
<td>modify</td>
<td><msg:unsupported-conditions/></td>
<td>One or more rule's specified conditions are not supported. The element <msg:unsupported-conditions/> contains the <rule/> elements that specify the unsupported conditions.</td>
</tr>
<tr>
<td><xmpp:not-acceptable/></td>
<td>modify</td>
<td><msg:invalid-rules/></td>
<td>One or more rules are not acceptable by this server, usually because the condition/action combination is restricted. The element <msg:invalid-rules/> contains the <rule/> elements that are not acceptable.</td>
</tr>
<tr>
<td><xmpp:service-unavailable/></td>
<td>cancel</td>
<td>NONE</td>
<td>This protocol is not supported. This error is returned to the sending entity if a server along the route to the recipient does not implement this protocol.</td>
</tr>
<tr>
<td><xmpp:undefined-condition/></td>
<td>modify</td>
<td><err:failed-rules/></td>
<td>One or more <rule/> elements triggered the "error" action. This condition contains the triggered <rule/> elements.</td>
</tr>
</table>
</section2>
<section2 topic='Examples' anchor='errors-examples'>
<p>This section shows examples of the error conditions described in the previous section (for information regarding mapping of XMPP error conditions to Jabber error codes, refer to &xep0086;).</p>
<section3 topic='Unsupported Action' anchor='errors-action'>
<example caption='A message with AMP semantics'><![CDATA[
<message
from='northumberland@shakespeare.lit'
id='richard2-4.1.247'
to='kingrichard@royalty.england.lit'>
<body>My lord, dispatch; read o'er these articles.</body>
<amp xmlns='http://jabber.org/protocol/amp'>
<rule action='drop' condition='expire-at' value='2004-01-01T00:00:00Z'/>
</amp>
</message>
]]></example>
<example caption='Server does not support action'><![CDATA[
<message
from='shakespeare.lit'
id='richard2-4.1.247'
to='northumberland@shakespeare.lit'
type='error'>
<amp xmlns='http://jabber.org/protocol/amp'>
<rule action='drop' condition='expire-at' value='2004-01-01T00:00:00Z'/>
</amp>
<error type='modify' code='400'>
<bad-request xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'/>
<unsupported-actions xmlns='http://jabber.org/protocol/amp'>
<rule condition='expire-at'
action='drop'
value='2004-01-01T00:00:00Z'/>
</unsupported-actions>
</error>
</message>
]]></example>
</section3>
<section3 topic='Unsupported Condition' anchor='errors-condition'>
<example caption='A message with AMP semantics'><![CDATA[
<message
from='shakespeare.lit'
id='richard2-4.1.247'
to='kingrichard@royalty.england.lit'>
<body>My lord, dispatch; read o'er these articles.</body>
<amp xmlns='http://jabber.org/protocol/amp'>
<rule action='drop' condition='expire-at' value='2004-01-01T00:00:00Z'/>
</amp>
</message>
]]></example>
<example caption='Server does not support condition'><![CDATA[
<message
from='shakespeare.lit'
id='richard2-4.1.247'
to='northumberland@shakespeare.lit'
type='error'>
<amp xmlns='http://jabber.org/protocol/amp'>
<rule action='drop' condition='expire-at' value='2004-01-01T00:00:00Z'/>
</amp>
<error type='modify' code='400'>
<bad-request xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'/>
<unsupported-conditions xmlns='http://jabber.org/protocol/amp'>
<rule action='drop' condition='expire-at' value='2004-01-01T00:00:00Z'/>
</unsupported-conditions>
</error>
</message>
]]></example>
</section3>
<section3 topic='Not Acceptable' anchor='errors-notacceptable'>
<example caption='A message with AMP semantics'><![CDATA[
<message
from='northumberland@shakespeare.lit'
id='richard2-4.1.247'
to='kingrichard@royalty.england.lit'>
<body>My lord, dispatch; read o'er these articles.</body>
<amp xmlns='http://jabber.org/protocol/amp'>
<rule action='drop' condition='expire-at' value='2004-01-01T00:00:00Z'/>
</amp>
</message>
]]></example>
<example caption='The rule is not acceptable to the server'><![CDATA[
<message
from='shakespeare.lit'
id='richard2-4.1.247'
to='northumberland@shakespeare.lit'
type='error'>
<amp xmlns='http://jabber.org/protocol/amp'>
<rule action='drop' condition='expire-at' value='2004-01-01T00:00:00Z'/>
</amp>
<error type='modify' code='405'>
<not-acceptable xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'/>
<invalid-rules xmlns='http://jabber.org/protocol/amp'>
<rule action='drop' condition='expire-at' value='2004-01-01T00:00:00Z'/>
</invalid-rules>
</error>
</message>
]]></example>
</section3>
<section3 topic='Service Unavailable' anchor='errors-unavail'>
<example caption='A message with AMP semantics'><![CDATA[
<message
from='northumberland@shakespeare.lit'
id='richard2-4.1.247'
to='kingrichard@royalty.england.lit'>
<body>My lord, dispatch; read o'er these articles.</body>
<amp xmlns='http://jabber.org/protocol/amp'>
<rule action='drop' condition='expire-at' value='2004-01-01T00:00:00Z'/>
</amp>
</message>
]]></example>
<example caption='AMP service is unavailable'><![CDATA[
<message
from='royalty.england.lit'
id='richard2-4.1.247'
to='northumberland@shakespeare.lit'
type='error'>
<amp xmlns='http://jabber.org/protocol/amp'>
<rule action='drop' condition='expire-at' value='2004-01-01T00:00:00Z'/>
</amp>
<error type='cancel' code='503'>
<service-unavailable xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'/>
</error>
</message>
]]></example>
</section3>
<section3 topic='Undefined Condition' anchor='errors-undefined'>
<example caption='A message with AMP semantics'><![CDATA[
<message from='hamlet.lit'
to='bernardo@hamlet.lit/elsinore'
id='chatty2'>
<body>Who's there?</body>
<amp xmlns='http://jabber.org/protocol/amp'
status='error'
from='francisco@hamlet.lit'
to='bernardo@hamlet.lit/elsinore'>
<rule action='error' condition='deliver' value='stored'/>
</amp>
</message>
]]></example>
<example caption='Failed rules'><![CDATA[
<message from='hamlet.lit'
to='bernardo@hamlet.lit/elsinore'
type='error'
id='chatty2'>
<amp xmlns='http://jabber.org/protocol/amp'
status='error'
from='francisco@hamlet.lit'
to='bernardo@hamlet.lit/elsinore'>
<rule action='error' condition='deliver' value='stored'/>
</amp>
<error type='modify' code='500'>
<undefined-condition xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'/>
<failed-rules xmlns='http://jabber.org/protocol/amp#errors'>
<rule action='error' condition='deliver' value='stored'/>
</failed-rules>
</error>
</message>