[Standards] XEP-0301 -- starting and stopping real-time text in a chat session.

Mark Rejhon markybox at gmail.com
Sun Jul 1 07:20:41 UTC 2012


On 2012-07-01 2:22 AM, "Kurt Zeilenga" <kurt.zeilenga at isode.com> wrote:
>
>
> On Jun 30, 2012, at 3:10 PM, Mark Rejhon wrote:
>
>> Also, I've now modified Section 5 to leave the door open to alternative
sender signalling of a desire to turn on RTT, even when there's no disco
response.  This will also allow RTT to proceed in extenuating
circumstances, regardless of disco.
>
>
> I note that the discovery stuff needs some work.  Aside from the issues
already raised with disco stuff, I noticed that that XEP 301 doesn't talk
about use of Entity Capabilities.  It likely should have text similar to
XEP-0085.
>
> In order for an application to determine whether an entity supports this
protocol, where possible it SHOULD use the dynamic, presence-based profile
of service discovery defined in Entity Capabilities [4]. However, if an
application has not received entity capabilities information from an
entity, it SHOULD use explicit service discovery instead.
>

Ironically, I used caps instead of disco in the old 0.0.1 of the
specification, before it was accepted.

At this stage, most implementers have not yet implemented Section 5, since
most software at this stage up to now, are highly targeted software. This
is going to change, though.

If we must modify Section 5, then now is the time, if we have discovered a
flaw with Section 5.

It is necessary to keep the door open for implementers to let  the sender
to *signal* a desire to begin RTT, even when we are not sure a recipient
supports RTT, or have disco advertising turned off.  The recipient can just
ignore if they really want to (and unsupported clients ignore anyway) but
other implementors need to be able to choose to display a notification of
an incoming RTT attempt even in a reject (ignore) mode.  There is also the
emergency aspect, plus the other reasons already in my earlier messages.

I wonder if we need to re-evaluate Section 5 in order to make everyone
satisfied with the compromise.

I do think the blank <rtt/> is the simplest solution to solving the
problem, and as a side effect, actually makes certain implementations
simpler to write, than using disco+caps by putting signalling and detection
completely inline with the <rtt/> stream itself.  And it uses less
bandwidth to send one blank <rtt/> than either disco or caps, anyway.

I already suggested the blank <rtt/> idea earlier, and I agree Peter said
it was not xmpp-ish, but unfortunately, Kevin and Kurt has convinced me the
current Section 5 of XEP-0301 needs improvement.   There is an extenuating
exception of needing simpler signalling and detection for what potentially
might become an unexpectedly more-important-than-expected XMPP extensions
(when we look back on this in ten years from now)

The best compromise to the disagreeing POV's that I can see is:
-- certain implementers need to be able to ignore (as if unsupported) or
reject (cancel) incoming RTT, even turn off disco fully.
-- other implementors need senders to be able to at least send a simple
signal of a desire to do RTT, *even* to clients not advertising RTT
support.  Not just emergency, but it is also important for accessibility
reasons too.

The single blank <rtt/> satisfies this signal requirement in a very simple
manner, without bandwidth problems (brought up last year) or making the
specification complex.  I like putting it inline, as it simplifies the
libraries I am making.

Putting caps back into the spec (in addition to disco) is more complex,
more bandwidth, and not as appealing, but please feel free to suggest a few
models.

Mark Rejhon
On 2012-07-01 2:22 AM, "Kurt Zeilenga" <kurt.zeilenga at isode.com> wrote:

>
> On Jun 30, 2012, at 3:10 PM, Mark Rejhon wrote:
>
> Also, I've now modified Section 5 to leave the door open to alternative
> sender signalling of a desire to turn on RTT, even when there's no disco
> response.  This will also allow RTT to proceed in extenuating
> circumstances, regardless of disco.
>
>
> I note that the discovery stuff needs some work.  Aside from the issues
> already raised with disco stuff, I noticed that that XEP 301 doesn't talk
> about use of Entity Capabilities.  It likely should have text similar to
> XEP-0085.
>
> In order for an application to determine whether an entity supports this
> protocol, where possible it SHOULD use the dynamic, presence-based profile
> of service discovery defined in Entity Capabilities<http://xmpp.org/extensions/xep-0115.html>
>  [4 <http://xmpp.org/extensions/xep-0085.html#nt-id68055>]. However, if
> an application has not received entity capabilities information from an
> entity, it SHOULD use explicit service discovery instead.
>
> -- Kurt
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.jabber.org/pipermail/standards/attachments/20120701/84501e0c/attachment.html>


More information about the Standards mailing list