Pitch(Foundation): String Encoding Names

[Karl]

@xwu

Perhaps I'm misunderstanding what @Karl is saying, but my read is that he buys the rationale for having legacy encoding support in Foundation, but thinks that library shouldn't offer a way to initialize them based on WHATWG name-to-encoding mappings because:

My feeling is that compatibility with the web platform may be more of a niche requirement that is better served by a package

...to which my question was: to which other platform or use case would the legacy encodings be less of a niche requirement? Since we cannot seem to name any use cases between us, isn't it the case (by construction) that the Web platform isn't "more" niche?

So, yes - legacy encodings are useful, even if we don't have any name parsing.

I find it difficult to parse the rest of your question. Anything that processes legacy text would, of course, benefit from support for legacy text encodings; but many of those don't need the web-compatible names, and in fact the proposal includes an example of when using the web-compatible name would be incorrect (XML documents).

And by the way, I'm not saying it isn't worth adding. I just think it's interesting and that we should consider to what extent we want Foundation APIs to formally reflect standards designed for the web.

[itingliu]

@Karl

I just think it's interesting and that we should consider to what extent we want Foundation APIs to formally reflect standards designed for the web.

I agree the extent to which Foundation should reflect standards is still an open question. But we do continue to add new API to support particular standards. For example the calendar recurrence rule was designed to work with RFC 5545
The HTTP date format was also designed so it works specifically for HTTP.