diff --git a/xep-0152.xml b/xep-0152.xml index 16da77ce..af970f74 100644 --- a/xep-0152.xml +++ b/xep-0152.xml @@ -7,7 +7,7 @@
Reachability Addresses - This document defines an XMPP protocol extension for communicating information about how an entity can be reached using methods other than the entity's normal JID. + This document defines an XMPP protocol extension for communicating information about how an entity can be reached temporarily using methods other than the entity's normal JID. &LEGALNOTICE; 0152 Proposed @@ -24,6 +24,12 @@ reach &stpeter; &hildjj; + + 0.5 + 2013-09-25 + psa +

Modified the text and examples to better illustrate the primary use case.

 + 0.4 2013-02-05 @@ -70,6 +76,7 @@

  • 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.

    @@ -85,7 +92,7 @@ - + ]]>

    When publishing reachability addresses, the <reach/> element MUST contain at least one <addr/> element. Each <addr/> element MUST possess a 'uri' attribute, whose value MUST be the Uniform Resource Identifier (&rfc3986;) or Internationalized Resource Identifier (&rfc3987;) of an alternate communications method for reaching the user.

    @@ -93,10 +100,10 @@ - New conference room number + Conference room phone - - My softphone + + In-room video system ]]> @@ -110,13 +117,15 @@

    This document does not recommend one transport method over the other.

    In addition, a contact MAY request a user's reachability addresses in an XMPP &IQ; stanza of type "get" and a user MAY send reachability addresses in an XMPP &MESSAGE; stanza. However, the presence and PEP transport methods are preferred.

    + -

    To broadcast reachability addresses in presence information, a user's client includes the <reach/> element in the &PRESENCE; stanza it sends to its server:

    +

    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.

    + - + ]]> @@ -125,28 +134,33 @@ - + ]]> -

    Naturally, a reachability address MAY alternatively be included in directed presence.

    +

    (Naturally, a reachability address MAY alternatively be included in directed presence.)

    +

    Upon leaving the conference room, the user's client would send updated presence without the reachability extension.

    + + ]]>     +

    To publish reachability addresses via the personal eventing protocol (XEP-0163), the entity publishes data to the "urn:xmpp:reach:0" node.

    - My mobile number + Conference room phone - - My softphone + + In-room video system @@ -162,10 +176,10 @@ - My mobile number + Conference room phone - - My softphone + + In-room video system @@ -173,6 +187,21 @@ ]]> +

    As above, when leaving the conference room the user's client would publish an updated payload indicating that it no longer has any temporary reachability addresses.

    + + + + + + + + + + ]]>