[Standards] RFC 3920, 10.2/10.3: subdomain routing rules

[Bruce Campbell]

On Tue, 27 Mar 2007, Tony Finch wrote:

> On Mon, 26 Mar 2007, Peter Saint-Andre wrote:
>> Please refer to rfc3920bis, which contains all the errata and corrections and
>> clarifications we have discussed so far:
>> http://www.xmpp.org/internet-drafts/draft-saintandre-rfc3920bis-01.html

It doesn't actually.  The 2005 thread that Tony referenced provides an 
explanation as to why the word 'subdomain' is confusing, and a loose 
promise of clarification from yourself.

> Why treat subdomains specially? Are special services required to be
> subdomains of the server's main domain? Can't a server be MUC-only (say)
> or have two domains users.example.com and muc.example.com?

Part of the problem is that 3920(bis) is using 'domain' in the DNS sense, 
and unless you carefully read the full document, the usage of 'subdomain' 
would appear to be also in the DNS sense.  That is, 'muc.example.com' is a 
subdomain of the domain 'example.com', and by the strict reading of 
3920(bis), it is assumed to be on the same server as 'example.com'.  If it 
is suddenly very popular, that is probably not true.

Rather than go through this explanation each time that the usage of 
'subdomain' in 3920bis is not in the DNS sense, please change 3920bis to 
avoid the confusion:

  3.2 Domain Identifier

 	The DOMAIN IDENTIFIER is the primary identifier and is the only
 	REQUIRED element of a JID (a mere domain identifier is a valid
 	JID). It usually represents the network or "home" server to which
 	other entities connect for XML routing and data management
 	capabilities. Note that a single server may host multiple domain
 	identifiers (local domains), and that domain identifiers do not
 	have to reference entities that provide traditional server
 	functionality (eg, a multi-user chat service or a user directory).

  9.1.2 From

 	Furthermore, the domain identifier portion of the JID contained in
 	the 'from' attribute MUST match the hostname of the sending server
 	(or any validated domain thereof, such as a validated domain
 	hosted by the sending server) as communicated in the SASL
 	negotiation, dialback negotiation or other means; if a server
 	receives a stanza that does not meet this restriction, it MUST
 	generate an <invalid-from/> stream error condition.

  11.2 Foreign Domain

 	If the hostname of the domain identifier portion of the JID
 	contained in the 'to' attribute does not match one of the
 	configured hostnames of the server itself or a configured
 	local domain thereof, the server SHOULD route the stanza to the
 	foreign domain (subject to local service provisioning and security
 	policies regarding inter-domain communication, since such
 	communication is OPTIONAL).

   11.3 Local domain

 	If the hostname of the domain identifier portion of the JID
 	contained in the 'to' attribute matches one of the configured
 	hostnames of the server, or one of the configured local domains
 	hosted by the server, the server MUST either process the stanza
 	itself or route the stanza to a specialized service that is
 	responsible for that local domain or return an error to the sender
 	(if the service providing the local domain is not available).

C.4 can be left as-is, as the usage of 'subdomain' there is consistent 
with DNS practice and provides a good starting tip to server developers 
for identifying already-open streams that can be re-used (I want to talk 
to 'chat.example.com', do I have a connection to 'example.com'?).

-- 
   Bruce Campbell.

   Lets see how long it takes this email address to be spammed.