aboutsummaryrefslogtreecommitdiff
path: root/xep-0313.xml
blob: e747d4d1bc0788baa5b2889b543f0fee64d148eb (plain)
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
<?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>Message Archive Management</title>
  <abstract>This document defines a protocol to query and control an archive of messages stored on a server.</abstract>
  &LEGALNOTICE;
  <number>0313</number>
  <status>Proposed</status>
  <lastcall>2017-11-15</lastcall>
  <type>Standards Track</type>
  <sig>Standards</sig>
  <dependencies>
    <spec>XMPP Core</spec>
    <spec>XEP-0030</spec>
    <spec>XEP-0059</spec>
    <spec>XEP-0297</spec>
  </dependencies>
  <supersedes/>
  <supersededby/>
  <shortname>mam</shortname>
  <schemaloc>
    <url>http://www.xmpp.org/schemas/archive-management.xsd</url>
  </schemaloc>
  &mwild;
  &ksmith;
  <revision>
    <version>0.6.1</version>
    <date>2017-02-22</date>
    <initials>mw</initials>
    <remark>
        <p>Warn of spoofing of &lt;x&gt; elements in MUC stanzas</p>
    </remark>
  </revision>
  <revision>
    <version>0.6</version>
    <date>2017-02-17</date>
    <initials>dg, mw</initials>
    <remark>
      <p>Namespace bump</p>
      <p>Added method for server to communicate the archive id</p>
      <p>Incorporated editorial clarifications based on implementation feedback</p>
      <p>Clarifications on the topics of message ordering, message deletion and use of the protocol for synchronization</p>
    </remark>
  </revision>
  <revision>
    <version>0.5.1</version>
    <date>2016-03-07</date>
    <initials>XEP Editor (ssw)</initials>
    <remark>
      <p>Bump old namespace version in examples (Kevin Smith)</p>
    </remark>
  </revision>
  <revision>
    <version>0.5</version>
    <date>2016-01-20</date>
    <initials>XEP Editor (mam)</initials>
    <remark>
      <p>Added clarifications and enhancements when interacting with Multi-User Chat (MUC) (Mickaël Rémond)</p>
    </remark>
  </revision>
  <revision>
    <version>0.4.1</version>
    <date>2015-09-29</date>
    <initials>XEP Editor (mam)</initials>
    <remark>
      <p>Fix Example #9 from &lt;/message/&gt; to &lt;/iq&gt; (Florian Schmaus)</p>
      <p>Add missing jabber:client namespace in Example #2 (Christian Schudt)</p>
    </remark>
  </revision>
  <revision>
    <version>0.4</version>
    <date>2015-09-21</date>
    <initials>ks/mw</initials>
    <remark>
      <p>Switch the sentinel message back to the iq result.</p>
      <p>Various small fixes to the document.</p>
    </remark>
  </revision>
  <revision>
    <version>0.3</version>
    <date>2014-08-14</date>
    <initials>ka/ks</initials>
    <remark><p>Fetching current preferences,
				switch to iq-set for searching,
				switch to using a data form,
				describe how to fetch that form, remove the archived element and
				use a sentinel message instead of iq reply.</p></remark>
  </revision>
  <revision>
    <version>0.2</version>
    <date>2013-05-31</date>
    <initials>mw</initials>
    <remark><p>Document the ability to page through results by message UIDs, define the &lt;archived/&gt; element, and various minor improvements.</p></remark>
  </revision>
  <revision>
    <version>0.1</version>
    <date>2012-04-18</date>
    <initials>mw</initials>
    <remark><p>Initial version, to much rejoicing.</p></remark>
  </revision>
</header>

<section1 topic='Introduction' anchor='intro'>
  <p>It is a common desire for users of XMPP to want to store their messages in a central archive
  on their server. This feature allows them to record conversations that take place on clients that do not
  support local history storage, to synchronise conversation history seamlessly between
  multiple clients, to read the history of a MUC room, or to view old items in a pubsub node.</p>
</section1>

<section1 topic='Requirements' anchor='requirements'>
  <p>As this extension aims to make things easy for client developers, some research was made into the
  way clients handle history today. The resulting protocol was designed to allow for the following primary
  usage scenarios:</p>
  <ul>
    <li>Automatic history synchronization between multiple clients.</li>
    <li>Calendar-based on-demand display of historic messages in a client that doesn't keep local history.</li>
    <li>So-called 'infinite' scrollback, whereby a client automatically fetches and displays historical messages
    naturally in the message log as the user scrolls back in time.</li>
  </ul>
  <p>Another extension for archiving already exists in XMPP, &xep0136;). However implementation experience has
  shown that the protocol defined therein supports rather more functionality than is typically needed for the
  above uses, and is significantly more effort to implement.</p>
  <p>This specification aims to define a much simpler and modular protocol for working with a server-side
  message store. Through this it is hoped to boost implementation and deployment of archiving in XMPP. It
  should be noted that (although not required) a server is free to implement XEP-0136 alongside this
  protocol if it so chooses, though a mapping between both protocols is beyond the scope of this specification.</p>
  <p>Notable functionality in XEP-0136 that is intentionally not defined by this specification for simplicity:</p>
  <ul>
    <li>Support for 'collections'. Few clients even support this concept for local history storage, and
    it is possible to apply the logic for splitting a stream of messages into conversations on the
    client-side, thus greatly simplifying the protocol.</li>
    <li>Support for uploading to the archive. On the assumption that a server automatically archives
    messages to and from the client, it is typically rare for a client to end up with messages that are
    not already in the archive. Uploading could be useful for bootstrapping an empty archive however, and
    may be defined in a future specification if there is demand for such functionality.</li>
    <li>Support for 'off the record' chats (OTR; not to be confused with the encryption algorithm of
    the same name). This allowed complex negotiation for either the user or contact to command specific
    conversations to bypass the archive. In reality the archiving behaviour of a contact's server cannot
    be enforced (they could ignore the OTR request and archive the messages anyway without your consent)
    so this specification does not try and regulate that. Equivalent functionality can be implemented with
    server logic for not including encrypted or specially-tagged messages in the archive (out of scope for
    this specification).</li>
    <li>Support per-session configuration. This feature was deemed unnecessary for the majority of
    implementations, and hence the configuration protocol in this specification is much simplified,
    which allows for a simple user interface in clients. Advanced configuration however may be performed
    through ad-hoc commands depending on the server implementation.</li>
  </ul>
