Hmm, but if we lean on HTTP then does that not mean that we have no standard for stdio servers? We can introduce that later, but then we need to have two ways to do i18n.

@pja-ant I both agree but

• STDIO servers can be directly configured, so a config convention could emerge without requiring a spec change
• we already did this for auth where we lean into HTTP ... I kind of thought that was setting the precedent for leaning into the http transport for what it already has more generally - one of the key drivers for choosing it, it's very mature.

Personally I could go either way on this, but it feels like we should be careful about reinventing the wheel. I wouldn't be against also adding this to the initialize payload for other transports lacking the envelope that http offers. I'm not sure that should prevent this being available now though, we are literally about to go the other direction with the http spec where we are replaying payload values as http headers, so values being both in the payload and in headers will become the standard soon I expect.

It seems like we should try to minimize the gaps between transports as much as possible. Is there a reason we couldn't put this as a field in _meta and mirror it to the header like we're doing for some other values?

@kurtisvg no, except that the mirroring proposal isn't baked in yet, but do you agree that the http model is likely the sensible i18n communication/resolution mechanism to copy? I feel like it makes sense to at least lift and shift it, rather than come up with something else.

@kurtisvg no, except that the mirroring proposal isn't baked in yet, but do you agree that the http model is likely the sensible i18n communication/resolution mechanism to copy? I feel like it makes sense to at least lift and shift it, rather than come up with something else.

Yes, I'm +1 to reusing over reinventing (unless we have a good rationale why)