Re: [Standards] XEP-0816 (Invisible Command) mandates ridiculous UI
Only my two cents... You should not forget the other side and for e.g. the popular protocols ICQ and MSN. In a nutshell both protocols support the Invisible mode (in MSN it's named appear off-line) and this is only annoying in both protocols. Take a look at the other side, you have a list full of off-line contacts, but many contacts write you messages. What's the sense of it? It's annoying! ... that's my choice, sorry, but I am not agree, stay off-line if you don't want to chat or keep the possibility that the user from the other side can see you and make sure Invisible is not a normal mode. Therefore, in my opinion, 3.1.2. makes sense. Peter -- Lastwebpage Lastwebpage's Profile: http://www.jabberforum.org/member.php?userid=41 View this thread: http://www.jabberforum.org/showthread.php?t=1903
Re: [Standards] XEP-0816 (Invisible Command) mandates ridiculous UI
And Jiří Zárevúcký spoke on 04/23/2009 11:02 AM, saying: I don't think it's ridiculous. I guards against accidental leaking of presence. You can leak for example by requesting users client's version or service discovery information. I can imagine very little ordinary users realize it. You can still add some sort of checkbox saying Don't ask again. That's not against the rules IMO, as this way the user configures the client to autopopulate trusted list with any contacts he interacts with. It's all just implementation details. I think it's critical to distinguish user-generated traffic from client-generated outgoing stanzas. I agree with Will that, for the former, this is a really frustrating UI and I'd hate my client for doing it. For client-generated stanzas, it's still overly restrictive (again, I'd hate my client for *double prompting me* if I try to establish a voice call with someone while I'm invisible); IMHO, the XEP should say that clients only send responses to parties to whom the user has already revealed presence (or previously whitelisted) and respond to all other stanzas as if the server were responding on behalf of an offline resource. If I start messaging someone, my client should treat that as implicit authorization to respond to IQs from or send IQs to that client. ~Paul
Re: [Standards] XEP-0816 (Invisible Command) mandates ridiculous UI
2009/4/25 Paul Aurich p...@darkrain42.org: I think it's critical to distinguish user-generated traffic from client-generated outgoing stanzas. I agree with Will that, for the former, this is a really frustrating UI and I'd hate my client for doing it. I think that's exactly the problem in question. User can explicitly generate traffic without him knowing. You generate traffic by opening a window. You generate it by displaying your contact's information. You can even generate it by hovering mouse over your contact in roster. Ordinary users don't understand the technology and should be warned. I still think it is implementation and configuration issue. The don't ask again checkbox is really a no-brainer.
Re: [Standards] XEP-0816 (Invisible Command) mandates ridiculous UI
I think the examples you give are arguably client bugs. Ji=C5=99=C3=AD Z=C3=A1rev=C3=BAck=C3=BD wrote: You generate traffic by opening a window. You don't need to. You generate it by displaying your contact's information. Then don't do so unless the contact's already whitelisted (because you sent them an IM) and have a show more information (may reveal your existence button. You can even generate it by hovering mouse over your contact in roster. Your client really shouldn't generate traffic then. Obviously the client should try not to expose the user without them doing something that obviously exposes them, so prompting them if they wouldn't expect to be exposed is reasonable. I think that's what the XEP was trying to ensure, but I think it goes too far. --=20 Will signature.asc Description: OpenPGP digital signature
Re: [Standards] XEP-0816 (Invisible Command) mandates ridiculous UI
2009/4/25 Will Thompson will.thomp...@collabora.co.uk: Obviously the client should try not to expose the user without them doing something that obviously exposes them, so prompting them if they wouldn't expect to be exposed is reasonable. I think that's what the XEP was trying to ensure, but I think it goes too far. The XEP says that based on configuration, client can auto-populate communication list with trusted entities. You can (for the purposes of end-user implementation) say that everyone in your roster, who you explicitly start communicating with, is a trusted entity and as such can be automatically (without prompting) added to the white-list, if your configuration allows it. Or am I understanding something incorrectly?
[Standards] Unclarified behavior in XEP-0047 (in-band bytestreams)
Upon receiving notice that a data packet is cannot be processed by the recipient, the sender SHOULD consider the bytestream to be closed and invalid but MAY attempt to correct the error and re-send the offending data packet using the same sequence number (the recipient MUST NOT consider a sequence number to have been used until the data packet has been successfully processed). The sender must either resend data or explicitly close the stream by sending the close query. Otherwise the recipient doesn't know whether the sender wants to resend or not. Right? What confuses me it that in the case of invalid sequence number, the one responsible for closing of the stream is the receiver: The recipient MUST NOT process the data of such an out-of-sequence packet, nor any that follow it within the same bytestream; instead, the recipient MUST consider the bytestream invalid and SHOULD close the bytestream as described in the next section. But that's also SHOULD, not MUST... what happens if the recipient doesn't close it? Can this part be clarified and made sure that stream invalidation is in all cases obvious to both entities? Thanks :)
