Internet Society Frontpage

Search/Site Map Membership
About the Internet Standards
Publications Public Policy
About ISOC Education

Publications 

Become an ISOC Member

Internet Documents

RFCs 3800 - 3899s

RFCs All DocumentsSTDs Internet Standards DocumentsBCPs Best Current Practice DocumentsFYIs Informational Documents
 

 
RFC 3801 Voice Profile for Internet Mail - version 2 (VPIMv2)
 
Authors:G. Vaudreuil, G. Parsons.
Date:June 2004
Formats:txt pdf
Obsoletes:RFC 2421, RFC 2423
Status:DRAFT STANDARD
DOI:10.17487/RFC 3801
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
 
Authors:G. Vaudreuil, G. Parsons.
Date:June 2004
Formats:txt pdf
Obsoletes:RFC 2422
Status:DRAFT STANDARD
DOI:10.17487/RFC 3802
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
 
Authors:G. Vaudreuil, G. Parsons.
Date:June 2004
Formats:txt pdf
Obsoletes:RFC 2424
Status:DRAFT STANDARD
DOI:10.17487/RFC 3803
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 pdf
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 pdf
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 pdf
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 pdf
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 pdf
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 pdf
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
 
Authors:R. Vida, Ed., L. Costa, Ed..
Date:June 2004
Formats:txt pdf
Updates:RFC 2710
Updated by:RFC 4604
Status:PROPOSED STANDARD
DOI:10.17487/RFC 3810
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 pdf
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 pdf
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 pdf
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 pdf
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 pdf
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 pdf
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 pdf
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)
 
Authors:V. Schryver.
Date:June 2004
Formats:txt pdf
Also:BCP 0088
Status:BEST CURRENT PRACTICE
DOI:10.17487/RFC 3818
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 pdf
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 pdf
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 pdf
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)
 
Authors:D. Peterson.
Date:July 2004
Formats:txt pdf
Updated by:RFC 7146
Status:PROPOSED STANDARD
DOI:10.17487/RFC 3822
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 pdf
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 pdf
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 pdf
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 pdf
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 pdf
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 pdf
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 pdf
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 pdf
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
 
Authors:C. DeSanti.
Date:July 2004
Formats:txt pdf
Obsoleted by:RFC 4338
Status:PROPOSED STANDARD
DOI:10.17487/RFC 3831
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 pdf
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 pdf
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
 
Authors:K. Moore.
Date:August 2004
Formats:txt pdf
Updated by:RFC 5436
Status:PROPOSED STANDARD
DOI:10.17487/RFC 3834
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 pdf
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 pdf
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 pdf
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 pdf
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 pdf
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 pdf
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 pdf
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 pdf
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 pdf
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 pdf
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
 
Authors:J. Schlyter, Ed..
Date:August 2004
Formats:txt pdf
Obsoleted by:RFC 4033, RFC 4034, RFC 4035
Updates:RFC 3755, RFC 2535
Status:PROPOSED STANDARD
DOI:10.17487/RFC 3845
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 pdf
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)
 
Authors:M. Shand, L. Ginsberg.
Date:July 2004
Formats:txt pdf
Obsoleted by:RFC 5306
Status:INFORMATIONAL
DOI:10.17487/RFC 3847
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 pdf
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 pdf
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
 
Authors:B. Ramsdell, Ed..
Date:July 2004
Formats:txt pdf
Obsoletes:RFC 2632
Obsoleted by:RFC 5750
Status:PROPOSED STANDARD
DOI:10.17487/RFC 3850
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
 
Authors:B. Ramsdell, Ed..
Date:July 2004
Formats:txt pdf
Obsoletes:RFC 2633
Obsoleted by:RFC 5751
Status:PROPOSED STANDARD
DOI:10.17487/RFC 3851
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)
 
Authors:R. Housley.
Date:July 2004
Formats:txt pdf
Obsoletes:RFC 3369
Obsoleted by:RFC 5652
Updated by:RFC 4853, RFC 5083
Status:PROPOSED STANDARD
DOI:10.17487/RFC 3852
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)
 
Authors:J. Peterson.
Date:July 2004
Formats:txt pdf
Updates:RFC 3261
Status:PROPOSED STANDARD
DOI:10.17487/RFC 3853
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 pdf
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 pdf
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)
 
Authors:J. Rosenberg.
Date:August 2004
Formats:txt pdf
Status:PROPOSED STANDARD
DOI:10.17487/RFC 3856
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 pdf
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 pdf
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 pdf
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 pdf
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 pdf
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 pdf
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 pdf
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
 
Authors:G. Klyne, M. Nottingham, J. Mogul.
Date:September 2004
Formats:txt pdf
Also:BCP 0090
Status:BEST CURRENT PRACTICE
DOI:10.17487/RFC 3864
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 pdf
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)
 
Authors:K. Zeilenga, Ed..
Date:July 2004
Formats:txt pdf
Obsoletes:RFC 2596
Status:PROPOSED STANDARD
DOI:10.17487/RFC 3866
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 pdf
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 pdf
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 pdf
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 pdf
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
 
Authors:G. Jones, Ed..
Date:September 2004
Formats:txt pdf
Status:INFORMATIONAL
DOI:10.17487/RFC 3871
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 pdf
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 pdf
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 pdf
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 pdf
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 pdf
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 pdf
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 pdf
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 pdf
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 pdf
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 pdf
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 pdf
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 pdf
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 pdf
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 pdf
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
 
Authors:E. Allman.
Date:September 2004
Formats:txt pdf
Updates:RFC 3463
Status:PROPOSED STANDARD
DOI:10.17487/RFC 3886
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
 
Authors:T. Hansen.
Date:September 2004
Formats:txt pdf
Status:PROPOSED STANDARD
DOI:10.17487/RFC 3887
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 pdf
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 pdf
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 pdf
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
 
Authors:R. Sparks.
Date:September 2004
Formats:txt pdf
Status:PROPOSED STANDARD
DOI:10.17487/RFC 3892
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 pdf
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 pdf
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
 
Authors:O. Nicklass, Ed..
Date:September 2004
Formats:txt pdf
Obsoletes:RFC 2495
Obsoleted by:RFC 4805
Status:PROPOSED STANDARD
DOI:10.17487/RFC 3895
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
 
Authors:O. Nicklass, Ed..
Date:September 2004
Formats:txt pdf
Obsoletes:RFC 2496
Status:PROPOSED STANDARD
DOI:10.17487/RFC 3896
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 pdf
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 pdf
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.