clarify server behavior for messages received with unsupported/unrecognized extensions

[LimeHat]

Current version of the spec does not explicitly define the behavior in cases when a server receives a request with an unsupported extension message.

• should the extension(s) be ignored (potentially leaving clients in the dark), or
• should the request be rejected?

cc @robshakir @karimra

[karimra]

AFAIU, unknown extensions should be ignored while requests with known extensions that are malformed or used in an inappropriate context should be rejected.

[LimeHat]

AFAIU, unknown extensions should be ignored while requests with known extensions that are malformed or used in an inappropriate context should be rejected.

I agree with that approach/interpretation.

[robshakir]

I agree with @karimra, this seems the right behaviour. I can propose a clarification in the specification.

We need to make sure that we are backwards and forwards compatible:

• clients may add new extensions that the server doesn't support -- if the client relies on such extension support, it seems like we should understand this out-of-band (although if there were sufficient demand we could add this to capabilities to allow clients to understand what the supported extensions are). this means that we need to accept extensions that are not understood by the server.
• the server may support extensions that the client doesn't implement, which in some cases could result in payload coming back to the client in *Response messages that it doesn't understand. to some extent, we could leave this open to clients as to how they should interpret unknown extensions that they didn't request -- but I think that for robustness we should just make it required that clients do not tear down RPCs based on unknown extensions (as this allows for servers to add new extensions that are -- for example -- adding additional metadata without the need for extension negotiation).

I agree that if you know about an extension and the contents are erroneous then this is something that can be defined on a per extension basis, and treating this as an error should be OK.

again, we're just channeling Postel here:

"Be liberal in what you accept, and conservative in what you send."

[robshakir]

Created #223