Appendix A. Frequently Asked Questions (Häufig gestellte Fragen)
A.1 Why Not JSON? (Warum nicht JSON?)
Frühe Vorschläge für strukturierte Felder basierten auf JSON [RFC8259]. Die Einschränkung seiner Verwendung zur Anpassung an HTTP-Header-Felder erforderte jedoch, dass Sender und Empfänger eine spezifische zusätzliche Verarbeitung implementieren.
Probleme mit JSON
1. Kanonisierungsprobleme
- Große Zahlen (überschreiten JavaScripts sicheren Bereich)
- Objekte mit doppelten Mitgliedern (Verhalten undefiniert)
2. Unicode-Strings
- Potenzielle Interoperabilitätsprobleme bei Vergleichen
- Verschiedene Unicode-Darstellungen für dasselbe Zeichen
3. Beliebige Verschachtelungstiefe
- Unangemessene Speicherverpflichtungen
- Muss irgendwie begrenzt werden
- Vorhandene JSON-Implementierungen haben keine solchen Grenzen
4. Implementierungsversuchung
- Schwierig, zusätzliche Einschränkungen durchzusetzen
- Menschen neigen dazu, JSON-Parser auf Feldwerten zu verwenden
Fazit
Diese Bedenken führten zur Annahme eines Formats, das dedizierte Parser und Serialisierer erfordert, da das Hauptziel darin bestand, Interoperabilität zu verbessern und Implementierung zu vereinfachen.
Vergleichstabelle
| Merkmal | JSON | RFC 8941 |
|---|---|---|
| Zahlenbereich | Undefiniert | Klar definiert (15 Ziffern) |
| Dezimalpräzision | Undefiniert | 3 Ziffern |
| Unicode | Standard | Nur ASCII |
| Tiefe | Unbegrenzt | Auf 2 Ebenen begrenzt |
| Doppelte Schlüssel | Undefiniert | Explizit verboten |
| HTTP-Anpassung | Schlecht | Ausgezeichnet |
Praktisches Beispiel
JSON-Ansatz (problematisch)
Example-Header: {"priority": 1, "timeout": 3.14159, "enabled": true}
RFC 8941-Ansatz (empfohlen)
Example-Header: priority=1, timeout=3.142, enabled
Vorteile: Klare Typdefinition, vorhersagbares Verhalten, passt natürlich zu HTTP.