Request for Comments Summary RFC Numbers 3500-3599
RFC 3599
|
| Document |
Type |
|
RFC - Informational
(December 2003; No errata)
|
|
Author |
|
Sandy Ginoza
|
|
Last updated |
|
2013-03-02
|
|
Stream |
|
Legacy stream
|
|
Formats |
|
plain text
html
pdf
htmlized
bibtex
|
| Stream |
Legacy state
|
|
(None)
|
|
Consensus Boilerplate |
|
Unknown
|
|
RFC Editor Note |
|
(None)
|
| IESG |
IESG state |
|
RFC 3599 (Informational)
|
|
Telechat date |
|
|
|
Responsible AD |
|
(None)
|
|
Send notices to |
|
(None)
|
Network Working Group S. Ginoza
Request for Comments: 3599 ISI
Category: Informational December 2003
Request for Comments Summary
RFC Numbers 3500-3599
Status of This Memo
This RFC is a slightly annotated list of the 100 RFCs from RFC 3500
through RFC 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 Summary
This memo.
3598 Murchison Sep 2003 Sieve Email Filtering --
Subaddress Extension
On email systems that allow for "subaddressing" or "detailed addressing"
(e.g., "ken+sieve@example.org"), it is sometimes desirable to make
comparisons against these sub-parts of addresses. This document defines
an extension to the Sieve mail filtering language that allows users to
compare against the user and detail parts of an address. [STANDARDS
TRACK]
Ginoza Informational [Page 1]
RFC 3599 Summary of 3500-3599 December 2003
3597 Gustafsson Sep 2003 Handling of Unknown DNS
Resource Record (RR) Types
Extending the Domain Name System (DNS) with new Resource Record (RR)
types currently requires changes to name server software. This document
specifies the changes necessary to allow future DNS implementations to
handle new RR types transparently. [STANDARDS TRACK]
3596 Thomson Oct 2003 DNS Extensions to Support IP
Version 6
This document defines the changes that need to be made to the Domain
Name System (DNS) to support hosts running IP version 6 (IPv6). The
changes include a resource record type to store an IPv6 address, a
domain to support lookups based on an IPv6 address, and updated
definitions of existing query types that return Internet addresses as
part of additional section processing. The extensions are designed to
be compatible with existing applications and, in particular, DNS
implementations themselves. [STANDARDS TRACK]
3595 Wijnen Sep 2003 Textual Conventions for IPv6
Flow Label
This MIB module defines textual conventions to represent the commonly
used IPv6 Flow Label. The intent is that these textual conventions
(TCs) will be imported and used in MIB modules that would otherwise
define their own representations. [STANDARDS TRACK]
3594 Duffy Sep 2003 PacketCable Security Ticket
Control Sub-Option for the
DHCP CableLabs Client
Configuration (CCC) Option
This document defines a new sub-option for the DHCP CableLabs Client
Configuration (CCC) Option. This new sub-option will be used to direct
CableLabs Client Devices (CCDs) to invalidate security tickets stored in
CCD non volatile memory (i.e., locally persisted security tickets).
[STANDARDS TRACK]
Ginoza Informational [Page 2]
RFC 3599 Summary of 3500-3599 December 2003
3593 Tesink, Ed. Sep 2003 Textual Conventions for MIB
Modules Using Performance
History Based on 15 Minute
Intervals
This document defines a set of Textual Conventions for MIB modules that
make use of performance history data based on 15 minute intervals.
This memo replaces RFC 2493. Changes relative to RFC 2493 are
summarized 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 Type
This memo defines a portion of the Management Information Base (MIB) for
use with network management protocols in TCP/IP-based internets. In
particular, it defines objects for managing Synchronous Optical
Network/Synchronous Digital Hierarchy (SONET/SDH) interfaces. This
document is a companion to the documents that define Managed Objects for
the DS1/E1/DS2/E2 and DS3/E3 Interface Types.
This memo replaces RFC 2558. Changes relative to RFC 2558 are
summarized in the MIB module's REVISION clause. [STANDARDS TRACK]
3591 Lam Sep 2003 Definitions of Managed Objects
for the Optical Interface Type
This memo defines a portion of the Management Information Base (MIB) for
use with Simple Network Management Protocol (SNMP) in TCP/IP-based
internets. In particular, it defines objects for managing Optical
Interfaces associated with WavelengthDivision Multiplexing systems or
characterized by the Optical Transport Network (OTN) in accordance with
the OTN architecture defined in ITU-T Recommendation G.872.
The MIB module defined in this memo can be used for performance
monitoring and/or configuration of such optical interface. [STANDARDS
TRACK]
Ginoza Informational [Page 3]
RFC 3599 Summary of 3500-3599 December 2003
3590 Haberman Sep 2003 Source Address Selection for
the Multicast Listener
Discovery (MLD) Protocol
It has come to light that there is an issue with the selection of a
suitable 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 IPv6
address to use for MLD messages. [STANDARDS TRACK]
3589 Loughney Sep 2003 Diameter Command Codes for
Third Generation Partnership
Project (3GPP) Release 5
This document describes the IANA's allocation of a block of Diameter
Command Codes for the Third Generation Partnership Project (3GPP)
Release 5. This document does not pass judgment on the usage of these
command codes. Further more, these command codes are for use for
Release 5. For future releases, these codes cannot be reused, but must
be allocated according to the Diameter Base specification. This memo
provides information for the Internet community.
3588 Calhoun Sep 2003 Diameter Base Protocol
The Diameter base protocol is intended to provide an Authentication,
Authorization and Accounting (AAA) framework for applications such as
network access or IP mobility. Diameter is also intended to work in
both local Authentication, Authorization & Accounting and roaming
situations. This document specifies the message format, transport,
error reporting, accounting and security services to be used by all
Diameter applications. The Diameter base application needs to be
supported by all Diameter implementations. [STANDARDS TRACK]
3587 Hinden Aug 2003 IPv6 Global Unicast Address
Format
This document obsoletes RFC 2374, "An IPv6 Aggregatable Global Unicast
Address Format". It defined an IPv6 address allocation structure that
includes Top Level Aggregator (TLA) and Next Level Aggregator (NLA).
This document makes RFC 2374 and the TLA/NLA structure historic. This
memo provides information for the Internet community.
Ginoza Informational [Page 4]
RFC 3599 Summary of 3500-3599 December 2003
3586 Blaze Aug 2003 IP Security Policy (IPSP)
Requirements
This document describes the problem space and solution requirements for
developing an IP Security Policy (IPSP) configuration and management
framework. The IPSP architecture provides a scalable, decentralized
framework for managing, discovering and negotiating the host and network
security policies that govern access, authorization, authentication,
confidentiality, data integrity, and other IP Security properties. This
document highlights such architectural components and presents their
functional requirements. [STANDARDS TRACK]
3585 Jason Aug 2003 IPsec Configuration Policy
Information Model
This document presents an object-oriented information model of IP
Security (IPsec) policy designed to facilitate agreement about the
content 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 to
configure IPsec-enabled endpoints. The information model described in
this document models the configuration parameters defined by IPSec. The
information model also covers the parameters found by the Internet Key
Exchange protocol (IKE). Other key exchange protocols could easily be
added to the information model by a simple extension. Further
extensions can further be added easily due to the object-oriented nature
of the model.
This information model is based upon the core policy classes as defined
in the Policy Core Information Model (PCIM) and in the Policy Core
Information Model Extensions (PCIMe). [STANDARDS TRACK]
3584 Frye Aug 2003 Coexistence between Version 1,
Version 2, and Version 3 of
the Internet-standard Network
Management Framework
The purpose of this document is to describe coexistence between version
3 of the Internet-standard Network Management Framework, (SNMPv3),
version 2 of the Internet-standard Network Management Framework
(SNMPv2), and the original Internet-standard Network Management
Framework (SNMPv1). This document also describes how to convert MIB
modules from SMIv1 format to SMIv2 format. This document obsoletes RFC
2576. This document specifies an Internet Best Current Practices for
the Internet Community, and requests discussion and suggestions for
improvements.
Ginoza Informational [Page 5]
RFC 3599 Summary of 3500-3599 December 2003
3583 Chaskar, Ed. Sep 2003 Requirements of a Quality of
Service (QoS) Solution for
Mobile IP
Mobile IP ensures correct routing of packets to a mobile node as the
mobile 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 the
intermediate nodes in the network, so that QoS-sensitive IP services can
be supported over Mobile IP. This document describes requirements for
an IP QoS mechanism for its satisfactory operation with Mobile IP. This
memo provides information for the Internet community.
3582 Abley Aug 2003 Goals for IPv6
Site-Multihoming Architectures
This document outlines a set of goals for proposed new IPv6 site-
multihoming architectures. It is recognised that this set of goals is
ambitious and that some goals may conflict with others. The solution or
solutions adopted may only be able to satisfy some of the goals
presented here. This memo provides information for the Internet
community.
3581 Rosenberg Aug 2003 An Extension to the Session
Initiation Protocol (SIP) for
Symmetric Response Routing
The Session Initiation Protocol (SIP) operates over UDP and TCP, among
others. When used with UDP, responses to requests are returned to the
source address the request came from, and to the port written into the
topmost Via header field value of the request. This behavior is not
desirable in many cases, most notably, when the client is behind a
Network Address Translator (NAT). This extension defines a new
parameter for the Via header field, called "rport", that allows a client
to request that the server send the response back to the source IP
address and port from which the request originated. [STANDARDS TRACK]
Ginoza Informational [Page 6]
RFC 3599 Summary of 3500-3599 December 2003
3580 Congdon Sep 2003 IEEE 802.1X Remote
Authentication Dial In User
Service (RADIUS) Usage
Guidelines
This document provides suggestions on Remote Authentication Dial In User
Service (RADIUS) usage by IEEE 802.1X Authenticators. The material in
this document is also included within a non-normative Appendix within
the IEEE 802.1X specification, and is being presented as an IETF RFC for
informational purposes. This memo provides information for the Internet
community.
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), an
authentication framework which supports multiple authentication
mechanisms. In the proposed scheme, the Network Access Server (NAS)
forwards EAP packets to and from the RADIUS server, encapsulated within
EAP-Message attributes. This has the advantage of allowing the NAS to
support any EAP authentication method, without the need for method-
specific code, which resides on the RADIUS server. While EAP was
originally developed for use with PPP, it is now also in use with IEEE
802. 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 Network
User Part (ISUP) overlap signalling to Session Initiation Protocol
(SIP). This mechanism might be implemented when using SIP in an
environment where part of the call involves interworking with the Public
Switched Telephone Network (PSTN). [STANDARDS TRACK]
Ginoza Informational [Page 7]
RFC 3599 Summary of 3500-3599 December 2003
3577 Waldbusser Aug 2003 Introduction to the Remote
Monitoring (RMON) Family of
MIB Modules
The Remote Monitoring (RMON) Framework consists of a number of
interrelated documents. This memo describes these documents and how
they relate to one another. This memo provides information for the
Internet 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 Remote
Authentication Dial In User Service (RADIUS) protocol, allowing dynamic
changes to a user session, as implemented by network access server
products. This includes support for disconnecting users and changing
authorizations applicable to a user session. This memo provides
information 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 Remote
Authentication Dial In User Service (RADIUS). [STANDARDS TRACK]
3574 Soininen, Ed. Aug 2003 Transition Scenarios for 3GPP
Networks
This document describes different scenarios in Third Generation
Partnership Project (3GPP) defined packet network, i.e., General Packet
Radio Service (GPRS) that would need IP version 6 and IP version 4
transition. The focus of this document is on the scenarios where the
User Equipment (UE) connects to nodes in other networks, e.g., in the
Internet. GPRS network internal transition scenarios, i.e., between
different GPRS elements in the network, are out of scope. The purpose
of the document is to list the scenarios for further discussion and
study. This memo provides information for the Internet community.
Ginoza Informational [Page 8]
RFC 3599 Summary of 3500-3599 December 2003
3573 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 tunneling
Point-to-Point Protocol (PPP) sessions. It is common for these PPP
sessions to be established using modems connected over the public
switched telephone network.
One of the standards governing modem operation defines procedures that
enable a client modem to put the call on hold and later, re-establish
the modem link with minimal delay and without having to redial. While
the modem call is on hold, the client phone line can be used to place or
receive other calls.
The L2TP base protocol does not provide any means to signal these events
from the L2TP Access Controller (LAC), where the modem is physically
connected, to the L2TP Network Server (LNS), where the PPP session is
handled.
This document describes a method to let the LNS know when a client modem
connected 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 a
Synchronous Optical NETwork/Synchronous Digital Hierarchy (SONET/SDH).
This document specifies the frame format for encapsulating an IPv6
datagram in a MAPOS frame. It also specifies the method of forming IPv6
interface identifiers, the method of detecting duplicate addresses, and
the format of the Source/Target Link-layer Addresses option field used
in IPv6 Neighbor Discovery messages. This memo provides information for
the Internet community.
3571 Rawlins Aug 2003 Framework Policy Information
Base for Usage Feedback
This 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 2003
The 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) that
provide the policy objects from which usage information is collected.
This memo provides information for the Internet community.
3570 Rzewski Jul 2003 Content Internetworking (CDI)
Scenarios
In describing content internetworking as a technology targeted for use
in production networks, it is useful to provide examples of the sequence
of events that may occur when two content networks decide to
interconnect. The scenarios presented here seek to provide some
concrete examples of what content internetworking is, and also to
provide a basis for evaluating content internetworking proposals. This
memo 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 of
Source-Specific Multicast (SSM) and issues related to its deployment.
It discusses how the SSM service model addresses the challenges faced in
inter-domain multicast deployment, changes needed to routing protocols
and applications to deploy SSM and interoperability issues with current
multicast service models. This memo provides information for the
Internet community.
3568 Barbir Jul 2003 Known Content Network (CN)
Request-Routing Mechanisms
This document presents a summary of Request-Routing techniques that are
used to direct client requests to surrogates based on various policies
and a possible set of metrics. The document covers techniques that were
commonly used in the industry on or before December 2000. In this memo,
the term Request-Routing represents techniques that is commonly called
content routing or content redirection. In principle, Request-Routing
techniques can be classified under: DNS Request-Routing, Transport-layer
Request-Routing, and Application-layer Request-Routing. This memo
provides information for the Internet community.
Ginoza Informational [Page 10]
RFC 3599 Summary of 3500-3599 December 2003
3567 Li Jul 2003 Intermediate System to
Intermediate System (IS-IS)
Cryptographic Authentication
This document describes the authentication of Intermediate System to
Intermediate System (IS-IS) Protocol Data Units (PDUs) using the Hashed
Message Authentication Codes - Message Digest 5 (HMAC-MD5) algorithm as
found in RFC 2104. IS-IS is specified in International Standards
Organization (ISO) 10589, with extensions to support Internet Protocol
version 4 (IPv4) described in RFC 1195. The base specification includes
an authentication mechanism that allows for multiple authentication
algorithms. The base specification only specifies the algorithm for
cleartext passwords.
This document proposes an extension to that specification that allows
the use of the HMAC-MD5 authentication algorithm to be used in
conjunction with the existing authentication mechanisms. This memo
provides information for the Internet community.
3566 Frankel Sep 2003 The AES-XCBC-MAC-96 Algorithm
and Its Use With IPsec
A Message Authentication Code (MAC) is a key-dependent one way hash
function. One popular way to construct a MAC algorithm is to use a
block cipher in conjunction with the Cipher-Block-Chaining (CBC) mode of
operation. The classic CBC-MAC algorithm, while secure for messages of
a pre-selected fixed length, has been shown to be insecure across
messages of varying lengths such as the type found in typical IP
datagrams. This memo specifies the use of AES in CBC mode with a set of
extensions to overcome this limitation. This new algorithm is named
AES-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 Advanced
Encryption Standard (AES) algorithm for encryption with the
Cryptographic Message Syntax (CMS). [STANDARDS TRACK]
Ginoza Informational [Page 11]
RFC 3599 Summary of 3500-3599 December 2003
3564 Le Faucheur Jul 2003 Requirements for Support of
Differentiated Services-aware
MPLS Traffic Engineering
This document presents Service Provider requirements for support of
Differentiated Services (Diff-Serv)-aware MPLS Traffic Engineering (DS-
TE).
Its objective is to provide guidance for the definition, selection and
specification of a technical solution addressing these requirements.
Specification for this solution itself is outside the scope of this
document.
A problem statement is first provided. Then, the document describes
example applications scenarios identified by Service Providers where
existing MPLS Traffic Engineering mechanisms fall short and
Diff-Serv-aware Traffic Engineering can address the needs. The detailed
requirements that need to be addressed by the technical solution are
also reviewed. Finally, the document identifies the evaluation criteria
that should be considered for selection and definition of the technical
solution. 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
Development
This document contains the text of the agreement signed between
ISOC/IETF and ISO/IEC JTC1/SC6 regarding cooperative development of the
IS-IS routing protocol. The agreement includes definitions of the
related work scopes for the two organizations, request for creation and
maintenance of an IS-IS registry by IANA, as well as collaboration
guidelines. This memo provides information for the Internet community.
3562 Leech Jul 2003 Key Management Considerations
for the TCP MD5 Signature
Option
The TCP MD5 Signature Option (RFC 2385), used predominantly by BGP, has
seen significant deployment in critical areas of Internet
infrastructure. The security of this option relies heavily on the
quality of the keying material used to compute the MD5 signature. This
document 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 2003
3561 Perkins Jul 2003 Ad hoc On-Demand Distance
Vector (AODV) Routing
The Ad hoc On-Demand Distance Vector (AODV) routing protocol is intended
for use by mobile nodes in an ad hoc network. It offers quick
adaptation to dynamic link conditions, low processing and memory
overhead, low network utilization, and determines unicast routes to
destinations within the ad hoc network. It uses destination sequence
numbers to ensure loop freedom at all times (even in the face of
anomalous delivery of routing control messages), avoiding problems (such
as "counting to infinity") associated with classical distance vector
protocols. This memo defines an Experimental Protocol for the Internet
community.
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 key
transport algorithm with the Cryptographic Message Syntax (CMS). The
CMS specifies the enveloped-data content type, which consists of an
encrypted content and encrypted content-encryption keys for one or more
recipients. The RSAES-OAEP key transport algorithm can be used to
encrypt content-encryption keys for intended recipients. [STANDARDS
TRACK]
3559 Thaler Jun 2003 Multicast Address Allocation
MIB
This memo defines a portion of the Management Information Base (MIB) for
use with network management protocols in the Internet community. In
particular, it describes managed objects used for managing multicast
address allocation. [STANDARDS TRACK]
Ginoza Informational [Page 13]
RFC 3599 Summary of 3500-3599 December 2003
3558 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 Variable
Rate Codec (EVRC) Speech and Selectable Mode Vocoder (SMV) Speech. Two
sub-formats are specified for different application scenarios. A
bundled/interleaved format is included to reduce the effect of packet
loss on speech quality and amortize the overhead of the RTP header over
more than one speech frame. A non-bundled format is also supported for
conversational 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
Encoding
This document specifies an RTP payload format for encapsulating European
Telecommunications Standards Institute (ETSI) European Standard (ES) 201
108 front-end signal processing feature streams for distributed speech
recognition (DSR) systems. [STANDARDS TRACK]
3556 Casner Jul 2003 Session Description Protocol
(SDP) Bandwidth Modifiers
for RTP Control Protocol
(RTCP) Bandwidth
This 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 RTP
Control Protocol (RTCP) packets in a Real-time Transport Protocol (RTP)
session. [STANDARDS TRACK]
Ginoza Informational [Page 14]
RFC 3599 Summary of 3500-3599 December 2003
3555 Casner Jul 2003 MIME Type Registration of RTP
Payload Formats
This document defines the procedure to register RTP Payload Formats as
audio, video or other MIME subtype names. This is useful in a text-
based format or control protocol to identify the type of an RTP
transmission. This document also registers all the RTP payload formats
defined in the RTP Profile for Audio and Video Conferences as MIME
subtypes. Some of these may also be used for transfer modes other than
RTP. [STANDARDS TRACK]
3554 Bellovin Jul 2003 On the Use of Stream Control
Transmission Protocol (SCTP)
with IPsec
This document describes functional requirements for IPsec (RFC 2401) and
Internet Key Exchange (IKE) (RFC 2409) to facilitate their use in
securing SCTP (RFC 2960) traffic. [STANDARDS TRACK]
3553 Mealling Jun 2003 An IETF URN Sub-namespace for
Registered Protocol Parameters
This document describes a new sub-delegation for the 'ietf' URN
namespace for registered protocol items. The 'ietf' URN namespace is
defined in RFC 2648 as a root for persistent URIs that refer to IETF-
defined resources. This document specifies an Internet Best Current
Practices for the Internet Community, and requests discussion and
suggestions for improvements.
3552 Rescorla Jul 2003 Guidelines for Writing RFC
Text on Security
Considerations
All RFCs are required to have a Security Considerations section.
Historically, such sections have been relatively weak. This document
provides guidelines to RFC authors on how to write a good Security
Considerations section. This document specifies an Internet Best
Current Practices for the Internet Community, and requests discussion
and suggestions for improvements.
Ginoza Informational [Page 15]
RFC 3599 Summary of 3500-3599 December 2003
3551 Schulzrinne Jul 2003 RTP Profile for Audio and
Video Conferences with Minimal
Control
This document describes a profile called "RTP/AVP" for the use of the
real-time transport protocol (RTP), version 2, and the associated
control protocol, RTCP, within audio and video multiparticipant
conferences with minimal control. It provides interpretations of
generic fields within the RTP specification suitable for audio and video
conferences. In particular, this document defines a set of default
mappings from payload type numbers to encodings.
This document also describes how audio and video data may be carried
within RTP. It defines a set of standard encodings and their names when
used within RTP. The descriptions provide pointers to reference
implementations and the detailed standards. This document is meant as
an aid for implementors of audio, video and other real-time multimedia
applications.
This memorandum obsoletes RFC 1890. It is mostly backwards-compatible
except for functions removed because two interoperable implementations
were not found. The additions to RFC 1890 codify existing practice in
the use of payload formats under this profile and include new payload
formats defined since RFC 1890 was published. [STANDARDS TRACK]
3550 Schulzrinne Jul 2003 RTP: A Transport Protocol for
Real-Time Applications
This memorandum describes RTP, the real-time transport protocol. RTP
provides end-to-end network transport functions suitable for
applications transmitting real-time data, such as audio, video or
simulation data, over multicast or unicast network services. RTP does
not address resource reservation and does not guarantee quality-of-
service for real-time services. The data transport is augmented by a
control protocol (RTCP) to allow monitoring of the data delivery in a
manner scalable to large multicast networks, and to provide minimal
control and identification functionality. RTP and RTCP are designed to
be independent of the underlying transport and network layers. The
protocol supports the use of RTP-level translators and mixers.
Most of the text in this memorandum is identical to RFC 1889 which it
obsoletes. There are no changes in the packet formats on the wire, only
changes to the rules and algorithms governing how the protocol is used.
The biggest change is an enhancement to the scalable timer algorithm for
calculating when to send RTCP packets in order to minimize transmission
in excess of the intended rate when many participants join a session
simultaneously. [STANDARDS TRACK]
Ginoza Informational [Page 16]
RFC 3599 Summary of 3500-3599 December 2003
3549 Salim Jul 2003 Linux Netlink as an IP
Services Protocol
This document describes Linux Netlink, which is used in Linux both as an
intra-kernel messaging system as well as between kernel and user space.
The focus of this document is to describe Netlink's functionality as a
protocol between a Forwarding Engine Component (FEC) and a Control Plane
Component (CPC), the two components that define an IP service. As a
result 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 other
non-networking or non-IP network services (such as decnet, etc.).
This document is intended as informational in the context of prior art
for the ForCES IETF working group. This memo provides information for
the Internet community.
3548 Josefsson Jul 2003 The Base16, Base32, and Base64
Data Encodings
This document describes the commonly used base 64, base 32, and base 16
encoding schemes. It also discusses the use of line-feeds in encoded
data, use of padding in encoded data, use of non-alphabet characters in
encoded data, and use of different encoding alphabets. This memo
provides information for the Internet community.
3547 Baugher Jul 2003 The Group Domain of
Interpretation
This document presents an ISAMKP Domain of Interpretation (DOI) for
group key management to support secure group communications. The GDOI
manages group security associations, which are used by IPSEC and
potentially other data security protocols running at the IP or
application layers. These security associations protect one or more
key-encrypting keys, traffic-encrypting keys, or data shared by group
members. [STANDARDS TRACK]
Ginoza Informational [Page 17]
RFC 3599 Summary of 3500-3599 December 2003
3546 Blake-Wilson Jun 2003 Transport Layer Security (TLS)
Extensions
This document describes extensions that may be used to add functionality
to Transport Layer Security (TLS). It provides both generic extension
mechanisms for the TLS handshake client and server hellos, and specific
extensions using these generic mechanisms.
The extensions may be used by TLS clients and servers. The extensions
are backwards compatible - communication is possible between TLS 1.0
clients that support the extensions and TLS 1.0 servers that do not
support the extensions, and vice versa. [STANDARDS TRACK]
3545 Koren Jul 2003 Enhanced Compressed RTP (CRTP)
for Links with High Delay,
Packet Loss and Reordering
This document describes a header compression scheme for point to point
links with packet loss and long delays. It is based on Compressed
Real-time Transport Protocol (CRTP), the IP/UDP/RTP header compression
described in RFC 2508. CRTP does not perform well on such links: packet
loss results in context corruption and due to the long delay, many more
packets are discarded before the context is repaired. To correct the
behavior of CRTP over such links, a few extensions to the protocol are
specified here. The extensions aim to reduce context corruption by
changing the way the compressor updates the context at the decompressor:
updates are repeated and include updates to full and differential
context parameters. With these extensions, CRTP performs well over
links with packet loss, packet reordering and long delays. [STANDARDS
TRACK]
3544 Koren Jul 2003 IP Header Compression over PPP
This document describes an option for negotiating the use of header
compression on IP datagrams transmitted over the Point-to-Point Protocol
(RFC 1661). It defines extensions to the PPP Control Protocols for IPv4
and IPv6 (RFC 1332, RFC 2472). Header compression may be applied to
IPv4 and IPv6 datagrams in combination with TCP, UDP and RTP transport
protocols as specified in RFC 2507, RFC 2508 and RFC 3545. [STANDARDS
TRACK]
Ginoza Informational [Page 18]
RFC 3599 Summary of 3500-3599 December 2003
3543 Glass Aug 2003 Registration Revocation in
Mobile IPv4
This document defines a Mobile IPv4 Registration Revocation mechanism
whereby a mobility agent involved in providing Mobile IP services to a
mobile node can notify the other mobility agent providing Mobile IP
services to the same mobile node of the termination of this
registration. The mechanism is also usable by a home agent to notify a
co-located mobile node of the termination of its binding as well.
Moreover, the mechanism provides for this notification to be
acknowledged. A signaling mechanism already defined by the Mobile IPv4
protocol is leveraged as a way to inform a mobile node of the revocation
of its binding. [STANDARDS TRACK]
3542 Stevens May 2003 Advanced Sockets Application
Program Interface (API) for
IPv6
This document provides sockets Application Program Interface (API) to
support "advanced" IPv6 applications, as a supplement to a separate
specification, RFC 3493. The expected applications include Ping,
Traceroute, routing daemons and the like, which typically use raw
sockets to access IPv6 or ICMPv6 header fields. This document proposes
some portable interfaces for applications that use raw sockets under
IPv6. There are other features of IPv6 that some applications will need
to access: interface identification (specifying the outgoing interface
and determining the incoming interface), IPv6 extension headers, and
path Maximum Transmission Unit (MTU) information. This document
provides API access to these features too. Additionally, some extended
interfaces to libraries for the "r" commands are defined. The extension
will provide better backward compatibility to existing implementations
that are not IPv6-capable. This memo provides information for the
Internet 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 the
Web3D Consortium (Web3D) for naming persistent resources such as
technical documents and specifications, Virtual Reality Modeling
Language (VRML) and Extensible 3D (X3D) files and resources, Extensible
Markup Language (XML) Document Type Definitions (DTDs), XML Schemas,
namespaces, style sheets, media assets, and other resources produced or
managed by Web3D. This memo provides information for the Internet
community.
Ginoza Informational [Page 19]
RFC 3599 Summary of 3500-3599 December 2003
3540 Spring Jun 2003 Robust Explicit Congestion
Notification (ECN)
Signaling with Nonces
This note describes the Explicit Congestion Notification (ECN)-nonce, an
optional addition to ECN that protects against accidental or malicious
concealment of marked packets from the TCP sender. It improves the
robustness of congestion control by preventing receivers from exploiting
ECN to gain an unfair share of network bandwidth. The ECN-nonce uses
the two ECN-Capable Transport (ECT)codepoints in the ECN field of the IP
header, and requires a flag in the TCP header. It is computationally
efficient for both routers and hosts. This memo defines an Experimental
Protocol for the Internet community.
3539 Aboba Jun 2003 Authentication, Authorization
and Accounting (AAA) Transport
Profile
This document discusses transport issues that arise within protocols for
Authentication, Authorization and Accounting (AAA). It also provides
recommendations on the use of transport by AAA protocols. This includes
usage 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 the
Internet Open Trading Protocol (IOTP) Payment Application Programming
Interface (API). It also describes procedures in the Payment Bridge for
the use of SET (SET Secure Electronic Transaction) as the payment
protocol within Version 1.0 of the IOTP. This memo provides information
for the Internet community.
Ginoza Informational [Page 20]
RFC 3599 Summary of 3500-3599 December 2003
3537 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) Key
This document defines two methods for wrapping an HMAC (Hashed Message
Authentication Code) key. The first method defined uses a Triple DES
(Data Encryption Standard) key to encrypt the HMAC key. The second
method defined uses an AES (Advanced Encryption Standard) key to encrypt
the HMAC key. One place that such an algorithm is used is for the
Authenticated Data type in CMS (Cryptographic Message Syntax).
[PROPOSED STANDARD]
3536 Hoffman May 2003 Terminology Used in
Internationalization in the
IETF
This document provides a glossary of terms used in the IETF when
discussing internationalization. The purpose is to help frame
discussions of internationalization in the various areas of the IETF and
to help introduce the main concepts to IETF participants. This memo
provides information for the Internet community.
3535 Schoenwaelder May 2003 Overview of the 2002 IAB
Network Management
Workshop
This document provides an overview of a workshop held by the Internet
Architecture Board (IAB) on Network Management. The workshop was hosted
by CNRI in Reston, VA, USA on June 4 thru June 6, 2002. The goal of the
workshop was to continue the important dialog started between network
operators and protocol developers, and to guide the IETFs focus on
future work regarding network management. This report summarizes the
discussions and lists the conclusions and recommendations to the
Internet Engineering Task Force (IETF) community. This memo provides
information for the Internet community.
Ginoza Informational [Page 21]
RFC 3599 Summary of 3500-3599 December 2003
3534 Walleij May 2003 The application/ogg Media
Type
The Ogg Bitstream Format aims at becoming a general, freely-available
standard for transporting multimedia content across computing platforms
and networks. The intention of this document is to define the MIME
media type application/ogg to refer to this kind of content when
transported across the Internet. It is the intention of the Ogg
Bitstream Format developers that it be usable without intellectual
property concerns. [STANDARDS TRACK]
3533 Pfeiffer May 2003 The Ogg Encapsulation
Format Version 0
This document describes the Ogg bitstream format version 0, which is a
general, freely-available encapsulation format for media streams. It is
able to encapsulate any kind and number of video and audio encoding
formats as well as other data streams in a single bitstream. This memo
provides information for the Internet community. This memo provides
information for the Internet community.
3532 Anderson May 2003 Requirements for the Dynamic
Partitioning of Switching
Elements
This document identifies a set of requirements for the mechanisms used
to dynamically reallocate the resources of a switching element (e.g., an
ATM switch) to its partitions. These requirements are particularly
critical in the case of an operator creating a switch partition and then
leasing control of that partition to a third party. This memo provides
information for the Internet community.
Ginoza Informational [Page 22]
RFC 3599 Summary of 3500-3599 December 2003
3531 Blanchet Apr 2003 A Flexible Method for Managing
the Assignment of Bits of an
IPv6 Address Block
This document proposes a method to manage the assignment of bits of an
IPv6 address block or range. When an organisation needs to make an
address plan for its subnets or when an ISP needs to make an address
plan for its customers, this method enables the organisation to postpone
the final decision on the number of bits to partition in the address
space they have. It does it by keeping the bits around the borders of
the partition to be free as long as possible. This scheme is applicable
to any bits addressing scheme using bits with partitions in the space,
but its first intended use is for IPv6. It is a generalization of RFC
1219 and can be used for IPv6 assignments. This memo provides
information for the Internet community.
3530 Shepler Apr 2003 Network File System (NFS)
version 4 Protocol
The Network File System (NFS) version 4 is a distributed filesystem
protocol which owes heritage to NFS protocol version 2, RFC 1094, and
version 3, RFC 1813. Unlike earlier versions, the NFS version 4
protocol supports traditional file access while integrating support for
file locking and the mount protocol. In addition, support for strong
security (and its negotiation), compound operations, client caching, and
internationalization have been added. Of course, attention has been
applied to making NFS version 4 operate well in an Internet environment.
This document replaces RFC 3010 as the definition of the NFS version 4
protocol. [STANDARDS TRACK]
3529 Harold Apr 2003 XML-RPC is an Extensible
Markup Language-Remote Procedure Calling protocol that works over the
Internet. It defines an XML format for messages that are transfered
between clients and servers using HTTP. An XML-RPC message encodes
either a procedure to be invoked by the server, along with the
parameters 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 Exchange
Protocol (BEEP) to transfer messages encoded in the XML-RPC format
between clients and servers. This memo defines an Experimental Protocol
for the Internet community.
Ginoza Informational [Page 23]
RFC 3599 Summary of 3500-3599 December 2003
3528 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 a
scope-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 and
consistency of SLP DA services, and simplifies Service Agent (SA)
registrations in systems with multiple DAs. mSLP is backward compatible
with SLPv2 and can be deployed incrementally. This memo defines an
Experimental Protocol for the Internet community.
3527 Kinnear Apr 2003 Link Selection sub-option
for the Relay Agent
Information Option for DHCPv4
This 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 a
subnet, and thereby a link on which a Dynamic Host Configuration
Protocol (DHCP) client resides as well as an IP address that can be used
to communicate with the relay agent. The subnet-selection option allows
the functions of the giaddr to be split so that when one entity is
performing as a DHCP proxy, it can specify the subnet/link from which to
allocate an IP address, which is different from the IP address with
which it desires to communicate with the DHCP server. Analogous
situations exist where the relay agent needs to specify the subnet/link
on which a DHCP client resides, which is different from an IP address
that 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 the
Internet Key Exchange (IKE) protocol. It documents the well known and
used 1536 bit group 5, and also defines new 2048, 3072, 4096, 6144, and
8192 bit Diffie-Hellman groups numbered starting at 14. The selection
of the primes for theses groups follows the criteria established by
Richard Schroeppel. [STANDARDS TRACK]
Ginoza Informational [Page 24]
RFC 3599 Summary of 3500-3599 December 2003
3525 Groves Jun 2003 Gateway Control Protocol
Version 1
This document defines the protocol used between elements of a physically
decomposed multimedia gateway, i.e., a Media Gateway and a Media Gateway
Controller. The protocol presented in this document meets the
requirements for a media gateway control protocol as presented in RFC
2805.
This document replaces RFC 3015. It is the result of continued
cooperation between the IETF Megaco Working Group and ITU-T Study Group
16. It incorporates the original text of RFC 3015, modified by
corrections and clarifications discussed on the Megaco
E-mail list and incorporated into the Study Group 16 Implementor's Guide
for Recommendation H.248. The present version of this document
underwent ITU-T Last Call as Recommendation H.248 Amendment 1. Because
of ITU-T renumbering, it was published by the ITU-T as Recommendation
H.248.1 (03/2002), Gateway Control Protocol Version 1.
Users of this specification are advised to consult the H.248 Sub-series
Implementors' Guide at http://www.itu.int/itudoc/itu-t/com16/implgd for
additional corrections and clarifications. [STANDARDS TRACK]
3524 Camarillo Apr 2003 Mapping of Media Streams to
Resource Reservation Flows
This document defines an extension to the Session Description Protocol
(SDP) grouping framework. It allows requesting a group of media streams
to be mapped into a single resource reservation flow. The SDP syntax
needed is defined, as well as a new "semantics" attribute called Single
Reservation Flow (SRF). [STANDARDS TRACK]
3523 Polk Apr 2003 Internet Emergency
Preparedness (IEPREP)
Telephony Topology Terminology
This document defines the topology naming conventions that are to be
used in reference to Internet Emergency Preparedness (IEPREP) phone
calls. These naming conventions should be used to focus the IEPREP
Working Group during discussions and when writing requirements, gap
analysis and other solutions documents. This memo provides information
for the Internet community.
Ginoza Informational [Page 25]
RFC 3599 Summary of 3500-3599 December 2003
3522 Ludwig Apr 2003 The Eifel Detection Algorithm
for TCP
The Eifel detection algorithm allows a TCP sender to detect a posteriori
whether it has entered loss recovery unnecessarily. It requires that
the TCP Timestamps option defined in RFC 1323 be enabled for a
connection. The Eifel detection algorithm makes use of the fact that
the TCP Timestamps option eliminates the retransmission ambiguity in
TCP. Based on the timestamp of the first acceptable ACK that arrives
during loss recovery, it decides whether loss recovery was entered
unnecessarily. The Eifel detection algorithm provides a basis for
future TCP enhancements. This includes response algorithms to back out
of 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 Authorization
Establishing multimedia streams must take into account requirements for
end-to-end QoS, authorization of network resource usage and accurate
accounting for resources used. During session set up, policies may be
enforced to ensure that the media streams being requested lie within the
bounds of the service profile established for the requesting host.
Similarly, when a host requests resources to provide a certain QoS for a
packet flow, policies may be enforced to ensure that the required
resources lie within the bounds of the resource profile established for
the requesting host.
To prevent fraud and to ensure accurate billing, this document describes
various scenarios and mechanisms that provide the linkage required to
verify 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 2003
3520 Hamer Apr 2003 Session Authorization Policy
Element
This document describes the representation of a session authorization
policy element for supporting policy-based per-session authorization and
admission control. The goal of session authorization is to allow the
exchange of information between network elements in order to authorize
the use of resources for a service and to co-ordinate actions between
the signaling and transport planes. This document describes how a
process on a system authorizes the reservation of resources by a host
and then provides that host with a session authorization policy element
which can be inserted into a resource reservation protocol (e.g., the
Resource ReSerVation Protocol (RSVP) PATH message) to facilitate proper
and secure reservation of those resources within the network. We
describe the encoding of session authorization information as a policy
element conforming to the format of a Policy Data object (RFC 2750) and
provide details relating to operations, processing rules and error
scenarios. [STANDARDS TRACK]
3519 Levkowetz May 2003 Mobile IP Traversal of Network
Address Translation (NAT)
Devices
Mobile IP's datagram tunnelling is incompatible with Network Address
Translation (NAT). This document presents extensions to the Mobile IP
protocol and a tunnelling method which permits mobile nodes using Mobile
IP to operate in private address networks which are separated from the
public internet by NAT devices. The NAT traversal is based on using the
Mobile IP Home Agent UDP port for encapsulated data traffic. [STANDARDS
TRACK]
3518 Higashiyama Apr 2003 Point-to-Point Protocol (PPP)
Bridging Control Protocol
(BCP)
The Point-to-Point Protocol (PPP) provides a standard method for
transporting multi-protocol datagrams over point-to-point links. PPP
defines an extensible Link Control Protocol (LCP) and proposes a family
of Network Control Protocols (NCP) for establishing and configuring
different network-layer protocols.
This document defines the NCP for establishing and configuring Remote
Bridging for PPP links.
Ginoza Informational [Page 27]
RFC 3599 Summary of 3500-3599 December 2003
This document obsoletes RFC 2878, which was based on the IEEE 802.1D-
1993 MAC Bridge. This document extends that specification by improving
support for bridge control packets. [STANDARDS TRACK]
3517 Blanton Apr 2003 A Conservative Selective
Acknowledgment (SACK)-based
Loss Recovery Algorithm for
TCP
This document presents a conservative loss recovery algorithm for TCP
that is based on the use of the selective acknowledgment (SACK) TCP
option. The algorithm presented in this document conforms to the spirit
of the current congestion control specification (RFC 2581), but allows
TCP senders to recover more effectively when multiple segments are lost
from a single flight of data. [STANDARDS TRACK]
3516 Nerenberg Apr 2003 IMAP4 Binary Content Extension
This memo defines the Binary extension to the Internet Message Access
Protocol (IMAP4). It provides a mechanism for IMAP4 clients and servers
to exchange message body data without using a MIME content-transfer-
encoding. [STANDARDS TRACK]
3515 Sparks Apr 2003 The Session Initiation
Protocol (SIP) Refer Method
This document defines the REFER method. This Session Initiation
Protocol (SIP) extension requests that the recipient REFER to a resource
provided in the request. It provides a mechanism allowing the party
sending the REFER to be notified of the outcome of the referenced
request. This can be used to enable many applications, including call
transfer.
In addition to the REFER method, this document defines the refer event
package and the Refer-To request header. [STANDARDS TRACK]
3514 Bellovin 1 Apr 2003 The Security Flag in the IPv4
Header
Firewalls, packet filters, intrusion detection systems, and the like
often have difficulty distinguishing between packets that have malicious
intent and those that are merely unusual. We define a security flag in
the IPv4 header as a means of distinguishing the two cases. This memo
provides information for the Internet community.
Ginoza Informational [Page 28]
RFC 3599 Summary of 3500-3599 December 2003
3513 Hinden Apr 2003 Internet Protocol Version 6
(IPv6) Addressing Architecture
This specification defines the addressing architecture of the IP Version
6 (IPv6) protocol. The document includes the IPv6 addressing model,
text representations of IPv6 addresses, definition of IPv6 unicast
addresses, anycast addresses, and multicast addresses, and an IPv6
node'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 Standard
Management Framework and its protocol, the Simple Network Management
Protocol (SNMP). In particular, it offers guidance in the effective use
of SNMP for configuration management. This information is relevant to
vendors 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 Performance
This document discusses and defines a number of tests that may be used
to describe the performance characteristics of firewalls. In addition
to defining the tests, this document also describes specific formats for
reporting 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 memo
provides information for the Internet community.
3510 Herriot Apr 2003 Internet Printing
Protocol/1.1:
IPP URL Scheme
This memo defines the "ipp" URL (Uniform Resource Locator) scheme. This
memo updates IPP/1.1: Encoding and Transport (RFC 2910), by expanding
and clarifying Section 5, "IPP URL Scheme", of RFC 2910. An "ipp" URL
is used to specify the network location of a print service that supports
the IPP Protocol (RFC 2910), or of a network resource (for example, a
print job) managed by such a print service. [STANDARDS TRACK]
Ginoza Informational [Page 29]
RFC 3599 Summary of 3500-3599 December 2003
3509 Zinin Apr 2003 Alternative Implementations of
OSPF Area Border Routers
Open Shortest Path First (OSPF) is a link-state intra-domain routing
protocol used for routing in IP networks. Though the definition of the
Area Border Router (ABR) in the OSPF specification does not require a
router with multiple attached areas to have a backbone connection, it is
actually necessary to provide successful routing to the inter-area and
external destinations. If this requirement is not met, all traffic
destined for the areas not connected to such an ABR or out of the OSPF
domain, is dropped. This document describes alternative ABR behaviors
implemented in Cisco and IBM routers. This memo provides information
for the Internet community.
3508 Levin Apr 2003 H.323 Uniform Resource Locator
(URL) Scheme Registration
ITU-T Recommendation H.323 version 4 introduced an H.323-specific
Uniform Resource Locator (URL). This document reproduces the H323-URL
definition found in H.323, and is published as an RFC for ease of access
and 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 at
providing simple object-based content vectoring for HTTP services. ICAP
is, in essence, a lightweight protocol for executing a "remote procedure
call" on HTTP messages. It allows ICAP clients to pass HTTP messages to
ICAP servers for some sort of transformation or other processing
("adaptation"). The server executes its transformation service on
messages and sends back responses to the client, usually with modified
messages. Typically, the adapted messages are either HTTP requests or
HTTP responses. This memo provides information for the Internet
community.
Ginoza Informational [Page 30]
RFC 3599 Summary of 3500-3599 December 2003
3506 Fujimura Mar 2003 Requirements and Design for
Voucher Trading System (VTS)
Crediting loyalty points and collecting digital coupons or gift
certificates are common functions in purchasing and trading
transactions. These activities can be generalized using the concept of
a "voucher", which is a digital representation of the right to claim
goods or services. This document presents a Voucher Trading System
(VTS) that circulates vouchers securely and its terminology; it lists
design principles and requirements for VTS and the Generic Voucher
Language (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
Requirements
This document lists the design principles, scope, and requirements for
the Electronic Commerce Modeling Language (ECML) version 2
specification. It includes requirements as they relate to Extensible
Markup Language (XML) syntax, data model, format, and payment
processing. This memo provides information for the Internet community.
3504 Eastlake Mar 2003 Internet Open Trading Protocol
(IOTP) Version 1, Errata
Since the publication of the RFCs specifying Version 1.0 of the Internet
Open Trading Protocol (IOTP), some errors have been noted. This
informational document lists these errors and provides corrections for
them. 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 in RFC 2298
provides a means by which a message can request that message processing
by the recipient be acknowledged as well as a format to be used for such
acknowledgements. However, it doesn't describe how multiple Mail User
Agents (MUAs) should handle the generation of MDNs in an Internet
Message Access Protocol (IMAP4) environment.
Ginoza Informational [Page 31]
RFC 3599 Summary of 3500-3599 December 2003
This document describes how to handle MDNs in such an environment and
provides guidelines for implementers of IMAP4 that want to add MDN
support to their products. [STANDARDS TRACK]
3502 Crispin Mar 2003 Internet Message Access
Protocol (IMAP) - MULTIAPPEND
Extension
This document describes the multiappending extension to the Internet
Message Access Protocol (IMAP) (RFC 3501). This extension provides
substantial performance improvements for IMAP clients which upload
multiple messages at a time to a mailbox on the server.
A server which supports this extension indicates this with a capability
name of "MULTIAPPEND". [STANDARDS TRACK]
3501 Crispin Mar 2003 INTERNET MESSAGE ACCESS
PROTOCOL - VERSION 4rev1
The Internet Message Access Protocol, Version 4rev1 (IMAP4rev1) allows a
client to access and manipulate electronic mail messages on a server.
IMAP4rev1 permits manipulation of mailboxes (remote message folders) in
a way that is functionally equivalent to local folders. IMAP4rev1 also
provides the capability for an offline client to resynchronize with the
server.
IMAP4rev1 includes operations for creating, deleting, and renaming
mailboxes, checking for new messages, permanently removing messages,
setting and clearing flags, RFC 2822 and RFC 2045 parsing, searching,
and selective fetching of message attributes, texts, and portions
thereof. 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 accessing
configuration information to support multiple IMAP4rev1 servers is
discussed in RFC 2244.
IMAP4rev1 does not specify a means of posting mail; this function is
handled by a mail transfer protocol such as RFC 2821. [STANDARDS TRACK]
Ginoza Informational [Page 32]
RFC 3599 Summary of 3500-3599 December 2003
3500 Never Issued
RFC 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.edu
Ginoza Informational [Page 33]
RFC 3599 Summary of 3500-3599 December 2003
Full 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]