XSF/SIG cleanup

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

xep-0002.xml

@@ -6,13 +6,13 @@
 <?xml-stylesheet type='text/xsl' href='xep.xsl'?>
 <xep>
 <header>
-  <title>Jabber Interest Groups (JIGs)</title>
-  <abstract>A definition of Jabber Interest Groups, including their structure and role within the Jabber Software Foundation.</abstract>
+  <title>Special Interest Groups (SIGs)</title>
+  <abstract>A definition of Special Interest Groups within the XMPP Standards Foundation.</abstract>
   &LEGALNOTICE;
   <number>0002</number>
   <status>Active</status>
   <type>Procedural</type>
-  <jig>None</jig>
+  <sig>None</sig>
   <approver>Board</approver>
   <dependencies/>
   <supersedes/>
@@ -32,11 +32,11 @@
   </revision>
 </header>
 <section1 topic='Short Definition'>
-  <p>A Jabber Interest Group (JIG) is a working group approved by the XMPP Council to address specific areas of growth or concern within the Jabber/XMPP developer community, usually by means of developing and publishing XMPP Extension Protocols (XEPs).</p>
+  <p>A Special Interest Group (SIG) is a working group approved by the XMPP Council to address specific areas of growth or concern within the Jabber/XMPP developer community, usually by means of developing and publishing XMPP Extension Protocols (XEPs).</p>
 </section1>
 <section1 topic='Explanation'>
