On Sep 15, 2010, at 9:28 PM, Thomson, Martin wrote:
> The joy of writing a specification is that you don't have to specify what algorithm is used. Either algorithm would only be an example - you can use the more conservative algorithm, I can choose to provide a more complicated algorithm :)
>
> Taking "Wêïrd\5cNàmé" you get [0x57, 0xC3, 0xAA, 0xC3, 0xAF, 0x72, 0x64, 0x4E, 0xC3, 0xA0, 0x6D, 0xC3, 0xA9]. You could just as easily go with "W\c3\aa\c3\afrd\5cN\c3\a0m\c3\a9"; or even "\57\c3\aa\c3\af\72\64\4e\c3\a0\6d\c3\a9". They all end up producing the same value. Certainly, the latter two choices are easier to write code for.
>
> This is what I intend to add:
>
> An SSID is a sequence of up to 32 octets. SSIDs are typically presented as strings, which are converted to an octet sequence using either ASCII or UTF-8 encoding. The "ssid" element is provided as a string that is converted to octets by UTF-8 encoding the string. Octet values can be expressed directly using a backslash ('\') followed by two hexadecimal digits.
>
> The value of an SSID is the sequence of octets that
> is produced from the concatenation of UTF-8 encoded sequences of
> unescaped characters and octets derived from escaped components.
I think there might be a problem in the revised definition. What if you have 32 ê values, which you encoded with the two octets \c3\aa? Per your pattern, that is legal but it's 64 octets. Perhaps we can get out of it with a statement in the text rather than trying to fix the pattern to be exact (a solution I don't prefer but it's manageable)?
Also I'd note in the text that 0 byte characters are legal in a SSID.
>
> The XML will change to have a constraint:
>
> <xs:pattern value="([^\\]|\\[\da-fA-F]{2}){1,32}"/>
The SSID can be zero bytes, so the pattern (before fixing the above problem) would be:
<xs:pattern value="([^\\]|\\[\da-fA-F]{2}){0,32}"/>
--
David Waitzman
BBN Technologies
djw@bbn.com 410-290-6160
