Movatterモバイル変換
[0]ホーム
[RFC Home] [TEXT|PDF|HTML] [Tracker] [IPR] [Info page]
INFORMATIONAL
Network Working Group S. GinozaRequest for Comments: 3599 ISICategory: Informational December 2003Request for Comments Summary RFC Numbers 3500-3599Status of This Memo This RFC is a slightly annotated list of the 100 RFCs fromRFC 3500 throughRFC 3599. This is a status report on these RFCs. This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.Copyright Notice Copyright (C) The Internet Society (2003). All Rights Reserved.Note Many RFCs, but not all, are Proposed Standards, Draft Standards, or Standards. Since the status of these RFCs may change during the standards processing, we note here only that they are on the standards track. Please see the latest edition of "Internet Official Protocol Standards" for the current state and status of these RFCs. In the following, RFCs on the standards track are marked [STANDARDS TRACK].RFC Author Date Title--- ------ ---- -----3599 Ginoza Request for Comments SummaryThis memo.3598 Murchison Sep 2003 Sieve Email Filtering -- Subaddress ExtensionOn email systems that allow for "subaddressing" or "detailed addressing"(e.g., "ken+sieve@example.org"), it is sometimes desirable to makecomparisons against these sub-parts of addresses. This document definesan extension to the Sieve mail filtering language that allows users tocompare against the user and detail parts of an address. [STANDARDSTRACK]Ginoza Informational [Page 1]
RFC 3599 Summary of 3500-3599 December 20033597 Gustafsson Sep 2003 Handling of Unknown DNS Resource Record (RR) TypesExtending the Domain Name System (DNS) with new Resource Record (RR)types currently requires changes to name server software. This documentspecifies the changes necessary to allow future DNS implementations tohandle new RR types transparently. [STANDARDS TRACK]3596 Thomson Oct 2003 DNS Extensions to Support IP Version 6This document defines the changes that need to be made to the DomainName System (DNS) to support hosts running IP version 6 (IPv6). Thechanges include a resource record type to store an IPv6 address, adomain to support lookups based on an IPv6 address, and updateddefinitions of existing query types that return Internet addresses aspart of additional section processing. The extensions are designed tobe compatible with existing applications and, in particular, DNSimplementations themselves. [STANDARDS TRACK]3595 Wijnen Sep 2003 Textual Conventions for IPv6 Flow LabelThis MIB module defines textual conventions to represent the commonlyused IPv6 Flow Label. The intent is that these textual conventions(TCs) will be imported and used in MIB modules that would otherwisedefine their own representations. [STANDARDS TRACK]3594 Duffy Sep 2003 PacketCable Security Ticket Control Sub-Option for the DHCP CableLabs Client Configuration (CCC) OptionThis document defines a new sub-option for the DHCP CableLabs ClientConfiguration (CCC) Option. This new sub-option will be used to directCableLabs Client Devices (CCDs) to invalidate security tickets stored inCCD non volatile memory (i.e., locally persisted security tickets).[STANDARDS TRACK]Ginoza Informational [Page 2]
RFC 3599 Summary of 3500-3599 December 20033593 Tesink, Ed. Sep 2003 Textual Conventions for MIB Modules Using Performance History Based on 15 Minute IntervalsThis document defines a set of Textual Conventions for MIB modules thatmake use of performance history data based on 15 minute intervals.This memo replacesRFC 2493. Changes relative toRFC 2493 aresummarized in the MIB module's REVISION clause. [STANDARDS TRACK]3592 Tesink Sep 2003 Definitions of Managed Objects for the Synchronous Optical Network/Synchronous Digital Hierarchy (SONET/SDH) Interface TypeThis memo defines a portion of the Management Information Base (MIB) foruse with network management protocols in TCP/IP-based internets. Inparticular, it defines objects for managing Synchronous OpticalNetwork/Synchronous Digital Hierarchy (SONET/SDH) interfaces. Thisdocument is a companion to the documents that define Managed Objects forthe DS1/E1/DS2/E2 and DS3/E3 Interface Types.This memo replacesRFC 2558. Changes relative toRFC 2558 aresummarized in the MIB module's REVISION clause. [STANDARDS TRACK]3591 Lam Sep 2003 Definitions of Managed Objects for the Optical Interface TypeThis memo defines a portion of the Management Information Base (MIB) foruse with Simple Network Management Protocol (SNMP) in TCP/IP-basedinternets. In particular, it defines objects for managing OpticalInterfaces associated with WavelengthDivision Multiplexing systems orcharacterized by the Optical Transport Network (OTN) in accordance withthe OTN architecture defined in ITU-T Recommendation G.872.The MIB module defined in this memo can be used for performancemonitoring and/or configuration of such optical interface. [STANDARDSTRACK]Ginoza Informational [Page 3]
RFC 3599 Summary of 3500-3599 December 20033590 Haberman Sep 2003 Source Address Selection for the Multicast Listener Discovery (MLD) ProtocolIt has come to light that there is an issue with the selection of asuitable IPv6 source address for Multicast Listener Discovery (MLD)messages when a node is performing stateless address autoconfiguration.This document is intended to clarify the rules on selecting an IPv6address to use for MLD messages. [STANDARDS TRACK]3589 Loughney Sep 2003 Diameter Command Codes for Third Generation Partnership Project (3GPP) Release 5This document describes the IANA's allocation of a block of DiameterCommand Codes for the Third Generation Partnership Project (3GPP)Release 5. This document does not pass judgment on the usage of thesecommand codes. Further more, these command codes are for use forRelease 5. For future releases, these codes cannot be reused, but mustbe allocated according to the Diameter Base specification. This memoprovides information for the Internet community.3588 Calhoun Sep 2003 Diameter Base ProtocolThe Diameter base protocol is intended to provide an Authentication,Authorization and Accounting (AAA) framework for applications such asnetwork access or IP mobility. Diameter is also intended to work inboth local Authentication, Authorization & Accounting and roamingsituations. This document specifies the message format, transport,error reporting, accounting and security services to be used by allDiameter applications. The Diameter base application needs to besupported by all Diameter implementations. [STANDARDS TRACK]3587 Hinden Aug 2003 IPv6 Global Unicast Address FormatThis document obsoletesRFC 2374, "An IPv6 Aggregatable Global UnicastAddress Format". It defined an IPv6 address allocation structure thatincludes Top Level Aggregator (TLA) and Next Level Aggregator (NLA).This document makesRFC 2374 and the TLA/NLA structure historic. Thismemo provides information for the Internet community.Ginoza Informational [Page 4]
RFC 3599 Summary of 3500-3599 December 20033586 Blaze Aug 2003 IP Security Policy (IPSP) RequirementsThis document describes the problem space and solution requirements fordeveloping an IP Security Policy (IPSP) configuration and managementframework. The IPSP architecture provides a scalable, decentralizedframework for managing, discovering and negotiating the host and networksecurity policies that govern access, authorization, authentication,confidentiality, data integrity, and other IP Security properties. Thisdocument highlights such architectural components and presents theirfunctional requirements. [STANDARDS TRACK]3585 Jason Aug 2003 IPsec Configuration Policy Information ModelThis document presents an object-oriented information model of IPSecurity (IPsec) policy designed to facilitate agreement about thecontent and semantics of IPsec policy, and enable derivations of task-specific representations of IPsec policy such as storage schema,distribution representations, and policy specification languages used toconfigure IPsec-enabled endpoints. The information model described inthis document models the configuration parameters defined by IPSec. Theinformation model also covers the parameters found by the Internet KeyExchange protocol (IKE). Other key exchange protocols could easily beadded to the information model by a simple extension. Furtherextensions can further be added easily due to the object-oriented natureof the model.This information model is based upon the core policy classes as definedin the Policy Core Information Model (PCIM) and in the Policy CoreInformation Model Extensions (PCIMe). [STANDARDS TRACK]3584 Frye Aug 2003 Coexistence between Version 1, Version 2, and Version 3 of the Internet-standard Network Management FrameworkThe purpose of this document is to describe coexistence between version3 of the Internet-standard Network Management Framework, (SNMPv3),version 2 of the Internet-standard Network Management Framework(SNMPv2), and the original Internet-standard Network ManagementFramework (SNMPv1). This document also describes how to convert MIBmodules from SMIv1 format to SMIv2 format. This document obsoletes RFC2576. This document specifies an Internet Best Current Practices forthe Internet Community, and requests discussion and suggestions forimprovements.Ginoza Informational [Page 5]
RFC 3599 Summary of 3500-3599 December 20033583 Chaskar, Ed. Sep 2003 Requirements of a Quality of Service (QoS) Solution for Mobile IPMobile IP ensures correct routing of packets to a mobile node as themobile node changes its point of attachment to the Internet. However,it is also required to provide proper Quality of Service (QoS)forwarding treatment to the mobile node's packet stream at theintermediate nodes in the network, so that QoS-sensitive IP services canbe supported over Mobile IP. This document describes requirements foran IP QoS mechanism for its satisfactory operation with Mobile IP. Thismemo provides information for the Internet community.3582 Abley Aug 2003 Goals for IPv6 Site-Multihoming ArchitecturesThis document outlines a set of goals for proposed new IPv6 site-multihoming architectures. It is recognised that this set of goals isambitious and that some goals may conflict with others. The solution orsolutions adopted may only be able to satisfy some of the goalspresented here. This memo provides information for the Internetcommunity.3581 Rosenberg Aug 2003 An Extension to the Session Initiation Protocol (SIP) for Symmetric Response RoutingThe Session Initiation Protocol (SIP) operates over UDP and TCP, amongothers. When used with UDP, responses to requests are returned to thesource address the request came from, and to the port written into thetopmost Via header field value of the request. This behavior is notdesirable in many cases, most notably, when the client is behind aNetwork Address Translator (NAT). This extension defines a newparameter for the Via header field, called "rport", that allows a clientto request that the server send the response back to the source IPaddress and port from which the request originated. [STANDARDS TRACK]Ginoza Informational [Page 6]
RFC 3599 Summary of 3500-3599 December 20033580 Congdon Sep 2003 IEEE 802.1X Remote Authentication Dial In User Service (RADIUS) Usage GuidelinesThis document provides suggestions on Remote Authentication Dial In UserService (RADIUS) usage by IEEE 802.1X Authenticators. The material inthis document is also included within a non-normative Appendix withinthe IEEE 802.1X specification, and is being presented as an IETF RFC forinformational purposes. This memo provides information for the Internetcommunity.3579 Aboba Sep 2003 RADIUS (Remote Authentication Dial In User Service) Support For Extensible Authentication Protocol (EAP)This document defines Remote Authentication Dial In User Service(RADIUS) support for the Extensible Authentication Protocol (EAP), anauthentication framework which supports multiple authenticationmechanisms. In the proposed scheme, the Network Access Server (NAS)forwards EAP packets to and from the RADIUS server, encapsulated withinEAP-Message attributes. This has the advantage of allowing the NAS tosupport any EAP authentication method, without the need for method-specific code, which resides on the RADIUS server. While EAP wasoriginally developed for use with PPP, it is now also in use with IEEE802. This memo provides information for the Internet community.3578 Camarillo Aug 2003 Mapping of Integrated Services Digital Network (ISDN) User Part (ISUP) Overlap Signalling to the Session Initiation Protocol (SIP)This document describes a way to map Integrated Services Digital NetworkUser Part (ISUP) overlap signalling to Session Initiation Protocol(SIP). This mechanism might be implemented when using SIP in anenvironment where part of the call involves interworking with the PublicSwitched Telephone Network (PSTN). [STANDARDS TRACK]Ginoza Informational [Page 7]
RFC 3599 Summary of 3500-3599 December 20033577 Waldbusser Aug 2003 Introduction to the Remote Monitoring (RMON) Family of MIB ModulesThe Remote Monitoring (RMON) Framework consists of a number ofinterrelated documents. This memo describes these documents and howthey relate to one another. This memo provides information for theInternet community.3576 Chiba Jul 2003 Dynamic Authorization Extensions to Remote Authentication Dial In User Service (RADIUS)This document describes a currently deployed extension to the RemoteAuthentication Dial In User Service (RADIUS) protocol, allowing dynamicchanges to a user session, as implemented by network access serverproducts. This includes support for disconnecting users and changingauthorizations applicable to a user session. This memo providesinformation for the Internet community.3575 Aboba Jul 2003 IANA Considerations for RADIUS (Remote Authentication Dial In User Service)This document describes the IANA considerations for the RemoteAuthentication Dial In User Service (RADIUS). [STANDARDS TRACK]3574 Soininen, Ed. Aug 2003 Transition Scenarios for 3GPP NetworksThis document describes different scenarios in Third GenerationPartnership Project (3GPP) defined packet network, i.e., General PacketRadio Service (GPRS) that would need IP version 6 and IP version 4transition. The focus of this document is on the scenarios where theUser Equipment (UE) connects to nodes in other networks, e.g., in theInternet. GPRS network internal transition scenarios, i.e., betweendifferent GPRS elements in the network, are out of scope. The purposeof the document is to list the scenarios for further discussion andstudy. This memo provides information for the Internet community.Ginoza Informational [Page 8]
RFC 3599 Summary of 3500-3599 December 20033573 Goyret Jul 2003 Signaling of Modem-On-Hold status in Layer 2 Tunneling Protocol (L2TP)The Layer 2 Tunneling Protocol (L2TP) defines a mechanism for tunnelingPoint-to-Point Protocol (PPP) sessions. It is common for these PPPsessions to be established using modems connected over the publicswitched telephone network.One of the standards governing modem operation defines procedures thatenable a client modem to put the call on hold and later, re-establishthe modem link with minimal delay and without having to redial. Whilethe modem call is on hold, the client phone line can be used to place orreceive other calls.The L2TP base protocol does not provide any means to signal these eventsfrom the L2TP Access Controller (LAC), where the modem is physicallyconnected, to the L2TP Network Server (LNS), where the PPP session ishandled.This document describes a method to let the LNS know when a client modemconnected to a LAC has placed the call on hold. [STANDARDS TRACK]3572 Ogura Jul 2003 Internet Protocol Version 6 over MAPOS (Multiple Access Protocol Over SONET/SDH)Multiple Access Protocol over SONET/SDH (MAPOS) is a high-speed link-layer protocol that provides multiple access capability over aSynchronous Optical NETwork/Synchronous Digital Hierarchy (SONET/SDH).This document specifies the frame format for encapsulating an IPv6datagram in a MAPOS frame. It also specifies the method of forming IPv6interface identifiers, the method of detecting duplicate addresses, andthe format of the Source/Target Link-layer Addresses option field usedin IPv6 Neighbor Discovery messages. This memo provides information forthe Internet community.3571 Rawlins Aug 2003 Framework Policy Information Base for Usage FeedbackThis document describes a portion of the Policy Information Base (PIB)to control policy usage collection and reporting in a device.Ginoza Informational [Page 9]
RFC 3599 Summary of 3500-3599 December 2003The provisioning classes specified here allow a Policy Decision Point(PDP) to select which policy objects should collect usage information,what information should be collected and when it should be reported.This PIB requires the presence of other PIBs (defined elsewhere) thatprovide the policy objects from which usage information is collected.This memo provides information for the Internet community.3570 Rzewski Jul 2003 Content Internetworking (CDI) ScenariosIn describing content internetworking as a technology targeted for usein production networks, it is useful to provide examples of the sequenceof events that may occur when two content networks decide tointerconnect. The scenarios presented here seek to provide someconcrete examples of what content internetworking is, and also toprovide a basis for evaluating content internetworking proposals. Thismemo provides information for the Internet community.3569 Bhattacharyya Jul 2003 An Overview of Source-Specific Multicast (SSM)The purpose of this document is to provide an overview ofSource-Specific Multicast (SSM) and issues related to its deployment.It discusses how the SSM service model addresses the challenges faced ininter-domain multicast deployment, changes needed to routing protocolsand applications to deploy SSM and interoperability issues with currentmulticast service models. This memo provides information for theInternet community.3568 Barbir Jul 2003 Known Content Network (CN) Request-Routing MechanismsThis document presents a summary of Request-Routing techniques that areused to direct client requests to surrogates based on various policiesand a possible set of metrics. The document covers techniques that werecommonly used in the industry on or before December 2000. In this memo,the term Request-Routing represents techniques that is commonly calledcontent routing or content redirection. In principle, Request-Routingtechniques can be classified under: DNS Request-Routing, Transport-layerRequest-Routing, and Application-layer Request-Routing. This memoprovides information for the Internet community.Ginoza Informational [Page 10]
RFC 3599 Summary of 3500-3599 December 20033567 Li Jul 2003 Intermediate System to Intermediate System (IS-IS) Cryptographic AuthenticationThis document describes the authentication of Intermediate System toIntermediate System (IS-IS) Protocol Data Units (PDUs) using the HashedMessage Authentication Codes - Message Digest 5 (HMAC-MD5) algorithm asfound inRFC 2104. IS-IS is specified in International StandardsOrganization (ISO) 10589, with extensions to support Internet Protocolversion 4 (IPv4) described inRFC 1195. The base specification includesan authentication mechanism that allows for multiple authenticationalgorithms. The base specification only specifies the algorithm forcleartext passwords.This document proposes an extension to that specification that allowsthe use of the HMAC-MD5 authentication algorithm to be used inconjunction with the existing authentication mechanisms. This memoprovides information for the Internet community.3566 Frankel Sep 2003 The AES-XCBC-MAC-96 Algorithm and Its Use With IPsecA Message Authentication Code (MAC) is a key-dependent one way hashfunction. One popular way to construct a MAC algorithm is to use ablock cipher in conjunction with the Cipher-Block-Chaining (CBC) mode ofoperation. The classic CBC-MAC algorithm, while secure for messages ofa pre-selected fixed length, has been shown to be insecure acrossmessages of varying lengths such as the type found in typical IPdatagrams. This memo specifies the use of AES in CBC mode with a set ofextensions to overcome this limitation. This new algorithm is namedAES-XCBC-MAC-96. [STANDARDS TRACK]3565 Schaad Jul 2003 Use of the Advanced Encryption Standard (AES) Encryption Algorithm in Cryptographic Message Syntax (CMS)This document specifies the conventions for using the AdvancedEncryption Standard (AES) algorithm for encryption with theCryptographic Message Syntax (CMS). [STANDARDS TRACK]Ginoza Informational [Page 11]
RFC 3599 Summary of 3500-3599 December 20033564 Le Faucheur Jul 2003 Requirements for Support of Differentiated Services-aware MPLS Traffic EngineeringThis document presents Service Provider requirements for support ofDifferentiated Services (Diff-Serv)-aware MPLS Traffic Engineering (DS-TE).Its objective is to provide guidance for the definition, selection andspecification of a technical solution addressing these requirements.Specification for this solution itself is outside the scope of thisdocument.A problem statement is first provided. Then, the document describesexample applications scenarios identified by Service Providers whereexisting MPLS Traffic Engineering mechanisms fall short andDiff-Serv-aware Traffic Engineering can address the needs. The detailedrequirements that need to be addressed by the technical solution arealso reviewed. Finally, the document identifies the evaluation criteriathat should be considered for selection and definition of the technicalsolution. This memo provides information for the Internet community.3563 Zinin Jul 2003 Cooperative Agreement Between the ISOC/IETF and ISO/IEC Joint Technical Committee 1/Sub Committee 6 (JTC1/SC6) on IS-IS Routing Protocol DevelopmentThis document contains the text of the agreement signed betweenISOC/IETF and ISO/IEC JTC1/SC6 regarding cooperative development of theIS-IS routing protocol. The agreement includes definitions of therelated work scopes for the two organizations, request for creation andmaintenance of an IS-IS registry by IANA, as well as collaborationguidelines. This memo provides information for the Internet community.3562 Leech Jul 2003 Key Management Considerations for the TCP MD5 Signature OptionThe TCP MD5 Signature Option (RFC 2385), used predominantly by BGP, hasseen significant deployment in critical areas of Internetinfrastructure. The security of this option relies heavily on thequality of the keying material used to compute the MD5 signature. Thisdocument addresses the security requirements of that keying material.This memo provides information for the Internet community.Ginoza Informational [Page 12]
RFC 3599 Summary of 3500-3599 December 20033561 Perkins Jul 2003 Ad hoc On-Demand Distance Vector (AODV) RoutingThe Ad hoc On-Demand Distance Vector (AODV) routing protocol is intendedfor use by mobile nodes in an ad hoc network. It offers quickadaptation to dynamic link conditions, low processing and memoryoverhead, low network utilization, and determines unicast routes todestinations within the ad hoc network. It uses destination sequencenumbers to ensure loop freedom at all times (even in the face ofanomalous delivery of routing control messages), avoiding problems (suchas "counting to infinity") associated with classical distance vectorprotocols. This memo defines an Experimental Protocol for the Internetcommunity.3560 Housley Jul 2003 Use of the RSAES-OAEP Key Transport Algorithm in the Cryptographic Message Syntax (CMS)This document describes the conventions for using the RSAES-OAEP keytransport algorithm with the Cryptographic Message Syntax (CMS). TheCMS specifies the enveloped-data content type, which consists of anencrypted content and encrypted content-encryption keys for one or morerecipients. The RSAES-OAEP key transport algorithm can be used toencrypt content-encryption keys for intended recipients. [STANDARDSTRACK]3559 Thaler Jun 2003 Multicast Address Allocation MIBThis memo defines a portion of the Management Information Base (MIB) foruse with network management protocols in the Internet community. Inparticular, it describes managed objects used for managing multicastaddress allocation. [STANDARDS TRACK]Ginoza Informational [Page 13]
RFC 3599 Summary of 3500-3599 December 20033558 Li Jul 2003 RTP Payload Format for Enhanced Variable Rate Codecs (EVRC) and Selectable Mode Vocoders (SMV)This document describes the RTP payload format for Enhanced VariableRate Codec (EVRC) Speech and Selectable Mode Vocoder (SMV) Speech. Twosub-formats are specified for different application scenarios. Abundled/interleaved format is included to reduce the effect of packetloss on speech quality and amortize the overhead of the RTP header overmore than one speech frame. A non-bundled format is also supported forconversational applications. [STANDARDS TRACK]3557 Xie, Ed. Jul 2003 RTP Payload Format for European Telecommunications Standards Institute (ETSI) European Standard ES 201 108 Distributed Speech Recognition EncodingThis document specifies an RTP payload format for encapsulating EuropeanTelecommunications Standards Institute (ETSI) European Standard (ES) 201108 front-end signal processing feature streams for distributed speechrecognition (DSR) systems. [STANDARDS TRACK]3556 Casner Jul 2003 Session Description Protocol (SDP) Bandwidth Modifiers for RTP Control Protocol (RTCP) BandwidthThis document defines an extension to the Session Description Protocol(SDP) to specify two additional modifiers for the bandwidth attribute.These modifiers may be used to specify the bandwidth allowed for RTPControl Protocol (RTCP) packets in a Real-time Transport Protocol (RTP)session. [STANDARDS TRACK]Ginoza Informational [Page 14]
RFC 3599 Summary of 3500-3599 December 20033555 Casner Jul 2003 MIME Type Registration of RTP Payload FormatsThis document defines the procedure to register RTP Payload Formats asaudio, video or other MIME subtype names. This is useful in a text-based format or control protocol to identify the type of an RTPtransmission. This document also registers all the RTP payload formatsdefined in the RTP Profile for Audio and Video Conferences as MIMEsubtypes. Some of these may also be used for transfer modes other thanRTP. [STANDARDS TRACK]3554 Bellovin Jul 2003 On the Use of Stream Control Transmission Protocol (SCTP) with IPsecThis document describes functional requirements for IPsec (RFC 2401) andInternet Key Exchange (IKE) (RFC 2409) to facilitate their use insecuring SCTP (RFC 2960) traffic. [STANDARDS TRACK]3553 Mealling Jun 2003 An IETF URN Sub-namespace for Registered Protocol ParametersThis document describes a new sub-delegation for the 'ietf' URNnamespace for registered protocol items. The 'ietf' URN namespace isdefined inRFC 2648 as a root for persistent URIs that refer to IETF-defined resources. This document specifies an Internet Best CurrentPractices for the Internet Community, and requests discussion andsuggestions for improvements.3552 Rescorla Jul 2003 Guidelines for Writing RFC Text on Security ConsiderationsAll RFCs are required to have a Security Considerations section.Historically, such sections have been relatively weak. This documentprovides guidelines to RFC authors on how to write a good SecurityConsiderations section. This document specifies an Internet BestCurrent Practices for the Internet Community, and requests discussionand suggestions for improvements.Ginoza Informational [Page 15]
RFC 3599 Summary of 3500-3599 December 20033551 Schulzrinne Jul 2003 RTP Profile for Audio and Video Conferences with Minimal ControlThis document describes a profile called "RTP/AVP" for the use of thereal-time transport protocol (RTP), version 2, and the associatedcontrol protocol, RTCP, within audio and video multiparticipantconferences with minimal control. It provides interpretations ofgeneric fields within the RTP specification suitable for audio and videoconferences. In particular, this document defines a set of defaultmappings from payload type numbers to encodings.This document also describes how audio and video data may be carriedwithin RTP. It defines a set of standard encodings and their names whenused within RTP. The descriptions provide pointers to referenceimplementations and the detailed standards. This document is meant asan aid for implementors of audio, video and other real-time multimediaapplications.This memorandum obsoletesRFC 1890. It is mostly backwards-compatibleexcept for functions removed because two interoperable implementationswere not found. The additions toRFC 1890 codify existing practice inthe use of payload formats under this profile and include new payloadformats defined sinceRFC 1890 was published. [STANDARDS TRACK]3550 Schulzrinne Jul 2003 RTP: A Transport Protocol for Real-Time ApplicationsThis memorandum describes RTP, the real-time transport protocol. RTPprovides end-to-end network transport functions suitable forapplications transmitting real-time data, such as audio, video orsimulation data, over multicast or unicast network services. RTP doesnot address resource reservation and does not guarantee quality-of-service for real-time services. The data transport is augmented by acontrol protocol (RTCP) to allow monitoring of the data delivery in amanner scalable to large multicast networks, and to provide minimalcontrol and identification functionality. RTP and RTCP are designed tobe independent of the underlying transport and network layers. Theprotocol supports the use of RTP-level translators and mixers.Most of the text in this memorandum is identical toRFC 1889 which itobsoletes. There are no changes in the packet formats on the wire, onlychanges to the rules and algorithms governing how the protocol is used.The biggest change is an enhancement to the scalable timer algorithm forcalculating when to send RTCP packets in order to minimize transmissionin excess of the intended rate when many participants join a sessionsimultaneously. [STANDARDS TRACK]Ginoza Informational [Page 16]
RFC 3599 Summary of 3500-3599 December 20033549 Salim Jul 2003 Linux Netlink as an IP Services ProtocolThis document describes Linux Netlink, which is used in Linux both as anintra-kernel messaging system as well as between kernel and user space.The focus of this document is to describe Netlink's functionality as aprotocol between a Forwarding Engine Component (FEC) and a Control PlaneComponent (CPC), the two components that define an IP service. As aresult of this focus, this document ignores other uses of Netlink,including its use as a intra-kernel messaging system, as an inter-process communication scheme (IPC), or as a configuration tool for othernon-networking or non-IP network services (such as decnet, etc.).This document is intended as informational in the context of prior artfor the ForCES IETF working group. This memo provides information forthe Internet community.3548 Josefsson Jul 2003 The Base16, Base32, and Base64 Data EncodingsThis document describes the commonly used base 64, base 32, and base 16encoding schemes. It also discusses the use of line-feeds in encodeddata, use of padding in encoded data, use of non-alphabet characters inencoded data, and use of different encoding alphabets. This memoprovides information for the Internet community.3547 Baugher Jul 2003 The Group Domain of InterpretationThis document presents an ISAMKP Domain of Interpretation (DOI) forgroup key management to support secure group communications. The GDOImanages group security associations, which are used by IPSEC andpotentially other data security protocols running at the IP orapplication layers. These security associations protect one or morekey-encrypting keys, traffic-encrypting keys, or data shared by groupmembers. [STANDARDS TRACK]Ginoza Informational [Page 17]
RFC 3599 Summary of 3500-3599 December 20033546 Blake-Wilson Jun 2003 Transport Layer Security (TLS) ExtensionsThis document describes extensions that may be used to add functionalityto Transport Layer Security (TLS). It provides both generic extensionmechanisms for the TLS handshake client and server hellos, and specificextensions using these generic mechanisms.The extensions may be used by TLS clients and servers. The extensionsare backwards compatible - communication is possible between TLS 1.0clients that support the extensions and TLS 1.0 servers that do notsupport the extensions, and vice versa. [STANDARDS TRACK]3545 Koren Jul 2003 Enhanced Compressed RTP (CRTP) for Links with High Delay, Packet Loss and ReorderingThis document describes a header compression scheme for point to pointlinks with packet loss and long delays. It is based on CompressedReal-time Transport Protocol (CRTP), the IP/UDP/RTP header compressiondescribed inRFC 2508. CRTP does not perform well on such links: packetloss results in context corruption and due to the long delay, many morepackets are discarded before the context is repaired. To correct thebehavior of CRTP over such links, a few extensions to the protocol arespecified here. The extensions aim to reduce context corruption bychanging the way the compressor updates the context at the decompressor:updates are repeated and include updates to full and differentialcontext parameters. With these extensions, CRTP performs well overlinks with packet loss, packet reordering and long delays. [STANDARDSTRACK]3544 Koren Jul 2003 IP Header Compression over PPPThis document describes an option for negotiating the use of headercompression on IP datagrams transmitted over the Point-to-Point Protocol(RFC 1661). It defines extensions to the PPP Control Protocols for IPv4and IPv6 (RFC 1332,RFC 2472). Header compression may be applied toIPv4 and IPv6 datagrams in combination with TCP, UDP and RTP transportprotocols as specified inRFC 2507,RFC 2508 andRFC 3545. [STANDARDSTRACK]Ginoza Informational [Page 18]
RFC 3599 Summary of 3500-3599 December 20033543 Glass Aug 2003 Registration Revocation in Mobile IPv4This document defines a Mobile IPv4 Registration Revocation mechanismwhereby a mobility agent involved in providing Mobile IP services to amobile node can notify the other mobility agent providing Mobile IPservices to the same mobile node of the termination of thisregistration. The mechanism is also usable by a home agent to notify aco-located mobile node of the termination of its binding as well.Moreover, the mechanism provides for this notification to beacknowledged. A signaling mechanism already defined by the Mobile IPv4protocol is leveraged as a way to inform a mobile node of the revocationof its binding. [STANDARDS TRACK]3542 Stevens May 2003 Advanced Sockets Application Program Interface (API) for IPv6This document provides sockets Application Program Interface (API) tosupport "advanced" IPv6 applications, as a supplement to a separatespecification,RFC 3493. The expected applications include Ping,Traceroute, routing daemons and the like, which typically use rawsockets to access IPv6 or ICMPv6 header fields. This document proposessome portable interfaces for applications that use raw sockets underIPv6. There are other features of IPv6 that some applications will needto access: interface identification (specifying the outgoing interfaceand determining the incoming interface), IPv6 extension headers, andpath Maximum Transmission Unit (MTU) information. This documentprovides API access to these features too. Additionally, some extendedinterfaces to libraries for the "r" commands are defined. The extensionwill provide better backward compatibility to existing implementationsthat are not IPv6-capable. This memo provides information for theInternet community.3541 Walsh May 2003 A Uniform Resource Name (URN) Namespace for the Web3D Consortium (Web3D)This document describes a Uniform Resource Name (URN) namespace for theWeb3D Consortium (Web3D) for naming persistent resources such astechnical documents and specifications, Virtual Reality ModelingLanguage (VRML) and Extensible 3D (X3D) files and resources, ExtensibleMarkup Language (XML) Document Type Definitions (DTDs), XML Schemas,namespaces, style sheets, media assets, and other resources produced ormanaged by Web3D. This memo provides information for the Internetcommunity.Ginoza Informational [Page 19]
RFC 3599 Summary of 3500-3599 December 20033540 Spring Jun 2003 Robust Explicit Congestion Notification (ECN) Signaling with NoncesThis note describes the Explicit Congestion Notification (ECN)-nonce, anoptional addition to ECN that protects against accidental or maliciousconcealment of marked packets from the TCP sender. It improves therobustness of congestion control by preventing receivers from exploitingECN to gain an unfair share of network bandwidth. The ECN-nonce usesthe two ECN-Capable Transport (ECT)codepoints in the ECN field of the IPheader, and requires a flag in the TCP header. It is computationallyefficient for both routers and hosts. This memo defines an ExperimentalProtocol for the Internet community.3539 Aboba Jun 2003 Authentication, Authorization and Accounting (AAA) Transport ProfileThis document discusses transport issues that arise within protocols forAuthentication, Authorization and Accounting (AAA). It also providesrecommendations on the use of transport by AAA protocols. This includesusage of standards-track RFCs as well as experimental proposals.[STANDARDS TRACK]3538 Kawatsura Jun 2003 Secure Electronic Transaction (SET) Supplement for the v1.0 Internet Open Trading Protocol (IOTP)This document describes detailed Input/Output parameters for theInternet Open Trading Protocol (IOTP) Payment Application ProgrammingInterface (API). It also describes procedures in the Payment Bridge forthe use of SET (SET Secure Electronic Transaction) as the paymentprotocol within Version 1.0 of the IOTP. This memo provides informationfor the Internet community.Ginoza Informational [Page 20]
RFC 3599 Summary of 3500-3599 December 20033537 Schaad May 2003 Wrapping a Hashed Message Authentication Code (HMAC) key with a Triple-Data Encryption Standard (DES) Key or an Advanced Encryption Standard (AES) KeyThis document defines two methods for wrapping an HMAC (Hashed MessageAuthentication Code) key. The first method defined uses a Triple DES(Data Encryption Standard) key to encrypt the HMAC key. The secondmethod defined uses an AES (Advanced Encryption Standard) key to encryptthe HMAC key. One place that such an algorithm is used is for theAuthenticated Data type in CMS (Cryptographic Message Syntax).[PROPOSED STANDARD]3536 Hoffman May 2003 Terminology Used in Internationalization in the IETFThis document provides a glossary of terms used in the IETF whendiscussing internationalization. The purpose is to help framediscussions of internationalization in the various areas of the IETF andto help introduce the main concepts to IETF participants. This memoprovides information for the Internet community.3535 Schoenwaelder May 2003 Overview of the 2002 IAB Network Management WorkshopThis document provides an overview of a workshop held by the InternetArchitecture Board (IAB) on Network Management. The workshop was hostedby CNRI in Reston, VA, USA on June 4 thru June 6, 2002. The goal of theworkshop was to continue the important dialog started between networkoperators and protocol developers, and to guide the IETFs focus onfuture work regarding network management. This report summarizes thediscussions and lists the conclusions and recommendations to theInternet Engineering Task Force (IETF) community. This memo providesinformation for the Internet community.Ginoza Informational [Page 21]
RFC 3599 Summary of 3500-3599 December 20033534 Walleij May 2003 The application/ogg Media TypeThe Ogg Bitstream Format aims at becoming a general, freely-availablestandard for transporting multimedia content across computing platformsand networks. The intention of this document is to define the MIMEmedia type application/ogg to refer to this kind of content whentransported across the Internet. It is the intention of the OggBitstream Format developers that it be usable without intellectualproperty concerns. [STANDARDS TRACK]3533 Pfeiffer May 2003 The Ogg Encapsulation Format Version 0This document describes the Ogg bitstream format version 0, which is ageneral, freely-available encapsulation format for media streams. It isable to encapsulate any kind and number of video and audio encodingformats as well as other data streams in a single bitstream. This memoprovides information for the Internet community. This memo providesinformation for the Internet community.3532 Anderson May 2003 Requirements for the Dynamic Partitioning of Switching ElementsThis document identifies a set of requirements for the mechanisms usedto dynamically reallocate the resources of a switching element (e.g., anATM switch) to its partitions. These requirements are particularlycritical in the case of an operator creating a switch partition and thenleasing control of that partition to a third party. This memo providesinformation for the Internet community.Ginoza Informational [Page 22]
RFC 3599 Summary of 3500-3599 December 20033531 Blanchet Apr 2003 A Flexible Method for Managing the Assignment of Bits of an IPv6 Address BlockThis document proposes a method to manage the assignment of bits of anIPv6 address block or range. When an organisation needs to make anaddress plan for its subnets or when an ISP needs to make an addressplan for its customers, this method enables the organisation to postponethe final decision on the number of bits to partition in the addressspace they have. It does it by keeping the bits around the borders ofthe partition to be free as long as possible. This scheme is applicableto any bits addressing scheme using bits with partitions in the space,but its first intended use is for IPv6. It is a generalization of RFC1219 and can be used for IPv6 assignments.This memo providesinformation for the Internet community.3530 Shepler Apr 2003 Network File System (NFS) version 4 ProtocolThe Network File System (NFS) version 4 is a distributed filesystemprotocol which owes heritage to NFS protocol version 2,RFC 1094, andversion 3,RFC 1813. Unlike earlier versions, the NFS version 4protocol supports traditional file access while integrating support forfile locking and the mount protocol. In addition, support for strongsecurity (and its negotiation), compound operations, client caching, andinternationalization have been added. Of course, attention has beenapplied to making NFS version 4 operate well in an Internet environment.This document replacesRFC 3010 as the definition of the NFS version 4protocol. [STANDARDS TRACK]3529 Harold Apr 2003 XML-RPC is an ExtensibleMarkup Language-Remote Procedure Calling protocol that works over theInternet. It defines an XML format for messages that are transferedbetween clients and servers using HTTP. An XML-RPC message encodeseither a procedure to be invoked by the server, along with theparameters to use in the invocation, or the result of an invocation.Procedure parameters and results can be scalars, numbers, strings,dates, etc.; they can also be complex record and list structures.This document specifies a how to use the Blocks Extensible ExchangeProtocol (BEEP) to transfer messages encoded in the XML-RPC formatbetween clients and servers. This memo defines an Experimental Protocolfor the Internet community.Ginoza Informational [Page 23]
RFC 3599 Summary of 3500-3599 December 20033528 Zhao Apr 2003 Mesh-enhanced Service Location Protocol (mSLP)This document describes the Mesh-enhanced Service Location Protocol(mSLP). mSLP enhances the Service Location Protocol (SLP) with ascope-based fully-meshed peering Directory Agent (DA) architecture.Peer DAs exchange new service registrations in shared scopes via anti-entropy and direct forwarding. mSLP improves the reliability andconsistency of SLP DA services, and simplifies Service Agent (SA)registrations in systems with multiple DAs. mSLP is backward compatiblewith SLPv2 and can be deployed incrementally. This memo defines anExperimental Protocol for the Internet community.3527 Kinnear Apr 2003 Link Selection sub-option for the Relay Agent Information Option for DHCPv4This document describes the link selection sub-option of the relay-agent-information option for the Dynamic Host Configuration Protocol(DHCPv4). The giaddr specifies an IP address which determines both asubnet, and thereby a link on which a Dynamic Host ConfigurationProtocol (DHCP) client resides as well as an IP address that can be usedto communicate with the relay agent. The subnet-selection option allowsthe functions of the giaddr to be split so that when one entity isperforming as a DHCP proxy, it can specify the subnet/link from which toallocate an IP address, which is different from the IP address withwhich it desires to communicate with the DHCP server. Analogoussituations exist where the relay agent needs to specify the subnet/linkon which a DHCP client resides, which is different from an IP addressthat can be used to communicate with the relay agent. [STANDARDS TRACK]3526 Kivinen May 2003 More Modular Exponential (MODP) Diffie-Hellman groups for Internet Key Exchange (IKE)This document defines new Modular Exponential (MODP) Groups for theInternet Key Exchange (IKE) protocol. It documents the well known andused 1536 bit group 5, and also defines new 2048, 3072, 4096, 6144, and8192 bit Diffie-Hellman groups numbered starting at 14.The selectionof the primes for theses groups follows the criteria established byRichard Schroeppel. [STANDARDS TRACK]Ginoza Informational [Page 24]
RFC 3599 Summary of 3500-3599 December 20033525 Groves Jun 2003 Gateway Control Protocol Version 1This document defines the protocol used between elements of a physicallydecomposed multimedia gateway, i.e., a Media Gateway and a Media GatewayController. The protocol presented in this document meets therequirements for a media gateway control protocol as presented in RFC2805.This document replacesRFC 3015. It is the result of continuedcooperation between the IETF Megaco Working Group and ITU-T Study Group16. It incorporates the original text ofRFC 3015, modified bycorrections and clarifications discussed on the MegacoE-mail list and incorporated into the Study Group 16 Implementor's Guidefor Recommendation H.248. The present version of this documentunderwent ITU-T Last Call as Recommendation H.248 Amendment 1. Becauseof ITU-T renumbering, it was published by the ITU-T as RecommendationH.248.1 (03/2002), Gateway Control Protocol Version 1.Users of this specification are advised to consult the H.248 Sub-seriesImplementors' Guide athttp://www.itu.int/itudoc/itu-t/com16/implgd foradditional corrections and clarifications. [STANDARDS TRACK]3524 Camarillo Apr 2003 Mapping of Media Streams to Resource Reservation FlowsThis document defines an extension to the Session Description Protocol(SDP) grouping framework. It allows requesting a group of media streamsto be mapped into a single resource reservation flow. The SDP syntaxneeded is defined, as well as a new "semantics" attribute called SingleReservation Flow (SRF). [STANDARDS TRACK]3523 Polk Apr 2003 Internet Emergency Preparedness (IEPREP) Telephony Topology TerminologyThis document defines the topology naming conventions that are to beused in reference to Internet Emergency Preparedness (IEPREP) phonecalls. These naming conventions should be used to focus the IEPREPWorking Group during discussions and when writing requirements, gapanalysis and other solutions documents. This memo provides informationfor the Internet community.Ginoza Informational [Page 25]
RFC 3599 Summary of 3500-3599 December 20033522 Ludwig Apr 2003 The Eifel Detection Algorithm for TCPThe Eifel detection algorithm allows a TCP sender to detect a posterioriwhether it has entered loss recovery unnecessarily. It requires thatthe TCP Timestamps option defined inRFC 1323 be enabled for aconnection. The Eifel detection algorithm makes use of the fact thatthe TCP Timestamps option eliminates the retransmission ambiguity inTCP. Based on the timestamp of the first acceptable ACK that arrivesduring loss recovery, it decides whether loss recovery was enteredunnecessarily. The Eifel detection algorithm provides a basis forfuture TCP enhancements. This includes response algorithms to back outof loss recovery by restoring a TCP sender's congestion control state.This memo defines an Experimental Protocol for the Internet community.3521 Hamer Apr 2003 Framework for Session Set-up with Media AuthorizationEstablishing multimedia streams must take into account requirements forend-to-end QoS, authorization of network resource usage and accurateaccounting for resources used. During session set up, policies may beenforced to ensure that the media streams being requested lie within thebounds of the service profile established for the requesting host.Similarly, when a host requests resources to provide a certain QoS for apacket flow, policies may be enforced to ensure that the requiredresources lie within the bounds of the resource profile established forthe requesting host.To prevent fraud and to ensure accurate billing, this document describesvarious scenarios and mechanisms that provide the linkage required toverify that the resources being used to provide a requested QoS are in-line with the media streams requested (and authorized) for the session.This memo provides information for the Internet community.Ginoza Informational [Page 26]
RFC 3599 Summary of 3500-3599 December 20033520 Hamer Apr 2003 Session Authorization Policy ElementThis document describes the representation of a session authorizationpolicy element for supporting policy-based per-session authorization andadmission control. The goal of session authorization is to allow theexchange of information between network elements in order to authorizethe use of resources for a service and to co-ordinate actions betweenthe signaling and transport planes. This document describes how aprocess on a system authorizes the reservation of resources by a hostand then provides that host with a session authorization policy elementwhich can be inserted into a resource reservation protocol (e.g., theResource ReSerVation Protocol (RSVP) PATH message) to facilitate properand secure reservation of those resources within the network. Wedescribe the encoding of session authorization information as a policyelement conforming to the format of a Policy Data object (RFC 2750) andprovide details relating to operations, processing rules and errorscenarios. [STANDARDS TRACK]3519 Levkowetz May 2003 Mobile IP Traversal of Network Address Translation (NAT) DevicesMobile IP's datagram tunnelling is incompatible with Network AddressTranslation (NAT). This document presents extensions to the Mobile IPprotocol and a tunnelling method which permits mobile nodes using MobileIP to operate in private address networks which are separated from thepublic internet by NAT devices. The NAT traversal is based on using theMobile IP Home Agent UDP port for encapsulated data traffic. [STANDARDSTRACK]3518 Higashiyama Apr 2003 Point-to-Point Protocol (PPP) Bridging Control Protocol (BCP)The Point-to-Point Protocol (PPP) provides a standard method fortransporting multi-protocol datagrams over point-to-point links. PPPdefines an extensible Link Control Protocol (LCP) and proposes a familyof Network Control Protocols (NCP) for establishing and configuringdifferent network-layer protocols.This document defines the NCP for establishing and configuring RemoteBridging for PPP links.Ginoza Informational [Page 27]
RFC 3599 Summary of 3500-3599 December 2003This document obsoletesRFC 2878, which was based on the IEEE 802.1D-1993 MAC Bridge.This document extends that specification by improvingsupport for bridge control packets. [STANDARDS TRACK]3517 Blanton Apr 2003 A Conservative Selective Acknowledgment (SACK)-based Loss Recovery Algorithm for TCPThis document presents a conservative loss recovery algorithm for TCPthat is based on the use of the selective acknowledgment (SACK) TCPoption. The algorithm presented in this document conforms to the spiritof the current congestion control specification (RFC 2581), but allowsTCP senders to recover more effectively when multiple segments are lostfrom a single flight of data. [STANDARDS TRACK]3516 Nerenberg Apr 2003 IMAP4 Binary Content ExtensionThis memo defines the Binary extension to the Internet Message AccessProtocol (IMAP4). It provides a mechanism for IMAP4 clients and serversto exchange message body data without using a MIME content-transfer-encoding. [STANDARDS TRACK]3515 Sparks Apr 2003 The Session Initiation Protocol (SIP) Refer MethodThis document defines the REFER method. This Session InitiationProtocol (SIP) extension requests that the recipient REFER to a resourceprovided in the request. It provides a mechanism allowing the partysending the REFER to be notified of the outcome of the referencedrequest. This can be used to enable many applications, including calltransfer.In addition to the REFER method, this document defines the refer eventpackage and the Refer-To request header. [STANDARDS TRACK]3514 Bellovin 1 Apr 2003 The Security Flag in the IPv4 HeaderFirewalls, packet filters, intrusion detection systems, and the likeoften have difficulty distinguishing between packets that have maliciousintent and those that are merely unusual. We define a security flag inthe IPv4 header as a means of distinguishing the two cases. This memoprovides information for the Internet community.Ginoza Informational [Page 28]
RFC 3599 Summary of 3500-3599 December 20033513 Hinden Apr 2003 Internet Protocol Version 6 (IPv6) Addressing ArchitectureThis specification defines the addressing architecture of the IP Version6 (IPv6) protocol.The document includes the IPv6 addressing model,text representations of IPv6 addresses, definition of IPv6 unicastaddresses, anycast addresses, and multicast addresses, and an IPv6node's required addresses. [STANDARDS TRACK]3512 MacFaden Apr 2003 Configuring Networks and Devices with Simple Network Management Protocol (SNMP)This document is written for readers interested in the Internet StandardManagement Framework and its protocol, the Simple Network ManagementProtocol (SNMP). In particular, it offers guidance in the effective useof SNMP for configuration management. This information is relevant tovendors that build network elements, management application developers,and those that acquire and deploy this technology in their networks.This memo provides information for the Internet community.3511 Hickman Apr 2003 Benchmarking Methodology for Firewall PerformanceThis document discusses and defines a number of tests that may be usedto describe the performance characteristics of firewalls. In additionto defining the tests, this document also describes specific formats forreporting the results of the tests.This document is a product of the Benchmarking Methodology Working Group(BMWG) of the Internet Engineering Task Force (IETF). This memoprovides information for the Internet community.3510 Herriot Apr 2003 Internet Printing Protocol/1.1: IPP URL SchemeThis memo defines the "ipp" URL (Uniform Resource Locator) scheme. Thismemo updates IPP/1.1: Encoding and Transport (RFC 2910), by expandingand clarifyingSection 5, "IPP URL Scheme", ofRFC 2910. An "ipp" URLis used to specify the network location of a print service that supportsthe IPP Protocol (RFC 2910), or of a network resource (for example, aprint job) managed by such a print service. [STANDARDS TRACK]Ginoza Informational [Page 29]
RFC 3599 Summary of 3500-3599 December 20033509 Zinin Apr 2003 Alternative Implementations of OSPF Area Border RoutersOpen Shortest Path First (OSPF) is a link-state intra-domain routingprotocol used for routing in IP networks. Though the definition of theArea Border Router (ABR) in the OSPF specification does not require arouter with multiple attached areas to have a backbone connection, it isactually necessary to provide successful routing to the inter-area andexternal destinations. If this requirement is not met, all trafficdestined for the areas not connected to such an ABR or out of the OSPFdomain, is dropped. This document describes alternative ABR behaviorsimplemented in Cisco and IBM routers. This memo provides informationfor the Internet community.3508 Levin Apr 2003 H.323 Uniform Resource Locator (URL) Scheme RegistrationITU-T Recommendation H.323 version 4 introduced an H.323-specificUniform Resource Locator (URL). This document reproduces the H323-URLdefinition found in H.323, and is published as an RFC for ease of accessand registration with the Internet Assigned Numbers Authority (IANA).This memo provides information for the Internet community.3507 Elson Apr 2003 Internet Content Adaptation Protocol (ICAP)ICAP, the Internet Content Adaption Protocol, is a protocol aimed atproviding simple object-based content vectoring for HTTP services. ICAPis, in essence, a lightweight protocol for executing a "remote procedurecall" on HTTP messages. It allows ICAP clients to pass HTTP messages toICAP servers for some sort of transformation or other processing("adaptation"). The server executes its transformation service onmessages and sends back responses to the client, usually with modifiedmessages. Typically, the adapted messages are either HTTP requests orHTTP responses. This memo provides information for the Internetcommunity.Ginoza Informational [Page 30]
RFC 3599 Summary of 3500-3599 December 20033506 Fujimura Mar 2003 Requirements and Design for Voucher Trading System (VTS)Crediting loyalty points and collecting digital coupons or giftcertificates are common functions in purchasing and tradingtransactions. These activities can be generalized using the concept ofa "voucher", which is a digital representation of the right to claimgoods or services. This document presents a Voucher Trading System(VTS) that circulates vouchers securely and its terminology; it listsdesign principles and requirements for VTS and the Generic VoucherLanguage (GVL), with which diverse types of vouchers can be described.This memo provides information for the Internet community.3505 Eastlake Mar 2003 Electronic Commerce Modeling Language (ECML): Version 2 RequirementsThis document lists the design principles, scope, and requirements forthe Electronic Commerce Modeling Language (ECML) version 2specification. It includes requirements as they relate to ExtensibleMarkup Language (XML) syntax, data model, format, and paymentprocessing. This memo provides information for the Internet community.3504 Eastlake Mar 2003 Internet Open Trading Protocol (IOTP) Version 1, ErrataSince the publication of the RFCs specifying Version 1.0 of the InternetOpen Trading Protocol (IOTP), some errors have been noted. Thisinformational document lists these errors and provides corrections forthem. This memo provides information for the Internet community.3503 Melnikov Mar 2003 Message Disposition Notification (MDN) profile for Internet Message Access Protocol (IMAP)The Message Disposition Notification (MDN) facility defined inRFC 2298provides a means by which a message can request that message processingby the recipient be acknowledged as well as a format to be used for suchacknowledgements. However, it doesn't describe how multiple Mail UserAgents (MUAs) should handle the generation of MDNs in an InternetMessage Access Protocol (IMAP4) environment.Ginoza Informational [Page 31]
RFC 3599 Summary of 3500-3599 December 2003This document describes how to handle MDNs in such an environment andprovides guidelines for implementers of IMAP4 that want to add MDNsupport to their products. [STANDARDS TRACK]3502 Crispin Mar 2003 Internet Message Access Protocol (IMAP) - MULTIAPPEND ExtensionThis document describes the multiappending extension to the InternetMessage Access Protocol (IMAP) (RFC 3501). This extension providessubstantial performance improvements for IMAP clients which uploadmultiple messages at a time to a mailbox on the server.A server which supports this extension indicates this with a capabilityname of "MULTIAPPEND". [STANDARDS TRACK]3501 Crispin Mar 2003 INTERNET MESSAGE ACCESS PROTOCOL - VERSION 4rev1The Internet Message Access Protocol, Version 4rev1 (IMAP4rev1) allows aclient to access and manipulate electronic mail messages on a server.IMAP4rev1 permits manipulation of mailboxes (remote message folders) ina way that is functionally equivalent to local folders. IMAP4rev1 alsoprovides the capability for an offline client to resynchronize with theserver.IMAP4rev1 includes operations for creating, deleting, and renamingmailboxes, checking for new messages, permanently removing messages,setting and clearing flags,RFC 2822 andRFC 2045 parsing, searching,and selective fetching of message attributes, texts, and portionsthereof. Messages in IMAP4rev1 are accessed by the use of numbers.These numbers are either message sequence numbers or unique identifiers.IMAP4rev1 supports a single server. A mechanism for accessingconfiguration information to support multiple IMAP4rev1 servers isdiscussed inRFC 2244.IMAP4rev1 does not specify a means of posting mail; this function ishandled by a mail transfer protocol such asRFC 2821. [STANDARDS TRACK]Ginoza Informational [Page 32]
RFC 3599 Summary of 3500-3599 December 20033500 Never IssuedRFC 3500 was never issued.Security Considerations Security issues are not discussed in this memo.Author's Address Sandy Ginoza University of Southern California Information Sciences Institute 4676 Admiralty Way Marina del Rey, CA 90292 Phone: (310) 822-1511 EMail: ginoza@isi.eduGinoza Informational [Page 33]
RFC 3599 Summary of 3500-3599 December 2003Full Copyright Statement Copyright (C) The Internet Society (2003). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.Acknowledgement Funding for the RFC Editor function is currently provided by the Internet Society.Ginoza Informational [Page 34]
[8]ページ先頭