XEP-0070: Mention a plaintext fallback

In the previous version, an entity requesting XEP-0070 validation could
add a <body/> element to the <message/> sent, which would be displayed
in any client (which may not support this XEP). If the client does not
support the XEP, and the entity does not support a plaintext fallback,
the client would be prompted to act, without any result being possible
(as the wording says that the <confirm/> element must be sent back as
well).

This change suggests that an entity adding a body should implement this
kind of fallback (which may be as dumb as "ok/nok", as long as the
<body/> element is clear enough).
This commit is contained in:
mathieui 2016-08-19 20:48:01 +02:00 committed by Sam Whited
parent 475fa51d7e
commit 50c04ec143
1 changed files with 1 additions and 1 deletions

View File

@ -218,7 +218,7 @@ Authorization: Digest username="juliet@capulet.com",
<p>Upon receiving the JID and transaction identifier from the HTTP Server, the XMPP Server MUST send a confirmation request (via XMPP) to the XMPP Client (or route the confirmation request generated by the HTTP Server acting as a trusted XMPP server component).</p>
<p>The confirmation request shall consist of an empty &lt;confirm/&gt; element qualified by the ''http://jabber.org/protocol/http-auth' namespace. This element MUST possess a 'method' attribute whose value is the method of the HTTP request, MUST possess a 'url' attribute whose value is the full HTTP URL that was requested, and MUST possess an 'id' attribute whose value is the transaction identifier provided in the HTTP Authorization Request.</p>
<p>If the JID provided was a full JID, the confirmation request SHOULD be sent in an &IQ; stanza of type "get" whose 'to' attribute is set to the full JID, but MAY be sent in a &MESSAGE; stanza.</p>
<p>If the JID provided was a bare JID, the confirmation request MUST be sent in a &MESSAGE; stanza whose 'to' attribute is set to the bare JID; this enables delivery to the "most available" resource for the user (however "most available" is determined by the XMPP Server). The &MESSAGE; stanza SHOULD include a &THREAD; element for tracking purposes and MAY include a &BODY; element that provides human-readable information or instructions.</p>
<p>If the JID provided was a bare JID, the confirmation request MUST be sent in a &MESSAGE; stanza whose 'to' attribute is set to the bare JID; this enables delivery to the "most available" resource for the user (however "most available" is determined by the XMPP Server). The &MESSAGE; stanza SHOULD include a &THREAD; element for tracking purposes and MAY include a &BODY; element that provides human-readable information or instructions. If it however provides a &BODY;, the server SHOULD be able to handle a plaintext reply from the client, in the case where it does not support this XEP.</p>
<example caption='Confirmation Request Sent via IQ'><![CDATA[
<iq type='get'
from='files.shakespeare.lit'