<html><head><meta http-equiv="Content-Type" content="text/html; charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class=""><br class=""><div><br class=""><blockquote type="cite" class=""><div class="">On 23 Oct 2019, at 16:07, Jonas Schäfer (XSF Editor) <<a href="mailto:jonas@wielicki.name" class="">jonas@wielicki.name</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div class="">This message constitutes notice of a Last Call for comments on<br class="">XEP-0423.<br class=""><br class="">Title: XMPP Compliance Suites 2020<br class="">Abstract:<br class="">This document defines XMPP application categories for different use<br class="">cases (Core, Web, IM, and Mobile), and specifies the required XEPs<br class="">that client and server software needs to implement for compliance with<br class="">the use cases.<br class=""><br class="">URL: <a href="https://xmpp.org/extensions/xep-0423.html" class="">https://xmpp.org/extensions/xep-0423.html</a><br class=""><br class="">This Last Call begins today and shall end at the close of business on<br class="">2019-11-06.<br class=""><br class="">Please consider the following questions during this Last Call and send<br class="">your feedback to the <a href="mailto:standards@xmpp.org" class="">standards@xmpp.org</a> discussion list:<br class=""><br class="">1. Is this specification needed to fill gaps in the XMPP protocol<br class="">stack or to clarify an existing protocol?<br class=""></div></div></blockquote><div><br class=""></div><div>I don’t think the Compliance Suites are the right thing to be doing, but at the moment we don’t have anything better to address the ‘provide guidance to implementors’ need.</div><div><br class=""></div><blockquote type="cite" class=""><div class=""><div class="">2. Does the specification solve the problem stated in the introduction<br class="">and requirements?<br class=""></div></div></blockquote><div><br class=""></div><div>I think the addition of ’66 is well-intentioned, but <a href="jabber:x:oob" class="">jabber:x:oob</a> is underspecified (it defines a syntax, but semantics are missing).</div><div>I think 392 (consistent colours) is worth a mention, but not as a requirement at this stage.</div><div>I would rather see bookmarks2 as a requirement than 411, but don’t hugely care. What does a client need to do to implement 411 though?</div><div>I think 286 (LTE mobile) is worth a mention, but how would one be compliant with it as a client or server?</div><div>I note that while requiring TLS is right, I suspect very few, if any, implementations follow 7590 (and by extension 7525).</div><div>It’s also inconsistent to require 7590 (and 7525) in core, but direct TLS (which 7525 would need) only in advanced.</div><div><br class=""></div><br class=""><blockquote type="cite" class=""><div class=""><div class="">3. Do you plan to implement this specification in your code? If not,<br class="">why not?<br class=""></div></div></blockquote><div><br class=""></div><div>Not in the short term - I think the document is more useful as guidance than it is as a hard compliance test.</div><br class=""><blockquote type="cite" class=""><div class=""><div class=""><br class="">4. Do you have any security concerns related to this specification?<br class=""></div></div></blockquote><div><br class=""></div>I think ’66’s security considerations are likely not adequate for the current Internet (particularly around privacy).</div><div><br class=""><blockquote type="cite" class=""><div class=""><div class="">5. Is the specification accurate and clearly written?<br class=""></div></div></blockquote><div><br class=""></div><div>Mostly. The ‘Changes since 2019’ section is very useful.</div><div>My only note on this is that I think the introduction to “Future Development” isn’t right - these are protocols that aren’t ready to be required by the compliance suite, rather than not ready for production use.</div><div><br class=""></div><div>/K</div><div><br class=""></div></div></body></html>