</section1>

<section1 topic='Message archives' anchor='archives'>
	<p>An archive contains a collection of messages relevant to a particular XMPP address, e.g. a user, MUC, pubsub node, server. Note: while a service might have many "archives" as defined here (one per JID capable of being queried) this is a conceptual distinction,
	and a server is not bound to any particular implementation or arrangement of data stores.</p>
	<p>Exactly which messages a server archives is up to implementation and deployment policy,
        but it is expected that all messages that hold meaningful content, rather than state changes such as Chat State Notifications, would be archived. Rules are specified later in this document.</p>
    <p>A stored message consists of at least the following pieces of information:</p>
    <ul>
            <li>A timestamp of when the message was sent (for an outgoing message) or received (for
            an incoming message).</li>
            <li>The remote JID that the stanza is to (for an outgoing message) or from (for an
            incoming message).</li>
            <li>A server-assigned UID that MUST be unpredictable and unique within the archive.</li>
            <li>The message stanza itself. The entire original stanza SHOULD be stored, but at a
            minimum only the &BODY; tag MUST be preserved (ie. the server might, at its
            discretion, strip certain extensions from messages before storage).</li>
    </ul>
    <p>Note that 'incoming' and 'outgoing' messages are viewed within the context of the archived JID, rather than the system as a whole. For example, if romeo@montegue.lit sent a message to juliet@capulet.lit, it would be an outgoing message in the context of archiving for Romeo, and an incoming message in the context of archiving for Juliet.</p>
    <section2 topic='Order of messages' anchor='archive_order'>
    <p>Order within the archive MUST be preserved, where the order of messages is the same as the order that the client originally received them (or would have received them if online). Throughout this document the term 'chronological order' refers to this order, however implementors should take care not to rely on timestamps alone for
    ordering messages, as multiple messages may share the same timestamp.</p>
    </section2>
    <section2 topic='Message retention and deletion' anchor='archives_deletion'>
	    <p>A server MAY impose limits on the size of an individual archive. For example a server might begin
		to discard old messages once the archive reaches a certain size, or only keep messages until they
		reach a certain age. Any such deleted messages MUST be the oldest in the archive, i.e. it is not permitted
		to create gaps or "holes" in the archive. The UIDs of deleted messages MUST NOT be reused for new messages.</p>

		<p>However a server that wishes to remove messages from the middle of an archive, e.g. to remove accidentally transmitted
                sensitive information may omit the &lt;message&gt; stanza from inside the &lt;forwarded&gt; element or replace the
                message with  an appropriate placeholder when transmitting the result in response to a query. However servers
                MUST retain the UID, timestamp and JID of the original message internally to ensure that all queries remain consistent.
                It should also be understood that clients maintaining their own local copy of the archive may still retain the original
                message locally in this case, and this protocol provides no mechanism for forcibly removing messages from any local archive
                or cache that clients may keep.</p>
    </section2>
    <section2 topic='Archiving entities' anchor='archiving_entities'>
	<p>There is no restriction on which services can expose archives, although only user, MUC and pubsub node archives are discussed here.</p>
	<section3 topic='User archives' anchor='archives_user'>
		<p>The most typical address is that of a user's own bare JID, within which those messages sent to or from that
        user's account would generally automatically be stored by the server. The collection
        is ordered chronologically by the time each message was sent/received.</p>

	<p>Servers that expose archive messages of sent/received messages on behalf of local users MUST expose these archives to the user on the user's bare JID.</p>
	</section3>
	<section3 topic='MUC archives' anchor='archives_user'>
		<p>A MUC service allowing MAM queries for a room MUST expose the MAM archive on the room's bare JID</p>
	</section3>
	<section3 topic='Pubsub node archives' anchor='archives_user'>
		<p>A pubsub service allowing MAM queries for a node's data MUST expose this for queries addressed to the pubsub service</p>
	</section3>
	</section2>
	<section2 topic='Querying Entities' anchor='entities'>
		<p>While this document talks about 'clients' and 'servers', as these are the common cases, the querying entity (referred to as a 'client') need not be an XMPP client as defined by RFC6120, but could potentially be any type of entity, and the queried entity (referred to as a 'server') need not be an XMPP server as defined by RFC6120, although access controls might prohibit any given entity from being able to access an archive.</p>
	</section2>
	<section2 topic='Communicating the archive ID' anchor='archives_id'>
		<p>When a message is archived, the server MUST add an &lt;stanza-id/&gt; element as defined in &xep0359; to the message, which informs the recipient of where and under what ID the message is stored. When doing this the server MUST follow the business rules defined in XEP-0359. The 'by' attribute MUST be set to the address of the archive. For regular users that’s the bare JID of the account and for MUC that’s the bare JID of the room.</p>
		<p>Servers MUST NOT include the &lt;stanza-id/&gt; element in messages addressed to JIDs that do not have permissions to access the archive, such as a users’s outgoing messages to their contacts. However servers SHOULD include the element as a child of the forwarded message when using &xep0280;</p>
		<example caption='Client receives a message that has been archived'><![CDATA[
<message to='juliet@capulet.lit/balcony'
	 from='romeo@montague.lit/orchard'
         type='chat'>
  <body>Call me but love, and I'll be new baptized; Henceforth I never will be Romeo.</body>
  <stanza-id xmlns='urn:xmpp:sid:0' by='juliet@capulet.lit' id='28482-98726-73623' />
</message>]]></example>
		<p>Note: Previous versions of this protocol did not specify any interaction with stanza-id, and clients MUST NOT interpret XEP-0359 IDs in messages as archive IDs unless the server advertises support for 'urn:xmpp:mam:2' specifically.</p>
	</section2>
