chore(AIP-122): add some rationale for resource names (#1430)

Author: noahdietz

aip/general/0122.md

@@ -352,6 +352,34 @@ message Book {
 
 ## Rationale
 
+### Using names instead of IDs
+
+For any large system, there are many kinds of resources. To use simple resource
+IDs to identify a resource, we'd actually need use a resource-specific tuple to
+reliably identify it, such as `(bucket, object)` or `(user, album, photo)`. This
+creates several issues:
+
+* Developers have to understand and remember such anonymous tuples.
+* Passing tuples is generally harder than passing strings.
+* Centralized infrastructures, such as logging and access control systems,
+  don't understand specialized tuples.
+* Specialized tuples limit API design flexibility, such as providing
+  reusable API interfaces. For example,
+  [Long Running Operations][aip-151] can work with many other API interfaces
+  because they use flexible resource names.
+
+[aip-151]: ./0151.md
+
+### Standardizing on `name`
+
+The concept of resource names is not a new one, and is formalized in Uniform
+Resource Names (URN) in conjunction with Uniform Resource Identifiers (URI) and
+Uniform Resource Locators (URL). Considering that the term "name" is so heavily
+overloaded in general, usage outside of a very well-defined meaning would be
+confusing for developers. So, the field name `name` is reserved in the context
+of AIP-compliant APIs so as to eliminate any confusion with resource names, and
+force other would be "name" fields to use a more specific field name.
+
 ### Disallow embedding of resources
 
 Using a resource message directly as the type of a field within another resource
@@ -374,6 +402,8 @@ isolation of logical concerns per-resource.
 
 ## Changelog
 
+- **2024-10-15**: Add some rationale we found for use of `name` as a field and
+  instead of IDs as an identifier.
 - **2024-06-14**: Clarify resource annotation shortening rules for nested
   collections.
 - **2023-09-19**: Prohibit duplicate collection identifiers.