From febac285036cc2a19b62bfa20e7eeee1afa5eec8 Mon Sep 17 00:00:00 2001 From: Peter Saint-Andre Date: Wed, 29 Nov 2017 12:33:02 -0700 Subject: [PATCH] XEP-0186: Address LC feedback --- xep-0186.xml | 25 +++++++++++++------------ 1 file changed, 13 insertions(+), 12 deletions(-) diff --git a/xep-0186.xml b/xep-0186.xml index 0bad8efe..c0b401fb 100644 --- a/xep-0186.xml +++ b/xep-0186.xml @@ -11,7 +11,7 @@ &LEGALNOTICE; 0186 Proposed - 2017-03-14 + 2017-12-12 Standards Track Standards @@ -25,11 +25,17 @@ invisible &stpeter; + + 0.13 + 2017-11-29 + psa +

Addressed Last Call feedback: (1) clarified conformance requirements for 'probe' attribute and (2) removed text about using the same server backend for privacy lists because XEP-0016 is now deprecated.

 + 0.12 2017-01-28 psa -

Added method for specifying server behavior regarding presence probes via new 'probe' attribute; increased the protocol version number from 0 to 1.

 +

Added method for specifying server behavior regarding presence probes via new 'probe' attribute; incremented the protocol version number from 0 to 1.

 0.11 @@ -112,12 +118,7 @@ -

Some XMPP-based instant messaging systems have long supported the ability for users to be online but to appear offline to other users. The existing protocols for this "invisibility" feature are:

-
    -

  • &xep0018; -- this protocol is not compatible with &xmppcore; and &xmppim; because it defines new values of the 'type' attribute for the &PRESENCE; outside of the IETF (also, the specification does not provide reliable documentation of the protocol in use, since many server implementations support presence of type "invisible" but not presence of type "visible").

    • -

  • &xep0126; -- this protocol is a somewhat complicated profile of &xep0016; to enable temporary invisibility, and violates the spirit of XEP-0016, which was defined to enable permanent blocking of communications instead of per-session interactions (nevertheless, the invisible command defined here can provide a client-friendly interface to the same data backend used for privacy lists).

    • -
-

In order to provide a standards-compliant protocol extension that can be used in the long term, this document defines an IQ-based protocol that enables an IM user to become "invisible" and "visible" at will within the context of a given session.

+

Some XMPP-based instant messaging systems have long supported the ability for users to be online but to appear offline to other users. This "invisibility" feature was previously defined in nonstandard or complicated ways via &xep0018; and &xep0126; (the latter was a profile of &xep0016;, which is now deprected). By contrast, this specification defines a standards-compliant protocol extension that can be used over the long term, using an IQ-based protocol that enables an IM user to become "invisible" and "visible" at will within the context of a given session.

 @@ -132,7 +133,7 @@

In order for a client to go invisible, it sends an IQ-set with no 'to' address (thus handled by the user's server) containing an <invisible/> element qualified by the 'urn:xmpp:invisible:1' namespace &VNOTE;.

-

The <invisible/> element MUST include a 'probe' attribute, which specifies whether the server shall or shall not send presence probes to entities in the user's roster (thus determining whether the user does or does not automatically receive presence notifications from contacts). This attribute is a boolean &BOOLEANNOTE;, where a logical value of TRUE (lexical value of "true" or "1") indicates that the server shall send presence probes and where a logical value of FALSE (lexical value of "false" or "0") indicates that the server shall not send presence probes. The default logical value is FALSE.

+

The <invisible/> element SHOULD include a 'probe' attribute, which specifies whether the server shall or shall not send presence probes to entities in the user's roster (thus determining whether the user does or does not automatically receive presence notifications from contacts). This attribute is a boolean &BOOLEANNOTE;, where a logical value of TRUE (lexical value of "true" or "1") indicates that the server shall send presence probes and where a logical value of FALSE (lexical value of "false" or "0") indicates that the server shall not send presence probes. The default logical value is FALSE.

A client SHOULD complete this service discovery process before sending initial presence to its server (as specified in &xep0115;, a server can include entity capabilities information in a stream feature, which obviates the need for explicit service discovery as shown above).

 - -

A server MAY use the same data backend for this invisibility mode as for privacy lists when employed for invisibility (see XEP-0126). If so, the server MUST update the relevant privacy lists on behalf of the user when the client sends an invisible command or a visible command as specified herein.

+ +

Implementers need to be aware that use of the 'probe' attribute is not consistent with the older privacy lists approach defined in XEP-0126.

 @@ -295,7 +296,7 @@ -

Thanks to Philipp Hancke, Kevin Smith, Matthew Wild and Ruslan N. Marchenko for their feedback.

+

Thanks to Philipp Hancke, Evgeny Khramtsov, Ruslan Marchenko, Kevin Smith, and Matthew Wild for their feedback.