| --- This message came from the IEEE 802.11 Task Group M Technical Reflector ---
>> some instances seem to be pretty clear on talking about a single ANQP-element instead of full set of elements
I agree with this. The issue is not shall vs should, it’s about clarifying what a “request” means in this context, since the required/recommended behavior for a request/response of a particular ANQP element is different to the required/recommended behavior for a request/response of multiple elements in the aggregate.
Best Thomas
--- This message came from the IEEE 802.11 Task Group M Technical Reflector ---I think I'd be OK with shall ignore -> should ignore. Thanks, Mark -- Mark RISON, Standards Architect, WLAN English/Esperanto/Français Samsung Cambridge Solution Centre Tel: +44 1223 434600 Innovation Park, Cambridge CB4 0DS Fax: +44 1223 434601 --- This message came from the IEEE 802.11 Task Group M Technical Reflector --- following the discussion about the ANQP CID 1618 on the TGme call yesterday, I wanted to check the proposed resolution with Jouni, as he was not on the call and has been involved in some implementations of these messages. Jouni mentioned that it's ok for me to forward his email to the mailing list. Thanks. That wording is ambiguous since "ANQP request/response" is not really clearly defined and it is used in two different contexts: reference to either the full frame containing potentially multiple ANQP-elements (11.22.3.3.1: "The ANQP request consists of one or more ANQP elements") or a single ANQP-element (may other locations, often a bit more vague, but some instances seem to be pretty clear on talking about a single ANQP-element instead of full set of elements). This "shall ignore" rule need to be clearly written to be evaluated separately for each ANQP-element received in the response (i.e., use other received ANQP-elements and only ignore the unrecognized one). I'm not convinced there would need to be a similar rule for the request. It should also be noted that "shall ignore" is problematic here if "ignore" were to be interpreted more like "silently discard", i.e., take no action based on it. There might be other recognized subfields or values in the same ANQP-element and those could still be used. And for the case of an AP reporting that it does not have some data, the information about the AP not having that data could still be used. IMHO, the proposed language looks worse than the current state of uncertainty.. I do agree that there would be room for improvement in this area, but this one does not result in net gain. It would be better to address the specific known issues on case-by-case basis rather than trying to come up with some generic shall statement that is way too easy to result in issues for some existing use cases. - Jouni regarding the following CID 1618 from Mark Rison (clause: 11.22.3.3.1): REVmd WG CC Comments ANQP-elements with fields with some reserved values need to define the behaviour on receiving such values, since they can be sent without prior capability negotiation. Typically this will involve ignoring the field in question and any other fields associated with them | After the 2nd para add a para "A STA shall unless specified otherwise ignore an ANQP request or response that contains non-reserved field/subfield values that are not known to it." |
We decided to accept this on the TGme call today. Are you ok with this? Thanks.
To unsubscribe from the STDS-802-11-TGM list, click the following link: https://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-11-TGM&A=1
To unsubscribe from the STDS-802-11-TGM list, click the following link: https://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-11-TGM&A=1
To unsubscribe from the STDS-802-11-TGM list, click the following link: https://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-11-TGM&A=1
|