<div dir="ltr">Hi Winfried,<div><br></div><div>It would be exciting to see XMPP adopted here! Here are some comments ordered by paragraph. Note that I'm not a native speaker - take anyone's word over mine in that regard! Some of the following will be pedantic. Feel free to cherry-pick.</div><div><br></div><div>Please keep us in the loop on how this progresses!</div><div><br></div><div>Regards,</div><div><br></div><div>  Guus</div><div><br></div><div><br></div><div><b>First paragraph</b></div><div>Pet peeve: The first paragraph has two places where there are two spaces instead of one: between "around<u>  </u>the NTA7516" and "interoperable<u>  </u>instant messaging"</div><div><br></div><div>Similarly, there should not be a space between the sentence-ending full-stop character after "healthcare" in the first paragraph.</div><div><br></div><div><b>Second paragraph</b></div><div><b><br></b></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">In the technical working group for the chat part of the NTA 7516 norm the different functionalities for a secure interoperable chat and some implementation aspects were discussed.</blockquote><div><br></div><div>This reads like a casual, informal sentence. I generally suggest using the term "instant messaging" instead of "chat". I would rephrase the sentence. Also, maybe clarify what "discussing functionalities" entails. Did it cover functional aspects? Requirements? Security aspects? UI? Adoptability? Interop?</div><div><br></div><div><b>Third paragraph</b></div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">of the vendors doesn’t have</blockquote><div><br></div><div>don't have</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">The ones who do have external interfaces, don’t default to one protocol for that.</blockquote><div><br></div><div>Is it "the ones who" or "the ones that"?</div><div><br></div><div>I do not think that you'd "default" to one protocol - as that suggests that each implementation can use multiple protocols and have some kind of default setting which would be a shared protocol. Do you mean to say "Those solutions that do provide external interfaces do not make use of a standardized protocol."<br></div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">None of the present vendors articulated to use an alternative open standard for their chat.</blockquote><div><br></div><div>I'd not use the term 'present' as that introduces the context of people being physically in the same space. This turns your document a bit int a set of minutes or meeting summary.</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"> (...) to most logical to explore.<br></blockquote><div> <br></div><div>(...) <i>the</i> most logical to explore.</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">(...) the ‘2020 XMPP compliance suites’ (XEP-0423) is used<br></blockquote><div><br></div><div>(...) are used </div><div><br></div><div>I would add a couple more relevant (to your audience) characteristics of XMPP to this text. The objective here is to immediately make abundantly clear that XMPP is the logical choice, even to people that are not familiar with it. I'm thinking that for your audience, the fact that XMPP is an open standard, has a long track record with many mature implementations by as many different vendors, is secure, and has a built-in feature of federation are relevant.</div><div><br></div><div>Maybe split this paragraph into two paragraphs: the first that describes the current status quo, which leads up to the choice for XMPP, while the second highlights relevant aspects of XMPP.</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">To keep the extensions as standard as possible the ‘2020 XMPP compliance suites’ (XEP-0423) is used as base for the selection of extensions.<br></blockquote><div><br></div><div>To the uninitiated, this might be a confusing sentence. Also, it feels like overreaching to, in this document, immediately dictate their se.. I'd reword this text to include both a brief explanation of how compliance suites, in the larger community, have been defined to facilitate XEP selection, and that it'd be a logical choice to re-use that concept for your benefit.</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">as base for</blockquote><div><br></div><div>as <i>a</i> base for </div><div><br></div><div><b>Fourth paragraph</b></div><div><br></div><div>I'm not exactly sure what you're trying to write here. The paragraph starts off with a generic XMPP architecture (it describes federation), but further down the text, it seems to propose an architecture specific to the audience of this document.</div><div><br></div><div>Does this paragraph mean to say that the envisioned application of XMPP is thought to be limited to the domain-to-domain inter-communications, and that there is no requirement for individual vendors to re-implement large swats of product based on XMPP?</div><div><br></div><div>I would not use the words "certainly" ("certainly a vendor uses") or "like that" (XMPP has a standard interface for integrations like that." To me, that's very informal.</div><div><br></div><div><b>Fifth paragraph</b></div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"> can be uses<br></blockquote><div><br></div><div>can be <i>used</i>. </div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">is standard in XMPP (RFC 7622) </blockquote><div><br></div><div>is <i>standardized</i> in XMPP </div><div><br></div><div>What do you mean when referring to [organisation]? Is that a central authority, for example like a certificate CA? Hinting at a central authority can take away value from the federated, no-central-service aspect that you described in the paragraph above, if you do not carefully explain its role.</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">To improve the readability of the addresses it can be advised to keep them the same as the e-mail addresses.</blockquote><div><br></div><div>I'd replace that with something like:</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Note that XMPP addresses use the same format as e-mail addresses. This similarity can, but needs not be, used to improve readability and recognizability.</blockquote><div><br></div><div><b>Sixth paragraph</b></div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">XMPP provides to possibility to to add SRV records to the domain of the address to point to a server in an other domain.<br></blockquote><div><br></div><div>Too many usage of the word 'to'. Some are typos.</div><div><br></div><div>Also, I don't think that XMPP 'provides the possibility" - it's the defined standard way.</div><div><br></div><div>Maybe also refer to having the availability of alternative discovery of connection methods, as specified in <a href="https://xmpp.org/extensions/xep-0156.html">https://xmpp.org/extensions/xep-0156.html</a></div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">The use of SRV records can be supported by the use of DNSSEC</blockquote><div><br></div><div>I'd write instead:</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">DNSSEC can be applied to further improve security. </blockquote><div><br></div><div><b>Seventh paragraph</b></div><div><br></div><div>(no comment)</div><div><br></div><div><b>Eight paragraph</b></div><div><br></div><div>Although I understand the desire to not want to include E2E encryption in this particular phase, the concept of E2E should be very appealing to your audience, as they're in the business of sharing privacy-sensitive information. Your text reads as a firm dismissal (which I don't think you intend it to be). I'd emphasize that XMPP has support for E2E encryption, but that, at this stage, you're not going to include it just yet (for reasons of x, y, and z).</div><div><br></div><div><b>Ninth paragraph</b></div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">then only technical aspects</blockquote><div><br></div><div>"Than" instead of "then".</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">with the NTA7516</blockquote><div><br></div><div>"with NTA7516" or "with the NTA7516 standard."</div><div><br></div><div>"sercurity" -> security<br></div><div><br></div><div><b>Remainder</b></div><div>You end by giving a set of mandatory and optional to implement features (XEPs, mostly). People will wonder how having optional functionality will affect interop. I'd mention that XMPP is specifically designed to allow interoperability in a network where each participant has a different set of supported features.</div><div><br></div><div>"All implementations user there" -> use their</div><div><br></div><div>"al clients" -> all clients</div><div><br></div><div>"notifications are send" -> sent.<br></div><div><br></div><div><br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Sun, 21 Jun 2020 at 18:15, Winfried Tilanus <<a href="mailto:winfried@tilanus.com">winfried@tilanus.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Hi members,<br>
<br>
A quick update: after some bumps and politics we are right now coming to<br>
the point where vendors of messaging solutions in Dutch Healthcare have<br>
to reveal if they are really willing subject themselves to a<br>
standardization or if they are blocking it (what would be a political<br>
painful defeat). The moment of truth, so to speak. It would need to be<br>
accorded in the technical committee and the grand committee and then it<br>
can be worked out as a formal standard.<br>
<br>
Based on the discussions and feedback I have drafted a proposal of what<br>
the standard would look like. Any feedback is welcome! See:<br>
<a href="https://tilanus.com/dav/index.php/s/w35zKwqFDLRioP6" rel="noreferrer" target="_blank">https://tilanus.com/dav/index.php/s/w35zKwqFDLRioP6</a><br>
<br>
Winfried<br>
<br>
-- <br>
privacy strategist & privacy architect<br>
+31.6.23303960<br>
<a href="https://www.tilanus.com/" rel="noreferrer" target="_blank">https://www.tilanus.com/</a><br>
</blockquote></div>