AIP-122 and AIP-162 both deal in the concept of an "alias" for a resource, allowing resources to be referenced for convenience by IDs other than the resource's actual canonical ID.

AIP-122 provides that when an alias is used in a lookup, the returned data must use the canonical resource name (unless it's an AIP-2510 Project ID). But the topic of what should occur when a resource is referenced by alias from a field in another resource is not addressed.

It would be convenient in such cases to be able to reference a resource by alias and have it be normalized by the system to the canonical resource name. For example, referencing the AIP-162 system-defined latest alias.

However, AIP-129 provides that normalizing fields is entirely prohibited except for string fields annotated with an AIP-202 google.api.field_info data type annotation, and none of the existing Format variants are applicable.

(There isn't one for emails either, which is the subject of #1448)

User-Specified Fields

For user-specified fields, the value in response from the service must be the same as provided by the create or update request. For string fields this means returning the value unchanged, with one exception:

When a string field has a data type annotation, a normalized string that represents the given value may be returned.

Normalizations

A field that is normalized by the service must be annotated with the google.api.field_info extension. See (AIP-202) for guidance on using this extension The allowed set of normalizations includes the following formats:

• uuid
• ipv4
• ipv6
• email

To address this, I propose adding a new Format variant like RESOURCE_ALIAS, which a service may choose to normalize to the canonical resource name.