5. Evoluzione futura di CBOR

I protocolli di successo evolvono nel tempo. Nascono nuove idee, le piattaforme di implementazione migliorano, protocolli correlati vengono sviluppati ed evolvono, e vengono aggiunti nuovi requisiti da parte di applicazioni e protocolli. Favorire l'evoluzione del protocollo è quindi una considerazione progettuale importante per lo sviluppo di qualsiasi protocollo.

Per i protocolli che utilizzeranno CBOR, CBOR fornisce alcuni meccanismi utili per favorire la loro evoluzione. Le migliori pratiche in questo ambito sono ben note, in particolare dallo sviluppo del formato JSON per i protocolli basati su JSON. Pertanto, tali migliori pratiche esulano dallo scopo di questa specifica.

Tuttavia, favorire l'evoluzione di CBOR stesso rientra pienamente nel suo scopo. CBOR è progettato sia per fornire una base stabile per lo sviluppo di protocolli basati su CBOR, sia per poter evolvere.

Poiché un protocollo di successo può vivere per decenni, CBOR deve essere progettato per decenni di utilizzo ed evoluzione. Questa sezione fornisce alcune indicazioni per l'evoluzione di CBOR. È necessariamente più soggettiva rispetto ad altre parti di questo documento. È anche necessariamente incompleta, per non trasformarsi in un manuale di sviluppo dei protocolli.

5.1. Punti di estensione

Nella progettazione di un protocollo, le opportunità di evoluzione sono spesso incluse sotto forma di punti di estensione. Ad esempio, può esserci uno spazio di codepoint non interamente allocato fin dall'inizio, e il protocollo è progettato per tollerare e accogliere implementazioni che iniziano a usare più codepoint di quelli inizialmente allocati.

Dimensionare lo spazio di codepoint può essere difficile, perché l'intervallo richiesto può essere difficile da prevedere. Si dovrebbe cercare di rendere lo spazio di codepoint abbastanza grande da poter essere riempito lentamente nel corso della vita prevista del protocollo.

CBOR ha tre punti di estensione principali:

• lo spazio "simple" (i valori nel tipo principale 7). Dei 24 valori efficienti (e 224 valori leggermente meno efficienti), solo un numero ridotto è stato allocato. Le implementazioni che ricevono un elemento dati simple sconosciuto possono essere in grado di elaborarlo come tale, dato che la struttura del valore è effettivamente semplice. Il registro IANA nella Sezione 7.1 è il modo appropriato per affrontare l'estensibilità di questo spazio di codepoint.

• lo spazio "tag" (i valori nel tipo principale 6). Anche in questo caso, solo una piccola parte dello spazio di codepoint è stata allocata, e lo spazio è abbondante (sebbene i numeri iniziali siano più efficienti di quelli successivi). Le implementazioni che ricevono un tag sconosciuto possono scegliere di ignorarlo semplicemente, oppure di elaborarlo come un tag sconosciuto che racchiude l'elemento dati seguente. Il registro IANA nella Sezione 7.2 è il modo appropriato per affrontare l'estensibilità di questo spazio di codepoint.

• lo spazio delle "additional information". Un'implementazione che riceve un valore di additional information sconosciuto non ha modo di continuare l'analisi, quindi allocare codepoint in questo spazio è un passo importante. Inoltre rimangono pochissimi codepoint.

5.2. Curatela dello spazio delle Additional Information

La mente umana è talvolta attratta dal riempire piccoli vuoti percepiti per rendere qualcosa ordinato. Ci aspettiamo che i vuoti rimanenti nello spazio di codepoint per i valori di additional information costituiscano un attrattore per nuove idee, semplicemente perché sono lì.

La presente specifica non gestisce lo spazio di codepoint delle additional information tramite un registro IANA. Al contrario, le allocazioni da questo spazio possono essere effettuate solo aggiornando questa specifica.

Per un valore di additional information n >= 24, la dimensione dei dati aggiuntivi è tipicamente di 2**(n-24) byte. Pertanto, i valori di additional information 28 e 29 dovrebbero essere considerati candidati per quantità a 128 bit e 256 bit, qualora si presentasse la necessità di aggiungerli al protocollo. Il valore di additional information 30 è quindi l'unico valore di additional information disponibile per l'allocazione generale, e dovrebbe esserci un'ottima ragione per allocarlo prima di assegnarlo tramite un aggiornamento di questo protocollo.