| |
| RFC 2300 | Internet Official Protocol Standards |
| |
|
|
A discussion of the standardization process and the RFC document series is presented first, followed by an explanation of the terms. Sections 6.2 - 6.10 contain the lists of protocols in each stage of standardization. Finally are pointers to references and contacts for further information. [STANDARDS-TRACK] |
|
| |
| RFC 2301 | File Format for Internet Fax |
| |
| Authors: | L. McIntyre, S. Zilles, R. Buckley, D. Venable, G. Parsons, J. Rafferty. |
| Date: | March 1998 |
| Formats: | txt html json |
| Obsoleted by: | RFC 3949 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 2301 |
|
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 RasterContent modes (Profiles C, L, M) for color and grayscale fax. These modes or profiles correspond to the content of the applicable ITU-TRecommendations. 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 |
| |
| Authors: | G. Parsons, J. Rafferty, S. Zilles. |
| Date: | March 1998 |
| Formats: | txt json html |
| Obsoleted by: | RFC 3302 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 2302 |
|
This document describes the registration of the MIME sub-type image/tiff. [STANDARDS-TRACK] |
|
| |
| RFC 2303 | Minimal PSTN address format in Internet Mail |
| |
|
|
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. [STANDARDS-TRACK] |
|
| |
| RFC 2304 | Minimal FAX address format in Internet Mail |
| |
|
|
This memo describes the MINIMAL addressing method and standard extensions to encode FAX addresses in e-mail addresses. [STANDARDS- TRACK] |
|
| |
| RFC 2305 | A Simple Mode of Facsimile Using Internet Mail |
| |
| Authors: | K. Toyoda, H. Ohno, J. Murai, D. Wing. |
| Date: | March 1998 |
| Formats: | txt html json |
| Obsoleted by: | RFC 3965 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 2305 |
|
This specification provides for "simple mode" carriage of facsimile data over the Internet. [STANDARDS-TRACK] |
|
| |
| RFC 2306 | Tag Image File Format (TIFF) - F Profile for Facsimile |
| |
| Authors: | G. Parsons, J. Rafferty. |
| Date: | March 1998 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 2306 |
|
This document describes in detail the definition of TIFF-F that is used to store facsimile images. This memo provides information for the Internet community. It does not specify an Internet standard of any kind. |
|
| |
| RFC 2307 | An Approach for Using LDAP as a Network Information Service |
| |
| Authors: | L. Howard. |
| Date: | March 1998 |
| Formats: | txt json html |
| Status: | EXPERIMENTAL |
| DOI: | 10.17487/RFC 2307 |
|
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 DirectoryAccess Protocol [RFC2251]. 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) |
| |
|
|
[RFC1034] 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 [RFC1034 Section4.3.4].
Negative caching was an optional part of the DNS specification and deals with the caching of the non-existence of an RRset [RFC2181] 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 |
| |
| Authors: | B. Braden, D. Clark, J. Crowcroft, B. Davie, S. Deering, D. Estrin, S. Floyd, V. Jacobson, G. Minshall, C. Partridge, L. Peterson, K. Ramakrishnan, S. Shenker, J. Wroclawski, L. Zhang. |
| Date: | April 1998 |
| Formats: | txt html json |
| Obsoleted by: | RFC 7567 |
| Updated by: | RFC 7141 |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 2309 |
|
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 |
| |
| Authors: | K. Holtman. |
| Date: | April 1998 |
| Formats: | txt html json |
| Status: | HISTORIC |
| DOI: | 10.17487/RFC 2310 |
|
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 |
| |
| Authors: | S. Dusse, P. Hoffman, B. Ramsdell, L. Lundblade, L. Repka. |
| Date: | March 1998 |
| Formats: | txt html json |
| Status: | HISTORIC |
| DOI: | 10.17487/RFC 2311 |
|
This document describes a protocol for adding cryptographic signature and encryption services to MIME data. This memo provides information for the Internet community. It does not specify an Internet standard of any kind. |
|
| |
| RFC 2312 | S/MIME Version 2 Certificate Handling |
| |
| Authors: | S. Dusse, P. Hoffman, B. Ramsdell, J. Weinstein. |
| Date: | March 1998 |
| Formats: | txt json html |
| Status: | HISTORIC |
| DOI: | 10.17487/RFC 2312 |
|
This memo describes the mechanisms S/MIME uses to create and validate keys using certificates. This memo provides information for the Internet community. It does not specify an Internet standard of any kind. |
|
| |
| RFC 2313 | PKCS #1: RSA Encryption Version 1.5 |
| |
|
|
This document describes a method for encrypting data using the RSA public-key cryptosystem. This memo provides information for the Internet community. It does not specify an Internet standard of any kind. |
|
| |
| RFC 2314 | PKCS #10: Certification Request Syntax Version 1.5 |
| |
|
|
This document describes a syntax for certification requests. This memo provides information for the Internet community. It does not specify an Internet standard of any kind. |
|
| |
| RFC 2315 | PKCS #7: Cryptographic Message Syntax Version 1.5 |
| |
| Authors: | B. Kaliski. |
| Date: | March 1998 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 2315 |
|
This document describes a general syntax for data that may have cryptography applied to it, such as digital signatures and digital envelopes. This memo provides information for the Internet community. It does not specify an Internet standard of any kind. |
|
| |
| RFC 2316 | Report of the IAB Security Architecture Workshop |
| |
| Authors: | S. Bellovin. |
| Date: | April 1998 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 2316 |
|
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. This memo provides information for the Internet community. It does not specify an Internet standard of any kind. |
|
| |
| RFC 2317 | Classless IN-ADDR.ARPA delegation |
| |
| Authors: | H. Eidnes, G. de Groot, P. Vixie. |
| Date: | March 1998 |
| Formats: | txt json html |
| Also: | BCP 0020 |
| Status: | BEST CURRENT PRACTICE |
| DOI: | 10.17487/RFC 2317 |
|
This document describes a way to do IN-ADDR.ARPA delegation on non-octet boundaries for address spaces covering fewer than 256 addresses. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. |
|
| |
| RFC 2318 | The text/css Media Type |
| |
| Authors: | H. Lie, B. Bos, C. Lilley. |
| Date: | March 1998 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 2318 |
|
Cascading Style Sheets (CSS) is a style sheet language for the WorldWide 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 |
| |
| Authors: | KOI8-U Working Group. |
| Date: | April 1998 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 2319 |
|
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 allRussian letters and extends it with four Ukrainian letters which locations are compliant with ISO-IR-111. The official site of KOI8-UWorking Group is http://www.net.ua. |
|
| |
| RFC 2320 | Definitions of Managed Objects for Classical IP and ARP Over ATM Using SMIv2 (IPOA-MIB) |
| |
| Authors: | M. Greene, J. Luciani, K. White, T. Kuo. |
| Date: | April 1998 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 2320 |
|
The purpose of this memo is to define the Management Information Base(MIB) for supporting Classical IP and ARP over ATM as specified inClassical IP and ARP over ATM, refer to reference [3]. Support of anATM 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 theSimple Network Management Protocol Version (refer to RFC 1902, reference [1]). |
|
| |
| RFC 2321 | RITA -- The Reliable Internetwork Troubleshooting Agent |
| |
| Authors: | A. Bressen. |
| Date: | 1 April 1998 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 2321 |
|
A Description of the usage of Nondeterministic Troubleshooting andDiagnostic Methodologies as applied to today's complex nondeterministic networks and environments. |
|
| |
| RFC 2322 | Management of IP numbers by peg-dhcp |
| |
| Authors: | K. van den Hout, A. Koopal, R. van Mook. |
| Date: | 1 April 1998 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 2322 |
|
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. This memo provides information for the Internet community. It does not specify an Internet standard of any kind. |
|
| |
| RFC 2323 | IETF Identification and Security Guidelines |
| |
| Authors: | A. Ramos. |
| Date: | 1 April 1998 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 2323 |
|
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 memo provides information for the Internet community. It does not specify an Internet standard of any kind. |
|
| |
| RFC 2324 | Hyper Text Coffee Pot Control Protocol (HTCPCP/1.0) |
| |
|
|
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 |
| |
| Authors: | M. Slavitch. |
| Date: | 1 April 1998 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 2325 |
|
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. This memo provides information for the Internet community. It does not specify an Internet standard of any kind. |
|
| |
| RFC 2326 | Real Time Streaming Protocol (RTSP) |
| |
| Authors: | H. Schulzrinne, A. Rao, R. Lanphier. |
| Date: | April 1998 |
| Formats: | txt json html |
| Obsoleted by: | RFC 7826 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 2326 |
|
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 |
| |
|
|
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 SessionControl (MMUSIC) working group of the Internet Engineering TaskForce. 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 |
| |
|
|
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 inAppendix G. All differences are backward-compatible in nature.
Implementations of this memo and of RFCs 2178, 1583, and 1247 will interoperate.
Please send comments to ospf@gated.cornell.edu. |
|
| |
| RFC 2329 | OSPF Standardization Report |
| |
| Authors: | J. Moy. |
| Date: | April 1998 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 2329 |
|
This memo documents how the requirements for advancing a routing protocol to Full Standard, set out in [Ref2], have been met forOSPFv2.
Please send comments to ospf@gated.cornell.edu. |
|
| |
| RFC 2330 | Framework for IP Performance Metrics |
| |
|
|
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. This memo provides information for the Internet community. It does not specify an Internet standard of any kind. |
|
| |
| RFC 2331 | ATM Signalling Support for IP over ATM - UNI Signalling 4.0 Update |
| |
| Authors: | M. Maher. |
| Date: | April 1998 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 2331 |
|
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 UNISignalling 4.0 are Available Bit Rate signalling and traffic parameter negotiation. This memo highlights the features of UNISignalling 4.0 that provide IP entities capabilities for requestingATM 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 implementedIP 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) |
| |
| Authors: | J. Luciani, D. Katz, D. Piscitello, B. Cole, N. Doraswamy. |
| Date: | April 1998 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 2332 |
|
This document describes the NBMA Next Hop Resolution Protocol (NHRP).NHRP can be used by a source station (host or router) connected to aNon-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 NBMAAddress Resolution Protocol (NARP) documented in [1].
Operation of NHRP as a means of establishing a transit path across anNBMA subnetwork between two routers will be addressed in a separate document (see [13]). |
|
| |
| RFC 2333 | NHRP Protocol Applicability Statement |
| |
| Authors: | D. Cansever. |
| Date: | April 1998 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 2333 |
|
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) |
| |
| Authors: | J. Luciani, G. Armitage, J. Halpern, N. Doraswamy. |
| Date: | April 1998 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 2334 |
|
This document describes the Server Cache Synchronization Protocol(SCSP) and is written in terms of SCSP's use within Non BroadcastMultiple 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 |
| |
| Authors: | J. Luciani. |
| Date: | April 1998 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 2335 |
|
This document describes a method for distributing an NHRP service within a LIS [1]. This method uses the Server Cache SynchronizationProtocol (SCSP) [2] to synchronize the client information databases held by NHRP Servers (NHSs) within a LIS. |
|
| |
| RFC 2336 | Classical IP and ARP over ATM to NHRP Transition |
| |
| Authors: | J. Luciani. |
| Date: | July 1998 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 2336 |
|
This document describes methods and procedures for the graceful transition from an ATMARP LIS[1] to an NHRP LIS[2] network model overATM. |
|
| |
| RFC 2337 | Intra-LIS IP multicast among routers over ATM using Sparse Mode PIM |
| |
| Authors: | D. Farinacci, D. Meyer, Y. Rekhter. |
| Date: | April 1998 |
| Formats: | txt json html |
| Status: | EXPERIMENTAL |
| DOI: | 10.17487/RFC 2337 |
|
This document describes how intra-LIS IP multicast can be efficiently supported among routers over ATM without using the Multicast Address Resolution Server (MARS). This memo defines an Experimental Protocol for the Internet community. It does not specify an Internet standard of any kind. Discussion and suggestions for improvement are requested. |
|
| |
| RFC 2338 | Virtual Router Redundancy Protocol |
| |
| Authors: | S. Knight, D. Weaver, D. Whipple, R. Hinden, D. Mitzel, P. Hunt, P. Higginson, M. Shand, A. Lindem. |
| Date: | April 1998 |
| Formats: | txt html json |
| Obsoleted by: | RFC 3768 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 2338 |
|
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 aLAN. 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 |
| |
| Authors: | in the matter of NFS V.4 Protocols. The Internet Society, Sun Microsystems. |
| Date: | May 1998 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 2339 |
|
This Request for Comments records an agreement between SunMicrosystems, Inc. and the Internet Society to permit the flow ofSun'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 |
| |
| Authors: | B. Jamoussi, D. Jamieson, D. Williston, S. Gabe. |
| Date: | May 1998 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 2340 |
|
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" |
| |
| Authors: | A. Valencia, M. Littlewood, T. Kolar. |
| Date: | May 1998 |
| Formats: | txt json html |
| Status: | HISTORIC |
| DOI: | 10.17487/RFC 2341 |
|
Virtual dial-up allows many separate and autonomous protocol domains to share common access infrastructure including modems, AccessServers, and ISDN routers. Previous RFCs have specified protocols for supporting IP dial-up via SLIP [1] and multiprotocol dial-up viaPPP [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 |
| |
|
|
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. [STANDARDS- TRACK] |
|
| |
| RFC 2343 | RTP Payload Format for Bundled MPEG |
| |
| Authors: | M. Civanlar, G. Cash, B. Haskell. |
| Date: | May 1998 |
| Formats: | txt html json |
| Status: | EXPERIMENTAL |
| DOI: | 10.17487/RFC 2343 |
|
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 |
| |
|
|
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 |
| |
| Authors: | J. Klensin, T. Wolf, G. Oglesby. |
| Date: | May 1998 |
| Formats: | txt json html |
| Status: | EXPERIMENTAL |
| DOI: | 10.17487/RFC 2345 |
|
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 |
| |
| Authors: | J. Palme. |
| Date: | May 1998 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 2346 |
|
Certain text formats, for example Postscript (MIME-Type: application/postscript; file extension .ps) and Portable DocumentFormat (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 theInternet, 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 usingU.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 |
| |
|
|
The Trivial File Transfer Protocol [1] 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 |
| |
|
|
The Trivial File Transfer Protocol [1] 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 |
| |
|
|
The Trivial File Transfer Protocol [1] 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 |
| |
|
|
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 SecurityIncident 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 |
| |
| Authors: | A. Robert. |
| Date: | May 1998 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 2351 |
|
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 |
| |
|
|
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. This memo provides information for the Internet community. It does not specify an Internet standard of any kind. |
|
| |
| RFC 2353 | APPN/HPR in IP Networks APPN Implementers' Workshop Closed Pages Document |
| |
| Authors: | G. Dudley. |
| Date: | May 1998 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 2353 |
|
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. This memo provides information for the Internet community. It does not specify an Internet standard of any kind. |
|
| |
| RFC 2354 | Options for Repair of Streaming Media |
| |
| Authors: | C. Perkins, O. Hodson. |
| Date: | June 1998 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 2354 |
|
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 |
| |
|
|
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, theSYSREQ 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[1]. |
|
| |
| RFC 2356 | Sun's SKIP Firewall Traversal for Mobile IP |
| |
| Authors: | G. Montenegro, V. Gupta. |
| Date: | June 1998 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 2356 |
|
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 |
| |
| Authors: | A. Mankin, A. Romanow, S. Bradner, V. Paxson. |
| Date: | June 1998 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 2357 |
|
This memo describes the procedures and criteria for reviewing reliable multicast protocols within the Transport Area (TSV) of theIETF. 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 [RMMinutes1997].
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 |
| |
|
|
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 theEthernet-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 theIEEE, 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 ofEthernet technology. In the future, this document might be revised, or new documents might be issued by the Ethernet Interfaces and HubMIB Working Group, in order to reflect the evolution of Ethernet technology. |
|
| |
| RFC 2359 | IMAP4 UIDPLUS extension |
| |
|
|
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. [STANDARDS-TRACK] |
|
| |
| RFC 2360 | Guide for Internet Standards Writers |
| |
|
|
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 withRFC 2223, "Instructions to RFC Authors". |
|
| |
| RFC 2361 | WAVE and AVI Codec Registries |
| |
| Authors: | E. Fleischman. |
| Date: | June 1998 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 2361 |
|
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 WAVERegistry 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 |
| |
| Authors: | D. Estrin, D. Farinacci, A. Helmy, D. Thaler, S. Deering, M. Handley, V. Jacobson, C. Liu, P. Sharma, L. Wei. |
| Date: | June 1998 |
| Formats: | txt html json |
| Obsoletes: | RFC 2117 |
| Obsoleted by: | RFC 4601, RFC 5059 |
| Status: | EXPERIMENTAL |
| DOI: | 10.17487/RFC 2362 |
|
This document describes a protocol for efficiently routing to multicast groups that may span wide-area (and inter-domain) internets. This memo defines an Experimental Protocol for the Internet community. It does not specify an Internet standard of any kind. Discussion and suggestions for improvement are requested. |
|
| |
| RFC 2363 | PPP Over FUNI |
| |
| Authors: | G. Gross, M. Kaycee, A. Li, A. Malis, J. Stephens. |
| Date: | July 1998 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 2363 |
|
The Point-to-Point Protocol (PPP) [1] 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 |
| |
| Authors: | G. Gross, M. Kaycee, A. Li, A. Malis, J. Stephens. |
| Date: | July 1998 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 2364 |
|
The Point-to-Point Protocol (PPP) [1] 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 |
| |
|
|
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 [RFC1884] and IPv4 multicast address classes. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. |
|
| |
| RFC 2366 | Definitions of Managed Objects for Multicast over UNI 3.0/3.1 based ATM Networks |
| |
|
|
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 UNI3.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 |
| |
| Authors: | D. McDonald, C. Metz, B. Phan. |
| Date: | July 1998 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 2367 |
|
A generic key management API that can be used not only for IPSecurity [Atk95a] [Atk95b] [Atk95c] but also for other network security services is presented in this document. Version 1 of thisAPI was implemented inside 4.4-Lite BSD as part of the U. S. NavalResearch 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], aPhoturis daemon, or a SKIP certificate discovery protocol daemon). |
|
| |
| RFC 2368 | The mailto URL scheme |
| |
|
|
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', andRFC 1808, 'Relative Uniform Resource Locators'. The syntax of'mailto' URLs from RFC 1738 is extended to allow creation of more RFC822 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 |
| |
| Authors: | G. Neufeld, J. Baer. |
| Date: | July 1998 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 2369 |
|
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 [RFC2368]) 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 areList-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 |
| |
|
|
This memo defines enhancements to the OSPF protocol to support a new class of link-state advertisements (LSA) called Opaque LSAs. [STANDARDS-TRACK] |
|
| |
| RFC 2371 | Transaction Internet Protocol Version 3.0 |
| |
| Authors: | J. Lyon, K. Evans, J. Klein. |
| Date: | July 1998 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 2371 |
|
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 |
| |
| Authors: | K. Evans, J. Klein, J. Lyon. |
| Date: | July 1998 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 2372 |
|
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 |
| |
|
|
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 node's required addresses. |
|
| |
| RFC 2374 | An IPv6 Aggregatable Global Unicast Address Format |
| |
|
|
This document defines an IPv6 aggregatable global unicast address format for use in the Internet. [STANDARDS-TRACK] |
|
| |
| RFC 2375 | IPv6 Multicast Address Assignments |
| |
| Authors: | R. Hinden, S. Deering. |
| Date: | July 1998 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 2375 |
|
This document defines the initial assignment of IPv6 multicast addresses. This memo provides information for the Internet community. It does not specify an Internet standard of any kind. |
|
| |
| RFC 2376 | XML Media Types |
| |
|
|
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 WorldWide 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 |
| |
| Authors: | A. Grimstad, R. Huber, S. Sataluri, M. Wahl. |
| Date: | September 1998 |
| Formats: | txt html json |
| Updated by: | RFC 4519 |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 2377 |
|
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 |
| |
| Authors: | R. Hedberg, P. Pomes. |
| Date: | September 1998 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 2378 |
|
The Ph Nameserver from the Computing and Communications ServicesOffice (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 |
| |
|
|
This memo presents specific implementation guidelines for runningRSVP 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 |
| |
| Authors: | L. Berger. |
| Date: | August 1998 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 2380 |
|
This memo presents specific implementation requirements for runningRSVP 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 overATM. |
|
| |
| RFC 2381 | Interoperation of Controlled-Load Service and Guaranteed Service with ATM |
| |
| Authors: | M. Garrett, M. Borden. |
| Date: | August 1998 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 2381 |
|
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 IPIntegrated 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 |
| |
| Authors: | E. Crawley, Ed., L. Berger, S. Berson, F. Baker, M. Borden, J. Krawczyk. |
| Date: | August 1998 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 2382 |
|
This document outlines the issues and framework related to providingIP 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 |
| |
| Authors: | M. Suzuki. |
| Date: | August 1998 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 2383 |
|
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 |
| |
| Authors: | R. Gellens. |
| Date: | August 1998 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 2384 |
|
This memo defines a URL scheme for referencing a POP mailbox. [STANDARDS-TRACK] |
|
| |
| RFC 2385 | Protection of BGP Sessions via the TCP MD5 Signature Option |
| |
|
|
This memo describes a TCP extension to enhance security for BGP. It defines a new TCP option for carrying an MD5 [RFC1321] digest in aTCP 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 |
| |
| Authors: | E. Crawley, R. Nair, B. Rajagopalan, H. Sandick. |
| Date: | August 1998 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 2386 |
|
This document describes some of the QoS-based routing issues and requirements, and proposes a framework for QoS-based routing in the Internet. This memo provides information for the Internet community. It does not specify an Internet standard of any kind. |
|
| |
| RFC 2387 | 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 2388 | Returning Values from Forms: multipart/form-data |
| |
|
|
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. [STANDARDS-TRACK] |
|
| |
| RFC 2389 | Feature negotiation mechanism for the File Transfer Protocol |
| |
|
|
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 |
| |
| Authors: | T. Bradley, C. Brown, A. Malis. |
| Date: | September 1998 |
| Formats: | txt json html |
| Obsoletes: | RFC 1293 |
| Status: | DRAFT STANDARD |
| DOI: | 10.17487/RFC 2390 |
|
This memo describes additions to ARP that will allow a station to request a protocol address corresponding to a given hardware address. [STANDARDS-TRACK] |
|
| |
| RFC 2391 | Load Sharing using IP Network Address Translation (LSNAT) |
| |
| Authors: | P. Srisuresh, D. Gan. |
| Date: | August 1998 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 2391 |
|
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 |
| |
|
|
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) |
| |
| Authors: | A. Shacham, R. Monsour, R. Pereira, M. Thomas. |
| Date: | December 1998 |
| Formats: | txt html json |
| Obsoleted by: | RFC 3173 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 2393 |
|
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 |
| |
| Authors: | R. Pereira. |
| Date: | December 1998 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 2394 |
|
This document describes a compression method based on the DEFLATE compression algorithm. This document defines the application of theDEFLATE algorithm to the IP Payload Compression Protocol. |
|
| |
| RFC 2395 | IP Payload Compression Using LZS |
| |
| Authors: | R. Friend, R. Monsour. |
| Date: | December 1998 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 2395 |
|
This document describes a compression method based on the LZS compression algorithm. This document defines the application of theLZS 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 |
| |
|
|
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 |
| |
| Authors: | L. Masinter. |
| Date: | August 1998 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 2397 |
|
A new URL scheme, "data", is defined. It allows inclusion of small data items as "immediate" data, as if it had been included externally. [STANDARDS-TRACK] |
|
| |
| RFC 2398 | Some Testing Tools for TCP Implementors |
| |
|
|
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. This memo provides information for the Internet community. It does not specify an Internet standard of any kind. |
|
| |
| RFC 2399 | Request for Comments Summary |
| |
| Authors: | A. Ramos. |
| Date: | January 1999 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 2399 |
|
|
|
