On Sep 13, 2010, at 8:19 PM, Thomson, Martin wrote:
> The SSID as string is an error.
>
> It would be relatively easy to change the base type used here to xs:hexBinary.
Using xs:hexBinary is also a good choice; I was trying to mirror how macAddressType are encoded.
> 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>
I get geopriv as a digest, for now, so it's too easy to loose track of valuable individual emails like John's and your response to him.
> That solution recognizes the virtues of a text-based protocol and attempts to retain those virtues at a small cost in complexity.
As I expressed in my first message, users don't normally look at raw XML contents:
>> 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.
Your suggestion in msg08717.html of:
>>> LDAP uses a simple scheme where a backslash followed by two hex characters is converted into an octet with that value:
>>>
>>> octetsAsString = *(vcharx / escaped)
>>> vcharx = %x21-5b / %x5d-7e ; VCHAR minus backslash
>>> escaped = %x5c 2HEXDIG
doesn't handle the UTF-8 encoding cases well. It would escape all non-ASCII values in an UTF-8 string, so for practical real-world cases, would use escaping. We did tests here with non-ASCII UTF-8 contents in real wireless devices and some were fine with them, like Apple Airports.
Therefore, I still prefer my proposal or your hexBinary proposal. At least the LDAP scheme is not lossy as compared to the current HELD-measurements draft.
> 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.
I looked that up and don't get your point. In <xs:element name="ssid" type="wifi:ssidBaseType" minOccurs="0"/> we not dealing with an Attribute's value.
---
One additional question for you: what's the difference between "name" and "ssid" in wifiType?
name: The broadcast name for the access point.
ssid: The service set identifier for the wireless network served by
the access point.
<xs:element name="name" type="wifi:ssidBaseType" minOccurs="0"/>
The one example of a wifiType has these values with different capitalization:
<name>Example</name>
<ssid>example</ssid>
As far as I can understand, name should be identical to ssid. Perhaps there was supposed to be some distinction with regards to "hidden" SSIDs?
--
David Waitzman
BBN Technologies
djw@bbn.com 410-290-6160
_______________________________________________
Geopriv mailing list
Geopriv@ietf.org
https://www.ietf.org/mailman/listinfo/geopriv
