11.2. The <zone_id> Part (La parte <zone_id>)
11.2. The <zone_id> Part (La parte <zone_id>)
Nella rappresentazione testuale, la parte <zone_id> dovrebbe essere in grado di identificare una particolare zona dell'ambito dell'indirizzo. Sebbene un indice di zona sia previsto per contenere informazioni sufficienti per determinare l'ambito e per essere univoco tra tutti gli ambiti come descritto nella Sezione 6, la parte <zone_id> di questo formato non deve contenere l'ambito. Questo perché la parte <address> dovrebbe specificare l'ambito appropriato. Ciò significa anche che la parte <zone_id> non deve essere univoca tra tutti gli ambiti.
Con questa proprietà allentata, un'implementazione può utilizzare una rappresentazione conveniente come <zone_id>. Ad esempio, per rappresentare l'indice di link 2, l'implementazione può semplicemente utilizzare "2" come <zone_id>, che sarebbe più leggibile rispetto ad altre rappresentazioni che contengono l'ambito "link".
Quando un'implementazione interpreta il formato, dovrebbe costruire l'indice di zona "completo", che contiene l'ambito, dalla parte <zone_id> e l'ambito specificato dalla parte <address>. (Ricordate che un indice di zona stesso dovrebbe contenere l'ambito, come specificato nella Sezione 6.)
Un'implementazione DOVREBBE supportare almeno indici numerici che sono interi decimali non negativi come <zone_id>. L'indice di zona predefinito, che dovrebbe tipicamente essere 0 (vedi Sezione 6), è incluso negli interi. Quando <zone_id> è il predefinito, i caratteri delimitatori "%" e <zone_id> possono essere omessi. Allo stesso modo, se una rappresentazione testuale di un indirizzo IPv6 è data senza un indice di zona, dovrebbe essere interpretata come <address>%<default ID>, dove <default ID> è l'indice di zona predefinito dell'ambito che <address> ha.
Un'implementazione PUÒ supportare altri tipi di stringhe non nulle come <zone_id>. Tuttavia, le stringhe non DEVONO entrare in conflitto con il carattere delimitatore. Il formato preciso e la semantica di stringhe aggiuntive è dipendente dall'implementazione.
Un possibile candidato per queste stringhe sarebbero i nomi di interfaccia, poiché le interfacce disambiguano univocamente qualsiasi ambito. In particolare, i nomi di interfaccia possono essere utilizzati come "identificatori predefiniti" per le interfacce e i link, perché per impostazione predefinita c'è una mappatura uno-a-uno tra le interfacce e ognuno di questi ambiti come descritto nella Sezione 6.
Un'implementazione potrebbe anche utilizzare i nomi di interfaccia come <zone_id> per ambiti più grandi dei link, ma potrebbe esserci una certa confusione in questo utilizzo. Ad esempio, quando più di un'interfaccia appartiene allo stesso sito (multicast), un utente potrebbe essere confuso su quale interfaccia dovrebbe essere utilizzata. Inoltre, una funzione di mappatura da un indirizzo a un nome incontrerebbe lo stesso tipo di problema quando stampa un indirizzo con un nome di interfaccia come indice di zona. Questo documento non specifica come questi casi dovrebbero essere trattati e lo lascia dipendente dall'implementazione.
Non si può presumere che gli indici siano comuni su tutti i nodi in una zona (vedi Sezione 6). Pertanto, il formato DEVE essere utilizzato solo all'interno di un nodo e NON DEVE essere inviato via cavo a meno che ogni nodo che interpreta il formato non concordi sulla semantica.