[Standards] Proposed XMPP Extension: XMPP Compliance Suites 2020

[XSF Editor]

The XMPP Extensions Editor has received a proposal for a new XEP.

Title: XMPP Compliance Suites 2020
Abstract:
This document defines XMPP protocol compliance levels.

URL: https://xmpp.org/extensions/inbox/cs-2020.html

The Council will decide in the next two weeks whether to accept this
proposal as an official XEP.
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] XEP-0288 - Bidi - Maybe CFE?

[Ruslan N. Marchenko]

Am Dienstag, den 03.09.2019, 10:58 + schrieb Maxime “pep” Buquet:
> On September 3, 2019 10:55:18 AM UTC, Dave Cridland <
> d...@cridland.net> wrote:
> > Thanks for your snappy response.
> > 
> > On Mon, 2 Sep 2019 at 18:13, Ruslan Marchenko  wrote:
> > 
> > > Hi,
> > > 
> > > I've recently realized my bidi implementation lacks SASL External
> > > outbound support - but when trying to implement it I figured my
> > > bidi
> > > external test now fails because the target I used earlier for
> > > BIDI
> > > end2end test (metronome.im) now dropped its support. So now
> > > wonder
> > > whether there's any known issue with this so that no one supports
> > > it in
> > > the wild? I have always thought this is the future state of s2s
> > > and
> > > sooner or later everyone would move to it but it looks quite
> > opposite.
> 
> Not sure where you got this impression. There's actually quite a few
> servers lately with bidi support since it's been marked as "stable"
> in prosody modules. Somebody had stats on prosody@ iirc.
> 
Maybe after seeing this features from prosody.im

and from many others I've tried. But I'm happpy to be wrong here and be
seeing growing implementation base.

Regards,
Ruslan

___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] Council Minutes 2019-08-28

[Georg Lukas]

* Tedd Sterr  [2019-09-02 22:00]:
> 4a) Advance to Draft: XEP-0300 (Use of Cryptographic Hash Functions in XMPP) 
> - https://xmpp.org/extensions/xep-0300.html

+1

> 4b) Advance to Draft: XEP-0353 (Jingle Message Initiation) - 
> https://xmpp.org/extensions/xep-0353.html
> Georg needs to review the XEP for MAM and Carbons side-effects.

Reviewed, and commented in the original thread.

-1, as I'm sure we need to change a non-empty sub-set of {0280, 0313,
0353, 0357} to make this sound.


Georg


signature.asc
Description: PGP signature
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] LAST CALL: XEP-0353 (Jingle Message Initiation)

[Georg Lukas]

* Philipp Hancke  [2019-09-03 14:15]:
> 0353 was explicitly designed for push (by not including the full payload due
> to size constraints) in conjunction with 0357 and should not go to MAM
> (hence no body).

Let's imagine the following:

- 0353 or 0313 get changed to store all 0353 messages into MAM

- a remote entity sends a 
- the user's server stores the  into MAM
- 0357 triggers a push on this new MAM message
- the (mobile) client connects and fetches MAM
- the client sees a  that was neither retracted, rejected or
  accepted and is sufficiently recent (say, last 30 second)
- the client s the call

@Andrew, would this be sufficient to make the protocol work for your iOS
case?

A side benefit of this would be that both the call itself and whether it
was accepted/rejected is stored in MAM and can be displayed in the
client's message history.


Speaking of 0353 as is, it was also not designed for Carbons. I think we
should explicitly make use of Carbons (by similar means as with MAM), so
that we do not need separate  (to self) and  (to the
initator) messages. Instead, the  will be carbon-copied to all
other resources, letting them know that one client accepted the call.



Georg
-- 
|| http://op-co.de ++  GCS d--(++) s: a C+++ UL+++ !P L+++ !E W+++ N  ++
|| gpg: 0x962FD2DE ||  o? K- w---() O M V? PS+ PE-- Y++ PGP+ t+ 5 R+  ||
|| Ge0rG: euIRCnet ||  X(+++) tv+ b+(++) DI+++ D- G e h- r++ y?   ||
++ IRCnet OFTC OPN ||_||


