This essentially re-introduces the major security flaw that was addressed
in XEP-0156 by removing the TXT record, just with a warning.
Isn't this security flaw inherent to all possible discovery mechanisms for
browser-based connection with domain delegation? Unless you can somehow
trust the
Hi Dave!
I've only briefly reviewed this so far, so please forgive if I've missed
things, but I have some early comments:
Major blocker I'm not sure can be addressed:
1.
This essentially re-introduces the major security flaw that was
addressed in XEP-0156 by removing the TXT record, just
Hi Dave!
On 12/27/23 04:12, Dave Cridland wrote:
I dislike this XEP intensely.
But... I think it's probably the most pragmatic solution that fits the
existing standards space.
Honestly... Nice summary of my opinion too. :) We need things, sadly we
don't live in an ideal world, and this
Hi Fannys!
On 12/16/23 04:06, Fannys wrote:
As I said in the @xsf room the problem with this XEP is that the author
is convinced that this is the one answer to everything and assumes a
*lot* of stuff to get there. And besides the title obviously that is
obvious in a few other places.
To try
Apologies for the delay on this, but I finally have an update:
On 12/15/23 23:00, Travis Burtrum wrote:
Lastly I was asked to contact to XEP-0156 authors to see how they'd feel
about this updating '156 instead of being it's own XEP
I emailed stpeter directly and he responded promptly, thanks
Hi all,
Attached is an *unsubmitted* Internet Draft covering SVCB usage for XMPP.
Assuming attachments work on this list!
Feedback welcome, I intend to submit this one shortly to the IETF.
Dave.
draft-cridland-dnsop-svcb-xmpp.pdf
Description: Adobe PDF document
