idnits 2.17.1 draft-royer-timezone-registry-03.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 14. -- Found old boilerplate from RFC 3978, Section 5.5 on line 673. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 650. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 657. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 663. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There are 6 instances of too long lines in the document, the longest one being 16 characters in excess of 72. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords -- however, there's a paragraph with a matching beginning. Boilerplate error? RFC 2119 keyword, line 218: '...-point from that character set MUST be...' RFC 2119 keyword, line 251: '...e: This property MUST be specified in ...' RFC 2119 keyword, line 260: '...ing applications MUST supply the 'tzre...' RFC 2119 keyword, line 313: '... registered TZID MUST BE unique in the...' RFC 2119 keyword, line 330: '... be unique. Each "NAME" property MUST...' (6 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (August 9, 2005) is 6807 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Looks like a reference, but probably isn't: 'TZ' on line 591 == Unused Reference: '2' is defined on line 604, but no explicit reference was found in the text == Unused Reference: '3' is defined on line 608, but no explicit reference was found in the text == Unused Reference: '6' is defined on line 619, but no explicit reference was found in the text == Unused Reference: '8' is defined on line 625, but no explicit reference was found in the text -- Possible downref: Non-RFC (?) normative reference: ref. '1' -- Possible downref: Non-RFC (?) normative reference: ref. '2' -- Possible downref: Non-RFC (?) normative reference: ref. '3' -- Possible downref: Non-RFC (?) normative reference: ref. '4' -- Possible downref: Non-RFC (?) normative reference: ref. '5' -- Possible downref: Non-RFC (?) normative reference: ref. '6' -- Possible downref: Non-RFC (?) normative reference: ref. '7' -- Possible downref: Non-RFC (?) normative reference: ref. '8' Summary: 7 errors (**), 0 flaws (~~), 6 warnings (==), 16 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group D. Royer 3 Internet-Draft IntelliCal LLC 4 Expires: February 10, 2006 August 9, 2005 6 Time Zone Registry 7 draft-royer-timezone-registry-03 9 Status of this Memo 11 By submitting this Internet-Draft, each author represents that any 12 applicable patent or other IPR claims of which he or she is aware 13 have been or will be disclosed, and any of which he or she becomes 14 aware will be disclosed, in accordance with Section 6 of BCP 79. 16 Internet-Drafts are working documents of the Internet Engineering 17 Task Force (IETF), its areas, and its working groups. Note that 18 other groups may also distribute working documents as Internet- 19 Drafts. 21 Internet-Drafts are draft documents valid for a maximum of six months 22 and may be updated, replaced, or obsoleted by other documents at any 23 time. It is inappropriate to use Internet-Drafts as reference 24 material or to cite them other than as "work in progress." 26 The list of current Internet-Drafts can be accessed at 27 http://www.ietf.org/ietf/1id-abstracts.txt. 29 The list of Internet-Draft Shadow Directories can be accessed at 30 http://www.ietf.org/shadow.html. 32 This Internet-Draft will expire on February 10, 2006. 34 Copyright Notice 36 Copyright (C) The Internet Society (2005). 38 Abstract 40 This is a submission for the creation of an new IANA Time Zones 41 registration process. This is intended to be a central repository 42 for time zone names. The registry does not presume to be the 43 authority for time zone information or rules. This register is 44 simply a place where time zone names may be registered for public 45 access. This registery only registers time zone names. The 46 description of the time zone is not included in this memo. Vendors 47 and services companies can elect to provide time zone servers that 48 publish time zone information details. 50 Table of Contents 52 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 53 2. Basic Grammar and Conventions . . . . . . . . . . . . . . . . 5 54 2.1 Formatting Conventions . . . . . . . . . . . . . . . . . . 5 55 2.2 Related Memos . . . . . . . . . . . . . . . . . . . . . . 6 56 2.3 International Considerations . . . . . . . . . . . . . . . 6 57 3. Security Considerations . . . . . . . . . . . . . . . . . . . 7 58 4. Interoperability Considerations . . . . . . . . . . . . . . . 8 59 5. Registry TZID Value . . . . . . . . . . . . . . . . . . . . . 9 60 6. Registry NAME . . . . . . . . . . . . . . . . . . . . . . . . 11 61 7. Registry TZURL Value . . . . . . . . . . . . . . . . . . . . . 13 62 7.1 Fetching a specific version of a VTIMEZONE . . . . . . . . 14 63 8. Fetching the newest version of a VTIMEZONE . . . . . . . . . . 15 64 9. iCalendar VTIMEZONE registry . . . . . . . . . . . . . . . . . 16 65 10. AREA parameter . . . . . . . . . . . . . . . . . . . . . . . 17 66 11. Specifying geographic area covered - POLYGON . . . . . . . . 18 67 12. Initial Time Zones . . . . . . . . . . . . . . . . . . . . . 21 68 13. Updating Time Zones . . . . . . . . . . . . . . . . . . . . 22 69 14. References . . . . . . . . . . . . . . . . . . . . . . . . . 22 70 Author's Address . . . . . . . . . . . . . . . . . . . . . . . 22 71 Intellectual Property and Copyright Statements . . . . . . . . 23 73 1. Introduction 75 Many software vendors create time zone information for their 76 applications. This information can sometimes be inconsistent with 77 other applications or contain insufficient information when referring 78 to times far in the past or future. By creating an IANA registry, 79 the time zone name information will be available to any vendor. 81 This memo will be discussed on the timezone@INET-Consulting.com 82 mailing list ( http://inet-consulting.com/mailman/listinfo/timezone 83 ). 85 In addition there is revision control in this memo so vendors will 86 know if they have the latest data. This document uses the iCalendar 87 "LAST-MODIFIED" property in the iCalendar "VTIMEZONE" calendar 88 component to track revisions of the data. Each time zone has a 89 unique iCalendar time zone identifier (TZID) that will be registered 90 with IANA. Then any compliant application may then contact any time 91 zone server to get the details of the time zone. 93 The initial information in the registry will be from the [TZ] 94 database. And new iCalendar properties are defined in this memo. 96 When applications create information using a time zone is critical 97 that the using applications have the same definitions of the time 98 zone in order for the instances in time to match. For that reason 99 the "TZID" property value will contain the revision information of 100 the time zone name and the "TZURL" value will point to the specific 101 revision of the time zone data. 103 When an iCalendar component is created, the originating software 104 specifies the TZID, determines the revision they is being used, and 105 include that TZID and revision information in the objects so that 106 consumers of the objects know exactly which time zone definition and 107 revision was used by the originator. And from that TZID a using 108 application can find the most up to date version of a time zone 109 definition. 111 The "TZID" property values are broken down into parts; region, 112 optional sub-regons, city, and revision. And they are separated 113 using the slash (/) (ascii decimal value 47) character. 115 This example is using the factious America/BosieLike time zone that 116 was registered on January 15th, 2005 at 6:17:22 PM UTC: 118 BEGIN:VCALENDAR 119 PRODID:-//INTELLICAL.COM//NONSGML TZ VTIMEZONE DATABASE//EN 120 VERSION:2.0 121 METHOD:PUBLISH 122 BEGIN:VTIMEZONE 123 TZID:/IANA.ORG/TimeZone/America/BoiseLike/20050115T181722Z 124 TZURL:ftp://example.com/TimeZone/America/BoiseLike.ics 125 LAST-MODIFIED:20050115T181722Z 126 BEGIN:STANDARD 127 TZOFFSETFROM:-0600 128 TZOFFSETTO:-0700 129 TZNAME:MST 130 DTSTART:19701025T020000 131 RRULE:FREQ=YEARLY;BYMONTH=10;BYDAY=-1SU 132 END:STANDARD 133 BEGIN:DAYLIGHT 134 TZOFFSETFROM:-0700 135 TZOFFSETTO:-0600 136 TZNAME:MDT 137 DTSTART:19700405T020000 138 RRULE:FREQ=YEARLY;BYMONTH=4;BYDAY=1SU 139 END:DAYLIGHT 140 END:VTIMEZONE 141 END:VCALENDAR 143 2. Basic Grammar and Conventions 145 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 146 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY" and 147 "OPTIONAL" in this document are to be interoperated as described in 148 [4]. 150 The notation used in this memo is the ABNF notation of [5]. Readers 151 intending on implementing this format defined in this memo should be 152 familiar with this notation in order to properly interpret the 153 specifications of this memo. 155 All numeric and hexadecimal values used in this memo are given in 156 decimal notation. 158 All names of properties, property parameters, enumerated property 159 values and property parameter values are case-insensitive. However, 160 all other property values are case-sensitive, unless otherwise 161 stated. 163 Note: All indented editorial notes, such as this one, are intended 164 to provide the reader with additional information. The 165 information is not essential to the building of an implementation 166 conformant with this memo. The information is provided to 167 highlight a particular feature or characteristic of the memo. 169 The format for the iCalendar object is based on the syntax of the [7] 170 content type. While the iCalendar object is not a profile of the [7] 171 content type, it does reuse a number of the elements from the [7] 172 specification. 174 2.1 Formatting Conventions 176 The mechanisms defined in this memo are defined in prose. Many of 177 the terms used to describe these have common usage that is different 178 than the standards usage of this memo. In order to reference within 179 this memo elements of the calendaring and scheduling model, core 180 object [1] some formatting conventions have been used. Calendaring 181 and scheduling roles are referred to in quoted-strings of text with 182 the first character of each word in upper case. For example, 183 "Organizer" refers to a role of a "Calendar User" within the protocol 184 defined by [1]. Calendar components defined by this memo are 185 referred to with capitalized, quoted-strings of text. For example, 186 "VTIMEZONE" refers to the time zone calendar component. Usage of the 187 term 'iCal' in this memo means RFC 2445 . 189 The properties defined by this memo are referred to with capitalized, 190 quoted-strings of text, followed by the word "property". For 191 example, "TZNAME" property refers to the iCalendar property used to 192 convey the display name of the time zone. Property parameters 193 defined by this memo are referred to with lowercase, quoted-strings 194 of text, followed by the word "parameter". For example, "value" 195 parameter refers to the iCalendar property parameter used to override 196 the default data type for a property value. 198 2.2 Related Memos 200 Implementers will need to be familiar with several other memos that, 201 along with this memo. Such as iCalendar [1] specifications. 203 [1] - Specifies the format for the "VTIMEZONE" calendar component. 205 This memo does not attempt to repeat the specification of concepts or 206 definitions from these other memos. Where possible, references are 207 made to the memo that provides for the specification of these 208 concepts or definitions. 210 2.3 International Considerations 212 In the rest of this document, descriptions of characters are of the 213 form "character name (codepoint)", where "codepoint" is from the US- 214 ASCII character set. The "character name" is the authoritative 215 description; (codepoint) is a reference to that character in US-ASCII 216 or US-ASCII compatible sets (for example the ISO-8859-x family, 217 UTF-8, ISO-2022-xx, KOI8-R). If a non-US-ASCII compatible character 218 set is used, appropriate code-point from that character set MUST be 219 chosen instead. 221 3. Security Considerations 223 There are no known security issues with this proposal as this is a 224 repository of information and not an over the wire protocol. 226 4. Interoperability Considerations 228 This document is intended to be compliant with the [iCAL] "VTIMEZONE" 229 calendar component and will interoperate with any implementation that 230 follows that specification. New properties are being registered as 231 part of this memo. 233 5. Registry TZID Value 235 Within the time zone registry, the "TZID" property will be used as 236 follows. This is compatible with the [iCAL] "TZID" property as here 237 we only define the format of the value of the property. 239 Property Name: TZID 241 Purpose: This property specifies the text value that uniquely 242 identifies the "VTIMEZONE" calendar component in the IANA registry. 243 The value is case sensitive and is UTF-8 so it should be able to 244 accomidate any locale. 246 Value Type: TEXT (in the format specified below) 248 Property Parameters: Non-standard property parameters can be 249 specified on this property. 251 Conformance: This property MUST be specified in a "VTIMEZONE" 252 calendar component that complies with this memo. 254 Description: This is the label by which a time zone calendar 255 component is referenced by any iCalendar properties whose data type 256 is either DATE-TIME, DATE, or TIME and not intended to specify a UTC 257 or a "floating" time. The presence of the SOLIDUS character (US- 258 ASCII decimal 47) as a prefix, indicates that this TZID represents an 259 unique ID in a globally defined IANA time zone registry (this 260 specification). Conforming applications MUST supply the 'tzrev' 261 attribute shown below in the "TZID" property value. The "TZID" 262 property value points to a specific version of the time zone. 264 All of the 'tzregion', 'tzcity', and 'tzrev' values are case 265 sensitive. 267 Format Definition: This property is defined by the following 268 notation: 270 tzid = "TZID" tzidpropparam ":" 271 ianatzidprefix 272 "/" tzregion *( "/" tzregion ) 273 "/" tzcity 274 "/" tzrev CRLF 276 tzidpropparam = *(";" xparam) 278 ianatzidprefix = "/IANA.ORG" 280 tzregion = < region names as used in the [TZ] databaee > 281 ; Examples are "Africa", "America", "Asia" 282 ; "Europe", "Indian" "Pacific" 284 tzcity = 286 tzrev = date-time "Z" 288 date-time = 290 Example: The following are examples of globally unique time zone 291 identifiers as defined by this specification: 293 TZID:/IANA.ORG/Indian/Reunion/20050115T112522Z 295 TZID:/IANA.ORG/Pacific/Pago_Pago/20050114T162291Z 297 TZID:/IANA.ORG//America/Indiana/Knox/20050114T162291Z 299 6. Registry NAME 301 One time zone definition may have more than one name or alias. And 302 time zone names might be in a non US-ASCII locale. So this "NAME" 303 property will be allowed multiple time zone names in a "VTIMEZONE" 304 component. By using the iCalenar "LANG" parameter, a "TZID" value 305 can be represented as aliases in muliple locales and multiple names 306 or aliases. 308 For example "PST" could be a alias for "America/Los_Angeles". Note 309 that many of the TZID's in use today are not unique so it is possible 310 that multiple registered TZIDs have aliases that are the same as 311 aliases for other registered TZIDs. This memo and the registration 312 process is inspired by the desire to solve that problem. The 313 registered TZID MUST BE unique in the registry. The "NAME" values do 314 not have to be unique across registered TZID's. 316 Property Name: NAME 318 Purpose: The NAME property allows for a TZID to have many possibly 319 locale specific names or aliases for the same definition. 321 Value Type: TEXT 323 Property Parameters: The "LANG" parameter and non-standard property 324 parameters can be specified on this property. 326 Conformance: This property can be specified in a "VTIMEZONE" calendar 327 component. 329 Description: Multiple NAME properties may be in a "VTIMEZONE" 330 calendar compoennt, each must be unique. Each "NAME" property MUST 331 include a "LANGUAGE" parameter specifing the locale where the "NAME" 332 property value would be used. There may be multiple "NAME" 333 properties with the same "LANGUAGE" parameter value as long as those 334 "NAME" property values are unique. When in a "VTIMEZONE" calendar 335 component then they are alias nams for the "TZID" property value. 336 Note that the "STANDARD" and "DAYLIGHT" calendar components use zero 337 or more of the locale specific "TZNAME" property as aliases as 338 defined in iCalendar. 340 Format Definition: The property is defined by the following notation: 342 aliasname = "NAME" nameparam ":" localeName CRLF 344 nameparam = langparam *(";" xparam) 346 langparam = < As defined in iCalendar > 348 localName = < Single line text used as name or alias of TZID >a 350 Examples. 352 NAME;LANGUAGE=us-EN:PST 353 NAME;LANGUAGE=us-EN:Us/Pacific 355 7. Registry TZURL Value 357 Within the time zone registry, the "TZURL" property will be used as 358 follows. This is compatible with the [iCAL] "TZURL" property as here 359 we only define the format of the value of the property. 361 Property Name: TZURL 363 Purpose: The TZURL provides a means for a VTIMEZONE component to 364 point to a network location that can be used to retrieve an up-to- 365 date version of itself. 367 Value Type: URI 369 Property Parameters: Non-standard property parameters can be 370 specified on this property. 372 Conformance: This property can be specified in a "VTIMEZONE" calendar 373 component. 375 Description: The TZURL provides a means for a VTIMEZONE component to 376 point to a network location that can be used to retrieve an up-to- 377 date version of itself. This provides a hook to handle changes 378 government bodies impose upon time zone definitions. Retrieval of 379 this resource results in an iCalendar object containing a single 380 VTIMEZONE component and a METHOD property set to PUBLISH. Conforming 381 applications MUST NOT supply the 'tzrev' attribute shown in the 382 "TZID" property value above. The "TZURL" property value points to 383 the newest version of the time zone named in the "TZID" parameter. 385 All of the fetch value is case sensitive. 387 All of the 'tzregion' and 'tzcity' values are case sensitive. And 388 the '.ics' is in lower case. 390 Format Definition: The property is defined by the following notation: 392 tzurl = "TZURL" tzurlparam ":" ianatzuri CRLF 394 tzurlparam = *(";" xparam) 396 ianatzuri = ( "ftp://" | "http://" ) vendorServer "/TimeZone" 397 "/" tzregion *( "/" tzregion ) 398 "/" tzcity ".ics" 400 vendorServer = ; Any hostname that is reachable on the Internet 401 ; by a client application. 403 Example: The following is an example of this property that points to 404 the newest version of the time zone definitions. 406 TZURL:ftp://example.com/TimeZone/Indian/Reunion.ics 408 TZURL:http://example.com/TimeZone/Pacific/Pago_Pago.ics 410 TZURL:ftp://example.com/TimeZone/America/Indiana/Knox.ics 412 7.1 Fetching a specific version of a VTIMEZONE 414 An application that wishes to get a specific version of a registered 415 "VTIMEZONE" component creates the FTP url as follows: 417 All of the 'tzregion', 'tzcity', and 'tzrev' values are case 418 sensitive and '.ics' is lower case. 420 fetchuri = ( "ftp://" | "http://" ) vendorServer "/TimeZone" 421 "/" tzregion *( "/" tzregion ) 422 "/" tzcity 423 "/" tzrev ".ics" 425 For example the following are the URIs to get a specific version of 426 these time zones. 428 ftp://example.com/TimeZone/Pacific/Pago_Pago/20050114T162291Z.ics 430 http://example.com/TimeZone/Indian/Reunion/20050115T112522Z.ics 432 ftp://example.com/TimeZone/America/Indiana/Knox/20050222T130921Z.ics 434 8. Fetching the newest version of a VTIMEZONE 436 An application that wishes to get the newest version of a registered 437 "VTIMEZONE" component creates the FTP url as follows: 439 Both the 'tzregion' and 'tzcity' values are case sensitive and '.ics' 440 is lower case. 442 fetchnewuri = ( "ftp://" | "http://" ) vendorServer "/TimeZone" 443 "/" tzregion *( "/" tzregion ) 444 "/" tzcity ".ics" 446 For example the following are the URIs to get a specific version of 447 these time zones. 449 ftp://example.com/TimeZone/Pacific/Pago_Pago.ics 451 ftp://example.com/TimeZone/Indian/Reunion.ics 453 9. iCalendar VTIMEZONE registry 455 Each time zone is an [iCAL] "VTIMEZONE" calendar component. The 456 [iCAL] "TZID" property value will be unique in the IANA registry and 457 will be prefixed with "/IANA.ORG/" to identify them as being part of 458 the registery. 460 The TZURL property will be URL that will point to the newest version 461 of the time zone ".ics" file in the IANA registry. 463 10. AREA parameter 465 The "POLYGON" property allows optional information about the area to 466 included or excluded from a geographic area. 468 The "AREA" parameter specifies if the values of the "POLYGON" 469 property are to be included or excluded from the geographic region 470 described in the "VTIMEZONE" component. 472 Parameter Name: AREA 474 Purpose: To specify if the area is to be included or excluded from 475 the geographic region. 477 Value Type: TEXT 479 Conformance: This property MUST BE specified in a "POLYGON" property. 481 Description: If the AREA value is "INCLUDE", then the area is to be 482 added to the geographic region of area covered. If the value is 483 "EXCLUDE" then the area is to be deleted from the geographic area 484 covered. If the "AREA" parameter is not specicied, the default is 485 "INCLUDE". 487 Format Definition: This property is defined by the following 488 notation: 490 area = ";" "AREA" "=" ( "INCLUDE" / "EXCLUDE") 492 Example: The following are examples of the usage of the "AREA" 493 parameter: 495 POLYGON;AREA=INCLUDE: ...lat/long..sets..of..data 496 POLYGON;AREA=EXCLUDE: ...lat/long..sets..of..data 498 11. Specifying geographic area covered - POLYGON 500 The "POLYGON" property allows optional information about the area to 501 include or exclude from a geographic area. 503 Property Name: POLYGON 505 Purpose: This property specifies the geographic area covered by a 506 time zone. 508 Value Type: TEXT (Comma separated latitude/longitude values) 510 Property Parameters: The "AREA" parameter and "VALUE" parameter are 511 the only parameter allowed in this memo. 513 Conformance: This property MAY be specified in a "VTIMEZONE" calendar 514 component. 516 Description: The values are a comma separated set of longitude and 517 latitude values to six decimal places. There must be at least three 518 sets and will be as many as needed to specify the area covered by the 519 polygon. Using the required "AREA" parameter an area can be included 520 or exclude from the time zone area covered. A time zone may have one 521 or more non-overlapping areas. And a time zone might have holes in 522 it. 524 The value type is TEXT and can be overwriten to be a "URI" value 525 type, so that the definiton can point to a separate file that 526 describes the geographic region that is convered. The URI MUST point 527 to a file that only contains a list of at least three comma separated 528 'geopoint' entries as shown in this section. And the URI MUST point 529 to a publicly available file. 531 The values start at one geographic point and continue in a counter 532 clockwise direction. The first point MUST NOT be repeated as the 533 last point. If drawn on paper, a line would start at the first 534 point, continue to the second point, and to each next point. Then a 535 line would be drawn from the last point to the first point. 537 Format Definition: This property is defined by the following 538 notation: 540 polygon = "POLYGON" polytzparam ":" 541 geopoint "," geopoint "," geopoint *("," geopoint) 542 CRLF 544 polytzparam = area *( ";" "VALUE" "=" "URI" ) 546 geopoint = lat "," lon 548 lat = 550 lon = 552 Example: The following is an example of a geographic region included, 553 and a section excludes on the second entry (if done correctly, the 554 time zone area in this example would be like a donut with a hole in 555 the center). 557 POLYGON;AREA=INCLUDE:43.336600,116.370000, 558 40.475000,111.586700, 559 37.276702,122.069020, 560 33.260654,122.006900 562 POLYGON;AREA=EXCLUDE:43.00,116.13000000, 563 40.30000,111.500000, 564 37.20000,122.069000, 565 33.20000,122.006000 567 Now assume you have two text files with at least three comma 568 separated 'geopoint' entries: 570 ftp://example.com/TimeZone/America/New_Yrk.geo 572 and 574 ftp://example.com/TimeZone/America/Indiana/Knox.geo 576 By using a "URI" value type, these can be in the "VTIMEZONE" 577 component and point to a files that really contain the time zone 578 geographic region. So the "Americla/New_York.ics" file might contain 579 this if the "America/New_York" time zone is not valid in the 580 "America/Indiana/Knox" time zone. 582 POLYGON;AREA=INCLUDE;VALUE=URI:ftp://example.com/TimeZone/America/New_York.geo 583 POLYGON;AREA=EXCLUDE:VALUE=URI:ftp://example.com/TimeZone/America/Indiana/Knox.geo 585 And the "Americia/Indiana/Knox.ics" file might contain this: 587 POLYGON;AREA=INCLUDE:VALUE=URI:ftp://example.com/TimeZone/America/Indiana/Knox.geo 589 12. Initial Time Zones 591 The initial time zones submitted will be from the latest [TZ] 592 database. 594 13. Updating Time Zones 596 This process is TBD and will be developled by consulting with IANA. 598 14. References 600 [1] Dawson, F. and D. Stenerson, "Internet Calendaring and 601 Scheduling Core Object specification (iCalendar)", 602 November 1998. 604 [2] "ISO 8601, Data elements and interchange formats-Information 605 interchange--Representation of dates and times International 606 Organization for Standardization", June 1988. 608 [3] "ISO/IEC 9070, Information Technology_SGML Support Facilities-- 609 Registration Procedures for Public Text Owner Identifiers Second 610 Edition, International Organization for Standardization", 611 April 1991. 613 [4] Bradner, S., "Key words for use in RFCs to Indicate Requirement 614 Levels", March 1997. 616 [5] Crocker, D. and P. Overell, "Augmented BNF for Syntax 617 Specifications: ABNF", November 1997. 619 [6] Yergeau, F., "UTF-8, a transformation format of ISO 10646", 620 January 1998. 622 [7] Howes, T., Smith, M., and F. Dawson, "A MIME Content-Type for 623 Directory Information", September 1998. 625 [8] Olson, A., "Time zone code and data, 626 ftp://elsie.nci.nih.gov/pub/, updated periodically", 627 . 629 Author's Address 631 Doug Royer 632 IntelliCal LLC 633 267 Kentlands Blvd., #3041 634 Gaithersburg, MD 20878 635 USA 637 Phone: +1-208-612-4638 638 Email: Doug@IntelliCal.net 639 URI: http://Royer.com 641 Intellectual Property Statement 643 The IETF takes no position regarding the validity or scope of any 644 Intellectual Property Rights or other rights that might be claimed to 645 pertain to the implementation or use of the technology described in 646 this document or the extent to which any license under such rights 647 might or might not be available; nor does it represent that it has 648 made any independent effort to identify any such rights. Information 649 on the procedures with respect to rights in RFC documents can be 650 found in BCP 78 and BCP 79. 652 Copies of IPR disclosures made to the IETF Secretariat and any 653 assurances of licenses to be made available, or the result of an 654 attempt made to obtain a general license or permission for the use of 655 such proprietary rights by implementers or users of this 656 specification can be obtained from the IETF on-line IPR repository at 657 http://www.ietf.org/ipr. 659 The IETF invites any interested party to bring to its attention any 660 copyrights, patents or patent applications, or other proprietary 661 rights that may cover technology that may be required to implement 662 this standard. Please address the information to the IETF at 663 ietf-ipr@ietf.org. 665 Disclaimer of Validity 667 This document and the information contained herein are provided on an 668 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 669 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 670 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 671 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 672 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 673 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 675 Copyright Statement 677 Copyright (C) The Internet Society (2005). This document is subject 678 to the rights, licenses and restrictions contained in BCP 78, and 679 except as set forth therein, the authors retain all their rights. 681 Acknowledgment 683 Funding for the RFC Editor function is currently provided by the 684 Internet Society.