Internet Engineering Task Force (IETF) T. Bray, Ed. Request for Comments: 8259 Textuality Obsoletes: 7159 December 2017 Category: Standards Track ISSN: 2070-1721 Il formato di Interscambio Dati JSON (JavaScript Object Notation) Traduzione a cura di ComiSAT Brescia, Gen. 2019 (comisat@yahoo.it) Distribuita da .::http://www.rfc.altervista.org::. Sommario Il JSON (JavaScript Object Notation) e' un formato di interscambio dati leggero, basato su testo e indipendente dal linguaggio. Deriva dal Linguaggio di Programmazione Standard ECMAScript. JSON definisce un piccolo insieme di regole di formattazione per la rappresentazione portatile di dati strutturati. Il presente documento rimuove le incoerenze con altre specifiche di JSON, corregge errori della specifica ed offre una guida all' interoperabilita' basata sull'esperienza. Stato di Questo Documento Questo documento e' una Traccia di uno Standard Internet. Questo documento e' il prodotto dell'IETC (Internet Engineering Task Force). Esso rappresenta il consenso della comunita' IETF. Ha ricevuto una revisione pubblica e la pubblicazione e' stata approvata dall'IESG (Internet Engineering Steering Group). Ulteriori informazioni sugli Standard Internet sono disponibili nella Sezione 2 dell'RFC 7841. Informazioni sullo stato attuale di questo documento, eventuali errori e su come fornire feedback possono essere ottenute qui: https://www.rfc-editor.org/info/rfc8259. Bray Standards Track [Page 1] RFC 8259 JSON December 2017 Nota di Copyright Copyright (c) 2017 IETF Trust e le persone identificate come autori del documento. Tutti i diritti sono riservati. Questo documento e' soggetto al BCP 78 e alle disposizioni legali dell'accordo IETF relative ai Documenti IETF (https://trustee.ietf.org/license-info) in vigore alla data di pubblicazione del presente documento. Si prega di leggere attentamente questi documenti poiche' descrivono diritti e restrizioni relative a questo documento. Le parti di codice estratte da questo documento devono includere il testo della Licenza Semplificata BSD come descritto nella Sezione 4.e degli Accordi Legali e rilasciate senza garanzia come descrcitto nella Licenza Semplificata BSD. Il presente documento puo' contenere materiale di Documenti IETF o Collaborazioni IETF pubblicate o rese disponibili pubblicamente prima del 10 Novembre 2008. Coloro che controllano il copyright in alcuni di questi documenti potrebbero non vedersi garantito il diritto secondo gli Accordi IETF di consentire modifiche a tale materiali al di fuori del Processo di Standard IETF. Senza ricevere un adeguata licenza dai detentori del copyright di tale materiale, questo documento non potrebbe essere modificabile al di fuoci del Processo di Standard IETF ad esclusione del formato di pubblicazione come una RFC e la traduzione in altri linguaggi dall'inglese. Bray Standards Track [Page 2] RFC 8259 JSON December 2017 Tavola dei Contenuti 1. Introduzione . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Convenzioni Utilizzate in Questo Documento . . . . . . . 4 1.2. Specifica di JSON . . . . . . . . . . . . . . . . . . . . 4 1.3. Introduzione a Questa Revisione . . . . . . . . . . . . . 5 2. Grammatica JSON . . . . . . . . . . . . . . . . . . . . . . . 5 3. Valori . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 4. Oggetti . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 5. Array . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 6. Numeri . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 7. Stringhe . . . . . . . . . . . . . . . . . . . . . . . . . . 8 8. Considerazioni relative a Stringhe e Caratteri . . . . . . . 9 8.1. Codifica dei Caratteri . . . . . . . . . . . . . . . . . 9 8.2. Caratteri Unicode . . . . . . . . . . . . . . . . . . . . 10 8.3. Comparazione di Stringhe . . . . . . . . . . . . . . . . 10 9. Parser . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 10. Generatori . . . . . . . . . . . . . . . . . . . . . . . . . 10 11. Considerazioni IANA . . . . . . . . . . . . . . . . . . . . . 11 12. Considerazioni relative alla Sicurezza . . . . . . . . . . . 12 13. Esempi . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 14. Riferimenti . . . . . . . . . . . . . . . . . . . . . . . . . 14 14.1. Riferimenti Normativi . . . . . . . . . . . . . . . . . 14 14.2. Riferimenti Informativi . . . . . . . . . . . . . . . . 14 Appendice A. Modifiche dalla RFC 7159 . . . . . . . . . . . . . 16 Collaboratori . . . . . . . . . . . . . . . . . . . . . . . . . . 16 Indirizzo dell'Autore . . . . . . . . . . . . . . . . . . . . . . 16 1. Introduzione JSON (JavaScript Object Notation) e' un formato di testo per la serializzazione di dati strutturati. Deriva dagli oggetti di JavaScript, come definito nel Linguaggio di Programmazione Standard ECMAScript, Terza Edizione [ECMA-262]. JSON puo' rappresentare quattro tipi primitivi (stringhe, numeri, booleani e null) e due tipi strutturati (oggetti ed array). Una stringa e' una sequenza di zero o piu' caratteri Unicode [UNICODE]. Si tenga presente che questa affermazione fa riferimetno all'ultima versione di Unicode e non ad una specifica release. Non si prevede che future modifiche alla specifica Unicode possano avere impatto sulla sintassi di JSON. Un oggetto e' un insieme non ordinato di zero o piu' coppie nome/valore, dove nome e' una stringa e valore e' una stringa, un numero, un booleano, un oggetto, un array oppure null. Un array e' una sequenza non ordinata di zero o piu' valori. Bray Standards Track [Page 3] RFC 8259 JSON December 2017 I termini "oggetto" ed "array" provengono dalle convenzioni di JavaScript. L'obiettivo alla base della progettazione di JSON era che fosse minimale, portabile, testuale ed un sottoinsieme di JavaScript. 1.1. Convenzioni Utilizzate in Questo Documento Le parole chiave "DEVE", "NON DEVE", "RICHIESTO", "DOVRA'", "NON DOVRA'", "DOVREBBE", "NON DOVREBBE", "RACCOMANDATO", "NON RACCOMANDATO", "PUO'" e "FACOLTATIVO" in questo documento devono essere interpretate come descritto in BCP 14 [RFC2119] [RFC8174] quando, e solo quando, appaiono tutto in masciuolo come mostrato qui. Le regole grammaticale in questo documento devono essere interpretate come descritto in [RFC5234]. 1.2. Specifiche di JSON Questo documento sostituisce [RFC7159]. [RFC7159] rese obsoleta [RFC4627] la quale descrisse in origine JSON e registro' il tipo media "application/json". JSON e' anche descritto in [ECMA-404]. Il riferimento ad ECMA-404 nella frase sopra e' normativo, non inteso al fatto che gli implementatori debbano consultarlo per capire il presente documento bensi' per enfatizzare che non vi sono incongruenze nella definizione del termine "testo JSON" in qualsiasi sua specifica. Si noti, comunque, che ECMA-404 consente diverse pratiche che la presente specifica raccomanda di evitare ai fini della massima interoperabilita'. L'intento e' che la grammatica sia la medesima in entrambi i due documenti nonostante descrizioni diverse. Se vi sono differenze tra essi, ECMA e IETF lavoreranno insieme per aggiornare entrambi i documenti. Se viene trovato un errore in uno dei due documenti, il secondo dovrebbe verificare di non avere un errore analogo; se fosse, dovrebbe essere corretto ove possibile. Se un documento viene modificato in futuro, ECMA e IETF lavoreranno insieme per garantire che i due documenti rimangano allineati. Bray Standards Track [Page 4] RFC 8259 JSON December 2017 1.3. Introduzione a Questa Revisione Negli anni successivi alla pubblicazione dell'RFC 4627, JSON ha trovato un ampio utilizzo. Tale esperienza ha rilevato alcuni modelli che, sebbene consentiti dalla specifica, hanno causato problemi di interoperabilita'. Inoltre, e' stato segnalato un numero contenuto di errori relativi a RFC 4627 (vedasi Errata RFC ID 607 [Err607] e 3607 [Err3607]) e a RFC 7159 (vedasi Errata RFC ID 3915 [Err3915], 4264 [Err4264], 4336 [Err4336], e 4388 [Err4388]). L'obiettivo di questo documento e' di applicare le correzioni, rimuovere le incongruenze con altre specifiche di JSON ed evidenziare le pratiche che possono portare a problemi di interoperabilita'. 2. Grammatica JSON Un testo JSON e' una sequenza di elementi. L'insieme di elementi include sei caratteri strutturali, stringhe, numeri e tre nomi letterali. Un testo JSON e' un valore serializzato. Si tenga presente che alcune specifiche precedenti di JSON costringevano un testo JSON ad essere un oggetto od un array. Le implementazioni che, a richiesta di un testo JSON, generano solamente oggetti od array saranno interoperabili nel senso che qualsiasi implementazione accettera' tale testo come testo JSON conforme. testo-JSON = spazio valore spazio I sei caratteri strutturali sono: inizio-array = spazio %x5B spazio ; [ parentesi quadra sinistra inizio-oggetto = spazio %x7B spazio ; { parentesi graffa sinistra fine-array = spazio %x5D spazio ; ] parentesi quadra destra fine-oggetto = spazio %x7D spazio ; } parentesi graffa destra separatore-nome = spazio %x3A spazio ; : due punti separatore-valore = spazio %x2C spazio ; , virgola Bray Standards Track [Page 5] RFC 8259 JSON December 2017 Prima o dopo qualsiasi dei sei caratteri strutturali sono consentiti spazi bianchi privi di significato. spazio = *( %x20 / ; Spazio %x09 / ; Tab orizzontale %x0A / ; LF o NL %x0D ) ; CR 3. Valori Un valore JSON DEVE essere un oggetto, un array, un numero, una stringa oppure uno dei tre nomi letterali seguenti: false null true I nomi letterali DEVONO essere minuscoli. Nessun altro nome letterale e' concesso. valore = false / null / true / oggetto / array / numero / stringhe false = %x66.61.6c.73.65 ; false null = %x6e.75.6c.6c ; null true = %x74.72.75.65 ; true 4. Oggetti La struttura di un oggetto e' rappresentata da una coppia di parentesi graffe che racchiudono zero o piu' coppie (o membri) di nome/valore. Un nome e' una stringa. Il segno dei due punti va messo dopo ogni nome, per separare il nome dal valore. Una virgola separa un valore da un nome successivo. I nomi all'interno di un oggetto DOVREBBERO essere univoci. oggetto = inizio-oggetto [ membro *( separatore-di-valore membro ) ] fine-oggetto membro = stringa separatore-del-nome valore Un oggetto in cui i nomi sono tutti univoci e' interoperabile nel senso che tutte le implementazioni software che ricevono quell'oggetto concorderanno sulla mappatura dei valori dei nomi. Quando i nomi in un oggetto non sono univoci, il comportamento del software che riceve l'oggetto non e' prevedibile. Molte implementazioni riportano solamente l'ultima coppia nome/valore. Altre implementazioni riportano un errore Bray Standards Track [Page 6] RFC 8259 JSON December 2017 o sbagliano ad interpretare l'oggetto, altre ancora riportano tutte le coppie di nome/valore compresi i doppioni. Si e' osservato che le librerie di parsing JSON differiscono sul fatto se rendono o meno ordinati i membri dell'oggetto visibile alle chiamate software. Le implementazioni il cui comportamento non dipende dall'ordinamento dei membri saranno interoperabili nel senso che non saranno influenzate da queste differenze. 5. Array La struttura di un array e' rappresentata da parentesi quadre che racchiudono zero o piu' valori (od elementi). Gli elementi sono separati da una virola. array = inizio-array [ valore *( separatore-di-valore valore ) ] fine-array Non e' richiesto che i valori in un array debbano essere dello stesso tipo. 6. Numeri La rappresentazione dei numeri e' simile a quella utilizzata nella maggior parte dei linguaggi di programmazione. Un numero viene rappresentato in base 10 utilizzando i numeri decimali. Esso e' composto da una parte intera, che puo' essere preceduta da segno meno facoltativo, e che puo' essere seguita da una parte frazionale e/o una parte esponenziale. Non sono consentiti zero iniziali. Una parte frazionale e' un punto seguito da una o piu' cifre. Un parte esponenziale inizia con la lettera E maiuscola o minuscola, che puo' essere seguita da un segno piu' o meno. La E e il segno facoltativo sono seguiti da una o piu' cifre. I valori numerici che non possono essere rappresentati nella grammatica che segue (come un Infinito e un NaN) sono sono ammessi. numero = [ meno ] intero [ frazionale ] [ esponenziale ] punto. = %x2E ; . cifra1-9 = %x31-39 ; 1-9 e = %x65 / %x45 ; e E esponenziale = e [ meno- / piu+ ] 1*CIFRA frazionale = punto. 1*CIFRA Bray Standards Track [Page 7] RFC 8259 JSON December 2017 intero = zero / ( cidra1-9 *CIFRA ) meno- = %x2D ; - piu+ = %x2B ; + zero = %x30 ; 0 Questa specifica consente alle implementazioni di impostare dei limiti di range e precisione ai numeri accettati. Dal momento che i software che implementano i numeri a precisione doppia [IEEE754] sono generalmente disponibili ed ampiamente utilizzati, si puo' ottenere una buona interoperabilita' dalle implementazioni che non si aspettano precisione o range maggiori di quanto forniscono, nel senso che esse approssimeranno i numeri JSON all'interno della precisione attesa. Un numero JSON come 1E400 o 3.141592653589793238462643383279 potrebbe indicare potenziali problemi di interoperabilita' dal momento che suggerisce che il software che l'ha generato si aspetta che il software che lo riceve abbia capacita' numeriche di grandezza e precisione maggiori di quanto ampiamente disponibile. Si tenga presente che quando un software simile viene utilizzato, i numeri interi nel range [-(2**53)+1, (2**53)-1] sono interoperabili nel senso che le implementazioni concorderanno esattamente sui loro valori numerici. 7. Stringhe La rappresentazione delle stringhe e' analoga alle convenzioni utilizzate nei linguaggi di programmazione della famiglia C. Una stringa inizia e termina con le virgolette. Tra di esse possono essere inclusi tutti i caratteri Unicode ad eccezione dei caratteri che DEVONO essere utilizzati in sequenza di escape: virgolette, barra inversa (backslash, reverse solidus) e caratteri di controllo (da U+0000 a U+001F). Qualsiasi carattere puo' essere usato in sequenza di escape. Se il carattere fa parte del plane BMP (piano base multilingua) (da U+0000 a U+FFFF) esso puo' essere rappresentato come una sequenza di sei caratteri: una barra inversa seguita dalla lettera minuscola u seguita da quattro cifre esadecimali che codificano il punto del codice del carattere. Le lettere esadecimali da A ad F possono essere sia maiuscole che minuscole. Quindi, ad esempio, una stringa che contiene solamente un carattere di barra inversa puo' essere rappresentata come "\u005C". In alternativa, esistono delle rappresentazioni in sequenza di escape di due caratteri per alcuni caratteri popolari. Quindi, ad esempio, una stringa che contiene solamente una carattere di barra inversa puo' essere rappresentata in forma compatta come "\\". Bray Standards Track [Page 8] RFC 8259 JSON December 2017 Per una sequenza di escape di un carattere esteso che non fa parte del BMP, il carattere viene rappresentato da una sequenza di 12 caratteri che codifica una coppia surrogata di UTF-16. Ad esempio, una stringa che contiene solamente il carattere chiave di violino (U+1D11E) puo' essere rappresentato come "\uD834\uDD1E". stringa = virgolette *carattere virgolette carattere = senza escape / carattere di escape ( %x22 / ; " virgolette U+0022 %x5C / ; \ barra inversa U+005C %x2F / ; / barra U+002F %x62 / ; b backspace U+0008 %x66 / ; f FF U+000C %x6E / ; n LF U+000A %x72 / ; r CR U+000D %x74 / ; t tab U+0009 %x75 4HEXDIG ) ; uXXXX U+XXXX carattere di escape = %x5C ; \ virgolette = %x22 ; " caratteri senza escape = %x20-21 / %x23-5B / %x5D-10FFFF 8. Considerazioni relative alle Stringhe ed ai Caratteri 8.1. Codifica dei Caratteri Il testo JSON interscambiato tra sistemi che non sono parte di un ecosistema chiuso DEVONO essere codificati utilizzando UTF-8 [RFC3629]. La specifica precedente di JSON non richiedeva l'uso di UTF-8 per la trasmissione di testo JSON. Ad ogni modo, la stragrande maggioranza delle implementazioni software basate su JSON hanno scelto l'uso della codifica UTF-8 dal momento che e' l'unica codifica che garantisce interoperabilita'. Le implementazioni NON DEVONO aggiungere un marcatore di ordine di byte (U+FEFF) all'inizio di un testo JSON trasmesso in rete. Ai fini dell'interoperabilita', le implementazioni che elaborano testi JSON POSSONO ignorare la presenza di un marcatore di ordine di byte piuttosto che gestirlo come un errore. Bray Standards Track [Page 9] RFC 8259 JSON December 2017 8.2. Caratteri Unicode Quando tutte le stringhe rappresentate in un testo JSON sono composte interamente da caratteri Unicode [UNICODE] (anche se in sequenza di escape) il testo JSON e' interoperabile nel senso che tutte le implementazioni software che lo elaborano converranno sul contenuto dei nomi e dei valori stringa di oggetti ed array. Ad ogni modo, l'ABNF in questa specifica consente ai nomi dei membri e ai valori di tipo stringa di contenere sequenze di bit che non codificano caratteri Unicode; ad esempio, "\uDEAD" (un singolo elemento surrogato UTF-16). Sono stati rilevati casi, ad esempio, quando una libreria tronca una stringa UTF-16 senza controllare se l'azione divide una coppia surrogata. Il comportamento dei software che ricevono testo JSON contenenti tali valori non e' prevedibile; ad esempio, alcune implementazioin potrebbero ritornare valori diversi di lunghezza di una stringa oppure errori fatali di esecuzione. 8.3. Comparazione di Stringhe Sono solitamente richieste implementazioni software per verificare l'uguaglianza dei nomi dei membri di un oggetto. Le implementazioni che trasformano la rappresentazione testuale in sequenze di unita' di codice Unicode e poi eseguono la comparazione numerica, unita' di codice per unita' di codice, sono interoperabili nel senso che quelle implementazioni concorderanno in tutti i casi di uguaglianza o diseguaglianza di due stringhe. Ad esempio, le implementazioni che confrontano stringhe con caratteri in sequenza di escape non convertiti possono determinare erroneamente che "a\\b" e "a\u005Cb" siano differenti. 9. Parser Un parser JSON trasforma un testo JSON in altre rappresentazioni. Un parser JSON DEVE accettare qualsiasi testo conforme alla grammatica JSON. Un parser JSON PUO' accettare forme non-JSON od estensioni. Un'implementazione puo' impostare dei limiti sulla dimensione del testo che puo' accettare. Un'implementazione puo' impostare dei limiti sulla profondita' massima di annidamento. Un'implementazione puo' impostare dei limiti sui range e sulla precisione dei numeri. Un'implementazione puo' impostare dei limiti sulla lunghezza di una stringa e sui relativi caratteri contenuti. 10. Generatori Un generatore JSON produce testo JSON. Il testo risultante DEVE essere rigorosamente conforme alla grammatica JSON. Bray Standards Track [Page 10] RFC 8259 JSON December 2017 11. Considerazioni IANA Il tipo media per il testo JSON e' application/json. Nome del tipo: application Nome del sottotipo: json Parametri richiesti: n/a Parametri opzionali: n/a Considerazioni sulla codifica: binaria Considerazioni sulla sicurezza: vedasi RFC 8259, Sezione 12 Considerazioni sull'interoperabilita': descritte nella RFC 8259 Publlicazione della specifica: RFC 8259 Applicazioni che usano il tipo media: JSON viene utilizzato per l'interscambio dei dati tra applicazioni scritte nei seguenti linguaggi di programmazione: ActionScript, C, C#, Clojure, ColdFusion, Common Lisp, E, Erlang, Go, Java, JavaScript, Lua, Objective CAML, Perl, PHP, Python, Rebol, Ruby, Scala e Scheme. Altre informazioni: Numero(i) magico: n/a Estensione del file: .json Codice del tipo di file Macintosh: TEXT Persona & indirizzo email da contattare per ulteriori informazioni: IESG Utilizzo previsto: COMUNE Limiti di utilizzo: nessuno Autore: Douglas Crockford Revisore delle modifiche: IESG Bray Standards Track [Page 11] RFC 8259 JSON December 2017 Nota: Nessun parametro "charset" viene definito per questa registrazione. Aggiungerne uno non ha alcun effetto concreto per i destinatari conformi. 12. Considerazioni relative alla Sicurezza Con i linguaggi di scripting vi sono solitamente questioni relative alla sicurezza. JSON e' un sottoinsieme di JavaScript ma non contempla assegnazioni ed invocazioni. Dal momento che la sintassi di JSON e' presa in prestito da JavaScript, e' possiibile utilizzare la funzione "eval()" di quel linguaggio per elaborare ma maggior parte dei testi JSON (ma non tutti; alcuni caratteri come la LINEA DI SEPARAZIONE U+2028 e il SEPARATORE DI PARAGRAFO U+2029 sono legali in JSON ma non in JavaScript). Questo costituisce generalmente un rischio non accettabile ai fini della sicurezza, poiche' il testo potrebbe contenere codice eseguibile insieme alle dichiarazioni di dati. Le stesse considerazioni si applicano all'uso di funzioni analoghe ad eval() in qualsiasi altro linguaggio di programmazione nei quali il testo JSON e' conforme alla sintassi di quel linguaggio. 13. Esempi Questo e' un oggetto JSON: { "Immagine": { "Larghezza": 800, "Altezza": 600, "Titolo": "Vista dal quindicesimo piano", "Miniatura": { "Url": "http://www.example.com/image/481989943", "Altezza": 125, "Larghezza": 100 }, "Animated" : false, "IDs": [116, 943, 234, 38793] } } Il suo membro Immagine e' un oggetto il cui membro Miniatura e' un oggetto e il membro ID e' un array di numeri. Bray Standards Track [Page 12] RFC 8259 JSON December 2017 Questo e' un array JSON contenente due oggetti: [ { "precisione": "zip", "Latitudine": 37.7668, "Longitudine": -122.3959, "Indirizzo": "", "Citta": "SAN FRANCISCO", "Stato": "CA", "CAP": "94107", "Stato": "US" }, { "precisione": "zip", "Latitudine": 37.371991, "Longitudine": -122.026020, "Indirizzo": "", "Citta": "SUNNYVALE", "Stato": "CA", "CAP": "94085", "Stato": "US" } ] A seguire vi sono tre brevi testi JSON contenenti solo valori: "Ciao mondo!" 42 true Bray Standards Track [Page 13] RFC 8259 JSON December 2017 14. Riferimenti 14.1. Riferimenti normativi [ECMA-404] Ecma International, "The JSON Data Interchange Format", Standard ECMA-404, . [IEEE754] IEEE, "IEEE Standard for Floating-Point Arithmetic", IEEE 754. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO 10646", STD 63, RFC 3629, DOI 10.17487/RFC3629, November 2003, . [RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", STD 68, RFC 5234, DOI 10.17487/RFC5234, January 2008, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . [UNICODE] The Unicode Consortium, "The Unicode Standard", . 14.2. Riferimenti informativi [ECMA-262] Ecma International, "ECMAScript Language Specification", Standard ECMA-262, Third Edition, December 1999, . [Err3607] RFC Errata, Erratum ID 3607, RFC 4627, . [Err3915] RFC Errata, Erratum ID 3915, RFC 7159, . Bray Standards Track [Page 14] RFC 8259 JSON December 2017 [Err4264] RFC Errata, Erratum ID 4264, RFC 7159, . [Err4336] RFC Errata, Erratum ID 4336, RFC 7159, . [Err4388] RFC Errata, Erratum ID 4388, RFC 7159, . [Err607] RFC Errata, Erratum ID 607, RFC 4627, . [RFC4627] Crockford, D., "The application/json Media Type for JavaScript Object Notation (JSON)", RFC 4627, DOI 10.17487/RFC4627, July 2006, . [RFC7159] Bray, T., Ed., "The JavaScript Object Notation (JSON) Data Interchange Format", RFC 7159, DOI 10.17487/RFC7159, March 2014, . Bray Standards Track [Page 15] RFC 8259 JSON December 2017 Appendice A. Modofiche dalla RFC 7159 Questa sezione elenca le modifiche tra questo documento e quanto contenuto nella RFC 7159. o La Sezione 1.2 e' stata aggiornata per riportare la rimozione di una specifica JSON da ECMA-262, per fare un riferimento normativo alla ECMA-404 e per spiegare il significato particolare di "normativo". o La Sezione 1.3 e' stata aggiornata per riportare gli errori rilevati nella RFC 7159, non nella RFC 4627. o La Sezione 8.1 e' stata modificata per richiedere l'uso di UTF-8 quando si trasmette in rete. o La Sezione 12 e' stata aggiornata per incrementare la precisione della descrizione del rischio di sicurezza che deriva dall'uso della funzione ECMAScript "eval()". o La Sezione 14.1 e' stata aggiornata per includere ECMA-404 come riferimento normativo. o La Sezione 14.2 e' stata aggiornata per rimuovere ECMA-404, aggiornare la versione di ECMA-262 e la lista degli errori. Collaboratori L'RFC 4627 e' stata scritta da Douglas Crockford. Questo documento e' stato costruito apportando un numero relativamente contenuto di modifiche a quella specifica; la maggior parte del testi qui contenuto e' pertanto di quel documento. Indirizzo dell'Autore Tim Bray (editor) Textuality Email: tbray@textuality.com Bray Standards Track [Page 16]