-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Changes checked in:
http://svn.xmpp.org:18080/changelog/XMPP/?cs=3447 On 9/15/09 5:30 PM, Peter Saint-Andre wrote: > 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. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.8 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkqwXRwACgkQNL8k5A2w/vy1SACdEplEvN1qt/tYcgb6ozQHX1KV IgAAoMWBxUx/R2cjVHUFpdnm4F6t4Csb =3TBY -----END PGP SIGNATURE-----
