The held-measurements draft makes a common assumption that the SSID (not the BSSID) is a printable character string. This is expressed in the XML on page 52:
<xs:simpleType name="ssidBaseType">
<xs:restriction base="xs:token">
<xs:maxLength value="32"/>
</xs:restriction>
</xs:simpleType>
Actually, xs:token has some important restrictions on its contents. http://www.w3.org/TR/xmlschema-2/#token says:
"The ·value space· of token is the set of strings that do not contain the carriage return (#xD), line feed (#xA) nor tab (#x9) characters, that have no leading or trailing spaces (#x20) and that have no internal sequences of two or more spaces."
The IEEE 802.11 standards simply state a SSID is "0 to 32 octets". Nothing about ASCII or UTF-8. I think it is just a convenience hack that many 802.11 devices show them as if they are ASCII and some in UTF-8.
Therefore, the held-measurements draft can not represent all valid SSID values nor even all common ones (such as with leading/trailing/multiple spaces or a tab).
Additionally, non-printable SSIDs have been used in the past to defeat wardriving tools, by having contents that the tools would crash upon decoding. If we make a clear comment in the draft to *not* assume ASCII or legal UTF-8 values, we can encourage more robust implementations.
I suggest changing ssidBaseType to be something that can hold any octet value, like:
<xs:simpleType name="ssidBaseType">
<xs:restriction base="xs:string">
<xs:pattern value="(([0-9A-Fa-f]{2})(-[0-9A-Fa-f]{2}){0,31})?"/>
</xs:restriction>
</xs:simpleType>
Example: 45-40-01-00-fe
This pattern is similar to what's used for macAddressType.
This way the *protocol* can express all legal underlying values and *implementations* can choose to pretty-print the SSID values if they wish.
A drawback to my suggestion is that the raw XML contents will no longer display human readable SSID values. But I don't feel that the IETF mandates humans being able to easily read raw packet dumps.
--
David Waitzman
BBN Technologies
djw@bbn.com 410-290-6160
