Further clarified the intent of the protocol.
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:
+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:
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).
Send the address(es) within a &PRESENCE; stanza; this option is described in the Presence Transport section of this document and is consistent with &rfc6121; since reachability is one aspect of a user's availability for communication.
Send address(es) to the appropriate &xep0060; node; this option is described in the PEP Transport section of this document but might not be available at all service providers.
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.
+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;).
To broadcast reachability addresses in presence information, a user's client includes the <reach/> element in the &PRESENCE; stanza it sends to its server.
-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.
+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.
The user's server then broadcasts that presence stanza to all entities who are subscribed to the user's presence:
To preserve network bandwidth, the sender SHOULD NOT include the <desc/> element unless that information is deemed necessary to enable communication.
-A recipient SHOULD attempt communications with reachability addresses in the order that the <addr/> elements appear within the <reach/> element.
+To preserve network bandwidth, the sender ought not include the <desc/> element unless that information is deemed necessary to enable communication.
+A recipient ought to attempt communications with reachability addresses in the order that the <addr/> elements appear within the <reach/> element.
Security considerations for XMPP presence and PEP publication are described in RFC 6120, RFC 6121, XEP-0060, and XEP-0163.
-