<remark><p>Adding discovery, as discussed as a prerequisite to acceptance with Council.</p></remark>
</revision>
<revision>
<version>0.0.1</version>
<date>2010-07-20</date>
<initials>kis</initials>
<remark><p>First draft.</p></remark>
</revision>
</header>
<section1topic='Introduction'anchor='intro'>
<p>When sending a message, people often introduce typing errors and send a follow-up message to correct them. This specification allows the sending client to flag the second message as correcting the first.</p>
<p>If a server implements message correction, it MUST specify the 'urn:xmpp:message-correct:0' feature in its service discovery information features as specified in &xep0030; and the Entity Capabilities profile specified in &xep0115;.</p>
<examplecaption='Client requests information about a chat partner's client'><![CDATA[
<p>When a user indicates to the client that he wants to correct the most recently sent message to a contact, the client will resend the corrected message with a new id, and with the replace payload refering to the previous message by id.</p>
<examplecaption='User sends a message with a mistake in'><![CDATA[
<messageto='juliet@capulet.net/balcony'id='bad1'>
<body>But soft, what light through yonder airlock breaks?</body>
</message>]]></example>
<examplecaption='User corrects the message and sends'><![CDATA[
<p>The 'id' attribute is included on the replace to prevent situations where messages being routed to a different resource than the intended cause incorrect replacements.</p>
<p>A receiving client can choose to replace the previous message in whatever display is used for messages, or in any stored history, or can choose to display the correction in another way.</p>
<p>A client SHOULD alert the user that the displayed message has been edited since it was originally sent.</p>
<p>Clients MUST send ids on messages if they allow the user to correct messages.</p>
<p>To deal with multiple payloads, the sender MUST re-send the entire stanza with only the id and the corrections changed. It is expected that the receiver will then treat the new stanza as complete replacement, but such logic is ultimately the resposibility of the client.</p>
<p> The Sender MUST NOT include a correction for a message with non-messaging payloads. For example, a sender MUST NOT include a correction for a roster item exchange request.</p>
<p>The replacement message could have an entirely different meaning from the original message, so clients will need to warn users that the displayed message has been edited.</p>
<p>Upon advancement of this specification, the ®ISTRAR; shall issue permanent namespaces in accordance with the process defined in Section 4 of &xep0053;.</p>
<p>The following namespaces are requested, and are thought to be unique per the XMPP Registrar's requirements:</p>