idnits 2.17.1 draft-leiba-tzregistry-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** The document seems to lack a License Notice according IETF Trust Provisions of 28 Dec 2009, Section 6.b.ii or Provisions of 12 Sep 2009 Section 6.b -- however, there's a paragraph with a matching beginning. Boilerplate error? (You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Feb 2009 rather than one of the newer Notices. See https://trustee.ietf.org/license-info/.) 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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (March 25, 2009) is 5509 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) ** Obsolete normative reference: RFC 4234 (ref. 'ABNF') (Obsoleted by RFC 5234) -- Obsolete informational reference (is this intentional?): RFC 2434 (ref. 'IANA') (Obsoleted by RFC 5226) Summary: 2 errors (**), 0 flaws (~~), 1 warning (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 VCardDav Working Group B. Leiba 3 Internet-Draft Internet Messaging Technology 4 Intended status: Standards Track March 25, 2009 5 Expires: September 26, 2009 7 Definition of IANA Registry for Timezone Names 8 draft-leiba-tzregistry-00 10 Status of this Memo 12 This Internet-Draft is submitted to IETF in full conformance with the 13 provisions of BCP 78 and BCP 79. 15 Internet-Drafts are working documents of the Internet Engineering 16 Task Force (IETF), its areas, and its working groups. Note that 17 other groups may also distribute working documents as Internet- 18 Drafts. 20 Internet-Drafts are draft documents valid for a maximum of six months 21 and may be updated, replaced, or obsoleted by other documents at any 22 time. It is inappropriate to use Internet-Drafts as reference 23 material or to cite them other than as "work in progress." 25 The list of current Internet-Drafts can be accessed at 26 http://www.ietf.org/ietf/1id-abstracts.txt. 28 The list of Internet-Draft Shadow Directories can be accessed at 29 http://www.ietf.org/shadow.html. 31 This Internet-Draft will expire on September 26, 2009. 33 Copyright Notice 35 Copyright (c) 2009 IETF Trust and the persons identified as the 36 document authors. All rights reserved. 38 This document is subject to BCP 78 and the IETF Trust's Legal 39 Provisions Relating to IETF Documents in effect on the date of 40 publication of this document (http://trustee.ietf.org/license-info). 41 Please review these documents carefully, as they describe your rights 42 and restrictions with respect to this document. 44 Abstract 46 VCards need a stable, well defined list of timezone names, so that 47 users can create VCards that refer to timezones. There is no common 48 list of such names, and other standards need timezone names also. 49 This document creates an IANA registry of timezone names, and 50 initially populates the list. 52 Initial version 54 o Define timezone registry. 56 o Defer initial population with Olsen database until we like the 57 basic document. 59 Table of Contents 61 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 63 2. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 3 64 2.1. New registry for timezone names . . . . . . . . . . . . . . . 3 65 2.2. Initial population of timezone-names registry . . . . . . . . 3 67 3. Security Considerations . . . . . . . . . . . . . . . . . . . 4 69 4. References . . . . . . . . . . . . . . . . . . . . . . . . . 4 70 4.1. Normative References . . . . . . . . . . . . . . . . . . . . 4 71 4.2. Informative References . . . . . . . . . . . . . . . . . . . 4 73 Author's Address . . . . . . . . . . . . . . . . . . . . . . 4 74 Intellectual Property and Copyright Statements . . . . . . . 5 76 1. Introduction 78 VCards need a stable, well defined list of timezone names, so that 79 users can create VCards that refer to timezones. There is no common 80 list of such names, and other standards need timezone names also. 81 This document creates an IANA registry of timezone names, and 82 initially populates the list. 84 This document defines only the names, leaving the definition of the 85 timezone rules ("normal offset is UTC+2", "switch to summer time on 86 the third Sunday in March", etc) out of scope. The registry contains 87 an optional URI for each defined timezone, and it's possible for that 88 URI to point to a place where such rule definitions can be obtained. 90 A timezone name has the following ABNF [ABNF] syntax: 92 tzname = ALPHA *127(ALPHA / DIGIT) 93 ; may have mixed case for readability 94 ; interpreted case-insensitively 96 2. IANA Considerations 98 2.1. New registry for timezone names 100 IANA is asked to create a new registry for timezone names. This 101 registry contains only IETF-controlled timezone names. New names are 102 registered using the "Specification Required" policy [IANA]. 103 [[It won't be "Specification Required". What should it be?]] 105 This defines the template for a new registry for timezone names, to 106 be created as http://www.iana.org/assignments/timezone-names. There 107 are no initial entries for this registry. 109 To: iana@iana.org 110 Subject: Registration of new timezone name 111 Timezone name: [a short US-ASCII string with no internal meaning] 112 Description: [a human-readable US-ASCII string, in English, that 113 describes the meaning of this timezone (such as, "the time zone in 114 New York City")] 115 Information URI: [A URI that points to more information about this 116 timezone. Specify "none" if there is no appropriate URI.] 118 2.2. Initial population of timezone-names registry 120 The following are the initial names to be registered in the timezone- 121 names registry, to be entered in 122 http://www.iana.org/assignments/timezone-names. 124 [[anchor1: We'll be filling this in from the Olsen DB...]] 126 Timezone name: ?? 127 Description: a time zone. 128 Information URI: none 130 3. Security Considerations 132 This document defines an IANA registry. There are no security 133 considerations. 135 4. References 137 4.1. Normative References 139 [ABNF] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax 140 Specifications: ABNF", RFC 4234, October 2005. 142 4.2. Informative References 144 [IANA] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA 145 Considerations Section in RFCs", BCP 26, RFC 2434, 146 October 1998. 148 Author's Address 150 Barry Leiba 151 Internet Messaging Technology 153 Phone: +1 646 827 0648 154 Email: barryleiba@computer.org