| |
| RFC 2500 | Internet Official Protocol Standards |
| |
|
|
This memo summarizes the status of Internet protocols and specifications. [STANDARDS-TRACK] |
|
| |
| RFC 2501 | Mobile Ad hoc Networking (MANET): Routing Protocol Performance Issues and Evaluation Considerations |
| |
| Authors: | S. Corson, J. Macker. |
| Date: | January 1999 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 2501 |
|
This memo first describes the characteristics of Mobile Ad hocNetworks (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 |
| |
| Authors: | M. Pullen, M. Myjak, C. Bouwens. |
| Date: | February 1999 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 2502 |
|
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 |
| |
| Authors: | R. Moulton, M. Needleman. |
| Date: | February 1999 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 2503 |
|
This memorandum describes a set of MIME types for use with the ISOInterlibrary 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 basicEncoding Rules used to encode PDU's which have been described usingASN.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 (ISO10160/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 theISO TC46/SC4/WG4 committee for approval as an ISO standard. |
|
| |
| RFC 2504 | Users' Security Handbook |
| |
| Authors: | E. Guttman, L. Leong, G. Malkin. |
| Date: | February 1999 |
| Formats: | txt html json |
| Also: | FYI 0034 |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 2504 |
|
The Users' Security Handbook is the companion to the Site SecurityHandbook (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 |
| |
|
|
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.
A brief summary of this memo is: o Stop unauthorized mail relaying. o Spammers then have to operate in the open; deal with them. o Design a mail system that can handle spam. |
|
| |
| RFC 2506 | Media Feature Tag Registration Procedure |
| |
| Authors: | K. Holtman, A. Mutz, T. Hardie. |
| Date: | March 1999 |
| Formats: | txt json html |
| Also: | BCP 0031 |
| Status: | BEST CURRENT PRACTICE |
| DOI: | 10.17487/RFC 2506 |
|
This document defines a registration procedure which uses the Internet Assigned Numbers Authority (IANA) as a central registry for the media feature vocabulary. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. |
|
| |
| RFC 2507 | IP Header Compression |
| |
| Authors: | M. Degermark, B. Nordgren, S. Pink. |
| Date: | February 1999 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 2507 |
|
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 andUDP 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 |
| |
| Authors: | S. Casner, V. Jacobson. |
| Date: | February 1999 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 2508 |
|
This document describes a method for compressing the headers ofIP/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 |
| |
| Authors: | M. Engan, S. Casner, C. Bormann. |
| Date: | February 1999 |
| Formats: | txt html json |
| Obsoleted by: | RFC 3544 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 2509 |
|
This document describes an option for negotiating the use of header compression on IP datagrams transmitted over the Point-to-PointProtocol [RFC1661]. It defines extensions to the PPP ControlProtocols for IPv4 and IPv6 [RFC1332, RFC2023]. 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 |
| |
| Authors: | C. Adams, S. Farrell. |
| Date: | March 1999 |
| Formats: | txt html json |
| Obsoleted by: | RFC 4210 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 2510 |
|
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.509v3Certificate as defined in [COR95, X509-AM]. |
|
| |
| RFC 2511 | Internet X.509 Certificate Request Message Format |
| |
| Authors: | M. Myers, C. Adams, D. Solo, D. Kemp. |
| Date: | March 1999 |
| Formats: | txt html json |
| Obsoleted by: | RFC 4211 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 2511 |
|
This document describes the Certificate Request Message Format (CRMF). [STANDARDS-TRACK] |
|
| |
| RFC 2512 | Accounting Information for ATM Networks |
| |
| Authors: | K. McCloghrie, J. Heinanen, W. Greene, A. Prasad. |
| Date: | February 1999 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 2512 |
|
This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. This memo defines a set of ATM-specific accounting information which can be collected for connections on ATM networks. [STANDARDS-TRACK] |
|
| |
| RFC 2513 | Managed Objects for Controlling the Collection and Storage of Accounting Information for Connection-Oriented Networks |
| |
| Authors: | K. McCloghrie, J. Heinanen, W. Greene, A. Prasad. |
| Date: | February 1999 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 2513 |
|
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. [STANDARDS-TRACK] |
|
| |
| RFC 2514 | Definitions of Textual Conventions and OBJECT-IDENTITIES for ATM Management |
| |
| Authors: | M. Noto, E. Spiegel, K. Tesink. |
| Date: | February 1999 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 2514 |
|
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 |
| |
|
|
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. [STANDARDS-TRACK] |
|
| |
| RFC 2516 | A Method for Transmitting PPP Over Ethernet (PPPoE) |
| |
| Authors: | L. Mamakos, K. Lidl, J. Evarts, D. Carrel, D. Simone, R. Wheeler. |
| Date: | February 1999 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 2516 |
|
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 |
| |
| Authors: | R. Moats, R. Huber. |
| Date: | February 1999 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 2517 |
|
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 DatabaseServices' 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 byMike Schwartz and his team at the University of Colorado at Boulder[1]. |
|
| |
| RFC 2518 | HTTP Extensions for Distributed Authoring -- WEBDAV |
| |
| Authors: | Y. Goland, E. Whitehead, A. Faizi, S. Carter, D. Jensen. |
| Date: | February 1999 |
| Formats: | txt html json |
| Obsoleted by: | RFC 4918 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 2518 |
|
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 |
| |
| Authors: | E. Chen, J. Stewart. |
| Date: | February 1999 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 2519 |
|
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 |
| |
| Authors: | J. Luciani, H. Suzuki, N. Doraswamy, D. Horton. |
| Date: | February 1999 |
| Formats: | txt html json |
| Status: | EXPERIMENTAL |
| DOI: | 10.17487/RFC 2520 |
|
This document describes an extension to NHRP [1] which would allowMobile 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 |
| |
| Authors: | P. Karn, W. Simpson. |
| Date: | March 1999 |
| Formats: | txt html json |
| Status: | EXPERIMENTAL |
| DOI: | 10.17487/RFC 2521 |
|
This document specifies ICMP messages for indicating failures when using IP Security Protocols (AH and ESP). |
|
| |
| RFC 2522 | Photuris: Session-Key Management Protocol |
| |
| Authors: | P. Karn, W. Simpson. |
| Date: | March 1999 |
| Formats: | txt json html |
| Status: | EXPERIMENTAL |
| DOI: | 10.17487/RFC 2522 |
|
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 |
| |
| Authors: | P. Karn, W. Simpson. |
| Date: | March 1999 |
| Formats: | txt json html |
| Status: | EXPERIMENTAL |
| DOI: | 10.17487/RFC 2523 |
|
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 IPAuthentication 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 |
| |
| Authors: | M. Banan. |
| Date: | February 1999 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 2524 |
|
This specification narrowly focuses on submission and delivery of short mail messages with a clear emphasis on efficiency. This memo provides information for the Internet community. |
|
| |
| RFC 2525 | Known TCP Implementation Problems |
| |
| Authors: | V. Paxson, M. Allman, S. Dawson, W. Fenner, J. Griner, I. Heavens, K. Lahey, J. Semke, B. Volz. |
| Date: | March 1999 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 2525 |
|
This memo catalogs a number of known TCP implementation problems. This memo provides information for the Internet community. |
|
| |
| RFC 2526 | Reserved IPv6 Subnet Anycast Addresses |
| |
| Authors: | D. Johnson, S. Deering. |
| Date: | March 1999 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 2526 |
|
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 |
| |
|
|
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 |
| |
| Authors: | R. Housley, W. Polk. |
| Date: | March 1999 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 2528 |
|
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 |
| |
| Authors: | B. Carpenter, C. Jung. |
| Date: | March 1999 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 2529 |
|
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, RouterAdvertisement, Neighbor Solicitation, and Neighbor Advertisement andRedirect 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 usesIPv4 multicast as a "virtual Ethernet". |
|
| |
| RFC 2530 | Indicating Supported Media Features Using Extensions to DSN and MDN |
| |
| Authors: | D. Wing. |
| Date: | March 1999 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 2530 |
|
This memo describes a format for generating Message Disposition Notifications and Delivery Status Notifications which contain such information. [STANDARDS-TRACK] |
|
| |
| RFC 2531 | Content Feature Schema for Internet Fax |
| |
| Authors: | G. Klyne, L. McIntyre. |
| Date: | March 1999 |
| Formats: | txt html json |
| Obsoleted by: | RFC 2879 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 2531 |
|
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 |
| |
| Authors: | L. Masinter, D. Wing. |
| Date: | March 1999 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 2532 |
|
This document describes extensions to "Simple Mode of Facsimile UsingInternet Mail" [RFC2305] 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.
The IETF has been notified of intellectual property rights claimed in regard to some or all of the specification contained in this document. For more information consult the online list of claimed rights in <http://www.ietf.org/ipr.html&rt;. |
|
| |
| RFC 2533 | A Syntax for Describing Media Feature Sets |
| |
|
|
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 |
| |
| Authors: | L. Masinter, D. Wing, A. Mutz, K. Holtman. |
| Date: | March 1999 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 2534 |
|
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 |
| |
| Authors: | D. Eastlake 3rd. |
| Date: | March 1999 |
| Formats: | txt html json |
| Obsoletes: | RFC 2065 |
| Obsoleted by: | RFC 4033, RFC 4034, RFC 4035 |
| Updates: | RFC 2181, RFC 1035, RFC 1034 |
| Updated by: | RFC 2931, RFC 3007, RFC 3008, RFC 3090, RFC 3226, RFC 3445, RFC 3597, RFC 3655, RFC 3658, RFC 3755, RFC 3757, RFC 3845 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 2535 |
|
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 awareDNS 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) |
| |
|
|
A standard method for storing US Government Digital SignatureAlgorithm 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) |
| |
|
|
A standard method for storing RSA keys and and RSA/MD5 based signatures in the Domain Name System is described which utilizes DNSKEY and SIG resource records. |
|
| |
| RFC 2538 | Storing Certificates in the Domain Name System (DNS) |
| |
| Authors: | D. Eastlake 3rd, O. Gudmundsson. |
| Date: | March 1999 |
| Formats: | txt html json |
| Obsoleted by: | RFC 4398 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 2538 |
|
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) |
| |
|
|
A standard method for storing Diffie-Hellman keys in the Domain NameSystem is described which utilizes DNS KEY resource records. |
|
| |
| RFC 2540 | Detached Domain Name System (DNS) Information |
| |
| Authors: | D. Eastlake 3rd. |
| Date: | March 1999 |
| Formats: | txt json html |
| Status: | EXPERIMENTAL |
| DOI: | 10.17487/RFC 2540 |
|
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 |
| |
|
|
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 |
| |
| Authors: | L. Masinter. |
| Date: | March 1999 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 2542 |
|
This document defines a number of terms useful for the discussion ofInternet 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 |
| |
|
|
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 |
| |
|
|
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 |
| |
| Authors: | P. Marques, F. Dupont. |
| Date: | March 1999 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 2545 |
|
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 |
| |
|
|
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 and Exterior Gateway Protocols. This memo provides information for the Internet community. |
|
| |
| RFC 2547 | BGP/MPLS VPNs |
| |
|
|
This document describes a method by which a Service Provider with anIP 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 GatewayProtocol) 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 |
| |
| Authors: | G. Zorn. |
| Date: | March 1999 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 2548 |
|
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 |
| |
|
|
This memo amends RFC 1149, "A Standard for the Transmission of IPDatagrams on Avian Carriers", with Quality of Service information.This is an experimental, not recommended standard. |
|
| |
| RFC 2550 | Y10K and Beyond |
| |
| Authors: | S. Glassman, M. Manasse, J. Mogul. |
| Date: | 1 April 1999 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 2550 |
|
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 |
| |
| Authors: | S. Bradner. |
| Date: | 1 April 1999 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 2551 |
|
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 |
| |
| Authors: | M. Blinov, M. Bessonov, C. Clissmann. |
| Date: | April 1999 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 2552 |
|
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 |
| |
|
|
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 supportIPv6 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 byTCP 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 |
| |
|
|
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. [STANDARDS-TRACK] |
|
| |
| RFC 2555 | 30 Years of RFCs |
| |
|
|
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. This memo provides information for the Internet community. |
|
| |
| RFC 2556 | OSI connectionless transport services on top of UDP Applicability Statement for Historic Status |
| |
| Authors: | S. Bradner. |
| Date: | March 1999 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 2556 |
|
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) |
| |
| Authors: | J. Palme, A. Hopmann, N. Shelness. |
| Date: | March 1999 |
| Formats: | txt html json |
| Obsoletes: | RFC 2110 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 2557 |
|
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 whichURIs 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 |
| |
|
|
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. [STANDARDS-TRACK] |
|
| |
| RFC 2559 | Internet X.509 Public Key Infrastructure Operational Protocols - LDAPv2 |
| |
|
|
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. [STANDARDS-TRACK] |
|
| |
| RFC 2560 | X.509 Internet Public Key Infrastructure Online Certificate Status Protocol - OCSP |
| |
| Authors: | M. Myers, R. Ankney, A. Malpani, S. Galperin, C. Adams. |
| Date: | June 1999 |
| Formats: | txt json html |
| Obsoleted by: | RFC 6960 |
| Updated by: | RFC 6277 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 2560 |
|
This document specifies a protocol useful in determining the current status of a digital certificate without requiring CRLs. [STANDARDS- TRACK] |
|
| |
| RFC 2561 | Base Definitions of Managed Objects for TN3270E Using SMIv2 |
| |
| Authors: | K. White, R. Moore. |
| Date: | April 1999 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 2561 |
|
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 SecondaryLogical 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 gatewayTN3270E 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) |
| |
| Authors: | K. White, R. Moore. |
| Date: | April 1999 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 2562 |
|
This memo defines the protocol and the Management Information Base(MIB) for performing response time data collection on TN3270 andTN3270E 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 ofTN3270 and TN3270E Sessions. This MIB has as a prerequisite theTN3270E-MIB, reference [20].
TN3270E, defined by RFC 2355 [19], refers to the enhancements made to the Telnet 3270 (TN3270) terminal emulation practices. Refer to RFC1041 [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 |
| |
|
|
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-localIP 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 |
| |
| Authors: | C. Kalbfleisch, C. Krupczak, R. Presuhn, J. Saperia. |
| Date: | May 1999 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 2564 |
|
This memo defines a standards track portion of the ManagementInformation 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 SystemApplication 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 |
| |
| Authors: | R. Herriot, Ed., S. Butler, P. Moore, R. Turner. |
| Date: | April 1999 |
| Formats: | txt json html |
| Obsoleted by: | RFC 2910 |
| Status: | EXPERIMENTAL |
| DOI: | 10.17487/RFC 2565 |
|
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 newInternet 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".
The full set of IPP documents includes:
Design Goals for an Internet Printing Protocol [RFC2567]Rationale for the Structure and Model and Protocol for theInternet Printing Protocol [RFC2568]Internet Printing Protocol/1.0: Model and Semantics [RFC2566]Internet Printing Protocol/1.0: Encoding and Transport (this document)Internet Printing Protocol/1.0: Implementer's Guide [ipp-iig]Mapping between LPD and IPP Protocols [RFC2569]
The document, "Design Goals for an Internet Printing Protocol", 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. It 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.
The document, "Rationale for the Structure and Model and Protocol for the Internet Printing Protocol", 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 theIETF working group's major decisions.
The document, "Internet Printing Protocol/1.0: Model and Semantics", describes a simplified model with abstract objects, their attributes, and their operations that are independent of encoding and transport.It introduces a Printer and a Job object. The Job object optionally supports multiple documents per Job. It also addresses security, internationalization, and directory issues.
This document "Internet Printing Protocol/1.0: Implementer's Guide", gives advice to implementers of IPP clients and IPP objects.
The document "Mapping between LPD and IPP Protocols" gives some advice to implementers of gateways between IPP and LPD (Line PrinterDaemon) implementations. |
|
| |
| RFC 2566 | Internet Printing Protocol/1.0: Model and Semantics |
| |
| Authors: | R. deBry, T. Hastings, R. Herriot, S. Isaacson, P. Powell. |
| Date: | April 1999 |
| Formats: | txt html json |
| Obsoleted by: | RFC 2911 |
| Status: | EXPERIMENTAL |
| DOI: | 10.17487/RFC 2566 |
|
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.
The full set of IPP documents includes:
Design Goals for an Internet Printing Protocol [RFC2567]Rationale for the Structure and Model and Protocol for the InternetPrinting Protocol [RFC2568]Internet Printing Protocol/1.0: Model and Semantics (this document)Internet Printing Protocol/1.0: Encoding and Transport [RFC2565]Internet Printing Protocol/1.0: Implementer's Guide [ipp-iig]Mapping between LPD and IPP Protocols [RFC2569]
The "Design Goals for an Internet Printing Protocol" 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. It 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.
The "Rationale for the Structure and Model and Protocol for theInternet Printing Protocol" 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 theIETF working group's major decisions.
The "Internet Printing Protocol/1.0: Encoding and Transport" document is a formal mapping of the abstract operations and attributes defined in the model document onto HTTP/1.1. It defines the encoding rules for a new Internet media type called "application/ipp".
The "Internet Printing Protocol/1.0: Implementer's Guide" document gives insight and advice to implementers of IPP clients and IPP objects. It is intended to help them understand IPP/1.0 and some of the considerations that may assist them in the design of their client and/or IPP object implementations. For example, a typical order of processing requests is given, including error checking. Motivation for some of the specification decisions is also included.
The "Mapping between LPD and IPP Protocols" document gives some advice to implementers of gateways between IPP and LPD (Line PrinterDaemon) implementations. |
|
| |
| RFC 2567 | Design Goals for an Internet Printing Protocol |
| |
| Authors: | F. Wright. |
| Date: | April 1999 |
| Formats: | txt html json |
| Status: | EXPERIMENTAL |
| DOI: | 10.17487/RFC 2567 |
|
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.
The full set of IPP documents includes:
Design Goals for an Internet Printing Protocol (this document)Rationale for the Structure and Model and Protocol for theInternet Printing Protocol [RFC2568]Internet Printing Protocol/1.0: Model and Semantics [RFC2568]Internet Printing Protocol/1.0: Encoding and Transport [RFC2565]Internet Printing Protocol/1.0: Implementer's Guide [ipp-iig]Mapping between LPD and IPP Protocols [RFC2569]
The "Rationale for the Structure and Model and Protocol for theInternet Printing Protocol" 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 theIETF working group's major decisions.
The "Internet Printing Protocol/1.0: Model and Semantics" 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. TheJob 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.
The "Internet Printing Protocol/1.0: Encoding and Transport" document is a formal mapping of the abstract operations and attributes defined in the model document onto HTTP/1.1. It defines the encoding rules for a new Internet media type called "application/ipp".
The "Internet Printing Protocol/1.0: Implementer's Guide" document gives insight and advice to implementers of IPP clients and IPP objects. It is intended to help them understand IPP/1.0 and some of the considerations that may assist them in the design of their client and/or IPP object implementations. For example, a typical order of processing requests is given, including error checking. Motivation for some of the specification decisions is also included.
The "Mapping between LPD and IPP Protocols" document gives some advice to implementers of gateways between IPP and LPD (Line PrinterDaemon) implementations. |
|
| |
| RFC 2568 | Rationale for the Structure of the Model and Protocol for the Internet Printing Protocol |
| |
| Authors: | S. Zilles. |
| Date: | April 1999 |
| Formats: | txt json html |
| Status: | EXPERIMENTAL |
| DOI: | 10.17487/RFC 2568 |
|
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. This memo defines an Experimental Protocol for the Internet community. |
|
| |
| RFC 2569 | Mapping between LPD and IPP Protocols |
| |
| Authors: | R. Herriot, Ed., T. Hastings, N. Jacobs, J. Martin. |
| Date: | April 1999 |
| Formats: | txt json html |
| Status: | EXPERIMENTAL |
| DOI: | 10.17487/RFC 2569 |
|
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 PrinterDaemon). This document describes the mapping between (1) the commands and operands of the 'Line Printer Daemon (LPD) Protocol' specified inRFC 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.
WARNING: RFC 1179 was not on the IETF standards track. While RFC1179 was intended to record existing practice, it fell short in some areas. However, this specification maps between (1) the actual current practice of RFC 1179 and (2) IPP. This document does not attempt to map the numerous divergent extensions to the LPD protocol that have been made by many implementers.
The full set of IPP documents includes:
Design Goals for an Internet Printing Protocol [RFC2567]Rationale for the Structure and Model and Protocol for theInternet Printing Protocol [RFC2568]Internet Printing Protocol/1.0: Model and Semantics [RFC2566]Internet Printing Protocol/1.0: Encoding and Transport [RFC2565]Internet Printing Protocol/1.0: Implementors Guide [ipp-iig]Mapping between LPD and IPP Protocols (this document)
The document, "Design Goals for an Internet Printing Protocol", 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. It 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.
The document, "Rationale for the Structure and Model and Protocol for the Internet Printing Protocol", 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 theIETF working group's major decisions.
The document, "Internet Printing Protocol/1.0: Model and Semantics", describes a simplified model with abstract objects, their attributes, and their operations. It introduces a Printer and a Job object. TheJob object supports multiple documents per Job. It also addresses security, internationalization, and directory issues.
The document, "Internet Printing Protocol/1.0: Encoding andTransport", is a formal mapping of the abstract operations and attributes defined in the model document onto HTTP/1.1. It defines the encoding rules for a new Internet media type called ' application/ipp'.
This document "Internet Printing Protocol/1.0: Implementer's Guide", gives advice to implementers of IPP clients and IPP objects. |
|
| |
| RFC 2570 | Introduction to Version 3 of the Internet-standard Network Management Framework |
| |
| Authors: | J. Case, R. Mundy, D. Partain, B. Stewart. |
| Date: | April 1999 |
| Formats: | txt json html |
| Obsoleted by: | RFC 3410 |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 2570 |
|
The purpose of this document is to provide an overview of the third version of the Internet-standard Management Framework, termed theSNMP version 3 Framework (SNMPv3). This Framework is derived from and builds upon both the original Internet-standard ManagementFramework (SNMPv1) and the second Internet-standard ManagementFramework (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 |
| |
|
|
This document describes an architecture for describing SNMPManagement 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 aMessage Processing Subsystem, a Security Subsystem and an AccessControl 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) |
| |
| Authors: | J. Case, D. Harrington, R. Presuhn, B. Wijnen. |
| Date: | April 1999 |
| Formats: | txt html json |
| Obsoletes: | RFC 2272 |
| Obsoleted by: | RFC 3412 |
| Status: | DRAFT STANDARD |
| DOI: | 10.17487/RFC 2572 |
|
This document describes the Message Processing and Dispatching forSNMP messages within the SNMP architecture [RFC2571]. 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 |
| |
|
|
This memo describes five types of SNMP applications which make use of an SNMP engine as described in [RFC2571]. The types of application described are Command Generators, Command Responders, NotificationOriginators, 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) |
| |
|
|
This document describes the User-based Security Model (USM) for SNMP version 3 for use in the SNMP architecture [RFC2571]. It defines theElements 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) |
| |
|
|
This document describes the View-based Access Control Model for use in the SNMP architecture [RFC2571]. It defines the Elements ofProcedure 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 |
| |
|
|
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 ManagementFramework (SNMPv2), and the original Internet-standard NetworkManagement Framework (SNMPv1). This document obsoletes RFC 1908 [13] and RFC2089 [14]. |
|
| |
| RFC 2577 | FTP Security Considerations |
| |
| Authors: | M. Allman, S. Ostermann. |
| Date: | May 1999 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 2577 |
|
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) |
| |
| Authors: | K. McCloghrie, Ed., D. Perkins, Ed., J. Schoenwaelder, Ed.. |
| Date: | April 1999 |
| Formats: | txt json html |
| Obsoletes: | RFC 1902 |
| Also: | STD 0058 |
| Status: | INTERNET STANDARD |
| DOI: | 10.17487/RFC 2578 |
|
It is the purpose of this document, the Structure of Management Information Version 2 (SMIv2), to define that adapted subset, and to assign a set of associated administrative values. [STANDARDS-TRACK] |
|
| |
| RFC 2579 | Textual Conventions for SMIv2 |
| |
| Authors: | K. McCloghrie, Ed., D. Perkins, Ed., J. Schoenwaelder, Ed.. |
| Date: | April 1999 |
| Formats: | txt json html |
| Obsoletes: | RFC 1903 |
| Also: | STD 0058 |
| Status: | INTERNET STANDARD |
| DOI: | 10.17487/RFC 2579 |
|
It is the purpose of this document to define the initial set of textual conventions available to all MIB modules. [STANDARDS-TRACK] |
|
| |
| RFC 2580 | Conformance Statements for SMIv2 |
| |
| Authors: | K. McCloghrie, Ed., D. Perkins, Ed., J. Schoenwaelder, Ed.. |
| Date: | April 1999 |
| Formats: | txt json html |
| Obsoletes: | RFC 1904 |
| Also: | STD 0058 |
| Status: | INTERNET STANDARD |
| DOI: | 10.17487/RFC 2580 |
|
Collections of related objects are defined in MIB modules. 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. [STANDARDS-TRACK] |
|
| |
| RFC 2581 | TCP Congestion Control |
| |
|
|
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 |
| |
|
|
RFC 2001 [RFC2001] documents the following four intertwined TCP congestion control algorithms: Slow Start, Congestion Avoidance, FastRetransmit, and Fast Recovery. RFC 2581 [RFC2581] 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 asNewReno. This response to partial acknowledgments was first proposed by Janey Hoe in [Hoe95]. |
|
| |
| RFC 2583 | Guidelines for Next Hop Client (NHC) Developers |
| |
| Authors: | R. Carlson, L. Winkler. |
| Date: | May 1999 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 2583 |
|
This document provides guidelines for developers of the Next Hop Resolution Protocol Clients (NHC). The intent is to define the interaction between the NHC code and the TCP/IP protocol stack of the local host operating system. This memo provides information for the Internet community. |
|
| |
| RFC 2584 | Definitions of Managed Objects for APPN/HPR in IP Networks |
| |
| Authors: | B. Clouston, B. Moore. |
| Date: | May 1999 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 2584 |
|
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 |
| |
| Authors: | R. Housley, P. Hoffman. |
| Date: | May 1999 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 2585 |
|
The protocol conventions described in this document satisfy some of the operational requirements of the Internet Public KeyInfrastructure (PKI). This document specifies the conventions for using the File Transfer Protocol (FTP) and the Hypertext TransferProtocol (HTTP) to obtain certificates and certificate revocation lists (CRLs) from PKI repositories. Additional mechanisms addressingPKIX operational requirements are specified in separate documents. |
|
| |
| RFC 2586 | The Audio/L16 MIME content type |
| |
| Authors: | J. Salsman, H. Alvestrand. |
| Date: | May 1999 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 2586 |
|
This document defines the audio/L16 MIME type, a reasonable quality audio format for use in Internet applications. This memo provides information for the Internet community. |
|
| |
| RFC 2587 | Internet X.509 Public Key Infrastructure LDAPv2 Schema |
| |
| Authors: | S. Boeyen, T. Howes, P. Richard. |
| Date: | June 1999 |
| Formats: | txt html json |
| Obsoleted by: | RFC 4523 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 2587 |
|
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. [STANDARDS-TRACK] |
|
| |
| RFC 2588 | IP Multicast and Firewalls |
| |
| Authors: | R. Finlayson. |
| Date: | May 1999 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 2588 |
|
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. This memo provides information for the Internet community. |
|
| |
| RFC 2589 | Lightweight Directory Access Protocol (v3): Extensions for Dynamic Directory Services |
| |
| Authors: | Y. Yaacovi, M. Wahl, T. Genovese. |
| Date: | May 1999 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 2589 |
|
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. [STANDARDS-TRACK] |
|
| |
| RFC 2590 | Transmission of IPv6 Packets over Frame Relay Networks Specification |
| |
| Authors: | A. Conta, A. Malis, M. Mueller. |
| Date: | May 1999 |
| Formats: | txt json html |
| Updated by: | RFC 8064 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 2590 |
|
This memo describes mechanisms for the transmission of IPv6 packets over Frame Relay networks. |
|
| |
| RFC 2591 | Definitions of Managed Objects for Scheduling Management Operations |
| |
| Authors: | D. Levi, J. Schoenwaelder. |
| Date: | May 1999 |
| Formats: | txt json html |
| Obsoleted by: | RFC 3231 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 2591 |
|
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 |
| |
| Authors: | D. Levi, J. Schoenwaelder. |
| Date: | May 1999 |
| Formats: | txt html json |
| Obsoleted by: | RFC 3165 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 2592 |
|
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 |
| |
| Authors: | J. Schoenwaelder, J. Quittek. |
| Date: | May 1999 |
| Formats: | txt html json |
| Obsoleted by: | RFC 3179 |
| Status: | EXPERIMENTAL |
| DOI: | 10.17487/RFC 2593 |
|
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 |
| |
| Authors: | H. Hazewinkel, C. Kalbfleisch, J. Schoenwaelder. |
| Date: | May 1999 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 2594 |
|
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 WideWeb (WWW) services. |
|
| |
| RFC 2595 | Using TLS with IMAP, POP3 and ACAP |
| |
|
|
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. [STANDARDS-TRACK] |
|
| |
| RFC 2596 | Use of Language Codes in LDAP |
| |
|
|
This document describes how language codes are carried in LDAP and are to be interpreted by LDAP servers. [STANDARDS-TRACK] |
|
| |
| RFC 2597 | Assured Forwarding PHB Group |
| |
| Authors: | J. Heinanen, F. Baker, W. Weiss, J. Wroclawski. |
| Date: | June 1999 |
| Formats: | txt html json |
| Updated by: | RFC 3260 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 2597 |
|
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 |
| |
| Authors: | V. Jacobson, K. Nichols, K. Poduri. |
| Date: | June 1999 |
| Formats: | txt json html |
| Obsoleted by: | RFC 3246 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 2598 |
|
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.
A pdf version of this document is available at ftp://ftp.ee.lbl.gov/papers/ef_phb.pdf |
|
| |
| RFC 2599 | Request for Comments Summary RFC Numbers 2500-2599 |
| |
| Authors: | A. DeLaCruz. |
| Date: | March 2000 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 2599 |
|
|
|
