I've written ten RFCs of varying quality. It's terribly difficult to write something that a) gives a good overview of the subject, b) explains the choices that had to be made, c) spells out every detail, and d) remains short enough that implementers actually read all of it. All of mine fail in some way. I've heard the OSI documents failed too.
Quoting one implementer, whose code did not accept non-ASCII passwords: "Oh, the password syntax is on page 88? My printout ends after page 68". In that RFC, the details are spelt out in appendices, and Appendix A starts on page 69. (And I'm sure pg assigns bonus karma if you can identify the RFC.)
You can submit an erratum and an author will comment and often clarify, so formally speaking the answer to your question is yes. But other implementers don't generally read the errata, so you have to expect that your interoperation peers haven't read the clarification.
Once you understand the problem, the clarification, and that your interop peers do not, I bet your implementation's handling of the issue will be conservative in what it sends and liberal in what it receives.
Quoting one implementer, whose code did not accept non-ASCII passwords: "Oh, the password syntax is on page 88? My printout ends after page 68". In that RFC, the details are spelt out in appendices, and Appendix A starts on page 69. (And I'm sure pg assigns bonus karma if you can identify the RFC.)