Thread Links | Date Links | ||||
---|---|---|---|---|---|
Thread Prev | Thread Next | Thread Index | Date Prev | Date Next | Date Index |
--- This message came from the IEEE 802.11 Working Group Reflector ---
I think an additional point is that although one can make the argument that while it might sometimes be harmless to include a "spurious" element, this then makes the "optionally present" statements confusing.
To pick one at random, in Beacon frames: The Quiet element is optionally present if
dot11SpectrumManagementRequired is true or
dot11RadioMeasurementActivated is true. … but if the Quiet element can also be present if neither of these MIB attributes is true, then why are they mentioned?
Just say it is optionally present full stop. 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 ROYAUME UNI WWW:
http://www.samsung.com/uk From: Mark Hamilton <mark.hamilton2152@xxxxxxxxx>
--- This message came from the IEEE 802.11 Working Group Reflector ---
All, REVme is looking for feedback on current implementation behavior/assumptions on a wide-ranging technical
point: REVme is discussing a comment on D1.0 (CID 1622) that requests, in effect, to add a statement to clause
9 that wherever we currently have a requirement such as “the xxx element is present if condition
yyy is true”, then there is an implicit _requirement_ (to be made explicit by this comment) that if “condition
yyy” is not true then “xxx” is _not_ present. Specifically, the added sentence(s) would be: “If an element is indicated as present when certain conditions are met, this is to be understood as meaning that the element is not included if these conditions
are not met.” Some considerations, and where we would like feedback:
-
In many places in the current spec, we explicitly say “and not present otherwise” (or something similar)
-
However, there are also many places in the spec where this is not stated.
o
Some of these unstated locations can be read as implying or only making sense if we take this to mean “is not included if these conditions
are not met”
o
Other places are not clear. In those places, are there implementations that may include the element, as an “allowed extension” (since
it is not currently prohibited), and thus those implementations would become non-compliant if add this sentence?
o
Or, in those places, is the general assumption and implementation practice already to not include the element, so adding the statement
above would be a proper clarification of existing interpretation? Feedback to this reflector, or to the
REVme reflector, is appreciated. Thanks! Mark To unsubscribe from the STDS-802-11 list, click the following link:
https://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-11&A=1 To unsubscribe from the STDS-802-11 list, click the following link: https://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-11&A=1 |