Computer Security - Hacking And Hackers Information Security Resource Portal security hacking hackers hacker news downloads crackers virus virii viruses hacked webpages DOS denial of service hacking files hack files hack links hacking links encryption spoofing news texts password crackers port monitors key logger phreaking boxes wardialers patches exploits computer security network security privacy encryption computer crime firewallsinformation warfare intrusion detection hackers elec

Computer Security - Hacking And Hackers Information Security Resource Portal

" The most comprehensive computer and network security resource
on the Internet for Information System Security Professionals "
- Says Yahoo, Jan 2000

" Impacting the way people WORK: This award goes to the web site that has fulfilled its mission
in actualizing ideas that change the way people work "
- Says Impact Award 2000, Feb 9th

( This Site is Optimized for IExplorer 4.xx - 5.XX and Netscape 4.XX - 1024 X 768 )
Download LANguard Internet/Network access control Now !
Click here to download LANguard Internet / Network access control or to read more about it


Cartoon Courtesy of Steve Sack

Return to Main Menu

Return to Main Menu

Our Research Facility

Audit - Detect Network Intrusions
Anonymity & Privacy
ATM - Asynchronous Transfer
Biometrics
Business Continuity Planning
Cellular Communications
Computer Crime & Investigations
Computer Hardware Tutorial
Corporate Violence in Workplace
Crypto & Encryption - Part I
Crypto & Encryption - Part II
Crypto & Encryption - Part III
Disaster Recovery Planning
Downloads - - Public Domain
Downloads - Packet Storm
Downloads - Hacker Domain
Employment and Job Opportunities
Ethics Law and Security Policy
Firewalls
Frame Relay Tutorials
FreeBSD - Berkeley Unix Clone
FreeBSD - OnlineBooks to Read
General Security Related Links
Hacking - How its done Guides
Hacked Web Sites
Information Warfare
Internet Telephony & Protocols
Intrusion Detection Library
Investigations and Courtrooms
Java Security Resources
Jobs & Employment Opportunities
Legal Resources - Legal Basics
Linux Resources - Basics
Linux Resources - Online Books
Mailing List - For Newsletters
Magazine Articles - SEARCHER
Magazine Store - CheapPrices
Military & Govt Security Docs
Networking - Internet Protocols
Novell Networking Security
Online Courses -Boost Your Skills
Pager Hardware Reprogramming
Penetration Testing -Intrusions
Physical and Facility Security
Privacy & Anonymity on the Net
Programming Tutorials
Protocols - Networking - Internet
Resume and Interview Resources
Security Magazines Online
Security Reference Library I
Security Reference Library II
Security Policy Library
Security Standards & Guidelines
Smart Cards
Telecommunication & Internet
Telecommunications Tutorials
Threat Risk Assessments
Unix Security Resources
Unix Security Online Books
VPN's - Virtual Private Networks
Virus Worms Trojans Hoaxs
Voice / IP Protocols and Standards
WIN NT Assorted Files
WIN NT Security Files
WIN 2000 Operating System
Workplace Violence
Y2K Year 2000 Information


Network Protocol Bibliographies -  Protocol article references


There are approximately 200 complete or partial items listed in this listing.  80% of these links lead to the complete work and about 20% lead to identifying why you can locate the reference at your library or by using the Search Engines to hunt them down.   Unfortunately some of the more commercial web sites use the partial chapters as bait to lure you into buying the hard copy of the text - rather then putting the whole thing online and letting the consumer decide whether he/she prefers the free online version or if they wish to purchase a hard copy.

Another problem with maintaining this listing is that web sites live and die faster then fruit flies - so it is possible that links will be up one day and down the next. 

SEARCHING THIS LIST - use your browsers built in find feature

Iin order to best search this list for topics of your particular interest, use the built in feature of YOUR web browser to search the page for keywords.   On the IE Explorer the FIND feature is located in the EDIT options at the top of your browser.   On the Netscape browser you will find the FIND option also in the EDIT options at the top of your web browser.

Good luck... good hunting... and hopefully good reading !

Network Bibliography : Network Protocols

Steven Low, Nicholas F. Maxemchuk and Sanjoy Paul, "Anonymous Credit Cards," in submitted to 1994 IEEE Symposium on Research in Security and Privacy, (Oakland, California), 1994.

Abstract: This paper describes a novel technique for generating an anonymous credit card which combines the privacy of cash transactions with the security, record-keeping and charging mechanisms of credit cards. Using this scheme, and individual can make purchases without revealing his identity while a shop can sell items to an unknown individual without the fear of being cheated.

Keywords: electronic cash; anonymous credit cards; mercantile protocols

Steven Low, Nicholas F. Maxemchuk and Sanjoy Paul, "Collusion in a Multi-party Communications Protocol for Anonymous Credit Cards," submitted to IEEE/ACM Transactions on Networking, 1994.

Abstract: We proposed in [8] a novel scheme to implement an anonymous credit card that protects privacy while providing the security, record- keeping, and charging mechanism of conventional credit cards. The key idea is to use cryptographic techniques to allow two parties to commuincate without knowing each other. In this paper we present a formal method to study collusion in the multi-party communication protocol in [8]. Application of the method to our protocol leads to a simplified implementation of anonymous credit cards that is equally secure.

Keywords: electronic cash; anonymous credit cards; mercantile protocols

Alec F. Yasinsac and William A. Wulf, "Evaluating cryptographic protocols," Department of Computer Science, University of Virginia, Charlottesville, Virginia, no. CS-93-66, Dec. 1993.

Abstract: Cryptographic protocol (CP) analysis is a topic of intense research. Meadows describes four approaches to CP verification under investigation in (Meadows 1992) and several authors have categorized protocols based on types of errors they are subject to (Bird 1992, Syverson 1993). This paper addresses the weakness injected into protocols when information is passed in the clear or encrypted only under the private key of a public/private key pair. We also propose a method for logically analyzing protocols based on action list analysis of valid and compromised protocol runs interleaved with action lists of intruders conducting known attacks.

Keywords: cryptography; protocols; protocol verification

Dominique de Waleffe and Jean-Jacques Quisquater, "Better login protocols for computer networks," in Computer Security and Industrial Cryptography, Preneel, Bart and Govaerts, Ren\'e and Vandewalle, Joos, ed., Berlin, pp. 50--70, May 1991.

Abstract: Authenticating computer users is a fairly old problem. Password based solutions were acceptable until the growth of computer networks based on insecure communications. Today many systems still use fixed passwords as a means of authentication. We show in this paper how an old scheme by Lamport can be used to provide more security. Relying on that scheme and zero-knowledge techniques, we show extensions providing much more general access control mechanisms. Those extensions can be exploited in several ways: to authenticate users in computer networks, to provide users with access tickets or provide servers with proofs of usage. We also show how, in a single transaction, a user can prove this authenticity as well as prove his possession of a ticket. Finally, we explain how smart cards make those protocols very practical.

Keywords: security; authentication; access control; login; smart card

Johan van Tilburg, "Secret-key exchange with authentication," in Computer Security and Industrial Cryptography, Preneel, Bart and Govaerts, Ren\'e and Vandewalle, Joos, ed., Berlin, pp. 71--86, May 1991.

Abstract: This paper provides an outline for the second lecture on authentication protocols and deals with the secret-key exchange protocols. The object is to encourage the interested reader to obtain and study the original papers, and papers related to this subject.

Keywords: security; authentication; encryption; secret key; public-key; Diffie-Hellman; ElGamal; zero-knowledge

Bart De Decker, "Unix Security and Kerberos," in Computer Security and Industrial Cryptography, Preneel, Bart and Govaerts, Ren\'e and Vandewalle, Joos, ed., Berlin, pp. 257--274, May 1991.

Abstract: This paper discusses some security issues related to the UNIX operating system, which is today the de facto standard Operating System. The authentication mechanism has been focused on, both in a central system and in a networked environment. It is shown that networking makes UNIX vulnerable if no special measures are taken. One of these could be the introduction of the Kerberos authentication system which is also becoming a ``standard'' in open network environments. The Kerberos protocols are described, and their merits and limitations in a possibly hostile environment are discussed.

Keywords: security; Unix; operating systems; Kerberos; authentication; login

B. Abarbanel and S. Venkatachalam, "BGP-4 support for Traffic Engineering," Internet Engineering Task Force, Jun. 2000.

Abstract: Currently, constraint routing (CR) and traffic engineering (TE) models do not take into consideration the big picture view of IP traffic traversing multiple autonomous systems (AS). Most of the traffic and constraint routing is based on IGP protocols such as OSPF/ISIS, etc. The resulting view of the Internet is limited to one autonomous system and areas or systems within it. Hence, the routing/forwarding functions do not select the optimum path for packets that need to traverse several autonomous systems. The proposal in this draft is that the BGP protocol can be utilized to choose the best BGP routes based on traffic engineered (TE) constraint weights. This information can be propagated between all BGP peers and calculated by the BGP AS border routers before it is deployed to their forwarding tables.

J. Abela, "UTF-9, a transformation format of UCS," Internet Engineering Task Force, Dec. 1997.

Abstract: ISO/IEC 10646 defines a multi-octet character set called the Universal Character Set (UCS) which encompasses most of the world's writing systems. Multi-octet characters, however, are not compatible with many current applications and protocols, and this has led to the development of a few so-called UCS transformation formats (UTF), each with different characteristics. UTF-9, the object of this memo, has the characteristic of preserving the full ISO-Latin1 range, providing compatibility with file systems, parsers and other software that rely on ISO-Latin1 values. ISO-Latin1 is almost as widespread as ASCII in many countries, especially in most of western Europe, and is the default character set for HTML. A compatible encoding seems desirable, where possible.

B. Aboba, "IPSEC Remote Access Protocol Evaluation Criteria," Internet Engineering Task Force, Jul. 2000.

Abstract: This document describes criteria for evaluation of IPSEC Remote Access (IPSRA) protocols. In particular, this document focuses on criteria relevant to voluntary tunneling.

