Passa al contenuto principale

1.1. Objectives (Obiettivi)

1.1. Objectives (Obiettivi)

Gli obiettivi di CBOR, approssimativamente in ordine decrescente di importanza, sono:

  1. La rappresentazione deve essere in grado di codificare senza ambiguità la maggior parte dei formati di dati comuni utilizzati negli standard Internet.

    • Deve rappresentare un insieme ragionevole di tipi di dati e strutture di base utilizzando la codifica binaria. "Ragionevole" qui è in gran parte influenzato dalle capacità di JSON, con l'aggiunta principale di stringhe di byte binari. Le strutture supportate sono limitate ad array e alberi; i loop e i grafi in stile reticolare non sono supportati.

    • Non vi è alcun requisito che tutti i formati di dati siano codificati in modo univoco; cioè, è accettabile che il numero "7" possa essere codificato in più modi diversi.

  2. Il codice per un encoder o decoder deve poter essere compatto per supportare sistemi con memoria, potenza del processore e set di istruzioni molto limitati.

    • Un encoder e un decoder devono essere implementabili con una quantità molto piccola di codice (ad esempio, nei nodi vincolati di classe 1 come definito in [CNN-TERMS]).

    • Il formato dovrebbe utilizzare rappresentazioni di dati macchina contemporanee (ad esempio, non richiedendo la conversione da binario a decimale).

  3. I dati devono poter essere decodificati senza una descrizione dello schema.

    • Simile a JSON, i dati codificati dovrebbero essere auto-descrittivi in modo che possa essere scritto un decoder generico.
  4. La serializzazione deve essere ragionevolmente compatta, ma la compattezza dei dati è secondaria rispetto alla compattezza del codice per l'encoder e il decoder.

    • "Ragionevole" qui è limitato da JSON come limite superiore nelle dimensioni e dalla complessità di implementazione che mantiene un limite inferiore. L'uso di schemi di compressione generali o di manipolazione estensiva dei bit viola gli obiettivi di complessità.
  5. Il formato deve essere applicabile sia ai nodi vincolati che alle applicazioni ad alto volume.

    • Ciò significa che deve essere ragionevolmente parsimonioso nell'uso della CPU sia per la codifica che per la decodifica. Questo è rilevante sia per i nodi vincolati che per un potenziale utilizzo in applicazioni con un volume di dati molto elevato.
  6. Il formato deve supportare tutti i tipi di dati JSON per la conversione da e verso JSON.

    • Deve supportare un livello ragionevole di conversione fintanto che i dati rappresentati rientrano nelle capacità di JSON. Deve essere possibile definire una mappatura unidirezionale verso JSON per tutti i tipi di dati.
  7. Il formato deve essere estensibile e i dati estesi devono essere decodificabili da decoder precedenti.

    • Il formato è progettato per decenni di utilizzo.

    • Il formato deve supportare una forma di estensibilità che consenta il fallback in modo che un decoder che non comprende un'estensione possa comunque decodificare il messaggio.

    • Il formato deve poter essere esteso in futuro da standard IETF successivi.