fix(AIP-203): explain IDENTIFIER behavior (#1241)

Author: noahdietz

aip/general/0203.md

@@ -70,6 +70,11 @@ The use of `IDENTIFIER` indicates that a field within a resource message is used
 to identify the resource. It **must** be attached to the `name` field and **must
 not** be attached to any other field (see [fields representing resource names]).
 
+The `IDENTIFIER` value conveys that the field is not accepted as input (i.e.
+`OUTPUT_ONLY`) in the context of a create method, while also being considered
+`IMMUTABLE` and accepted as input for mutation methods that accept the
+resource as the primary input e.g. [Standard Update][aip-134].
+
 This annotation **must not** be applied to references to other resources within
 a message.
 
@@ -220,6 +225,19 @@ There are some changes that *are* backwards compatible, which are as follows:
 
 ## Rationale
 
+### Identifier field behavior
+
+Resource names, the primary identifiers for any compliant resource, are never
+fully constructed by the user on create. Such fields are typically assigned
+`OUTPUT_ONLY` field behavior. They are, however, also often consumed as
+the primary identifier in scenarios where the resource itself is the primary
+request payload. Such fields could *not* be considered `OUTPUT_ONLY`.
+Furthermore, in mutation requests, like Standard Update, the resource name as
+the primary identifier cannot be changed in place. Such fields are typically
+assigned `IMMUTABLE` field behavior. These conflicting and context-dependent
+field behaviors meant that a new value was necessary to single out and convey
+the behavior of the resource name field.
+
 ### Required set of annotations
 
 A field used in a request message must be either an input or an output.