signature.asc
Description: PGP signature
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] Council Minutes 2019-08-28

[Dave Cridland]

On Tue, 3 Sep 2019 at 16:38, Kevin Smith  wrote:

> On 2 Sep 2019, at 20:57, Tedd Sterr  wrote:
>
>
> *4a) Advance to Draft: XEP-0300 (Use of Cryptographic Hash Functions in
> XMPP)* - https://xmpp.org/extensions/xep-0300.html
> Georg: [on-list]
> Jonas: +1 (I think)
> Dave: +1 (I think)
> Link: [on-list]
> Kev: [pending]
>
> Georg doesn't think Table 1 belongs in the XEP, rather in an Informational
> XEP or a registry; Dave thinks the ideal solution would be registering the
> names with IANA - Jonas notes that that would require an RFC which updates
> RFC 3279 [1]. Georg is unsure whether the table is subject to change, but
> will vote +1 if it's guaranteed to remain as-is.
>
>
> I agree that Table 1 is problematic. It’s there to supplement the IANA
> registry, but things we want to supplement that with are likely to change
> over time. That said, the registry itself is subject to change over time,
> so I’m not sure in practical terms that this table changing post-Draft
> would be different to that. So I think +1 is ok here.
>
> *4b) Advance to Draft: XEP-0353 (Jingle Message Initiation)* -
> https://xmpp.org/extensions/xep-0353.html
> Georg: [on-list]
> Jonas: [on-list] (default to -0)
> Dave: +1 (seems widely deployed and sensible)
> Link: [on-list] (default to +1)
> Kev: [pending]
>
> Jonas has little knowledge of Jingle, and there was no LC feedback.
> Georg needs to review the XEP for MAM and Carbons side-effects.
> Jonas questions whether it is widely deployed, given the total lack of
> feedback during the month-long LC - Dave suggests that might be due to low
> energy and engagement - Jonas will send a mail to the list [2].
>
>
> The (belated) LC feedback seems to suggest outstanding questions that need
> answering before this is advanced, to me, so -1 until there’s a clearer
> picture.
>

I concur - I'll change my vote to -1 accordingly.


>
> /K
> ___
> Standards mailing list
> Info: https://mail.jabber.org/mailman/listinfo/standards
> Unsubscribe: standards-unsubscr...@xmpp.org
> ___
>
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] LAST CALL: XEP-0353 (Jingle Message Initiation)

[Andrew Nenakhov]

вт, 3 сент. 2019 г. в 19:15, Ralph Meijer :>
> Hi,
>
> Let me start out saying that, like Philipp, my reading of the current
> version of XEP-0353 is also that there is additional information shared
> with the client over FCM/APNS. However, I must also say that neither
> XEP-0353 nor XEP-357 make it clear how this should work exactly. This is
> a problem, because it results in proprietary solutions for doing the
> same thing. At minimum this should get another look and more concrete
> examples with how existing push services would *actually* be used.
>
> Andrew's description of their use of XEP-0353 introduces new elements in
> the existing namespace, and adds a new iq-based exchange. Assuming this
> is an experiment, I do want to point out that before it would go into
> actual use, those would need to be moved to their own private namespace,
> or be included in a next version of this specification (which might
> require a new namespace).

I agree that our approach changes 0353 significantly. Since we DID
implement 0353 in its current form to the letter and discovered that
it can't work well on iOS without additional roundtrip. So it is
unlikely we'll support this XEP without changes. If our approach won't
be accepted into 0353, we'll move it to another namespace and treat is
as a new protocol, and will be implementing it (or another working
solution, if one emerges) instead of non-working one.

As for passing additional information over FCM/APNS. This data goes
totally unencrypted over third party entities, one of which has very
little public trust with matters concerning privacy. The mechanics of
these services prevent payload from being encrypted, so it's what it
is: some meaningful data will go in plain open form over untrusted
networks. If we start doing that, why really stop at 'additional
data'? We could have saved ourselves tons of blood and sweat spent at
making iOS client wake up on notification, connect to a server, fetch
recent messages, check their markers and present only an actual
message to users, all of this in fewer than 30 seconds. Instead, we
could have just displayed banner with a message in a standard open
way, without even establishing a connection, and all we had to do is
agree to send message contents to Apple/Google. No big deal, right?

