Technical question about WLAN names

I'm working on an embedded systems device that has 802.11b wireless.
I'm working on the the part of the configuration utility where the
user assigns a WLAN name. I want to implement this correctly. The
802.11 standard says there are 32 octets in this name.

I need to be compatible with existing WLAN names because this device
will be deployed on peoples' infrastructure networks.

What I want to know is what characters are allowed in the WLAN name.
For example, is the terminal bell character allowed? What do you do
for foreign characters and encodings? For example, in Japan do people
store Japanese characters in the WLAN name? How/where is the encoding
stored?

Do I just assume UTF-8?

Thanks in advance for any illumination!

Brant Sears

I assume you mean SSID (there is no such thing as "WLAN name" defined in the
standard).

It's defined as a 0-32 byte octet string. In ASN.1, an octet string is a
sequence of 8-bit quantities, each of which can take on *any* value.
Therefore, the standard imposes no restrictions or structure on the SSID,
other than length, and the fact that the 0-length SSID is special (the
universal SSID). Any structure is an implementation detail left to you.

But some general observations are in order.

1. I can think of no reason to allow the universal SSID to be assigned when
configuring an AP.

2. Not all client drivers allow universal SSID to be specified, so you don't
necessarily have to support it. If you do, I recommend that you provide a
way to positively confirm that it's what the user wants - don't just accept
an empty data entry field. Require a pair of double-quotes, or a selection
from a drop-down menu, or something else that forces the user to consciously
choose.

3. People normally want the SSID to be human-readable so that it will be
meaningful and easy to remember. If the operating system is handling all
text entry/presentation issues for you, then there should be no issue for
the utility, except to ensure that no more than 32 octets are accepted for
the SSID. If a double-byte encoding is used (common for Chinese and
Japanese), then no more than 16 characters can be entered. Hopefully, some
way can be found to make the operating system enforce this for you.

4. You might find it useful, especially for Asian language contexts, to
allow a hexadecimal representation of the octet string to be entered. This
is a last resort if you are having encoding issues with double-byte
character sets that are not being properly resolved by the text entry
frontend.

