subdomain cleanup

git-svn-id: file:///home/ksmith/gitmigration/svn/xmpp/trunk@3447 4b5297f7-1745-476d-ba37-a9c6900126ab

xep-0016.xml

@@ -135,7 +135,7 @@
       <li>&lt;user@domain/resource&gt; (only that resource matches)</li>
       <li>&lt;user@domain&gt; (any resource matches)</li>
       <li>&lt;domain/resource&gt; (only that resource matches)</li>
-      <li>&lt;domain&gt; (the domain itself matches, as does any user@domain, domain/resource, or address containing a subdomain)</li>
+      <li>&lt;domain&gt; (the domain itself matches, as does any user@domain or domain/resource)</li>
     </ol>
     <p>If the type is "group", then the 'value' attribute SHOULD contain the name of a group in the user's roster.  (If a client attempts to update, create, or delete a list item with a group that is not in the user's roster, the server SHOULD return to the client an &lt;item-not-found/&gt; stanza error.)</p>
     <p>If the type is "subscription", then the 'value' attribute MUST be one of "both", "to", "from", or "none" as defined <cite>RFC 3921</cite>, where "none" includes entities that are totally unknown to the user and therefore not in the user's roster at all.</p>

xep-0045.xml

@@ -2820,7 +2820,7 @@
       <li>&lt;user@domain/resource&gt; (only that resource matches)</li>
       <li>&lt;user@domain&gt; (any resource matches)</li>
       <li>&lt;domain/resource&gt; (only that resource matches)</li>
-      <li>&lt;domain&gt; (the domain itself matches, as does any user@domain, domain/resource, or address containing a subdomain)</li>
+      <li>&lt;domain&gt; (the domain itself matches, as does any user@domain or domain/resource)</li>
     </ol>
     <p>Some administrators may wish to ban all users associated with a specific domain from all rooms hosted by a MUC service. Such functionality is a service-level feature and is therefore out of scope for this document, instead being defined in <cite>XEP-0133</cite>.</p>
   </section2>

xep-0100.xml

@@ -867,7 +867,7 @@
 </section1>
 <section1 topic='Addressing' anchor='addressing'>
   <section2 topic='Gateways' anchor='addressing-gateway'>
-    <p>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).</p>
+    <p>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).</p>
   </section2>
   <section2 topic='Users' anchor='addressing-user'>
     <p>The Jabber Identifier corresponding to a Legacy User's address is typically of the form &lt;LegacyUserAddress@gateway.example.com&gt;, where LegacyUserAddress is the Legacy User's address on the Legacy Service and where gateway.example.com is the Jabber address of the gateway.</p>

xep-0178.xml

@@ -232,7 +232,7 @@
   </ol>
 </section1>
 <section1 topic='Server-to-Server Recommendation' anchor='s2s'>
-  <p>As specified in <cite>RFC 3920</cite> and provisionally clarified in <cite>rfc3920bis</cite>, 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.</p>
+  <p>As specified in <cite>RFC 3920</cite> and provisionally clarified in <cite>rfc3920bis</cite>, 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.</p>
   <p>The RECOMMENDED protocol flow for server-to-server use of SASL EXTERNAL with server (domain) certificates is as follows:</p>
   <ol>
     <li>
@@ -315,7 +315,7 @@
       ]]></code>
     </li>
     <li>