While I'm not at all jumping on this full e2ee & full stanza
encryption bandwagon, compromising user privacy this way is a no go
for us.

> In the mean while it can present the screen for allowing the user to
> accept the call. As soon as the slow human user then presses 'accept'
> you're immediately good to go and fully establish the call. This saves
> several round-trips, and thus many centiseconds compared to XEP-0353 in
> its current form, and even more if you have a model that relies on
> re-establishing the XMPP connection before starting all of the above.

Of course, it is faster and simpler to do it this way! But at what
cost? Agan, If we start developing the fastest solution, we'll
eventually come up with some CA service that manages calls directly,
fully bypassing XMPP. Is that what we want?

-- 
Andrew Nenakhov
CEO, redsolution, OÜ
https://redsolution.com
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] Council Minutes 2019-08-28

[Kevin Smith]

On 2 Sep 2019, at 20:57, Tedd Sterr  wrote:
> 
> 4a) Advance to Draft: XEP-0300 (Use of Cryptographic Hash Functions in XMPP) 
> - https://xmpp.org/extensions/xep-0300.html 
> 
> Georg: [on-list]
> Jonas: +1 (I think)
> Dave: +1 (I think)
> Link: [on-list]
> Kev: [pending]
> 
> Georg doesn't think Table 1 belongs in the XEP, rather in an Informational 
> XEP or a registry; Dave thinks the ideal solution would be registering the 
> names with IANA - Jonas notes that that would require an RFC which updates 
> RFC 3279 [1]. Georg is unsure whether the table is subject to change, but 
> will vote +1 if it's guaranteed to remain as-is.

I agree that Table 1 is problematic. It’s there to supplement the IANA 
registry, but things we want to supplement that with are likely to change over 
time. That said, the registry itself is subject to change over time, so I’m not 
sure in practical terms that this table changing post-Draft would be different 
to that. So I think +1 is ok here.

> 4b) Advance to Draft: XEP-0353 (Jingle Message Initiation) - 
> https://xmpp.org/extensions/xep-0353.html 
> 
> Georg: [on-list]
> Jonas: [on-list] (default to -0)
> Dave: +1 (seems widely deployed and sensible)
> Link: [on-list] (default to +1)
> Kev: [pending]
> 
> Jonas has little knowledge of Jingle, and there was no LC feedback.
> Georg needs to review the XEP for MAM and Carbons side-effects.
> Jonas questions whether it is widely deployed, given the total lack of 
> feedback during the month-long LC - Dave suggests that might be due to low 
> energy and engagement - Jonas will send a mail to the list [2].

The (belated) LC feedback seems to suggest outstanding questions that need 
answering before this is advanced, to me, so -1 until there’s a clearer picture.

/K___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] LAST CALL: XEP-0353 (Jingle Message Initiation)

[Ralph Meijer]

On 03/09/2019 15.02, Andrew Nenakhov wrote:



вт, 3 сент. 2019 г. в 17:14, Philipp Hancke >:


0353 was explicitly designed for push (by not including the full
payload
due to size constraints) in conjunction with 0357 and should not go to
MAM (hence no body).

This has some sad consequences like the lack of a message acting as a
call data record in the users history.


We're using Processing hints  element to make an archive store 
such messages. https://xmpp.org/extensions/xep-0313.html#hints


The way 0353 is supposed to work is:
1) you are offline but have a push-enabled client
(there is the more interesting scenario where some clients of yours are
online but none does jingle... and you would need to send a push
notification to your offline client that does... that is a generic
issue
however)
2) you get a push notification with the  element and know the
senders full jid, the session id and (FYI) the media types involved

