:: wikimiki.org ::

Internet Standard

Internet standard

An Internet standard is a specification for an innovative internetworking technology or methodology, which the Internet Engineering Task Force (IETF) ratified as an open standard after the innovation underwent peer review. An Internet standard begins as an Internet Draft, which may then mature into a Request for Comments memorandum. RFCs that are intended to become Internet standards evolve through a series of three maturation stages: proposed standard, draft standard, and standard; collectively, these stages of evolution are known as the standards track. A proposed standard specification is generally stable, has resolved known design choices, is believed to be well-understood, has received significant community review, and appears to enjoy enough community interest to be considered valuable. However, further experience might result in a change or even retraction of the specification before it advances. Usually, neither implementation nor operational experience is required. A specification from which at least two independent and interoperable implementations from different code bases have been developed, and for which sufficient successful operational experience has been obtained, may be elevated to the draft standard level. A Draft Standard is normally considered to be a final specification, and changes are likely to be made only to solve specific problems encountered. In most circumstances, it is reasonable for vendors to deploy implementations of Draft Standards into a disruption sensitive environment. A specification for which significant implementation and successful operational experience has been obtained may be elevated to the Internet standard level. An Internet standard, which may simply be referred to as a standard, is characterized by a high degree of technical maturity and by a generally held belief that the specified protocol or service provides significant benefit to the Internet community. Generally Internet standards cover interoperability of systems on the internet through defining protocols, messages formats, schemas, and languages. The most fundamental of the standards are the ones defining the Internet Protocol. All Internet standards are given a number in the STD series - The first document in this series, STD 1, describes the remaining documents in the series, and has a list of proposed standards. Often, documents in the STD series are copies of RFCs or are a few RFCs collected together. For example, STD 8 defines the core of the telnet protocol and comprises RFCs 854 and 855.

Reference

