Movatterモバイル変換
[0]ホーム
[RFC Home] [TEXT|PDF|HTML] [Tracker] [IPR] [Info page]
INFORMATIONAL
Network Working Group A. RamosRequest for Comments: 2399 ISICategory: Informational January 1999Request for Comments Summary RFC Numbers 2300-2399Status of This Memo This RFC is a slightly annotated list of the 100 RFCs fromRFC 2300 through RFCs 2399. This is a status report on these RFCs. This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.Copyright Notice Copyright (C) The Internet Society (1999). All Rights Reserved.Note Many RFCs, but not all, are Proposed Standards, Draft Standards, or Standards. Since the status of these RFCs may change during the standards processing, we note here only that they are on the standards track. Please see the latest edition of "Internet Official Protocol Standards" for the current state and status of these RFCs. In the following, RFCs on the standards track are marked [STANDARDS- TRACK].RFC Author Date Title--- ------ ---- -----2399 Ramos Jan 1999 Request for Comments SummaryThis memo.2398 Parker Aug 1998 Some Testing Tools for TCP ImplementorsThis document lists only tools which can evaluate one or more TCPimplementations, or which can privde some specific results whichdescribe or evaluate the TCP being tested. This memo providesinformation for the Internet community. It does not specify an Internetstandard of any kind.Ramos Informational [Page 1]
RFC 2399 Summary of 2300-2399 January 19992397 Masinter Aug 1998 The "data" URL schemeA new URL scheme, "data", is defined. It allows inclusion of small dataitems as "immediate" data, as if it had been included externally.[STANDARDS-TRACK]2396 Berners-Lee Aug 1998 Uniform Resource Identifiers (URI): Generic SyntaxThis document defines a grammar that is a superset of all valid URI,such that an implementation can parse the common components of a URIreference without knowing the scheme-specific requirements of everypossible identifier type. [STANDARDS-TRACK]2395 Friend Dec 1998 IP Payload Compression Using LZSThis document describes a compression method based on the LZScompression algorithm. This document defines the application of the LZSalgorithm to the IP Payload Compression Protocol. This memo providesinformation for the Internet community. It does not specify an Internetstandard of any kind.2394 Pereira Dec 1998 IP Payload Compression Using DEFLATEThis document describes a compression method based on the DEFLATEcompression algorithm. This document defines the application of theDEFLATE algorithm to the IP Payload Compression Protocol. This memoprovides information for the Internet community. It does not specify anInternet standard of any kind.2393 Shacham Dec 1998 IP Payload Compression Protocol (IPComp)This document describes a protocol intended to provide losslesscompression for Internet Protocol datagrams in an Internet environment.[STANDARDS-TRACK]Ramos Informational [Page 2]
RFC 2399 Summary of 2300-2399 January 19992392 Levinson Aug 1998 Content-ID and Message-ID Uniform Resource LocatorsThe Uniform Resource Locator (URL) schemes, "cid:" and "mid:" allowreferences to messages and the body parts of messages. For example,within a single multipart message, one HTML body part might includeembedded references to other parts of the same message. [STANDARDS-TRACK]2391 Srisuresh Aug 1998 Load Sharing using IP Network Address Translation (LSNAT)In this document, we extend the use of NATs to offer Load share feature,where session load can be distributed across a pool of servers, insteadof directing to a single server. This memo provides information for theInternet community. It does not specify an Internet standard of anykind.2390 Bradley Sep 1998 Inverse Address Resolution ProtocolThis memo describes additions to ARP that will allow a station torequest a protocol address corresponding to a given hardware address.[STANDARDS-TRACK]2389 Hethmon Aug 1998 Feature negotiation mechanism for the File Transfer ProtocolThis document provides a mechanism by which clients of the FTP protocolcan discover which new features are supported by a particular FTPserver. [STANDARDS-TRACK]2388 Masinter Aug 1998 Returning Values from Forms: multipart/form-dataThis specification defines an Internet Media Type, multipart/form-data,which can be used by a wide variety of applications and transported by awide variety of protocols as a way of returning a set of values as theresult of a user filling out a form. [STANDARDS-TRACK]Ramos Informational [Page 3]
RFC 2399 Summary of 2300-2399 January 19992387 Levinson Aug 1998 The MIME Multipart/Related Content-typeThis document defines the Multipart/Related content-type and providesexamples of its use. [STANDARDS-TRACK]2386 Crawley Aug 1998 A Framework for QoS-based Routing in the InternetThis document describes some of the QoS-based routing issues andrequirements, and proposes a framework for QoS-based routing in theInternet. This memo provides information for the Internet community.It does not specify an Internet standard of any kind.2385 Heffernan Aug 1998 Protection of BGP Sessions via the TCP MD5 Signature OptionThis memo describes a TCP extension to enhance security for BGP.[STANDARDS-TRACK]2384 Gellens Aug 1998 POP URL SchemeThis memo defines a URL scheme for referencing a POP mailbox.[STANDARDS-TRACK]2383 Suzuki Aug 1998 ST2+ over ATM Protocol Specification - UNI 3.1 VersionThis document specifies an ATM-based protocol for communication betweenST2+ agents. This memo provides information for the Internet community.It does not specify an Internet standard of any kind.2382 Crawley Aug 1998 A Framework for Integrated Services and RSVP over ATMThis document outlines the issues and framework related to providing IPIntegrated Services with RSVP over ATM. This memo provides informationfor the Internet community. It does not specify an Internet standard ofany kind.Ramos Informational [Page 4]
RFC 2399 Summary of 2300-2399 January 19992381 Garrett Aug 1998 Interoperation of Controlled-Load Service and Guaranteed Service with ATMThis document provides guidelines for mapping service classes, andtraffic management features and parameters between Internet and ATMtechnologies. [STANDARDS-TRACK]2380 Berger Aug 1998 RSVP over ATM Implementation RequirementsThis memo presents specific implementation requirements for running RSVPover ATM switched virtual circuits (SVCs). It presents requirementsthat ensure interoperability between multiple implementations andconformance to the RSVP and Integrated Services specifications.[STANDARDS-TRACK]2379 Berger Aug 1998 RSVP over ATM Implementation GuidelinesThis memo presents specific implementation guidelines for running RSVPover ATM switched virtual circuits (SVCs). This document specifies anInternet Best Current Practices for the Internet Community, and requestsdiscussion and suggestions for improvements.2378 Hedberg Sep 1998 The CCSO Nameserver (Ph) ArchitectureThe Ph Nameserver from the Computing and Communications Services Office(CCSO), University of Illinois at Urbana-Champaign has for some time nowbeen used by several organizations as their choice of publicly availabledatabase for information about people as well as other things. Thisdocument provides a formal definition of the client-server protocol.This memo provides information for the Internet community. It does notspecify an Internet standard of any kind.2377 Grimstad Sep 1998 Naming Plan for Internet Directory-Enabled ApplicationsApplication of the conventional X.500 approach to naming has heretofore,in the experience of the authors, proven to be an obstacle to the widedeployment of directory-enabled applications on the Internet. Wepropose a new directory naming plan that leverages the strengths of themost popular and successful Internet naming schemes for naming objectsRamos Informational [Page 5]
RFC 2399 Summary of 2300-2399 January 1999in a hierarchical directory. This memo provides information for theInternet community. It does not specify an Internet standard of anykind.2376 Whitehead Jul 1998 XML Media TypesThis document proposes two new media subtypes, text/xml andapplication/xml, for use in exchanging network entities which areconforming Extensible Markup Language (XML). This memo providesinformation for the Internet community. It does not specify an Internetstandard of any kind.2375 Hinden Jul 1998 IPv6 Multicast Address AssignmentsThis document defines the initial assignment of IPv6 multicastaddresses. This memo provides information for the Internet community.It does not specify an Internet standard of any kind.2374 Hinden Jul 1998 An IPv6 Aggregatable Global Unicast Address FormatThis document defines an IPv6 aggregatable global unicast address formatfor use in the Internet. [STANDARDS-TRACK]2373 Hinden Jul 1998 IP Version 6 Addressing ArchitectureThis specification defines the addressing architecture of the IP Version6 protocol [IPV6].[STANDARDS-TRACK]2372 Evans Jul 1998 Transaction Internet Protocol - Requirements and Supplemental InformationThis document describes the purpose (usage scenarios), and requirementsfor the Transaction Internet Protocol. This memo provides informationfor the Internet community. It does not specify an Internet standard ofany kind.Ramos Informational [Page 6]
RFC 2399 Summary of 2300-2399 January 19992371 Lyon Jul 1998 Transaction Internet Protocol Version 3.0In many applications where different nodes cooperate on some work, thereis a need to guarantee that the work happens atomically. That is, eachnode must reach the same conclusion as to whether the work is to becompleted, even in the face of failures. This document proposes asimple, easily-implemented protocol for achieving this end.[STANDARDS-TRACK]2370 Coltun Jul 1998 The OSPF Opaque LSA OptionThis memo defines enhancements to the OSPF protocol to support a newclass of link-state advertisements (LSA) called Opaque LSAs.[STANDARDS-TRACK]2369 Neufeld Jul 1998 The Use of URLs as Meta-Syntax for Core Mail List Commands and their Transport through Message Header FieldsThe mailing list command specification header fields are a set ofstructured fields to be added to email messages sent by emaildistribution lists.By including these header fields, list servers can make it possible formail clients to provide automated tools for users to perform listfunctions. This could take the form of a menu item, push button, orother user interface element. The intent is to simplify the userexperience, providing a common interface to the often cryptic and variedmailing list manager commands. [STANDARDS-TRACK]2368 Hoffman Jul 1998 The mailto URL schemeThis document defines the format of Uniform Resource Locators (URL) fordesignating electronic mail addresses. [STANDARDS-TRACK]Ramos Informational [Page 7]
RFC 2399 Summary of 2300-2399 January 19992367 McDonald Jul 1998 PF_KEY Key Management API, Version 2A generic key management API that can be used not only for IP Securitybut also for other network security services is presented in thisdocument. This memo provides information for the Internet community.It does not specify an Internet standard of any kind.2366 Chung Jul 1998 Definitions of Managed Objects for Multicast over UNI 3.0/3.1 based ATM NetworksThis memo defines a portion of the Management Information Base (MIB) foruse with network management protocols in the Internet community. Inparticular, it describes managed objects for IP hosts and routers thatuse a Multicast Address Resolution Server (MARS) to support IP multicastover ATM, as described in 'Support for Multicast over UNI 3.0/3.1 basedATM Networks'. [STANDARDS-TRACK]2365 Meyer Jul 1998 Administratively Scoped IP MulticastThis document defines the "administratively scoped IPv4 multicast space"to be the range 239.0.0.0 to 239.255.255.255. In addition, it describesa simple set of semantics for the implementation of AdministrativelyScoped IP Multicast. Finally, it provides a mapping between the IPv6multicast address classes [RFC1884] and IPv4 multicast address classes.This document specifies an Internet Best Current Practices for theInternet Community, and requests discussion and suggestions forimprovements.2364 Gross Jul 1998 PPP Over AAL5This document describes the use of ATM Adaptation Layer 5 (AAL5) forframing PPP encapsulated packets. [STANDARDS-TRACK]2363 Gross Jul 1998 PPP Over FUNIThis document describes the use of ATM Frame User Network Interface(FUNI) for framing PPP encapsulated packets. [STANDARDS-TRACK]Ramos Informational [Page 8]
RFC 2399 Summary of 2300-2399 January 19992362 Estrin Jun 1998 Protocol Independent Multicast-Sparse Mode (PIM-SM): Protocol SpecificationThis document describes a protocol for efficiently routing to multicastgroups that may span wide-area (and inter-domain) internets. This memodefines an Experimental Protocol for the Internet community. It doesnot specify an Internet standard of any kind. Discussion andsuggestions for improvement are requested.2361 Fleischman Jun 1998 WAVE and AVI Codec RegistriesThe purpose of this paper is to establish a mechanism by which codecsregistered within Microsoft's WAVE and AVI Registries may be referencedwithin the IANA Namespace by Internet applications. This memo providesinformation for the Internet community. It does not specify an Internetstandard of any kind.2360 Scott Jun 1998 Guide for Internet Standards WritersThis document is a guide for Internet standard writers. It definesthose characteristics that make standards coherent, unambiguous, andeasy to interpret. This document specifies an Internet Best CurrentPractices for the Internet Community, and requests discussion andsuggestions for improvements.2359 Myers Jun 1998 IMAP4 UIDPLUS extensionThe UIDPLUS extension of the Internet Message Access Protocol [IMAP4]provides a set of features intended to reduce the amount of time andresources used by some client operations. [STANDARDS-TRACK]2358 Flick Jun 1998 Definitions of Managed Objects for the Ethernet-like Interface TypesThis memo defines a portion of the Management Information Base (MIB) foruse with network management protocols in the Internet community. Thismemo obsoletesRFC 1650 "Definitions of Managed Objects for theEthernet-like Interface Types using SMIv2". This memo extends thatspecification by including management information useful for themanagement of 100 Mb/s Ethernet interfaces. [STANDARDS-TRACK]Ramos Informational [Page 9]
RFC 2399 Summary of 2300-2399 January 19992357 Mankin Jun 1998 IETF Criteria for Evaluating Reliable Multicast Transport and Application ProtocolsThis memo describes the procedures and criteria for reviewing reliablemulticast protocols within the Transport Area (TSV) of the IETF. Withintoday's Internet, important applications exist for a reliable multicastservice. This memo provides information for the Internet community. Itdoes not specify an Internet standard of any kind.2356 Montenegro Jun 1998 Sun's SKIP Firewall Traversal for Mobile IPThe Mobile IP specification establishes the mechanisms that enable amobile host to maintain and use the same IP address as it changes itspoint of attachment to the network. The mechanisms described in thisdocument allow a mobile node out on a public sector of the internet tonegotiate access past a SKIP firewall, and construct a secure channelinto its home network. This memo provides information for the Internetcommunity. This memo does not specify an Internet standard of any kind.2355 Kelly Jun 1998 TN3270 EnhancementsThis document describes a protocol that more fully supports 3270 devicesthan do traditional tn3270 practices. [STANDARDS-TRACK]2354 Perkins Jun 1998 Options for Repair of Streaming MediaThis document summarizes a range of possible techniques for the repairof continuous media streams subject to packet loss. This memo providesinformation for the Internet community. This memo does not specify anInternet standard of any kind.2353 Dudley May 1998 APPN/HPR in IP Networks APPN Implementers' Workshop Closed Pages DocumentThis memo defines a method with which HPR nodes can use IP networks forcommunication, and the enhancements to APPN required by this method.This memo also describes an option set that allows the use of the APPNconnection network model to allow HPR nodes to use IPRamos Informational [Page 10]
RFC 2399 Summary of 2300-2399 January 1999networks for communication without having to predefine link connections.This memo provides information for the Internet community. It does notspecify an Internet standard of any kind.2352 Vaughan May 1998 A Convention For Using Legal Names as Domain NamesThe purpose of this memo is to focus discussion on the particularproblems with the exhaustion of the top level domain space in theInternet and the possible conflicts that can occur when multipleorganisations are vying for the same name. This memo providesinformation for the Internet community. It does not specify an Internetstandard of any kind.2351 Robert May 1998 Mapping of Airline Reservation, Ticketing, and Messaging Traffic over IPThis memo specifies a protocol for the encapsulation of the airlinespecific protocol over IP. This memo provides information for theInternet community. It does not specify an Internet standard of anykind.2250 Brownlee Jun 1998 Expectations for Computer Security Incident ResponseThe purpose of this document is to express the general Internetcommunity's expectations of Computer Security Incident Response Teams(CSIRTs). It is not possible to define a set of requirements that wouldbe appropriate for all teams, but it is possible and helpful to list anddescribe the general set of topics and issues which are of concern andinterest to constituent communities. This document specifies anInternet Best Current Practices for the Internet Community, and requestsdiscussion and suggestions for improvements.2349 Malkin May 1998 TFTP Timeout Interval and Transfer Size OptionsThe Trivial File Transfer Protocol is a simple, lock-step, file transferprotocol which allows a client to get or put a file onto a remote host.This document describes two TFTP options. [STANDARDS-TRACK]Ramos Informational [Page 11]
RFC 2399 Summary of 2300-2399 January 19992348 Malkin May 1998 TFTP Blocksize OptionThe Trivial File Transfer Protocol is a simple, lock-step, file transferprotocol which allows a client to get or put a file onto a remote host.This document describes a TFTP option which allows the client and serverto negotiate a blocksize more applicable to the network medium.[STANDARDS-TRACK]2347 Malkin May 1998 TFTP Option ExtensionThe Trivial File Transfer Protocol is a simple, lock-step, file transferprotocol which allows a client to get or put a file onto a remote host.This document describes a simple extension to TFTP to allow optionnegotiation prior to the file transfer. [STANDARDS-TRACK]2346 Palme May 1998 Making Postscript and PDF InternationalCertain text formats, for example Postscript (MIME-Type:application/postscript; file extension .ps) and Portable Document Format(MIME-Type: application/pdf; file extension .pdf) specify exactly thepage layout of the printed document. The commonly used paper format isdifferent in North America and the rest of the world. North Americauses the 'Letter' format, while the rest of the world mostly uses theISO-standard 'A4' format. This means that documents formatted on onecontinent may not be easily printable on another continent. This memogives advice on how to produce documents which are equally wellprintable with the Letter and the A4 formats. This memo providesinformation for the Internet community. It does not specify an Internetstandard of any kind.2345 Klensin May 1998 Domain Names and Company Name RetrievalThis document proposes a company name to URL mapping service based onthe oldest and least complex of Internet directory protocols, whois, inorder to explore whether an extremely simple and widely-deployedprotocol can succeed where more complex and powerful options have failedor been excessively delayed. This memo defines an Experimental Protocolfor the Internet community. It does not specify an Internet standard ofany kind. Discussion and suggestions for improvement are requested.Ramos Informational [Page 12]
RFC 2399 Summary of 2300-2399 January 19992344 Montenegro May 1998 Reverse Tunneling for Mobile IPThis document proposes backwards-compatible extensions to Mobile IP inorder to support topologically correct reverse tunnels. [STANDARDS-TRACK]2343 Civanlar May 1998 RTP Payload Format for Bundled MPEGThis document describes a payload type for bundled, MPEG-2 encoded videoand audio data that may be used with RTP, version 2. This memo definesan Experimental Protocol for the Internet community. This memo does notspecify an Internet standard of any kind. Discussion and suggestionsfor improvement are requested.2342 Gahrns May 1998 IMAP4 NamespaceThis document defines a NAMESPACE command that allows a client todiscover the prefixes of namespaces used by a server for personalmailboxes, other users' mailboxes, and shared mailboxes. [STANDARDS-TRACK]2341 Valencia May 1998 Cisco Layer Two Forwarding (Protocol) "L2F"This document describes the Layer Two Forwarding protocol (L2F) whichpermits the tunneling of the link layer (i.e., HDLC, async HDLC, or SLIPframes) of higher level protocols. This memo describes a historicprotocol for the Internet community. It does not specify an Internetstandard of any kind.2340 Jamoussi May 1998 Nortel's Virtual Network Switching (VNS) OverviewThis document provides an overview of Virtual Network Switching (VNS).This memo provides information for the Internet community. It does notspecify an Internet standard of any kind.Ramos Informational [Page 13]
RFC 2399 Summary of 2300-2399 January 19992339 ISOC May 1998 An Agreement Between the Internet Society, the IETF, and Sun Microsystems, Inc. in the matter of NFS V.4 ProtocolsThis Request for Comments records an agreement between Sun Microsystems,Inc. and the Internet Society to permit the flow of Sun's Network FileSystem specifications into the Internet Standards process conducted bythe Internet Engineering Task Force. This memo provides information forthe Internet community. It does not specify an Internet standard of anykind.2338 Knight Apr 1998 Virtual Router Redundancy ProtocolThis memo defines the Virtual Router Redundancy Protocol (VRRP). VRRPspecifies an election protocol that dynamically assigns responsibilityfor a virtual router to one of the VRRP routers on a LAN. [STANDARDS-TRACK]2337 Farinacci Apr 1998 Intra-LIS IP multicast among routers over ATM using Sparse Mode PIMThis document describes how intra-LIS IP multicast can be efficientlysupported among routers over ATM without using the Multicast AddressResolution Server (MARS). This memo defines an Experimental Protocolfor the Internet community. It does not specify an Internet standard ofany kind. Discussion and suggestions for improvement are requested.2336 Luciani Jul 1998 Classical IP and ARP over ATM to NHRP TransitionThis document describes methods and procedures for the gracefultransition from an ATMARP LIS to an NHRP LIS network model over ATM.This memo provides information for the Internet community. It does notspecify an Internet standard of any kind.2335 Luciani Apr 1998 A Distributed NHRP Service Using SCSPThis document describes a method for distributing an NHRP service withina LIS. [STANDARDS-TRACK]Ramos Informational [Page 14]
RFC 2399 Summary of 2300-2399 January 19992334 Luciani Apr 1998 Server Cache Synchronization Protocol (SCSP)This document describes the Server Cache Synchronization Protocol (SCSP)and is written in terms of SCSP's use within Non Broadcast MultipleAccess (NBMA) networks; although, a somewhat straight forward usage isapplicable to BMA networks. [STANDARDS-TRACK]2333 Cansever Apr 1998 NHRP Protocol Applicability StatementAs required by the Routing Protocol Criteria [RFC 1264], this memodiscusses the applicability of the Next Hop Resolution Protocol (NHRP)in routing of IP datagrams over Non-Broadcast Multiple Access (NBMA)networks, such as ATM, SMDS and X.25. [STANDARDS-TRACK]2332 Luciani Apr 1998 NBMA Next Hop Resolution Protocol (NHRP)This document describes the NBMA Next Hop Resolution Protocol (NHRP).NHRP can be used by a source station (host or router) connected to aNon-Broadcast, Multi-Access (NBMA) subnetwork to determine theinternetworking layer address and NBMA subnetwork addresses of the "NBMAnext hop" towards a destination station. [STANDARDS-TRACK]2331 Maher Apr 1998 ATM Signalling Support for IP over ATM - UNI Signalling 4.0 UpdateThis memo describes how to efficiently use the ATM call controlsignalling procedures defined in UNI Signalling 4.0 to support IP overATM environments as described inRFC 2225 and inRFC 2332. [STANDARDS-TRACK]2330 Paxson May 1998 Framework for IP Performance MetricsThe purpose of this memo is to define a general framework for particularmetrics to be developed by the IETF's IP Performance Metrics effort.This memo provides information for the Internet community. It does notspecify an Internet standard of any kind.Ramos Informational [Page 15]
RFC 2399 Summary of 2300-2399 January 19992329 Moy Apr 1998 OSPF Standardization ReportThis memo documents how the requirements for advancing a routingprotocol to Full Standard have been met for OSPFv2. This memo providesinformation for the Internet community. It does not specify an Internetstandard of any kind.2328 Moy Apr 1998 OSPF Version 2This memo documents version 2 of the OSPF protocol. OSPF is a link-state routing protocol. [STANDARDS-TRACK]2327 Handley Apr 1998 SDP: Session Description ProtocolThis document defines the Session Description Protocol, SDP. SDP isintended for describing multimedia sessions for the purposes of sessionannouncement, session invitation, and other forms of multimedia sessioninitiation. [STANDARDS-TRACK]2326 Schulzrinne Apr 1998 Real Time Streaming Protocol (RTSP)The Real Time Streaming Protocol, or RTSP, is an application-levelprotocol for control over the delivery of data with real-timeproperties. RTSP provides an extensible framework to enable controlled,on-demand delivery of real-time data, such as audio and video.[STANDARDS-TRACK]2325 Slavitch 1 Apr 1998 Definitions of Managed Objects for Drip-Type Heated Beverage Hardware Devices using SMIv2This memo defines an extension to the Management Information Base (MIB)for use with network management protocols in the Internet community. Inparticular, it defines objects for the management of coffee-brewing andmaintenance devices. This memo provides information for the Internetcommunity. It does not specify an Internet standard of any kind.Ramos Informational [Page 16]
RFC 2399 Summary of 2300-2399 January 19992324 Masinter 1 Apr 1998 Hyper Text Coffee Pot Control Protocol (HTCPCP/1.0)This document describes HTCPCP, a protocol for controlling, monitoring,and diagnosing coffee pots. This memo provides information for theInternet community. It does not specify an Internet standard of anykind.2323 Ramos 1 Apr 1998 IETF Identification and Security GuidelinesThis RFC is meant to represent a guideline by which the IETF conferencesmay run more effeciently with regards to identification and securityprotocols, with specific attention paid to a particular sub-group withinthe IETF: "facial hairius extremis". This memo provides information forthe Internet community. It does not specify an Internet standard of anykind.2322 van den Hout 1 Apr 1998 Management of IP numbers by peg-dhcpThis RFC describes a protocol to dynamically hand out ip-numbers onfield networks and small events that don't necessarily have a clearorganisational body. This memo provides information for the Internetcommunity. It does not specify an Internet standard of any kind.2321 Bressen 1 Apr 1998 RITA -- The Reliable Internetwork Troubleshooting AgentA Description of the usage of Nondeterministic Troubleshooting andDiagnostic Methodologies as applied to today's complex nondeterministicnetworks and environments. This memo provides information for theInternet community. It does not specify an Internet standard of anykind.2320 Greene Apr 1998 Definitions of Managed Objects for Classical IP and ARP Over ATM Using SMIv2The purpose of this memo is to define the Management Information Base(MIB) for supporting Classical IP and ARP over ATM as specified inClassical IP and ARP over ATM. [STANDARDS-TRACK]Ramos Informational [Page 17]
RFC 2399 Summary of 2300-2399 January 19992319 KOI8-U WG Apr 1998 Ukrainian Character Set KOI8-UThis document provides information about character encoding KOI8-U (KOI8Ukrainian) wich is a de-facto standard in Ukrainian Internet community.This memo provides information for the Internet community. It does notspecify an Internet standard of any kind.2318 Lie Mar 1998 The text/css Media TypeThis memo provides information about the text/css Media Type. This memoprovides information for the Internet community. It does not specify anInternet standard of any kind.2317 Eidnes Mar 1998 Classless IN-ADDR.ARPA delegationThis document describes a way to do IN-ADDR.ARPA delegation on non-octetboundaries for address spaces covering fewer than 256 addresses. Thisdocument specifies an Internet Best Current Practices for the InternetCommunity, and requests discussion and suggestions for improvements.2316 Bellovin Apr 1998 Report of the IAB Security Architecture WorkshopOn 3-5 March 1997, the IAB held a security architecture workshop at BellLabs in Murray Hill, NJ. We identified the core security components ofthe architecture, and specified several documents that need to bewritten. Most importantly, we agreed that security was not optional,and that it needed to be designed in from the beginning. This memoprovides information for the Internet community. It does not specify anInternet standard of any kind.2315 Kaliski Mar 1998 PKCS #7: Cryptographic Message Syntax Version 1.5This document describes a general syntax for data that may havecryptography applied to it, such as digital signatures and digitalenvelopes. This memo provides information for the Internet community.It does not specify an Internet standard of any kind.Ramos Informational [Page 18]
RFC 2399 Summary of 2300-2399 January 19992314 Kaliski Mar 1998 PKCS #10: Certification Request Syntax Version 1.5This document describes a syntax for certification requests. This memoprovides information for the Internet community. It does not specify anInternet standard of any kind.2313 Kaliski Mar 1998 PKCS #1: RSA Encryption Version 1.5This document describes a method for encrypting data using the RSApublic-key cryptosystem. This memo provides information for theInternet community. It does not specify an Internet standard of anykind.2312 Dusse Mar 1998 S/MIME Version 2 Certificate HandlingThis memo describes the mechanisms S/MIME uses to create and validatekeys using certificates. This memo provides information for theInternet community. It does not specify an Internet standard of anykind.2311 Dusse Mar 1998 S/MIME Version 2 Message SpecificationThis document describes a protocol for adding cryptographic signatureand encryption services to MIME data. This memo provides informationfor the Internet community. It does not specify an Internet standard ofany kind.2310 Holtman Apr 1998 The Safe Response Header FieldThis document defines a HTTP response header field called Safe, whichcan be used to indicate that repeating a HTTP request is safe. Thismemo defines an Experimental Protocol for the Internet community. Itdoes not specify an Internet standard of any kind. Discussion andsuggestions for improvement are requested.Ramos Informational [Page 19]
RFC 2399 Summary of 2300-2399 January 19992309 Braden Apr 1998 Recommendations on Queue Management and Congestion Avoidance in the InternetThis memo presents two recommendations to the Internet communityconcerning measures to improve and preserve Internet performance. Itpresents a strong recommendation for testing, standardization, andwidespread deployment of active queue management in routers, to improvethe performance of today's Internet. It also urges a concerted effortof research, measurement, and ultimate deployment of router mechanismsto protect the Internet from flows that are not sufficiently responsiveto congestion notification. This memo provides information for theInternet community. It does not specify an Internet standard of anykind.2308 Andrews Mar 1998 Negative Caching of DNS Queries (DNS NCACHE)RFC1034 provided a description of how to cache negative responses. Ithowever had a fundamental flaw in that it did not allow a name server tohand out those cached responses to other resolvers, thereby greatlyreducing the effect of the caching. This document addresses issuesraise in the light of experience and replacesRFC1034 Section 4.3.4.[STANDARDS-TRACK]2307 Howard Mar 1998 An Approach for Using LDAP as a Network Information ServiceThis document describes an experimental mechanism for mapping entitiesrelated to TCP/IP and the UNIX system into X.500 entries so that theymay be resolved with the Lightweight Directory Access Protocol[RFC2251]. This memo defines an Experimental Protocol for the Internetcommunity. It does not specify an Internet standard of any kind.Discussion and suggestions for improvement are requested.2306 Parsons Mar 1998 Tag Image File Format (TIFF) - F Profile for FacsimileThis document describes in detail the definition of TIFF-F that is usedto store facsimile images. This memo provides information for theInternet community. It does not specify an Internet standard of anykind.Ramos Informational [Page 20]
RFC 2399 Summary of 2300-2399 January 19992305 Toyoda Mar 1998 A Simple Mode of Facsimile Using Internet MailThis specification provides for "simple mode" carriage of facsimile dataover the Internet. [STANDARDS-TRACK]2304 Allocchio Mar 1998 Minimal FAX address format in Internet MailThis memo describes the MINIMAL addressing method and standardextensions to encode FAX addresses in e-mail addresses. [STANDARDS-TRACK]2303 Allocchio Mar 1998 Minimal PSTN address format in Internet MailThis memo describes the MINIMAL addressing method to encode PSTNaddresses into e-mail addresses and the standard extension mechanism toallow definition of further standard elements. [STANDARDS-TRACK]2302 Parsons Mar 1998 Tag Image File Format (TIFF) - image/tiff MIME Sub-type RegistrationThis document describes the registration of the MIME sub-typeimage/tiff. [STANDARDS-TRACK]2301 McIntyre Mar 1998 File Format for Internet FaxThis document describes the TIFF (Tag Image File Format) representationof image data specified by the ITU-T Recommendations for black-and-whiteand color facsimile. [STANDARDS-TRACK]2300 IAB May 1998 INTERNET OFFICIAL PROTOCOL STANDARDSA discussion of the standardization process and the RFC document seriesis presented first, followed by an explanation of the terms. Sections6.2 - 6.10 contain the lists of protocols in each stage ofstandardization. Finally are pointers to references and contacts forfurther information. [STANDARDS-TRACK]Ramos Informational [Page 21]
RFC 2399 Summary of 2300-2399 January 1999Security Considerations There are no security issues in this Informational RFC.Author's Address Alegre Ramos University of Southern California Information Sciences Institute 4676 Admiralty Way Marina del Rey, CA 90292 Phone: (310) 822-1511 EMail: ramos@isi.eduRamos Informational [Page 22]
RFC 2399 Summary of 2300-2399 January 1999Full Copyright Statement Copyright (C) The Internet Society (1999). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.Ramos Informational [Page 23]
[8]ページ先頭