rfc2550.txt

中、英文RFC文档大全打包下载完全版 .


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(<letter>) - 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: [phone]
   EMail: [e-mail]


   Mark Manasse
   Compaq Systems Research Center
   130 Lytton Avenue
   Palo Alto, CA 94301 USA

   Phone: [phone]
   EMail: [e-mail]


   Jeff Mogul
   Compaq Western Resarch Lab
   250 University Avenue
   Palo Alto, CA 94301 USA

   Phone: [phone]
   EMail: [e-mail]














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]