On 2012-07-10 3:13 PM, "Peter Saint-Andre" <stpe...@stpeter.im> wrote: > > http://xmpp.org/extensions/xep-0085.html#bizrules-gen > > > > Oh wow -- This is a massive surprise for me. > > *precedent* in a *Final* standard -- that allows bypassing disco! > > > > This is XEP-0085 Chat States (Final standard) advocating sending chat > > states without first discovering support! > > Don't read too much into it. XEP-0085 says you *SHOULD* use explicit > service discovery, and says that you *MAY* use the fallback method > described there if service discovery is not available. That's *not* the > same as advocating the fallback method.
I am using similar RFC2119 terminology. I will smooth the rough edges, though. (Until replaced by a better method if found) > We could have a separate discussion about whether that fallback method > is a good idea in XEP-0085, but the context there was having a chat > session with someone with whom you don't share presence (thus you > wouldn't know which full JIDs to query about XEP-0085 support). If you > do share presence, then entity capabilities (XEP-0115) is really the > right way to go here (BTW, I notice that XEP-0301 does not mention > XEP-0115, and it really ought to). If you don't share presence > permanently, then sharing it temporarily is really the best idea, using > directed presence as explained in Section 5.1 of RFC 6121. See also > XEP-0276 (currently deferred) about temporary sharing. I should note that XEP-0301 works even if you show up as offline. A person who is invisible can still successfully use RTT either as sender or recipient, and regardless of which side initiated. If the message makes it through, real time text can also make it through in all situations that messages are immediately deliverable. (I'm excluding offline delivery as that is not real time anyway, and it is weird to watch keypresses play out in a non-live manner) I will look closely at XEP-0115 and see if it is a suitable alternative. The last time I read it, it did not appear suitable, but I will verify. Thanks! > Although I think directed presence and entity capabilities is the right > thing to do here, I can't object *too* strongly to the fallback approach > since I co-authored XEP-0085. However, if the consensus of the community > were to remove the fallback method from XEP-0085 now that we have > XEP-0115, I would do it. I am quite interested in those discussions because the 'sender-side ability to signal capabilty' is algorithmically/scientifically similiar between section 5.1 of XEP-0085 and the end of section 5 of XEP-0301. > > 1. Permits sender attempts to initiate real-time text even when > > recipients stay private. > > What does it mean for recipients to stay private? Do you mean they don't > send presence, don't advertise support for RTT, or something else? I meant "don't advertise support for RTT" but it also applies to doing RTT with people who go into invisible mode, too. > > 2. Permits elimination of bandwidth consumption of unnecessary incoming > > <rtt/> while still continuing to be receptive to real-time text. > > Reducing bandwidth consumption is indeed a good thing. That's one of the > reasons we invented entity capabilities (XEP-0115). Which I will also investigate, if it also satisfies #1 too. > > 3. Permits maximum interoperability between widest possible variety of > > client implementations. > > Do you mean clients that don't support service discovery or entity > capabilities? Those too. I really meant "turning off advertising of RTT" when I say "turning off disco". But as a side issue, I was thinking the other items I listed, but those too. Rudimentary low end software programmed by less skilled programmers, including charity-starved assistive/deaf organizations. (Some of those have gone bankrupt). I also want to mimimize prerequisites on other large XMPP protocols, where "reasonably achievable", while still meeting requirements. There is a fine line there, we can probably agree :-) Programmer ease is preferable to adding an order (or more) magnitude additional computer code. I suspect, behind it all, is part of the reaon of the fallback mechanism in XEP-0085 -- it was the simplest programming solution to meet criteria. > > -- Feedback has shown that some implementers have high likelihood of > > choosing to "turning off disco to stop the bandwidth" > > Implementers or users? Again, I have *never* seen a client that lets you > disable service discovery. The emails (Kevin, Kurt, and one other) from the last 18 months indicate some powerful motivators (bandwidth, privacy) requires us to solidify the spec so that we ensure these people can be satisfied while still allowing interop. In addition, I feel that the controversial modification I made (one sentence) made the spec much harder to abuse, too. But maybe it is not that controversial, given precedent in XEP-0085? :-) (Yes, maybe the converse is true, rather: It is now a controversial part of XEP-0085) > Could you please explain the privacy concern with enabling service > discovery? I have never heard this objection in relation to any other > XMPP extension (voice, video, file transfer, chat state notifications, > or dozens of others). An expression of fear of bandwidth was mentioned, as one of the reasons. (You agreed bandwidth is good). Also the issue of RTT to people who want to show as offline/private mode. Different angle (don't want to sidetrack, but) Some clients -- like Pidgin -- a popular open source client -- disables most plugins by default, also disabling advertising of the feature when the plug-in is disabled. When made, the real time text plugin is more likely to be enabled by default in a default install if it can run with very conservative/discreet settings that don't annoy the majority of mainstream users. Then it is more Accessible. > > This method of turning on/off real-time text is > > already discouraged, because it makes it hard for senders/recipients to > > optionally synchronize enabling of real time text (without a secondary > > fall back mechanism like the one I proposd). You already know disco is > > going to be turned off in possible XEP-0301 implementations (in emails > > from multiple people in the last 18 months). > > I must have missed those. I am interpreting broadly, but there are several on list and off list. People include Kevin, Kurt and someone else last year (the person who originally asked for the original Section 5 to be added) quoted various reasons why an implementation may disable XEP-0301, and those reasons are often separate from user intent. Search my most recent replies to Kurt for an example. (The first one containing the phrase "user intent") > Some technologies tend to require explicit approval by a user before > starting a session (voice, video, whiteboarding, screen sharing, etc.). > For those protocols, we use explicit session negotiation as in XEP-0166. > It is unclear to me whether RTT rises to that level (I see it as more > similar to chat state notifications). Side example -- AOL Real-Time IM uses explicit session negotiation of RTT, with a user prompt for confirmation. Even though we permit that behavior if the implementer wishes, we don't want to enforce session negotiation. So I agree. The spec I have made allows basic session synchronization that provides just barely enough protocol to permit (for practical user purposes) identical behavior to explicit session negotiation. The minimum protocol possible, methinks, to satisfy all conceivable realistic scenarios. Some clients will confirm to the user about enabling RTT. But it will still interop with clients that don't prompt and/or don't synchronize. XEP-0301 can behave as an enhanced chat state notification and implementors are also welcome to use it that way....though with the privacy implications, it will (by default) require user confirm in certain implementations, as implementers are also allowed to implement behavior of explicit session negotiation. The spec provide huge flexibility in how it is activated, while remaining interoperable between those who do and those who do not. That is a huge reason I also added the fallback mechanism, to continue to permit interop between wide combinations of differing activation methods in wide variety of circumstances (including private mode, etc) > > *3. Permits maximum interoperability between widest possible variety of > > client implementations.* > > Maximum interoperability is possible between the maximum possible, > > widest-diverging implementations of real-time text activations: > > -- some clients will activate real time text right away (e.g. assistive > > clients) > > -- some clients will activate real-time text upon a button/menu/etc > > (e.g. mainstream) > > What do you mean by "activate"? My mainstream client might give me a > configuration option for allowing RTT, and not require me to click some > button every time someone sends me RTT data. All the above. The fallback mechanism now maximizes flexibility as to how vendors wish to implement activate, while maximizing interop between different implementations. Activation can be button, menu, config option, per session, per startup, per preferences, a rube goldberg contraption. And other clients may just send RTT right away in all chats (if determining support says it is allowed to do so). As you already noticed, I provide a new section in Implementation Notes on Activation/Deactivation to loosely cover basic concepts, while leaving it to the implementer to decide how to implement activation. > > -- some clients will not synchronize enabling of real-time text (e.g. > > unidirectional real time text) > > Do we think unidirectional RTT is a good idea? Please note that chat > state notifications are *not* unidirectional. There are valid use cases. -- In one possible (of many allowed activation scenarios) activation scenario is displaying incoming real time text while waiting for the user to confirm activation of outgoing real time text. (The appearance of incoming RTT is a convenient way to educate users of what RTT looks like) -- Transcription services. Like sprintcaptel.com that uses proprietary RTT protocol. Those do ot care about RTT in the other direction. -- Bot services that output streaming text such as real time stock quotes. Ditto. -- Using XEP0301 to relay live closed captioning. Return RTT not used. -- There are other good reasons, but if any one of the above is a good reason, it short circuits needing to list further good reasons :-) > > -- some recipients may or may not ask user for permission (e.g. like > > user prompt during audio/video activation) > > I assume you mean on a per-session basis. Yes, that is allowed. Implementors can choose to treat XEP-0301 this way. It will still interop in general with other different activation methods. > > -- some clients will keep real-time text private, but want to be > > signalled (see previous email, and reason #1) > > Here again, what does it mean to keep it private? Do you mean not > advertise the feature, or encrypt the RTT data end-to-end? I meant, in situations where the feature is not advertised/advertisable. > > I want to point out that the fallback mechanism that I designed (blank > > rtt element), provides for maximum interopreability of real-time text > > *between ALL combinations of ALL the above scenarios. * This is > > "Accessible". I honestly believe I tried to design well on that basis > > -- even if it is not "engineer clean", it's pretty "human compatible" > > and "Accessible". Please rest assured I thought through subtle > > interaction scenarios, and some may have been missed. I am avoiding > > interop problems between willing senders/recipients, that end up not > > talking to each other, > > > Well, that's the reason we ended up taking that approach in XEP-0085 > (although, as noted, I think we could do better by using entity > capabilities and directed presence). Exactly.... > > > only because one end has lack of disco (including > > for any silly or stupid reason that we engineers disagree about). > I really don't like designing protocols around buggy implementations! We > have service discovery and entity capabilities for good reasons. > > > I realize it may not be 100% perfect protocol design. But we engineers > > --> are designing for human-usable software. > > --> are designing for protocols that get popular more quickly because of > > flexibility (and maximum interop). > > --> more RTT means more deaf can do RTT, more accessible. > > Those are nice, but don't trump designing good protocols. And XEP-0085 section 5.1? ;-) Also, "good protocol" is subjective. Good from what perspective? Good to Rosie the robot? Good to a computer? Good to a human? Good from ease of implementation? Good from interop perspective? All potentially mutually exclusive. Ok, I know it can probably now be updated due to XEP-0115 which was only invented later. But the point remains. Mark Rejhon On 2012-07-10 3:13 PM, "Peter Saint-Andre" <stpe...@stpeter.im> wrote: > On 7/10/12 12:34 PM, Mark Rejhon wrote: > > (Starting over, from good grounds) > > (NOTE: This big email is regarding what is essentially a *single > > controversial sentence* added to XEP-0301 protocol) > > Welcome to the wonderful world of standards development. :) > > > On Tue, Jul 10, 2012 at 1:17 PM, Peter Saint-Andre <stpe...@stpeter.im > > <mailto:stpe...@stpeter.im>> wrote: > > > > > Metaphorically speaking: > > > > > i.e. in a manner of speaking, we strongly believe senders should be > > > allowed to "dial the phone". > > > Even if we don't know if the phone number is good or not. i.e. > > senders > > > should be able to be allowed to try to dial. > > > > Sure, this is essentially the chat state notifications fallback for > > determining when to generate notifications, applied to the example of > > RTT data: > > > > http://xmpp.org/extensions/xep-0085.html#bizrules-gen > > > > > > Oh wow -- This is a massive surprise for me. > > *precedent* in a *Final* standard -- that allows bypassing disco! > > > > This is XEP-0085 Chat States (Final standard) advocating sending chat > > states without first discovering support! > > Don't read too much into it. XEP-0085 says you *SHOULD* use explicit > service discovery, and says that you *MAY* use the fallback method > described there if service discovery is not available. That's *not* the > same as advocating the fallback method. > > We could have a separate discussion about whether that fallback method > is a good idea in XEP-0085, but the context there was having a chat > session with someone with whom you don't share presence (thus you > wouldn't know which full JIDs to query about XEP-0085 support). If you > do share presence, then entity capabilities (XEP-0115) is really the > right way to go here (BTW, I notice that XEP-0301 does not mention > XEP-0115, and it really ought to). If you don't share presence > permanently, then sharing it temporarily is really the best idea, using > directed presence as explained in Section 5.1 of RFC 6121. See also > XEP-0276 (currently deferred) about temporary sharing. > > > That's exactly what I am trying to do with the blank <rtt/> fallback > > mechanism (that's been controversial) at the end of Section 5 of > > XEP-0301: http://xmpp.org/extensions/xep-0301.html#message_reset > > It's controversial because it's still probably not a great idea, given > that you can solve the same problem using directed presence and entity > capabilities. > > > I realize that I may have been overly-defensive of keeping a fallback > > mechanism on Accessibility grounds, maybe my approach (is wrong) in > > explaining why a fallback mechanism should exist. Yes, I know I should > > not use XEP-0085 as an excuse, but clearly there was apparently enough > > agreement to accept the fallback mechanism, and keeping it in a Final > > standard. > > Although I think directed presence and entity capabilities is the right > thing to do here, I can't object *too* strongly to the fallback approach > since I co-authored XEP-0085. However, if the consensus of the community > were to remove the fallback method from XEP-0085 now that we have > XEP-0115, I would do it. > > > I will now approach from a professional/technical approach, to justify > > keeping some modified form of fallback mechanism in XEP-0301: > > > > I want to clarify that the fallback mechanism I designed (which I now > > know has precedent) permits the following: > > 1. Permits sender attempts to initiate real-time text even when > > recipients stay private. > > What does it mean for recipients to stay private? Do you mean they don't > send presence, don't advertise support for RTT, or something else? > > > 2. Permits elimination of bandwidth consumption of unnecessary incoming > > <rtt/> while still continuing to be receptive to real-time text. > > Reducing bandwidth consumption is indeed a good thing. That's one of the > reasons we invented entity capabilities (XEP-0115). > > > 3. Permits maximum interoperability between widest possible variety of > > client implementations. > > Do you mean clients that don't support service discovery or entity > capabilities? > > > 4. (more good reasons exist, but will limit to above to keep email short) > > > > More detail: > > > > *1. Permits sender attempts to initiate real-time text even when > > recipients stay private.* > > -- Explained in the previous huge email message. But wait -- that's not > > the only reason. (see below) > > > > *2. Permits elimination of bandwidth consumption of unnecessary incoming > > <rtt/> while still continuing to be receptive to real-time text. * > > -- Turning on disco loses all control of bandwidth of incoming <rtt/>. > > Well, and other things too, no? > > Please note that you'll receive RTT data only if you engage in a > conversation with another party. > > > If your software enables disco, clients are allowed to just transmit > > you an <rtt/> every 0.7 seconds, consuming your bandwidth. (Bandwidth > > control is now achievable via <rtt event='init'/> and <rtt > > event='cancel'/> ...) > > Or feature negotiation, or Jingle, or some other method. :) > > I'm not saying we'd want to use Jingle to negotiate an RTT session, but > we do use it for things like whiteboarding, file transfer, and voice and > video. It seems a bit heavy for negotiating an RTT session, though. > > > -- Feedback has shown that some implementers have high likelihood of > > choosing to "turning off disco to stop the bandwidth" > > Implementers or users? Again, I have *never* seen a client that lets you > disable service discovery. > > > (as a secondary > > reason to privacy). > > Could you please explain the privacy concern with enabling service > discovery? I have never heard this objection in relation to any other > XMPP extension (voice, video, file transfer, chat state notifications, > or dozens of others). > > > This method of turning on/off real-time text is > > already discouraged, because it makes it hard for senders/recipients to > > optionally synchronize enabling of real time text (without a secondary > > fall back mechanism like the one I proposd). You already know disco is > > going to be turned off in possible XEP-0301 implementations (in emails > > from multiple people in the last 18 months). > > I must have missed those. > > > It's a very fine line > > between "I don't want to ever receive real time text" (Kurt) and "I > > don't want to ever receive real time text, _until you ask me first_" > > ...Key phrase is "Until you ask me first". Fallback mechanism becomes > > necessary. > > Fallback or explicit negotiation using XEP-0020 or XEP-0166 or somesuch. > > > -- By providing the fallback mechanism, it is now possible to > > have discovery while reducing bandwidth. > > Actually you seem to be using the fallback method to determine both > protocol support and willingness to use the protocol in a particular > interaction. > > > The existence of <rtt > > event='init'/> and <rtt event='cancel'/> allows vendors some control of > > bandwidth of real-time text, and discourage vendors from permanently > > turning off disco. > > Some technologies tend to require explicit approval by a user before > starting a session (voice, video, whiteboarding, screen sharing, etc.). > For those protocols, we use explicit session negotiation as in XEP-0166. > It is unclear to me whether RTT rises to that level (I see it as more > similar to chat state notifications). > > > *3. Permits maximum interoperability between widest possible variety of > > client implementations.* > > Maximum interoperability is possible between the maximum possible, > > widest-diverging implementations of real-time text activations: > > -- some clients will activate real time text right away (e.g. assistive > > clients) > > -- some clients will activate real-time text upon a button/menu/etc > > (e.g. mainstream) > > What do you mean by "activate"? My mainstream client might give me a > configuration option for allowing RTT, and not require me to click some > button every time someone sends me RTT data. > > However, if we're going to talk about information leakage, then the > leakage of keystroke data in RTT is much more significant than the > leakage of supported features in disco, so perhaps we do want clients to > warn users about that (you have that covered in Section 10.1 under the > security considerations). > > > -- some clients will not synchronize enabling of real-time text (e.g. > > unidirectional real time text) > > Do we think unidirectional RTT is a good idea? Please note that chat > state notifications are *not* unidirectional. > > > -- some recipients may or may not ask user for permission (e.g. like > > user prompt during audio/video activation) > > I assume you mean on a per-session basis. > > > -- some clients will keep real-time text private, but want to be > > signalled (see previous email, and reason #1) > > Here again, what does it mean to keep it private? Do you mean not > advertise the feature, or encrypt the RTT data end-to-end? > > > I want to point out that the fallback mechanism that I designed (blank > > rtt element), provides for maximum interopreability of real-time text > > *between ALL combinations of ALL the above scenarios. * This is > > "Accessible". I honestly believe I tried to design well on that basis > > -- even if it is not "engineer clean", it's pretty "human compatible" > > and "Accessible". Please rest assured I thought through subtle > > interaction scenarios, and some may have been missed. I am avoiding > > interop problems between willing senders/recipients, that end up not > > talking to each other, > > > Well, that's the reason we ended up taking that approach in XEP-0085 > (although, as noted, I think we could do better by using entity > capabilities and directed presence). > > > only because one end has lack of disco (including > > for any silly or stupid reason that we engineers disagree about). > > I really don't like designing protocols around buggy implementations! We > have service discovery and entity capabilities for good reasons. > > > I realize it may not be 100% perfect protocol design. But we engineers > > --> are designing for human-usable software. > > --> are designing for protocols that get popular more quickly because of > > flexibility (and maximum interop). > > --> more RTT means more deaf can do RTT, more accessible. > > Those are nice, but don't trump designing good protocols. > > > The more software that uses RTT, the more chances of successful RTT > > conversations. > > Even if I don't like some of the aspects (privacy considerations > > interfering with protocol), I am designing for a protocol that both > > small and big vendors like, as well as accessible and mainstream > > vendors. Maximum adoption is more important than a small petty privacy > > rule. > > And the controversy is just one sentence -- one that apparently already > > has precedent in a Final standard (XEP-0085 standard). > > The number of words is irrelevant. Your one sentence could be "clients > must disable all security" and you'd receive plenty of feedback. ;-) > > > However, I now recognize some of the wording choices used are poor. > > I am slimming down Section 5, and making it more professional -- but I > > plan to be keeping a fallback mechanism. > > Let's see what the list consensus turns out to be on this point. (I'll > save further comments regarding process for later, if needed.) > > Peter > > -- > Peter Saint-Andre > https://stpeter.im/ > > > > >