B. Aboba, "Extension for PPP Authentication," Internet Engineering Task Force, Nov. 1997.

Abstract: This document defines the ''PPP Authentication Operation'' for LDAP. This operation provides for PPP authentication in an LDAP association and is defined in terms of an LDAP extended operation. It is expected that this extended operation will be useful in inte- grating authentication protocols such as RADIUS and TACACS+ with LDAP- based directory services. Consolidation of information stores is desirable since it results in lessened administrative workload and a consistent view of user information throughout the enterprise.

B. Aboba, "PPP EAP GSS Authentication Protocol," Internet Engineering Task Force, Jul. 2000.

Abstract: The Extensible Authentication Protocol (EAP) provides a standard mechanism for support of additional authentication methods within layer 2 protocols, including PPP and IEEE 802. Through the use of EAP, support for a number of authentication schemes may be added, including public key, smart cards, Kerberos, One Time Passwords, and others.

C. Adams and J. Gilchrist, "The CAST-256 Encryption Algorithm," Internet Engineering Task Force, Feb. 1999.

Abstract: There is always a desire in the Internet community for unencumbered encryption algorithms with a range of key sizes that can provide security for a variety of cryptographic applications and protocols. This document describes an existing algorithm that can be used to satisfy this requirement. Included are a description of the cipher and the key scheduling algorithm, the s-boxes, and a set of test vectors (Appendix A).

C. Adams, "Alternative Certificate Formats for PKIX-CMP," Internet Engineering Task Force, Jul. 2000.

Abstract: The PKIX Certificate Management Protocols (PKIX-CMP) specification [1], while primarily focused on X.509v3 public-key certificates, allows the messages it defines to be used for the management of alternative certificate formats as well. This document specifies precisely how such formats may be incorporated into PKIX-CMP and provides the relevant syntax for some important certificate types.

C. Adams and R. Zuccherato, "Data Certification Server Protocols," Internet Engineering Task Force, Jun. 1998.

Abstract: This document describes a general data certification service and the protocols to be used when communicating with it. The Data Certification Server is a Trusted Third Party (TTP) that can be used as one component in building reliable non-repudiation services (see [ISONR]). Useful Data Certification Server responsibilities in a PKI are to validate signatures and to provide up-to-date information regarding the status of public key certificates. We give examples of how to use the Data Certification Server to extend the lifetime of a signature beyond key expiry or revocation and to query the Data Certification Server regarding the status of a public key certificate. The key words 'MUST', 'MUST NOT', 'REQUIRED', 'SHALL', 'SHALL NOT', 'SHOULD', 'SHOULD NOT', 'RECOMMENDED', 'MAY', and 'OPTIONAL' in this document are to be interpreted as described in RFC 2119 [RFC2119].

C. Adams and R. Zuccherato, "Notary Protocols," Internet Engineering Task Force, Feb. 1998.

Abstract: This document describes a general notary service and the protocols to be used when communicating with it. The Notary Authority is a Trusted Third Party (TTP) that can be used as one component in building reliable non-repudiation services (see [ISONR]). Useful Notary Authority responsibilities in a PKI are to validate signatures and to provide up- to-date information regarding the status of certificates. We give examples of how to use the notary to extend the lifetime of a signature beyond key expiry or revocation and to query the notary regarding the status of a certificate.

C. Adams, D. Pinkas, P. Cain and R. Zuccherato, "Time Stamp Protocols," Internet Engineering Task Force, Jun. 1998.

Abstract: This document describes the format of the data returned by a Time Stamp Authority and the protocols to be used when communicating with it. The time stamping service can be used as a Trusted Third Party (TTP) as one component in building reliable non-repudiation services (see [ISONR]). In order to reduce the amount of trust required of a TSA we introduce (in Appendix C) the optional Temporal Data Authority (TDA) whose function is to provide further corroborating evidence of the time contained in the token. We also give an example of how to place a signature at a particular point in time, from which the appropriate certificate status information (e.g. CRLs) may be checked.

C. Perkins and H. AFIFI, "Internet General Packet Radio Service (IGPRS); Service description," Internet Engineering Task Force, Jul. 2000.

Abstract: We propose an architecture (IGPRS) for the integration of the IPv6 protocol in the GPRS infrastructure. The data and signalling protocol suite will be based on mobile IPv6 protocol (instead of the GTP protocol). This new infrastructure will take advantage of the available internet protocols for routing and security. Since it is targetted to co-exist with the GPRS, it is a partial translation of MAP specifications to Internet protocols. This document uses some of the GPRS Service document and some of its terminology.

S. Ago, S. Moeenuddin and S. Hadvani, "NEC contribution on pre-Spirits ICW implementations," Internet Engineering Task Force, Feb. 2000.

Abstract: This document provides overview of a pre-SPIRITS Internet Call Waiting (ICW) implementation developed by NEC. The document describes the ICW service, the architecture, interface, and the protocols used in the ICW implementation. As such, this document contributes to the future SPIRITS architecture and protocol RFCs.

C. Akinlar, D. Braun and S. Mukherjee, "Multi-Router Zeroconf Network Requirements," Internet Engineering Task Force, Aug. 2000.

Abstract: Zero Configuration (Zeroconf) Networks are a particular class of TCP/IP networks that may be established in the home, in small offices or even for a variety of adhoc purposes. Zeroconf networks do not have and should not be expected to have user configurable network infrastructure such as DHCP, DNS and other administered network services. This is because typical zeroconf network users neither have the skill nor the desire to configure, administer or manage a network [1]. The IETF Zeroconf Requirements draft [1] presents the zeroconf protocol requirements for 4 areas: IP host configuration, domain name to IP address resolution, IP multicast address allocation, and service discovery. This draft builds on [1] and lists the zeroconf protocol requirements for IP router configuration and dynamic routing protocol in multi-router zeroconf networks. The IETF Zeroconf Requirements draft [1] presents the zeroconf protocol requirements for 4 areas: IP host configuration, domain name to IP address resolution, IP multicast address allocation, and service discovery. The most complex network topology addressed by the Zeroconf Requirements document [1] is a multi-segment zeroconf network connected by a single router. This drafts builds on that draft and lists the zeroconf protocol requirements for IP router configuration and dynamic routing protocols in multi-router zeroconf networks.

S. Ostermann and M. Allman, "FTP Extensions for Variable Protocol Specification," Internet Engineering Task Force, Aug. 1997.

Abstract: The specification for the File Transfer Protocol assumes that the underlying network protocols use a 32-bit network address and a 16-bit transport address (specifically IP version 4 and TCP). With the deployment of version 6 of the Internet Protocol, network addresses will no longer be 32-bits. This paper specifies extensions to FTP that will allow the protocol to work over a variety of network and transport protocols.

H. Alvestrand, "IETF Policy on Character Sets and Languages," Internet Engineering Task Force, Oct. 1997.

Abstract: The Internet is international. With the international Internet follows an absolute requirement to interchange data in a multiplicity of languages, which in turn utilize a bewildering number of characters. This document is (INTENDED TO BE) the current policies being applied by the Internet Engineering Steering Group towards the standardization efforts in the Internet Engineering Task Force in order to help Internet protocols fulfil these requirements. The document is very much based upon the recommendations of the IAB Character Set Workshop of February 29-March 1, 1996, which is documented in RFC 2130 [WR]. This document attempts to be concise, explicit and clear; people wanting more background are encouraged to read RFC 2130. The document uses the terms 'MUST', 'SHOULD' and 'MAY', and their negatives, in the way described in [RFC 2119]. In this case, 'the specification' as used by RFC 2119 refers to the processing of protocols being submitted to the IETF standards process.

C. Weider, T. Howes, C. Apple and M. Wahl, "A Minimum LDAPv3 White Pages Schema," Internet Engineering Task Force, Dec. 1997.

Abstract: Many different white pages schema proposals have been published for use in LDAPv3 as well as other directory service protocols. While these proposals define schema elements that are indeed useful in the deployment of LDAPv3-based directory services, there are a few problems common to the set of such proposals currently available to implementors: inconsistent semantic and syntactic definitions of similar attributes across schema, little or no semantic extensibility of attribute definitions without changing source code for deployed implementations, lack of standard object class definitions for containing white pages meta schema elements, and lack of an attribute grouping method. This document defines an object class for holding IWPS attributes as mapped into existing and relatively few newly defined extensible attribute types.

G. Armitage, "Security issues for ION protocols," Internet Engineering Task Force, Oct. 1997.

Abstract: This document aims to assist people attempting to understand the security limitations of existing ION working group protocols RFC 2022 (MARS), and RFC xxxx (NHRP). As RFC 2022 and RFC xxxx share their basic control message protocol(s), this document also identifies common areas amenable to improvement using additional security TLVs.

T. Arnold and J. Eaton, "Simple Commerce Messaging Protocol (SCMP)Version 1 Message Specification," Internet Engineering Task Force, Jun. 2000.

Abstract: The Simple Commerce Messaging Protocol (SCMP) is a general-purpose electronic commerce message protocol for secure, real-time communication of a set of data from a sending agent's application to a receiving agent's server. Additionally the response by the receiving agent's server to the sending agent is the reply from the request represented by the set of data in the message's payload. The intent of this protocol is to define a method where trading partners can perform on-line business requests in an environment where the sending partner is fully authenticated, and the message cannot be repudiated. The taxonomy of the SCMP message payload is not in the scope of this document. The SCMP protocol does not specify payload definitions or how trading partners are expected to process the payload, beyond basic server-level functions related to processing SCMP headers. This intent is to permit trading partners the flexibility to implement either a standard commerce message format as in ANSI-X12 Electronic Data Interchange (EDI) or some other non-standard payload format. This document does give an example implementation of a payload format based on [XML]. The only requirement on the message payload is that it be prepared as specified in [MIME]. In this manner, SCMP fundamentally differs from many emerging commerce message protocols. Beyond specifying the method for encryption, authentication and handling, these other protocols specify the contents of the message and details how a server is to process and respond to a given message payload.

