Clarify that size limits are in bytes

In almost all instances we are already talking about UTF-8 encoded
ASCII. As such this is not a behavioural change apart from in theory
legacy identifiers, that never were part of the spec.

fixes #1001

Signed-off-by: Nicolas Werner <nicolas.werner@hotmail.de>
This commit is contained in:
Nicolas Werner 2022-09-09 13:32:34 +02:00
parent a6990ff27c
commit 9af3059db5
No known key found for this signature in database
GPG key ID: C8D75E610773F2D9
11 changed files with 14 additions and 14 deletions

View file

@ -9,7 +9,7 @@ type: docs
*Unpadded* Base64 refers to 'standard' Base64 encoding as defined in
[RFC 4648](https://tools.ietf.org/html/rfc4648), without "=" padding.
Specifically, where RFC 4648 requires that encoded data be padded to a
multiple of four characters using `=` characters, unpadded Base64 omits
multiple of four bytes using `=` characters, unpadded Base64 omits
this padding.
For reference, RFC 4648 uses the following alphabet for Base 64:
@ -398,7 +398,7 @@ identifiers.
The grammar is defined as follows:
* An identifier must be at least one character and at most 255 characters
* An identifier must be at least one character and at most 255 bytes
in length.
* Identifiers must start with one of the characters `[a-z]`, and be entirely
composed of the characters `[a-z]`, `[0-9]`, `-`, `_` and `.`.
@ -483,7 +483,7 @@ Server names must be treated case-sensitively: in other words,
Some recommendations for a choice of server name follow:
- The length of the complete server name should not exceed 230
characters.
bytes.
- Server names should not use upper-case characters.
### Common Identifier Format
@ -535,7 +535,7 @@ The `domain` of a user ID is the [server name](#server-name) of the
homeserver which allocated the account.
The length of a user ID, including the `@` sigil and the domain, MUST
NOT exceed 255 characters.
NOT exceed 255 bytes.
The complete grammar for a legal user ID is:

View file

@ -375,7 +375,7 @@ be inappropriate to expect a user to copy a long passphrase including
punctuation from an SMS message into a client.)
Whatever format the identity server uses, the validation token must
consist of at most 255 Unicode codepoints. Clients must pass the token
consist of at most 255 UTF-8 bytes. Clients must pass the token
through without modification.
### Email associations

View file

@ -85,7 +85,7 @@ authorization would cause older servers to potentially end up in a
split-brain situation due to not understanding the new rules.
A room version is defined as a string of characters which MUST NOT
exceed 32 codepoints in length. Room versions MUST NOT be empty and
exceed 32 bytes in length. Room versions MUST NOT be empty and
SHOULD contain only the characters `a-z`, `0-9`, `.`, and `-`.
Room versions are not intended to be parsed and should be treated as

View file

@ -19,7 +19,7 @@ properties:
description: |-
The session ID. Session IDs are opaque strings that must consist entirely
of the characters `[0-9a-zA-Z.=_-]`. Their length must not exceed 255
characters and they must not be empty.
bytes and they must not be empty.
example: "123abc"
submit_url:
type: string

View file

@ -40,7 +40,7 @@ properties:
description: |-
Opaque string chosen by the homeserver, uniquely identifying
the IdP from other IdPs the homeserver might support. Should
be between 1 and 255 characters in length, containing unreserved
be between 1 and 255 bytes in length, containing unreserved
characters under [RFC 3986](http://www.ietf.org/rfc/rfc3986.txt)
(`ALPHA DIGIT "-" / "." / "_" / "~"`). Clients are not intended
to parse or infer meaning from opaque strings.

View file

@ -23,7 +23,7 @@ properties:
description: |
A unique string generated by the client, and used to identify the
validation attempt. It must be a string consisting of the characters
`[0-9a-zA-Z.=_-]`. Its length must not exceed 255 characters and it
`[0-9a-zA-Z.=_-]`. Its length must not exceed 255 bytes and it
must not be empty.
example: "monkeys_are_GREAT"
email:

View file

@ -24,7 +24,7 @@ properties:
description: |
A unique string generated by the client, and used to identify the
validation attempt. It must be a string consisting of the characters
`[0-9a-zA-Z.=_-]`. Its length must not exceed 255 characters and it
`[0-9a-zA-Z.=_-]`. Its length must not exceed 255 bytes and it
must not be empty.
example: "monkeys_are_GREAT"
country:

View file

@ -18,7 +18,7 @@ properties:
description: |
The session ID. Session IDs are opaque strings generated by the identity
server. They must consist entirely of the characters
`[0-9a-zA-Z.=_-]`. Their length must not exceed 255 characters and they
`[0-9a-zA-Z.=_-]`. Their length must not exceed 255 bytes and they
must not be empty.
example: "123abc"
required: ['sid']

View file

@ -135,7 +135,7 @@ paths:
description: |
The generated token. Must be a string consisting of the
characters `[0-9a-zA-Z.=_-]`. Its length must not exceed
255 characters and it must not be empty.
255 bytes and it must not be empty.
public_keys:
type: array
description: |

View file

@ -43,7 +43,7 @@ allOf:
message_id:
type: string
description: Unique ID for the message, used for idempotence. Arbitrary
utf8 string, of maximum length 32 codepoints.
utf8 string, of maximum length 32 bytes.
example: "hiezohf6Hoo7kaev"
messages:
type: object

View file

@ -22,7 +22,7 @@ properties:
compared against other children's `order`, if present.
Must consist of ASCII characters within the range `\x20` (space) and `\x7E` (`~`),
inclusive. Must not exceed 50 characters.
inclusive. Must not exceed 50 bytes.
`order` values with the wrong type, or otherwise invalid contents, are to be treated
as though the `order` key was not provided.