RFC 2626
RFC 2626
Nesser II
Request for Comments: 2626 Nesser & Nesser Consulting
Category: Informational June 1999
Copyright Notice
Abstract
The Year 2000 Working Group (WG) has conducted an investigation into
the millennium problem as it regards Internet related protocols.
This investigation only targeted the protocols as documented in the
Request For Comments Series (RFCs). This investigation discovered
little reason for concern with regards to the functionality of the
protocols. A few minor cases of older implementations still using
two digit years (ala RFC 850) were discovered, but almost all
Internet protocols were given a clean bill of health. Several cases
of "period" problems were discovered, where a time field would "roll
over" as the size of field was reached. In particular, there are
several protocols, which have 32 bit, signed integer representations
of the number of seconds since January 1, 1970 which will turn
negative at Tue Jan 19 03:14:07 GMT 2038. Areas whose protocols will
be effected by such problems have been notified so that new revisions
will remove this limitation.
1. Introduction
2. Disclaimer
adopted.
HTTP 1.1, as defined in RFC 2068, requires all newly generated date
stamps to conform to RFC 1123 date formats which are Year 2000
compliant, but it also requires acceptance of the older non-compliant
RFC850 formats. Some specific recommendations have been passed to
the HTTP WG.
HTML 2.0, as defined in RFC 1866, could allow a very subtle Year 2000
problem, but once again this recommendation has been passed on the
HTML WG.
RFCs 821 and 822, the main basis for SMTP mail exchange and message
format, originally required two-digit years. However, both of these
RFCs were later modified by RFC 1123 in 1989, which strongly
recommended 4-digit years.
There does exist a problem in both NNTP, RFC 977, and the Usenet News
Message Format, RFC 10336. They both specify two-digit year format.
A working group has been formed to update the network news protocols
in general, and addressing this problem is on their list of work
items.
A Year 2000 problem does occur in the Simple Network Paging Protocol,
versions 2 & 3. Both define a HOLDuntil option which uses a
YYMMDDHHMMSS+/-GMT field. Version 3 also defines a MSTAtus command,
which is required to store,dates and times as YYMMDDHHMMSS+/-GMT.
3.8 "Security"
RFCs 1421-1424 specifies that PEM uses UTC time formats which could
have a Millennium issue.
DNS Security uses 32-bit timestamps which will roll over in 2038.
This issue has been refered to the appropriate Working Group so that
the details of rollover can be established.
4.2 "Routing"
5. Suggested Solutions
The real solution to the problem is to use 4 digit year fields for
applications and hardware systems. For counters that key off of a
certain time (January 1, 1970 for example) need to either: define a
wrapping solution, or to define a larger number space (greater than
32-bits), or to make more efficient use of the 32-bit space. However,
This solution has two advantages. First, no new fixed year problems
are introduced. Second, different applications and protocols could
choose different values of N. The drawback is that this solution is
harder to implement, and to work well the value of N will need to be
constant across different implementations.
6. Methodology
The first task was dividing the types of RFC's into logical groups
rather than the strict numeric publishing order. Sixteen specific
areas were identified. They are: "Autoconfiguration" , "Directory
Services", "Disk Sharing", "Games and Chat" ,"Information Services &
File Transfer", "Network & Transport Layer", "Electronic Mail",
"NTP", Name Serving", "Network Management", "News", "Real Time
Services", "Routing", "Security", "Virtual Terminal", and "Other".
In addition to these categories, many hundreds of RFC's were
immediately eliminated based on content. That is not to say that all
Informational RFC's were not considered, many did contain some
technical content or overview whichdemanded scrutiny.
- date
- GMT
- UTCTime
- year
- yy (that is not part of yyyy)
- two-digit, 2-digit, 2digit
- century
- 1900 & 2000
After the documents were scanned, therefore, each "hit" was examined
individually. Those that cause no Year 2000 problems (e.g., those
that encode the year as a two-byte integer, or as a four-character
display string) are not discussed here. Those that do cause Year
2000 problems are identified in this document, and the nature and
impact of the problems they cause are described.
7. Autoconfiguration
7.1 Summary
The RFC's which were categorized into this group were primarily the
BOOT Protocol (BOOTP) and the Dynamic Host Configuration Protocol
(DHCP) for both IP version four and six.
7.2 Specifics
RFC 1533 enumerates all the known DHCP field types and a number of
these have to do with time. Section 3.4 defines a "Time Offset"
field which specifies the offset of the clients subnet in seconds
from UTC. This 4 byte field has no millennium issues. Section 9.2
defines the IP Address Lease Time field which is used by clients to
request a specific lease time. This four byte field is an unsigned
integer containing a number of seconds. Section 9.9 defines a
Renewal Time Value field, Section 9.10 defines a Rebinding Time
Value, both of which are similarly 32 bit fields, which have no
millennium issues.
RFC 1541 has two mentions of times/dates. The first is the "secs"
field which, similarly to RFC 951, is a 16-bit field for the number
of seconds since the host has booted. There is also a discussion in
section 3.3 about "Interpretation and Representation of Time Values"
which while clearly states that there is no millennium or period
problems.
8. Directory Services
8.1 Summary
The RFC's which were categorized into this group were primarily X.500
related RFC's, Whois, Rwhois, Whois++, and the Lightweight Directory
Access Protocol (LDAP).
8.2 Specifics
Two RFC's have unusual date specifications and specify their own date
format. Both of these support Y2K compliant dates.
RFC1714 (RWhois) specifies date formats that are not Y2K compliant,
but it also supports dates that are. Implementers of the RWhois
protocol should only use the %MY4 format
9. Disk Sharing
9.1 Summary
The RFC's which were categorized into this group were those related
to the Network File System (NFS). Other popular disk sharing
protocols like SMB and AFS were referred to their respective
trustee's for review.
9.2 Specifics
The references to time in this protocol are the times of file data
modification, file access, and file metadata change (mtime, atime,
and time, respectively). These times are kept as 32 bit unsigned
quantities in seconds since 1970-01-01, and so the NFS protocol will
not experience an Epoch event until the year 2106.
10.1 Summary
The RFC's which were categorized into this group were related to the
Internet Relay Chat Protocol (IRC). No millennium problems exist in
the IRC protocol.
10.2 Specifics
11.1 Summary
The RFC's which were categorized into this group were divided among
World Wide Web (WWW) protocols and File Transfer Protocols (FTP).
WWW protocols include the Hypertext Transfer Protocol (HTTP), a
variety of Uniform Resource formats (URL, URAs, etc.) and the
HyperText Markup Language(HTML). FTP protocols include the well
known FTP protocol, the Trivial File Transfer Protocol (TFTP) and a
variety of extensions to these protocols. Other information services
includes the Finger Protocol and the LPD protocol.
HTTP 1.1, as defined in RFC 2068, requires all newly generated date
stamps to conform to RFC 1123 date formats which are Year 2000
compliant, but it also requires acceptance of the older non-compliant
RFC850 formats. Some specific recommendations are listed below and
have been passed to the HTTP WG.
HTML 2.0, as defined in RFC 1866, could allow a very subtle Year 2000
problem, but once again this recommendation has been passed on the
HTML WG.
11.2 Specifics
Sun, 06 Nov 1994 08:49:37 GMT ; RFC 822, updated by RFC 1123
This avoids a "stale cache" problem, which would cause the user to
see out-of-date data.
<META HTTP-EQUIV="Expires"
CONTENT="Tue, 04 Dec 1993 21:29:02 GMT">
RFC 1784 on TFTP Timeout Intervals and Transfer Size Options uses a
field for the number of seconds for the timeout. It is an ASCII
value from 1 to 255 octets in length. There is no Y2K issue.
RFC 1068 on the Background File Transfer Protocol (BFTP) defines two
commands in Sections B.2.12 and B.2.13, the Submit and Time commands.
>From the example usage's given in Appendix C it is clear that this
protocol will function correctly though the year 9999.
RFC 978 on the Voice File Interchange Protocol defines the Total Time
of a message to be a 32-bit number of deci-seconds. This limits the
size of a message but has no millennium issues.
RFCs 2122, 2056, 2055, 2054, 2044, 2016, 1960, 1959, 1874, 1865, 1862,
1843, 1842, 1823, 1815, 1808, 1798, 1785, 1783, 1782, 1779, 1766,
1738, 1737, 1736, 1729, 1728, 1727, 1639, 1633, 1630, 1625, 1554,
1545, 1530, 1529, 1528, 1489, 1486, 1436, 1415, 1413, 1350, 1345,
1312, 1302, 1288, 1278, 1241, 1235, 1196, 1194, 1179, 1123, 1003, 971,
965, 959, 949, 913, 887, 866, 865, 864, 863, 862, 797, 795, 783, 775,
765, 751, 743, 742, 740, 737, 725, 722, 707, 691, 683, 662, 640, 624,
614, 607, 599, 412, 411, 410, 407, and 406 were found to have no
references to dates or times, and hence no millennium issues.
RFCs 712, 697, 633, 630, 622, 610, 593, 592, 589, 573, 571, 570, 553,
551, 549, 543, 535, 532, 525, 520, 514, 506, 505, 504, 501, 499, 493,
490, 487, 486, 485, 480, 479, 478, 477, 472, 468, 467, 463, 454, 451,
448, 446, 438, 437, 436, 430, 429, 418, 414, and 409 were not
available for review.
12.1 Summary
The RFC's which were categorized into this group were the Internet
Protocol (IP) versions four and six, the Transmission Control
Protocol (TCP), the User Datagram Protocol (UDP), the Point-to-Point
Protocol (PPP) and its extensions, Internet Control Message Protocol
(ICMP), the Address Resolution Protocol (ARP) and Remote Procedure
Call (RPC) protocol. A variety of less known protocols were also
examined.
12.2 Specifics
RFC 2097 on the PPP NetBIOS Frame Control Protocol discuesses several
timer and timeouts in Section 2.1, none of which suffers from a year
2000 problem.
RFC 2075 on the IP Echo Host Service discusses timestamps and has no
millennium issues.
RFC 2002 on IP Mobility Support uses a 16-bit field for the lifetime
of a connection and notes the 18.2 hour limitation that this imposes.
Section 5.6.1 on replay protection requires the use of 64-bit time
fields, of a similar format to NTP packets.
RFC 1981 on Path MTU Discovery for IPv6 discusses timestamps and
their potential use to purge stale information in section 5.3. There
is no millennium issues in this use.
RFC 1963 on the PPP Serial Data Transport Protocol defines a flow
expiration time in section 4.9 which has no year 2000 issues.
RFC 1761 on Snoop Version 2 Packet Capture File Format discusses two
32-bit timestamp values on Section 4 on Packet Record Formats. The
first of these may wrap in the year 2038, but should not effect
anything of any import.
RFC 1755 on ATM Signalling Support for IP Over ATM discusses timing
issues in Section 3.4 on VC Teardown. These limited timers have no
year 2000 issues.
RFC 1661 on PPP defines three timers in Section 4.6, none of which
have any year 2000 issues.
RFC 1644 on T/TCP (TCP Extensions for Transactions) mentions RFC 1323
and the extended timers recommended in it.
RFC 1575 defines an echo function for CNLP discusses in the narrative
the use of the Lifetime Field in Section 5.3. There is nothing to
suggest that there is any year 2000 issues.
RFC 1329 on Dual MAC FDDI Networks discusses ARP cache administration
in Section 9.3 and 9.4 and various timers to expire entries.
RFC 781 was defines the same option which is codified in RFC 791 as a
packet type 68.
RFC's 2126, 2118, 2113, 2107, 2106, 2105, 2098, 2067, 2043, 2023,
2019, 2018, 2009, 2004, 2003, 2001, 1994, 1993, 1990, 1989, 1979,
1978, 1977, 1976, 1975, 1974, 1973, 1972, 1967, 1962, 1954, 1946,
1937, 1936, 1934, 1933, 1932, 1931, 1926, 1924, 1919, 1918, 1917,
1916, 1915, 1897, 1888, 1887, 1885, 1884, 1883, 1881, 1878, 1877,
1868, 1860, 1859, 1853, 1841, 1832, 1831, 1809, 1795, 1791, 1770,
1764, 1763, 1756, 1754, 1752, 1744, 1735, 1726, 1719, 1717, 1710,
1707, 1705, 1698, 1693, 1688, 1687, 1686, 1683, 1682, 1681, 1680,
1679, 1678, 1677, 1676, 1674, 1673, 1672, 1671, 1670, 1669, 1667,
1663, 1662, 1638, 1634, 1631, 1629, 1624, 1622, 1621, 1620, 1619,
1618, 1613, 1605, 1604, 1598, 1590, 1577, 1570, 1561, 1560, 1553,
1552, 1551, 1549, 1548, 1547, 1538, 1526, 1518, 1498, 1490, 1483,
1475, 1466, 1454, 1435, 1434, 1433, 1393, 1390, 1385, 1379, 1378,
1377, 1376, 1375, 1374, 1365, 1363, 1362, 1356, 1347, 1337, 1335,
1334, 1333, 1332, 1331, 1326, 1323, 1314, 1307, 1306, 1294, 1293,
1277, 1263, 1240, 1237, 1236, 1234, 1226, 1223, 1220, 1219, 1210,
1209, 1201, 1191, 1188, 1185, 1172, 1171, 1166, 1162, 1151, 1146,
1145, 1144, 1141, 1139, 1134, 1132, 1122, 1110, 1106, 1103, 1088,
1086, 1085, 1078, 1072, 1071, 1070, 1069, 1063, 1062, 1057, 1055,
1051, 1050, 1046, 1045, 1044, 1042, 1030, 1029, 1027, 1025, 1016,
1008, 1007, 1006, 1002, 1001, 994, 986, 983, 982, 970, 964, 963, 962,
955, 948, 942, 941, 940, 936, 935, 932, 926, 925, 924, 922, 919, 917,
914, 905, 903, 896, 895, 894, 893, 892, 891, 889, 879, 877, 874, 872,
871, 848, 829, 826, 824, 815, 814, 813, 801, 793, 789, 787, 777, 768,
761, 760, 759, 730, 704, 696, 695, 692, 690, 689, 687, 685, 680, 675,
674, 660, 632, 626, 613, 611 were reviewed but were found to have no
millennium references.
RFC's 594, 591, 576, 550, 548, 528, 521, 489, 488, 473, 460, 459, 450,
449, 445, 442, 434, 426, 417, 398, 395, 394, 359, 357, 348, 347, 346,
343, 312, 301, 300, 271, 241, 210, 203, 202, 197, 190, 178, 176, 175,
166, 165, 161, 151, 150, 146, 145, 143, 142, 128, 127, 123, 122, 93,
91, 80, 79, 70, 67, 65, 62, 60, 59, 56, 55, 54, 53, 41, 38, 33, 23,
22, 20, 19, 17, 12 were deemed too old to be considered for millennium
investigation.
13.1 Summary
The RFC's which were categorized into this group were the Simple Mail
Transfer Protocol (SMTP), Internet Mail Access Protocol (IMAP), Post
Office Protocol (POP), Multipurpose Internet Mail Exchange (MIME),
and X.400 to SMTP interaction.
13.2 Specifics
RFCs 821 and 822, the main basis for SMTP mail exchange and message
format, originally required two-digit years. However, both of these
RFCs were later modified by RFC 1123 in 1989, which strongly
recommended 4-digit years. Although there might be a few very old
SMTP systems using two-digit years, it is believed that almost all
mail sent over the Internet today uses four-digit years. Mail that
contains two-digit years in its SMTP headers will not "fail", but
might be mis-sorted in message stores and mail user agents. This
problem is avoided entirely by taking the RFC 1123 change as a
requirement, rather than merely as a recommendation.
RFC 1153 describes a format for digests of mailing lists, and uses
two-digit dates. This format is not widely used. The use of two-digit
dates could possibly cause missorting of stored messages.
RFC 1327, which describes mapping between X.400 mail and SMTP mail,
uses the UTCTime format.
14.1 Summary
The RFC's which were categorized into this group were the Network
Time Protocol (NTP), and the Time Protocol.
NTP has been certified year 2000 compliant, while the Time Protocol
will "roll over" at Thu Feb 07 00:54:54 2036 GMT. Since NTP is the
current defacto standard for network time this does not seem to be an
issue.
14.2 Specifics
...
15.1 Summary
The RFC's which were categorized into this group were the Domain Name
System (DNS), it's advanced add on features (Incremental Zone
Transfer, etc.).
There have been no year 2000 relayed problems found with the DNS
protocols, or common implementations of them.
15.2 Specifics
16 Network Management
16.1 Summary
The RFC's which were categorized into this group were the Simple
Network Management Protocol (SNMP), a large number of Management
Information Bases (MIBs) and the Common Management Information
Protocol over TCP/IP (CMOT).
Although a few discrepancies have been found and outlined below, none
of them should have an impact on interoperability.
16.2 Specifics
The standards for CMOT specify an unusual use for the GeneralizedTime
type. (GeneralizedTime has a four-digit representation of the year.)
If the system generating the PDU does not have the current time, yet
does have the time since last boot, then GeneralizedTime can be used
to encode this information. The time since last boot will be added
to the base time "0001 Jan 1 00:00:00.00" using the Gregorian
calendar algorithm.
This is really a "Year 0" problem rather than a Year 2000 problem,
and in any case, CMOT is not currently deployed.
YYMMDDHHMMZ
The first usage of UTCTime in the standards for SNMP definitions goes
all the way back to RFC 1303. It has persisted unchanged up through
the current specifications in RFC 1902. The role of UTCTime in SNMP
definitions is to record the history of an SNMP MIB module in the
module itself, via two ASN.1 macros:
o LAST-UPDATED
o REVISION
There are two objects in the Printer MIB that allow use of a date as
an object value with no explicit guidance for formatting the value.
The objects are prtInterpreterLangVersion and prtInterpreterVersion.
Both are defined with a syntax of OCTET STRING. The descriptions for
the objects allow the object value to contain a date, version code or
other product specific information to identify the interpreter or
language. The descriptions do not include an explicit statement
recommending use of a four-digit year when a date is used as the
object value.
The RFC specifies trace headers and footers with date fields that are
character arrays of size 32. While 32 characters certainly provide
enough room for a four-digit year, there's no explicit statement that
these years must be represented with four digits.
17 Network News
17.1 Summary
The RFC's which were categorized into this group were related to the
Network News Protocol (NNTP).
There does exist a problem in both NNTP, RFC 977, and the Usenet News
Message Format, RFC 10336. They both specify two-digit year format.
A working group has been formed to update the network news protocols
in general, and addressing this problem is on their list of work
items.
17.2 Specifics
The NNTP transfer protocols defined in RFC 977. Sections 3.7.1, the
definition of the NEWGROUPS command, and 3.8.1, the NEWNEWS command,
that dates must be specified in YYMMDD format.
The format for USENET news messages is defined in RFC 1036. The Date
line is defined in section 2.1.2 and it is specified in RFC-822
format. It specifically disallows the standard UNIX ctime(3) format,
which would allow for four digit years. Section 2.2.4 on Expires
also mandates the same two-digit year format.
18.1 Summary
The RFC's which were categorized into this group were related to IP
Multicast, RTP, and Internet Stream Protocol. A Year 2000 problem
does occur in the Simple Network Paging Protocol, versions 2 & 3.
Both define a HOLDuntil option which uses a YYMMDDHHMMSS+/-GMT field.
Version 3 also defines a MSTAtus command, which is required to store,
dates and times as YYMMDDHHMMSS+/-GMT.
18.2 Specifics
RFC 2102 discusses Multicast support for NIMROD and has no mention of
dates or time. RFC 2090 on TFTP Multicast options is also free from
any date/time references.
Similarly RFC 2035 on the RTP JPEG format defines the same timestamp
in section 3. RFC 2032 on RTP H.261 video streams uses a calculated
time based on the original frame so once again there is no millennium
issue. RFC 2029 on the RTP format for Sun's CellB video encoding
mentions the RTP timestamp in section 2.1.
RFC 2022 defines support for multicast over UNI 3.0/3.1 based ATM
networks. Section 5. defines a timeout value for connections
between one and twenty minutes. Section 5.1.1 discusses several
timers that are bound between five and ten seconds, while 5.1.3
requires an inactivity timer, which should also run between one and
twenty minutes. Sections 5.1.5, 5.1.5.1, 5.1.5.2, 5.2.2, 5.4, 5.4.1,
5.4.2, 5.4.3, 6.1.3 and Appendix E all defines numerous timers, none
of which have any millennium issues.
RFC 1890 on RTP profiles for audio and video conferences discusses a
sampling frequency which has no issues. RFC 1889 on RTP discusses
time formats in section 4, as the same 64 bit unsigned integer format
that NTP uses. There is a "period" problem, which will occur in the
year 2106. Section 5.1 is a more formalized discussion of the
timestamp properties, while Section 6.3.1 discusses a variety of
different timers all using the 64 bit field format, or a compressed
32-bit version of the inner octet of bytes. Section 8.2 discusses
loop detection and how the various timers are used to determine if
looping occurs.
RFC 1861 on Version 3 of the Simple Network Paging Protocol does have
a Year 2000 problem. The protocol defines a HOLDuntil command in
section 4.5.6 and a MSTAtus command in section 4.6.10, both of which
require dates/times to be stored as YYMMDDHHMMSS+/-GMT. Clearly this
format will be invalid after the end of 1999.
RFC 1193 on Client Requirements for Real Time Services talks about
time in section 4.4, but there are no Year 2000 issues. RFC 1190
have been obsoleted by RFC 1819, but the hello timer issues are
similar.
RFCs 1789, 1768, 1703, 1614, 1569, 1568, 1546, 1469, 1453, 1313,
1257, 1197, 1112, 1054, 988, 966, 947, 809, 804, 803, 798, 769, 741,
511, 508, 420, 408 and 251 contain no date or time references.
19. Routing
19.1 Summary
The RFC's which were categorized into this group were Routing
Information Protocol (RIP), the Open Shortest Path First (OSPF)
protocol, Classless InterDomain Routing (CIDR),the Border Gateway
Protocol (BGP), and the InterDomain Routing Protocol (IDRP).
After careful examination both BGP and RIP have been found Year 2000
compliant.
19.2 Specifics
and the Over-Subscription Timer (6.4) are all counters, which have no
millennium, issues. RFC 2081 on the applicability of RIPng discusses
deletion of routes for a variety of issues, one of which is the
garbage- collection timer exceeds 120 seconds. There are no Year
2000 issues. RFC 2080 on RIPng for IPv6, discusses various times in
section 2.6, none of which have any millennium problems.
RFC 1771 defines the Border Gateway Protocol (BGP). BGP does not
have knowledge of absolute time, only relative time. There are five
timers defined: Hold Timer, ConnectRetry Timer, KeepAlive Timer,
MinRoueAdvertisementInterval and MinASOriginationInterval. There are
no known issues regarding BGP and the millennium.
RFC 1583, OSPF, there are two types of timers defined in section 4.4,
single-shot timers and interval timers. There are a number of timers
defined in Section 9 including: HelloInterval, RouterDeadInterval,
InfTransDelay, Hello Timer, Wait Timer and RxmtInterval. Section 10
also defines the Inactivity Timer. No millennium problem exists for
any of these timers.
RFC 1058 on RIP discusses the 30-second timers in section 3.3. There
is no millennium issues related to RIP.
RFC 911 on EGP on Berkeley Unix recommend timer values of 30 and 120
seconds.
RFC 904 which defines the Exterior Gateway Protocol (EGP). There are
a number of timers discussed in sections 4.1.1 and 4.1.4. None of
these timers suffer from any relevant problems.
RFCs 2103, 2092, 2073, 2072, 2042, 2008, 1998, 1997, 1992, 1966, 1955,
1940, 1930, 1925, 1923, 1863, 1817, 1812, 1793, 1787, 1774, 1773,
1772, 1765, 1753, 1745, 1723, 1722, 1721, 1716, 1702, 1701, 1668,
1656, 1655, 1654, 1587, 1586, 1585, 1581, 1520, 1519, 1517, 1482,
1476, 1439, 1403, 1397, 1388, 1387, 1383, 1380, 1371, 1370, 1364,
1338, 1322, 1268, 1267, 1266, 1265, 1264, 1254, 1246, 1245, 1222,
1195, 1164, 1163, 1142, 1136, 1133, 1126, 1125, 1124,1104, 1102, 1092,
1009, 985, 981, 975, 950, 898, 890, 888, 875, and 823 contain no date
or time references.
20. Security
20.1 Summary
The RFC's which were categorized into this group were kerberos
authentication protocol, Remote Authentication Dial In User Service
(RADIUS), One Time Password System (OTP), Privacy Enhanced Mail
(PEM), security extensions to a variety of protocols including (but
not limited to) RIPv2, HTTP, MIME, PPP, IP, Telnet and FTP.
RFCs 1421-1424 specifies that PEM uses UTC time formats which could
have a Millennium issue since the year specification only provides
the last two digits of the year.
20.2 Specifics
RFC 2078 on the GSSAPI Version 2 defines numerous calls that use
timers for inputs and outputs. Sections 2.1.1, 2.1.3, 2.1.4, 2.1.5,
2.2.1, 2.2.2, 2.2.5 and 2.2.6 all use the lifetime_rec field, which
is defined as an integer counter in seconds. There should be no
relevant problems with this protocol.
RFC 2035 on the Simple Public Key GSSAPI Mechanism talks about secure
timestamps in the background and overview sections only in an
expository manner.
RFC 1969 on the PPP DES Encryption Protocol uses time as an example
in Section 4 when discussing how to encrypt the first packet of a
stream. It is suggested that the first 32 bits be used for the
number of seconds since January 1, 1970. There could thus be a
potential operations problem in 2038.
RFCs 1113, 1114, and 1115 specify the original version of PEM and
have been obsoleted bye 1421, 1422, 1423, & 1424.
RFCs 2104, 2085, 2084, 2057, 2040, 2015, 1984, 1968, 1964, 1961, 1949,
1948, 1938, 1929, 1928, 1858, 1852, 1851, 1829, 1828, 1827, 1826,
1825, 1824, 1760, 1751, 1750, 1704, 1675, 1579, 1535, 1511, 1492,
1457, 1455, 1423, 1416, 1412, 1411, 1409, 1408, 1321, 1320, 1319,
1281, 1244, 1186, 1170, 1156, 1108, 1004, 972, 931, 927, 912, and 644
contain no date or time references.
21.1 Summary
The RFC's which were categorized into this group were Telnet and its
many extensions, as well as the Secure SHell (SSH) protocol. The X
window system was not considered since it is not an IETF protocol.
Official acknowledgement by the trustee's of the X window system was
given that they will examine the protocol.
Unencrypted Telnet and TN3270 have both been found to be Year 2000
Compliant. The SSH protocols are also Year 2000 compliant.
21.2 Specifics
RFCs 2066, 1647, 1576, 1572, 1571, 1372, 1282, 1258, 1221, 1205, 1184,
1143, 1116, 1097, 1096, 1091, 1080, 1079, 1073, 1053, 1043, 1041,
1005, 946, 933, 930, 929, 907, 885, 884, 878, 861, 860, 859, 858, 857,
856, 855, 854, 851, 818, 802, 782, 779, 764, 749, 748, 747, 746, 736,
735, 734, 732, 731, 729, 728, 727, 726, 721, 719, 718, 701, 698, 658,
657, 656, 655, 654, 653, 652, 651, 647, 636, 431, 399, 393, 386, 365,
352, 340, 339, 328, 311, 297, 231, and 215 contain no date or time
references.
RFCs 703, 702, 688, 679, 669, 659, 600, 596, 595, 587, 563, 562, 560,
559, 513, 495, 470, 466, 461, 447, 435, 377, 364, 318, 296, 216, 206,
205, 177, 158, 139, 137, 110, 97 were unavailable.
22. Other
22.1 Summary
22.2 Specifics
RFCs 2123, 2036, 2014, 2000, 1999, 1958, 1935, 1900, 1879, 1855, 1822,
1814, 1810, 1799, 1776, 1718, 1715, 1700, 1699, 1640, 1627, 1610,
1607, 1601, 1600, 1599, 1594, 1580, 1578, 1574, 1550, 1540, 1539,
1527, 1499, 1463, 1462, 1438, 1410, 1402, 1401, 1391, 1367, 1366,
1360, 1359, 1358, 1349, 1340, 1336, 1325, 1324, 1300, 1291, 1287,
1261, 1250, 1249, 1206, 1200, 1199, 1177, 1175, 1174, 1152, 1149,
1140, 1135, 1127, 1118, 1111, 1100, 1099, 1077, 1060, 1039, 1020,
1019, 999, 997, 992, 990, 980, 960, 945, 944, 943, 939, 909, 902, 900,
899, 873, 869, 846, 845, 844, 843, 842, 840, 839, 838, 837, 836, 835,
834, 833, 832, 831, 820, 817, 800, 776, 774, 770, 766, 762, 758, 755,
750, 745, 717, 637, 603, 602, 590, 581, 578, 529, 527, 526, 523, 519,
518, 496, 491, 432, 404, 403, 401, 372, 363, 356, 345, 330, 329, 327,
317, 316, 313, 295, 282, 263, 242, 239, 234, 232, 225, 223, 213, 209,
204, 198, 195, 173, 170, 169, 167, 154, 149, 148, 147, 140, 138, 132,
131, 130, 129, 126, 121, 112, 109, 107, 100, 95, 90, 68, 64, 57, 52,
51, 46, 43, 37, 27, 25, 21, 15, 10, and 9 were examined and none were
found to have any date or time references, let alone millennium or Year
2000 issues.
24. References
Philip J. Nesser II
Nesser & Nesser Consulting
13501 100th Ave N.E.
Suite 5202
Kirkland, WA 98052
Phone: 425-481-4303
EMail: [email protected]
[email protected]
The following list contains the RFC's grouped by area that were
searched for year 2000 problems.
Each line contains three fields are separated by '::'. The first
filed is the RFC number, the second field is the type of RFC (S =
Standard, DS = Draft Standard, PS = Proposed Standard, E =
Experimental, H = Historical, I = Informational, BC = Best Current
Practice, '' = No Type), and the third field is the Title.
A.1 Autoconfiguration
1617:: I:: Naming and Structuring Guidelines for X.500 Directory Pilots
1609:: E:: Charting Networks in the X.500 Directory
1608:: E:: Representing IP Information in the X.500 Directory
1588:: I:: WHITE PAGES MEETING REPORT
1562:: I:: Naming Guidelines for the AARNet X.500 Directory Service
1491:: I:: A Survey of Advanced Usages of X.500
1488:: PS:: The X.500 String Representation of Standard Attribute
Syntaxes
1487:: PS:: X.500 Lightweight Directory Access Protocol
1485:: PS:: A String Representation of Distinguished Names
1484:: E:: Using the OSI Directory to achieve User Friendly Naming
1430:: I:: A Strategic Plan for Deploying an Internet X.500
Directory Service
1400:: I:: Transition and Modernization of the Internet Registration
Service
1384:: I:: Naming Guidelines for Directory Pilots
1355:: I:: Privacy and Accuracy Issues in Network Information
Center Databases
1330:: I:: Recommendations for the Phase I Deployment of OSI
Directory Services (X.500) and OSI Message Handling
Services (X.400) within the ESnet Community
1309:: I:: Technical Overview of Directory Services Using the
X.500 Protocol
1308:: I:: Executive Introduction to Directory Services Using the
X.500 Protocol
1292:: I:: A Catalog of Available X.500 Implementations
1279:: :: X.500 and Domains
1276:: PS:: Replication and Distributed Operations extensions to
provide an Internet Directory using X.500
1275:: I:: Replication Requirements to provide an Internet Directory
using X.500
1274:: PS:: The COSINE and Internet X.500 Schema
1255:: I:: A Naming Scheme for c=US
1218:: :: A Naming Scheme for c=US
1202:: I:: Directory Assistance Service
1107:: :: Plan for Internet directory services
954:: DS:: NICNAME/WHOIS
953:: H:: Hostname Server
812:: :: NICNAME/WHOIS
756:: :: NIC name server - a datagram-based information utility
752:: :: Universal host table
============ ==========================================================
Disk Sharing
1813:: I:: NFS Version 3 Protocol Specification
1094:: H:: NFS: Network File System Protocol specification
============ ==========================================================
Games and Chat
1459:: E:: Internet Relay Chat Protocol
======================================================================
Information Services & File Transfer
2122:: PS:: VEMMI URL Specification
2070:: PS:: Internationalization of the Hypertext Markup Language
2068:: PS:: Hypertext Transfer Protocol -- HTTP/1.1
2056:: PS:: Uniform Resource Locators for Z39.50
2055:: I:: WebNFS Server Specification
2054:: I:: WebNFS Client Specification
2044:: I:: UTF-8, a transformation format of Unicode and ISO 10646
2016:: E:: Uniform Resource Agents (URAs)
1986:: E:: Experiments with a Simple File Transfer Protocol for
Radio Links using Enhanced Trivial File Transfer
Protocol (ETFTP)
1980:: I:: A Proposed Extension to HTML: Client-Side Image Maps
1960:: PS:: A String Representation of LDAP Search Filters
1959:: PS:: An LDAP URL Format
1945:: I:: Hypertext Transfer Protocol -- HTTP/1.0
1942:: E:: HTML Tables
1874:: E:: SGML Media Types
1867:: E:: Form-based File Upload in HTML
1866:: PS:: Hypertext Markup Language - 2.0
1865:: I:: EDI Meets the Internet: Frequently Asked Questions
about Electronic Data Interchange (EDI) on the Internet
1862:: I:: Report of the IAB Workshop on Internet Information
Infrastructure, October 12-14, 1994
1843:: I:: HZ - A Data Format for Exchanging Files of Arbitrarily
Mixed Chinese and ASCII characters
1842:: I:: ASCII Printable Characters-Based Chinese Character
Encoding for Internet Messages
1823:: I:: The LDAP Application Program Interface
1815:: I:: Character Sets ISO-10646 and ISO-10646-J-1
1808:: PS:: Relative Uniform Resource Locators
1807:: I:: A Format for Bibliographic Records
1798:: PS:: Connection-less Lightweight Directory Access Protocol
1788:: E:: ICMP Domain Name Messages
1785:: I:: TFTP Option Negotiation Analysis
1784:: PS:: TFTP Timeout Interval and Transfer Size Options
1783:: PS:: TFTP Blocksize Option
1782:: PS:: TFTP Option Extension
1779:: DS:: A String Representation of Distinguished Names
1778:: DS:: The String Representation of Standard Attribute Syntaxes
1777:: DS:: Lightweight Directory Access Protocol
1766:: PS:: Tags for the Identification of Languages
1738:: PS:: Uniform Resource Locators (URL)
1737:: I:: Functional Requirements for Uniform Resource Names
1736:: I:: Functional Requirements for Internet Resource Locators
1729:: I:: Using the Z39.50 Information Retrieval Protocol in the
Internet Environment
for IPng
1676:: I:: INFN Requirements for an IPng
1674:: I:: A Cellular Industry View of IPng
1673:: I:: Electric Power Research Institute Comments on IPng
1672:: I:: Accounting Requirements for IPng
1671:: I:: IPng White Paper on Transition and Other Considerations
1670:: I:: Input to IPng Engineering Considerations
1669:: I:: Market Viability as a IPng Criteria
1667:: I:: Modeling and Simulation Requirements for IPng
1663:: PS:: PPP Reliable Transmission
1662:: S:: PPP in HDLC-like Framing
1661:: S:: The Point-to-Point Protocol (PPP)
1644:: E:: T/TCP -- TCP Extensions for Transactions Functional
Specification
1638:: PS:: PPP Bridging Control Protocol (BCP)
1634:: I:: Novell IPX Over Various WAN Media (IPXWAN)
1631:: I:: The IP Network Address Translator (Nat)
1629:: DS:: Guidelines for OSI NSAP Allocation in the Internet
1626:: PS:: Default IP MTU for use over ATM AAL5
1624:: I:: Computation of the Internet Checksum via Incremental
Update
1622:: I:: Pip Header Processing
1621:: I:: Pip Near-term Architecture
1620:: I:: Internet Architecture Extensions for Shared Media
1619:: PS:: PPP over SONET/SDH
1618:: PS:: PPP over ISDN
1613:: I:: cisco Systems X.25 over TCP (XOT)
1605:: I:: SONET to Sonnet Translation
1604:: PS:: Definitions of Managed Objects for Frame Relay Service
1598:: PS:: PPP in X.25
1590:: I:: Media Type Registration Procedure
1577:: PS:: Classical IP and ARP over ATM
1575:: DS:: An Echo Function for CLNP (ISO 8473)
1570:: PS:: PPP LCP Extensions
1561:: E:: Use of ISO CLNP in TUBA Environments
1560:: I:: The MultiProtocol Internet
1553:: PS:: Compressing IPX Headers Over WAN Media (CIPX)
1552:: PS:: The PPP Internetwork Packet Exchange Control
Protocol (IPXCP)
1551:: I:: Novell IPX Over Various WAN Media (IPXWAN)
1549:: DS:: PPP in HDLC Framing
1548:: DS:: The Point-to-Point Protocol (PPP)
1547:: I:: Requirements for an Internet Standard
Point-to-Point Protocol
1538:: I:: Advanced SNA/IP
1526:: I:: Assignment of System Identifiers for TUBA/CLNP Hosts
1518:: PS:: An Architecture for IP Address Allocation with CIDR
1498:: I:: On the Naming and Binding of Network Destinations
Hardware Devices
1317:: PS:: Definitions of Managed Objects for RS-232-like
Hardware Devices
1316:: PS:: Definitions of Managed Objects for Character Stream
Devices
1315:: PS:: Management Information Base for Frame Relay DTEs
1304:: PS:: Definitions of Managed Objects for the SIP Interface Type
1303:: I:: A Convention for Describing SNMP-based Agents
1298:: I:: SNMP over IPX
1289:: PS:: DECnet Phase IV MIB Extensions
1286:: PS:: Definitions of Managed Objects for Bridges
1285:: PS:: FDDI Management Information Base
1284:: PS:: Definitions of Managed Objects for the Ethernet-like
Interface Types
1283:: E:: SNMP over OSI
1273:: I:: A Measurement Study of Changes in Service-Level
Reachability in the Global TCP/IP Internet
1272:: I:: Internet Accounting
1271:: PS:: Remote Network Monitoring Management Information Base
1270:: I:: SNMP Communications Services
1269:: PS:: Definitions of Managed Objects for the Border Gateway
Protocol (Version 3)
1262:: :: Guidelines for Internet Measurement Activities
1253:: PS:: OSPF Version 2 Management Information Base
1252:: PS:: OSPF Version 2 Management Information Base
1248:: PS:: OSPF Version 2 Management Information Base
1247:: DS:: OSPF Version 2
1243:: PS:: AppleTalk Management Information Base
1242:: I:: Benchmarking Terminology for Network Interconnection
Devices
1239:: PS:: Reassignment of Experimental MIBs to Standard MIBs
1238:: E:: CLNS MIB - for use with Connectionless Network
Protocol (ISO 8473) and End System to Intermediate
System (ISO 9542)
1233:: H:: Definitions of Managed Objects for the DS3 Interface Type
1232:: H:: Definitions of Managed Objects for the DS1 Interface Type
1231:: DS:: IEEE 802.5 Token Ring MIB
1230:: H:: IEEE 802.4 Token Bus MIB
1229:: DS:: Extensions to the Generic-Interface MIB
1228:: E:: SNMP-DPI - Simple Network Management Protocol
Distributed Program Interface
1227:: E:: SNMP MUX Protocol and MIB
1224:: E:: Techniques for Managing Asynchronously Generated Alerts
1215:: I:: A Convention for Defining Traps for use with the SNMP
1214:: H:: OSI Internet Management
1213:: S:: Management Information Base for Network Management of
TCP/IP-based internets
1212:: S:: Concise MIB Definitions
network information
522:: ::Traffic statistics May 1973
509:: ::Traffic statistics April 1973
500:: ::Integration of data management systems on a computer
network
482:: :: Traffic statistics February 1973
455:: :: Traffic statistics January 1973
443:: :: Traffic statistics December 1972
423:: :: UCLA Campus Computing Network liaison staff for ARPANET
422:: :: Traffic statistics November 1972
421:: :: Software consulting service for network users
416:: :: ARC system will be unavailable for use during
Thanksgivingweek
415:: :: Tenex bandwidth
413:: :: Traffic statistics October 1972
400:: :: Traffic statistics September 1972
392:: :: Measurement of host costs for transmitting network data
391:: :: Traffic statistics August 1972
389:: :: UCLA Campus Computing Network liaison staff for ARPA
Network
388:: :: NCP statistics
384:: :: Official site idents for organizations in the ARPA
Network
381:: :: Three aids to improved network operation
378:: :: Traffic statistics July 1972
369:: :: Evaluation of ARPANET services January-March, 1972
362:: :: Network host status
353:: :: Network host status
344:: :: Network host status
326:: :: Network host status
323:: :: Formation of Network Measurement Group NMG
308:: :: ARPANET host availability data
304:: :: Data management system proposal for the ARPA network
302:: :: Exercising the ARPANET
274:: :: Establishing a local guide for network usage
227:: :: Data transfer rates Rand/UCLA
212:: :: NWG meeting on network usage
193:: :: Network checkout
188:: :: Data management meeting announcement
156:: :: Status of the Illinois site
153:: :: SRI ARC-NIC status
96:: :: Interactive network experiment to study modes of
access tothe Network Information Center
32:: :: Connecting M.I.T. computers to the
ARPA Computer-to-computer communication network
18:: :: [Link assignments]
======================================================================
Network News
1036:: :: Standard for interchange of USENET messages
977:: PS:: Network News Transfer Protocol
850:: :: Standard for interchange of USENET messages
===================================================================
Real Time Services
:: ::
2102:: I:: Multicast Support for Nimrod
2090:: E:: TFTP Multicast Option
2038:: PS:: RTP Payload Format for MPEG1/MPEG2 Video
2035:: PS:: RTP Payload Format for JPEG-compressed Video
2032:: PS:: RTP payload format for H.261 video streams
2029:: PS:: RTP Payload Format of Sun's CellB Video Encoding
2022:: PS:: Support for Multicast over UNI 3.0/3.1 based ATM
Networks
1890:: PS:: RTP Profile for Audio and Video Conferences with Minimal
Control
1889:: PS:: RTP
1861:: I:: Simple Network Paging Protocol - Version 3 - Two-Way
Enhanced
1821:: I:: Integration of Real-time Services in an IP-ATM Network
Architecture
1819:: E:: Internet Stream Protocol Version 2 (ST2) Protocol
Specification - Version ST2+
1789:: I:: INETPhone
1768:: E:: Host Group Extensions for CLNP Multicasting
1703:: I:: Principles of Operation for the TPC.INT Subdomain
1645:: I:: Simple Network Paging Protocol - Version 2
1614:: I:: Network Access to Multimedia Information
1569:: I:: Principles of Operation for the TPC.INT Subdomain
1568:: I:: Simple Network Paging Protocol - Version 1(b)
1546:: I:: Host Anycasting Service
1469:: PS:: IP Multicast over Token-Ring Local Area Networks
1458:: I:: Requirements for Multicast Protocols
1453:: I:: A Comment on Packet Video Remote Conferencing and the
Transport/Network Layers
1313:: I:: Today's Programming for KRFC AM 1313 Internet Talk Radio
1301:: I:: Multicast Transport Protocol
1257:: I:: Isochronous Applications Do Not Require
Jitter-Controlled Networks
1197:: I:: Using ODA for Translating Multimedia Information
1193:: :: Client Requirements for Real-Time Communication Services
1190:: E:: Experimental Internet Stream Protocol, Version 2 (ST-II)
1112:: S:: Host extensions for IP multicasting
1054:: :: Host extensions for IP multicasting
988:: :: Host extensions for IP multicasting
966:: :: Host groups
947:: :: Multi-network broadcasting within the Internet
Framework
1983:: I:: Internet Users' Glossary
1958:: I:: Architectural Principles of the Internet
1952:: I:: GZIP file format specification version 4.3
1951:: I:: DEFLATE Compressed Data Format Specification version 1.3
1950:: I:: ZLIB Compressed Data Format Specification version 3.3
1941:: I:: Frequently Asked Questions for Schools
1935:: I:: What is the Internet, Anyway?
1920:: S:: INTERNET OFFICIAL PROTOCOL STANDARDS
1900:: I:: Renumbering Needs Work
1899:: I:: Request for Comments Summary RFC Numbers 1800-1899
1882:: I:: The 12-Days of Technology Before Christmas
1880:: S:: INTERNET OFFICIAL PROTOCOL STANDARDS
1879:: I:: Class A Subnet Experiment Results and Recommendations
1875:: I:: UNINETT PCA Policy Statements
1871:: BC:: Addendum to RFC 1602 -- Variance Procedure
1855:: I:: Netiquette Guidelines
1822:: I:: A Grant of Rights to Use a Specific IBM patent with
Photuris
1818:: S:: Best Current Practices
1816:: I:: U.S. Government Internet Domain Names
1814:: I:: Unique Addresses are Good
1811:: I:: U.S. Government Internet Domain Names
1810:: I:: Report on MD5 Performance
1805:: I:: Location-Independent Data/Software Integrity Protocol
1802:: I:: Introducing Project Long Bud
1800:: S:: INTERNET OFFICIAL PROTOCOL STANDARDS
1799:: I:: Request for Comments Summary RFC Numbers 1700-1799
1797:: E:: Class A Subnet Experiment
1796:: I:: Not All RFCs are Standards
1790:: I:: An Agreement between the Internet Society and Sun
Microsystems, Inc. in the Matter of ONC RPC and
XDR Protocols
1780:: S:: INTERNET OFFICIAL PROTOCOL STANDARDS
1776:: I:: The Address is the Message
1775:: I:: To Be "On" the Internet
1758:: I:: NADF Standing Documents
1746:: I:: Ways to Define User Expectations
1739:: I:: A Primer On Internet and TCP/IP Tools
1720:: S:: INTERNET OFFICIAL PROTOCOL STANDARDS
1718:: I:: The Tao of IETF - A Guide for New Attendees of the
Internet Engineering Task Force
1715:: I:: The H Ratio for Address Assignment Efficiency
1709:: I:: K-12 Internetworking Guidelines
1700:: S:: ASSIGNED NUMBERS
1699:: I:: Request for Comments Summary RFC Numbers 1600-1699
1691:: I:: The Document Architecture for the Cornell Digital Library
1690:: I:: Introducing the Internet Engineering and Planning
Group (IEPG)
1689:: I::A Status Report on Networked Information Retrieval
1640:: I::The Process for Organization of Internet Standards
Working Group (POISED)
1636:: I:: Report of IAB Workshop on Security in the Internet
Architecture - February 8-10, 1994
1635:: I:: How to Use Anonymous FTP
1627:: I:: Network 10 Considered Harmful (Some Practices
Shouldn't be Codified)
1610:: S:: INTERNET OFFICIAL PROTOCOL STANDARDS
1607:: I:: A VIEW FROM THE 21ST CENTURY
1606:: I:: A Historical Perspective On The Usage Of IP Version 9
1603:: I:: IETF Working Group Guidelines and Procedures
y1602:: I:: The Internet Standards Process -- Revision 2
1601:: I:: Charter of the Internet Architecture Board (IAB)
1600:: S:: INTERNET OFFICIAL PROTOCOL STANDARDS
1599:: I:: Request for Comments Summary RFC Numbers 1500 - 1599
1597:: I:: Address Allocation for Private Internets
1594:: I:: FYI on Questions and Answer Answers to Commonly
asked "New Internet User" Questions
1580:: I:: Guide to Network Resource Tools
1578:: I:: FYI on Questions and Answers
1574:: I:: Essential Tools for the OSI Internet
1550:: I:: IP
1543:: I:: Instructions to RFC Authors
1540:: S:: INTERNET OFFICIAL PROTOCOL STANDARDS
1539:: I:: The Tao of IETF - A Guide for New Attendees of the
Internet Engineering Task Force
1527:: I:: What Should We Plan Given the Dilemma of the Network?
1501:: I:: OS/2 User Group
1500:: S:: INTERNET OFFICIAL PROTOCOL STANDARDS
1499:: I:: Request for Comments Summary RFC Numbers 1400-1499
1481:: I:: IAB Recommendation for an Intermediate Strategy to
Address the Issue of Scaling
1467:: I:: Status of CIDR Deployment in the Internet
1463:: I:: FYI on Introducing the Internet--A Short Bibliography
of Introductory Internetworking Readings for the
Network Novice
1462:: I:: FYI on "What is the Internet?"
1438:: I:: Internet Engineering Task Force Statements Of
Boredom (SOBs)
1432:: I:: Recent Internet Books
1417:: I:: NADF Standing Documents
1410:: S:: IAB OFFICIAL PROTOCOL STANDARDS
1402:: I:: There's Gold in them thar Networks! Searching for
Treasure in all the Wrong Places
1401:: I:: Correspondence between the IAB and DISA on the use
of DNS throughout the Internet
#!/usr/bin/perl
# Program to read text files (such as RFCs and Internet Drafts) and
# output items that might relate to year 2000 issues, particularly
# 2-digit years.
# Some people like using disk files, others like STDIN and STDOUT.
# This program accomodates both types by setting the $UsageType
# variable. 'file' means input comes from the first argument on
# the command line, output goes to that filename with a ".out"
# extension; 'std' means STDIN and STDOUT.
$UsageType = 'file'; # Should be 'file' or 'std'
if($UsageType eq 'file') {
if($ARGV[0] eq '')
{ die "You must specify the name of the file to open.\n" }
$InName = $ARGV[0];
unless(-r $InName) { die "Could not read $InName.\n" }
open(IN, $InName) or die "Could not open $InName.\n";
$OutName = "$InName.out";
open(OUT, ">$OutName") or die "Could not write to $OutName.\n";
$OutStuff = ''; # Holder for what we're going to print out
} else { # Do STDIN and STDOUT
open(IN, "-"); open(OUT, ">-");
}
# Read the whole file into an array. This is a tad wasteful of memory
# but makes the output easier.
@All = ();
while(<IN>) { push(@All, $_) }
$LastLine = $#All;
# All done. If writing to a file, and nothing got written, delete the
# file so that you can quickly scan for the ".out" files.
# (A better-written program would have waited to do the opens
# until here so the unlink wouldn't be necessary. Oh, well.)
if($UsageType eq 'file') {
if(length($OutStuff) > 0) {
$OutStuff = "+=+=+=+=+= File $InName +=+=+=+=+= \n$OutStuff\n
print OUT $OutStuff; close(OUT);
} else { # Nothing to put in the .out
close(OUT);
unlink($OutName) or die "Couldn't unlink $OutName\n";
}
}
exit;
$WhereRealLine = $Where + 1;
$OutStuff .= "$Msg found at line $WhereRealLine:\n";
$Start = $WhereRealLine - 2; $End = $WhereRealLine + 2;
if($Where < 2) { $Start = 0 }
if($Where > $LastLine - 2) { $End = $LastLine }
for($j = $Start; $j <= $End; $j += 1) {
if (length($All[$j-1]) > 64) {
$FirstHalf = substr($All[$j-1], 0, 64) . "\n";
$LastHalf = "$j(continued):\t\t" . substr($All[$j-1], 64);
832:
352: %TXTOP 4000 This character has the [TOP] key depressed.
353:
354: %TXSFL 2000 Reserved, must be zero.
355:
356: %TXSFT 1000 Reserved, must be zero.
1946: <time> ::= <hh> ":" <mm> ":" <ss> <SP> <zone>
342:
343: "<n>(element)" is equivalent to "<n>*<n>(element)"; th
343(continued): at is,
344: exactly <n> occurrences of (element). Thus 2DIGIT is a 2
344(continued): -digit
345: number, and 3ALPHA is a string of three alphabetic characte
345(continued): rs.
346:
1596: HP-2621
1597: HP-2621A
144(continued): s, as
145: shown in the following diagram.
816(continued): (with
1284: S: <[email protected]>
1285: S: <[email protected]>
3394: The extended syntax of zone defined in the JNT Mail Protoc
3394(continued): ol
3395: should be used in the mapping of UTCTime defined in chapte
3395(continued): r 3.
3396:
3397: 5. Lack of separate 822-P1 originator specification
2946: HP-2621
2947: HP-2621A
1351: AEGIS
1352: APOLLO
1353: BS-2000
1354: CEDAR
1355: CGW
539(continued): ssed in
540: Universal Time format, which measures a
540(continued): time as
541: the number of seconds since January 1, 1
541(continued): 900, at
542: midnight GMT.
543:
650(continued): t in the
651: last 32 bits, as shown in the following diagram.
4470:
4471: 6. Lack of 822-MTS originator specification
1266:
1267: Email: [email protected]
1268:
1269:
137:
138: Files are available for anonymous ftp; use 'guest' as the
2483(continued): DDN-
2484: related host security problems; call (800) 235-3155
2484(continued): (6:00
343(continued): -
344: divestiture AT&T which held back market-driven innovation in
345: telecommunications for half a century. Given the interconnec
345(continued): tion
346: technology now available, we should never again have to accep
346(continued): t the
347: argument that we have to sacrifice interoperability for effic
347(continued): iency,
278: "snmp"/NS+4900590800200038bafe00
279:
280:
4548(continued): done
4549: so, the Greek astronomer Meton calculated there were 110 lunar m
4549(continued): onths of
4550: 29 days and 125 lunar months of 30 days for a total of 235 lunar
4550(continued): months
4641(continued): Earth -
4642: is 29.53059 days; however, the actual tropical year can be deter
4642(continued): mined
4725: (MJD 15,020.0). The insertion of leap seconds in UTC and subsequ
4725(continued): ently
4726: into NTP does not affect the UTC or NTP oscillator, only the con
4726(continued): version
4015(continued): [GB7]
145: 1900 and time relative to 2036 (and other multiples of 136 ye
145(continued): ars).
146: Timestamped data requiring such qualification will be so prec
146(continued): ious
147: that appropriate means should be readily available. There wil
147(continued): l exist
1152: MA0GCSqGSIb3DQEBAgUAA38AAICPv4f9Gx/tY4+p+4DB7MV+tKZnvBoy8zgo
1152(continued): MGOx
330(continued): may be
331: sent and applied to the copy at the receiving site. The form
331(continued): is US
332: mm/dd/yy and hh:mm:ss. A time zone is optional. If the time
332(continued): zone is
333: omitted, local time is assumed. If the DATE command is omitt
333(continued): ed, time
334: and date of arrival are assumed.
1949:
1950: file /ftp/rfc/rfcnnnn.yyy where 'nnnn' is the RFC n
1950(continued): umber.
1951: and 'yyy' is 'txt' or 'ps
1951(continued): '.
1952:
663: bulky equipment - some of the early 3DV clips from 2000-
664: 2005 showed rooms full of gear required to steer beams
665: around. A very interesting combination of fiber optics and
1353(continued):
1354:
1355: 0x01 Intervention Required 0x08020000
1355(continued):
1356:
1357: 0x02 Operation Check 0x10050000
1357(continued):
384: 0x00020000.
385:
386: Filler
1930(continued):
1931: transition of the Internet from IPv4 to IPv6 and to give advi
1931(continued): ce on
249(continued): ious
250: that appropriate means should be readily available. There wil
250(continued): l exist
1950(continued): umber.
1951: and 'yyy' is 'txt' or 'ps
1951(continued): '.
1952:
1881(continued): MdlynU
1882: d4jcJgRnQIQvIxm2VRgH8W8MkAlul+RWGu7jnxjp0sNsU562+RZr0f4F
1882(continued): 3K3n4w
1883: onUUP265UvvMj23RSTguZ/nl/OxnFM6SzDgV39V/i/RofqI=
1491: GGMwPMGoF+GDPM7GlC6fReQ5wyvV1PnETSVO9/LAyRz0zzRYuyVueOjWDlr5
1491(continued):
1492:
2500(continued): 7eun2dsy
2501: Wve2O/FwicWHvkg5aDPsgOjzetsn1JCNZzbW
2502: $$-CyberCash-End-7Tm/djB05pLIw3JAyy5E7A==-$$
2503:
2504: #############################################################
2504(continued): ########
227:
228: RFC 1999 Summary of 1900-1999 Janu
228(continued): ary 1997
229:
230:
619:
620: RFC 2000 Internet Standards Febru
620(continued): ary 1997
621:
622:
1739:
1740: RFC 2000 Internet Standards Febru
1740(continued): ary 1997
1741:
1742:
1963:
1964: RFC 2000 Internet Standards Febru
1964(continued): ary 1997
1965:
1966:
2245:
2246:
2859:
2860: RFC 2000 Internet Standards Febru
2860(continued): ary 1997
2861:
2862:
2248(continued): PKM-2
2249: randTarg Random-Integer,
2250: src-name [1] Name OPTIONAL,
8453: in the past (this helps solve the "year 2000" problem).
8454:
8455:
2608:
2609: [RPS] Alaettinoglu, C., Bates, T., Gerich, E., Terpstra, M., a
2609(continued): nd C.
1011:
1012: RFC 2099 Summary of 2000-2099 Ma
1012(continued): rch 1997
1013:
1014:
533(continued): e
534: renumbering more and more common [RFC 1900].
535:
536: The need to scale the Internet routing system, and the use of
536(continued): CIDR as
916: DD.Mail-11=route::node::localpart;
917:
1094:
1095: C=xx; ADMD=yyy; DD.Dnet=net;
1096: DD.Mail-11=route::gwnode::gw(p)(q)x400-text-address(q);
1097:
497(continued): 648).
498: This is then an increment of the serial number [RFC1982].
1895(continued): onth
1896: and day respectively [ISO-8601].
1897:
1947(continued): s is a
1948: draft paper, currently available at http://
1949: www2000.ogsm.vanderbilt.edu/novak/web.standards/webstand.
1949(continued): html.
1950: Cited by permission of the author; do not quote or cite w
1950(continued): ithout
1951: permission.
1971:
1972: Phone: (415) 254-1900
1973: EMail: [email protected]
1974:
1868(continued): gned by
1869: the Internet Assigned Number Authority (IANA). Four of these
1869(continued): port
1870: numbers are used for ANR-routed network layer packets (NLPs)
1870(continued): and
2287:
2288: byyrdaylist = yeardaynum / ( yeardaynum *("," yeardaynum) )
2288(continued):
2289:
2290: yeardaynum = ([plus] ordyrday) / (minus ordyrday)
1919(continued): and
1920: two-digit day of the month. There are no separator characters
1920(continued): between
1921: the year, month and day component text.
2277:
2278: weekday = "SU" / "MO" / "TU" / "WE" / "TH" / "FR" / "SA"
2278(continued):
3374: DTSTART:19970701T210000Z
3375: DTEND:19970701T230000Z
4074: END:VCALENDAR
4360: DTSTART;TZID=America-SanJose:19970701T140000
4361: DTEND;TZID=America-SanJose:19970701T150000
3594: DTSTAMP:19970611T190000Z
3595: DTSTART:19970701T200000Z
3596: DTEND:19970701T2000000Z
3597: SUMMARY:Conference
7164:
7165: Since this object incorporates the Year 2000-unfriendl
7165(continued): y
7166: 2-digit year specified in SMI for the LAST-UPDATED fie
7166(continued): ld, and
7167:
HTTP:
Sun, 06 Nov 1994 08:49:37 GMT ; RFC 822, updated by RFC 1123
This avoids a "stale cache" problem, which would cause the user to
see out-of-date data.
HTTP/1.0:
Date:
Expires: # can be in the future
If-Modified-Since: # required to be in the past
Last-Modified: # required to be in the past
Retry-After: # can be in the future, also takes
# relative time - number of seconds
HTTP/1.1:
If-Range:
If-Unmodified-Since: # required to be in the past
Note that clock skew between hosts can lead to confusion here - see
the RFC for details.
Some cases involve comparisons with the current time, and others may
involve comparisons between dates from different sources. The
abbreviation "/99" is used to imply an RFC850 date with the value
"99" for the year.
Scenario 1:
If a client gets an Expires /99 date after the year 2000, it
should interpret it as 1999, to avoid ending up with a stale
cache entry.
Scenario 2:
If a client gets an Expires /00 date before the year 2000,
and subsequently is faced with a choice to either retrieve
the document from its cache or look for an updated copy, it
may interpret it as the year 2000, to avoid the unnecessary
delay and bandwidth of an extra request.
Scenario 3:
If a server gets an If-Modified-Since /99 date from a client
after the year 2000, it should interpret it as 1999 when
comparing with the local modification date, in order to
possibly avoid sending a full GET response rather than a HEAD
response.
The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns.
Acknowledgement