-  <p>The main function of most JIGs is to produce acceptable XMPP extensions (delivered in the form of XMPP Extension Protocols or XEPs <note>For information about XMPP Extension Protocols, see <link url="http://www.xmpp.org/extensions/xep-0001.html">http://www.xmpp.org/extensions/xep-0001.html</link>.</note>) within a reasonably limited period of time. However, at the discretion of the XMPP Council, a handful of standing JIGs may be approved (e.g., to address security or standards compliance).</p>
-  <p>Anyone (not limited to members of the Jabber Software Foundation) may propose the formation of a JIG by completing a XMPP Extension Protocol outlining the need for the JIG and its proposed focus. However, JIG leaders must be members of the Jabber Software Foundation. The number of leaders for a JIG is flexible, and shall be determined by each JIG, in consultation with the XMPP Council if necessary. The concept of "membership" with regard to JIGs is loose, and is essentially co-extensive with membership in the appropriate mailing list (each JIG has its own mailing list, which is archived for public review). JIG members do not need to be members of the Jabber Software Foundation, and any member of the general public may subscribe to JIG mailing lists.</p>
-  <p>It is expected that all JIGs (other than certain standing JIGs) will remain active for as long as necessary in order to produce one or more standards-track specifications for review by the XMPP Council in the JIG's area of focus. However, if a JIG does not show signs of activity for an extended period of time (usually six months of inactivity on the JIG's mailing list), the JIG may be disbanded at the discretion of the XMPP Council with appropriate warning to the JIG members (usually in the form of an email sent to the JIG's mailing list).</p>
+  <p>The main function of most SIGs is to produce acceptable XMPP extensions (delivered in the form of XMPP Extension Protocols or XEPs <note>For information about XMPP Extension Protocols, see <link url="http://www.xmpp.org/extensions/xep-0001.html">http://www.xmpp.org/extensions/xep-0001.html</link>.</note>) within a reasonably limited period of time. However, at the discretion of the XMPP Council, a handful of standing SIGs may be approved (e.g., to address security or standards compliance).</p>
+  <p>Anyone (not limited to members of the XMPP Standards Foundation) may propose the formation of a SIG by completing a XMPP Extension Protocol outlining the need for the SIG and its proposed focus. However, SIG leaders must be members of the XMPP Standards Foundation. The number of leaders for a SIG is flexible, and shall be determined by each SIG, in consultation with the XMPP Council if necessary. The concept of "membership" with regard to SIGs is loose, and is essentially co-extensive with membership in the appropriate mailing list (each SIG has its own mailing list, which is archived for public review). SIG members do not need to be members of the XMPP Standards Foundation, and any member of the general public may subscribe to SIG mailing lists.</p>
+  <p>It is expected that all SIGs (other than certain standing SIGs) will remain active for as long as necessary in order to produce one or more standards-track specifications for review by the XMPP Council in the SIG's area of focus. However, if a SIG does not show signs of activity for an extended period of time (usually six months of inactivity on the SIG's mailing list), the SIG may be disbanded at the discretion of the XMPP Council with appropriate warning to the SIG members (usually in the form of an email sent to the SIG's mailing list).</p>
 </section1>
 </xep>

xep-0003.xml

@@ -12,7 +12,7 @@
   <number>0003</number>
   <status>Active</status>
   <type>Historical</type>
-  <jig>Standards JIG</jig>
+  <sig>Standards</sig>
   <dependencies>
     <spec>XMPP Core</spec>
   </dependencies>

xep-0004.xml

@@ -12,7 +12,7 @@
     <number>0004</number>
     <status>Final</status>
     <type>Standards Track</type>
-    <jig>Standards JIG</jig>
+    <sig>Standards</sig>
     <dependencies>
       <spec>XMPP Core</spec>
     </dependencies>
@@ -91,7 +91,7 @@
       <version>0.6</version>
       <date>2002-03-15</date>
       <initials>rwe</initials>
-      <remark>Protocol tweaks based on standards-jig discussion.</remark>
+      <remark>Protocol tweaks based on Standards list discussion.</remark>
     </revision>
     <revision>
       <version>0.5</version>
@@ -577,7 +577,7 @@
     <p>The &REGISTRAR; includes the 'jabber:x:data' namespace in its registry of protocol namespaces.</p>
   </section2>
   <section2 topic='Parameter Values' anchor='registrar-parameters'>
-    <p>The XMPP Registrar maintains a registry of parameter values related to the 'jabber:x:data' namespace, specifically as defined in &xep0068;; the registry is located at &lt;<link url="http://www.jabber.org/registrar/formtypes.html">http://www.jabber.org/registrar/formtypes.html</link>&gt;.</p>
+    <p>The XMPP Registrar maintains a registry of parameter values related to the 'jabber:x:data' namespace, specifically as defined in &xep0068;; the registry is located at &FORMTYPES;.</p>
   </section2>
 </section1>
 <section1 topic='XML Schema' anchor='schema'>

xep-0005.xml

@@ -12,7 +12,7 @@
   <number>0005</number>
   <status>Obsolete</status>
   <type>Informational</type>
-  <jig>None</jig>
+  <sig>None</sig>
   <author>
     <firstname>Jeremie</firstname>
     <surname>Miller</surname>

xep-0006.xml

@@ -11,8 +11,8 @@
   &LEGALNOTICE;
   <number>0006</number>
   <status>Obsolete</status>
-  <type>JIG Formation</type>
-  <jig>Forms, Security</jig>
+  <type>SIG Formation</type>
+  <sig>Forms, Security</sig>
   <author>
     <firstname>Adam</firstname>
     <surname>Theo</surname>
@@ -66,7 +66,7 @@
   </section2>
   <section2 topic='Storage'>
     <p>Storage is describing and accessing the physical location where the Profiles are kept. It will likely start off being only the Jabber Server, but will eventually allow for remote (specialized network hard drive services) and local (on the User's local machine or a portable floppy) storage. It also describes how this data will be transferred between computers and networks in an efficient and secure manner.</p>
-    <p>This will likely be the most other-JIG dependent part of the system, since we will have to make heavy use of encryption in Jabber, and likely file transfers. So we may want to help out those related JIGs when we get to this point to make sure their results can be used by this system.</p>
+    <p>This will likely be the most other-SIG dependent part of the system, since we will have to make heavy use of encryption in Jabber, and likely file transfers. So we may want to help out those related SIGs when we get to this point to make sure their results can be used by this system.</p>
   </section2>
   <section2 topic='Gate'>
     <p>Gate gives the User complete control at all times of others' access to and power over their Profiles. Since this system is designed to hold the bulk, if not all, of a User's personal information, they *must* have a powerful way to prevent unwanted others to access their data. So there must exist a powerful access regulation framework to precisely control which, when, and how other parties can get this information.</p>
@@ -75,22 +75,22 @@
 </section1>
 <section1 topic='Road-map'>
   <p>To make sure this project progresses smoothly and orderly, it has been decided it will be split up into steps, or 'Phases'. Each of the above four aspects will be split into two to four Phases, and the Road-map for the entire project will follow along these Phases. Version 1.0 of the Profiles system will be little more than an expanded vCard schema with simple rules and permissions to regulate access to it. It will progress up to Version 4.0 or 5.0, adding in advanced verification to persuade Services to use a User's Jabber Profiles instead of forcing them to set up a local account, and also adding write permissions so Services can set receipts of purchases and similar information in a User's Account.</p>
-  <p>This Road-map will be produced soon after the JIG is set up, and will give a good feature list and time-line to follow.</p>
+  <p>This Road-map will be produced soon after the SIG is set up, and will give a good feature list and time-line to follow.</p>
 </section1>
 <section1 topic='Benefits'>
   <p>Such an improved system would obviously provide for more types of information storage and management, but there are some other side-benefits that can be conceived of.</p>
   <ul>
     <li>Since the User will have all personal information in their one account, and Services can retrieve this information with permission, this could mean no more having to fill out forms, especially account sign-up forms with Services. The information can be automatically retrieved and filled in for you. This is similar to client-side form-filler applications, except it can be used from any computer, no matter what software it has installed on it.</li>
     <li>With write permission allowed to Services by the User, the Service can store their own Profiles about you in your Jabber Account. Information such as your Amazon wish list, receipts of purchases, calendar events, etc. This is similar to what Services do now, except you have control over where and how this information is physically stored and accessed.</li>
-    <li>Also, with an advanced authentication system (which will be the focus of a future JIG), a Service could use your Jabber Account to verify you are who you say you are, instead of requiring you set up a new account just with them. This is often called 'Universal Accounts', and similar to Microsoft's Passport and AOL's new Magic Carpet services.</li>
+    <li>Also, with an advanced authentication system (which will be the focus of a future SIG), a Service could use your Jabber Account to verify you are who you say you are, instead of requiring you set up a new account just with them. This is often called 'Universal Accounts', and similar to Microsoft's Passport and AOL's new Magic Carpet services.</li>
     <li>With cookies and other auto-detection methods allowed by the User, Services can automatically detect their JID from the web browser or other tool. This eliminates the step of the User having to type in their JID, and can make this system all the more seamless to them. Combined with the above universal account benefit, this is similar to single sign-on systems such as Microsoft's Passport or AOL's new Magic Carpet.</li>
   </ul>
 </section1>
 <section1 topic='Conclusion'>
-  <p>Eventually we would like this Profiles specification to completely replace the strict vCard schema that is 'hard-coded' into the protocol. We do not expect vCard to disappear from Jabber at all, simply be one possible Profile among many in a User's Account. At the end of this JIGs existence, we would like to see it integrate the Profiles and special 'jabber:profiles' namespaces fully into the rest of the Jabber protocol, having it become the method by which all User information (such as Roster, client-side preferences, and filters) is stored and retrieved.</p>
-  <p>It is important to note that this JIG will not be a stand-alone JIG. It will draw upon many other JIGs (that currently exist and that have yet to be created). It will need encryption from the Security JIG for safe transfer of the information, a versatile forms format from the Forms JIG for Profiles administration, and advanced authentication from a future JIG for Services to authenticate the User against their Jabber account.</p>
+  <p>Eventually we would like this Profiles specification to completely replace the strict vCard schema that is 'hard-coded' into the protocol. We do not expect vCard to disappear from Jabber at all, simply be one possible Profile among many in a User's Account. At the end of this SIGs existence, we would like to see it integrate the Profiles and special 'jabber:profiles' namespaces fully into the rest of the Jabber protocol, having it become the method by which all User information (such as Roster, client-side preferences, and filters) is stored and retrieved.</p>
+  <p>It is important to note that this SIG will not be a stand-alone SIG. It will draw upon many other SIGs (that currently exist and that have yet to be created). It will need encryption from the Security SIG for safe transfer of the information, a versatile forms format from the Forms SIG for Profiles administration, and advanced authentication from a future SIG for Services to authenticate the User against their Jabber account.</p>
 </section1>
 <section1 topic='History'>
-  <p>The concept of Jabber Profiles was started by Eric Murphy and Mike Hearn. They both had begun to come up with similar ideas, but did not meet and exchange ideas until around early 2001. Adam Theo also came across them soon after that, and after some discussion, the three authors of this document agreed to start a serious effort on developing it. We started it as a project at Theoretic Solutions (<link url="http://www.theoretic.com/identity/">http://www.theoretic.com/identity/</link>), although at that time it was as a full-fledged identity specification, complete with Profiles, Authentication, and Trust. It was not until we have now moved to set it up as an official JIG that we have split the individual parts up, to make it easier to develop.</p>
+  <p>The concept of Jabber Profiles was started by Eric Murphy and Mike Hearn. They both had begun to come up with similar ideas, but did not meet and exchange ideas until around early 2001. Adam Theo also came across them soon after that, and after some discussion, the three authors of this document agreed to start a serious effort on developing it. We started it as a project at Theoretic Solutions (<link url="http://www.theoretic.com/identity/">http://www.theoretic.com/identity/</link>), although at that time it was as a full-fledged identity specification, complete with Profiles, Authentication, and Trust. It was not until we have now moved to set it up as an official SIG that we have split the individual parts up, to make it easier to develop.</p>
 </section1>
 </xep>

xep-0007.xml

@@ -6,13 +6,13 @@
 <?xml-stylesheet type='text/xsl' href='xep.xsl'?>
 <xep>
 <header>
-  <title>Conferencing JIG</title>
+  <title>Conferencing SIG</title>
   <abstract>A proposal for a Jabber Interest Group that will discuss the protocol for implementing many-to-many communications.</abstract>
   &LEGALNOTICE;
   <number>0007</number>
   <status>Obsolete</status>
-  <type>JIG Proposal</type>
-  <jig>Conferencing</jig>
+  <type>SIG Proposal</type>
+  <sig>Conferencing</sig>
   <author>
     <firstname>David</firstname>
     <surname>Waite</surname>
@@ -36,7 +36,7 @@
   <p>The following proposal is for the formation of a Jabber Interest Group that will create a new conferencing protocol, as well as create additional functionality and standardize communications on top of said conferencing protocol.</p>
 </section1>
 <section1 topic='Base conferencing protocol'>
-  <p>The initial task of the Conferencing JIG will be to propose a Jabber Conferencing specification that will solve various problems which exist in the current "groupchat" specification. This specification is meant to be a foundation for additional functionality; it defines the framework needed to provide additional features, without requiring changes to the framework specification itself. There is also to be a certain amount of feature-negotiation included; the conferencing service can define what features can be declared for a room, both as optional and required client features for room participation.</p>
+  <p>The initial task of the Conferencing SIG will be to propose a Jabber Conferencing specification that will solve various problems which exist in the current "groupchat" specification. This specification is meant to be a foundation for additional functionality; it defines the framework needed to provide additional features, without requiring changes to the framework specification itself. There is also to be a certain amount of feature-negotiation included; the conferencing service can define what features can be declared for a room, both as optional and required client features for room participation.</p>
   <p>The framework's scope consists of the following minimum functionality:</p>
   <ul>
     <li>Browsing a list of public rooms</li>
@@ -68,6 +68,6 @@
   <p>Because of the prevalence of the existing "groupchat" specification for multi-user chats, a long conversion process is anticipated.  A server implementation which supports both protocols will simply not allow "groupchat"-only clients to participate in rooms with required features.</p> 
 </section1>
 <section1 topic='Continuing Development'>
-  <p>As listed above, there is a fairly large number of features that could be developed on top of a well-designed framework. The Conferencing JIG will first be established to develop a framework, with features mainly being compared against the framework for feasibility of implementation. After a proposal has been formalized as a specification, the JIG will become a group for discussing and proposing new features, and for formally specifying those features.</p>
+  <p>As listed above, there is a fairly large number of features that could be developed on top of a well-designed framework. The Conferencing SIG will first be established to develop a framework, with features mainly being compared against the framework for feasibility of implementation. After a proposal has been formalized as a specification, the SIG will become a group for discussing and proposing new features, and for formally specifying those features.</p>
 </section1>
 </xep>

xep-0008.xml

@@ -12,7 +12,7 @@
   <number>0008</number>
   <status>Deferred</status>
   <type>Historical</type>
-  <jig>Standards JIG</jig>
+  <sig>Standards</sig>
   <approver>Council</approver>
   <dependencies>
     <spec>XMPP Core</spec>
@@ -39,7 +39,7 @@
     <version>0.2</version>
     <date>2003-05-06</date>
     <initials>psa</initials>
-    <remark>At the request of the authors, the status of this document has been changed to Retracted, to be superseded by a forthcoming specification. This document will not be considered further by the Jabber Software Foundation and should not be used as a basis for implementations.</remark>
+    <remark>At the request of the authors, the status of this document has been changed to Retracted.</remark>
   </revision>
   <revision>
     <version>0.1</version>

xep-0009.xml

@@ -12,7 +12,7 @@
   <number>0009</number>
   <status>Final</status>
   <type>Standards Track</type>
-  <jig>Standards JIG</jig>
+  <sig>Standards</sig>
   <dependencies>
     <spec>XMPP Core</spec>
     <spec>XML-RPC</spec>