</section1>

<section1 topic='Querying an archive' anchor='query'>
        <p>An entity is able to query (subject to appropriate access rights) an archive for all messages within a certain timespan, optionally
        restricting results to those to/from a particular JID. To allow limiting the results or paging
        through them a client may use &xep0059;, which MUST be supported by both the client and the server.</p>
        <p>A query consists of an &IQ; stanza of type 'set' addressed to the account or server entity hosting
        the archive, with a 'query' payload. On receiving the query, the server pushes to the client a
        series of messages in chronological order from the archive that match the client's given criteria. After the
        results it then returns the &IQ; result to indicate that the query is completed.</p>
        <p>The final &IQ; result response MUST include an RSM &lt;set/&gt; element, wrapped into a &lt;fin/&gt;
        element qualified by the 'urn:xmpp:mam:2' namespace, indicating the
      UID of the first and last message of the (possibly limited) result set. This
      allows clients to accurately page through messages.</p>
    <example caption='A user queries their archive for messages'><![CDATA[
<iq type='set' id='juliet1'>
  <query xmlns='urn:xmpp:mam:2' queryid='f27' />
</iq>]]></example>

    <example caption='Their server sends the matching messages'><![CDATA[
<message id='aeb213' to='juliet@capulet.lit/chamber'>
  <result xmlns='urn:xmpp:mam:2' queryid='f27' id='28482-98726-73623'>
    <forwarded xmlns='urn:xmpp:forward:0'>
      <delay xmlns='urn:xmpp:delay' stamp='2010-07-10T23:08:25Z'/>
      <message xmlns='jabber:client' from="witch@shakespeare.lit" to="macbeth@shakespeare.lit">
        <body>Hail to thee</body>
      </message>
    </forwarded>
  </result>
</message>]]></example>

    <example caption='Server returns the result IQ to signal the end'><![CDATA[
<iq type='result' id='juliet1'>
  <fin xmlns='urn:xmpp:mam:2'>
    <set xmlns='http://jabber.org/protocol/rsm'>
      <first index='0'>28482-98726-73623</first>
      <last>09af3-cc343-b409f</last>
    </set>
  </fin>
</iq>]]></example>
  <p>To ensure that the client knows when the results are complete, the server MUST send the &IQ; result after last query result has been sent
  to the client. The client can optionally include a 'queryid' attribute in their query, which allows the client to match results to their initiating query.</p>
  <p>When querying a pubsub node's archive, the 'node' attribute is added to the &lt;query&gt; element.</p>
  <example caption="A user queries a pubsub node's archive for messages"><![CDATA[
<iq to='pubsub.shakespeare.lit' type='set' id='juliet1'>
  <query xmlns='urn:xmpp:mam:2' queryid='f28' node='fdp/submitted/capulet.lit/sonnets'/>
</iq>
]]></example>
  <section2 topic='Filtering results' anchor='filter'>
    <p>By default all messages match a query, and filters are used to request a subset of the archived
    messages. Filters are specified in a &xep0004; data form included with the query. The hidden FORM_TYPE field
    MUST be set to this protocol's namespace, 'urn:xmpp:mam:2'. Three further fields are defined by this
    XEP and MUST be supported by servers, though all of them are optional for the client. These fields are:</p>
    <ul>
        <li>start</li>
        <li>end</li>
        <li>with</li>
    </ul>
    <p>Other fields may be used, but are not defined in this document - the naming of new fields MUST be
    consistent with the format defined in &xep0068;. Servers MUST NOT mark any fields in the form as
    being required (i.e. with the data forms &lt;required/&gt; element), regardless of whether they are
    defined in this document or elsewhere.</p>
    <section3 topic='Filtering by JID' anchor='filter-jid'>
      <p>If a 'with' field is present in the form, it contains a JID against which to match messages. The
      server MUST only return messages if they match the supplied JID. A message in a user's archive matches if the JID matches either the to or from of the message. An item in a pubsub or MUC archive matches if the publisher of the item matches the JID; note that this should only be available to entities that would already have been allowed to know the publisher of the events (e.g. this could not be used by a visitor to a semi-anonymous MUC).</p>
      <p>If the 'with' field's value is the bare JID of the archive, the server must only return results where both the 'to' and 'from' match the bare JID (either as bare or by ignoring the resource), as otherwise every message in the archive would match</p>
      <p>If 'with' is omitted, the server MUST match all messages in the selected timespan with the query,
      regardless of the to/from addresses on each message.</p>
    <example caption='Querying for all messages to/from a particular JID'><![CDATA[
<iq type='set' id='juliet1'>
  <query xmlns='urn:xmpp:mam:2'>
    <x xmlns='jabber:x:data' type='submit'>
      <field var='FORM_TYPE' type='hidden'>
        <value>urn:xmpp:mam:2</value>
      </field>
      <field var='with'>
        <value>juliet@capulet.lit</value>
      </field>
    </x>
  </query>
</iq>
    ]]></example>
    <p>If (and only if) the supplied JID is a bare JID (i.e. no resource is present), then
    the server SHOULD return messages if their bare to/from address for a user archive, or from address otherwise, would match it. For example,
    if the client supplies a 'with' of "juliet@capulet.lit" a query to their own archive would also match messages to
    or from "juliet@capulet.lit/balcony" and "juliet@capulet.lit/chamber".</p>
    </section3>
    <section3 topic='Filtering by time received' anchor='filter-time'>
      <p>The 'start' and 'end' fields, if provided, MUST contain timestamps
      formatted according to the DateTime profile defined in &xep0082;</p>
      <p>The 'start' field is used to filter out messages before a certain date/time.
      If specified, a server MUST only return messages whose timestamp is equal to or later
      than the given timestamp.</p>
      <p>If omitted, the server SHOULD assume the value of 'start' to be equal to the
      date/time of the earliest message stored in the archive.</p>
      <p>Conversely, the 'end' field is used to exclude from the results messages
      after a certain point in time. If specified, a server MUST only return messages whose
      timestamp is equal to or earlier than the timestamp given in the 'end' field.</p>
      <p>If omitted, the server SHOULD assume the value of 'end' to be equal to the
      date/time of the most recent message stored in the archive.</p>
      <example caption='Querying the archive for all messages in a certain timespan'><![CDATA[
<iq type='set' id='juliet1'>
  <query xmlns='urn:xmpp:mam:2'>
    <x xmlns='jabber:x:data' type='submit'>
      <field var='FORM_TYPE' type='hidden'>
        <value>urn:xmpp:mam:2</value>
      </field>
      <field var='start'>
        <value>2010-06-07T00:00:00Z</value>
      </field>
      <field var='end'>
        <value>2010-07-07T13:23:54Z</value>
      </field>
    </x>
  </query>
</iq>
    ]]></example>
      <example caption='Querying the archive for all messages after a certain time'><![CDATA[
<iq type='set' id='juliet1'>
  <query xmlns='urn:xmpp:mam:2'>
    <x xmlns='jabber:x:data' type='submit'>
      <field var='FORM_TYPE' type='hidden'>
        <value>urn:xmpp:mam:2</value>
      </field>
      <field var='start'>
        <value>2010-08-07T00:00:00Z</value>
      </field>
    </x>
  </query>
</iq>
    ]]></example>
    </section3>
    <section3 topic='Limiting results' anchor='query-limit'>
      <p>Finally, in order for the client or server to limit the number of results transmitted at
      a time a server MUST support &xep0059; and MUST support the paging mechanism defined therein.
      A client MAY include a &lt;set/&gt; element in its query.</p>
      <p>For the purposes of this protocol, the UIDs used by RSM correspond with the UIDs of the
      stanzas stored in the archive.</p>
      <example caption='A query using Result Set Management'><![CDATA[
<iq type='set' id='q29302'>
  <query xmlns='urn:xmpp:mam:2'>
    <x xmlns='jabber:x:data' type='submit'>
      <field var='FORM_TYPE' type='hidden'>
        <value>urn:xmpp:mam:2</value>
      </field>
      <field var='start'>
        <value>2010-08-07T00:00:00Z</value>
      </field>
    </x>
    <set xmlns='http://jabber.org/protocol/rsm'>
      <max>10</max>
    </set>
  </query>
</iq>
    ]]></example>
    <p>To conserve resources, a server MAY place a reasonable limit on how many stanzas may be
    pushed to a client in one request. Whether or not the client query included a &lt;set/&gt; element, the server MAY simply return
    its limited results, modifying the &lt;set/&gt; element it returns appropriately.</p>
    <example caption='Server responds to client with limited results using RSM'><![CDATA[
<!-- result messages -->
<iq type='result' id='q29302'>
  <fin xmlns='urn:xmpp:mam:2'>
    <set xmlns='http://jabber.org/protocol/rsm'>
      <first index='0'>28482-98726-73623</first>
      <last>09af3-cc343-b409f</last>
      <count>20</count>
    </set>
  </fin>
</iq>
    ]]></example>
    <p>The &lt;first&gt; and &lt;last&gt; elements specify the UID of the first and last returned
    results (not necessarily of all the messages that matched the query, if the results have been limited).</p>

    <p>The RSM &lt;count&gt; element and the 'index' attribute on the RSM &lt;first&gt; element are optional,
    but servers SHOULD include them. Please refer to the RSM specification for more information
    surrounding their meaning and use.</p>
    </section3>
    <section3 topic='Paging through results' anchor='query-paging'>
      <p>Having previously made a query that returned results limited by the server (as described above), a client
      can re-send the same request and receive the next 'page' of results. It does this by including a &lt;set&gt;
      element with its request, containing an &lt;after/&gt; with the UID of the last message it received
      from the previous query.</p>
      <example caption='A page query using Result Set Management'><![CDATA[
<iq type='set' id='q29303'>
  <query xmlns='urn:xmpp:mam:2'>
      <x xmlns='jabber:x:data' type='submit'>
        <field var='FORM_TYPE' type='hidden'><value>urn:xmpp:mam:2</value></field>
        <field var='start'><value>2010-08-07T00:00:00Z</value></field>
      </x>
      <set xmlns='http://jabber.org/protocol/rsm'>
         <max>10</max>
         <after>09af3-cc343-b409f</after>
      </set>
  </query>
</iq>
    ]]></example>
    <p>Note: There is no concept of an "open query", and servers MUST be prepared to receive arbitrary page requests at any time.</p>
    <p>If the UID contained within an &lt;after&gt; or &lt;before&gt; element is not present in the archive, the server MUST return an item-not-found error in response to the query.</p>
    <p>When the results returned by the server are complete (that is: when they are the last page of the result set), the server MUST include a 'complete' attribute on the &lt;fin&gt; element, with a value of 'true'. If it is not the last page of the result set, the server MUST either omit the 'complete' attribute, or give it a value of 'false'.</p>
    <example caption='Server completes a result with the last page of messages'><![CDATA[
<!-- result messages -->
<iq type='result' id='u29303'>
  <fin xmlns='urn:xmpp:mam:2' complete='true'>
    <set xmlns='http://jabber.org/protocol/rsm'>
      <first index='0'>23452-4534-1</first>
      <last>390-2342-22</last>
      <count>16</count>
    </set>
  </fin>
</iq>
    ]]></example>
    <p>Sometimes (e.g. due to network or storage partitioning, or other transient errors) the server might return results to a client that are unstable (e.g. they might later change in sequence or content). In such a situation the server MUST stamp the &lt;fin&gt; element with a 'stable' attribute with a value of 'false'. If the server knows that the data it's serving are stable it MUST either stamp a 'stable' attribute with a value of 'true', or no such attribute. An example of when unstable might legitimately be returned is if the MAM service uses a clustered data store and a query covers a time period for which the data store has not yet converged; it the server could return best-guess results and tell the client that they may be unstable. A client SHOULD NOT cache unstable results long-term without later confirming (by reissuing appropriate queries) that they have become stable.</p>
    </section3>
		<section3 topic='Retrieving form fields' anchor='query-form'>
			<p>In order for the client find out about additional fields the server might support, it can send an iq stanza of type 'get' addressed to the archive like this:</p>
			<example caption="Client requests supported query fields"><![CDATA[
<iq type='get' id='form1'>
  <query xmlns='urn:xmpp:mam:2'/>
</iq>
]]></example>
			<p>The server replies with all the form fields it supports in queries, which MUST include the mandatory fields specified in this document.</p>
			<example caption="Server returns supported fields"><![CDATA[
<iq type='result' id='form1'>
  <query xmlns='urn:xmpp:mam:2'>
    <x xmlns='jabber:x:data' type='form'>
      <field type='hidden' var='FORM_TYPE'>
        <value>urn:xmpp:mam:2</value>
      </field>
      <field type='jid-single' var='with'/>
      <field type='text-single' var='start'/>
      <field type='text-single' var='end'/>
      <field type='text-single' var='urn:example:xmpp:free-text-search'/>
      <field type='text-single' var='urn:example:xmpp:stanza-content'/>
    </x>
  </query>
</iq>
]]></example>
<p>If the client understands any of the additional fields it MAY proceed to include any of them in subsequent queries. It is not required to include any or all of the supported fields in queries.</p>
			<example caption="Client uses two discovered query fields in a query"><![CDATA[
<iq type='set' id='query4'>
  <query xmlns='urn:xmpp:mam:2'>
    <x xmlns='jabber:x:data' type='submit'>
      <field type='hidden' var='FORM_TYPE'>
        <value>urn:xmpp:mam:2</value>
      </field>
      <field type='text-single' var='urn:example:xmpp:free-text-search'>
        <value>Where arth thou, my Juliet?</value>
      </field>
      <field type='text-single' var='urn:example:xmpp:stanza-content'>
        <value>{http://jabber.org/protocol/mood}mood/lonely</value>
      </field>
    </x>
  </query>
</iq>
]]></example>
		<p>Note that as the 'with', 'start' and 'end' fields MUST be implemented by servers, clients are able to submit forms using combinations of only these fields without needing to first fetch the form from the server and the types of these fields MUST be 'jid-single', 'text-single' and 'text-single' respectively. A server MUST NOT rely on a client having first requested the form before submitting queries</p>
		</section3>
  </section2>
  <section2 topic='Query results' anchor='results'>
    <p>The server responds to the archive query by transmitting to the client all the messages
       that match the criteria the client requested, subject to implementation limits. The results are sent as individual stanzas,
       with the original message encapsulated in a &lt;forwarded/&gt; element as described in &xep0297;.
    </p>
    <p>The result messages MUST contain a &lt;result/&gt; element with an 'id' attribute that gives
       the current message's archive UID (archived messages MAY also contain a XEP-0359 &lt;stanza-id&gt; element, but clients MUST NOT depend
       on it). If the client gave a 'queryid' attribute in its initial query, the server MUST also include that in this result element.
    </p>
    <p>The &lt;result/&gt; element contains a &lt;forwarded/&gt; element which SHOULD contain the
       original message as it was received, and SHOULD also contain a &lt;delay/&gt; element
       qualified by the 'urn:xmpp:delay' namespace specified in &xep0203;. The value of the 'stamp'
       attribute MUST be the time the message was originally received by the forwarding entity.
    </p>
    <p>The archive results MUST be sorted in chronological order, both within the returned results and within the ordering of RSM such that if a client were to request the first 10 stanzas in an archive, then use RSM to request the next 10 stanzas (by providing the 'after' element with the UID of the 10th stanza in the first results) all 20 result stanzas would be received in chronological order.
    </p>
    <example caption='Server returns two matching messages'><![CDATA[
<message id='aeb213' to='juliet@capulet.lit/chamber'>
  <result xmlns='urn:xmpp:mam:2' queryid='f27' id='28482-98726-73623'>
    <forwarded xmlns='urn:xmpp:forward:0'>
      <delay xmlns='urn:xmpp:delay' stamp='2010-07-10T23:08:25Z'/>
      <message xmlns='jabber:client'
        to='juliet@capulet.lit/balcony'
        from='romeo@montague.lit/orchard'
        type='chat'>
        <body>Call me but love, and I'll be new baptized; Henceforth I never will be Romeo.</body>
      </message>
    </forwarded>
  </result>
</message>

<message id='aeb214' to='juliet@capulet.lit/chamber'>
  <result xmlns='urn:xmpp:mam:2' queryid='f27' id='5d398-28273-f7382'>
    <forwarded xmlns='urn:xmpp:forward:0'>
      <delay xmlns='urn:xmpp:delay' stamp='2010-07-10T23:09:32Z'/>
      <message xmlns='jabber:client'
         to='romeo@montague.lit/orchard'
         from='juliet@capulet.lit/balcony'
         type='chat' id='8a54s'>
        <body>What man art thou that thus bescreen'd in night so stumblest on my counsel?</body>
      </message>
    </forwarded>
  </result>
</message>
    ]]></example>
  </section2>
