As per Relevance of the word represent, we have this rfc below:
Network Working Group G.
Request for Comments: 3339 Clearswift
Category: Standards Track C.
Sun
July 2002
Date and Time on the Internet:
Status of this
This document specifies an Internet standards track protocol for
Internet community, and requests discussion and suggestions
improvements. Please refer to the current edition of the "
Official Protocol Standards" (STD 1) for the standardization
and status of this protocol. Distribution of this memo is unlimited
Copyright
Copyright (C) The Internet Society (2002). All Rights Reserved
This document defines a date and time format for use in
protocols that is a profile of the ISO 8601 standard
representation of dates and times using the Gregorian calendar
Table of
1. Introduction ............................................ 2
2. Definitions ............................................. 3
3. Two Digit Years ......................................... 4
4. Local Time .............................................. 4
4.1. Coordinated Universal Time (UTC) ...................... 4
4.2. Local Offsets ......................................... 5
4.3. Unknown Local Offset Convention ....................... 5
4.4. Unqualified Local Time ................................ 5
5. Date and Time format .................................... 6
5.1. Ordering .............................................. 6
5.2. Human Readability ..................................... 6
5.3. Rarely Used Options ................................... 7
5.4. Redundant Information ................................. 7
5.5. Simplicity ............................................ 7
5.6. Internet Date/Time Format ............................. 8
5.7. Restrictions .......................................... 9
5.8. Examples ............................................. 10
6. References ............................................. 10
7. Security Considerations ................................ 11
Klyne, et. al. Standards Track [Page 1]
RFC 3339 Date and Time on the Internet: Timestamps July 2002
Appendix A. ISO 8601 Collected ABNF ....................... 12
Appendix B. Day of the Week ............................... 14
Appendix C. Leap Years .................................... 14
Appendix D. Leap Seconds ..............................,... 15
Acknowledgements .......................................... 17
Authors' Addresses ........................................ 17
Full Copyright Statement .................................. 18
1.
Date and time formats cause a lot of confusion and
problems on the Internet. This document addresses many of
problems encountered and makes recommendations to improve
and interoperability when representing and using date and time
Internet protocols
This document includes an Internet profile of the ISO 8601 [ISO8601]
standard for representation of dates and times using the
calendar
There are many ways in which date and time values might appear
Internet protocols: this document focuses on just one common usage
viz. timestamps for Internet protocol events. This
consideration has the following consequences
o All dates and times are assumed to be in the "current era",
somewhere between 0000AD and 9999AD
o All times expressed have a stated relationship (offset)
Coordinated Universal Time (UTC). (This is distinct from
usage in scheduling applications where a local time and
may be known, but the actual relationship to UTC may be
on the unknown or unknowable actions of politicians
administrators. The UTC time corresponding to 17:00 on 23rd
2005 in New York may depend on administrative decisions
daylight savings time. This specification steers well clear
such considerations.)
o Timestamps can express times that occurred before the
of UTC. Such timestamps are expressed relative to universal time
using the best available practice at the stated time
o Date and time expressions indicate an instant in time
Description of time periods, or intervals, is not covered here
Klyne, et. al. Standards Track [Page 2]
RFC 3339 Date and Time on the Internet: Timestamps July 2002
2.
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in
document are to be interpreted as described in RFC 2119 [RFC2119].
UTC Coordinated Universal Time as maintained by the
International des Poids et Mesures (BIPM).
second A basic unit of measurement of time in
International System of Units. It is defined as
duration of 9,192,631,770 cycles of microwave
absorbed or emitted by the hyperfine transition
cesium-133 atoms in their ground state undisturbed
external fields
minute A period of time of 60 seconds. However, see also
restrictions in section 5.7 and Appendix D for
leap seconds are denoted within minutes
hour A period of time of 60 minutes
day A period of time of 24 hours
leap year In the Gregorian calendar, a year which has 366 days
A leap year is a year whose number is divisible
four an integral number of times, except that if it
a centennial year (i.e. divisible by one hundred)
shall also be divisible by four hundred an
number of times
ABNF Augmented Backus-Naur Form, a format used to
permissible strings in a protocol or language,
defined in [ABNF].
Email Date/Time
The date/time format used by Internet Mail as
by RFC 2822 [IMAIL-UPDATE].
Internet Date/Time
The date format defined in section 5 of this document
Timestamp This term is used in this document to refer to
unambiguous representation of some instant in time
Z A suffix which, when applied to a time, denotes a
offset of 00:00; often spoken "Zulu" from the
phonetic alphabet representation of the letter "Z".
Klyne, et. al. Standards Track [Page 3]
RFC 3339 Date and Time on the Internet: Timestamps July 2002
For more information about time scales, see Appendix E of [NTP],
Section 3 of [ISO8601], and the appropriate ITU documents [ITU-R
TF].
3. Two Digit
The following requirements are to address the problems of
of 2-digit years
o Internet Protocols MUST generate four digit years in dates
o The use of 2-digit years is deprecated. If a 2-digit year
received, it should be accepted ONLY if an
interpretation will not cause a protocol or processing
(e.g. if used only for logging or tracing purposes).
o It is possible that a program using two digit years
represent years after 1999 as three digits. This occurs if
program simply subtracts 1900 from the year and doesn't
the number of digits. Programs wishing to robustly deal
dates generated by such broken software may add 1900 to
digit years
o It is possible that a program using two digit years
represent years after 1999 as ":0", ":1", ... ":9", ";0", ...
This occurs if the program simply subtracts 1900 from the
and adds the decade to the US-ASCII character zero.
wishing to robustly deal with dates generated by such
software should detect non-numeric decades and
appropriately
The problems with two digit years amply demonstrate why all dates
times used in Internet protocols MUST be fully qualified
4. Local
4.1. Coordinated Universal Time (UTC
Because the daylight saving rules for local time zones are
convoluted and can change based on local law at unpredictable times
true interoperability is best achieved by using Coordinated
Time (UTC). This specification does not cater to local time
rules
Klyne, et. al. Standards Track [Page 4]
RFC 3339 Date and Time on the Internet: Timestamps July 2002
4.2. Local
The offset between local time and UTC is often useful information
For example, in electronic mail (RFC2822, [IMAIL-UPDATE]) the
offset provides a useful heuristic to determine the probability of
prompt response. Attempts to label local offsets with
strings have resulted in poor interoperability in the past [IMAIL],
[HOST-REQ]. As a result, RFC2822 [IMAIL-UPDATE] has made
offsets mandatory
Numeric offsets are calculated as "local time minus UTC". So
equivalent time in UTC can be determined by subtracting the
from the local time. For example, 18:50:00-04:00 is the same time
22:50:00Z. (This example shows negative offsets handled by
the absolute value of the offset.)
NOTE: Following ISO 8601, numeric offsets represent only
zones that differ from UTC by an integral number of minutes
However, many historical time zones differ from UTC by a non
integral number of minutes. To represent such historical
stamps exactly, applications must convert them to a
time zone
4.3. Unknown Local Offset
If the time in UTC is known, but the offset to local time is unknown
this can be represented with an offset of "-00:00". This
semantically from an offset of "Z" or "+00:00", which imply that
is the preferred reference point for the specified time. RFC2822
[IMAIL-UPDATE] describes a similar convention for email
4.4. Unqualified Local
A number of devices currently connected to the Internet run
internal clocks in local time and are unaware of UTC. While
Internet does have a tradition of accepting reality when
specifications, this should not be done at the expense
interoperability. Since interpretation of an unqualified local
zone will fail in approximately 23/24 of the globe,
interoperability problems of unqualified local time are
unacceptable for the Internet. Systems that are configured with
local time, are unaware of the corresponding UTC offset, and
on time synchronization with other Internet systems, MUST use
mechanism that ensures correct synchronization with UTC.
suitable mechanisms are
o Use Network Time Protocol [NTP] to obtain the time in UTC
Klyne, et. al. Standards Track [Page 5]
RFC 3339 Date and Time on the Internet: Timestamps July 2002
o Use another host in the same local time zone as a gateway to
Internet. This host MUST correct unqualified local times that
transmitted to other hosts
o Prompt the user for the local time zone and daylight saving
settings
5. Date and Time
This section discusses desirable qualities of date and time
and defines a profile of ISO 8601 for use in Internet protocols
5.1.
If date and time components are ordered from least precise to
precise, then a useful property is achieved. Assuming that the
zones of the dates and times are the same (e.g., all in UTC),
expressed using the same string (e.g., all "Z" or all "+00:00"),
all times have the same number of fractional second digits, then
date and time strings may be sorted as strings (e.g., using
strcmp() function in C) and a time-ordered sequence will result.
presence of optional punctuation would violate this characteristic
5.2. Human
Human readability has proved to be a valuable feature of
protocols. Human readable protocols greatly reduce the costs
debugging since telnet often suffices as a test client and
analyzers need not be modified with knowledge of the protocol.
the other hand, human readability sometimes results
interoperability problems. For example, the date format "10/11/1996"
is completely unsuitable for global interchange because it
interpreted differently in different countries. In addition,
date format in [IMAIL] has resulted in interoperability problems
people assumed any text string was permitted and translated the
letter abbreviations to other languages or substituted date
which were easier to generate (e.g. the format used by the C
ctime). For this reason, a balance must be struck between
readability and interoperability
Because no date and time format is readable according to
conventions of all countries, Internet clients SHOULD be prepared
transform dates into a display format suitable for the locality
This may include translating UTC to local time
Klyne, et. al. Standards Track [Page 6]
RFC 3339 Date and Time on the Internet: Timestamps July 2002
5.3. Rarely Used
A format which includes rarely used options is likely to
interoperability problems. This is because rarely used options
less likely to be used in alpha or beta testing, so bugs in
are less likely to be discovered. Rarely used options should be
mandatory or omitted for the sake of interoperability
possible
The format defined below includes only one rarely used option
fractions of a second. It is expected that this will be used only
applications which require strict ordering of date/time stamps
which have an unusual precision requirement
5.4. Redundant
If a date/time format includes redundant information, that
the possibility that the redundant information will not correlate
For example, including the day of the week in a date/time
introduces the possibility that the day of week is incorrect but
date is correct, or vice versa. Since it is not difficult to
the day of week from a date (see Appendix B), the day of week
not be included in a date/time format
5.5.
The complete set of date and time formats specified in ISO 8601
[ISO8601] is quite complex in an attempt to provide
representations and partial representations. Appendix A contains
attempt to translate the complete syntax of ISO 8601 into ABNF
Internet protocols have somewhat different requirements
simplicity has proved to be an important characteristic.
addition, Internet protocols usually need complete specification
data in order to achieve true interoperability. Therefore,
complete grammar for ISO 8601 is deemed too complex for most
protocols
The following section defines a profile of ISO 8601 for use on
Internet. It is a conformant subset of the ISO 8601 extended format
Simplicity is achieved by making most fields and
mandatory
Klyne, et. al. Standards Track [Page 7]
RFC 3339 Date and Time on the Internet: Timestamps July 2002
5.6. Internet Date/Time
The following profile of ISO 8601 [ISO8601] dates SHOULD be used
new protocols on the Internet. This is specified using the
description notation defined in [ABNF].
date-fullyear = 4
date-month = 2DIGIT ; 01-12
date-mday = 2DIGIT ; 01-28, 01-29, 01-30, 01-31 based
; month/
time-hour = 2DIGIT ; 00-23
time-minute = 2DIGIT ; 00-59
time-second = 2DIGIT ; 00-58, 00-59, 00-60 based on leap
;
time-secfrac = "." 1*
time-numoffset = ("+" / "-") time-hour ":" time-
time-offset = "Z" / time-
partial-time = time-hour ":" time-minute ":" time-
[time-secfrac
full-date = date-fullyear "-" date-month "-" date-
full-time = partial-time time-
date-time = full-date "T" full-
NOTE: Per [ABNF] and ISO8601, the "T" and "Z" characters in
syntax may alternatively be lower case "t" or "z" respectively
This date/time format may be used in some environments or
that distinguish between the upper- and lower-case letters 'A'-'Z
and 'a'-'z' (e.g. XML). Specifications that use this format
such environments MAY further limit the date/time syntax so
the letters 'T' and 'Z' used in the date/time syntax must
be upper case. Applications that generate this format SHOULD
upper case letters
NOTE: ISO 8601 defines date and time separated by "T".
Applications using this syntax may choose, for the sake
readability, to specify a full-date and full-time separated
(say) a space character
Klyne, et. al. Standards Track [Page 8]
RFC 3339 Date and Time on the Internet: Timestamps July 2002
5.7.
The grammar element date-mday represents the day number within
current month. The maximum value varies based on the month and
as follows
Month Number Month/Year Maximum value of date-
------------ ---------- --------------------------
01 January 31
02 February, normal 28
02 February, leap year 29
03 March 31
04 April 30
05 May 31
06 June 30
07 July 31
08 August 31
09 September 30
10 October 31
11 November 30
12 December 31
Appendix C contains sample C code to determine if a year is a
year
The grammar element time-second may have the value "60" at the end
months in which a leap second occurs -- to date: June (XXXX-06-
30T23:59:60Z) or December (XXXX-12-31T23:59:60Z); see Appendix D
a table of leap seconds. It is also possible for a leap second to
subtracted, at which times the maximum value of time-second is "58".
At all other times the maximum value of time-second is "59".
Further, in time zones other than "Z", the leap second point
shifted by the zone offset (so it happens at the same instant
the globe).
Leap seconds cannot be predicted far into the future.
International Earth Rotation Service publishes bulletins [IERS]
announce leap seconds with a few weeks' warning. Applications
not generate timestamps involving inserted leap seconds until
the leap seconds are announced
Although ISO 8601 permits the hour to be "24", this profile of
8601 only allows values between "00" and "23" for the hour in
to reduce confusion
Klyne, et. al. Standards Track [Page 9]
RFC 3339 Date and Time on the Internet: Timestamps July 2002
5.8.
Here are some examples of Internet date/time format
1985-04-12T23:20:50.52
This represents 20 minutes and 50.52 seconds after the 23rd hour
April 12th, 1985 in UTC
1996-12-19T16:39:57-08:00
This represents 39 minutes and 57 seconds after the 16th hour
December 19th, 1996 with an offset of -08:00 from UTC (
Standard Time). Note that this is equivalent to 1996-12-20T00:39:57
in UTC
1990-12-31T23:59:60
This represents the leap second inserted at the end of 1990.
1990-12-31T15:59:60-08:00
This represents the same leap second in Pacific Standard Time, 8
hours behind UTC
1937-01-01T12:00:27.87+00:20
This represents the same instant of time as noon, January 1, 1937,
Netherlands time. Standard time in the Netherlands was exactly 19
minutes and 32.13 seconds ahead of UTC by law from 1909-05-01
1937-06-30. This time zone cannot be represented exactly using
HH:MM format, and this timestamp uses the closest representable
offset
6.
[ZELLER] Zeller, C., "Kalender-Formeln", Acta Mathematica, Vol
9, Nov 1886.
[IMAIL] Crocker, D., "Standard for the Format of Arpa
Text Messages", STD 11, RFC 822, August 1982.
[IMAIL-UPDATE] Resnick, P., "Internet Message Format", RFC 2822,
April 2001.
[ABNF] Crocker, D. and P. Overell, "Augmented BNF for
Specifications: ABNF", RFC 2234, November 1997.
Klyne, et. al. Standards Track [Page 10]
RFC 3339 Date and Time on the Internet: Timestamps July 2002
[ISO8601] "Data elements and interchange formats --
interchange -- Representation of dates and times",
8601:1988(E), International Organization
Standardization, June, 1988.
[ISO8601:2000] "Data elements and interchange formats --
interchange -- Representation of dates and times",
8601:2000, International Organization
Standardization, December, 2000.
[HOST-REQ] Braden, R., "Requirements for Internet Hosts --
Application and Support", STD 3, RFC 1123,
1989.
[IERS] International Earth Rotation Service Bulletins
pc/products/bulletins.html>.
[NTP] Mills, D, "Network Time Protocol (Version 3)
Specification, Implementation and Analysis", RFC 1305,
March 1992.
[ITU-R-TF] International Telecommunication Union
for Time Signals and Frequency Standards Emissions
[RFC2119] Bradner, S, "Key words for use in RFCs to
Requirement Levels", BCP 14, RFC 2119, March 1997.
7. Security
Since the local time zone of a site may be useful for determining
time when systems are less likely to be monitored and might be
susceptible to a security probe, some sites may wish to emit times
UTC only. Others might consider this to be loss of
functionality at the hands of paranoia
Klyne, et. al. Standards Track [Page 11]
RFC 3339 Date and Time on the Internet: Timestamps July 2002
Appendix A. ISO 8601 Collected
This information is based on the 1988 version of ISO 8601. There
be some changes in the 2000 revision
ISO 8601 does not specify a formal grammar for the date and
formats it defines. The following is an attempt to create a
grammar from ISO 8601. This is informational only and may
errors. ISO 8601 remains the authoritative reference
Note that due to ambiguities in ISO 8601, some interpretations had
be made. First, ISO 8601 is not clear if mixtures of basic
extended format are permissible. This grammar permits mixtures.
8601 is not clear on whether an hour of 24 is permissible only
minutes and seconds are 0. This assumes that an hour of 24
permissible in any context. Restrictions on date-mday in section 5.7
apply. ISO 8601 states that the "T" may be omitted under
circumstances. This grammar requires the "T" to avoid ambiguity
ISO 8601 also requires (in section 5.3.1.3) that a decimal
be proceeded by a "0" if less than unity. Annex B.2 of ISO 8601
gives examples where the decimal fractions are not preceded by a "0".
This grammar assumes section 5.3.1.3 is correct and that Annex B.2
in error
date-century = 2DIGIT ; 00-99
date-decade = DIGIT ; 0-9
date-subdecade = DIGIT ; 0-9
date-year = date-decade date-
date-fullyear = date-century date-
date-month = 2DIGIT ; 01-12
date-wday = DIGIT ; 1-7 ; 1 is Monday, 7 is
date-mday = 2DIGIT ; 01-28, 01-29, 01-30, 01-31 based
; month/
date-yday = 3DIGIT ; 001-365, 001-366 based on
date-week = 2DIGIT ; 01-52, 01-53 based on
datepart-fullyear = [date-century] date-year ["-"]
datepart-ptyear = "-" [date-subdecade ["-"]]
datepart-wkyear = datepart-ptyear / datepart-
dateopt-century = "-" / date-
dateopt-fullyear = "-" / datepart-
dateopt-year = "-" / (date-year ["-"])
dateopt-month = "-" / (date-month ["-"])
dateopt-week = "-" / (date-week ["-"])
Klyne, et. al. Standards Track [Page 12]
RFC 3339 Date and Time on the Internet: Timestamps July 2002
datespec-full = datepart-fullyear date-month ["-"] date-
datespec-year = date-century / dateopt-century date-
datespec-month = "-" dateopt-year date-month [["-"] date-mday
datespec-mday = "--" dateopt-month date-
datespec-week = datepart-wkyear "W
(date-week / dateopt-week date-wday
datespec-wday = "---" date-
datespec-yday = dateopt-fullyear date-
date = datespec-full / datespec-
/ datespec-month /
datespec-mday / datespec-week / datespec-wday / datespec-
Time
time-hour = 2DIGIT ; 00-24
time-minute = 2DIGIT ; 00-59
time-second = 2DIGIT ; 00-58, 00-59, 00-60 based
; leap-second
time-fraction = ("," / ".") 1*
time-numoffset = ("+" / "-") time-hour [[":"] time-minute
time-zone = "Z" / time-
timeopt-hour = "-" / (time-hour [":"])
timeopt-minute = "-" / (time-minute [":"])
timespec-hour = time-hour [[":"] time-minute [[":"] time-second]]
timespec-minute = timeopt-hour time-minute [[":"] time-second
timespec-second = "-" timeopt-minute time-
timespec-base = timespec-hour / timespec-minute / timespec-
time = timespec-base [time-fraction] [time-zone
iso-date-time = date "T"
Durations
dur-second = 1*DIGIT "S
dur-minute = 1*DIGIT "M" [dur-second
dur-hour = 1*DIGIT "H" [dur-minute
dur-time = "T" (dur-hour / dur-minute / dur-second
dur-day = 1*DIGIT "D
dur-week = 1*DIGIT "W
dur-month = 1*DIGIT "M" [dur-day
dur-year = 1*DIGIT "Y" [dur-month
dur-date = (dur-day / dur-month / dur-year) [dur-time
duration = "P" (dur-date / dur-time / dur-week
Klyne, et. al. Standards Track [Page 13]
RFC 3339 Date and Time on the Internet: Timestamps July 2002
Periods
period-explicit = iso-date-time "/" iso-date-
period-start = iso-date-time "/"
period-end = duration "/" iso-date-
period = period-explicit / period-start / period-
Appendix B. Day of the
The following is a sample C subroutine loosely based on Zeller'
Congruence [Zeller] which may be used to obtain the day of the
for dates on or after 0000-03-01:
char *day_of_week(int day, int month, int year
{
int cent
char *dayofweek[] = {
"Sunday", "Monday", "Tuesday", "Wednesday",
"Thursday", "Friday", "Saturday
};
/* adjust months so February is the last one */
month -= 2;
if (month < 1) {
month += 12;
--year
}
/* split by century */
cent = year / 100;
year %= 100;
return (dayofweek[((26 * month - 2) / 10 + day +
+ year / 4 + cent / 4 + 5 * cent) % 7]);
}
Appendix C. Leap
Here is a sample C subroutine to calculate if a year is a leap year
/* This returns non-zero if year is a leap year. Must use 4
year
*/
int leap_year(int year
{
return (year % 4 == 0 && (year % 100 != 0 || year % 400 == 0));
}
Klyne, et. al. Standards Track [Page 14]
RFC 3339 Date and Time on the Internet: Timestamps July 2002
Appendix D. Leap
Information about leap seconds can be found at
. In particular, it
that
The decision to introduce a leap second in UTC is
responsibility of the International Earth Rotation Service (IERS).
According to the CCIR Recommendation, first preference is given
the opportunities at the end of December and June, and
preference to those at the end of March and September
When required, insertion of a leap second occurs as an extra
at the end of a day in UTC, represented by a timestamp of the
YYYY-MM-DDT23:59:60Z. A leap second occurs simultaneously in
time zones, so that time zone relationships are not affected.
section 5.8 for some examples of leap second times
The following table is an excerpt from the table maintained by
United States Naval Observatory. The source data is located at
Klyne, et. al. Standards Track [Page 15]
RFC 3339 Date and Time on the Internet: Timestamps July 2002
This table shows the date of the leap second, and the
between the time standard TAI (which isn't adjusted by leap seconds
and UTC after that leap second
UTC Date TAI - UTC After Leap
-------- ---------------------------
1972-06-30 11
1972-12-31 12
1973-12-31 13
1974-12-31 14
1975-12-31 15
1976-12-31 16
1977-12-31 17
1978-12-31 18
1979-12-31 19
1981-06-30 20
1982-06-30 21
1983-06-30 22
1985-06-30 23
1987-12-31 24
1989-12-31 25
1990-12-31 26
1992-06-30 27
1993-06-30 28
1994-06-30 29
1995-12-31 30
1997-06-30 31
1998-12-31 32
Klyne, et. al. Standards Track [Page 16]
RFC 3339 Date and Time on the Internet: Timestamps July 2002
The following people provided helpful advice for an
incarnation of this document: Ned Freed, Neal McBurnett,
Keegel, Markus Kuhn, Paul Eggert and Robert Elz. Thanks are also
to participants of the IETF Calendaring/Scheduling working
mailing list, and participants of the time zone mailing list
The following reviewers contributed helpful suggestions for
present revision: Tom Harsch, Markus Kuhn, Pete Resnick, Dan Kohn
Paul Eggert provided many careful observations regarding
subtleties of leap seconds and time zone offsets. The
people noted corrections and improvements to earlier drafts: Dr
Stockton, Jutta Degener, Joe Abley, and Dan Wing
Authors'
Chris
Sun
1050 Lakes Drive, Suite 250
West Covina, CA 91790
EMail: chris.newman@sun.
Graham Klyne (editor, this revision
Clearswift
1310
Arlington Business
Theale, Reading RG7 4
Phone: +44 11 8903 8903
Fax: +44 11 8903 9000
EMail: GK@ACM.
Klyne, et. al. Standards Track [Page 17]
RFC 3339 Date and Time on the Internet: Timestamps July 2002
Full Copyright
Copyright (C) The Internet Society (2002). All Rights Reserved
This document and translations of it may be copied and furnished
others, and derivative works that comment on or otherwise explain
or assist in its implementation may be prepared, copied,
and distributed, in whole or in part, without restriction of
kind, provided that the above copyright notice and this paragraph
included on all such copies and derivative works. However,
document itself may not be modified in any way, such as by
the copyright notice or references to the Internet Society or
Internet organizations, except as needed for the purpose
developing Internet standards in which case the procedures
copyrights defined in the Internet Standards process must
followed, or as required to translate it into languages other
English
The limited permissions granted above are perpetual and will not
revoked by the Internet Society or its successors or assigns
This document and the information contained herein is provided on
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED,
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE
Funding for the RFC Editor function is currently provided by
Internet Society
Klyne, et. al. Standards Track [Page 18]
if you see any problems within the linking, don't worry be happy,
this is version 0.1 of the Relevance System and you gotta expect some crappy subroutines sometimes,
just be content we did not write this in Java, which would have made this "bigger and better" HAHAHHA.
RFC documents can be found at I.E.T.F.
Relevance System Copyright © 2002 Spectrum WorldResearch
other technical nosh by ServerMasters Corporation
collaboration of BobX
