11.2 The <zone_id> Part
11.2 The <zone_id> Part
In the textual representation, the <zone_id> part should be able to identify a particular zone of the address's scope. Although a zone index is expected to contain enough information to determine the scope and to be unique among all scopes as described in Section 6, the <zone_id> part of this format does not have to contain the scope. This is because the <address> part should specify the appropriate scope. This also means that the <zone_id> part does not have to be unique among all scopes.
With this loosened property, an implementation can use a convenient representation as <zone_id>. For example, to represent link index 2, the implementation can simply use "2" as <zone_id>, which would be more readable than other representations that contain the "link" scope.
When an implementation interprets the format, it should construct the "full" zone index, which contains the scope, from the <zone_id> part and the scope specified by the <address> part. (Remember that a zone index itself should contain the scope, as specified in Section 6.)
An implementation SHOULD support at least numerical indices that are non-negative decimal integers as <zone_id>. The default zone index, which should typically be 0 (see Section 6), is included in the integers. When <zone_id> is the default, the delimiter characters "%" and <zone_id> can be omitted. Similarly, if a textual representation of an IPv6 address is given without a zone index, it should be interpreted as <address>%<default ID>, where <default ID> is the default zone index of the scope that <address> has.
An implementation MAY support other kinds of non-null strings as <zone_id>. However, the strings must not conflict with the delimiter character. The precise format and semantics of additional strings is implementation dependent.
One possible candidate for these strings would be interface names, as interfaces uniquely disambiguate any scopes. In particular, interface names can be used as "default identifiers" for interfaces and links, because by default there is a one-to-one mapping between interfaces and each of those scopes as described in Section 6.
An implementation could also use interface names as <zone_id> for scopes larger than links, but there might be some confusion in this use. For example, when more than one interface belongs to the same (multicast) site, a user would be confused about which interface should be used. Also, a mapping function from an address to a name would encounter the same kind of problem when it prints an address with an interface name as a zone index. This document does not specify how these cases should be treated and leaves it implementation dependent.
It cannot be assumed that indices are common across all nodes in a zone (see Section 6). Hence, the format MUST be used only within a node and MUST NOT be sent on the wire unless every node that interprets the format agrees on the semantics.