-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 9/10/09 10:03 AM, Peter Saint-Andre wrote: > 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)
Done in my working copy. > 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. Done in my working copy. > 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. Done in my working copy. > 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". Done in my working copy. > 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. I've put the word 'subdomains' in scare quotes there and elsewhere. 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/ iEYEARECAAYFAkqwI5sACgkQNL8k5A2w/vyHUQCg1lArwJJybjtqxj4R9B1CqOr9 EfoAoNYvH7YwTW72joXZAGjVHv6UYQ9W =6TRw -----END PGP SIGNATURE-----
