Re: Discontinuing XMPP support after IETF 115

[Phillip Hallam-Baker <[e-mail]>]

On Wed, Sep 7, 2022 at 6:13 PM Brian E Carpenter <
[e-mail]> 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.

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.