The SSID as string is an error.
It would be relatively easy to change the base type used here to xs:hexBinary.
The only concern is that, in most cases, an SSID is a string. Users set and view SSIDs as strings.
LDAP has a similar problem with its attributes and they solved it [RFC4514] differently. And I proposed that we do the same in response to John Bressler:
<http://www.ietf.org/mail-archive/web/geopriv/current/msg08717.html>
That solution recognizes the virtues of a text-based protocol and attempts to retain those virtues at a small cost in complexity.
--Martin
p.s. It's not immediately clear, but a token can include any string content: <http://www.w3.org/TR/xml/#AVNormalize>. The text you cite is misleading.
> -----Original Message-----
> From: geopriv-bounces@ietf.org [mailto:geopriv-bounces@ietf.org] On
> Behalf Of David Waitzman
> Sent: Tuesday, 14 September 2010 5:49 AM
> To: geopriv@ietf.org
> Subject: [Geopriv] Format of SSID in held-measurements-01.txt
>
> I have a comment about the choice of data representation of SSID along
> with a suggested change.
>
> 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
_______________________________________________
Geopriv mailing list
Geopriv@ietf.org
https://www.ietf.org/mailman/listinfo/geopriv
