Appendice E. Confronto tra altri formati binari e gli obiettivi di progettazione di CBOR

La proposta di CBOR si inserisce in una storia dei formati binari lunga quanto la storia dei computer stessi. Diversi formati hanno avuto obiettivi diversi. Nella maggior parte dei casi, gli obiettivi del formato non sono mai stati dichiarati, sebbene possano talvolta essere dedotti dal contesto in cui il formato è stato utilizzato per la prima volta. Alcuni formati avevano l'intento di essere universalmente utilizzabili, sebbene la storia abbia dimostrato che nessun formato binario soddisfa le esigenze di tutti i protocolli e di tutte le applicazioni.

CBOR si differenzia da molti di questi formati perché parte da un insieme di obiettivi e tenta di soddisfare esattamente quelli. Questa sezione confronta alcuni delle decine di formati con gli obiettivi di CBOR, per aiutare il lettore a decidere se utilizzare CBOR o un formato diverso per un particolare protocollo o applicazione.

Si noti che la discussione qui presente non intende essere una critica ad alcun formato: per quanto ci è noto, nessun formato precedente a CBOR aveva l'intento di coprire gli obiettivi di CBOR con la priorità che abbiamo loro assegnato. Un breve riassunto degli obiettivi della Sezione 1.1 è:

1. codifica non ambigua della maggior parte dei formati dati comuni degli standard Internet

2. compattezza del codice per l'encoder o il decoder

3. nessuna descrizione di schema necessaria

4. serializzazione ragionevolmente compatta

5. applicabilità ad applicazioni vincolate e non vincolate

6. buona conversione da/verso JSON

7. estensibilità

E.1. ASN.1 DER, BER e PER

• [ASN.1] ha molte serializzazioni. Nella IETF, DER e BER sono le più comuni. L'output serializzato non è particolarmente compatto per molti elementi, e il codice necessario per decodificare elementi numerici può essere complesso su un dispositivo vincolato.

Pochi (se non nessuno) protocolli IETF hanno adottato una delle diverse varianti delle Packed Encoding Rules (PER). Le ragioni potrebbero essere molte, ma una che viene comunemente indicata è che PER fa uso dello schema anche per l'analisi della struttura superficiale del flusso di dati, richiedendo un supporto significativo da parte di strumenti. Esistono diverse versioni del linguaggio di schema ASN.1 in uso, il che ha anch'esso ostacolato l'adozione.

E.2. MessagePack

• [MessagePack] è un formato di serializzazione binario conciso e ampiamente implementato, simile in molte proprietà a CBOR, sebbene un po' meno regolare. Sebbene il modello dei dati possa essere utilizzato per rappresentare dati JSON, MessagePack è stato impiegato anche in molte applicazioni di remote procedure call (RPC) e per l'archiviazione a lungo termine dei dati.

MessagePack è stato sostanzialmente stabile da quando è stato pubblicato per la prima volta, intorno al 2011; non ha ancora avuto una transizione. L'evoluzione di MessagePack è ostacolata dall'imperativo di mantenere la completa compatibilità all'indietro con i dati archiviati esistenti, mentre solo pochi bytecode sono ancora disponibili per l'estensione. Richieste ripetute nel corso degli anni da parte della comunità degli utenti di MessagePack per separare nell'encoding le stringhe binarie da quelle di testo hanno recentemente portato a una proposta di estensione che lascerebbe i dati "raw" di MessagePack ambigui tra i loro usi per dati binari e dati di testo. Il meccanismo di estensione per MessagePack rimane poco chiaro.

E.3. BSON

• [BSON] è un formato di dati sviluppato per l'archiviazione di mappe simili a JSON (oggetti JSON) nel database MongoDB. La sua caratteristica distintiva principale è la capacità di aggiornamento sul posto, rinunciando a una rappresentazione compatta. BSON utilizza una rappresentazione con conteggio, tranne che per le chiavi delle mappe, che sono terminate da un byte nullo. Sebbene BSON possa essere utilizzato per la rappresentazione sul canale di oggetti simili a JSON, la sua specifica è dominata dai requisiti dell'applicazione di database ed è diventata alquanto barocca. Lo stato di come verranno implementate le estensioni di BSON rimane poco chiaro.

E.4. UBJSON

• [UBJSON] ha l'obiettivo di progettazione di rendere JSON più veloce e un po' più piccolo, utilizzando un formato binario limitato esattamente al modello di dati che JSON utilizza. Pertanto, non vi è espressamente alcuna intenzione di supportare, ad esempio, dati binari; è tuttavia presente un "high-precision number", espresso come stringa di caratteri nella sintassi JSON. UBJSON non è ottimizzato per la compattezza del codice, e la sua codifica del byte di tipo è ottimizzata per il riconoscimento umano e non per la rappresentazione compatta di tipi nativi come i piccoli interi. Sebbene UBJSON sia per lo più basato su conteggio, fornisce un valore riservato "unknown-length" per supportare lo streaming di array e mappe (oggetti JSON). All'interno di questi contenitori, UBJSON ha anche un tipo "Noop" per il padding.

E.5. MSDTP: RFC 713

Message Services Data Transmission (MSDTP) è un esempio molto precoce di formato di messaggio compatto; è descritto nel [RFC0713], scritto nel 1976. È incluso qui per il suo valore storico, non perché sia stato mai ampiamente utilizzato.

E.6. Concisione sul canale

Sebbene l'obiettivo di progettazione di CBOR della compattezza del codice per encoder e decoder abbia una priorità più alta rispetto al suo obiettivo di concisione sul canale, molte persone si concentrano sulla dimensione sul canale. La Tabella 6 mostra alcuni esempi di codifica per il semplice array annidato [1, [2, 3]]; dove una qualche forma di codifica a lunghezza indefinita è supportata dall'encoding, viene mostrato anche [_ 1, [2, 3]] (lunghezza indefinita sull'array esterno).

Formato	[1, [2, 3]]	[_ 1, [2, 3]]
RFC 713	c2 05 81 c2 02 82 83
ASN.1 BER	30 0b 02 01 01 30 06 02 01 02 02 01 03	30 80 02 01 01 30 06 02 01 02 02 01 03 00 00
MessagePack	92 01 92 02 03
BSON	22 00 00 00 10 30 00 01 00 00 00 04 31 00 13 00 00 00 10 30 00 02 00 00 00 10 31 00 03 00 00 00 00 00
UBJSON	61 02 42 01 61 02 42 02 42 03	61 ff 42 01 61 02 42 02 42 03 45
CBOR	82 01 82 02 03	9f 01 82 02 03 ff

Tabella 6: Esempi per diversi livelli di concisione