{"action":"created","issue":{"url":"https://api.github.com/repos/tavendo/WAMP/issues/159","labels_url":"https://api.github.com/repos/tavendo/WAMP/issues/159/labels{/name}","comments_url":"https://api.github.com/repos/tavendo/WAMP/issues/159/comments","events_url":"https://api.github.com/repos/tavendo/WAMP/issues/159/events","html_url":"https://github.com/tavendo/WAMP/issues/159","id":67403795,"number":159,"title":"Unclear behavior for unsupported announced features","user":{"login":"ecorm","id":9258548,"avatar_url":"https://avatars.githubusercontent.com/u/9258548?v=3","gravatar_id":"","url":"https://api.github.com/users/ecorm","html_url":"https://github.com/ecorm","followers_url":"https://api.github.com/users/ecorm/followers","following_url":"https://api.github.com/users/ecorm/following{/other_user}","gists_url":"https://api.github.com/users/ecorm/gists{/gist_id}","starred_url":"https://api.github.com/users/ecorm/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/ecorm/subscriptions","organizations_url":"https://api.github.com/users/ecorm/orgs","repos_url":"https://api.github.com/users/ecorm/repos","events_url":"https://api.github.com/users/ecorm/events{/privacy}","received_events_url":"https://api.github.com/users/ecorm/received_events","type":"User","site_admin":false},"labels":[{"url":"https://api.github.com/repos/tavendo/WAMP/labels/WAMPv2%20Basic%20Profile","name":"WAMPv2 Basic Profile","color":"d7e102"}],"state":"open","locked":false,"assignee":null,"milestone":null,"comments":5,"created_at":"2015-04-09T16:51:14Z","updated_at":"2015-04-09T22:13:56Z","closed_at":null,"body":"_(Issue imported from this Google Groups [thread](https://groups.google.com/forum/#!topic/wampws/1B2JE0UeE9Y))_\r\n\r\nThe spec is not clear about what should happen when a client **announces** a feature that is not supported on the router, and vice-versa.\r\n\r\nFor example, if my client library announces that it supports `subscriber_blackwhite_listing`, but the router does not support it, should the router send an `ABORT` message during session establishment?\r\n\r\nIf the answer to the above is that the router should ignore that unsupported feature and proceed with session establishment as normal, then what should happen when the client attempts to use the `subscriber_blackwhite_listing` feature during a `PUBLISH` message?\r\n\r\nHere's another scenario. Suppose that my client library supports `subscriber_blackwhite_listing`, but the user of my library has no intention of using that feature in his or her app. Should the `subscriber_blackwhite_listing` still be listed in `HELLO.Details.roles.publisher.features` in the `HELLO` message?"},"comment":{"url":"https://api.github.com/repos/tavendo/WAMP/issues/comments/91369371","html_url":"https://github.com/tavendo/WAMP/issues/159#issuecomment-91369371","issue_url":"https://api.github.com/repos/tavendo/WAMP/issues/159","id":91369371,"user":{"login":"ecorm","id":9258548,"avatar_url":"https://avatars.githubusercontent.com/u/9258548?v=3","gravatar_id":"","url":"https://api.github.com/users/ecorm","html_url":"https://github.com/ecorm","followers_url":"https://api.github.com/users/ecorm/followers","following_url":"https://api.github.com/users/ecorm/following{/other_user}","gists_url":"https://api.github.com/users/ecorm/gists{/gist_id}","starred_url":"https://api.github.com/users/ecorm/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/ecorm/subscriptions","organizations_url":"https://api.github.com/users/ecorm/orgs","repos_url":"https://api.github.com/users/ecorm/repos","events_url":"https://api.github.com/users/ecorm/events{/privacy}","received_events_url":"https://api.github.com/users/ecorm/received_events","type":"User","site_admin":false},"created_at":"2015-04-09T22:13:56Z","updated_at":"2015-04-09T22:13:56Z","body":"I know it would be tedious, but I think we should analyze the use of unsupported features on a case-by-case basis. If it's possible to generalize the behavior for most cases (and specify only a few exceptions), that would be great.\r\n\r\nI propose that someone draft a table of all stable (and semi-stable) features, and for each feature enumerate:\r\n- Its feature URI\r\n- _Misuse_ cases where a peer attempts to use an unsupported feature\r\n- All the reasonable course of actions that could be taken upon receiving an message having an unsupported attribute\r\n\r\nI might draft such a table sometime this weekend. Once its all laid out in front of us, we should be able to see patterns emerge and establish some general rules regarding behavior."}}