|
|
|
RFC Home |
Full RFC Index |
Recent RFCs |
RFC Standards |
Best Current Practice |
RFC Errata |
1 April RFC |
|
|
||||||
| RFC 2701 |
 Nortel Networks Multi-link Multi-node PPP Bundle Discovery Protocol
|
|
Summary Publication date: Sep 1999 This document specifies a standard way for Multi-link PPP to operate across multiple nodes. Both the mechanism by which the Bundle Head is discovered and the PPP fragment encapsulation are specified. |
| RFC 2702 |
Requirements for Traffic Engineering Over MPLS
|
|
Summary Publication date: Sep 1999 This document presents a set of requirements for Traffic Engineering over Multiprotocol Label Switching (MPLS). It identifies the functional capabilities required to implement policies that facilitate efficient and reliable network operations in an MPLS domain. These capabilities can be used to optimize the utilization of network resources and to enhance traffic oriented performance characteristics. |
| RFC 2703 |
Protocol-independent Content Negotiation Framework
|
|
Summary Publication date: Sep 1999 A number of Internet application protocols have a need to provide content negotiation for the resources with which they interact. MIME media types [1,2] provide a standard method for handling one major axis of variation, but resources also vary in ways which cannot be expressed using currently available MIME headers. This memo sets out terminology, an abstract framework and goals for protocol-independent content negotiation, and identifies some technical issues which may need to be addressed. The abstract framework does not attempt to specify the content negotiation process, but gives an indication of the anticipated scope and form of any such specification. The goals set out the desired properties of a content negotiation mechanism. |
| RFC 2704 |
The KeyNote Trust-Management System Version 2
|
|
Summary Publication date: Sep 1999 This memo describes version 2 of the KeyNote trust-management system. It specifies the syntax and semantics of KeyNote ssertions', describes ction attribute' processing, and outlines the application architecture into which a KeyNote implementation can be fit. The KeyNote architecture and language are useful as building blocks for the trust management aspects of a variety of Internet protocols and services. |
| RFC 2705 |
Media Gateway Control Protocol (MGCP) Version 1.0
|
|
Summary Publication date: Oct 1999 This document describes an application programming interface and a corresponding protocol (MGCP) for controlling Voice over IP (VoIP) Gateways from external call control elements. MGCP assumes a call control architecture where the call control "intelligence" is outside the gateways and handled by external call control elements. The document is structured in 6 main sections: * The introduction presents the basic assumptions and the relation to other protocols such as H.323, RTSP, SAP or SIP. * The interface section presents a conceptual overview of the MGCP, presenting the naming conventions, the usage of the session description protocol SDP, and the procedures that compose MGCP: Notifications Request, Notification, Create Connection, Modify Connection, Delete Connection, AuditEndpoint, AuditConnection and RestartInProgress. * The protocol description section presents the MGCP encodings, which are based on simple text formats, and the transmission procedure over UDP. * The security section presents the security requirement of MGCP, and its usage of IP security services (IPSEC). * The event packages section provides an initial definition of packages and event names. * The description of the changes made in combining SGCP 1.1 and IPDC to create MGCP 1.0. |
| RFC 2706 |
ECML v1: Field Names for E-Commerce
|
|
Summary Publication date: Oct 1999 Customers are frequently required to enter substantial amounts of information at an Internet merchant site in order to complete a purchase or other transaction, especially the first time they go there. A standard set of information fields is defined as the first version of an Electronic Commerce Modeling Language (ECML) so that this task can be more easily automated, for example by wallet software that could fill in fields. Even for the manual data entry case, customers will be less confused by varying merchant sites if a substantial number adopt these standard fields. |
| RFC 2707 |
Job Monitoring MIB - V1.0
|
|
Summary Publication date: Nov 1999 This document provides a printer industry standard SNMP MIB for (1) monitoring the status and progress of print jobs (2) obtaining resource requirements before a job is processed, (3) monitoring resource consumption while a job is being processed and (4) collecting resource accounting data after the completion of a job. This MIB is intended to be implemented (1) in a printer or (2) in a server that supports one or more printers. Use of the object set is not limited to printing. However, support for services other than printing is outside the scope of this Job Monitoring MIB. Future extensions to this MIB may include, but are not limited to, fax machines and scanners. |
| RFC 2708 |
Job Submission Protocol Mapping Recommendations for the Job Monitoring MIB
|
|
Summary Publication date: Nov 1999 This document defines the recommended mapping for many currently popular Job submission protocols to objects and attributes in the Job Monitoring MIB. |
| RFC 2709 |
Security Model with Tunnel-mode IPsec for NAT Domains
|
|
Summary Publication date: Oct 1999 There are a variety of NAT flavors, as described in [Ref 1]. Of the domains supported by NATs, only Realm-Specific IP clients are able to pursue end-to-end IPsec secure sessions. However, all flavors of NAT are capable of offering tunnel-mode IPsec security to private domain hosts peering with nodes in external realm. This document describes a security model by which tunnel-mode IPsec security can be architected on NAT devices. A section is devoted to describing how security policies may be transparently communicated to IKE (for automated KEY exchange) during Quick Mode. Also outlined are applications that can benefit from the Security Model described. |
| RFC 2710 |
Multicast Listener Discovery (MLD) for IPv6
|
|
Summary Publication date: Oct 1999 This document specifies the protocol used by an IPv6 router to discover the presence of multicast listeners (that is, nodes wishing to receive multicast packets) on its directly attached links, and to discover specifically which multicast addresses are of interest to those neighboring nodes. This protocol is referred to as Multicast Listener Discovery or MLD. MLD is derived from version 2 of IPv4's Internet Group Management Protocol, IGMPv2. One important difference to note is that MLD uses ICMPv6 (IP Protocol 58) message types, rather than IGMP (IP Protocol 2) message types. |
| RFC 2711 |
IPv6 Router Alert Option
|
|
Summary Publication date: Oct 1999 This memo describes a new IPv6 Hop-by-Hop Option type that alerts transit routers to more closely examine the contents of an IP datagram. This option is useful for situations where a datagram addressed to a particular destination contains information that may require special processing by routers along the path. |
| RFC 2712 |
Addition of Kerberos Cipher Suites to Transport Layer Security (TLS)
|
|
Summary Publication date: Oct 1999 This document proposes the addition of new cipher suites to the TLS protocol [1] to support Kerberos-based authentication. Kerberos credentials are used to achieve mutual authentication and to establish a master secret which is subsequently used to secure client-server communication. |
| RFC 2713 |
Schema for Representing Java(tm) Objects in an LDAP Directory
|
|
Summary Publication date: Oct 1999 This document defines the schema for representing Java(tm) objects in an LDAP directory [LDAPv3]. It defines schema elements to represent a Java serialized object [Serial], a Java marshalled object [RMI], a Java remote object [RMI], and a JNDI reference [JNDI]. |
| RFC 2714 |
Schema for Representing CORBA Object References in an LDAP Directory
|
|
Summary Publication date: Oct 1999 CORBA [CORBA] is the Common Object Request Broker Architecture defined by the Object Management Group. This document defines the schema for representing CORBA object references in an LDAP directory [LDAPv3]. |
| RFC 2715 |
Interoperability Rules for Multicast Routing Protocols
|
|
Summary Publication date: Oct 1999 The rules described in this document will allow efficient interoperation among multiple independent multicast routing domains. Specific instantiations of these rules are given for the DVMRP, MOSPF, PIM-DM, PIM-SM, and CBT multicast routing protocols, as well as for IGMP-only links. Future versions of these protocols, and any other multicast routing protocols, may describe their interoperability procedure by stating how the rules described herein apply to them. |
| RFC 2716 |
PPP EAP TLS Authentication Protocol
|
|
Summary Publication date: Oct 1999 The Point-to-Point Protocol (PPP) provides a standard method for transporting multi-protocol datagrams over point-to-point links. PPP also defines an extensible Link Control Protocol (LCP), which can be used to negotiate authentication methods, as well as an Encryption Control Protocol (ECP), used to negotiate data encryption over PPP links, and a Compression Control Protocol (CCP), used to negotiate compression methods. The Extensible Authentication Protocol (EAP) is a PPP extension that provides support for additional authentication methods within PPP. Transport Level Security (TLS) provides for mutual authentication, integrity-protected ciphersuite negotiation and key exchange between two endpoints. This document describes how EAP-TLS, which includes support for fragmentation and reassembly, provides for these TLS mechanisms within EAP. |
| RFC 2717 |
Registration Procedures for URL Scheme Names
|
|
Summary Publication date: Nov 1999 This document defines the process by which new URL scheme names are registered. |
| RFC 2718 |
Guidelines for new URL Schemes
|
|
Summary Publication date: Nov 1999 A Uniform Resource Locator (URL) is a compact string representation of the location for a resource that is available via the Internet. This document provides guidelines for the definition of new URL schemes. |
| RFC 2719 |
Framework Architecture for Signaling Transport
|
|
Summary Publication date: Oct 1999 This document defines an architecture framework and functional requirements for transport of signaling information over IP. The framework describes relationships between functional and physical entities exchanging signaling information, such as Signaling Gateways and Media Gateway Controllers. It identifies interfaces where signaling transport may be used and the functional and performance requirements that apply from existing Switched Circuit Network (SCN) signaling protocols. |
| RFC 2720 |
Traffic Flow Measurement: Meter MIB
|
|
Summary Publication date: Oct 1999 The RTFM Traffic Measurement Architecture provides a general framework for describing and measuring network traffic flows. Flows are defined in terms of their Address Attribute values and measured by a 'Traffic Meter'. This document defines a Management Information Base (MIB) for use in controlling an RTFM Traffic Meter, in particular for specifying the flows to be measured. It also provides an efficient mechanism for retrieving flow data from the meter using SNMP. Security issues concerning the operation of traffic meters are summarised. |
| RFC 2721 |
RTFM: Applicability Statement
|
|
Summary Publication date: Oct 1999 This document provides an overview covering all aspects of Realtime Traffic Flow Measurement, including its area of applicability and its limitations. |
| RFC 2722 |
Traffic Flow Measurement: Architecture
|
|
Summary Publication date: Oct 1999 This document provides a general framework for describing network traffic flows, presents an architecture for traffic flow measurement and reporting, discusses how this relates to an overall network traffic flow architecture and indicates how it can be used within the Internet. |
| RFC 2723 |
SRL: A Language for Describing Traffic Flows and Specifying Actions for Flow Groups
|
|
Summary Publication date: Oct 1999 This document describes a language for specifying rulesets, i.e. configuration files which may be loaded into a traffic flow meter so as to specify which traffic flows are measured by the meter, and the information it will store for each flow. |
| RFC 2724 |
RTFM: New Attributes for Traffic Flow Measurement
|
|
Summary Publication date: Oct 1999 The RTFM Traffic Measurement Architecture provides a general framework for describing and measuring network traffic flows. Flows are defined in terms of their Address Attribute values and measured by a 'Traffic Meter'. This document discusses RTFM flows and the attributes which they can have, so as to provide a logical framework for extending the architecture by adding new attributes. Extensions described include Address Attributes such as DSCodePoint, SourceASN and DestASN, and Group Attributes such as short-term bit rates and turnaround times. Quality of Service parameters for Integrated Services are also discussed. |
| RFC 2725 |
Routing Policy System Security
|
|
Summary Publication date: Dec 1999 The RIPE database specifications and RPSL language define languages used as the basis for representing information in a routing policy system. A repository for routing policy system information is known as a routing registry. A routing registry provides a means of exchanging information needed to address many issues of importance to the operation of the Internet. The implementation and deployment of a routing policy system must maintain some degree of integrity to be of any operational use. This document addresses the need to assure integrity of the data by providing an authentication and authorization model. |
| RFC 2726 |
PGP Authentication for RIPE Database Updates
|
|
Summary Publication date: Dec 1999 This document presents the proposal for a stronger authentication method of the updates of the RIPE database based on digital signatures. The proposal tries to be as general as possible as far as digital signing methods are concerned, however, it concentrates mainly on PGP, as the first method to be implemented. The proposal is the result of the discussions within the RIPE DBSEC Task Force. |
| RFC 2727 |
IAB and IESG Selection, Confirmation, and Recall Process: Operation of the Nominating and Recall Committees
|
|
Summary Publication date: Feb 2000 The process by which the members of the IAB and IESG are selected, confirmed, and recalled is specified. This document is a self- consistent, organized compilation of the process as it was known at the time of publication. |
| RFC 2728 |
The Transmission of IP Over the Vertical Blanking Interval of a Television Signal
|
|
Summary Publication date: Nov 1999 This document describes a method for broadcasting IP data in a unidirectional manner using the vertical blanking interval of television signals. It includes a description for compressing IP headers on unidirectional networks, a framing protocol identical to SLIP, a forward error correction scheme, and the NABTS byte structures. |
| RFC 2729 |
Taxonomy of Communication Requirements for Large-scale Multicast Applications
|
|
Summary Publication date: Dec 1999 The intention of this memo is to define a classification system for the communication requirements of any large-scale multicast application (LSMA). It is very unlikely one protocol can achieve a compromise between the diverse requirements of all the parties involved in any LSMA. It is therefore necessary to understand the worst-case scenarios in order to minimize the range of protocols needed. Dynamic protocol adaptation is likely to be necessary which will require logic to map particular combinations of requirements to particular mechanisms. Standardizing the way that applications define their requirements is a necessary step towards this. Classification is a first step towards standardization. |
| RFC 2730 |
Multicast Address Dynamic Client Allocation Protocol (MADCAP)
|
|
Summary Publication date: Dec 1999 This document defines a protocol, Multicast Address Dynamic Client Allocation Protocol (MADCAP), that allows hosts to request multicast addresses from multicast address allocation servers. |
| RFC 2731 |
Encoding Dublin Core Metadata in HTML
|
|
Summary Publication date: Dec 1999 The Dublin Core [DC1] is a small set of metadata elements for describing information resources. This document explains how these elements are expressed using the META and LINK tags of HTML [HTML4.0]. A sequence of metadata elements embedded in an HTML file is taken to be a description of that file. Examples illustrate conventions allowing interoperation with current software that indexes, displays, and manipulates metadata, such as [SWISH-E], [freeWAIS-sf2.0], [GLIMPSE], [HARVEST], [ISEARCH], etc., and the Perl [PERL] scripts in the appendix. |
| RFC 2732 |
Format for Literal IPv6 Addresses in URL's
|
|
Summary Publication date: Dec 1999 This document defines the format for literal IPv6 Addresses in URL's for implementation in World Wide Web browsers. This format has been implemented in the IPv6 versions of several widely deployed browsers including Microsoft Internet Explorer, Mozilla, and Lynx. It is also intended to be used in the IPv6 version of the service location protocol. This document incudes an update to the generic syntax for Uniform Resource Identifiers defined in RFC 2396 [URL]. It defines a syntax for IPv6 addresses and allows the use of "[" and "]" within a URI explicitly for this reserved purpose. |
| RFC 2733 |
An RTP Payload Format for Generic Forward Error Correction
|
|
Summary Publication date: Dec 1999 This document specifies a payload format for generic forward error correction of media encapsulated in RTP. It is engineered for FEC algorithms based on the exclusive-or (parity) operation. The payload format allows end systems to transmit using arbitrary block lengths and parity schemes. It also allows for the recovery of both the payload and critical RTP header fields. Since FEC is sent as a separate stream, it is backwards compatible with non-FEC capable hosts, so that receivers which do not wish to implement FEC can just ignore the extensions. |
| RFC 2734 |
IPv4 over IEEE 1394
|
|
Summary Publication date: Dec 1999 This document specifies how to use IEEE Std 1394-1995, Standard for a High Performance Serial Bus (and its supplements), for the transport of Internet Protocol Version 4 (IPv4) datagrams; it defines the necessary methods, data structures and codes for that purpose. These include not only packet formats and encapsulation methods for datagrams, but also an address resolution protocol (1394 ARP) and a multicast channel allocation protocol (MCAP). Both 1394 ARP and MCAP are specific to Serial Bus; the latter permits management of Serial Bus resources when used by IP multicast groups. |
| RFC 2735 |
NHRP Support for Virtual Private Networks
|
|
Summary Publication date: Dec 1999 The NBMA Next Hop Resolution Protocol (NHRP) is used to determine the NBMA subnetwork addresses of the "NBMA next hop" towards a public internetworking layer address (see [1]). This document describes the enhancements necessary to enable NHRP to perform the same function for private internetworking layer addresses available within the framework of a Virtual Private Network (VPN) service on a shared NBMA network. |
| RFC 2736 |
Guidelines for Writers of RTP Payload Format Specifications
|
|
Summary Publication date: Dec 1999 This document provides general guidelines aimed at assisting the authors of RTP Payload Format specifications in deciding on good formats. These guidelines attempt to capture some of the experience gained with RTP as it evolved during its development. |
| RFC 2737 |
Entity MIB (Version 2)
|
|
Summary Publication date: Dec 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 managing multiple logical and physical entities managed by a single SNMP agent. |
| RFC 2738 |
Corrections to 'A Syntax for Describing Media Feature Sets'
|
|
Summary Publication date: Dec 1999 In RFC 2533, "A Syntax for Describing Media Feature Sets", an expression format is presented for describing media feature capabilities using simple media feature tags. This memo contains two corrections to that specification: one fixes an error in the formal syntax specification, and the other fixes an error in the rules for reducing feature comparison predicates. |
| RFC 2739 |
Calendar Attributes for vCard and LDAP
|
|
Summary Publication date: Jan 2000 When scheduling a calendar entity, such as an event, it is a prerequisite that an organizer has the calendar address of each attendee that will be invited to the event. Additionally, access to an attendee's current "busy time" provides an a priori indication of whether the attendee will be free to participate in the event. In order to meet these challenges, a calendar user agent (CUA) needs a mechanism to locate (URI) individual user's calendar and free/busy time. This memo defines three mechanisms for obtaining a URI to a user's calendar and free/busy time. These include: - Manual transfer of the information; - Personal data exchange using the vCard format; and - Directory lookup using the LDAP protocol. |
| RFC 2740 |
OSPF for IPv6
|
|
Summary Publication date: Dec 1999 This document describes the modifications to OSPF to support version 6 of the Internet Protocol (IPv6). The fundamental mechanisms of OSPF (flooding, DR election, area support, SPF calculations, etc.) remain unchanged. However, some changes have been necessary, either due to changes in protocol semantics between IPv4 and IPv6, or simply to handle the increased address size of IPv6. Changes between OSPF for IPv4 and this document include the following. Addressing semantics have been removed from OSPF packets and the basic LSAs. New LSAs have been created to carry IPv6 addresses and prefixes. OSPF now runs on a per-link basis, instead of on a per-IP-subnet basis. Flooding scope for LSAs has been generalized. Authentication has been removed from the OSPF protocol itself, instead relying on IPv6's Authentication Header and Encapsulating Security Payload. Most packets in OSPF for IPv6 are almost as compact as those in OSPF for IPv4, even with the larger IPv6 addresses. Most field-XSand packet-size limitations present in OSPF for IPv4 have been relaxed. In addition, option handling has been made more flexible. All of OSPF for IPv4's optional capabilities, including on-demand circuit support, NSSA areas, and the multicast extensions to OSPF (MOSPF) are also supported in OSPF for IPv6. |
| RFC 2741 |
Agent Extensibility (AgentX) Protocol Version 1
|
|
Summary Publication date: Jan 2000 This memo defines a standardized framework for extensible SNMP agents. It defines processing entities called master agents and subagents, a protocol (AgentX) used to communicate between them, and the elements of procedure by which the extensible agent processes SNMP protocol messages. This memo obsoletes RFC 2257. |
| RFC 2742 |
Definitions of Managed Objects for Extensible SNMP Agents
|
|
Summary Publication date: Jan 2000 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 managing SNMP agents that use the Agent Extensibility (AgentX) Protocol. This memo specifies a MIB module in a manner that is both compliant to the SMIv2, and semantically identical to the peer SMIv1 definitions. |
| RFC 2743 |
Generic Security Service Application Program Interface Version 2, Update 1
|
|
Summary Publication date: Jan 2000 The Generic Security Service Application Program Interface (GSS-API), Version 2, as defined in [RFC 2078], provides security services to callers in a generic fashion, supportable with a range of underlying mechanisms and technologies and hence allowing source-level portability of applications to different environments. This specification defines GSS-API services and primitives at a level independent of underlying mechanism and programming language environment, and is to be complemented by other, related specifications: documents defining specific parameter bindings for particular language environments documents defining token formats, protocols, and procedures to be implemented in order to realize GSS-API services atop particular security mechanisms This memo obsoletes [RFC 2078], making specific, incremental changes in response to implementation experience and liaison requests. It is intended, therefore, that this memo or a successor version thereto will become the basis for subsequent progression of the GSS-API specification on the standards track. |
| RFC 2744 |
Generic Security Service API Version 2: C-bindings
|
|
Summary Publication date: Jan 2000 This document specifies C language bindings for Version 2, Update 1 of the Generic Security Service Application Program Interface (GSS- API), which is described at a language-independent conceptual level in RFC 2743 [GSSAPI]. It obsoletes RFC 1509, making specific incremental changes in response to implementation experience and liaison requests. It is intended, therefore, that this memo or a successor version thereof will become the basis for subsequent progression of the GSS-API specification on the standards track. The Generic Security Service Application Programming Interface provides security services to its callers, and is intended for implementation atop a variety of underlying cryptographic mechanisms. Typically, GSS-API callers will be application protocols into which security enhancements are integrated through invocation of services provided by the GSS-API. The GSS-API allows a caller application to authenticate a principal identity associated with a peer application, to delegate rights to a peer, and to apply security services such as confidentiality and integrity on a per-message basis. |
| RFC 2745 |
RSVP Diagnostic Messages
|
|
Summary Publication date: Jan 2000 This document specifies the RSVP diagnostic facility, which allows a user to collect information about the RSVP state along a path. This specification describes the functionality, diagnostic message formats, and processing rules. |
| RFC 2746 |
RSVP Operation Over IP Tunnels
|
|
Summary Publication date: Jan 2000 This document describes an approach for providing RSVP protocol services over IP tunnels. We briefly describe the problem, the characteristics of possible solutions, and the design goals of our approach. We then present the details of an implementation which meets our design goals. |
| RFC 2747 |
RSVP Cryptographic Authentication
|
|
Summary Publication date: Jan 2000 This document describes the format and use of RSVP's INTEGRITY object to provide hop-by-hop integrity and authentication of RSVP messages. |
| RFC 2748 |
The COPS (Common Open Policy Service) Protocol
|
|
Summary Publication date: Jan 2000 This document describes a simple client/server model for supporting policy control over QoS signaling protocols. The model does not make any assumptions about the methods of the policy server, but is based on the server returning decisions to policy requests. The model is designed to be extensible so that other kinds of policy clients may be supported in the future. However, this document makes no claims that it is the only or the preferred approach for enforcing future types of policies. |
| RFC 2749 |
COPS usage for RSVP
|
|
Summary Publication date: Jan 2000 This document describes usage directives for supporting COPS policy services in RSVP environments. |
| RFC 2750 |
RSVP Extensions for Policy Control
|
|
Summary Publication date: Jan 2000 This memo presents a set of extensions for supporting generic policy based admission control in RSVP. It should be perceived as an extension to the RSVP functional specifications [RSVP] These extensions include the standard format of POLICY_DATA objects, and a description of RSVP's handling of policy events. This document does not advocate particular policy control mechanisms; however, a Router/Server Policy Protocol description for these extensions can be found in [RAP, COPS, COPS-RSVP]. |
| RFC 2751 |
Signaled Preemption Priority Policy Element
|
|
Summary Publication date: Jan 2000 This document describes a preemption priority policy element for use by signaled policy based admission protocols (such as [RSVP] and [COPS]). Preemption priority defines a relative importance (rank) within the set of flows competing to be admitted into the network. Rather than admitting flows by order of arrival (First Come First Admitted) network nodes may consider priorities to preempt some previously admitted low priority flows in order to make room for a newer, high- priority flow. |
| RFC 2752 |
Identity Representation for RSVP
|
|
Summary Publication date: Jan 2000 This document describes the representation of identity information in POLICY_DATA object [POL-EXT] for supporting policy based admission control in RSVP. The goal of identity representation is to allow a process on a system to securely identify the owner and the application of the communicating process (e.g. user id) and convey this information in RSVP messages (PATH or RESV) in a secure manner. We describe the encoding of identities as RSVP policy element. We describe the processing rules to generate identity policy elements for multicast merged flows. Subsequently, we describe representations of user identities for Kerberos and Public Key based user authentication mechanisms. In summary we describe the use of this identity information in an operational setting. |
| RFC 2753 |
A Framework for Policy-based Admission Control
|
|
Summary Publication date: Jan 2000 The IETF working groups such as Integrated Services (called "int- serv") and RSVP [1] have developed extensions to the IP architecture and the best-effort service model so that applications or end users can request specific quality (or levels) of service from an internetwork in addition to the current IP best-effort service. Recent efforts in the Differentiated Services Working Group are also directed at the definition of mechanisms that support aggregate QoS services. The int-serv model for these new services requires explicit signaling of the QoS (Quality of Service) requirements from the end points and provision of admission and traffic control at Integrated Services routers. The proposed standards for RSVP [RFC 2205] and Integrated Services [RFC 2211, RFC 2212] are examples of a new reservation setup protocol and new service definitions respectively. Under the int-serv model, certain data flows receive preferential treatment over other flows; the admission control component only takes into account the requester's resource reservation request and available capacity to determine whether or not to accept a QoS request. However, the int-serv mechanisms do not include an important aspect of admission control: network managers and service providers must be able to monitor, control, and enforce use of network resources and services based on policies derived from criteria such as the identity of users and applications, traffic/bandwidth requirements, security considerations, and time- of-day/week. Similarly, diff-serv mechanisms also need to take into account policies that involve various criteria such as customer identity, ingress points, and so on. This document is concerned with specifying a framework for providing policy-based control over admission control decisions. In particular, it focuses on policy-based control over admission control using RSVP as an example of the QoS signaling mechanism. Even though the focus of the work is on RSVP-based admission control, the document outlines a framework that can provide policy-based admission control in other QoS contexts. We argue that policy-based control must be applicable to different kinds and qualities of services offered in the same network and our goal is to consider such extensions whenever possible. |
| RFC 2754 |
RPS IANA Issues
|
|
Summary Publication date: Jan 2000 RPS Security [2] requires certain RPSL [1] objects in the IRR to be hierarchically delegated. The set of objects that are at the root of this hierarchy needs to be created and digitally signed by IANA. This paper presents these seed objects and lists operations required from IANA. |
| RFC 2755 |
Security Negotiation for WebNFS
|
|
Summary Publication date: Jan 2000 This document describes a protocol for a WebNFS client [RFC 2054] to negotiate the desired security mechanism with a WebNFS server [RFC 2055] before the WebNFS client falls back to the MOUNT v3 protocol [RFC 1813]. This document is provided so that people can write compatible implementations. |
| RFC 2756 |
Hyper Text Caching Protocol (HTCP/0.0)
|
|
Summary Publication date: Jan 2000 This document describes HTCP, a protocol for discovering HTTP caches and cached data, managing sets of HTTP caches, and monitoring cache activity. This is an experimental protocol, one among several proposals to perform these functions. |
| RFC 2757 |
Long Thin Networks
|
|
Summary Publication date: Jan 2000 In view of the unpredictable and problematic nature of long thin networks (for example, wireless WANs), arriving at an optimized transport is a daunting task. We have reviewed the existing proposals along with future research items. Based on this overview, we also recommend mechanisms for implementation in long thin networks. Our goal is to identify a TCP that works for all users, including users of long thin networks. We started from the working recommendations of the IETF TCP Over Satellite Links (tcpsat) working group with this end in mind. We recognize that not every tcpsat recommendation will be required for long thin networks as well, and work toward a set of TCP recommendations that are 'benign' in environments that do not require them. |
| RFC 2758 |
Definitions of Managed Objects for Service Level Agreements Performance Monitoring
|
|
Summary Publication date: Feb 2000 This memo defines a Management Information Base (MIB) for performance monitoring of Service Level Agreements (SLAs) defined via policy definitions. The MIB defined herein focuses on defining a set of objects for monitoring SLAs and not on replication of the content of the policy definitions being monitored. The goal of the MIB defined within this document is to defined statistics related to a policy rule definition for reporting on the effect that a policy rule has on a system and to defined a method of monitoring this data. |
| RFC 2759 |
Microsoft PPP CHAP Extensions, Version 2
|
|
Summary Publication date: Jan 2000 The Point-to-Point Protocol (PPP) [1] provides a standard method for transporting multi-protocol datagrams over point-to-point links. PPP defines an extensible Link Control Protocol and a family of Network Control Protocols (NCPs) for establishing and configuring different network-layer protocols. This document describes version two of Microsoft's PPP CHAP dialect (MS-CHAP-V2). MS-CHAP-V2 is similar to, but incompatible with, MS- CHAP version one (MS-CHAP-V1, described in [9]). In particular, certain protocol fields have been deleted or reused but with different semantics. In addition, MS-CHAP-V2 features mutual authentication. The algorithms used in the generation of various MS-CHAP-V2 protocol fields are described in section 8. Negotiation and hash generation examples are provided in section 9. |
| RFC 2760 |
Ongoing TCP Research Related to Satellites
|
|
Summary Publication date: Feb 2000 This document outlines possible TCP enhancements that may allow TCP to better utilize the available bandwidth provided by networks containing satellite links. The algorithms and mechanisms outlined have not been judged to be mature enough to be recommended by the IETF. The goal of this document is to educate researchers as to the current work and progress being done in TCP research related to satellite networks. |
| RFC 2761 |
Terminology for ATM Benchmarking
|
|
Summary Publication date: Feb 2000 This memo discusses and defines terms associated with performance benchmarking tests and the results of these tests in the context of Asynchronous Transfer Mode (ATM) based switching devices. The terms defined in this memo will be used in addition to terms defined in RFCs 1242, 2285, and 2544. This memo is a product of the Benchmarking Methodology Working Group (BMWG) of the Internet Engineering Task Force (IETF). |
| RFC 2762 |
Sampling of the Group Membership in RTP
|
|
Summary Publication date: Feb 2000 In large multicast groups, the size of the group membership table maintained by RTP (Real Time Transport Protocol) participants may become unwieldy, particularly for embedded devices with limited memory and processing power. This document discusses mechanisms for sampling of this group membership table in order to reduce the memory requirements. Several mechanisms are proposed, and the performance of each is considered. |
| RFC 2763 |
Dynamic Hostname Exchange Mechanism for IS-IS
|
|
Summary Publication date: Feb 2000 Currently, there does not exist a simple and dynamic mechanism for routers running IS-IS to learn about symbolic hostnames. This document defines a new TLV which allows the IS-IS routers to flood their name to system ID mapping information across the IS-IS network. |
| RFC 2764 |
A Framework for IP Based Virtual Private Networks
|
|
Summary Publication date: Feb 2000 This document describes a framework for Virtual Private Networks (VPNs) running across IP backbones. It discusses the various different types of VPNs, their respective requirements, and proposes specific mechanisms that could be used to implement each type of VPN using existing or proposed specifications. The objective of this document is to serve as a framework for related protocol development in order to develop the full set of specifications required for widespread deployment of interoperable VPN solutions. |
| RFC 2765 |
Stateless IP/ICMP Translation Algorithm (SIIT)
|
|
Summary Publication date: Feb 2000 This document specifies a transition mechanism algorithm in addition to the mechanisms already specified in [TRANS-MECH]. The algorithm translates between IPv4 and IPv6 packet headers (including ICMP headers) in separate translator "boxes" in the network without requiring any per-connection state in those "boxes". This new algorithm can be used as part of a solution that allows IPv6 hosts, which do not have a permanently assigned IPv4 addresses, to communicate with IPv4-only hosts. The document neither specifies address assignment nor routing to and from the IPv6 hosts when they communicate with the IPv4-only hosts. |
| RFC 2766 |
Network Address Translation - Protocol Translation (NAT-PT)
|
|
Summary Publication date: Feb 2000 This document specifies an IPv4-to-IPv6 transition mechanism, in addition to those already specified in [TRANS]. This solution attempts to provide transparent routing, as defined in [NAT-TERM], to end-nodes in V6 realm trying to communicate with end-nodes in V4 realm and vice versa. This is achieved using a combination of Network Address Translation and Protocol Translation. The scheme described does not mandate dual-stacks (i.e., IPv4 as well as V6 protocol support) or special purpose routing requirements (such as requiring tunneling support) on end nodes. This scheme is based on a combination of address translation theme as described in [NAT-TERM] and V6/V4 protocol translation theme as described in [SIIT]. |
| RFC 2767 |
Dual Stack Hosts using the 'Bump-In-the-Stack' Technique (BIS)
|
|
Summary Publication date: Feb 2000 In the especially initial stage of the transition from IPv4 to IPv6, it is hard to provide a complete set of IPv6 applications. This memo proposes a mechanism of dual stack hosts using the technique called "Bump-in-the-Stack" in the IP security area. The mechanism allows the hosts to communicate with other IPv6 hosts using existing IPv4 applications. |
| RFC 2768 |
Network Policy and Services: A Report of a Workshop on Middleware
|
|
Summary Publication date: Feb 2000 An ad hoc middleware workshop was held at the International Center for Advanced Internet Research in December 1998. The Workshop was organized and sponsored by Cisco, Northwestern University's International Center for Advanced Internet Research (iCAIR), IBM, and the National Science Foundation (NSF). The goal of the workshop was to identify existing middleware services that could be leveraged for new capabilities as well as identifying additional middleware services requiring research and development. The workshop participants discussed the definition of middleware in general, examined the applications perspective, detailed underlying network transport capabilities relevant to middleware services, and then covered various specific examples of middleware components. These included APIs, authentication, authorization, and accounting (AAA) issues, policy framework, directories, resource management, networked information discovery and retrieval services, quality of service, security, and operational tools. The need for a more organized framework for middleware R&D was recognized, and a list of specific topics needing further work was identified. |
| RFC 2769 |
Routing Policy System Replication
|
|
Summary Publication date: Feb 2000 The RIPE database specifications and RPSL define languages used as the basis for representing information in a routing policy system. A repository for routing policy system information is known as a routing registry. A routing registry provides a means of exchanging information needed to address many issues of importance to the operation of the Internet. The implementation and deployment of a routing policy system must maintain some degree of integrity to be of any use. The Routing Policy System Security RFC [3] addresses the need to assure integrity of the data by proposing an authentication and authorization model. This document addresses the need to distribute data over multiple repositories and delegate authority for data subsets to other repositories without compromising the authorization model established in Routing Policy System Security RFC. |
| RFC 2770 |
GLOP Addressing in 233/8
|
|
Summary Publication date: Feb 2000 This describes an experimental policy for use of the class D address space using 233/8 as the experimental statically assigned subset of the class D address space. This new experimental allocation is in addition to those described on [IANA] (e.g. [RFC 2365]). This memo is a product of the Multicast Deployment Working Group (MBONED) in the Operations and Management Area of the Internet Engineering Task Force. Submit comments to |
| RFC 2771 |
An Abstract API for Multicast Address Allocation
|
|
Summary Publication date: Feb 2000 This document describes the "abstract service interface" for the dynamic multicast address allocation service, as seen by applications. While it does not describe a concrete API (i.e., for a specific programming language), it describes - in abstract terms - the semantics of this service, including the guarantees that it makes to applications. Additional documents (not necessarily products of the IETF) would describe concrete APIs for this service. |
| RFC 2772 |
6Bone Backbone Routing Guidelines
|
|
Summary Publication date: Feb 2000 The 6Bone is an Ipv6 testbed to assist in the evolution and deployment of IPv6. Because of this, it is important that the core backbone of the IPv6 network maintain stability, and that all operators have a common set of rules and guidelines by which to deploy IPv6 routing equipment. This document provides a set of guidelines for all 6bone routing equipment operators to use as a reference for efficient and stable deployment of 6bone routing systems. As the complexity of the 6Bone grows,the adherence to a common set of rules becomes increasingly important in order for an efficient, scalable backbone to exist. |
| RFC 2773 |
Encryption using KEA and SKIPJACK
|
|
Summary Publication date: Feb 2000 This document defines a method to encrypt a file transfer using the FTP specification STD 9, RFC 959, "File Transfer Protocol (FTP)", (October 1985) [3] and RFC 2228, "FTP Security Extensions" (October 1997) [1]. This method will use the Key Exchange Algorithm (KEA) to give mutual authentication and establish the data encryption keys. SKIPJACK is used to encrypt file data and the FTP command channel. |
| RFC 2774 |
An HTTP Extension Framework
|
|
Summary Publication date: Feb 2000 A wide range of applications have proposed various extensions of the HTTP protocol. Current efforts span an enormous range, including distributed authoring, collaboration, printing, and remote procedure call mechanisms. These HTTP extensions are not coordinated, since there has been no standard framework for defining extensions and thus, separation of concerns. This document describes a generic extension mechanism for HTTP, which is designed to address the tension between private agreement and public specification and to accommodate extension of applications using HTTP clients, servers, and proxies. The proposal associates each extension with a globally unique identifier, and uses HTTP header fields to carry the extension identifier and related information between the parties involved in the extended communication. |
| RFC 2775 |
Internet Transparency
|
|
Summary Publication date: Feb 2000 This document describes the current state of the Internet from the architectural viewpoint, concentrating on issues of end-to-end connectivity and transparency. It concludes with a summary of some major architectural alternatives facing the Internet network layer. This document was used as input to the IAB workshop on the future of the network layer held in July 1999. For this reason, it does not claim to be complete and definitive, and it refrains from making recommendations. |
| RFC 2776 |
Multicast-Scope Zone Announcement Protocol (MZAP)
|
|
Summary Publication date: Feb 2000 This document defines a protocol, the Multicast-Scope Zone Announcement Protocol (MZAP), for discovering the multicast administrative scope zones that are relevant at a particular location. MZAP also provides mechanisms whereby common misconfigurations of administrative scope zones can be discovered. |
| RFC 2777 |
Publicly Verifiable Nomcom Random Selection
|
|
Summary Publication date: Feb 2000 This document describes a method for making random selections in such a way that the unbiased nature of the choice is publicly verifiable. As an example, the selection of the voting members of the IETF Nominations Committee from the pool of eligible volunteers is used. Similar techniques would be applicable to other cases. |
| RFC 2778 |
A Model for Presence and Instant Messaging
|
|
Summary Publication date: Feb 2000 This document defines an abstract model for a presence and instant messaging system. It defines the various entities involved, defines terminology, and outlines the services provided by the system. The goal is to provide a common vocabulary for further work on requirements for protocols and markup for presence and instant messaging. |
| RFC 2779 |
Instant Messaging / Presence Protocol Requirements
|
|
Summary Publication date: Feb 2000 Presence and Instant Messaging have recently emerged as a new medium of communications over the Internet. Presence is a means for finding, retrieving, and subscribing to changes in the presence information (e.g. "online" or "offline") of other users. Instant messaging is a means for sending small, simple messages that are delivered immediately to online users. Applications of presence and instant messaging currently use independent, non-standard and non-interoperable protocols developed by various vendors. The goal of the Instant Messaging and Presence Protocol (IMPP) Working Group is to define a standard protocol so that independently developed applications of instant messaging and/or presence can interoperate across the Internet. This document defines a minimal set of requirements that IMPP must meet. |
| RFC 2780 |
IANA Allocation Guidelines For Values In the Internet Protocol and Related Headers
|
|
Summary Publication date: Mar 2000 This memo provides guidance for the IANA to use in assigning parameters for fields in the IPv4, IPv6, ICMP, UDP and TCP protocol headers. |
| RFC 2781 |
UTF-16, an encoding of ISO 10646
|
|
Summary Publication date: Feb 2000 This document describes the UTF-16 encoding of Unicode/ISO-10646, addresses the issues of serializing UTF-16 as an octet stream for transmission over the Internet, discusses MIME charset naming as described in [CHARSET-REG], and contains the registration for three MIME charset parameter values: UTF-16BE (big-endian), UTF-16LE (little-endian), and UTF-16. |
| RFC 2782 |
A DNS RR for specifying the location of services (DNS SRV)
|
|
Summary Publication date: Feb 2000 This document describes a DNS RR which specifies the location of the server(s) for a specific protocol and domain. |
| RFC 2783 |
Pulse-Per-Second API for UNIX-like Operating Systems, Version 1.0
|
|
Summary Publication date: Mar 2000 RFC 1589 describes a UNIX kernel implementation model for high- precision time-keeping. This model is meant for use in conjunction with the Network Time Protocol (NTP, RFC 1305), or similar time synchronization protocols. One aspect of this model is an accurate interface to the high-accuracy, one pulse-per-second (PPS) output typically available from precise time sources (such as a GPS or GOES receiver). RFC 1589 did not define an API for managing the PPS facility, leaving implementors without a portable means for using PPS sources. This document specifies such an API. |
| RFC 2784 |
Generic Routing Encapsulation (GRE)
|
|
Summary Publication date: Mar 2000 This document specifies a protocol for encapsulation of an arbitrary network layer protocol over another arbitrary network layer protocol. |
| RFC 2785 |
Methods for Avoiding the 'Small-Subgroup' Attacks on the Diffie-Hellman Key Agreement Method for S/MIME
|
|
Summary Publication date: Mar 2000 In some circumstances the use of the Diffie-Hellman key agreement scheme in a prime order subgroup of a large prime p is vulnerable to certain attacks known as "small-subgroup" attacks. Methods exist, however, to prevent these attacks. This document will describe the situations relevant to implementations of S/MIME version 3 in which protection is necessary and the methods that can be used to prevent these attacks. |
| RFC 2786 |
Diffie-Helman USM Key Management Information Base and Textual Convention
|
|
Summary Publication date: Mar 2000 This memo defines an experimental portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it defines a textual convention for doing Diffie-Helman key agreement key exchanges and a set of objects which extend the usmUserTable to permit the use of a DH key exchange in addition to the key change method described in [12]. In otherwords, this MIB adds the possibility of forward secrecy to the USM model. It also defines a set of objects that can be used to kick start security on an SNMPv3 agent when the out of band path is authenticated, but not necessarily private or confidential. The KeyChange textual convention described in [12] permits secure key changes, but has the property that if a third-party has knowledge of the original key (e.g. if the agent was manufactured with a standard default key) and could capture all SNMP exchanges, the third-party would know the new key. The Diffie-Helman key change described here limits knowledge of the new key to the agent and the manager making the change. In otherwords, this process adds forward secrecy to the key change process. The recommendation in [12] is that the usmUserTable be populated out of band - e.g. not via SNMP. If the number of agents to be configured is small, this can be done via a console port and manually. If the number of agents is large, as is the case for a cable modem system, the manual approach doesn't scale well. The combination of the two mechanisms specified here - the DH key change mechanism, and the DH key ignition mechanism - allows managable use of SNMPv3 USM in a system of millions of devices. This memo specifies a MIB module in a manner that is compliant to the SNMP SMIv2[5][6][7]. The set of objects is consistent with the SNMP framework and existing SNMP standards and is intended for use with the SNMPv3 User Security Model MIB and other security related MIBs. |
| RFC 2787 |
Definitions of Managed Objects for the Virtual Router Redundancy Protocol
|
|
Summary Publication date: Mar 2000 This specification defines an extension to the Management Information Base (MIB) for use with SNMP-based network management. In particular, it defines objects for configuring, monitoring, and controlling routers that employ the Virtual Router Redundancy Protocol (VRRP) [17]. This memo specifies a MIB module in a manner that is compliant with SMIv2 [5], and semantically identical to the SMIv1 definitions [2]. |
| RFC 2788 |
Network Services Monitoring MIB
|
|
Summary Publication date: Mar 2000 A networked application is a realization of some well-defined service on one or more host computers that is accessible via some network, uses some network for its internal operations, or both. There are a wide range of networked applications for which it is appropriate to provide SNMP monitoring of their network usage. This includes applications using both TCP/IP and OSI networking. This document defines a MIB which contains the elements common to the monitoring of any network service application. This information includes a table of all monitorable network service applications, a count of the associations (connections) to each application, and basic information about the parameters and status of each application-related association. This MIB may be used on its own for any application, and for most simple applications this will suffice. This MIB is also designed to serve as a building block which can be used in conjunction with application-specific monitoring and management. Two examples of this are MIBs defining additional variables for monitoring a Message Transfer Agent (MTA) service or a Directory Service Agent (DSA) service. It is expected that further MIBs of this nature will be specified. This MIB does not attempt to provide facilities for management of the host or hosts the network service application runs on, nor does it provide facilities for monitoring applications that provide something other than a network service. Host resource and general application monitoring is handled by either the Host Resources MIB [1] or the application MIB [2]. |
| RFC 2789 |
Mail Monitoring MIB
|
|
Summary Publication date: Mar 2000 This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. Specifically, this memo extends the basic Network Services Monitoring MIB defined in RFC 2788 [16] to allow monitoring of Message Transfer Agents (MTAs). It may also be used to monitor MTA components within gateways. |
| RFC 2790 |
Host Resources MIB
|
|
Summary Publication date: Mar 2000 This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. This memo obsoletes RFC 1514, the "Host Resources MIB". This memo extends that specification by clarifying changes based on implementation and deployment experience and documenting the Host Resources MIB in SMIv2 format while remaining semantically identical to the existing SMIv1-based MIB. This memo defines a MIB for use with managing host systems. The term "host" is construed to mean any computer that communicates with other similar computers attached to the internet and that is directly used by one or more human beings. Although this MIB does not necessarily apply to devices whose primary function is communications services (e.g., terminal servers, routers, bridges, monitoring equipment), such relevance is not explicitly precluded. This MIB instruments attributes common to all internet hosts including, for example, both personal computers and systems that run variants of Unix. |
| RFC 2791 |
Scalable Routing Design Principles
|
|
Summary Publication date: Jul 2000 Routing is essential to a network. Routing scalability is essential to a large network. When routing does not scale, there is a direct impact on the stability and performance of a network. Therefore, routing scalability is an important issue, especially for a large network. This document identifies major factors affecting routing scalability as well as basic principles of designing scalable routing for large networks. |
| RFC 2792 |
DSA and RSA Key and Signature Encoding for the KeyNote Trust Management System
|
|
Summary Publication date: Mar 2000 This memo describes RSA and DSA key and signature encoding, and binary key encoding for version 2 of the KeyNote trust-management system. |
| RFC 2793 |
RTP Payload for Text Conversation
|
|
Summary Publication date: May 2000 This memo describes how to carry text conversation session contents in RTP packets. Text conversation session contents are specified in ITU-T Recommendation T.140 [1]. Text conversation is used alone or in connection to other conversational facilities such as video and voice, to form multimedia conversation services. This RTP payload description contains an optional possibility to include redundant text from already transmitted packets in order to reduce the risk of text loss caused by packet loss. The redundancy coding follows RFC 2198. |
| RFC 2794 |
Mobile IP Network Access Identifier Extension for IPv4
|
|
Summary Publication date: Mar 2000 AAA servers are in use within the Internet today to provide authentication and authorization services for dial-up computers. Such services are likely to be equally valuable for mobile nodes using Mobile IP when the nodes are attempting to connect to foreign domains with AAA servers. AAA servers today identify clients by using the Network Access Identifier (NAI). Our proposal defines a way for the mobile node to identify itself, by including the NAI along with the Mobile IP Registration Request. This memo also updates RFC 2290 which specifies the Mobile-IPv4 Configuration option for IPCP, by allowing the Mobile Node's Home Address field of this option to be zero. |
| RFC 2795 |
The Infinite Monkey Protocol Suite (IMPS)
|
|
Summary Publication date: Apr 2000 This memo describes a protocol suite which supports an infinite number of monkeys that sit at an infinite number of typewriters in order to determine when they have either produced the entire works of William Shakespeare or a good television show. The suite includes communications and control protocols for monkeys and the organizations that interact with them. |
| RFC 2796 |
BGP Route Reflection - An Alternative to Full Mesh IBGP
|
|
Summary Publication date: Apr 2000 The Border Gateway Protocol [1] is an inter-autonomous system routing protocol designed for TCP/IP internets. Currently in the Internet BGP deployments are configured such that that all BGP speakers within a single AS must be fully meshed so that any external routing information must be re-distributed to all other routers within that AS. This represents a serious scaling problem that has been well documented with several alternatives proposed [2,3]. This document describes the use and design of a method known as "Route Reflection" to alleviate the the need for "full mesh" IBGP. |
| RFC 2797 |
Certificate Management Messages over CMS
|
|
Summary Publication date: Apr 2000 This document defines a Certificate Management protocol using CMS (CMC). This protocol addresses two immediate needs within the Internet PKI community: 1. The need for an interface to public key certification products and services based on [CMS] and [PKCS10], and 2. The need in [SMIMEV3] for a certificate enrollment protocol for DSA-signed certificates with Diffie-Hellman public keys. A small number of additional services are defined to supplement the core certificate request service. Throughout this specification the term CMS is used to refer to both [CMS] and [PKCS7]. For both signedData and envelopedData, CMS is a superset of the PKCS7. In general, the use of PKCS7 in this document is aligned to the Cryptographic Message Syntax [CMS] that provides a superset of the PKCS7 syntax. The term CMC refers to this specification. |
| RFC 2798 |
Definition of the inetOrgPerson LDAP Object Class
|
|
Summary Publication date: Apr 2000 While the X.500 standards define many useful attribute types [X520] and object classes [X521], they do not define a person object class that meets the requirements found in today's Internet and Intranet directory service deployments. We define a new object class called inetOrgPerson for use in LDAP and X.500 directory services that extends the X.521 standard organizationalPerson class to meet these needs. |
| RFC 2799 |
Request for Comments Summary RFC Numbers 2700-2799
|
|
Summary Publication date: Sep 2000 This RFC is a slightly annotated list of the 100 RFCs from RFC 2700 through RFCs 2799. This is a status report on these RFCs. |
| RFC 2800 |
Internet Official Protocol Standards
|
|
Summary Publication date: May 2001 This memo contains a snapshot of the state of standardization of protocols used in the Internet as of April 17, 2001. It lists only official protocol standards RFCs; it is not a complete index to the RFC series. The latest version of this memo is designated STD 1. |
