[Members] Update on XMPP as mandatory standard for healthcare in the Netherlands
Guus der Kinderen
guus.der.kinderen at gmail.com
Mon Jun 22 08:12:49 UTC 2020
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.
Please keep us in the loop on how this progresses!
Pet peeve: The first paragraph has two places where there are two spaces
instead of one: between "around the NTA7516" and "interoperable instant
Similarly, there should not be a space between the sentence-ending
full-stop character after "healthcare" in the first paragraph.
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.
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?
of the vendors doesn’t have
The ones who do have external interfaces, don’t default to one protocol for
Is it "the ones who" or "the ones that"?
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
None of the present vendors articulated to use an alternative open standard
> for their chat.
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.
(...) to most logical to explore.
(...) *the* most logical to explore.
(...) the ‘2020 XMPP compliance suites’ (XEP-0423) is used
(...) are used
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
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.
To keep the extensions as standard as possible the ‘2020 XMPP compliance
> suites’ (XEP-0423) is used as base for the selection of extensions.
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
as base for
as *a* base for
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.
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?
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.
can be uses
can be *used*.
is standard in XMPP (RFC 7622)
is *standardized* in XMPP
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
To improve the readability of the addresses it can be advised to keep them
> the same as the e-mail addresses.
I'd replace that with something like:
Note that XMPP addresses use the same format as e-mail addresses. This
> similarity can, but needs not be, used to improve readability and
XMPP provides to possibility to to add SRV records to the domain of the
> address to point to a server in an other domain.
Too many usage of the word 'to'. Some are typos.
Also, I don't think that XMPP 'provides the possibility" - it's the defined
Maybe also refer to having the availability of alternative discovery of
connection methods, as specified in
The use of SRV records can be supported by the use of DNSSEC
I'd write instead:
DNSSEC can be applied to further improve security.
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).
then only technical aspects
"Than" instead of "then".
with the NTA7516
"with NTA7516" or "with the NTA7516 standard."
"sercurity" -> security
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
"All implementations user there" -> use their
"al clients" -> all clients
"notifications are send" -> sent.
On Sun, 21 Jun 2020 at 18:15, Winfried Tilanus <winfried at tilanus.com> wrote:
> Hi members,
> A quick update: after some bumps and politics we are right now coming to
> the point where vendors of messaging solutions in Dutch Healthcare have
> to reveal if they are really willing subject themselves to a
> standardization or if they are blocking it (what would be a political
> painful defeat). The moment of truth, so to speak. It would need to be
> accorded in the technical committee and the grand committee and then it
> can be worked out as a formal standard.
> Based on the discussions and feedback I have drafted a proposal of what
> the standard would look like. Any feedback is welcome! See:
> privacy strategist & privacy architect
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Members