conn parameters: rename 'account' to 'username'account-to-username-25033

Bug: https://bugs.freedesktop.org/show_bug.cgi?id=25033
Signed-off-by: Jonny Lamb <jonny.lamb@collabora.co.uk>

5 files changed, 17 insertions, 17 deletions

diff --git a/spec/Account.xml b/spec/Account.xml
index b700b8fa..671565e6 100644
--- a/spec/Account.xml
+++ b/spec/Account.xml
@@ -50,7 +50,7 @@ Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.
         <li>The account manager SHOULD choose <em>acct</em> such that if
           an account is deleted, its object path will be re-used if and only
           if the new account is in some sense "the same"
-          (incorporating the 'account' parameter in some way is
+          (incorporating the 'username' parameter in some way is
           recommended)</li>
       </ul>
 
@@ -704,7 +704,7 @@ Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.
         in the past.
 
         <tp:rationale>
-          UIs could apply a policy that the 'account' parameter can only be
+          UIs could apply a policy that the 'username' parameter can only be
           edited in accounts that have never been online, or that
           ConnectAutomatically cannot be set on such accounts. The account
           manager should not enforce such policies, but it can expose enough
diff --git a/spec/Account_Manager.xml b/spec/Account_Manager.xml
index 7a281951..6498981b 100644
--- a/spec/Account_Manager.xml
+++ b/spec/Account_Manager.xml
@@ -214,7 +214,7 @@ Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.
             namespace="im.telepathy1.Account">DisplayName</tp:dbus-ref>
           property. The account manager SHOULD modify this to make it unique if
           an Account already exists with the same display name, for instance by
-          appending a number or the 'account' parameter. Account manager
+          appending a number or the username' parameter. Account manager
           implementations SHOULD accept an empty string, but account editing
           user interfaces should avoid passing an empty string for this
           parameter.
diff --git a/spec/Channel_Interface_SASL_Authentication1.xml b/spec/Channel_Interface_SASL_Authentication1.xml
index b58c90e5..507cc4ca 100644
--- a/spec/Channel_Interface_SASL_Authentication1.xml
+++ b/spec/Channel_Interface_SASL_Authentication1.xml
@@ -224,7 +224,7 @@ Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.</
       type="s" access="read" tp:immutable="yes">
       <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
         <p>The identity for which authorization is being attempted,
-          typically the 'account' from the <tp:dbus-ref
+          typically the 'username' from the <tp:dbus-ref
             namespace="imt1.ConnectionManager">RequestConnection</tp:dbus-ref>
           parameters, normalized and formatted according to the
           conventions used for SASL in this protocol.</p>
@@ -262,7 +262,7 @@ Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.</
             or some other identity.</p>
 
           <p>As a concrete example, the "sysadmin" XMPP account mentioned
-            above would have <code>{ 'account': 'sysadmin@example.com' }</code>
+            above would have <code>{ 'username': 'sysadmin@example.com' }</code>
             in its Parameters, and this property would also be
             'sysadmin@example.com'. A simple Handler would
             merely prompt for sysadmin@example.com's password,
@@ -312,7 +312,7 @@ Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.</
         <p>For example, in the simple case, if the user connects with
         <tp:dbus-ref
         namespace="imt1.ConnectionManager">RequestConnection</tp:dbus-ref>({
-        account: "<tt>user@example.com</tt>" }) and use PLAIN with
+        username: "<tt>user@example.com</tt>" }) and use PLAIN with
         password "password", he or she should authenticate like so:
         "<tt>\0user\0password</tt>" and the channel will look like
         this:</p>
