On 7 Dec 2017, at 17:35, Jonas Wielicki (XSF Editor) <jo...@wielicki.name> wrote: > > This message constitutes notice of a Last Call for comments on > XEP-0186. > > Title: Invisible Command > Abstract: > This document specifies an XMPP protocol extension for user > invisibility. > > URL: https://xmpp.org/extensions/xep-0186.html > > This Last Call begins today and shall end at the close of business on > 2017-12-21. > > Please consider the following questions during this Last Call and send > your feedback to the standards@xmpp.org discussion list: > > 1. Is this specification needed to fill gaps in the XMPP protocol > stack or to clarify an existing protocol?
Probably. > 2. Does the specification solve the problem stated in the introduction > and requirements? Probably. Comments later. > 3. Do you plan to implement this specification in your code? If not, > why not? Not currently, I don’t think we need the feature in our code. > 4. Do you have any security concerns related to this specification? I think the Security Considerations should list the most obvious leaks that still occur when this is implemented (it says they exist, but doesn’t suggest what any are). > 5. Is the specification accurate and clearly written? It’s not clear to me why we need to both mandate a default for probe, and that it’s always included. I think it would be worth explaining *why* you might want to send invisible without a probe, which seems at first glance like it’s the same as not sending presence at all (I know it’s not!). "SHOULD deliver inbound <message/> stanzas whose 'to' address is the bare JID <localp...@domain.tld> of the user (subject to standard XMPP stanza handling rules from RFC 6120 and RFC 6121).” I think this needs tightening to instead of ‘subject to…’ say something like ‘if it would otherwise receive…’. Else one could read it as saying that a negative priority invisible resource gets messages. " • If the server responds to a presence probe, the last available presence MUST indicate that the user is unavailable, and if a time is indicated it MUST be the time when the client went invisible.” I don’t think this is right, e.g. two resources, 1 goes invisible, then 2 goes offline - the time should be when 2 went offline, not 1 went invisible. " • If the server responds to a Last Activity (XEP-0012) [5] request, the last activity time MUST be the time when the client went invisible.” Same. "If the user wishes to then send presence to all contacts in the roster,” I think this means those with a presence sub, not just being in the roster (this is correctly stated later) "(the server MAY also send that notification to any entities to which the client sent directed presence while invisible, whether or not they are in the user's roster)” This seems weird, as its the only time this would happen; I don’t see a reason for the inconsistency with normal directed presence handling. /K _______________________________________________ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org _______________________________________________
