Merge pull request #1853 from matrix-org/anoa/3pid_typos

Replace "3pid" with "3PID"

changelogs/client_server/newsfragments/1853.clarification

@@ -0,0 +1 @@
+Fix various spelling mistakes throughout the specification.

changelogs/identity_service/newsfragments/1853.clarification

@@ -0,0 +1 @@
+Fix various spelling mistakes throughout the specification.

specification/client_server_api.rst

@@ -658,7 +658,7 @@ For example, to authenticate using the user's Matrix ID, clients would submit:
     "session": "<session ID>"
   }
 
-Alternatively reply using a 3pid bound to the user's account on the homeserver
+Alternatively reply using a 3PID bound to the user's account on the homeserver
 using the |/account/3pid|_ API rather then giving the ``user`` explicitly as
 follows:
 
@@ -675,7 +675,7 @@ follows:
     "session": "<session ID>"
   }
 
-In the case that the homeserver does not know about the supplied 3pid, the
+In the case that the homeserver does not know about the supplied 3PID, the
 homeserver must respond with 403 Forbidden.
 
 Google ReCaptcha
@@ -938,8 +938,8 @@ Third-party ID
 :Description:
   The user is identified by a third-party identifier in canonicalised form.
 
-A client can identify a user using a 3pid associated with the user's account on
-the homeserver, where the 3pid was previously associated using the
+A client can identify a user using a 3PID associated with the user's account on
+the homeserver, where the 3PID was previously associated using the
 |/account/3pid|_ API.  See the `3PID Types`_ Appendix for a list of Third-party
 ID media.
 
@@ -995,7 +995,7 @@ request as follows:
     "password": "<password>"
   }
 
-Alternatively, a client can use a 3pid bound to the user's account on the
+Alternatively, a client can use a 3PID bound to the user's account on the
 homeserver using the |/account/3pid|_ API rather then giving the ``user``
 explicitly, as follows:
 
@@ -1010,7 +1010,7 @@ explicitly, as follows:
     "password": "<password>"
   }
 
-In the case that the homeserver does not know about the supplied 3pid, the
+In the case that the homeserver does not know about the supplied 3PID, the
 homeserver must respond with ``403 Forbidden``.
 
 To log in using a login token, clients should submit a ``/login`` request as

specification/identity_service_api.rst

@@ -22,10 +22,10 @@ Identity Service API
 
 The Matrix client-server and server-server APIs are largely expressed in Matrix
 user identifiers. From time to time, it is useful to refer to users by other
-("third-party") identifiers, or "3pid"s, e.g. their email address or phone
+("third-party") identifiers, or "3PID"s, e.g. their email address or phone
 number. This Identity Service Specification describes how mappings between
 third-party identifiers and Matrix user identifiers can be established,
-validated, and used. This description technically may apply to any 3pid, but in
+validated, and used. This description technically may apply to any 3PID, but in
 practice has only been applied specifically to email addresses and phone numbers.
 
 .. contents:: Table of Contents
@@ -150,9 +150,9 @@ Identity is a privacy-sensitive issue. While the identity server exists to
 provide identity information, access should be restricted to avoid leaking
 potentially sensitive data. In particular, being able to construct large-scale
 connections between identities should be avoided. To this end, in general APIs
-should allow a 3pid to be mapped to a Matrix user identity, but not in the other
-direction (i.e. one should not be able to get all 3pids associated with a Matrix
-user ID, or get all 3pids associated with a 3pid).
+should allow a 3PID to be mapped to a Matrix user identity, but not in the other
+direction (i.e. one should not be able to get all 3PIDs associated with a Matrix
+user ID, or get all 3PIDs associated with a 3PID).
 
 Web browser clients
 -------------------
@@ -204,10 +204,10 @@ Establishing associations
 
 The flow for creating an association is session-based.
 
-Within a session, one may prove that one has ownership of a 3pid.
+Within a session, one may prove that one has ownership of a 3PID.
 Once this has been established, the user can form an association between that
-3pid and a Matrix user ID. Note that this association is only proved one way;
-a user can associate *any* Matrix user ID with a validated 3pid,
+3PID and a Matrix user ID. Note that this association is only proved one way;
+a user can associate *any* Matrix user ID with a validated 3PID,
 i.e. I can claim that any email address I own is associated with
 @billg:microsoft.com.
 
@@ -255,11 +255,11 @@ General
 Invitation storage
 ------------------
 
-An identity server can store pending invitations to a user's 3pid, which will
-be retrieved and can be either notified on or look up when the 3pid is
+An identity server can store pending invitations to a user's 3PID, which will
+be retrieved and can be either notified on or look up when the 3PID is
 associated with a Matrix user ID.
 
-At a later point, if the owner of that particular 3pid binds it with a Matrix user
+At a later point, if the owner of that particular 3PID binds it with a Matrix user
 ID, the identity server will attempt to make an HTTP POST to the Matrix user's
 homeserver via the `/3pid/onbind`_ endpoint. The request MUST be signed with a
 long-term private key for the identity server.