3) your client requests that session at the sender. If that session
doesn't exist anymore the sender will respond with a message stanza
with
type=error and  (and potentially the jingle



No, I think push notifications do not work the way you describe. 
XEP-0357 says that a published  MAY contain additional 
custom information, however, all our implementations of Push 
notifications assume that NO additional information is relayed through 
third-party services (ejabberd, as I recall, doesn't even support 
publishing such additional information). Thus, we get NO  in 
push notifications, NO message text, nothing. Just notification to an 
app that it should wake up and update its data. Consequently, the only 
ways we can get this information are MAM and offline messages/ Since 
offline messages perform poorly when there are multiple user devices, it 
leaves us with just MAM.


I strongly oppose any suggestions to make push notifications work 
differently. If we start sending payload about calls via FCM/APNS, why 
stop at calls? We can just send full message text via push notifications 
as Telegram does. And at that point, why messing with XMPP at all? An 
FCM-only messenger can be coded in a week, it'll send and receive full 
message text via FCM, store messages on FCM cloud database and all will 
work admirably well.


Hi,

Let me start out saying that, like Philipp, my reading of the current
version of XEP-0353 is also that there is additional information shared
with the client over FCM/APNS. However, I must also say that neither
XEP-0353 nor XEP-357 make it clear how this should work exactly. This is
a problem, because it results in proprietary solutions for doing the
same thing. At minimum this should get another look and more concrete
examples with how existing push services would *actually* be used.

Andrew's description of their use of XEP-0353 introduces new elements in
the existing namespace, and adds a new iq-based exchange. Assuming this
is an experiment, I do want to point out that before it would go into
actual use, those would need to be moved to their own private namespace,
or be included in a next version of this specification (which might
require a new namespace).

With that all out of the way, let me describe what we did at VEON, as I
briefly alluded to in my presentation at the Summit [1]. Our approach
made calls server-mediated. I.e. the Jingle session-initiate was sent to
the callee's bare JID (their 'account'). The server then could send the
IQ on to online resources or via FCM/APNS. The latter notifications
actually did carry payload, including the media descriptions and
transport information (candidates).

The primary reason for doing it like this is speeding up the
negotiation. A receiving client can:

 * start evaluating the payload
 * configure the media library (in our case libwebrtc) to start media
streams on the device
 * re-establish the XMPP connection to the server
 * possibly request credentials for TURN
 * set up a TURN connection
 * retrieve vCards / avatars for the caller
 * etc.

In the mean while it can present the screen for allowing the user to
accept the call. As soon as the slow human user then presses 'accept'
you're immediately good to go and fully establish the call. This saves
several round-trips, and thus many centiseconds compared to XEP-0353 in
its current form, and even more if you have a model that relies on
re-establishing the XMPP connection before starting all of the above.

I want to note that our use cases where the XMPP connection might have
high latency but the actual media flows are local (even within office
networks).

Obviously, we also ran into the issue that notification payloads have
size limits. Thiago Camargo wrote a specialized compression library,
Shogun, to tackle this. It relies on a pre-shared dictionary for better
compression.

[1] 

--
Cheers,

ralph

Re: [Standards] LAST CALL: XEP-0353 (Jingle Message Initiation)

[Andrew Nenakhov]

вт, 3 сент. 2019 г. в 17:14, Philipp Hancke :

> 0353 was explicitly designed for push (by not including the full payload
> due to size constraints) in conjunction with 0357 and should not go to
> MAM (hence no body).
>
> This has some sad consequences like the lack of a message acting as a
> call data record in the users history.
>

We're using Processing hints  element to make an archive store such
messages.  https://xmpp.org/extensions/xep-0313.html#hints

> The way 0353 is supposed to work is:
> 1) you are offline but have a push-enabled client
> (there is the more interesting scenario where some clients of yours are
> online but none does jingle... and you would need to send a push
> notification to your offline client that does... that is a generic issue
> however)
> 2) you get a push notification with the  element and know the
> senders full jid, the session id and (FYI) the media types involved
>
3) your client requests that session at the sender. If that session
> doesn't exist anymore the sender will respond with a message stanza with
> type=error and  (and potentially the jingle
> 
>

No, I think push notifications do not work the way you describe. XEP-0357
says that a published  MAY contain additional custom
information, however, all our implementations of Push notifications assume
that NO additional information is relayed through third-party services
(ejabberd, as I recall, doesn't even support publishing such additional
information). Thus, we get NO  in push notifications, NO message
text, nothing. Just notification to an app that it should wake up and
update its data. Consequently, the only ways we can get this information
are MAM and offline messages/ Since offline messages perform poorly when
there are multiple user devices, it leaves us with just MAM.

I strongly oppose any suggestions to make push notifications work
differently. If we start sending payload about calls via FCM/APNS, why stop
at calls? We can just send full message text via push notifications as
Telegram does. And at that point, why messing with XMPP at all? An FCM-only
messenger can be coded in a week, it'll send and receive full message text
via FCM, store messages on FCM cloud database and all will work admirably
well.

-- 
Andrew Nenakhov
CEO, redsolution, OÜ
https://redsolution.com 
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] LAST CALL: XEP-0353 (Jingle Message Initiation)

