-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 9/10/09 8:30 AM, Dave Cridland wrote:
> you've made my point - the term "subdomain" is > meaningless in most circumstances. The email address > "[email protected]" has no relation to "[email protected]" aside > from a (likely) common ancestor in their management. And even that's not > certain, given addresses like "[email protected]", which was > (back when it existed) certainly not under the direct control of Demon > Internet. Right. Here is the impact of airbrushing the concept of subdomain from the XSF's specifications... 1. JID matching rules In XEPs 16, 45, and 191 change this: <domain> (the domain itself matches, as does any u...@domain, domain/resource, or address containing a subdomain) to this: <domain> (the domain itself matches, as does any u...@domain or domain/resource) 2. Addressing XEP-0100 (Gateway Interaction) has the following text: "The address of a gateway itself SHOULD be a hostname only, and that hostname SHOULD NOT be supplemented with a resource identifier when referring to the gateway's address (e.g., when storing the gateway in a roster). The hostname SHOULD be a subdomain of a primary Jabber host (e.g., icq.jabber.org might be the ICQ gateway run by the jabber.org server)." I think that is simply out of date, so I would recommend that we strike the second sentence. XEP-0271 (XMPP Nodes) contains the following analogy between Internet domains and the real world: *** ... an Internet domain (e.g., jabber.org or xmpp.org) is a virtual space or area that is controlled by an individual or organization (e.g., Jeremie Miller or the XMPP Standards Foundation). Given the workings of the Domain Name System, it is also possible to have subdomains such as planet.jabber.org or interop.xmpp.org, which can be seen as the virtual equivalent of administrative subdivisions in the real world... *** I think that's mostly harmless, but I might put the word "subdomains" in scare quotes. 3. Server identity in certificates and DNS records The only mention of subdomains in draft-ietf-xmpp-3920bis is the following informational note: Note: Many XMPP servers are implemented in such a way that they can host additional services (beyond those defined in this specification and [xmpp-im]) at hostnames that are subdomains of the hostname of the main XMPP service (e.g., conference.example.net for a [XEP-0045] service associated with the example.net XMPP service) or subdomains of the first-level domain of the underlying host (e.g., muc.example.com for a [XEP-0045] service associated with the im.example.com XMPP service). If an entity from a remote domain wishes to use such additional services, it would generate an appropriate XML stanza and the remote domain itself would attempt to resolve the service's hostname via an SRV lookup on resource records such as "_xmpp-server._tcp.conference.example.net." or "_xmpp- server._tcp.muc.example.com.". Therefore if a service wishes to enable entities from remote domains to access these additional services, it needs to advertise the appropriate "_xmpp-server" SRV records in addition to the "_xmpp-server" record for its main XMPP service. This is reflected in XEP-0178 (Best Practices for Use of SASL EXTERNAL with Certificates): *** As specified in RFC 3920 and provisionally clarified in rfc3920bis, if a JabberID is included in an X.509 certificate, it MUST be encapsulated as an id-on-xmppAddr Object Identifier. Although it is not necessary for an X.509 certificate to include a JabberID, it is RECOMMENDED that server certificates include the id-on-xmppAddr OID encapsulating the JabberID of the bare XMPP server domain only (e.g., "example.org"). In addition, it is RECOMMENDED in the case of server certificates for the server's hostname to be encapsulated as a subjectAltName extension of type dNSName. Furthermore it is quite common for XMPP servers to also offer associated services as subdomains of the server; if a server offers such services then it is RECOMMENDED to either include an id-on-xmppAddr OID for each subdomain or to include a dnsName containing the wildcard character '*' applying to the left-most domain name component or component fragment (this is considered to match any single component or component fragment, e.g., *.example.org matches foo.example.org but not bar.foo.example.org, and im*.example.net matches im1.example.net and im2.example.net but not chat.example.net). This specification includes recommendations that address all three cases. *** That recommendation seems appropriate. XEP-0178 also has this: *** Server2 advertises SASL mechanisms. If Server2 expects that Server1 will be able to authenticate and authorize as the identity provided in the certificate that Server1 already provided (e.g., because the two servers share a common root certification authority, Server1's certificate has not been revoked, and the address provided in the 'from' address of Server1's initial stream header matches the authentication identity or a subdomain thereof), then Server2 SHOULD advertize the SASL EXTERNAL mechanism. *** That seems wrong to me, so I would recommend striking the phrase "or a subdomain thereof". In XEP-0220 (Server Dialback) we talk about piggypacking / multiplexing and mention subdomains: *** A single XML stream between Originating and Receiving Server can be used to multiplex stanzas for more than one domain pair. This usage is for historical reasons also known as "PIGGYBACKING". One common motivation for this is virtual hosting, for which many domains are hosted on the same server. Another common motivation for such reuse is the existence of additional services associated with the Sender Domain but hosted at subdomains thereof. For example, both the "target.tld" and the "sender.tld" XMPP servers might host a groupchat service at "chat.target.tld" and "chat.sender.tld" respectively. Without multiplexing, many server-to-server connections would be necessary to exchange stanzas between those domains. With more domains, the number of connections might exceed the maximum number of connections allowed from a single IP address as explained in Best Practices to Discourage Denial of Service Attacks [10]. Multiplexing reduces the number of connections to two. *** Given how dialback works (based on DNS using a callback to the base XMPP domain), that text is probably fine, but I need to think about it some more. Peter - -- Peter Saint-Andre https://stpeter.im/ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.8 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkqpI2UACgkQNL8k5A2w/vxxgwCgzOK1dtv7cL3XhddAgu+Ptr1T M6AAoPwE+4KiPYbmSvJmTEqNfoAQxUJf =MVih -----END PGP SIGNATURE-----
