<p><br>
On 2012-07-01 2:22 AM, "Kurt Zeilenga" <<a href="mailto:kurt.zeilenga@isode.com">kurt.zeilenga@isode.com</a>> wrote:<br>
><br>
><br>
> On Jun 30, 2012, at 3:10 PM, Mark Rejhon wrote:<br>
><br>
>> 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.<br>

><br>
><br>
> 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.<br>

><br>
> 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.<br>

></p>
<p>Ironically, I used caps instead of disco in the old 0.0.1 of the specification, before it was accepted.</p>
<p>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.</p>
<p>If we must modify Section 5, then now is the time, if we have discovered a flaw with Section 5.</p>
<p>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.   </p>

<p>I wonder if we need to re-evaluate Section 5 in order to make everyone satisfied with the compromise.</p>
<p>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.</p>

<p>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)</p>

<p>The best compromise to the disagreeing POV's that I can see is:<br>
-- certain implementers need to be able to ignore (as if unsupported) or reject (cancel) incoming RTT, even turn off disco fully.<br>
-- 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.</p>

<p>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.</p>

<p>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.</p>
<p>Mark Rejhon</p>
<div class="gmail_quote">On 2012-07-01 2:22 AM, "Kurt Zeilenga" <<a href="mailto:kurt.zeilenga@isode.com">kurt.zeilenga@isode.com</a>> wrote:<br type="attribution"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div style="word-wrap:break-word"><br><div><div>On Jun 30, 2012, at 3:10 PM, Mark Rejhon wrote:</div><br><blockquote type="cite"><span style="border-collapse:separate;font-family:Helvetica;font-style:normal;font-variant:normal;font-weight:normal;letter-spacing:normal;line-height:normal;text-align:-webkit-auto;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;font-size:medium"><div>
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.</div>
</span></blockquote></div><br><div>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.</div>
<div><br></div><div><span style="font-family:Verdana,Arial,Helvetica,Geneva,sans-serif;line-height:16px;font-size:small">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 <span style="font-weight:bold"><a href="http://xmpp.org/extensions/xep-0115.html" style="color:rgb(51,102,153)" target="_blank">Entity Capabilities</a></span> [<a href="http://xmpp.org/extensions/xep-0085.html#nt-id68055" style="color:rgb(51,102,153)" target="_blank">4</a>]. However, if an application has not received entity capabilities information from an entity, it SHOULD use explicit service discovery instead.</span></div>
<div><span style="font-family:Verdana,Arial,Helvetica,Geneva,sans-serif;line-height:16px;font-size:small"><br></span></div><div>-- Kurt</div></div></blockquote></div>