Subject: Editorial Issue: Unknown/Undefined Settings IDs

From: James M Snell <[email-masked]>
Date: Fri, 26 Apr 2013 13:47:56 -0700

We currently define Settings as being extensible but we do not define,
as far as I can tell, what should happen if a Settings ID is not known
or recognized by an endpoint.

We could define it as MUST IGNORE but that could be dangerous
depending on what the new setting is being used for.

---

From: Martin Thomson <[email-masked]>
Date: Fri, 26 Apr 2013 13:52:29 -0700

See earlier response.  If you want something other than "MUST ignore"
it's possible to negotiate a different protocol.

An alternative is to add a flag to settings that mark them as "MUST understand".

---

From: James M Snell <[email-masked]>
Date: Fri, 26 Apr 2013 13:58:20 -0700

>> or recognized by an endpoint.

Agreed, but it needs to be expressed this way. Specifically, all
implementations are required to support the settings defined in the
core spec, but must ignore any unknown or unrecognized settings that
appear in the SETTINGS frame. Extensions that define new Settings IDs
MUST NOT do so in a way that requires an implementation to understand
in order to successfully communicate over the session.

>> depending on what the new setting is being used for.

Possible yes.. but bleh! Let's not go there unless it becomes
blatantly obvious that we have to.

- James