Updating a SXG via validity-url forces content negotiation on servers

Section 3.6, 'Updating Signature Validity', says:

If the the update map is present, that indicates that a new version of the signed exchange is available at its effective request URI (Section 5.5 of [RFC7230]) and can give an estimate of the size of the updated exchange (update.size). If the signed exchange is currently the most recent version, the update SHOULD NOT be present.

Consider a set-up where main.html is the actual resource of interest, and main.html.sxg is a signed exchange containing main.html (and hence main.html.sxg has an effective request URI of main.html). main.html can have a Link header pointing to main.html.sxg with rel=alternate and type=application/signed-exchange to allow clients to discover the signed exchange. Each of the representations is addressable and there's no need for content negotiation, which is often a big simplification in operation.

However, if the server operator wants to use the update field of the validity URL's resource to signal that clients can download a new version of the signed exchange, the spec's current text forces that to be made available at main.html. This would force the server into content negotiation because main.html is now a name for both the direct representation and the signed exchange.

If, alternatively, the spec said to try re-downloading the signed exchange from wherever it was originally found, using content-addressing for the SXG would fail: they'll just download the old version again or run into a 410.

I think that the spec would be better if it just dropped the 'at its effective request URI', and let clients look for the new SXG however they want to: the best thing would be to use the same mechanism to discover the updated SXG as they used to discover the SXG originally, but they could try content negotiation at the effective request URI if they think it's a good idea or if it's the best option they have (e.g., if the SXG wasn't discovered and actively pulled, but rather pushed to them out of band). It might be worth having a SHOULD here noting the pitfalls.

Start with Section 3.6, “Updating Signature Validity,” and review the validity URL, update field, effective request URI, and original SXG discovery mechanism described in the issue. The specification text should clearly define how clients discover an updated signed exchange without requiring content negotiation at the effective request URI, while preserving a workable fallback for exchanges obtained out of band.