@TECHREPORT{Ball9211:Core,
AUTHOR="Anthony Ballardie and Paul Tsuchiya and Jon Crowcroft",
TITLE="Core Based Trees {(CBT)}",
TYPE="Internet Draft",
INSTITUTION="University College London",
NUMBER="I-D",
MONTH=nov,
YEAR=1992,
NOTE="work in progress",
KEYWORDS="multicast; routing",
ABSTRACT="Multicasting is a technique used which allows for group
communications either locally or on a wide-area scale. Most local-area
networks such as Ethernet and Tokenring provide a multicast service,
which has since been exploited by many applications and distributed
systems. More recently, multicast capability has been extended to the
internetwork using a combination of a distance-vector routing algorithm,
a host-to-router group-membership reporting protocol, and the
computation of sender-based multicast trees. This, and other approaches
to internet multicasting, are not scalable to large groups, especially
so for large numbers of groups. This document provides a proposal for a
new multicast routing algorithm which provides multicast capability in a
datagram internetwork. It is scalable, low-cost and efficient --
properties lacking in current internetwork multicast routing protocols."
}

@TECHREPORT{draft-adie-shave,
AUTHOR="Chris Adie",
TITLE="{SGML-based} hierarchical attribute/value encoding",
TYPE="Internet Draft",
HOWPUBLISHED="draft-adie-shave-00",
INSTITUTION="Edinburgh University",
MONTH=oct,
YEAR=1993,
NOTE="Work in progress",
KEYWORDS="SGML; encoding; presentation layer",
ABSTRACT="The usefulness of attribute/value pairs for conveying
information is well established. There is a need for a standard
text-based method of representing attribute/value data, which is capable
of being easily written and read by humans, and also easily processed by
a computer program. Often, such data is required to be transferred in
electronic mail messages. This document describes how SGML (Standard
Generalized Markup Language) can be used as the basis for such a
representation.",
URL="ftp://ds.internic.net/internet-drafts/draft-adie-shave-00.txt"
}

@TECHREPORT{draft-adie-spci,
AUTHOR="Chris Adie",
TITLE="{SGML-based} personal contact information {(SPCI)}",
TYPE="Internet Draft",
HOWPUBLISHED="draft-adie-spci-00",
INSTITUTION="Edinburgh University",
MONTH=oct,
YEAR=1993,
NOTE="Work in progress",
KEYWORDS="SGML; business card",
ABSTRACT={This document describes how personal contact information may
be exchanged in a structured format suitable for machine processing. The
SGML-based Personal Contact Information (SPCI) format can be used to
encode personal information of the type which might be found on a
business card, in a form which is also suitable for human
interpretation. Possible uses of this format include: exchange of
personal information in email messages; encoding author information
within a document; providing information about a mailing list; as an
exchange format for {"}address book{"} databases; and providing contact
information for a company. The SPCI information is encoded using SGML,
and the specification is aligned with the SHAVE rules. A MIME body part
type is defined for SPCI information.},
URL="ftp://ds.internic.net/internet-drafts/draft-adie-spci-00.txt"
}

@TECHREPORT{draft-braden-realtime-outline,
AUTHOR="Bob Braden and D. Clark and Scott Shenker",
TITLE="Integrated services in the Internet architecture: an overview",
TYPE="Internet Draft",
INSTITUTION="USC-ISI",
MONTH=oct,
YEAR=1993,
NOTE="Work in progress",
KEYWORDS="RSVP; real-time services; Internet",
ABSTRACT="This memo discusses a proposed extension to the Internet
architecture and protocols to provide integrated services, i.e., to
support real-time as well as the current non-real-time service of IP.
This extension is necessary to meet the growing need for real-time
service for multimedia applications. This memo represents the direct
product of recent work by Dave Clark, John Wroclawski, Scott Shenker,
Lixia Zhang, Sugih Jamin, Deborah Estrin, Bob Braden, and Shai Herzog,
and indirectly draws upon the work of many others.",
URL="ftp://ds.internic.net/internet-drafts/draft-braden-realtime-outline00.txt"
}

@TECHREPORT{draft-braden-rsvp,
AUTHOR="L. Zhang and B. Braden and D. Estrin and S. Herzog and S. Jamin",
TITLE="Resource reservation protocol {(RSVP)} {--} Version 1 Functional
Specification",
TYPE="Internet Draft",
HOWPUBLISHED="draft-braden-rsvp-00",
INSTITUTION="Xerox PARC",
MONTH=oct,
YEAR=1993,
NOTE="Work in progress",
KEYWORDS="RSVP; resource reservation; call setup; signaling",
ABSTRACT="This memo describes version 1 of RSVP, a resource reservation
setup protocol designed for an integrated services Internet. RSVP
provides receiver-initiated setup of resource reservations for multicast
or unicast data flows, with good scaling and robustness properties.",
URL="ftp://ds.internic.net/internet-drafts/draft-braden-rsvp-00.txt"
}

@TECHREPORT{draft-ietf-cat-ftpsec,
AUTHOR="S. Lunt",
TITLE="{FTP} security extensions",
TYPE="Internet Draft",
HOWPUBLISHED="draft-ietf-cat-ftpsec-04",
INSTITUTION="Bellcore",
MONTH=nov,
YEAR=1993,
NOTE="Work in progress",
KEYWORDS="ftp; file transfer; security; Internet",
ABSTRACT={This document defines extensions to the FTP specification RFC
959, {"}FILE TRANSFER PROTOCOL (FTP){"} (October 1985), which provide
strong
authentication, integrity, and confidentiality on both the control and
data channels with the introduction of new optional commands, replies,
and file transfer encodings. The following new optional commands are
introduced in this specification: AUTH (Authentication Type), ADAT
(Authentication Data), MIC (Integrity Protected Command), ENC (Privacy
Protected Command), PROT (Data Channel Protection Level), and PBSZ
(Protection Buffer Size). A new class of reply types (6yz) is also
introduced for protected replies. None of the above commands are
required to be implemented, but each is dependent on the other (except
ENC, which is optional). Note that this specification is compatible with
RFC 959.},
URL="ftp://ds.internic.net/internet-drafts/draft-ietf-cat-ftpsec-04.txt"
}

@TECHREPORT{draft-ietf-iiir-html,
AUTHOR="Tim Berners-Lee and D. Connolly",
TITLE="Hypertext Markup Language",
TYPE="Internet Draft",
HOWPUBLISHED="draft-ietf-iiir-html-01",
INSTITUTION="CERN",
MONTH=jun,
YEAR=1993,
NOTE="Work in progress",
KEYWORDS="HTML; world-wide web; hypertext",
ABSTRACT="HyperText Markup Language (HTML) can be used to represent
Hypertext news, mail, online documentation, and collaborative
hypermedia; Menus of options; Database query results; Simple structured
documents with inlined graphics. Hypertext views of existing bodies of
information. The World Wide Web (W3) initiative links related
information throughout the globe. HTML provides one simple format for
throughout the globe. HTML provides one simple format for providing
linked information, and all W3 compatible programs are required to be
capable of handling HTML. W3 uses an Internet protocol (Hypertext
Transfer Protocol, HTTP), which allows transfer representations to be
negotiated between client and server, the result being returned in an
extended MIME message. HTML is therefore just one, but an important one,
of the representations used with W3. HTML is proposed as a MIME content
type.",
URL="ftp://ds.internic.net/internet-drafts/draft-ietf-iiir-html-01.txt"
}

@TECHREPORT{draft-ietf-iiir-http,
AUTHOR="Tim Berners-Lee",
TITLE="Hypertext transfer protocol",
TYPE="Internet Draft",
HOWPUBLISHED="draft-ietf-iiir-http-00",
INSTITUTION="CERN",
MONTH=nov,
YEAR=1993,
NOTE="Work in progress",
KEYWORDS="HTTP; WWW; world-wide web; hypertext; transport protocol",
ABSTRACT="HTTP is a protocol with the lightness and speed necessary for
a distributed collaborative hypermedia information system. It is a
generic stateless object-oriented protocol, which may be used for many
similar tasks such as name servers, and distributed object-oriented
systems, by extending the commands, or 'methods', used. A feature if
HTTP is the negotiation of data representation, allowing systems to be
built independently of the development of new advanced representations.",
URL="ftp://ds.internic.net/internet-drafts/draft-ietf-iiir-http-00.txt"
}

@TECHREPORT{draft-ietf-iiir-vision,
AUTHOR="Chris Weider and Peter Deutsch",
TITLE="A vision of an integrated Internet information service",
TYPE="Internet Draft",
HOWPUBLISHED="draft-ietf-iiir-vision-01",
INSTITUTION="Merit Network/Bunyip",
MONTH=oct,
YEAR=1993,
NOTE="Work in progress",
KEYWORDS="information services; WWW; Internet; world-wide web",
ABSTRACT="In this paper, the authors put forth their vision of an
integrated Internet information service which ties together the
information services currently deployed and allows them to work
together.",
URL="ftp://ds.internic.net/internet-drafts/draft-ietf-iiir-vision-01.txt"
}

@TECHREPORT{draft-ietf-tpix-catnip-base-0,
AUTHOR="Robert Ullmann",
TITLE="{CATNIP:} common architecture technology for next-generation Internet
Protocol",
TYPE="Internet Draft",
HOWPUBLISHED="draft-ietf-tpix-catnip-base-0",
INSTITUTION="Lotus Development Corporation",
MONTH=nov,
YEAR=1993,
NOTE="Work in progress",
KEYWORDS="IPng; network layer; TUBA; IP; network protocol; addressing",
ABSTRACT="This memo describes a common architecture for the network
layer protocol.",
URL="ftp://ds.internic.net/internet-drafts/draft-ietf-tpix-catnip-base-0.txt"
}

@TECHREPORT{draft-ietf-uri-resource-names,
AUTHOR="Chris Weider and Peter Deutsch",
TITLE="Uniform Resource Names",
TYPE="Internet Draft",
INSTITUTION="Merit Network",
MONTH=oct,
YEAR=1993,
NOTE="Work in progress",
KEYWORDS="URI; URL; URN; naming; directory service",
ABSTRACT="In this paper, the authors propose an identifier, called the
Uniform Resource Name (URN), which is designed to provide persistent
naming for resources and objects on the Internet.",
URL="ftp://ds.internic.net/internet-drafts/draft-ietf-uri-resource-names-01.txt"
}

@TECHREPORT{draft-ietf-uri-url,
AUTHOR="Tim Berners-Lee",
TITLE="Uniform Resource Locators",
TYPE="Internet Draft",
HOWPUBLISHED="draft-ietf-uri-url-01",
INSTITUTION="CERN",
MONTH=jul,
YEAR=1993,
NOTE="Work in progress",
KEYWORDS="URL; directory services; WWW",
ABSTRACT={Many protocols and systems for document search and retrieval
are currently in use, and many more protocols or refinements of existing
protocols are to be expected in a field whose expansion is explosive.
These systems are aiming to achieve global search and readership of
documents across differing computing platforms, and despite a plethora
of protocols and data formats. As protocols evolve, gateways can allow
global access to remain possible. As data formats evolve, format
conversion programs can preserve global access. There is one area,
however, in which it is impractical to make conversions, and that is in
the names and addresses used to identify objects. This is because names
and addresses of objects are passed on in so many ways, from the backs
of envelopes to hypertext objects, and may have a long life. This paper
discusses the requirements on a universal syntax which can be used to
refer to objects available using existing protocols, and may be extended
with technology. It makes a recommendation for a generic syntax, and for
specific forms for {"}Uniform Resource Locators{"} (URLs) of objects
accessible using existing Internet protocols.},
URL="ftp://ds.internic.net/internet-drafts/draft-ietf-uri-url-01.txt"
}

@TECHREPORT{draft-ietf-wnils-whois,
AUTHOR="Chris Weider and Jim Fullton and Simon Spero",
TITLE="Architecture of the Whois++ Index Service",
TYPE="Internet Draft",
HOWPUBLISHED="draft-ietf-wnils-whois-02",
INSTITUTION="Merit Network",
MONTH=oct,
YEAR=1993,
NOTE="Work in progress",
KEYWORDS="whois++; directory service; indexing; distributed database; X.500",
ABSTRACT="The authors describe an architecture for indexing in
distributed databases, and apply this to the WHOIS++ protocol.",
URL="ftp://ds.internic.net/internet-drafts/draft-ietf-wnils-whois-02.txt"
}

@TECHREPORT{draft-raggett-www-html,
AUTHOR="David Raggett",
TITLE="{HTML+} (Hypertext markup format)",
TYPE="Internet Draft",
HOWPUBLISHED="draft-raggett-www-html-00",
INSTITUTION="Hewlett Packard",
MONTH=oct,
YEAR=1993,
NOTE="Work in progress",
KEYWORDS="HTML; hypertext",
ABSTRACT="This draft presents a proposal for a light weight delivery
format for browsing and querying information in a web of globally
distributed hypertext, accessible over the Internet. HTML+ embodies a
pageless model making it suitable for efficient rendering on a wide
range of display types, for example, VT100 terminals, X11 Workstations,
Windows 3.x and the Macintosh. HTML+ is based upon SGML, and represents
document elements at a logical level, e.g. headers, paragraphs, lists,
tables, and figures. Authors can choose to create HTML+ documents
directly, or to use filters to convert from other formats such as LaTeX,
Framemaker, and Word for Windows. HTML+ has grown out of several years
experience with the HTML document format in the World Wide Web
community. Browser writers are experimenting with extensions to HTML and
it is now appropriate to draw these ideas together into a revised
document format. The new format is designed to allow a gradual roll over
from HTML, adding features like tables, captioned figures and pull-out
forms for querying remote databases or mailing questionnaires. Large
documents can be split into a number of smaller nodes for reduced
latency, with explicit or implicit navigation links. This draft also
includes a proposal to add direct support for mathematical formulae.
Authors can include limited presentation hints, and further control
mayeventually be possible via associated style sheets.",
URL="ftp://ds.internic.net/internet-drafts/draft-raggett-www-html-00.txt"
}

@TECHREPORT{draft-rare-imm-netaccess,
AUTHOR="Chris Adie",
TITLE="Network access to multimedia information",
TYPE="Internet Draft",
HOWPUBLISHED="draft-rare-imm-netaccess-00.t
t",
INSTITUTION="Edinburgh University Computing Service",
MONTH=nov,
YEAR=1993,
NOTE="Work in progress",
KEYWORDS="multimedia; WWW; Gopher",
ABSTRACT="This report summarises the requirements of research and
academic network users for network access to multimedia information. It
does this by investigating some of the projects planned or currently
underway in the community. Existing information systems such as Gopher,
WAIS and World-Wide Web are examined from the point of view of
multimedia support, and some interesting hypermedia systems emerging
from the research community are also studied. Relevant existing and
developing standards in this area are discussed. The report identifies
the gaps between the capabilities of currently-deployed systems and the
user requirements, and proposes further work centred on the World-Wide
Web system to rectify this. The report is in some places very detailed,
so it is preceded by an extended summary, which outlines the findings of
the report.",
URL="ftp://ds.internic.net/internet-drafts/draft-rare-imm-netaccess-00.t
t"
}

@TECHREPORT{draft-shenker-realtime-model-0,
AUTHOR="S. Shenker and D. Clark and L. Zhang",
TITLE="A service model for an integrated services Internet",
TYPE="Internet Draft",
HOWPUBLISHED="draft-shenker-realtime-model-0",
INSTITUTION="Xerox PARC",
MONTH=oct,
YEAR=1993,
NOTE="Work in progress",
KEYWORDS="Internet; network architecture; quality of service; service model;
real-time services",
ABSTRACT={The Internet is currently being confronted with service
demands from a new generation of applications. Supporting these
applications effectively and efficiently will require extending the
current Internet {"}best-effort{"} service model to one that offers an
integrated suite of services. The purpose of this memo is to describe a
proposed {"}core{"} service model for an integrated services Internet. In
the Appendix we discuss the process by which such a service model could
be standardized by the IETF.},
URL="ftp://ds.internic.net/internet-drafts/draft-shenker-realtime-model-0.txt"
}

@TECHREPORT{draft-tschofenig-sipping-framework-spit-reduction,
AUTHOR="Hannes Tschofenig and Henning Schulzrinne and Dan Wing and Jonathan
Rosenberg and David Schwartz",
TITLE="A Framework to tackle Spam and Unwanted Communication for Internet
Telephony",
TYPE="Internet Draft",
INSTITUTION="Internet Engineering Task Force",
NUMBER="draft-tschofenig-sipping-framework-spit-reduction",
DAYS=1,
MONTH=jan,
YEAR=1993,
ABSTRACT="Spam, defined as sending unsolicited messages to someone in bulk, is likely
to become a problem on SIP open-wide deployed networks. A number of
solutions have been proposed for dealing with Spam for Internet Telephony
(SPIT) and unwanted communication, for example, content filtering, black
lists, white lists, consent-based communication, reputation systems,
address obfuscation, limited use addresses, turing tests, computational
puzzles, payments at risk, circles of trust, and many others. This document
describes the big picture that illustrates how the different building
blocks fit together and can be deployed incrementally.",
URL="http://tools.ietf.org/internet-drafts/draft-tschofenig-sipping-framework-spit-reduction.txt"
}

@TECHREPORT{Kapl9303:Resource,
AUTHOR="S. Kaplan",
TITLE="Resource location protocol",
TYPE="Internet Draft",
INSTITUTION="FTP Software, Inc.",
NUMBER="I-D draft-ietf-svrlo",
MONTH=mar,
YEAR=1993,
NOTE="work in progress",
KEYWORDS="resource location protocol; protocols",
ABSTRACT="This document specifies the Resource Location (ResLoc)
protocol. The ResLoc protocol allows a resource to advertise itself on
the network. It defines a set of network queries that determines the
location and type of resource available. It defines a mechanism to
provide the minimal configuration information to effectively use that
resource. It provides the ability to gather the advertised information
in a central repository (binding broker) to reduce network bandwidth and
allow the protocol to scale to large networks."
}

@TECHREPORT{Turl9303:Packetization,
AUTHOR="T. Turletti and C. Huitema",
TITLE="Packetization of {H.261} video streams",
TYPE="Internet Draft",
INSTITUTION="INRIA",
NUMBER="I-D draft-ietf-avt-v",
MONTH=mar,
YEAR=1993,
NOTE="work in progress",
KEYWORDS="H.261; packetization; RTP",
ABSTRACT="The CCITT recommendation H.261 specifies the encodings used by
CCITT compliant video-conference codecs. Although these encodings were
originally specified for fixed data rate ISDN circuits, experimentations
have shown that they can also be used over the internet. The purpose of
this memo is to specify how H.261 video streams can be carried over UDP
and IP, using the RTP protocol."
}

@TECHREPORT{draft-ietf-avt-cellb-profile,
AUTHOR="Michael Speer and Don Hoffman",
TITLE="{RTP} Encapsulation of {CellB} Video Encoding",
TYPE="Internet Draft",
HOWPUBLISHED="draft-ietf-avt-cellb-profile-01",
INSTITUTION="Sun Microsystems",
MONTH=nov,
YEAR=1994,
NOTE="Work in progress",
KEYWORDS="RTP; packet video; cellb; video encoding",
ABSTRACT="This note describes a packetization scheme for the CellB video
encoding using RTP. This document is meant for implementors of video
applications that use RTP and CellB.",
URL="ftp://ds.internic.net/internet-drafts/draft-ietf-avt-cellb-profile-01.txt.txt"
}

@TECHREPORT{draft-ietf-avt-jpeg,
AUTHOR="William Fenner and Lance Berc and Ron Frederick and Steve McCanne",
TITLE="{RTP} Encapsulation of {JPEG-compressed} video",
TYPE="Internet Draft",
HOWPUBLISHED="draft-ietf-avt-jpeg-00",
INSTITUTION="Kaman Sciences",
MONTH=nov,
YEAR=1994,
NOTE="Work in progress",
KEYWORDS="RTP; JPEG; packet video",
ABSTRACT="This draft describes a packetization scheme for JPEG video
over RTP. It is optimized for real-time video streams using constant
JPEG parameters, as opposed to individual JPEG images coming from
different sources.",
URL="ftp://ds.internic.net/internet-drafts/draft-ietf-avt-jpeg-00.txt"
}

@TECHREPORT{draft-ietf-avt-video-packet,
AUTHOR="T. Turletti and C. Huitema",
TITLE="Packetization of {H.261} video streams",
TYPE="Internet Draft",
HOWPUBLISHED="draft-ietf-avt-video-packet-03",
INSTITUTION="INRIA",
MONTH=sep,
YEAR=1994,
NOTE="Work in progress",
KEYWORDS="RTP; packet video; H.261",
ABSTRACT="This draft describes a packetization scheme of H.261 video
stream. The scheme proposed can be used to transport such a video flow
over the protocols used by RTP.",
URL="ftp://ds.internic.net/internet-drafts/draft-ietf-avt-video-packet-03.txt"
}

@TECHREPORT{draft-ietf-uri-url,
AUTHOR="T. Berners-Lee and L. Masinter and M. McCahill",
TITLE="Uniform Resource Locators {(URL)}",
TYPE="Internet Draft",
HOWPUBLISHED="draft-ietf-uri-url-07",
INSTITUTION="URI Working Group",
MONTH=sep,
YEAR=1994,
NOTE="Work in progress",
KEYWORDS="world-wide web; WWW; URL; resource location; FTP; gopher",
ABSTRACT="This document specifies a Uniform Resource Locator (URL), the
syntax and semantics of formalized information for location and access
of resources via the Internet.",
URL="ftp://ds.internic.net/internet-drafts/draft-ietf-uri-url-07.txt"
}

@TECHREPORT{Calh9505:Congestion,
AUTHOR="Pat Calhoun",
TITLE="Congestion Control in {IPv6} Internetworks",
TYPE="Internet Draft",
INSTITUTION="Internet Engineering Task Force",
MONTH=may,
YEAR=1995,
NOTE="Work in progress",
KEYWORDS="Bit marking; TCP; Congestion Control"
}

@TECHREPORT{draft-hickman-netscape-ssl,
AUTHOR="K. Hickman and T. Elgamal",
TITLE="The {SSL} Protocol",
TYPE="Internet Draft",
HOWPUBLISHED="draft-hickman-netscape-ssl-01",
INSTITUTION="Internet Engineering Task Force",
MONTH=jun,
YEAR=1995,
NOTE="Work in progress",
URL="http://www.ietf.org/internet-drafts/draft-hickman-netscape-ssl-01.txt"
}

@TECHREPORT{draft-ietf-asid-whois-mesh,
AUTHOR="P. Faltstrom and R. Schoultz and C. Weider",
TITLE="How to interact with a Whois++ mesh",
TYPE="Internet Draft",
HOWPUBLISHED="draft-ietf-asid-whois-mesh-01",
INSTITUTION="Internet Engineering Task Force",
MONTH=mar,
YEAR=1995,
NOTE="Work in progress",
URL="http://www.ietf.org/internet-drafts/draft-ietf-asid-whois-mesh-01.txt"
}

@TECHREPORT{draft-ietf-avt-cellb,
AUTHOR="Michael Speer and Don Hoffman",
TITLE="{RTP} Payload Format of {CellB} Video Encoding",
TYPE="Internet Draft",
HOWPUBLISHED="draft-ietf-avt-cellb-06",
INSTITUTION="Internet Engineering Task Force",
MONTH=aug,
YEAR=1995,
NOTE="Work in progress",
URL="http://www.ietf.org/internet-drafts/draft-ietf-avt-cellb-06.txt"
}

@TECHREPORT{draft-ietf-avt-h261,
AUTHOR="T. Turletti and C. Huitema",
TITLE="{RTP} payload format for {H.261} video streams",
TYPE="Internet Draft",
HOWPUBLISHED="draft-ietf-avt-h261-01",
INSTITUTION="Internet Engineering Task Force",
MONTH=jul,
YEAR=1995,
NOTE="Work in progress",
URL="http://www.ietf.org/internet-drafts/draft-ietf-avt-h261-01.txt"
}

@TECHREPORT{draft-ietf-avt-jpeg,
AUTHOR="W. Fenner and L. Berc and R. Frederick and S. McCanne",
TITLE="{RTP} Encapsulation of {JPEG-compressed} video",
TYPE="Internet Draft",
HOWPUBLISHED="draft-ietf-avt-jpeg-01",
INSTITUTION="Internet Engineering Task Force",
MONTH=mar,
YEAR=1995,
NOTE="Work in progress",
URL="http://www.ietf.org/internet-drafts/draft-ietf-avt-jpeg-01.txt"
}

@TECHREPORT{draft-ietf-avt-profile,
AUTHOR="Henning Schulzrinne",
TITLE="{RTP} Profile for Audio and Video Conferences with Minimal Control",
TYPE="Internet Draft",
HOWPUBLISHED="draft-ietf-avt-profile-06.ps",
INSTITUTION="IETF",
MONTH=nov,
YEAR=1995,
NOTE="Work in progress",
KEYWORDS="RTP; profile; packet audio; packet video",
ABSTRACT="This note describes a profile for the use of the real-time
transport protocol (RTP) and the associated control protocol, RTCP,
within audio and video multiparticipant conferences with minimal
control.  It provides interpretations of generic fields within the RTP
specification suitable for audio and video conferences.  In
particular, this document defines a set of default mappings from
format index to encodings.  The document also describes how audio and
video data may be carried within RTP.  It defines a set of standard
encodings and their names when used within RTP.  However, the
definitions are independent of the particular transport mechanism
used.  The descriptions provide pointers to reference implementations
and the detailed standards.  This document is meant as an aid for
implementors of audio, video and other real-time multimedia
applications.",
URL="ftp://ds.internic.net/internet-drafts/draft-ietf-avt-profile-06.ps"
}

@TECHREPORT{draft-ietf-http-v10-spec,
AUTHOR="T. Berners-Lee and R. Fielding and H. Frystyk",
TITLE="Hypertext Transfer Protocol {--} {HTTP/1.0}",
TYPE="Internet Draft",
HOWPUBLISHED="draft-ietf-http-v10-spec-01.ps",
INSTITUTION="Internet Engineering Task Force",
MONTH=aug,
YEAR=1995,
NOTE="Work in progress",
URL="http://www.ietf.org/internet-drafts/draft-ietf-http-v10-spec-01.ps"
}

@TECHREPORT{draft-ietf-http-v11-spec,
AUTHOR="R. Fielding and H. Frystyk and T. Berners-Lee",
TITLE="Hypertext Transfer Protocol {--} {HTTP/1.1}",
TYPE="Internet Draft",
HOWPUBLISHED="draft-ietf-http-v11-spec-00.ps",
INSTITUTION="Internet Engineering Task Force",
MONTH=nov,
YEAR=1995,
NOTE="Work in progress",
URL="http://www.ietf.org/internet-drafts/draft-ietf-http-v11-spec-00.ps"
}

@TECHREPORT{draft-ietf-mmusic-agree,
AUTHOR="S. Shenker and A. Weinrib and E. Schooler",
TITLE="Managing Shared Ephemeral Teleconferencing State: Policy and Mechanism",
TYPE="Internet Draft",
HOWPUBLISHED="draft-ietf-mmusic-agree-00.ps",
INSTITUTION="Internet Engineering Task Force",
MONTH=jul,
YEAR=1995,
NOTE="Work in progress",
URL="http://www.ietf.org/internet-drafts/draft-ietf-mmusic-agree-00.ps"
}

@TECHREPORT{Mill9507:Integrated,
AUTHOR="Walter Milliken",
TITLE="Integrated Services {IP} Multicasting over {ATM}",
TYPE="Internet Draft",
INSTITUTION="Internet Engineering Task Force",
MONTH=jul,
YEAR=1995,
NOTE="Work in progress"
}

@TECHREPORT{draft-eastlake-universal-payment,
AUTHOR="Donald Eastlake",
TITLE="Universal Payment Preamble",
TYPE="Internet Draft",
HOWPUBLISHED="draft-eastlake-universal-payment-03",
INSTITUTION="Internet Engineering Task Force",
MONTH=oct,
YEAR=1996,
NOTE="Work in progress",
KEYWORDS="payment protocol; electronic commerce",
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.",
URL="http://www.ietf.org/internet-drafts/draft-eastlake-universal-payment-03.txt"
}

@TECHREPORT{draft-gulbrandsen-dns-rr-srvcs,
AUTHOR="Arnt Gulbrandsen and Paul Vixie",
TITLE="A {DNS} {RR} for specifying the location of services",
TYPE="Internet Draft",
HOWPUBLISHED="draft-gulbrandsen-dns-rr-srvcs-01",
INSTITUTION="Internet Engineering Task Force",
MONTH=jan,
YEAR=1996,
NOTE="Work in progress",
URL="http://www.ietf.org/internet-drafts/draft-gulbrandsen-dns-rr-srvcs-01.txt"
}

@TECHREPORT{draft-holtman-http-negotiation,
AUTHOR="Koen Holtman and Andrew Mutz",
TITLE="Transparent Content Negotiation in {HTTP}",
TYPE="Internet Draft",
HOWPUBLISHED="draft-holtman-http-negotiation-04",
INSTITUTION="Internet Engineering Task Force",
MONTH=nov,
YEAR=1996,
NOTE="Work in progress",
KEYWORDS="WWW; HTTP; content negotiation",
ABSTRACT="HTTP allows one to put multiple versions of the same
information under a single URL. Transparent content negotiation is a
mechanism, layered on top of HTTP, for automatically selecting the best
version when the URL is accessed. This enables the smooth deployment of
new web data formats and markup tags. Design goals for transparent
content negotiation include: low overhead on the request message size,
downwards compatibility, extensibility, enabling the rapid introduction
of new areas of negotiation, scalability, low cost for minimal support,
end user control, and good cacheability.",
URL="http://www.ietf.org/internet-drafts/draft-holtman-http-negotiation-04.txt"
}

@TECHREPORT{draft-ietf-avt-mmusic-scip,
AUTHOR="Henning Schulzrinne",
TITLE="Simple Conference Invitation Protocol",
TYPE="Internet Draft",
HOWPUBLISHED="draft-ietf-avt-mmusic-scip-00",
INSTITUTION="Internet Engineering Task Force",
MONTH=feb,
YEAR=1996,
NOTE="Work in progress",
KEYWORDS="conference control; SCIP",
URL="http://www.ietf.org/internet-drafts/draft-ietf-avt-mmusic-scip-00.txt"
}

@TECHREPORT{draft-ietf-http-state-mgmt,
AUTHOR="David Kristol and Lou Montulli",
TITLE="{HTTP} State Management Mechanism",
TYPE="Internet Draft",
HOWPUBLISHED="draft-ietf-http-state-mgmt-05",
INSTITUTION="Internet Engineering Task Force",
MONTH=nov,
YEAR=1996,
NOTE="Work in progress",
KEYWORDS="HTTP; WWW; state management",
ABSTRACT="This document specifies a way to create a stateful session
with HTTP requests and responses. It describes two new headers, Cookie
and Set- Cookie, which carry state information between participating
origin servers and user agents. The method described here differs from
Netscape's Cookie proposal, but it can interoperate with HTTP/1.0 user
agents that use Netscape's method. (See the HISTORICAL section.)",
URL="http://www.ietf.org/internet-drafts/draft-ietf-http-state-mgmt-05.txt"
}

@TECHREPORT{draft-ietf-idmr-spec,
AUTHOR="Anton Ballardie and Scott Reeve and Nitin Jain",
TITLE="Core Based Trees {(CBT)} Multicast - Protocol Specification",
TYPE="Internet Draft",
HOWPUBLISHED="draft-ietf-idmr-spec-06",
INSTITUTION="Internet Engineering Task Force",
MONTH=sep,
YEAR=1996,
NOTE="Work in progress",
KEYWORDS="CBT; multicast; routing; core-based trees",
ABSTRACT="This document describes the Core Based Tree (CBT) network
layer multicast protocol. CBT is a next-generation multicast protocol
that makes use of a shared delivery tree rather than separate per-sender
trees utilized by most other multicast schemes [1, 2, 3]. The CBT
architecture is described in [4a]. This specification includes an
optimization whereby unencapsulated (native) IP-style multicasts are
forwarded by CBT routers, resulting in very good forwarding performance.
This mode of operation is called CBT 'native mode'. Native mode can only
be used in CBT-only domains.",
URL="http://www.ietf.org/internet-drafts/draft-ietf-idmr-spec-06.txt"
}

@TECHREPORT{draft-ietf-mmusic-sap,
AUTHOR="Mark Handley",
TITLE="{SAP:} Session Announcement Protocol",
TYPE="Internet Draft",
HOWPUBLISHED="draft-ietf-mmusic-sap-00",
INSTITUTION="Internet Engineering Task Force",
MONTH=nov,
YEAR=1996,
NOTE="Work in progress",
ABSTRACT="This document describes the SAP - the session directory
announcement protocol, and the related issues affecting secu- rity and
scalability that should be taken into account by the implementors of
session directory tools. It is a companion document to
draft-ietf-mmusic-sdp.",
URL="http://www.ietf.org/internet-drafts/draft-ietf-mmusic-sap-00.txt"
}

@TECHREPORT{draft-ietf-urn-naptr,
AUTHOR="Ron Daniel",
TITLE="Resolution of Uniform Resource Identifiers using the Domain Name System",
TYPE="Internet Draft",
HOWPUBLISHED="draft-ietf-urn-naptr-01",
INSTITUTION="Internet Engineering Task Force",
MONTH=nov,
YEAR=1996,
NOTE="Work in progress",
KEYWORDS="URN; name resolution; DNS",
ABSTRACT="Uniform Resource Locators (URLs) are the foundation of the
World Wide Web, and are a vital Internet technology. However, they have
proven to be brittle in practice. The basic problem is that URLs
typically identify a particular path to a file on a particular host.
There is no graceful way of changing the path or host once the URL has
been assigned. Neither is there a graceful way of replicating the
resource located by the URL to achieve better network utilization and/or
fault tolerance. Uniform Resource Names (URNs) have been hypothesized as
a adjunct to URLs that would overcome such problems. URNs and URLs are
both instances of a broader class of identifiers known as Uniform
Resource Identifiers (URIs). This document describes a new DNS Resource
Record, NAPTR (Naming Authority PoinTeR), that provides rules for
mapping parts of URIs to domain names. By changing the mapping rules, we
can change the host that is contacted to resolve a URI. This will allow
a more graceful handling of URLs over long time periods, and forms the
foundation for a new proposal for Uniform Resource Names. In addition to
locating resolvers, the NAPTR provides for other naming systems to be
grandfathered into the URN world, provides independence between the name
assignment system and the resolution protocol system, and allows
multiple services (Name to Location, Name to Description, Name to
Resource, ...) to be offered. In conjunction with the SRV RR proposal
[3], the NAPTR record allows those services to be replicated for the
purposes of fault tolerance and load balancing.",
URL="http://www.ietf.org/internet-drafts/draft-ietf-urn-naptr-01.txt"
}

@TECHREPORT{draft-masinter-url-data,
AUTHOR="Larry Masinter",
TITLE="Data: {URL} scheme",
TYPE="Internet Draft",
HOWPUBLISHED="draft-masinter-url-data-00",
INSTITUTION="Internet Engineering Task Force",
MONTH=feb,
YEAR=1996,
NOTE="Work in progress",
URL="http://www.ietf.org/internet-drafts/draft-masinter-url-data-00.txt"
}

@TECHREPORT{draft-rosenberg-itg,
AUTHOR="Jonathan Rosenberg and Henning Schulzrinne",
TITLE="Issues and Options for an Aggregation Service within {RTP}",
TYPE="Internet Draft",
HOWPUBLISHED="draft-rosenberg-itg-00.ps",
INSTITUTION="Internet Engineering Task Force",
MONTH=nov,
YEAR=1996,
NOTE="Work in progress",
KEYWORDS="RTP; aggregation",
ABSTRACT="This memorandum discusses the issues and options involved in
the design of a new transport protocol for multiplexed voice within a
single packet. The intended application is the interconnection of
devices which provide 'trunking' or long distance telephone service over
the Internet. Such devices have many voice connections simultaneously
between them. Multiplexing them into the same connection improves on the
efficiency, enables the use of low bitrate voice codecs, and improves
scalability. Options and issues concerning timestamping, payload type
identification, length indication, and channel identification are
discussed. Several possible header formats are identified, and their
efficiencies are compared.",
URL="http://www.ietf.org/internet-drafts/draft-rosenberg-itg-00.ps"
}

@TECHREPORT{draft-stevens-tcpca-spec,
AUTHOR="W. Stevens",
TITLE="{TCP} Slow Start, Congestion Avoidance, Fast Retransmit, and Fast Recovery
Algorithms",
TYPE="Internet Draft",
HOWPUBLISHED="draft-stevens-tcpca-spec-01",
INSTITUTION="Internet Engineering Task Force",
MONTH=mar,
YEAR=1996,
NOTE="Work in progress",
KEYWORDS="Tcp",
URL="http://ftp.www.ietf.org/internet-drafts/draft-stevens-tcpca-spec-01.txt"
}

@TECHREPORT{draft-williams-uls,
AUTHOR="R. Williams",
TITLE="User Location Service",
TYPE="Internet Draft",
HOWPUBLISHED="draft-williams-uls-01",
INSTITUTION="Internet Engineering Task Force",
MONTH=feb,
YEAR=1996,
NOTE="Work in progress",
KEYWORDS="user location; directory",
URL="http://www.cs.columbia.edu/~hgs/sip/draft-williams-uls-01.txt"
}

@TECHREPORT{Talp9611:Multicast,
AUTHOR="R. Talpade and M. Ammar",
TITLE="Multicast Server Architectures for {MARS-based} {ATM} multicasting",
TYPE="Internet Draft",
INSTITUTION="Internet Engineering Task Force",
MONTH=nov,
YEAR=1996,
NOTE="Work in progress"
}

@TECHREPORT{Borm9705:Providing,
AUTHOR="C. Bormann",
TITLE="Providing integrated services over low-bitrate links",
TYPE="Internet Draft",
INSTITUTION="Internet Engineering Task Force - ISSLL WG",
MONTH=may,
YEAR=1997,
NOTE="Work in progress"
}

@TECHREPORT{draft-abela-utf9,
AUTHOR="J. Abela",
TITLE="{UTF-9,} a transformation format of {UCS}",
TYPE="Internet Draft",
HOWPUBLISHED="draft-abela-utf9-00",
INSTITUTION="Internet Engineering Task Force",
MONTH=dec,
YEAR=1997,
NOTE="Work in progress",
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.",
URL="http://www.ietf.org/internet-drafts/draft-abela-utf9-00.txt"
}

@TECHREPORT{draft-aboba-dynradius,
AUTHOR="B. Aboba",
TITLE="Dynamic Attributes for the Remote Access Dialin User Service {(RADIUS)}",
TYPE="Internet Draft",
HOWPUBLISHED="draft-aboba-dynradius-01",
INSTITUTION="Internet Engineering Task Force",
MONTH=nov,
YEAR=1997,
NOTE="Work in progress",
ABSTRACT="This document defines dynamic attributes used by the Remote
Access Dialin User Service (RADIUS). These attributes are written to a
dynamic directory service by the RADIUS server in order to provide
information about sessions in progress. This information can then be
used in order to provide for control of simultaneous logins, or for
detection or tracking of security incidents in progress.",
URL="http://www.ietf.org/internet-drafts/draft-aboba-dynradius-01.txt"
}

@TECHREPORT{draft-aboba-ppp,
AUTHOR="B. Aboba",
TITLE="Extension for {PPP} Authentication",
TYPE="Internet Draft",
HOWPUBLISHED="draft-aboba-ppp-01",
INSTITUTION="Internet Engineering Task Force",
MONTH=nov,
YEAR=1997,
NOTE="Work in progress",
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.",
URL="http://www.ietf.org/internet-drafts/draft-aboba-ppp-01.txt"
}

@TECHREPORT{draft-aboba-rpsl,
AUTHOR="B. Aboba",
TITLE="Lightweight Directory Access Protocol (v3): Schema for the Routing Policy
Specification Language {(RPSL)}",
TYPE="Internet Draft",
HOWPUBLISHED="draft-aboba-rpsl-00",
INSTITUTION="Internet Engineering Task Force",
MONTH=nov,
YEAR=1997,
NOTE="Work in progress",
ABSTRACT="This document defines a schema for the Routing Policy
Specification Language (RPSL). It is expected that this schema will be
useful in providing a standardized format for representation of RPSL
within LDAP-based directory services.",
URL="http://www.ietf.org/internet-drafts/draft-aboba-rpsl-00.txt"
}

@TECHREPORT{draft-aboba-rtpscale,
AUTHOR="Bernard Aboba",
TITLE="Alternatives for Enhancing {RTCP} Scalability",
TYPE="Internet Draft",
HOWPUBLISHED="draft-aboba-rtpscale-02",
INSTITUTION="Internet Engineering Task Force",
MONTH=jan,
YEAR=1997,
NOTE="Work in progress",
KEYWORDS="RTP; scalability",
ABSTRACT="This document discusses current issues with RTCP scalability
as well as describing the advantages and disadvantages of possible
solutions.",
URL="http://www.ietf.org/internet-drafts/draft-aboba-rtpscale-02.txt"
}

@TECHREPORT{draft-allen-pppsonet-mapping,
AUTHOR="B. Allen and J. Anderson and B. Wang and A. White and D. Kostas",
TITLE="{PPP} Over {SONET} Mapping",
TYPE="Internet Draft",
HOWPUBLISHED="draft-allen-pppsonet-mapping-00",
INSTITUTION="Internet Engineering Task Force",
MONTH=oct,
YEAR=1997,
NOTE="Work in progress",
ABSTRACT="This Internet Draft addresses the PPP/SONET interface defined
in the IETF RFC 1619 and the standards work underway in T1X1 on SONET.",
URL="http://www.ietf.org/internet-drafts/draft-allen-pppsonet-mapping-00.txt"
}

@TECHREPORT{draft-allman-ftp-sec-consider,
AUTHOR="S. Ostermann and M. Allman",
TITLE="{FTP} Security Considerations",
TYPE="Internet Draft",
HOWPUBLISHED="draft-allman-ftp-sec-consider-02",
INSTITUTION="Internet Engineering Task Force",
MONTH=aug,
YEAR=1997,
NOTE="Work in progress",
ABSTRACT="The specification for the File Transfer Protocol contains a
number of mechanisms that can be used to compromise network security.
The FTP specification allows a client to instruct a server to transfer
files to a third machine. This third-party mechanism, known as proxy
FTP, causes a well known security problem. The FTP specification also
allows an unlimited number of attempts at entering a user's password.
This allows brute force 'password guessing' attacks. This document
provides suggestions for system administrators and those implementing
FTP servers that will decrease the security problems associated with
FTP.",
URL="http://www.ietf.org/internet-drafts/draft-allman-ftp-sec-consider-02.txt"
}

@TECHREPORT{draft-allman-ftp-variable,
AUTHOR="S. Ostermann and M. Allman",
TITLE="{FTP} Extensions for Variable Protocol Specification",
TYPE="Internet Draft",
HOWPUBLISHED="draft-allman-ftp-variable-05",
INSTITUTION="Internet Engineering Task Force",
MONTH=aug,
YEAR=1997,
NOTE="Work in progress",
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.",
URL="http://www.ietf.org/internet-drafts/draft-allman-ftp-variable-05.txt"
}

@TECHREPORT{draft-almesberger-srp,
AUTHOR="T. Ferrari and Jean-Yves Boudec and W. Almesberger",
TITLE="Scalable Resource Reservation for the Internet",
TYPE="Internet Draft",
HOWPUBLISHED="draft-almesberger-srp-00",
INSTITUTION="Internet Engineering Task Force",
MONTH=nov,
YEAR=1997,
NOTE="Work in progress",
ABSTRACT="Current resource reservation architectures for multimedia
networks don't scale well for a large number of flows. We propose a new
architecture that aggregates flows on each link in the network.
Therefore, the network has no knowledge of individual flows, and
resource management functions traditionally implemented in the network
(such as flow acceptance control) are delegated to hosts.",
URL="http://www.ietf.org/internet-drafts/draft-almesberger-srp-00.txt"
}

@TECHREPORT{draft-alvestrand-charset-policy,
AUTHOR="H. Alvestrand",
TITLE="{IETF} Policy on Character Sets and Languages",
TYPE="Internet Draft",
HOWPUBLISHED="draft-alvestrand-charset-policy-02",
INSTITUTION="Internet Engineering Task Force",
MONTH=oct,
YEAR=1997,
NOTE="Work in progress",
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.",
URL="http://www.ietf.org/internet-drafts/draft-alvestrand-charset-policy-02.txt"
}

@TECHREPORT{draft-apple-ldapv3-schema-wp,
AUTHOR="C. Weider and T. Howes and C. Apple and M. Wahl",
TITLE="A Minimum {LDAPv3} White Pages Schema",
TYPE="Internet Draft",
HOWPUBLISHED="draft-apple-ldapv3-schema-wp-00",
INSTITUTION="Internet Engineering Task Force",
MONTH=dec,
YEAR=1997,
NOTE="Work in progress",
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.",
URL="http://www.ietf.org/internet-drafts/draft-apple-ldapv3-schema-wp-00.txt"
}

@TECHREPORT{draft-apple-schema-file-list,
AUTHOR="C. Apple",
TITLE="Directory Schema Listing File Names",
TYPE="Internet Draft",
HOWPUBLISHED="draft-apple-schema-file-list-01",
INSTITUTION="Internet Engineering Task Force",
MONTH=nov,
YEAR=1997,
NOTE="Work in progress",
ABSTRACT="This memo specifies a file name syntax for use by the primary
listing repository operator of the directory schema listing service.",
URL="http://www.ietf.org/internet-drafts/draft-apple-schema-file-list-01.txt"
}

@TECHREPORT{draft-apple-schema-mime-metadata,
AUTHOR="C. Apple",
TITLE="Directory Schema Listing Meta Data",
TYPE="Internet Draft",
HOWPUBLISHED="draft-apple-schema-mime-metadata-00",
INSTITUTION="Internet Engineering Task Force",
MONTH=nov,
YEAR=1997,
NOTE="Work in progress",
ABSTRACT="This memo defines a MIME directory profile for content
transfer and encoding of meta data elements used for cataloging schema
listings in a directory schema listing service.",
URL="http://www.ietf.org/internet-drafts/draft-apple-schema-mime-metadata-00.txt"
}

@TECHREPORT{draft-apple-schema-rqmts-list,
AUTHOR="C. Apple",
TITLE="Directory Schema Listing Requirements",
TYPE="Internet Draft",
HOWPUBLISHED="draft-apple-schema-rqmts-list-03",
INSTITUTION="Internet Engineering Task Force",
MONTH=nov,
YEAR=1997,
NOTE="Work in progress",
ABSTRACT="This memo documents requirements for listing directory
services schema in a centrally operated, administered, and maintained
repository. This repository will be available as a resource to directory
protocol and service implementors to facilitate schema discovery.",
URL="http://www.ietf.org/internet-drafts/draft-apple-schema-rqmts-list-03.txt"
}

@TECHREPORT{draft-armitage-ion-sec-arp,
AUTHOR="G. Armitage and C. Wang",
TITLE="Security issues for the {ATMARP} protocol",
TYPE="Internet Draft",
HOWPUBLISHED="draft-armitage-ion-sec-arp-00",
INSTITUTION="Internet Engineering Task Force",
MONTH=oct,
YEAR=1997,
NOTE="Work in progress",
ABSTRACT="This document discusses some security issues associated with
IP over ATM operation. RFC1577 defines the Classic IP model for sending
IP traffic over ATM. However, security issues were not addressed in the
standard. Since internet is an open architecture, security measures to
protect network integrity are essential for normal operation. The
security loopholes in the current RFC 1577 model are analyzed and
discussed. Possible solutions are proposed.",
URL="http://www.ietf.org/internet-drafts/draft-armitage-ion-sec-arp-00.txt"
}

@TECHREPORT{draft-armitage-ion-security,
AUTHOR="G. Armitage",
TITLE="Security issues for {ION} protocols",
TYPE="Internet Draft",
HOWPUBLISHED="draft-armitage-ion-security-01",
INSTITUTION="Internet Engineering Task Force",
MONTH=oct,
YEAR=1997,
NOTE="Work in progress",
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.",
URL="http://www.ietf.org/internet-drafts/draft-armitage-ion-security-01.txt"
}

@TECHREPORT{draft-bakre-mcast-atm,
AUTHOR="T. Nishida and A. Bakre",
TITLE="{IP} Multicast over {ATM} Networks with Cut-through Forwarding for Inter
{LIS} Traffic",
TYPE="Internet Draft",
HOWPUBLISHED="draft-bakre-mcast-atm-00",
INSTITUTION="Internet Engineering Task Force",
MONTH=dec,
YEAR=1997,
NOTE="Work in progress",
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.",
URL="http://www.ietf.org/internet-drafts/draft-bakre-mcast-atm-00.txt"
}

@TECHREPORT{draft-ballardie-shared-mtrace,
AUTHOR="T. Ballardie",
TITLE="A Multicast 'traceroute' facility for Shared Trees",
TYPE="Internet Draft",
HOWPUBLISHED="draft-ballardie-shared-mtrace-00",
INSTITUTION="Internet Engineering Task Force",
MONTH=oct,
YEAR=1997,
NOTE="Work in progress",
ABSTRACT="''mtrace'' [1] is a very useful tool for diagnosing IP
multicast routing problems, such as multicast routing loops and
misconfigured multicast routers, associated with source-rooted
RPF-based distribution trees. For ''mtrace'' to be useful in a shared
tree environment (e.g. PIM [2], CBT [3], GUM [4]) its behaviour must be
modified. This draft specifies that behaviour, which is sufficiently
general to be applicable to all shared tree types and operating modes. A
new ''wildcard'' mode of behaviour is also described, which allows a
trace of a complete shared tree. Authentication is recommended in this
mode because of its potential as a vehicle for denial of service
attacks. It is intended that this draft become a document of the Mbone
Deployment (mboned) working group of the IETF. Therefore, comments are
solicited and should be sent to mboned's mailing list <mboned(at)network-
services.uoregon.edu> and/or the author.",
URL="http://www.ietf.org/internet-drafts/draft-ballardie-shared-mtrace-00.txt"
}

@TECHREPORT{draft-ballou-nntpsrch,
AUTHOR="B. Hernacki and N. Ballou",
TITLE="{NNTP} Full-text Search Extension",
TYPE="Internet Draft",
HOWPUBLISHED="draft-ballou-nntpsrch-04",
INSTITUTION="Internet Engineering Task Force",
MONTH=sep,
YEAR=1997,
NOTE="Work in progress",
ABSTRACT="This document describes a set of enhancements to the Network
News Transport Protocol [NNTP-977] that allows full-text searching of
news articles in multiple newsgroups. The proposed SEARCH command
supports functionality similar to the [IMAP4] SEARCH command, minus user
specific search keys (i.e., ANSWERED, DRAFT, FLAGGED, KEYWORD, NEW, OLD,
RECENT, SEEN) and minus search keys based on headers that do not exist
in news (i.e., CC, BCC, TO). The availability of the extensions
described here will be advertised by the server using the extension
negotiation-mechanism described in the new NNTP protocol specification
currently being developed [NNTP- NEW].",
URL="http://www.ietf.org/internet-drafts/draft-ballou-nntpsrch-04.txt"
}

@TECHREPORT{draft-bartz-hyperdrive-ldap-rbac-schema,
AUTHOR="L. Bartz",
TITLE="{LDAP} Schema for Role Based Access Control",
TYPE="Internet Draft",
HOWPUBLISHED="draft-bartz-hyperdrive-ldap-rbac-schema-00",
INSTITUTION="Internet Engineering Task Force",
MONTH=oct,
YEAR=1997,
NOTE="Work in progress",
ABSTRACT="Role Based Access Control (RBAC) is an authorization strategy
in which an entity's permission to access and manipulate targeted
resources is determined by the entity's role or function within a
certain organizational context. RBAC's principal motivation is to
streamline security policy administration. Many discrete authoriza-
tions can be aggregated within a defined role. One or many roles may be
assigned or attributed to individuals. This draft describes LDAP object
classes and attributes which support RBAC. Adoption of this schema
across multiple LDAP implementations will enable RBAC intero- perability
among heterogeneous underlying directory services.",
URL="http://www.ietf.org/internet-drafts/draft-bartz-hyperdrive-ldap-rbac-schema-00.txt"
}

@TECHREPORT{draft-berson-classy-approach,
AUTHOR="S. Berson and S. Vincent",
TITLE="Aggregation of Internet Integrated Services State",
TYPE="Internet Draft",
HOWPUBLISHED="draft-berson-classy-approach-01.txt,.ps",
INSTITUTION="Internet Engineering Task Force",
MONTH=dec,
YEAR=1997,
NOTE="Work in progress",
ABSTRACT="The Internet Integrated Services (IIS) architecture[2] has a
fundamental scaling problem in that per flow state is maintained at all
routers and end-systems supporting a flow. This paper examines the use
of aggregation as a technique to reduce the amount of state needed to
provide IIS. In our approach, routers at the edge of a region doing
aggregation keep detailed IIS state, while in the interior of this
region, routers keep a greatly reduced amount of state. Packets will be
tagged at the edge with scheduling information that will be used in
place of the detailed IIS state. The aggregation scheme described will
allow large scale deployment of IIS without overloading routers with
state and associated processing.",
URL="http://www.ietf.org/internet-drafts/draft-berson-classy-approach-01.txt,.ps"
}

@TECHREPORT{draft-bierman-entmib-compid,
AUTHOR="K. McCloghrie and A. Bierman",
TITLE="Entity {MIB} Extesions for Persistent Component Identification",
TYPE="Internet Draft",
HOWPUBLISHED="draft-bierman-entmib-compid-00",
INSTITUTION="Internet Engineering Task Force",
MONTH=aug,
YEAR=1997,
NOTE="Work in progress",
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.",
URL="http://www.ietf.org/internet-drafts/draft-bierman-entmib-compid-00.txt"
}

@TECHREPORT{draft-blake-diffserv-marking,
AUTHOR="S. Blake",
TITLE="Some Issues and Applications of Packet Marking for Differentiated Services",
TYPE="Internet Draft",
HOWPUBLISHED="draft-blake-diffserv-marking-00",
INSTITUTION="Internet Engineering Task Force",
MONTH=dec,
YEAR=1997,
NOTE="Work in progress",
ABSTRACT="''Packet marking'' is proposed as an architectural
generalization of the type of service (TOS) and precedence facilities of
IPv4 [RFC795, RFC1349], as well as the traffic class facilities of IPv6
[IPv6]. It is intended to encompass all mechanisms by which a host or a
router may mark a packet to invoke some differentiated packet handling
behavior by another node along the transit path of the packet. This memo
examines several proposed applications of a packet marking facility and
attempts to categorize each application in terms of the behavioral
requirements it imposes on hosts and routers. In addition, issues
related to the deployment of packet marking, including provisioning,
authorization, and security, are examined. This memo is proposed as a
framework to focus discussion on implementation issues and mechanisms as
new differentiated services enabled by a packet marking facility are
introduced into the Internet.",
URL="http://www.ietf.org/internet-drafts/draft-blake-diffserv-marking-00.txt"
}

@TECHREPORT{draft-briscoe-ama,
AUTHOR="M. Tatham and B. Briscoe",
TITLE="End to End Aggregation of Multicast Addresses",
TYPE="Internet Draft",
HOWPUBLISHED="draft-briscoe-ama-00.txt,.ps",
INSTITUTION="Internet Engineering Task Force",
MONTH=dec,
YEAR=1997,
NOTE="Work in progress",
ABSTRACT="This paper presents an approach for solving the inherent
problem with multicast routing scalability - by co-operation between
end-systems and the network. We introduce an extremely efficient,
elegant way to name arbitrary sized inter-meshed aggregations of
multicast addresses. This is done in such a way that it is easy to
calculate how to change the name to encompass many more related names.
We describe how these aggregate names could be used anywhere in place of
the set of addresses to which they refer, not by resolving them into
multiple operations, but by a single bulk action throughout the routing
tree, and in session descriptions potentially including those for
reservations. Initial aggregation in end-systems might only reduce the
problem by an order of magnitude, but it is believed that this will
provide sufficient structure for routers to be able to recognise further
aggregation potential. To improve the chances of router aggregation,
address set allocation schemes must fulfil certain criteria that are
laid down in this paper.",
URL="http://www.ietf.org/internet-drafts/draft-briscoe-ama-00.txt,.ps"
}

@TECHREPORT{draft-chambless-mobileip-harp,
AUTHOR="J. Binkley and B. Chambless",
TITLE="{HARP} - ''Home Agent Redundancy Protocol''",
TYPE="Internet Draft",
HOWPUBLISHED="draft-chambless-mobileip-harp-00",
INSTITUTION="Internet Engineering Task Force",
MONTH=oct,
YEAR=1997,
NOTE="Work in progress",
ABSTRACT="This document presents a protocol called the Home Agent
Redundancy Protocol or HARP. HARP is an optional extension to Mobile-IP
[RFC- 2002]. Mobile-IP includes the notion of a Home Agent which is a
host located on the home IP subnet for Mobile Nodes. Home Agents forward
packets to Mobile Nodes that are away from home. Since Mobile Nodes are
dependent on the Home Agent for connectivity when away from home, the
Home Agent represents a possible single source of failure for the Mobile
IP system. HARP is a protocol which allows a pair (or set) of Home
Agents to cooperate and share Mobile-IP Mobile Node registration
information. If one of the HARP peers should fail, the Mobile-IP system
will not necessarily fail, hence HARP introduces Home Agent redundancy
into the Mobile-IP system. Mobile Nodes are not aware that HARP exists,
so HARP requires no changes to Mobile-IP as a protocol. In this
document, we present the HARP architecture and protocol.",
URL="http://www.ietf.org/internet-drafts/draft-chambless-mobileip-harp-00.txt"
}

@TECHREPORT{draft-chuahli-mobileip-dremip,
AUTHOR="M. Chuah and Y. Li",
TITLE="Distributed Registration Extension to Mobile {IP}",
TYPE="Internet Draft",
HOWPUBLISHED="draft-chuahli-mobileip-dremip-00",
INSTITUTION="Internet Engineering Task Force",
MONTH=dec,
YEAR=1997,
NOTE="Work in progress",
ABSTRACT="This document proposes an extension to the Mobile IP base
protocol. The features in this extension allow us to (i) reduce frequent
distant registrations at the mobility agents, (ii) be more scalable by a
separation of registration and forwarding services, (iii) ease the key
management problem among mobility agents, and (iv) be interoperable with
other mobility agents/mobile nodes running standard Mobile-IP specified
in RFC2002.",
URL="http://www.ietf.org/internet-drafts/draft-chuahli-mobileip-dremip-00.txt"
}

@TECHREPORT{draft-clark-diff-svc-alloc,
AUTHOR="D. Clark and J. Wroclawski",
TITLE="An Approach to Service Allocation in the Internet",
TYPE="Internet Draft",
HOWPUBLISHED="draft-clark-diff-svc-alloc-00",
INSTITUTION="Internet Engineering Task Force",
MONTH=aug,
YEAR=1997,
NOTE="Work in progress",
ABSTRACT="This note describes the Service Allocation Profile scheme for
differential service allocation within the Internet. The scheme is based
on a simple packet drop preference mechanism at interior nodes, and
highly flexible service profiles at edges and inter- provider boundary
points within the net. The service profiles capture a wide variety of
user requirements and expectations, and allow different users to receive
different levels of service from the network in a scalable and efficient
manner. The note describes the basic form of the mechanism, discusses
the range of services that users and providers can obtain by employing
it, and gives a more detailed presentation of particular technical,
deployment, standardization, and economic issues related to its use.",
URL="http://www.ietf.org/internet-drafts/draft-clark-diff-svc-alloc-00.txt"
}

@TECHREPORT{draft-conta-ipv6-inv-nd-tun,
AUTHOR="A. Conta",
TITLE="{IPv6} Inverse Neighbor Discovery for {IPv6} and {IPv4} Tunnels",
TYPE="Internet Draft",
HOWPUBLISHED="draft-conta-ipv6-inv-nd-tun-00",
INSTITUTION="Internet Engineering Task Force",
MONTH=jul,
YEAR=1997,
NOTE="Work in progress",
ABSTRACT="This memo describes an extension mechanism to the IPv6
Neighbor Discovery and IPv6 Inverse Neighbor Discovery [IND] that
applies to IPv6 and IPv4 tunnels. The mechanism can be used to advertise
the parameters of a tunnel to its exit point node, and to create a
reverse tunnel path between the exit point and entry point nodes of a
unidirectional tunnel. If such a bidirectional tunnel already exists,
the mechanism can be used to learn the IPv6 address of the tunnel
pseudointerface of the exit-point node, as well as the reverse tunnel
path parameters.",
URL="http://www.ietf.org/internet-drafts/draft-conta-ipv6-inv-nd-tun-00.txt"
}

@TECHREPORT{draft-conta-ipv6-nd_ext_ind,
AUTHOR="A. Conta",
TITLE="{IPv6} Neighbor Discovery Extensions for Inverse Discovery Specification",
TYPE="Internet Draft",
HOWPUBLISHED="draft-conta-ipv6-nd\_ext\_ind-00",
INSTITUTION="Internet Engineering Task Force",
MONTH=aug,
YEAR=1997,
NOTE="Work in progress",
ABSTRACT="This memo describes a mechanism that can be seen as an
extension to the IPv6 Neighbor Discovery. It allows a node to solicit
and be advertized an IPv6 address corresponding to a given link-layer
address. Because the known parameter is the link layer address, the
mechanism is called Inverse Neighbor Discovery. It specifically applies
to Frame Relay nodes that may have a Data Link Connection Identifier
(DLCI), the Frame Relay equivalent of a link-layer address, associated
with an established Permanent Virtual Circuit (PVC), but do not know the
IPv6 address of the node at the other end of the circuit. It may also
apply to other networks with similar behavior.",
URL="http://www.ietf.org/internet-drafts/draft-conta-ipv6-nd\_ext\_ind-00.txt"
}

@TECHREPORT{draft-conta-ipv6-trans-fr,
AUTHOR="A. Conta and M. Mueller",
TITLE="Transmission of {IPv6} Packets over Frame Relay",
TYPE="Internet Draft",
HOWPUBLISHED="draft-conta-ipv6-trans-fr-00",
INSTITUTION="Internet Engineering Task Force",
MONTH=jul,
YEAR=1997,
NOTE="Work in progress",
ABSTRACT="This memo describes the transmission of IPv6 packets over
Frame Relay, the IPv6 Frame Relay interface token, the IPv6 Frame Relay
link local addresses, the IPv6 Frame Relay link layer Information
formatting for Neighbor Discovery.",
URL="http://www.ietf.org/internet-drafts/draft-conta-ipv6-trans-fr-00.txt"
}

@TECHREPORT{draft-conta-ipv6-trans-tunnel,
AUTHOR="A. Conta",
TITLE="Transmission of {IPv6} Packets over {IPv6} and {IPv4} Tunnels",
TYPE="Internet Draft",
HOWPUBLISHED="draft-conta-ipv6-trans-tunnel-00",
INSTITUTION="Internet Engineering Task Force",
MONTH=aug,
YEAR=1997,
NOTE="Work in progress",
ABSTRACT="This memo describes the transmission of IPv6 packets over IPv6
and IPv4 tunnels, and the IPv6 tunnel link local addresses.",
URL="http://www.ietf.org/internet-drafts/draft-conta-ipv6-trans-tunnel-00.txt"
}

@TECHREPORT{draft-conta-mpls-fr,
AUTHOR="A. Malis and A. Conta and P. Doolan",
TITLE="Use of Label Switching With Frame Relay Specification",
TYPE="Internet Draft",
HOWPUBLISHED="draft-conta-mpls-fr-01",
INSTITUTION="Internet Engineering Task Force",
MONTH=nov,
YEAR=1997,
NOTE="Work in progress",
ABSTRACT="This document defines the model and generic mechanisms for
Multiprotocol Label Switching on Frame Relay networks. A Multiprotocol
Label Switching Architecture is described in [ARCH]. MPLS enables the
use of Frame Relay Switches as Label Switching Routers (LSRs).",
URL="http://www.ietf.org/internet-drafts/draft-conta-mpls-fr-01.txt"
}

@TECHREPORT{draft-cordell-sg16-conv-url,
AUTHOR="P. Cordell",
TITLE="Conversational Multimedia {URLs}",
TYPE="Internet Draft",
HOWPUBLISHED="draft-cordell-sg16-conv-url-00",
INSTITUTION="Internet Engineering Task Force",
MONTH=dec,
YEAR=1997,
NOTE="Work in progress",
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.",
URL="http://www.ietf.org/internet-drafts/draft-cordell-sg16-conv-url-00.txt"
}

@TECHREPORT{draft-costales-subscribe,
AUTHOR="B. Costales",
TITLE="{E-Mail} Headers to Facilitate Mailing List Subscriptions and
Unsubscriptions",
TYPE="Internet Draft",
HOWPUBLISHED="draft-costales-subscribe-01",
INSTITUTION="Internet Engineering Task Force",
MONTH=aug,
YEAR=1997,
NOTE="Work in progress",
ABSTRACT="The number of ways to subscribe-to (and to unsubscribe-from)
e-mail mailing lists is as varied as the number of programmers designing
mailing list software. For some lists, for example, users (un)subscribe
by sending a request to <listname>-request(at)host.domain. For others
lists
the address is majordomo(at)host.domain with the request to (un)subscribe
embedded in the message body. Yet others set up special hosts to satisfy
this need, such as <listname>(at)list-off.domain. In this Internet Draft
we
offer two new e-mail headers intended to make mailing list subscription
and unsubscription easier and more uniform: List-Subscribe and
List-Unsubscribe.",
URL="http://www.ietf.org/internet-drafts/draft-costales-subscribe-01.txt"
}

@TECHREPORT{draft-davie-mpls-explicit-routes,
AUTHOR="B. Davie and T. Li and Y. Rekhter and E. Rosen",
TITLE="Explicit Route Support in {MPLS}",
TYPE="Internet Draft",
HOWPUBLISHED="draft-davie-mpls-explicit-routes-00",
INSTITUTION="Internet Engineering Task Force",
MONTH=nov,
YEAR=1997,
NOTE="Work in progress",
ABSTRACT="We define an `explicit route' as a route which is explicitly
specified as a sequence of hops rather than being determined solely by
conventional routing algorithms on a hop by hop basis. Using the
explicit route object proposed for use in RSVP [1] and the ability to
bind MPLS labels to RSVP flows [2] we describe how explicit routes may
be set up in an MPLS environment. The resulting label switched paths may
have associated resource reservations, or may be purely best effort.",
URL="http://www.ietf.org/internet-drafts/draft-davie-mpls-explicit-routes-00.txt"
}

@TECHREPORT{draft-davie-mpls-rsvp,
AUTHOR="B. Davie and Y. Rekhter and E. Rosen and A. Viswanathan and C. Srinivasan",
TITLE="Use of Label Switching With {RSVP}",
TYPE="Internet Draft",
HOWPUBLISHED="draft-davie-mpls-rsvp-01",
INSTITUTION="Internet Engineering Task Force",
MONTH=nov,
YEAR=1997,
NOTE="Work in progress",
ABSTRACT="Multiprotocol Label Switching (MPLS) allows labels to be bound
to various granularities of forwarding information, including
application flows. In this document we present a specification for
allocating and binding labels to RSVP flows, and to distributing the
appropriate binding information using RSVP messages.",
URL="http://www.ietf.org/internet-drafts/draft-davie-mpls-rsvp-01.txt"
}

@TECHREPORT{draft-demchenko-koi8-ru,
AUTHOR="Y. Demchenko",
TITLE="Registration of a Ukrainian Cyrillic Character Set {KOI8-RU} (as extension
to Russian {KOI8-R} and {ISO-IR-111)}",
TYPE="Internet Draft",
HOWPUBLISHED="draft-demchenko-koi8-ru-00",
INSTITUTION="Internet Engineering Task Force",
MONTH=nov,
YEAR=1997,
NOTE="Work in progress",
ABSTRACT="This document provides information about widely used in
Ukrainian Internet community (including Ukraine and worldwide Ukrainian
speaking community)character set for mail and news exchange as well as
for presentation WWW information resources in Ukrainian language.
''KOI8-RU'' (KOI8 Russian and Ukrainian) summarises and completes
de-facto standard koi8-u accepted by all Ukrainian community in the
Internet and unofficially published at many sites. KOI8-RU is compatible
with KOI8-R (RFC 1489) in all Cyrillic Letters and completes it with
four Ukrainian letters which locations are complaint with ISO-IR-111.
KOI8-RU should be registered to support and facilitate general and
cultural information content development and dissemination. Support of
Ukrainian language in new software product is restrained by absent of
officially registered and widely published de-facto used Ukrainian
charset.",
URL="http://www.ietf.org/internet-drafts/draft-demchenko-koi8-ru-00.txt"
}

@TECHREPORT{draft-demizu-mpls-atm-svc,
AUTHOR="N. Demizu and H. Esaki and K. Nagami and P. Doolan",
TITLE="{ATM} {SVC} Support for {ATM-LSRs}",
TYPE="Internet Draft",
HOWPUBLISHED="draft-demizu-mpls-atm-svc-00",
INSTITUTION="Internet Engineering Task Force",
MONTH=oct,
YEAR=1997,
NOTE="Work in progress",
ABSTRACT="Several label switching schemes have been proposed to fuse and
integrate Layer 2 and Layer 3. ATM Label Switching Router (ATM-LSR) is
one of the major applications of label switching. Some ATM-LSRs will
need to support ATM SVC services, which requires signaling to establish
VCs before employing them and to release VCs after utilizing them. This
document proposes procedures to deal with ATM SVCs between ATM-LSRs.",
URL="http://www.ietf.org/internet-drafts/draft-demizu-mpls-atm-svc-00.txt"
}

@TECHREPORT{draft-demizu-mpls-vcid,
AUTHOR="N. Demizu and H. Esaki and K. Nagami and P. Doolan",
TITLE="Virtual Connection Identifier",
TYPE="Internet Draft",
HOWPUBLISHED="draft-demizu-mpls-vcid-01",
INSTITUTION="Internet Engineering Task Force",
MONTH=oct,
YEAR=1997,
NOTE="Work in progress",
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.",
URL="http://www.ietf.org/internet-drafts/draft-demizu-mpls-vcid-01.txt"
}

@TECHREPORT{draft-demizu-mpls-vcpool,
AUTHOR="N. Demizu and H. Esaki and K. Nagami and P. Doolan",
TITLE="{VC} Pool",
TYPE="Internet Draft",
HOWPUBLISHED="draft-demizu-mpls-vcpool-00",
INSTITUTION="Internet Engineering Task Force",
MONTH=oct,
YEAR=1997,
NOTE="Work in progress",
ABSTRACT="Several label switching schemes have been proposed to fuse and
integrate Layer 2 and Layer 3. They can be applied to various datalinks
including intermittent links such as ATM SVC. Intermittent links require
signaling to establish VCs before employing them and to release VCs
after utilizing them. Because signaling often introduces delays and
costs, some kind of optimization is necessary. This document proposes to
introduce a VC pool to reduce the delays and the costs of signaling.",
URL="http://www.ietf.org/internet-drafts/draft-demizu-mpls-vcpool-00.txt"
}

@TECHREPORT{draft-demizu-udlr-dtcp,
AUTHOR="N. Demizu and H. Izumiyama",
TITLE="Dynamic Tunnel Configuration Protocol",
TYPE="Internet Draft",
HOWPUBLISHED="draft-demizu-udlr-dtcp-00",
INSTITUTION="Internet Engineering Task Force",
MONTH=dec,
YEAR=1997,
NOTE="Work in progress",
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.",
URL="http://www.ietf.org/internet-drafts/draft-demizu-udlr-dtcp-00.txt"
}

@TECHREPORT{draft-denninger-ipv6number,
AUTHOR="K. Denninger",
TITLE="{IPV6} {NUMBER} {ASSIGNMENT} {PROTOCOL} Rev {0.1}",
TYPE="Internet Draft",
HOWPUBLISHED="draft-denninger-ipv6number-00",
INSTITUTION="Internet Engineering Task Force",
MONTH=nov,
YEAR=1997,
NOTE="Work in progress",
ABSTRACT="This memorandum shall be entitled ''IPV6 NUMBER ASSIGNMENT
PROTOCOL'', and describes a proposed policy, procedure and control
structure for the allocation of IPV6 Internet addresses. This memorandum
discusses the issues surrounding IPV6 numbering on a hierarchial
structure and overview. It also presents, where possible and relevant,
justification for the positions expressed in this paper. Distribution is
unlimited and comments are invited.",
URL="http://www.ietf.org/internet-drafts/draft-denninger-ipv6number-00.txt"
}

@TECHREPORT{draft-duerst-dns-i18n,
AUTHOR="M. Duerst",
TITLE="Internationalization of Domain Names",
TYPE="Internet Draft",
HOWPUBLISHED="draft-duerst-dns-i18n-02",
INSTITUTION="Internet Engineering Task Force",
MONTH=jul,
YEAR=1997,
NOTE="Work in progress",
ABSTRACT="Internet domain names are currently limited to a very
restricted character set. This document proposes the introduction of a
new 'zero-level' domain (ZLD) to allow the use of arbitrary characters
from the Universal Character Set (ISO 10646/Unicode) in domain names.
The proposal is fully backwards compatible and does not need any changes
to DNS. Version 02 is reissued without changes just to keep this draft
available.",
URL="http://www.ietf.org/internet-drafts/draft-duerst-dns-i18n-02.txt"
}

@TECHREPORT{draft-duerst-query-i18n,
AUTHOR="M. Duerst",
TITLE="Handling Internationalized Query Components in {URLs}",
TYPE="Internet Draft",
HOWPUBLISHED="draft-duerst-query-i18n-00",
INSTITUTION="Internet Engineering Task Force",
MONTH=jul,
YEAR=1997,
NOTE="Work in progress",
ABSTRACT="HTTP and HTML provide the facility to query the user and
return the results. This is usually done in the query component of an
URL. This mechanisms works with full satisfaction for characters of the
us- ascii repertoire. Due to the lack of an agreed encoding for other
characters, the situation is much less satisfactory for characters
outside the us-ascii repertoire.",
URL="http://www.ietf.org/internet-drafts/draft-duerst-query-i18n-00.txt"
}

@TECHREPORT{draft-durand-ipv6-traceroute,
AUTHOR="A. Durand",
TITLE="{IPv6} traceroute option",
TYPE="Internet Draft",
HOWPUBLISHED="draft-durand-ipv6-traceroute-00",
INSTITUTION="Internet Engineering Task Force",
MONTH=nov,
YEAR=1997,
NOTE="Work in progress",
ABSTRACT="The traceroute program has proven very useful and has been
extensively used in the Internet for measurement and debugging purposes.
However, it only shows the originator to target path and gives no
indication on the reverse path. Source routing may sometimes be used to
find it, but it's very often disable by intermediary routers. Another
problem occurs when packets do not follow the same routes: traceroute
outputs are very difficult to read. Other solutions has been proposed to
record the route taken by an IPv4 packet. Originally, IPv4 contains an
option in which every intermediary router can add its address [RFC791].
Unfortunately, the limitation in size imposed by the options design of
IPv4 limits its use to 9 routers. In [RFC1393] another strategy was
proposed. An new IPv4 option was created. When a router receives a
packet containing this option, it generates a ICMP Echo message to the
source. This technique couldn't be widely deployed in IPv4 because it
needed a change in every single router to be efficient. These two
methods create less traffic on the network and are more accurate, since
they give the real route taken by packets and are less sensitive to
fluttering. The IPv6 deployment could be the opportunity to widely
deploy a new traceroute mechanism based on those two methods. We propose
to combine the two previous methods by defining a new hop-by-hop option
and a new ICMP message type to record the direct path from the
originator to the target and the reverse path from the target to the
originator.",
URL="http://www.ietf.org/internet-drafts/draft-durand-ipv6-traceroute-00.txt"
}

@TECHREPORT{draft-dusse-smime-cert,
AUTHOR="S. Dusse and P. Hoffman and J. Weinstein and B. Ramsdell",
TITLE="{S/MIME} Version 2 Certificate Handling",
TYPE="Internet Draft",
HOWPUBLISHED="draft-dusse-smime-cert-06",
INSTITUTION="Internet Engineering Task Force",
MONTH=nov,
YEAR=1997,
NOTE="Work in progress",
ABSTRACT="S/MIME (Secure/Multipurpose Internet Mail Extensions),
described in [SMIME-MSG], provides a method to send and receive secure
MIME messages. In order to validate the keys of a message sent to it, an
S/MIME agent needs to certify that the key is valid. This draft
describes the mechanisms S/MIME uses to create and validate keys using
certificates. This specification is compatible with PKCS #7 in that it
uses the data types defined by PKCS #7. It also inherits all the
varieties of architectures for certificate-based key management
supported by PKCS #7. Note that the method S/MIME messages make
certificate requests is defined in [SMIME-MSG].",
URL="http://www.ietf.org/internet-drafts/draft-dusse-smime-cert-06.txt"
}

@TECHREPORT{draft-dusse-smime-msg,
AUTHOR="S. Dusse and L. Lundblade and P. Hoffman and L. Repka and B. Ramsdell",
TITLE="{S/MIME} Version 2 Message Specification",
TYPE="Internet Draft",
HOWPUBLISHED="draft-dusse-smime-msg-07",
INSTITUTION="Internet Engineering Task Force",
MONTH=nov,
YEAR=1997,
NOTE="Work in progress",
ABSTRACT="S/MIME (Secure/Multipurpose Internet Mail Extensions) provides
a consistent way to send and receive secure MIME data. Based on the
popular Internet MIME standard, S/MIME provides the following
cryptographic security services for electronic messaging applications:
authentication, message integrity and non-repudiation of origin (using
digital signatures) and privacy and data security (using encryption).
S/MIME can be used by traditional mail user agents (MUAs) to add
cryptographic security services to mail that is sent, and to interpret
cryptographic security services in mail that is received. However,
S/MIME is not restricted to mail; it can be used with any transport
mechanism that transports MIME data, such as HTTP. As such, S/MIME takes
advantage of the object-based features of MIME and allows secure
messages to be exchanged in mixed-transport systems. Further, S/MIME can
be used in automated message transfer agents that use cryptographic
security services that do not require any human intervention, such as
the signing of software-generated documents and the encryption of FAX
messages sent over the Internet. Please note: The information in this
document is historical material being published for the public record.
It is not an IETF standard. The use of the word ''standard'' in this
document indicates a standard for adopters of S/MIME version 2, not an
IETF standard.",
URL="http://www.ietf.org/internet-drafts/draft-dusse-smime-msg-07.txt"
}

@TECHREPORT{draft-earhart-url-smtp,
AUTHOR="R. Earhart",
TITLE="An {SMTP} {URL} Interface",
TYPE="Internet Draft",
HOWPUBLISHED="draft-earhart-url-smtp-00",
INSTITUTION="Internet Engineering Task Force",
MONTH=dec,
YEAR=1997,
NOTE="Work in progress",
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.",
URL="http://www.ietf.org/internet-drafts/draft-earhart-url-smtp-00.txt"
}

@TECHREPORT{draft-eastlake-local-names,
AUTHOR="D. Eastlake",
TITLE="Local {DNS} Names",
TYPE="Internet Draft",
HOWPUBLISHED="draft-eastlake-local-names-00",
INSTITUTION="Internet Engineering Task Force",
MONTH=aug,
YEAR=1997,
NOTE="Work in progress",
ABSTRACT="A set of second level domain names are defined under a new top
level domain name such that local private DNS zones can be maintained
similar to the private IP addresses reserved in RFC 1918 but which
locally appear to be part of the global DNS name tree.",
URL="http://www.ietf.org/internet-drafts/draft-eastlake-local-names-00.txt"
}

@TECHREPORT{draft-ellesson-tos,
AUTHOR="E. Ellesson and S. Blake",
TITLE="A Proposal for the Format and Semantics of the {TOS} Byte and Traffic Class
Byte in {IPv4} and {IPv6} Headers",
TYPE="Internet Draft",
HOWPUBLISHED="draft-ellesson-tos-00",
INSTITUTION="Internet Engineering Task Force",
MONTH=dec,
YEAR=1997,
NOTE="Work in progress",
ABSTRACT="This draft proposes an arrangement of fields in the IPv4 TOS
byte [RFC795, RFC1349], and in the IPv6 Traffic Class byte [IPv6], and
proposes a definition for their associated semantics. The intention is
to enable the preservation of currently useful differential class- based
queueing behavior on existing network devices, while simultaneously
enabling new methods of bandwidth allocation and policing via drop
preference, all within the context of flows which may be encrypted at
the IP layer using IPSEC. (Note: the IPv6 Class field has recently been
expanded to eight bits, but this in not yet available in any version of
the specification).",
URL="http://www.ietf.org/internet-drafts/draft-ellesson-tos-00.txt"
}

@TECHREPORT{draft-ema-vpimdir-schema,
AUTHOR="A. Brown",
TITLE="{VPIM} Directory Schema Definition and Profile",
TYPE="Internet Draft",
HOWPUBLISHED="draft-ema-vpimdir-schema-00",
INSTITUTION="Internet Engineering Task Force",
MONTH=nov,
YEAR=1997,
NOTE="Work in progress",
ABSTRACT="One use of a directory service is the retrieval of
information, such as email address and spoken name, to support voice
messsaging. This document defines the directory schema required for an
X.500/LDAP-based directory service for use by applications supporting
Voice Profile for Internet Mail [VPIM2]. The directory service is
intended to assist the exchange of voice messages between voice
messaging systems. Interaction with desktop applications is outside the
scope of this draft. Some schema elements defined herin may be of more
general use than just for voice messaging. They are included here
because they are not defined elsewhere. It is anticipated that the next
version of this schema will only reference such definitions if they get
defined in more appropriate areas. This schema will be used to support a
pilot VPIM directory service based on X.500 93 and LDAPv2. This next
version of the schema will support X.500 97 and LDAPv3.",
URL="http://www.ietf.org/internet-drafts/draft-ema-vpimdir-schema-00.txt"
}

@TECHREPORT{draft-engan-ip-compress,
AUTHOR="S. Casner and C. Bormann and M. Engan",
TITLE="{IP} Header Compression over {PPP}",
TYPE="Internet Draft",
HOWPUBLISHED="draft-engan-ip-compress-02",
INSTITUTION="Internet Engineering Task Force",
MONTH=dec,
YEAR=1997,
NOTE="Work in progress",
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.]",
URL="http://www.ietf.org/internet-drafts/draft-engan-ip-compress-02.txt"
}

@TECHREPORT{draft-feldman-ldp-spec,
AUTHOR="N. Feldman and P. Doolan and L. Andersson and A. Fredette",
TITLE="{LDP} Specification",
TYPE="Internet Draft",
HOWPUBLISHED="draft-feldman-ldp-spec-00",
INSTITUTION="Internet Engineering Task Force",
MONTH=dec,
YEAR=1997,
NOTE="Work in progress",
ABSTRACT="An overview of Multi Protocol Label Switching (MPLS) is
provided in [FRAMEWORK] and a proposed architecture in [ARCH]. A
fundamental concept in MPLS is that two Label Switching Routers (LSRs)
must agree on the meaning of the labels used to forward traffic between
and through them. This common understanding is achieved by using the
Label Distribution Protocol (LDP) referenced in [FRAMEWORK] and [ARCH].
This document defines the LDP protocol.",
URL="http://www.ietf.org/internet-drafts/draft-feldman-ldp-spec-00.txt"
}

@TECHREPORT{draft-ferguson-ingress-filtering,
AUTHOR="P. Ferguson and D. Senie",
TITLE="Defeating Denial of Service Attacks which employ {IP} Source Address
Spoofing",
TYPE="Internet Draft",
HOWPUBLISHED="draft-ferguson-ingress-filtering-03",
INSTITUTION="Internet Engineering Task Force",
MONTH=oct,
YEAR=1997,
NOTE="Work in progress",
ABSTRACT="Recent occurrences of various Denial of Service (DoS) attacks
which have employed forged source addresses have proven to be a
troublesome issue for Internet Service Providers and the Internet
community overall. This paper discusses a simple, effective, and
straightforward method for using ingress traffic filtering to prohibit
DoS attacks which use forged IP addresses to be propagated from 'behind'
an Internet Service Provider's (ISP) aggregation point.",
URL="http://www.ietf.org/internet-drafts/draft-ferguson-ingress-filtering-03.txt"
}

@TECHREPORT{draft-ferguson-pppsonet-selfsync,
AUTHOR="D. Ferguson and R. Cherukuri",
TITLE="{Self-Synchronous} Scramblers For {PPP} Over {Sonet/SDH:} Some Analysis",
TYPE="Internet Draft",
HOWPUBLISHED="draft-ferguson-pppsonet-selfsync-00",
INSTITUTION="Internet Engineering Task Force",
MONTH=nov,
YEAR=1997,
NOTE="Work in progress",
ABSTRACT="The use of a self-synchronous scrambler to minimize the
possibility that a carefully chosen PPP over SONET/SDH payload can cause
a long sequence of zero bits to be transmitted is examined. It is
pointed out that, while self-synchronous scramblers have some attractive
properties for the application, the x^43 + 1 scrambler used by ATM for
the same purpose has some unfortunate interactions with the 16-bit CRC
Frame Check Sequence which is the PPP default FCS. It is suggested that
adding a third term to the self-synchronous generator polynomial might
improve its behaviour, and that inverting the scrambler bit ordering so
it is applied to the data in the same bit order as the PPP CRC FCS
algorithms are defined for may eliminate any remaining effect such
scramblers have on either PPP FCS.",
URL="http://www.ietf.org/internet-drafts/draft-ferguson-pppsonet-selfsync-00.txt"
}

@TECHREPORT{draft-fielding-url-syntax,
AUTHOR="T. Berners-Lee and L. Masinter and R. Fielding",
TITLE="Generic Syntax and Semantics",
TYPE="Internet Draft",
HOWPUBLISHED="draft-fielding-url-syntax-09",
INSTITUTION="Internet Engineering Task Force",
MONTH=oct,
YEAR=1997,
NOTE="Work in progress",
ABSTRACT="A Uniform Resource Locator (URL) is a compact string
representation of a location for use in identifying an abstract or
physical resource. This document defines the general syntax and
semantics of URLs, including both absolute and relative locators, and
guidelines for their use; it revises and replaces the generic
definitions in RFC 1738 and RFC 1808.",
URL="http://www.ietf.org/internet-drafts/draft-fielding-url-syntax-09.txt"
}

@TECHREPORT{draft-fleischman-asf-rtp-record,
AUTHOR="A. Klemets and E. Fleischman",
TITLE="Recording {MBone} Sessions to {ASF} Files",
TYPE="Internet Draft",
HOWPUBLISHED="draft-fleischman-asf-rtp-record-00",
INSTITUTION="Internet Engineering Task Force",
MONTH=nov,
YEAR=1997,
NOTE="Work in progress",
ABSTRACT="This document specifies two approaches by which multimedia
data (e.g., MBone conferences), transmitted using the Real-Time Protocol
(RTP), may be recorded to Advanced Streaming Format (ASF) files. The
first method requires a minimum amount of buffering at the recording
station but results in recordings which identically preserve the
received content including out of order packets, network ''jitter'',
etc. The second approach requires buffering at the recording station but
results in enhanced recordings (i.e., higher percentage of correctly
ordered packets, elimination of a percentage of received jitter,
potential recovery of a percentage of lost packets). Both approaches
record all received RTP content and the relevant subset of RTCP
information. This recording occurs transparently to the MBone conference
or RTP session, and does not involve any alterations to normal RTP,
RTCP, or ASF use.",
URL="http://www.ietf.org/internet-drafts/draft-fleischman-asf-rtp-record-00.txt"
}

@TECHREPORT{draft-fredette-mpls-aggregation,
AUTHOR="P. Doolan and L. Andersson and A. Fredette and C. White",
TITLE="Stream Aggregation",
TYPE="Internet Draft",
HOWPUBLISHED="draft-fredette-mpls-aggregation-00",
INSTITUTION="Internet Engineering Task Force",
MONTH=dec,
YEAR=1997,
NOTE="Work in progress",
ABSTRACT="This document describes issues with aggregating streams of
data in an MPLS system and suggests alternatives for increasing the
level of aggregation possible.",
URL="http://www.ietf.org/internet-drafts/draft-fredette-mpls-aggregation-00.txt"
}

@TECHREPORT{draft-freed-charset-reg,
AUTHOR="J. Postel and N. Freed",
TITLE="{IANA} Charset Registration Procedures",
TYPE="Internet Draft",
HOWPUBLISHED="draft-freed-charset-reg-04",
INSTITUTION="Internet Engineering Task Force",
MONTH=sep,
YEAR=1997,
NOTE="Work in progress",
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.",
URL="http://www.ietf.org/internet-drafts/draft-freed-charset-reg-04.txt"
}

@TECHREPORT{draft-freed-firewall-req,
AUTHOR="N. Freed and K. Carosso",
TITLE="An Internet Firewall Transparency Requirement",
TYPE="Internet Draft",
HOWPUBLISHED="draft-freed-firewall-req-02",
INSTITUTION="Internet Engineering Task Force",
MONTH=dec,
YEAR=1997,
NOTE="Work in progress",
ABSTRACT="This memo defines a basic transparency requirement for
Internet firewalls. While such a requirement may seem obvious, the fact
of the matter is that firewall behavior is currently either unspecified
or underspecified, and this lack of specificity often causes problems in
practice. This requirement is intended to be a necessary first step in
making the behavior of firewalls more consistent and correct.",
URL="http://www.ietf.org/internet-drafts/draft-freed-firewall-req-02.txt"
}

@TECHREPORT{draft-fritsche-ipv6-multicast,
AUTHOR="W. Fritsch and H. Seifert",
TITLE="Dynamical routing (unicast and multicast) for the Ipv6 protocol",
TYPE="Internet Draft",
HOWPUBLISHED="draft-fritsche-ipv6-multicast-02",
INSTITUTION="Internet Engineering Task Force",
MONTH=nov,
YEAR=1997,
NOTE="Work in progress",
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.",
URL="http://www.ietf.org/internet-drafts/draft-fritsche-ipv6-multicast-02.txt"
}

@TECHREPORT{draft-gahrns-imap-namespace,
AUTHOR="C. Newman and M. Gahrns",
TITLE="{IMAP4} Namespace",
TYPE="Internet Draft",
HOWPUBLISHED="draft-gahrns-imap-namespace-07",
INSTITUTION="Internet Engineering Task Force",
MONTH=dec,
YEAR=1997,
NOTE="Work in progress",
ABSTRACT="IMAP4[RFC-2060] does not define a default server namespace. As
a result, two common namespace models have evolved: The ''Personal
Mailbox'' model, in which the default namespace that is presented
consists of only the user's personal mailboxes. To access shared
mailboxes, the user must use an escape mechanism to reach another
namespace. The ''Complete Hierarchy'' model, in which the default
namespace that is presented includes the user's personal mailboxes along
with any other mailboxes they have access to. These two models, create
difficulties for certain client operations. This document defines a
NAMESPACE command that allows a client to discover the prefixes of
namespaces used by a server for personal mailboxes, other users'
mailboxes, and shared mailboxes. This allows a client to avoid much of
the manual user configuration that is now necessary when mixing and
matching IMAP4 clients and servers.",
URL="http://www.ietf.org/internet-drafts/draft-gahrns-imap-namespace-07.txt"
}

@TECHREPORT{draft-glenn-dns-dir,
AUTHOR="G. Mansfield and K. Ohta and T. Ika",
TITLE="A Directory for organizations and services from {DNS} and {WHOIS.}",
TYPE="Internet Draft",
HOWPUBLISHED="draft-glenn-dns-dir-00",
INSTITUTION="Internet Engineering Task Force",
MONTH=nov,
YEAR=1997,
NOTE="Work in progress",
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
from the Domain Name System (DNS) and the WHOIS servers is described in
this memo.",
URL="http://www.ietf.org/internet-drafts/draft-glenn-dns-dir-00.txt"
}

@TECHREPORT{draft-gray-mpls-generic-ldp-spec,
AUTHOR="G. Armitage and Z. Wang and E. Gray",
TITLE="Generic Label Distribution Protocol Specification",
TYPE="Internet Draft",
HOWPUBLISHED="draft-gray-mpls-generic-ldp-spec-00",
INSTITUTION="Internet Engineering Task Force",
MONTH=nov,
YEAR=1997,
NOTE="Work in progress",
ABSTRACT="This document describes the specification of generic Label
Distribution Protocol (LDP) for Multi-Protocol Label Switching (MPLS).
Its purpose is to define those parts of LDP that are media/technology
independent. Other documents, both existing works in progress and yet to
come, will describe specifics of MPLS protocol behavior that apply to a
particular media or technology.",
URL="http://www.ietf.org/internet-drafts/draft-gray-mpls-generic-ldp-spec-00.txt"
}

@TECHREPORT{draft-haas-zone-routing-protocol,
AUTHOR="Z. Haas and M. Pearlman",
TITLE="The Zone Routing Protocol {(ZRP)} for Ad Hoc Networks",
TYPE="Internet Draft",
HOWPUBLISHED="draft-haas-zone-routing-protocol-00",
INSTITUTION="Internet Engineering Task Force",
MONTH=nov,
YEAR=1997,
NOTE="Work in progress",
ABSTRACT="This document describes a routing protocol for ad hoc
networks. In particular, it is suitable for highly versatile networks,
characterized by large range of nodal mobilities and large network
diameters. The protocol is a hybrid of a proactive and a reactive
schemes, allowing adjustment of its operation to the current network
operational conditions.",
URL="http://www.ietf.org/internet-drafts/draft-haas-zone-routing-protocol-00.txt"
}

@TECHREPORT{draft-handley-aap,
AUTHOR="M. Handley",
TITLE="Multicast Address Allocation Protocol {(AAP)}",
TYPE="Internet Draft",
HOWPUBLISHED="draft-handley-aap-00.txt,.ps",
INSTITUTION="Internet Engineering Task Force",
MONTH=dec,
YEAR=1997,
NOTE="Work in progress",
ABSTRACT="The document defines a Multicast Address Allocation Protocol
(AAP) that forms a part of a larger multicast address allocation
architecture currently being defined. AAP addresses the specific issue
of intra-domain multicast address allocation between multicast address
allocation servers.",
URL="http://www.ietf.org/internet-drafts/draft-handley-aap-00.txt,.ps"
}

@TECHREPORT{draft-handley-malloc-arch,
AUTHOR="D. Estrin and M. Handley and D. Thaler",
TITLE="The Internet Multicast Address Allocation Architecture",
TYPE="Internet Draft",
HOWPUBLISHED="draft-handley-malloc-arch-00.txt,.ps",
INSTITUTION="Internet Engineering Task Force",
MONTH=dec,
YEAR=1997,
NOTE="Work in progress",
ABSTRACT="This document proposes a multicast address allocation
architecture for the Internet. The architecture is three layered,
comprising a client->server protocol, an intra- domain protocol and an
inter-domain protocol.",
URL="http://www.ietf.org/internet-drafts/draft-handley-malloc-arch-00.txt,.ps"
}

@TECHREPORT{draft-harada-http-xconnfrom,
AUTHOR="J. Mogul and P. Leach and L. Harada and H. Hendren",
TITLE="{HTTP} {X-Connfrom} header",
TYPE="Internet Draft",
HOWPUBLISHED="draft-harada-http-xconnfrom-00",
INSTITUTION="Internet Engineering Task Force",
MONTH=jul,
YEAR=1997,
NOTE="Work in progress",
ABSTRACT="HTTP/1.1 defines a Connection header, allowing 'the sender to
specify options that are desired for that particular connection and MUST
NOT be communicated by proxies over further connections.' Because
HTTP/1.0 proxies would normally forward the Connection header without
obeying its specification, a Connection header received in an HTTP/1.0
message must normally be treated as if it had been forwarded in error.
This document defines an X-Connfrom header that identifies the sending
host, and so is safe to use in HTTP/1.0 messages. This might be useful
in experimenting with HTTP/1.0 implementations of applications of the
HTTP/1.1 Connection mechanism.",
URL="http://www.ietf.org/internet-drafts/draft-harada-http-xconnfrom-00.txt"
}

@TECHREPORT{draft-heffernan-bgp-tcp-md5,
AUTHOR="A. Heffernan",
TITLE="Protection of {BGP} Sessions via the {TCP} {MD5} Signature Option",
TYPE="Internet Draft",
HOWPUBLISHED="draft-heffernan-bgp-tcp-md5-00",
INSTITUTION="Internet Engineering Task Force",
MONTH=dec,
YEAR=1997,
NOTE="Work in progress",
ABSTRACT="This memo describes a TCP extension to enhance security for
BGP. It defines a new TCP option for carrying an MD5 [RFC1321] digest in
a TCP segment. This digest acts like a signature for that segment,
incorporating information known only to the connection end points. Since
BGP uses TCP as its transport, using this option in the way described in
this paper significantly reduces the danger from certain security
attacks on BGP. This document specifies an experimental protocol for use
in the Internet.",
URL="http://www.ietf.org/internet-drafts/draft-heffernan-bgp-tcp-md5-00.txt"
}

@TECHREPORT{draft-heinanen-diff-tos-octet,
AUTHOR="J. Heinanen",
TITLE="Use of the {IPv4} {TOS} Octet to Support Differential Services",
TYPE="Internet Draft",
HOWPUBLISHED="draft-heinanen-diff-tos-octet-01",
INSTITUTION="Internet Engineering Task Force",
MONTH=dec,
YEAR=1997,
NOTE="Work in progress",
ABSTRACT="This document describes how the TOS octet in the IPv4 header
can be used to support differential Internet services. The proposal is
based on the existing format of the TOS octet as defined in [RFC791] and
[RFC1349].",
URL="http://www.ietf.org/internet-drafts/draft-heinanen-diff-tos-octet-01.txt"
}

@TECHREPORT{draft-hodges-ldap-dir-dn-reqs,
AUTHOR="J. Hodges",
TITLE="Requirements for Distinguished Names in Autonomous to Loosely-coupled
{LDAP-based} Directory Services",
TYPE="Internet Draft",
HOWPUBLISHED="draft-hodges-ldap-dir-dn-reqs-00",
INSTITUTION="Internet Engineering Task Force",
MONTH=oct,
YEAR=1997,
NOTE="Work in progress",
ABSTRACT="This document analyzes the issues involved in the
Distinguished Name- spaces of autonomous to loosely-coupled, LDAP-based
directory services (LLDSs). It folds in experience learned from the
global X.500-based Dis- tinguished Name-space, and proposes requirements
for the construction of Distinguished Names for LLDSs of varying scopes.",
URL="http://www.ietf.org/internet-drafts/draft-hodges-ldap-dir-dn-reqs-00.txt"
}

@TECHREPORT{draft-hoffman-pkcs-certif-req,
AUTHOR="B. Kaliski",
TITLE="Certification Request Syntax Version {1.5}",
TYPE="Internet Draft",
HOWPUBLISHED="draft-hoffman-pkcs-certif-req-03",
INSTITUTION="Internet Engineering Task Force",
MONTH=oct,
YEAR=1997,
NOTE="Work in progress",
ABSTRACT="This document describes a syntax for certification requests.",
URL="http://www.ietf.org/internet-drafts/draft-hoffman-pkcs-certif-req-03.txt"
}

@TECHREPORT{draft-hoffman-pkcs-crypt-msg,
AUTHOR="B. Kaliski",
TITLE="Cryptographic Message Syntax Version {1.5}",
TYPE="Internet Draft",
HOWPUBLISHED="draft-hoffman-pkcs-crypt-msg-03",
INSTITUTION="Internet Engineering Task Force",
MONTH=oct,
YEAR=1997,
NOTE="Work in progress",
ABSTRACT="This document describes a general syntax for data that may
have cryptography applied to it, such as digital signatures and digital
envelopes. The syntax admits recursion, so that, for example, one
envelope can be nested inside another, or one party can sign some
previously enveloped digital data. It also allows arbitrary attributes,
such as signing time, to be authenticated along with the content of a
message, and provides for other attributes such as countersignatures to
be associated with a signature. A degenerate case of the syntax provides
a means for disseminating certificates and certificate-revocation lists.",
URL="http://www.ietf.org/internet-drafts/draft-hoffman-pkcs-crypt-msg-03.txt"
}

@TECHREPORT{draft-hoffman-pkcs-rsa-encrypt,
AUTHOR="B. Kaliski",
TITLE="{RSA} Encryption Version {1.5}",
TYPE="Internet Draft",
HOWPUBLISHED="draft-hoffman-pkcs-rsa-encrypt-03",
INSTITUTION="Internet Engineering Task Force",
MONTH=oct,
YEAR=1997,
NOTE="Work in progress",
ABSTRACT="This document describes a method for encrypting data using the
RSA public-key cryptosystem.",
URL="http://www.ietf.org/internet-drafts/draft-hoffman-pkcs-rsa-encrypt-03.txt"
}

@TECHREPORT{draft-hopmann-mimedirxml,
AUTHOR="A. Hopmann",
TITLE="Conversion of {MIMEDIR} content into {XML}",
TYPE="Internet Draft",
HOWPUBLISHED="draft-hopmann-mimedirxml-00",
INSTITUTION="Internet Engineering Task Force",
MONTH=jul,
YEAR=1997,
NOTE="Work in progress",
ABSTRACT="This document specifies how to translate information which is
represented in the MIMEDIR format into a representation of the identical
information using the XML syntax. Using this specification, applications
which have been designed to understand MIMEDIR formatted data should be
able to interoperate using XML representations of the same schemas.",
URL="http://www.ietf.org/internet-drafts/draft-hopmann-mimedirxml-00.txt"
}

@TECHREPORT{draft-housley-smime-cms,
AUTHOR="R. Housley",
TITLE="Cryptographic Message Syntax",
TYPE="Internet Draft",
HOWPUBLISHED="draft-housley-smime-cms-00",
INSTITUTION="Internet Engineering Task Force",
MONTH=oct,
YEAR=1997,
NOTE="Work in progress",
ABSTRACT="This document describes the Cryptographic Message Syntax. This
syntax is used to digitally sign or encrypt arbitrary messages. The
Cryptographic Message Syntax is deriveded from PKCS #7 version 1.5.
Wherever possible, backward compatibility is preserved; however, changes
were necessary to accomodate attribute certificate transfer and key
agreement techniques for key management. Please send comments on this
document to the ietf-smime(at)imc.com mail list.",
URL="http://www.ietf.org/internet-drafts/draft-housley-smime-cms-00.txt"
}

@TECHREPORT{draft-howalter-sieve,
AUTHOR="Tim Showalter",
TITLE="{SIEVE:} A Mail Filtering Language",
TYPE="Internet Draft",
HOWPUBLISHED="draft-howalter-sieve-00",
INSTITUTION="Internet Engineering Task Force",
MONTH=apr,
YEAR=1997,
NOTE="Work in progress",
KEYWORDS="email; filtering",
ABSTRACT="This document describes a mail filtering language for
filtering messages at time of final delivery. It is designed to be
independent of protocol, and implementable on either a mail client or
mail server which uses multiple folders. It is meant to be extensible,
simple, and independent of access protocol, mail architecture, and
operating systems used to implement it. Mail filtering systems are
widely used for a variety of reasons, including organization of messages
(filtering out mailing list messages for separate reading). They are
becoming increasingly useful in avoiding unsolicited mail. Existing
languages are not consistant across client, server, or operating system,
and are frequently difficult for users to use. This language is not tied
to any particular system or mail architecture and is suitable for
running on a mail server where users may not be allowed to execute
arbitrary programs, such as on black box IMAP servers.",
URL="http://www.ietf.org/internet-drafts/draft-howalter-sieve-00.txt"
}

@TECHREPORT{draft-iab-secwks-report,
AUTHOR="S. Bellovin",
TITLE="Report of the {IAB} Security Architecture Workshop",
TYPE="Internet Draft",
HOWPUBLISHED="draft-iab-secwks-report-00",
INSTITUTION="Internet Engineering Task Force",
MONTH=nov,
YEAR=1997,
NOTE="Work in progress",
ABSTRACT="On 3-5 March 1997, the IAB held a security architecture
workshop at Bell Labs in Murray Hill, NJ. We identified the core
security components of the architecture, and specified several documents
that need to be written. Most importantly, we agreed that security was
not optional, and that it needed to be designed in from the beginning.",
URL="http://www.ietf.org/internet-drafts/draft-iab-secwks-report-00.txt"
}

@TECHREPORT{draft-iab-wgannounce,
AUTHOR="B. Carpenter",
TITLE="Improved Working Group Coordination",
TYPE="Internet Draft",
HOWPUBLISHED="draft-iab-wgannounce-00",
INSTITUTION="Internet Engineering Task Force",
MONTH=oct,
YEAR=1997,
NOTE="Work in progress",
ABSTRACT="This is a proposal for a pragmatic way to improve working
group coordination between various standards-related organisations, by
use of a shared mailing list for early announcement of new activities.",
URL="http://www.ietf.org/internet-drafts/draft-iab-wgannounce-00.txt"
}

@TECHREPORT{draft-ietf-aft-mcast-fw-traversal,
AUTHOR="D. Chouinard",
TITLE="{SOCKS} {V5} {UDP} and Multicast Extensions to Facilitate Multicast
Firewall Traversal",
TYPE="Internet Draft",
HOWPUBLISHED="draft-ietf-aft-mcast-fw-traversal-01",
INSTITUTION="Internet Engineering Task Force",
MONTH=nov,
YEAR=1997,
NOTE="Work in progress",
ABSTRACT="This proposal creates a mechanism for managing the ingress or
egress of IP multicast through a firewall. It does this by defining
extensions to the existing SOCKS V5 protocol [RFC-1928], which provides
a framework for doing user-level, authenticated firewall traversal of
unicast TCP and UDP traffic. However, because the current UDP support in
SOCKS V5 has scalability problems as well as other deficiencies -- and
these need to be addressed before multicast support can be achieved --
the extensions are defined in two parts: Base-level UDP extensions, and
Multicast UDP extensions. Using the SOCKS framework for managing
multicast flows in/out of an organization, offers numerous security
advantages over what is possible with a conventional firewall approach.
These are spelled out in the draft.",
URL="http://www.ietf.org/internet-drafts/draft-ietf-aft-mcast-fw-traversal-01.txt"
}

@TECHREPORT{draft-ietf-aft-socks-multiple-traversal,
AUTHOR="M. Kayashima and T. Ogino and M. Terada and Y. Fujiyama",
TITLE="{SOCKS} {V5} Protocol extension for Multiple Firewalls Traversal",
TYPE="Internet Draft",
HOWPUBLISHED="draft-ietf-aft-socks-multiple-traversal-00",
INSTITUTION="Internet Engineering Task Force",
MONTH=nov,
YEAR=1997,
NOTE="Work in progress",
ABSTRACT="This document provides the extended specification of SOCKS
Version 5 which enable to use multiple firewalls traversal. In this
protocol, client does subnegotiation with all servers on the
communication path, and each server relays the connection after
subnegotiation.",
URL="http://www.ietf.org/internet-drafts/draft-ietf-aft-socks-multiple-traversal-00.txt"
}

@TECHREPORT{draft-ietf-applmib-sysapplmib,
AUTHOR="J. Saperia and C. Krupczak",
TITLE="Definitions of {System-Level} Managed Objects for Applications",
TYPE="Internet Draft",
HOWPUBLISHED="draft-ietf-applmib-sysapplmib-09",
INSTITUTION="Internet Engineering Task Force",
MONTH=oct,
YEAR=1997,
NOTE="Work in progress",
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 a basic set of managed objects
for fault, configuration and performance management of applications from
a systems perspective. More specifically, the managed objects are
restricted to information that can be determined from the system itself
and which does not require special instrumentation within the
applications to make the information available. This memo does not
specify a standard for the Internet community.",
URL="http://www.ietf.org/internet-drafts/draft-ietf-applmib-sysapplmib-09.txt"
}

@TECHREPORT{draft-ietf-asid-inetorgperson,
AUTHOR="M. Smith",
TITLE="Definition of the {inetOrgPerson} Object Class",
TYPE="Internet Draft",
HOWPUBLISHED="draft-ietf-asid-inetorgperson-01",
INSTITUTION="Internet Engineering Task Force",
MONTH=aug,
YEAR=1997,
NOTE="Work in progress",
ABSTRACT="While the X.500 standards [X500] define many useful attribute
types and object classes, they do not define a person object class that
meets the requirements found in today's Internet and Intranet directory
service deployments. We define a new object class called inetOrgPerson
that extends the X.521 standard organizationalPerson class to meet these
needs.",
URL="http://www.ietf.org/internet-drafts/draft-ietf-asid-inetorgperson-01.txt"
}

@TECHREPORT{draft-ietf-asid-ldap-cache,
AUTHOR="T. Howes and L. Howard",
TITLE="A Simple Caching Scheme for {LDAP} and {X.500} Directories",
TYPE="Internet Draft",
HOWPUBLISHED="draft-ietf-asid-ldap-cache-01",
INSTITUTION="Internet Engineering Task Force",
MONTH=oct,
YEAR=1997,
NOTE="Work in progress",
ABSTRACT="This memo defines an object class and attribute type in
support of a simple caching mechanism for use in LDAP and X.500
directories. The object class allows a simple 'time-to-live' attribute
to be included in entries, enabling clients retrieving the attribute to
tell when the other information they have retrieved from the entry
should be thrown away. The use of this scheme does not preclude the
subsequent or additional use of other more complicated schemes, for
example, allowing different TTLs on individual attributes.",
URL="http://www.ietf.org/internet-drafts/draft-ietf-asid-ldap-cache-01.txt"
}

@TECHREPORT{draft-ietf-asid-ldap-dynatt,
AUTHOR="T. Genovese and M. Wahl and Y. Yaacovi",
TITLE="Dynamic Attributes",
TYPE="Internet Draft",
HOWPUBLISHED="draft-ietf-asid-ldap-dynatt-01",
INSTITUTION="Internet Engineering Task Force",
MONTH=nov,
YEAR=1997,
NOTE="Work in progress",
ABSTRACT="This document defines dynamic attributes and the fashion in
which they are being set and used on entries in the directory. This
document builds heavily on the dynamic extensions to LDAP infrastructure
as defined in [1]. The Lightweight Directory Access Protocol (LDAP) [2]
supports lightweight access to static directory services, allowing
relatively fast search and update access. Static directory services
store information about people that persists in its accuracy and value
over a long period of time. The dynamic extension to LDAP as defined in
[1] added the concept of dynamic entries that only persist in the
directory, when they are periodically refreshed. This document takes
this approach one step farther and defines how dynamic attributes can be
used, on either static or dynamic entries, to handle up-to-date and
dynamic information about an entry in the directory. An example use will
be a client or a person that has a static entry in the directory and
sometimes goes online, which is reflected in the 'online' attribute for
the entry. To specify whether this person is online or offline - an
attribute that changes frequently, a client application will have to
modify this attribute relatively frequently. The current location of a
person is another attribute that may change frequently. Dynamic
attributes must be periodically refreshed. Otherwise, they will
disappear from the directory over time.",
URL="http://www.ietf.org/internet-drafts/draft-ietf-asid-ldap-dynatt-01.txt"
}

@TECHREPORT{draft-ietf-asid-ldap-java-api,
AUTHOR="T. Howes and M. Smith and R. Weltman",
TITLE="The Java {LDAP} Application Program Interface",
TYPE="Internet Draft",
HOWPUBLISHED="draft-ietf-asid-ldap-java-api-01",
INSTITUTION="Internet Engineering Task Force",
MONTH=sep,
YEAR=1997,
NOTE="Work in progress",
ABSTRACT="This document defines a java language application program
interface to the lightweight directory access protocol (LDAP), in the
form of a class library. It complements but does not replace RFC 1823
([9]), which describes a C language application program interface. It
updates and replaces draft-ietf-asid-ldap-java-api-00.txt [13], in
adding clarifica- tion on behavior under various circumstances, and in
revising support for language-sensitive attribute parsing. Other
additions and correc- tions are listed in the appendix.",
URL="http://www.ietf.org/internet-drafts/draft-ietf-asid-ldap-java-api-01.txt"
}

@TECHREPORT{draft-ietf-asid-ldap-java-controls,
AUTHOR="R. Weltman",
TITLE="Java {LDAP} Controls",
TYPE="Internet Draft",
HOWPUBLISHED="draft-ietf-asid-ldap-java-controls-00",
INSTITUTION="Internet Engineering Task Force",
MONTH=sep,
YEAR=1997,
NOTE="Work in progress",
ABSTRACT="This document defines support for the Preferred Language
Control, the Server Sorting Control, and the Virtual List Control in the
java LDAP API. Controls are an LDAP protocol version 3 extension, to
allow pass- ing arbitrary control information along with a standard
request to a server, and to receive arbitrary information back with a
standard result.",
URL="http://www.ietf.org/internet-drafts/draft-ietf-asid-ldap-java-controls-00.txt"
}

@TECHREPORT{draft-ietf-asid-ldap-mult-mast-rep,
AUTHOR="C. Weider and B. Huston and J. Strassner",
TITLE="{LDAP} {Multi-Master} Replication Protocol",
TYPE="Internet Draft",
HOWPUBLISHED="draft-ietf-asid-ldap-mult-mast-rep-02",
INSTITUTION="Internet Engineering Task Force",
MONTH=nov,
YEAR=1997,
NOTE="Work in progress",
ABSTRACT="This paper defines a multi-master, incremental replication
protocol using the LDAP protocol [LDAPv3]. This protocol uses and builds
upon previous LDAP support protocols, namely the changelog [change] and
LDIF [LDIF] protocols. It defines the use of two types of transport
protocols for replication data, and specifies the schema that must be
supported by a server that wishes to participate in replication
activities using this protocol. In addition, it specifies a conflict
resolution mechanism for integrating updates from multiple servers.",
URL="http://www.ietf.org/internet-drafts/draft-ietf-asid-ldap-mult-mast-rep-02.txt"
}

@TECHREPORT{draft-ietf-asid-ldap-repl-info,
AUTHOR="G. Good",
TITLE="Schema for Replication Information",
TYPE="Internet Draft",
HOWPUBLISHED="draft-ietf-asid-ldap-repl-info-01",
INSTITUTION="Internet Engineering Task Force",
MONTH=oct,
YEAR=1997,
NOTE="Work in progress",
ABSTRACT="This document defines a new attribute syntax and an
operational attribute type to store replication agreements within the
directory. In addition it defines a framework to detect whether an entry
is a master or replica. The replication agreement structure defined here
includes a placeholder to specify the replication protocol associated
with an agreement. This document itself does not define any replication
protocol. Replication protocols and replication agreements are seen as
orthogonal issues.",
URL="http://www.ietf.org/internet-drafts/draft-ietf-asid-ldap-repl-info-01.txt"
}

@TECHREPORT{draft-ietf-asid-ldapv3-attributes,
AUTHOR="S. Kille and T. Howes and M. Wahl and A. Coulbeck",
TITLE="Attribute Syntax Definitions",
TYPE="Internet Draft",
HOWPUBLISHED="draft-ietf-asid-ldapv3-attributes-08",
INSTITUTION="Internet Engineering Task Force",
MONTH=oct,
YEAR=1997,
NOTE="Work in progress",
ABSTRACT="The Lightweight Directory Access Protocol (LDAP) [1] requires
that the contents of AttributeValue fields in protocol elements be octet
strings. This document defines a set of syntaxes for LDAPv3, and the
rules by which attribute values of these syntaxes are represented as
octet strings for transmission in the LDAP protocol. The syntaxes
defined in this document are referenced by this and other documents that
define attribute types. This document also defines the set of attribute
types which LDAP servers should support.",
URL="http://www.ietf.org/internet-drafts/draft-ietf-asid-ldapv3-attributes-08.txt"
}

@TECHREPORT{draft-ietf-asid-ldapv3-dn,
AUTHOR="S. Kille and T. Howes and M. Wahl",
TITLE="{UTF-8} String Representation of Distinguished Names",
TYPE="Internet Draft",
HOWPUBLISHED="draft-ietf-asid-ldapv3-dn-04",
INSTITUTION="Internet Engineering Task Force",
MONTH=nov,
YEAR=1997,
NOTE="Work in progress",
ABSTRACT="The X.500 Directory uses distinguished names as the primary
keys to entries in the directory. Distinguished Names are encoded in
ASN.1 in the X.500 Directory protocols. In the Lightweight Directory
Access Protocol, a string representation of distinguished names is
transferred. This specification defines the string format for
representing names, which is designed to give a clean representation of
commonly used distinguished names, while being able to represent any
distinguished name.",
URL="http://www.ietf.org/internet-drafts/draft-ietf-asid-ldapv3-dn-04.txt"
}

@TECHREPORT{draft-ietf-asid-ldapv3-radius,
AUTHOR="B. Aboba",
TITLE="Schema for the Remote Access Dialin User Service {(RADIUS)}",
TYPE="Internet Draft",
HOWPUBLISHED="draft-ietf-asid-ldapv3-radius-00",
INSTITUTION="Internet Engineering Task Force",
MONTH=nov,
YEAR=1997,
NOTE="Work in progress",
ABSTRACT="This document defines a schema for the Remote Access Dialin
User Service (RADIUS). This schema makes it possible to integrate a
RADIUS server with an LDAP-based directory service, making it possible
for an organization to maintain a single store of user information. This
consolidation is desirable since it results in a reduction in the
administrative workload, and eliminates the need to synchronize across
multiple user information stores.",
URL="http://www.ietf.org/internet-drafts/draft-ietf-asid-ldapv3-radius-00.txt"
}

@TECHREPORT{draft-ietf-asid-replica-req,
AUTHOR="E. Stokes and R. Weiser and B. Huston",
TITLE="{LDAP} Replication Requirements",
TYPE="Internet Draft",
HOWPUBLISHED="draft-ietf-asid-replica-req-01",
INSTITUTION="Internet Engineering Task Force",
MONTH=nov,
YEAR=1997,
NOTE="Work in progress",
ABSTRACT="This document discusses the fundamental requirements for
replication of the LDAPv3 [LDAPv3] protocol. It is intended to be a
gathering place for general replication requirements needed to provide
interoperability between informational directories.",
URL="http://www.ietf.org/internet-drafts/draft-ietf-asid-replica-req-01.txt"
}

@TECHREPORT{draft-ietf-asid-rwhois,
AUTHOR="S. Williamson and M. Mealling and M. Kosters",
TITLE="Referral Whois Protocol {(RWhois)} {2.0}",
TYPE="Internet Draft",
HOWPUBLISHED="draft-ietf-asid-rwhois-00",
INSTITUTION="Internet Engineering Task Force",
MONTH=jul,
YEAR=1997,
NOTE="Work in progress",
ABSTRACT="This memo describes Version 2.0 of the client/server
interaction of RWhois. RWhois provides a distributed system for the
display of hierarchical and non-hierarchical information. This system is
primarily hierarchical by design, allowing for the deterministic
reduction of a query and the referral of the user closer to the
maintainer of the information. It also identifies the attributes that
are non-hierarchical so that they may be indexed into a mesh.",
URL="http://www.ietf.org/internet-drafts/draft-ietf-asid-rwhois-00.txt"
}

@TECHREPORT{draft-ietf-avt-byerecon,
AUTHOR="J. Rosenberg and Henning Schulzrinne",
TITLE="New Results in {RTP} Scalability",
TYPE="Internet Draft",
HOWPUBLISHED="draft-ietf-avt-byerecon-00.txt,http://www.ietf.org/internet-drafts/draft-ietf-avt-byerecon-00.txt.ps",
INSTITUTION="Internet Engineering Task Force",
MONTH=dec,
YEAR=1997,
NOTE="Work in progress",
ABSTRACT="Recently, a number of problems related to RTP scalability to
large multicast groups have been identified. The main problem,
congestion of RTCP packets due to near-simultaneous joins, has been
resolved in previous work. In this document, we present some additional
problems and describe the solutions. In particular, we discuss the
problem of BYE floods and premature timeouts. To resolve the BYE flood
problem, we propose a BYE reconsideration mechanism. To help alleviate
prema- ture timeouts, we propose a reverse timer reconsideration
algorithm. Both algorithms are simple, and require minimal state and
computa- tion.",
URL="http://www.ietf.org/internet-drafts/draft-ietf-avt-byerecon-00.txt,http://www.ietf.org/internet-drafts/draft-ietf-avt-byerecon-00.txt.ps"
}

@TECHREPORT{draft-ietf-avt-mpeg-new,
AUTHOR="D. Hoffman and G. Fernando and V. Goyal and R. Civanlar",
TITLE="{RTP} Payload Format for {MPEG1/MPEG2} Video",
TYPE="Internet Draft",
HOWPUBLISHED="draft-ietf-avt-mpeg-new-02",
INSTITUTION="Internet Engineering Task Force",
MONTH=nov,
YEAR=1997,
NOTE="Work in progress",
ABSTRACT="This memo describes a packetization scheme for MPEG video and
audio streams. The scheme proposed can be used to transport such a video
or audio flow over the transport protocols supported by RTP. Two
approaches are described. The first is designed to support maximum
interoperability with MPEG System environments. The second is designed
to provide maximum compatibility with other RTP-encapsulated media
streams and future conference control work of the IETF. This memo is a
revision of RFC 2038, an Internet standards track pro- tocol, prepared
for publication as a revised RFC. In this revision, the packet loss
resilience mechanisms in Section 3.4 were extended to include additional
picture header information required for MPEG2. A new section on security
considerations for this payload type is added.",
URL="http://www.ietf.org/internet-drafts/draft-ietf-avt-mpeg-new-02.txt"
}

@TECHREPORT{draft-ietf-avt-reconsider,
AUTHOR="Jonathan Rosenberg and Henning Schulzrinne",
TITLE="Timer Reconsideration for Enhanced {RTP} Scalability",
TYPE="Internet Draft",
HOWPUBLISHED="draft-ietf-avt-reconsider-00.ps",
INSTITUTION="Internet Engineering Task Force",
MONTH=jul,
YEAR=1997,
NOTE="Work in progress",
KEYWORDS="RTP; RTCP; scaling; reconsideration",
ABSTRACT="RTP, the Real Time Transport Protocol, has gained widespread
acceptance as the transport protocol for voice and video on the
Internet. It provides services such as timestamping, sequence numbering,
and payload identification. It also contains a control component, the
Real Time Control Protocol (RTCP), which is used for loose session
control, QoS reporting, and media synchronization, among other
functions. The RTP specification describes an algorithm for determining
the RTCP packet transmission rate at a host participating in a multicast
RTP session. This algorithm was designed to allow RTP to be used in
sessions with anywhere from one to a million members. However, we have
discovered several problems with this algorithm when used with very
large groups with rapidly changing group membership. One problem is the
flood of RTCP packets which occurs when many users join a multicast RTP
session at nearly the same time. To solve this problem, we present a
novel adaptive timer algorithm called reconsideration. We present a
mathematical analysis of this algorithm, and demonstrate that it
performs extremely well, reducing the congestion problem by several
orders of magnitude. We also back up these results with simulation.",
URL="http://www.ietf.org/internet-drafts/draft-ietf-avt-reconsider-00.ps"
}

@TECHREPORT{draft-ietf-bmwg-ippm-delay,
AUTHOR="G. Almes and S. Kalidindi",
TITLE="A One-way Delay Metric for {IPPM}",
TYPE="Internet Draft",
HOWPUBLISHED="draft-ietf-bmwg-ippm-delay-02",
INSTITUTION="Internet Engineering Task Force",
MONTH=aug,
YEAR=1997,
NOTE="Work in progress",
ABSTRACT="This memo defines a metric for one-way delay of packets across
Inter- net paths. It builds on notions introduced and discussed in the
IPPM Framework document (currently 'Framework for IP Provider Metrics'
<draft-ietf-bmwg-ippm-framework-01.txt>); the reader is assumed to be
familiar with that document. This memo is intended to be very parallel
in structure to a companion document for Packet Loss ('A Packet Loss
Metric for IPPM' <draft- ietf-bmwg-ippm-loss-01.txt>). + A 'singleton'
analytic metric, called Type-P-One-way-Delay, will be introduced to
measure a single observation of one-way delay. + Using this singleton
metric, a 'sample', called Type-P-One-way- Delay-Stream, will be
introduced to measure a sequence of single- ton delays measured at times
taken from a Poisson process. + Using this sample, several 'statistics'
of the sample will be defined and discussed. This progression from
singleton to sample to statistics, with clear separation among them, is
important. Whenever a technical term from the IPPM Framework document is
first used in this memo, it will be tagged with a trailing asterisk, as
with >>term*<<.",
URL="http://www.ietf.org/internet-drafts/draft-ietf-bmwg-ippm-delay-02.txt"
}

@TECHREPORT{draft-ietf-bmwg-ippm-treno-btc,
AUTHOR="M. Mathis",
TITLE="Empirical Bulk Transfer Capacity",
TYPE="Internet Draft",
HOWPUBLISHED="draft-ietf-bmwg-ippm-treno-btc-01",
INSTITUTION="Internet Engineering Task Force",
MONTH=aug,
YEAR=1997,
NOTE="Work in progress",
ABSTRACT="Bulk Transport Capacity (BTC) is a measure of a network's
ability to transfer significant quantities of data with a single
congestion-aware transport connection (e.g. state-of-the-art TCP). For
many applications the BTC of the underlying network dominates the the
overall elapsed time for the application, and thus dominates the
performance as perceived by a user. The BTC is a property of an IP cloud
(links, routers, switches, etc) between a pair of hosts. It does not
include the hosts themselves (or their transport-layer software).
However, congestion control is crucial to the BTC metric because the
Internet depends on the end systems to fairly divide the available
bandwidth on the basis of common congestion behavior. The BTC metric is
based on the performance of a reference congestion control algorithm
that has particularly uniform and stable behavior.",
URL="http://www.ietf.org/internet-drafts/draft-ietf-bmwg-ippm-treno-btc-01.txt"
}

@TECHREPORT{draft-ietf-calsch-mod,
AUTHOR="J. Noerenberg",
TITLE="Internet Calendar Model Specification",
TYPE="Internet Draft",
HOWPUBLISHED="draft-ietf-calsch-mod-03",
INSTITUTION="Internet Engineering Task Force",
MONTH=nov,
YEAR=1997,
NOTE="Work in progress",
ABSTRACT="Internet Calendaring and Scheduling protocols require the
definition of objects to encapsulate an event to be scheduled, a
calendar on which the event will be stored, and means for exchanging
these objects across the Internet between calendars on behalf of people
for whom the calendars are meaningful. This document gives an abstract
model of the objects and the protocols necessary to accomplish this kind
of information exchange. It will establish the context in which other
Calendaring and Scheduling RFCs can be interpreted. Included are brief
introductions to the other components of Internet calendar protocols and
definitions of nomenclature common to all documents defining these
protocols. Reading this document will enable implementors and users of
Internet Calendaring and Scheduling protocols to understand the goals
and constraints chosen for related protocols.",
URL="http://www.ietf.org/internet-drafts/draft-ietf-calsch-mod-03.txt"
}

@TECHREPORT{draft-ietf-cat-kerberos-anoncred,
AUTHOR="J. Cargille and M. Hur and A. Medvinsky",
TITLE="Anonymous Credentials in Kerberos",
TYPE="Internet Draft",
HOWPUBLISHED="draft-ietf-cat-kerberos-anoncred-00",
INSTITUTION="Internet Engineering Task Force",
MONTH=sep,
YEAR=1997,
NOTE="Work in progress",
ABSTRACT="This document defines the concept of anonymous Kerberos
credentials, and describes how such credentials can be securely obtained
from a Kerberos KDC via the PKINIT extension. This draft defines no new
mechanisms or protocols; instead, it defines the concepts and proposes
usage and naming conventions.",
URL="http://www.ietf.org/internet-drafts/draft-ietf-cat-kerberos-anoncred-00.txt"
}

@TECHREPORT{draft-ietf-cat-krb5-firewalls,
AUTHOR="A. Westerlund and J. Danielsson",
TITLE="Kerberos vs firewalls",
TYPE="Internet Draft",
HOWPUBLISHED="draft-ietf-cat-krb5-firewalls-00",
INSTITUTION="Internet Engineering Task Force",
MONTH=dec,
YEAR=1997,
NOTE="Work in progress",
ABSTRACT="Kerberos[RFC1510] is a protocol for authenticating parties
communicating over insecure networks. Firewalling is a technique for
achieving an illusion of security by putting restrictions on what kinds
of packets and how these are sent between the internal (so called
''secure'') network and the global (or ''insecure'') Internet.",
URL="http://www.ietf.org/internet-drafts/draft-ietf-cat-krb5-firewalls-00.txt"
}

@TECHREPORT{draft-ietf-cat-krb5-ipv6,
AUTHOR="A. Westerlund",
TITLE="Kerberos over {IPv6}",
TYPE="Internet Draft",
HOWPUBLISHED="draft-ietf-cat-krb5-ipv6-00",
INSTITUTION="Internet Engineering Task Force",
MONTH=oct,
YEAR=1997,
NOTE="Work in progress",
ABSTRACT="This document specifies the address types and transport types
necessary for using Kerberos [RFC1510] over IPv6 [RFC1883].",
URL="http://www.ietf.org/internet-drafts/draft-ietf-cat-krb5-ipv6-00.txt"
}

@TECHREPORT{draft-ietf-cat-krb5-tcp,
AUTHOR="A. Westerlund and J. Danielsson",
TITLE="Kerberos over {TCP}",
TYPE="Internet Draft",
HOWPUBLISHED="draft-ietf-cat-krb5-tcp-00",
INSTITUTION="Internet Engineering Task Force",
MONTH=nov,
YEAR=1997,
NOTE="Work in progress",
ABSTRACT="This document specifies how the communication should be done
between a client and a KDC using Kerberos [RFC1510] with TCP as the
transport protocol.",
URL="http://www.ietf.org/internet-drafts/draft-ietf-cat-krb5-tcp-00.txt"
}

@TECHREPORT{draft-ietf-cat-user2user,
AUTHOR="M. Swift",
TITLE="User to User Kerberos Authentication using {GSS-API}",
TYPE="Internet Draft",
HOWPUBLISHED="draft-ietf-cat-user2user-02",
INSTITUTION="Internet Engineering Task Force",
MONTH=dec,
YEAR=1997,
NOTE="Work in progress",
ABSTRACT="This draft proposes a simple extension to the Kerberos GSS-API
mechanism to support user to user authentication both in the case where
the client application explicitly requests user to user authentication
and when it does not know whether the server supports user to user
authentication.",
URL="http://www.ietf.org/internet-drafts/draft-ietf-cat-user2user-02.txt"
}

@TECHREPORT{draft-ietf-dhc-interserver,
AUTHOR="R. Droms and R. Cole and K. Kinnear",
TITLE="An Inter-server Protocol for {DHCP}",
TYPE="Internet Draft",
HOWPUBLISHED="draft-ietf-dhc-interserver-02",
INSTITUTION="Internet Engineering Task Force",
MONTH=aug,
YEAR=1997,
NOTE="Work in progress",
ABSTRACT="The DHCP protocol is designed to allow for multiple DHCP
servers, so that reliability of DHCP service can be improved through the
use of redundant servers. To provide redundant service, multiple DHCP
servers must carry the same information about assigned IP addresses and
parameters; i.e., the servers must be configured with the same bindings.
Because DHCP servers may dynamically assign new addresses or
configuration parameters, or extend the lease on an existing address
assignment, the bindings on some servers may become out of date. The
DHCP inter-server protocol provides an automatic mechanism for
synchronization of the bindings stored on a set of cooperating DHCP
servers. The underlying capabilities of the DHCP inter-server protocol
required for multiple server cache replications are based upon the
Server Cache Synchronization Protocol (SCSP).",
URL="http://www.ietf.org/internet-drafts/draft-ietf-dhc-interserver-02.txt"
}

@TECHREPORT{draft-ietf-dhc-mdhcp,
AUTHOR="B. Patel and M. Shah",
TITLE="Multicast address allocation extensions to the Dynamic Host Configuration
Protocol",
TYPE="Internet Draft",
HOWPUBLISHED="draft-ietf-dhc-mdhcp-03",
INSTITUTION="Internet Engineering Task Force",
MONTH=nov,
YEAR=1997,
NOTE="Work in progress",
ABSTRACT="The Dynamic Host Configuration Protocol (DHCP) provides a
framework for passing configuration information to hosts on a TCP/IP
network. The multicast extensions to DHCP add additional capability of
dynamic allocation of the multicast addresses and additional
configuration options.",
URL="http://www.ietf.org/internet-drafts/draft-ietf-dhc-mdhcp-03.txt"
}

@TECHREPORT{draft-ietf-dhc-securing-dhc,
AUTHOR="B. Patel",
TITLE="Securing {DHCP}",
TYPE="Internet Draft",
HOWPUBLISHED="draft-ietf-dhc-securing-dhc-00",
INSTITUTION="Internet Engineering Task Force",
MONTH=jul,
YEAR=1997,
NOTE="Work in progress",
ABSTRACT="This proposal describes methods of securing DHCP based on IETF
DHCP and IPSEC protocols. This protocol achieves security goals for DHCP
client and servers without having to define a new security protocol.
Instead, it first bootstraps the DHCP client in un-trusted mode using
existing DHCP protocol and then proceeds to secure configuration of the
client using existing DHCP and IP protocol features.",
URL="http://www.ietf.org/internet-drafts/draft-ietf-dhc-securing-dhc-00.txt"
}

@TECHREPORT{draft-ietf-dhc-security-arch,
AUTHOR="O. Gudmundsson",
TITLE="Security Architecture for {DHCP}",
TYPE="Internet Draft",
HOWPUBLISHED="draft-ietf-dhc-security-arch-01",
INSTITUTION="Internet Engineering Task Force",
MONTH=aug,
YEAR=1997,
NOTE="Work in progress",
ABSTRACT="This document addresses the general security requirements of
both v4 and v6 versions of DHCP. This document lists security
requirements and proposes as security model, which meets scaling
requirements, security requirements and efficiency requirements. The
proposed security model uses public key cryptography and a proposed
trusted key distribution mechanism to authenticate clients and servers.
The authentication protocol can also exchange keying material for more
efficiently protecting successive communication between client and
server. The security model also addresses securing relay agents.",
URL="http://www.ietf.org/internet-drafts/draft-ietf-dhc-security-arch-01.txt"
}

@TECHREPORT{draft-ietf-dhc-subsel,
AUTHOR="P. Gupta and W. Townsley",
TITLE="Subnet Selection Option for {DHCP}",
TYPE="Internet Draft",
HOWPUBLISHED="draft-ietf-dhc-subsel-00",
INSTITUTION="Internet Engineering Task Force",
MONTH=jul,
YEAR=1997,
NOTE="Work in progress",
ABSTRACT="The Subnet Selections option is provided by a DHCP client to
DHCP a server as an indication to which subnet or subnets to select an
address from for the client's lease. When present, the DHCP server will
use this value as an indication to which configured subnet pool of
addresses to select from, effectively divorcing the giaddr of its
overloaded subnet selection function for a packet forwarded by a DHCP
relay agent. The giaddr is retains its function as the address for the
DHCP server to send replies to. An application for this new option would
be to allow a Network Access Server (NAS) acting as DHCP proxy on behalf
of a large number of dial-in users to obtain an address that is in the
desired subnet(s) for the dial users without having to configure
multiple giaddr values at the NAS, or requiring the NAS to utilize an
address within each subnet.",
URL="http://www.ietf.org/internet-drafts/draft-ietf-dhc-subsel-00.txt"
}

@TECHREPORT{draft-ietf-dnsind-dns-error,
AUTHOR="O. Gudmundsson and R. Watson",
TITLE="Error Record {(ERR)} for {DNS}",
TYPE="Internet Draft",
HOWPUBLISHED="draft-ietf-dnsind-dns-error-00",
INSTITUTION="Internet Engineering Task Force",
MONTH=jul,
YEAR=1997,
NOTE="Work in progress",
ABSTRACT="The DNS protocol defines a 4-bit RCODE field in the header of
the DNS envelope. This field is used to indicate the completion status
of requests. Defined values exist to describe successful completion as
well as a variety of error conditions that could result from DNS server
operations. As DNS has been expanded to perform additional functions,
the number of possible error conditions has increased significantly, and
the field no longer has space for new error codes to be added. To
address this problem, a new RR type is defined. The Error Record
contains a machine-readable extended error value, as well as an optional
human-readable ASCII text string. Additionally, it contains a
domain-name source field to identify the entity generating the error
condition. This RR may also be used in non- error conditions to provide
extended information about server responses, such as security
information on specific records in the response.",
URL="http://www.ietf.org/internet-drafts/draft-ietf-dnsind-dns-error-00.txt"
}

@TECHREPORT{draft-ietf-dnssec-ar,
AUTHOR="R. Watson",
TITLE="{DNSsec} Authentication Referral Record {(AR)}",
TYPE="Internet Draft",
HOWPUBLISHED="draft-ietf-dnssec-ar-00",
INSTITUTION="Internet Engineering Task Force",
MONTH=nov,
YEAR=1997,
NOTE="Work in progress",
ABSTRACT="Authentication Referrals allow DNS to refer to authentication
mechanisms that supplement or replace the KEY RRs of DNSsec. Five
Authentication Service types are defined: DNSsec, Kerberos IV, Kerberos
V, Network Information Service (NIS+), and Radius.",
URL="http://www.ietf.org/internet-drafts/draft-ietf-dnssec-ar-00.txt"
}

@TECHREPORT{draft-ietf-dnssec-as-map,
AUTHOR="D. Eastlake",
TITLE="Mapping Autonomous Systems Number into the Domain Name System",
TYPE="Internet Draft",
HOWPUBLISHED="draft-ietf-dnssec-as-map-05",
INSTITUTION="Internet Engineering Task Force",
MONTH=aug,
YEAR=1997,
NOTE="Work in progress",
ABSTRACT="One requirement of secure routing is that independent routing
entities, such as those identified by Internet Autonomous System
Numbers, be able to authenticate messages to each other. Additions have
developed to the Domain Name System to enable it to be used for
authenticated public key distribution [RFC 2065]. This draft maps all
Autonomous System numbers into DNS Domain Names so that the DNS security
can be used to distribute their public keys. [Changes from previous
version are to accommodate AS numbers larger than 16 bits and to
delegate on decimal boundaries rather than binary boundaries.]",
URL="http://www.ietf.org/internet-drafts/draft-ietf-dnssec-as-map-05.txt"
}

@TECHREPORT{draft-ietf-dnssec-indirect-key,
AUTHOR="D. Eastlake",
TITLE="Indirect {KEY} {RRs} in the Domain Name System",
TYPE="Internet Draft",
HOWPUBLISHED="draft-ietf-dnssec-indirect-key-01",
INSTITUTION="Internet Engineering Task Force",
MONTH=nov,
YEAR=1997,
NOTE="Work in progress",
ABSTRACT="RFC 2065 defines a means for storing cryptogrpahic public keys
in the Domain Name System. An additional code point is defined for the
KEY resource record (RR) algorithm field to indicate that the key itself
is not stored in the KEY RR but is pointed to by the KEY RR. Encodings
to indicate different types of key and pointer formats are specified.",
URL="http://www.ietf.org/internet-drafts/draft-ietf-dnssec-indirect-key-01.txt"
}

@TECHREPORT{draft-ietf-dnssec-key-handling,
AUTHOR="O. Gudmundsson and E. Lewis",
TITLE="Zone {KEY} {RRSet} Signing Procedure",
TYPE="Internet Draft",
HOWPUBLISHED="draft-ietf-dnssec-key-handling-00",
INSTITUTION="Internet Engineering Task Force",
MONTH=nov,
YEAR=1997,
NOTE="Work in progress",
ABSTRACT="Under the security extensions to DNS, as defined in RFC 2065
and RFC 2137, a secured zone will have a KEY RRSet associated with the
domain name at the apex of the zone. This document covers the manner in
which this RRSet is generated, signed, and inserted into the name
servers.",
URL="http://www.ietf.org/internet-drafts/draft-ietf-dnssec-key-handling-00.txt"
}

@TECHREPORT{draft-ietf-drums-abnf,
AUTHOR="D. Crocker and P. Overell",
TITLE="{ABNF}",
TYPE="Internet Draft",
HOWPUBLISHED="draft-ietf-drums-abnf-04",
INSTITUTION="Internet Engineering Task Force",
MONTH=sep,
YEAR=1997,
NOTE="Work in progress",
ABSTRACT="Internet technical specifications often need to define a
format syntax and are free to employ whatever notation their authors
deem useful. Over the years, a modified version of Backus-Naur Form
(BNF), called Augmented BNF (ABNF), has been popular among many Internet
specifications. It balances compactness and simplicity, with reasonable
representational power. In the early days of the Arpanet, each
specification contained its own definition of ABNF. This included the
email specifications, RFC733 and then RFC822 which have come to be the
common citations for defining ABNF. The current document separates out
that definition, to permit selective reference. Predictably, it also
provides some modifications and enhancements.",
URL="http://www.ietf.org/internet-drafts/draft-ietf-drums-abnf-04.txt"
}

@TECHREPORT{draft-ietf-drums-kre-reply-to,
AUTHOR="R. Elz",
TITLE="Use of {Reply-To} in Internet {E-Mail} messages",
TYPE="Internet Draft",
HOWPUBLISHED="draft-ietf-drums-kre-reply-to-00",
INSTITUTION="Internet Engineering Task Force",
MONTH=oct,
YEAR=1997,
NOTE="Work in progress",
ABSTRACT="This draft forms part of a discussion on the appropriate use
of the Reply-To header in e-mail messages. This draft argues for one
particular proposed definition of the Reply-To header. It is not
intended that this document ever become anything more than an
Internet-Draft. If adopted, the text here, or a modified version of some
parts of it, would be merged into the proposed replacement for RFC822.",
URL="http://www.ietf.org/internet-drafts/draft-ietf-drums-kre-reply-to-00.txt"
}

@TECHREPORT{draft-ietf-drums-mail-followup-to,
AUTHOR="J. Palme",
TITLE="The {''Mail-Followup-To''} header",
TYPE="Internet Draft",
HOWPUBLISHED="draft-ietf-drums-mail-followup-to-00",
INSTITUTION="Internet Engineering Task Force",
MONTH=dec,
YEAR=1997,
NOTE="Work in progress",
ABSTRACT="This proposal contains a proposed new e-mail header
''Mail-Followup-To'', which is intended to be used instead of the
''Reply-To'' header for suggesting where replies to the group who
participates in a discussion should be sent.",
URL="http://www.ietf.org/internet-drafts/draft-ietf-drums-mail-followup-to-00.txt"
}

@TECHREPORT{draft-ietf-drums-message-id,
AUTHOR="J. Palme",
TITLE="The {''Message-ID''} header",
TYPE="Internet Draft",
HOWPUBLISHED="draft-ietf-drums-message-id-00",
INSTITUTION="Internet Engineering Task Force",
MONTH=dec,
YEAR=1997,
NOTE="Work in progress",
ABSTRACT="This is a proposal of a text to include msgfmt in order to
clarify the relation between changes in the ''Message-ID'' header and
other parts of a message. This information is important, because many
mailers use the ''Message-ID'' to eliminate duplicates of the same
message, and information may be lost if this is not done the right way.
Temporary note This document does not at this time (21 November 1997)
represent any consensus opinion in the drums working group.",
URL="http://www.ietf.org/internet-drafts/draft-ietf-drums-message-id-00.txt"
}

@TECHREPORT{draft-ietf-drums-replyto-meaning,
AUTHOR="C. Newman",
TITLE="{Reply-To-Meaning} Proposal",
TYPE="Internet Draft",
HOWPUBLISHED="draft-ietf-drums-replyto-meaning-00",
INSTITUTION="Internet Engineering Task Force",
MONTH=dec,
YEAR=1997,
NOTE="Work in progress",
ABSTRACT="This is a candidate proposal for one way which the problems
with the reply-to header in email could be resolved. Under no
circumstances should this be implemented as it is only a candidate for a
solution and no decision has yet been made. This proposal distinguishes
the different incompatible uses of the Reply-To header with a new
Reply-To-Meaning header. This has the advantage of being relatively
simple, not invalidating most current practices and allowing mail user
agents to present more predictable user interfaces.",
URL="http://www.ietf.org/internet-drafts/draft-ietf-drums-replyto-meaning-00.txt"
}

@TECHREPORT{draft-ietf-drums-replyto-personal,
AUTHOR="E. Raymond",
TITLE="{Reply-To} Personal Proposal",
TYPE="Internet Draft",
HOWPUBLISHED="draft-ietf-drums-replyto-personal-00",
INSTITUTION="Internet Engineering Task Force",
MONTH=dec,
YEAR=1997,
NOTE="Work in progress",
ABSTRACT="This proposal describes proposed language for the 822bis
draft, draft-ietf-drums-msg-fmt-03.txt, that clarifies the semantics of
the Reply-To header. The intention is to clarify the rather vague
language in 822bis in a way which preserves compatibility with the
largest possible subset of existing mail user agents. This document
should be read in conjunction with Jacob Palme's Mail-Followup-To
proposal (draft-ietf-drums-mail-followup-to-00.txt), which the working
group chair, Jacob Palme and the author regard as a natural complement
of this proposal.",
URL="http://www.ietf.org/internet-drafts/draft-ietf-drums-replyto-personal-00.txt"
}

@TECHREPORT{draft-ietf-fax-addressing,
AUTHOR="C. Allocchio",
TITLE="{PSTN} and fax address format in e-mail services v3.6",
TYPE="Internet Draft",
HOWPUBLISHED="draft-ietf-fax-addressing-02",
INSTITUTION="Internet Engineering Task Force",
MONTH=nov,
YEAR=1997,
NOTE="Work in progress",
ABSTRACT="Since the very first e-mail to fax gateway objects appeared, a
number of different methods to specify a fax address into an e-mail
address have been used by implementors.",
URL="http://www.ietf.org/internet-drafts/draft-ietf-fax-addressing-02.txt"
}

@TECHREPORT{draft-ietf-fax-ipfax,
AUTHOR="H. Silbiger",
TITLE="{PROCEDURES} {FOR} {REAL} {TIME} {GROUP} 3 {FACSIMILE} {COMMUNICATION}
{BETWEEN} {TERMINALS} {USING} {IP} {NETWORKS}",
TYPE="Internet Draft",
HOWPUBLISHED="draft-ietf-fax-ipfax-00",
INSTITUTION="Internet Engineering Task Force",
MONTH=nov,
YEAR=1997,
NOTE="Work in progress",
ABSTRACT="This Internet Draft defines the procedures to be applied to
allow Group 3 facsimile transmission between terminals where in addition
to the GSTN or ISDN a portion of the transmission path used between
terminals includes an IP network, e.g. the Internet.",
URL="http://www.ietf.org/internet-drafts/draft-ietf-fax-ipfax-00.txt"
}

@TECHREPORT{draft-ietf-fax-itudc,
AUTHOR="D. Crocker",
TITLE="{PROCEDURES} {FOR} {THE} {TRANSFER} {OF} {FACSIMILE} {DATA} {VIA}
{INTERNET} {MAIL}",
TYPE="Internet Draft",
HOWPUBLISHED="draft-ietf-fax-itudc-00",
INSTITUTION="Internet Engineering Task Force",
MONTH=oct,
YEAR=1997,
NOTE="Work in progress",
ABSTRACT="F.IFax, defines the service requirement for both real-time and
store and forward facsimile over the Internet. For store and forward
facsimile this Recommendation defines addressing, MIME encapsulation of
document components and data formats for those components. Store and
forward facsimile uses Internet mail standard protocols for posting,
relaying and delivery of store and forward facsimile document. It
requires no changes to Internet standards or to ITU Facsimile
Recommendations. Such an approach leads to a system that can be used
universally without changes to Internet servers or other intermediate
systems between the sender and the recipient and which permits
interworking between facsimile store and forward users and users of
general Internet mail.",
URL="http://www.ietf.org/internet-drafts/draft-ietf-fax-itudc-00.txt"
}

@TECHREPORT{draft-ietf-fax-requirements,
AUTHOR="L. Masinter",
TITLE="Requirements for Internet Fax",
TYPE="Internet Draft",
HOWPUBLISHED="draft-ietf-fax-requirements-03",
INSTITUTION="Internet Engineering Task Force",
MONTH=nov,
YEAR=1997,
NOTE="Work in progress",
ABSTRACT="Facsimile (Fax) has a long tradition of being a telephony
application from one terminal device to another, where the terminal
device consists of a paper input device (scanner), a paper output device
(printer), and a limited amount of processing power. The transmission of
data end-to-end is accompanied by negotiation (to ensure that the
scanned data can be rendered at the recipient) and confirmation of
delivery (to give the sender assurance that the final data has been
received and processed.) Over time, facsimile has been extended to allow
for PCs connected running software to send and receive fax, to send data
other than paper images, as well as many extensions to the basic image
model, e.g., recent ITU fax standards for color fax. Other delivery
extensions have included sub-addressing (additional signals after the
call is established to facilitate automated routing of faxes to desktops
or mailboxes), and enhanced features such as fax-back, polling, and even
the transfer of binary files. Many mechanisms for sending fax documents
over the Internet have been demonstrated and deployed and are currently
in use. This document summarizes the requirements for Internet Fax as
discussed in the IETF Internet Fax working group. It is an attempt to
establish a baseline of agreed-to requirements against which any
proposal for Internet Fax can be judged. This document encompasses the
requirements for both 'real-time' fax as well as 'store and forward' fax
(both terms defined in Section 2).",
URL="http://www.ietf.org/internet-drafts/draft-ietf-fax-requirements-03.txt"
}

@TECHREPORT{draft-ietf-fax-scenarios,
AUTHOR="D. Wing",
TITLE="Scenarios for Delivery of {FAX} messages over {SMTP}",
TYPE="Internet Draft",
HOWPUBLISHED="draft-ietf-fax-scenarios-00",
INSTITUTION="Internet Engineering Task Force",
MONTH=nov,
YEAR=1997,
NOTE="Work in progress",
ABSTRACT="This document describes various fax-over-SMTP implementation
and deployment scenarios and some of the problems inherient with various
solutions. Most of these scenarios have been described and discussed on
the IETF-FAX mailing list.",
URL="http://www.ietf.org/internet-drafts/draft-ietf-fax-scenarios-00.txt"
}

@TECHREPORT{draft-ietf-fax-scenerios,
AUTHOR="D. Wing",
TITLE="Scenerios for Delivery of {FAX} messages over {SMTP}",
TYPE="Internet Draft",
HOWPUBLISHED="draft-ietf-fax-scenerios-00",
INSTITUTION="Internet Engineering Task Force",
MONTH=nov,
YEAR=1997,
NOTE="Work in progress",
ABSTRACT="This document describes various fax-over-SMTP implementation
and deployment scenerios and some of the problems inherient with various
solutions. Most of these scenerios have been described and discussed on
the IETF-FAX mailing list.",
URL="http://www.ietf.org/internet-drafts/draft-ietf-fax-scenerios-00.txt"
}

@TECHREPORT{draft-ietf-fax-smtp-capabilities,
AUTHOR="N. Joffe and D. Wing",
TITLE="{SMTP} Service Extension for Capabilities Exchange",
TYPE="Internet Draft",
HOWPUBLISHED="draft-ietf-fax-smtp-capabilities-00",
INSTITUTION="Internet Engineering Task Force",
MONTH=nov,
YEAR=1997,
NOTE="Work in progress",
ABSTRACT="This document describes an extension to SMTP [SMTP] which
provides a mechanism for capabilities exchange so the sender of a
message can know selected capabilities of its ultimate recipient, or of
the message transmission path to that recipient.",
URL="http://www.ietf.org/internet-drafts/draft-ietf-fax-smtp-capabilities-00.txt"
}

@TECHREPORT{draft-ietf-fax-tiff-application,
AUTHOR="G. Klyne",
TITLE="Some comments on the {TIFF} 'application' parameter",
TYPE="Internet Draft",
HOWPUBLISHED="draft-ietf-fax-tiff-application-00",
INSTITUTION="Internet Engineering Task Force",
MONTH=dec,
YEAR=1997,
NOTE="Work in progress",
ABSTRACT="This draft attempts to clarify some misunderstandings
concerning use of the 'Application' parameter with the MIME type
'image/tiff'. It is not intended to prescribe or proscribe future use of
the 'Application' parameter, but simply to indicate the intention behind
its introduction.",
URL="http://www.ietf.org/internet-drafts/draft-ietf-fax-tiff-application-00.txt"
}

@TECHREPORT{draft-ietf-fax-tiff-f-reg,
AUTHOR="G. Parsons and J. Rafferty",
TITLE="Tag Image File Format {(TIFF)} - image/tiff-f {MIME} Sub-type Registration",
TYPE="Internet Draft",
HOWPUBLISHED="draft-ietf-fax-tiff-f-reg-00",
INSTITUTION="Internet Engineering Task Force",
MONTH=sep,
YEAR=1997,
NOTE="Work in progress",
ABSTRACT="This document describes the registration of the MIME sub-type
image/tiff-f. The baseline encoding is defined by [TIFF].",
URL="http://www.ietf.org/internet-drafts/draft-ietf-fax-tiff-f-reg-00.txt"
}

@TECHREPORT{draft-ietf-find-cip-soif,
AUTHOR="M. Schwartz and D. Hardy and M. Bowman and E. Hardie and D. Wessels",
TITLE="{CIP} Index Object Format for {SOIF} Objects",
TYPE="Internet Draft",
HOWPUBLISHED="draft-ietf-find-cip-soif-02",
INSTITUTION="Internet Engineering Task Force",
MONTH=oct,
YEAR=1997,
NOTE="Work in progress",
ABSTRACT="The Common Indexing Protocol (CIP) allows servers to form a
referral mesh for query handling by defining a mechanism by which
cooperating servers exchange hints about the searchable indices they
maintain. The structure and transport of CIP are described in (Ref. 1),
as are general rules for the definition of index object types. This
document describes SOIF, the Summary Object Interchange Format, as an
index object type in the context of the CIP framework. SOIF is a
machine-readable syntax for transmitting structured summary objects,
currently used primarily in the context of the World Wide Web. Query
referral has often been dismissed as an ineffective strategy for
handling searches of Web resources, and Web resources certainly present
challenges not present in structured directory services like Rwhois. In
situations where a keyword-based free text search is desired, query
referral is not likely to be effective because the query will probably
be routed to every server participating in the referral mesh. Where a
search can be limited by reference to a specific resource attribute,
however, query referral is an effective tool. SOIF can be used to create
such a known-attribute query mesh because it provides a method for
associating attributes with net-addressable resources. Mic Bowman,
Darren Hardy, Mike Schwartz, and Duane Wessels each contributed to the
creation of the SOIF format and to the descriptions from which this
draft is drawn; errors in this description of their work are the
responsibility of Edward Hardie and corrections should be directed
accordingly.",
URL="http://www.ietf.org/internet-drafts/draft-ietf-find-cip-soif-02.txt"
}

@TECHREPORT{draft-ietf-grip-framework-irt,
AUTHOR="Nevil Brownlee and E. Guttman",
TITLE="Expectations for Computer Security Incident Response",
TYPE="Internet Draft",
HOWPUBLISHED="draft-ietf-grip-framework-irt-08",
INSTITUTION="Internet Engineering Task Force",
MONTH=sep,
YEAR=1997,
NOTE="Work in progress",
ABSTRACT="The purpose of this document is to express the general
Internet community's expectations of Computer Security Incident Response
Teams (CSIRTs). It is not possible to define a set of requirements that
would be appropriate for all teams, but it is possible and helpful to
list and describe the general set of topics and issues which are of
concern and interest to constituent communities. CSIRT constituents have
a legitimate need and right to fully understand the policies and
procedures of 'their' Computer Security Incident Response Team. One way
to support this understanding is to supply detailed information which
users may consider, in the form of a formal template completed by the
CSIRT. An outline of such a template and a filled in example are
provided.",
URL="http://www.ietf.org/internet-drafts/draft-ietf-grip-framework-irt-08.txt"
}

@TECHREPORT{draft-ietf-http-alternates,
AUTHOR="T. Hardie and K. Holtman and A. Mutz",
TITLE="The Alternates Header Field",
TYPE="Internet Draft",
HOWPUBLISHED="draft-ietf-http-alternates-01",
INSTITUTION="Internet Engineering Task Force",
MONTH=nov,
YEAR=1997,
NOTE="Work in progress",
ABSTRACT="This document proposes a header, Alternates, which is intended
to provide a common method for Internet-based application protocols to
indicate that a particular resource exists in multiple forms. The
Alternates header provides a machine-readable indication of the bases on
which the different forms vary and how the the recipient of the header
can select among them.",
URL="http://www.ietf.org/internet-drafts/draft-ietf-http-alternates-01.txt"
}

@TECHREPORT{draft-ietf-http-jaye-trust-state,
AUTHOR="D. Jaye",
TITLE="{HTTP} Trust Mechanism for State Management",
TYPE="Internet Draft",
HOWPUBLISHED="draft-ietf-http-jaye-trust-state-01",
INSTITUTION="Internet Engineering Task Force",
MONTH=oct,
YEAR=1997,
NOTE="Work in progress",
ABSTRACT="This document specifies an addition to the state management
protocol specified in draft-ietf-http-state-man-mec-03[Kristol]. The
intent is to provide a mechanism that allows user agents to determine
the privacy practices of a server and to accept or reject cookies based
on those practices. Allowing the user to establish preferences for how
to handle cookies based on the server's practices provides a practical
mechanism to provide users control over the privacy implications of
cookies. To provide verification of server privacy practices, we assume
the existence of one or more independent Trust Authorities. The
authority establishes PICS ratings representing server privacy
practices. It then issues trust-labels, in the form of digitally signed
PICS labels, to organizations for specific domains and paths based on
the server privacy practices. The Trust Authority must be able to audit
domains to verify their adherence to a given level. Passing these
trust-labels along with cookies allows the user agent to support cookie
handling preferences based on trusted privacy practices. This document
describes how PICS-headers are used in conjunction with Set-Cookie or
Set-Cookie2 headers in [Kristol] to provide trust-labels to communicate
the privacy practices of servers regarding cookies.",
URL="http://www.ietf.org/internet-drafts/draft-ietf-http-jaye-trust-state-01.txt"
}

@TECHREPORT{draft-ietf-http-negotiate-scenario,
AUTHOR="E. Hardie",
TITLE="Scenarios for the Delivery of Negotiated Content",
TYPE="Internet Draft",
HOWPUBLISHED="draft-ietf-http-negotiate-scenario-02",
INSTITUTION="Internet Engineering Task Force",
MONTH=nov,
YEAR=1997,
NOTE="Work in progress",
ABSTRACT="A number of Internet application protocols have a need to
provide content negotiation for the resources with which they interact.
While MIME media types [1] provide a standard method for handling one
major axis of variation, resources also vary in ways which cannot be
expressed using currently available MIME headers. This paper asserts
that a cross-protocol negotiation framework is needed, both to leverage
work already done for specific protocols and to allow for content
negotiation when resources will pass through several protocols on their
way from provider to recipient. To justify the need, this paper puts
forward several content negotiation scenarios and discusses how they
affect the requirements for such a framework.",
URL="http://www.ietf.org/internet-drafts/draft-ietf-http-negotiate-scenario-02.txt"
}

@TECHREPORT{draft-ietf-http-options,
AUTHOR="J. Mogul and S. Lawrence and J. Cohen",
TITLE="Specification of {HTTP/1.1} {OPTIONS} messages",
TYPE="Internet Draft",
HOWPUBLISHED="draft-ietf-http-options-01",
INSTITUTION="Internet Engineering Task Force",
MONTH=aug,
YEAR=1997,
NOTE="Work in progress",
ABSTRACT="RFC2068 defined a new OPTIONS method for HTTP/1.1. The purpose
of OPTIONS is to allow a 'client to determine the options and/or
requirements associated with a resource, or the capabilities of a
server, without implying a resource action or initiating a resource
retrieval.' However, RFC2068 did not defined a specific syntax for using
OPTIONS to make such a determination. This proposal clarifies the
original specification of OPTIONS, adds several new HTTP message headers
to provide syntactic support for OPTIONS, and establishes new IANA
registries to avoid namespace conflicts.",
URL="http://www.ietf.org/internet-drafts/draft-ietf-http-options-01.txt"
}

@TECHREPORT{draft-ietf-http-pep,
AUTHOR="D. Connolly and H. Nielsen and R. Khare and E. Prud'hommeaux",
TITLE="{PEP} - an Extension Mechanism for {HTTP}",
TYPE="Internet Draft",
HOWPUBLISHED="draft-ietf-http-pep-05",
INSTITUTION="Internet Engineering Task Force",
MONTH=dec,
YEAR=1997,
NOTE="Work in progress",
ABSTRACT="HTTP is used increasingly in applications that need more
facilities than the standard version of the protocol provides, ranging
from distributed authoring, collaboration, and printing, to various
remote procedure call mechanisms. The Protocol Extension Protocol (PEP)
is an extension mechanism designed to address the tension between
private agreement and public specification and to accommodate extension
of applications such as HTTP clients, servers, and proxies. The PEP
mechanism is designed to associate each extension with a URI[2], and use
a few new RFC 822[1] derived header fields to carry the extension
identifier and related information between the parties involved in an
extended transaction. This document defines PEP and describes the
interactions between PEP and HTTP/1.1[7]. PEP is intended to be
compatible with HTTP/1.0[5] inasmuch as HTTP/1.1 is compatible with
HTTP/1.0 (see [7], section 19.7). It is proposed that the PEP extension
mechanism be included in future versions of HTTP. The PEP extension
mechanism may be applicable to other information exchange not mentioned
in this document. It is recommended that readers get acquainted with
section 1.4 for a suggested reading of this specification and a list of
sections specific for HTTP based applications.",
URL="http://www.ietf.org/internet-drafts/draft-ietf-http-pep-05.txt"
}

@TECHREPORT{draft-ietf-idmr-masc,
AUTHOR="D. Estrin and M. Handley and D. Thaler and S. Kumar",
TITLE="The Multicast Address Set Claim {(MASC)} Protocol",
TYPE="Internet Draft",
HOWPUBLISHED="draft-ietf-idmr-masc-00",
INSTITUTION="Internet Engineering Task Force",
MONTH=nov,
YEAR=1997,
NOTE="Work in progress",
ABSTRACT="The MASC protocol is used by a node (typically a router) to
claim one or more sets of addresses (''address sets'') from which
Multicast Address Allocation Servers (MAAS's) within its domain will
allocate group addresses to hosts. Each address set has an associated
lifetime, and is chosen out of a larger address set with a lifetime at
least as long, in a manner such that address sets are aggregatable. At
any time, each MASC node will typically be advertising several address
sets with different lifetimes and scopes allowing MAAS's to choose
appropriate addresses for their clients.",
URL="http://www.ietf.org/internet-drafts/draft-ietf-idmr-masc-00.txt"
}

@TECHREPORT{draft-ietf-ids-inp,
AUTHOR="J. Ordille",
TITLE="Internet Nomenclator Project",
TYPE="Internet Draft",
HOWPUBLISHED="draft-ietf-ids-inp-03",
INSTITUTION="Internet Engineering Task Force",
MONTH=nov,
YEAR=1997,
NOTE="Work in progress",
ABSTRACT="The goal of the Internet Nomenclator Project is to integrate
the hundreds of publicly available CCSO servers from around the world.
Each CCSO server has a database schema that is tailored to the needs of
the organization that owns it. The project is integrating the different
database schema into one query service. The Internet Nomenclator Project
will provide fast cross-server searches for locating people on the
Internet. It augments existing CCSO services by supplying schema
integration, more extensive indexing, and two kinds of caching -- all
this in a system that scales as the number of CCSO servers grows. One of
the best things about the system is that administrators can incorporate
their CCSO servers into Nomenclator without changing the servers. All
Nomenclator needs is basic information about the server. This document
provides an overview of the Nomenclator system, describes how to
register a CCSO server in the Internet Nomenclator Project, and how to
use the Nomenclator search engine to find people on the Internet.
Distribution of this document is unlimited. Comments should be sent to
the author.",
URL="http://www.ietf.org/internet-drafts/draft-ietf-ids-inp-03.txt"
}

@TECHREPORT{draft-ietf-ids-snqp,
AUTHOR="J. Ordille and J. Elliott",
TITLE="Simple Nomenclator Query Protocol {(SNQP)}",
TYPE="Internet Draft",
HOWPUBLISHED="draft-ietf-ids-snqp-02",
INSTITUTION="Internet Engineering Task Force",
MONTH=nov,
YEAR=1997,
NOTE="Work in progress",
ABSTRACT="The Simple Nomenclator Query Protocol (SNQP) allows a client
to communicate with a descriptive name service or other relational-style
query service. The protocol is useful to services that search many data
repositories for query responses. Clients can pose queries on relations,
list descriptions of relations, and obtain advice on reducing the search
time and cost of their queries. Clients are informed of the age of
information in caches, and may request more recent information. SNQP
provides support for graphical user interfaces. It also supports
different types of comparison operators, so services can use SNQP with a
variety of back-end servers, e.g. relational database servers, CCSO
servers, and servers providing relational views of X.500. SNQP is an
ASCII protocol in the request-reply style of SMTP. It was specifically
designed for use with the Nomenclator name and information service, and
has been useful elsewhere.",
URL="http://www.ietf.org/internet-drafts/draft-ietf-ids-snqp-02.txt"
}

@TECHREPORT{draft-ietf-ifmib-mib,
AUTHOR="F. Kastenholz and K. McCloghrie",
TITLE="The Interfaces Group {MIB}",
TYPE="Internet Draft",
HOWPUBLISHED="draft-ietf-ifmib-mib-06",
INSTITUTION="Internet Engineering Task Force",
MONTH=oct,
YEAR=1997,
NOTE="Work in progress",
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 managing
Network Interfaces. This memo discusses the 'interfaces' group of
MIB-II, especially the experience gained from the definition of numerous
media- specific MIB modules for use in conjunction with the 'interfaces'
group for managing various sub-layers beneath the internetwork- layer.
It specifies clarifications to, and extensions of, the architectural
issues within the previous model used for the 'interfaces' group.",
URL="http://www.ietf.org/internet-drafts/draft-ietf-ifmib-mib-06.txt"
}

@TECHREPORT{draft-ietf-intserv-control-flow,
AUTHOR="Sugih Jamin and C. Jin and L. Breslau",
TITLE="A Measurement Based Admission Control Algorithm for {Controlled-Load}
Service with a Reference Implementation Framework",
TYPE="Internet Draft",
HOWPUBLISHED="draft-ietf-intserv-control-flow-01",
INSTITUTION="Internet Engineering Task Force",
MONTH=oct,
YEAR=1997,
NOTE="Work in progress",
ABSTRACT="Controlled-Load Service provides data flows with an enhanced
quality of service, in the form of low packet delay and a low
probability of packet loss even under congestion. A network element
providing Controlled-Load Service can use an admission control algorithm
to limit the number of data flows receiving the service. In this
document we describe an admission control algorithm for Controlled- Load
Service. This algorithm is not intended for IETF standardization.
Rather, it is presented for informational purposes only. We also present
a reference implementation framework for the measurement-based admission
control algorithm. Our implementation separates the measurement from the
actual admission control decision to provide the flexibility of using
different algorithms in bandwidth estimation and admission control.",
URL="http://www.ietf.org/internet-drafts/draft-ietf-intserv-control-flow-01.txt"
}

@TECHREPORT{draft-ietf-intserv-guaranteed-mib,
AUTHOR="F. Baker",
TITLE="Integrated Services Management Information Base Guaranteed Service
Extensions",
TYPE="Internet Draft",
HOWPUBLISHED="draft-ietf-intserv-guaranteed-mib-04",
INSTITUTION="Internet Engineering Task Force",
MONTH=aug,
YEAR=1997,
NOTE="Work in progress",
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 the the
interface attributes defined in the Guaranteed Service of the Integrated
Services Model. Comments should be made to the Integrated Services
Working Group, int-serv(at)isi.edu. This memo does not, in its draft form,
specify a standard for the Internet community.",
URL="http://www.ietf.org/internet-drafts/draft-ietf-intserv-guaranteed-mib-04.txt"
}

@TECHREPORT{draft-ietf-intserv-mib,
AUTHOR="F. Baker and J. Krawczyk",
TITLE="Integrated Services Management Information Base",
TYPE="Internet Draft",
HOWPUBLISHED="draft-ietf-intserv-mib-10",
INSTITUTION="Internet Engineering Task Force",
MONTH=aug,
YEAR=1997,
NOTE="Work in progress",
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 the the
interface attributes defined in the Integrated Services Model. Comments
should be made to the Integrated Services Working Group,
int-serv(at)isi.edu. This memo does not, in its draft form, specify a
standard for the Internet community.",
URL="http://www.ietf.org/internet-drafts/draft-ietf-intserv-mib-10.txt"
}

@TECHREPORT{draft-ietf-ion-intra-area-unicast,
AUTHOR="J. Heinanen",
TITLE="Intra-area {IP} unicast among routers over legacy {ATM}",
TYPE="Internet Draft",
HOWPUBLISHED="draft-ietf-ion-intra-area-unicast-01",
INSTITUTION="Internet Engineering Task Force",
MONTH=nov,
YEAR=1997,
NOTE="Work in progress",
ABSTRACT="This document describes how IP unicast can be efficiently
implemented among routers belonging to the same area of a routing
domain, where the connectivity is provided by a legacy ATM network as
defined by the ATM Forum or ITU. This proposal is designed to be
complementary to IP multicast solutions such as the one described in
[1].",
URL="http://www.ietf.org/internet-drafts/draft-ietf-ion-intra-area-unicast-01.txt"
}

@TECHREPORT{draft-ietf-ion-ipatm-classic2,
AUTHOR="M. Laubach and J. Halpern",
TITLE="Classical {IP} and {ARP} over {ATM}",
TYPE="Internet Draft",
HOWPUBLISHED="draft-ietf-ion-ipatm-classic2-03",
INSTITUTION="Internet Engineering Task Force",
MONTH=oct,
YEAR=1997,
NOTE="Work in progress",
ABSTRACT="This memo defines an initial application of classical IP and
ARP in an Asynchronous Transfer Mode (ATM) network environment
configured as a Logical IP Subnetwork (LIS) as described in Section 5.
This memo does not preclude the subsequent development of ATM technology
into areas other than a LIS; specifically, as single ATM networks grow
to replace many Ethernet local LAN segments and as these networks become
globally connected, the application of IP and ARP will be treated
differently. This memo considers only the application of ATM as a direct
replacement for the",
URL="http://www.ietf.org/internet-drafts/draft-ietf-ion-ipatm-classic2-03.txt"
}

@TECHREPORT{draft-ietf-ion-sig-uni4.0,
AUTHOR="M. Maher",
TITLE="{ATM} Signalling Support for {IP} over {ATM} - {UNI} Signalling {4.0}
Update",
TYPE="Internet Draft",
HOWPUBLISHED="draft-ietf-ion-sig-uni4.0-05",
INSTITUTION="Internet Engineering Task Force",
MONTH=oct,
YEAR=1997,
NOTE="Work in progress",
ABSTRACT="This memo describes how to efficiently use the ATM call
control signalling procedures defined in UNI Signalling 4.0 [SIG40] to
support IP over ATM environments as described in RFC XXX [LAUB97] and in
[LUC97]. Among the new features found in UNI Signalling 4.0 are
Available Bit Rate signalling and traffic parameter negotiation. This
draft highlights the features of UNI Signalling 4.0 that provide IP
entities capabilities for requesting ATM service in sites with SVC
support, whether it is private ATM or publicly provisioned ATM, in which
case the SVC support is probably configured inside PVPs. This document
is only relevant to IP when used as the well known ''best effort''
connectionless service. In particular, this means that this document
does not pertain to IP in the presence of implemented IP Integrated
Services. The topic of IP with Integrated Services over ATM will be
handled by a different specification or set of specifications being
worked on in the ISSLL WG. This specification is follow-on to RFC 1755,
''ATM Signaling Support for IP over ATM'', which is based on UNI 3.1
signalling [UNI95]. Readers are assumed to be familiar with RFC 1755.",
URL="http://www.ietf.org/internet-drafts/draft-ietf-ion-sig-uni4.0-05.txt"
}

@TECHREPORT{draft-ietf-ipngwg-dns-reverse-lookup,
AUTHOR="O. Gudmundsson",
TITLE="Reverse Address lookup in {DNS} for {IPng.}",
TYPE="Internet Draft",
HOWPUBLISHED="draft-ietf-ipngwg-dns-reverse-lookup-00",
INSTITUTION="Internet Engineering Task Force",
MONTH=dec,
YEAR=1997,
NOTE="Work in progress",
ABSTRACT="This document proposes a new mechanism to represent inverse
address mapping in the Domain Name System (DNS) for IP version 6 (IPv6).
Documented in here are the changes needed for securing the binding and
delegation of address ranges, to facilitate queries for the binding of
address to host name. This document also defines a mechanism for dumb
resolvers to query directly for the binding. The changes include a new
resource record to delegate the address space in segments based on
arbitrary bit boundaries. This proposal provides a mechanism that is
self checking and can be traversed from both top and bottom. Additional
processing requirements on IPv6 aware resolvers and servers are defined.",
URL="http://www.ietf.org/internet-drafts/draft-ietf-ipngwg-dns-reverse-lookup-00.txt"
}

@TECHREPORT{draft-ietf-ipngwg-tokenring,
AUTHOR="S. Thomas",
TITLE="Transmission of {IPv6} Packets over Token Ring Networks",
TYPE="Internet Draft",
HOWPUBLISHED="draft-ietf-ipngwg-tokenring-01",
INSTITUTION="Internet Engineering Task Force",
MONTH=sep,
YEAR=1997,
NOTE="Work in progress",
ABSTRACT="This memo specifies the MTU and frame format for transmission
of IPv6 packets on Token Ring networks. It also specifies the method of
forming IPv6 link-local addresses on Token Ring networks and the content
of the Source/Target Link-layer Address option used the Router
Solicitation, Router Advertisement, Neighbor Solicitation and Neighbor
Advertisement messages when those messages are transmitted on a Token
Ring network.",
URL="http://www.ietf.org/internet-drafts/draft-ietf-ipngwg-tokenring-01.txt"
}

@TECHREPORT{draft-ietf-ipngwg-trans-ethernet,
AUTHOR="M. Crawford",
TITLE="Transmission of {IPv6} Packets over Ethernet Networks",
TYPE="Internet Draft",
HOWPUBLISHED="draft-ietf-ipngwg-trans-ethernet-04",
INSTITUTION="Internet Engineering Task Force",
MONTH=nov,
YEAR=1997,
NOTE="Work in progress",
ABSTRACT="This document specifies the frame format for transmission of
IPv6 packets and the method of forming IPv6 link-local addresses and
statelessly autoconfigured addresses on Ethernet networks. It also
specifies the content of the Source/Target Link-layer Address option
used in Router Solicitation, Router Advertisement, Neighbor
Solicitation, Neighbor Advertisement and Redirect messages when those
messages are transmitted on an Ethernet. This document replaces RFC
1972, ''A Method for the Transmission of IPv6 Packets over Ethernet
Networks'', which will become historic.",
URL="http://www.ietf.org/internet-drafts/draft-ietf-ipngwg-trans-ethernet-04.txt"
}

@TECHREPORT{draft-ietf-ipngwg-trans-fddi-net,
AUTHOR="M. Crawford",
TITLE="Transmission of {IPv6} Packets over {FDDI} Networks",
TYPE="Internet Draft",
HOWPUBLISHED="draft-ietf-ipngwg-trans-fddi-net-05",
INSTITUTION="Internet Engineering Task Force",
MONTH=nov,
YEAR=1997,
NOTE="Work in progress",
ABSTRACT="This document specifies the frame format for transmission of
IPv6 packets and the method of forming IPv6 link-local addresses and
statelessly autoconfigured addresses on FDDI networks. It also specifies
the content of the Source/Target Link-layer Address option used in
Router Solicitation, Router Advertisement, Neighbor Solicitation,
Neighbor Advertisement and Redirect messages when those messages are
transmitted on an FDDI network. This document replaces RFC 2019,
''Transmission of IPv6 Packets Over FDDI'', which will become historic.",
URL="http://www.ietf.org/internet-drafts/draft-ietf-ipngwg-trans-fddi-net-05.txt"
}

@TECHREPORT{draft-ietf-ippcp-arch,
AUTHOR="R. Monsour and A. Shacham",
TITLE="{IP} Payload Compression Protocol Architecture",
TYPE="Internet Draft",
HOWPUBLISHED="draft-ietf-ippcp-arch-00",
INSTITUTION="Internet Engineering Task Force",
MONTH=jul,
YEAR=1997,
NOTE="Work in progress",
ABSTRACT="This memo describes an architecture for applying lossless
compression to Internet Protocol datagrams. It defines several of the
key architectural elements of a compression protocol and describes
alternatives for each element.",
URL="http://www.ietf.org/internet-drafts/draft-ietf-ippcp-arch-00.txt"
}

@TECHREPORT{draft-ietf-ipsec-isakmp-SA-revised,
AUTHOR="B. Patel and M. Jeronimo",
TITLE="Revised {SA} negotiation mode for {ISAKMP/Oakley}",
TYPE="Internet Draft",
HOWPUBLISHED="draft-ietf-ipsec-isakmp-SA-revised-00",
INSTITUTION="Internet Engineering Task Force",
MONTH=dec,
YEAR=1997,
NOTE="Work in progress",
ABSTRACT="ISAKMP/OAKLEY [2][3] is the key management protocol defined by
IPSEC working to be a framework for authentication, security association
negotiation and key management. The protocol defines two phases whereby,
in the phase 1, the peers are authenticates, the security association
(SA) for ISAKMP/Oakley, and keying material is agreed upon by the peers
to secure ISAKMP messages. The phase 2 is used to negotiate security
association for security applications (e.g., IPSEC AH and ESP). When
perfect forward secrecy is required, phase 2 is also used to exchange
keying material for the application. However, when perfect forward
secrecy is not a requirement, the keying material from the phase 1 is
used to generate session keys for the secure communication applications.
The proposal in this document is based on the observation that when
perfect forward secrecy is not a requirement, if application specific SA
was negotiated during phase 1, the application can start immediately
after phase 1. The phase 2 can be used subsequently for key refresh on
per need bases in the future. Therefore, this proposal reduces startup
time for communication and improves the efficiency of the protocol.
Remark: This document is NOT self-contained, it is intended as an
addendum to [2][3]. Thus, it is best read in conjunction with [2][3].",
URL="http://www.ietf.org/internet-drafts/draft-ietf-ipsec-isakmp-SA-revised-00.txt"
}

@TECHREPORT{draft-ietf-ipsec-revised-enc-mode,
AUTHOR="H. Krawczyk and P. Cheng and R. Canetti",
TITLE="A revised encryption mode for {ISAKMP/Oakley}",
TYPE="Internet Draft",
HOWPUBLISHED="draft-ietf-ipsec-revised-enc-mode-01",
INSTITUTION="Internet Engineering Task Force",
MONTH=aug,
YEAR=1997,
NOTE="Work in progress",
ABSTRACT="The ISAKMP/Oakley document [HC97] describes a proposed
standard for using the Oakley Key Exchange Protocol in conjunction with
ISAKMP to obtain authenticated and secret keying material for use with
ISAKMP, and for other security associations such as AH and ESP for the
IETF IPsec DOI. The public-key encryption method of carrying out Phase 1
of the key exchange in the ISAKMP/Oakley document provides significant
security advantages over the other alternatives and should be the method
of choice in many implementations. Unfortunately, as currently described
in [HC97] the method requires two public key encryption and decryption
operations from both the Initiator and the Responder. The present
document describes a small modification to this method. The resulting
scheme requires only one public key encryption and decryption operation
from each party, while maintaining (and even improving on) the strong
security properties of the ISAKMP/Oakley public-key encryption mode.
Remark: This document is NOT self-contained, it is intended as an
addendum to the authentication methods defined in [HC97]. In particular,
it uses notation and definitions of [HC97]. Thus, it is best read in
conjunction with [HC97].",
URL="http://www.ietf.org/internet-drafts/draft-ietf-ipsec-revised-enc-mode-01.txt"
}

@TECHREPORT{draft-ietf-ipsec-vpn,
AUTHOR="N. Doraswamy",
TITLE="Implementation of Virtual Private Network {(VPNs)} with {IP} Security",
TYPE="Internet Draft",
HOWPUBLISHED="draft-ietf-ipsec-vpn-00",
INSTITUTION="Internet Engineering Task Force",
MONTH=mar,
YEAR=1997,
NOTE="Work in progress",
ABSTRACT="This document discusses methods for implementing Virtural
Private Networks (VPN) with IP Security (IPSec). We discuss different
scenarios in which VPN is implemented and the security implications for
each of these scenarios.",
URL="http://www.ietf.org/internet-drafts/draft-ietf-ipsec-vpn-00.txt"
}

@TECHREPORT{draft-ietf-issll-is802-bm,
AUTHOR="R. Yavatkar and F. Baker and D. Hoffman and Y. Bernet",
TITLE="{SBM} (Subnet Bandwidth Manager): A Proposal for Admission Control over
{IEEE} 802-style networks",
TYPE="Internet Draft",
HOWPUBLISHED="draft-ietf-issll-is802-bm-05",
INSTITUTION="Internet Engineering Task Force",
MONTH=dec,
YEAR=1997,
NOTE="Work in progress",
ABSTRACT="This document outlines a signaling method and protocol for
RSVP-based admission control over IEEE 802-style LANs. The proposed
method is designed to work both with the current generation of IEEE 802
LANs and new work being defined within the IEEE 802.1p/q committees.",
URL="http://www.ietf.org/internet-drafts/draft-ietf-issll-is802-bm-05.txt"
}

@TECHREPORT{draft-ietf-ldapext-hobs,
AUTHOR="K. Richardson and A. Hodson and E. Andersen and L. Visser and P. Fantou and
J. Pasquerau",
TITLE="Hierarchical Operational Bindings - a profile",
TYPE="Internet Draft",
HOWPUBLISHED="draft-ietf-ldapext-hobs-00",
INSTITUTION="Internet Engineering Task Force",
MONTH=dec,
YEAR=1997,
NOTE="Work in progress",
ABSTRACT="Where LDAP servers are based on X.500 DSAs for the holding of
distributed Directory information, the maintenance of the necessary
security and networking relationships between DSAs is an important
factor to consider. The '93 X.500 Directory standards define HOB
(Hierarchical Operational Binding) procedures for the creation of a new
naming context in another DSA, and also for the maintenance of the
relationship between two DSAs where one holds a superior naming context
and the other holds a subordinate naming context. The standards also
define the use of the Directory Operational Binding Management Protocol
(DOP) to mediate these procedures. The use of HOBs provides a major
simplification for managers of X.500 systems, since it provides a way to
update policies automatically from one DSA to another. But practical
design for HOBs requires decisions in a number of respects not fully
treated by the standards. This document simplifies the implementor's
task by defining viable and practical subsets of the standards and by
clarifying some of the issues left undefined by the standards. HOBs
always represent an intimate relationship between DSAs which must be
protected from masquerade. A method of providing this protection is
given in the '93 Directory standards by requiring mutual authentication
at the bind between DSAs. HOBS will normally only be established between
DSAs owned by a single administrative authority, so security needs to be
considered in this somewhat easier context than complete openness.
Although simple unprotected authentication (name and password) can be a
valid option in an already-secure environment, simple protected
authentication using an encrypted password is potentially a much more
secure technique, as is strong authentication using public key
cryptography. All such techniques are validly used within the scope of
this profile, as are techniques not defined but permitted by the
Directory standards (these are known as ''external'' methods). Support
of simple authentication is mandated for all implementations compliant
with this profile. Where this is not adequate, purchasers need to ensure
that their requirements for are met.",
URL="http://www.ietf.org/internet-drafts/draft-ietf-ldapext-hobs-00.txt"
}

@TECHREPORT{draft-ietf-lsd-client-finding,
AUTHOR="R. Moats",
TITLE="{LDAP} Clients Finding {LDAP} Servers",
TYPE="Internet Draft",
HOWPUBLISHED="draft-ietf-lsd-client-finding-00",
INSTITUTION="Internet Engineering Task Force",
MONTH=nov,
YEAR=1997,
NOTE="Work in progress",
ABSTRACT="This document discusses methods available for LDAP clients to
discover the existance and location of LDAP servers. It is based on
previous and ongoing IETF work.",
URL="http://www.ietf.org/internet-drafts/draft-ietf-lsd-client-finding-00.txt"
}

@TECHREPORT{draft-ietf-madman-mail-monitor-mib,
AUTHOR="S. Kille and N. Freed",
TITLE="Mail Monitoring {MIB}",
TYPE="Internet Draft",
HOWPUBLISHED="draft-ietf-madman-mail-monitor-mib-06",
INSTITUTION="Internet Engineering Task Force",
MONTH=dec,
YEAR=1997,
NOTE="Work in progress",
ABSTRACT="This memo defines a portion of the Management Information Base
(MIB) for use with network management protocols in the Internet
community. Specifically, this memo extends the basic Network Services
Monitoring MIB [8] to allow monitoring of Message Transfer Agents
(MTAs). It may also be used to monitor MTA components within gateways.",
URL="http://www.ietf.org/internet-drafts/draft-ietf-madman-mail-monitor-mib-06.txt"
}

@TECHREPORT{draft-ietf-madman-nsm-mib,
AUTHOR="S. Kille and N. Freed",
TITLE="Network Services Monitoring {MIB}",
TYPE="Internet Draft",
HOWPUBLISHED="draft-ietf-madman-nsm-mib-07",
INSTITUTION="Internet Engineering Task Force",
MONTH=dec,
YEAR=1997,
NOTE="Work in progress",
ABSTRACT="A networked application is a realization of some well defined
service on one or more host computers that is accessible via some
network, uses some network for its internal operations, or both.",
URL="http://www.ietf.org/internet-drafts/draft-ietf-madman-nsm-mib-07.txt"
}

@TECHREPORT{draft-ietf-madman-trackmib,
AUTHOR="B. Ernst and G. Jones and J. Weintraub",
TITLE="Message Tracking {MIB}",
TYPE="Internet Draft",
HOWPUBLISHED="draft-ietf-madman-trackmib-00",
INSTITUTION="Internet Engineering Task Force",
MONTH=aug,
YEAR=1997,
NOTE="Work in progress",
ABSTRACT="This document defines a message tracking Management
Information Base (MIB) for electronic messaging usage. Message tracking
is the ability to find out, after the fact, the path that a particular
message took through the messaging system and the current status of that
message.",
URL="http://www.ietf.org/internet-drafts/draft-ietf-madman-trackmib-00.txt"
}

@TECHREPORT{draft-ietf-manet-imep-spec,
AUTHOR="S. Corson and V. Park",
TITLE="An Internet {MANET} Encapsulation Protocol {(IMEP)} Specification",
TYPE="Internet Draft",
HOWPUBLISHED="draft-ietf-manet-imep-spec-00",
INSTITUTION="Internet Engineering Task Force",
MONTH=dec,
YEAR=1997,
NOTE="Work in progress",
ABSTRACT="This memo describes a multipurpose network-layer
protocol---named the Internet MANET Encapsulation Protocol
(IMEP)---designed to support the operation of many routing algorithms or
other upper layer protocols intended for use in Mobile Ad hoc Networks
(MANET). The protocol incorporates mechanisms for supporting link status
sensing, control message aggregation and encapsulation, broadcast
reliability, network-layer address resolution and provides hooks for
interrouter security authentication procedures. The IMEP also puts forth
a framework or architecture for MANET router and interface
identification and addressing. The present specification is high-level
and incomplete, giving only a behavioral protocol description and
proposed packet format. This version of this draft is intended primarily
to acquaint readers with the concept of the protocol. A subsequent
revision will detail the protocol's mechanisms and data structures.",
URL="http://www.ietf.org/internet-drafts/draft-ietf-manet-imep-spec-00.txt"
}

@TECHREPORT{draft-ietf-mboned-imrp-some-issues,
AUTHOR="D. Meyer",
TITLE="Some Issues for an Inter-domain Multicast Routing Protocol",
TYPE="Internet Draft",
HOWPUBLISHED="draft-ietf-mboned-imrp-some-issues-03",
INSTITUTION="Internet Engineering Task Force",
MONTH=nov,
YEAR=1997,
NOTE="Work in progress",
ABSTRACT="The IETF's Inter-Domain Multicast Routing (IDMR) working group
has produced several multicast routing protocols, including Core Based
Trees [CBT] and Protocol Independent Multicasting [PIMARCH]. In
addition, the IDMR WG has formalized the specification of the Distance
Vector Multicast Routing Protocol [DVMRP]. Various specifications for
protocol inter-operation have also been produced (see, for example,
[THALER96] and [PIMMBR]). However, none of these protocols seems ideally
suited to the inter-domain routing case; that is, while these protocols
are appropriate for the intra-domain routing environment, they break
down in various ways when applied in to the multi-provider inter-domain
case. This document considers some of the scaling, stability and policy
issues that are of primary importance in a inter-domain, multi- provider
multicast environment.",
URL="http://www.ietf.org/internet-drafts/draft-ietf-mboned-imrp-some-issues-03.txt"
}

@TECHREPORT{draft-ietf-mixer-directory,
AUTHOR="S. Kille",
TITLE="Use of an {X.500/LDAP} directory to support {MIXER} address mapping",
TYPE="Internet Draft",
HOWPUBLISHED="draft-ietf-mixer-directory-03",
INSTITUTION="Internet Engineering Task Force",
MONTH=nov,
YEAR=1997,
NOTE="Work in progress",
ABSTRACT="his document defines how to use an X.500 or LDAP directory to
support the mapping between X.400 OR Addresses and mailboxes defined in
MIXER (RFC 1327bis) [4]. This draft document will be submitted to the
RFC editor as a protocol standard. Distribution of this memo is
unlimited.",
URL="http://www.ietf.org/internet-drafts/draft-ietf-mixer-directory-03.txt"
}

@TECHREPORT{draft-ietf-mobileip-ra,
AUTHOR="G. Troxel and L. Sanchez",
TITLE="Rapid Authentication for Mobile {IP}",
TYPE="Internet Draft",
HOWPUBLISHED="draft-ietf-mobileip-ra-00",
INSTITUTION="Internet Engineering Task Force",
MONTH=dec,
YEAR=1997,
NOTE="Work in progress",
ABSTRACT="This document describes a mechanism that provides Mobile IP
nodes and agents with the necessary keys and information needed to
establish mobility security associations within a foreign network. This
mechanism aims at reducing the latency and computational burden
introduced by public-key based key management protocols in network
topologies where visiting mobile nodes register with their respective
home agents several times through different foreign agents requiring
Mobile-Foreign Authentication. This mechanism employs a key distribution
center capable of generating the security contexts needed to
authenticate Mobile IP control messages. This mechanism, designed as an
extension to the Mobile IP protocol, preservs backward compatibility and
interoperability with RFC2002 compliant implementations of Mobile IP.",
URL="http://www.ietf.org/internet-drafts/draft-ietf-mobileip-ra-00.txt"
}

@TECHREPORT{draft-ietf-mobileip-spectun,
AUTHOR="C. Perkins and D. Johnson",
TITLE="Special Tunnels for Mobile {IP}",
TYPE="Internet Draft",
HOWPUBLISHED="draft-ietf-mobileip-spectun-00",
INSTITUTION="Internet Engineering Task Force",
MONTH=dec,
YEAR=1997,
NOTE="Work in progress",
ABSTRACT="This document defines actions taken by Mobile IP home agents
and foreign agents to try to avoid loss of datagrams sent to an
incorrect care-of address, even if a foreign agent has no binding for
the mobile node.",
URL="http://www.ietf.org/internet-drafts/draft-ietf-mobileip-spectun-00.txt"
}

@TECHREPORT{draft-ietf-mobileip-v2,
AUTHOR="C. Perkins",
TITLE="{IP} Mobility Support version 2",
TYPE="Internet Draft",
HOWPUBLISHED="draft-ietf-mobileip-v2-00",
INSTITUTION="Internet Engineering Task Force",
MONTH=nov,
YEAR=1997,
NOTE="Work in progress",
ABSTRACT="This document specifies protocol enhancements that allow
transparent routing of IP datagrams to mobile nodes in the Internet.
Each mobile node is always identified by its home address, regardless of
its current point of attachment to the Internet. While situated away
from its home, a mobile node is also associated with a care-of address,
which provides information about its current point of attachment to the
Internet. The protocol provides for registering the care-of address with
a home agent. The home agent sends datagrams destined for the mobile
node through a tunnel to the care-of address. After arriving at the end
of the tunnel, each datagram is then delivered to the mobile node.",
URL="http://www.ietf.org/internet-drafts/draft-ietf-mobileip-v2-00.txt"
}

@TECHREPORT{draft-ietf-ngtrans-header-trans,
AUTHOR="E. Nordmark",
TITLE="Stateless {IP/ICMP} Translator {(SIIT)}",
TYPE="Internet Draft",
HOWPUBLISHED="draft-ietf-ngtrans-header-trans-01",
INSTITUTION="Internet Engineering Task Force",
MONTH=nov,
YEAR=1997,
NOTE="Work in progress",
ABSTRACT="This document specifies a transition mechanism in addition to
those already specified in RFC 1933. The new mechanism can be used as
part of a solution that allows IPv6 hosts that do not have a permanently
assigned IPv4 address to communication with IPv4-only hosts.",
URL="http://www.ietf.org/internet-drafts/draft-ietf-ngtrans-header-trans-01.txt"
}

@TECHREPORT{draft-ietf-ngtrans-nnat,
AUTHOR="J. Bound",
TITLE="No Network Address Translation {(NNAT)} for {IPv6}",
TYPE="Internet Draft",
HOWPUBLISHED="draft-ietf-ngtrans-nnat-00",
INSTITUTION="Internet Engineering Task Force",
MONTH=nov,
YEAR=1997,
NOTE="Work in progress",
ABSTRACT="The initial deployment of IPv6 will require a tightly coupled
use of IPv4 addresses to support the interoperation of IPv6 and IPv4.
Nodes will be able to be deployed with IPv6 addresses, but will still
need to communicate with IPv4 nodes that do not have a dual IP layer
supporting both IPv4 and IPv6. This specification defines a mechanism
called No Network Address Translation (NNAT), which will assign an IPv6
node a temporary IPv4 address, which can be used to communicate with a
node that supports only IPv4.",
URL="http://www.ietf.org/internet-drafts/draft-ietf-ngtrans-nnat-00.txt"
}

@TECHREPORT{draft-ietf-pint-basics,
AUTHOR="S. Petrack",
TITLE="Basic Service Requirements, Definitions, and Architecture",
TYPE="Internet Draft",
HOWPUBLISHED="draft-ietf-pint-basics-00.txt,.ps",
INSTITUTION="Internet Engineering Task Force",
MONTH=nov,
YEAR=1997,
NOTE="Work in progress",
ABSTRACT="This document specifies those PSTN services which will be
accessible from the Internet via the PINT protocols. It defines these
services in terms of a simple set of architectural elements and atomic
services. It gives some concrete examples of these services, and
indicates how to build the examples out of the presented atomic
services.",
URL="http://www.ietf.org/internet-drafts/draft-ietf-pint-basics-00.txt,.ps"
}

@TECHREPORT{draft-ietf-pint-internet-callcenter,
AUTHOR="M. Lautenbacher and L. Conroy",
TITLE="{Pre-PINT} Callback Service Implementation Experiences",
TYPE="Internet Draft",
HOWPUBLISHED="draft-ietf-pint-internet-callcenter-00",
INSTITUTION="Internet Engineering Task Force",
MONTH=nov,
YEAR=1997,
NOTE="Work in progress",
ABSTRACT="This draft describes our experiences in developing an
Intelligent Network Service Node that provides Call Center functions,
using the Internet for (non-call) communications with customers and call
center agents. It shows one approach to the provision of an interface
between the Internet and the Public Switched Telephone Network (PSTN),
via the Intelligent Network (IN).",
URL="http://www.ietf.org/internet-drafts/draft-ietf-pint-internet-callcenter-00.txt"
}

@TECHREPORT{draft-ietf-pint-inweb,
AUTHOR="M. Krishnaswamy",
TITLE="{PSTN-Internet} Internetworking - An Architecture Overview",
TYPE="Internet Draft",
HOWPUBLISHED="draft-ietf-pint-inweb-00",
INSTITUTION="Internet Engineering Task Force",
MONTH=nov,
YEAR=1997,
NOTE="Work in progress",
ABSTRACT="This memo is submitted as input to the draft PINT (PSTN and
Internet Internetworking) Informational RFC. This document describes an
internetworking architecture of the Public Switched Telephone Network
(PSTN) and the Internet based on the Lucent prototype. This architecture
enables access to PSTN services from the Internet. The four basic PSTN
services that could be made available to an Internet User are described.
We have used the World Wide Web as an example to show how these PSTN
services can be seamlessly integrated into the Internet. Next a Service
Support Transport Protocol for reliable transfer of service request from
the Internet to the PSTN network is described. A simple Management
Information Base (MIB) that is used for uploading information and
performing authentication checks is then described.",
URL="http://www.ietf.org/internet-drafts/draft-ietf-pint-inweb-00.txt"
}

@TECHREPORT{draft-ietf-pint-sip,
AUTHOR="Henning Schulzrinne",
TITLE="{SIP} for {Click-To-Dial-Back} and {Third-Party} Control",
TYPE="Internet Draft",
HOWPUBLISHED="draft-ietf-pint-sip-00",
INSTITUTION="Internet Engineering Task Force",
MONTH=nov,
YEAR=1997,
NOTE="Work in progress",
ABSTRACT="SIP can also be used to control calls established by other
entities, for example, to have a computer control a PBX or a web server
ask an SCP to initiate a call to a standard telephone (''click-to-dial-
back''). We refer to the entity initiating the phone call as the
controller and the PBX or SCP as the PSTN server.",
URL="http://www.ietf.org/internet-drafts/draft-ietf-pint-sip-00.txt"
}

@TECHREPORT{draft-ietf-pktway-protocol-rrp1-spec,
AUTHOR="D. Cohen and C. Lund and T. Skjellum and T. McMahon and R. George",
TITLE="Part-1 of The {Router-to-Router} {(RRP)} {PacketWay} Protocol for
{High-Performance} Interconnection of Computer Clusters",
TYPE="Internet Draft",
HOWPUBLISHED="draft-ietf-pktway-protocol-rrp1-spec-00",
INSTITUTION="Internet Engineering Task Force",
MONTH=oct,
YEAR=1997,
NOTE="Work in progress",
ABSTRACT="The PktWay protocol is introduced in the 'The End-to-End (EEP)
PacketWay Protocol for High-Performance Interconnection of Computer
Clusters'. This document defines the basic part (Part 1) of the
Router-to-Router protocol (RRP) of PacketWay. The shorter 'PktWay' is
used for 'PacketWay'.",
URL="http://www.ietf.org/internet-drafts/draft-ietf-pktway-protocol-rrp1-spec-00.txt"
}

@TECHREPORT{draft-ietf-pppext-cobs,
AUTHOR="J. Carlson and M. Baker and S. Cheshire",
TITLE="{PPP} Consistent Overhead Byte Stuffing {(COBS)}",
TYPE="Internet Draft",
HOWPUBLISHED="draft-ietf-pppext-cobs-00",
INSTITUTION="Internet Engineering Task Force",
MONTH=nov,
YEAR=1997,
NOTE="Work in progress",
ABSTRACT="The Point-to-Point Protocol (PPP) [1] provides a standard
method for transporting multi-protocol datagrams over point-to-point
links. PPP also defines an extensible Link Control Protocol, which
allows the negotiation of optional frame encoding methods. This document
defines the Consistent Overhead Byte Stuffing (COBS) negotiation and
encapsulation procedure.",
URL="http://www.ietf.org/internet-drafts/draft-ietf-pppext-cobs-00.txt"
}

@TECHREPORT{draft-ietf-pppext-crtxchg,
AUTHOR="J. Zmuda and W. Nace",
TITLE="{PPP} Certificate Exchange Protocol",
TYPE="Internet Draft",
HOWPUBLISHED="draft-ietf-pppext-crtxchg-01",
INSTITUTION="Internet Engineering Task Force",
MONTH=dec,
YEAR=1997,
NOTE="Work in progress",
ABSTRACT="The Point-to-Point Protocol (PPP) [1] provides a standard
method for transporting multi-protocol datagrams over point-to-point
links PPP also defines an extensible Link Control Protocol, which allows
negotiation of an Authentication Protocol for authentication of its peer
before allowing Network Layer protocols to transmit over the link. The
Certificate exchange protocol is an extension to PPP that is in the form
of an additional phase, called the certificate exchange phase, that
would allow for a PPP entity to request certificates from a peer. If
configured, this phase would be negotiated during the LCP exchange. This
exchange of certificates is aimed at easing configuration issues by
providing for the exchange of certificate path information in a standard
manner across different strong, or public-key certificate-based,
authentication protocols. The certificate exchange protocol accomodates
arbitrary sized certificates.",
URL="http://www.ietf.org/internet-drafts/draft-ietf-pppext-crtxchg-01.txt"
}

@TECHREPORT{draft-ietf-pppext-eapdss,
AUTHOR="J. Zmuda and W. Nace",
TITLE="{PPP} {EAP} {DSS} Public Key Authentication Protocol",
TYPE="Internet Draft",
HOWPUBLISHED="draft-ietf-pppext-eapdss-01",
INSTITUTION="Internet Engineering Task Force",
MONTH=dec,
YEAR=1997,
NOTE="Work in progress",
ABSTRACT="The Point-to-Point Protocol (PPP) [1] provides a standard
method for transporting multi-protocol datagrams over point-to-point
links PPP also defines an extensible Link Control Protocol, which allows
negotiation of an Authentication Protocol for authentication of its peer
before allowing Network Layer protocols to transmit over the link. PPP
Extensible Authentication Protocol (EAP) [2] provides for a number of
authentication mechanisms. This document specifies yet another
authentication mechanism that may be used within the EAP framework. This
document defines the DSS Public Key Authentication Protocol within PPP
EAP.",
URL="http://www.ietf.org/internet-drafts/draft-ietf-pppext-eapdss-01.txt"
}

@TECHREPORT{draft-ietf-pppext-eapisakmp,
AUTHOR="G. Carter",
TITLE="{PPP} {EAP} {ISAKMP} Authentication Protocol",
TYPE="Internet Draft",
HOWPUBLISHED="draft-ietf-pppext-eapisakmp-00",
INSTITUTION="Internet Engineering Task Force",
MONTH=sep,
YEAR=1997,
NOTE="Work in progress",
ABSTRACT="The Point-to-Point Protocol (PPP) [RFC1661] provides a
standard method for transporting multi-protocol datagrams over
point-to-point links. PPP also defines an extensible Link Control
Protocol (LCP), which can be used to negotiate authentication methods,
as well as an Encryption Control Protocol (ECP) [RFC1968], used to
negotiate data encryption over PPP links, and a Compression Control
Protocol (CCP) [RFC1962], used to negotiate compression methods. The
Extensible Authentication Protocol (EAP) [EAP] is a PPP extension that
provides support for additional authentication methods within PPP. The
Internet Security Association and Key Management Protocol [ISAKMP]
combined with the Oakley [Oakley] key exchange protocol enables secure,
mutually authenticated security association exchanges between two
endpoints. This document describes how ISAKMP provides for these
mechanisms within EAP.",
URL="http://www.ietf.org/internet-drafts/draft-ietf-pppext-eapisakmp-00.txt"
}

@TECHREPORT{draft-ietf-pppext-eapkea,
AUTHOR="P. Yee and J. Zmuda and W. Nace",
TITLE="{PPP} {EAP} {KEA} Public Key Authentication Protocol",
TYPE="Internet Draft",
HOWPUBLISHED="draft-ietf-pppext-eapkea-01",
INSTITUTION="Internet Engineering Task Force",
MONTH=dec,
YEAR=1997,
NOTE="Work in progress",
ABSTRACT="The Point-to-Point Protocol (PPP) [1] provides a standard
method for transporting multi-protocol datagrams over point-to-point
links PPP also defines an extensible Link Control Protocol, which allows
negotiation of an Authentication Protocol for authentication of its peer
before allowing Network Layer protocols to transmit over the link. PPP
Extensible Authentication Protocol (EAP) [2] provides for a number of
authentication mechanisms. This document specifies yet another
authentication mechanism that may be used within the EAP framework. This
document defines the KEA Public Key Authentication Protocol within PPP
EAP. A side effect of KEA public key authentication is the creation of a
session key for encryption of data on the PPP link.",
URL="http://www.ietf.org/internet-drafts/draft-ietf-pppext-eapkea-01.txt"
}

@TECHREPORT{draft-ietf-pppext-feep,
AUTHOR="J. Zmuda and W. Nace",
TITLE="{PPP} Fortezza Encryption Encapsulation Protocol",
TYPE="Internet Draft",
HOWPUBLISHED="draft-ietf-pppext-feep-01",
INSTITUTION="Internet Engineering Task Force",
MONTH=dec,
YEAR=1997,
NOTE="Work in progress",
ABSTRACT="The Point-to-Point Protocol (PPP) [1] provides a standard
method for transporting multi-protocol datagrams over point-to-point
links PPP also defines an extensible Link Control Protocol, which allows
negotiation of an Authentication Protocol for authentication of its peer
before allowing Network Layer protocols to transmit over the link. One
of the Authentication protocols that can be negotiated is the EAP. The
EAP can be used in any of a number of variants. When the EAP is used in
it's KEA variant, this results in mutual authentication and key
generation. This key is available for use during the PPP data transfer
phase by an encryption encapsulation. The encryption encapsulation that
is described in this memo is one possible encapsulation that can use the
keying material generated by the EAP KEA protocol.",
URL="http://www.ietf.org/internet-drafts/draft-ietf-pppext-feep-01.txt"
}

@TECHREPORT{draft-ietf-pppext-l2tphc,
AUTHOR="A. Valencia",
TITLE="{L2TP} Header Compression {(''L2TPHC'')}",
TYPE="Internet Draft",
HOWPUBLISHED="draft-ietf-pppext-l2tphc-01",
INSTITUTION="Internet Engineering Task Force",
MONTH=dec,
YEAR=1997,
NOTE="Work in progress",
ABSTRACT="The Layer 2 Tunneling Protocol (``L2TP'') defines a mechanism
for tunneling PPP sessions over arbitrary media. There exists a class of
specific media and applications for which protocol overhead may be
optimized, and where such reduction results in improved operation. This
document describes the solution space addressed, its underlying
motivations, and the protocol modifications required. The enhancement to
the L2TP protocol is called L2TP Header Compression, or ``L2TPHC''.",
URL="http://www.ietf.org/internet-drafts/draft-ietf-pppext-l2tphc-01.txt"
}

@TECHREPORT{draft-ietf-radius-ipsec,
AUTHOR="P. Calhoun and S. Vakil",
TITLE="{RADIUS} {IP} Security Extensions",
TYPE="Internet Draft",
HOWPUBLISHED="draft-ietf-radius-ipsec-00",
INSTITUTION="Internet Engineering Task Force",
MONTH=nov,
YEAR=1997,
NOTE="Work in progress",
ABSTRACT="The RADIUS Authentication/Authorization protocol defines a
mechanism which is used by a Network Access Server (NAS) to authenticate
dial-up users. IP Security defines a mechanism of establishing a secure
link between two entities over a network. This document defines a
mechanism for RADIUS to inform the NAS of the security policies required
for secure communication with a host.",
URL="http://www.ietf.org/internet-drafts/draft-ietf-radius-ipsec-00.txt"
}

@TECHREPORT{draft-ietf-radius-mschap-attr,
AUTHOR="G. Zorn",
TITLE="{RADIUS} Attributes for {MS-CHAP} Support",
TYPE="Internet Draft",
HOWPUBLISHED="draft-ietf-radius-mschap-attr-01",
INSTITUTION="Internet Engineering Task Force",
MONTH=nov,
YEAR=1997,
NOTE="Work in progress",
ABSTRACT="This document describes a set of vendor-specific RADIUS
attributes designed to support the use of Microsoft's proprietary
dialect of PPP CHAP (MS-CHAP) in dial-up networks. MS-CHAP is derived
from and (where possible) consistent with PPP CHAP [1]; the differences
between PPP CHAP and MS-CHAP are significant enough to warrant the
definition of new RADIUS attributes, however.",
URL="http://www.ietf.org/internet-drafts/draft-ietf-radius-mschap-attr-01.txt"
}

@TECHREPORT{draft-ietf-radius-saltencrypt,
AUTHOR="D. Fox and P. Funk and D. Mitton and O. Tavakoli",
TITLE="{Salt-Encryption} of {RADIUS} Attributes",
TYPE="Internet Draft",
HOWPUBLISHED="draft-ietf-radius-saltencrypt-00",
INSTITUTION="Internet Engineering Task Force",
MONTH=dec,
YEAR=1997,
NOTE="Work in progress",
ABSTRACT="This document defines a general mechanism for encrypting
attributes within RADIUS packets. This mechanism permits more than one
attribute within a RADIUS transaction (request and response) to be
encrypted without compromising the security of the encryption.",
URL="http://www.ietf.org/internet-drafts/draft-ietf-radius-saltencrypt-00.txt"
}

@TECHREPORT{draft-ietf-rmonmib-rmonprot-v2,
AUTHOR="C. Bucci and R. Iddon and A. Bierman",
TITLE="Remote Network Monitoring {MIB} Protocol Identifiers (Version {2)}",
TYPE="Internet Draft",
HOWPUBLISHED="draft-ietf-rmonmib-rmonprot-v2-03",
INSTITUTION="Internet Engineering Task Force",
MONTH=oct,
YEAR=1997,
NOTE="Work in progress",
ABSTRACT="This memo describes protocol encapsulations which are
referenced by the management objects defined in the Remote Network
Monitoring MIB Version 2 [RFC2021]. Additionally, this memo defines a
notation describing protocol layers in a protocol encapsulation and
contains a large list of protocol definitions using this notation.
Although related to the original Remote Network Monitoring MIB
[RFC1757], this document refers only to objects found in the RMON-2 MIB.",
URL="http://www.ietf.org/internet-drafts/draft-ietf-rmonmib-rmonprot-v2-03.txt"
}

@TECHREPORT{draft-ietf-roamops-sec,
AUTHOR="Y. Jiang",
TITLE="Secure Radius Server Operation Guidelines for Dial Roaming",
TYPE="Internet Draft",
HOWPUBLISHED="draft-ietf-roamops-sec-00",
INSTITUTION="Internet Engineering Task Force",
MONTH=oct,
YEAR=1997,
NOTE="Work in progress",
ABSTRACT="Authenticating and authorizing roaming dialup users requires
messages to be exchanged among facilities managed by two or more service
providers, and secure operation of the facilities is of vital
importance. This document provides guidelines for operating such
facilities when using the Remote Authentication Dial In User Service
(RADIUS) protocol and the companion accounting protocol for
authentication and accounting message exchange.",
URL="http://www.ietf.org/internet-drafts/draft-ietf-roamops-sec-00.txt"
}

@TECHREPORT{draft-ietf-rps-extending,
AUTHOR="D. Meyer and C. Alaettinoglu and D. Kessens",
TITLE="Guidelines for Extending {RPSL}",
TYPE="Internet Draft",
HOWPUBLISHED="draft-ietf-rps-extending-00",
INSTITUTION="Internet Engineering Task Force",
MONTH=nov,
YEAR=1997,
NOTE="Work in progress",
ABSTRACT="This Internet Draft describes guidelines for extending the
Routing Policy Specification Language (RPSL) [3, 4]. Our experiences
with PRDB [2], RIPE-81 [6], and RIPE-181 [5] taught us that RPSL had to
be extensible. These languages were not extensible and each transition
to a new language turned out to be quite painful. As a result,
extensibility was a primary design goal for RPSL. New routing protocols
or new features to existing routing protocols can be easily handled
using RPSL's dictionary class. New classes or new attributes to the
existing classes can also be added.",
URL="http://www.ietf.org/internet-drafts/draft-ietf-rps-extending-00.txt"
}

@TECHREPORT{draft-ietf-rps-rpsl,
AUTHOR="E. Gerich and D. Karrenberg and D. Meyer and M. Terpstra and C. Villamizar
and C. Alaettinoglu and T. Bates",
TITLE="Routing Policy Specification Language {(RPSL)}",
TYPE="Internet Draft",
HOWPUBLISHED="draft-ietf-rps-rpsl-04.txt,.ps",
INSTITUTION="Internet Engineering Task Force",
MONTH=nov,
YEAR=1997,
NOTE="Work in progress",
ABSTRACT="This Internet Draft is the reference document for the Routing
Policy Specification Language (RPSL). RPSL allows a network operator to
be able to specify routing policies at various levels in the Internet
hierarchy; for example at the Autonomous System (AS) level. At the same
time, policies can be specified with sufficient detail in RPSL so that
low level router configurations can be generated from them. RPSL is
extensible; new routing protocols and new protocol features can be
introduced at any time. RPSL is a replacement for the current Internet
policy specification language known as RIPE-181 [4] or RFC-1786 [5].
RIPE-81 [6] was the first language deployed in the Internet for
specifying routing policies. It was later replaced by RIPE-181 [4].
Through operational use of RIPE-181 it has become apparent that certain
policies cannot be specified and a need for an enhanced and more
generalized language is needed. RPSL addresses RIPE-181's limitations.",
URL="http://www.ietf.org/internet-drafts/draft-ietf-rps-rpsl-04.txt,.ps"
}

@TECHREPORT{draft-ietf-rps-transition,
AUTHOR="D. Kessens and C. Orange",
TITLE="{RIPE-181} to {RPSL} Transition Plan",
TYPE="Internet Draft",
HOWPUBLISHED="draft-ietf-rps-transition-02",
INSTITUTION="Internet Engineering Task Force",
MONTH=nov,
YEAR=1997,
NOTE="Work in progress",
ABSTRACT="The standardization of RPSL (Routing Policy Specification
Language) is imminent, and there is a user community eager to make use
of the power- ful features it offers in the Routing Registry (IRR).
Thus, a plan of action is needed to assure a successful transition from
the RIPE-181 language currently employed to describe routing policies in
the IRR to the more expressive RPSL. This document describes such a
plan, which the authors believe can be used to bring about a successful
transition in a timely fashion with a minimum of disruption to the IRR
and its cur- rent role in Internet routing. This document will be
modified to reflect the progress of the transition if appropriate.",
URL="http://www.ietf.org/internet-drafts/draft-ietf-rps-transition-02.txt"
}

@TECHREPORT{draft-ietf-rsvp-mib,
AUTHOR="F. Baker and J. Krawczyk and A. Sastry",
TITLE="{RSVP} Management Information Base",
TYPE="Internet Draft",
HOWPUBLISHED="draft-ietf-rsvp-mib-10",
INSTITUTION="Internet Engineering Task Force",
MONTH=aug,
YEAR=1997,
NOTE="Work in progress",
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 the Resource
Reservation Protocol (RSVP) within the interface attributes defined in
the Integrated Services Model. Thus, the Integrated Services MIB is
directly relevant to and cross-referenced by this MIB. Comments should
be made to the RSVP Working Group, rsvp(at)isi.edu. This memo does not, in
its draft form, specify a standard for the Internet community.",
URL="http://www.ietf.org/internet-drafts/draft-ietf-rsvp-mib-10.txt"
}

@TECHREPORT{draft-ietf-rsvp-pepci,
AUTHOR="Jim Boyle and Ron Cohen and Laura Cunningham and David Durham and Arun
Sastry and Raj Yavatkar",
TITLE="Protocol for Exchange of {PoliCy} Information {(PEPCI)}",
TYPE="Internet Draft",
HOWPUBLISHED="draft-ietf-rsvp-pepci-00",
INSTITUTION="Internet Engineering Task Force",
MONTH=jul,
YEAR=1997,
NOTE="Work in progress",
KEYWORDS="RSVP; policy; resource reservation",
ABSTRACT="This document describes a simple client/server model for
supporting policy for RSVP, and is designed to be extensible so that
other kinds of client types may be supported in the future. The model
does not make any assumptions about the algorithm of the policy server,
but is based on the server returning a single priority value in response
to a policy request. The objective is to use this very basic model to
begin policy experimentation.",
URL="http://www.ietf.org/internet-drafts/draft-ietf-rsvp-pepci-00.txt"
}

@TECHREPORT{draft-ietf-rsvp-policy-ext,
AUTHOR="Shai Herzog",
TITLE="{RSVP} Extensions for Policy Control",
TYPE="Internet Draft",
HOWPUBLISHED="draft-ietf-rsvp-policy-ext-02",
INSTITUTION="Internet Engineering Task Force",
MONTH=apr,
YEAR=1997,
NOTE="Work in progress",
ABSTRACT="This memo presents a set of extensions for supporting generic
policy based admission control in RSVP. These extensions include the
standard format of POLICY\_DATA objects, a generic RSVP/Policy-Control
interface, and a description of RSVP's",
URL="http://www.ietf.org/internet-drafts/draft-ietf-rsvp-policy-ext-02.txt"
}

@TECHREPORT{draft-ietf-rsvp-policy-oops,
AUTHOR="R. Guerin and S. Herzog and R. Rajan and D. Pendarakis",
TITLE="Open Outsourcing Policy Service {(OOPS)} for {RSVP}",
TYPE="Internet Draft",
HOWPUBLISHED="draft-ietf-rsvp-policy-oops-01.ps",
INSTITUTION="Internet Engineering Task Force",
MONTH=aug,
YEAR=1997,
NOTE="Work in progress",
ABSTRACT="This document describes a protocol for exchanging policy
information and decisions between an RSVP-capable router (client) and a
policy server. The OOPS protocol supports a wide range of router
configurations and RSVP implementations, and is compatible with the RSVP
Extensions for Policy Control [Ext].",
URL="http://www.ietf.org/internet-drafts/draft-ietf-rsvp-policy-oops-01.ps"
}

@TECHREPORT{draft-ietf-smime-crs,
AUTHOR="H. Prafullchandra and B. Fox and X. Liu and M. Myers and J. Weinstein",
TITLE="Certificate Request Syntax",
TYPE="Internet Draft",
HOWPUBLISHED="draft-ietf-smime-crs-00",
INSTITUTION="Internet Engineering Task Force",
MONTH=nov,
YEAR=1997,
NOTE="Work in progress",
ABSTRACT="This document defines an Internet PKI Certificate Request
Syntax (CRS). It addresses a growing need within the Internet PKI
community for an interface to public key certification products and
services based on PKCS7 [PKCS7] and PKCS10 [PKCS10]. A small number of
additional services are defined to supplement the core certificate
request service. Current industry practice regarding the use of PKCS7
and PKCS10 is also documented for the benefit of the Internet community.
In general, the use of PKCS7 in this document is aligned to the
Cryptographic Message Syntax [CMS] which provides a superset of the
PKCS7 syntax. Throughout this document, the term CMS should be taken to
include the PKCS #7 document as defined in [PKCS7]. The term CRS refers
to this specification. The chief differences between CRS and PKIXMGMT
are: - Use of PKCS7 for security encapsulation and transaction framework
- Use of PKCS10 as the certification request message content -
Certification of Diffie-Hellman Public Keys based on PKCS10 requests -
No assumption of reliable connectivity or persistent on-line operation -
Single request/response transaction model",
URL="http://www.ietf.org/internet-drafts/draft-ietf-smime-crs-00.txt"
}

@TECHREPORT{draft-ietf-snmpv3-acm,
AUTHOR="K. McCloghrie and B. Wijnen and R. Presuhn",
TITLE="View-based Access Control Model {(VACM)} for the Simple Network Management
Protocol {(SNMP)}",
TYPE="Internet Draft",
HOWPUBLISHED="draft-ietf-snmpv3-acm-05",
INSTITUTION="Internet Engineering Task Force",
MONTH=dec,
YEAR=1997,
NOTE="Work in progress",
ABSTRACT="This document describes the View-based Access Control Model
for use in the SNMP architecture [SNMP-ARCH]. It defines the Elements of
Procedure for controlling access to management information. This
document also includes a MIB for remotely managing the configuration
parameters for the View-based Access Control Model.",
URL="http://www.ietf.org/internet-drafts/draft-ietf-snmpv3-acm-05.txt"
}

@TECHREPORT{draft-ietf-snmpv3-appl,
AUTHOR="B. Stewart and D. Levi and P. Meyer",
TITLE="{SNMPv3} Applications",
TYPE="Internet Draft",
HOWPUBLISHED="draft-ietf-snmpv3-appl-05",
INSTITUTION="Internet Engineering Task Force",
MONTH=dec,
YEAR=1997,
NOTE="Work in progress",
ABSTRACT="This memo describes five types of SNMP applications which make
use of an SNMP engine as described in [SNMP-ARCH]. The types of
application described are Command Generators, Command Responders,
Notification Originators, Notification Receivers, and Proxy Forwarders.
This memo also defines MIB modules for specifying targets of management
operations, for notification filtering, and for proxy forwarding.",
URL="http://www.ietf.org/internet-drafts/draft-ietf-snmpv3-appl-05.txt"
}

@TECHREPORT{draft-ietf-snmpv3-next-gen-arch,
AUTHOR="B. Wijnen and R. Presuhn and D. Harrington",
TITLE="An Architecture for Describing {SNMP} Management Frameworks",
TYPE="Internet Draft",
HOWPUBLISHED="draft-ietf-snmpv3-next-gen-arch-07",
INSTITUTION="Internet Engineering Task Force",
MONTH=dec,
YEAR=1997,
NOTE="Work in progress",
ABSTRACT="This document describes an architecture for describing SNMP
Management Frameworks. The architecture is designed to be modular to
allow the evolution of the SNMP protocol standards over time. The major
portions of the architecture are an SNMP engine containing a Message
Processing Subsystem, a Security Subsystem and an Access Control
Subsystem, and possibly multiple SNMP applications which provide
specific functional processing of management data.",
URL="http://www.ietf.org/internet-drafts/draft-ietf-snmpv3-next-gen-arch-07.txt"
}

@TECHREPORT{draft-ietf-snmpv3-usm,
AUTHOR="B. Wijnen",
TITLE="User-based Security Model {(USM)} for version 3 of the Simple Network
Management Protocol {(SNMPv3)}",
TYPE="Internet Draft",
HOWPUBLISHED="draft-ietf-snmpv3-usm-04",
INSTITUTION="Internet Engineering Task Force",
MONTH=dec,
YEAR=1997,
NOTE="Work in progress",
ABSTRACT="This document describes the User-based Security Model (USM)
for SNMP version 3 for use in the SNMP architecture [SNMP-ARCH]. It
defines the Elements of Procedure for providing SNMP message level
security. This document also includes a MIB for remotely
monitoring/managing the configuration parameters for this Security
Model.",
URL="http://www.ietf.org/internet-drafts/draft-ietf-snmpv3-usm-04.txt"
}

@TECHREPORT{draft-ietf-snmpv3-v3mpc-model,
AUTHOR="J. Case and B. Wijnen and R. Presuhn and D. Harrington",
TITLE="Message Processing and Dispatching for the Simple Network Management
Protocol {(SNMP)}",
TYPE="Internet Draft",
HOWPUBLISHED="draft-ietf-snmpv3-v3mpc-model-07",
INSTITUTION="Internet Engineering Task Force",
MONTH=dec,
YEAR=1997,
NOTE="Work in progress",
ABSTRACT="This document describes the Message Processing and Dispatching
for SNMP messages within the SNMP architecture [SNMP-ARCH]. It defines
the procedures for dispatching potentially multiple versions of SNMP
messages to the proper SNMP Message Processing Models, and for
dispatching PDUs to SNMP applications. This document also describes one
Message Processing Model - the SNMPv3 Message Processing Model.",
URL="http://www.ietf.org/internet-drafts/draft-ietf-snmpv3-v3mpc-model-07.txt"
}

@TECHREPORT{draft-ietf-spki-cert-structure,
AUTHOR="B. Lampson and T. Ylonen and R. Rivest and W. Frantz and C. Ellison and B.
Thomas",
TITLE="Simple Public Key Certificate",
TYPE="Internet Draft",
HOWPUBLISHED="draft-ietf-spki-cert-structure-04",
INSTITUTION="Internet Engineering Task Force",
MONTH=dec,
YEAR=1997,
NOTE="Work in progress",
ABSTRACT="This document specifies a standard form of digital certificate
that is both more general and simpler than what is traditionally
considered to be a certificate. Since the word ''certificate'' was first
used by Loren Kohnfelder in 1978 to refer to a signed record holding a
name and a public key, it has been assumed that the only purpose of a
certificate has been to bind a public key to a globally unique name and
therefore to a person. This binding was assumed both necessary and
sufficient for security. The SPKI working group has found that the
creation of a globally unique name is neither necessary nor sufficient
for Internet security or electronic commerce. In fact, it can lead to a
security flaw. Therefore, we define certificate forms for binding local
names to keys (to retain security while offering the convenience of
meaningful names) and for assigning authorizations to keys (to provide
adequate information for real applications). These forms can be used
alone or together.",
URL="http://www.ietf.org/internet-drafts/draft-ietf-spki-cert-structure-04.txt"
}

@TECHREPORT{draft-ietf-srvloc-printer-scheme,
AUTHOR="P. Pierre",
TITLE="{URLs} for use with Service Location",
TYPE="Internet Draft",
HOWPUBLISHED="draft-ietf-srvloc-printer-scheme-00",
INSTITUTION="Internet Engineering Task Force",
MONTH=nov,
YEAR=1997,
NOTE="Work in progress",
ABSTRACT="This document defines the printer service type and the
attributes associated with it. This template is designed to be used in
conjuction with the Service Location Protocol [1], but may be used with
any directory service supporting attribute/value pair registration. The
printer service type is designed as an abstract service type. It is
expected that printers advertised with the printer type may be
accessible by one or more protocols. IPP and lpr are a two examples of
printing protocols that may be used to perform the actual printing
function.",
URL="http://www.ietf.org/internet-drafts/draft-ietf-srvloc-printer-scheme-00.txt"
}

@TECHREPORT{draft-ietf-svrloc-slp-mib,
AUTHOR="P. Pierre",
TITLE="{SNMP} {MIB} for {SLP} Directory Agents",
TYPE="Internet Draft",
HOWPUBLISHED="draft-ietf-svrloc-slp-mib-00",
INSTITUTION="Internet Engineering Task Force",
MONTH=nov,
YEAR=1997,
NOTE="Work in progress",
ABSTRACT="This memo defines a Management Information Base (MIB) for the
Service Location Protocol (SLP). The MIB describes the statistics and
alerts required to allow management of Service Location Protocol enabled
entities. The SLP MIB conforms to the Structure of Management
Information (SMI), as described in RFC 1902. It is intended for use with
the Simple Network Management Protocol, version 2.",
URL="http://www.ietf.org/internet-drafts/draft-ietf-svrloc-slp-mib-00.txt"
}

@TECHREPORT{draft-ietf-svrloc-wasrv,
AUTHOR="J. Rosenberg and Henning Schulzrinne and B. Suter",
TITLE="Wide Area Network Service Location",
TYPE="Internet Draft",
HOWPUBLISHED="draft-ietf-svrloc-wasrv-01",
INSTITUTION="Internet Engineering Task Force",
MONTH=dec,
YEAR=1997,
NOTE="Work in progress",
ABSTRACT="We propose extensions to the Service Location Protocol (SLP),
which allow for registration and discovery of services scattered across
the wide area network. We make use of scalable wide area multicast to
allow agents within an administrative domain to learn about services
within other domains. We also describe a new agent, the Brokering Agent
(BA), which is responsible for providing information about a particular
set of services types.",
URL="http://www.ietf.org/internet-drafts/draft-ietf-svrloc-wasrv-01.txt"
}

@TECHREPORT{draft-ietf-udlr-dtpc,
AUTHOR="A. Tosaka and H. Izumiyama",
TITLE="Dynamic Tunneling Path Configuration for Uni-directional Link Routing",
TYPE="Internet Draft",
HOWPUBLISHED="draft-ietf-udlr-dtpc-00",
INSTITUTION="Internet Engineering Task Force",
MONTH=nov,
YEAR=1997,
NOTE="Work in progress",
ABSTRACT="The idea to use unidirectional link(UDL) routing without any
modifications of current routing protocols is described in [1], but any
dynamic tunneling path configuration technique was not described. This
document describe the dynamic tunneling path configuration for UDL
routing.",
URL="http://www.ietf.org/internet-drafts/draft-ietf-udlr-dtpc-00.txt"
}

@TECHREPORT{draft-ietf-udlr-dvmrp,
AUTHOR="W. Dabbous and E. Duros",
TITLE="Handling of unidirectional links with {DVMRP}",
TYPE="Internet Draft",
HOWPUBLISHED="draft-ietf-udlr-dvmrp-00",
INSTITUTION="Internet Engineering Task Force",
MONTH=nov,
YEAR=1997,
NOTE="Work in progress",
ABSTRACT="This document defines the modifications which can be applied
to DVMRP [rfc1075] which make the communication over asymmetric links
feasible.",
URL="http://www.ietf.org/internet-drafts/draft-ietf-udlr-dvmrp-00.txt"
}

@TECHREPORT{draft-ietf-udlr-general,
AUTHOR="W. Dabbous and E. Duros",
TITLE="Supporting Unidirectional Paths in the Internet",
TYPE="Internet Draft",
HOWPUBLISHED="draft-ietf-udlr-general-00",
INSTITUTION="Internet Engineering Task Force",
MONTH=nov,
YEAR=1997,
NOTE="Work in progress",
ABSTRACT="Many distributed applications may benefit from a high
bandwidth connection to the Internet. However, this requires high
bandwidth links between remotes sites. A low-cost solution to deliver
high bandwidth services over wide geographical areas via the use of
broadcast satellite networks has been proposed by [ASBD]. However, this
solution is based on low cost receivers with zero bandwidth return.
Connection over the satellite link is therefore unidirectional. The
integration of these satellite networks with the Internet requires
changes in common routing protocols.",
URL="http://www.ietf.org/internet-drafts/draft-ietf-udlr-general-00.txt"
}

@TECHREPORT{draft-ietf-udlr-ospf,
AUTHOR="E. Duros",
TITLE="Handling of unidirectional links with {OSPF}",
TYPE="Internet Draft",
HOWPUBLISHED="draft-ietf-udlr-ospf-00",
INSTITUTION="Internet Engineering Task Force",
MONTH=nov,
YEAR=1997,
NOTE="Work in progress",
ABSTRACT="This document defines the modifications which can be applied
to OSPF [rfc1583] which make the communication over asymmetric links
feasible.",
URL="http://www.ietf.org/internet-drafts/draft-ietf-udlr-ospf-00.txt"
}

@TECHREPORT{draft-ietf-udlr-rip,
AUTHOR="C. Huitema and E. Duros",
TITLE="Handling of unidirectional links with {RIP}",
TYPE="Internet Draft",
HOWPUBLISHED="draft-ietf-udlr-rip-00",
INSTITUTION="Internet Engineering Task Force",
MONTH=nov,
YEAR=1997,
NOTE="Work in progress",
ABSTRACT="This document defines the modifications which can be applied
to RIP [rfc1723] which make the communication over asymmetric links
feasible.",
URL="http://www.ietf.org/internet-drafts/draft-ietf-udlr-rip-00.txt"
}

@TECHREPORT{draft-ietf-udlr-vipre,
AUTHOR="J. Stepanek and S. Schwab",
TITLE="{VIPRE} {--} Virtual Internet Packet Relay An Encapsulation Architecture
for Unidirectional Links",
TYPE="Internet Draft",
HOWPUBLISHED="draft-ietf-udlr-vipre-00",
INSTITUTION="Internet Engineering Task Force",
MONTH=nov,
YEAR=1997,
NOTE="Work in progress",
ABSTRACT="This memo describes a method of incorporating unidirectional
links into an IP network in a bidirectional mode by relaying
encapsulated IP packets over a bidirectional network.",
URL="http://www.ietf.org/internet-drafts/draft-ietf-udlr-vipre-00.txt"
}

@TECHREPORT{draft-ietf-udlr-wide-tunnel,
AUTHOR="A. Kato and A. Tosaka and H. Izumiyama",
TITLE="An {IP} tunneling approach for Uni-directional Link routing",
TYPE="Internet Draft",
HOWPUBLISHED="draft-ietf-udlr-wide-tunnel-00",
INSTITUTION="Internet Engineering Task Force",
MONTH=nov,
YEAR=1997,
NOTE="Work in progress",
ABSTRACT="Since digital multichannel TV broadcasting services have been
started in many areas, low cost digital data receivers are available.
They can be used for not only TV broadcasting service but also any kind
of data communication services. A low cost receiver can receive high
bandwidth traffic from a feed, while no bandwidth from the receiver to
the feed is provided. Therefore the connection between the feed and the
receiver is unidirectional. Current routing protocols stand on a fact
that any links are bidirectional even if the bandwidth in each direction
may be different. They can not handle unidirectional links. This
document defines an idea to use unidirectional links (UDLs) routing
without any modifications of current routing protocols.",
URL="http://www.ietf.org/internet-drafts/draft-ietf-udlr-wide-tunnel-00.txt"
}

@TECHREPORT{draft-ietf-urlreg-noreg,
AUTHOR="Y. Goland",
TITLE="{NOREG} {URL} Naming Scheme",
TYPE="Internet Draft",
HOWPUBLISHED="draft-ietf-urlreg-noreg-00",
INSTITUTION="Internet Engineering Task Force",
MONTH=nov,
YEAR=1997,
NOTE="Work in progress",
ABSTRACT="This document proposes mapping DNS names into the URL scheme
space for the purpose of preventing namespace collisions amongst URL
schemes whose syntax and functionality are not appropriate for
standardization.",
URL="http://www.ietf.org/internet-drafts/draft-ietf-urlreg-noreg-00.txt"
}

@TECHREPORT{draft-ietf-urn-biblio,
AUTHOR="C. Lynch and C. Preston and R. Daniel",
TITLE="Using Existing Bibliographic Identifiers as Uniform Resource Names",
TYPE="Internet Draft",
HOWPUBLISHED="draft-ietf-urn-biblio-02",
INSTITUTION="Internet Engineering Task Force",
MONTH=sep,
YEAR=1997,
NOTE="Work in progress",
ABSTRACT="A system for Uniform Resource Names (URNs) must be capable of
supporting identifiers from existing widely-used naming systems. This
document discusses how three major bibliographic identifiers (the ISBN,
ISSN and SICI) can be supported within the URN framework and the
currently proposed syntax for URNs.",
URL="http://www.ietf.org/internet-drafts/draft-ietf-urn-biblio-02.txt"
}

@TECHREPORT{draft-ietf-urn-req-frame,
AUTHOR="K. Sollins",
TITLE="Architectural Principles of Uniform Resource Name Resolution",
TYPE="Internet Draft",
HOWPUBLISHED="draft-ietf-urn-req-frame-04",
INSTITUTION="Internet Engineering Task Force",
MONTH=sep,
YEAR=1997,
NOTE="Work in progress",
ABSTRACT="This document addresses the issues of the discovery of URN
(Uniform Resource Name) resolver services that in turn will directly
translate URNs into URLs (Uniform Resource Locators) and URCs (Uniform
Resource Characteristics). The document falls into three major parts,
the assumptions underlying the work, the guidelines in order to be a
viable Resolver Discovery Service or RDS, and a framework for designing
RDSs. The guidelines fall into three principle areas: evolvability,
usability, and security and privacy. An RDS that is compliant with the
framework will not necessarily be compliant with the guidelines.
Compliance with the guidelines will need to be validated separately.",
URL="http://www.ietf.org/internet-drafts/draft-ietf-urn-req-frame-04.txt"
}

@TECHREPORT{draft-ietf-webdav-acreq,
AUTHOR="H. Palmer",
TITLE="Requirements for Access Control within Distributed Authoring and Versioning
Environments on the World Wide Web",
TYPE="Internet Draft",
HOWPUBLISHED="draft-ietf-webdav-acreq-00",
INSTITUTION="Internet Engineering Task Force",
MONTH=nov,
YEAR=1997,
NOTE="Work in progress",
ABSTRACT="To provide a robust model for modifying documents and data
within a distributed World Wide Web authoring environment, it is
necessary to furnish a methodology which controls access to objects.
Access control may include the ability to read an object, modify an
object, or perform other more advanced functions upon an object. Access
control is necessary to prevent unauthorized access or modification of
objects within the authoring environment which could lead to unintended
loss, damage or disclosure of data. This document proposes requirements
for the support of access control within a Web Distributed Authoring and
Versioning (WebDAV) environment. It describes a model for the
representation and interpretation of access control policies, and a set
of operations needed to manage policies in that form. It is intended
that these requirements be supported within the framework of the
proposed WebDAV extensions [WEBDAV1] to HTTP [HTTP], in the form of
additional protocol operations and compliance requirements for clients
and servers",
URL="http://www.ietf.org/internet-drafts/draft-ietf-webdav-acreq-00.txt"
}

@TECHREPORT{draft-ietf-webdav-depth,
AUTHOR="Y. Goland and S. Reddy",
TITLE="{WebDAV} Tree Operations",
TYPE="Internet Draft",
HOWPUBLISHED="draft-ietf-webdav-depth-01",
INSTITUTION="Internet Engineering Task Force",
MONTH=nov,
YEAR=1997,
NOTE="Work in progress",
ABSTRACT="The WebDAV protocol specification [Goland et al., 1997]
defines the DELETE, COPY and MOVE methods. However these methods have a
scope of a single source resource. It is common for principals to wish
to perform a DELETE, COPY or MOVE on a collection and all its internal
members. This specification defines the DELETE-TREE, COPY-TREE and
MOVE-TREE methods that perform the equivalent of DELETE, COPY and MOVE
across a collection and all its progeny.",
URL="http://www.ietf.org/internet-drafts/draft-ietf-webdav-depth-01.txt"
}

@TECHREPORT{draft-ietf-webdav-requirements,
AUTHOR="D. Durand and J. Whitehead and J. Slein and F. Vitali",
TITLE="Requirements for a Distributed Authoring and Versioning Protocol",
TYPE="Internet Draft",
HOWPUBLISHED="draft-ietf-webdav-requirements-03",
INSTITUTION="Internet Engineering Task Force",
MONTH=sep,
YEAR=1997,
NOTE="Work in progress",
ABSTRACT="Current World Wide Web (WWW or Web) standards provide simple
support for applications which allow remote editing of typed data. In
practice, the existing capabilities of the WWW have proven inadequate to
support efficient, scalable remote editing free of overwriting
conflicts. This document presents a list of features in the form of
requirements for a Web Distributed Authoring and Versioning protocol
which, if implemented, would improve the efficiency of common remote
editing operations, provide a locking mechanism to prevent overwrite
conflicts, improve link management support between non-HTML data types,
provide a simple attribute-value metadata facility, provide for the
creation and reading of container data types, and integrate versioning
into the WWW.",
URL="http://www.ietf.org/internet-drafts/draft-ietf-webdav-requirements-03.txt"
}

@TECHREPORT{draft-katsube-csr-arch,
AUTHOR="Y. Katsube and H. Esaki and K. Nagami and Y. Ohba and S. Matsuzawa",
TITLE="Cell Switch Router - Architecture and Protocol Overview -",
TYPE="Internet Draft",
HOWPUBLISHED="draft-katsube-csr-arch-00",
INSTITUTION="Internet Engineering Task Force",
MONTH=dec,
YEAR=1997,
NOTE="Work in progress",
ABSTRACT="This memorandum describes an internetworking architecture of
Cell Switch Router (CSR) and related control protocol overview. Cell
Switch Router is an ATM-based label switching router that can provide
ATM cut-through paths for packet flows with various levels of
granularity while retaining current router-based internetworking
architecture. The proposed architecture is able to provide the
cut-through path in response to the creation of IP forwarding entry
(topology-driven), the arrival of data packets (traffic-driven), and the
reception of control packets such as RSVP (request-driven). One
important feature that is provided by the proposed architecture is
interoperability with the emerging ATM network platform, specified by
the ATM Forum and/or ITU-T, which provides PVC (Permanent Virtual
Channel), VP (Virtual Path), or SVC (Switched Virtual Channel) services.",
URL="http://www.ietf.org/internet-drafts/draft-katsube-csr-arch-00.txt"
}

@TECHREPORT{draft-katsube-mpls-two-ldp,
AUTHOR="Y. Katsube and K. Nagami and Y. Ohba",
TITLE="Two Modes of {MPLS} Explicit Label Distribution Protocol",
TYPE="Internet Draft",
HOWPUBLISHED="draft-katsube-mpls-two-ldp-00",
INSTITUTION="Internet Engineering Task Force",
MONTH=oct,
YEAR=1997,
NOTE="Work in progress",
ABSTRACT="This memo discusses characteristics of two types of MPLS
protocol operations, which we call 'Edge Control' operation and
'Distributed' operation individually, and proposes that these two mode
of protocol operations should be specified as the explicit Label
Distribution Protocol for the MPLS.",
URL="http://www.ietf.org/internet-drafts/draft-katsube-mpls-two-ldp-00.txt"
}

@TECHREPORT{draft-kaukonen-cipher-arcfour,
AUTHOR="R. Thayer and K. Kaukonen",
TITLE="A Stream Cipher Encryption Algorithm 'Arcfour'",
TYPE="Internet Draft",
HOWPUBLISHED="draft-kaukonen-cipher-arcfour-01",
INSTITUTION="Internet Engineering Task Force",
MONTH=jul,
YEAR=1997,
NOTE="Work in progress",
ABSTRACT="This document describes an algorithm here called Arcfour that
is believed to be fully interoperable with the RC4 algoritm. RC4 is
trademark of RSA Data Security, Inc. There is a need in the Internet
community for an encryption algorithm that provides interoperable
operation with existing deployed commercial cryptographic applications.
This interoperability will allow for a smoother transition to protocols
that have been developed through the IETF standards process.",
URL="http://www.ietf.org/internet-drafts/draft-kaukonen-cipher-arcfour-01.txt"
}

@TECHREPORT{draft-kessens-ride-classes,
AUTHOR="R. Wesson and D. Kessens and D. Shah",
TITLE="{RIDE} classes",
TYPE="Internet Draft",
HOWPUBLISHED="draft-kessens-ride-classes-01",
INSTITUTION="Internet Engineering Task Force",
MONTH=sep,
YEAR=1997,
NOTE="Work in progress",
ABSTRACT="This document describes the attributes and classes that will
be used in the internet Registry Information Database Exchange formats
(RIDE). For now it is mostly limited to 'domain' and 'contact' classes
since they were widely considered as most urgent. Encoding that will be
used for the objects and ways to find and access objects are beyond the
scope of this document. This will be addressed in the future in separate
drafts.",
URL="http://www.ietf.org/internet-drafts/draft-kessens-ride-classes-01.txt"
}

@TECHREPORT{draft-kessens-ride-referencing,
AUTHOR="D. Conrad and W. Woeber and D. Kessens",
TITLE="{RIDE} referencing",
TYPE="Internet Draft",
HOWPUBLISHED="draft-kessens-ride-referencing-00",
INSTITUTION="Internet Engineering Task Force",
MONTH=sep,
YEAR=1997,
NOTE="Work in progress",
ABSTRACT="This document describes two variants of a proposal on how to
find information regarding some critical resources (domain names, IP
addresses and routing registry information) on the Internet. The
proposed solution uses globally unique registry identifiers that are
derived from a domain name in use by a registry.",
URL="http://www.ietf.org/internet-drafts/draft-kessens-ride-referencing-00.txt"
}

@TECHREPORT{draft-kessens-ride-requirements,
AUTHOR="D. Kessens",
TITLE="{RIDE} functional requirements",
TYPE="Internet Draft",
HOWPUBLISHED="draft-kessens-ride-requirements-00",
INSTITUTION="Internet Engineering Task Force",
MONTH=sep,
YEAR=1997,
NOTE="Work in progress",
ABSTRACT="This document describes the (functional) requirements for the
RIDE format and protocols.",
URL="http://www.ietf.org/internet-drafts/draft-kessens-ride-requirements-00.txt"
}

@TECHREPORT{draft-kim-tld-class,
AUTHOR="J. Kim",
TITLE="{DNS} Top Level Domain Name Classification and Structure",
TYPE="Internet Draft",
HOWPUBLISHED="draft-kim-tld-class-00",
INSTITUTION="Internet Engineering Task Force",
MONTH=aug,
YEAR=1997,
NOTE="Work in progress",
ABSTRACT="This document specifies a structural organization of Internet
top level domain names based on the International Schedule of Classes of
Goods and Services. This structure intends to provide a framework for
classification such that web content providers can differentiate their
goods and services and minimize the probability of name confusion and
collision. Under each class, as specified by the International Schedule
of Classes of Goods and Services, single or multiple top level domain
names should be specified each appropriately partitioning the class of
goods or service into an appropriate sub-categorization. A method will
further be described to incorporate additions/modifications as becomes
necessary by as of yet unforseen future developments. This document does
not address the delegation or the administration of top level domain
names which the author feels should be considered separately. However,
the author does acknowledge that some form of centralized authority
should be in place to properly control the structure to be described.",
URL="http://www.ietf.org/internet-drafts/draft-kim-tld-class-00.txt"
}

@TECHREPORT{draft-kindel-uuid-uri,
AUTHOR="C. Kindel",
TITLE="{URI} scheme",
TYPE="Internet Draft",
HOWPUBLISHED="draft-kindel-uuid-uri-00",
INSTITUTION="Internet Engineering Task Force",
MONTH=nov,
YEAR=1997,
NOTE="Work in progress",
ABSTRACT="This memo describes a Universal Resource Identifier (URI)
scheme that allows resources to be uniquely named over time and space
using Universally Unique Identifiers (UUIDs). A UUID URI is a pure URI,
in that it contains no information about location. However due to the
uniqueness of UUIDs, a UUID URI is persistent over time, much like URNs.
UUID URIs are useful in situations where a unique identifier is required
that cannot or should not be tied to a particular physical root
namespace (such as a DNS name).",
URL="http://www.ietf.org/internet-drafts/draft-kindel-uuid-uri-00.txt"
}

@TECHREPORT{draft-klyne-conneg-requirements,
AUTHOR="G. Klyne",
TITLE="Requirements for protocol-independent content negotiation",
TYPE="Internet Draft",
HOWPUBLISHED="draft-klyne-conneg-requirements-00",
INSTITUTION="Internet Engineering Task Force",
MONTH=dec,
YEAR=1997,
NOTE="Work in progress",
ABSTRACT="A number of Internet application protocols have a need to
provide content negotiation for the resources with which they interact.
MIME media types [1, 2] provide a standard method for handling one major
axis of variation, but resources also vary in ways which cannot be
expressed using currently available MIME headers. The case for a
cross-protocol negotiation framework is set out in [4]. This draft sets
out an abstract framework and requirements for protocol-independent
content negotiation, and identifies a number of technical issues which
may need to be addressed. The abstract framework does not attempt to
specify the content negotiation process, but gives an indication of the
anticipated scope and form of any such specification. The requirements
set out the desired properties of a content negotiation mechanism.",
URL="http://www.ietf.org/internet-drafts/draft-klyne-conneg-requirements-00.txt"
}

@TECHREPORT{draft-koch-dnsind-local-compression,
AUTHOR="P. Koch",
TITLE="A New Scheme for the Compression of Domain Names",
TYPE="Internet Draft",
HOWPUBLISHED="draft-koch-dnsind-local-compression-00",
INSTITUTION="Internet Engineering Task Force",
MONTH=nov,
YEAR=1997,
NOTE="Work in progress",
ABSTRACT="The compression of domain names in DNS messages was introduced
in [RFC1035]. Although some remarks were made about applicability to
future defined resource record types, no method has been deployed yet to
support interoperable DNS compression for RR types specified since then.
This document summarizes current problems and proposes a new compression
scheme to be applied to future RR types, which supports
interoperability. Also, suggestions are made how to deal with RR types
defined so far.",
URL="http://www.ietf.org/internet-drafts/draft-koch-dnsind-local-compression-00.txt"
}

@TECHREPORT{draft-kohei-rmon-svcloc,
AUTHOR="G. Mansfield and K. Ohta and T. Ika",
TITLE="Network Service Discovery using {RMON-MIB.}",
TYPE="Internet Draft",
HOWPUBLISHED="draft-kohei-rmon-svcloc-00",
INSTITUTION="Internet Engineering Task Force",
MONTH=nov,
YEAR=1997,
NOTE="Work in progress",
ABSTRACT="The Remote network monitoring MIB may be conveniently utilised
to discover network services. This memo briefly outlines the technique
of carrying out the discovery.",
URL="http://www.ietf.org/internet-drafts/draft-kohei-rmon-svcloc-00.txt"
}

@TECHREPORT{draft-laviano-srtp,
AUTHOR="M. Pullen and V. Laviano",
TITLE="Selectively Reliable Transport Protocol",
TYPE="Internet Draft",
HOWPUBLISHED="draft-laviano-srtp-02",
INSTITUTION="Internet Engineering Task Force",
MONTH=aug,
YEAR=1997,
NOTE="Work in progress",
ABSTRACT="This memo describes a protocol for selectively reliable
transmission of Distributed Interactive Simulation (DIS) data in a
wide-area multicast environment. The Selectively Reliable Transmission
Protocol (SRTP) operates in three distinct modes: best-effort multicast,
reliable multicast using negative acknowledgements with a NAK
suppression mechanism to avoid congestion at the sender, and lightweight
reliable transaction-oriented unicast. SRTP is designed to run in user
space and form a sublayer between applications and the kernel-level
Internet protocol stack.",
URL="http://www.ietf.org/internet-drafts/draft-laviano-srtp-02.txt"
}

@TECHREPORT{draft-leiba-imap-mailconnect3,
AUTHOR="P. Hoffman and B. Leiba",
TITLE="{IMAP} {MailConnect} 3 Report",
TYPE="Internet Draft",
HOWPUBLISHED="draft-leiba-imap-mailconnect3-00",
INSTITUTION="Internet Engineering Task Force",
MONTH=nov,
YEAR=1997,
NOTE="Work in progress",
ABSTRACT="In an effort to help increase the depth of interoperability in
the Internet mail industry, over 80 people from 16 companies
participated in MailConnect 3, a two-day event sponsored by the Internet
Mail Consortium and held in San Jose, California, October 30 and 31,
1997. This document reports the findings of the MailConnect 3 event.",
URL="http://www.ietf.org/internet-drafts/draft-leiba-imap-mailconnect3-00.txt"
}

@TECHREPORT{draft-levine-bmtp,
AUTHOR="J. Levine",
TITLE="Bulk Mail Transfer Protocol",
TYPE="Internet Draft",
HOWPUBLISHED="draft-levine-bmtp-00",
INSTITUTION="Internet Engineering Task Force",
MONTH=nov,
YEAR=1997,
NOTE="Work in progress",
ABSTRACT="Bulk Mail Transfer Protocol (BMTP) provides a channel for the
delivery of ''bulk mail'' electronic mail. BMTP is a service parallel to
but sepa- rate from SMTP. The specification of BMTP is intended to be
similar enough to SMTP that existing SMTP clients and servers can easily
be adapted for BMTP. Extensions provide for categorizing messages by
class, and for authorizing the client to the server, to aid in the
implementation of cost-sharing systems.",
URL="http://www.ietf.org/internet-drafts/draft-levine-bmtp-00.txt"
}

@TECHREPORT{draft-lewis-dnssig-authorization,
AUTHOR="O. Gudmundsson and E. Lewis",
TITLE="{DNSSEC} Signature and Data Verification Semantics",
TYPE="Internet Draft",
HOWPUBLISHED="draft-lewis-dnssig-authorization-00",
INSTITUTION="Internet Engineering Task Force",
MONTH=dec,
YEAR=1997,
NOTE="Work in progress",
ABSTRACT="This draft discusses authorization models for DNSSEC that can
be used to determine the relationship of a KEY RR and a DNS RRset in the
validation process. Is this key trusted to sign for this data? Is this
data trusted because it was signed by this key? This draft defines a
number of different policies that can be used and what the signing
authority of keys are in each. This draft also addresses what steps are
recommended in the secure DNS resolution process and how the
authorization policy is put to use. The ideas and definitions expressed
here are based on the authors experience in implementing a reference
secure resolver.",
URL="http://www.ietf.org/internet-drafts/draft-lewis-dnssig-authorization-00.txt"
}

@TECHREPORT{draft-li-hsrp,
AUTHOR="T. Li and B. Cole and D. Li and P. Morton",
TITLE="Hot Standby Router Protocol {(HSRP)}",
TYPE="Internet Draft",
HOWPUBLISHED="draft-li-hsrp-01",
INSTITUTION="Internet Engineering Task Force",
MONTH=oct,
YEAR=1997,
NOTE="Work in progress",
ABSTRACT="The memo specifies the Hot Standby Router Protocol (HSRP). The
goal of the protocol is to allow hosts to appear to use a single router
and to maintain connectivity even if the actual first hop router they
are using fails. Multiple routers participate in this protocol and in
concert create the illusion of a single virtual router. The protocol
insures that one and only one of the routers is forwarding packets on
behalf of the virtual router. End hosts forward their packets to the
virtual router. The router forwarding packets is known as the active
router. A standby router is selected to replace the active router should
it fail. The protocol provides a mechanism for determining active and
standby routers, using the IP addresses on the participating routers. If
an active router fails a standby router can take over without a major
interruption in the host's connectivity. This memo also discusses the
ARP, MAC address, and security issues with this protocol.",
URL="http://www.ietf.org/internet-drafts/draft-li-hsrp-01.txt"
}

@TECHREPORT{draft-liu-ipsec-vpn-management,
AUTHOR="Q. Liu",
TITLE="Definition of a Common Management Interface Format",
TYPE="Internet Draft",
HOWPUBLISHED="draft-liu-ipsec-vpn-management-00",
INSTITUTION="Internet Engineering Task Force",
MONTH=dec,
YEAR=1997,
NOTE="Work in progress",
ABSTRACT="This document defines a common interface format for describing
the configuration of a Virtual Private Network (VPN) in the context of
IPSec and equipment from different vendors. The configuration format
would be both importable and exportable by various vendors of VPN
equipment and software that is IPSec compliant, facilitating an uniform
and perhaps automated method of interoperability (creating a VPN)
between VPN products from different vendors. This document will only
discuss the proposed configuration format. The mechanism by which the
file is propagated is beyond the scope of this document and will not be
discussed. A security association is not mandatory between two
management stations from different vendors wishing to employ this method
of VPN configuration, as this configuration format can easily be
packaged in a file and propagated out of band.",
URL="http://www.ietf.org/internet-drafts/draft-liu-ipsec-vpn-management-00.txt"
}

@TECHREPORT{draft-low-sdr,
AUTHOR="C. Low and J. Randell and M. Wray",
TITLE="{Self-Describing} Data Representation {(SDR)}",
TYPE="Internet Draft",
HOWPUBLISHED="draft-low-sdr-00",
INSTITUTION="Internet Engineering Task Force",
MONTH=oct,
YEAR=1997,
NOTE="Work in progress",
ABSTRACT="This document describes a human-readable, textual syntax for
representing self-describing structured data. This representation was
designed as a transfer syntax for loosely-coupled distributed
applications where one cannot depend on sender(s) and receiver(s)
sharing a schema for exchanged data. The syntax is compact, expressive,
intuitive, and simple to implement.",
URL="http://www.ietf.org/internet-drafts/draft-low-sdr-00.txt"
}

@TECHREPORT{draft-lundblade-1pass-mult-alt,
AUTHOR="L. Lundblade",
TITLE="One Pass {Multipart/Alternative} Processing",
TYPE="Internet Draft",
HOWPUBLISHED="draft-lundblade-1pass-mult-alt-00",
INSTITUTION="Internet Engineering Task Force",
MONTH=nov,
YEAR=1997,
NOTE="Work in progress",
ABSTRACT="Most MIME syntax and semantics can usually be processed in a
single pass through the data. For example, the MIME boundary parameter
always appears before it is used. Similarly the security multiparts
explicitly list the hash algorithm before the hashed (signed) data so
the correct hash algorithm can be used to calculate the hash on the data
as it is processed. This is not the case with multipart/alternative MIME
structures. The processor of the data cannot know the MIME types of the
altnernatives present until all alternatives have been processed. Thus,
it is not possible for a one pass processor to consider more than the
first and most limited representation, because the second part or
subsequent may be something that cannot be handled. A particular case of
this occurs with alternative representations of types text/plain and
text/html or text/enriched formats. The text/plain representation must
come first as required by the multipart/alternative standard. If the
processing is being done on a small device with limited memory it is
most desirable to process the structure in one pass. If the display is
also small, for example 40 colums rather than 80, it is desirable to use
the text/html alternative because it appropriate to reflow HTML to fit
the display. Essentially, given some text that was composed with more
than plain markup, (e.g., HTML), it is preferrable to format the text
with knowledge of the display, than use generically formatted text
(i.e., the text/plain part). This memo proposes a parameter addition to
the multipart/alternative MIME type that lists the MIME types of its
alternative components. This allows a one-pass processor of the
multipart/alternative entity to pick which alternative to use before
processing the entire entity.",
URL="http://www.ietf.org/internet-drafts/draft-lundblade-1pass-mult-alt-00.txt"
}

@TECHREPORT{draft-malkin-pnsmip,
AUTHOR="G. Malkin and P. Raison and N. Kossack",
TITLE="Portable Node Support Using Mobile {IP} Protocol",
TYPE="Internet Draft",
HOWPUBLISHED="draft-malkin-pnsmip-00",
INSTITUTION="Internet Engineering Task Force",
MONTH=aug,
YEAR=1997,
NOTE="Work in progress",
ABSTRACT="This document describes an extension to the Mobile IP protocol
[1] which allows portable nodes to tunnel, through a Service Provider's
network, to their home networks without the need to implement any
special code on the portable nodes.",
URL="http://www.ietf.org/internet-drafts/draft-malkin-pnsmip-00.txt"
}

@TECHREPORT{draft-mallery-urn-pdi,
AUTHOR="J. Mallery",
TITLE="Persistent Document Identifiers",
TYPE="Internet Draft",
HOWPUBLISHED="draft-mallery-urn-pdi-00",
INSTITUTION="Internet Engineering Task Force",
MONTH=nov,
YEAR=1997,
NOTE="Work in progress",
ABSTRACT="This document specifies the syntax and semantics of the
Persistent Document Identifier (PDI) namespace within the URN framework
defined by RFC 2141 [17]. PDIs provide a means to refer to digital
objects and fragments that does not depend their storage location or the
protocol used to access them. Since 1994, several large-scale
applications with these requirements have used PDIs [12] [21]. PDIs are
intended primarily as permanent identifiers for archival reference to
long-lived documents. PDIs have a fragment syntax to allow permanent
references to parts of documents (within specific formats) as well as a
citation syntax to allow references to appearances of such fragments in
composite documents. PDIs are most useful for any document series that
is distributed via multiple protocols, is available from multiple
sources, migrates to new locations, needs fragment references, or
participates in distributed assertion semantics related to collaboration
or access control.",
URL="http://www.ietf.org/internet-drafts/draft-mallery-urn-pdi-00.txt"
}

@TECHREPORT{draft-mamros-pskeyext,
TITLE="{Pre-Shared} Key Extensions for {ISAKMP/Oakley}",
TYPE="Internet Draft",
HOWPUBLISHED="draft-mamros-pskeyext-00",
INSTITUTION="Internet Engineering Task Force",
MONTH=nov,
YEAR=1997,
NOTE="Work in progress",
ABSTRACT="The application of IP Security for remote access over the
Internet requires that it support ''traditional'' authentication
paradigms. This document describes how a traditional username and
passphrase-style mechanism can be integrated into the existing
pre-shared key authentication mechanism in ISAKMP/Oakley.",
URL="http://www.ietf.org/internet-drafts/draft-mamros-pskeyext-00.txt"
}

@TECHREPORT{draft-manchester-pppext-transper,
AUTHOR="J. Manchester and S. Dravida and J. Anderson and B. Doshi and R. Broberg
and P. Lothberg",
TITLE="Enabling Transparency for the {PPP} over {SONET/SDH} Mapping",
TYPE="Internet Draft",
HOWPUBLISHED="draft-manchester-pppext-transper-00",
INSTITUTION="Internet Engineering Task Force",
MONTH=nov,
YEAR=1997,
NOTE="Work in progress",
ABSTRACT="Recent Internet Draft submissions and discussion on the PPP
Extensions Working Group email list have highlighted a transparency
deficiency with the PPP over SONET/SDH mapping described in IETF RFC
1619. This ID proposes that a 1+x**43 scrambler be used to overcome the
transparency deficiency of IETF RFC 1619.",
URL="http://www.ietf.org/internet-drafts/draft-manchester-pppext-transper-00.txt"
}

@TECHREPORT{draft-mealling-rwhoisurl,
AUTHOR="S. Williamson and M. Mealling",
TITLE="The {RWhois} Version 1.x Uniform Resource Locator",
TYPE="Internet Draft",
HOWPUBLISHED="draft-mealling-rwhoisurl-01",
INSTITUTION="Internet Engineering Task Force",
MONTH=aug,
YEAR=1997,
NOTE="Work in progress",
ABSTRACT="RWhois is an Internet directory access protocol, defined in
RFC1714 [1] and RFC2167 [3]. This document describes a format for an
RWhois Uniform Resource Locator (URL) that will allow Internet clients
to have direct access to the RWhois protocol. An RWhois URL will
represent a single query to an RWhois server.",
URL="http://www.ietf.org/internet-drafts/draft-mealling-rwhoisurl-01.txt"
}

@TECHREPORT{draft-moats-finding,
AUTHOR="R. Moats",
TITLE="How to find {LDAP} servers",
TYPE="Internet Draft",
HOWPUBLISHED="draft-moats-finding-01",
INSTITUTION="Internet Engineering Task Force",
MONTH=sep,
YEAR=1997,
NOTE="Work in progress",
ABSTRACT="This document discusses methods available for LDAP server
discovery and advertisement based on previous IETF and ongoing IETF
work.",
URL="http://www.ietf.org/internet-drafts/draft-moats-finding-01.txt"
}

@TECHREPORT{draft-moats-server-finding,
AUTHOR="R. Moats",
TITLE="{LDAP} Servers Finding Other {LDAP} Servers",
TYPE="Internet Draft",
HOWPUBLISHED="draft-moats-server-finding-00",
INSTITUTION="Internet Engineering Task Force",
MONTH=nov,
YEAR=1997,
NOTE="Work in progress",
ABSTRACT="This document discusses methods available for an LDAP server
to discover other LDAP servers. It is based on previous and ongoing IETF
work.",
URL="http://www.ietf.org/internet-drafts/draft-moats-server-finding-00.txt"
}

@TECHREPORT{draft-mohamed-gp-ep,
AUTHOR="M. Mohamed-Rafi",
TITLE="{GP/E} Protocol for a Wireless Network",
TYPE="Internet Draft",
HOWPUBLISHED="draft-mohamed-gp-ep-00",
INSTITUTION="Internet Engineering Task Force",
MONTH=feb,
YEAR=1997,
NOTE="Work in progress",
ABSTRACT="This memo defines Global Postion/Encryption Protocol (GP/EP),
a proposal for a universal wireless computer network. Global position is
defined as region in space-time. The network routes data to a global
position using routing information provided as part of the protocol data
and proposes use of encryption algorithms to prevent unauthorised
access. This protocol is proposed as an alternative for IP, the Internet
Protocol. The memo also describes how a network can work with no real
network address other than its global position in the universe.",
URL="http://www.ietf.org/internet-drafts/draft-mohamed-gp-ep-00.txt"
}

@TECHREPORT{draft-montenegro-tsp,
AUTHOR="Gabriel Montenegro",
TITLE="Tunnel Set-up Protocol {(TSP)}",
TYPE="Internet Draft",
HOWPUBLISHED="draft-montenegro-tsp-00",
INSTITUTION="Internet Engineering Task Force",
MONTH=aug,
YEAR=1997,
NOTE="Work in progress",
ABSTRACT="Remote access over the internet and IP mobility are currently
being addressed as two separate problems. The L2TP specification is
defining a protocol, or rather a tunnel control mechanism to solve the
remote access problem. On the other hand, the Mobile IP working group
has been solving the mobility problem. Nevertheless, the same solution
applies to both problems, namely, tunneling. This document defines a
Tunnel Set-up Protocol (TSP) that solves both problems using a common
approach. TSP is heavily based on the control messages defined by Mobile
IP.",
URL="http://www.ietf.org/internet-drafts/draft-montenegro-tsp-00.txt"
}

@TECHREPORT{draft-moore-maillist-req,
AUTHOR="K. Moore",
TITLE="Requirements for {IETF} Mailing Lists",
TYPE="Internet Draft",
HOWPUBLISHED="draft-moore-maillist-req-01",
INSTITUTION="Internet Engineering Task Force",
MONTH=sep,
YEAR=1997,
NOTE="Work in progress",
ABSTRACT="This document describes requirements for all IETF official
mailing lists, including (but not limited to) mailing lists used for
working group discussion.",
URL="http://www.ietf.org/internet-drafts/draft-moore-maillist-req-01.txt"
}

@TECHREPORT{draft-myers-imap-optimize,
AUTHOR="J. Myers",
TITLE="{IMAP4} {UIDPLUS} extension",
TYPE="Internet Draft",
HOWPUBLISHED="draft-myers-imap-optimize-03",
INSTITUTION="Internet Engineering Task Force",
MONTH=dec,
YEAR=1997,
NOTE="Work in progress",
ABSTRACT="The UIDPLUS extension of the Internet Message Access Protocol
[IMAP4] provides a set of features intended to reduce the amount of time
and resources used by some client operations. The features in UIDPLUS
are primarily intended for disconnected-use clients.",
URL="http://www.ietf.org/internet-drafts/draft-myers-imap-optimize-03.txt"
}

@TECHREPORT{draft-nagami-csr-fanpv2-dcmode,
AUTHOR="Y. Katsube and K. Nagami and A. Mogi",
TITLE="Flow Attribute Notification Protocol Version 2 {(FANPv2)} Distributed
Control Mode",
TYPE="Internet Draft",
HOWPUBLISHED="draft-nagami-csr-fanpv2-dcmode-00",
INSTITUTION="Internet Engineering Task Force",
MONTH=dec,
YEAR=1997,
NOTE="Work in progress",
ABSTRACT="This memo describes the specification of FANPv2 (Flow
Attribute Notification Protocol version 2) distributed control mode
(DC-mode). The FANPv2 is a protocol used by Cell Switch Routers (CSRs)
to communicate mapping information between a specific packet flow and a
virtual connection that conveys the packet flow. In the DC-mode, the
control message exchange for a packet flow between each pair of
neighboring CSRs is initiated independently from the message exchange
for the same flow between any other pair of CSRs. The DC-mode is
applicable to the control of both unicast and multicast cut-through
paths.",
URL="http://www.ietf.org/internet-drafts/draft-nagami-csr-fanpv2-dcmode-00.txt"
}

@TECHREPORT{draft-nagami-csr-fanpv2-nd,
AUTHOR="K. Nagami and Y. Ohba and A. Mogi",
TITLE="Flow Attribute Notification Protocol Version 2 {(FANPv2)} Neighbor
Discovery",
TYPE="Internet Draft",
HOWPUBLISHED="draft-nagami-csr-fanpv2-nd-00",
INSTITUTION="Internet Engineering Task Force",
MONTH=dec,
YEAR=1997,
NOTE="Work in progress",
ABSTRACT="This memo describes the specification of FANPv2 (Flow
Attribute Notification Protocol version 2) Neighbor Discovery protocol
(ND). The ND is used for (1) automatically detecting FANPv2 neighbors,
(2) obtaining FANPv2 protocol attributes of the neighbors, and (3)
checking whether consistent states are maintained by the neighboring
nodes. Both DC-mode (Distributed Control mode)[4] and IC-mode (Ingress
Control mode)[5] of the FANPv2 use the ND for these purposes. The ND
operates over multi-access interfaces as well as over point-point
interfaces.",
URL="http://www.ietf.org/internet-drafts/draft-nagami-csr-fanpv2-nd-00.txt"
}

@TECHREPORT{draft-narten-canonical-ordering,
AUTHOR="T. Narten and C. Burton",
TITLE="A Caution On The Canonical Ordering Of {Link-Layer} Addresses",
TYPE="Internet Draft",
HOWPUBLISHED="draft-narten-canonical-ordering-00",
INSTITUTION="Internet Engineering Task Force",
MONTH=nov,
YEAR=1997,
NOTE="Work in progress",
ABSTRACT="Protocols such as ARP and Neighbor Discovery have data fields
that contain link-layer addresses. In order to interoperate properly, a
sender setting such a field must insure that the receiver extracts those
bits and interprets them correctly. In most cases, such fields must be
in ''canonical form.'' Unfortunately, not all LAN adaptors are
consistent in their use of canonical form, and implementations may need
to explicitly bit swap individual bytes in order to obtain the correct
format. This document provides information to implementors to help them
avoid the pitfall of using non-canonical forms when canonical forms are
required.",
URL="http://www.ietf.org/internet-drafts/draft-narten-canonical-ordering-00.txt"
}

@TECHREPORT{draft-newman-pop3ext,
AUTHOR="C. Newman",
TITLE="{POP3} Extension Mechanism and Error Codes",
TYPE="Internet Draft",
HOWPUBLISHED="draft-newman-pop3ext-00",
INSTITUTION="Internet Engineering Task Force",
MONTH=nov,
YEAR=1997,
NOTE="Work in progress",
ABSTRACT="The POP3 protocol [POP3] includes a number of optional
commands and some useful protocol extensions have also been published.
Currently these optional features and extensions can only be detected by
probing. This has resulted in some clients including manual
configuration options for POP3 server capabilities.",
URL="http://www.ietf.org/internet-drafts/draft-newman-pop3ext-00.txt"
}

@TECHREPORT{draft-newman-protocol-design,
AUTHOR="C. Newman",
TITLE=": Application Protocol Design Principles",
TYPE="Internet Draft",
HOWPUBLISHED="draft-newman-protocol-design-01",
INSTITUTION="Internet Engineering Task Force",
MONTH=jul,
YEAR=1997,
NOTE="Work in progress",
ABSTRACT="There are a number of design principles which come into play
over and over again when designing application protocols. Many of these
are entrenched in IETF lore and spread by word of mouth. Most have been
learned the hard way many times. This is an attempt to codify some of
these principles so they can be referenced rather than spread by word of
mouth. The author has not invented any of these ideas and while the
exercise of finding the originator of the ideas would be interesting, it
is not deemed necessary for this project. Many of these principles have
a much wider scope than application protocol design. However, the
author's primary experience is with application protocols and examples
provided usually involve application protocols or elements. [Disclaimer:
this is a preliminary draft. Some of the case studies and exceptions
need tuning. Suggestions welcome.]",
URL="http://www.ietf.org/internet-drafts/draft-newman-protocol-design-01.txt"
}

@TECHREPORT{draft-newman-sasl-plaintrans,
AUTHOR="C. Newman",
TITLE="Plaintext Password {SASL} Mechanism for Transitioning",
TYPE="Internet Draft",
HOWPUBLISHED="draft-newman-sasl-plaintrans-04",
INSTITUTION="Internet Engineering Task Force",
MONTH=nov,
YEAR=1997,
NOTE="Work in progress",
ABSTRACT="Unencrypted plaintext passwords are the biggest single risk to
Internet application protocol security. Unfortunately, they are widely
deployed, often tightly integrated into operating system services and
very difficult to replace in an interoperable fashion. This
specification discusses some methods which can be used to eliminate
unencrypted plaintext passwords. It also defines a SASL mechanism [SASL]
which may be used by newer protocols such as ACAP [ACAP] to transition
away from a legacy authentication database.",
URL="http://www.ietf.org/internet-drafts/draft-newman-sasl-plaintrans-04.txt"
}

@TECHREPORT{draft-nichols-diff-svc-arch,
AUTHOR="Kathleen Nichols and V. Jacobson and L. Zhang",
TITLE="A Two-bit Differentiated Services Architecture for the Internet",
TYPE="Internet Draft",
HOWPUBLISHED="draft-nichols-diff-svc-arch-02",
INSTITUTION="Bay Networks, LBNL and UCLA",
MONTH=nov,
YEAR=1997,
NOTE="Work in progress",
KEYWORDS="traffic shaping; best effort; premium service; better effort service;
service differentiation",
ABSTRACT="This document presents a differentiated services architecture
for the internet.  Dave Clark and Van Jacobson each presented work on
differentiated services at the Munich IETF meeting [2,3].  Each
explained how to use one bit of the IP header to deliver a new kind of
service to packets in the internet.  These were two very different kinds
of service with quite different policy assumptions.  Ensuing discussion
has convinced us that both service types have merit and that both
service types can be implemented with a set of very similar mechanisms. 
We propose an architectural framework that permits the use of both of
these service types and exploits their similarities in forwarding path
mechanisms.  The major goals of this architecture are each shared with
one or both of those two proposals:  keep the forwarding path simple,
push complexity to the edges of the network to the extent possible,
provide a service that avoids assumptions about the type of traffic
using it, employ an allocation policy that will be compatible with both
long-term and short-term provisioning, make it possible for the dominant
Internet traffic model to remain best-effort.",
URL="ftp://ftp.ee.lbl.gov/papers/dsarch.pdf"
}

@TECHREPORT{draft-palme-newsmail,
AUTHOR="J. Palme",
TITLE="Messages between Email and Netnews",
TYPE="Internet Draft",
HOWPUBLISHED="draft-palme-newsmail-00",
INSTITUTION="Internet Engineering Task Force",
MONTH=aug,
YEAR=1997,
NOTE="Work in progress",
ABSTRACT="Messages can be transported through gateways between email and
netnews. Combined clients for mail and netnews can submit the same
message at the same time to email and netnews. Many netnews clients can
produce email replies to the author of netnews articles. This standard
specifies how to handle these kinds of messages. This standard specifies
three new email headers: 'Posted-To', 'Group-Reply-To' and
'Personal-Reply-To'. Further discussions on this memo should take place
in the mailing-list MAILNEWS-L(at)SEGATE.SUNET.SE. More info in the full
text of this memo or at URL
http://www.dsv.su.se/~jpalme/ietf/jp-ietf-home.html#newsharmony.",
URL="http://www.ietf.org/internet-drafts/draft-palme-newsmail-00.txt"
}

@TECHREPORT{draft-pan-rsvp-timer,
AUTHOR="Ping Pan and Henning Schulzrinne and Roch Guerin",
TITLE="Staged Refresh Timers for {RSVP}",
TYPE="Internet Draft",
HOWPUBLISHED="draft-pan-rsvp-timer-00",
INSTITUTION="Internet Engineering Task Force",
MONTH=dec,
YEAR=1997,
NOTE="Work in progress",
ABSTRACT="The current resource Reservation Protocol (RSVP) design has no
reliability mechanism for the delivery of control messages. Instead,
RSVP relies on periodic refresh between routers to maintain reservation
states. This approach has several problems in a congested network. End
systems send Path and Resv messages to set up RSVP connections. If the
first Path or Resv message from an end system is accidentally lost in
the network, a copy of the message will not be retransmitted until the
end of a refresh interval, causing a delay of 30 seconds or more until a
reservation is established. If a congested link causes a tear-down
message (PathTear or ResvTear) to be dropped, the corresponding
reservation will not be removed from the routers until the RSVP cleanup
timer expires.",
URL="http://www.ietf.org/internet-drafts/draft-pan-rsvp-timer-00.txt"
}

@TECHREPORT{draft-panabaker-ip-vbi,
AUTHOR="R. Panabaker",
TITLE="The transmission of {IP} over the vertical blanking interval of a
television signal",
TYPE="Internet Draft",
HOWPUBLISHED="draft-panabaker-ip-vbi-02",
INSTITUTION="Internet Engineering Task Force",
MONTH=nov,
YEAR=1997,
NOTE="Work in progress",
ABSTRACT="This is an Internet-Draft, which describes a method for
broadcasting multicast I P data using the vertical blanking interval of
a television signal. It includes a description for compressing multicast
IP headers on unidirectional networks, a framing protocol identical to
SLIP, and a forward error correction scheme for the NABTS standard.
Keywords: VBI, NTSC, broadcast, push, FEC, television, NABTS, IP",
URL="http://www.ietf.org/internet-drafts/draft-panabaker-ip-vbi-02.txt"
}

@TECHREPORT{draft-pohlmann-http-traffic-satellite,
AUTHOR="R. Pohlmann",
TITLE="{HTTP} Traffic over Satellite",
TYPE="Internet Draft",
HOWPUBLISHED="draft-pohlmann-http-traffic-satellite-00",
INSTITUTION="Internet Engineering Task Force",
MONTH=oct,
YEAR=1997,
NOTE="Work in progress",
ABSTRACT="Internet use over satellites (LEO, MEO and GEO) has not
received enough attention. Satellites have an inherent broadcasting
ability useful for transmitting Internet traffic. They can send
information to many locations simultaneously depending on the coverage
beam of the satellite. The issue of Internet use over satellites needs
to be addressed so that future implementations of networking protocols
can be used with this medium. The vast majority of Internet traffic is
TCP traffic resulting from the HTTP protocol so this issue will be
addressed here. It is hoped that this facilitates the transition from
the use of terrestial networks, to networks incorporating satellite
links.",
URL="http://www.ietf.org/internet-drafts/draft-pohlmann-http-traffic-satellite-00.txt"
}

@TECHREPORT{draft-przygienda-bgp-md5,
AUTHOR="T. Przygienda",
TITLE="{BGP-4} {MD5} Authentication",
TYPE="Internet Draft",
HOWPUBLISHED="draft-przygienda-bgp-md5-00",
INSTITUTION="Internet Engineering Task Force",
MONTH=nov,
YEAR=1997,
NOTE="Work in progress",
ABSTRACT="This memo describes MD5 authentication scheme for BGP-4
routing protocol analogous to the one proposed for SNMP Version 2 and
RIP-2. The mechanism provides greatly enhanced probability for a system
attacked to detect and ignore messages received. A sequence number
improves additionally the resistance against replay attacks.",
URL="http://www.ietf.org/internet-drafts/draft-przygienda-bgp-md5-00.txt"
}

@TECHREPORT{draft-putzolu-heuristic,
AUTHOR="D. Putzolu",
TITLE="Heuristics for utilizing {ISSL} Mechanisms for {A/V} Streams Over Low
Bandwidth Links in the absence of Announcement Protocols",
TYPE="Internet Draft",
HOWPUBLISHED="draft-putzolu-heuristic-00",
INSTITUTION="Internet Engineering Task Force",
MONTH=dec,
YEAR=1997,
NOTE="Work in progress",
ABSTRACT="The ISSLOW subgroup of the ISSL working group has defined a
set of mechanisms for providing integrated services over low bandwidth
links [1]. These mechanisms rely on an announcement protocol (typically
RSVP [2]) to determine which streams require other than best-effort
service and to determine what level and type of service to provide for
such streams. It is anticipated that at least some of the mechanisms
defined by the ISSLOW subgroup, specifically Compressed RTP [3] (CRTP)
[4] and Multi-Channel Multi-Link PPP (MCML) [5], will be available well
before RSVP has been widely deployed. Given the proliferation of
applications streaming audio and video using the mechanisms defined in
the AVT working group (e.g., RTP), a means of utilizing these mechanisms
in the absence of an announcement protocol would be beneficial. Such
means have been proposed in [6], but they require changes to
applications so as to be able to indicate the need for special
treatment. This document describes a set of heuristics for use with the
mechanisms defined in the ISSLOW subgroup that provide an enhanced
degree of service for audio/video streaming applications without
requiring that changes be made to applications. The approach taken is to
provide a default set of heuristics that implementations of MCML and
CRTP can use to provide enhanced service over PPP links for audio and
video streams without requiring any application or infrastructure
changes.",
URL="http://www.ietf.org/internet-drafts/draft-putzolu-heuristic-00.txt"
}

@TECHREPORT{draft-ramsdell-smime-msg,
AUTHOR="B. Ramsdell",
TITLE="{S/MIME} Version 3 Message Specification",
TYPE="Internet Draft",
HOWPUBLISHED="draft-ramsdell-smime-msg-00",
INSTITUTION="Internet Engineering Task Force",
MONTH=nov,
YEAR=1997,
NOTE="Work in progress",
ABSTRACT="S/MIME (Secure/Multipurpose Internet Mail Extensions) provides
a consistent way to send and receive secure MIME data. Based on the
popular Internet MIME standard, S/MIME provides the following
cryptographic security services for electronic messaging applications:
authentication, message integrity and non-repudiation of origin (using
digital signatures) and privacy and data security (using encryption).
S/MIME can be used by traditional mail user agents (MUAs) to add
cryptographic security services to mail that is sent, and to interpret
cryptographic security services in mail that is received. However,
S/MIME is not restricted to mail; it can be used with any transport
mechanism that transports MIME data, such as HTTP. As such, S/MIME takes
advantage of the object-based features of MIME and allows secure
messages to be exchanged in mixed-transport systems. Further, S/MIME can
be used in automated message transfer agents that use cryptographic
security services that do not require any human intervention, such as
the signing of software-generated documents and the encryption of FAX
messages sent over the Internet.",
URL="http://www.ietf.org/internet-drafts/draft-ramsdell-smime-msg-00.txt"
}

@TECHREPORT{draft-reddy-ishop,
AUTHOR="R. Reddy",
TITLE="Protocol for shopping over the Internet",
TYPE="Internet Draft",
HOWPUBLISHED="draft-reddy-ishop-00",
INSTITUTION="Internet Engineering Task Force",
MONTH=dec,
YEAR=1997,
NOTE="Work in progress",
ABSTRACT="This Internet-Draft specifies a standard method for shopping
on the Internet. Using this protocol client programs can enumerate all
the products sold by category, search for a particular product and find
the cost or quantity of each product. After realizing the cost of a
particular product, client programs can compare the price of this
product sold on other Internet sites.",
URL="http://www.ietf.org/internet-drafts/draft-reddy-ishop-00.txt"
}

@TECHREPORT{draft-rekhter-tagswitch-arch,
AUTHOR="D. Katz and Y. Rekhter and D. Farinacci",
TITLE="Tag Switching Architecture - Overview",
TYPE="Internet Draft",
HOWPUBLISHED="draft-rekhter-tagswitch-arch-01",
INSTITUTION="Internet Engineering Task Force",
MONTH=aug,
YEAR=1997,
NOTE="Work in progress",
ABSTRACT="This document provides an overview of tag switching. Tag
switching is a way to combine the label-swapping forwarding paradigm
with network layer routing. This has several advantages. Tags can have a
wide spectrum of forwarding granularities, so at one end of the spectrum
a tag could be associated with a group of destinations, while at the
other a tag could be associated with a single application flow. At the
same time forwarding based on tag switching, due to its simplicity, is
well suited to high performance forwarding. These factors facilitate the
development of a routing system which is both functionally rich and
scalable. Finally, tag switching simplifies integration of routers and
ATM switches by employing common addressing, routing, and management
procedures.",
URL="http://www.ietf.org/internet-drafts/draft-rekhter-tagswitch-arch-01.txt"
}

@TECHREPORT{draft-rfced-exp-beals,
AUTHOR="A. Beals",
TITLE="The {TPING} option for the Telnet protocol",
TYPE="Internet Draft",
HOWPUBLISHED="draft-rfced-exp-beals-00",
INSTITUTION="Internet Engineering Task Force",
MONTH=nov,
YEAR=1997,
NOTE="Work in progress",
ABSTRACT="When using the telnet protocol to talk to a remote device, as
one would with RFC 2217, it would be useful to be able to determine if
the remote server is active or not. In contrast with the ''Are You
There'' sub-option, the return message is not mixed into the data stream
presented to the user or client program, it is simply passed between the
telnet client/server pair.",
URL="http://www.ietf.org/internet-drafts/draft-rfced-exp-beals-00.txt"
}

@TECHREPORT{draft-rfced-exp-whalen,
AUTHOR="C. Whalen",
TITLE="Communicating Information for External Program Use in Internet Messages:",
TYPE="Internet Draft",
HOWPUBLISHED="draft-rfced-exp-whalen-00",
INSTITUTION="Internet Engineering Task Force",
MONTH=sep,
YEAR=1997,
NOTE="Work in progress",
ABSTRACT="This memo provides a mechanism whereby messages conforming to
the MIME specifications [RFC 2045, RFC 2046, RFC 2047, RFC 2048, RFC
2049] can convey information not intended for display by the Mail User
Agent (UA), but for processing (as opposed to display) by an external
program. It specifies a new type of 'Content-Disposition' (defined by
[RFC 2183]), which is valid for any MIME entity ('message' or 'body
part). When 'body part' is referred to in this memo, it is referring to
any MIME entity, except in section 2.4. This memo is the definition of
this type, as specified by Section 9 of [RFC 2183]. This document is
intended as an extension to MIME. As such, the reader is assumed to be
familiar with the MIME specifications, [RFC 822], and [RFC 2183]. The
information presented herein supplements but does not replace that found
in those documents.",
URL="http://www.ietf.org/internet-drafts/draft-rfced-exp-whalen-00.txt"
}

@TECHREPORT{draft-rfced-info-bates-multihoming,
AUTHOR="Y. Rekhter and T. Bates",
TITLE="Scalable support for multi-homed multi-provider connectivity",
TYPE="Internet Draft",
HOWPUBLISHED="draft-rfced-info-bates-multihoming-01",
INSTITUTION="Internet Engineering Task Force",
MONTH=jul,
YEAR=1997,
NOTE="Work in progress",
ABSTRACT="This document describes addressing and routing strategies for
multi- homed enterprises attached to multiple Internet Service Providers
(ISPs) that are intended to reduce the routing overhead due to these
enterprises in the global Internet routing system.",
URL="http://www.ietf.org/internet-drafts/draft-rfced-info-bates-multihoming-01.txt"
}

@TECHREPORT{draft-rfced-info-buddenberg,
AUTHOR="R. Buddenberg",
TITLE="Automated Digital Network System Description",
TYPE="Internet Draft",
HOWPUBLISHED="draft-rfced-info-buddenberg-00",
INSTITUTION="Internet Engineering Task Force",
MONTH=sep,
YEAR=1997,
NOTE="Work in progress",
ABSTRACT="The Navy's Automated Digital Network System (ADNS) provides a
means for ship's to centralize and automate the operation of multiple
independent radio communications systems into an efficient
communications network.",
URL="http://www.ietf.org/internet-drafts/draft-rfced-info-buddenberg-00.txt"
}

@TECHREPORT{draft-rfced-info-demchenko,
AUTHOR="Y. Demchenko",
TITLE="Registration of a Ukrainian Cyrillic Character Set {KOI8-RU} (as extention
to",
TYPE="Internet Draft",
HOWPUBLISHED="draft-rfced-info-demchenko-00",
INSTITUTION="Internet Engineering Task Force",
MONTH=oct,
YEAR=1997,
NOTE="Work in progress",
ABSTRACT="This document provides information about widely used in
Ukrainian Internet community character set for mail and news exchange as
well as for presentation WWW information resources in Ukrainian
language.",
URL="http://www.ietf.org/internet-drafts/draft-rfced-info-demchenko-00.txt"
}

@TECHREPORT{draft-rfced-info-honton,
AUTHOR="C. Honton",
TITLE="Service Discovery Protocol",
TYPE="Internet Draft",
HOWPUBLISHED="draft-rfced-info-honton-00",
INSTITUTION="Internet Engineering Task Force",
MONTH=nov,
YEAR=1997,
NOTE="Work in progress",
ABSTRACT="This document suggests a protocol using a well-known multicast
address [RFC1112] to discover the interface of the closest service
provider for a desired service port.",
URL="http://www.ietf.org/internet-drafts/draft-rfced-info-honton-00.txt"
}

@TECHREPORT{draft-rfced-info-khana,
AUTHOR="V. Khanna",
TITLE="{PPP} for Asynchronous {PAD} to Synchronous {X.25} access",
TYPE="Internet Draft",
HOWPUBLISHED="draft-rfced-info-khana-01",
INSTITUTION="Internet Engineering Task Force",
MONTH=oct,
YEAR=1997,
NOTE="Work in progress",
ABSTRACT="The PPP protocol allows data transfer thru asynchronous or
synchronous connections. But the prevalent Public Switched Data Networks
(PSDNs) support connections between asynchronous and synchronous
protocols. This document defines extensions to the PPP protocol to
support asynchronous PAD to synchronous X.25 protocols on PSDNs.",
URL="http://www.ietf.org/internet-drafts/draft-rfced-info-khana-01.txt"
}

@TECHREPORT{draft-rfced-info-lantz,
AUTHOR="Philip Lantz",
TITLE="Usage of {H.323} on the Internet",
TYPE="Internet Draft",
HOWPUBLISHED="draft-rfced-info-lantz-00",
INSTITUTION="Internet Engineering Task Force",
MONTH=feb,
YEAR=1997,
NOTE="Work in progress",
URL="http://www.ietf.org/internet-drafts/draft-rfced-info-lantz-00.txt"
}

@TECHREPORT{draft-rfced-info-madan,
AUTHOR="B. Madan",
TITLE="The Boot Selection Menu Option for {BOOTP/DHCP}",
TYPE="Internet Draft",
HOWPUBLISHED="draft-rfced-info-madan-00",
INSTITUTION="Internet Engineering Task Force",
MONTH=oct,
YEAR=1997,
NOTE="Work in progress",
ABSTRACT="The BOOTP [1] or the Dynamic Host Configuration Protocol
(DHCP) [2] provide a framework for booting a host over a network from a
remote server. This document defines a new option which a BOOTP/DHCP
client may include in its BOOTP request or DHCPDISCOVER message. In
their replies, the recipient servers may include this option along with
the location/path information to a file ('boot.info') in the option
field. The client may use the contents of this file to select the
desired OS with which to boot along with the location/path of the
appropriate boot image file.",
URL="http://www.ietf.org/internet-drafts/draft-rfced-info-madan-00.txt"
}

@TECHREPORT{draft-rfced-info-robert,
AUTHOR="A. Robert",
TITLE="{MAPPING} {OF} {AIRLINE} {TRAFFIC} {OVER} {IP}",
TYPE="Internet Draft",
HOWPUBLISHED="draft-rfced-info-robert-00",
INSTITUTION="Internet Engineering Task Force",
MONTH=aug,
YEAR=1997,
NOTE="Work in progress",
ABSTRACT="This memo specifies a protocol for the encapsulation of the
airline specific protocol over IP.",
URL="http://www.ietf.org/internet-drafts/draft-rfced-info-robert-00.txt"
}

@TECHREPORT{draft-rfced-info-stanislevic,
AUTHOR="H. Stanislevic",
TITLE="{End-to-End} Throughput and Response Time Testing With {HTTP} User Agents
and the {JavaScript} Language",
TYPE="Internet Draft",
HOWPUBLISHED="draft-rfced-info-stanislevic-00",
INSTITUTION="Internet Engineering Task Force",
MONTH=aug,
YEAR=1997,
NOTE="Work in progress",
ABSTRACT="This memo describes two simple metrics and a methodology for
testing end-to-end one-way data throughput and two-way response time at
the application layer utilizing HTTP [1] (web) servers and user agents
(web browsers). Two Interactive Hypertext Transfer Test (IHTTT)
implementations are described in detail.",
URL="http://www.ietf.org/internet-drafts/draft-rfced-info-stanislevic-00.txt"
}

@TECHREPORT{draft-rfced-info-tkachuk,
AUTHOR="R. Tkachuk",
TITLE="Ukrainian Code Page {KOI8-U}",
TYPE="Internet Draft",
HOWPUBLISHED="draft-rfced-info-tkachuk-00",
INSTITUTION="Internet Engineering Task Force",
MONTH=oct,
YEAR=1997,
NOTE="Work in progress",
ABSTRACT="This memo is the specification of the code page, which was
originally developed for the transmission of texts in the Ukrainian
language through networks, and in particular the networks, employing
Unix operating systems. It is, however, operating-system-neutral, and is
used in various situations, just as its Russian language counterpart
KOI-8R. With some minor exceptions, this specification can be considered
to be an extension of KOI8-R (RFC-1489). The present edition of the
specification is the result of the wide concensus reached after many
prolonged exchanges and discussions, which took place in Ukraine and on
some Usenet conferences covering Ukraine and read by the public who
employs the Ukrainian language.",
URL="http://www.ietf.org/internet-drafts/draft-rfced-info-tkachuk-00.txt"
}

@TECHREPORT{draft-rfced-info-vaughan,
AUTHOR="O. Vaughan",
TITLE="A Legal Domain Name Allocation Method",
TYPE="Internet Draft",
HOWPUBLISHED="draft-rfced-info-vaughan-00",
INSTITUTION="Internet Engineering Task Force",
MONTH=nov,
YEAR=1997,
NOTE="Work in progress",
ABSTRACT="The purpose of this memo is to focus discussion on the
particular problems with the exhaustion of the top level domain space in
the Internet and the possible conflicts that can occur when multiple
organisations are vying for the same name. No proposed solutions in this
document are intended as standards for the Internet. Rather, it is hoped
that a general consensus will emerge as to the appropriate solution to
such problems, leading eventually to the adoption of standards.",
URL="http://www.ietf.org/internet-drafts/draft-rfced-info-vaughan-00.txt"
}

@TECHREPORT{draft-rivest-rc2desc,
AUTHOR="R. Rivest",
TITLE="A Description of the {RC2(r)} Encryption Algorithm",
TYPE="Internet Draft",
HOWPUBLISHED="draft-rivest-rc2desc-01",
INSTITUTION="Internet Engineering Task Force",
MONTH=dec,
YEAR=1997,
NOTE="Work in progress",
ABSTRACT="This draft is an RSA Laboratories Technical Note. It is meant
for informational use by the Internet community. This memo describes a
conventional (secret-key) block encryption algorithm, called RC2, which
may be considered as a proposal for a DES replacement. The input and
output block sizes are 64 bits each. The key size is variable, from one
byte up to 128 bytes, although the current implementation uses eight
bytes. The algorithm is designed to be easy to implement on 16-bit
microprocessors. On an IBM AT, the encryption runs about twice as fast
as DES (assuming that key expansion has been done).",
URL="http://www.ietf.org/internet-drafts/draft-rivest-rc2desc-01.txt"
}

@TECHREPORT{draft-rosen-mpls-lan-encaps,
AUTHOR="D. Farinacci and T. Li and Y. Rekhter and D. Tappan and G. Fedorkow and E.
Rosen and A. Conta",
TITLE="{MPLS} Label Stack Encoding on {LAN} Media",
TYPE="Internet Draft",
HOWPUBLISHED="draft-rosen-mpls-lan-encaps-00",
INSTITUTION="Internet Engineering Task Force",
MONTH=nov,
YEAR=1997,
NOTE="Work in progress",
ABSTRACT="''Multi-Protocol Label Switching (MPLS)'' [1,2,3] requires a
set of procedures for augmenting network layer packets with ''label
stacks'', thereby turning them into ''labeled packets'' [4]. Routers
which support MPLS are known as ''Label Switching Routers'', or
''LSRs''. In order to transmit a labeled packet on a particular data
link, an LSR must support an encoding technique which, given a label
stack and a network layer packet, produces a labeled packet. This
document specifies the encoding to be used by an LSR in order to
transmit labeled packets on LAN data links.",
URL="http://www.ietf.org/internet-drafts/draft-rosen-mpls-lan-encaps-00.txt"
}

@TECHREPORT{draft-rosen-mpls-lan-encaps-compar,
AUTHOR="K. McCloghrie and T. Li and E. Rosen and A. Fredette and M. Merhar",
TITLE="Comparison of {MPLS} {LAN} Encapsulation Proposals",
TYPE="Internet Draft",
HOWPUBLISHED="draft-rosen-mpls-lan-encaps-compar-00",
INSTITUTION="Internet Engineering Task Force",
MONTH=nov,
YEAR=1997,
NOTE="Work in progress",
ABSTRACT="[1] describes how to encode an MPLS label stack as a ''shim''
between the data link and network layer headers of a labeled frame, but
[1] does not require that this encoding be used to encode the top of the
label stack on LAN media. This document examines the alternative
encapsulations that have been proposed for LANs. One alternative is to
use the shim as the MPLS encapsulation on LAN interfaces [2]. Another
alternative is to encode the top label in the MAC header, rather than in
the shim [3]. We describe the implications of each approach.",
URL="http://www.ietf.org/internet-drafts/draft-rosen-mpls-lan-encaps-compar-00.txt"
}

@TECHREPORT{draft-rosen-tag-stack,
AUTHOR="Y. Rekhter and D. Farinacci and T. Li and A. Conta",
TITLE="Label Switching: Label Stack Encodings",
TYPE="Internet Draft",
HOWPUBLISHED="draft-rosen-tag-stack-03",
INSTITUTION="Internet Engineering Task Force",
MONTH=aug,
YEAR=1997,
NOTE="Work in progress",
ABSTRACT="'Multi-Protocol Label Switching (MPLS)' [1,2,9] requires a set
of procedures for augmenting network layer packets with 'label stacks'
(sometimes called 'tag stacks'), thereby turning them into 'labeled
packets'. Routers which support MPLS are known as 'Label Switching
Routers', or 'LSRs'. In order to transmit a labeled packet on a
particular data link, an LSR must support an encoding technique which,
given a label stack and a network layer packet, produces a labeled
packet. This document specifies the encoding to be used by an LSR in
order to transmit labeled packets on PPP data links and on LAN data
links. This document also specifies rules and procedures for processing
the various fields of the label stack encoding.",
URL="http://www.ietf.org/internet-drafts/draft-rosen-tag-stack-03.txt"
}

@TECHREPORT{draft-salgarelli-issll-mis,
AUTHOR="M. Smirnow and Henning Sanneck and D. Witaszek and L. Salgarelli and A.
Corghi",
TITLE="Supporting {IP} Multicast Integrated Services in {ATM} Networks",
TYPE="Internet Draft",
HOWPUBLISHED="draft-salgarelli-issll-mis-00.txt,.ps",
INSTITUTION="Internet Engineering Task Force",
MONTH=nov,
YEAR=1997,
NOTE="Work in progress",
ABSTRACT="This memo presents an integrated, server-based mechanism for
the efficient support of the IP Integrated Services (IIS) model in ATM
networks, namely the Multicast Integration Server (MIS) architecture.
Instead of viewing IP-ATM multicast address resolution and QoS support
separately, the approach in this memo is to consider such issues in an
integrated manner. In particular, the MIS architecture defines how a
layer-3 setup protocol as RSVP can be mapped to and integrated with a
layer-2 multicast address resolution protocol as EARTH - EAsy Multicast
Routing THrough ATM clouds. With the use of EARTH, several ATM
point-to-multipoint connections with different QoS parameters can be
associated to a single IP multicast address. An RSVP server (RSVP-S)
within the MIS is used to distribute RSVP messages inside the ATM cloud
and to set the corresponding QoS state in the address resolution table
of EARTH (setup protocol mapping). In addition, this memo defines a
quantized heterogeneity model which supports, together with the MIS,
advanced IIS features as QoS heterogeneity and dynamic QoS changes in
IP-ATM networks.",
URL="http://www.ietf.org/internet-drafts/draft-salgarelli-issll-mis-00.txt,.ps"
}

@TECHREPORT{draft-schulzrinne-http-status,
AUTHOR="Henning Schulzrinne",
TITLE="Assignment of Status Codes for {HTTP} and {HTTP-Derived} Protocols",
TYPE="Internet Draft",
HOWPUBLISHED="draft-schulzrinne-http-status-00",
INSTITUTION="Internet Engineering Task Force",
MONTH=jul,
YEAR=1997,
NOTE="Work in progress",
KEYWORDS="HTTP; status codes; RTSP; SIP",
ABSTRACT="A number of other protocols may make use of HTTP syntax and
facilities; this memo defines a mechanism for IANA to allocate status
codes",
URL="http://www.ietf.org/internet-drafts/draft-schulzrinne-http-status-00.txt"
}

@TECHREPORT{draft-simpson-cbc,
AUTHOR="W. Simpson",
TITLE="{ESP} with Cipher Block Chaining {(CBC)}",
TYPE="Internet Draft",
HOWPUBLISHED="draft-simpson-cbc-01",
INSTITUTION="Internet Engineering Task Force",
MONTH=jul,
YEAR=1997,
NOTE="Work in progress",
ABSTRACT="This document describes the Cipher Block Chaining (CBC) mode,
used by a number of IP Encapsulating Security Payload (ESP) transforms.",
URL="http://www.ietf.org/internet-drafts/draft-simpson-cbc-01.txt"
}

@TECHREPORT{draft-simpson-ipsec-cbcs,
AUTHOR="W. Simpson",
TITLE="{ESP} with Cipher Block {CheckSums} {(CBCS)}",
TYPE="Internet Draft",
HOWPUBLISHED="draft-simpson-ipsec-cbcs-01",
INSTITUTION="Internet Engineering Task Force",
MONTH=jul,
YEAR=1997,
NOTE="Work in progress",
ABSTRACT="This document describes the Cipher Block Chaining mode with
addi- tional single or double parallel CheckSums for integrity, used
with a number of Internet Encapsulating Security Payload (ESP)
transforms. This version is described in terms of 64-bit block ciphers,
but can be expanded to other block sizes.",
URL="http://www.ietf.org/internet-drafts/draft-simpson-ipsec-cbcs-01.txt"
}

@TECHREPORT{draft-simpson-spki-shrinkwrap,
AUTHOR="W. Simpson and A. Keromytis",
TITLE="{ShrinkWrap}",
TYPE="Internet Draft",
HOWPUBLISHED="draft-simpson-spki-shrinkwrap-01",
INSTITUTION="Internet Engineering Task Force",
MONTH=sep,
YEAR=1997,
NOTE="Work in progress",
ABSTRACT="This protocol facilitates the use of Simple Public Key
Infrastructure [SPKI] certificate chains with Internet Protocol Security
key management protocols.",
URL="http://www.ietf.org/internet-drafts/draft-simpson-spki-shrinkwrap-01.txt"
}

@TECHREPORT{draft-steinback-ldap-mailgroups,
AUTHOR="B. Steinback",
TITLE="Using {LDAP} for {SMTP} Mailing Lists and Aliases",
TYPE="Internet Draft",
HOWPUBLISHED="draft-steinback-ldap-mailgroups-00",
INSTITUTION="Internet Engineering Task Force",
MONTH=sep,
YEAR=1997,
NOTE="Work in progress",
ABSTRACT="Directory services based on the Lightweight Directory Access
Protocol (LDAP) [1] and X.500 [2] provide a general-purpose means to
store information about users and other network entities. One such use
is to store information on groups. There are LDAP standards established
for this purpose, e.g. the groupOfUniqueNames [3]. However, currently
there are no standards for a very important use of Groups, as SMTP
Mailing Lists or Aliases. This document discusses how we at Netscape
have made this extension, with the intent of providing useful
information towards perhaps creating standards for this important use of
LDAP.",
URL="http://www.ietf.org/internet-drafts/draft-steinback-ldap-mailgroups-00.txt"
}

@TECHREPORT{draft-suzuki-res-resv-svc-arch,
AUTHOR="M. Suzuki",
TITLE="Architecture of the Resource Reservation Service for the Commercial
Internet",
TYPE="Internet Draft",
HOWPUBLISHED="draft-suzuki-res-resv-svc-arch-02",
INSTITUTION="Internet Engineering Task Force",
MONTH=oct,
YEAR=1997,
NOTE="Work in progress",
ABSTRACT="The purpose of this document is to clarify the architecture
that should be used for the resource reservation service for the
commercial Internet. First, this document explains the basis of the
tariff for current telecommunication and Internet services. Then it
clarifies problems in the billing for Internet service, and describes
how billing can be improved by using the resource reservation setup
protocol. Finally, it also studies technical and application models for
a commercial resource reservation service model, and clarifies an
architecture for the resource reservation setup protocol.",
URL="http://www.ietf.org/internet-drafts/draft-suzuki-res-resv-svc-arch-02.txt"
}

@TECHREPORT{draft-teow-fabric-mib,
AUTHOR="K. Teow",
TITLE="Definitions of Managed Objects for the Fabric Element in Fibre Channel
Standard",
TYPE="Internet Draft",
HOWPUBLISHED="draft-teow-fabric-mib-03",
INSTITUTION="Internet Engineering Task Force",
MONTH=oct,
YEAR=1997,
NOTE="Work in progress",
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 defines the objects for managing
the operations of the Fabric Element portion of the Fibre Channel
Standards. This memo specifies a MIB module in a manner that is both
compliant to the SNMPv2 SMI, and semantically identical to the peer
SNMPv1 definitions.",
URL="http://www.ietf.org/internet-drafts/draft-teow-fabric-mib-03.txt"
}

@TECHREPORT{draft-thorne-vbi,
AUTHOR="N. Thorne",
TITLE="{THE} {TRANSMISSION} {OF} {IP} {OVER} {THE} {VERTICAL} {BLANKING}
{INTERVAL} {OF} A {PAL} {TELEVISION} {SIGNAL}",
TYPE="Internet Draft",
HOWPUBLISHED="draft-thorne-vbi-00",
INSTITUTION="Internet Engineering Task Force",
MONTH=nov,
YEAR=1997,
NOTE="Work in progress",
ABSTRACT="This is an Internet-Draft, which describes a method for
broadcasting multicast IP data using the vertical blanking interval of a
PAL television signal. It includes a description for compressing
multicast IP headers on unidirectional networks, a framing protocol
identical to SLIP, forward error correction schemes for the WST
standards. A related Internet-Draft, Ref.[1], is progressing
transmission of IP over the VBI of an NTSC television signal. Keywords:
VBI, PAL, broadcast, push, FEC, television, NABTS, WST, IP",
URL="http://www.ietf.org/internet-drafts/draft-thorne-vbi-00.txt"
}

@TECHREPORT{draft-tsuchiya-ipv4-ipv6-translator,
AUTHOR="Y. Atarashi and K. Watanabe and M. Sumikawa and K. Tsuchiya and T. Miyamoto
and K. Yamamoto and J. Murai",
TITLE="A Communication Mechanism between {IPv4} and {IPv6}",
TYPE="Internet Draft",
HOWPUBLISHED="draft-tsuchiya-ipv4-ipv6-translator-00",
INSTITUTION="Internet Engineering Task Force",
MONTH=nov,
YEAR=1997,
NOTE="Work in progress",
ABSTRACT="In the late stage of the transition from IPv4 to IPv6, IPv4
lands are interconnected by IPv6 ocean and it is necessary for an IPv4
node and an IPv6 to communicate directly. This memo proposes a mechanism
to enable such direct communication with extension name servers, an
address mapper, and translators for each IPv4 land.",
URL="http://www.ietf.org/internet-drafts/draft-tsuchiya-ipv4-ipv6-translator-00.txt"
}

@TECHREPORT{draft-valencia-l2f,
AUTHOR="T. Kolar and M. Littlewood and A. Valencia",
TITLE="Layer Two Forwarding (Protocol) {'L2F'}",
TYPE="Internet Draft",
HOWPUBLISHED="draft-valencia-l2f-00",
INSTITUTION="Internet Engineering Task Force",
MONTH=oct,
YEAR=1997,
NOTE="Work in progress",
ABSTRACT="Virtual dial-up allows many separate and autonomous protocol
domains to share common access infrastructure including modems, Access
Servers, and ISDN routers. Previous RFCs have specified protocols for
supporting IP dial-up via SLIP [1] and multiprotocol dial-up via PPP
[2]. This document describes the Layer Two Forwarding protocol (L2F)
which permits the tunneling of the link layer (i.e., HDLC, async HDLC,
or SLIP frames) of higher level protocols. Using such tunnels, it is
possible to divorce the location of the initial dial- up server from the
location at which the dial-up protocol connection is terminated and
access to the network provided.",
URL="http://www.ietf.org/internet-drafts/draft-valencia-l2f-00.txt"
}

@TECHREPORT{draft-viswanathan-mpls-rsvp,
AUTHOR="A. Viswanathan and S. Blake and V. Srinivasan",
TITLE="Soft State Switching A Proposal to Extend {RSVP} for Switching {RSVP} Flows",
TYPE="Internet Draft",
HOWPUBLISHED="draft-viswanathan-mpls-rsvp-00",
INSTITUTION="Internet Engineering Task Force",
MONTH=aug,
YEAR=1997,
NOTE="Work in progress",
ABSTRACT="This memo describes a mechanism for establishing a switched
path with guaranteed Quality of Service for RSVP [1] flows in a
MultiProtocol Label Switching (MPLS) environment. It proposes an
extension to the RSVP protocol that allows the establishment of a
sequence of label switched hops along the hop-by-hop routed path by
enabling adjacent nodes to exchange MPLS labels [11]. The labels may
correspond to information that identifies a layer 2 virtual connection;
for example, the VPI/VCI value in the case of an ATM-based
infrastructure.",
URL="http://www.ietf.org/internet-drafts/draft-viswanathan-mpls-rsvp-00.txt"
}

@TECHREPORT{draft-wahl-ldapv3-trigger,
AUTHOR="M. Wahl",
TITLE="{LDAPv3} Change Log Triggered Search Result Control",
TYPE="Internet Draft",
HOWPUBLISHED="draft-wahl-ldapv3-trigger-00",
INSTITUTION="Internet Engineering Task Force",
MONTH=dec,
YEAR=1997,
NOTE="Work in progress",
ABSTRACT="This document defines a LDAPv3 [2] control to be used on the
Search Request to allow a client to retrieve information on changes
which are made to the directory information tree held by that server.",
URL="http://www.ietf.org/internet-drafts/draft-wahl-ldapv3-trigger-00.txt"
}

@TECHREPORT{draft-wahl-mime-schema,
AUTHOR="M. Wahl",
TITLE="A {MIME} Directory Profile for {LDAP} Schema",
TYPE="Internet Draft",
HOWPUBLISHED="draft-wahl-mime-schema-01",
INSTITUTION="Internet Engineering Task Force",
MONTH=nov,
YEAR=1997,
NOTE="Work in progress",
ABSTRACT="This document defines a MIME directory profile [1] for holding
an LDAP [2] schema. It is intended for communication with the Internet
schema listing service [3].",
URL="http://www.ietf.org/internet-drafts/draft-wahl-mime-schema-01.txt"
}

@TECHREPORT{draft-wang-diff-serv-usd,
AUTHOR="Z. Wang",
TITLE="{User-Share} Differentiation {(USD)} Scalable bandwidth allocation for
differentiated services",
TYPE="Internet Draft",
HOWPUBLISHED="draft-wang-diff-serv-usd-00",
INSTITUTION="Internet Engineering Task Force",
MONTH=dec,
YEAR=1997,
NOTE="Work in progress",
ABSTRACT="In this memo, we present a new differentiated service scheme
called ''User-Share Differentiation (USD)''. The USD scheme is based on
the principle of link sharing. The scheme allows ISPs to differentiate
traffic flows on a per-user basis, providing minimum bandwidth guar-
antee and share-based bandwidth sharing. We first look at the objec-
tives of differentiated services, and the problems with the current
proposals, then present the details of the USD scheme. Finally we
examine the implementation and standardization issues",
URL="http://www.ietf.org/internet-drafts/draft-wang-diff-serv-usd-00.txt"
}

@TECHREPORT{draft-wang-ion-scsp-mib,
AUTHOR="C. Wang and J. Luciani and C. Verrilli",
TITLE="Definitions of Managed Objects for Server Cache Synchronization Protocol
Using {SMIv2}",
TYPE="Internet Draft",
HOWPUBLISHED="draft-wang-ion-scsp-mib-00",
INSTITUTION="Internet Engineering Task Force",
MONTH=nov,
YEAR=1997,
NOTE="Work in progress",
ABSTRACT="This document defines the Management Information Base (MIB)
for supporting Server Cache Synchronization Protocol (SCSP)[1], [2],
[3], [4]. SCSP is used to solve the generalized cache
synchronization/cache-replication problem for distributed protocol
entities. In a client/server paradigm, SCSP synchronizes caches (or a
portion of the caches) of a set of server entities of a particular
protocol which are bound to a Server Group. The MIB module specified in
this document follows the Structure of Management Information (SMI) for
the Simple Network Management Protocol (SNMP) Version 2.",
URL="http://www.ietf.org/internet-drafts/draft-wang-ion-scsp-mib-00.txt"
}

@TECHREPORT{draft-warwick-tokenring,
AUTHOR="K. Lee and T. Warwick",
TITLE="Dedicated Token Ring Interface {MIB}",
TYPE="Internet Draft",
HOWPUBLISHED="draft-warwick-tokenring-02",
INSTITUTION="Internet Engineering Task Force",
MONTH=dec,
YEAR=1997,
NOTE="Work in progress",
ABSTRACT="This document contains an extract from the approved text of
IEEE standard 802.5R ''Dedicated Token Ring''. The extract comprises the
Interface MIB for the Dedicated Token Ring interface, in SNMPv2 format.
There are no changes to the MIB from the Draft 7 version. 802.5R is a
standard that encompasses the existing 802.5 token- passing method of
operation, and also defines a new duplex method of operation for use
only on dedicated point to point links, that does not use tokens for
data transmission.",
URL="http://www.ietf.org/internet-drafts/draft-warwick-tokenring-02.txt"
}

@TECHREPORT{draft-warwick-tokenring-arch,
AUTHOR="K. Lee and T. Warwick",
TITLE="Dedicated Token Ring Concentrator {MIB}",
TYPE="Internet Draft",
HOWPUBLISHED="draft-warwick-tokenring-arch-02",
INSTITUTION="Internet Engineering Task Force",
MONTH=dec,
YEAR=1997,
NOTE="Work in progress",
ABSTRACT="This document contains an extract from the approved text of
IEEE standard 802.5R ''Dedicated Token Ring''. The extract comprises the
MIB for the Dedicated Token Ring Concentrator, in SNMPv2 format. The
changes from the previous version of this draft are small but important,
and are in the area of CRF creation, where a RowStatus mechanism
replaces the previous way of creating CRFs. 802.5R is a standard that
encompasses the existing 802.5 token- passing method of operation, and
also defines a new duplex method of operation for use only on dedicated
point to point links, that does not use tokens for data transmission.
The architecture of a DTR Concentrator is defined in the 802.5R
standard. It is a MAC layer bridging device, which uses a new set of
forwarding rules that ease interoperability between source routing and
transparent bridging in an 802.5 LAN. The DTR Concentrator MIB is
derived from the Source Routing and Transparent Bridge MIBs (RFCs 1525
and 1493).",
URL="http://www.ietf.org/internet-drafts/draft-warwick-tokenring-arch-02.txt"
}

@TECHREPORT{draft-watson-dhc-serv-verify,
AUTHOR="O. Gudmundsson",
TITLE="{DHCP} Server Verification by Client Via {DNSSEC}",
TYPE="Internet Draft",
HOWPUBLISHED="draft-watson-dhc-serv-verify-00",
INSTITUTION="Internet Engineering Task Force",
MONTH=jul,
YEAR=1997,
NOTE="Work in progress",
ABSTRACT="The document defines a mechanism to allow a DHCP client to
verify the authenticity of a DHCP server configuration offer using
DNSSEC. Currently DHCP clients have no way to assess which of DHCP
OFFERS are from valid DHCP servers, and which are not. Malicious DHCP
servers can cause various network problems for unsuspecting clients. In
order to support DHCP server authorization a new DNS Resource Record
type (ALLOC) is added. Using the ALLOC record in combination with the
servers KEY record the client can authoritatively assess if the server
is authorized.",
URL="http://www.ietf.org/internet-drafts/draft-watson-dhc-serv-verify-00.txt"
}

@TECHREPORT{draft-wing-smtp-capabilities,
AUTHOR="N. Joffe and D. Wing",
TITLE="Capabilities Exchange over {SMTP}",
TYPE="Internet Draft",
HOWPUBLISHED="draft-wing-smtp-capabilities-00",
INSTITUTION="Internet Engineering Task Force",
MONTH=aug,
YEAR=1997,
NOTE="Work in progress",
ABSTRACT="This document describes an extension to SMTP [RFC821] which
provides a mechanism for capabilities exchange so the sender knows the
capabilities of the ultimate recipient or the ESMTP server itself.",
URL="http://www.ietf.org/internet-drafts/draft-wing-smtp-capabilities-00.txt"
}

@TECHREPORT{draft-wing-smtp-session,
AUTHOR="N. Joffe and D. Wing and L. Masinter",
TITLE="Immediate Delivery over {SMTP}",
TYPE="Internet Draft",
HOWPUBLISHED="draft-wing-smtp-session-00",
INSTITUTION="Internet Engineering Task Force",
MONTH=aug,
YEAR=1997,
NOTE="Work in progress",
ABSTRACT="This memo defines an extension to SMTP [RFC821] which provides
a mechanism for immediate message delivery over ESMTP, bypassing SMTP's
normal store-and-forward behavior.",
URL="http://www.ietf.org/internet-drafts/draft-wing-smtp-session-00.txt"
}

@TECHREPORT{draft-xu-isakmp-app,
AUTHOR="L. Harn and Y. Xu",
TITLE="The {ISAKMP} Applications on Security Related Failure Handling",
TYPE="Internet Draft",
HOWPUBLISHED="draft-xu-isakmp-app-00",
INSTITUTION="Internet Engineering Task Force",
MONTH=nov,
YEAR=1997,
NOTE="Work in progress",
ABSTRACT="A Security Association is a set of security related
information between two or more entities. The Internet Security
Association and Key Management Protocol defines procedures and packet
formats to authenticate a communicating peer, and establish, negotiate,
modify and delete Security Associations. This document describes a new
ISAKMP application that utilizes ISAKMP negotiation functions to handle
security operation failures of other security protocols.",
URL="http://www.ietf.org/internet-drafts/draft-xu-isakmp-app-00.txt"
}

@TECHREPORT{draft-zawinski-posted-to,
AUTHOR="J. Zawinski",
TITLE="Identification of messages delivered via both mail and news",
TYPE="Internet Draft",
HOWPUBLISHED="draft-zawinski-posted-to-00",
INSTITUTION="Internet Engineering Task Force",
MONTH=oct,
YEAR=1997,
NOTE="Work in progress",
ABSTRACT="This draft defines a format to be used when delivering a
single message to multiple destinations, where some destinations are
newsgroups and some destinations are email mailboxes.",
URL="http://www.ietf.org/internet-drafts/draft-zawinski-posted-to-00.txt"
}

@TECHREPORT{draft-zhang-ospf-dvl,
AUTHOR="Z. Zhang",
TITLE="Fixing Backbone Partition with Dynamic Virtual Links",
TYPE="Internet Draft",
HOWPUBLISHED="draft-zhang-ospf-dvl-01",
INSTITUTION="Internet Engineering Task Force",
MONTH=nov,
YEAR=1997,
NOTE="Work in progress",
ABSTRACT="This document proposes a Dynamic Virtual Link (DVL) algorithm
to dynamically detect and fix OSPF backbone area partition. In the DVL
algorithm, each ABR periodically checks if it can reach via backbone
area all other ABRs that it can reach via its transit areas. If not, it
knows that a backbone partition has occurred and a spanning tree of
Dynamic Virtual Links are created. When the DVLs are not needed, they
are automatically deleted.",
URL="http://www.ietf.org/internet-drafts/draft-zhang-ospf-dvl-01.txt"
}

@TECHREPORT{draft-zhu-dns-url-level-addr,
AUTHOR="H. Zhu",
TITLE="{DNS} and {URL} Level Addressing for Public {Circuit-Switching} Network
Devices",
TYPE="Internet Draft",
HOWPUBLISHED="draft-zhu-dns-url-level-addr-00",
INSTITUTION="Internet Engineering Task Force",
MONTH=oct,
YEAR=1997,
NOTE="Work in progress",
ABSTRACT="Recently there are a number of efforts [sw1, sw2, in,tpc,
etc.] of trying to connect the packet-switching network with
circuit-switching network, especially connecting the Internet with
public telephone networks. The first problem of such interconnection is
naming and addressing, later will come with directory services and
routing problems. This draft concentrates on naming for DNS and URL.
Other problems are discussed in other documents [utrpt, framework].",
URL="http://www.ietf.org/internet-drafts/draft-zhu-dns-url-level-addr-00.txt"
}

@TECHREPORT{draft-zhu-public-circuit-switch,
AUTHOR="H. Zhu",
TITLE="Framework for Interconnecting Internet with Public {Circuit-Switching}
Network",
TYPE="Internet Draft",
HOWPUBLISHED="draft-zhu-public-circuit-switch-00",
INSTITUTION="Internet Engineering Task Force",
MONTH=nov,
YEAR=1997,
NOTE="Work in progress",
ABSTRACT="Recently there are a number of efforts trying to connect the
packet- switching network with circuit-switching network, especially the
Internet with public telephone networks. The first problem of such
interconnection is naming and addressing, which are described in some
other drafts ([dnsurl], [telurl1], [faxemail]). This draft gives a brief
framework on what the problems we may have in architecture and
technology when connecting these two networks, and the possible
solutions for these problems.",
URL="http://www.ietf.org/internet-drafts/draft-zhu-public-circuit-switch-00.txt"
}

@TECHREPORT{Garr9707:Interoperation,
AUTHOR="Mark Garrett and M. Borden",
TITLE="Interoperation of {Controlled-Load} Service and Guaranteed Service with
{ATM}",
TYPE="Internet Draft",
INSTITUTION="Internet Engineering Task Force",
MONTH=jul,
YEAR=1997,
NOTE="Work in progress"
}

@TECHREPORT{Ghan9705:Framework,
AUTHOR="A. Ghanwani and W. Pace and V. Srinivasan",
TITLE="A Framework for Providing Integrated Services Over Shared and Switched
{LAN} Technologies",
TYPE="Internet Draft",
INSTITUTION="Internet Engineering Task Force",
MONTH=may,
YEAR=1997,
NOTE="Work in progress"
}

@TECHREPORT{draft-adams-dcs,
AUTHOR="C. Adams and R. Zuccherato",
TITLE="Data Certification Server Protocols",
TYPE="Internet Draft",
HOWPUBLISHED="draft-adams-dcs-00",
INSTITUTION="Internet Engineering Task Force",
MONTH=jun,
YEAR=1998,
NOTE="Work in progress",
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].",
URL="http://www.ietf.org/internet-drafts/draft-adams-dcs-00.txt"
}

@TECHREPORT{draft-adams-notary,
AUTHOR="C. Adams and R. Zuccherato",
TITLE="Notary Protocols",
TYPE="Internet Draft",
HOWPUBLISHED="draft-adams-notary-01",
INSTITUTION="Internet Engineering Task Force",
MONTH=feb,
YEAR=1998,
NOTE="Work in progress",
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.",
URL="http://www.ietf.org/internet-drafts/draft-adams-notary-01.txt"
}

@TECHREPORT{draft-adams-time-stamp,
AUTHOR="C. Adams and D. Pinkas and P. Cain and R. Zuccherato",
TITLE="Time Stamp Protocols",
TYPE="Internet Draft",
HOWPUBLISHED="draft-adams-time-stamp-02",
INSTITUTION="Internet Engineering Task Force",
MONTH=jun,
YEAR=1998,
NOTE="Work in progress",
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.",
URL="http://www.ietf.org/internet-drafts/draft-adams-time-stamp-02.txt"
}

@TECHREPORT{draft-agapi-ini-gwloc,
AUTHOR="C. Agapi and C. Chiu and T. Chong and H. Phillips and B. Willingham",
TITLE="Internet Telephony Gateway Location Service Protocol",
TYPE="Internet Draft",
HOWPUBLISHED="draft-agapi-ini-gwloc-00",
INSTITUTION="Internet Engineering Task Force",
MONTH=nov,
YEAR=1998,
NOTE="Work in progress",
ABSTRACT="The development of IP to PSTN gateways has made it possible
for users of the two disparate networks to place 'telephone' calls
between the two networks with little effort. Users placing calls from an
IP network to the PSTN network must choose a gateway to act as a bridge
between the two networks. Selection of a gateway can be based on any
number of criteria, such as price, codecs, version, billing, etc. In
this draft we propose a gateway location service for this purpose. The
gateway location service protocol is an instantiation of the Service
Location Protocol that has been modified to run in a wide area network
across many administrative domains.",
URL="http://www.ietf.org/internet-drafts/draft-agapi-ini-gwloc-00.txt"
}

@TECHREPORT{draft-akkiraju-nat-multihoming,
AUTHOR="P. Akkiraju and Y. Rekhter",
TITLE="A Multihoming solution using {NATs}",
TYPE="Internet Draft",
HOWPUBLISHED="draft-akkiraju-nat-multihoming-00",
INSTITUTION="Internet Engineering Task Force",
MONTH=nov,
YEAR=1998,
NOTE="Work in progress",
ABSTRACT="Multihoming to upstream ISPs is a requirement today for most
networks in the Internet. The most common motivation to multihome is for
reliable, non-stop access to the Internet. However, Multihoming creates
scaling problems for the global routing infrastructure by making route
aggregation more difficult for multihomed networks. Multihoming also
complicates the addressing scheme used by the network. Another
requirement for multihomed networks is the ability to load balance
traffic between the multiple links to upstream ISPs. This requirement is
difficult to fulfill for traffic flow in both directions as the
multihomed network has no control over the return path of the packet.",
URL="http://www.ietf.org/internet-drafts/draft-akkiraju-nat-multihoming-00.txt"
}

@TECHREPORT{draft-allan-ion-mars-proxy,
AUTHOR="D. Allan",
TITLE="{MARS} Proxy",
TYPE="Internet Draft",
HOWPUBLISHED="draft-allan-ion-mars-proxy-00",
INSTITUTION="Internet Engineering Task Force",
MONTH=mar,
YEAR=1998,
NOTE="Work in progress",
ABSTRACT="The Point-to-Point Protocol (PPP) [1] has been proposed as an
access vehicle for public ATM networks. Support for multicast in this
environment via either RAS replication, or a adding MARS client side by
side with PPP is problematic on several fronts. This document describes
how an ATM attached system can act as a MARS proxy on behalf of a PPP
client. This solution circumvents many of the associated problems with
respect to VC frugality, scalability, and authentication.",
URL="http://www.ietf.org/internet-drafts/draft-allan-ion-mars-proxy-00.txt"
}

@TECHREPORT{draft-andersen-isss-ws-dir-ldifext,
AUTHOR="E. Andersen",
TITLE="The Extended {LDAP} Data Interchange Format {(LDIFext)} Technical
Specification",
TYPE="Internet Draft",
HOWPUBLISHED="draft-andersen-isss-ws-dir-ldifext-00",
INSTITUTION="Internet Engineering Task Force",
MONTH=jun,
YEAR=1998,
NOTE="Work in progress",
ABSTRACT="This document describes a file format known as Extended LDAP
Data Interchange Format (LDIFext) that builds on the LDAP Data
Interchange Format (LDIF). LDIFext is backward compatible with LDIF.
Based on the LDIFext specification it is possible to build either a
basic LDIF file or an LDIFext file. LDIFext is in particular applicable
in situation where several participating systems are masters of pieces
of information about the same object and where the participating systems
do not necessarily use the same name space. LDIFext also allows for more
efficient bulk transfer.",
URL="http://www.ietf.org/internet-drafts/draft-andersen-isss-ws-dir-ldifext-00.txt"
}

@TECHREPORT{draft-angelos-spki-keynote,
AUTHOR="A. Keromytis and M. Blaze and J. Feigenbaum",
TITLE="The {KeyNote} Trust Management System",
TYPE="Internet Draft",
HOWPUBLISHED="draft-angelos-spki-keynote-01",
INSTITUTION="Internet Engineering Task Force",
MONTH=jun,
YEAR=1998,
NOTE="Work in progress",
ABSTRACT="This memo describes KeyNote, a simple trust-management system
to support public-key infrastructure. It outlines the syntax and
semantics of keynote credentials, describes action environment
processing, and describes the application architecture into which a
KeyNote implementation would fit.",
URL="http://www.ietf.org/internet-drafts/draft-angelos-spki-keynote-01.txt"
}

@TECHREPORT{draft-anker-congress,
AUTHOR="T. Anker and D. Breitgand and D. Dolev and Z. Levy",
TITLE="{IMSS:} {IP} Multicast Shortcut Service",
TYPE="Internet Draft",
HOWPUBLISHED="draft-anker-congress-01",
INSTITUTION="Internet Engineering Task Force",
MONTH=jan,
YEAR=1998,
NOTE="Work in progress",
ABSTRACT="This memo describes an IP Multicast Shortcut Service (IMSS)
over a large ATM cloud. The service enables cut-through routing between
routers serving different Logical IP Subnets (LISs). The presented
solution is complementary to MARS [2], adopted as the IETF standard
solution for IP multicast over ATM. IMSS consists of two orthogonal
components: CONnection-oriented Group address RESolution Service
(CONGRESS) and IP multicast SErvice for Non-broadcast Access Networking
TEchnology (IP-SENATE). An IP class D address is resolved into a set of
addresses of multicast routers that should receive the multicast traffic
targeted to this class D address. This task is accomplished using
CONGRESS. The cut-through routing decisions and actual data transmission
are performed by IP- SENATE. IMSS preserves the classical LIS model [8].
The scope of IMSS is to facilitate inter-LIS cut-through routing, while
MARS provides tools for the intra-LIS IP multicast.",
URL="http://www.ietf.org/internet-drafts/draft-anker-congress-01.txt"
}

@TECHREPORT{draft-arkko-acctreq,
AUTHOR="J. Arkko",
TITLE="Requirements for {Internet-Scale} Accounting Management",
TYPE="Internet Draft",
HOWPUBLISHED="draft-arkko-acctreq-00",
INSTITUTION="Internet Engineering Task Force",
MONTH=aug,
YEAR=1998,
NOTE="Work in progress",
ABSTRACT="Over the years, as Internet services have evolved,
sophisticated inter-domain applications such as roaming, voice over IP,
Internet fax, and QoS provisioning have arisen. This document discusses
whether accounting for these services services can be reliably and
securely accomplished using established techniques, and explores the
requirements for Internet-scale Accounting Management.",
URL="http://www.ietf.org/internet-drafts/draft-arkko-acctreq-00.txt"
}

@TECHREPORT{draft-awduche-mpls-traffic-eng,
AUTHOR="M. O'Dell and J. Malcolm and J. Agogbua and Daniel Awduche and J. McManus",
TITLE="Requirements for Traffic Engineering Over {MPLS}",
TYPE="Internet Draft",
HOWPUBLISHED="draft-awduche-mpls-traffic-eng-00",
INSTITUTION="Internet Engineering Task Force",
MONTH=apr,
YEAR=1998,
NOTE="Work in progress",
ABSTRACT="This Internet draft presents a set of requirements for Traffic
Engineering over multiprotocol label switching (MPLS). It identifies the
functional capabilities required to implement policies that facilitate
efficient and reliable network operations in an MPLS domain. These
capabilities can be used to optimize the utilization of network
resources and enhance traffic oriented performance characteristics.",
URL="http://www.ietf.org/internet-drafts/draft-awduche-mpls-traffic-eng-00.txt"
}

@TECHREPORT{draft-ayandeh-mpls-dynamics,
AUTHOR="S. Ayandeh and Y. Fan",
TITLE="{MPLS} Routing Dynamics",
TYPE="Internet Draft",
HOWPUBLISHED="draft-ayandeh-mpls-dynamics-00",
INSTITUTION="Internet Engineering Task Force",
MONTH=mar,
YEAR=1998,
NOTE="Work in progress",
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.",
URL="http://www.ietf.org/internet-drafts/draft-ayandeh-mpls-dynamics-00.txt"
}

@TECHREPORT{draft-balabanian-intserv-mpeg4-dmif,
AUTHOR="V. Balabanian",
TITLE="The Use of {MPEG-4/DMIF} and {RSVP} with Integrated Services",
TYPE="Internet Draft",
HOWPUBLISHED="draft-balabanian-intserv-mpeg4-dmif-00",
INSTITUTION="Internet Engineering Task Force",
MONTH=sep,
YEAR=1998,
NOTE="Work in progress",
ABSTRACT="This draft proposal explains how the ISO/IEC MPEG DMIF
(Delivery Multimedia Integration Framework) can be used to carry MPEG-4
streams according to required media specific QoSs using RSVP with
Integrated Services. Comments are solicited and should be addressed to
the working group's mailing list at int-serv(at)isi.edu and/or the
authors.",
URL="http://www.ietf.org/internet-drafts/draft-balabanian-intserv-mpeg4-dmif-00.txt"
}

@TECHREPORT{draft-balabanian-rtp-mpeg4-dmif,
AUTHOR="V. Balabanian",
TITLE="The Role of {DMIF} in Support of {RTP} {MPEG-4} Payloads",
TYPE="Internet Draft",
HOWPUBLISHED="draft-balabanian-rtp-mpeg4-dmif-01",
INSTITUTION="Internet Engineering Task Force",
MONTH=sep,
YEAR=1998,
NOTE="Work in progress",
ABSTRACT="This draft technical proposal describes how RTP carrying
MPEG-4 payloads interacts with the MPEG-4 Sync layer through the MPEG
(Delivery Multimedia Integration Framework) DMIF. Single or multiple
MPEG-4 streams can be carried over one RTP session. MPEG-4 information
essential for the efficient packing and unpacking of MPEG-4 streams
into/from RTP is identified. The DMIF end-to-end signaling protocol is
applied to identify the MPEG-4 RTP payload types and ensure stack
compatibility at both sender and receiver locations. DMIF also
interprets the RTCP reports by comparing its statistics to the requested
MPEG-4 media based QoS. If the statistics fail to meet the requested QoS
then action is taken to either continue with the impaired performance,
upgrade the network service class, scale down the stream or delete the
stream. This action is apart from scalability using the stream
back-channel flow control which may be present between an encoder and
its decoder. This is an update of the draft-ietf-avt-rtp-mpeg4-dmif-00.
It reflects the latest MPEG-4 specs. In addition some clarifications are
included and an open issues section is established based on feedback
received.",
URL="http://www.ietf.org/internet-drafts/draft-balabanian-rtp-mpeg4-dmif-01.txt"
}

@TECHREPORT{draft-balabanian-rtsp-mpeg4-dmif,
AUTHOR="V. Balabanian",
TITLE="The Role of {DMIF} with {RTSP} and {MPEG-4}",
TYPE="Internet Draft",
HOWPUBLISHED="draft-balabanian-rtsp-mpeg4-dmif-00",
INSTITUTION="Internet Engineering Task Force",
MONTH=sep,
YEAR=1998,
NOTE="Work in progress",
ABSTRACT="This draft technical proposal describes how MPEG DMIF
(Delivery Multimedia Integration Framework) can be used with RTSP for
setting MPEG-4 service sessions and subsequently detaching the service.
DMIF creates an instance of DMIF RTSP augmented with QoS appropriate for
each MPEG-4 stream and also makes use of the FlexMux to carry multiple
streams on a single UDP or TCP IP flow. The stream control play/pause
etc. using RTSP is executed directly by the MPEG-4 Systems Sync Layer.
Comments are solicited and should be addressed to the working group's
mailing list at confctrl(at)isi.edu and/or the authors.",
URL="http://www.ietf.org/internet-drafts/draft-balabanian-rtsp-mpeg4-dmif-00.txt"
}

@TECHREPORT{draft-banerjea-qosmic,
AUTHOR="A. Banerjea and M. Faloutsos and R. Pankaj",
TITLE="Designing {QoSMIC:} A Quality of Service sensitive Multicast Internet
protoCol",
TYPE="Internet Draft",
HOWPUBLISHED="draft-banerjea-qosmic-00.txt,.ps",
INSTITUTION="Internet Engineering Task Force",
MONTH=may,
YEAR=1998,
NOTE="Work in progress",
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.",
URL="http://www.ietf.org/internet-drafts/draft-banerjea-qosmic-00.txt,.ps"
}

@TECHREPORT{draft-bathrick-adsllinemib-adsl,
AUTHOR="G. Bathrick",
TITLE="Definitions of Managed Objects for the {ADSL} Lines",
TYPE="Internet Draft",
HOWPUBLISHED="draft-bathrick-adsllinemib-adsl-00",
INSTITUTION="Internet Engineering Task Force",
MONTH=mar,
YEAR=1998,
NOTE="Work in progress",
ABSTRACT="This document defines a standard SNMP MIB for ADSL lines based
on the ADSL Forum standard data model. The model assumed by this MIB is
that the SNMP agent's perspective is from the ATU-C side which acts as a
proxy for the ATU-R. Each MIB instance includes information for both
ends of a single line, i.e., both the ATU-C and ATU-R. It should be
noted that the initial version of this internet-draft is dervived from
work completed by the ADSL Forum's Network Management working group and
documented in ADSL Forum TR-006 ''SNMP-based ADSL Line MIB''[9]. See
Acknowledgement Section for a list individuals of those involved with
this effort. It should also be noted that the author of this
intenet-draft was also a primary contributor of the forementioned ADSL
Forum document.",
URL="http://www.ietf.org/internet-drafts/draft-bathrick-adsllinemib-adsl-00.txt"
}

@TECHREPORT{draft-beadles-nas,
AUTHOR="M. Beadles",
TITLE="The Network Access Server",
TYPE="Internet Draft",
HOWPUBLISHED="draft-beadles-nas-01",
INSTITUTION="Internet Engineering Task Force",
MONTH=nov,
YEAR=1998,
NOTE="Work in progress",
ABSTRACT="The Network Access Server is the initial entry point to a
network for the majority of users of network services. It is the first
device in the network to provide services to an end user, and acts as a
gateway for all further services. As such, its importance to users and
ser- vice providers alike is paramount. However, the concept of a
Network Access Server has grown up over the years without being formally
defined or analyzed. This document offers a framework for the defini-
tion and analysis of a modern Network Access Server.",
URL="http://www.ietf.org/internet-drafts/draft-beadles-nas-01.txt"
}

@TECHREPORT{draft-bell-bridgemib,
AUTHOR="K. McCloghrie and P. Langille and A. Rijsinghani and A. Smith and L. Bell",
TITLE="Definitions of Managed Objects for Bridges with Traffic Classes, Multicast
Filtering and Virtual {LAN} Extensions",
TYPE="Internet Draft",
HOWPUBLISHED="draft-bell-bridgemib-00",
INSTITUTION="Internet Engineering Task Force",
MONTH=mar,
YEAR=1998,
NOTE="Work in progress",
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].",
URL="http://www.ietf.org/internet-drafts/draft-bell-bridgemib-00.txt"
}

@TECHREPORT{draft-bell-ipdc-signaling,
AUTHOR="Blaine Bell",
TITLE="{IPDC} Device Management Protocol",
TYPE="Internet Draft",
HOWPUBLISHED="draft-bell-ipdc-signaling-00",
INSTITUTION="Internet Engineering Task Force",
MONTH=aug,
YEAR=1998,
NOTE="Work in progress",
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.",
URL="http://www.ietf.org/internet-drafts/draft-bell-ipdc-signaling-00.txt"
}

@TECHREPORT{draft-berkowitz-multirqmt,
AUTHOR="H. Berkowitz",
TITLE="To Be Multihomed: Requirements and Definitions",
TYPE="Internet Draft",
HOWPUBLISHED="draft-berkowitz-multirqmt-01",
INSTITUTION="Internet Engineering Task Force",
MONTH=mar,
YEAR=1998,
NOTE="Work in progress",
ABSTRACT="As organizations find their Internet connectivity increasingly
critical to their mission, they seek ways of making that connectivity
more robust. The term ''multi-homing'' often is used to describe means
of fault-tolerant connection. Unfortunately, this term covers a variety
of mechanisms, including naming/directory services, routing, and
physical connectivity. The ''home'' may be identified by a DNS name, an
IP address, or an IP address and transport-layer port identifier. Any of
these identifiers may be translated in the path between source and
destination. This memorandum presents a systematic way to define the
requirement for resilience, and a taxonomy for describing mechanisms to
achieve it. Its intended audience is primarily people concerned with
planning and performing multihoming deployments, rather than protocol
developers. It examines both requirements and applications, with the
emphasis on the former.",
URL="http://www.ietf.org/internet-drafts/draft-berkowitz-multirqmt-01.txt"
}

@TECHREPORT{draft-berkowitz-ospfdeploy,
AUTHOR="H. Berkowitz",
TITLE="Techniques in {OSPF-based} Network Deployment",
TYPE="Internet Draft",
HOWPUBLISHED="draft-berkowitz-ospfdeploy-00",
INSTITUTION="Internet Engineering Task Force",
MONTH=mar,
YEAR=1998,
NOTE="Work in progress",
ABSTRACT="OSPF is the preferred interior routing protocol of the
Internet. It is a complex protocol intended to deal with complex
networks. While it is a powerful mechanism, it does not handle all
situations, and its appropriate use may not be obvious to beginners.
Standards track documents deal with protocol design, but deployment of
OSPF in many enterprise networks has been limited by lack of information
on best current practice information for interior routing. Best Current
Practices documents have focused on general exterior connectivity. This
memorandum is intended to complement the protocol specification by
describing the experience-based, vendor-independent techniques of OSPF
and complementary technologies in representative networks. Better
understanding of the use of OSPF features to help exterior connectivity
will help reduce the demand for complex user BGP configuration.",
URL="http://www.ietf.org/internet-drafts/draft-berkowitz-ospfdeploy-00.txt"
}

@TECHREPORT{draft-bernet-diffedge,
AUTHOR="Y. Bernet and D. Durham and F. Reichmeyer",
TITLE="Requirements of Diff-serv Boundary Routers",
TYPE="Internet Draft",
HOWPUBLISHED="draft-bernet-diffedge-01",
INSTITUTION="Internet Engineering Task Force",
MONTH=nov,
YEAR=1998,
NOTE="Work in progress",
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.",
URL="http://www.ietf.org/internet-drafts/draft-bernet-diffedge-01.txt"
}

@TECHREPORT{draft-bernet-intdiff,
AUTHOR="L. Zhang and R. Yavatkar and F. Baker and P. Ford and Y. Bernet",
TITLE="A Framework for {End-to-End} {QoS} Combining {RSVP/Intserv} and
Differentiated Services",
TYPE="Internet Draft",
HOWPUBLISHED="draft-bernet-intdiff-00",
INSTITUTION="Internet Engineering Task Force",
MONTH=mar,
YEAR=1998,
NOTE="Work in progress",
ABSTRACT="In the past several years, work on QoS enabled networks led to
the development of the Integrated Services (Intserv) architecture [12]
and the RSVP signaling protocol [1]. RSVP addresses the needs of
applications that require QoS, promising per-flow service. As the
RSVP/Intserv (from here on abbreviated to intserv) work has proceeded,
we have recognized barriers to the deployment of intserv. The reliance
of intserv on per-flow state and per-flow processing is an impediment to
its deployment in the Internet at large, and in particular in large
carrier networks. Additionally, RSVP signaling is supposed to originate
from hosts, which as of yet are not RSVP enabled in large numbers.
Recently, attention has shifted to Differentiated services (diff- serv).
Diff-serv promises to expedite the realization of QoS enabled networks
by offering a significantly simpler alternative to intserv, which
eliminates scalability concerns and which can be implemented and managed
in large networks, without requiring end-to-end deployment. However,
unlike intserv, diff-serv focuses on the needs of the large network.
This draft proposes a framework for end-to-end QoS, in which intserv and
diff-serv are used together to meet the needs of large ISPs who manage
the transit networks of the Internet, and the users of QoS applications
and hosts, who are the ISPs' ultimate customers. This focus is
important, as we believe that in the coming years, there will be a
proliferation of applications that depend on QoS and of hosts which are
capable of QoS signaling. We envision the deployment of diff-serv
capable core networks and intserv capable stub networks at the
periphery. Our framework allows each to proceed at its own pace,
providing immediate incremental benefits in areas of the network in
which one or the other is deployed and additional benefits where both
are deployed. This framework builds upon current work in the IETF
including diff-serv [10] and RSVP aggregation [8]. Many of the ideas in
this document have been previously discussed in the original intserv
architecture document [12].",
URL="http://www.ietf.org/internet-drafts/draft-bernet-intdiff-00.txt"
}

@TECHREPORT{draft-binkrich-mobisec,
AUTHOR="Jim Binkley and John Richardson",
TITLE="Security Considerations for Mobility and Firewalls",
TYPE="Internet Draft",
HOWPUBLISHED="draft-binkrich-mobisec-00",
INSTITUTION="Internet Engineering Task Force",
MONTH=nov,
YEAR=1998,
NOTE="Work in progress",
ABSTRACT="In this paper we discuss various security issues concerning
Mobile Hosts using Mobile-IP or other mobility systems (DHCP standalone)
and current firewall technology. We first present some recent attacks on
the Internet and what they might mean for mobile systems like Mobile-IP
that rely on tunneling technologies. We point out that tunnels are a
security threat and suggest how mobile systems may be made 'less
insecure' with the use of IP layer security (IPSEC) as one means for
creating Virtual Private Networks. The goal is to describe a security
model wherein mobile systems can work across the Internet and not just
as an interior routing protocol within one security and/or interior
routing domain. Both the protection of Mobile Systems abroad and of
Security Enclaves that tolerate mobile visitors must be considered.",
URL="http://www.ietf.org/internet-drafts/draft-binkrich-mobisec-00.txt"
}

@TECHREPORT{draft-blanchet-ipaddressalloc,
AUTHOR="M. Blanchet",
TITLE="A flexible allocation scheme for {IP} addresses {(IPv4} and {IPv6)}",
TYPE="Internet Draft",
HOWPUBLISHED="draft-blanchet-ipaddressalloc-00",
INSTITUTION="Internet Engineering Task Force",
MONTH=jul,
YEAR=1998,
NOTE="Work in progress",
ABSTRACT="This draft presents an IP address allocation scheme that
enables the IP allocator (the organisation that allocates addresses) to
postpone the final decision of prefix length by keeping space between
allocated bits of the different parts of the IP address. This enables
the allocator to change the different part lengths of the prefix (TLA,
subTLA, SLA, ...) even after allocated spaces. This scheme is applicable
to both IPv4 and IPv6 but is envisionned mainly for IPv6 where the
address space is larger and more flexible.",
URL="http://www.ietf.org/internet-drafts/draft-blanchet-ipaddressalloc-00.txt"
}

@TECHREPORT{draft-blanchet-preflang,
AUTHOR="M. Blanchet",
TITLE="Preferred Language Tag",
TYPE="Internet Draft",
HOWPUBLISHED="draft-blanchet-preflang-00",
INSTITUTION="Internet Engineering Task Force",
MONTH=feb,
YEAR=1998,
NOTE="Work in progress",
ABSTRACT="This memo defines a new tag which will help users and servers
to determine the best language in their communications. For example,
error messages coming from SMTP servers or HTTP servers can use this tag
to send those error messages in the preferred language for the user.",
URL="http://www.ietf.org/internet-drafts/draft-blanchet-preflang-00.txt"
}

@TECHREPORT{draft-blaze-trustmgt-keynote,
AUTHOR="M. Blaze and J. Feigenbaum and A. Keromytis and J. Ioannidis",
TITLE="The {KeyNote} {Trust-Management} System",
TYPE="Internet Draft",
HOWPUBLISHED="draft-blaze-trustmgt-keynote-00",
INSTITUTION="Internet Engineering Task Force",
MONTH=aug,
YEAR=1998,
NOTE="Work in progress",
ABSTRACT="This memo describes KeyNote, a simple trust-management system.
It outlines the syntax and semantics of KeyNote credentials, describes
action environment processing, and describes the application
architecture into which a KeyNote implementation would fit.",
URL="http://www.ietf.org/internet-drafts/draft-blaze-trustmgt-keynote-00.txt"
}

@TECHREPORT{draft-borella-aatn-dnat,
AUTHOR="M. Borella and D. Grabelsky and I. Sidhu and B. Petry",
TITLE="Distributed Network Address Translation",
TYPE="Internet Draft",
HOWPUBLISHED="draft-borella-aatn-dnat-01",
INSTITUTION="Internet Engineering Task Force",
MONTH=oct,
YEAR=1998,
NOTE="Work in progress",
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.",
URL="http://www.ietf.org/internet-drafts/draft-borella-aatn-dnat-01.txt"
}

@TECHREPORT{draft-borgonovo-qos-ds,
AUTHOR="L. Fratta and F. Borgonovo and A. Capone and M. Marchese and C. Petrioli",
TITLE="End-to-end {QoS} provisioning mechanism for Differentiated Services",
TYPE="Internet Draft",
HOWPUBLISHED="draft-borgonovo-qos-ds-00",
INSTITUTION="Internet Engineering Task Force",
MONTH=jul,
YEAR=1998,
NOTE="Work in progress",
ABSTRACT="This document presents an end-to-end mechanism to guarantee
bandwidth and delay into the Differentiated Services mechanism to
constant rate traffic such as voice and video. The mechanism requires
network routers to be able to serve packets according to three classes
of priority. The needed call admission control is performed by an end-
to-end signaling procedure that implicitly looks for the required
bandwidth and seizes it, if available. Short delays are guaranteed by
the regular structure of constant rate traffic. No entities other than
source and destination are involved and multicast operation comes at no
further cost, which makes the mechanism fully scalable and integrable
into the existing Internet.",
URL="http://www.ietf.org/internet-drafts/draft-borgonovo-qos-ds-00.txt"
}

@TECHREPORT{draft-bormann-mnnp-nndp,
AUTHOR="C. Bormann",
TITLE="Network News Distribution Protocol: Architecture and Design Guidelines",
TYPE="Internet Draft",
HOWPUBLISHED="draft-bormann-mnnp-nndp-00",
INSTITUTION="Internet Engineering Task Force",
MONTH=mar,
YEAR=1998,
NOTE="Work in progress",
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(at)va.pubnix.com and/or the author.",
URL="http://www.ietf.org/internet-drafts/draft-bormann-mnnp-nndp-00.txt"
}

@TECHREPORT{draft-bressler-sigtran-ipss7l2,
AUTHOR="W. Bressler",
TITLE="{SS7} Level Two over {IP}",
TYPE="Internet Draft",
HOWPUBLISHED="draft-bressler-sigtran-ipss7l2-00",
INSTITUTION="Internet Engineering Task Force",
MONTH=dec,
YEAR=1998,
NOTE="Work in progress",
ABSTRACT="This document proposes the use of TCP/IP as the transport
protocol for common channel signaling, Signaling System #7 (SS7). The
migration from the current 56k/64k physical layer to an IP based
transport will reduce the cost associated with dedicated trunk based
link. Also, the current signaling point (SP) network using quasi-
associated architecture will be maintained to make the transition as
seamless as possible.",
URL="ftp://www.ietf.org/internet-drafts/draft-bressler-sigtran-ipss7l2-00.txt"
}

@TECHREPORT{draft-brown-dcom-v1-spec,
AUTHOR="N. Brown and C. Kindel",
TITLE="Distributed Component Object Model Protocol {--} {DCOM/1.0}",
TYPE="Internet Draft",
HOWPUBLISHED="draft-brown-dcom-v1-spec-03",
INSTITUTION="Internet Engineering Task Force",
MONTH=mar,
YEAR=1998,
NOTE="Work in progress",
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.",
URL="http://www.ietf.org/internet-drafts/draft-brown-dcom-v1-spec-03.txt"
}

@TECHREPORT{draft-brown-e164,
AUTHOR="A. Brown",
TITLE="{E.164} Resolution",
TYPE="Internet Draft",
HOWPUBLISHED="draft-brown-e164-00",
INSTITUTION="Internet Engineering Task Force",
MONTH=nov,
YEAR=1998,
NOTE="Work in progress",
ABSTRACT="This paper addresses global access to address information and
additional subscriber and equipment information, given a telephone
number as input.",
URL="http://www.ietf.org/internet-drafts/draft-brown-e164-00.txt"
}

@TECHREPORT{draft-byrne-ldap-alias,
AUTHOR="E. Stokes and D. Byrne and L. Poitou",
TITLE="Use of Aliases within {LDAP}",
TYPE="Internet Draft",
HOWPUBLISHED="draft-byrne-ldap-alias-00",
INSTITUTION="Internet Engineering Task Force",
MONTH=apr,
YEAR=1998,
NOTE="Work in progress",
ABSTRACT="This document describes the suggested behavior for aliases for
LDAPv3 and above to improve LDAP server interoperability . The key words
'MUST', 'SHOULD', and 'MAY' used in this document are to be interpreted
as described in [Bradner97].",
URL="http://www.ietf.org/internet-drafts/draft-byrne-ldap-alias-00.txt"
}

@TECHREPORT{draft-calhoun-diameter-eap,
AUTHOR="P. Calhoun and A. Rubens and J. Haag",
TITLE="{DIAMETER} Extensible Authentication Protocol Extensions",
TYPE="Internet Draft",
HOWPUBLISHED="draft-calhoun-diameter-eap-02",
INSTITUTION="Internet Engineering Task Force",
MONTH=nov,
YEAR=1998,
NOTE="Work in progress",
ABSTRACT="The Extensible Authentication Protocol (EAP) is a PPP
extension that provides support for additional authentication methods
within PPP. This document describes how the EAP-Message and Signature
attributes may be used for providing EAP support within DIAMETER.",
URL="http://www.ietf.org/internet-drafts/draft-calhoun-diameter-eap-02.txt"
}

@TECHREPORT{draft-calhoun-diameter-ipsec-policy,
AUTHOR="P. Calhoun and S. Vakil",
TITLE="{DIAMETER} {IP} Security Policy Extensions",
TYPE="Internet Draft",
HOWPUBLISHED="draft-calhoun-diameter-ipsec-policy-00",
INSTITUTION="Internet Engineering Task Force",
MONTH=mar,
YEAR=1998,
NOTE="Work in progress",
ABSTRACT="The DIAMETER User Authentication/Authorization extension
defines a mechanism which is used by a Network Access Server (NAS) to
authenticate dial-up users. IP Security defines a mechanism of
establishing a secure link between two entities over a network. This
document defines a mechanism for DIAMETER to inform the NAS of the
security policies required for secure communication with a host.",
URL="http://www.ietf.org/internet-drafts/draft-calhoun-diameter-ipsec-policy-00.txt"
}

@TECHREPORT{draft-calhoun-diameter-qos,
AUTHOR="M. Speer and K. Peirce and P. Calhoun",
TITLE="{DIAMETER} {QOS} Extension",
TYPE="Internet Draft",
HOWPUBLISHED="draft-calhoun-diameter-qos-00",
INSTITUTION="Internet Engineering Task Force",
MONTH=may,
YEAR=1998,
NOTE="Work in progress",
ABSTRACT="This document describes a simple client/server model for
supporting QOS policies. A router that supports RSVP or one of the
proposed differentiated service schemes will require a policy database
and a means to access it. This document describes the extensions to a
protocol based originally on RADIUS [1] called DIAMETER[2]. This
document does not describe the policy database or policy enforcement.",
URL="http://www.ietf.org/internet-drafts/draft-calhoun-diameter-qos-00.txt"
}

@TECHREPORT{draft-calsyn-rvp,
AUTHOR="M. Calsyn and L. Dusseault and G. Mohr",
TITLE="{RVP:} A Presence Notification Protocol",
TYPE="Internet Draft",
HOWPUBLISHED="draft-calsyn-rvp-01",
INSTITUTION="Internet Engineering Task Force",
MONTH=mar,
YEAR=1998,
NOTE="Work in progress",
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(at)iastate.ed",
URL="http://www.ietf.org/internet-drafts/draft-calsyn-rvp-01.txt"
}

@TECHREPORT{draft-canetti-secure-multicast-taxonomy,
AUTHOR="B. Pinkas and R. Canetti",
TITLE="A taxonomy of multicast security issues (temporary version)",
TYPE="Internet Draft",
HOWPUBLISHED="draft-canetti-secure-multicast-taxonomy-00",
INSTITUTION="Internet Engineering Task Force",
MONTH=jun,
YEAR=1998,
NOTE="Work in progress",
ABSTRACT="With the growth and commercialization of the Internet, the
need for secure IP multicast is growing. In this draft we present a
taxonomy of multicast security issues. We first sketch some multicast
group parameters that are relevant to security, and outline the basic
security issues concerning multicast in general, with emphasis on IP
multicast. Next we suggest two `benchmark' scenarios for secure
multicast solutions. Lastly we review some previous works. This is a
temporary version of the document. The authors will be grateful for
remarks, and will update and revise this document accordingly.",
URL="http://www.ietf.org/internet-drafts/draft-canetti-secure-multicast-taxonomy-00.txt"
}

@TECHREPORT{draft-caronni-esp-stream,
AUTHOR="G. Caronni and M. Waldvogel",
TITLE="The {ESP} Stream Transform",
TYPE="Internet Draft",
HOWPUBLISHED="draft-caronni-esp-stream-01",
INSTITUTION="Internet Engineering Task Force",
MONTH=jul,
YEAR=1998,
NOTE="Work in progress",
ABSTRACT="This document describes a security transform providing privacy
and optional replay protection through Encapsulating Secure Payload
(ESP). The transform defines how to use ESP in conjunction with
byte-oriented stream ciphers, such as RC4 or SEAL. These stream ciphers
offer strong encryption with comparatively low computational demands,
and are thus favorable for multimedia bulk data or environments where
the computing power needed per packet should be low.",
URL="http://www.ietf.org/internet-drafts/draft-caronni-esp-stream-01.txt"
}

@TECHREPORT{draft-carpenter-ipng-6over4,
AUTHOR="B. Carpenter and C. Jung",
TITLE="Transmission of {IPv6} over {IPv4} Domains without Explicit Tunnels",
TYPE="Internet Draft",
HOWPUBLISHED="draft-carpenter-ipng-6over4-04",
INSTITUTION="Internet Engineering Task Force",
MONTH=aug,
YEAR=1998,
NOTE="Work in progress",
ABSTRACT="This memo specifies the frame format for transmission of IPv6
[IPV6] packets and the method of forming IPv6 link-local addresses over
IPv4 domains. It also specifies the content of the Source/Target Link-
layer Address option used in the Router Solicitation, Router
Advertisement, Neighbor Solicitation, and Neighbor Advertisement and
Redirect messages, when those messages are transmitted on an IPv4
network. The motivation for this method is to allow isolated IPv6 hosts,
located on a physical link which has no directly connected IPv6 router,
to become fully functional IPv6 hosts by using an IPv4 domain that
supports IPv4 multicast as their virtual local link. It uses IPv4
multicast as a 'virtual Ethernet.'",
URL="http://www.ietf.org/internet-drafts/draft-carpenter-ipng-6over4-04.txt"
}

@TECHREPORT{draft-carrasco-language-code,
AUTHOR="M. Benitez",
TITLE="Codes for language transformation",
TYPE="Internet Draft",
HOWPUBLISHED="draft-carrasco-language-code-00",
INSTITUTION="Internet Engineering Task Force",
MONTH=apr,
YEAR=1998,
NOTE="Work in progress",
ABSTRACT="This is a draft proposal to extend the RFC1766 to cover
language transformations (transliteration/transcription/trans-anything)
from one language (the source language) to another (the target
language).",
URL="http://www.ietf.org/internet-drafts/draft-carrasco-language-code-00.txt"
}

@TECHREPORT{draft-carrel-info-pppoe,
AUTHOR="L. Mamakos and K. Lidl and J. Evarts and D. Carrel and D. Simone and R.
Wheeler",
TITLE="A Method for Transmitting {PPP} Over Ethernet {'PPPoE'}",
TYPE="Internet Draft",
HOWPUBLISHED="draft-carrel-info-pppoe-02",
INSTITUTION="Internet Engineering Task Force",
MONTH=nov,
YEAR=1998,
NOTE="Work in progress",
ABSTRACT="The Point-to-Point Protocol (PPP) [1] provides a standard
method for transporting multi-protocol datagrams over point-to-point
links. This document describes how to build PPP sessions and encapsulate
PPP packets over Ethernet",
URL="http://www.ietf.org/internet-drafts/draft-carrel-info-pppoe-02.txt"
}

@TECHREPORT{draft-carter-bounded-delay,
AUTHOR="S. Carter and T. Hodgkinson and A. O'Neill and D. Mortimore",
TITLE="A Bounded-delay service for the internet",
TYPE="Internet Draft",
HOWPUBLISHED="draft-carter-bounded-delay-00",
INSTITUTION="Internet Engineering Task Force",
MONTH=nov,
YEAR=1998,
NOTE="Work in progress",
ABSTRACT="This document outlines a proposed new service class for the
internet which is intended to provide for some small proportion of the
total traffic on each link, a quantifiable, low-delay service having
essentially no packet-loss. We call this proposed service, Bounded-
delay (BD). The approach is consistent with the architecture and
philosophy of diff-serv, and could potentially make use of the proposed
EF PHB. BD is similar in many respects to Premium service which has been
described previously [Twobit], except that BD is intended specifically
to allow control of end-to-end delay in a quantifiable manner.",
URL="http://www.ietf.org/internet-drafts/draft-carter-bounded-delay-00.txt"
}

@TECHREPORT{draft-casey-vpn-extns,
AUTHOR="L. Casey",
TITLE="An extended {IP} {VPN} Architecture",
TYPE="Internet Draft",
HOWPUBLISHED="draft-casey-vpn-extns-00",
INSTITUTION="Internet Engineering Task Force",
MONTH=nov,
YEAR=1998,
NOTE="Work in progress",
ABSTRACT="This Internet Draft extends the framework for IP VPN's, as,
for example, described by Heinanen et al.[1] and Gleeson et al [2], to
include the concept of VPN Areas. VPN areas relate to the scoping of the
mechanisms (membership dissemination, tunneling etc.) used to provide IP
VPN service. VPN areas are a partitioning of the shared service
provider's network. In general, all sites within a VPN area are one
tunneled hop from each other, but multiple tunneled hops will be
required for traffic between sites served by different VPN areas. Two
reasons why Service Providers might partition their IP network into
areas in support of VPN's are to achieve scalability, and to match
administrative domain. VPN areas also facilitate the use of different IP
VPN mechanisms in different parts of the network. There are multiple
proposals for tunnel technology and discovery mechanisms for IP VPN's.
The VPN area concept allows them to co-exist in one provider's network
as well as smoothing migration to new mechanisms. This draft also
examines the impact that VPN areas have on the IP VPN framework
mechanisms described in [2]. The conclusion reached is that the best
mechanism for intra-VPN reachability dissemination is a full routing
protocol run by Virtual Routers.",
URL="http://www.ietf.org/internet-drafts/draft-casey-vpn-extns-00.txt"
}

@TECHREPORT{draft-casey-vpn-mpls,
AUTHOR="L. Casey and I. Cunningham and R. Eros",
TITLE="{IP} {VPN} Realization using {MPLS} Tunnels",
TYPE="Internet Draft",
HOWPUBLISHED="draft-casey-vpn-mpls-00",
INSTITUTION="Internet Engineering Task Force",
MONTH=nov,
YEAR=1998,
NOTE="Work in progress",
ABSTRACT="This Internet Draft describes a method of using MPLS to
realize a provider IP VPN capability. The approach described here
exploits the Label Switch Path (LSP) mesh implicitly established between
all edge routers in an MPLS domain [4]. It uses 2 levels of LSP
tunneling. The outer or base level is the hop by hop LSP tunnels that
interconnect all VPN Border (Label Switch) Routers (VBR\022s). The
'bottom of label stack', nested level provides logically single hop
tunnels between VBR\022s. For each IP VPN, single hop nested tunnels are
established between all VBR's serving that particular VPN. The draft
outlines the components involved in the MPLS IP VPN architecture and
outlines how they interact. The proposed realization is caste in terms
of the VPN areas introduced in [1] and is geared to take advantage of a
virtual router (VR) capability in the VBR's. This results in a powerful
and flexible method of providing an IP VPN service that meets the
requirements outlined in [3]. Also described are two extensions:
offering MPLS VPN service to the customer (rather than IP service) and
using Label Switching to traverse VPN areas[1].",
URL="http://www.ietf.org/internet-drafts/draft-casey-vpn-mpls-00.txt"
}

@TECHREPORT{draft-christ-rtsp-mpeg4,
AUTHOR="P. Christ and C. Guillemot and S. Wesner",
TITLE="{RTSP-based} Stream Control in {MPEG-4}",
TYPE="Internet Draft",
HOWPUBLISHED="draft-christ-rtsp-mpeg4-00",
INSTITUTION="Internet Engineering Task Force",
MONTH=nov,
YEAR=1998,
NOTE="Work in progress",
ABSTRACT="In order to support advanced interactivity as envisaged for
MPEG-4 applications, this document proposes a simple RTSP- based [1]
streams control framework - including necessary extensions to RTP
methods syntax and semantics. Reflecting syntax and semantics of the
MPEG-4 BIFS scene description [2], VRML nodes [4] and the MPEG-4 media
delivery framework (DMIF)[3], in the spirit of HTMLSMIL [5], Random
Access Point information, Range and Time parameters are introduced into
the relevant URL(s) and related signaling methods accordingly. Two
additional optional methods, R-MUTE, for Remote-MUTE, and RESUME are
also proposed.",
URL="http://www.ietf.org/internet-drafts/draft-christ-rtsp-mpeg4-00.txt"
}

@TECHREPORT{draft-chuafoo-mobileip-rafa,
AUTHOR="S. Foo and K. Chua",
TITLE="Regional Aware Foreign Agent {(RAFA)} for Fast Local Handoffs",
TYPE="Internet Draft",
HOWPUBLISHED="draft-chuafoo-mobileip-rafa-00",
INSTITUTION="Internet Engineering Task Force",
MONTH=nov,
YEAR=1998,
NOTE="Work in progress",
ABSTRACT="This document proposes an extension to the Mobile IP base
protocol. The purpose of this extension is to solve the distant
registrations, handoff latency, and key management problems among
mobility agents. It provides a easy and robust solution for secure
ubiquitous deployment of IP mobility while still maintaining
interoperability with the base protocol.",
URL="http://www.ietf.org/internet-drafts/draft-chuafoo-mobileip-rafa-00.txt"
}

@TECHREPORT{draft-codogno-mime-nntp8bit,
AUTHOR="M. Codogno",
TITLE="The {MIME} application/nntp8bit Content-type",
TYPE="Internet Draft",
HOWPUBLISHED="draft-codogno-mime-nntp8bit-00",
INSTITUTION="Internet Engineering Task Force",
MONTH=aug,
YEAR=1998,
NOTE="Work in progress",
ABSTRACT="The application/nntp8bit content-type is proposed and defined
as an efficient and simple way to transmit raw ('binary') data over an
NNTP connection, taking into account the foreseeable limitations of that
standard.",
URL="http://www.ietf.org/internet-drafts/draft-codogno-mime-nntp8bit-00.txt"
}

@TECHREPORT{draft-cohen-gena-p-base,
AUTHOR="J. Cohen and S. Aggarwal",
TITLE="General Event Notification Architecture Base",
TYPE="Internet Draft",
HOWPUBLISHED="draft-cohen-gena-p-base-01",
INSTITUTION="Internet Engineering Task Force",
MONTH=jul,
YEAR=1998,
NOTE="Work in progress",
ABSTRACT="This specification defines an HTTP notification architecture
that transmits notifications between HTTP resources. An HTTP resource
could be any object which might need to send or receive a notification,
for example a distribution list, buddy list, print job, etc.",
URL="http://www.ietf.org/internet-drafts/draft-cohen-gena-p-base-01.txt"
}

@TECHREPORT{draft-cohen-http-ext-postal,
AUTHOR="J. Cohen and  others",
TITLE="Don't Go Postal - An argument against improperly overloading the {HTTP}
{POST} Method",
TYPE="Internet Draft",
HOWPUBLISHED="draft-cohen-http-ext-postal-00",
INSTITUTION="Internet Engineering Task Force",
MONTH=feb,
YEAR=1998,
NOTE="Work in progress",
ABSTRACT="As time goes on, more and more groups are extending HTTP's
functionality. In using HTTP, a decision is made to either use a new
method name for new functionality or to overload an existing one such as
POST. Our belief is that in most cases, overloading existing method
names, with POST as a particularly troublesome example, is a bad idea.
We, as a group of individuals, suggest that the default requirement for
new HTTP functionality must be to create a new method name.",
URL="http://www.ietf.org/internet-drafts/draft-cohen-http-ext-postal-00.txt"
}

@TECHREPORT{draft-costanzo-fs-mime,
AUTHOR="A. Costanzo",
TITLE="Creating File System Object Attachments with {MIME}",
TYPE="Internet Draft",
HOWPUBLISHED="draft-costanzo-fs-mime-00",
INSTITUTION="Internet Engineering Task Force",
MONTH=aug,
YEAR=1998,
NOTE="Work in progress",
ABSTRACT="This memo defines a new top level type for MIME and its
subtypes and mappings to file types. The intent of this draft is to both
define a new comprehensive top level type and define a method and usage
for one of the to be defined subtypes. This new subtype in itself is a
media type. The purpose of which provides a mechanism to move a
structured set of files system object structures (directories and/or
files) as a MIME attachment from one environment to another while
preserving common elements.",
URL="http://www.ietf.org/internet-drafts/draft-costanzo-fs-mime-00.txt"
}

@TECHREPORT{draft-costanzo-lzju90-mime,
AUTHOR="A. Costanzo",
TITLE="Definition of the {LZJU90} {MIME} Content Transfer Encoding Type",
TYPE="Internet Draft",
HOWPUBLISHED="draft-costanzo-lzju90-mime-01",
INSTITUTION="Internet Engineering Task Force",
MONTH=sep,
YEAR=1998,
NOTE="Work in progress",
ABSTRACT="This memo defines a new transfer encoding type for MIME,
namely LZJU90. LZJU90 specifies a section consisting of an encoded
binary or text object. The encoding provides both compression and
representation in a text format.",
URL="http://www.ietf.org/internet-drafts/draft-costanzo-lzju90-mime-01.txt"
}

@TECHREPORT{draft-coulter-pmap,
AUTHOR="D. Coulter",
TITLE="Proxy Mail Address Protocol",
TYPE="Internet Draft",
HOWPUBLISHED="draft-coulter-pmap-00",
INSTITUTION="Internet Engineering Task Force",
MONTH=aug,
YEAR=1998,
NOTE="Work in progress",
ABSTRACT="This specification defines a service that manages a type of
disposable Internet mail address known as a proxy address. Proxy
addresses conform to the standard addressing scheme [RFC 822] and exist
in the same address space, but act as aliases for regular, fixed
addresses. Users may own many at a time and allocate and deallocate them
at will. Proxy addresses offer a defense against junk mail by allowing
individuals to control access to their mailboxes by creating addresses
for specific contacts or purposes. If unwanted mail arrives addressed to
a proxy, the user may delete or suspend the proxy address to remove the
intrusive sender's means of accessing the mailbox. The service also
defines a distinct command-response interface for use between client and
server implementations to conduct management chores.",
URL="http://www.ietf.org/internet-drafts/draft-coulter-pmap-00.txt"
}

@TECHREPORT{draft-court-dynfeed,
AUTHOR="B. Court",
TITLE="An {NNTP} Extension for Dynamic Feed Adjustment",
TYPE="Internet Draft",
HOWPUBLISHED="draft-court-dynfeed-01",
INSTITUTION="Internet Engineering Task Force",
MONTH=aug,
YEAR=1998,
NOTE="Work in progress",
ABSTRACT="This document describes an extension to the Network News
Transport Protocol[RFC977] that allows NNTP peers to dynamically adjust
their criteria for sending network news articles to one another. This
extension provides only for the addition of 'negative' criteria, i.e.,
criteria for articles that are not to be sent. It is believed that a
more comprehensive scheme allowing for 'positive' criteria, while
desirable, would not receive wide deployment in the Internet because of
concerns about security and intellectual property. The extension
described in this document does not present these concerns and allows
for gains in network efficiency.",
URL="http://www.ietf.org/internet-drafts/draft-court-dynfeed-01.txt"
}

@TECHREPORT{draft-cpsr-one-net,
AUTHOR="N. Borenstein and H. Hochheiser and A. Oram",
TITLE="One Planet, One Net: Principles for the Internet Era",
TYPE="Internet Draft",
HOWPUBLISHED="draft-cpsr-one-net-01",
INSTITUTION="Internet Engineering Task Force",
MONTH=apr,
YEAR=1998,
NOTE="Work in progress",
ABSTRACT="This document presents a suggested set of basic principles
that the authors believe should underlie all future work in the area of
Internet governance. The purpose of this document is to work towards as
broad a consensus as possible, in the diverse Internet community, about
principles that should inform the way the Internet is administered for
the benefit of all humanity. The principles have been drafted under the
auspices of Computer Professionals for Social Responsibility, with
several iterations internal to that organization. However, they are
still very much seen as a work in progress. Comments are solicited from
all interested parties. Future versions will be refined based on these
comments and published as future Internet-Drafts, with a goal of
publication of a finalized version of the declaration as an Internet RFC
in summer, 1998. All comments on this document are welcome; please send
them to onenet-comments(at)cpsr.org. Open discussion of this document is
encouraged on the onenet-discuss list, which is archived at
http://www.findmail.com/listsaver/onenet- discuss.",
URL="http://www.ietf.org/internet-drafts/draft-cpsr-one-net-01.txt"
}

@TECHREPORT{draft-crispin-imap-sort,
AUTHOR="M. Crispin",
TITLE="{INTERNET} {MESSAGE} {ACCESS} {PROTOCOL} - {SORT} {EXTENSION}",
TYPE="Internet Draft",
HOWPUBLISHED="draft-crispin-imap-sort-00",
INSTITUTION="Internet Engineering Task Force",
MONTH=feb,
YEAR=1998,
NOTE="Work in progress",
ABSTRACT="This document describes the server-based sorting extension to
the IMAP4rev1 protocol. This extension provides substantial performance
improvements for IMAP clients which offer sorted views.",
URL="http://www.ietf.org/internet-drafts/draft-crispin-imap-sort-00.txt"
}

@TECHREPORT{draft-crispin-srs,
AUTHOR="K. Crispin",
TITLE="Shared Registry System Protocol {(SRSP)}",
TYPE="Internet Draft",
HOWPUBLISHED="draft-crispin-srs-00",
INSTITUTION="Internet Engineering Task Force",
MONTH=nov,
YEAR=1998,
NOTE="Work in progress",
ABSTRACT="This specification describes a protocol for a Shared Registry
System (SRS) that allows multiple registrars to register domain names
within a single Top Level Domain (TLD). The protocol is high-level,
text-based, and can be used over many underlying transport mechanisms,
including email. The semantic content of the protocol is expressed as a
set of keyword-value pairs; the semantics and structure of this content
is, in this document, loosely described as the 'payload'. The protocol
described herein is essentially identical to the SRS version 1.5
protocol, specified by the CORE SRS RFP and developed by Curt Meyer of
Emergent Corporation.",
URL="http://www.ietf.org/internet-drafts/draft-crispin-srs-00.txt"
}

@TECHREPORT{draft-cromwell-navdec-media-req,
AUTHOR="D. Cromwell and M. Durling",
TITLE="Requirements For Control Of A Media Services Function",
TYPE="Internet Draft",
HOWPUBLISHED="draft-cromwell-navdec-media-req-00",
INSTITUTION="Internet Engineering Task Force",
MONTH=nov,
YEAR=1998,
NOTE="Work in progress",
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.",
URL="http://www.ietf.org/internet-drafts/draft-cromwell-navdec-media-req-00.txt"
}

@TECHREPORT{draft-cromwell-navdec-mgcp-audio-pkg,
AUTHOR="D. Cromwell",
TITLE="A Syntax For The {MGCP} Audio Package",
TYPE="Internet Draft",
HOWPUBLISHED="draft-cromwell-navdec-mgcp-audio-pkg-00",
INSTITUTION="Internet Engineering Task Force",
MONTH=nov,
YEAR=1998,
NOTE="Work in progress",
ABSTRACT="The MGCP protocol describes a protocol for controlling a VOIP
(Voice Over IP) gateway from an external call agent. The protocol
defines a number of event packages, each of which defines a group of
events supporting a particular type of gateway functionality. For
example, there is a package for MF trunks, one for DTMF, and one for
RTP. A gateway may support one or more packages depending on the
functional- ity it provides. A Residential Gateway might support the
Generic Media, DTMF, Line, and RTP packages while an MF Trunk Gateway
could support the Generic Media, MF, DTMF, MF Trunk, and RTP packages.
This document proposes a set of IVR-related events that constitute an
MGCP Announcement Package for use by an Announcement Server Gateway.
This event package provides support for the standard IVR operations of
Play Announcement, Play Collect, and Play Record. It supports direct
references to simple audio as well as indirect references to simple and
complex audio. It also provides multi-language audio vari- ables,
control of audio interruptibility, digit buffer control, spe- cial key
sequences, and support for reprompting during data collec- tion.",
URL="http://www.ietf.org/internet-drafts/draft-cromwell-navdec-mgcp-audio-pkg-00.txt"
}

@TECHREPORT{draft-crowcroft-rmfp,
AUTHOR="Jon Crowcroft and H. Fuchs and T. Turletti and A. Ghosh and Z. Wang and L.
Vicisano and Christophe Diot",
TITLE="{RMFP:} A Reliable Multicast Framing Protocol",
TYPE="Internet Draft",
HOWPUBLISHED="draft-crowcroft-rmfp-02",
INSTITUTION="Internet Engineering Task Force",
MONTH=mar,
YEAR=1998,
NOTE="Work in progress",
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].",
URL="http://www.ietf.org/internet-drafts/draft-crowcroft-rmfp-02.txt"
}

@TECHREPORT{draft-cucchiara-mpls-ldp-mib,
AUTHOR="J. Cucchiara and J. Luciani and H. Sjostrand",
TITLE="Definitions of Managed Objects for the Multiprotocol Label Switching, Label
Distribution Protocol {(LDP)}",
TYPE="Internet Draft",
HOWPUBLISHED="draft-cucchiara-mpls-ldp-mib-00",
INSTITUTION="Internet Engineering Task Force",
MONTH=aug,
YEAR=1998,
NOTE="Work in progress",
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.",
URL="http://www.ietf.org/internet-drafts/draft-cucchiara-mpls-ldp-mib-00.txt"
}

@TECHREPORT{draft-cuervo-navdec-mg-arch,
AUTHOR="F. Cuervo and G. Gibbs",
TITLE="Media Gateway Architecture: A Functional Model of the Media Gateway",
TYPE="Internet Draft",
HOWPUBLISHED="draft-cuervo-navdec-mg-arch-00",
INSTITUTION="Internet Engineering Task Force",
MONTH=nov,
YEAR=1998,
NOTE="Work in progress",
ABSTRACT="This document presents a functional model of a Media Gateway.
The model extends the functional model of the base architecture
draft[1]. The model identifies the functions that the MG may expose to
other functions of the architecture, namely, the Media Gateway
Controller and the Signalling Gateway [1]. The objective of the model is
to identify completeness of the protocol functions, flexibility to
handle the optionality of functions and ensure that the protocol is not
biased towards a particular implementation of the Media Gateway.",
URL="http://www.ietf.org/internet-drafts/draft-cuervo-navdec-mg-arch-00.txt"
}

@TECHREPORT{draft-daniele-iana-addr-mib,
AUTHOR="M. Daniele",
TITLE="{IANA} Address {MIB}",
TYPE="Internet Draft",
HOWPUBLISHED="draft-daniele-iana-addr-mib-00",
INSTITUTION="Internet Engineering Task Force",
MONTH=sep,
YEAR=1998,
NOTE="Work in progress",
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.",
URL="http://www.ietf.org/internet-drafts/draft-daniele-iana-addr-mib-00.txt"
}

@TECHREPORT{draft-davie-mpls-atm,
AUTHOR="B. Davie and J. Lawrence and K. McCloghrie and Y. Rekhter and E. Rosen and
G. Swallow and P. Doolan",
TITLE="Use of Label Switching With {ATM}",
TYPE="Internet Draft",
HOWPUBLISHED="draft-davie-mpls-atm-01",
INSTITUTION="Internet Engineering Task Force",
MONTH=jul,
YEAR=1998,
NOTE="Work in progress",
ABSTRACT="A Multi Protocol Label Switching architecture is described in
[1]. Label Switching enables the use of ATM Switches as Label Switching
Routers. The ATM Switches run network layer routing algorithms (such as
OSPF, IS-IS, etc.), and their data forwarding is based on the results of
these routing algorithms. No ATM-specific routing or addressing is
needed. This document describes how the label switching architecture is
applied to ATM switches.",
URL="http://www.ietf.org/internet-drafts/draft-davie-mpls-atm-01.txt"
}

@TECHREPORT{draft-davis-dasl-requirements,
AUTHOR="J. Davis and S. Reddy and J. Slein",
TITLE="Requirements for {DAV} Searching and Locating",
TYPE="Internet Draft",
HOWPUBLISHED="draft-davis-dasl-requirements-00",
INSTITUTION="Internet Engineering Task Force",
MONTH=sep,
YEAR=1998,
NOTE="Work in progress",
ABSTRACT="The Distributed Authoring and Versioning protocol [WEBDAV]
defines simple mechanisms to assign and retrieve values for properties.
This document presents requirements for a WebDAV extension to support
efficient searching for resources based on WEBDAV properties and
content. These requirements are intended to be the basis for the DAV
Searching and Location (DASL) protocol.",
URL="http://www.ietf.org/internet-drafts/draft-davis-dasl-requirements-00.txt"
}

@TECHREPORT{draft-davis-xdr-ext,
AUTHOR="T. Davis",
TITLE="{XDR} Extensions",
TYPE="Internet Draft",
HOWPUBLISHED="draft-davis-xdr-ext-01",
INSTITUTION="Internet Engineering Task Force",
MONTH=sep,
YEAR=1998,
NOTE="Work in progress",
ABSTRACT="This document describes extensions to the External Data
Representation Standard (XDR) protocol as it is currently deployed and
accepted.",
URL="http://www.ietf.org/internet-drafts/draft-davis-xdr-ext-01.txt"
}

@TECHREPORT{draft-dawson-ical-fpi,
AUTHOR="P. Hoffman and F. Dawson",
TITLE="iCalendar v2.0 Formal Public Identifier",
TYPE="Internet Draft",
HOWPUBLISHED="draft-dawson-ical-fpi-00",
INSTITUTION="Internet Engineering Task Force",
MONTH=jul,
YEAR=1998,
NOTE="Work in progress",
ABSTRACT="The IETF has defined a standard format for exchanging
calendaring and scheduling data, called iCalendar. This format is useful
for exchange of personal calendar data across the Internet, as well as
in non-Internet environments.",
URL="http://www.ietf.org/internet-drafts/draft-dawson-ical-fpi-00.txt"
}

@TECHREPORT{draft-dawson-ical-xml-dtd,
AUTHOR="F. Dawson",
TITLE="The iCalendar {XML} {DTD}",
TYPE="Internet Draft",
HOWPUBLISHED="draft-dawson-ical-xml-dtd-01",
INSTITUTION="Internet Engineering Task Force",
MONTH=dec,
YEAR=1998,
NOTE="Work in progress",
ABSTRACT="This memo defines a [XML] Document Type Definition (DTD) that
corresponds to the iCalendar, calendaring and scheduling core object
format defined by [RFC2445]. This DTD provides equivalent functionality
to the standard format defined by [RFC2445]. Documents structured in
accordance with this DTD may also be know as 'XML iCalendar' documents.
The mailing list for discussion of this memo is 'ietf-
calendar(at)imc.org'. Send an email to ' ietf-calendar-request(at)imc.org'
with the message 'SUBSCRIBE' to add your email address to this mailing
list. Send an email to ' ietf-vcard-xml-request(at)imc.org' with the
message 'UNSUBSCRIBE' to remove your email address from this mailing
list. 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].",
URL="ftp://www.ietf.org/internet-drafts/draft-dawson-ical-xml-dtd-01.txt"
}

@TECHREPORT{draft-day-envy,
AUTHOR="M. Day",
TITLE="{''HTTP} Envy'' and Presence Information Protocols",
TYPE="Internet Draft",
HOWPUBLISHED="draft-day-envy-00",
INSTITUTION="Internet Engineering Task Force",
MONTH=mar,
YEAR=1998,
NOTE="Work in progress",
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.",
URL="http://www.ietf.org/internet-drafts/draft-day-envy-00.txt"
}

@TECHREPORT{draft-day-msd,
AUTHOR="M. Day",
TITLE="Matrix Model for Selective Dissemination",
TYPE="Internet Draft",
HOWPUBLISHED="draft-day-msd-00",
INSTITUTION="Internet Engineering Task Force",
MONTH=jan,
YEAR=1998,
NOTE="Work in progress",
ABSTRACT="The year-2000 problem (Y2K problem) is of increasing interest.
Little has been said about the relationship of Y2K to synchronous
groupware. We describe a matrix model of selective dissemination of
information to viewers of that information. The model is suitable for
some forms of synchronous groupware.",
URL="http://www.ietf.org/internet-drafts/draft-day-msd-00.txt"
}

@TECHREPORT{draft-day-rpim,
AUTHOR="M. Day",
TITLE="Requirements for Presence and Instant Messaging",
TYPE="Internet Draft",
HOWPUBLISHED="draft-day-rpim-00",
INSTITUTION="Internet Engineering Task Force",
MONTH=mar,
YEAR=1998,
NOTE="Work in progress",
ABSTRACT="This document is an alternative approach to defining the
requirements for a presence information protocol. It may be usefully
compared and contrasted with ''Presence Information Protocol
Requirements'' by Lisa Dusseault, draft-dusseault-pipr-00.txt. Although
worthy in many respects, that document includes numerous desiderata,
design considerations, and implementation concerns. This document
attempts to define only requirements, and a minimal set of requirements
at that. In addition, this document treats ''presence'' and ''instant
messaging'' as distinct entities for the purpose of defining
requirements. We leave open the possibility of a single protocol
fulfilling both sets of requirements, without requiring it.",
URL="http://www.ietf.org/internet-drafts/draft-day-rpim-00.txt"
}

@TECHREPORT{draft-day-sgap,
AUTHOR="M. Day",
TITLE="Simple General Awareness Protocol {(SGAP)} Revision 1",
TYPE="Internet Draft",
HOWPUBLISHED="draft-day-sgap-01",
INSTITUTION="Internet Engineering Task Force",
MONTH=mar,
YEAR=1998,
NOTE="Work in progress",
ABSTRACT="The Simple General Awareness Protocol (SGAP) provides
notifications of changes to small data items. The changes are
selectively made available to a large collection of viewers. This
facility is most useful for a class of applications variously called
people locators, colleague-awareness tools, people browsers, or ''buddy
lists''.",
URL="http://www.ietf.org/internet-drafts/draft-day-sgap-01.txt"
}

@TECHREPORT{draft-debry-http-usepost,
AUTHOR="T. Hasting and F. Wright and H. Lewis and S. Isaacson and R. deBry and C.
Kugler and S. Gebert",
TITLE="The Use of Post: A Response to draft-cohen-http-postal-00.txt",
TYPE="Internet Draft",
HOWPUBLISHED="draft-debry-http-usepost-00",
INSTITUTION="Internet Engineering Task Force",
MONTH=feb,
YEAR=1998,
NOTE="Work in progress",
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.",
URL="http://www.ietf.org/internet-drafts/draft-debry-http-usepost-00.txt"
}

@TECHREPORT{draft-degermark-ipv6-hc,
AUTHOR="M. Degermark and B. Nordgren and S. Pink",
TITLE="{IP} Header Compression",
TYPE="Internet Draft",
HOWPUBLISHED="draft-degermark-ipv6-hc-08",
INSTITUTION="Internet Engineering Task Force",
MONTH=dec,
YEAR=1998,
NOTE="Work in progress",
ABSTRACT="This document describes how to compress multiple IP headers
and TCP and UDP headers per-hop over point-to-point links. The methods
can be applied to of IPv6 base and extension headers, IPv4 headers, TCP
and UDP headers, and encapsulated IPv6 and IPv4 headers. Headers of
typical UDP or TCP packets can be compressed down to 4-7 octets
including the 2 octet UDP or TCP checksum. This largely removes the
negative impact of large IP headers and allows efficient use of
bandwidth on low- and medium-speed links. The compression algorithms are
specifically designed to work well over links with nontrivial
packet-loss rates. Several wireless and modem technologies result in
such links.",
URL="ftp://www.ietf.org/internet-drafts/draft-degermark-ipv6-hc-08.txt"
}

@TECHREPORT{draft-donovan-sip-gw-client,
AUTHOR="S. Donovan and M. Cannon",
TITLE="A Functional Description of a {SIP-PSTN} Gateway",
TYPE="Internet Draft",
HOWPUBLISHED="draft-donovan-sip-gw-client-00",
INSTITUTION="Internet Engineering Task Force",
MONTH=nov,
YEAR=1998,
NOTE="Work in progress",
ABSTRACT="This document describes a functional model of a gateway
between the Public Switched Telephony Network (PSTN) and a SIP-based IP
network providing telephony service. In this document, the SIP-based IP
network will be referred to as Telephony over IP Service (TIPS). The
primary function of the gateway is to handle connections involving one
or more PSTN phones (i.e.; PSTN black phones) as if those PSTN phones
are SIP clients. The goal of this approach is to ensure that SIP-based
TIPS service logic applies to both native Internet- based SIP clients
and PSTN phones without modification.",
URL="http://www.ietf.org/internet-drafts/draft-donovan-sip-gw-client-00.txt"
}

@TECHREPORT{draft-doria-gsmp-applicability,
AUTHOR="A. Doria and T. Worster and K. Sundell",
TITLE="Applicability of {GSMP} as an {IETF} Protocol",
TYPE="Internet Draft",
HOWPUBLISHED="draft-doria-gsmp-applicability-00",
INSTITUTION="Internet Engineering Task Force",
MONTH=oct,
YEAR=1998,
NOTE="Work in progress",
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",
URL="http://www.ietf.org/internet-drafts/draft-doria-gsmp-applicability-00.txt"
}

@TECHREPORT{draft-dovrolis-cbsd,
AUTHOR="C. Dvorolis",
TITLE="{Class-Based} Service Differentiation",
TYPE="Internet Draft",
HOWPUBLISHED="draft-dovrolis-cbsd-00",
INSTITUTION="Internet Engineering Task Force",
MONTH=jun,
YEAR=1998,
NOTE="Work in progress",
ABSTRACT="This document describes the Class-Based Service
Differentiation (CBSD) architecture and it proposes a set of
Per-Hop-Behaviors that can be used for implementing it. According to
CBSD, the network traffic is mapped to a set of classes. The
differentiating factor between traffic classes is the relative
forwarding quality in a DS capable router. The Class PHBs have quite
similar semantics with the Precedence PHBs, recently proposed by Baker
et.al. in [PREC], but an attempt is made here to define them in a more
general manner, decoupling them from specific implementation
possibilities. There is also a semantical overlap between the Expedited
Forwarding PHB of [DSFIELD] and the highest Class PHB. Consequently, the
Diffserv working group may want to combine these three PHB proposals in
a single one, minimizing the number of DS Field bits used.",
URL="http://www.ietf.org/internet-drafts/draft-dovrolis-cbsd-00.txt"
}

@TECHREPORT{draft-dube-route-reflection-harmful,
AUTHOR="R. Dube and J. Scudder",
TITLE="Route Reflection Considered Harmful",
TYPE="Internet Draft",
HOWPUBLISHED="draft-dube-route-reflection-harmful-00",
INSTITUTION="Internet Engineering Task Force",
MONTH=nov,
YEAR=1998,
NOTE="Work in progress",
ABSTRACT="Route reflection as defined by [2] is a popular way of
reducing the full-mesh IBGP peering required by routers running the
Border Gateway Protocol [1]. There are cases where a topology built
using route reflectors produces persistent loops or does not produce the
same results as what one would expect with a full IBGP mesh. This
document describes these problems.",
URL="http://www.ietf.org/internet-drafts/draft-dube-route-reflection-harmful-00.txt"
}

@TECHREPORT{draft-duffield-vpn-qos-framework,
AUTHOR="N. Duffield and P. Goyal and A. Greenberg and P. Mishra and K. Ramakrishnan",
TITLE="A Performance Oriented Service Interface for Virtual Private Networks",
TYPE="Internet Draft",
HOWPUBLISHED="draft-duffield-vpn-qos-framework-00",
INSTITUTION="Internet Engineering Task Force",
MONTH=nov,
YEAR=1998,
NOTE="Work in progress",
ABSTRACT="This document presents a quality of service (QoS) framework
for IP based virtual private networks (VPNs). For IP based VPNs to
provide a service comparable to private line networks it has to provide
a number of features including closed user groups, security and
performance guarantees. This document focuses primarily on the issue of
performance, and provide a QoS framework which is applicable to various
VPN solution that have been proposed.",
URL="http://www.ietf.org/internet-drafts/draft-duffield-vpn-qos-framework-00.txt"
}

@TECHREPORT{draft-dugan-ipdc-connection,
AUTHOR="A. Dugan",
TITLE="{IPDC} Connection Control Protocol",
TYPE="Internet Draft",
HOWPUBLISHED="draft-dugan-ipdc-connection-00",
INSTITUTION="Internet Engineering Task Force",
MONTH=aug,
YEAR=1998,
NOTE="Work in progress",
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.",
URL="http://www.ietf.org/internet-drafts/draft-dugan-ipdc-connection-00.txt"
}

@TECHREPORT{draft-dun-calsch-locate,
AUTHOR="A. Dun and D. Hennessy and F. Jr.",
TITLE="Calendar attributes for vCard and {LDAP}",
TYPE="Internet Draft",
HOWPUBLISHED="draft-dun-calsch-locate-02",
INSTITUTION="Internet Engineering Task Force",
MONTH=mar,
YEAR=1998,
NOTE="Work in progress",
ABSTRACT="When scheduling an event, it is a prerequisite that an
organizer has the calendar address of each attendee that will be invited
to the event. Additionally, access to an attendee's current ''busy
time'' provides an a priori indication of whether the attendee will be
free to participate in the event. In order to meet these challenges, a
calendar user agent (CUA) needs a mechanism to locate (URL) individual
user's calendar and free/busy time. This draft defines three mechanisms
for obtaining a URL to a user's calendar and free/busy time. These
include: - Manual transfer of the information; - Personal data exchange
using the vCard format; and - Directory lookup using the LDAP protocol.",
URL="http://www.ietf.org/internet-drafts/draft-dun-calsch-locate-02.txt"
}

@TECHREPORT{draft-dusseault-pipr,
AUTHOR="L. Dusseault and M. Calsyn",
TITLE="Presence Information Protocol Requirements",
TYPE="Internet Draft",
HOWPUBLISHED="draft-dusseault-pipr-00",
INSTITUTION="Internet Engineering Task Force",
MONTH=feb,
YEAR=1998,
NOTE="Work in progress",
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(at)iastate.edu, which may be
joined by sending a message with subject ''subscribe'' to rvp-
request(at)iastate.edu. Archives of past messages are available. Send the
single word \021help\022 to rvp-request(at)iastate.edu for more
informatio",
URL="http://www.ietf.org/internet-drafts/draft-dusseault-pipr-00.txt"
}

@TECHREPORT{draft-dusseault-rvp-addr,
AUTHOR="L. Dusseault",
TITLE="Addressing and Location for {RVP}",
TYPE="Internet Draft",
HOWPUBLISHED="draft-dusseault-rvp-addr-00",
INSTITUTION="Internet Engineering Task Force",
MONTH=mar,
YEAR=1998,
NOTE="Work in progress",
ABSTRACT="A core part of a presence and instant messaging protocol, such
as RVP [7], must be the ability to find users online. This draft defines
several aspects of finding a user online: - Schema of RVP URL - How to
find a user\022s RVP address (URL) - How to find a RVP server The
problem may be generalized to finding a non-user object online. In this
draft, the client is the process which is searching for a RVP object.
This can be a RVP server acting as a client or on behalf of a user. The
server is the process which is responsible for answering queries and
receiving messages for a RVP object. A RVP client may sometimes act as
its own server.",
URL="http://www.ietf.org/internet-drafts/draft-dusseault-rvp-addr-00.txt"
}

@TECHREPORT{draft-dusseault-rvp-schema,
AUTHOR="L. Dusseault and J. Bone",
TITLE="{RVP} Schemas",
TYPE="Internet Draft",
HOWPUBLISHED="draft-dusseault-rvp-schema-00",
INSTITUTION="Internet Engineering Task Force",
MONTH=mar,
YEAR=1998,
NOTE="Work in progress",
ABSTRACT="The RVP protocol [2] can be used to query properties of
objects, subscribe to certain kinds of events, and send instant messages
to objects. These objects are often users, but there are other classes
of objects as well. A schema needs to be defined which applies to all
kinds of RVP objects, as well as more detailed schemas for the most
commonly used objects, users and groups. The required properties for all
RVP objects include common name (Cn), schema type and access control
list. The required properties for a user object, which represents a
single human user of the system, include status, status message, email
address and directory server address. The required properties for a
group object, which represents a list of objects which may be messaged
all at once by messaging this group, include member- count and owner.",
URL="http://www.ietf.org/internet-drafts/draft-dusseault-rvp-schema-00.txt"
}

@TECHREPORT{draft-earhart-ap-spec,
AUTHOR="R. Earhart",
TITLE="Access Protocol",
TYPE="Internet Draft",
HOWPUBLISHED="draft-earhart-ap-spec-01",
INSTITUTION="Internet Engineering Task Force",
MONTH=jan,
YEAR=1998,
NOTE="Work in progress",
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.",
URL="http://www.ietf.org/internet-drafts/draft-earhart-ap-spec-01.txt"
}

@TECHREPORT{draft-earhart-url-pop3,
AUTHOR="R. Earhart",
TITLE="A {POP3} {URL} Interface",
TYPE="Internet Draft",
HOWPUBLISHED="draft-earhart-url-pop3-00",
INSTITUTION="Internet Engineering Task Force",
MONTH=jan,
YEAR=1998,
NOTE="Work in progress",
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.",
URL="http://www.ietf.org/internet-drafts/draft-earhart-url-pop3-00.txt"
}

@TECHREPORT{draft-eastlake-weak-ato,
AUTHOR="D. Eastlake",
TITLE="The Weak Authentication and Tracing Option",
TYPE="Internet Draft",
HOWPUBLISHED="draft-eastlake-weak-ato-03",
INSTITUTION="Internet Engineering Task Force",
MONTH=feb,
YEAR=1998,
NOTE="Work in progress",
ABSTRACT="The packet switched nature of the Internet Protocol (IP)
provides no inherent method to assure that a packet has been issued with
a source address authorized for the sender and no inherent method to
trace the actual source of a packet. These characteristics make it
difficult to take effective action concerning injurious packets which
may have originated, by accident or maliciously, virtually anywhere in
the Internet. A lightweight IP level option is proposed that provides
(1) some assurance that packet's source addresses are authorized for
their sender, and (2) limited statistical tracing information such that,
if many bad packets are logged, the path to their source will be
revealed. These features, even if not implemented throughout the
Internet, would provide significantly improved protection against packet
level abuse.",
URL="http://www.ietf.org/internet-drafts/draft-eastlake-weak-ato-03.txt"
}

@TECHREPORT{draft-eisler-nfssec,
AUTHOR="M. Eisler",
TITLE="{NFS} Version 2 and Version 3 Security Issues and the {NFS} Protocol's Use
of {RPCSEC\_GSS} and Kerberos {V5}",
TYPE="Internet Draft",
HOWPUBLISHED="draft-eisler-nfssec-02",
INSTITUTION="Internet Engineering Task Force",
MONTH=nov,
YEAR=1998,
NOTE="Work in progress",
ABSTRACT="This memorandum clarifies various security issues involving
the NFS protocol (Version 2 and Version 3 only) and then describes how
the Version 2 and Version 3 of the NFS protocol use the RPCSEC\_GSS
security flavor protocol and Kerberos V5. This memorandum is provided so
that people can write compatible implementations.",
URL="http://www.ietf.org/internet-drafts/draft-eisler-nfssec-02.txt"
}

@TECHREPORT{draft-ellesson-sla-schema,
AUTHOR="E. Ellesson and D. Verma and R. Rajan and S. Kamat",
TITLE="Schema for Service Level Administration of Differentiated Services and
Integrated Services in Networks",
TYPE="Internet Draft",
HOWPUBLISHED="draft-ellesson-sla-schema-00",
INSTITUTION="Internet Engineering Task Force",
MONTH=feb,
YEAR=1998,
NOTE="Work in progress",
ABSTRACT="This document describes the structure of a directory schema to
enable and support administration of differentiated services and/or
integrated services within and among Internet domains, intranets, and
extranets.",
URL="http://www.ietf.org/internet-drafts/draft-ellesson-sla-schema-00.txt"
}

@TECHREPORT{draft-elliott-ipdc-media,
AUTHOR="I. Elliott",
TITLE="{IPDC} Media Control Protocol",
TYPE="Internet Draft",
HOWPUBLISHED="draft-elliott-ipdc-media-00",
INSTITUTION="Internet Engineering Task Force",
MONTH=aug,
YEAR=1998,
NOTE="Work in progress",
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.",
URL="http://www.ietf.org/internet-drafts/draft-elliott-ipdc-media-00.txt"
}

@TECHREPORT{draft-ernst-msgmib,
AUTHOR="G. Jones and B. Ernst and J. Weintraub",
TITLE="Message Tracking {MIB}",
TYPE="Internet Draft",
HOWPUBLISHED="draft-ernst-msgmib-00",
INSTITUTION="Internet Engineering Task Force",
MONTH=feb,
YEAR=1998,
NOTE="Work in progress",
ABSTRACT="This document defines a message tracking Management
Information Base (MIB) for electronic messaging management. Message
tracking is the ability to find out, after the fact, the path that a
particular message took through the messaging system and the current
status of that message.",
URL="http://www.ietf.org/internet-drafts/draft-ernst-msgmib-00.txt"
}

@TECHREPORT{draft-faerber-http-content-disp,
AUTHOR="C. Faerber",
TITLE="Use of the {Content-Disposition} header with {HTTP.}",
TYPE="Internet Draft",
HOWPUBLISHED="draft-faerber-http-content-disp-00",
INSTITUTION="Internet Engineering Task Force",
MONTH=sep,
YEAR=1998,
NOTE="Work in progress",
ABSTRACT="[RFC2183] introduces a Content-Disposition header field for
Internet Mail Messages to transmit presentation information as well as a
suggested file name for saving the content to disk and the file's date
information. All of this information is missing from HTTP entities
[RFC2068]. However, there is nothing that would prevent the use of the
Content- Disposition header with this HTTP. Without being standard, the
Content-Disposition header has already been introduced by some software
products. [HTTP1.1-REV] documents this practice, based on [RFC1806].
This memo also extends the specification to cover [RFC2183] and corrects
the common abuse of the Content-Type header to cover presentation
information.",
URL="http://www.ietf.org/internet-drafts/draft-faerber-http-content-disp-00.txt"
}

@TECHREPORT{draft-farinacci-anycast-clusters,
AUTHOR="D. Farinacci and Lin Wei and J. Meylor",
TITLE="Use of Anycast Clusters for {Inter-Domain} Multicast Routing",
TYPE="Internet Draft",
HOWPUBLISHED="draft-farinacci-anycast-clusters-01",
INSTITUTION="Internet Engineering Task Force",
MONTH=mar,
YEAR=1998,
NOTE="Work in progress",
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.",
URL="http://www.ietf.org/internet-drafts/draft-farinacci-anycast-clusters-01.txt"
}

@TECHREPORT{draft-farinacci-msdp,
AUTHOR="D. Farinacci and P. Lothberg and Y. Rekhter and H. Kilmer and J. Hall",
TITLE="Multicast Source Discovery Protocol {(MSDP)}",
TYPE="Internet Draft",
HOWPUBLISHED="draft-farinacci-msdp-00",
INSTITUTION="Internet Engineering Task Force",
MONTH=jun,
YEAR=1998,
NOTE="Work in progress",
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.",
URL="http://www.ietf.org/internet-drafts/draft-farinacci-msdp-00.txt"
}

@TECHREPORT{draft-farinacci-multicast-label-part,
AUTHOR="D. Farinacci and Y. Rekhter",
TITLE="Partitioning Label Space among Multicast Routers on a Common Subnet",
TYPE="Internet Draft",
HOWPUBLISHED="draft-farinacci-multicast-label-part-00",
INSTITUTION="Internet Engineering Task Force",
MONTH=nov,
YEAR=1998,
NOTE="Work in progress",
ABSTRACT="There are 3 major functions that must be performed to achieve
multicast Label Switching. 1) Label Allocation, which requires each
multicast Label Switching Router (LSR) to have a label value range that
it uses. 2) Label Binding, using the labels allocated, a LSR must assign
them to multicast routes. 3) Label Binding Distribution, after binding
label values to routes, they must be distributed to other LSRs so they
all forward on a common and consistent distribution tree. In this
document we present how labels are allocated uniquely across multicast
capable LSRs on a LAN and point-to-point IP subnets.",
URL="http://www.ietf.org/internet-drafts/draft-farinacci-multicast-label-part-00.txt"
}

@TECHREPORT{draft-farinacci-multicast-tagsw,
AUTHOR="D. Farinacci and Y. Rekhter",
TITLE="Multicast Tag Binding and Distribution using {PIM}",
TYPE="Internet Draft",
HOWPUBLISHED="draft-farinacci-multicast-tagsw-01",
INSTITUTION="Internet Engineering Task Force",
MONTH=nov,
YEAR=1998,
NOTE="Work in progress",
ABSTRACT="This document describes a method for advertising labels for
multicast flows. It strives to use downstream label assignment to be
consistent with unicast label distribution. This proposal is media- type
independent. Therefore, it works for multi-access/multicast capable
LANs, point-to-point links, and NBMA networks.",
URL="http://www.ietf.org/internet-drafts/draft-farinacci-multicast-tagsw-01.txt"
}

@TECHREPORT{draft-feng-dp-services,
AUTHOR="W. Feng",
TITLE="Drop Preference Services",
TYPE="Internet Draft",
HOWPUBLISHED="draft-feng-dp-services-00",
INSTITUTION="Internet Engineering Task Force",
MONTH=jun,
YEAR=1998,
NOTE="Work in progress",
ABSTRACT="Drop preference has been proposed as a possible means for
providing differentiated services in the Internet. Used as a parameter
in a PHB group, drop preference can provide weighted bandwidth sharing
amongst flows and flow aggregates of a PHB group. This memo documents a
number of services which can be implemented using either a single drop
preference PHB setting or multiple drop preference settings.",
URL="http://www.ietf.org/internet-drafts/draft-feng-dp-services-00.txt"
}

@TECHREPORT{draft-ferguson-delay-drop,
AUTHOR="P. Ferguson",
TITLE="Simple Differential Services: {IP} {TOS} and Precedence, Delay Indication,
and Drop Preference",
TYPE="Internet Draft",
HOWPUBLISHED="draft-ferguson-delay-drop-02",
INSTITUTION="Internet Engineering Task Force",
MONTH=mar,
YEAR=1998,
NOTE="Work in progress",
ABSTRACT="Recent opinions and sentiments expressed in the Internet
Service Provider (ISP) community, as well as the Internet community
at-large, have voiced concern over the applicability and scalability of
RSVP and the Integrated Service model in the global Internet
infrastructure. Convincing arguments have been made for a differential
services model which offers packet delivery services better than
traditional best effort, especially in the face of congestion, yet not
as resource intensive as RSVP. As a result, the Differentiated Service
(diffserv) working group in the IETF has been examining methods to
provide simpler, less resource intensive methods of offering
differentiated services. This draft provides a practical method to use
bit values expressed in the IP Type or Service (TOS) and IP precedence
subfields of the TOS byte in the IP packet header for delay indication
and packet drop preference, respectively.",
URL="http://www.ietf.org/internet-drafts/draft-ferguson-delay-drop-02.txt"
}

@TECHREPORT{draft-fhns-rsvp-support-in-mipv6,
AUTHOR="G. Fankhauser and S. Hadjiefthymiades and N. Nikaein and L. Stacey",
TITLE="{RSVP} Support for Mobile {IP} Version 6 in Wireless Environments",
TYPE="Internet Draft",
HOWPUBLISHED="draft-fhns-rsvp-support-in-mipv6-00",
INSTITUTION="Internet Engineering Task Force",
MONTH=nov,
YEAR=1998,
NOTE="Work in progress",
ABSTRACT="This draft describes a specific problem encountered when using
RSVP (Resource Reservation Protocol) over optimised routes in MIPv6
(Mobile IP Version 6). The address translation in the MIP's binding
cache creates a mismatch between the flow-id of the packets sent from
correspondent node to mobile node and the flow-id signalled by RSVP. We
discuss several solutions to this problem: (1) By modifying RSVP at
mobile and correspondent nodes to become aware of MIPv6 addressing, we
provide a simple repair that allows RSVP flows to be established
between the fixed network and mobiles; (2a) By adding optional objects
to RSVP messages, a performance enhancement is pro- posed to make
handovers smooth and seamless; (2b) A different tech- nique with the
same goal is called flow extension and it provides flows with fixed
flow-ids from the correspondent node into the wireless access network
at the expense of forwarding traffic inside the access network, whenever
the mobile node moves. We conclude that the minimal solution (1) is a
requirement in order to make MIPv6 and RSVP interoperable; our favored
approach requires only minor changes to the correspondent and mobile
node's RSVP and MIP specification. However, for well performing and
uninterrupted operation we strongly recommend one of the solutions (2a
or 2b) that support fast re-establishment or preservation of resource
reserva- tions when mobile nodes move.",
URL="http://www.ietf.org/internet-drafts/draft-fhns-rsvp-support-in-mipv6-00.txt"
}

@TECHREPORT{draft-finlayson-mafp,
AUTHOR="R. Finlayson",
TITLE="The Multicast Attribute Framing Protocol",
TYPE="Internet Draft",
HOWPUBLISHED="draft-finlayson-mafp-02",
INSTITUTION="Internet Engineering Task Force",
MONTH=jan,
YEAR=1998,
NOTE="Work in progress",
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.",
URL="http://www.ietf.org/internet-drafts/draft-finlayson-mafp-02.txt"
}

@TECHREPORT{draft-finlayson-malloc-api,
AUTHOR="R. Finlayson",
TITLE="An Abstract {API} for Multicast Address Allocation",
TYPE="Internet Draft",
HOWPUBLISHED="draft-finlayson-malloc-api-00",
INSTITUTION="Internet Engineering Task Force",
MONTH=mar,
YEAR=1998,
NOTE="Work in progress",
ABSTRACT="This document describes the ''abstract service interface'' for
the dynamic multicast address allocation service, as seen by
applications. While it does not describe a concrete API (i.e., for a
specific programming language), it describes - in abstract terms - the
semantics of this service, including the guarantees that it makes to
applications. Additional documents (not necessarily products of the
IETF) would describe concrete APIs for this service.",
URL="http://www.ietf.org/internet-drafts/draft-finlayson-malloc-api-00.txt"
}

@TECHREPORT{draft-finlayson-mcast-firewall,
AUTHOR="R. Finlayson",
TITLE="{IP} Multicast and Firewalls",
TYPE="Internet Draft",
HOWPUBLISHED="draft-finlayson-mcast-firewall-00",
INSTITUTION="Internet Engineering Task Force",
MONTH=mar,
YEAR=1998,
NOTE="Work in progress",
ABSTRACT="Many organizations use a firewall computer that acts as a
security gateway between the public Internet and their private, internal
'intranet'. In this document, we discuss the issues surrounding the
traversal of IP multicast traffic across a firewall, and describe
possible ways in which a firewall can implement and control this
traversal. We also explain why some firewall mechanisms - such as SOCKS
- that were designed specifically for unicast traffic, are less
appropriate for multicast.",
URL="http://www.ietf.org/internet-drafts/draft-finlayson-mcast-firewall-00.txt"
}

@TECHREPORT{draft-finseth-eid-url-scheme,
AUTHOR="C. Finseth",
TITLE="The 'eid' {URL} Scheme",
TYPE="Internet Draft",
HOWPUBLISHED="draft-finseth-eid-url-scheme-00",
INSTITUTION="Internet Engineering Task Force",
MONTH=nov,
YEAR=1998,
NOTE="Work in progress",
ABSTRACT="This document defines a new URL scheme, 'eid'. This scheme
provides a mechanism by which the local application can reference data
that has been obtained by other, non-URL scheme means. The scheme is
intended to provide a general escape mechanism to allow access to
information for applications that are too specialized to justify their
own schemas.",
URL="http://www.ietf.org/internet-drafts/draft-finseth-eid-url-scheme-00.txt"
}

@TECHREPORT{draft-firoiu-diffserv-af-amend,
AUTHOR="V. Firoiu and A. Casati",
TITLE="Amendments to the Assured Forwarding {PHB} Group",
TYPE="Internet Draft",
HOWPUBLISHED="draft-firoiu-diffserv-af-amend-00",
INSTITUTION="Internet Engineering Task Force",
MONTH=nov,
YEAR=1998,
NOTE="Work in progress",
ABSTRACT="This note was motivated by the ongoing discussion in the
Differentiated Services Working Group regarding the definition of the
Assured Forwarding (AF) Per-Hop Behavior (PHB) Group. We consider two
issues with the current proposal for AF PHB Group in [Heinanen]: the
recommendation for AF discard mechanism, and the definition of AF
classes. We discuss the implications of the definitions and
recommendations that have raised comments and propose alternative texts.",
URL="http://www.ietf.org/internet-drafts/draft-firoiu-diffserv-af-amend-00.txt"
}

@TECHREPORT{draft-fleischman-asf,
AUTHOR="E. Fleischman",
TITLE="Advanced Streaming Format {(ASF)} Specification",
TYPE="Internet Draft",
HOWPUBLISHED="draft-fleischman-asf-01",
INSTITUTION="Internet Engineering Task Force",
MONTH=feb,
YEAR=1998,
NOTE="Work in progress",
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.",
URL="http://www.ietf.org/internet-drafts/draft-fleischman-asf-01.txt"
}

@TECHREPORT{draft-ford-issll-diff-svc,
AUTHOR="P. Ford and Y. Bernet",
TITLE="Integrated Services Over Differentiated Services",
TYPE="Internet Draft",
HOWPUBLISHED="draft-ford-issll-diff-svc-00",
INSTITUTION="Internet Engineering Task Force",
MONTH=mar,
YEAR=1998,
NOTE="Work in progress",
ABSTRACT="This document describes a mapping of IETF Integrated
Services[3] over Diff-Serv Networks built from network elements having
diff-serv defined Per Hop Behaviours (PHBs)[11]. In many ways, this
document should look like an ISSLL document assuming that a
differentiated service network looks like an instance of \_media\_ within
a integrated services network. It describes parameter mappings for
supporting Controlled Load [6] and Guaranteed Service [7] using the
capabilities of diff-serv networks in routers and switches. These
mappings fit within an overall Framework for Integrated and
Differentiated Services[to be submitted].",
URL="http://www.ietf.org/internet-drafts/draft-ford-issll-diff-svc-00.txt"
}

@TECHREPORT{draft-fox-vpn-id,
AUTHOR="B. Fox and B. Gleeson",
TITLE="Virtual Private Networks Identifier",
TYPE="Internet Draft",
HOWPUBLISHED="draft-fox-vpn-id-00",
INSTITUTION="Internet Engineering Task Force",
MONTH=nov,
YEAR=1998,
NOTE="Work in progress",
ABSTRACT="Virtual Private IP networks may span multiple Autonomous
Systems or Service Providers. There is a requirement for the use of a
globally unique VPN identifier in order to be able to refer to a
particular VPN (see section 6.1.1 of [1]). This document proposes a
format for a globally unique VPN identifier.",
URL="http://www.ietf.org/internet-drafts/draft-fox-vpn-id-00.txt"
}

@TECHREPORT{draft-freed-gatesec,
AUTHOR="N. Freed",
TITLE="Gateways and {MIME} Security Multiparts",
TYPE="Internet Draft",
HOWPUBLISHED="draft-freed-gatesec-03",
INSTITUTION="Internet Engineering Task Force",
MONTH=sep,
YEAR=1998,
NOTE="Work in progress",
ABSTRACT="This document examines the problems associated with use of
MIME security multiparts and gateways to non-MIME environments. A set of
requirements for gateway behavior are defined which provide facilities
necessary to properly accomodate the transfer of security multiparts
through gateways.",
URL="http://www.ietf.org/internet-drafts/draft-freed-gatesec-03.txt"
}

@TECHREPORT{draft-freeman-snmpv3-sec,
AUTHOR="S. Borbash and B. Freeman and D. Maughan",
TITLE="Simpler and More Secure Architectures for {SNMPv3}",
TYPE="Internet Draft",
HOWPUBLISHED="draft-freeman-snmpv3-sec-00.txt,.ps",
INSTITUTION="Internet Engineering Task Force",
MONTH=dec,
YEAR=1998,
NOTE="Work in progress",
ABSTRACT="This document presents simpler and more secure architectures
for SNMPv3 agents than the ones specified in RFCs 2271-2275. Agent
security is improved by restricting each module's access to data, using
the 'principle of least privilege'. The new agent architectures are
analyzed in terms of software complexity as well as security, and are
shown in some respects to be simpler.",
URL="ftp://www.ietf.org/internet-drafts/draft-freeman-snmpv3-sec-00.txt,.ps"
}

@TECHREPORT{draft-frystyk-http-mandatory,
AUTHOR="P. Leach and H. Nielsen and S. Lawrence",
TITLE="Mandatory Extensions in {HTTP}",
TYPE="Internet Draft",
HOWPUBLISHED="draft-frystyk-http-mandatory-00",
INSTITUTION="Internet Engineering Task Force",
MONTH=jan,
YEAR=1998,
NOTE="Work in progress",
ABSTRACT="HTTP is used increasingly in applications that need more
facilities than the standard version of the protocol provides, ranging
from distributed authoring, collaboration, and printing, to various
remote procedure call mechanisms. This document proposes the use of a
mandatory extension mechanism designed to address the tension between
private agreement and public specification and to accommodate extension
of applications such as HTTP clients, servers, and proxies. The proposal
associates each extension with a URI[2], and use a few new RFC 822[1]
style header fields to carry the extension identifier and related
information between the parties involved in an extended transaction.",
URL="http://www.ietf.org/internet-drafts/draft-frystyk-http-mandatory-00.txt"
}

@TECHREPORT{draft-frystyk-httpng-arch,
AUTHOR="B. Janssen and H. Nielsen and M. Spreitzer",
TITLE="{HTTP-ng} Architectural Model",
TYPE="Internet Draft",
HOWPUBLISHED="draft-frystyk-httpng-arch-00",
INSTITUTION="Internet Engineering Task Force",
MONTH=aug,
YEAR=1998,
NOTE="Work in progress",
ABSTRACT="This document defines the architectural model for a new HTTP
framework called HTTP-ng, along with a set of terms for referring to
parts of it.",
URL="http://www.ietf.org/internet-drafts/draft-frystyk-httpng-arch-00.txt"
}

@TECHREPORT{draft-frystyk-httpng-overview,
AUTHOR="H. Nielsen and M. Spreitzer and B. Janssen and J. Gettys",
TITLE="Problem Statement, Requirements, and Solution Outline",
TYPE="Internet Draft",
HOWPUBLISHED="draft-frystyk-httpng-overview-00",
INSTITUTION="Internet Engineering Task Force",
MONTH=nov,
YEAR=1998,
NOTE="Work in progress",
ABSTRACT="This document gives the authors' opinion of a rough outline of
(1) the problems to be addressed by the proposed IETF HTTP-NG Working
Group; (2) the requirements on the solution; and (3) the architecture of
the solution. It draws heavily on contributions from the whole Protocol
Design Group of the W3C HTTP-NG Activity. A suite of problems should be
addressed, summarized as observing that the World Wide Web's tremendous
success has created some strains on the Internet, its users, and its
application developers. The requirements on the solution include
modularity, extensibility, scalability, and efficiency. The proposed
solution is to factor HTTP, the Web's central protocol, into three
layers and look into performance improvements in the lower two of those
resultant layers.",
URL="http://www.ietf.org/internet-drafts/draft-frystyk-httpng-overview-00.txt"
}

@TECHREPORT{draft-fujikawa-sdp-url,
AUTHOR="K. Fujikawa",
TITLE="{SDP} {URL} Scheme",
TYPE="Internet Draft",
HOWPUBLISHED="draft-fujikawa-sdp-url-01",
INSTITUTION="Internet Engineering Task Force",
MONTH=aug,
YEAR=1998,
NOTE="Work in progress",
ABSTRACT="This document describes a format for an Session Description
Protocol Uniform Resource Locator (SDP URL) which will allow Internet
clients to have direct access to multimedia sessions.",
URL="http://www.ietf.org/internet-drafts/draft-fujikawa-sdp-url-01.txt"
}

@TECHREPORT{draft-fujisawa-ip1394-dhcp,
AUTHOR="K. Fujisawa",
TITLE="{DHCP} on {IEEE} 1394",
TYPE="Internet Draft",
HOWPUBLISHED="draft-fujisawa-ip1394-dhcp-00",
INSTITUTION="Internet Engineering Task Force",
MONTH=may,
YEAR=1998,
NOTE="Work in progress",
ABSTRACT="IEEE Std 1394-1995 is a standard for a High Performance Serial
Bus. Since 1394 uses different link-layer addressing method than
conventional IEEE802/Ethernet, the usage of some fields must be
clarified to achieve interoperability. This memo proposes the 1394
specific usage of some fields of DHCP messages.",
URL="http://www.ietf.org/internet-drafts/draft-fujisawa-ip1394-dhcp-00.txt"
}

@TECHREPORT{draft-garbrick-shtp,
AUTHOR="R. Garbrick",
TITLE="{Content-Specific} Hypertext Transfer Protocol",
TYPE="Internet Draft",
HOWPUBLISHED="draft-garbrick-shtp-00",
INSTITUTION="Internet Engineering Task Force",
MONTH=jun,
YEAR=1998,
NOTE="Work in progress",
ABSTRACT="This document describes HTTPX, a protocol for providing access
to materials that may be objectionable or that have age or locale-based
restrictions, while providing a simple method to filter such content
where required. HTTPX uses the protocol HTTP 1.1 ([RFC 2068]), with the
single exception of designating a separate range of TCP and UDP port
numbers that are allocated to a specific content type.",
URL="http://www.ietf.org/internet-drafts/draft-garbrick-shtp-00.txt"
}

@TECHREPORT{draft-gellens-acap-acnt,
AUTHOR="R. Gellens",
TITLE="{ACAP} Email Account Dataset Class",
TYPE="Internet Draft",
HOWPUBLISHED="draft-gellens-acap-acnt-00",
INSTITUTION="Internet Engineering Task Force",
MONTH=mar,
YEAR=1998,
NOTE="Work in progress",
ABSTRACT="It has become common for Internet mail users to have more than
one account where mail is received, to access multiple accounts from the
same machine, to access the same accounts from different machines, and
to use multiple programs which require account configuration
information. The Application Configuration Access Protocol [ACAP]
provides an ideal mechanism for storage of email account data. This
specification defines a standard ACAP dataset class for email accounts,
and a common option for indicating a default.",
URL="http://www.ietf.org/internet-drafts/draft-gellens-acap-acnt-00.txt"
}

@TECHREPORT{draft-gellens-acap-book,
AUTHOR="R. Gellens",
TITLE="{ACAP} Bookmarks Dataset Class",
TYPE="Internet Draft",
HOWPUBLISHED="draft-gellens-acap-book-00",
INSTITUTION="Internet Engineering Task Force",
MONTH=mar,
YEAR=1998,
NOTE="Work in progress",
ABSTRACT="Storing URLs [URL] for later access has become common in
Internet applications (for example, web browsers, FTP clients); these
saved URLs have become known as bookmarks. It would be desirable to
access one's bookmarks from multiple clients and multiple machines. The
Application Configuration Access Protocol [ACAP] provides an ideal
mechanism for storage of bookmarks, providing for ease of coordination
and synchronization of bookmarks between diverse applications and
systems, as well as for hierarchy, inheritance, and sharing.",
URL="http://www.ietf.org/internet-drafts/draft-gellens-acap-book-00.txt"
}

@TECHREPORT{draft-gellens-acap-pers,
AUTHOR="R. Gellens",
TITLE="{ACAP} Email Personality Dataset Class",
TYPE="Internet Draft",
HOWPUBLISHED="draft-gellens-acap-pers-00",
INSTITUTION="Internet Engineering Task Force",
MONTH=mar,
YEAR=1998,
NOTE="Work in progress",
ABSTRACT="It has become common for Internet mail users to receive and
compose mail in the capacity of different roles or identities (for
example, personal and work), to receive and compose mail at different
machines, and to use multiple programs which require mail composition
configuration information. These different roles or identities have
become known as email personalities. The Application Configuration
Access Protocol [ACAP] provides an ideal mechanism for storage of email
personality data. This specification defines a standard ACAP dataset
class for email personalities, and a common option for indicating a
default.",
URL="http://www.ietf.org/internet-drafts/draft-gellens-acap-pers-00.txt"
}

@TECHREPORT{draft-gerla-manet-odmrp,
AUTHOR="M. Gerla and G. Pei and S. Lee and C. Chiang",
TITLE="{On-Demand} Multicast Routing Protocol {(ODMRP)} for {Ad-Hoc} Networks",
TYPE="Internet Draft",
HOWPUBLISHED="draft-gerla-manet-odmrp-00",
INSTITUTION="Internet Engineering Task Force",
MONTH=nov,
YEAR=1998,
NOTE="Work in progress",
ABSTRACT="On-Demand Multicast Routing Protocol (ODMRP) is a multicast
routing protocol designed for ad-hoc networks with mobile hosts. ODMRP
is a mesh-based, rather than a conventional tree-based, multicast scheme
and uses a Forwarding Group concept (only a subset of nodes forwards the
multicast packets via scoped flooding). It applies on-demand procedures
to dynamically set up routes and maintain multicast group membership.
ODMRP is well suited for ad-hoc wireless networks with mobile hosts
where bandwidth is limited, topology changes frequently and rapidly, and
power is constrained.",
URL="http://www.ietf.org/internet-drafts/draft-gerla-manet-odmrp-00.txt"
}

@TECHREPORT{draft-gettys-webmux,
AUTHOR="J. Gettys and H. Nielsen",
TITLE="The {WebMUX} Protocol",
TYPE="Internet Draft",
HOWPUBLISHED="draft-gettys-webmux-00",
INSTITUTION="Internet Engineering Task Force",
MONTH=aug,
YEAR=1998,
NOTE="Work in progress",
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",
URL="http://www.ietf.org/internet-drafts/draft-gettys-webmux-00.txt"
}

@TECHREPORT{draft-gilman-news-url,
AUTHOR="A. Gilman",
TITLE="The 'news' {URL} scheme",
TYPE="Internet Draft",
HOWPUBLISHED="draft-gilman-news-url-01",
INSTITUTION="Internet Engineering Task Force",
MONTH=mar,
YEAR=1998,
NOTE="Work in progress",
ABSTRACT="This document defines the format of Uniform Resource Locators
(URLs) identifying news messages and groups. The syntax of 'news' URLs
from RFC 1738 is extended to allow specification of the site from which
the message is to be sought and to incorporate protections via 'snews'
URLs. This combines into the 'news' scheme enough capability so that the
previously-proposed 'nntp' scheme can be retired and URL usage
simplified.",
URL="http://www.ietf.org/internet-drafts/draft-gilman-news-url-01.txt"
}

@TECHREPORT{draft-girod-urn-res-using-wire,
AUTHOR="B. Chen and L. Girod and J. Mallery",
TITLE="{URN} Resolution Using {WIRE}",
TYPE="Internet Draft",
HOWPUBLISHED="draft-girod-urn-res-using-wire-00",
INSTITUTION="Internet Engineering Task Force",
MONTH=mar,
YEAR=1998,
NOTE="Work in progress",
ABSTRACT="The identifier resolution extensions proposed in WIRE [11] add
new mechanisms for redirection and resolver delegation to HTTP. While
these mechanisms are generalized to support resolution of all URIs, they
were designed in part to meet the specific needs of URN resolution
systems. This document describes how the WIRE model maintains
consistency with existing models of URN resolution, how WIRE can be used
as a URN resolution protocol, and how WIRE fits into the existing URN
resolution infrastructure, including NAPTR [8] and THTTP [9].",
URL="http://www.ietf.org/internet-drafts/draft-girod-urn-res-using-wire-00.txt"
}

@TECHREPORT{draft-girod-w3-id-res-ext,
AUTHOR="B. Chen and H. Frystyk and L. Girod and J. Mallery",
TITLE="{WIRE} - {W3} Identifier Resolution Extensions",
TYPE="Internet Draft",
HOWPUBLISHED="draft-girod-w3-id-res-ext-00",
INSTITUTION="Internet Engineering Task Force",
MONTH=mar,
YEAR=1998,
NOTE="Work in progress",
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.",
URL="http://www.ietf.org/internet-drafts/draft-girod-w3-id-res-ext-00.txt"
}

@TECHREPORT{draft-glaude-ss7-gw,
AUTHOR="N. Glaude and T. Blain and R. Cable",
TITLE="{SS7} to {IP} Signaling Gateway Transport Architecture",
TYPE="Internet Draft",
HOWPUBLISHED="draft-glaude-ss7-gw-00",
INSTITUTION="Internet Engineering Task Force",
MONTH=dec,
YEAR=1998,
NOTE="Work in progress",
ABSTRACT="This memo defines an architectural framework for transporting
SS7 signaling information over Internet Protocol networks. It describes
a Signaling Gateway which acts as a bridge between the SS7 and IP
networks. The Signaling Gateway can be configured as an SS7 end-node or
as a Signal Transfer Point (STP) deployed singly or in a mated pair
configuration. An application program interface (API) allows multiple
remote devices, such as Media Gateways and Media Gateway Controllers, to
register with the Signaling Gateway using TCP or UDP. The API consists
of MTP and SCCP primitives which remote devices can use to send and
receive ISUP and TCAP messages to effect PSTN call control and access
Intelligent Network databases. The MTP and SCCP primitives ensure that
application states (available, unavailable or congested) are propagated
into the SS7 network. This memo also identifies some functional and
performance requirements for SS7 signaling transport to IP-based
application processes residing on one or more client hosts.",
URL="ftp://www.ietf.org/internet-drafts/draft-glaude-ss7-gw-00.txt"
}

@TECHREPORT{draft-gordon-ufdl-spec,
AUTHOR="D. Manning and R. Bennett and J. Boyer and S. McLellan and M. Mansell",
TITLE="Universal Forms Description Language Specification Version {4.0.1}",
TYPE="Internet Draft",
HOWPUBLISHED="draft-gordon-ufdl-spec-02",
INSTITUTION="Internet Engineering Task Force",
MONTH=jul,
YEAR=1998,
NOTE="Work in progress",
ABSTRACT="The Universal Forms Description Language (UFDL) describes
complex business forms for use over the Internet. The objective of the
UFDL is to enable the creation of cross-platform Internet business forms
that (1) contain both the complex logic and precise layout that
administrators require, (2) are simple to maintain and distribute, and
(3) integrate easily with existing business systems. As more and more
business is done over the Internet, the need for a form description
language that incorporates these features grows. HTML is designed for
Internet pages, and is severely limited as a form language. This
document specifies the vocabulary, syntax, and meaning of the UFDL.",
URL="http://www.ietf.org/internet-drafts/draft-gordon-ufdl-spec-02.txt"
}

@TECHREPORT{draft-goyal-tcpsat-tcpatm,
AUTHOR="R. Goya and R. Jain",
TITLE="Optimizing {TCP} over Satellite {ATM} Networks",
TYPE="Internet Draft",
HOWPUBLISHED="draft-goyal-tcpsat-tcpatm-00",
INSTITUTION="Internet Engineering Task Force",
MONTH=nov,
YEAR=1998,
NOTE="Work in progress",
ABSTRACT="This document discusses techniques to improve the performance
of TCP over satellite-ATM networks. ATM provides the ABR, UBR and GFR
service categories for data traffic. TCP experiences poor performance
over UBR due to bursty packet losses during congestion. Buffer
management and guaranteed rate techniques to improve TCP performance
over UBR are presented. The performance of TCP over ABR and the
interaction of ABR congestion control mechanisms with TCP congestion
control mechanisms are also described. This document is intended to be
in informational document for the efficient transport of TCP over
satellite-ATM networks.",
URL="http://www.ietf.org/internet-drafts/draft-goyal-tcpsat-tcpatm-00.txt"
}

@TECHREPORT{draft-grall-firewall-mib,
AUTHOR="C. Grall",
TITLE="Firewall Management Information Base",
TYPE="Internet Draft",
HOWPUBLISHED="draft-grall-firewall-mib-01",
INSTITUTION="Internet Engineering Task Force",
MONTH=apr,
YEAR=1998,
NOTE="Work in progress",
ABSTRACT="This document 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 monitoring firewall
devices.",
URL="http://www.ietf.org/internet-drafts/draft-grall-firewall-mib-01.txt"
}

@TECHREPORT{draft-grant-tacacs,
AUTHOR="D. Carrel and L. Grant",
TITLE="The {TACACS+} Protocol Version {1.78}",
TYPE="Internet Draft",
HOWPUBLISHED="draft-grant-tacacs-02",
INSTITUTION="Internet Engineering Task Force",
MONTH=jan,
YEAR=1998,
NOTE="Work in progress",
ABSTRACT="TACACS+ provides access control for routers, network access
servers and other networked computing devices via one or more
centralized servers. TACACS+ provides separate authentication,
authorization and accounting services. This document describes the
protocol that is used by TACACS+.",
URL="http://www.ietf.org/internet-drafts/draft-grant-tacacs-02.txt"
}

@TECHREPORT{draft-greenblatt-signed-dirops,
AUTHOR="B. Greenblatt",
TITLE="Signed Directory Operations Using {S/MIME}",
TYPE="Internet Draft",
HOWPUBLISHED="draft-greenblatt-signed-dirops-00",
INSTITUTION="Internet Engineering Task Force",
MONTH=may,
YEAR=1998,
NOTE="Work in progress",
ABSTRACT="This document defines an LDAP v3 based mechanism for signing
direc- tory operations in order to create a secure journal of changes
that have been made to each directory entry. Both client and server
based signa- tures are supported. An object class for subsequent
retrieval are 'journal entries' is also defined.",
URL="http://www.ietf.org/internet-drafts/draft-greenblatt-signed-dirops-00.txt"
}

@TECHREPORT{draft-greene-diameter-devconf,
AUTHOR="N. Greene and P. Calhoun",
TITLE="{DIAMETER} Device Configuration Extensions",
TYPE="Internet Draft",
HOWPUBLISHED="draft-greene-diameter-devconf-00",
INSTITUTION="Internet Engineering Task Force",
MONTH=sep,
YEAR=1998,
NOTE="Work in progress",
ABSTRACT="This DIAMETER Extension defines commands and AVPs that are
used by two peers to exchange DIAMETER configuration information. The
intent of this draft is to minimize configuration of devices prior to
deployment.",
URL="http://www.ietf.org/internet-drafts/draft-greene-diameter-devconf-00.txt"
}

@TECHREPORT{draft-greene-diameter-ss7-session,
AUTHOR="N. Greene and F. Cuervo",
TITLE="{Bi-Directional} Session Setup Extension to Diameter",
TYPE="Internet Draft",
HOWPUBLISHED="draft-greene-diameter-ss7-session-00",
INSTITUTION="Internet Engineering Task Force",
MONTH=jul,
YEAR=1998,
NOTE="Work in progress",
ABSTRACT="The document [1] describes an architectural framework for
protocol standardization for telephony interworking with the internet.
Interworking deals with both signalling and bearer connections (i.e.,
media stream), which can either be carried together (e.g., in-band, BRI,
PRI) or separately (e.g., SS7).",
URL="http://www.ietf.org/internet-drafts/draft-greene-diameter-ss7-session-00.txt"
}

@TECHREPORT{draft-greene-nasreq,
AUTHOR="N. Greene and F. Cuervo",
TITLE="Best Current Practice for Modem Outsourcing",
TYPE="Internet Draft",
HOWPUBLISHED="draft-greene-nasreq-00",
INSTITUTION="Internet Engineering Task Force",
MONTH=mar,
YEAR=1998,
NOTE="Work in progress",
ABSTRACT="This document describes an architecture and the protocol used
with respect to a Network Access Server (NAS), when modems are
outsourced from the data network operator to the carrier network
operator. At the heart of modem outsourcing there are several key areas,
namely, varied mechanisms for authentication, authorization based on
network wide state and policy for resource sharing, accounting/auditing
and other management functions.",
URL="http://www.ietf.org/internet-drafts/draft-greene-nasreq-00.txt"
}

@TECHREPORT{draft-greene-ss7-arch-frame,
AUTHOR="C. Huitema and M. Holdrege and N. Greene and L. Ong and F. Cuervo",
TITLE="{SS7-Internet} Interworking - Architectural Framework",
TYPE="Internet Draft",
HOWPUBLISHED="draft-greene-ss7-arch-frame-01",
INSTITUTION="Internet Engineering Task Force",
MONTH=aug,
YEAR=1998,
NOTE="Work in progress",
ABSTRACT="This document describes an architectural framework for
SS7-Internet interworking, onto which existing protocols and future
protocols in this space can be mapped. It also provides an ordering of
importance for the standardization of these protocols.",
URL="http://www.ietf.org/internet-drafts/draft-greene-ss7-arch-frame-01.txt"
}

@TECHREPORT{draft-greenfield-acap-mbox,
AUTHOR="L. Greenfield",
TITLE="{ACAP} Mailbox Dataset Class",
TYPE="Internet Draft",
HOWPUBLISHED="draft-greenfield-acap-mbox-01",
INSTITUTION="Internet Engineering Task Force",
MONTH=nov,
YEAR=1998,
NOTE="Work in progress",
ABSTRACT="IMAP [IMAP4] allows users to access the mail store in an
efficient way, but has insufficient support to export detailed
meta-level information about mailboxes, subscriptions, and multiple
servers. The mailbox dataset provides a fast, flexible way of exporting
this",
URL="http://www.ietf.org/internet-drafts/draft-greenfield-acap-mbox-01.txt"
}

@TECHREPORT{draft-greis-aggregation-with-pbac,
AUTHOR="M. Greis and M. Albrecht",
TITLE="Aggregation of Internet Integrated Services State using Parameter-based
Admission Control",
TYPE="Internet Draft",
HOWPUBLISHED="draft-greis-aggregation-with-pbac-00",
INSTITUTION="Internet Engineering Task Force",
MONTH=nov,
YEAR=1998,
NOTE="Work in progress",
ABSTRACT="Aggregation has been proposed as one possible solution to the
scalability problem of the Internet Integrated Services. The current
suggestions for aggregation are based on measurement-based admission
control, which allows for the omission of RSVP soft state in the
interior routers of an aggregating domain. However, measurement-based
admission control has certain flaws which may lead to over-reservations
on links in the network under certain conditions. This can result in
packet losses for reserved traffic. Hence, we believe that it will be
necessary to discuss the possibility of using parameter-based admission
control with aggregation. In this document, we present a technique for
using parameter-based admission control with aggregation as a basis for
further discussions, and we evaluate possible advantages and
disadvantages.",
URL="http://www.ietf.org/internet-drafts/draft-greis-aggregation-with-pbac-00.txt"
}

@TECHREPORT{draft-griner-tcppep-term,
AUTHOR="J. Griner",
TITLE="{TCP} Performance Enhancing Proxy Terminology",
TYPE="Internet Draft",
HOWPUBLISHED="draft-griner-tcppep-term-00",
INSTITUTION="Internet Engineering Task Force",
MONTH=nov,
YEAR=1998,
NOTE="Work in progress",
ABSTRACT="This document presents definitions for many terms to be used
during the discussion of various TCP Performance Enhancing Proxies
(PEP). A PEP, located between two end-systems, is used to, in some way,
enhance a TCP connection. PEP's are commonly referred to as spoofing,
connection splitting gateways, etc.",
URL="http://www.ietf.org/internet-drafts/draft-griner-tcppep-term-00.txt"
}

@TECHREPORT{draft-gupta-efficient-ad,
AUTHOR="A. Gupta and G. Baehr",
TITLE="Efficiently transporting ad-carrying web pages",
TYPE="Internet Draft",
HOWPUBLISHED="draft-gupta-efficient-ad-00",
INSTITUTION="Internet Engineering Task Force",
MONTH=nov,
YEAR=1998,
NOTE="Work in progress",
ABSTRACT="This draft proposes a simple extension to HTTP, using a new
set of headers, which can significantly reduce the network traffic used
for sending pages containing advertising banners and other related
content. We begin by describing the problems generated by the use of
'cache-busting' techniques today and why the Hit-metering scheme
[RFC2227], by itself, may not be adequate. We will then describe a new
scheme which relies on collaboration between the content providers and
the Internet Service Providers (ISPs).",
URL="http://www.ietf.org/internet-drafts/draft-gupta-efficient-ad-00.txt"
}

@TECHREPORT{draft-gustafsson-mobileip-imt-2000,
AUTHOR="E. Gustafsson and A. Herlitz and A. Jonsson and M. Korling",
TITLE="{UMTS/IMT-2000} and Mobile {IP/DIAMETER} Harmonization",
TYPE="Internet Draft",
HOWPUBLISHED="draft-gustafsson-mobileip-imt-2000-00",
INSTITUTION="Internet Engineering Task Force",
MONTH=nov,
YEAR=1998,
NOTE="Work in progress",
ABSTRACT="The purpose of this document is to form a basis for discussion
about the development of the Mobile IP standard. It is foreseen that
cellular mobile systems will give rise to a widespread global use of IP
mobility tunnels. We describe scenarios and identify important issues
for the Mobile IP specification and the proposed DIAMETER extensions for
Mobile IP.",
URL="http://www.ietf.org/internet-drafts/draft-gustafsson-mobileip-imt-2000-00.txt"
}

@TECHREPORT{draft-haberman-ipv6-site-route,
AUTHOR="B. Haberman",
TITLE="Routing of {Site-Scoped} Addresses in the Internet Protocol Version 6
{(IPv6)}",
TYPE="Internet Draft",
HOWPUBLISHED="draft-haberman-ipv6-site-route-00",
INSTITUTION="Internet Engineering Task Force",
MONTH=apr,
YEAR=1998,
NOTE="Work in progress",
ABSTRACT="This document outlines a mechanism for generating routing
tables that include site-scoped IPv6 addresses. It defines a set of
rules for routers to implement in order to forward site-scoped addresses
regardless of the routing protocol.",
URL="http://www.ietf.org/internet-drafts/draft-haberman-ipv6-site-route-00.txt"
}

@TECHREPORT{draft-halpern-ion-r2r-nhrp,
AUTHOR="J. Halpern and Y. Rekhter",
TITLE="{NHRP} for Destinations off the {NBMA} Subnetwork",
TYPE="Internet Draft",
HOWPUBLISHED="draft-halpern-ion-r2r-nhrp-00",
INSTITUTION="Internet Engineering Task Force",
MONTH=jun,
YEAR=1998,
NOTE="Work in progress",
ABSTRACT="The NBMA Next Hop Resolution Protocol (NHRP) [1] specifies a
mechanism that allows a source station (e.g., a host or a router) on an
NBMA subnetwork to find the NBMA subnetwork address address of a
destination station when the destination station is connected to the
NBMA subnetwork. For the case where the destination station is off the
NBMA subnetwork the mechanism described in [1] allows to determine the
NBMA subnetwork address of an egress router from the NBMA subnetwork
that is ``nearest'' to the destination station. If used to locate an
egress router wherein the destination station is directly behind the
egress router, the currently document NHRP behaviors are sufficient.
However, as documented elsewhere [2], there are cases where if used
between routers for generalized transit, NHRP can produce loops. This
document describes extensions to the NBMA Next Hop Resolution Protocol
(NHRP) [1] that allow to acquire and maintain the information about the
egress router without constraining the destination(s) to be directly
connected to the egress router.",
URL="http://www.ietf.org/internet-drafts/draft-halpern-ion-r2r-nhrp-00.txt"
}

@TECHREPORT{draft-hamilton-fix-dns,
AUTHOR="M. Hamilton and J. Knight",
TITLE="Distributing control of the Domain Name System",
TYPE="Internet Draft",
HOWPUBLISHED="draft-hamilton-fix-dns-00",
INSTITUTION="Internet Engineering Task Force",
MONTH=mar,
YEAR=1998,
NOTE="Work in progress",
ABSTRACT="This proposal outlines a way in which the Internet community
may be able to route around the legal and political issues associated
with control of the Domain Name System. We suggest a new mechanism for
the distribution of domain name information, based on strong
cryptographic authentication. In this new system, anyone is free to
''publish'' domain name information, with control over whether or not it
is accepted left to the local site DNS server administrators.",
URL="http://www.ietf.org/internet-drafts/draft-hamilton-fix-dns-00.txt"
}

@TECHREPORT{draft-hanna-marp,
AUTHOR="S. Hanna",
TITLE="Multicast Address Request Protocol {(MARP)}",
TYPE="Internet Draft",
HOWPUBLISHED="draft-hanna-marp-00",
INSTITUTION="Internet Engineering Task Force",
MONTH=jan,
YEAR=1998,
NOTE="Work in progress",
ABSTRACT="The Multicast Address Request Protocol (MARP) serves as a
front end to the Multicast Address Allocation Architecture. Any host
that wishes to allocate a multicast address may contact a Multicast
Address Allocation Server and use MARP to request an address allocation
for a specific interval, scope, etc. Later, the host may request an
extension of the address allocation or deallocate the address if it is
no longer needed.",
URL="http://www.ietf.org/internet-drafts/draft-hanna-marp-00.txt"
}

@TECHREPORT{draft-hansen-pop3-xtndext,
AUTHOR="T. Hansen",
TITLE="{POP3} {XTND} Extensions",
TYPE="Internet Draft",
HOWPUBLISHED="draft-hansen-pop3-xtndext-00",
INSTITUTION="Internet Engineering Task Force",
MONTH=jun,
YEAR=1998,
NOTE="Work in progress",
ABSTRACT="This Internet Draft describes some extensions to the Post
Office Protocol [POP3] and are described here for historical purposes.
The status of this Internet Draft will be Historic. [XTND] describes a
mechanism to extend the POP3 protocol, called XTND. Two extensions which
have been implemented on some server implementations are XTND XMIT and
XTND XLST; this memo describes these extensions. New implementations of
POP3 clients and servers are not expected to implement these extensions;
other mechanisms should be used instead. For example, [SMTP] should be
used instead of XTND XMIT for sending email. If authentication is needed
for sending email, then the proposed [ESMTP] [AUTH] extension should be
used.",
URL="http://www.ietf.org/internet-drafts/draft-hansen-pop3-xtndext-00.txt"
}

@TECHREPORT{draft-hassler-ldapv3-secparam,
AUTHOR="V. Hassler",
TITLE="{LDAPv3} Security Parameters",
TYPE="Internet Draft",
HOWPUBLISHED="draft-hassler-ldapv3-secparam-00",
INSTITUTION="Internet Engineering Task Force",
MONTH=mar,
YEAR=1998,
NOTE="Work in progress",
ABSTRACT="Two security services that are required in many applications
but have not been addressed by LDAPv3 [ldapv3] in a satisfactory manner
yet are integrity and non-repudiation. According to the latest LDAPv3
security draft [ldapv3-auth] integrity can be achieved within a secure
association only. Non-repudiation, and by this we mean digital signing
of operations, is mentioned in [ldapv3] as an example of the use of the
LDAPv3 extended operation mechanism. A disadvantage of this approach is
that it would be necessary to define a new Extended Request/Response
pair for each basic operation that should be signed. This document
defines an LDAP control called LDAPSecurityParameters for transferring
security parameters with LDAP operations. With this control it is
possible to append digital signature to LDAP operations and in this way
provide for message authenticity, message integrity, non-repudiation of
message origin and message freshness.",
URL="http://www.ietf.org/internet-drafts/draft-hassler-ldapv3-secparam-00.txt"
}

@TECHREPORT{draft-heftagaub-rmff,
AUTHOR="R. Agarwal and J. Ayars and B. Hefta-Gaub and D. Stammen",
TITLE="{RealMedia} File Format",
TYPE="Internet Draft",
HOWPUBLISHED="draft-heftagaub-rmff-00",
INSTITUTION="Internet Engineering Task Force",
MONTH=mar,
YEAR=1998,
NOTE="Work in progress",
ABSTRACT="The RealMedia File Format (RMFF) is designed to be a generic
container for streaming media data. This data may then be played back
locally or streamed over a network using protocols such as RTSP and RTP.
The format is data-independent, allowing any data type to be recorded,
manipulated and played back. Note: This document is intended to be
informational in nature of what the file format in use by RealNetworks'
RealServer and RealPlayer implementations. Though we think that there
are a lot of important concepts embodied in this specification, and that
it may even make the basis of a ''standard'' file format, this is
intended to eventually end up as an Informational RFC.",
URL="http://www.ietf.org/internet-drafts/draft-heftagaub-rmff-00.txt"
}

@TECHREPORT{draft-heinanen-diffserv-af,
AUTHOR="J. Heinanen",
TITLE="Assured Forwarding {PHB} Group",
TYPE="Internet Draft",
HOWPUBLISHED="draft-heinanen-diffserv-af-00",
INSTITUTION="Internet Engineering Task Force",
MONTH=aug,
YEAR=1998,
NOTE="Work in progress",
ABSTRACT="This document proposes a general use Differentiated Services
(DS) [Black] Per-Hop-Behavior (PHB) Group called Assured Forwarding
(AF). AF PHB group consists of two code points AF1 and AF2. A DS node
delivers packets marked as AF1 with a very small propability of loss,
whereas packets marked as AF2 are delivered as best effort. The DS node
will not reorder AF packets of the same microflow no matter if some of
the packets are marked as AF1 and some as AF2. There is no timing
requirements associated with the delivery of AF packets.",
URL="http://www.ietf.org/internet-drafts/draft-heinanen-diffserv-af-00.txt"
}

@TECHREPORT{draft-heinanen-generic-vpn-mpls,
AUTHOR="J. Heinanen and B. Gleeson and A. Lin",
TITLE="{MPLS} Mappings of Generic {VPN} Mechanisms",
TYPE="Internet Draft",
HOWPUBLISHED="draft-heinanen-generic-vpn-mpls-00",
INSTITUTION="Internet Engineering Task Force",
MONTH=aug,
YEAR=1998,
NOTE="Work in progress",
ABSTRACT="This document describes a set of generic mechanisms which can
be used to set up network based Virtual Private Networks (VPN) across IP
networks. In particular, it describes how these mechanisms can be mapped
into a network running the Multi-Protocol Label Switching (MPLS)
specification. The mechanisms described, however, can apply to any type
of IP network running various forms of IP tunneling mechanisms, and are
not solely restricted to MPLS networks. This Draft serves to introduce
these generic mechanisms, which are part of the broader VPN framework
which will be described more fully in forthcoming Drafts.",
URL="http://www.ietf.org/internet-drafts/draft-heinanen-generic-vpn-mpls-00.txt"
}

@TECHREPORT{draft-heinanen-mpls-vpn,
AUTHOR="J. Heinanen and E. Rosen",
TITLE="{VPN} support for {MPLS}",
TYPE="Internet Draft",
HOWPUBLISHED="draft-heinanen-mpls-vpn-01",
INSTITUTION="Internet Engineering Task Force",
MONTH=mar,
YEAR=1998,
NOTE="Work in progress",
ABSTRACT="This document provides a high-level description of how Virtual
Private Networks can be supported by using MPLS.",
URL="http://www.ietf.org/internet-drafts/draft-heinanen-mpls-vpn-01.txt"
}

@TECHREPORT{draft-heinanen-ppp-subnet,
AUTHOR="J. Heinanen and D. Allan and A. Lin and P. Shieh",
TITLE="{PPP} Internet Protocol Control Protocol Extensions for {IP} Subnet",
TYPE="Internet Draft",
HOWPUBLISHED="draft-heinanen-ppp-subnet-00",
INSTITUTION="Internet Engineering Task Force",
MONTH=nov,
YEAR=1998,
NOTE="Work in progress",
ABSTRACT="The Point-to-Point Protocol (PPP) [1] provides a standard
method for transporting multi-protocol datagrams over point-to-point
links. PPP defines an extensible Link Control Protocol and a family of
Network Control Protocols (NCPs) for establishing and configuring
different network-layer protocols. This document extends the NCP for
establishing and configuring the Internet Protocol over PPP [2] by
defining an IP Subnet configuration option.",
URL="http://www.ietf.org/internet-drafts/draft-heinanen-ppp-subnet-00.txt"
}

@TECHREPORT{draft-henderson-dasl-scenarios,
AUTHOR="R. Henderson",
TITLE="Scenarios for {DASL}",
TYPE="Internet Draft",
HOWPUBLISHED="draft-henderson-dasl-scenarios-00",
INSTITUTION="Internet Engineering Task Force",
MONTH=sep,
YEAR=1998,
NOTE="Work in progress",
ABSTRACT="The Distributed Authoring and Versioning protocol [WEBDAV]
defines simple mechanisms to assign and retrieve values for properties.
This document presents scenarios for a WebDAV extension to support
efficient searching for resources based on WEBDAV properties and
content. These scenarios are intended to suggest some of the uses that
DASL could be put to. This may in turn motivate decisions on what is
essential to DASL and what may be considered extra.",
URL="http://www.ietf.org/internet-drafts/draft-henderson-dasl-scenarios-00.txt"
}

@TECHREPORT{draft-henry-DHCP-opt61-UUID-type,
AUTHOR="M. Henry",
TITLE="{DHCP} Option 61 {UUID} Type Definition",
TYPE="Internet Draft",
HOWPUBLISHED="draft-henry-DHCP-opt61-UUID-type-00",
INSTITUTION="Internet Engineering Task Force",
MONTH=nov,
YEAR=1998,
NOTE="Work in progress",
ABSTRACT="The DHCP [1] mechanism for identifying the client as a unique
entity is the DHCP client-identifier option (code 61) [2]. This draft
defines for Option 61 a specific type and type number of a
client-identifier based on generated UUIDs [3]. These identifiers are
guaranteed to be, or are very, very likely to be unique across time and
all clients.",
URL="http://www.ietf.org/internet-drafts/draft-henry-DHCP-opt61-UUID-type-00.txt"
}

@TECHREPORT{draft-hodson-hobs,
AUTHOR="K. Richardson and A. Hodson and E. Andersen and L. Visser and P. Fantou and
J. Pasquerau",
TITLE="Hierarchical Operational Bindings - a profile",
TYPE="Internet Draft",
HOWPUBLISHED="draft-hodson-hobs-00",
INSTITUTION="Internet Engineering Task Force",
MONTH=feb,
YEAR=1998,
NOTE="Work in progress",
ABSTRACT="Where LDAP servers are based on X.500 DSAs for the holding of
distributed Directory information, the maintenance of the necessary
security and networking relationships between DSAs is an important
factor to consider. The '93 X.500 Directory standards define HOB
(Hierarchical Operational Binding) procedures for the creation of a new
naming context in another DSA, and also for the maintenance of the
relationship between two DSAs where one holds a superior naming context
and the other holds a subordinate naming context. The standards also
define the use of the Directory Operational Binding Management Protocol
(DOP) to mediate these procedures. The use of HOBs provides a major
simplification for managers of X.500 systems, since it provides a way to
update policies automatically from one DSA to another. But practical
design for HOBs requires decisions in a number of respects not fully
treated by the standards. This document simplifies the implementor's
task by defining viable and practical subsets of the standards and by
clarifying some of the issues left undefined by the standards. HOBs
always represent an intimate relationship between DSAs which must be
protected from masquerade. A method of providing this protection is
given in the '93 Directory standards by requiring mutual authentication
at the bind between DSAs. HOBS will normally only be established between
DSAs owned by a single administrative authority, so security needs to be
considered in this somewhat easier context than complete openness.
Although simple unprotected authentication (name and password) can be a
valid option in an already-secure environment, simple protected
authentication using an encrypted password is potentially a much more
secure technique, as is strong authentication using public key
cryptography. All such techniques are validly used within the scope of
this profile, as are techniques not defined but permitted by the
Directory standards (these are known as ''external'' methods). Support
of simple authentication is mandated for all implementations compliant
with this profile. Where this is not adequate, purchasers need to ensure
that their requirements for are met.",
URL="http://www.ietf.org/internet-drafts/draft-hodson-hobs-00.txt"
}

@TECHREPORT{draft-hoffman-legis-smtp-banner,
AUTHOR="P. Hoffman and J. Levine",
TITLE="{Anti-UBE} and {Anti-UCE} Keywords in {SMTP} Banners",
TYPE="Internet Draft",
HOWPUBLISHED="draft-hoffman-legis-smtp-banner-03",
INSTITUTION="Internet Engineering Task Force",
MONTH=nov,
YEAR=1998,
NOTE="Work in progress",
ABSTRACT="Legislators writing laws that would limit or prohibit the
sending of unsolicited bulk email (UBE) or unsolicited commercial email
(UCE) have begun to include rules that require mail servers to include
particular wording in the SMTP banner. To date, this wording has had two
distinct purposes: to warn senders that they may not send UBE or UCE to
that SMTP host, and to state the physical location of the host so that
the sender may know which laws apply. This document is meant to help
clarify how such legislation might be worded, and to help increase
interoperability of various laws. It is not meant to be a standard of
any kind, but is meant only for its informational value.",
URL="http://www.ietf.org/internet-drafts/draft-hoffman-legis-smtp-banner-03.txt"
}

@TECHREPORT{draft-hoffman-smtp-ssl,
AUTHOR="P. Hoffman",
TITLE="{SMTP} Service Extension for Secure {SMTP} over {TLS}",
TYPE="Internet Draft",
HOWPUBLISHED="draft-hoffman-smtp-ssl-10",
INSTITUTION="Internet Engineering Task Force",
MONTH=nov,
YEAR=1998,
NOTE="Work in progress",
ABSTRACT="This document describes an extension to the SMTP service that
allows an SMTP server and client to use transport-layer security to
provide private, authenticated communication over the Internet. This
gives SMTP agents the ability to protect some or all of their
communications from eavesdroppers and attackers.",
URL="http://www.ietf.org/internet-drafts/draft-hoffman-smtp-ssl-10.txt"
}

@TECHREPORT{draft-hoffman-widetext,
AUTHOR="P. Hoffman",
TITLE="Registration for the 'widetext' Media Type",
TYPE="Internet Draft",
HOWPUBLISHED="draft-hoffman-widetext-01",
INSTITUTION="Internet Engineering Task Force",
MONTH=dec,
YEAR=1998,
NOTE="Work in progress",
ABSTRACT="This document defines a new MIME top-level media type,
'widetext', which can be used to carry text that employs the UTF-16
character encoding scheme. The use of the 'widetext' media type is
limited to text-like MIME bodies that cannot be represented using the
'text' media type.",
URL="ftp://www.ietf.org/internet-drafts/draft-hoffman-widetext-01.txt"
}

@TECHREPORT{draft-honton-sdp,
AUTHOR="C. Honton",
TITLE="Simple Server Discovery Protocol",
TYPE="Internet Draft",
HOWPUBLISHED="draft-honton-sdp-02",
INSTITUTION="Internet Engineering Task Force",
MONTH=jan,
YEAR=1998,
NOTE="Work in progress",
ABSTRACT="The Simple Server Discovery Protocol allows clients to use a
multicast address to discover the unicast interface of a cooperating
server for a desired service port and optionally authenticate the
identity of the client and/or server.",
URL="http://www.ietf.org/internet-drafts/draft-honton-sdp-02.txt"
}

@TECHREPORT{draft-hoschka-smilsdp,
AUTHOR="P. Hoschka",
TITLE="Integrating {SDP} Functionality Into {SMIL}",
TYPE="Internet Draft",
HOWPUBLISHED="draft-hoschka-smilsdp-01",
INSTITUTION="Internet Engineering Task Force",
MONTH=sep,
YEAR=1998,
NOTE="Work in progress",
ABSTRACT="This document describes an approach for integrating the
functionality currently contained in [47]SDP (Session Announcement
Protocol) into [48]SMIL (Synchronized Multimedia Integration Language).
The motivation is to make it easier for SMIL authors to interface with
the existing RTP/MBone infrastructure. Currently, this requires
maintaining two different sets of files, each of which use a different
text format. Another motivation is to save one network round-trip per
RTSP URL in the SMIL file, since the information contained in the SDP
file is now directly included in the SMIL file.",
URL="http://www.ietf.org/internet-drafts/draft-hoschka-smilsdp-01.txt"
}

@TECHREPORT{draft-huehnlein-credman-spkm,
AUTHOR="D. Huehnlein and H. Schupp",
TITLE="Credential Management for {SPKM}",
TYPE="Internet Draft",
HOWPUBLISHED="draft-huehnlein-credman-spkm-00",
INSTITUTION="Internet Engineering Task Force",
MONTH=mar,
YEAR=1998,
NOTE="Work in progress",
ABSTRACT="The GSS-API [GSS-API1,2] offers security services independent
of underlying mechanisms. A possible GSS-mechanism is the Simple Public
Key Mechanism [SPKM]. This paper complements [SPKM] by providing
concrete rules for the Credential Management. Our proposal allows beside
the standard Credential Management based on X.509v3 [X509v3] and PKIX
[PKIX] the self certification of temporary public keys, which may be
used to implement a Secure Single Login variant, which works with
temporary keys instead of the sensitive long term keys. The benefits of
this approach are discussed in [SSLogin] more detailed. Since DL-based
signature- and encryption algorithms are very well suited for the
efficient generation of the temporary keys we propose two new
RECOMMENDED algorithms for SPKM.",
URL="http://www.ietf.org/internet-drafts/draft-huehnlein-credman-spkm-00.txt"
}

@TECHREPORT{draft-huitema-mgcp-flows,
AUTHOR="C. Huitema and F. Andreasen and M. Arango",
TITLE="Media Gateway Control Protocol {(SGCP)} Call Flows",
TYPE="Internet Draft",
HOWPUBLISHED="draft-huitema-mgcp-flows-00",
INSTITUTION="Internet Engineering Task Force",
MONTH=nov,
YEAR=1998,
NOTE="Work in progress",
ABSTRACT="The Media Gateway Control Protocol (MGCP) organizes the
communication between a Media Gateway controller, or call agent, and a
Media Gateway, e.g. a Voice over IP gateway or a Network Access Server.
MGCP is defined in a companion document [1]. This document provides
example of MGCP usage by providing a variety of call flows, in the case
of telephony and network access servers.",
URL="http://www.ietf.org/internet-drafts/draft-huitema-mgcp-flows-00.txt"
}

@TECHREPORT{draft-huitema-sgcp-v1,
AUTHOR="M. Arango and C. Huitema",
TITLE="Simple Gateway Control Protocol {(SGCP)}",
TYPE="Internet Draft",
HOWPUBLISHED="draft-huitema-sgcp-v1-02",
INSTITUTION="Internet Engineering Task Force",
MONTH=sep,
YEAR=1998,
NOTE="Work in progress",
ABSTRACT="This document describes an application programming interface
(SGCI) and a corresponding protocol (SGCP) for controlling Voice over IP
(VoIP) Gateways from external call control elements. The SGCP assumes a
call control architecture where the call control 'intelligence' is
outside the gateways and handled by external call control elements. The
document is structured in 5 main sections: * The introduction presents
the basic assumptions and the relation to other protocols such as H.323,
RTSP, SAP or SIP. * The interface section presents a conceptual overview
of the SGCP, presenting the naming conventions, the usage of the session
description protocol SDP, and the five procedurs that compose SGCP:
Notifications Request, Notification, Create Connection, Modify Con-
nection and Delete Connection. * The protocol description section
presents the SGCP encodings, which are based on simple text formats, and
the transmission procedure over UDP. * The security section presents the
security requirement of SGCP, and its usage of IP security services
(IPSEC). * An example section presents two detailed examples of call set
up procedures using SGCP. * The description of the changes between
version 1.0 and version 1.1",
URL="http://www.ietf.org/internet-drafts/draft-huitema-sgcp-v1-02.txt"
}

@TECHREPORT{draft-hunter-talk,
AUTHOR="M. Hunter",
TITLE="talk: a historical protocol for interactive communication",
TYPE="Internet Draft",
HOWPUBLISHED="draft-hunter-talk-00",
INSTITUTION="Internet Engineering Task Force",
MONTH=jan,
YEAR=1998,
NOTE="Work in progress",
ABSTRACT="The BSD talk utility is used for interactive communication
between two users. This memo outlines the protocol used.",
URL="http://www.ietf.org/internet-drafts/draft-hunter-talk-00.txt"
}

@TECHREPORT{draft-iab-perlman-folklore,
AUTHOR="R. Perlman",
TITLE="Folklore of Protocol Design",
TYPE="Internet Draft",
HOWPUBLISHED="draft-iab-perlman-folklore-00",
INSTITUTION="Internet Engineering Task Force",
MONTH=jan,
YEAR=1998,
NOTE="Work in progress",
ABSTRACT="This document is intended to set the tone as an IETF
collaboration to collect various tricks and ''gotchas'' in protocol
design. It is not intended to declare the ''right'' and ''wrong'' ways
of doing things, but rather ''this practice has the following advantages
and disadvantages'', or ''here are several ways of solving the following
problem'', with technical explanation of the pros and cons of the
various approaches. Discussion will take place on the mailing list
folklore(at)external.cisco.com. To join, send a message to folklore-
request(at)external.cisco.com.",
URL="http://www.ietf.org/internet-drafts/draft-iab-perlman-folklore-00.txt"
}

@TECHREPORT{draft-iab-rtr-workshop,
AUTHOR="S. Deering and S. Hares and C. Perkins and R. Perlman",
TITLE="Report on the 1998 {IAB} Routing Workshop",
TYPE="Internet Draft",
HOWPUBLISHED="draft-iab-rtr-workshop-00",
INSTITUTION="Internet Engineering Task Force",
MONTH=nov,
YEAR=1998,
NOTE="Work in progress",
ABSTRACT="This document is an overview of a Routing workshop held by the
Internet Architecture Board during March 25-27, 1998. The major points
of discussion are listed, along with some conclusions and action items
for many of the points of discussion. The full body of the report will
be provided in a separate document.",
URL="http://www.ietf.org/internet-drafts/draft-iab-rtr-workshop-00.txt"
}

@TECHREPORT{draft-iannella-admin,
AUTHOR="R. Iannella and D. Campbell",
TITLE="Admin Core - Administrative Container Metadata",
TYPE="Internet Draft",
HOWPUBLISHED="draft-iannella-admin-00",
INSTITUTION="Internet Engineering Task Force",
MONTH=sep,
YEAR=1998,
NOTE="Work in progress",
ABSTRACT="Administrative metadata - referred to as 'Admin Core' - is
useful to designate information about the creation and availability of
other sets of metadata. The objective of Admin Core is to provide simple
authentication to verify the integrity and provenance of information
retrieved from networked resources. The Admin Core elements are utilised
to associate date and creator information about metadata.",
URL="http://www.ietf.org/internet-drafts/draft-iannella-admin-00.txt"
}

@TECHREPORT{draft-ibanez-diffserv-assured-eval,
AUTHOR="K. Nichols and J. Ibanez",
TITLE="Preliminary Simulation Evaluation of an Assured Service",
TYPE="Internet Draft",
HOWPUBLISHED="draft-ibanez-diffserv-assured-eval-00",
INSTITUTION="Internet Engineering Task Force",
MONTH=aug,
YEAR=1998,
NOTE="Work in progress",
ABSTRACT="This draft presents a simulation analysis of Assured Service,
an end-to-end service based on the differentiated services enhancements
for IP. Assured Service has been the subject of much discussion in the
past year in the IETF, but solid information on its applicability to the
entire Internet has been lacking. This report is aimed at providing a
first step in this direction. Assured Service requires an active queue
management algorithm with preferential packet drop. The RIO algorithm
(an extension of the RED algorithm) has been the primary method
suggested and is the one evaluated here. Our results show that Assured
Service does not provide clearly defined and consistent rate guarantees;
the advantage gained by connections using Assured Service is not a
quantifiable one. Further work would be required to determine an
appropriate use of the Assured Service. A pdf version of this document
is available and recommended for the figures it contains.",
URL="http://www.ietf.org/internet-drafts/draft-ibanez-diffserv-assured-eval-00.txt"
}

@TECHREPORT{draft-iesg-bradner-pso-bl,
AUTHOR="S. Bradner",
TITLE="Bylaws for a Protocol Support Organization",
TYPE="Internet Draft",
HOWPUBLISHED="draft-iesg-bradner-pso-bl-00",
INSTITUTION="Internet Engineering Task Force",
MONTH=oct,
YEAR=1998,
NOTE="Work in progress",
ABSTRACT="The 'new IANA corporation' (referred to below as 'the Internet
Corporation for Assigned Names and Numbers' (ICANN)) assumes the
existence of a 'Protocol Supporting Organization' (PSO). This document
is a draft set of bylaws for such an organization.",
URL="http://www.ietf.org/internet-drafts/draft-iesg-bradner-pso-bl-00.txt"
}

@TECHREPORT{draft-iesg-rfc-checklist,
AUTHOR="K. Moore",
TITLE="{(DRAFT)} Checklist for {RFC} Authors",
TYPE="Internet Draft",
HOWPUBLISHED="draft-iesg-rfc-checklist-00",
INSTITUTION="Internet Engineering Task Force",
MONTH=apr,
YEAR=1998,
NOTE="Work in progress",
ABSTRACT="This is a list of things that often delay processing of RFCs
by IESG and/or the RFC Editor, and which are often preventable by RFC
authors. The purpose of this document is to list in one place the most
frequent causes of unnecessary delay, and thereby help RFC authors
minimize such delays when possible. This document is emphatically NOT an
expression of IESG policy, nor that of the RFC Editor, and is provided
merely for informational purposes. When appropriate, this document
attempts to provide references to other documents, some of which are
expressions of IESG, IETF, and/or RFC Editor policy and others which are
merely informational. Readers are advised to check the official status
of each reference. The RFC Editor's instructions to RFC Authors are in
[rfc-instructions].",
URL="http://www.ietf.org/internet-drafts/draft-iesg-rfc-checklist-00.txt"
}

@TECHREPORT{draft-iesg-using-http,
AUTHOR="K. Moore and P. Faltstrom",
TITLE="On the use of {HTTP} as a Substrate for Other Protocols",
TYPE="Internet Draft",
HOWPUBLISHED="draft-iesg-using-http-00",
INSTITUTION="Internet Engineering Task Force",
MONTH=aug,
YEAR=1998,
NOTE="Work in progress",
ABSTRACT="Recently there has been widespread interest in using Hypertext
Transport Protocol (HTTP) as a substrate for other applications-level
protocols. This document relates current IESG and IAB thinking on
technical particulars of such use, including use of default ports, URL
schemes, and HTTP security mechanisms. This thinking is subject to
change as discussion continues and more experience is gained with such
use.",
URL="http://www.ietf.org/internet-drafts/draft-iesg-using-http-00.txt"
}

@TECHREPORT{draft-ietf-acap-dict,
AUTHOR="C. Daboo",
TITLE="{ACAP} personal dictionary dataset class",
TYPE="Internet Draft",
HOWPUBLISHED="draft-ietf-acap-dict-00",
INSTITUTION="Internet Engineering Task Force",
MONTH=mar,
YEAR=1998,
NOTE="Work in progress",
ABSTRACT="The Application Configuration Access Protocol [ACAP] is
designed to support remote storage and access of common application
option, configuration and preference information. Its main benefits are
in providing a way for users to gain access to personal information from
any computer at a location supporting an internet connection, by keeping
this information stored centrally on a server. Additionally, it allows
'kiosk' style use of computers so that users do not need to store data
locally on a shared or public workstation or network computer. This
specification defines a standard dataset class for personal dictionaries
that would allow users to keep one or more 'user dictionaries' stored on
an ACAP server for access by any ACAP-aware application that requires
such information, for example any application that uses a spell checker.",
URL="http://www.ietf.org/internet-drafts/draft-ietf-acap-dict-00.txt"
}

@TECHREPORT{draft-ietf-acap-options,
AUTHOR="S. Hole",
TITLE="{ACAP} Application Options Dataset Class",
TYPE="Internet Draft",
HOWPUBLISHED="draft-ietf-acap-options-02",
INSTITUTION="Internet Engineering Task Force",
MONTH=mar,
YEAR=1998,
NOTE="Work in progress",
ABSTRACT="The Application Configuration Access Protocol (ACAP) is
designed to support remote storage and access of application option,
configuration and preference information. The generalized form of this
runtime configuration is called ''options''. Options consist of any type
of structured or unstructured data that an application requires to
operate in a user specific manner.",
URL="http://www.ietf.org/internet-drafts/draft-ietf-acap-options-02.txt"
}

@TECHREPORT{draft-ietf-acap-type-ext,
AUTHOR="R. Earhart",
TITLE="{ACAP} {TYPE} Extension",
TYPE="Internet Draft",
HOWPUBLISHED="draft-ietf-acap-type-ext-01",
INSTITUTION="Internet Engineering Task Force",
MONTH=mar,
YEAR=1998,
NOTE="Work in progress",
ABSTRACT="The Application Configuration Access Protocol [ACAP] defines
rough typing information in the form of an attribute naming convention.
This extension to ACAP allows a MIME content-type/subtype with
parameters to be associated with a given piece of data, providing
knowledgeable clients with useful information in a way which maintains
compatability with innocent clients and servers.",
URL="http://www.ietf.org/internet-drafts/draft-ietf-acap-type-ext-01.txt"
}

@TECHREPORT{draft-ietf-aft-socks-chap,
AUTHOR="M. VanHeyningen",
TITLE="{Challenge-Handshake} Authentication Protocol for {SOCKS} {V5}",
TYPE="Internet Draft",
HOWPUBLISHED="draft-ietf-aft-socks-chap-01",
INSTITUTION="Internet Engineering Task Force",
MONTH=jan,
YEAR=1998,
NOTE="Work in progress",
ABSTRACT="This document specifies the integration of authentication
based on Challenge-Handshake Authenticaton Protocol into SOCKS Version
5. The primary algorithm to be used is HMAC-MD5, although the framework
is general enough to permit use of MD5 or other keyed hash algorithms.
This document describes the message formats and protocol details of
incorporating CHAP into the SOCKS V5 authentication ''subnegotiation.''
Support is included for authentication of server to client as well as
client to server.",
URL="http://www.ietf.org/internet-drafts/draft-ietf-aft-socks-chap-01.txt"
}

@TECHREPORT{draft-ietf-aft-socks-eap,
AUTHOR="G. Zorn and P. Calhoun and J. Haag",
TITLE="{EAP} Authentication for {SOCKS} Version 5",
TYPE="Internet Draft",
HOWPUBLISHED="draft-ietf-aft-socks-eap-00",
INSTITUTION="Internet Engineering Task Force",
MONTH=mar,
YEAR=1998,
NOTE="Work in progress",
ABSTRACT="This document defines how EAP [5] (Extensible Authentication
Protocol) can be used with the SOCKS V5 protocol. EAP was defined to
allow any authentication mechanism to be used without any modification
to the authentication protocol (i.e. CHAP, OTP).",
URL="http://www.ietf.org/internet-drafts/draft-ietf-aft-socks-eap-00.txt"
}

@TECHREPORT{draft-ietf-aft-socks-maf,
AUTHOR="J. Michener and D. Fritch",
TITLE="{Multi-Authentication} Framework Method for {SOCKS} {V5}",
TYPE="Internet Draft",
HOWPUBLISHED="draft-ietf-aft-socks-maf-00",
INSTITUTION="Internet Engineering Task Force",
MONTH=mar,
YEAR=1998,
NOTE="Work in progress",
ABSTRACT="SOCKS V5 [RFC 1928] provides a means to select one from among
a number of authentication methods, but does not provide any means for
utilizing multiple authentication methods to obtain desired
authentication properties. This document specifies the Multi-
Authentication Framework Method (MAF) which is a method extension to
SOCKS Version 5 to support the efficient management of composite
authentication protocols composed of more than one authentication
methods. MAF is a client-initiated but server managed framework. MAF
relies upon a trusted Authentication Management Server (AMS) to select
the authentication methods to be invoked, order them as appropriate, and
assign integrity grades to the final authentication after all methods
invoked have been completed.",
URL="http://www.ietf.org/internet-drafts/draft-ietf-aft-socks-maf-00.txt"
}

@TECHREPORT{draft-ietf-applmib-mib,
AUTHOR="C. Kalbfleisch and C. Krupczak and R. Presuhn and J. Saperia",
TITLE="Application Management {MIB}",
TYPE="Internet Draft",
HOWPUBLISHED="draft-ietf-applmib-mib-11",
INSTITUTION="Internet Engineering Task Force",
MONTH=nov,
YEAR=1998,
NOTE="Work in progress",
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 defines objects used for the
management of applications. This MIB complements the System Application
MIB, providing for the management of applications' common attributes
which could not typically be observed without the cooperation of the
software being managed.",
URL="http://www.ietf.org/internet-drafts/draft-ietf-applmib-mib-11.txt"
}

@TECHREPORT{draft-ietf-asid-ldapv3-dynamic,
AUTHOR="Y. Yaacovi and M. Wahl and T. Genovese",
TITLE="Lightweight Directory Access Protocol (v3): Extensions for Dynamic
Directory Services",
TYPE="Internet Draft",
HOWPUBLISHED="draft-ietf-asid-ldapv3-dynamic-08",
INSTITUTION="Internet Engineering Task Force",
MONTH=dec,
YEAR=1998,
NOTE="Work in progress",
ABSTRACT="This document defines the requirements for dynamic directory
services and specifies the format of request and response extended
operations for supporting client-server interoperation in a dynamic
directories environment. The Lightweight Directory Access Protocol
(LDAP) [1] supports lightweight access to static directory services,
allowing relatively fast search and update access. Static directory
services store information about people that persists in its accuracy
and value over a long period of time. Dynamic directory services are
different in that they store information that only persists in its
accuracy and value when it is being periodically refreshed. This
information is stored as dynamic entries in the directory. A typical use
will be a client or a person that is either online - in which case it
has an entry in the directory, or is offline - in which case its entry
disappears from the directory. Though the protocol operations and
attributes used by dynamic directory services are similar to the ones
used for static directory services, clients that store dynamic
information in the directory need to periodically refresh this
information, in order to prevent it from disappearing. If dynamic
entries are not refreshed within a given timeout, they will be removed
from the directory. For example, this will happen if the client that set
them goes offline. A flow control mechanism from the server is also
described that allows a server to inform clients how often they should
refresh their presence.",
URL="ftp://www.ietf.org/internet-drafts/draft-ietf-asid-ldapv3-dynamic-08.txt"
}

@TECHREPORT{draft-ietf-asid-ldapv3-simplepaged,
AUTHOR="C. Weider and T. Howes and A. Herron and A. Anantha",
TITLE="{LDAP} Control Extension for Simple Paged Results Manipulation",
TYPE="Internet Draft",
HOWPUBLISHED="draft-ietf-asid-ldapv3-simplepaged-03",
INSTITUTION="Internet Engineering Task Force",
MONTH=aug,
YEAR=1998,
NOTE="Work in progress",
ABSTRACT="This document describes an LDAPv3 control extension for simple
paging of search results. This control extension allows a client to
control the rate at which an LDAP server returns the results of an LDAP
search operation. This control may be useful when the LDAP client has
limited resources and may not be able to process the entire result set
from a given LDAP query, or when the LDAP client is connected over a
low-bandwidth connection. Other operations on the result set are not
defined in this extension. This extension is not designed to provide
more sophisticated result set management. The key words 'MUST',
'SHOULD', and 'MAY' used in this document are to be interpreted as
described in [bradner97].",
URL="http://www.ietf.org/internet-drafts/draft-ietf-asid-ldapv3-simplepaged-03.txt"
}

@TECHREPORT{draft-ietf-asid-whois-schema,
AUTHOR="J. Knight and P. Faltstrom and M. Hamilton and L. Daigle",
TITLE="{WHOIS++} templates",
TYPE="Internet Draft",
HOWPUBLISHED="draft-ietf-asid-whois-schema-03",
INSTITUTION="Internet Engineering Task Force",
MONTH=mar,
YEAR=1998,
NOTE="Work in progress",
ABSTRACT="WHOIS++ is a simple Internet search and retrieval protocol,
specified in [1], which allows clients and servers to exchange
structured data objects known as templates. In the interests of
interoperability it is desirable to have a common base schema for these
templates. This document suggests a schema drawn from implementation and
deployment experience to date with WHOIS++.",
URL="http://www.ietf.org/internet-drafts/draft-ietf-asid-whois-schema-03.txt"
}

@TECHREPORT{draft-ietf-asid-whois-url,
AUTHOR="M. Hamilton",
TITLE="{WHOIS++} {URL} Specification",
TYPE="Internet Draft",
HOWPUBLISHED="draft-ietf-asid-whois-url-02",
INSTITUTION="Internet Engineering Task Force",
MONTH=mar,
YEAR=1998,
NOTE="Work in progress",
ABSTRACT="This document defines a new Uniform Resource Locator (URL)
scheme ''whois++'', which provides a convention within the URL framework
for referring to WHOIS++ servers and the data held within them.",
URL="http://www.ietf.org/internet-drafts/draft-ietf-asid-whois-url-02.txt"
}

@TECHREPORT{draft-ietf-asid-whoispp,
AUTHOR="P. Faltstrom and L. Daigle and S. Newell",
TITLE="Architecture of the {WHOIS++} service",
TYPE="Internet Draft",
HOWPUBLISHED="draft-ietf-asid-whoispp-02",
INSTITUTION="Internet Engineering Task Force",
MONTH=mar,
YEAR=1998,
NOTE="Work in progress",
ABSTRACT="This document describes Whois++, an extension to the trivial
WHOIS service described in RFC 954 to permit WHOIS-like servers to make
available more structured information to the Internet. We describe an
extension to the simple WHOIS data model and query protocol and a
companion extensible, distributed indexing service. A number of options
have also been added such as the use of multiple languages and character
sets, more advanced search expressions, structured data and a number of
other useful features. An optional authentication mechanism for
protecting all or part of the associated Whois++ information database
from unauthorized access is also described.",
URL="http://www.ietf.org/internet-drafts/draft-ietf-asid-whoispp-02.txt"
}

@TECHREPORT{draft-ietf-atommib-acct,
AUTHOR="K. McCloghrie and J. Heinanen and W. Greene and A. Prasad",
TITLE="Managed Objects for Controlling the Collection and Storage of Accounting
Information for {Connection-Oriented} Networks",
TYPE="Internet Draft",
HOWPUBLISHED="draft-ietf-atommib-acct-06",
INSTITUTION="Internet Engineering Task Force",
MONTH=oct,
YEAR=1998,
NOTE="Work in progress",
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
controlling the collection and storage of accounting information for
connection-oriented networks such as ATM. The accounting data is
collected into files for later retrieval via a file transfer protocol.
For information on data which can be collected for ATM networks, see
[19].",
URL="http://www.ietf.org/internet-drafts/draft-ietf-atommib-acct-06.txt"
}

@TECHREPORT{draft-ietf-atommib-atm1ng,
AUTHOR="K. Tesink",
TITLE="Definitions of Managed Objects for {ATM} Management",
TYPE="Internet Draft",
HOWPUBLISHED="draft-ietf-atommib-atm1ng-06",
INSTITUTION="Internet Engineering Task Force",
MONTH=nov,
YEAR=1998,
NOTE="Work in progress",
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 objects used for managing
ATM-based interfaces, devices, networks and services. This memo replaces
RFC1695[24].Changes relative to RFC1695 are summarized in the MIB
module's REVISION clause. Textual Conventions used in this MIB are
defined in [6] and [19].",
URL="http://www.ietf.org/internet-drafts/draft-ietf-atommib-atm1ng-06.txt"
}

@TECHREPORT{draft-ietf-atommib-atm2TC,
AUTHOR="M. Noto and E. Spiegel and K. Tesink",
TITLE="Definitions of Textual Conventions and {OBJECT-IDENTITIES} for {ATM}
Management",
TYPE="Internet Draft",
HOWPUBLISHED="draft-ietf-atommib-atm2TC-09",
INSTITUTION="Internet Engineering Task Force",
MONTH=nov,
YEAR=1998,
NOTE="Work in progress",
ABSTRACT="This memo describes Textual Conventions and OBJECT-IDENTITIES
used for managing ATM-based interfaces, devices, networks and services.",
URL="http://www.ietf.org/internet-drafts/draft-ietf-atommib-atm2TC-09.txt"
}

@TECHREPORT{draft-ietf-atommib-atmacct,
AUTHOR="K. McCloghrie and J. Heinanen and W. Greene and A. Prasad",
TITLE="Accounting Information for {ATM} Networks",
TYPE="Internet Draft",
HOWPUBLISHED="draft-ietf-atommib-atmacct-03",
INSTITUTION="Internet Engineering Task Force",
MONTH=oct,
YEAR=1998,
NOTE="Work in progress",
ABSTRACT="This memo defines a portion of the Management Information Base
(MIB) for use with network management protocols in the Internet
community. A separate memo [16] defines managed objects, in a manner
independent of the type of network, for controlling the selection,
collection and storage of accounting information into files for later
retrieval via a file transfer protocol. This memo defines a set of
ATM-specific accounting information which can be collected for
connections on ATM networks.",
URL="http://www.ietf.org/internet-drafts/draft-ietf-atommib-atmacct-03.txt"
}

@TECHREPORT{draft-ietf-atommib-perfhistTC,
AUTHOR="K. Tesink",
TITLE="Textual Conventions for {MIB} Modules Using Performance History Based on 15
Minute Intervals",
TYPE="Internet Draft",
HOWPUBLISHED="draft-ietf-atommib-perfhistTC-05",
INSTITUTION="Internet Engineering Task Force",
MONTH=nov,
YEAR=1998,
NOTE="Work in progress",
ABSTRACT="This document defines a set of Textual Conventions for MIB
modules which make use of performance history data based on 15 minute
intervals.",
URL="http://www.ietf.org/internet-drafts/draft-ietf-atommib-perfhistTC-05.txt"
}

@TECHREPORT{draft-ietf-atommib-sonetng,
AUTHOR="K. Tesink",
TITLE="Definitions of Managed Objects for the {SONET/SDH} Interface Type",
TYPE="Internet Draft",
HOWPUBLISHED="draft-ietf-atommib-sonetng-05",
INSTITUTION="Internet Engineering Task Force",
MONTH=nov,
YEAR=1998,
NOTE="Work in progress",
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 Synchronous
Optical Network/Synchronous Digital Hierarchy (SONET/SDH) interfaces.
This document is a companion to the documents that define Managed
Objects for the DS1/E1/DS2/E2 and DS3/E3 Interface Types [24][25].
Textual Conventions used in this MIB are defined in [6] and [36]. This
memo replaces RFC1595 [30]. Changes relative to RFC1595 are summarized
in the MIB module's REVISION clause.",
URL="http://www.ietf.org/internet-drafts/draft-ietf-atommib-sonetng-05.txt"
}

@TECHREPORT{draft-ietf-avt-aggregation,
AUTHOR="J. Rosenberg and Henning Schulzrinne",
TITLE="An {RTP} Payload Format for User Multiplexing",
TYPE="Internet Draft",
HOWPUBLISHED="draft-ietf-avt-aggregation-00",
INSTITUTION="Internet Engineering Task Force",
MONTH=may,
YEAR=1998,
NOTE="Work in progress",
ABSTRACT="This memo describes an RTP payload format for multiplexing
data from multiple users into a single RTP packet. Such multiplexing is
especially useful for transporting voice data between Internet telephony
gateways. It causes significant reductions in header overheads and
improves scalability.",
URL="http://www.ietf.org/internet-drafts/draft-ietf-avt-aggregation-00.txt"
}

@TECHREPORT{draft-ietf-avt-crtp,
AUTHOR="V. Jacobson and S. Casner",
TITLE="Compressing {IP/UDP/RTP} Headers for {Low-Speed} Serial Links",
TYPE="Internet Draft",
HOWPUBLISHED="draft-ietf-avt-crtp-05",
INSTITUTION="Internet Engineering Task Force",
MONTH=jul,
YEAR=1998,
NOTE="Work in progress",
ABSTRACT="This document describes a method for compressing the headers
of IP/UDP/RTP datagrams to reduce overhead on low-speed serial links. In
many cases, all three headers can be compressed to 2-4 bytes. Comments
are solicited and should be addressed to the working group mailing list
rem-conf(at)es.net and/or the author(s).",
URL="http://www.ietf.org/internet-drafts/draft-ietf-avt-crtp-05.txt"
}

@TECHREPORT{draft-ietf-avt-dtmf,
AUTHOR="Henning Schulzrinne",
TITLE="{RTP} Payload for {DTMF} Digits",
TYPE="Internet Draft",
HOWPUBLISHED="draft-ietf-avt-dtmf-01",
INSTITUTION="Internet Engineering Task Force",
MONTH=nov,
YEAR=1998,
NOTE="Work in progress",
ABSTRACT="This memo describes how to carry dual-tone multifrequency
(DTMF) signaling and other tone signals in RTP packets.",
URL="http://www.ietf.org/internet-drafts/draft-ietf-avt-dtmf-01.txt"
}

@TECHREPORT{draft-ietf-avt-germ,
AUTHOR="M. Handley",
TITLE="{GeRM:} Generic {RTP} Multiplexing",
TYPE="Internet Draft",
HOWPUBLISHED="draft-ietf-avt-germ-00.txt,.ps",
INSTITUTION="Internet Engineering Task Force",
MONTH=nov,
YEAR=1998,
NOTE="Work in progress",
ABSTRACT="This document describes GeRM, an RTP payload format for
generic multiplexing of multiple RTP streams. This document is a product
of the Audio/Video Transport (AVT) working group of the Internet
Engineering Task Force. Comments are solicited and should be addressed
to the working group's mailing list at rem-conf(at)es.net and/or the
author.",
URL="http://www.ietf.org/internet-drafts/draft-ietf-avt-germ-00.txt,.ps"
}

@TECHREPORT{draft-ietf-avt-mux-rtp,
AUTHOR="B. Subbiah and S. Sengodan",
TITLE="User Multiplexing in {RTP} payload between {IP} Telephony Gateways",
TYPE="Internet Draft",
HOWPUBLISHED="draft-ietf-avt-mux-rtp-00",
INSTITUTION="Internet Engineering Task Force",
MONTH=aug,
YEAR=1998,
NOTE="Work in progress",
ABSTRACT="This draft proposes a method to multiplex a number of low bit
rate audio streams (upto 256) into a single RTP/UDP/IP connection
between IP telephony gateways. Audio samples from different users are
assembled into an RTP payload thus reducing the overhead of RTP/UDP/IP
headers. To identify users sharing a single RTP/UDP/IP connection, a 2
byte MINI-Header is proposed. A channel negotiation procedure to assign
and release channels on a single UDP connection between gateways is
described.",
URL="http://www.ietf.org/internet-drafts/draft-ietf-avt-mux-rtp-00.txt"
}

@TECHREPORT{draft-ietf-avt-muxissues,
AUTHOR="J. Rosenberg and Henning Schulzrinne",
TITLE="Issues and Options for {RTP} Multiplexing",
TYPE="Internet Draft",
HOWPUBLISHED="draft-ietf-avt-muxissues-00",
INSTITUTION="Internet Engineering Task Force",
MONTH=oct,
YEAR=1998,
NOTE="Work in progress",
ABSTRACT="This memorandum discusses the issues and options involved in
the design of a new transport protocol for multiplexed voice within a
single packet. The intended application is the interconnection of
devices which provide trunking or long distance telephone service over
the Internet. Such devices have many voice connections simultaneously
between them. Multiplexing them into the same connection improves on the
efficiency, enables the use of low bitrate voice codecs, and improves
scalability. Options and issues con- cerning timestamping, payload type
identification, length indication, and channel identification are
discussed. Sev- eral possible header formats are identified, and their
efficiencies are compared.",
URL="http://www.ietf.org/internet-drafts/draft-ietf-avt-muxissues-00.txt"
}

@TECHREPORT{draft-ietf-avt-redundancy-revised,
AUTHOR="C. Perkins and I. Kouvelas and O. Hodson and V. Hardman and M. Handley and
J. Bolot and A. Vega-Garcia and S. Fosse-Parisis",
TITLE="{RTP} Payload for Redundant Audio Data",
TYPE="Internet Draft",
HOWPUBLISHED="draft-ietf-avt-redundancy-revised-00",
INSTITUTION="Internet Engineering Task Force",
MONTH=aug,
YEAR=1998,
NOTE="Work in progress",
ABSTRACT="This document describes a payload format for use with the
real-time transport protocol (RTP), version 2, for encoding redundant
audio data. The primary motivation for the scheme described herein is
the development of audio conferencing tools for use with lossy packet
networks such as the Internet Mbone, although this scheme is not limited
to such applications.",
URL="http://www.ietf.org/internet-drafts/draft-ietf-avt-redundancy-revised-00.txt"
}

@TECHREPORT{draft-ietf-avt-reedsolomon,
AUTHOR="J. Rosenberg and Henning Schulzrinne",
TITLE="An {RTP} Payload Format for Reed Solomon Codes",
TYPE="Internet Draft",
HOWPUBLISHED="draft-ietf-avt-reedsolomon-00",
INSTITUTION="Internet Engineering Task Force",
MONTH=nov,
YEAR=1998,
NOTE="Work in progress",
ABSTRACT="This document specifies a payload format for forward error
correction of media encapsulated in RTP using Reed Solomon codes. The
payload format allows end systems to transmit using arbitrary block
lengths and codes. It also allows for the recovery of both the payload
and critical RTP header fields. Since FEC is sent as a separate stream,
it is backwards compatible with non-FEC capable hosts, so that receivers
which do not wish to implement FEC can just ignore the extensions.",
URL="http://www.cs.columbia.edu/~hgs/rtp/drafts/draft-ietf-avt-reedsolomon-00.txt"
}

@TECHREPORT{draft-ietf-avt-rtp-h263-video,
AUTHOR="C. Maciocco and J. Ott and C. Bormann and C. Zhu and L. Cline and D. Newell
and G. Sullivan and G. Deisher",
TITLE="{RTP} Payload Format for the 1998 Version of {ITU-T} Rec. {H.263} Video
{(H.263+)}",
TYPE="Internet Draft",
HOWPUBLISHED="draft-ietf-avt-rtp-h263-video-02",
INSTITUTION="Internet Engineering Task Force",
MONTH=may,
YEAR=1998,
NOTE="Work in progress",
ABSTRACT="This document specifies an RTP payload header format
applicable to the transmission of video streams generated based on the
1998 version of ITU-T Recommendation H.263 [4]. Because the 1998 version
of H.263 is a superset of the 1996 syntax, this format can also be used
with the 1996 version of H.263 [3], and is recommended for this use by
new implementations. This format does not replace RFC 2190, which
continues to be used by existing implementations, and may be required
for backward compatibility in new implementations. Implementations using
the new features of the 1998 version of H.263 shall use the format
described in this document. The 1998 version of ITU-T Recommendation
H.263 added numerous coding options to improve codec performance over
the 1996 version. The 1998 version is referred to as H.263+ in this
document. Among the new options, the ones with the biggest impact on the
RTP payload specification and the error resilience of the video content
are the slice structured mode, the independent segment decoding mode,
the reference picture selection mode, and the scalability mode. This
section summarizes the impact of these new coding options on
packetization. Refer to [4] for more information on coding options.",
URL="http://www.ietf.org/internet-drafts/draft-ietf-avt-rtp-h263-video-02.txt"
}

@TECHREPORT{draft-ietf-avt-telephone-tones,
AUTHOR="S. Petrack",
TITLE="{RTP} Payloads for Telephone Signal Events",
TYPE="Internet Draft",
HOWPUBLISHED="draft-ietf-avt-telephone-tones-00",
INSTITUTION="Internet Engineering Task Force",
MONTH=nov,
YEAR=1998,
NOTE="Work in progress",
ABSTRACT="This note describes two RTP payload formats for in-band
telephony signal events (TSE) such as DTMF, dial-tone, ring-tone,
off-hook, SIT, etc. One payload is designed to carry a named signal, and
the other is designed carry a compact representation of actual audio
waveform cadence to be played. The two formats are independent, but they
can be used together very usefully within redundant audio payloads; this
enables highly efficient and robust transport of telephony network
signal events along with a representation of the actual audio media
associated to the signal events. Acknowledgements: This internet draft
is an extension of H. Schulzrinne's draft ietf-avt-dtmf-00.txt and
borrows heavily from it (including copying actual text). The main
extensions appearing in this draft are as follows: a) many other
telephony call progress tones and signal events have been added to the
original DTMF and flash-hook of ietf-avt-dtmf-00.txt (an attempt has
been made to align this with [MGCP] and [E.180 supp2] b) a second
payload is defined which carries a highly compact frequency
representation of the audio waveform of the signal; c) a few
clarifications about reliability and redundancy, including how the two
payloads will work together. Acknowledgement is also due to [MGCP]; part
of this draft is an attempt to use RTP to provide the signal transport
required by MGCP, in a way which can be reused by a large class of
applications.",
URL="http://www.ietf.org/internet-drafts/draft-ietf-avt-telephone-tones-00.txt"
}

@TECHREPORT{draft-ietf-avt-X11-new,
AUTHOR="L. Gannoun",
TITLE="{RTP} Payload Format for X Protocol Media Streams",
TYPE="Internet Draft",
HOWPUBLISHED="draft-ietf-avt-X11-new-00",
INSTITUTION="Internet Engineering Task Force",
MONTH=mar,
YEAR=1998,
NOTE="Work in progress",
ABSTRACT="This document specifies the payload format for encapsulating
X-protocol streams in the Realtime Transport Protocol (RTP). This
specification is intended for X-protocol media streams that are not
already handled by other RTP payload specifications. This specification
gives details of the payload format of X-protocol data requests that are
carried over RTP/UDP/IP in a shared window session. Multiple X protocol
requests can be carried over an RTP packet as well as one X protocol
request can be carried over multiple RTP packets. a shared window header
is defined within the RTP payload to carry X protocol media requests. An
RTCP join and RTP reply packets are specified to allow a latecomer to
join an on-going session. This specification is intended for streaming
stored X Window protocol data as well as live X protocol data requests.",
URL="http://www.ietf.org/internet-drafts/draft-ietf-avt-X11-new-00.txt"
}

@TECHREPORT{draft-ietf-calsch-scap,
AUTHOR="S. Reddy",
TITLE="Web based Simple Calendar Access Protocol - {SCAP}",
TYPE="Internet Draft",
HOWPUBLISHED="draft-ietf-calsch-scap-00",
INSTITUTION="Internet Engineering Task Force",
MONTH=apr,
YEAR=1998,
NOTE="Work in progress",
ABSTRACT="Distributed calendaring is gradually becoming more demanding
than standalone calendaring and scheduling. The use of calendaring and
scheduling has grown exponentially and enterprise and inter- enterprise
business has become so dependent on group scheudling applications. But
there is no Internet standard to provide interoperability among various
calendaring applications. Consequently, user need to install different
conduit programs to access these calendaring stores. This memo proposes
a HTTP based simple calendaring access protocol which allows web, email
and any HTTP compliant clients to access and manipulate calendar store.
The motivation for this proposal is the expanded scope and diversity of
the World Wide Web. The World Wide Web provides a simple and effective
means for users to search, browse, retrieve, and publish information of
their own available for others. Now that Web browsers and servers are
ubiquitous on the Internet, it is worthwhile to use HTTP as transport
protocol and XML to encode calendar objects. The power and extensibility
of XML allows us to represent calendar data objects as well-formed XML
documents. Simple Calendar Access Protocol(SCAP) allows exchanging
calendaring information between scheduling systems using the Hypertext
Transfer Protocol (HTTP). This allows users to schedule meetings with
anyone else, no matter what scheduling software they use. This document
specifies a set of methods, headers, and content-types ancillary to
HTTP/1.1 for the management of calender properties, creation and
management of calendar objects, and namespace manipulation.",
URL="http://www.ietf.org/internet-drafts/draft-ietf-calsch-scap-00.txt"
}

@TECHREPORT{draft-ietf-cat-gssv2-cbind,
AUTHOR="J. Wray",
TITLE="Generic Security Service {API} Version 2 : C-bindings",
TYPE="Internet Draft",
HOWPUBLISHED="draft-ietf-cat-gssv2-cbind-08",
INSTITUTION="Internet Engineering Task Force",
MONTH=nov,
YEAR=1998,
NOTE="Work in progress",
ABSTRACT="This draft document specifies C language bindings for Version
2 of the Generic Security Service Application Program Interface
(GSS-API), which is described at a language-independent conceptual level
in other drafts [GSSAPI]. It revises RFC-1509, making specific
incremental changes in response to implementation experience and liaison
requests. It is intended, therefore, that this draft or a successor
version thereof will become the basis for subsequent progression of the
GSS-API specification on the standards track. The Generic Security
Service Application Programming Interface provides security services to
its callers, and is intended for implementation atop a variety of
underlying cryptographic mechanisms. Typically, GSS-API callers will be
application protocols into which security enhancements are integrated
through invocation of services provided by the GSS-API. The GSS-API
allows a caller application to authenticate a principal identity
associated with a peer application, to delegate rights to a peer, and to
apply security services such as confidentiality and integrity on a
per-message basis.",
URL="http://www.ietf.org/internet-drafts/draft-ietf-cat-gssv2-cbind-08.txt"
}

@TECHREPORT{draft-ietf-cat-kerb-chg-password,
AUTHOR="M. Horowitz",
TITLE="Kerberos Change Password Protocol",
TYPE="Internet Draft",
HOWPUBLISHED="draft-ietf-cat-kerb-chg-password-01",
INSTITUTION="Internet Engineering Task Force",
MONTH=mar,
YEAR=1998,
NOTE="Work in progress",
ABSTRACT="The Kerberos V5 protocol [RFC1510] does not describe any
mechanism for users to change their own passwords. In order to promote
interoperability between workstations, personal computers, terminal
servers, routers, and KDC's from multiple vendors, a common password
changing protocol is required.",
URL="http://www.ietf.org/internet-drafts/draft-ietf-cat-kerb-chg-password-01.txt"
}

@TECHREPORT{draft-ietf-cat-kerberos-passwords,
AUTHOR="C. Neuman and G. Zorn and J. Trostle and K. Hornstein",
TITLE="Integrating Single-use Authentication Mechanisms with Kerberos",
TYPE="Internet Draft",
HOWPUBLISHED="draft-ietf-cat-kerberos-passwords-04",
INSTITUTION="Internet Engineering Task Force",
MONTH=nov,
YEAR=1998,
NOTE="Work in progress",
ABSTRACT="This document defines extensions to the Kerberos protocol
specifi- cation [RFC1510] which provide a method by which a variety of
single-use authentication mechanisms may be supported within the
protocol. The method defined specifies a standard fashion in which the
preauthentication data and error data fields in Kerberos mes- sages may
be used to support single-use authentication mechanisms.",
URL="http://www.ietf.org/internet-drafts/draft-ietf-cat-kerberos-passwords-04.txt"
}

@TECHREPORT{draft-ietf-cat-kerberos-pk-recovery,
AUTHOR="J. Trostle",
TITLE="Public Key Cryptography for {KDC} Recovery in Kerberos {V5}",
TYPE="Internet Draft",
HOWPUBLISHED="draft-ietf-cat-kerberos-pk-recovery-01",
INSTITUTION="Internet Engineering Task Force",
MONTH=nov,
YEAR=1998,
NOTE="Work in progress",
ABSTRACT="This document defines extensions to the Kerberos protocol
specification (RFC 1510, 'The Kerberos Network Authentication Service
(V5)', September 1993) to enable the recovery of a compromised Kerberos
V5 KDC using public key cryptography. The document specifies the
recovery protocol which uses preauthentication data fields and error
data fields in Kerberos messages to transport recovery data.",
URL="http://www.ietf.org/internet-drafts/draft-ietf-cat-kerberos-pk-recovery-01.txt"
}

@TECHREPORT{draft-ietf-cat-mpaker,
AUTHOR="L. Harn and Y. Xu",
TITLE="The {Multiple-Path} Authentication of Kerberos {(MPAKER)}",
TYPE="Internet Draft",
HOWPUBLISHED="draft-ietf-cat-mpaker-00",
INSTITUTION="Internet Engineering Task Force",
MONTH=jan,
YEAR=1998,
NOTE="Work in progress",
ABSTRACT="This draft proposes an authentication scheme that improves the
efficiency and security without losing features of the standard Kerberos
and other extension schemes. Instead of completely replacing those
schemes, the new scheme can be integrated with them to provide
multiple-path authentication for Kerberos.",
URL="http://www.ietf.org/internet-drafts/draft-ietf-cat-mpaker-00.txt"
}

@TECHREPORT{draft-ietf-cat-pktapp,
AUTHOR="C. Neuman and M. Hur and A. Medvinsky and A. Medvinsky",
TITLE="Public Key Utilizing Tickets for Application Servers {(PKTAPP)}",
TYPE="Internet Draft",
HOWPUBLISHED="draft-ietf-cat-pktapp-01",
INSTITUTION="Internet Engineering Task Force",
MONTH=mar,
YEAR=1998,
NOTE="Work in progress",
ABSTRACT="Public key based Kerberos for Distributed Authentication[1],
(PKDA) proposed by Sirbu and Chuang, describes PK based authentication
that eliminates the use of a centralized key distribution center while
retaining the advantages of Kerberos tickets. This draft describes how,
without any modification, the PKINIT specification[2] may be used to
implement the ideas introduced in PKDA. The benefit is that only a
single PK Kerberos extension is needed to address the goals of PKINIT \&
PKDA.",
URL="http://www.ietf.org/internet-drafts/draft-ietf-cat-pktapp-01.txt"
}

@TECHREPORT{draft-ietf-cat-rfc2078bis,
AUTHOR="J. Linn",
TITLE="Generic Security Service Application Program Interface Version {2,} Update
1",
TYPE="Internet Draft",
HOWPUBLISHED="draft-ietf-cat-rfc2078bis-08",
INSTITUTION="Internet Engineering Task Force",
MONTH=dec,
YEAR=1998,
NOTE="Work in progress",
ABSTRACT="The Generic Security Service Application Program Interface
(GSS-API), Version 2, as defined in [RFC-2078], provides security
services to callers in a generic fashion, supportable with a range of
underlying mechanisms and technologies and hence allowing source-level
portability of applications to different environments. This
specification defines GSS-API services and primitives at a level
independent of underlying mechanism and programming language
environment, and is to be complemented by other, related specifications:
documents defining specific parameter bindings for particular language
environments documents defining token formats, protocols, and procedures
to be implemented in order to realize GSS-API services atop particular
security mechanisms This Internet-Draft revises [RFC-2078], making
specific, incremental changes in response to implementation experience
and liaison requests. It is intended, therefore, that this draft or a
successor version thereto will become the basis for subsequent
progression of the GSS-API specification on the standards track.",
URL="ftp://www.ietf.org/internet-drafts/draft-ietf-cat-rfc2078bis-08.txt"
}

@TECHREPORT{draft-ietf-cat-xgssapi-acc-cntrl,
AUTHOR="T. Parker and B. Pinkas",
TITLE="Extended Generic Security Service {APIs:} {XGSS-APIs} Access control and
delegation extensions",
TYPE="Internet Draft",
HOWPUBLISHED="draft-ietf-cat-xgssapi-acc-cntrl-03",
INSTITUTION="Internet Engineering Task Force",
MONTH=nov,
YEAR=1998,
NOTE="Work in progress",
ABSTRACT="The Generic Security Service Application Program Interface
(GSS- API), as defined in RFC-1508, provides security services to
callers in a generic fashion, supportable with a range of underlying
mechanisms and technologies and hence allowing source-level portability
of applications to different environments. It defines GSS-API services
and primitives at a level independent of underlying mechanism and
programming language environment. The GSSAPI allows a caller application
to authenticate a principal identity associated with a peer application,
to delegate rights to a peer, and to apply security services such as
confidentiality and integrity on a per-message basis. The primitives of
the GSS-API do not currently allow support of security attributes other
than a single identity and do not allow fine control of delegation. The
additional primitives described in this document provide support for: *
the exchange of a variety of security attributes, and the construction
of authorization functions using these attributes, including delegated
ones, (attribute handling support functions), * fine control over
delegation by allowing specification of the delegation method, the
acceptor(s) of a security context, their type and the restrictions that
may apply (acceptor control and support functions).",
URL="http://www.ietf.org/internet-drafts/draft-ietf-cat-xgssapi-acc-cntrl-03.txt"
}

@TECHREPORT{draft-ietf-conneg-feature-algebra,
AUTHOR="G. Klyne",
TITLE="An algebra for describing media feature sets",
TYPE="Internet Draft",
HOWPUBLISHED="draft-ietf-conneg-feature-algebra-03",
INSTITUTION="Internet Engineering Task Force",
MONTH=aug,
YEAR=1998,
NOTE="Work in progress",
ABSTRACT="A number of Internet application protocols have a need to
provide content negotiation for the resources with which they interact
[1]. A framework for such negotiation is described in [2]. Part of this
framework is a way to describe the range of media features which can be
handled by the sender, recipient or document transmission format of a
message. A format for a vocabulary of individual media features and
procedures for registering media features are presented in [3]. This
document describes an algebra and syntax that can be used to define
feature sets which are formed from combinations and relations involving
individual media features. Such feature sets are used to describe the
media feature handling capabilities of message senders, recipients and
file formats. This document also outlines an algorithm for feature set
matching.",
URL="http://www.ietf.org/internet-drafts/draft-ietf-conneg-feature-algebra-03.txt"
}

@TECHREPORT{draft-ietf-conneg-feature-reg,
AUTHOR="T. Hardie and K. Holtman and A. Mutz",
TITLE="Media Feature Tag Registration Procedure",
TYPE="Internet Draft",
HOWPUBLISHED="draft-ietf-conneg-feature-reg-03",
INSTITUTION="Internet Engineering Task Force",
MONTH=jul,
YEAR=1998,
NOTE="Work in progress",
ABSTRACT="Recent Internet applications, such as the World Wide Web, tie
together a great diversity in data formats, client and server platforms,
and communities. This has created a need for media feature descriptions
and negotiation mechanisms in order to identify and reconcile the form
of information to the capabilities and preferences of the parties
involved. Extensible media feature identification and negotiation
mechanisms require a common vocabulary in order to positively identify
media features. A registration process and authority for media features
is defined with the intent of sharing this vocabulary between
communicating parties. In addition, a URI tree is defined to enable
sharing of media feature definitions without registration. This document
defines a registration procedure which uses the Internet Assigned
Numbers Authority (IANA) as a central registry for the media feature
vocabulary.",
URL="http://www.ietf.org/internet-drafts/draft-ietf-conneg-feature-reg-03.txt"
}

@TECHREPORT{draft-ietf-conneg-feature-syntax,
AUTHOR="G. Klyne",
TITLE="A syntax for describing media feature sets",
TYPE="Internet Draft",
HOWPUBLISHED="draft-ietf-conneg-feature-syntax-04",
INSTITUTION="Internet Engineering Task Force",
MONTH=dec,
YEAR=1998,
NOTE="Work in progress",
ABSTRACT="A number of Internet application protocols have a need to
provide content negotiation for the resou