[Standards] XEP-0301 Fallback Mechanism of Determining Support (Accessibility)
stpeter at stpeter.im
Tue Jul 10 19:13:32 UTC 2012
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 <stpeter at stpeter.im
> <mailto:stpeter at 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.
> > 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:
> 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
> 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
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
> 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
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
> 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
> -- 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
> -- 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
> 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
> 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.)
More information about the Standards