color management protocol: Assuming sRGB for untagged surfaces

Current version of the color-management protocol v1 says:

        By default, a surface does not have an associated image description
        nor a rendering intent. The handling of color on such surfaces is
        compositor implementation defined.

As I was saying in a comment (I opened this report as followup, as requested):

Couldn't we assume sRGB for a surface with no image description? "implementation defined" (in other words "undefined behavior") is not so nice, because it won't work well with legacy software which might not be updated. Typically if a software/toolkit just define "RGB" data (with no color space information, as what used to be the common usage… and to be fair, mostly still is for most software) and if some compositor decides that untagged surface is implicitly in the output's wp_image_description_v1, then we get saturated color on wide gamut displays.

Yet we know that when most software used to set RGB data, they meant sRGB (often without even knowing that's what they meant). sRGB is clearly the historical de-facto default. So what about just making this part of the protocol? This way, we get reasonable defaults and software which don't care as much about colors won't even have to do anything (i.e. they won't have to explicitly tag all their surfaces as sRGB).

You answered:

We discussed this already and while I agree that sRGB is a very good guess it's also true that a lot of "sRGB" content is viewed on wider color gamut screens and that results in expectations of more saturated colors. If you want to discuss this further please open an issue on my repo.

I don't really understand this answer. When do people expect that sRGB content be viewed as saturated? This is quite the contrary a common issue and probably one of the biggest search result which you'll find with people buying wide gamut displays then going on forums to complain that all their colors are over-saturated.