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

0.6

This commit is contained in:
Peter Saint-Andre 2013-12-02 19:39:56 -07:00
parent 81f49bd3bf
commit 1bfabec142
1 changed files with 13 additions and 8 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

21
xep-0152.xml
View File

@ -11,7 +11,6 @@
&LEGALNOTICE;
<number>0152</number>
<status>Proposed</status>
<lastcall>2013-03-19</lastcall>
<type>Standards Track</type>
<sig>Standards</sig>
<approver>Council</approver>
@ -24,6 +23,12 @@
<shortname>reach</shortname>
&stpeter;
&hildjj;
<revision>
<version>0.6</version>
<date>2013-12-02</date>
<initials>psa</initials>
<remark><p>Further clarified the intent of the protocol.</p></remark>
</revision>
<revision>
<version>0.5</version>
<date>2013-09-25</date>
@ -70,13 +75,13 @@
</header>
<section1 topic='Introduction' anchor='intro'>
<p>Sometimes it is desirable to augment instant messaging (IM) with another real-time communications medium, such as a voice conversation conducted over the traditional public switched telephone network (PSTN) or more recent Voice over Internet Protocol (VoIP) applications. In order to facilitate this functionality, a user needs to advertise the address(es) at which they can be reached. There are several possible ways to do this:</p>
<p>Sometimes it is desirable to augment instant messaging (IM) with another real-time communications medium, such as a voice conversation conducted over the traditional public switched telephone network (PSTN) or Voice over Internet Protocol (VoIP) applications. In order to facilitate this functionality, a user needs to advertise the address(es) at which they can be reached. There are several possible ways to do this:</p>
<ul>
<li><p>Publish the address(es) in the user's vCard (see &xep0054; and &xep0292;); this is convenient, but is not very dynamic (e.g., reachability addresses might change when the user moves to a new conference room in an office building).</p></li>
<li><p>Send the address(es) within a &PRESENCE; stanza; this option is described in the <link url='#transport-presence'>Presence Transport</link> section of this document and is consistent with &rfc6121; since reachability is one aspect of a user's availability for communication.</p></li>
<li><p>Send address(es) to the appropriate &xep0060; node; this option is described in the <link url='#transport-pep'>PEP Transport</link> section of this document but might not be available at all service providers.</p></li>
</ul>
<p>This document defines methods for publishing addresses at which a user can be reached temporarily, as opposed to semi-permanent addresses of the kind that are more appropriately communicated in a user's vCard.</p>
<p>This document defines methods for publishing addresses at which a user can be reached temporarily, as opposed to semi-permanent addresses of the kind that are more appropriately communicated in a user's vCard. We illustrate this usage through the scenario of a user sending a reachability address upon entering a physical conference room and then sending an updated notification (without a reachability address) upon leaving the conference room. Similar scenarios might apply when an XMPP implementation is used with technologies such as WebRTC and in deployments of the combined use of SIP and XMPP ("CUSAX"; &rfc7081;).</p>
</section1>
<section1 topic='Requirements' anchor='reqs'>
@ -120,7 +125,7 @@
<section2 topic='Presence Transport' anchor='transport-presence'>
<p>To broadcast reachability addresses in presence information, a user's client includes the &lt;reach/&gt; element in the &PRESENCE; stanza it sends to its server.</p>
<p>For example, consider someone who walks into a conference room at the office. Via nearfield communication, the user's XMPP client might auto-discovery a 'tel:' URI for the room audio system and a 'sip:' URI for the room video system.</p>
<p>For example, consider someone who walks into a conference room at the office. Via nearfield communication, the user's XMPP client might auto-discover a 'tel:' URI for the room audio system and a 'sip:' URI for the room video system.</p>
<example caption="User&apos;s Client Includes Reachability Addresses in Presence"><![CDATA[
<presence from='romeo@example.com/mobile'>
<reach xmlns='urn:xmpp:reach:0'>
@ -131,7 +136,7 @@
]]></example>
<p>The user's server then broadcasts that presence stanza to all entities who are subscribed to the user's presence:</p>
<example caption="User&apos;s Server Broadcasts Presence Information"><![CDATA[
<presence from='romeo@montague.net' to='juliet@capulet.com'>
<presence from='romeo@montague.net/mobile' to='juliet@capulet.com'>
<reach xmlns='urn:xmpp:reach:0'>
<addr uri='tel:+1-303-555-1212'/>
<addr uri='sip:room123@example.com'/>
@ -229,8 +234,8 @@
</section1>
<section1 topic='Implementation Notes' anchor='impl'>
<p>To preserve network bandwidth, the sender SHOULD NOT include the &lt;desc/&gt; element unless that information is deemed necessary to enable communication.</p>
<p>A recipient SHOULD attempt communications with reachability addresses in the order that the &lt;addr/&gt; elements appear within the &lt;reach/&gt; element.</p>
<p>To preserve network bandwidth, the sender ought not include the &lt;desc/&gt; element unless that information is deemed necessary to enable communication.</p>
<p>A recipient ought to attempt communications with reachability addresses in the order that the &lt;addr/&gt; elements appear within the &lt;reach/&gt; element.</p>
</section1>
<section1 topic='Internationalization Considerations' anchor='i18n'>
@ -239,7 +244,7 @@
<section1 topic='Security Considerations' anchor='security'>
<p>Security considerations for XMPP presence and PEP publication are described in RFC 6120, RFC 6121, XEP-0060, and XEP-0163.</p>
<t>Advertising a telephone number, SIP URI, or other real-time communication address to one contact or to multiple contacts introduces the possibility of information leakage and subsequent attacks (e.g., unsolicited phone calls). Clients are advised to appropriately warn users about the dangers of such attacks.</t>
<t>Advertising a telephone number, SIP URI, or other real-time communication address to multiple contacts in an unencrypted way (e.g., via XMPP presence or PEP in cases where not all hops are TLS-protected) introduces the possibility of information leakage and subsequent attacks such as unsolicited phone calls. Clients are advised to appropriately warn users about the dangers of such attacks. Alternatively, if the address is especially sensitive (say, a hashname &rfc6920; for use in a system that enables direct private communication outside of XMPP), then a client could send it in a message that itself is end-to-end encrypted.</t>
</section1>
<section1 topic='IANA Considerations' anchor='iana'>