DOCSLIB.ORG

2048 Innosoft BCP: 13 J. Klensin Obsoletes: 1521, 1522, 1590 MCI Category: Best Current Practice J

Total Page：16

File Type：pdf, Size：1020Kb

Download full-text PDF Read full-text
2048 Innosoft BCP: 13 J. Klensin Obsoletes: 1521, 1522, 1590 MCI Category: Best Current Practice J Network Working Group N. Freed Request for Comments: 2048 Innosoft BCP: 13 J. Klensin Obsoletes: 1521, 1522, 1590 MCI Category: Best Current Practice J. Postel ISI November 1996 Multipurpose Internet Mail Extensions (MIME) Part Four: Registration Procedures Status of this Memo This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. Distribution of this memo is unlimited. Abstract STD 11, RFC 822, defines a message representation protocol specifying considerable detail about US-ASCII message headers, and leaves the message content, or message body, as flat US-ASCII text. This set of documents, collectively called the Multipurpose Internet Mail Extensions, or MIME, redefines the format of messages to allow for (1) textual message bodies in character sets other than US-ASCII, (2) an extensible set of different formats for non-textual message bodies, (3) multi-part message bodies, and (4) textual header information in character sets other than US-ASCII. These documents are based on earlier work documented in RFC 934, STD 11, and RFC 1049, but extends and revises them. Because RFC 822 said so little about message bodies, these documents are largely orthogonal to (rather than a revision of) RFC 822. Freed, et. al. Best Current Practice [Page 1] RFC 2048 MIME Registration Procedures November 1996 This fourth document, RFC 2048, specifies various IANA registration procedures for the following MIME facilities: (1) media types, (2) external body access types, (3) content-transfer-encodings. Registration of character sets for use in MIME is covered elsewhere and is no longer addressed by this document. These documents are revisions of RFCs 1521 and 1522, which themselves were revisions of RFCs 1341 and 1342. An appendix in RFC 2049 describes differences and changes from previous versions. Table of Contents 1. Introduction ......................................... 3 2. Media Type Registration .............................. 4 2.1 Registration Trees and Subtype Names ................ 4 2.1.1 IETF Tree ......................................... 4 2.1.2 Vendor Tree ....................................... 4 2.1.3 Personal or Vanity Tree ........................... 5 2.1.4 Special `x.' Tree ................................. 5 2.1.5 Additional Registration Trees ..................... 6 2.2 Registration Requirements ........................... 6 2.2.1 Functionality Requirement ......................... 6 2.2.2 Naming Requirements ............................... 6 2.2.3 Parameter Requirements ............................ 7 2.2.4 Canonicalization and Format Requirements .......... 7 2.2.5 Interchange Recommendations ....................... 8 2.2.6 Security Requirements ............................. 8 2.2.7 Usage and Implementation Non-requirements ......... 9 2.2.8 Publication Requirements .......................... 10 2.2.9 Additional Information ............................ 10 2.3 Registration Procedure .............................. 11 2.3.1 Present the Media Type to the Community for Review 11 2.3.2 IESG Approval ..................................... 12 2.3.3 IANA Registration ................................. 12 2.4 Comments on Media Type Registrations ................ 12 2.5 Location of Registered Media Type List .............. 12 2.6 IANA Procedures for Registering Media Types ......... 12 2.7 Change Control ...................................... 13 2.8 Registration Template ............................... 14 3. External Body Access Types ........................... 14 3.1 Registration Requirements ........................... 15 3.1.1 Naming Requirements ............................... 15 Freed, et. al. Best Current Practice [Page 2] RFC 2048 MIME Registration Procedures November 1996 3.1.2 Mechanism Specification Requirements .............. 15 3.1.3 Publication Requirements .......................... 15 3.1.4 Security Requirements ............................. 15 3.2 Registration Procedure .............................. 15 3.2.1 Present the Access Type to the Community .......... 16 3.2.2 Access Type Reviewer .............................. 16 3.2.3 IANA Registration ................................. 16 3.3 Location of Registered Access Type List ............. 16 3.4 IANA Procedures for Registering Access Types ........ 16 4. Transfer Encodings ................................... 17 4.1 Transfer Encoding Requirements ...................... 17 4.1.1 Naming Requirements ............................... 17 4.1.2 Algorithm Specification Requirements .............. 18 4.1.3 Input Domain Requirements ......................... 18 4.1.4 Output Range Requirements ......................... 18 4.1.5 Data Integrity and Generality Requirements ........ 18 4.1.6 New Functionality Requirements .................... 18 4.2 Transfer Encoding Definition Procedure .............. 19 4.3 IANA Procedures for Transfer Encoding Registration... 19 4.4 Location of Registered Transfer Encodings List ...... 19 5. Authors' Addresses ................................... 20 A. Grandfathered Media Types ............................ 21 1. Introduction Recent Internet protocols have been carefully designed to be easily extensible in certain areas. In particular, MIME [RFC 2045] is an open-ended framework and can accommodate additional object types, character sets, and access methods without any changes to the basic protocol. A registration process is needed, however, to ensure that the set of such values is developed in an orderly, well-specified, and public manner. This document defines registration procedures which use the Internet Assigned Numbers Authority (IANA) as a central registry for such values. Historical Note: The registration process for media types was initially defined in the context of the asynchronous Internet mail environment. In this mail environment there is a need to limit the number of possible media types to increase the likelihood of interoperability when the capabilities of the remote mail system are not known. As media types are used in new environments, where the proliferation of media types is not a hindrance to interoperability, the original procedure was excessively restrictive and had to be generalized. Freed, et. al. Best Current Practice [Page 3] RFC 2048 MIME Registration Procedures November 1996 2. Media Type Registration Registration of a new media type or types starts with the construction of a registration proposal. Registration may occur in several different registration trees, which have different requirements as discussed below. In general, the new registration proposal is circulated and reviewed in a fashion appropriate to the tree involved. The media type is then registered if the proposal is acceptable. The following sections describe the requirements and procedures used for each of the different registration trees. 2.1. Registration Trees and Subtype Names In order to increase the efficiency and flexibility of the registration process, different structures of subtype names may be registered to accomodate the different natural requirements for, e.g., a subtype that will be recommended for wide support and implementation by the Internet Community or a subtype that is used to move files associated with proprietary software. The following subsections define registration "trees", distinguished by the use of faceted names (e.g., names of the form "tree.subtree...type"). Note that some media types defined prior to this document do not conform to the naming conventions described below. See Appendix A for a discussion of them. 2.1.1. IETF Tree The IETF tree is intended for types of general interest to the Internet Community. Registration in the IETF tree requires approval by the IESG and publication of the media type registration as some form of RFC. Media types in the IETF tree are normally denoted by names that are not explicitly faceted, i.e., do not contain period (".", full stop) characters. The "owner" of a media type registration in the IETF tree is assumed to be the IETF itself. Modification or alteration of the specification requires the same level of processing (e.g. standards track) required for the initial registration. 2.1.2. Vendor Tree The vendor tree is used for media types associated with commercially available products. "Vendor" or "producer" are construed as equivalent and very broadly in this context. Freed, et. al. Best Current Practice [Page 4] RFC 2048 MIME Registration Procedures November 1996 A registration may be placed in the vendor tree by anyone who has need to interchange files associated with the particular product. However, the registration formally belongs to the vendor or organization producing the software or file format. Changes to the specification will be made at their request, as discussed in subsequent sections. Registrations in the vendor tree will be distinguished by the leading facet "vnd.". That may be followed, at the discretion of the registration, by either a media type name from a well-known producer (e.g., "vnd.mudpie") or by an IANA-approved designation of the producer's name which is then followed by a media type or product designation (e.g., vnd.bigcompany.funnypictures). While public exposure and review of media types to be registered in the vendor tree is not required, using the ietf-types list for review is strongly encouraged to improve the quality of those specifications. Registrations in the vendor tree may be submitted directly to the IANA. 2.1.3. Personal or Vanity Tree Registrations for
Load more

Recommended publications
  • Network Working Group N. Freed Request for Comments: 2049 Innosoft Obsoletes: 1521, 1522, 1590 N
    Network Working Group N. Freed Request for Comments: 2049 Innosoft Obsoletes: 1521, 1522, 1590 N. Borenstein Category: Standards Track First Virtual November 1996 Multipurpose Internet Mail Extensions (MIME) Part Five: Conformance Criteria and Examples Status of this Memo This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited. Abstract STD 11, RFC 822, defines a message representation protocol specifying considerable detail about US-ASCII message headers, and leaves the message content, or message body, as flat US-ASCII text. This set of documents, collectively called the Multipurpose Internet Mail Extensions, or MIME, redefines the format of messages to allow for (1) textual message bodies in character sets other than US-ASCII, (2) an extensible set of different formats for non-textual message bodies, (3) multi-part message bodies, and (4) textual header information in character sets other than US-ASCII. These documents are based on earlier work documented in RFC 934, STD 11, and RFC 1049, but extends and revises them. Because RFC 822 said so little about message bodies, these documents are largely orthogonal to (rather than a revision of) RFC 822. The initial document in this set, RFC 2045, specifies the various headers used to describe the structure of MIME messages. The second document defines the general structure of the MIME media typing system and defines an initial set of media types.
    [Show full text]
  • About | Network Startup Resource Center
    UO Home | Dept Index HOME ABOUT ACTIVITIES NEWS SUPPORTERS CALENDAR Enter your keywords Search About Index Core Support Main Focus Areas Overview Early History: 1990's International TCP/IP Training Workshops Computing, Networking Equipment & Book Donations Hosting Network Engineering Interns Financial and Operational Support Core Support The NSRC is funded by grant number 1451045 from the International Research Network Connections (IRNC) program of the National Science Foundation and Google, with additional contributions from dozens of public and private organizations. The NSRC works closely with several University of Oregon organizations, including the Route Views project, the Network and Telecommunication Services group, UO Libraries, and the Wired Humanities Project (WHP). Main Focus Areas Helping develop and deploy Internet infrastructure in R&E networks Assisting US scientists with international research partnerships World Map of Assistance from 1992-2014 Providing technical information and tools to network operators Providing direct network engineering and design assistance Helping organize regional training workshops and centers Coordinating donations and shipments of networking books and equipment Helping develop Internet eXchange points Helping build wireless network infrastructure Hosting network engineering interns Advising on how to establish help desk/user support services Maintaining a historical archive of Internet connectivity Overview The Network Startup Resource Center works directly with the indigenous network engineers and operators who develop and maintain the Internet infrastructure in their respective countries and regions by providing technical information, engineering assistance, training, donations of networking books, equipment and other resources. The end goal in this work is to make it easier for local scientists, engineers and educators to collaborate via the Internet with their international colleagues by helping to connect communities of interest.
    [Show full text]
  • The People Who Invented the Internet Source: Wikipedia's History of the Internet
    The People Who Invented the Internet Source: Wikipedia's History of the Internet PDF generated using the open source mwlib toolkit. See http://code.pediapress.com/ for more information. PDF generated at: Sat, 22 Sep 2012 02:49:54 UTC Contents Articles History of the Internet 1 Barry Appelman 26 Paul Baran 28 Vint Cerf 33 Danny Cohen (engineer) 41 David D. Clark 44 Steve Crocker 45 Donald Davies 47 Douglas Engelbart 49 Charles M. Herzfeld 56 Internet Engineering Task Force 58 Bob Kahn 61 Peter T. Kirstein 65 Leonard Kleinrock 66 John Klensin 70 J. C. R. Licklider 71 Jon Postel 77 Louis Pouzin 80 Lawrence Roberts (scientist) 81 John Romkey 84 Ivan Sutherland 85 Robert Taylor (computer scientist) 89 Ray Tomlinson 92 Oleg Vishnepolsky 94 Phil Zimmermann 96 References Article Sources and Contributors 99 Image Sources, Licenses and Contributors 102 Article Licenses License 103 History of the Internet 1 History of the Internet The history of the Internet began with the development of electronic computers in the 1950s. This began with point-to-point communication between mainframe computers and terminals, expanded to point-to-point connections between computers and then early research into packet switching. Packet switched networks such as ARPANET, Mark I at NPL in the UK, CYCLADES, Merit Network, Tymnet, and Telenet, were developed in the late 1960s and early 1970s using a variety of protocols. The ARPANET in particular led to the development of protocols for internetworking, where multiple separate networks could be joined together into a network of networks. In 1982 the Internet Protocol Suite (TCP/IP) was standardized and the concept of a world-wide network of fully interconnected TCP/IP networks called the Internet was introduced.
    [Show full text]
  • (IETF) J. Klensin Request for Comments: 6152 STD: 71 N
    Internet Engineering Task Force (IETF) J. Klensin Request for Comments: 6152 STD: 71 N. Freed Obsoletes: 1652 Oracle Category: Standards Track M. Rose ISSN: 2070-1721 Dover Beach Consulting, Inc. D. Crocker, Ed. Brandenburg InternetWorking March 2011 SMTP Service Extension for 8-bit MIME Transport Abstract This memo defines an extension to the SMTP service whereby an SMTP content body consisting of text containing octets outside of the US-ASCII octet range (hex 00-7F) may be relayed using SMTP. Status of This Memo This is an Internet Standards Track document. This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 5741. Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc6152. Copyright Notice Copyright (c) 2011 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
    [Show full text]
  • Update 6: Internet Society 20Th Anniversary and Global INET 2012
    Update 6: Internet Society 20th Anniversary and Global INET 2012 Presented is the latest update (edited from the previous “Update #6) on the Global INET 2012 and Internet Hall of Fame. Executive Summary By all accounts, Global INET was a great success. Bringing together a broad audience of industry pioneers; policy makers; technologists; business executives; global influencers; ISOC members, chapters and affiliated community; and Internet users, we hosted more than 600 attendees in Geneva, and saw more than 1,300 participate from remote locations. Global INET kicked off with our pre‐conference programs: Global Chapter Workshop, Collaborative Leadership Exchange and the Business Roundtable. These three programs brought key audiences to the event, and created a sense of energy and excitement that lasted through the week. Of key importance to the program was our outstanding line‐up of keynotes, including Dr. Leonard Kleinrock, Jimmy Wales, Francis Gurry, Mitchell Baker and Vint Cerf. The Roundtable discussions at Global INET featured critical topics, and included more than 70 leading experts engaged in active dialogue with both our in‐room and remote audiences. It was truly an opportunity to participate. The evening of Monday 23 April was an important night of celebration and recognition for the countless individuals and organizations that have dedicated time and effort to advancing the availability and vitality of the Internet. Featuring the Internet Society's 20th Anniversary Awards Gala and the induction ceremony for the Internet Hall of Fame, the importance of the evening cannot be understated. The media and press coverage we have already received is a testament to the historic nature of the Internet Hall of Fame.
    [Show full text]
  • A Security Analysis of Email Communications
    A security analysis of email communications Ignacio Sanchez Apostolos Malatras Iwen Coisel Reviewed by: Jean Pierre Nordvik 2 0 1 5 EUR 28509 EN European Commission Joint Research Centre Institute for the Protection and Security of the Citizen Contact information Ignacio Sanchez Address: Joint Research Centre, Via Enrico Fermi 2749, I - 21027 Ispra (VA), Italia E-mail: [email protected] JRC Science Hub https://ec.europa.eu/jrc Legal Notice This publication is a Technical Report by the Joint Research Centre, the European Commission’s in-house science service. It aims to provide evidence-based scientific support to the European policy-making process. The scientific output expressed does not imply a policy position of the European Commission. Neither the European Commission nor any person acting on behalf of the Commission is responsible for the use which might be made of this publication. All images © European Union 2015, except: Frontpage : © bluebay2014, fotolia.com JRC 99372 EUR 28509 EN ISSN 1831-9424 ISBN 978-92-79-66503-5 doi:10.2760/319735 Luxembourg: Publications Office of the European Union, 2015 © European Union, 2015 Reproduction is authorised provided the source is acknowledged. Printed in Italy Abstract The objective of this report is to analyse the security and privacy risks of email communications and identify technical countermeasures capable of mitigating them effectively. In order to do so, the report analyses from a technical point of view the core set of communication protocols and standards that support email communications in order to identify and understand the existing security and privacy vulnerabilities. On the basis of this analysis, the report identifies and analyses technical countermeasures, in the form of newer standards, protocols and tools, aimed at ensuring a better protection of the security and privacy of email communications.
    [Show full text]
  • List of Internet Pioneers
    List of Internet pioneers Instead of a single "inventor", the Internet was developed by many people over many years. The following are some Internet pioneers who contributed to its early development. These include early theoretical foundations, specifying original protocols, and expansion beyond a research tool to wide deployment. The pioneers Contents Claude Shannon The pioneers Claude Shannon Claude Shannon (1916–2001) called the "father of modern information Vannevar Bush theory", published "A Mathematical Theory of Communication" in J. C. R. Licklider 1948. His paper gave a formal way of studying communication channels. It established fundamental limits on the efficiency of Paul Baran communication over noisy channels, and presented the challenge of Donald Davies finding families of codes to achieve capacity.[1] Charles M. Herzfeld Bob Taylor Vannevar Bush Larry Roberts Leonard Kleinrock Vannevar Bush (1890–1974) helped to establish a partnership between Bob Kahn U.S. military, university research, and independent think tanks. He was Douglas Engelbart appointed Chairman of the National Defense Research Committee in Elizabeth Feinler 1940 by President Franklin D. Roosevelt, appointed Director of the Louis Pouzin Office of Scientific Research and Development in 1941, and from 1946 John Klensin to 1947, he served as chairman of the Joint Research and Development Vint Cerf Board. Out of this would come DARPA, which in turn would lead to the ARPANET Project.[2] His July 1945 Atlantic Monthly article "As We Yogen Dalal May Think" proposed Memex, a theoretical proto-hypertext computer Peter Kirstein system in which an individual compresses and stores all of their books, Steve Crocker records, and communications, which is then mechanized so that it may Jon Postel [3] be consulted with exceeding speed and flexibility.
    [Show full text]
  • Advisory Committee (Advcomm) Report
    Advisory Committee (AdvComm) Report Wednesday Plenary IETF 58 Outline • What is AdvComm? • Current Reality • Identified stress points • Requirements • Recommendations •Next steps What is AdvComm? • A committee formed to advise the Internet Architecture Board (IAB) • Members – Leslie Daigle, IAB Chair & Chair of AdvComm – Harald Alvestrand, IETF Chair – Lynn St. Amour (ISOC President) – Fred Baker (Chair, ISOC Board of Trustees) – Brian Carpenter (ex-IAB Chair, ex-member ISOC Board of Trustees) – John Klensin (ex-IAB Chair, former IESG) – Steve Crocker (member, ISOC Board of Trustees) – Russ Housley (IESG Security Area Director), – Bernard Aboba (member, IAB) AdvComm, cont’d •Timeline – IETF 58: Presentation of findings & recommendations – mid-November: publish Internet Draft documenting the findings & recommendations – mid-December: Incorporate comments, issue final document & shutdown • Acknowledgements – Thoughtful input from RFC Editor, Secretariat and IANA in response to AdvComm’s questions Goals & Non-Goals • Goals – To review the IETF administrative structure and relationships (RFC Editor, IETF Secretariat, IANA) – To propose structural changes necessary to improve the functioning of the IETF • Non-goals – Reorganization of IETF internal structure (IESG, IAB) – Changes to the standards process IETF Functions & Organizations Function Known as Organization (within the IETF) IESG Support Secretariat Foretec/CNRI IAB Support ISOC/Secretariat ISOC, Foretec/CNRI WG Support Secretariat Foretec/CNRI Community Support Secretariat Foretec/CNRI IETF Meetings Secretariat Foretec/CNRI RFC Publication RFC Editor USC/ISI Parameter Registration IANA ICANN Legal, insurance, etc. (largely invisible) Provided by ISOC IETF Support Organizations • Internet Society (ISOC) – Since 1992, the organizational home of the IETF, IAB, IESG and IRTF. • Corporation for National Research Initiatives (CNRI)/Foretec – Since 1987, CNRI has provided the IETF Secretariat.
    [Show full text]
  • Requests for Comments (RFC)
    ,QWHUQHW6RFLHW\ ,62& ,QWHUQHW$UFKLWHFWXUH%RDUG Requests for Comments (RFC) 6HOHFWHG5HTXHVWVIRU&RPPHQWVUHOHYDQWWRLQVWUXFWLRQDOGHVLJQ5HTXHVWV IRU&RPPHQWVRU5)&VLQFOXGH,QWHUQHWVWDQGDUGVGHYHORSHGE\WKH ,QWHUQHW$UFKLWHFWXUH%RDUGIRUWKH,QWHUQHW6RFLHW\0DQ\RIWKH5)&V SURYLGHLPSRUWDQWWHFKQLFDOLQIRUPDWLRQDQGDUHQRWFODVVLILHGDV ³VWDQGDUGV´ 5HSURGXFHGLQDFFRUGDQFHZLWKWKHSROLFLHVRIWKH,QWHUQHW6RFLHW\)RUWKH ODWHVWLQIRUPDWLRQDERXWWKH6RFLHW\VHHZZZLVRFRUJ)RUPRUH LQIRUPDWLRQDERXWVWDQGDUGVVHHZZZLDERUJ RFC1314 Web Address: Image Exchange Format http://sunsite.cnlab-switch.ch/ By: Katz & Cohen Network Working Group A. Katz Request for Comments: 1314 D. Cohen ISI April 1992 A File Format for the Exchange of Images in the Internet Status of This Memo This document specifies an IAB standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "IAB Official Protocol Standards" for the standardization state and status of this protocol. Distribution of this memo is unlimited. Abstract This document defines a standard file format for the exchange of fax-like black and white images within the Internet. It is a product of the Network Fax Working Group of the Internet Engineering Task Force (IETF). The standard is: ** The file format should be TIFF-B with multi-page files supported. Images should be encoded as one TIFF strip per page. ** Images should be compressed using MMR when possible. Images may also be MH or MR compressed or uncompressed. If MH or MR compression is used, scan lines should be "byte-aligned". ** For maximum interoperability, image resolutions should either be 600, 400, or 300 dpi; or else be one of the standard Group 3 fax resolutions (98 or 196 dpi vertically and 204 dpi horizontally). Note that this specification is self contained and an implementation should be possible without recourse to the TIFF references, and that only the specific TIFF documents cited are relevant to this specification.
    [Show full text]
  • Network Working Group G. Malkin Request for Comments: 1325 Xylogics FYI: 4 A
    Network Working Group G. Malkin Request for Comments: 1325 Xylogics FYI: 4 A. Marine Obsoletes: RFC 1206 SRI May 1992 FYI on Questions and Answers Answers to Commonly asked "New Internet User" Questions Status of this Memo This memo provides information for the Internet community. It does not specify an Internet standard. Distribution of this memo is unlimited. Abstract This FYI RFC is one of two FYI's called, "Questions and Answers" (Q/A), produced by the User Services Working Group of the Internet Engineering Task Force (IETF). The goal is to document the most commonly asked questions and answers in the Internet. New Questions and Answers In addition to updating information contained in the previous version of this FYI RFC, the following new questions have been added: Questions About the Internet: How do I get a list of all the hosts on the Internet? Questions About Internet Documentation: What is the RFC-INFO service? What is an FYI? What is an STD? What is the Internet Monthly Report? Questions About Internet Organizations: What is the Internet Society? Questions About Internet Services: What is "archie"? How do I Connect to archie? Mailing Lists and Sending Mail How Do I Send Mail to Other Networks? User Services Working Group [Page 1] RFC 1325 FYI Q/A - for New Internet Users May 1992 Table of Contents 1. Introduction................................................. 2 2. Acknowledgements............................................. 3 3. Questions About the Internet................................. 3 4. Questions About TCP/IP....................................... 5 5. Questions About the Domain Name System....................... 6 6. Questions About Internet Documentation....................... 6 7. Questions about Internet Organizations and Contacts.........
    [Show full text]
  • Signposts in Cyberspace: the Domain Name System and Internet Navigation
    Prepublication Copy—Subject to Further Editorial Correction Signposts in Cyberspace: The Domain Name System and Internet Navigation Committee on Internet Navigation and the Domain Name System: Technical Alternatives and Policy Implications Computer Science and Telecommunications Board Division on Engineering and Physical Sciences NATIONAL ACADEMIES PRESS Washington, D.C. www.nap.edu Prepublication Copy—Subject to Further Editorial Correction THE NATIONAL ACADEMIES PRESS 500 Fifth Street, N.W. Washington, D.C. 20001 NOTICE: The project that is the subject of this report was approved by the Governing Board of the National Research Council, whose members are drawn from the councils of the National Academy of Sciences, the National Academy of Engineering, and the Institute of Medicine. The members of the committee responsible for the report were chosen for their special competences and with regard for appropriate balance. Support for this project was provided by the U.S. Department of Commerce and the National Science Foundation under Grant No. ANI-9909852 and by the National Research Council. Any opinions, findings, conclusions, or recommendations expressed in this publication are those of the authors and do not necessarily reflect the views of the National Science Foundation or the Commerce Department. International Standard Book Number Cover designed by Jennifer M. Bishop. Copies of this report are available from the National Academies Press, 500 Fifth Street, N.W., Lockbox 285, Washington, D.C. 20055, (800) 624-6242 or (202) 334-3313 in the Washington metropolitan area. Internet, http://www.nap.edu Copyright 2005 by the National Academy of Sciences. All rights reserved. Printed in the United States of America Prepublication Copy—Subject to Further Editorial Correction The National Academy of Sciences is a private, nonprofit, self-perpetuating society of distinguished scholars engaged in scientific and engineering research, dedicated to the furtherance of science and technology and to their use for the general welfare.
    [Show full text]
  • 5321 October 2008 Obsoletes: 2821 Updates: 1123 Category: Standards Track
    Network Working Group J. Klensin Request for Comments: 5321 October 2008 Obsoletes: 2821 Updates: 1123 Category: Standards Track Simple Mail Transfer Protocol Status of This Memo This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited. Abstract This document is a specification of the basic protocol for Internet electronic mail transport. It consolidates, updates, and clarifies several previous documents, making all or parts of most of them obsolete. It covers the SMTP extension mechanisms and best practices for the contemporary Internet, but does not provide details about particular extensions. Although SMTP was designed as a mail transport and delivery protocol, this specification also contains information that is important to its use as a "mail submission" protocol for "split-UA" (User Agent) mail reading systems and mobile environments. Klensin Standards Track [Page 1] RFC 5321 SMTP October 2008 Table of Contents 1. Introduction . 5 1.1. Transport of Electronic Mail . 5 1.2. History and Context for This Document . 5 1.3. Document Conventions . 6 2. The SMTP Model . 7 2.1. Basic Structure . 7 2.2. The Extension Model . 9 2.2.1. Background . 9 2.2.2. Definition and Registration of Extensions . 10 2.2.3. Special Issues with Extensions . 11 2.3. SMTP Terminology . 11 2.3.1. Mail Objects . 11 2.3.2. Senders and Receivers . 12 2.3.3.
    [Show full text]