Fix a bunch of rst syntax errors.

drafts/general_api.rst

@@ -111,6 +111,7 @@ Global initial sync API ``[Draft]``
       - The invite event
       - Other state info (e.g. room name, topic, join_rules to know if pubilc)
       - # members?
+
     so clients know more information about the room other than the user_id of the
     inviter, timestamp and the room ID.
 
@@ -637,7 +638,7 @@ A client may wish to send multiple actions in parallel. The send event APIs
 support sending multiple events in a batch.
  
 Inviting a user ``[ONGOING]``
-~~~~~~~~~~~~~~~~~~~~~~~~~~~
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 .. NOTE::
   - Clients need to know *why* they are being invited (e.g. a ``reason`` key,
     just like for kicks/bans). However, this opens up a spam vector where any
@@ -1028,8 +1029,8 @@ relate to other events are referred to as "Child Events". The event being
 related to is referred to as "Parent Events". Child events cannot stand alone as
 a separate entity; they require the parent event in order to make sense.
 
-Bundling
-++++++++
+Bundling updates
+++++++++++++++++
 Events that relate to another event should come down inside that event. That is,
 the top-level event should come down with all the child events at the same time.
 This is called a "bundle" and it is represented as an array of events inside the
@@ -1081,8 +1082,8 @@ not update the event itself*, and are *not required* in order to display the
 parent event. Crucially, the child events can be paginated, whereas ``updates`` 
 child events cannot be paginated.
 
-Bundling
-++++++++
+Bundling relations
+++++++++++++++++++
 Child events can be optionally bundled with the parent event, depending on your 
 display mechanism. The number of child events which can be bundled should be 
 limited to prevent events becoming too large. This limit should be set by the 

drafts/model/profiles.rst

@@ -198,12 +198,11 @@ Requests that a client can make to its Home Server
 
  * get another user's Display Name / Avatar / metadata fields
 
-[[TODO(paul): At some later stage we should consider the API for:
+TODO(paul): At some later stage we should consider the API for:
 
  * get/set ACL permissions on my metadata fields
 
  * manage my ACL tokens
-]]
 
 Server-Server
 -------------

drafts/model/protocol_examples.rst

@@ -3,7 +3,9 @@ Host: ...
 Content-Length: ...
 Content-Type: application/json
 
-{
+.. code :: javascript
+
+  {
     "origin": "localhost:5000",
     "pdus": [
         {
@@ -27,7 +29,7 @@ Content-Type: application/json
         "1404381396852"
     ],
     "ts": 1404381427823
-}
+  }
 
 HTTP/1.1 200 OK
 ...
@@ -42,7 +44,9 @@ HTTP/1.1 200 OK
 Content-Length: ...
 Content-Type: application/json
 
-{
+.. code :: javascript
+
+  {
     origin: ...,
     prev_ids: ...,
     data: [
@@ -59,6 +63,6 @@ Content-Type: application/json
         },
         ...,
     ]
-}
+  }
 
 

drafts/model/rooms.rst

@@ -125,13 +125,14 @@ m.invite_level
 m.join_rules
   Encodes the rules on how non-members can join the room. Has the following
   possibilities:
-    "public" - a non-member can join the room directly
-    "knock" - a non-member cannot join the room, but can post a single "knock"
-        message requesting access, which existing members may approve or deny
-    "invite" - non-members cannot join the room without an invite from an
-        existing member
-    "private" - nobody who is not in the 'may_join' list or already a member
-        may join by any mechanism
+
+    - "public" - a non-member can join the room directly
+    - "knock" - a non-member cannot join the room, but can post a single "knock"
+      message requesting access, which existing members may approve or deny
+    - "invite" - non-members cannot join the room without an invite from an
+      existing member
+    - "private" - nobody who is not in the 'may_join' list or already a member
+      may join by any mechanism
 
   In any of the first three modes, existing members with sufficient permission
   can send invites to non-members if allowed by the "m.invite_level" key. A
@@ -263,10 +264,11 @@ resolve this:
    that duplicate requests can be suppressed. On receipt of a room creation
    request that the HS thinks there already exists a room for, the invitation to
    join can be rejected if:
-      a) the HS believes the sending user is already a member of the room (and
-         maybe their HS has forgotten this fact), or
-      b) the proposed room has a lexicographically-higher ID than the existing
-         room (to resolve true race condition conflicts)
+
+      - a) the HS believes the sending user is already a member of the room (and
+        maybe their HS has forgotten this fact), or
+      - b) the proposed room has a lexicographically-higher ID than the existing
+        room (to resolve true race condition conflicts)
       
  * The room ID for a private 1:1 chat has a special form, determined by
    concatenting the User IDs of both members in a deterministic order, such that