-      <p>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.</p>
+      <p>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), then Server2 SHOULD advertize the SASL EXTERNAL mechanism.</p>
       <code><![CDATA[
 <stream:features>
   <mechanisms xmlns='urn:ietf:params:xml:ns:xmpp-sasl'>

xep-0191.xml

@@ -107,7 +107,7 @@
     <li>&lt;user@domain/resource&gt; (only that resource matches)</li>
     <li>&lt;user@domain&gt; (any resource matches)</li>
     <li>&lt;domain/resource&gt; (only that resource matches)</li>
-    <li>&lt;domain&gt; (the domain itself matches, as does any user@domain, domain/resource, or address containing a subdomain)</li>
+    <li>&lt;domain&gt; (the domain itself matches, as does any user@domain or domain/resource)</li>
   </ol>
 </section1>
 <section1 topic='Use Cases' anchor='usecases'>

xep-0220.xml

@@ -435,7 +435,7 @@ send: <db:verify
   </section2>
 
   <section2 topic="Multiplexing" anchor='multiplex'>
-    <p>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 &xep0205;. Multiplexing reduces the number of connections to two.</p>
+    <p>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 &xep0205;. Multiplexing reduces the number of connections to two.</p>
     <p>Note: Because dialback operates on domain pairs, a total of eight dialback negotiations is necessary for a bidirectional exchange of stanzas between two sending domains and two target domains.</p>
     <section3 topic="Multiplexing Sender Domains" anchor="senderpiggyback">
       <p>In order to accept XML stanzas from rooms at "chat.sender.tld" intended for addresses at "target.tld", the "target.tld" domain will need to validate the "chat.sender.tld" domain (just as it already did for the "sender.tld" domain). Thus the Originating Server would now initiate a dialback negotiation with "target.tld" but specify the Sender Domain as "chat.sender.tld". Specifying different Sender Domains is called "SENDER PIGGYBACKING" and MAY be used without further negotation.</p>

xep-0271.xml

@@ -48,7 +48,7 @@
   </section1>
   <section1 topic='Definition' anchor='def'>
     <p>To clarify the nature of a node, it is first helpful to describe the architecture of XMPP systems.</p>
-    <p>Because XMPP is a client-server technology that relies on the Domain Name System, the fundamental building block of XMPP systems is the <strong>"domain"</strong>. The idea of an Internet domain is borrowed from the real world, where a domain is an area of physical territory over which an individual or organization has control (e.g., the United States of America). Similarly, 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 (e.g., a particular state within the USA, such as Colorado). In any case, a domain identifier is the primary portion of a JabberID (e.g., "jabber.org" in the JID "stpeter@jabber.org"), and can stand alone as a complete JabberID.</p>
+    <p>Because XMPP is a client-server technology that relies on the Domain Name System, the fundamental building block of XMPP systems is the <strong>"domain"</strong>. The idea of an Internet domain is borrowed from the real world, where a domain is an area of physical territory over which an individual or organization has control (e.g., the United States of America). Similarly, 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 (e.g., a particular state within the USA, such as Colorado). In any case, a domain identifier is the primary portion of a JabberID (e.g., "jabber.org" in the JID "stpeter@jabber.org"), and can stand alone as a complete JabberID.</p>
     <p>A given physical domain contains particular points or places. Similarly, a given virtual domain can contain particular points or entities. These entities are often thought of as accounts (e.g., the URI mailto:stpeter@jabber.org represents an email account and the URI xmpp:stpeter@jabber.org represents an XMPP account), but other entity types are possible (e.g., jdev@conference.jabber.org happens to be a &xep0045; room. Confusingly, the part of a JabberID that identifies an account or entity within the scope of an XMPP domain is called a node (e.g., the string "stpeter" in the JabberID stpeter@jabber.org is called a "node identifier"). Unfortunately, this usage collides with the term "node" as used in Service Discovery and Publish-Subscribe. Therefore we suggest the term <strong>"localpart"</strong> for a particular point or entity in an XMPP domain. A localpart identifier is an optional secondary portion of a JabberID (e.g., "stpeter" in the JID "stpeter@jabber.org").</p>
     <p>A given domain or localpart can have various assets associated with it; in XMPP these assets are called <strong>"resources"</strong>. In the case of an account registered with an XMPP service, such resources are typically devices or connections. In the case of a multi-user chat room, such resources are usually room occupants. And so on. A resource identifier is an optional tertiary portion of a JabberID (e.g., "roundabout" in the JID "stpeter@jabber.org/roundabout" or "psa" in the JID "jdev@conference.jabber.org/psa").</p>
     <p>The Service Discovery and Publish-Subscribe extensions to XMPP use an optional quaternary identifer called a <strong>"node"</strong>, which identifies a particular facet or aspect of an XMPP domain, localpart, or resource. The exact nature of a node depends on the protocol in use:</p>