Merge branch 'master' into proofing

Conflicts:
	specification/0-intro.rst

event-schemas/schema/v1/core-event-schema/state_event.json

@@ -8,7 +8,7 @@
   "properties": {
     "state_key": {
       "type": "string",
-      "description": "A unique key which defines the overwriting semantics for this piece of room state. This value is often a zero-length string. The presence of this key makes this event a State Event."
+      "description": "A unique key which defines the overwriting semantics for this piece of room state. This value is often a zero-length string. The presence of this key makes this event a State Event. The key MUST NOT start with '_'."
     },
     "prev_content": {
       "type": "object",

event-schemas/schema/v1/m.room.name

@@ -11,7 +11,7 @@
             "properties": {
                 "name": {
                     "type": "string",
-                    "description": "The name of the room."
+                    "description": "The name of the room. This MUST NOT exceed 255 bytes."
                 }
             },
             "required": ["name"]

specification/0-events.rst

@@ -12,6 +12,22 @@ server-server and application-service APIs, and are described below.
 {{common_state_event_fields}}
 
 
+Size limits
+-----------
+
+The total size of any event MUST NOT exceed 65 KB. There are additional
+restrictions on sizes per key:
+
+ - ``user_id`` MUST NOT exceed 255 bytes (including domain).
+ - ``room_id`` MUST NOT exceed 255 bytes.
+ - ``state_key`` MUST NOT exceed 255 bytes.
+ - ``type`` MUST NOT exceed 255 bytes.
+ - ``event_id`` MUST NOT exceed 255 bytes.
+
+Some event types have additional size restrictions which are specified in
+the description of the event. Additional keys have no limit other than that
+implied by the total 65 KB limit on events.
+
 Room Events
 -----------
 .. NOTE::

specification/0-intro.rst

@@ -295,7 +295,9 @@ rooms are publicised and discovered.  The room ID the alias is pointing to can
 be obtained by visiting the domain specified. Note that the mapping from a room
 alias to a room ID is not fixed, and may change over time to point to a
 different room ID. For this reason, Clients SHOULD resolve the room alias to a
-room ID once and then use that ID on subsequent requests.
+room ID once and then use that ID on subsequent requests. Room aliases MUST NOT
+exceed 255 bytes (including the domain).
+
 
 When resolving a room alias the server will also respond with a list of servers
 that are in the room that can be used to join via.

specification/3-application_service_api.rst

@@ -54,6 +54,11 @@ An example HS configuration required to pass traffic to the AS is:
       aliases: []  # Namespaces of room aliases which should be delegated to the AS
       rooms: [] # Namespaces of room ids which should be delegated to the AS
 
+.. WARNING::
+  If the homeserver in question has multiple application services, each
+  ``as_token`` MUST be unique per application service as this token is used to
+  identify the application service. The homeserver MUST enforce this.
+
 - An application service can state whether they should be the only ones who 
   can manage a specified namespace. This is referred to as an "exclusive" 
   namespace. An exclusive namespace prevents humans and other application