|
|
|
RFC Home |
Full RFC Index |
Recent RFCs |
RFC Standards |
Best Current Practice |
RFC Errata |
1 April RFC |
|
|
||||||
| RFC 2301 |
 File Format for Internet Fax
|
|
Summary Publication date: Mar 1998 This document describes the TIFF (Tag Image File Format) representation of image data specified by the ITU-T Recommendations for black-and-white and color facsimile. This file format specification is commonly known as TIFF-FX. It formally defines minimal, extended and lossless JBIG modes (Profiles S, F, J) for black-and-white fax, and base JPEG, lossless JBIG and Mixed Raster Content modes (Profiles C, L, M) for color and grayscale fax. These modes or profiles correspond to the content of the applicable ITU-T Recommendations. Files formatted according to this specification use the image/tiff MIME Content Type. |
| RFC 2302 |
Tag Image File Format (TIFF) - image/tiff MIME Sub-type Registration
|
|
Summary Publication date: Mar 1998 This document describes the registration of the MIME sub-type image/tiff. The baseline encoding is defined by [TIFF]. This document refines an earlier sub-type registration in RFC 1528 [TPC.INT]. |
| RFC 2303 |
Minimal PSTN address format in Internet Mail
|
|
Summary Publication date: Mar 1998 This memo describes the MINIMAL addressing method to encode PSTN addresses into e-mail addresses and the standard extension mechanism to allow definition of further standard elements. The opposite problem, i.e. to allow a traditional numeric-only PSTN device user to access the e-mail transport service, is not discussed here. All implementations supporting this PSTN over e-mail service MUST support as a minimum the specification described in this document. The generic complex case of converting the whole PSTN addressing into e-mail is out of scope in this minimal specification: there is some work in progress in the field, where also a number of standard optional extensions are being defined. |
| RFC 2304 |
Minimal FAX address format in Internet Mail
|
|
Summary Publication date: Mar 1998 This memo describes the MINIMAL addressing method and standard extensions to encode FAX addresses in e-mail addresses, as required in reference [13]. The opposite problem, i.e. to allow a traditional numeric-only fax device user to access the e-mail transport service, is not discussed here. All implementations supporting this FAX over e-mail address format MUST support as a minimum the specification described in this document. The generic complex case of converting the whole PSTN addressing in e-mail is out of scope in this minimal specification: there is some work in progress in the field, where also a number of standard optional extensions are being defined. |
| RFC 2305 |
A Simple Mode of Facsimile Using Internet Mail
|
|
Summary Publication date: Mar 1998 This specification provides for "simple mode" carriage of facsimile data over the Internet. Extensions to this document will follow. The current specification employs standard protocols and file formats such as TCP/IP, Internet mail protocols, MIME, and TIFF for Facsimile. It can send images not only to other Internet-aware facsimile devices but also to Internet-native systems, such as PCs with common email readers which can handle MIME mail and TIFF for Facsimile data. The specification facilitates communication among existing facsimile devices, Internet mail agents, and the gateways which connect them. |
| RFC 2306 |
Tag Image File Format (TIFF) - F Profile for Facsimile
|
|
Summary Publication date: Mar 1998 This document references the Tag Image File Format (TIFF) to define the F profile of TIFF for facsimile (TIFF-F) as a file format that may be used for the storage and interchange of facsimile images. |
| RFC 2307 |
An Approach for Using LDAP as a Network Information Service
|
|
Summary Publication date: Mar 1998 This document describes an experimental mechanism for mapping entities related to TCP/IP and the UNIX system into X.500 [X500] entries so that they may be resolved with the Lightweight Directory Access Protocol [RFC 2251]. A set of attribute types and object classes are proposed, along with specific guidelines for interpreting them. The intention is to assist the deployment of LDAP as an organizational nameservice. No proposed solutions are intended as standards for the Internet. Rather, it is hoped that a general consensus will emerge as to the appropriate solution to such problems, leading eventually to the adoption of standards. The proposed mechanism has already been implemented with some success. |
| RFC 2308 |
Negative Caching of DNS Queries (DNS NCACHE)
|
|
Summary Publication date: Mar 1998 RFC 1034 provided a description of how to cache negative responses. It however had a fundamental flaw in that it did not allow a name server to hand out those cached responses to other resolvers, thereby greatly reducing the effect of the caching. This document addresses issues raise in the light of experience and replaces [RFC 1034 Section 4.3.4]. Negative caching was an optional part of the DNS specification and deals with the caching of the non-existence of an RRset [RFC 2181] or domain name. Negative caching is useful as it reduces the response time for negative answers. It also reduces the number of messages that have to be sent between resolvers and name servers hence overall network traffic. A large proportion of DNS traffic on the Internet could be eliminated if all resolvers implemented negative caching. With this in mind negative caching should no longer be seen as an optional part of a DNS resolver. |
| RFC 2309 |
Recommendations on Queue Management and Congestion Avoidance in the Internet
|
|
Summary Publication date: Apr 1998 This memo presents two recommendations to the Internet community concerning measures to improve and preserve Internet performance. It presents a strong recommendation for testing, standardization, and widespread deployment of active queue management in routers, to improve the performance of today's Internet. It also urges a concerted effort of research, measurement, and ultimate deployment of router mechanisms to protect the Internet from flows that are not sufficiently responsive to congestion notification. |
| RFC 2310 |
The Safe Response Header Field
|
|
Summary Publication date: Apr 1998 This document defines a HTTP response header field called Safe, which can be used to indicate that repeating a HTTP request is safe. Such an indication will allow user agents to handle retries of some safe requests, in particular safe POST requests, in a more user-friendly way. |
| RFC 2311 |
S/MIME Version 2 Message Specification
|
|
Summary Publication date: Mar 1998 S/MIME (Secure/Multipurpose Internet Mail Extensions) provides a consistent way to send and receive secure MIME data. Based on the popular Internet MIME standard, S/MIME provides the following cryptographic security services for electronic messaging applications: authentication, message integrity and non-repudiation of origin (using digital signatures) and privacy and data security (using encryption). S/MIME can be used by traditional mail user agents (MUAs) to add cryptographic security services to mail that is sent, and to interpret cryptographic security services in mail that is received. However, S/MIME is not restricted to mail; it can be used with any transport mechanism that transports MIME data, such as HTTP. As such, S/MIME takes advantage of the object-based features of MIME and allows secure messages to be exchanged in mixed-transport systems. Further, S/MIME can be used in automated message transfer agents that use cryptographic security services that do not require any human intervention, such as the signing of software-generated documents and the encryption of FAX messages sent over the Internet. Please note: The information in this document is historical material being published for the public record. It is not an IETF standard. The use of the word "standard" in this document indicates a standard for adopters of S/MIME version 2, not an IETF standard. |
| RFC 2312 |
S/MIME Version 2 Certificate Handling
|
|
Summary Publication date: Mar 1998 S/MIME (Secure/Multipurpose Internet Mail Extensions), described in [SMIME-MSG], provides a method to send and receive secure MIME messages. In order to validate the keys of a message sent to it, an S/MIME agent needs to certify that the key is valid. This memo describes the mechanisms S/MIME uses to create and validate keys using certificates. This specification is compatible with PKCS #7 in that it uses the data types defined by PKCS #7. It also inherits all the varieties of architectures for certificate-based key management supported by PKCS #7. Note that the method S/MIME messages make certificate requests is defined in [SMIME-MSG]. In order to handle S/MIME certificates, an agent has to follow specifications in this memo, as well as some of the specifications listed in the following documents: - "PKCS #1: RSA Encryption", [PKCS-1]. - "PKCS #7: Cryptographic Message Syntax", [PKCS-7] - "PKCS #10: Certification Request Syntax", [PKCS-10]. Please note: The information in this document is historical material being published for the public record. It is not an IETF standard. The use of the word "standard" in this document indicates a standard for adopters of S/MIME version 2, not an IETF standard. |
| RFC 2313 |
PKCS #1: RSA Encryption Version 1.5
|
|
Summary Publication date: Mar 1998 This document describes a method for encrypting data using the RSA public-key cryptosystem. |
| RFC 2314 |
PKCS #10: Certification Request Syntax Version 1.5
|
|
Summary Publication date: Mar 1998 This document describes a syntax for certification requests. |
| RFC 2315 |
PKCS #7: Cryptographic Message Syntax Version 1.5
|
|
Summary Publication date: Mar 1998 This document describes a general syntax for data that may have cryptography applied to it, such as digital signatures and digital envelopes. The syntax admits recursion, so that, for example, one envelope can be nested inside another, or one party can sign some previously enveloped digital data. It also allows arbitrary attributes, such as signing time, to be authenticated along with the content of a message, and provides for other attributes such as countersignatures to be associated with a signature. A degenerate case of the syntax provides a means for disseminating certificates and certificate-revocation lists. |
| RFC 2316 |
Report of the IAB Security Architecture Workshop
|
|
Summary Publication date: Apr 1998 On 3-5 March 1997, the IAB held a security architecture workshop at Bell Labs in Murray Hill, NJ. We identified the core security components of the architecture, and specified several documents that need to be written. Most importantly, we agreed that security was not optional, and that it needed to be designed in from the beginning. |
| RFC 2317 |
Classless IN-ADDR.ARPA delegation
|
|
Summary Publication date: Mar 1998 This document describes a way to do IN-ADDR.ARPA delegation on non- octet boundaries for address spaces covering fewer than 256 addresses. The proposed method should thus remove one of the objections to subnet on non-octet boundaries but perhaps more significantly, make it possible to assign IP address space in smaller chunks than 24-bit prefixes, without losing the ability to delegate authority for the corresponding IN-ADDR.ARPA mappings. The proposed method is fully compatible with the original DNS lookup mechanisms specified in [1], i.e. there is no need to modify the lookup algorithm used, and there should be no need to modify any software which does DNS lookups. The document also discusses some operational considerations to provide some guidance in implementing this method. |
| RFC 2318 |
The text/css Media Type
|
|
Summary Publication date: Mar 1998 Cascading Style Sheets (CSS) is a style sheet language for the World Wide Web. CSS style sheets have been in use since October 1995 using the Media Type text/css without registration; this memo seeks to regularize that position. |
| RFC 2319 |
Ukrainian Character Set KOI8-U
|
|
Summary Publication date: Apr 1998 This document provides information about character encoding KOI8-U (KOI8 Ukrainian) wich is a de-facto standard in Ukrainian Internet community. KOI8-U is compatible with KOI8-R (RFC 1489) in all Russian letters and extends it with four Ukrainian letters which locations are compliant with ISO-IR-111. |
| RFC 2320 |
Definitions of Managed Objects for Classical IP and ARP Over ATM Using SMIv2 (IPOA-MIB)
|
|
Summary Publication date: Apr 1998 The purpose of this memo is to define the Management Information Base (MIB) for supporting Classical IP and ARP over ATM as specified in Classical IP and ARP over ATM, refer to reference [3]. Support of an ATM interface by an IP layer will require implementation of objects from several Management Information Bases (MIBs) as well as their enhancement in order to enable usage of ATM transports. It is the intent of this MIB to fully adhere to all prerequisite MIBs unless explicitly stated. Deviations will be documented in corresponding conformance statements. The specification of this MIB will utilize the Structure of Management Information (SMI) for Version 2 of the Simple Network Management Protocol Version (refer to RFC 1902, reference [1]). |
| RFC 2321 |
RITA -- The Reliable Internetwork Troubleshooting Agent
|
|
Summary Publication date: Apr 1998 A Description of the usage of Nondeterministic Troubleshooting and Diagnostic Methodologies as applied to today's complex nondeterministic networks and environments. |
| RFC 2322 |
Management of IP numbers by peg-dhcp
|
|
Summary Publication date: Apr 1998 This RFC describes a protocol to dynamically hand out ip-numbers on field networks and small events that don't necessarily have a clear organisational body. It can also provide some fixed additional fields global for all clients like netmask and even autoproxyconfigs. It does not depend on a particular ip-stack. |
| RFC 2323 |
IETF Identification and Security Guidelines
|
|
Summary Publication date: Apr 1998 This RFC is meant to represent a guideline by which the IETF conferences may run more effeciently with regards to identification and security protocols, with specific attention paid to a particular sub-group within the IETF: "facial hairius extremis". This document will shed further illumination on these problems and provide some possible solutions. This memo provides entertainment for the Internet community. It does not specify an Internet standard of any kind, but is rather unstandard, actually. Please laugh loud and hard. |
| RFC 2324 |
Hyper Text Coffee Pot Control Protocol (HTCPCP/1.0)
|
|
Summary Publication date: Apr 1998 This document describes HTCPCP, a protocol for controlling, monitoring, and diagnosing coffee pots. |
| RFC 2325 |
Definitions of Managed Objects for Drip-Type Heated Beverage Hardware Devices using SMIv2
|
|
Summary Publication date: Apr 1998 This memo defines an extension to the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it defines objects for the management of coffee-brewing and maintenance devices. |
| RFC 2326 |
Real Time Streaming Protocol (RTSP)
|
|
Summary Publication date: Apr 1998 The Real Time Streaming Protocol, or RTSP, is an application-level protocol for control over the delivery of data with real-time properties. RTSP provides an extensible framework to enable controlled, on-demand delivery of real-time data, such as audio and video. Sources of data can include both live data feeds and stored clips. This protocol is intended to control multiple data delivery sessions, provide a means for choosing delivery channels such as UDP, multicast UDP and TCP, and provide a means for choosing delivery mechanisms based upon RTP (RFC 1889). |
| RFC 2327 |
SDP: Session Description Protocol
|
|
Summary Publication date: Apr 1998 This document defines the Session Description Protocol, SDP. SDP is intended for describing multimedia sessions for the purposes of session announcement, session invitation, and other forms of multimedia session initiation. This document is a product of the Multiparty Multimedia Session Control (MMUSIC) working group of the Internet Engineering Task Force. Comments are solicited and should be addressed to the working group's mailing list at confctrl@isi.edu and/or the authors. |
| RFC 2328 |
OSPF Version 2
|
|
Summary Publication date: Apr 1998 This memo documents version 2 of the OSPF protocol. OSPF is a link-state routing protocol. It is designed to be run internal to a single Autonomous System. Each OSPF router maintains an identical database describing the Autonomous System's topology. From this database, a routing table is calculated by constructing a shortest- path tree. OSPF recalculates routes quickly in the face of topological changes, utilizing a minimum of routing protocol traffic. OSPF provides support for equal-cost multipath. An area routing capability is provided, enabling an additional level of routing protection and a reduction in routing protocol traffic. In addition, all OSPF routing protocol exchanges are authenticated. The differences between this memo and RFC 2178 are explained in Appendix G. All differences are backward-compatible in nature. Implementations of this memo and of RFCs 2178, 1583, and 1247 will interoperate. |
| RFC 2329 |
OSPF Standardization Report
|
|
Summary Publication date: Apr 1998 This memo documents how the requirements for advancing a routing protocol to Full Standard, set out in [Ref2], have been met for OSPFv2. |
| RFC 2330 |
Framework for IP Performance Metrics
|
|
Summary Publication date: May 1998 The purpose of this memo is to define a general framework for particular metrics to be developed by the IETF's IP Performance Metrics effort, begun by the Benchmarking Methodology Working Group (BMWG) of the Operational Requirements Area, and being continued by the IP Performance Metrics Working Group (IPPM) of the Transport Area. |
| RFC 2331 |
ATM Signalling Support for IP over ATM - UNI Signalling 4.0 Update
|
|
Summary Publication date: Apr 1998 This memo describes how to efficiently use the ATM call control signalling procedures defined in UNI Signalling 4.0 [SIG40] to support IP over ATM environments as described in RFC 2225 [LAUB98] and in RFC 2332 [LUC98]. Among the new features found in UNI Signalling 4.0 are Available Bit Rate signalling and traffic parameter negotiation. This memo highlights the features of UNI Signalling 4.0 that provide IP entities capabilities for requesting ATM service in sites with SVC support, whether it is private ATM or publicly provisioned ATM, in which case the SVC support is probably configured inside PVPs. This document is only relevant to IP when used as the well known "best effort" connectionless service. In particular, this means that this document does not pertain to IP in the presence of implemented IP Integrated Services. The topic of IP with Integrated Services over ATM will be handled by a different specification or set of specifications being worked on in the ISSLL WG. This specification is a follow-on to RFC 1755, "ATM Signaling Support for IP over ATM", which is based on UNI 3.1 signalling [UNI95]. Readers are assumed to be familiar with RFC 1755. |
| RFC 2332 |
NBMA Next Hop Resolution Protocol (NHRP)
|
|
Summary Publication date: Apr 1998 This document describes the NBMA Next Hop Resolution Protocol (NHRP). NHRP can be used by a source station (host or router) connected to a Non-Broadcast, Multi-Access (NBMA) subnetwork to determine the internetworking layer address and NBMA subnetwork addresses of the "NBMA next hop" towards a destination station. If the destination is connected to the NBMA subnetwork, then the NBMA next hop is the destination station itself. Otherwise, the NBMA next hop is the egress router from the NBMA subnetwork that is "nearest" to the destination station. NHRP is intended for use in a multiprotocol internetworking layer environment over NBMA subnetworks. Note that while this protocol was developed for use with NBMA subnetworks, it is possible, if not likely, that it will be applied to BMA subnetworks as well. However, this usage of NHRP is for further study. This document is intended to be a functional superset of the NBMA Address Resolution Protocol (NARP) documented in [1]. Operation of NHRP as a means of establishing a transit path across an NBMA subnetwork between two routers will be addressed in a separate document (see [13]). |
| RFC 2333 |
NHRP Protocol Applicability Statement
|
|
Summary Publication date: Apr 1998 As required by the Routing Protocol Criteria [RFC 1264], this memo discusses the applicability of the Next Hop Resolution Protocol (NHRP) in routing of IP datagrams over Non-Broadcast Multiple Access (NBMA) networks, such as ATM, SMDS and X.25. |
| RFC 2334 |
Server Cache Synchronization Protocol (SCSP)
|
|
Summary Publication date: Apr 1998 This document describes the Server Cache Synchronization Protocol (SCSP) and is written in terms of SCSP's use within Non Broadcast Multiple Access (NBMA) networks; although, a somewhat straight forward usage is applicable to BMA networks. SCSP attempts to solve the generalized cache synchronization/cache-replication problem for distributed protocol entities. However, in this document, SCSP is couched in terms of the client/server paradigm in which distributed server entities, which are bound to a Server Group (SG) through some means, wish to synchronize the contents (or a portion thereof) of their caches which contain information about the state of clients being served. |
| RFC 2335 |
A Distributed NHRP Service Using SCSP
|
|
Summary Publication date: Apr 1998 This document describes a method for distributing an NHRP service within a LIS [1]. This method uses the Server Cache Synchronization Protocol (SCSP) [2] to synchronize the client information databases held by NHRP Servers (NHSs) within a LIS. |
| RFC 2336 |
Classical IP to NHRP Transition
|
|
Summary Publication date: Jul 1998 This document describes methods and procedures for the graceful transition from an ATMARP LIS[1] to an NHRP LIS[2] network model over ATM. |
| RFC 2337 |
Intra-LIS IP multicast among routers over ATM using Sparse Mode PIM
|
|
Summary Publication date: Apr 1998 This document describes how intra-LIS IP multicast can be efficiently supported among routers over ATM without using the Multicast Address Resolution Server (MARS). The method described here is specific to Sparse Mode PIM [PIM-SM], and relies on the explicit join mechanism inherent in PIM-SM to notify routers when they should create group specific point-to-multipoint VCs. |
| RFC 2338 |
Virtual Router Redundancy Protocol
|
|
Summary Publication date: Apr 1998 This memo defines the Virtual Router Redundancy Protocol (VRRP). VRRP specifies an election protocol that dynamically assigns responsibility for a virtual router to one of the VRRP routers on a LAN. The VRRP router controlling the IP address(es) associated with a virtual router is called the Master, and forwards packets sent to these IP addresses. The election process provides dynamic fail over in the forwarding responsibility should the Master become unavailable. This allows any of the virtual router IP addresses on the LAN to be used as the default first hop router by end-hosts. The advantage gained from using VRRP is a higher availability default path without requiring configuration of dynamic routing or router discovery protocols on every end-host. |
| RFC 2339 |
An Agreement Between the Internet Society, the IETF, and Sun Microsystems, Inc. in the matter of NFS V.4 Protocols
|
|
Summary Publication date: May 1998 This Request for Comments records an agreement between Sun Microsystems, Inc. and the Internet Society to permit the flow of Sun's Network File System specifications into the Internet Standards process conducted by the Internet Engineering Task Force. |
| RFC 2340 |
Nortel's Virtual Network Switching (VNS) Overview
|
|
Summary Publication date: May 1998 This document provides an overview of Virtual Network Switching (VNS). VNS is a multi-protocol switching architecture that provides COS- sensitive packet switching, reduces the complexity of operating protocols like PPP and frame relay, provides logical networks and traffic segregation for Virtual Private Networks (VPNs), security and traffic engineering, enables efficient WAN broadcasting and multicasting, and reduces address space requirements. VNS reduces the number of routing hops over the WAN by switching packets based on labels. VNS has been proven in production networks for several years. |
| RFC 2341 |
Cisco Layer Two Forwarding (Protocol) 'L2F'
|
|
Summary Publication date: May 1998 Virtual dial-up allows many separate and autonomous protocol domains to share common access infrastructure including modems, Access Servers, and ISDN routers. Previous RFCs have specified protocols for supporting IP dial-up via SLIP [1] and multiprotocol dial-up via PPP [2]. This document describes the Layer Two Forwarding protocol (L2F) which permits the tunneling of the link layer (i.e., HDLC, async HDLC, or SLIP frames) of higher level protocols. Using such tunnels, it is possible to divorce the location of the initial dial- up server from the location at which the dial-up protocol connection is terminated and access to the network provided. |
| RFC 2342 |
IMAP4 Namespace
|
|
Summary Publication date: May 1998 IMAP4 [RFC 2060] does not define a default server namespace. As a result, two common namespace models have evolved: The "Personal Mailbox" model, in which the default namespace that is presented consists of only the user's personal mailboxes. To access shared mailboxes, the user must use an escape mechanism to reach another namespace. The "Complete Hierarchy" model, in which the default namespace that is presented includes the user's personal mailboxes along with any other mailboxes they have access to. These two models, create difficulties for certain client operations. This document defines a NAMESPACE command that allows a client to discover the prefixes of namespaces used by a server for personal mailboxes, other users' mailboxes, and shared mailboxes. This allows a client to avoid much of the manual user configuration that is now necessary when mixing and matching IMAP4 clients and servers. |
| RFC 2343 |
RTP Payload Format for Bundled MPEG
|
|
Summary Publication date: May 1998 This document describes a payload type for bundled, MPEG-2 encoded video and audio data that may be used with RTP, version 2. Bundling has some advantages for this payload type particularly when it is used for video-on-demand applications. This payload type may be used when its advantages are important enough to sacrifice the modularity of having separate audio and video streams. |
| RFC 2344 |
Reverse Tunneling for Mobile IP
|
|
Summary Publication date: May 1998 Mobile IP uses tunneling from the home agent to the mobile node's care-of address, but rarely in the reverse direction. Usually, a mobile node sends its packets through a router on the foreign network, and assumes that routing is independent of source address. When this assumption is not true, it is convenient to establish a topologically correct reverse tunnel from the care-of address to the home agent. This document proposes backwards-compatible extensions to Mobile IP in order to support topologically correct reverse tunnels. This document does not attempt to solve the problems posed by firewalls located between the home agent and the mobile node's care-of address. |
| RFC 2345 |
Domain Names and Company Name Retrieval
|
|
Summary Publication date: May 1998 Location of web information for particular companies based on their names has become an increasingly difficult problem as the Internet and the web grow. The use of a naming convention and the domain name system (DNS) for that purpose has caused complications for the latter while not solving the problem. While there have been several proposals to use contemporary, high-capability, directory service and search protocols to reduce the dependencies on DNS conventions, none of them have been significantly deployed. This document proposes a company name to URL mapping service based on the oldest and least complex of Internet directory protocols, whois, in order to explore whether an extremely simple and widely-deployed protocol can succeed where more complex and powerful options have failed or been excessively delayed. |
| RFC 2346 |
Making Postscript and PDF International
|
|
Summary Publication date: May 1998 Certain text formats, for example Postscript (MIME-Type: application/postscript; file extension .ps) and Portable Document Format (MIME-Type: application/pdf; file extension .pdf) specify exactly the page layout of the printed document. The commonly used paper format is different in North America and the rest of the world. North America uses the 'Letter' format, while the rest of the world mostly uses the ISO-standard 'A4' format. This means that documents formatted on one continent may not be easily printable on another continent. This memo gives advice on how to produce documents which are equally well printable with the Letter and the A4 formats. By using the advice in this document, you can put up a document on the Internet, which recipients can print without problem both in and outside North America. A very short summary of the advice in this document: If you are using U.S. Letter paper format, ensure that both the left and right margins are at least 21 mm (0.8 in). If you are using A4 paper format, ensure that both the top and bottom margins are at least 33 mm (1.3 in). |
| RFC 2347 |
TFTP Option Extension
|
|
Summary Publication date: May 1998 The Trivial File Transfer Protocol is a simple, lock-step, file transfer protocol which allows a client to get or put a file onto a remote host. This document describes a simple extension to TFTP to allow option negotiation prior to the file transfer. |
| RFC 2348 |
TFTP Blocksize Option
|
|
Summary Publication date: May 1998 The Trivial File Transfer Protocol is a simple, lock-step, file transfer protocol which allows a client to get or put a file onto a remote host. One of its primary uses is the booting of diskless nodes on a Local Area Network. TFTP is used because it is very simple to implement in a small node's limited ROM space. However, the choice of a 512-octet blocksize is not the most efficient for use on a LAN whose MTU may 1500 octets or greater. This document describes a TFTP option which allows the client and server to negotiate a blocksize more applicable to the network medium. The TFTP Option Extension mechanism is described in [2]. |
| RFC 2349 |
TFTP Timeout Interval and Transfer Size Options
|
|
Summary Publication date: May 1998 The Trivial File Transfer Protocol is a simple, lock-step, file transfer protocol which allows a client to get or put a file onto a remote host. This document describes two TFTP options. The first allows the client and server to negotiate the Timeout Interval. The second allows the side receiving the file to determine the ultimate size of the transfer before it begins. The TFTP Option Extension mechanism is described in [2]. |
| RFC 2350 |
Expectations for Computer Security Incident Response
|
|
Summary Publication date: Jun 1998 The purpose of this document is to express the general Internet community's expectations of Computer Security Incident Response Teams (CSIRTs). It is not possible to define a set of requirements that would be appropriate for all teams, but it is possible and helpful to list and describe the general set of topics and issues which are of concern and interest to constituent communities. CSIRT constituents have a legitimate need and right to fully understand the policies and procedures of 'their' Computer Security Incident Response Team. One way to support this understanding is to supply detailed information which users may consider, in the form of a formal template completed by the CSIRT. An outline of such a template and a filled in example are provided. |
| RFC 2351 |
Mapping of Airline Reservation, Ticketing, and Messaging Traffic over IP
|
|
Summary Publication date: May 1998 This memo specifies a protocol for the encapsulation of the airline specific protocol over IP. |
| RFC 2352 |
A Convention For Using Legal Names as Domain Names
|
|
Summary Publication date: May 1998 The purpose of this memo is to focus discussion on the particular problems with the exhaustion of the top level domain space in the Internet and the possible conflicts that can occur when multiple organisations are vying for the same name. The proposed solutions in this document are intended as a framework for development, such that a general consensus will emerge as to the appropriate solution to the problems in each case, leading eventually to the adoption of standards. |
| RFC 2353 |
APPN/HPR in IP Networks APPN Implementers' Workshop Closed Pages Document
|
|
Summary Publication date: May 1998 The APPN Implementers' Workshop (AIW) is an industry-wide consortium of networking vendors that develops Advanced Peer-to-Peer Networking(R) (APPN(R)) standards and other standards related to Systems Network Architecture (SNA), and facilitates high quality, fully interoperable APPN and SNA internetworking products. The AIW approved Closed Pages (CP) status for the architecture in this document on December 2, 1997, and, as a result, the architecture was added to the AIW architecture of record. A CP-level document is sufficiently detailed that implementing products will be able to interoperate; it contains a clear and complete specification of all necessary changes to the architecture of record. However, the AIW has procedures by which the architecture may be modified, and the AIW is open to suggestions from the internet community. The architecture for APPN nodes is specified in "Systems Network Architecture Advanced Peer-to-Peer Networking Architecture Reference". A set of APPN enhancements for High Performance Routing (HPR) is specified in "Systems Network Architecture Advanced Peer-to-Peer Networking High Performance Routing Architecture Reference, Version 3.0". The formats associated with these architectures are specified in "Systems Network Architecture Formats". This memo assumes the reader is familiar with these specifications. This memo defines a method with which HPR nodes can use IP networks for communication, and the enhancements to APPN required by this method. This memo also describes an option set that allows the use of the APPN connection network model to allow HPR nodes to use IP networks for communication without having to predefine link connections. |
| RFC 2354 |
Options for Repair of Streaming Media
|
|
Summary Publication date: Jun 1998 This document summarizes a range of possible techniques for the repair of continuous media streams subject to packet loss. The techniques discussed include redundant transmission, retransmission, interleaving and forward error correction. The range of applicability of these techniques is noted, together with the protocol requirements and dependencies. |
| RFC 2355 |
TN3270 Enhancements
|
|
Summary Publication date: Jun 1998 This document describes a protocol that more fully supports 3270 devices than do traditional tn3270 practices. Specifically, it defines a method of emulating both the terminal and printer members of the 3270 family of devices via Telnet; it provides for the ability of a Telnet client to request that it be assigned a specific device- name (also referred to as "LU name" or "network name"); finally, it adds support for a variety of functions such as the ATTN key, the SYSREQ key, and SNA response handling. This protocol is negotiated under the TN3270E Telnet Option, and is unrelated to the Telnet 3270 Regime Option as defined in RFC 1041. |
| RFC 2356 |
Sun's SKIP Firewall Traversal for Mobile IP
|
|
Summary Publication date: Jun 1998 The Mobile IP specification establishes the mechanisms that enable a mobile host to maintain and use the same IP address as it changes its point of attachment to the network. Mobility implies higher security risks than static operation, because the traffic may at times take unforeseen network paths with unknown or unpredictable security characteristics. The Mobile IP specification makes no provisions for securing data traffic. The mechanisms described in this document allow a mobile node out on a public sector of the internet to negotiate access past a SKIP firewall, and construct a secure channel into its home network. In addition to securing traffic, our mechanisms allow a mobile node to roam into regions that (1) impose ingress filtering, and (2) use a different address space. |
| RFC 2357 |
IETF Criteria for Evaluating Reliable Multicast Transport and Application Protocols
|
|
Summary Publication date: Jun 1998 This memo describes the procedures and criteria for reviewing reliable multicast protocols within the Transport Area (TSV) of the IETF. Within today's Internet, important applications exist for a reliable multicast service. Some examples that are driving reliable multicast technology are collaborative workspaces (such as whiteboard), data and software distribution, and (more speculatively) web caching protocols. Due to the nature of the technical issues, a single commonly accepted technical solution that solves all the demands for reliable multicast is likely to be infeasible [RMMinutes 1997]. A number of reliable multicast protocols have already been developed to solve a variety of problems for various types of applications. [Floyd97] describes one widely deployed example. How should these protocols be treated within the IETF and how should the IETF guide the development of reliable multicast in a direction beneficial for the general Internet? The TSV Area Directors and their Directorate have outlined a set of review procedures that address these questions and set criteria and processes for the publication as RFCs of Internet-Drafts on reliable multicast transport protocols. |
| RFC 2358 |
Definitions of Managed Objects for the Ethernet-like Interface Types
|
|
Summary Publication date: Jun 1998 This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. This memo obsoletes RFC 1650 "Definitions of Managed Objects for the Ethernet-like Interface Types using SMIv2". This memo extends that specification by including management information useful for the management of 100 Mb/s Ethernet interfaces. Ethernet technology, as defined by the 802.3 Working Group of the IEEE, continues to evolve, with scalable increases in speed, new types of cabling and interfaces, and new features. This evolution may require changes in the managed objects in order to reflect this new functionality. This document, as with other documents issued by this working group, reflect a certain stage in the evolution of Ethernet technology. In the future, this document might be revised, or new documents might be issued by the Ethernet Interfaces and Hub MIB Working Group, in order to reflect the evolution of Ethernet technology. |
| RFC 2359 |
IMAP4 UIDPLUS extension
|
|
Summary Publication date: Jun 1998 The UIDPLUS extension of the Internet Message Access Protocol [IMAP4] provides a set of features intended to reduce the amount of time and resources used by some client operations. The features in UIDPLUS are primarily intended for disconnected-use clients. |
| RFC 2360 |
Guide for Internet Standards Writers
|
|
Summary Publication date: Jun 1998 This document is a guide for Internet standard writers. It defines those characteristics that make standards coherent, unambiguous, and easy to interpret. In addition, it singles out usage believed to have led to unclear specifications, resulting in non-interoperable interpretations in the past. These guidelines are to be used with RFC 2223, "Instructions to RFC Authors". |
| RFC 2361 |
WAVE and AVI Codec Registries
|
|
Summary Publication date: Jun 1998 Internet applications may reference specific codecs within the WAVE and AVI registries as follows: * video/vnd.avi; codec=XXX identifies a specific video codec (i.e., XXX) within the AVI Registry. * audio/vnd.wave; codec=YYY identifies a specific audio codec (i.e., YYY) within the WAVE Registry. Appendix A and Appendix B provides an authoritative reference for the interpretation of the required "codec" parameter. That is, the current set of audio codecs that are registered within the WAVE Registry are enumerated in Appendix A. Appendix B enumerates the current set of video codecs that have been registered to date within the AVI Registry. |
| RFC 2362 |
Protocol Independent Multicast-Sparse Mode (PIM-SM): Protocol Specification
|
|
Summary Publication date: Jun 1998 This document describes a protocol for efficiently routing to multicast groups that may span wide-area (and inter-domain) internets. We refer to the approach as Protocol Independent Multicast--Sparse Mode (PIM-SM) because it is not dependent on any particular unicast routing protocol, and because it is designed to support sparse groups as defined in [1][2]. This document describes the protocol details. For the motivation behind the design and a description of the architecture, see [1][2]. Section 2 summarizes PIM-SM operation. It describes the protocol from a network perspective, in particular, how the participating routers interact to create and maintain the multicast distribution tree. Section 3 describes PIM-SM operations from the perspective of a single router implementing the protocol; this section constitutes the main body of the protocol specification. It is organized according to PIM-SM message type; for each message type we describe its contents, its generation, and its processing. Sections 3.8 and 3.9 summarize the timers and flags referred to throughout this document. Section 4 provides packet format details. The most significant functional changes since the January '95 version involve the Rendezvous Point-related mechanisms, several resulting simplifications to the protocol, and removal of the PIM-DM protocol details to a separate document [3] (for clarity). |
| RFC 2363 |
PPP Over FUNI
|
|
Summary Publication date: Jul 1998 The Point-to-Point Protocol (PPP) provides a standard method for transporting multi-protocol datagrams over point-to-point links. This document describes the use of ATM Frame User Network Interface (FUNI) for framing PPP encapsulated packets. |
| RFC 2364 |
PPP Over AAL5
|
|
Summary Publication date: Jul 1998 The Point-to-Point Protocol (PPP) provides a standard method for transporting multi-protocol datagrams over point-to-point links. This document describes the use of ATM Adaptation Layer 5 (AAL5) for framing PPP encapsulated packets. |
| RFC 2365 |
Administratively Scoped IP Multicast
|
|
Summary Publication date: Jul 1998 This document defines the "administratively scoped IPv4 multicast space" to be the range 239.0.0.0 to 239.255.255.255. In addition, it describes a simple set of semantics for the implementation of Administratively Scoped IP Multicast. Finally, it provides a mapping between the IPv6 multicast address classes [RFC 1884] and IPv4 multicast address classes. This memo is a product of the MBONE Deployment Working Group (MBONED) in the Operations and Management Area of the Internet Engineering Task Force. |
| RFC 2366 |
Definitions of Managed Objects for Multicast over UNI 3.0/3.1 based ATM Networks
|
|
Summary Publication date: Jul 1998 This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes managed objects for IP hosts and routers that use a Multicast Address Resolution Server (MARS) to support IP multicast over ATM, as described in 'Support for Multicast over UNI 3.0/3.1 based ATM Networks' [1]. This memo specifies a MIB module in a manner that is both compliant to the SNMPv2 SMI, and semantically identical to the peer SNMPv1 definitions. This memo does not specify a standard for the Internet community. |
| RFC 2367 |
PF_KEY Key Management API, Version 2
|
|
Summary Publication date: Jul 1998 A generic key management API that can be used not only for IP Security [Atk95a] [Atk95b] [Atk95c] but also for other network security services is presented in this document. Version 1 of this API was implemented inside 4.4-Lite BSD as part of the U. S. Naval Research Laboratory's freely distributable and usable IPv6 and IPsec implementation[AMPMC96]. It is documented here for the benefit of others who might also adopt and use the API, thus providing increased portability of key management applications (e.g. a manual keying application, an ISAKMP daemon, a GKMP daemon [HM97a][HM97b], a Photuris daemon, or a SKIP certificate discovery protocol daemon). |
| RFC 2368 |
The mailto URL scheme
|
|
Summary Publication date: Jul 1998 This document defines the format of Uniform Resource Locators (URL) for designating electronic mail addresses. It is one of a suite of documents which replace RFC 1738, 'Uniform Resource Locators', and RFC 1808, 'Relative Uniform Resource Locators'. The syntax of 'mailto' URLs from RFC 1738 is extended to allow creation of more RFC 822 messages by allowing the URL to express additional header and body fields. |
| RFC 2369 |
The Use of URLs as Meta-Syntax for Core Mail List Commands and their Transport through Message Header Fields
|
|
Summary Publication date: Jul 1998 The mailing list command specification header fields are a set of structured fields to be added to email messages sent by email distribution lists. Each field typically contains a URL (usually mailto [RFC 2368]) locating the relevant information or performing the command directly. The three core header fields described in this document are List-Help, List-Subscribe, and List-Unsubscribe. There are three other header fields described here which, although not as widely applicable, will have utility for a sufficient number of mailing lists to justify their formalization here. These are List-Post, List-Owner and List-Archive. By including these header fields, list servers can make it possible for mail clients to provide automated tools for users to perform list functions. This could take the form of a menu item, push button, or other user interface element. The intent is to simplify the user experience, providing a common interface to the often cryptic and varied mailing list manager commands. |
| RFC 2370 |
The OSPF Opaque LSA Option
|
|
Summary Publication date: Jul 1998 This memo defines enhancements to the OSPF protocol to support a new class of link-state advertisements (LSA) called Opaque LSAs. Opaque LSAs provide a generalized mechanism to allow for the future extensibility of OSPF. Opaque LSAs consist of a standard LSA header followed by application-specific information. The information field may be used directly by OSPF or by other applications. Standard OSPF link-state database flooding mechanisms are used to distribute Opaque LSAs to all or some limited portion of the OSPF topology. |
| RFC 2371 |
Transaction Internet Protocol Version 3.0
|
|
Summary Publication date: Jul 1998 In many applications where different nodes cooperate on some work, there is a need to guarantee that the work happens atomically. That is, each node must reach the same conclusion as to whether the work is to be completed, even in the face of failures. This document proposes a simple, easily-implemented protocol for achieving this end. |
| RFC 2372 |
Transaction Internet Protocol - Requirements and Supplemental Information
|
|
Summary Publication date: Jul 1998 This document describes the purpose (usage scenarios), and requirements for the Transaction Internet Protocol [1]. It is intended to help qualify the necessary features and functions of the protocol. It also provides supplemental information to aid understanding and facilitate implementation of the TIP protocol. |
| RFC 2373 |
IP Version 6 Addressing Architecture
|
|
Summary Publication date: Jul 1998 This specification defines the addressing architecture of the IP Version 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 an IPv6 node's required addresses. |
| RFC 2374 |
An IPv6 Aggregatable Global Unicast Address Format
|
|
Summary Publication date: Jul 1998 This document defines an IPv6 aggregatable global unicast address format for use in the Internet. The address format defined in this document is consistent with the IPv6 Protocol [IPV6] and the "IPv6 Addressing Architecture". It is designed to facilitate scalable Internet routing. This documented replaces RFC 2073, "An IPv6 Provider-Based Unicast Address Format". RFC 2073 will become historic. The Aggregatable Global Unicast Address Format is an improvement over RFC 2073 in a number of areas. The major changes include removal of the registry bits because they are not needed for route aggregation, support of EUI-64 based interface identifiers, support of provider and exchange based aggregation, separation of public and site topology, and new aggregation based terminology. |
| RFC 2375 |
IPv6 Multicast Address Assignments
|
|
Summary Publication date: Jul 1998 This document defines the initial assignment of IPv6 multicast addresses. It is based on the "IP Version 6 Addressing Architecture" and current IPv4 multicast address assignment found in |
| RFC 2376 |
XML Media Types
|
|
Summary Publication date: Jul 1998 This document proposes two new media subtypes, text/xml and application/xml, for use in exchanging network entities which are conforming Extensible Markup Language (XML). XML entities are currently exchanged via the HyperText Transfer Protocol on the World Wide Web, are an integral part of the WebDAV protocol for remote web authoring, and are expected to have utility in many domains. |
| RFC 2377 |
Naming Plan for Internet Directory-Enabled Applications
|
|
Summary Publication date: Sep 1998 Application of the conventional X.500 approach to naming has heretofore, in the experience of the authors, proven to be an obstacle to the wide deployment of directory-enabled applications on the Internet. We propose a new directory naming plan that leverages the strengths of the most popular and successful Internet naming schemes for naming objects in a hierarchical directory. This plan can, we believe, by extending the X.500 approach to naming, facilitate the creation of an Internet White Pages Service (IWPS) and other directory-enabled applications by overcoming the problems encountered by those using the conventional X.500 approach. |
| RFC 2378 |
The CCSO Nameserver (Ph) Architecture
|
|
Summary Publication date: Sep 1998 The Ph Nameserver from the Computing and Communications Services Office (CCSO), University of Illinois at Urbana-Champaign has for some time now been used by several organizations as their choice of publicly available database for information about people as well as other things. This document provides a formal definition of the client-server protocol. The Ph service as specified in this document is built around an information model, a client command language and the server responses. |
| RFC 2379 |
RSVP over ATM Implementation Guidelines
|
|
Summary Publication date: Aug 1998 This memo presents specific implementation guidelines for running RSVP over ATM switched virtual circuits (SVCs). The general problem is discussed in [6]. Implementation requirements are discussed in [2]. Integrated Services to ATM service mappings are covered in [3]. The full set of documents present the background and information needed to implement Integrated Services and RSVP over ATM. |
| RFC 2380 |
RSVP over ATM Implementation Requirements
|
|
Summary Publication date: Aug 1998 This memo presents specific implementation requirements for running RSVP over ATM switched virtual circuits (SVCs). It presents requirements that ensure interoperability between multiple implementations and conformance to the RSVP and Integrated Services specifications. A separate document [5] provides specific guidelines for running over today's ATM networks. The general problem is discussed in [9]. Integrated Services to ATM service mappings are covered in [6]. The full set of documents present the background and information needed to implement Integrated Services and RSVP over ATM. |
| RFC 2381 |
Interoperation of Controlled-Load Service and Guaranteed Service with ATM
|
|
Summary Publication date: Aug 1998 This document provides guidelines for mapping service classes, and traffic management features and parameters between Internet and ATM technologies. The service mappings are useful for providing effective interoperation and end-to-end Quality of Service for IP Integrated Services networks containing ATM subnetworks. The discussion and specifications given here support the IP integrated services protocols for Guaranteed Service (GS), Controlled-Load Service (CLS) and the ATM Forum UNI specification, versions 3.0, 3.1 and 4.0. Some discussion of IP best effort service over ATM is also included. |
| RFC 2382 |
A Framework for Integrated Services and RSVP over ATM
|
|
Summary Publication date: Aug 1998 This document outlines the issues and framework related to providing IP Integrated Services with RSVP over ATM. It provides an overall approach to the problem(s) and related issues. These issues and problems are to be addressed in further documents from the ISATM subgroup of the ISSLL working group. |
| RFC 2383 |
ST2+ over ATM Protocol Specification - UNI 3.1 Version
|
|
Summary Publication date: Aug 1998 This document specifies an ATM-based protocol for communication between ST2+ agents. The ST2+ over ATM protocol supports the matching of one hop in an ST2+ tree-structure stream with one ATM connection. In this document, ATM is a subnet technology for the ST2+ stream. The ST2+ over ATM protocol is designed to achieve resource- reservation communications across ATM and non-ATM networks, to extend the UNI 3.1/4.0 signaling functions, and to reduce the UNI 4.0 LIJ signaling limitations. The specifications of the ST2+ over ATM protocol consist of a revision of RFC 1819 ST2+ and specifications of protocol interaction between ST2+ and ATM on the user plane, management plane, and control plane which correspond to the three planes of the B-ISDN protocol reference model. |
| RFC 2384 |
POP URL Scheme
|
|
Summary Publication date: Aug 1998 POP3 is a widely-deployed mail access protocol. Many programs access POP3 message stores, and thus need POP3 configuration information. Since there are multiple configuration elements which are required in order to access a mailbox, a single string representation is convenient. A POP3 mailbox (like an IMAP4 mailbox) is a network resource, and URLs are a widely-supported generalized representation of network resources. A means of specifying a POP3 mailbox as a URL will likely be useful in many programs and protocols. ACAP is one case where a string encapsulation of elements required to access network services is needed. For example, an IMAP4 message store is usually specified in ACAP datasets as an IMAP-URL. This memo defines a URL scheme for referencing a POP mailbox. |
| RFC 2385 |
Protection of BGP Sessions via the TCP MD5 Signature Option
|
|
Summary Publication date: Aug 1998 This memo describes a TCP extension to enhance security for BGP. It defines a new TCP option for carrying an MD5 [RFC 1321] digest in a TCP segment. This digest acts like a signature for that segment, incorporating information known only to the connection end points. Since BGP uses TCP as its transport, using this option in the way described in this paper significantly reduces the danger from certain security attacks on BGP. |
| RFC 2386 |
A Framework for QoS-based Routing in the Internet
|
|
Summary Publication date: Aug 1998 QoS-based routing has been recognized as a missing piece in the evolution of QoS-based service offerings in the Internet. This document describes some of the QoS-based routing issues and requirements, and proposes a framework for QoS-based routing in the Internet. This framework is based on extending the current Internet routing model of intra and interdomain routing to support QoS. |
| RFC 2387 |
The MIME Multipart/Related Content-type
|
|
Summary Publication date: Aug 1998 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 2388 |
Returning Values from Forms: multipart/form-data
|
|
Summary Publication date: Aug 1998 This specification defines an Internet Media Type, multipart/form- data, which can be used by a wide variety of applications and transported by a wide variety of protocols as a way of returning a set of values as the result of a user filling out a form. |
| RFC 2389 |
Feature negotiation mechanism for the File Transfer Protocol
|
|
Summary Publication date: Aug 1998 The File Transfer Protocol is, from time to time, extended with new commands, or facilities. Implementations of the FTP protocol cannot be assumed to all immediately implement all newly defined mechanisms. This document provides a mechanism by which clients of the FTP protocol can discover which new features are supported by a particular FTP server. |
| RFC 2390 |
Inverse Address Resolution Protocol
|
|
Summary Publication date: Sep 1998 This memo describes additions to ARP that will allow a station to request a protocol address corresponding to a given hardware address. Specifically, this applies to Frame Relay stations that may have a Data Link Connection Identifier (DLCI), the Frame Relay equivalent of a hardware address, associated with an established Permanent Virtual Circuit (PVC), but do not know the protocol address of the station on the other side of this connection. It will also apply to other networks with similar circumstances. This memo replaces RFC 1293. The changes from RFC 1293 are minor changes to formalize the language, the additions of a packet diagram and an example in section 7.2, and a new security section. |
| RFC 2391 |
Load Sharing using IP Network Address Translation (LSNAT)
|
|
Summary Publication date: Aug 1998 Network Address Translators (NATs) translate IP addresses in a datagram, transparent to end nodes, while routing the datagram. NATs have traditionally been been used to allow private network domains to connect to Global networks using as few as one globally unique IP address. In this document, we extend the use of NATs to offer Load share feature, where session load can be distributed across a pool of servers, instead of directing to a single server. Load sharing is beneficial to service providers and system administrators alike in grappling with scalability of servers with increasing session load. |
| RFC 2392 |
Content-ID and Message-ID Uniform Resource Locators
|
|
Summary Publication date: Aug 1998 The Uniform Resource Locator (URL) schemes, "cid:" and "mid:" allow references to messages and the body parts of messages. For example, within a single multipart message, one HTML body part might include embedded references to other parts of the same message. |
| RFC 2393 |
IP Payload Compression Protocol (IPComp)
|
|
Summary Publication date: Dec 1998 This document describes a protocol intended to provide lossless compression for Internet Protocol datagrams in an Internet environment. |
| RFC 2394 |
IP Payload Compression Using DEFLATE
|
|
Summary Publication date: Dec 1998 This document describes a compression method based on the DEFLATE compression algorithm. This document defines the application of the DEFLATE algorithm to the IP Payload Compression Protocol. |
| RFC 2395 |
IP Payload Compression Using LZS
|
|
Summary Publication date: Dec 1998 This document describes a compression method based on the LZS compression algorithm. This document defines the application of the LZS algorithm to the IP Payload Compression Protocol [IPCOMP]. [IPCOMP] defines a method for applying lossless compression to the payloads of Internet Protocol datagrams. |
| RFC 2396 |
Uniform Resource Identifiers (URI): Generic Syntax
|
|
Summary Publication date: Aug 1998 A Uniform Resource Identifier (URI) is a compact string of characters for identifying an abstract or physical resource. This document defines the generic syntax of URI, including both absolute and relative forms, and guidelines for their use; it revises and replaces the generic definitions in RFC 1738 and RFC 1808. This document defines a grammar that is a superset of all valid URI, such that an implementation can parse the common components of a URI reference without knowing the scheme-specific requirements of every possible identifier type. This document does not define a generative grammar for URI; that task will be performed by the individual specifications of each URI scheme. |
| RFC 2397 |
The 'data' URL scheme
|
|
Summary Publication date: Aug 1998 A new URL scheme, "data", is defined. It allows inclusion of small data items as "immediate" data, as if it had been included externally. |
| RFC 2398 |
Some Testing Tools for TCP Implementors
|
|
Summary Publication date: Aug 1998 Available tools for testing TCP implementations are catalogued by this memo. Hopefully disseminating this information will encourage those responsible for building and maintaining TCP to make the best use of available tests. The type of testing the tool provides, the type of tests it is capable of doing, and its availability is enumerated. This document lists only tools which can evaluate one or more TCP implementations, or which can privde some specific results which describe or evaluate the TCP being tested. |
| RFC 2399 |
Request for Comments Summary
|
|
Summary Publication date: Jan 1999 This RFC is a slightly annotated list of the 100 RFCs from RFC 2300 through RFCs 2399. This is a status report on these RFCs. |
| RFC 2400 |
Internet Official Protocol Standards
|
|
Summary Publication date: Sep 1998 This memo describes the state of standardization of protocols used in the Internet as determined by the Internet Architecture Board (IAB). |
