Subject: [Geopriv] I-D Action:draft-ietf-geopriv-held-measurements-01.txt

From: [email-masked]
Date: Sun, 5 Sep 2010 18:00:02 -0700 (PDT)

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Geographic Location/Privacy Working Group of the IETF.

	Title           : Using Device-provided Location-Related Measurements in Location Configuration Protocols
	Author(s)       : M. Thomson, J. Winterbottom
	Filename        : draft-ietf-geopriv-held-measurements-01.txt
	Pages           : 73
	Date            : 2010-09-05

A method is described by which a Device is able to provide location-
related measurement data to a LIS within a request for location
information.  Location-related measurement information are
observations concerning properties related to the position of a
Device, which could be data about network attachment or about the
physical environment.  When a LIS generates location information for
a Device, information from the Device can improve the accuracy of the
location estimate.  A basic set of location-related measurements are
defined, including common modes of network attachment as well as
assisted Global Navigation Satellite System (GNSS) parameters.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-geopriv-held-measurements-01.txt

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

---

From: "Thomson, Martin" <[email-masked]>
Date: Mon, 6 Sep 2010 10:59:39 +0800

This update includes the following changes:

 - The schemas have been moved to the end of the document. [S8]
 - The 802.11 measurements have been altered based on discussions with Gabor and others to include [S5.3]: 
   o WAP -> AP (terminology change)
   o A "verified" attribute for the BSSID
   o A "band" element that identifies the frequency band
   o An antenna identifier for the access point
   o Flight time in place of round trip.  Round trip time measurement is adversely affected by scheduling delays; flight time measurement is what is being adopted by the IEEE.
 - The draft now describes how individual measurements could be better than reporting an average value. [S4.2]
 - An update to the MAC address, allowing for EUI-64. [S8.3]
 - A description of attacks that involve altering the measured phenomenon, such as the broadcasting of a spoofed GPS signal. [S7.1.5]
 - Correction to measurement schema for identifying the source of data [S8.1]

--Martin

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On
> Behalf Of [email-masked]
> Sent: Monday, 6 September 2010 11:00 AM
> To: [email-masked]
> Cc: [email-masked]
> Subject: [Geopriv] I-D Action:draft-ietf-geopriv-held-measurements-
> 01.txt
> 
> 	Title           : Using Device-provided Location-Related
> Measurements in Location Configuration Protocols
...

---

From: "John R. Bressler" <[email-masked]>
Date: Mon, 6 Sep 2010 13:27:52 -0400

How should clients handle WiFi measurements with non-ASCII SSID values? HELD
is required to use UTF-8, however the 802.11 standard does not appear to
restrict SSIDs to ASCII, UTF-8,  or even printable characters.  The standard
simply mentions "octets."

In other words, if these SSID octets are not UTF-8-friendly, how might they
be sent in a HELD request?

Reference:

http://standards.ieee.org/getieee802/download/802.11-2007.pdf

(see "7.3.2.1 SSID element" )

--John B.

From: "Thomson, Martin" <[email-masked]>

Date: September 5, 2010 10:59:39 PM EDT

To: "[email-masked]" <[email-masked]>

Subject: Re: [Geopriv] I-D
Action:draft-ietf-geopriv-held-measurements-01.txt

- The schemas have been moved to the end of the document. [S8]
- The 802.11 measurements have been altered based on discussions with Gabor
and others to include [S5.3]: 
  o WAP -> AP (terminology change)
  o A "verified" attribute for the BSSID
  o A "band" element that identifies the frequency band
  o An antenna identifier for the access point
  o Flight time in place of round trip.  Round trip time measurement is
adversely affected by scheduling delays; flight time measurement is what is
being adopted by the IEEE.
- The draft now describes how individual measurements could be better than
reporting an average value. [S4.2]
- An update to the MAC address, allowing for EUI-64. [S8.3]
- A description of attacks that involve altering the measured phenomenon,
such as the broadcasting of a spoofed GPS signal. [S7.1.5]
- Correction to measurement schema for identifying the source of data [S8.1]

--Martin

-----Original Message-----

Cc: [email-masked]

01.txt

A New Internet-Draft is available from the on-line Internet-Drafts

directories.

This draft is a work item of the Geographic Location/Privacy Working

Group of the IETF.

          Pages           : 73

          Date            : 2010-09-05

...
_______________________________________________
Geopriv mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/geopriv

---

From: "Thomson, Martin" <[email-masked]>
Date: Tue, 7 Sep 2010 07:19:31 +0800

Good question.  It’s easy to forget that SSID can contain sequences of octets that wouldn’t be able to be represented in a textual format.

That leaves a choice: either use something like hexBinary or base64 encoding, which would be unfriendly for the majority of cases where the value truly is textual, or define an encoding scheme.

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

I had to do a similar thing for NAI, which is similarly challenged.  Of course, this needs to be specified…

--Martin

From: [email-masked] [mailto:[email-masked]] On Behalf Of John R. Bressler
Sent: Tuesday, 7 September 2010 3:28 AM
To: [email-masked]
Subject: Re: [Geopriv] I-D Action:draft-ietf-geopriv-held-measurements-01.txt

How should clients handle WiFi measurements with non-ASCII SSID values? HELD is required to use UTF-8, however the 802.11 standard does not appear to restrict SSIDs to ASCII, UTF-8,  or even printable characters.  The standard simply mentions “octets.”

In other words, if these SSID octets are not UTF-8-friendly, how might they be sent in a HELD request?

Reference:
http://standards.ieee.org/getieee802/download/802.11-2007.pdf
(see “7.3.2.1 SSID element” )

--John B.

From: "Thomson, Martin" <[email-masked]<mailto:[email-masked]>>
Date: September 5, 2010 10:59:39 PM EDT
To: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: Re: [Geopriv] I-D Action:draft-ietf-geopriv-held-measurements-01.txt

--Martin

-----Original Message-----
From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]] On
Behalf Of [email-masked]<mailto:[email-masked]>
Sent: Monday, 6 September 2010 11:00 AM
To: [email-masked]<mailto:[email-masked]>
Cc: [email-masked]<mailto:[email-masked]>
Subject: [Geopriv] I-D Action:draft-ietf-geopriv-held-measurements-
01.txt

[email-masked]<mailto:[email-masked]>