Hi
I was reading XEP-0440 and noticed that since 2022-08 it requires
support for tls-server-end-point channel bindings.
I believe this is unfortunate because tls-server-end-point channel
binding are worse than either of tls-unique or tls-exporter.
Mandating support for this weak channel binding will detract from
efforts to implement the stronger tls-unique and tls-exporter. When
deciding what to prioritize, it may be that someone believes that since
XEP-0440 requires tls-server-end-point, it is more important to
implement it than spend time getting tls-exporter implemented. That
would be a bad outcome.
I suggest changing XEP-0440 to require tls-unique when TLS <= 1.2 is
used and tls-exporter when TLS >= 1.3 is used.
If you have already given up on supporting TLS <= 1.2 I think you
should only mandate tls-exporter as this is the best available channel
binding available.
I believe tls-server-end-point is generally best left unimplemented to
guide efforts towards supporting the stronger tls-exporter.
/Simon
The XMPP Extensions Editor has received a proposal for a new XEP.
Title: PubSub Server Information
Abstract:
This document defines a data format whereby basic information of an
XMPP domain can be expressed and exposed over pub-sub.
URL: https://xmpp.org/extensions/inbox/pubsub-server-info.html
The Council will decide in the next two weeks whether to accept this
proposal as an official XEP.
Hello,
first of all, this is my first attempted contribution to an Internet
standard, so I do apologize if the form is a bit off.
That said, I was implementing a parser for "XEP-0393: Message Styling",
and I ran into the issue that not much is defined in the way of escape
characters.
In Gajim, for instance, the sequence
*hello*
becomes bold, the sequence
\*hello*
does not, but the sequence
\\*hello*
also does not.
In many applications, preceding a \ with another \ escapes the latter \,
making it so that the escape character itself is escaped, and therefore
the * that creates the emphasis span would not be.
However, the standard does not mention any rule regarding this (and
Gajim does not do what I expect), so it is perhaps a good idea to add a
note about this before making it final.
Kind regards,
Werner
Version 0.2.0 of XEP-0483 (HTTP Online Meetings) has been released.
Abstract:
This specification defines a protocol extension to request URLs from
an external HTTP entity usable to initiate and invite participants to
an online meeting.
Changelog:
* Use XEP-0482 to send the meeting link to another party (do)
URL: https://xmpp.org/extensions/xep-0483.html
Note: The information in the XEP list at https://xmpp.org/extensions/
is updated by a separate automated process and may be stale at the
time this email is sent. The XEP documents linked herein are up-to-
date.
Version 1.0.0 of XEP-0458 (Community Code of Conduct) has been
released.
Abstract:
This document describes the XMPP Standard Foundation's Code of
Conduct.
Changelog:
Changed status to Active per Board vote on 2024-01-05. (psa)
URL: https://xmpp.org/extensions/xep-0458.html
Note: The information in the XEP list at https://xmpp.org/extensions/
is updated by a separate automated process and may be stale at the
time this email is sent. The XEP documents linked herein are up-to-
date.
On Wed, Jul 19, 2023 at 04:12:22PM +0200, Daniel Gultsch wrote:
>Hi Kev,
>
>council has accepted this XEP.
>
>cheers
>Daniel
>
>On Tue, Jul 4, 2023 at 3:56 PM <kevin.smith(a)isode.com> wrote:
>>
>> The XMPP Extensions Editor has received a proposal for a new XEP.
>>
>> Title: Reporting Account Affiliations
>> Abstract:
>> This specification documents a way for an XMPP server to report to
>> other entities the relationship it has with a user on its domain.
>>
>> URL: https://xmpp.org/extensions/inbox/xep-reporting-account-
>> affiliations.html
>>
>> The Council will decide in the next two weeks whether to accept this
>> proposal as an official XEP.
Bringing Up Matthews ProtoXEP
Incidents over the holidays reminded me of this one.
--
This friendly reminder brought to you by
Zash
Hello,
I have setup the membership application Wiki page for the application
period Q1 2024
Applications are encouraged from developers and others who are actively
involved in the Jabber/XMPP community. To apply, create a page about
yourself on the Wiki:
https://wiki.xmpp.org/web/Membership_Applications_Q1_2024
If you don't have a wiki account, send your full name, preferred
nickname and email address to me or one of the other Sysops:
https://wiki.xmpp.org/web/Sysops
Apply now!!!
Thanks,
Alex
Dear Editor,
Council has accepted this XEP.
Dear XEP author: Council has noted some overlap with XEP-0482. Please
get in touch with the authors of that XEP to see if you can merge
and/or remove the overlap. See Marvins earlier mail for details.
cheers
Daniel
Version 0.1.0 of XEP-0484 (Fast Authentication Streamlining Tokens)
has been released.
Abstract:
This specification defines a token-based method to streamline
authentication in XMPP, allowing fully authenticated stream
establishment within a single round-trip.
Changelog:
* Promoted to Experimental. (XEP Editor: kis)
URL: https://xmpp.org/extensions/xep-0484.html
Note: The information in the XEP list at https://xmpp.org/extensions/
is updated by a separate automated process and may be stale at the
time this email is sent. The XEP documents linked herein are up-to-
date.