RFC 2550の翻訳です。(まだ途中)翻訳内容については1bitも保証しません。 再配布、リンク等は自由に行っていただいて結構です。 翻訳上に問題がある場合や翻訳についてのご意見は、Naoki Nakashima / 中島 尚紀(nn111@columbia.edu)までどうぞ。内容について意見がある場合は、 直接筆者の方にどうぞ。 (以上お約束。) ----------------------------------------------------------------------- Network Working Group S. Glassman Request for Comments: 2550 M. Manasse Category: Stinkards Track J. Mogul Compaq Computer Corporation 1 April 1999 Y10K and Beyond 1万年、およびその後 Status of this Memo このメモの状態 This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited. このメモは、インターネット社会に情報を提供するものである。これは何らか の標準を示すものではない。改良のための議論・提案などを求めている。 このメモの再配布については、無制限である。 Copyright Notice 著作権の表示 Copyright (C) The Internet Society (1999). All Rights Reserved. Abstract 概要 As we approach the end of the millennium, much attention has been paid to the so-called "Y2K" problem. Nearly everyone now regrets the short-sightedness of the programmers of yore who wrote programs designed to fail in the year 2000. Unfortunately, the current fixes for Y2K lead inevitably to a crisis in the year 10,000 when the programs are again designed to fail. 我々がいま1000年ごとの終わりに近づいているように、いわゆる「2000年問題」 が現在非常に注目を集めている。ほとんどすべての人が今、昔のプログラマ たちが2000年になったらプログラムが動作しなくなりようにプログラムを 作ってきたという浅はかさを後悔している。不幸なことに、2000年問題の 為に行われている修正は、10000年になってまたプログラムが動作しなくなる、 という危機が不可避である。 This specification provides a solution to the "Y10K" problem which has also been called the "YAK" problem (hex) and the "YXK" problem (Roman numerals). このスペックは1万年問題("Y10K"、もしくは"YAK"(hex)や"YXK"(ローマ数字) と呼ばれる)についての解法を提供する。 1. Introduction, Discussion, and Related Work Many programs and standards contain, manipulate and maintain dates. Comparing and sorting dates is a common activity. Many different formats and standards for dates have been developed and all have been found wanting. たくさんのプログラムや標準は日付データを含み、操作し、保持している。 日付データの比較や並べ替えというのは一般的な動作である。たくさんの 異なった日付データについてのフォーマットや標準が開発されてきており、 それらのすべてにはぬけおちたものが見つかっている。 Early date formats reserved only two digits to represent the year portion of a date. Programs that use this format make mistakes when dealing with dates after the year 2000. This is the so-called Y2K problem. 初期の日付のフォーマットは年部分を表現するため、たった2つの数字しか 保持していなかった。このフォーマットを利用するプログラムは、2000年後の 日付を扱う際に、誤りを起こす。これがいわゆる「200年問題」である。 Glassman, et. al. Informational [Page 1] RFC 2550 Y10K and Beyond 1 April 1999 The most common fix for the Y2K problem has been to switch to 4-digit years. This fix covers roughly the next 8,000 years (until the year 9999) by which time, everyone seems convinced that all current programs will have been retired. This is exactly the faulty logic and lazy programming practice that led to the current Y2K problem! Programmers and designers always assume that their code will eventually disappear, but history suggests that code and programs are often used well past their intended circumstances. 最も一般的な2000年問題の修正法は、4桁に年部分を変更することである。 この修正は大まかにはこの後8000年(9999年まで)をカバーしており、ほと んどの人はそれまでには現在のすべてのプログラムが利用されていないと 信じているようである。これこそまさに現在の2000年問題を引き起こした 間違った論理であり、怠惰なプログラミングの習慣である!プログラマや デザイナーは常に自分が書いたコードが徐々に消えていくと仮定しているが、 歴史が示すようにコードとプログラムはしばしば彼らが予想した環境が 過ぎ去ったあともしっかりと使われているのである。 The 4-digit year leads directly to programs that will fail in the year 10,000. This proposal addresses the Y10K problem in a general way that covers the full range of date and time format issues. 4桁による年表示は直接的に1万年にプログラムの誤りを導く。この提案は 日付と時間のフォーマットの問題での、すべての長さをカバーする一般的な 方法によって1万年問題の対策を行う。 1.1 Current approaches 1.1 現状の試み A large number of approaches exist for formatting dates and times. All of them have limitations. The 2-digit year runs into trouble next year. The 4-digit year hits the wall in the year 10,000. A 16-bit year runs out in the year 65,536. A 32-bit counter for the number of seconds since 1970 [UNIX] wraps in 2038. A 32-bit counter for the number of milli-seconds since booting crashes a Windows (TM) PC in 49.7 days [Microsoft]. 日付と時間のフォーマットについては、たくさんの試みが存在する。それら すべてには限界がある。2桁の数字による年表記は来年には問題をおこす。 4桁による年表記は1万年に壁にぶつかる。16bitによる年表記は65536年には つきてしまう。1970年からの32bitの秒による表記[UNIX]は2038年までで 終わってしまう。起動時からの32bitのミリ秒による表記はWindows(TM) パソコンを47.9日目にクラッシュさせてしまう。[Microsoft] In this specification, we focus on the Y10K problems since they are most common and a large number of existing standards and protocols are susceptible to them (section 7). These standards, and new proposals on their way, will lead to a serious world-wide problem unless efforts are made now to correct the computing, government, and business communities. このスペックでは、我々は1万年問題に注目する。なぜならば、それが 最も一般的であり、たくさんの現存する標準やプロトコルが影響をその 受けやすいためである。(Section 7) これらの標準、そして自分自身の 方法での新しいプロトコルは、コンピューター、政府、ビジネス社会を 修正するための努力が今なされなければ深刻な世界レベルでの問題を 引き起こすであろう。 Already, a small cottage industry is popping up to deal with the Y10K problem [YUCK]. We encourage these efforts and, in the coming years, this effort can only grow in size and importance. すでに、1万年問題を扱う小さな業界が立ち上がっている。[YUCK] われわれは これらの努力をおこなうように推奨され、これからの年に、この努力のみが 大きさと重要性を成長させるのである。 1.2 A Fixed Format Y10K Fix 1.2 1万年修正用修正フォーマット At the time of this writing, only one proposal [Wilborne] directly deals with the Y10K problem. In that proposal, dates are represented as decimal numbers with the dates compared numerically. The proposed format is simply YYYYYMMDD - i.e. 5-digit years. これを執筆時点での、唯一の1万年問題を直接扱った提案。[Wilborne] この 提案において、日付は10進数で表現され、日付は数的に比較される。この 提案のフォーマットはシンプルでYYYYYMMDD - つまり、5桁による年表記である。 To allow numerical comparison of dates, this representation requires a completely fixed representation for the date. There can be no optional fields, the date resolution is limited to the granularity of one day, and this solution fails in the year 100,000 (Y100K). 数による日付の比較を行うために、この表現では完全に日付の表現を修正 する事が必要となる。これらはオプションとなる領域がありえず、一日 粒度までしか日付の分解度をあげることができない。そしてこの修正法は 10万年(Y100K)には誤りをおこす。 Glassman, et. al. Informational [Page 2] RFC 2550 Y10K and Beyond 1 April 1999 1.2.2 Limitations of Numerical Comparison 1.2.2 数による比較における制限 While sufficient for the specific Y10K problem, this solution is limited. Even if extended for 6-digit years, it fails on 32-bit systems (and future 32-bit system emulators) after the date represented by the number 2147481231 (December 31, 214748) leading to a Y214749 problem. Similarly, 64-bit and 128-bit systems also will fail, although somewhat later (after December 31, 922,337,203,685,477 and December 31, 17,014,118,346,046,923,173,168,730,371,588,410 respectively). 特定の1万年問題には十分でも、この解法は制限がある。かりに6桁による 年表示に拡張したとしても、それは32bitシステム(そして、将来の32bit システムエミュレータ)において、2148491231(214748年12月31日)という数字で 表記される日以降には誤りを起こし、214849年問題を引き起こす。同じように 64bit,128bitシステムでも、少し先(それぞれ922,337,203,685,477年12月31日、 17,014,118,346,046,923,173,168,730,371,588,410年12月31日以降)ではあるが やはり誤りをおこす。 1.2.3 Granularity Issues 1.2.3 粒度の問題 The granularity problems of a fixed format date can be improved by extending the date format to include greater precision in the date. However, since numerical comparison of dates requires a fixed representation date, an extended format can not provide sufficient resolution for all foreseeable needs. 固定型日付フォーマットにおける粒度の問題は日付のフォーマットをより 精度の高い日付を含むように拡張することで改良することができる。 しかし、数字による日付の比較を行うためには、固定型の日付表現が 必要であり、拡張フォーマットはすべての予見される必要性にについて、 十分な解像度を供給する事はできない。 For instance, if the precision were extended to the femto-second range the date format would become YYYYYMMDDHHMMSSmmmuuunnnpppfff (year, month, day, hour, minute, second, milli-second, micro-second, nano-second, pico-second, and femto-second). The additional 21 digits of this format limit the set of representable dates. Compared to 1.2.2, the 32-bit and 64-bit forms of the date are instantly exceeded, while the 128-bit version would be viable - expiring on December 31, 17,014,118,346,046. 例えば、もし精度がフェムト秒の幅まで広がったとして、日付のフォーマット はYYYYYMMDDHHMMSSmmmuuunnnpppfff (年月日時分秒ミリ秒マイクロ秒ナノ秒 ピコ秒フェムト秒)となる。このフォーマットの追加された21桁の数字によって 表現できる日付は制限される。1.2.2と比較すると、32bitおよび64bitの日付 表現ではすでに越えてしまうし、128bitは実行可能だが - 17,014,118,346,046 年12月31日にはついえてしまう。 1.2.3.1 Extrapolation of Future Granularity Issues 1.2.3.1 将来の粒度についての問題の導出 However, a simple extrapolation of Moore's law shows that even femto-second resolution will soon be inadequate. Projecting current CPU clock speeds forward, a femto-second clock speed will be achieved in only 30 years. And, by the year 10,000 the projected clock speed of the Intel Pentium MMDCLXVI (TM) will be approximately 10 ** (- 1609) seconds. しかし、ムーアの法則から単純に導出すると、フェムト秒の解像度でさえ はすぐに不十分になることがわかる。現在のCPUクロックの進化の早さから 見積もると、フェムト秒クロックのスピードはたった30年後には達成されて しまう。さらに、1万年には、Intel Pentium MMDCLXUI (TM)のクロック スピードを見積もると、おおよそ10の-1609乗秒になる。 This discussion clearly shows that any fixed-format, integer representation of a date is likely to be insufficiently precise for future uses. この議論により、すべての固定長フォーマットの整数による日付表現は 将来的な利用において十分な精度を保てないであろう事が明らかに 示される。 1.2.3.2 Floating Point Is No Solution 1.2.3.2 浮動小数点は解法でない。 The temptation to use floating point numbers to represent dates should be avoided. Like the longer fixed-format, integer representations of the date, floating point representations merely delay the inevitable time when their range is exceeded. In addition, Glassman, et. al. Informational [Page 3] RFC 2550 Y10K and Beyond 1 April 1999 the well known problems of real numbers - rounding, de-normalization, non-uniform distribution, etc. - just add to the problems of dealing with dates. 浮動小数点を日付の表現に利用しようという誘惑は、避けられなければ ならない。長い固定長整数による日付表現と同様に、その表現の幅を超える という避けられない時を単に送らせるなるだけである。加えて、よく しらら手いる実数の問題 - 丸め、非正規化。非統一的配置など - がさらに 日付を扱う上で問題を付け加えるだけである。 2 Structure of Y10K Solution Any Y10K solution should have the following characteristics. 2.1 Compatibility The format must be compatible with existing 4-digit date formats. Y2K compliant programs and standards must continue to work with Y10K dates before the year 10,000. Y10K compliant programs can gradually be developed over time and coexist with non-Y10K compliant programs. 2.2 Simplicity and Efficiency Y10K dates must allow dates after 10,000 to be easily identified. Within a program, there must be a simple procedure for recognizing the Y10K dates and distinguishing them from legacy dates. 2.3 Lexical Sorting Y10K dates must be sortable lexically based on their ASCII representation. The dates must not require specialized libraries or procedures. 2.4 Future Extensibility Y10K dates must support arbitrary precision dates, and should support dates extending arbitrarily far into the future and past. Y10K dates from different eras and with different precisions must be directly comparable and sortable. 2.4.1 Environmental Considerations The known universe has a finite past and future. The current age of the universe is estimated in [Zebu] as between 10 ** 10 and 2 * 10 ** 10 years. The death of the universe is estimated in [Nigel] to occur in 10 ** 11 - years and in [Drake] as occurring either in 10 ** 12 years for a closed universe (the big crunch) or 10 ** 14 years for an open universe (the heat death of the universe). In any case, the prevailing belief is that the life of the universe (and thus the range of possible dates) is finite. Glassman, et. al. Informational [Page 4] RFC 2550 Y10K and Beyond 1 April 1999 2.4.2 Transcending Environmental Considerations However, we might get lucky. So, Y10K dates are able to represent any possible time without any limits to their range either in the past or future. Y10K compliant programs MAY choose to limit the range of dates they support to those consistent with the expected life of the universe. Y10K compliant systems MUST accept Y10K dates from 10 ** 12 years in the past to 10 ** 20 years into the future. Y10K compliant systems SHOULD accept dates for at least 10 ** 29 years in the past and future. 3 Syntax Overview The syntax of Y10K dates consists of simple, printable ASCII characters. The syntax and the characters are chosen to support a simple lexical sort order for dates represented in Y10K format. All Y10K dates MUST conform to these rules. Every Y10K date MUST begin with a Y10K year. Following the year, there MAY be an arbitrary sequence of digits. The digits are interpreted as MMDDHHMMSSmmmuuunnnpppfff... (month, day, hour, minute, second, milli-second, micro-second, nano-second pico-second, femto-second, etc. - moving left to right in the date, digits always decrease in significance). All dates and times MUST be relative to International Atomic Time (TAI) [NRAO]. When comparing dates, a date precedes every other date for which it is a prefix. So, the date "19990401000000" precedes the date "19990401000000000". In particular, dates with the format YYYYMMDD are interpreted to represent the exact instant that the day begins and precede any other date contained in that day. 3.1 Years 1 - 9999 The current 4-digit year syntax covers all years from 1000 - 9999. These years are represented as 4 decimal digits. Leading 0's MUST be added to the years before 1000 to bring the year to 4 digits. Files containing legacy pre-Y1K [Mike] dates will have to be converted. 3.2 Years 10,000 through 99,999 Four digits are not sufficient to represent dates beyond the year 9999. So, all years from 10,000 - 99,999 are represented by 5 digits preceded by the letter 'A'. So, 10,000 becomes "A10000" and 99,999 Glassman, et. al. Informational [Page 5] RFC 2550 Y10K and Beyond 1 April 1999 becomes "A99999". Since 'A' follows '9' in the ASCII ordering, all dates with 5-digit years will follow all dates with 4-digit years (for example, "A10000" will sort after "9999"). This gives us the sort and comparison behaviour we want. 3.3 Years 100,000 up to 10 ** 30 By a simple generalization of 3.2, 6-digit years are preceded by the letter 'B', 7-digit years by 'C', etc. Using just the 26 upper-case ASCII characters, we can cover all years up to 10**30 (the last year representable is "Z999999999999999999999999999999"). Again, since the ASCII characters are sorted alphabetically, all dates sort appropriately. 3.4 Years 10 ** 30 and beyond (Y10**30) As discussed in 2.4.1, the end of the universe is predicted to occur well before the year 10 ** 30. However, if there is one single lesson to be learned from the current Y2K problems, it is that specifications and conventions have a way of out living their expected environment. Therefore we feel it is imperative to completely solve the date representation problem once and for all. 3.4.1 Naive Approach for Y10**30 Problem The naive solution is to prepend a single '^' (caret) - caret sorts after all letters in the ASCII order) before all years from 10 ** 30 to 10 ** 56. Thus the year "Z999999999999999999999999999999" is followed by the year "^A1000000000000000000000000000000". Similarly, all years from 10 ** 56 to 10 ** 82 get one more caret. So, the year "^Z99999999999999999999999999999999999999999999999999999999" is followed by the year "^^A100000000000000000000000000000000000000000000000000000000". This scheme can be extended indefinitely by prepending one addition caret for each additional factor of 10 ** 26 in the range of the year. In this approach, the number of digits in a date that are used to represent the year is simply: 26 * + ASCII() - ASCII('A') + 5 Note: this algorithm is provided for informational purposes only and to show the path leading to the true solution. Y10K dates MUST NOT use this format. They MUST use the format in the next section. Glassman, et. al. Informational [Page 6] RFC 2550 Y10K and Beyond 1 April 1999 3.4.2 Space Efficient Approach for Y10**30 Problem The solution in 3.4.1 is not a space efficient format for giving the number of digits in the year. The length of the prefix grows linearly in the length of the year (which, itself, grows logarithmically over time). Therefore, Y10K format dates use an improved, more compact encoding of the number of digits in the year. 3.4.2.1 Years 10 ** 30 to 10 ** 56 As in 3.4.1, a single '^' and letter precede the year. 3.4.2.2 Years 10 ** 56 to 10 ** 732 The year is preceded by two carets ("^^") and two letters. The letters create a two digit, base 26 number which is the number of digits in the year minus 57. So, the year "^Z99999999999999999999999999999999999999999999999999999999" is followed by the year "^^AA100000000000000000000000000000000000000000000000000000000". The last representable year with two carets is the year (10 ** 732) - 1 and is "^^ZZ999..999" (i.e. two carets and two Z's, followed by 732 consecutive 9's). The formula for the number of digits in the year is, based on the two digit prefix is: 26 * (ASCII() - ASCII('A')) + ASCII() - ASCII('A') + 57 3.4.2.3 Years 10 ** 732 to 10 ** 18308 The next block of years has the number of digits given by three carets ("^^^") followed by three letters forming a three-digit, base 26 number. The number of digits in the year is given by the formula: 676 * (ASCII() - ASCII('A')) + 26 * (ASCII() - ASCII('A')) + ASCII() - ASCII('A') + 733 3.4.2.4 General Format for Y10K Dates In general, if there is at least one letter in a Y10K year, the number of the digits in the year portion of the date is given by the formula: base26(fib(n) letters) + y10k(n) Glassman, et. al. Informational [Page 7] RFC 2550 Y10K and Beyond 1 April 1999 Where "n" is the number of leading carets and the fig, base26 and y10k functions are defined with the following recurrence relations: fib(n) is the standard Fibonacci sequence with: fib(0) = 1 fib(1) = 1 fib(n+2) = fib(n) + fib(n+1) base26(m letters) is the base 26 number represented by m letters A-Z: base26(letter) = ASCII() - ASCII('A') base26(string letter) = 26 * base26(string) + base26(letter) y10k(n) is the necessary fudge factor to align the sequences properly: y10k(0) = 5 y10k(n+1) = 26 ** fib(n) + y10k(n) If the year does not have at least one letter in the year, then the number of digits in the year is: 4 This year format is space-efficient. The length of the prefix giving number of digits in the year only grows logarithmically with the number of digits in the year. And, the number of carets preceding the prefix only grows logarithmically with the number of digits in the prefix. 3.5 B.C.E. (Before Common Era) Years Now that have a format for all of the years in the future, we'll take on the "negative" years. A negative year is represented in "Y10K- complement" form. A Y10K-complement year is computed as follows: 1) Calculate the non-negative Y10K year string as in 3.4.2.4. 2) Replace all letters by their base 26 complement. I.E. A -> Z, B -> Y, ... Z -> A. 3) Replace all digits in the year portion of the date by their base 10 complement. I.E. 0 -> 9, 1 -> 8, ... 9 -> 0. 4) Replace carets by exclamation points ('!'). 5) Four-digit years are pre-pended with a slash ('/') Glassman, et. al. Informational [Page 8] RFC 2550 Y10K and Beyond 1 April 1999 6) Years that don't now begin with an exclamation point or slash are pre-pended with a star ('*'). (This rule covers the negative 5- 31 digit years). For example, the year 1 BCE is represented by "/9998". The conversion is accomplished by applying rules: 1) Calculate the non-negative Y10K year ("1" -> "0001") 2) Complement the digits ("0001" -> "9998") 3) Four-digit numbers get a leading slash. The earliest four-digit BCE year (9999 BCE) becomes "/0000" and the year before that (10000 BCE) becomes "*Z89999". The earliest 5-digit BCE year (99999 BCE) is "*Z00000". And the year before that (100000 BCE) is "*Y899999". And so on. These rules give the desired sort order for BCE dates. For example, the following dates get translated and sorted as: Jun 6, 200 BCE /97990606 199 BCE /9800 Jan 1, 199 BCE /98000101 3.6 Restrictions on Y10K Dates There are no restrictions on legal values for Y10K dates. Y10K compliant programs MUST accept any syntactically legal Y10K date as a valid date. A '0' can be appended to the end of any Y10K date, yielding an equivalent date that sorts immediately after the original date and represents the instant after the original date. The following are all valid representations (in sorted order) of the first instant of A10000: A1 A10000 A1000001 A100000101000000 A1000001010000000000000000000000 Similarly, the following are all valid Y10K dates (in sorted order) for the time after the last instant of the A99999 and before the first instant of B100000: A999991231250000 A999991232 A999992 A9999999999 A99999999990000000000000 Glassman, et. al. Informational [Page 9] RFC 2550 Y10K and Beyond 1 April 1999 4 ABNF The following ABNF [Crocker] gives the formal syntax for Y10K years. The initial characters definitions are given in their lexical collation (ASCII) order. exclamation = '!' star = '*' slash = '/' digit = 0 | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 letter = A | B | C | D | E | F | G | H | I | J | K | L | M | N | O | P | Q | R | S | T | U | V | W | X | Y | Z caret = '^' year = [*(caret | exclamation) | star | slash ] [ *letter ] *digit month = 2digit day = 2digit hour = 2digit minute = 2digit second = 2digit fraction = *digit date = year [ month [ day [ hour [ minute [ second [ fraction ]]]]]] 5 Open Issues There are a number date comparison problems that are beyond the scope of this specification. 1) Dates from different calendar systems can not be directly compared. For instance, dates from the Aztec, Bhuddist, Jewish, Muslim, and Hittite calendars must be converted to a common calendar before comparisons are possible. 2) Future re-numberings of years are not covered. If, and when, a new "Year 0" occurs and comes into general use, old dates will have to be adjusted. 3) Continued existence of Earth-centric time periods (year, day, etc.) are problematical past the up-coming destruction of the solar system (5-10 billion years or so). The use of atomic-time helps some since leap seconds are no longer an issue. Glassman, et. al. Informational [Page 10] RFC 2550 Y10K and Beyond 1 April 1999 4) Future standards and methods of synchronization for inter- planetary and inter-galactic time have not been agreed to. 5) Survivability of dates past the end of the universe is uncertain. 6 Affected Standards A number of standards currently and RFCs use 4-digit years and are affected by this proposal: rfc2459: Internet X.509 Public Key Infrastructure Certificate and CRL Profile rfc2326: Real Time Streaming Protocol (RTSP) rfc2311: ODETTE File Transfer Protocol rfc2280: Routing Policy Specification Language (RPSL) rfc2259: Simple Nomenclator Query Protocol (SNQP) rfc2244: ACAP -- Application Configuration Access Protocol rfc2167: Referral Whois (RWhois) Protocol V1.5 rfc2065: Domain Name System Security Extensions rfc2060: Internet Message Access Protocol - Version 4rev1 rfc1922: Chinese Character Encoding for Internet Messages rfc1912: Common DNS Operational and Configuration Errors rfc1903: Textual Conventions for Version 2 of the Simple Network Management Protocol (SNMPv2) rfc1521: MIME (Multipurpose Internet Mail Extensions) Part One: rfc1123: Requirements for Internet hosts - application and support The following standards internally represent years as 16-bit numbers (0..65536) and are affected by this proposal: rfc2021: Remote Network Monitoring Management Information Base Version 2 using SMIv2 rfc1514: Host Resources MIB The following ISO standard is affected: ISO8601: International Date Format 8 Security Considerations Y10K dates will improve the security of all programs where they are used. Many errors in programs have been tracked to overflow while parsing illegal input. Programs allocating fixed size storage for dates will exhibit errors when presented with larger dates. These errors can be exploited by wily hackers to compromise the security of systems running these programs. Since Y10K dates are arbitrary length strings, there is no way to make them overflow. Glassman, et. al. Informational [Page 11] RFC 2550 Y10K and Beyond 1 April 1999 In addition, positive Y10K dates are easy to compare and less error- prone for humans. It is easier to compare the three projected end of the universe dates - "H100000000000", "I1000000000000" and "K100000000000000" - by looking at the leading letter than by counting the 0's. This will reduce inadvertent errors by people. This advantage will become more noticeable when large dates are more common. Unfortunately, negative Y10K dates are a bit more difficult to decipher. However, by comparing the current age of the universe to its projected end, it is obvious that there will be many more positive dates than negative dates. And, while the number of negative dates for human history is currently greater than the number of positive dates, the number of negative dates is fixed and the number of positive dates is unbounded. 9 Conclusion It is not too early to aggressively pursue solutions for the Y10K problem. This specification presents a simple, elegant, and efficient solution to this problem. 10 References [Crocker] Crocker, D. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", RFC 2234, November 1997. [Drake] Review for the Drake Equation http://www.umsl.edu/~bwilking/assign/drake.html [Microsoft] SNMP SysUpTime Counter Resets After 49.7 Days http://support.microsoft.com/support/kb/articles/Q169/ 8/47.asp [Mike] Y1K http://lonestar.texas.net/~mdlvas/y1k.htm [Nigel] Nigel's (en)lighening tour of Thermodynamics for Economists ;-) http://www.santafe.edu/~nigel/thermo- primer.html [NRAO] Astronomical Times http://sadira.gb.nrao.edu/~rfisher/Ephemerides/times.html [RFC] Here are all the online RFCs. Note: this is a LONG menu. http://info.internet.isi.edu/1s/in-notes/rfc/files [UNIX] Year 2000 Issues http://www.rdrop.com/users/caf/y2k.html Glassman, et. al. Informational [Page 12] RFC 2550 Y10K and Beyond 1 April 1999 [Wilborne] PktCDateLig http://www3.gamewood.net/mew3/pilot/pocketc/pktcdate/ index.html [YUCK] Y10K Unlimited Consulting Knowledgebase http://www.loyd.net/y10k/index.html [Zebu] The Search for H0 http://zebu.uoregon.edu/1997/ph410/l6.html 11 Authors' Addresses Steve Glassman Compaq Systems Research Center 130 Lytton Avenue Palo Alto, CA 94301 USA Phone: +1 650-853-2166 EMail: steveg@pa.dec.com Mark Manasse Compaq Systems Research Center 130 Lytton Avenue Palo Alto, CA 94301 USA Phone: +1 650-853-2221 EMail: msm@pa.dec.com Jeff Mogul Compaq Western Resarch Lab 250 University Avenue Palo Alto, CA 94301 USA Phone: +1 650-617-3300 EMail: mogul@pa.dec.com Glassman, et. al. Informational [Page 13] RFC 2550 Y10K and Beyond 1 April 1999 12. Full Copyright Statement Copyright (C) The Internet Society (1999). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Glassman, et. al. Informational [Page 14]