Annexe B. Considérations de déploiement pour le paramètre 'charset'
B.1. Agents utilisateurs
Les agents utilisateurs n'implémentant pas 'charset' continueront à fonctionner comme avant, en ignorant le nouveau paramètre.
Les agents utilisateurs qui utilisent déjà UTF-8 par défaut implémentent 'charset' par définition.
Les autres agents utilisateurs peuvent conserver leur comportement par défaut et passer à UTF-8 lorsqu'ils voient le nouveau paramètre.
B.2. Serveurs
Les serveurs qui ne prennent pas en charge les caractères non US-ASCII dans les informations d'identification ne nécessitent aucun changement pour prendre en charge 'charset'.
Les serveurs qui doivent prendre en charge les caractères non US-ASCII, mais ne peuvent pas utiliser le schéma d'encodage de caractères UTF-8 ne seront pas affectés; ils continueront à fonctionner aussi bien ou aussi mal qu'avant.
Enfin, les serveurs qui doivent prendre en charge les caractères non US-ASCII et peuvent utiliser le schéma d'encodage de caractères UTF-8 peuvent choisir d'activer cette fonctionnalité en spécifiant le paramètre 'charset' dans le challenge d'authentification. Les clients qui comprennent le paramètre 'charset' commenceront alors à utiliser UTF-8, tandis que les autres clients continueront à envoyer des informations d'identification dans leur encodage par défaut, des informations d'identification cassées, ou aucune information d'identification du tout. Jusqu'à ce que tous les clients soient mis à niveau pour prendre en charge UTF-8, les serveurs sont susceptibles de voir à la fois UTF-8 et des encodages "legacy" dans les demandes. Lorsque le traitement en UTF-8 échoue (en raison d'un échec de décodage en UTF-8 ou d'une non-correspondance user-id/mot de passe), un serveur peut essayer un repli vers l'encodage legacy précédemment pris en charge afin d'accommoder ces clients legacy. Notez que les nouvelles tentatives implicites doivent être effectuées avec précaution; par exemple, certains sous-systèmes peuvent détecter des échecs de connexion répétés et les traiter comme une attaque potentielle de devinette d'informations d'identification.
B.3. Pourquoi ne pas simplement changer l'encodage par défaut en UTF-8?
Il existe aujourd'hui des sites en utilisation qui utilisent par défaut un schéma d'encodage de caractères local, tel que ISO-8859-1 ([ISO-8859-1]), et s'attendent à ce que les agents utilisateurs utilisent cet encodage. L'authentification sur ces sites cessera de fonctionner si l'agent utilisateur passe à un encodage différent, tel que UTF-8.
Notez que les sites peuvent même inspecter le champ d'en-tête User-Agent ([RFC7231], section 5.5.3) pour décider quel schéma d'encodage de caractères attendre du client. Par conséquent, ils peuvent prendre en charge UTF-8 pour certains agents utilisateurs, mais utiliser par défaut autre chose pour d'autres. Les agents utilisateurs dans ce dernier groupe devront continuer à faire ce qu'ils font aujourd'hui jusqu'à ce que la majorité de ces serveurs aient été mis à niveau pour toujours utiliser UTF-8.