</section1>

<section1 topic='Business Rules' anchor='business_rules'>
  <section2 topic='Storage and Retrieval Rules'>
  	<p>Different entities will have different requirements for which data are stored, as might different deployments. This section provides general rules within which a server will act. While there may be local policy restrictions that prevent archiving of some aspects discussed here, this is a RECOMMENDED baseline. A server MAY implement any subset of possible archives for JIDs it controls (although it MUST advertise support only for those JIDs that support it).</p>
	<p>No requirements are placed on how a server implements its storage beyond that it has to store data sufficient to be able to comply with this document. When this document describes storage requirements (e.g. MUST NOT store more than one copy...), it refers to what would appear to have been stored in order to satisfy the query.</p>
    <p>If an entity (user's server, MUC room, pubsub node, ...) rejects an incoming message (such as from an occupant not allowed to send messages to the room, a user not authorized to publish to a pubsub node, a contact blocked by the user etc.) that message should not appear in the archive for the entity that rejected it - the archive should represent what logical entities (MUC occupants, users, pubsub subscribers...) would have received, and so only contain messages accepted for delivery to such entities.</p>
  	<section3 topic="User Archives">
  		<p>A user archive is anticipated to provide the user with the ability to access their prior conversations. To this end, a server SHOULD include in a user archive all of the messages a user sends or receives of type 'normal' or 'chat' that contain a &lt;body&gt; element. A server SHOULD also include messages of type 'groupchat' that have a &lt;body&gt;, but where such history is accessible through another method (e.g. through an archive on the MUC JID), a server MAY exclude these from the archive. A server MAY include additional non-conversation messages. A server MAY include messages of type 'headline', but this is not generally suggested.</p>
  		<p>At a minimum, the server MUST store the &lt;body&gt; elements of a stanza. It is suggested that other elements that are used in a given deployment to supplement conversations (e.g. XHTML-IM payloads) are also stored. Other elements MAY be stored.</p>
  		<p>If a server supports mechanisms that multiply copies of a stanza (e.g. Carbons, or forking a stanza to a bare JID), it MUST store such a staza within a given archive only once, irrespective of multiple connected clients receiving copies</p>
  	</section3>
  	<section3 topic="MUC Archives">
  		<p>A MUC archives allows a user to view the conversation within a room. All messages sent to the room that contain a &lt;body&gt; element SHOULD be stored, as should subject change stanzas, apart from those messages that the room rejects.</p>
  		<p>A MUC archive MUST store each message only once (not, for example, every copy sent out to an occupant).</p>
                <p>A MUC archive MUST NOT include 'private message' results (those sent directly between occupants, not shared in the room) in the results</p>
                <p>A MUC archive MUST check that the user requesting the archive has the right to enter it at the time of the query and only allow access if so. In a members-only chat room, only owners, admins or members can query a room archive. In the case of open MUC rooms, the MUC archives can generally be accessed by any users (including those who have never entered the room) who do not have an affiliation of 'outcast', but a MUC archive MAY further limit access based on other criteria as part of the deployment policy. A MUC archive MAY, if it stores historical data about previous configuration states, limit the results returned to only those that the querying user would have been authorised to see at the time (e.g. it MAY limit the results to not include results while a user was an outcast).</p>
  		<p>When sending out the archives to a requesting client, the 'to' of the forwarded stanza MUST be empty, and the 'from' MUST be the occupant JID of the sender of the archived message.</p>
                <p>In the case of non-anonymous rooms or if the recipient of the MUC archive has the right to access the sender real JID at the time of the query, the archive message will use extended message information in an &lt;x/&gt; element qualified by the 'http://jabber.org/protocol/muc#user' namespace and containing an &lt;item/&gt; child with a 'jid' attribute specifying the occupant's full JID, as defined for non-anonymous room presence in &xep0045;. The archiving entity MUST strip any pre-existing &lt;x&gt; element from MUC messages (as MUC rooms are not required to do this).</p>
                <example caption='Server returns MUC messages'><![CDATA[
<message id='iasd207' from='coven@chat.shakespeare.lit' to='hag66@shakespeare.lit/pda'>
  <result xmlns='urn:xmpp:mam:2' queryid='g27' id='34482-21985-73620'>
    <forwarded xmlns='urn:xmpp:forward:0'>
      <delay xmlns='urn:xmpp:delay' stamp='2002-10-13T23:58:37Z'/>
      <message xmlns="jabber:client"
        from='coven@chat.shakespeare.lit/firstwitch'
        id='162BEBB1-F6DB-4D9A-9BD8-CFDCC801A0B2'
        type='groupchat'>
        <body>Thrice the brinded cat hath mew'd.</body>
        <x xmlns='http://jabber.org/protocol/muc#user'>
          <item affiliation='none'
                jid='witch1@shakespeare.lit'
                role='participant' />
        </x>
      </message>
    </forwarded>
  </result>
</message>

<message id='iasd207' from='coven@chat.shakespeare.lit' to='hag66@shakespeare.lit/pda'>
  <result xmlns='urn:xmpp:mam:2' queryid='g27' id='34482-21985-73620'>
    <forwarded xmlns='urn:xmpp:forward:0'>
      <delay xmlns='urn:xmpp:delay' stamp='2002-10-13T23:58:43Z'/>
      <message xmlns="jabber:client"
        from='coven@chat.shakespeare.lit/secondwitch'
        id='90057840-30FD-4141-AA44-103EEDF218FC'
        type='groupchat'>
        <body>Thrice and once the hedge-pig whined.</body>
        <x xmlns='http://jabber.org/protocol/muc#user'>
          <item affiliation='none'
                jid='witch2@shakespeare.lit'
                role='participant' />
        </x>
      </message>
    </forwarded>
  </result>
</message>
                ]]></example>
  	</section3>
  	<section3 topic="Pubsub Archives">
  		<p>A PubSub service offering MAM SHOULD store each of the items published to each node. When responding to MAM requests it MUST construct the message stanza within the &lt;forwarded&gt; element in the same manner as the notifications sent to subscribers for the item, except that specifying the 'from' 'to' and 'id' attributes are OPTIONAL. Pubsub items must be returned one per message stanza (i.e. there MUST NOT be multiple &lt;item&gt; elements within the &lt;items&gt; element).</p>
  		<example caption='Server returns a pubsub messages'><![CDATA[
<message id='iasd208' to='juliet@capulet.lit/chamber'>
  <result xmlns='urn:xmpp:mam:2' queryid='g28' id='28482-20987-73623'>
    <forwarded xmlns='urn:xmpp:forward:0'>
      <delay xmlns='urn:xmpp:delay' stamp='2010-07-10T23:08:25Z'/>
      <message xmlns="jabber:client">
		  <event xmlns='http://jabber.org/protocol/pubsub#event'>
		    <items node='princely_musings'>
		      <item id='ae890ac52d0df67ed7cfdf51b644e901'>
		        <entry xmlns='http://www.w3.org/2005/Atom'>
		          <title>Soliloquy</title>
		          <summary>
					To be, or not to be: that is the question:
					Whether 'tis nobler in the mind to suffer
					The slings and arrows of outrageous fortune,
					Or to take arms against a sea of troubles,
					And by opposing end them?
		          </summary>
		          <link rel='alternate' type='text/html'
		                href='http://denmark.lit/2003/12/13/atom03'/>
		          <id>tag:denmark.lit,2003:entry-32397</id>
		          <published>2003-12-13T18:30:02Z</published>
		          <updated>2003-12-13T18:30:02Z</updated>
		        </entry>
		      </item>
		    </items>
		  </event>
		</message>
    </forwarded>
  </result>
</message>]]></example>
  </section3>

  </section2>
  <section2 topic='IDs'>
        <p>The IDs used within an archive MUST be unique per item stored and MUST NOT be reused, even if the original item with a given ID has since been removed from the archive. If a server provides multiple archives (e.g. many user archives, or many MUC archives), the IDs do not need to be unique across all of these archives unless the server also allows a single query to be run across multiple archives (e.g. searching of all MUC rooms), discussion of which is beyond the scope of this document. These IDs are strings that servers may construct in any manner, and clients must treat as opaque strings (e.g. there is no requirement for them to be numeric, sequenced or GUIDs).</p>
  </section2>
  <section2 topic='Client synchronization' anchor='sync'>
    <p>In addition to one-off queries, clients may use this protocol to synchronize a local archive with the server's archive. However
       because this protocol is detached from normal routing of messages, it is possible that a client will receive messages while trying
       to synchronize, which has the potential to cause duplicated messages. Resolving this is beyond the scope of this specification,
       but may instead be solved during the initial connection phase by using an alternative connection protocol such as &xep0386;.</p>
  </section2>
</section1>

<section1 topic='Archiving Preferences' anchor='prefs'>
  <p>Depending on implementation and deployment policies, a server MAY allow the user to have control
  over the server's archiving behaviour. This specification defines a basic protocol for this, and
  also allows a server to offer more advanced configuration to a user.</p>
  <section2 topic='Simple configuration' anchor='config'>
    <p>If the server supports and allows configuration of the preferences described below then it SHOULD implement the protocol defined
    in this section. This allows the user to retrieve and configure the following preferences:</p>
    <ul>
      <li>A list of JIDs that should always have messages to/from archived in the user's store.</li>
      <li>A list of JIDs that should never have messages to/from archived in the user's store.</li>
      <li>The default archiving behaviour (for JIDs in neither of the above lists).</li>
    </ul>
    <example caption='Retrieving archiving preferences'><![CDATA[
<iq type='get' id='juliet2'>
  <prefs xmlns='urn:xmpp:mam:2'/>
</iq>
]]></example>

    <p>The server replies with the user's current archiving preferences. The &lt;prefs&gt; element
    MUST be present and contain the current default archiving policy. The &lt;always&gt; and &lt;never&gt;
    MUST also be present (even if empty), and contain a list of JIDs enclosed in &lt;jid&gt; elements.</p>

    <example caption='Server responds with current preferences'><![CDATA[
<iq type='result' id='juliet2'>
  <prefs xmlns='urn:xmpp:mam:2' default='roster'>
    <always/>
    <never/>
  </prefs>
</iq>
]]></example>

    <p>It is also possible that the server may respond with a stanza error, for example the standard
    'feature-not-implemented' (server does not support MAM configuration) defined in &rfc6120;.</p>

    <example caption='Server does not support archive configuration'><![CDATA[
<iq type='error' id='juliet2'>
  <error type='cancel'>
    <feature-not-implemented xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'/>
  </error>
</iq>
]]></example>

    <p>To update the preferences, the client can simply send an iq stanza with a type of 'set':</p>

    <example caption='Updating archiving preferences'><![CDATA[
<iq type='set' id='juliet3'>
  <prefs xmlns='urn:xmpp:mam:2' default='roster'>
    <always>
      <jid>romeo@montague.lit</jid>
    </always>
    <never>
      <jid>montague@montague.lit</jid>
    </never>
  </prefs>
</iq>
]]></example>
  <p>The server then replies with the applied preferences (note that due to server policies these
  MAY be different to the preferences sent by the client):</p>
<example caption='Server responds with updated preferences'><![CDATA[
<iq type='result' id='juliet3'>
  <prefs xmlns='urn:xmpp:mam:2' default='roster'>
    <always>
      <jid>romeo@montague.lit</jid>
    </always>
    <never>
      <jid>montague@montague.lit</jid>
    </never>
  </prefs>
</iq>
]]></example>

  <p>It is also possible for the server to respond with an error, for example (but not limited to)
  the standard 'feature-not-implemented' (the server does not support configuration of preferences),
  'forbidden' (the user is not authorized to change their preferences) or 'not-allowed' (the server
  generally does not allow changing of configuration preferences).</p>

    <section3 topic='Default behaviour' anchor='config-default'>
      <p>If a JID is in neither the 'always archive' nor the 'never archive' list then whether it
         is archived depends on this setting, the default.
      </p>
      <p>The 'default' attribute of the 'prefs' element MUST be one of the following values:</p>
      <ul>
        <li>'always' - all messages are archived by default.</li>
        <li>'never' - messages are never archived by default.</li>
        <li>'roster' - messages are archived only if the contact's bare JID is in the user's roster.</li>
      </ul>
    </section3>
    <section3 topic='Always archive' anchor='config-always'>
      <p>The &lt;prefs/&gt; element MAY contain an &lt;always/&gt; child element. If present, it
         contains a list of &lt;jid/&gt; elements, each containing a single JID. The server SHOULD
         archive any messages to/from this JID (see 'JID matching').
      </p>
      <p>If missing from the preferences, &lt;always/&gt; SHOULD be assumed by the server to be an
         empty list.
      </p>
    </section3>
    <section3 topic='Never archive' anchor='config-never'>
      <p>The &lt;prefs/&gt; element MAY contain an &lt;never/&gt; child element. If present, it
         contains a list of &lt;jid/&gt; elements, each containing a single JID. The server SHOULD
         NOT archive any messages to/from this JID (see 'JID matching').
      </p>
      <p>If missing from the preferences, &lt;never/&gt; SHOULD be assumed by the server to be an
         empty list.
      </p>
    </section3>
  </section2>
  <section2 topic='Advanced configuration' anchor='advanced-config'>
    <p>In addition to this protocol, a server MAY offer more advanced configuration to the user
       through &xep0050;. Such an interface might, for example, allow the user to configure what
       types of messages to store, or set a limit on how long messages should remain in the
       archive.</p>
    <p>If supported, such a configuration command SHOULD be presented on the well-defined
       command node of "urn:xmpp:mam#configure".</p>
  </section2>
  <section2 topic='JID matching' anchor='match'>
    <section3 topic='General rules' anchor='match-rules'>
      <p>When comparing the message target JID against the user's roster (ie. when the user has
         set default='roster') the comparison MUST use the bare target JID (that is, stripped of
         any resource).
      </p>
      <p>For matching against entries in either the 'allow' or 'never' lists, for each listed
         JID:
      </p>
      <ul>
        <li>If the listed JID contains a resource, compare against the target JID as-is.</li>
        <li>If the listed JID has no resource (it is a bare JID) then first strip any resource
            from the target JID prior to comparison.
        </li>
      </ul>
    </section3>
    <section3 topic='Outgoing messages' anchor='match-out'>
      <p>For outgoing messages, the server MUST use the value of the 'to' attribute as the target JID.
      </p>
    </section3>
    <section3 topic='Incoming messages' anchor='match-in'>
      <p>For incoming messages, the server MUST use the value of the 'from' attribute as the target JID.
      </p>
    </section3>
  </section2>
	<section2 topic='Processing Hints' anchor='hints'>
		<p>Clients can use &xep0334; for signaling that they do not wish some messages to be stored in the archive.</p>
		<example><![CDATA[
<message from='romeo@montague.lit/laptop' to='juliet@capulet.lit/laptop'>
  <body>V unir avtug'f pybnx gb uvqr zr sebz gurve fvtug</body>
  <no-store xmlns='urn:xmpp:hints'/>
</message>
			]]></example>
	</section2>
