idnits 2.17.1 draft-royer-timezone-registry-01.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.a on line 15. -- Found old boilerplate from RFC 3978, Section 5.5 on line 875. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 852. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 859. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 865. ** The document seems to lack an RFC 3978 Section 5.1 IPR Disclosure Acknowledgement. ** 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. ** The document uses RFC 3667 boilerplate or RFC 3978-like boilerplate instead of verbatim RFC 3978 boilerplate. After 6 May 2005, submission of drafts without verbatim RFC 3978 boilerplate is not accepted. The following non-3978 patterns matched text found in the document. That text should be removed or replaced: This document is an Internet-Draft and is subject to all provisions of Section 3 of RFC 3667. By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard == It seems as if not all pages are separated by form feeds - found 0 form feeds but 27 pages 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 9 characters in excess of 72. 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 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? (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- 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 (January 28, 2005) is 7029 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 575 == Unused Reference: '1' is defined on line 773, but no explicit reference was found in the text == Unused Reference: '3' is defined on line 780, but no explicit reference was found in the text == Unused Reference: '4' is defined on line 784, but no explicit reference was found in the text == Unused Reference: '5' is defined on line 789, but no explicit reference was found in the text == Unused Reference: '6' is defined on line 792, but no explicit reference was found in the text == Unused Reference: '7' is defined on line 795, but no explicit reference was found in the text == Unused Reference: '8' is defined on line 798, but no explicit reference was found in the text == Unused Reference: '9' is defined on line 802, but no explicit reference was found in the text == Unused Reference: '10' is defined on line 806, but no explicit reference was found in the text == Unused Reference: '13' is defined on line 816, but no explicit reference was found in the text == Unused Reference: '15' is defined on line 822, but no explicit reference was found in the text == Unused Reference: '16' is defined on line 826, but no explicit reference was found in the text -- Possible downref: Non-RFC (?) normative reference: ref. '1' ** Obsolete normative reference: RFC 2445 (ref. '2') (Obsoleted by RFC 5545) -- Possible downref: Non-RFC (?) normative reference: ref. '3' -- Possible downref: Non-RFC (?) normative reference: ref. '4' ** Obsolete normative reference: RFC 822 (ref. '5') (Obsoleted by RFC 2822) ** Obsolete normative reference: RFC 1738 (ref. '6') (Obsoleted by RFC 4248, RFC 4266) ** Obsolete normative reference: RFC 1766 (ref. '7') (Obsoleted by RFC 3066, RFC 3282) ** Obsolete normative reference: RFC 2048 (ref. '10') (Obsoleted by RFC 4288, RFC 4289) ** Obsolete normative reference: RFC 2234 (ref. '12') (Obsoleted by RFC 4234) ** Obsolete normative reference: RFC 2279 (ref. '13') (Obsoleted by RFC 3629) ** Obsolete normative reference: RFC 2425 (ref. '14') (Obsoleted by RFC 6350) -- Possible downref: Non-RFC (?) normative reference: ref. '15' -- Possible downref: Non-RFC (?) normative reference: ref. '16' Summary: 16 errors (**), 0 flaws (~~), 16 warnings (==), 13 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group D. Royer 2 Internet-Draft IntelliCal LLC 3 Expires: July 29, 2005 January 28, 2005 5 Time Zone Registry 6 draft-royer-timezone-registry-01 8 Status of this Memo 10 This document is an Internet-Draft and is subject to all provisions 11 of section 3 of RFC 3667. By submitting this Internet-Draft, each 12 author represents that any applicable patent or other IPR claims of 13 which he or she is aware have been or will be disclosed, and any of 14 which he or she become aware will be disclosed, in accordance with 15 RFC 3668. 17 Internet-Drafts are working documents of the Internet Engineering 18 Task Force (IETF), its areas, and its working groups. Note that 19 other groups may also distribute working documents as 20 Internet-Drafts. 22 Internet-Drafts are draft documents valid for a maximum of six months 23 and may be updated, replaced, or obsoleted by other documents at any 24 time. It is inappropriate to use Internet-Drafts as reference 25 material or to cite them other than as "work in progress." 27 The list of current Internet-Drafts can be accessed at 28 http://www.ietf.org/ietf/1id-abstracts.txt. 30 The list of Internet-Draft Shadow Directories can be accessed at 31 http://www.ietf.org/shadow.html. 33 This Internet-Draft will expire on July 29, 2005. 35 Copyright Notice 37 Copyright (C) The Internet Society (2005). 39 Abstract 41 This is a submission for the creation of an new IANA Time Zones 42 registration process. This is a registry for iCalendar "VTIMEZONE" 43 calendar component information. Time zones and their definitions are 44 required in order to schedule and synchronize meetings and software. 45 The condition in which these time zones change are subject to civil 46 authority rulings and are not always determinable by software 47 algorithms. 49 This is intended to be a central repository for time zone 50 information. The registry does not presume to be the authority for 51 time zone information or rules. This register is simply a place 52 where time zone definitions may be registered for public access. 54 Table of Contents 56 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 57 2. Basic Grammar and Conventions . . . . . . . . . . . . . . . . 5 58 2.1 Formatting Conventions . . . . . . . . . . . . . . . . . . 5 59 2.2 Related Memos . . . . . . . . . . . . . . . . . . . . . . 6 60 2.3 International Considerations . . . . . . . . . . . . . . . 6 61 3. Security Considerations . . . . . . . . . . . . . . . . . . . 7 62 4. Interoperability Considerations . . . . . . . . . . . . . . . 8 63 5. Registry TZID Value . . . . . . . . . . . . . . . . . . . . . 9 64 6. Registry NAME . . . . . . . . . . . . . . . . . . . . . . . . 11 65 7. Registry TZURL Value . . . . . . . . . . . . . . . . . . . . . 12 66 8. Fetching a specific version of a VTIMEZONE . . . . . . . . . . 14 67 9. Fetching the newest version of a VTIMEZONE . . . . . . . . . . 15 68 10. iCalendar VTIMEZONE registry . . . . . . . . . . . . . . . . 16 69 11. AREA parameter . . . . . . . . . . . . . . . . . . . . . . . 17 70 12. Specifying geographic area covered - POLYGON . . . . . . . . 18 71 13. Initial Time Zone Names . . . . . . . . . . . . . . . . . . 21 72 14. References . . . . . . . . . . . . . . . . . . . . . . . . . 25 73 Author's Address . . . . . . . . . . . . . . . . . . . . . . . 26 74 Intellectual Property and Copyright Statements . . . . . . . . 27 76 1. Introduction 78 Many software vendors create time zone information for their 79 applications. This information can sometimes be inconsistent with 80 other applications or contain insufficient information when referring 81 to times far in the past. By creating an IANA registry, the same 82 information will be available to any vendor. In addition there is 83 revision control in the database so vendors will know if they have 84 the latest data. 86 Each time zone has a unique iCalendar time zone identifier (TZID). 87 This document uses the iCalendar "LAST-MODIFIED" property in the 88 iCalendar "VTIMEZONE" calendar component to track revisions of the 89 data. 91 The "VTIMEZONE" calendar component is not defined in this 92 specification and all usage here are simply examples. At the time of 93 this writing RFC-2445 is the authority for the "VTIMEZONE" calendar 94 component. The initial information in the registry will be from the 95 [TZ] database. 97 When applications create information using a time zone is critical 98 that the using applications have the same definitions of the time 99 zone in order for the instances in time to match. For that reason 100 the "TZID" property value will contain the revision information of 101 the time zone name and the "TZURL" value will point to the specific 102 revision of the time zone data. 104 The "TZID" property values are broken down into parts; region, 105 optional sub-regons, city, and revision. And they are separated 106 using the slash (/) character. 108 This example is using the factious America/BosieLike time zone that 109 was registered on January 15th, 2005 at 6:17:22 PM UTC: 111 BEGIN:VCALENDAR 112 PRODID:-//IANA.ORG//NONSGML TZ VTIMEZONE DATABASE//EN 113 VERSION:2.0 114 METHOD:PUBLISH 115 BEGIN:VTIMEZONE 116 TZID:/IANA.ORG/America/BoiseLike/20050115T181722Z 117 TZURL:ftp://iana.org/XXXXX/America/BoiseLike.ics 118 LAST-MODIFIED:20050115T181722Z 119 BEGIN:STANDARD 120 TZOFFSETFROM:-0600 121 TZOFFSETTO:-0700 122 TZNAME:MST 123 DTSTART:19701025T020000 124 RRULE:FREQ=YEARLY;BYMONTH=10;BYDAY=-1SU 125 END:STANDARD 126 BEGIN:DAYLIGHT 127 TZOFFSETFROM:-0700 128 TZOFFSETTO:-0600 129 TZNAME:MDT 130 DTSTART:19700405T020000 131 RRULE:FREQ=YEARLY;BYMONTH=4;BYDAY=1SU 132 END:DAYLIGHT 133 END:VTIMEZONE 134 END:VCALENDAR 136 2. Basic Grammar and Conventions 138 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 139 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY" and 140 "OPTIONAL" in this document are to be interoperated as described in 141 [11]. 143 The notation used in this memo is the ABNF notation of [12]. Readers 144 intending on implementing this format defined in this memo should be 145 familiar with this notation in order to properly interpret the 146 specifications of this memo. 148 All numeric and hexadecimal values used in this memo are given in 149 decimal notation. 151 All names of properties, property parameters, enumerated property 152 values and property parameter values are case-insensitive. However, 153 all other property values are case-sensitive, unless otherwise 154 stated. 155 Note: All indented editorial notes, such as this one, are intended 156 to provide the reader with additional information. The 157 information is not essential to the building of an implementation 158 conformant with this memo. The information is provided to 159 highlight a particular feature or characteristic of the memo. 161 The format for the iCalendar object is based on the syntax of the 162 [14] content type. While the iCalendar object is not a profile of 163 the [14] content type, it does reuse a number of the elements from 164 the [14] specification. 166 2.1 Formatting Conventions 168 The mechanisms defined in this memo are defined in prose. Many of 169 the terms used to describe these have common usage that is different 170 than the standards usage of this memo. In order to reference within 171 this memo elements of the calendaring and scheduling model, core 172 object [2] some formatting conventions have been used. Calendaring 173 and scheduling roles are referred to in quoted-strings of text with 174 the first character of each word in upper case. For example, 175 "Organizer" refers to a role of a "Calendar User" within the protocol 176 defined by [2]. Calendar components defined by this memo are 177 referred to with capitalized, quoted-strings of text. All calendar 178 components start with the letter "V". For example, "VTIMEZONE" 179 refers to the time zone calendar component. 181 The properties defined by this memo are referred to with capitalized, 182 quoted-strings of text, followed by the word "property". For 183 example, "TZNAME" property refers to the iCalendar property used to 184 convey the display name of the time zone. Property parameters 185 defined by this memo are referred to with lowercase, quoted-strings 186 of text, followed by the word "parameter". For example, "value" 187 parameter refers to the iCalendar property parameter used to override 188 the default data type for a property value. 190 2.2 Related Memos 192 Implementers will need to be familiar with several other memos that, 193 along with this memo. Such as iCalendar [2] specifications. 195 [2] - Specifies the format for the "VTIMEZONE" calendar component. 197 This memo does not attempt to repeat the specification of concepts or 198 definitions from these other memos. Where possible, references are 199 made to the memo that provides for the specification of these 200 concepts or definitions. 202 2.3 International Considerations 204 In the rest of this document, descriptions of characters are of the 205 form "character name (codepoint)", where "codepoint" is from the US- 206 ASCII character set. The "character name" is the authoritative 207 description; (codepoint) is a reference to that character in US-ASCII 208 or US-ASCII compatible sets (for example the ISO-8859-x family, 209 UTF-8, ISO-2022-xx, KOI8-R). If a non-US-ASCII compatible character 210 set is used, appropriate code-point from that character set MUST be 211 chosen instead. Use of non-US-ASCII-compatible character sets is NOT 212 recommended. 214 3. Security Considerations 216 There are no known security issues with this proposal as this is a 217 repository of information and not an over the wire protocol. 219 4. Interoperability Considerations 221 This document is intended to be compliant with the [iCAL] "VTIMEZONE" 222 calendar component and will interoperate with any implementation that 223 follows that specification. 225 5. Registry TZID Value 227 Within the time zone registry, the "TZID" property will be used as 228 follows. This is compatible with the [iCAL] "TZID" property as here 229 we only define the format of the value of the property. 231 Property Name: TZID 233 Purpose: This property specifies the text value that uniquely 234 identifies the "VTIMEZONE" calendar component in the IANA registry. 235 The value is case sensitive and is UTF-8 so it should be able to 236 accomidate any locale. 238 Value Type: TEXT (in the format specified below) 240 Property Parameters: Non-standard property parameters can be 241 specified on this property. 243 Conformance: This property MUST be specified in a "VTIMEZONE" 244 calendar component. 246 Description: This is the label by which a time zone calendar 247 component is referenced by any iCalendar properties whose data type 248 is either DATE-TIME, DATE, or TIME and not intended to specify a UTC 249 or a "floating" time. The presence of the SOLIDUS character 250 (US-ASCII decimal 47) as a prefix, indicates that this TZID 251 represents an unique ID in a globally defined IANA time zone registry 252 (this specification). Conforming applications MUST supply the 253 'tzrev' attribute shown below in the "TZID" property value. The 254 "TZID" property value points to a specific version of the time zone. 256 All of the 'tzregion', 'tzcity', and 'tzrev' values are case 257 sensitive. 259 Format Definition: This property is defined by the following 260 notation: 262 tzid = "TZID" tzidpropparam ":" 263 ianatzidprefix 264 "/" tzregion *( "/" tzregion ) 265 "/" tzcity 266 "/" tzrev CRLF 268 tzidpropparam = *(";" xparam) 270 ianatzidprefix = "/IANA.ORG" 272 tzregion = < region names as used in the [TZ] databaee > 273 ; Examples are "Africa", "America", "Asia" 274 ; "Europe", "Indian" "Pacific" 276 tzcity = 278 tzrev = date-time "Z" 280 date-time = 282 Example: The following are examples of globally unique time zone 283 identifiers as defined by this specification: 285 TZID:/IANA.ORG/Indian/Reunion/20050115T112522Z 287 TZID:/IANA.ORG/Pacific/Pago_Pago/20050114T162291Z 289 TZID:/IANA.ORG//America/Indiana/Knox/20050114T162291Z 291 6. Registry NAME 293 One time zone definition may have more than one name or alias. And 294 time zone names might be in a non US-ASCII locale. So this "NAME" 295 property will be allowed multiple time in a "VTIMEZONE" component. 296 By using the iCalenar "LANG" parameter, a "TZID" value can be 297 represented as aliases in muliple locales. 299 Property Name: NAME 301 Purpose: The NAME property allows for a TZID to have many possibly 302 locale specific names or aliases. 304 Value Type: TEXT 306 Property Parameters: The "LANG" parameter and non-standard property 307 parameters can be specified on this property. 309 Conformance: This property can be specified in a "VTIMEZONE" calendar 310 component. 312 Description: Multiple NAME properties may be in a "VTIMEZONE" 313 calendar compoennt, each must be unique. Each "NAME" property MUST 314 include a "LANGUAGE" parameter specifing the locale where the "NAME" 315 property value would be used. There may be multiple "NAME" 316 properties with the same "LANGUAGE" parameter value as long as those 317 "NAME" property values are unique. When in a "VTIMEZONE" calendar 318 component then they are alias nams for the "TZID" property value. 319 Note that the "STANDARD" and "DAYLIGHT" calendar components use zero 320 or more of the locale specific "TZNAME" property as aliases as 321 defined in iCalendar. 323 Format Definition: The property is defined by the following notation: 325 aliasname = "NAME" nameparam ":" localeName CRLF 327 nameparam = langparam *(";" xparam) 329 langparam = < As defined in iCalendar > 331 localName = < Single line text used as name or alias of TZID >a 333 Examples. 335 7. Registry TZURL Value 337 Within the time zone registry, the "TZURL" property will be used as 338 follows. This is compatible with the [iCAL] "TZURL" property as here 339 we only define the format of the value of the property. 341 Property Name: TZURL 343 Purpose: The TZURL provides a means for a VTIMEZONE component to 344 point to a network location that can be used to retrieve an up-to- 345 date version of itself. 347 Value Type: URI 349 Property Parameters: Non-standard property parameters can be 350 specified on this property. 352 Conformance: This property can be specified in a "VTIMEZONE" calendar 353 component. 355 Description: The TZURL provides a means for a VTIMEZONE component to 356 point to a network location that can be used to retrieve an up-to- 357 date version of itself. This provides a hook to handle changes 358 government bodies impose upon time zone definitions. Retrieval of 359 this resource results in an iCalendar object containing a single 360 VTIMEZONE component and a METHOD property set to PUBLISH. Conforming 361 applications MUST NOT supply the 'tzrev' attribute shown in the 362 "TZID" property value above. The "TZURL" property value points to 363 the newest version of the time zone named in the "TZID" parameter. 365 All of the fetch value is case sensitive. 367 All of the 'tzregion' and 'tzcity' values are case sensitive. And 368 the '.ics' is in lower case. 370 Format Definition: The property is defined by the following notation: 372 tzurl = "TZURL" tzurlparam ":" ianatzuri CRLF 374 tzurlparam = *(";" xparam) 376 ianatzuri = "ftp://iana.org/XXXXXX" 377 "/" tzregion *( "/" tzregion ) 378 "/" tzcity ".ics" 380 Example: The following is an example of this property that points to 381 the newest version of the time zone definitions. 383 TZURL:ftp://iana.org/XXXXXX/Indian/Reunion.ics 385 TZURL:ftp://iana.org/XXXXXX/Pacific/Pago_Pago.ics 387 TZURL:ftp://iana.org/XXXXXX/America/Indiana/Knox.ics 389 8. Fetching a specific version of a VTIMEZONE 391 An application that wishes to get a specific version of a registered 392 "VTIMEZONE" component creates the FTP url as follows: 394 All of the 'tzregion', 'tzcity', and 'tzrev' values are case 395 sensitive and '.ics' is lower case. 397 fetchuri = "ftp://iana.org/XXXXXX" 398 "/" tzregion *( "/" tzregion ) 399 "/" tzcity 400 "/" tzrev ".ics" 402 For example the following are the URIs to get a specific version of 403 these time zones. 405 ftp://iana.org/XXXXXX/Pacific/Pago_Pago/20050114T162291Z.ics 407 ftp://iana.org/XXXXXX/Indian/Reunion/20050115T112522Z.ics 409 ftp://iana.org/XXXXXX/America/Indiana/Knox/20050222T130921Z.ics 411 9. Fetching the newest version of a VTIMEZONE 413 An application that wishes to get the newest version of a registered 414 "VTIMEZONE" component creates the FTP url as follows: 416 Both the 'tzregion' and 'tzcity' values are case sensitive and '.ics' 417 is lower case. 419 fetchnewuri = "ftp://iana.org/XXXXXX" 420 "/" tzregion *( "/" tzregion ) 421 "/" tzcity ".ics" 423 For example the following are the URIs to get a specific version of 424 these time zones. 426 ftp://iana.org/XXXXXX/Pacific/Pago_Pago.ics 428 ftp://iana.org/XXXXXX/Indian/Reunion.ics 430 10. iCalendar VTIMEZONE registry 432 Each time zone is an [iCAL] "VTIMEZONE" calendar component. The 433 [iCAL] "TZID" property value will be unique in the IANA registry and 434 will be prefixed with "/IANA.ORG/" to identify them as being part of 435 the register. 437 The TZURL property will be URL that will point to the newest version 438 of the time zone ".ics" file in the IANA registry. 440 11. AREA parameter 442 The "POLYGON" property is being proposed to allow optional 443 information about the area to included or excluded from a geographic 444 area. 446 This parameter specifies if the values of the "POLYGON" property are 447 to be included or excluded from the geographic region described in 448 the "VTIMEZONE" component. 450 Parameter Name: AREA 452 Purpose: To specify if the area is to be included or excluded from 453 the geographic region. 455 Value Type: TEXT 457 Conformance: This property MUST BE specified in a "POLYGON" property. 459 Description: If the AREA value is 'include', then the area is to be 460 added to the geographic region of area covered. If the value is 461 'exclude', then the area is to be deleted from the geographic area 462 covered. 464 Format Definition: This property is defined by the following 465 notation: 467 area = ";" "AREA" "=" ( "INCLUDE" / "EXCLUDE") 469 Example: The following are examples of the usage of the "AREA" 470 parameter: 472 POLYGON;AREA=INCLUDE: ...lat/long..sets..of..data 473 POLYGON;AREA=EXCLUDE: ...lat/long..sets..of..data 475 12. Specifying geographic area covered - POLYGON 477 One of the issues brought up a few years ago on the CALSCH mailing 478 list was how to identify the area covered by a time zone. The issues 479 are that two or more time zone may overlap, and they might have areas 480 within them that are excluded, they have holes in their polygon. 482 So the "POLYGON" property is being proposed to allow optional 483 information about the area to include or exclude from a geographic 484 area. 486 Property Name: POLYGON 488 Purpose: This property specifies the geographic area covered by a 489 time zone. 491 Value Type: TEXT (Comma separated latitude/longitude values) 493 Property Parameters: The "AREA" parameter is the only parameter 494 allowed. 496 Conformance: This property MAY be specified in a "VTIMEZONE" calendar 497 component. 499 Description: The values are a comma separated set of longitude and 500 latitude values to six decimal places. There must be at least three 501 sets and will be as many as needed to specify the area covered by the 502 polygon. Using the required "AREA" parameter an area can be included 503 or exclude from the time zone area covered. A time zone may have one 504 or more non-overlapping areas. And a time zone might have holes in 505 it. 507 The value type is TEXT and can be overwriten to be a "URI" value 508 type, so that the definiton can point to a separate file that 509 describes the geographic region that is convered. The URI MUST point 510 to a file that only contains a list of at least three comma separated 511 'geopoint' entries as shown in this section. And the URI MUST point 512 to a publicly available file. 514 The values start at one geographic point and continue in a counter 515 clockwise direction. The first point MUST NOT be repeated as the 516 last point. If drawn on paper, a line would start at the first 517 point, continue to the second point, and to each next point. Then a 518 line would be drawn from the last point to the first point. 520 Format Definition: This property is defined by the following 521 notation: 523 polygon = "POLYGON" polytzparam ":" 524 geopoint "," geopoint "," geopoint *("," geopoint) CRLF 526 polytzparam = area *( ";" "VALUE" "=" "URI" ) 528 geopoint = lat "," lon 530 lat = 532 lon = 534 Example: The following is an example of a geographic region included, 535 and a section excludes on the second entry (if done correctly, the 536 time zone area in this example would be like a donut with a hole in 537 the center). 539 POLYGON;AREA=INCLUDE:43.336600,116.13.370000, 540 40.475000,111.586700, 541 37.276702,122.069020, 542 33.260654,122.006900 544 POLYGON;AREA=EXCLUDE:43.00,116.13.000000, 545 40.30000,111.500000, 546 37.20000,122.069000, 547 33.20000,122.006000 549 Now assume you have two text files with at least three comma 550 separated 'geopoint' entries: 552 http://iana.org/xxx/America/New_Yrk.geo 554 and 556 http://iana.org/xxx/America/Indiana/Knox.geo 558 By using a "URI" value type, these can be in the "VTIMEZONE" 559 component and point to a files that really contain the time zone 560 geographic region. So the "Americla/New_York.ics" file might contain 561 this if the "America/New_York" time zone is not valid in the 562 "America/Indiana/Knox" time zone. 564 POLYGON;AREA=INCLUDE;VALUE=URI:http://iana.org/xxx/America/New_York.geo 565 POLYGON;AREA=EXCLUDE:VALUE=URI:http://iana.org/xxx/America/Indiana/Knox.geo 567 And the "Americia/Indiana/Knox.ics" file might contain this: 569 POLYGON;AREA=INCLUDE:VALUE=URI:http://iana.org/xxx/America/Indiana/Knox.geo 571 13. Initial Time Zone Names 573 The following time zone ID's will are in the initial submission. 574 They are all from the [TZ] database. They will all have "TZID" 575 property that matches the [TZ] database names and the 'tzrev' value 576 that is the submission date to IANA. (SAMPLE FOR NOW, FULL SET WILL 577 BE ADDED IN LATER DRAFTS) 579 Africa/Abidjan Africa/Accra 580 Africa/Addis_Ababa Africa/Algiers 581 Africa/Asmera Africa/Bamako 582 Africa/Bangui Africa/Banjul 583 Africa/Bissau Africa/Blantyre 584 Africa/Brazzaville Africa/Bujumbura 585 Africa/Cairo Africa/Casablanca 586 Africa/Ceuta Africa/Conakry 587 Africa/Dakar Africa/Dar_es_Salaam 588 Africa/Djibouti Africa/Douala 589 Africa/El_Aaiun Africa/Freetown 590 Africa/Gaborone Africa/Harare 591 Africa/Johannesburg Africa/Kampala 592 Africa/Khartoum Africa/Kigali 593 Africa/Kinshasa Africa/Lagos 594 Africa/Libreville Africa/Lome 595 Africa/Luanda Africa/Lubumbashi 596 Africa/Lusaka Africa/Malabo 597 Africa/Maputo Africa/Maseru 598 Africa/Mbabane Africa/Mogadishu 599 Africa/Monrovia Africa/Nairobi 600 Africa/Ndjamena Africa/Niamey 601 Africa/Nouakchott Africa/Ouagadougou 602 Africa/Porto-Novo Africa/Sao_Tome 603 Africa/Timbuktu Africa/Tripoli 604 Africa/Tunis Africa/Windhoek 605 America/Adak America/Anchorage 606 America/Anguilla America/Antigua 607 America/Araguaina America/Aruba 608 America/Asuncion America/Bahia 609 America/Barbados America/Belem 610 America/Belize America/Boa_Vista 611 America/Bogota America/Boise 612 America/Buenos_Aires America/Cambridge_Bay 613 America/Campo_Grande America/Cancun 614 America/Caracas America/Catamarca 615 America/Cayenne America/Cayman 616 America/Chicago America/Chihuahua 617 America/Cordoba America/Costa_Rica 618 America/Cuiaba America/Curacao 619 America/Danmarkshavn America/Dawson_Creek 620 America/Dawson America/Denver 621 America/Detroit America/Dominica 622 America/Edmonton America/Eirunepe 623 America/El_Salvador America/Fortaleza 624 America/Glace_Bay America/Godthab 625 America/Goose_Bay America/Grand_Turk 626 America/Grenada America/Guadeloupe 627 America/Guatemala America/Guayaquil 628 America/Guyana America/Halifax 629 America/Havana America/Hermosillo 630 America/Indiana/Indianapolis America/Indiana/Knox 631 America/Indiana/Marengo America/Indianapolis 632 America/Indiana/Vevay America/Inuvik 633 America/Iqaluit America/Jamaica 634 America/Jujuy America/Juneau 635 America/Kentucky/Louisville America/Kentucky/Monticello 636 America/La_Paz America/Lima 637 America/Los_Angeles America/Louisville 638 America/Maceio America/Managua 639 America/Manaus America/Martinique 640 America/Mazatlan America/Mendoza 641 America/Menominee America/Merida 642 America/Mexico_City America/Miquelon 643 America/Monterrey America/Montevideo 644 America/Montreal America/Montserrat 645 America/Nassau America/New_York 646 America/Nipigon America/Nome 647 America/Noronha America/North_Dakota/Center 648 America/Panama America/Pangnirtung 649 America/Paramaribo America/Phoenix 650 America/Port-au-Prince America/Port_of_Spain 651 America/Porto_Velho America/Puerto_Rico 652 America/Rainy_River America/Rankin_Inlet 653 America/Recife America/Regina 654 America/Rio_Branco America/Santiago 655 America/Santo_Domingo America/Sao_Paulo 656 America/Scoresbysund America/Shiprock 657 America/St_Johns America/St_Kitts 658 America/St_Lucia America/St_Thomas 659 America/St_Vincent America/Swift_Current 660 America/Tegucigalpa America/Thule 661 America/Thunder_Bay America/Tijuana 662 America/Toronto America/Tortola 663 America/Vancouver America/Whitehorse 664 America/Winnipeg America/Yakutat 665 America/Yellowknife Antarctica/Casey 666 Antarctica/Davis Antarctica/DumontDUrville 667 Antarctica/Mawson Antarctica/McMurdo 668 Antarctica/Palmer Antarctica/Rothera 669 Antarctica/South_Pole Antarctica/Syowa 670 Antarctica/Vostok Arctic/Longyearbyen 671 Asia/Aden Asia/Almaty 672 Asia/Amman Asia/Anadyr 673 Asia/Aqtau Asia/Aqtobe 674 Asia/Ashgabat Asia/Baghdad 675 Asia/Bahrain Asia/Baku 676 Asia/Bangkok Asia/Beirut 677 Asia/Bishkek Asia/Brunei 678 Asia/Calcutta Asia/Choibalsan 679 Asia/Chongqing Asia/Colombo 680 Asia/Damascus Asia/Dhaka 681 Asia/Dili Asia/Dubai 682 Asia/Dushanbe Asia/Gaza 683 Asia/Harbin Asia/Hong_Kong 684 Asia/Hovd Asia/Irkutsk 685 Asia/Istanbul Asia/Jakarta 686 Asia/Jayapura Asia/Jerusalem 687 Asia/Kabul Asia/Kamchatka 688 Asia/Karachi Asia/Kashgar 689 Asia/Katmandu Asia/Krasnoyarsk 690 Asia/Kuala_Lumpur Asia/Kuching 691 Asia/Kuwait Asia/Macau 692 Asia/Magadan Asia/Makassar 693 Asia/Manila Asia/Muscat 694 Asia/Nicosia Asia/Novosibirsk 695 Asia/Omsk Asia/Oral 696 Asia/Phnom_Penh Asia/Pontianak 697 Asia/Pyongyang Asia/Qatar 698 Asia/Qyzylorda Asia/Rangoon 699 Asia/Riyadh Asia/Saigon 700 Asia/Sakhalin Asia/Samarkand 701 Asia/Seoul Asia/Shanghai 702 Asia/Singapore Asia/Taipei 703 Asia/Tashkent Asia/Tbilisi 704 Asia/Tehran Asia/Thimphu 705 Asia/Tokyo Asia/Ulaanbaatar 706 Asia/Urumqi Asia/Vientiane 707 Asia/Vladivostok Asia/Yakutsk 708 Asia/Yekaterinburg Asia/Yerevan 709 Atlantic/Azores Atlantic/Bermuda 710 Atlantic/Canary Atlantic/Cape_Verde 711 Atlantic/Faeroe Atlantic/Jan_Mayen 712 Atlantic/Madeira Atlantic/Reykjavik 713 Atlantic/South_Georgia Atlantic/Stanley 714 Atlantic/St_Helena Australia/Adelaide! 715 Australia/Brisbane Australia/Broken_Hill 716 Australia/Darwin Australia/Hobart 717 Australia/Lindeman Australia/Lord_Howe 718 Australia/Melbourne Australia/Perth 719 Australia/Sydney Europe/Amsterdam 720 Europe/Andorra Europe/Athens 721 Europe/Belfast Europe/Belgrade 722 Europe/Berlin Europe/Bratislava 723 Europe/Brussels Europe/Bucharest 724 Europe/Budapest Europe/Chisinau 725 Europe/Copenhagen Europe/Dublin 726 Europe/Gibraltar Europe/Helsinki 727 Europe/Istanbul Europe/Kaliningrad 728 Europe/Kiev Europe/Lisbon 729 Europe/Ljubljana Europe/London 730 Europe/Luxembourg Europe/Madrid 731 Europe/Malta Europe/Minsk 732 Europe/Monaco Europe/Moscow 733 Europe/Nicosia Europe/Oslo 734 Europe/Paris Europe/Prague 735 Europe/Riga Europe/Rome 736 Europe/Samara Europe/San_Marino 737 Europe/Sarajevo Europe/Simferopol 738 Europe/Skopje Europe/Sofia 739 Europe/Stockholm Europe/Tallinn 740 Europe/Tirane Europe/Uzhgorod 741 Europe/Vaduz Europe/Vatican 742 Europe/Vienna Europe/Vilnius 743 Europe/Warsaw Europe/Zagreb 744 Europe/Zaporozhye Europe/Zurich 745 Indian/Antananarivo Indian/Chagos 746 Indian/Christmas Indian/Cocos 747 Indian/Comoro Indian/Kerguelen 748 Indian/Mahe Indian/Maldives 749 Indian/Mauritius Indian/Mayotte 750 Indian/Reunion Pacific/Apia 751 Pacific/Auckland Pacific/Chatham 752 Pacific/Easter Pacific/Efate 753 Pacific/Enderbury Pacific/Fakaofo 754 Pacific/Fiji Pacific/Funafuti 755 Pacific/Galapagos Pacific/Gambier 756 Pacific/Guadalcanal Pacific/Guam 757 Pacific/Honolulu Pacific/Johnston 758 Pacific/Kiritimati Pacific/Kosrae 759 Pacific/Kwajalein Pacific/Majuro 760 Pacific/Marquesas Pacific/Midway 761 Pacific/Nauru Pacific/Niue 762 Pacific/Norfolk Pacific/Noumea 763 Pacific/Pago_Pago Pacific/Palau 764 Pacific/Pitcairn Pacific/Ponape 765 Pacific/Port_Moresby Pacific/Rarotonga 766 Pacific/Saipan Pacific/Tahiti 767 Pacific/Tarawa Pacific/Tongatapu 768 Pacific/Truk Pacific/Wake 769 Pacific/Wallis Pacific/Yap 771 14 References 773 [1] Royer, D., "Calendar Access Protocol (CAP)", RFC XXXX - TBD, 774 XXXXX 2005. 776 [2] Dawson, F. and D. Stenerson, "Internet Calendaring and 777 Scheduling Core Object specification (iCalendar)", RFC 2445, 778 November 1998. 780 [3] "ISO 8601, Data elements and interchange formats-Information 781 interchange--Representation of dates and times International 782 Organization for Standardization", June 1988. 784 [4] "ISO/IEC 9070, Information Technology_SGML Support 785 Facilities--Registration Procedures for Public Text Owner 786 Identifiers Second Edition, International Organization for 787 Standardization", April 1991. 789 [5] Crocker, D., "Standard for the Format of ARPA Internet Text 790 Messages", STD 11, RFC 822, August 1982. 792 [6] Berners-Lee, T., Masinter, L. and M. McCahill, "Uniform 793 Resource Locators (URL", RFC 1738, December 1994. 795 [7] Alvestrand, H., "Tags for the Identification of Languages", RFC 796 1766, March 1995. 798 [8] Freed, N. and N. Borenstein, "Multipurpose Internet Mail 799 Extensions (MIME) - Part One: Format of Internet Message 800 Bodies", RFC 2045, November 1996. 802 [9] Freed, N. and N. Borenstein, "Multipurpose Internet Mail 803 Extensions (MIME) - Part Two: Media Types", RFC 2046, November 804 1996. 806 [10] Freed, N., Klensin, J. and J. Postel, "Multipurpose Internet 807 Mail Extensions (MIME) - Part Four: Registration Procedures", 808 RFC 2048, January 1997. 810 [11] Bradner, S., "Key words for use in RFCs to Indicate Requirement 811 Levels", BCP 14, RFC 2119, March 1997. 813 [12] Crocker, D. and P. Overell, "Augmented BNF for Syntax 814 Specifications: ABNF", RFC 2234, November 1997. 816 [13] Yergeau, F., "UTF-8, a transformation format of ISO 10646", RFC 817 2279, January 1998. 819 [14] Howes, T., Smith, M. and F. Dawson, "A MIME Content-Type for 820 Directory Information", RFC 2425, September 1998. 822 [15] Olson, A., "Time zone code and data, 823 ftp://elsie.nci.nih.gov/pub/, updated periodically", 824 . 826 [16] "Internet Mail Consortium, vCalendar - The Electronic 827 Calendaring and Scheduling Exchange Format 828 http://www.imc.org/pdi/vcal-10.txt", September 1996, 829 . 831 Author's Address 833 Doug Royer 834 IntelliCal LLC 835 267 Kentlands Blvd., #3041 836 Gaithersburg, MD 20878 837 USA 839 Phone: +1-208-612-4638 840 EMail: Doug@IntelliCal.net 841 URI: http://Royer.com 843 Intellectual Property Statement 845 The IETF takes no position regarding the validity or scope of any 846 Intellectual Property Rights or other rights that might be claimed to 847 pertain to the implementation or use of the technology described in 848 this document or the extent to which any license under such rights 849 might or might not be available; nor does it represent that it has 850 made any independent effort to identify any such rights. Information 851 on the procedures with respect to rights in RFC documents can be 852 found in BCP 78 and BCP 79. 854 Copies of IPR disclosures made to the IETF Secretariat and any 855 assurances of licenses to be made available, or the result of an 856 attempt made to obtain a general license or permission for the use of 857 such proprietary rights by implementers or users of this 858 specification can be obtained from the IETF on-line IPR repository at 859 http://www.ietf.org/ipr. 861 The IETF invites any interested party to bring to its attention any 862 copyrights, patents or patent applications, or other proprietary 863 rights that may cover technology that may be required to implement 864 this standard. Please address the information to the IETF at 865 ietf-ipr@ietf.org. 867 Disclaimer of Validity 869 This document and the information contained herein are provided on an 870 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 871 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 872 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 873 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 874 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 875 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 877 Copyright Statement 879 Copyright (C) The Internet Society (2005). This document is subject 880 to the rights, licenses and restrictions contained in BCP 78, and 881 except as set forth therein, the authors retain all their rights. 883 Acknowledgment 885 Funding for the RFC Editor function is currently provided by the 886 Internet Society.