Appendix B. Deployment Considerations for the 'charset' Parameter
B.1. User Agents
User agents not implementing 'charset' will continue to work as before, ignoring the new parameter.
User agents that already default to the UTF-8 encoding implement 'charset' by definition.
Other user agents can keep their default behavior and switch to UTF-8 when seeing the new parameter.
B.2. Servers
Servers that do not support non-US-ASCII characters in credentials do not require any changes to support 'charset'.
Servers that need to support non-US-ASCII characters, but cannot use the UTF-8 character encoding scheme will not be affected; they will continue to function as well or as badly as before.
Finally, servers that need to support non-US-ASCII characters and can use the UTF-8 character encoding scheme can opt in by specifying the 'charset' parameter in the authentication challenge. Clients that do understand the 'charset' parameter will then start to use UTF-8, while other clients will continue to send credentials in their default encoding, broken credentials, or no credentials at all. Until all clients are upgraded to support UTF-8, servers are likely to see both UTF-8 and "legacy" encodings in requests. When processing as UTF-8 fails (due to a failure to decode as UTF-8 or a mismatch of user-id/password), a server might try a fallback to the previously supported legacy encoding in order to accommodate these legacy clients. Note that implicit retries need to be done carefully; for instance, some subsystems might detect repeated login failures and treat them as a potential credentials-guessing attack.
B.3. Why not simply switch the default encoding to UTF-8?
There are sites in use today that default to a local character encoding scheme, such as ISO-8859-1 ([ISO-8859-1]), and expect user agents to use that encoding. Authentication on these sites will stop working if the user agent switches to a different encoding, such as UTF-8.
Note that sites might even inspect the User-Agent header field ([RFC7231], Section 5.5.3) to decide which character encoding scheme to expect from the client. Therefore, they might support UTF-8 for some user agents, but default to something else for others. User agents in the latter group will have to continue to do what they do today until the majority of these servers have been upgraded to always use UTF-8.