XSF stuff

git-svn-id: svn://svn.xmpp.org:7938/xmpp/trunk@345 4b5297f7-1745-476d-ba37-a9c6900126ab
g2p · Jan 15, 2007 · aef5d07 · aef5d07
1 parent 811d075
commit aef5d07
Show file tree

Hide file tree

Showing 7 changed files with 66 additions and 80 deletions.
diff --git a/about/contributors.shtml b/about/contributors.shtml
@@ -7,6 +7,5 @@
 <ul>
   <li>Hosting is provided by <a href='http://www.n-connect.net/'>NetConnect</a></li>
   <li>Data backup is provided by <a href='http://aset.psu.edu/'>ASET</a></li>
-  <li>The xmpp.org domain was contributed by <a href="http://www.opendomain.org/">OpenDomain.org</a></li>
 </ul>
 <!--#include virtual="/includes/foot.txt" -->
diff --git a/about/copyright.shtml b/about/copyright.shtml
@@ -1,8 +1,8 @@
 <html>
 <head>
 <title>Copyright</title>
-<!--#include virtual="/includes/head.txt" -->
+<!--#include virtual='/includes/head.txt' -->
 <h2>Copyright</h2>
 <p>With the exception of certain files copyrighted by the Internet Society (e.g., the <a href='/rfcs/'>XMPP RFCs</a>), all information on this website is copyright &#169; 1999 - 2006 by the <a href='http://www.jabber.org/jsf/'>Jabber Software Foundation</a> (JSF) and is made available under the <a href='http://creativecommons.org/licenses/by/2.5/'>Creative Commons Attribution License</a>. For details, refer to the JSF's Intellectual Property Rights Policy at &lt;<a href='http://www.xmpp.org/extensions/ipr-policy.shtml'>http://www.xmpp.org/extensions/ipr-policy.shtml</a>&gt;.</p>
 <p style='text-align: center'><a href='http://creativecommons.org/licenses/by/2.5/'><img border='0' src='/images/cc.png'/></a></p>
-<!--#include virtual="/includes/foot.txt" -->
+<!--#include virtual='/includes/foot.txt' -->
diff --git a/about/history.shtml b/about/history.shtml
diff --git a/about/reqsum.shtml b/about/reqsum.shtml
@@ -22,10 +22,10 @@
 <h2>XMPP WG Requirements Summary</h2>
 <p><em>
 Author: Peter Saint-Andre<br />
-Version: 0.4<br />
-Last Updated: 2003-12-08
+Version: 0.5<br />
+Last Updated: 2007-01-14
 </em></p>
-<p>The charter of the XMPP WG specifies that "the final specifications will be consistent as much as practical with ... the requirements given in RFC2779". This document summarizes how the existing XMPP Internet-Drafts meet the requirements defined in RFC2779. Text from RFC2779 that specifies each requirement is followed by explanatory text that specifies how XMPP meets that requirement. Further detail, including references to specific sections of the XMPP Internet-Drafts, may be added to this document at a future date. Note well that this document inherits the terminology defined in the XMPP Internet-Drafts, and cannot be understood apart from those I-Ds.</p>
+<p>The charter of the XMPP WG specifies that "the final specifications will be consistent as much as practical with ... the requirements given in RFC2779". This document summarizes how the <a href='/rfcs/'>XMPP RFCs</a> (and their prospective successors, currently published as <a href='/internet-drafts/'>Internet-Drafts</a>) meet the requirements defined in <a href='http://www.ietf.org/rfc/rfc2779.txt'>RFC2779</a>. Text from RFC2779 that specifies each requirement is followed by explanatory text that specifies how XMPP meets that requirement. Further detail, including references to specific sections of the XMPP RFCs, may be added to this document at a future date. Note well that this document inherits the terminology defined in the XMPP RFCs, and cannot be understood apart from those specifications. This document refers to <a href='http://www.ietf.org/rfc/rfc3920.txt'>RFC 3920</a> as "XMPP Core" and <a href='http://www.ietf.org/rfc/rfc3921.txt'>RFC 3921</a> as "XMPP IM".</p>
 <h2>Table of Contents</h2>
 <pre>
    2. Shared Requirements
