On Wed, 3 Feb 2021 at 15:50, Florian Schmaus <f...@geekplace.eu> wrote:
> On 2/3/21 3:52 PM, Sonny Piers wrote: > > On Wed, Feb 3, 2021, at 14:20, Florian Schmaus wrote: > >> On 2/3/21 1:47 PM, Sonny Piers wrote> > >> > The equivalent for TCP (srv records) is in core so why not its > >> > equivalent for web ? > >> > >> I don't see xmpp-*. SRV RRs in 'Core'. Only xmpps-*. SRV RRs are in > >> 'Advanced', and that is probably because they are an extra XEP. > >> > >> And since it appears you could be RFC-6120 compliant without > >> implementing SRV RRs lookup, I would similarly argue as above: The > >> compliance suite should explicitly state that for RFC-6120 style > >> connections, proper SRV RRs handling is REQUIRED. This would mean that > >> "lazy" clients, as Daniel describes then, could not declare conformity > >> with the compliance suites. > > > > xmpp-* srvs are in RFC 6120 > > https://xmpp.org/rfcs/rfc6120.html#tcp-resolution-prefer > > <https://xmpp.org/rfcs/rfc6120.html#tcp-resolution-prefer> > > Right, they are *described* in RFC 6120. But it does not appear that > they are mandatory to implement, at least I am unable to find some > normative wording on this. Something like "clients SHOULD perform ยง > 3.2.1 when connecting". Hence an implementation could claim RFC 6120 > compliance without implementing SRV RRs lookups. > > The situation is similar with RFC 7395: There appears to be no normative > wording that makes XEP-0156 mandatory. It is just described there. > > Hence, I wonder if the compliance suites should not explicitly require > support for SRV RRs, or XEP-0156 in case of WebSocket. Well, it says the preferred mechanism is SRV lookup, describes A/AAA direct lookup as a fallback, and gives information on when not to use SRV. But then, it also never says implementations SHOULD support TCP; indeed RFC 6120 really goes out of its way to remind the reader that BOSH is available. Do we need to explicitly state that TCP support is a core feature? "Normative language" in the sense of littering prose with RFC 2119 keywords was never intended to be the sole method of indicating that something is normative; it's designed to be a shorthand to remove some of the ambiguity we necessarily face when describing desired behaviour - it's also, mind, intended to be used only for matters of interoperability rather than general preference. I have always assumed - and I think it's reasonable to have always assumed, and further, I have assumed that everyone assumed, and think that is reasonable too - that SRV-based resolution is what a connecting client does unless it's overridden or - in extremis - simply unable to do so on its platform. Also, that desktop clients will typically support TCP. Moreover, this all makes sense - if SRV isn't a MUST-unless-overridden-or-impossible (you're welcome to argue SHOULD vs MUST here and I do not care), then you can't, for example, connect to my server. And that's OK. This all feels like arguing over the semantics of the language choices, and it seems pretty obvious to me that if you don't support SRV, there will be plenty of servers you cannot connect to without manual configuration. Dave.
_______________________________________________ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org _______________________________________________
