|
|
|
RFC Home |
Full RFC Index |
Recent RFCs |
RFC Standards |
Best Current Practice |
RFC Errata |
1 April RFC |
|
|
||||||
| RFC 2501 |
 Mobile Ad hoc Networking (MANET): Routing Protocol Performance Issues and Evaluation Considerations
|
|
Summary Publication date: Jan 1999 This memo first describes the characteristics of Mobile Ad hoc Networks (MANETs), and their idiosyncrasies with respect to traditional, hardwired packet networks. It then discusses the effect these differences have on the design and evaluation of network control protocols with an emphasis on routing performance evaluation considerations. |
| RFC 2502 |
Limitations of Internet Protocol Suite for Distributed Simulation the Large Multicast Environment
|
|
Summary Publication date: Feb 1999 The Large-Scale Multicast Applications (LSMA) working group was chartered to produce documents aimed at a consensus based development of the Internet protocols to support large scale multicast applications including real-time distributed simulation. This memo defines services that LSMA has found to be required, and aspects of the Internet protocols that LSMA has found to need further development in order to meet these requirements. |
| RFC 2503 |
MIME Types for Use with the ISO ILL Protocol
|
|
Summary Publication date: Feb 1999 This memorandum describes a set of MIME types for use with the ISO Interlibrary Loan Protocol (ISO 10160/10161). Two MIME types are specified below. The first is a media type to carry objects which are BER [BER] encoded ISO ILL Protocol Data Units (PDU's). BER are the basic Encoding Rules used to encode PDU's which have been described using ASN.1 (Abstract Syntax Notation 1) [ASN.1] . The second is for use with the associated document delivery instructions. Document Delivery Instructions (DDI) is an emerging protocol which enables automatic electronic delivery of items. It allows a request management system (which might have received a request for an item via the ISO Interlibrary Loan Protocol (ISO 10160/10161)) to pass details of the request, item, and delivery, to a delivery module, and to receive back reports on the delivery process or arrival of an item. It is currently being submitted to the ISO TC46/SC4/WG4 committee for approval as an ISO standard. |
| RFC 2504 |
Users' Security Handbook
|
|
Summary Publication date: Feb 1999 The Users' Security Handbook is the companion to the Site Security Handbook (SSH). It is intended to provide users with the information they need to help keep their networks and systems secure. |
| RFC 2505 |
Anti-Spam Recommendations for SMTP MTAs
|
|
Summary Publication date: Feb 1999 This memo gives a number of implementation recommendations for SMTP, [1], MTAs (Mail Transfer Agents, e.g. sendmail, [8]) to make them more capable of reducing the impact of spam(*). The intent is that these recommendations will help clean up the spam situation, if applied on enough SMTP MTAs on the Internet, and that they should be used as guidelines for the various MTA vendors. We are fully aware that this is not the final solution, but if these recommendations were included, and used, on all Internet SMTP MTAs, things would improve considerably and give time to design a more long term solution. The Future Work section suggests some ideas that may be part of such a long term solution. It might, though, very well be the case that the ultimate solution is social, political, or legal, rather than technical in nature. The implementor should be aware of the increased risk of denial of service attacks that several of the proposed methods might lead to. For example, increased number of queries to DNS servers and increased size of logfiles might both lead to overloaded systems and system crashes during an attack. |
| RFC 2506 |
Media Feature Tag Registration Procedure
|
|
Summary Publication date: Mar 1999 Recent Internet applications, such as the World Wide Web, tie together a great diversity in data formats, client and server platforms, and communities. This has created a need for media feature descriptions and negotiation mechanisms in order to identify and reconcile the form of information to the capabilities and preferences of the parties involved. Extensible media feature identification and negotiation mechanisms require a common vocabulary in order to positively identify media features. A registration process and authority for media features is defined with the intent of sharing this vocabulary between communicating parties. In addition, a URI tree is defined to enable sharing of media feature definitions without registration. This document defines a registration procedure which uses the Internet Assigned Numbers Authority (IANA) as a central registry for the media feature vocabulary. |
| RFC 2507 |
IP Header Compression
|
|
Summary Publication date: Feb 1999 This document describes how to compress multiple IP headers and TCP and UDP headers per hop over point to point links. The methods can be applied to of IPv6 base and extension headers, IPv4 headers, TCP and UDP headers, and encapsulated IPv6 and IPv4 headers. Headers of typical UDP or TCP packets can be compressed down to 4-7 octets including the 2 octet UDP or TCP checksum. This largely removes the negative impact of large IP headers and allows efficient use of bandwidth on low and medium speed links. The compression algorithms are specifically designed to work well over links with nontrivial packet-loss rates. Several wireless and modem technologies result in such links. |
| RFC 2508 |
Compressing IP/UDP/RTP Headers for Low-Speed Serial Links
|
|
Summary Publication date: Feb 1999 This document describes a method for compressing the headers of IP/UDP/RTP datagrams to reduce overhead on low-speed serial links. In many cases, all three headers can be compressed to 2-4 bytes. Comments are solicited and should be addressed to the working group mailing list rem-conf@es.net and/or the author(s). |
| RFC 2509 |
IP Header Compression over PPP
|
|
Summary Publication date: Feb 1999 This document describes an option for negotiating the use of header compression on IP datagrams transmitted over the Point-to-Point Protocol [RFC 1661]. It defines extensions to the PPP Control Protocols for IPv4 and IPv6 [RFC 1332, RFC 2023]. Header compression may be applied to IPv4 and IPv6 datagrams in combination with TCP, UDP and RTP transport protocols as specified in [IPHC] and [CRTP]. |
| RFC 2510 |
Internet X.509 Public Key Infrastructure Certificate Management Protocols
|
|
Summary Publication date: Mar 1999 This document describes the Internet X.509 Public Key Infrastructure (PKI) Certificate Management Protocols. Protocol messages are defined for all relevant aspects of certificate creation and management. Note that "certificate" in this document refers to an X.509v3 Certificate as defined in [COR95, X509-AM]. |
| RFC 2511 |
Internet X.509 Certificate Request Message Format
|
|
Summary Publication date: Mar 1999 This document describes the Certificate Request Message Format (CRMF). This syntax is used to convey a request for a certificate to a Certification Authority (CA) (possibly via a Registration Authority (RA)) for the purposes of X.509 certificate production. The request will typically include a public key and associated registration information. |
| RFC 2512 |
Accounting Information for ATM Networks
|
|
Summary Publication date: Feb 1999 This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. A separate memo [16] defines managed objects, in a manner independent of the type of network, for controlling the selection, collection and storage of accounting information into files for later retrieval via a file transfer protocol. This memo defines a set of ATM-specific accounting information which can be collected for connections on ATM networks. |
| RFC 2513 |
Managed Objects for Controlling the Collection and Storage of Accounting Information for Connection-Oriented Networks
|
|
Summary Publication date: Feb 1999 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 used for controlling the collection and storage of accounting information for connection- oriented networks such as ATM. The accounting data is collected into files for later retrieval via a file transfer protocol. For information on data which can be collected for ATM networks, see [19]. |
| RFC 2514 |
Definitions of Textual Conventions and OBJECT-IDENTITIES for ATM Management
|
|
Summary Publication date: Feb 1999 This memo describes Textual Conventions and OBJECT-IDENTITIES used for managing ATM-based interfaces, devices, networks and services. |
| RFC 2515 |
Definitions of Managed Objects for ATM Management
|
|
Summary Publication date: Feb 1999 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 objects used for managing ATM-based interfaces, devices, networks and services. This memo replaces RFC 1695 [24]. Changes relative to RFC 1695 are summarized in the MIB module's REVISION clause. Textual Conventions used in this MIB are defined in [6] and [19]. |
| RFC 2516 |
A Method for Transmitting PPP Over Ethernet (PPPoE)
|
|
Summary Publication date: Feb 1999 The Point-to-Point Protocol (PPP) [1] provides a standard method for transporting multi-protocol datagrams over point-to-point links. This document describes how to build PPP sessions and encapsulate PPP packets over Ethernet. |
| RFC 2517 |
Building Directories from DNS: Experiences from WWWSeeker
|
|
Summary Publication date: Feb 1999 There has been much discussion and several documents written about the need for an Internet Directory. Recently, this discussion has focused on ways to discover an organization's domain name without relying on use of DNS as a directory service. This memo discusses lessons that were learned during InterNIC Directory and Database Services' development and operation of WWWSeeker, an application that finds a web site given information about the name and location of an organization. The back end database that drives this application was built from information obtained from domain registries via WHOIS and other protocols. We present this information to help future implementors avoid some of the blind alleys that we have already explored. This work builds on the Netfind system that was created by Mike Schwartz and his team at the University of Colorado at Boulder [1]. |
| RFC 2518 |
HTTP Extensions for Distributed Authoring -- WEBDAV
|
|
Summary Publication date: Feb 1999 This document specifies a set of methods, headers, and content-types ancillary to HTTP/1.1 for the management of resource properties, creation and management of resource collections, namespace manipulation, and resource locking (collision avoidance). |
| RFC 2519 |
A Framework for Inter-Domain Route Aggregation
|
|
Summary Publication date: Feb 1999 This document presents a framework for inter-domain route aggregation and shows an example router configuration which 'implements' this framework. This framework is flexible and scales well as it emphasizes the philosophy of aggregation by the source, both within routing domains as well as towards upstream providers, and it also strongly encourages the use of the 'no-export' BGP community to balance the provider-subscriber need for more granular routing information with the Internet's need for scalable inter-domain routing. |
| RFC 2520 |
NHRP with Mobile NHCs
|
|
Summary Publication date: Feb 1999 This document describes an extension to NHRP [1] which would allow Mobile NHCs to perform a registration with and attach to an NHS in their home LIS in an authenticated manner. As described in this document, Mobile NHCs are NHCs which are not configured with enough information to find a specific serving NHS in their home LIS, but which have a mechanism to find an NHS (which may or may not be a serving NHS) to which they will attach. As described in [1], an NHC may attach to a 'surrogate' NHS by using a mechanism such as an anycast address. In this case, the NHC may use the surrogate NHS to send a NHRP Registration Request toward the NHC's home LIS where a serving NHS resides. However, as defined in [1], packet authentication is performed on a hop by hop basis. In the mobile NHC case, it is not practical for the mobile NHC be in a security relationship with every surrogate NHS, thus it is presumably desirable to have some form of end to end only authentication for the case of a mobile NHC's registration. This document describes an authentication extension for NHRP which has such end to end only semantics. |
| RFC 2521 |
ICMP Security Failures Messages
|
|
Summary Publication date: Mar 1999 This document specifies ICMP messages for indicating failures when using IP Security Protocols (AH and ESP). |
| RFC 2522 |
Photuris: Session-Key Management Protocol
|
|
Summary Publication date: Mar 1999 Photuris is a session-key management protocol intended for use with the IP Security Protocols (AH and ESP). This document defines the basic protocol mechanisms. |
| RFC 2523 |
Photuris: Extended Schemes and Attributes
|
|
Summary Publication date: Mar 1999 Photuris is a session-key management protocol. Extensible Exchange- Schemes are provided to enable future implementation changes without affecting the basic protocol. Additional authentication attributes are included for use with the IP Authentication Header (AH) or the IP Encapsulating Security Protocol (ESP). Additional confidentiality attributes are included for use with ESP. |
| RFC 2524 |
Neda's Efficient Mail Submission and Delivery (EMSD) Protocol Specification Version 1.3
|
|
Summary Publication date: Feb 1999 This document specifies the protocol and format encodings for Efficient Mail Submission and Delivery (EMSD). EMSD is a messaging protocol that is highly optimized for submission and delivery of short Internet mail messages. EMSD is designed to be a companion to existing Internet mail protocols. This specification narrowly focuses on submission and delivery of short mail messages with a clear emphasis on efficiency. EMSD is designed specifically with wireless network (e.g., CDPD, Wireless-IP, Mobile-IP) usage in mind. EMSD is designed to be a natural enhancement to the mainstream of Internet mail protocols when efficiency in mail submission and mail delivery are important. As such, EMSD is anticipated to become an initial basis for convergence of Internet Mail and IP-based Two-Way Paging. The reliability requirement for message submission and message delivery in EMSD are the same as existing email protocols. EMSD protocol accomplishes reliable connectionless mail submission and delivery services on top of Efficient Short Remote Operations (ESRO) protocols as specified in RFC 2188 [1]. Most existing Internet mail protocols are not efficient. Most existing Internet mail protocols are designed with simplicity and continuity with SMTP traditions as two primary requirements. EMSD is designed with efficiency as a primary requirement. The early use of EMSD in the wireless environment is manifested as IP-based Two-Way Paging services. The efficiency of this protocol also presents significant benefits for large centrally operated Internet mail service providers. |
| RFC 2525 |
Known TCP Implementation Problems
|
|
Summary Publication date: Mar 1999 This memo catalogs a number of known TCP implementation problems. The goal in doing so is to improve conditions in the existing Internet by enhancing the quality of current TCP/IP implementations. It is hoped that both performance and correctness issues can be resolved by making implementors aware of the problems and their solutions. In the long term, it is hoped that this will provide a reduction in unnecessary traffic on the network, the rate of connection failures due to protocol errors, and load on network servers due to time spent processing both unsuccessful connections and retransmitted data. This will help to ensure the stability of the global Internet. |
| RFC 2526 |
Reserved IPv6 Subnet Anycast Addresses
|
|
Summary Publication date: Mar 1999 The IP Version 6 addressing architecture defines an "anycast" address as an IPv6 address that is assigned to one or more network interfaces (typically belonging to different nodes), with the property that a packet sent to an anycast address is routed to the "nearest" interface having that address, according to the routing protocols' measure of distance. This document defines a set of reserved anycast addresses within each subnet prefix, and lists the initial allocation of these reserved subnet anycast addresses. |
| RFC 2527 |
Internet X.509 Public Key Infrastructure Certificate Policy and Certification Practices Framework
|
|
Summary Publication date: Mar 1999 This document presents a framework to assist the writers of certificate policies or certification practice statements for certification authorities and public key infrastructures. In particular, the framework provides a comprehensive list of topics that potentially (at the writer's discretion) need to be covered in a certificate policy definition or a certification practice statement. |
| RFC 2528 |
Internet X.509 Public Key Infrastructure Representation of Key Exchange Algorithm (KEA) Keys in Internet X.509 Public Key Infrastructure Certificates
|
|
Summary Publication date: Mar 1999 The Key Exchange Algorithm (KEA) is a classified algorithm for exchanging keys. This specification profiles the format and semantics of fields in X.509 V3 certificates containing KEA keys. The specification addresses the subjectPublicKeyInfo field and the keyUsage extension. |
| RFC 2529 |
Transmission of IPv6 over IPv4 Domains without Explicit Tunnels
|
|
Summary Publication date: Mar 1999 This memo specifies the frame format for transmission of IPv6 [IPV6] packets and the method of forming IPv6 link-local addresses over IPv4 domains. It also specifies the content of the Source/Target Link- layer Address option used in the Router Solicitation, Router Advertisement, Neighbor Solicitation, and Neighbor Advertisement and Redirect messages, when those messages are transmitted on an IPv4 multicast network. The motivation for this method is to allow isolated IPv6 hosts, located on a physical link which has no directly connected IPv6 router, to become fully functional IPv6 hosts by using an IPv4 domain that supports IPv4 multicast as their virtual local link. It uses IPv4 multicast as a "virtual Ethernet". |
| RFC 2530 |
Indicating Supported Media Features Using Extensions to DSN and MDN
|
|
Summary Publication date: Mar 1999 There is a need in Internet mail and Internet fax for a recipient to indicate the media features it supports so that messages can be generated by senders without exceeding the recipient's abilities. This memo describes a format for generating Message Disposition Notifications [RFC 2298] and Delivery Status Notifications [RFC 1894] which contain such information. This information can be used by senders to avoid exceeding the recipient's capabilities when sending subsequent messages. |
| RFC 2531 |
Content Feature Schema for Internet Fax
|
|
Summary Publication date: Mar 1999 This document defines a content feature schema that is a profile of the media feature registration mechanisms [1,2,3] for use in performing capability identification between extended Internet fax systems [5]. This document does not describe any specific mechanisms for communicating capability information, but does presume that any such mechanisms will transfer textual values. It specifies a textual format to be used for describing Internet fax capability information. |
| RFC 2532 |
Extended Facsimile Using Internet Mail
|
|
Summary Publication date: Mar 1999 This document describes extensions to "Simple Mode of Facsimile Using Internet Mail" [RFC 2305] and describes additional features, including transmission of enhanced document characteristics (higher resolution, color) and confirmation of delivery and processing. These additional features are designed to provide the highest level of interoperability with the existing and future standards-compliant email infrastructure and mail user agents, while providing a level of service that approximates the level currently enjoyed by fax users. |
| RFC 2533 |
A Syntax for Describing Media Feature Sets
|
|
Summary Publication date: Mar 1999 A number of Internet application protocols have a need to provide content negotiation for the resources with which they interact [1]. A framework for such negotiation is described in [2], part of which is a way to describe the range of media features which can be handled by the sender, recipient or document transmission format of a message. A format for a vocabulary of individual media features and procedures for feature registration are presented in [3]. This document introduces and describes a syntax that can be used to define feature sets which are formed from combinations and relations involving individual media features. Such feature sets are used to describe the media feature handling capabilities of message senders, recipients and file formats. An algorithm for feature set matching is also described here. |
| RFC 2534 |
Media Features for Display, Print, and Fax
|
|
Summary Publication date: Mar 1999 This specification defines some common media features for describing image resolution, size, color, and image representation methods that are common to web browsing, printing, and facsimile applications. These features are registered for use within the framework of [REG]. |
| RFC 2535 |
Domain Name System Security Extensions
|
|
Summary Publication date: Mar 1999 Extensions to the Domain Name System (DNS) are described that provide data integrity and authentication to security aware resolvers and applications through the use of cryptographic digital signatures. These digital signatures are included in secured zones as resource records. Security can also be provided through non-security aware DNS servers in some cases. The extensions provide for the storage of authenticated public keys in the DNS. This storage of keys can support general public key distribution services as well as DNS security. The stored keys enable security aware resolvers to learn the authenticating key of zones in addition to those for which they are initially configured. Keys associated with DNS names can be retrieved to support other protocols. Provision is made for a variety of key types and algorithms. In addition, the security extensions provide for the optional authentication of DNS protocol transactions and requests. This document incorporates feedback on RFC 2065 from early implementers and potential users. |
| RFC 2536 |
DSA KEYs and SIGs in the Domain Name System (DNS)
|
|
Summary Publication date: Mar 1999 A standard method for storing US Government Digital Signature Algorithm keys and signatures in the Domain Name System is described which utilizes DNS KEY and SIG resource records. |
| RFC 2537 |
RSA/MD5 KEYs and SIGs in the Domain Name System (DNS)
|
|
Summary Publication date: Mar 1999 A standard method for storing RSA keys and and RSA/MD5 based signatures in the Domain Name System is described which utilizes DNS KEY and SIG resource records. |
| RFC 2538 |
Storing Certificates in the Domain Name System (DNS)
|
|
Summary Publication date: Mar 1999 Cryptographic public key are frequently published and their authenticity demonstrated by certificates. A CERT resource record (RR) is defined so that such certificates and related certificate revocation lists can be stored in the Domain Name System (DNS). |
| RFC 2539 |
Storage of Diffie-Hellman Keys in the Domain Name System (DNS)
|
|
Summary Publication date: Mar 1999 A standard method for storing Diffie-Hellman keys in the Domain Name System is described which utilizes DNS KEY resource records. |
| RFC 2540 |
Detached Domain Name System (DNS) Information
|
|
Summary Publication date: Mar 1999 A standard format is defined for representing detached DNS information. This is anticipated to be of use for storing information retrieved from the Domain Name System (DNS), including security information, in archival contexts or contexts not connected to the Internet. |
| RFC 2541 |
DNS Security Operational Considerations
|
|
Summary Publication date: Mar 1999 Secure DNS is based on cryptographic techniques. A necessary part of the strength of these techniques is careful attention to the operational aspects of key and signature generation, lifetime, size, and storage. In addition, special attention must be paid to the security of the high level zones, particularly the root zone. This document discusses these operational aspects for keys and signatures used in connection with the KEY and SIG DNS resource records. |
| RFC 2542 |
Terminology and Goals for Internet Fax
|
|
Summary Publication date: Mar 1999 This document defines a number of terms useful for the discussion of Internet Fax. In addition, it describes the goals of the Internet Fax working group and establishes a baseline of desired functionality against which protocols for Internet Fax can be judged. It encompasses the goals for all modes of facsimile delivery, including 'real-time', 'session', and 'store and forward'. Different levels of desirability are indicated throughout the document. |
| RFC 2543 |
SIP: Session Initiation Protocol
|
|
Summary Publication date: Mar 1999 The Session Initiation Protocol (SIP) is an application-layer control (signaling) protocol for creating, modifying and terminating sessions with one or more participants. These sessions include Internet multimedia conferences, Internet telephone calls and multimedia distribution. Members in a session can communicate via multicast or via a mesh of unicast relations, or a combination of these. SIP invitations used to create sessions carry session descriptions which allow participants to agree on a set of compatible media types. SIP supports user mobility by proxying and redirecting requests to the user's current location. Users can register their current location. SIP is not tied to any particular conference control protocol. SIP is designed to be independent of the lower-layer transport protocol and can be extended with additional capabilities. |
| RFC 2544 |
Benchmarking Methodology for Network Interconnect Devices
|
|
Summary Publication date: Mar 1999 This document discusses and defines a number of tests that may be used to describe the performance characteristics of a network interconnecting device. In addition to defining the tests this document also describes specific formats for reporting the results of the tests. Appendix A lists the tests and conditions that we believe should be included for specific cases and gives additional information about testing practices. Appendix B is a reference listing of maximum frame rates to be used with specific frame sizes on various media and Appendix C gives some examples of frame formats to be used in testing. |
| RFC 2545 |
Use of BGP-4 Multiprotocol Extensions for IPv6 Inter-Domain Routing
|
|
Summary Publication date: Mar 1999 BGP-4 Multiprotocol Extensions [BGP-MP] defines the format of two BGP attributes (MP_REACH_NLRI and MP_UNREACH_NLRI) that can be used to announce and withdraw the announcement of reachability information. This document defines how compliant systems should make use of those attributes for the purpose of conveying IPv6 routing information. |
| RFC 2546 |
6Bone Routing Practice
|
|
Summary Publication date: Mar 1999 The 6Bone is an environment supporting experimentation with the IPv6 protocols and products implementing it. As the network grows, the need for common operation rules emerged. In particular, operation of the 6Bone backbone is a challenge due to the frequent insertion of bogus routes by leaf or even backbone sites. This memo identifies guidelines on how 6Bone sites might operate, so that the 6Bone can remain a quality experimentation environment and to avoid pathological situations that have been encountered in the past. It defines the 'best current practice' acceptable in the 6Bone for the configuration of both Interior Gateway Protocols (such as RIPng [RFC 2080]) and Exterior Gateway Protocols (like BGP4+ [RFC 2283]). |
| RFC 2547 |
BGP/MPLS VPNs
|
|
Summary Publication date: Mar 1999 This document describes a method by which a Service Provider with an IP backbone may provide VPNs (Virtual Private Networks) for its customers. MPLS (Multiprotocol Label Switching) is used for forwarding packets over the backbone, and BGP (Border Gateway Protocol) is used for distributing routes over the backbone. The primary goal of this method is to support the outsourcing of IP backbone services for enterprise networks. It does so in a manner which is simple for the enterprise, while still scalable and flexible for the Service Provider, and while allowing the Service Provider to add value. These techniques can also be used to provide a VPN which itself provides IP service to customers. |
| RFC 2548 |
Microsoft Vendor-specific RADIUS Attributes
|
|
Summary Publication date: Mar 1999 This document describes the set of Microsoft vendor-specific RADIUS attributes. These attributes are designed to support Microsoft proprietary dial-up protocols and/or provide support for features which is not provided by the standard RADIUS attribute set [3]. It is expected that this memo will be updated whenever Microsoft defines a new vendor-specific attribute, since its primary purpose is to provide an open, easily accessible reference for third-parties wishing to interoperate with Microsoft products. |
| RFC 2549 |
IP over Avian Carriers with Quality of Service
|
|
Summary Publication date: Apr 1999 This memo amends RFC 1149, "A Standard for the Transmission of IP Datagrams on Avian Carriers", with Quality of Service information. This is an experimental, not recommended standard. |
| RFC 2550 |
Y10K and Beyond
|
|
Summary Publication date: Apr 1999 As we approach the end of the millennium, much attention has been paid to the so-called "Y2K" problem. Nearly everyone now regrets the short-sightedness of the programmers of yore who wrote programs designed to fail in the year 2000. Unfortunately, the current fixes for Y2K lead inevitably to a crisis in the year 10,000 when the programs are again designed to fail. This specification provides a solution to the "Y10K" problem which has also been called the "YAK" problem (hex) and the "YXK" problem (Roman numerals). |
| RFC 2551 |
The Roman Standards Process -- Revision III
|
|
Summary Publication date: Apr 1999 This memo documents the process used by the Roman community for the standardization of protocols and procedures. It defines the stages in the standardization process, the requirements for moving a document between stages and the types of documents used during this process. It also addresses the intellectual property rights and copyright issues associated with the standards process. |
| RFC 2552 |
Architecture for the Information Brokerage in the ACTS Project GAIA
|
|
Summary Publication date: Apr 1999 This memo introduces a domain and supplier independent generic architecture for information brokerage, designed as part of the ACTS project GAIA (Generic Architecture for Information Availability). |
| RFC 2553 |
Basic Socket Interface Extensions for IPv6
|
|
Summary Publication date: Mar 1999 The de facto standard application program interface (API) for TCP/IP applications is the "sockets" interface. Although this API was developed for Unix in the early 1980s it has also been implemented on a wide variety of non-Unix systems. TCP/IP applications written using the sockets API have in the past enjoyed a high degree of portability and we would like the same portability with IPv6 applications. But changes are required to the sockets API to support IPv6 and this memo describes these changes. These include a new socket address structure to carry IPv6 addresses, new address conversion functions, and some new socket options. These extensions are designed to provide access to the basic IPv6 features required by TCP and UDP applications, including multicasting, while introducing a minimum of change into the system and providing complete compatibility for existing IPv4 applications. Additional extensions for advanced IPv6 features (raw sockets and access to the IPv6 extension headers) are defined in another document [4]. |
| RFC 2554 |
SMTP Service Extension for Authentication
|
|
Summary Publication date: Mar 1999 This document defines an SMTP service extension [ESMTP] whereby an SMTP client may indicate an authentication mechanism to the server, perform an authentication protocol exchange, and optionally negotiate a security layer for subsequent protocol interactions. This extension is a profile of the Simple Authentication and Security Layer [SASL]. |
| RFC 2555 |
30 Years of RFCs
|
|
Summary Publication date: Apr 1999 Thirty years ago today, the first Request for Comments document, RFC 1, was published at UCLA (ftp://ftp.isi.edu/in-notes/RFC 1.txt). This was the first of a series that currently contains more than 2500 documents on computer networking, collected, archived, and edited by Jon Postel for 28 years. Jon has left us, but this 30th anniversary tribute to the RFC series is assembled in grateful admiration for his massive contribution. The rest of this document contains a brief recollection from the present RFC Editor Joyce K. Reynolds, followed by recollections from three pioneers: Steve Crocker who wrote RFC 1, Vint Cerf whose long- range vision continues to guide us, and Jake Feinler who played a key role in the middle years of the RFC series. |
| RFC 2556 |
OSI connectionless transport services on top of UDP Applicability Statement for Historic Status
|
|
Summary Publication date: Mar 1999 RFC 1240, "OSI connectionless transport services on top of UDP", was published as a Proposed Standard in June 1991 but at this time there do not seem to be any implementations which follow RFC 1240. In addition there is a growing concern over using UDP-based transport protocols in environments where congestion is a possibility. |
| RFC 2557 |
MIME Encapsulation of Aggregate Documents, such as HTML (MHTML)
|
|
Summary Publication date: Mar 1999 HTML [RFC 1866] defines a powerful means of specifying multimedia documents. These multimedia documents consist of a text/html root resource (object) and other subsidiary resources (image, video clip, applet, etc. objects) referenced by Uniform Resource Identifiers (URIs) within the text/html root resource. When an HTML multimedia document is retrieved by a browser, each of these component resources is individually retrieved in real time from a location, and using a protocol, specified by each URI. In order to transfer a complete HTML multimedia document in a single e-mail message, it is necessary to: a) aggregate a text/html root resource and all of the subsidiary resources it references into a single composite message structure, and b) define a means by which URIs in the text/html root can reference subsidiary resources within that composite message structure. This document a) defines the use of a MIME multipart/related structure to aggregate a text/html root resource and the subsidiary resources it references, and b) specifies a MIME content-header (Content-Location) that allow URIs in a multipart/related text/html root body part to reference subsidiary resources in other body parts of the same multipart/related structure. While initially designed to support e-mail transfer of complete multi-resource HTML multimedia documents, these conventions can also be employed to resources retrieved by other transfer protocols such as HTTP and FTP to retrieve a complete multi-resource HTML multimedia document in a single transfer or for storage and archiving of complete HTML-documents. Differences between this and a previous version of this standard, which was published as RFC 2110, are summarized in chapter 12. |
| RFC 2558 |
Definitions of Managed Objects for the SONET/SDH Interface Type
|
|
Summary Publication date: Mar 1999 This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in TCP/IP-based internets. In particular, it defines objects for managing Synchronous Optical Network/Synchronous Digital Hierarchy (SONET/SDH) interfaces. This document is a companion to the documents that define Managed Objects for the DS1/E1/DS2/E2 and DS3/E3 Interface Types [24][25]. Textual Conventions used in this MIB are defined in [6] and [36]. This memo replaces RFC 1595 [30]. Changes relative to RFC 1595 are summarized in the MIB module's REVISION clause. |
| RFC 2559 |
Internet X.509 Public Key Infrastructure Operational Protocols - LDAPv2
|
|
Summary Publication date: Apr 1999 The protocol described in this document is designed to satisfy some of the operational requirements within the Internet X.509 Public Key Infrastructure (IPKI). Specifically, this document addresses requirements to provide access to Public Key Infrastructure (PKI) repositories for the purposes of retrieving PKI information and managing that same information. The mechanism described in this document is based on the Lightweight Directory Access Protocol (LDAP) v2, defined in RFC 1777, defining a profile of that protocol for use within the IPKI and updates encodings for certificates and revocation lists from RFC 1778. Additional mechanisms addressing PKIX operational requirements are specified in separate documents. |
| RFC 2560 |
X.509 Internet Public Key Infrastructure Online Certificate Status Protocol - OCSP
|
|
Summary Publication date: Jun 1999 This document specifies a protocol useful in determining the current status of a digital certificate without requiring CRLs. Additional mechanisms addressing PKIX operational requirements are specified in separate documents. An overview of the protocol is provided in section 2. Functional requirements are specified in section 4. Details of the protocol are in section 5. We cover security issues with the protocol in section 6. Appendix A defines OCSP over HTTP, appendix B accumulates ASN.1 syntactic elements and appendix C specifies the mime types for the messages. |
| RFC 2561 |
Base Definitions of Managed Objects for TN3270E Using SMIv2
|
|
Summary Publication date: Apr 1999 This memo defines a Management Information Base (MIB) for configuring and managing TN3270E servers. TN3270E, defined by RFC 2355 [19], refers to the enhancements made to the Telnet 3270 (TN3270) terminal emulation practices. Refer to RFC 1041 [18], STD 8, RFC 854 [16], and STD 31, RFC 860 [17] for a sample of what is meant by TN3270 practices. The MIB defined by this memo provides generic support for both host and gateway TN3270E server implementations. A TN3270E server connects a Telnet client performing 3270 emulation to a target SNA host over both a client-side network (client to TN3270E server) and an SNA Network (TN3270E server to target SNA host). The client-side network is typically TCP/IP, but it need not be. A host TN3270E server refers to an implementation where the TN3270E server is collocated with the Systems Network Architecture (SNA) System Services Control Point (SSCP) for the dependent Secondary Logical Units (SLUs) that the server makes available to its clients for connecting into a SNA network. A gateway TN3270E server resides on an SNA node other than an SSCP, either an SNA type 2.0 node, a boundary-function-attached type 2.1 node, or an APPN node acting in the role of a Dependent LU Requester (DLUR). Host and gateway TN3270E server implementations typically differ greatly as to their internal implementation and system definition (SYSDEF) methods. It is the intent that the MIB defined herein be extended by subsequent memos. For example, one such extension enables collection of TN3270E response time data. |
| RFC 2562 |
Definitions of Protocol and Managed Objects for TN3270E Response Time Collection Using SMIv2 (TN3270E-RT-MIB)
|
|
Summary Publication date: Apr 1999 This memo defines the protocol and the Management Information Base (MIB) for performing response time data collection on TN3270 and TN3270E sessions by a TN3270E server. The response time data collected by a TN3270E server is structured to support both validation of service level agreements and performance monitoring of TN3270 and TN3270E Sessions. This MIB has as a prerequisite the TN3270E-MIB, reference [20]. TN3270E, defined by RFC 2355 [19], refers to the enhancements made to the Telnet 3270 (TN3270) terminal emulation practices. Refer to RFC 1041 [18], STD 8, RFC 854 [16], and STD 31, RFC 860 [17] for a sample of what is meant by TN3270 practices. |
| RFC 2563 |
DHCP Option to Disable Stateless Auto-Configuration in IPv4 Clients
|
|
Summary Publication date: May 1999 Operating Systems are now attempting to support ad-hoc networks of two or more systems, while keeping user configuration at a minimum. To accommodate this, in the absence of a central configuration mechanism (DHCP), some OS's are automatically choosing a link-local IP address which will allow them to communicate only with other hosts on the same link. This address will not allow the OS to communicate with anything beyond a router. However, some sites depend on the fact that a host with no DHCP response will have no IP address. This document describes a mechanism by which DHCP servers are able to tell clients that they do not have an IP address to offer, and that the client should not generate an IP address it's own. |
| RFC 2564 |
Application Management MIB
|
|
Summary Publication date: May 1999 This memo defines a standards track portion of the Management Information Base (MIB) for use with network management protocols in the Internet Community. In particular, it defines objects used for the management of applications. This MIB complements the System Application MIB, providing for the management of applications' common attributes which could not typically be observed without the cooperation of the software being managed. |
| RFC 2565 |
Internet Printing Protocol/1.0: Encoding and Transport
|
|
Summary Publication date: Apr 1999 This document is one of a set of documents, which together describe all aspects of a new Internet Printing Protocol (IPP). IPP is an application level protocol that can be used for distributed printing using Internet tools and technologies. This document defines the rules for encoding IPP operations and IPP attributes into a new Internet mime media type called "application/ipp". This document also defines the rules for transporting over HTTP a message body whose Content-Type is "application/ipp". |
| RFC 2566 |
Internet Printing Protocol/1.0: Model and Semantics
|
|
Summary Publication date: Apr 1999 This document is one of a set of documents, which together describe all aspects of a new Internet Printing Protocol (IPP). IPP is an application level protocol that can be used for distributed printing using Internet tools and technologies. This document describes a simplified model consisting of abstract objects, their attributes, and their operations that is independent of encoding and transport. The model consists of a Printer and a Job object. A Job optionally supports multiple documents. IPP 1.0 semantics allow end-users and operators to query printer capabilities, submit print jobs, inquire about the status of print jobs and printers, and cancel print jobs. This document also addresses security, internationalization, and directory issues. |
| RFC 2567 |
Design Goals for an Internet Printing Protocol
|
|
Summary Publication date: Apr 1999 This document is one of a set of documents, which together describe all aspects of a new Internet Printing Protocol (IPP). IPP is an application level protocol that can be used for distributed printing using Internet tools and technologies. This document takes a broad look at distributed printing functionality, and it enumerates real- life scenarios that help to clarify the features that need to be included in a printing protocol for the Internet. It identifies requirements for three types of users: end users, operators, and administrators. The design goals document calls out a subset of end user requirements that are satisfied in IPP/1.0. Operator and administrator requirements are out of scope for version 1.0. |
| RFC 2568 |
Rationale for the Structure of the Model and Protocol for the Internet Printing Protocol
|
|
Summary Publication date: Apr 1999 This document is one of a set of documents, which together describe all aspects of a new Internet Printing Protocol (IPP). IPP is an application level protocol that can be used for distributed printing using Internet tools and technologies. This document describes IPP from a high level view, defines a roadmap for the various documents that form the suite of IPP specifications, and gives background and rationale for the IETF working group's major decisions. |
| RFC 2569 |
Mapping between LPD and IPP Protocols
|
|
Summary Publication date: Apr 1999 This document is one of a set of documents, which together describe all aspects of a new Internet Printing Protocol (IPP). IPP is an application level protocol that can be used for distributed printing using Internet tools and technologies. This document gives some advice to implementers of gateways between IPP and LPD (Line Printer Daemon). This document describes the mapping between (1) the commands and operands of the 'Line Printer Daemon (LPD) Protocol' specified in RFC 1179 and (2) the operations, operation attributes and job template attributes of the Internet Printing Protocol/1.0 (IPP). One of the purposes of this document is to compare the functionality of the two protocols. Another purpose is to facilitate implementation of gateways between LPD and IPP. |
| RFC 2570 |
Introduction to Version 3 of the Internet-standard Network Management Framework
|
|
Summary Publication date: Apr 1999 The purpose of this document is to provide an overview of the third version of the Internet-standard Management Framework, termed the SNMP version 3 Framework (SNMPv3). This Framework is derived from and builds upon both the original Internet-standard Management Framework (SNMPv1) and the second Internet-standard Management Framework (SNMPv2). The architecture is designed to be modular to allow the evolution of the Framework over time. |
| RFC 2571 |
An Architecture for Describing SNMP Management Frameworks
|
|
Summary Publication date: Apr 1999 This document describes an architecture for describing SNMP Management Frameworks. The architecture is designed to be modular to allow the evolution of the SNMP protocol standards over time. The major portions of the architecture are an SNMP engine containing a Message Processing Subsystem, a Security Subsystem and an Access Control Subsystem, and possibly multiple SNMP applications which provide specific functional processing of management data. |
| RFC 2572 |
Message Processing and Dispatching for the Simple Network Management Protocol (SNMP)
|
|
Summary Publication date: Apr 1999 This document describes the Message Processing and Dispatching for SNMP messages within the SNMP architecture [RFC 2571]. It defines the procedures for dispatching potentially multiple versions of SNMP messages to the proper SNMP Message Processing Models, and for dispatching PDUs to SNMP applications. This document also describes one Message Processing Model - the SNMPv3 Message Processing Model. |
| RFC 2573 |
SNMP Applications
|
|
Summary Publication date: Apr 1999 This memo describes five types of SNMP applications which make use of an SNMP engine as described in [RFC 2571]. The types of application described are Command Generators, Command Responders, Notification Originators, Notification Receivers, and Proxy Forwarders. This memo also defines MIB modules for specifying targets of management operations, for notification filtering, and for proxy forwarding. |
| RFC 2574 |
User-based Security Model (USM) for version 3 of the Simple Network Management Protocol (SNMPv3)
|
|
Summary Publication date: Apr 1999 This document describes the User-based Security Model (USM) for SNMP version 3 for use in the SNMP architecture [RFC 2571]. It defines the Elements of Procedure for providing SNMP message level security. This document also includes a MIB for remotely monitoring/managing the configuration parameters for this Security Model. |
| RFC 2575 |
View-based Access Control Model (VACM) for the Simple Network Management Protocol (SNMP)
|
|
Summary Publication date: Apr 1999 This document describes the View-based Access Control Model for use in the SNMP architecture [RFC 2571]. It defines the Elements of Procedure for controlling access to management information. This document also includes a MIB for remotely managing the configuration parameters for the View-based Access Control Model. |
| RFC 2576 |
Coexistence between Version 1, Version 2, and Version 3 of the Internet-standard Network Management Framework
|
|
Summary Publication date: Mar 2000 The purpose of this document is to describe coexistence between version 3 of the Internet-standard Network Management Framework, (SNMPv3), version 2 of the Internet-standard Network Management Framework (SNMPv2), and the original Internet-standard Network Management Framework (SNMPv1). This document obsoletes RFC 1908 [13] and RFC 2089 [14]. |
| RFC 2577 |
FTP Security Considerations
|
|
Summary Publication date: May 1999 The specification for the File Transfer Protocol (FTP) contains a number of mechanisms that can be used to compromise network security. The FTP specification allows a client to instruct a server to transfer files to a third machine. This third-party mechanism, known as proxy FTP, causes a well known security problem. The FTP specification also allows an unlimited number of attempts at entering a user's password. This allows brute force "password guessing" attacks. This document provides suggestions for system administrators and those implementing FTP servers that will decrease the security problems associated with FTP. |
| RFC 2578 |
Structure of Management Information Version 2 (SMIv2)
|
|
Summary Publication date: Apr 1999 Management information is viewed as a collection of managed objects, residing in a virtual information store, termed the Management Information Base (MIB). Collections of related objects are defined in MIB modules. These modules are written using an adapted subset of OSI's Abstract Syntax Notation One, ASN.1 (1988) [1]. It is the purpose of this document, the Structure of Management Information (SMI), to define that adapted subset, and to assign a set of associated administrative values. The SMI is divided into three parts: module definitions, object definitions, and, notification definitions. (1) Module definitions are used when describing information modules. An ASN.1 macro, MODULE-IDENTITY, is used to concisely convey the semantics of an information module. (2) Object definitions are used when describing managed objects. An ASN.1 macro, OBJECT-TYPE, is used to concisely convey the syntax and semantics of a managed object. (3) Notification definitions are used when describing unsolicited transmissions of management information. An ASN.1 macro, NOTIFICATION-TYPE, is used to concisely convey the syntax and semantics of a notification. |
| RFC 2579 |
Textual Conventions for SMIv2
|
|
Summary Publication date: Apr 1999 Management information is viewed as a collection of managed objects, residing in a virtual information store, termed the Management Information Base (MIB). Collections of related objects are defined in MIB modules. These modules are written using an adapted subset of OSI's Abstract Syntax Notation One, ASN.1 (1988) [1], termed the Structure of Management Information (SMI) [2]. When designing a MIB module, it is often useful to define new types similar to those defined in the SMI. In comparison to a type defined in the SMI, each of these new types has a different name, a similar syntax, but a more precise semantics. These newly defined types are termed textual conventions, and are used for the convenience of humans reading the MIB module. It is the purpose of this document to define the initial set of textual conventions available to all MIB modules. Objects defined using a textual convention are always encoded by means of the rules that define their primitive type. However, textual conventions often have special semantics associated with them. As such, an ASN.1 macro, TEXTUAL-CONVENTION, is used to concisely convey the syntax and semantics of a textual convention. |
| RFC 2580 |
Conformance Statements for SMIv2
|
|
Summary Publication date: Apr 1999 Management information is viewed as a collection of managed objects, residing in a virtual information store, termed the Management Information Base (MIB). Collections of related objects are defined in MIB modules. These modules are written using an adapted subset of OSI's Abstract Syntax Notation One, ASN.1 (1988) [1], termed the Structure of Management Information (SMI) [2]. It may be useful to define the acceptable lower-bounds of implementation, along with the actual level of implementation achieved. It is the purpose of this document to define the notation used for these purposes. |
| RFC 2581 |
TCP Congestion Control
|
|
Summary Publication date: Apr 1999 This document defines TCP's four intertwined congestion control algorithms: slow start, congestion avoidance, fast retransmit, and fast recovery. In addition, the document specifies how TCP should begin transmission after a relatively long idle period, as well as discussing various acknowledgment generation methods. |
| RFC 2582 |
The NewReno Modification to TCP's Fast Recovery Algorithm
|
|
Summary Publication date: Apr 1999 RFC 2001 [RFC 2001] documents the following four intertwined TCP congestion control algorithms: Slow Start, Congestion Avoidance, Fast Retransmit, and Fast Recovery. RFC 2581 [RFC 2581] explicitly allows certain modifications of these algorithms, including modifications that use the TCP Selective Acknowledgement (SACK) option [MMFR96], and modifications that respond to "partial acknowledgments" (ACKs which cover new data, but not all the data outstanding when loss was detected) in the absence of SACK. This document describes a specific algorithm for responding to partial acknowledgments, referred to as NewReno. This response to partial acknowledgments was first proposed by Janey Hoe in [Hoe95]. |
| RFC 2583 |
Guidelines for Next Hop Client (NHC) Developers
|
|
Summary Publication date: May 1999 This document provides guidelines for developers of the Next Hop Resolution Protocol Clients (NHC). It assumes that the clients are directly connected to an ATM based NBMA network. The same principles will apply to clients connected to other types of NBMA networks. The intent is to define the interaction between the NHC code and the TCP/IP protocol stack of the local host operating system. The NHC is capable of sending NHRP requests to a Next Hop Resolution Protocol Server (NHS) to resolve both inter and intra LIS addresses. The NHS reply may be positive (ACK) indicating a short-cut path is available or negative (NAK) indicating that a shortcut is not available and the routed path must be used. The NHC must cache (maintain state) for both the ACK and NAK replies in order to use the correct shortcut or routed path. The NAK reply must be cached to avoid making repeated requests to the NHS when the routed path is being used. |
| RFC 2584 |
Definitions of Managed Objects for APPN/HPR in IP Networks
|
|
Summary Publication date: May 1999 This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it defines objects for monitoring and controlling HPR (High Performance Routing) network devices which have the capability to communicate in IP (Internet Protocol) networks. This memo identifies managed objects for the HPR in IP network communications. |
| RFC 2585 |
Internet X.509 Public Key Infrastructure Operational Protocols: FTP and HTTP
|
|
Summary Publication date: May 1999 The protocol conventions described in this document satisfy some of the operational requirements of the Internet Public Key Infrastructure (PKI). This document specifies the conventions for using the File Transfer Protocol (FTP) and the Hypertext Transfer Protocol (HTTP) to obtain certificates and certificate revocation lists (CRLs) from PKI repositories. Additional mechanisms addressing PKIX operational requirements are specified in separate documents. |
| RFC 2586 |
The Audio/L16 MIME content type
|
|
Summary Publication date: May 1999 This document defines the audio/L16 MIME type, a reasonable quality audio format for use in Internet applications. Possible application areas include E-mail, Web served content, file upload in Web forms, and more. |
| RFC 2587 |
Internet X.509 Public Key Infrastructure LDAPv2 Schema
|
|
Summary Publication date: Jun 1999 The schema defined in this document is a minimal schema to support PKIX in an LDAPv2 environment, as defined in RFC 2559. Only PKIX- specific components are specified here. LDAP servers, acting as PKIX repositories should support the auxiliary object classes defined in this specification and integrate this schema specification with the generic and other application-specific schemas as appropriate, depending on the services to be supplied by that server. |
| RFC 2588 |
IP Multicast and Firewalls
|
|
Summary Publication date: May 1999 Many organizations use a firewall computer that acts as a security gateway between the public Internet and their private, internal 'intranet'. In this document, we discuss the issues surrounding the traversal of IP multicast traffic across a firewall, and describe possible ways in which a firewall can implement and control this traversal. We also explain why some firewall mechanisms - such as SOCKS - that were designed specifically for unicast traffic, are less appropriate for multicast. |
| RFC 2589 |
Lightweight Directory Access Protocol (v3): Extensions for Dynamic Directory Services
|
|
Summary Publication date: May 1999 This document defines the requirements for dynamic directory services and specifies the format of request and response extended operations for supporting client-server interoperation in a dynamic directories environment. The Lightweight Directory Access Protocol (LDAP) [1] supports lightweight access to static directory services, allowing relatively fast search and update access. Static directory services store information about people that persists in its accuracy and value over a long period of time. Dynamic directory services are different in that they store information that only persists in its accuracy and value when it is being periodically refreshed. This information is stored as dynamic entries in the directory. A typical use will be a client or a person that is either online - in which case it has an entry in the directory, or is offline - in which case its entry disappears from the directory. Though the protocol operations and attributes used by dynamic directory services are similar to the ones used for static directory services, clients that store dynamic information in the directory need to periodically refresh this information, in order to prevent it from disappearing. If dynamic entries are not refreshed within a given timeout, they will be removed from the directory. For example, this will happen if the client that set them goes offline. A flow control mechanism from the server is also described that allows a server to inform clients how often they should refresh their presence. |
| RFC 2590 |
Transmission of IPv6 Packets over Frame Relay Networks Specification
|
|
Summary Publication date: May 1999 This memo describes mechanisms for the transmission of IPv6 packets over Frame Relay networks. |
| RFC 2591 |
Definitions of Managed Objects for Scheduling Management Operations
|
|
Summary Publication date: May 1999 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 a set of managed objects that are used to schedule management operations periodically or at specified dates and times. |
| RFC 2592 |
Definitions of Managed Objects for the Delegation of Management Script
|
|
Summary Publication date: May 1999 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 a set of managed objects that allow the delegation of management scripts to distributed managers. |
| RFC 2593 |
Script MIB Extensibility Protocol Version 1.0
|
|
Summary Publication date: May 1999 The IETF Script MIB defines an interface for the delegation of management functions based on the Internet management framework. A management script is a set of instructions that are executed by a language specific runtime system. The Script MIB extensibility protocol (SMX) defined in this memo separates language specific runtime systems from language independent Script MIB implementations. |
| RFC 2594 |
Definitions of Managed Objects for WWW Services
|
|
Summary Publication date: May 1999 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 a set of objects for managing World Wide Web (WWW) services. |
| RFC 2595 |
Using TLS with IMAP, POP3 and ACAP
|
|
Summary Publication date: Jun 1999 The TLS protocol (formerly known as SSL) provides a way to secure an application protocol from tampering and eavesdropping. The option of using such security is desirable for IMAP, POP and ACAP due to common connection eavesdropping and hijacking attacks [AUTH]. Although advanced SASL authentication mechanisms can provide a lightweight version of this service, TLS is complimentary to simple authentication-only SASL mechanisms or deployed clear-text password login commands. Many sites have a high investment in authentication infrastructure (e.g., a large database of a one-way-function applied to user passwords), so a privacy layer which is not tightly bound to user authentication can protect against network eavesdropping attacks without requiring a new authentication infrastructure and/or forcing all users to change their password. Recognizing that such sites will desire simple password authentication in combination with TLS encryption, this specification defines the PLAIN SASL mechanism for use with protocols which lack a simple password authentication command such as ACAP and SMTP. (Note there is a separate RFC for the STARTTLS command in SMTP [SMTPTLS].) There is a strong desire in the IETF to eliminate the transmission of clear-text passwords over unencrypted channels. While SASL can be used for this purpose, TLS provides an additional tool with different deployability characteristics. A server supporting both TLS with simple passwords and a challenge/response SASL mechanism is likely to interoperate with a wide variety of clients without resorting to unencrypted clear-text passwords. The STARTTLS command rectifies a number of the problems with using a separate port for a "secure" protocol variant. Some of these are mentioned in section 7. |
| RFC 2596 |
Use of Language Codes in LDAP
|
|
Summary Publication date: May 1999 The Lightweight Directory Access Protocol [1] provides a means for clients to interrogate and modify information stored in a distributed directory system. The information in the directory is maintained as attributes [2] of entries. Most of these attributes have syntaxes which are human-readable strings, and it is desirable to be able to indicate the natural language associated with attribute values. This document describes how language codes [3] are carried in LDAP and are to be interpreted by LDAP servers. All implementations MUST be prepared to accept language codes in the LDAP protocols. Servers may or may not be capable of storing attributes with language codes in the directory. This document does not specify how to determine whether particular attributes can or cannot have language codes. |
| RFC 2597 |
Assured Forwarding PHB Group
|
|
Summary Publication date: Jun 1999 This document defines a general use Differentiated Services (DS) [Blake] Per-Hop-Behavior (PHB) Group called Assured Forwarding (AF). The AF PHB group provides delivery of IP packets in four independently forwarded AF classes. Within each AF class, an IP packet can be assigned one of three different levels of drop precedence. A DS node does not reorder IP packets of the same microflow if they belong to the same AF class. |
| RFC 2598 |
An Expedited Forwarding PHB
|
|
Summary Publication date: Jun 1999 The definition of PHBs (per-hop forwarding behaviors) is a critical part of the work of the Diffserv Working Group. This document describes a PHB called Expedited Forwarding. We show the generality of this PHB by noting that it can be produced by more than one mechanism and give an example of its use to produce at least one service, a Virtual Leased Line. A recommended codepoint for this PHB is given. |
| RFC 2599 |
Request for Comments Summary RFC Numbers 2500-2599
|
|
Summary Publication date: Mar 2000 This RFC is a slightly annotated list of the 100 RFCs from RFC 2500 through RFCs 2599. This is a status report on these RFCs. |
| RFC 2600 |
Internet Official Protocol Standards
|
|
Summary Publication date: Mar 2000 This memo is published by the RFC Editor in accordance with Section 2.1 of "The Internet Standards Process -- Revision 3", RFC 2026, which specifies the rules and procedures by which all Internet standards are set. This memo is prepared by the RFC Editor for the IESG and IAB. |