The Internet Standards Process is defined in a "Best Current Practice" document [http://ftp.rfc-editor.org/in-notes/bcp/bcp9.txt BCP 9] (currently RFC 2026).

External links

- [http://www.iab.org/ Internet Architecture Board]
- [http://www.ietf.org/iesg.html Internet Engineering Steering Group] Category:Internet standards

Specification

In engineering and manufacturing, the term specification has the following meanings:

Technical requirement

An essential technical requirement for items, materials, or services, including the procedures to be used to determine whether the requirement has been met. Specifications may also include requirements for preservation, packaging, packing, and marking. See requirements analysis.

Procurement

An official document intended primarily for supporting procurement, which document clearly and accurately describes the essential technical requirements for items, materials, or services, including the procedures by which it will be determined that the requirements have been met. An example of a Federal specification is FIPS-PUB 159, Detail Specification for 62.5-μm Core Diameter/125-μm Cladding Diameter Class Ia Multimode Optical Fibers. Source: from Federal Standard 1037C and from MIL-STD-188

Internet Engineering Task Force

The Internet Engineering Task Force (IETF) is charged with developing and promoting Internet standards, in particular, those of the TCP/IP protocol suite. It is an open, all-volunteer organization, with no formal membership or membership requirements. It is organized into a large number of working groups, each dealing with a specific topic, and intended to complete work on that topic and then shut down. Each working group has an appointed chair (or sometimes several co-chairs), along with a charter that describes its focus, and what and when it is expected to produce. The working groups are organized into areas by subject matter; each area is overseen by an area director (AD) (most areas have 2 co-AD's); the ADs appoint working group chairs. The area directors, together with the IETF Chair, form the Internet Engineering Steering Group (IESG), which is responsible for the overall operation of the IETF. The IETF is formally an activity under the umbrella of the Internet Society. The IETF is overseen by the Internet Architecture Board (IAB), which oversees its external relationships, and relations with the RFC Editor. The IAB is also jointly responsible for the IETF Administrative Oversight Committee (IAOC), which oversees the IETF Administrative Support Activity (IASA), which provides logistical, etc support for the IETF. The IAB also manages the Internet Research Task Force (IRTF), with which the IETF has a number of cross-group relations.

History

The IETF started in January of 1986 with U.S.-government-funded researchers meeting quarterly. Representatives from non-government vendors were invited, starting with the fourth IETF meeting, in October of that year. Since that time all IETF meetings have been open to anyone. The majority of the IETF's work is done on mailing lists, however, and meeting attendance is not required for contributors. The initial meetings were very small, with less than 35 people in attendance at each of the first five meetings and with the peak attendance in the first 13 meetings of only 120 attendees, at the 12th meeting in January of 1989. It has grown in both participation and scope a great deal since the early 90s; it had a peak attendance of 3000 at the July 2000 IETF held in San Diego, CA. Attendance declined with industry restructuring in the early 2000s, and is currently around 1500. During the early 1990s the IETF changed institutional form from an activity of the U.S. government to an independent, international activity associated with the Internet Society. The IETF has at times been ascribed nearly magical abilities by the trade press, who assumed its mechanisms were responsible for the success of the Internet because it works on the Internet's core protocols. The reality that it is a group of engineers putting together specifications so that multiple vendors' products can interoperate across networks is considerably more prosaic. The details of its operations have changed considerably as it has grown, but the basic mechanism remains publication of draft specifications, review and independent testing by participants, and republication. Interoperability is the chief test for IETF specifications becoming standards. Most of its specifications are focused on single protocols rather than tightly-interlocked systems. This has allowed its protocols to be used in many different systems, and its standards are routinely re-used by bodies which create full-fledged architectures (e.g. 3GPP IMS). Because it relies on volunteers and uses "rough consensus and running code" as its touchstone, it can, however, be slow whenever the number of volunteers is either too small to make progress or so large as to make consensus difficult. For protocols like SMTP, which is used to transport e-mail for a user community in the many hundreds of millions, there is also considerable resistance to any change which is not fully backwards compatible. Work within the IETF on ways to improve its speed is ongoing but, because the number of volunteers with opinions on it is very great, consensus mechanisms on how to improve have been slow to emerge.

List of IETF chairs

- Mike Corrigan (1986)
- Phill Gross (1986–1993)
- Paul Mockapetris (1994–1995)
- Fred Baker (1996–2001)
- Harald Tveit Alvestrand (2001–2005)
- Brian Carpenter (2005–)

External links and references

- [http://www.ietf.org/ The official IETF site]
- [http://www.ietf.org/proceedings/directory.html IETF Online Proceedings]
- [http://www.ietf.org/proceedings/directory2.html Early IETF Proceedings] (note: large pdf files, one for each volume)
- [http://www.ietf.org/meetings/past.meetings.html Past Meetings of the IETF]
- [http://www.ietf.org/ietf_chairs_year.html IETF Chairs]
- [http://www.ietf.org/rfc/rfc3160.txt The Tao of the IETF]: details on how IETF is organized [http://www.ietf.org/tao.html (also as HTML)]
- [http://koi.uoregon.edu/~iaoc/ IAOC information]
- [http://www.cs.berkeley.edu/~lazzaro/sa/pubs/txt/current-guide.txt An Implementation Guide for RTP MIDI]
- [http://www.cs.berkeley.edu/~lazzaro/sa/pubs/txt/current-rtp-midi.txt RTP Payload Format for MIDI] Category:Internet governance Category:Internet Category:Standards organizations ko:IETF ja:Internet Engineering Task Force

Open standard

Open Standards are publicly available specifications for achieving a specific task. By allowing anyone to obtain and implement the standard, they can increase compatibility between various hardware and software components, since anyone with the necessary technical know-how and resources can build products that work together with those of the other vendors that base their designs on the standard (although patent holders may impose "reasonable and non-discriminatory" royalty fees and other licensing terms on implementers of the standard). Many technical specifications that are sometimes considered standards are proprietary rather than being open, and are only available under restrictive contract terms (if they can be obtained at all) from the organization that owns the copyright for the specification. Being an open standard also does not necessarily imply that no licenses to patent rights are needed to use the standard or that such licenses are available for free. For example, the standards published by the major internationally-recognized standards bodies such as the ITU, ISO, and IEC are ordinarily considered open, but may require patent licensing fees for implementation. Open standards which can be implemented by anyone, without royalties or other restrictions, are sometimes referred to as open formats. There is little really universal agreement about the usage of either of the terms "open" or "standard". Some people restrict their use of the term "open" to royalty-free technologies, while others do not; and some people restrict their use of the term "standard" to technologies approved by formalized committees that are open to participation by all interested parties and operate on a consensus basis, while others do not.

Examples of open standards

Hardware:
- ISA (a specification by IBM for plug-in boards to IBM-architecture PCs, later standardized by the IEEE)
- PCI (a specification by Intel Corporation for plug-in boards to IBM-architecture PCs)
- AGP (a specification by Intel Corporation for plug-in boards to IBM-architecture PCs) Software:
- HTML/XHTML (specifications of the W3C for structured hyperlinked document formatting)
- SQL (a specification approved by ANSI and ISO, with multiple generations of design and additional less official variants)
- IP (a specification of the IETF for transmitting packets of data on a network - specifically, IETF RFC 791)
- TCP (a specification of the IETF for implementing streams of data on top of IP - specifically, IETF RFC 793)
- PDF/X (a specification by Adobe Systems Incorporated for formatted documents, later approved by ISO as ISO 15930-1:2001 [http://www.pdf-x.com/pdfx_123_1.php])
- OpenDocument (a specification by OASIS for office documents)

Patents

In 2002 and 2003 there was some controversy about using reasonable and non-discriminatory (RAND) licensing for the use of patented technology in web standards. Bruce Perens and others have argued that the use of patents restricts who can implement a standard to those able or willing to pay for the use of the patented technology. The requirement to pay some small amount per user, is often an insurmountable problem for free software or open source implementations which can be redistributed by anyone. Royalty free (RF) licensing is preferred by Open Source adepts. The GNU GPL license includes a section that enjoins anyone who distributes a program released under the GPL from enforcing patents on subsequent users of the software or derivative works.

Quotes

- EU Commissioner Erkki Liikanen: "Open standards are important to help create interoperable and affordable solutions for everybody. They also promote competition by setting up a technical playing field that is level to all market players. This means lower costs for enterprises and, ultimately, the consumer." (World Standards Day, 14 October, 2003) [http://europa.eu.int/rapid/start/cgi/guesten.ksh?p_action.gettxt=gt&doc=IP/03/1374%7C0%7CRAPID&lg=EN]

External links

- Bruce Perens: [http://perens.com/OpenStandards/ Open Standards: Principles and Practice]
- Ken Krechmer: [http://www.csrstds.com/openstds.html The Principles of Open Standards]
- European Commission: [http://europa.eu.int/ida/en/document/3439 Valoris report on Open Document Formats]
- The New York Times: [http://www.nytimes.com/2005/09/09/technology/09open.html?ex=1283918400&en=91f207f077cec245&ei=5088&partner=rssnyt&emc=rss Plan by 13 Nations Urges Open Technology Standards] Category:Standards

Internet Draft

Internet Drafts (IDs) is a series of documents published by the IETF. They are drafts for RFCs. They have a validity of only six months, after which the IETF deletes them, although expired IDs can be found on a number of sites around the Internet. They are given names of the following format: draft-ietf---.txt

External links

- http://ietf.org/ID.html — Official IETF ID site
- http://www.watersprings.org/pub/id/ — An archive of expired IDs Category:Internet standards

Request for Comments

In internetworking and computer network engineering, Request for Comments (RFC) documents are a series of memoranda encompassing new research, innovations, and methodologies applicable to Internet technologies. Through the Internet Society, engineers and computer scientists may publish discourse in the form of an RFC memorandum, either for peer review or simply to convey new concepts, information, or (occasionally) engineering humor. The Internet Engineering Task Force (IETF) adopts some of the applied information theory published in RFCs as Internet standards. The IETF issues each RFC document a unique serial number. Once issued a numerical identifier and published, an RFC is never rescinded; if the document requires amendments, the authors publish a revised document via the IETF; therefore, some RFCs obsolete others. Together, the serialized RFCs compose a continuous historical record of the evolution of Internet standards.

RFC production and evolution

The RFC production process differs from the standardization process of formal standards organizations such as ANSI. Internet technology experts may submit an Internet Draft without support from an external institution. Practically speaking, standards-track RFCs are usually produced by experts participating in working groups which first publish an Internet Draft. This approach facilitates initial rounds of peer review before documents mature into RFCs. The RFC tradition of pragmatic, experience-driven, after-the-fact standards-authorship accomplished by individuals or small working groups has important advantages over the more formal, committee-driven process typical of ANSI or ISO. Emblematic of some of these advantages is the existence of a flourishing tradition of joke RFCs. Usually at least one a year is published, usually on April Fool's Day. The RFCs are most remarkable for how well they work - they manage to have neither the ambiguities that are usually rife in informal specifications, nor the committee-perpetrated misfeatures that often haunt formal standards, and they define a network that has grown to truly worldwide proportions. For more details about RFCs and the RFC process, see RFC 2026, "The Internet Standards Process, Revision 3".

History

The inception of the RFC format occurred in 1969 as part of the seminal ARPANET project. Today, it is the official publication channel for the IETF, the Internet Architecture Board (IAB), and —to some extent—the global community of computer network researchers in general. The authors of the first RFCs typewrote their work and circulated hard copies among the ARPA researchers. In December of 1969, researchers began distributing new RFCs via the now-operational ARPANET. RFC 1, entitled "Host Software", was written by Steve Crocker of the University of California, Los Angeles (UCLA), and published on April 7, 1969. Crocker first drafted the document in his bathroom to avoid waking his roommate. Many of the subsequent RFCs of the 1970s also came from UCLA, not only because of the quality of the scholarship, but also because UCLA was one of the first Interface Message Processors (IMPs) on ARPANET. Douglas Engelbart's Augmentation Research Center (ARC) at Stanford Research Institute was another of the four first ARPANET nodes, as well as the first Network Information Centre, and (as noted by the sociologist Thierry Bardini) the source of a large number of early RFCs. From 1969 until 1998, Jon Postel served as the sole RFC editor. Following his death, the Internet Society (acting on behalf of the IETF) contracted the Networking Division of the USC Information Sciences Institute to assume the editorship and publishing responsibilities (under the direction of the IAB).

Obtaining RFCs

Official sources for RFCs on the World Wide Web are the [http://www.rfc-editor.org/rfc.html RFC Editor] and the [http://www.ietf.org/rfc.html IETF repository]. Unofficially, they are obtainable from a multitude of mirrors accessible via the HyperText Transfer Protocol, anonymous FTP, the gopher protocol, and other prominent application layer protocols. One may retrieve any individual, published RFC via the following Uniform Resource Locator by replacing the # with the document's RFC serial number: http://www.ietf.org/rfc/rfc#.txt Every RFC is available as ASCII text, but may also be available in other file formats; however, the definitive version of any standards-track specification is always the ASCII version.

Sources

- [http://www.rfc-editor.org/rfcfaq.html RFC Frequently Asked Questions]

:This article was originally based on material from the Free On-line Dictionary of Computing, which is licensed under the GFDL.

Category:FOLDOC sourced articles

External links

- [http://www.rfc-editor.org/rfc.html RFC Database]
- [http://www.ietf.org/iesg/1rfc_index.txt RFC Index] (plaintext)
- [http://www.rfc-editor.org/rfcxx00.html Official RFC standardization status]
- [http://www.ietf.org/rfc.html RFCs from the IETF]
- [http://www.elook.org/computing/request-for-comments.htm eLook.org Computing Reference - Request for Comments]

RFC document mirrors

- [http://tangentsoft.net/rfcs/ Important RFCs]
- [http://www.faqs.org/rfcs/np.html RFC by Category] at [http://www.faqs.org/ faqs.org]
- [http://www.rfc-archive.org/ RFC-Archive.org]
- [http://rfclibrary.hosting.com/ RFC Index]
- [http://www.elook.org/computing/rfc/ eLook Computing Reference - RFC Database]
- [http://rfc.8x.ca/ RFC Library - Searchable RFC database]
- [http://zvon.org/tmRFC/RFC_share/Output/index.html ZVON RFC Repository] Category:Internet standards ja:Request for Comments

Memorandum

A memorandum is a written form of communication most often employed in business environments. It is used as a means of communication between executives and their employees. A memorandum is typically written using the following structure: TO: FROM: DATE: the date of when the memorandum is being distributed SUBJECT: - Opening statement, that states the purpose of the memorandum. - Discussion segment, where the subject is developed. - Closing statements, that notifies the reader of what providences must follow. A memorandum can also be a legal document setting out the terms of an agreement or contract as in a "Memorandum of Sale" or "Memorandum of Shipment".

Internal links

See also business memo for a guide on how to create and format a business memo.

External links

- [http://owl.english.purdue.edu/handouts/pw/p_memo.html Memo Writing Brought to you by the Purdue University Online Writing Lab]
- [http://www.internalmemos.com Internal Memos], large internet collection of corporate memos and internal communication
- [http://www.uchicago.edu/research/jnl-crit-inq/features/artsstatements/arts.guillory.htm Article]: The Memo and Modernity

Telnet

Telnet is a network protocol used on the Internet or local area network LAN connections. IETF document STD 8 (aka [http://www.faqs.org/rfcs/rfc854.html RFC 854] and [http://www.faqs.org/rfcs/rfc855.html RFC 855]) states:

The purpose of the TELNET Protocol is to provide a fairly general, bi-directional, eight-bit byte oriented communications facility.

It is typically used to provide user oriented command line login sessions between hosts on the Internet. The name is derived from the words telephone network, since the program is designed to emulate a single terminal attached to the other computer. By extension, "telnet" also refers to the telnet program which provides the client part of the protocol. Telnet clients have been available on most Unix systems for many years, and are available for virtually all types of computers. On many systems, the "telnet" program may also be used to make interactive raw-TCP sessions and is used to communicate to services such as POP3 servers without specialized client software. "To telnet" is also used as a verb meaning to establish or use a telnet connection, as in, "If you need to change your password you need to telnet to the server and run the passwd command".

Protocol details

Telnet is a client-server protocol, based on TCP, and clients generally connect to port 23 on the host providing the service (though like many protocols in use on the Internet which port to use is fairly easy to change). Partly because of the design of the protocol and partly because of the flexibility typically provided by telnet programs, it is also possible to use a Telnet program to establish an interactive TCP connection to some other service on an Internet host. A classic use of this is telnetting to port 25 (where typically an SMTP server is to be found) to debug a mail server. The Telnet protocol can be divided into a core and a set of extensions. The core protocol is described by IETF documents RFC 854 and RFC 855 which are also collected together in STD 8, which defines fairly basic operating characteristics of the protocol and a means of defining and implementing extensions. There are many extensions, some of which have been adopted as Internet Standards, some of which haven't. IETF STD document numbers from 27 through to 32 define various Telnet extensions (most of which are extremely common). Of the remaining extensions the most useful ones are probably those that are on the IETF standards track as proposed standards; details can be found in STD 1.

Security

There are three main problems with Telnet, making it a bad choice for modern systems from the point of view of computer security:
- Commonly used telnet daemons have several vulnerabilities discovered over the years, and probably several more still exist.
- Telnet, by default, does not encrypt any data sent over the connection (including passwords), and so it is trivial to eavesdrop on the communications and use the password later for malicious purposes.
- Telnet lacks an authentication scheme that makes it possible to ensure that communication is carried out between the two desired hosts, and not intercepted in the middle. In environments where security is important, such as on the public Internet, telnet should not be used. Telnet sessions are unencrypted. This means that anybody who has access to any router, switch, or gateway located on the network between the two hosts where telnet is being used can intercept the telnet packets passing by and easily obtain login and password information (and whatever else is typed) with any of several common utilities like tcpdump and Ethereal. These flaws have seen the usage of the Telnet protocol drop rapidly in favor of a more secure and functional protocol called SSH, released in 1995. SSH provides all functionality present in telnet, with the addition of strong encryption to prevent sensitive data such as passwords from being intercepted, and public key authentication, to ensure that the remote computer is actually who it claims to be. Experts in computer security, such as SANS Institute, and the members of the comp.os.linux.security newsgroup recommend that the use of Telnet for remote logins should be discontinued under all normal circumstances. When telnet was initially developed in 1969, most users of networked computers were in the computer departments of academic institutions, or at large private and government research facilities. In this environment, security was not nearly as much of a concern as it became after the bandwidth explosion of the 1990s. With the exponential rise in the number of people with access to the Internet, and by extension, the number of people attempting to crack into other people's servers, telnet should generally not ever be used on networks with Internet connectivity. Telnet clients are still occasionally used to manually "talk" to other services. It is sometimes used in debugging network services such as an SMTP or HTTP server, by serving as a simple way to send commands to the server and examine the responses. Telnet can also be used as a rudimentary IRC client if you know the protocol well enough. Telnet is also heavily used for MUD games played over the Internet, as well as talkers, MUSHes, MUCKs and MOOes.

Telnet clients

Windows

- [http://dtelnet.sourceforge.net/ dtelnet] is a free telnet client for Windows.
- [http://www.pegsol.com/whitehorn/downloads.htm Whitehorn Secure Terminal] free Telnet client for Windows
- [http://consoletelnet.sourceforge.net/ Console telnet] is a full screen (console) telnet client for MS Win32 environments.

Macintosh

- [http://www.brown.edu/Facilities/CIS/tn3270/ tn3270] is a free telnet client for Macintosh.

Multiplatform

- PuTTY is a free SSH, Telnet, rlogin, and raw TCP client for Windows and Unix.

Telnet servers

- [http://telnetd.sourceforge.net/ telnetd] is an embeddable telnet daemon written in Java.

Coordinated Universal Time

:For alternate uses of UTC see UTC (disambiguation) Coordinated Universal Time or UTC, also sometimes referred to as "Zulu time" or Z, is an atomic realization of Universal Time (UT) or Greenwich Mean Time, the astronomical basis for civil time. Time zones around the world are expressed as positive and negative offsets from UT. UTC differs by an integral number of seconds from International Atomic Time (TAI), as measured by atomic clocks and a fractional number of seconds from UT. UTC is a hybrid time scale: the rate of UTC is based on atomic frequency standards but the epoch of UTC is synchronized to remain close to astronomical UT. The Earth's rotation is very slowly decelerating (due to braking action of the tides), hence the mean solar day has increased since TAI was introduced on 1 January 1958 (under another name). For this reason, UT is 'slower' than TAI. As of 1 January 1999, TAI was ahead of UTC by 32 seconds, consisting of a 10-second offset introduced on 1 January 1972 to account for all variations between 1958 and 1971, plus an additional 22 leap seconds introduced between 1972 and 1998. UTC is maintained within 0.9 s of UT1 (UT1 is one of three precise definitions of UT); leap seconds are added (or, theoretically, subtracted) at the end of any UTC month as necessary. The primary dates for leap second adjustments are at the end of the day on June 30 and December 31. The secondary dates, which to date have been unused, are March 31 and September 30. To date, all such adjustments – the first in 1972 – have been positive and applied on dates June 30 or December 31, where an additive leap second is designated as 23:59:60. The announcement of leap seconds is made by the International Earth Rotation and Reference Systems Service (IERS), based on precise astronomical forecasts of the Earth's rotation. Historically, one leap second has been required every one to two years. However a leap second has not been required since 1998, as the deceleration of the Earth's rotation slowed temporarily in the past seven years. The IERS announced in July 2005 that the next leap second will be on 31 December 2005. For most practical and legal-trade purposes, the fractional difference between UTC and UT (or GMT) is inconsequentially small, and for this reason UTC is colloquially called GMT sometimes, even if this is not technically correct.

Proposal to redefine UTC and abolish leap seconds

There is a proposal to redefine UTC and abolish leap seconds, such that sundials would slowly get further out-of-sync with civil time. See Leap second for more information.

General information

"UTC" is not a true acronym; it is a variant of Universal Time, UT, and has a modifier C (for "coordinated") appended to it just like other variants of UT. It [http://www.boulder.nist.gov/timefreq/general/misc.htm#Anchor-14550 may be regarded] as a compromise between the English acronym "CUT" and the French acronym "TUC" (temps universel coordonné). It is sometimes erroneously expanded into "Universal Time Code".

Converting Universal Time
to Standard (Winter) Local Times
Hawaii-Aleutian Standard Time	UTC -10
Alaska Standard Time	UTC -9
Pacific Standard Time	UTC -8
Mountain Standard Time	UTC -7
Central Standard Time	UTC -6
Eastern Standard Time	UTC -5
Atlantic Standard Time	UTC -4
Greenwich Mean Time/Western European Time	UTC
Central European Time	UTC +1
Eastern European Time	UTC +2
Moscow Time	UTC +3
Indian Standard Time	UTC +5:30
Singapore Standard Time, Hong Kong Time, Australian Western Standard Time, Chinese Standard Time	UTC +8
Japan Standard Time, Korea Standard Time	UTC +9
Australian Central Standard Time	UTC +9:30
Australian Eastern Standard Time	UTC +10
New Zealand Standard Time	UTC +12

For more, see time zone.

International standard UTC time can only be determined to the highest precision after the fact, as atomic time is determined by the reconciliation of the observed differences between an ensemble of atomic clocks maintained by a number of national time bureaus. This is done under the auspices of the Bureau International des Poids et Mesures (International Bureau of Weights and Measures). However, local clusters of atomic clocks are sufficient for accuracy to within a few tens of nanoseconds. UTC is the time system used for many Internet and World Wide Web standards. In particular, the Network Time Protocol, designed to synchronize the clocks of many computers over the Internet (usually to that of a known accurate atomic clock), uses UTC. As indicated in the standards, it is convenient to include the UTC date too. The UT time zone is sometimes denoted by the letter Z since the equivalent nautical time zone (GMT) has been denoted by Z since about 1950, and by a "zone description" of zero hours since 1920. See Time zone history. Since the NATO phonetic alphabet and radio-amateur word for Z is "Zulu", UT is sometimes known as Zulu time.

Amateur Radio

Those who transmit on the amateur radio bands often log the time of their radio contacts in UTC, as transmissions can go worldwide on some frequencies. In the past, the FCC required all amateur radio operators in the United States of America to log their radio conversations. While maintaining a record of radio transmissions is no longer required in the USA, many American amateur radio operators still choose to maintain a log expressing the time of their transmissions in UTC, due to the world wide reach of ham radio.

References

- ITU-R Recommendation TF.460-4: Standard-frequency and time-signal emissions. International Telecommunication Union. (Annex I of this document contains the official definition of UTC.)
- Dennis D. McCarthy: "Astronomical Time". Proc. IEEE, Vol. 79, No. 7, July 1991, pp. 915-920.
- Nelson, McCarthy, et al.: "[http://www.cl.cam.ac.uk/~mgk25/time/metrologia-leapsecond.pdf The leap second: its history and possible future]" (381 KB PDF file), Metrologia, Vol. 38, pp. 509–529, 2001.
- David W. Allan, Neil Ashby, Clifford C. Hodge: The Science of Timekeeping. Hewlett Packard Application Note 1289, 1997.

External links

- [http://www.bipm.org/en/scientific/tai/time_server.html Bureau International des Poids et Mesures UTC/TAI Time Server]
- [http://www.time.gov/ The official U.S. time]
- [http://www.worldtimeserver.com/ World Time Server - any location, any time]
- [http://www.thetimenow.com/ thetimeNOW - Current time in all time zones]
- [http://aa.usno.navy.mil/faq/docs/UT.html United States Naval Observatory - What is Universal Time?]
- [http://hpiers.obspm.fr/eoppc/bul/bulc/bulletinc.dat International Earth Rotation Service Leap Second Updates]
- [http://www.qsl.net/zl1bpu/micro/CLOCK/ Make your own UTC /Local time hardware clock]
- [http://www.w3.org/TR/NOTE-datetime W3C Specification about UTC Date and Time] and IETF Internet standard RFC 3339
- [http://www.grc.nasa.gov/WWW/MAEL/ag/zulu.htm Zulu Time]
- [http://www.hko.gov.hk/gts/time/worldtime2.htm Hong Kong Time by Hong Kong Observatory] Category:Time scales als:UTC ko:협정 세계시 zh-min-nan:UTC ja:協定世界時 nb:UTC simple:Coordinated Universal Time th:เวลาพิกัดสากล

As of 2005

2005

Category:Internet standards

This category contains current and future Internet Standards, i.e., published RFC documents currently on the IETF's Standards Track. This can include both network protocols and other non-protocol standards. See also: :Category:Internet protocols Category:Computer and telecommunication standards Category:Electronic documents Standards Category:Standards ko:분류:인터넷 표준

Vorlage:Portal Leichtathletik/Aktuelle Ereignisse

- 26.11. Jens Borrmann wird Deutsche Crossmeister über die Langstrecke.
- 26.11. Dominik Burkhardt wird Deutscher Crossmeister über die Mittelstrecke.
- 26.11. Sabrina Mockenhaupt wird Deutsche Crossmeisterin.

cellulitis venice luxury hotels narty francja Sklep Zoologiczny tablice

:: RELATED NEWS ::

Mary de Bohun
Marie de Bohun, född ca 1369, död 4 juni 1394, var Henrik Bolingbrokes hustru och mor till Henrik V, men blev aldrig drottning. Som dotter till Humphrey de Bohun, earl av Hereford, hade hon ett stort arv, och hennes äldre syster Eleanor, blev hustru till 1369, död 4 juni 1394, var Henrik Bolingbrokes hustru och mor till Henrik V, men blev aldrig drottning. Som dotter till Humphrey de Bohun, earl av Hereford, hade hon ett stort arv, och hennes äldre syster Eleanor, blev hustru till 3 november 1929 i Stockholm, svensk kompositör, dirigent, kapellmästare, musikarrangör och musiker (piano). Olsson studerade till kantor, efter studerna var han engagerad som piani

Suzuki Sarina
Suzuki Sarina (鈴木紗理奈), född 13 juli 1977 i Settsu, Osaka prefektur. Japansk s.k. "talang" (tarento). Förekommer ofta i panelen i program som London Hearts och Mecha Mecha Iketeru. Har också medverkat i japan

Terrängbil 30/40
Terrängbil 30/40 (Tgb 30/40) är den vanligaste lastbilsversionen inom Försvarsmakten. Två versioner levererade 1975. Vanligtvis kallas den bara Tgb 30/40.

Historia

Under 1964 började man vid FMV diskutera en ny terrängbil för att fylla försvarets behov. 1969 skrevs kotrakt med Scania om provbilar. Efter

Tony Leung Chiu Wai
Tony Leung Chiu Wai , född 27 juni 1962 i Hong Kong, Kina, kinesisk skådespelare.

Filmografi

- 2046 (2004)
- Hero (2002)
-
Read More...

Spermaharen
Spermaharen är en numera nedlagd satirisk webbsida skapad av humorgruppen Killinggänget. Webbsidan har sammanställts och givits ut i bok- och dvd-form. Ansvarig utgivare är Henrik Schyffert. Begravningsbyrån Fonus startade en rättsprocess mot Spermaharen för att webbsidan använt Fonus varumärke i sin satir. Fonus förlorade denna rättsprocess. Spermaharen fick också uppmärksamhet efter att författarna