@@ -147,7 +147,7 @@ Last Updated: 2003-12-08
       -- (2.3.5) which other PRINCIPALS, if any, can send INSTANT
          MESSAGES to that INSTANT INBOX.
 </pre></blockquote>
-<p class='done'>DONE through use of privacy lists to block messages from other JIDs (see discussion under 5.4.10).</p>
+<p class='done'>DONE via privacy lists (specified in <a href='/extensions/xep-0016.html'>XEP-0016</a>) or block lists (specified in <a href='/extensions/xep-0191.html'>XEP-0191</a>).</p>
 <blockquote><pre>
       -- (2.3.6) which other PRINCIPALS, if any, can read INSTANT
          MESSAGES from that INSTANT INBOX.
@@ -230,7 +230,7 @@ Last Updated: 2003-12-08
    contact information for the PRESENTITY's PRINCIPAL (if applicable),
    such as email address, telephone number, postal address, or the like.
 </pre></blockquote>
-<p class='done'>DONE via vCard XML format (defined by Jabber Software Foundation but not part of core specs).</p>
+<p class='done'>DONE via vCard XML format (defined in <a href='/extensions/xep-0054.html'>XEP-0054</a> but not part of core specs).</p>
 <blockquote><pre>
    3.1.4. There MUST be a means of extending the common presence format
    to represent additional information not included in the common
@@ -243,7 +243,7 @@ Last Updated: 2003-12-08
    mechanisms for presence information schema, including new STATUS
    conditions and new forms for OTHER PRESENCE MARKUP.
 </pre></blockquote>
-<p class='done'>DONE: XMPP defines several status conditions ("unavailable" corresponding to RFC2778's closed, and "available" corresponding to RFC2778's open, with 4 defined sub-states of available using the &lt;show/&gt; child element); registration of official status conditions must be pursued only through changes to XMPP Core, although XMPP extensibility mechanisms make it possible to define unofficial status conditions as well. The meaning of "other presence markup" is undefined in RFC2778 except to note that it includes any additional presence information (above and beyond status conditions) that may be included in a notification; in XMPP this might include (1) user-defined values of the &lt;status/&gt; element that is part of the XMPP schema, (2) well-known presence information contained in extended namespaces defined by the Jabber Software Foundation, or (3) proprietary extensions that are custom to a particular application or implementation. The particular values or data included via (1) or (3) would not be registered or explictly defined, whereas those included via (2) would be (albeit outside the purview of the XMPP WG). However, extended presence information mechanisms such as those handled by the Jabber Software Foundation would need to be defined and approved through the XMPP WG in order to be considered part of XMPP.</p>
+<p class='done'>DONE: XMPP defines several status conditions ("unavailable" corresponding to RFC2778's closed, and "available" corresponding to RFC2778's open, with 4 defined sub-states of available using the &lt;show/&gt; child element); registration of official status conditions must be pursued only through changes to XMPP Core, although XMPP extensibility mechanisms make it possible to define unofficial status conditions as well. The meaning of "other presence markup" is undefined in RFC2778 except to note that it includes any additional presence information (above and beyond status conditions) that may be included in a notification; in XMPP this might include (1) user-defined values of the &lt;status/&gt; element that is part of the XMPP schema, (2) well-known presence information contained in extended namespaces defined in the <a href='/extensions/'>XEP Series</a> published by the XMPP Standards Foundation, or (3) proprietary extensions that are custom to a particular application or implementation. The particular values or data included via (1) or (3) would not be registered or explictly defined, whereas those included via (2) would be (albeit outside the purview of the XMPP WG). However, extended presence information mechanisms such as those in the <a href='/extensions/'>XEP Series</a> would need to be defined and approved through the XMPP WG in order to be considered part of XMPP.</p>
 <blockquote><pre>
    3.1.6. The presence format SHOULD be based on IETF standards such as
    vCard [RFC 2426] if possible.
