idnits 2.17.1
draft-caufield-paws-protocol-for-tvws-01.txt:
Checking boilerplate required by RFC 5378 and the IETF Trust (see
https://trustee.ietf.org/license-info):
----------------------------------------------------------------------------
No issues found here.
Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt:
----------------------------------------------------------------------------
No issues found here.
Checking nits according to https://www.ietf.org/id-info/checklist :
----------------------------------------------------------------------------
** There are 75 instances of too long lines in the document, the longest
one being 30 characters in excess of 72.
== There are 1 instance of lines with non-RFC2606-compliant FQDNs in the
document.
Miscellaneous warnings:
----------------------------------------------------------------------------
== The copyright year in the IETF Trust and authors Copyright Line does not
match the current year
-- The document date (October 31, 2011) is 4561 days in the past. Is this
intentional?
Checking references for intended status: Experimental
----------------------------------------------------------------------------
-- Looks like a reference, but probably isn't: '0' on line 551
-- Looks like a reference, but probably isn't: '360' on line 551
** Obsolete normative reference: RFC 2426 (Obsoleted by RFC 6350)
== Outdated reference: A later version (-15) exists of
draft-ietf-paws-problem-stmt-usecases-rqmts-00
Summary: 2 errors (**), 0 flaws (~~), 3 warnings (==), 3 comments (--).
Run idnits with the --verbose option for more detailed information about
the items above.
--------------------------------------------------------------------------------
2 PAWS J. Caufield
3 Internet-Draft Key Bridge
4 Intended status: Experimental October 31, 2011
5 Expires: May 3, 2012
7 Protocol to query a White Space Database
8 draft-caufield-paws-protocol-for-tvws-01.txt
10 Abstract
12 Regulatory entities in many countries are making spectrum previously
13 used by television stations available for secondary use as a result
14 of the switch from analog to digital. The spectrum in such cases is
15 still owned by the primary user to whom it is licensed. However
16 parts of the spectrum may be unused at a given location or time and
17 hence can be made available for secondary use. In order to use such
18 spectrum a device has to query a database in order to obtain a list
19 of available channels or spectrum at a given location and time. This
20 document specifies protocol elements that can be used to query a
21 white space database and obtain a response by a device.
23 Status of this Memo
25 This Internet-Draft is submitted in full conformance with the
26 provisions of BCP 78 and BCP 79.
28 Internet-Drafts are working documents of the Internet Engineering
29 Task Force (IETF). Note that other groups may also distribute
30 working documents as Internet-Drafts. The list of current Internet-
31 Drafts is at http://datatracker.ietf.org/drafts/current/.
33 Internet-Drafts are draft documents valid for a maximum of six months
34 and may be updated, replaced, or obsoleted by other documents at any
35 time. It is inappropriate to use Internet-Drafts as reference
36 material or to cite them other than as "work in progress."
38 This Internet-Draft will expire on May 3, 2012.
40 Copyright Notice
42 Copyright (c) 2011 IETF Trust and the persons identified as the
43 document authors. All rights reserved.
45 This document is subject to BCP 78 and the IETF Trust's Legal
46 Provisions Relating to IETF Documents
47 (http://trustee.ietf.org/license-info) in effect on the date of
48 publication of this document. Please review these documents
49 carefully, as they describe your rights and restrictions with respect
50 to this document. Code Components extracted from this document must
51 include Simplified BSD License text as described in Section 4.e of
52 the Trust Legal Provisions and are provided without warranty as
53 described in the Simplified BSD License.
55 Table of Contents
57 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
58 2. Terminology and Abbreviations . . . . . . . . . . . . . . . . 3
59 3. Background . . . . . . . . . . . . . . . . . . . . . . . . . . 3
60 4. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 4
61 5. Protocol approach . . . . . . . . . . . . . . . . . . . . . . 4
62 6. Data Model details . . . . . . . . . . . . . . . . . . . . . . 5
63 6.1. White Space Query Object . . . . . . . . . . . . . . . . . 5
64 6.1.1. Query object definition . . . . . . . . . . . . . . . 5
65 6.2. White Space Response Object . . . . . . . . . . . . . . . 6
66 6.2.1. Response Object Definition . . . . . . . . . . . . . . 6
67 6.3. Elements of the Query and Response objects . . . . . . . . 7
68 6.3.1. Station element . . . . . . . . . . . . . . . . . . . 7
69 6.3.2. Schedule element . . . . . . . . . . . . . . . . . . . 7
70 6.3.3. ChannelList element . . . . . . . . . . . . . . . . . 8
71 6.3.4. ContactList element . . . . . . . . . . . . . . . . . 8
72 6.3.5. Location element . . . . . . . . . . . . . . . . . . . 8
73 6.3.6. Antenna element . . . . . . . . . . . . . . . . . . . 8
74 6.3.7. StationRxList element . . . . . . . . . . . . . . . . 9
75 6.3.8. TransmitterList element . . . . . . . . . . . . . . . 9
76 6.3.9. Address element . . . . . . . . . . . . . . . . . . . 9
77 6.3.10. Coordinate element . . . . . . . . . . . . . . . . . . 10
78 6.3.11. RadiationPattern element . . . . . . . . . . . . . . . 10
79 6.3.12. Contact Element . . . . . . . . . . . . . . . . . . . 10
80 6.3.13. Extension element . . . . . . . . . . . . . . . . . . 10
81 6.3.14. WhiteSpaceFrequencyList element . . . . . . . . . . . 11
82 6.3.15. WhiteSpaceFrequency element . . . . . . . . . . . . . 11
83 6.3.16. Channel Element . . . . . . . . . . . . . . . . . . . 11
84 6.3.17. Transmitter Element . . . . . . . . . . . . . . . . . 12
85 6.4. Attributes definition . . . . . . . . . . . . . . . . . . 13
86 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19
87 8. Security Considerations . . . . . . . . . . . . . . . . . . . 19
88 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 19
89 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 19
90 10.1. Normative References . . . . . . . . . . . . . . . . . . . 19
91 10.2. Informative References . . . . . . . . . . . . . . . . . . 20
92 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 20
94 1. Introduction
96 Regulatory entities in many countries are making spectrum previously
97 used by television stations available for secondary use as a result
98 of the switch from analog to digital. The spectrum in such cases is
99 still owned by the primary user to whom it is licensed. However
100 parts of the spectrum may be unused at a given location or time and
101 hence can be made available for secondary use. In order to use such
102 spectrum a device has to query a database in order to obtain a list
103 of available channels or spectrum at a given location and time. This
104 document specifies protocol elements that can be used to query a
105 white space database and obtain a response by a device.
107 The problem statement, use cases and requirements for the use of
108 white space spectrum and the associated protocol is captured in the
109 document: [I-D.ietf-paws-problem-stmt-usecases-rqmts].
111 2. Terminology and Abbreviations
113 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
114 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
115 document are to be interpreted as described in [RFC2119].
117 This document relies on the terminology specified in
118 [I-D.ietf-paws-problem-stmt-usecases-rqmts].
120 3. Background
122 Spectrum is a scarce resource and hence it is essential that
123 technology provide a means to use this resource in an optimal manner.
124 Spectrum has been generally licensed or granted or reserved for
125 specific use by regulatory bodies and governments. Some spectrum
126 such as the ISM band has been made publicly available for use without
127 any licenses but still with a set of regulations. In many cases
128 spectrum that has been licensed to an entity or reserved is either
129 not utilized or under utilized. As the demand for services over
130 wireless medium continues to grow the need for additional spectrum is
131 increasing. Cognitive radio and white space technology is a solution
132 that allows the use of spectrum by a secondary user at a given
133 location if the primary user is either not using the spectrum at a
134 given time and without causing interference to the primary user.
135 Regualtions to this effect have been specified by the FCC in the US
136 and other regulatory bodies in many other countries are also studying
137 similar approaches for parts of the spectrum.
139 One of the approaches to determining if spectrum is available at a
140 given location and time is to query a centralized database and obtain
141 information about what channels or spectrum can be used. There may
142 exist multiple databases from which such information can be obtained.
143 A standardized query/response mechanism is in the scope of the PAWS
144 working group. This document proposes a data format for the query
145 and response aspects of the protocol.
147 4. Problem Statement
149 The query/response protocol to obtain information about available
150 channels or spectrum can be specified using various means. LDAP is
151 an example of a protocol that can be used for this purpose. However
152 one of the objectives of this protocol is to ensure that it is
153 globally applicable and can be adapted for use in various regulatory
154 environments. The elements of the query and response can vary
155 depending on the country or region where a device is making a query
156 to a database. As a result of this objective, flexibility of the
157 protocol in terms of the attributes and parameters carried in the
158 query and response are quite important.
160 5. Protocol approach
162 This document does not specify the complete protocol itself. The
163 protocol can be split into three parts:
165 1. The data model
166 2. The transport protocol
167 3. The security solution
169 A data model for the query/response protocol is proposed in this
170 document. A hierarchical object model approach is used for defining
171 the query/response and its attributes. The figure below is a high-
172 level view of how the data model is structured:
174 -------------
175 |WS Protocol|
176 -------------
177 |
178 |
179 -------------------------------------
180 | |
181 --------- ------------
182 |wsQuery| |wsResponse|
183 --------- ------------
184 | |
185 ---------- ----------
186 |Element1| ...5, 6, 7 |Elementx| ... y,z
187 ---------- . . . ---------- . .
188 | . . . | . .
189 ------------ . . . ------------ . .
190 |Attributes| o o o o o |Attributes| o o o
191 ------------ ------------
193 Figure 1: Data Model
195 6. Data Model details
197 The data model includes two main objects, the wsQuery and wsResponse
198 objects. Each of these objects contain a list of elements. The
199 elements are further comprised of attributes. The wsQuery object is
200 sent by a WS Master device to a database and the database responds
201 with a wsResponse object. The actual message and header in which
202 this object is carried is not specified here and is expected to be
203 specified elsewhere. Neither does this document specify how the
204 device discovers the database or how the object is transported or
205 secured.
207 6.1. White Space Query Object
209 The whitespaceQuery object is a data object carried in a request
210 message that any white space client (e.g. a white space device,
211 software application, coexistence manager, etc.) may use to request
212 information from a white space database, as part of a Rules-compliant
213 data transaction.
215 6.1.1. Query object definition
216
217
218
219
220
221
222
223
224
225
227 whitespaceQuery Object
229 6.2. White Space Response Object
231 A whitespaceResponse object is a generalized message response
232 structure that any white space administrator (e.g. a white space
233 database implementation) may use to communicate white space
234 information in a Rules-compliant data transaction.
236 The whitespaceResponse object structure is intended to accommodate
237 various responses to information queries from different white space
238 client such as, for example, white space devices (for transmission),
239 management systems (not for transmission) and consumers (not for
240 transmission).
242 6.2.1. Response Object Definition
244
245
246
247
249
250
251
252
253
254
255
256
257
258
259 whitespaceResponse Object
261 6.3. Elements of the Query and Response objects
263 The whitespaceQuery and whitespaceResponse objects include multiple
264 elements. Some of the elements are common across the query and
265 response objects. The following sections define these elements.
267 6.3.1. Station element
269 A WSIF station object contains information about the inquiring
270 station including antenna, location, transmitter details, etc.
272
273
274
275
276
277
278
279
281
283
285
289
290
291
292
293
294
295
297 Station Element
299 6.3.2. Schedule element
301 Type: Schedule
303 A schedule object is used by white space devices to request temporary
304 spectrum access (i.e. less than 24 hours). The schedule element is
305 intended to enable the recording, persistence and distribution of
306 standardized iCalendar-compatible messages. The format of the
307 Schedule object is defined in [RFC5545].
309 6.3.3. ChannelList element
311 Type: Channel
313 A list of channels (i.e. frequency ranges) that are occupied by the
314 transmitter(s) at this station.
316 6.3.4. ContactList element
318 Type: Contact
320 A list of contacts associated with this station. For example, a
321 facility or on-site technical manager, administrator, and operational
322 contacts may be identified.
324 6.3.5. Location element
326 This element describes the station's physical and geographic
327 location.
329
330
331
332
333
334
335
336
337
338
339
340
342 Location Element
344 6.3.6. Antenna element
346 A description of this station's (transmit or receive) antenna,
347 including the required antenna parameters like pointing and elevation
348 information plus the radiation pattern.
350
351
352
353
354
355
356
357
358
359
360
361
362
363
365 Antenna Element
367 6.3.7. StationRxList element
369 Type: Station
371 For wireless services that include multiple stations, and especially
372 for wireless services with multiple TXRX stations, each receiving
373 station may indicate its respective upstream transmitting stations by
374 adding that transmitting station to this receiving stationis
375 rxStationList element. Example uses of this element include
376 Television translator stations, MVPD receive sites, etc.
378 6.3.8. TransmitterList element
380 Type: Transmitter
382 A station may support multiple transmitters operating within the same
383 geographic area and on the same schedule. For example, several
384 wireless microphones may operate simultaneously within the geographic
385 contour defined within this stationis location element. If the
386 stationType attribute indicates this station is receive-only then
387 this element SHOULD be null.
389 6.3.9. Address element
391 Type: Address
393 This element specifies the civic location of the station. The
394 structure of this element is described in [RFC5139].
396 6.3.10. Coordinate element
398 Type: Coordinate
400 this element specifies the geolocation of the station. The structure
401 of this element is described in [RFC5491].
403 6.3.11. RadiationPattern element
405 Type: RadiationPattern
407 A radiation pattern representing the directional (azimuth) dependence
408 of the strength of the radio signal from the antenna. The
409 radiationPattern represents the directional (azimuth) dependence of
410 the strength of the radio signal from the antenna.
412 A WKT MULTIPOINT SFA Geometry implementation. The azimuthal field
413 values are encoded as a well known text (WKT) MULTIPOINT object with
414 [azimuth, radial value] pairs encoded according to the format
415 POINT(x,y) = POINT(azimuth, field_value).
417
418
419
420
421
422
423
424
426 RadiationPattern Element
428 6.3.12. Contact Element
430 The contact represents a generalized container for individual
431 (person) and company (organization) contact information. The
432 structure of this element is defined in [RFC2426].
434 6.3.13. Extension element
436 Type: xs:string
438 A URL-ENCODED string containing key/value pairs that requesting
439 devices may implement and administrators may support at their
440 discretion to provide supplementary information or to otherwise
441 extend this object.
443 6.3.14. WhiteSpaceFrequencyList element
445 Contains a complete and canonical list of available and valid white
446 space frequencies that is appropriate for the inquiring message's
447 criterion. For white space devices, the whitespaceFrequencyList
448 element represents all channels available for unlicensed operation at
449 the inquiring deviceis location or indicated geographic area and
450 according to the schedule in this element.Contains one or more
451 occurencies of WhiteSpaceFrequency elements.
453 6.3.15. WhiteSpaceFrequency element
455
456
457
458
459
460
461
462
463
464
466 WhiteSpaceFrequency Element
468 6.3.16. Channel Element
470 A channel describes a fully qualified and canonical frequency range.
471 Channel object definitions support positive definitions of colloquial
472 channel identifiers (e.g. TV channel 24) through identification of
473 the authorizing regulatory definition and the TV channelis frequency
474 range.
476
477
478
479
480
481
483 Channel Element
485 6.3.17. Transmitter Element
487 The transmitter object provides an extensible software template to
488 contain and exchange required and optional but otherwise useful
489 transmitter information.
491 A transmitter provides an object template for common device-related
492 attributes and may be optionally used directly or, more likely, may
493 be extended by other, more specific transmitter descriptions that
494 fully describe a certain type wireless device. For this reason all
495 transmitter attributes and elements are defined as optional by
496 default. Attribute and element validity is expected to be defined in
497 transmitter-derived objects. The transmitter is designed to support,
498 through extension, the communication of required and optional but
499 otherwise useful information about licensed and unlicensed wireless
500 devices including transmitters, receivers and transceivers.
502
503
504
505
506
507
508
509
510
511
512
513
514
515
516
517
518
519
520
521
522
523
524
526 Transmitter Element
528 6.4. Attributes definition
530 This section defines the attributes which are included in the various
531 elements of the whitespacequery or whitespaceresponse objects.
533 Channel attribute
534 Type: xs: boolean
535 Description: An indicator for whether the radiationPattern element
536 of this object contains interpolated values.
538 Source attribute
539 Type: xs:string
540 Description: The originating source of the data represented in the
541 radiationPattern element. An example value for this attribute is
542 ius.fcc.cdbsi.
544 Directional attribute
545 Type: xs:boolean
546 Descrition: Indicates whether the antenna is directional (true) or
547 non-directional (false).
549 Rotation attribute
550 Type: xs:float
551 Description: Indicates the offset in degrees azimuth [0, 360] from
552 true North that the antenna radiation pattern should be rotated.
554 HeightAboveGround attribute
555 Type: xs:float
556 Description: The antenna radiation center height above ground
557 level.
559 Manufacturer attribute
560 Type: xs:string
561 Description: The antenna manufacturer
563 x-elevantModel attribute
564 Type: xs:string
565 Description: The digital elevation model used to calculate this
566 antenna objectis HAAT (x-haat) and rcAMSL (x-rcAmsl) values.
568 x-govtAntennaId attribute
569 Type: xs:int
570 Description: A reference to the antenna ID record within FCC CDBS
572 x-haat attribute
573 Type: xs:float
574 Description: The antenna height above average terrain
576 x-rcAmsl attribute
577 Type: xs:float
578 Description: The antenna radiation center above mean sea level
580 Frequency attribute
581 Type: xs:double
582 Description: If a specific frequency has been assigned to this
583 transmitter that information may be recorded here in MHz. If only
584 the channel is provided then the assignedFrequency value is set to
585 the center frequency of this transmitteris channel.
587 deviceID attribute
588 Type: xs:string
589 Description: The transmitter device's Government provided
590 identifier.
592 deviceSn attribute
593 Type: xs:string
594 Description: the transmitting device's manufacturer-provided
595 serial number.
597 ea attribute
598 Type: xs:string
599 Description: The Government equipment authorization agency from
600 which this device is authorized to operate and which issued the
601 device ID.
603 erp attribute
604 Type: xs: float
605 Description: The transmitting deviceis current effective radiated
606 power (ERP), measured in dBw.
608 isDigital attribute
609 Type: xs:boolean
610 Description: Indicates whether this transmitter is sending a
611 digital (TRUE) or analog (FALSE) carrier.
613 manufacturer attribute
614 Type: xs:string
615 Description: the device manufacturer company name
617 Model attribute
618 Type: xs:string
619 Description: the antenna product model
621 allocation attribute
622 Type: xs:string
623 Description:A dot-delimited reverse domain encoded description of
624 the frequency allocation defined according the following strategy:
625 [country].[regulator].[allocation].[band range]
626 For example, the UHF-high block allocation of TV channels 38 to 51
627 within the United States is identified as "us.fcc.broadcast.614-
628 698".
630 channel attribute
632 Type: xs:float
633 Description: The colloquial channel number
634 Note: A FLOAT number type is used to accommodate future sub-
635 channelization. For the avoidance of doubt channel numbers ending
636 in zero shall be interpreted to represent a whole channel. i.e.
637 float value channel 38.0 is equivalent to integer-value channel
638 38.
640 effectiveDate attribute
642 Type: xs:dateTime
643 Description: The date and time when this white space information
644 should be considered effective. The value may be set in the
645 future to accommodate frequencies that may become available at a
646 later date or time.
648 expirationDate attribute
650 Type: xs:dateTime
651 Description: The date and time when this white space information
652 expires.
654 locationType attribute
656 Type: xs:string
657 Description: A descriptor string used to classify and organize
658 locations. If the location is derived from another database
659 source, this attribute is a dot-delimited string used to identify
660 this location type and its source. An example value for this
661 attribute is "us.fcc.cdbs.stationClass.CDT".
663 maxEIRP attribute
665 Type: xs:float
666 Description: The maximum allowable equivalent isotripically
667 radiated power (EIRP) that a white space device may transmit on
668 the indicated channel. Provided in dBW.
670 maxFreq attribute
672 Type: xs:double
673 Description: The maximum (or end) frequency of the indicated
674 channel in MHz.
676 messageType attribute
678 Type: xs:string
679 Description: An enumerated message type. Allowed message types
680 are:
681 Message code: ws.messageType.TVBD.QUERY
682 Description: The message is a certified client-initiated query for
683 white space frequency information for the purposes of
684 transmission. Examples of certified clients include FCC-certified
685 white space devices and other devices authorized to operate within
686 the band (e.g. wireless microphones, medical telemetry, PLMRS
687 systems, etc.)
688 Message code: ws.messageType.TVBD.RESPONSE
689 Description: The message is a response to a TVBD.QUERY request for
690 information.
691 Message code: ws.messageType.INFORMATION.QUERY
692 Description: The message is a non-certified client-initiated query
693 for general (possibly white-space) frequency information NOT for
694 the purposes of transmission. Examples of non-certified clients
695 include network management and planning systems, client software
696 applications, etc.
697 Message code: ws.messageType.INFORMATION.RESPONSE
698 Description: The message is a response to an INFORMATION.QUERY
699 request for information.
701 minFreq attribute
703 Type: xs:double
704 Description: The minimum (or start) frequency of the indicated
705 channel in MHz.
707 name attribute
708 Type: xs:string
709 Description: A human readable name or label that may be used to
710 identify a location or station. A useful hint is to use a
711 memorable place name as might be represented on a map (e.g.
712 "Empire State Building"). For licensed wireless services it is
713 recommended to use the facility call sign. For unlicensed
714 wireless services it is recommended to use the venue name.
716 protocolVersion attribute
718 Type: xs:float
719 Description: The message protocol version.
721 stationClass attribute
723 Type: xs:string
724 Description: Indicates the station classification. Classification
725 may be used to determine whether and how many elements of this
726 station are required for validation. Allowed values are:
727 TX. This is a transmitting station and a transmitter is required
728 in the transmitterList element
729 RX. This is a receive-only station and a transmitter element is
730 NOT required
731 TXRX. This station is able to both transmit and receive and a
732 transmitter is required in the transmitterList element.
734 stationType attribute
736 Type: xs:string
737 Description: A description of this station's operation.
739 statusIndicator attribute
741 Type: xs:int
742 Description: The number of available white space channels included
743 in the message. A negative value indicates that an error
744 condition has occured.
746 timeStamp attribute
748 Type: xs:dateTime
749 Description: When the message was created.
751 uuid attribute
753 Type: xs:string
754 Description (for use in Location):A universally unique identifier
755 (UUID) associated with and permanently assigned to this location.
756 Description (for use in Station):A universally unique identifier
757 (UUID) associated with and permanently assigned to this station.
758 Description (for use in whitespaceFrequency): A universally unique
759 idenfifier (UUID) assigned by an Administrator that is associated
760 with this freuquency
761 Description (for use in whitespaceQuery): A universally unique
762 identifier (UUID) created by the inquiring agent (i.e. a TV band
763 device, user software, etc.) and associated with this whitespace
764 query message. This uuid may be used to correlate a
765 whitespaceResponse message with this whitespaceQuery and to
766 simplify logging and archival.
767 Description (for use in whitespaceResponse): A universally unique
768 identifier (UUID), set to match the client's whitespaceQuery.uuid
769 attribute and to simplify logging and arhival.
771 x-geocode attribute
773 Type: xs:string
774 Description: An enumerated value indicating whether any one of
775 this location object's components have been calculated according
776 to another of this location object's set parameters.
777 Allowed values are:
778 NO (xs:string) (DEFAULT). The coordinate, address and geometry
779 elements of this location are not correlated.
780 GC (xs:string). The coordinate.[longitude, latitude] and
781 geometry.point values have been calculated and set according to a
782 Geo-coding algorithm from the address.
783 RG (xs:string). The address has been calculated and set according
784 to a Reverse Geo-coding algorithm from the coordinate.[longitude,
785 latitude] value.
787 x-haat attribute
789 Type: xs:float
790 Description: The ground height above average terrain value at this
791 location's coordinates, calculated according to the methodology
792 described in 47 CFR 73.684(d). The elevation model used in the
793 calculation of this location attribute is recorded in the
794 coordinate.x-elevationModel attribute. This value is used to
795 support TVBD transmit antenna compliance with 15.709(b)(2), which
796 states that the ground level HAAT must be below 76 meters.
798 x-timeZone attribute
799 Type: xs:string
800 Description: The local time zone at this location. Two
801 interchangeable formats are supported, with the zoneinfo format
802 preferred:
803 The zoneinfo database format (e.g. "America/New_York")
804 An offset to Coordinated Universal Time (e.g. "UTC-05:00" or
805 "UTC-5"
806 Note: Three-character notation (e.g. "EDT") is not supported.
808 7. IANA Considerations
810 This document will require actions on the part of IANA to assign
811 values for the new messages and attributes.
813 8. Security Considerations
815 This document defines the data model for the database query and
816 response protocol to be used between white space devices and a
817 database. The actual security for the messages that transport these
818 objects needs to be specified in the relevant document.
820 9. Acknowledgements
822 This document has been made possible as a result of the efforts of
823 Basavaraj Patil and Scott Probasco.
825 10. References
827 10.1. Normative References
829 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
830 Requirement Levels", BCP 14, RFC 2119, March 1997.
832 [RFC2426] Dawson, F. and T. Howes, "vCard MIME Directory Profile",
833 RFC 2426, September 1998.
835 [RFC5139] Thomson, M. and J. Winterbottom, "Revised Civic Location
836 Format for Presence Information Data Format Location
837 Object (PIDF-LO)", RFC 5139, February 2008.
839 [RFC5491] Winterbottom, J., Thomson, M., and H. Tschofenig, "GEOPRIV
840 Presence Information Data Format Location Object (PIDF-LO)
841 Usage Clarification, Considerations, and Recommendations",
842 RFC 5491, March 2009.
844 [RFC5545] Desruisseaux, B., "Internet Calendaring and Scheduling
845 Core Object Specification (iCalendar)", RFC 5545,
846 September 2009.
848 10.2. Informative References
850 [I-D.ietf-paws-problem-stmt-usecases-rqmts]
851 Probasco, S., Bajko, G., Patil, B., and B. Rosen,
852 "Protocol to Access White Space database: PS, use cases
853 and rqmts", draft-ietf-paws-problem-stmt-usecases-rqmts-00
854 (work in progress), September 2011.
856 Author's Address
858 Jesse Caufield
859 Key Bridge
860 1600 Tysons Blvd, Suite 450
861 McLean VA 22102
862 USA
864 Email: jesse.caulfield@keybridgeglobal.com