Am 01.07.19 um 10:08 schrieb Dave Cridland:
[...]
Do you know which server implementations currently support both TLS and
non-TLS (with STARTLS) on the same port?
I have a vague recollection that Fippo mentioned this trick years ago -
perhaps Psyc, perhaps even the original Jabberd?
psyced
On Sun, 30 Jun 2019 at 17:31, Ralph Meijer wrote:
> On June 30, 2019 5:20:09 PM GMT+02:00, Sam Whited
> wrote:
> >On Sun, Jun 30, 2019, at 15:16, Ralph Meijer wrote:
> >> Hmm. On which port? I want to point out explicitly that although 5223
> >> has been used a bunch since before the IETF
On Sun, Jun 30, 2019, at 20:33, Kim Alvefur wrote:
> You can detect it, it's advertised in DNS.
The point of this is a fallback in case it's not advertised in DNS.
> Since a common use case of Direct TLS is to put it on port 443, why
> don't you also probe that port?
That might be a good idea
On Sun, Jun 30, 2019 at 06:23:36PM +, Sam Whited wrote:
> On Sun, Jun 30, 2019, at 18:15, Kim Alvefur wrote:
> > Please don't. While detecting use of TLS or plain is fairly simple it
> > is more complicated to handle both on the same port. I don't know any
> > socket handling framework that
On June 30, 2019 12:32:07 PM EDT, Ralph Meijer wrote:
>Do you know which server implementations currently support both TLS and
>non-TLS (with STARTLS) on the same port?
If you put sslh in front of them, all servers do. Try burtrum.org:443 for
instance.
On Sun, Jun 30, 2019, at 18:15, Kim Alvefur wrote:
> Please don't. While detecting use of TLS or plain is fairly simple it
> is more complicated to handle both on the same port. I don't know any
> socket handling framework that makes this easy. Usually the TLS
> library takes over the socket and
On Sun, Jun 30, 2019 at 04:55:47PM +, Sam Whited wrote:
> On Sun, Jun 30, 2019, at 16:32, Ralph Meijer wrote:
> > Do you know which server implementations currently support both TLS
> > and non-TLS (with STARTLS) on the same port?
>
> I'm sure if any of them do, but the fallback would still
On Sun, Jun 30, 2019, at 16:32, Ralph Meijer wrote:
> Do you know which server implementations currently support both TLS
> and non-TLS (with STARTLS) on the same port?
I'm sure if any of them do, but the fallback would still be useful in
case the service is only configured to support direct TLS
On June 30, 2019 5:20:09 PM GMT+02:00, Sam Whited wrote:
>On Sun, Jun 30, 2019, at 15:16, Ralph Meijer wrote:
>> Hmm. On which port? I want to point out explicitly that although 5223
>> has been used a bunch since before the IETF standardization, IANA has
>> assigned it to some HP management
On Sun, Jun 30, 2019, at 15:16, Ralph Meijer wrote:
> Hmm. On which port? I want to point out explicitly that although 5223
> has been used a bunch since before the IETF standardization, IANA has
> assigned it to some HP management service. Hence my other proposal,
> which is still currently
On June 30, 2019 5:07:08 PM GMT+02:00, Sam Whited wrote:
>On Sun, Jun 30, 2019, at 14:58, Ralph Meijer wrote:
>> Just to be clear, in the same way as for xmpp-client, as per RFC
>2782?
>
>I think so; I meant by fetching the A/ record of the domain part of
>the JID, and then attempting to
On Sun, Jun 30, 2019, at 14:58, Ralph Meijer wrote:
> Just to be clear, in the same way as for xmpp-client, as per RFC 2782?
I think so; I meant by fetching the A/ record of the domain part of
the JID, and then attempting to perform direct TLS if a connection is
established. Then again, if an
On June 30, 2019 4:45:40 PM GMT+02:00, Sam Whited wrote:
>On Sun, Jun 30, 2019, at 09:54, Dave Cridland wrote:
>> 1) It's not A/ fallback "as per RFC 6120", because we're talking
>>about a Direct TLS fallback. It should be per section... erm...
>> 2) This document doesn't mention a A/
On Sun, Jun 30, 2019, at 09:54, Dave Cridland wrote:
> 1) It's not A/ fallback "as per RFC 6120", because we're talking
>about a Direct TLS fallback. It should be per section... erm...
> 2) This document doesn't mention a A/ fallback at all, and perhaps
>that's right - do we ever
On June 30, 2019 11:53:39 AM GMT+02:00, Dave Cridland wrote:
> [..]
>OK, two comments, which are essentially both my fault:
>
>1) It's not A/ fallback "as per RFC 6120", because we're talking
>about
>a Direct TLS fallback. It should be per section... erm...
>2) This document doesn't mention a
On Sun, 30 Jun 2019 at 09:40, Jonas Schäfer wrote:
> On Samstag, 29. Juni 2019 23:32:41 CEST Dave Cridland wrote:
> > On Sat, 29 Jun 2019 at 16:56, Ralph Meijer wrote:
> > > On June 29, 2019 4:32:15 PM GMT+02:00, "Jonas Schäfer" <
> > >
> > > jo...@wielicki.name> wrote:
> > > >Hi list,
> > > >
On Samstag, 29. Juni 2019 23:32:41 CEST Dave Cridland wrote:
> On Sat, 29 Jun 2019 at 16:56, Ralph Meijer wrote:
> > On June 29, 2019 4:32:15 PM GMT+02:00, "Jonas Schäfer" <
> >
> > jo...@wielicki.name> wrote:
> > >Hi list,
> > >
> > >It is not clear to me how to interpret, in a library
On Sat, 29 Jun 2019 at 16:56, Ralph Meijer wrote:
> On June 29, 2019 4:32:15 PM GMT+02:00, "Jonas Schäfer" <
> jo...@wielicki.name> wrote:
> >Hi list,
> >
> >It is not clear to me how to interpret, in a library connecting to an
> >XMPP
> >service, a single SRV record for _xmpps-{client,server}
On June 29, 2019 4:32:15 PM GMT+02:00, "Jonas Schäfer"
wrote:
>Hi list,
>
>It is not clear to me how to interpret, in a library connecting to an
>XMPP
>service, a single SRV record for _xmpps-{client,server} which has `.`
>as the
>target.
>
>For RFC 6120 _xmpp-{client,server} records (note the
Hi list,
It is not clear to me how to interpret, in a library connecting to an XMPP
service, a single SRV record for _xmpps-{client,server} which has `.` as the
target.
For RFC 6120 _xmpp-{client,server} records (note the missing `s`), a `.`
indicates that the domain does not host an XMPP
20 matches
Mail list logo