@@ -329,7 +329,7 @@ Last Updated: 2003-12-08
    addresses or contact means for media other than INSTANT MESSAGES,
    such as telephone numbers or email addresses.
 </pre></blockquote>
-<p class='done'>DONE via vCard XML format (defined by Jabber Software Foundation but not part of core specs).</p>
+<p class='done'>DONE via vCard XML format (defined in <a href='/extensions/xep-0054.html'>XEP-0054</a> but not part of core specs).</p>
 <blockquote><pre>
    4.1.5. The common message format MUST permit the encoding and
    identification of the message payload to allow for non-ASCII or
@@ -351,7 +351,7 @@ Last Updated: 2003-12-08
    mechanisms for the message format, including new fields and new
    schemes for INSTANT INBOX ADDRESSES.
 </pre></blockquote>
-<p class='done'>DONE: XMPP defines several child elements of the message stanza (subject, body, thread); definition of official new child elements would need to be pursued through changes to XMPP Core. However, XMPP includes a ready mechanism for extension, since a message stanza may contain child elements in other namespaces. Many such extended namespaces are defined by the Jabber Software Foundation (e.g., multi-user chat extensions), and proprietary extensions that are custom to a particular application or implementation may also be included if desired. The particular values or data included via custom extensions would not be registered or explictly defined, whereas those included via the Jabber Software Foundation would be (albeit outside the purview of the XMPP WG). Extended message information mechanisms such as those handled by the Jabber Software Foundation would need to be defined and approved through the XMPP WG in order to be considered part of XMPP.</p>
+<p class='done'>DONE: XMPP defines several child elements of the message stanza (subject, body, thread); definition of official new child elements would need to be pursued through changes to XMPP Core. However, XMPP includes a ready mechanism for extension, since a message stanza may contain child elements in other namespaces. Many such extended namespaces are defined in the <a href='/extensions/'>XEP Series</a> (e.g., <a href='/extensions/xep-0045.html'>multi-user chat</a>), and proprietary extensions that are custom to a particular application or implementation may also be included if desired. The particular values or data included via custom extensions would not be registered or explictly defined, whereas those defined in the <a href='/extensions/'>XEP Series</a> would be (albeit outside the purview of the XMPP WG). Extended message information mechanisms such as those specified in the <a href='/extensions/'>XEP Series</a> would need to be defined and approved through the XMPP WG in order to be considered part of XMPP.</p>
 <blockquote><pre>
    4.1.9. The working group MUST determine whether the common message
    format includes fields for numbering or identifying messages. If
@@ -425,7 +425,7 @@ Last Updated: 2003-12-08
    choose to accept A's SUBSCRIPTION, but fail to deliver any
    information to it (so-called "polite blocking"). See 5.1.15.
 </pre></blockquote>
-<p class='done'>DONE: The MUST is addressed fully by sending &lt;presence type='unsubscribed'/&gt;. Polite blocking is handled via privacy lists.</p>
+<p class='done'>DONE: The MUST is addressed fully by sending &lt;presence type='unsubscribed'/&gt;. Polite blocking is handled via privacy lists (specified in <a href='/extensions/xep-0016.html'>XEP-0016</a>) or block lists (specified in <a href='/extensions/xep-0191.html'>XEP-0191</a>).</p>
 <blockquote><pre>
    5.1.6. The protocol MUST NOT let any third party C force A to
    subscribe to B's PRESENCE INFORMATION without A's consent.
@@ -481,7 +481,7 @@ Last Updated: 2003-12-08
    protocol MUST NOT mandate the PRESENCE SERVICE to service
    subscriptions that are treated in this manner.
 </pre></blockquote>
-<p class='done'>DONE via privacy lists.</p>
+<p class='done'>DONE via privacy lists (specified in <a href='/extensions/xep-0016.html'>XEP-0016</a>) or block lists (specified in <a href='/extensions/xep-0191.html'>XEP-0191</a>).</p>
 <blockquote><pre>
    5.1.16. B MUST be able to cancel A's subscription at will.
 </pre></blockquote>
