RFC3599 日本語訳
3599 Request for Comments Summary RFC Numbers 3500-3599. S. Ginoza. December 2003. (Format: TXT=76893 bytes) (Status: INFORMATIONAL)
プログラムでの自動翻訳です。
英語原文
Network Working Group S. Ginoza Request for Comments: 3599 ISI Category: Informational December 2003
Network Working Group S. Ginoza Request for Comments: 3599 ISI Category: Informational December 2003
Request for Comments Summary
Request for Comments Summary
RFC Numbers 3500-3599
RFC Numbers 3500-3599
Status of This Memo
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.
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 Notice
Copyright (C) The Internet Society (2003). All Rights Reserved.
Copyright (C) The Internet Society (2003). All Rights Reserved.
Note
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].
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 --- ------ ---- -----
RFC Author Date Title --- ------ ---- -----
3599 Ginoza Request for Comments Summary
3599 Ginoza Request for Comments Summary
This memo.
This memo.
3598 Murchison Sep 2003 Sieve Email Filtering --
Subaddress Extension
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]
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
Ginoza Informational [Page 1] RFC 3599 Summary of 3500-3599 December 2003
3597 Gustafsson Sep 2003 Handling of Unknown DNS
Resource Record (RR) Types
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]
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
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]
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
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]
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
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]
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
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
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 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]
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
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 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]
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
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.
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]
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
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
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]
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
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.
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
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]
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
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.
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
Ginoza Informational [Page 4] RFC 3599 Summary of 3500-3599 December 2003
3586 Blaze Aug 2003 IP Security Policy (IPSP)
Requirements
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]
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
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 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]
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
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.
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
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
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.
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
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.
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
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]
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
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
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.
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)
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.
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)
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]
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
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
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.
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)
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.
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)
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]
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
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.
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
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)
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.
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.
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.
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]
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)
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).
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.
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
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.
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
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.
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.
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
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.
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)
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.
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
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.
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
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
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 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.
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
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]
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)
3565 暗号のメッセージ構文におけるエー・イー・エス(AES)暗号化アルゴリズムのSchaad2003年7月の使用(cm)
This document specifies the conventions for using the Advanced Encryption Standard (AES) algorithm for encryption with the Cryptographic Message Syntax (CMS). [STANDARDS TRACK]
このドキュメントはCryptographic Message Syntax(CMS)との暗号化にエー・イー・エス(AES)アルゴリズムを使用するのにコンベンションを指定します。 [標準化過程]
Ginoza Informational [Page 11] RFC 3599 Summary of 3500-3599 December 2003
3500-3599 2003年12月の宜野座の情報[11ページ]のRFC3599概要
3564 Le Faucheur Jul 2003 Requirements for Support of
Differentiated Services-aware
MPLS Traffic Engineering
3564 差別化されたサービス意識しているMPLS交通工学のサポートのためのLe Faucheur2003年7月要件
This document presents Service Provider requirements for support of Differentiated Services (Diff-Serv)-aware MPLS Traffic Engineering (DS- TE).
このドキュメントはDifferentiated Services(デフ-Serv)の意識しているMPLS Traffic Engineering(DS- TE)のサポートのための要件をService Providerに提示します。
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.
最初に、問題声明を提供します。 そして、ドキュメントは既存のMPLS Traffic Engineeringメカニズムが不足して、Diff-Serv意識しているTraffic Engineeringが必要性を扱うことができるService Providersによって特定された例のアプリケーションシナリオについて説明します。 また、技術的解決法によって扱われる必要がある詳細な要件は再検討されます。 最終的に、ドキュメントは技術的解決法の選択と定義のために考えられるべきである評価基準を特定します。 このメモはインターネットコミュニティのための情報を提供します。
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
ISOC/IETFとISO/IECの共同専門委員会1/潜水艦委員会6(JTC1/SC6)の間の3563年のジニン2003年7月の共同契約、オンである、-、ルーティング・プロトコル開発
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.
このドキュメントがISOC/IETFとISO/IEC JTC1/SC6の間で共同開発に関して署名される協定書の文章を含んでいる、-、ルーティング・プロトコル 協定が2つの組織のための関連する仕事範囲、作成を求める要求、およびメインテナンスの定義を含んでいる、-、登録、IANA、および共同ガイドラインで。 このメモはインターネットコミュニティのための情報を提供します。
3562 Leech Jul 2003 Key Management Considerations
for the TCP MD5 Signature
Option
3562は2003年7月にTCP MD5署名オプションのための主要な管理問題を取ります。
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.
BGPによって支配的に使用されたTCP MD5 Signature Option(RFC2385)はインターネット基盤の重要な領域で重要な展開を見ました。 このオプションのセキュリティは大いに材料がMD5署名を計算するのに使用した合わせることの品質を当てにします。 このドキュメントは、材料を合わせながら、セキュリティがその要件であると扱います。 このメモはインターネットコミュニティのための情報を提供します。
Ginoza Informational [Page 12] RFC 3599 Summary of 3500-3599 December 2003
3500-3599 2003年12月の宜野座の情報[12ページ]のRFC3599概要
3561 Perkins Jul 2003 Ad hoc On-Demand Distance
Vector (AODV) Routing
パーキンス3561年2003年7月のAd hoc On-要求Distance Vector(AODV)ルート設定
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.
Ad hoc On-要求Distance Vector(AODV)ルーティング・プロトコルは使用のためにモバイルノードで臨時のネットワークで意図します。 それは、ダイナミックなリンク状態、低い処理、およびメモリの頭上の、そして、低いネットワーク利用への迅速な適合を提供して、臨時のネットワークの中でユニキャストルートを目的地に決定します。 それはいつも(ルーティングコントロールメッセージの変則的な配送に直面してさえ)輪の自由を確実にするのに目的地一連番号を使用します、古典的な距離ベクトルプロトコルに関連している問題(「無限勘定」などであることなどの)を避けて。 このメモはインターネットコミュニティのためにExperimentalプロトコルを定義します。
3560 Housley Jul 2003 Use of the RSAES-OAEP Key
Transport Algorithm in
the Cryptographic Message
Syntax (CMS)
3560 暗号のメッセージ構文におけるRSAES-OAEPの主要な輸送アルゴリズムのHousley2003年7月の使用(cm)
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]
このドキュメントは、RSAES-OAEPの主要な輸送アルゴリズムを使用するためにCryptographic Message Syntax(CMS)と共にコンベンションについて説明します。 CMSはおおわれたデータcontent typeを指定します。(それは、1人以上の受取人のための暗号化された内容と暗号化された満足している暗号化キーから成ります)。 意図している受取人のために満足している暗号化キーを暗号化するのにRSAES-OAEPの主要な輸送アルゴリズムを使用できます。 [標準化過程]
3559 Thaler Jun 2003 Multicast Address Allocation
MIB
3559 ターレルJun2003マルチキャストアドレス配分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]
ネットワーク管理プロトコルがインターネットコミュニティにある状態で、このメモは使用のために、Management Information基地の一部(MIB)を定義します。 特に、それはマルチキャストアドレス配分を管理するのに使用される管理オブジェクトについて説明します。 [標準化過程]
Ginoza Informational [Page 13] RFC 3599 Summary of 3500-3599 December 2003
3500-3599 2003年12月の宜野座の情報[13ページ]のRFC3599概要
3558 Li Jul 2003 RTP Payload Format for
Enhanced Variable Rate Codecs
(EVRC) and Selectable Mode
Vocoders (SMV)
3558 高められた変動金利コーデック(EVRC)と選択可能なモードボコーダのための李2003年7月のRTP有効搭載量形式(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]
このドキュメントはEnhanced Variable Rate Codec(EVRC)スピーチとSelectable Mode Vocoder(SMV)スピーチのためにRTPペイロード形式について説明します。 2つのサブ形式が異なったアプリケーションシナリオに指定されます。 添付されたかはさみ込まれた形式は、スピーチ品質でパケット損失の影響を減少させて、1個以上のスピーチフレームの上にRTPヘッダーのオーバーヘッドを清算するために含まれています。 また、非添付された形式は会話のアプリケーションのためにサポートされます。 [標準化過程]
3557 Xie, Ed. Jul 2003 RTP Payload Format for
European Telecommunications
Standards Institute (ETSI)
European Standard ES 201 108
Distributed Speech Recognition
Encoding
3557 シェ、ヨーロッパのテレコミュニケーション規格が(ETSI)ヨーロッパの標準のES201 108を設けるので、エド2003年7月のRTP有効搭載量形式は音声認識コード化を分配しました。
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]
分配された音声認識(DSR)システムのためにヨーロッパのTelecommunications Standards Institute(ETSI)のヨーロッパのStandard(ES)201 108がフロントエンド信号処理特徴ストリームであるとカプセル化するのにこのドキュメントはRTPペイロード形式を指定します。[標準化過程]
3556 Casner Jul 2003 Session Description Protocol
(SDP) Bandwidth Modifiers
for RTP Control Protocol
(RTCP) Bandwidth
RTP制御プロトコル(RTCP)帯域幅への3556のCasner2003年7月のセッション記述プロトコル(SDP)帯域幅修飾語
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]
このドキュメントは、2つの追加修飾語を帯域幅属性に指定するためにSession記述プロトコル(SDP)と拡大を定義します。 これらの修飾語は、レアル-時間Transportプロトコル(RTP)セッションのときにRTP Controlプロトコル(RTCP)パケットのために許容された帯域幅を指定するのに使用されるかもしれません。 [標準化過程]
Ginoza Informational [Page 14] RFC 3599 Summary of 3500-3599 December 2003
3500-3599 2003年12月の宜野座の情報[14ページ]のRFC3599概要
3555 Casner Jul 2003 MIME Type Registration of RTP
Payload Formats
3555 RTP有効搭載量形式のCasner2003年7月のMIMEの種類登録
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]
このドキュメントは、オーディオ、ビデオまたは他のMIME「副-タイプ」名としてRTP有効搭載量Formatsを登録するために手順を定義します。 これはベースのテキスト形式かRTPトランスミッションのタイプを特定する制御プロトコルで役に立ちます。 また、このドキュメントはAudioとVideoコンファレンスのためにRTP ProfileでMIME血液型亜型と定義されたすべてのRTPペイロード書式を登録します。 また、これらの或るものはRTP以外の転送モードに使用されるかもしれません。 [標準化過程]
3554 Bellovin Jul 2003 On the Use of Stream Control
Transmission Protocol (SCTP)
with IPsec
3554 IPsecとのストリーム制御伝動プロトコル(SCTP)の使用でのBellovin2003年7月
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]
このドキュメントはIPsec(RFC2401)とインターネット・キー・エクスチェンジ(IKE)(RFC2409)がSCTP(RFC2960)がトラフィックであると機密保護することにおける彼らの使用を容易にするという機能条件書について説明します。 [標準化過程]
3553 Mealling Jun 2003 An IETF URN Sub-namespace for
Registered Protocol Parameters
3553 2003年6月に登録されたプロトコルパラメタのためのサブ名前空間のIETFつぼを荒びきにすること。
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.
このドキュメントは登録されたプロトコル項目のために'ietf'URN名前空間のための新しい復委任について説明します。'ietf'URN名前空間はIETFについて言及する永続的なURIのための根がリソースを定義したようなRFC2648で定義されます。 このドキュメントはインターネット共同体、要求議論、および提案のためのインターネットBest Current Practicesを改良に指定します。
3552 Rescorla Jul 2003 Guidelines for Writing RFC
Text on Security
Considerations
3552 セキュリティ問題に関するテキストをRFCに書くためのレスコラ2003年7月ガイドライン
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.
すべてのRFCsが、Security Considerations部を持つのに必要です。 歴史的に、そのようなセクションは比較的弱いです。 このドキュメントはどう良いSecurity Considerations部に書くかのRFC作者にガイドラインを提供します。 このドキュメントはインターネット共同体、要求議論、および提案のためのインターネットBest Current Practicesを改良に指定します。
Ginoza Informational [Page 15] RFC 3599 Summary of 3500-3599 December 2003
3500-3599 2003年12月の宜野座の情報[15ページ]のRFC3599概要
3551 Schulzrinne Jul 2003 RTP Profile for Audio and
Video Conferences with Minimal
Control
Schulzrinne2003年7月のRTPがオーディオとテレビ会議システムのために最小量のコントロールで輪郭を描く3551
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.
このドキュメントはリアルタイムのトランスポート・プロトコル(RTP)、バージョン2、および関連制御プロトコルの使用のために"RTP/AVP"と呼ばれるプロフィールについて説明します、RTCP、最小量のコントロールとのオーディオとビデオ「マルチ-関係者」会議の中で。 それはオーディオとテレビ会議システムに適したRTP仕様の中でジェネリック分野の解釈を提供します。 特に、このドキュメントは1セットのデフォルトマッピングをペイロード形式数から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.
また、このドキュメントはオーディオとビデオ・データがRTPの中でどう運ばれるかもしれないかを説明します。 RTPの中で使用されると、それは標準のencodingsと彼らの名前の1セットを定義します。 記述は参照実装と詳細な規格に指針を提供します。 このドキュメントはオーディオ、ビデオ、および他のリアルタイムのマルチメディア応用の作成者のための援助として意味されます。
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]
このメモはRFC1890を時代遅れにします。 2つの共同利用できる実装が見つけられなかったので取り除かれた機能を除いて、それは後方にほとんど互換性があります。 RFC1890への追加は、このプロフィールの下でペイロード形式の使用における既存の習慣を成文化して、RFC1890が発行されたので形式が定義した新しいペイロードを含んでいます。 [標準化過程]
3550 Schulzrinne Jul 2003 RTP: A Transport Protocol for
Real-Time Applications
3550 Schulzrinne2003年7月のRTP: リアルタイムのアプリケーションのためのトランスポート・プロトコル
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.
このメモはRTP、リアルタイムのトランスポート・プロトコルについて説明します。 RTPは終わりから終わりへのネットワーク輸送リアルタイムデータを伝えるアプリケーションに適した機能を提供します、オーディオ、ビデオまたはシミュレーションデータなどのように、マルチキャストかユニキャストネットワーク・サービスの上で。 RTPが資源予約を扱わないで、また品質を保証しない、-、-、本当の時間指定サービスのためのサービス。 制御プロトコル(RTCP)によってデータ伝送は増大させられて、データ配送が大きいマルチキャストネットワークにスケーラブルな方法でモニターされるのを許容して、最小量のコントロールと識別の機能性を前提とします。 RTPとRTCPは、基本的な輸送とネットワーク層から独立しているように設計されています。 プロトコルはRTP-レベル翻訳者とミキサーの使用をサポートします。
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]
このメモのテキストの大部分はそれが時代遅れにするRFC1889と同じです。 ワイヤのパケット・フォーマットにおける変化ではなく、規則とアルゴリズムへのプロトコルがどう使用されているかを治める変化しかありません。 最も大きい変化は多くの関係者が同時にセッションに参加するとき、意図しているレートを超えてトランスミッションを最小にするためにいつパケットをRTCPに送るかを見込むためのスケーラブルなタイマアルゴリズムへの増進です。 [標準化過程]
Ginoza Informational [Page 16] RFC 3599 Summary of 3500-3599 December 2003
3500-3599 2003年12月の宜野座の情報[16ページ]のRFC3599概要
3549 Salim Jul 2003 Linux Netlink as an IP
Services Protocol
3549 IPサービスプロトコルとしてのサリム2003年7月のリナックスNetlink
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.).
このドキュメントはリナックスNetlinkについて説明します。(Netlinkはイントラカーネルメッセージシステムとカーネルとユーザスペースの間のリナックスに使用されます)。 このドキュメントの焦点はForwarding Engine Component(FEC)とControl Plane Component(CPC)(IPサービスを定義する2つのコンポーネント)の間でNetlinkの機能性をプロトコルとして記述することになっています。 この焦点の結果、このドキュメントはNetlinkの他の用途を無視します、イントラカーネルメッセージシステムとして、または、相互プロセスコミュニケーション体系(IPC)として、または、他の非ネットワークの、または、非IPのネットワーク・サービスのための構成ツール(decnetなどの)として使用を含んでいて。
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.
このドキュメントは従来技術の文脈のForCES IETFワーキンググループにおける情報として意図します。 このメモはインターネットコミュニティのための情報を提供します。
3548 Josefsson Jul 2003 The Base16, Base32, and Base64
Data Encodings
3548 Josefsson2003年7月のBase16、Base32、およびBase64データ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.
このドキュメントは一般的に使用されたベース64、ベース32、およびベース16コード化体系について説明します。 また、それはコード化されたデータにおける改行の使用、コード化されたデータでそっと歩くことの使用、コード化されたデータにおける非アルファベットキャラクタの使用、および異なったコード化アルファベットの使用について議論します。 このメモはインターネットコミュニティのための情報を提供します。
3547 Baugher Jul 2003 The Group Domain of
Interpretation
解釈の3547Baugher2003年7月のグループドメイン
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]
グループ重要経営者側が安全なグループコミュニケーションをサポートするように、このドキュメントはInterpretation(DOI)のISAMKP Domainを寄贈します。 GDOIはグループセキュリティ協会を経営します。(協会はIPSECとIPを動く潜在的に他のデータ機密保護プロトコルか応用層によって使用されます)。 これらのセキュリティ協会は1個以上のキーを暗号化するキー、トラフィックを暗号化するキー、またはグループのメンバーによって共有されたデータを保護します。 [標準化過程]
Ginoza Informational [Page 17] RFC 3599 Summary of 3500-3599 December 2003
3500-3599 2003年12月の宜野座の情報[17ページ]のRFC3599概要
3546 Blake-Wilson Jun 2003 Transport Layer Security (TLS)
Extensions
ブレーク-ウィルソン2003年6月が輸送する3546はセキュリティ(TLS)拡大を層にします。
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.
このドキュメントはTransport Layer Security(TLS)に機能性を加えるのに使用されるかもしれない拡張子について説明します。 それは、これらのジェネリックメカニズムを使用することでTLS握手クライアントとサーバのための両方のジェネリック拡張機能にhellos、および特定の拡大を提供します。
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]
拡張子はTLSクライアントとサーバによって使用されるかもしれません。 拡大が後方にそうである、コンパチブル、--コミュニケーションは間にTLS1.0に、拡大とTLS1.0サーバがそれであるとサポートするクライアントが拡大をサポートしないのが可能です、逆もまた同様に。 [標準化過程]
3545 Koren Jul 2003 Enhanced Compressed RTP (CRTP)
for Links with High Delay,
Packet Loss and Reordering
コーレン2003年7月が高めた3545は高い遅れ、パケット損失、およびReorderingとのリンクへのRTP(CRTP)を圧縮しました。
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]
ポイントがパケット損失と長時間の遅延とのリンクを指すように、このドキュメントはヘッダー圧縮技術について説明します。 IP/UDP/RTPヘッダー圧縮は、RFC2508でそれがCompressedレアル-時間Transportプロトコル(CRTP)に基づいていると説明しました。 CRTPはそのようなリンクの上によく振る舞いません: 文脈不正と長時間の遅延のためパケット損失結果、文脈が修理される前にずっと多くのパケットが捨てられます。 そのようなリンクの上にCRTPの動きを修正するために、プロトコルへのいくつかの拡大がここで指定されます。 拡大は、コンプレッサーが減圧装置で文脈をアップデートする方法を変えることによって文脈不正を抑えることを目指します: アップデートは、完全で特異な文脈パラメタに繰り返されて、アップデートを含んでいます。 これらの拡大で、CRTPはパケット損失、パケット再命令、および長時間の遅延とのリンクの上によく振る舞います。 [標準化過程]
3544 Koren Jul 2003 IP Header Compression over PPP
3544 pppの上のコーレンの2003年7月のIPヘッダー圧縮
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]
このドキュメントはPointからポイントへのプロトコル(RFC1661)の上に送られたIPデータグラムにおけるヘッダー圧縮の使用を交渉するためのオプションについて説明します。 それはIPv4とIPv6(RFC1332、RFC2472)のためにPPP Controlプロトコルと拡大を定義します。 ヘッダー圧縮はRFC2507、RFC2508、およびRFC3545の指定されるとしてのTCP、UDP、およびRTPトランスポート・プロトコルと組み合わせてIPv4とIPv6データグラムに適用されるかもしれません。 [標準化過程]
Ginoza Informational [Page 18] RFC 3599 Summary of 3500-3599 December 2003
3500-3599 2003年12月の宜野座の情報[18ページ]のRFC3599概要
3543 Glass Aug 2003 Registration Revocation in
Mobile IPv4
3543はモバイルIPv4で2003年8月の登録取消しをガラスで覆います。
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]
このドキュメントはモバイルノードに対するモバイルIPサービスを提供するのにかかわる移動性エージェントがこの登録の終了の同じモバイルノードに対するモバイルIPサービスを提供するもう片方の移動性エージェントに通知できるモバイルIPv4 Registration Revocationメカニズムを定義します。 また、メカニズムもまた、結合の終了の共同見つけられたモバイルノードに通知するホームのエージェントは使用可能です。 そのうえ、メカニズムは、承認されるためにこの通知に備えます。 モバイルIPv4プロトコルによって既に定義されたシグナル伝達機構は結合の取消しのモバイルノードを知らせる方法として利用されます。 [標準化過程]
3542 Stevens May 2003 Advanced Sockets Application
Program Interface (API) for
IPv6
スティーブンス3542年2003年5月のIPv6に、高度なソケット適用業務プログラム・インタフェース(API)
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.
このドキュメントは「高度な」IPv6アプリケーションをサポートするためにソケットApplication Program Interface(API)を提供します、別々の仕様への補足として、RFC3493。 予想されたアプリケーションはPing、Traceroute、ルーティングデーモン、および同様のものを含んでいます。(それは、IPv6かICMPv6ヘッダーフィールドにアクセスするのに生のソケットを通常使用します)。 このドキュメントはIPv6の下で生のソケットを使用するアプリケーションのためにいくつかの携帯用のインタフェースを提案します。 いくつかのアプリケーションがアクセスする必要があるIPv6の他の特徴があります: 識別(外向的なインタフェースを指定して、入って来るインタフェースを決定する)、IPv6拡張ヘッダー、および経路Maximum Transmission Unit(MTU)情報を連結してください。 このドキュメントはこれらの特徴にもAPIアクセスを提供します。 さらに、「r」コマンドのためのライブラリへのいくつかの拡張インターフェースが定義されます。 拡大はIPv6できない既存の実装により良い後方の互換性を提供するでしょう。 このメモはインターネットコミュニティのための情報を提供します。
3541 Walsh May 2003 A Uniform Resource Name (URN)
Namespace for the Web3D
Consortium (Web3D)
3541 Web3D共同体のための一定のリソース名前(つぼ)名前空間あたりのウォルシュ2003年5月(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.
このドキュメントはWeb3Dによって作り出されたか、または管理された技術文献や、仕様や、Virtual Reality Modeling Language(VRML)やExtensible3D(X3D)などの永続的なリソースをファイルとリソースと命名するためのWeb3D Consortium(Web3D)、拡張マークアップ言語(XML)ドキュメントType Definitions(DTD)、XML Schemas、名前空間、スタイルシート、メディア資産、および他のリソースのためにUniform Resource Name(URN)名前空間について説明します。 このメモはインターネットコミュニティのための情報を提供します。
Ginoza Informational [Page 19] RFC 3599 Summary of 3500-3599 December 2003
3500-3599 2003年12月の宜野座の情報[19ページ]のRFC3599概要
3540 Spring Jun 2003 Robust Explicit Congestion
Notification (ECN)
Signaling with Nonces
一回だけで合図して、3540は2003年6月の体力を要している明白な混雑通知(電子証券取引ネットワーク)を跳ばせます。
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.
この注意はExplicit Congestion Notification(電子証券取引ネットワーク)一回だけ(TCP送付者から著しいパケットの偶然の、または、悪意がある隠すことから守る電子証券取引ネットワークへの任意の追加)について説明します。 それは、ネットワーク回線容量の不公平なシェアを獲得するのに電子証券取引ネットワークを利用するのからの受信機を防ぐことによって、輻輳制御の丈夫さを改良します。 電子証券取引ネットワーク-一回だけは、IPヘッダーの電子証券取引ネットワーク分野で2の電子証券取引ネットワークできるTransport(ECT)codepointsを使用して、TCPヘッダーで旗を必要とします。 ルータとホストの両方には、それは計算上効率的です。 このメモはインターネットコミュニティのためにExperimentalプロトコルを定義します。
3539 Aboba Jun 2003 Authentication, Authorization
and Accounting (AAA) Transport
Profile
3539 Aboba2003年6月の認証、承認、および会計(AAA)輸送プロフィール
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]
このドキュメントはAuthentication、Authorization、およびAccounting(AAA)のためにプロトコルの中に起こる輸送問題について議論します。 また、それは輸送の使用のときにAAAプロトコルで推薦を提供します。 これは実験的な提案と同様に標準化過程RFCsの使用法を含んでいます。 [標準化過程]
3538 Kawatsura Jun 2003 Secure Electronic Transaction
(SET) Supplement for the v1.0
Internet Open Trading Protocol
(IOTP)
v1.0インターネットオープンTradingプロトコルのための3538年のKawatsura Jun2003Secure Electronic Transaction(SET)補足(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.
このドキュメントはインターネットオープンTradingプロトコル(IOTP)支払いApplication Programming Interface(API)のための詳細なInput/出力パラメタについて説明します。 また、それは、SET(SET Secure Electronic Transaction)の使用のためにIOTPのバージョン1.0の中でPayment Bridgeの手順を支払いプロトコルと説明します。 このメモはインターネットコミュニティのための情報を提供します。
Ginoza Informational [Page 20] RFC 3599 Summary of 3500-3599 December 2003
3500-3599 2003年12月の宜野座の情報[20ページ]のRFC3599概要
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
3537年のSchaad2003年5月のWrapping Triple-データ暗号化規格(DES)キーかエー・イー・エス(AES)キーによって主要なHashedメッセージ立証コード(HMAC)
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]
このドキュメントはHMAC(メッセージ立証コードを論じ尽くす)キーを包装するための2つのメソッドを定義します。 定義された最初のメソッドはHMACキーを暗号化するために主要なTriple DES(データ暗号化規格)を使用します。 定義された2番目のメソッドはHMACキーを暗号化するために主要なAES(エー・イー・エス)を使用します。 使用されるそのようなアルゴリズムがCMS(暗号のMessage Syntax)のAuthenticated Dataタイプのためのものである1つの場所。 [提案された標準]
3536 Hoffman May 2003 Terminology Used in
Internationalization in the
IETF
ホフマン2003年5月の用語がIETFでの国際化に使用した3536
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.
このドキュメントは国際化について議論するときIETFで使用される用語の用語集を提供します。 目的は、IETFの様々な領域での国際化のフレーム議論を助けて、IETF関係者に主な概念を紹介するのを助けることです。 このメモはインターネットコミュニティのための情報を提供します。
3535 Schoenwaelder May 2003 Overview of the 2002 IAB
Network Management
Workshop
3535 2002IABネットワークマネージメントワークショップのSchoenwaelder2003年5月の概要
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.
このドキュメントはNetwork Managementでインターネット・アーキテクチャ委員会(IAB)によって開かれたワークショップの概要を提供します。 そのワークショップは6月4日から2002年6月6日を通したレストン(ヴァージニア)(米国)でCNRIによって主催されました。 ワークショップの目標は、ネットワーク・オペレータとプロトコル開発者の間で始められた重要な対話を続けて、今後の活動のときにネットワークマネージメントに関してIETFs焦点を誘導することでした。 このレポートは、インターネット・エンジニアリング・タスク・フォース(IETF)共同体に議論をまとめて、結論と推薦を記載します。 このメモはインターネットコミュニティのための情報を提供します。
Ginoza Informational [Page 21] RFC 3599 Summary of 3500-3599 December 2003
3500-3599 2003年12月の宜野座の情報[21ページ]のRFC3599概要
3534 Walleij May 2003 The application/ogg Media
Type
3534Walleij2003年5月のアプリケーション/oggメディア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]
オッグBitstream Formatはコンピューティングプラットホームとネットワークの向こう側にマルチメディアコンテントを輸送する一般的で、自由に利用可能な規格になるのを目的とします。 このドキュメントの意志はインターネットの向こう側に輸送されるとこの種類の内容を示すためにMIMEメディアタイプアプリケーション/oggを定義することです。 それは知的所有権関心なしで使用可能であるというオッグBitstream Format開発者の意志です。 [標準化過程]
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はただ一つのサーバをサポートします。RFC2244で複数のIMAP4rev1サーバをサポートするために設定情報にアクセスするためのメカニズムについて議論します。
IMAP4rev1 does not specify a means of posting mail; this function is handled by a mail transfer protocol such as RFC 2821. [STANDARDS TRACK]
IMAP4rev1はメールを掲示する手段を指定しません。 この機能はRFC2821などのメール転送プロトコルによって扱われます。 [標準化過程]
Ginoza Informational [Page 32] RFC 3599 Summary of 3500-3599 December 2003
3500-3599 2003年12月の宜野座の情報[32ページ]のRFC3599概要
3500 Never Issued
3500 決して発行されませんでした。
RFC 3500 was never issued.
RFC3500は決して発行されませんでした。
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
南カリフォルニア情報Sciences Institute4676海軍本部Wayマリナデルレイの砂地の宜野座大学、カリフォルニア 90292
Phone: (310) 822-1511 EMail: ginoza@isi.edu
以下に電話をしてください。 (310) 822-1511 メールしてください: ginoza@isi.edu
Ginoza Informational [Page 33] RFC 3599 Summary of 3500-3599 December 2003
3500-3599 2003年12月の宜野座の情報[33ページ]のRFC3599概要
Full Copyright Statement
完全な著作権宣言文
Copyright (C) The Internet Society (2003). All Rights Reserved.
Copyright(C)インターネット協会(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.
それに関するこのドキュメントと翻訳は、コピーして、それが批評するか、またはそうでなければわかる他のもの、および派生している作品に提供するか、または準備されているかもしれなくて、コピーされて、発行されて、全体か一部広げられた実現を助けるかもしれません、どんな種類の制限なしでも、上の版権情報とこのパラグラフがそのようなすべてのコピーと派生している作品の上に含まれていれば。 しかしながら、このドキュメント自体は何らかの方法で変更されないかもしれません、インターネット協会か他のインターネット組織の版権情報か参照を取り除くのなどように、それを英語以外の言語に翻訳するのが著作権のための手順がインターネットStandardsの過程で定義したどのケースに従わなければならないか、必要に応じてさもなければ、インターネット標準を開発する目的に必要であるのを除いて。
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.
RFC Editor機能のための基金は現在、インターネット協会によって提供されます。
Ginoza Informational [Page 34]
宜野座情報です。[34ページ]
一覧
スポンサーリンク
