Re: [Standards] Proper SRV Record Fallback

Wed, 10 Jan 2018 01:47:46 -0500 Travis Burtrum wrote: > Which question have I not addressed? Rephrasing, the question about what to consider a success connection. We have several phases of stream negotiation (not to mention mam or roster queries).

Re: [Standards] Proper SRV Record Fallback

On January 10, 2018 12:55:06 AM EST, Evgeny Khramtsov wrote: >Tue, 9 Jan 2018 21:28:55 -0500 >Travis Burtrum wrote: > >> Is there any reason why any client would rather fail and show a >> 'cannot connect' to a user rather than actually allowing them to

Re: [Standards] Proper SRV Record Fallback

Tue, 9 Jan 2018 21:28:55 -0500 Travis Burtrum wrote: > Is there any reason why any client would rather fail and show a > 'cannot connect' to a user rather than actually allowing them to > connect? I can't actually think of one. You continue ignoring the question about all

Re: [Standards] Proper SRV Record Fallback

On 01/09/2018 03:58 PM, Marcel Waldvogel wrote: > Is there a mechanism a client can determine whether ALPN is needed for a > particular SRV entry? (Besides guessing based on the port number) No. In fact it wouldn't even fit on a SRV record level. For instance I have 1 SRV record pointing to

Re: [Standards] Proper SRV Record Fallback

On 01/09/2018 05:55 AM, Florian Schmaus wrote: > On 09.01.2018 05:19, Travis Burtrum wrote: >> It is also clear I didn't think about this too hard when writing >> XEP-0368, because I clearly (to me) assume SRV fallback will happen if a >> complete XMPP connection is not successful, because under

Re: [Standards] Proper SRV Record Fallback

On 01/09/2018 05:03 AM, Dave Cridland wrote: > On 9 January 2018 at 04:19, Travis Burtrum wrote: >> In my opinion, at least all of cannot-connect-to-port, non-XML, >> not-proper-stream and invalid TLS cert should trigger a fallback to the >> next highest priority SRV record.

Re: [Standards] Proper SRV Record Fallback

Is there a mechanism a client can determine whether ALPN is needed for a particular SRV entry? (Besides guessing based on the port number) -MarcelOn Tue, 2018-01-09 at 21:54 +0100, Philipp Hörist wrote: > Hi, > Currently ALPN is only a SHOULD for the client implicating that the > XEP will work

Re: [Standards] Proper SRV Record Fallback

Hi, Currently ALPN is only a SHOULD for the client implicating that the XEP will work also without ALPN. For that reason the XEP states that a server admin should also provide other records not using ALPN to which the client can fallback. What is not clear from the XEP, and did come as a

Re: [Standards] Proper SRV Record Fallback

On Dienstag, 9. Januar 2018 11:55:15 CET Florian Schmaus wrote: > - Invalid XML (how could that happen BTW?) When you end up at an HTTP service instead (will probably be the default on services which run on 443). You send XML (stream header), you get 400 Bad Request back. kind regards, Jonas

[Standards] XMPP Council Meeting, 2018-01-10 1600Z

Folks, The XMPP Council will be holding it's first meeting of 2018 tomorrow at 1600 UTC. We organise the agenda on Trello at https://trello.com/b/ww7zWMlI/xmpp-council-agenda and I (try to) send out the final agenda about 24 hours in advance. Agenda as follows: 1) Roll Call 2) Discuss of how

Re: [Standards] Proposal: Server selection for user-registration

That list contains only very basic information though. An ideal list would combine the results from the TLS tester, the compliance tester and some uptime monitor. Those tools need to be improved. I imagine most client developers wouldn't necessarily want to download the list automatically but

Re: [Standards] Proposal: Server selection for user-registration

We currently have a pre-existing central directories of XMPP domains at https://xmpp.net/directory.php - the code powering the observatory is available (the most up-to-date code is in Jonas' repo: https://github.com/horazont/xmppoke-frontend-docker ) The upside of that project is that it's an

[Standards] Feedback (was: Proposal: Server selection for user-registration)

Am 09. Januar 2018 um 07:39 Uhr +0100 schrieb Daniel Gultsch: > It's more important to > have the tools than to bikeshed about how to use them. Thanks. First hammer the nail in, and then think where it should have gone. Nice idea. To return from personal argumenting to more useful one, the

Re: [Standards] Proper SRV Record Fallback

On 09.01.2018 12:08, Evgeny Khramtsov wrote: > Tue, 9 Jan 2018 11:55:15 +0100 > Florian Schmaus wrote: > >> A client supporting xep368 but not ALPN would > > This sounds like asking for troubles ;) Since one of the use case of > XEP-0368 is multiplexing and you cannot do this

Re: [Standards] Proper SRV Record Fallback

Tue, 9 Jan 2018 11:55:15 +0100 Florian Schmaus wrote: > A client supporting xep368 but not ALPN would This sounds like asking for troubles ;) Since one of the use case of XEP-0368 is multiplexing and you cannot do this easily without ALPN. > 2. xep368 makes ALPN mandatory

Re: [Standards] Proper SRV Record Fallback

On 09.01.2018 11:03, Dave Cridland wrote: > On 9 January 2018 at 04:19, Travis Burtrum wrote: >> In my opinion, at least all of cannot-connect-to-port, non-XML, >> not-proper-stream and invalid TLS cert should trigger a fallback to the >> next highest priority SRV record.

Re: [Standards] Proper SRV Record Fallback

On 09.01.2018 05:19, Travis Burtrum wrote: > It is also clear I didn't think about this too hard when writing > XEP-0368, because I clearly (to me) assume SRV fallback will happen if a > complete XMPP connection is not successful, because under Implementation > Notes I say: > >> Server operators

Re: [Standards] Proper SRV Record Fallback

On 9 January 2018 at 10:09, Evgeny Khramtsov wrote: > Tue, 9 Jan 2018 10:03:24 + > Dave Cridland wrote: > >> What's the distinction between invalid TLS certificates and >> authentication failure? > > Another question is what if I get an error response

Re: [Standards] Proper SRV Record Fallback

Tue, 09 Jan 2018 11:30:25 +0100 Marcel Waldvogel wrote: > So, a connection runs into a timeout: Why not try the fallback? Runs into a timeout in what state? TCP? TLS? SASL? Roster-get? MAM-request? ___ Standards

Re: [Standards] Proper SRV Record Fallback

You mention "overloaded hardware/software". So, a connection runs into a timeout: Why not try the fallback? BTW: Maybe a distinction between c2s and s2s might make sense, as fallbacks on s2s might cause more problems than on c2s. -Marcel On Tue, 2018-01-09 at 09:59 +0300, Evgeny Khramtsov

Re: [Standards] Proper SRV Record Fallback

Tue, 9 Jan 2018 10:03:24 + Dave Cridland wrote: > What's the distinction between invalid TLS certificates and > authentication failure? Another question is what if I get an error response on, let's say, roster get? I bet there are situations where I benefit from

Re: [Standards] Proper SRV Record Fallback

On 9 January 2018 at 04:19, Travis Burtrum wrote: > In my opinion, at least all of cannot-connect-to-port, non-XML, > not-proper-stream and invalid TLS cert should trigger a fallback to the > next highest priority SRV record. Everyone in the MUC seemed to agree > if

Re: [Standards] XEP-0313: Treatment of type=groupchat in user archive with or without hint

bumping this thread. In regards to forward compatibility with MIX which has good reason to store its messages in the users archive how about changing this rule to not store type=groupchat addressed to a full jid? Is this something we can get you to agree to Kev? Keeping in mind our xsf group