[Philipp Hancke]

Am 29.08.19 um 13:24 schrieb Andrew Nenakhov:

I might be late to the party. This email was sent by me on August 03 after
changing my email address and resubscribing to this list, but it seems that
I wasn't put through. My points against XEP-0353 in current form still
stand. I obviously missed all conversations here in August, so I might need
to catch up on this though.

сб, 3 авг. 2019 г. в 21:04, Andrew Nenakhov 
:



вт, 30 июл. 2019 г. в 23:42, Jonas Schäfer :


1. Is this specification needed to fill gaps in the XMPP protocol
stack or to clarify an existing protocol?



Yes.




2. Does the specification solve the problem stated in the introduction
and requirements?



Partially. This specification is not suitable to work with clients that
rely on push notifications and fetching messages from an archive.


0353 was explicitly designed for push (by not including the full payload 
due to size constraints) in conjunction with 0357 and should not go to 
MAM (hence no body).


This has some sad consequences like the lack of a message acting as a 
call data record in the users history.



3. Do you plan to implement this specification in your code? If not,

why not?



We have implemented this specification on iOS client, and discovered that
it is unsuitable in real life scenarios. We have updated it with additional
callback routine, the changes and stanza format is described here:

https://docs.google.com/document/d/1geR2-VlKkjwqFftstV7O1cYfGqKQy-eEUepgRrge0ow/edit

This modified solution does the job. We have also created a test bot for
testing automated VoIP calling, bot's address is dev...@dev.xabber.com
(calling bot works well, receiving calls from bot has some bugs at the
moment). One may perform calls using preview version
 of Xabber for
iOS (it's under construction at the moment and has quite a number of bugs,
but VoIP is mostly working by now).


I wanted to reply to your post in June but seems I never did :-(

What you are describing is a different protocol. If you go via the users 
MAM archive then you could simply initiate with a full session 
description as payload. Its been a while there since we wrote that up 
but I think the complexity of getting that to work turned out to be too 
high which would match your experience.


The way 0353 is supposed to work is:
1) you are offline but have a push-enabled client
(there is the more interesting scenario where some clients of yours are 
online but none does jingle... and you would need to send a push 
notification to your offline client that does... that is a generic issue 
however)
2) you get a push notification with the  element and know the 
senders full jid, the session id and (FYI) the media types involved
3) your client requests that session at the sender. If that session 
doesn't exist anymore the sender will respond with a message stanza with 
type=error and  (and potentially the jingle 




4. Do you have any security concerns related to this specification?




Yes. Security considerations does not cover the issue of private
information exposure (IP address) to remote party when taking part in a
jingle session. This is covered in XEP-0166 Security Considerations though,
but I think it should make sense that taking part in jingle session not
only results in a presence leak, but also in disclosure of IP.


That is a generic jingle-related concern, no? There is a potential 
presence/resource leak in section 3.4 example 10 though as the initiator 
is *optionally* told about the rejection.


cheers

Philipp
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] LAST CALL: XEP-0353 (Jingle Message Initiation)

[Philipp Hancke]

Am 29.08.19 um 11:06 schrieb Dave Cridland:

On Thu, 29 Aug 2019 at 09:09, Daniel Gultsch  wrote:


Am Di., 30. Juli 2019 um 18:42 Uhr schrieb Jonas Schäfer <
jo...@wielicki.name>:

