Appendix A. Frequently Asked Questions (Foire aux questions)
A.1 Why Not JSON? (Pourquoi pas JSON?)
Les premières propositions de champs structurés étaient basées sur JSON [RFC8259]. Cependant, contraindre son utilisation pour l'adapter aux champs d'en-tête HTTP nécessitait que les expéditeurs et les destinataires implémentent un traitement supplémentaire spécifique.
Problèmes avec JSON
1. Problèmes de canonisation
- Grands nombres (dépassent la plage sûre de JavaScript)
- Objets avec membres en double (comportement non défini)
2. Chaînes Unicode
- Problèmes potentiels d'interopérabilité dans les comparaisons
- Différentes représentations Unicode pour le même caractère
3. Profondeur de imbrication arbitraire
- Engagements mémoire inappropriés
- Nécessité de limiter d'une manière ou d'une autre
- Les implémentations JSON existantes n'ont pas de telles limites
4. Tentation d'implémentation
- Difficile d'imposer des contraintes supplémentaires
- Les gens ont tendance à utiliser des parseurs JSON sur des valeurs de champ
Conclusion
Ces préoccupations ont conduit à l'adoption d'un format nécessitant des parseurs et sérialiseurs dédiés, car l'objectif principal était d'améliorer l'interopérabilité et de simplifier l'implémentation.
Tableau comparatif
| Fonctionnalité | JSON | RFC 8941 |
|---|---|---|
| Plage numérique | Indéfinie | Clairement définie (15 chiffres) |
| Précision décimale | Indéfinie | 3 chiffres |
| Unicode | Par défaut | ASCII uniquement |
| Profondeur | Illimitée | Limitée à 2 niveaux |
| Clés en double | Non défini | Explicitement interdit |
| Adaptation HTTP | Mauvaise | Excellente |
Exemple pratique
Approche JSON (problématique)
Example-Header: {"priority": 1, "timeout": 3.14159, "enabled": true}
Approche RFC 8941 (recommandée)
Example-Header: priority=1, timeout=3.142, enabled
Avantages: Définition de type claire, comportement prévisible, s'adapte naturellement à HTTP.