| Thread Links | Date Links | ||||
|---|---|---|---|---|---|
| Thread Prev | Thread Next | Thread Index | Date Prev | Date Next | Date Index |
| --- This message came from the IEEE 802.11 Task Group M Technical Reflector ---
Hi, Jon, I can give you my opinions, to kick things off, perhaps: Question 1: Why is "self-protected action frame" not "self-protected Action Frame" like "robust Action frame"? or " protected dual of public action frame" not " protected dual of public Action frame" MAH: I believe we have a general convention that words that are being defined are in all lower case (except the acronyms, which are also spelled out and their constituent words are in lower case). The examples that we are finding where there are some upper case words sprinkled in (like “robust Action frame”) look like an error to me. I’ll note that there are many named frame types referenced in 3.2, and it looks like the majority are lower case – I don’t think there is, or should be, anything special about Action frames in this regard. Question 2: Why is the use of these defined frame names in 3.2 upper cased in some instances in the text in later clauses and in some cases in the definition of the frame name itself? MAH: This seems like a generalization of the same question above. As stated, I think the use of upper case words in frame names in 3.2 is incorrect. Question 3: Why on p244 L 58 does it use TDLS Setup Request frame and TDLS Discovery Request frame? The “S” in TDLS is “setup”. However, in 3.2 there is no definition for TDLS Setup Request frame. MAH: I think there are two questions here. Why does it use “TDLS Setup Request frame”? A: Because that’s the name of the frame. I agree, the “S” in TDLS is “setup”, but nonetheless, that’s what the frame is named. Perhaps there is wider (and more philosophical?) question of why did the frame get named that way, and/or should we fix it? I can’t answer either of those, although it’s probably too late to fix it. The second question is about no definition for TDLS Setup Request frame in 3.2. A: There are many frame types that are not defined in 3.2. They are all defined in Clause 9, of course. I’m actually not sure why _any_ frame names/types would be defined in 3.2, in retrospect. There are definitely many such definitions where the term is “special” and not just a frame type from the Clause 9 tables, and those probably make sense in 3.2. For example, EAPOL-Key frame (which is not defined by us in 802.11), or “mesh Data frame” [sic – capitalization 😊] which is not a defined frame type, but a particular usage scenario of the Data frame. But, others I think are probably a waste of space in 3.2, such as “non-high-throughput duplicate frame” – isn’t that pretty self-evident, without the definition? Mark From: Jon Rosdahl <jrosdahl@xxxxxxxx> --- This message came from the IEEE 802.11 Task Group M Technical Reflector --- Greetings, I have a few questions on this CID that Emily is taking to the Editors for more discussion: From the Minutes: 1.1 CID 1630 (ED1) 1.1.1 Review Comment 1.1.2 Context: 1.1.2.1 protected dual of public action frame: An Action frame with the category value specified in 9.4.1.11 (Action field) (Table 9-79 (Category values)). For each Protected Dual of Public Action frame, there is a dual Action frame in a category that is specified with No in the Robust column of Table 9-79 (Category values). 1.1.3 Note the capitalization of “Protected Dual of Public Action frame” is used in the description but not in the name of the definition. 1.1.4 Examples of Frame Names: 1.1.4.1 directional multi-gigabit (DMG) frame 1.1.4.2 concealed groupcast with retries (GCR) frame 1.1.4.3 broadcast wake-up radio (WUR) wake-up frame 1.1.4.4 directed frame 1.1.4.5 group addressed quality-of-service management frame (GQMF): 1.1.4.6 group addressed wake-up radio (WUR) wake-up frame: 1.1.4.7 groupcast with retries (GCR) frame: 1.1.4.8 groupcast with retries (GCR) service period (GCR-SP) frame: 1.1.4.9 individually addressed quality-of-service management frame (IQMF): 1.1.4.10nonaggregate medium access control (MAC) protocol data unit (non-A-MPDU) frame: 1.1.4.11nonconcealed groupcast with retries (GCR) frame: 1.1.4.12non-high-throughput (non-HT) duplicate frame: 1.1.4.13non-quality-of-service management frame (non-QMF) access point (AP): 1.1.4.14non-space-time-block-coding (non-STBC) frame: 1.1.4.15peer trigger frame: 1.1.4.16protected dual of public action frame: 1.1.4.17protected frame: 1.1.4.18quality-of-service (QoS) frame: 1.1.4.19quality-of-service management frame (QMF): 1.1.4.20self-protected action frame: 1.1.4.21space-time block coding (STBC) frame: 1.1.4.22trigger frame: 1.1.4.23triggering frame: 1.1.4.24tunneled direct-link setup (TDLS) frame (TDLS frame): 1.1.5 Examples of Frame Names where some capitalizing is occurring: 1.1.5.1 mesh Data frame: 1.1.5.2 EAPOL-Key frame: 1.1.5.3 EAPOL-Key request frame: 1.1.5.4 EAPOL-Start frame: 1.1.5.5 robust Action frame: 1.1.5.6 robust Management frame: 1.1.5.7 time priority Management frame: 1.1.6 More work will be done – Will discuss in Editors Group. Question 1: Why is "self-protected action frame" not "self-protected Action Frame" like "robust Action frame"? or " protected dual of public action frame" not " protected dual of public Action frame" Question 2: Why is the use of these defined frame names in 3.2 upper cased in some instances in the text in later clauses and in some cases in the definition of the frame name itself? Question 3: Why on p244 L 58 does it use TDLS Setup Request frame and TDLS Discovery Request frame? The "S" in TDLS is "setup". However, in 3.2 there is no definition for TDLS Setup Request frame. These questions make me say "mmm" What do you think? Jon ----------------------------------------------------------------------------- Jon Rosdahl Engineer, Senior Staff
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 |