chore(AIP-203): resorting field behavior (#1200)

Making it a bit easier to find the appropriate field behavior with
alphabetical sorting.

Author: toumorokoshi

aip/general/0203.md

@@ -44,42 +44,41 @@ document this behavior for clients.
 
 ## Vocabulary
 
-### Required
+### Immutable
 
-The use of `REQUIRED` indicates that the field **must** be present (and set to
-a non-empty value) on the request or resource.
+The use of `IMMUTABLE` indicates that a field on a resource cannot be changed
+after it's creation. This can apply to either fields that are input or outputs,
+required or optional.
 
-A field **should** only be described as required if _either_:
+When a service receives an immutable field in an update request (or similar),
+even if included in the update mask, the service **should** ignore the field if
+the value matches, but **should** error with `INVALID_ARGUMENT` if a change is
+requested.
 
-- It is a field on a resource that a user provides somewhere as input. In this
-  case, the resource is only valid if a "truthy" value is _stored_.
-  - When [creating][aip-133] the resource, a value **must** be provided for the
-    field on the create request.
-  - When [updating][aip-134] the resource, the user **may** omit the field
-    provided that the field is also absent from the field mask, indicating no
-    change to the field (otherwise it **must** be provided).
-- It is a field on a request message (a message that is an argument to an RPC,
-  with a name usually ending in `Request`). In this case, a value **must** be
-  provided as part of the request, and failure to do so **must** cause an error
-  (usually `INVALID_ARGUMENT`).
+Potential use cases for immutable fields (this is not an exhaustive list) are:
 
-We define the term "truthy" above as follows:
+- Names or IDs which are set on creation and then used as a primary key.
 
-- For primitives, values other than `0`, `0.0`, empty string/bytes, and `false`
-- For repeated fields maps, values with at least one entry
-- For messages, any message with at least one "truthy" field.
+**Note:** Fields which are "conditionally immutable" **must not** be given the
+immutable annotation.
 
-Fields **should not** be described as required in order to signify:
+### Input only
 
-- A field which will always be present in a response.
-- A field which is conditionally required in some situations.
-- A field on any message (including messages that are resources) which is never
-  used as user input.
+The use of `INPUT_ONLY` indicates that the field is provided in requests and
+that the corresponding field will not be included in output.
 
-**Note:** In most cases, empty values (such as `false` for booleans, `0` for
-integers, or the unspecified value for enums) are indistinguishable from unset
-values, and therefore setting a required field to a falsy value yields an
-error. A corollary to this is that a required boolean must be set to `true`.
+Additionally, a field **should** only be described as input only if it is a
+field in a resource message or a field of a message included within a resource
+message. Notably, fields in request messages (a message which only ever acts as
+an argument to an RPC, with a name usually ending in `Request`) **should not**
+be described as input only because this is already implied.
+
+Potential use cases for input only fields (this is not an exhaustive list) are:
+
+- The `ttl` field as described in AIP-214.
+
+**Warning:** Input only fields are rare and should be considered carefully
+before use.
 
 ### Optional
 
@@ -112,41 +111,42 @@ are:
 - Derived or structured information based on original user input.
 - Properties of a resource assigned by the service which can not be altered.
 
-### Input only
-
-The use of `INPUT_ONLY` indicates that the field is provided in requests and
-that the corresponding field will not be included in output.
-
-Additionally, a field **should** only be described as input only if it is a
-field in a resource message or a field of a message included within a resource
-message. Notably, fields in request messages (a message which only ever acts as
-an argument to an RPC, with a name usually ending in `Request`) **should not**
-be described as input only because this is already implied.
-
-Potential use cases for input only fields (this is not an exhaustive list) are:
+### Required
 
-- The `ttl` field as described in AIP-214.
+The use of `REQUIRED` indicates that the field **must** be present (and set to
+a non-empty value) on the request or resource.
 
-**Warning:** Input only fields are rare and should be considered carefully
-before use.
+A field **should** only be described as required if _either_:
 
-### Immutable
+- It is a field on a resource that a user provides somewhere as input. In this
+  case, the resource is only valid if a "truthy" value is _stored_.
+  - When [creating][aip-133] the resource, a value **must** be provided for the
+    field on the create request.
+  - When [updating][aip-134] the resource, the user **may** omit the field
+    provided that the field is also absent from the field mask, indicating no
+    change to the field (otherwise it **must** be provided).
+- It is a field on a request message (a message that is an argument to an RPC,
+  with a name usually ending in `Request`). In this case, a value **must** be
+  provided as part of the request, and failure to do so **must** cause an error
+  (usually `INVALID_ARGUMENT`).
 
-The use of `IMMUTABLE` indicates that a field on a resource cannot be changed
-after it's creation. This can apply to either fields that are input or outputs,
-required or optional.
+We define the term "truthy" above as follows:
 
-When a service receives an immutable field in an update request (or similar),
-even if included in the update mask, the service **should** ignore the field if
-the value matches, but **should** error with `INVALID_ARGUMENT` if a change is
-requested.
+- For primitives, values other than `0`, `0.0`, empty string/bytes, and `false`
+- For repeated fields maps, values with at least one entry
+- For messages, any message with at least one "truthy" field.
 
-Potential use cases for immutable fields (this is not an exhaustive list) are:
+Fields **should not** be described as required in order to signify:
 
-- Names or IDs which are set on creation and then used as a primary key.
+- A field which will always be present in a response.
+- A field which is conditionally required in some situations.
+- A field on any message (including messages that are resources) which is never
+  used as user input.
 
-**Note:** Fields which are "conditionally immutable" **must not** be given the
-immutable annotation.
+**Note:** In most cases, empty values (such as `false` for booleans, `0` for
+integers, or the unspecified value for enums) are indistinguishable from unset
+values, and therefore setting a required field to a falsy value yields an
+error. A corollary to this is that a required boolean must be set to `true`.
 
 ### Unordered List