| |
| RFC 3801 | Voice Profile for Internet Mail - version 2 (VPIMv2) |
| |
|
|
This document specifies a restricted profile of the Internet multimedia messaging protocols for use between voice processing server platforms. The profile is referred to as the Voice Profile for Internet Mail (VPIM) in this document. These platforms have historically been special-purpose computers and often do not have the same facilities normally associated with a traditional InternetEmail-capable computer. As a result, VPIM also specifies additional functionality, as it is needed. This profile is intended to specify the minimum common set of features to allow interworking between conforming systems.
This document obsoletes RFC 2421 and describes version 2 of the profile with greater precision. No protocol changes were made in this revision. A list of changes from RFC 2421 are noted in AppendixF. Appendix A summarizes the protocol profiles of this version ofVPIM. |
|
| |
| RFC 3802 | Toll Quality Voice - 32 kbit/s Adaptive Differential Pulse Code Modulation (ADPCM) MIME Sub-type Registration |
| |
|
|
This document describes the registration of the MIME sub-type audio/32KADPCM Adaptive Differential Pulse Code Modulation for toll quality audio. This audio encoding is defined by the ITU-T inRecommendation G.726. |
|
| |
| RFC 3803 | Content Duration MIME Header Definition |
| |
|
|
This document describes the MIME header Content-Duration that is intended for use with any time varying media content (typically audio/* or video/*). |
|
| |
| RFC 3804 | Voice Profile for Internet Mail (VPIM) Addressing |
| |
| Authors: | G. Parsons. |
| Date: | June 2004 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 3804 |
|
This document lists the various Voice Profile for Internet Mail(VPIM) email address formats that are currently in common use and defines several new address formats for special case usage.Requirements are imposed on the formats of addresses used in VPIM submission mode. |
|
| |
| RFC 3805 | Printer MIB v2 |
| |
| Authors: | R. Bergman, H. Lewis, I. McDonald. |
| Date: | June 2004 |
| Formats: | txt html json |
| Obsoletes: | RFC 1759 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 3805 |
|
This document provides definitions of models and manageable objects for printing environments. The objects included in this MIB apply to physical, as well as logical entities within a printing device. This document obsoletes RFC 1759. |
|
| |
| RFC 3806 | Printer Finishing MIB |
| |
| Authors: | R. Bergman, H. Lewis, I. McDonald. |
| Date: | June 2004 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 3806 |
|
This document defines a MIB module for the management of printer finishing device subunits. The finishing device subunits applicable to this MIB are an integral part of the Printer System. This MIB applies only to a Finisher Device that is connected to a PrinterSystem. |
|
| |
| RFC 3807 | V5.2-User Adaptation Layer (V5UA) |
| |
| Authors: | E. Weilandt, N. Khanchandani, S. Rao. |
| Date: | June 2004 |
| Formats: | txt json html |
| Updates: | RFC 3057 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 3807 |
|
This document defines a mechanism for the backhauling of V5.2 messages over IP using the Stream Control Transmission Protocol(SCTP). This protocol may be used between a Signaling Gateway (SG) and a Media Gateway controller (MGC). It is assumed that the SG receives V5.2 signaling over a standard V5.2 interface.
This document builds on the ISDN User Adaptation Layer Protocol (RFC3057). It defines all necessary extensions to the IUA Protocol needed for the V5UA protocol implementation. |
|
| |
| RFC 3808 | IANA Charset MIB |
| |
| Authors: | I. McDonald. |
| Date: | June 2004 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 3808 |
|
This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community.This IANA Charset MIB is now an IANA registry. In particular, a single textual convention 'IANACharset' is defined that may be used to specify charset labels in MIB objects. 'IANACharset' was extracted from Printer MIB v2 (RFC 3805). 'IANACharset' was originally defined (and mis-named) as 'CodedCharSet' in Printer MIB v1 (RFC 1759). A tool has been written in C, that may be used byIANA to regenerate this IANA Charset MIB, when future charsets are registered in accordance with the IANA Charset RegistrationProcedures (RFC 2978). |
|
| |
| RFC 3809 | Generic Requirements for Provider Provisioned Virtual Private Networks (PPVPN) |
| |
| Authors: | A. Nagarajan, Ed.. |
| Date: | June 2004 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 3809 |
|
This document describes generic requirements for Provider ProvisionedVirtual Private Networks (PPVPN). The requirements are categorized into service requirements, provider requirements and engineering requirements. These requirements are not specific to any particular type of PPVPN technology, but rather apply to all PPVPN technologies.All PPVPN technologies are expected to meet the umbrella set of requirements described in this document. |
|
| |
| RFC 3810 | Multicast Listener Discovery Version 2 (MLDv2) for IPv6 |
| |
|
|
This document updates RFC 2710, and it specifies Version 2 of theMulticast Listener Discovery Protocol (MLDv2). MLD is used by anIPv6 router to discover the presence of multicast listeners on directly attached links, and to discover which multicast addresses are of interest to those neighboring nodes. MLDv2 is designed to be interoperable with MLDv1. MLDv2 adds the ability for a node to report interest in listening to packets with a particular multicast address only from specific source addresses or from all sources except for specific source addresses. |
|
| |
| RFC 3811 | Definitions of Textual Conventions (TCs) for Multiprotocol Label Switching (MPLS) Management |
| |
| Authors: | T. Nadeau, Ed., J. Cucchiara, Ed.. |
| Date: | June 2004 |
| Formats: | txt html json |
| Updated by: | RFC 7274 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 3811 |
|
This memo defines a Management Information Base (MIB) module which contains Textual Conventions to represent commonly used MultiprotocolLabel Switching (MPLS) management information. The intent is that these TEXTUAL CONVENTIONS (TCs) will be imported and used in MPLS related MIB modules that would otherwise define their own representations. |
|
| |
| RFC 3812 | Multiprotocol Label Switching (MPLS) Traffic Engineering (TE) Management Information Base (MIB) |
| |
| Authors: | C. Srinivasan, A. Viswanathan, T. Nadeau. |
| Date: | June 2004 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 3812 |
|
This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community.In particular, it describes managed objects for Multiprotocol LabelSwitching (MPLS) based traffic engineering (TE). |
|
| |
| RFC 3813 | Multiprotocol Label Switching (MPLS) Label Switching Router (LSR) Management Information Base (MIB) |
| |
| Authors: | C. Srinivasan, A. Viswanathan, T. Nadeau. |
| Date: | June 2004 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 3813 |
|
This memo defines an portion of the Management Information Base (MIB) for use with network management protocols in the Internet community.In particular, it describes managed objects to configure and/or monitor a Multiprotocol Label Switching (MPLS) Label Switching Router(LSR). |
|
| |
| RFC 3814 | Multiprotocol Label Switching (MPLS) Forwarding Equivalence Class To Next Hop Label Forwarding Entry (FEC-To-NHLFE) Management Information Base (MIB) |
| |
| Authors: | T. Nadeau, C. Srinivasan, A. Viswanathan. |
| Date: | June 2004 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 3814 |
|
This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community.In particular, it describes managed objects for defining, configuring, and monitoring Forwarding Equivalence Class (FEC) toNext Hop Label Forwarding Entry (NHLFE) mappings and corresponding actions for use with Multiprotocol Label Switching (MPLS). |
|
| |
| RFC 3815 | Definitions of Managed Objects for the Multiprotocol Label Switching (MPLS), Label Distribution Protocol (LDP) |
| |
| Authors: | J. Cucchiara, H. Sjostrand, J. Luciani. |
| Date: | June 2004 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 3815 |
|
This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community.In particular, it describes managed objects for the MultiprotocolLabel Switching, Label Distribution Protocol (LDP). |
|
| |
| RFC 3816 | Definitions of Managed Objects for RObust Header Compression (ROHC) |
| |
| Authors: | J. Quittek, M. Stiemerling, H. Hartenstein. |
| Date: | June 2004 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 3816 |
|
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 monitoring of running instances of RObust Header Compression (ROHC).The managed objects defined in this memo are grouped into three MIB modules. The ROHC-MIB module defines managed objects shared by allROHC profiles, the ROHC-UNCOMPRESSED-MIB module defines managed objects specific to the ROHC uncompressed profile, the ROHC-RTP-MIB module defines managed objects specific to the ROHC RTP (Real-TimeTransport Protocol) profile, the ROHC UDP (User Datagram Protocol) profile, the ROHC ESP (Encapsulating Security Payload) profile, and the ROHC LLA (Link Layer Assisted) profile. |
|
| |
| RFC 3817 | Layer 2 Tunneling Protocol (L2TP) Active Discovery Relay for PPP over Ethernet (PPPoE) |
| |
| Authors: | W. Townsley, R. da Silva. |
| Date: | June 2004 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 3817 |
|
The Point-to-Point Protocol (PPP) provides a standard method for transporting multi-protocol datagrams over point-to-point links.Layer Two Tunneling Protocol (L2TP), facilitates the tunneling of PPP packets across an intervening packet-switched network. And yet a third protocol, PPP over Ethernet (PPPoE) describes how to build PPP sessions and to encapsulate PPP packets over Ethernet.
L2TP Active Discovery Relay for PPPoE describes a method to relayActive Discovery and Service Selection functionality from PPPoE over the reliable control channel within L2TP. Two new L2TP control message types and associated PPPoE-specific Attribute Value Pairs(AVPs) for L2TP are defined. This relay mechanism provides enhanced integration of a specific feature in the PPPoE tunneling protocol with L2TP. |
|
| |
| RFC 3818 | IANA Considerations for the Point-to-Point Protocol (PPP) |
| |
|
|
The charter of the Point-to-Point Protocol (PPP) Extensions working group (pppext) includes the responsibility to "actively advance PPP's most useful extensions to full standard, while defending against further enhancements of questionable value." In support of that charter, the allocation of PPP protocol and other assigned numbers will no longer be "first come first served." |
|
| |
| RFC 3819 | Advice for Internet Subnetwork Designers |
| |
| Authors: | P. Karn, Ed., C. Bormann, G. Fairhurst, D. Grossman, R. Ludwig, J. Mahdavi, G. Montenegro, J. Touch, L. Wood. |
| Date: | July 2004 |
| Formats: | txt html json |
| Updated by: | RFC 9599 |
| Also: | BCP 0089 |
| Status: | BEST CURRENT PRACTICE |
| DOI: | 10.17487/RFC 3819 |
|
This document provides advice to the designers of digital communication equipment, link-layer protocols, and packet-switched local networks (collectively referred to as subnetworks), who wish to support the Internet protocols but may be unfamiliar with theInternet architecture and the implications of their design choices on the performance and efficiency of the Internet. |
|
| |
| RFC 3820 | Internet X.509 Public Key Infrastructure (PKI) Proxy Certificate Profile |
| |
| Authors: | S. Tuecke, V. Welch, D. Engert, L. Pearlman, M. Thompson. |
| Date: | June 2004 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 3820 |
|
This document forms a certificate profile for Proxy Certificates, based on X.509 Public Key Infrastructure (PKI) certificates as defined in RFC 3280, for use in the Internet. The term ProxyCertificate is used to describe a certificate that is derived from, and signed by, a normal X.509 Public Key End Entity Certificate or by another Proxy Certificate for the purpose of providing restricted proxying and delegation within a PKI based authentication system. |
|
| |
| RFC 3821 | Fibre Channel Over TCP/IP (FCIP) |
| |
| Authors: | M. Rajagopal, E. Rodriguez, R. Weber. |
| Date: | July 2004 |
| Formats: | txt html json |
| Updated by: | RFC 7146 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 3821 |
|
Fibre Channel Over TCP/IP (FCIP) describes mechanisms that allow the interconnection of islands of Fibre Channel storage area networks over IP-based networks to form a unified storage area network in a single Fibre Channel fabric. FCIP relies on IP-based network services to provide the connectivity between the storage area network islands over local area networks, metropolitan area networks, or wide area networks. |
|
| |
| RFC 3822 | Finding Fibre Channel over TCP/IP (FCIP) Entities Using Service Location Protocol version 2 (SLPv2) |
| |
|
|
This document defines the use of Service Location Protocol version 2(SLPv2) by Fibre Channel over TCP/IP (FCIP) Entities. |
|
| |
| RFC 3823 | MIME Media Type for the Systems Biology Markup Language (SBML) |
| |
| Authors: | B. Kovitz. |
| Date: | June 2004 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 3823 |
|
This document registers the MIME sub-type application/sbml+xml, a media type for SBML, the Systems Biology Markup Language. SBML is defined by The SBML Team at the California Institute of Technology and interested members of the systems biology community. |
|
| |
| RFC 3824 | Using E.164 numbers with the Session Initiation Protocol (SIP) |
| |
| Authors: | J. Peterson, H. Liu, J. Yu, B. Campbell. |
| Date: | June 2004 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 3824 |
|
There are a number of contexts in which telephone numbers are employed by Session Initiation Protocol (SIP) applications, many of which can be addressed by ENUM. Although SIP was one of the primary applications for which ENUM was created, there is nevertheless a need to define procedures for integrating ENUM with SIP implementations.This document illustrates how the two protocols might work in concert, and clarifies the authoring and processing of ENUM records for SIP applications. It also provides guidelines for instances in which ENUM, for whatever reason, cannot be used to resolve a telephone number. |
|
| |
| RFC 3825 | Dynamic Host Configuration Protocol Option for Coordinate-based Location Configuration Information |
| |
| Authors: | J. Polk, J. Schnizlein, M. Linsner. |
| Date: | July 2004 |
| Formats: | txt html json |
| Obsoleted by: | RFC 6225 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 3825 |
|
This document specifies a Dynamic Host Configuration Protocol Option for the coordinate-based geographic location of the client. TheLocation Configuration Information (LCI) includes latitude, longitude, and altitude, with resolution indicators for each. The reference datum for these values is also included. |
|
| |
| RFC 3826 | The Advanced Encryption Standard (AES) Cipher Algorithm in the SNMP User-based Security Model |
| |
| Authors: | U. Blumenthal, F. Maino, K. McCloghrie. |
| Date: | June 2004 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 3826 |
|
This document describes a symmetric encryption protocol that supplements the protocols described in the User-based Security Model(USM), which is a Security Subsystem for version 3 of the SimpleNetwork Management Protocol for use in the SNMP Architecture. The symmetric encryption protocol described in this document is based on the Advanced Encryption Standard (AES) cipher algorithm used inCipher FeedBack Mode (CFB), with a key size of 128 bits. |
|
| |
| RFC 3827 | Additional Snoop Datalink Types |
| |
| Authors: | K. Sarcar. |
| Date: | June 2004 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 3827 |
|
The snoop file format provides a way to store and exchange datalink layer packet traces. This document describes extensions to this file format to support new media. |
|
| |
| RFC 3828 | The Lightweight User Datagram Protocol (UDP-Lite) |
| |
| Authors: | L-A. Larzon, M. Degermark, S. Pink, L-E. Jonsson, Ed., G. Fairhurst, Ed.. |
| Date: | July 2004 |
| Formats: | txt html json |
| Updated by: | RFC 6335 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 3828 |
|
This document describes the Lightweight User Datagram Protocol (UDP-Lite), which is similar to the User Datagram Protocol (UDP) (RFC768), but can also serve applications in error-prone network environments that prefer to have partially damaged payloads delivered rather than discarded. If this feature is not used, UDP-Lite is semantically identical to UDP. |
|
| |
| RFC 3829 | Lightweight Directory Access Protocol (LDAP) Authorization Identity Request and Response Controls |
| |
| Authors: | R. Weltman, M. Smith, M. Wahl. |
| Date: | July 2004 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 3829 |
|
This document extends the Lightweight Directory Access Protocol(LDAP) bind operation with a mechanism for requesting and returning the authorization identity it establishes. Specifically, this document defines the Authorization Identity Request and Response controls for use with the Bind operation. |
|
| |
| RFC 3830 | MIKEY: Multimedia Internet KEYing |
| |
| Authors: | J. Arkko, E. Carrara, F. Lindholm, M. Naslund, K. Norrman. |
| Date: | August 2004 |
| Formats: | txt html json |
| Updated by: | RFC 4738, RFC 6309 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 3830 |
|
This document describes a key management scheme that can be used for real-time applications (both for peer-to-peer communication and group communication). In particular, its use to support the Secure Real- time Transport Protocol is described in detail.
Security protocols for real-time multimedia applications have started to appear. This has brought forward the need for a key management solution to support these protocols. |
|
| |
| RFC 3831 | Transmission of IPv6 Packets over Fibre Channel |
| |
|
|
This document specifies the way of encapsulating IPv6 packets overFibre Channel, and the method of forming IPv6 link-local addresses and statelessly autoconfigured addresses on Fibre Channel networks. |
|
| |
| RFC 3832 | Remote Service Discovery in the Service Location Protocol (SLP) via DNS SRV |
| |
| Authors: | W. Zhao, H. Schulzrinne, E. Guttman, C. Bisdikian, W. Jerome. |
| Date: | July 2004 |
| Formats: | txt json html |
| Updated by: | RFC 8553 |
| Status: | EXPERIMENTAL |
| DOI: | 10.17487/RFC 3832 |
|
Remote service discovery refers to discovering desired services in given remote (i.e., non-local) DNS domains. This document describes remote service discovery in the Service Location Protocol (SLP) viaDNS SRV. It defines the DNS SRV Resource Records for SLP DirectoryAgent services, discusses various issues in using SLP and DNS SRV together for remote service discovery, and gives the steps for discovering desired services in remote DNS domains. |
|
| |
| RFC 3833 | Threat Analysis of the Domain Name System (DNS) |
| |
| Authors: | D. Atkins, R. Austein. |
| Date: | August 2004 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 3833 |
|
Although the DNS Security Extensions (DNSSEC) have been under development for most of the last decade, the IETF has never written down the specific set of threats against which DNSSEC is designed to protect. Among other drawbacks, this cart-before-the-horse situation has made it difficult to determine whether DNSSEC meets its design goals, since its design goals are not well specified. This note attempts to document some of the known threats to the DNS, and, in doing so, attempts to measure to what extent (if any) DNSSEC is a useful tool in defending against these threats. |
|
| |
| RFC 3834 | Recommendations for Automatic Responses to Electronic Mail |
| |
|
|
This memo makes recommendations for software that automatically responds to incoming electronic mail messages, including "out of the office" or "vacation" response generators, mail filtering software, email-based information services, and other automatic responders.The purpose of these recommendations is to discourage undesirable behavior which is caused or aggravated by such software, to encourage uniform behavior (where appropriate) among automatic mail responders, and to clear up some sources of confusion among implementors of automatic email responders. |
|
| |
| RFC 3835 | An Architecture for Open Pluggable Edge Services (OPES) |
| |
| Authors: | A. Barbir, R. Penno, R. Chen, M. Hofmann, H. Orman. |
| Date: | August 2004 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 3835 |
|
This memo defines an architecture that enables the creation of an application service in which a data provider, a data consumer, and zero or more application entities cooperatively implement a data stream service. |
|
| |
| RFC 3836 | Requirements for Open Pluggable Edge Services (OPES) Callout Protocols |
| |
| Authors: | A. Beck, M. Hofmann, H. Orman, R. Penno, A. Terzis. |
| Date: | August 2004 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 3836 |
|
This document specifies the requirements that the OPES (OpenPluggable Edge Services) callout protocol must satisfy in order to support the remote execution of OPES services. The requirements are intended to help evaluate possible protocol candidates, as well as to guide the development of such protocols. |
|
| |
| RFC 3837 | Security Threats and Risks for Open Pluggable Edge Services (OPES) |
| |
| Authors: | A. Barbir, O. Batuner, B. Srinivas, M. Hofmann, H. Orman. |
| Date: | August 2004 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 3837 |
|
The document investigates the security threats associated with theOpen Pluggable Edge Services (OPES) and discusses the effects of security threats on the underlying architecture. The main goal of this document is threat discovery and analysis. The document does not specify or recommend any solutions. |
|
| |
| RFC 3838 | Policy, Authorization, and Enforcement Requirements of the Open Pluggable Edge Services (OPES) |
| |
| Authors: | A. Barbir, O. Batuner, A. Beck, T. Chan, H. Orman. |
| Date: | August 2004 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 3838 |
|
This document describes policy, authorization, and enforcement requirements for the selection of the services to be applied to a given Open Pluggable Edge Services (OPES) flow. |
|
| |
| RFC 3839 | MIME Type Registrations for 3rd Generation Partnership Project (3GPP) Multimedia files |
| |
| Authors: | R. Castagno, D. Singer. |
| Date: | July 2004 |
| Formats: | txt html json |
| Updated by: | RFC 6381 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 3839 |
|
This document serves to register and document the standard MIME types associated with the 3GPP multimedia file format, which is part of the family based on the ISO Media File Format. |
|
| |
| RFC 3840 | Indicating User Agent Capabilities in the Session Initiation Protocol (SIP) |
| |
| Authors: | J. Rosenberg, H. Schulzrinne, P. Kyzivat. |
| Date: | August 2004 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 3840 |
|
This specification defines mechanisms by which a Session InitiationProtocol (SIP) user agent can convey its capabilities and characteristics to other user agents and to the registrar for its domain. This information is conveyed as parameters of the Contact header field. |
|
| |
| RFC 3841 | Caller Preferences for the Session Initiation Protocol (SIP) |
| |
| Authors: | J. Rosenberg, H. Schulzrinne, P. Kyzivat. |
| Date: | August 2004 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 3841 |
|
This document describes a set of extensions to the Session InitiationProtocol (SIP) which allow a caller to express preferences about request handling in servers. These preferences include the ability to select which Uniform Resource Identifiers (URI) a request gets routed to, and to specify certain request handling directives in proxies and redirect servers. It does so by defining three new request header fields, Accept-Contact, Reject-Contact, and Request-Disposition, which specify the caller's preferences. |
|
| |
| RFC 3842 | A Message Summary and Message Waiting Indication Event Package for the Session Initiation Protocol (SIP) |
| |
| Authors: | R. Mahy. |
| Date: | August 2004 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 3842 |
|
This document describes a Session Initiation Protocol (SIP) event package to carry message waiting status and message summaries from a messaging system to an interested User Agent. |
|
| |
| RFC 3843 | RObust Header Compression (ROHC): A Compression Profile for IP |
| |
| Authors: | L-E. Jonsson, G. Pelletier. |
| Date: | June 2004 |
| Formats: | txt html json |
| Updated by: | RFC 4815 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 3843 |
|
The original RObust Header Compression (ROHC) RFC (RFC 3095) defines a framework for header compression, along with compression protocols(profiles) for IP/UDP/RTP, IP/ESP (Encapsulating Security Payload),IP/UDP, and also a profile for uncompressed packet streams. However, no profile was defined for compression of IP only, which has been identified as a missing piece in RFC 3095. This document defines aROHC compression profile for IP, similar to the IP/UDP profile defined by RFC 3095, but simplified to exclude UDP, and enhanced to compress IP header chains of arbitrary length. |
|
| |
| RFC 3844 | IETF Problem Resolution Process |
| |
| Authors: | E. Davies, Ed., J. Hofmann, Ed.. |
| Date: | August 2004 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 3844 |
|
This Informational document records the history of discussions in theProblem WG during 2003 of how to resolve the problems described in the IETF Problem Statement. It decomposes each of the problems described into a few areas for improvement and categorizes them as either problems affecting the routine processes used to create standards or problems affecting the fundamental structure and practices of the IETF. Expeditious and non-disruptive solutions are proposed for the problems affecting routine processes.
The document also lists suggested ways to handle the development of solutions for the structure and practices problems proposed in IETF discussions. Neither the working group nor the wider IETF has reached consensus on a recommendation for any of the proposals. This document therefore has no alternative but to suggest that the search for structure and practices solutions be handed back to the control of the IESG.
While there was working group consensus on the processes for short- term and medium term improvements, there was no working group consensus on the proposals for longer-term improvements. This document therefore includes longer-term improvement proposals only as a matter of record; they must not be regarded as recommendations from the working group. |
|
| |
| RFC 3845 | DNS Security (DNSSEC) NextSECure (NSEC) RDATA Format |
| |
|
|
This document redefines the wire format of the "Type Bit Map" field in the DNS NextSECure (NSEC) resource record RDATA format to cover the full resource record (RR) type space. |
|
| |
| RFC 3846 | Mobile IPv4 Extension for Carrying Network Access Identifiers |
| |
| Authors: | F. Johansson, T. Johansson. |
| Date: | June 2004 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 3846 |
|
When a mobile node moves between two foreign networks, it has to be re-authenticated. If the home network has both multipleAuthentication Authorization and Accounting (AAA) servers and HomeAgents (HAs) in use, the Home AAA server may not have sufficient information to process the re-authentication correctly (i.e., to ensure that the same HA continues to be used). This document defines a Mobile IP extension that carries identities for the Home AAA and HA servers in the form of Network Access Identifiers (NAIs). The extension allows a Home Agent to pass its identity (and that of theHome AAA server) to the mobile node, which can then pass it on to the local AAA server when changing its point of attachment. This extension may also be used in other situations requiring communication of a NAI between Mobile IP nodes. |
|
| |
| RFC 3847 | Restart Signaling for Intermediate System to Intermediate System (IS-IS) |
| |
|
|
This document describes a mechanism for a restarting router to signal to its neighbors that it is restarting, allowing them to reestablish their adjacencies without cycling through the down state, while still correctly initiating database synchronization.
This document additionally describes a mechanism for a restarting router to determine when it has achieved LSP database synchronization with its neighbors and a mechanism to optimize LSP database synchronization, while minimizing transient routing disruption when a router starts. |
|
| |
| RFC 3848 | ESMTP and LMTP Transmission Types Registration |
| |
| Authors: | C. Newman. |
| Date: | July 2004 |
| Formats: | txt json html |
| Status: | DRAFT STANDARD |
| DOI: | 10.17487/RFC 3848 |
|
This registers seven new mail transmission types (ESMTPA, ESMTPS,ESMTPSA, LMTP, LMTPA, LMTPS, LMTPSA) for use in the "with" clause of a Received header in an Internet message. |
|
| |
| RFC 3849 | IPv6 Address Prefix Reserved for Documentation |
| |
| Authors: | G. Huston, A. Lord, P. Smith. |
| Date: | July 2004 |
| Formats: | txt json html |
| Updated by: | RFC 9637 |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 3849 |
|
To reduce the likelihood of conflict and confusion when relating documented examples to deployed systems, an IPv6 unicast address prefix is reserved for use in examples in RFCs, books, documentation, and the like. Since site-local and link-local unicast addresses have special meaning in IPv6, these addresses cannot be used in many example situations. The document describes the use of the IPv6 address prefix 2001:DB8::/32 as a reserved prefix for use in documentation. |
|
| |
| RFC 3850 | Secure/Multipurpose Internet Mail Extensions (S/MIME) Version 3.1 Certificate Handling |
| |
|
|
This document specifies conventions for X.509 certificate usage bySecure/Multipurpose Internet Mail Extensions (S/MIME) agents. S/MIME provides a method to send and receive secure MIME messages, and certificates are an integral part of S/MIME agent processing. S/MIME agents validate certificates as described in RFC 3280, the InternetX.509 Public Key Infrastructure Certificate and CRL Profile. S/MIME agents must meet the certificate processing requirements in this document as well as those in RFC 3280. |
|
| |
| RFC 3851 | Secure/Multipurpose Internet Mail Extensions (S/MIME) Version 3.1 Message Specification |
| |
|
|
This document defines Secure/Multipurpose Internet Mail Extensions(S/MIME) version 3.1. S/MIME provides a consistent way to send and receive secure MIME data. Digital signatures provide authentication, message integrity, and non-repudiation with proof of origin.Encryption provides data confidentiality. Compression can be used to reduce data size. This document obsoletes RFC 2633. |
|
| |
| RFC 3852 | Cryptographic Message Syntax (CMS) |
| |
|
|
This document describes the Cryptographic Message Syntax (CMS). This syntax is used to digitally sign, digest, authenticate, or encrypt arbitrary message content. |
|
| |
| RFC 3853 | S/MIME Advanced Encryption Standard (AES) Requirement for the Session Initiation Protocol (SIP) |
| |
|
|
RFC 3261 currently specifies 3DES as the mandatory-to-implement ciphersuite for implementations of S/MIME in the Session InitiationProtocol (SIP). This document updates the normative guidance of RFC3261 to require the Advanced Encryption Standard (AES) for S/MIME. |
|
| |
| RFC 3854 | Securing X.400 Content with Secure/Multipurpose Internet Mail Extensions (S/MIME) |
| |
| Authors: | P. Hoffman, C. Bonatti, A. Eggen. |
| Date: | July 2004 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 3854 |
|
This document describes a protocol for adding cryptographic signature and encryption services to X.400 content with Secure/MultipurposeInternet Mail Extensions (S/MIME). |
|
| |
| RFC 3855 | Transporting Secure/Multipurpose Internet Mail Extensions (S/MIME) Objects in X.400 |
| |
| Authors: | P. Hoffman, C. Bonatti. |
| Date: | July 2004 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 3855 |
|
This document describes protocol options for conveying objects that have been protected using the Cryptographic Message Syntax (CMS) andSecure/Multipurpose Internet Mail Extensions (S/MIME) version 3.1 over an X.400 message transfer system. |
|
| |
| RFC 3856 | A Presence Event Package for the Session Initiation Protocol (SIP) |
| |
|
|
This document describes the usage of the Session Initiation Protocol(SIP) for subscriptions and notifications of presence. Presence is defined as the willingness and ability of a user to communicate with other users on the network. Historically, presence has been limited to "on-line" and "off-line" indicators; the notion of presence here is broader. Subscriptions and notifications of presence are supported by defining an event package within the general SIP event notification framework. This protocol is also compliant with theCommon Presence Profile (CPP) framework. |
|
| |
| RFC 3857 | A Watcher Information Event Template-Package for the Session Initiation Protocol (SIP) |
| |
| Authors: | J. Rosenberg. |
| Date: | August 2004 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 3857 |
|
This document defines the watcher information template-package for the Session Initiation Protocol (SIP) event framework. Watcher information refers to the set of users subscribed to a particular resource within a particular event package. Watcher information changes dynamically as users subscribe, unsubscribe, are approved, or are rejected. A user can subscribe to this information, and therefore learn about changes to it. This event package is a template-package because it can be applied to any event package, including itself. |
|
| |
| RFC 3858 | An Extensible Markup Language (XML) Based Format for Watcher Information |
| |
| Authors: | J. Rosenberg. |
| Date: | August 2004 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 3858 |
|
Watchers are defined as entities that request (i.e., subscribe to) information about a resource. There is fairly complex state associated with these subscriptions. The union of the state for all subscriptions to a particular resource is called the watcher information for that resource. This state is dynamic, changing as subscribers come and go. As a result, it is possible, and indeed useful, to subscribe to the watcher information for a particular resource. In order to enable this, a format is needed to describe the state of watchers on a resource. This specification describes anExtensible Markup Language (XML) document format for such state. |
|
| |
| RFC 3859 | Common Profile for Presence (CPP) |
| |
| Authors: | J. Peterson. |
| Date: | August 2004 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 3859 |
|
At the time this document was written, numerous presence protocols were in use (largely as components of commercial instant messaging services), and little interoperability between services based on these protocols has been achieved. This specification defines common semantics and data formats for presence to facilitate the creation of gateways between presence services. |
|
| |
| RFC 3860 | Common Profile for Instant Messaging (CPIM) |
| |
| Authors: | J. Peterson. |
| Date: | August 2004 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 3860 |
|
At the time this document was written, numerous instant messaging protocols were in use, and little interoperability between services based on these protocols has been achieved. This specification defines common semantics and data formats for instant messaging to facilitate the creation of gateways between instant messaging services. |
|
| |
| RFC 3861 | Address Resolution for Instant Messaging and Presence |
| |
| Authors: | J. Peterson. |
| Date: | August 2004 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 3861 |
|
Presence and instant messaging are defined in RFC 2778. The CommonProfiles for Presence and Instant Messaging define two UniversalResource Identifier (URI) schemes: 'im' for INSTANT INBOXes and'pres' for PRESENTITIES. This document provides guidance for locating the resources associated with URIs that employ these schemes. |
|
| |
| RFC 3862 | Common Presence and Instant Messaging (CPIM): Message Format |
| |
| Authors: | G. Klyne, D. Atkins. |
| Date: | August 2004 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 3862 |
|
This memo defines the MIME content type 'Message/CPIM', a message format for protocols that conform to the Common Profile for InstantMessaging (CPIM) specification. |
|
| |
| RFC 3863 | Presence Information Data Format (PIDF) |
| |
| Authors: | H. Sugano, S. Fujimoto, G. Klyne, A. Bateman, W. Carr, J. Peterson. |
| Date: | August 2004 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 3863 |
|
This memo specifies the Common Profile for Presence (CPP) PresenceInformation Data Format (PIDF) as a common presence data format forCPP-compliant Presence protocols, and also defines a new media type"application/pidf+xml" to represent the XML MIME entity for PIDF. |
|
| |
| RFC 3864 | Registration Procedures for Message Header Fields |
| |
|
|
This specification defines registration procedures for the message header fields used by Internet mail, HTTP, Netnews and other applications. |
|
| |
| RFC 3865 | A No Soliciting Simple Mail Transfer Protocol (SMTP) Service Extension |
| |
| Authors: | C. Malamud. |
| Date: | September 2004 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 3865 |
|
This document proposes an extension to Soliciting Simple MailTransfer Protocol (SMTP) for an electronic mail equivalent to the real-world "No Soliciting" sign. In addition to the service extension, a new message header and extensions to the existing"received" message header are described. |
|
| |
| RFC 3866 | Language Tags and Ranges in the Lightweight Directory Access Protocol (LDAP) |
| |
|
|
It is often desirable to be able to indicate the natural language associated with values held in a directory and to be able to query the directory for values which fulfill the user's language needs.This document details the use of Language Tags and Ranges in theLightweight Directory Access Protocol (LDAP). |
|
| |
| RFC 3867 | Payment Application Programmers Interface (API) for v1.0 Internet Open Trading Protocol (IOTP) |
| |
| Authors: | Y. Kawatsura, M. Hiroya, H. Beykirch. |
| Date: | November 2004 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 3867 |
|
The Internet Open Trading Protocol (IOTP) provides a data exchange format for trading purposes while integrating existing pure payment protocols seamlessly. This motivates the multiple layered system architecture which consists of at least some generic IOTP application core and multiple specific payment modules.
This document addresses a common interface between the IOTP application core and the payment modules, enabling the interoperability between these kinds of modules. Furthermore, such an interface provides the foundations for a plug-in-mechanism in actual implementations of IOTP application cores.
Such interfaces exist at the Consumers', the Merchants' and thePayment Handlers' installations connecting the IOTP application core and the payment software components/legacy systems. |
|
| |
| RFC 3868 | Signalling Connection Control Part User Adaptation Layer (SUA) |
| |
| Authors: | J. Loughney, Ed., G. Sidebottom, L. Coene, G. Verwimp, J. Keller, B. Bidulock. |
| Date: | October 2004 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 3868 |
|
This document defines a protocol for the transport of any SignallingConnection Control Part-User signalling over IP using the StreamControl Transmission Protocol. The protocol is designed to be modular and symmetric, to allow it to work in diverse architectures, such as a Signalling Gateway to IP Signalling Endpoint architecture as well as a peer-to-peer IP Signalling Endpoint architecture. |
|
| |
| RFC 3869 | IAB Concerns and Recommendations Regarding Internet Research and Evolution |
| |
| Authors: | R. Atkinson, Ed., S. Floyd, Ed., Internet Architecture Board. |
| Date: | August 2004 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 3869 |
|
This document discusses IAB concerns that ongoing research is needed to further the evolution of the Internet infrastructure, and that consistent, sufficient non-commercial funding is needed to enable such research. |
|
| |
| RFC 3870 | application/rdf+xml Media Type Registration |
| |
| Authors: | A. Swartz. |
| Date: | September 2004 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 3870 |
|
This document describes a media type (application/rdf+xml) for use with the Extensible Markup Language (XML) serialization of theResource Description Framework (RDF). RDF is a language designed to support the Semantic Web, by facilitating resource description and data exchange on the Web. RDF provides common structures that can be used for interoperable data exchange and follows the World Wide WebConsortium (W3C) design principles of interoperability, evolution, and decentralization. |
|
| |
| RFC 3871 | Operational Security Requirements for Large Internet Service Provider (ISP) IP Network Infrastructure |
| |
|
|
This document defines a list of operational security requirements for the infrastructure of large Internet Service Provider (ISP) IP networks (routers and switches). A framework is defined for specifying "profiles", which are collections of requirements applicable to certain network topology contexts (all, core-only, edge-only...). The goal is to provide network operators a clear, concise way of communicating their security requirements to vendors. |
|
| |
| RFC 3872 | Management Information Base for Telephony Routing over IP (TRIP) |
| |
| Authors: | D. Zinman, D. Walker, J. Jiang. |
| Date: | September 2004 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 3872 |
|
This memo defines a portion of the Management Information Base (MIB) module for use with network management protocols in the Internet community. In particular, it describes a set of managed objects that are used to manage Telephony Routing over IP (TRIP) devices. |
|
| |
| RFC 3873 | Stream Control Transmission Protocol (SCTP) Management Information Base (MIB) |
| |
| Authors: | J. Pastor, M. Belinchon. |
| Date: | September 2004 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 3873 |
|
The Stream Control Transmission Protocol (SCTP) is a reliable transport protocol operating on top of a connectionless packet network such as IP. It is designed to transport public switched telephone network (PSTN) signaling messages over the connectionless packet network, but is capable of broader applications.
This memo defines the Management Information Base (MIB) module which describes the minimum set of objects needed to manage the implementation of the SCTP. |
|
| |
| RFC 3874 | A 224-bit One-way Hash Function: SHA-224 |
| |
| Authors: | R. Housley. |
| Date: | September 2004 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 3874 |
|
This document specifies a 224-bit one-way hash function, calledSHA-224. SHA-224 is based on SHA-256, but it uses a different initial value and the result is truncated to 224 bits. |
|
| |
| RFC 3875 | The Common Gateway Interface (CGI) Version 1.1 |
| |
| Authors: | D. Robinson, K. Coar. |
| Date: | October 2004 |
| Formats: | txt json pdf html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 3875 |
|
The Common Gateway Interface (CGI) is a simple interface for running external programs, software or gateways under an information server in a platform-independent manner. Currently, the supported information servers are HTTP servers.
The interface has been in use by the World-Wide Web (WWW) since 1993.This specification defines the 'current practice' parameters of the'CGI/1.1' interface developed and documented at the U.S. NationalCentre for Supercomputing Applications. This document also defines the use of the CGI/1.1 interface on UNIX(R) and other, similar systems. |
|
| |
| RFC 3876 | Returning Matched Values with the Lightweight Directory Access Protocol version 3 (LDAPv3) |
| |
| Authors: | D. Chadwick, S. Mullan. |
| Date: | September 2004 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 3876 |
|
This document describes a control for the Lightweight DirectoryAccess Protocol version 3 that is used to return a subset of attribute values from an entry. Specifically, only those values that match a "values return" filter. Without support for this control, a client must retrieve all of an attribute's values and search for specific values locally. |
|
| |
| RFC 3877 | Alarm Management Information Base (MIB) |
| |
| Authors: | S. Chisholm, D. Romascanu. |
| Date: | September 2004 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 3877 |
|
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 management objects used for modelling and storing alarms. |
|
| |
| RFC 3878 | Alarm Reporting Control Management Information Base (MIB) |
| |
| Authors: | H. Lam, A. Huynh, D. Perkins. |
| Date: | September 2004 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 3878 |
|
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 controlling the reporting of alarm conditions. |
|
| |
| RFC 3879 | Deprecating Site Local Addresses |
| |
| Authors: | C. Huitema, B. Carpenter. |
| Date: | September 2004 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 3879 |
|
This document describes the issues surrounding the use of IPv6 site- local unicast addresses in their original form, and formally deprecates them. This deprecation does not prevent their continued use until a replacement has been standardized and implemented. |
|
| |
| RFC 3880 | Call Processing Language (CPL): A Language for User Control of Internet Telephony Services |
| |
| Authors: | J. Lennox, X. Wu, H. Schulzrinne. |
| Date: | October 2004 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 3880 |
|
This document defines the Call Processing Language (CPL), a language to describe and control Internet telephony services. It is designed to be implementable on either network servers or user agents. It is meant to be simple, extensible, easily edited by graphical clients, and independent of operating system or signalling protocol. It is suitable for running on a server where users may not be allowed to execute arbitrary programs, as it has no variables, loops, or ability to run external programs. |
|
| |
| RFC 3881 | Security Audit and Access Accountability Message XML Data Definitions for Healthcare Applications |
| |
| Authors: | G. Marshall. |
| Date: | September 2004 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 3881 |
|
This document defines the format of data to be collected and minimum set of attributes that need to be captured for security auditing in healthcare application systems. The format is defined as an XML schema, which is intended as a reference for healthcare standards developers and application designers. It consolidates several previous documents on security auditing of healthcare data. |
|
| |
| RFC 3882 | Configuring BGP to Block Denial-of-Service Attacks |
| |
| Authors: | D. Turk. |
| Date: | September 2004 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 3882 |
|
This document describes an operational technique that uses BGP communities to remotely trigger black-holing of a particular destination network to block denial-of-service attacks. Black-holing can be applied on a selection of routers rather than all BGP-speaking routers in the network. The document also describes a sinkhole tunnel technique using BGP communities and tunnels to pull traffic into a sinkhole router for analysis. |
|
| |
| RFC 3883 | Detecting Inactive Neighbors over OSPF Demand Circuits (DC) |
| |
| Authors: | S. Rao, A. Zinin, A. Roy. |
| Date: | October 2004 |
| Formats: | txt html json |
| Updates: | RFC 1793 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 3883 |
|
OSPF is a link-state intra-domain routing protocol used in IP networks. OSPF behavior over demand circuits (DC) is optimized inRFC 1793 to minimize the amount of overhead traffic. A part of theOSPF demand circuit extensions is the Hello suppression mechanism.This technique allows a demand circuit to go down when no interesting traffic is going through the link. However, it also introduces a problem, where it becomes impossible to detect an OSPF-inactive neighbor over such a link. This memo introduces a new mechanism called "neighbor probing" to address the above problem. |
|
| |
| RFC 3884 | Use of IPsec Transport Mode for Dynamic Routing |
| |
| Authors: | J. Touch, L. Eggert, Y. Wang. |
| Date: | September 2004 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 3884 |
|
IPsec can secure the links of a multihop network to protect communication between trusted components, e.g., for a secure virtual network (VN), overlay, or virtual private network (VPN). Virtual links established by IPsec tunnel mode can conflict with routing and forwarding inside VNs because IP routing depends on references to interfaces and next-hop IP addresses. The IPsec tunnel mode specification is ambiguous on this issue, so even compliant implementations cannot be trusted to avoid conflicts. An alternative to tunnel mode uses non-IPsec IPIP encapsulation together with IPsec transport mode, which we call IIPtran. IPIP encapsulation occurs as a separate initial step, as the result of a forwarding lookup of theVN packet. IPsec transport mode processes the resulting (tunneled) IP packet with an SA determined through a security association database(SAD) match on the tunnel header. IIPtran supports dynamic routing inside the VN without changes to the current IPsec architecture.IIPtran demonstrates how to configure any compliant IPsec implementation to avoid the aforementioned conflicts. IIPtran is also compared to several alternative mechanisms for VN routing and their respective impact on IPsec, routing, policy enforcement, and interactions with the Internet Key Exchange (IKE). |
|
| |
| RFC 3885 | SMTP Service Extension for Message Tracking |
| |
| Authors: | E. Allman, T. Hansen. |
| Date: | September 2004 |
| Formats: | txt json html |
| Updates: | RFC 3461 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 3885 |
|
This memo defines an extension to the SMTP service whereby a client may mark a message for future tracking. |
|
| |
| RFC 3886 | An Extensible Message Format for Message Tracking Responses |
| |
|
|
Message Tracking is expected to be used to determine the status of undelivered e-mail upon request. Tracking is used in conjunction with Delivery Status Notifications (DSN) and Message DispositionNotifications (MDN); generally, a message tracking request will be issued only when a DSN or MDN has not been received within a reasonable timeout period.
This memo defines a MIME content-type for message tracking status in the same spirit as RFC 3464, "An Extensible Message Format forDelivery Status Notifications". It is to be issued upon a request as described in "Message Tracking Query Protocol". This memo defines only the format of the status information. An extension to SMTP to label messages for further tracking and request tracking status is defined in a separate memo. |
|
| |
| RFC 3887 | Message Tracking Query Protocol |
| |
|
|
Customers buying enterprise message systems often ask: Can I track the messages? Message tracking is the ability to find out the path that a particular message has taken through a messaging system and the current routing status of that message. This document describes the Message Tracking Query Protocol that is used in conjunction with extensions to the ESMTP protocol to provide a complete message tracking solution for the Internet. |
|
| |
| RFC 3888 | Message Tracking Model and Requirements |
| |
| Authors: | T. Hansen. |
| Date: | September 2004 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 3888 |
|
Customers buying enterprise message systems often ask: Can I track the messages? Message tracking is the ability to find out the path that a particular message has taken through a messaging system and the current routing status of that message. This document provides a model of message tracking that can be used for understanding theInternet-wide message infrastructure and to further enhance those capabilities to include message tracking, as well as requirements for proposed message tracking solutions. |
|
| |
| RFC 3890 | A Transport Independent Bandwidth Modifier for the Session Description Protocol (SDP) |
| |
| Authors: | M. Westerlund. |
| Date: | September 2004 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 3890 |
|
This document defines a Session Description Protocol (SDP) TransportIndependent Application Specific Maximum (TIAS) bandwidth modifier that does not include transport overhead; instead an additional packet rate attribute is defined. The transport independent bit-rate value together with the maximum packet rate can then be used to calculate the real bit-rate over the transport actually used.
The existing SDP bandwidth modifiers and their values include the bandwidth needed for the transport and IP layers. When using SDP with protocols like the Session Announcement Protocol (SAP), theSession Initiation Protocol (SIP), and the Real-Time StreamingProtocol (RTSP), and when the involved hosts has different transport overhead, for example due to different IP versions, the interpretation of what lower layer bandwidths are included is not clear. |
|
| |
| RFC 3891 | The Session Initiation Protocol (SIP) "Replaces" Header |
| |
| Authors: | R. Mahy, B. Biggs, R. Dean. |
| Date: | September 2004 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 3891 |
|
This document defines a new header for use with Session InitiationProtocol (SIP) multi-party applications and call control. TheReplaces header is used to logically replace an existing SIP dialog with a new SIP dialog. This primitive can be used to enable a variety of features, for example: "Attended Transfer" and "CallPickup". Note that the definition of these example features is non- normative. |
|
| |
| RFC 3892 | The Session Initiation Protocol (SIP) Referred-By Mechanism |
| |
|
|
The Session Initiation Protocol (SIP) REFER method provides a mechanism where one party (the referrer) gives a second party (the referee) an arbitrary URI to reference. If that URI is a SIP URI, the referee will send a SIP request, often an INVITE, to that URI(the refer target). This document extends the REFER method, allowing the referrer to provide information about the REFER request to the refer target using the referee as an intermediary. This information includes the identity of the referrer and the URI to which the referrer referred. The mechanism utilizes S/MIME to help protect this information from a malicious intermediary. This protection is optional, but a recipient may refuse to accept a request unless it is present. |
|
| |
| RFC 3893 | Session Initiation Protocol (SIP) Authenticated Identity Body (AIB) Format |
| |
| Authors: | J. Peterson. |
| Date: | September 2004 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 3893 |
|
RFC 3261 introduces the concept of adding an S/MIME body to a SessionInitiation Protocol (SIP) request or response in order to provide reference integrity over its headers. This document provides a more specific mechanism to derive integrity and authentication properties from an 'authenticated identity body', a digitally-signed SIP message, or message fragment. A standard format for such bodies(known as Authenticated Identity Bodies, or AIBs) is given in this document. Some considerations for the processing of AIBs by recipients of SIP messages with such bodies are also given. |
|
| |
| RFC 3894 | Sieve Extension: Copying Without Side Effects |
| |
| Authors: | J. Degener. |
| Date: | October 2004 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 3894 |
|
The Sieve scripting language allows users to control handling and disposal of their incoming e-mail. By default, an e-mail message that is processed by a Sieve script is saved in the owner's "inbox".Actions such as "fileinto" and "redirect" cancel this default behavior.
This document defines a new keyword parameter, ":copy", to be used with the Sieve "fileinto" and "redirect" actions. Adding ":copy" to an action suppresses cancellation of the default "inbox" save. It allows users to add commands to an existing script without changing the meaning of the rest of the script. |
|
| |
| RFC 3895 | Definitions of Managed Objects for the DS1, E1, DS2, and E2 Interface Types |
| |
|
|
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 DS1, E1, DS2 and E2 interfaces. This document is a companion to the documents that define Managed Objects for the DS0, DS3/E3 and SynchronousOptical Network/Synchronous Digital Hierarchy (SONET/SDH) InterfaceTypes. This document obsoletes RFC 2495. |
|
| |
| RFC 3896 | Definitions of Managed Objects for the DS3/E3 Interface Type |
| |
|
|
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 DS3 and E3 interfaces. This document is a companion to the documents that define Managed Objects for the DS0, DS1/E1/DS2/E2 and SynchronousOptical Network/Synchronous Digital Hierarchy (SONET/SDH) InterfaceTypes. This document obsoletes RFC 2496. |
|
| |
| RFC 3897 | Open Pluggable Edge Services (OPES) Entities and End Points Communication |
| |
| Authors: | A. Barbir. |
| Date: | September 2004 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 3897 |
|
This memo documents tracing and non-blocking (bypass) requirements for Open Pluggable Edge Services (OPES). |
|
| |
| RFC 3898 | Network Information Service (NIS) Configuration Options for Dynamic Host Configuration Protocol for IPv6 (DHCPv6) |
| |
| Authors: | V. Kalusivalingam. |
| Date: | October 2004 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 3898 |
|
This document describes four options for Network Information Service(NIS) related configuration information in Dynamic Host ConfigurationProtocol for IPv6 (DHCPv6): NIS Servers, NIS+ Servers, NIS ClientDomain Name, NIS+ Client Domain name. |
|