NOTE: You do NOT want to implement Japanese Kanji or Chinese Guo-Bioa/Big
Five data entry within the utility, if you can avoid it. If the operating
system can't handle it for you, look into getting a frontend that does (and
hopefully also resolves issues like restricting the data entry field to 16
characters if double-byte encoding is used). There are tens of thousands of
characters, and the usual data entry method is to type phonetic
representations of syllables to a frontend editor, which then presents a
list of possible character readings from which you must select. Japanese
katakana can be implemented fairly easily (it's already phonetic), but that
doesn't solve the general problem for Taiwan and China. If you have to get
into this, buy the O'Reilly "puffer-fish" book.

"Brant Sears" <(E-Mail Removed)> wrote in message
news:(E-Mail Removed) om...
> I'm working on an embedded systems device that has 802.11b wireless.
> I'm working on the the part of the configuration utility where the
> user assigns a WLAN name. I want to implement this correctly. The
> 802.11 standard says there are 32 octets in this name.
>
> I need to be compatible with existing WLAN names because this device
> will be deployed on peoples' infrastructure networks.
>
> What I want to know is what characters are allowed in the WLAN name.
> For example, is the terminal bell character allowed? What do you do
> for foreign characters and encodings? For example, in Japan do people
> store Japanese characters in the WLAN name? How/where is the encoding
> stored?
>
> Do I just assume UTF-8?
>
> Thanks in advance for any illumination!
>
> Brant Sears

gary <(E-Mail Removed)> wrote:
> I assume you mean SSID (there is no such thing as "WLAN name" defined in the
> standard).
>
> It's defined as a 0-32 byte octet string. In ASN.1, an octet string is a
> sequence of 8-bit quantities, each of which can take on *any* value.
> Therefore, the standard imposes no restrictions or structure on the SSID,
> other than length, and the fact that the 0-length SSID is special (the
> universal SSID). Any structure is an implementation detail left to you.
>
> But some general observations are in order.
>
> 1. I can think of no reason to allow the universal SSID to be assigned when
> configuring an AP.
>
> 2. Not all client drivers allow universal SSID to be specified, so you don't
> necessarily have to support it. If you do, I recommend that you provide a
> way to positively confirm that it's what the user wants - don't just accept
> an empty data entry field. Require a pair of double-quotes, or a selection
> from a drop-down menu, or something else that forces the user to consciously
> choose.

I would probably pop up a dialog box if there are nulls in there too.
You know they are legal, I know they are legal, want to bet someone
is using a null-terminated buffer somewhere in some driver somewhere?

I'd strongly recommend to the user that they stick to [A-Za-z0-9 ]
and certainly to [!-~] unless it's a non-english charset.
Certainly pop up a box saying "this SSID is likely to appear differently
than you are entering it now for computers set for a different language"
or similar.

"Ian Stirling" <(E-Mail Removed)> wrote in message
news:73K1c.15258$(E-Mail Removed)...
> gary <(E-Mail Removed)> wrote:
> > I assume you mean SSID (there is no such thing as "WLAN name" defined in
the
> > standard).
> >
> > It's defined as a 0-32 byte octet string. In ASN.1, an octet string is a
> > sequence of 8-bit quantities, each of which can take on *any* value.
> > Therefore, the standard imposes no restrictions or structure on the
SSID,
> > other than length, and the fact that the 0-length SSID is special (the
> > universal SSID). Any structure is an implementation detail left to you.
> >
> > But some general observations are in order.
> >
> > 1. I can think of no reason to allow the universal SSID to be assigned
when
> > configuring an AP.
> >
> > 2. Not all client drivers allow universal SSID to be specified, so you
don't
> > necessarily have to support it. If you do, I recommend that you provide
a
> > way to positively confirm that it's what the user wants - don't just
accept
> > an empty data entry field. Require a pair of double-quotes, or a
selection
> > from a drop-down menu, or something else that forces the user to
consciously
> > choose.
>
> I would probably pop up a dialog box if there are nulls in there too.
> You know they are legal, I know they are legal, want to bet someone

I agree. I would exclude nulls altogether, as they are never needed in any
text encoding, and will probably cause havoc in string handling routines.
Should be an issue only if you allow a hexadecimal text entry format.

> is using a null-terminated buffer somewhere in some driver somewhere?
>
> I'd strongly recommend to the user that they stick to [A-Za-z0-9 ]
> and certainly to [!-~] unless it's a non-english charset.
> Certainly pop up a box saying "this SSID is likely to appear differently
> than you are entering it now for computers set for a different language"
> or similar.
>

There's no reason to exclude extended ASCII to get the cedille or accented
vowels. I know from experience that it's awkward to ask people to make up
orthographic tricks to spell ordinary words. Example: using "nh" (Portuguese
spelling convention) or "nn" to approximate the Spanish "n" with a tilde, or
"oe" to approximate German "o" with umlaut. This makes for clumsy and
unnatural text. If you're going to support full extended ASCII, there's not
much point in enforcing any restriction on special graphics. Anything not
mapped to a keyboard will be difficult to enter anyway, and if somebody
wants to go out of their way to enter a right angle bracket, more power to
them.

It may be a good idea to recommend that European countries stick to ordinary
7-bit ASCII, because it will be readable in any European locale, but I
wouldn't try to enforce it in any way. In Asian countries, if the OS string
libraries support double-byte encoding without any effort on your part, it
would be a mistake not to allow it. You can use the Roman alphabet in Japan
and China ("Romaji" and pinyin phonetic), but there is a strong preference
to use characters. Since SSIDs often encode useful information, you don't
want to make this hard.for them. Not placing any restrictions at all (except
possibly on nulls) allows the Asian users the flexibility to choose a Roman
alphabet with ASCII encoding or traditional characters.