| |
| RFC 1800 | Internet Official Protocol Standards |
| |
|
|
This memo describes the state of standardization of protocols used in the Internet as determined by the Internet Architecture Board (IAB). [STANDARDS-TRACK] |
|
| |
| RFC 1801 | MHS use of the X.500 Directory to support MHS Routing |
| |
| Authors: | S. Kille. |
| Date: | June 1995 |
| Formats: | txt json html |
| Status: | EXPERIMENTAL |
| DOI: | 10.17487/RFC 1801 |
|
The key problem in routing is to map from an O/R Address onto an MTA (next hop). This shall be an MTA which in some sense is "nearer" to the destination UA. This is done repeatedly until the message can be directly delivered to the recipient UA. This memo defines an Experimental Protocol for the Internet community. |
|
| |
| RFC 1802 | Introducing Project Long Bud: Internet Pilot Project for the Deployment of X.500 Directory Information in Support of X.400 Routing |
| |
| Authors: | H. Alvestrand, K. Jordan, S. Langlois, J. Romaguera. |
| Date: | June 1995 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 1802 |
|
The Internet X.400 community (i.e., GO-MHS) currently lacks a distributed mechanism providing dynamic updating and management of message routing information. The IETF MHS-DS Working Group has specified an approach for X.400 Message Handling Systems to perform message routing using OSI Directory Services. The MHS-DS approach has been successfully tested in a number of local environments.
This memo describes a proposed Internet Pilot Project that seeks to prove the MHS-DS approach on a larger scale. The results of this pilot will then be used to draw up recommendations for a global deployment. |
|
| |
| RFC 1803 | Recommendations for an X.500 Production Directory Service |
| |
| Authors: | R. Wright, A. Getchell, T. Howes, S. Sataluri, P. Yee, W. Yeong. |
| Date: | June 1995 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 1803 |
|
This document contains a set of basic recommendations for a country- level X.500 DSA. These recommendations can only be considered a starting point in the quest to create a global production qualityX.500 infrastructure. For there to be a true "production quality"X.500 infrastructure more work must be done, including a transition from the 1988 X.500 (plus some Internet extensions) to the 1993 X.500 standard (including the '93 replication and knowledge model). This document does not discuss this transition. |
|
| |
| RFC 1804 | Schema Publishing in X.500 Directory |
| |
| Authors: | G. Mansfield, P. Rajeev, S. Raghavan, T. Howes. |
| Date: | June 1995 |
| Formats: | txt json html |
| Status: | EXPERIMENTAL |
| DOI: | 10.17487/RFC 1804 |
|
The X.500 directory provides a powerful mechanism for storing and retrieving information about objects of interest. To interpret the information stored in the directory, the schema must be known to all the components of the directory. Presently, there are no means other than ftp to distribute schema information across the Internet. This is proving to be a severe constraint as the Directory is growing.This document presents a solution to the schema distribution problem using the existing mechanisms of the directory. A naming scheme for naming schema objects and a meta-schema for storing schema objects is presented. The procedures for fetching unknown schema from the directory at runtime are described. |
|
| |
| RFC 1805 | Location-Independent Data/Software Integrity Protocol |
| |
| Authors: | A. Rubin. |
| Date: | June 1995 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 1805 |
|
This memo describes a protocol for adding integrity assurance to files that are distributed across the Internet. This protocol is intended for the distribution of software, data, documents, and any other file that is subject to malicious modification. The protocol described here is intended to provide assurances of integrity and time. A trusted third party is required. |
|
| |
| RFC 1806 | Communicating Presentation Information in Internet Messages: The Content-Disposition Header |
| |
|
|
This memo provides a mechanism whereby messages conforming to the[RFC 1521] ("MIME") specification can convey presentational information. It specifies a new "Content-Disposition" header, optional and valid for any [RFC 1521] entity ("message" or "body part"). Two values for this header are described in this memo; one for the ordinary linear presentation of the body part, and another to facilitate the use of mail to transfer files. It is expected that more values will be defined in the future, and procedures are defined for extending this set of values.
This document is intended as an extension to [RFC 1521]. As such, the reader is assumed to be familiar with [RFC 1521], and [RFC 822]. The information presented herein supplements but does not replace that found in those documents. |
|
| |
| RFC 1807 | A Format for Bibliographic Records |
| |
|
|
This RFC defines a format for bibliographic records describing technical reports. This format is used by the Cornell UniversityDienst protocol and the Stanford University SIFT system. The original RFC (RFC 1357) was written by D. Cohen, ISI, July 1992.This is a revision of RFC 1357. New fields include handle, other_access, keyword, and withdraw. |
|
| |
| RFC 1808 | Relative Uniform Resource Locators |
| |
|
|
A Uniform Resource Locator (URL) is a compact representation of the location and access method for a resource available via the Internet.When embedded within a base document, a URL in its absolute form may contain a great deal of information which is already known from the context of that base document's retrieval, including the scheme, network location, and parts of the url-path. In situations where the base URL is well-defined and known to the parser (human or machine), it is useful to be able to embed URL references which inherit that context rather than re-specifying it in every instance. This document defines the syntax and semantics for such Relative UniformResource Locators. |
|
| |
| RFC 1809 | Using the Flow Label Field in IPv6 |
| |
| Authors: | C. Partridge. |
| Date: | June 1995 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 1809 |
|
The purpose of this memo is to distill various opinions and suggestions of the End-to-End Research Group regarding the handling of Flow Labels into a set of suggestions for IPv6. This memo is for information purposes only and is not one of the IPv6 specifications.Distribution of this memo is unlimited. |
|
| |
| RFC 1810 | Report on MD5 Performance |
| |
| Authors: | J. Touch. |
| Date: | June 1995 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 1810 |
|
MD5 is an authentication algorithm, which has been proposed as the default authentication option in IPv6. When enabled, the MD5 algorithm operates over the entire data packet, including header.This RFC addresses how fast MD5 can be implemented in software and hardware, and whether it supports currently available IP bandwidth.MD5 can be implemented in existing hardware technology at 256 Mbps, and in software at 87 Mbps. These rates cannot support current IP rates, e.g., 100 Mbps TCP and 130 Mbps UDP over ATM. If MD5 cannot support existing network bandwidth using existing technology, it will not scale as network speeds increase in the future. This RFC is intended to alert the IP community about the performance limitations of MD5, and to suggest that alternatives be considered for use in high speed IP implementations. |
|
| |
| RFC 1811 | U.S |
| |
| Authors: | Government Internet Domain Names. Federal Networking Council. |
| Date: | June 1995 |
| Formats: | txt json html |
| Obsoleted by: | RFC 1816 |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 1811 |
|
This document describes the registration policies for the top-level domain ".GOV". Thus far, Federal Agencies and their subsidiaries have registered without any guidance. This has resulted in multiple registrations for Federal Agencies and naming schemes that do not facilitate responsiveness to the public. This document fixes this by restricting registrations to coincide with the approved structure of the US government. The document cited, FIPS 95-1, provides a standard recognized structure into which domain registrations for top-level domains. The IANA requires that an organization/country apply for and get a 2 letter code from ISO/ITU (e.g., US for UnitedStates) for additional top-level registration.
As a side effect, this reduces the number of .GOV level registrations and reduces the workload on the Internic. |
|
| |
| RFC 1812 | Requirements for IP Version 4 Routers |
| |
|
|
This memo defines and discusses requirements for devices that perform the network layer forwarding function of the Internet protocol suite. [STANDARDS-TRACK] |
|
| |
| RFC 1813 | NFS Version 3 Protocol Specification |
| |
| Authors: | B. Callaghan, B. Pawlowski, P. Staubach. |
| Date: | June 1995 |
| Formats: | txt html json |
| Also: | RFC 1094 |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 1813 |
|
This paper describes the NFS version 3 protocol. This paper is provided so that people can write compatible implementations. |
|
| |
| RFC 1814 | Unique Addresses are Good |
| |
| Authors: | E. Gerich. |
| Date: | June 1995 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 1814 |
|
The IAB suggests that while RFC 1597 establishes reserved IP address space for the use of private networks which are isolated and will remain isolated from the Internet, any enterprise which anticipates external connectivity to the Internet should apply for a globally unique address from an Internet registry or service provider. |
|
| |
| RFC 1815 | Character Sets ISO-10646 and ISO-10646-J-1 |
| |
| Authors: | M. Ohta. |
| Date: | July 1995 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 1815 |
|
Though the ISO character set standard of ISO 10646 is specified reasonably well about European characters, it is not so useful in an fully internationalized environment.
For the practical use of ISO 10646, a lot of external profiling such as restriction of characters, restriction of combination of characters and addition of language information is necessary.
This memo provides information on such profiling, along with charset names to each profiled instance.
Though all the effort is done to make the resulting charset as useful10646 based charset as possible, the result is not so good. So, the charsets defined in this memo are only for reference purpose and its use for practical purpose is strongly discouraged. |
|
| |
| RFC 1816 | U.S |
| |
| Authors: | Government Internet Domain Names. Federal Networking Council. |
| Date: | August 1995 |
| Formats: | txt html json |
| Obsoletes: | RFC 1811 |
| Obsoleted by: | RFC 2146 |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 1816 |
|
This memo provides an update and clarification to RFC 1811. This document describes the registration policies for the top-level domain".GOV". Thus far, Federal Agencies and their subsidiaries have registered without any guidance. This has resulted in multiple registrations for Federal Agencies and naming schemes that do not facilitate responsiveness to the public. This document fixes this by restricting registrations to coincide with the approved structure of the US government. The document cited, FIPS 95-1, provides a standard recognized structure into which domain registrations for.GOV can be fit. This policy is exactly comparable to that for the top-level domains. The IANA requires that an organization/country apply for and get a 2 letter code from ISO/ITU (e.g., US for UnitedStates) for additional top-level registration.
As a side effect, this reduces the number of .GOV level registrations and reduces the workload on the Internic. |
|
| |
| RFC 1817 | CIDR and Classful Routing |
| |
| Authors: | Y. Rekhter. |
| Date: | August 1995 |
| Formats: | txt html json |
| Status: | HISTORIC |
| DOI: | 10.17487/RFC 1817 |
|
Classless Inter-Domain Routing (CIDR) is used in the Internet as the primary mechanism to improve scalability of the Internet routing system. This document represents the IAB's (Internet ArchitectureBoard) evaluation of the current and near term implications of CIDR on organizations that use Classful routing technology. |
|
| |
| RFC 1818 | Best Current Practices |
| |
| Authors: | J. Postel, T. Li, Y. Rekhter. |
| Date: | August 1995 |
| Formats: | txt json html |
| Status: | HISTORIC |
| DOI: | 10.17487/RFC 1818 |
|
This document describes a new series of documents which describe best current practices for the Internet community. Documents in this series carry the endorsement of the Internet Engineering SteeringGroup (IESG). |
|
| |
| RFC 1819 | Internet Stream Protocol Version 2 (ST2) Protocol Specification - Version ST2+ |
| |
| Authors: | L. Delgrossi, Ed., L. Berger, Ed.. |
| Date: | August 1995 |
| Formats: | txt json html |
| Obsoletes: | RFC 1190, IEN119 |
| Status: | HISTORIC |
| DOI: | 10.17487/RFC 1819 |
|
This memo contains a revised specification of the Internet STreamProtocol Version 2 (ST2). ST2 is an experimental resource reservation protocol intended to provide end-to-end real-time guarantees over an internet. It allows applications to build multi-destination simplex data streams with a desired quality of service. The revised version of ST2 specified in this memo is called ST2+.
This specification is a product of the STream Protocol Working Group of the Internet Engineering Task Force. |
|
| |
| RFC 1820 | Multimedia E-mail (MIME) User Agent Checklist |
| |
|
|
This document presents a checklist to facilitate evaluation of MIME capable User Agents. Access to a MIME test-responder, that generates test-messages is described. |
|
| |
| RFC 1821 | Integration of Real-time Services in an IP-ATM Network Architecture |
| |
| Authors: | M. Borden, E. Crawley, B. Davie, S. Batsell. |
| Date: | August 1995 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 1821 |
|
The IETF is currently developing an integrated service model which is designed to support real-time services on the Internet.Concurrently, the ATM Forum is developing Asynchronous Transfer Mode networking which similarly provides real-time networking support. The use of ATM in the Internet as a link layer protocol is already occurring, and both the IETF and the ATM Forum are producing specifications for IP over ATM. The purpose of this paper is to provide a clear statement of what issues need to be addressed in interfacing the IP integrated services environment with an ATM service environment so as to create a seamless interface between the two in support of end users desiring real-time networking services. |
|
| |
| RFC 1822 | A Grant of Rights to Use a Specific IBM patent with Photuris |
| |
| Authors: | J. Lowe. |
| Date: | August 1995 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 1822 |
|
This Request for Comments records a grant by IBM Corporation to permit the conditional free use of one of its patents. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind. |
|
| |
| RFC 1823 | The LDAP Application Program Interface |
| |
| Authors: | T. Howes, M. Smith. |
| Date: | August 1995 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 1823 |
|
This document defines a C language application program interface to the lightweight directory access protocol (LDAP). This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind. |
|
| |
| RFC 1824 | The Exponential Security System TESS: An Identity-Based Cryptographic Protocol for Authenticated Key-Exchange (E.I.S.S.-Report 1995/4) |
| |
| Authors: | H. Danisch. |
| Date: | August 1995 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 1824 |
|
This informational RFC describes the basic mechanisms and functions of an identity based system for the secure authenticated exchange of cryptographic keys, the generation of signatures, and the authentic distribution of public keys. |
|
| |
| RFC 1825 | Security Architecture for the Internet Protocol |
| |
|
|
This memo describes the security mechanisms for IP version 4 (IPv4) and IP version 6 (IPv6) and the services that they provide. [STANDARDS- TRACK] |
|
| |
| RFC 1826 | IP Authentication Header |
| |
|
|
This document describes a mechanism for providing cryptographic authentication for IPv4 and IPv6 datagrams. [STANDARDS-TRACK] |
|
| |
| RFC 1827 | IP Encapsulating Security Payload (ESP) |
| |
|
|
This document describes the IP Encapsulating Security Payload (ESP). ESP is a mechanism for providing integrity and confidentiality to IP datagrams. [STANDARDS-TRACK] |
|
| |
| RFC 1828 | IP Authentication using Keyed MD5 |
| |
| Authors: | P. Metzger, W. Simpson. |
| Date: | August 1995 |
| Formats: | txt json html |
| Status: | HISTORIC |
| DOI: | 10.17487/RFC 1828 |
|
This document describes the use of keyed MD5 with the IPAuthentication Header. |
|
| |
| RFC 1829 | The ESP DES-CBC Transform |
| |
| Authors: | P. Karn, P. Metzger, W. Simpson. |
| Date: | August 1995 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 1829 |
|
This document describes the DES-CBC security transform for the IPEncapsulating Security Payload (ESP). |
|
| |
| RFC 1830 | SMTP Service Extensions for Transmission of Large and Binary MIME Messages |
| |
|
|
This memo defines two extensions to the SMTP service. The first service enables a SMTP client and server to negotiate the use of an alternate DATA command "BDAT" for efficiently sending large MIME messages. The second extension takes advantage of the BDAT command to permit the negotiated sending of unencoded binary data. This memo defines an Experimental Protocol for the Internet community. |
|
| |
| RFC 1831 | RPC: Remote Procedure Call Protocol Specification Version 2 |
| |
|
|
This document describes the ONC Remote Procedure Call (ONC RPC Version 2) protocol as it is currently deployed and accepted. [STANDARDS-TRACK] |
|
| |
| RFC 1832 | XDR: External Data Representation Standard |
| |
|
|
This document describes the External Data Representation Standard (XDR) protocol as it is currently deployed and accepted. [STANDARDS-TRACK] |
|
| |
| RFC 1833 | Binding Protocols for ONC RPC Version 2 |
| |
|
|
This document describes the binding protocols used in conjunction with the ONC Remote Procedure Call (ONC RPC Version 2) protocols. [STANDARDS-TRACK] |
|
| |
| RFC 1834 | Whois and Network Information Lookup Service, Whois++ |
| |
| Authors: | J. Gargano, K. Weiss. |
| Date: | August 1995 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 1834 |
|
This memo describes new features for WHOIS. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind. |
|
| |
| RFC 1835 | Architecture of the WHOIS++ service |
| |
| Authors: | P. Deutsch, R. Schoultz, P. Faltstrom, C. Weider. |
| Date: | August 1995 |
| Formats: | txt json html |
| Status: | HISTORIC |
| DOI: | 10.17487/RFC 1835 |
|
This document describes WHOIS++, an extension to the trivial WHOIS service described in RFC 954 to permit WHOIS-like servers to make available more structured information to the Internet. We describe an extension to the simple WHOIS data model and query protocol and a companion extensible, distributed indexing service. A number of options have also been added such as the use of multiple languages and character sets, more advanced search expressions, structured data and a number of other useful features. An optional authentication mechanism for protecting all or part of the associated WHOIS++ information database from unauthorized access is also described. |
|
| |
| RFC 1836 | Representing the O/R Address hierarchy in the X.500 Directory Information Tree |
| |
|
|
This document defines a representation of the O/R Address hierarchy in the Directory Information Tree [6, 1]. This is useful for a range of purposes, including: |
|
| |
| RFC 1837 | Representing Tables and Subtrees in the X.500 Directory |
| |
|
|
This document defines techniques for representing two types of information mapping in the OSI Directory [1].
1. Mapping from a key to a value (or set of values), as might be done in a table lookup.
2. Mapping from a distinguished name to an associated value (or values), where the values are not defined by the owner of the entry. This is achieved by use of a directory subtree.
These techniques were developed for supporting MHS use of Directory[2], but are specified separately as they have more general applicability. |
|
| |
| RFC 1838 | Use of the X.500 Directory to support mapping between X.400 and RFC 822 Addresses |
| |
|
|
This document defines how to use directory to support the mapping between X.400 O/R Addresses and mailboxes defined in RFC 1327 [2]. |
|
| |
| RFC 1841 | PPP Network Control Protocol for LAN Extension |
| |
| Authors: | J. Chapman, D. Coli, A. Harvey, B. Jensen, K. Rowett. |
| Date: | September 1995 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 1841 |
|
Telecommunications infrastructure is improving to offer higher bandwidth connections at lower cost. Access to the network is changing from modems to more intelligent devices. This informationalRFC discusses a PPP Network Control Protocol for one such intelligent device. The protocol is the LAN extension interface protocol. |
|
| |
| RFC 1842 | ASCII Printable Characters-Based Chinese Character Encoding for Internet Messages |
| |
| Authors: | Y. Wei, Y. Zhang, J. Li, J. Ding, Y. Jiang. |
| Date: | August 1995 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 1842 |
|
This document describes the encoding used in electronic mail [RFC822] and network news [RFC1036] messages over the Internet. The 7-bit representation of GB 2312 Chinese text was specified by Fung Fung Lee of Stanford University [Lee89] and implemented in various software packages under different platforms (see appendix for a partial list of the available software packages that support this encoding method). It is further tested and used in the usenet newsgroups alt.chinese.text and chinese.* as well as various other network forums with considerable success. Future extensions of this encoding method can accommodate additional GB character sets and other east asian language character sets [Wei94].
The name given to this encoding is "HZ-GB-2312", which is intended to be used in the "charset" parameter field of MIME headers (see [MIME1] and [MIME2]). |
|
| |
| RFC 1843 | HZ - A Data Format for Exchanging Files of Arbitrarily Mixed Chinese and ASCII characters |
| |
| Authors: | F. Lee. |
| Date: | August 1995 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 1843 |
|
The content of this memo is identical to an article of the same title written by the author on September 4, 1989. In this memo, GB stands for GB2312-80. Note that the title is kept only for historical reasons. HZ has been widely used for purposes other than "file exchange". |
|
| |
| RFC 1844 | Multimedia E-mail (MIME) User Agent Checklist |
| |
|
|
This document presents a checklist to facilitate evaluation of MIME capable User Agents. Access to a MIME test-responder, that generates test-messages is described. |
|
| |
| RFC 1845 | SMTP Service Extension for Checkpoint/Restart |
| |
| Authors: | D. Crocker, N. Freed, A. Cargille. |
| Date: | September 1995 |
| Formats: | txt html json |
| Status: | EXPERIMENTAL |
| DOI: | 10.17487/RFC 1845 |
|
This memo defines an extension to the SMTP service whereby an interrupted SMTP transaction can be restarted at a later time without having to repeat all of the commands and message content sent prior to the interruption. |
|
| |
| RFC 1846 | SMTP 521 Reply Code |
| |
|
|
This memo defines a new Simple Mail Transfer Protocol (SMTP) [1] reply code, 521, which one may use to indicate that an Internet host does not accept incoming mail. |
|
| |
| RFC 1847 | Security Multiparts for MIME: Multipart/Signed and Multipart/Encrypted |
| |
| Authors: | J. Galvin, S. Murphy, S. Crocker, N. Freed. |
| Date: | October 1995 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 1847 |
|
This document defines a framework within which security services may be applied to MIME body parts. MIME, an acronym for "MultipurposeInternet Mail Extensions", defines the format of the contents ofInternet mail messages and provides for multi-part textual and non- textual message bodies. The new content types are subtypes of multipart: signed and encrypted. Each will contain two body parts: one for the protected data and one for the control information necessary to remove the protection. The type and contents of the control information body parts are determined by the value of the protocol parameter of the enclosing multipart/signed or multipart/encrypted content type, which is required to be present. |
|
| |
| RFC 1848 | MIME Object Security Services |
| |
| Authors: | S. Crocker, N. Freed, J. Galvin, S. Murphy. |
| Date: | October 1995 |
| Formats: | txt html json |
| Status: | HISTORIC |
| DOI: | 10.17487/RFC 1848 |
|
This document defines MIME Object Security Services (MOSS), a protocol that uses the multipart/signed and multipart/encrypted framework [7] to apply digital signature and encryption services toMIME objects. The services are offered through the use of end-to-end cryptography between an originator and a recipient at the application layer. Asymmetric (public key) cryptography is used in support of the digital signature service and encryption key management.Symmetric (secret key) cryptography is used in support of the encryption service. The procedures are intended to be compatible with a wide range of public key management approaches, including both ad hoc and certificate-based schemes. Mechanisms are provided to support many public key management approaches. |
|
| |
| RFC 1849 | "Son of 1036": News Article Format and Transmission |
| |
|
|
By the early 1990s, it had become clear that RFC 1036, then the specification for the Interchange of USENET Messages, was badly in need of repair. This "Internet-Draft-to-be", though never formally published at that time, was widely circulated and became the de facto standard for implementors of News Servers and User Agents, rapidly acquiring the nickname "Son of 1036". Indeed, under that name, it could fairly be described as the best-known Internet Draft (n)ever published, and it formed the starting point for the recently adoptedProposed Standards for Netnews.
It is being published now in order to provide the historical background out of which those standards have grown. Present-day implementors should be aware that it is NOT NOW APPROPRIATE for use in current implementations. |
|
| |
| RFC 1850 | OSPF Version 2 Management Information Base |
| |
|
|
This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in TCP/IP-based internets.In particular, it defines objects for managing the Open Shortest PathFirst Routing Protocol. |
|
| |
| RFC 1851 | The ESP Triple DES Transform |
| |
| Authors: | P. Karn, P. Metzger, W. Simpson. |
| Date: | September 1995 |
| Formats: | txt html json |
| Status: | EXPERIMENTAL |
| DOI: | 10.17487/RFC 1851 |
|
This document describes the Triple DES-CBC security transform for theIP Encapsulating Security Payload (ESP). |
|
| |
| RFC 1852 | IP Authentication using Keyed SHA |
| |
| Authors: | P. Metzger, W. Simpson. |
| Date: | September 1995 |
| Formats: | txt json html |
| Obsoleted by: | RFC 2841 |
| Status: | EXPERIMENTAL |
| DOI: | 10.17487/RFC 1852 |
|
This document describes the use of keyed SHA with the IPAuthentication Header. |
|
| |
| RFC 1853 | IP in IP Tunneling |
| |
| Authors: | W. Simpson. |
| Date: | October 1995 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 1853 |
|
This document discusses implementation techniques for using IPProtocol/Payload number 4 Encapsulation for tunneling with IPSecurity and other protocols. |
|
| |
| RFC 1854 | SMTP Service Extension for Command Pipelining |
| |
|
|
This memo defines an extension to the SMTP service whereby a server can indicate the extent of its ability to accept multiple commands in a single TCP send operation. Using a single TCP send operation for multiple commands can improve SMTP performance significantly. |
|
| |
| RFC 1855 | Netiquette Guidelines |
| |
|
|
This document provides a minimum set of guidelines for NetworkEtiquette (Netiquette) which organizations may take and adapt for their own use. As such, it is deliberately written in a bulleted format to make adaptation easier and to make any particular item easy(or easier) to find. It also functions as a minimum set of guidelines for individuals, both users and administrators. This memo is the product of the Responsible Use of the Network (RUN) WorkingGroup of the IETF. |
|
| |
| RFC 1856 | The Opstat Client-Server Model for Statistics Retrieval |
| |
| Authors: | H. Clark. |
| Date: | September 1995 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 1856 |
|
Network administrators gather data related to the performance, utilization, usability and growth of their data network. The amount of raw data gathered is usually quite large, typically ranging somewhere between several megabytes to several gigabytes of data each month. Few (if any) tools exist today for the sharing of that raw data among network operators or between a network service provider(NSP) and its customers. This document defines a model and protocol for a set of tools which could be used by NSPs and Network OperationCenters (NOCs) to share data among themselves and with customers. |
|
| |
| RFC 1857 | A Model for Common Operational Statistics |
| |
|
|
This memo describes a model for operational statistics in theInternet. It gives recommendations for metrics, measurements, polling periods and presentation formats and defines a format for the exchange of operational statistics. |
|
| |
| RFC 1858 | Security Considerations for IP Fragment Filtering |
| |
| Authors: | G. Ziemba, D. Reed, P. Traina. |
| Date: | October 1995 |
| Formats: | txt html json |
| Updated by: | RFC 3128 |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 1858 |
|
IP fragmentation can be used to disguise TCP packets from IP filters used in routers and hosts. This document describes two methods of attack as well as remedies to prevent them. |
|
| |
| RFC 1859 | ISO Transport Class 2 Non-use of Explicit Flow Control over TCP RFC1006 extension |
| |
| Authors: | Y. Pouffary. |
| Date: | October 1995 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 1859 |
|
This document is an extension to STD35, RFC1006, a standard for the Internet community. The document does not duplicate the protocol definitions contained in RFC1006 and in International Standard ISO 8073. It supplements that information with the description of how to implement ISO Transport Class 2 Non-use of Explicit Flow Control on top of TCP. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind. |
|
| |
| RFC 1860 | Variable Length Subnet Table For IPv4 |
| |
| Authors: | T. Pummill, B. Manning. |
| Date: | October 1995 |
| Formats: | txt html json |
| Obsoleted by: | RFC 1878 |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 1860 |
|
This document itemizes the potential values for IPv4 subnets.Additional information is provided for Hex and Decmial values, classfull equivalents, and number of addresses available within the indicated block. We appreciate inputs from Bruce Pinsky (cisco) andDaniel Karrenberg (RIPE). |
|
| |
| RFC 1861 | Simple Network Paging Protocol - Version 3 -Two-Way Enhanced |
| |
|
|
This RFC suggests a simple way for delivering wireless messages, both one and two-way, to appropriate receiving devices. In its simplest form, SNPP provides a simple way to implement a "shim" between theInternet and a TAP/IXO paging terminal. In its level 3 form, it provides an easy-to-use (and build) method for communicating and receiving end-to-end acknowledgments and replies from two-way messaging devices (such as ReFLEX units).
Gateways supporting this protocol, as well as SMTP, have been in use for well over a year at several commercial paging companies, and private businesses. Client software supporting this protocol has become widespread, and is being integrated into many of the new paging and messaging products being built. In addition to commercial software, email filters and SNPP client software for Unix and Windows(WikiPage) are available at no cost. Please contact the author for more information.
Earlier versions of this specification were reviewed by IESG members and the "822 Extensions" Working Group. They preferred an alternate strategy, as discussed under "Relationship to Other IETF Work", below. |
|
| |
| RFC 1862 | Report of the IAB Workshop on Internet Information Infrastructure, October 12-14, 1994 |
| |
| Authors: | M. McCahill, J. Romkey, M. Schwartz, K. Sollins, T. Verschuren, C. Weider. |
| Date: | November 1995 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 1862 |
|
This document is a report on an Internet architecture workshop, initiated by the IAB and held at MCI on October 12-14, 1994. This workshop generally focused on aspects of the information infrastructure on the Internet. |
|
| |
| RFC 1863 | A BGP/IDRP Route Server alternative to a full mesh routing |
| |
|
|
This document describes the use and detailed design of Route Servers for dissemination of routing information among BGP/IDRP speaking routers.
The intention of the proposed technique is to reduce overhead and management complexity of maintaining numerous direct BGP/IDRP sessions which otherwise might be required or desired among routers within a single routing domain as well as among routers in different domains that are connected to a common switched fabric (e.g. an ATM cloud). |
|
| |
| RFC 1864 | The Content-MD5 Header Field |
| |
|
|
This memo specifies an optional header field, Content-MD5, for use with MIME-conformant messages. |
|
| |
| RFC 1865 | EDI Meets the Internet Frequently Asked Questions about Electronic Data Interchange (EDI) on the Internet |
| |
| Authors: | W. Houser, J. Griffin, C. Hage. |
| Date: | January 1996 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 1865 |
|
This memo is targeted towards the EDI community that is unfamiliar with the Internet, including EDI software developers, users, and service providers. The memo introduces the Internet and assumes a basic knowledge of EDI. |
|
| |
| RFC 1866 | Hypertext Markup Language - 2.0 |
| |
| Authors: | T. Berners-Lee, D. Connolly. |
| Date: | November 1995 |
| Formats: | txt json html |
| Obsoleted by: | RFC 2854 |
| Status: | HISTORIC |
| DOI: | 10.17487/RFC 1866 |
|
The Hypertext Markup Language (HTML) is a simple markup language used to create hypertext documents that are platform independent. HTML documents are SGML documents with generic semantics that are appropriate for representing information from a wide range of domains. HTML markup can represent hypertext news, mail, documentation, and hypermedia; menus of options; database query results; simple structured documents with in-lined graphics; and hypertext views of existing bodies of information.
HTML has been in use by the World Wide Web (WWW) global information initiative since 1990. This specification roughly corresponds to the capabilities of HTML in common use prior to June 1994. HTML is an application of ISO Standard 8879:1986 Information Processing Text andOffice Systems; Standard Generalized Markup Language (SGML).
The "text/html" Internet Media Type (RFC 1590) and MIME Content Type(RFC 1521) is defined by this specification. |
|
| |
| RFC 1867 | Form-based File Upload in HTML |
| |
|
|
Since file-upload is a feature that will benefit many applications, this proposes an extension to HTML to allow information providers to express file upload requests uniformly, and a MIME compatible representation for file upload responses. This memo defines an Experimental Protocol for the Internet community. |
|
| |
| RFC 1868 | ARP Extension - UNARP |
| |
| Authors: | G. Malkin. |
| Date: | November 1995 |
| Formats: | txt html json |
| Status: | EXPERIMENTAL |
| DOI: | 10.17487/RFC 1868 |
|
The Address Resolution Protocol allows an IP node to determine the hardware (datalink) address of a neighboring node on a broadcast network. The protocol depends on timers to age away old ARP entries.This document specifies a trivial modification to the ARP mechanism, not the packet format, which allows a node to announce that it is leaving the network and that all other nodes should modify their ARP tables accordingly. |
|
| |
| RFC 1869 | SMTP Service Extensions |
| |
|
|
This memo defines a framework for extending the SMTP service by defining a means whereby a server SMTP can inform a client SMTP as to the service extensions it supports. [STANDARDS-TRACK] |
|
| |
| RFC 1870 | SMTP Service Extension for Message Size Declaration |
| |
|
|
This memo defines an extension to the SMTP service whereby an SMTP client and server may interact to give the server an opportunity to decline to accept a message (perhaps temporarily) based on the client's estimate of the message size. [STANDARDS-TRACK] |
|
| |
| RFC 1871 | Addendum to RFC 1602 -- Variance Procedure |
| |
|
|
This document describes a modification to the IETF procedures to allow an escape from a situation where the existing procedures are not working or do not seem to apply. This is a modification to the procedures of RFC 1602 and 1603. |
|
| |
| RFC 1872 | The MIME Multipart/Related Content-type |
| |
|
|
The Multipart/Related content-type provides a common mechanism for representing objects that are aggregates of related MIME body parts.This document defines the Multipart/Related content-type and provides examples of its use. |
|
| |
| RFC 1873 | Message/External-Body Content-ID Access Type |
| |
| Authors: | E. Levinson, J. Clark. |
| Date: | December 1995 |
| Formats: | txt json html |
| Status: | EXPERIMENTAL |
| DOI: | 10.17487/RFC 1873 |
|
When using MIME [MIME] to encapsulate a structured object that consist of many elements, for example an SGML [SGML] document, a single element may occur several times. An encapsulation normally maps each of the structured objects elements to a MIME entity. It is useful to include elements that occur multiple time exactly once. To accomplish that and to preserve the object structure it is desirable to unambiguously refer to another body part of the same message.
The existing MIME Content-Type Message/External-Body access-types allow a MIME entity (body-part) to refer to an object that is not in the message by specifying how to access that object. The Content-ID access method described in this document provides the capability to refer to an object within the message. |
|
| |
| RFC 1874 | SGML Media Types |
| |
| Authors: | E. Levinson. |
| Date: | December 1995 |
| Formats: | txt html json |
| Status: | EXPERIMENTAL |
| DOI: | 10.17487/RFC 1874 |
|
This document proposes new media sub-types of Text/SGML andApplication/SGML. These media types can be used in the exchange ofSGML documents and their entities. Specific details for the exchange or encapsulation of groups of related SGML entities using MIME are currently being considered by the mimesgml Working Group <sgml- internet@ebt.com&rt;. |
|
| |
| RFC 1875 | UNINETT PCA Policy Statements |
| |
| Authors: | N. Berge. |
| Date: | December 1995 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 1875 |
|
This document provides information about policy statements submitted by the UNINETT Policy Certification Authority (UNINETT PCA). This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind. |
|
| |
| RFC 1876 | A Means for Expressing Location Information in the Domain Name System |
| |
|
|
This memo defines a new DNS RR type for experimental purposes. This RFC describes a mechanism to allow the DNS to carry location information about hosts, networks, and subnets. This memo defines an Experimental Protocol for the Internet community. |
|
| |
| RFC 1877 | PPP Internet Protocol Control Protocol Extensions for Name Server Addresses |
| |
| Authors: | S. Cobb. |
| Date: | December 1995 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 1877 |
|
The Point-to-Point Protocol (PPP) [1] provides a standard method for transporting multi-protocol datagrams over point-to-point links. PPP defines an extensible Link Control Protocol and a family of NetworkControl Protocols (NCPs) for establishing and configuring different network-layer protocols.
This document extends the NCP for establishing and configuring theInternet Protocol over PPP [2], defining the negotiation of primary and secondary Domain Name System (DNS) [3] and NetBIOS Name Server(NBNS) [4] addresses. |
|
| |
| RFC 1878 | Variable Length Subnet Table For IPv4 |
| |
|
|
This memo clarifies issues surrounding subnetting IP networks by providing a standard subnet table. This table includes subnetting for Class A, B, and C networks, as well as Network IDs, host ranges and IP broadcast addresses with emphasis on Class C subnets.
This memo is intended as an informational companion to Subneting RFC[1] and the Hosts Requirements RFC [2]. |
|
| |
| RFC 1879 | Class A Subnet Experiment Results and Recommendations |
| |
| Authors: | B. Manning, Ed.. |
| Date: | January 1996 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 1879 |
|
This memo documents some experiences with the RFC 1797 [1] subnet A experiment (performed by the Net39 Test Group (see credits)) and provides a number of recommendations on future direction for both the Internet Registries and the Operations community. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind. |
|
| |
| RFC 1880 | Internet Official Protocol Standards |
| |
|
|
This memo describes the state of standardization of protocols used in the Internet as determined by the Internet Architecture Board (IAB). [STANDARDS-TRACK] |
|
| |
| RFC 1881 | IPv6 Address Allocation Management |
| |
| Authors: | IAB, IESG. |
| Date: | December 1995 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 1881 |
|
The IPv6 address space will be managed by the IANA for the good of the Internet community, with advice from the IAB and the IESG, by delegation to the regional registries. |
|
| |
| RFC 1882 | The 12-Days of Technology Before Christmas |
| |
| Authors: | B. Hancock. |
| Date: | December 1995 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 1882 |
|
This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind. |
|
| |
| RFC 1883 | Internet Protocol, Version 6 (IPv6) Specification |
| |
| Authors: | S. Deering, R. Hinden. |
| Date: | December 1995 |
| Formats: | txt json html |
| Obsoleted by: | RFC 2460 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 1883 |
|
This document specifies version 6 of the Internet Protocol (IPv6), also sometimes referred to as IP Next Generation or IPng. |
|
| |
| RFC 1884 | IP Version 6 Addressing Architecture |
| |
| Authors: | R. Hinden, Ed., S. Deering, Ed.. |
| Date: | December 1995 |
| Formats: | txt html json |
| Obsoleted by: | RFC 2373 |
| Status: | HISTORIC |
| DOI: | 10.17487/RFC 1884 |
|
This specification defines the addressing architecture of the IPVersion 6 protocol [IPV6]. The document includes the IPv6 addressing model, text representations of IPv6 addresses, definition of IPv6 unicast addresses, anycast addresses, and multicast addresses, and anIPv6 nodes required addresses. |
|
| |
| RFC 1885 | Internet Control Message Protocol (ICMPv6) for the Internet Protocol Version 6 (IPv6) |
| |
| Authors: | A. Conta, S. Deering. |
| Date: | December 1995 |
| Formats: | txt html json |
| Obsoleted by: | RFC 2463 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 1885 |
|
This document specifies a set of Internet Control Message Protocol(ICMP) messages for use with version 6 of the Internet Protocol(IPv6). The Internet Group Management Protocol (IGMP) messages specified in STD 5, RFC 1112 have been merged into ICMP, for IPv6, and are included in this document. |
|
| |
| RFC 1886 | DNS Extensions to support IP version 6 |
| |
|
|
This document defines the changes that need to be made to the DomainName System to support hosts running IP version 6 (IPv6). The changes include a new resource record type to store an IPv6 address, a new domain to support lookups based on an IPv6 address, and updated definitions of existing query types that return Internet addresses as part of additional section processing. The extensions are designed to be compatible with existing applications and, in particular, DNS implementations themselves. |
|
| |
| RFC 1887 | An Architecture for IPv6 Unicast Address Allocation |
| |
| Authors: | Y. Rekhter, Ed., T. Li, Ed.. |
| Date: | December 1995 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 1887 |
|
This document provides an architecture for allocating IPv6 [1] unicast addresses in the Internet. The overall IPv6 addressing architecture is defined in [2]. This document does not go into the details of an addressing plan. |
|
| |
| RFC 1888 | OSI NSAPs and IPv6 |
| |
| Authors: | J. Bound, B. Carpenter, D. Harrington, J. Houldsworth, A. Lloyd. |
| Date: | August 1996 |
| Formats: | txt html json |
| Obsoleted by: | RFC 4048 |
| Updated by: | RFC 4548 |
| Status: | HISTORIC |
| DOI: | 10.17487/RFC 1888 |
|
This document recommends that network implementors who have planned or deployed an OSI NSAP addressing plan, and who wish to deploy or transition to IPv6, should redesign a native IPv6 addressing plan to meet their needs. However, it also defines a set of mechanisms for the support of OSI NSAP addressing in an IPv6 network. These mechanisms are the ones that MUST be used if such support is required. This document also defines a mapping of IPv6 addresses within the OSI address format, should this be required. |
|
| |
| RFC 1889 | RTP: A Transport Protocol for Real-Time Applications |
| |
| Authors: | Audio-Video Transport Working Group, H. Schulzrinne, S. Casner, R. Frederick, V. Jacobson. |
| Date: | January 1996 |
| Formats: | txt html json |
| Obsoleted by: | RFC 3550 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 1889 |
|
This memorandum describes RTP, the real-time transport protocol. RTP provides end-to-end network transport functions suitable for applications transmitting real-time data, such as audio, video or simulation data, over multicast or unicast network services. RTP does not address resource reservation and does not guarantee quality-of- service for real-time services. The data transport is augmented by a control protocol (RTCP) to allow monitoring of the data delivery in a manner scalable to large multicast networks, and to provide minimal control and identification functionality. RTP and RTCP are designed to be independent of the underlying transport and network layers. The protocol supports the use of RTP-level translators and mixers. |
|
| |
| RFC 1890 | RTP Profile for Audio and Video Conferences with Minimal Control |
| |
| Authors: | Audio-Video Transport Working Group, H. Schulzrinne. |
| Date: | January 1996 |
| Formats: | txt html json |
| Obsoleted by: | RFC 3551 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 1890 |
|
This memo describes a profile for the use of the real-time transport protocol (RTP), version 2, and the associated control protocol, RTCP, within audio and video multiparticipant conferences with minimal control. It provides interpretations of generic fields within the RTP specification suitable for audio and video conferences. In particular, this document defines a set of default mappings from payload type numbers to encodings.
The document also describes how audio and video data may be carried within RTP. It defines a set of standard encodings and their names when used within RTP. However, the encoding definitions are independent of the particular transport mechanism used. The descriptions provide pointers to reference implementations and the detailed standards. This document is meant as an aid for implementors of audio, video and other real-time multimedia applications. |
|
| |
| RFC 1891 | SMTP Service Extension for Delivery Status Notifications |
| |
|
|
This memo defines an extension to the SMTP service, which allows an SMTP client to specify (a) that delivery status notifications (DSNs) should be generated under certain conditions, (b) whether such notifications should return the contents of the message, and (c) additional information, to be returned with a DSN, that allows the sender to identify both the recipient(s) for which the DSN was issued, and the transaction in which the original message was sent. [STANDARDS-TRACK] |
|
| |
| RFC 1892 | The Multipart/Report Content Type for the Reporting of Mail System Administrative Messages |
| |
|
|
The Multipart/Report MIME content-type is a general "family" or "container" type for electronic mail reports of any kind. Although this memo defines only the use of the Multipart/Report content-type with respect to delivery status reports, mail processing programs will benefit if a single content-type is used to for all kinds of reports. [STANDARDS-TRACK] |
|
| |
| RFC 1893 | Enhanced Mail System Status Codes |
| |
|
|
There currently is not a standard mechanism for the reporting of mail system errors except for the limited set offered by SMTP and the system specific text descriptions sent in mail messages. There is a pressing need for a rich machine readable status code for use in delivery status notifications [DSN]. This document proposes a new set of status codes for this purpose. [STANDARDS-TRACK] |
|
| |
| RFC 1894 | An Extensible Message Format for Delivery Status Notifications |
| |
|
|
This memo defines a MIME content-type that may be used by a message transfer agent (MTA) or electronic mail gateway to report the result of an attempt to deliver a message to one or more recipients. This content-type is intended as a machine-processable replacement for the various types of delivery status notifications currently used inInternet electronic mail.
Because many messages are sent between the Internet and other messaging systems (such as X.400 or the so-called "LAN-based" systems), the DSN protocol is designed to be useful in a multi- protocol messaging environment. To this end, the protocol described in this memo provides for the carriage of "foreign" addresses and error codes, in addition to those normally used in Internet mail.Additional attributes may also be defined to support "tunneling" of foreign notifications through Internet mail.
Any questions, comments, and reports of defects or ambiguities in this specification may be sent to the mailing list for the NOTARY working group of the IETF, using the address<notifications@cs.utk.edu&rt;. Requests to subscribe to the mailing list should be addressed to <notifications-request@cs.utk.edu&rt;.Implementors of this specification are encouraged to subscribe to the mailing list, so that they will quickly be informed of any problems which might hinder interoperability.
NOTE: This document is a Proposed Standard. If and when this protocol is submitted for Draft Standard status, any normative text(phrases containing SHOULD, SHOULD NOT, MUST, MUST NOT, or MAY) in this document will be re-evaluated in light of implementation experience, and are thus subject to change. |
|
| |
| RFC 1895 | The Application/CALS-1840 Content-type |
| |
| Authors: | E. Levinson. |
| Date: | February 1996 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 1895 |
|
This memorandum provides guidelines for using the United StatesDepartment of Defense Military Standard MIL-STD-1840, "AutomatedInterchange of Technical Information," with the Internet electronic mail standards, RFC 822 and RFC 1521. Electronic mail provides a more convenient mechanism that delivery via physical media for certain types and quantities of data. Software already exists to support data exchanges based on MIL-STD-1840 and it can continue to be used in conjunction with electronic mail exchanges defined in this document. This document defines a new media type and a MIME message structure for exchanging data in conformance with MIL-STD-1840. |
|
| |
| RFC 1896 | The text/enriched MIME Content-type |
| |
|
|
MIME [RFC-1521] defines a format and general framework for the representation of a wide variety of data types in Internet mail. This document defines one particular type of MIME data, the text/enrichedMIME type. The text/enriched MIME type is intended to facilitate the wider interoperation of simple enriched text across a wide variety of hardware and software platforms. This document is only a minor revision to the text/enriched MIME type that was first described in[RFC-1523] and [RFC-1563], and is only intended to be used in the short term until other MIME types for text formatting in Internet mail are developed and deployed. |
|
| |
| RFC 1897 | IPv6 Testing Address Allocation |
| |
|
|
This document describes an allocation plan for IPv6 addresses to be used in testing IPv6 prototype software. This document specifies an Experimental protocol for the Internet community. |
|
| |
| RFC 1898 | CyberCash Credit Card Protocol Version 0.8 |
| |
| Authors: | D. Eastlake 3rd, B. Boesch, S. Crocker, M. Yesil. |
| Date: | February 1996 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 1898 |
|
CyberCash is developing a general payments system for use over theInternet. The structure and communications protocols of version 0.8 are described. This version includes credit card payments only.Additional capabilities are planned for future versions.
This document covers only the current CyberCash system which is one of the few operational systems in the rapidly evolving area ofInternet payments. CyberCash is committed to the further development of its system and to cooperation with the Internet Engineering TaskForce and other standards organizations. |
|
| |
| RFC 1899 | Request for Comments Summary RFC Numbers 1800-1899 |
| |
| Authors: | J. Elliott. |
| Date: | January 1997 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 1899 |
|
|
|