@@ -548,7 +548,7 @@ Last Updated: 2003-12-08
    5.3.2. The protocol MUST ensure that A is only sent NOTIFICATIONS
    from entities she has subscribed to.
 </pre></blockquote>
-<p class='done'>DONE via privacy lists.</p>
+<p class='done'>DONE via privacy lists (specified in <a href='/extensions/xep-0016.html'>XEP-0016</a>) or block lists (specified in <a href='/extensions/xep-0191.html'>XEP-0191</a>).</p>
 <blockquote><pre>
    5.3.3. The protocol MUST provide A means of verifying that the
    notification was sent by B.
@@ -604,5 +604,5 @@ Last Updated: 2003-12-08
 <blockquote><pre>
    5.4.10. B MUST be able to prevent A from sending him messages
 </pre></blockquote>
-<p class='done'>DONE via privacy lists.</p>
+<p class='done'>DONE via privacy lists (specified in <a href='/extensions/xep-0016.html'>XEP-0016</a>) or block lists (specified in <a href='/extensions/xep-0191.html'>XEP-0191</a>).</p>
 <!--#include virtual="/includes/foot.txt" -->
diff --git a/about/sponsors.shtml b/about/sponsors.shtml
@@ -1,27 +1,10 @@
 <html>
 <head>
-<title>Sponsors</title>
-<!--#include virtual="/includes/head.txt" -->
-<h2>Sponsors</h2>
-<p>As an initiative of the <a href='http://www.jabber.org/jsf/'>Jabber Software Foundation</a>, xmpp.org is generously supported by a number of companies that are using or building Jabber/XMPP technologies.</p>
-
-<h2>Platinum Sponsors</h2>
-<blockquote>
-<p><a href="http://www.jabber.org/sponsors/google.shtml"><img border='0' src="/images/logo-google.gif" /></a></p>
-<p><a href="http://www.jabber.org/sponsors/hp.shtml"><img border='0' src="/images/logo-hp.gif" /></a></p>
-<p><a href="http://www.jabber.org/sponsors/jabberinc.shtml"><img border='0' src="/images/logo-jinc.png" /></a></p>
-</blockquote>
-<hr noshade />
-
-<h2>Silver Sponsors</h2>
-<blockquote>
-<p><a href="http://www.jabber.org/sponsors/agsoftware.shtml"><img border='0' src="/images/logo-agsoftware.png" /></a></p>
-<p><a href="http://www.jabber.org/sponsors/antepo.shtml"><img border='0' src="/images/logo-antepo.png" /></a></p>
-<p><a href="http://www.jabber.org/sponsors/coversant.shtml"><img border='0' src="/images/logo-coversant.jpg" /></a></p>
-<p><a href="http://www.jabber.org/sponsors/dreamhost.shtml"><img border='0' src="/images/logo-dreamhost.png" /></a></p>
-<p><a href="http://www.jabber.org/sponsors/jivesoftware.shtml"><img border='0' src="/images/logo-jivesoftware.png" /></a></p>
-<p><a href="http://www.jabber.org/sponsors/tipic.shtml"><img border='0' src="/images/logo-tipic.png" /></a></p>
-<p><a href="http://www.jabber.org/sponsors/zettai.shtml"><img border='0' src="/images/logo-zettai.png" /></a></p>
-</blockquote>
-
-<!--#include virtual="/includes/foot.txt" -->
+<title>xmpp.org</title>
+<meta http-equiv='Refresh' content='5; URL=http://www.xmpp.org/sponsors/'>
+<meta name='robots' content='noindex'>
+</head>
+<body>
+<p><em>The information you are looking for has been moved to <a href='http://www.xmpp.org/sponsors/'>http://www.xmpp.org/sponsors/</a>. You are being redirected there now.</em></p>
+</body>
+</html>
diff --git a/about/summary.shtml b/about/summary.shtml
@@ -3,13 +3,13 @@
 <title>Summary of XMPP</title>
 <!--#include virtual="/includes/head.txt" -->
 <h2>Summary of XMPP</h2>
