Doc.: IEEE 802.11-17/14120
IEEE P802.11Wireless LANsMAC Comments for Discussion Date: 2018-08-1Author(s):NameAffiliationAddressPhoneemailMark HamiltonRuckus/ARRIS350 W Java DrSunnyvale, CA 94089+1.303.818.8472mark.hamtilon2152@168910206375AbstractThis submission contains comments on REVmd LB 232, assigned to Mark Hamilton for preparation of proposed resolutions.The first section contains comments with proposed resolutions ready for review or discussion by TGmd. The latter sections are comments not ready for discussion yet, or already completed.R0 – initial version. CIDs ready for TGmd review: 1398, 1425, 1381, 1382, 1390.R1 – Reviewed CIDs 1398, 1425, 1381, 1382, 1390 at FLL F2F, and approved resolutions, with minor modifications (as shown below, with Green highlight status color). Added proposed resolutions, ready for review, for CIDs: 1394, 1369, 1397, and 1354.R2 – Reviewed CIDs 1394, 1369, 1397, and 1354 at Warsaw F2F, and approved resolutions (as shown below, with Green highlight status color). R3 – CIDs ready for TGmd review: 1281, 1400, 1401, 1403, 1405, 1414, 1008, 1282, 1018, 1033, 1114, 1305R4 – Reviewed CIDs 1281, 1400, 1401, 1403, 1405, 1414, 1008, 1282, 1018, 1033, 1114, 1305. All have approved resolutions.R5 – Proposed resolutions/discussion on CIDs 1286, 1338, 1343, and 1349.R6 – Reviewed CIDs 1338 and 1343 at Waikoloa F2F and approved resolutions. Expanded Editor’s instructions for deprecating dot11GDDEnablementValidityTimer in the resolution to CID 1349. (Thanks to Emily QI for these instructions.) Proposed resolutions for CIDs 1273, 1569, 1415, 1536, and 1485.R7 – TGm reviewed the updated CID 1349, and CIDs 1273, 1536, and 1485, and approved the resolutions as captured here. CID 1569 was considered, but more expert review is needed.00AbstractThis submission contains comments on REVmd LB 232, assigned to Mark Hamilton for preparation of proposed resolutions.The first section contains comments with proposed resolutions ready for review or discussion by TGmd. The latter sections are comments not ready for discussion yet, or already completed.R0 – initial version. CIDs ready for TGmd review: 1398, 1425, 1381, 1382, 1390.R1 – Reviewed CIDs 1398, 1425, 1381, 1382, 1390 at FLL F2F, and approved resolutions, with minor modifications (as shown below, with Green highlight status color). Added proposed resolutions, ready for review, for CIDs: 1394, 1369, 1397, and 1354.R2 – Reviewed CIDs 1394, 1369, 1397, and 1354 at Warsaw F2F, and approved resolutions (as shown below, with Green highlight status color). R3 – CIDs ready for TGmd review: 1281, 1400, 1401, 1403, 1405, 1414, 1008, 1282, 1018, 1033, 1114, 1305R4 – Reviewed CIDs 1281, 1400, 1401, 1403, 1405, 1414, 1008, 1282, 1018, 1033, 1114, 1305. All have approved resolutions.R5 – Proposed resolutions/discussion on CIDs 1286, 1338, 1343, and 1349.R6 – Reviewed CIDs 1338 and 1343 at Waikoloa F2F and approved resolutions. Expanded Editor’s instructions for deprecating dot11GDDEnablementValidityTimer in the resolution to CID 1349. (Thanks to Emily QI for these instructions.) Proposed resolutions for CIDs 1273, 1569, 1415, 1536, and 1485.R7 – TGm reviewed the updated CID 1349, and CIDs 1273, 1536, and 1485, and approved the resolutions as captured here. CID 1569 was considered, but more expert review is needed.For review by TG:1286842.18189.4.1.8IEEE Std 802.11-2016 modified the definition of AID field to say "A non-DMG STA assigns the value of the AID in the range of 1 to 2007; the 5 MSBs of the AID field are reserved" while the 802.11-2012 definition said "The value assigned as the AID is in the range 1-2007 and is placed in the 14 LSBs of the AID field, with the two MSBs of the AID field set to 1". This changes behavior in a backwards incompatible manner due to the general convention (see 9.2.2): "Reserved fields and subfields are set to 0 upon transmission and are ignored upon reception.". In other words, this change would imply that the two MSBs are set to 0 instead 1. This results in interoperability issues with deployed devices in particular with (Re)Association Response frames where a non-AP STA may either reject the frame if the two MSBs of the AID are not 1 or there might be undefined behavior when matching the received value against the value used in PS-Poll frames. This type of "cleanup" change is not acceptable and needs to be reverted to avoid interoperability issues with deployed devices. This comment is proposing a change for the 802.11-2012 case. A similar change could be considered for DMG and S1G cases as well, if those are expected to have interoperability issues. Alternatively, the AID field definition could be left as-is and the specific uses of AID field in the relevant frames (at least (Re)Association Response frames) could be specified to set the two MSBs to 1.Replace "A non-DMG and non-S1G STA assigns the value of the AID in the range of 1 to 2007; the 5 MSBs of the AID field are reserved."with"A non-DMG and non-S1G STA assigns the value of the AID in the range of 1 to 2007. This value is placed in the 14 LSBs of the AID field, with the two MSBs of the AID field set to 1."Discussion:Context:From 802.11-2012:So, the behavior of this subclause has in fact changed.Note from the current text, and the -2012 text, that the AID itself is a small(ish) integer, and does have these high bits set to 1. This is also necessary for the text describing a TIM bitfield to make sense. This is further supported by text in 9.2.4.2:“In Control frames of subtype PS-Poll other than PS-Poll+BDT frames,(11ah) the Duration/ID field carries the association identifier (AID) of the STA that transmitted the frame in the 14 least significant bits (LSB), and the 2 most significant bits (MSB) both set to 1.(M53)”So, clearly the upper bits being set is a matter of frame formatting, probably in early usage as a way to disambiguate the Duration/ID field of every frame. Such setting of upper bits in any other context is probably a carry-over and unneccesary. But, as the commenter points out, we can’t change these now without breaking backward compatibility.The proposed change would align with the -2012 approach of specifying the two MSBs are set to one explicitly in the AID field (and not in the AID itself), and therefore in all frames that include the AID field: (Re)Assocation ResponseMesh Peeting ConfirmAID Response element in (Re)Association Response and AID Switch Response framesAID Announcement element in a STA Information Annoucement frameRelay Search Request frameAID element in TDLS Setup Request and TDLS Setup Response framesAND MAYBE?:RLS Request frame, RLS Announcement frame, RLS Teardown frame – the format of AIDs in these frames is unclear.Need expert opinion on whether all these frames should have the two MSBs set to 1.Also, see CID 1588 (already resolved) which makes these changes:Change the two sentences about mesh AIDs to, "In mesh BSS operation, the AID field is a value that represents the 16-bit ID of a neighbor peer mesh STA, assigned during mesh peering." Change “A non-DMG and non-S1G STA assigns the value of the AID in the range of 1 to 2007; the 5 MSBs of the AID field are reserved. An S1G STA assigns the value of the AID in the range of 1 to 8191; the 3 MSBs of the AID field are reserved. A DMG STA assigns the value of the AID field in the range 1 to 254. The value 255 is reserved as the broadcast AID, and the value 0 corresponds to the AP or PCP. The 8 MSBs of the AID field are reserved.”To :“The value of the AID field for a non-DMG and non-S1G STA is in the range of 1 to 2007, and the 5 MSBs of the AID field are reserved. The value of the AID field for an S1G STA is in the range of 1 to 8191, and the 3 MSBs of the AID field are reserved. The value of the AID field for A DMG STA is in the range 1 to 254. The value 255 is reserved as the broadcast AID, and the value 0 corresponds to the AP or PCP. The 8 MSBs of the AID field are reserved.”Proposed Resolution:15691236.30309.4.2.146What is "A/C power"? Is PoE sufficient? Battery backup?Change "A/C Power" in the Figure to "Mains power", and in the descriptive text to "Mains or grid power".Discussion:Context:This field is in the Relay Capability Information field of the Relay Capabilities element (for DMG Relays):A Google search (definitive research ?) comes back with the suggestion that one meant “AC Power” (so we should at the very least, delete the “/”), meaning specifically alternating current.Presumably, the point of this capability being indicated over 802.11 is to let other devices know that this is not a battery powered device, but has a (logically infinite) external power source. This doesn’t seem related to that power being alternating current or not.The “see also” hints in Wikipedia for “AC Power” suggest that if one means utility-supplied AC power (which seems close to what we mean), use the entry titled “Mains electricity”. That page suggests that for regions that don’t commonly call it “mains”, they call it “grid power”, “wall power” or “domestic power”.The commenter’s Proposed Change seems to align with, and capture, these same terms.Proposed Resolution:Revised.Change to “The A/C Power subfield indicates whether the STA is using AC power. It is set to 1 if the STA is supplied by AC power, including PoE, wall plug, etc.; otherwise, it is set to 0.”Change to “The A/C Power subfield indicates whether the STA is capable of using AC power. It is set to 1 if the STA is capable of being supplied by AC power, including PoE, wall plug, etc.; otherwise, it is set to 0.”Original: The A/C Power subfield indicates whether the STA is capable of obtaining AC power. It is set to 1 if the STA is capable of being supplied by AC power; otherwise, it is set to 0.”1415743.0339.2.4.5.4The way the ack policy is referred to is confusing/inconsistent. Do you refer to the options indicated by the bit pattern (e.g. "Normal Ack or Implicit Block Ack Request") or do you refer to only the type of ack being requested in the context being requested (e.g. just "Implicit Block Ack Request" in the case of an A-MPDU)?Change "The Ack Policy subfield is 2 bits in length and identifies the acknowledgment policy that is followed upon the delivery of the MPDU." to "The Ack Policy subfield is 2 bits in length and identifies, together with other information such as whether it is in the context of an S-MPDU and the value of bit 6 of the Frame Control field, the acknowledgment policy that is followed upon the delivery of the MPDU." at the referenced locationDiscussion:Context:The comment is correct that these two bits alone are not sufficient to identify the acknowledgement policy (as evidenced by the complex discussion in the Meaning column). It does seem to be correct that these two bits, combined with bit 6 of the Frame Control, and dependent on the context (for (0,0)).However, the context discussed is whether the frame containing these bits is an A-MPDU (not S-MPDU) and whether the two endpoints support fragment block acks.Editorially, the proposed change is a bit awkward with the subordinate clause (about this other information) being in the middle of the sentence.Proposed Resolution:Revised. At the referenced location, change "The Ack Policy subfield is 2 bits in length and identifies the acknowledgment policy that is followed upon the delivery of the MPDU." to "The Ack Policy subfield is 2 bits in length and identifies the acknowledgment policy that is followed upon the delivery of the MPDU, when the bit values are considered in combination with other information such as whether it is in the context of an A-MPDU, support for fragment BA procedure, and the value of bit 6 of the Frame Control field." Not ready for review, yet:15531953.525211.1.4.3.4A Probe Request frame may contain the DSS Parameter Set element regardless of whether the receiving STA has radio measurements activated. As such, the local value of dot11RadioMeasurementActivated should not be used as a condition for using this information when deciding whether to reply to a Probe Request frame.Replace "The STA has dot11RadioMeasurementActivated equal to true and the Probe Request frame contains a DSSS Parameter Set element" with "The Probe Request frame contains a DSSS Parameter Set element".15542014.181811.3.2Figure 11-15 has an extraneous State 5. (And editorial typo from an earlier draft of 802.11ai, perhaps.)Remove State 5 from Figure 11-15, restoring it to Figure 11-13 from the published 802.11ai-2016.15282014.181811.3.2There is no State 5Delete the State 5 box in Figure 11-15 and all arrows to/from it15601719.606010.25.5.3Data MPDU is rarely used. "Data frame" is overwhelmingly preferred.Change the remaining 5 "data MPDU"s to "data frame"s1526743.0339.2.4.5.4The way the ack policy is referred to is confusing/inconsistent. Do you refer to the options indicated by the bit pattern (e.g. "Normal Ack or Implicit Block Ack Request") or do you refer to only the type of ack being requested in the context being requested (e.g. just "Implicit Block Ack Request" in the case of an A-MPDU)?See 17/1243r615721360.26269.4.5.21Can the NAI Realm field have zero NAI Realm Tuple subfields? If so, what does the AoC element mean? Does the Plan Information have to have valid information including the XML description?Clarify if the NAI Realm field can be zero length or not, and if it can be, clarify (in 11.23.3.3.12) how the "information is provided on a per NAI realm basis" works.15732211.06611.23.3.3.12Consider having a default charge that applies if none of the NAI Realms in the Advice of Charge Duples matches.Add "Plan information for the special NAI realm "*" is indicated, if none of the explicit NAI realms are currently applicable."15861455.29299.6.13.1What is "WNM-Notify Response" in Table 9-396?Delete this row1593809.28289.3.3.9In Table 9-36 (the "Reassociation Response frame body"), Order 31 appears twice. Association Response (up about 5 pages) has the same problem, with Order 27.Renumber the tables with sequential Order1594726.0669.2.2Things are wrong with this sentence, "An ASCII or UTF-8 string a sequence of ASCII-encoded octets without a terminating null." First, there's no verb. Probably supposed to be "... string _is_ a sequence of ..." Secondly, how can an UTF-8 string be ASCII-encoded? The point of UTF-8 is to encode stuff ASCII can't do. (Yes, extended ASCII could arguably contain the octets of the UTF-8, but that is just confusing things.)Replace with, "An ASCII or UTF-8 string is a sequence of ASCII or UTF-8 encoded octets without a terminating null."16141286.60609.4.2.187Payload of each element is limited to a maximum of 254 or 255 octets. The should be limited to one single value. If it can be either or then clarify the condition for each.Fix as commented15571563.282810.2.1HCF doesn't really use DCF architecturally. It 'replaces' DCF.Change Figure 10-1 to show HCF (EDCA and HCCA) as directly using the PHY. Cleanup text in 10.2, 10.3 and 10.22 to not describe HCF as using DCF.15031670.101010.23.2.4The precedence of the actions on page 1670 is not clearAt 1670.14 and 1670.22 change "At each" to "Otherwise, at each"1442743.45459.2.4.5.4The terms "require acknowledgment" or "requires acknowledgment" are not clear, because some ack policies other than 00 do require ack, just not immediate (e.g. Block Ack, PSMP Ack, No Explicit Acknowledgment)Add "immediate" before "acknowledgement" in "require acknowledgement"/"requires acknowledgement" in 9.3.1.3 (2x), 10.3.2.10 at 1592.24 and 1594.47/51, 10.3.4.4, 10.3.4.5, 11.2.3.6 (4x), 14.14.9.2, G.3 (2x)14481535.51519.4.3"The preceding PPDU" is behaviour not formatMove from Clause 9 to Clause 1014492095.242411.10.9.6"Originator Requesting MAC address field" -- no such field (and bad case)Change all instances of "Originator Requesting MAC address" to "Originator Requesting STA MAC Address field" throughout the document1450835.50509.4.1.4"An AP sets the ESS subfield to 1 and the IBSS subfield to 0 within transmitted Beacon or Probe Responseframes. Otherwise, the ESS and IBSS subfields are reserved. An IBSS STA sets the ESS subfield to 0 andthe IBSS subfield to 1 in transmitted Beacon or Probe Response frames. A mesh STA sets the ESS and IBSSsubfields to 0 in transmitted Beacon or Probe Response frames." is either unclear as to the setting for non-AP non-mesh non-IBSS STAs, or self-contradictory for IBSS and mesh STAsChange the cited text to "An AP sets the ESS subfield to 1 and the IBSS subfield to 0 within transmitted Beacon or Probe Responseframes. An IBSS STA sets the ESS subfield to 0 andthe IBSS subfield to 1 in transmitted Beacon or Probe Response frames. A mesh STA sets the ESS and IBSSsubfields to 0 in transmitted Beacon or Probe Response frames. Otherwise, the ESS and IBSS subfields are reserved."14542019.525211.3.5It is not clear what is reset in the case of (re)association to a different APAt the end of the last step of 11.3.5.2 add "All states, agreements and allocations shall be deleted or reset to initial values."At the end of the last step of 11.3.5.3 add "All states, agreements and allocations pertaining to the STA that has associated shall be deleted or reset to initial values."At the end of the last step of 11.3.5.5, add "In the case of reassociation to a different AP, all states, agreements and allocations pertaining to the STA that has reassociated shall be deleted or reset to initial values."15321277.33339.4.2.179"0: Reserved, FILS Public Key is undefined." -- this can't be used, nor can any values above 3Delete the line at 1277.33 and at the end of the referenced subclause add "Other values are reserved."1500794.18189.3.3.2"All fields and elements are mandatory unless stated otherwise and appear in the specified, relative order,with gaps allowed." -- it is not clear what "with gaps allowed" means. It seems to suggest you can just put random filler between fields/elementsDelete ", with gaps allowed" in the cited text at the referenced location16201298.64649.4.2.194Note has normative text "can be set to".... Notes can only contain informative text.Extract the normative information in the paragraph on line 60.15042232.02211.26.3The (non-AP) PeerKey mechanism is obsolete, and the STKSA is not definedDelete "and STKSA" at 11.26.315092058.01111.5.4It is not clear what "corresponding to the TID for which the block ack policy is set" meansChange each of the three instances in the referenced subclause to "with the TID for the block ack agreement"15111644.202010.7"For MSDUs or A-MSDUs belonging to the service class of QoSAck when the receiveris a QoS STA, set to Normal Ack or Implicit Block Ack Request, PSMP Ack, or Block Ack." is missing some words (what is set?)Change the cited text in the referenced location to "For MSDUs or A-MSDUs belonging to the service class of QoSAck when the receiveris a QoS STA, the QoS Data framesthat are used to send these MSDUs or A-MSDUs shall have the Ack Policy subfield in the QoS Control field set to Normal Ack or Implicit Block Ack Request, PSMP Ack, or Block Ack."14629It is not necessary in Clause 9 to say things are done according to the conventions in 9.2.2. It is confusing to do so, because it implies something unusual is happeningDelete the sentences like "The order of theOrganization Identifier field is described in 9.2.2 (Conventions)." or "All fields use the bit convention from 9.2.2 (Conventions)." or " It is encoded following the conventions in 9.2.2(Conventions)." at [mc/D6.0 references] 685.46, 827.4, 828.41, 881.22, 881.26, 881.62, 882.43, 883.44, 999.59, 999.64, 1007.33, 1083.20, 1101.58, 1101.62, 1130.33, 1144.47. Delete the NOTE at 706.48. Change 880.20 to say "The MDID field contains an arbitrary value." At 951.39 delete ", encoded according to 9.2.2 (Conventions)". At 1085.14 delete " and is encoded following theconventions given in 9.2.2 (Conventions)"15191066.25259.4.2.36"Set to 4 for 80+80 MHz operating channel width" is not consistent with the other sentencesChange the cited text at the referenced location to "Set to 4 for 80+80 MHz BSS bandwidth"15201676.636310.23.2.8"Note that when transmitting multiple frames in a TXOP using acknowledgment mechanisms other thanNormal Ack," -- it is not clear what this means; it seems to be inadvertently omitting implicit BAChange the cited text at the referenced location to "Note that when transmitting multiple frames in a TXOP using acknowledgment mechanisms other than immediate acknowledgement,"1498There is no such thing as "DSSS/CCK mode"Change "DSSS/CCK Mode" (or "mode") to "DSSS/CCK PPDUs" in 9.4.2.55.2 (3x), 11.15.8 (4x), C.3 (1x). Change "dot11RMNeighborReportHTDSSCCKModein40MHz" to "dot11RMNeighborReportHTDSSCCKPPDUsin40MHz" in C.3 (3x)13961571.151510.2.6"A QoS Data frame with a TID matching an existing block ack agreement may be transmitted outside anA-MPDU with its Ack Policy subfield set to Normal Ack" -- also in an S-MPDUAppend ", or in an S-MPDU" to the cited text at the referenced location11461657.303010.19Please clarify how the PARTIAL_AID is calculated when the Multiple BSSID is used.For example, do BSSID[39:47], BSSID[44:47], and BSSID[40:43] are derived from a transmitted BSSID or a non-transmitted BSSID?802.11ah had the same discussion, the following sentence has been added into the spec.NOTE--When a STA for which dot11MultiBSSIDActivated is true is associated with ith BSSID of an AP, the BSSID means the value of BSSID(i).If VHT PPDU follows the same rule, please add the same NOTE into the spec.As in comment.13701964.606011.1.711.1.4.6 Operation of Supported Rates and BSS Membership Selectors element andExtended Supported Rates and BSS Membership Selectors element and 11.1.7 Supported rates and extended supported rates advertisement cover the same materialMerge 11.1.7 into 11.1.4.6 then delete 11.1.714312249.151511.31.1"the Capabilities element, the Operation element" -- there are no such elements. Discussions with 11ad experts suggests the intent is that you use all the elements relevant to the target band/PHYIn the referenced subclause change "A multi-band capable device shall include, in any transmitted FST Setup Request frame and in anytransmitted FST Setup Response frame, the Capabilities element, the Operation element, the EDCAParameter Set element, Supported Rates and BSS Membership Selectors element, Extended SupportedRates and BSS Membership Selectors element, and Supported Channels element that are applicable to theband and channel number indicated within its most recently transmitted Multi-band element that wastransmitted on the same band and channel number on which it is transmitting the FST Setup Request or FSTSetup Response frames." to "A multi-band capable device shall include, in any transmitted FST Setup Request frame and in anytransmitted FST Setup Response frame, all the elements that are applicable to theband, PHY and channel number indicated within its most recently transmitted Multi-band element that wastransmitted on the same band and channel number on which it is transmitting the FST Setup Request or FSTSetup Response frames."Completed:CIDPageLineClauseSubmissionCommentProposed Change13982281.101011.4"Notify Channel Width frames and elements are used to" -- no such elementDelete "and elements" in the cited text at the referenced locationDiscussion:The commenter is correct, there is no such element. Perhaps this meant to say “Notify Channel Width frames and the contained Channel Width field”? In any regard, it seems superfluous. Proposed Resolution:Revised. Replace the cited note with: “A Notify Channel Width frame or the STA Channel Width field in the HT Operation element is used to signal STA operating channel width changes to and from STAs that are not operating mode notification capable.”Editor: note that the clause number is 11.40.14251592.151510.3.2.10"A non-AP STA shall not transmit an Ack or BlockAck frame in response to a group addressed frame." -- an AP shouldn't ack group-addressed frames (i.e. RA = group) eitherDelete "non-AP" in the cited text at the referenced locationDiscussion:It seems, from the following NOTE, that the intention is that an AP should never receive a group addressed frame (only group addressed MSDUs in individually addressed frames), so the response rules for an AP are moot. Additionally, the filtering rules for Address 1 filtering should prevent an AP from passing any group addressed frame up the stack (to be acknowledged) as the dot11GroupAddressesTable should be null on an AP. From 10.2.7:All that said, it doesn’t hurt to state that this rule applies to APs also, and does simply the sentence.Proposed Resolution:Accepted.13812170.404011.22.7.1"A STAwhose dot11BSSTransitionActivated is true shall support BSS transition management and shall set to 1 theTransition field of the Extended Capabilities elements that it transmits" -- no such fieldIn the cited text at the referenced location change "Transition" to "BSS Transition"Discussion:Per the definition of the Extended Capabilites field:Bit 19 is in fact called “BSS Transition”.Proposed Resolution:Accepted.13822170.404011.22.7.1"A STAwhose dot11BSSTransitionActivated is true shall support BSS transition management and shall set to 1 theTransition field of the Extended Capabilities elements that it transmits" -- should also have implemented set to trueIn the cited text at the referenced location add "shall have dot11BSSTransitionImplemented set to true," after "is true"Discussion:While logically both do need to be true, also, logically, there is no way dot11BSSTransitionActivated could be true if the feature were not implemented, hence dot11BSSTransitionImplemented must be true without needing to state so.Proposed Resolution:Rejected. For dot11BSSTransitionActivated to be true, logically, dot11BSSTransitionImplemented must also be true without needing to state so.13901063.46469.4.2.36"The Measurement Pilot Transmission subelement has the same format as the Measurement Pilot Transmission element (see 9.4.2.42 (Measurement Pilot Transmission element)). The Measurement Pilot Interval subelement is not included if" -- last Interval should be TransmissionChange "Interval" to "Transmission" in the cited text at the referenced locationDiscussion:Agree with commenter.Proposed Resolution:Accepted. Note to Editor, the change is actually at P1063L48.CIDPageLineClauseSubmissionCommentProposed Change13941337.37379.4.3All the statements of the form "The $blah field contains zero or more subelements. The subelement format and ordering ofsubelements are defined in 9.4.3 (Subelements)." are unclear as to whether you can have more than one subelement with the same Subelement IDAdd a para at the end of 9.4.3: "Unless stated otherwise, no more than one subelement with the same Subelement ID is present within an element."Discussion:From 9.4.2.20.5:Many (but not all) of the occurances of the cited statements are of the above form, specifying Optional Sublements, and all of them appear to include the Vendor Specific element. While several other elements (besides Vendor Specific) don’t make sense to include more than one time, there are a few that could potentially be reasonable, and certainly more than one Vendor Specific element could be reasonable. Given this, and the potential for making existing implementations non-compliant if they do include more than one of some element type, the suggestion is not to add this restriction. No clear problem is identified by the commenter for allowing more than one of some element types/IDs.Proposed Resolution:Rejected. Adding such a restriction could make existing implementations non-compliant. Further, the comment provides no clear problem that would be solved by such a restriction.13691964.606011.1.711.1.4.6 Operation of Supported Rates and BSS Membership Selectors element andExtended Supported Rates and BSS Membership Selectors element and 11.1.7 Supported rates and extended supported rates advertisement cover the same materialDelete Subclause 11.1.7Discussion:Examining the above, it can be seen that 11.1.7 describes the transmitter of this information (the transmitter of Beacons and Probe Responses), while 11.1.4.6 describes the behavior of a receiver of this information. There is some information that is repeated, and could potentially be trimmed (for example the optional inclusion of an Extended Supported Rates and BSS Membership Selectors element if the total number of supported rates and BSS membership selectors is eight or less). However, this overlap is small, and is helpful to understand the complete scope of what each of the transmitter and receiver needs to accommodate (respectively).Proprosed Resolution:Rejected. Subclauses 11.1.4.6 and 11.1.7 describe required behavior for the receiver and transmitter of these elements, respectively. There is minimal duplicated information between these two subclauses, and only where it helps understand the overall behavior expectations of the receiver or transmitter, appropriately.1397966.46469.4.2.20.19"The Randomization Interval field specifies the upper bound of the random delay to be used prior to making the measurement, in units of TUs. See 11.11.3 (Measurement start time)." --- the xref is bogus as 11.11.3 is about radio measurement frames not FTM framesDelete "See 11.11.3 (Measurement start time)." in the cited text at the referenced locationDiscussion:The cross-reference in 9.4.2.20.19 is actually to 11.10.3:11.10.3 discusses the start time for Radio Measurement Requests, including the randomization interval. This applies to all measurement types listed in 11.10.And, finally, 11.10.9.11 lists Fine Timing Measurement Range report as one such request. Also, note this is Fine Timing Measurement *Range* report, which is a request for the receiving STA to start a Fine Timing Measurement procedure (to meaure range to one or more third devices), not an actual/direct use of Fine Timing Measurement between the requesting and receiving STAs.Since this is a request for the receiving STA to perform a measurement, that request can be satisfied using the randomization interval, just like for any other measurement request. Thus, the cross-reference is correct.Proposed Resolution:Rejected. The request in 9.4.2.20.19 is for a Fine Timing Measurement Report, not for a Fine Timing Measurement procedure directly. Such a request for a report can use the randomization interval before starting, as specified in 11.10.3. Thus, the cross-reference is correct. See also 11-18/0669 for more detailed discussion.1354766.25259.3.1.1It is not very clear that Figure 9-22 normatively requires most FC subfields in Control frames to be 0Below the referenced figure add a "NOTE---The To DS, From DS, More Frag, Retry, Protected Frame and +HTC subfields in the Frame Control field within Control frames carried in anon-S1G PPDU are reserved."Discussion:While it is true that these fields are effective reserved (currently) for a non-S1G PPDU Control frame, this is not the usual meaning of reserved. Normally, reserved means the bits are meaningless in a given frame, and so are reserved for future use by “protecting” that they are set to zero in current transmitter implementations, and ignored by current receivers, to future proof a potential use in a later version of the Standard. In this case, they are meaningful bits, which happen to have known and fixed values in the particular context of a non-S1G PPDU Control frame. As such, it can be argued that a receiver is not expected to ignore these fields, but could (potentially) rely on the zero values specified.Further, this is not the only use of this convention (specifying a fixed value for a field, in a certain context). See Figures 9-33, 9-296, 9-297, 9-895, and others. If any change is made, it should be a description of this nomenclature style, in subclause 9.2.2. Proposed Resolution:Revised. Add a sentence to the end of the first paragraph in 9.2.2, “A field or subfield within the figure depiction of a frame format that includes a decimal value within parentheses indicates that this field or subfield is set to the indicated value upon transmission.”1281839.64649.4.1.7In Table 9-51, Reason codes 40-44 are not defined.Please change the Reason code "45" to "40-45".Discussion:Context: Robert Stacey (ANA coordinator) confirms that these entries were assigned to 802.11e, and were apparently not used. They should be marked as “Reserved” in Table 9-51, and marked appropriately for future use in the ANA database (which Robert will do).By changing the Reason code column from “45” to “40-45” (as proposed), codes 40 through 44 will become Reserved.Proposed Resolution:Accepted.14002272.222211.38.1"the STA shall indicate support for MCSs 8(n-1) to 8(n-1)+7" should be clearer as to what kind of MCSOn lines 22 and 23 at the referenced page change "MCS" to "HT-MCS"Discussion:Context: Arguably, it should be apparent that setting bits in the Rx MCS Bitmask contained in the HT Capabilites element, would be indicating HT MCS rates. However, this paragraph is already rather confusing with the number of cross-references between VHT and HT capabilities in the text, there is potential for confusion, so the proposed change seems to cause no harm and might be helpful.The use of “HT-MCS” (with the hyphen) seems to be limited to “Basic HT-MCS Set” (the fieldname), however. The usage is “HT MCS” where the “HT” is an adjective.Proposed Resolution:Revised. On lines 22 and 23 at the referenced page change “MCSs” to “HT MCSs”.14011975.434311.2.3.6"If the STA has set up to useunscheduled SPs, the AP shall buffer BUs using delivery-enabled ACs until it has received a triggerframe using a trigger-enabled AC from the non-AP STA, which indicates the start of an unscheduledSP. A trigger frame received by the AP from a STA that already has an unscheduled SP underwayshall not trigger the start of a new unscheduled SP. The AP transmits BUs destined for the STA andusing delivery-enabled ACs during an unscheduled SP." -- 1) this seems to be the only specification of trigger frame handling for U-APSD at the AP, but "tramsmits BUs" is vague; 2) it is not clear whether/how/when MMPDUs are "using delivery-enabled ACs"After the cited text at the referenced location add "NOTE 1---Transmission of BUs during an unscheduled SP is constrained by the max SP length.NOTE 2---The AC for delivery of an MMPDU (see 10.2.3.2) determines whether it is transmitted using a delivery-enabled AC during an unscheduled SP."Discussion:Context: (The text is quoted in the comment, but shown here to make it easier to read, and show the context within 11.2.3.6.)While the statements made in the proposed NOTEs are already made elsewhere, they are correct, and it might be helpful to the reader’s understanding to have those reminders in this context.Proposed Resolution:Revised. Make the proposed changes, by adding the NOTEs at the end of bullet (d). 14032018.424211.3.4.3Missing clarification cf. 11.3.4.2At the end of step g) add "; the state shall remain unchanged if it was other than State 1"Discussion:Context:11.3.4.3(g) does leave it vague what (if anything) happens to the state after successful Authentication, if was not in State 1. Since it doesn’t say anything is changed, the assumption would be that nothing is changed, but that’s a bit vague.11.3.4.2(c) has this, to make the assumption more explicit:Proposed Resolution:Accepted.14051971.343411.2.3.5.1"An unscheduled SP ends after the AP has attempted to transmit at least one BU using a delivery-enabled AC and destined for the STA, but no more than the number indicated in the Max SP Length field of the QoS Capability element of the STA's (Re)Association Request frame if the field has a nonzero value." -- it doesn't necessarily end after the AP has attempted to transmit one BU. It ends when the AP has transmitted an EOSP or the number of BUs reaches Max SP LengthChange the cited text at the referenced location to "An unscheduled SP ends after the AP has attempted to transmit at least one BU using a delivery-enabled AC and destined for the STA, but no more than the number indicated in the Max SP Length field of the QoS Capability element of the STA's (Re)Association Request frame if the field has a nonzero value, where the last BU is transmitted in MPDUs with EOSP subfield set to 1."Discussion:Context:The fourth paragraph does have the quoted text. This paragraph gives a description of the start and end points of the service period. The following paragraph gives the details that the last frame in the SP must have the EOSP set to 1, and that this might be before the Max SP Length has been reached. Thus, all the information requested is present in these two paragraphs, already.Proposed Resolution:Rejected. The requested information is already present in the paragraph following the cited text.14142127.444411.15.8If the DSSS/CCK Mode in 40 MHz subfield is equal to 0 in a beacon/probe response, it is not clear whether the STA is required to set it to 0 in the association request. The description is "An HT STA declares its capability to use DSSS/CCK rates while it has a 40 MHz operating channel width", which is vague (capability to use v. intent to use). However, it seems clear that if the AP says DSSS/CCK Mode in 40 MHz is not allowed, the STA's signal of capability to transmit such is irrelevantAppend "- The DSSS/CCK Mode in 40 MHz subfield transmitted by a (re)associating STA is ignored." at the end of the list in the para after the referenced locationDiscussion:Context:The second paragraph of 11.15.8 makes it clear that an HT (non-AP) STA indicates “its capability to use DSSS/CCK” with 40 MHz channel width, in the DSSS/CCK Mode in 40 MHz subfield in (Re)Association requests to the AP.The first sentence of the third paragraph makes it clear that an HT AP will indicate support in the same subfield in Beacons and Probe Responses. If the AP supports this, the non-AP STA may generate such transmissions.If the AP does not support this, the (non-AP) associated HT STA shall not generate such transmissions. However, the bullet list that describes this situation is vacuuous on how the non-AP STA should set the subfield on its (Re)Association Request.Since the AP will not transmit DSSS/CCK with 40 MHz channel width anyway, it seems irrelevant what the non-AP STA puts in the (Re)Association Request. Thus, the proposed change seems arguably unnecessary, but it does clarify what it currently underspecified in a backwards compatible way.Proposed Resolution:Accepted.10081337.43439.4.3Definition of subelement is not aligned with actual use of it. In relation to Measurement request and Measurement report IE the statement that "Each subelement is assigned a subelement ID that is unique within the containing element or subelement." is not true. The sub elements are defined within the Measurement type.Add to the sentence as follows:Each subelement is assigned a subelement ID that is unique within the containing element or subelement, or measurement type of the Measurement Request IE and Measurement Report IE.Discussion:Context:9.4.3 does make the claim as stated, that all subelements are uniquely identified within “the containing element or subelement.” Looking at the definition of the subfields in a Measurement Request, we turn to the following format definition:It can be seen that the Measurement Request element has a subfield of Measurement Request. Further the Measurement Request is defined, based on the Measurement Type, by the following descriptions:One sudh Measurement Request field is the “Basic request”, defined in 9.4.2.20.2:It can be seen that the Basic request is not a sublement, however, and in fact it has no ID at all.Rather, the interpretation of this construct is that the Measurement Request element is a variable element, where one field (the Measurement Request field) has a format that is dependent on another field (the Measurement Type field). This is no longer a “subelement” construct, as are described in 9.4.3. Thus, 9.4.3 has no error.Proposed Resolution:Rejected. The Measurement Request field (of a Measurement Request element) is not itself a subelement, and has no ID at all for which a uniqueness context can be described. Thus, 9.4.3 does not apply to this structure, so this is not a counter-example of the correctness of 9.4.3. No change to 9.4.3 seems necessary. The same logic applies to the Measurement Report structure.1282847.19199.4.1.9In Table 9-52, Status code 123 is double defined.Please change Status code "114-65535" to "114-122, 124-65535".Discussion:Context:From 802.11REVmd_D1.0:The value 123 is indeed defined individually and also covered by the range 114-65535.However, from 802.11REVmd_D1.2:It seems the REVmd editors already caught this error, during the roll-in of 802.11ai, and the error has already been fixed, in a manner consistent with (but not exactly matching) the commenter’s request.Proposed Resolution:Revised. Split the Reserved range into two sub-ranges, excluding the value 123.Note to EDITOR: This change is already made in REVmd-D1.2.Note to EDITOR: The representation of “Reserved” in this Table is inconsistent, sometimes appearing in the “Name” column and sometimes in the “Meaning” column. The Table should be consistent.10181571.585810.2.7This section talks about filtering group addressed frames from a STA andreceived by the STA relayed back from AP in an infrastructure BSS. It is not clear wherethis filtering happens. Is this along with address filtering on Address 1 or later? Where do this reside, say in Figure 5-1MAC data plane architecture?It should be done after replay detection for AES and perhaps after MSDU MIC check for TKIPDiscussion:Context:The fourth and fifth paragraphs discuss the behavior when group addressed messages are present in an infrastructure BSS. It is correct that this text prescribes a (non-AP) STA to filter out group addressed messages that contain the STA’s own address as the source address, and that it is not specified where this occurs in the “stack”. However, it does not seem important where this happens, as the rule is simple, and will be applied to each and every such frame received with the STA’s own address as the source address. It seems there is little harm in doing this very low/early in the receive stack, since the frame will be discarded anyway, so checking the MIC or for retries (which will only discard the frame for other reasons) doesn’t seem to matter. Conversely, if the frame is discarded only higher in the stack, consideration has to be given for DOS attack vectors, etc. However, this frame will never be processed fully up the stack, so again, attacks that cause incorrect discarding (for the wrong reason) have no net effect. Finally, the frame generates no response (no ACK is generated for such group addressed frames, for example), so there is no consideration for the transmitter’s view of the process.So, it seems this can be entirely an implementation choice, as to where in the stack such frames are discarded, as long as it is accomplished consistently at some point.Proposed Resolution:Revised. Append “; the point at which such filtering occurs in the processing of received frames is an implementation choice” to the end of the second sentence of the fifth paragraph of 10.2.7.10331945.01111.1.3.9The sentence "In the case of an infrastructure BSS, the STA's TSF timer shall then be set to the adjusted value of the timestamp." on Line 1 is redundant, because the sentence on Line 9 covers it.Delete the cited sentence on Line 1.Discussion:Context:The statement at line 1 is the last step for that bullet, and it does seem to be exactly covered by the following paragraph’s first sentence.Proposed Resolution:Accepted. Note to EDITOR: The copy to delete is the one at the end of the first bullet’s text in 11.1.3.9. The copy at the start of the next (non-bulleted) paragraph is to be retained.1114783.30309.3.1.19With the 11ah changes, this statement is now incomplete.Change to "If the VHT NDP Announcment frame is transmitted by a non-S1G STA, then the format of the STA Info field is shown in Figure 9-55."Discussion:Context:The cited text:With details of the subfields folling.Then, after all that, there is new text, added by 11ah:Clearly, 11ah did intend the STA Info field to have a different format for S1G and non-S1G. The proposed change does clarify this.Proposed Resolution:Accepted.13051565.595910.2.3.1Text states "Frames listed in Table 9-376 (HT Action field values)(11ah)," Frames are not listed in these tables. It lists valuesGrammar? Should it say "frames using values in tables.......with a value of yes in the "time priority" column....Discussion:Context:The commenter is correct, in that the referenced Tables list values (used in the Action field, of various Action frame categories), as shown in this example (the others are similar):However, there is an (unwritten?) convention that a phrase that means “Action frame with <category> Action field value of <x>” is referenced in the Standard as an “<x> frame”. For example, an HT Action frame with HT Action field value of “PSMP” is called a “PSMP frame”.So, when the cited text in 10.2.3.1 says “Frames listed in Table 9-376, etc., is this using the same shorthand convention and implicitly means, “Action frames with HT Action field value of PSMP listed in Table 9-376”?If this convention is sufficiently clear and understood, then no change is needed.If this convention is unclear/vague enough that clarification is needed, the text could be changed to say “Frames with Action field values of the appropriate category as listed in Table 9-376, etc.” This accomplishes the apparent direction the commenter suggested, without the vague use of “frames using values …”. Proposed Resolution:Revised.Change “Frames listed in Table 9-376 (HT Action field values)(11ah), Table 9-460 (VHT Action field values), Table 9-465 (Unprotected S1G Action field values(11ah)), and Table 9-482 (Flow Control Action field format(11ah)) with a value of “Yes” in the “Time priority” column are time priority Management frames.”to “Time priority Management frames are defined to be those that have a value of “Yes” in the “Time priority” column in Table 9-376 (HT Action field values)(11ah), Table 9-460 (VHT Action field values), Table 9-465 (Unprotected S1G Action field values(11ah)), and Table 9-482 (Flow Control Action field format(11ah))”13381285.37379.4.2.185" At least one of the bits in FILSC Type field is set to 1. " -- but setting one of the reserved bits would not be helpful (and would be contrary to the definition of "reserved")Change the cited text at the referenced location to "At least one of the non-reserved bits in FILSC Type field is set to 1."Discussion:Context:The proposed change would clarify the intent, for the avoidance of any doubt.Proposed Resolution:Accepted.13431955.161611.1.4.3.4"If the next Beacon is not used as a response" is missing "frame"Add "frame" after "Beacon" in the cited text at the referenced locationDiscussion:Context:Similarly, on P 1937:Proposed Resolution:Revised. Make the change as proposed, and also make the same change at P1937.15.13492287.181811.42.3"A GDD dependent STA shall cease all transmission when (#172)dot11GDDEnablementValidityTimer has expired" -- a MIB variable cannot expireChange the cited text in the referenced location to "A GDD dependent STA shall cease all transmission when the GDD enablement validity timer has expired".In the para above delete "by decrementing dot11GDDEnablementValidityTimer". In Figure 11-51 change "dot11GDDEnablementValidityTimer has expired" to "GDD enablement validity timer has expired". In 11.42.4.1 change "it reinitializes the dot11GDDEnablementValidityTimer to" to "it reinitializes the GDD enablement validity timer". In C.3 delete dot11GDDEnablementValidityTimer. In Tables E-8 and E-11 delete the dot11GDDEnablementValidityTimer rowDiscussion:Context:The first bullet introduces the term “GDD enablement validity timer”, and subsequent references to decrementing, reinitializing and expiry should reference this conceptual timer, as there appears no need for a MIB attribute tracking this timer’s value.Thus, the first two proposed changes appear to be correct.Context for Figure 11-51:The third proposed change appears correct.11.42.4.1 context:The fourth change appears correct in intent. But the replacement text should include the “to” at the end. Thus, In 11.42.4.1 change "it reinitializes the dot11GDDEnablementValidityTimer to" to "it reinitializes the GDD enablement validity timer to". C.3 contexts:The cited location (to be deleted):And, the definition for dot11ContactVerificationSignalInterval:There seem to be a number of issues with these definitions. First, dot11GDDEnablementValidityTimer can’t be a status variable if it is initialized by the SME. But, the proposed resolution is to delete this attribute entirely, and use the conceptual (local) timer instead. Okay, except we don’t delete MIB attributes, we mark them obsolete.Look next at dot11ContactVerificationSignalInterval, which is the value the timer is reset to, upon each response for its Channel Availability Query frame from the GDD enabling STA. There is no text describing how an external entity sets this attribute, in fact, there are two “shall” statements that this attribute shall be set to 60 seconds in both the US/Canada and Europe. Also, the DESCRIPTION seems to be missing a temporal verb, probably “wait to”.Suggest to add to the text (with the “shall” statements) introducing Tables E-8 and E-11:All GDD dependent STAs shall set the dot11GDD timer values as shown in Table E-11 (TVWS GDD timer limits), unless otherwise mandated by regulatory authorities.and to modify the DESCRIPTION for this MIB attribute as shown:dot11ContactVerificationSignalInterval indicates the maximum number ofseconds that a GDD dependent STA may wait to receive the Contact VerificationSignal frame before stopping operation in TVWS. Unless another value is mandated by regulatory authorities, the value is 60 seconds."That leaves the final proposed change to remove the dot11GDDEnablementValidityTimer row from Tables E-8 and E-11. This change seems correct.Finally, due to a spelling error, two more instances of dot11GDDEnablementValidityTimer, in subclause 11.42.6, were missed in this comment’s proposed resolution. Conext:Propose to correct this text, also, by replacing “dot11GDDEnablementValidityTimer” with "the GDD enablement validity timer” in both occurrances.Proposed Resolution:Change the cited text in the referenced location to:"A GDD dependent STA shall cease all transmission when the GDD enablement validity timer has expired".In the para above, delete:"by decrementing dot11GDDEnablementValidityTimer". In Figure 11-51 change "dot11GDDEnablementValidityTimer has expired" to "GDD enablement validity timer has expired". In 11.42.4.1 change: "it reinitializes the dot11GDDEnablementValidityTimer to" to "it reinitializes the GDD enablement validity timer to". In Tables E-8 and E-11 delete the dot11GDDEnablementValidityTimer row In C.3, mark dot11GDDEnablementValidityTimer as deprecated with appropriate collateral changes as follows:Change its STATUS to “Deprecated”.Insert a new first line in the DESCRIPTION: “Deprecated as the related feature has been removed from the standard”. For any reference to the variable in any GROUPs, re-instate this reference. Change the groups STATUS to “Deprecated”. In the DESCRIPTION, insert a new first line: “Superseded by YYYY.” (Note that “YYYY” is the new GROUP name.) For each of the groups noted above, copy the group, set its status to “Current” and increment (or add) a number after the name of the group name (e.g. dot11SMTbase11 -> dot11SMTbase12).Make the corresponding changes (e.g. add or remove MIB varables) in the new groupFor each reference to one of the noted groups from a compliance statement, update it to refer to the new group.In the text just before Tables E-8 and E-11 makes changes as shown:All GDD dependent STAs shall set the dot11GDD timer values as shown in Table E-11 (TVWS GDD timer limits), unless otherwise mandated by regulatory authorities.In C.3, change the DESCRIPTION of dot11ContactVerificationSignalInterval as shown:dot11ContactVerificationSignalInterval indicates the maximum number ofseconds that a GDD dependent STA may wait to receive the Contact VerificationSignal frame before stopping operation in TVWS. Unless another value is mandated by regulatory authorities, the value is 60 seconds."Replace “dot11GDDEnablementValidityTimer” with "the GDD enablement validity timer” in both occurrances in 11.42.6.12731019.57579.4.2.24.1"AES-128-CMAC" is a name of the integrity protection algorithm used by the cipher that is called "BIP-CMAC-128". However, couple of places that are clearly referring to a cipher are incorrectly using the name of the algorithm rather than the cipher.Replace "AES-128-CMAC" with "BIP-CMAC-128" at page 1019 line 57 and page 1020 line 27.Discussion:Context:The cited text is here:. . .The “BIP-CMAC-128” suite selector is listed in the table of Cipher suite selectors on the next page.Indeed, AES-CMAC-128 is an algorihm name, not a suite selector, so the change is correct.Proposed Resolution:Accepted.15361267.56569.4.2.169.2" Values of Operating Class are shown in Table E-4 (Global operating classes), of which operating classes that, together with the channel number, indicate the primary channel is valid (see 11.42.8 (Reduced neighbor report))." -- this sentence doesn't make senseDelete the referenced sentence in the referenced locationDiscussion:Context:The cited text applies to the Neighbor AP Information field, within the context of a Reduced Neighbor Report:It appears that most of the cited sentence is actually a duplicate of the prior sentence, and is likely an editorial glitch. However, the concept that the “primary channel is valid” is uniquely in the cited sentence. There is no occurance of “valid” in 11.50, so that cross-reference does not actually add to this concept. It’s not clear what this is trying to add, over the simple statement in the prior sentence that the RNR is indicating the primary channel that is being used. Whether that channel is valid, can either be assumed (if it is being used), or is at least outside the scope of what is reported in an RNR. So, this concept seems unnecessary to introduce here.Thus, the entire cited sentence does appear to be unnecessary, and agree with the commenter that it doesn’t make sense in the current form. So, just delete it.Proposed Resolution:Accepted.14852084.474711.10.6" A STA refusing a measurement request within an individually addressed Radio Measurement Request frame shall respond with a measurement report indicating that it is refusing the measurement request. A STA shall not respond to measurement requests received in Radio Measurement Request frames in this manner." is self-contradictoryAdd "group addressed" after "shall not respond to" in the cited text at the referenced locationDiscussion:Context:This text comes from 802.11k-2008. It got changed somewhere before 802.11-2012, and has remained as seen above since then. In 802.11k-2008, we find the following version:Proposed Resolution:Revised.Insert “group addressed” after “received in”, in the cited sentence. ................
................
In order to avoid copyright disputes, this page is only a partial summary.
To fulfill the demand for quickly locating and searching documents.
It is intelligent file search solution for home and business.
Related download
- programming with unicode documentation
- crash course on character encodings
- mini lecture on character sets and unicode
- character sets and unicode in firebird
- localization of text editor using java programming
- java urls university of north dakota
- java and unicode juneday
- encodings for obix common encodings version 1 0
- file format wikipedia the free encyclopedia
- introduction