2. Conventions utilisées dans ce document
Les mots-clés « MUST » (doit), « MUST NOT » (ne doit pas), « REQUIRED » (requis), « SHALL » (doit), « SHALL NOT » (ne doit pas), « SHOULD » (devrait), « SHOULD NOT » (ne devrait pas), « RECOMMENDED » (recommandé), « MAY » (peut) et « OPTIONAL » (optionnel) de ce document doivent être interprétés comme décrit dans [RFC 2119].
Interprétation des mots-clés RFC 2119
Selon RFC 2119, ces mots-clés ont les significations spécifiques suivantes dans cette spécification :
Exigences obligatoires
| Mot-clé | Signification | Exemple |
|---|---|---|
| MUST | Exigence absolue | L'implémentation doit inclure le caractère de remplissage |
| MUST NOT | Interdiction absolue | L'implémentation ne doit pas ajouter de sauts de ligne |
| REQUIRED | Identique à MUST | La prise en charge de l'alphabet standard est requise |
| SHALL | Identique à MUST | Le décodeur doit rejeter les caractères illégaux |
| SHALL NOT | Identique à MUST NOT | L'encodeur ne doit pas utiliser de caractères non standard |
Recommandations
| Mot-clé | Signification | Exemple |
|---|---|---|
| SHOULD | Fortement recommandé, exceptions possibles | L'implémentation devrait valider le remplissage |
| SHOULD NOT | Fortement déconseillé, exceptions possibles | L'implémentation ne devrait pas ignorer les erreurs |
| RECOMMENDED | Identique à SHOULD | L'alphabet sûr pour les URL est recommandé |
Optionnalité
| Mot-clé | Signification | Exemple |
|---|---|---|
| MAY | Vraiment optionnel | L'implémentation peut prendre en charge le mode sans remplissage |
| OPTIONAL | Identique à MAY | La prise en charge des sauts de ligne est optionnelle |
Application dans les spécifications d'encodage de base
Utilisation de MUST
Exemple 1 : exigence de remplissage
"L'implémentation doit inclure le caractère de
remplissage approprié à la fin des données encodées."
Conséquence en cas de violation : ❌ échec de décodage, corruption des données
Exemple 2 : traitement des caractères illégaux
"Si les données encodées contiennent des caractères
hors de l'alphabet de base, l'implémentation doit rejeter ces données."
Conséquence en cas de violation : ❌ vulnérabilité de sécurité, corruption des données
Utilisation de SHOULD
Exemple : rapport d'erreur
"En cas d'échec de décodage, l'implémentation devrait
fournir un message d'erreur clair."
Cas où la non-conformité est acceptable :
- Systèmes embarqués aux ressources limitées
- Scénarios où les performances sont critiques
Utilisation de MAY
Exemple : fonctionnalité optionnelle
"L'implémentation peut prendre en charge le décodage
de données ne contenant pas de caractère de remplissage."
Signification : il s'agit d'une fonctionnalité vraiment optionnelle ;
l'implémentation peut décider de la prendre en charge ou non.
Guide d'application pratique
Pour les implémenteurs
Priorité de conformité :
1. MUST/MUST NOT/REQUIRED/SHALL/SHALL NOT
→ à respecter strictement, sinon non conforme
2. SHOULD/SHOULD NOT/RECOMMENDED
→ fortement recommandé, sauf raison valable
3. MAY/OPTIONAL
→ décider en fonction des besoins
Pour les testeurs
Points clés de test :
✅ Vérifier toutes les exigences MUST
✅ Contrôler l'implémentation des recommandations SHOULD
⚠️ Documenter la prise en charge des fonctionnalités MAY
Pour les utilisateurs
Lors du choix d'une implémentation :
1. S'assurer que l'implémentation satisfait toutes les exigences MUST
2. Privilégier les implémentations respectant les recommandations SHOULD
3. Choisir les fonctionnalités MAY selon les besoins
Malentendus courants
❌ Compréhension erronée
Malentendu 1 : « SHOULD peut être ignoré »
✗ Erreur : SHOULD est une simple suggestion, ignorable librement
✓ Correct : SHOULD est fortement recommandé, ne s'écarte que pour juste raison
Malentendu 2 : « MAY n'est qu'une fonctionnalité optionnelle »
✗ Erreur : les fonctionnalités MAY ne sont pas importantes
✓ Correct : les fonctionnalités MAY sont optionnelles, mais si implémentées doivent être correctes
Malentendu 3 : « MUST n'est qu'une suggestion »
✗ Erreur : MUST peut parfois être ignoré
✓ Correct : MUST est une exigence absolue, à respecter strictement
Aperçu des exigences clés de cette spécification
Dans les sections suivantes, vous rencontrerez les exigences clés suivantes :
Section 3.1 :
"L'implémentation ne doit pas ajouter de sauts de ligne aux données
encodées en base, sauf si la spécification de référence l'exige explicitement…"
Section 3.2 :
"L'implémentation doit inclure le caractère de remplissage
approprié à la fin des données encodées…"
Section 3.3 :
"Si les données encodées contiennent des caractères hors
de l'alphabet de base, l'implémentation doit les rejeter…"
Ces exigences utilisent MUST, ce qui indique qu'elles sont absolument obligatoires et doivent être respectées par toutes les implémentations conformes.
Références
- RFC 2119 - Mots-clés indiquant les niveaux d'exigence dans les RFC
- RFC 8174 - Ambiguïté des majuscules/minuscules des mots-clés RFC 2119 (version mise à jour)