@@ -325,7 +325,7 @@ Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.</
           sysadmin powers to log in as the "announcements" role address,
           he or she would connect with <tp:dbus-ref
             namespace="imt1.ConnectionManager">RequestConnection</tp:dbus-ref>({
-          account: "<tt>announcements@example.com</tt>" }) and the SASL
+          username: "<tt>announcements@example.com</tt>" }) and the SASL
           channel would look like this:</p>
 
 <blockquote><pre>{ "...<tp:member-ref>DefaultUsername</tp:member-ref>": "announcements",
diff --git a/spec/Connection.xml b/spec/Connection.xml
index d0a9b220..05e40065 100644
--- a/spec/Connection.xml
+++ b/spec/Connection.xml
@@ -756,9 +756,9 @@ USA.</p>
 
       <p>In order to allow Connection objects to be discovered by new clients,
         the object path and well-known bus name MUST be of the form
-        <code>/im/telepathy1/Connection/cmname/proto/account</code>
+        <code>/im/telepathy1/Connection/cmname/proto/username</code>
         and
-        <code>im.telepathy1.Connection.cmname.proto.account</code>
+        <code>im.telepathy1.Connection.cmname.proto.username</code>
         where:</p>
 
       <ul>
@@ -769,11 +769,11 @@ USA.</p>
           <tp:dbus-ref namespace="imt1.ConnectionManager">Protocols</tp:dbus-ref>,
           but with "-" replaced with "_" to get a valid
           object path/bus name</li>
-        <li><em>account</em> is some non-empty sequence of ASCII letters,
+        <li><em>username</em> is some non-empty sequence of ASCII letters,
           digits and underscores not starting with a digit</li>
       </ul>
 
-      <p><em>account</em> SHOULD be formed such that any valid distinct
+      <p><em>username</em> SHOULD be formed such that any valid distinct
         connection instance on this protocol has a distinct name. This
         might be formed by including the server name followed by the user
         name (escaped via some suitable mechanism like telepathy-glib's
@@ -784,7 +784,7 @@ USA.</p>
 
       <p>Clients MAY parse the object path to determine the connection
         manager name and the protocol, but MUST NOT attempt to parse the
-        <em>account</em> part. Connection managers MAY use any unique string
+        <em>username</em> part. Connection managers MAY use any unique string
         for this part.</p>
 
     <p>As well as the methods and signatures below, arbitrary interfaces may be
@@ -812,7 +812,7 @@ USA.</p>
     alone (without its type) is meaningless or ambiguous.</p>
     </tp:docstring>
 
-    <tp:changed version="0.17.10">Previously, the account part of
+    <tp:changed version="0.17.10">Previously, the username part of
       Connection bus names/object paths was allowed to have more than one
       component (i.e. contain dots or slashes), resulting in Connection
       bus names and object paths with more than 7 components. We now restrict
diff --git a/spec/Protocol.xml b/spec/Protocol.xml
index 7197b81d..c2408f67 100644
--- a/spec/Protocol.xml
+++ b/spec/Protocol.xml
@@ -54,7 +54,7 @@ Interfaces=
 [Protocol example]
 Interfaces=
 ConnectionInterfaces=im.telepathy1.Connection.Interface.Requests;
-param-account=s required
+param-username=s required
 param-password=s required secret
 RequestableChannelClasses=text;
 VCardField=x-example
@@ -191,7 +191,7 @@ allowed=im.telepathy1.Channel.TargetHandle;im.telepathy1.Channel.TargetID;
           Call audio calls:</p>
 
 <pre>[Protocol jabber]
-param-account=s required
+param-username=s required
 param-password=s required
 RequestableChannelClasses=rcc0;rcc1;
 
@@ -321,9 +321,9 @@ allowed=im.telepathy1.Channel.TargetHandle;im.telepathy1.Channel.TargetID;im.tel
           given parameters would connect.</p>
 
         <tp:rationale>
-          <p>For many protocols, this would return the well-known 'account'
+          <p>For many protocols, this would return the well-known 'username'
             parameter. However, for IRC the returned string would be composed
-            from the 'account' (i.e. nickname) and 'server' parameters.
+            from the username' (i.e. nickname) and 'server' parameters.
             AccountManager implementations can use this to form the
             account-specific part of an Account's object path.</p>
         </tp:rationale>