-<p><em>Last Updated: 2006-10-04</em></p>
+<p><em>Last Updated: 2007-01-14</em></p>
 
-<p>The Extensible Messaging and Presence Protocol (XMPP) is the IETF's formalization of the base XML streaming protocols for instant messaging and presence developed within the <a href="http://www.jabber.org/">Jabber</a> community starting in 1999.</p>
+<p>The Extensible Messaging and Presence Protocol (XMPP) is the IETF's formalization of the base XML streaming protocols for instant messaging and presence developed within the <a href="http://www.jabber.org/">Jabber</a> open-source community in 1999.</p>
 <p>As specified in <a href="http://www.ietf.org/rfc/rfc3920.txt">RFC 3920</a>, the core "transport" layer for XMPP is an XML streaming protocol that makes it possible to exchange fragments of XML between any two network endpoints. Authentication and channel encryption happen at the XML streaming layer using the IETF-standard protocols for Simple Authentication and Security Layer (<a href="http://www.ietf.org/rfc/rfc2222.txt">RFC 2222</a>) and Transport Layer Security (<a href="http://www.ietf.org/rfc/rfc2246.txt">RFC 2246</a>). The normal architecture of XMPP is a pure client-server model, wherein clients connect to servers and (optionally) servers connect to each other for interdomain communications. XMPP addresses are fully internationalized, and are of the form &lt;node@domain&gt; for clients (similar to email).</p>
 <p>A wide variety of applications can be built on top of the core XML streaming layer. The first such application is instant messaging (IM) and presence. The basic IM and presence extensions specified in <a href="http://www.ietf.org/rfc/rfc3921.txt">RFC 3921</a> address the requirements of <a href="http://www.ietf.org/rfc/rfc2779.txt">RFC 2779</a>, as well as the contact list functionality expected IM and presence systems. RFC 3921 also makes it possible to separate the messaging and presence functionality if desired (although most deployments offer both).</p>
-<p>The <a href="history.shtml">history</a> of XMPP is that the protocols were initially developed within the Jabber open-source community. After several years of implementation and deployment experience, the base protocols were submitted to the Internet standards process by the Jabber Software Foundation in 2002. After appropriate formalization in the areas of security and internationalization, the base protocols were approved as IETF-appproved instant messaging and presence technologies in October 2004.</p>
-<p>In addition to the base protocols specified in <a href="http://www.ietf.org/rfc/rfc3920.txt">RFC 3920</a> and <a href="http://www.ietf.org/rfc/rfc3921.txt">RFC 3921</a>, there exist many XMPP extensions for functionality that was not required by <a href="http://www.ietf.org/rfc/rfc2779.txt">RFC 2779</a>. These extensions are generally specified in the <a href="/extensions/">XEP series</a> published by the Jabber Software Foundation.</p>
+<p>The <a href="history.shtml">history</a> of XMPP is that the protocols were initially developed within the Jabber open-source community. After several years of implementation and deployment experience, the base protocols were submitted to the Internet standards process by the Jabber Software Foundation (now XMPP Standards Foundation) in 2002. After appropriate formalization in the areas of security and internationalization, the base protocols were approved as IETF-appproved instant messaging and presence technologies in October 2004.</p>
+<p>In addition to the base protocols specified in <a href="http://www.ietf.org/rfc/rfc3920.txt">RFC 3920</a> and <a href="http://www.ietf.org/rfc/rfc3921.txt">RFC 3921</a>, there exist many XMPP extensions for functionality that was not required by <a href="http://www.ietf.org/rfc/rfc2779.txt">RFC 2779</a>. These extensions are generally specified in the <a href="/extensions/">XEP series</a> published by the XMPP Standards Foundation.</p>
 <p>The following list describes the main XMPP protocol specifications and XMPP extensions that are in wide use today:</p>
 <ul>
   <li><p><a href="http://www.ietf.org/rfc/rfc3920.txt">RFC 3920</a> -- Extensible Messaging and Presence Protocol (XMPP): Core -- the core protocols for XML streaming, including strong authentication, channel encryption, and internationalized addressing.</p></li>