</section1>

<section1 topic='Determining support' anchor='support'>
        <p>If a server or other entity hosts archives and supports MAM queries, it MUST advertise
          the 'urn:xmpp:mam:2' feature in response to &xep0030; requests made to archiving JIDs
          (i.e. JIDs hosting an archive, such as users' bare JIDs):
        </p>
<example caption='Client queries for server features'><![CDATA[
<iq type='get' id='disco1' to='juliet@capulet.lit' from='juliet@capulet.lit/balcony'>
  <query xmlns='http://jabber.org/protocol/disco#info'/>
</iq>
]]></example>

<example caption='Server responds with features'><![CDATA[
<iq type='result' id='disco1' from='juliet@capulet.lit' to='juliet@capulet.lit/balcony'>
	<query xmlns='http://jabber.org/protocol/disco#info'>
		...
		<feature var='urn:xmpp:mam:2'/>
		...
	</query>
</iq>
]]></example>
</section1>

<section1 topic='Security Considerations' anchor='security'>
  <section2 topic='Data privacy' anchor='security-privacy'>
    <p>An archive generally consists of private conversations, and so
    a server MUST adequately protect an archive from unauthorized third-party
    access. For example authorized parties for a user's archive would likely include
    just the user, and a MUC archive for a private room might be restricted
    to room members. An implementation MAY choose to allow access to any archive
    by server administrators. If a client
	requests access to an archive is does not have permissions for the server MUST
	return an iq with type error, and the error condition SHOULD be 'forbidden'.</p>
    <p>A server SHOULD provide a mechanism for a user to disable archiving of
    messages with all or specific contacts, such as via the configuration
    protocol described in this document. This allows the user to prevent the
    archiving of potentially sensitive messages in the first place.</p>
    <p>A server MAY automatically prevent certain sensitive messages from being
    archived. How such messages are identified is beyond the scope of this
    specification, but technologies such as &xep0258; may be used, for example.</p>
  </section2>
  <section2 topic='Stanza IDs' anchor='security-stanza-ids'>
    <p>Entities that implement this specification must also adhere to the security requirements of XEP-0359.</p>
  </section2>
  <section2 topic='MUC message spoofing'>
    <p>This specification re-uses the &lt;x&gt; element from the 'http://jabber.org/protocol/muc#user' namespace to convey information about the sender of a message in a MUC room. However this element is not sanitized by MUC services, so the archiving entity MUST strip any existing &lt;x&gt; element in the 'http://jabber.org/protocol/muc#user' namespace from messages before archiving them (regardless of whether it adds in its own &lt;x&gt; element).</p>
  </section2>
</section1>

<section1 topic='XMPP Registrar Considerations' anchor='registrar'>
</section1>

<section1 topic='Acknowledgements' anchor='acks'>
        <p>Many thanks to Dave Cridland, Kim Alvefur, Yann Leboulanger, Evgeny Khramtsov, Florian Schmaus, Lance Stout,
       Waqas Hussain and Daniel Gultsch for their input and feedback on this specification.</p>
</section1>

</xep>