Merge branches 'merge/xep-0156', 'merge/xep-0167', 'merge/xep-0260', 'merge/xep-0261', 'merge/xep-0284', 'merge/xep-0313', 'merge/xep-0333' and 'merge/xep-0410'

This commit is contained in:
Jonas Schäfer 2019-02-20 16:10:18 +01:00
8 changed files with 34 additions and 10 deletions

View File

@ -25,6 +25,12 @@
&hildjj;
&stpeter;
&lance;
<revision>
<version>1.2.0</version>
<date>2019-02-20</date>
<initials>wk</initials>
<remark><p>Add information about CORS header usage and requirements</p></remark>
</revision>
<revision>
<version>1.1.5</version>
<date>2018-09-30</date>
@ -231,7 +237,14 @@ _xmppconnect IN TXT "_xmpp-client-websocket=wss://web.example.com:443/ws"
]]></example>
</section2>
</section1>
<section1 topic='Implementation Notes' anchor='impl'>
<p>To make connection discovery work in web clients (including those hosted on a different domain) the host service SHOULD set appropriate <link url="https://www.w3.org/TR/cors/">CORS</link> headers for Web Host Metadata files. The exact headers and values are out of scope of this document but may include: <em>Access-Control-Allow-Origin</em>, <em>Access-Control-Allow-Methods</em> and <em>Access-Control-Allow-Headers</em>.</p>
<p>Due care has to be exercised in limiting the scope of <em>Access-Control-Allow-Origin</em> response header to Web Host Metadata files only.</p>
<code caption="Example header allowing all sites to read host metadata"><![CDATA[
Access-Control-Allow-Origin: *
]]></code>
<p class="box"><em>Access-Control-Allow-Origin</em> header with a value of <em>*</em> allows JavaScript code running on a different domain to read the content of Web Host Metadata files. Special value <em>*</em> ensures that the request will only succeed if it is <link url="https://www.w3.org/TR/cors/#resource-requests">invoked without user credentials</link> (e.g. cookies, HTTP authentication).</p>
</section1>
<section1 topic='Security Considerations' anchor='security'>
<p>It is possible that advertisement of alternative connection methods can introduce security vulnerabilities, since a connecting entity (usually a client) might deliberately seek to connect using the method with the weakest security mechanisms (e.g., no channel encryption or relatively weak authentication). Care needs to be taken in determining which alternative connection methods are appropriate to advertise.</p>
<p>Entities that use these connection methods MUST conform to the security considerations of each method, for example by preferring to use 'https' or 'wss' URLs that are protected using Transport Layer Security (TLS).</p>

View File

@ -1592,7 +1592,7 @@ Romeo Juliet
to='romeo@montague.lit/orchard'
type='set'>
<jingle xmlns='urn:xmpp:jingle:1'
action='session-info'
action='content-modify'
initiator='romeo@montague.lit/orchard'
sid='a73sjjvkla37jfea'>
<content creator='initiator' name='webcam' senders='both'/>

View File

@ -248,7 +248,6 @@ Initiator Responder
<description xmlns='urn:xmpp:example'/>
<transport xmlns='urn:xmpp:jingle:transports:s5b:1'
dstaddr='1a12fb7bc625e55f3ed5b29a53dbe0e4aa7d80ba'
mode='tcp'
sid='vj3hs98y'>
<candidate cid='ht567dq'
host='192.169.1.10'

View File

@ -260,7 +260,7 @@ Initiator Responder
type='set'>
<open xmlns='http://jabber.org/protocol/ibb'
block-size='2048'
sid='pd51xa96'
sid='bt8a71h6'
stanza='iq'/>
</iq>
]]></example>

View File

@ -33,6 +33,12 @@
<surname>Pusateri</surname>
<email>pusateri@bangj.com</email>
</author>
<revision>
<version>0.1.1</version>
<date>2019-02-20</date>
<initials>ka</initials>
<remark><p>Fix use of incorrect namespace in examples</p></remark>
</revision>
<revision>
<version>0.1</version>
<date>2010-07-02</date>
@ -265,13 +271,13 @@
to='kingclaudius@shakespeare.lit/castle'
id='disco1'>
type='get'>
<query xmlns='http://xmpp.org/protocol/disco#info'/>
<query xmlns='http://jabber.org/protocol/disco#info'/>
</iq>
]]></example>
<p>If the host supports Shared XML Editing over XMPP, it MUST return features of "urn:xmpp:sxe:0" and "urn:xmpp:jingle:transports:sxe" &NSNOTE;:</p>
<example caption='Service discovery response'><![CDATA[
<iq from='laertes@shakespeare.lit/castle' to='kingclaudius@shakespeare.lit/castle' type='result' id='disco1'>
<query xmlns='http://xmpp.org/protocol/disco#info'>
<query xmlns='http://jabber.org/protocol/disco#info'>
<identity category='client' type='pc'/>
...
<feature var='urn:xmpp:sxe:0'/>

View File

@ -53,7 +53,7 @@
<date>2017-02-17</date>
<initials>dg, mw</initials>
<remark>
<p>Namespace bump</p>
<p>Namespace bump from mam:1 to mam:2</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>

View File

@ -156,7 +156,7 @@
<p>If the sender determines that the recipient's client supports the Chat Markers protocol then it MAY send a Chat Marker or markable message to that full JID.</p>
</section2>
<section2 topic='Chat Marker' anchor='when-chat-marker'>
<p>To prevent looping, an entity MUST NOT send a Chat Maker to mark up to a Chat Marker.</p>
<p>To prevent looping, an entity MUST NOT send a Chat Marker to mark up to a Chat Marker.</p>
</section2>
</section1>
@ -211,7 +211,7 @@
<p>Clients SHOULD use &xep0136; or &xep0313; to support offline updating of Chat Markers. Chat Markers SHOULD be archived, so they can be fetched and set regardless of whether the other users in a chat are online.</p>
<p>Messages MUST have an 'id' to use Chat Markers.</p>
<p>Messages MUST include the 'markable' element to use Chat Markers.</p>
<p>Chat Markers MUST only move forward. If a Chat Maker is received for an earlier message than the current Chat Marker, it MUST be ignored by the client.
<p>Chat Markers MUST only move forward. If a Chat Marker is received for an earlier message than the current Chat Marker, it MUST be ignored by the client.
</p>
<p>Chat Markers for unknown messages MUST be ignored by the client. A client MAY store the Chat Marker incase the associated message is retrieved later.
</p>

View File

@ -29,6 +29,12 @@
<email>georg@op-co.de</email>
<jid>georg@yax.im</jid>
</author>
<revision>
<version>0.3.0</version>
<date>2019-02-20</date>
<initials>gl</initials>
<remark>Incorporate council feedback: use @by on error elements</remark>
</revision>
<revision>
<version>0.2.0</version>
<date>2019-02-04</date>
@ -140,7 +146,7 @@
<example caption="Server Response to a Non-Occupant"><![CDATA[
<iq from='characters@chat.shakespeare.lit/JuliC' id='s2c1' type='error'
to='juliet@capulet.lit/client' >
<error type="cancel">
<error type="cancel" by="characters@chat.shakespeare.lit">
<not-acceptable xmlns="urn:ietf:params:xml:ns:xmpp-stanzas" />
</error>
</iq>