-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 As part of revising RFC 3920 I pretty much removed the concept of "subdomain" because it always caused confusion. See here for the scrubbed text:
http://tools.ietf.org/html/draft-ietf-xmpp-3920bis However, some remnants of the concept remain, such as the JID matching rules in the Privacy Lists protocol (XEP-0016): *** If the type is "jid", then the 'value' attribute MUST contain a valid Jabber ID. JIDs SHOULD be matched in the following order: 1. <u...@domain/resource> (only that resource matches) 2. <u...@domain> (any resource matches) 3. <domain/resource> (only that resource matches) 4. <domain> (the domain itself matches, as does any u...@domain, domain/resource, or address containing a subdomain) *** Unfortunately, the notion of a subdomain was never really defined -- it basically meant that you added another domain part to the left-hand side of a server JID, such as foo.example.com if the XMPP server is hosted at example.com or bar.im.example.net if the XMPP server is hosted at im.example.net. Yet we don't really know if what looks like a subdomain really is associated with a given XMPP server. So for instance there might be one XMPP server running at example.net and an entirely different XMPP server running at im.example.net. A long-running example is provided by jabber.com because there is also a server corp.jabber.com for employees (well, they now work for Cisco but you see what I mean!), and corp.jabber.com might look like a "subdomain" of jabber.com but in practice it is not. This is why we removed the notion of a subdomain from rfc3920bis. Similarly, I suggest that we remove it from the JID matching rules in XEP-0016, XEP-0045, etc. Objections? 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/ iEYEARECAAYFAkqoGeEACgkQNL8k5A2w/vz9tgCgjGCdc6BSmJUEhoYN0zsUZrx/ X+MAoKD5R7Qcwj9YCMO7TgNXd8JMKsGy =ylwc -----END PGP SIGNATURE-----
