moparisthebest/xeps
1
0
Fork 0
mirror of https://github.com/moparisthebest/xeps synced 2024-11-21 16:55:07 -05:00
Code Issues Releases Wiki Activity

Typos from Jonas Wielickig

Browse Source
This commit is contained in:
Steve Kille 2017-02-19 15:20:09 +00:00 committed by Sam Whited
parent 11e4febde5
commit 9b58aac74e
1 changed files with 15 additions and 15 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

24
xep-0369.xml
View File

@ -359,7 +359,7 @@ This approach enables flexible support of multiple clients for a MIX channel pa
The primary representation of a participant in a MIX channel is a proxy JID, which is an anonymized JID using the same domain as the channel and with the name of the channel encoded, using the format "<channel>+<generated identifier>@<mix domain>". They generated identifier MUST NOT contain the '+' characters. The Channel name MAY contain the '+' character. For example in the channel 'coven@mix.shakespeare.example', the user 'hag66@shakespeare.example' might have a proxy JID of 'coven+123456@mix.shakespeare.example'. The reason for the proxy JID is to support JID Hidden channels. Proxy JIDs are also used in JID Visible channels, for consistency and to enable switching of JID visibility. The "urn:xmpp:mix:nodes:jidmap" node maps from proxy JID to real JID. While a user is a participant in a Channel, the mapping between real JID and proxy JID MUST NOT be changed.
</p>
<p>
The example real full JIDs in this specification follow the anticipated new format that splits the resource into two parts. The first part is UUID that is a stable and fixed value for the client. The second part is server assigned and will vary with each session. For example: 'hag66@shakespeare.example/d104f6a7-97e9-477f-8947-e4a37691d7ee/7533375f-2cd1-4455-a311-494bab21f9f0'. CITATION TO BE ADDED. If the final specification differs from this, the examples will be updated.
The example real full JIDs in this specification follow the anticipated new format that splits the resource into two parts. The first part is UUID that is a stable and fixed value for the client. The second part is server assigned and will vary with each session. For example: 'hag66@shakespeare.example/d104f6a7-97e9-477f-8947-e4a37691d7ee/7533375f-2cd1-4455-a311-494bab21f9f0'. CITATION TO BE ADDED. If the final specification differs from this, the examples will be updated. It is intended to use shorter values if possible, as long as this complies with recommendations of the specifications.
</p>
<p>
The full JIDs held in the presence nodes are anonymized using a similar mechanism. First the bare JID is mapped to a bare proxy JID, using the mapping held in the "urn:xmpp:mix:nodes:jidmap" node for the bare JID. Then the resource is replaced with a generated value. For example, 'hag66@shakespeare.example/d104f6a7-97e9-477f-8947-e4a37691d7ee/7533375f-2cd1-4455-a311-494bab21f9f0' in the channel coven might have a proxy JID of 'coven+123456@mix.shakespeare.example/789'. There is no client visible mapping of proxy full JIDs maintained as this is not needed. The MIX channel will need to maintain a mapping, to support directly addressing clients, such as for client to client disco#info queries. While an anonymized JID is held in the presence node, the mapping to real JID MUST NOT be changed. When an anonoymized full JID is added to the presence node, mapping to a real full JID that was previously in the presence node, the same anonymized JID as the previous time MAY be used or a different anonymized JID MAY be used.
@ -608,7 +608,7 @@ This approach enables flexible support of multiple clients for a MIX channel pa
</p>
<ol>
<li>IQ. All of the IQ errors of &rfc6120; MUST be supported.</li>
<li>Messages. If a message is received and an error situation is encountered, an message of type error MUST be sent back to the message sender of type error specified in &rfc6121; containing an error defined in &rfc6120;, which is the same error set as for IQs.</li>
<li>Messages. If a message is received and an error situation is encountered, an message of type error MUST be sent back to the message sender. This message format is specified in &rfc6121; containing an error defined in &rfc6120;, which is the same error set as for IQs.</li>
<li>Presence. Any responses to presence messages MUST follow the rules of &rfc6121;.</li>
<li>PubSub. Where MIX protocol messages use PubSub protocol, the errors defined in &xep0060; MUST be used and supported.</li>
</ol>
@ -724,7 +724,7 @@ This approach enables flexible support of multiple clients for a MIX channel pa
]]></example>
</section2>
<section2 topic='Discovering Nodes at a Channel' anchor='disco-channel-nodes'>
<p>Use disco#items to find the nodes associated with a channel. Discovering nodes in MIX MUST user the node='mix; attribute. The MIX service MUST only return nodes that exist and that the user making the query has rights to subscribe to. </p>
<p>Use disco#items to find the nodes associated with a channel. Discovering nodes in MIX MUST use the node='mix' attribute. The MIX service MUST only return nodes that exist and that the user making the query has rights to subscribe to. </p>
<example caption='Entity Queries for Nodes at a Channel'><![CDATA[
<iq from='hag66@shakespeare.example/e0def5dc-3282-4d00-840a-0292622ba804/ba70bd0f-96fe-442d-872a-96ef3b168613'
id='kl2fax27'
@ -1416,8 +1416,8 @@ This approach enables flexible support of multiple clients for a MIX channel pa
</p>
<ol>
<li>If the client has previously displayed message history and has been offline for a reasonably small time, the client MAY wish to retrieve all messages since the last one displayed to the user.</li>
<li>The client MAY wish to display a fixed number of messages, perhaps finding more messages if the client subsequently requests.</li>
<li>The client MAY wish to display messages from a recent time period, perhaps finding more messages if the client subsequently requests.</li>
<li>The client MAY wish to display a fixed number of messages, perhaps finding more messages if the user subsequently requests.</li>
<li>The client MAY wish to display messages from a recent time period, perhaps finding more messages if the user subsequently requests.</li>
</ol>
<p>To achieve this, the client will query the user's own MAM archive using &xep0313;, with the query filtered by the channel JID. This gives the client flexibility to retrieve and display message history in a manner appropriate to the client implementation.</p>
</section3>
@ -1650,7 +1650,7 @@ This approach enables flexible support of multiple clients for a MIX channel pa
<section3 topic="Requesting vCard" anchor="usecase-vcard">
<p>A user MAY request the vCard of a channel participant by sending a request through the channel. The request MAY be sent directly by the client or MAY be sent by the user's server on behalf of the user. The MIX channel MAY pass this request on or MAY block it. vCard requests MAY use &xep0054; (vcard-temp) or &xep0292; (vCard4 over XMPP). Where a MIX service supports one or both of these protocols, the protocol MUST be advertized as a feature of the MIX service. In the following example, using vcard-temp, the requesting client sends a message to the anonymized bare JID of the channel participant for which the vCard is desired.</p>
<p>A user MAY request the vCard of a channel participant by sending a request through the channel. The request MAY be sent directly by the client or MAY be sent by the user's server on behalf of the user. The MIX channel MAY pass this request on or MAY block it. vCard requests MAY use &xep0054; (vcard-temp) or &xep0292; (vCard4 over XMPP). Where a MIX service supports one or both of these protocols, the protocol MUST be advertised as a feature of the MIX service. In the following example, using vcard-temp, the requesting client sends a message to the anonymized bare JID of the channel participant for which the vCard is desired.</p>
<example caption="Client directly requests vCard through channel" ><![CDATA[
<iq from='hag66@shakespeare.example/e0def5dc-3282-4d00-840a-0292622ba804/ba70bd0f-96fe-442d-872a-96ef3b168613'
id='lx09df27'
@ -2178,7 +2178,7 @@ This approach enables flexible support of multiple clients for a MIX channel pa
<section2 topic="Server Identification of MIX Capabable Clients" anchor="server-identification-mix-clients">
<p>
A MIX User's server MUST determine which online clients support MIX. This will enable the server to send MIX traffic to all MIX capable clients. A MIX capable client MAY choose to come online an not advertize MIX capability. The mechanism for a server to discover client capability is described in <link url="#mix-client-discovery">Discovering Client MIX Capability</link>.
A MIX User's server MUST determine which online clients support MIX. This will enable the server to send MIX traffic to all MIX capable clients. A MIX capable client MAY choose to come online and not advertise MIX capability. The mechanism for a server to discover client capability is described in <link url="#mix-client-discovery">Discovering Client MIX Capability</link>.
</p>
</section2>
@ -2216,7 +2216,7 @@ This approach enables flexible support of multiple clients for a MIX channel pa
</message>
<message from='coven@mix.shakespeare.example'
to='hecate@shakespeare.example/desktop'
to='hecate@shakespeare.example/111c6613-fc5b-40f1-9984-a27887d406c9/222cdb49-b08a-4617-a372-f3b4cff75c6a'
id='77E07BB0-55CF-4BD4-890E-3F7C0E686BBD'
type='groupchat'>
<body>Harpier cries: 'tis time, 'tis time.</body>
@ -2236,7 +2236,7 @@ This approach enables flexible support of multiple clients for a MIX channel pa
<section2 topic="MIX Management and Discovery" anchor="user-server-disco">
<p>
Most interaction between a MIX client and a MIX channel is directly between the client channel. The participant's server relays the message but does not modify the messages. In particular configuration management and discovery is direct. Interaction will be direct, unless explicitly stated otherwise.
Most interaction between a MIX client and a MIX channel is directly between the client and the channel channel. The participant's server relays the message but does not modify the messages. In particular configuration management and discovery is direct. Interaction will be direct, unless explicitly stated otherwise.
</p>
</section2>
<section2 topic="IQ Support on Local Server" anchor="mix-diso">
@ -2290,7 +2290,7 @@ This approach enables flexible support of multiple clients for a MIX channel pa
The participant's server is responsible for ensuring that MIX channels are correctly entered into the user's roster when user's join MIX channels and for removing them when they leave.
</p>
<p>
The participant's server MUST ensure that only presence information from clients that advertize MIX capability is sent to the MIX channel. So, if a user has two online clients, but only one is MIX capable, then the channel will only receive presence information relating to the MIX client.
The participant's server MUST ensure that only presence information from clients that advertise MIX capability is sent to the MIX channel. So, if a user has two online clients, but only one is MIX capable, then the channel will only receive presence information relating to the MIX client.
</p>
</section2>
@ -2316,7 +2316,7 @@ This approach enables flexible support of multiple clients for a MIX channel pa
</p>
<p>
Where a client does not advertize MIX capability, the server MAY choose to not return MIX channels as roster items. If this is done care needs to be taken, in particular around support of roster versioning &xep0237;.
Where a client does not advertise MIX capability, the server MAY choose to not return MIX channels as roster items. If this is done care needs to be taken, in particular around support of roster versioning &xep0237;.
</p>
</section2>
@ -2473,7 +2473,7 @@ This approach enables flexible support of multiple clients for a MIX channel pa
</section1>
<section1 topic='Acknowledgements' anchor='ack'>
<p>Thanks to the following who have made contributions: Dave Cridland, Philipp Hancke, Waqas Hussain, Timothée Jaussoin, Evgeny Khramtsov, Georg Lukas, Tobias Markmann, Ralph Meijer, Edwin Mons, Emmanuel Gil Peyrot, Florian Schmaus, Lance Stout, Sam Whited, Matthew Wild and one anonymous reviewer.</p>
<p>Thanks to the following who have made contributions: Dave Cridland, Philipp Hancke, Waqas Hussain, Timothée Jaussoin, Evgeny Khramtsov, Georg Lukas, Tobias Markmann, Ralph Meijer, Edwin Mons, Emmanuel Gil Peyrot, Florian Schmaus, Lance Stout, Sam Whited, Jonas Wielicki, Matthew Wild and one anonymous reviewer.</p>
</section1>
</xep>