A. Arsenault and S. Farrell, "Securely Available Credentials - Requirements," Internet Engineering Task Force, Sep. 2000.

Abstract: This document describes requirements to be placed on Securely Available Credentials (sacred) protocols. This is the initial draft of the sacred requirements specification and is therefore highly likely to change substantially. Discussion of this draft is taking place on the sacred list (see http://www.imc.org/ietf-sacred for subscription information).

S. Ayandeh and Y. Fan, "MPLS Routing Dynamics," Internet Engineering Task Force, Mar. 1998.

Abstract: This Internet draft outlines how transients in protocols such as OSPF [7] (intra-domain routing) and MPLS LDP [2] can lead to periods of time with loops and other undesirable routing phenomenon. It defines a set of metrics to quantify this dynamic behavior. Quantification of these metrics, using a simulation model, for various local vs. egress label allocation schemes is used as the basis of a comparative analysis. This includes quantifying any incremental impact that MPLS may have once it is introduced into an autonomous IP routing area. The resulting insights would help develop a better understanding of routing dynamics. This includes identifying key nodal and network variables which impact routing dynamics hence guiding MPLS feature selection and IP network design.

M. Bakke and J. Muchow, "Definitions of Managed Objects for SCSI over TCP," Internet Engineering Task Force, Aug. 2000.

Abstract: 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 a client using the SCS over TCP (aka iSCSI) protocol.

S. Bakker, "AAA Considerations for Middleware," Internet Engineering Task Force, Jun. 1999.

Abstract: The IETF AAA Working Group is currently looking at defining the requirements for Authentication, Authorization and Accounting. Various documents have already been written that outline AAA requirements for various services and protocols. This document falls into that category, as it outlines some ideas for middleware that have specific AAA requirements.

T. Nishida and A. Bakre, "IP Multicast over ATM Networks with Cut-through Forwarding for Inter LIS Traffic," Internet Engineering Task Force, Dec. 1997.

Abstract: This document proposes a scheme for IP multicasting in ATM networks, which can achieve cut-through forwarding for inter LIS multicast traffic using ATM protocols.

O. Aboul-Magd and others, "Signaling Requirements at the Optical UNI," Internet Engineering Task Force, Jul. 2000.

Abstract: This draft considers the optical network service model referred to as the 'domain services' model [1]. Under this model, the optical network provides a set of well-defined services to clients (IP and others). The signaling and routing interface between the client and optical networks is referred to as the User-Network Interface (UNI). This draft describes the services provided over the UNI, and the requirements on any signaling protocol used to invoke the services. This draft reflects ongoing work at the Optical Interworking Forum (OIF) and the Optical Domain Service Interconnect (ODSI) coalition on the optical UNI [2]. The relevance of this draft to the IETF is two-fold. First, for the signaling portion of the optical UNI, extensions of two MPLS signaling protocols are presently under consideration in the OIF: RSVP with TE extensions and LDP. The objective of this draft is to guide the adaptation of these protocols for UNI signaling. Second, to harmonize the signaling of UNI originated lightpath requests and peer model lightpath establishment mechanisms [1], alignment between OIF, ODSI and IETF lightpath parameters and signaling functionality is desirable. This draft aims to serve this purpose. The content of this draft is expected to evolve as work progresses on the optical UNI.

H. Balakrishnan and S. Seshan, "The Congestion Manager," Internet Engineering Task Force, Mar. 2000.

Abstract: This document describes the Congestion Manager (CM), an end-system module that (i) enables an ensemble of multiple concurrent flows from a sender destined to the same receiver and sharing the same congestion properties to perform proper congestion avoidance and control, and (ii) allows applications to easily adapt to network congestion. This CM framework integrates congestion management across all applications and transport protocols. The CM maintains congestion parameters (available aggregate and per-flow bandwidth, per-receiver round-trip times, etc.) and exports an API that enables applications to learn about network characteristics, pass information to the CM, share congestion information with each other, and schedule data transmissions. This document focuses on applications and transport protocols with their own independent per-byte or per-packet sequence number information, and does not require modifications to the receiver protocol stack. The receiving application must provide feedback to the sending application about received packets and losses, and the latter uses the CM API to update CM state. This document does not address networks with reservations or service discrimination.

B. Baldwin, A. Wilson, S. Nishimura and M. Yurovitsky, "BSAFE CRYPTOGRAPHIC SECURITY COMPONENTS," Internet Engineering Task Force, May 1999.

Abstract: This Internet-Draft describes protocols, procedures, and conventions to be employed by peers implementing a generic cryptographic application program interface. Version 4.0 of this API was implemented inside RSA Data Security, Inc.'s BSAFE product. The API provides a model for implementing symmetric ciphers, message digests, message authentication, random number generation, public-key algorithms, digital signatures, and secret sharing. The API is documented here for the benefit of others who might also adopt and use the API, thus providing increased portability of security applications.

A. Banerjea, M. Faloutsos and R. Pankaj, "Designing QoSMIC: A Quality of Service sensitive Multicast Internet protoCol," online Internet Engineering Task Force, May 1998.

Abstract: We present, QoSMIC, a multicast protocol for the Internet that supports QoS-sensitive routing, and minimizes the importance of a priori configuration decisions (such as core selection). The protocol is resource-efficient, robust, flexible, and scalable. In addition, our protocol is provably loop-free. Our protocol starts with a resources-saving tree (Shared Tree) and individual receivers switch to a QoS-competitive tree (Source-Based Tree) when necessary. In both trees, the new destination is able to choose the most promising among several paths. An innovation is that we use dynamic routing information without relying on a link state exchange protocol to provide it. Our protocol limits the effect of pre- configuration decisions drastically, by separating the management from the data transfer functions; administrative routers are not necessarily part of the tree. This separation increases the robustness, and flexibility of the protocol. Furthermore, QoSMIC is able to adapt dynamically to the conditions of the network. The QoSMIC protocol introduces several new ideas that make it more flexible than other protocols proposed to date. In fact, many of the other protocols, (such as YAM, PIM-SM, BGMP, CBT) can be seen as special cases of QoSMIC. The goal of this document is to present the motivation behind, and the design of QoSMIC, and to provide both analytical and experimental results to support our claims. NOTE: The text version of the draft is missing several figures, that facilitate the understanding of the work. For this, the authors suggest the postscript version.

D. Basak, D. Awduche, J. Drake and Y. Rekhter, "Multi-protocol Lambda Switching: Issues in Combining MPLS Traffic Engineering Control With Optical Cross-connects," Internet Engineering Task Force, Feb. 2000.

Abstract: This document describes the domain specific enhancements required to adapt MPLS traffic engineering control plane constructs to control optical cross-connects in emerging automatically switched optical transport networks. These enhancements are within the framework of Multiprotocol LAMBDA switching proposed in [1]. Specifically, this memo investigates the behavior of the MPLS based control plane technique for OXCs, and identifies required enhancements to both OXCs and to existing MPLS traffic engineering control plane objects (routing and signaling protocols) to support the application to OXCs.

J. Beck, "ResCap Requirements," Internet Engineering Task Force, Jun. 1999.

Abstract: A variety of resource identifiers have been widely deployed on the Internet as a means of identifying various resources, services, and destinations. However, a means of attaching a set of attributes or characteristics to a given resource identifier and subsequently assessing those attributes or characteristics has not been specified and deployed. A particularly important resolution service of this general type is one which, when given a mail address identifying a particular mail recipient, will return a series of attributes describing the capabilities of that recipient. This differs from a directory service in that no searching or other advanced query operations are involved. Two tasks are envisioned. The first task will be to define a general resolution protocol that will translate resource identifiers to a list of attributes. The second task will be to define an administrative model and update protocol that can be used to set up and maintain the information the resolution protocol accesses. This document defines the requirements for these two protocols.

K. McCloghrie, P. Langille, A. Rijsinghani, A. Smith and L. Bell, "Definitions of Managed Objects for Bridges with Traffic Classes, Multicast Filtering and Virtual LAN Extensions," Internet Engineering Task Force, Mar. 1998.

Abstract: 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 MAC bridges based on the IEEE 802.1D-1998 MAC Bridges and IEEE 802.1Q-1998 Virtual LAN (VLAN) standards for bridging between Local Area Network (LAN) segments. Provisions are made for support of transparent bridging. Provisions are also made so that these objects apply to bridges connected by subnetworks other than LAN segments. This memo also includes several MIB modules in a manner that is compliant to the SNMP SMI [3].

B. Bell, "IPDC Device Management Protocol," Internet Engineering Task Force, Aug. 1998.

Abstract: The protocol described in this document is a member of the IP Device Control (IPDC) family of protocols. The IPDC protocols are proposed as a protocol suite, components of which can be used individually or together to perform connection control, media control, and signaling transport for environments where the service control logic is separated from the network access server. Please see the references section for other IPDC documents. The protocol specification presented here is intended for use between a media gateway controller and a media gateway. The media gateway may be capable of acting as a voice over IP gateway, voice over ATM gateway, dialup modem media gateway, circuit switch, or cross- connect. Using the IP Device Signaling Transport protocol presented here, the media gateway can receive a signaling from a circuit switched network and deliver the signaling to a media gateway controller on an intervening IP network. The media gateway controller can also send signaling to a media gateway for delivery on a circuit switched network.

S. Bellovin and R. Moskowitz, "Client Certificate and Key Retrieval for IKE," Internet Engineering Task Force, Feb. 2000.

Abstract: (Insert justification, possibly copied wholesale from section 1.1 and maybe 2.1/2.2 of draft-kelly-ipsra-userauth-00.txt) We consider inadvisable to change IKE [RFC2409] to meet these needs. IKE is a complex protocol; adding more features to it is a bad idea. Instead, we propose a layered approach: use standard IKE, with certificates, but provide a simple mechanism to provide clients with keys and certificates. A number of objections have been raised to using certificates. The most important is that we lack a public key infrastructure (PKI). We do not agree that this is an obstacle. Our proposal provides a simple mechanism for certificate generation and retrieval, while still relying on legacy authentication infrastructures. Furthermore, we provide for an easy migration path to certificate use once organizational PKIs are deployed. Our purpose at this point is not to present a firm protocol. Rather, we sketch several ideas for what such a protocol could look like. Final details can be determined if and when the working group opts for this path. In the interests of simplicity, we have chosen to reuse standard protocols and components. In particular, we use HTTP [RFC2616] for transport, HTML [RFC1866] as a data representation and TLS [RFC2246] for confidentiality. However, we do not mandate (or even necessarily encourage) use of a actual Web browser for certificate retrieval. As an alternative, we present a transient shared secret generation mechanism for IKE.

L. Berger and J. Jeffords, "MPLS/IP Header Compression over PPP," Internet Engineering Task Force, Mar. 2000.

Abstract: This document describes an option for negotiating the use of MPLS and IP header compression over the Point-to-Point Protocol [STD51]. It defines extensions to the PPP Control Protocol for MPLS [LABELS]. It is based on, and borrows heavily from, IP Header Compression over PPP [RFC2509]. MPLS/IP header compression is defined in [CMPLS] and may be applied to MPLS datagrams transporting IPv4 and IPv6 datagrams in combination with TCP, UDP and RTP transport protocols

L. Berger and T. O'Malley, "RSVP Extensions for IPSEC Data Flows," Internet Engineering Task Force, Aug. 1997.

Abstract: This document presents extensions to Version 1 of RSVP. These extensions permit support of individual data flows using RFC 1826 IP Authentication Header (AH) or RFC 1827 IP Encapsulating Security Payload (ESP). RSVP Version 1 as currently specified can support the IPSEC protocols, but only on a per address, per protocol basis not on a per flow basis. The presented extensions can be used with both IPv4 and IPv6.

Y. Bernet, D. Durham and F. Reichmeyer, "Requirements of Diff-serv Boundary Routers," Internet Engineering Task Force, Nov. 1998.

Abstract: This draft discusses requirements of routers that serve as ingress/egress points to/from differentiated services (diff-serv) networks. We discuss the traffic conditioning components required and associated configuration mechanisms and protocols. We also discuss admission control to diff-serv networks in support of signaled QoS.

G. Bernstein and V. Sharma, "Some Comments on GMPLS and Optical Technologies," Internet Engineering Task Force, Nov. 2000.

Abstract: GMPLS [2] is being considered as an extension to the MPLS framework to include optical, non-packet switched technologies. This draft reviews the motivation for doing so from an end-userĘs perspective and points out some key requirements/impacts that this will have on the extensions to the routing and label distribution/signaling protocols.

B. Beser, "Codec Capabilities Attribute for SDP," Internet Engineering Task Force, Mar. 2000.

Abstract: The need for assured communication arisen protocols like RSVP [2] and SBM [3] which are linked to access technologies to guarantee the delay and drop probabilities of a given IP flow. One of the side-effects of the assurance is that when the bandwidth of the IP flow goes outside the contracted region then the IP flow will be disturbed and the communication will be effected. This document discusses the effects of assured communication to SDP protocol, identifies the weaknesses and proposes a new attribute to rectify these weaknesses.

S. Bhattacharyya and others, "A Framework for Source-Specific IP Multicast Deployment," Internet Engineering Task Force, Jul. 2000.

Abstract: This document provides an overview of the Source-Specific Multicast (SSM) service model which supports source-based multicast trees across multiple domains in the Internet. SSM realizes components of the EXPRESS [HOLB99] multicast service model in which there is a single source for every multicast channel, and channel membership is based on the unique combination of multicast group address (G) as well as the source's unicast address (S). End-hosts use version 3 of the IGMP protocol (IGMPv3) to register their interest in a particular source-group (S,G) pair. The PIM-SM protocol is then used to construct the multicast forwarding tree rooted at the source S. This document is intended as a starting point for implementing and deploying SSM services. It provides a brief architectural overview of SSM described in more detail in [HOLBOO] and describes associated deployment challenges. It summarizes changes to protocols and applications both at end-hosts and routers, with pointers to more detailed documents, wherever appropriate. Issues of interoperability with the current multicast architecture are also discussed.

A. Bierman, "Remote Monitoring MIB Extensions for Differentiated Services Enabled Networks," Internet Engineering Task Force, Jun. 1999.

Abstract: This memo defines an experimental 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 monitoring Differentiated Services Codepoint usage in IP packets, utilizing the monitoring framework defined in the RMON-2 MIB [RFC2021].

K. McCloghrie and A. Bierman, "Entity MIB Extesions for Persistent Component Identification," Internet Engineering Task Force, Aug. 1997.

Abstract: This memo defines an experimental 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 physical topology identification and discovery.

A. Bierman, "Application Performance Measurement Capabilities MIB," Internet Engineering Task Force, Mar. 2000.

Abstract: 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 classifying and characterizing the application performance measurement (APM) capabilities of various standard and proprietary APM techniques.

A. Bierman, "Remote Monitoring MIB Extensions for Virtual Data Sources," Internet Engineering Task Force, Jul. 2000.

Abstract: 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 defining virtual data monitoring sources for use with existing RMON MIBs.

M. Blaze, J. Feigenbaum, J. Ioannidis and A. Keromytis, "The KeyNote Trust-Management System," Internet Engineering Task Force, Apr. 1999.

Abstract: this memo describes version 2 of the KeyNote trust-management system. It specifies the syntax and semantics of KeyNote `assertions,' describes `action attribute' processing, and outlines the application architecture into which a KeyNote implementation can be fit. The KeyNote architecture and language are useful as building blocks for the trust management aspects of a variety of Internet protocols and services.

M. Borella, D. Grabelsky, I. Sidhu and B. Petry, "Distributed Network Address Translation," Internet Engineering Task Force, Oct. 1998.

Abstract: NAT (Network Address Translation) has been proposed to extend the lifetime of IPv4 by allowing one or more subnets to exist behind a single IP address. It is desirable to support dozens, if not hundreds, of nodes on a NAT subnet. As it is currently defined, NAT may not gracefully scale beyond networks containing a few dozen nodes. In particular, the computational burden placed on the NAT router may be significant, especially if the router is shared by several NAT-enabled subnets. Additionally, NAT requires that support for many protocols be specifically programmed into the translation mechanism. In this document, we introduce DNAT (Distributed Network Address Translation), an alternative to NAT. In particular, DNAT will eliminate all address and port translation at the router, providing an application independent mechanism for sharing an IP address amongst many hosts while providing end-to-end connectivity.

C. Bormann, "Network News Distribution Protocol: Architecture and Design Guidelines," Internet Engineering Task Force, Mar. 1998.

Abstract: This document describes an architecture and a set of protocols for distributing Netnews [RFC0977, RFC1036] via IP multicast enabled networks. The architecture is designed to be useful in the global Internet. In particular, it allows multiple news servers to cooperate on multicasting each new article only once. To facilitate scalability to tens of thousands of news servers, it also provides for receive-only multicast participants (that continue to send articles via conventional NNTP). This document is a submission to the IETF MNNP working group. Comments are solicited and should be addressed to the working groups' mailing list at ietf-mnnp@va.pubnix.com and/or the author.}

C. Bormann, J. Ott and N. Seifert, "MTP/SO: Self-Organizing Multicast," Internet Engineering Task Force, Jul. 1999.

Abstract: MTP/SO is a reliable multicast protocol based on the earlier protocols MTP (RFC1301) and MTP-2, simplifying the protocol considerably while adding self-organization of the members of the group into a hierarchy of local regions, local retransmissions, local NAK damping, and both global and local forward error correction. MTP/SO retains the coordinated many-to-many multicast model of MTP-2 while improving scalability.

J. Bouwen, B. Van Doorselaer and M. Dekeyser, "Issues for Megaco - Sigtran Interworking in ISDN Access Gateways," Internet Engineering Task Force, Jul. 2000.

Abstract: This document introduces the concept of an ISDN access gateway in the context of Megaco/H.248 and Sigtran protocols. For these ISDN access gateways, the ISDN B channels may be controlled by the Media Gateway Controller using megaco/H.248 while the User-to-Network signaling running over the D channels may be relayed to the Media Gateway Controller using either megaco/H.248 or the Sigtran protocols. The main issues involved are: * Megaco/H.248 and Sigtran protocols may interwork in different ways in ISDN access gateways, leaving room for non - interoperable solutions; * Megaco needs additional packages in order to support ISDN terminations in the ISDN access gateway; * A data service may be offered to ISDN users via the ISDN D- channel, introducing the need to introduce a NAS package for the D-channel. This document addresses these issues, proposes and explains different solutions and suggests best practice guideline for megaco / sigtran interworking in ISDN access gateways.

S. Bradner, "OSI connectionless transport services on top of UDP Applicability Statement for Historic Status," Internet Engineering Task Force, Jan. 1999.

Abstract: RFC 1240, 'OSI connectionless transport services on top of UDP', was published as a Proposed Standard in June 1991 but at this time there do not seem to be any implementations which follow RFC 1240. In addition there is a growing concern over using UDP-based transport protocols in environments where congestion is a possibility.

A. Farrel, P. Brittain and P. Matthews, "Fault Tolerance for LDP and CR-LDP," Internet Engineering Task Force, Jul. 2000.

Abstract: MPLS systems will be used in core networks where system downtime must be kept to an absolute minimum. Many MPLS LSRs may, therefore, exploit fault tolerant (FT) hardware or software to provide high availability of the core networks. The details of how FT is achieved for the various components of an FT LSR, including LDP, CR-LDP, the switching hardware and TCP, are implementation specific. This document identifies issues in the CR-LDP specification [2] and the LDP specification [4] that make it difficult to implement an FT LSR using the current LDP and CR-LDP protocols, and proposes enhancements to the LDP specification to ease such FT LSR implementations. The extensions described here are equally applicable to CR-LDP.

N. Brown and C. Kindel, "Distributed Component Object Model Protocol -- DCOM/1.0," Internet Engineering Task Force, Mar. 1998.

Abstract: The Distributed Component Object Model protocol is an application-level protocol for object-oriented remote procedure calls useful for distributed, component-based systems of all types. It is a generic protocol layered on the distributed computing environment (DCE) RPC specification and facilitates the construction of task-specific communication protocols through features such as: a platform neutral argument/parameter marshaling format (NDR), the ability for objects to support multiple interfaces with a safe, interface- level versioning scheme suited to independent evolution by multiple parties, the ability to make authenticated connections and to choose levels of channel security, and a transport-neutral data representation for references (including by-value) to objects.

A. Brusilovsky, E. Gausmann, V. Gurbani and A. Jain, "A Proposal for Internet Call Waiting Service using SIP An Implementation Report," Internet Engineering Task Force, Jan. 1999.

Abstract: The purpose of this Internet Draft is to start discussion on the issues involved in Internet Call Waiting Service (ICW), as part of interconnecting IP and Global Switched Telephone Network (GSTN) with the intent of providing ICW service that is much needed by numerous dial-up Internet users. Interworking of the IP network and GSTN, based on open well-defined protocols, will promote interoperability of both the networks and systems built by different vendors. This Internet Draft is submitted with the goal of becoming an informational RFC. The rest of this document is as follows: Section 2 briefly describes the services offered to the end Subscriber. It is the support of these services that necessitates the proposed internetworking project. Section 3 describes the scope of the proposed project by introducing its overall architecture, identifying the interfaces to be standardized, describing experience with SIP for ICW. Sections 4, 5, and 6 respectively address security considerations, supply references, and provide the authors address, as required by [1]. Section 7 acknowledges individuals providing assistance in the creation of this document. Section 8 is the Appendix, which contains IN Tutorial and Figure A.

A. Brusilovsky, V. Gurbani, A. Jain and D. Varney, "Need for PSTN Internet Notification (PIN) ServiceA Proposal for a new Working Groups," Internet Engineering Task Force, Feb. 1999.

Abstract: The purpose of this Internet Draft is to start discussion on the issues involved in PSTN Internet Notification (PIN), as part of interconnecting IP and Public Switched Telephone Network (PSTN) with the intent of converging existing and creating new hybrid PSTN and IP services. PSTN Events Notification, based on open well-defined protocols, will promote interoperability of both the networks and systems built by different vendors. This Internet Draft is submitted with the goal of becoming an informational RFC. The rest of this document is as follows: Section 2 briefly describes the PIN services. Section 3 describes the scope of the proposed project by introducing its overall architecture and identifying the interfaces to be standardized. Sections 4, 5, and 6 respectively address security considerations, supply references, and provide the authors address, as required by [1]. Section 7 acknowledges individuals providing assistance in the creation of this document.

A. Brusilovsky, J. Buller, L. Conroy, V. Gurbani and L. Slutsman, "PSTN Internet Notification (PIN) Architecture, Services and Protocols (A Provisional Framework)," Internet Engineering Task Force, Jun. 1999.

Abstract: The purpose of this Internet Draft is to continue discussion on the issues involved in PSTN Internet Notification (PIN), as part of interconnecting IP and Public Switched Telephone Network (PSTN) with the intent of converging existing and creating new hybrid PSTN and IP services. PSTN initiated Service Requests, based on open well-defined protocols, will promote interoperability of both the networks and systems built by different vendors. This Internet Draft is submitted with the goal of becoming an Informational RFC.

b. Buffam, B. Thompson and T. Koren, "IP/UDP/RTP Header Compression over AAL2," Internet Engineering Task Force, Jul. 2000.

Abstract: This document describes a method to carry compressed and uncompressed traffic over AAL2. This proposal uses AAL2 frame mode SSCS to carry uncompressed protocols directly. The proposal also includes a new SSCS for carriage of compressed protocols over AAL2 frame mode to improve the bandwidth efficiency of RTP streams over an ATM network using compression and multiplexing. This proposal advocates the use of compressed RTP and multiplexing over ATM Adaptation Layer Type 2 (AAL2) frame mode. RTP traffic is first compressed, the resulting CRTP stream is then processed by the AAL2 CRTP Service Specific Convergence Sub-layer (AAL2 CRTP SSCS), to be multiplexed onto an AAL2 CPS-PDU frame mode stream. The resulting multiplexed stream is carried end-to-end through an ATM network and then mapped in reverse back into CRTP at the far end to be presented to the upper layer IP/UDP/RTP protocol stack.

H. Basilier, P. Calhoun, M. Holdrege, T. Johansson and J. Kempf, "AAA Requirements for IP Telephony/Multimedia," Internet Engineering Task Force, Jul. 2000.

Abstract: The AAA Working Group has been defining requirements for Network Access in an Inter-Domain (roaming) network, both Mobile IP and NASREQ. Some of these requirements were input from work done in the 3rd Generation wireless SDOs. These same SDO's have a need to tie their IP Intelligent Servers (e.g. Softswitches, Call Agents, SIP Servers, etc.) to their AAA infrastructure. This specification defines some requirements for both the AAA and IP Telephony protocols (SIP, MEGACO, etc.) This first Internet Draft is intended to simulate discussions within the SIP Working Group, in order to come up with a set of requirements that could then be used to begin protocol design.

M. Calsyn, L. Dusseault and G. Mohr, "RVP: A Presence Notification Protocol," Internet Engineering Task Force, Mar. 1998.

Abstract: A new kind of application is emerging on the Internet, driven by the desire of individuals to know instantly whether another individual is online, to be notified when another individual arrives online, and to send messages in \021real time\022. These are all special cases of the more general problem of Internet-wide notification. This protocol for facilitating rendezvous between users, known herein as RVP, is designed to enable such notifications and messages across a loosely coupled (federated) constellation of servers. RVP is designed to address the need for notification in a secure, reliable and scaleable fashion. RVP encompasses the client-server and server-server interactions. The authors recognize that there is significant overlap with between RVP and HTTP, though there are also significant differences. We expect RVP to evolve and either converge or diverge with HTTP and/or other existing protocols. The protocol described in this document represents a very viable starting point for a discussion of a standardized solution to the problem. Comments on this draft are solicited and should be sent to the authors or the RVP discussion list. To join the RVP discussion list, send email with the body 'subscribe' to rvp- request@iastate.edu

G. Camarillo and A. Roach, "Best Current Practice for ISUP to SIP mapping," Internet Engineering Task Force, Mar. 2000.

Abstract: This document describes a way to perform the mapping between two signalling protocols: SIP and ISUP.

K. Carlberg and I. Brown, "Framework for Supporting IEPS in IP Telephony," Internet Engineering Task Force, Nov. 2000.

Abstract: This document presents a framework for supporting authorized emergency-related communication within the context of IP telephony. We present a series of objectives that reflect a general view of how authorized emergency service, in line with International Emergency Preparedness Scheme (IEPS), should be realized within today's IP architecture and service models. From these objectives, we present a corresponding set of functional requirements, which provide a more specific set of recommendations regarding existing IETF protocols. Finally, we present two scenarios that act as guiding models for the objectives and functions listed in this document. These, models, coupled with an example of an existing service in the PSTN, contribute to a constrained solution space.

A. Casati and C. Perkins, "Generic Tunneling Protocol (GTP)," Internet Engineering Task Force, Mar. 2000.

Abstract: Some discussion has been lately going on on the standardization of GRE within the IETF. GRE has an Impact on standard track protocols such as Mobile IP. A Generic Tunneling Protocol (GTP) sharing the same format and byte order of the 3GPP GTP protocol ( 3G TS 29.060) benefits from the commonality of the encapsulation format used in IP mobility support protocols in different families of 3G standards.

D. Chadwick, "Internet X.509 Public Key Infrastructure Operational Protocols - LDAPv3," Internet Engineering Task Force, Jun. 1999.

Abstract: This document describes the features of the Lightweight Directory Access Protocol v3 that are needed in order to support a public key infrastructure based on X.509 certificates and CRLs.

S. Chisholm, "Alarm MIB," Internet Engineering Task Force, Oct. 2000.

Abstract: This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes management objects used for maintaining a list of alarms currently active on a network element.

S. Christey, "The Infinite Monkey Protocol Suite (IMPS)," Internet Engineering Task Force, Mar. 2000.

Abstract: This draft describes a protocol suite which supports an infinite number of monkeys that sit at an infinite number of typewriters in order to determine when they have either produced the entire works of William Shakespeare or a good television show. The suite includes communications and control protocols for monkeys and the organizations that interact with them.

P. Cordell, "Conversational Multimedia URLs," Internet Engineering Task Force, Dec. 1997.

Abstract: The evolving technologies for real-time conversation over the Internet require URLs to provide user contact information. As there are many protocols (including some that are not Internet based) that can be used for inter-user conversation, this document describes a two stage transaction process for obtaining a URL that can be used to initiate conversation. The first stage involves retrieving a list of protocol specific URLs in a MIME encoded file. The MIME type enables an appropriate application to be launched which will analyse the presented URLs and select the most appropriate one. The second stage involves interpreting the protocol specific URL and initiating the conversation. The protocol specific URLs are encoded in a URL form so that they can be embedded directly into HTML pages. This allows the first stage to be omitted. The document describes the format of the MIME encoded list of URLs, and the format of a number of protocol specific URLs.

D. Cromwell and M. Durling, "Requirements For Control Of A Media Services Function," Internet Engineering Task Force, Nov. 1998.

Abstract: This document describes the functional requirements for protocol used by a call processing agent in a packet network to control an media services function located in the same packet network or at the inter- face of the packet network and the traditional telephone network. The primary focus of the protocol is on audio, however the protocol could be extended in the future to support other media streams such as video. The protocol provides the standard audio operations of play audio, collect DTMF, and record speech. It supports direct references to simple audio as well as indirect references to simple and complex audio. It provides multi-language audio variables, interruptibility of audio, digit buffer control, special key sequences, and support for reprompting during data collection. The approach used in specifying protocol functionality was to look at several existing protocols currently in use in the telephone network, taking the best concepts from each and attempting to avoid any limi- tations. The following protocols were examined: ITU CS1-R [2], Nor- tel Extended CS1-R [3], Bellcore GR-1129 [4], and Bellcore SR-3511 [5]. The protocol described in this document provides at a minimum a superset of the functionality of these protocols.

J. Crowcroft, H. Fuchs, T. Turletti, A. Ghosh, Z. Wang, L. Vicisano and C. Diot, "RMFP: A Reliable Multicast Framing Protocol," Internet Engineering Task Force, Mar. 1998.

Abstract: There has been considerable interest in reliable multicast, and a number of reliable multicast transport applications and systems have been built in the past years, e.g. [PGM], [RMDP], [RMTP], [SRM]. A survey of most of current reliable multicast protocols is available in [Diot97].

J. Crowcroft, "RTCP location reports," Internet Engineering Task Force, Feb. 1999.

Abstract: This note is a proposal to add lat/long data to RTCP reports to enable transport protocols, and applications to carry out a number of useful tasks.

C. Sapuntzakis and D. Cheriton, "TCP RDMA option," Internet Engineering Task Force, Feb. 2000.

Abstract: The TCP option introduced in this draft reduces the overhead of receiving data with TCP-based protocols such as NFS and HTTP. It enables the construction of a simple hardware accelerator that copies data directly from the incoming packet into application buffers, avoiding expensive copies in the protocol stack. Even without hardware acceleration, the option enables the protocol stack to decrease the number of copies it must do.

J. Cucchiara, J. Luciani and H. Sjostrand, "Definitions of Managed Objects for the Multiprotocol Label Switching, Label Distribution Protocol (LDP)," Internet Engineering Task Force, Aug. 1998.

Abstract: This memo defines an experimental portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes managed objects for the Multiprotocol Label Switching, Label Distribution Protocol (LDP) as defined in [17]. This memo does not specify a standard for the Internet community.

L. Daigle and R. Hedberg, "Technical Infrastructure for Swedish Directory Access Gateways (TISDAG)," Internet Engineering Task Force, Jun. 2000.

Abstract: The strength of the TISDAG project's DAG proposal is that it defines the necessary technical infrastructure to provide a single-access-point service for information on Swedish Internet users. The resulting service will provide uniform access for all information - the same level of access to information (7x24 service), and the same information made available, irrespective of the service provider responsible for maintaining that information, their directory service protocols, or the end- user's client access protocol.

M. Daniele, "IANA Address MIB," Internet Engineering Task Force, Sep. 1998.

Abstract: This document contains an initial version of a MIB module for commonly used network addressing information. It defines a registry for identifiers that identify protocols and a set of textual conventions for representing addresses. This document also establishes IANA as the maintainer of this registry.

M. Day and D. Gilletti, "Content Distribution Network Peering Scenarios," Internet Engineering Task Force, Nov. 2000.

Abstract: This document sets forth several logical and detailed scenarios to be considered when evaluating systems and protocols for CDN peering.

M. Day, "''HTTP Envy'' and Presence Information Protocols," Internet Engineering Task Force, Mar. 1998.

Abstract: There are a variety of proposals [Calsyn, Mohr] for building a presence information protocol as a variant or version of HTTP. This document summarizes why I believe that is not a good idea.

T. Hasting, F. Wright, H. Lewis, S. Isaacson, R. deBry, C. Kugler and S. Gebert, "The Use of Post: A Response to draft-cohen-http-postal-00.txt," Internet Engineering Task Force, Feb. 1998.

Abstract: A recent Internet Draft [1] argues that the common use of POST to proide a uniform method of passing blocks of data to an application, is being misused in the definition of new application protocols, such as the Internet Printing Protocol. Cohen et. al. argue that a new PUSH method be defined for this purpose. This Internet Draft argues that the existing POST method proides all of the required functionality for back end applications, such as Print, without sacrificing the leels of security that customers expect. More importantly, from the customer\022s point of iew, it does this without any impact to existing, installed network components.

N. Demizu, H. Esaki, K. Nagami and P. Doolan, "Virtual Connection Identifier," Internet Engineering Task Force, Oct. 1997.

Abstract: Several label switching schemes have been proposed to fuse and integrate the cost-performance and QoS assurance of Layer 2 devices and the flexibility and functionality of Layer 3 protocols. Some of these proposals assume that Label Switching Routers (LSRs) are placed in a homogeneous LSR cloud in a campus area network or a backbone network, and they are connected directly to each other. However, this assumption sometimes does not hold true in the real situation. For example, some campuses will be connected via ATM SVC service, and LSR networks will be constructed hierarchically. To deal with Virtual Connections (VCs) in these environments, this document proposes to identify a VC with a VCID instead of a label.

N. Demizu and H. Izumiyama, "Dynamic Tunnel Configuration Protocol," Internet Engineering Task Force, Dec. 1997.

Abstract: As the Internet grows, the importance of Uni-Directional Links such as satellite links has been increasing. However, most of existing routing protocols assume that datalinks are bi-directional. To incorporate UDLs into the Internet, an IP tunneling approach has been proposed, where tunnels are set up as a virtual back-channel of a UDL to carry routing information between Feeders and Receivers. Dynamic Tunnel Configuration Protocol (DTCP) supports to setup tunnels dynamically between Feeders and Receivers in such environments.

S. Dharanikota and S. Venkatachalam, "OSPF, IS-IS, RSVP, CR-LDP Extensions to Support inter-Area Traffic Engineering Using MPLS TE," Internet Engineering Task Force, Nov. 2000.

Abstract: In this draft, we propose the extensions required to the routing protocols, signaling protocols, and the MIB to support the idea of inter-area LSPs. A companion document [INTER_AREA_FWK] provides the architectural requirements for such a concept. This document also provides the signaling extensions to support the crankback as defined in the architecture document [INTER_AREA_FWK].

R. Dietz, "Remote Monitoring MIB Extensions or Application Performance Metrics," Internet Engineering Task Force, Jul. 1999.

Abstract: This memo defines an experimental portion of the Management Informa- tion Base (MIB) for use with network management protocols in the Internet community. In particular, it describes managed objects used for monitoring selectable performance metrics and statistics derived from the monitoring of network packets.

R. Dietz, "Transport Performance Metrics MIB," Internet Engineering Task Force, Mar. 2000.

Abstract: This memo defines an experimental portion of the Management Informa- tion Base (MIB) for use with network management protocols in the Internet community. In particular, it describes managed objects used for monitoring selectable performance metrics and statistics derived from the monitoring of network packets and transport protocol states.

B. Dolnik, "Definitions of Managed Objects for the Universal Serial Bus (USB) Interface," Internet Engineering Task Force, Aug. 2000.

Abstract: This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it defines objects for managing Universal Serial Bus (USB) interfaces.

A. Doria, T. Worster and K. Sundell, "Applicability of GSMP as an IETF Protocol," Internet Engineering Task Force, Oct. 1998.

Abstract: This memo discusses the applicability of the General Switch Management Protocol, GSMP, to network control protocols such as Multiprotocol Label Switching (MPLS). It discusses the need for this protocol to be standardized and discusses areas where development is still necessary. Finally, it recommends that the IETF establish a working group with the objective of furthering the protocol and working toward making it a standard. A PDF version of this draft can be found at: http://www. apocalypse.org/~avri/draft-doria-gsmp-applicability-00.pdf

M. Duerst and M. Davis, "Character Normalization in ITEF Protocols," Internet Engineering Task Force, Sep. 2000.

Abstract: The Universal Character Set (UCS) [ISO10646, Unicode] covers a very wide repertoire of characters. The IETF, in [RFC 2277], requires that future IETF protocols support UTF-8 [RFC 2279], an ASCII-compatible encoding of UCS. The wide range of characters included in the UCS has lead to some cases of duplicate encodings. This document proposes that in IETF protocols, the class of duplicates called canonical equivalents be dealt with by using Early Uniform Normalization according to Unicode Normalization Form C, Canonical Composition (NFC) [UTR15]. This document describes both Early Uniform Normalization and Normalization Form C.

A. Dugan, "IPDC Connection Control Protocol," Internet Engineering Task Force, Aug. 1998.

Abstract: The protocol described in this document is a member of the IP Device Control (IPDC) family of protocols. The IPDC protocols are proposed as a protocol suite, components of which can be used individually or together to perform connection control, media control, and signaling transport for environments where the service control logic is separated from the network access server. Please see the references section for other IPDC documents. The protocol specification presented here is intended for use between a media gateway controller and a media gateway. The media gateway may be capable of acting as a voice over IP gateway, voice over ATM gateway, dialup modem media gateway, circuit switch, or cross- connect. Using the IP Connection Control protocol presented here, the media gateway controller can setup, modify and teardown connections within or between media gateways.

A. Durand, "MIME TYPE definition for IP in IP tunnels," Internet Engineering Task Force, Jul. 2000.

Abstract: IP in IP tunnels are very common in the Internet. They are often used to deploy new technologies such as multicast or IPv6 when the underlying infrastructure is not ready to natively support those new protocols. Virtual Private Network are also often build using IP in IP tunnels. This document describe a MIME type that provide configuration information about IP in IP tunnels.

W. Weiss, D. Durham and A. Westerinen, "Network Information Model Requirements," Internet Engineering Task Force, Jul. 2000.

Abstract: As networking technology has evolved, a diverse set of technologies has been deployed to manage the resulting products. These very from Web based products, standard management protocols, and text scripts. The underlying systems to be manipulated are represented in varying ways including implicitly in the programmatics, with proprietary data descriptions, or with standardized descriptions using a range of technologies including MIBs, PIBs, or LDAP schemas. The result is that a single application such as DHCP or Differentiated Services may be represented in many different inconsistent fashions. Even the existing standard descriptive technologies have not been focussed on re-use across domains and commonality. The situation would be significantly improved if there were to be a common representation of data (an 'information model') from which technology-specific data models can be derived to suit application- specific configuration and management needs. This would allow the industry to build common descriptions, resulting in consistency across the paradigms, and better interoperability. Such an 'information model' would also assist other IETF working groups by reducing the work needed to determine how to represent those parts of their technology that are already in the common model.

L. Dusseault and M. Calsyn, "Presence Information Protocol Requirements," Internet Engineering Task Force, Feb. 1998.

Abstract: Online users have demonstrated a desire to know instantly whether another individual is online, to be notified when another individual arrives online, and to send instant messages. These applications currently use independent, non-standard and usually non-interoperable protocols. The goal is to define a standard protocol so that independently written client and server implementations can participate in a global network of ''online'' users. This draft outlines requirements for a Presence Information Protocol to support these applications. Distribution of this document is unlimited. Please send comments to the RVP discussion list at rvp@iastate.edu, which may be joined by sending a message with subject ''subscribe'' to rvp- request@iastate.edu. Archives of past messages are available. Send the single word \021help\022 to rvp-request@iastate.edu for more information

R. Earhart, "Application Core Protocol," Internet Engineering Task Force, Mar. 1999.

Abstract: This document specifies a textual protocol intended as a framework for applications-layer protocols. While complete, it does not do anything in and of itself; it's meant to be extensible to particular applications.

R. Earhart, "Access Protocol," Internet Engineering Task Force, Jan. 1998.

Abstract: The Access Protocol defines a standard extensible framework upon which application-specific protocols may be layered, providing a piece of infrastructure for a common class of internet protocols.

R. Earhart, "A POP3 URL Interface," Internet Engineering Task Force, Jan. 1998.

Abstract: It is occasionally useful to be able to reference a generic server to be used for message submission. URLs provide a good mechanism for refering to arbitrary network resources. The POP3 URL scheme allows a URL to specify a POP3 [POP3] server, allowing other protocols to use a general ''URL to be used for mail access'' in place of an explicit reference to POP3.

R. Earhart, "An SMTP URL Interface," Internet Engineering Task Force, Dec. 1997.

Abstract: It is occasionally useful to be able to reference a generic server to be used for message submission. URLs provide a good mechanism for refering to arbitrary network resources. The SMTP URL scheme allows a URL to specify an SMTP server, thus allowing other protocols to use a general ''URL to be used for message delivery'' in place of an explicit reference to SMTP.

D. Eastlake, "ISO 7812/7816 Numbers and the Domain Name System (DNS)," Internet Engineering Task Force, Jul. 2000.

Abstract: There are a variety of servers, web pages, and the like, which holders of ISO 7812 financial transaction identification card (i.e., credit/debit card) numbers and ISO 7816 smart card or related numbers may need to locate on the Internet. For example, some systems assume a smart card holder can contact the issuer of a smart card application for maintenance and update functions and the payment protocols may assume that a card holder can locate the appropriate certification authority to obtain a card holder certificate. This document specifies a method using the DNS as an important element in locating card related facilities on the Internet by mapping ISO 7812 and ISO 7816 number systems into domain names within in the card.reg.int domain.

Donald E. Eastlake, "Universal Payment Preamble," Internet Engineering Task Force, Oct. 1996.

Abstract: The Internet is becoming an increasingly commercial arena in which payments are rendered for goods, information, and services. To support such commerce, various incompatible Internet payment protocols have been proposed or adopted by a variety of organizations. There appears to be little prospect of merger of all or abandonment of most of these protocols. A header syntax, the Universal Payment Preamble (UPP), is presented for parties to negotiate payment alternatives at any point in shopping, until a final hand-off to a particular chosen payment system. The chosen payment system, not UPP, is responsible for the security of any actual transmission of funds.

Keywords: payment protocol; electronic commerce

R. Ekstein, Y. T'Joens, B. Sales and O. Paridaens, "AAA Protocols : Comparison between RADIUS, DIAMETER and COPS.," Internet Engineering Task Force, Apr. 2000.

Abstract: The purpose of this draft is to provide an extensive comparison between the RADIUS, DIAMETER and COPS protocols as these are positioned as generic Authentication, Authorization and Accounting (AAA) protocols. The protocols will further be verified on their compliance to the NAS requirements described in [TBA] and roaming requirements described in RFC 2477.

R. Ekstein, Y. T'Joens, B. Sales and O. Paridaens, "AAA Protocols : Comparison between RADIUS, DIAMETER and COPS.," Internet Engineering Task Force, Jan. 2000.

Abstract: The purpose of this draft is to provide an extensive comparison between the RADIUS, DIAMETER and COPS protocols as these are positioned as generic Authentication, Authorization and Accounting (AAA) protocols. The protocols will further be verified on their compliance to the NAS requirements described in [TBA] and roaming requirements described in RFC 2477.

I. Elliott, "IPDC Media Control Protocol," Internet Engineering Task Force, Aug. 1998.

Abstract: The protocol described in this document is a member of the IP Device Control (IPDC) family of protocols. The IPDC protocols are proposed as a protocol suite, components of which can be used individually or together to perform connection control, media control, and signaling transport for environments where the service control logic is separated from the network access server. Please see the references section for other IPDC documents. The protocol specification presented here is intended for use between a media gateway controller and a media gateway. The media gateway may be capable of acting as a voice over IP gateway, voice over ATM gateway, dialup modem media gateway, circuit switch, or cross-connect. Using the IP Media Control protocol presented here, the media gateway controller can send messages to the media gateway to cause events such as tones to be generated or detected within a media stream.

G. Vaudreuil and G. Parsons, "Voice Profile for Internet Mail - version 2," Internet Engineering Task Force, Nov. 1999.

Abstract: Voice messaging evolved as telephone answering service into a full send, receive, and forward messaging paradigm with unique message features, semantics and usage patterns. Voice messaging was introduced on special purpose computers that interface to a telephone switch and provide call answering and voice messaging services. Traditionally, messages sent from one voice messaging system to another were transported using analog networking protocols based on DTMF signaling and analog voice playback. As the demand for networking increases, there was a need for a standard high-quality digital protocol to connect these machines. VPIM has successfully demonstrated its usefulness as this new standard. VPIM is widely implemented and is seeing deployment in early adopter customer networks. This document clarifies ambiguities found in the earlier specification and is consistent with implementation practice. The profile is referred to as VPIM (Voice Profile for Internet Mail) in this document. This second revision of the version 2 of obsoletes RFC 2421 which less precisely describes version 2 of the profile.

S. Casner, C. Bormann and M. Engan, "IP Header Compression over PPP," Internet Engineering Task Force, Dec. 1997.

Abstract: This document describes an option for negotiating the use of header compression on IP datagrams transmitted over the Point-to- Point Protocol [RFC1661]. It defines extensions to the PPP Control Protocols for IPv4 and IPv6 [RFC1332, RFC2023]. Header compression may be applied to IPv4 and IPv6 datagrams in combination with TCP, UDP and RTP transport protocols as specified in [IPHC] and [CRTP]. [Note to IANA, to be removed before publication: The PPP protocol type assignments suggested in this document were selected from those unassigned in http://ftp.isi.edu/in-notes/iana/assignments/ppp-numbers on December 7, 1997. These selections were presented to the PPPEXT working group at IETF in Washington, DC on December 9, 1997 and were approved as being in the appropriate ranges for this protocol.]

D. Farinacci, L. Wei and J. Meylor, "Use of Anycast Clusters for Inter-Domain Multicast Routing," Internet Engineering Task Force, Mar. 1998.

Abstract: Anycast Clusters is a proposal to connect multiple ISP sparse-mode PIM domains together. The environment we anticipate is multiple interconnection points among a set of ISPs when they are unable to colocate their respective RPs at the same dense-mode interconnect point. This is an alternative to the Multi-Level RP design and requires less new code in routers. This proposal is being submitted as a method for the initial phase of Inter-Domain Multicast deployment and is upward compatible with the IDMR protocols being proposed for subsequent phases.

D. Farinacci, P. Lothberg, Y. Rekhter, H. Kilmer and J. Hall, "Multicast Source Discovery Protocol (MSDP)," Internet Engineering Task Force, Jun. 1998.

Abstract: This proposal describes a mechanism to connect multiple PIM-SM domains together. Each PIM-SM domain uses it's own independent RP(s) and do not have to depend on RPs in other domains. This proposal is being submitted as a method for the initial phase of Inter-Domain Multicast deployment in the Internet and may be upward compatible with the IDMR protocols being proposed for subsequent phases.

A. Farrel and P. Brittain, "Fault Tolerance for LDP and CR-LDP," Internet Engineering Task Force, Feb. 2000.

Abstract: MPLS systems will be used in core networks where system downtime must be kept to an absolute minimum. Many MPLS LSRs may, therefore, exploit Fault Tolerant (FT) hardware or software to provide high-availability of the core networks. The details of how FT is achieved for the various components of an FT LSR, including LDP, CR-LDP, the switching hardware and TCP, are implementation specific. This document identifies issues in the CR-LDP specification [2] and the LDP specification [4] that make it difficult to implement an FT LSR using the current LDP and CR-LDP protocols, and proposes enhancements to the LDP specification to ease such FT LSR implementations. The extensions described here are equally applicable to CR-LDP.

G. Fiaschi, F. Poggi and G. Rolandelli, "A proposal to provide QoS capability for PPP," Internet Engineering Task Force, Jul. 2000.

Abstract: Quality of Service in the IP protocol has been proposed in some service definitions (Int-Serv and Diff-Serv) and in a variety of schemes and supporting protocols (RSVP). These schemes assume, of course, that all the protocols supporting IP links in turn provide a well-defined degree of QoS the IP schemes can rely upon. One of the most common link protocols is PPP. The PPP protocol provides a standard method for transporting multi-protocol datagrams over point-to-point links. It was designed to be used in serial point-to-point links. These ones can be for example PSTN circuits, characterized by a fixed bandwidth and fixed delay. Hence, there was no need to specify QoS mechanisms for PPP: the IP layer (or more generally the network layer) did not take into account the data-link layer to calculate the available resources.

R. Finlayson, "The Multicast Attribute Framing Protocol," Internet Engineering Task Force, Jan. 1998.

Abstract: The Internet has recently seen the emergence of applications that involve the ongoing transmission, or ''pushing'', of structured data from a server to one or more client nodes. Most current applications send this data using unicast communications - usually over TCP connections. However, similar applications can also be implemented using multicast-based protocols. Multicast not only improves the scalability of this particular class of application, but also makes possible an additional class of application in which the participants can act as peers - sending data as well as receiving. This Internet Draft describes the ''Multicast Attribute Framing Protocol'' (MAFP) - a generic, attribute-based data representation, intended for a wide variety of multicast-based applications. It is currently being used to implement the ''multikit'' generic multicast session browser (http://www.lvn.com/multikit). This draft describes an early version of MAFP that is likely to undergo changes in the future. However, it is being described now, in the hope that it will promote open discussion of this and similar protocols - ideally leading to the adoption of an open, interoperable standard for this class of application.

E. Fleischman, "Advanced Streaming Format (ASF) Specification," Internet Engineering Task Force, Feb. 1998.

Abstract: The Advanced Streaming Format (ASF) is an extensible file format designed to store synchronized multimedia data. It supports data delivery over a wide variety of networks and protocols while still proving suitable for local playback. ASF supports advanced multimedia capabilities including extensible media types, component download, scaleable media types, author-specified stream prioritization, multiple language support, and extensive bibliographic capabilities, including document and content management.

S. Floyd, "Congestion Control Principles," Internet Engineering Task Force, Jun. 2000.

Abstract: The goal of this document is to explain the need for congestion control in the Internet, and to discuss what constitutes correct congestion control. One specific goal is to illustrate the dangers of neglecting to apply proper congestion control. A second goal is to discuss the role of the IETF in standardizing new congestion control protocols. This document draws heavily from earlier RFCs, in some cases reproducing entire sections of the text of earlier documents [RFC2309, RFC2357]. We have also borrowed heavily from earlier publications addressing the need for end-to-end congestion control [FF99].

B. Foster, "MGCP CAS Packages," Internet Engineering Task Force, Oct. 2000.

Abstract: This document contains a collection of media gateway CAS packages for R1 CAS, North American CAS, CAS PBX interconnect as well as basic FXO support. Included are six packages. The 'MS' package covers MF single stage dialing trunks. This includes wink start and immediate start PBX DID/DOD trunks as well as basic R1 and Feature Group D (FGD) Terminating protocol [3]. The 'DT' package covers immediate start and basic DTMF and dial-pulse trunks and the 'BL' package covers the interface to a basic PBX (digital or FXS interface). In addition to the Terminating protocol, there are three other FGD protocols described in [3]. These include EAIN and EANA which is covered by the enclosed 'MD' package and the Operator Service Signaling protocol which is handled by the 'MO' package. Support for basic FXO interconnect is provided by 'DO' package.

J. Postel and N. Freed, "IANA Charset Registration Procedures," Internet Engineering Task Force, Sep. 1997.

Abstract: MIME [RFC-2045, RFC-2046, RFC-2047, RFC-2184] and various other modern Internet protocols are capable of using many different charsets. This in turn means that the ability to label different charsets is essential. This registration procedure exists solely to associate a specific name or names with a given charset and to give an indication of whether or not a given charset can be used in MIME text objects. In particular, the general applicability and appropriateness of a given registered charset is a protocol issue, not a registration issue, and is not dealt with by this registration procedure.

N. Freed and J. Postel, "IANA Charset Registration Procedures," Internet Engineering Task Force, Jul. 2000.

Abstract: MIME [RFC-2045, RFC-2046, RFC-2047, RFC-2184] and various other Internet protocols are capable of using many different charsets. This in turn means that the ability to label different charsets is essential.

W. Fritsch and H. Seifert, "Dynamical routing (unicast and multicast) for the Ipv6 protocol," Internet Engineering Task Force, Nov. 1997.

Abstract: Future communication networks will be based more and more on a dynamically changing network topology. Therefore it is advantageous, to have routing mechanisms, which will dynamically adapt their routing decisions to these topology changes. This document describes a set of network protocols, which realize such a dynamical routing of unicast and multicast packets within communication networks based on IPv6. All used routing algorithms will be immediately executed at the occurrence of any topology changes and will therefore have already complete routing information at the receipt of data packets. For the unicasting the Shortest Path First (SPF) routing algorithm has be chosen. This algorithm calculates the shortest, and therefore the optimal routing paths within the routing area, by which it is sufficient for a router, to compute a single routing tree for the whole area. For the multicasting the Minimum Spanning Tree (MST) routing algorithm has been chosen. This distributed algorithm prevents the occurrence of endless routing loops, offers for distributed Address Groups nearly optimal results in saving network bandwidth, and needs also only a single routing tree for the whole area. This version 02 of the draft mainly corrects some minor errors of version 01.

R. Gellens, "POP URL Scheme," Internet Engineering Task Force, Mar. 1998.

Abstract: [POP3] is a widely-deployed mail access protocol. Many programs access POP3 message stores, and thus need POP3 configuration information. Since there are multiple configuration elements which are required in order to access a mailbox, a single string representation is convenient. A POP3 mailbox (like an [IMAP4] mailbox) is a network resource, and URLs are a widely-supported generalized representation of network resources. A means of specifying a POP3 mailbox as a URL will likely be useful in many programs and protocols. [ACAP] is one case where a string encapsulation of elements required to access network services is needed. For example, an [IMAP4] message store is usually specified in ACAP datasets as an [IMAP-URL].

J. Gettys and H. Nielsen, "The WebMUX Protocol," Internet Engineering Task Force, Aug. 1998.

Abstract: This document defines the experimental multiplexing protocol referred to as 'WebMUX'. WebMUX is a session management protocol separating the underlying transport from the upper level application protocols. It provides a lightweight communication channel to the application layer by multiplexing data streams on top of a reliable stream oriented transport. By supporting coexistence of multiple application level protocols (e.g. HTTP and HTTP/NG), WebMUX should ease transitions to future Web protocols, and communications of client applets using private protocols with servers over the same TCP connection as the HTTP conversation. WebMUX is intended for, but by no means restricted to, transport of Web related protocols; the name has been chosen to reduce confusion with other existing multiplexing protocols. This document is part of a suite of documents describing the HTTP-NG design and prototype implementation: * HTTP-NG Short- and Longterm Goals, ID * HTTP-NG Architectural Model, ID * HTTP-NG Wire Protocol, ID * The Classic Web Interfaces in HTTP-NG, ID * Description of the HTTP-NG Testbed, ID

N. Ghani, Z. Zhang, L. Zhang and J. Fu, "COPS Usage for ODSI," Internet Engineering Task Force, Jul. 2000.

Abstract: ODSI is a framework of protocols designed to allow internetworking devices to dynamically request bandwidth from optical networks. Within this framework, a protocol is required for policy provisioning inside the optical domain. This documents defines the application of the IETF Common Open Policy Service (COPS) protocol for this purpose and details its interworking with the ODSI framework.

S. Giacalone, "Scored Fair Metric Calculation," Internet Engineering Task Force, Aug. 2000.

Abstract: This memo defines a modular metric calculation system termed Scored Fair Metric Calculation (SFMC). SFMC can be integrated with Link State and Distance Vector routing protocols and their extensions [1,4,5,6,7], enabling them to find network paths that support the highest possible number of best metrics across a network. SFMC makes it possible to support and mix large sets of heterogeneous network features and capabilities. SFMC solves many of the issues inherent in routing protocols that attempt to use complex sets of metrics by decoupling raw metric data from the input side of routing protocols. Unlike the past, SFMC regards all metrics all the time, while treating all metrics equally (by default). Additionally, the SFMC architecture provides a simple and flexible interface for extensive manipulation of path selection. Please send comments to ospf@discuss.microsoft.com.}

B. Chen, H. Frystyk, L. Girod and J. Mallery, "WIRE - W3 Identifier Resolution Extensions," Internet Engineering Task Force, Mar. 1998.

Abstract: WIRE extends HTTP with a new type of redirect response that permits a resolver to explicitly delegate a resolution to other resolvers and protocols. WIRE is an effort to make delegation more explicit, redirection more flexible, and resolution processes more efficient through the use of hints. This document defines WIRE and describes the expected behaviors of resolvers and clients using WIRE. WIRE is an extension of the HyperText Transfer Protocol (HTTP), and is intended to be compatible with HTTP/1.0 and above [4][5]. WIRE encourages use of long-lived URIs and at the same time supports protocol evolution without having to change currently deployed URIs or URI schemes. The extension is based on a simple URI resolution model that allows an application to dynamically request metadata describing where and how to access a resource. The model can use any generic metadata description language (e.g. RDF) and as the metadata itself is interpreted as a first class resource, metadata resources are no different than any other resource on the Web.

G. Mansfield, K. Ohta and T. Ika, "A Directory for organizations and services from DNS and WHOIS.," Internet Engineering Task Force, Nov. 1997.

Abstract: An Internet Directory is a necessity. The lack of an Internet Directory is posing serious problems. There are several Directory Protocols ready for deployment in the Internet. But, among other factors, content generation for the directory has been a major stumbling block. A simple and straight-forward method of generating contents for a directory of organizations and their network services using information