1. Is this specification needed to fill gaps in the XMPP protocol
stack or to clarify an existing protocol?


Yes


2. Does the specification solve the problem stated in the introduction
and requirements?


I don’t know yet. I haven’t implemented it.


3. Do you plan to implement this specification in your code? If not,
why not?


I do have plans to implement this (hopefully by the end of this year~ish)

Given the low number of implementations I would suggest to wait a
little longer until we have more experience.



I was under the impression that there were a few implementations of this
around, actually - anyone care to chime in? Fippo, perhaps, or Андрей?


Some people chimed in at
  https://mail.jabber.org/pipermail/standards/2019-March/035884.html
back in march. If OTOH we have promises of feedback it might be worth 
postponing the LC again...

___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] XEP-0288 - Bidi - Maybe CFE?

[Maxime “pep” Buquet]

On September 3, 2019 10:55:18 AM UTC, Dave Cridland  wrote:
>Thanks for your snappy response.
>
>On Mon, 2 Sep 2019 at 18:13, Ruslan Marchenko  wrote:
>
>> Hi,
>>
>> Am 11.01.2019 um 15:04 schrieb Philipp Hancke:
>> > Am 18.12.18 um 09:45 schrieb Dave Cridland:
>> >> Hi folks,
>> >>
>> >> I'm thinking of asking the Editor to issue a Call For Experience
>on
>> >> XEP-0288.
>> >>
>> >> I would do so now, but I'm not entirely sure who actually
>implements it.
>> >>
>> >> So, who does implement it? (And is your implementation open
>source)?
>> >
>> > I did, a long time ago in psyced. Its opensource but hasn't changed
>in
>> > ages. I still use it and it continues to work -- even though i seem
>to
>> > have had quite some issues with Dave's server at times.
>> >
>> > Its still useful, I always considered one-way s2s a bug caused by
>weak
>> > (or lacking) authentication mechanism in the initial design.
>> >
>> I've recently realized my bidi implementation lacks SASL External
>> outbound support - but when trying to implement it I figured my bidi
>> external test now fails because the target I used earlier for BIDI
>> end2end test (metronome.im) now dropped its support. So now wonder
>> whether there's any known issue with this so that no one supports it
>in
>> the wild? I have always thought this is the future state of s2s and
>> sooner or later everyone would move to it but it looks quite
>opposite.
>>

Not sure where you got this impression. There's actually quite a few servers 
lately with bidi support since it's been marked as "stable" in prosody modules. 
Somebody had stats on prosody@ iirc.


-- 
Maxime “pep” Buquet
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] XEP-0288 - Bidi - Maybe CFE?

[Dave Cridland]

Thanks for your snappy response.

On Mon, 2 Sep 2019 at 18:13, Ruslan Marchenko  wrote:

> Hi,
>
> Am 11.01.2019 um 15:04 schrieb Philipp Hancke:
> > Am 18.12.18 um 09:45 schrieb Dave Cridland:
> >> Hi folks,
> >>
> >> I'm thinking of asking the Editor to issue a Call For Experience on
> >> XEP-0288.
> >>
> >> I would do so now, but I'm not entirely sure who actually implements it.
> >>
> >> So, who does implement it? (And is your implementation open source)?
> >
> > I did, a long time ago in psyced. Its opensource but hasn't changed in
> > ages. I still use it and it continues to work -- even though i seem to
> > have had quite some issues with Dave's server at times.
> >
> > Its still useful, I always considered one-way s2s a bug caused by weak
> > (or lacking) authentication mechanism in the initial design.
> >
> I've recently realized my bidi implementation lacks SASL External
> outbound support - but when trying to implement it I figured my bidi
> external test now fails because the target I used earlier for BIDI
> end2end test (metronome.im) now dropped its support. So now wonder
> whether there's any known issue with this so that no one supports it in
> the wild? I have always thought this is the future state of s2s and
> sooner or later everyone would move to it but it looks quite opposite.
>

Interesting.

OK, how about this - is there any interest in running an interopathon
across a few days where people have bidi-enabled domains available?

Dave.
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___