moparisthebest
/
xeps
mirror of https://github.com/moparisthebest/xeps
1
0
Fork 0
Code Issues Releases Wiki Activity

XEP-0393: updates based on LC feedback

This commit is contained in:
Sam Whited 2020-06-01 11:30:25 -04:00
parent caa2ad41ef
commit 13631dd0d4
1 changed files with 104 additions and 3 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

107
xep-0393.xml
View File

@ -26,6 +26,18 @@
<supersededby/>
<shortname>styling</shortname>
&sam;
<revision>
<version>0.3.0</version>
<date>2020-06-02</date>
<initials>ssw</initials>
<remark>
<p>
Add ability to disable styling, further clarify accessibility
considerations, and mention that Styling is not Markdown in the security
considerations section.
</p>
</remark>
</revision>
<revision>
<version>0.2.2</version>
<date>2020-05-20</date>
@ -255,6 +267,19 @@
</di>
</dl>
</section1>
<section1 topic='Discovering Support' anchor='disco'>
<p>
Clients that support message styling MUST advertise the fact by including a
feature of "urn::xmpp:styling:0" in response to &xep0030; information
requests and in their &xep0115; profiles.
</p>
<example caption='Disco info response'><![CDATA[
<query xmlns='http://jabber.org/protocol/disco#info'>
…
<feature var='urn:xmpp:styling:0' />
…
</query>]]></example>
</section1>
<section1 topic='Business Rules' anchor='rules'>
<section2 topic='Blocks' anchor='block'>
<p>
@ -441,6 +466,39 @@
</section3>
</section2>
</section1>
<section1 topic='Disabling Styling' anchor='disable'>
<p>
On rare occasions styling hints may conflict with the contents of a message.
For example, if the user sends the emoji "&gt; _ &lt;" it would be
interpreted as a block quote.
</p>
<section2 topic='Individual Directives'>
<p>
To remove styling without removing the styling directives, a whitespace
character can be inserted after the opening styling directive and before
the closing styling directive (if applicable).
This whitespace character SHOULD be U+2060 WORD JOINER to prevent line
breaks between the character that was misinterpreted as a styling
directive and the text that it would otherwise style.
</p>
</section2>
<section2 topic='Entire Messages'>
<p>
An entire message may also have styling disabled to remove the need to
parse the message for styling in the first place.
Senders may indicate to the receiver that a particular message SHOULD NOT
be styled by adding an empty &lt;unstyled&gt; element qualified by the
"urn:xmpp:styling:0" namespace.
</p>
<example caption='Sender indicates that styling is disabled'><![CDATA[
<message>
<body>&gt; _ &lt;</body>
<unstyled xmlns="urn:xmpp:styling:0"/>
</message>
]]></example>
</section2>
</section1>
<section1 topic='Implementation Notes' anchor='impl'>
<p>
This document does not define a regular grammar and thus styling cannot be
@ -467,9 +525,12 @@
text more difficult to read for visually impaired users.
</p>
<p>
Styled text may also be rendered poorly by screen readers.
Styled text may be rendered poorly by screen readers.
When applying formatting it may be desirable to include directives to
exclude styling directives from being read.
exclude styling directives from being read, or to add markers to the final
output that have semantic meaning for screen readers.
For example, in an web based client an emphasis span might be converted to
an HTML &lt;em&gt; element.
</p>
</section1>
<section1 topic='Security Considerations' anchor='security'>
@ -477,6 +538,13 @@
Authors of message styling parsers should take care that improperly
formatted messages cannot lead to buffer overruns or code execution.
</p>
<p>
Though message styling is not compatible with Markdown, some of its styles
are similar.
Markdown parsers often allow arbitrary HTML to be inserted into documents
and therefore MUST NOT be used to parse the format defined in this document
even if they are flexible enough to do so.
</p>
</section1>
<section1 topic='IANA Considerations' anchor='iana'>
<p>
@ -484,7 +552,40 @@
</p>
</section1>
<section1 topic='XMPP Registrar Considerations' anchor='registrar'>
<p>This specification requires no interaction with the &REGISTRAR;</p>
<section2 topic='Protocol Namespaces' anchor='registrar-ns'>
<p>This specification defines the following XML namespace:</p>
<ul>
<li>urn:xmpp:styling:0</li>
</ul>
<p>
Upon advancement of this specification from a status of Experimental to a
status of Draft, the &REGISTRAR; shall add the foregoing namespace to the
registries located at &DISCOFEATURES;, as described in Section 4 of
&xep0053;.
</p>
<code caption='Service Discovery Features Registry Submission'><![CDATA[
<var>
<name>urn:xmpp:styling:0</name>
<desc>Support for rendering message styling.</desc>
<doc>&xep0393;</doc>
</var>]]></code>
<p>
The &REGISTRAR; shall also add the foregoing namespace to the Jabber/XMPP
Protocol Namespaces Registry located at &NAMESPACES;.
Upon advancement of this specification from a status of Experimental to a
status of Draft, the &REGISTRAR; shall remove the provisional status from
this registry entry.
</p>
<code caption='Jabber/XMPP Protocol Namespaces Registry Submission'><![CDATA[
<ns>
<name>urn:xmpp:styling:0</name>
<doc>&xep0393;</doc>
<status>provisional</status>
</ns>]]></code>
</section2>
<section2 topic='Namespace Versioning' anchor='registrar-versioning'>
&NSVER;
</section2>
</section1>
<section1 topic='XML Schema' anchor='schema'>
<p>This document does not define any new XML structure requiring a schema.</p>