tl;dr: Chrome will start accepting TAB characters as separators in some headers. You almost certainly don't need to do anything.
Chrome currently uses the Draft 15 structured headers parsing code for:
(For Trust tokens, it also parses Signed-Headers, Sec-Redemption-Record and Sec-Signature, but only from internally generated data -- they are request, not response headers -- or in unit tests)
There were very few changes between the Draft 15 and the final RFC; the only actual substantive change appears to be that a tab character is now accepted as a separator between top-level list and dictionary items, whereas before that character would have caused the parser to reject the header. (There was an additional change regarding the support for asterisks starting certain fields, but we had already implemented that.)
This is technically a web-visible change, though an extremely minor fix to bring everything in line with specs (none of the specs or code ever explicitly depended on Draft 15; the expected behaviour should be in line with the RFC) The impact seems tiny, and only positive (this shouldn't break anything; nothing should have been relying on this quirk, and HTTPArchive analysis seems to support that.)