Re: Discontinuing XMPP support after IETF 115

[Brian E Carpenter <[e-mail]>]

On 09-Sep-22 04:08, Phillip Hallam-Baker wrote:
> 
> 
> On Wed, Sep 7, 2022 at 6:13 PM Brian E Carpenter
> <[e-mail] <mailto:[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.

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.
>