On 09-Sep-22 04:08, Phillip Hallam-Baker wrote:
On Wed, Sep 7, 2022 at 6:13 PM Brian E Carpenter
<brian.e.carpenter@xxxxxxxxx <mailto:brian.e.carpenter@xxxxxxxxx>>
wrote:
On 08-Sep-22 08:00, S Moonesamy wrote:
Hello, At 10:06 AM 07-09-2022, Robert Sparks wrote:
After a series of trials used to gather feedback from the
community, the IETF has switched from Jabber to Zulip as its chat
service.
I assumed that XMPP was in wide use in the IETF community and
still in use on the internet. I gather that is not the case given
that RFC 6120 is following a path similar to RFC 959 [1]. It is
high time to consider what to do with "standards" which no longer
have community support.
Why? A Proposed Standard can sit on the books and does no harm.
Sometimes, it turns out that there is a whole user community for such
a standard that we don't know about, for some version of "we".
That is not really true. A proposed standard can and often does
prevent others trying to address a problem.
IMHO that's a minority case, but when it happens, it can be dealt with by formally obsoleting the problematic document or feature. Anecdotal evidence: I've done it. Several times in fact: RFC3879, RFC4048, RFC6563, RFC7526.
So if XMPP was actively harmful, we could obsolete it. But I don't think that's the case.
Brian
Before DPRIV, I proposed a DNS client-resolver protocol that
leveraged a TLS key exchange to secure a UDP based replacement
protocol. Two years later DPRIV was started and at the first meeting
we were told that this problem is so very very urgent, there is no
time to consider any proposals except for running DNS client
interactions over TLS because it 'had to be done in a year'.
Having seized the floor, sharp elbows stopped anyone from proposing a
practical approach to the problem until QUIC came along and the
absurdity of claiming Fast TCP start, a solution requiring a kernel
change would solve the performance problem became to much. So now,
eight years after I made my original proposal for DNS client-resolver
over UDP, there is finally an RFC but of course, much of the
deployment momentum has been dissipated.
We has the same problem today with DANE and security policy. Again
against my advice, DANE adopted an approach that is technically
defective. If you want to deploy security policy you have to consider
the whole process of service discovery. That means considering the
SRV and TXT records FIRST, not treating them as an afterthought. In
other words, start with RFC 6763 and work from there. That is the
approach I adopt in the Mesh.
draft-hallambaker-web-service-discovery-06 (ietf.org)
<https://datatracker.ietf.org/doc/html/draft-hallambaker-web-service-discovery-06>
I have a security policy system that works and is not tied to one
transport protocol. But I am pretty sure that I would face demands to
recast it in DANE terms because that is the 'proposed standard' even
though it is dead on its feet for everything but SMTP STARTTLS.
Recognizing that standards have failed or failed to thrive can be a
very valuable and positive contribution to the community because
recognizing failure clears the stage for possible success.
