On 30.03.19 16:48, Jonas Schäfer (XSF Editor) wrote: > Version 0.1.0 of XEP-0418 (DNS Queries over XMPP (DoX)) has been > released. > > Abstract: > This specification defines an XMPP protocol extension for sending DNS > queries and getting DNS responses over XML streams. Each DNS query- > response pair is mapped into an IQ exchange. > > Changelog: > Accepted by vote of Council on 2019-03-13. (XEP Editor (jsc)) > > URL: https://xmpp.org/extensions/xep-0418.html
Love it. Although I don't have an immediate use case, I could imagine that one will come up possibly. § 4 "If the resolver does not support the dns namespace, it MUST return a <service-unavailable/> error:" I suggest to clarify that this is as per RFC 6120 § 8.5 § 5 Do only entities acting as DoX resolver announce the feature, or all? I suggest the former and to state that explicit in the XEP. "In order for an application to determine whether an entity supports this protocol, where possible it SHOULD use the dynamic, presence-based profile of service discovery defined in Entity Capabilities (XEP-0115) [7]. However, if an application has not received entity capabilities information from an entity, it SHOULD use explicit service discovery instead." I am not a friend of the XEP-0115 hint in such situations. It just adds additional redundancy and noise. XEP-0030 already has a forward hint to XEP-0115. There is no need to mention it again. I suggest to remove that paragraph. "Support could also be pre-arranged between parties by putting a resolver at a known JID, in which case the requestor can just start sending queries to the resolver" Appears pretty obvious to me and nothing a XEP needs to specify explicitly. I suggest to remove this sentence too. Nit: Missing dot at the end of the sentence. § 6 Whut? How does this result in a disconnection? I also think it does not belong into this particular XEP, as it is nothing DoX specific. § 7 "…therefore all queries and responses MUST use TLS or equivalent connection security" Please remove the 'MUST'. There are valid uses cases to use DoX without transport security. I would suggest to recommend the usage though. At least use 'SHOULD' as compromise if you must. "This mitigates classic amplification attacks for UDP- based DNS." I don't think this is true (in the case of DoX). A reference to the DNSSEC RFC(s) would be appropriate. s/dns/DNS/ (everywhere) The last paragraph in § 7 is also not really DoX specific and I don't see what the takeaway for DoX-interested readers would be. I suggest to remove it. - Florian
signature.asc
Description: OpenPGP digital signature
_______________________________________________ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: [email protected] _______________________________________________
