<?xml version='1.0'?>
<!DOCTYPE rfc SYSTEM 'rfc2629.dtd'>

<?rfc private=' '?>
<?rfc symrefs='yes'?>
<?rfc topblock='no'?>

<rfc>
<front>
<title abbrev='The (unofficial) RFC Index'>The (unofficial) RFC Index (as of January 23, 2004)</title>

<date month='January' day='23' year='2004' />
</front>

<middle />

<back>
<references title='rfc-index'>


<reference target2="reference.RFC.0001.xml" anchor="RFC0001">
<front>
<title>Host Software</title>
<author fullname="Steve Crocker" initials="S." surname="Crocker">
<organization>University California Los Angeles (UCLA)</organization>
</author>

<date year="1969" day="7" month="April" />
</front>

<seriesInfo value="1" name="RFC" />
</reference>


<reference target2="reference.RFC.0002.xml" anchor="RFC0002">
<front>
<title>Host software</title>
<author fullname="Bill Duvall" initials="B." surname="Duvall">
<organization>Stanford Research Institute (SRI)</organization>
</author>

<date year="1969" day="9" month="April" />
</front>

<seriesInfo value="2" name="RFC" />
</reference>


<reference target2="reference.RFC.0003.xml" anchor="RFC0003">
<front>
<title>Documentation conventions</title>
<author fullname="Steve Crocker" initials="S." surname="Crocker">
<organization>University California Los Angeles (UCLA)</organization>
</author>

<date year="1969" day="9" month="April" />

<abstract>
<t>The Network Working Group seems to consist of Steve Carr of Utah, Jeff Rulifson and Bill Duvall at SRI, and Steve Crocker and Gerard Deloche at UCLA.  Membership is not closed.</t>

<t>The Network Working Group (NWG) is concerned with the HOST software, the strategies for using the network, and initial experiments with the network.</t>

<t>Documentation of the NWG's effort is through notes such as this.  Notes may be produced at any site by anybody and included in this series.</t>
</abstract>
</front>

<seriesInfo value="3" name="RFC" />
</reference>


<reference target2="reference.RFC.0004.xml" anchor="RFC0004">
<front>
<title>Network timetable</title>
<author fullname="Elmer B. Shapiro" initials="E." surname="Shapiro">
<organization>Stanford Research Institute (SRI) International</organization>
</author>

<date year="1969" day="24" month="March" />
</front>

<seriesInfo value="4" name="RFC" />
</reference>


<reference target2="reference.RFC.0005.xml" anchor="RFC0005">
<front>
<title>Decode Encode Language (DEL)</title>
<author fullname="Jeff Rulifson" initials="J." surname="Rulifson">
<organization>Stanford Research Institute (SRI) International</organization>

<address>
<postal>
<street>333 Ravenswood</street>
<city>Menlo Park</city>
<region>CA</region>
<code>94025</code>
<country>US</country>
</postal>

<phone>+1 415 326 6200 x4116</phone>
</address>
</author>

<date year="1969" day="2" month="June" />

<abstract>
<t>The Decode-Encode Language (DEL) is a machine independent language tailored to two specific computer network tasks:</t>

<t>accepting input codes from interactive consoles, giving immediate feedback, and packing the resulting information into message  packets for network transmissin.</t>

<t>and accepting message packets from another computer, unpacking them, building trees of display information, and sending other information to the user at his interactive station.</t>

<t>This is a working document for the evolution of the DEL language. Comments should be made through Jeff Rulifson at SRI.</t>
</abstract>
</front>

<seriesInfo value="5" name="RFC" />
</reference>


<reference target2="reference.RFC.0006.xml" anchor="RFC0006">
<front>
<title>Conversation with Bob Kahn</title>
<author fullname="Steve Crocker" initials="S." surname="Crocker">
<organization>University California Los Angeles (UCLA)</organization>
</author>

<date year="1969" day="10" month="April" />

<abstract>
<t>I talked with Bob Kahn at BB&amp;N yesterday.  We talked about code conversion in the IMP's, the IMP-HOST communication and HOST software.</t>
</abstract>
</front>

<seriesInfo value="6" name="RFC" />
</reference>


<reference target2="reference.RFC.0007.xml" anchor="RFC0007">
<front>
<title>Host-IMP interface</title>
<author fullname="G. Deloche" initials="G." surname="Deloche">
<organization />
</author>

<date year="1969" day="1" month="May" />
</front>

<seriesInfo value="7" name="RFC" />
<format octets="13408" type="TXT" target="ftp://ftp.isi.edu/in-notes/rfc7.txt" />
</reference>


<reference target2="reference.RFC.0008.xml" anchor="RFC0008">
<front>
<title>Functional specifications for the ARPA Network</title>
<author fullname="G. Deloche" initials="G." surname="Deloche">
<organization />
</author>

<date year="1969" day="5" month="May" />
</front>

<seriesInfo value="8" name="RFC" />
</reference>


<reference target2="reference.RFC.0009.xml" anchor="RFC0009">
<front>
<title>Host software</title>
<author fullname="G. Deloche" initials="G." surname="Deloche">
<organization />
</author>

<date year="1969" day="1" month="May" />
</front>

<seriesInfo value="9" name="RFC" />
</reference>


<reference target2="reference.RFC.0010.xml" anchor="RFC0010">
<front>
<title>Documentation conventions</title>
<author fullname="Steve Crocker" initials="S." surname="Crocker">
<organization>University of California, Los Angeles (UCLA)</organization>
</author>

<date year="1969" day="29" month="July" />

<abstract>
<t>This note is a revision of NWG/RFC #3</t>

<t>The Network Working Group seems to consist of Steve Carr at Utah, Elmer Shapiro and Bill English SRI, Steve Crocker at UCLA, John Haefner at RAND, Paul Rovner and Jim Curry at Lincoln Labs.  Membership is not closed.</t>

<t>The Network Working Group (NWG  is concerned with the HOST software, the strategies for using the network, and initial experience with the network.</t>

<t>Documentation of the NWG's effort is through notes such as this.  Notes may be produced at any site by anybody and included in this series.</t>
</abstract>
</front>

<seriesInfo value="10" name="RFC" />
</reference>


<reference target2="reference.RFC.0011.xml" anchor="RFC0011">
<front>
<title>Implementation of the Host-Host software procedures in GORDO</title>
<author fullname="G. Deloche" initials="G." surname="Deloche">
<organization />
</author>

<date year="1969" day="1" month="August" />
</front>

<seriesInfo value="11" name="RFC" />
</reference>


<reference target2="reference.RFC.0012.xml" anchor="RFC0012">
<front>
<title>IMP-Host interface flow diagrams</title>
<author fullname="M. Wingfield" initials="M." surname="Wingfield">
<organization />
</author>

<date year="1969" day="26" month="August" />
</front>

<seriesInfo value="12" name="RFC" />
<format octets="177" type="TXT" target="ftp://ftp.isi.edu/in-notes/rfc12.txt" />
<format octets="1489750" type="PS" target="ftp://ftp.isi.edu/in-notes/rfc12.ps" />
<format octets="1163721" type="PDF" target="ftp://ftp.isi.edu/in-notes/rfc12.pdf" />
</reference>


<reference target2="reference.RFC.0013.xml" anchor="RFC0013">
<front>
<title>Zero Text Length EOF Message</title>
<author fullname="Vint Cerf" initials="V." surname="Cerf">
<organization>University California Los Angeles (UCLA)</organization>
</author>

<date year="1969" day="20" month="August" />

<abstract>
<t>Referring to NWG/RFC: 11, it appears that file transmissions over auxiliary connections will require some mechanism to specify "END-OF-FILE."  It is proposed that a length 0 (zero) message be used for this purpose.</t>
</abstract>
</front>

<seriesInfo value="13" name="RFC" />
</reference>


<reference target2="reference.RFC.0015.xml" anchor="RFC0015">
<front>
<title>Network subsystem for time sharing hosts</title>
<author fullname="C. Stephen Carr" initials="C." surname="Carr">
<organization>University of Utah</organization>
</author>

<date year="1969" day="25" month="September" />
</front>

<seriesInfo value="15" name="RFC" />
</reference>


<reference target2="reference.RFC.0016.xml" anchor="RFC0016">
<front>
<title>M.I.T</title>
<author fullname="Steve Crocker" initials="S." surname="Crocker">
<organization>University California Los Angeles (UCLA)</organization>
</author>

<date year="1969" day="27" month="August" />

<abstract>
<t>M.I.T. is now to receive all Network Working Group memos.</t>
</abstract>
</front>

<seriesInfo value="16" name="RFC" />
</reference>


<reference target2="reference.RFC.0017.xml" anchor="RFC0017">
<front>
<title abbrev="Re: HOST-IMP Protocol &amp; Response">Some questions re: Host-IMP Protocol</title>
<author fullname="J. Kreznar" initials="J." surname="Kreznar">
<organization>System Development Corporation (SDC)</organization>
</author>

<date year="1969" day="27" month="August" />
</front>

<seriesInfo value="17" name="RFC" />
</reference>


<reference target2="reference.RFC.0018.xml" anchor="RFC0018">
<front>
<title>IMP-IMP and HOST-HOST Control Links</title>
<author fullname="Vint Cerf" initials="V." surname="Cerf">
<organization>University California Los Angeles (UCLA)</organization>
</author>

<date year="1969" day="1" month="September" />

<abstract>
<t>It is suggested that link 1 be used for the HOST-HOST control link and link 0 be used for IMP-IMP control.</t>
</abstract>
</front>

<seriesInfo value="18" name="RFC" />
</reference>


<reference target2="reference.RFC.0019.xml" anchor="RFC0019">
<front>
<title>Two protocol suggestions to reduce congestion at swap bound nodes</title>
<author fullname="John E. Kreznar" initials="J." surname="Kreznar">
<organization>System Development Corporation (SDC)</organization>
</author>

<date year="1969" day="7" month="October" />

<abstract>
<t>There is a wide variance in swap rates between core and auxiliary store among the HOST systems to be nodes in the ARPA IMP network.  The slower of these, of which our 360/50 system with 2303 drump swap store is an example, might improve the utility of the network not only for themselves but for all nodes if the two protocol suggestions of this note were to be adopted.</t>
</abstract>
</front>

<seriesInfo value="19" name="RFC" />
</reference>


<reference target2="reference.RFC.0020.xml" anchor="RFC0020">
<front>
<title>ASCII format for network interchange</title>
<author fullname="Vint Cerf" initials="V." surname="Cerf">
<organization>University California Los Angeles (UCLA)</organization>
</author>

<date year="1969" day="16" month="October" />

<abstract>
<t>For concreteness, we suggest the use of standard 7-bit ASCII embedded in an 8 bit byte whose high order bit is always 0.</t>
</abstract>
</front>

<seriesInfo value="20" name="RFC" />
</reference>


<reference target2="reference.RFC.0021.xml" anchor="RFC0021">
<front>
<title>Network meeting</title>
<author fullname="V. Cerf" initials="V." surname="Cerf">
<organization>University California Los Angeles (UCLA)</organization>
</author>

<date year="1969" day="17" month="October" />

<abstract>
<t>At UCLA on October 10, there was a network meeting attended by:</t>
</abstract>
</front>

<seriesInfo value="21" name="RFC" />
</reference>


<reference target2="reference.RFC.0022.xml" anchor="RFC0022">
<front>
<title>Host-host control message formats</title>
<author fullname="V.G. Cerf" initials="V.G." surname="Cerf">
<organization />
</author>

<date year="1969" day="17" month="October" />
</front>

<seriesInfo value="22" name="RFC" />
<format octets="4606" type="TXT" target="ftp://ftp.isi.edu/in-notes/rfc22.txt" />
</reference>


<reference target2="reference.RFC.0023.xml" anchor="RFC0023">
<front>
<title>Transmission of Multiple Control Messages</title>
<author fullname="G. Gregg" initials="G." surname="Gregg">
<organization>University of California, Santa Barbara (UCSB)</organization>
</author>

<date year="1969" day="16" month="October" />

<abstract>
<t>The network program at a site must be prepared to send or receive more than one control message in a single control communication.</t>

<t>During the time that the control link is blocked awaiting RFNM, it is possible that a number of control messages to a particular remote host will accumulate.  When the link is unblocked, these should all be sent in a single communication for greatest efficiency.</t>

<t>For receiving, it will be necessary to have a loop which returns to decode and take action on successive control messages until the control communication is exhausted.</t>
</abstract>
</front>

<seriesInfo value="23" name="RFC" />
</reference>


<reference target2="reference.RFC.0024.xml" anchor="RFC0024">
<front>
<title>Documentation Conventions</title>
<author fullname="S. Crocker" initials="S." surname="Crocker">
<organization>University of California, Los Angeles (UCLA)</organization>
</author>

<date year="1969" day="21" month="November" />

<abstract>
<t>This note is a revision of NWG/RFC 10 and 16,.</t>

<t>The Network Working Group consists of interested people from existing or potential ARPA network sites.  Membership is not closed.</t>

<t>The Network Working Group (NWG) is concerned with the HOST software, the strategies for using the network, and initial experience with the network.</t>

<t>Documentation of the NWG's effort is through notes such as this.  Notes may be produced at any site by and included in this series.</t>
</abstract>
</front>

<seriesInfo value="24" name="RFC" />
</reference>


<reference target2="reference.RFC.0025.xml" anchor="RFC0025">
<front>
<title>No High Link Numbers</title>
<author fullname="Steve Crocker" initials="S." surname="Crocker">
<organization>University of California, Los Angeles (UCLA)</organization>
</author>

<date year="1969" day="30" month="October" />

<abstract>
<t>Because it may be desirable to reserve one or more link numbers for instrumentation purposes, and because 256 link numbers are many more than are needed, we suggest that no link number over 63 be used.  At UCLA, we will implement our tables to take advantage of this limitation. We also note that 32 may be even more realistic, but 64 is certainly sufficient.</t>
</abstract>
</front>

<seriesInfo value="25" name="RFC" />
</reference>


<reference target2="reference.RFC.0027.xml" anchor="RFC0027">
<front>
<title>Documentation Conventions</title>
<author fullname="Steve Crocker" initials="S." surname="Crocker">
<organization>University California Los Angeles (UCLA)</organization>
</author>

<date year="1969" day="9" month="December" />

<abstract>
<t>This note is a revision of NWG/RFC 10, 16, and 24,,.</t>

<t>The Network Working Group consists of interested people from existing or 
potential ARPA network sites.  Membership is not closed.</t>

<t>The Network Working Group (NWG) is concerned with the HOST software, the
strategies for using the network, and initial experience with the network.</t>

<t>Documentation of the NWG's effort is through notes such as this.  Notes may be produced at any site by anybody and included in this series.</t>
</abstract>
</front>

<seriesInfo value="27" name="RFC" />
</reference>


<reference target2="reference.RFC.0028.xml" anchor="RFC0028">
<front>
<title>Time Standards</title>
<author fullname="Bill English" initials="B." surname="English">
<organization>Stanford Research Institute (SRI)</organization>
</author>

<date year="1970" day="13" month="January" />

<abstract>
<t>We are about to install a relatively accurate real-time clock on our system.  I would like any comments relative to Network time standards for such things as delay measurement so we can decide how good our clock should be.</t>
</abstract>
</front>

<seriesInfo value="28" name="RFC" />
</reference>


<reference target2="reference.RFC.0029.xml" anchor="RFC0029">
<front>
<title>Response to RFC 28</title>
<author fullname="Robert Kahn" initials="R." surname="Kahn">
<organization>Bolt Baranek and Newman (BBN)</organization>
</author>

<date year="1970" day="19" month="January" />

<abstract>
<t>A "millisecond" clock should be satisfactory for most network measurements. Round-trip message transit times typically should be at least on the order of tens to hundreds of milliseconds.  The IMP contains a 16-bit hardware clock which is incremented every 100 microseconds to allow for timing of internal events within the IMP, as for example, during tracing.However, most measurements are made using a 25.6 ms. software clock.</t>
</abstract>
</front>

<seriesInfo value="29" name="RFC" />
</reference>


<reference target2="reference.RFC.0030.xml" anchor="RFC0030">
<front>
<title>Documentation Conventions</title>
<author fullname="Steve Crocker" initials="S." surname="Crocker">
<organization>University of California, Los Angeles (UCLA)</organization>
</author>

<date year="1970" day="4" month="February" />

<abstract>
<t>This note is a revision of NWG/RFC 10, 16, 24, and 27,.,.</t>

<t>The Network Working Group consists of interested pleople from existing or potential ARPA network sites.  Membership is not closed.</t>

<t>The Network Working Group (NWG) is concerned with the HOST software, the strategies for using the network, and initial experience with the network.</t>

<t>Documentation of the NWG's effort is through notes such as this.  Notes may be produced at any site by anybody and included in this series.</t>
</abstract>
</front>

<seriesInfo value="30" name="RFC" />
</reference>


<reference target2="reference.RFC.0031.xml" anchor="RFC0031">
<front>
<title abbrev="Binary Message Forms">Binary Message Forms in Computer</title>
<author fullname="Daniel Bobrow" initials="D." surname="Bobrow">
<organization>Bolt, Beranek, and Newman (BBN)</organization>
</author>

<author fullname="William R. Sutherland" initials="W." surname="Sutherland">
<organization>Massachusetts Institute of Technology (MIT), Lincoln Laboratory</organization>
</author>

<date year="1968" day="1" month="February" />
</front>

<seriesInfo value="31" name="RFC" />
</reference>


<reference target2="reference.RFC.0032.xml" anchor="RFC0032">
<front>
<title>Connecting M.I.T</title>
<author fullname="Jerry Cole" initials="J." surname="Cole">
<organization>University of California, Los Angeles (UCLA)</organization>
</author>

<date year="1969" day="5" month="February" />

<abstract>
<t>Re: NWG/RFC's #28 and 29,.</t>

<t>The addition of a clock in one or more of the network HOST's seems to be very desireable since it (or they) would allow user-oriented message delay measurements.</t>
</abstract>
</front>

<seriesInfo value="32" name="RFC" />
</reference>


<reference target2="reference.RFC.0033.xml" anchor="RFC0033">
<front>
<title>New Host-Host Protocol</title>
<author fullname="S.D. Crocker" initials="S.D." surname="Crocker">
<organization />
</author>

<date year="1970" day="12" month="February" />
</front>

<seriesInfo value="33" name="RFC" />
<format octets="44167" type="TXT" target="ftp://ftp.isi.edu/in-notes/rfc33.txt" />
</reference>


<reference target2="reference.RFC.0034.xml" anchor="RFC0034">
<front>
<title abbrev="Prelimary Notes on the ARC Clock">Some Brief Preliminary Notes on the Augmentation Research Center Clock</title>
<author fullname="Bill English" initials="B." surname="English">
<organization>Stanford Research Institute (SRI) International,  Augmentation Research Center (ARC)</organization>
</author>

<date year="1970" day="26" month="February" />

<abstract>
<t>The ARC clock system provides a time reference that is written into the core memory of the XDS 940 Computer. There are two types of time information available--absolute and relative.</t>
</abstract>
</front>

<seriesInfo value="34" name="RFC" />
</reference>


<reference target2="reference.RFC.0035.xml" anchor="RFC0035">
<front>
<title>Network Meeting</title>
<author fullname="Steve Crocker" initials="S." surname="Crocker">
<organization>University of California, Los Angeles (UCLA)</organization>
</author>

<date year="1970" day="3" month="March" />

<abstract>
<t>I expect to have the details of the new network protocol as outlined in NWG/RFC #33ready in two weeks.</t>
</abstract>
</front>

<seriesInfo value="35" name="RFC" />
</reference>


<reference target2="reference.RFC.0036.xml" anchor="RFC0036">
<front>
<title>Protocol Notes</title>
<author fullname="Steve Crocker" initials="S." surname="Crocker">
<organization>University California Los Angeles (UCLA)</organization>
</author>

<date year="1970" day="16" month="March" />
</front>

<seriesInfo value="36" name="RFC" />
</reference>


<reference target2="reference.RFC.0037.xml" anchor="RFC0037">
<front>
<title>Network Meeting Epilogue, etc</title>
<author fullname="Steve Crocker" initials="S." surname="Crocker">
<organization>University of California, Los Angeles (UCLA)</organization>
</author>

<date year="1970" day="20" month="March" />
</front>

<seriesInfo value="37" name="RFC" />
</reference>


<reference target2="reference.RFC.0038.xml" anchor="RFC0038">
<front>
<title>Comments on Network Protocol from NWG/RFC #36</title>
<author fullname="Stephen M. Wolfe" initials="S." surname="Wolfe">
<organization>University of California, Los Angeles (UCLA), Campus Computing Network (CCN)</organization>
</author>

<date year="1970" day="20" month="March" />

<abstract>
<t>The proposed protocol does not allow for the possible multiplexing of connections over links.</t>
</abstract>
</front>

<seriesInfo value="38" name="RFC" />
</reference>


<reference target2="reference.RFC.0039.xml" anchor="RFC0039">
<front>
<title>Comments on Protocol Re: NWG/RFC #36</title>
<author fullname="E. Harslem" initials="E." surname="Harslem">
<organization>Rand Corporation</organization>
</author>

<author fullname="J. Heafner" initials="J." surname="Heafner">
<organization>Rand Corporation</organization>
</author>

<date year="1970" day="25" month="March" />

<abstract>
<t>We offer the following suggestions to be considered as additions to the April 28th 1970 protocol grammar specifications.</t>
</abstract>
</front>

<seriesInfo value="39" name="RFC" />
</reference>


<reference target2="reference.RFC.0040.xml" anchor="RFC0040">
<front>
<title>More Comments on the Forthcoming Protocol</title>
<author fullname="E. Harslem" initials="E." surname="Harslem">
<organization>Rand Corporation</organization>
</author>

<author fullname="J. Heafner" initials="J." surname="Heafner">
<organization>Rand Corporation</organization>
</author>

<date year="1970" day="27" month="March" />

<abstract>
<t>We have recently discussed NWG/RFC Nos. 36 and 39,with Steve Crocker, UCLA.  Steve has asked that we elaborate on the errors, queries, and HOST status that were mentioned in NWG/RFC #39.</t>
</abstract>
</front>

<seriesInfo value="40" name="RFC" />
</reference>


<reference target2="reference.RFC.0041.xml" anchor="RFC0041">
<front>
<title>IMP-IMP Teletype Communication</title>
<author fullname="John Melvin" initials="J." surname="Melvin">
<organization>Stanford Research Institute (SRI) International,  Augmentation Research Center (ARC)</organization>
</author>

<date year="1970" day="30" month="March" />

<abstract>
<t>I have occasionally found myself in a situatuation in Which I see a message from site X on my IMP teletype, but I don't know the time and date of the message.</t>

<t>I find this annoying, since a response to it may be in order if it is (say) less than an hour old, but not if it is several hours old. The situation is not improved by the existence of sites that now span all time zones of the U.S. and do not have direct voice connection.</t>

<t>It is requested that everyone tag their IMP to IMP teletype messages that cause no response at the receiving IMP.</t>

<t>The transmitting IMP site should use 24 hour time and include the time zone designation.</t>
</abstract>
</front>

<seriesInfo value="41" name="RFC" />
</reference>


<reference target2="reference.RFC.0042.xml" anchor="RFC0042">
<front>
<title>Message Data Types</title>
<author fullname="E. I. Ancona" initials="E." surname="Ancona">
<organization>Massachusetts Institute of Technology (MIT), Lincoln Laboratory</organization>
</author>

<date year="1970" day="31" month="March" />
</front>

<seriesInfo value="42" name="RFC" />
</reference>


<reference target2="reference.RFC.0043.xml" anchor="RFC0043">
<front>
<title>Proposed Meeting</title>
<author fullname="A. G. Nemeth" initials="A." surname="Nemeth">
<organization>Massachusetts Institute of Technology (MIT), Lincoln Laboratory</organization>

<address>
<postal>
<street />
<city>Lexington</city>
<region>MA</region>
<code>02173</code>
<country>US</country>
</postal>

<phone>+1 617 862 5500 x7354</phone>
</address>
</author>

<date year="1970" day="8" month="April" />

<abstract>
<t>On Friday, 8 May 1970, at 9:30 AM a meeting at M.I.T. Lincoln Laboratory is proposed. A description of LIL (Local Interaction Language) for the TSP (Terminal Support Processor) system will be presented.</t>

<t>The purpose of the TSP system is to provide a flexible I/O capability for network users. In order to achieve maximum flexibility, the system is user-programmable in an interpretable language called LIL.</t>
</abstract>
</front>

<seriesInfo value="43" name="RFC" />
</reference>


<reference target2="reference.RFC.0044.xml" anchor="RFC0044">
<front>
<title>Comments on NWG/RFC 33 and 36</title>
<author fullname="A. Shoshani" initials="A." surname="Shoshani">
<organization />
</author>

<author fullname="R. Long" initials="R." surname="Long">
<organization />
</author>

<author fullname="A. Landsberg" initials="A." surname="Landsberg">
<organization />
</author>

<date year="1970" day="10" month="April" />
</front>

<seriesInfo value="44" name="RFC" />
<format octets="7381" type="TXT" target="ftp://ftp.isi.edu/in-notes/rfc44.txt" />
</reference>


<reference target2="reference.RFC.0045.xml" anchor="RFC0045">
<front>
<title>New Protocol is Coming</title>
<author fullname="J. Postel" initials="J." surname="Postel">
<organization>University of California, Los Angeles (UCLA)</organization>
</author>

<author fullname="S. Crocker" initials="S." surname="Crocker">
<organization>University of California, Los Angeles (UCLA)</organization>
</author>

<date year="1970" day="14" month="April" />

<abstract>
<t>We are currently preparing a clean version of the Network protocol, hopefully suitable for immediate implementation.  As advertised, we will send these specs out on April 28.</t>
</abstract>
</front>

<seriesInfo value="45" name="RFC" />
</reference>


<reference target2="reference.RFC.0046.xml" anchor="RFC0046">
<front>
<title>ARPA Network protocol notes</title>
<author fullname="Edwin E. Meyer Jr." initials="E." surname="Meyer">
<organization>Massachusetts Institute of Technology (MIT)</organization>
</author>

<date year="1970" day="17" month="April" />

<abstract>
<t>The attached document contains comments and suggestions of the Network Working Group at Project MAC.  It is based upon the protocol outlined in NWG/RFC 33, 36,, and later documents.</t>

<t>This proposal is intended as a contribution to the dialog leading to a protocol specification to be accepted by the entire Network Working Group.</t>

<t>We solicit your comments.</t>
</abstract>
</front>

<seriesInfo value="46" name="RFC" />
</reference>


<reference target2="reference.RFC.0047.xml" anchor="RFC0047">
<front>
<title>BBN's Comments on NWG/RFC #33</title>
<author fullname="J. Postel" initials="J." surname="Postel">
<organization>University of California, Los Angeles (UCLA)</organization>
</author>

<author fullname="S. Crocker" initials="S." surname="Crocker">
<organization>University of California, Los Angeles (UCLA)</organization>
</author>

<date year="1970" day="20" month="April" />

<abstract>
<t>BBN has given us the attached comments on NWG/RFC 33, but wouldn't publish them being relectant to embarrass us.  Embarrassment notwithstanding, we found the comments particularly useful and decided to share them with our friends.  Bill Crowther is the author.</t>
</abstract>
</front>

<seriesInfo value="47" name="RFC" />
</reference>


<reference target2="reference.RFC.0048.xml" anchor="RFC0048">
<front>
<title>Possible protocol plateau</title>
<author fullname="J. Postel" initials="J." surname="Postel">
<organization>University of California, Los Angeles (UCLA)</organization>
</author>

<author fullname="S. Crocker" initials="S." surname="Crocker">
<organization>University of California, Los Angeles (UCLA)</organization>
</author>

<date year="1970" day="21" month="April" />
</front>

<seriesInfo value="48" name="RFC" />
</reference>


<reference target2="reference.RFC.0049.xml" anchor="RFC0049">
<front>
<title>Conversations with S</title>
<author fullname="Edwin W. Meyer Jr." initials="E." surname="Meyer">
<organization>Massachusetts Institute of Technology (MIT), Project MAC</organization>
</author>

<date year="1970" day="25" month="April" />

<abstract>
<t>On April 21 and 23 Thomas P. Skinner and I had telephone conversations with Steve Crocker at UCLA relating to the network protocol, specifically regarding our proposal in NWG/RFC 46.</t>
</abstract>
</front>

<seriesInfo value="49" name="RFC" />
</reference>


<reference target2="reference.RFC.0050.xml" anchor="RFC0050">
<front>
<title>Comments on the Meyer Proposal</title>
<author fullname="E. Harslen" initials="E." surname="Harslen">
<organization>RAND Corporation</organization>
</author>

<author fullname="J. Heafner" initials="J." surname="Heafner">
<organization>RAND Corporation</organization>
</author>

<date year="1970" day="30" month="April" />

<abstract>
<t>We find the Meyer proposal (Note #46) to be the most acceptable to dare, for exactly the reasons that he enumerates; viz., simple, suffices for most planned uses of the Network, easy to implement, can be extended.</t>
</abstract>
</front>

<seriesInfo value="50" name="RFC" />
</reference>


<reference target2="reference.RFC.0051.xml" anchor="RFC0051">
<front>
<title>Proposal for a Network Interchange Language</title>
<author fullname="M. Elie" initials="M." surname="Elie">
<organization />
</author>

<date year="1970" day="4" month="May" />
</front>

<seriesInfo value="51" name="RFC" />
</reference>


<reference target2="reference.RFC.0052.xml" anchor="RFC0052">
<front>
<title>Updated distribution list</title>
<author fullname="J. Postel" initials="J." surname="Postel">
<organization>University California Los Angeles (UCLA)</organization>
</author>

<author fullname="S. Crocker" initials="S." surname="Crocker">
<organization>University California Los Angeles (UCLA)</organization>
</author>

<date year="1970" day="1" month="July" />
</front>

<seriesInfo value="52" name="RFC" />
</reference>


<reference target2="reference.RFC.0053.xml" anchor="RFC0053">
<front>
<title>Official protocol mechanism</title>
<author fullname="S. Crocker" initials="S." surname="Crocker">
<organization>University of California, Los Angeles (UCLA)</organization>
</author>

<date year="1970" day="9" month="June" />

<abstract>
<t>During the Spring Joint Computer Conference in Atlantic City, Larry Roberts, Barry Wessler, Cordell Green, Jon Postel and I discussed rules for establishing and modifying an official Host-Host protocol.</t>
</abstract>
</front>

<seriesInfo value="53" name="RFC" />
</reference>


<reference target2="reference.RFC.0054.xml" anchor="RFC0054">
<front>
<title>Official Protocol Proffering</title>
<author fullname="Steve Crocker" initials="S." surname="Crocker">
<organization>University of California, Los Angeles (UCLA)</organization>
</author>

<author fullname="Jon Postel" initials="J." surname="Postel">
<organization>University of California, Los Angeles (UCLA)</organization>
</author>

<author fullname="John Newkirk" initials="J." surname="Newkirk">
<organization>Harvard University</organization>
</author>

<author fullname="Mike Kraley" initials="M." surname="Kraley">
<organization>Harvard University</organization>
</author>

<date year="1970" day="18" month="June" />
</front>

<seriesInfo value="54" name="RFC" />
</reference>


<reference target2="reference.RFC.0055.xml" anchor="RFC0055">
<front>
<title>Prototypical implementation of the NCP</title>
<author fullname="J. Newkirk" initials="J." surname="Newkirk">
<organization>Harvard University</organization>
</author>

<author fullname="M. Kraley" initials="M." surname="Kraley">
<organization>Harvard University</organization>
</author>

<author fullname="J. Postel" initials="J." surname="Postel">
<organization>University of California, Los Angeles (UCLA)</organization>
</author>

<author fullname="S. Crocker" initials="S." surname="Crocker">
<organization>University of California, Los Angeles (UCLA)</organization>
</author>

<date year="1970" day="19" month="June" />

<abstract>
<t>While involved in attempting to specify the formal protocol, we also attempted to formulate a prototypical NCP in an Algol-like language.</t>
</abstract>
</front>

<seriesInfo value="55" name="RFC" />
</reference>


<reference target2="reference.RFC.0056.xml" anchor="RFC0056">
<front>
<title>Third Level Protocol: Logger Protocol</title>
<author fullname="Ed Belove" initials="E." surname="Belove">
<organization>Harvard University</organization>
</author>

<author fullname="Dave Black" initials="D." surname="Black">
<organization>Harvard University</organization>
</author>

<author fullname="Bob Flegel" initials="B." surname="Flegel">
<organization>University of Utah</organization>
</author>

<author fullname="Lamar G. Farquar" initials="L." surname="Farquar">
<organization>University of Utah</organization>
</author>

<date year="1970" day="1" month="June" />

<abstract>
<t>In our view of the world each host has a set of four programs to allow a user teletype to communicate with a foreign monitor. The exact implementation of these programs is highly installation-dependent.  Thus all explanations are meant to describe functional characteristics rather than design.</t>
</abstract>
</front>

<seriesInfo value="56" name="RFC" />
</reference>


<reference target2="reference.RFC.0057.xml" anchor="RFC0057">
<front>
<title>Thoughts and Reflections on NWG/RFC 54</title>
<author fullname="Mike Kraley" initials="M." surname="Kraley">
<organization>Harvard University</organization>
</author>

<author fullname="John Newkirk" initials="J." surname="Newkirk">
<organization>Harvard University</organization>
</author>

<date year="1970" day="19" month="June" />

<abstract>
<t>In the course of writing NWG/RFC #54several new ideas became apparent.  Since these ideas had not previously been discussed by the NWG, or were sufficiently imprecise, it was decided not to include them in the official protocol proffering.  We thought, however, that they might be proper subjects for discussion and later inclusion in the second level protocol.</t>
</abstract>
</front>

<seriesInfo value="57" name="RFC" />
</reference>


<reference target2="reference.RFC.0058.xml" anchor="RFC0058">
<front>
<title>Logical Message Synchronization</title>
<author fullname="T. P. Skinner" initials="T." surname="Skinner">
<organization>Massachusetts Institute of Technology (MIT),  Project MAC</organization>
</author>

<date year="1970" day="26" month="June" />

<abstract>
<t>At the last network meeting, the question of logical and physical message distinctions was raised.  An argument was made in favor of never running two logical messages together as one or more physical messages.  Another method of stating this is that a logical message must begin on a physical message boundary.  This did not, however, solve the problem of locating the end of a logical message.  A rather poor technique was suggested by myself which consisted of using the first partial physical message as an indication of the last physical message of the logical message.  This technique was thrown out for a number of very valid reasons.  The solution that seemed most pleasing was the inclusion of some sort of a bit count or data type specification to precede the logical message.  Most everyone seemed to like this even though it was stated in a very general way.</t>
</abstract>
</front>

<seriesInfo value="58" name="RFC" />
</reference>


<reference target2="reference.RFC.0059.xml" anchor="RFC0059">
<front>
<title>Flow Control - Fixed Versus Demand Allocation</title>
<author fullname="Edwin W. Meyer Jr." initials="E." surname="Meyer">
<organization>Massachusetts Institute of Technology (MIT), Project MAC</organization>
</author>

<date year="1970" day="27" month="June" />

<abstract>
<t>The method of flow control described in RFC 54, prior allocation of buffer space by the use of ALL network commands, has one particular advantage. If no more than 100% of an NCP's buffer space is allocated, the situation in which more messages are presented to a HOST then it can handle will never arise.</t>

<t>However, this scheme has very serious disadvantages:</t>
</abstract>
</front>

<seriesInfo value="59" name="RFC" />
</reference>


<reference target2="reference.RFC.0060.xml" anchor="RFC0060">
<front>
<title>Simplified NCP Protocol</title>
<author fullname="Richard Kalin" initials="R." surname="Kalin">
<organization>Massachusetts Institute of Technology (MIT), Lincoln Laboratory</organization>
</author>

<date year="1970" day="13" month="July" />

<abstract>
<t>This RFC defines a new NCP protocol that is simple enough to be implemented on a very small computer, yet can be extended for efficient operation on large timesharing machines. Because worst case storage requirements can be predicted, a conservative implementation can be freed of complicated resource allocation and storage control procedures. A general error recovery procedure is also defined.</t>
</abstract>
</front>

<seriesInfo value="60" name="RFC" />
</reference>


<reference target2="reference.RFC.0061.xml" anchor="RFC0061">
<front>
<title abbrev="Interprocess Communication in a Computer Network">Note on Interprocess Communication in a Resource Sharing Computer Network</title>
<author fullname="Dave Walden" initials="D." surname="Walden">
<organization>Bolt Beranek and Newman (BBN)</organization>
</author>

<date year="1970" day="17" month="July" />
</front>

<seriesInfo value="61" name="RFC" />
</reference>


<reference target2="reference.RFC.0062.xml" anchor="RFC0062">
<front>
<title abbrev="IPC for Resource Sharing">Systems for Interprocess Communication in a Resource Sharing Computer Network</title>
<author fullname="D. C. Walden" initials="D." surname="Walden">
<organization>Bolt Beranek and Newman, Inc. (BBN)</organization>

<address>
<postal>
<street>10 Moulton Street</street>
<city>Cambridge</city>
<region>MA</region>
<code>02138</code>
<country>US</country>
</postal>

</address>
</author>

<date year="1970" day="3" month="August" />
</front>

<seriesInfo value="62" name="RFC" />
</reference>


<reference target2="reference.RFC.0063.xml" anchor="RFC0063">
<front>
<title>Belated Network Meeting Report</title>
<author fullname="V. Cerf" initials="V." surname="Cerf">
<organization />
</author>

<date year="1970" day="31" month="July" />

<abstract>
<t>On 8 May 1970, a Network Working Group meeting was hosted at Lincoln Labs.</t>
</abstract>
</front>

<seriesInfo value="63" name="RFC" />
</reference>


<reference target2="reference.RFC.0064.xml" anchor="RFC0064">
<front>
<title>Getting rid of marking</title>
<author fullname="M. Elie" initials="M." surname="Elie">
<organization />
</author>

<date year="1970" day="1" month="July" />
</front>

<seriesInfo value="64" name="RFC" />
<format octets="7556" type="TXT" target="ftp://ftp.isi.edu/in-notes/rfc64.txt" />
</reference>


<reference target2="reference.RFC.0065.xml" anchor="RFC0065">
<front>
<title abbrev="Comments on Host-Host Protocol">Comments on Host/Host Protocol document #1</title>
<author fullname="Dave Walden" initials="D." surname="Walden">
<organization>A/S Norsk Data-Elektonikk</organization>
</author>

<date year="1970" day="29" month="August" />

<abstract>
<t>Eliminate marking.  Instead, make all regular messages into two message: The first containing just the leader and indicating that the data follows in the second (next) message. Do this both from the source Host to its IMP and from the destination IMP to its Host.</t>
</abstract>
</front>

<seriesInfo value="65" name="RFC" />
</reference>


<reference target2="reference.RFC.0066.xml" anchor="RFC0066">
<front>
<title>NIC - third level ideas and other noise</title>
<author fullname="S.D. Crocker" initials="S.D." surname="Crocker">
<organization />
</author>

<date year="1970" day="26" month="August" />
</front>

<seriesInfo value="66" name="RFC" />
<format octets="4575" type="TXT" target="ftp://ftp.isi.edu/in-notes/rfc66.txt" />
</reference>


<reference target2="reference.RFC.0067.xml" anchor="RFC0067">
<front>
<title>Proposed Change to Host/IMP Spec to Eliminate Marking</title>
<author fullname="W. Crowther" initials="W." surname="Crowther">
<organization>Bolt Baranek and Newman (BBN)</organization>
</author>

<date year="1970" day="1" month="January" />

<abstract>
<t>Before he left for Norway, Dave Walden observed that there was a simple change to the Host/IMP specifications which would eliminate all "marking" problems. The change is to separate the leader from the text of regular messages, and then to send them as consecutive messages instead of one packed message.  The text would then start on a word boundary no matter what the word lengths of the machines involved.  The process would take place on both IMP-to-Host and Host-to-IMP messages.</t>
</abstract>
</front>

<seriesInfo value="67" name="RFC" />
</reference>


<reference target2="reference.RFC.0068.xml" anchor="RFC0068">
<front>
<title>Comments on Memory Allocation Control Commands: CEASE, ALL, GVB, RET, and RFNM</title>
<author fullname="M. Elie" initials="M." surname="Elie">
<organization>University of California, Los Angeles (UCLA)</organization>
</author>

<date year="1970" day="31" month="August" />

<abstract>
<t>The protocol provides a scheme for buffer allocation.</t>
</abstract>
</front>

<seriesInfo value="68" name="RFC" />
</reference>


<reference target2="reference.RFC.0069.xml" anchor="RFC0069">
<front>
<title>Distribution List Change for MIT</title>
<author fullname="A. Bhushan" initials="A." surname="Bhushan">
<organization>Massachusetts Institute of Technology (MIT)</organization>
</author>

<date year="1970" day="22" month="September" />

<abstract>
<t>Please delete my name from your distribution list and add that of Mr. Albert Vezza.</t>
</abstract>
</front>

<seriesInfo value="69" name="RFC" />
</reference>


<reference target2="reference.RFC.0070.xml" anchor="RFC0070">
<front>
<title>Note on Padding</title>
<author fullname="S. Crocker" initials="S." surname="Crocker">
<organization>University of California, Los Angeles (UCLA)</organization>
</author>

<date year="1970" day="15" month="October" />

<abstract>
<t>The padding on a message is a string of the form 10*.  For Hosts with word lengths 16, 32, 48, etc., bits long, this string is necessarily in the last word received from the Imp.</t>
</abstract>
</front>

<seriesInfo value="70" name="RFC" />
</reference>


<reference target2="reference.RFC.0071.xml" anchor="RFC0071">
<front>
<title>Reallocation in Case of Input Error</title>
<author fullname="Tjaart Schipper" initials="T." surname="Schipper">
<organization>University of California, Los Angeles (UCLA), Campus Computing Network (CCN)</organization>
</author>

<date year="1970" day="25" month="September" />

<abstract>
<t>In case of reading a message from the IMP, it may be impossible for the receiving NCP to determine the length of the message if an input error occurs. The following protocol will be used at the CCN-Host at UCLA to resynchronize flow control.</t>
</abstract>
</front>

<seriesInfo value="71" name="RFC" />
</reference>


<reference target2="reference.RFC.0072.xml" anchor="RFC0072">
<front>
<title>Proposed Moratorium on Changes to Network Protocol</title>
<author fullname="Robert D. Bressler" initials="R." surname="Bressler">
<organization>Massachusetts Institute of Technology (MIT), Project MAC</organization>
</author>

<date year="1970" day="28" month="September" />

<abstract>
<t>Bill Crowther's RFC No. 67raised a much more  fundamental  issue than  the  question  of marking.  Any change to presently established protocol  is  going  to  involve  changes  in  the  hardware/software development  efforts  that have, in some instances, been going on for over 6 months.  In the case  of  Multics,  this  effort  has  yielded programs  either  complete or in the advanced debugging stages.  This is no doubt true for many other sites as well.</t>
</abstract>
</front>

<seriesInfo value="72" name="RFC" />
</reference>


<reference target2="reference.RFC.0073.xml" anchor="RFC0073">
<front>
<title>Response to NWG/RFC 67</title>
<author fullname="S. Crocker" initials="S." surname="Crocker">
<organization>University of California, Los Angeles (UCLA)</organization>
</author>

<date year="1970" day="25" month="September" />

<abstract>
<t>Bill's suggestion is a good one; however, my current policy is to encourage the most rapid implementation of the protocol in document #1, and his suggested modification should be delayed.  It seems to me most important to gain experience using the network before making changes to the protocol which are not dictated by necessity.</t>
</abstract>
</front>

<seriesInfo value="73" name="RFC" />
</reference>


<reference target2="reference.RFC.0074.xml" anchor="RFC0074">
<front>
<title>Specifications for network use of the UCSB On-Line System</title>
<author fullname="J.E. White" initials="J.E." surname="White">
<organization />
</author>

<date year="1970" day="16" month="October" />
</front>

<seriesInfo value="74" name="RFC" />
</reference>


<reference target2="reference.RFC.0075.xml" anchor="RFC0075">
<front>
<title>Network Meeting</title>
<author fullname="S. Crocker" initials="S." surname="Crocker">
<organization>University of California, Los Angeles (UCLA)</organization>
</author>

<date year="1970" day="14" month="October" />

<abstract>
<t>Taking advantage of the FJCC in Houston, I have scheduled a meeting of the Network Working Group in room Astro VII of the Astroworld Hotel at 8:00 p.m.  on Monday, November 16, 1970.</t>
</abstract>
</front>

<seriesInfo value="75" name="RFC" />
</reference>


<reference target2="reference.RFC.0076.xml" anchor="RFC0076">
<front>
<title>Connection by name: User oriented protocol</title>
<author fullname="J. Bouknight" initials="J." surname="Bouknight">
<organization>University of Illinois</organization>
</author>

<author fullname="J. Madden" initials="J." surname="Madden">
<organization>University of Illinois</organization>
</author>

<author fullname="G. Grossman" initials="G." surname="Grossman">
<organization>University of Illinois</organization>
</author>

<date year="1970" day="28" month="October" />

<abstract>
<t>Shortly after the first of the year, 1971, the Center for Advanced Computation (CAC) at the University of Illinois will begin to use the facilities of the ARPA network.</t>
</abstract>
</front>

<seriesInfo value="76" name="RFC" />
</reference>


<reference target2="reference.RFC.0077.xml" anchor="RFC0077">
<front>
<title>Network meeting report</title>
<author fullname="J. Postel" initials="J." surname="Postel">
<organization>University of California, Los Angeles (UCLA)</organization>
</author>

<date year="1970" day="20" month="November" />

<abstract>
<t>This is a report on a series of three Network Working Group meetings at the Fall Joint Computer Conference, November 16, 17 and 18 in Houston, Texas.</t>
</abstract>
</front>

<seriesInfo value="77" name="RFC" />
</reference>


<reference target2="reference.RFC.0078.xml" anchor="RFC0078">
<front>
<title>NCP Status Report: UCSB/Rand</title>
<author fullname="E. Harslem" initials="E." surname="Harslem">
<organization>Rand Corporation</organization>
</author>

<author fullname="J. Heafner" initials="J." surname="Heafner">
<organization>Rand Corporation</organization>
</author>

<author fullname="J. White" initials="J." surname="White">
<organization />
</author>

<date year="1970" day="1" month="October" />
</front>

<seriesInfo value="78" name="RFC" />
</reference>


<reference target2="reference.RFC.0079.xml" anchor="RFC0079">
<front>
<title>Logger Protocol error</title>
<author fullname="Edwin W. Meyer Jr." initials="E." surname="Meyer">
<organization>Massachusetts Institute of Technology (MIT), Project MAC</organization>
</author>

<date year="1970" day="16" month="November" />

<abstract>
<t>A conflict was recently discovered between the official NCP protocol as described in protocol document 1 and the logger protocol as described in RFC 66by Steve Crocker.  Steve suggested that we put out an RFC to alert the network community to this point.</t>
</abstract>
</front>

<seriesInfo value="79" name="RFC" />
</reference>


<reference target2="reference.RFC.0080.xml" anchor="RFC0080">
<front>
<title>Protocols and Data Formats</title>
<author fullname="E. Harslem" initials="E." surname="Harslem">
<organization />
</author>

<author fullname="J.F. Heafner" initials="J.F." surname="Heafner">
<organization />
</author>

<date year="1970" day="1" month="December" />
</front>

<seriesInfo value="80" name="RFC" />
<format octets="17620" type="TXT" target="ftp://ftp.isi.edu/in-notes/rfc80.txt" />
</reference>


<reference target2="reference.RFC.0081.xml" anchor="RFC0081">
<front>
<title>Request for Reference Information</title>
<author fullname="J. Bouknight" initials="J." surname="Bouknight">
<organization>University of Illinois, Center for Advanced Computation</organization>

<address>
<postal>
<street>168 Engineering Research Laboratory</street>
<city>Urbana</city>
<region>IL</region>
<code>61801</code>
<country>US</country>
</postal>

</address>
</author>

<date year="1970" day="3" month="December" />

<abstract>
<t>Please ask your Technical Liaison Contact if he will send me as many references as he can in the subject areas of data communications and communications theory.</t>
</abstract>
</front>

<seriesInfo value="81" name="RFC" />
</reference>


<reference target2="reference.RFC.0082.xml" anchor="RFC0082">
<front>
<title>Network Meeting Notes</title>
<author fullname="Edwin W. Meyer Jr." initials="E." surname="Meyer">
<organization>Massachusetts Institute of Technology (MIT), Project MAC</organization>
</author>

<date year="1970" day="9" month="December" />

<abstract>
<t>The following summary was transcribed from notes I took at three network meetings held in Houston during the 1970 Fall Joint Computer Conference.</t>
</abstract>
</front>

<seriesInfo value="82" name="RFC" />
</reference>


<reference target2="reference.RFC.0083.xml" anchor="RFC0083">
<front>
<title>Language-machine for data reconfiguration</title>
<author fullname="R.H. Anderson" initials="R.H." surname="Anderson">
<organization />
</author>

<author fullname="E. Harslem" initials="E." surname="Harslem">
<organization />
</author>

<author fullname="J.F. Heafner" initials="J.F." surname="Heafner">
<organization />
</author>

<date year="1970" day="18" month="December" />
</front>

<seriesInfo value="83" name="RFC" />
<format octets="22253" type="TXT" target="ftp://ftp.isi.edu/in-notes/rfc83.txt" />
</reference>


<reference target2="reference.RFC.0084.xml" anchor="RFC0084">
<front>
<title>List of NWG/RFC's 1-80</title>
<author fullname="J. B. North" initials="J." surname="North">
<organization />
</author>

<date year="1970" day="23" month="December" />
</front>

<seriesInfo value="84" name="RFC" />
</reference>


<reference target2="reference.RFC.0085.xml" anchor="RFC0085">
<front>
<title>Network Working Group meeting</title>
<author fullname="Steve Crocker" initials="S." surname="Crocker">
<organization>University of California, Los Angeles (UCLA)</organization>
</author>

<date year="1970" day="28" month="December" />

<abstract>
<t>In line with the consensus of the Houston Network Working Group meeting in November, we will hold general Network Working Group meetings approximately every three months.  The Spring and Fall meetings will be synchronized to the Joint Computer Conferences.  The others will be moved around in order to promote exposure to the various sites and spread the burden of hosting.</t>
</abstract>
</front>

<seriesInfo value="85" name="RFC" />
</reference>


<reference target2="reference.RFC.0086.xml" anchor="RFC0086">
<front>
<title>Proposal for a Network Standard Format for a Data Stream to Control Graphics Display</title>
<author fullname="S. Croker" initials="S." surname="Crocker">
<organization>University of California, Los Angeles (UCLA)</organization>
</author>

<date year="1971" day="5" month="January" />

<abstract>
<t>*A typical arrangement of facilities is to have a console attached to a computer at the user's site, and to be using the computational facilities of a remote site.  Information entered by the user is transmitted to the remote Host, and output from the remote Host is transmitted back to the local user.  In this proposal I am concerned with specifying the form of the output stream for the case that the output portion of the console is a typical refresh display with point, vector and character drawing capability. Devices in this class include the DEC 338, DEC 340, IBM 2250, and IMLAC PDS-1.</t>
</abstract>
</front>

<seriesInfo value="86" name="RFC" />
</reference>


<reference target2="reference.RFC.0087.xml" anchor="RFC0087">
<front>
<title>Topic for Discussion at the Next Network Working Group Meeting</title>
<author fullname="A. Vezza" initials="A." surname="Vezza">
<organization>Massachusetts Institute of Technology (MIT), Project MAC</organization>

<address>
<postal>
<street>545 Technology Square</street>
<street>Room 830</street>
<city>Cambridge</city>
<region>MA</region>
<code>02139</code>
<country>US</country>
</postal>

<phone>+1 617 864 6900 x6026</phone>
</address>
</author>

<date year="1971" day="12" month="January" />

<abstract>
<t>Project MAC is planning a network graphics meeting to be held in  April.</t>
</abstract>
</front>

<seriesInfo value="87" name="RFC" />
</reference>


<reference target2="reference.RFC.0088.xml" anchor="RFC0088">
<front>
<title>NETRJS: A third level protocol for Remote Job Entry</title>
<author fullname="R.T. Braden" initials="R.T." surname="Braden">
<organization />
</author>

<author fullname="S.M. Wolfe" initials="S.M." surname="Wolfe">
<organization />
</author>

<date year="1971" day="13" month="January" />
</front>

<seriesInfo value="88" name="RFC" />
<format octets="19691" type="TXT" target="ftp://ftp.isi.edu/in-notes/rfc88.txt" />
</reference>


<reference target2="reference.RFC.0089.xml" anchor="RFC0089">
<front>
<title>Some historic moments in networking</title>
<author fullname="R.M. Metcalfe" initials="R.M." surname="Metcalfe">
<organization />
</author>

<date year="1971" day="19" month="January" />
</front>

<seriesInfo value="89" name="RFC" />
<format octets="16832" type="TXT" target="ftp://ftp.isi.edu/in-notes/rfc89.txt" />
</reference>


<reference target2="reference.RFC.0090.xml" anchor="RFC0090">
<front>
<title>CCN as a Network Service Center</title>
<author fullname="R. T. Braden" initials="R." surname="Braden">
<organization>University of California, Los Angeles  (UCLA), Campus Computing Network (CCN)</organization>
</author>

<date year="1971" day="25" month="January" />
</front>

<seriesInfo value="90" name="RFC" />
</reference>


<reference target2="reference.RFC.0091.xml" anchor="RFC0091">
<front>
<title>Proposed User-User Protocol</title>
<author fullname="George H. Mealy" initials="G." surname="Mealy">
<organization>Harvard University</organization>
</author>

<date year="1970" day="27" month="December" />
</front>

<seriesInfo value="91" name="RFC" />
</reference>


<reference target2="reference.RFC.0093.xml" anchor="RFC0093">
<front>
<title>Initial Connection Protocol</title>
<author fullname="A. McKenzie" initials="A." surname="McKenzie">
<organization>Bolt Baranek and Newman (BBN)</organization>
</author>

<date year="1971" day="27" month="January" />

<abstract>
<t>A review of the Initial Connection Protocol (ICP) first described in RFC #66and restated in RFC #80has revealed an area of ambiguity, which in turn reflects an ambiguity in the Host-Host Protocol Document No. 1.  This is the definition of the message sent over the connection from "Server socket #1".  In both referenced RFC's, the message is defined as "exactly an even 32 bit number".  It is not clear, however, whether this 32 bit number is meant to follow an eight-bit "message data type" code or not, stemming from the fact that the Host-Host Protocol makes provision for such codes but does not seem to absolutely demand them.</t>
</abstract>
</front>

<seriesInfo value="93" name="RFC" />
</reference>


<reference target2="reference.RFC.0094.xml" anchor="RFC0094">
<front>
<title>Some thoughts on Network Graphics</title>
<author fullname="E. Harslem" initials="E." surname="Harslem">
<organization />
</author>

<author fullname="J.F. Heafner" initials="J.F." surname="Heafner">
<organization />
</author>

<date year="1971" day="3" month="February" />
</front>

<seriesInfo value="94" name="RFC" />
<format octets="13516" type="TXT" target="ftp://ftp.isi.edu/in-notes/rfc94.txt" />
</reference>


<reference target2="reference.RFC.0095.xml" anchor="RFC0095">
<front>
<title>Distribution of NWG/RFC's through the NIC</title>
<author fullname="Steve Crocker" initials="S." surname="Crocker">
<organization>University of California, Los Angeles (UCLA), Computer Science Department</organization>

<address>
<postal>
<street>3732 Boelter Hall</street>
<city>Los Angeles</city>
<region>CA</region>
<code>90024</code>
<country>US</country>
</postal>

<phone>+1 213 825 2368</phone>
</address>
</author>

<date year="1971" day="4" month="February" />
</front>

<seriesInfo value="95" name="RFC" />
</reference>


<reference target2="reference.RFC.0096.xml" anchor="RFC0096">
<front>
<title>An Interactive Network Experiment to Study Modes of Access the Network Information Center</title>
<author fullname="Richard W. Watson" initials="R." surname="Watson">
<organization>Stanford Research Institute (SRI) International,  Augmentation Research Center (ARC)</organization>
</author>

<date year="1971" day="12" month="February" />
</front>

<seriesInfo value="96" name="RFC" />
</reference>


<reference target2="reference.RFC.0097.xml" anchor="RFC0097">
<front>
<title>First Cut at a Proposed Telnet Protocol</title>
<author fullname="J.T. Melvin" initials="J.T." surname="Melvin">
<organization />
</author>

<author fullname="R.W. Watson" initials="R.W." surname="Watson">
<organization />
</author>

<date year="1971" day="15" month="February" />
</front>

<seriesInfo value="97" name="RFC" />
</reference>


<reference target2="reference.RFC.0098.xml" anchor="RFC0098">
<front>
<title>Logger Protocol Proposal</title>
<author fullname="Edwin W. Meyer Jr." initials="E." surname="Meyer">
<organization />
</author>

<author fullname="Thomas P. Skinner" initials="T." surname="Skinner">
<organization />
</author>

<date year="1971" day="11" month="February" />

<abstract>
<t>With the ARPA Network Host-to-Host  Protocol  specified  and  at least  partially  implemented at a number of sites, the question of what steps should be taken next arises. There  appears  to  be  a  widespread feeling  among  Network  participants  that the first step should be the specification and implementation of what has  been  called  the  "Logger Protocol";  the  Computer  Network Group at project MAC agrees. The term "logger" has been commonly used to indicate the basic mechanism to  gain access  (to  "login")  to  a  system from a console. A network logger is intended to specify how the existing logger of  a  network  host  is  to interface to the network so as to permit a login from a console attached to another host.</t>
</abstract>
</front>

<seriesInfo value="98" name="RFC" />
</reference>


<reference target2="reference.RFC.0099.xml" anchor="RFC0099">
<front>
<title>Network Meeting</title>
<author fullname="P. Karp" initials="P." surname="Karp">
<organization>Mitre Corporation</organization>
</author>

<date year="1971" day="22" month="February" />

<abstract>
<t>The next meeting of the Network Working Group will be held in Atlantic City, New Jersey coincident with the SJCC.</t>
</abstract>
</front>

<seriesInfo value="99" name="RFC" />
</reference>


<reference target2="reference.RFC.0100.xml" anchor="RFC0100">
<front>
<title>Categorization and guide to NWG/RFCs</title>
<author fullname="P. Karp" initials="P." surname="Karp">
<organization>MITRE Corporation</organization>
</author>

<date year="1971" day="26" month="February" />

<abstract>
<t>The NWG/RFC Guide is an attempt to introduce some order into the NWG/RFC series, which now numbers 102.  The Guide categorizes the NWG/RFC notes, identifies topics under discussion and the relevant NWG/RFCs, and indicates whether the notes are current, obsolete, or superseded.</t>
</abstract>
</front>

<seriesInfo value="100" name="RFC" />
</reference>


<reference target2="reference.RFC.0101.xml" anchor="RFC0101">
<front>
<title>Notes on the Network Working Group meeting, Urbana, Illinois, February 17, 1971</title>
<author fullname="Richard W. Watson" initials="R." surname="Watson">
<organization>Stanford Research Institute (SRI) International,  Augmentation Research Center (ARC)</organization>
</author>

<date year="1971" day="23" month="February" />
</front>

<seriesInfo value="101" name="RFC" />
</reference>


<reference target2="reference.RFC.0102.xml" anchor="RFC0102">
<front>
<title>Output of the Host-Host Protocol glitch cleaning committee</title>
<author fullname="Steve Crocker" initials="S." surname="Crocker">
<organization>University California Los Angeles (UCLA)</organization>
</author>

<date year="1971" day="22" month="February" />

<abstract>
<t>At the NWG meeting in Urbana on 17-19 February 1971, a committee was established to look at the Host/Host protocol and see what changes were immediately desirable or necessary.</t>
</abstract>
</front>

<seriesInfo value="102" name="RFC" />
</reference>


<reference target2="reference.RFC.0103.xml" anchor="RFC0103">
<front>
<title>Implementation of Interrupt Keys</title>
<author fullname="R. B. Kalin" initials="R." surname="Kalin">
<organization>Massachusetts Institute of Technology (MIT), Lincoln Laboratory (LL)</organization>
</author>

<date year="1971" day="24" month="February" />

<abstract>
<t>The current protocol specifications contain a serious logical error in the implementation of the program interrupt function.  This paper discusses the problem and offers a solution that is simple to implement.</t>
</abstract>
</front>

<seriesInfo value="103" name="RFC" />
</reference>


<reference target2="reference.RFC.0104.xml" anchor="RFC0104">
<front>
<title>Link 191</title>
<author fullname="J. Postel" initials="J." surname="Postel">
<organization>University of California, Los Angeles (UCLA), Computer Science</organization>
</author>

<author fullname="C. Crocker" initials="C." surname="Crocker">
<organization>University of California, Los Angeles (UCLA), Computer Science</organization>
</author>

<date year="1971" day="25" month="February" />

<abstract>
<t>At the Network meeting at the University of Illinois, it was agreed to reserve a link for use in measurements. The link chosen was the highest unassigned link which was incorrectly calculated to be number 223. The correct number is 191. Therefore, Link 191 will be assigned for measurement use. Use of this link should be cleared with the Liasion Officer at the Network Measurement Center (NMC).</t>
</abstract>
</front>

<seriesInfo value="104" name="RFC" />
</reference>


<reference target2="reference.RFC.0105.xml" anchor="RFC0105">
<front>
<title abbrev="RJE at UCSB">Network Specifications for Remote Job Entry and Remote Job Output Retrieval at UCSB</title>
<author fullname="James E. White" initials="J." surname="White">
<organization>University of California, Santa Barbara (UCSB), Computer Research Lab.</organization>
</author>

<date year="1971" day="22" month="March" />

<abstract>
<t>In the discussions that follow, 'byte' means 8 bits, with those eight bits numbered 0-7 from left to right.</t>
</abstract>
</front>

<seriesInfo value="105" name="RFC" />
</reference>


<reference target2="reference.RFC.0106.xml" anchor="RFC0106">
<front>
<title>User/Server Site Protocol Network Host Questionnaire</title>
<author fullname="Thomas O&apos;Sullivan" initials="T." surname="O&apos;Sullivan">
<organization>RDS</organization>
</author>

<date year="1971" day="3" month="March" />

<abstract>
<t>The answer to a number of questions about the characteristics and operation of Network HOSTS will be useful to implementers of some early versions of TELNET, and/or to the USER/SERVER SITE PROTOCOL Committee in their consideration of a full TELNET PROTOCOL specification.</t>
</abstract>
</front>

<seriesInfo value="106" name="RFC" />
</reference>


<reference target2="reference.RFC.0107.xml" anchor="RFC0107">
<front>
<title>Output of the Host-Host Protocol Glitch Cleaning Committee</title>
<author fullname="Robert Bressler" initials="R." surname="Bressler">
<organization>University of California, Los Angeles (UCLA)</organization>
</author>

<author fullname="Steve Crocker" initials="S." surname="Crocker">
<organization>University of California, Los Angeles (UCLA)</organization>
</author>

<author fullname="William Crowter" initials="W." surname="Crowter">
<organization>University of California, Los Angeles (UCLA)</organization>
</author>

<author fullname="Gary Grossman" initials="G." surname="Grossman">
<organization>University of California, Los Angeles (UCLA)</organization>
</author>

<author fullname="Ray Tomlinson" initials="R." surname="Tomlinson">
<organization>University of California, Los Angeles (UCLA)</organization>
</author>

<author fullname="James Withe" initials="J." surname="Withe">
<organization>University of California, Los Angeles (UCLA)</organization>
</author>

<date year="1971" day="23" month="March" />
</front>

<seriesInfo value="107" name="RFC" />
</reference>


<reference target2="reference.RFC.0108.xml" anchor="RFC0108">
<front>
<title abbrev="Addendum to NWG Meeting Notes">Attendance list at the Urbana NWG meeting, February 17-19, 1971</title>
<author fullname="R. Watson" initials="R." surname="Watson">
<organization>Stanford Research Institute (SRI) International,  Augmentation Research Center (ARC)</organization>
</author>

<date year="1971" day="25" month="March" />

<abstract>
<t>Attendance List at the Urbana NWG Meeting</t>
</abstract>
</front>

<seriesInfo value="108" name="RFC" />
</reference>


<reference target2="reference.RFC.0109.xml" anchor="RFC0109">
<front>
<title>Level III Server Protocol for the Lincoln Laboratory NIC 360/67 Host</title>
<author fullname="J.M. Winett" initials="J.M." surname="Winett">
<organization />
</author>

<date year="1971" day="24" month="March" />
</front>

<seriesInfo value="109" name="RFC" />
</reference>


<reference target2="reference.RFC.0110.xml" anchor="RFC0110">
<front>
<title>Conventions for using an IBM 2741 terminal as a user console for access to network server hosts</title>
<author fullname="J.M. Winett" initials="J.M." surname="Winett">
<organization />
</author>

<date year="1971" day="25" month="March" />
</front>

<seriesInfo value="110" name="RFC" />
</reference>


<reference target2="reference.RFC.0111.xml" anchor="RFC0111">
<front>
<title>Pressure from the Chairman</title>
<author fullname="Steve Crocker" initials="S." surname="Crocker">
<organization>University of California, Los Angeles (UCLA)</organization>
</author>

<date year="1971" day="31" month="March" />

<abstract>
<t>It is time to set serious schedules for the implementation of NCP's  and Telnets. To  facilitate  matters,  John Heafner of Rand has agreed to monitor each site's progress and test its implementation.</t>
</abstract>
</front>

<seriesInfo value="111" name="RFC" />
</reference>


<reference target2="reference.RFC.0112.xml" anchor="RFC0112">
<front>
<title>User/Server Site Protocol: Network host questionnaire responses</title>
<author fullname="T.C. O&apos;Sullivan" initials="T.C." surname="O&apos;Sullivan">
<organization />
</author>

<date year="1971" day="1" month="April" />
</front>

<seriesInfo value="112" name="RFC" />
</reference>


<reference target2="reference.RFC.0113.xml" anchor="RFC0113">
<front>
<title>Network activity report: UCSB Rand</title>
<author fullname="E. F. Harslem" initials="E." surname="Harslem">
<organization>Rand Corporation</organization>
</author>

<author fullname="J. F. Heafner" initials="J." surname="Heafner">
<organization>Rand Corporation</organization>
</author>

<author fullname="J. E. White" initials="J." surname="White">
<organization />
</author>

<date year="1971" day="5" month="April" />
</front>

<seriesInfo value="113" name="RFC" />
</reference>


<reference target2="reference.RFC.0114.xml" anchor="RFC0114">
<front>
<title>File Transfer Protocol</title>
<author fullname="A.K. Bhushan" initials="A.K." surname="Bhushan">
<organization />
</author>

<date year="1971" day="10" month="April" />
</front>

<seriesInfo value="114" name="RFC" />
<format octets="38981" type="TXT" target="ftp://ftp.isi.edu/in-notes/rfc114.txt" />
</reference>


<reference target2="reference.RFC.0115.xml" anchor="RFC0115">
<front>
<title abbrev="Policies on Handling Documents">Some Network Information Center policies on handling documents</title>
<author fullname="R. Watson" initials="R." surname="Watson">
<organization>Stanford Research Institute (SRI) International,  Augmentation Research Center (ARC)</organization>
</author>

<author fullname="J. North" initials="J." surname="North">
<organization>Stanford Research Institute (SRI) International,  Augmentation Research Center (ARC)</organization>
</author>

<date year="1971" day="16" month="April" />
</front>

<seriesInfo value="115" name="RFC" />
</reference>


<reference target2="reference.RFC.0116.xml" anchor="RFC0116">
<front>
<title>Structure of the May NWG Meeting</title>
<author fullname="S. Crocker" initials="S." surname="Crocker">
<organization>University of California, Los Angeles (UCLA)</organization>
</author>

<date year="1971" day="12" month="April" />

<abstract>
<t>In order to use our time in Atlantic City more effectively, I would like to organize the meetings around discussions of advertised topics, with published status reports and position papers.  I envision our  time being divided into three phases.</t>
</abstract>
</front>

<seriesInfo value="116" name="RFC" />
</reference>


<reference target2="reference.RFC.0117.xml" anchor="RFC0117">
<front>
<title>Some comments on the official protocol</title>
<author fullname="J. Wong" initials="J." surname="Wong">
<organization>University of California, Los Angeles (UCLA)</organization>
</author>

<date year="1971" day="7" month="April" />

<abstract>
<t>Document No. 1 and NWG/RFC No. 107gave a very detailed description of connection establishment, connection termination and flow control over the Network.  Throughout the implementation of the NCP it was discovered that the handling of ERR control commands, messages of types other than 0 (regular), 4 (nop), and 5 (rfnm), and messages with the From-imp bit on are not well discussed so that problems arise when they occur.</t>

<t>The Protocol is not complete if the above situations are not handled clearly, and the Host-Host Protocol Glitch Cleaning Committee should take this into consideration.  In this document, experience with these unfavorable situations and suggestions for handling are given:</t>
</abstract>
</front>

<seriesInfo value="117" name="RFC" />
</reference>


<reference target2="reference.RFC.0118.xml" anchor="RFC0118">
<front>
<title abbrev="Recommendations for Facility Documentation">Recommendations for facility documentation</title>
<author fullname="Richard Watson" initials="R." surname="Watson">
<organization>Stanford Research Institute (SRI) International,  Augmentation Research Center (ARC)</organization>
</author>

<date year="1971" day="16" month="April" />

<abstract>
<t>INFORMATION REQUIRED FOR EACH SERVICE AVAILABLE TO THE NETWORK</t>

<t>There are two classes of information which a site needs to provide for each service or process it makes available over the Network:</t>

<t>i) information required by system programmers in order to establish a connection to the facility</t>

<t>ii) information required by a user to gain access to and use the facility</t>

<t>The above two basic kinds of information which need to be in each facility description will comprise a "functional document" (see RFC 115, NIC (5822,) for a description of functional documents and recommended procedures for updating them).</t>
</abstract>
</front>

<seriesInfo value="118" name="RFC" />
</reference>


<reference target2="reference.RFC.0119.xml" anchor="RFC0119">
<front>
<title>Network Fortran subprograms</title>
<author fullname="M. Krilanovich" initials="M." surname="Krilanovich">
<organization />
</author>

<date year="1971" day="21" month="April" />
</front>

<seriesInfo value="119" name="RFC" />
</reference>


<reference target2="reference.RFC.0120.xml" anchor="RFC0120">
<front>
<title>Network PL1 subprograms</title>
<author fullname="Mark Krilanovich" initials="M." surname="Krilanovich">
<organization>University of California, Santa Barbara (UCSB), Computer Research Lab</organization>
</author>

<date year="1971" day="21" month="April" />
</front>

<seriesInfo value="120" name="RFC" />
</reference>


<reference target2="reference.RFC.0121.xml" anchor="RFC0121">
<front>
<title>Network on-line operators</title>
<author fullname="M. Krilanovich" initials="M." surname="Krilanovich">
<organization />
</author>

<date year="1971" day="21" month="April" />
</front>

<seriesInfo value="121" name="RFC" />
<format octets="29419" type="TXT" target="ftp://ftp.isi.edu/in-notes/rfc121.txt" />
</reference>


<reference target2="reference.RFC.0122.xml" anchor="RFC0122">
<front>
<title abbrev="Simple-Minded file System">Network specifications for UCSB's Simple-Minded File System</title>
<author fullname="James E. White" initials="J." surname="White">
<organization>University of California, Santa Barbara (UCSB)</organization>
</author>

<date year="1971" day="26" month="April" />
</front>

<seriesInfo value="122" name="RFC" />
</reference>


<reference target2="reference.RFC.0123.xml" anchor="RFC0123">
<front>
<title>Proffered Official ICP</title>
<author fullname="S. Crocker" initials="S." surname="Crocker">
<organization>University of California, Los Angeles (UCLA)</organization>
</author>

<date year="1971" day="20" month="April" />

<abstract>
<t>By Initial Connection Protocol (ICP), I mean a third level protocol which is initiated by a user process at one site in order to contact a server process at another site.  Typically, the user process will be a Telnet and the server process will be a logger, but there may be other cases.</t>

<t>In this RFC, I wish to describe a family of ICPs suitable for establishing one pair of connections (one in each direction) between any user process and any server process, and to propose further a particular subset of this family as the standard ICP for connecting user processes to loggers on systems which accept teletype-like devices.</t>
</abstract>
</front>

<seriesInfo value="123" name="RFC" />
</reference>


<reference target2="reference.RFC.0124.xml" anchor="RFC0124">
<front>
<title>Typographical error in RFC 107</title>
<author fullname="J. Melvin" initials="J." surname="Melvin">
<organization>Network Information Center (NIC)</organization>
</author>

<date year="1971" day="19" month="April" />

<abstract>
<t>On page 7 of RFC 107, the RTS (1.) should be an STR.</t>
</abstract>
</front>

<seriesInfo value="124" name="RFC" />
</reference>


<reference target2="reference.RFC.0125.xml" anchor="RFC0125">
<front>
<title>Response to RFC 86: Proposal for Network Standard Format for a Graphics Data Stream</title>
<author fullname="John McConnell" initials="J." surname="McConnell">
<organization>Ames Research Center</organization>
</author>

<date year="1971" day="18" month="April" />

<abstract>
<t>The basic approach of transmitting an intermediate, device independent language which is translated into specific device codes at the receiving host is sound. It appears to be the only approach that will allow thought to be centered on picture descriptions.</t>
</abstract>
</front>

<seriesInfo value="125" name="RFC" />
</reference>


<reference target2="reference.RFC.0126.xml" anchor="RFC0126">
<front>
<title>Graphics Facilities at Ames Research Center</title>
<author fullname="John McConnell" initials="J." surname="McConnell">
<organization>Ames Research Center</organization>
</author>

<date year="1971" day="18" month="April" />

<abstract>
<t>This note is intended as a response to an RFC which suggested that nodes describe their graphics environment.</t>
</abstract>
</front>

<seriesInfo value="126" name="RFC" />
</reference>


<reference target2="reference.RFC.0127.xml" anchor="RFC0127">
<front>
<title>Comments on RFC 123</title>
<author fullname="J. Postel" initials="J." surname="Postel">
<organization>University of California, Los Angeles (UCLA), Computer Science</organization>
</author>

<date year="1971" day="20" month="April" />

<abstract>
<t>The following is my interpretation of the exchange between NCP's which would be necessary to carry out the Initial Connection Protocol of RFC123.</t>
</abstract>
</front>

<seriesInfo value="127" name="RFC" />
</reference>


<reference target2="reference.RFC.0128.xml" anchor="RFC0128">
<front>
<title>Bytes</title>
<author fullname="J. Postel" initials="J." surname="Postel">
<organization />
</author>

<date year="1971" day="21" month="April" />
</front>

<seriesInfo value="128" name="RFC" />
<format octets="2745" type="TXT" target="ftp://ftp.isi.edu/in-notes/rfc128.txt" />
</reference>


<reference target2="reference.RFC.0129.xml" anchor="RFC0129">
<front>
<title>Request for comments on socket name structure</title>
<author fullname="E. E. Harslem" initials="E." surname="Harslem">
<organization>Rand Corporation</organization>
</author>

<author fullname="J. F. Heafner" initials="J." surname="Heafner">
<organization>Rand Corporation</organization>
</author>

<author fullname="E. Meyer" initials="E." surname="Meyer">
<organization>Massachusetts Institute of Technology (MIT)</organization>
</author>

<date year="1971" day="22" month="April" />
</front>

<seriesInfo value="129" name="RFC" />
</reference>


<reference target2="reference.RFC.0130.xml" anchor="RFC0130">
<front>
<title>Response to RFC 111: Pressure from the chairman</title>
<author fullname="J. Heafner" initials="J." surname="Heafner">
<organization>Rand Corporation</organization>
</author>

<date year="1971" day="22" month="April" />

<abstract>
<t>The purpose of RFC #111, as I interpret it, is two-fold:  1) To establish realistic implementation schedules and to make them known to the Network community so as to expedite everyone's planning of productive use of Network Services.  2) To uncover implementation techniques and strategies that were most successful and might be useful in future implementations.</t>
</abstract>
</front>

<seriesInfo value="130" name="RFC" />
</reference>


<reference target2="reference.RFC.0131.xml" anchor="RFC0131">
<front>
<title>Response to RFC 116: May NWG meeting</title>
<author fullname="E. Harslem" initials="E." surname="Harslem">
<organization>Rand Corporation</organization>
</author>

<author fullname="J. Heafner" initials="J." surname="Heafner">
<organization>Rand Corporation</organization>
</author>

<date year="1971" day="22" month="April" />
</front>

<seriesInfo value="131" name="RFC" />
</reference>


<reference target2="reference.RFC.0132.xml" anchor="RFC0132">
<front>
<title>Typographical Error in RFC 107</title>
<author fullname="Jim White" initials="J." surname="White">
<organization>University of California, Santa Barbara (UCSB)</organization>
</author>

<date year="1971" day="28" month="April" />

<abstract>
<t>On page 5 of RFC 107, at the end of the section titled 'V. Flow Control', the partial sentence:</t>

<t>Each of these numbers is interpreted as "the number of 128ths of the current allocation" to be returned if it is in the range zero to 128...</t>

<t>should read:</t>

<t>...if it is the range of zero to 127,...</t>
</abstract>
</front>

<seriesInfo value="132" name="RFC" />
</reference>


<reference target2="reference.RFC.0133.xml" anchor="RFC0133">
<front>
<title>File Transfer and Recovery</title>
<author fullname="R.L. Sunberg" initials="R.L." surname="Sunberg">
<organization>Harvard University</organization>
</author>

<date year="1971" day="27" month="April" />
</front>

<seriesInfo value="133" name="RFC" />
</reference>


<reference target2="reference.RFC.0134.xml" anchor="RFC0134">
<front>
<title>Network Graphics meeting</title>
<author fullname="A. Vezza" initials="A." surname="Vezza">
<organization>Massachusetts Institute of Technology (MIT), Project MAC</organization>

<address>
<postal>
<street>545 Technology Square</street>
<street>Room 201</street>
<city>Cambridge</city>
<region>MA</region>
<code>02139</code>
<country>US</country>
</postal>

<phone>+1 617 864 6900 x1458</phone>
</address>
</author>

<date year="1971" day="29" month="April" />

<abstract>
<t>Project MAC will host a Network Graphics Meeting on the 18th, 19th, and 20th of July 1971.</t>
</abstract>
</front>

<seriesInfo value="134" name="RFC" />
</reference>


<reference target2="reference.RFC.0135.xml" anchor="RFC0135">
<front>
<title>Response to NWG/RFC 110</title>
<author fullname="W. Hathaway" initials="W." surname="Hathaway">
<organization />
</author>

<date year="1971" day="29" month="April" />
</front>

<seriesInfo value="135" name="RFC" />
<format octets="5282" type="TXT" target="ftp://ftp.isi.edu/in-notes/rfc135.txt" />
</reference>


<reference target2="reference.RFC.0136.xml" anchor="RFC0136">
<front>
<title>Host accounting and administrative procedures</title>
<author fullname="R.E. Kahn" initials="R.E." surname="Kahn">
<organization />
</author>

<date year="1971" day="29" month="April" />
</front>

<seriesInfo value="136" name="RFC" />
<format octets="8016" type="TXT" target="ftp://ftp.isi.edu/in-notes/rfc136.txt" />
</reference>


<reference target2="reference.RFC.0137.xml" anchor="RFC0137">
<front>
<title>Telnet Protocol - a proposed document</title>
<author fullname="T.C. O&apos;Sullivan" initials="T.C." surname="O&apos;Sullivan">
<organization />
</author>

<date year="1971" day="30" month="April" />
</front>

<seriesInfo value="137" name="RFC" />
<format octets="17606" type="TXT" target="ftp://ftp.isi.edu/in-notes/rfc137.txt" />
</reference>


<reference target2="reference.RFC.0138.xml" anchor="RFC0138">
<front>
<title>Status report on proposed Data Reconfiguration Service</title>
<author fullname="R.H. Anderson" initials="R.H." surname="Anderson">
<organization />
</author>

<author fullname="V.G. Cerf" initials="V.G." surname="Cerf">
<organization />
</author>

<author fullname="E. Harslem" initials="E." surname="Harslem">
<organization />
</author>

<author fullname="J.F. Heafner" initials="J.F." surname="Heafner">
<organization />
</author>

<author fullname="J. Madden" initials="J." surname="Madden">
<organization />
</author>

<author fullname="R.M. Metcalfe" initials="R.M." surname="Metcalfe">
<organization />
</author>

<author fullname="A. Shoshani" initials="A." surname="Shoshani">
<organization />
</author>

<author fullname="J.E. White" initials="J.E." surname="White">
<organization />
</author>

<author fullname="D.C.M. Wood" initials="D.C.M." surname="Wood">
<organization />
</author>

<date year="1971" day="28" month="April" />
</front>

<seriesInfo value="138" name="RFC" />
<format octets="46641" type="TXT" target="ftp://ftp.isi.edu/in-notes/rfc138.txt" />
</reference>


<reference target2="reference.RFC.0139.xml" anchor="RFC0139">
<front>
<title>Discussion of Telnet Protocol</title>
<author fullname="T.C. O&apos;Sullivan" initials="T.C." surname="O&apos;Sullivan">
<organization />
</author>

<date year="1971" day="7" month="May" />
</front>

<seriesInfo value="139" name="RFC" />
<format octets="26085" type="TXT" target="ftp://ftp.isi.edu/in-notes/rfc139.txt" />
</reference>


<reference target2="reference.RFC.0140.xml" anchor="RFC0140">
<front>
<title>Agenda for the May NWG meeting</title>
<author fullname="Steve Crocker" initials="S." surname="Crocker">
<organization>University of California, Los Angeles (UCLA)</organization>
</author>

<date year="1971" day="4" month="May" />

<abstract>
<t>The NWG meeting will be from 8 p.m., Sunday, May 16 through Wednesday evening May 19.</t>
</abstract>
</front>

<seriesInfo value="140" name="RFC" />
</reference>


<reference target2="reference.RFC.0141.xml" anchor="RFC0141">
<front>
<title abbrev="Comments on RFC 141">Comments on RFC 114: A File Transfer Protocol</title>
<author fullname="E. F. Harslem" initials="E." surname="Harslem">
<organization>Rand Corporation</organization>
</author>

<author fullname="J. F. Haefner" initials="J." surname="Haefner">
<organization>Rand Corporation</organization>
</author>

<date year="1971" day="29" month="April" />

<abstract>
<t>A file transfer protocol is needed.  Bushan's proposal would satisfy a particular current need that we have, as well as short-term envisioned needs</t>
</abstract>
</front>

<seriesInfo value="141" name="RFC" />
</reference>


<reference target2="reference.RFC.0142.xml" anchor="RFC0142">
<front>
<title>Time-Out Mechanism in the Host-Host Protocol</title>
<author fullname="Charley Kline" initials="C." surname="Kline">
<organization>University California Los Angeles (UCLA), Network Measurement Center (NMC)</organization>
</author>

<author fullname="Johnny Wong" initials="J." surname="Wong">
<organization>University California Los Angeles (UCLA), Network Measurement Center (NMC)</organization>
</author>

<date year="1971" day="3" month="May" />

<abstract>
<t>On sending a message to a foreign site, the following situations can occur:</t>

<t>1. Destination IMP down - Type 7 message is returned.</t>

<t>2. Destination IMP up but destination IMP-HOST interface is down - Type 7 message is returned.</t>

<t>3. Destination IMP and IMP-HOST interface up, but IMP-HOST inter-face is not taking messages - Type 9 message is returned after IMP time-out (ask BBN for time).</t>

<t>4. Destination IMP and IMP-HOST interface up and IMP-HOST interface is taking messages - Type 5 (rfnm) message is returned.</t>

<t>A suggestion for handling type 7 and type 9 messages has been made in NWG/RFC #117.  In this document we would like to discuss in detail the problem: what should happen to the HOST-HOST protocol on receiving a rfnm?</t>
</abstract>
</front>

<seriesInfo value="142" name="RFC" />
</reference>


<reference target2="reference.RFC.0143.xml" anchor="RFC0143">
<front>
<title>Regarding proffered official ICP</title>
<author fullname="W. Naylor" initials="W." surname="Naylor">
<organization>University California Los Angeles (UCLA), Network Measurement Center (NMC)</organization>
</author>

<author fullname="J. Wong" initials="J." surname="Wong">
<organization>University California Los Angeles (UCLA), Network Measurement Center (NMC)</organization>
</author>

<author fullname="C. Kline" initials="C." surname="Kline">
<organization>University California Los Angeles (UCLA), Network Measurement Center (NMC)</organization>
</author>

<author fullname="J. Postel" initials="J." surname="Postel">
<organization>University California Los Angeles (UCLA), Network Measurement Center (NMC)</organization>
</author>

<date year="1971" day="3" month="May" />

<abstract>
<t>We should like to comment on a race condition discovered in the ICP as proposed in NWG/RFC #123. The problem arises when the server attempts to initiate a second connection to the user's receive socket and the first connection is not yet closed.</t>
</abstract>
</front>

<seriesInfo value="143" name="RFC" />
</reference>


<reference target2="reference.RFC.0144.xml" anchor="RFC0144">
<front>
<title>Data sharing on computer networks</title>
<author fullname="A. Shoshani" initials="A." surname="Shoshani">
<organization />
</author>

<date year="1971" day="30" month="April" />
</front>

<seriesInfo value="144" name="RFC" />
<format octets="13744" type="TXT" target="ftp://ftp.isi.edu/in-notes/rfc144.txt" />
</reference>


<reference target2="reference.RFC.0145.xml" anchor="RFC0145">
<front>
<title>Initial Connection Protocol Control Commands</title>
<author fullname="J. Postel" initials="J." surname="Postel">
<organization />
</author>

<date year="1971" day="4" month="May" />
</front>

<seriesInfo value="145" name="RFC" />
<format octets="2490" type="TXT" target="ftp://ftp.isi.edu/in-notes/rfc145.txt" />
<format octets="552114" type="PS" target="ftp://ftp.isi.edu/in-notes/rfc145.ps" />
<format octets="15869" type="PDF" target="ftp://ftp.isi.edu/in-notes/rfc145.pdf" />
</reference>


<reference target2="reference.RFC.0146.xml" anchor="RFC0146">
<front>
<title>Views on issues relevant to data sharing on computer networks</title>
<author fullname="P. M. Karp" initials="P." surname="Karp">
<organization>Mitre Corporation</organization>
</author>

<author fullname="D. B. McKay" initials="D." surname="McKay">
<organization>International Business Machines (IBM)</organization>
</author>

<author fullname="D. C. Wood" initials="D." surname="Wood">
<organization>Mitre Corporation</organization>
</author>

<date year="1971" day="12" month="May" />

<abstract>
<t>The formation of a committee to address the problems of achieving data sharing on the ARPA Network, as suggested by Arie Shoshani (RFC #140) is desirable at this point of network development.</t>
</abstract>
</front>

<seriesInfo value="146" name="RFC" />
</reference>


<reference target2="reference.RFC.0147.xml" anchor="RFC0147">
<front>
<title>Definition of a socket</title>
<author fullname="Joel M. Winett" initials="J." surname="Winett">
<organization>Massachusetts Institute of Technology (MIT), Lincoln Laboratory</organization>
</author>

<date year="1971" day="7" month="May" />

<abstract>
<t>A socket is defined to be the unique identification to or from which information is transmitted in the network. The socket is specified as a 32 bit number with even sockets identifying receiving sockets and odd sockets identifying sending sockets. A socket is also identified by the host in which the sending or receiving processer is located.</t>
</abstract>
</front>

<seriesInfo value="147" name="RFC" />
</reference>


<reference target2="reference.RFC.0148.xml" anchor="RFC0148">
<front>
<title>Comments on RFC 123</title>
<author fullname="A. Bhushan" initials="A." surname="Bhushan">
<organization>Massachusetts Institute of Technology (MIT), Project MAC</organization>
</author>

<date year="1971" day="7" month="May" />

<abstract>
<t>The requirement that byte size 's' be 32-bits for the initial connection imposes some severe strains on some of the 36-bit machines.</t>
</abstract>
</front>

<seriesInfo value="148" name="RFC" />
</reference>


<reference target2="reference.RFC.0149.xml" anchor="RFC0149">
<front>
<title>Best Laid Plans</title>
<author fullname="Steve Crocker" initials="S." surname="Crocker">
<organization>University of California, Los Angeles (UCLA)</organization>
</author>

<date year="1971" day="10" month="May" />

<abstract>
<t>Dr. Roberts informs me that it is now unlikely that he will be able to attend the Monday afternoon session of the NWG meeting, but that he will be able to attend the Tuesday evening session.</t>
</abstract>
</front>

<seriesInfo value="149" name="RFC" />
</reference>


<reference target2="reference.RFC.0150.xml" anchor="RFC0150">
<front>
<title>Use of IPC Facilities: A Working Paper</title>
<author fullname="Richard B. Kalin" initials="R." surname="Kalin">
<organization>Massachusetts Institute of Technology (MIT), Lincoln Laboratory</organization>
</author>

<date year="1971" day="5" month="May" />

<abstract>
<t>***A WORKING PAPER*** This material has not been reviewed for public release and is intended only for use within the ARPA network. It should not be quoted or cited in any publication not related to the ARPA network.</t>
</abstract>
</front>

<seriesInfo value="150" name="RFC" />
</reference>


<reference target2="reference.RFC.0151.xml" anchor="RFC0151">
<front>
<title>Comments on a proffered official ICP: RFCs 123, 127</title>
<author fullname="A. Shoshani" initials="A." surname="Shoshani">
<organization>System Development Corporation (SDC)</organization>
</author>

<date year="1971" day="10" month="May" />

<abstract>
<t>Bob Long at SDC noticed that the order in which messages go out to the network depend on the local NCP.</t>
</abstract>
</front>

<seriesInfo value="151" name="RFC" />
</reference>


<reference target2="reference.RFC.0152.xml" anchor="RFC0152">
<front>
<title>SRI Artificial Intelligence status report</title>
<author fullname="M. Wilber" initials="M." surname="Wilber">
<organization>Stanford Research Institute (SRI) International,  Augmentation Research Center (ARC)</organization>
</author>

<date year="1971" day="10" month="May" />

<abstract>
<t>The Stanford Research Institute's Artificial Intelligence Group (SRAI in the four-letter abbreviations) expects connection to the ARPA net as a research center after conversion this summer to a TENEX from our current PDP-10.</t>
</abstract>
</front>

<seriesInfo value="152" name="RFC" />
</reference>


<reference target2="reference.RFC.0153.xml" anchor="RFC0153">
<front>
<title>SRI ARC-NIC status</title>
<author fullname="J.T. Melvin" initials="J.T." surname="Melvin">
<organization />
</author>

<author fullname="R.W. Watson" initials="R.W." surname="Watson">
<organization />
</author>

<date year="1971" day="15" month="May" />
</front>

<seriesInfo value="153" name="RFC" />
<format octets="8573" type="TXT" target="ftp://ftp.isi.edu/in-notes/rfc153.txt" />
</reference>


<reference target2="reference.RFC.0154.xml" anchor="RFC0154">
<front>
<title>Exposition Style</title>
<author fullname="S. Crocker" initials="S." surname="Crocker">
<organization>University of California, Los Angeles (UCLA)</organization>
</author>

<date year="1971" day="12" month="May" />

<abstract>
<t>As a pedagogical device for describing functions such as the one below</t>

<t>|
           |                  +-----------------
           |                 /:
           |                / :
           |               /  :
           |              /   :
           |             /    :
           |            /     :
      -----+------------------------------------
           |                  a
           |</t>

<t>where two formulae, f1 and f2, are necessary for adjoining domains but the function is continous at the boundary point, I usually write the description in the form</t>
</abstract>
</front>

<seriesInfo value="154" name="RFC" />
</reference>


<reference target2="reference.RFC.0155.xml" anchor="RFC0155">
<front>
<title>ARPA Network mailing lists</title>
<author fullname="J.B. North" initials="J.B." surname="North">
<organization>ARPA Network</organization>
</author>

<date year="1971" day="1" month="May" />

<abstract>
<t>Note:  This list includes all Network Liaisons and others who should receive initial distribution of formal documents.  It supersedes RFC 95, and corresponds to Current Directory of Network Participants, NIC 5799.</t>
</abstract>
</front>

<seriesInfo value="155" name="RFC" />
</reference>


<reference target2="reference.RFC.0156.xml" anchor="RFC0156">
<front>
<title>Status of the Illinois site: Response to RFC 116</title>
<author fullname="J. Bouknight" initials="J." surname="Bouknight">
<organization>University of Illinois</organization>
</author>

<date year="1971" day="26" month="April" />

<abstract>
<t>As of the date of the report, 26 April, the Illinois Site has complete operational hardware connecting the PDP-11 system with the IMP.</t>
</abstract>
</front>

<seriesInfo value="156" name="RFC" />
</reference>


<reference target2="reference.RFC.0157.xml" anchor="RFC0157">
<front>
<title>Invitation to the Second Symposium on Problems in the Optimization of Data Communications Systems</title>
<author fullname="V.G. Cerf" initials="V.G." surname="Cerf">
<organization />
</author>

<date year="1971" day="12" month="May" />
</front>

<seriesInfo value="157" name="RFC" />
<format octets="3159" type="TXT" target="ftp://ftp.isi.edu/in-notes/rfc157.txt" />
</reference>


<reference target2="reference.RFC.0158.xml" anchor="RFC0158">
<front>
<title>Telnet Protocol: A Proposed Document</title>
<author fullname="T.C. O&apos;Sullivan" initials="T.C." surname="O&apos;Sullivan">
<organization />
</author>

<date year="1971" day="19" month="May" />
</front>

<seriesInfo value="158" name="RFC" />
</reference>


<reference target2="reference.RFC.0160.xml" anchor="RFC0160">
<front>
<title>RFC brief list</title>
<author>
<organization>SRI/Network Information Center</organization>
</author>

<date year="1971" day="18" month="May" />
</front>

<seriesInfo value="160" name="RFC" />
<format octets="12173" type="TXT" target="ftp://ftp.isi.edu/in-notes/rfc160.txt" />
</reference>


<reference target2="reference.RFC.0161.xml" anchor="RFC0161">
<front>
<title>Solution to the race condition in the ICP</title>
<author fullname="A. Shoshani" initials="A." surname="Shoshani">
<organization>System Development Corporation (SDC)</organization>
</author>

<date year="1971" day="19" month="May" />

<abstract>
<t>In NWG/RFC #143a race condition in the ICP was described and a solution was suggested. The problem arises because the Host-Host protocol does not specify what the NCP should do when it gets more than one request of STR (or RTS) to the same socket. As a result this decision depends on the particular implementation: some may queue these requests (SDC for example), some will refuse a request if the socket is already connected (UCLA for example), etc.</t>
</abstract>
</front>

<seriesInfo value="161" name="RFC" />
</reference>


<reference target2="reference.RFC.0162.xml" anchor="RFC0162">
<front>
<title>NETBUGGER3</title>
<author fullname="M. Kampe" initials="M." surname="Kampe">
<organization />
</author>

<date year="1971" day="22" month="May" />
</front>

<seriesInfo value="162" name="RFC" />
<format octets="3153" type="TXT" target="ftp://ftp.isi.edu/in-notes/rfc162.txt" />
</reference>


<reference target2="reference.RFC.0163.xml" anchor="RFC0163">
<front>
<title>Data transfer protocols</title>
<author fullname="V. Cerf" initials="V." surname="Cerf">
<organization>University of California, Los Angeles  (UCLA), Computer Science Department, Network Measurement Center (NMC)</organization>
</author>

<date year="1971" day="19" month="May" />

<abstract>
<t>This is an informal statement of material discussed at the SJCC.  There are two problems.</t>

<t>1.  Movement of data from one site to another.</t>

<t>2.  Interpretation of the data at receiving site.</t>
</abstract>
</front>

<seriesInfo value="163" name="RFC" />
</reference>


<reference target2="reference.RFC.0164.xml" anchor="RFC0164">
<front>
<title>Minutes of Network Working Group meeting, 5/16 through 5/19/71</title>
<author fullname="J.F. Heafner" initials="J.F." surname="Heafner">
<organization />
</author>

<date year="1971" day="25" month="May" />
</front>

<seriesInfo value="164" name="RFC" />
<format octets="58597" type="TXT" target="ftp://ftp.isi.edu/in-notes/rfc164.txt" />
</reference>


<reference target2="reference.RFC.0165.xml" anchor="RFC0165">
<front>
<title>Proffered official Initial Connection Protocol</title>
<author fullname="J. Postel" initials="J." surname="Postel">
<organization />
</author>

<date year="1971" day="25" month="May" />
</front>

<seriesInfo value="165" name="RFC" />
</reference>


<reference target2="reference.RFC.0166.xml" anchor="RFC0166">
<front>
<title>Data Reconfiguration Service: An implementation specification</title>
<author fullname="R.H. Anderson" initials="R.H." surname="Anderson">
<organization />
</author>

<author fullname="V.G. Cerf" initials="V.G." surname="Cerf">
<organization />
</author>

<author fullname="E. Harslem" initials="E." surname="Harslem">
<organization />
</author>

<author fullname="J.F. Heafner" initials="J.F." surname="Heafner">
<organization />
</author>

<author fullname="J. Madden" initials="J." surname="Madden">
<organization />
</author>

<author fullname="R.M. Metcalfe" initials="R.M." surname="Metcalfe">
<organization />
</author>

<author fullname="A. Shoshani" initials="A." surname="Shoshani">
<organization />
</author>

<author fullname="J.E. White" initials="J.E." surname="White">
<organization />
</author>

<author fullname="D.C.M. Wood" initials="D.C.M." surname="Wood">
<organization />
</author>

<date year="1971" day="25" month="May" />
</front>

<seriesInfo value="166" name="RFC" />
<format octets="42094" type="TXT" target="ftp://ftp.isi.edu/in-notes/rfc166.txt" />
</reference>


<reference target2="reference.RFC.0167.xml" anchor="RFC0167">
<front>
<title>Socket conventions reconsidered</title>
<author fullname="Athay Bhushan" initials="A." surname="Bhushan">
<organization>Massachusetts Institute of Technology (MIT), Project MAC</organization>
</author>

<author fullname="Bob Metcalfe" initials="B." surname="Metcalfe">
<organization>Harvard University</organization>
</author>

<author fullname="Joel Winett" initials="J." surname="Winett">
<organization>Massachusetts Institute of Technology  (MIT), Lincoln Laboratory</organization>
</author>

<date year="1971" day="24" month="May" />

<abstract>
<t>The current NCP Protocol says nothing about how hosts should assign socket numbers to process ports, except that the low-order bit is to specify socket gender (i.e., send or receive). Two recent proposals call for additional network-wide conventions on the 32-bit socket-number. The first proposal asks that a portion of the socket number be reserved for a network-unique user number for accounting and access control. The second proposal asks that the high-order 16 bits of the socket number be zero to assist smaller hosts in reducing the space required for socket number tables.</t>

<t>It is recommended that both of these proposals be set aside.  Because a large perturbation of the current NCP Protocol is required to provide adequate handles for accounting and access control, and because the socket number is already underpowered for its use, it is recommended that both proposals be set aside until serious consideration can be given to a major NCP Protocol overhaul</t>
</abstract>
</front>

<seriesInfo value="167" name="RFC" />
</reference>


<reference target2="reference.RFC.0168.xml" anchor="RFC0168">
<front>
<title>ARPA Network mailing lists</title>
<author fullname="J.B. North" initials="J.B." surname="North">
<organization />
</author>

<date year="1971" day="26" month="May" />

<abstract>
<t>The following three lists are those to be used for distribution of Network documents. List A should be used by sites when they distribute their own documents. to get RFC's to Liaisons as quickly as possible. All but local mail should be sent Air Mail. Lists B and C will be used by NIC in making distribution of copies to non-site Network Participants and to Station Agents. These Lists supercede RPC 95and RFC 155. For phone numbers and lists of names by sites see the Current Directory of Network Participants.</t>
</abstract>
</front>

<seriesInfo value="168" name="RFC" />
</reference>


<reference target2="reference.RFC.0169.xml" anchor="RFC0169">
<front>
<title>Computer networks</title>
<author fullname="S.D. Crocker" initials="S.D." surname="Crocker">
<organization />
</author>

<date year="1971" day="27" month="May" />
</front>

<seriesInfo value="169" name="RFC" />
</reference>


<reference target2="reference.RFC.0170.xml" anchor="RFC0170">
<front>
<title>RFC List by Number</title>
<author>
<organization />
</author>

<date year="1971" day="1" month="June" />
</front>

<seriesInfo value="170" name="RFC" />
</reference>


<reference target2="reference.RFC.0171.xml" anchor="RFC0171">
<front>
<title>The Data Transfer Protocol</title>
<author fullname="Abhay Bhushan" initials="A." surname="Bhushan">
<organization>Massachusetts Institute of Technology (MIT)</organization>
</author>

<author fullname="Bob Braden" initials="B." surname="Braden">
<organization>University of California, Los Angeles (UCLA)</organization>
</author>

<author fullname="Will Crowther" initials="W." surname="Crowther">
<organization>Bolt Beranek and Newman (BBN)</organization>
</author>

<author fullname="Eric Harslem" initials="E." surname="Harslem">
<organization>The Rand Corporation</organization>
</author>

<author fullname="John Heafner" initials="J." surname="Heafner">
<organization>The Rand Corporation</organization>
</author>

<author fullname="Alex McKenzie" initials="A." surname="McKenzie">
<organization>Bolt Beranek and Newman (BBN)</organization>
</author>

<author fullname="John Melvin" initials="J." surname="Melvin">
<organization>Stanford Research Institute (SRI)</organization>
</author>

<author fullname="Bob Sundberg" initials="B." surname="Sundberg">
<organization>Harvard University</organization>
</author>

<author fullname="Dick Watson" initials="D." surname="Watson">
<organization>Stanford Research Institute (SRI)</organization>
</author>

<author fullname="Jim White" initials="J." surname="White">
<organization>University of California, Santa Barbara (UCSB)</organization>
</author>

<date year="1971" day="1" month="June" />
</front>

<seriesInfo value="171" name="RFC" />
</reference>


<reference target2="reference.RFC.0172.xml" anchor="RFC0172">
<front>
<title>The File Transfer Protocol</title>
<author fullname="Abhay Bhushan" initials="A." surname="Bhushan">
<organization>Massachusetts Institute of Technology (MIT)</organization>
</author>

<author fullname="Bob Braden" initials="B." surname="Braden">
<organization>University of California, Los Angeles (UCLA)</organization>
</author>

<author fullname="Will Crowther" initials="W." surname="Crowther">
<organization>Bolt Beranek and Newman (BBN)</organization>
</author>

<author fullname="Eric Harslem" initials="E." surname="Harslem">
<organization>The Rand Corporation</organization>
</author>

<author fullname="John Heafner" initials="J." surname="Heafner">
<organization>The Rand Corporation</organization>
</author>

<author fullname="Alex McKenzie" initials="A." surname="McKenzie">
<organization>Bolt Beranek and Newman (BBN)</organization>
</author>

<author fullname="John Melvin" initials="J." surname="Melvin">
<organization>Stanford Research Institute (SRI)</organization>
</author>

<author fullname="Bob Sundberg" initials="B." surname="Sundberg">
<organization>Harvard University</organization>
</author>

<author fullname="Dick Watson" initials="D." surname="Watson">
<organization>Stanford Research Institute (SRI)</organization>
</author>

<author fullname="Jim White" initials="J." surname="White">
<organization>University of California, Santa Barbara (UCSB)</organization>
</author>

<date year="1971" day="23" month="June" />
</front>

<seriesInfo value="172" name="RFC" />
</reference>


<reference target2="reference.RFC.0173.xml" anchor="RFC0173">
<front>
<title>Network Data Management Committee Meeting Announcement</title>
<author fullname="P. M. Karp" initials="P." surname="Karp">
<organization>MITRE Corporation</organization>
</author>

<author fullname="D. B. McKay" initials="D." surname="McKay">
<organization>International Business Machines (IBM)</organization>
</author>

<date year="1971" day="4" month="June" />

<abstract>
<t>The data management discussions at the recent NWG meeting resulted in the formation of a Network Data Management Committee to be chaired by Doug McKay, IBM.</t>
</abstract>
</front>

<seriesInfo value="173" name="RFC" />
</reference>


<reference target2="reference.RFC.0174.xml" anchor="RFC0174">
<front>
<title>UCLA - Computer Science Graphics Overview</title>
<author fullname="J. Postel" initials="J." surname="Postel">
<organization>University of California, Los Angeles (UCLA), Computer Science Department, Network Measurement Center (NMC)</organization>
</author>

<author fullname="V. Cerf" initials="V." surname="Cerf">
<organization>University of California, Los Angeles (UCLA), Computer Science Department, Network Measurement Center (NMC)</organization>
</author>

<date year="1971" day="8" month="June" />
</front>

<seriesInfo value="174" name="RFC" />
</reference>


<reference target2="reference.RFC.0175.xml" anchor="RFC0175">
<front>
<title>Comments on "Socket Conventions Reconsidered"</title>
<author fullname="E. Harslem" initials="E." surname="Harslem">
<organization>The Rand Corporation</organization>
</author>

<author fullname="J. Heafner" initials="J." surname="Heafner">
<organization>The Rand Corporation</organization>
</author>

<date year="1971" day="11" month="June" />

<abstract>
<t>We agree with the conclusions reached by Abhay, Bob, and Joel in RFC #167, "Socket Conventions Reconsidered," (see RFC #129, scheme #4) - especially the necessity for a major NCP overhaul.</t>

<t>Our main departure in thinking from RFC #167 concerns the socket length. (See RFC #164, page 21.)  Since there is an apparently serious TIP storage consideration, Rand- assigned sockets will have the high-order 16 bits zero.</t>

<t>For the particular programs (current and pending) that Rand must access, repeatability of socket name (RFC #167, page 3) is not necessary for the user process and also not necessary for the server process except for initial contact (ICP) sockets.</t>
</abstract>
</front>

<seriesInfo value="175" name="RFC" />
</reference>


<reference target2="reference.RFC.0176.xml" anchor="RFC0176">
<front>
<title>Comments on "Byte size for connections"</title>
<author fullname="A. Bhushan" initials="A." surname="Bhushan">
<organization>Massachusetts Institute of Technology (MIT)</organization>
</author>

<author fullname="R. Kanodia" initials="R." surname="Kanodia">
<organization>Massachusetts Institute of Technology (MIT)</organization>
</author>

<author fullname="R. Metcalfe" initials="R." surname="Metcalfe">
<organization>Massachusetts Institute of Technology (MIT)</organization>
</author>

<author fullname="J. Postel" initials="J." surname="Postel">
<organization>University of California, Los Angeles (UCLA)</organization>
</author>

<date year="1971" day="14" month="June" />

<abstract>
<t>There are at least the following three views on the use of byte size for network connections*:</t>

<t>1)   Byte size should not be used at all.</t>

<t>2)   Byte size is solely for the convenience of NCP's.</t>

<t>3)   Byte size choice is a user-level prerogative.</t>
</abstract>
</front>

<seriesInfo value="176" name="RFC" />
</reference>


<reference target2="reference.RFC.0177.xml" anchor="RFC0177">
<front>
<title>Device independent graphical display description</title>
<author fullname="J. McConnell" initials="J." surname="McConnell">
<organization>Ames Research Center</organization>

<address>
<postal>
<street />
<city>Moffett Field</city>
<region>CA</region>
<code>94035</code>
<country>US</country>
</postal>

</address>
</author>

<date year="1971" day="15" month="June" />

<abstract>
<t>As more nodes are connected to the ARPA network, the types of graphical display processors available to users is quite varied.  To attempt to facilitate the transmission of graphical information over the network, a device independent description of a display is described.  The using host may make any conversions necessary to realize the picture on a specific device.  It is also possible to interpose a form machine as proposed by Heafner and Harslem in RFC #94.  Some of the items and entities described herein were first discussed by Steve Crocker in RFC #86.  It is intended that this description is to be oriented to a refresh display with point, vector, and character drawing capability, these types of devices include the IBM 2250, IMLAC PDS-1, the DEC 338, and DEC 340, as well as the Evans and Sutherland LDS-1.  However, direct video storage tube devices represented by the ARDS, Tektronix and Computer devices can also serve as clumsy interactive devices.  Hard copy devices, such as microfilm or plotters, can also be used at the using host's
 discretion.</t>
</abstract>
</front>

<seriesInfo value="177" name="RFC" />
</reference>


<reference target2="reference.RFC.0178.xml" anchor="RFC0178">
<front>
<title>Network graphic attention handling</title>
<author fullname="Ira W. Cotton" initials="I." surname="Cotton">
<organization>The MITRE Corporation</organization>
</author>

<date year="1971" day="27" month="June" />
</front>

<seriesInfo value="178" name="RFC" />
</reference>


<reference target2="reference.RFC.0179.xml" anchor="RFC0179">
<front>
<title>Link Number Assignments</title>
<author fullname="Alex McKenzie" initials="A." surname="McKenzie">
<organization>Bolt Beranek and Newman (BBN)</organization>
</author>

<date year="1971" day="22" month="June" />

<abstract>
<t>Today Steve Crocker asked me to announce that from now on link numbers 2-71 (decimal), inclusive, are to be valid for use in connections.</t>
</abstract>
</front>

<seriesInfo value="179" name="RFC" />
</reference>


<reference target2="reference.RFC.0180.xml" anchor="RFC0180">
<front>
<title>File system questionnaire</title>
<author fullname="Alex McKenzie" initials="A." surname="McKenzie">
<organization>Bolt Baranek and Newman (BBN)</organization>

<address>
<postal>
<street>50 Moulton Street</street>
<city>Cambridge</city>
<region>MA</region>
<code>02138</code>
<country>US</country>
</postal>

<phone>+1 617 491 1850 x441</phone>
</address>
</author>

<date year="1971" day="25" month="June" />

<abstract>
<t>As noted in RFC #164(page 35), a subcommittee of the NWG, under the chairmanship of Abhay Bhushan, is currently generating proposals for a "data transfer protocol" and a "file transfer protocol".</t>

<t>The subcommittee has decided that the file transfer protocol should provide standard methods for requesting the transfer of a file but should not, at this time, attempt to standardize file naming conventions, access control conventions, and the like.  Thus a user who is, for example, trying to store a file on a remote Host will be required to use the file naming conventions appropriate to the remote Host.</t>

<t>Given the above point of view, it becomes imperative for users to have some source of information about Host file conventions.</t>
</abstract>
</front>

<seriesInfo value="180" name="RFC" />
</reference>


<reference target2="reference.RFC.0181.xml" anchor="RFC0181">
<front>
<title>Modifications to RFC 177</title>
<author fullname="John McConnell" initials="J." surname="McConnell">
<organization>AMES RESEARCH CENTER</organization>
</author>

<date year="1971" day="21" month="July" />

<abstract>
<t>This RFC is intended to modifiy the proposal for a device independent graphical display description discussed in RFC #177.  Thanks are due to Stan Mantiply of Ames for his ideas.  The main changes are in the definition of coordinate areas to avoid one problem encountered with the old definition and to provide more flexibility.  Terms used are those defined in RFC #177.</t>
</abstract>
</front>

<seriesInfo value="181" name="RFC" />
</reference>


<reference target2="reference.RFC.0182.xml" anchor="RFC0182">
<front>
<title>Compilation of list of relevant site reports</title>
<author fullname="Jeanne North" initials="J." surname="North">
<organization>Stanford Research Institute (SRI) International,  Augmentation Research Center (ARC), ARPA Network Information Center</organization>
</author>

<date year="1971" day="25" month="June" />

<abstract>
<t>The Network Information Center is working to compile a list of all Site-produced reports which are of interest to Network participants. Reports procuced under ARPA IPT contracts and any other relevant reports produced by the Sites on information processing, network planning, the hardware and sorfware for the projects, and some general reports on the subject concerns of individual Sites, are being identified, to be listed and acquired for the Network Information Center collection.</t>
</abstract>
</front>

<seriesInfo value="182" name="RFC" />
</reference>


<reference target2="reference.RFC.0183.xml" anchor="RFC0183">
<front>
<title>EBCDIC codes and their mapping to ASCII</title>
<author fullname="J.M. Winett" initials="J.M." surname="Winett">
<organization />
</author>

<date year="1971" day="21" month="July" />
</front>

<seriesInfo value="183" name="RFC" />
</reference>


<reference target2="reference.RFC.0184.xml" anchor="RFC0184">
<front>
<title>Proposed graphic display modes</title>
<author fullname="K.C. Kelley" initials="K.C." surname="Kelley">
<organization />
</author>

<date year="1971" day="6" month="July" />
</front>

<seriesInfo value="184" name="RFC" />
<format octets="18678" type="TXT" target="ftp://ftp.isi.edu/in-notes/rfc184.txt" />
</reference>


<reference target2="reference.RFC.0185.xml" anchor="RFC0185">
<front>
<title>NIC distribution of manuals and handbooks</title>
<author fullname="Jeanne North" initials="J." surname="North">
<organization>Stanford Research Institute (SRI) International,  Augmentation Research Center (ARC), ARPA Network Information Center</organization>
</author>

<date year="1971" day="7" month="July" />

<abstract>
<t>The Network Information Center asks that whenever basic manuals or handbooks are produced by Network participants, a sufficient quantity be made to supply NIC with copies for distribution.</t>
</abstract>
</front>

<seriesInfo value="185" name="RFC" />
</reference>


<reference target2="reference.RFC.0186.xml" anchor="RFC0186">
<front>
<title>Network graphics loader</title>
<author fullname="J.C. Michener" initials="J.C." surname="Michener">
<organization />
</author>

<date year="1971" day="12" month="July" />
</front>

<seriesInfo value="186" name="RFC" />
<format octets="30557" type="TXT" target="ftp://ftp.isi.edu/in-notes/rfc186.txt" />
</reference>


<reference target2="reference.RFC.0187.xml" anchor="RFC0187">
<front>
<title>Network/440 Protocol Concept</title>
<author fullname="Douglas B. McKay" initials="D." surname="McKay">
<organization>International Business Machines (IBM), Thomas J. Watson Research Center</organization>
</author>

<author fullname="Donald P. Karp" initials="D." surname="Karp">
<organization>International Business Machines (IBM), Thomas J. Watson Research Center</organization>
</author>

<date year="1971" day="1" month="July" />

<abstract>
<t>This RFC is being circulated as an	information RFC. Its intent is to convey some of the thinking and philosophy that went into IBM's network protocol and overall network design.</t>
</abstract>
</front>

<seriesInfo value="187" name="RFC" />
</reference>


<reference target2="reference.RFC.0188.xml" anchor="RFC0188">
<front>
<title>Data management meeting announcement</title>
<author fullname="P.M. Karp" initials="P.M." surname="Karp">
<organization />
</author>

<author fullname="D.B. McKay" initials="D.B." surname="McKay">
<organization />
</author>

<date year="1971" day="28" month="January" />
</front>

<seriesInfo value="188" name="RFC" />
<format octets="3383" type="TXT" target="ftp://ftp.isi.edu/in-notes/rfc188.txt" />
</reference>


<reference target2="reference.RFC.0189.xml" anchor="RFC0189">
<front>
<title>Interim NETRJS specifications</title>
<author fullname="R.T. Braden" initials="R.T." surname="Braden">
<organization />
</author>

<date year="1971" day="15" month="July" />
</front>

<seriesInfo value="189" name="RFC" />
<format octets="41383" type="TXT" target="ftp://ftp.isi.edu/in-notes/rfc189.txt" />
</reference>


<reference target2="reference.RFC.0190.xml" anchor="RFC0190">
<front>
<title>DEC PDP-10-IMLAC communications system</title>
<author fullname="L.P. Deutsch" initials="L.P." surname="Deutsch">
<organization />
</author>

<date year="1971" day="13" month="July" />
</front>

<seriesInfo value="190" name="RFC" />
<format octets="18752" type="TXT" target="ftp://ftp.isi.edu/in-notes/rfc190.txt" />
</reference>


<reference target2="reference.RFC.0191.xml" anchor="RFC0191">
<front>
<title>Graphics implementation and conceptualization at Augmentation Research Center</title>
<author fullname="Charles Irby" initials="C." surname="Irby">
<organization>Stanford Research Institute (SRI) International,  Augmentation Research Center (ARC)</organization>
</author>

<date year="1971" day="13" month="July" />
</front>

<seriesInfo value="191" name="RFC" />
</reference>


<reference target2="reference.RFC.0192.xml" anchor="RFC0192">
<front>
<title>Some factors which a Network Graphics Protocol must consider</title>
<author fullname="R.W. Watson" initials="R.W." surname="Watson">
<organization />
</author>

<date year="1971" day="12" month="July" />
</front>

<seriesInfo value="192" name="RFC" />
<format octets="48540" type="TXT" target="ftp://ftp.isi.edu/in-notes/rfc192.txt" />
</reference>


<reference target2="reference.RFC.0193.xml" anchor="RFC0193">
<front>
<title>NETWORK CHECKOUT</title>
<author fullname="E. Harslem" initials="E." surname="Harslem">
<organization>Rand Corporation</organization>
</author>

<author fullname="J. Heafner" initials="J." surname="Heafner">
<organization>Rand Corporation</organization>
</author>

<date year="1971" day="14" month="July" />

<abstract>
<t>As of 15 July we had contacted or been contacted by the sites listed below.  The matrix indicates the elements of Network software we have verified at each site.</t>
</abstract>
</front>

<seriesInfo value="193" name="RFC" />
</reference>


<reference target2="reference.RFC.0194.xml" anchor="RFC0194">
<front>
<title>The Data Reconfiguration Service -- Compiler/Interpreter Implementation Notes</title>
<author fullname="Vint Cerf" initials="V." surname="Cerf">
<organization>University California Los Angeles (UCLA)</organization>
</author>

<author fullname="Eric Harslem" initials="E." surname="Harslem">
<organization>Rand Corporation</organization>
</author>

<author fullname="John Heafner" initials="J." surname="Heafner">
<organization>Rand Corporation</organization>
</author>

<author fullname="Bob Metcalfe" initials="B." surname="Metcalfe">
<organization>Massachusetts Institute of Technology (MIT)</organization>
</author>

<author fullname="Jim White" initials="J." surname="White">
<organization>University California Santa Barbara (UCSB)</organization>
</author>

<date year="1971" day="14" month="July" />
</front>

<seriesInfo value="194" name="RFC" />
</reference>


<reference target2="reference.RFC.0195.xml" anchor="RFC0195">
<front>
<title>Data computers-data descriptions and access language</title>
<author fullname="G.H. Mealy" initials="G.H." surname="Mealy">
<organization />
</author>

<date year="1971" day="16" month="July" />
</front>

<seriesInfo value="195" name="RFC" />
<format octets="8704" type="TXT" target="ftp://ftp.isi.edu/in-notes/rfc195.txt" />
</reference>


<reference target2="reference.RFC.0196.xml" anchor="RFC0196">
<front>
<title>Mail Box Protocol</title>
<author fullname="Richard W. Watson" initials="R." surname="Watson">
<organization>Stanford Research Institute (SRI) International,  Augmentation Research Center (ARC)</organization>
</author>

<date year="1971" day="20" month="July" />

<abstract>
<t>The purpose of this protocol is to provide at each site a standard mechanism to receive sequential files for immediate or deferred printing or other uses.</t>
</abstract>
</front>

<seriesInfo value="196" name="RFC" />
</reference>


<reference target2="reference.RFC.0197.xml" anchor="RFC0197">
<front>
<title>Initial Connection Protocol - Reviewed</title>
<author fullname="A. Shoshani" initials="A." surname="Shoshani">
<organization>System Development Corporation ( SDC)</organization>
</author>

<author fullname="E. Harslem" initials="E." surname="Harslem">
<organization>Rand Corporation</organization>
</author>

<date year="1971" day="14" month="July" />
</front>

<seriesInfo value="197" name="RFC" />
</reference>


<reference target2="reference.RFC.0198.xml" anchor="RFC0198">
<front>
<title>Site Certification - Lincoln Labs 360/67</title>
<author fullname="J. Heafner" initials="J." surname="Heafner">
<organization>Rand Corporation</organization>
</author>

<date year="1971" day="20" month="July" />

<abstract>
<t>We have exercised Lincoln Labs Network software as follows: NCP, ICP, ASCII Telnet (user and server), login procedure, access to CMS, and operator and console communication.  All  behave  according  to  current specifications.</t>
</abstract>
</front>

<seriesInfo value="198" name="RFC" />
</reference>


<reference target2="reference.RFC.0199.xml" anchor="RFC0199">
<front>
<title>Suggestions for a network data-tablet graphics protocol</title>
<author fullname="T. Williams" initials="T." surname="Williams">
<organization />
</author>

<date year="1971" day="15" month="July" />
</front>

<seriesInfo value="199" name="RFC" />
</reference>


<reference target2="reference.RFC.0200.xml" anchor="RFC0200">
<front>
<title>RFC list by number</title>
<author fullname="J.B. White" initials="J.B." surname="North">
<organization />
</author>

<date year="1971" day="1" month="August" />
</front>

<seriesInfo value="200" name="RFC" />
</reference>


<reference target2="reference.RFC.0202.xml" anchor="RFC0202">
<front>
<title>Possible Deadlock in ICP</title>
<author fullname="Steve Wolfe" initials="S." surname="Wolfe">
<organization>University California Los Angeles (UCLA), CCN</organization>
</author>

<author fullname="Jon Postel" initials="J." surname="Postel">
<organization>University California Los Angeles (UCLA), NMC</organization>
</author>

<date year="1971" day="26" month="July" />

<abstract>
<t>We have noticed a possible deadlock situation which may arise using the Initial Connection Protocol (ICP) specified in Document #2 (NIC #7101 in the Current Network Protocols Notebook NIC #7104).</t>
</abstract>
</front>

<seriesInfo value="202" name="RFC" />
</reference>


<reference target2="reference.RFC.0203.xml" anchor="RFC0203">
<front>
<title>Achieving reliable communication</title>
<author fullname="R.B. Kalin" initials="R.B." surname="Kalin">
<organization />
</author>

<date year="1971" day="10" month="August" />
</front>

<seriesInfo value="203" name="RFC" />
<format octets="9253" type="TXT" target="ftp://ftp.isi.edu/in-notes/rfc203.txt" />
</reference>


<reference target2="reference.RFC.0204.xml" anchor="RFC0204">
<front>
<title>Sockets in use</title>
<author fullname="Jon Postel" initials="J." surname="Postel">
<organization>University California Los Angeles (UCLA), Computer Science Dept, NMC</organization>

<address>
<postal>
<street>3732 Boelter Hall</street>
<city>Los Angeles</city>
<region>CA</region>
<code>90024</code>
<country>US</country>
</postal>

<phone>+1 213 825 2368</phone>
</address>
</author>

<date year="1971" day="5" month="August" />

<abstract>
<t>I would like to collect information on the use of socket numbers for "standard" service programs. For example Loggers (telnet servers) Listen on socket 1. What sockets at your host are Listened to by what programs?</t>
</abstract>
</front>

<seriesInfo value="204" name="RFC" />
</reference>


<reference target2="reference.RFC.0205.xml" anchor="RFC0205">
<front>
<title>NETCRT - a character display protocol</title>
<author fullname="R.T. Braden" initials="R.T." surname="Braden">
<organization />
</author>

<date year="1971" day="6" month="August" />
</front>

<seriesInfo value="205" name="RFC" />
<format octets="28272" type="TXT" target="ftp://ftp.isi.edu/in-notes/rfc205.txt" />
</reference>


<reference target2="reference.RFC.0206.xml" anchor="RFC0206">
<front>
<title>User Telnet - description of an initial implementation</title>
<author fullname="J.E. White" initials="J.E." surname="White">
<organization />
</author>

<date year="1971" day="9" month="August" />
</front>

<seriesInfo value="206" name="RFC" />
</reference>


<reference target2="reference.RFC.0207.xml" anchor="RFC0207">
<front>
<title>September Network Working Group meeting</title>
<author fullname="A. Vezza" initials="A." surname="Vezza">
<organization>Massachusetts Institute of Technology (MIT), Project MAC</organization>
</author>

<date year="1971" day="9" month="August" />

<abstract>
<t>The next meeting of the Network Working Group will be hosted by M.I.T.'s Project MAC in Cambridge, Massachusetts.</t>
</abstract>
</front>

<seriesInfo value="207" name="RFC" />
</reference>


<reference target2="reference.RFC.0208.xml" anchor="RFC0208">
<front>
<title>Address tables</title>
<author fullname="A.M. McKenzie" initials="A.M." surname="McKenzie">
<organization />
</author>

<date year="1971" day="9" month="August" />
</front>

<seriesInfo value="208" name="RFC" />
<format octets="5858" type="TXT" target="ftp://ftp.isi.edu/in-notes/rfc208.txt" />
</reference>


<reference target2="reference.RFC.0209.xml" anchor="RFC0209">
<front>
<title>Host/IMP interface documentation</title>
<author fullname="B. Cosell" initials="B." surname="Cosell">
<organization />
</author>

<date year="1971" day="13" month="August" />
</front>

<seriesInfo value="209" name="RFC" />
<format octets="2566" type="TXT" target="ftp://ftp.isi.edu/in-notes/rfc209.txt" />
</reference>


<reference target2="reference.RFC.0210.xml" anchor="RFC0210">
<front>
<title>Improvement of Flow Control</title>
<author fullname="W. Conrad" initials="W." surname="Conrad">
<organization>Harvard University</organization>
</author>

<date year="1971" day="16" month="August" />

<abstract>
<t>The current "give back" - "return" scheme seems to put the cart before the horse in that the "return" command indicates the amount of space the sending host is returning rather than the amount of space it has left after decrementing by the amount specified in the "give back" command.  Considering the fact that allocation counters at sending and receiving hosts may get out of synchronization and the fact that the receiving host has a preemptive priority in the allocation of its resources, it is only logical that the receiving host be able to find out exactly how much of its buffer space a sending host thinks it can claim.</t>
</abstract>
</front>

<seriesInfo value="210" name="RFC" />
</reference>


<reference target2="reference.RFC.0211.xml" anchor="RFC0211">
<front>
<title>ARPA Network mailing lists</title>
<author fullname="J.B. North" initials="J.B." surname="North">
<organization />
</author>

<date year="1971" day="18" month="August" />
</front>

<seriesInfo value="211" name="RFC" />
</reference>


<reference target2="reference.RFC.0212.xml" anchor="RFC0212">
<front>
<title>NWG meeting on network usage</title>
<author>
<organization>NWG Steering Committee</organization>
</author>

<date year="1971" day="23" month="August" />

<abstract>
<t>M.I.T.'s Project MAC has agreed to host the next Network Working Group Meeting in Cambridge, Massachusetts.</t>
</abstract>
</front>

<seriesInfo value="212" name="RFC" />
</reference>


<reference target2="reference.RFC.0213.xml" anchor="RFC0213">
<front>
<title>IMP System change notification</title>
<author fullname="B. Cosell" initials="B." surname="Cosell">
<organization>Bolt Beranek and Newman (BBN)</organization>
</author>

<date year="1971" day="20" month="August" />

<abstract>
<t>During the week of 16 August, we installed a new version of the IMP system, version 2505.</t>
</abstract>
</front>

<seriesInfo value="213" name="RFC" />
</reference>


<reference target2="reference.RFC.0214.xml" anchor="RFC0214">
<front>
<title>Network checkpoint</title>
<author fullname="E. Harslem" initials="E." surname="Harslem">
<organization>Rand Corporation</organization>
</author>

<date year="1971" day="21" month="August" />

<abstract>
<t>As of August 21 we had performed the following verifications with the sites listed below.  These verifications were done on an arranged basis and do not indicate any degree of continuous availability.</t>
</abstract>
</front>

<seriesInfo value="214" name="RFC" />
</reference>


<reference target2="reference.RFC.0215.xml" anchor="RFC0215">
<front>
<title>NCP, ICP, and Telnet: The Terminal IMP implementation</title>
<author fullname="A. McKenzie" initials="A." surname="McKenzie">
<organization>Bolt Baranek and Newman (BBN)</organization>
</author>

<date year="1971" day="30" month="August" />

<abstract>
<t>By early December there will be six Terminal IMPs incorporated into the network, with additional Terminal IMPs scheduled for delivery at a rate of about one per month thereafter.  For this reason the implementation of network protocols (and deviations from them) may be of interest to the network community.  This note describes the choices made by the Terminal IMP system programmers where choices are permitted by the protocols, and documents some instances of non-compliance with protocols.</t>
</abstract>
</front>

<seriesInfo value="215" name="RFC" />
</reference>


<reference target2="reference.RFC.0216.xml" anchor="RFC0216">
<front>
<title>Telnet access to UCSB's On-Line System</title>
<author fullname="J.E. White" initials="J.E." surname="White">
<organization />
</author>

<date year="1971" day="8" month="September" />
</front>

<seriesInfo value="216" name="RFC" />
</reference>


<reference target2="reference.RFC.0217.xml" anchor="RFC0217">
<front>
<title>Specifications changes for OLS, RJE/RJOR, and SMFS</title>
<author fullname="James E. White" initials="J." surname="White">
<organization>University of California, Santa Barbara (UCSB), Computer Research Lab</organization>
</author>

<date year="1971" day="8" month="September" />

<abstract>
<t>The following documents are hereby revised:</t>

<t>1)  'Specifications for Network Use of the UCSB On-Line System [16 October 70, RFC 74, NIC 5417],</t>

<t>(2)  'Network Specifications for Remote Job Entry and Remote Job Output Retrieval at UCSB' [22 March 71, RFC 105, NIC 5775], and</t>

<t>(3)  'Network Specifications for UCSB's Simple-Minded File System' [26 April 71, RFC 122, NIC 5834].</t>
</abstract>
</front>

<seriesInfo value="217" name="RFC" />
</reference>


<reference target2="reference.RFC.0218.xml" anchor="RFC0218">
<front>
<title>Changing the IMP status reporting facility</title>
<author fullname="B. Cosell" initials="B." surname="Cosell">
<organization>Bolt Baranek and Newman (BBN)</organization>
</author>

<date year="1971" day="8" month="September" />

<abstract>
<t>To help us expand our role as NCC, we will be changing the status reporting facility of the IMP.  The change will take place within the next month and should be transparent to the hosts.</t>
</abstract>
</front>

<seriesInfo value="218" name="RFC" />
</reference>


<reference target2="reference.RFC.0219.xml" anchor="RFC0219">
<front>
<title>User's view of the datacomputer</title>
<author fullname="R. Winter" initials="R." surname="Winter">
<organization />
</author>

<date year="1971" day="3" month="September" />
</front>

<seriesInfo value="219" name="RFC" />
</reference>


<reference target2="reference.RFC.0221.xml" anchor="RFC0221">
<front>
<title>Mail Box Protocol: Version 2</title>
<author fullname="R.W. Watson" initials="R.W." surname="Watson">
<organization />
</author>

<date year="1971" day="27" month="August" />
</front>

<seriesInfo value="221" name="RFC" />
<format octets="9805" type="TXT" target="ftp://ftp.isi.edu/in-notes/rfc221.txt" />
</reference>


<reference target2="reference.RFC.0222.xml" anchor="RFC0222">
<front>
<title>Subject: System programmer's workshop</title>
<author fullname="R.M. Metcalfe" initials="R.M." surname="Metcalfe">
<organization />
</author>

<date year="1971" day="13" month="September" />
</front>

<seriesInfo value="222" name="RFC" />
<format octets="4023" type="TXT" target="ftp://ftp.isi.edu/in-notes/rfc222.txt" />
</reference>


<reference target2="reference.RFC.0223.xml" anchor="RFC0223">
<front>
<title>Network Information Center schedule for network users</title>
<author fullname="John Melvin" initials="J." surname="Melvin">
<organization>Stanford Research Institute (SRI) International,  Augmentation Research Center (ARC)</organization>
</author>

<author fullname="Dick Watson" initials="D." surname="Watson">
<organization>Stanford Research Institute (SRI) International,  Augmentation Research Center (ARC)</organization>
</author>

<date year="1971" day="14" month="September" />

<abstract>
<t>The Network Information Center has planned to provide service for network users on a regular basis Monday through Friday.</t>
</abstract>
</front>

<seriesInfo value="223" name="RFC" />
</reference>


<reference target2="reference.RFC.0224.xml" anchor="RFC0224">
<front>
<title>Comments on Mailbox Protocol</title>
<author fullname="Alex McKenzie" initials="A." surname="McKenzie">
<organization>Bolt Baranek and Newman (BBN)</organization>
</author>

<date year="1971" day="14" month="September" />

<abstract>
<t>It should be noted that the Terminal IMP will be unable to directly implement the currently-proposed mailbox protocol for the following reasons:</t>
</abstract>
</front>

<seriesInfo value="224" name="RFC" />
</reference>


<reference target2="reference.RFC.0225.xml" anchor="RFC0225">
<front>
<title>Rand/UCSB network graphics experiment</title>
<author fullname="E. Harslem" initials="E." surname="Harslem">
<organization />
</author>

<author fullname="R. Stoughton" initials="R." surname="Stoughton">
<organization />
</author>

<date year="1971" day="13" month="September" />
</front>

<seriesInfo value="225" name="RFC" />
<format octets="13573" type="TXT" target="ftp://ftp.isi.edu/in-notes/rfc225.txt" />
</reference>


<reference target2="reference.RFC.0226.xml" anchor="RFC0226">
<front>
<title>Standardization of host mnemonics</title>
<author fullname="Peggy Karp" initials="P." surname="Karp">
<organization>The Mitre Corporation (MITRE)</organization>
</author>

<date year="1971" day="20" month="September" />

<abstract>
<t>IN EACH TELNET IMPLEMENTATION, A LIST OF HOST NMEUMONICS IS PROVIDED FOR THE USER TO INDICATE THE SERVING HOST DESIRED.  CURRENTLY, EACH SITE EMPLOYS THEIR OWN SPECIAL LIST.  RATHER THAN REQUIRE THE USER TO BE COGNIZANT OF THE IDIOSYNCRASIES OF EACH LIST, ESPECIALLY WHEN CHAINED THROUGH SEVERAL HOSTS VIA TELNET, IT HAS BEEN RECOMMENDED THAT STANDARD HOST DESIGNATORS BE ADOPTED.</t>

<t>THE FOLLOWING LIST OF SIX CHARACTER DESIGNATORS IS PROPOSED AS THE STANDARD LIST.  REGISTER ANY OBJECTIONS BY 3 OCTOBER TO P. KARP (703) 893-3500 X2391, X2318. AN OFFICIAL POLICY AND IMPLEMENTATION DATE WILL BE SET ON 8 OCTOBER.</t>
</abstract>
</front>

<seriesInfo value="226" name="RFC" />
</reference>


<reference target2="reference.RFC.0227.xml" anchor="RFC0227">
<front>
<title>Data transfer rates (Rand/UCLA)</title>
<author fullname="J. Heafner" initials="J." surname="Heafner">
<organization>Rand Corporation</organization>
</author>

<author fullname="E. Harslem" initials="E." surname="Harslem">
<organization>Rand Corporation</organization>
</author>

<date year="1971" day="17" month="September" />

<abstract>
<t>The attached memo indicates data rates typical of our use of RJS at UCLA CCN.</t>
</abstract>
</front>

<seriesInfo value="227" name="RFC" />
</reference>


<reference target2="reference.RFC.0228.xml" anchor="RFC0228">
<front>
<title>Clarification</title>
<author fullname="Dave Walden" initials="D." surname="Walden">
<organization>Bolt Baranek and Newman (BBN)</organization>
</author>

<date year="1971" day="22" month="September" />

<abstract>
<t>The second statement before statement 20 in the FORTRAN program on page 7 of RFC #70should read N=1</t>
</abstract>
</front>

<seriesInfo value="228" name="RFC" />
</reference>


<reference target2="reference.RFC.0229.xml" anchor="RFC0229">
<front>
<title>Standard host names</title>
<author fullname="Jon Postel" initials="J." surname="Postel">
<organization>University California Los Angeles (UCLA), Computer Science Department, Network Measurement Center (NMC)</organization>
</author>

<date year="1971" day="22" month="September" />

<abstract>
<t>I suggest 8 character names and the following list:</t>
</abstract>
</front>

<seriesInfo value="229" name="RFC" />
</reference>


<reference target2="reference.RFC.0230.xml" anchor="RFC0230">
<front>
<title>Toward reliable operation of minicomputer-based terminals on a TIP</title>
<author fullname="T. N. Pyke Jr." initials="T." surname="Pyke">
<organization>National Bureau of Standards (NBS)</organization>
</author>

<date year="1971" day="24" month="September" />

<abstract>
<t>The present protocol for communication between a TIP and attached terminals requires character-oriented transmission and provides for no error control. In the design of this protocol, it was apparently assumed that the majority of terminals attached to a TIP would be interactive, be normally used in a character-by-character mode both for transmission to and from the terminal, and normally support a human user who would in effect be in the communication loop. The human user would thus be in a position to detect any significant telecommunication-induced errors both by direct observation of the character stream and, more importantly, by examining the computer output in the context of his ongoing interaction.</t>

<t>The effectiveness of this means for error detection and initiation of corrective measures when necessary is not adequate in the following cases:</t>
</abstract>
</front>

<seriesInfo value="230" name="RFC" />
</reference>


<reference target2="reference.RFC.0231.xml" anchor="RFC0231">
<front>
<title>Service center standards for remote usage: A user's view</title>
<author fullname="J. Heafner" initials="J." surname="Heafner">
<organization>The Rand Corporation</organization>
</author>

<author fullname="E. Harslem" initials="E." surname="Harslem">
<organization>The Rand Corporation</organization>
</author>

<date year="1971" day="21" month="September" />
</front>

<seriesInfo value="231" name="RFC" />
</reference>


<reference target2="reference.RFC.0232.xml" anchor="RFC0232">
<front>
<title>Postponement of network graphics meeting</title>
<author fullname="A. Vezza" initials="A." surname="Vezza">
<organization>Massachusetts Institute of Technology (MIT), Project MAC</organization>
</author>

<date year="1971" day="23" month="September" />

<abstract>
<t>At the last Network Graphics meeting held in July at M.I.T., we tentatively scheduled the next Network Graphics meeting which is being hosted by Stanford AI, for October 17, 18, and 19.</t>
</abstract>
</front>

<seriesInfo value="232" name="RFC" />
</reference>


<reference target2="reference.RFC.0233.xml" anchor="RFC0233">
<front>
<title>Standardization of host call letters</title>
<author fullname="Abhay Bhushan" initials="A." surname="Bhushan">
<organization>Massachusetts Institute of Technology (MIT)</organization>
</author>

<author fullname="Bob Metcalfe" initials="B." surname="Metcalfe">
<organization>Massachusetts Institute of Technology (MIT)</organization>
</author>

<date year="1971" day="28" month="September" />

<abstract>
<t>We agree with Peggy Karp (See RFC #226) that there would be some benefit in standardizing the symbolic host names used in TELNET programs.</t>
</abstract>
</front>

<seriesInfo value="233" name="RFC" />
</reference>


<reference target2="reference.RFC.0234.xml" anchor="RFC0234">
<front>
<title>Network Working Group meeting schedule</title>
<author fullname="A. Vezza" initials="A." surname="Vezza">
<organization />
</author>

<date year="1971" day="5" month="October" />
</front>

<seriesInfo value="234" name="RFC" />
</reference>


<reference target2="reference.RFC.0235.xml" anchor="RFC0235">
<front>
<title>Site status</title>
<author fullname="E. Westheimer" initials="E." surname="Westheimer">
<organization>Bolt Baranek and Newman (BBN)</organization>
</author>

<date year="1971" month="September" day="27" />

<abstract>
<t>Beginning with this RFC, BBN will report on the status of most Network Hosts approximately once every two weeks.  The information for these reports will be gained from talking to people at each site, and from experimental "data".  These data will be the results of daily attempts to log into each of the Hosts which might be accessible to a Network user; the attempts will have been made from the BBN prototype Terminal IMP at a random time each weekday.</t>
</abstract>
</front>

<seriesInfo value="235" name="RFC" />
</reference>


<reference target2="reference.RFC.0236.xml" anchor="RFC0236">
<front>
<title>Standard host names</title>
<author fullname="Jon Postel" initials="J." surname="Postel">
<organization>University of California, Los Angeles (UCLA), Computer Science Department, NMC</organization>
</author>

<date year="1971" day="27" month="September" />

<abstract>
<t>In RFC #226, Peggy Karp suggested that there be a set of standard host names, that the names be 6 characters in length, and gave a partial list.  In RFC #229, I suggested 8 character names and gave a longer list.  Here I present my list again with some modifications.</t>

<t>I also suggest that as far as possible the Standard host names be consistent with the site names used by the Network Information Center.  It also seems to me to be a good idea to consult with each host's technical liaison officer before assigning that host's name.</t>
</abstract>
</front>

<seriesInfo value="236" name="RFC" />
</reference>


<reference target2="reference.RFC.0237.xml" anchor="RFC0237">
<front>
<title>NIC view of standard host names</title>
<author fullname="Richard W. Watson" initials="R." surname="Watson">
<organization>Stanford Research Institute (SRI) International,  Augmentation Research Center (ARC)</organization>
</author>

<date year="1971" day="5" month="October" />

<abstract>
<t>The NIC strongly favors standardization of host names.</t>
</abstract>
</front>

<seriesInfo value="237" name="RFC" />
</reference>


<reference target2="reference.RFC.0238.xml" anchor="RFC0238">
<front>
<title>Comments on DTP and FTP proposals</title>
<author fullname="R. T. Braden" initials="R." surname="Braden">
<organization>University of California, Los Angeles (UCLA), Campus Computing Network (CCN)</organization>
</author>

<date year="1971" day="29" month="September" />
</front>

<seriesInfo value="238" name="RFC" />
</reference>


<reference target2="reference.RFC.0239.xml" anchor="RFC0239">
<front>
<title>Host mnemonics proposed in RFC 226 (NIC 7625)</title>
<author fullname="R. Braden" initials="R." surname="Braden">
<organization>University of California, Los Angeles (UCLA), Campus Computing Network (CCN)</organization>
</author>

<date year="1971" day="23" month="September" />

<abstract>
<t>CCN is in full agreement that a standard set of host mnemonics should be selected. However, your proposed set is not fully satisfactory.</t>
</abstract>
</front>

<seriesInfo value="239" name="RFC" />
</reference>


<reference target2="reference.RFC.0240.xml" anchor="RFC0240">
<front>
<title>Site Status</title>
<author fullname="A. McKenzie" initials="A." surname="McKenzie">
<organization>Bolt Baranek and Newman (BBN)</organization>
</author>

<date year="1971" day="30" month="September" />

<abstract>
<t>Due to extensive typographic errors in RFC #235, I have decided to reissue the first of our experimental site status reports.</t>

<t>In compiling RFC #235, I followed the principle that timeliness was somewhat more important than extremely careful editing; this seemed to me to be in keeping with the original RFC philosophy.  I am sorry for any embarrassment this may have caused to anyone associated with the Network, and accept full responsibility for the content of RFC #235.  I will try to do a better job in the future.</t>
</abstract>
</front>

<seriesInfo value="240" name="RFC" />
</reference>


<reference target2="reference.RFC.0241.xml" anchor="RFC0241">
<front>
<title>Connecting computers to MLC ports</title>
<author fullname="A. McKenzie" initials="A." surname="McKenzie">
<organization>Bolt Baranek and Newman (BBN)</organization>
</author>

<date year="1971" day="29" month="September" />

<abstract>
<t>Several times we have been asked if computers can be connected through serial communication lines to ports on the Terminal IMP's Multi-Line Controller (MLC) [related questions about the level of software support provided by the Terminal IMP to such a connection, have also been raised].  In the past we have said, "Please don't!" We now say, "Sure, but will that really help you the way you think it will?"</t>
</abstract>
</front>

<seriesInfo value="241" name="RFC" />
</reference>


<reference target2="reference.RFC.0242.xml" anchor="RFC0242">
<front>
<title>Data Descriptive Language for Shared Data</title>
<author fullname="L. Haibt" initials="L." surname="Haibt">
<organization>International Business Machines (IBM), Thomas J. Watson Research Center</organization>
</author>

<author fullname="A. Mullery" initials="A." surname="Mullery">
<organization>International Business Machines (IBM), Thomas J. Watson Research Center</organization>
</author>

<date year="1971" day="19" month="July" />
</front>

<seriesInfo value="242" name="RFC" />
</reference>


<reference target2="reference.RFC.0243.xml" anchor="RFC0243">
<front>
<title>Network and data sharing bibliography</title>
<author fullname="Alvin P. Mullery" initials="A." surname="Mullery">
<organization>International Business Machines (IBM), Thomas J. Watson Research Center</organization>
</author>

<date year="1971" day="5" month="October" />
</front>

<seriesInfo value="243" name="RFC" />
</reference>


<reference target2="reference.RFC.0245.xml" anchor="RFC0245">
<front>
<title>Reservations for Network Group meeting</title>
<author fullname="Carol Falls" initials="C." surname="Falls">
<organization>Massachusetts Institute of Technology (MIT), Project MAC</organization>

<address>
<phone>+1 617 864 6900 x1450</phone>
</address>
</author>

<date year="1971" day="5" month="October" />

<abstract>
<t>Guaranteed arrival reservations for rooms at the Hotel Sonesta in Cambridge, Massachusetts have been made for NWGM attendees who have made reservations through Project MAC.</t>
</abstract>
</front>

<seriesInfo value="245" name="RFC" />
</reference>


<reference target2="reference.RFC.0246.xml" anchor="RFC0246">
<front>
<title>Network Graphics meeting</title>
<author fullname="A. Vezza" initials="A." surname="Vezza">
<organization>Massachusetts Institute of Technology (MIT), Project MAC</organization>
</author>

<date year="1971" day="5" month="October" />

<abstract>
<t>The next Networks Graphics Meeting has been scheduled to commence the evening of Sunday, November 21st and adjourn Tuesday, November 23rd.  The Stanford Artifical Intellegence Project will host the meeting.</t>
</abstract>
</front>

<seriesInfo value="246" name="RFC" />
</reference>


<reference target2="reference.RFC.0247.xml" anchor="RFC0247">
<front>
<title>Proffered set of standard host names</title>
<author fullname="Peggy Karp" initials="P." surname="Karp">
<organization>The MITRE Corporation (MITRE)</organization>
</author>

<date year="1971" day="12" month="October" />

<abstract>
<t>In RFC #226, BBN's TENEX list of Host names was set up as a strawman set of standard Host names.  Comments received since then (an RFC actually generated comments!!!) have influenced me to propose the following general rules for forming Host names.</t>
</abstract>
</front>

<seriesInfo value="247" name="RFC" />
</reference>


<reference target2="reference.RFC.0249.xml" anchor="RFC0249">
<front>
<title>Coordination of equipment and supplies purchase</title>
<author fullname="R. F. Borelli" initials="R." surname="Borelli">
<organization>University of Illinois, Center for Advanced Computation</organization>

<address>
<postal>
<street />
<city>Urbana</city>
<region>IL</region>
<code>61801</code>
<country>US</country>
</postal>

<phone>+1 217 333 6375</phone>
</address>
</author>

<date year="1971" day="8" month="October" />

<abstract>
<t>The purpose of this message is to pass on to all members of the Network an agreement reached between Messrs. Steve Crocker of ARPA and R. F. Borelli of the University of Illinois.  The Center for Advanced Computation has agreed to study the feasibility of a coordinating point for purchases of equipment and supplies to be used on the network.</t>
</abstract>
</front>

<seriesInfo value="249" name="RFC" />
</reference>


<reference target2="reference.RFC.0250.xml" anchor="RFC0250">
<front>
<title>Some thoughts on file transfer</title>
<author fullname="H. Brodie" initials="H." surname="Brodie">
<organization>University California Los Angeles (UCLA), Computer Science, NMC</organization>
</author>

<date year="1971" day="7" month="October" />

<abstract>
<t>There are several aspects of the proposed Data Transfer Protocol (RFC #171) and File Transfer Protocol (RFC #172) which we believe could use further clarification and perhaps revision.  Interest in transferring larger amounts of data than is typically sent via the usual TELNET connection is increasing, and at least at UCLA-NMC implementation attempts have pointed out several difficulties with the proposed protocols.</t>
</abstract>
</front>

<seriesInfo value="250" name="RFC" />
</reference>


<reference target2="reference.RFC.0251.xml" anchor="RFC0251">
<front>
<title>Weather data</title>
<author fullname="Dale H. Stern" initials="D." surname="Stern">
<organization>Computer Corporation of America (CCA)</organization>

<address>
<postal>
<street>575 Technology Square</street>
<city>Cambridge</city>
<region>MA</region>
<code>02139</code>
<country>US</country>
</postal>

<phone>+1 617 491 3670</phone>
</address>
</author>

<date year="1971" day="13" month="October" />

<abstract>
<t>The USAF Environmental Technical Applications Center (ETAC) is providing weather data for the ARPA Network.  Ultimately there will be ten years of high quality surface and upper air weather observations, as well as hemispheric grid point analyses.  The observations are generated by approximately 5000 surface and 1200 upper air stations, distributed all over the world.</t>
</abstract>
</front>

<seriesInfo value="251" name="RFC" />
</reference>


<reference target2="reference.RFC.0252.xml" anchor="RFC0252">
<front>
<title>Network host status</title>
<author fullname="E. Westheimer" initials="E." surname="Westheimer">
<organization>Bolt Baranek and Newman (BBN)</organization>
</author>

<date year="1971" day="8" month="October" />

<abstract>
<t>The purpose of this RFC is to report on the recent status of most Network Hosts.</t>
</abstract>
</front>

<seriesInfo value="252" name="RFC" />
</reference>


<reference target2="reference.RFC.0253.xml" anchor="RFC0253">
<front>
<title>Second Network Graphics meeting details</title>
<author fullname="James A. Moorer" initials="J." surname="Moorer">
<organization>Stanford University (SU), Artificial Intelligence (AI) Laboratory</organization>
</author>

<date year="1971" day="19" month="October" />

<abstract>
<t>Stanford will be the site of the second network graphics meeting.</t>
</abstract>
</front>

<seriesInfo value="253" name="RFC" />
</reference>


<reference target2="reference.RFC.0254.xml" anchor="RFC0254">
<front>
<title>Scenarios for using ARPANET computers</title>
<author fullname="A. Bhushan" initials="A." surname="Bhushan">
<organization />
</author>

<date year="1971" day="29" month="October" />
</front>

<seriesInfo value="254" name="RFC" />
</reference>


<reference target2="reference.RFC.0255.xml" anchor="RFC0255">
<front>
<title>Status of network hosts</title>
<author fullname="E. Westheimer" initials="E." surname="Westheimer">
<organization />
</author>

<date year="1971" day="26" month="October" />
</front>

<seriesInfo value="255" name="RFC" />
<format octets="4002" type="TXT" target="ftp://ftp.isi.edu/in-notes/rfc255.txt" />
</reference>


<reference target2="reference.RFC.0256.xml" anchor="RFC0256">
<front>
<title>IMPSYS change notification</title>
<author fullname="B. Cosell" initials="B." surname="Cosell">
<organization>Bolt Baranek and Newman (BBN)</organization>
</author>

<date year="1971" day="3" month="November" />

<abstract>
<t>We will shortly install (or perhaps will have already installed) a new version of the IMP system, Version 2513.  The new version incorporates two principal changes:</t>
</abstract>
</front>

<seriesInfo value="256" name="RFC" />
</reference>


<reference target2="reference.RFC.0263.xml" anchor="RFC0263">
<front>
<title>"Very Distant" Host interface</title>
<author fullname="Alex McKenzie" initials="A." surname="McKenzie">
<organization>Bolt Baranek and Newman (BBN)</organization>
</author>

<date year="1971" day="17" month="December" />

<abstract>
<t>The normal method of connecting a Host computer to the ARPA Network is, and will continue to be, placing an IMP at the Host site and making a short-distance hard-wire connection.  However, during the past several months we have become increasingly aware of the occasional desire to interface a Host to some IMP via a long-distance connection (where long-distance, in this context, is any cable run longer than 2000 feet but may typically be tens of miles) via either a hard-wire or telephone circuit.  We believe that any good solution to the general problem of interfacing Hosts to IMPs must satisfy at least the following criteria:</t>

<t>1)  The characteristics of the connection should be such that the undetected error rate can be expected to be extremely low.</t>

<t>2)  The bandwidth of the connection should not be intrinsically limited to a low value.</t>

<t>3)  The nature of the connection should be such that the Host may establish multiple network "conversations", i.e., it should have all the power of a normal Host connection.</t>
</abstract>
</front>

<seriesInfo value="263" name="RFC" />
</reference>


<reference target2="reference.RFC.0264.xml" anchor="RFC0264">
<front>
<title>The Data Transfer Protocol</title>
<author fullname="A. Bhushan" initials="A." surname="Bhushan">
<organization />
</author>

<author fullname="B. Braden" initials="B." surname="Braden">
<organization />
</author>

<author fullname="W. Crowther" initials="W." surname="Crowther">
<organization />
</author>

<author fullname="E. Harslem" initials="E." surname="Harslem">
<organization />
</author>

<author fullname="J. Heafner" initials="J." surname="Heafner">
<organization />
</author>

<author fullname="A. McKenize" initials="A." surname="McKenize">
<organization />
</author>

<author fullname="B. Sundberg" initials="B." surname="Sundberg">
<organization />
</author>

<author fullname="D. Watson" initials="D." surname="Watson">
<organization />
</author>

<author fullname="J. White" initials="J." surname="White">
<organization />
</author>

<date year="1972" day="4" month="January" />
</front>

<seriesInfo value="264" name="RFC" />
<format octets="20907" type="TXT" target="ftp://ftp.isi.edu/in-notes/rfc264.txt" />
</reference>


<reference target2="reference.RFC.0265.xml" anchor="RFC0265">
<front>
<title abbrev="File Transfer Protocol">The File Transfer Protocol</title>
<author fullname="Abbay Bhushan" initials="A." surname="Bhushan">
<organization>Massachusetts Institute of Technology (MIT)</organization>
</author>

<author fullname="Bob Braden" initials="B." surname="Braden">
<organization>University of California, Los Angeles (UCLA)</organization>
</author>

<author fullname="Will Crowther" initials="W." surname="Crowther">
<organization>Bolt Beranek and Newman (BBN)</organization>
</author>

<author fullname="Eric Narslem" initials="E." surname="Narslem">
<organization>Rand Corporation</organization>
</author>

<author fullname="John Heafner" initials="J." surname="Heafner">
<organization>Rand Corporation</organization>
</author>

<author fullname="Alex McKenzie" initials="A." surname="McKenzie">
<organization>Bolt Beranek and Newman (BBN)</organization>
</author>

<author fullname="John Melvin" initials="J." surname="Melvin">
<organization>Stanford Research Institute (SRI)</organization>
</author>

<author fullname="Bob Sundberg" initials="B." surname="Sundberg">
<organization>Harvard University</organization>
</author>

<author fullname="Dick Watson" initials="D." surname="Watson">
<organization>Stanford Research Institute (SRI)</organization>
</author>

<author fullname="Jim White" initials="J." surname="White">
<organization>University California Santa Barbara (UCSB)</organization>
</author>

<date year="1971" day="17" month="November" />

<abstract>
<t>This Paper is a revision of RF 172, Mic 6794. The changes to RFC 172are given below. The protocol is then restated for your ocnvenience.</t>
</abstract>
</front>

<seriesInfo value="265" name="RFC" />
</reference>


<reference target2="reference.RFC.0266.xml" anchor="RFC0266">
<front>
<title>Network host status</title>
<author fullname="Ellen Westheimer" initials="E." surname="Westheimer">
<organization>Bolt Beranek and Newman Inc. (BBN)</organization>
</author>

<date year="1971" day="8" month="November" />

<abstract>
<t>This RFC reports on the status of most.Network Hosts from October 26 to November 5</t>
</abstract>
</front>

<seriesInfo value="266" name="RFC" />
</reference>


<reference target2="reference.RFC.0267.xml" anchor="RFC0267">
<front>
<title>Network Host Status</title>
<author fullname="Ellen Westheimer" initials="E." surname="Westheimer">
<organization>Bolt Baranek and Newman (BBN)</organization>
</author>

<date year="1971" day="22" month="November" />

<abstract>
<t>This RFC reports on the status of most Network Hosts from November 8  to November 19.</t>
</abstract>
</front>

<seriesInfo value="267" name="RFC" />
</reference>


<reference target2="reference.RFC.0268.xml" anchor="RFC0268">
<front>
<title>Graphics facilities information</title>
<author fullname="J. Postel" initials="J." surname="Postel">
<organization>University California Los Angeles (UCLA), Computer Science Department, Network Measurement Center (NMC)</organization>
</author>

<date year="1971" day="24" month="November" />

<abstract>
<t>It was suggested at the recent network graphics meeting (@ SAIL 21-23 November) that it would be a good idea to include in the Resources Notebook information about the graphics facilities at each site.</t>
</abstract>
</front>

<seriesInfo value="268" name="RFC" />
</reference>


<reference target2="reference.RFC.0269.xml" anchor="RFC0269">
<front>
<title>Some Experience with File Transfer</title>
<author fullname="H. Brodie" initials="H." surname="Brodie">
<organization>University California Los Angeles (UCLA), Network Measurement Center (NMC)</organization>
</author>

<date year="1971" day="6" month="December" />

<abstract>
<t>At UCLA-NMC we have recently completed implementation of a program which utilizes UCSB's storage capability via their Simple Minded File System (See RFC #122by Jim White for a description of SMFS).  The use of the program is detailed in Appendix A.</t>

<t>We learned a number of things in the implementation effort and subsequent usage.  We think a number of these apply towards the development of a net- word-wide File Transfer Protocol, and we hope to stimulate further dis- cussion of these issues.  We discovered some things in the UCSB protocol that we would like to see included in the network-wide protocol, and we see some things that are in the currently proposed net protocol and are unfortunately absent from the UCSB protocol.</t>
</abstract>
</front>

<seriesInfo value="269" name="RFC" />
</reference>


<reference target2="reference.RFC.0270.xml" anchor="RFC0270">
<front>
<title>Correction to BBN Report No</title>
<author fullname="A. McKenzie" initials="A." surname="McKenzie">
<organization>Bolt Baranek and Newman (BBN)</organization>
</author>

<date year="1972" day="1" month="January" />

<abstract>
<t>In the process of generating RFC #271we have discovered a set of errors in BBN Report No. 1822 (NIC 7958).</t>
</abstract>
</front>

<seriesInfo value="270" name="RFC" />
</reference>


<reference target2="reference.RFC.0271.xml" anchor="RFC0271">
<front>
<title>IMP System change notifications</title>
<author fullname="Bernard Cosell" initials="B." surname="Cosell">
<organization>Bolt Baranek and Newman (BBN)</organization>
</author>

<date year="1972" day="3" month="January" />

<abstract>
<t>We are planning to install a new version of the IMP System, version 2514.  The new version is scheduled for field installation Thursday, January 13, 1972 between noon and 1 PM EST, and will require the assistance of IMP-site personnel at each site.</t>
</abstract>
</front>

<seriesInfo value="271" name="RFC" />
</reference>


<reference target2="reference.RFC.0273.xml" anchor="RFC0273">
<front>
<title abbrev="More on Standard Names">More on standard host names</title>
<author fullname="Richard W. Watson" initials="R." surname="Watson">
<organization>Stanford Research Institute (SRI) International,  Augmentation Research Center (ARC)</organization>
</author>

<date year="1971" day="18" month="October" />

<abstract>
<t>The Network Information Center is a logical place to handle this problem of Standard Host Names and so the ball now rests here. This is clearly a delicate subject with people having strong feelings and attachments to names.  No past proposal, including RFC 247, NIC 7668, has yet achieved any acceptance.  This identification seems a natural thing and should be taken into account in setting up a naming scheme.  Therefore, the following proposal is offered which I hope may be satisfactory to everyone.</t>
</abstract>
</front>

<seriesInfo value="273" name="RFC" />
</reference>


<reference target2="reference.RFC.0274.xml" anchor="RFC0274">
<front>
<title>Establishing a local guide for network usage</title>
<author fullname="E. Forman" initials="E." surname="Forman">
<organization>The Mitre Corporation (MITRE)</organization>
</author>

<date year="1971" day="1" month="November" />

<abstract>
<t>Actual experiences and experimentation with network systems and subsystems will be an important supplement to existing NIC documentation.  For this reason, MITRE, to facilitate local user access to network resources, is planning to establish a local GUIDE TO NETWORK USAGE to supplement the Resources Notebook and other NIC documentation.  The Guide will be tailored to the needs of MITRE users and will contain information on network systems and subsystems.</t>
</abstract>
</front>

<seriesInfo value="274" name="RFC" />
</reference>


<reference target2="reference.RFC.0276.xml" anchor="RFC0276">
<front>
<title abbrev="NIC Course">NIC course</title>
<author fullname="Richard W. Watson" initials="R." surname="Watson">
<organization>Stanford Research Institute (SRI) International,  Augmentation Research Center (ARC)</organization>
</author>

<date year="1971" day="8" month="November" />

<abstract>
<t>The Network Information Center is planning to run a course on the use of its Online System (NLS), including use of the Journal, at SRI.  The dates are to be Nov. 29, 30.</t>
</abstract>
</front>

<seriesInfo value="276" name="RFC" />
</reference>


<reference target2="reference.RFC.0278.xml" anchor="RFC0278">
<front>
<title>Revision of the Mail Box Protocol</title>
<author fullname="Abhay Bhushan" initials="A." surname="Bhushan">
<organization>Massachusetts Institute of Technology (MIT), DMCG</organization>
</author>

<author fullname="Bob Braden" initials="B." surname="Braden">
<organization>University California Los Angeles (UCLA), CCN</organization>
</author>

<author fullname="Eric Harslem" initials="E." surname="Harslem">
<organization>RAND Corporation</organization>
</author>

<author fullname="John Heafner" initials="J." surname="Heafner">
<organization>RAND Corporation</organization>
</author>

<author fullname="Alex McKenzie" initials="A." surname="McKenzie">
<organization>Bolt Beranek and Newman Inc. (BBN), NET</organization>
</author>

<author fullname="Bob Sundberg" initials="B." surname="Sundberg">
<organization>Harvard University</organization>
</author>

<author fullname="Dick Watson" initials="D." surname="Watson">
<organization>Stanford Research Institute (SRI) International,  Augmentation Research Center (ARC)</organization>
</author>

<author fullname="Jim White" initials="J." surname="White">
<organization>University California Santa Barbara (UCSB)</organization>
</author>

<date year="1971" day="17" month="November" />

<abstract>
<t>The file transfer committee met and discussed the Mail Box Protocol RFC 221, NIC 7612.  The potential utility for the mechanism was confirmed and a couple of changes suggested.  We first give the changes and then restate the Protocol.</t>
</abstract>
</front>

<seriesInfo value="278" name="RFC" />
</reference>


<reference target2="reference.RFC.0280.xml" anchor="RFC0280">
<front>
<title>A Draft of Host Names</title>
<author fullname="Richard W. Watson" initials="R." surname="Watson">
<organization>Stanford Research Institute (SRI), Augmentation Research Center (ARC)</organization>
</author>

<date year="1971" day="17" month="November" />

<abstract>
<t>The enclosed list of host names is a draft.</t>
</abstract>
</front>

<seriesInfo value="280" name="RFC" />
</reference>


<reference target2="reference.RFC.0281.xml" anchor="RFC0281">
<front>
<title>Suggested addition to File Transfer Protocol</title>
<author fullname="A. McKenzie" initials="A." surname="McKenzie">
<organization>Bolt Baranek and Newman (BBN)</organization>
</author>

<date year="1971" day="8" month="December" />

<abstract>
<t>On November 16, an informal meeting was held at UCLA to discuss prospects for a network standard Remote Job Service (RJS) protocol.</t>
</abstract>
</front>

<seriesInfo value="281" name="RFC" />
</reference>


<reference target2="reference.RFC.0282.xml" anchor="RFC0282">
<front>
<title>Graphics meeting report</title>
<author fullname="M. A. Padlipsky" initials="M." surname="Padlipsky">
<organization>Project MAC</organization>
</author>

<date year="1971" day="8" month="December" />

<abstract>
<t>The second Network Graphics Group Meeting was convened at the Stanford Artificial Intelligence Lab at 6:00p.m. Sunday, November 21st.</t>
</abstract>
</front>

<seriesInfo value="282" name="RFC" />
</reference>


<reference target2="reference.RFC.0283.xml" anchor="RFC0283">
<front>
<title>NETRJT: Remote Job Service Protocol for TIPS</title>
<author fullname="R. T. Braden" initials="R." surname="Braden">
<organization>University of California (UCLA), Los Angeles, Campus Computing Network (CCN)</organization>
</author>

<date year="1971" day="20" month="December" />
</front>

<seriesInfo value="283" name="RFC" />
</reference>


<reference target2="reference.RFC.0285.xml" anchor="RFC0285">
<front>
<title>Network graphics</title>
<author fullname="D. Huff" initials="D." surname="Huff">
<organization>Case Western Reserve University (CWRU)</organization>
</author>

<date year="1971" day="15" month="December" />

<abstract>
<t>Not much has been written about graphics on the ARPANET when the volume of the NIC collection is considered. Presently it contains some 8000 entries of which only about 20 are on the subject of graphics. The reason is probably similar to that given by L. G. Roberts in A FORWARD LOOK (NIC 7542) as the reason that data base sharing or software sharing will not be important topics for several more years: the NET hasn't been up long enough for interested people to have enough of the facts to know if it is feasible and to think creatively.</t>

<t>This paper is therefore aimed at bringing together the present state of graphics on the NET for the newcomer and attempting to add a little more distance to the ground covered so far. I will start with an overview, then proceed to briefly describe past work, and finally add some of my own thoughts.</t>
</abstract>
</front>

<seriesInfo value="285" name="RFC" />
</reference>


<reference target2="reference.RFC.0286.xml" anchor="RFC0286">
<front>
<title>Network Library Information System</title>
<author fullname="E. Forman" initials="E." surname="Forman">
<organization>The Mitre Corporation (MITRE)</organization>
</author>

<date year="1971" day="21" month="December" />

<abstract>
<t>Georgetown University is designing a Learning Resource Center (LRC), part of which may consist of a system to enable computer query (hopefully on-line) of G.U.'s Library holdings.  The ARPA community might be of assistance in either of two ways:</t>

<t>1.  One or more organizations may have a Library Retrieval System that they would like to share with Georgetown</t>

<t>2.  Since there probably are needs for such a system at most organizations, and since it would be highly beneficial for one organization to be able to query other library holdings as well, and subsequently arrange for inter-library loans, the ARPA community might undertake to design a Network Library Information System.</t>

<t>If sufficient interest in such a system exists, a working group could be set up to establish the necessary protocols and iron out details of the system.</t>
</abstract>
</front>

<seriesInfo value="286" name="RFC" />
</reference>


<reference target2="reference.RFC.0287.xml" anchor="RFC0287">
<front>
<title>Status of Network Hosts</title>
<author fullname="Ellen Westheimer" initials="E." surname="Westheimer">
<organization>Bolt Baranek and Newman (BBN)</organization>
</author>

<date year="1971" day="22" month="December" />

<abstract>
<t>This RFC reports on the status of most Network Hosts from December 6 to December 18.</t>
</abstract>
</front>

<seriesInfo value="287" name="RFC" />
</reference>


<reference target2="reference.RFC.0288.xml" anchor="RFC0288">
<front>
<title>Network host status</title>
<author fullname="E. Westheimer" initials="E." surname="Westheimer">
<organization>Bolt Baranek and Newman (BBN)</organization>
</author>

<date year="1972" day="6" month="January" />

<abstract>
<t>This RFC reports on the status of most Network Hosts from December 20 to December 30.</t>
</abstract>
</front>

<seriesInfo value="288" name="RFC" />
</reference>


<reference target2="reference.RFC.0289.xml" anchor="RFC0289">
<front>
<title>What we hope is an official list of host names</title>
<author fullname="Richard W. Watson" initials="R." surname="Watson">
<organization>Stanford Research Institute (SRI), Augmentation Research Center (ARC)</organization>
</author>

<date year="1971" day="21" month="December" />

<abstract>
<t>The enclosed is what we hope will be accepted as a list of official formal host names and nicknames.  As no other subject worked on by the NWG has generated so much comment, it is worthwhile to review briefly how this list came into being.</t>

<t>The need for some standard set of names recognized by NCP's and Telnets and usable on hardcopy to designate a persons affiliation had been recognized for some time and several sets of names were in use.</t>
</abstract>
</front>

<seriesInfo value="289" name="RFC" />
</reference>


<reference target2="reference.RFC.0290.xml" anchor="RFC0290">
<front>
<title abbrev="Computer Networks and Data Sharing Bibliography">Computer networks and data sharing: A bibliography</title>
<author fullname="Alvin P. Mullery" initials="A." surname="Mullery">
<organization>International Business Machines (IBM), Thomas J. Watson Research Center</organization>
</author>

<date year="1972" day="11" month="January" />

<abstract>
<t>The bibliography is broken into seven subject areas - general data structures, data description, data conversion, data management, data security, data transmission, and computer network design.  Two of these areas, general data structures and data management, cover a very broad range of subjects: however, in these two areas, only entries that seem to be specially pertinent to computer networks and data sharing are included.  The bibliography also contains an index of authors.</t>
</abstract>
</front>

<seriesInfo value="290" name="RFC" />
</reference>


<reference target2="reference.RFC.0291.xml" anchor="RFC0291">
<front>
<title>Data Management Meeting Announcement</title>
<author fullname="D. B. McKay" initials="D." surname="McKay">
<organization>International Business Machines (IBM)</organization>

<address>
<phone>+1 914 945 1159</phone>
</address>
</author>

<date year="1972" day="14" month="January" />
</front>

<seriesInfo value="291" name="RFC" />
</reference>


<reference target2="reference.RFC.0292.xml" anchor="RFC0292">
<front>
<title abbrev="Graphics Protocol Level 0">Graphics Protocol: Level 0 only</title>
<author fullname="Jim Michener" initials="J." surname="Michener">
<organization>Massachusetts Institute of Technology (MIT), Project MAC</organization>
</author>

<author fullname="Ira Cotton" initials="I." surname="Cotton">
<organization>The Mitre Corporation (MITRE)</organization>
</author>

<author fullname="Karl Kelley" initials="K." surname="Kelley">
<organization>University of Illinois</organization>
</author>

<author fullname="Dave Liddle" initials="D." surname="Liddle">
<organization />
</author>

<author fullname="Ed Meyer" initials="E." surname="Meyer">
<organization>Massachusetts Institute of Technology (MIT), Project MAC</organization>
</author>

<date year="1972" day="12" month="January" />
</front>

<seriesInfo value="292" name="RFC" />
</reference>


<reference target2="reference.RFC.0293.xml" anchor="RFC0293">
<front>
<title>Network Host Status</title>
<author fullname="Ellen Westheimer" initials="E." surname="Westheimer">
<organization>Bolt Baranek and Newman (BBN)</organization>
</author>

<date year="1972" day="18" month="January" />

<abstract>
<t>This RFC reports on the status of most Network Hosts from January 3 to January 15.</t>
</abstract>
</front>

<seriesInfo value="293" name="RFC" />
</reference>


<reference target2="reference.RFC.0294.xml" anchor="RFC0294">
<front>
<title>The Use of "Set Data Type" Transaction in File Transfer Protocol</title>
<author fullname="Abhay Bhushan" initials="A." surname="Bhushan">
<organization>Massachusetts Institute of Technology (MIT)</organization>
</author>

<date year="1972" day="25" month="January" />

<abstract>
<t>As mentioned in RFC 265, the opcode of '00' is set aside for the clarify the use of 'set data type' in file transfer operations.</t>

<t>In many systems such as Multics at MIT, there is no provision to identify the type of data (i.e., ASCII or numeric) stored in files.</t>
</abstract>
</front>

<seriesInfo value="294" name="RFC" />
</reference>


<reference target2="reference.RFC.0295.xml" anchor="RFC0295">
<front>
<title abbrev="Protocol Workshop Report">Report of the Protocol Workshop, 12 October 1971</title>
<author fullname="Jon Postel" initials="J." surname="Postel">
<organization />
</author>

<date year="1972" day="2" month="January" />
</front>

<seriesInfo value="295" name="RFC" />
</reference>


<reference target2="reference.RFC.0296.xml" anchor="RFC0296">
<front>
<title>DS-1 display system</title>
<author fullname="D.E. Liddle" initials="D.E." surname="Liddle">
<organization />
</author>

<date year="1972" day="27" month="January" />
</front>

<seriesInfo value="296" name="RFC" />
</reference>


<reference target2="reference.RFC.0297.xml" anchor="RFC0297">
<front>
<title>TIP Message Buffers</title>
<author fullname="Dave Walden" initials="D." surname="Walden">
<organization>Bolt Baranek and Newman (BBN)</organization>
</author>

<date year="1972" day="31" month="January" />
</front>

<seriesInfo value="297" name="RFC" />
</reference>


<reference target2="reference.RFC.0298.xml" anchor="RFC0298">
<front>
<title>Network host status</title>
<author fullname="E. Westheimer" initials="E." surname="Westheimer">
<organization />
</author>

<date year="1972" day="11" month="February" />
</front>

<seriesInfo value="298" name="RFC" />
<format octets="8770" type="TXT" target="ftp://ftp.isi.edu/in-notes/rfc298.txt" />
</reference>


<reference target2="reference.RFC.0299.xml" anchor="RFC0299">
<front>
<title>Information Management System</title>
<author fullname="Dorothy Hopkin" initials="D." surname="Hopkin">
<organization>University of Illinois, Urbana, Center for Advanced Computation</organization>

<address>
<postal>
<street>333 Advanced Computation Building</street>
<city>Urbana</city>
<region>IL</region>
<code>61801</code>
<country>US</country>
</postal>

<phone>+1 217 333 8060</phone>
</address>
</author>

<date year="1972" day="11" month="February" />

<abstract>
<t>We intend to build an Information Management and Statistical System for the ILLIAC IV.  It is intended to support various areas of research whose problems are ILLIAC IV suited and whose data bases are large.</t>
</abstract>
</front>

<seriesInfo value="299" name="RFC" />
</reference>


<reference target2="reference.RFC.0300.xml" anchor="RFC0300">
<front>
<title>ARPA Network mailing lists</title>
<author fullname="J.B. North" initials="J.B." surname="North">
<organization />
</author>

<date year="1972" day="25" month="January" />
</front>

<seriesInfo value="300" name="RFC" />
<format octets="16357" type="TXT" target="ftp://ftp.isi.edu/in-notes/rfc300.txt" />
</reference>


<reference target2="reference.RFC.0301.xml" anchor="RFC0301">
<front>
<title>BBN IMP (#5) and NCC Schedule March 4, 1971</title>
<author fullname="R. Alter" initials="R." surname="Alter">
<organization>Bolt Baranek and Newman (BBN)</organization>
</author>

<date year="1972" day="11" month="February" />

<abstract>
<t>On Saturday morning, March 4, 1972, at 0800 EST the BBN IMP (#5) will go off the air to allow for a move of the equipment to a new location in BBN's facilities.</t>
</abstract>
</front>

<seriesInfo value="301" name="RFC" />
</reference>


<reference target2="reference.RFC.0302.xml" anchor="RFC0302">
<front>
<title>Exercising The ARPANET</title>
<author fullname="Roland F. Bryan" initials="R." surname="Bryan">
<organization>University California Santa Barbara (UCSB), Computer Research Laboratory</organization>
</author>

<date year="1972" day="8" month="February" />
</front>

<seriesInfo value="302" name="RFC" />
</reference>


<reference target2="reference.RFC.0303.xml" anchor="RFC0303">
<front>
<title>ARPA Network mailing lists</title>
<author>
<organization />
</author>

<date year="1972" day="3" month="March" />

<abstract>
<t>The following are three lists to be used for distribution of Network documents.</t>
</abstract>
</front>

<seriesInfo value="303" name="RFC" />
</reference>


<reference target2="reference.RFC.0304.xml" anchor="RFC0304">
<front>
<title>Data management system proposal for the ARPA network</title>
<author fullname="D.B. McKay" initials="D.B." surname="McKay">
<organization />
</author>

<date year="1972" day="17" month="February" />
</front>

<seriesInfo value="304" name="RFC" />
</reference>


<reference target2="reference.RFC.0305.xml" anchor="RFC0305">
<front>
<title>Unknown Host Numbers</title>
<author fullname="Ralph Alter" initials="R." surname="Alter">
<organization>Bolt Baranek and Newman (BBN)</organization>
</author>

<date year="1972" day="23" month="February" />

<abstract>
<t>In response to a recent minor flurry of confusion, it seems worth announcing publicly the fact that new IMPs are tested (almost always) on the ARPA Net here at BBN before delivery to the intended site.  Accordingly, sites should not be surprised to receive RFCs or at least RSTs from IMPs or Hosts they thought didn't exist, or at least did not exist yet.</t>
</abstract>
</front>

<seriesInfo value="305" name="RFC" />
</reference>


<reference target2="reference.RFC.0306.xml" anchor="RFC0306">
<front>
<title>Network host status</title>
<author fullname="E. Westheimer" initials="E." surname="Westheimer">
<organization>Bolt Baranek and Newman (BBN)</organization>
</author>

<date year="1972" day="15" month="February" />

<abstract>
<t>This RFC reports on the status of most Network Hosts from January 31 to February 11.</t>
</abstract>
</front>

<seriesInfo value="306" name="RFC" />
</reference>


<reference target2="reference.RFC.0307.xml" anchor="RFC0307">
<front>
<title>Using network Remote Job Entry</title>
<author fullname="E. Harslem" initials="E." surname="Harslem">
<organization>Rand Corporation</organization>
</author>

<date year="1972" day="24" month="February" />
</front>

<seriesInfo value="307" name="RFC" />
</reference>


<reference target2="reference.RFC.0308.xml" anchor="RFC0308">
<front>
<title>ARPANET host availability data</title>
<author fullname="Marc Seriff" initials="M." surname="Seriff">
<organization>Massachusetts Institute of Technology (MIT), DMCG</organization>

<address>
<postal>
<street>545 Main Street</street>
<city>Cambridge</city>
<region>MA</region>
<code>02139</code>
<country>US</country>
</postal>

<phone>+1 617 864 6900 x1458</phone>
</address>
</author>

<date year="1972" day="13" month="March" />

<abstract>
<t>Several months ago a SURVEY program was implemented on the MIT-DMCG ITS PDP-10 system to aid in gathering information on the availability of various HOSTS on the ARPANET.  The purpose of this Request for Comments is threefold:</t>

<t>1. to inform the Network Working Group of the existence of this information gathering service and about getting access to it, 2. to present the results of SURVEY for its first few months, and 3. to correct errors in our data or collection methods.</t>
</abstract>
</front>

<seriesInfo value="308" name="RFC" />
</reference>


<reference target2="reference.RFC.0309.xml" anchor="RFC0309">
<front>
<title>Data and File Transfer Workshop Announcement</title>
<author fullname="Abhay Bhushan" initials="A." surname="Bhushan">
<organization>Massachusetts Institute of Technology (MIT), Project MAC</organization>
</author>

<date year="1972" day="17" month="March" />

<abstract>
<t>The objective of this workshop is to arrive at a unified convention for ARPANET data and file transfer.</t>
</abstract>
</front>

<seriesInfo value="309" name="RFC" />
</reference>


<reference target2="reference.RFC.0310.xml" anchor="RFC0310">
<front>
<title abbrev="Another Look At Data And FTP">Another Look at Data and File Transfer Protocols</title>
<author fullname="Abhay K. Bhushan" initials="A." surname="Bhushan">
<organization>Massachusetts Institute of Technology (MIT), Project MAC</organization>
</author>

<date year="1972" day="3" month="April" />

<abstract>
<t>Our experience with ad hoc techniques of data and file transfer over the ARPANET together with a better knowledge of terminal IMP (TIP) capabilities and Datacomputer requirements has indicated to us that the Data Transfer Protocol (DTP) (see ref 1) and the File Transfer Protocol (FTP) (see ref 2) could undergo revision.  Our effort in implementing DTP and FTP has revealed areas in which the protocols could be simplified without degrading their usefulness.</t>

<t>This paper suggests some specific changes in DTP and FTP that should make them more useful and/or simplify implementation.  The attempt here is to stimulate thinking so that we may come up with a better protocol at the forthcoming Data and File Transfer Workshop (see ref 3).</t>
</abstract>
</front>

<seriesInfo value="310" name="RFC" />
</reference>


<reference target2="reference.RFC.0311.xml" anchor="RFC0311">
<front>
<title>New Console Attachments to the USCB Host</title>
<author fullname="Roland F. Bryan" initials="R." surname="Bryan">
<organization>University California Santa Barbara (UCSB), Computer Research Laboratory</organization>
</author>

<date year="1972" day="29" month="February" />
</front>

<seriesInfo value="311" name="RFC" />
</reference>


<reference target2="reference.RFC.0312.xml" anchor="RFC0312">
<front>
<title>Proposed Change in IMP-to-Host Protocol</title>
<author fullname="Alex McKenzie" initials="A." surname="McKenzie">
<organization>Bolt Baranek and Newman (BBN)</organization>
</author>

<date year="1972" day="22" month="March" />

<abstract>
<t>We are currently considering a redefinition of the IMP-to-Host error message types (type 1 and type 8) and the creation of additional IMP-to-Host error message types.  We believe that these changes will assist the Hosts in determining appropriate recovery action, without causing any serious reprogramming problems.  Our current plans are to install these changes within a few months; therefore we should be informed of any strong negative reactions relatively quickly.</t>
</abstract>
</front>

<seriesInfo value="312" name="RFC" />
</reference>


<reference target2="reference.RFC.0313.xml" anchor="RFC0313">
<front>
<title>Computer based instruction</title>
<author fullname="Tom O&apos;Sullivan" initials="T." surname="O&apos;Sullivan">
<organization>Raytheon Corporation</organization>
</author>

<date year="1972" day="6" month="March" />

<abstract>
<t>Current development of Computer Based Instruction (CBI) systems seem to be directed toward two types of system:</t>

<t>1.)  Small to medium scale, dedicated, stand alone systems (such as the IBM 1130, 1500, 1800 complexes) or medium scale systems with dedicated network implications (such as TICKET), and 2.)  Large, centralized, dedicated systems with dedicated network implications (such as PLATO).</t>
</abstract>
</front>

<seriesInfo value="313" name="RFC" />
</reference>


<reference target2="reference.RFC.0314.xml" anchor="RFC0314">
<front>
<title>Network Graphics Working Group Meeting</title>
<author fullname="Ira Cotton" initials="I." surname="Cotton">
<organization>Mitre Corporation</organization>
</author>

<date year="1972" day="14" month="March" />

<abstract>
<t>The next network graphics working group meeting has definitely been scheduled for April 16-18 at The Mitre Corporation, McLean, Virginia.</t>
</abstract>
</front>

<seriesInfo value="314" name="RFC" />
</reference>


<reference target2="reference.RFC.0315.xml" anchor="RFC0315">
<front>
<title>Network Host Status</title>
<author fullname="Ellen Westheimer" initials="E." surname="Westheimer">
<organization>Bolt Baranek and Newman (BBN)</organization>
</author>

<date year="1972" day="8" month="March" />

<abstract>
<t>This RFC reports on the status of most Network Hosts from February 14 to February 25.</t>
</abstract>
</front>

<seriesInfo value="315" name="RFC" />
</reference>


<reference target2="reference.RFC.0316.xml" anchor="RFC0316">
<front>
<title abbrev="Data Management Working Group">ARPA Network Data Management Working Group</title>
<author fullname="Douglas B. McKay" initials="D." surname="McKay">
<organization>International Business Machines (IBM)</organization>
</author>

<author fullname="A. P. Mullery" initials="A.P." surname="Mullery">
<organization>International Business Machines (IBM)</organization>
</author>

<date year="1972" day="23" month="February" />

<abstract>
<t>The meeting had two different phases.  The first included presentations of applications of networks and development work in the design to allow data sharing in a computer network, the second was a working meeting in which was discussed what the data management working group should do.</t>
</abstract>
</front>

<seriesInfo value="316" name="RFC" />
</reference>


<reference target2="reference.RFC.0317.xml" anchor="RFC0317">
<front>
<title>Official Host-Host Protocol Modification: Assigned Link Numbers</title>
<author fullname="Jon Postel" initials="J." surname="Postel">
<organization>University California Los Angeles (UCLA), Computer Science Department, NMC</organization>
</author>

<date year="1972" day="20" month="March" />
</front>

<seriesInfo value="317" name="RFC" />
</reference>


<reference target2="reference.RFC.0318.xml" anchor="RFC0318">
<front>
<title>Telnet Protocols</title>
<author fullname="Jon Postel" initials="J." surname="Postel">
<organization>University California Los Angeles (UCLA), Computer Science Department, NMC</organization>

<address>
<postal>
<street>3804 Boelter Hall</street>
<city>Los Angeles</city>
<region>CA</region>
<code>90024</code>
<country>US</country>
</postal>

<phone>+1 213 825 2368</phone>
</address>
</author>

<date year="1972" day="3" month="April" />

<abstract>
<t>At the October 1971 Network Working Group Meeting, I promised to promptly produce a document which clearly and succinctly specified and explained the Official Telnet Protocol.  This document fails to meet any part of that promise.  This document was not produced promptly.  This document is neither clear nor succinct.  There is NO Official Telnet Protocol.</t>

<t>The following pages present my understanding of the ad hoc Telnet protocol.  There are some who have serious questions about this protocol.  The proposed changes to the protocol are given in Section IV.</t>
</abstract>
</front>

<seriesInfo value="318" name="RFC" />
</reference>


<reference target2="reference.RFC.0319.xml" anchor="RFC0319">
<front>
<title>Network Host Status</title>
<author fullname="Ellen Westheimer" initials="E." surname="Westheimer">
<organization>Bolt Baranek and Newman (BBN)</organization>
</author>

<date year="1972" day="21" month="March" />

<abstract>
<t>This RFC reports on the status of most Network Hosts from February 28 to March 10.  The ETAC Terminal IMP (Network address 148) was installed during this period.</t>
</abstract>
</front>

<seriesInfo value="319" name="RFC" />
</reference>


<reference target2="reference.RFC.0320.xml" anchor="RFC0320">
<front>
<title>Workshop on Hard Copy Line Printers</title>
<author fullname="R. Reddy" initials="R." surname="Reddy">
<organization />
</author>

<date year="1972" day="27" month="March" />
</front>

<seriesInfo value="320" name="RFC" />
</reference>


<reference target2="reference.RFC.0321.xml" anchor="RFC0321">
<front>
<title>CBI Networking Activity at MITRE</title>
<author fullname="Peggy M. Karp" initials="P." surname="Karp">
<organization>MITRE Corporation</organization>
</author>

<date year="1972" day="24" month="March" />

<abstract>
<t>This RFC is in response to Tom O'Sullivan's probe for comments on Computer Based Instruction. MITRE is currently doing some pre liminary work in the area,at the present time limited to use of CAI-related network resources.</t>

<t>The most expedient way for me to respond is by attaching excerpts taken from a recent status report prepared for internal MITRE use, intended for staff not generally familiar with the ARPANET. Comments directed at specific items in Tom's attachment will follow in a future RFC.</t>

<t>We welcome comments on our activities and would like to participate in any CBI dialogs that take place.</t>
</abstract>
</front>

<seriesInfo value="321" name="RFC" />
</reference>


<reference target2="reference.RFC.0322.xml" anchor="RFC0322">
<front>
<title>Well known socket numbers</title>
<author fullname="V. Cerf" initials="V." surname="Cerf">
<organization>University California Los Angeles (UCLA), NMC</organization>

<address>
<postal>
<street>3804 Boelter Hall</street>
<city>Los Angeles</city>
<region>CA</region>
<code>90024</code>
<country>US</country>
</postal>

<phone>+1 213 825 4864</phone>
</address>
</author>

<author fullname="J. Postel" initials="J." surname="Postel">
<organization>University California Los Angeles (UCLA), NMC</organization>

<address>
<postal>
<street>3804 Boelter Hall</street>
<city>Los Angeles</city>
<region>CA</region>
<code>90024</code>
<country>US</country>
</postal>

<phone>+1 213 825 4733</phone>
</address>
</author>

<date year="1972" day="26" month="March" />

<abstract>
<t>The Network Measurement Group would like to establish a network standard socket number for a Process Discard service (not all HOSTs need cooperate.) To do this, it is necessary to know which sockets at each HOST have already been allocated to standard network functions.</t>
</abstract>
</front>

<seriesInfo value="322" name="RFC" />
</reference>


<reference target2="reference.RFC.0323.xml" anchor="RFC0323">
<front>
<title>Formation of Network Measurement Group (NMG)</title>
<author fullname="Vint Cerf" initials="V." surname="Cerf">
<organization>University California Los Angeles (UCLA), NMC</organization>
</author>

<date year="1972" day="23" month="March" />

<abstract>
<t>On March 17, 1972, at MIT project MAC, the following group met to discuss plans to perform measurement experiments on the ARPANET:</t>

<t>The purpose of the meeting was to discuss existing and planned measurements of network and HOST behavior.</t>
</abstract>
</front>

<seriesInfo value="323" name="RFC" />
</reference>


<reference target2="reference.RFC.0324.xml" anchor="RFC0324">
<front>
<title>RJE Protocol meeting</title>
<author fullname="J. Postel" initials="J." surname="Postel">
<organization>University of California, Los Angeles (UCLA), NMC</organization>
</author>

<date year="1972" day="3" month="April" />

<abstract>
<t>There will be a meeting to discuss Remote Job Entry (RJE) protocols in the ARPA Network on Friday 21 April 72.</t>
</abstract>
</front>

<seriesInfo value="324" name="RFC" />
</reference>


<reference target2="reference.RFC.0325.xml" anchor="RFC0325">
<front>
<title>Network Remote Job Entry program - NETRJS</title>
<author fullname="G. Hicks" initials="G." surname="Hicks">
<organization />
</author>

<date year="1972" day="6" month="April" />
</front>

<seriesInfo value="325" name="RFC" />
<format octets="17499" type="TXT" target="ftp://ftp.isi.edu/in-notes/rfc325.txt" />
</reference>


<reference target2="reference.RFC.0326.xml" anchor="RFC0326">
<front>
<title>Network Host Status</title>
<author fullname="Ellen Westheimer" initials="E." surname="Westheimer">
<organization>Bolt Baranek and Newman (BBN)</organization>
</author>

<date year="1972" day="3" month="April" />

<abstract>
<t>This RFC reports on the status of most Network Hosts from March 13 to March 24.  During this period the SRI-AI computer became a server.</t>
</abstract>
</front>

<seriesInfo value="326" name="RFC" />
</reference>


<reference target2="reference.RFC.0327.xml" anchor="RFC0327">
<front>
<title>Data and File Transfer workshop notes</title>
<author fullname="A. Bhushan" initials="A." surname="Bhushan">
<organization>Massachusetts Institute of Technology (MIT), Project MAC</organization>
</author>

<date year="1972" day="27" month="April" />

<abstract>
<t>On April 14 and 15, 1972, a Data and File Transfer Workshop was held at M.I.T., Cambridge, Mass.</t>
</abstract>
</front>

<seriesInfo value="327" name="RFC" />
</reference>


<reference target2="reference.RFC.0328.xml" anchor="RFC0328">
<front>
<title>Suggested Telnet Protocol Changes</title>
<author fullname="Jon Postel" initials="J." surname="Postel">
<organization>University of California, Los Angeles (UCLA), Computer Science, NMC</organization>
</author>

<date year="1972" day="29" month="April" />

<abstract>
<t>I hereby propose the following changes to the Telnet protocol.  If no substantial negative response is received by 15 May 72 it will be assumed that these changes are desired and should be incorporated in any "Official Telnet Protocol".</t>

<t>First I suggest that we drop the idea of a "minimum" implementation and require a standard implementation which includes all aspects of the protocol.</t>

<t>Second I suggest that we eliminate the DATA TYPE signals.</t>

<t>Third I suggest that we do away with HIDE YOUR INPUT signal.</t>
</abstract>
</front>

<seriesInfo value="328" name="RFC" />
</reference>


<reference target2="reference.RFC.0329.xml" anchor="RFC0329">
<front>
<title>ARPA Network Mailing Lists</title>
<author>
<organization>SRI/Network Information Center</organization>
</author>

<date year="1972" day="17" month="May" />
</front>

<seriesInfo value="329" name="RFC" />
<format octets="23861" type="TXT" target="ftp://ftp.isi.edu/in-notes/rfc329.txt" />
</reference>


<reference target2="reference.RFC.0330.xml" anchor="RFC0330">
<front>
<title>Network Host Status</title>
<author fullname="Ellen Westheimer" initials="E." surname="Westheimer">
<organization>Bolt Beranek and Newman (BBN)</organization>
</author>

<date year="1972" day="13" month="April" />

<abstract>
<t>This RFC reports on the status of most Network Hosts from March 27 to April 7.</t>
</abstract>
</front>

<seriesInfo value="330" name="RFC" />
</reference>


<reference target2="reference.RFC.0331.xml" anchor="RFC0331">
<front>
<title>IMP System Change Notification</title>
<author fullname="J. McQuillan" initials="J." surname="McQuillan">
<organization>Bolt Beranek and Newman (BBN), NET</organization>
</author>

<date year="1972" day="19" month="April" />

<abstract>
<t>We are planning to release IMPSYS 2600 on May 15, 1972, between 12 noon and 3 p.m. E.D.T.  As discussed at the March 16 seminar held at BBN, this release constitutes a major change to the IMP program. Because of the magnitude of the change, the system will be released on an experimental basis.  If problems develop, then the current system, IMPSYS 2514, will be reloaded and the cutover for IMPSYS 2600 will be rescheduled for some later time.</t>
</abstract>
</front>

<seriesInfo value="331" name="RFC" />
</reference>


<reference target2="reference.RFC.0332.xml" anchor="RFC0332">
<front>
<title>Network Host Status</title>
<author fullname="Ellen Westheimer" initials="E." surname="Westheimer">
<organization>Bolt Beranek and Newman (BBN)</organization>
</author>

<date year="1972" day="25" month="April" />

<abstract>
<t>This RFC reports on the status of most Network Hosts from April 10 to April 21.</t>
</abstract>
</front>

<seriesInfo value="332" name="RFC" />
</reference>


<reference target2="reference.RFC.0333.xml" anchor="RFC0333">
<front>
<title>Proposed experiment with a Message Switching Protocol</title>
<author fullname="R.D. Bressler" initials="R.D." surname="Bressler">
<organization />
</author>

<author fullname="D. Murphy" initials="D." surname="Murphy">
<organization />
</author>

<author fullname="D.C. Walden" initials="D.C." surname="Walden">
<organization />
</author>

<date year="1972" day="15" month="May" />
</front>

<seriesInfo value="333" name="RFC" />
<format octets="62507" type="TXT" target="ftp://ftp.isi.edu/in-notes/rfc333.txt" />
</reference>


<reference target2="reference.RFC.0334.xml" anchor="RFC0334">
<front>
<title>Network Use on May 8</title>
<author fullname="Alex McKenzie" initials="A." surname="McKenzie">
<organization>Bolt Beranek and Newman (BBN)</organization>
</author>

<date year="1972" day="1" month="May" />

<abstract>
<t>Vint Cerf of UCLA Network Measurement Center has just indicated to us a requirement to carry out certain performance experiments on the network prior to installation of the new IMP software on May 15.</t>
</abstract>
</front>

<seriesInfo value="334" name="RFC" />
</reference>


<reference target2="reference.RFC.0335.xml" anchor="RFC0335">
<front>
<title>New Interface - IMP/360</title>
<author fullname="Roland F. Bryan" initials="R." surname="Bryan">
<organization>University of California, Santa Barbara (UCSB), Computer Research Laboratory</organization>
</author>

<date year="1972" day="1" month="May" />

<abstract>
<t>The former interface to the network for our 360-75 was replaced by a production unit similar to the NASA- AMES and USC versions.  This controller went into operation 1 May 1972.</t>

<t>We would be pleased to hear of any difficulties network users encounter, while operating with UCSB, that might be related to this unit. Thank you.</t>
</abstract>
</front>

<seriesInfo value="335" name="RFC" />
</reference>


<reference target2="reference.RFC.0336.xml" anchor="RFC0336">
<front>
<title>Level 0 Graphic Input Protocol</title>
<author fullname="Ira Cotton" initials="I." surname="Cotton">
<organization>The MITRE Corporation</organization>
</author>

<date year="1972" day="5" month="May" />

<abstract>
<t>At its meeting on April 16-18 the network Graphics working group began to consider the definition of levels of protocol for graphic Input Protocol.</t>
</abstract>
</front>

<seriesInfo value="336" name="RFC" />
</reference>


<reference target2="reference.RFC.0338.xml" anchor="RFC0338">
<front>
<title>EBCDIC/ASCII Mapping for Network RJE</title>
<author fullname="R.T. Braden" initials="R.T." surname="Braden">
<organization />
</author>

<date year="1972" day="17" month="May" />
</front>

<seriesInfo value="338" name="RFC" />
<format octets="11494" type="TXT" target="ftp://ftp.isi.edu/in-notes/rfc338.txt" />
<format octets="2386987" type="PS" target="ftp://ftp.isi.edu/in-notes/rfc338.ps" />
<format octets="1871020" type="PDF" target="ftp://ftp.isi.edu/in-notes/rfc338.pdf" />
</reference>


<reference target2="reference.RFC.0339.xml" anchor="RFC0339">
<front>
<title>MLTNET: A "Multi Telnet" Subsystem for Tenex</title>
<author fullname="R.Thomas" initials="R." surname="Thomas">
<organization>Bolt Beranek and Newman (BBN)</organization>
</author>

<date year="1972" day="5" month="May" />
</front>

<seriesInfo value="339" name="RFC" />
</reference>


<reference target2="reference.RFC.0340.xml" anchor="RFC0340">
<front>
<title>Proposed Telnet Changes</title>
<author fullname="Tom O&apos;Sullivan" initials="T." surname="O&apos;Sullivan">
<organization>Raytheon Company</organization>
</author>

<date year="1972" day="15" month="May" />

<abstract>
<t>The proposed change to the TELNET protocol calling for one standard protocol and dropping the idea of minimum implementation seems reasonable at this time.</t>
</abstract>
</front>

<seriesInfo value="340" name="RFC" />
</reference>


<reference target2="reference.RFC.0342.xml" anchor="RFC0342">
<front>
<title>Network Host Status</title>
<author fullname="Ellen Westheimer" initials="E." surname="Westheimer">
<organization>Bolt Beranek and Newman (BBN)</organization>
</author>

<date year="1972" day="15" month="May" />

<abstract>
<t>This RFC reports on the status of most Network Hosts from April 24 to May 5.</t>
</abstract>
</front>

<seriesInfo value="342" name="RFC" />
</reference>


<reference target2="reference.RFC.0343.xml" anchor="RFC0343">
<front>
<title>IMP System change notification</title>
<author fullname="A.M. McKenzie" initials="A.M." surname="McKenzie">
<organization />
</author>

<date year="1972" day="19" month="May" />
</front>

<seriesInfo value="343" name="RFC" />
<format octets="3370" type="TXT" target="ftp://ftp.isi.edu/in-notes/rfc343.txt" />
</reference>


<reference target2="reference.RFC.0344.xml" anchor="RFC0344">
<front>
<title>Network Host Status</title>
<author fullname="Ellen Westheimer" initials="E." surname="Westheimer">
<organization>Bolt Beranek and Newman (BBN)</organization>
</author>

<date year="1972" day="22" month="May" />

<abstract>
<t>This RFC reports on the status of most Network Hosts from May 8 to May 19.</t>
</abstract>
</front>

<seriesInfo value="344" name="RFC" />
</reference>


<reference target2="reference.RFC.0345.xml" anchor="RFC0345">
<front>
<title>Interest in Mixed Integer Programming (MPSX on NIC 360/91 at CCN)</title>
<author fullname="Karl Kelley" initials="K." surname="Kelley">
<organization>University of Illinois</organization>
</author>

<date year="1972" day="26" month="May" />

<abstract>
<t>MPSX is a newer version of the IBM project MPS, used for integer programming.  From what I've been told, MPSX outperforms the previous package.  In addition, it has available a feature of mixed integer programming.</t>
</abstract>
</front>

<seriesInfo value="345" name="RFC" />
</reference>


<reference target2="reference.RFC.0346.xml" anchor="RFC0346">
<front>
<title>Satellite Considerations</title>
<author fullname="Jon Postel" initials="J." surname="Postel">
<organization>University of California, Los Angeles (UCLA), Computer Science, NMC</organization>
</author>

<date year="1972" day="30" month="May" />

<abstract>
<t>The consideration of using space satellite transmission links in the ARPANET should be cause for some thought by the parties making use of the network.</t>
</abstract>
</front>

<seriesInfo value="346" name="RFC" />
</reference>


<reference target2="reference.RFC.0347.xml" anchor="RFC0347">
<front>
<title>Echo process</title>
<author fullname="Jon Postel" initials="J." surname="Postel">
<organization>University of California, Los Angeles (UCLA), Computer Science, NMC</organization>
</author>

<date year="1972" day="30" month="May" />

<abstract>
<t>I suggest that for debugging and measurement purposes those hosts which are willing implement an "Echo" process.</t>
</abstract>
</front>

<seriesInfo value="347" name="RFC" />
</reference>


<reference target2="reference.RFC.0348.xml" anchor="RFC0348">
<front>
<title>Discard Process</title>
<author fullname="Jon Postel" initials="J." surname="Postel">
<organization>University of California, Los Angeles (UCLA),  Computer Science, NMC</organization>
</author>

<date year="1972" day="30" month="May" />

<abstract>
<t>I suggest that for debugging and measurement purposes those hosts which are willing implement a "Discard" process.</t>
</abstract>
</front>

<seriesInfo value="348" name="RFC" />
</reference>


<reference target2="reference.RFC.0349.xml" anchor="RFC0349">
<front>
<title>Proposed Standard Socket Numbers</title>
<author fullname="Jon Postel" initials="J." surname="Postel">
<organization>University of California, Los Angeles (UCLA), NMC</organization>
</author>

<date year="1972" day="30" month="May" />

<abstract>
<t>I propose that there be a czar (me ?) who hands out official socket numbers for use by standard protocols.  This czar should also keep track of and publish a list of those socket numbers where host specific services can be obtained.</t>
</abstract>
</front>

<seriesInfo value="349" name="RFC" />
</reference>


<reference target2="reference.RFC.0350.xml" anchor="RFC0350">
<front>
<title>User Accounts for UCSB On-Line System</title>
<author fullname="R. M. Stoughton" initials="R." surname="Stoughton">
<organization>University of California, Santa Barbara (UCSB)</organization>
</author>

<date year="1972" day="18" month="May" />

<abstract>
<t>For the past year UCSB has provided free use of the UCSB On-line System to Network sites.  Recharges for this service are being paid for by the Computer Research Lab with funds out of our current ARPA contract.  Connect time for the month of April totaled 152 hours.</t>

<t>Presently, all users are running on the same account: User Number=196, ID Code=57372, User Name=ARPA.  As such, it is difficult to monitor the amount of use by each site.  Consequently, we are changing the login procedure for Network users, effective 1 June 72.</t>
</abstract>
</front>

<seriesInfo value="350" name="RFC" />
</reference>


<reference target2="reference.RFC.0351.xml" anchor="RFC0351">
<front>
<title>Graphics information form for the ARPANET graphics resources notebook</title>
<author fullname="D. Crocker" initials="D." surname="Crocker">
<organization />
</author>

<date year="1972" day="5" month="June" />
</front>

<seriesInfo value="351" name="RFC" />
<format octets="2150" type="TXT" target="ftp://ftp.isi.edu/in-notes/rfc351.txt" />
</reference>


<reference target2="reference.RFC.0352.xml" anchor="RFC0352">
<front>
<title>TIP Site Information Form</title>
<author fullname="David H. Crocker" initials="D." surname="Crocker">
<organization>University of California, Los Angeles (UCLA), School of Engineering and Applied Science, Computer Science Department</organization>

<address>
<postal>
<street>3804 Boelter Hall</street>
<city>Los Angeles</city>
<region>CA</region>
<code>90024</code>
<country>US</country>
</postal>

</address>
</author>

<date year="1972" day="5" month="June" />

<abstract>
<t>(tips) Information form about ARPANET TIPS:</t>

<t>We are attempting to provide additional information for TIP users of the NET.  The availability of such information should allow more flexibility to TIP users and thereby make NET use easier.</t>
</abstract>
</front>

<seriesInfo value="352" name="RFC" />
</reference>


<reference target2="reference.RFC.0353.xml" anchor="RFC0353">
<front>
<title>Network host status</title>
<author fullname="E. Westheimer" initials="E." surname="Westheimer">
<organization />
</author>

<date year="1972" day="12" month="June" />
</front>

<seriesInfo value="353" name="RFC" />
<format octets="8747" type="TXT" target="ftp://ftp.isi.edu/in-notes/rfc353.txt" />
</reference>


<reference target2="reference.RFC.0354.xml" anchor="RFC0354">
<front>
<title>File Transfer Protocol</title>
<author fullname="Abhay Bhushan" initials="A." surname="Bhushan">
<organization>Massachusetts Institute of Technology (MIT), Project MAC</organization>
</author>

<date year="1972" day="8" month="July" />
</front>

<seriesInfo value="354" name="RFC" />
</reference>


<reference target2="reference.RFC.0355.xml" anchor="RFC0355">
<front>
<title>Response to NWG/RFC 346</title>
<author fullname="John Davidson" initials="J." surname="Davidson">
<organization>University of Hawaii (UH),  ALOHA SYSTEM</organization>
</author>

<date year="1972" day="9" month="June" />

<abstract>
<t>Long transmission delays such as those inherent in satellite communication are most certainly a cause for concern among users of remote interactive systems.  Since the University of Hawaii will, by the end of this year, be linked to the ARPANET via satellite, the consequences of such delays are perhaps of more immediate concern to us than to current members of the surface net.  Consequently the BCC 500 research group here has been studying various solutions to the problems of buffer allocation, partitioned echoing, etc. re-introduced in RFC 346.</t>

<t>Generally, the solutions come from extensions to the original design concepts of the BCC 500 distributed communication system.</t>
</abstract>
</front>

<seriesInfo value="355" name="RFC" />
</reference>


<reference target2="reference.RFC.0356.xml" anchor="RFC0356">
<front>
<title>ARPA Network Control Center</title>
<author fullname="R. Alter" initials="R." surname="Alter">
<organization>Bolt Beranek and Newman Inc. (BBN), ARPA Network Control Center(NCC)</organization>

<address>
<postal>
<street>50 Moulton Street</street>
<city>Cambridge</city>
<region>MA</region>
<code>02138</code>
<country>US</country>
</postal>

<phone>+1 617 661 0100</phone>
</address>
</author>

<date year="1972" day="21" month="June" />
</front>

<seriesInfo value="356" name="RFC" />
</reference>


<reference target2="reference.RFC.0357.xml" anchor="RFC0357">
<front>
<title>Echoing strategy for satellite links</title>
<author fullname="J. Davidson" initials="J." surname="Davidson">
<organization />
</author>

<date year="1972" day="26" month="June" />
</front>

<seriesInfo value="357" name="RFC" />
<format octets="30103" type="TXT" target="ftp://ftp.isi.edu/in-notes/rfc357.txt" />
</reference>


<reference target2="reference.RFC.0359.xml" anchor="RFC0359">
<front>
<title>Status of the Release of the New IMP System (2600)</title>
<author fullname="Dave Walden" initials="D." surname="Walden">
<organization>Bolt Baranek and Newman (BBN)</organization>
</author>

<date year="1972" day="22" month="June" />

<abstract>
<t>We have still not managed to get the new IMP system up.</t>
</abstract>
</front>

<seriesInfo value="359" name="RFC" />
</reference>


<reference target2="reference.RFC.0360.xml" anchor="RFC0360">
<front>
<title>Proposed Remote Job Entry Protocol</title>
<author fullname="C. Holland" initials="C." surname="Holland">
<organization />
</author>

<date year="1972" day="24" month="June" />
</front>

<seriesInfo value="360" name="RFC" />
</reference>


<reference target2="reference.RFC.0361.xml" anchor="RFC0361">
<front>
<title>Deamon Processes on Host 106</title>
<author fullname="Bob Bressler" initials="B." surname="Bressler">
<organization>Massachusetts Institute of Technology (MIT), DMCG</organization>
</author>

<date year="1972" day="5" month="July" />

<abstract>
<t>In response to RFCs 347 and 348, ECHO and DISCARD, MIT-DMCG (Host 106) now has deamon processes that will respond to RFCs on sockets 7 and 9.</t>
</abstract>
</front>

<seriesInfo value="361" name="RFC" />
</reference>


<reference target2="reference.RFC.0362.xml" anchor="RFC0362">
<front>
<title>Network Host Status</title>
<author fullname="Ellen Westheimer" initials="E." surname="Westheimer">
<organization>Bolt Baranek and Newman (BBN)</organization>
</author>

<date year="1972" day="28" month="June" />

<abstract>
<t>This RFC reports on the status of most Network Hosts from June 5 to June 16.</t>
</abstract>
</front>

<seriesInfo value="362" name="RFC" />
</reference>


<reference target2="reference.RFC.0363.xml" anchor="RFC0363">
<front>
<title>ARPA Network mailing lists</title>
<author>
<organization>SRI/Network Information Center</organization>
</author>

<date year="1972" day="8" month="August" />
</front>

<seriesInfo value="363" name="RFC" />
<format octets="25356" type="TXT" target="ftp://ftp.isi.edu/in-notes/rfc363.txt" />
</reference>


<reference target2="reference.RFC.0364.xml" anchor="RFC0364">
<front>
<title>Serving remote users on the ARPANET</title>
<author fullname="Marshall D. Abrams" initials="M." surname="Abrams">
<organization>National Bureau of Standards</organization>
</author>

<date year="1972" day="11" month="July" />
</front>

<seriesInfo value="364" name="RFC" />
</reference>


<reference target2="reference.RFC.0365.xml" anchor="RFC0365">
<front>
<title>Letter to All TIP Users</title>
<author fullname="David Walden" initials="D." surname="Walden">
<organization>Bolt Beranek and Newman Inc. (BBN)</organization>
</author>

<date year="1972" day="11" month="July" />

<abstract>
<t>You will shortly be sent a revised version of the "TIP User's Guide."  Besides now having a loose leaf format, mainly descriptions of new commands have been added.  Appendix B will be an alphabetical list of all TIP commands.</t>
</abstract>
</front>

<seriesInfo value="365" name="RFC" />
</reference>


<reference target2="reference.RFC.0366.xml" anchor="RFC0366">
<front>
<title>Network Host Status</title>
<author fullname="Ellen Westheimer" initials="E." surname="Westheimer">
<organization>Bolt Baranek and Newman (BBN)</organization>
</author>

<date year="1972" day="11" month="July" />

<abstract>
<t>This RFC reports on the status of most Network Hosts from June 19 to June 30.</t>
</abstract>
</front>

<seriesInfo value="366" name="RFC" />
</reference>


<reference target2="reference.RFC.0367.xml" anchor="RFC0367">
<front>
<title>Network host status</title>
<author fullname="E. Westheimer" initials="E." surname="Westheimer">
<organization />
</author>

<date year="1972" day="19" month="July" />
</front>

<seriesInfo value="367" name="RFC" />
<format octets="8057" type="TXT" target="ftp://ftp.isi.edu/in-notes/rfc367.txt" />
</reference>


<reference target2="reference.RFC.0368.xml" anchor="RFC0368">
<front>
<title>Comments on "Proposed Remote Job Entry Protocol"</title>
<author fullname="Robert T. Braden" initials="R." surname="Braden">
<organization>University of California, Los Angeles (UCLA), Campus Computing Network (CCN)</organization>
</author>

<date year="1972" day="21" month="July" />

<abstract>
<t>Chuck Holland's draft proposal (RFC #360) is an excellent document, very complete and consistent</t>
</abstract>
</front>

<seriesInfo value="368" name="RFC" />
</reference>


<reference target2="reference.RFC.0369.xml" anchor="RFC0369">
<front>
<title>Evaluation of ARPANET services January-March, 1972</title>
<author fullname="J.R. Pickens" initials="J.R." surname="Pickens">
<organization />
</author>

<date year="1972" day="25" month="July" />
</front>

<seriesInfo value="369" name="RFC" />
<format octets="24414" type="TXT" target="ftp://ftp.isi.edu/in-notes/rfc369.txt" />
</reference>


<reference target2="reference.RFC.0370.xml" anchor="RFC0370">
<front>
<title>Network Host Status</title>
<author fullname="Ellen Westheimer" initials="E." surname="Westheimer">
<organization>Bolt Baranek and Newman (BBN)</organization>
</author>

<date year="1972" day="31" month="July" />

<abstract>
<t>This RFC reports on the status of most Network Hosts from July 17 to July 28.</t>
</abstract>
</front>

<seriesInfo value="370" name="RFC" />
</reference>


<reference target2="reference.RFC.0371.xml" anchor="RFC0371">
<front>
<title>Demonstration at International Computer Communications Conference</title>
<author fullname="Robert Kahn" initials="R." surname="Kahn">
<organization>Bolt Baranek and Newman (BBN)</organization>
</author>

<date year="1972" day="12" month="July" />

<abstract>
<t>The International Computer Communications Conference, scheduled for 24-26 October 1972 at the Washington, D.C. Hilton Hotel, is a newly organized conference intended to address a broad set of issues in the Computer Communications field.  Approximately 17 sessions are currently planned for the conference.  The social implications of this field are a matter of widespread interest that reaches society in almost all walks of life; education, medicine, research, business and government.  All these areas will be affected as the field develops.</t>
</abstract>
</front>

<seriesInfo value="371" name="RFC" />
</reference>


<reference target2="reference.RFC.0372.xml" anchor="RFC0372">
<front>
<title>Notes on a Conversation with Bob Kahn on the ICCC</title>
<author fullname="Richard W. Watson" initials="R." surname="Watson">
<organization>Stanford Research Institute (SRI), Augmentation Research Center (ARC)</organization>
</author>

<date year="1972" day="12" month="July" />

<abstract>
<t>I called Bob Kahn and had a good chat with him about some aspects of the ICCC meeting demonstration.</t>
</abstract>
</front>

<seriesInfo value="372" name="RFC" />
</reference>


<reference target2="reference.RFC.0373.xml" anchor="RFC0373">
<front>
<title>Arbitrary Character Sets</title>
<author fullname="John McCarthy" initials="J." surname="McCarthy">
<organization>Stanford University, Artificial Intelligence (AI)</organization>
</author>

<date year="1972" day="14" month="July" />

<abstract>
<t>It would be nice to be able to have documents stored in computers that could include arbitrary characters and to be able to display them on any CRT screen, edit them using any keyboard, and print them on any printer.  The object of this memorandum is to suggest how to get there from here with special reference to the ARPA network.</t>
</abstract>
</front>

<seriesInfo value="373" name="RFC" />
</reference>


<reference target2="reference.RFC.0374.xml" anchor="RFC0374">
<front>
<title>IMP System Announcement</title>
<author fullname="Alex McKenzie" initials="A." surname="McKenzie">
<organization>Bolt Baranek and Newman (BBN)</organization>
</author>

<date year="1972" day="19" month="July" />

<abstract>
<t>There are two significant developments in the operation of the network which should be of interest to all sites:</t>
</abstract>
</front>

<seriesInfo value="374" name="RFC" />
</reference>


<reference target2="reference.RFC.0376.xml" anchor="RFC0376">
<front>
<title>Network Host Status</title>
<author fullname="Ellen Westheimer" initials="E." surname="Westheimer">
<organization>Bolt Baranek and Newman (BBN)</organization>
</author>

<date year="1972" day="8" month="August" />

<abstract>
<t>This RFC reports on the status of most Network Hosts from July 31 to August 4.</t>
</abstract>
</front>

<seriesInfo value="376" name="RFC" />
</reference>


<reference target2="reference.RFC.0377.xml" anchor="RFC0377">
<front>
<title>Using TSO via ARPA Network Virtual Terminal</title>
<author fullname="R.T. Braden" initials="R.T." surname="Braden">
<organization />
</author>

<date year="1972" day="10" month="August" />
</front>

<seriesInfo value="377" name="RFC" />
<format octets="7093" type="TXT" target="ftp://ftp.isi.edu/in-notes/rfc377.txt" />
</reference>


<reference target2="reference.RFC.0378.xml" anchor="RFC0378">
<front>
<title>Traffic statistics (July 1972)</title>
<author fullname="A.M. McKenzie" initials="A.M." surname="McKenzie">
<organization />
</author>

<date year="1972" day="10" month="August" />
</front>

<seriesInfo value="378" name="RFC" />
<format octets="5730" type="TXT" target="ftp://ftp.isi.edu/in-notes/rfc378.txt" />
</reference>


<reference target2="reference.RFC.0379.xml" anchor="RFC0379">
<front>
<title>Using TSO at CCN</title>
<author fullname="Robert T. Braden" initials="R." surname="Braden">
<organization>University of California, Los Angeles (UCLA), Campus Computing Network (CCN)</organization>
</author>

<date year="1972" day="11" month="August" />

<abstract>
<t>IBM's Time Sharing Option ("TSO") is now available at CCN for use via the Network with Telnet Protocol.</t>
</abstract>
</front>

<seriesInfo value="379" name="RFC" />
</reference>


<reference target2="reference.RFC.0381.xml" anchor="RFC0381">
<front>
<title>Three aids to improved network operation</title>
<author fullname="J.M. McQuillan" initials="J.M." surname="McQuillan">
<organization />
</author>

<date year="1972" day="26" month="July" />
</front>

<seriesInfo value="381" name="RFC" />
<format octets="9305" type="TXT" target="ftp://ftp.isi.edu/in-notes/rfc381.txt" />
</reference>


<reference target2="reference.RFC.0382.xml" anchor="RFC0382">
<front>
<title>Mathematical Software on the ARPA Network</title>
<author fullname="Lawrence McDaniel" initials="L." surname="McDaniel">
<organization>University of Illinois, Center for Advanced Computation</organization>
</author>

<date year="1972" day="3" month="August" />

<abstract>
<t>There have been several efforts in the past few years to develop high quality libraries of mathematical and statistical subroutines.  Some of the projects mentioned in the literature include:</t>

<t>1.  The Bell Laboratories numerical mathematics program library project.
				2.  IMSL Inc.:  IMSL Library I, mathematical-statistical computer subroutines
				3.  The NATS (National Science Foundation,Argonne Laboratories, Stanford and Texas) joint project on the Wilkinson linear algebra routines.</t>

<t>The ARPA Network could further enhance the desirability of such libraries as they would become another sharable network resource.  Although the diversity of network computing no doubt requires an equally diverse set of mathematical software, and in spite of the fact everyone has their own software hangups - not to mention hardware!, it seems everyone could benefit from some type of information interchange regarding mathematical software of interest.</t>
</abstract>
</front>

<seriesInfo value="382" name="RFC" />
</reference>


<reference target2="reference.RFC.0384.xml" anchor="RFC0384">
<front>
<title>Official site idents for organizations in the ARPA Network</title>
<author fullname="J.B. North" initials="J.B." surname="North">
<organization />
</author>

<date year="1972" day="28" month="August" />
</front>

<seriesInfo value="384" name="RFC" />
<format octets="10401" type="TXT" target="ftp://ftp.isi.edu/in-notes/rfc384.txt" />
</reference>


<reference target2="reference.RFC.0385.xml" anchor="RFC0385">
<front>
<title>Comments on the File Transfer Protocol</title>
<author fullname="Abhay K. Bhushan" initials="A." surname="Bhushan">
<organization>Massachusetts Institute of Technology (MIT), Project MAC</organization>
</author>

<date year="1972" day="18" month="August" />

<abstract>
<t>The following comments pertain to the File Transfer Protocol, NWG/RFC 354. The comments include errata, further discussion, emphasis points, and additions to the protocol.  I shall incorporate these comments into the main protocol document after we have had sufficient experience.</t>
</abstract>
</front>

<seriesInfo value="385" name="RFC" />
</reference>


<reference target2="reference.RFC.0386.xml" anchor="RFC0386">
<front>
<title>Letter to TIP users-2</title>
<author fullname="Bernard P. Cosell" initials="B." surname="Cosell">
<organization>Bolt Beranek and Newman Inc. (BBN)</organization>
</author>

<author fullname="David C. Walden" initials="D." surname="Walden">
<organization>Bolt Beranek and Newman Inc. (BBN)</organization>
</author>

<date year="1972" day="16" month="August" />

<abstract>
<t>This is the second letter to TIP users.  The first was RFC #365. There will be more letters to TIP users as they seem to us to be a good way to keep you informed about what's going on.  We suggest you keep these letters with your TIP User's Guide (TUG) as we will use the letters to provide documentation of TIP system changes which are made before we can get TUG revisions printed and distributed. (It is almost inevitable that the TUG revisions follow actual system changes. Further more, these letters will allow us more discussion of new commands than in TUG.)</t>
</abstract>
</front>

<seriesInfo value="386" name="RFC" />
</reference>


<reference target2="reference.RFC.0387.xml" anchor="RFC0387">
<front>
<title>Some experiences in implementing Network Graphics Protocol Level 0</title>
<author fullname="K.C. Kelley" initials="K.C." surname="Kelley">
<organization />
</author>

<author fullname="J. Meir" initials="J." surname="Meir">
<organization />
</author>

<date year="1972" day="10" month="August" />
</front>

<seriesInfo value="387" name="RFC" />
<format octets="9059" type="TXT" target="ftp://ftp.isi.edu/in-notes/rfc387.txt" />
</reference>


<reference target2="reference.RFC.0388.xml" anchor="RFC0388">
<front>
<title>NCP statistics</title>
<author fullname="V. Cerf" initials="V." surname="Cerf">
<organization />
</author>

<date year="1972" day="23" month="August" />
</front>

<seriesInfo value="388" name="RFC" />
<format octets="8458" type="TXT" target="ftp://ftp.isi.edu/in-notes/rfc388.txt" />
</reference>


<reference target2="reference.RFC.0389.xml" anchor="RFC0389">
<front>
<title>UCLA Campus Computing Network Liaison Staff for ARPA Network</title>
<author fullname="Barbara Noble" initials="B." surname="Noble">
<organization>University of California, Los Angeles (UCLA), Campus Computing Network (CCN)</organization>

<address>
<phone>+1 213 825 7438</phone>
</address>
</author>

<date year="1972" day="30" month="August" />
</front>

<seriesInfo value="389" name="RFC" />
</reference>


<reference target2="reference.RFC.0390.xml" anchor="RFC0390">
<front>
<title>TSO Scenario</title>
<author fullname="Robert T. Braden" initials="R." surname="Braden">
<organization>University of California, Los Angeles (UCLA), CCM</organization>
</author>

<date year="1972" day="12" month="September" />
</front>

<seriesInfo value="390" name="RFC" />
</reference>


<reference target2="reference.RFC.0391.xml" anchor="RFC0391">
<front>
<title>Traffic statistics (August 1972)</title>
<author fullname="A.M. McKenzie" initials="A.M." surname="McKenzie">
<organization />
</author>

<date year="1972" day="15" month="September" />
</front>

<seriesInfo value="391" name="RFC" />
<format octets="4695" type="TXT" target="ftp://ftp.isi.edu/in-notes/rfc391.txt" />
</reference>


<reference target2="reference.RFC.0392.xml" anchor="RFC0392">
<front>
<title>Measurement of host costs for transmitting network data</title>
<author fullname="G. Hicks" initials="G." surname="Hicks">
<organization />
</author>

<author fullname="B.D. Wessler" initials="B.D." surname="Wessler">
<organization />
</author>

<date year="1972" day="20" month="September" />
</front>

<seriesInfo value="392" name="RFC" />
<format octets="14462" type="TXT" target="ftp://ftp.isi.edu/in-notes/rfc392.txt" />
</reference>


<reference target2="reference.RFC.0393.xml" anchor="RFC0393">
<front>
<title>Comments on Telnet Protocol Changes</title>
<author fullname="Joel M. Winett" initials="J." surname="Winett">
<organization>Massachusetts Institute of Technology (MIT), Lincoln Laboratory (LL)</organization>
</author>

<date year="1972" day="3" month="October" />

<abstract>
<t>Through this RFC, I am registering my objection to two of the three suggestions for changing the TELNET protocol as described in RFC 328 and am adding my suggestion for the interpretation of the TELNET Reverse Break Control Code.</t>
</abstract>
</front>

<seriesInfo value="393" name="RFC" />
</reference>


<reference target2="reference.RFC.0394.xml" anchor="RFC0394">
<front>
<title>Two Proposed Changes to the IMP-Host Protocol</title>
<author fullname="John M. McQuillan" initials="J." surname="McQuillan">
<organization>Bolt Beranek and Newman Inc. (BBN)</organization>
</author>

<date year="1972" day="27" month="September" />

<abstract>
<t>This note describes two changes to the IMP-Host communication protocol described in BBN Report 1822 and revised in RFC 381.  The first deals with the IMP-to-Host interface and the 30-second timeout mechanism on each IMP transmission to the Host.  The second deals with the Host-to-IMP interface and proposes a new timeout mechanism.  These changes are independent; in statement and in implementation.  We invite comments on each proposal.  If no adverse comments are received, they will be installed in the network on Tuesday, October 10 (if serious adverse comments are received, action will be delayed until early November).</t>
</abstract>
</front>

<seriesInfo value="394" name="RFC" />
</reference>


<reference target2="reference.RFC.0395.xml" anchor="RFC0395">
<front>
<title>Switch Settings on IMPs and TIPs</title>
<author fullname="John M. McQuillan" initials="J." surname="McQuillan">
<organization>Bolt Beranek and Newman Inc.(BBN)</organization>
</author>

<date year="1972" day="3" month="October" />

<abstract>
<t>This note provides a description of the switches on the front panel of IMPs and TIPs that are important to the correct operation of the network software.  We have had some difficulty in the past when certain of these switches were set incorrectly, This RFC will be updated as necessary, to notify site personnel of changes to the settings.</t>
</abstract>
</front>

<seriesInfo value="395" name="RFC" />
</reference>


<reference target2="reference.RFC.0396.xml" anchor="RFC0396">
<front>
<title>Network Graphics Working Group Meeting - Second Iteration</title>
<author fullname="Steve Bunch" initials="S." surname="Bunch">
<organization>University of Illinois, Center for Advanced Computation, ANTS</organization>

<address>
<phone>+1 217 333 9354</phone>
</address>
</author>

<date year="1972" day="13" month="November" />

<abstract>
<t>I have obtained some feedback concerning my suggestion in RFC 474 that the Working Group meeting be held here on May 11, 1973.</t>
</abstract>
</front>

<seriesInfo value="396" name="RFC" />
</reference>


<reference target2="reference.RFC.0398.xml" anchor="RFC0398">
<front>
<title>ICP Sockets</title>
<author fullname="John R. Pickens" initials="J." surname="Pickens">
<organization>University of California, Santa Barbara (UCSB)</organization>

<address>
<phone>+1 805 961 3454</phone>
</address>
</author>

<author fullname="Edward D. Faeh" initials="E." surname="Faeh">
<organization>University of California, Santa Barbara (UCSB)</organization>

<address>
<phone>+1 805 961 4047</phone>
</address>
</author>

<date year="1972" day="22" month="September" />

<abstract>
<t>At present, users with TEKTRONIX or IMLAC terminals or with systems that support the proposed level 0 graphics protocol can access UCSB graphics.  Listed below are the ICP sockets for the currently supported terminals and protocols.</t>
</abstract>
</front>

<seriesInfo value="398" name="RFC" />
</reference>


<reference target2="reference.RFC.0399.xml" anchor="RFC0399">
<front>
<title>SMFS Login and Logout</title>
<author fullname="Mark Krilanovich" initials="M." surname="Krilanovich">
<organization>University of California, Santa Barbara (UCSB)</organization>
</author>

<date year="1972" day="26" month="September" />

<abstract>
<t>Two new commands have been added to UCSB's Simple Minded File System (SMFS).</t>
</abstract>
</front>

<seriesInfo value="399" name="RFC" />
</reference>


<reference target2="reference.RFC.0400.xml" anchor="RFC0400">
<front>
<title>Traffic Statistics (September 1972)</title>
<author fullname="A.M. McKenzie" initials="A.M." surname="McKenzie">
<organization />
</author>

<date year="1972" day="18" month="October" />
</front>

<seriesInfo value="400" name="RFC" />
<format octets="5435" type="TXT" target="ftp://ftp.isi.edu/in-notes/rfc400.txt" />
</reference>


<reference target2="reference.RFC.0401.xml" anchor="RFC0401">
<front>
<title>Conversion of NGP-0 Coordinates to Device Specific Coordinates</title>
<author fullname="Jim Hansen" initials="J." surname="Hansen">
<organization>University of Illinois, Center for Advanced Computation</organization>
</author>

<date year="1972" day="23" month="October" />

<abstract>
<t>Conversion of NGP-0 coordinates to floating point PDP-10 coordinates was discussed in RFC #387.  In general, however, it is undesirable to convert NGP coordinates to floating point coordinates because real devices require integer addressing.</t>
</abstract>
</front>

<seriesInfo value="401" name="RFC" />
</reference>


<reference target2="reference.RFC.0402.xml" anchor="RFC0402">
<front>
<title>ARPA Network Mailing Lists</title>
<author fullname="J.B. North" initials="J.B." surname="North">
<organization />
</author>

<date year="1972" day="26" month="October" />
</front>

<seriesInfo value="402" name="RFC" />
<format octets="28162" type="TXT" target="ftp://ftp.isi.edu/in-notes/rfc402.txt" />
</reference>


<reference target2="reference.RFC.0403.xml" anchor="RFC0403">
<front>
<title>Desirability of a network 1108 service</title>
<author fullname="G. Hicks" initials="G." surname="Hicks">
<organization />
</author>

<date year="1973" day="10" month="January" />
</front>

<seriesInfo value="403" name="RFC" />
</reference>


<reference target2="reference.RFC.0404.xml" anchor="RFC0404">
<front>
<title>Host Address Changes Involving Rand and ISI</title>
<author fullname="A.M. McKenzie" initials="A.M." surname="McKenzie">
<organization />
</author>

<date year="1972" day="5" month="October" />

<abstract>
<t>This week the RAND IMP was temporarily removed from the Network and a new IMP was installed at ISI.</t>
</abstract>
</front>

<seriesInfo value="404" name="RFC" />
</reference>


<reference target2="reference.RFC.0405.xml" anchor="RFC0405">
<front>
<title>Correction to RFC 404</title>
<author fullname="A.M. McKenzie" initials="A.M." surname="McKenzie">
<organization />
</author>

<date year="1972" day="10" month="October" />

<abstract>
<t>This is to correct a typographic error in RFC# 404.</t>
</abstract>
</front>

<seriesInfo value="405" name="RFC" />
</reference>


<reference target2="reference.RFC.0406.xml" anchor="RFC0406">
<front>
<title>Scheduled IMP Software Releases</title>
<author fullname="John M. McQuillan" initials="J." surname="McQuillan">
<organization>Bolt Beranek and Newman (BBN)</organization>
</author>

<date year="1972" day="10" month="October" />

<abstract>
<t>This note is a reminder that the procedures suggested in RFC # 381 for scheduling IMP software maintenance have now been in effect for a period of about two months.</t>
</abstract>
</front>

<seriesInfo value="406" name="RFC" />
</reference>


<reference target2="reference.RFC.0407.xml" anchor="RFC0407">
<front>
<title>Remote Job Entry Protocol</title>
<author fullname="Robert Bressler" initials="R." surname="Bressler">
<organization>Massachusetts Institute of Technology (MIT), DMCG</organization>
</author>

<author fullname="Richard Guida" initials="R." surname="Guida">
<organization>Massachusetts Institute of Technology (MIT), DMCG</organization>
</author>

<author fullname="Alex McKenzie" initials="A." surname="McKenzie">
<organization>Bolt Baranek and Newman (BBN), NET</organization>
</author>

<date year="1972" day="16" month="October" />
</front>

<seriesInfo value="407" name="RFC" />
</reference>


<reference target2="reference.RFC.0408.xml" anchor="RFC0408">
<front>
<title>NETBANK</title>
<author fullname="Buzz Owen" initials="B." surname="Owen">
<organization />
</author>

<author fullname="Jon Postel" initials="J." surname="Postel">
<organization>University of California, Los Angeles (UCLA)</organization>
</author>

<date year="1972" day="25" month="October" />

<abstract>
<t>The following idea for a protocol (or service) is offered as an aid to network use for new users:</t>

<t>a single billing and account creation and validation system, so that a manager of a "goal oriented project" could:</t>

<t>authorize a set of user's ids to gain access to and utilize resources at the entire or a specified subset of the server hosts.</t>

<t>create a set of accounts which the users will expend, and which will be used as the breakdown for a single bill to be presented to the project manager.</t>
</abstract>
</front>

<seriesInfo value="408" name="RFC" />
</reference>


<reference target2="reference.RFC.0409.xml" anchor="RFC0409">
<front>
<title>Tenex interface to UCSB's Simple-Minded File System</title>
<author fullname="J.E. White" initials="J.E." surname="White">
<organization />
</author>

<date year="1972" day="8" month="December" />
</front>

<seriesInfo value="409" name="RFC" />
<format octets="14231" type="TXT" target="ftp://ftp.isi.edu/in-notes/rfc409.txt" />
</reference>


<reference target2="reference.RFC.0410.xml" anchor="RFC0410">
<front>
<title>Removal of the 30-Second Delay When Hosts Come Up</title>
<author fullname="John M. McQuillan" initials="J." surname="McQuillan">
<organization>Bolt Beranek and Newman (BBN)</organization>
</author>

<date year="1972" day="10" month="November" />

<abstract>
<t>The IMP currently delays accepting input from a Host for 30 seconds after the Host has come up.  This delay serves to allow the fact that the Host is up to propagate through the network.</t>
</abstract>
</front>

<seriesInfo value="410" name="RFC" />
</reference>


<reference target2="reference.RFC.0411.xml" anchor="RFC0411">
<front>
<title>New MULTICS Network Software Features</title>
<author fullname="M. A. Padlipsky" initials="M." surname="Padlipsky">
<organization>Massachusetts Institute of Technology (MIT), MULTICS</organization>
</author>

<date year="1972" day="14" month="November" />

<abstract>
<t>Two recently-installed features of the Multics  Network  software might be of general interest to the Network community, and should be of particular interest to those who use Multics via TIP's:</t>
</abstract>
</front>

<seriesInfo value="411" name="RFC" />
</reference>


<reference target2="reference.RFC.0412.xml" anchor="RFC0412">
<front>
<title>User FTP Documentation</title>
<author fullname="G. Hicks" initials="G." surname="Hicks">
<organization />
</author>

<date year="1972" day="27" month="November" />

<abstract>
<t>The attached document is the HELP file for the Utah-10 implementation of the User FTP Process. This is what the user has typed on his console when he types 'HELP cr' and as such is the only documention produced to date.</t>
</abstract>
</front>

<seriesInfo value="412" name="RFC" />
</reference>


<reference target2="reference.RFC.0413.xml" anchor="RFC0413">
<front>
<title>Traffic statistics (October 1972)</title>
<author fullname="A.M. McKenzie" initials="A.M." surname="McKenzie">
<organization />
</author>

<date year="1972" day="13" month="November" />
</front>

<seriesInfo value="413" name="RFC" />
<format octets="16145" type="TXT" target="ftp://ftp.isi.edu/in-notes/rfc413.txt" />
</reference>


<reference target2="reference.RFC.0414.xml" anchor="RFC0414">
<front>
<title>File Transfer Protocol (FTP) status and further comments</title>
<author fullname="A.K. Bhushan" initials="A.K." surname="Bhushan">
<organization />
</author>

<date year="1972" day="29" month="December" />
</front>

<seriesInfo value="414" name="RFC" />
<format octets="12845" type="TXT" target="ftp://ftp.isi.edu/in-notes/rfc414.txt" />
</reference>


<reference target2="reference.RFC.0415.xml" anchor="RFC0415">
<front>
<title>Tenex bandwidth</title>
<author fullname="H. Murray" initials="H." surname="Murray">
<organization />
</author>

<date year="1972" day="29" month="November" />
</front>

<seriesInfo value="415" name="RFC" />
<format octets="3456" type="TXT" target="ftp://ftp.isi.edu/in-notes/rfc415.txt" />
</reference>


<reference target2="reference.RFC.0416.xml" anchor="RFC0416">
<front>
<title>ARC System Will Be Unavailable for Use During Thanksgiving Week</title>
<author fullname="James C. Norton" initials="J." surname="Norton">
<organization>Stanford Research Institute (SRI) International,  Augmentation Research Center (ARC)</organization>
</author>

<date year="1972" day="7" month="November" />

<abstract>
<t>The ARC PDP-10 system will be unavailable for ARC and NIC users from Friday, November 17 (6:00 pm PST ) through Sunday, November 26. (10:00 pm PST).</t>
</abstract>
</front>

<seriesInfo value="416" name="RFC" />
</reference>


<reference target2="reference.RFC.0417.xml" anchor="RFC0417">
<front>
<title>Link usage violation</title>
<author fullname="J. Postel" initials="J." surname="Postel">
<organization />
</author>

<author fullname="C. Kline" initials="C." surname="Kline">
<organization />
</author>

<date year="1972" day="6" month="December" />
</front>

<seriesInfo value="417" name="RFC" />
<format octets="901" type="TXT" target="ftp://ftp.isi.edu/in-notes/rfc417.txt" />
</reference>


<reference target2="reference.RFC.0418.xml" anchor="RFC0418">
<front>
<title>Server file transfer under TSS/360 at NASA Ames</title>
<author fullname="W. Hathaway" initials="W." surname="Hathaway">
<organization />
</author>

<date year="1972" day="27" month="November" />
</front>

<seriesInfo value="418" name="RFC" />
</reference>


<reference target2="reference.RFC.0419.xml" anchor="RFC0419">
<front>
<title>To: Network liaisons and station agents</title>
<author fullname="A. Vezza" initials="A." surname="Vezza">
<organization />
</author>

<date year="1972" day="12" month="December" />
</front>

<seriesInfo value="419" name="RFC" />
<format octets="1252" type="TXT" target="ftp://ftp.isi.edu/in-notes/rfc419.txt" />
</reference>


<reference target2="reference.RFC.0420.xml" anchor="RFC0420">
<front>
<title>CCA ICCC weather demo</title>
<author fullname="H. Murray" initials="H." surname="Murray">
<organization />
</author>

<date year="1973" day="4" month="January" />
</front>

<seriesInfo value="420" name="RFC" />
<format octets="14752" type="TXT" target="ftp://ftp.isi.edu/in-notes/rfc420.txt" />
</reference>


<reference target2="reference.RFC.0421.xml" anchor="RFC0421">
<front>
<title>Software Consulting Service for Network Users</title>
<author fullname="Alexander McKenzie" initials="A." surname="McKenzie">
<organization>Bolt Baranek and Newman (BBN)</organization>
</author>

<date year="1972" day="27" month="November" />

<abstract>
<t>As actual or attempted Network use has grown, it has become increasingly apparent that users with real problems to solve are not afforded the kinds of software assistance and consulting services normally provided by computer service facilities.</t>
</abstract>
</front>

<seriesInfo value="421" name="RFC" />
</reference>


<reference target2="reference.RFC.0422.xml" anchor="RFC0422">
<front>
<title>Traffic statistics (November 1972)</title>
<author fullname="A.M. McKenzie" initials="A.M." surname="McKenzie">
<organization />
</author>

<date year="1972" day="11" month="December" />
</front>

<seriesInfo value="422" name="RFC" />
<format octets="5494" type="TXT" target="ftp://ftp.isi.edu/in-notes/rfc422.txt" />
</reference>


<reference target2="reference.RFC.0423.xml" anchor="RFC0423">
<front>
<title>UCLA Campus Computing Network Liaison Staff for ARPANET</title>
<author fullname="Barbara B. Noble" initials="B." surname="Noble">
<organization>University of California, Los Angeles (UCLA), Campus Computing Network (CCN)</organization>

<address>
<phone>+1 213 825 7438</phone>
</address>
</author>

<date year="1972" day="12" month="December" />
</front>

<seriesInfo value="423" name="RFC" />
</reference>


<reference target2="reference.RFC.0425.xml" anchor="RFC0425">
<front>
<title>"But my NCP costs $500 a day"</title>
<author fullname="Bob Bressler" initials="B." surname="Bressler">
<organization>Bolt Baranek and Newman (BBN)</organization>
</author>

<date year="1972" day="19" month="December" />

<abstract>
<t>Now that networking is becoming commonplace, people are beginning to measure the cost of their network software and network use.</t>
</abstract>
</front>

<seriesInfo value="425" name="RFC" />
</reference>


<reference target2="reference.RFC.0426.xml" anchor="RFC0426">
<front>
<title>Reconnection Protocol</title>
<author fullname="R. Thomas" initials="R." surname="Thomas">
<organization />
</author>

<date year="1973" day="26" month="January" />
</front>

<seriesInfo value="426" name="RFC" />
<format octets="26548" type="TXT" target="ftp://ftp.isi.edu/in-notes/rfc426.txt" />
</reference>


<reference target2="reference.RFC.0429.xml" anchor="RFC0429">
<front>
<title>Character Generator Process</title>
<author fullname="Jonathan B. Postel" initials="J." surname="Postel">
<organization>Stanford Research Institute (SRI), ARPA Network Information Center</organization>
</author>

<date year="1972" day="12" month="December" />

<abstract>
<t>I hereby propose that there be a standard process implemented on whatever hosts desire which generates character data with out any regard to input. In some sense the process is the converse of the discard process. Many hosts have an existing terminal testing program [e.g. TTYTST] which would suit this function adequately.</t>

<t>This Character Generator process would listen for a request for connection and execute the Initial Connection Protocol (ICP) as specified in NIC 7104 the "Current Network Protocols" notebook.  Upon completion of the ICP the Character Generator process would begin to send characters into the network as buffer space is made available. The Character Generator process is terminated by closing the connections.</t>
</abstract>
</front>

<seriesInfo value="429" name="RFC" />
</reference>


<reference target2="reference.RFC.0430.xml" anchor="RFC0430">
<front>
<title>Comments on File Transfer Protocol</title>
<author fullname="R.T. Braden" initials="R.T." surname="Braden">
<organization />
</author>

<date year="1973" day="7" month="February" />
</front>

<seriesInfo value="430" name="RFC" />
<format octets="18696" type="TXT" target="ftp://ftp.isi.edu/in-notes/rfc430.txt" />
</reference>


<reference target2="reference.RFC.0431.xml" anchor="RFC0431">
<front>
<title>Update on SMFS Login and Logout</title>
<author fullname="Mark Krilanovich" initials="M." surname="Krilanovich">
<organization>University of California, Santa Barbara (UCSB)</organization>
</author>

<date year="1972" day="15" month="December" />

<abstract>
<t>This document replaces RFC 399, which introduced the Login and Logout commands for UCSB's SMFS, but was incomplete.  RFC 399 is restated here, followed by a description of the nature of the response elicted by these commands</t>
</abstract>
</front>

<seriesInfo value="431" name="RFC" />
</reference>


<reference target2="reference.RFC.0432.xml" anchor="RFC0432">
<front>
<title>Network logical map</title>
<author fullname="N. Neigus" initials="N." surname="Neigus">
<organization />
</author>

<date year="1972" day="29" month="December" />
</front>

<seriesInfo value="432" name="RFC" />
<format octets="1291" type="TXT" target="ftp://ftp.isi.edu/in-notes/rfc432.txt" />
<format octets="148880" type="PDF" target="ftp://ftp.isi.edu/in-notes/rfc432.pdf" />
<format octets="1344571" type="PS" target="ftp://ftp.isi.edu/in-notes/rfc432.ps" />
</reference>


<reference target2="reference.RFC.0433.xml" anchor="RFC0433">
<front>
<title>Socket number list</title>
<author fullname="Jon Postel" initials="J." surname="Postel">
<organization>University of California, Los Angeles (UCLA), Computer Science Department, NMC</organization>

<address>
<postal>
<street>3804 Boelter Hall</street>
<city>Los Angeles</city>
<region>CA</region>
<code>90024</code>
<country>US</country>
</postal>

<phone>+1 213 825 2368</phone>
</address>
</author>

<author fullname="Nancy Neigus" initials="N." surname="Neigus">
<organization>Bolt Baranek and Newman (BBN)</organization>

<address>
<postal>
<street>50 Moulton Street</street>
<city>Cambridge</city>
<region>MA</region>
<code>02139</code>
<country>US</country>
</postal>

<phone>+1 617 661 0100</phone>
</address>
</author>

<date year="1972" day="22" month="December" />

<abstract>
<t>The czar of socket numbers [Jon Postel] has established the following assignments for socket numbers used for public functions. Note that a socket number is a 40 bit quantity, the first 8 bits being the host specification, the next 24 bits being site specific, and the last 8 bits being user specified - these last 8 bits are called the AEN [it stands for, cleverly enough, Another Eightbit Number].</t>
</abstract>
</front>

<seriesInfo value="433" name="RFC" />
</reference>


<reference target2="reference.RFC.0434.xml" anchor="RFC0434">
<front>
<title>IMP/TIP memory retrofit schedule</title>
<author fullname="A.M. McKenzie" initials="A.M." surname="McKenzie">
<organization />
</author>

<date year="1973" day="4" month="January" />
</front>

<seriesInfo value="434" name="RFC" />
<format octets="2242" type="TXT" target="ftp://ftp.isi.edu/in-notes/rfc434.txt" />
</reference>


<reference target2="reference.RFC.0435.xml" anchor="RFC0435">
<front>
<title>Telnet issues</title>
<author fullname="B. Cosell" initials="B." surname="Cosell">
<organization />
</author>

<author fullname="D.C. Walden" initials="D.C." surname="Walden">
<organization />
</author>

<date year="1973" day="5" month="January" />
</front>

<seriesInfo value="435" name="RFC" />
<format octets="23019" type="TXT" target="ftp://ftp.isi.edu/in-notes/rfc435.txt" />
</reference>


<reference target2="reference.RFC.0436.xml" anchor="RFC0436">
<front>
<title>Announcement of RJS at UCSB</title>
<author fullname="M. Krilanovich" initials="M." surname="Krilanovich">
<organization />
</author>

<date year="1973" day="10" month="January" />
</front>

<seriesInfo value="436" name="RFC" />
<format octets="2579" type="TXT" target="ftp://ftp.isi.edu/in-notes/rfc436.txt" />
</reference>


<reference target2="reference.RFC.0437.xml" anchor="RFC0437">
<front>
<title>Data Reconfiguration Service at UCSB</title>
<author fullname="E. Faeh" initials="E." surname="Faeh">
<organization />
</author>

<date year="1973" day="30" month="June" />
</front>

<seriesInfo value="437" name="RFC" />
<format octets="21562" type="TXT" target="ftp://ftp.isi.edu/in-notes/rfc437.txt" />
</reference>


<reference target2="reference.RFC.0438.xml" anchor="RFC0438">
<front>
<title>FTP server-server interaction</title>
<author fullname="R. Thomas" initials="R." surname="Thomas">
<organization />
</author>

<author fullname="R. Clements" initials="R." surname="Clements">
<organization />
</author>

<date year="1973" day="15" month="January" />
</front>

<seriesInfo value="438" name="RFC" />
<format octets="6514" type="TXT" target="ftp://ftp.isi.edu/in-notes/rfc438.txt" />
</reference>


<reference target2="reference.RFC.0439.xml" anchor="RFC0439">
<front>
<title>PARRY encounters the DOCTOR</title>
<author fullname="V. Cerf" initials="V." surname="Cerf">
<organization />
</author>

<date year="1973" day="21" month="January" />
</front>

<seriesInfo value="439" name="RFC" />
<format octets="7066" type="TXT" target="ftp://ftp.isi.edu/in-notes/rfc439.txt" />
</reference>


<reference target2="reference.RFC.0440.xml" anchor="RFC0440">
<front>
<title>Scheduled network software maintenance</title>
<author fullname="David C. Walden" initials="D." surname="Walden">
<organization>Bolt Baranek and Newman (BBN), NET</organization>
</author>

<date year="1973" day="1" month="January" />

<abstract>
<t>As explained in RFC 381, we believe that we can minimize the disruption caused by the release of new IMP software systems by doing them on a regularly scheduled basis.</t>
</abstract>
</front>

<seriesInfo value="440" name="RFC" />
</reference>


<reference target2="reference.RFC.0441.xml" anchor="RFC0441">
<front>
<title abbrev="Inter-Entity Communication">Inter-Entity Communication - an experiment</title>
<author fullname="Bob Bressler" initials="B." surname="Bressler">
<organization />
</author>

<author fullname="Bob Thomas" initials="B." surname="Thomas">
<organization />
</author>

<date year="1973" day="19" month="January" />

<abstract>
<t>This note is an attempt to be a status report concerning an experiment based on the desire of users, at their consoles, to converse with one another, and perhaps to get some debugging assistance.</t>
</abstract>
</front>

<seriesInfo value="441" name="RFC" />
</reference>


<reference target2="reference.RFC.0442.xml" anchor="RFC0442">
<front>
<title>Current flow-control scheme for IMPSYS</title>
<author fullname="V. Cerf" initials="V." surname="Cerf">
<organization />
</author>

<date year="1973" day="24" month="January" />
</front>

<seriesInfo value="442" name="RFC" />
<format octets="16315" type="TXT" target="ftp://ftp.isi.edu/in-notes/rfc442.txt" />
</reference>


<reference target2="reference.RFC.0443.xml" anchor="RFC0443">
<front>
<title>Traffic statistics (December 1972)</title>
<author fullname="A.M. McKenzie" initials="A.M." surname="McKenzie">
<organization />
</author>

<date year="1973" day="18" month="January" />
</front>

<seriesInfo value="443" name="RFC" />
<format octets="5664" type="TXT" target="ftp://ftp.isi.edu/in-notes/rfc443.txt" />
</reference>


<reference target2="reference.RFC.0445.xml" anchor="RFC0445">
<front>
<title>IMP/TIP preventive maintenance schedule</title>
<author fullname="Alexander A. McKenzie" initials="A." surname="McKenzie">
<organization>Bolt Baranek and Newman (BBN), NET</organization>
</author>

<date year="1973" day="22" month="January" />

<abstract>
<t>This note presents the current IMP/TIP Preventive Maintenance schedule. Preventive Maintenance is scheduled on a monthly basis, and a given machine is normally scheduled at the same time each month; wherever possible the time is chosen to coincide with the PM time for the Host(s) at the site.</t>
</abstract>
</front>

<seriesInfo value="445" name="RFC" />
</reference>


<reference target2="reference.RFC.0446.xml" anchor="RFC0446">
<front>
<title abbrev="Network Program Resource Notebook">Proposal to consider a network program resource notebook</title>
<author fullname="L. Peter Deutsch" initials="L." surname="Deutsch">
<organization>Stanford Research Institute (SRI)</organization>
</author>

<date year="1973" day="25" month="January" />

<abstract>
<t>Since the exchange of knowledge and techniques (not to mention programs) is a central motivating factor in the development of the ARPANET, it seems only reasonable that we begin to systematize the process now that someone (MITRE and the government agencies on whose behalf it is acting) feels there is enough information to be worth collecting.</t>

<t>Obviously, the network community should be in a position to profit from such compilation at least as much as outside agencies.</t>
</abstract>
</front>

<seriesInfo value="446" name="RFC" />
</reference>


<reference target2="reference.RFC.0447.xml" anchor="RFC0447">
<front>
<title abbrev="IMP/TIP Memory Retrofit Schedule (Rev 1)">IMP/TIP memory retrofit schedule</title>
<author fullname="Alex A. McKenzie" initials="A." surname="McKenzie">
<organization>Bolt Baranek and Newman (BBN), NET</organization>
</author>

<date year="1973" day="29" month="January" />

<abstract>
<t>This revision contains two major changes to RFC #434.</t>
</abstract>
</front>

<seriesInfo value="447" name="RFC" />
</reference>


<reference target2="reference.RFC.0448.xml" anchor="RFC0448">
<front>
<title>Print files in FTP</title>
<author fullname="R.T. Braden" initials="R." surname="Braden">
<organization>University of California, Los Angeles (UCLA), CCN</organization>
</author>

<date year="1973" day="27" month="February" />
</front>

<seriesInfo value="448" name="RFC" />
</reference>


<reference target2="reference.RFC.0449.xml" anchor="RFC0449">
<front>
<title>Current flow-control scheme for IMPSYS</title>
<author fullname="Dave Walden" initials="D." surname="Walden">
<organization>Bolt Baranek and Newman (BBN), NET</organization>
</author>

<date year="1973" day="6" month="January" />

<abstract>
<t>While Vint's notes on IMPSYS flow-control from the March 16, 1972, meeting (RFC 442) seem reasonably accurate and while he does cite our Quarterly Technical Report #13, he might have done better to cite BBN's two formal publications relevant to the IMPSYS flow-control scheme:</t>
</abstract>
</front>

<seriesInfo value="449" name="RFC" />
</reference>


<reference target2="reference.RFC.0450.xml" anchor="RFC0450">
<front>
<title>MULTICS sampling timeout change</title>
<author fullname="Mike Padlipsky" initials="M." surname="Padlipsky">
<organization>Massachusetts Institute of Technology (MIT), Multics</organization>
</author>

<date year="1973" day="8" month="February" />

<abstract>
<t>In response to popular demand, and in view of the fact that we've found an extra bit of budget, the timeout on sampling ("anonymous") use of Multics via the Net has been increased to 5 cpu minutes (from 1 cpu minute); coupled with various internal speedups, this change should allow the performance of substantive experiments in a single session.</t>
</abstract>
</front>

<seriesInfo value="450" name="RFC" />
</reference>


<reference target2="reference.RFC.0451.xml" anchor="RFC0451">
<front>
<title abbrev="Unified User Level Protocol Proposal">Tentative proposal for a Unified User Level Protocol</title>
<author fullname="Mike A. Padlipsky" initials="M." surname="Padlipsky">
<organization>Massachusetts Institute of Technology (MIT), Multics</organization>
</author>

<date year="1973" day="22" month="February" />

<abstract>
<t>Now that proposals for expansions to the Telnet Protocol are in vogue again (RFC's 426 and 435, for example), I'd like to promote some discussion of a particular favorite of my own.  Please note that this is presented as a tentative proposal: it's an attempt to consider the desirability of a new approach, not a rigorous specification.</t>
</abstract>
</front>

<seriesInfo value="451" name="RFC" />
</reference>


<reference target2="reference.RFC.0452.xml" anchor="RFC0452">
<front>
<title>TELENET Command at Host LL</title>
<author fullname="J. Winett" initials="J." surname="Winett">
<organization />
</author>

<date year="1973" day="8" month="February" />
</front>

<seriesInfo value="452" name="RFC" />
</reference>


<reference target2="reference.RFC.0453.xml" anchor="RFC0453">
<front>
<title abbrev="Meeting to Discuss a Network Mail System">Meeting announcement to discuss a network mail system</title>
<author fullname="Michael D. Kudlick" initials="M." surname="Kudlick">
<organization>Stanford Research Institute (SRI) International,  Augmentation Research Center (ARC)</organization>
</author>

<date year="1973" day="7" month="February" />

<abstract>
<t>The purpose of this RFC is to announce a meeting at SRI-ARC on the Network Mail problem discussed at the January 1973 Principal Investigators' Meeting in San Diego.</t>
</abstract>
</front>

<seriesInfo value="453" name="RFC" />
</reference>


<reference target2="reference.RFC.0454.xml" anchor="RFC0454">
<front>
<title>File Transfer Protocol - meeting announcement and a new proposed document</title>
<author fullname="A.M. McKenzie" initials="A.M." surname="McKenzie">
<organization />
</author>

<date year="1973" day="16" month="February" />
</front>

<seriesInfo value="454" name="RFC" />
<format octets="78966" type="TXT" target="ftp://ftp.isi.edu/in-notes/rfc454.txt" />
</reference>


<reference target2="reference.RFC.0455.xml" anchor="RFC0455">
<front>
<title>Traffic statistics (January 1973)</title>
<author fullname="A.M. McKenzie" initials="A.M." surname="McKenzie">
<organization />
</author>

<date year="1973" day="12" month="February" />
</front>

<seriesInfo value="455" name="RFC" />
<format octets="5746" type="TXT" target="ftp://ftp.isi.edu/in-notes/rfc455.txt" />
</reference>


<reference target2="reference.RFC.0456.xml" anchor="RFC0456">
<front>
<title>Memorandum: Date change of mail meeting</title>
<author fullname="M. D. Kudlick" initials="M." surname="Kudlick">
<organization>Stanford Research Institute (SRI) International,  Augmentation Research Center (ARC)</organization>
</author>

<date year="1973" day="13" month="February" />

<abstract>
<t>This RFC announces a slight change in the meeting time for the Network Mail meeting discussed in RFC #453.</t>
</abstract>
</front>

<seriesInfo value="456" name="RFC" />
</reference>


<reference target2="reference.RFC.0457.xml" anchor="RFC0457">
<front>
<title>TIPUG</title>
<author fullname="Dave Walden" initials="D." surname="Walden">
<organization>Bolt Baranek and Newman (BBN), NET</organization>
</author>

<date year="1973" day="15" month="February" />

<abstract>
<t>To any TIP users who have not been receiving updates to their TIP User's Guide or who have not been receiving copies of TIP User's Group Notes: please send me your name (along with the TIP and Host you normally use) and I'll make sure you get on a distribution list for these materials.</t>
</abstract>
</front>

<seriesInfo value="457" name="RFC" />
</reference>


<reference target2="reference.RFC.0458.xml" anchor="RFC0458">
<front>
<title>Mail retrieval via FTP</title>
<author fullname="R.D. Bressler" initials="R.D." surname="Bressler">
<organization />
</author>

<author fullname="R. Thomas" initials="R." surname="Thomas">
<organization />
</author>

<date year="1973" day="20" month="February" />
</front>

<seriesInfo value="458" name="RFC" />
<format octets="2705" type="TXT" target="ftp://ftp.isi.edu/in-notes/rfc458.txt" />
</reference>


<reference target2="reference.RFC.0459.xml" anchor="RFC0459">
<front>
<title>Network questionnaires</title>
<author fullname="W. Kantrowitz" initials="W." surname="Kantrowitz">
<organization />
</author>

<date year="1973" day="26" month="February" />

<abstract>
<t>In recent times, a steady stream of questionnaires has been arriving from the network community.</t>
</abstract>
</front>

<seriesInfo value="459" name="RFC" />
</reference>


<reference target2="reference.RFC.0460.xml" anchor="RFC0460">
<front>
<title>NCP survey</title>
<author fullname="C. Kline" initials="C." surname="Kline">
<organization />
</author>

<date year="1973" day="13" month="February" />
</front>

<seriesInfo value="460" name="RFC" />
<format octets="10324" type="TXT" target="ftp://ftp.isi.edu/in-notes/rfc460.txt" />
</reference>


<reference target2="reference.RFC.0461.xml" anchor="RFC0461">
<front>
<title>Telnet Protocol meeting announcement</title>
<author fullname="A. McKenzie" initials="A." surname="McKenzie">
<organization>Bolt Baranek and Newman (BBN), NET</organization>

<address>
<postal>
<street>50 Moulton Street</street>
<city>Cambridge</city>
<region>MA</region>
<code>02l38</code>
<country>US</country>
</postal>

<phone>+1 617 491 1850 x441</phone>
</address>
</author>

<date year="1973" day="14" month="February" />

<abstract>
<t>Since the publication of RFC #318 there have been a great number of proposals for changes and/or extensions to the (still unofficial) TELNET Protocol. It now seems appropriate to have a meeting of concerned parties to try, once again, to reach a consensus position and define an "official" protocol (with perhaps, some room for optional expansion).</t>
</abstract>
</front>

<seriesInfo value="461" name="RFC" />
</reference>


<reference target2="reference.RFC.0462.xml" anchor="RFC0462">
<front>
<title>Responding to user needs</title>
<author fullname="Jean Iseli" initials="J." surname="Iseli">
<organization>The Mitre Corporation</organization>
</author>

<author fullname="Dave Crocker" initials="D." surname="Crocker">
<organization>University of California, Los Angeles (UCLA), NMC</organization>
</author>

<date year="1973" day="22" month="February" />
</front>

<seriesInfo value="462" name="RFC" />
</reference>


<reference target2="reference.RFC.0463.xml" anchor="RFC0463">
<front>
<title>FTP comments and response to RFC 430</title>
<author fullname="Abhay K. Bhushan" initials="A." surname="Bhushan">
<organization>Massachusetts Institute of Technology (MIT), DMCG</organization>
</author>

<date year="1973" day="21" month="February" />

<abstract>
<t>Most of the comments in RFC 430 by Bob Braden are useful suggestions which should be included in the forthcoming official FTP specification. This RFC represents my response to Braden's comments and other views.</t>
</abstract>
</front>

<seriesInfo value="463" name="RFC" />
</reference>


<reference target2="reference.RFC.0464.xml" anchor="RFC0464">
<front>
<title>Resource notebook framework</title>
<author fullname="Michael D. Kudlick" initials="M." surname="Kudlick">
<organization>Stanford Research Institute (SRI) International,  Augmentation Research Center (ARC)</organization>
</author>

<date year="1973" day="27" month="February" />

<abstract>
<t>The purpose of this RFC is to present a framework for coordinating all the surveys and data gathering efforts concerned with "resource notebook" type of information.</t>
</abstract>
</front>

<seriesInfo value="464" name="RFC" />
</reference>


<reference target2="reference.RFC.0466.xml" anchor="RFC0466">
<front>
<title>Telnet logger/server for host LL-67</title>
<author fullname="J.M. Winett" initials="J.M." surname="Winett">
<organization />
</author>

<date year="1973" day="27" month="February" />
</front>

<seriesInfo value="466" name="RFC" />
<format octets="17595" type="TXT" target="ftp://ftp.isi.edu/in-notes/rfc466.txt" />
</reference>


<reference target2="reference.RFC.0467.xml" anchor="RFC0467">
<front>
<title>Proposed change to Host-Host Protocol: Resynchronization of connection status</title>
<author fullname="J.D. Burchfiel" initials="J.D." surname="Burchfiel">
<organization />
</author>

<author fullname="R.S. Tomlinson" initials="R.S." surname="Tomlinson">
<organization />
</author>

<date year="1973" day="20" month="February" />
</front>

<seriesInfo value="467" name="RFC" />
<format octets="14325" type="TXT" target="ftp://ftp.isi.edu/in-notes/rfc467.txt" />
</reference>


<reference target2="reference.RFC.0468.xml" anchor="RFC0468">
<front>
<title>FTP data compression</title>
<author fullname="R.  Braden" initials="R." surname="Braden">
<organization>University of California, Los Angeles (UCLA), CCN</organization>
</author>

<date year="1973" day="8" month="March" />
</front>

<seriesInfo value="468" name="RFC" />
</reference>


<reference target2="reference.RFC.0469.xml" anchor="RFC0469">
<front>
<title>Network mail meeting summary</title>
<author fullname="Michael D. Kudlick" initials="M." surname="Kudlick">
<organization>Stanford Research Institute (SRI) International,  Augmentation Research Center (ARC)</organization>
</author>

<date year="1973" day="8" month="March" />
</front>

<seriesInfo value="469" name="RFC" />
</reference>


<reference target2="reference.RFC.0470.xml" anchor="RFC0470">
<front>
<title>Change in socket for TIP news facility</title>
<author fullname="Bob Thomas" initials="B." surname="Thomas">
<organization>Bolt Baranek and Newman (BBN), TENEX</organization>
</author>

<date year="1973" day="13" month="March" />

<abstract>
<t>The Socket which supports the TIP News Facility has been changed to socket 367 (Octal) at BBN-TENEX..</t>
</abstract>
</front>

<seriesInfo value="470" name="RFC" />
</reference>


<reference target2="reference.RFC.0471.xml" anchor="RFC0471">
<front>
<title abbrev="Workshop On Multi Site Executive Programs">Workshop on multi-site executive programs</title>
<author fullname="Bob Thomas" initials="B." surname="Thomas">
<organization>Bolt Beranek and Newman, Inc. (BBN), TENEX</organization>

<address>
<postal>
<street>50 Moulton Street</street>
<city>Cambridge</city>
<region>MA</region>
<code>02139</code>
<country>US</country>
</postal>

<phone>+1 617 491 1850 x483</phone>
<email>BTHOMAS@BBN-TENEX</email>
</address>
</author>

<date year="1973" day="13" month="March" />

<abstract>
<t>An executive program is one which accepts and interprets commands from a user, calling upon other programs to provide the resources required to satisfy each command. There is currently interest in making resources on the ARPANET available to the user via a standard, conversational facility which one might call an ARPANET Executive.</t>
</abstract>
</front>

<seriesInfo value="471" name="RFC" />
</reference>


<reference target2="reference.RFC.0472.xml" anchor="RFC0472">
<front>
<title abbrev="Reply to Request for Graphics Information">Illinois' reply to Maxwell's request for graphics information (NIC 14925)</title>
<author fullname="Steve Bunch" initials="S." surname="Bunch">
<organization>University of Illinois, Center for Advanced Computation, ANTS</organization>
</author>

<date year="1973" day="1" month="March" />

<abstract>
<t>This is a reply to Craig Maxwell's (UCLA-NMC) "Request for graphics information" of 3/7/73.</t>
</abstract>
</front>

<seriesInfo value="472" name="RFC" />
</reference>


<reference target2="reference.RFC.0473.xml" anchor="RFC0473">
<front>
<title>MIX and MIXAL?</title>
<author fullname="D.C. Walden" initials="D.C." surname="Walden">
<organization />
</author>

<date year="1973" day="28" month="February" />
</front>

<seriesInfo value="473" name="RFC" />
<format octets="868" type="TXT" target="ftp://ftp.isi.edu/in-notes/rfc473.txt" />
</reference>


<reference target2="reference.RFC.0474.xml" anchor="RFC0474">
<front>
<title>Announcement of NGWG meeting: Call for papers</title>
<author fullname="Steve Bunch" initials="S." surname="Bunch">
<organization>University of Illinois, Center for Advanced Computation, ANTS</organization>

<address>
<postal>
<street />
<city>Urbana</city>
<region>IL</region>
<code>61801</code>
<country>US</country>
</postal>

<phone>+1 217 333 9354</phone>
<email>BUNCH@USC-ISI</email>
</address>
</author>

<date year="1973" day="1" month="March" />

<abstract>
<t>Ira Cotton (NBS) has proposed that Illinois host the next NGWG meeting and that it be held in early May.</t>
</abstract>
</front>

<seriesInfo value="474" name="RFC" />
</reference>


<reference target2="reference.RFC.0475.xml" anchor="RFC0475">
<front>
<title>FTP and network mail system</title>
<author fullname="A.K. Bhushan" initials="A.K." surname="Bhushan">
<organization />
</author>

<date year="1973" day="6" month="March" />
</front>

<seriesInfo value="475" name="RFC" />
</reference>


<reference target2="reference.RFC.0476.xml" anchor="RFC0476">
<front>
<title abbrev="IMP/TIP Memory Retrofit Schedule (Rev 2)">IMP/TIP memory retrofit schedule (rev 2)</title>
<author fullname="Alexander McKenzie" initials="A." surname="McKenzie">
<organization>Bolt Baranek and Newman (BBN), NET</organization>
</author>

<date year="1973" day="7" month="March" />

<abstract>
<t>This revision contains two types of changes to RFC #447.  First, the retrofits to Utah, Belvoir, NOAA, USC, Stanford, ISI, Case, and CCA have been completed and are therefore removed from the schedule.  Second, the retrofits to UCSB, ETAC, Aberdeen, and Rome have been rescheduled.</t>
</abstract>
</front>

<seriesInfo value="476" name="RFC" />
</reference>


<reference target2="reference.RFC.0477.xml" anchor="RFC0477">
<front>
<title>Remote Job Service at UCSB</title>
<author fullname="M. Krilanovich" initials="M." surname="Krilanovich">
<organization />
</author>

<date year="1973" day="23" month="May" />
</front>

<seriesInfo value="477" name="RFC" />
<format octets="40535" type="TXT" target="ftp://ftp.isi.edu/in-notes/rfc477.txt" />
</reference>


<reference target2="reference.RFC.0478.xml" anchor="RFC0478">
<front>
<title>FTP server-server interaction - II</title>
<author fullname="R.D. Bressler" initials="R.D." surname="Bressler">
<organization />
</author>

<author fullname="R. Thomas" initials="R." surname="Thomas">
<organization />
</author>

<date year="1973" day="26" month="March" />
</front>

<seriesInfo value="478" name="RFC" />
<format octets="4199" type="TXT" target="ftp://ftp.isi.edu/in-notes/rfc478.txt" />
</reference>


<reference target2="reference.RFC.0479.xml" anchor="RFC0479">
<front>
<title>Use of FTP by the NIC Journal</title>
<author fullname="James E. White" initials="J." surname="White">
<organization>Stanford Research Institute (SRI) International,  Augmentation Research Center (ARC)</organization>
</author>

<date year="1973" day="8" month="March" />

<abstract>
<t>At the Network Mail Meeting (see -- 14317,) the NIC outlined it's requirements for implementing FTP Journal delivery and submission.</t>

<t>It had always been our thinking that those two services should rely upon the File Transfer Protocol's MLFL command for their implementation.</t>
</abstract>
</front>

<seriesInfo value="479" name="RFC" />
</reference>


<reference target2="reference.RFC.0480.xml" anchor="RFC0480">
<front>
<title>Host-dependent FTP parameters</title>
<author fullname="James E. White" initials="J." surname="White">
<organization>Stanford Research Institute (SRI) International,  Augmentation Research Center (ARC)</organization>
</author>

<date year="1973" day="8" month="March" />
</front>

<seriesInfo value="480" name="RFC" />
</reference>


<reference target2="reference.RFC.0482.xml" anchor="RFC0482">
<front>
<title>Traffic statistics (February 1973)</title>
<author fullname="A.M. McKenzie" initials="A.M." surname="McKenzie">
<organization />
</author>

<date year="1973" day="12" month="March" />
</front>

<seriesInfo value="482" name="RFC" />
<format octets="6162" type="TXT" target="ftp://ftp.isi.edu/in-notes/rfc482.txt" />
</reference>


<reference target2="reference.RFC.0483.xml" anchor="RFC0483">
<front>
<title>Cancellation of the resource notebook framework meeting</title>
<author fullname="Mike Kudlick" initials="M." surname="Kudlick">
<organization>Stanford Research Institute (SRI) International,  Augmentation Research Center (ARC)</organization>
</author>

<date year="1973" day="14" month="March" />
</front>

<seriesInfo value="483" name="RFC" />
</reference>


<reference target2="reference.RFC.0485.xml" anchor="RFC0485">
<front>
<title>MIX and MIXAL at UCSB</title>
<author fullname="John R. Pickens" initials="J." surname="Pickens">
<organization>University of California, Santa Barbara (UCSB)</organization>
</author>

<author fullname="Roland F. Bryan" initials="R." surname="Bryan">
<organization>University of California, Santa Barbara (UCSB)</organization>
</author>

<date year="1973" day="19" month="March" />
</front>

<seriesInfo value="485" name="RFC" />
</reference>


<reference target2="reference.RFC.0486.xml" anchor="RFC0486">
<front>
<title>Data transfer revisited</title>
<author fullname="Bob Bressler" initials="B." surname="Bressler">
<organization>Bolt Beranek and Newman (BBN)</organization>
</author>

<date year="1973" day="20" month="March" />
</front>

<seriesInfo value="486" name="RFC" />
</reference>


<reference target2="reference.RFC.0487.xml" anchor="RFC0487">
<front>
<title>Free file transfer</title>
<author fullname="Bob Bressler" initials="B." surname="Bressler">
<organization>Bolt Beranek and Newman (BBN)</organization>
</author>

<date year="1973" day="6" month="April" />

<abstract>
<t>In the past several months, many people have commented to me about their difficulty in transferring files.  The hang up appears to be with systems that have some flavor of security, but on which the user has no access privileges.  Specifically, the FTP server demands a user and password before it will grant any system access.  The loophole which people have been using is the MAIL FILE facility, which is both limited in scope and intended for other purposes.</t>
</abstract>
</front>

<seriesInfo value="487" name="RFC" />
</reference>


<reference target2="reference.RFC.0488.xml" anchor="RFC0488">
<front>
<title>NLS classes at network sites</title>
<author fullname="Marilyn Auerbach" initials="M." surname="Auerbach">
<organization>Stanford Research Institute (SRI) International,  Augmentation Research Center (ARC)</organization>
</author>

<date year="1973" day="23" month="March" />

<abstract>
<t>Network users have expressed interest in holding NLS classes at sites on the Network, instead of at SRI-ARC.</t>
</abstract>
</front>

<seriesInfo value="488" name="RFC" />
</reference>


<reference target2="reference.RFC.0489.xml" anchor="RFC0489">
<front>
<title>Comment on resynchronization of connection status proposal</title>
<author fullname="Jon Postel" initials="J." surname="Postel">
<organization>University of California, Los Angeles (UCLA), NMC</organization>
</author>

<date year="1973" day="26" month="March" />

<abstract>
<t>This is a comment on the proposal by Burchfiel and Tomlinson in RFC 467 for a procedure in the host-to host protocol for resynchronization of connection status.</t>
</abstract>
</front>

<seriesInfo value="489" name="RFC" />
</reference>


<reference target2="reference.RFC.0490.xml" anchor="RFC0490">
<front>
<title>Surrogate RJS for UCLA-CCN</title>
<author fullname="John R. Pickens" initials="J." surname="Pickens">
<organization>University of California, Santa Barbara (UCSB)</organization>
</author>

<date year="1973" day="6" month="March" />

<abstract>
<t>By using UCSB's Network Standard RJS* users can now gain access to UCLA-CCN's RJS without converting to the UCLA protocol.  In addition, the need to use and create files in an intermediate host is avoided. For example, TIP users may operate with hot card readers and printers through UCSB's Remote Job Server and have their jobs execute at UCLA-CCN.</t>
</abstract>
</front>

<seriesInfo value="490" name="RFC" />
</reference>


<reference target2="reference.RFC.0491.xml" anchor="RFC0491">
<front>
<title>What is "Free"?</title>
<author fullname="M.A. Padlipsky" initials="M.A." surname="Padlipsky">
<organization />
</author>

<date year="1973" day="12" month="April" />
</front>

<seriesInfo value="491" name="RFC" />
<format octets="5872" type="TXT" target="ftp://ftp.isi.edu/in-notes/rfc491.txt" />
</reference>


<reference target2="reference.RFC.0492.xml" anchor="RFC0492">
<front>
<title>Response to RFC 467</title>
<author fullname="E. Meyer" initials="E." surname="Meyer">
<organization />
</author>

<date year="1973" day="18" month="April" />
</front>

<seriesInfo value="492" name="RFC" />
<format octets="18791" type="TXT" target="ftp://ftp.isi.edu/in-notes/rfc492.txt" />
</reference>


<reference target2="reference.RFC.0493.xml" anchor="RFC0493">
<front>
<title>Graphics Protocol</title>
<author fullname="J.C. Michener" initials="J.C." surname="Michener">
<organization />
</author>

<author fullname="I.W. Cotton" initials="I.W." surname="Cotton">
<organization />
</author>

<author fullname="K.C. Kelley" initials="K.C." surname="Kelley">
<organization />
</author>

<author fullname="D.E. Liddle" initials="D.E." surname="Liddle">
<organization />
</author>

<author fullname="E. Meyer" initials="E." surname="Meyer">
<organization />
</author>

<date year="1973" day="26" month="April" />
</front>

<seriesInfo value="493" name="RFC" />
</reference>


<reference target2="reference.RFC.0494.xml" anchor="RFC0494">
<front>
<title>Availability of MIX and MIXAL in the Network</title>
<author fullname="D.C. Walden" initials="D.C." surname="Walden">
<organization />
</author>

<date year="1973" day="20" month="April" />
</front>

<seriesInfo value="494" name="RFC" />
<format octets="2007" type="TXT" target="ftp://ftp.isi.edu/in-notes/rfc494.txt" />
</reference>


<reference target2="reference.RFC.0495.xml" anchor="RFC0495">
<front>
<title>Telnet Protocol specifications</title>
<author fullname="A.M. McKenzie" initials="A.M." surname="McKenzie">
<organization />
</author>

<date year="1973" day="1" month="May" />
</front>

<seriesInfo value="495" name="RFC" />
<format octets="4260" type="TXT" target="ftp://ftp.isi.edu/in-notes/rfc495.txt" />
</reference>


<reference target2="reference.RFC.0496.xml" anchor="RFC0496">
<front>
<title>TNLS quick reference card is available</title>
<author fullname="Marilyn Auerbach" initials="M." surname="Auerbach">
<organization>Stanford Research Institute (SRI) International,  Augmentation Research Center (ARC)</organization>
</author>

<date year="1973" day="5" month="April" />

<abstract>
<t>This RFC announces a new TNLS Quick Reference Card.  It documents all of the basic commands required for everyday TNLS usage as well as some special purpose features.</t>
</abstract>
</front>

<seriesInfo value="496" name="RFC" />
</reference>


<reference target2="reference.RFC.0497.xml" anchor="RFC0497">
<front>
<title>Traffic statistics (March 1973)</title>
<author fullname="A.M. McKenzie" initials="A.M." surname="McKenzie">
<organization />
</author>

<date year="1973" day="10" month="April" />
</front>

<seriesInfo value="497" name="RFC" />
</reference>


<reference target2="reference.RFC.0498.xml" anchor="RFC0498">
<front>
<title>On mail service to CCN</title>
<author fullname="Robert T. Braden" initials="R." surname="Braden">
<organization>University of California, Los Angeles (UCLA), CCN</organization>
</author>

<date year="1973" day="17" month="April" />

<abstract>
<t>Most of the recent documents on mail protocols have discussed the facilities desired at "post-office" hosts, i.e. those which provide store-and-forward services. CCN has no plans to provide post-office services; we expect to receive mail only for the staff of CCN.  Our greatest concern is to get messages reliably to and from our administrative and user support people who don't habitually use on-line terminals, so we are printing out all mail and distributing it by courier/secretary.</t>

<t>Let me say a friendly word for SNDMSG.  This Tenex command, which uses the FTP MAIL command to deliver messages, is very simple but extremely useful--probably because it is so simple.  Furthermore, it is one of the well-kept secrets of the Network that SNDMSG can be used to send messages to any host which supports the MAIL command (without requiring logon to FTP).  Thus, to send a message to anyone at CCN, the recommended procedure is to do SNDMSG to "name@CCN".  This connects to CCN's FTP and sends a "MAIL name" command followed by the message.  We now accept any "name" and print an immediate upper-case copy which is distributed to the recipient's office.  So, if you SNDMSG to "BRADEN@CCN", your message will end up on my desk, usually within a few hours.</t>
</abstract>
</front>

<seriesInfo value="498" name="RFC" />
</reference>


<reference target2="reference.RFC.0499.xml" anchor="RFC0499">
<front>
<title>Harvard's network RJE</title>
<author fullname="B.R. Reussow" initials="B.R." surname="Reussow">
<organization />
</author>

<date year="1973" day="1" month="April" />
</front>

<seriesInfo value="499" name="RFC" />
<format octets="12584" type="TXT" target="ftp://ftp.isi.edu/in-notes/rfc499.txt" />
</reference>


<reference target2="reference.RFC.0500.xml" anchor="RFC0500">
<front>
<title>Integration of data management systems on a computer network</title>
<author fullname="A. Shoshani" initials="A." surname="Shoshani">
<organization />
</author>

<author fullname="I. Spiegler" initials="I." surname="Spiegler">
<organization />
</author>

<date year="1973" day="16" month="April" />
</front>

<seriesInfo value="500" name="RFC" />
</reference>


<reference target2="reference.RFC.0501.xml" anchor="RFC0501">
<front>
<title>Un-muddling "free file transfer"</title>
<author fullname="K.T. Pogran" initials="K.T." surname="Pogran">
<organization />
</author>

<date year="1973" day="11" month="May" />
</front>

<seriesInfo value="501" name="RFC" />
<format octets="13177" type="TXT" target="ftp://ftp.isi.edu/in-notes/rfc501.txt" />
</reference>


<reference target2="reference.RFC.0503.xml" anchor="RFC0503">
<front>
<title>Socket number list</title>
<author fullname="N. Neigus" initials="N." surname="Neigus">
<organization />
</author>

<author fullname="J. Postel" initials="J." surname="Postel">
<organization />
</author>

<date year="1973" day="12" month="April" />
</front>

<seriesInfo value="503" name="RFC" />
<format octets="8690" type="TXT" target="ftp://ftp.isi.edu/in-notes/rfc503.txt" />
</reference>


<reference target2="reference.RFC.0504.xml" anchor="RFC0504">
<front>
<title abbrev="Workshop Announcement">Distributed resources workshop announcement</title>
<author fullname="Bob Thomas" initials="B." surname="Thomas">
<organization>Bolt Beranek and Newman (BBN)</organization>
</author>

<date year="1973" day="30" month="April" />

<abstract>
<t>This workshop will focus on various aspects of the question: What steps can be taken to automate access to the distributed resources on the ARPANET?</t>
</abstract>
</front>

<seriesInfo value="504" name="RFC" />
</reference>


<reference target2="reference.RFC.0505.xml" anchor="RFC0505">
<front>
<title>Two solutions to a file transfer access problem</title>
<author fullname="M.A. Padlipsky" initials="M.A." surname="Padlipsky">
<organization />
</author>

<date year="1973" day="25" month="June" />
</front>

<seriesInfo value="505" name="RFC" />
<format octets="7476" type="TXT" target="ftp://ftp.isi.edu/in-notes/rfc505.txt" />
</reference>


<reference target2="reference.RFC.0506.xml" anchor="RFC0506">
<front>
<title>FTP command naming problem</title>
<author fullname="M.A. Padlipsky" initials="M." surname="Padlipsky">
<organization>Massachusetts Institute of Technology (MIT), Multics</organization>
</author>

<date year="1973" day="26" month="June" />

<abstract>
<t>In using the File Transfer Protocol, I've noticed that the choice of names for two crucial commands is faulty.</t>
</abstract>
</front>

<seriesInfo value="506" name="RFC" />
</reference>


<reference target2="reference.RFC.0508.xml" anchor="RFC0508">
<front>
<title>Real-time data transmission on the ARPANET</title>
<author fullname="L. Pfeifer" initials="L." surname="Pfeifer">
<organization />
</author>

<author fullname="J. McAfee" initials="J." surname="McAfee">
<organization />
</author>

<date year="1973" day="7" month="May" />
</front>

<seriesInfo value="508" name="RFC" />
<format octets="25002" type="TXT" target="ftp://ftp.isi.edu/in-notes/rfc508.txt" />
</reference>


<reference target2="reference.RFC.0509.xml" anchor="RFC0509">
<front>
<title>Traffic statistics (April 1973)</title>
<author fullname="A.M. McKenzie" initials="A.M." surname="McKenzie">
<organization />
</author>

<date year="1973" day="7" month="April" />
</front>

<seriesInfo value="509" name="RFC" />
<format octets="6538" type="TXT" target="ftp://ftp.isi.edu/in-notes/rfc509.txt" />
</reference>


<reference target2="reference.RFC.0510.xml" anchor="RFC0510">
<front>
<title>Request for network mailbox addresses</title>
<author fullname="J.E. White" initials="J.E." surname="White">
<organization />
</author>

<date year="1973" day="30" month="May" />
</front>

<seriesInfo value="510" name="RFC" />
<format octets="4150" type="TXT" target="ftp://ftp.isi.edu/in-notes/rfc510.txt" />
</reference>


<reference target2="reference.RFC.0511.xml" anchor="RFC0511">
<front>
<title abbrev="ARPA Network Information Center">Enterprise phone service to NIC from ARPANET sites</title>
<author fullname="Jeanne North" initials="J." surname="North">
<organization>Stanford Research Institute (SRI) International,  Augmentation Research Center (ARC)</organization>

<address>
<postal>
<street />
<city>Menlo Park</city>
<region>CA</region>
<code>94025</code>
<country>US</country>
</postal>

</address>
</author>

<date year="1973" day="23" month="May" />

<abstract>
<t>In September 1971, NIC arranged for all Sites then on the Network to have phone service to NIC with all tolls billed to NIC. (7554,).</t>
</abstract>
</front>

<seriesInfo value="511" name="RFC" />
</reference>


<reference target2="reference.RFC.0512.xml" anchor="RFC0512">
<front>
<title>More on lost message detection</title>
<author fullname="Wayne Hathaway" initials="W." surname="Hathaway">
<organization>NASA Ames Research Center (AMES-67)</organization>
</author>

<date year="1973" day="23" month="May" />

<abstract>
<t>I would like to second Edwin Meyer's (RFC #492) strong opposition to the proposals made in RFC #467 concerning solutions to the "lost allocate" and "half-closed" phenomena.  In particular I support all of his principles concerning the "half-closed" phenomenon.  I also agree that the proposed "lost allocate" solution tends to mask the real problem of lost messages.  I would, however, like to propose the following alternative scheme for recognizing lost messages.</t>
</abstract>
</front>

<seriesInfo value="512" name="RFC" />
</reference>


<reference target2="reference.RFC.0513.xml" anchor="RFC0513">
<front>
<title>Comments on the new Telnet specifications</title>
<author fullname="Wayne Hathaway" initials="W." surname="Hathaway">
<organization>AMES-67</organization>
</author>

<date year="1973" day="30" month="May" />

<abstract>
<t>I would like to make the following comments on the proposed new TELNET Protocol Specification (NIC # 15372) and TELNET Option Specification (NIC 15373).  In general I feel the new TELNET protocol is far superior to the previous version.  There are, however, a few items of substance which I feel should be changed, as well as some recommended editorial changes.</t>
</abstract>
</front>

<seriesInfo value="513" name="RFC" />
</reference>


<reference target2="reference.RFC.0514.xml" anchor="RFC0514">
<front>
<title>Network make-work</title>
<author fullname="W. Kantrowitz" initials="W." surname="Kantrowitz">
<organization />
</author>

<date year="1973" day="5" month="June" />
</front>

<seriesInfo value="514" name="RFC" />
<format octets="8734" type="TXT" target="ftp://ftp.isi.edu/in-notes/rfc514.txt" />
</reference>


<reference target2="reference.RFC.0515.xml" anchor="RFC0515">
<front>
<title>Specifications for datalanguage: Version 0/9</title>
<author fullname="R. Winter" initials="R." surname="Winter">
<organization />
</author>

<date year="1973" day="6" month="June" />
</front>

<seriesInfo value="515" name="RFC" />
</reference>


<reference target2="reference.RFC.0516.xml" anchor="RFC0516">
<front>
<title>Lost message detection</title>
<author fullname="Jonathan B. Postel" initials="J." surname="Postel">
<organization>University of California, Los Angeles (UCLA), NMC</organization>
</author>

<date year="1973" day="18" month="May" />
</front>

<seriesInfo value="516" name="RFC" />
</reference>


<reference target2="reference.RFC.0518.xml" anchor="RFC0518">
<front>
<title>ARPANET accounts</title>
<author fullname="N. Vaughan" initials="N." surname="Vaughan">
<organization />
</author>

<author fullname="E.J. Feinler" initials="E.J." surname="Feinler">
<organization />
</author>

<date year="1973" day="19" month="June" />
</front>

<seriesInfo value="518" name="RFC" />
<format octets="12880" type="TXT" target="ftp://ftp.isi.edu/in-notes/rfc518.txt" />
</reference>


<reference target2="reference.RFC.0519.xml" anchor="RFC0519">
<front>
<title>Resource evaluation</title>
<author fullname="J.R. Pickens" initials="J.R." surname="Pickens">
<organization />
</author>

<date year="1973" day="1" month="June" />
</front>

<seriesInfo value="519" name="RFC" />
</reference>


<reference target2="reference.RFC.0520.xml" anchor="RFC0520">
<front>
<title>Memo to FTP group: Proposal for File Access Protocol</title>
<author fullname="J.D. Day" initials="J.D." surname="Day">
<organization />
</author>

<date year="1973" day="25" month="June" />
</front>

<seriesInfo value="520" name="RFC" />
<format octets="16825" type="TXT" target="ftp://ftp.isi.edu/in-notes/rfc520.txt" />
</reference>


<reference target2="reference.RFC.0521.xml" anchor="RFC0521">
<front>
<title>Restricted use of IMP DDT</title>
<author fullname="A. McKenzie" initials="A." surname="McKenzie">
<organization>Bolt Baranek and Newman (BBN), NET</organization>
</author>

<date year="1973" day="30" month="May" />

<abstract>
<t>At the recent workshop on "Automated Resource Sharing on the ARPANET", considerable interest was expressed on the topic of network security.  In particular, representatives of several sites felt that uncontrolled use of IMP DDT made access control mechanisms quite vulnerable to interception or tampering.*</t>
</abstract>
</front>

<seriesInfo value="521" name="RFC" />
</reference>


<reference target2="reference.RFC.0522.xml" anchor="RFC0522">
<front>
<title>Traffic statistics (May 1973)</title>
<author fullname="A.M. McKenzie" initials="A.M." surname="McKenzie">
<organization />
</author>

<date year="1973" day="5" month="June" />
</front>

<seriesInfo value="522" name="RFC" />
</reference>


<reference target2="reference.RFC.0523.xml" anchor="RFC0523">
<front>
<title>SURVEY is in operation again</title>
<author fullname="Abhay K. Bhushan" initials="A." surname="Bhushan">
<organization>Massachusetts Institute of Technology (MIT), DMCG</organization>
</author>

<date year="1973" day="5" month="June" />

<abstract>
<t>The purpose of this message is to inform the network community that the survey program at MIT-DMCG computer system is in operation now.</t>
</abstract>
</front>

<seriesInfo value="523" name="RFC" />
</reference>


<reference target2="reference.RFC.0524.xml" anchor="RFC0524">
<front>
<title>Proposed Mail Protocol</title>
<author fullname="J.E. White" initials="J.E." surname="White">
<organization />
</author>

<date year="1973" day="13" month="June" />
</front>

<seriesInfo value="524" name="RFC" />
<format octets="75385" type="TXT" target="ftp://ftp.isi.edu/in-notes/rfc524.txt" />
</reference>


<reference target2="reference.RFC.0525.xml" anchor="RFC0525">
<front>
<title>MIT-MATHLAB meets UCSB-OLS -an example of resource sharing</title>
<author fullname="W. Parrish" initials="W." surname="Parrish">
<organization />
</author>

<author fullname="J.R. Pickens" initials="J.R." surname="Pickens">
<organization />
</author>

<date year="1973" day="1" month="June" />
</front>

<seriesInfo value="525" name="RFC" />
<format octets="18501" type="TXT" target="ftp://ftp.isi.edu/in-notes/rfc525.txt" />
<format octets="304440" type="PS" target="ftp://ftp.isi.edu/in-notes/rfc525.ps" />
<format octets="228274" type="PDF" target="ftp://ftp.isi.edu/in-notes/rfc525.pdf" />
</reference>


<reference target2="reference.RFC.0526.xml" anchor="RFC0526">
<front>
<title abbrev="Digital Image Processing Software Systems Meeting">Technical meeting: Digital image processing software systems</title>
<author fullname="William K. Pratt" initials="W." surname="Pratt">
<organization>University of Southern California (USC)</organization>

<address>
<postal>
<street>University Park, Olin Hall</street>
<street>Room 330H</street>
<city>Los Angeles</city>
<region>CA</region>
<code>90007</code>
<country>US</country>
</postal>

<phone>+1 213 746 2694</phone>
</address>
</author>

<date year="1973" day="25" month="June" />
</front>

<seriesInfo value="526" name="RFC" />
</reference>


<reference target2="reference.RFC.0527.xml" anchor="RFC0527">
<front>
<title>ARPAWOCKY</title>
<author fullname="R. Merryman" initials="R." surname="Merryman">
<organization>University of California, San Diego (UCSD), CC</organization>
</author>

<author fullname="D. L. Covill" initials="D." surname="Covill">
<organization />
</author>

<date year="1973" day="22" month="June" />
</front>

<seriesInfo value="527" name="RFC" />
</reference>


<reference target2="reference.RFC.0528.xml" anchor="RFC0528">
<front>
<title>Software checksumming in the IMP and network reliability</title>
<author fullname="J.M. McQuillan" initials="J.M." surname="McQuillan">
<organization />
</author>

<date year="1973" day="20" month="June" />
</front>

<seriesInfo value="528" name="RFC" />
<format octets="23152" type="TXT" target="ftp://ftp.isi.edu/in-notes/rfc528.txt" />
</reference>


<reference target2="reference.RFC.0529.xml" anchor="RFC0529">
<front>
<title>Note on protocol synch sequences</title>
<author fullname="A.M. McKenzie" initials="A.M." surname="McKenzie">
<organization />
</author>

<author fullname="R. Thomas" initials="R." surname="Thomas">
<organization />
</author>

<author fullname="R.S. Tomlinson" initials="R.S." surname="Tomlinson">
<organization />
</author>

<author fullname="K.T. Pogran" initials="K.T." surname="Pogran">
<organization />
</author>

<date year="1973" day="29" month="June" />
</front>

<seriesInfo value="529" name="RFC" />
<format octets="9068" type="TXT" target="ftp://ftp.isi.edu/in-notes/rfc529.txt" />
</reference>


<reference target2="reference.RFC.0530.xml" anchor="RFC0530">
<front>
<title>Report on the Survey project</title>
<author fullname="A.K. Bhushan" initials="A.K." surname="Bhushan">
<organization />
</author>

<date year="1973" day="22" month="June" />
</front>

<seriesInfo value="530" name="RFC" />
</reference>


<reference target2="reference.RFC.0531.xml" anchor="RFC0531">
<front>
<title abbrev="Feast or famine?">Feast or famine? A response to two recent RFC's about network information</title>
<author fullname="M. A. Padlipsky" initials="M." surname="Padlipsky">
<organization>Massachusetts Institute of Technology (MIT), Multics</organization>
</author>

<date year="1973" day="26" month="June" />

<abstract>
<t>In RFC 514, Will Kantrowitz returns to the theme of his superb RFC 459. There are too many people spending too much time asking for too much information about Network Hosts.  In RFC 519, John Pickens returns to the theme of his rather querulous RFC 369.  It's not easy to learn how to use network Hosts.  On the one hand, it would seem that there's a veritable feast of information going around; on the other hand it would seem that there's a terrible famine.  Can this apparent contradiction be resolved?</t>
</abstract>
</front>

<seriesInfo value="531" name="RFC" />
</reference>


<reference target2="reference.RFC.0532.xml" anchor="RFC0532">
<front>
<title>UCSD-CC Server-FTP facility</title>
<author fullname="R.G. Merryman" initials="R.G." surname="Merryman">
<organization />
</author>

<date year="1973" day="12" month="July" />
</front>

<seriesInfo value="532" name="RFC" />
<format octets="7298" type="TXT" target="ftp://ftp.isi.edu/in-notes/rfc532.txt" />
</reference>


<reference target2="reference.RFC.0533.xml" anchor="RFC0533">
<front>
<title>Message-ID numbers</title>
<author fullname="David Walden" initials="D." surname="Walden">
<organization>Bolt Baranek and Newman (BBN), NET</organization>
</author>

<date year="1973" day="17" month="July" />

<abstract>
<t>It has been noted that the IMP message format (specified in BBN Report 1822) constrains network users to low throughputs if messages are to be uniquely identified via the link number.  We have recently implemented a change in the IMP/Host protocol which alleviates this difficulty.</t>
</abstract>
</front>

<seriesInfo value="533" name="RFC" />
</reference>


<reference target2="reference.RFC.0534.xml" anchor="RFC0534">
<front>
<title>Lost message detection</title>
<author fullname="D.C. Walden" initials="D.C." surname="Walden">
<organization />
</author>

<date year="1973" day="17" month="July" />
</front>

<seriesInfo value="534" name="RFC" />
<format octets="3227" type="TXT" target="ftp://ftp.isi.edu/in-notes/rfc534.txt" />
</reference>


<reference target2="reference.RFC.0535.xml" anchor="RFC0535">
<front>
<title>Comments on File Access Protocol</title>
<author fullname="R. Thomas" initials="R." surname="Thomas">
<organization />
</author>

<date year="1973" day="25" month="July" />
</front>

<seriesInfo value="535" name="RFC" />
</reference>


<reference target2="reference.RFC.0537.xml" anchor="RFC0537">
<front>
<title>Announcement of NGG meeting July 16-17</title>
<author fullname="S. Bunch" initials="S." surname="Bunch">
<organization />
</author>

<date year="1973" day="27" month="June" />
</front>

<seriesInfo value="537" name="RFC" />
<format octets="2695" type="TXT" target="ftp://ftp.isi.edu/in-notes/rfc537.txt" />
</reference>


<reference target2="reference.RFC.0538.xml" anchor="RFC0538">
<front>
<title>Traffic statistics (June 1973)</title>
<author fullname="A.M. McKenzie" initials="A.M." surname="McKenzie">
<organization />
</author>

<date year="1973" day="5" month="July" />
</front>

<seriesInfo value="538" name="RFC" />
<format octets="6389" type="TXT" target="ftp://ftp.isi.edu/in-notes/rfc538.txt" />
</reference>


<reference target2="reference.RFC.0539.xml" anchor="RFC0539">
<front>
<title>Thoughts on the mail protocol proposed in RFC 524</title>
<author fullname="D. Crocker" initials="D." surname="Crocker">
<organization>University of Calfornia, Los Angeles (UCLA), NMC</organization>
</author>

<author fullname="J. Postel" initials="J." surname="Postel">
<organization>University of Calfornia, Los Angeles (UCLA), NMC</organization>
</author>

<date year="1973" day="7" month="July" />
</front>

<seriesInfo value="539" name="RFC" />
</reference>


<reference target2="reference.RFC.0542.xml" anchor="RFC0542">
<front>
<title abbrev="File Transfer Protocol">File Transfer Protocol</title>
<author fullname="Nancy J. Neigus" initials="N." surname="Neigus">
<organization>Bolt Beranek and Newman, Inc. (BBN)</organization>

<address>
<postal>
<street>10 Moulton Street</street>
<city>Cambridge</city>
<region>MA</region>
<code>02138</code>
<country>US</country>
</postal>

</address>
</author>

<date year="1973" day="12" month="August" />
</front>

<seriesInfo value="542" name="RFC" />
</reference>


<reference target2="reference.RFC.0543.xml" anchor="RFC0543">
<front>
<title>Network journal submission and delivery</title>
<author fullname="N.D. Meyer" initials="N.D." surname="Meyer">
<organization />
</author>

<date year="1973" day="24" month="July" />
</front>

<seriesInfo value="543" name="RFC" />
<format octets="15621" type="TXT" target="ftp://ftp.isi.edu/in-notes/rfc543.txt" />
</reference>


<reference target2="reference.RFC.0544.xml" anchor="RFC0544">
<front>
<title>Locating on-line documentation at SRI-ARC</title>
<author fullname="Dean Meyer" initials="D." surname="Meyer">
<organization>Stanford Research Institute (SRI) International,  Augmentation Research Center (ARC)</organization>
</author>

<author fullname="Kirk Kelley" initials="K." surname="Kelley">
<organization>Stanford Research Institute (SRI) International,  Augmentation Research Center (ARC)</organization>
</author>

<date year="1973" day="13" month="July" />
</front>

<seriesInfo value="544" name="RFC" />
</reference>


<reference target2="reference.RFC.0545.xml" anchor="RFC0545">
<front>
<title>Of what quality be the UCSB resources evaluators?</title>
<author fullname="J.R. Pickens" initials="J.R." surname="Pickens">
<organization />
</author>

<date year="1973" day="23" month="July" />
</front>

<seriesInfo value="545" name="RFC" />
<format octets="3754" type="TXT" target="ftp://ftp.isi.edu/in-notes/rfc545.txt" />
</reference>


<reference target2="reference.RFC.0546.xml" anchor="RFC0546">
<front>
<title>Tenex load averages for July 1973</title>
<author fullname="R. Thomas" initials="R." surname="Thomas">
<organization />
</author>

<date year="1973" day="10" month="August" />
</front>

<seriesInfo value="546" name="RFC" />
<format octets="6632" type="TXT" target="ftp://ftp.isi.edu/in-notes/rfc546.txt" />
<format octets="356023" type="PS" target="ftp://ftp.isi.edu/in-notes/rfc546.ps" />
<format octets="268918" type="PDF" target="ftp://ftp.isi.edu/in-notes/rfc546.pdf" />
</reference>


<reference target2="reference.RFC.0547.xml" anchor="RFC0547">
<front>
<title>Change to the Very Distant Host specification</title>
<author fullname="D.C. Walden" initials="D.C." surname="Walden">
<organization />
</author>

<date year="1973" day="13" month="August" />
</front>

<seriesInfo value="547" name="RFC" />
<format octets="6236" type="TXT" target="ftp://ftp.isi.edu/in-notes/rfc547.txt" />
</reference>


<reference target2="reference.RFC.0548.xml" anchor="RFC0548">
<front>
<title>Hosts using the IMP Going Down message</title>
<author fullname="D. Walden" initials="D." surname="Walden">
<organization>Bolt Baranek and Newman (BBN), NET</organization>
</author>

<date year="1973" day="16" month="August" />

<abstract>
<t>As given in BBN Report 1822 (Specifications for the Interconnection of a Host and an IMP), IMP to Host message type 2 specifies that the IMP local to the Host is going down; the message further says when the IMP is going down, for how long, and why.</t>
</abstract>
</front>

<seriesInfo value="548" name="RFC" />
</reference>


<reference target2="reference.RFC.0549.xml" anchor="RFC0549">
<front>
<title>Minutes of Network Graphics Group meeting, 15-17 July 1973</title>
<author fullname="J.C. Michener" initials="J.C." surname="Michener">
<organization />
</author>

<date year="1973" day="17" month="July" />
</front>

<seriesInfo value="549" name="RFC" />
<format octets="23367" type="TXT" target="ftp://ftp.isi.edu/in-notes/rfc549.txt" />
</reference>


<reference target2="reference.RFC.0550.xml" anchor="RFC0550">
<front>
<title>NIC NCP experiment</title>
<author fullname="L. P. Deutsch" initials="L." surname="Deutsch">
<organization>Xerox Palo Alto Research Center (PARC), MAXC</organization>
</author>

<date year="1973" day="24" month="August" />

<abstract>
<t>For the past couple of weeks, the NIC NCP has been keeping statistics on total incoming messages, incoming host-host control opcodes, and size of outgoing messages.</t>
</abstract>
</front>

<seriesInfo value="550" name="RFC" />
</reference>


<reference target2="reference.RFC.0551.xml" anchor="RFC0551">
<front>
<title>NYU, ANL, and LBL Joining the Net</title>
<author>
<organization>Feinroth</organization>
</author>

<date year="1973" month="August" />
</front>

<seriesInfo value="551" name="RFC" />
</reference>


<reference target2="reference.RFC.0552.xml" anchor="RFC0552">
<front>
<title>Single access to standard protocols</title>
<author fullname="Buz Owen" initials="B." surname="Owen">
<organization>SDAC, TIP</organization>
</author>

<date year="1973" day="13" month="July" />

<abstract>
<t>Isn't the idea of a single access protocol simple enough that one could be specified, and a socket reserved for it, before the proposed mail protocol becomes official?  The result would be that MP could be the first protocol implemented under UULP (or whatever it is to be called), and the other protocols could be "moved" as soon as any problems in the official specifications could be worked out, and at the convenience of implementors.</t>
</abstract>
</front>

<seriesInfo value="552" name="RFC" />
</reference>


<reference target2="reference.RFC.0553.xml" anchor="RFC0553">
<front>
<title>Draft design for a text/graphics protocol</title>
<author fullname="C.H. Irby" initials="C.H." surname="Irby">
<organization />
</author>

<author fullname="K. Victor" initials="K." surname="Victor">
<organization />
</author>

<date year="1973" day="14" month="July" />
</front>

<seriesInfo value="553" name="RFC" />
<format octets="35414" type="TXT" target="ftp://ftp.isi.edu/in-notes/rfc553.txt" />
</reference>


<reference target2="reference.RFC.0555.xml" anchor="RFC0555">
<front>
<title>Responses to critiques of the proposed mail protocol</title>
<author fullname="James E. White" initials="J." surname="White">
<organization>Stanford Research Institute (SRI) International,  Augmentation Research Center (ARC)</organization>
</author>

<date year="1973" day="27" month="July" />

<abstract>
<t>A number of people have responded to my proposal for a Mail Protocol (JEW RFC 524 -- 17140,2:y).  In the current RFC, I've attempted to collect and respond to the questions, complaints, and suggestions that various individuals in the Network community have offered.  I intend to critique myself in a forthcoming RFC.</t>
</abstract>
</front>

<seriesInfo value="555" name="RFC" />
</reference>


<reference target2="reference.RFC.0556.xml" anchor="RFC0556">
<front>
<title>Traffic statistics (July 1973)</title>
<author fullname="A.M. McKenzie" initials="A.M." surname="McKenzie">
<organization />
</author>

<date year="1973" day="13" month="August" />
</front>

<seriesInfo value="556" name="RFC" />
</reference>


<reference target2="reference.RFC.0557.xml" anchor="RFC0557">
<front>
<title>Revelations in network host measurements</title>
<author fullname="B.D. Wessler" initials="B.D." surname="Wessler">
<organization />
</author>

<date year="1973" day="30" month="August" />
</front>

<seriesInfo value="557" name="RFC" />
</reference>


<reference target2="reference.RFC.0559.xml" anchor="RFC0559">
<front>
<title abbrev="Comments on TELNET">Comments on The New Telnet Protocol and its Implementation</title>
<author fullname="Abhay K. Bushan" initials="A." surname="Bushan">
<organization>Massachusetts Institute of Technology (MIT), Project MAC</organization>
</author>

<date year="1973" day="15" month="August" />

<abstract>
<t>We at MIT-DN have implemented the new TELNET protocol (both server and user).  This RFC describes our experience with the implementation (particularly the use of GO AHEAD) and in bringing the new User and Server TELNET's in operation (the new TELNET is not compatible with the old).  We have a few suggestions here which should help other implementors and lead to a smoother transition to the new protocol.</t>
</abstract>
</front>

<seriesInfo value="559" name="RFC" />
</reference>


<reference target2="reference.RFC.0560.xml" anchor="RFC0560">
<front>
<title>Remote Controlled Transmission and Echoing Telnet option</title>
<author fullname="D. Crocker" initials="D." surname="Crocker">
<organization />
</author>

<author fullname="J. Postel" initials="J." surname="Postel">
<organization />
</author>

<date year="1973" day="18" month="August" />
</front>

<seriesInfo value="560" name="RFC" />
</reference>


<reference target2="reference.RFC.0561.xml" anchor="RFC0561">
<front>
<title>Standardizing Network Mail Headers</title>
<author fullname="Abhay Bhushan" initials="A." surname="Bhushan">
<organization>Massachusetts Institute of Technology (MIT), DMCG</organization>
</author>

<author fullname="Ken Pogran" initials="K." surname="Pogran">
<organization>Massachusetts Institute of Technology (MIT), MULTICS</organization>
</author>

<author fullname="Ray Tomlinson" initials="R." surname="Tomlinson">
<organization>Bolt Baranek and Newman (BBN), TENEX</organization>
</author>

<author fullname="Jim White" initials="J." surname="White">
<organization>Stanford Research Institute (SRI), Augmentation Research Center (ARC)</organization>
</author>

<date year="1973" day="5" month="September" />

<abstract>
<t>One of the deficiences of the current FTP mail protocol is that it makes no provision for the explicit specification of such header information as author, title, and date.  Many systems send that information, but each in a different format.  One fairly serious result of this lack of standardization is that it's next to impossible for a system or user program to intelligently process incoming mail.</t>
</abstract>
</front>

<seriesInfo value="561" name="RFC" />
</reference>


<reference target2="reference.RFC.0562.xml" anchor="RFC0562">
<front>
<title>Modifications to the Telnet specification</title>
<author fullname="A.M. McKenzie" initials="A.M." surname="McKenzie">
<organization />
</author>

<date year="1973" day="28" month="August" />
</front>

<seriesInfo value="562" name="RFC" />
</reference>


<reference target2="reference.RFC.0563.xml" anchor="RFC0563">
<front>
<title>Comments on the RCTE Telnet option</title>
<author fullname="J. Davidson" initials="J." surname="Davidson">
<organization />
</author>

<date year="1973" day="28" month="August" />
</front>

<seriesInfo value="563" name="RFC" />
<format octets="10788" type="TXT" target="ftp://ftp.isi.edu/in-notes/rfc563.txt" />
</reference>


<reference target2="reference.RFC.0565.xml" anchor="RFC0565">
<front>
<title>Storing network survey data at the datacomputer</title>
<author fullname="D. Cantor" initials="D." surname="Cantor">
<organization />
</author>

<date year="1973" day="28" month="August" />
</front>

<seriesInfo value="565" name="RFC" />
<format octets="9307" type="TXT" target="ftp://ftp.isi.edu/in-notes/rfc565.txt" />
</reference>


<reference target2="reference.RFC.0566.xml" anchor="RFC0566">
<front>
<title>Traffic statistics (August 1973)</title>
<author fullname="A.M. McKenzie" initials="A.M." surname="McKenzie">
<organization />
</author>

<date year="1973" day="4" month="September" />
</front>

<seriesInfo value="566" name="RFC" />
<format octets="6674" type="TXT" target="ftp://ftp.isi.edu/in-notes/rfc566.txt" />
</reference>


<reference target2="reference.RFC.0567.xml" anchor="RFC0567">
<front>
<title>Cross Country Network Bandwidth</title>
<author fullname="L. Peter Deutsch" initials="L." surname="Deutsch">
<organization>Xerox Palo Alto Research Center (PARC). MAXC</organization>
</author>

<date year="1973" day="6" month="September" />

<abstract>
<t>The following computation of cross-country network bandwidth was contributed by Butler Lampson of PARC.</t>
</abstract>
</front>

<seriesInfo value="567" name="RFC" />
</reference>


<reference target2="reference.RFC.0568.xml" anchor="RFC0568">
<front>
<title>Response to RFC 567 - cross country network bandwidth</title>
<author fullname="J. McQuillan" initials="J." surname="McQuillan">
<organization>Bolt Baranek and Newman (BBN), NET</organization>
</author>

<date year="1973" day="18" month="September" />

<abstract>
<t>This note serves as a brief correction to several fundamental errors in RFC 567 by L. Peter Deutsch.</t>
</abstract>
</front>

<seriesInfo value="568" name="RFC" />
</reference>


<reference target2="reference.RFC.0569.xml" anchor="RFC0569">
<front>
<title>NETED: A Common Editor for the ARPA Network</title>
<author fullname="Mike Padlipsky" initials="M." surname="Padlipsky">
<organization />
</author>

<date year="1973" day="15" month="October" />
</front>

<seriesInfo value="569" name="RFC" />
</reference>


<reference target2="reference.RFC.0570.xml" anchor="RFC0570">
<front>
<title>Experimental input mapping between NVT ASCII and UCSB On Line System</title>
<author fullname="J.R. Pickens" initials="J.R." surname="Pickens">
<organization />
</author>

<date year="1973" day="30" month="October" />
</front>

<seriesInfo value="570" name="RFC" />
<format octets="177" type="TXT" target="ftp://ftp.isi.edu/in-notes/rfc570.txt" />
<format octets="488023" type="PS" target="ftp://ftp.isi.edu/in-notes/rfc570.ps" />
<format octets="375635" type="PDF" target="ftp://ftp.isi.edu/in-notes/rfc570.pdf" />
</reference>


<reference target2="reference.RFC.0571.xml" anchor="RFC0571">
<front>
<title>Tenex FTP problem</title>
<author fullname="R.T. Braden" initials="R.T." surname="Braden">
<organization />
</author>

<date year="1973" day="15" month="November" />
</front>

<seriesInfo value="571" name="RFC" />
</reference>


<reference target2="reference.RFC.0573.xml" anchor="RFC0573">
<front>
<title>Data and file transfer: Some measurement results</title>
<author fullname="A.K. Bhushan" initials="A.K." surname="Bhushan">
<organization />
</author>

<date year="1973" day="14" month="September" />
</front>

<seriesInfo value="573" name="RFC" />
</reference>


<reference target2="reference.RFC.0574.xml" anchor="RFC0574">
<front>
<title>Announcement of a mail facility at UCSB</title>
<author fullname="M. Krilanovich" initials="M." surname="Krilanovich">
<organization />
</author>

<date year="1973" day="26" month="September" />
</front>

<seriesInfo value="574" name="RFC" />
</reference>


<reference target2="reference.RFC.0576.xml" anchor="RFC0576">
<front>
<title>Proposal for modifying linking</title>
<author fullname="K. Victor" initials="K." surname="Victor">
<organization />
</author>

<date year="1973" day="26" month="September" />
</front>

<seriesInfo value="576" name="RFC" />
</reference>


<reference target2="reference.RFC.0577.xml" anchor="RFC0577">
<front>
<title>Mail priority</title>
<author fullname="D. Crocker" initials="D." surname="Crocker">
<organization />
</author>

<date year="1973" day="18" month="October" />
</front>

<seriesInfo value="577" name="RFC" />
</reference>


<reference target2="reference.RFC.0578.xml" anchor="RFC0578">
<front>
<title>Using MIT-Mathlab MACSYMA from MIT-DMS Muddle</title>
<author fullname="A.K. Bhushan" initials="A.K." surname="Bhushan">
<organization />
</author>

<author fullname="N.D. Ryan" initials="N.D." surname="Ryan">
<organization />
</author>

<date year="1973" day="29" month="October" />
</front>

<seriesInfo value="578" name="RFC" />
</reference>


<reference target2="reference.RFC.0579.xml" anchor="RFC0579">
<front>
<title>Traffic statistics (September 1973)</title>
<author fullname="A.M. McKenzie" initials="A.M." surname="McKenzie">
<organization />
</author>

<date year="1973" day="26" month="November" />
</front>

<seriesInfo value="579" name="RFC" />
</reference>


<reference target2="reference.RFC.0580.xml" anchor="RFC0580">
<front>
<title>Note to Protocol Designers and Implementers</title>
<author fullname="Jon Postel" initials="J." surname="Postel">
<organization>The MITRE Corporation</organization>

<address>
<postal>
<street>Westgate Research Park</street>
<street>Mail Stop W185</street>
<city>McLean</city>
<region>VA</region>
<code>22101</code>
<country>US</country>
</postal>

<phone>+1 703 893 3500 x2350</phone>
<email>POSTEL@ISI</email>
</address>
</author>

<date year="1973" day="25" month="October" />

<abstract>
<t>Hereafter proposed protocols shall be submitted in the form of on-line documents, preferably as nls files at the Network Information Center. This will greatly facilitate the review process and enable editorial and substantive changes to proceed quickly. This also will permit timely updating of protocol documents as may be neccessitated by future decisions. On-line documents are also easily distributed to the network community. If you find great difficulty in complying with this request please contact me.</t>
</abstract>
</front>

<seriesInfo value="580" name="RFC" />
</reference>


<reference target2="reference.RFC.0581.xml" anchor="RFC0581">
<front>
<title>Corrections to RFC 560: Remote Controlled Transmission and Echoing Telnet Option</title>
<author fullname="D. Crocker" initials="D." surname="Crocker">
<organization />
</author>

<author fullname="J. Postel" initials="J." surname="Postel">
<organization />
</author>

<date year="1973" day="2" month="November" />
</front>

<seriesInfo value="581" name="RFC" />
</reference>


<reference target2="reference.RFC.0582.xml" anchor="RFC0582">
<front>
<title>Comments on RFC 580: Machine readable protocols</title>
<author fullname="R. Clements" initials="R." surname="Clements">
<organization />
</author>

<date year="1973" day="5" month="November" />
</front>

<seriesInfo value="582" name="RFC" />
<format octets="1635" type="TXT" target="ftp://ftp.isi.edu/in-notes/rfc582.txt" />
</reference>


<reference target2="reference.RFC.0584.xml" anchor="RFC0584">
<front>
<title>Charter for ARPANET Users Interest Working Group</title>
<author fullname="J. Iseli" initials="J." surname="Iseli">
<organization>MITRE Corporation, TIP</organization>
</author>

<author fullname="D. Crocker" initials="D." surname="Crocker">
<organization>University of California, Los Angeles (UCLA), New Media Centers (NMC)</organization>
</author>

<author fullname="N. Neigus" initials="N." surname="Neigus">
<organization>Bolt Beranek and Newman Inc. (BBN), Network Control Center (NET)</organization>
</author>

<date year="1973" day="6" month="November" />
</front>

<seriesInfo value="584" name="RFC" />
</reference>


<reference target2="reference.RFC.0585.xml" anchor="RFC0585">
<front>
<title abbrev="USING Working Group Meeting">ARPANET users interest working group meeting</title>
<author fullname="D. Crocker" initials="D." surname="Crocker">
<organization>University of California, Los Angeles (UCLA), New Media Centers (NMC)</organization>
</author>

<author fullname="N. Neigus" initials="N." surname="Neigus">
<organization>Bolt Beranek and Newman Inc. (BBN), Network Control Center (NET)</organization>
</author>

<author fullname="J. Feinler" initials="J." surname="Feinler">
<organization>Stanford Research Institute (SRI), Augmentation Research Center (ARC)</organization>
</author>

<author fullname="J. Iseli" initials="J." surname="Iseli">
<organization>MITRE Corporation, TIP</organization>
</author>

<date year="1973" day="6" month="November" />

<abstract>
<t>A new group, the Arpanet Users Interest Working Group (USING) is the outgrowth of a meeting held in Boston on May 22-23, 1973.</t>
</abstract>
</front>

<seriesInfo value="585" name="RFC" />
</reference>


<reference target2="reference.RFC.0586.xml" anchor="RFC0586">
<front>
<title>Traffic statistics (October 1973)</title>
<author fullname="A.M. McKenzie" initials="A.M." surname="McKenzie">
<organization />
</author>

<date year="1973" day="8" month="November" />
</front>

<seriesInfo value="586" name="RFC" />
</reference>


<reference target2="reference.RFC.0587.xml" anchor="RFC0587">
<front>
<title>Announcing new Telnet options</title>
<author fullname="J. Postel" initials="J." surname="Postel">
<organization />
</author>

<date year="1973" day="13" month="November" />
</front>

<seriesInfo value="587" name="RFC" />
</reference>


<reference target2="reference.RFC.0588.xml" anchor="RFC0588">
<front>
<title>London node is now up</title>
<author fullname="A.V. Stokes" initials="A.V." surname="Stokes">
<organization />
</author>

<date year="1973" day="29" month="October" />
</front>

<seriesInfo value="588" name="RFC" />
</reference>


<reference target2="reference.RFC.0589.xml" anchor="RFC0589">
<front>
<title>CCN NETRJS server messages to remote user</title>
<author fullname="R.T. Braden" initials="R.T." surname="Braden">
<organization />
</author>

<date year="1973" day="26" month="November" />
</front>

<seriesInfo value="589" name="RFC" />
<format octets="7998" type="TXT" target="ftp://ftp.isi.edu/in-notes/rfc589.txt" />
</reference>


<reference target2="reference.RFC.0590.xml" anchor="RFC0590">
<front>
<title>MULTICS address change</title>
<author fullname="M.A. Padlipsky" initials="M.A." surname="Padlipsky">
<organization />
</author>

<date year="1973" day="19" month="November" />
</front>

<seriesInfo value="590" name="RFC" />
<format octets="1436" type="TXT" target="ftp://ftp.isi.edu/in-notes/rfc590.txt" />
</reference>


<reference target2="reference.RFC.0591.xml" anchor="RFC0591">
<front>
<title>Addition to the Very Distant Host specifications</title>
<author fullname="D.C. Walden" initials="D.C." surname="Walden">
<organization />
</author>

<date year="1973" day="29" month="November" />
</front>

<seriesInfo value="591" name="RFC" />
<format octets="901" type="TXT" target="ftp://ftp.isi.edu/in-notes/rfc591.txt" />
</reference>


<reference target2="reference.RFC.0592.xml" anchor="RFC0592">
<front>
<title>Some thoughts on system design to facilitate resource sharing</title>
<author fullname="R.W. Watson" initials="R.W." surname="Watson">
<organization />
</author>

<date year="1973" day="20" month="November" />
</front>

<seriesInfo value="592" name="RFC" />
</reference>


<reference target2="reference.RFC.0593.xml" anchor="RFC0593">
<front>
<title abbrev="Telnet &amp; FTP Implementation Schedule Change">Telnet and FTP implementation schedule change</title>
<author fullname="Alex McKenzie" initials="A." surname="McKenzie">
<organization>Bolt Beranek and Newman (BBN)</organization>
</author>

<author fullname="Jon Postel" initials="J." surname="Postel">
<organization>MITRE Corporation (MITRE)</organization>
</author>

<date year="1973" day="29" month="November" />
</front>

<seriesInfo value="593" name="RFC" />
</reference>


<reference target2="reference.RFC.0594.xml" anchor="RFC0594">
<front>
<title>Speedup of Host-IMP interface</title>
<author fullname="J.D. Burchfiel" initials="J.D." surname="Burchfiel">
<organization />
</author>

<date year="1973" day="10" month="December" />
</front>

<seriesInfo value="594" name="RFC" />
</reference>


<reference target2="reference.RFC.0595.xml" anchor="RFC0595">
<front>
<title abbrev="In Defense of the TELNET Go-Ahead">Second thoughts in defense of the Telnet Go-Ahead</title>
<author fullname="Wayne Hathaway" initials="W." surname="Hathaway">
<organization>NASA Ames Research Center (AMES-67)</organization>
</author>

<date year="1973" day="12" month="December" />

<abstract>
<t>This note is a reply to Edward Taft's "Second Thoughts on TELNET Go-Ahead" (NIC #20812).</t>
</abstract>
</front>

<seriesInfo value="595" name="RFC" />
</reference>


<reference target2="reference.RFC.0596.xml" anchor="RFC0596">
<front>
<title>Second thoughts on Telnet Go-Ahead</title>
<author fullname="E. Taft" initials="E." surname="Taft">
<organization>Xerox Palo Alto Research Center (PARC), MAXC</organization>
</author>

<date year="1973" day="8" month="December" />

<abstract>
<t>In this RFC we present objections to the requirement that hosts implement the Telnet Go-Ahead (GA) command, as specified in the Telnet Protocol Specification (NIC #15372).</t>
</abstract>
</front>

<seriesInfo value="596" name="RFC" />
</reference>


<reference target2="reference.RFC.0597.xml" anchor="RFC0597">
<front>
<title>Host status</title>
<author fullname="N. Neigus" initials="N." surname="Neigus">
<organization />
</author>

<author fullname="J. Feinler" initials="J." surname="Feinler">
<organization />
</author>

<date year="1973" day="12" month="December" />

<abstract>
<t>Attached are the latest network maps -- geographic and logical -- and a list of Hosts connected to the ARPANET.</t>

<t>The geographic map shows all IMPs and TIPs currently installed in the subnetwork.</t>
</abstract>
</front>

<seriesInfo value="597" name="RFC" />
</reference>


<reference target2="reference.RFC.0598.xml" anchor="RFC0598">
<front>
<title>RFC index - December 5, 1973</title>
<author>
<organization>SRI/Network Information Center</organization>
</author>

<date year="1973" day="5" month="December" />
</front>

<seriesInfo value="598" name="RFC" />
</reference>


<reference target2="reference.RFC.0599.xml" anchor="RFC0599">
<front>
<title>Update on NETRJS</title>
<author fullname="Robert T. Braden" initials="R." surname="Braden">
<organization>University of California, Los Angeles (UCLA), CCN</organization>
</author>

<date year="1973" day="13" month="December" />
</front>

<seriesInfo value="599" name="RFC" />
</reference>


<reference target2="reference.RFC.0600.xml" anchor="RFC0600">
<front>
<title>Interfacing an Illinois plasma terminal to the ARPANET</title>
<author fullname="A. Berggreen" initials="A." surname="Berggreen">
<organization />
</author>

<date year="1973" day="26" month="November" />
</front>

<seriesInfo value="600" name="RFC" />
</reference>


<reference target2="reference.RFC.0601.xml" anchor="RFC0601">
<front>
<title>Traffic statistics (November 1973)</title>
<author fullname="A. McKenzie" initials="A." surname="McKenzie">
<organization>Bolt Beranek and Newman Inc. (BBN), Network Control Center (NET)</organization>
</author>

<date year="1973" day="14" month="December" />
</front>

<seriesInfo value="601" name="RFC" />
</reference>


<reference target2="reference.RFC.0602.xml" anchor="RFC0602">
<front>
<title>"The stockings were hung by the chimney with care"</title>
<author fullname="Bob Metcalfe" initials="B." surname="Metcalfe">
<organization>Xerox Palo Alto Research Center (PARC), MAXC</organization>
</author>

<date year="1973" day="27" month="December" />
</front>

<seriesInfo value="602" name="RFC" />
</reference>


<reference target2="reference.RFC.0603.xml" anchor="RFC0603">
<front>
<title>Response to RFC 597: Host status</title>
<author fullname="J. D. Burchfiel" initials="J." surname="Burchfiel">
<organization>Bolt Baranek and Newman (BBN), TENEX</organization>
</author>

<date year="1973" day="31" month="December" />
</front>

<seriesInfo value="603" name="RFC" />
</reference>


<reference target2="reference.RFC.0604.xml" anchor="RFC0604">
<front>
<title>Assigned link numbers</title>
<author fullname="Jon Postel" initials="J." surname="Postel">
<organization>The MITRE Corporation</organization>
</author>

<date year="1973" day="26" month="December" />
</front>

<seriesInfo value="604" name="RFC" />
</reference>


<reference target2="reference.RFC.0606.xml" anchor="RFC0606">
<front>
<title>Host names on-line</title>
<author fullname="L. Peter Deutsch" initials="L." surname="Deutsch">
<organization>Xerox Palo Alto Research Center (PARC), MAXC</organization>
</author>

<date year="1973" day="29" month="December" />
</front>

<seriesInfo value="606" name="RFC" />
</reference>


<reference target2="reference.RFC.0607.xml" anchor="RFC0607">
<front>
<title>Comments on the File Transfer Protocol</title>
<author fullname="Mark Krilanovich" initials="M." surname="Krilanovich">
<organization>University of California, Santa Barbara (UCSB)</organization>
</author>

<author fullname="George Gregg" initials="G." surname="Gregg">
<organization>University of California, Santa Barbara (UCSB)</organization>
</author>

<date year="1974" day="7" month="January" />

<abstract>
<t>There are several aspects of the File Transfer Protocol that constitute serious drawbacks.</t>
</abstract>
</front>

<seriesInfo value="607" name="RFC" />
</reference>


<reference target2="reference.RFC.0608.xml" anchor="RFC0608">
<front>
<title>Host names on-line</title>
<author fullname="M. D. Kudlick" initials="M." surname="Kudlick">
<organization>Stanford Research Institute (SRI), Augmentation Research Center (ARC)</organization>
</author>

<date year="1974" day="10" month="January" />

<abstract>
<t>We at the NIC agree with Peter Deutsch's suggestion (in RFC# 606 / NIC# 21246) that the NIC maintain an online ASCII text file of Host names, addresses, and attributes.</t>
</abstract>
</front>

<seriesInfo value="608" name="RFC" />
</reference>


<reference target2="reference.RFC.0609.xml" anchor="RFC0609">
<front>
<title abbrev="Upcoming Move of NIC/NLS Services">Statement of upcoming move of NIC/NLS service</title>
<author fullname="Bill Ferguson" initials="B." surname="Ferguson">
<organization>Stanford Research Institute (SRI), Augmentation Research Center (ARC)</organization>
</author>

<date year="1974" day="10" month="January" />

<abstract>
<t>Within the next few weeks we will be transferring computer services for our ROME, ARPA, and NIC users from the ARC/NIC system to a new system we are installing at TYMSHARE in Cupertino, Ca.</t>
</abstract>
</front>

<seriesInfo value="609" name="RFC" />
</reference>


<reference target2="reference.RFC.0610.xml" anchor="RFC0610">
<front>
<title>Further datalanguage design concepts</title>
<author fullname="Richard Winter" initials="R." surname="Winter">
<organization>Computer Corporation of America (CCA)</organization>
</author>

<author fullname="Jeffrey Hill" initials="J." surname="Hill">
<organization>Computer Corporation of America (CCA)</organization>
</author>

<author fullname="Warren Greiff" initials="W." surname="Greiff">
<organization>Computer Corporation of America (CCA)</organization>
</author>

<date year="1973" day="15" month="December" />
</front>

<seriesInfo value="610" name="RFC" />
</reference>


<reference target2="reference.RFC.0611.xml" anchor="RFC0611">
<front>
<title abbrev="Changes to IMP/Host Protocol">Two changes to the IMP/Host Protocol to improve user/network communications</title>
<author fullname="D. Walden" initials="D." surname="Walden">
<organization>Bolt Beranek and Newman Inc. (BBN), Network Control Center (NET)</organization>
</author>

<date year="1974" day="14" month="February" />
</front>

<seriesInfo value="611" name="RFC" />
</reference>


<reference target2="reference.RFC.0612.xml" anchor="RFC0612">
<front>
<title>Traffic statistics (December 1973)</title>
<author fullname="A. McKenzie" initials="A." surname="McKenzie">
<organization>Bolt Beranek and Newman Inc. (BBN), Network Control Center (NET)</organization>
</author>

<date year="1974" day="16" month="January" />
</front>

<seriesInfo value="612" name="RFC" />
</reference>


<reference target2="reference.RFC.0613.xml" anchor="RFC0613">
<front>
<title>Network connectivity: A response to RFC 603</title>
<author fullname="Alex McKenzie" initials="A." surname="McKenzie">
<organization>Bolt Baranek and Newman, Network Control Center (BBN), NET</organization>
</author>

<date year="1974" day="21" month="January" />
</front>

<seriesInfo value="613" name="RFC" />
</reference>


<reference target2="reference.RFC.0614.xml" anchor="RFC0614">
<front>
<title>Response to RFC 607: "Comments on the File Transfer Protocol"</title>
<author fullname="K. Pogran" initials="K." surname="Pogran">
<organization>Massachusetts Institute of Technology (MIT), Multics</organization>
</author>

<author fullname="N. Neigus" initials="N." surname="Neigus">
<organization>Bolt Beranek and Newman Inc. (BBN), Network Control Center (NET)</organization>
</author>

<date year="1974" day="28" month="January" />
</front>

<seriesInfo value="614" name="RFC" />
</reference>


<reference target2="reference.RFC.0615.xml" anchor="RFC0615">
<front>
<title>Proposed Network Standard Data Pathname syntax</title>
<author fullname="D. Crocker" initials="D." surname="Crocker">
<organization>University of California, Los Angeles (UCLA), NMC</organization>
</author>

<date year="1974" day="1" month="March" />

<abstract>
<t>There seems to be an increasing call for a Network Standard Data Pathname (NSDP); that is, a standardized means of referring to a specific location for/of a collection of bits somewhere on the Network.</t>
</abstract>
</front>

<seriesInfo value="615" name="RFC" />
</reference>


<reference target2="reference.RFC.0616.xml" anchor="RFC0616">
<front>
<title>Latest network maps</title>
<author fullname="D.C. Walden" initials="D.C." surname="Walden">
<organization />
</author>

<date year="1973" day="11" month="February" />
</front>

<seriesInfo value="616" name="RFC" />
</reference>


<reference target2="reference.RFC.0617.xml" anchor="RFC0617">
<front>
<title>Note on socket number assignment</title>
<author fullname="Edward Taft" initials="E." surname="Taft">
<organization>Xerox Palo Alto Research Center (PARC), MAXC</organization>
</author>

<date year="1974" day="19" month="February" />
</front>

<seriesInfo value="617" name="RFC" />
</reference>


<reference target2="reference.RFC.0618.xml" anchor="RFC0618">
<front>
<title>Few observations on NCP statistics</title>
<author fullname="Edward Taft" initials="E." surname="Taft">
<organization>Xerox Palo Alto Research Center (PARC), MAXC</organization>
</author>

<date year="1974" day="19" month="February" />

<abstract>
<t>The NCP in use at HARV-10, CMU-10A, and CMU-10B collects a number of operating and error statistics, which may be typed out on demand by any user by means of the 'IMP ERROR' command, as shown on the sample typescript.</t>
</abstract>
</front>

<seriesInfo value="618" name="RFC" />
</reference>


<reference target2="reference.RFC.0619.xml" anchor="RFC0619">
<front>
<title>Mean round-trip times in the ARPANET</title>
<author fullname="W. Naylor" initials="W." surname="Naylor">
<organization>University of California, Los Angeles (UCLA), New Media Centers (NMC)</organization>
</author>

<author fullname="H. Opderbeck" initials="H." surname="Opderbeck">
<organization>University of California, Los Angeles (UCLA), New Media Centers (NMC)</organization>
</author>

<date year="1974" day="7" month="March" />

<abstract>
<t>In one of our current measurement projects we are interested in the average values of important network parameters.  For this purpose we collect data on the network activity over seven consecutive days.  This data collection is only interrupted by down-time or maintenance of either the net or our collecting facility (the "late" Sigma-7 or, in future, the 360/91 at CCN).</t>
</abstract>
</front>

<seriesInfo value="619" name="RFC" />
</reference>


<reference target2="reference.RFC.0620.xml" anchor="RFC0620">
<front>
<title>Request for monitor host table updates</title>
<author fullname="Bill Ferguson" initials="B." surname="Ferguson">
<organization>Stanford Research Institute (SRI) International,  Augmentation Research Center (ARC)</organization>
</author>

<date year="1974" day="1" month="March" />
</front>

<seriesInfo value="620" name="RFC" />
</reference>


<reference target2="reference.RFC.0621.xml" anchor="RFC0621">
<front>
<title>NIC user directories at SRI ARC</title>
<author fullname="Michael D. Kudlick" initials="M." surname="Kudlick">
<organization>Stanford Research Intitute (SRI), Augmentation Research Center (ARC)</organization>
</author>

<date year="1974" day="6" month="March" />
</front>

<seriesInfo value="621" name="RFC" />
</reference>


<reference target2="reference.RFC.0622.xml" anchor="RFC0622">
<front>
<title>Scheduling IMP/TIP down time</title>
<author fullname="Alex McKenzie" initials="A." surname="McKenzie">
<organization>Bolt Beranek and Newman Inc. (BBN), Network Control Center (NET)</organization>

<address>
<postal>
<street>50 Moulton Street</street>
<city>Cambridge</city>
<region>MA</region>
<code>02138</code>
<country>US</country>
</postal>

</address>
</author>

<date year="1974" day="13" month="March" />

<abstract>
<t>From time to time it is necessary for an IMP or TIP to be taken down other than during its scheduled Preventive Maintenance period.  Examples of such cases are retrofit programs and the off-line diagnosis and repair of intermittent problems. In the past we have scheduled these downs with our "primary site contact" at the affected site; in our view this individual was responsible for representing all of the hosts (and TIP users) connected to that IMP/TIP. Although this policy has worked well in the past, the recent proliferation of Very Distant Hosts, together with complaints from representatives of other (local or distant) Hosts, has caused us to review our procedures.</t>
</abstract>
</front>

<seriesInfo value="622" name="RFC" />
</reference>


<reference target2="reference.RFC.0623.xml" anchor="RFC0623">
<front>
<title>Comments on on-line host name service</title>
<author fullname="Mark Krilanovich" initials="M." surname="Krilanovich">
<organization>University of California, Santa Barbara (UCSB)</organization>
</author>

<date year="1974" day="22" month="February" />

<abstract>
<t>Peter Deutsch in RFC #606 pointed out the desirability of having a single host maintain a data base containing official host names and host addresses, as well as other information of secondary importance.  Mike Kudlick in RFC #608 agreed with the concept, and proposed that the NIC would implement Peter's ideas.  I would like to add my voice to those in support of such a service, and express a few ideas for its modification.</t>
</abstract>
</front>

<seriesInfo value="623" name="RFC" />
</reference>


<reference target2="reference.RFC.0624.xml" anchor="RFC0624">
<front>
<title>Comments on the File Transfer Protocol</title>
<author fullname="Mark Krilanovich" initials="M." surname="Krilanovich">
<organization>University of California, Santa Barbara (UCSB)</organization>
</author>

<author fullname="George Gregg" initials="G." surname="Gregg">
<organization>University of California, Santa Barbara (UCSB)</organization>
</author>

<author fullname="Wayne Hathaway" initials="W." surname="Hathaway">
<organization>AMES Research Center (AMES-67)</organization>
</author>

<author fullname="Jim White" initials="J." surname="White">
<organization>Stanford Research Institute (SRI), Augmentation Research Center (ARC)</organization>
</author>

<date year="1974" day="28" month="February" />

<abstract>
<t>There are several aspects of the File Transfer Protocol of RFC 542 that constitute serious drawbacks. Some of these are quite basic in nature, and imply substantial design changes; these will be discussed in a later RFC. Others could be remedied with very little effort, and this should be done as soon as possible.</t>
</abstract>
</front>

<seriesInfo value="624" name="RFC" />
</reference>


<reference target2="reference.RFC.0625.xml" anchor="RFC0625">
<front>
<title>On-line hostnames service</title>
<author fullname="Mike Kudlick" initials="M." surname="Kudlick">
<organization>Stanford Research Institute (SRI) International,  Augmentation Research Center
(ARC)</organization>
</author>

<author fullname="Jake Feinler" initials="J." surname="Feinler">
<organization>Stanford Research Institute (SRI) International,  Augmentation Research Center
(ARC)</organization>
</author>

<author fullname="Alex McKenzie" initials="A." surname="McKenzie">
<organization />
</author>

<date year="1974" day="7" month="March" />

<abstract>
<t>We agree with the suggestion in RFC 623 that more than one Host should be responsible for maintaining a copy of the Hostnames data base. The NIC is certainly willing to continue to maintain the master data base, and make it available to any secondary Host that volunteers to maintain a copy. We would be pleased to have UCSB serve as one of the secondary Hosts.</t>
</abstract>
</front>

<seriesInfo value="625" name="RFC" />
</reference>


<reference target2="reference.RFC.0626.xml" anchor="RFC0626">
<front>
<title>On a possible lockup condition in IMP subnet due to message sequencing</title>
<author fullname="L. Kleinrock" initials="L." surname="Kleinrock">
<organization>University of Los Angeles (UCLA), New Media Centers (NMC)</organization>
</author>

<author fullname="H. Opderbeck" initials="H." surname="Opderbeck">
<organization>University of Los Angeles (UCLA), New Media Centers (NMC)</organization>
</author>

<date year="1974" day="14" month="March" />

<abstract>
<t>Lockup or deadlock conditions are one of the most serious system malfunctions that can occur in a computer system or network.  Communication protocols have to be designed very carefully to avoid the occurrence of these lockups.  Their common characteristic is that they occur only under unusual circumstances which were not foreseen or deemed too unlikely to occur by the protocol designers.  (However, these designers often are not the ones in a position to evaluate such likelihoods quantitatively.)</t>
</abstract>
</front>

<seriesInfo value="626" name="RFC" />
</reference>


<reference target2="reference.RFC.0627.xml" anchor="RFC0627">
<front>
<title>ASCII text file of hostnames</title>
<author fullname="Mike Kudlick" initials="M." surname="Kudlick">
<organization>Stanford Research Institute (SRI) International,  Augmentation Research Center (ARC)</organization>
</author>

<author fullname="Jake Feinler" initials="J." surname="Feinler">
<organization>Stanford Research Institute (SRI) International,  Augmentation Research Center (ARC)</organization>

<address>
<postal>
<street />
<city>Menlo Park</city>
<region>CA</region>
<code>94025</code>
<country>US</country>
</postal>

<phone>+1 415 329 0742</phone>
<email>Feinler@SRI-ARC</email>
</address>
</author>

<date year="1974" day="25" month="March" />

<abstract>
<t>The online ASCII text file of official hostnames as defined in RFCs 606 and 608 is now available at OFFICE-1 (Hostaddr. 43 decimal) with pathname NETINFOHOSTS.TXT.  Currently the file includes hostname, host address, and host status.  We hope to be adding additional attributes soon. This file will be maintained by the NIC, and all hosts are encouraged to use these hostnames in their monitors.  Changes or additions will be added on a weekly basis.  Each network host will be responsible for accessing this file via FTP for new information.</t>
</abstract>
</front>

<seriesInfo value="627" name="RFC" />
</reference>


<reference target2="reference.RFC.0628.xml" anchor="RFC0628">
<front>
<title>Status of RFC numbers and a note on pre-assigned journal numbers</title>
<author fullname="Marcia L. Keeney" initials="M." surname="Keeney">
<organization>Stanford Research Institute (SRI), Augmentation Research Center (ARC)</organization>
</author>

<date year="1974" day="27" month="March" />
</front>

<seriesInfo value="628" name="RFC" />
</reference>


<reference target2="reference.RFC.0629.xml" anchor="RFC0629">
<front>
<title abbrev="Using the Network Journal">Scenario for using the Network Journal</title>
<author fullname="Jeanne North" initials="J." surname="North">
<organization>Stanford Research Institute (SRI), Augmentation Research Center (ARC)</organization>
</author>

<date year="1974" day="27" month="March" />

<abstract>
<t>Network users may send mail to individuals and to groups, input as messages or entire files, through the Network Journal, using SNDMSG or their site's mail system.  The mail is converted at NIC into NLS files, Journalized, and sent to specified recipients.  Short messages may be received as messages, longer ones as citations to files which may be retrieved immediately, and also later, by using FTP.  Mail sent to NIC with a "/" in the user-name field invokes the Net Journal.</t>
</abstract>
</front>

<seriesInfo value="629" name="RFC" />
</reference>


<reference target2="reference.RFC.0630.xml" anchor="RFC0630">
<front>
<title abbrev="FTP Error Code Usage for Mail Service">FTP error code usage for more reliable mail service</title>
<author fullname="Julie Sussman" initials="J." surname="Sussman">
<organization>Bolt Beranek and Newman (BBN)</organization>
</author>

<date year="1974" day="10" month="April" />
</front>

<seriesInfo value="630" name="RFC" />
</reference>


<reference target2="reference.RFC.0631.xml" anchor="RFC0631">
<front>
<title abbrev="Mini-Computers and Data Communication">International meeting on minicomputers and data communication: Call for papers</title>
<author fullname="A. Danthine" initials="A." surname="Danthine">
<organization>Universite de Liege</organization>

<address>
<postal>
<street>49 Avenue des Tilleuls</street>
<city>Liege</city>
<region />
<code>B-4000</code>
<country>BE</country>
</postal>

</address>
</author>

<date year="1974" day="17" month="April" />

<abstract>
<t>The "Association des Ingenieurs Electriciens sortis de l'Institut Electrotechnique Montefiore A.I.M.)" organizes a meeting on "Mini-Computers and Data Communication" in Liege from January 20 to January-22, 1975.</t>
</abstract>
</front>

<seriesInfo value="631" name="RFC" />
</reference>


<reference target2="reference.RFC.0632.xml" anchor="RFC0632">
<front>
<title>Throughput degradations for single packet messages</title>
<author fullname="H. Opderbeck" initials="H." surname="Opderbeck">
<organization>University of California, Los Angeles (UCLA), NMC</organization>
</author>

<date year="1974" day="20" month="May" />

<abstract>
<t>The transmission of digitized speech over the ARPANET represents a new dimension in the use of packet switching systems.  The throughput and delay requirements for this newly emerging application area are quite different from the throughput and delay requirements for interactive use or file transfers.  In particular, we need to achieve a high throughput for small messages since long messages result in long source delays to fill the large buffers.  Therefore we are currently studying the throughput limits for single-packet messages.  We realize that up to now little attempt was made to optimize throughput for low delay traffic. It was nevertheless surprising for us to find out that the observed throughput for single-packet messages is in many cases only about one fourth of what one would expect.  In what follows we are going to explain why this happens and what could be done to correct this situation.</t>
</abstract>
</front>

<seriesInfo value="632" name="RFC" />
</reference>


<reference target2="reference.RFC.0633.xml" anchor="RFC0633">
<front>
<title>IMP/TIP preventive maintenance schedule</title>
<author fullname="A. McKenzie" initials="A." surname="McKenzie">
<organization>Bolt Beranek and Newman (BBN), NET</organization>
</author>

<date year="1974" day="18" month="March" />

<abstract>
<t>This note presents the current IMP/TIP Preventive Maintenance schedule. Preventive Maintenance is scheduled on a monthly basis and a given machine is normally scheduled at the same time each month; wherever possible the time is chosen to coincide with the PM time for the Host(s) at the site.</t>
</abstract>
</front>

<seriesInfo value="633" name="RFC" />
</reference>


<reference target2="reference.RFC.0634.xml" anchor="RFC0634">
<front>
<title>Change in network address for Haskins Lab</title>
<author fullname="Alex McKenzie" initials="A." surname="McKenzie">
<organization>Bolt Beranek and Newman (BBN), NET</organization>
</author>

<date year="1974" day="10" month="April" />

<abstract>
<t>Sometime between May 8 and May 22, probably toward the end of that period, the Haskins Laboratory "Very Distant Host" connection will be moved from BBN (IMP #5) to Harvard (IMP #9).  The Host Number of the Haskins machine will remain Host 3 (numbering from zero to three). Thus, the Network Address of the Haskins Laboratory Host will change from 197 to 201.  Since the date of the change is dependent on installation of new circuits by the local telephone company, I am unable to give the actual date more precisely.</t>
</abstract>
</front>

<seriesInfo value="634" name="RFC" />
</reference>


<reference target2="reference.RFC.0635.xml" anchor="RFC0635">
<front>
<title>Assessment of ARPANET protocols</title>
<author fullname="V. Cerf" initials="V." surname="Cerf">
<organization />
</author>

<date year="1974" day="22" month="April" />
</front>

<seriesInfo value="635" name="RFC" />
</reference>


<reference target2="reference.RFC.0636.xml" anchor="RFC0636">
<front>
<title>TIP/Tenex reliability improvements</title>
<author fullname="J. Burchfiel" initials="J." surname="Burchfiel">
<organization>Bolt Beranek and Newman (BBN), TENEX</organization>
</author>

<author fullname="B. Cosell" initials="B." surname="Cosell">
<organization>Bolt Beranek and Newman (BBN), NET</organization>
</author>

<author fullname="R. Tomlinson" initials="R." surname="Tomlinson">
<organization>Bolt Beranek and Newman (BBN), TENEX</organization>
</author>

<author fullname="D. Walden" initials="D." surname="Walden">
<organization>Bolt Beranek and Newman (BBN), NET</organization>
</author>

<date year="1974" day="10" month="June" />

<abstract>
<t>During the past months we have felt strong pressure to improve the reliability of TIP/TENEX network connection as improvement in the reliability of users' connections between TENEXs and TIPs would have major impact on the appearance of overall network reliability due to the large number and high visibility of TENEXs and TIPs.  Despite the emphasis on TIP/TENEX interaction, all work done applies equally well to interactions between Hosts of any type.</t>
</abstract>
</front>

<seriesInfo value="636" name="RFC" />
</reference>


<reference target2="reference.RFC.0637.xml" anchor="RFC0637">
<front>
<title>Change of network address for SU-DSL</title>
<author fullname="Alex A. McKenzie" initials="A." surname="McKenzie">
<organization>Bolt Baranek and Newman (BBN), NET</organization>
</author>

<date year="1974" day="23" month="April" />

<abstract>
<t>Effective immediately, the Host at Stanford Electronics Research Lab. (SU-DSL), a Very Distant Host connected to the SRI IMP, has its address changed from IMP 2, Host 2, to IMP 2 Host 3.  Thus its "Network Address" is changed from 130 to 194.</t>

<t>Host 2 on IMP 2 will eventually be a PDP-11 operated by the SRI Artificial Intelligence Center.</t>
</abstract>
</front>

<seriesInfo value="637" name="RFC" />
</reference>


<reference target2="reference.RFC.0638.xml" anchor="RFC0638">
<front>
<title>IMP/TIP preventive maintenance schedule</title>
<author fullname="Alex A. McKenzie" initials="A.A." surname="McKenzie">
<organization>Bolt Baranek and Newman (BBN), NET</organization>
</author>

<date year="1974" day="25" month="April" />

<abstract>
<t>This note presents the current IMP/TIP Preventive Maintenance schedule.  Preventive Maintenance is scheduled on a monthly basis and a given machine is normally scheduled at the same time each month; wherever possible the time is chosen to coincide with the PM time for the Host(s) at the site.</t>
</abstract>
</front>

<seriesInfo value="638" name="RFC" />
</reference>


<reference target2="reference.RFC.0640.xml" anchor="RFC0640">
<front>
<title abbrev="Revised FTP Reply Codes">Revised FTP reply codes</title>
<author fullname="Nancy Neigus" initials="N." surname="Neigus">
<organization />
</author>

<author fullname="Ken Pogran" initials="K." surname="Pogran">
<organization />
</author>

<author fullname="Jon Postel" initials="J." surname="Postel">
<organization />
</author>

<date year="1974" day="19" month="June" />

<abstract>
<t>This document describes a revised set of reply codes for the File Transfer Protocol.</t>
</abstract>
</front>

<seriesInfo value="640" name="RFC" />
</reference>


<reference target2="reference.RFC.0642.xml" anchor="RFC0642">
<front>
<title>Ready line philosophy and implementation</title>
<author fullname="Jerry Burchfiel" initials="J." surname="Burchfiel">
<organization>Bolt Baranek and Newman (BBN)</organization>
</author>

<date year="1974" day="5" month="July" />
</front>

<seriesInfo value="642" name="RFC" />
</reference>


<reference target2="reference.RFC.0643.xml" anchor="RFC0643">
<front>
<title>Network Debugging Protocol</title>
<author fullname="Eric Mader" initials="E." surname="Mader">
<organization />
</author>

<date year="1974" day="1" month="July" />

<abstract>
<t>This document describes a proposed protocol  to be used  in an implementation of a PDP-11 network  Bootstrap service and a cross-network debugger.  The  protocol  is designed  for debugging processes  running under an operating system which can perform some of the "lower level" debugging  tasks,  such  as  planting and removing breakpoints  and  single  stepping.  A subset of the protocol could be used if such a capability does not exist (a  stand-alone  program  for example).</t>
</abstract>
</front>

<seriesInfo value="643" name="RFC" />
</reference>


<reference target2="reference.RFC.0644.xml" anchor="RFC0644">
<front>
<title>On the problem of signature authentication for network mail</title>
<author fullname="Bob Thomas" initials="B." surname="Thomas">
<organization>Bolt Baranek and Newman (BBN), TENEX</organization>
</author>

<date year="1974" day="22" month="July" />

<abstract>
<t>This note describes the problem of signature authentication for network mail, presents a general approach to the problem and proposes a specific implementation of that approach.</t>
</abstract>
</front>

<seriesInfo value="644" name="RFC" />
</reference>


<reference target2="reference.RFC.0645.xml" anchor="RFC0645">
<front>
<title>Network Standard Data Specification syntax</title>
<author fullname="D. Crocker" initials="D." surname="Crocker">
<organization />
</author>

<date year="1974" day="26" month="June" />
</front>

<seriesInfo value="645" name="RFC" />
</reference>


<reference target2="reference.RFC.0647.xml" anchor="RFC0647">
<front>
<title>Proposed protocol for connecting host computers to ARPA-like networks via front end processors</title>
<author fullname="M.A. Padlipsky" initials="M.A." surname="Padlipsky">
<organization />
</author>

<date year="1974" day="12" month="November" />
</front>

<seriesInfo value="647" name="RFC" />
</reference>


<reference target2="reference.RFC.0651.xml" anchor="RFC0651">
<front>
<title>Revised Telnet status option</title>
<author fullname="D. Crocker" initials="D." surname="Crocker">
<organization>University of California, Los Angeles (UCLA), NMC</organization>
</author>

<date year="1974" day="25" month="October" />
</front>

<seriesInfo value="651" name="RFC" />
</reference>


<reference target2="reference.RFC.0652.xml" anchor="RFC0652">
<front>
<title>Telnet output carriage-return disposition option</title>
<author fullname="D. Crocker" initials="D." surname="Crocker">
<organization>University of California, Los Angeles (UCLA), NMC</organization>
</author>

<date year="1974" day="25" month="October" />
</front>

<seriesInfo value="652" name="RFC" />
</reference>


<reference target2="reference.RFC.0653.xml" anchor="RFC0653">
<front>
<title>Telnet output horizontal tabstops option</title>
<author fullname="D. Crocker" initials="D." surname="Crocker">
<organization>University of California, Los Angeles (UCLA), NMC</organization>
</author>

<date year="1974" day="25" month="October" />
</front>

<seriesInfo value="653" name="RFC" />
</reference>


<reference target2="reference.RFC.0654.xml" anchor="RFC0654">
<front>
<title>Telnet output horizontal tab disposition option</title>
<author fullname="D. Crocker" initials="D." surname="Crocker">
<organization>University of California, Los Angeles (UCLA), NMC</organization>
</author>

<date year="1974" day="25" month="October" />
</front>

<seriesInfo value="654" name="RFC" />
</reference>


<reference target2="reference.RFC.0655.xml" anchor="RFC0655">
<front>
<title>Telnet output formfeed disposition option</title>
<author fullname="D. Crocker" initials="D." surname="Crocker">
<organization>University of California, Los Angeles (UCLA), NMC</organization>
</author>

<date year="1974" day="25" month="October" />
</front>

<seriesInfo value="655" name="RFC" />
</reference>


<reference target2="reference.RFC.0656.xml" anchor="RFC0656">
<front>
<title>Telnet output vertical tabstops option</title>
<author fullname="D. Crocker" initials="D." surname="Crocker">
<organization>University of California, Los Angeles (UCLA), NMC</organization>
</author>

<date year="1974" day="25" month="October" />
</front>

<seriesInfo value="656" name="RFC" />
</reference>


<reference target2="reference.RFC.0657.xml" anchor="RFC0657">
<front>
<title>Telnet output vertical tab disposition option</title>
<author fullname="D. Crocker" initials="D." surname="Crocker">
<organization>University of California, Los Angeles (UCLA), NMC</organization>
</author>

<date year="1974" day="25" month="October" />
</front>

<seriesInfo value="657" name="RFC" />
</reference>


<reference target2="reference.RFC.0658.xml" anchor="RFC0658">
<front>
<title>Telnet output linefeed disposition</title>
<author fullname="D. Crocker" initials="D." surname="Crocker">
<organization>University of California, Los Angeles (UCLA), NMC</organization>
</author>

<date year="1974" day="25" month="October" />
</front>

<seriesInfo value="658" name="RFC" />
</reference>


<reference target2="reference.RFC.0659.xml" anchor="RFC0659">
<front>
<title>Announcing additional Telnet options</title>
<author fullname="J. Postel" initials="J." surname="Postel">
<organization />
</author>

<date year="1974" day="18" month="October" />
</front>

<seriesInfo value="659" name="RFC" />
<format octets="2016" type="TXT" target="ftp://ftp.isi.edu/in-notes/rfc659.txt" />
</reference>


<reference target2="reference.RFC.0660.xml" anchor="RFC0660">
<front>
<title>Some changes to the IMP and the IMP/Host interface</title>
<author fullname="D. Walden" initials="D." surname="Walden">
<organization>Bolt Baranek and Newman (BBN), NET</organization>
</author>

<date year="1974" day="23" month="October" />

<abstract>
<t>In the next few weeks several changes will be made to the IMP software including changes to the IMP/Host software interface as specified in BBN Report No. 1822, Specifications for the Interconnection of a Host and an IMP. These changes come in four areas: a) decoupling of the message number sequences of Hosts; b) Host/Host access control; c) expansion of the message number window from four to eight; and d) provision for messages outside the normal message number mechanism. All changes are backward compatible with possible minor exceptions in timing.</t>
</abstract>
</front>

<seriesInfo value="660" name="RFC" />
</reference>


<reference target2="reference.RFC.0661.xml" anchor="RFC0661">
<front>
<title>Protocol information</title>
<author fullname="J. Postel" initials="J." surname="Postel">
<organization />
</author>

<date year="1974" day="23" month="November" />
</front>

<seriesInfo value="661" name="RFC" />
</reference>


<reference target2="reference.RFC.0662.xml" anchor="RFC0662">
<front>
<title>Performance improvement in ARPANET file transfers from Multics</title>
<author fullname="Raj Kanodia" initials="R." surname="Kanodia">
<organization>Massachusetts Institute of Technology (MIT), Project MAC</organization>
</author>

<date year="1974" day="26" month="November" />

<abstract>
<t>With the growth of Multics usage in the ARPA Network community, users often need to transfer large amounts of data from Multics to other systems. However, Multics performance in this area has been less than optimal and there clearly exists a need to improve the situation. Even within Project MAC there are users who regularly ship files back and forth between Multics and other Project MAC computer systems. Recently the Cambridge Information Systems Laboratory (CISL) development Multics system was connected to the ARPA Network. This has generated considerable interest among the members of the CSR (Computer Systems Research) and CISL groups in using the Multics file transfer facility for transmission of Multics system tapes (MST) from one Multics system to the other. At currently realizable data transfer rates, transmission of a typical MST, (approximately 12 million bits), takes about half an hour. The usefulness of the present file transfer system is severely limited by its low bandwidth.</t>

<t>One of the reasons for such a poor performance is the output buffering strategy in the Multics IMP DIM (IMP Device Interface Manager.) With the hope of making a significant performance improvement, we recently changed the IMP DIM buffering strategy. To assess the effects of this change an experiment was conducted between the service machine (MIT Multics) and the development machine (CISL Multics.) This memo reports the experiment and its results.</t>
</abstract>
</front>

<seriesInfo value="662" name="RFC" />
</reference>


<reference target2="reference.RFC.0663.xml" anchor="RFC0663">
<front>
<title>Lost message detection and recovery protocol</title>
<author fullname="Rajendra K. Kanodia" initials="R." surname="Kanodia">
<organization>Massachusetts Institute of Technology (MIT), Project MAC</organization>
</author>

<date year="1974" day="29" month="November" />
</front>

<seriesInfo value="663" name="RFC" />
</reference>


<reference target2="reference.RFC.0666.xml" anchor="RFC0666">
<front>
<title>Specification of the Unified User-Level Protocol</title>
<author fullname="M.A. Padlipsky" initials="M.A." surname="Padlipsky">
<organization />
</author>

<date year="1974" day="26" month="November" />
</front>

<seriesInfo value="666" name="RFC" />
</reference>


<reference target2="reference.RFC.0667.xml" anchor="RFC0667">
<front>
<title>BBN host ports</title>
<author fullname="S.G. Chipman" initials="S.G." surname="Chipman">
<organization />
</author>

<date year="1974" day="17" month="December" />
</front>

<seriesInfo value="667" name="RFC" />
</reference>


<reference target2="reference.RFC.0669.xml" anchor="RFC0669">
<front>
<title abbrev="Survey of New-Protocol TELNET Servers">November, 1974, survey of New-Protocol Telnet servers</title>
<author fullname="D. W. Dodds" initials="D." surname="Dodds">
<organization>Bolt Baranek and Newman (BBN), TENEXA</organization>
</author>

<date year="1974" day="4" month="December" />
</front>

<seriesInfo value="669" name="RFC" />
</reference>


<reference target2="reference.RFC.0671.xml" anchor="RFC0671">
<front>
<title>Note on Reconnection Protocol</title>
<author fullname="R. Schantz" initials="R." surname="Schantz">
<organization />
</author>

<date year="1974" day="6" month="December" />
</front>

<seriesInfo value="671" name="RFC" />
</reference>


<reference target2="reference.RFC.0672.xml" anchor="RFC0672">
<front>
<title>Multi-site data collection facility</title>
<author fullname="Richard Schantz" initials="R." surname="Schantz">
<organization>Bolt Baranek and Newman (BBN), TENEX</organization>
</author>

<date year="1974" day="6" month="December" />
</front>

<seriesInfo value="672" name="RFC" />
</reference>


<reference target2="reference.RFC.0674.xml" anchor="RFC0674">
<front>
<title abbrev="PCP Announcement">Procedure call documents: Version 2</title>
<author fullname="Jon Postel" initials="J." surname="Postel">
<organization>Stanford Research Institute (SRI) International,  Augmentation Research Center (ARC)</organization>

<address>
<postal>
<street />
<city>Menlo Park</city>
<region>CA</region>
<code>94025</code>
<country>US</country>
</postal>

<phone>+1 415 326 6200 x3718</phone>
<email>POSTEL@SRI-ARC</email>
</address>
</author>

<author fullname="James E. White" initials="J." surname="White">
<organization>Stanford Research Institute (SRI) International,  Augmentation Research Center (ARC)</organization>

<address>
<postal>
<street />
<city>Menlo Park</city>
<region>CA</region>
<code>94025</code>
<country>US</country>
</postal>

<phone>+1 415 326 6200 x2960</phone>
<email>WHITE@SRI-ARC</email>
</address>
</author>

<date year="1974" day="12" month="December" />

<abstract>
<t>As many of you may know SRI is part of a team working on the National Software Works project. In the course of our work we have developed a Procedure Call Protocol to be used between the modules which make up the NSW.</t>
</abstract>
</front>

<seriesInfo value="674" name="RFC" />
</reference>


<reference target2="reference.RFC.0675.xml" anchor="RFC0675">
<front>
<title abbrev="Specification of Internet TCP">Specification of Internet Transmission Control Program</title>
<author fullname="Vinton Cerf" initials="V." surname="Cerf">
<organization />
</author>

<author fullname="Yogen Dalal" initials="Y." surname="Dalal">
<organization />
</author>

<author fullname="Carl Sunshine" initials="C." surname="Sunshine">
<organization />
</author>

<date year="1974" day="1" month="December" />
</front>

<seriesInfo value="675" name="RFC" />
</reference>


<reference target2="reference.RFC.0677.xml" anchor="RFC0677">
<front>
<title>Maintenance of duplicate databases</title>
<author fullname="Paul R. Johnson" initials="P." surname="Johnson">
<organization>Bolt Baranek and Newman (BBN), TENEX</organization>
</author>

<author fullname="Robert H. Thomas" initials="R." surname="Thomas">
<organization>Bolt Baranek and Newman (BBN),  TENEX</organization>
</author>

<date year="1975" day="27" month="January" />
</front>

<seriesInfo value="677" name="RFC" />
</reference>


<reference target2="reference.RFC.0678.xml" anchor="RFC0678">
<front>
<title>Standard file formats</title>
<author fullname="J. Postel" initials="J." surname="Postel">
<organization>Stanford Research Institute (SRI) International,  Augmentation Research Center (ARC)</organization>
</author>

<date year="1974" day="19" month="December" />
</front>

<seriesInfo value="678" name="RFC" />
</reference>


<reference target2="reference.RFC.0679.xml" anchor="RFC0679">
<front>
<title>February, 1975, survey of New-Protocol Telnet servers</title>
<author fullname="D.W. Dodds" initials="D.W." surname="Dodds">
<organization />
</author>

<date year="1975" day="21" month="February" />
</front>

<seriesInfo value="679" name="RFC" />
</reference>


<reference target2="reference.RFC.0680.xml" anchor="RFC0680">
<front>
<title>Message Transmission Protocol</title>
<author fullname="T.H. Myer" initials="T.H." surname="Myer">
<organization />
</author>

<author fullname="D.A. Henderson" initials="D.A." surname="Henderson">
<organization />
</author>

<date year="1975" day="30" month="April" />
</front>

<seriesInfo value="680" name="RFC" />
</reference>


<reference target2="reference.RFC.0681.xml" anchor="RFC0681">
<front>
<title>Network UNIX</title>
<author fullname="Steve Holmgren" initials="S." surname="Holmgren">
<organization>University Of Illinois</organization>

<address>
<postal>
<street>210 Advanced Computation Bldg.</street>
<city>Urbana</city>
<region>IL</region>
<code>61801</code>
<country>US</country>
</postal>

<phone>+1 217 333 8469</phone>
<email>HOLMGREN@BBN</email>
</address>
</author>

<date year="1975" day="18" month="March" />
</front>

<seriesInfo value="681" name="RFC" />
</reference>


<reference target2="reference.RFC.0683.xml" anchor="RFC0683">
<front>
<title>FTPSRV - Tenex extension for paged files</title>
<author fullname="R. Clements" initials="R." surname="Clements">
<organization>Bolt Beranek and Newman (BBN)</organization>
</author>

<date year="1975" day="3" month="April" />
</front>

<seriesInfo value="683" name="RFC" />
</reference>


<reference target2="reference.RFC.0684.xml" anchor="RFC0684">
<front>
<title abbrev="A COMMENTARY on PROCEDURE CALLING">Commentary on procedure calling as a network protocol</title>
<author fullname="Richard Schantz" initials="R." surname="Schantz">
<organization>Bolt Baranek and Newman (BBN), TENEX</organization>
</author>

<date year="1975" day="15" month="April" />
</front>

<seriesInfo value="684" name="RFC" />
</reference>


<reference target2="reference.RFC.0685.xml" anchor="RFC0685">
<front>
<title>Response time in cross network debugging</title>
<author fullname="Michael Beeler" initials="M." surname="Beeler">
<organization>Bolt Baranek and Newman (BBN), TENEX</organization>
</author>

<date year="1975" month="April" day="16" />

<abstract>
<t>Cross-network debugging is a means whereby a programmer at one computer on a network can debug a program which executes on another computer. One form of cross-net debugging has been in use for some years by programmers who maintain IMPs on the ARPA network. Another form has been used by ARPA network users who employ TELNET or RSEXEC to log into a distant computer and remotely run a debugger on that machine. In both of these cases, the debugger is almost entirely resident in the same machine as the subject program, and only a remote means of access to that computer distinguishes the activity
from single-computer debugging.</t>

<t>In our case, we use a PDP-10 to perform complex debugging manipulations. Simple manipulations, and complex actions which the PDP-10 has partially digested into simple actions, are sent over the ARPA network to a PDP-11. The portion of the debugger resident in the PDP-11, where the subject program executes, can perform only simple actions (examine, deposit, start, stop, set breakpoint, etc.). This division of debugging computation between the two machines is implemented and in use at BBN. A user s manual is available (as (BBN] DOCUMENTATION XNET.DOC) describing the debugger s features and discussing some of the issues involved.</t>

<t>The purpose of this RFC is to describe our experience with response times the debugger exhibits. Response time is a serious problem in any elaboration to a debugger. Here we wish to discuss the contribution of communicating over the ARPA network to response time. The debugger (X-NET) keeps statistics during each debugging session, and a debugger command prints them out. We used a "standard scenario" to measure response times on two occasions. The first was debugging a PDP-11 at BBN on the same IMP as the PDP-10. The second was with a PDP-11 at SRI-ARC in California, with at least nine IMPs intervening.</t>
</abstract>
</front>

<seriesInfo value="685" name="RFC" />
</reference>


<reference target2="reference.RFC.0686.xml" anchor="RFC0686">
<front>
<title>Leaving well enough alone</title>
<author fullname="Brian Harvey" initials="B." surname="Harvey">
<organization>Stanford University (SU), Artificial Intelligence (AI)</organization>
</author>

<date year="1975" day="10" month="May" />

<abstract>
<t>I recently decided it was time for an overhaul of our FTP user and server programs.  This was my first venture into the world of network protocols, and I soon discovered that there was a lot we were doing wrong -- and a few things that everyone seemed to be doing differently from each other.  When I enquired about this, the response from some quarters was "Oh, you're running version 1!"</t>
</abstract>
</front>

<seriesInfo value="686" name="RFC" />
</reference>


<reference target2="reference.RFC.0687.xml" anchor="RFC0687">
<front>
<title>IMP/Host and Host/IMP Protocol changes</title>
<author fullname="David C. Walden" initials="D." surname="Walden">
<organization>Bolt Baranek and Newman (BBN)</organization>

<address>
<email>WALDEN@BBN</email>
</address>
</author>

<date year="1975" day="2" month="June" />

<abstract>
<t>This note sketches the design of an expansion to the IMP/host and host/IMP  protocol which will include among other things the possibility of addressing hosts on more than 63 IMPs. Our intention in this expansion is to correct certain existing limits without fundamental changes in the philosophy of the IMP/host protocol; i.e., while many issues which would represent  fundamental changes to the IMP/host protocol are presently under discussion in the world-wide packet-switching com unity, we are not able to undertake massive fundamental changes on a time scale compatible with the short term needs for network improvement (e.g., already there are almost 60 IMPs).</t>
</abstract>
</front>

<seriesInfo value="687" name="RFC" />
</reference>


<reference target2="reference.RFC.0688.xml" anchor="RFC0688">
<front>
<title>Tentative schedule for the new Telnet implementation for the TIP</title>
<author fullname="David C. Walden" initials="D." surname="Walden">
<organization>Bolt Baranek and Newman (BBN)</organization>
</author>

<date year="1975" day="4" month="June" />

<abstract>
<t>Implementation of the New TELNET Protocol has now become the top priority item on the TIP development queue.  Because what is done in the TIP potentially affects what is done at a number of hosts, below we give the implementation schedule to which we hope to adhere.</t>
</abstract>
</front>

<seriesInfo value="688" name="RFC" />
</reference>


<reference target2="reference.RFC.0689.xml" anchor="RFC0689">
<front>
<title abbrev="TENEX NCP Finite State Machine for Connections">Tenex NCP finite state machine for connections</title>
<author fullname="R. Clements" initials="R." surname="Clements">
<organization />
</author>

<date year="1975" day="23" month="May" />

<abstract>
<t>The attached figure describes the finite state machine used in TENEX version 1.33 to implement the ARPANET Host to Host protocol. This memo updates that of 27 August 1971, TENEX memo number 113, with regard to the finite state machine. Other parts of that memo have been incorporated into the JSYS manual and other documents.</t>
</abstract>
</front>

<seriesInfo value="689" name="RFC" />
</reference>


<reference target2="reference.RFC.0690.xml" anchor="RFC0690">
<front>
<title>Comments on the proposed Host/IMP Protocol changes</title>
<author fullname="Jon Postel" initials="J." surname="Postel">
<organization>University of Southern California (USC)/Information Sciences Institute</organization>

<address>
<postal>
<street>4676 Admiralty Way</street>
<city>Marina del Rey</city>
<region>CA</region>
<code>90291</code>
<country>US</country>
</postal>

<phone>+1 213 822 1511</phone>
</address>
</author>

<date year="1975" day="6" month="June" />

<abstract>
<t>This is a set of comments on Dave Walden's RFC 687 suggesting a set of changes to the host--imp protocol.</t>
</abstract>
</front>

<seriesInfo value="690" name="RFC" />
</reference>


<reference target2="reference.RFC.0691.xml" anchor="RFC0691">
<front>
<title>One more try on the FTP</title>
<author fullname="Brian Harvey" initials="B." surname="Harvey">
<organization>Stanford University (SU), Artifical Intelligence (AI)</organization>
</author>

<date year="1975" day="6" month="June" />

<abstract>
<t>This is a slight revision of RFC 686, mainly differing in the discussion of print files.  Reading several RFCs that I (sigh) never heard of before writing 686 has convinced me that although I was right all along it was for the wrong reasons.  The list of reply codes is also slightly different to reflect the four lists in RFCs 354, 454, 542, and 640 more completely.  Let me also suggest that if there are no objections before June 1, everyone take it as official that HELP should return 200, that SRVR should be used as discussed below, and that "permanent" 4xx errors be changed to 5xx.  And thanks to Jon Postel who just spent all evening helping me straighten this all out.</t>

<t>Aside from a cry of anguish by the site responsible for the security hassle described below, I've only had one comment on this, which was unfavorable but, alas, unspecific.  Let me just say, in the hopes of avoiding more such, that I am not just trying to step on toes for the fun of it, and that I don't think the positive changes to FTP-1 proposed here are necessarily the best possible thing.  What they are, I think, is easily doable. The great-FTP-in-the-sky isn't showing any signs of universal acceptability, and it shouldn't stand in the way of solving immediate problems.</t>

<t>Leaving Well Enough Alone</t>

<t>I recently decided it was time for an overhaul of our FTP user and server programs.  This was my first venture into the world of network protocols, and I soon discovered that there was a lot we were doing wrong--and a few things that everyone seemed to be doing differently from each other.  When I enquired about this, the response from some quarters was "Oh, you're running Version 1!"</t>
</abstract>
</front>

<seriesInfo value="691" name="RFC" />
</reference>


<reference target2="reference.RFC.0692.xml" anchor="RFC0692">
<front>
<title abbrev="Comments on IMP/Host Protocol Changes">Comments on IMP/Host Protocol changes (RFCs 687 and 690)</title>
<author fullname="Stephen Wolfe" initials="S." surname="Wolfe">
<organization>University of California, Los Angeles (UCLA), CCN</organization>
</author>

<date year="1975" day="20" month="June" />

<abstract>
<t>Basically, the proposed set of changes in RFC 687 seems reasonable, as are the comments in RFC 690.</t>
</abstract>
</front>

<seriesInfo value="692" name="RFC" />
</reference>


<reference target2="reference.RFC.0694.xml" anchor="RFC0694">
<front>
<title>Protocol information</title>
<author fullname="J. Postel" initials="J." surname="Postel">
<organization />
</author>

<date year="1975" day="18" month="June" />
</front>

<seriesInfo value="694" name="RFC" />
</reference>


<reference target2="reference.RFC.0695.xml" anchor="RFC0695">
<front>
<title>Official change in Host-Host Protocol</title>
<author fullname="Mark Krilanovich" initials="M." surname="Krilanovich">
<organization />
</author>

<date year="1975" day="5" month="July" />
</front>

<seriesInfo value="695" name="RFC" />
</reference>


<reference target2="reference.RFC.0696.xml" anchor="RFC0696">
<front>
<title>Comments on the IMP/Host and Host/IMP Protocol changes</title>
<author fullname="V.G. Cerf" initials="V.G." surname="Cerf">
<organization />
</author>

<date year="1975" day="13" month="July" />
</front>

<seriesInfo value="696" name="RFC" />
</reference>


<reference target2="reference.RFC.0697.xml" anchor="RFC0697">
<front>
<title>CWD command of FTP</title>
<author fullname="Jim Lieb" initials="J." surname="Lieb">
<organization>SUMEX-AIM</organization>
</author>

<date year="1975" day="14" month="July" />
</front>

<seriesInfo value="697" name="RFC" />
</reference>


<reference target2="reference.RFC.0698.xml" anchor="RFC0698">
<front>
<title>Telnet extended ASCII option</title>
<author fullname="T. Mock" initials="T." surname="Mock">
<organization />
</author>

<date year="1975" day="23" month="July" />
</front>

<seriesInfo value="698" name="RFC" />
</reference>


<reference target2="reference.RFC.0699.xml" anchor="RFC0699">
<front>
<title>Request For Comments summary notes: 600-699</title>
<author fullname="J. Postel" initials="J." surname="Postel">
<organization>University of Southern California (USC)/Information Sciences Institute</organization>

<address>
<postal>
<street>4676 Admiralty Way</street>
<city>Marina del Rey</city>
<region>CA</region>
<code>90291</code>
<country>US</country>
</postal>

<phone>+1 213 822 1511</phone>
</address>
</author>

<author fullname="J. Vernon" initials="J." surname="Vernon">
<organization>University of Southern California (USC)/Information Sciences Institute</organization>

<address>
<postal>
<street>4676 Admiralty Way</street>
<city>Marina del Rey</city>
<region>CA</region>
<code>90291</code>
<country>US</country>
</postal>

<phone>+1 213 822 1511</phone>
</address>
</author>

<date year="1982" day="1" month="November" />

<abstract>
<t>This RFC is a slightly annotated list of the 100 RFCs from RFC 600 through RFC 699.  This is a kind of status report on these RFCs.</t>
</abstract>
</front>

<seriesInfo value="699" name="RFC" />
</reference>


<reference target2="reference.RFC.0700.xml" anchor="RFC0700">
<front>
<title>Protocol experiment</title>
<author fullname="Eric R. Mader" initials="E." surname="Mader">
<organization />
</author>

<author fullname="William W. Plummer" initials="W." surname="Plummer">
<organization />
</author>

<author fullname="Raymond S. Tomlinson" initials="R." surname="Tomlinson">
<organization />
</author>

<date year="1974" day="1" month="August" />
</front>

<seriesInfo value="700" name="RFC" />
</reference>


<reference target2="reference.RFC.0701.xml" anchor="RFC0701">
<front>
<title>August, 1974, survey of New-Protocol Telnet servers</title>
<author fullname="D. W. Dodds" initials="D." surname="Dodds">
<organization>Bolt Baranek and Newman (BBN), TENEXA</organization>
</author>

<date year="1974" day="1" month="August" />

<abstract>
<t>THIS IS THE FIRST OF WHAT ARE PLANNED TO BE MONTHLY REPORTS ON THE STATUS OF THE NEW-PROTOCOL TELNET IMPLEMENTAIONS ON THE SERVER HOSTS ON THE ARPA NETWORK.  INCLUDED IN THIS REPORT ARE DATA ONLY ON SERVER TELNETS AT THE VARIOUS SITES.  ONE WOULD HOPE THAT ANY SITE WITH AN OPERATIONAL NEW-PROTOCOL SERVER TELNET WOULD ALSO BOAST A NEW-PROTOCOL USER TELNET; WE CAN CERTAINLY ASSUME THIS FOR TENEX SITES AT WHICH TENEX 1.32 IS OPERATING.  HOWEVER, NO FURTHER CLAIMS
ARE MADE FOR THE SERVER DATA CONTAINED IN THIS REPORT.</t>
</abstract>
</front>

<seriesInfo value="701" name="RFC" />
</reference>


<reference target2="reference.RFC.0702.xml" anchor="RFC0702">
<front>
<title abbrev="SURVEY OF NEW-PROTOCOL TELNET SERVERS">September, 1974, survey of New-Protocol Telnet servers</title>
<author fullname="D. W. Dodds" initials="D." surname="Dodds">
<organization>Bolt Baranek and Newman (BBN), TENEXA</organization>
</author>

<date year="1974" day="25" month="September" />

<abstract>
<t>LAST MONTH'S SURVEY PRODUCED A GRATIFYING AMOUNT OF FEEDBACK CLARIFYING THE STATUS OF SEVERAL SITES; HOWEVER THERE HAVE BEEN VERY FEW CHANGES IN THE STATUS OF HOST SERVERS.  THE CHANGES IN THIS MONTH'S LIST, IN NUMERICAL ORDER (HOST NUMBER THROUGHOUT ARE OCTAL):</t>
</abstract>
</front>

<seriesInfo value="702" name="RFC" />
</reference>


<reference target2="reference.RFC.0703.xml" anchor="RFC0703">
<front>
<title abbrev="Survey of New-Protocol TELNET Servers">July, 1975, survey of New-Protocol Telnet Servers</title>
<author fullname="D. W. Dodds" initials="D." surname="Dodds">
<organization>Bolt Baranek and Newman (BBN), TENEXA</organization>
</author>

<date year="1975" day="11" month="July" />

<abstract>
<t>In the nearly five months since the last report several new server sites have joined the network and there has been some significant progress in New-Protocol implementation.  Perhaps the New-Protocol implementation on the TIPs scheduled for the end of the year will encourage further progress in the near future.</t>
</abstract>
</front>

<seriesInfo value="703" name="RFC" />
</reference>


<reference target2="reference.RFC.0704.xml" anchor="RFC0704">
<front>
<title>IMP/Host and Host/IMP Protocol change</title>
<author fullname="Paul J. Santos, Jr." initials="P." surname="Santos">
<organization>Bolt Beranek and Newman (BBN)</organization>
</author>

<date year="1975" day="15" month="September" />

<abstract>
<t>This note is a revision of RFC 687 and sketches the design of an expansion to the IMP/host and host/IMP protocol which will include among other things the possibility of addressing hosts on more than 63 IMPs. Our intention in this expansion is to correct certain existing limits without fundamental changes in the philosophy of the IMP/host protocol; i.e., while many issues which would represent fundamental changes to the IMP/host protocol are presently under discussion in the world-wide packet-switching community, we are not able to undertake massive fundamental changes on a time scale compatible with the short term needs for network improvement (e.g., already there are 62 IMPs).</t>
</abstract>
</front>

<seriesInfo value="704" name="RFC" />
</reference>


<reference target2="reference.RFC.0705.xml" anchor="RFC0705">
<front>
<title>Front-end Protocol B6700 version</title>
<author fullname="Roland Bryan" initials="R." surname="Bryan">
<organization>University of Southern California (USC)/Information Sciences Institute</organization>

<address>
<postal>
<street>4676 Admiralty Way</street>
<city>Marina del Rey</city>
<region>CA</region>
<code>90291</code>
<country>US</country>
</postal>

<phone>+1 213 822 1511</phone>
<email>BRYAN@ISI</email>
</address>
</author>

<author fullname="Gerald Bailey" initials="G." surname="Bailey">
<organization>NSA</organization>
</author>

<author fullname="Keith McCloghrie" initials="K." surname="McCloghrie">
<organization>NSA</organization>
</author>

<author fullname="David Grothe" initials="D." surname="Grothe">
<organization>ACC</organization>
</author>

<date year="1975" day="5" month="November" />

<abstract>
<t>This is a working document which has been developed as the specification and guideline for design of a Burroughs B6700 attachment to an ARPA-Style network.</t>

<t>The approach is to utilize a front-end processor with a new protocol for network operation.  That protocol, described herein, has been built upon the concepts expressed by M.A. Padlipsky, et al, in NIC# 31117, RFC# 647..</t>

<t>This proposed, site-specific, FEP implementation is the work of Gerald Bailey and Keith McCloghrie of NSA and of David Grothe of ACC.  It has already sustained some corrections provided by MAP.  It will be helpful if interested networkers will review and provide comments to us.</t>
</abstract>
</front>

<seriesInfo value="705" name="RFC" />
</reference>


<reference target2="reference.RFC.0706.xml" anchor="RFC0706">
<front>
<title>On the junk mail problem</title>
<author fullname="Jon Postel" initials="J." surname="Postel">
<organization>Stanford Research Institute (SRI), Augmentation Research Center (ARC)</organization>
</author>

<date year="1975" day="8" month="November" />

<abstract>
<t>In the ARPA Network Host/IMP interface protocol there is no mechanism for the Host to selectively refuse messages. This means that a Host which desires to receive some particular messages must  read all messages addressed to it. Such a Host could be sent many messages by a malfunctioning Host. This would constitute a denial of service to the normal users of this Host. Both the local users and the network communication could suffer. The services denied are the processor time consumed in examining the undesired messages and rejecting them, and the loss of network thruput or increased delay due to the unnecessary busyness of the network.</t>

<t>It would be useful for a Host to be able to decline messages from sources it believes are misbehaving or are simply annoying. If the Host/IMP interface protocol allowed the Host to say to the IMP "refuse messages from Host X", the IMPs could discard the unwanted messages at their earliest opportunity returning a "refused" notice to the offending Host.</t>
</abstract>
</front>

<seriesInfo value="706" name="RFC" />
</reference>


<reference target2="reference.RFC.0707.xml" anchor="RFC0707">
<front>
<title>High-level framework for network-based resource sharing</title>
<author fullname="James E. White" initials="J." surname="White">
<organization>Stanford Research Institute (SRI) International,  Augmentation Research Center (ARC)</organization>

<address>
<postal>
<street />
<city>Menlo Park</city>
<region>CA</region>
<code>94025</code>
<country>US</country>
</postal>

<phone>+1 415 326 6200 x2960</phone>
</address>
</author>

<date year="1975" day="23" month="December" />

<abstract>
<t>This paper proposes a high-level, application-independent protocol and software framework that would extend the local programming environment to embrace modules in other computers within a resource sharing computer network, and thereby facilitate the construction of distributed systems and encourage the sharing of resources.</t>

<t>The work reported here was supported by the Advanced Research Projects Agency of the Department of Defense, and by the Rome Air Development Center of the Air Force.</t>

<t>This paper has been submitted for publication in the Proceedings of the 1976 National Computer Conference.</t>
</abstract>
</front>

<seriesInfo value="707" name="RFC" />
</reference>


<reference target2="reference.RFC.0708.xml" anchor="RFC0708">
<front>
<title>Elements of a Distributed Programming System</title>
<author fullname="James E. White" initials="J." surname="White">
<organization>Stanford Research Institute (SRI), Augmentation Research Center (ARC)</organization>

<address>
<postal>
<street />
<city>Menlo Park</city>
<region>CA</region>
<code>94025</code>
<country>US</country>
</postal>

<phone>+1 415 326 6200 x2960</phone>
</address>
</author>

<date year="1976" day="28" month="January" />

<abstract>
<t>This paper suggests some extensions to the simple Procedure Call Protocol described in a previous paper (27197).  By expanding the procedure call model and standardizing other common forms of inter-process interaction, such extensions would provide the applications programmer with an even more powerful distributed programming system.</t>
</abstract>
</front>

<seriesInfo value="708" name="RFC" />
</reference>


<reference target2="reference.RFC.0712.xml" anchor="RFC0712">
<front>
<title>Distributed Capability Computing System (DCCS)</title>
<author fullname="J.E. Donnelley" initials="J.E." surname="Donnelley">
<organization />
</author>

<date year="1976" day="5" month="February" />
</front>

<seriesInfo value="712" name="RFC" />
</reference>


<reference target2="reference.RFC.0713.xml" anchor="RFC0713">
<front>
<title>MSDTP-Message Services Data Transmission Protocol</title>
<author fullname="Jack Haverty" initials="J." surname="Haverty">
<organization>Massachusetts Institute of Technology (MIT)</organization>

<address>
<email>JFH@MIT-DMS</email>
</address>
</author>

<date year="1976" day="6" month="April" />

<abstract>
<t>A mechanism is defined for use by message servers in transferring data between hosts.  The mechanism, called the MSDTP, is defined in terms of a model of the process as a translation between two sets of items, the abstract entities such as 'strings' and 'integers', and the formats used to represent such data as a byte stream.</t>

<t>A proposed organization of a general data transfer mechanism is described, and the manner in which the MSDTP would be used in that environment is presented.</t>
</abstract>
</front>

<seriesInfo value="713" name="RFC" />
</reference>


<reference target2="reference.RFC.0714.xml" anchor="RFC0714">
<front>
<title>Host-Host Protocol for an ARPANET-Type Network</title>
<author fullname="A.M. McKenzie" initials="A.M." surname="McKenzie">
<organization />
</author>

<date year="1976" day="21" month="April" />
</front>

<seriesInfo value="714" name="RFC" />
</reference>


<reference target2="reference.RFC.0716.xml" anchor="RFC0716">
<front>
<title>Interim Revision to Appendix F of BBN 1822</title>
<author fullname="David Walden" initials="D." surname="Walden">
<organization />
</author>

<author fullname="Joel Levin" initials="J." surname="Levin">
<organization />
</author>

<date year="1976" day="24" month="May" />

<abstract>
<t>Over the past few months we have become aware that there has been some confusion as to how to operate a Host connected to an IMP as a Very Distant Host (or VDH).  Therefore, next time BBN Report 1822 ("Specifications for the Interconnection of a Host and an IMP") is revised, we will include additional information on how the IMP side of a VDH connection works and how the Host side may operate most efficiently.  As an interim measure, we are distributing this RFC which takes the form of a (logical) update to Appendix F of BBN Report 1822.</t>
</abstract>
</front>

<seriesInfo value="716" name="RFC" />
</reference>


<reference target2="reference.RFC.0717.xml" anchor="RFC0717">
<front>
<title>Assigned Network Numbers</title>
<author fullname="Jon Postel" initials="J." surname="Postel">
<organization>Stanford Research Institute (SRI) International,  Augmentation Research Center (ARC)</organization>
</author>

<date year="1976" day="1" month="July" />
</front>

<seriesInfo value="717" name="RFC" />
</reference>


<reference target2="reference.RFC.0718.xml" anchor="RFC0718">
<front>
<title>Comments on RCTE from the Tenex Implementation Experience</title>
<author fullname="Jon Postel" initials="J." surname="Postel">
<organization>Stanford Research Institute (SRI) International,  Augmentation Research Center (ARC)</organization>
</author>

<date year="1976" day="30" month="June" />
</front>

<seriesInfo value="718" name="RFC" />
</reference>


<reference target2="reference.RFC.0719.xml" anchor="RFC0719">
<front>
<title>Discussion on RCTE</title>
<author fullname="Jon Postel" initials="J." surname="Postel">
<organization>Stanford Research Institute (SRI) International,  Augmentation Research Center (ARC)</organization>
</author>

<date year="1976" day="22" month="July" />

<abstract>
<t>The following is the significant portion of a dialog on RCTE that has followed the publication of RFC 718.</t>
</abstract>
</front>

<seriesInfo value="719" name="RFC" />
</reference>


<reference target2="reference.RFC.0720.xml" anchor="RFC0720">
<front>
<title>Address Specification Syntax for Network Mail</title>
<author fullname="D. Crocker" initials="D." surname="Crocker">
<organization>University of Southern California (USC)/Information Sciences Institute</organization>

<address>
<postal>
<street>4676 Admiralty Way</street>
<city>Marina del Rey</city>
<region>CA</region>
<code>90291</code>
<country>US</country>
</postal>

<phone>+1 213 822 1511</phone>
</address>
</author>

<date year="1976" day="5" month="August" />

<abstract>
<t>Experience with processing mail on the Arpanet has pointed up many addressing issues, including:</t>

<t>1. People's names are not the same as their addresses;
				2. Mailing lists can get quite long;
				3. To allow responding, messages often need to carry all of their mailing list with them;
				4. It would be very useful to be able to send mail to files other than the person's primary mailbox.</t>
</abstract>
</front>

<seriesInfo value="720" name="RFC" />
</reference>


<reference target2="reference.RFC.0721.xml" anchor="RFC0721">
<front>
<title abbrev="Out-of-Band Control Signals">Out-of-Band Control Signals in a Host-to-Host Protocol</title>
<author fullname="Larry Garlick" initials="L." surname="Garlick">
<organization>Stanford Research Institute (SRI) International, Augmentation Research Center (ARC)</organization>
</author>

<date year="1976" day="1" month="September" />

<abstract>
<t>This note addresses the problem of implementing a reliable out-of-band signal for use in a host-to-host protocol.  It is motivated by the fact that such a satisfactory mechanism does not exist in the Transmission Control Protocol (TCP) of Cerf et. al.,. In addition to discussing some requirements for such an out-of-band signal (interrupts) and the implications for the implementation of the requirements, a discussion of the problem for the TCP case will be presented.</t>

<t>While the ARPANET host-to-host protocol does not support reliable transmission of either data or controls, it does meet the other requirements we have for an out-of-band control signal and will be drawn upon to provide a solution for the TCP case.</t>
</abstract>
</front>

<seriesInfo value="721" name="RFC" />
</reference>


<reference target2="reference.RFC.0722.xml" anchor="RFC0722">
<front>
<title>Thoughts on Interactions in Distributed Services</title>
<author fullname="Jack Haverty" initials="J." surname="Haverty">
<organization>Massachusetts Institute of Technology (MIT)</organization>
</author>

<date year="1976" day="16" month="September" />

<abstract>
<t>This paper addresses some issues concerned with the design of distributed services.  In particular, it is concerned with the characteristics of the interactions, between programs which support some service at various network sites.  The ideas presented are derived mainly from experience with various service protocolson the ARPANET.</t>

<t>A model is developed of interactions between programs. Salient features of this model which promote and simplify the construction of reliable, responsive services are identified.  These dualities are motivated by problems experienced with various ARPANET protocols and in the design and maintenance of programs which use these protocols in the performance of some service.</t>

<t>Using this model as a template, the general architecture of one possible interaction protocol is presented.  This mechanism provides a foundation on which protocols would be constructed for particular services, simplifying the process of creating services which are easy to implement and maintain, and appear reliable and responsive to the customer.  This presentation is meant to serve as an introduction to a specific instance of such a protocol, called the RRP, which is defined in one of the references.</t>
</abstract>
</front>

<seriesInfo value="722" name="RFC" />
</reference>


<reference target2="reference.RFC.0724.xml" anchor="RFC0724">
<front>
<title abbrev="Proposed Standard for Message Format">Proposed official standard for the format of ARPA Network messages</title>
<author fullname="Ken Pogran" initials="K." surname="Pogran">
<organization>Massachusetts Institute of Technology (MIT), LCS/CSR</organization>

<address>
<email>Pogran@MIT-Multics</email>
</address>
</author>

<author fullname="John Vittal" initials="J." surname="Vittal">
<organization>Bolt Baranek and Newman (BBN)</organization>

<address>
<email>Vittal@BBN-TENEXA</email>
</address>
</author>

<author fullname="Dave Crocker" initials="D." surname="Crocker">
<organization>The Rand Corporation, Information Sciences Department</organization>

<address>
<email>DCrocker@Rand-Unix</email>
</address>
</author>

<author fullname="Austin Henderson" initials="A." surname="Henderson">
<organization>Bolt Baranek and Newman (BBN)</organization>

<address>
<email>Henderson@BBN-TENEXD</email>
</address>
</author>

<date year="1977" day="12" month="May" />
</front>

<seriesInfo value="724" name="RFC" />
</reference>


<reference target2="reference.RFC.0725.xml" anchor="RFC0725">
<front>
<title>RJE protocol for a resource sharing network</title>
<author fullname="John Day" initials="J." surname="Day">
<organization />
</author>

<author fullname="Gary R. Grossman" initials="G." surname="Grossman">
<organization />
</author>

<author>
<organization>Command and Control Technical Center WWMCCS ADP Director of the Defense Communications Agency</organization>

<address>
<postal>
<street />
<city>Washington</city>
<region>DC</region>
<code>20305</code>
<country>US</country>
</postal>

</address>
</author>

<author>
<organization>University of Illinois at Urbana-Champaign, Center for Advanced Computation</organization>

<address>
<postal>
<street />
<city>Urbana</city>
<region>IL</region>
<code>61801</code>
<country>US</country>
</postal>

</address>
</author>

<date year="1977" day="1" month="March" />
</front>

<seriesInfo value="725" name="RFC" />
</reference>


<reference target2="reference.RFC.0726.xml" anchor="RFC0726">
<front>
<title>Remote Controlled Transmission and Echoing Telnet option</title>
<author fullname="Jon Postel" initials="J." surname="Postel">
<organization>Stanford Research Institute (SRI) International, Augmentation Research Center (ARC)</organization>
</author>

<author fullname="D. Crocker" initials="D." surname="Crocker">
<organization>University of California, Irvine</organization>
</author>

<date year="1977" day="8" month="March" />
</front>

<seriesInfo value="726" name="RFC" />
</reference>


<reference target2="reference.RFC.0727.xml" anchor="RFC0727">
<front>
<title>Telnet logout option</title>
<author fullname="Mark Crispin" initials="M." surname="Crispin">
<organization>Massechusetts Institute of Technology (MIT), Artifical Intelligence</organization>
</author>

<date year="1977" day="27" month="April" />
</front>

<seriesInfo value="727" name="RFC" />
</reference>


<reference target2="reference.RFC.0728.xml" anchor="RFC0728">
<front>
<title>Minor pitfall in the Telnet Protocol</title>
<author fullname="John Day" initials="J." surname="Day">
<organization />
</author>

<date year="1977" day="27" month="April" />

<abstract>
<t>Designers of Telnet options should be aware of the following possible case in the Telnet protocol which may generate unexpected behavior on either end of the connection. Although at present none of the existing options are susceptible to this problem, it could arise in the future.</t>
</abstract>
</front>

<seriesInfo value="728" name="RFC" />
</reference>


<reference target2="reference.RFC.0729.xml" anchor="RFC0729">
<front>
<title>Telnet byte macro option</title>
<author fullname="Dave Crocker" initials="D." surname="Crocker">
<organization>Rand Corporation, ISD</organization>

<address>
<email>Dcrocker@Rand-Unix</email>
</address>
</author>

<date year="1977" day="13" month="May" />
</front>

<seriesInfo value="729" name="RFC" />
</reference>


<reference target2="reference.RFC.0730.xml" anchor="RFC0730">
<front>
<title>Extensible field addressing</title>
<author fullname="Jon Postel" initials="J." surname="Postel">
<organization>University of Southern California (USC)/Information Sciences Institute</organization>

<address>
<postal>
<street>4676 Admiralty Way</street>
<city>Marina del Rey</city>
<region>CA</region>
<code>90291</code>
<country>US</country>
</postal>

<phone>+1 213 822 1511</phone>
</address>
</author>

<date year="1977" day="20" month="May" />
</front>

<seriesInfo value="730" name="RFC" />
</reference>


<reference target2="reference.RFC.0731.xml" anchor="RFC0731">
<front>
<title abbrev="Data Entry Terminal Option">Telnet Data Entry Terminal option</title>
<author fullname="John Day" initials="J." surname="Day">
<organization />
</author>

<date year="1977" day="27" month="June" />
</front>

<seriesInfo value="731" name="RFC" />
</reference>


<reference target2="reference.RFC.0732.xml" anchor="RFC0732">
<front>
<title>Telnet Data Entry Terminal option</title>
<author fullname="John Day" initials="J." surname="Day">
<organization />
</author>

<date year="1977" day="12" month="September" />
</front>

<seriesInfo value="732" name="RFC" />
</reference>


<reference target2="reference.RFC.0733.xml" anchor="RFC0733">
<front>
<title>Standard for the format of ARPA network text messages</title>
<author fullname="David H. Crocker" initials="D." surname="Crocker">
<organization>The Rand Corporation, Information Sciences Department</organization>

<address>
<postal>
<street>1700 Main St</street>
<city>Santa Monica</city>
<region>CA</region>
<code>90406</code>
<country>US</country>
</postal>

<email>DCrocker@Rand-Unix</email>
</address>
</author>

<author fullname="John J. Vittal" initials="J." surname="Vittal">
<organization>Bolt Beranek and Newman Inc. (BBN)</organization>

<address>
<postal>
<street>50 Moulton St.</street>
<city>Cambridge</city>
<region>MA</region>
<code>02138</code>
<country>US</country>
</postal>

<email>Vittal@BBN-TenexD</email>
</address>
</author>

<author fullname="Kenneth T. Pogran" initials="K." surname="Pogran">
<organization>Massachusets Institute of Technology (MIT), Laboratory for Computer Science</organization>

<address>
<postal>
<street>545 Technology Square</street>
<city>Cambridge</city>
<region>MA</region>
<code>02139</code>
<country>US</country>
</postal>

<email>Pogran@MIT-Multics</email>
</address>
</author>

<author fullname="D. Austin Henderson, Jr." initials="D." surname="Henderson">
<organization>Bolt Beranek and Newman Inc. (BBN)</organization>

<address>
<postal>
<street>50 Moulton St.</street>
<city>Cambridge</city>
<region>MA</region>
<code>02138</code>
<country>US</country>
</postal>

<email>Henderson@BBN-TenexD</email>
</address>
</author>

<date year="1977" day="21" month="November" />
</front>

<seriesInfo value="733" name="RFC" />
</reference>


<reference target2="reference.RFC.0734.xml" anchor="RFC0734">
<front>
<title abbrev="SUPDUP Display Protocol">SUPDUP Protocol</title>
<author fullname="Mark Crispin" initials="M." surname="Crispin">
<organization>Stanford University, Artifical Intelligence</organization>
</author>

<date year="1977" day="7" month="October" />
</front>

<seriesInfo value="734" name="RFC" />
</reference>


<reference target2="reference.RFC.0735.xml" anchor="RFC0735">
<front>
<title abbrev="Telnet Byte Macro Option">Revised Telnet byte macro option</title>
<author fullname="David H. Crocker" initials="D." surname="Crocker">
<organization>The Rand Corporation, Information Sciences Department</organization>

<address>
<email>Dcrocker@Rand-Unix</email>
</address>
</author>

<author fullname="Richard H. Gumpertz" initials="R." surname="Gumpertz">
<organization>Carnegie-Mellon University (CMU)</organization>

<address>
<email>Gumpertz@CMU-10A</email>
</address>
</author>

<date year="1977" day="3" month="November" />
</front>

<seriesInfo value="735" name="RFC" />
</reference>


<reference target2="reference.RFC.0736.xml" anchor="RFC0736">
<front>
<title>Telnet SUPDUP option</title>
<author fullname="Mark Crispin" initials="M." surname="Crispin">
<organization>Stanford University, Artifical Intelligence</organization>
</author>

<date year="1977" day="31" month="October" />
</front>

<seriesInfo value="736" name="RFC" />
</reference>


<reference target2="reference.RFC.0737.xml" anchor="RFC0737">
<front>
<title>FTP extension: XSEN</title>
<author fullname="K. Harrenstien" initials="K." surname="Harrenstien">
<organization>Stanford Research Institute (SRI) International, KL</organization>
</author>

<date year="1977" day="31" month="October" />

<abstract>
<t>This note describes an extension to the File Transfer Protocol which provides for "sending" a message to a logged-in user, as well as variants for mailing it normally whether the user is logged in or not.</t>
</abstract>
</front>

<seriesInfo value="737" name="RFC" />
</reference>


<reference target2="reference.RFC.0738.xml" anchor="RFC0738">
<front>
<title>Time server</title>
<author fullname="K. Harrenstien" initials="K." surname="Harrenstien">
<organization>Stanford Research Institute (SRI) International, KL</organization>
</author>

<date year="1977" day="31" month="October" />

<abstract>
<t>This note describes the Time Server protocol, as currently implemented on ITS hosts (i.e. MIT-(AI/ML/MC/DMS)).  The idea is to provide a site-independent, machine readable date and time in as efficient and swift a manner as possible; its motivation arises from the fact that not all systems have a date/time clock, and all are subject to occasional human or machine error.  The use of time-servers makes it possible to quickly confirm or correct a system's idea of the time, by making a brief poll of several independent sites on the network.</t>
</abstract>
</front>

<seriesInfo value="738" name="RFC" />
</reference>


<reference target2="reference.RFC.0739.xml" anchor="RFC0739">
<front>
<title>Assigned numbers</title>
<author fullname="Jon Postel" initials="J." surname="Postel">
<organization>University of Southern California (USC)/Information Sciences Institute</organization>

<address>
<postal>
<street>4676 Admiralty Way</street>
<city>Marina del Rey</city>
<region>CA</region>
<code>90291</code>
<country>US</country>
</postal>

<phone>+1 213 822 1511</phone>
<email>POSTEL@ISIB</email>
</address>
</author>

<date year="1977" day="11" month="November" />

<abstract>
<t>This Network Working Group Request for Comments documents the currently assigned values from several series of numbers used in network protocol implementations.</t>
</abstract>
</front>

<seriesInfo value="739" name="RFC" />
</reference>


<reference target2="reference.RFC.0740.xml" anchor="RFC0740">
<front>
<title>NETRJS Protocol</title>
<author fullname="R. Braden" initials="R." surname="Braden">
<organization>University of California, Los Angeles (UCLA), CCN</organization>
</author>

<date year="1977" day="22" month="November" />
</front>

<seriesInfo value="740" name="RFC" />
</reference>


<reference target2="reference.RFC.0741.xml" anchor="RFC0741">
<front>
<title abbrev="NVP">Specifications for the Network Voice Protocol (NVP)</title>
<author fullname="Danny Cohen" initials="D." surname="Cohen">
<organization>University of Southern California (USC)/Information Sciences Institute</organization>

<address>
<postal>
<street>4676 Admiralty Way</street>
<city>Marina del Rey</city>
<region>CA</region>
<code>90291</code>
<country>US</country>
</postal>

<phone>+1 213 822 1511</phone>
</address>
</author>

<date year="1976" day="22" month="November" />
</front>

<seriesInfo value="741" name="RFC" />
</reference>


<reference target2="reference.RFC.0742.xml" anchor="RFC0742">
<front>
<title>NAME/FINGER Protocol</title>
<author fullname="K. Harrenstien" initials="K." surname="Harrenstien">
<organization>Stanford Research Institute (SRI) International, KL</organization>
</author>

<date year="1977" day="30" month="December" />
</front>

<seriesInfo value="742" name="RFC" />
</reference>


<reference target2="reference.RFC.0743.xml" anchor="RFC0743">
<front>
<title abbrev="An Extension to FTP">FTP extension: XRSQ/XRCP</title>
<author fullname="K. Harrenstien" initials="K." surname="Harrenstien">
<organization>Stanford Research Institute (SRI), KL</organization>
</author>

<date year="1977" day="30" month="December" />
</front>

<seriesInfo value="743" name="RFC" />
</reference>


<reference target2="reference.RFC.0744.xml" anchor="RFC0744">
<front>
<title>MARS - a Message Archiving and Retrieval Service</title>
<author fullname="Joanne Sattley" initials="J." surname="Sattley">
<organization />

<address>
<email>JZS@CCA</email>
</address>
</author>

<date year="1978" day="8" month="January" />
</front>

<seriesInfo value="744" name="RFC" />
</reference>


<reference target2="reference.RFC.0745.xml" anchor="RFC0745">
<front>
<title abbrev="JANUS Interface Specifications">JANUS interface specifications</title>
<author fullname="Michael Beeler" initials="M." surname="Beeler">
<organization>Bolt Beranek and Newman (BBN)</organization>
</author>

<date year="1978" day="30" month="March" />
</front>

<seriesInfo value="745" name="RFC" />
</reference>


<reference target2="reference.RFC.0746.xml" anchor="RFC0746">
<front>
<title>SUPDUP graphics extension</title>
<author fullname="Richard Stallman" initials="R." surname="Stallman">
<organization>Massachusetts Institute of Technology (MIT), Artifical Intelligence (AI)</organization>
</author>

<date year="1978" day="17" month="March" />
</front>

<seriesInfo value="746" name="RFC" />
</reference>


<reference target2="reference.RFC.0747.xml" anchor="RFC0747">
<front>
<title>Recent extensions to the SUPDUP Protocol</title>
<author fullname="Mark Crispin" initials="M." surname="Crispin">
<organization>Stanford University, Artifical Intelligence</organization>
</author>

<date year="1978" day="21" month="March" />
</front>

<seriesInfo value="747" name="RFC" />
</reference>


<reference target2="reference.RFC.0748.xml" anchor="RFC0748">
<front>
<title>Telnet randomly-lose option</title>
<author fullname="M. Crispin" initials="M." surname="Crispin">
<organization>Stanford University, Artifical Intelligence</organization>
</author>

<date year="1978" day="1" month="April" />
</front>

<seriesInfo value="748" name="RFC" />
</reference>


<reference target2="reference.RFC.0749.xml" anchor="RFC0749">
<front>
<title>Telnet SUPDUP-Output option</title>
<author fullname="Bernard Greenberg" initials="B." surname="Greenberg">
<organization>Massachusetts Institute of Technology (MIT), Multics</organization>
</author>

<date year="1978" day="18" month="September" />
</front>

<seriesInfo value="749" name="RFC" />
</reference>


<reference target2="reference.RFC.0750.xml" anchor="RFC0750">
<front>
<title>Assigned numbers</title>
<author fullname="J. Postel" initials="J." surname="Postel">
<organization>University of Southern California (USC) / Information Sciences Institute</organization>

<address>
<postal>
<street>4676 Admiralty Way</street>
<city>Marina del Rey</city>
<region>CA</region>
<code>90291</code>
<country>US</country>
</postal>

<phone>+1 213 822 1511</phone>
<email>POSTEL@ISIB</email>
</address>
</author>

<date year="1978" day="26" month="September" />
</front>

<seriesInfo value="750" name="RFC" />
</reference>


<reference target2="reference.RFC.0751.xml" anchor="RFC0751">
<front>
<title>Survey of FTP mail and MLFL</title>
<author fullname="P. David Lebling" initials="P." surname="Lebling">
<organization>Massechusetts Institute of Technology (MIT)</organization>

<address>
<email>PDL@MIT-DMS</email>
</address>
</author>

<date year="1978" day="10" month="December" />

<abstract>
<t>Two surveys of Arpanet Server hosts were run between September 20, 1978
and December 11, 1978.  The intent was to determine the response of the host's Server FTP program</t>
</abstract>
</front>

<seriesInfo value="751" name="RFC" />
</reference>


<reference target2="reference.RFC.0752.xml" anchor="RFC0752">
<front>
<title>Universal host table</title>
<author fullname="Mark Crispin" initials="M." surname="Crispin">
<organization>Stanford University, Artifical Intelligence</organization>
</author>

<date year="1979" day="2" month="January" />

<abstract>
<t>The network host table in use at MITand Stanford is described. This host table is superior to the NIC and Tenex host tables in several ways.  A binary file, compiled from this host table, is also described. This file  is used  by subsystems on  MIT's  ITS and Stanford's  WAITS timesharing systems for efficiency in host and network lookups.</t>
</abstract>
</front>

<seriesInfo value="752" name="RFC" />
</reference>


<reference target2="reference.RFC.0753.xml" anchor="RFC0753">
<front>
<title>Internet Message Protocol</title>
<author fullname="Jonathan B. Postel" initials="J." surname="Postel">
<organization>University of Southern California (USC) / Information Sciences Institute</organization>

<address>
<postal>
<street>4676 Admiralty Way</street>
<city>Marina del Rey</city>
<region>CA</region>
<code>90291</code>
<country>US</country>
</postal>

<phone>+1 213 822 1511</phone>
</address>
</author>

<date year="1979" day="1" month="March" />
</front>

<seriesInfo value="753" name="RFC" />
</reference>


<reference target2="reference.RFC.0754.xml" anchor="RFC0754">
<front>
<title>Out-of-net host addresses for mail</title>
<author fullname="J. Postel" initials="J." surname="Postel">
<organization>University of Southern California (USC) / Information Sciences Institute</organization>

<address>
<postal>
<street>4676 Admiralty Way</street>
<city>Marina del Rey</city>
<region>CA</region>
<code>90291</code>
<country>US</country>
</postal>

<phone>+1 213 822 1511</phone>
</address>
</author>

<date year="1979" day="6" month="April" />

<abstract>
<t>There is now interest in sustantially extending the scope of the computer mail system used in the ARPANET to allow communication of voice, fax, graphics, as well as text information between users in different networks as wells as within the ARPANET.</t>

<t>The discussion of a transition from the current ARPANET sndmsg environment and mechanisms to a more general internet environment and richer mechanisms must consider techniques for continued activity during the transition.  In addition, there is a current need for a mechanism to support the interaction of the several already existing NSW-like message environments with the ARPANET message environment.</t>

<t>This memo discusses some possible alternatives for computer mail addressing for hosts outside the ARPANET in the short term.  This memo is hopelessly Tenex oriented in its descriptions and examples.</t>
</abstract>
</front>

<seriesInfo value="754" name="RFC" />
</reference>


<reference target2="reference.RFC.0755.xml" anchor="RFC0755">
<front>
<title>Assigned numbers</title>
<author fullname="Jon Postel" initials="J." surname="Postel">
<organization>University of Southern California (USC) / Information Sciences Institute</organization>

<address>
<postal>
<street>4676 Admiralty Way</street>
<city>Marina del Rey</city>
<region>CA</region>
<code>90291</code>
<country>US</country>
</postal>

<phone>+1 213 822 1511</phone>
<email>POSTEL@ISIB</email>
</address>
</author>

<date year="1979" day="3" month="May" />

<abstract>
<t>This Network Working Group Request for Comments documents the currently assigned values from several series of numbers used in network protocol
implementations.</t>
</abstract>
</front>

<seriesInfo value="755" name="RFC" />
</reference>


<reference target2="reference.RFC.0756.xml" anchor="RFC0756">
<front>
<title abbrev="NIC Name Server">NIC name server - a datagram-based information utility</title>
<author fullname="John R. Pickens" initials="J." surname="Pickens">
<organization>SRI International, Telecommunications Sciences Center</organization>

<address>
<postal>
<street>333 Ravenswood</street>
<city>Menlo Park</city>
<region>CA</region>
<code>94025</code>
<country>US</country>
</postal>

</address>
</author>

<author fullname="Elizabeth J. Feinler" initials="E." surname="Feinler">
<organization>SRI International, Telecommunications Sciences Center</organization>

<address>
<postal>
<street>333 Ravenswood</street>
<city>Menlo Park</city>
<region>CA</region>
<code>94025</code>
<country>US</country>
</postal>

</address>
</author>

<author fullname="James E. Mathis" initials="J." surname="Mathis">
<organization>SRI International, Telecommunications Sciences Center</organization>

<address>
<postal>
<street>333 Ravenswood</street>
<city>Menlo Park</city>
<region>CA</region>
<code>94025</code>
<country>US</country>
</postal>

</address>
</author>

<date year="1979" day="1" month="July" />

<abstract>
<t>In this paper a new method for distributing and updating host name/address information in large computer networks is described. The technique uses datagrams to provide a simple transaction-based query/response service.  A provisional service is being provided by the Arpanet Network Information Center (NIC) and is used by mobile packet radio terminals, as well as by several Arpanet DEC-10 hosts.  Extensions to the service are suggested that would expand the query functionality to allow more flexible query formats as well as queries for service addresses. Several architectural approaches with potential for expansion into a distributed internet environment are proposed.  This technique may be utilized in support of other distributed applications such as user identification and group distribution for computer based mail.</t>
</abstract>
</front>

<seriesInfo value="756" name="RFC" />
</reference>


<reference target2="reference.RFC.0757.xml" anchor="RFC0757">
<front>
<title>Suggested solution to the naming, addressing, and delivery problem for ARPANET message systems</title>
<author fullname="Debra P. Deutsch" initials="D." surname="Deutsch">
<organization>Bolt Beranek and Newman (BBN)</organization>

<address>
<postal>
<street>50 Moulton Street</street>
<city>Cambridge</city>
<region>MA</region>
<code>02138</code>
<country>US</country>
</postal>

<phone>+1 617 491 1850</phone>
</address>
</author>

<date year="1979" day="10" month="September" />
</front>

<seriesInfo value="757" name="RFC" />
</reference>


<reference target2="reference.RFC.0758.xml" anchor="RFC0758">
<front>
<title>Assigned numbers</title>
<author fullname="Jon Postel" initials="J." surname="Postel">
<organization>University of Southern California (USC) / Information Sciences Institute</organization>

<address>
<postal>
<street>4676 Admiralty Way</street>
<city>Marina del Rey</city>
<region>CA</region>
<code>90291</code>
<country>US</country>
</postal>

<phone>+1 213 822 1511</phone>
<email>POSTEL@ISIB</email>
</address>
</author>

<date year="1979" day="1" month="August" />

<abstract>
<t>This Network Working Group Request for Comments documents the currently assigned values from several series of numbers used in network protocol  implementations.</t>
</abstract>
</front>

<seriesInfo value="758" name="RFC" />
</reference>


<reference target2="reference.RFC.0759.xml" anchor="RFC0759">
<front>
<title>Internet Message Protocol</title>
<author fullname="Jonathan B. Postel" initials="J." surname="Postel">
<organization>University of Southern California (USC)/Information Sciences Institute</organization>

<address>
<postal>
<street>4676 Admiralty Way</street>
<city>Marina del Rey</city>
<region>CA</region>
<code>90291</code>
<country>US</country>
</postal>

<phone>+1 213 822 1511</phone>
</address>
</author>

<date year="1980" day="1" month="August" />
</front>

<seriesInfo value="759" name="RFC" />
</reference>


<reference target2="reference.RFC.0760.xml" anchor="RFC0760">
<front>
<title abbrev="Internet Protocol">DoD standard Internet Protocol</title>
<author fullname="Jon Postel" initials="J." surname="Postel">
<organization>University of Southern California (USC)/Information Sciences Institute</organization>

<address>
<postal>
<street>4676 Admiralty Way</street>
<city>Marina del Rey</city>
<region>CA</region>
<code>90291</code>
<country>US</country>
</postal>

</address>
</author>

<date year="1980" day="1" month="January" />
</front>

<seriesInfo value="760" name="RFC" />
</reference>


<reference target2="reference.RFC.0761.xml" anchor="RFC0761">
<front>
<title abbrev="Transmission Control Protocol">DoD standard Transmission Control Protocol</title>
<author fullname="Jon Postel" initials="J." surname="Postel">
<organization>University of Southern California (USC)/Information Sciences Institute</organization>

<address>
<postal>
<street>4676 Admiralty Way</street>
<city>Marina del Rey</city>
<region>CA</region>
<code>90291</code>
<country>US</country>
</postal>

</address>
</author>

<date year="1980" day="1" month="January" />
</front>

<seriesInfo value="761" name="RFC" />
</reference>


<reference target2="reference.RFC.0762.xml" anchor="RFC0762">
<front>
<title abbrev="Assigned Numbers Network Numbers">Assigned numbers</title>
<author fullname="Jon Postel" initials="J." surname="Postel">
<organization>University of Southern California (USC)/Information Sciences Institute</organization>

<address>
<postal>
<street>4676 Admiralty Way</street>
<city>Marina del Rey</city>
<region>CA</region>
<code>90291</code>
<country>US</country>
</postal>

<phone>+1 213 822 1511</phone>
<email>POSTEL@ISIE</email>
</address>
</author>

<date year="1980" day="1" month="January" />

<abstract>
<t>This Network Working Group Request for Comments documents the currently assigned values from several series of numbers used in network protocol
implementations.</t>
</abstract>
</front>

<seriesInfo value="762" name="RFC" />
</reference>


<reference target2="reference.RFC.0763.xml" anchor="RFC0763">
<front>
<title>Role mailboxes</title>
<author fullname="Marshall Abrams" initials="M." surname="Abrams">
<organization>National Bureau of Standards (NBS)</organization>
</author>

<date year="1980" day="7" month="May" />

<abstract>
<t>Occasionally it is necessary to send mail to someone on the net who is known only as the incumbent in an official position.  Often the mail is undeliverable because of employee turnover.</t>

<t>We have also had such a problem at NBS and have therefore created MAIL address synonyms such as SYSTEMS, MANAGEMENT, and LIAISON to ensure that mail is correctly delivered no matter who the incumbent happens to be.</t>

<t>I suggest that all systems which permit MAIL address synonyms install them.  I further suggest that the NIC or the ARPANet management select a standardized set of synonyms, thus increasing their utility.</t>
</abstract>
</front>

<seriesInfo value="763" name="RFC" />
</reference>


<reference target2="reference.RFC.0764.xml" anchor="RFC0764">
<front>
<title>Telnet Protocol specification</title>
<author fullname="J. Postel" initials="J." surname="Postel">
<organization>University of Southern California (USC)/Information Sciences Institute</organization>

<address>
<postal>
<street>4676 Admiralty Way</street>
<city>Marina del Rey</city>
<region>CA</region>
<code>90291</code>
<country>US</country>
</postal>

<phone>+1 213 822 1511</phone>
</address>
</author>

<date year="1980" day="1" month="June" />
</front>

<seriesInfo value="764" name="RFC" />
</reference>


<reference target2="reference.RFC.0765.xml" anchor="RFC0765">
<front>
<title>File Transfer Protocol specification</title>
<author fullname="J. Postel" initials="J." surname="Postel">
<organization>University of Southern California (USC)/Information Sciences Institute</organization>

<address>
<postal>
<street>4676 Admiralty Way</street>
<city>Marina del Rey</city>
<region>CA</region>
<code>90291</code>
<country>US</country>
</postal>

<phone>+1 213 822 1511</phone>
</address>
</author>

<date year="1980" day="1" month="June" />
</front>

<seriesInfo value="765" name="RFC" />
</reference>


<reference target2="reference.RFC.0766.xml" anchor="RFC0766">
<front>
<title>Internet Protocol Handbook: Table of contents</title>
<author fullname="J. Postel" initials="J." surname="Postel">
<organization>University of Southern California (USC)/Information Sciences Institute</organization>

<address>
<postal>
<street>4676 Admiralty Way</street>
<city>Marina del Rey</city>
<region>CA</region>
<code>90291</code>
<country>US</country>
</postal>

<phone>+1 213 822 1511</phone>
</address>
</author>

<date year="1980" day="1" month="July" />

<abstract>
<t>In recent years the ARPA Network Research Program has had as one concern the interconnection of networks.  In the course of this research a family of protocols suitable for an internetwork environment has emerged.  Much of this work is documented in a series of project memos called Internet Experiment Notes or IENs.  A few of these IENs document protocols in the internet protocol family.  Most of the major internet protocol documents have also been issued as RFCs.</t>

<t>The situation has evolved to the point that it is appropriate for the internet family of protocols to replace the old ARPANET protocols.  To this end an Internet Protocol Handbook will be prepared by the Network Information Center.  This Handbook is tentatively planned to be available at the end of 1980.  This Internet Protocol Handbook will closely parallel the old ARPANET Protocol Handbook, and will primarily be a collection of existing RFCs and IENs.</t>
</abstract>
</front>

<seriesInfo value="766" name="RFC" />
</reference>


<reference target2="reference.RFC.0767.xml" anchor="RFC0767">
<front>
<title>Structured format for transmission of multi-media documents</title>
<author fullname="Jonathan B. Postel" initials="J." surname="Postel">
<organization>University of Southern California (USC)/Information Sciences Institute</organization>

<address>
<postal>
<street>4676 Admiralty Way</street>
<city>Marina del Rey</city>
<region>CA</region>
<code>90291</code>
<country>US</country>
</postal>

<phone>+1 213 822 1511</phone>
</address>
</author>

<date year="1980" day="1" month="August" />
</front>

<seriesInfo value="767" name="RFC" />
</reference>


<reference target2="reference.RFC.0768.xml" anchor="RFC0768">
<front>
<title>User Datagram Protocol</title>
<author fullname="J. Postel" initials="J." surname="Postel">
<organization>University of Southern California (USC)/Information Sciences Institute</organization>

<address>
<postal>
<street>4676 Admiralty Way</street>
<city>Marina del Rey</city>
<region>CA</region>
<code>90291</code>
<country>US</country>
</postal>

<phone>+1 213 822 1511</phone>
</address>
</author>

<date year="1980" day="28" month="August" />
</front>

<seriesInfo value="6" name="STD" />
<seriesInfo value="768" name="RFC" />
</reference>


<reference target2="reference.RFC.0769.xml" anchor="RFC0769">
<front>
<title>Rapicom 450 facsimile file format</title>
<author fullname="J. Postel" initials="J." surname="Postel">
<organization>University of Southern California (USC)/Information Sciences Institute</organization>

<address>
<postal>
<street>4676 Admiralty Way</street>
<city>Marina del Rey</city>
<region>CA</region>
<code>90291</code>
<country>US</country>
</postal>

<phone>+1 213 822 1511</phone>
</address>
</author>

<date year="1980" day="26" month="September" />
</front>

<seriesInfo value="769" name="RFC" />
</reference>


<reference target2="reference.RFC.0770.xml" anchor="RFC0770">
<front>
<title abbrev="Assigned Numbers Network Numbers">Assigned numbers</title>
<author fullname="Jon Postel" initials="J." surname="Postel">
<organization>University of Southern California (USC)/Information Sciences Institute</organization>

<address>
<postal>
<street>4676 Admiralty Way</street>
<city>Marina del Rey</city>
<region>CA</region>
<code>90291</code>
<country>US</country>
</postal>

<phone>+1 213 822 1511</phone>
<email>POSTEL@ISIF</email>
</address>
</author>

<date year="1980" day="1" month="September" />

<abstract>
<t>This Network Working Group Request for Comments documents the currently assigned values from several series of numbers used in network protocol 
implementations.</t>
</abstract>
</front>

<seriesInfo value="770" name="RFC" />
</reference>


<reference target2="reference.RFC.0771.xml" anchor="RFC0771">
<front>
<title>Mail transition plan</title>
<author fullname="V. Cerf" initials="V." surname="Cerf">
<organization>Advanced Research Projects Agency (ARPA)</organization>
</author>

<author fullname="J. Postel" initials="J." surname="Postel">
<organization>University of Southern California (USC)/Information Sciences Institute</organization>

<address>
<postal>
<street>4676 Admiralty Way</street>
<city>Marina del Rey</city>
<region>CA</region>
<code>90291</code>
<country>US</country>
</postal>

<phone>+1 213 822 1511</phone>
</address>
</author>

<date year="1980" day="1" month="September" />
</front>

<seriesInfo value="771" name="RFC" />
</reference>


<reference target2="reference.RFC.0772.xml" anchor="RFC0772">
<front>
<title>Mail Transfer Protocol</title>
<author fullname="S. Sluizer" initials="S." surname="Sluizer">
<organization>University of Southern California (USC)/Information Sciences Institute</organization>

<address>
<postal>
<street>4676 Admiralty Way</street>
<city>Marina del Rey</city>
<region>CA</region>
<code>90291</code>
<country>US</country>
</postal>

<phone>+1 213 822 1511</phone>
</address>
</author>

<author fullname="J. Postel" initials="J." surname="Postel">
<organization>University of Southern California (USC)/Information Sciences Institute</organization>

<address>
<postal>
<street>4676 Admiralty Way</street>
<city>Marina del Rey</city>
<region>CA</region>
<code>90291</code>
<country>US</country>
</postal>

<phone>+1 213 822 1511</phone>
</address>
</author>

<date year="1980" day="1" month="September" />
</front>

<seriesInfo value="772" name="RFC" />
</reference>


<reference target2="reference.RFC.0773.xml" anchor="RFC0773">
<front>
<title>Comments on NCP/TCP mail service transition strategy</title>
<author fullname="V. Cerf" initials="V." surname="Cerf">
<organization>Defense Advanced Research Projects Agency (DARPA)</organization>
</author>

<date year="1980" day="1" month="October" />
</front>

<seriesInfo value="773" name="RFC" />
</reference>


<reference target2="reference.RFC.0774.xml" anchor="RFC0774">
<front>
<title abbrev="Internet Protocol Handbook">Internet Protocol Handbook: Table of contents</title>
<author fullname="J. Postel" initials="J." surname="Postel">
<organization>University of Southern California (USC)/Information Sciences Institute</organization>

<address>
<postal>
<street>4676 Admiralty Way</street>
<city>Marina del Rey</city>
<region>CA</region>
<code>90291</code>
<country>US</country>
</postal>

<phone>+1 213 822 1511</phone>
</address>
</author>

<date year="1980" day="1" month="October" />

<abstract>
<t>The internet family of protocols is replacing the old ARPANET protocols. To this end an Internet Protocol Handbook will be prepared by the Network Information Center.  This Handbook is tentatively planned to be available at the end of 1980.  This Internet Protocol Handbook will closely parallel the old ARPANET Protocol Handbook, and will primarily be a collection of existing RFCs and IENs.</t>
</abstract>
</front>

<seriesInfo value="774" name="RFC" />
</reference>


<reference target2="reference.RFC.0775.xml" anchor="RFC0775">
<front>
<title>Directory oriented FTP commands</title>
<author fullname="David Mankins" initials="D." surname="Mankins">
<organization />

<address>
<email>dm@bbn-unix</email>
</address>
</author>

<author fullname="Dan Franklin" initials="D." surname="Franklin">
<organization />

<address>
<email>dan@bbn-unix</email>
</address>
</author>

<author fullname="A. D. Owen" initials="A." surname="Owen">
<organization />

<address>
<email>ADOwen@bbnd</email>
</address>
</author>

<date year="1980" day="1" month="December" />

<abstract>
<t>As a part of the Remote Site Maintenance (RSM) project for  ARPA, BBN has installed and maintains the software of several DEC PDP-11s running the Unix operating system.  Since Unix has a tree-like directory structure, in which directories are as easy to manipulate as ordinary files, we  have  found  it  convenient  to expand  the FTP servers on these machines to include commands which deal with the creation of  directories.   Since  there are other hosts on the ARPA net which have tree-like directories, including Tops-20 and  Multics, we have tried to make these commands as general as possible.</t>
</abstract>
</front>

<seriesInfo value="775" name="RFC" />
</reference>


<reference target2="reference.RFC.0776.xml" anchor="RFC0776">
<front>
<title abbrev="Assigned Numbers Network Numbers">Assigned numbers</title>
<author fullname="Jon Postel" initials="J." surname="Postel">
<organization>University of Southern California (USC) / Information Sciences Institue</organization>

<address>
<postal>
<street>4676 Admiralty Way</street>
<city>Marina del Rey</city>
<region>CA</region>
<code>90291</code>
<country>US</country>
</postal>

<phone>+1 213 822 1511</phone>
<email>POSTEL@ISIF</email>
</address>
</author>

<date year="1981" day="1" month="January" />

<abstract>
<t>This Network Working Group Request for Comments documents the currently assigned values from several series of numbers used in network protocol
implementations.</t>
</abstract>
</front>

<seriesInfo value="776" name="RFC" />
</reference>


<reference target2="reference.RFC.0777.xml" anchor="RFC0777">
<front>
<title>Internet Control Message Protocol</title>
<author fullname="J. Postel" initials="J." surname="Postel">
<organization>University of Southern California (USC)/Information Sciences Institute</organization>

<address>
<postal>
<street>4676 Admiralty Way</street>
<city>Marina del Rey</city>
<region>CA</region>
<code>90291</code>
<country>US</country>
</postal>

<phone>+1 213 822 1511</phone>
</address>
</author>

<date year="1981" day="1" month="April" />
</front>

<seriesInfo value="777" name="RFC" />
</reference>


<reference target2="reference.RFC.0778.xml" anchor="RFC0778">
<front>
<title>DCNET Internet Clock Service</title>
<author fullname="D. L. Mills" initials="D." surname="Mills">
<organization>COMSAT Laboratories</organization>
</author>

<date year="1981" day="18" month="April" />
</front>

<seriesInfo value="778" name="RFC" />
</reference>


<reference target2="reference.RFC.0779.xml" anchor="RFC0779">
<front>
<title>Telnet send-location option</title>
<author fullname="E. Killian" initials="E." surname="Killian">
<organization>LLL</organization>
</author>

<date year="1981" day="1" month="April" />
</front>

<seriesInfo value="779" name="RFC" />
</reference>


<reference target2="reference.RFC.0780.xml" anchor="RFC0780">
<front>
<title>Mail Transfer Protocol</title>
<author fullname="Suzanne Sluizer" initials="S." surname="Sluizer">
<organization>University of Southern California (USC)/Information Sciences Institute</organization>

<address>
<postal>
<street>4676 Admiralty Way</street>
<city>Marina del Rey</city>
<region>CA</region>
<code>90291</code>
<country>US</country>
</postal>

<phone>+1 213 822 1511</phone>
</address>
</author>

<author fullname="Jonathan B. Postel" initials="J." surname="Postel">
<organization>University of Southern California (USC)/Information Sciences Institute</organization>

<address>
<postal>
<street>4676 Admiralty Way</street>
<city>Marina del Rey</city>
<region>CA</region>
<code>90291</code>
<country>US</country>
</postal>

<phone>+1 213 822 1511</phone>
</address>
</author>

<date year="1981" day="1" month="May" />
</front>

<seriesInfo value="780" name="RFC" />
</reference>


<reference target2="reference.RFC.0781.xml" anchor="RFC0781">
<front>
<title>Specification of the Internet Protocol (IP) timestamp option</title>
<author fullname="Zaw-Sing Su" initials="Z." surname="Su">
<organization>SRI International</organization>
</author>

<date year="1981" day="1" month="May" />
</front>

<seriesInfo value="781" name="RFC" />
</reference>


<reference target2="reference.RFC.0782.xml" anchor="RFC0782">
<front>
<title>Virtual Terminal management model</title>
<author fullname="Jose Nabielsky" initials="J." surname="Nabielsky">
<organization>The MITRE Corporation,  MITRE C(3) Division, (3) Operations</organization>

<address>
<postal>
<street>1820 Dolley Madison Boulevard</street>
<city>McLean</city>
<region>VA</region>
<code>22102-3481</code>
<country>US</country>
</postal>

</address>
</author>

<author fullname="Anita P. Skelton" initials="A." surname="Skelton">
<organization>The MITRE Corporation,  MITRE C(3) Division, (3) Operations</organization>

<address>
<postal>
<street>1820 Dolley Madison Boulevard</street>
<city>McLean</city>
<region>VA</region>
<code>22102-3481</code>
<country>US</country>
</postal>

</address>
</author>

<date year="1981" day="1" month="January" />
</front>

<seriesInfo value="782" name="RFC" />
</reference>


<reference target2="reference.RFC.0783.xml" anchor="RFC0783">
<front>
<title>TFTP Protocol (revision 2)</title>
<author fullname="K. R. Sollins" initials="K." surname="Sollins">
<organization>Massechusetts Institute of Technology (MIT)</organization>
</author>

<date year="1981" day="1" month="June" />
</front>

<seriesInfo value="783" name="RFC" />
</reference>


<reference target2="reference.RFC.0784.xml" anchor="RFC0784">
<front>
<title abbrev="ISI TOPS20 Implementation">Mail Transfer Protocol: ISI TOPS20 implementation</title>
<author fullname="S. Sluizer" initials="S." surname="Sluizer">
<organization>University of Southern California (USC)/Information Sciences Institute</organization>

<address>
<postal>
<street>4676 Admiralty Way</street>
<city>Marina del Rey</city>
<region>CA</region>
<code>90291</code>
<country>US</country>
</postal>

<phone>+1 213 822 1511</phone>
</address>
</author>

<author fullname="J. Postel" initials="J." surname="Postel">
<organization>University of Southern California (USC)/Information Sciences Institute</organization>

<address>
<postal>
<street>4676 Admiralty Way</street>
<city>Marina del Rey</city>
<region>CA</region>
<code>90291</code>
<country>US</country>
</postal>

<phone>+1 213 822 1511</phone>
</address>
</author>

<date year="1981" day="1" month="July" />

<abstract>
<t>We are creating an implementation of MTP for TOPS20.  The programs are written in BLISS-10.  This implementation supports the MTP user and server functions using both TCP and NCP transport services, and provides interfaces to other mail delivery mechanisms.</t>
</abstract>
</front>

<seriesInfo value="784" name="RFC" />
</reference>


<reference target2="reference.RFC.0785.xml" anchor="RFC0785">
<front>
<title abbrev="ISI TOPS20 File Definitions">Mail Transfer Protocol: ISI TOPS20 file definitions</title>
<author fullname="S. Sluizer" initials="S." surname="Sluizer">
<organization>University of Southern California (USC)/Information Sciences Institute</organization>

<address>
<postal>
<street>4676 Admiralty Way</street>
<city>Marina del Rey</city>
<region>CA</region>
<code>90291</code>
<country>US</country>
</postal>

<phone>+1 213 822 1511</phone>
</address>
</author>

<author fullname="J. Postel" initials="J." surname="Postel">
<organization>University of Southern California (USC)/Information Sciences Institute</organization>

<address>
<postal>
<street>4676 Admiralty Way</street>
<city>Marina del Rey</city>
<region>CA</region>
<code>90291</code>
<country>US</country>
</postal>

<phone>+1 213 822 1511</phone>
</address>
</author>

<date year="1981" day="1" month="July" />
</front>

<seriesInfo value="785" name="RFC" />
</reference>


<reference target2="reference.RFC.0786.xml" anchor="RFC0786">
<front>
<title abbrev="ISI TOPS20 MTP-NIMAIL Interface">Mail Transfer Protocol: ISI TOPS20 MTP-NIMAIL interface</title>
<author fullname="S. Sluizer" initials="S." surname="Sluizer">
<organization>University of Southern California (USC)/Information Sciences Institute</organization>

<address>
<postal>
<street>4676 Admiralty Way</street>
<city>Marina del Rey</city>
<region>CA</region>
<code>90291</code>
<country>US</country>
</postal>

<phone>+1 213 822 1511</phone>
</address>
</author>

<author fullname="J. Postel" initials="J." surname="Postel">
<organization>University of Southern California (USC)/Information Sciences Institute</organization>

<address>
<postal>
<street>4676 Admiralty Way</street>
<city>Marina del Rey</city>
<region>CA</region>
<code>90291</code>
<country>US</country>
</postal>

<phone>+1 213 822 1511</phone>
</address>
</author>

<date year="1981" day="1" month="July" />
</front>

<seriesInfo value="786" name="RFC" />
</reference>


<reference target2="reference.RFC.0787.xml" anchor="RFC0787">
<front>
<title abbrev="Connectionless Data Transmission">Connectionless data transmission survey/tutorial</title>
<author fullname="A. Lyman Chapin" initials="A." surname="Chapin">
<organization>Data General Corporation</organization>

<address>
<postal>
<street>4400 Computer Drive</street>
<street>MS E111</street>
<city>Westborough</city>
<region>MA</region>
<code>01580</code>
<country>US</country>
</postal>

<phone>+1 617 366 8911 x3056</phone>
</address>
</author>

<date year="1981" day="1" month="July" />

<abstract>
<t>The increasingly  familiar and ubiquitous Reference Model of Open  Systems Interconnection, currently being considered by the International Organization  for Standardization (ISO) for promotion to the status of a Draft International Standard, is based on the explicit assumption that a "connection" - an association between two or  more  communicating  entities, possessing certain characteristics over and above those possessed by the entities themselves  -   is required for the transfer of data in an Open Systems Interconnection (OSI)  environment.  Although  the connection-oriented model of communications behavior has proven to be an extremely powerful concept, and has been applied successfully to the design and implementation of protocols and systems covering a wide  range of applications, a growing body of research and experience suggests that a complementary concept  -  connectionless data transmission  -  is an essential part of the Open Systems  Interconnection architecture, and should be embraced  as such by the OSI Reference Model.  This paper explores the concept of connectionless data transmission and its relationship to the more familiar concepts of connection-oriented  data transfer, developing a rationale for the  inclusion of the connectionless concept in the Reference Model  as an integral part of the standard description of the OSI architecture.</t>
</abstract>
</front>

<seriesInfo value="787" name="RFC" />
</reference>


<reference target2="reference.RFC.0788.xml" anchor="RFC0788">
<front>
<title>Simple Mail Transfer Protocol</title>
<author fullname="Jonathan B. Postel" initials="J." surname="Postel">
<organization>University of Southern California (USC)/Information Sciences Institute</organization>

<address>
<postal>
<street>4676 Admiralty Way</street>
<city>Marina del Rey</city>
<region>CA</region>
<code>90291</code>
<country>US</country>
</postal>

<phone>+1 213 822 1511</phone>
</address>
</author>

<date year="1981" day="1" month="November" />
</front>

<seriesInfo value="788" name="RFC" />
</reference>


<reference target2="reference.RFC.0789.xml" anchor="RFC0789">
<front>
<title>Vulnerabilities of network control protocols: An example</title>
<author fullname="Eric C. Rosen" initials="E." surname="Rosen">
<organization>Bolt Beranek and Newman Inc.</organization>
</author>

<date year="1981" day="1" month="July" />

<abstract>
<t>On  October 27, 1980, there was an unusual occurrence on the ARPANET. For a period of several hours, the network appeared  to be  unusable, due to what was later diagnosed as a high priority software process running out of control. Network-wide disturbances are extremely unusual  in the ARPANET (none has occurred in several years), and as a result, many  people have expressed  interest  in  learning more about the etiology of this particular incident.  The purpose of this note is to explain what the symptoms of the problem  were, what the underlying  causes were, and what lessons can be drawn. As we shall see, the immediate cause of the problem was  a  rather  freakish  hardware malfunction  (which is not likely to recur) which caused a faulty sequence of network control packets to be generated.  This faulty sequence of control packets in turn affected the apportionment of software resources in the IMPs, causing one of the IMP processes to use an excessive amount of resources, to the detriment of other IMP processes.  Restoring  the  network to operational condition  was  a  relatively straightforward task.  There was no damage other than the outage itself, and no residual problems once the network was restored.  Nevertheless, it is quite interesting to see the way in which unusual  (indeed, unique) circumstances can bring out vulnerabilities in network control protocols, and that shall be the focus of this paper.</t>
</abstract>
</front>

<seriesInfo value="789" name="RFC" />
</reference>


<reference target2="reference.RFC.0790.xml" anchor="RFC0790">
<front>
<title abbrev="Assigned Numbers Network Numbers">Assigned numbers</title>
<author fullname="J. Postel" initials="J." surname="Postel">
<organization>University of Southern California (USC)/Information Sciences Institute</organization>

<address>
<postal>
<street>4676 Admiralty Way</street>
<city>Marina del Rey</city>
<region>CA</region>
<code>90291</code>
<country>US</country>
</postal>

<phone>+1 213 822 1511</phone>
</address>
</author>

<date year="1981" day="1" month="September" />

<abstract>
<t>This Network Working Group Request for Comments documents the currently assigned values from several series of numbers used in network protocol implementations.</t>
</abstract>
</front>

<seriesInfo value="790" name="RFC" />
</reference>


<reference target2="reference.RFC.0791.xml" anchor="RFC0791">
<front>
<title abbrev="Internet Protocol">Internet Protocol</title>
<author fullname="Jon Postel" initials="J." surname="Postel">
<organization>University of Southern California (USC)/Information Sciences Institute</organization>

<address>
<postal>
<street>4676 Admiralty Way</street>
<city>Marina del Rey</city>
<region>CA</region>
<code>90291</code>
<country>US</country>
</postal>

</address>
</author>

<date year="1981" day="1" month="September" />
</front>

<seriesInfo value="5" name="STD" />
<seriesInfo value="791" name="RFC" />
</reference>


<reference target2="reference.RFC.0792.xml" anchor="RFC0792">
<front>
<title>Internet Control Message Protocol</title>
<author fullname="J. Postel" initials="J." surname="Postel">
<organization>University of Southern California (USC)/Information Sciences Institute</organization>

<address>
<postal>
<street>4676 Admiralty Way</street>
<city>Marina del Rey</city>
<region>CA</region>
<code>90291</code>
<country>US</country>
</postal>

<phone>+1 213 822 1511</phone>
</address>
</author>

<date year="1981" day="1" month="September" />
</front>

<seriesInfo value="5" name="STD" />
<seriesInfo value="792" name="RFC" />
</reference>


<reference target2="reference.RFC.0793.xml" anchor="RFC0793">
<front>
<title abbrev="Transmission Control Protocol">Transmission Control Protocol</title>
<author fullname="Jon Postel" initials="J." surname="Postel">
<organization>University of Southern California (USC)/Information Sciences Institute</organization>

<address>
<postal>
<street>4676 Admiralty Way</street>
<city>Marina del Rey</city>
<region>CA</region>
<code>90291</code>
<country>US</country>
</postal>

</address>
</author>

<date year="1981" day="1" month="September" />
</front>

<seriesInfo value="7" name="STD" />
<seriesInfo value="793" name="RFC" />
</reference>


<reference target2="reference.RFC.0794.xml" anchor="RFC0794">
<front>
<title>Pre-emption</title>
<author fullname="V. Cerf" initials="V." surname="Cerf">
<organization>Advanced Research Projects Agency (ARPA)</organization>
</author>

<date year="1981" day="1" month="September" />

<abstract>
<t>In general, precedence is a tool for deciding how to allocate resources when systems are saturated.  In circuit switched systems, the resource is circuits; in message switched systems the resource is the message switch processor; and in packet switching the resource is the packet switching system itself.</t>

<t>This capability can be realized in AUTODIN II without adding any new mechanisms to TCP (except to make precedence of incoming connection requests visible to the processes which use TCP).  To allow pre-emptive access to a particular terminal, the software (i.e., THP) which supports terminal access to the TAC can be configured so as to always have a LISTEN posted for that terminal, even if the terminal has a connection in operation.  For example in the ARPANET TENEX systems, the user TELNET permits a user to have many connections open at one time - the user can switch among them at will.  To the extent that this can be done without violating security requirements, one could imagine a multi-connection THP which always leaves a LISTEN pending for incoming connection requests.  If a connection is established, the THP can decide, based on its precedence, whether to pre-empt any existing connection and to switch the user to the high precedence one.</t>
</abstract>
</front>

<seriesInfo value="794" name="RFC" />
</reference>


<reference target2="reference.RFC.0795.xml" anchor="RFC0795">
<front>
<title>Service mappings</title>
<author fullname="J. Postel" initials="J." surname="Postel">
<organization>University of Southern California (USC)/Information Sciences Institute</organization>

<address>
<postal>
<street>4676 Admiralty Way</street>
<city>Marina del Rey</city>
<region>CA</region>
<code>90291</code>
<country>US</country>
</postal>

<phone>+1 213 822 1511</phone>
</address>
</author>

<date year="1981" day="1" month="September" />

<abstract>
<t>This memo describes the relationship between the Internet Protocol (IP)Type of Service and the service parameters of specific networks.</t>
</abstract>
</front>

<seriesInfo value="795" name="RFC" />
</reference>


<reference target2="reference.RFC.0796.xml" anchor="RFC0796">
<front>
<title>Address mappings</title>
<author fullname="J. Postel" initials="J." surname="Postel">
<organization>University of Southern California (USC)/Information Sciences Institute</organization>

<address>
<postal>
<street>4676 Admiralty Way</street>
<city>Marina del Rey</city>
<region>CA</region>
<code>90291</code>
<country>US</country>
</postal>

<phone>+1 213 822 1511</phone>
</address>
</author>

<date year="1981" day="1" month="September" />
</front>

<seriesInfo value="796" name="RFC" />
</reference>


<reference target2="reference.RFC.0797.xml" anchor="RFC0797">
<front>
<title>Format for Bitmap files</title>
<author fullname="Alan R. Katz" initials="A." surname="Katz">
<organization>University of Southern California (USC)/Information Sciences Institute</organization>

<address>
<postal>
<street>4676 Admiralty Way</street>
<city>Marina del Rey</city>
<region>CA</region>
<code>90291</code>
<country>US</country>
</postal>

<phone>+1 213 822 1511</phone>
</address>
</author>

<date year="1981" day="1" month="September" />

<abstract>
<t>This note describes a proposed format for storing simple bitmaps (one bit per pixel) in a file. These  files may be very  large and the intent is to use this format for short term storage and passing data between closely coupled  programs. The data in the file should be stored in 8-bit bytes (octets).  Bitmaps may be any size.</t>
</abstract>
</front>

<seriesInfo value="797" name="RFC" />
</reference>


<reference target2="reference.RFC.0798.xml" anchor="RFC0798">
<front>
<title abbrev="DECODING FACSIMILE DATA">Decoding facsimile data from the Rapicom 450</title>
<author fullname="Alan R. Katz" initials="A." surname="Katz">
<organization>University of Southern California (USC)/Information Sciences Institute</organization>

<address>
<postal>
<street>4676 Admiralty Way</street>
<city>Marina del Rey</city>
<region>CA</region>
<code>90291</code>
<country>US</country>
</postal>

<phone>+1 213 822 1511</phone>
</address>
</author>

<date year="1981" day="1" month="September" />
</front>

<seriesInfo value="798" name="RFC" />
</reference>


<reference target2="reference.RFC.0799.xml" anchor="RFC0799">
<front>
<title>Internet name domains</title>
<author fullname="D. L. Mills" initials="D." surname="Mills">
<organization>COMSAT Laboratories</organization>
</author>

<date year="1981" day="1" month="September" />
</front>

<seriesInfo value="799" name="RFC" />
</reference>


<reference target2="reference.RFC.0800.xml" anchor="RFC0800">
<front>
<title>Request For Comments summary notes: 700-799</title>
<author fullname="J. Postel" initials="J." surname="Postel">
<organization>University of Southern California (USC)/Information Sciences Institute</organization>

<address>
<postal>
<street>4676 Admiralty Way</street>
<city>Marina del Rey</city>
<region>CA</region>
<code>90291</code>
<country>US</country>
</postal>

<phone>+1 213 822 1511</phone>
</address>
</author>

<author fullname="J. Vernon" initials="J." surname="Vernon">
<organization>University of Southern California (USC)/Information Sciences Institute</organization>

<address>
<postal>
<street>4676 Admiralty Way</street>
<city>Marina del Rey</city>
<region>CA</region>
<code>90291</code>
<country>US</country>
</postal>

<phone>+1 213 822 1511</phone>
</address>
</author>

<date year="1982" day="1" month="November" />

<abstract>
<t>This RFC is a slightly annotated list of the 100 RFCs from RFC 700 through RFC 799.  This is a kind of status report on these RFCs.</t>
</abstract>
</front>

<seriesInfo value="800" name="RFC" />
</reference>


<reference target2="reference.RFC.0801.xml" anchor="RFC0801">
<front>
<title>NCP/TCP transition plan</title>
<author fullname="J. Postel" initials="J." surname="Postel">
<organization>University of Southern California (USC)/Information Sciences Institute</organization>

<address>
<postal>
<street>4676 Admiralty Way</street>
<city>Marina del Rey</city>
<region>CA</region>
<code>90291</code>
<country>US</country>
</postal>

<phone>+1 213 822 1511</phone>
</address>
</author>

<date year="1981" day="1" month="November" />
</front>

<seriesInfo value="801" name="RFC" />
</reference>


<reference target2="reference.RFC.0802.xml" anchor="RFC0802">
<front>
<title>ARPANET 1822L Host Access Protocol</title>
<author fullname="Andrew G. Malis" initials="A." surname="Malis">
<organization>Bolt Beranek and Newman Inc.</organization>

<address>
<email>malis@bbn-unix</email>
</address>
</author>

<date year="1981" day="1" month="November" />
</front>

<seriesInfo value="802" name="RFC" />
</reference>


<reference target2="reference.RFC.0803.xml" anchor="RFC0803">
<front>
<title>Dacom 450/500 facsimile data transcoding</title>
<author fullname="A. Agarwal" initials="A." surname="Agarwal">
<organization />
</author>

<author fullname="M. J. O&apos;Connor" initials="M." surname="O&apos;Connor">
<organization />
</author>

<author fullname="D. L. Mills" initials="D." surname="Mills">
<organization />
</author>

<date year="1981" day="2" month="November" />
</front>

<seriesInfo value="803" name="RFC" />
</reference>


<reference target2="reference.RFC.0804.xml" anchor="RFC0804">
<front>
<title>CCITT draft recommendation T.4</title>
<author>
<organization>International Telephone and Telegraph Consultative Committee (CCITT)</organization>
</author>

<date year="1981" day="1" month="January" />
</front>

<seriesInfo value="804" name="RFC" />
</reference>


<reference target2="reference.RFC.0805.xml" anchor="RFC0805">
<front>
<title>Computer mail meeting notes</title>
<author fullname="J. Postel" initials="J." surname="Postel">
<organization>University of Southern California (USC)/Information Sciences Institute</organization>

<address>
<postal>
<street>4676 Admiralty Way</street>
<city>Marina del Rey</city>
<region>CA</region>
<code>90291</code>
<country>US</country>
</postal>

<phone>+1 213 822 1511</phone>
</address>
</author>

<date year="1982" day="8" month="February" />
</front>

<seriesInfo value="805" name="RFC" />
</reference>


<reference target2="reference.RFC.0806.xml" anchor="RFC0806">
<front>
<title>Proposed Federal Information Processing Standard: Specification for message format for computer based message systems</title>
<author>
<organization>National Bureau of Standards</organization>
</author>

<date year="1981" day="1" month="September" />
</front>

<seriesInfo value="806" name="RFC" />
</reference>


<reference target2="reference.RFC.0807.xml" anchor="RFC0807">
<front>
<title abbrev="Multi-Media Mail Meeting Notes">Multimedia mail meeting notes</title>
<author fullname="J. Postel" initials="J." surname="Postel">
<organization>University of Southern California (USC)/Information Sciences Institute</organization>

<address>
<postal>
<street>4676 Admiralty Way</street>
<city>Marina del Rey</city>
<region>CA</region>
<code>90291</code>
<country>US</country>
</postal>

<phone>+1 213 822 1511</phone>
</address>
</author>

<date year="1982" day="9" month="February" />
</front>

<seriesInfo value="807" name="RFC" />
</reference>


<reference target2="reference.RFC.0808.xml" anchor="RFC0808">
<front>
<title>Summary of computer mail services meeting held at BBN on 10 January 1979</title>
<author fullname="J. Postel" initials="J." surname="Postel">
<organization>University of Southern California (USC)/Information Sciences Institute</organization>

<address>
<postal>
<street>4676 Admiralty Way</street>
<city>Marina del Rey</city>
<region>CA</region>
<code>90291</code>
<country>US</country>
</postal>

<phone>+1 213 822 1511</phone>
</address>
</author>

<date year="1982" day="1" month="March" />
</front>

<seriesInfo value="808" name="RFC" />
</reference>


<reference target2="reference.RFC.0809.xml" anchor="RFC0809">
<front>
<title>UCL facsimile system</title>
<author fullname="Tawei Chang" initials="T." surname="Chang">
<organization>University College London (UCL), Department of Computer Science</organization>
</author>

<date year="1982" day="1" month="February" />

<abstract>
<t>This note describes the features of  the computerized facsimile system developed in the Department of Computer Science at UCL.  First its functions are considered and the related experimental work is reported.  Then the disciplines for system design are discussed.  Finally, the implementation of the systems are described, while detailed descriptions are given as appendices.</t>
</abstract>
</front>

<seriesInfo value="809" name="RFC" />
</reference>


<reference target2="reference.RFC.0810.xml" anchor="RFC0810">
<front>
<title abbrev="Host Table Specification">DoD Internet host table specification</title>
<author fullname="Elizabeth Feinler" initials="E." surname="Feinler">
<organization />
</author>

<author fullname="Ken Harrenstien" initials="K." surname="Harrenstien">
<organization />
</author>

<author fullname="Zaw-Sing Su" initials="Z." surname="Su">
<organization />
</author>

<author fullname="Vic White" initials="V." surname="White">
<organization>SRI International, Network Information Center</organization>
</author>

<date year="1982" day="1" month="March" />
</front>

<seriesInfo value="810" name="RFC" />
</reference>


<reference target2="reference.RFC.0811.xml" anchor="RFC0811">
<front>
<title>Hostnames Server</title>
<author fullname="Ken Harrenstien" initials="K." surname="Harrenstien">
<organization>SRI International, Network Information Center</organization>
</author>

<author fullname="Vic White" initials="V." surname="White">
<organization>SRI International, Network Information Center</organization>
</author>

<author fullname="Elizabeth Feinler" initials="E." surname="Feinler">
<organization>SRI International, Network Information Center</organization>
</author>

<date year="1982" day="1" month="March" />
</front>

<seriesInfo value="811" name="RFC" />
</reference>


<reference target2="reference.RFC.0812.xml" anchor="RFC0812">
<front>
<title>NICNAME/WHOIS</title>
<author fullname="Ken Harrenstien" initials="K." surname="Harrenstien">
<organization>SRI International, Network Information Center</organization>
</author>

<author fullname="Vic White" initials="V." surname="White">
<organization>SRI International, Network Information Center</organization>
</author>

<date year="1982" day="1" month="March" />
</front>

<seriesInfo value="812" name="RFC" />
</reference>


<reference target2="reference.RFC.0813.xml" anchor="RFC0813">
<front>
<title>Window and Acknowledgement Strategy in TCP</title>
<author fullname="David D. Clark" initials="D." surname="Clark">
<organization>Massachusetts Institute of Technology (MIT), Laboratory for Computer Science, Computer Systems and Communications Group</organization>
</author>

<date year="1982" day="1" month="July" />
</front>

<seriesInfo value="813" name="RFC" />
</reference>


<reference target2="reference.RFC.0814.xml" anchor="RFC0814">
<front>
<title>Name, addresses, ports, and routes</title>
<author fullname="David D. Clark" initials="D." surname="Clark">
<organization>Massachusetts Institute of Technology (MIT), Laboratory for Computer Science, Computer Systems and Communications Group</organization>
</author>

<date year="1982" day="1" month="July" />
</front>

<seriesInfo value="814" name="RFC" />
</reference>


<reference target2="reference.RFC.0815.xml" anchor="RFC0815">
<front>
<title>IP datagram reassembly algorithms</title>
<author fullname="David D. Clark" initials="D." surname="Clark">
<organization>Massachusetts Institute of Technology (MIT), Laboratory for Computer Science Computer Systems and Communications Group</organization>
</author>

<date year="1982" day="1" month="July" />
</front>

<seriesInfo value="815" name="RFC" />
</reference>


<reference target2="reference.RFC.0816.xml" anchor="RFC0816">
<front>
<title>Fault isolation and recovery</title>
<author fullname="David D. Clark" initials="D." surname="Clark">
<organization>Massachusetts Institute of Technology (MIT), Laboratory for Computer Science, Computer Systems and Communications Group</organization>
</author>

<date year="1982" day="1" month="July" />
</front>

<seriesInfo value="816" name="RFC" />
</reference>


<reference target2="reference.RFC.0817.xml" anchor="RFC0817">
<front>
<title>Modularity and efficiency in protocol implementation</title>
<author fullname="David D. Clark" initials="D." surname="Clark">
<organization>Massachusetts Institute of Technology (MIT), Laboratory for Computer Science, Computer Systems and Communications Group</organization>
</author>

<date year="1982" day="1" month="July" />
</front>

<seriesInfo value="817" name="RFC" />
</reference>


<reference target2="reference.RFC.0818.xml" anchor="RFC0818">
<front>
<title abbrev="Remote User Telnet Service">Remote User Telnet service</title>
<author fullname="J. Postel" initials="J." surname="Postel">
<organization>University of Southern California (USC)/Information Sciences Institute</organization>

<address>
<postal>
<street>4676 Admiralty Way</street>
<city>Marina del Rey</city>
<region>CA</region>
<code>90291</code>
<country>US</country>
</postal>

<phone>+1 213 822 1511</phone>
</address>
</author>

<date year="1982" day="1" month="November" />
</front>

<seriesInfo value="818" name="RFC" />
</reference>


<reference target2="reference.RFC.0819.xml" anchor="RFC0819">
<front>
<title>Domain naming convention for Internet user applications</title>
<author fullname="Zaw-Sing Su" initials="Z." surname="Su">
<organization>SRI International</organization>
</author>

<author fullname="J. Postel" initials="J." surname="Postel">
<organization>University of Southern California (USC)/Information Sciences Institute</organization>

<address>
<postal>
<street>4676 Admiralty Way</street>
<city>Marina del Rey</city>
<region>CA</region>
<code>90291</code>
<country>US</country>
</postal>

<phone>+1 213 822 1511</phone>
</address>
</author>

<date year="1982" day="1" month="August" />
</front>

<seriesInfo value="819" name="RFC" />
</reference>


<reference target2="reference.RFC.0820.xml" anchor="RFC0820">
<front>
<title>Assigned numbers</title>
<author fullname="Jon Postel" initials="J." surname="Postel">
<organization>University of Southern California (USC)/Information Sciences Institute</organization>

<address>
<postal>
<street>4676 Admiralty Way</street>
<city>Marina del Rey</city>
<region>CA</region>
<code>90291</code>
<country>US</country>
</postal>

<phone>+1 213 822 1511</phone>
<email>POSTEL@ISIF</email>
</address>
</author>

<author fullname="J. Vernon" initials="J." surname="Vernon">
<organization />
</author>

<date year="1982" day="14" month="August" />

<abstract>
<t>This Network Working Group Request for Comments documents the currently assigned values from several series of numbers used in network protocol implementations.</t>
</abstract>
</front>

<seriesInfo value="820" name="RFC" />
</reference>


<reference target2="reference.RFC.0821.xml" anchor="RFC0821">
<front>
<title>Simple Mail Transfer Protocol</title>
<author fullname="Jonathan B. Postel" initials="J.B." surname="Postel">
<organization>University of Southern California (USC)/Information Sciences Institute</organization>

<address>
<postal>
<street>4676 Admiralty Way</street>
<city>Marina del Rey</city>
<region>CA</region>
<code>90291</code>
<country>US</country>
</postal>

<phone>+1 213 822 1511</phone>
</address>
</author>

<date year="1982" day="1" month="August" />
</front>

<seriesInfo value="10" name="STD" />
<seriesInfo value="821" name="RFC" />
</reference>


<reference target2="reference.RFC.0822.xml" anchor="RFC0822">
<front>
<title abbrev="Standard for ARPA Internet Text Messages">Standard for the format of ARPA Internet text messages</title>
<author fullname="David H. Crocker" initials="D.H." surname="Crocker">
<organization>University of Delaware, Dept. of Electrical Engineering</organization>

<address>
<postal>
<street />
<city>Newark</city>
<region>DE</region>
<code>19711</code>
<country>US</country>
</postal>

<email>DCrocker@UDel-Relay</email>
</address>
</author>

<date year="1982" day="13" month="August" />
</front>

<seriesInfo value="11" name="STD" />
<seriesInfo value="822" name="RFC" />
</reference>


<reference target2="reference.RFC.0823.xml" anchor="RFC0823">
<front>
<title abbrev="DARPA Internet Gateway">DARPA Internet gateway</title>
<author fullname="Robert Hinden" initials="R." surname="Hinden">
<organization>Bolt Beranek and Newman Inc. (BBN)</organization>

<address>
<postal>
<street>10 Moulton St.</street>
<city>Cambridge</city>
<region>MA</region>
<code>02238</code>
<country>US</country>
</postal>

</address>
</author>

<author fullname="Alan Sheltzer" initials="A." surname="Sheltzer">
<organization>Bolt Beranek and Newman Inc. (BBN)</organization>

<address>
<postal>
<street>10 Moulton St.</street>
<city>Cambridge</city>
<region>MA</region>
<code>02238</code>
<country>US</country>
</postal>

</address>
</author>

<author>
<organization>Defense Advanced Research Projects Agency, Information Processing Techniques Office</organization>

<address>
<postal>
<street>1400 Wilson Boulevard</street>
<city>Arlington</city>
<region>VA</region>
<code>22209</code>
<country>US</country>
</postal>

</address>
</author>

<date year="1982" day="1" month="September" />

<abstract>
<t>This RFC is a status report on the Internet Gateway developed by BBN. It describes the Internet Gateway as of September 1982.  This memo presents detailed descriptions of message formats and gateway procedures, however this is not an implementation specification, and such details are subject to change.</t>
</abstract>
</front>

<seriesInfo value="823" name="RFC" />
</reference>


<reference target2="reference.RFC.0824.xml" anchor="RFC0824">
<front>
<title abbrev="DOS-26 Rev A - Virtual Local Networ">CRONUS Virtual Local Network</title>
<author fullname="William I. MacGregor" initials="W." surname="MacGregor">
<organization>Bolt Beranek and Newman Inc. (BBN)</organization>
</author>

<author fullname="Daniel C. Tappan" initials="D." surname="Tappan">
<organization>Bolt Beranek and Newman Inc. (BBN)</organization>
</author>

<date year="1982" day="25" month="August" />

<abstract>
<t>The purpose of this note is to describe the CRONUS Virtual Local Network, especially the addressing related features. These features include a method for mapping between Internet Addresses and Local Network addresses.  This is a topic of current concern in the ARPA Internet community.  This note is intended to stimulate discussion.  This is not a specification of an Internet Standard.</t>
</abstract>
</front>

<seriesInfo value="824" name="RFC" />
</reference>


<reference target2="reference.RFC.0825.xml" anchor="RFC0825">
<front>
<title abbrev="RFC on RFCs">Request for comments on Requests For Comments</title>
<author fullname="J. Postel" initials="J." surname="Postel">
<organization>University of Southern California (USC)/Information Sciences Institute</organization>

<address>
<postal>
<street>4676 Admiralty Way</street>
<city>Marina del Rey</city>
<region>CA</region>
<code>90291</code>
<country>US</country>
</postal>

<phone>+1 213 822 1511</phone>
</address>
</author>

<date year="1982" day="1" month="November" />

<abstract>
<t>This RFC is intended to clarify the status of RFCs and to provide some guidance for the authors of RFCs in the future.  It is in a sense a specification for RFCs.</t>
</abstract>
</front>

<seriesInfo value="825" name="RFC" />
</reference>


<reference target2="reference.RFC.0826.xml" anchor="RFC0826">
<front>
<title>Ethernet Address Resolution Protocol: Or converting network protocol addresses to 48.bit Ethernet address for transmission on Ethernet hardware</title>
<author fullname="David C. Plummer" initials="D." surname="Plummer">
<organization>Symbolics, Inc.</organization>

<address>
<postal>
<street>243 Vassar Street</street>
<city>Cambridge</city>
<region>MA</region>
<code>02139</code>
<country>US</country>
</postal>

<email>DCP@MIT-MC</email>
</address>
</author>

<date year="1982" day="1" month="November" />

<abstract>
<t>The implementation of protocol P on a sending host S decides, through protocol P's routing mechanism, that it wants to transmit to a target host T located some place on a connected piece of 10Mbit Ethernet cable.  To actually transmit the Ethernet packet a 48.bit Ethernet address must be generated.  The addresses of hosts within protocol P are not always compatible with the corresponding Ethernet address (being different lengths or values).  Presented here is a protocol that allows dynamic distribution of the information needed to build tables to translate an address A in protocol P's address space into a 48.bit Ethernet address.</t>

<t>Generalizations have been made which allow the protocol to be used for non-10Mbit Ethernet hardware.  Some packet radio networks are examples of such hardware.</t>

<t>The protocol proposed here is the result of a great deal of discussion with several other people, most notably J. Noel Chiappa, Yogen Dalal, and James E. Kulp, and helpful comments from David Moon.</t>

<t>The purpose of this RFC is to present a method of Converting Protocol Addresses (e.g., IP addresses) to Local Network Addresses (e.g., Ethernet addresses).  This is a issue of general concern in the ARPA Internet community at this time.  The method proposed here is presented for your consideration and comment.  This is not the specification of a Internet Standard.</t>
</abstract>
</front>

<seriesInfo value="37" name="STD" />
<seriesInfo value="826" name="RFC" />
</reference>


<reference target2="reference.RFC.0827.xml" anchor="RFC0827">
<front>
<title>Exterior Gateway Protocol (EGP)</title>
<author fullname="Eric C. Rosen" initials="E." surname="Rosen">
<organization>Bolt Beranek and Newman Inc. (BBN)</organization>
</author>

<date year="1982" day="1" month="October" />

<abstract>
<t>It is proposed to establish a standard for Gateway to Gateway procedures that allow the Gateways to be mutually suspicious.  This document is a DRAFT for that standard.  Your comments are strongly encouraged.</t>
</abstract>
</front>

<seriesInfo value="827" name="RFC" />
</reference>


<reference target2="reference.RFC.0828.xml" anchor="RFC0828">
<front>
<title>Data communications: IFIP's international "network" of experts</title>
<author fullname="K. Owen" initials="K." surname="Owen">
<organization>International Federation for Information Processing (IFIP)</organization>
</author>

<date year="1982" day="1" month="August" />

<abstract>
<t>This RFC is distributed to inform the ARPA Internet community of the activities of the IFIP technical committee on Data Communications, and to encourage participation in those activities</t>
</abstract>
</front>

<seriesInfo value="828" name="RFC" />
</reference>


<reference target2="reference.RFC.0829.xml" anchor="RFC0829">
<front>
<title abbrev="Remote User Telnet Service">Packet satellite technology reference sources</title>
<author fullname="Vinton G. Cerf" initials="V." surname="Cerf">
<organization>Defense Advanced Research Projects Agency (DARPA)</organization>
</author>

<date year="1982" day="1" month="November" />

<abstract>
<t>This paper describes briefly the packet satellite technology developed by the Defense Advanced Research Projects Agency and several other participating organizations in the U.K. and Norway and provides a biblography of relevant papers for researchers interested in experimental and operational experience with this dynamic satellite-sharing technique.</t>
</abstract>
</front>

<seriesInfo value="829" name="RFC" />
</reference>


<reference target2="reference.RFC.0830.xml" anchor="RFC0830">
<front>
<title>Distributed system for Internet name service</title>
<author fullname="Zaw-Sing Su" initials="Z." surname="Su">
<organization>SRI International</organization>

<address>
<postal>
<street>333 Ravenswood Avenue</street>
<city>Menlo Park</city>
<region>CA</region>
<code>94025</code>
<country>US</country>
</postal>

<phone>+1 415 859 4576</phone>
</address>
</author>

<date year="1982" day="1" month="October" />

<abstract>
<t>This RFC proposes a distributed name service for DARPA Internet.  Its purpose is to focus discussion on the subject.  It is hoped that a general consensus will emerge leading eventually to the adoption of standards.</t>
</abstract>
</front>

<seriesInfo value="830" name="RFC" />
</reference>


<reference target2="reference.RFC.0831.xml" anchor="RFC0831">
<front>
<title>Backup access to the European side of SATNET</title>
<author fullname="Robert Braden" initials="R." surname="Braden">
<organization>University College London</organization>
</author>

<date year="1982" day="1" month="December" />
</front>

<seriesInfo value="831" name="RFC" />
</reference>


<reference target2="reference.RFC.0832.xml" anchor="RFC0832">
<front>
<title>Who talks TCP?</title>
<author fullname="D. Smallberg" initials="D." surname="Smallberg">
<organization />
</author>

<date year="1982" day="7" month="December" />

<abstract>
<t>The list of hosts was taken from the NIC hostname table of 2-Dec-82.</t>
</abstract>
</front>

<seriesInfo value="832" name="RFC" />
</reference>


<reference target2="reference.RFC.0833.xml" anchor="RFC0833">
<front>
<title>Who talks TCP?</title>
<author fullname="D. Smallberg" initials="D." surname="Smallberg">
<organization />
</author>

<date year="1982" day="14" month="December" />

<abstract>
<t>The list of hosts was taken from the NIC hostname table of 2-Dec-82.</t>
</abstract>
</front>

<seriesInfo value="833" name="RFC" />
</reference>


<reference target2="reference.RFC.0834.xml" anchor="RFC0834">
<front>
<title>Who talks TCP?</title>
<author fullname="D. Smallberg" initials="D." surname="Smallberg">
<organization />
</author>

<date year="1982" day="22" month="December" />

<abstract>
<t>The list of hosts was taken from the NIC hostname table of 2-Dec-82.</t>
</abstract>
</front>

<seriesInfo value="834" name="RFC" />
</reference>


<reference target2="reference.RFC.0835.xml" anchor="RFC0835">
<front>
<title>Who talks TCP?</title>
<author fullname="D. Smallberg" initials="D." surname="Smallberg">
<organization />
</author>

<date year="1982" day="29" month="December" />

<abstract>
<t>The list of hosts was taken from the NIC hostname table of 2-Dec-82.</t>
</abstract>
</front>

<seriesInfo value="835" name="RFC" />
</reference>


<reference target2="reference.RFC.0836.xml" anchor="RFC0836">
<front>
<title>Who talks TCP?</title>
<author fullname="D. Smallberg" initials="D." surname="Smallberg">
<organization />
</author>

<date year="1983" day="5" month="January" />

<abstract>
<t>The list of hosts was taken from the NIC hostname table of 20-Dec-82.</t>
</abstract>
</front>

<seriesInfo value="836" name="RFC" />
</reference>


<reference target2="reference.RFC.0837.xml" anchor="RFC0837">
<front>
<title>Who talks TCP?</title>
<author fullname="D. Smallberg" initials="D." surname="Smallberg">
<organization />
</author>

<date year="1983" day="12" month="January" />

<abstract>
<t>The list of hosts was taken from the NIC hostname table of 31-Dec-82.</t>
</abstract>
</front>

<seriesInfo value="837" name="RFC" />
</reference>


<reference target2="reference.RFC.0838.xml" anchor="RFC0838">
<front>
<title>Who talks TCP?</title>
<author fullname="D. Smallberg" initials="D." surname="Smallberg">
<organization />
</author>

<date year="1983" day="20" month="January" />

<abstract>
<t>The list of hosts was taken from the NIC hostname table of 31-Dec-82.</t>
</abstract>
</front>

<seriesInfo value="838" name="RFC" />
</reference>


<reference target2="reference.RFC.0839.xml" anchor="RFC0839">
<front>
<title>Who talks TCP?</title>
<author fullname="D. Smallberg" initials="D." surname="Smallberg">
<organization />
</author>

<date year="1983" day="26" month="January" />

<abstract>
<t>The list of hosts was taken from the NIC hostname table of 31-Dec-82.</t>
</abstract>
</front>

<seriesInfo value="839" name="RFC" />
</reference>


<reference target2="reference.RFC.0840.xml" anchor="RFC0840">
<front>
<title>Official protocols</title>
<author fullname="J. Postel" initials="J." surname="Postel">
<organization>University of Southern California (USC)/Information Sciences Institute</organization>

<address>
<postal>
<street>4676 Admiralty Way</street>
<city>Marina del Rey</city>
<region>CA</region>
<code>90291</code>
<country>US</country>
</postal>

<phone>+1 213 822 1511</phone>
</address>
</author>

<date year="1983" day="13" month="April" />

<abstract>
<t>This RFC identifies the documents specifying the official protocols used
in the Internet</t>
</abstract>
</front>

<seriesInfo value="840" name="RFC" />
</reference>


<reference target2="reference.RFC.0841.xml" anchor="RFC0841">
<front>
<title abbrev="Federal Information Processing Standards Publication 98 27 January 1983 Announcing the Standard for MESSAGE FORMAT FOR COMPUTER BASED MESSAGE SYSTEMS">Specification for message format for Computer Based Message Systems</title>
<author>
<organization>National Bureau of Standards</organization>
</author>

<date year="1983" day="27" month="January" />

<abstract>
<t>This RFC is FIPS 98. The purpose of distributing this document as an RFC is to make it easily accesible to the ARPA research  community. This RFC does not specify a standard for the ARPA  Internet.</t>
</abstract>
</front>

<seriesInfo value="841" name="RFC" />
</reference>


<reference target2="reference.RFC.0842.xml" anchor="RFC0842">
<front>
<title>Who talks TCP? - survey of 1 February 83</title>
<author fullname="D. Smallberg" initials="D." surname="Smallberg">
<organization />
</author>

<date year="1983" day="3" month="February" />

<abstract>
<t>The list of hosts was taken from the NIC hostname table of 28-Jan-83.</t>
</abstract>
</front>

<seriesInfo value="842" name="RFC" />
</reference>


<reference target2="reference.RFC.0843.xml" anchor="RFC0843">
<front>
<title>Who talks TCP? - survey of 8 February 83</title>
<author fullname="D. Smallberg" initials="D." surname="Smallberg">
<organization />
</author>

<date year="1983" day="9" month="February" />

<abstract>
<t>The list of hosts was taken from the NIC hostname table of 3-Feb-83.</t>
</abstract>
</front>

<seriesInfo value="843" name="RFC" />
</reference>


<reference target2="reference.RFC.0844.xml" anchor="RFC0844">
<front>
<title>Who talks ICMP, too? - Survey of 18 February 1983</title>
<author fullname="R. Clements" initials="R." surname="Clements">
<organization />
</author>

<date year="1983" day="18" month="February" />

<abstract>
<t>A survey was undertaken to determine how many hosts are able to respond to TELNET connections from a user at a class C site. This requires, in addition to IP and TCP, participation in gateway routing via ICMP and handling of class C addresses.</t>
</abstract>
</front>

<seriesInfo value="844" name="RFC" />
</reference>


<reference target2="reference.RFC.0845.xml" anchor="RFC0845">
<front>
<title>Who talks TCP? - survey of 15 February 1983</title>
<author fullname="D. Smallberg" initials="D." surname="Smallberg">
<organization />
</author>

<date year="1983" day="17" month="February" />

<abstract>
<t>The list of hosts was taken from the NIC hostname table of 3-Feb-83.</t>
</abstract>
</front>

<seriesInfo value="845" name="RFC" />
</reference>


<reference target2="reference.RFC.0846.xml" anchor="RFC0846">
<front>
<title>Who talks TCP? - survey of 22 February 1983</title>
<author fullname="D. Smallberg" initials="D." surname="Smallberg">
<organization />
</author>

<date year="1983" day="23" month="February" />

<abstract>
<t>The list of hosts was taken from the NIC hostname table of 18-Feb-83.</t>
</abstract>
</front>

<seriesInfo value="846" name="RFC" />
</reference>


<reference target2="reference.RFC.0847.xml" anchor="RFC0847">
<front>
<title>Summary of Smallberg surveys</title>
<author fullname="A. Westine" initials="A." surname="Westine">
<organization />
</author>

<author fullname="D. Smallberg" initials="D." surname="Smallberg">
<organization />
</author>

<author fullname="J. Postel" initials="J." surname="Postel">
<organization>University of Southern California (USC)/Information Sciences Institute</organization>

<address>
<postal>
<street>4676 Admiralty Way</street>
<city>Marina del Rey</city>
<region>CA</region>
<code>90291</code>
<country>US</country>
</postal>

<phone>+1 213 822 1511</phone>
</address>
</author>

<date year="1983" day="1" month="February" />

<abstract>
<t>This is a summary of the surveys of Telnet, FTP and Mail (SMTP) servers conducted by David Smallberg in December 1982 and January and February 1983 as reported in RFC 832-843, 845-846.  This memo extracts the number of hosts that accepted the connection to their server for each of Telnet, FTP, and SMTP, and compares it to the total host in the Internet (not counting TACs or ECHOS).</t>
</abstract>
</front>

<seriesInfo value="847" name="RFC" />
</reference>


<reference target2="reference.RFC.0848.xml" anchor="RFC0848">
<front>
<title>Who provides the "little" TCP services?</title>
<author fullname="Dave Smallberg" initials="D." surname="Smallberg">
<organization />
</author>

<date year="1983" day="14" month="March" />

<abstract>
<t>This report lists those hosts which provide any of these "little" TCP
services:

Port (in decimal)   Service
        -----------------   -------
                7           Echo
                9           Discard
               11           Active Users (systat)
               13           Date and Time in printable form
               15           Netstat
               17           Quote of the Day
               19           Character Generator (ttytst)
               37           Time (32 bits)
               79           Finger</t>
</abstract>
</front>

<seriesInfo value="848" name="RFC" />
</reference>


<reference target2="reference.RFC.0849.xml" anchor="RFC0849">
<front>
<title>Suggestions for improved host table distribution</title>
<author fullname="Mark Crispin" initials="M." surname="Crispin">
<organization>Stanford University</organization>
</author>

<date year="1983" day="1" month="May" />

<abstract>
<t>This RFC may be something unique among modern-day RFC's, an RFC that actually is a request for comments.  The issue dealt with is that of a naming registry update procedure, both as exists currently and what could exist in the future.  None of the proposed solutions are intended as standards at this time; rather it is hoped that a general consensus will emerge as the appropriate solution, leaving eventually to the
adoption of standards.</t>
</abstract>
</front>

<seriesInfo value="849" name="RFC" />
</reference>


<reference target2="reference.RFC.0850.xml" anchor="RFC0850">
<front>
<title>Standard for interchange of USENET messages</title>
<author fullname="Mark R. Horton" initials="M." surname="Horton">
<organization />
</author>

<date year="1983" day="1" month="June" />

<abstract>
<t>This memo is distributed as an RFC  only  to  make  this information  easily  accessible to researchers in the ARPA community.  It does not specify  an  Internet  standard.</t>
</abstract>
</front>

<seriesInfo value="850" name="RFC" />
</reference>


<reference target2="reference.RFC.0851.xml" anchor="RFC0851">
<front>
<title abbrev="1822L Host Access Protocol">ARPANET 1822L Host Access Protocol</title>
<author fullname="Andrew G. Malis" initials="A." surname="Malis">
<organization>Bolt Beranek and Newman Inc. (BBN)</organization>

<address>
<postal>
<street>50 Moulton St.</street>
<city>Cambridge</city>
<region>MA</region>
<code>02238</code>
<country>US</country>
</postal>

<email>malis@bbn-unix</email>
</address>
</author>

<date year="1983" day="18" month="April" />

<abstract>
<t>This RFC specifies the ARPANET 1822L Host Access Protocol,  which is  a successor to the existing 1822 Host Access Protocol.  1822L allows ARPANET hosts to use  logical  names  as  well  as  1822's physical  port  locations to address each other.  The RFC is also being  presented  as  a  solicitation  of  comments   on   1822L, especially   from   host   network   software   implementers  and maintainers.</t>
</abstract>
</front>

<seriesInfo value="851" name="RFC" />
</reference>


<reference target2="reference.RFC.0852.xml" anchor="RFC0852">
<front>
<title abbrev="ARPANET Short Blocking Feature">ARPANET short blocking feature</title>
<author fullname="Andrew G. Malis" initials="A." surname="Malis">
<organization>Bolt Beranek and Newman Inc. (BBN)</organization>

<address>
<postal>
<street>50 Moulton St.</street>
<city>Cambridge</city>
<region>MA</region>
<code>02238</code>
<country>US</country>
</postal>

<email>malis@bbn-unix</email>
</address>
</author>

<date year="1983" day="1" month="April" />

<abstract>
<t>This RFC specifies the ARPANET Short Blocking Feature, which will allow ARPANET hosts to optionally shorten the IMP's host blocking timer.  This Feature is a replacement of the ARPANET non-blocking host   interface,  which  was  never  implemented,  and  will  be available to hosts using either the 1822  or  1822L  Host  Access Protocol.   The  RFC is also being presented as a solicitation of comments on the Short  Blocking  Feature,  especially  from  host network software implementers and maintainers.</t>
</abstract>
</front>

<seriesInfo value="852" name="RFC" />
</reference>


<reference target2="reference.RFC.0854.xml" anchor="RFC0854">
<front>
<title>Telnet Protocol Specification</title>
<author fullname="J. Postel" initials="J." surname="Postel">
<organization>University of Southern California (USC)/Information Sciences Institute</organization>

<address>
<postal>
<street>4676 Admiralty Way</street>
<city>Marina del Rey</city>
<region>CA</region>
<code>90291</code>
<country>US</country>
</postal>

<phone>+1 213 822 1511</phone>
</address>
</author>

<author fullname="J. Reynolds" initials="J." surname="Reynolds">
<organization>University of Southern California (USC)/Information Sciences Institute</organization>

<address>
<postal>
<street>4676 Admiralty Way</street>
<city>Marina del Rey</city>
<region>CA</region>
<code>90291</code>
<country>US</country>
</postal>

<phone>+1 213 822 1511</phone>
</address>
</author>

<date year="1983" day="1" month="May" />

<abstract>
<t>This RFC specifies a standard for the ARPA Internet community.  Hosts on the ARPA Internet are expected to adopt and implement this standard.</t>
</abstract>
</front>

<seriesInfo value="8" name="STD" />
<seriesInfo value="854" name="RFC" />
</reference>


<reference target2="reference.RFC.0855.xml" anchor="RFC0855">
<front>
<title>Telnet Option Specifications</title>
<author fullname="Jonathan B. Postel" initials="J." surname="Postel">
<organization>University of Southern California (USC)/Information Sciences Institute</organization>

<address>
<postal>
<street>4676 Admiralty Way</street>
<city>Marina del Rey</city>
<region>CA</region>
<code>90291</code>
<country>US</country>
</postal>

<phone>+1 213 822 1511</phone>
<email>POSTEL@USC-ISIF</email>
</address>
</author>

<author fullname="J. Reynolds" initials="J." surname="Reynolds">
<organization>University of Southern California (USC)/Information Sciences Institute</organization>

<address>
<postal>
<street>4676 Admiralty Way</street>
<city>Marina del Rey</city>
<region>CA</region>
<code>90291</code>
<country>US</country>
</postal>

<phone>+1 213 822 1511</phone>
</address>
</author>

<date year="1983" day="1" month="May" />

<abstract>
<t>This RFC specifies a standard for the ARPA Internet community.  Hosts on the ARPA Internet are expected to adopt and implement this standard.</t>

<t>The intent of providing for options in the TELNET Protocol is to permit hosts to obtain more elegant solutions to the problems of communication between dissimilar devices than is possible within the framework provided by the Network Virtual Terminal (NVT).  It should be possible for hosts to invent, test, or discard options at will.  Nevertheless, it is envisioned that options which prove to be generally useful will eventually be supported by many hosts; therefore it is desirable that options should be carefully documented and well publicized.  In addition, it is necessary to insure that a single option code is not used for several different options.</t>

<t>This document specifies a method of option code assignment and standards for documentation of options.  The individual responsible for assignment of option codes may waive the requirement for complete documentation for some cases of experimentation, but in general documentation will be required prior to code assignment.  Options will be publicized by publishing their documentation as RFCs; inventors of options may, of course, publicize them in other ways as well.</t>
</abstract>
</front>

<seriesInfo value="8" name="STD" />
<seriesInfo value="855" name="RFC" />
</reference>


<reference target2="reference.RFC.0856.xml" anchor="RFC0856">
<front>
<title>Telnet Binary Transmission</title>
<author fullname="J. Postel" initials="J." surname="Postel">
<organization>University of Southern California (USC)/Information Sciences Institute</organization>

<address>
<postal>
<street>4676 Admiralty Way</street>
<city>Marina del Rey</city>
<region>CA</region>
<code>90291</code>
<country>US</country>
</postal>

<phone>+1 213 822 1511</phone>
</address>
</author>

<author fullname="J. Reynolds" initials="J." surname="Reynolds">
<organization>University of Southern California (USC)/Information Sciences Institute</organization>

<address>
<postal>
<street>4676 Admiralty Way</street>
<city>Marina del Rey</city>
<region>CA</region>
<code>90291</code>
<country>US</country>
</postal>

<phone>+1 213 822 1511</phone>
</address>
</author>

<date year="1983" day="1" month="May" />

<abstract>
<t>This RFC specifies a standard for the ARPA Internet community.  Hosts on the ARPA Internet are expected to adopt and implement this standard.</t>
</abstract>
</front>

<seriesInfo value="27" name="STD" />
<seriesInfo value="856" name="RFC" />
</reference>


<reference target2="reference.RFC.0857.xml" anchor="RFC0857">
<front>
<title>Telnet Echo Option</title>
<author fullname="J. Postel" initials="J." surname="Postel">
<organization>University of Southern California (USC)/Information Sciences Institute</organization>

<address>
<postal>
<street>4676 Admiralty Way</street>
<city>Marina del Rey</city>
<region>CA</region>
<code>90291</code>
<country>US</country>
</postal>

<phone>+1 213 822 1511</phone>
</address>
</author>

<author fullname="J. Reynolds" initials="J." surname="Reynolds">
<organization>University of Southern California (USC)/Information Sciences Institute</organization>

<address>
<postal>
<street>4676 Admiralty Way</street>
<city>Marina del Rey</city>
<region>CA</region>
<code>90291</code>
<country>US</country>
</postal>

<phone>+1 213 822 1511</phone>
</address>
</author>

<date year="1983" day="1" month="May" />

<abstract>
<t>This RFC specifies a standard for the ARPA Internet community.  Hosts on the ARPA Internet are expected to adopt and implement this standard.</t>
</abstract>
</front>

<seriesInfo value="28" name="STD" />
<seriesInfo value="857" name="RFC" />
</reference>


<reference target2="reference.RFC.0858.xml" anchor="RFC0858">
<front>
<title>Telnet Suppress Go Ahead Option</title>
<author fullname="J. Postel" initials="J." surname="Postel">
<organization>University of Southern California (USC)/Information Sciences Institute</organization>

<address>
<postal>
<street>4676 Admiralty Way</street>
<city>Marina del Rey</city>
<region>CA</region>
<code>90291</code>
<country>US</country>
</postal>

<phone>+1 213 822 1511</phone>
</address>
</author>

<author fullname="J. Reynolds" initials="J." surname="Reynolds">
<organization>University of Southern California (USC)/Information Sciences Institute</organization>

<address>
<postal>
<street>4676 Admiralty Way</street>
<city>Marina del Rey</city>
<region>CA</region>
<code>90291</code>
<country>US</country>
</postal>

<phone>+1 213 822 1511</phone>
</address>
</author>

<date year="1983" day="1" month="May" />

<abstract>
<t>This RFC specifies a standard for the ARPA Internet community.  Hosts on the ARPA Internet are expected to adopt and implement this standard.</t>
</abstract>
</front>

<seriesInfo value="29" name="STD" />
<seriesInfo value="858" name="RFC" />
</reference>


<reference target2="reference.RFC.0859.xml" anchor="RFC0859">
<front>
<title>Telnet Status Option</title>
<author fullname="J. Postel" initials="J." surname="Postel">
<organization>University of Southern California (USC)/Information Sciences Institute</organization>

<address>
<postal>
<street>4676 Admiralty Way</street>
<city>Marina del Rey</city>
<region>CA</region>
<code>90291</code>
<country>US</country>
</postal>

<phone>+1 213 822 1511</phone>
</address>
</author>

<author fullname="J. Reynolds" initials="J." surname="Reynolds">
<organization>University of Southern California (USC)/Information Sciences Institute</organization>

<address>
<postal>
<street>4676 Admiralty Way</street>
<city>Marina del Rey</city>
<region>CA</region>
<code>90291</code>
<country>US</country>
</postal>

<phone>+1 213 822 1511</phone>
</address>
</author>

<date year="1983" day="1" month="May" />

<abstract>
<t>This RFC specifies a standard for the ARPA Internet community.  Hosts on the ARPA Internet are expected to adopt and implement this standard.</t>
</abstract>
</front>

<seriesInfo value="30" name="STD" />
<seriesInfo value="859" name="RFC" />
</reference>


<reference target2="reference.RFC.0860.xml" anchor="RFC0860">
<front>
<title>Telnet Timing Mark Option</title>
<author fullname="J. Postel" initials="J." surname="Postel">
<organization>University of Southern California (USC)/Information Sciences Institute</organization>

<address>
<postal>
<street>4676 Admiralty Way</street>
<city>Marina del Rey</city>
<region>CA</region>
<code>90291</code>
<country>US</country>
</postal>

<phone>+1 213 822 1511</phone>
</address>
</author>

<author fullname="J. Reynolds" initials="J." surname="Reynolds">
<organization>University of Southern California (USC)/Information Sciences Institute</organization>

<address>
<postal>
<street>4676 Admiralty Way</street>
<city>Marina del Rey</city>
<region>CA</region>
<code>90291</code>
<country>US</country>
</postal>

<phone>+1 213 822 1511</phone>
</address>
</author>

<date year="1983" day="1" month="May" />

<abstract>
<t>This RFC specifies a standard for the ARPA community.  Hosts on the ARPA Internet are expected to adopt and implement this standard.</t>
</abstract>
</front>

<seriesInfo value="31" name="STD" />
<seriesInfo value="860" name="RFC" />
</reference>


<reference target2="reference.RFC.0861.xml" anchor="RFC0861">
<front>
<title>Telnet Extended Options: List Option</title>
<author fullname="J. Postel" initials="J." surname="Postel">
<organization>University of Southern California (USC)/Information Sciences Institute</organization>

<address>
<postal>
<street>4676 Admiralty Way</street>
<city>Marina del Rey</city>
<region>CA</region>
<code>90291</code>
<country>US</country>
</postal>

<phone>+1 213 822 1511</phone>
</address>
</author>

<author fullname="J. Reynolds" initials="J." surname="Reynolds">
<organization>University of Southern California (USC)/Information Sciences Institute</organization>

<address>
<postal>
<street>4676 Admiralty Way</street>
<city>Marina del Rey</city>
<region>CA</region>
<code>90291</code>
<country>US</country>
</postal>

<phone>+1 213 822 1511</phone>
</address>
</author>

<date year="1983" day="1" month="May" />

<abstract>
<t>This RFC specifies a standard for the ARPA Internet community.  Hosts on the ARPA Internet are expected to adopt and implement this standard.</t>
</abstract>
</front>

<seriesInfo value="32" name="STD" />
<seriesInfo value="861" name="RFC" />
</reference>


<reference target2="reference.RFC.0862.xml" anchor="RFC0862">
<front>
<title>Echo Protocol</title>
<author fullname="J. Postel" initials="J." surname="Postel">
<organization>University of Southern California (USC)/Information Sciences Institute</organization>

<address>
<postal>
<street>4676 Admiralty Way</street>
<city>Marina del Rey</city>
<region>CA</region>
<code>90291</code>
<country>US</country>
</postal>

<phone>+1 213 822 1511</phone>
</address>
</author>

<date year="1983" day="1" month="May" />

<abstract>
<t>This RFC specifies a standard for the ARPA Internet community.  Hosts on the ARPA Internet that choose to implement an Echo Protocol are expected to adopt and implement this standard.</t>

<t>A very useful debugging and measurement tool is an echo service.  An echo service simply sends back to the originating source any data it receives.</t>
</abstract>
</front>

<seriesInfo value="20" name="STD" />
<seriesInfo value="862" name="RFC" />
</reference>


<reference target2="reference.RFC.0863.xml" anchor="RFC0863">
<front>
<title>Discard Protocol</title>
<author fullname="J. Postel" initials="J." surname="Postel">
<organization>University of Southern California (USC)/Information Sciences Institute</organization>

<address>
<postal>
<street>4676 Admiralty Way</street>
<city>Marina del Rey</city>
<region>CA</region>
<code>90291</code>
<country>US</country>
</postal>

<phone>+1 213 822 1511</phone>
</address>
</author>

<date year="1983" day="1" month="May" />

<abstract>
<t>This RFC specifies a standard for the ARPA Internet community.  Hosts on the ARPA Internet that choose to implement a Discard Protocol are expected to adopt and implement this standard.</t>

<t>A useful debugging and measurement tool is a discard service.  A discard service simply throws away any data it receives.</t>
</abstract>
</front>

<seriesInfo value="21" name="STD" />
<seriesInfo value="863" name="RFC" />
</reference>


<reference target2="reference.RFC.0864.xml" anchor="RFC0864">
<front>
<title>Character Generator Protocol</title>
<author fullname="J. Postel" initials="J." surname="Postel">
<organization>University of Southern California (USC)/Information Sciences Institute</organization>

<address>
<postal>
<street>4676 Admiralty Way</street>
<city>Marina del Rey</city>
<region>CA</region>
<code>90291</code>
<country>US</country>
</postal>

<phone>+1 213 822 1511</phone>
</address>
</author>

<date year="1983" day="1" month="May" />

<abstract>
<t>This RFC specifies a standard for the ARPA Internet community.  Hosts on the ARPA Internet that choose to implement a Character Generator Protocol are expected to adopt and implement this standard.</t>

<t>A useful debugging and measurement tool is a character generator service.  A character generator service simply sends data without regard to the input.</t>
</abstract>
</front>

<seriesInfo value="22" name="STD" />
<seriesInfo value="864" name="RFC" />
</reference>


<reference target2="reference.RFC.0865.xml" anchor="RFC0865">
<front>
<title>Quote of the Day Protocol</title>
<author fullname="J. Postel" initials="J." surname="Postel">
<organization>University of Southern California (USC)/Information Sciences Institute</organization>

<address>
<postal>
<street>4676 Admiralty Way</street>
<city>Marina del Rey</city>
<region>CA</region>
<code>90291</code>
<country>US</country>
</postal>

<phone>+1 213 822 1511</phone>
</address>
</author>

<date year="1983" day="1" month="May" />

<abstract>
<t>This RFC specifies a standard for the ARPA Internet community.  Hosts on the ARPA Internet that choose to implement a Quote of the Day Protocol are expected to adopt and implement this standard.</t>

<t>A useful debugging and measurement tool is a quote of the day service. A quote of the day service simply sends a short message without regard to the input.</t>
</abstract>
</front>

<seriesInfo value="23" name="STD" />
<seriesInfo value="865" name="RFC" />
</reference>


<reference target2="reference.RFC.0866.xml" anchor="RFC0866">
<front>
<title>Active users</title>
<author fullname="J. Postel" initials="J." surname="Postel">
<organization>Information Sciences Institute (ISI)</organization>
</author>

<date year="1983" day="1" month="May" />

<abstract>
<t>This RFC specifies a standard for the ARPA Internet community.  Hosts on the ARPA Internet that choose to implement an Active Users Protocol are expected to adopt and implement this standard.</t>

<t>A useful debugging and measurement tool is an active users service.  An active users service simply sends a list of the currently active users on the host without regard to the input.</t>

<t>An active user is one logged in, such as listed in SYSTAT or WHO.</t>
</abstract>
</front>

<seriesInfo value="24" name="STD" />
<seriesInfo value="866" name="RFC" />
</reference>


<reference target2="reference.RFC.0867.xml" anchor="RFC0867">
<front>
<title>Daytime Protocol</title>
<author fullname="J. Postel" initials="J." surname="Postel">
<organization>University of Southern California (USC)/Information Sciences Institute</organization>

<address>
<postal>
<street>4676 Admiralty Way</street>
<city>Marina del Rey</city>
<region>CA</region>
<code>90291</code>
<country>US</country>
</postal>

<phone>+1 213 822 1511</phone>
</address>
</author>

<date year="1983" day="1" month="May" />

<abstract>
<t>This RFC specifies a standard for the ARPA Internet community.  Hosts on the ARPA Internet that choose to implement a Daytime Protocol are expected to adopt and implement this standard.</t>

<t>A useful debugging and measurement tool is a daytime service.  A daytime service simply sends a the current date and time as a character string without regard to the input.</t>
</abstract>
</front>

<seriesInfo value="25" name="STD" />
<seriesInfo value="867" name="RFC" />
</reference>


<reference target2="reference.RFC.0868.xml" anchor="RFC0868">
<front>
<title>Time Protocol</title>
<author fullname="J. Postel" initials="J." surname="Postel">
<organization>University of Southern California (USC)/Information Sciences Institute</organization>

<address>
<postal>
<street>4676 Admiralty Way</street>
<city>Marina del Rey</city>
<region>CA</region>
<code>90291</code>
<country>US</country>
</postal>

<phone>+1 213 822 1511</phone>
</address>
</author>

<author fullname="K. Harrenstien" initials="K." surname="Harrenstien">
<organization>SRI International</organization>
</author>

<date year="1983" day="1" month="May" />

<abstract>
<t>This RFC specifies a standard for the ARPA Internet community.  Hosts on the ARPA Internet that choose to implement a Time Protocol are expected to adopt and implement this standard.</t>

<t>This protocol provides a site-independent, machine readable date and time.  The Time service sends back to the originating source the time in seconds since midnight on January first 1900.</t>

<t>One motivation arises from the fact that not all systems have a date/time clock, and all are subject to occasional human or machine error.  The use of time-servers makes it possible to quickly confirm or 
correct a system's idea of the time, by making a brief poll of several independent sites on the network.</t>

<t>This protocol may be used either above the Transmission Control Protocol (TCP) or above the User Datagram Protocol (UDP).</t>
</abstract>
</front>

<seriesInfo value="26" name="STD" />
<seriesInfo value="868" name="RFC" />
</reference>


<reference target2="reference.RFC.0869.xml" anchor="RFC0869">
<front>
<title>Host Monitoring Protocol</title>
<author fullname="Robert M. Hinden" initials="R." surname="Hinden">
<organization>Bolt Baranek and Newman Communications Corporation (BBNCC)</organization>
</author>

<date year="1983" day="1" month="December" />
</front>

<seriesInfo value="869" name="RFC" />
</reference>


<reference target2="reference.RFC.0870.xml" anchor="RFC0870">
<front>
<title abbrev="Assigned Numbers Network Numbers">Assigned numbers</title>
<author fullname="Joyce Reynolds" initials="J." surname="Reynolds">
<organization>University of Southern California (USC)/Information Sciences Institute</organization>

<address>
<postal>
<street>4676 Admiralty Way</street>
<city>Marina del Rey</city>
<region>CA</region>
<code>90292</code>
<country>US</country>
</postal>

<phone>+1 213 822 1511</phone>
<email>JKREYNOLDS@USC-ISIF</email>
</address>
</author>

<author fullname="J. Postel" initials="J." surname="Postel">
<organization>University of Southern California (USC)/Information Sciences Institute</organization>

<address>
<postal>
<street>4676 Admiralty Way</street>
<city>Marina del Rey</city>
<region>CA</region>
<code>90291</code>
<country>US</country>
</postal>

<phone>+1 213 822 1511</phone>
</address>
</author>

<date year="1983" day="1" month="October" />
</front>

<seriesInfo value="870" name="RFC" />
</reference>


<reference target2="reference.RFC.0871.xml" anchor="RFC0871">
<front>
<title>Perspective on the ARPANET reference model</title>
<author fullname="Mike A. Padlipsky" initials="M." surname="Padlipsky">
<organization>The Mitre Corporation</organization>

<address>
<postal>
<street>P.O. Box 208</street>
<city>Bedford</city>
<region>MA</region>
<code>01730</code>
<country>US</country>
</postal>

<email>Padlipsky@USC-ISIA</email>
</address>
</author>

<date year="1982" day="1" month="September" />

<abstract>
<t>The paper, by one of its developers, describes the conceptual framework in which the ARPANET intercomputer networking protocol suite, including the DoD standard Transmission Control Protocol (TCP) and Internet Protocol (IP), were designed.  It also compares and contrasts several aspects of the ARPANET Reference Model (ARM) with the more widely publicized International Standards Organization's Reference Model for Open System Interconnection (ISORM).</t>
</abstract>
</front>

<seriesInfo value="871" name="RFC" />
</reference>


<reference target2="reference.RFC.0872.xml" anchor="RFC0872">
<front>
<title>TCP-on-a-LAN</title>
<author fullname="Mike A. Padlipsky" initials="M." surname="Padlipsky">
<organization>The Mitre Corporation</organization>

<address>
<postal>
<street>P.O. Box 208</street>
<city>Bedford</city>
<region>MA</region>
<code>01730</code>
<country>US</country>
</postal>

<email>Padlipsky@USC-ISIA</email>
</address>
</author>

<date year="1982" day="1" month="September" />

<abstract>
<t>The sometimes-held position that the DoD Standard Transmission Control Protocol (TCP) and Internet Protocol (IP) are inappropriate for use "on" a Local Area Network (LAN) is shown to be fallacious.  The paper is a companion piece to M82-47, M82-49, M82-50, and M82-51.</t>
</abstract>
</front>

<seriesInfo value="872" name="RFC" />
</reference>


<reference target2="reference.RFC.0873.xml" anchor="RFC0873">
<front>
<title>Illusion of vendor support</title>
<author fullname="M. A. Padlipsky" initials="M." surname="Padlipsky">
<organization>The Mitre Corporation</organization>

<address>
<postal>
<street>P.O. Box 208</street>
<city>Bedford</city>
<region>MA</region>
<code>01730</code>
<country>US</country>
</postal>

<email>Padlipsky@ISIA</email>
</address>
</author>

<date year="1982" day="1" month="September" />

<abstract>
<t>The sometimes-held position that "vendor supplied" intercomputer networking protocols based upon the International Standards Organization's Reference Model for Open System Interconnection are worth waiting for, in particular in preference to protocols based upon the ARPANET Reference Model  (ARM), is shown to be fallacious</t>

<t>This paper is a companion piece to M82-47, M82-48, M82-50, and M82-51</t>
</abstract>
</front>

<seriesInfo value="873" name="RFC" />
</reference>


<reference target2="reference.RFC.0874.xml" anchor="RFC0874">
<front>
<title>Critique of X.25</title>
<author fullname="M. A. Padlipsky" initials="M." surname="Padlipsky">
<organization>The Mitre Corporation</organization>

<address>
<postal>
<street>P.O. Box 208</street>
<city>Bedford</city>
<region>MA</region>
<code>01730</code>
<country>US</country>
</postal>

<email>Padlipsky@ISIA</email>
</address>
</author>

<date year="1982" day="1" month="September" />

<abstract>
<t>The widely touted network interface protocol, "X.25", and its attendant conceptual framework, the International Standards Organization's Reference Model for Open System Interconnection ISORM), are analyzed and found wanting.  The paper is a companion piece to M82-48, and M82-51</t>
</abstract>
</front>

<seriesInfo value="874" name="RFC" />
</reference>


<reference target2="reference.RFC.0875.xml" anchor="RFC0875">
<front>
<title>Gateways, architectures, and heffalumps</title>
<author fullname="Mike A. Padlipsky" initials="M." surname="Padlipsky">
<organization>The Mitre Corporation</organization>

<address>
<postal>
<street>P.O. Box 208</street>
<city>Bedford</city>
<region>MA</region>
<code>01730</code>
<country>US</country>
</postal>

<email>Padlipsky@ISIA</email>
</address>
</author>

<date year="1982" day="1" month="September" />

<abstract>
<t>The growth of autonomous intercomputer networks has led to a desire on the part of their respective proprietors to "gateway" from one to the other.  Unfortunately, however, the implications and shortcomings of gateways which must translate or map between differing protocol suites are not widely understood.  Some protocol sets have such severe functionality mismatches that proper T/MG's cannot be generated for them; all attempts to mesh heterogeneous suites are subject to numerous problems, including the introduction of "singularity points" on logical connections which would otherwise be able to enjoy the advantages of communications subnetwork alternate routing, loss of functionality, difficulty of Flow Control resolution, higher cost than non-translating/mapping Gateways, and the necessity of re-creating T/MG's when a given suite changes.  The preferability of a protocol-compatible internet is also touched upon, as is the psychology of those soi-disant architects who posit T/MG's.</t>
</abstract>
</front>

<seriesInfo value="875" name="RFC" />
</reference>


<reference target2="reference.RFC.0876.xml" anchor="RFC0876">
<front>
<title>Survey of SMTP implementations</title>
<author fullname="D. Smallberg" initials="D." surname="Smallberg">
<organization>University of Southern California (USC)/Information Sciences Institute</organization>

<address>
<postal>
<street>4676 Admiralty Way</street>
<city>Marina del Rey</city>
<region>CA</region>
<code>90291</code>
<country>US</country>
</postal>

<phone>+1 213 822 1511</phone>
</address>
</author>

<date year="1983" day="1" month="September" />

<abstract>
<t>This memo is a survey of implementation status.  It does not specify an official protocol, but rather notes the status of impementation of aspects of a protocol.  It is expected that the status of the hosts reported on will change.  This information must be treated as a snapshot of the state of these implementations.</t>
</abstract>
</front>

<seriesInfo value="876" name="RFC" />
</reference>


<reference target2="reference.RFC.0877.xml" anchor="RFC0877">
<front>
<title abbrev="Transmission of IP Datagrams Over Public Data Networks">Standard for the transmission of IP datagrams over public data networks</title>
<author fullname="J. T. Korb" initials="J." surname="Korb">
<organization>Purdue University</organization>
</author>

<date year="1983" day="1" month="September" />

<abstract>
<t>This RFC specifies a standard adopted by CSNET, the VAN gateway, and other organizations for the transmission of IP datagrams over the X.25-based public data networks.</t>

<t>An X.25 virtual circuit is opened on demand when a datagram arrives at the network interface for transmission. A virtual circuit is closed after some period of inactivity (the length of the period depends on
the cost associated with an open virtual circuit). A virtual circuit may also be closed if the interface runs out of virtual circuits. An algorithm for managing virtual circuits during peak demand is given in.</t>
</abstract>
</front>

<seriesInfo value="877" name="RFC" />
</reference>


<reference target2="reference.RFC.0878.xml" anchor="RFC0878">
<front>
<title abbrev="1822L Host Access Protocol">ARPANET 1822L Host Access Protocol</title>
<author fullname="Andrew G. Malis" initials="A." surname="Malis">
<organization>Bolt Baranek and Newman Communications Corporation (BBNCC)</organization>

<address>
<postal>
<street>50 Moulton St.</street>
<city>Cambridge</city>
<region>MA</region>
<code>02238</code>
<country>US</country>
</postal>

<email>malis@bbn-unix</email>
</address>
</author>

<date year="1983" day="1" month="December" />

<abstract>
<t>This RFC specifies the ARPANET 1822L Host Access Protocol,  which is  a successor to the existing 1822 Host Access Protocol.  1822L allows ARPANET hosts to use  logical  names as well as  1822's physical port locations to address each other</t>
</abstract>
</front>

<seriesInfo value="878" name="RFC" />
</reference>


<reference target2="reference.RFC.0879.xml" anchor="RFC0879">
<front>
<title abbrev="TCP Maximum Segment Size">TCP maximum segment size and related topics</title>
<author fullname="J. Postel" initials="J." surname="Postel">
<organization>University of Southern California (USC)/Information Sciences Institute</organization>

<address>
<postal>
<street>4676 Admiralty Way</street>
<city>Marina del Rey</city>
<region>CA</region>
<code>90291</code>
<country>US</country>
</postal>

<phone>+1 213 822 1511</phone>
</address>
</author>

<date year="1983" day="1" month="November" />

<abstract>
<t>This memo discusses the TCP Maximum Segment Size Option and related topics.  The purposes is to clarify some aspects of TCP and its interaction with IP.  This memo is a clarification to the TCP specification, and contains information that may be considered as "advice to implementers".</t>
</abstract>
</front>

<seriesInfo value="879" name="RFC" />
</reference>


<reference target2="reference.RFC.0880.xml" anchor="RFC0880">
<front>
<title>Official protocols</title>
<author fullname="J. Reynolds" initials="J." surname="Reynolds">
<organization>University of Southern California (USC)/Information Sciences Institute</organization>

<address>
<postal>
<street>4676 Admiralty Way</street>
<city>Marina del Rey</city>
<region>CA</region>
<code>90291</code>
<country>US</country>
</postal>

<phone>+1 213 822 1511</phone>
</address>
</author>

<author fullname="J. Postel" initials="J." surname="Postel">
<organization>University of Southern California (USC)/Information Sciences Institute</organization>

<address>
<postal>
<street>4676 Admiralty Way</street>
<city>Marina del Rey</city>
<region>CA</region>
<code>90291</code>
<country>US</country>
</postal>

<phone>+1 213 822 1511</phone>
</address>
</author>

<date year="1983" day="1" month="October" />

<abstract>
<t>This RFC identifies the documents specifying the official protocols used in the Internet.  Annotations identify any revisions or changes planned.</t>
</abstract>
</front>

<seriesInfo value="880" name="RFC" />
</reference>


<reference target2="reference.RFC.0881.xml" anchor="RFC0881">
<front>
<title>Domain names plan and schedule</title>
<author fullname="J. Postel" initials="J." surname="Postel">
<organization>University of Southern California (USC)/Information Sciences Institute</organization>

<address>
<postal>
<street>4676 Admiralty Way</street>
<city>Marina del Rey</city>
<region>CA</region>
<code>90291</code>
<country>US</country>
</postal>

<phone>+1 213 822 1511</phone>
</address>
</author>

<date year="1983" day="1" month="November" />

<abstract>
<t>This RFC outlines a plan and schedule for the implementation of domain style names throughout the DDN/ARPA Internet community.  The introduction of domain style names will impact all hosts on the DDN/ARPA Internet.</t>
</abstract>
</front>

<seriesInfo value="881" name="RFC" />
</reference>


<reference target2="reference.RFC.0882.xml" anchor="RFC0882">
<front>
<title>Domain names: Concepts and facilities</title>
<author fullname="P. Mockapetris" initials="P." surname="Mockapetris">
<organization>University of Southern California (USC)/Information Sciences Institute</organization>

<address>
<postal>
<street>4676 Admiralty Way</street>
<city>Marina del Rey</city>
<region>CA</region>
<code>90291</code>
<country>US</country>
</postal>

<phone>+1 213 822 1511</phone>
</address>
</author>

<date year="1983" day="1" month="November" />

<abstract>
<t>This RFC introduces domain style names, their use for ARPA Internet mail and host address support, and the protocols and servers used to implement domain name facilities</t>

<t>This memo describes the conceptual framework of the domain system and some uses, but it omits many uses, fields, and implementation details.  A complete specification of formats, timeouts, etc. is presented in RFC 883, "Domain Names - Implementation and Specification".  That RFC assumes that the reader is familiar with the concepts discussed in this memo</t>
</abstract>
</front>

<seriesInfo value="882" name="RFC" />
</reference>


<reference target2="reference.RFC.0883.xml" anchor="RFC0883">
<front>
<title>Domain names: Implementation specification</title>
<author fullname="Mockapetris" initials="P." surname="Mockapetris">
<organization>University of Southern California (USC)/Information Sciences Institute</organization>

<address>
<postal>
<street>4676 Admiralty Way</street>
<city>Marina del Rey</city>
<region>CA</region>
<code>90291</code>
<country>US</country>
</postal>

<phone>+1 213 822 1511</phone>
</address>
</author>

<date year="1983" day="1" month="November" />

<abstract>
<t>This memo discusses the implementation of domain name servers and resolvers, specifies the format of transactions, and discusses the use of domain names in the context of existing mail systems and other network software</t>

<t>This memo assumes that the reader is familiar with RFC 882, "Domain Names - Concepts and Facilities" which discusses the basic principles of domain names and their use</t>

<t>The algorithms and internal data structures used in this memo are offered as suggestions rather than requirements; implementers are free to design their own structures so long as the same external behavior is achieved</t>
</abstract>
</front>

<seriesInfo value="883" name="RFC" />
</reference>


<reference target2="reference.RFC.0884.xml" anchor="RFC0884">
<front>
<title>Telnet terminal type option</title>
<author fullname="Marvin Solomon" initials="M." surname="Solomon">
<organization>University of Wisconsin - Madison</organization>
</author>

<author fullname="Edward Wimmers" initials="E." surname="Wimmers">
<organization>University of Wisconsin - Madison</organization>
</author>

<date year="1983" day="1" month="December" />

<abstract>
<t>This RFC specifies a standard for the ARPA Internet community.  Hosts on the ARPA Internet that exchange terminal type information within the Telnet protocol are expected to adopt and implement this standard.</t>
</abstract>
</front>

<seriesInfo value="884" name="RFC" />
</reference>


<reference target2="reference.RFC.0885.xml" anchor="RFC0885">
<front>
<title>Telnet end of record option</title>
<author fullname="J. Postel" initials="J." surname="Postel">
<organization>University of Southern California (USC)/Information Sciences Institute</organization>

<address>
<postal>
<street>4676 Admiralty Way</street>
<city>Marina del Rey</city>
<region>CA</region>
<code>90291</code>
<country>US</country>
</postal>

<phone>+1 213 822 1511</phone>
</address>
</author>

<date year="1983" day="1" month="December" />

<abstract>
<t>This RFC specifies a standard for the ARPA Internet community.  Hosts on the ARPA Internet that need to mark record boundaries within Telnet protocol data are expected to adopt and implement this standard.</t>
</abstract>
</front>

<seriesInfo value="885" name="RFC" />
</reference>


<reference target2="reference.RFC.0886.xml" anchor="RFC0886">
<front>
<title>Proposed standard for message header munging</title>
<author fullname="Marshall T. Rose" initials="M." surname="Rose">
<organization>University of California, Irvine, Department of Information and Computer Science</organization>

<address>
<postal>
<street />
<city>Irvine</city>
<region>CA</region>
<code>92717</code>
<country>US</country>
</postal>

<email>MRose.UCI@Rand-Relay</email>
</address>
</author>

<date year="1983" day="15" month="December" />

<abstract>
<t>This memo proposes a standard for the ARPA Internet community. If this proposal is adopted, hosts on the ARPA Internet that do message translation would be expected to adopt and implement this standard.</t>
</abstract>
</front>

<seriesInfo value="886" name="RFC" />
</reference>


<reference target2="reference.RFC.0887.xml" anchor="RFC0887">
<front>
<title>Resource Location Protocol</title>
<author fullname="M. Accetta" initials="M." surname="Accetta">
<organization>Carnegie-Mellon University</organization>
</author>

<date year="1983" day="1" month="December" />

<abstract>
<t>This note describes a resource location protocol for use in the ARPA Internet.  It is most useful on networks employing technologies which support some method of broadcast addressing, however it may also be used on other types of networks.  For maximum benefit, all hosts which provide significant resources or services to other hosts on the Internet should implement this protocol.  Hosts failing to implement the Resource Location Protocol risk being ignored by other hosts which are attempting to locate resources on the Internet.  This RFC specifies a draft standard for the ARPA Internet community.</t>

<t>The Resource Location Protocol (RLP) utilizes the User Datagram Protocol (UDP)which in turn calls on the Internet Protocol (IP)to deliver its datagrams.  See Appendix A andfor the appropriate port and protocol number assignments.</t>

<t>Unless otherwise indicated, all numeric quantities in this document are decimal numbers.</t>
</abstract>
</front>

<seriesInfo value="887" name="RFC" />
</reference>


<reference target2="reference.RFC.0888.xml" anchor="RFC0888">
<front>
<title>"STUB" Exterior Gateway Protocol</title>
<author fullname="Linda J. Seamonson" initials="L." surname="Seamonson">
<organization>BBN Communications</organization>
</author>

<author fullname="Eric C. Rosen" initials="E." surname="Rosen">
<organization>BBN Communications</organization>
</author>

<date year="1984" day="1" month="January" />

<abstract>
<t>This note describes the Exterior Gateway Protocol used to connect Stub Gateways to an Autonomous System of core Gateways.  This document specifies the working protocol, and defines an ARPA official protocol.  All implementers of Gateways should carefully review this document.</t>
</abstract>
</front>

<seriesInfo value="888" name="RFC" />
</reference>


<reference target2="reference.RFC.0889.xml" anchor="RFC0889">
<front>
<title>Internet delay experiments</title>
<author fullname="D. L. Mills" initials="D." surname="Mills">
<organization />
</author>

<date year="1983" day="1" month="December" />

<abstract>
<t>This memo reports on some measurement experiments and suggests some possible improvements to the TCP retransmission timeout calculation.  This memo is both a status report on the measurements and advice to implementers of TCP.</t>
</abstract>
</front>

<seriesInfo value="889" name="RFC" />
</reference>


<reference target2="reference.RFC.0890.xml" anchor="RFC0890">
<front>
<title abbrev="EGP Implementation Schedule">Exterior Gateway Protocol implementation schedule</title>
<author fullname="J. Postel" initials="J." surname="Postel">
<organization>University of Southern California (USC)/Information Sciences Institute</organization>

<address>
<postal>
<street>4676 Admiralty Way</street>
<city>Marina del Rey</city>
<region>CA</region>
<code>90291</code>
<country>US</country>
</postal>

<phone>+1 213 822 1511</phone>
</address>
</author>

<date year="1984" day="1" month="February" />
</front>

<seriesInfo value="890" name="RFC" />
</reference>


<reference target2="reference.RFC.0891.xml" anchor="RFC0891">
<front>
<title>DCN local-network protocols</title>
<author fullname="D. L. Mills" initials="D." surname="Mills">
<organization />
</author>

<date year="1983" day="1" month="December" />

<abstract>
<t>This RFC is a description of the protocol used in the DCN local networks to maintain connectivity, routing, and timekeeping information.  These procedures may be of interest to designers and implementers of other networks.</t>
</abstract>
</front>

<seriesInfo value="44" name="STD" />
<seriesInfo value="891" name="RFC" />
</reference>


<reference target2="reference.RFC.0892.xml" anchor="RFC0892">
<front>
<title abbrev="ISO Transport Protocol Specification International Standards Organization">ISO Transport Protocol specification</title>
<author>
<organization>International Organization for Standardization (ISO)</organization>
</author>

<date year="1983" day="1" month="December" />

<abstract>
<t>This document is distributed as an RFC for information only. It does not specify a standard for the ARPA Internet. Note:  This document appeared in:</t>

<t>ISO/TC97/SC16/WG6.  Information Processing Systems - Open Systems Interconnection - Transport Protocol Specification.  Computer Communication Review 12, 3-4 (July/October 1982), pp.  24-67.</t>

<t>and differs from it only in format.</t>
</abstract>
</front>

<seriesInfo value="892" name="RFC" />
</reference>


<reference target2="reference.RFC.0893.xml" anchor="RFC0893">
<front>
<title>Trailer encapsulations</title>
<author fullname="Samuel J. Leffler" initials="S." surname="Leffler">
<organization>University of California at Berkeley</organization>
</author>

<author fullname="Michael J. Karels" initials="M." surname="Karels">
<organization>University of California at Berkeley</organization>
</author>

<date year="1984" day="1" month="April" />
</front>

<seriesInfo value="893" name="RFC" />
</reference>


<reference target2="reference.RFC.0894.xml" anchor="RFC0894">
<front>
<title>Standard for the transmission of IP datagrams over Ethernet networks</title>
<author fullname="Charles Hornig" initials="C." surname="Hornig">
<organization>Symbolics Cambridge Research Center</organization>
</author>

<date year="1984" day="1" month="April" />
</front>

<seriesInfo value="41" name="STD" />
<seriesInfo value="894" name="RFC" />
</reference>


<reference target2="reference.RFC.0895.xml" anchor="RFC0895">
<front>
<title>Standard for the transmission of IP datagrams over experimental Ethernet networks</title>
<author fullname="Jon Postel" initials="J." surname="Postel">
<organization>University of Southern California (USC)/Information Sciences Institute</organization>

<address>
<postal>
<street>4676 Admiralty Way</street>
<city>Marina del Rey</city>
<region>CA</region>
<code>90291</code>
<country>US</country>
</postal>

<phone>+1 213 822 1511</phone>
</address>
</author>

<date year="1984" day="1" month="April" />
</front>

<seriesInfo value="42" name="STD" />
<seriesInfo value="895" name="RFC" />
</reference>


<reference target2="reference.RFC.0896.xml" anchor="RFC0896">
<front>
<title>Congestion control in IP/TCP internetworks</title>
<author fullname="John Nagle" initials="J." surname="Nagle">
<organization>Ford Aerospace and Communications Corporation</organization>
</author>

<date year="1984" month="January" day="6" />

<abstract>
<t>This memo discusses some aspects of congestion control in  IP/TCP Internetworks. It  is intended to stimulate thought and further discussion of this topic. While some specific  suggestions  are
made for improved congestion  control  implementation, this memo does not specify any standards.</t>
</abstract>
</front>

<seriesInfo value="896" name="RFC" />
</reference>


<reference target2="reference.RFC.0897.xml" anchor="RFC0897">
<front>
<title abbrev="Domain Implementation Schedule">Domain name system implementation schedule</title>
<author fullname="J. Postel" initials="J." surname="Postel">
<organization>University of Southern California (USC)/Information Sciences Institute</organization>

<address>
<postal>
<street>4676 Admiralty Way</street>
<city>Marina del Rey</city>
<region>CA</region>
<code>90291</code>
<country>US</country>
</postal>

<phone>+1 213 822 1511</phone>
</address>
</author>

<date year="1984" day="1" month="February" />
</front>

<seriesInfo value="897" name="RFC" />
</reference>


<reference target2="reference.RFC.0898.xml" anchor="RFC0898">
<front>
<title abbrev="Gateway SIG Meeting Notes">Gateway special interest group meeting notes</title>
<author fullname="R. Hinden" initials="R." surname="Hinden">
<organization>Bolt Baranek and Newman (BBN)</organization>
</author>

<author fullname="J. Postel" initials="J." surname="Postel">
<organization>University of Southern California (USC)/Information Sciences Institute</organization>

<address>
<postal>
<street>4676 Admiralty Way</street>
<city>Marina del Rey</city>
<region>CA</region>
<code>90291</code>
<country>US</country>
</postal>

<phone>+1 213 822 1511</phone>
</address>
</author>

<author fullname="M. Muuss" initials="M." surname="Muuss">
<organization>BRL</organization>
</author>

<author fullname="J. Reynolds" initials="J." surname="Reynolds">
<organization>University of Southern California (USC)/Information Sciences Institute</organization>

<address>
<postal>
<street>4676 Admiralty Way</street>
<city>Marina del Rey</city>
<region>CA</region>
<code>90291</code>
<country>US</country>
</postal>

<phone>+1 213 822 1511</phone>
</address>
</author>

<date year="1984" day="1" month="April" />
</front>

<seriesInfo value="898" name="RFC" />
</reference>


<reference target2="reference.RFC.0899.xml" anchor="RFC0899">
<front>
<title>Request For Comments summary notes: 800-899</title>
<author fullname="J. Postel" initials="J." surname="Postel">
<organization>University of Southern California (USC)/Information Sciences Institute</organization>

<address>
<postal>
<street>4676 Admiralty Way</street>
<city>Marina del Rey</city>
<region>CA</region>
<code>90291</code>
<country>US</country>
</postal>

<phone>+1 213 822 1511</phone>
</address>
</author>

<author fullname="A. Westine" initials="A." surname="Westine">
<organization>University of Southern California (USC)/Information Sciences Institute</organization>

<address>
<postal>
<street>4676 Admiralty Way</street>
<city>Marina del Rey</city>
<region>CA</region>
<code>90291</code>
<country>US</country>
</postal>

<phone>+1 213 822 1511</phone>
</address>
</author>

<date year="1984" day="1" month="May" />
</front>

<seriesInfo value="899" name="RFC" />
</reference>


<reference target2="reference.RFC.0900.xml" anchor="RFC0900">
<front>
<title abbrev="Assigned Numbers Network Numbers">Assigned Numbers</title>
<author fullname="Joyce Reynolds" initials="J." surname="Reynolds">
<organization>University of Southern California (USC)/Information Sciences Institute</organization>

<address>
<postal>
<street>4676 Admiralty Way</street>
<city>Marina del Rey</city>
<region>CA</region>
<code>90292-6695</code>
<country>US</country>
</postal>

<phone>+1 213 822 1511</phone>
<email>JKREYNOLDS@USC-ISIF.ARPA</email>
</address>
</author>

<author fullname="J. Postel" initials="J." surname="Postel">
<organization>University of Southern California (USC)/Information Sciences Institute</organization>

<address>
<postal>
<street>4676 Admiralty Way</street>
<city>Marina del Rey</city>
<region>CA</region>
<code>90291</code>
<country>US</country>
</postal>

<phone>+1 213 822 1511</phone>
</address>
</author>

<date year="1984" day="1" month="June" />
</front>

<seriesInfo value="900" name="RFC" />
</reference>


<reference target2="reference.RFC.0901.xml" anchor="RFC0901">
<front>
<title>Official ARPA-Internet protocols</title>
<author fullname="Joyce Reynolds" initials="J." surname="Reynolds">
<organization>University of Southern California (USC)/Information Sciences Institute</organization>

<address>
<postal>
<street>4676 Admiralty Way</street>
<city>Marina del Rey</city>
<region>CA</region>
<code>90292-6695</code>
<country>US</country>
</postal>

<phone>+1 213 822 1511</phone>
<email>JKREYNOLDS@USC-ISIF.ARPA</email>
</address>
</author>

<author fullname="J. Postel" initials="J." surname="Postel">
<organization>University of Southern California (USC)/Information Sciences Institute</organization>

<address>
<postal>
<street>4676 Admiralty Way</street>
<city>Marina del Rey</city>
<region>CA</region>
<code>90291</code>
<country>US</country>
</postal>

<phone>+1 213 822 1511</phone>
</address>
</author>

<date year="1984" day="1" month="June" />
</front>

<seriesInfo value="901" name="RFC" />
</reference>


<reference target2="reference.RFC.0902.xml" anchor="RFC0902">
<front>
<title abbrev="DARPA Internet Protocol Policy">ARPA Internet Protocol policy</title>
<author fullname="J. Reynolds" initials="J." surname="Reynolds">
<organization>University of Southern California (USC)/Information Sciences Institute</organization>

<address>
<postal>
<street>4676 Admiralty Way</street>
<city>Marina del Rey</city>
<region>CA</region>
<code>90291</code>
<country>US</country>
</postal>

<phone>+1 213 822 1511</phone>
</address>
</author>

<author fullname="J. Postel" initials="J." surname="Postel">
<organization>University of Southern California (USC)/Information Sciences Institute</organization>

<address>
<postal>
<street>4676 Admiralty Way</street>
<city>Marina del Rey</city>
<region>CA</region>
<code>90291</code>
<country>US</country>
</postal>

<phone>+1 213 822 1511</phone>
</address>
</author>

<date year="1984" day="1" month="July" />
</front>

<seriesInfo value="902" name="RFC" />
</reference>


<reference target2="reference.RFC.0903.xml" anchor="RFC0903">
<front>
<title>Reverse Address Resolution Protocol</title>
<author fullname="Ross Finlayson" initials="R." surname="Finlayson">
<organization>Stanford University, Computer Science Department</organization>
</author>

<author fullname="Timothy Mann" initials="T." surname="Mann">
<organization>Stanford University, Computer Science Department</organization>
</author>

<author fullname="Jeffrey Mogul" initials="J." surname="Mogul">
<organization>Stanford University, Computer Science Department</organization>
</author>

<author fullname="Marvin Theimer" initials="M." surname="Theimer">
<organization>Stanford University, Computer Science Department</organization>
</author>

<date year="1984" day="1" month="June" />
</front>

<seriesInfo value="38" name="STD" />
<seriesInfo value="903" name="RFC" />
</reference>


<reference target2="reference.RFC.0904.xml" anchor="RFC0904">
<front>
<title>Exterior Gateway Protocol formal specification</title>
<author fullname="D. L. Mills" initials="D." surname="Mills">
<organization />
</author>

<date year="1984" day="1" month="April" />
</front>

<seriesInfo value="904" name="RFC" />
</reference>


<reference target2="reference.RFC.0905.xml" anchor="RFC0905">
<front>
<title>ISO Transport Protocol specification ISO DP 8073</title>
<author>
<organization>International Organization for Standardization (ISO)</organization>
</author>

<date year="1984" day="1" month="April" />
</front>

<seriesInfo value="905" name="RFC" />
</reference>


<reference target2="reference.RFC.0906.xml" anchor="RFC0906">
<front>
<title>Bootstrap loading using TFTP</title>
<author fullname="Ross Finlayson" initials="R." surname="Finlayson">
<organization>Stanford University</organization>
</author>

<date year="1984" day="1" month="June" />
</front>

<seriesInfo value="906" name="RFC" />
</reference>


<reference target2="reference.RFC.0907.xml" anchor="RFC0907">
<front>
<title>Host Access Protocol specification</title>
<author>
<organization>Bolt Beranek and Newman (BBN) Laboratories</organization>

<address>
<postal>
<street>10 Moulton Street</street>
<city>Cambridge</city>
<region>MA</region>
<code>02238</code>
<country>US</country>
</postal>

</address>
</author>

<date year="1984" day="1" month="July" />
</front>

<seriesInfo value="40" name="STD" />
<seriesInfo value="907" name="RFC" />
</reference>


<reference target2="reference.RFC.0908.xml" anchor="RFC0908">
<front>
<title abbrev="RDP Specification">Reliable Data Protocol</title>
<author fullname="David Velten" initials="D." surname="Velten">
<organization>Bolt Baranek and Newman (BBN) Communications Corporation</organization>
</author>

<author fullname="Robert Hinden" initials="R." surname="Hinden">
<organization>Bolt Baranek and Newman (BBN) Communications Corporation</organization>
</author>

<author fullname="Jack Sax" initials="J." surname="Sax">
<organization>Bolt Baranek and Newman (BBN) Communications Corporation</organization>
</author>

<date year="1984" day="1" month="July" />
</front>

<seriesInfo value="908" name="RFC" />
</reference>


<reference target2="reference.RFC.0909.xml" anchor="RFC0909">
<front>
<title abbrev="LDP Specification">Loader Debugger Protocol</title>
<author fullname="Christopher Welles" initials="C." surname="Welles">
<organization>Bolt Baranek and Newman Communications Corporation (BBNCC)</organization>
</author>

<author fullname="Walter Milliken" initials="W." surname="Milliken">
<organization>Bolt Baranek and Newman (BBN) Laboratories</organization>
</author>

<date year="1984" day="1" month="July" />
</front>

<seriesInfo value="909" name="RFC" />
</reference>


<reference target2="reference.RFC.0910.xml" anchor="RFC0910">
<front>
<title>Multimedia mail meeting notes</title>
<author fullname="Harry Forsdick" initials="H." surname="Forsdick">
<organization>Bolt Baranek and Newman (BBN) Laboratories</organization>
</author>

<date year="1984" day="1" month="August" />
</front>

<seriesInfo value="910" name="RFC" />
</reference>


<reference target2="reference.RFC.0911.xml" anchor="RFC0911">
<front>
<title>EGP Gateway under Berkeley UNIX 4.2</title>
<author fullname="Paul Kirton" initials="P." surname="Kirton">
<organization>University of Southern California (USC)/Information Sciences Institute</organization>

<address>
<postal>
<street>4676 Admiralty Way</street>
<city>Marina del Rey</city>
<region>CA</region>
<code>90291</code>
<country>US</country>
</postal>

<phone>+1 213 822 1511</phone>
</address>
</author>

<date year="1984" day="22" month="August" />

<abstract>
<t>This  report  describes an implementation of the Exterior Gateway Protocol that runs under the Unix 4.2 BSD operating system.  Some  issues  related  to  local network configurations are also discussed.</t>
</abstract>
</front>

<seriesInfo value="911" name="RFC" />
</reference>


<reference target2="reference.RFC.0912.xml" anchor="RFC0912">
<front>
<title>Authentication service</title>
<author fullname="Mike St. Johns" initials="M." surname="St. Johns">
<organization>TPSC</organization>
</author>

<date year="1984" day="1" month="September" />
</front>

<seriesInfo value="912" name="RFC" />
</reference>


<reference target2="reference.RFC.0913.xml" anchor="RFC0913">
<front>
<title>Simple File Transfer Protocol</title>
<author fullname="Mark K. Lottor" initials="M." surname="Lottor">
<organization>Massachusetts Institute of Technology (MIT)</organization>
</author>

<date year="1984" day="1" month="September" />
</front>

<seriesInfo value="913" name="RFC" />
</reference>


<reference target2="reference.RFC.0914.xml" anchor="RFC0914">
<front>
<title abbrev="Thinwire Protocol">Thinwire protocol for connecting personal computers to the Internet</title>
<author fullname="David J. Farber" initials="D." surname="Farber">
<organization>University of Delaware</organization>
</author>

<author fullname="Gary S. Delp" initials="G." surname="Delp">
<organization>University of Delaware</organization>
</author>

<author fullname="Thomas M. Conte" initials="T." surname="Conte">
<organization>University of Delaware</organization>
</author>

<date year="1984" day="1" month="September" />
</front>

<seriesInfo value="914" name="RFC" />
</reference>


<reference target2="reference.RFC.0915.xml" anchor="RFC0915">
<front>
<title>Network mail path service</title>
<author fullname="Marc A. Elvy" initials="M." surname="Elvy">
<organization>Harvard University</organization>

<address>
<postal>
<street>33 Oxford Street</street>
<street>108 Aiken Computation Laboratory</street>
<city>Cambridge</city>
<region>MA</region>
<code>02138</code>
<country>US</country>
</postal>

<phone>+1 617 495 5849</phone>
</address>
</author>

<author fullname="Rudy Nedved" initials="R." surname="Nedved">
<organization>Carnegie-Mellon University, Department of Computer Science</organization>

<address>
<postal>
<street>Schenley Park</street>
<city>Pittsburgh</city>
<region>PA</region>
<code>15213</code>
<country>US</country>
</postal>

<phone>+1 412 578 7685</phone>
</address>
</author>

<date year="1984" day="1" month="December" />
</front>

<seriesInfo value="915" name="RFC" />
</reference>


<reference target2="reference.RFC.0916.xml" anchor="RFC0916">
<front>
<title abbrev="Reliable Asynchronous Transfer Protocol">Reliable Asynchronous Transfer Protocol (RATP)</title>
<author fullname="G. Finn" initials="G." surname="Finn">
<organization>University of Southern California (USC)/Information Sciences Institute</organization>

<address>
<postal>
<street>4676 Admiralty Way</street>
<city>Marina del Rey</city>
<region>CA</region>
<code>90291</code>
<country>US</country>
</postal>

<phone>+1 213 822 1511</phone>
</address>
</author>

<date year="1984" day="1" month="October" />
</front>

<seriesInfo value="916" name="RFC" />
</reference>


<reference target2="reference.RFC.0917.xml" anchor="RFC0917">
<front>
<title>Internet subnets</title>
<author fullname="Jeffrey Mogul" initials="J." surname="Mogul">
<organization>Stanford University, Computer Science Department</organization>
</author>

<date year="1984" day="1" month="October" />
</front>

<seriesInfo value="917" name="RFC" />
</reference>


<reference target2="reference.RFC.0918.xml" anchor="RFC0918">
<front>
<title>Post Office Protocol</title>
<author fullname="J. K. Reynolds" initials="J." surname="Reynolds">
<organization>University of Southern California (USC)/Information Sciences Institute</organization>

<address>
<postal>
<street>4676 Admiralty Way</street>
<city>Marina del Rey</city>
<region>CA</region>
<code>90291</code>
<country>US</country>
</postal>

<phone>+1 213 822 1511</phone>
</address>
</author>

<date year="1984" day="1" month="October" />
</front>

<seriesInfo value="918" name="RFC" />
</reference>


<reference target2="reference.RFC.0919.xml" anchor="RFC0919">
<front>
<title>Broadcasting Internet Datagrams</title>
<author fullname="Jeffrey Mogul" initials="J." surname="Mogul">
<organization>Stanford University, Computer Science Department</organization>
</author>

<date year="1984" day="1" month="October" />
</front>

<seriesInfo value="5" name="STD" />
<seriesInfo value="919" name="RFC" />
</reference>


<reference target2="reference.RFC.0920.xml" anchor="RFC0920">
<front>
<title>Domain requirements</title>
<author fullname="J. Postel" initials="J." surname="Postel">
<organization>University of Southern California (USC)/Information Sciences Institute</organization>

<address>
<postal>
<street>4676 Admiralty Way</street>
<city>Marina del Rey</city>
<region>CA</region>
<code>90291</code>
<country>US</country>
</postal>

<phone>+1 213 822 1511</phone>
</address>
</author>

<author fullname="J. Reynolds" initials="J." surname="Reynolds">
<organization>University of Southern California (USC)/Information Sciences Institute</organization>

<address>
<postal>
<street>4676 Admiralty Way</street>
<city>Marina del Rey</city>
<region>CA</region>
<code>90291</code>
<country>US</country>
</postal>

<phone>+1 213 822 1511</phone>
</address>
</author>

<date year="1984" day="1" month="October" />
</front>

<seriesInfo value="920" name="RFC" />
</reference>


<reference target2="reference.RFC.0921.xml" anchor="RFC0921">
<front>
<title>Domain name system implementation schedule - revised</title>
<author fullname="Jon Postel" initials="J." surname="Postel">
<organization>University of Southern California (USC)/Information Sciences Institute</organization>

<address>
<postal>
<street>4676 Admiralty Way</street>
<city>Marina del Rey</city>
<region>CA</region>
<code>90291</code>
<country>US</country>
</postal>

<phone>+1 213 822 1511</phone>
</address>
</author>

<date year="1984" day="1" month="October" />
</front>

<seriesInfo value="921" name="RFC" />
</reference>


<reference target2="reference.RFC.0922.xml" anchor="RFC0922">
<front>
<title>Broadcasting Internet datagrams in the presence of subnets</title>
<author fullname="Jeffrey Mogul" initials="J." surname="Mogul">
<organization>Stanford University, Computer Science Department</organization>
</author>

<date year="1984" day="1" month="October" />
</front>

<seriesInfo value="5" name="STD" />
<seriesInfo value="922" name="RFC" />
</reference>


<reference target2="reference.RFC.0923.xml" anchor="RFC0923">
<front>
<title abbrev="Assigned Numbers Network Numbers">Assigned numbers</title>
<author fullname="Joyce Reynolds" initials="J." surname="Reynolds">
<organization>University of Southern California (USC)/Information Sciences Institute</organization>

<address>
<postal>
<street>4676 Admiralty Way</street>
<city>Marina del Rey</city>
<region>CA</region>
<code>90292-6695</code>
<country>US</country>
</postal>

<phone>+1 213 822 1511</phone>
<email>JKREYNOLDS@USC-ISIF.ARPA</email>
</address>
</author>

<author fullname="J. Postel" initials="J." surname="Postel">
<organization>University of Southern California (USC)/Information Sciences Institute</organization>

<address>
<postal>
<street>4676 Admiralty Way</street>
<city>Marina del Rey</city>
<region>CA</region>
<code>90291</code>
<country>US</country>
</postal>

<phone>+1 213 822 1511</phone>
</address>
</author>

<date year="1984" day="1" month="October" />
</front>

<seriesInfo value="923" name="RFC" />
</reference>


<reference target2="reference.RFC.0924.xml" anchor="RFC0924">
<front>
<title>Official ARPA-Internet protocols for connecting personal computers to the Internet</title>
<author fullname="J. Reynolds" initials="J." surname="Reynolds">
<organization>University of Southern California (USC)/Information Sciences Institute</organization>

<address>
<postal>
<street>4676 Admiralty Way</street>
<city>Marina del Rey</city>
<region>CA</region>
<code>90292-6695</code>
<country>US</country>
</postal>

<phone>+1 213 822 1511</phone>
<email>JKREYNOLDS@USC-ISIF.ARPA</email>
</address>
</author>

<author fullname="J. Postel" initials="J." surname="Postel">
<organization>University of Southern California (USC)/Information Sciences Institute</organization>

<address>
<postal>
<street>4676 Admiralty Way</street>
<city>Marina del Rey</city>
<region>CA</region>
<code>90291</code>
<country>US</country>
</postal>

<phone>+1 213 822 1511</phone>
</address>
</author>

<date year="1984" day="1" month="October" />
</front>

<seriesInfo value="924" name="RFC" />
</reference>


<reference target2="reference.RFC.0925.xml" anchor="RFC0925">
<front>
<title>Multi-LAN address resolution</title>
<author fullname="J. Postel" initials="J." surname="Postel">
<organization>University of Southern California (USC)/ISI</organization>

<address>
<postal>
<street>4676 Admiralty Way</street>
<city>Marina del Rey</city>
<region>CA</region>
<code>90291</code>
<country>US</country>
</postal>

<phone>+1 213 822 1511</phone>
</address>
</author>

<date year="1984" day="1" month="October" />
</front>

<seriesInfo value="925" name="RFC" />
</reference>


<reference target2="reference.RFC.0926.xml" anchor="RFC0926">
<front>
<title abbrev="ISO DIS 8473 (May 1984)">Protocol for providing the connectionless mode network services</title>
<author>
<organization>International Organization for Standardization</organization>
</author>

<date year="1984" day="1" month="December" />
</front>

<seriesInfo value="926" name="RFC" />
</reference>


<reference target2="reference.RFC.0927.xml" anchor="RFC0927">
<front>
<title abbrev="TUID Telnet Option">TACACS user identification Telnet option</title>
<author fullname="Brian A. Anderson" initials="B." surname="Anderson">
<organization>Bolt Baranek and Newman (BBN)</organization>
</author>

<date year="1984" day="1" month="December" />
</front>

<seriesInfo value="927" name="RFC" />
</reference>


<reference target2="reference.RFC.0928.xml" anchor="RFC0928">
<front>
<title abbrev="Introduction to H-FP">Introduction to proposed DoD standard H-FP</title>
<author fullname="M. A. Padlipsky" initials="M." surname="Padlipsky">
<organization>Mitre Corporation</organization>
</author>

<date year="1984" day="1" month="December" />
</front>

<seriesInfo value="928" name="RFC" />
</reference>


<reference target2="reference.RFC.0929.xml" anchor="RFC0929">
<front>
<title>Proposed Host-Front End Protocol</title>
<author fullname="Joel Lilienkamp" initials="J." surname="Lilienkamp">
<organization>SDC</organization>
</author>

<author fullname="Richard Mandell" initials="R." surname="Mandell">
<organization>SDC</organization>
</author>

<author fullname="Michael Padlipsky" initials="M." surname="Padlipsky">
<organization>Mitre Corporation</organization>
</author>

<date year="1984" day="1" month="December" />
</front>

<seriesInfo value="929" name="RFC" />
</reference>


<reference target2="reference.RFC.0930.xml" anchor="RFC0930">
<front>
<title>Telnet terminal type option</title>
<author fullname="Marvin Solomon" initials="M." surname="Solomon">
<organization>University of Wisconsin - Madison</organization>
</author>

<author fullname="Edward Wimmers" initials="E." surname="Wimmers">
<organization>University of Wisconsin - Madison</organization>
</author>

<date year="1985" day="1" month="January" />
</front>

<seriesInfo value="930" name="RFC" />
</reference>


<reference target2="reference.RFC.0931.xml" anchor="RFC0931">
<front>
<title>Authentication server</title>
<author fullname="Mike St. Johns" initials="M." surname="St. Johns">
<organization>TPSC</organization>
</author>

<date year="1985" day="1" month="January" />
</front>

<seriesInfo value="931" name="RFC" />
</reference>


<reference target2="reference.RFC.0932.xml" anchor="RFC0932">
<front>
<title>Subnetwork addressing scheme</title>
<author fullname="David D. Clark" initials="D." surname="Clark">
<organization>Massachusetts Institute of Technology (MIT), LCS</organization>
</author>

<date year="1985" day="1" month="January" />
</front>

<seriesInfo value="932" name="RFC" />
</reference>


<reference target2="reference.RFC.0933.xml" anchor="RFC0933">
<front>
<title>Output marking Telnet option</title>
<author fullname="S. Silverman" initials="S." surname="Silverman">
<organization>MITRE-Washington</organization>
</author>

<date year="1985" day="1" month="January" />
</front>

<seriesInfo value="933" name="RFC" />
</reference>


<reference target2="reference.RFC.0934.xml" anchor="RFC0934">
<front>
<title abbrev="Message Encapsulation">Proposed standard for message encapsulation</title>
<author fullname="Marshall T. Rose" initials="M." surname="Rose">
<organization>University of Delaware, Department of Computer and Information Sciences</organization>

<address>
<postal>
<street />
<city>Newark</city>
<region>DE</region>
<code>19716</code>
<country>US</country>
</postal>

<email>MRose@UDel.ARPA</email>
</address>
</author>

<author fullname="Einar A. Stefferud" initials="E." surname="Stefferud">
<organization>Network Management Associates, Inc.</organization>

<address>
<postal>
<street>17301 Drey Lane</street>
<city>Huntington Beach</city>
<region>CA</region>
<code>92647</code>
<country>US</country>
</postal>

<email>Stef@UCI.ARPA</email>
</address>
</author>

<date year="1985" day="1" month="January" />
</front>

<seriesInfo value="934" name="RFC" />
</reference>


<reference target2="reference.RFC.0935.xml" anchor="RFC0935">
<front>
<title>Reliable link layer protocols</title>
<author fullname="J. Robinson" initials="J." surname="Robinson">
<organization>Bolt Baranek and Newman (BBN)</organization>
</author>

<date year="1985" day="1" month="January" />
</front>

<seriesInfo value="935" name="RFC" />
</reference>


<reference target2="reference.RFC.0936.xml" anchor="RFC0936">
<front>
<title>Another Internet subnet addressing scheme</title>
<author fullname="Michael J. Karels" initials="M." surname="Karels">
<organization>University California, Berkeley</organization>
</author>

<date year="1985" day="1" month="February" />
</front>

<seriesInfo value="936" name="RFC" />
</reference>


<reference target2="reference.RFC.0937.xml" anchor="RFC0937">
<front>
<title abbrev="Post Office Protocol">Post Office Protocol: Version 2</title>
<author fullname="M. Butler" initials="M." surname="Butler">
<organization>University of Southern California (USC)/Information Sciences Institute</organization>

<address>
<postal>
<street>4676 Admiralty Way</street>
<city>Marina del Rey</city>
<region>CA</region>
<code>90291</code>
<country>US</country>
</postal>

<phone>+1 213 822 1511</phone>
</address>
</author>

<author fullname="J. Postel" initials="J." surname="Postel">
<organization>University of Southern California (USC)/Information Sciences Institute</organization>

<address>
<postal>
<street>4676 Admiralty Way</street>
<city>Marina del Rey</city>
<region>CA</region>
<code>90291</code>
<country>US</country>
</postal>

<phone>+1 213 822 1511</phone>
</address>
</author>

<author fullname="D. Chase" initials="D." surname="Chase">
<organization>University of Southern California (USC)/Information Sciences Institute</organization>

<address>
<postal>
<street>4676 Admiralty Way</street>
<city>Marina del Rey</city>
<region>CA</region>
<code>90291</code>
<country>US</country>
</postal>

<phone>+1 213 822 1511</phone>
</address>
</author>

<author fullname="J. Goldberger" initials="J." surname="Goldberger">
<organization>University of Southern California (USC)/Information Sciences Institute</organization>

<address>
<postal>
<street>4676 Admiralty Way</street>
<city>Marina del Rey</city>
<region>CA</region>
<code>90291</code>
<country>US</country>
</postal>

<phone>+1 213 822 1511</phone>
</address>
</author>

<author fullname="J. K. Reynolds" initials="J." surname="Reynolds">
<organization>University of Southern California (USC)/Information Sciences Institute</organization>

<address>
<postal>
<street>4676 Admiralty Way</street>
<city>Marina del Rey</city>
<region>CA</region>
<code>90291</code>
<country>US</country>
</postal>

<phone>+1 213 822 1511</phone>
</address>
</author>

<date year="1985" day="1" month="February" />
</front>

<seriesInfo value="937" name="RFC" />
</reference>


<reference target2="reference.RFC.0938.xml" anchor="RFC0938">
<front>
<title abbrev="Internet Reliable Transaction Protocol">Internet Reliable Transaction Protocol functional and interface specification</title>
<author fullname="Trudy Miller" initials="T." surname="Miller">
<organization>Advanced Computer Communications (ACC)</organization>

<address>
<postal>
<street>720 Santa Barbara Street</street>
<city>Santa Barbara</city>
<region>CA</region>
<code>93101</code>
<country>US</country>
</postal>

<phone>+1 805 963 9431</phone>
</address>
</author>

<date year="1985" day="1" month="February" />

<abstract>
<t>The Internet Reliable Transaction Protocol (IRTP) is a transport level host to host protocol designed for an internet environment.  It provides reliable, sequenced delivery of packets of data between hosts and multiplexes/demultiplexes streams of packets from/to user processes representing ports.  It is simple to implement, with a minimum of connection management, at the possible expense of efficiency.</t>
</abstract>
</front>

<seriesInfo value="938" name="RFC" />
</reference>


<reference target2="reference.RFC.0939.xml" anchor="RFC0939">
<front>
<title abbrev="Executive Summary of the NRC Report Transport on Protocols">Executive summary of the NRC report on transport protocols for Department of Defense data networks</title>
<author>
<organization>National Research Council, Board on Telecommunications and Computer Applications Commission on Engineering and Technical Systems</organization>

<address>
<postal>
<street>2101 Constitution Avenue NW</street>
<city>Washington</city>
<region>DC</region>
<code>20418</code>
<country>US</country>
</postal>

</address>
</author>

<date year="1985" day="1" month="February" />
</front>

<seriesInfo value="939" name="RFC" />
</reference>


<reference target2="reference.RFC.0940.xml" anchor="RFC0940">
<front>
<title>Toward an Internet standard scheme for subnetting</title>
<author>
<organization>Gateway Algorithms and Data Structures Task Force (GADS)</organization>
</author>

<date year="1985" day="1" month="April" />
</front>

<seriesInfo value="940" name="RFC" />
</reference>


<reference target2="reference.RFC.0941.xml" anchor="RFC0941">
<front>
<title abbrev="Network Layer Addressing">Addendum to the network service definition covering network layer addressing</title>
<author fullname="Alex McKenzie" initials="A." surname="McKenzie">
<organization>Bolt Baranek and Newman (BBN) Laboratories</organization>
</author>

<date year="1985" day="1" month="April" />
</front>

<seriesInfo value="941" name="RFC" />
</reference>


<reference target2="reference.RFC.0942.xml" anchor="RFC0942">
<front>
<title abbrev="Report Transport on Protocols">Transport protocols for Department of Defense data networks</title>
<author>
<organization>National Research Council</organization>

<address>
<postal>
<street>2101 Constitution Avenue NW</street>
<city>Washington</city>
<region>DC</region>
<code>20418</code>
<country>US</country>
</postal>

</address>
</author>

<date year="1985" day="1" month="February" />
</front>

<seriesInfo value="942" name="RFC" />
</reference>


<reference target2="reference.RFC.0943.xml" anchor="RFC0943">
<front>
<title abbrev="Assigned Numbers Network Numbers">Assigned numbers</title>
<author fullname="Joyce Reynolds" initials="J." surname="Reynolds">
<organization>University of Southern California (USC)/Information Sciences Institute</organization>

<address>
<postal>
<street>4676 Admiralty Way</street>
<city>Marina del Rey</city>
<region>CA</region>
<code>90292-6695</code>
<country>US</country>
</postal>

<phone>+1 213 822 1511</phone>
<email>JKREYNOLDS@USC-ISIF.ARPA</email>
</address>
</author>

<author fullname="J. Postel" initials="J." surname="Postel">
<organization>University of Southern California (USC)/Information Sciences Institute</organization>

<address>
<postal>
<street>4676 Admiralty Way</street>
<city>Marina del Rey</city>
<region>CA</region>
<code>90291</code>
<country>US</country>
</postal>

<phone>+1 213 822 1511</phone>
</address>
</author>

<date year="1985" day="1" month="April" />
</front>

<seriesInfo value="943" name="RFC" />
</reference>


<reference target2="reference.RFC.0944.xml" anchor="RFC0944">
<front>
<title>Official ARPA-Internet protocols</title>
<author fullname="Joyce Reynolds" initials="J." surname="Reynolds">
<organization>University of Southern California (USC)/Information Sciences Institute</organization>

<address>
<postal>
<street>4676 Admiralty Way</street>
<city>Marina del Rey</city>
<region>CA</region>
<code>90292-6695</code>
<country>US</country>
</postal>

<phone>+1 213 822 1511</phone>
<email>JKREYNOLDS@USC-ISIF.ARPA</email>
</address>
</author>

<author fullname="J. Postel" initials="J." surname="Postel">
<organization>University of Southern California (USC)/Information Sciences Institute</organization>

<address>
<postal>
<street>4676 Admiralty Way</street>
<city>Marina del Rey</city>
<region>CA</region>
<code>90291</code>
<country>US</country>
</postal>

<phone>+1 213 822 1511</phone>
<email>Postel@USC-ISIF.ARPA</email>
</address>
</author>

<date year="1985" day="1" month="April" />
</front>

<seriesInfo value="944" name="RFC" />
</reference>


<reference target2="reference.RFC.0945.xml" anchor="RFC0945">
<front>
<title>DoD statement on the NRC report</title>
<author fullname="J. Postel" initials="J." surname="Postel">
<organization>University of Southern California (USC)/Information Sciences Institute</organization>

<address>
<postal>
<street>4676 Admiralty Way</street>
<city>Marina del Rey</city>
<region>CA</region>
<code>90291</code>
<country>US</country>
</postal>

<phone>+1 213 822 1511</phone>
</address>
</author>

<date year="1985" day="1" month="May" />
</front>

<seriesInfo value="945" name="RFC" />
</reference>


<reference target2="reference.RFC.0946.xml" anchor="RFC0946">
<front>
<title>Telnet terminal location number option</title>
<author fullname="R. Nedved" initials="R." surname="Nedved">
<organization>Carnegie-Mellon University</organization>
</author>

<date year="1985" day="1" month="May" />
</front>

<seriesInfo value="946" name="RFC" />
</reference>


<reference target2="reference.RFC.0947.xml" anchor="RFC0947">
<front>
<title>Multi-network broadcasting within the Internet</title>
<author fullname="Ken Lebowitz" initials="K." surname="Lebowitz">
<organization>Bolt Beranek and Newman, Inc., BBN Laboratories</organization>
</author>

<author fullname="David Mankins" initials="D." surname="Mankins">
<organization>Bolt Beranek and Newman, Inc., BBN Laboratories</organization>
</author>

<date year="1985" day="1" month="June" />
</front>

<seriesInfo value="947" name="RFC" />
</reference>


<reference target2="reference.RFC.0948.xml" anchor="RFC0948">
<front>
<title abbrev="Transmission of IP Datagrams Over IEEE 802.3 Networks">Two methods for the transmission of IP datagrams over IEEE 802.3 networks</title>
<author fullname="Ira Winston" initials="I." surname="Winston">
<organization>University of Pennsylvania</organization>
</author>

<date year="1985" day="1" month="June" />
</front>

<seriesInfo value="948" name="RFC" />
</reference>


<reference target2="reference.RFC.0949.xml" anchor="RFC0949">
<front>
<title>FTP unique-named store command</title>
<author fullname="Mike Padlipsky" initials="M." surname="Padlipsky">
<organization>Mitre</organization>
</author>

<date year="1985" day="1" month="July" />
</front>

<seriesInfo value="949" name="RFC" />
</reference>


<reference target2="reference.RFC.0950.xml" anchor="RFC0950">
<front>
<title>Internet Standard Subnetting Procedure</title>
<author fullname="J. Mogul" initials="J." surname="Mogul">
<organization>Stanford University</organization>
</author>

<author fullname="J. Postel" initials="J." surname="Postel">
<organization>University of Southern California (USC)/Information Sciences Institute</organization>

<address>
<postal>
<street>4676 Admiralty Way</street>
<city>Marina del Rey</city>
<region>CA</region>
<code>90291</code>
<country>US</country>
</postal>

<phone>+1 213 822 1511</phone>
</address>
</author>

<date year="1985" day="1" month="August" />
</front>

<seriesInfo value="5" name="STD" />
<seriesInfo value="950" name="RFC" />
</reference>


<reference target2="reference.RFC.0951.xml" anchor="RFC0951">
<front>
<title abbrev="Bootstrap Protocol">Bootstrap Protocol</title>
<author fullname="Bill Croft" initials="B." surname="Croft">
<organization>Stanford University</organization>
</author>

<author fullname="John Gilmore" initials="J." surname="Gilmore">
<organization>Sun Microsystems</organization>
</author>

<date year="1985" day="1" month="September" />
</front>

<seriesInfo value="951" name="RFC" />
</reference>


<reference target2="reference.RFC.0952.xml" anchor="RFC0952">
<front>
<title>DoD Internet host table specification</title>
<author fullname="K. Harrenstien" initials="K." surname="Harrenstien">
<organization>SRI International</organization>
</author>

<author fullname="M. Stahl" initials="M." surname="Stahl">
<organization>SRI International</organization>
</author>

<author fullname="E. Feinler" initials="E." surname="Feinler">
<organization>SRI International</organization>
</author>

<date year="1985" day="1" month="October" />
</front>

<seriesInfo value="952" name="RFC" />
</reference>


<reference target2="reference.RFC.0953.xml" anchor="RFC0953">
<front>
<title>Hostname Server</title>
<author fullname="K. Harrenstien" initials="K." surname="Harrenstien">
<organization>SRI International</organization>
</author>

<author fullname="M. Stahl" initials="M." surname="Stahl">
<organization>SRI International</organization>
</author>

<author fullname="E. Feinler" initials="E." surname="Feinler">
<organization>SRI International</organization>
</author>

<date year="1985" day="1" month="October" />
</front>

<seriesInfo value="953" name="RFC" />
</reference>


<reference target2="reference.RFC.0954.xml" anchor="RFC0954">
<front>
<title>NICNAME/WHOIS</title>
<author fullname="K. Harrenstien" initials="K." surname="Harrenstien">
<organization>SRI International</organization>
</author>

<author fullname="M. Stahl" initials="M." surname="Stahl">
<organization>SRI International</organization>
</author>

<author fullname="E. Feinler" initials="E." surname="Feinler">
<organization>SRI International</organization>
</author>

<date year="1985" day="1" month="October" />
</front>

<seriesInfo value="954" name="RFC" />
</reference>


<reference target2="reference.RFC.0955.xml" anchor="RFC0955">
<front>
<title abbrev="Transaction Protocol">Towards a transport service for transaction processing applications</title>
<author fullname="R. Braden" initials="R." surname="Braden">
<organization>University of California, Los Angeles (UCLA), OAC</organization>
</author>

<date year="1985" day="1" month="September" />
</front>

<seriesInfo value="955" name="RFC" />
</reference>


<reference target2="reference.RFC.0956.xml" anchor="RFC0956">
<front>
<title>Algorithms for synchronizing network clocks</title>
<author fullname="D. L. Mills" initials="D." surname="Mills">
<organization>M/A-Com Linkabit</organization>
</author>

<date year="1985" day="1" month="September" />
</front>

<seriesInfo value="956" name="RFC" />
</reference>


<reference target2="reference.RFC.0957.xml" anchor="RFC0957">
<front>
<title>Experiments in network clock synchronization</title>
<author fullname="D. L. Mills" initials="D." surname="Mills">
<organization>M/A-COM Linkabit</organization>
</author>

<date year="1985" day="1" month="September" />
</front>

<seriesInfo value="957" name="RFC" />
</reference>


<reference target2="reference.RFC.0958.xml" anchor="RFC0958">
<front>
<title abbrev="Network Time Protocol">Network Time Protocol (NTP)</title>
<author fullname="D. L. Mills" initials="D." surname="Mills">
<organization>M/A-COM Linkabit</organization>
</author>

<date year="1985" day="1" month="September" />
</front>

<seriesInfo value="958" name="RFC" />
</reference>


<reference target2="reference.RFC.0959.xml" anchor="RFC0959">
<front>
<title abbrev="File Transfer Protocol">File Transfer Protocol</title>
<author fullname="J. Postel" initials="J." surname="Postel">
<organization>Information Sciences Institute (ISI)</organization>
</author>

<author fullname="J. Reynolds" initials="J." surname="Reynolds">
<organization />
</author>

<date year="1985" day="1" month="October" />
</front>

<seriesInfo value="9" name="STD" />
<seriesInfo value="959" name="RFC" />
</reference>


<reference target2="reference.RFC.0960.xml" anchor="RFC0960">
<front>
<title abbrev="Assigned Numbers Network Numbers">Assigned numbers</title>
<author fullname="Joyce Reynolds" initials="J." surname="Reynolds">
<organization>University of Southern California (USC)/Information Sciences Institute</organization>

<address>
<postal>
<street>4676 Admiralty Way</street>
<city>Marina del Rey</city>
<region>CA</region>
<code>90292-6695</code>
<country>US</country>
</postal>

<phone>+1 213 822 1511</phone>
<email>JKREYNOLDS@USC-ISIB.ARPA</email>
</address>
</author>

<author fullname="J. Postel" initials="J." surname="Postel">
<organization>University of Southern California (USC)/Information Sciences Institute</organization>

<address>
<postal>
<street>4676 Admiralty Way</street>
<city>Marina del Rey</city>
<region>CA</region>
<code>90291</code>
<country>US</country>
</postal>

<phone>+1 213 822 1511</phone>
</address>
</author>

<date year="1985" day="1" month="December" />
</front>

<seriesInfo value="960" name="RFC" />
</reference>


<reference target2="reference.RFC.0961.xml" anchor="RFC0961">
<front>
<title>Official ARPA-Internet protocols</title>
<author fullname="J. Reynolds" initials="J." surname="Reynolds">
<organization>University of Southern California (USC)/Information Sciences Institute</organization>

<address>
<postal>
<street>4676 Admiralty Way</street>
<city>Marina del Rey</city>
<region>CA</region>
<code>90292-6695</code>
<country>US</country>
</postal>

<phone>+1 213 822 1511</phone>
<email>JKREYNOLDS@USC-ISIB.ARPA</email>
</address>
</author>

<author fullname="J. Postel" initials="J." surname="Postel">
<organization>University of Southern California (USC)/Information Sciences Institute</organization>

<address>
<postal>
<street>4676 Admiralty Way</street>
<city>Marina del Rey</city>
<region>CA</region>
<code>90291</code>
<country>US</country>
</postal>

<phone>+1 213 822 1511</phone>
</address>
</author>

<date year="1985" day="1" month="December" />
</front>

<seriesInfo value="961" name="RFC" />
</reference>


<reference target2="reference.RFC.0962.xml" anchor="RFC0962">
<front>
<title>TCP-4 prime</title>
<author fullname="M.A. Padlipsky" initials="M.A." surname="Padlipsky">
<organization>Mitre-Bedford</organization>
</author>

<date year="1985" day="1" month="November" />
</front>

<seriesInfo value="962" name="RFC" />
</reference>


<reference target2="reference.RFC.0963.xml" anchor="RFC0963">
<front>
<title abbrev="Some Problems with MIL-STD IP">Some problems with the specification of the Military Standard Internet Protocol</title>
<author fullname="Deepinder P. Sidhu" initials="D." surname="Sidhu">
<organization>Iowa State University</organization>
</author>

<date year="1985" day="1" month="November" />

<abstract>
<t>This paper points out several significant problems in the specification of the Military Standard Internet Protocol (MIL-STD-1777, dated August 1983).  These results are based on an initial investigation of this protocol standard.  The problems are: (1) a failure to reassemble fragmented messages completely; (2) a missing state transition; (3) errors in testing for reassembly completion; (4) errors in computing fragment sizes; (5) minor errors in message reassembly; (6) incorrectly computed length for certain datagrams.  This note also proposes solutions to these problems.</t>
</abstract>
</front>

<seriesInfo value="963" name="RFC" />
</reference>


<reference target2="reference.RFC.0964.xml" anchor="RFC0964">
<front>
<title abbrev="Some Problems with MIL-STD TCP">Some problems with the specification of the Military Standard Transmission Control Protocol</title>
<author fullname="Deepinder P. Sidhu" initials="D." surname="Sidhu">
<organization>SDC - A Burroughs Company</organization>
</author>

<author fullname="Thomas P. Blumer" initials="T." surname="Blumer">
<organization>SDC - A Burroughs Company</organization>
</author>

<date year="1985" day="1" month="November" />

<abstract>
<t>This note points out three errors with the specification of the Military Standard Transmission Control Protocol (MIL-STD-1778, dated August 1983).  These results are based on an initial investigation of this protocol standard.  The first problem is that data accompanying a SYN can not be accepted because of errors in the acceptance policy.  The second problem is that no retransmission timer is set for a SYN packet, and therefore the SYN will not be retransmitted if it is lost.  The third problem is that when the connection has been established, neither entity takes the proper steps to accept incoming data.  This note also proposes solutions to these problems.</t>
</abstract>
</front>

<seriesInfo value="964" name="RFC" />
</reference>


<reference target2="reference.RFC.0965.xml" anchor="RFC0965">
<front>
<title>Format for a graphical communication protocol</title>
<author fullname="Lorenzo Aguilar" initials="L." surname="Aguilar">
<organization>SRI International</organization>
</author>

<date year="1985" day="1" month="December" />

<abstract>
<t>This paper describes the requirements for a graphical format on which to base a graphical on-line communication protocol. It is argued that on-line graphical communication is similar to graphical session capture, and thus we propose an Interactive Graphical Communication Format using the GKSM session metafile.</t>

<t>We discuss the items that we believe complement the GKSM metafile as a format for on-line interactive exchanges. One key application area of such a format is multi-media on-line conferencing; therefore, we  present a conferencing software architecture for processing the proposed format. We make this format specification available to those planning multi-media conferencing systems as a contribution toward the development of a graphical communication protocol that will permit the interoperation of these systems.</t>

<t>We hope this contribution will encourage the discussion of multimedia data exchange and the proposal of solutions. At SRI, we stay open to the exploration of alternatives and we will continue our research and development work in this problem area.</t>
</abstract>
</front>

<seriesInfo value="965" name="RFC" />
</reference>


<reference target2="reference.RFC.0966.xml" anchor="RFC0966">
<front>
<title>Host groups: A multicast extension to the Internet Protocol</title>
<author fullname="S. E. Deering" initials="S." surname="Deering">
<organization>Stanford University</organization>
</author>

<author fullname="D. R. Cheriton" initials="D." surname="Cheriton">
<organization>Stanford University</organization>
</author>

<date year="1985" day="1" month="December" />
</front>

<seriesInfo value="966" name="RFC" />
</reference>


<reference target2="reference.RFC.0967.xml" anchor="RFC0967">
<front>
<title>All victims together</title>
<author fullname="M. A. Padlipsky" initials="M." surname="Padlipsky">
<organization>The Mitre Corporation</organization>
</author>

<date year="1985" day="1" month="December" />
</front>

<seriesInfo value="967" name="RFC" />
</reference>


<reference target2="reference.RFC.0968.xml" anchor="RFC0968">
<front>
<title>Twas the night before start-up</title>
<author fullname="V. Cerf" initials="V." surname="Cerf">
<organization>MCI</organization>
</author>

<date year="1985" day="1" month="December" />
</front>

<seriesInfo value="968" name="RFC" />
</reference>


<reference target2="reference.RFC.0969.xml" anchor="RFC0969">
<front>
<title>NETBLT: A bulk data transfer protocol</title>
<author fullname="David D. Clark" initials="D." surname="Clark">
<organization>Massachusetts Institute of Technology (MIT), Laboratory for Computer Science</organization>
</author>

<author fullname="Mark L. Lambert" initials="M." surname="Lambert">
<organization>Massachusetts Institute of Technology (MIT), Laboratory for Computer Science</organization>
</author>

<author fullname="Lixia Zhang" initials="L." surname="Zhang">
<organization>Massachusetts Institute of Technology (MIT), Laboratory for Computer Science</organization>
</author>

<date year="1985" day="1" month="December" />
</front>

<seriesInfo value="969" name="RFC" />
</reference>


<reference target2="reference.RFC.0970.xml" anchor="RFC0970">
<front>
<title>On packet switches with infinite storage</title>
<author fullname="John Nagle" initials="J." surname="Nagle">
<organization>FACC Palo Alto</organization>
</author>

<date year="1985" day="1" month="December" />

<abstract>
<t>Most prior work on congestion in datagram systems focuses on buffer management.  We find it illuminating to consider the case of a packet switch with infinite storage.  Such a packet switch can never run out of buffers. It can, however, still become congested.  The meaning of congestion in an infinite-storage system is explored.  We demonstrate the unexpected result that a datagram network with infinite storage, first-in-first-out queuing, at least two packet switches, and a finite packet lifetime will, under overload, drop all packets.  By attacking the problem of congestion for the infinite-storage case, we discover new solutions applicable to switches with finite storage.</t>
</abstract>
</front>

<seriesInfo value="970" name="RFC" />
</reference>


<reference target2="reference.RFC.0971.xml" anchor="RFC0971">
<front>
<title>Survey of data representation standards</title>
<author fullname="Annette L. DeSchon" initials="A." surname="DeSchon">
<organization>University of Southern California (USC)/Information Sciences Institute</organization>

<address>
<postal>
<street>4676 Admiralty Way</street>
<city>Marina del Rey</city>
<region>CA</region>
<code>90291</code>
<country>US</country>
</postal>

<phone>+1 213 822 1511</phone>
</address>
</author>

<date year="1986" day="1" month="January" />
</front>

<seriesInfo value="971" name="RFC" />
</reference>


<reference target2="reference.RFC.0972.xml" anchor="RFC0972">
<front>
<title>Password Generator Protocol</title>
<author fullname="F. Wancho" initials="F." surname="Wancho">
<organization>White Sands Missile Range (WSMR)</organization>
</author>

<date year="1986" day="1" month="January" />
</front>

<seriesInfo value="972" name="RFC" />
</reference>


<reference target2="reference.RFC.0973.xml" anchor="RFC0973">
<front>
<title>Domain system changes and observations</title>
<author fullname="P. Mockapetris" initials="P." surname="Mockapetris">
<organization>University of Southern California (USC)/Information Sciences Institute</organization>

<address>
<postal>
<street>4676 Admiralty Way</street>
<city>Marina del Rey</city>
<region>CA</region>
<code>90291</code>
<country>US</country>
</postal>

<phone>+1 213 822 1511</phone>
</address>
</author>

<date year="1986" day="1" month="January" />
</front>

<seriesInfo value="973" name="RFC" />
</reference>


<reference target2="reference.RFC.0974.xml" anchor="RFC0974">
<front>
<title>Mail routing and the domain system</title>
<author fullname="Craig Partridge" initials="C." surname="Partridge">
<organization>Bolt Baranek and Newman (BBN) Laboratories Inc., CSNET CIC</organization>
</author>

<date year="1986" day="1" month="January" />
</front>

<seriesInfo value="974" name="RFC" />
</reference>


<reference target2="reference.RFC.0975.xml" anchor="RFC0975">
<front>
<title>Autonomous confederations</title>
<author fullname="D. L. Mills" initials="D." surname="Mills">
<organization>M/A-COM Linkabit</organization>
</author>

<date year="1986" day="1" month="February" />
</front>

<seriesInfo value="975" name="RFC" />
</reference>


<reference target2="reference.RFC.0976.xml" anchor="RFC0976">
<front>
<title>UUCP mail interchange format standard</title>
<author fullname="Mark. R. Horton" initials="M." surname="Horton">
<organization>Bell Laboratories</organization>
</author>

<date year="1986" day="1" month="February" />
</front>

<seriesInfo value="976" name="RFC" />
</reference>


<reference target2="reference.RFC.0977.xml" anchor="RFC0977">
<front>
<title abbrev="Network News Transfer Protocol">Network News Transfer Protocol</title>
<author fullname="Brian Kantor" initials="B." surname="Kantor">
<organization>University of California, San Diego (UCSD)</organization>
</author>

<author fullname="Phil Lapsley" initials="P." surname="Lapsley">
<organization>University of California, Berkeley (UCB)</organization>
</author>

<date year="1986" day="1" month="February" />
</front>

<seriesInfo value="977" name="RFC" />
</reference>


<reference target2="reference.RFC.0978.xml" anchor="RFC0978">
<front>
<title abbrev="Voice File Interchange Protocol">Voice File Interchange Protocol (VFIP)</title>
<author fullname="J. K. Reynolds" initials="J." surname="Reynolds">
<organization>University of Southern California (USC)/Information Sciences Institute</organization>

<address>
<postal>
<street>4676 Admiralty Way</street>
<city>Marina del Rey</city>
<region>CA</region>
<code>90291</code>
<country>US</country>
</postal>

<phone>+1 213 822 1511</phone>
</address>
</author>

<author fullname="R. Gillmann" initials="R." surname="Gillmann">
<organization>Inner Loop</organization>
</author>

<author fullname="W. A. Brackenridge" initials="W." surname="Brackenridge">
<organization>Alembic</organization>
</author>

<author fullname="A. Witkowski" initials="A." surname="Witkowski">
<organization>Inner Loop</organization>
</author>

<author fullname="J. Postel" initials="J." surname="Postel">
<organization>University of Southern California (USC)/Information Sciences Institute</organization>

<address>
<postal>
<street>4676 Admiralty Way</street>
<city>Marina del Rey</city>
<region>CA</region>
<code>90291</code>
<country>US</country>
</postal>

<phone>+1 213 822 1511</phone>
</address>
</author>

<date year="1986" day="1" month="February" />
</front>

<seriesInfo value="978" name="RFC" />
</reference>


<reference target2="reference.RFC.0979.xml" anchor="RFC0979">
<front>
<title>PSN End-to-End functional specification</title>
<author fullname="Andrew G. Malis" initials="A." surname="Malis">
<organization>Bolt Baranek and Newman (BBN) Communications Corp.</organization>
</author>

<date year="1986" day="1" month="March" />
</front>

<seriesInfo value="979" name="RFC" />
</reference>


<reference target2="reference.RFC.0980.xml" anchor="RFC0980">
<front>
<title>Protocol document order information</title>
<author fullname="Ole Jacobsen" initials="O." surname="Jacobsen">
<organization>SRI International</organization>

<address>
<postal>
<street>333 Ravenswood Avenue</street>
<city>Menlo Park</city>
<region>CA</region>
<code>94025</code>
<country>US</country>
</postal>

<phone>+1 415 859 3695</phone>
</address>
</author>

<author fullname="Jon Postel" initials="J." surname="Postel">
<organization>University of Southern California (USC)/Information Sciences Institute</organization>

<address>
<postal>
<street>4676 Admiralty Way</street>
<city>Marina del Rey</city>
<region>CA</region>
<code>90291</code>
<country>US</country>
</postal>

<phone>+1 213 822 1511</phone>
</address>
</author>

<date year="1986" day="1" month="March" />
</front>

<seriesInfo value="980" name="RFC" />
</reference>


<reference target2="reference.RFC.0981.xml" anchor="RFC0981">
<front>
<title>Experimental multiple-path routing algorithm</title>
<author fullname="D. L. Mills" initials="D." surname="Mills">
<organization>M/A-COM Linkabit</organization>
</author>

<date year="1986" day="1" month="March" />

<abstract>
<t>This document introduces wiretap algorithms, which are a class of routing algorithms that compute quasi-optimum routes for stations sharing a broadcast channel, but with some stations hidden from others. The wiretapper observes the paths (source routes) used by other stations sending traffic on the channel and, using a heuristic set of factors and weights, constructs speculative paths for its own traffic.  A prototype algorithm, called here the Wiretap Algorithm, has been designed for the AX.25 packet-radio channel.  Its design is similar in many respects to the shortest-path-first (spf) algorithm used in the ARPANET and elsewhere, and is in fact a variation in the class of algorithms, including the Viterbi Algorithm, that construct optimum paths on a graph according to a distance computed as a weighted sum of factors assigned to the nodes and edges.</t>

<t>The Wiretap Algorithm differs from conventional algorithms in that it computes not only the primary route (a minimum-distance path), but also additional paths ordered by distance, which serve as alternate routes should the primary route fail.  This feature is also useful for the discovery of new paths not previously observed on the channel.</t>

<t>Since the amateur AX.25 packet-radio channel is very active in the Washington, DC, area and carries a good deal of traffic under punishing conditions, it was considered a sufficiently heroic environment for a convincing demonstration of the prototype algorithm.  It was implemented as part of an IP/TCP driver for the LSI-11 processor running the "fuzzball" operating system.  The driver is connected via serial line to a 6809-based TAPR-1 processor running the WA8DED firmware, which controls the radio equipmnet in both virtual-circuit and datagram modes. The prototype implementation provides primary and alternate routes, can route around congested areas and can change routes during a connection. This document describes the design, implementation and initial testing of the algorithm.</t>
</abstract>
</front>

<seriesInfo value="981" name="RFC" />
</reference>


<reference target2="reference.RFC.0982.xml" anchor="RFC0982">
<front>
<title>Guidelines for the specification of the structure of the Domain Specific Part (DSP) of the ISO standard NSAP address</title>
<author fullname="Hans-Werner Braun" initials="H." surname="Braun">
<organization>University of Michigan</organization>

<address>
<postal>
<street />
<city />
<region />
<code />
<country>US</country>
</postal>

<email>HWB@GW.UMICH.EDU</email>
</address>
</author>

<date year="1986" day="1" month="April" />
</front>

<seriesInfo value="982" name="RFC" />
</reference>


<reference target2="reference.RFC.0983.xml" anchor="RFC0983">
<front>
<title>ISO transport arrives on top of the TCP</title>
<author fullname="D. E. Cass" initials="D." surname="Cass">
<organization>Northrop Research and Technology Center (NRTC)</organization>
</author>

<author fullname="M. T. Rose" initials="M." surname="Rose">
<organization>Northrop Research and Technology Center (NRTC)</organization>
</author>

<date year="1986" day="1" month="April" />
</front>

<seriesInfo value="983" name="RFC" />
</reference>


<reference target2="reference.RFC.0984.xml" anchor="RFC0984">
<front>
<title abbrev="PCMAIL">PCMAIL: A distributed mail system for personal computers</title>
<author fullname="David D. Clark" initials="D." surname="Clark">
<organization>Massachusetts Institute of Technology (MIT), Laboratory for Computer Science</organization>
</author>

<author fullname="Mark L. Lambert" initials="M." surname="Lambert">
<organization>Massachusetts Institute of Technology (MIT), Laboratory for Computer Science</organization>
</author>

<date year="1986" day="1" month="May" />
</front>

<seriesInfo value="984" name="RFC" />
</reference>


<reference target2="reference.RFC.0985.xml" anchor="RFC0985">
<front>
<title>Requirements for Internet gateways - draft</title>
<author>
<organization>National Science Foundation</organization>
</author>

<date year="1986" day="1" month="May" />
</front>

<seriesInfo value="985" name="RFC" />
</reference>


<reference target2="reference.RFC.0986.xml" anchor="RFC0986">
<front>
<title abbrev="DOD IP Addresses in ISO CLNP">Guidelines for the use of Internet-IP addresses in the ISO Connectionless-Mode Network Protocol</title>
<author fullname="Ross Callon" initials="R." surname="Callon">
<organization>Bolt Baranek and Newman (BBN)</organization>
</author>

<author fullname="Hans-Werner Braun" initials="H." surname="Braun">
<organization>University of Michigan</organization>
</author>

<date year="1986" day="1" month="June" />
</front>

<seriesInfo value="986" name="RFC" />
</reference>


<reference target2="reference.RFC.0987.xml" anchor="RFC0987">
<front>
<title>Mapping between X.400 and RFC 822</title>
<author fullname="S. E. Kille" initials="S." surname="Kille">
<organization>University College of London</organization>
</author>

<date year="1986" day="1" month="June" />
</front>

<seriesInfo value="987" name="RFC" />
</reference>


<reference target2="reference.RFC.0988.xml" anchor="RFC0988">
<front>
<title>Host extensions for IP multicasting</title>
<author fullname="S. E. Deering" initials="S." surname="Deering">
<organization>Stanford University</organization>
</author>

<date year="1986" day="1" month="July" />
</front>

<seriesInfo value="988" name="RFC" />
</reference>


<reference target2="reference.RFC.0989.xml" anchor="RFC0989">
<front>
<title>Privacy enhancement for Internet electronic mail: Part I: Message encipherment and authentication procedures</title>
<author fullname="John Linn" initials="J." surname="Linn">
<organization>Bolt Baranek and Newman Communications (BBNCC)</organization>
</author>

<author>
<organization>IAB Privacy Task Force</organization>
</author>

<date year="1987" day="1" month="February" />
</front>

<seriesInfo value="989" name="RFC" />
</reference>


<reference target2="reference.RFC.0990.xml" anchor="RFC0990">
<front>
<title>Assigned numbers</title>
<author fullname="J. K. Reynolds" initials="J." surname="Reynolds">
<organization>University of Southern California (USC)/ Information Sciences Institute (ISI)</organization>

<address>
<postal>
<street>4676 Admiralty Way</street>
<city>Marina del Rey</city>
<region>CA</region>
<code>90292-6695</code>
<country>US</country>
</postal>

<phone>+1 213 822 1511</phone>
<email>JKREYNOLDS@ISI.EDU</email>
</address>
</author>

<author fullname="J. Postel" initials="J." surname="Postel">
<organization>Information Sciences Institute (ISI)</organization>
</author>

<date year="1986" day="1" month="November" />
</front>

<seriesInfo value="990" name="RFC" />
</reference>


<reference target2="reference.RFC.0991.xml" anchor="RFC0991">
<front>
<title>Official ARPA-Internet protocols</title>
<author fullname="J. K. Reynolds" initials="J." surname="Reynolds">
<organization>University of Southern California (USC)/Information Sciences Institute</organization>

<address>
<postal>
<street>4676 Admiralty Way</street>
<city>Marina del Rey</city>
<region>CA</region>
<code>90292-6695</code>
<country>US</country>
</postal>

<phone>+1 213 822 1511</phone>
<email>JKREYNOLDS@ISI.EDU</email>
</address>
</author>

<author fullname="J. Postel" initials="J." surname="Postel">
<organization>University of Southern California (USC)/Information Sciences Institute</organization>

<address>
<postal>
<street>4676 Admiralty Way</street>
<city>Marina del Rey</city>
<region>CA</region>
<code>90291</code>
<country>US</country>
</postal>

<phone>+1 213 822 1511</phone>
</address>
</author>

<date year="1986" day="1" month="November" />
</front>

<seriesInfo value="991" name="RFC" />
</reference>


<reference target2="reference.RFC.0992.xml" anchor="RFC0992">
<front>
<title>On communication support for fault tolerant process groups</title>
<author fullname="K. P. Birman" initials="K." surname="Birman">
<organization>Cornell University, Dept. of Computer Science</organization>

<address>
<postal>
<street />
<city>Ithaca</city>
<region>NY</region>
<code>14853</code>
<country>US</country>
</postal>

<phone>+1 607 255 9199</phone>
</address>
</author>

<author fullname="T. A. Joseph" initials="T." surname="Joseph">
<organization>Cornell University, Dept. of Computer Science</organization>

<address>
<postal>
<street />
<city>Ithaca</city>
<region>NY</region>
<code>14853</code>
<country>US</country>
</postal>

<phone>+1 607 255 9199</phone>
</address>
</author>

<date year="1986" day="1" month="November" />
</front>

<seriesInfo value="992" name="RFC" />
</reference>


<reference target2="reference.RFC.0993.xml" anchor="RFC0993">
<front>
<title>PCMAIL: A distributed mail system for personal computers</title>
<author fullname="David D. Clark" initials="D." surname="Clark">
<organization>Massachusetts Institute of Technology (MIT)</organization>
</author>

<author fullname="Mark L. Lambert" initials="M." surname="Lambert">
<organization>Massachusetts Institute of Technology (MIT)</organization>
</author>

<date year="1986" day="1" month="December" />
</front>

<seriesInfo value="993" name="RFC" />
</reference>


<reference target2="reference.RFC.0994.xml" anchor="RFC0994">
<front>
<title abbrev="ISO 8473">Final text of DIS 8473, Protocol for Providing the Connectionless-mode Network Service</title>
<author>
<organization>International Organization for Standardization (ISO)</organization>
</author>

<author>
<organization>American National Standards Institute (ANSI)</organization>
</author>

<date year="1986" day="1" month="March" />
</front>

<seriesInfo value="994" name="RFC" />
</reference>


<reference target2="reference.RFC.0995.xml" anchor="RFC0995">
<front>
<title abbrev="ISO N4053">End System to Intermediate System Routing Exchange Protocol for use in conjunction with ISO 8473</title>
<author>
<organization>International Organization for Standardization</organization>
</author>

<author>
<organization>American National Standards Institute (ANSI)</organization>
</author>

<date year="1986" day="1" month="April" />
</front>

<seriesInfo value="995" name="RFC" />
</reference>


<reference target2="reference.RFC.0996.xml" anchor="RFC0996">
<front>
<title>Statistics server</title>
<author fullname="D. L. Mills" initials="D." surname="Mills">
<organization>University of Delaware</organization>
</author>

<date year="1987" day="1" month="February" />
</front>

<seriesInfo value="996" name="RFC" />
</reference>


<reference target2="reference.RFC.0997.xml" anchor="RFC0997">
<front>
<title>Internet numbers</title>
<author fullname="J. Reynolds" initials="J." surname="Reynolds">
<organization>University of Southern California (USC)/Information Sciences Institute</organization>

<address>
<postal>
<street>4676 Admiralty Way</street>
<city>Marina del Rey</city>
<region>CA</region>
<code>90291</code>
<country>US</country>
</postal>

<phone>+1 213 822 1511</phone>
</address>
</author>

<author fullname="J. Postel" initials="J." surname="Postel">
<organization>University of Southern California (USC)/Information Sciences Institute</organization>

<address>
<postal>
<street>4676 Admiralty Way</street>
<city>Marina del Rey</city>
<region>CA</region>
<code>90291</code>
<country>US</country>
</postal>

<phone>+1 213 822 1511</phone>
</address>
</author>

<date year="1987" day="1" month="March" />
</front>

<seriesInfo value="997" name="RFC" />
</reference>


<reference target2="reference.RFC.0998.xml" anchor="RFC0998">
<front>
<title>NETBLT: A bulk data transfer protocol</title>
<author fullname="David D. Clark" initials="D." surname="Clark">
<organization>Massachusetts Institute of Technology (MIT)</organization>
</author>

<author fullname="Mark L Lambert" initials="M." surname="Lambert">
<organization>Massachusetts Institute of Technology (MIT)</organization>
</author>

<author fullname="Lixia Zhang" initials="L." surname="Zhang">
<organization>Massachusetts Institute of Technology (MIT)</organization>
</author>

<date year="1987" day="1" month="March" />
</front>

<seriesInfo value="998" name="RFC" />
</reference>


<reference target2="reference.RFC.0999.xml" anchor="RFC0999">
<front>
<title>Requests For Comments summary notes: 900-999</title>
<author fullname="A. Westine" initials="A." surname="Westine">
<organization>University of Southern California (USC)/Information Sciences Institute</organization>

<address>
<postal>
<street>4676 Admiralty Way</street>
<city>Marina del Rey</city>
<region>CA</region>
<code>90291</code>
<country>US</country>
</postal>

<phone>+1 213 822 1511</phone>
</address>
</author>

<author fullname="J. Postel" initials="J." surname="Postel">
<organization>University of Southern California (USC)/Information Sciences Institute</organization>

<address>
<postal>
<street>4676 Admiralty Way</street>
<city>Marina del Rey</city>
<region>CA</region>
<code>90291</code>
<country>US</country>
</postal>

<phone>+1 213 822 1511</phone>
</address>
</author>

<date year="1987" day="1" month="April" />
</front>

<seriesInfo value="999" name="RFC" />
</reference>


<reference target2="reference.RFC.1000.xml" anchor="RFC1000">
<front>
<title>Request For Comments reference guide</title>
<author fullname="Joyce K. Reynolds" initials="J." surname="Reynolds">
<organization>University of Southern California (USC)/ Information Sciences Institute</organization>

<address>
<postal>
<street>4676 Admiralty Way</street>
<city>Marina del Rey</city>
<region>CA</region>
<code>90291</code>
<country>US</country>
</postal>

<phone>+1 213 822 1511</phone>
</address>
</author>

<author fullname="J. Postel" initials="J." surname="Postel">
<organization>University of Southern California (USC)/ Information Sciences Institute</organization>

<address>
<postal>
<street>4676 Admiralty Way</street>
<city>Marina del Rey</city>
<region>CA</region>
<code>90291</code>
<country>US</country>
</postal>

<phone>+1 213 822 1511</phone>
</address>
</author>

<date year="1987" day="1" month="August" />
</front>

<seriesInfo value="1000" name="RFC" />
</reference>


<reference target2="reference.RFC.1001.xml" anchor="RFC1001">
<front>
<title>Protocol standard for a NetBIOS service on a TCP/UDP transport: Concepts and methods</title>
<author>
<organization>NetBIOS Working Group</organization>
</author>

<date year="1987" day="1" month="March" />

<abstract>
<t>This RFC defines a proposed standard protocol to support NetBIOS services in a TCP/IP environment.  Both local network and internet operation are supported.  Various node types are defined to accommodate local and internet topologies and to allow operation with or without the use of IP broadcast.</t>

<t>This RFC describes the NetBIOS-over-TCP protocols in a general manner, emphasizing the underlying ideas and techniques.  Detailed specifications are found in a companion RFC, "Protocol Standard For a NetBIOS Service on a TCP/UDP Transport: Detailed Specifications".</t>
</abstract>
</front>

<seriesInfo value="19" name="STD" />
<seriesInfo value="1001" name="RFC" />
</reference>


<reference target2="reference.RFC.1002.xml" anchor="RFC1002">
<front>
<title>Protocol standard for a NetBIOS service on a TCP/UDP transport: Detailed specifications</title>
<author>
<organization>NetBIOS Working Group</organization>
</author>

<date year="1987" day="1" month="March" />

<abstract>
<t>This RFC defines a proposed standard protocol to support NetBIOS services in a TCP/IP environment.  Both local network and internet operation are supported.  Various node types are defined to accommodate local and internet topologies and to allow operation with or without the use of IP broadcast.</t>

<t>This RFC gives the detailed specifications of the NetBIOS-over-TCP packets, protocols, and defined constants and variables.  A more general overview is found in a companion RFC, "Protocol Standard For a NetBIOS Service on a TCP/UDP Transport: Concepts and Methods".</t>
</abstract>
</front>

<seriesInfo value="19" name="STD" />
<seriesInfo value="1002" name="RFC" />
</reference>


<reference target2="reference.RFC.1003.xml" anchor="RFC1003">
<front>
<title>Issues in defining an equations representation standard</title>
<author fullname="Alan Katz" initials="A." surname="Katz">
<organization>University of Southern California (USC)/ISI</organization>

<address>
<postal>
<street>4676 Admiralty Way</street>
<city>Marina del Rey</city>
<region>CA</region>
<code>90291</code>
<country>US</country>
</postal>

<phone>+1 213 822 1511</phone>
</address>
</author>

<date year="1987" day="1" month="March" />
</front>

<seriesInfo value="1003" name="RFC" />
</reference>


<reference target2="reference.RFC.1004.xml" anchor="RFC1004">
<front>
<title>Distributed-protocol authentication scheme</title>
<author fullname="D. L. Mills" initials="D." surname="Mills">
<organization>University of Delaware</organization>
</author>

<date year="1987" day="1" month="April" />
</front>

<seriesInfo value="1004" name="RFC" />
</reference>


<reference target2="reference.RFC.1005.xml" anchor="RFC1005">
<front>
<title>ARPANET AHIP-E Host Access Protocol (enhanced AHIP)</title>
<author fullname="Atul Khanna" initials="A." surname="Khanna">
<organization>BBN Communications Corp.</organization>
</author>

<author fullname="Andy Malis" initials="A." surname="Malis">
<organization>BBN Communications Corp.</organization>
</author>

<date year="1987" day="1" month="May" />
</front>

<seriesInfo value="1005" name="RFC" />
</reference>


<reference target2="reference.RFC.1006.xml" anchor="RFC1006">
<front>
<title>ISO transport services on top of the TCP: Version 3</title>
<author fullname="Marshall T. Rose" initials="M." surname="Rose">
<organization>Northrop Research and Technology Center</organization>
</author>

<author fullname="Dwight E. Cass" initials="D." surname="Cass">
<organization>Northrop Research and Technology Center</organization>
</author>

<date year="1987" day="1" month="May" />
</front>

<seriesInfo value="35" name="STD" />
<seriesInfo value="1006" name="RFC" />
</reference>


<reference target2="reference.RFC.1007.xml" anchor="RFC1007">
<front>
<title>Military supplement to the ISO Transport Protocol</title>
<author fullname="Wayne McCoy" initials="W." surname="McCoy">
<organization />
</author>

<date year="1987" day="1" month="June" />
</front>

<seriesInfo value="1007" name="RFC" />
</reference>


<reference target2="reference.RFC.1008.xml" anchor="RFC1008">
<front>
<title>Implementation guide for the ISO Transport Protocol</title>
<author fullname="Wayne McCoy" initials="W." surname="McCoy">
<organization />
</author>

<date year="1987" day="1" month="June" />
</front>

<seriesInfo value="1008" name="RFC" />
</reference>


<reference target2="reference.RFC.1009.xml" anchor="RFC1009">
<front>
<title>Requirements for Internet gateways</title>
<author fullname="R. Braden" initials="R." surname="Braden">
<organization>University of Southern California (USC)/ Information Sciences Institute</organization>

<address>
<postal>
<street>4676 Admiralty Way</street>
<city>Marina del Rey</city>
<region>CA</region>
<code>90291</code>
<country>US</country>
</postal>

<phone>+1 213 822 1511</phone>
</address>
</author>

<author fullname="J. Postel" initials="J." surname="Postel">
<organization>University of Southern California (USC)/ Information Sciences Institute</organization>

<address>
<postal>
<street>4676 Admiralty Way</street>
<city>Marina del Rey</city>
<region>CA</region>
<code>90291</code>
<country>US</country>
</postal>

<phone>+1 213 822 1511</phone>
</address>
</author>

<date year="1987" day="1" month="June" />
</front>

<seriesInfo value="1009" name="RFC" />
</reference>


<reference target2="reference.RFC.1010.xml" anchor="RFC1010">
<front>
<title>Assigned numbers</title>
<author fullname="Joyce K. Reynolds" initials="J." surname="Reynolds">
<organization>University of Southern California (USC)/ Information Sciences Institute</organization>

<address>
<postal>
<street>4676 Admiralty Way</street>
<city>Marina del Rey</city>
<region>CA</region>
<code>90292-6695</code>
<country>US</country>
</postal>

<phone>+1 213 822 1511</phone>
<email>JKREYNOLDS@ISI.EDU</email>
</address>
</author>

<author fullname="J. Postel" initials="J." surname="Postel">
<organization>University of Southern California (USC)/ Information Sciences Institute</organization>

<address>
<postal>
<street>4676 Admiralty Way</street>
<city>Marina del Rey</city>
<region>CA</region>
<code>90291</code>
<country>US</country>
</postal>

<phone>+1 213 822 1511</phone>
</address>
</author>

<date year="1987" day="1" month="May" />
</front>

<seriesInfo value="1010" name="RFC" />
</reference>


<reference target2="reference.RFC.1011.xml" anchor="RFC1011">
<front>
<title>Official Internet protocols</title>
<author fullname="Joyce K. Reynolds" initials="J." surname="Reynolds">
<organization>USC - Information Sciences Institute</organization>

<address>
<postal>
<street>4676 Admiralty Way</street>
<city>Marina del Rey</city>
<region>CA</region>
<code>90292-6695</code>
<country>US</country>
</postal>

<phone>+1 213 822 1511</phone>
<email>JKREYNOLDS@ISI.EDU</email>
</address>
</author>

<author fullname="J. Postel" initials="J." surname="Postel">
<organization />
</author>

<date year="1987" day="1" month="May" />
</front>

<seriesInfo value="1011" name="RFC" />
</reference>


<reference target2="reference.RFC.1012.xml" anchor="RFC1012">
<front>
<title abbrev="Bibliography of RFCs 1 - 999">Bibliography of Request For Comments 1 through 999</title>
<author fullname="J. Reynolds" initials="J." surname="Reynolds">
<organization>USC/Information Sciences Institute</organization>

<address>
<postal>
<street>4676 Admiralty Way</street>
<city>Marina del Rey</city>
<region>CA</region>
<code>90291</code>
<country>US</country>
</postal>

<phone>+1 213 822 1511</phone>
</address>
</author>

<author fullname="J. Postel" initials="J." surname="Postel">
<organization>USC/Information Sciences Institute</organization>

<address>
<postal>
<street>4676 Admiralty Way</street>
<city>Marina del Rey</city>
<region>CA</region>
<code>90291</code>
<country>US</country>
</postal>

<phone>+1 213 822 1511</phone>
</address>
</author>

<date year="1987" day="1" month="June" />
</front>

<seriesInfo value="1012" name="RFC" />
</reference>


<reference target2="reference.RFC.1013.xml" anchor="RFC1013">
<front>
<title>X Window System Protocol, version 11: Alpha update April 1987</title>
<author fullname="Robert W. Scheifler" initials="R." surname="Scheifler">
<organization>Laboratory for Computer Science</organization>

<address>
<postal>
<street>545 Technology Square</street>
<street>Room 418</street>
<city>Cambridge</city>
<region>MA</region>
<code>02139</code>
<country>US</country>
</postal>

</address>
</author>

<date year="1987" day="1" month="June" />
</front>

<seriesInfo value="1013" name="RFC" />
</reference>


<reference target2="reference.RFC.1014.xml" anchor="RFC1014">
<front>
<title abbrev="External Data Representation">XDR: External Data Representation standard</title>
<author>
<organization>Sun Microsystems, Inc.</organization>
</author>

<date year="1987" day="1" month="June" />
</front>

<seriesInfo value="1014" name="RFC" />
</reference>


<reference target2="reference.RFC.1015.xml" anchor="RFC1015">
<front>
<title abbrev="IRI Plan">Implementation plan for interagency research Internet</title>
<author fullname="Barry M. Leiner" initials="B." surname="Leiner">
<organization>RIACS</organization>
</author>

<date year="1987" day="1" month="July" />
</front>

<seriesInfo value="1015" name="RFC" />
</reference>


<reference target2="reference.RFC.1016.xml" anchor="RFC1016">
<front>
<title abbrev="Source Quench Introduced Delay -- SQuID">Something a host could do with source quench: The Source Quench Introduced Delay (SQuID)</title>
<author fullname="W. Prue" initials="W." surname="Prue">
<organization>USC/Information Sciences Institute</organization>

<address>
<postal>
<street>4676 Admiralty Way</street>
<city>Marina del Rey</city>
<region>CA</region>
<code>90291</code>
<country>US</country>
</postal>

<phone>+1 213 822 1511</phone>
</address>
</author>

<author fullname="J. Postel" initials="J." surname="Postel">
<organization>USC/Information Sciences Institute</organization>

<address>
<postal>
<street>4676 Admiralty Way</street>
<city>Marina del Rey</city>
<region>CA</region>
<code>90291</code>
<country>US</country>
</postal>

<phone>+1 213 822 1511</phone>
</address>
</author>

<date year="1987" day="1" month="July" />
</front>

<seriesInfo value="1016" name="RFC" />
</reference>


<reference target2="reference.RFC.1017.xml" anchor="RFC1017">
<front>
<title abbrev="Requirements for Scientific Research">Network requirements for scientific research: Internet task force on scientific computing</title>
<author fullname="Barry M. Leiner" initials="B." surname="Leiner">
<organization>RIACS</organization>
</author>

<date year="1987" day="1" month="August" />
</front>

<seriesInfo value="1017" name="RFC" />
</reference>


<reference target2="reference.RFC.1018.xml" anchor="RFC1018">
<front>
<title>Some comments on SQuID</title>
<author fullname="A. McKenzie" initials="A." surname="McKenzie">
<organization>Bolt Baranek and Newman (BBN) Labs</organization>
</author>

<date year="1987" day="1" month="August" />
</front>

<seriesInfo value="1018" name="RFC" />
</reference>


<reference target2="reference.RFC.1019.xml" anchor="RFC1019">
<front>
<title>Report of the Workshop on Environments for Computational Mathematics</title>
<author fullname="D. Arnon" initials="D." surname="Arnon">
<organization>Xerox PARC</organization>
</author>

<date year="1987" day="1" month="September" />
</front>

<seriesInfo value="1019" name="RFC" />
</reference>


<reference target2="reference.RFC.1020.xml" anchor="RFC1020">
<front>
<title abbrev="Internet Numbers">Internet numbers</title>
<author fullname="S. Romano" initials="S." surname="Romano">
<organization>SRI International</organization>
</author>

<author fullname="M. Stahl" initials="M." surname="Stahl">
<organization>SRI International</organization>
</author>

<date year="1987" day="1" month="November" />
</front>

<seriesInfo value="1020" name="RFC" />
</reference>


<reference target2="reference.RFC.1021.xml" anchor="RFC1021">
<front>
<title abbrev="HEMS Overview">High-level Entity Management System (HEMS)</title>
<author fullname="C. Partridge" initials="C." surname="Partridge">
<organization>BBN/NNSC</organization>
</author>

<author fullname="G. Trewitt" initials="G." surname="Trewitt">
<organization>Stanford University</organization>
</author>

<date year="1987" day="1" month="October" />
</front>

<seriesInfo value="1021" name="RFC" />
</reference>


<reference target2="reference.RFC.1022.xml" anchor="RFC1022">
<front>
<title abbrev="HEMS Protocol">High-level Entity Management Protocol (HEMP)</title>
<author fullname="C. Partridge" initials="C." surname="Partridge">
<organization>Bolt Baranek and Newman (BBN)/NNSC</organization>
</author>

<author fullname="G. Trewitt" initials="G." surname="Trewitt">
<organization>Stanford University</organization>
</author>

<date year="1987" day="1" month="October" />
</front>

<seriesInfo value="1022" name="RFC" />
</reference>


<reference target2="reference.RFC.1023.xml" anchor="RFC1023">
<front>
<title abbrev="HEMS Language">HEMS monitoring and control language</title>
<author fullname="G. Trewitt" initials="G." surname="Trewitt">
<organization>Stanford University</organization>
</author>

<author fullname="C. Partridge" initials="C." surname="Partridge">
<organization>BBN/NNSC</organization>
</author>

<date year="1987" day="1" month="October" />
</front>

<seriesInfo value="1023" name="RFC" />
</reference>


<reference target2="reference.RFC.1024.xml" anchor="RFC1024">
<front>
<title abbrev="HEMS Definitions">HEMS variable definitions</title>
<author fullname="C. Partridge" initials="C." surname="Partridge">
<organization>Bolt Baranek and Newman (BBN)/NNSC</organization>
</author>

<author fullname="G. Trewitt" initials="G." surname="Trewitt">
<organization>Stanford University</organization>
</author>

<date year="1987" day="1" month="October" />
</front>

<seriesInfo value="1024" name="RFC" />
</reference>


<reference target2="reference.RFC.1025.xml" anchor="RFC1025">
<front>
<title>TCP and IP bake off</title>
<author fullname="J. Postel" initials="J." surname="Postel">
<organization>USC/Information Sciences Institute</organization>

<address>
<postal>
<street>4676 Admiralty Way</street>
<city>Marina del Rey</city>
<region>CA</region>
<code>90291</code>
<country>US</country>
</postal>

<phone>+1 213 822 1511</phone>
</address>
</author>

<date year="1987" day="1" month="September" />
</front>

<seriesInfo value="1025" name="RFC" />
</reference>


<reference target2="reference.RFC.1026.xml" anchor="RFC1026">
<front>
<title>Addendum to RFC 987: (Mapping between X.400 and RFC-822)</title>
<author fullname="S. E. Kille" initials="S." surname="Kille">
<organization>University College London</organization>
</author>

<date year="1987" day="1" month="September" />
</front>

<seriesInfo value="1026" name="RFC" />
</reference>


<reference target2="reference.RFC.1027.xml" anchor="RFC1027">
<front>
<title>Using ARP to implement transparent subnet gateways</title>
<author fullname="Smoot Carl-Mitchell" initials="S." surname="Carl-Mitchell">
<organization>Texas Internet Consulting</organization>
</author>

<author fullname="John S. Quarterman" initials="J." surname="Quarterman">
<organization>Texas Internet Consulting</organization>
</author>

<date year="1987" day="1" month="October" />
</front>

<seriesInfo value="1027" name="RFC" />
</reference>


<reference target2="reference.RFC.1028.xml" anchor="RFC1028">
<front>
<title abbrev="Simple Gateway Monitoring">Simple Gateway Monitoring Protocol</title>
<author fullname="J. Davin" initials="J." surname="Davin">
<organization>Proteon, Inc.</organization>
</author>

<author fullname="J. Case" initials="J." surname="Case">
<organization>University of Tennessee at Knoxville</organization>
</author>

<author fullname="M. Fedor" initials="M." surname="Fedor">
<organization>Cornell University</organization>
</author>

<author fullname="M. Schoffstall" initials="M." surname="Schoffstall">
<organization>Rensselaer Polytechnic Institute</organization>
</author>

<date year="1987" day="1" month="November" />
</front>

<seriesInfo value="1028" name="RFC" />
</reference>


<reference target2="reference.RFC.1029.xml" anchor="RFC1029">
<front>
<title abbrev="Fault Tolerant ARP for Multi-LANs">More fault tolerant approach to address resolution for a Multi-LAN system of Ethernets</title>
<author fullname="G. Parr" initials="G." surname="Parr">
<organization>University of Ulster</organization>
</author>

<date year="1988" day="1" month="May" />

<abstract>
<t>Executing a protocol P, a sending host S decides, through P's routing mechanism, that it wants to transmit to a target host T located somewhere on a connected piece of 10Mbit Ethernet cable which conforms to IEEE 802.3.  To actually transmit the Ethernet packet, a 48 bit Ethernet/hardware address must be generated.  The addresses assigned to hosts within protocol P are not always compatible with the corresponding Ethernet address (being different address space byte orderings or values).  A protocol is presented which allows dynamic distribution of the information required to build tables that translate a host's address in protocol P's address space into a 48 bit Ethernet address.  An extension is incorporated to allow such a protocol to be flexible enough to exist in a Transparent Bridge, or generic Host.  The capability of the Bridge to detect host reboot conditions in a multi-LAN environment is also discussed, emphasising particularly the effect on channel bandwidth.  To illustrate the operation of the protocol mechanisms, the Internet Protocol (IP) is used as a benchmark [6], [8].  Part 1 presents an introduction to Address Resolution, whilst Part 2 discusses a reboot detection process.</t>
</abstract>
</front>

<seriesInfo value="1029" name="RFC" />
</reference>


<reference target2="reference.RFC.1030.xml" anchor="RFC1030">
<front>
<title abbrev="Testing the NETBLT Protocol">On testing the NETBLT Protocol over divers networks</title>
<author fullname="M. Lambert" initials="M." surname="Lambert">
<organization>Massechusetts Institute of Technology (MIT), Laboratory for Computer Science</organization>
</author>

<date year="1987" day="1" month="November" />
</front>

<seriesInfo value="1030" name="RFC" />
</reference>


<reference target2="reference.RFC.1031.xml" anchor="RFC1031">
<front>
<title abbrev="MILNET DOMAIN TRANSITION">MILNET name domain transition</title>
<author fullname="W. Lazear" initials="W." surname="Lazear">
<organization>MITRE</organization>
</author>

<date year="1987" day="1" month="November" />
</front>

<seriesInfo value="1031" name="RFC" />
</reference>


<reference target2="reference.RFC.1032.xml" anchor="RFC1032">
<front>
<title>Domain administrators guide</title>
<author fullname="M. Stahl" initials="M." surname="Stahl">
<organization>SRI International</organization>
</author>

<date year="1987" day="1" month="November" />
</front>

<seriesInfo value="1032" name="RFC" />
</reference>


<reference target2="reference.RFC.1033.xml" anchor="RFC1033">
<front>
<title abbrev="DOMAIN OPERATIONS GUIDE">Domain administrators operations guide</title>
<author fullname="M. Lottor" initials="M." surname="Lottor">
<organization>SRI International</organization>
</author>

<date year="1987" day="1" month="November" />
</front>

<seriesInfo value="1033" name="RFC" />
</reference>


<reference target2="reference.RFC.1034.xml" anchor="RFC1034">
<front>
<title abbrev="Domain Concepts and Facilities">Domain names - concepts and facilities</title>
<author fullname="P. Mockapetris" initials="P." surname="Mockapetris">
<organization>Information Sciences Institute (ISI)</organization>
</author>

<date year="1987" day="1" month="November" />
</front>

<seriesInfo value="13" name="STD" />
<seriesInfo value="1034" name="RFC" />
</reference>


<reference target2="reference.RFC.1035.xml" anchor="RFC1035">
<front>
<title abbrev="Domain Implementation and Specification">Domain names - implementation and specification</title>
<author fullname="P. Mockapetris" initials="P." surname="Mockapetris">
<organization>USC/ISI</organization>

<address>
<postal>
<street>4676 Admiralty Way</street>
<city>Marina del Rey</city>
<region>CA</region>
<code>90291</code>
<country>US</country>
</postal>

<phone>+1 213 822 1511</phone>
</address>
</author>

<date year="1987" day="1" month="November" />
</front>

<seriesInfo value="13" name="STD" />
<seriesInfo value="1035" name="RFC" />
</reference>


<reference target2="reference.RFC.1036.xml" anchor="RFC1036">
<front>
<title abbrev="Standard for USENET Messages">Standard for interchange of USENET messages</title>
<author fullname="M. Horton" initials="M." surname="Horton">
<organization>AT&amp;T Bell Laboratories</organization>
</author>

<author fullname="R. Adams" initials="R." surname="Adams">
<organization>Center for Seismic Studies</organization>
</author>

<date year="1987" day="1" month="December" />
</front>

<seriesInfo value="1036" name="RFC" />
</reference>


<reference target2="reference.RFC.1037.xml" anchor="RFC1037">
<front>
<title>NFILE - a file access protocol</title>
<author fullname="B. Greenberg" initials="B." surname="Greenberg">
<organization />
</author>

<author fullname="S. Keene" initials="S." surname="Keene">
<organization />
</author>

<date year="1987" day="1" month="December" />
</front>

<seriesInfo value="1037" name="RFC" />
</reference>


<reference target2="reference.RFC.1038.xml" anchor="RFC1038">
<front>
<title>Draft revised IP security option</title>
<author fullname="M. St. Johns" initials="M." surname="St. Johns">
<organization>Internet Engineering Task Force (IETF)</organization>
</author>

<date year="1988" day="1" month="January" />
</front>

<seriesInfo value="1038" name="RFC" />
</reference>


<reference target2="reference.RFC.1039.xml" anchor="RFC1039">
<front>
<title abbrev="A DoD Statement on OSIP">DoD statement on Open Systems Interconnection protocols</title>
<author fullname="D. Latham" initials="D." surname="Latham">
<organization>Department of Defense (DoD)</organization>
</author>

<date year="1988" day="1" month="January" />
</front>

<seriesInfo value="1039" name="RFC" />
</reference>


<reference target2="reference.RFC.1040.xml" anchor="RFC1040">
<front>
<title abbrev="Privacy Enhancement for Electronic Mail">Privacy enhancement for Internet electronic mail: Part I: Message encipherment and authentication procedures</title>
<author fullname="J. Linn" initials="J." surname="Linn">
<organization>Bolt Baranek and Newman Communications (BBNCC)</organization>
</author>

<author>
<organization>IAB Privacy Task Force</organization>
</author>

<date year="1988" day="1" month="January" />
</front>

<seriesInfo value="1040" name="RFC" />
</reference>


<reference target2="reference.RFC.1041.xml" anchor="RFC1041">
<front>
<title>Telnet 3270 regime option</title>
<author fullname="J. Rekhter" initials="J." surname="Rekhter">
<organization>International Business Machines (IBM), T. J. Watson Research Center</organization>
</author>

<date year="1988" day="1" month="January" />
</front>

<seriesInfo value="1041" name="RFC" />
</reference>


<reference target2="reference.RFC.1042.xml" anchor="RFC1042">
<front>
<title abbrev="IP and ARP on IEEE 802 Networks">Standard for the transmission of IP datagrams over IEEE 802 networks</title>
<author fullname="J. Postel" initials="J." surname="Postel">
<organization>USC/Information Sciences Institute</organization>

<address>
<postal>
<street>4676 Admiralty Way</street>
<city>Marina del Rey</city>
<region>CA</region>
<code>90291</code>
<country>US</country>
</postal>

<phone>+1 213 822 1511</phone>
</address>
</author>

<author fullname="J. Reynolds" initials="J." surname="Reynolds">
<organization>USC/Information Sciences Institute</organization>

<address>
<postal>
<street>4676 Admiralty Way</street>
<city>Marina del Rey</city>
<region>CA</region>
<code>90291</code>
<country>US</country>
</postal>

<phone>+1 213 822 1511</phone>
</address>
</author>

<date year="1988" day="1" month="February" />
</front>

<seriesInfo value="43" name="STD" />
<seriesInfo value="1042" name="RFC" />
</reference>


<reference target2="reference.RFC.1043.xml" anchor="RFC1043">
<front>
<title abbrev="Data Entry Terminal - DODIIS">Telnet Data Entry Terminal option: DODIIS implementation</title>
<author fullname="A. Yasuda" initials="A." surname="Yasuda">
<organization>Defense Intelligence Agency</organization>
</author>

<author fullname="T. Thompson" initials="T." surname="Thompson">
<organization>Defense Intelligence Agency</organization>
</author>

<date year="1988" day="1" month="February" />
</front>

<seriesInfo value="1043" name="RFC" />
</reference>


<reference target2="reference.RFC.1044.xml" anchor="RFC1044">
<front>
<title abbrev="IP on Network Systems HYPERchannel">Internet Protocol on Network System's HYPERchannel: Protocol specification</title>
<author fullname="Ken Hardwick" initials="K." surname="Hardwick">
<organization>Network Systems Corporation</organization>

<address>
<postal>
<street>7600 Boone Avenue North</street>
<street>MS029</street>
<city>Minneapolis</city>
<region>MN</region>
<code>55428</code>
<country>US</country>
</postal>

<phone>+1 612 424 1607</phone>
</address>
</author>

<author fullname="John Lekashman" initials="J." surname="Lekashman">
<organization>Nasa Ames Research Center. NASA/GE</organization>

<address>
<postal>
<street>MS 258-6</street>
<city>Moffett Field</city>
<region>CA</region>
<code>94035</code>
<country>US</country>
</postal>

<phone>+1 415 694 4359</phone>
<email>lekash@orville.nas.nasa.gov</email>
</address>
</author>

<date year="1988" day="1" month="February" />
</front>

<seriesInfo value="45" name="STD" />
<seriesInfo value="1044" name="RFC" />
</reference>


<reference target2="reference.RFC.1045.xml" anchor="RFC1045">
<front>
<title abbrev="VMTP">VMTP: Versatile Message Transaction Protocol: Protocol specification</title>
<author fullname="David Cheriton" initials="D." surname="Cheriton">
<organization>Stanford University</organization>
</author>

<date year="1988" day="1" month="February" />
</front>

<seriesInfo value="1045" name="RFC" />
</reference>


<reference target2="reference.RFC.1046.xml" anchor="RFC1046">
<front>
<title abbrev="Type-of-Service Queuing">Queuing algorithm to provide type-of-service for IP links</title>
<author fullname="W. Prue" initials="W." surname="Prue">
<organization />
</author>

<author fullname="J. Postel" initials="J." surname="Postel">
<organization>Information Sciences Institute (ISI)</organization>
</author>

<date year="1988" day="1" month="February" />
</front>

<seriesInfo value="1046" name="RFC" />
</reference>


<reference target2="reference.RFC.1047.xml" anchor="RFC1047">
<front>
<title>Duplicate messages and SMTP</title>
<author fullname="Craig Partridge" initials="C." surname="Partridge">
<organization>Bolt Baraneck and Newman (BBN)</organization>
</author>

<date year="1988" day="1" month="February" />
</front>

<seriesInfo value="1047" name="RFC" />
</reference>


<reference target2="reference.RFC.1048.xml" anchor="RFC1048">
<front>
<title abbrev="BOOTP Extensions">BOOTP vendor information extensions</title>
<author fullname="P. Prindeville" initials="P." surname="Prindeville">
<organization>McGill University</organization>
</author>

<date year="1988" day="1" month="February" />
</front>

<seriesInfo value="1048" name="RFC" />
</reference>


<reference target2="reference.RFC.1049.xml" anchor="RFC1049">
<front>
<title abbrev="Mail Content Type">Content-type header field for Internet messages</title>
<author fullname="M. Sirbu" initials="M." surname="Sirbu">
<organization>Carnegie-Mellon University</organization>
</author>

<date year="1988" day="1" month="March" />

<abstract>
<t>A standardized Content-type field allows mail reading systems to automatically identify the type of a structured message body and to process it for display accordingly.  The structured message body must still conform to the RFC-822 requirements concerning allowable characters.  A mail reading system need not take any specific action upon receiving a message with a valid Content-Type header field.  The ability to recognize this field and invoke the appropriate display process accordingly will, however, improve the readability of messages, and allow the exchange of messages containing mathematical symbols, or foreign language characters.</t>
</abstract>
</front>

<seriesInfo value="1049" name="RFC" />
</reference>


<reference target2="reference.RFC.1050.xml" anchor="RFC1050">
<front>
<title abbrev="Remote Procedure Call">RPC: Remote Procedure Call Protocol specification</title>
<author>
<organization>Sun Microsystems</organization>
</author>

<date year="1988" day="1" month="April" />
</front>

<seriesInfo value="1050" name="RFC" />
</reference>


<reference target2="reference.RFC.1051.xml" anchor="RFC1051">
<front>
<title abbrev="IP and ARP on ARCNET">Standard for the transmission of IP datagrams and ARP packets over ARCNET networks</title>
<author fullname="P. Prindeville" initials="P." surname="Prindeville">
<organization>McGill University</organization>
</author>

<date year="1988" day="1" month="March" />
</front>

<seriesInfo value="1051" name="RFC" />
</reference>


<reference target2="reference.RFC.1052.xml" anchor="RFC1052">
<front>
<title abbrev="Internet Management">IAB recommendations for the development of Internet network management standards</title>
<author fullname="Vint Cerf" initials="V." surname="Cerf">
<organization>Corp. for National Research Initiatives (NRI)</organization>

<address>
<postal>
<street>1895 Preston White Dr.</street>
<street>Suite 100</street>
<city>Reston</city>
<region>VA</region>
<code>22091</code>
<country>US</country>
</postal>

<phone>+1 703 620 8990</phone>
<email>Cerf@ISI.EDU</email>
</address>
</author>

<date year="1988" day="1" month="April" />
</front>

<seriesInfo value="1052" name="RFC" />
</reference>


<reference target2="reference.RFC.1053.xml" anchor="RFC1053">
<front>
<title>Telnet X.3 PAD option</title>
<author fullname="S. Levy" initials="S." surname="Levy">
<organization>Minnesota Supercomputer Center</organization>
</author>

<author fullname="T. Jacobson" initials="T." surname="Jacobson">
<organization>Minnesota Supercomputer Center</organization>
</author>

<date year="1988" day="1" month="April" />
</front>

<seriesInfo value="1053" name="RFC" />
</reference>


<reference target2="reference.RFC.1054.xml" anchor="RFC1054">
<front>
<title>Host extensions for IP multicasting</title>
<author fullname="S. Deering" initials="S." surname="Deering">
<organization>Stanford University</organization>
</author>

<date year="1988" day="1" month="May" />
</front>

<seriesInfo value="1054" name="RFC" />
</reference>


<reference target2="reference.RFC.1055.xml" anchor="RFC1055">
<front>
<title abbrev="Serial Line IP">Nonstandard for transmission of IP datagrams over serial lines: SLIP</title>
<author fullname="J. Romkey" initials="J." surname="Romkey">
<organization />
</author>

<date year="1988" day="1" month="June" />
</front>

<seriesInfo value="47" name="STD" />
<seriesInfo value="1055" name="RFC" />
</reference>


<reference target2="reference.RFC.1056.xml" anchor="RFC1056">
<front>
<title abbrev="PCMAIL">PCMAIL: A distributed mail system for personal computers</title>
<author fullname="M. Lambert" initials="M." surname="Lambert">
<organization>Massachusetts Institute of Technology (MIT)</organization>
</author>

<date year="1988" day="1" month="June" />
</front>

<seriesInfo value="1056" name="RFC" />
</reference>


<reference target2="reference.RFC.1057.xml" anchor="RFC1057">
<front>
<title abbrev="Remote Procedure Call, Version 2">RPC: Remote Procedure Call Protocol specification: Version 2</title>
<author>
<organization>Sun Microsystems, Inc.</organization>
</author>

<date year="1988" day="1" month="June" />
</front>

<seriesInfo value="1057" name="RFC" />
</reference>


<reference target2="reference.RFC.1058.xml" anchor="RFC1058">
<front>
<title>Routing Information Protocol</title>
<author fullname="C. Hedrick" initials="C." surname="Hedrick">
<organization>Rutgers University</organization>
</author>

<date year="1988" day="1" month="June" />
</front>

<seriesInfo value="1058" name="RFC" />
</reference>


<reference target2="reference.RFC.1059.xml" anchor="RFC1059">
<front>
<title abbrev="Network Time Protocol">Network Time Protocol (version 1) specification and implementation</title>
<author fullname="D. Mills" initials="D." surname="Mills">
<organization>University of Delaware</organization>
</author>

<date year="1988" day="1" month="July" />
</front>

<seriesInfo value="1059" name="RFC" />
</reference>


<reference target2="reference.RFC.1060.xml" anchor="RFC1060">
<front>
<title abbrev="Assigned Numbers">Assigned numbers</title>
<author fullname="Joyce K. Reynolds" initials="J." surname="Reynolds">
<organization>University of Southern California (USC), Information Sciences Institute</organization>

<address>
<postal>
<street>4676 Admiralty Way</street>
<city>Marina del Rey</city>
<region>CA</region>
<code>90292</code>
<country>US</country>
</postal>

<phone>+1 213 822 1511</phone>
<email>JKREY@ISI.EDU</email>
</address>
</author>

<author fullname="Jon Postel" initials="J." surname="Postel">
<organization>University of Southern California (USC), Information Sciences Institute</organization>

<address>
<postal>
<street>4676 Admiralty Way</street>
<city>Marina del Rey</city>
<region>CA</region>
<code>90292</code>
<country>US</country>
</postal>

<phone>+1 213 822 1511</phone>
<email>POSTEL@ISI.EDU</email>
</address>
</author>

<date year="1990" day="1" month="March" />
</front>

<seriesInfo value="1060" name="RFC" />
</reference>


<reference target2="reference.RFC.1062.xml" anchor="RFC1062">
<front>
<title abbrev="Internet Numbers">Internet numbers</title>
<author fullname="S. Romano" initials="S." surname="Romano">
<organization />
</author>

<author fullname="M. Stahl" initials="M." surname="Stahl">
<organization />
</author>

<author fullname="M. Recker" initials="M." surname="Recker">
<organization />
</author>

<date year="1988" day="1" month="August" />
</front>

<seriesInfo value="1062" name="RFC" />
</reference>


<reference target2="reference.RFC.1063.xml" anchor="RFC1063">
<front>
<title>IP MTU discovery options</title>
<author fullname="J.  Mogul" initials="J." surname="Mogul">
<organization>Digital Equipment Corporation (DEC)</organization>
</author>

<author fullname="C. Kent" initials="C." surname="Kent">
<organization>Digital Equipment Corporation (DEC)</organization>
</author>

<author fullname="C. Partridge" initials="C." surname="Partridge">
<organization>Bolt Baranek and Newman (BBN)</organization>
</author>

<author fullname="K. McCloghrie" initials="K." surname="McCloghrie">
<organization>The Wollongong Group (TWG)</organization>
</author>

<date year="1988" day="1" month="July" />
</front>

<seriesInfo value="1063" name="RFC" />
</reference>


<reference target2="reference.RFC.1064.xml" anchor="RFC1064">
<front>
<title abbrev="IMAP2">Interactive Mail Access Protocol: Version 2</title>
<author fullname="M. Crispin" initials="M." surname="Crispin">
<organization>SUMEX-AIM</organization>
</author>

<date year="1988" day="1" month="July" />
</front>

<seriesInfo value="1064" name="RFC" />
</reference>


<reference target2="reference.RFC.1065.xml" anchor="RFC1065">
<front>
<title abbrev="SMI">Structure and identification of management information for TCP/IP-based internets</title>
<author fullname="M. Rose" initials="M." surname="Rose">
<organization>The Wollongong Group</organization>
</author>

<author fullname="K. McCloghrie" initials="K." surname="McCloghrie">
<organization>The Wollongong Group</organization>
</author>

<date year="1988" day="1" month="August" />
</front>

<seriesInfo value="1065" name="RFC" />
</reference>


<reference target2="reference.RFC.1066.xml" anchor="RFC1066">
<front>
<title abbrev="MIB">Management Information Base for network management of TCP/IP-based internets</title>
<author fullname="K. McCloghrie" initials="K." surname="McCloghrie">
<organization>The Wollongong Group</organization>
</author>

<author fullname="M. Rose" initials="M." surname="Rose">
<organization>The Wollongong Group</organization>
</author>

<date year="1988" day="1" month="August" />
</front>

<seriesInfo value="1066" name="RFC" />
</reference>


<reference target2="reference.RFC.1067.xml" anchor="RFC1067">
<front>
<title abbrev="SNMP">Simple Network Management Protocol</title>
<author fullname="J. Case" initials="J." surname="Case">
<organization>University of Tennessee, Knoxville</organization>
</author>

<author fullname="M. Fedor" initials="M." surname="Fedor">
<organization>NYSERNet, Inc.</organization>
</author>

<author fullname="M. Schoffstall" initials="M." surname="Schoffstall">
<organization>Rensselaer Polytechnic Institute</organization>
</author>

<author fullname="J. Davin" initials="J." surname="Davin">
<organization>Proteon, Inc.</organization>
</author>

<date year="1988" day="1" month="August" />
</front>

<seriesInfo value="1067" name="RFC" />
</reference>


<reference target2="reference.RFC.1068.xml" anchor="RFC1068">
<front>
<title>Background File Transfer Program (BFTP)</title>
<author fullname="A. DeSchon" initials="A." surname="DeSchon">
<organization>USC/Information Sciences Institute</organization>

<address>
<postal>
<street>4676 Admiralty Way</street>
<city>Marina del Rey</city>
<region>CA</region>
<code>90291</code>
<country>US</country>
</postal>

<phone>+1 213 822 1511</phone>
</address>
</author>

<author fullname="R. Braden" initials="R." surname="Braden">
<organization>USC/Information Sciences Institute</organization>

<address>
<postal>
<street>4676 Admiralty Way</street>
<city>Marina del Rey</city>
<region>CA</region>
<code>90291</code>
<country>US</country>
</postal>

<phone>+1 213 822 1511</phone>
</address>
</author>

<date year="1988" day="1" month="August" />
</front>

<seriesInfo value="1068" name="RFC" />
</reference>


<reference target2="reference.RFC.1069.xml" anchor="RFC1069">
<front>
<title abbrev="IP ISO Addressing">Guidelines for the use of Internet-IP addresses in the ISO Connectionless-Mode Network Protocol</title>
<author fullname="R. Callon" initials="R." surname="Callon">
<organization>Digital Equipment Corporation (DEC)</organization>
</author>

<author fullname="H.W. Braun" initials="H." surname="Braun">
<organization>University of Michigan</organization>
</author>

<date year="1989" day="1" month="February" />
</front>

<seriesInfo value="1069" name="RFC" />
</reference>


<reference target2="reference.RFC.1070.xml" anchor="RFC1070">
<front>
<title abbrev="Experimental OSI Net">Use of the Internet as a subnetwork for experimentation with the OSI network layer</title>
<author fullname="Robert A. Hagens" initials="R." surname="Hagens">
<organization>University of Wisconsin, Madison, Computer Sciences Department</organization>

<address>
<postal>
<street>1210 West Dayton Street</street>
<city>Madison</city>
<region>WI</region>
<code>53706</code>
<country>US</country>
</postal>

<phone>+1 608 262 1017</phone>
<email>hagens@cs.wisc.edu</email>
</address>
</author>

<author fullname="Nancy E. Hall" initials="N." surname="Hall">
<organization>University of Wisconsin, Madison, Computer Sciences Department</organization>

<address>
<postal>
<street>1210 West Dayton Street</street>
<city>Madison</city>
<region>WI</region>
<code>53706</code>
<country>US</country>
</postal>

<phone>+1 608 262 5945</phone>
<email>nhall@cs.wisc.edu</email>
</address>
</author>

<author fullname="Marshall T. Rose" initials="M." surname="Rose">
<organization>The Wollongong Group</organization>

<address>
<postal>
<street>1129 San Antonio Road</street>
<city>Palo Alto</city>
<region>CA</region>
<code>94303</code>
<country>US</country>
</postal>

<phone>+1 415 962 7100</phone>
<email>mrose@twg.com</email>
</address>
</author>

<date year="1989" day="1" month="February" />
</front>

<seriesInfo value="1070" name="RFC" />
</reference>


<reference target2="reference.RFC.1071.xml" anchor="RFC1071">
<front>
<title>Computing the Internet checksum</title>
<author fullname="R.  Braden" initials="R." surname="Braden">
<organization>USC/Information Sciences Institute</organization>

<address>
<postal>
<street>4676 Admiralty Way</street>
<city>Marina del Rey</city>
<region>CA</region>
<code>90291</code>
<country>US</country>
</postal>

<phone>+1 213 822 1511</phone>
</address>
</author>

<author fullname="D.  Borman" initials="D." surname="Borman">
<organization>Cray Research</organization>
</author>

<author fullname="C. Partridge" initials="C." surname="Partridge">
<organization>Bolt Baranek and Newman (BBN) Laboratories</organization>
</author>

<author fullname="William W. Plummer" initials="W." surname="Plummer">
<organization>Bolt Beranek and Newman, Inc. (BBN)</organization>

<address>
<postal>
<street>50 Moulton Street</street>
<city>Cambridge</city>
<region>MA</region>
<code>02138</code>
<country>US</country>
</postal>

</address>
</author>

<date year="1988" day="1" month="September" />
</front>

<seriesInfo value="1071" name="RFC" />
</reference>


<reference target2="reference.RFC.1072.xml" anchor="RFC1072">
<front>
<title>TCP extensions for long-delay paths</title>
<author fullname="V. Jacobson" initials="V." surname="Jacobson">
<organization>Lawrence Berkeley Laboratory (LBL)</organization>
</author>

<author fullname="R. Braden" initials="R." surname="Braden">
<organization>USC/Information Sciences Institute</organization>

<address>
<postal>
<street>4676 Admiralty Way</street>
<city>Marina del Rey</city>
<region>CA</region>
<code>90291</code>
<country>US</country>
</postal>

<phone>+1 213 822 1511</phone>
</address>
</author>

<date year="1988" day="1" month="October" />
</front>

<seriesInfo value="1072" name="RFC" />
</reference>


<reference target2="reference.RFC.1073.xml" anchor="RFC1073">
<front>
<title>Telnet window size option</title>
<author fullname="D. Waitzman" initials="D." surname="Waitzman">
<organization>Bolt Baranek and Newman (BBN)/STC</organization>
</author>

<date year="1988" day="1" month="October" />
</front>

<seriesInfo value="1073" name="RFC" />
</reference>


<reference target2="reference.RFC.1074.xml" anchor="RFC1074">
<front>
<title abbrev="NSFNET Backbone SPF based IGP">NSFNET backbone SPF based Interior Gateway Protocol</title>
<author fullname="J. Rekhter" initials="J." surname="Rekhter">
<organization>IBM Corporation, T.J. Watson Research Center</organization>
</author>

<date year="1988" day="1" month="October" />
</front>

<seriesInfo value="1074" name="RFC" />
</reference>


<reference target2="reference.RFC.1075.xml" anchor="RFC1075">
<front>
<title>Distance Vector Multicast Routing Protocol</title>
<author fullname="D. Waitzman" initials="D." surname="Waitzman">
<organization>Bolt Baranek and Newman (BBN)/STC</organization>
</author>

<author fullname="C. Partridge" initials="C." surname="Partridge">
<organization>Bolt Baranek and Newman (BBN)/STC</organization>
</author>

<author fullname="S. Deering" initials="S." surname="Deering">
<organization>Stanford University</organization>
</author>

<date year="1988" day="1" month="November" />
</front>

<seriesInfo value="1075" name="RFC" />
</reference>


<reference target2="reference.RFC.1076.xml" anchor="RFC1076">
<front>
<title>HEMS monitoring and control language</title>
<author fullname="G. Trewitt" initials="G." surname="Trewitt">
<organization>Stanford University</organization>
</author>

<author fullname="C. Partridge" initials="C." surname="Partridge">
<organization>Bolt Baranek and Newman (BBN)/NNSC</organization>
</author>

<date year="1988" day="1" month="November" />
</front>

<seriesInfo value="1076" name="RFC" />
</reference>


<reference target2="reference.RFC.1077.xml" anchor="RFC1077">
<front>
<title>Critical issues in high bandwidth networking</title>
<author fullname="B. Leiner" initials="B." surname="Leiner">
<organization>Gigabit Working Group</organization>
</author>

<date year="1988" day="1" month="November" />

<abstract>
<t>At the request of Maj. Mark Pullen and Maj. Brian Boesch of DARPA, an ad-hoc working group was assembled to develop a set of recommendations on the research required to achieve a ubiquitous high-bandwidth network as discussed in the FCCSET recommendations for Phase III.</t>

<t>This report outlines a set of research topics aimed at providing the technology base for an interconnected set of networks that can provide highbandwidth capabilities.  The suggested research focus draws upon ongoing research and augments it with basic and applied components.  The major activities are the development and demonstration of a gigabit backbone network, the development and demonstration of an interconnected set of networks with gigabit throughput and appropriate management techniques, and the development and demonstration of the required overall architecture that allows users to gain access to such high bandwidth.</t>
</abstract>
</front>

<seriesInfo value="1077" name="RFC" />
</reference>


<reference target2="reference.RFC.1078.xml" anchor="RFC1078">
<front>
<title abbrev="TCPMUX">TCP port service Multiplexer (TCPMUX)</title>
<author fullname="M. Lottor" initials="M." surname="Lottor">
<organization>SRI-NIC</organization>
</author>

<date year="1988" day="1" month="November" />
</front>

<seriesInfo value="1078" name="RFC" />
</reference>


<reference target2="reference.RFC.1079.xml" anchor="RFC1079">
<front>
<title>Telnet terminal speed option</title>
<author fullname="Charles Hedrick" initials="C." surname="Hedrick">
<organization>Rutgers University, Center for Computer and Information Services,</organization>

<address>
<postal>
<street>Hill Center, Busch Campus</street>
<street>P.O. Box 879</street>
<city>Piscataway</city>
<region>NJ</region>
<code>08855-0879</code>
<country>US</country>
</postal>

<phone>+1 201 932 3088</phone>
<email>HEDRICK@ARAMIS.RUTGERS.EDU</email>
</address>
</author>

<date year="1988" day="1" month="December" />
</front>

<seriesInfo value="1079" name="RFC" />
</reference>


<reference target2="reference.RFC.1080.xml" anchor="RFC1080">
<front>
<title>Telnet remote flow control option</title>
<author fullname="Charles Hedrick" initials="C." surname="Hedrick">
<organization>Rutgers University, Center for Computer and Information Services</organization>

<address>
<postal>
<street>Hill Center, Busch Campus</street>
<street>P.O. Box 879</street>
<city>Piscataway</city>
<region>NJ</region>
<code>08855-0879</code>
<country>US</country>
</postal>

<phone>+1 201 932 3088</phone>
<email>HEDRICK@ARAMIS.RUTGERS.EDU</email>
</address>
</author>

<date year="1988" day="1" month="November" />
</front>

<seriesInfo value="1080" name="RFC" />
</reference>


<reference target2="reference.RFC.1081.xml" anchor="RFC1081">
<front>
<title abbrev="POP3">Post Office Protocol: Version 3</title>
<author fullname="Marshall Rose" initials="M." surname="Rose">
<organization>The Wollongong Group</organization>

<address>
<postal>
<street>1129 San Antonio Rd.</street>
<city>Palo Alto</city>
<region>CA</region>
<code>94303</code>
<country>US</country>
</postal>

<phone>+1 415 962 7100</phone>
<email>MRose@TWG.COM</email>
</address>
</author>

<date year="1988" day="1" month="November" />
</front>

<seriesInfo value="1081" name="RFC" />
</reference>


<reference target2="reference.RFC.1082.xml" anchor="RFC1082">
<front>
<title abbrev="POP3 Extended Service">Post Office Protocol: Version 3: Extended service offerings</title>
<author fullname="Marshall T. Rose" initials="M." surname="Rose">
<organization>The Wollongong Group</organization>

<address>
<postal>
<street>1129 San Antonio Rd.</street>
<city>Palo Alto</city>
<region>CA</region>
<code>94303</code>
<country>US</country>
</postal>

<phone>+1 415 962 7100</phone>
<email>MRose@TWG.COM</email>
</address>
</author>

<date year="1988" day="1" month="November" />
</front>

<seriesInfo value="1082" name="RFC" />
</reference>


<reference target2="reference.RFC.1083.xml" anchor="RFC1083">
<front>
<title abbrev="IAB Standards">IAB official protocol standards</title>
<author fullname="Jon Postel" initials="J." surname="Postel">
<organization>USC/Information Sciences Institute</organization>

<address>
<postal>
<street>4676 Admiralty Way</street>
<city>Marina del Rey</city>
<region>CA</region>
<code>90292</code>
<country>US</country>
</postal>

<phone>+1 213 822 1511</phone>
<email>Postel@ISI.EDU</email>
</address>
</author>

<date year="1988" day="1" month="December" />
</front>

<seriesInfo value="1083" name="RFC" />
</reference>


<reference target2="reference.RFC.1084.xml" anchor="RFC1084">
<front>
<title abbrev="BOOTP Extensions">BOOTP vendor information extensions</title>
<author fullname="Joyce K. Reynolds" initials="J." surname="Reynolds">
<organization>University of Southern California (USC)/Information Sciences Institute</organization>

<address>
<postal>
<street>4676 Admiralty Way</street>
<city>Marina del Rey</city>
<region>CA</region>
<code>90292</code>
<country>US</country>
</postal>

<phone>+1 213 822 1511</phone>
<email>JKREYNOLDS@ISI.EDU</email>
</address>
</author>

<date year="1988" day="1" month="December" />
</front>

<seriesInfo value="1084" name="RFC" />
</reference>


<reference target2="reference.RFC.1085.xml" anchor="RFC1085">
<front>
<title abbrev="ISO Presentation Services">ISO presentation services on top of TCP/IP based internets</title>
<author fullname="Marshall T. Rose" initials="M." surname="Rose">
<organization>The Wollongong Group</organization>

<address>
<postal>
<street>1129 San Antonio Road</street>
<city>Palo Alto</city>
<region>CA</region>
<code>94303</code>
<country>US</country>
</postal>

<phone>+1 415 962 7100</phone>
<email>mrose@TWG.COM</email>
</address>
</author>

<date year="1988" day="1" month="December" />
</front>

<seriesInfo value="1085" name="RFC" />
</reference>


<reference target2="reference.RFC.1086.xml" anchor="RFC1086">
<front>
<title>ISO-TP0 bridge between TCP and X.25</title>
<author fullname="Julian P. Onions" initials="J." surname="Onions">
<organization>Nottingham University, Computer Science Department</organization>

<address>
<postal>
<street>University Park</street>
<city>Nottingham</city>
<region>England</region>
<code>NG7 2RD</code>
<country>UK</country>
</postal>

<email>JPO@CS.NOTT.AC.UK</email>
</address>
</author>

<author fullname="Marshall T. Rose" initials="M." surname="Rose">
<organization>The Wollongong Group</organization>

<address>
<postal>
<street>1129 San Antonio Road</street>
<city>Palo Alto</city>
<region>CA</region>
<code>94303</code>
<country>US</country>
</postal>

<phone>+1 415 962 7100</phone>
<email>mrose@TWG.COM</email>
</address>
</author>

<date year="1988" day="1" month="December" />
</front>

<seriesInfo value="1086" name="RFC" />
</reference>


<reference target2="reference.RFC.1087.xml" anchor="RFC1087">
<front>
<title>Ethics and the Internet</title>
<author>
<organization>Internet Activities Board (IAB)</organization>
</author>

<date year="1989" day="1" month="January" />
</front>

<seriesInfo value="1087" name="RFC" />
</reference>


<reference target2="reference.RFC.1088.xml" anchor="RFC1088">
<front>
<title abbrev="IP over NetBIOS networks">Standard for the transmission of IP datagrams over NetBIOS networks</title>
<author fullname="Leo J. McLaughlin III" initials="L." surname="McLaughlin">
<organization>The Wollongong Group</organization>

<address>
<postal>
<street>1129 San Antonio Road</street>
<city>Palo Alto</city>
<region>CA</region>
<code>94303</code>
<country>US</country>
</postal>

<phone>+1 415 962 7100</phone>
<email>ljm@TWG.COM</email>
</address>
</author>

<date year="1989" day="1" month="February" />
</front>

<seriesInfo value="48" name="STD" />
<seriesInfo value="1088" name="RFC" />
</reference>


<reference target2="reference.RFC.1089.xml" anchor="RFC1089">
<front>
<title>SNMP over Ethernet</title>
<author fullname="Marty Schoffstall" initials="M." surname="Schoffstall">
<organization>NYSERNET Inc., Rensselaer Polytechnic Institute</organization>

<address>
<postal>
<street>165 Jordan Road</street>
<street>Rensselaer Technology Park</street>
<city>Troy</city>
<region>NY</region>
<code>12180</code>
<country>US</country>
</postal>

<phone>+1 518 276 2654</phone>
<email>schoff@stonewall.nyser.net</email>
</address>
</author>

<author fullname="Chuck Davin" initials="C." surname="Davin">
<organization>Massechusetts Institute of Technology (MIT) Laboratory for Computer Science</organization>

<address>
<postal>
<street>545 Technology Square</street>
<street>NE43-507</street>
<city>Cambridge</city>
<region>MA</region>
<code>02139</code>
<country>US</country>
</postal>

<phone>+1 617 253 6020</phone>
<email>jrd@ptt.lcs.mit.edu</email>
</address>
</author>

<author fullname="Mark Fedor" initials="M." surname="Fedor">
<organization>Nysernet, Inc.</organization>

<address>
<postal>
<street>125 Jordan Road</street>
<street>Rensselaer Technology Park</street>
<city>Troy</city>
<region>NY</region>
<code>12180</code>
<country>US</country>
</postal>

<phone>+1 518 283 8860</phone>
<email>fedor@patton.NYSER.NET</email>
</address>
</author>

<author fullname="Jeff Case" initials="J." surname="Case">
<organization>University of Tennessee, Knoxville, Computing Center</organization>

<address>
<postal>
<street>200 Stokely Management Center</street>
<city>Knoxville</city>
<region>TN</region>
<code>37996-0520</code>
<country>US</country>
</postal>

<phone>+1 615 974 6721</phone>
<email>case@UTKUX1.UTK.EDU</email>
</address>
</author>

<date year="1989" day="1" month="February" />
</front>

<seriesInfo value="1089" name="RFC" />
</reference>


<reference target2="reference.RFC.1090.xml" anchor="RFC1090">
<front>
<title>SMTP on X.25</title>
<author fullname="Robert Ullmann" initials="R." surname="Ullmann">
<organization>Prime Computer, Inc.</organization>

<address>
<postal>
<street>Technology Drive</street>
<city>Milford</city>
<region>MA</region>
<code>01757</code>
<country>US</country>
</postal>

<phone>+1 508 478 8600 x1736</phone>
<email>Ariel@Relay.Prime.COM</email>
</address>
</author>

<date year="1989" day="1" month="February" />
</front>

<seriesInfo value="1090" name="RFC" />
</reference>


<reference target2="reference.RFC.1091.xml" anchor="RFC1091">
<front>
<title>Telnet terminal-type option</title>
<author fullname="James VanBokkelen" initials="J." surname="VanBokkelen">
<organization>FTP Software, Inc.</organization>

<address>
<postal>
<street>26 Princess Street</street>
<city>Wakefield</city>
<region>MA</region>
<code>01880-3004</code>
<country>US</country>
</postal>

<phone>+1 617 246 0900</phone>
<email>jbvb@ftp.com</email>
</address>
</author>

<date year="1989" day="1" month="February" />
</front>

<seriesInfo value="1091" name="RFC" />
</reference>


<reference target2="reference.RFC.1092.xml" anchor="RFC1092">
<front>
<title abbrev="IP EGP and Policy Based Routing">EGP and policy based routing in the new NSFNET backbone</title>
<author fullname="Jacob Rekhter" initials="J." surname="Rekhter">
<organization>International Business Machines Corporation (IBM), T.J. Watson Research Center</organization>

<address>
<postal>
<street>P.O. Box 218</street>
<city>Yorktown Heights</city>
<region>NY</region>
<code>10598</code>
<country>US</country>
</postal>

<phone>+1 914 945 3896</phone>
<email>YAKOV@IBM.COM</email>
</address>
</author>

<date year="1989" day="1" month="February" />
</front>

<seriesInfo value="1092" name="RFC" />
</reference>


<reference target2="reference.RFC.1093.xml" anchor="RFC1093">
<front>
<title abbrev="NSFNET Routing Architecture">NSFNET routing architecture</title>
<author fullname="Hans-Werner Braun" initials="H." surname="Braun">
<organization>University of Michigan, Computing Center</organization>

<address>
<postal>
<street>1075 Beal Avenue</street>
<city>Ann Arbor</city>
<region>MI</region>
<code>48109</code>
<country>US</country>
</postal>

<phone>+1 313 763 4897</phone>
<email>HWB@MCR.UMICH.EDU</email>
</address>
</author>

<date year="1989" day="1" month="February" />
</front>

<seriesInfo value="1093" name="RFC" />
</reference>


<reference target2="reference.RFC.1094.xml" anchor="RFC1094">
<front>
<title abbrev="NFS: Network File System">NFS: Network File System Protocol specification</title>
<author fullname="Bill Nowicki" initials="B." surname="Nowicki">
<organization>Sun Microsystems, Inc.</organization>

<address>
<postal>
<street>2550 Garcia Avenue</street>
<street>Mail Stop 1-40</street>
<city>Mountain View</city>
<region>CA</region>
<code>94043</code>
<country>US</country>
</postal>

<phone>+1 415 336 7278</phone>
<email>nowicki@SUN.COM</email>
</address>
</author>

<date year="1989" day="1" month="March" />
</front>

<seriesInfo value="1094" name="RFC" />
</reference>


<reference target2="reference.RFC.1095.xml" anchor="RFC1095">
<front>
<title abbrev="CMOT">Common Management Information Services and Protocol over TCP/IP (CMOT)</title>
<author fullname="Unnikrishnan S. Warrier" initials="U." surname="Warrier">
<organization>Unisys Corporation</organization>

<address>
<postal>
<street>2400 Colorado  MS #42-13</street>
<city>Santa Monica</city>
<region>CA</region>
<code>90406</code>
<country>US</country>
</postal>

<phone>+1 213 453 5196</phone>
<email>unni@cs.ucla.edu</email>
</address>
</author>

<author fullname="Larry Besaw" initials="L." surname="Besaw">
<organization>Hewlett-Packard</organization>

<address>
<postal>
<street>3404 East Harmony Road</street>
<city>Fort Collins</city>
<region>CO</region>
<code>80525</code>
<country>US</country>
</postal>

<phone>+1 303 229 6022</phone>
<email>lmb%hpcndaw@hplabs.hp.com</email>
</address>
</author>

<date year="1989" day="1" month="April" />
</front>

<seriesInfo value="1095" name="RFC" />
</reference>


<reference target2="reference.RFC.1096.xml" anchor="RFC1096">
<front>
<title>Telnet X display location option</title>
<author fullname="Glenn A. Marcy" initials="G." surname="Marcy">
<organization>Carnegie Mellon University, School of Computer Science</organization>

<address>
<postal>
<street />
<city>Pittsburgh</city>
<region>PA</region>
<code>15213-3890</code>
<country>US</country>
</postal>

<phone>+1 412 268 7669</phone>
<email>Glenn.Marcy@CS.CMU.EDU</email>
</address>
</author>

<date year="1989" day="1" month="March" />
</front>

<seriesInfo value="1096" name="RFC" />
</reference>


<reference target2="reference.RFC.1097.xml" anchor="RFC1097">
<front>
<title abbrev="SUBLIMINAL">Telnet subliminal-message option</title>
<author fullname="B. Miller" initials="B." surname="Miller">
<organization>CMU-NetDev</organization>
</author>

<date year="1989" day="1" month="April" />
</front>

<seriesInfo value="1097" name="RFC" />
</reference>


<reference target2="reference.RFC.1098.xml" anchor="RFC1098">
<front>
<title abbrev="SNMP">Simple Network Management Protocol (SNMP)</title>
<author fullname="Jeffrey D. Case" initials="J." surname="Case">
<organization>University of Tennessee, Computing Center</organization>

<address>
<postal>
<street>200 Stokely Management Center</street>
<city>Knoxville</city>
<region>TN</region>
<code>37996-0520</code>
<country>US</country>
</postal>

<phone>+1 615 974 6721</phone>
<email>case@UTKUX1.UTK.EDU</email>
</address>
</author>

<author fullname="Mark Fedor" initials="M." surname="Fedor">
<organization>Nysernet, Inc.</organization>

<address>
<postal>
<street>125 Jordan Road</street>
<street>Rensselaer Technology Park</street>
<city>Troy</city>
<region>NY</region>
<code>12180</code>
<country>US</country>
</postal>

<phone>+1 518 283 8860</phone>
<email>fedor@patton.NYSER.NET</email>
</address>
</author>

<author fullname="Martin Lee Schoffstall" initials="M." surname="Schoffstall">
<organization>NYSERNET Inc.</organization>

<address>
<postal>
<street>165 Jordan Road</street>
<street>Rensselaer Technology Park</street>
<city>Troy</city>
<region>NY</region>
<code>12180</code>
<country>US</country>
</postal>

<phone>+1 518 283 8860</phone>
<email>schoff@NISC.NYSER.NET</email>
</address>
</author>

<author fullname="Chuck Davin" initials="C." surname="Davin">
<organization>Massechusetts Institute of Technology (MIT) Laboratory for Computer Science</organization>

<address>
<postal>
<street>545 Technology Square</street>
<street>NE43-507</street>
<city>Cambridge</city>
<region>MA</region>
<code>02139</code>
<country>US</country>
</postal>

<phone>+1 617 253 6020</phone>
<email>jrd@ptt.lcs.mit.edu</email>
</address>
</author>

<date year="1989" month="April" />
</front>

<seriesInfo value="1098" name="RFC" />
</reference>


<reference target2="reference.RFC.1099.xml" anchor="RFC1099">
<front>
<title abbrev="Summary of 1000-1099">Request for Comments Summary: RFC Numbers 1000-1099</title>
<author fullname="Joyce K. Reynolds" initials="J." surname="Reynolds">
<organization>University of Southern California (USC), Information Sciences Institute</organization>

<address>
<postal>
<street>4676 Admiralty Way</street>
<city>Marina del Rey</city>
<region>CA</region>
<code>90292</code>
<country>US</country>
</postal>

<phone>+1 310 822 1511</phone>
<email>JKREY@ISI.EDU</email>
</address>
</author>

<date year="1991" month="December" />
</front>

<seriesInfo value="1099" name="RFC" />
</reference>


<reference target2="reference.RFC.1100.xml" anchor="RFC1100">
<front>
<title abbrev="IAB Standards">IAB official protocol standards</title>
<author fullname="Jon Postel" initials="J." surname="Postel">
<organization>University of Southern California (USC)/Information Sciences Institute</organization>

<address>
<postal>
<street>4676 Admiralty Way</street>
<city>Marina del Rey</city>
<region>CA</region>
<code>90292</code>
<country>US</country>
</postal>

<phone>+1 213 822 1511</phone>
<email>Postel@ISI.EDU</email>
</address>
</author>

<date year="1989" day="1" month="April" />
</front>

<seriesInfo value="1100" name="RFC" />
</reference>


<reference target2="reference.RFC.1101.xml" anchor="RFC1101">
<front>
<title>DNS encoding of network names and other types</title>
<author fullname="Paul Mockapetris" initials="P." surname="Mockapetris">
<organization>USC/Information Sciences Institute</organization>

<address>
<postal>
<street>4676 Admiralty Way</street>
<city>Marina del Rey</city>
<region>CA</region>
<code>90292</code>
<country>US</country>
</postal>

<phone>+1 213 822 1511</phone>
<email>PVM@ISI.EDU</email>
</address>
</author>

<date year="1989" day="1" month="April" />
</front>

<seriesInfo value="1101" name="RFC" />
</reference>


<reference target2="reference.RFC.1102.xml" anchor="RFC1102">
<front>
<title>Policy routing in Internet protocols</title>
<author fullname="David D. Clark" initials="D." surname="Clark">
<organization>Massachusetts Institute of Technology (MIT), Laboratory for Computer Science</organization>

<address>
<postal>
<street>545 Main Street</street>
<city>Cambridge</city>
<region>MA</region>
<code>02139</code>
<country>US</country>
</postal>

<phone>+1 617 253 6003</phone>
<email>ddc@LCS.MIT.EDU</email>
</address>
</author>

<date year="1989" day="1" month="May" />
</front>

<seriesInfo value="1102" name="RFC" />
</reference>


<reference target2="reference.RFC.1103.xml" anchor="RFC1103">
<front>
<title abbrev="IP Datagrams over FDDI Networks">Proposed standard for the transmission of IP datagrams over FDDI Networks</title>
<author fullname="Dave Katz" initials="D." surname="Katz">
<organization>Merit/NSFNET</organization>

<address>
<postal>
<street>1075 Beal</street>
<city>Ann Arbor</city>
<region>MI</region>
<code>48109-2112</code>
<country>US</country>
</postal>

<phone>+1 800 666 3748</phone>
<email>Dave_Katz@um.cc.umich.edu</email>
</address>
</author>

<date year="1989" day="1" month="June" />
</front>

<seriesInfo value="1103" name="RFC" />
</reference>


<reference target2="reference.RFC.1104.xml" anchor="RFC1104">
<front>
<title>Models of policy based routing</title>
<author fullname="Hans-Werner Braun" initials="H." surname="Braun">
<organization>University of Michigan, Merit Computer Network</organization>

<address>
<postal>
<street>1075 Beal Avenue</street>
<city>Ann Arbor</city>
<region>MI</region>
<code>48109</code>
<country>US</country>
</postal>

<phone>+1 313 763 4897</phone>
<facsimile>+1 313 747 3745</facsimile>
<email>hwb@merit.edu</email>
</address>
</author>

<date year="1989" day="1" month="June" />
</front>

<seriesInfo value="1104" name="RFC" />
</reference>


<reference target2="reference.RFC.1105.xml" anchor="RFC1105">
<front>
<title abbrev="BGP">Border Gateway Protocol (BGP)</title>
<author fullname="Kirk Lougheed" initials="K." surname="Lougheed">
<organization>cisco Systems, Inc.</organization>

<address>
<postal>
<street>1360 Willow Road</street>
<street>Suite 201</street>
<city>Menlo Park</city>
<region>CA</region>
<code>94025</code>
<country>US</country>
</postal>

<phone>+1 415 326 1941</phone>
<email>LOUGHEED@MATHOM.CISCO.COM</email>
</address>
</author>

<author fullname="Jacob Rekhter" initials="J." surname="Rekhter">
<organization>IBM Corporation, T.J. Watson Research Center</organization>

<address>
<postal>
<street>P.O. Box 218</street>
<city>Yorktown Heights</city>
<region>NY</region>
<code>10598</code>
<country>US</country>
</postal>

<phone>+1 914 945 3896</phone>
<email>YAKOV@IBM.COM</email>
</address>
</author>

<date year="1989" day="1" month="June" />
</front>

<seriesInfo value="1105" name="RFC" />
</reference>


<reference target2="reference.RFC.1106.xml" anchor="RFC1106">
<front>
<title>TCP big window and NAK options</title>
<author fullname="Richard Fox" initials="R." surname="Fox">
<organization>Tandem</organization>

<address>
<postal>
<street>950 Linden #208</street>
<city>Sunnyvale</city>
<region>CA</region>
<code>94086</code>
<country>US</country>
</postal>

<email>rfox@tandem.com</email>
</address>
</author>

<date year="1989" day="1" month="June" />

<abstract>
<t>Two extensions to the TCP protocol are described in this RFC in order to provide a more efficient operation over a network with a high bandwidth*delay product.  The main issue that still needs to be solved is congestion versus noise.  This issue is touched on in this memo, but further research is still needed on the applicability of the extensions in the Internet as a whole infrastructure and not just high bandwidth*delay product networks.  Even with this outstanding issue, this document does describe the use of these options in the isolated satellite network environment to help facilitate more efficient use of this special medium to help off load bulk data transfers from links needed for interactive use.</t>
</abstract>
</front>

<seriesInfo value="1106" name="RFC" />
</reference>


<reference target2="reference.RFC.1107.xml" anchor="RFC1107">
<front>
<title>Plan for Internet directory services</title>
<author fullname="Karen R. Sollins" initials="K." surname="Sollins">
<organization>Massachusetts Institute of Technology (MIT), Laboratory for Computer Science</organization>

<address>
<postal>
<street>545 Technology Square</street>
<city>Cambridge</city>
<region>MA</region>
<code>02139-1986</code>
<country>US</country>
</postal>

<phone>+1 617 253 6006</phone>
<email>SOLLINS@XX.LCS.MIT.EDU</email>
</address>
</author>

<date year="1989" day="1" month="July" />
</front>

<seriesInfo value="1107" name="RFC" />
</reference>


<reference target2="reference.RFC.1108.xml" anchor="RFC1108">
<front>
<title abbrev="U.S. DOD Security Option">U.S</title>
<author fullname="Stephen Kent" initials="S." surname="Kent">
<organization>Bolt Baranek and Newman Communications (BBNCC)</organization>

<address>
<postal>
<street>150 CambridgePark Drive</street>
<city>Cambridge</city>
<region>MA</region>
<code>02140</code>
<country>US</country>
</postal>

<phone>+1 617 873 3988</phone>
<email>kent@bbn.com</email>
</address>
</author>

<date year="1991" month="November" />

<abstract>
<t>This RFC specifies the U.S. Department of Defense Basic Security Option and the top-level description of the Extended Security Option for use with the Internet Protocol.  This RFC obsoletes RFC 1038 "Revised IP Security Option", dated January 1988.</t>
</abstract>
</front>

<seriesInfo value="1108" name="RFC" />
</reference>


<reference target2="reference.RFC.1109.xml" anchor="RFC1109">
<front>
<title abbrev="Internet Management">Report of the second Ad Hoc Network Management Review Group</title>
<author fullname="Vinton G. Cerf" initials="V." surname="Cerf">
<organization>Corporation for National Research Initiatives</organization>

<address>
<postal>
<street>1895 Preston White Drive</street>
<street>Suite 100</street>
<city>Reston</city>
<region>VA</region>
<code>22091</code>
<country>US</country>
</postal>

<phone>+1 703 620 8990</phone>
<email>CERF@A.ISI.EDU</email>
</address>
</author>

<date year="1989" day="1" month="August" />
</front>

<seriesInfo value="1109" name="RFC" />
</reference>


<reference target2="reference.RFC.1110.xml" anchor="RFC1110">
<front>
<title abbrev="Comments on TCP Big Window Option">Problem with the TCP big window option</title>
<author fullname="Alex McKenzie" initials="A." surname="McKenzie">
<organization>Bolt Beranek and Newman Inc. (BBN)</organization>

<address>
<postal>
<street>10 Moulton Street</street>
<city>Cambridge</city>
<region>MA</region>
<code>02238</code>
<country>US</country>
</postal>

<phone>+1 617 873 2962</phone>
<email>MCKENZIE@BBN.COM</email>
</address>
</author>

<date year="1989" day="1" month="August" />

<abstract>
<t>The TCP Big Window option discussed in RFC 1106 will not work properly in an Internet environment which has both a high bandwidth * delay product and the possibility of disordering and duplicating packets.  In such networks, the window size must not be increased without a similar increase in the sequence number space.  Therefore, a different approach to big windows should be taken in the Internet.</t>
</abstract>
</front>

<seriesInfo value="1110" name="RFC" />
</reference>


<reference target2="reference.RFC.1111.xml" anchor="RFC1111">
<front>
<title abbrev="RFC Instructions">Request for comments on Request for Comments: Instructions to RFC authors</title>
<author fullname="Jon Postel" initials="J." surname="Postel">
<organization>USC/Information Sciences Institute</organization>

<address>
<postal>
<street>4676 Admiralty Way</street>
<city>Marina del Rey</city>
<region>CA</region>
<code>90292-6695</code>
<country>US</country>
</postal>

<phone>+1 213 822 1511</phone>
<email>POSTEL@ISI.EDU</email>
</address>
</author>

<date year="1989" day="1" month="August" />
</front>

<seriesInfo value="1111" name="RFC" />
</reference>


<reference target2="reference.RFC.1112.xml" anchor="RFC1112">
<front>
<title>Host extensions for IP multicasting</title>
<author fullname="Steve Deering" initials="S." surname="Deering">
<organization>Stanford University, Computer Science Department</organization>

<address>
<postal>
<street />
<city>Stanford</city>
<region>CA</region>
<code>94305-2140</code>
<country>US</country>
</postal>

<phone>+1 415 723 9427</phone>
<email>deering@PESCADERO.STANFORD.EDU</email>
</address>
</author>

<date year="1989" day="1" month="August" />
</front>

<seriesInfo value="5" name="STD" />
<seriesInfo value="1112" name="RFC" />
</reference>


<reference target2="reference.RFC.1113.xml" anchor="RFC1113">
<front>
<title abbrev="Mail Privacy: Procedures">Privacy enhancement for Internet electronic mail: Part I - message encipherment and authentication procedures</title>
<author fullname="John Linn" initials="J." surname="Linn">
<organization>Digital Equipment Corporation (DEC), Secure Systems</organization>

<address>
<postal>
<street>85 Swanson Road</street>
<street>BXB1-2/D04</street>
<city>Boxborough</city>
<region>MA</region>
<code>01719-1326</code>
<country>US</country>
</postal>

<phone>+1 508 264 5491</phone>
<email>Linn@ultra.enet.dec.com</email>
</address>
</author>

<date year="1989" day="1" month="August" />
</front>

<seriesInfo value="1113" name="RFC" />
</reference>


<reference target2="reference.RFC.1114.xml" anchor="RFC1114">
<front>
<title abbrev="Mail Privacy: Key Management">Privacy enhancement for Internet electronic mail: Part II - certificate-based key management</title>
<author fullname="Steve Kent" initials="S." surname="Kent">
<organization>Bolt Baranek and Newman Communications (BBNCC)</organization>

<address>
<postal>
<street>50 Moulton Street</street>
<city>Cambridge</city>
<region>MA</region>
<code>02138</code>
<country>US</country>
</postal>

<phone>+1 617 873 3988</phone>
<email>kent@BBN.COM</email>
</address>
</author>

<author fullname="John Linn" initials="J." surname="Linn">
<organization>Digital Equipment Corporation (DEC), Secure Systems</organization>

<address>
<postal>
<street>85 Swanson Road</street>
<street>BXB1-2/D04</street>
<city>Boxborough</city>
<region>MA</region>
<code>01719-1326</code>
<country>US</country>
</postal>

<phone>+1 508 264 5491</phone>
<email>Linn@ultra.enet.dec.com</email>
</address>
</author>

<date year="1989" day="1" month="August" />
</front>

<seriesInfo value="1114" name="RFC" />
</reference>


<reference target2="reference.RFC.1115.xml" anchor="RFC1115">
<front>
<title abbrev="Mail Privacy: Algorithms">Privacy enhancement for Internet electronic mail: Part III - algorithms, modes, and identifiers</title>
<author fullname="John Linn" initials="J." surname="Linn">
<organization>Digital Equipment Corporation (DEC), Secure Systems</organization>

<address>
<postal>
<street>85 Swanson Road</street>
<street>BXB1-2/D04</street>
<city>Boxborough</city>
<region>MA</region>
<code>01719-1326</code>
<country>US</country>
</postal>

<phone>+1 508 264 5491</phone>
<email>Linn@ultra.enet.dec.com</email>
</address>
</author>

<date year="1989" day="1" month="August" />
</front>

<seriesInfo value="1115" name="RFC" />
</reference>


<reference target2="reference.RFC.1116.xml" anchor="RFC1116">
<front>
<title>Telnet Linemode option</title>
<author fullname="Dave Borman" initials="D." surname="Borman">
<organization>Cray Research Inc.</organization>

<address>
<postal>
<street>1440 Northland Drive</street>
<city>Mendota Heights</city>
<region>MN</region>
<code>55120</code>
<country>US</country>
</postal>

<phone>+1 612 681 3398</phone>
<email>dab@CRAY.COM</email>
</address>
</author>

<date year="1989" day="1" month="August" />
</front>

<seriesInfo value="1116" name="RFC" />
</reference>


<reference target2="reference.RFC.1117.xml" anchor="RFC1117">
<front>
<title abbrev="Internet Numbers">Internet numbers</title>
<author fullname="Sue Romano" initials="S." surname="Romano">
<organization>SRI International, Network Information Systems Center</organization>

<address>
<postal>
<street>333 Ravenswood Avenue</street>
<street>EJ217</street>
<city>Menlo Park</city>
<region>CA</region>
<code>94025</code>
<country>US</country>
</postal>

<phone>+1 415 859 5539</phone>
<email>SUE@NIC.DDN.MIL</email>
</address>
</author>

<author fullname="Mary Stahl" initials="M." surname="Stahl">
<organization>SRI International, Network Information Systems Center</organization>

<address>
<postal>
<street>333 Ravenswood Avenue</street>
<street>EJ296</street>
<city>Menlo Park</city>
<region>CA</region>
<code>94025</code>
<country>US</country>
</postal>

<phone>+1 415 859 4775</phone>
<email>STAHL@NIC.DDN.MIL</email>
</address>
</author>

<author fullname="Mimi Recker" initials="M." surname="Recker">
<organization>SRI International, Network Information Systems Center</organization>

<address>
<postal>
<street>333 Ravenswood Avenue</street>
<street>EJ268</street>
<city>Menlo Park</city>
<region>CA</region>
<code>94025</code>
<country>US</country>
</postal>

<phone>+1 415 859 2110</phone>
<email>Mimi@NIC.DDN.MIL</email>
</address>
</author>

<date year="1989" day="1" month="August" />
</front>

<seriesInfo value="1117" name="RFC" />
</reference>


<reference target2="reference.RFC.1118.xml" anchor="RFC1118">
<front>
<title>Hitchhikers guide to the Internet</title>
<author fullname="Ed Krol" initials="E." surname="Krol">
<organization>University of Illinois, Urbana</organization>

<address>
<postal>
<street>1304 West Springfield Avenue</street>
<street>195 DCL</street>
<city>Urbana</city>
<region>IL</region>
<code>61801-4399</code>
<country>US</country>
</postal>

<phone>+1 217 333 7886</phone>
<email>Krol@UXC.CSO.UIUC.EDU</email>
</address>
</author>

<date year="1989" day="1" month="September" />
</front>

<seriesInfo value="1118" name="RFC" />
</reference>


<reference target2="reference.RFC.1119.xml" anchor="RFC1119">
<front>
<title>Network Time Protocol (version 2) specification and implementation</title>
<author fullname="D.L. Mills" initials="D.L." surname="Mills">
<organization />
</author>

<date year="1989" day="1" month="September" />
</front>

<seriesInfo value="12" name="STD" />
<seriesInfo value="1119" name="RFC" />
<format octets="143" type="TXT" target="ftp://ftp.isi.edu/in-notes/rfc1119.txt" />
<format octets="518020" type="PS" target="ftp://ftp.isi.edu/in-notes/rfc1119.ps" />
<format octets="187940" type="PDF" target="ftp://ftp.isi.edu/in-notes/rfc1119.pdf" />
</reference>


<reference target2="reference.RFC.1120.xml" anchor="RFC1120">
<front>
<title abbrev="The IAB">Internet Activities Board</title>
<author fullname="Vinton G. Cerf" initials="V." surname="Cerf">
<organization>Corporation for National Research Initiatives (NRI)</organization>

<address>
<postal>
<street>1895 Preston White Drive</street>
<street>Suite 100</street>
<city>Reston</city>
<region>VA</region>
<code>22091</code>
<country>US</country>
</postal>

<phone>+1 703 620 8990</phone>
<email>VCERF@NRI.RESTON.VA.US</email>
</address>
</author>

<date year="1989" day="1" month="September" />
</front>

<seriesInfo value="1120" name="RFC" />
</reference>


<reference target2="reference.RFC.1121.xml" anchor="RFC1121">
<front>
<title>Act one - the poems</title>
<author fullname="Jon Postel" initials="J." surname="Postel">
<organization>USC/Information Sciences Institute</organization>

<address>
<postal>
<street>4676 Admiralty Way</street>
<city>Marina del Rey</city>
<region>CA</region>
<code>90292-6695</code>
<country>US</country>
</postal>

<phone>+1 213 822 1511</phone>
<email>Postel@ISI.EDU</email>
</address>
</author>

<author fullname="Leonard Kleinrock" initials="L." surname="Kleinrock">
<organization>University of California  Los Angeles (UCLA), Computer Science Department</organization>

<address>
<postal>
<street>3732G Boelter Hall</street>
<city>Los Angeles</city>
<region>CA</region>
<code>90024-1600</code>
<country>US</country>
</postal>

<phone>+1 213 825 2543</phone>
<email>lk@CS.UCLA.EDU</email>
</address>
</author>

<author fullname="Vinton G. Cerf" initials="V." surname="Cerf">
<organization>Corporation for National Research Initiatives</organization>

<address>
<postal>
<street>1895 Preston White Drive</street>
<street>Suite 100</street>
<city>Reston</city>
<region>VA</region>
<code>22091</code>
<country>US</country>
</postal>

<phone>+1 703 620 8990</phone>
<email>VCerf@NRI.RESTON.VA.US</email>
</address>
</author>

<author fullname="Barry Boehm" initials="B." surname="Boehm">
<organization>University of California  Los Angeles (UCLA), Computer Science Department</organization>

<address>
<postal>
<street>3732 Boelter Hall</street>
<city>Los Angeles</city>
<region>CA</region>
<code>90024-1600</code>
<country>US</country>
</postal>

<phone>+1 213 825 8137</phone>
<email>boehm@CS.UCLA.EDU</email>
</address>
</author>

<date year="1989" day="1" month="September" />
</front>

<seriesInfo value="1121" name="RFC" />
</reference>


<reference target2="reference.RFC.1122.xml" anchor="RFC1122">
<front>
<title>Requirements for Internet Hosts - Communication Layers</title>
<author fullname="Robert Braden" initials="R." surname="Braden">
<organization>University of Southern California (USC)/ Information Sciences Institute (ISI)</organization>

<address>
<postal>
<street>4676 Admiralty Way</street>
<city>Marina del Rey</city>
<region>CA</region>
<code>90292-6695</code>
<country>US</country>
</postal>

<phone>+1 213 822 1511</phone>
<email>Braden@ISI.EDU</email>
</address>
</author>

<date year="1989" month="October" />
</front>

<seriesInfo value="3" name="STD" />
<seriesInfo value="1122" name="RFC" />
</reference>


<reference target2="reference.RFC.1123.xml" anchor="RFC1123">
<front>
<title>Requirements for Internet Hosts - Application and Support</title>
<author fullname="Robert Braden" initials="R." surname="Braden">
<organization>University of Southern California (USC), Information Sciences Institute</organization>

<address>
<postal>
<street>4676 Admiralty Way</street>
<city>Marina del Rey</city>
<region>CA</region>
<code>90292-6695</code>
<country>US</country>
</postal>

<phone>+1 213 822 1511</phone>
<email>Braden@ISI.EDU</email>
</address>
</author>

<date year="1989" month="October" />
</front>

<seriesInfo value="3" name="STD" />
<seriesInfo value="1123" name="RFC" />
</reference>


<reference target2="reference.RFC.1124.xml" anchor="RFC1124">
<front>
<title>Policy issues in interconnecting networks</title>
<author fullname="B.M. Leiner" initials="B.M." surname="Leiner">
<organization />
</author>

<date year="1989" day="1" month="September" />
</front>

<seriesInfo value="1124" name="RFC" />
<format octets="118" type="TXT" target="ftp://ftp.isi.edu/in-notes/rfc1124.txt" />
<format octets="315692" type="PS" target="ftp://ftp.isi.edu/in-notes/rfc1124.ps" />
<format octets="143819" type="PDF" target="ftp://ftp.isi.edu/in-notes/rfc1124.pdf" />
</reference>


<reference target2="reference.RFC.1125.xml" anchor="RFC1125">
<front>
<title abbrev="Policy Requirements">Policy requirements for inter Administrative Domain routing</title>
<author fullname="Deborah Estrin" initials="D." surname="Estrin">
<organization>University of Southern California (USC), Computer Science Department</organization>

<address>
<postal>
<street />
<city>Los Angeles</city>
<region>CA</region>
<code>90089-0782</code>
<country>US</country>
</postal>

<phone>+1 213 743 7842</phone>
<email>Estrin@OBERON.USC.EDU</email>
</address>
</author>

<date year="1989" day="1" month="November" />

<abstract>
<t>Efforts are now underway to develop a new generation of routing protocol that will allow each Administrative Domain (AD) in the growing Internet (and internets in general) to independently express and enforce policies regarding the flow of packets to, from, and through its resources. (FOOTNOTE 1: The material presented here incorporates discussions held with members of the IAB Autonomous Networks Research Group and the Open Routing Working Group.)  This document articulates the requirements for policy based routing and should be used as input to the functional specification and evaluation of proposed protocols.</t>

<t>Two critical assumptions will shape the type of routing mechanism that is devised: (1) the topological organization of ADs, and (2) the type and variability of policies expressed by ADs.  After justifying our assumptions regarding AD topology we present a taxonomy, and specific examples, of policies that must be supported by a PR protocol.  We conclude with a brief discussion of policy routing mechanisms proposed in previous RFCs (827, 1102, 1104, 1105).  Future RFCs will elaborate on the architecture and protocols needed to support the requirements presented here.</t>
</abstract>
</front>

<seriesInfo value="1125" name="RFC" />
</reference>


<reference target2="reference.RFC.1126.xml" anchor="RFC1126">
<front>
<title abbrev="Inter-Autonomous System Routing">Goals and functional requirements for inter-autonomous system routing</title>
<author fullname="Mike Little" initials="M." surname="Little">
<organization>Science Applications International Corporation (SAIC)</organization>

<address>
<postal>
<street>8619 Westwood Center Drive</street>
<city>Vienna</city>
<region>VA</region>
<code>22182</code>
<country>US</country>
</postal>

<phone>+1 703 734 9000</phone>
<email>little@SAIC.COM</email>
</address>
</author>

<date year="1989" day="1" month="October" />
</front>

<seriesInfo value="1126" name="RFC" />
</reference>


<reference target2="reference.RFC.1127.xml" anchor="RFC1127">
<front>
<title abbrev="Perspective on Host Requirements">Perspective on the Host Requirements RFCs</title>
<author fullname="Robert Braden" initials="R." surname="Braden">
<organization>USC/Information Sciences Institute</organization>

<address>
<postal>
<street>4676 Admiralty Way</street>
<city>Marina del Rey</city>
<region>CA</region>
<code>90292-6695</code>
<country>US</country>
</postal>

<phone>+1 213 822 1511</phone>
<email>Braden@ISI.EDU</email>
</address>
</author>

<date year="1989" day="1" month="October" />
</front>

<seriesInfo value="1127" name="RFC" />
</reference>


<reference target2="reference.RFC.1128.xml" anchor="RFC1128">
<front>
<title>Measured performance of the Network Time Protocol in the Internet system</title>
<author fullname="D.L. Mills" initials="D.L." surname="Mills">
<organization />
</author>

<date year="1989" day="1" month="October" />
</front>

<seriesInfo value="1128" name="RFC" />
<format octets="314" type="TXT" target="ftp://ftp.isi.edu/in-notes/rfc1128.txt" />
<format octets="633742" type="PS" target="ftp://ftp.isi.edu/in-notes/rfc1128.ps" />
<format octets="197897" type="PDF" target="ftp://ftp.isi.edu/in-notes/rfc1128.pdf" />
</reference>


<reference target2="reference.RFC.1129.xml" anchor="RFC1129">
<front>
<title>Internet Time Synchronization: The Network Time Protocol</title>
<author fullname="D.L. Mills" initials="D.L." surname="Mills">
<organization />
</author>

<date year="1989" day="1" month="October" />
</front>

<seriesInfo value="1129" name="RFC" />
<format octets="298" type="TXT" target="ftp://ftp.isi.edu/in-notes/rfc1129.txt" />
<format octets="551697" type="PS" target="ftp://ftp.isi.edu/in-notes/rfc1129.ps" />
<format octets="197036" type="PDF" target="ftp://ftp.isi.edu/in-notes/rfc1129.pdf" />
</reference>


<reference target2="reference.RFC.1130.xml" anchor="RFC1130">
<front>
<title abbrev="IAB Standards">IAB official protocol standards</title>
<author fullname="Jon Postel" initials="J." surname="Postel">
<organization>University of Southern California (USC)/Information Sciences Institute</organization>

<address>
<postal>
<street>4676 Admiralty Way</street>
<city>Marina del Rey</city>
<region>CA</region>
<code>90292</code>
<country>US</country>
</postal>

<phone>+1 213 822 1511</phone>
<email>Postel@ISI.EDU</email>
</address>
</author>

<date year="1989" day="1" month="October" />
</front>

<seriesInfo value="1130" name="RFC" />
</reference>


<reference target2="reference.RFC.1131.xml" anchor="RFC1131">
<front>
<title>OSPF specification</title>
<author fullname="J. Moy" initials="J." surname="Moy">
<organization />
</author>

<date year="1989" day="1" month="October" />
</front>

<seriesInfo value="1131" name="RFC" />
<format octets="268" type="TXT" target="ftp://ftp.isi.edu/in-notes/rfc1131.txt" />
<format octets="857280" type="PS" target="ftp://ftp.isi.edu/in-notes/rfc1131.ps" />
<format octets="398863" type="PDF" target="ftp://ftp.isi.edu/in-notes/rfc1131.pdf" />
</reference>


<reference target2="reference.RFC.1132.xml" anchor="RFC1132">
<front>
<title abbrev="802.2 Packets over IPX Networks">Standard for the transmission of 802.2 packets over IPX networks</title>
<author fullname="Leo J. McLaughlin III" initials="L." surname="McLaughlin">
<organization>The Wollongong Group</organization>

<address>
<postal>
<street>1129 San Antonio Road</street>
<city>Palo Alto</city>
<region>CA</region>
<code>94303</code>
<country>US</country>
</postal>

<phone>+1 415 962 7100</phone>
<email>ljm@TWG.COM</email>
</address>
</author>

<date year="1989" day="1" month="November" />
</front>

<seriesInfo value="49" name="STD" />
<seriesInfo value="1132" name="RFC" />
</reference>


<reference target2="reference.RFC.1133.xml" anchor="RFC1133">
<front>
<title>Routing between the NSFNET and the DDN</title>
<author fullname="Jessica (Jie Yun) Yu" initials="J." surname="Yu">
<organization>Merit Computer Network</organization>

<address>
<postal>
<street>1075 Beal Avenue</street>
<city>Ann Arbor</city>
<region>MI</region>
<code>48109</code>
<country>US</country>
</postal>

<phone>+1 313 936 2655</phone>
<facsimile>+1 313 747 3745</facsimile>
<email>jyy@merit.edu</email>
</address>
</author>

<author fullname="Hans-Werner Braun" initials="H." surname="Braun">
<organization>Merit Computer Network</organization>

<address>
<postal>
<street>1075 Beal Avenue</street>
<city>Ann Arbor</city>
<region>MI</region>
<code>48109</code>
<country>US</country>
</postal>

<phone>+1 313 763 4897</phone>
<facsimile>+1 313 747 3745</facsimile>
<email>hwb@merit.edu</email>
</address>
</author>

<date year="1989" day="1" month="November" />
</front>

<seriesInfo value="1133" name="RFC" />
</reference>


<reference target2="reference.RFC.1134.xml" anchor="RFC1134">
<front>
<title abbrev="PPP">Point-to-Point Protocol: A proposal for multi-protocol transmission of datagrams over Point-to-Point links</title>
<author fullname="Drew Perkins" initials="D." surname="Perkins">
<organization>University of California, Davis, Computing Services</organization>
</author>

<date year="1989" day="1" month="November" />

<abstract>
<t>The Point-to-Point Protocol (PPP) provides a method for transmitting datagrams over serial point-to-point links.  PPP is composed of three parts:</t>

<t>1. A method for encapsulating datagrams over serial links.</t>

<t>2. An extensible Link Control Protocol (LCP).</t>

<t>3. A family of Network Control Protocols (NCP) for establishing and configuring different network-layer protocols.</t>

<t>This document defines the encapsulation scheme, the basic LCP, and an NCP for establishing and configuring the Internet Protocol (IP) (called the IP Control Protocol, IPCP).</t>

<t>The options and facilities used by the LCP and the IPCP are defined in separate documents.  Control protocols for configuring and utilizing other network-layer protocols besides IP (e.g., DECNET, OSI) are expected to be developed as needed.</t>
</abstract>
</front>

<seriesInfo value="1134" name="RFC" />
</reference>


<reference target2="reference.RFC.1135.xml" anchor="RFC1135">
<front>
<title>Helminthiasis of the Internet</title>
<author fullname="Joyce K. Reynolds" initials="J." surname="Reynolds">
<organization>University of Southern California (USC), Information Sciences Institute (ISI)</organization>

<address>
<postal>
<street>4676 Admiralty Way</street>
<city>Marina del Rey</city>
<region>CA</region>
<code>90292</code>
<country>US</country>
</postal>

<phone>+1 213 822 1511</phone>
<email>JKREY@ISI.EDU</email>
</address>
</author>

<date year="1989" day="1" month="December" />
</front>

<seriesInfo value="1135" name="RFC" />
</reference>


<reference target2="reference.RFC.1136.xml" anchor="RFC1136">
<front>
<title abbrev="A Model for Routing in the Internet">Administrative Domains and Routing Domains: A model for routing in the Internet</title>
<author fullname="Susan Hares" initials="S." surname="Hares">
<organization>Merit/NSFNET</organization>

<address>
<postal>
<street>1075 Beal Ave.</street>
<city>Ann Arbor</city>
<region>MI</region>
<code>48109</code>
<country>US</country>
</postal>

<phone>+1 313 936 3000</phone>
<email>skh@merit.edu</email>
</address>
</author>

<author fullname="Dave Katz" initials="D." surname="Katz">
<organization>Merit/NSFNET</organization>

<address>
<postal>
<street>1075 Beal Ave.</street>
<city>Ann Arbor</city>
<region>MI</region>
<code>48109</code>
<country>US</country>
</postal>

<phone>+1 313 763 4898</phone>
<email>dkatz@merit.edu</email>
</address>
</author>

<date year="1989" day="1" month="December" />
</front>

<seriesInfo value="1136" name="RFC" />
</reference>


<reference target2="reference.RFC.1137.xml" anchor="RFC1137">
<front>
<title abbrev="E-Mail Address and Quoted Strings">Mapping between full RFC 822 and RFC 822 with restricted encoding</title>
<author fullname="Steve Kille" initials="S." surname="Kille">
<organization>University College London (UCL)</organization>

<address>
<postal>
<street>Gower Street</street>
<city>London</city>
<region>England</region>
<code>WC1E 6BT</code>
<country>UK</country>
</postal>

<phone>+44 1 3807294</phone>
<email>S.Kille@Cs.Ucl.AC.UK</email>
</address>
</author>

<date year="1989" day="1" month="December" />
</front>

<seriesInfo value="1137" name="RFC" />
</reference>


<reference target2="reference.RFC.1138.xml" anchor="RFC1138">
<front>
<title abbrev="Mapping X.400(88) and 822">Mapping between X.400(1988) / ISO 10021 and RFC 822</title>
<author fullname="Steve Kille" initials="S." surname="Kille">
<organization>University College London</organization>

<address>
<postal>
<street>Gower Street</street>
<city>London</city>
<region>England</region>
<code>WC1E 6BT</code>
<country>UK</country>
</postal>

<phone>+44 1 3807294</phone>
<email>S.Kille@Cs.Ucl.AC.UK</email>
</address>
</author>

<date year="1989" day="1" month="December" />
</front>

<seriesInfo value="1138" name="RFC" />
</reference>


<reference target2="reference.RFC.1139.xml" anchor="RFC1139">
<front>
<title>Echo function for ISO 8473</title>
<author fullname="Robert A. Hagens" initials="R." surname="Hagens">
<organization>University of Wisconsin, Computer Science Department</organization>

<address>
<postal>
<street>1210 West Dayton Street</street>
<city>Madison</city>
<region>WI</region>
<code>53706</code>
<country>US</country>
</postal>

<phone>+1 608 262 1204</phone>
<email>hagens@CS.WISC.EDU</email>
</address>
</author>

<date year="1990" day="1" month="January" />

<abstract>
<t>This memo defines an echo function for the connection-less network layer protocol.  Two mechanisms are introduced that may be used to implement the echo function.  The first mechanism is recommended as an interim solution for the Internet community.  The second mechanism will be progressed to the ANSI X3S3.3 working group for consideration as a work item.</t>

<t>When an ISO standard is adopted that provides functionality similar to that described by this memo, then this memo will become obsolete and superceded by the ISO standard.</t>
</abstract>
</front>

<seriesInfo value="1139" name="RFC" />
</reference>


<reference target2="reference.RFC.1140.xml" anchor="RFC1140">
<front>
<title abbrev="IAB Standards">IAB official protocol standards</title>
<author fullname="Jon Postel" initials="J." surname="Postel">
<organization>USC/Information Sciences Institute</organization>

<address>
<postal>
<street>4676 Admiralty Way</street>
<city>Marina del Rey</city>
<region>CA</region>
<code>90292</code>
<country>US</country>
</postal>

<phone>+1 213 822 1511</phone>
<email>Postel@ISI.EDU</email>
</address>
</author>

<date year="1990" day="1" month="May" />
</front>

<seriesInfo value="1140" name="RFC" />
</reference>


<reference target2="reference.RFC.1141.xml" anchor="RFC1141">
<front>
<title abbrev="Incremental Updating">Incremental updating of the Internet checksum</title>
<author fullname="Tracy Mallory" initials="T." surname="Mallory">
<organization>Bolt Baranek and Newman Communications Corporation</organization>

<address>
<postal>
<street>50 Moulton Street</street>
<city>Cambridge</city>
<region>MA</region>
<code>02238</code>
<country>US</country>
</postal>

<phone>+1 617 873 3193</phone>
<email>tmallory@CCV.BBN.COM</email>
</address>
</author>

<author fullname="A. Kullberg" initials="A." surname="Kullberg">
<organization>Bolt Baranek and Newman Communications Corporation</organization>

<address>
<postal>
<street>50 Moulton Street</street>
<city>Cambridge</city>
<region>MA</region>
<code>02238</code>
<country>US</country>
</postal>

<phone>+1 617 873 4000</phone>
<email>akullberg@BBN.COM</email>
</address>
</author>

<date year="1990" day="1" month="January" />
</front>

<seriesInfo value="1141" name="RFC" />
</reference>


<reference target2="reference.RFC.1142.xml" anchor="RFC1142">
<front>
<title>OSI IS-IS Intra-domain Routing Protocol</title>
<author fullname="David R. Oran" initials="D." surname="Oran">
<organization>Digital Equipment Corporation (DEC)</organization>

<address>
<postal>
<street>550 King Street</street>
<street>LKG 1-2/a 19</street>
<city>Littleton</city>
<region>MA</region>
<code>01460</code>
<country>US</country>
</postal>

<phone>+1 508 486 7377</phone>
<email>Oran@Oran.enet.dec.com</email>
</address>
</author>

<date year="1990" day="1" month="February" />
</front>

<seriesInfo value="1142" name="RFC" />
</reference>


<reference target2="reference.RFC.1143.xml" anchor="RFC1143">
<front>
<title abbrev="Q Method">The Q Method of Implementing TELNET Option Negotiation</title>
<author fullname="Daniel J. Bernstein" initials="D." surname="Bernstein">
<organization>New York University</organization>

<address>
<postal>
<street>5 Brewster Lane</street>
<city>Bellport</city>
<region>NY</region>
<code>11713</code>
<country>US</country>
</postal>

<phone>+1 516 286 1339</phone>
<email>brnstnd@acf10.nyu.edu</email>
</address>
</author>

<date year="1990" day="1" month="February" />
</front>

<seriesInfo value="1143" name="RFC" />
</reference>


<reference target2="reference.RFC.1144.xml" anchor="RFC1144">
<front>
<title abbrev="Compressing TCP/IP Headers">Compressing TCP/IP headers for low-speed serial links</title>
<author fullname="Van Jacobson" initials="V." surname="Jacobson">
<organization>Lawrence Berkeley Laboratory, Real Time Systems Group</organization>

<address>
<postal>
<street>Mail Stop 46A</street>
<city>Berkeley</city>
<region>CA</region>
<code>94720</code>
<country>US</country>
</postal>

<email>van@helios.ee.lbl.gov</email>
</address>
</author>

<date year="1990" day="1" month="February" />
</front>

<seriesInfo value="1144" name="RFC" />
</reference>


<reference target2="reference.RFC.1145.xml" anchor="RFC1145">
<front>
<title>TCP alternate checksum options</title>
<author fullname="Johnny Zweig" initials="J." surname="Zweig">
<organization>University of Illinois, Digital Computer Lab</organization>

<address>
<postal>
<street>1304 West Springfield Avenue</street>
<street>CAMPUS MC 258</street>
<city>Urbana</city>
<region>IL</region>
<code>61801</code>
<country>US</country>
</postal>

<phone>+1 217 333 7937</phone>
<email>zweig@CS.UIUC.EDU</email>
</address>
</author>

<author fullname="Craig Partridge" initials="C." surname="Partridge">
<organization>Bolt Beranek and Newman Inc.</organization>

<address>
<postal>
<street>50 Moulton Street</street>
<city>Cambridge</city>
<region>MA</region>
<code>02138</code>
<country>US</country>
</postal>

<phone>+1 617 873 2459</phone>
<email>craig@BBN.COM</email>
</address>
</author>

<date year="1990" day="1" month="February" />
</front>

<seriesInfo value="1145" name="RFC" />
</reference>


<reference target2="reference.RFC.1146.xml" anchor="RFC1146">
<front>
<title>TCP alternate checksum options</title>
<author fullname="Johnny Zweig" initials="J." surname="Zweig">
<organization>University of Illinois, Digital Computer Lab</organization>

<address>
<postal>
<street>1304 West Springfield Avenue</street>
<street>CAMPUS MC 258</street>
<city>Urbana</city>
<region>IL</region>
<code>61801</code>
<country>US</country>
</postal>

<phone>+1 217 333 7937</phone>
<email>zweig@CS.UIUC.EDU</email>
</address>
</author>

<author fullname="Craig Partridge" initials="C." surname="Partridge">
<organization>Bolt Beranek and Newman Inc.</organization>

<address>
<postal>
<street>50 Moulton Street</street>
<city>Cambridge</city>
<region>MA</region>
<code>02138</code>
<country>US</country>
</postal>

<phone>+1 617 873 2459</phone>
<email>craig@BBN.COM</email>
</address>
</author>

<date year="1990" day="1" month="March" />
</front>

<seriesInfo value="1146" name="RFC" />
</reference>


<reference target2="reference.RFC.1147.xml" anchor="RFC1147">
<front>
<title abbrev="FYI: Network Management Tool Catalog">FYI on a Network Management Tool Catalog: Tools for Monitoring and Debugging TCP/IP Internets and Interconnected Devices</title>
<author fullname="Robert H. Stine" initials="R." surname="Stine">
<organization>SPARTA, Inc.</organization>

<address>
<postal>
<street>7926 Jones Branch Drive</street>
<street>Suite 1070</street>
<city>McLean</city>
<region>VA</region>
<code>22102</code>
<country>US</country>
</postal>

<email>STINE@SPARTA.COM</email>
</address>
</author>

<date year="1990" day="1" month="April" />
</front>

<seriesInfo value="1147" name="RFC" />
</reference>


<reference target2="reference.RFC.1148.xml" anchor="RFC1148">
<front>
<title abbrev="Mapping X.400(88) and 822">Mapping between X.400(1988) / ISO 10021 and RFC 822</title>
<author fullname="Steve Kille" initials="S." surname="Kille">
<organization>University College London</organization>

<address>
<postal>
<street>Gower Street</street>
<city>London</city>
<region>England</region>
<code>WC1E 6BT</code>
<country>UK</country>
</postal>

<phone>+44 1 3807294</phone>
<email>S.Kille@Cs.Ucl.AC.UK</email>
</address>
</author>

<date year="1990" day="1" month="March" />
</front>

<seriesInfo value="1148" name="RFC" />
</reference>


<reference target2="reference.RFC.1149.xml" anchor="RFC1149">
<front>
<title abbrev="IP Datagrams on Avian Carriers">Standard for the transmission of IP datagrams on avian carriers</title>
<author fullname="David Waitzman" initials="D." surname="Waitzman">
<organization>Bolt Baranek and Newman Systems and Technologies Corporation,  Labs Division</organization>

<address>
<postal>
<street>10 Moulton Street</street>
<city>Cambridge</city>
<region>MA</region>
<code>02238</code>
<country>US</country>
</postal>

<phone>+1 617 873 4323</phone>
<email>dwaitzman@BBN.COM</email>
</address>
</author>

<date year="1990" day="1" month="April" />
</front>

<seriesInfo value="1149" name="RFC" />
</reference>


<reference target2="reference.RFC.1150.xml" anchor="RFC1150">
<front>
<title abbrev="F.Y.I. on F.Y.I.">FYI on FYI: Introduction to the FYI Notes</title>
<author fullname="Gary Scott Malkin" initials="G." surname="Malkin">
<organization>Proteon, Inc.</organization>

<address>
<postal>
<street>2 Technology Drive</street>
<city>Westborough</city>
<region>MA</region>
<code>01581-5008</code>
<country>US</country>
</postal>

<phone>+1 508 898 2800</phone>
<email>gmalkin@proteon.com</email>
</address>
</author>

<author fullname="Joyce K. Reynolds" initials="J." surname="Reynolds">
<organization>University of Southern California (USC), Information Sciences Institute (ISI)</organization>

<address>
<postal>
<street>4676 Admiralty Way</street>
<city>Marina del Rey</city>
<region>CA</region>
<code>90292-6695</code>
<country>US</country>
</postal>

<phone>+1 213 822 1511</phone>
<email>jkrey@isi.edu</email>
</address>
</author>

<date year="1990" day="1" month="March" />
</front>

<seriesInfo value="1150" name="RFC" />
</reference>


<reference target2="reference.RFC.1151.xml" anchor="RFC1151">
<front>
<title abbrev="RDP - Version 2">Version 2 of the Reliable Data Protocol (RDP)</title>
<author fullname="Craig Partridge" initials="C." surname="Partridge">
<organization>Bolt Beranek and Newman Inc., Systems and Technologies</organization>

<address>
<postal>
<street>50 Moulton Street</street>
<city>Cambridge</city>
<region>MA</region>
<code>02138</code>
<country>US</country>
</postal>

<phone>+1 617 873 2459</phone>
<email>craig@BBN.COM</email>
</address>
</author>

<author fullname="Robert Hinden" initials="R." surname="Hinden">
<organization>Bolt Beranek and Newman Inc., Communications Corp.</organization>

<address>
<postal>
<street>50 Moulton Street</street>
<city>Cambridge</city>
<region>MA</region>
<code>02238</code>
<country>US</country>
</postal>

<phone>+1 617 873 3757</phone>
<email>HINDEN@BBN.COM</email>
</address>
</author>

<date year="1990" day="1" month="April" />
</front>

<seriesInfo value="1151" name="RFC" />
</reference>


<reference target2="reference.RFC.1152.xml" anchor="RFC1152">
<front>
<title abbrev="IRSG Workshop Report">Workshop report: Internet research steering group workshop on very-high-speed networks</title>
<author fullname="Craig Partridge" initials="C." surname="Partridge">
<organization>Bolt Beranek and Newman Systems and Technologies</organization>

<address>
<postal>
<street>50 Moulton Street</street>
<city>Cambridge</city>
<region>MA</region>
<code>02138</code>
<country>US</country>
</postal>

<phone>+1 617 873 2459</phone>
<email>craig@BBN.COM</email>
</address>
</author>

<date year="1990" day="1" month="April" />
</front>

<seriesInfo value="1152" name="RFC" />
</reference>


<reference target2="reference.RFC.1153.xml" anchor="RFC1153">
<front>
<title>Digest message format</title>
<author fullname="Frank J. Wancho" initials="F." surname="Wancho">
<organization>White Sands Missile Range (WSMR), USAISC-White Sands</organization>

<address>
<postal>
<street>ASQNC-TWS-SS-C (F. Wancho, Building 1512)</street>
<city>White Sands</city>
<region>NM</region>
<code>88002-5506</code>
<country>US</country>
</postal>

<phone>+1 505 678 3009</phone>
<email>WANCHO@WSMR-SIMTEL20.ARMY.MIL</email>
</address>
</author>

<date year="1990" day="1" month="April" />
</front>

<seriesInfo value="1153" name="RFC" />
</reference>


<reference target2="reference.RFC.1154.xml" anchor="RFC1154">
<front>
<title>Encoding header field for internet messages</title>
<author fullname="David Robinson" initials="D." surname="Robinson">
<organization>Prime Computer, Inc.</organization>

<address>
<postal>
<street>500 Old Connecticut Path</street>
<city>Framingham</city>
<region>MA</region>
<code>01701</code>
<country>US</country>
</postal>

<phone>+1 508 879 2960 x1774</phone>
<email>DRB@Relay.Prime.COM</email>
</address>
</author>

<author fullname="Robert Ullmann" initials="R." surname="Ullmann">
<organization>Prime Computer, Inc.</organization>

<address>
<postal>
<street>500 Old Connecticut Path</street>
<city>Framingham</city>
<region>MA</region>
<code>01701</code>
<country>US</country>
</postal>

<phone>+1 508 879 2960 x1736</phone>
<email>Ariel@Relay.Prime.COM</email>
</address>
</author>

<date year="1990" day="1" month="April" />
</front>

<seriesInfo value="1154" name="RFC" />
</reference>


<reference target2="reference.RFC.1155.xml" anchor="RFC1155">
<front>
<title abbrev="SMI">Structure and identification of management information for TCP/IP-based internets</title>
<author fullname="Marshall T. Rose" initials="M." surname="Rose">
<organization>Performance Systems International, Inc.</organization>

<address>
<postal>
<street>P.O. Box 391776</street>
<city>Mountain View</city>
<region>CA</region>
<code>94039</code>
<country>US</country>
</postal>

<phone>+1 415 961 3380</phone>
<email>mrose@PSI.COM</email>
</address>
</author>

<author fullname="Keith McCloghrie" initials="K." surname="McCloghrie">
<organization>Hughes LAN Systems, The Wollongong Group</organization>

<address>
<postal>
<street>1129 San Antonio Road</street>
<city>Palo Alto</city>
<region>CA</region>
<code>94303</code>
<country>US</country>
</postal>

<phone>+1 415 962 7160</phone>
<email>sytek!kzm@HPLABS.HP.COM</email>
</address>
</author>

<date year="1990" day="1" month="May" />
</front>

<seriesInfo value="16" name="STD" />
<seriesInfo value="1155" name="RFC" />
</reference>


<reference target2="reference.RFC.1156.xml" anchor="RFC1156">
<front>
<title abbrev="MIB">Management Information Base for network management of TCP/IP-based internets</title>
<author fullname="Keith McCloghrie" initials="K." surname="McCloghrie">
<organization>Hughes LAN Systems, The Wollongong Group</organization>

<address>
<postal>
<street>1129 San Antonio Road</street>
<city>Palo Alto</city>
<region>CA</region>
<code>94303</code>
<country>US</country>
</postal>

<phone>+1 415 962 7160</phone>
<email>sytek!kzm@HPLABS.HP.COM</email>
</address>
</author>

<author fullname="Marshall T. Rose" initials="M." surname="Rose">
<organization>Performance Systems International, Inc. (PSI), PSI California Office</organization>

<address>
<postal>
<street>P.O. Box 391776</street>
<city>Mountain View</city>
<region>CA</region>
<code>94039</code>
<country>US</country>
</postal>

<phone>+1 415 961 3380</phone>
<email>mrose@PSI.COM</email>
</address>
</author>

<date year="1990" day="1" month="May" />
</front>

<seriesInfo value="1156" name="RFC" />
</reference>


<reference target2="reference.RFC.1157.xml" anchor="RFC1157">
<front>
<title abbrev="SNMP">Simple Network Management Protocol (SNMP)</title>
<author fullname="Jeffrey D. Case" initials="J.D." surname="Case">
<organization>Simple Network Management Protocol (SNMP) Research</organization>

<address>
<postal>
<street>P.O. Box 8593</street>
<city>Knoxville</city>
<region>TN</region>
<code>37996-4800</code>
<country>US</country>
</postal>

<phone>+1 615 573 1434</phone>
<email>case@CS.UTK.EDU</email>
</address>
</author>

<author fullname="Mark Fedor" initials="M." surname="Fedor">
<organization>Performance Systems International</organization>

<address>
<postal>
<street>125 Jordan Road</street>
<street>Rensselaer Technology Park</street>
<city>Troy</city>
<region>NY</region>
<code>12180</code>
<country>US</country>
</postal>

<phone>+1 518 283 8860</phone>
<email>fedor@patton.NYSER.NET</email>
</address>
</author>

<author fullname="Martin Lee Schoffstall" initials="M.L." surname="Schoffstall">
<organization>Performance Systems International</organization>

<address>
<postal>
<street>165 Jordan Road</street>
<street>Rensselaer Technology Park</street>
<city>Troy</city>
<region>NY</region>
<code>12180</code>
<country>US</country>
</postal>

<phone>+1 518 283 8860</phone>
<email>schoff@NISC.NYSER.NET</email>
</address>
</author>

<author fullname="James R. Davin" initials="J.R." surname="Davin">
<organization>Massachusetts Institute of Technology (MIT), Laboratory for Computer Science</organization>

<address>
<postal>
<street>545 Technology Square</street>
<street>NE43-507</street>
<city>Cambridge</city>
<region>MA</region>
<code>02139</code>
<country>US</country>
</postal>

<phone>+1 617 253 6020</phone>
<email>jrd@ptt.lcs.mit.edu</email>
</address>
</author>

<date year="1990" day="1" month="May" />
</front>

<seriesInfo value="15" name="STD" />
<seriesInfo value="1157" name="RFC" />
</reference>


<reference target2="reference.RFC.1158.xml" anchor="RFC1158">
<front>
<title abbrev="MIB II">Management Information Base for network management of TCP/IP-based internets: MIB-II</title>
<author fullname="Marshall T. Rose" initials="M." surname="Rose">
<organization>Performance Systems International, Inc.</organization>

<address>
<postal>
<street>P.O. Box 391776</street>
<city>Mountain View</city>
<region>CA</region>
<code>94039</code>
<country>US</country>
</postal>

<phone>+1 415 961 3380</phone>
<email>mrose@PSI.COM</email>
</address>
</author>

<date year="1990" day="1" month="May" />
</front>

<seriesInfo value="1158" name="RFC" />
</reference>


<reference target2="reference.RFC.1159.xml" anchor="RFC1159">
<front>
<title>Message Send Protocol</title>
<author fullname="Russell Nelson" initials="R." surname="Nelson">
<organization>Clarkson University, Educational Computing System</organization>

<address>
<postal>
<street />
<city>Potsdam</city>
<region>NY</region>
<code>13699-5730</code>
<country>US</country>
</postal>

<phone>+1 315 268 6455</phone>
<email>nelson@sun.soe.clarkson.edu</email>
</address>
</author>

<date year="1990" day="1" month="June" />
</front>

<seriesInfo value="1159" name="RFC" />
</reference>


<reference target2="reference.RFC.1160.xml" anchor="RFC1160">
<front>
<title abbrev="The IAB">Internet Activities Board</title>
<author fullname="Vinton G. Cerf" initials="V." surname="Cerf">
<organization>Corporation for National Research Initiatives (CNRI)</organization>

<address>
<postal>
<street>1895 Preston White Drive</street>
<street>Suite 100</street>
<city>Reston</city>
<region>VA</region>
<code>22091</code>
<country>US</country>
</postal>

<phone>+1 703 620 8990</phone>
<email>VCERF@NRI.RESTON.VA.US</email>
</address>
</author>

<date year="1990" day="1" month="May" />
</front>

<seriesInfo value="1160" name="RFC" />
</reference>


<reference target2="reference.RFC.1161.xml" anchor="RFC1161">
<front>
<title>SNMP over OSI</title>
<author fullname="Marshall T. Rose" initials="M." surname="Rose">
<organization>Performance Systems International, Inc.</organization>

<address>
<postal>
<street>P.O. Box 391776</street>
<city>Mountain View</city>
<region>CA</region>
<code>94039</code>
<country>US</country>
</postal>

<phone>+1 415 961 3380</phone>
<email>mrose@PSI.COM</email>
</address>
</author>

<date year="1990" day="1" month="June" />
</front>

<seriesInfo value="1161" name="RFC" />
</reference>


<reference target2="reference.RFC.1162.xml" anchor="RFC1162">
<front>
<title abbrev="CLNS MIB">Connectionless Network Protocol (ISO 8473) and End System to Intermediate System (ISO 9542) Management Information Base</title>
<author fullname="Greg Satz" initials="G." surname="Satz">
<organization>cisco Systems, Inc.</organization>

<address>
<postal>
<street>1350 Willow Road</street>
<city>Menlo Park</city>
<region>CA</region>
<code>94025</code>
<country>US</country>
</postal>

<phone>+1 415 326 1941</phone>
<email>Satz@CISCO.COM</email>
</address>
</author>

<date year="1990" day="1" month="June" />
</front>

<seriesInfo value="1162" name="RFC" />
</reference>


<reference target2="reference.RFC.1163.xml" anchor="RFC1163">
<front>
<title abbrev="BGP">Border Gateway Protocol (BGP)</title>
<author fullname="Kirk Lougheed" initials="K." surname="Lougheed">
<organization>cisco Systems, Inc.</organization>

<address>
<postal>
<street>1525 O'Brien Drive</street>
<city>Menlo Park</city>
<region>CA</region>
<code>94025</code>
<country>US</country>
</postal>

<phone>+1 415 326 1941</phone>
<email>LOUGHEED@CISCO.COM</email>
</address>
</author>

<author fullname="Yakov Rekhter" initials="Y." surname="Rekhter">
<organization>International Business Machines Corporation (IBM), T.J. Watson Research Center</organization>

<address>
<postal>
<street>P.O. Box 218</street>
<city>Yorktown Heights</city>
<region>NY</region>
<code>10598</code>
<country>US</country>
</postal>

<phone>+1 914 945 3896</phone>
<email>YAKOV@IBM.COM</email>
</address>
</author>

<date year="1990" day="1" month="June" />
</front>

<seriesInfo value="1163" name="RFC" />
</reference>


<reference target2="reference.RFC.1164.xml" anchor="RFC1164">
<front>
<title abbrev="BGP - Application">Application of the Border Gateway Protocol in the Internet</title>
<author fullname="Jeffrey C. Honig" initials="J." surname="Honig">
<organization>Cornell University, Theory Center</organization>

<address>
<postal>
<street>265 Olin Hall</street>
<city>Ithaca</city>
<region>NY</region>
<code>14853-5201</code>
<country>US</country>
</postal>

<phone>+1 607 255 8686</phone>
<email>JCH@TCGOULD.TN.CORNELL.EDU</email>
</address>
</author>

<author fullname="Dave Katz" initials="D." surname="Katz">
<organization>Merit/NSFNET</organization>

<address>
<postal>
<street>1075 Beal Ave.</street>
<city>Ann Arbor</city>
<region>MI</region>
<code>48109</code>
<country>US</country>
</postal>

<phone>+1 313 763 4898</phone>
<email>DKATZ@MERIT.EDU</email>
</address>
</author>

<author fullname="Matt Mathis" initials="M." surname="Mathis">
<organization>Pittsburgh Supercomputing Center</organization>

<address>
<postal>
<street>4400 Fifth Ave.</street>
<city>Pittsburgh</city>
<region>PA</region>
<code>15213</code>
<country>US</country>
</postal>

<phone>+1 412 268 3319</phone>
<email>MATHIS@FARADAY.ECE.CMU.EDU</email>
</address>
</author>

<author fullname="Yakov Rekhter" initials="Y." surname="Rekhter">
<organization>IBM Corporation, T.J. Watson Research Center</organization>

<address>
<postal>
<street>P.O. Box 218</street>
<city>Yorktown Heights</city>
<region>NY</region>
<code>10598</code>
<country>US</country>
</postal>

<phone>+1 914 945 3896</phone>
<email>YAKOV@IBM.COM</email>
</address>
</author>

<author fullname="Jie Yun (Jessica) Yu" initials="J." surname="Yu">
<organization>Merit/NSFNET</organization>

<address>
<postal>
<street>1075 Beal Ave.</street>
<city>Ann Arbor</city>
<region>MI</region>
<code>48109</code>
<country>US</country>
</postal>

<phone>+1 313 936 3000</phone>
<email>JYY@MERIT.EDU</email>
</address>
</author>

<date year="1990" day="1" month="June" />
</front>

<seriesInfo value="1164" name="RFC" />
</reference>


<reference target2="reference.RFC.1165.xml" anchor="RFC1165">
<front>
<title abbrev="NTP over OSI">Network Time Protocol (NTP) over the OSI Remote Operations Service</title>
<author fullname="Jon Crowcroft" initials="J." surname="Crowcroft">
<organization>University College London, Computer Science Department</organization>

<address>
<postal>
<street>Gower Street</street>
<city>London</city>
<region>England</region>
<code>WC1E 6BT</code>
<country>UK</country>
</postal>

<email>JON@CS.UCL.AC.UK</email>
</address>
</author>

<author fullname="Julian P. Onions" initials="J." surname="Onions">
<organization>Nottingham University, Computer Science Department</organization>

<address>
<postal>
<street>University Park</street>
<city>Nottingham</city>
<region>England</region>
<code>NG7 2RD</code>
<country>UK</country>
</postal>

<email>JPO@CS.NOTT.AC.UK</email>
</address>
</author>

<date year="1990" day="1" month="June" />
</front>

<seriesInfo value="1165" name="RFC" />
</reference>


<reference target2="reference.RFC.1166.xml" anchor="RFC1166">
<front>
<title abbrev="Internet Numbers">Internet numbers</title>
<author fullname="Sue Kirkpatrick" initials="S." surname="Kirkpatrick">
<organization>SRI International, Network Information Systems Center</organization>

<address>
<postal>
<street>333 Ravenswood Avenue</street>
<street>EJ217</street>
<city>Menlo Park</city>
<region>CA</region>
<code>94025</code>
<country>US</country>
</postal>

<phone>+1 415 859 5539</phone>
<email>SUE@NIC.DDN.MIL</email>
</address>
</author>

<author fullname="Mary Stahl" initials="M." surname="Stahl">
<organization>SRI International, Network Information Systems Center</organization>

<address>
<postal>
<street>333 Ravenswood Avenue</street>
<street>EJ296</street>
<city>Menlo Park</city>
<region>CA</region>
<code>94025</code>
<country>US</country>
</postal>

<phone>+1 415 859 4775</phone>
<email>STAHL@NIC.DDN.MIL</email>
</address>
</author>

<author fullname="Mimi Recker" initials="M." surname="Recker">
<organization>SRI International, Network Information Systems Center</organization>

<address>
<postal>
<street>333 Ravenswood Avenue</street>
<street>EJ268</street>
<city>Menlo Park</city>
<region>CA</region>
<code>94025</code>
<country>US</country>
</postal>

<phone>+1 415 859 2110</phone>
<email>MIMI@NIC.DDN.MIL</email>
</address>
</author>

<date year="1990" day="1" month="July" />
</front>

<seriesInfo value="1166" name="RFC" />
</reference>


<reference target2="reference.RFC.1167.xml" anchor="RFC1167">
<front>
<title abbrev="NREN">Thoughts on the National Research and Education Network</title>
<author fullname="Vinton G. Cerf" initials="V." surname="Cerf">
<organization>Corporation for National Research Initiatives (CNRI)</organization>

<address>
<postal>
<street>1895 Preston White Drive</street>
<street>Suite 100</street>
<city>Reston</city>
<region>VA</region>
<code>22091</code>
<country>US</country>
</postal>

<phone>+1 703 620 8990</phone>
<email>vcerf@NRI.Reston.VA.US</email>
</address>
</author>

<date year="1990" day="1" month="July" />

<abstract>
<t>This contribution seeks to outline and call attention to some of the major factors which will influence the form and structure of a National Research and Education Network (NREN).  It is implicitly assumed that the system will emerge from the existing Internet.</t>
</abstract>
</front>

<seriesInfo value="1167" name="RFC" />
</reference>


<reference target2="reference.RFC.1168.xml" anchor="RFC1168">
<front>
<title abbrev="Intermail and Commercial Mail Relay Services">Intermail and Commercial Mail Relay services</title>
<author fullname="Ann Westine" initials="A." surname="Westine">
<organization>University of Southern California (USC), Information Sciences Instutite</organization>

<address>
<postal>
<street>4676 Admiralty Way</street>
<city>Marina del Rey</city>
<region>CA</region>
<code>90292-6695</code>
<country>US</country>
</postal>

<phone>+1 213 822 1511</phone>
<email>Westine@ISI.EDU</email>
</address>
</author>

<author fullname="Annette DeSchon" initials="A." surname="DeSchon">
<organization>University of Southern California (USC), Information Sciences Instutite</organization>

<address>
<postal>
<street>4676 Admiralty Way</street>
<city>Marina del Rey</city>
<region>CA</region>
<code>90292-6695</code>
<country>US</country>
</postal>

<phone>+1 213 822 1511</phone>
<email>DeSchon@ISI.EDU</email>
</address>
</author>

<author fullname="Jon Postel" initials="J." surname="Postel">
<organization>University of Southern California (USC), Information Sciences Instutite</organization>

<address>
<postal>
<street>4676 Admiralty Way</street>
<city>Marina del Rey</city>
<region>CA</region>
<code>90292-6695</code>
<country>US</country>
</postal>

<phone>+1 213 822 1511</phone>
<email>Postel@ISI.EDU</email>
</address>
</author>

<author fullname="Craig E. Ward" initials="C." surname="Ward">
<organization>University of Southern California (USC), Information Sciences Instutite</organization>

<address>
<postal>
<street>4676 Admiralty Way</street>
<city>Marina del Rey</city>
<region>CA</region>
<code>90292-6695</code>
<country>US</country>
</postal>

<phone>+1 213 822 1511</phone>
<email>Ward@ISI.EDU</email>
</address>
</author>

<date year="1990" day="1" month="July" />
</front>

<seriesInfo value="1168" name="RFC" />
</reference>


<reference target2="reference.RFC.1169.xml" anchor="RFC1169">
<front>
<title>Explaining the role of GOSIP</title>
<author fullname="Vinton G. Cerf" initials="V." surname="Cerf">
<organization>Corporation for National Research Initiatives</organization>

<address>
<postal>
<street>1895 Preston White Drive</street>
<street>Suite 100</street>
<city>Reston</city>
<region>VA</region>
<code>22091</code>
<country>US</country>
</postal>

<phone>+1 703 620 8990</phone>
<email>vcerf@nri.reston.va.us</email>
</address>
</author>

<author fullname="Kevin L. Mills" initials="K." surname="Mills">
<organization>National Institute of Standards and Technology (NIST)</organization>

<address>
<postal>
<street>Building 225</street>
<street>Room B217</street>
<city>Gaithersburg</city>
<region>MD</region>
<code>20899</code>
<country>US</country>
</postal>

<phone>+1 301 975 3618</phone>
<email>MILLS@ECF.NCSL.NIST.GOV</email>
</address>
</author>

<date year="1990" day="1" month="August" />

<abstract>
<t>The Federal Networking Council (FNC), the Internet Activities Board (IAB), and the Internet Engineering Task Force (IETF) have a firm commitment to responsible integration of OSI based upon sound network planning.  This implies that OSI will be added to the Internet without sacrificing services now available to existing Internet users, and that a multi-protocol environment will exist in the Internet for a prolonged period.  Planning is underway within the Internet community to enable integration of OSI, coexistence of OSI with TCP/IP, and interoperability between OSI and TCP/IP.</t>

<t>The U.S. Government OSI Profile (GOSIP) is a necessary tool for planning OSI integration.  However, as the August 1990 requirement date for GOSIP compliance approaches, concern remains as to how GOSIP should be applied to near-term network planning.</t>

<t>The intent of this statement is to help explain the role and applicability of the GOSIP document, as well as to emphasize the government's commitment to an integrated interoperable OSI environment based on responsible planning.</t>
</abstract>
</front>

<seriesInfo value="1169" name="RFC" />
</reference>


<reference target2="reference.RFC.1170.xml" anchor="RFC1170">
<front>
<title>Public key standards and licenses</title>
<author fullname="Robert B. Fougner" initials="R." surname="Fougner">
<organization>Public Key Partners</organization>

<address>
<postal>
<street>130 B Kifer Court</street>
<city>Sunnyvale</city>
<region>CA</region>
<code>94086</code>
<country>US</country>
</postal>

<phone>+1 408 735 6779</phone>
</address>
</author>

<date year="1991" day="1" month="January" />
</front>

<seriesInfo value="1170" name="RFC" />
</reference>


<reference target2="reference.RFC.1171.xml" anchor="RFC1171">
<front>
<title abbrev="Point-to-Point Protocol">Point-to-Point Protocol for the transmission of multi-protocol datagrams over Point-to-Point links</title>
<author fullname="Drew D. Perkins" initials="D." surname="Perkins">
<organization>Carnegie Mellon University (CMU), Networking and Communications</organization>

<address>
<postal>
<street />
<city>Pittsburgh</city>
<region>PA</region>
<code>15213</code>
<country>US</country>
</postal>

<phone>+1 412 268 8576</phone>
<email>ddp@andrew.cmu.edu</email>
</address>
</author>

<date year="1990" day="1" month="July" />

<abstract>
<t>The Point-to-Point Protocol (PPP) provides a method for transmitting datagrams over serial point-to-point links.  PPP is composed of three parts:</t>

<t>1. A method for encapsulating datagrams over serial links.</t>

<t>2. An extensible Link Control Protocol (LCP).</t>

<t>3. A family of Network Control Protocols (NCP) for establishing and configuring different network-layer protocols.</t>

<t>This document defines the encapsulation scheme, the basic LCP, and an NCP for establishing and configuring the Internet Protocol (IP) (called the IP Control Protocol, IPCP).</t>

<t>The options and facilities used by the LCP and the IPCP are defined in separate documents.  Control protocols for configuring and utilizing other network-layer protocols besides IP (e.g., DECNET, OSI) are expected to be developed as needed.</t>
</abstract>
</front>

<seriesInfo value="1171" name="RFC" />
</reference>


<reference target2="reference.RFC.1172.xml" anchor="RFC1172">
<front>
<title abbrev="PPP Initial Options">Point-to-Point Protocol (PPP) initial configuration options</title>
<author fullname="Drew D. Perkins" initials="D." surname="Perkins">
<organization>Carnegie Mellon University</organization>

<address>
<postal>
<city>Pittsburgh</city>
<region>PA</region>
<code>15213</code>
<country>US</country>
</postal>

<phone>+1 412 268 8576</phone>
<email>ddp@andrew.cmu.edu</email>
</address>
</author>

<author fullname="Russ Hobby" initials="R." surname="Hobby">
<organization>University of California, Davis</organization>

<address>
<postal>
<city>Davis</city>
<region>CA</region>
<code>95616</code>
<country>US</country>
</postal>

<phone>+1 916 752 0236</phone>
<email>rdhobby@ucdavis.edu</email>
</address>
</author>

<date year="1990" day="1" month="July" />

<abstract>
<t>The Point-to-Point Protocol (PPP) provides a method for transmitting datagrams over serial point-to-point links.  PPP is composed of</t>

<t>1) a method for encapsulating datagrams over serial links,
      2) an extensible Link Control Protocol (LCP), and
      3) a family of Network Control Protocols (NCP) for establishing and configuring different network-layer protocols.</t>

<t>The PPP encapsulating scheme, the basic LCP, and an NCP for controlling and establishing the Internet Protocol (IP) (called the IP Control Protocol, IPCP) are defined in The Point-to-Point Protocol (PPP)
.</t>

<t>This document defines the intial options used by the LCP and IPCP. It also defines a method of Link Quality Monitoring and a simple authentication scheme.</t>
</abstract>
</front>

<seriesInfo value="1172" name="RFC" />
</reference>


<reference target2="reference.RFC.1173.xml" anchor="RFC1173">
<front>
<title abbrev="Responsibilities of Host and Network Managers">Responsibilities of host and network managers: A summary of the "oral tradition" of the Internet</title>
<author fullname="James B. VanBokkelen" initials="J." surname="VanBokkelen">
<organization>FTP Software Inc.</organization>

<address>
<postal>
<street>26 Princess St.</street>
<city>Wakefield</city>
<region>MA</region>
<code>01880</code>
<country>US</country>
</postal>

<phone>+1 617 246 0900</phone>
<email>jbvb@ftp.com</email>
</address>
</author>

<date year="1990" day="1" month="August" />
</front>

<seriesInfo value="1173" name="RFC" />
</reference>


<reference target2="reference.RFC.1174.xml" anchor="RFC1174">
<front>
<title abbrev="Identifier Assignment and Connected Status">IAB recommended policy on distributing internet identifier assignment and IAB recommended policy change to internet "connected" status</title>
<author fullname="Vinton G. Cerf" initials="V.G." surname="Cerf">
<organization>Corporation for National Research Initiatives (CNRI)</organization>

<address>
<postal>
<street>1895 Preston White Drive</street>
<street>Suite 100</street>
<city>Reston</city>
<region>VA</region>
<code>22091</code>
<country>US</country>
</postal>

<phone>+1 703 620 8990</phone>
<email>vcerf@nri.reston.va.us</email>
</address>
</author>

<date year="1990" day="1" month="August" />
</front>

<seriesInfo value="1174" name="RFC" />
</reference>


<reference target2="reference.RFC.1175.xml" anchor="RFC1175">
<front>
<title abbrev="FYI - Bibliography">FYI on where to start: A bibliography of internetworking information</title>
<author fullname="Karen Bowers" initials="K." surname="Bowers">
<organization>Corporation for National Research Initiatives (CNRI)</organization>

<address>
<postal>
<street>1895 Preston White Drive</street>
<street>Suite 100</street>
<city>Reston</city>
<region>VA</region>
<code>22091</code>
<country>US</country>
</postal>

<phone>+1 703 582 8990</phone>
<email>kbowers@nri.reston.va.us</email>
</address>
</author>

<author fullname="Tracy LaQuey" initials="T." surname="LaQuey">
<organization>University of Texas, Austin, Computation Center</organization>

<address>
<postal>
<street>M/S COM 1</street>
<city>Austin</city>
<region>TX</region>
<code>78712</code>
<country>US</country>
</postal>

<phone>+1 512 471 3241</phone>
<email>tracy@nic.the.net</email>
</address>
</author>

<author fullname="Joyce K. Reynolds" initials="J." surname="Reynolds">
<organization>University of Southern California (USC), Information Sciences Institute</organization>

<address>
<postal>
<street>4676 Admiralty Way #1001</street>
<city>Marina del Rey</city>
<region>CA</region>
<code>90292-6695</code>
<country>US</country>
</postal>

<phone>+1 213 822 1511</phone>
<email>jkrey@isi.edu</email>
</address>
</author>

<author fullname="Karen Roubicek" initials="K." surname="Roubicek">
<organization>Bolt Baranek and Newman Systems and Technologies, NSF Network Service Center</organization>

<address>
<postal>
<street>10 Moulton Street</street>
<city>Cambridge</city>
<region>MA</region>
<code>02138</code>
<country>US</country>
</postal>

<phone>+1 617 873 3361</phone>
<email>roubicek@nnsc.nsf.net</email>
</address>
</author>

<author fullname="Mary Stahl" initials="M." surname="Stahl">
<organization>SRI International, Network Information Systems Center</organization>

<address>
<postal>
<street>333 Ravenswood Avenue</street>
<street>Rm EJ 296</street>
<city>Menlo Park</city>
<region>CA</region>
<code>94025</code>
<country>US</country>
</postal>

<phone>+1 415 859 4775</phone>
<email>stahl@nisc.sri.com</email>
</address>
</author>

<author fullname="Aileen Yuan" initials="A." surname="Yuan">
<organization>The MITRE Corporation</organization>

<address>
<postal>
<street>7525 Colshire Drive</street>
<street>MS W422</street>
<city>McLean</city>
<region>VA</region>
<code>22102</code>
<country>US</country>
</postal>

<phone>+1 703 883 7023</phone>
<email>aileen@gateway.mitre.org</email>
</address>
</author>

<date year="1990" day="1" month="August" />

<abstract>
<t>The intent of this bibliography is to offer a representative collection of resources of information that will help the reader become familiar with the concepts of internetworking.  It is meant to be a starting place for further research.  There are references to other sources of information for those users wishing to pursue, in greater depth, the issues and complexities of the current networking environment.</t>
</abstract>
</front>

<seriesInfo value="1175" name="RFC" />
</reference>


<reference target2="reference.RFC.1176.xml" anchor="RFC1176">
<front>
<title abbrev="IMAP2">Interactive Mail Access Protocol: Version 2</title>
<author fullname="Mark R. Crispin" initials="M." surname="Crispin">
<organization>Panda Programming</organization>

<address>
<postal>
<street>6158 Lariat Loop NE</street>
<city>Bainbridge Island</city>
<region>WA</region>
<code>98110-2020</code>
<country>US</country>
</postal>

<phone>+1 206 842 2385</phone>
<email>mrc@Tomobiki-Cho.CAC.Washington.EDU</email>
</address>
</author>

<date year="1990" day="1" month="August" />
</front>

<seriesInfo value="1176" name="RFC" />
</reference>


<reference target2="reference.RFC.1177.xml" anchor="RFC1177">
<front>
<title abbrev="FYI Q/A - for New Internet Users">FYI on Questions and Answers: Answers to commonly asked "new internet user" questions</title>
<author fullname="Gary Scott Malkin" initials="G." surname="Malkin">
<organization>FTP Software, Inc.</organization>

<address>
<postal>
<street>26 Princess Street</street>
<city>Wakefield</city>
<region>MA</region>
<code>01880</code>
<country>US</country>
</postal>

<phone>+1 617 246 0900</phone>
<email>gmalkin@ftp.com</email>
</address>
</author>

<author fullname="April N. Marine" initials="A." surname="Marine">
<organization>SRI International, Network Information Systems Center</organization>

<address>
<postal>
<street>333 Ravenswood Avenue</street>
<street>EJ294</street>
<city>Menlo Park</city>
<region>CA</region>
<code>94025</code>
<country>US</country>
</postal>

<phone>+1 415 859 5318</phone>
<email>APRIL@NIC.DDN.MIL</email>
</address>
</author>

<author fullname="Joyce K. Reynolds" initials="J." surname="Reynolds">
<organization>USC/Information Sciences Institute</organization>

<address>
<postal>
<street>4676 Admiralty Way</street>
<city>Marina del Rey</city>
<region>CA</region>
<code>90292-6695</code>
<country>US</country>
</postal>

<phone>+1 213 822 1511</phone>
<email>jkrey@isi.edu</email>
</address>
</author>

<date year="1990" day="1" month="August" />
</front>

<seriesInfo value="1177" name="RFC" />
</reference>


<reference target2="reference.RFC.1178.xml" anchor="RFC1178">
<front>
<title abbrev="Name Your Computer">Choosing a name for your computer</title>
<author fullname="Don Libes" initials="D." surname="Libes">
<organization>National Institute of Standards and Technology (NIST), Integrated Systems Group</organization>

<address>
<postal>
<street />
<city>Gaithersburg</city>
<region>MD</region>
<code>20899</code>
<country>US</country>
</postal>

<phone>+1 301 975 3535</phone>
<email>libes@cme.nist.gov</email>
</address>
</author>

<date year="1990" day="1" month="August" />

<abstract>
<t>In order to easily distinguish between multiple computers, we give them names.  Experience has taught us that it is as easy to choose bad names as it is to choose good ones.  This essay presents
 guidelines for deciding what makes a name good or bad.</t>

<t>Keywords: domain name system, naming conventions, computer administration, computer network management</t>
</abstract>
</front>

<seriesInfo value="1178" name="RFC" />
</reference>


<reference target2="reference.RFC.1179.xml" anchor="RFC1179">
<front>
<title abbrev="LPR">Line printer daemon protocol</title>
<author fullname="Leo J. McLaughlin III" initials="L." surname="McLaughlin">
<organization>The Wollongong Group</organization>

<address>
<postal>
<street>1129 San Antonio Road</street>
<city>Palo Alto</city>
<region>CA</region>
<code>94303</code>
<country>US</country>
</postal>

<phone>+1 415 962 7100</phone>
<email>ljm@twg.com</email>
</address>
</author>

<date year="1990" day="1" month="August" />
</front>

<seriesInfo value="1179" name="RFC" />
</reference>


<reference target2="reference.RFC.1180.xml" anchor="RFC1180">
<front>
<title>TCP/IP tutorial</title>
<author fullname="Theodore John Socolofsky" initials="T." surname="Socolofsky">
<organization>Spider Systems Limited</organization>

<address>
<postal>
<street>Stanwell Street</street>
<street>Spider Park</street>
<city>Edinburgh</city>
<region>Scotland</region>
<code>EH6 5NG</code>
<country>UK</country>
</postal>

<phone>+44 31 5549424</phone>
<facsimile>+44 31 5540649</facsimile>
<email>TEDS@SPIDER.CO.UK</email>
</address>
</author>

<author fullname="Claudia Jeanne Kale" initials="C." surname="Kale">
<organization />

<address>
<postal>
<street>12 Gosford Place</street>
<city>Edinburgh</city>
<region>England</region>
<code>EH6 4BJ</code>
<country>UK</country>
</postal>

<phone>+44 31 5547432</phone>
<email>CLAUDIAK@SPIDER.CO.UK</email>
</address>
</author>

<date year="1991" day="1" month="January" />
</front>

<seriesInfo value="1180" name="RFC" />
</reference>


<reference target2="reference.RFC.1181.xml" anchor="RFC1181">
<front>
<title>RIPE Terms of Reference</title>
<author fullname="Rob Blokzijl" initials="R." surname="Blokzijl">
<organization>Reseaux IP Europeens (RIPE)/NIKHEF</organization>

<address>
<postal>
<street>P.O.B. 41882</street>
<city>Amsterdam</city>
<region />
<code>NL-1009 DB</code>
<country>NL</country>
</postal>

<phone>+31 20 5920413</phone>
<email>k13@nikhef.nl</email>
</address>
</author>

<date year="1990" day="1" month="September" />
</front>

<seriesInfo value="1181" name="RFC" />
</reference>


<reference target2="reference.RFC.1183.xml" anchor="RFC1183">
<front>
<title>New DNS RR Definitions</title>
<author fullname="Craig F. Everhart" initials="C." surname="Everhart">
<organization>Transarc Corporation</organization>

<address>
<postal>
<street>707 Grant Street</street>
<street>The Gulf Tower</street>
<city>Pittsburgh</city>
<region>PA</region>
<code>15219</code>
<country>US</country>
</postal>

<phone>+1 412 338 4467</phone>
<email>Craig_Everhart@transarc.com</email>
</address>
</author>

<author fullname="Louis A. Mamakos" initials="L." surname="Mamakos">
<organization>University of Maryland, Network Infrastructure Group</organization>

<address>
<postal>
<street />
<city>College Park</city>
<region>MD</region>
<code>20742-2411</code>
<country>US</country>
</postal>

<phone>+1 301 405 7836</phone>
<email>louie@Sayshell.UMD.EDU</email>
</address>
</author>

<author fullname="Robert Ullmann" initials="R." surname="Ullmann">
<organization>Prime Computer, Inc.</organization>

<address>
<postal>
<street>500 Old Connecticut Path</street>
<city>Framingham</city>
<region>MA</region>
<code>01701</code>
<country>US</country>
</postal>

<phone>+1 508 620 2800 x1736</phone>
<email>Ariel@Relay.Prime.COM</email>
</address>
</author>

<author fullname="Paul Mockapetris" initials="P." surname="Mockapetris">
<organization>University of Southern California (USC), Information Sciences Institute</organization>

<address>
<postal>
<street>4676 Admiralty Way</street>
<city>Marina del Rey</city>
<region>CA</region>
<code>90292</code>
<country>US</country>
</postal>

<phone>+1 213 822 1511</phone>
<email>pvm@isi.edu</email>
</address>
</author>

<date year="1990" day="1" month="October" />
</front>

<seriesInfo value="1183" name="RFC" />
</reference>


<reference target2="reference.RFC.1184.xml" anchor="RFC1184">
<front>
<title>Telnet Linemode Option</title>
<author fullname="David A. Borman" initials="D." surname="Borman">
<organization>Cray Research Inc.</organization>

<address>
<postal>
<street>655F Lone Oak Drive</street>
<city>Eagan</city>
<region>MN</region>
<code>55123</code>
<country>US</country>
</postal>

<phone>+1 612 452 6650</phone>
<email>dab@CRAY.COM</email>
</address>
</author>

<date year="1990" day="1" month="October" />
</front>

<seriesInfo value="1184" name="RFC" />
</reference>


<reference target2="reference.RFC.1185.xml" anchor="RFC1185">
<front>
<title abbrev="TCP over High-Speed Paths">TCP Extension for High-Speed Paths</title>
<author fullname="Van Jacobson" initials="V." surname="Jacobson">
<organization>University of California, Lawrence Berkeley Laboratory</organization>

<address>
<postal>
<street>Mail Stop 46A</street>
<city>Berkeley</city>
<region>CA</region>
<code>94720</code>
<country>US</country>
</postal>

<phone>+1 415 486 6411</phone>
<email>van@CSAM.LBL.GOV</email>
</address>
</author>

<author fullname="Bob Braden" initials="B." surname="Braden">
<organization>University of Southern California (USC), Information Sciences Institute</organization>

<address>
<postal>
<street>4676 Admiralty Way</street>
<city>Marina del Rey</city>
<region>CA</region>
<code>90292</code>
<country>US</country>
</postal>

<phone>+1 213 822 1511</phone>
<email>Braden@ISI.EDU</email>
</address>
</author>

<author fullname="Lixia Zhang" initials="L." surname="Zhang">
<organization>XEROX, Palo Alto Research Center (PARC)</organization>

<address>
<postal>
<street>3333 Coyote Hill Road</street>
<city>Palo Alto</city>
<region>CA</region>
<code>94304</code>
<country>US</country>
</postal>

<phone>+1 415 494 4415</phone>
<email>lixia@PARC.XEROX.COM</email>
</address>
</author>

<date year="1990" day="1" month="October" />
</front>

<seriesInfo value="1185" name="RFC" />
</reference>


<reference target2="reference.RFC.1186.xml" anchor="RFC1186">
<front>
<title abbrev="MD4 Message Digest Algorithm">MD4 Message Digest Algorithm</title>
<author fullname="Ronald L. Rivest" initials="R." surname="Rivest">
<organization>Massachusetts Institute of Technology (MIT), Laboratory for Computer Science</organization>

<address>
<postal>
<street>545 Technology Square</street>
<street>NE43-324</street>
<city>Cambridge</city>
<region>MA</region>
<code>02139-1986</code>
<country>US</country>
</postal>

<phone>+1 617 253 5880</phone>
<email>rivest@theory.lcs.mit.edu</email>
</address>
</author>

<date year="1990" day="1" month="October" />

<abstract>
<t>This note describes the MD4 message digest algorithm.  The algorithm takes as input an input message of arbitrary length and produces as output a 128-bit "fingerprint" or "message digest" of the input.  It is conjectured that it is computationally infeasible to produce two messages having the same message digest, or to produce any message having a given prespecified target message digest.  The MD4 algorithm is thus ideal for digital signature applications, where a large file must be "compressed" in a secure manner before being signed with the RSA public-key cryptosystem.</t>

<t>The MD4 algorithm is designed to be quite fast on 32-bit machines. On a SUN Sparc station, MD4 runs at 1,450,000 bytes/second.  On a DEC MicroVax II, MD4 runs at approximately 70,000 bytes/second.  On a 20MHz 80286, MD4 runs at approximately 32,000 bytes/second.  In addition, the MD4 algorithm does not require any large substitution tables; the algorithm can be coded quite compactly.</t>

<t>The MD4 algorithm is being placed in the public domain for review and possible adoption as a standard.</t>

<t>(Note: The document supersedes an earlier draft.  The algorithm described here is a slight modification of the one described in the draft.)</t>
</abstract>
</front>

<seriesInfo value="1186" name="RFC" />
</reference>


<reference target2="reference.RFC.1187.xml" anchor="RFC1187">
<front>
<title>Bulk Table Retrieval with the SNMP</title>
<author fullname="Marshall T. Rose" initials="M." surname="Rose">
<organization>Performance Systems International, Inc.</organization>

<address>
<postal>
<street>P.O. Box 391776</street>
<city>Mountain View</city>
<region>CA</region>
<code>94039</code>
<country>US</country>
</postal>

<phone>+1 415 961 3380</phone>
<email>mrose@PSI.COM</email>
</address>
</author>

<author fullname="Keith McCloghrie" initials="K." surname="McCloghrie">
<organization>Hughes, LAN Systems</organization>

<address>
<postal>
<street>1225 Charleston Road</street>
<city>Mountain View</city>
<region>CA</region>
<code>94043</code>
<country>US</country>
</postal>

<phone>+1 415 966 7934</phone>
<email>KZM@HLS.COM</email>
</address>
</author>

<author fullname="James R. Davin" initials="J." surname="Davin">
<organization>Massechusetts Institute of Technology (MIT), Laboratory for Computer Science</organization>

<address>
<postal>
<street>545 Technology Square</street>
<street>NE43-507</street>
<city>Cambridge</city>
<region>MA</region>
<code>02139</code>
<country>US</country>
</postal>

<phone>+1 617 253 6020</phone>
<email>jrd@ptt.lcs.mit.edu</email>
</address>
</author>

<date year="1990" day="1" month="October" />

<abstract>
<t>This memo reports an interesting family of algorithms for bulk table retrieval using the Simple Network Management Protocol (RFC 1157). The reader is expected to be familiar with both the Simple Network Management Protocol and SNMP's powerful get-next operator.  Please send comments to: Marshall T. Rose (mrose@psi.com).</t>
</abstract>
</front>

<seriesInfo value="1187" name="RFC" />
</reference>


<reference target2="reference.RFC.1188.xml" anchor="RFC1188">
<front>
<title abbrev="IP and ARP on FDDI Networks">Proposed Standard for the Transmission of IP Datagrams over FDDI Networks</title>
<author fullname="Dave Katz" initials="D." surname="Katz">
<organization>Merit/NSFNET</organization>

<address>
<postal>
<street>1075 Beal Ave.</street>
<city>Ann Arbor</city>
<region>MI</region>
<code>48109</code>
<country>US</country>
</postal>

<phone>+1 313 763 4898</phone>
<email>dkatz@merit.edu</email>
</address>
</author>

<date year="1990" day="1" month="October" />

<abstract>
<t>This document specifies a method for the use of IP and ARP on FDDI networks.  The encapsulation method used is described, as well as various media-specific issues.</t>
</abstract>
</front>

<seriesInfo value="1188" name="RFC" />
</reference>


<reference target2="reference.RFC.1189.xml" anchor="RFC1189">
<front>
<title abbrev="CMOT and CMIP">Common Management Information Services and Protocols for the Internet (CMOT and CMIP)</title>
<author fullname="Unnikrishnan S. Warrier" initials="U." surname="Warrier">
<organization>NetLabs</organization>

<address>
<postal>
<street>11693 San Vicente Blvd</street>
<street>Suite 348</street>
<city>Los Angeles</city>
<region>CA</region>
<code>90049</code>
<country>US</country>
</postal>

<phone>+1 213 476 4070</phone>
<email>unni@netlabs.com</email>
</address>
</author>

<author fullname="Larry Besaw" initials="L." surname="Besaw">
<organization>Hewlett-Packard</organization>

<address>
<postal>
<street>3404 East Harmony Road</street>
<city>Fort Collins</city>
<region>CO</region>
<code>80525</code>
<country>US</country>
</postal>

<phone>+1 303 229 6022</phone>
<email>lmb%hpcndaw@hplabs.hp.com</email>
</address>
</author>

<author fullname="Lee LaBarre" initials="L." surname="LaBarre">
<organization>Mitre Corporation</organization>

<address>
<postal>
<street>Burlington Road</street>
<city>Bedford</city>
<region>MA</region>
<code>01730</code>
<country>US</country>
</postal>

<phone>+1 617 271 8507</phone>
<email>cel@mbunix.mitre.org</email>
</address>
</author>

<author fullname="Brian D. Handspicker" initials="B.D." surname="Handspicker">
<organization>Digital Equipment Corporation (DEC)</organization>

<address>
<postal>
<street>550 King St.</street>
<city>Littleton</city>
<region>MA</region>
<code>01460</code>
<country>US</country>
</postal>

<phone>+1 508 486 7894</phone>
<email>bd@vines.enet.dec.com</email>
</address>
</author>

<date year="1990" day="1" month="October" />
</front>

<seriesInfo value="1189" name="RFC" />
</reference>


<reference target2="reference.RFC.1190.xml" anchor="RFC1190">
<front>
<title abbrev="Internet Stream Protocol">Experimental Internet Stream Protocol: Version 2 (ST-II)</title>
<author fullname="Stephen Casner" initials="S." surname="Casner">
<organization>University of Southern Californai (USC)/Information Sciences Institute</organization>

<address>
<postal>
<street>4676 Admiralty Way</street>
<city>Marina del Rey</city>
<region>CA</region>
<code>90292-6695</code>
<country>US</country>
</postal>

<phone>+1 213 822 1511 x153</phone>
<email>Casner@ISI.Edu</email>
</address>
</author>

<author fullname="Charles Lynn, Jr." initials="C." surname="Lynn">
<organization>Bolt Beranek and Newman Inc., BBN Systems and Technologies</organization>

<address>
<postal>
<street>10 Moulton Street</street>
<city>Cambridge</city>
<region>MA</region>
<code>02138</code>
<country>US</country>
</postal>

<phone>+1 617 873 3367</phone>
<email>CLynn@BBN.Com</email>
</address>
</author>

<author fullname="Philippe Park" initials="P." surname="Park">
<organization>Bolt Beranek and Newman Inc., BBN Systems and Technologies</organization>

<address>
<postal>
<street>10 Moulton Street</street>
<city>Cambridge</city>
<region>MA</region>
<code>02138</code>
<country>US</country>
</postal>

<phone>+1 617 873 2892</phone>
<email>ppark@BBN.COM</email>
</address>
</author>

<author fullname="Kenneth Schroder" initials="K." surname="Schroder">
<organization>Bolt Beranek and Newman Inc., BBN Systems and Technologies</organization>

<address>
<postal>
<street>10 Moulton Street</street>
<city>Cambridge</city>
<region>MA</region>
<code>02138</code>
<country>US</country>
</postal>

<phone>+1 617 873 3167</phone>
<email>Schroder@BBN.Com</email>
</address>
</author>

<author fullname="Claudio Topolcic" initials="C." surname="Topolcic">
<organization>Bolt Beranek and Newman Inc., BBN Systems and Technologies</organization>

<address>
<postal>
<street>10 Moulton Street</street>
<city>Cambridge</city>
<region>MA</region>
<code>02138</code>
<country>US</country>
</postal>

<phone>+1 617 873 3874</phone>
<email>Topolcic@BBN.Com</email>
</address>
</author>

<date year="1990" day="1" month="October" />

<abstract>
<t>This memo defines the Internet Stream Protocol, Version 2 (ST-II), an IP-layer protocol that provides end-to-end guaranteed service across an internet.  This specification obsoletes IEN 119 "ST - A Proposed Internet Stream Protocol" written by Jim Forgie in 1979, the previous specification of ST.  ST-II is not compatible with Version 1 of the protocol, but maintains much of the architecture and philosophy of that version.  It is intended to fill in some of the areas left unaddressed, to make it easier to implement, and to support a wider range of applications.</t>
</abstract>
</front>

<seriesInfo value="1190" name="RFC" />
</reference>


<reference target2="reference.RFC.1191.xml" anchor="RFC1191">
<front>
<title>Path MTU discovery</title>
<author fullname="Jeffrey Mogul" initials="J." surname="Mogul">
<organization>Digital Equipment Corporation (DEC) , Western Research Laboratory</organization>

<address>
<postal>
<street>100 Hamilton Avenue</street>
<city>Palo Alto</city>
<region>CA</region>
<code>94301</code>
<country>US</country>
</postal>

<phone>+1 415 853 6643</phone>
<email>mogul@decwrl.dec.com</email>
</address>
</author>

<author fullname="Steve Deering" initials="S." surname="Deering">
<organization>Xerox Palo Alto Research Center</organization>

<address>
<postal>
<street>3333 Coyote Hill Road</street>
<city>Palo Alto</city>
<region>CA</region>
<code>94304</code>
<country>US</country>
</postal>

<phone>+1 415 494 4839</phone>
<email>deering@xerox.com</email>
</address>
</author>

<date year="1990" day="1" month="November" />

<abstract>
<t>This memo describes a technique for dynamically discovering the maximum transmission unit (MTU) of an arbitrary internet path.  It specifies a small change to the way routers generate one type of ICMP
 message.  For a path that passes through a router that has not been so changed, this technique might not discover the correct Path MTU, but it will always choose a Path MTU as accurate as, and in many cases more accurate than, the Path MTU that would be chosen by current practice.</t>
</abstract>
</front>

<seriesInfo value="1191" name="RFC" />
</reference>


<reference target2="reference.RFC.1192.xml" anchor="RFC1192">
<front>
<title abbrev="Commercialization of the Internet">Commercialization of the Internet summary report</title>
<author fullname="Brian Kahin" initials="B." surname="Kahin">
<organization>Harvard University, John F. Kennedy School of Government</organization>

<address>
<phone>+1 617 495 8903</phone>
<email>kahin@hulaw.harvard.edu</email>
</address>
</author>

<date year="1990" day="1" month="November" />
</front>

<seriesInfo value="1192" name="RFC" />
</reference>


<reference target2="reference.RFC.1193.xml" anchor="RFC1193">
<front>
<title abbrev="Requirements for Real-Time Services">Client requirements for real-time communication services</title>
<author fullname="Domenico Ferrari" initials="D." surname="Ferrari">
<organization>University of California, Berkeley, Computer Science Division, EECS Department</organization>

<address>
<postal>
<street />
<city>Berkeley</city>
<region>CA</region>
<code>94720</code>
<country>US</country>
</postal>

<phone>+1 415 642 3806</phone>
<email>ferrari@UCBVAX.BERKELEY.EDU</email>
</address>
</author>

<date year="1990" day="1" month="November" />

<abstract>
<t>A real-time communication service provides its clients with the ability to specify their performance requirements and to obtain guarantees about the satisfaction of those requirements.  In this paper, we propose a set of performance specifications that seem appropriate for such services; they include various types of delay bounds, throughput bounds, and reliability bounds.  We also describe other requirements and desirable properties from a client's viewpoint, and the ways in which each requirement is to be translated to make it suitable for lower levels in the protocol hierarchy. Finally, we present some examples of requirements specification, and discuss some of the possible objections to our approach.</t>

<t>This research has been supported in part by AT&amp;T Bell Laboratories, the University of California under a MICRO grant, and the International Computer Science Institute.  The views and conclusions in this document are those of the author and should not be interpreted as representing official policies, either expressed or implied, of any of the sponsoring organizations.</t>
</abstract>
</front>

<seriesInfo value="1193" name="RFC" />
</reference>


<reference target2="reference.RFC.1194.xml" anchor="RFC1194">
<front>
<title abbrev="Finger">Finger User Information Protocol</title>
<author fullname="David Paul Zimmerman" initials="D." surname="Zimmerman">
<organization>Rutgers University, Center for Discrete Mathematics and Theoretical Computer Science</organization>

<address>
<postal>
<street>P.O. Box 1179</street>
<city>Piscataway</city>
<region>NJ</region>
<code>08855-1179</code>
<country>US</country>
</postal>

<phone>+1 908 932 4592</phone>
<email>dpz@dimacs.rutgers.edu</email>
</address>
</author>

<date year="1990" day="1" month="November" />

<abstract>
<t>This memo describes the Finger User Information Protocol.  This is a simple protocol which provides an interface to a remote user information program.</t>

<t>Based on RFC 742, a description of the original Finger protocol, this memo attempts to clarify the expected communication between the two ends of a Finger connection.  It also tries not to invalidate the
 many existing implementations or add unnecessary restrictions to the original protocol definition.</t>
</abstract>
</front>

<seriesInfo value="1194" name="RFC" />
</reference>


<reference target2="reference.RFC.1195.xml" anchor="RFC1195">
<front>
<title abbrev="OSI ISIS for IP and Dual Environments">Use of OSI IS-IS for routing in TCP/IP and dual environments</title>
<author fullname="Ross Callon" initials="R." surname="Callon">
<organization>Digital Equipment Corporation (DEC)</organization>

<address>
<postal>
<street>550 King Street</street>
<street>LKG 1-2/A19</street>
<city>Littleton</city>
<region>MA</region>
<code>01460-1289</code>
<country>US</country>
</postal>

<phone>+1 508 486 5009</phone>
</address>
</author>

<date year="1990" day="1" month="December" />

<abstract>
<t>This RFC specifies an integrated routing protocol, based on the OSI Intra-Domain IS-IS Routing Protocol, which may be used as an interior gateway protocol (IGP) to support TCP/IP as well as OSI. This allows a single routing protocol to be used to support pure IP environments, pure OSI environments, and dual environments. This specification was developed by the IS-IS working group of the Internet Engineering Task Force.</t>

<t>The OSI IS-IS protocol has reached a mature state, and is ready for implementation and operational use. The most recent version of the OSI IS-IS protocol is contained in ISO DP 10589. The proposed standard for using IS-IS for support of TCP/IP will therefore make use of this version (with a minor bug correction, as discussed in Annex B).  We expect that future versions of this proposed standard will upgrade to the final International Standard version of IS-IS when available.</t>

<t>Comments should be sent to "isis@merit.edu".</t>
</abstract>
</front>

<seriesInfo value="1195" name="RFC" />
</reference>


<reference target2="reference.RFC.1196.xml" anchor="RFC1196">
<front>
<title abbrev="Finger">Finger User Information Protocol</title>
<author fullname="David Paul Zimmerman" initials="D." surname="Zimmerman">
<organization>Rutgers University, Center for Discrete Mathematics and Theoretical Computer Science</organization>

<address>
<postal>
<street>P.O. Box 1179</street>
<city>Piscataway</city>
<region>NJ</region>
<code>08855-1179</code>
<country>US</country>
</postal>

<phone>+1 908 932 4592</phone>
<email>dpz@dimacs.rutgers.edu</email>
</address>
</author>

<date year="1990" day="1" month="December" />

<abstract>
<t>This memo describes the Finger User Information Protocol.  This is a simple protocol which provides an interface to a remote user information program.</t>

<t>Based on RFC 742, a description of the original Finger protocol, this memo attempts to clarify the expected communication between the two ends of a Finger connection.  It also tries not to invalidate the   many existing implementations or add unnecessary restrictions to the original protocol definition.  This edition corrects and clarifies in a minor way, RFC 1194.</t>
</abstract>
</front>

<seriesInfo value="1196" name="RFC" />
</reference>


<reference target2="reference.RFC.1197.xml" anchor="RFC1197">
<front>
<title abbrev="Using ODA">Using ODA for translating multimedia information</title>
<author fullname="Mark Sherman" initials="M." surname="Sherman">
<organization>Carnegie Mellon University , Information Technology Center</organization>

<address>
<postal>
<street>4910 Forbes Avenue</street>
<city>Pittsburgh</city>
<region>PA</region>
<code>15213</code>
<country>US</country>
</postal>

<phone>+1 412 268 6727</phone>
<facsimile>+1 412 268 6787</facsimile>
<email>mss+@andrew.cmu.edu</email>
</address>
</author>

<date year="1990" day="1" month="December" />
</front>

<seriesInfo value="1197" name="RFC" />
</reference>


<reference target2="reference.RFC.1198.xml" anchor="RFC1198">
<front>
<title abbrev="FYI - X Window System">FYI on the X window system</title>
<author fullname="Bob Scheifler" initials="B." surname="Scheifler">
<organization>MIT,  X Consortium, Laboratory for Computer Science</organization>

<address>
<postal>
<street>545 Technology Square</street>
<city>Cambridge</city>
<region>MA</region>
<code>02139</code>
<country>US</country>
</postal>

<phone>+1 617 253 0628</phone>
<email>rws@expo.lcs.mit.edu</email>
</address>
</author>

<date year="1991" day="1" month="January" />
</front>

<seriesInfo value="1198" name="RFC" />
</reference>


<reference target2="reference.RFC.1199.xml" anchor="RFC1199">
<front>
<title abbrev="Summary of 1100-1199">Request for Comments Summary Notes: 1100-1199</title>
<author fullname="Joyce K. Reynolds" initials="J." surname="Reynolds">
<organization>University of Southern California (USC), Information Sciences Institute</organization>

<address>
<postal>
<street>4676 Admiralty Way</street>
<city>Marina del Rey</city>
<region>CA</region>
<code>90292</code>
<country>US</country>
</postal>

<phone>+1 310 822 1511</phone>
<email>JKREY@ISI.EDU</email>
</address>
</author>

<date year="1991" day="1" month="December" />
</front>

<seriesInfo value="1199" name="RFC" />
</reference>


<reference target2="reference.RFC.1200.xml" anchor="RFC1200">
<front>
<title abbrev="IAB Standards">IAB official protocol standards</title>
<author fullname="Jon Postel" initials="J." surname="Postel">
<organization>USC/Information Sciences Institute</organization>

<address>
<postal>
<street>4676 Admiralty Way</street>
<city>Marina del Rey</city>
<region>CA</region>
<code>90292</code>
<country>US</country>
</postal>

<phone>+1 213 822 1511</phone>
<facsimile>+1 213 823 6714</facsimile>
<email>Postel@ISI.EDU</email>
</address>
</author>

<date year="1991" day="1" month="April" />
</front>

<seriesInfo value="1200" name="RFC" />
</reference>


<reference target2="reference.RFC.1201.xml" anchor="RFC1201">
<front>
<title abbrev="IP on ARCNET">Transmitting IP traffic over ARCNET networks</title>
<author fullname="Don Provan" initials="D." surname="Provan">
<organization>Novell, Inc.</organization>

<address>
<postal>
<street>2180 Fortune Drive</street>
<city>San Jose</city>
<region>CA</region>
<code>95131</code>
<country>US</country>
</postal>

<phone>+1 408 473 8440</phone>
<email>donp@Novell.Com</email>
</address>
</author>

<date year="1991" day="1" month="February" />
</front>

<seriesInfo value="46" name="STD" />
<seriesInfo value="1201" name="RFC" />
</reference>


<reference target2="reference.RFC.1202.xml" anchor="RFC1202">
<front>
<title>Directory Assistance service</title>
<author fullname="Marshall T. Rose" initials="M." surname="Rose">
<organization>Performance Systems International, Inc.</organization>

<address>
<postal>
<street>P.O. Box 391776</street>
<city>Mountain View</city>
<region>CA</region>
<code>94039</code>
<country>US</country>
</postal>

<phone>+1 415 961 3380</phone>
<email>mrose@psi.com</email>
</address>
</author>

<date year="1991" day="1" month="February" />
</front>

<seriesInfo value="1202" name="RFC" />
</reference>


<reference target2="reference.RFC.1203.xml" anchor="RFC1203">
<front>
<title abbrev="IMAP3">Interactive Mail Access Protocol: Version 3</title>
<author fullname="James Rice" initials="J." surname="Rice">
<organization>Stanford University, Knowledge Systems Laboratory</organization>

<address>
<postal>
<street>701 Welch Road</street>
<street>Building C</street>
<city>Palo Alto</city>
<region>CA</region>
<code>94304</code>
<country>US</country>
</postal>

<phone>+1 415 723 8405</phone>
<email>RICE@SUMEX-AIM.STANFORD.EDU</email>
</address>
</author>

<date year="1991" day="1" month="February" />
</front>

<seriesInfo value="1203" name="RFC" />
</reference>


<reference target2="reference.RFC.1204.xml" anchor="RFC1204">
<front>
<title abbrev="MPP">Message Posting Protocol (MPP)</title>
<author fullname="Shannon Yeh" initials="S." surname="Yeh">
<organization>Netix Communications, Inc.</organization>

<address>
<postal>
<street>15375 Barranca Parkway</street>
<street>Suite A-215</street>
<city>Irvine</city>
<region>CA</region>
<code>92718</code>
<country>US</country>
</postal>

<phone>+1 714 727 9335</phone>
<email>yeh@netix.com</email>
</address>
</author>

<author fullname="David Lee" initials="D." surname="Lee">
<organization>Netix Communications, Inc.</organization>

<address>
<postal>
<street>15375 Barranca Parkway</street>
<street>Suite A-215</street>
<city>Irvine</city>
<region>CA</region>
<code>92718</code>
<country>US</country>
</postal>

<phone>+1 714 727 9335</phone>
<email>dlee@netix.com</email>
</address>
</author>

<date year="1991" day="1" month="February" />
</front>

<seriesInfo value="1204" name="RFC" />
</reference>


<reference target2="reference.RFC.1205.xml" anchor="RFC1205">
<front>
<title>5250 Telnet interface</title>
<author fullname="Paul Chmielewski" initials="P." surname="Chmielewski">
<organization>International Business Machines Corporation (IBM)</organization>

<address>
<postal>
<street>Highway 52 and 37 Street North West</street>
<city>Rochester</city>
<region>MN</region>
<code>55901</code>
<country>US</country>
</postal>

<phone>+1 507 253 6315</phone>
<email>paulc@rchland.iinus1.ibm.com</email>
</address>
</author>

<date year="1991" day="1" month="February" />
</front>

<seriesInfo value="1205" name="RFC" />
</reference>


<reference target2="reference.RFC.1206.xml" anchor="RFC1206">
<front>
<title abbrev="FYI Q/A - for New Internet Users">FYI on Questions and Answers: Answers to commonly asked "new Internet user" questions</title>
<author fullname="Gary Scott Malkin" initials="G." surname="Malkin">
<organization>FTP Software, Inc.</organization>

<address>
<postal>
<street>26 Princess Street</street>
<city>Wakefield</city>
<region>MA</region>
<code>01880</code>
<country>US</country>
</postal>

<phone>+1 617 246 0900</phone>
<email>gmalkin@ftp.com</email>
</address>
</author>

<author fullname="April N. Marine" initials="A." surname="Marine">
<organization>SRI International, Network Information Systems Center</organization>

<address>
<postal>
<street>333 Ravenswood Avenue</street>
<street>EJ294</street>
<city>Menlo Park</city>
<region>CA</region>
<code>94025</code>
<country>US</country>
</postal>

<phone>+1 415 859 5318</phone>
<email>APRIL@nic.ddn.mil</email>
</address>
</author>

<date year="1991" day="1" month="February" />
</front>

<seriesInfo value="1206" name="RFC" />
</reference>


<reference target2="reference.RFC.1207.xml" anchor="RFC1207">
<front>
<title abbrev="FYI Q/A - for Experienced Internet Users">FYI on Questions and Answers: Answers to commonly asked "experienced Internet user" questions</title>
<author fullname="Gary Scott Malkin" initials="G." surname="Malkin">
<organization>FTP Software, Inc.</organization>

<address>
<postal>
<street>26 Princess Street</street>
<city>Wakefield</city>
<region>MA</region>
<code>01880</code>
<country>US</country>
</postal>

<phone>+1 617 246 0900</phone>
<email>gmalkin@ftp.com</email>
</address>
</author>

<author fullname="April N. Marine" initials="A." surname="Marine">
<organization>SRI International, Network Information Systems Center</organization>

<address>
<postal>
<street>333 Ravenswood Avenue</street>
<street>EJ294</street>
<city>Menlo Park</city>
<region>CA</region>
<code>94025</code>
<country>US</country>
</postal>

<phone>+1 415 859 5318</phone>
<email>APRIL@nic.ddn.mil</email>
</address>
</author>

<author fullname="Joyce K. Reynolds" initials="J." surname="Reynolds">
<organization>University of Southern California (USC)/Information Sciences Institute (ISI)</organization>

<address>
<postal>
<street>4676 Admiralty Way</street>
<city>Marina del Rey</city>
<region>CA</region>
<code>90292 6695</code>
<country>US</country>
</postal>

<phone>+1 213 822 1511</phone>
<email>jkrey@isi.edu</email>
</address>
</author>

<date year="1991" day="1" month="February" />
</front>

<seriesInfo value="1207" name="RFC" />
</reference>


<reference target2="reference.RFC.1208.xml" anchor="RFC1208">
<front>
<title abbrev="INTEROP Pocket Glossary">Glossary of networking terms</title>
<author fullname="Ole J. Jacobsen" initials="O." surname="Jacobsen">
<organization>Interop, Inc.</organization>

<address>
<postal>
<street>480 San Antonio Road</street>
<street>Suite 100</street>
<city>Mountain View</city>
<region>CA</region>
<code>94040</code>
<country>US</country>
</postal>

<phone>+1 415 941 3399</phone>
<email>OLE@CSLI.STANFORD.EDU</email>
</address>
</author>

<author fullname="Daniel C. Lynch" initials="D." surname="Lynch">
<organization>Interop, Inc.</organization>

<address>
<postal>
<street>480 San Antonio Road</street>
<street>Suite 100</street>
<city>Mountain View</city>
<region>CA</region>
<code>94040</code>
<country>US</country>
</postal>

<phone>+1 415 941 3399</phone>
<email>Lynch@ISI.EDU</email>
</address>
</author>

<date year="1991" day="1" month="March" />
</front>

<seriesInfo value="1208" name="RFC" />
</reference>


<reference target2="reference.RFC.1209.xml" anchor="RFC1209">
<front>
<title>Transmission of IP datagrams over the SMDS Service</title>
<author fullname="Dave Piscitello" initials="D." surname="Piscitello">
<organization>Bell Communications Research</organization>

<address>
<postal>
<street>331 Newman Springs Road</street>
<city>Red Bank</city>
<region>NJ</region>
<code>07701</code>
<country>US</country>
</postal>

<phone>+1 908 758 2286</phone>
<email>dave@sabre.bellcore.com</email>
</address>
</author>

<author fullname="Joseph Lawrence" initials="J." surname="Lawrence">
<organization>Bell Communications Research</organization>

<address>
<postal>
<street>331 Newman Springs Road</street>
<city>Red Bank</city>
<region>NJ</region>
<code>07701</code>
<country>US</country>
</postal>

<phone>+1 908 758 4146</phone>
<email>jcl@sabre.bellcore.com</email>
</address>
</author>

<date year="1991" day="1" month="March" />

<abstract>
<t>This memo describes an initial use of IP and ARP in an SMDS service environment configured as a logical IP subnetwork, LIS (described below).  The encapsulation method used is described, as well as various service-specific issues.  This memo does not preclude subsequent treatment of the SMDS Service in configurations other than LIS; specifically, public or inter-company, inter-enterprise configurations may be treated differently and will be described in future documents.  This document considers only directly connected IP end-stations or routers; issues raised by MAC level bridging are beyond the scope of this paper.</t>
</abstract>
</front>

<seriesInfo value="52" name="STD" />
<seriesInfo value="1209" name="RFC" />
</reference>


<reference target2="reference.RFC.1210.xml" anchor="RFC1210">
<front>
<title abbrev="Network and Infrastructure User Requirements">Network and infrastructure user requirements for transatlantic research collaboration: Brussels, July 16-18, and Washington July 24-25, 1990</title>
<author fullname="Vinton G. Cerf" initials="V." surname="Cerf">
<organization>Corporation for National Research Initiatives</organization>

<address>
<postal>
<street>1895 Preston White Drive</street>
<street>Suite 100</street>
<city>Reston</city>
<region>VA</region>
<code>22091</code>
<country>US</country>
</postal>

<phone>+1 703 620 8990</phone>
<email>vcerf@nri.reston.va.us</email>
</address>
</author>

<author fullname="Peter Kirstein" initials="P." surname="Kirstein">
<organization>University College London, Department of Computer Science</organization>

<address>
<postal>
<street>Gower Street</street>
<city>London</city>
<region>England</region>
<code>WC1E GBT</code>
<country>UK</country>
</postal>

<phone>+44 71 3807286</phone>
<email>kirstein@cs.ucl.ac.uk</email>
</address>
</author>

<author fullname="Brian Randell" initials="B." surname="Randell">
<organization>University of Newcastle upon Tyne, Computing Laboratory</organization>

<address>
<postal>
<street />
<city>Newcastle upon Tyne</city>
<region>England</region>
<code>NE1 7RU</code>
<country>UK</country>
</postal>

<phone>+44 91 2227923</phone>
<email>Brian.Randell@newcastle.ac.uk</email>
</address>
</author>

<date year="1991" day="1" month="March" />

<abstract>
<t>This report summarises user requirements for networking and related infrastructure facilities needed to enable effective cooperation between US and European research teams participating in the planned ESPRIT-DARPA/NSF programme of collaborative research in Information Science and Technology.  It analyses the problems and disparities of the current facilities, and suggests appropriate one and three year targets for improvements.  It proposes a number of initial actions aimed at achieving these targets.  Finally, the workshop has identified a non-exhaustive set of important issues upon which support of future research will depend.  These issues could be studied in the short term, with the aim of initiating a programme of joint research in collaboration technology within the next year.</t>
</abstract>
</front>

<seriesInfo value="1210" name="RFC" />
</reference>


<reference target2="reference.RFC.1211.xml" anchor="RFC1211">
<front>
<title abbrev="Problems with Mailing Lists">Problems with the maintenance of large mailing lists</title>
<author fullname="Ann Westine" initials="A." surname="Westine">
<organization>USC/Information Sciences Institute</organization>

<address>
<postal>
<street>4676 Admiralty Way</street>
<city>Marina del Rey</city>
<region>CA</region>
<code>90292-6695</code>
<country>US</country>
</postal>

<phone>+1 213 822 1511</phone>
<email>Westine@ISI.EDU</email>
</address>
</author>

<author fullname="Jon Postel" initials="J." surname="Postel">
<organization>USC/Information Sciences Institute</organization>

<address>
<postal>
<street>4676 Admiralty Way</street>
<city>Marina del Rey</city>
<region>CA</region>
<code>90292-6695</code>
<country>US</country>
</postal>

<phone>+1 213 822 1511</phone>
<email>Postel@ISI.EDU</email>
</address>
</author>

<date year="1991" day="1" month="March" />
</front>

<seriesInfo value="1211" name="RFC" />
</reference>


<reference target2="reference.RFC.1212.xml" anchor="RFC1212">
<front>
<title>Concise MIB definitions</title>
<author fullname="Marshall T. Rose" initials="M." surname="Rose">
<organization>Performance Systems International</organization>

<address>
<postal>
<street>5201 Great America Parkway</street>
<street>Suite 3106</street>
<city>Santa Clara</city>
<region>CA</region>
<code>95054</code>
<country>US</country>
</postal>

<phone>+1 408 562 6222</phone>
<email>mrose@psi.com</email>
</address>
</author>

<author fullname="Keith McCloghrie" initials="K." surname="McCloghrie">
<organization>Hughes, LAN Systems</organization>

<address>
<postal>
<street>1225 Charleston Road</street>
<city>Mountain View</city>
<region>CA</region>
<code>94043</code>
<country>US</country>
</postal>

<phone>+1 415 966 7934</phone>
<email>kzm@hls.com</email>
</address>
</author>

<date year="1991" day="1" month="March" />

<abstract>
<t>This memo describes a straight-forward approach toward producing concise, yet descriptive, MIB modules.  It is intended that all future MIB modules be written in this format.</t>
</abstract>
</front>

<seriesInfo value="16" name="STD" />
<seriesInfo value="1212" name="RFC" />
</reference>


<reference target2="reference.RFC.1213.xml" anchor="RFC1213">
<front>
<title abbrev="MIB-II">Management Information Base for Network Management of TCP/IP-based internets:MIB-II</title>
<author fullname="Keith McCloghrie" initials="K." surname="McCloghrie">
<organization>Hughes, LAN Systems</organization>

<address>
<postal>
<street>1225 Charleston Road</street>
<city>Mountain View</city>
<region>CA</region>
<code>94043</code>
<country>US</country>
</postal>

<phone>+1 415 966 7934</phone>
<email>kzm@hls.com</email>
</address>
</author>

<author fullname="Marshall T. Rose" initials="M." surname="Rose">
<organization>Performance Systems International</organization>

<address>
<postal>
<street>5201 Great America Parkway</street>
<street>Suite 3106</street>
<city>Santa Clara</city>
<region>CA</region>
<code>95054</code>
<country>US</country>
</postal>

<phone>+1 408 562 6222</phone>
<email>mrose@psi.com</email>
</address>
</author>

<date year="1991" day="1" month="March" />

<abstract>
<t>This memo defines the second version of the Management Information Base (MIB-II) for use with network management protocols in TCP/IP-based internets.  In particular, together with its companion memos which describe the structure of management information (RFC 1155) along with the network management protocol (RFC 1157) for TCP/IP-based internets, these documents provide a simple, workable architecture and system for managing TCP/IP-based internets and in particular the Internet community.</t>
</abstract>
</front>

<seriesInfo value="17" name="STD" />
<seriesInfo value="1213" name="RFC" />
</reference>


<reference target2="reference.RFC.1214.xml" anchor="RFC1214">
<front>
<title abbrev="MIB-II-OIM">OSI internet management: Management Information Base</title>
<author fullname="Lee LaBarre" initials="L." surname="LaBarre">
<organization>The MITRE Corporation</organization>

<address>
<postal>
<street>Burlington Road</street>
<city>Bedford</city>
<region>MA</region>
<code>01730</code>
<country>US</country>
</postal>

<phone>+1 617 271 8507</phone>
<email>cel@mbunix.mitre.org</email>
</address>
</author>

<date year="1991" day="1" month="April" />

<abstract>
<t>This RFC documents a MIB for use with CMIP, either over pure OSI stacks or with the CMIP over TCP specification.  It redefines objects comprised by the second revision of the Management Information Base for Network Management of TCP/IP-based internets: MIB-II so as to conform to the OSI structure of management information.  This document is a product of the IETF OIM working group.</t>
</abstract>
</front>

<seriesInfo value="1214" name="RFC" />
</reference>


<reference target2="reference.RFC.1215.xml" anchor="RFC1215">
<front>
<title abbrev="Convention for Defining Traps">Convention for defining traps for use with the SNMP</title>
<author fullname="Marshall T. Rose" initials="M." surname="Rose">
<organization>Performance Systems International</organization>

<address>
<postal>
<street>5201 Great America Parkway</street>
<street>Suite 3106</street>
<city>Santa Clara</city>
<region>CA</region>
<code>95054</code>
<country>US</country>
</postal>

<phone>+1 408 562 6222</phone>
<email>mrose@psi.com</email>
</address>
</author>

<date year="1991" day="1" month="March" />
</front>

<seriesInfo value="1215" name="RFC" />
</reference>


<reference target2="reference.RFC.1216.xml" anchor="RFC1216">
<front>
<title>Gigabit network economics and paradigm shifts</title>
<author fullname="Dr. Poorer Richard" initials="P." surname="Richard">
<organization>Almanac Institute, Center against Misoneoism</organization>

<address>
<postal>
<street />
<city>Campo Imperatore</city>
<region />
<code />
<country>IT</country>
</postal>

</address>
</author>

<author fullname="Prof. Kynikos" surname="Kynikos">
<organization>Miskatonic University</organization>

<address>
<postal>
<street />
<city>Arkham</city>
<region>MA</region>
<code />
<country>US</country>
</postal>

<email>Kynikos@Cthulu.Miskatonic.EDU</email>
</address>
</author>

<date year="1991" day="1" month="April" />
</front>

<seriesInfo value="1216" name="RFC" />
</reference>


<reference target2="reference.RFC.1217.xml" anchor="RFC1217">
<front>
<title abbrev="ULSNET BAA">Memo from the Consortium for Slow Commotion Research (CSCR)</title>
<author fullname="Vint Cerf" initials="V." surname="Cerf">
<organization>Corporation for National Research Initiatives</organization>

<address>
<postal>
<street>1895 Preston White Drive</street>
<street>Suite 100</street>
<city>Reston</city>
<region>VA</region>
<code>22091</code>
<country>US</country>
</postal>

<phone>+1 703 620 8990</phone>
<email>CERF@NRI.RESTON.VA.US</email>
</address>
</author>

<date year="1991" day="1" month="April" />
</front>

<seriesInfo value="1217" name="RFC" />
</reference>


<reference target2="reference.RFC.1218.xml" anchor="RFC1218">
<front>
<title>Naming scheme for c=US</title>
<author fullname="Theodore H. Myer" initials="T." surname="Myer">
<organization>North American Directory Forum</organization>

<address>
<postal>
<street>3055 Q Street NW</street>
<city>Washington</city>
<region>DC</region>
<code>20007</code>
<country>US</country>
</postal>

<phone>+1 202 342 2727</phone>
</address>
</author>

<date year="1991" day="1" month="April" />

<abstract>
<t>This is one of a series of documents produced for discussion within the North American Directory Forum.  Distribution, with attribution, is unlimited.  This document is being circulated for comment.  The deadline for comments is July 1, 1991.  Comments should be directed to the contact given on page 16.</t>
</abstract>
</front>

<seriesInfo value="1218" name="RFC" />
</reference>


<reference target2="reference.RFC.1219.xml" anchor="RFC1219">
<front>
<title>On the assignment of subnet numbers</title>
<author fullname="Paul F. Tsuchiya" initials="P." surname="Tsuchiya">
<organization>Bellcore</organization>

<address>
<postal>
<street>435 South St..</street>
<street>MRE 2L-281</street>
<city>Morristown</city>
<region>NJ</region>
<code>07960</code>
<country>US</country>
</postal>

<phone>+1 201 829 4484</phone>
<email>tsuchiya@thumper.bellcore.com</email>
</address>
</author>

<date year="1991" day="1" month="April" />
</front>

<seriesInfo value="1219" name="RFC" />
</reference>


<reference target2="reference.RFC.1220.xml" anchor="RFC1220">
<front>
<title abbrev="Bridging Point-to-Point Protocol">Point-to-Point Protocol extensions for bridging</title>
<author fullname="Fred Baker" initials="F." surname="Baker">
<organization>Advanced Computer Communications</organization>

<address>
<postal>
<street>720 Santa Barbara Street</street>
<city>Santa Barbara</city>
<region>CA</region>
<code>93101</code>
<country>US</country>
</postal>

<phone>+1 805 963 9431</phone>
<email>fbaker@ACC.COM</email>
</address>
</author>

<date year="1991" day="1" month="April" />
</front>

<seriesInfo value="1220" name="RFC" />
</reference>


<reference target2="reference.RFC.1221.xml" anchor="RFC1221">
<front>
<title abbrev="HAP2">Host Access Protocol (HAP) specification: Version 2</title>
<author fullname="Winston Edmond" initials="W." surname="Edmond">
<organization>Bolt Beranek and Newman, Inc. (BBN), Network Technologies Department</organization>

<address>
<postal>
<street>10 Moulton Street</street>
<city>Cambridge</city>
<region>MA</region>
<code>02138</code>
<country>US</country>
</postal>

<phone>+1 617 873 3000</phone>
<email>wbe@bbn.com</email>
</address>
</author>

<date year="1991" day="1" month="April" />
</front>

<seriesInfo value="1221" name="RFC" />
</reference>


<reference target2="reference.RFC.1222.xml" anchor="RFC1222">
<front>
<title>Advancing the NSFNET routing architecture</title>
<author fullname="Hans-Werner Braun" initials="H." surname="Braun">
<organization>San Diego Supercomputer Center</organization>

<address>
<postal>
<street>P.O. Box 85608</street>
<city>La Jolla</city>
<region>CA</region>
<code>92186-9784</code>
<country>US</country>
</postal>

<phone>+1 619 534 5035</phone>
<facsimile>+1 619 534 5113</facsimile>
<email>HWB@SDSC.EDU</email>
</address>
</author>

<author fullname="Yakov Rekhter" initials="Y." surname="Rekhter">
<organization>IBM Corporation, T.J. Watson Research Center</organization>

<address>
<postal>
<street>P.O. Box 218</street>
<city>Yorktown Heights</city>
<region>NY</region>
<code>10598</code>
<country>US</country>
</postal>

<phone>+1 914 945 3896</phone>
<email>Yakov@Watson.IBM.COM</email>
</address>
</author>

<date year="1991" day="1" month="May" />
</front>

<seriesInfo value="1222" name="RFC" />
</reference>


<reference target2="reference.RFC.1223.xml" anchor="RFC1223">
<front>
<title abbrev="OSI and LLC1 on HYPERchannel">OSI CLNS and LLC1 protocols on Network Systems HYPERchannel</title>
<author fullname="Joel M. Halpern" initials="J." surname="Halpern">
<organization>Network Systems Corporation</organization>

<address>
<postal>
<street>7600 Boone Avenue North</street>
<street>MS033</street>
<city>Minneapolis</city>
<region>MN</region>
<code>55428</code>
<country>US</country>
</postal>

<phone>+1 612 424 1606</phone>
<email>jmh@anubis.network.com</email>
</address>
</author>

<date year="1991" day="1" month="May" />
</front>

<seriesInfo value="1223" name="RFC" />
</reference>


<reference target2="reference.RFC.1224.xml" anchor="RFC1224">
<front>
<title abbrev="Managing Asynchronously Generated Alerts">Techniques for managing asynchronously generated alerts</title>
<author fullname="Lou Steinberg" initials="L." surname="Steinberg">
<organization>IBM, NSFNET Software Development</organization>

<address>
<postal>
<street>472 Wheelers Farms Rd</street>
<street>M/S 91</street>
<city>Milford</city>
<region>CT</region>
<code>06460</code>
<country>US</country>
</postal>

<phone>+1 203 783 7175</phone>
<email>LOUISS@IBM.COM</email>
</address>
</author>

<date year="1991" day="1" month="May" />

<abstract>
<t>This RFC explores mechanisms to prevent a remotely managed entity from burdening a manager or network with an unexpected amount of network management information, and to ensure delivery of "important" information.  The focus is on controlling the flow of asynchronously generated information, and not how the information is generated.</t>
</abstract>
</front>

<seriesInfo value="1224" name="RFC" />
</reference>


<reference target2="reference.RFC.1225.xml" anchor="RFC1225">
<front>
<title abbrev="POP3">Post Office Protocol: Version 3</title>
<author fullname="Marshall T. Rose" initials="M." surname="Rose">
<organization>Performance Systems International</organization>

<address>
<postal>
<street>5201 Great America Parkway</street>
<street>Suite 3106</street>
<city>Santa Clara</city>
<region>CA</region>
<code>95054</code>
<country>US</country>
</postal>

<phone>+1 408 562 6222</phone>
<email>mrose@psi.com</email>
</address>
</author>

<date year="1991" day="1" month="May" />
</front>

<seriesInfo value="1225" name="RFC" />
</reference>


<reference target2="reference.RFC.1226.xml" anchor="RFC1226">
<front>
<title abbrev="IP Encapsulation of AX.25 Frames">Internet protocol encapsulation of AX.25 frames</title>
<author fullname="Brian Kantor" initials="B." surname="Kantor">
<organization>University of California San Diego (UCSD), Network Operations</organization>

<address>
<postal>
<street>C-024</street>
<city>La Jolla</city>
<region>CA</region>
<code>92093-0214</code>
<country>US</country>
</postal>

<phone>+1 619 534 6865</phone>
<email>brian@UCSD.EDU</email>
</address>
</author>

<date year="1991" day="1" month="May" />
</front>

<seriesInfo value="1226" name="RFC" />
</reference>


<reference target2="reference.RFC.1227.xml" anchor="RFC1227">
<front>
<title abbrev="SMUX">SNMP MUX protocol and MIB</title>
<author fullname="Marshall T. Rose" initials="M.T." surname="Rose">
<organization>Performance Systems International, Inc.</organization>

<address>
<postal>
<street>5201 Great America Parkway</street>
<street>Suite 3106</street>
<city>Santa Clara</city>
<region>CA</region>
<code>95054</code>
<country>US</country>
</postal>

<phone>+1 408 562 6222</phone>
<email>mrose@psi.com</email>
</address>
</author>

<date year="1991" day="1" month="May" />
</front>

<seriesInfo value="1227" name="RFC" />
</reference>


<reference target2="reference.RFC.1228.xml" anchor="RFC1228">
<front>
<title abbrev="SNMP-DPI">SNMP-DPI: Simple Network Management Protocol Distributed Program Interface</title>
<author fullname="Geoffrey C. Carpenter" initials="G." surname="Carpenter">
<organization>IBM, T. J. Watson Research Center</organization>

<address>
<postal>
<street>P.O. Box 218</street>
<city>Yorktown Heights</city>
<region>NY</region>
<code>10598</code>
<country>US</country>
</postal>

<phone>+1 914 945 1970</phone>
<email>gcc@watson.ibm.com</email>
</address>
</author>

<author fullname="Bert Wijnen" initials="B." surname="Wijnen">
<organization>IBM International Operations</organization>

<address>
<postal>
<street>Watsonweg 2</street>
<city>Uithoorn</city>
<region />
<code>1423 ND</code>
<country>NL</country>
</postal>

<phone>+31 29 7553316</phone>
<email>wijnen@uitvm2.iinus1.ibm.com</email>
</address>
</author>

<date year="1991" day="1" month="May" />

<abstract>
<t>The Simple Network Management Protocol (SNMP)Distributed Program Interface (DPI) is an extension to SNMP agents that permits end-users to dynamically add, delete or replace management variables in the local Management Information Base without requiring recompilation of the SNMP agent.  This is achieved by writing a so-called sub-agent that communicates with the agent via the SNMP-DPI.</t>

<t>For the author of a sub-agent, the SNMP-DPI eliminates the need to know the details of ASN.1or SNMP PDU (Protocol Data Unit) encoding/decoding,.</t>

<t>This protocol has been in use within IBM since 1989 and is included in the SNMP agents for VM, MVS and OS/2.</t>

<t>Potentially useful sample sub-agent code and implementation examples are available for anonymous FTP from the University of Toronto.</t>
</abstract>
</front>

<seriesInfo value="1228" name="RFC" />
</reference>


<reference target2="reference.RFC.1229.xml" anchor="RFC1229">
<front>
<title abbrev="Interface MIB Extensions">Extensions to the generic-interface MIB</title>
<author fullname="Keith McCloghrie" initials="K." surname="McCloghrie">
<organization>Hughes, LAN Systems, Inc.</organization>

<address>
<postal>
<street>1225 Charleston Road</street>
<city>Mountain View</city>
<region>CA</region>
<code>94043</code>
<country>US</country>
</postal>

<phone>+1 415 966 7934</phone>
<email>kzm@hls.com</email>
</address>
</author>

<date year="1991" day="1" month="May" />

<abstract>
<t>This memo defines an experimental portion of the Management Information Base (MIB) for use with network management protocols in TCP/IP-based internets.  In particular, it defines managed object types as experimental extensions to the generic interfaces structure of MIB-II.</t>
</abstract>
</front>

<seriesInfo value="1229" name="RFC" />
</reference>


<reference target2="reference.RFC.1230.xml" anchor="RFC1230">
<front>
<title abbrev="IEEE 802.4 MIB">IEEE 802.4 Token Bus MIB</title>
<author fullname="Keith McCloghrie" initials="K." surname="McCloghrie">
<organization>Hughes, LAN Systems, Inc.</organization>

<address>
<postal>
<street>1225 Charleston Road</street>
<city>Mountain View</city>
<region>CA</region>
<code>94043</code>
<country>US</country>
</postal>

<phone>+1 415 966 7934</phone>
<email>kzm@hls.com</email>
</address>
</author>

<author fullname="Richard Fox" initials="R." surname="Fox">
<organization>Synoptics, Inc.</organization>

<address>
<postal>
<street>4401 Great America Pkwy</street>
<street>PO Box 58185</street>
<city>Santa Clara</city>
<region>CA</region>
<code>95052</code>
<country>US</country>
</postal>

<phone>+1 408 764 1372</phone>
<email>rfox@synoptics.com</email>
</address>
</author>

<date year="1991" day="1" month="May" />

<abstract>
<t>This memo defines an experimental portion of the Management Information Base (MIB) for use with network management protocols in TCP/IP-based internets.  In particular, this memo defines managed objects used for managing subnetworks which use the IEEE 802.4 Token Bus technology described in 802.4 Token-Passing Bus Access Method and Physical Layer Specifications, IEEE Standard 802.4.</t>
</abstract>
</front>

<seriesInfo value="1230" name="RFC" />
</reference>


<reference target2="reference.RFC.1231.xml" anchor="RFC1231">
<front>
<title abbrev="IEEE 802.5 MIB">IEEE 802.5 Token Ring MIB</title>
<author fullname="Keith McCloghrie" initials="K." surname="McCloghrie">
<organization>Hughes, LAN Systems, Inc.</organization>

<address>
<postal>
<street>1225 Charleston Road</street>
<city>Mountain View</city>
<region>CA</region>
<code>94043</code>
<country>US</country>
</postal>

<phone>+1 415 966 7934</phone>
<email>kzm@hls.com</email>
</address>
</author>

<author fullname="Richard Fox" initials="R." surname="Fox">
<organization>Synoptics, Inc.</organization>

<address>
<postal>
<street>4401 Great America Pkwy</street>
<street>PO Box 58185</street>
<city>Santa Clara</city>
<region>CA</region>
<code>95052</code>
<country>US</country>
</postal>

<phone>+1 408 764 1372</phone>
<email>rfox@synoptics.com</email>
</address>
</author>

<author fullname="Eric Decker" initials="E." surname="Decker">
<organization>cisco Systems, Inc.</organization>

<address>
<postal>
<street>1525 O'Brien Dr.</street>
<city>Menlo Park</city>
<region>CA</region>
<code>94025</code>
<country>US</country>
</postal>

<phone>+1 415 688 8241</phone>
<email>cire@cisco.com</email>
</address>
</author>

<date year="1991" day="1" month="May" />

<abstract>
<t>This memo defines an experimental portion of the Management Information Base (MIB) for use with network management protocols in TCP/IP-based internets.  In particular, this memo defines managed objects used for managing subnetworks which use the IEEE 802.5 Token Ring technology described in 802.5 Token Ring Access Method and Physical Layer Specifications, IEEE Standard 802.5-1989.</t>
</abstract>
</front>

<seriesInfo value="1231" name="RFC" />
</reference>


<reference target2="reference.RFC.1232.xml" anchor="RFC1232">
<front>
<title abbrev="DS1 Interface Objects">Definitions of managed objects for the DS1 Interface type</title>
<author fullname="Fred Baker" initials="F." surname="Baker">
<organization>Advanced Computer Communications, Inc.</organization>

<address>
<postal>
<street>720 Santa Barbara Street</street>
<city>Santa Barbara</city>
<region>CA</region>
<code>93101</code>
<country>US</country>
</postal>

<phone>+1 805 963 9431</phone>
<email>fbaker@acc.com</email>
</address>
</author>

<author fullname="Christopher P. Kolb" initials="C." surname="Kolb">
<organization>Performance Systems International, Inc., Reston International Center</organization>

<address>
<postal>
<street>11800 Sunrise Valley Drive</street>
<street>Suite 1100</street>
<city>Reston</city>
<region>VA</region>
<code>22091</code>
<country>US</country>
</postal>

<phone>+1 703 620 6651</phone>
<email>kolb@psi.com</email>
</address>
</author>

<date year="1991" day="1" month="May" />

<abstract>
<t>This memo defines an experimental portion of the Management Information Base (MIB) for use with network management protocols in TCP/IP-based internets.  In particular, this memo defines MIB objects for representing DS1 physical interfaces.  Implementors should consult in addition to this memo the companion document that describes that DS3 managed objects.</t>
</abstract>
</front>

<seriesInfo value="1232" name="RFC" />
</reference>


<reference target2="reference.RFC.1233.xml" anchor="RFC1233">
<front>
<title abbrev="DS3 Interface Objects">Definitions of managed objects for the DS3 Interface type</title>
<author fullname="Tracy A. Cox" initials="T." surname="Cox">
<organization>Bell Communications Research</organization>

<address>
<postal>
<street>331 Newman Springs Road</street>
<street>P.O. Box 7020</street>
<city>Red Bank</city>
<region>NJ</region>
<code>07701-7020</code>
<country>US</country>
</postal>

<phone>+1 908 758 2107</phone>
<email>tacox@sabre.bellcore.com</email>
</address>
</author>

<author fullname="Kaj Tesink" initials="K." surname="Tesink">
<organization>Bell Communications Research</organization>

<address>
<postal>
<street>331 Newman Springs Road</street>
<street>P.O. Box 7020</street>
<city>Red Bank</city>
<region>NJ</region>
<code>07701-7020</code>
<country>US</country>
</postal>

<phone>+1 908 758 5254</phone>
<email>kaj@nvuxr.cc.bellcore.com</email>
</address>
</author>

<date year="1991" day="1" month="May" />

<abstract>
<t>This memo defines an experimental portion of the Management Information Base (MIB) for use with network management protocols in TCP/IP-based internets.  In particular, this memo defines MIB objects for representing DS3 physical interfaces.  Implementors should consult in addition to this memo the companion document that   describes that DS1 managed objects.</t>
</abstract>
</front>

<seriesInfo value="1233" name="RFC" />
</reference>


<reference target2="reference.RFC.1234.xml" anchor="RFC1234">
<front>
<title abbrev="IPX on IP">Tunneling IPX traffic through IP networks</title>
<author fullname="Don Provan" initials="D." surname="Provan">
<organization>Novell, Inc.</organization>

<address>
<postal>
<street>2180 Fortune Drive</street>
<city>San Jose</city>
<region>CA</region>
<code>95131</code>
<country>US</country>
</postal>

<phone>+1 408 473 8440</phone>
<email>donp@Novell.Com</email>
</address>
</author>

<date year="1991" day="1" month="June" />
</front>

<seriesInfo value="1234" name="RFC" />
</reference>


<reference target2="reference.RFC.1235.xml" anchor="RFC1235">
<front>
<title abbrev="CFDP">Coherent File Distribution Protocol</title>
<author fullname="John Ioannidis" initials="J." surname="Ioannidis">
<organization>Columbia University, Department of Computer Science</organization>

<address>
<postal>
<street>450 Computer Science</street>
<city>New York</city>
<region>NY</region>
<code>10027</code>
<country>US</country>
</postal>

<email>ji@cs.columbia.edu</email>
</address>
</author>

<author fullname="Gerald Q. Maguire, Jr." initials="G." surname="Maquire">
<organization>Columbia University, Department of Computer Science</organization>

<address>
<postal>
<street>450 Computer Science</street>
<city>New York</city>
<region>NY</region>
<code>10027</code>
<country>US</country>
</postal>

<phone>+1 212 854 2736</phone>
<email>maguire@cs.columbia.edu</email>
</address>
</author>

<date year="1991" day="1" month="June" />
</front>

<seriesInfo value="1235" name="RFC" />
</reference>


<reference target2="reference.RFC.1236.xml" anchor="RFC1236">
<front>
<title>IP to X.121 address mapping for DDN</title>
<author fullname="Luis F. Morales, Jr." initials="L." surname="Morales">
<organization>United States Army Information Systems Engineering Command (USAISEC)</organization>

<address>
<postal>
<street>ASQB-SEP-C</street>
<city>Fort Huachuca</city>
<region>AZ</region>
<code>85613-5300</code>
<country>US</country>
</postal>

<phone>+1 602 533 2873</phone>
<email>lmorales@huachuca-emh8.army.mil</email>
</address>
</author>

<author fullname="Phillip R. Hasse" initials="P." surname="Hasse">
<organization>United States Army Information Systems Engineering Command (USAISEC)</organization>

<address>
<postal>
<street>ASQB-SEP-C</street>
<city>Fort Huachuca</city>
<region>AZ</region>
<code>85613-5300</code>
<country>US</country>
</postal>

<phone>+1 602 533 2873</phone>
<email>phasse@huachuca-emh8.army.mil</email>
</address>
</author>

<date year="1991" day="1" month="June" />
</front>

<seriesInfo value="1236" name="RFC" />
</reference>


<reference target2="reference.RFC.1237.xml" anchor="RFC1237">
<front>
<title>Guidelines for OSI NSAP Allocation in the Internet</title>
<author fullname="Richard P. Colella" initials="R." surname="Colella">
<organization>National Institute of Standards &amp; Technology (NIST)</organization>

<address>
<postal>
<street>Building 225/Room B217</street>
<city>Gaithersburg</city>
<region>MD</region>
<code>20899</code>
<country>US</country>
</postal>

<phone>+1 301 975 3627</phone>
<email>colella@osi3.ncsl.nist.gov</email>
</address>
</author>

<author fullname="Ella P. Gardner" initials="E." surname="Gardner">
<organization>The MITRE Corporation</organization>

<address>
<postal>
<street>7525 Colshire Drive</street>
<city>McLean</city>
<region>VA</region>
<code>22102</code>
<country>US</country>
</postal>

<phone>+1 703 883 5826</phone>
<email>epg@gateway.mitre.org</email>
</address>
</author>

<author fullname="Ross Callon" initials="R." surname="Callon">
<organization>Digital Equipment Corporation (DEC)</organization>

<address>
<postal>
<street>550 King Street</street>
<street>1-2/A19</street>
<city>Littleton</city>
<region>MA</region>
<code>01460-1289</code>
<country>US</country>
</postal>

<phone>+1 508 486 5009</phone>
<email>Callon@bigfut.enet.dec.com</email>
</address>
</author>

<date year="1991" day="1" month="July" />

<abstract>
<t>The Internet is moving towards a multi-protocol environment that includes OSI. To support OSI in the Internet, an OSI lower layers infrastructure is required. This infrastructure comprises the connectionless network protocol (CLNP) and supporting routing protocols. Also required as part of this infrastructure are guidelines for network service access point (NSAP) address assignment. This paper provides guidelines for allocating NSAPs in the Internet.</t>

<t>This document provides our current best judgment for the allocation of NSAP addresses in the Internet. This is intended to guide initial deployment of OSI 8473 (Connectionless Network Layer Protocol) in the Internet, as well as to solicit comments. It is expected that these guidelines may be further refined and this document updated as a result of experience gained during this initial deployment.</t>
</abstract>
</front>

<seriesInfo value="1237" name="RFC" />
</reference>


<reference target2="reference.RFC.1238.xml" anchor="RFC1238">
<front>
<title abbrev="CLNS MIB">CLNS MIB for use with Connectionless Network Protocol (ISO 8473) and End System to Intermediate System (ISO 9542)</title>
<author fullname="Greg Satz" initials="G." surname="Satz">
<organization>cisco Systems, Inc.</organization>

<address>
<postal>
<street>1350 Willow Road</street>
<city>Menlo Park</city>
<region>CA</region>
<code>94025</code>
<country>US</country>
</postal>

<phone>+1 415 326 1941</phone>
<email>Satz@CISCO.COM</email>
</address>
</author>

<date year="1991" day="1" month="June" />
</front>

<seriesInfo value="1238" name="RFC" />
</reference>


<reference target2="reference.RFC.1239.xml" anchor="RFC1239">
<front>
<title abbrev="Reassignment of Exp MIBs to Std MIBs">Reassignment of experimental MIBs to standard MIBs</title>
<author fullname="Joyce K. Reynolds" initials="J." surname="Reynolds">
<organization>USC/Information Sciences Institute</organization>

<address>
<postal>
<street>4676 Admiralty Way</street>
<city>Marina del Rey</city>
<region>CA</region>
<code>90292-6695</code>
<country>US</country>
</postal>

<phone>+1 213 822 1511</phone>
<email>jkrey@isi.edu</email>
</address>
</author>

<date year="1991" day="1" month="June" />
</front>

<seriesInfo value="1239" name="RFC" />
</reference>


<reference target2="reference.RFC.1240.xml" anchor="RFC1240">
<front>
<title abbrev="OSI on top of UDP">OSI connectionless transport services on top of UDP: Version 1</title>
<author fullname="Chikong Shue" initials="C." surname="Shue">
<organization>Open Software Foundation, Inc.</organization>

<address>
<postal>
<street>11 Cambridge Center</street>
<city>Cambridge</city>
<region>MA</region>
<code>02142</code>
<country>US</country>
</postal>

<phone>+1 617 621 8972</phone>
<email>chi@osf.org</email>
</address>
</author>

<author fullname="William Haggerty" initials="W." surname="Haggerty">
<organization>Wang Laboratories, Inc.</organization>

<address>
<postal>
<street>1 Industrial Ave</street>
<city>Lowell</city>
<region>MA</region>
<code>01851</code>
<country>US</country>
</postal>

<phone>+1 508 967 3403</phone>
<email>bill@comm.wang.com</email>
</address>
</author>

<author fullname="Kurt Dobbins" initials="K." surname="Dobbins">
<organization>Cabletron, Inc.</organization>

<address>
<postal>
<street>35 Industrial Way</street>
<city>Rochester</city>
<region>NH</region>
<code>03867</code>
<country>US</country>
</postal>

<phone>+1 603 332 9400</phone>
</address>
</author>

<date year="1991" day="1" month="June" />
</front>

<seriesInfo value="1240" name="RFC" />
</reference>


<reference target2="reference.RFC.1241.xml" anchor="RFC1241">
<front>
<title abbrev="Internet Encapsulation">Scheme for an internet encapsulation protocol: Version 1</title>
<author fullname="Robert A. Woodburn" initials="R." surname="Woodburn">
<organization>Science Applications International Corporation (SAIC)</organization>

<address>
<postal>
<street>8619 Westwood Center Drive</street>
<city>Vienna</city>
<region>VA</region>
<code>22182</code>
<country>US</country>
</postal>

<phone>+1 703 734 9000</phone>
<email>woody@cseic.saic.com</email>
</address>
</author>

<author fullname="David L. Mills" initials="D." surname="Mills">
<organization>University of Delaware, Electrical Engineering Department</organization>

<address>
<postal>
<street />
<city>Newark</city>
<region>DE</region>
<code>19716</code>
<country>US</country>
</postal>

<phone>+1 302 451 8247</phone>
<email>mills@udel.edu</email>
</address>
</author>

<date year="1991" day="1" month="July" />
</front>

<seriesInfo value="1241" name="RFC" />
</reference>


<reference target2="reference.RFC.1242.xml" anchor="RFC1242">
<front>
<title abbrev="Benchmarking Terminology">Benchmarking terminology for network interconnection devices</title>
<author fullname="Scott Bradner" initials="S." surname="Bradner">
<organization>Harvard University</organization>

<address>
<postal>
<street>33 Kirkland Street</street>
<street>William James Hall 1232</street>
<city>Cambridge</city>
<region>MA</region>
<code>02138</code>
<country>US</country>
</postal>

<phone>+1 617 495 3864</phone>
<email>SOB@HARVARD.HARVARD.EDU</email>
</address>
</author>

<date year="1991" day="1" month="July" />

<abstract>
<t>This memo discusses and defines a number of terms that are used in describing performance benchmarking tests and the results of such tests.  The terms defined in this memo will be used in additional memos to define specific benchmarking tests and the suggested format to be used in reporting the results of each of the tests.  This memo is a product of the Benchmarking Methodology Working Group (BMWG) of the Internet Engineering Task Force (IETF).</t>
</abstract>
</front>

<seriesInfo value="1242" name="RFC" />
</reference>


<reference target2="reference.RFC.1243.xml" anchor="RFC1243">
<front>
<title abbrev="AppleTalk MIB">AppleTalk Management Information Base</title>
<author fullname="Steven Waldbusser" initials="S." surname="Waldbusser">
<organization>Carnegie Mellon University</organization>

<address>
<postal>
<street>4910 Forbes Ave.</street>
<city>Pittsburgh</city>
<region>PA</region>
<code>15213</code>
<country>US</country>
</postal>

<email>waldbusser@andrew.cmu.edu</email>
</address>
</author>

<date year="1991" day="1" month="July" />

<abstract>
<t>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 AppleTalk networks.</t>
</abstract>
</front>

<seriesInfo value="1243" name="RFC" />
</reference>


<reference target2="reference.RFC.1244.xml" anchor="RFC1244">
<front>
<title>Site Security Handbook</title>
<author fullname="J. Paul Holbrook" initials="J." surname="Holbrook">
<organization>CICNet, Inc.</organization>

<address>
<postal>
<street>2901 Hubbard</street>
<city>Ann Arbor</city>
<region>MI</region>
<code>48105</code>
<country>US</country>
</postal>

<phone>+1 313 998 7680</phone>
<email>holbrook@cic.net</email>
</address>
</author>

<author fullname="Joyce K. Reynolds" initials="J." surname="Reynolds">
<organization>University of Southern California, Information Sciences Institute</organization>

<address>
<postal>
<street>4676 Admiralty Way</street>
<city>Marina del Rey</city>
<region>CA</region>
<code>90292</code>
<country>US</country>
</postal>

<phone>+1 213 822 1511</phone>
<email>JKREY@ISI.EDU</email>
</address>
</author>

<date year="1991" day="1" month="July" />
</front>

<seriesInfo value="1244" name="RFC" />
</reference>


<reference target2="reference.RFC.1245.xml" anchor="RFC1245">
<front>
<title>OSPF Protocol Analysis</title>
<author fullname="John Moy" initials="J." surname="Moy">
<organization>Proteon Inc.</organization>

<address>
<postal>
<street>2 Technology Drive</street>
<city>Westborough</city>
<region>MA</region>
<code>01581</code>
<country>US</country>
</postal>

<phone>+1 508 898 2800</phone>
<email>jmoy@proteon.com</email>
</address>
</author>

<date year="1991" day="1" month="July" />

<abstract>
<t>This is the first of two reports on the OSPF protocol. These reports are required by the IAB/ IESG in order for an Internet routing protocol to advance to Draft Standard Status. OSPF is a TCP/IP routing protocol, designed to be used internal to an Autonomous System (in other words, OSPF is an Interior Gateway Protocol).</t>

<t>Version 1 of the OSPF protocol was published in RFC 1131. Since then OSPF version 2 has been developed. Version 2 has been documented in RFC 1247.  The changes between version 1 and version 2 of the OSPF protocol are explained in Appendix F of RFC 1247. It is OSPF Version 2 that is the subject of this report.</t>

<t>This report attempts to summarize the key features of OSPF V2. It also attempts to analyze how the protocol will perform and scale in the Internet.</t>
</abstract>
</front>

<seriesInfo value="1245" name="RFC" />
</reference>


<reference target2="reference.RFC.1246.xml" anchor="RFC1246">
<front>
<title abbrev="Experience with OSPF">Experience with the OSPF Protocol</title>
<author fullname="John Moy" initials="J." surname="Moy">
<organization>Proteon Inc.</organization>

<address>
<postal>
<street>2 Technology Drive</street>
<city>Westborough</city>
<region>MA</region>
<code>01581</code>
<country>US</country>
</postal>

<phone>+1 508 898 2800</phone>
<email>jmoy@proteon.com</email>
</address>
</author>

<date year="1991" day="1" month="July" />

<abstract>
<t>This is the second of two reports on the OSPF protocol. These reports are required by the IAB/IESG in order for an Internet routing protocol to advance to Draft Standard Status. OSPF is a TCP/IP routing protocol, designed to be used internal to an Autonomous System (in other words, OSPF is an Interior Gateway Protocol).</t>

<t>OSPF is currently designated as a Proposed Standard. Version 1 of the OSPF protocol was published in RFC 1131. Since then OSPF version 2 has been developed. Version 2 has been documented in RFC 1247.  The changes between version 1 and version 2 of the OSPF protocol are explained in Appendix F of RFC 1247. It is OSPF Version 2 that is the subject of this report.</t>

<t>This report documents experience with OSPF V2. This includes reports on interoperability testing, field experience, simulations and the current state of OSPF implementations. It also presents a summary of the OSPF Management Information Base (MIB), and a summary of OSPF authentication mechanism.</t>

<t>Please send comments to ospf@trantor.umd.edu.</t>
</abstract>
</front>

<seriesInfo value="1246" name="RFC" />
</reference>


<reference target2="reference.RFC.1247.xml" anchor="RFC1247">
<front>
<title>OSPF Version 2</title>
<author fullname="John Moy" initials="J." surname="Moy">
<organization>Proteon, Inc.</organization>

<address>
<postal>
<street>2 Technology Drive</street>
<city>Westborough</city>
<region>MA</region>
<code>01581</code>
<country>US</country>
</postal>

<phone>+1 508 898 2800</phone>
<email>jmoy@proteon.com</email>
</address>
</author>

<date year="1991" day="1" month="July" />

<abstract>
<t>This memo documents version 2 of the OSPF protocol.  OSPF is a link-state based routing protocol.  It is designed to be run internal to a single Autonomous System.  Each OSPF router maintains an identical database describing the Autonomous System's topology.  From this database, a routing table is calculated by constructing a shortest-path tree.</t>

<t>OSPF recalculates routes quickly in the face of topological changes, utilizing a minimum of routing protocol traffic.  OSPF provides support for equal-cost multipath.  Separate routes can be calculated for each IP type of service.  An area routing capability is provided, enabling an additional level of routing protection and a reduction in routing protocol traffic.  In addition, all OSPF routing protocol exchanges are authenticated.</t>

<t>Version 1 of the OSPF protocol was documented in RFC 1131.  The differences between the two versions are explained in Appendix F.</t>

<t>Please send comments to ospf@trantor.umd.edu.</t>
</abstract>
</front>

<seriesInfo value="1247" name="RFC" />
</reference>


<reference target2="reference.RFC.1248.xml" anchor="RFC1248">
<front>
<title abbrev="OSPF Version 2 MIB">OSPF Version 2 Management Information Base</title>
<author fullname="Fred Baker" initials="F." surname="Baker">
<organization>Advanced Computer Communications (ACC)</organization>

<address>
<postal>
<street>720 Santa Barbara Street</street>
<city>Santa Barbara</city>
<region>CA</region>
<code>93101</code>
<country>US</country>
</postal>

<phone>+1 805 963 9431</phone>
<email>fbaker@acc.com</email>
</address>
</author>

<author fullname="Rob Coltun" initials="R." surname="Coltun">
<organization>Computer Science Center</organization>

<address>
<postal>
<street>Computer and Space Sciences Building</street>
<city>College Park</city>
<region>MD</region>
<code>20742</code>
<country>US</country>
</postal>

<phone>+1 301 921 8600</phone>
<email>rcoltun@ni.umd.edu</email>
</address>
</author>

<date year="1991" day="1" month="July" />

<abstract>
<t>This memo defines an experimental 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 OSPF Version 2.</t>
</abstract>
</front>

<seriesInfo value="1248" name="RFC" />
</reference>


<reference target2="reference.RFC.1249.xml" anchor="RFC1249">
<front>
<title abbrev="DIXIE">DIXIE Protocol Specification</title>
<author fullname="Tim Howes" initials="T." surname="Howes">
<organization>University of Michigan, Information Technology Division</organization>

<address>
<postal>
<street>535 West William St.</street>
<city>Ann Arbor</city>
<region>MI</region>
<code>48103-4943</code>
<country>US</country>
</postal>

<phone>+1 313 764 2278</phone>
<email>tim@umich.edu</email>
</address>
</author>

<author fullname="Mark Smith" initials="M." surname="Smith">
<organization>University of Michigan, Information Technology Division</organization>

<address>
<postal>
<street>535 West William St.</street>
<city>Ann Arbor</city>
<region>MI</region>
<code>48103-4943</code>
<country>US</country>
</postal>

<phone>+1 313 764 2277</phone>
<email>mcs@umich.edu</email>
</address>
</author>

<author fullname="Bryan Beecher" initials="B." surname="Beecher">
<organization>University of Michigan, Information Technology Division</organization>

<address>
<postal>
<street>535 West William St.</street>
<city>Ann Arbor</city>
<region>MI</region>
<code>48103-4943</code>
<country>US</country>
</postal>

<phone>+1 313 764 4050</phone>
<email>bryan@umich.edu</email>
</address>
</author>

<date year="1991" day="1" month="August" />
</front>

<seriesInfo value="1249" name="RFC" />
</reference>


<reference target2="reference.RFC.1250.xml" anchor="RFC1250">
<front>
<title abbrev="IAB Standards">IAB Official Protocol Standards</title>
<author fullname="Jon Postel" initials="J." surname="Postel">
<organization>USC/Information Sciences Institute</organization>

<address>
<postal>
<street>4676 Admiralty Way</street>
<city>Marina del Rey</city>
<region>CA</region>
<code>90292</code>
<country>US</country>
</postal>

<phone>+1 213 822 1511</phone>
<facsimile>+1 213 823 6714</facsimile>
<email>Postel@ISI.EDU</email>
</address>
</author>

<date year="1991" day="1" month="August" />
</front>

<seriesInfo value="1250" name="RFC" />
</reference>


<reference target2="reference.RFC.1251.xml" anchor="RFC1251">
<front>
<title abbrev="Who&apos;s Who">Who's Who in the Internet: Biographies of IAB, IESG and IRSG Members</title>
<author fullname="Gary Scott Malkin" initials="G." surname="Malkin">
<organization>FTP Software, Inc.</organization>

<address>
<postal>
<street>26 Princess Street</street>
<city>Wakefield</city>
<region>MA</region>
<code>01880</code>
<country>US</country>
</postal>

<phone>+1 617 246 0900</phone>
<email>gmalkin@ftp.com</email>
</address>
</author>

<date year="1991" day="1" month="August" />
</front>

<seriesInfo value="1251" name="RFC" />
</reference>


<reference target2="reference.RFC.1252.xml" anchor="RFC1252">
<front>
<title abbrev="OSPF Version 2 MIB">OSPF Version 2 Management Information Base</title>
<author fullname="Fred Baker" initials="F." surname="Baker">
<organization>Advanced Computer Communications</organization>

<address>
<postal>
<street>720 Santa Barbara Street</street>
<city>Santa Barbara</city>
<region>CA</region>
<code>93101</code>
<country>US</country>
</postal>

<phone>+1 805 963 9431</phone>
<email>fbaker@acc.com</email>
</address>
</author>

<author fullname="Rob Coltun" initials="R." surname="Coltun">
<organization>Computer Science Center</organization>

<address>
<postal>
<street>Computer and Space Sciences Building</street>
<city>College Park</city>
<region>MD</region>
<code>20742</code>
<country>US</country>
</postal>

<phone>+1 301 921 8600</phone>
<email>rcoltun@ni.umd.edu</email>
</address>
</author>

<date year="1991" day="1" month="August" />

<abstract>
<t>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 OSPF Version 2.</t>
</abstract>
</front>

<seriesInfo value="1252" name="RFC" />
</reference>


<reference target2="reference.RFC.1253.xml" anchor="RFC1253">
<front>
<title abbrev="OSPF Version 2 MIB">OSPF Version 2 Management Information Base</title>
<author fullname="Fred Baker" initials="F." surname="Baker">
<organization>Advanced Computer Communications</organization>

<address>
<postal>
<street>720 Santa Barbara Street</street>
<city>Santa Barbara</city>
<region>CA</region>
<code>93101</code>
<country>US</country>
</postal>

<phone>+1 805 963 9431</phone>
<email>fbaker@acc.com</email>
</address>
</author>

<author fullname="Rob Coltun" initials="R." surname="Coltun">
<organization>Computer Science Center</organization>

<address>
<postal>
<street>Computer and Space Sciences Building</street>
<city>College Park</city>
<region>MD</region>
<code>20742</code>
<country>US</country>
</postal>

<phone>+1 301 921 8600</phone>
<email>rcoltun@ni.umd.edu</email>
</address>
</author>

<date year="1991" day="1" month="August" />

<abstract>
<t>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 OSPF Version 2.</t>
</abstract>
</front>

<seriesInfo value="1253" name="RFC" />
</reference>


<reference target2="reference.RFC.1254.xml" anchor="RFC1254">
<front>
<title>Gateway Congestion Control Survey</title>
<author fullname="Allison Mankin" initials="A." surname="Mankin">
<organization>The MITRE Corporation</organization>

<address>
<postal>
<street>7525 Colshire Drive</street>
<street>M/S W425</street>
<city>McLean</city>
<region>VA</region>
<code>22102</code>
<country>US</country>
</postal>

<email>mankin@gateway.mitre.org</email>
</address>
</author>

<author fullname="K. K. Ramakrishnan" initials="K." surname="Ramakrishnan">
<organization>Digital Equipment Corporation (DEC)</organization>

<address>
<postal>
<street>550 King Street</street>
<street>M/S LKG1-2/A19</street>
<city>Maynard</city>
<region>MA</region>
<code>01754</code>
<country>US</country>
</postal>

<email>rama@kalvi.enet.dec.com</email>
</address>
</author>

<date year="1991" day="1" month="August" />

<abstract>
<t>The growth of network intensive Internet applications has made gateway congestion control a high priority.  The IETF Performance and Congestion Control Working Group surveyed and reviewed gateway congestion control and avoidance approaches.  The purpose of this paper is to present our review of the congestion control approaches, as a way of encouraging new discussion and experimentation. Included in the survey are Source Quench, Random Drop, Congestion Indication (DEC Bit), and Fair Queueing.  The task remains for Internet implementors to determine and agree on the most effective mechanisms for controlling gateway congestion.</t>
</abstract>
</front>

<seriesInfo value="1254" name="RFC" />
</reference>


<reference target2="reference.RFC.1255.xml" anchor="RFC1255">
<front>
<title>A Naming Scheme for c=US</title>
<author fullname="Theodore H. Myer" initials="T." surname="Myer">
<organization>North American Directory Forum</organization>

<address>
<postal>
<street>3055 Q Street NW</street>
<city>Washington</city>
<region>DC</region>
<code>20007</code>
<country>US</country>
</postal>

<phone>+1 202 342 2727</phone>
</address>
</author>

<date year="1991" day="1" month="September" />
</front>

<seriesInfo value="1255" name="RFC" />
</reference>


<reference target2="reference.RFC.1256.xml" anchor="RFC1256">
<front>
<title>ICMP Router Discovery Messages</title>
<author fullname="Stephen E. Deering" initials="S." surname="Deering">
<organization>Xerox, Palo Alto Research Center</organization>

<address>
<postal>
<street>3333 Coyote Hill Road</street>
<city>Palo Alto</city>
<region>CA</region>
<code>94304</code>
<country>US</country>
</postal>

<phone>+1 415 494 4839</phone>
<email>deering@xerox.com</email>
</address>
</author>

<date year="1991" day="1" month="September" />

<abstract>
<t>This document specifies an extension of the Internet Control Message Protocol (ICMP) to enable hosts attached to multicast or broadcast networks to discover the IP addresses of their neighboring routers.</t>
</abstract>
</front>

<seriesInfo value="1256" name="RFC" />
</reference>


<reference target2="reference.RFC.1257.xml" anchor="RFC1257">
<front>
<title abbrev="Isochronous and Jitter">Isochronous applications do not require jitter-controlled networks</title>
<author fullname="Craig Partridge" initials="C." surname="Partridge">
<organization>Swedish Institute of Computer Science</organization>

<address>
<postal>
<street>Box 1263</street>
<city>Kista</city>
<region />
<code>164 28</code>
<country>SE</country>
</postal>

<phone>+46 8 7521524</phone>
<email>craig@SICS.SE</email>
</address>
</author>

<date year="1991" day="1" month="September" />

<abstract>
<t>This memo argues that jitter control is not required for networks to support isochronous applications.  A network providing bandwidth and bounds delay is sufficient.  The implications for gigabit internetworking protocols are briefly considered.</t>
</abstract>
</front>

<seriesInfo value="1257" name="RFC" />
</reference>


<reference target2="reference.RFC.1258.xml" anchor="RFC1258">
<front>
<title>BSD Rlogin</title>
<author fullname="Brian Kantor" initials="B." surname="Kantor">
<organization>University of California at San Diego, Network Operations C-024</organization>

<address>
<postal>
<street />
<city>La Jolla</city>
<region>CA</region>
<code>92093-0214</code>
<country>US</country>
</postal>

<phone>+1 619 534 6865</phone>
<email>brian@UCSD.EDU</email>
</address>
</author>

<date year="1991" day="1" month="September" />
</front>

<seriesInfo value="1258" name="RFC" />
</reference>


<reference target2="reference.RFC.1259.xml" anchor="RFC1259">
<front>
<title abbrev="Building The Open Road">Building the open road: The NREN as test-bed for the national public network</title>
<author fullname="Mitchell Kapor" initials="M." surname="Kapor">
<organization>Electronic Frontier Foundation</organization>

<address>
<postal>
<street>155 Second Street</street>
<city>Cambridge</city>
<region>MA</region>
<code>02142</code>
<country>US</country>
</postal>

<phone>+1 617 864 1550</phone>
<email>mkapor@eff.org</email>
</address>
</author>

<date year="1991" day="1" month="September" />
</front>

<seriesInfo value="1259" name="RFC" />
</reference>


<reference target2="reference.RFC.1261.xml" anchor="RFC1261">
<front>
<title abbrev="Transition of NIC Services">Transition of Nic Services</title>
<author fullname="Scott Williamson" initials="S." surname="Williamson">
<organization>Network Solutions, Inc.</organization>

<address>
<postal>
<street>505 Huntmar Park Drive</street>
<city>Herndon</city>
<region>VA</region>
<code>22070</code>
<country>US</country>
</postal>

<phone>+1 703 802 8405</phone>
<email>scottw@DIIS.DDN.MIL</email>
</address>
</author>

<author fullname="Leslie Nobile" initials="L." surname="Nobile">
<organization>Network Solutions, Inc.</organization>

<address>
<postal>
<street>505 Huntmar Park Drive</street>
<city>Herndon</city>
<region>VA</region>
<code>22070</code>
<country>US</country>
</postal>

<phone>+1 703 802 8456</phone>
<email>leslie@DIIS.DDN.MIL</email>
</address>
</author>

<date year="1991" day="1" month="September" />
</front>

<seriesInfo value="1261" name="RFC" />
</reference>


<reference target2="reference.RFC.1262.xml" anchor="RFC1262">
<front>
<title abbrev="Measurement Guidelines">Guidelines for Internet Measurement Activities</title>
<author fullname="Vinton G. Cerf" initials="V." surname="Cerf">
<organization>Corporation for National Research Initiatives (CNRI), Internet Activities Board (IAB)</organization>

<address>
<postal>
<street>1895 Preston White Drive</street>
<street>Suite 100</street>
<city>Reston</city>
<region>VA</region>
<code>22091</code>
<country>US</country>
</postal>

<phone>+1 703 620 8990</phone>
<email>VCerf@NRI.RESTON.VA.US</email>
</address>
</author>

<date year="1991" day="1" month="October" />
</front>

<seriesInfo value="1262" name="RFC" />
</reference>


<reference target2="reference.RFC.1263.xml" anchor="RFC1263">
<front>
<title abbrev="TCP Extensions Considered Harmful">TCP Extensions Considered Harmful</title>
<author fullname="Sean O&apos;Malley" initials="S." surname="O&apos;Malley">
<organization>University of Arizona, Department of Computer Sciences</organization>

<address>
<postal>
<street />
<city>Tucson</city>
<region>AZ</region>
<code>85721</code>
<country>US</country>
</postal>

<phone>+1 602 621 8373</phone>
<email>sean@cs.arizona.edu</email>
</address>
</author>

<author fullname="Larry L. Peterson" initials="L.L." surname="Peterson">
<organization>University of Arizona, Department of Computer Sciences</organization>

<address>
<postal>
<street />
<city>Tucson</city>
<region>AZ</region>
<code>85721</code>
<country>US</country>
</postal>

<phone>+1 602 621 4231</phone>
<email>llp@cs.arizona.edu</email>
</address>
</author>

<date year="1991" day="1" month="October" />

<abstract>
<t>This RFC comments on recent proposals to extend TCP.  It argues that the backward compatible extensions proposed in RFC's 1072 and 1185 should not be pursued, and proposes an alternative way to evolve the Internet protocol suite.  Its purpose is to stimulate discussion in the Internet community.</t>
</abstract>
</front>

<seriesInfo value="1263" name="RFC" />
</reference>


<reference target2="reference.RFC.1264.xml" anchor="RFC1264">
<front>
<title abbrev="Routing Protocol Criteria">Internet Engineering Task Force Internet Routing Protocol Standardization Criteria</title>
<author fullname="Robert M. Hinden" initials="R." surname="Hinden">
<organization>Bolt Beranek and Newman, Inc. (BBN)</organization>

<address>
<postal>
<street>50 Moulton Street</street>
<city>Cambridge</city>
<region>MA</region>
<code>02138</code>
<country>US</country>
</postal>

<phone>+1 617 873 3757</phone>
<email>hinden@bbn.com</email>
</address>
</author>

<date year="1991" day="1" month="October" />
</front>

<seriesInfo value="1264" name="RFC" />
</reference>


<reference target2="reference.RFC.1265.xml" anchor="RFC1265">
<front>
<title>BGP Protocol Analysis</title>
<author fullname="Yakov Rekhter" initials="Y." surname="Rekhter">
<organization>IBM Corporation, T.J. Watson Research Center</organization>

<address>
<postal>
<street>P.O. Box 218</street>
<city>Yorktown Heights</city>
<region>NY</region>
<code>10598</code>
<country>US</country>
</postal>

<phone>+1 914 945 3896</phone>
<email>yakov@watson.ibm.com</email>
</address>
</author>

<date year="1991" day="1" month="October" />
</front>

<seriesInfo value="1265" name="RFC" />
</reference>


<reference target2="reference.RFC.1266.xml" anchor="RFC1266">
<front>
<title>Experience with the BGP Protocol</title>
<author fullname="Yakov Rekhter" initials="Y." surname="Rekhter">
<organization>IBM Corporation, T.J. Watson Research Center</organization>

<address>
<postal>
<street>P.O. Box 218</street>
<city>Yorktown Heights</city>
<region>NY</region>
<code>10598</code>
<country>US</country>
</postal>

<phone>+1 914 945 3896</phone>
<email>yakov@watson.ibm.com</email>
</address>
</author>

<date year="1991" day="1" month="October" />
</front>

<seriesInfo value="1266" name="RFC" />
</reference>


<reference target2="reference.RFC.1267.xml" anchor="RFC1267">
<front>
<title abbrev="BGP-3">Border Gateway Protocol 3 (BGP-3)</title>
<author fullname="Kirk Lougheed" initials="K." surname="Lougheed">
<organization>cisco Systems, Inc.</organization>

<address>
<postal>
<street>1525 O'Brien Drive</street>
<city>Menlo Park</city>
<region>CA</region>
<code>94025</code>
<country>US</country>
</postal>

<phone>+1 415 326 1941</phone>
<email>LOUGHEED@CISCO.COM</email>
</address>
</author>

<author fullname="Yakov Rekhter" initials="Y." surname="Rekhter">
<organization>IBM Corporation, T.J. Watson Research Center</organization>

<address>
<postal>
<street>P.O. Box 218</street>
<city>Yorktown Heights</city>
<region>NY</region>
<code>10598</code>
<country>US</country>
</postal>

<phone>+1 914 945 3896</phone>
<email>YAKOV@WATSON.IBM.COM</email>
</address>
</author>

<date year="1991" day="1" month="October" />
</front>

<seriesInfo value="1267" name="RFC" />
</reference>


<reference target2="reference.RFC.1268.xml" anchor="RFC1268">
<front>
<title abbrev="Application of BGP in the Internet">Application of the Border Gateway Protocol in the Internet</title>
<author fullname="Yakov Rekhter" initials="Y." surname="Rekhter">
<organization>IBM Corporation, T.J. Watson Research Center</organization>

<address>
<postal>
<street>P.O. Box 218</street>
<city>Yorktown Heights</city>
<region>NY</region>
<code>10598</code>
<country>US</country>
</postal>

<phone>+1 914 945 3896</phone>
<email>yakov@watson.ibm.com</email>
</address>
</author>

<author fullname="Phill Gross" initials="P." surname="Gross">
<organization>Advanced Network and Services (ANS)</organization>

<address>
<postal>
<street>100 Clearbrook Road</street>
<city>Elmsford</city>
<region>NY</region>
<code>10523</code>
<country>US</country>
</postal>

<phone>+1 914 789 5300</phone>
<email>pgross@NIS.ANS.NET</email>
</address>
</author>

<date year="1991" day="1" month="October" />

<abstract>
<t>This document, together with its companion document, "A Border Gateway Protocol (BGP-3)", define an inter-autonomous system routing protocol for the Internet.  "A Border Gateway Protocol (BGP-3)" defines the BGP protocol specification, and this document describes the usage of the BGP in the Internet.</t>

<t>Information about the progress of BGP can be monitored and/or reported on the BGP mailing list (iwg@rice.edu).</t>
</abstract>
</front>

<seriesInfo value="1268" name="RFC" />
</reference>


<reference target2="reference.RFC.1269.xml" anchor="RFC1269">
<front>
<title abbrev="BGP-3 MIB">Definitions of Managed Objects for the Border Gateway Protocol: Version 3</title>
<author fullname="Steven Willis" initials="S." surname="Willis">
<organization>Wellfleet Communications Inc.</organization>

<address>
<postal>
<street>15 Crosby Drive</street>
<city>Bedford</city>
<region>MA</region>
<code>01730</code>
<country>US</country>
</postal>

<phone>+1 617 275 2400</phone>
<email>swillis@wellfleet.com</email>
</address>
</author>

<author fullname="John Burruss" initials="J." surname="Burruss">
<organization>Wellfleet Communications Inc.</organization>

<address>
<postal>
<street>15 Crosby Drive</street>
<city>Bedford</city>
<region>MA</region>
<code>01730</code>
<country>US</country>
</postal>

<phone>+1 617 275 2400</phone>
<email>jburruss@wellfleet.com</email>
</address>
</author>

<date year="1991" day="1" month="October" />

<abstract>
<t>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 Border Gateway Protocol,.</t>
</abstract>
</front>

<seriesInfo value="1269" name="RFC" />
</reference>


<reference target2="reference.RFC.1270.xml" anchor="RFC1270">
<front>
<title>SNMP Communications Services</title>
<author fullname="Frank Kastenholz" initials="F." surname="Kastenholz">
<organization>Clearpoint Research Corporation</organization>

<address>
<postal>
<street>35 Parkwood Drive</street>
<city>Hopkinton</city>
<region>MA</region>
<code>01748</code>
<country>US</country>
</postal>

<phone>+1 508 435 2000</phone>
<email>kasten@europa.clearpoint.com</email>
</address>
</author>

<date year="1991" day="1" month="October" />

<abstract>
<t>This memo is being distributed to members of the Internet community as an Informational RFC.  The intent is to present a discussion on the issues relating to the communications services for SNMP.  While the issues discussed may not be directly relevant to the research problems of the Internet, they may be interesting to a number of researchers and implementors.</t>
</abstract>
</front>

<seriesInfo value="1270" name="RFC" />
</reference>


<reference target2="reference.RFC.1271.xml" anchor="RFC1271">
<front>
<title abbrev="Remote Network Monitoring MIB">Remote Network Monitoring Management Information Base</title>
<author fullname="Steven Waldbusser" initials="S." surname="Waldbusser">
<organization>Carnegie Mellon University</organization>

<address>
<postal>
<street>4910 Forbes Ave.</street>
<city>Pittsburgh</city>
<region>PA</region>
<code>15213</code>
<country>US</country>
</postal>

<phone>+1 412 268 6628</phone>
<email>waldbusser@andrew.cmu.edu</email>
</address>
</author>

<date year="1991" day="1" month="November" />

<abstract>
<t>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 remote network monitoring devices.</t>
</abstract>
</front>

<seriesInfo value="1271" name="RFC" />
</reference>


<reference target2="reference.RFC.1272.xml" anchor="RFC1272">
<front>
<title abbrev="Internet Accounting: Background">Internet Accounting: Background</title>
<author fullname="Cyndi Mills" initials="C." surname="Mills">
<organization>Bolt, Beranek, &amp; Newman</organization>

<address>
<postal>
<street>150 Cambridge Park Drive</street>
<city>Cambridge</city>
<region>MA</region>
<code>02140</code>
<country>US</country>
</postal>

<phone>+1 617 873 4143</phone>
<email>cmills@bbn.com</email>
</address>
</author>

<author fullname="Donald Hirsh" initials="D." surname="Hirsh">
<organization>Meridian Technology Corporation</organization>

<address>
<postal>
<street>11 McBride Corporate Center Drive</street>
<street>Suite 250</street>
<city>Chesterfield</city>
<region>MO</region>
<code>63005</code>
<country>US</country>
</postal>

<phone>+1 314 532 7708</phone>
<email>hirsh@meridian.uucp</email>
</address>
</author>

<author fullname="Gregory Ruth" initials="G." surname="Ruth">
<organization>Bolt, Beranek, &amp; Newman</organization>

<address>
<postal>
<street>150 Cambridge Park Drive</street>
<city>Cambridge</city>
<region>MA</region>
<code>02140</code>
<country>US</country>
</postal>

<phone>+1 617 873 3150</phone>
<email>gruth@bbn.com</email>
</address>
</author>

<date year="1991" day="1" month="November" />
</front>

<seriesInfo value="1272" name="RFC" />
</reference>


<reference target2="reference.RFC.1273.xml" anchor="RFC1273">
<front>
<title abbrev="A Measurement Study">Measurement Study of Changes in Service-Level Reachability in the Global TCP/IP Internet: Goals, Experimental Design, Implementation, and Policy Considerations</title>
<author fullname="Michael F. Schwartz" initials="M." surname="Schwartz">
<organization>University of Colorado, Department of Computer Science</organization>

<address>
<postal>
<street>Campus Box 430</street>
<city>Boulder</city>
<region>CO</region>
<code>80309-0430</code>
<country>US</country>
</postal>

<phone>+1 303 492 3902</phone>
<email>schwartz@cs.colorado.edu</email>
</address>
</author>

<date year="1991" day="1" month="November" />

<abstract>
<t>In this report we discuss plans to carry out a longitudinal measurement study of changes in service-level reachability in the global TCP/IP Internet.  We overview our experimental design, considerations of network and remote site load, mechanisms used to control the measurement collection process, and network appropriate use and privacy issues, including our efforts to inform sites measured by this study.  A list of references and information on how to contact the Principal Investigator are included.</t>
</abstract>
</front>

<seriesInfo value="1273" name="RFC" />
</reference>


<reference target2="reference.RFC.1274.xml" anchor="RFC1274">
<front>
<title abbrev="COSINE and Internet X.500 Schema">The COSINE and Internet X.500 Schema</title>
<author fullname="Paul Barker" initials="P." surname="Barker">
<organization>University College London, Department of Computer Science</organization>

<address>
<postal>
<street>Gower Street</street>
<city>London</city>
<region>England</region>
<code>WC1E 6BT</code>
<country>UK</country>
</postal>

<phone>+44 71 3807366</phone>
<email>P.Barker@cs.ucl.ac.uk</email>
</address>
</author>

<author fullname="Steve Kille" initials="S." surname="Kille">
<organization>University College London, Department of Computer Science</organization>

<address>
<postal>
<street>Gower Street</street>
<city>London</city>
<region>England</region>
<code>WC1E 6BT</code>
<country>UK</country>
</postal>

<phone>+44 71 3807294</phone>
<email>S.Kille@cs.ucl.ac.uk</email>
</address>
</author>

<date year="1991" month="November" />

<abstract>
<t>This document suggests an X.500 Directory Schema, or Naming Architecture, for use in the COSINE and Internet X.500 pilots.  The schema is independent of any specific implementation.  As well as indicating support for the standard object classes and attributes, a large number of generally useful object classes and attributes are also defined.  An appendix to this document includes a machine processable version of the schema.</t>

<t>This document also proposes a mechanism for allowing the schema to evolve in line with emerging requirements.  Proformas to support this process are included.</t>

<t>Corrections and additions to the schema should be sent to na-update@cs.ucl.ac.uk list, as described within.</t>
</abstract>
</front>

<seriesInfo value="1274" name="RFC" />
</reference>


<reference target2="reference.RFC.1275.xml" anchor="RFC1275">
<front>
<title abbrev="Replication Requirements">Replication Requirements to provide an Internet Directory using X.500</title>
<author fullname="Steve Hardcastle-Kille" initials="S." surname="Hardcastle-Kille">
<organization>University College London, Department of Computer Science</organization>

<address>
<postal>
<street>Gower Street</street>
<city>London</city>
<region>England</region>
<code>WC1E 6BT</code>
<country>UK</country>
</postal>

<phone>+44 71 3807294</phone>
<email>S.Kille@CS.UCL.AC.UK</email>
</address>
</author>

<date year="1991" month="November" />

<abstract>
<t>This RFCconsiders certain deficiencies of the 1988 X.500 standard, which need to be addressed before an effective open Internet Directory can be established using these protocols and services.  The only areas considered are primary problems, to which solutions must be found before a pilot can be deployed.  This RFCconcerns itself with deficiencies which can only be addressed by use of ditional protocol or procedures for distributed operation.</t>
</abstract>
</front>

<seriesInfo value="1275" name="RFC" />
</reference>


<reference target2="reference.RFC.1276.xml" anchor="RFC1276">
<front>
<title abbrev="Internet Directory Replication">Replication and Distributed Operations extensions to provide an Internet Directory using X.500</title>
<author fullname="Steve Hardcastle-Kille" initials="S." surname="Hardcastle-Kille">
<organization>University College London, Department of Computer Science</organization>

<address>
<postal>
<street>Gower Street</street>
<city>London</city>
<region>England</region>
<code>WC1E 6BT</code>
<country>UK</country>
</postal>

<phone>+44 71 3807294</phone>
<email>S.Kille@CS.UCL.AC.UK</email>
</address>
</author>

<date year="1991" month="November" />

<abstract>
<t>Some requirements on extensions to X.500 are described in the RFC, in order to build an Internet Directory using  X.500(1988).  This document specifies a set of solutions to the problems raised.  These solutions are based on some work done for the QUIPU implementation, and demonstrated to be effective in a number of directory pilots.  By documenting a de facto standard, rapid progress can be made towards a full-scale pilot. These procedures are an INTERIM approach.  There are known deficiencies, both in terms of manageability and scalability. Transition to standard approaches are planned when appropriate standards are available.  This RFCwill be obsoleted at this point.</t>
</abstract>
</front>

<seriesInfo value="1276" name="RFC" />
</reference>


<reference target2="reference.RFC.1277.xml" anchor="RFC1277">
<front>
<title abbrev="Encoding Network Addresses">Encoding Network Addresses to Support Operation over Non-OSI Lower Layers</title>
<author fullname="Steve Hardcastle-Kille" initials="S." surname="Hardcastle-Kille">
<organization>University College London, Department of Computer Science</organization>

<address>
<postal>
<street>Gower Street</street>
<city>London</city>
<region>England</region>
<code>WC1E 6BT</code>
<country>UK</country>
</postal>

<phone>+44 71 3807294</phone>
<email>S.Kille@CS.UCL.AC.UK</email>
</address>
</author>

<date year="1991" month="November" />

<abstract>
<t>The OSI Directory specifies an encoding of Presentation Address, which utilises OSI Network Addresses as defined in the OSI Network Layer standards. The OSI Directory, and  any OSI application utilising the OSI Directory must be able use these Network Addresses to identify end systems.  Currently, OSI applications are often run over lower layers other than the OSI Network Service.  It is neither reasonable nor desirable for groups wishing to investigate and use OSI Applications in conjunction with the OSI Directory to be dependent on a global OSI Network Service.  This document defines a new network address format, and rules for using some existing network address formats.  The scope of this document is:</t>

<t>1.  Any TCP/IP network supporting COTS using RFC 1006.</t>

<t>2.  Any mapping of COTS onto X.25 (usually X.25(80)), where X.25 is not used to provide CONS (i.e., only DTE and not Network address is carried).</t>

<t>The approach could also be extended to use with other means of providing COTS (or CLTS). It is not appropriate for use where CONS or CLNS is used to provide COTS (or CLTS).</t>
</abstract>
</front>

<seriesInfo value="1277" name="RFC" />
</reference>


<reference target2="reference.RFC.1278.xml" anchor="RFC1278">
<front>
<title abbrev="String encoded P-Address">A string encoding of Presentation Address</title>
<author fullname="Steve Hardcastle-Kille" initials="S." surname="Hardcastle-Kille">
<organization>University College London, Department of Computer Science</organization>

<address>
<postal>
<street>Gower Street</street>
<city>London</city>
<region>England</region>
<code>WC1E 6BT</code>
<country>UK</country>
</postal>

<phone>+44 71 3807294</phone>
<email>S.Kille@CS.UCL.AC.UK</email>
</address>
</author>

<date year="1991" month="November" />

<abstract>
<t>There are a number of environments where a simple string encoding of Presentation Address is desirable.  This specification defines such a representation.</t>
</abstract>
</front>

<seriesInfo value="1278" name="RFC" />
</reference>


<reference target2="reference.RFC.1279.xml" anchor="RFC1279">
<front>
<title>X.500 and Domains</title>
<author fullname="Steve Hardcastle-Kille" initials="S." surname="Hardcastle-Kille">
<organization>University College London, Department of Computer Science</organization>

<address>
<postal>
<street>Gower Street</street>
<city>London</city>
<region>England</region>
<code>WC1E 6BT</code>
<country>UK</country>
</postal>

<phone>+44 71 3807294</phone>
<email>S.Kille@CS.UCL.AC.UK</email>
</address>
</author>

<date year="1991" month="November" />

<abstract>
<t>This RFCconsiders X.500 in relation to Internet and UK Domains.  A basic model of X.500 providing a higher level and more descriptive naming structure is emphasised.  In addition, a mapping of domains onto X.500 is proposed, which gives a range of new management and user facilities over and above those currently available.  This specification proposes an experimental new mechanism to access and manage domain information on the Internet and in the UK Academic Community.  There is no current intention to provide an operational replacement for DNS.</t>
</abstract>
</front>

<seriesInfo value="1279" name="RFC" />
</reference>


<reference target2="reference.RFC.1280.xml" anchor="RFC1280">
<front>
<title abbrev="IAB Standards">IAB Official Protocol Standards</title>
<author fullname="Jon Postel" initials="J." surname="Postel">
<organization>USC/Information Sciences Institute</organization>

<address>
<postal>
<street>4676 Admiralty Way</street>
<city>Marina del Rey</city>
<region>CA</region>
<code>90292</code>
<country>US</country>
</postal>

<phone>+1 310 822 1511</phone>
<facsimile>+1 310 823 6714</facsimile>
<email>Postel@ISI.EDU</email>
</address>
</author>

<date year="1992" month="March" />
</front>

<seriesInfo value="1280" name="RFC" />
</reference>


<reference target2="reference.RFC.1281.xml" anchor="RFC1281">
<front>
<title abbrev="Guidelines for the Secure Operation">Guidelines for the Secure Operation of the Internet</title>
<author fullname="Richard D. Pethia" initials="R." surname="Pethia">
<organization>Carnegie Mellon University, Software Engineering Institute</organization>

<address>
<postal>
<street />
<city>Pittsburgh</city>
<region>PA</region>
<code>15213-3890</code>
<country>US</country>
</postal>

<phone>+1 412 268 7739</phone>
<facsimile>+1 412 268 6989</facsimile>
<email>rdp@cert.sei.cmu.edu</email>
</address>
</author>

<author fullname="Stephen D. Crocker" initials="S." surname="Crocker">
<organization>Trusted Information Systems, Inc.</organization>

<address>
<postal>
<street>3060 Washington Road</street>
<city>Glenwood</city>
<region>MD</region>
<code>21738</code>
<country>US</country>
</postal>

<phone>+1 301 854 6889</phone>
<facsimile>+1 301 854 5363</facsimile>
<email>crocker@tis.com</email>
</address>
</author>

<author fullname="Barbara Y. Fraser" initials="B." surname="Fraser">
<organization>Carnegie Mellon University, Software Engineering Institute</organization>

<address>
<postal>
<street />
<city>Pittsburgh</city>
<region>PA</region>
<code>15213-3890</code>
<country>US</country>
</postal>

<phone>+1 412 268 5010</phone>
<facsimile>+1 412 268 6989</facsimile>
<email>byf@cert.sei.cmu.edu</email>
</address>
</author>

<date year="1991" month="November" />
</front>

<seriesInfo value="1281" name="RFC" />
</reference>


<reference target2="reference.RFC.1282.xml" anchor="RFC1282">
<front>
<title>BSD Rlogin</title>
<author fullname="Brian Kantor" initials="B." surname="Kantor">
<organization>University of California at San Diego, Network Operations</organization>

<address>
<postal>
<street>C-024</street>
<city>La Jolla</city>
<region>CA</region>
<code>92093-0214</code>
<country>US</country>
</postal>

<phone>+1 619 534 6865</phone>
<email>brian@UCSD.EDU</email>
</address>
</author>

<date year="1991" month="December" />
</front>

<seriesInfo value="1282" name="RFC" />
</reference>


<reference target2="reference.RFC.1283.xml" anchor="RFC1283">
<front>
<title>SNMP over OSI</title>
<author fullname="Marshall T. Rose" initials="M." surname="Rose">
<organization>Dover Beach Consulting, Inc.</organization>

<address>
<postal>
<street>420 Whisman Court</street>
<city>Mountain View</city>
<region>CA</region>
<code>94043-2112</code>
<country>US</country>
</postal>

<phone>+1 415 968 1052</phone>
<email>mrose@dbc.mtview.ca.us</email>
</address>
</author>

<date year="1991" month="December" />
</front>

<seriesInfo value="1283" name="RFC" />
</reference>


<reference target2="reference.RFC.1284.xml" anchor="RFC1284">
<front>
<title abbrev="ETHERNET-LIKE OBJECTS">Definitions of Managed Objects for the Ethernet-like Interface Types</title>
<author fullname="John Cook" initials="J." surname="Cook">
<organization>Chipcom Corporation</organization>

<address>
<postal>
<street>118 Turnpike Road</street>
<city>Southborough</city>
<region>MA</region>
<code>01772</code>
<country>US</country>
</postal>

</address>
</author>

<date year="1991" month="December" />

<abstract>
<t>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 ethernet-like objects.</t>
</abstract>
</front>

<seriesInfo value="1284" name="RFC" />
</reference>


<reference target2="reference.RFC.1285.xml" anchor="RFC1285">
<front>
<title abbrev="FDDI MIB">FDDI Management Information Base</title>
<author fullname="Jeffrey D. Case" initials="J." surname="Case">
<organization>SNMP Research, Incorporated</organization>

<address>
<postal>
<street>3001 Kimberlin Heights Road</street>
<city>Knoxville</city>
<region>TN</region>
<code>37920</code>
<country>US</country>
</postal>

<phone>+1 615 573 1434</phone>
<email>case@CS.UTK.EDU</email>
</address>
</author>

<date year="1992" month="January" />

<abstract>
<t>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 devices which implement the FDDI.</t>
</abstract>
</front>

<seriesInfo value="1285" name="RFC" />
</reference>


<reference target2="reference.RFC.1286.xml" anchor="RFC1286">
<front>
<title abbrev="Bridge MIB">Definitions of Managed Objects for Bridges</title>
<author fullname="Eric B. Decker" initials="E." surname="Decker">
<organization>cisco Systems, Inc.</organization>

<address>
<postal>
<street>1525 O'Brien Dr.</street>
<city>Menlo Park</city>
<region>CA</region>
<code>94025</code>
<country>US</country>
</postal>

<phone>+1 415 326 1941</phone>
<email>cire@cisco.com</email>
</address>
</author>

<author fullname="Paul Langille" initials="P." surname="Langille">
<organization>Digital Equipment Corporation (DEC)</organization>

<address>
<postal>
<street>Digital Drive</street>
<street>MK02-2/K03</street>
<city>Merrimack</city>
<region>NH</region>
<code>03054</code>
<country>US</country>
</postal>

<phone>+1 603 884 4045</phone>
<email>langille@edwin.enet.dec.com</email>
</address>
</author>

<author fullname="Anil Rijsinghani" initials="A." surname="Rijsinghani">
<organization>Digital Equipment Corporation (DEC)</organization>

<address>
<postal>
<street>153 Taylor St.</street>
<city>Littleton</city>
<region>MA</region>
<code>01460</code>
<country>US</country>
</postal>

<phone>+1 508 952 3520</phone>
<email>anil@levers.enet.dec.com</email>
</address>
</author>

<author fullname="Keith McCloghrie" initials="K." surname="McCloghrie">
<organization>Hughes, LAN Systems</organization>

<address>
<postal>
<street>1225 Charleston Road</street>
<city>Mountain View</city>
<region>CA</region>
<code>94043</code>
<country>US</country>
</postal>

<phone>+1 415 966 7934</phone>
<email>kzm@hls.com</email>
</address>
</author>

<date year="1991" month="December" />

<abstract>
<t>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 bridges based on the IEEE 802.1d draft standard between Local Area Network (LAN) segments. Provisions are made for support of transparent and source route bridging.  Provisions are also made so that these objects apply to bridges connected by subnetworks other than LAN segments.</t>
</abstract>
</front>

<seriesInfo value="1286" name="RFC" />
</reference>


<reference target2="reference.RFC.1287.xml" anchor="RFC1287">
<front>
<title abbrev="Future of Internet Architecture">Towards the Future Internet Architecture</title>
<author fullname="David D. Clark" initials="D." surname="Clark">
<organization>Massachusetts Institute of Technology (MIT), Laboratory for Computer Science</organization>

<address>
<postal>
<street>545 Main Street</street>
<city>Cambridge</city>
<region>MA</region>
<code>02139</code>
<country>US</country>
</postal>

<phone>+1 617 253 6003</phone>
<email>ddc@LCS.MIT.EDU</email>
</address>
</author>

<author fullname="Vinton G. Cerf" initials="V." surname="Cerf">
<organization>Corporation for National Research Initiatives</organization>

<address>
<postal>
<street>1895 Preston White Drive</street>
<street>Suite 100</street>
<city>Reston</city>
<region>VA</region>
<code>22091</code>
<country>US</country>
</postal>

<phone>+1 703 620 8990</phone>
<email>vcerf@nri.reston.va.us</email>
</address>
</author>

<author fullname="Lyman A. Chapin" initials="L." surname="Chapin">
<organization>Bolt, Beranek &amp; Newman</organization>

<address>
<postal>
<street>150 Cambridge Park Drive</street>
<street>Mail Stop 20/5b</street>
<city>Cambridge</city>
<region>MA</region>
<code>02140</code>
<country>US</country>
</postal>

<phone>+1 617 873 3133</phone>
<email>lyman@BBN.COM</email>
</address>
</author>

<author fullname="Robert Braden" initials="R." surname="Braden">
<organization>USC/Information Sciences Institute</organization>

<address>
<postal>
<street>4676 Admiralty Way</street>
<city>Marina del Rey</city>
<region>CA</region>
<code>90292</code>
<country>US</country>
</postal>

<phone>+1 310 822 1511</phone>
<email>braden@isi.edu</email>
</address>
</author>

<author fullname="Russell Hobby" initials="R." surname="Hobby">
<organization>University of California, Davis, Computing Services</organization>

<address>
<postal>
<street />
<city>Davis</city>
<region>CA</region>
<code>95616</code>
<country>US</country>
</postal>

<phone>+1 916 752 0236</phone>
<email>rdhobby@ucdavis.edu</email>
</address>
</author>

<date year="1991" month="December" />
</front>

<seriesInfo value="1287" name="RFC" />
</reference>


<reference target2="reference.RFC.1288.xml" anchor="RFC1288">
<front>
<title abbrev="Finger">The Finger User Information Protocol</title>
<author fullname="David Paul Zimmerman" initials="D." surname="Zimmerman">
<organization>Rutgers University, Center for Discrete Mathematics and Theoretical Computer Science (DIMACS)</organization>

<address>
<postal>
<street>P.O. Box 1179</street>
<city>Piscataway</city>
<region>NJ</region>
<code>08855-1179</code>
<country>US</country>
</postal>

<phone>+1 908 932 4592</phone>
<email>dpz@dimacs.rutgers.edu</email>
</address>
</author>

<date year="1991" month="December" />

<abstract>
<t>This memo describes the Finger user information protocol.  This is a simple protocol which provides an interface to a remote user information program.</t>

<t>Based on RFC 742, a description of the original Finger protocol, this memo attempts to clarify the expected communication between the two ends of a Finger connection.  It also tries not to invalidate the many existing implementations or add unnecessary restrictions to the original protocol definition.</t>

<t>This edition corrects and clarifies RFC 1196.</t>
</abstract>
</front>

<seriesInfo value="1288" name="RFC" />
</reference>


<reference target2="reference.RFC.1289.xml" anchor="RFC1289">
<front>
<title abbrev="DECnet Phase IV MIB">DECnet Phase IV MIB Extensions</title>
<author fullname="Jon Saperia" initials="J." surname="Saperia">
<organization>Digital Equipment Corporation (DEC)</organization>

<address>
<postal>
<street>40 Old Bolton Road</street>
<city>Stow</city>
<region>MA</region>
<code>01775-1215</code>
<country>US</country>
</postal>

<phone>+1 508 496 8333</phone>
<email>saperia@enet.dec.com</email>
</address>
</author>

<date year="1991" month="December" />

<abstract>
<t>This memo defines a set of DECnet Phase IV extensions that have been created for the Internet MIB.  When used in conjunction with the structure of management information (RFC 1155), the management information base for network management of TCP/IP-based internets (RFC 1213) and the Simple Network Management Protocol (RFC 1157), it will be possible to provide integrated network management of combined TCP/IP and DECnet Phase IV based internets. This document was produced by the DECnet Phase IV MIB working group of the Internet Engineering Task Force (IETF).</t>
</abstract>
</front>

<seriesInfo value="1289" name="RFC" />
</reference>


<reference target2="reference.RFC.1290.xml" anchor="RFC1290">
<front>
<title abbrev="Searching for Treasure">There's Gold in them thar Networks! or Searching for Treasure in all the Wrong Places</title>
<author fullname="Jerry Martin" initials="J." surname="Martin">
<organization>Ohio State University, ACS, Network Information Center</organization>

<address>
<postal>
<street>1971 Neil Ave.</street>
<city>Columbus</city>
<region>OH</region>
<code>43210-1210</code>
<country>US</country>
</postal>

<phone>+1 614 292 4843</phone>
<email>jmartin@magnus.acs.ohio-state.edu</email>
</address>
</author>

<date year="1991" month="December" />

<abstract>
<t>This document was presented at the 1991 ACM SIGUCCS User Services Conference.  It appears here in its updated form.</t>

<t>There is a wealth of information on the network.  In fact, so much information, that you could spend your entire life browsing. This paper will present some of the "gold nuggets" of information and file repositories on the network that could be of use to end users.</t>

<t>The ultimate goal is to make the route to these sources of information invisible to the user.  At present, this is not easy to do.  I will explain some of the techniques that can be used to make these nuggets easier to pick up so that we can all be richer.</t>
</abstract>
</front>

<seriesInfo value="1290" name="RFC" />
</reference>


<reference target2="reference.RFC.1291.xml" anchor="RFC1291">
<front>
<title abbrev="Potential Technical Services">Mid-Level Networks Potential Technical Services</title>
<author fullname="Vikas Aggarwal" initials="V." surname="Aggarwal">
<organization>Princeton University, JvNCnet</organization>

<address>
<postal>
<street>6 von Neumann Hall</street>
<city>Princeton</city>
<region>NJ</region>
<code>08544</code>
<country>US</country>
</postal>

<phone>+1 609 258 2403</phone>
<email>vikas@jvnc.net</email>
</address>
</author>

<date year="1991" month="December" />

<abstract>
<t>This document proposes a set of technical services that each Internet mid-level network can offer within the mid-level network itself and to its peer networks. The term "mid-level" is used as a generic term to represent all regional and similar networks, which, due to continuous evolutions and transitions, can no longer be termed "regional" [MAN]. It discusses the pros and cons of offering these services, as well as areas in which mid-level networks can work together.</t>

<t>A large portion of the ideas stem from discussions at the IETF Operational Statistics (OPstat), User Connectivity Problems (UCP) and Network Joint Management (NJM) working groups.</t>
</abstract>
</front>

<seriesInfo value="1291" name="RFC" />
</reference>


<reference target2="reference.RFC.1292.xml" anchor="RFC1292">
<front>
<title abbrev="X.500 Catalog">A Catalog of Available X.500 Implementations</title>
<author fullname="Ruth Lang" initials="R." surname="Lang">
<organization>SRI International</organization>

<address>
<postal>
<street>333 Ravenswood Ave.</street>
<city>Menlo Park</city>
<region>CA</region>
<code>94025</code>
<country>US</country>
</postal>

<phone>+1 415 859 5608</phone>
<email>rlang@nisc.sri.com</email>
</address>
</author>

<author fullname="Russ Wright" initials="R." surname="Wright">
<organization>Lawrence Berkeley Laboratory</organization>

<address>
<postal>
<street>1 Cyclotron Road</street>
<city>Berkeley</city>
<region>CA</region>
<code>94720</code>
<country>US</country>
</postal>

<phone>+1 415 486 6965</phone>
<email>wright@lbl.gov</email>
</address>
</author>

<date year="1992" month="January" />

<abstract>
<t>The goal of this document is to provide information regarding the availability and capability of implementations of X.500.  Comments and critiques of this document, and new or updated descriptions of  X.500 implementations are welcome.  Send them to the Directory Information Services Infrastructure (DISI) Working Group (disi@merit.edu) or to the editors.</t>
</abstract>
</front>

<seriesInfo value="1292" name="RFC" />
</reference>


<reference target2="reference.RFC.1293.xml" anchor="RFC1293">
<front>
<title abbrev="Inverse ARP">Inverse Address Resolution Protocol</title>
<author fullname="Terry Bradley" initials="T." surname="Bradley">
<organization>Wellfleet Communications, Inc.</organization>

<address>
<postal>
<street>15 Crosby Drive</street>
<city>Bedford</city>
<region>MA</region>
<code>01730</code>
<country>US</country>
</postal>

<phone>+1 617 275 2400</phone>
<email>tbradley@wellfleet.com</email>
</address>
</author>

<author fullname="Caralyn Brown" initials="C." surname="Brown">
<organization>Wellfleet Communications, Inc.</organization>

<address>
<postal>
<street>15 Crosby Drive</street>
<city>Bedford</city>
<region>MA</region>
<code>01730</code>
<country>US</country>
</postal>

<phone>+1 617 275 2400</phone>
<email>cbrown@wellfleet.com</email>
</address>
</author>

<date year="1992" month="January" />

<abstract>
<t>This memo describes additions to ARP that will allow a station to request a protocol address corresponding to a given hardware address. Specifically, this applies to Frame Relay stations that may have a Data Link Connection Identifier (DLCI), the Frame Relay equivalent of a hardware address, associated with an established Permanent Virtual Circuit (PVC), but do not know the protocol address of the station on the other side of this connection.  It will also apply to other networks with similar circumstances.</t>
</abstract>
</front>

<seriesInfo value="1293" name="RFC" />
</reference>


<reference target2="reference.RFC.1294.xml" anchor="RFC1294">
<front>
<title abbrev="Multiprotocol over Frame Relay">Multiprotocol Interconnect over Frame Relay</title>
<author fullname="Terry Bradley" initials="T." surname="Bradley">
<organization>Wellfleet Communications, Inc.</organization>

<address>
<postal>
<street>15 Crosby Drive</street>
<city>Bedford</city>
<region>MA</region>
<code>01730</code>
<country>US</country>
</postal>

<phone>+1 617 275 2400</phone>
<email>tbradley@wellfleet.com</email>
</address>
</author>

<author fullname="Caralyn Brown" initials="C." surname="Brown">
<organization>Wellfleet Communications, Inc.</organization>

<address>
<postal>
<street>15 Crosby Drive</street>
<city>Bedford</city>
<region>MA</region>
<code>01730</code>
<country>US</country>
</postal>

<phone>+1 617 275 2400</phone>
<email>cbrown@wellfleet.com</email>
</address>
</author>

<author fullname="Andrew G. Malis" initials="A." surname="Malis">
<organization>BBN Communications</organization>

<address>
<postal>
<street>150 CambridgePark Drive</street>
<city>Cambridge</city>
<region>MA</region>
<code>02140</code>
<country>US</country>
</postal>

<phone>+1 617 873 3419</phone>
<email>malis@bbn.com</email>
</address>
</author>

<date year="1992" month="January" />

<abstract>
<t>This memo describes an encapsulation method for carrying network interconnect traffic over a Frame Relay backbone.  It covers aspects of both Bridging and Routing.  Systems with the ability to transfer both this encapsulation method, and others must have a priori knowledge of which virtual circuits will carry which encapsulation method and this encapsulation must only be used over virtual circuits that have been explicitly configured for its use.</t>
</abstract>
</front>

<seriesInfo value="1294" name="RFC" />
</reference>


<reference target2="reference.RFC.1295.xml" anchor="RFC1295">
<front>
<title abbrev="User Bill of Rights">User Bill of Rights for entries and listings in the Public Directory</title>
<author fullname="Theodore H. Myer" initials="T." surname="Myer">
<organization>North American Directory Forum</organization>

<address>
<postal>
<street>3055 Q Street NW</street>
<city>Washington</city>
<region>DC</region>
<code>20007</code>
<country>US</country>
</postal>

<phone>+1 202 342 2727</phone>
<email>0004454742@mcimail.com</email>
</address>
</author>

<date year="1992" month="January" />

<abstract>
<t>This RFC is a near-verbatim copy of a document, known as NADF-265, which has been produced by the North American Directory Forum (NADF).</t>

<t>User Bill of Rights for entries and listings in the Public Directory</t>

<t>The mission of the North American Directory Forum is to provide interconnected electronic directories which empower users with unprecedented access to public information.  To address significant security and privacy issues, the North American Directory Forum introduces the following "User Bill of Rights" for entries in the Public Directory.  As a user, you have:</t>

<t>I. The right not to be listed.</t>

<t>II. The right to have you or your agent informed when your entry is created.</t>

<t>III. The right to examine your entry.</t>

<t>IV. The right to correct inaccurate information in your entry.</t>

<t>V. The right to remove specific information from your entry.</t>

<t>VI. The right to be assured that your listing in the Public Directory will comply with US or Canadian law regulating privacy or access information.</t>

<t>VII. The right to expect timely fulfillment of these rights.</t>
</abstract>
</front>

<seriesInfo value="1295" name="RFC" />
</reference>


<reference target2="reference.RFC.1296.xml" anchor="RFC1296">
<front>
<title>Internet Growth (1981-1991)</title>
<author fullname="Mark K. Lottor" initials="M." surname="Lottor">
<organization>SRI International, Network Information Systems Center</organization>

<address>
<postal>
<street>333 Ravenswood Avenue</street>
<street>EJ282</street>
<city>Menlo Park</city>
<region>CA</region>
<code>94025</code>
<country>US</country>
</postal>

<email>mkl@nisc.sri.com</email>
</address>
</author>

<date year="1992" month="January" />

<abstract>
<t>This document illustrates the growth of the Internet by examination of entries in the Domain Name System (DNS) and pre-DNS host tables. DNS entries are collected by a program called ZONE, which searches the Internet and retrieves data from all known domains.  Pre-DNS host table data were retrieved from system archive tapes.  Various statistics are presented on the number of hosts and domains.</t>
</abstract>
</front>

<seriesInfo value="1296" name="RFC" />
</reference>


<reference target2="reference.RFC.1297.xml" anchor="RFC1297">
<front>
<title abbrev="NOC TT REQUIREMENTS">NOC Internal Integrated Trouble Ticket System Functional Specification Wishlist ("NOC TT REQUIREMENTS")</title>
<author fullname="Dale S. Johnson" initials="D." surname="Johnson">
<organization>Merit NOC</organization>

<address>
<postal>
<street>1075 Beal Avenue</street>
<city>Ann Arbor</city>
<region>MI</region>
<code>48109-2112</code>
<country>US</country>
</postal>

<phone>+1 313 936 2270</phone>
<email>dsj@merit.edu</email>
</address>
</author>

<date year="1992" month="January" />

<abstract>
<t>Professional quality handling of network problems requires some kind of problem tracking system, herein referred to as a "trouble ticket" system.  A basic trouble ticket system acts like a hospital chart, coordinating the work of multiple people who may need to work on the problem.</t>

<t>Once the basic trouble ticket system is in place, however, there are many extensions that can aid Network Operations efficiency. Information in the tickets can be used to produce statistical reports.  Operator efficiency and accuracy may be increased by automating trouble ticket entry with information from the network Alert system.  The Alert system may be used to monitor trouble ticket progress.  Trouble tickets may be also used to communicate network health information between NOCs, to telcom vendors, and to other internal sales and engineering audiences.</t>

<t>This document explores competing uses, architectures, and desirable features of integrated internal trouble ticket systems for Network and other Operations Centers.</t>
</abstract>
</front>

<seriesInfo value="1297" name="RFC" />
</reference>


<reference target2="reference.RFC.1298.xml" anchor="RFC1298">
<front>
<title>SNMP over IPX</title>
<author fullname="Raymond Brett Wormley" initials="R." surname="Wormley">
<organization>Novell, Inc.</organization>

<address>
<postal>
<street>2180 Fortune Drive</street>
<street>Mail Stop F5-91-2</street>
<city>San Jose</city>
<region>CA</region>
<code>95131</code>
<country>US</country>
</postal>

<phone>+1 408 473 8208</phone>
<email>bwormley@novell.com</email>
</address>
</author>

<author fullname="Steve Bostock" initials="S." surname="Bostock">
<organization />

<address>
<postal>
<street>2180 Fortune Drive</street>
<street>Mail Stop F5-91-2</street>
<city>San Jose</city>
<region>CA</region>
<code>95131</code>
<country>US</country>
</postal>

<phone>+1 408 473 8203</phone>
<email>steveb@novell.com</email>
</address>
</author>

<date year="1992" month="February" />

<abstract>
<t>This memo defines a convention for encapsulating Simple Network Management Protocol (SNMP)packets over the transport mechanism  provided via the Internetwork Packet Exchange (IPX) protocol.</t>
</abstract>
</front>

<seriesInfo value="1298" name="RFC" />
</reference>


<reference target2="reference.RFC.1299.xml" anchor="RFC1299">
<front>
<title abbrev="Summary of 1200-1299">Summary of 1200-1299</title>
<author fullname="Mary Kennedy" initials="M." surname="Kennedy">
<organization>University of Southern California, Information Sciences Institute</organization>

<address>
<postal>
<street>4676 Admiralty Way</street>
<city>Marina del Rey</city>
<region>CA</region>
<code>90292</code>
<country>US</country>
</postal>

<phone>+1 310 822 1511</phone>
<email>MKENNEDY@ISI.EDU</email>
</address>
</author>

<date year="1997" month="January" />
</front>

<seriesInfo value="1299" name="RFC" />
</reference>


<reference target2="reference.RFC.1300.xml" anchor="RFC1300">
<front>
<title>Remembrances of Things Past</title>
<author fullname="Stanley R. Greenfield" initials="S." surname="Greenfield">
<organization>Ziff-Davis</organization>

<address>
<postal>
<street>One Park Avenue</street>
<city>New York</city>
<region>NY</region>
<code>10016</code>
<country>US</country>
</postal>

<email>0004689513@mcimail.com</email>
</address>
</author>

<date year="1992" month="February" />
</front>

<seriesInfo value="1300" name="RFC" />
</reference>


<reference target2="reference.RFC.1301.xml" anchor="RFC1301">
<front>
<title>Multicast Transport Protocol</title>
<author fullname="Susan M. Armstrong" initials="S." surname="Armstrong">
<organization>Xerox Webster Research Center</organization>

<address>
<postal>
<street>800 Phillips Rd.</street>
<street>MS 128-27E</street>
<city>Webster</city>
<region>NY</region>
<code>14580</code>
<country>US</country>
</postal>

<phone>+1 716 422 6437</phone>
<email>armstrong@wrc.xerox.com</email>
</address>
</author>

<author fullname="Alan O. Freier" initials="A." surname="Freier">
<organization>Apple Computer, Inc.</organization>

<address>
<postal>
<street>20525 Mariani Ave.</street>
<street>MS 3-PK</street>
<city>Cupertino</city>
<region>CA</region>
<code>95014</code>
<country>US</country>
</postal>

<phone>+1 408 974 9196</phone>
<email>freier@apple.com</email>
</address>
</author>

<author fullname="Keith A. Marzullo" initials="K." surname="Marzullo">
<organization>Cornell University, Department of Computer Science</organization>

<address>
<postal>
<street>Upson Hall</street>
<city>Ithaca</city>
<region>NY</region>
<code>14853-7501</code>
<country>US</country>
</postal>

<phone>+1 607 255 9188</phone>
<email>marzullo@cs.cornell.edu</email>
</address>
</author>

<date year="1992" month="February" />
</front>

<seriesInfo value="1301" name="RFC" />
</reference>


<reference target2="reference.RFC.1302.xml" anchor="RFC1302">
<front>
<title abbrev="NISI">Building a Network Information Services Infrastructure</title>
<author fullname="Dana D. Sitzler" initials="D." surname="Sitzler">
<organization>Merit Network, Inc</organization>

<address>
<postal>
<street>1075 Beal Avenue</street>
<city>Ann Arbor</city>
<region>MI</region>
<code>48109-2112</code>
<country>US</country>
</postal>

<phone>+1 313 936 2648</phone>
<email>dds@merit.edu</email>
</address>
</author>

<author fullname="Patricia G. Smith" initials="P." surname="Smith">
<organization>Merit Network, Inc</organization>

<address>
<postal>
<street>1075 Beal Avenue</street>
<city>Ann Arbor</city>
<region>MI</region>
<code>48109-2112</code>
<country>US</country>
</postal>

<phone>+1 313 936 3000</phone>
<email>psmith@merit.edu</email>
</address>
</author>

<author fullname="April N. Marine" initials="A." surname="Marine">
<organization>SRI International, Network Information Systems Center</organization>

<address>
<postal>
<street>333 Ravenswood Avenue</street>
<street>EJ294</street>
<city>Menlo Park</city>
<region>CA</region>
<code>94025-3493</code>
<country>US</country>
</postal>

<phone>+1 415 859 5318</phone>
<email>april@nisc.sri.com</email>
</address>
</author>

<date year="1992" month="February" />

<abstract>
<t>This FYI RFC document is intended for existing Internet Network Information Center (NIC) personnel, people interested in establishing a new NIC, Internet Network Operations Centers (NOCs), and funding agencies interested in contributing to user support facilities.  The document strives to:</t>

<t>- Define a basic set of essential services that Network Information Centers (NICs) will provide to Internet users, including new mechanisms that will facilitate the timely dissemination of  information to the Internet community and encourage cooperation among NICs.</t>

<t>- Describe existing NIC services as an aid to Internet users and as a model for organizations establishing new NICs.</t>
</abstract>
</front>

<seriesInfo value="1302" name="RFC" />
</reference>


<reference target2="reference.RFC.1303.xml" anchor="RFC1303">
<front>
<title abbrev="Convention for Describing SNMP Agents">A Convention for Describing SNMP-based Agents</title>
<author fullname="Keith McCloghrie" initials="K." surname="McCloghrie">
<organization>Hughes, LAN Systems</organization>

<address>
<postal>
<street>1225 Charleston Road</street>
<city>Mountain View</city>
<region>CA</region>
<code>94043</code>
<country>US</country>
</postal>

<phone>+1 415 966 7934</phone>
<email>kzm@hls.com</email>
</address>
</author>

<author fullname="Marshall T. Rose" initials="M." surname="Rose">
<organization>Dover Beach Consulting, Inc.</organization>

<address>
<postal>
<street>420 Whisman Court</street>
<city>Mountain View</city>
<region>CA</region>
<code>94043-2112</code>
<country>US</country>
</postal>

<phone>+1 415 968 1052</phone>
<email>mrose@dbc.mtview.ca.us</email>
</address>
</author>

<date year="1992" month="February" />

<abstract>
<t>This memo suggests a straight-forward approach towards describing SNMP-based agents.</t>
</abstract>
</front>

<seriesInfo value="1303" name="RFC" />
</reference>


<reference target2="reference.RFC.1304.xml" anchor="RFC1304">
<front>
<title abbrev="SIP Objects">Definitions of Managed Objects for the SIP Interface Type</title>
<author fullname="Tracy A. Cox" initials="T." surname="Cox">
<organization>Bell Communications Research</organization>

<address>
<postal>
<street>331 Newman Springs Road</street>
<city>Red Bank</city>
<region>NJ</region>
<code>07701</code>
<country>US</country>
</postal>

<phone>+1 908 758 2107</phone>
<email>tacox@sabre.bellcore.com</email>
</address>
</author>

<author fullname="Kaj Tesink" initials="K." surname="Tesink">
<organization>Bell Communications Research</organization>

<address>
<postal>
<street>331 Newman Springs Road</street>
<city>Red Bank</city>
<region>NJ</region>
<code>07701</code>
<country>US</country>
</postal>

<phone>+1 908 758 5254</phone>
<email>kaj@nvuxr.cc.bellcore.com</email>
</address>
</author>

<date year="1992" month="February" />

<abstract>
<t>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 SIP (SMDS Interface Protocol) objects.</t>
</abstract>
</front>

<seriesInfo value="1304" name="RFC" />
</reference>


<reference target2="reference.RFC.1305.xml" anchor="RFC1305">
<front>
<title>Network Time Protocol (Version 3) Specification, Implementation</title>
<author fullname="David L. Mills" initials="D." surname="Mills">
<organization>University of Delaware, Electrical Engineering Department</organization>

<address>
<postal>
<street />
<city>Newark</city>
<region>DE</region>
<code>19716</code>
<country>US</country>
</postal>

<phone>+1 302 451 8247</phone>
<email>mills@udel.edu</email>
</address>
</author>

<date year="1992" month="March" />

<abstract>
<t>This document describes the Network Time Protocol (NTP), specifies its normal structure and summarizes information useful for its implementation. NTP provides the mechanisms to synchronize time and coordinate time distribution in a large, diverse internet operating at rates from mundane to lightwave. It uses a returnable-time design in which a distributed subnet of time servers operating in a self-organizing, hierarchical-master-slave configuration synchronizes local clocks within the subnet and to national time standards via wire or radio. The servers can also redistribute reference time via local routing algorithms and time daemons.</t>
</abstract>
</front>

<seriesInfo value="1305" name="RFC" />
</reference>


<reference target2="reference.RFC.1306.xml" anchor="RFC1306">
<front>
<title abbrev="Experiences with Circuit-Switched T3">Experiences Supporting By-Request Circuit-Switched T3 Networks</title>
<author fullname="Andy Nicholson" initials="A." surname="Nicholson">
<organization>Cray Research, Inc.</organization>

<address>
<postal>
<street>655F Lone Oak Drive</street>
<city>Eagan</city>
<region>MN</region>
<code>55123</code>
<country>US</country>
</postal>

<phone>+1 612 452 6650</phone>
<email>droid@cray.com</email>
</address>
</author>

<author fullname="Jeff Young" initials="J." surname="Young">
<organization>Cray Research, Inc.</organization>

<address>
<postal>
<street>655F Lone Oak Drive</street>
<city>Eagan</city>
<region>MN</region>
<code>55123</code>
<country>US</country>
</postal>

<phone>+1 612 452 6650</phone>
<email>jsy@cray.com</email>
</address>
</author>

<date year="1992" month="March" />

<abstract>
<t>This memo describes the experiences of a project team at Cray Research, Inc., in implementing support for circuit-switched T3 services.  While the issues discussed may not be directly relevant to the research problems of the Internet, they may be interesting to a number of researchers and implementers.</t>

<t>Developers at Cray Research, Inc. were presented with an opportunity to use a circuit-switched T3 network for wide area networking.  They devised an architectural model for using this new resource.  This involves activating the circuit-switched connection when an application program engages in a bulk data transfer, and releasing the connection when the transfer is complete.</t>

<t>Three software implementations for this feature have been tested, and the results documented here.  A variety of issues are involved, and further research is necessary.  Network users are beginning to recognize the value of this service, and are planning to make use of by-request circuit-switched networks.  A standard method of access will be needed to ensure interoperability among vendors of circuit-switched network support products.</t>
</abstract>
</front>

<seriesInfo value="1306" name="RFC" />
</reference>


<reference target2="reference.RFC.1307.xml" anchor="RFC1307">
<front>
<title>Dynamically Switched Link Control Protocol</title>
<author fullname="Jeff Young" initials="J." surname="Young">
<organization>Cray Research, Inc.</organization>

<address>
<postal>
<street>655F Lone Oak Drive</street>
<city>Eagan</city>
<region>MN</region>
<code>55123</code>
<country>US</country>
</postal>

<phone>+1 612 452 6650</phone>
<email>jsy@cray.com</email>
</address>
</author>

<author fullname="Andy Nicholson" initials="A." surname="Nicholson">
<organization>Cray Research, Inc.</organization>

<address>
<postal>
<street>655F Lone Oak Drive</street>
<city>Eagan</city>
<region>MN</region>
<code>55123</code>
<country>US</country>
</postal>

<phone>+1 612 452 6650</phone>
<email>droid@cray.com</email>
</address>
</author>

<date year="1992" month="March" />

<abstract>
<t>This memo describes an experimental protocol developed by a project team at Cray Research, Inc., in implementing support for circuit-switched T3 services.  The protocol is used for the control of network connections external to a host, but known to the host.  It is documented here for the benefit of others who may wish to perform further research.</t>

<t>While working with circuit-switched T3 networks, developers at Cray Research, Inc., defined a model wherein a host would generate control messages for a network switch.  This work is described in RFC  1306, "Experiences Supporting By-Request Circuit-Switched T3 Networks".  In order to simplify the model it was decided that the inconsistencies of switch control should be hidden from the host generating the
   control messages.  To that end, a protocol was defined and implemented.  This RFC documents the Dynamically Switched Link Control Protocol (DSLCP), which is used for creation and control of downstream network links by a host.</t>
</abstract>
</front>

<seriesInfo value="1307" name="RFC" />
</reference>


<reference target2="reference.RFC.1308.xml" anchor="RFC1308">
<front>
<title abbrev="Executive Intro to X.500">Executive Introduction to Directory Services Using the X.500 Protocol</title>
<author fullname="Chris Weider" initials="C." surname="Weider">
<organization>Advanced Network and Services, Inc.</organization>

<address>
<postal>
<street>2901 Hubbard</street>
<street>G-1</street>
<city>Ann Arbor</city>
<region>MI</region>
<code>48105-2437</code>
<country>US</country>
</postal>

<phone>+1 313 663 2482</phone>
<email>weider@ans.net</email>
</address>
</author>

<author fullname="Joyce K. Reynolds" initials="J." surname="Reynolds">
<organization>University of Southern California, Information Sciences Institute</organization>

<address>
<postal>
<street>4676 Admirality Way</street>
<city>Marina del Rey</city>
<region>CA</region>
<code>90292</code>
<country>US</country>
</postal>

<phone>+1 310 822 1511</phone>
<email>jkrey@isi.edu</email>
</address>
</author>

<date year="1992" month="March" />

<abstract>
<t>This document is an Executive Introduction to Directory Services using the X.500 protocol. It briefly discusses the deficiencies in currently deployed Internet Directory Services, and then illustrates the solutions provided by X.500.</t>

<t>This FYI RFC is a product of the Directory Information Services (pilot) Infrastructure Working Group (DISI).  A combined effort of the User Services and the OSI Integration Areas of the Internet Engineering Task Force (IETF).</t>
</abstract>
</front>

<seriesInfo value="1308" name="RFC" />
</reference>


<reference target2="reference.RFC.1309.xml" anchor="RFC1309">
<front>
<title abbrev="Technical Overview of X.500">Technical Overview of Directory Services Using the X.500 Protocol</title>
<author fullname="Chris Weider" initials="C." surname="Weider">
<organization>Advanced Network and Services, Inc.</organization>

<address>
<postal>
<street>2901 Hubbard G-1</street>
<city>Ann Arbor</city>
<region>MI</region>
<code>48105-2437</code>
<country>US</country>
</postal>

<phone>+1 313 663 2482</phone>
<email>weider@ans.net</email>
</address>
</author>

<author fullname="Joyce K. Reynolds" initials="J." surname="Reynolds">
<organization>University of Southern California, Information Sciences Institute</organization>

<address>
<postal>
<street>4676 Admirality Way</street>
<city>Marina del Rey</city>
<region>CA</region>
<code>90292</code>
<country>US</country>
</postal>

<phone>+1 310 822 1511</phone>
<email>jkrey@isi.edu</email>
</address>
</author>

<author fullname="Sergio Heker" initials="S." surname="Heker">
<organization>Princeton University, JvNCnet</organization>

<address>
<postal>
<street>6 von Neumann Hall</street>
<city>Princeton</city>
<region>NJ</region>
<code>08544</code>
<country>US</country>
</postal>

<phone>+1 609 258 2400</phone>
<email>heker@nisc.jvnc.net</email>
</address>
</author>

<date year="1992" month="March" />

<abstract>
<t>This document is an overview of the X.500 standard for people not familiar with the technology. It compares and contrasts Directory Services based on X.500 with several of the other Directory services currently in use in the Internet. This paper also describes the status of the standard and provides references for further information on X.500 implementations and technical information.</t>

<t>A primary purpose of this paper is to illustrate the vast functionality of the X.500 protocol and to show how it can be used to provide a global directory for human use, and can support other applications which would benefit from directory services, such as main programs.</t>

<t>This FYI RFC is a product of the Directory Information Services (pilot) Infrastructure Working Group (DISI).  A combined effort of the User Services and the OSI Integration Areas of the Internet Engineering Task Force (IETF).</t>
</abstract>
</front>

<seriesInfo value="1309" name="RFC" />
</reference>


<reference target2="reference.RFC.1310.xml" anchor="RFC1310">
<front>
<title abbrev="Internet Standards Process">The Internet Standards Process</title>
<author fullname="A. Lyman Chapin" initials="A." surname="Chapin">
<organization>BBN Communications Corporation</organization>

<address>
<postal>
<street>150 Cambridge Park Drive</street>
<city>Cambridge</city>
<region>MA</region>
<code>02140</code>
<country>US</country>
</postal>

<phone>+1 617 873 3133</phone>
<facsimile>+1 617 873 4086</facsimile>
<email>Lyman@BBN.COM</email>
</address>
</author>

<date year="1992" month="March" />
</front>

<seriesInfo value="1310" name="RFC" />
</reference>


<reference target2="reference.RFC.1311.xml" anchor="RFC1311">
<front>
<title abbrev="RFC on STD RFCs">Introduction to the STD Notes</title>
<author fullname="Jon Postel" initials="J." surname="Postel">
<organization>USC/Information Sciences Institute</organization>

<address>
<postal>
<street>4676 Admiralty Way</street>
<city>Marina del Rey</city>
<region>CA</region>
<code>90292</code>
<country>US</country>
</postal>

<phone>+1 310 822 1511</phone>
<facsimile>+1 310 823 6714</facsimile>
<email>Postel@ISI.EDU</email>
</address>
</author>

<date year="1992" month="March" />
</front>

<seriesInfo value="1311" name="RFC" />
</reference>


<reference target2="reference.RFC.1312.xml" anchor="RFC1312">
<front>
<title>Message Send Protocol 2</title>
<author fullname="Russell Nelson" initials="R." surname="Nelson">
<organization>Crynwr Software</organization>

<address>
<postal>
<street>11 Grant St.</street>
<city>Potsdam</city>
<region>NY</region>
<code>13676</code>
<country>US</country>
</postal>

<phone>+1 315 268 1925</phone>
<email>nelson@crynwr.com</email>
</address>
</author>

<author fullname="Geoff Arnold" initials="G." surname="Arnold">
<organization>Sun Microsystems, Inc.</organization>

<address>
<postal>
<street>2 Federal Street</street>
<city>Billerica</city>
<region>MA</region>
<code>01821</code>
<country>US</country>
</postal>

<phone>+1 508 671 0317</phone>
<email>geoff@east.sun.com</email>
</address>
</author>

<date year="1992" month="April" />
</front>

<seriesInfo value="1312" name="RFC" />
</reference>


<reference target2="reference.RFC.1313.xml" anchor="RFC1313">
<front>
<title abbrev="Today&apos;s Programming for KRFC AM 13XX">Today's Programming for KRFC AM 1313 Internet Talk Radio</title>
<author fullname="Craig Partridge" initials="C." surname="Partridge">
<organization>BBN</organization>

<address>
<postal>
<street>824 Kipling St</street>
<city>Palo Alto</city>
<region>CA</region>
<code>94301</code>
<country>US</country>
</postal>

<phone>+1 415 325 4541</phone>
<email>craig@aland.bbn.com</email>
</address>
</author>

<date year="1992" day="1" month="April" />
</front>

<seriesInfo value="1313" name="RFC" />
</reference>


<reference target2="reference.RFC.1314.xml" anchor="RFC1314">
<front>
<title abbrev="Image Exchange Format">A File Format for the Exchange of Images in the Internet</title>
<author fullname="Alan Katz" initials="A." surname="Katz">
<organization>USC, Information Sciences Institute</organization>

<address>
<postal>
<street>4676 Admiralty Way #1100</street>
<city>Marina del Rey</city>
<region>CA</region>
<code>90292-6695</code>
<country>US</country>
</postal>

<phone>+1 310 822 1511</phone>
<facsimile>+1 310 823 6714</facsimile>
<email>Katz@ISI.Edu</email>
</address>
</author>

<author fullname="Danny Cohen" initials="D." surname="Cohen">
<organization>USC, Information Sciences Institute</organization>

<address>
<postal>
<street>4676 Admiralty Way #1100</street>
<city>Marina del Rey</city>
<region>CA</region>
<code>90292-6695</code>
<country>US</country>
</postal>

<phone>+1 310 822 1511</phone>
<facsimile>+1 310 823 6714</facsimile>
<email>Cohen@ISI.Edu</email>
</address>
</author>

<date year="1992" month="April" />

<abstract>
<t>This document defines a standard file format for the exchange of fax-like black and white images within the Internet.  It is a product of the Network Fax Working Group of the Internet Engineering Task Force (IETF).</t>

<t>The standard is:</t>

<t>** The file format should be TIFF-B with multi-page files supported.  Images should be encoded as one TIFF strip per page.</t>

<t>** Images should be compressed using MMR when possible.  Images may also be MH or MR compressed or uncompressed.  If MH or MR compression is used, scan lines should be "byte-aligned".</t>

<t>** For maximum interoperability, image resolutions should either be 600, 400, or 300 dpi; or else be one of the standard Group 3 fax resolutions (98 or 196 dpi vertically and 204 dpi horizontally).</t>

<t>Note that this specification is self contained and an implementation should be possible without recourse to the TIFF references, and that only the specific TIFF documents cited are relevant to this specification.  Updates to the TIFF documents do not change this specification.</t>

<t>Experimentation with this file format specified here is encouraged.</t>
</abstract>
</front>

<seriesInfo value="1314" name="RFC" />
</reference>


<reference target2="reference.RFC.1315.xml" anchor="RFC1315">
<front>
<title abbrev="Frame Relay DTE MIB">Management Information Base for Frame Relay DTEs</title>
<author fullname="Caralyn Brown" initials="C." surname="Brown">
<organization>Wellfleet Communications, Inc.</organization>

<address>
<postal>
<street>15 Crosby Drive</street>
<city>Bedford</city>
<region>MA</region>
<code>01730</code>
<country>US</country>
</postal>

<phone>+1 617 275 2400</phone>
<email>cbrown@wellfleet.com</email>
</address>
</author>

<author fullname="Fred Baker" initials="F." surname="Baker">
<organization>Advanced Computer Communications</organization>

<address>
<postal>
<street>315 Bollay Drive</street>
<city>Santa Barbara</city>
<region>CA</region>
<code>93117</code>
<country>US</country>
</postal>

<phone>+1 805 685 4455</phone>
<email>fbaker@acc.com</email>
</address>
</author>

<author fullname="Charles Carvalho" initials="C." surname="Carvalho">
<organization>Advanced Computer Communications</organization>

<address>
<postal>
<street>315 Bollay Drive</street>
<city>Santa Barbara</city>
<region>CA</region>
<code>93117</code>
<country>US</country>
</postal>

<phone>+1 805 685 4455</phone>
<email>charles@acc.com</email>
</address>
</author>

<date year="1992" month="April" />

<abstract>
<t>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 Frame Relay.</t>
</abstract>
</front>

<seriesInfo value="1315" name="RFC" />
</reference>


<reference target2="reference.RFC.1316.xml" anchor="RFC1316">
<front>
<title abbrev="Character MIB">Definitions of Managed Objects for Character Stream Devices</title>
<author fullname="Bob Stewart" initials="B." surname="Stewart">
<organization>Xyplex, Inc.</organization>

<address>
<postal>
<street>330 Codman Hill Road</street>
<city>Boxborough</city>
<region>MA</region>
<code>01719</code>
<country>US</country>
</postal>

<phone>+1 508 264 9900</phone>
<email>rlstewart@eng.xyplex.com</email>
</address>
</author>

<date year="1992" month="April" />

<abstract>
<t>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 the management of character stream devices.</t>
</abstract>
</front>

<seriesInfo value="1316" name="RFC" />
</reference>


<reference target2="reference.RFC.1317.xml" anchor="RFC1317">
<front>
<title abbrev="RS-232-LIKE MIB">Definitions of Managed Objects for RS-232-like Hardware Devices</title>
<author fullname="Bob Stewart" initials="B." surname="Stewart">
<organization>Xyplex, Inc.</organization>

<address>
<postal>
<street>330 Codman Hill Road</street>
<city>Boxborough</city>
<region>MA</region>
<code>01719</code>
<country>US</country>
</postal>

<phone>+1 508 264 9900</phone>
<email>rlstewart@eng.xyplex.com</email>
</address>
</author>

<date year="1992" month="April" />

<abstract>
<t>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 the management of RS-232-like devices.</t>
</abstract>
</front>

<seriesInfo value="1317" name="RFC" />
</reference>


<reference target2="reference.RFC.1318.xml" anchor="RFC1318">
<front>
<title abbrev="PARALLEL-PRINTER-LIKE-MIB">Definitions of Managed Objects for Parallel-printer-like Hardware Devices</title>
<author fullname="Bob Stewart" initials="B." surname="Stewart">
<organization>Xyplex, Inc.</organization>

<address>
<postal>
<street>330 Codman Hill Road</street>
<city>Boxborough</city>
<region>MA</region>
<code>01719</code>
<country>US</country>
</postal>

<phone>+1 508 264 9900</phone>
<email>rlstewart@eng.xyplex.com</email>
</address>
</author>

<date year="1992" month="April" />

<abstract>
<t>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 the management of parallel-printer-like devices.</t>
</abstract>
</front>

<seriesInfo value="1318" name="RFC" />
</reference>


<reference target2="reference.RFC.1319.xml" anchor="RFC1319">
<front>
<title abbrev="MD2 Message-Digest Algorithm">The MD2 Message-Digest Algorithm</title>
<author fullname="Burton S. Kaliski Jr." initials="B." surname="Kaliski">
<organization>RSA Laboratories</organization>

<address>
<postal>
<street>10 Twin Dolphin Drive</street>
<city>Redwood City</city>
<region>CA</region>
<code>94065</code>
<country>US</country>
</postal>

<phone>+1 415 595 8782</phone>
<facsimile>+1 415 595 4126</facsimile>
<email>burt@rsa.com</email>
</address>
</author>

<date year="1992" month="April" />
</front>

<seriesInfo value="1319" name="RFC" />
</reference>


<reference target2="reference.RFC.1320.xml" anchor="RFC1320">
<front>
<title abbrev="MD4 Message-Digest Algorithm">The MD4 Message-Digest Algorithm</title>
<author fullname="Ronald L. Rivest" initials="R." surname="Rivest">
<organization>Massachusetts Institute of Technology (MIT), Laboratory for Computer Science, RSA Data Security, Inc.</organization>

<address>
<postal>
<street>545 Technology Square</street>
<street>NE43-324</street>
<city>Cambridge</city>
<region>MA</region>
<code>02139-1986</code>
<country>US</country>
</postal>

<phone>+1 617 253 5880</phone>
<email>rivest@theory.lcs.mit.edu</email>
</address>
</author>

<date year="1992" month="April" />
</front>

<seriesInfo value="1320" name="RFC" />
</reference>


<reference target2="reference.RFC.1321.xml" anchor="RFC1321">
<front>
<title abbrev="MD5 Message-Digest Algorithm">The MD5 Message-Digest Algorithm</title>
<author fullname="Ronald L. Rivest" initials="R." surname="Rivest">
<organization>Massachusetts Institute of Technology, (MIT) Laboratory for Computer Science</organization>

<address>
<postal>
<street>545 Technology Square</street>
<street>NE43-324</street>
<city>Cambridge</city>
<region>MA</region>
<code>02139-1986</code>
<country>US</country>
</postal>

<phone>+1 617 253 5880</phone>
<email>rivest@theory.lcs.mit.edu</email>
</address>
</author>

<date year="1992" month="April" />
</front>

<seriesInfo value="1321" name="RFC" />
</reference>


<reference target2="reference.RFC.1322.xml" anchor="RFC1322">
<front>
<title>A Unified Approach to Inter-Domain Routing</title>
<author fullname="Deborah Estrin" initials="D." surname="Estrin">
<organization>University of Southern California (USC)</organization>

<address>
<postal>
<street>MC 0782</street>
<city>Los Angeles</city>
<region>CA</region>
<code>90089-0782</code>
<country>US</country>
</postal>

<phone>+1 310 740 4524</phone>
<email>estrin@usc.edu</email>
</address>
</author>

<author fullname="Yakov Rekhter" initials="Y." surname="Rekhter">
<organization>IBM, T. J. Watson Research Center</organization>

<address>
<postal>
<street>P.O. Box 218</street>
<city>Yorktown Heights</city>
<region>NY</region>
<code>10598</code>
<country>US</country>
</postal>

<phone>+1 914 945 3896</phone>
<email>yakov@ibm.com</email>
</address>
</author>

<author fullname="Steven Hotz" initials="S." surname="Hotz">
<organization>University of Southern California  (USC), Computer Science Department</organization>

<address>
<postal>
<street>MC 0782</street>
<city>Los Angeles</city>
<region>CA</region>
<code>90089-0782</code>
<country>US</country>
</postal>

<phone>+1 310 822 1511</phone>
<email>hotz@usc.edu</email>
</address>
</author>

<date year="1992" month="May" />

<abstract>
<t>This memo is an informational RFC which outlines one potential approach for inter-domain routing in future global internets.  The focus is on scalability to very large networks and functionality, as well as scalability, to support routing in an environment of heterogeneous services, requirements, and route selection criteria.</t>

<t>Note: The work of D. Estrin and S. Hotz was supported by the National Science Foundation under contract number NCR-9011279, with matching funds from GTE Laboratories.  The work of Y. Rekhter was supported by the Defense Advanced Research Projects Agency, under contract DABT63-91-C-0019.  Views and conclusions expressed in this paper are not necessarily those of the Defense Advanced Research Projects Agency and National Science Foundation.</t>
</abstract>
</front>

<seriesInfo value="1322" name="RFC" />
</reference>


<reference target2="reference.RFC.1323.xml" anchor="RFC1323">
<front>
<title>TCP Extensions for High Performance</title>
<author fullname="Van Jacobson" initials="V." surname="Jacobson">
<organization>University of California Berkeley, Lawrence Berkeley Laboratory</organization>

<address>
<postal>
<street>Mail Stop 46A</street>
<city>Berkeley</city>
<region>CA</region>
<code>94720</code>
<country>US</country>
</postal>

<phone>+1 415 486 6411</phone>
<email>van@CSAM.LBL.GOV</email>
</address>
</author>

<author fullname="Bob Braden" initials="B." surname="Braden">
<organization>University of Southern California (USC), Information Sciences Institute</organization>

<address>
<postal>
<street>4676 Admiralty Way</street>
<city>Marina del Rey</city>
<region>CA</region>
<code>90292</code>
<country>US</country>
</postal>

<phone>+1 310 822 1511</phone>
<email>Braden@ISI.EDU</email>
</address>
</author>

<author fullname="Dave Borman" initials="D." surname="Borman">
<organization>Cray Research</organization>

<address>
<postal>
<street>655-E Lone Oak Drive</street>
<city>Eagan</city>
<region>MN</region>
<code>55121</code>
<country>US</country>
</postal>

<phone>+1 612 683 5571</phone>
<email>dab@cray.com</email>
</address>
</author>

<date year="1992" month="May" />

<abstract>
<t>This memo presents a set of TCP extensions to improve performance over large bandwidth*delay product paths and to provide reliable operation over very high-speed paths.  It defines new TCP options for scaled windows and timestamps, which are designed to provide compatible interworking with TCP's that do not implement the extensions.  The timestamps are used for two distinct mechanisms: RTTM (Round Trip Time Measurement) and PAWS (Protect Against Wrapped Sequences).  Selective acknowledgments are not included in this memo.</t>

<t>This memo combines and supersedes RFC-1072 and RFC-1185, adding additional clarification and more detailed specification.  Appendix C summarizes the changes from the earlier RFCs.</t>
</abstract>
</front>

<seriesInfo value="1323" name="RFC" />
</reference>


<reference target2="reference.RFC.1324.xml" anchor="RFC1324">
<front>
<title abbrev="Computer Network Conferencing">A Discussion on Computer Network Conferencing</title>
<author fullname="Darren Reed" initials="D." surname="Reed">
<organization />

<address>
<postal>
<street>4 Pateman Street</street>
<city>Watsonia</city>
<region>Victoria</region>
<code>3087</code>
<country>AU</country>
</postal>

<email>avalon@coombs.anu.edu.au</email>
</address>
</author>

<date year="1992" month="May" />

<abstract>
<t>This memo is intended to make more people aware of the present developments in the Computer Conferencing field as well as put forward ideas on what should be done to formalize this work so that    there is a common standard for programmers and others who are involved in this field to work with.  It is also the intention of this memo to stimulate the computer community and generate some useful discussion about the merits of this field.</t>
</abstract>
</front>

<seriesInfo value="1324" name="RFC" />
</reference>


<reference target2="reference.RFC.1325.xml" anchor="RFC1325">
<front>
<title abbrev="FYI Q/A - for New Internet Users">FYI on Questions and Answers Answers to Commonly asked "New Internet User" Questions</title>
<author fullname="Gary Scott Malkin" initials="G." surname="Malkin">
<organization>Xylogics, Inc.</organization>

<address>
<postal>
<street>53 Third Avenue</street>
<city>Burlington</city>
<region>MA</region>
<code>01803</code>
<country>US</country>
</postal>

<phone>+1 617 272 8140</phone>
<email>gmalkin@Xylogics.COM</email>
</address>
</author>

<author fullname="April N. Marine" initials="A." surname="Marine">
<organization>SRI International, Network Information Systems Center</organization>

<address>
<postal>
<street>333 Ravenswood Avenue</street>
<street>EJ294</street>
<city>Menlo Park</city>
<region>CA</region>
<code>94025</code>
<country>US</country>
</postal>

<phone>+1 415 859 5318</phone>
<email>april@nisc.sri.com</email>
</address>
</author>

<date year="1992" month="May" />

<abstract>
<t>This FYI RFC is one of two FYI's called, "Questions and Answers" (Q/A), produced by the User Services Working Group of the Internet Engineering Task Force (IETF).  The goal is to document the most commonly asked questions and answers in the Internet.</t>
</abstract>
</front>

<seriesInfo value="1325" name="RFC" />
</reference>


<reference target2="reference.RFC.1326.xml" anchor="RFC1326">
<front>
<title abbrev="Encapsulation Dangerous">Mutual Encapsulation Considered Dangerous</title>
<author fullname="Paul Tsuchiya" initials="P." surname="Tsuchiya">
<organization>Bellcore</organization>

<address>
<postal>
<street>435 South St.</street>
<street>MRE 2L-281</street>
<city>Morristown</city>
<region>NJ</region>
<code>07960</code>
<country>US</country>
</postal>

<phone>+1 908 829 4484</phone>
<email>tsuchiya@thumper.bellcore.com</email>
</address>
</author>

<date year="1992" month="May" />

<abstract>
<t>This memo describes a packet explosion problem that can occur with mutual encapsulation of protocols (A encapsulates B and B encapsulates A).</t>
</abstract>
</front>

<seriesInfo value="1326" name="RFC" />
</reference>


<reference target2="reference.RFC.1327.xml" anchor="RFC1327">
<front>
<title abbrev="Mapping between X.400 (1988) and RFC 822">Mapping between X.400(1988) / ISO 10021 and RFC 822</title>
<author fullname="Steve Hardcastle-Kille" initials="S." surname="Hardcastle-Kille">
<organization>University College London, Department of Computer Science</organization>

<address>
<postal>
<street>Gower Street</street>
<city>London</city>
<region>England</region>
<code>WC1E 6BT</code>
<country>UK</country>
</postal>

<phone>+44 71 3807294</phone>
<email>S.Kille@CS.UCL.AC.UK</email>
</address>
</author>

<date year="1992" month="May" />

<abstract>
<t>This document describes a set of mappings which will enable interworking between systems operating the CCITT X.400 1988) Recommendations on Message Handling Systems / ISO IEC 10021 Message Oriented Text Interchange Systems (MOTIS), and systems using the RFC 822 mail protocolor protocols derived from RFC 822.  The approach aims to maximise the services offered across the boundary, whilst not requiring unduly complex mappings. The mappings should not require any changes to end systems. This document is a revision based on RFCs 987, 1026, 1138, and 1148,which it obsoletes.</t>

<t>This document specifies a mapping between two protocols.  This specification should be used when this mapping is performed on the DARPA Internet or in the UK Academic Community.  This specification may be modified in the light of implementation experience, but no substantial changes are expected.</t>
</abstract>
</front>

<seriesInfo value="1327" name="RFC" />
</reference>


<reference target2="reference.RFC.1328.xml" anchor="RFC1328">
<front>
<title>X.400 1988 to 1984 downgrading</title>
<author fullname="Steve Hardcastle-Kille" initials="S." surname="Hardcastle-Kille">
<organization>University College London, Department of Computer Science</organization>

<address>
<postal>
<street>Gower Street</street>
<city>London</city>
<region>England</region>
<code>WC1E 6BT</code>
<country>UK</country>
</postal>

<phone>+44 71 3807294</phone>
<email>S.Kille@CS.UCL.AC.UK</email>
</address>
</author>

<date year="1992" month="May" />

<abstract>
<t>This document considers issues of downgrading from X.400 (1988) to  X.400 (1984),.  Annexe B of X.419 specifies some downgrading rules, but these are not sufficient for provision of service in an environment containing both 1984 and 1988 components.  This document defines a number of extensions to this annexe.</t>

<t>This specification is not tutorial.  COSINE Study 8.2 by J.A.I. Craigie gives a useful overview.</t>
</abstract>
</front>

<seriesInfo value="1328" name="RFC" />
</reference>


<reference target2="reference.RFC.1329.xml" anchor="RFC1329">
<front>
<title abbrev="Address Resolution for Dual MAC FDDI Networks">Thoughts on Address Resolution for Dual MAC FDDI Networks</title>
<author fullname="Peter Kuehn" initials="P." surname="Kuehn">
<organization />

<address>
<postal>
<street>Raiffeisenstrasse 9b</street>
<city>Untermeitingen</city>
<region />
<code>8933</code>
<country>DE</country>
</postal>

<phone>.. 82 32 / 7 46 02</phone>
<email>thimmela@sniabg.wa.sni.de</email>
</address>
</author>

<date year="1992" month="May" />

<abstract>
<t>In this document an idea is submitted how IP and ARP can be used on inhomogeneous FDDI networks (FDDI networks with single MAC and dual MAC stations) by introducing a new protocol layer in the protocol suite of the dual MAC stations.  Thus two dual MAC stations are able to do a load splitting across the two rings and use the double bandwidth of 200 Mbits/s as single MAC stations.  The new layer is an extension of layer 3.  For the user, the higher layer protocols, IP and ARP the property "dual MAC" is transparent.  No modification is required in the protocol suite of single MAC stations and transparent bridges.</t>
</abstract>
</front>

<seriesInfo value="1329" name="RFC" />
</reference>


<reference target2="reference.RFC.1330.xml" anchor="RFC1330">
<front>
<title abbrev="X.500 and X.400 Plans for ESnet">Recommendations for the Phase I Deployment of OSI Directory Services (X.500) and OSI Message Handling Services (X.400) within the ESNET Community</title>
<author fullname="Allen Sturtevant" initials="A." surname="Sturtevant">
<organization>Lawrence Livermore National Laboratory</organization>

<address>
<postal>
<street>P.O. Box 5509; L-561</street>
<city>Livermore</city>
<region>CA</region>
<code>94551</code>
<country>US</country>
</postal>

<phone>+1 510 422 8266</phone>
<email>sturtevant@es.net</email>
</address>
</author>

<author fullname="Tony Genovese" initials="T." surname="Genovese">
<organization>Lawrence Livermore National Laboratory</organization>

<address>
<postal>
<street>P.O. Box 5509; L-561</street>
<city>Livermore</city>
<region>CA</region>
<code>94551</code>
<country>US</country>
</postal>

<phone>+1 510 423 2471</phone>
<email>genovese@es.net</email>
</address>
</author>

<author fullname="Arlene Getchell" initials="A." surname="Getchell">
<organization>Lawrence Livermore National Laboratory</organization>

<address>
<postal>
<street>P.O. Box 5509; L-561</street>
<city>Livermore</city>
<region>CA</region>
<code>94551</code>
<country>US</country>
</postal>

<phone>+1 510 423 6349</phone>
<email>getchell@es.net</email>
</address>
</author>

<author fullname="H. A. Kippenhan Jr." initials="H." surname="Kippenhan">
<organization>Fermi National Accelerator Laboratory</organization>

<address>
<postal>
<street>Wilson Hall 6W</street>
<street>MS-234</street>
<street>P.O. Box 500</street>
<city>Batavia</city>
<region>IL</region>
<code>60150</code>
<country>US</country>
</postal>

<phone>+1 708 840 8068</phone>
<email>kippenhan@fnal.fnal.gov</email>
</address>
</author>

<author fullname="Kevin Oberman" initials="K." surname="Oberman">
<organization>Lawrence Livermore National Laboratory</organization>

<address>
<postal>
<street>P.O. Box 5509; L-156</street>
<city>Livermore</city>
<region>CA</region>
<code>94551</code>
<country>US</country>
</postal>

<phone>+1 510 422 6955</phone>
<email>oberman1@llnl.gov</email>
</address>
</author>

<author fullname="Alan Turner" initials="A." surname="Turner">
<organization>Pacific Northwest Laboratory</organization>

<address>
<postal>
<street>P.O. Box 999; K7-57</street>
<city>Richland</city>
<region>WA</region>
<code>99352</code>
<country>US</country>
</postal>

<phone>+1 509 375 6670</phone>
<email>ae_turner@pnl.gov</email>
</address>
</author>

<author fullname="Linda Winkler" initials="L." surname="Winkler">
<organization>Argonne National Laboratory</organization>

<address>
<postal>
<street>9700 South Cass Avenue</street>
<street>Building 221 B251</street>
<city>Argonne</city>
<region>IL</region>
<code>60439</code>
<country>US</country>
</postal>

<phone>+1 708 252 7236</phone>
<email>lwinkler@anl.gov</email>
</address>
</author>

<author fullname="Russ Wright" initials="R." surname="Wright">
<organization>Lawrence Berkeley Laboratory</organization>

<address>
<postal>
<street>1 Cyclotron Road</street>
<street>MS 50B-2258</street>
<city>Berkeley</city>
<region>CA</region>
<code>94720</code>
<country>US</country>
</postal>

<phone>+1 510 486 6965</phone>
<email>wright@lbl.gov</email>
</address>
</author>

<date year="1992" month="May" />

<abstract>
<t>This document recommends an initial approach for the Phase I deployment of OSI Directory Services (X.500) and OSI Message Handling Services (X.400) within the ESnet community.  It is anticipated that directly connected ESnet backbone sites will participate and follow the suggestions set forth in this document.</t>

<t>Section 7 of the "ESnet Program Plan" (DOE/OER-0486T, dated March 1991) cites the need for further research and investigation in the  areas of electronic mail and directory services.  The ESCC X.500/X.400 Task Force was created to address this need. Additionally, the task force is addressing the issues of a coordinated, interoperable deployment of OSI Directory Services and OSI Message Handling within the entire ESnet community.  Since only a small subset of this community is actively pursuing these avenues, considerable effort must be made to establish the necessary "base" to build upon.  If directly connected ESnet sites participate in these services, a consistent transition path will be ensured and the services provided will be mutually valuable and useful.</t>

<t>X.500 and X.400 are continuously evolving standards, and are typically updated every four years.  U.S. GOSIP (Government OSI Profile) Requirements are updated to define additional functionality as needed by the U.S. Federal Government, usually every two years. As the X.500 and X.400 standards evolve and U.S. GOSIP Requirements are extended, consideration must be given as to the effect this may have on these existing services in the ESnet community.  At these cross-roads, or when a sizeable increase in service functionality is desired, another "phase of deployment" may be in order.  In this sense, there isn't a specific "final phase" goal, but rather several new releases (updates) to the level of existing services.</t>
</abstract>
</front>

<seriesInfo value="1330" name="RFC" />
</reference>


<reference target2="reference.RFC.1331.xml" anchor="RFC1331">
<front>
<title abbrev="Point-to-Point Protocol">The Point-to-Point Protocol (PPP) for the Transmission of Multi-protocol Datagrams over Point-to-Point Links</title>
<author fullname="William Allen Simpson" initials="W." surname="Simpson">
<organization>Daydreamer, Computer Systems Consulting Services</organization>

<address>
<postal>
<street>P O Box 6205</street>
<city>East Lansing</city>
<region>MI</region>
<code>48826-6025</code>
<country>US</country>
</postal>

<email>bsimpson@ray.lloyd.com</email>
</address>
</author>

<date year="1992" month="May" />

<abstract>
<t>The Point-to-Point Protocol (PPP) provides a method for transmitting datagrams over serial point-to-point links.  PPP is comprised of three main components:</t>

<t>1. A method for encapsulating datagrams over serial links.</t>

<t>2. A Link Control Protocol (LCP) for establishing, configuring, and testing the data-link connection.</t>

<t>3. A family of Network Control Protocols (NCPs) for establishing and configuring different network-layer protocols.</t>

<t>This document defines the PPP encapsulation scheme, together with the PPP Link Control Protocol (LCP), an extensible option negotiation protocol which is able to negotiate a rich assortment of configuration parameters and provides additional management functions.</t>

<t>This RFC is a product of the Point-to-Point Protocol Working Group of the Internet Engineering Task Force (IETF).  Comments on this memo should be submitted to the ietf-ppp@ucdavis.edu mailing list.</t>
</abstract>
</front>

<seriesInfo value="1331" name="RFC" />
</reference>


<reference target2="reference.RFC.1332.xml" anchor="RFC1332">
<front>
<title abbrev="PPP IPCP">The PPP Internet Protocol Control Protocol (IPCP)</title>
<author fullname="Glenn McGregor" initials="G." surname="McGregor">
<organization>Merit Network, Inc.</organization>

<address>
<postal>
<street>1071 Beal Avenue</street>
<city>Ann Arbor</city>
<region>MI</region>
<code>48109-2103</code>
<country>US</country>
</postal>

<phone>+1 313 763 1203</phone>
<email>Glenn.McGregor@Merit.edu</email>
</address>
</author>

<date year="1992" month="May" />

<abstract>
<t>The Point-to-Point Protocol (PPP)provides a standard method of encapsulating Network Layer protocol information over point-to-point links.  PPP also defines an extensible Link Control Protocol, and proposes a family of Network Control Protocols (NCPs) for establishing and configuring different network-layer protocols.</t>

<t>This document defines the NCP for establishing and configuring the Internet Protocolover PPP, and a method to negotiate and use Van Jacobson TCP/IP header compressionwith PPP.</t>

<t>This RFC is a product of the Point-to-Point Protocol Working Group of the Internet Engineering Task Force (IETF).</t>
</abstract>
</front>

<seriesInfo value="1332" name="RFC" />
</reference>


<reference target2="reference.RFC.1333.xml" anchor="RFC1333">
<front>
<title>PPP Link Quality Monitoring</title>
<author fullname="William Allen Simpson" initials="W." surname="Simpson">
<organization>Daydreamer, Computer Systems Consulting Services</organization>

<address>
<postal>
<street>P O Box 6205</street>
<city>East Lansing</city>
<region>MI</region>
<code>48826-6025</code>
<country>US</country>
</postal>

<email>bsimpson@ray.lloyd.com</email>
</address>
</author>

<date year="1992" month="May" />

<abstract>
<t>The Point-to-Point Protocol (PPP)provides a standard method of encapsulating Network Layer protocol information over point-to-point links.  PPP also defines an extensible Link Control Protocol, which allows negotiation of a Quality Protocol for continuous monitoring of the viability of the link.</t>

<t>This document defines a protocol for generating Link-Quality-Reports.</t>

<t>This RFC is a product of the Point-to-Point Protocol Working Group of the Internet Engineering Task Force (IETF).  Comments on this memo should be submitted to the ietf-ppp@ucdavis.edu mailing list.</t>
</abstract>
</front>

<seriesInfo value="1333" name="RFC" />
</reference>


<reference target2="reference.RFC.1334.xml" anchor="RFC1334">
<front>
<title abbrev="PPP Authentication">PPP Authentication Protocols</title>
<author fullname="Brian Lloyd" initials="B." surname="Lloyd">
<organization>Lloyd &amp; Associates</organization>

<address>
<postal>
<street>3420 Sudbury Road</street>
<city>Cameron Park</city>
<region>CA</region>
<code>95682</code>
<country>US</country>
</postal>

<phone>+1 916 676 1147</phone>
<email>brian@lloyd.com</email>
</address>
</author>

<author fullname="William Allen Simpson" initials="W.A." surname="Simpson">
<organization>Daydreamer Computer Systems Consulting Services</organization>

<address>
<postal>
<street>P O Box 6205</street>
<city>East Lansing</city>
<region>MI</region>
<code>48826-6205</code>
<country>US</country>
</postal>

<email>Bill.Simpson@um.cc.umich.edu</email>
</address>
</author>

<date year="1992" month="October" />

<abstract>
<t>The Point-to-Point Protocol (PPP)provides a standard method of encapsulating Network Layer protocol information over point-to-point links.  PPP also defines an extensible Link Control Protocol, which allows negotiation of an, Authentication Protocol for authenticating its peer before allowing Network Layer protocols to transmit over the link.</t>

<t>This document defines two protocols for Authentication: the Password Authentication Protocol and the Challenge-Handshake Authentication Protocol.  This memo is the product of the Point-to-Point Protocol Working Group of the Internet Engineering Task Force (IETF). Comments on this memo should be submitted to the ietf-ppp@ucdavis.edu mailing list.</t>
</abstract>
</front>

<seriesInfo value="1334" name="RFC" />
</reference>


<reference target2="reference.RFC.1335.xml" anchor="RFC1335">
<front>
<title abbrev="Two-Tier Address Structure for the Internet">A Two-Tier Address Structure for the Internet: A Solution to the Problem of Address Space Exhaustion</title>
<author fullname="Zheng Wang" initials="Z." surname="Wang">
<organization>University College London, Dept. of Computer Science</organization>

<address>
<postal>
<street>Gower Street</street>
<city>London</city>
<region>England</region>
<code>WC1E 6BT</code>
<country>UK</country>
</postal>

<email>z.wang@cs.ucl.ac.uk</email>
</address>
</author>

<author fullname="Jon Crowcroft" initials="J." surname="Crowcroft">
<organization>University College London, Dept. of Computer Science</organization>

<address>
<postal>
<street>Gower Street</street>
<city>London</city>
<region>England</region>
<code>WC1E 6BT</code>
<country>UK</country>
</postal>

<email>j.crowcroft@cs.ucl.ac.uk</email>
</address>
</author>

<date year="1992" month="May" />

<abstract>
<t>This RFC presents a solution to problem of address space exhaustion in the Internet.  It proposes a two-tier address structure for the Internet.  This is an "idea" paper and discussion is strongly encouraged.</t>
</abstract>
</front>

<seriesInfo value="1335" name="RFC" />
</reference>


<reference target2="reference.RFC.1336.xml" anchor="RFC1336">
<front>
<title abbrev="Who&apos;s Who">Who's Who in the Internet: Biographies of IAB, IESG and IRSG Members</title>
<author fullname="Gary Scott Malkin" initials="G.S." surname="Malkin">
<organization>Xylogics, Inc.</organization>

<address>
<postal>
<street>53 Third Avenue</street>
<city>Burlington</city>
<region>MA</region>
<code>01803</code>
<country>US</country>
</postal>

<phone>+1 617 272 8140</phone>
<email>gmalkin@Xylogics.COM</email>
</address>
</author>

<date year="1992" month="May" />

<abstract>
<t>This FYI RFC contains biographical information about members of the Internet Activities Board (IAB), the Internet Engineering Steering Group (IESG) of the Internet Engineering Task Force (IETF), and the Internet Research Steering Group (IRSG) of the Internet Research Task Force (IRTF).</t>
</abstract>
</front>

<seriesInfo value="1336" name="RFC" />
</reference>


<reference target2="reference.RFC.1337.xml" anchor="RFC1337">
<front>
<title abbrev="TCP TIME-WAIT Hazards">TIME-WAIT Assassination Hazards in TCP</title>
<author fullname="Bob Braden" initials="B." surname="Braden">
<organization>University of Southern California (USC), Information Sciences Institute</organization>

<address>
<postal>
<street>4676 Admiralty Way</street>
<city>Marina del Rey</city>
<region>CA</region>
<code>90292</code>
<country>US</country>
</postal>

<phone>+1 213 822 1511</phone>
<email>EMail: Braden@ISI.EDU</email>
</address>
</author>

<date year="1992" month="May" />

<abstract>
<t>This note describes some theoretically-possible failure modes for TCP connections and discusses possible remedies.  In particular, one very simple fix is identified.</t>
</abstract>
</front>

<seriesInfo value="1337" name="RFC" />
</reference>


<reference target2="reference.RFC.1338.xml" anchor="RFC1338">
<front>
<title abbrev="Supernetting">Supernetting: an Address Assignment and Aggregation Strategy</title>
<author fullname="Vince Fuller" initials="V." surname="Fuller">
<organization>BARRNet</organization>

<address>
<postal>
<street>Pine Hall 115</street>
<city>Stanford</city>
<region>CA</region>
<code>94305-4122</code>
<country>US</country>
</postal>

<email>vaf@Stanford.EDU</email>
</address>
</author>

<author fullname="Tony Li" initials="T." surname="Li">
<organization>cisco Systems, Inc.</organization>

<address>
<postal>
<street>1525 O'Brien Drive</street>
<city>Menlo Park</city>
<region>CA</region>
<code>94025</code>
<country>US</country>
</postal>

<email>tli@cisco.com</email>
</address>
</author>

<author fullname="Jessica (Jie Yun) Yu" initials="J." surname="Yu">
<organization>Merit Network, Inc.</organization>

<address>
<postal>
<street>1071 Beal Ave.</street>
<city>Ann Arbor</city>
<region>MI</region>
<code>48109</code>
<country>US</country>
</postal>

<email>jyy@merit.edu</email>
</address>
</author>

<author fullname="Kannan Varadhan" initials="K." surname="Varadhan">
<organization>OARnet</organization>

<address>
<postal>
<street>1224 Kinnear Road</street>
<city>Columbus</city>
<region>OH</region>
<code>43212</code>
<country>US</country>
</postal>

<email>kannan@oar.net</email>
</address>
</author>

<date year="1992" month="June" />

<abstract>
<t>This memo discusses strategies for address assignment of the existing IP address space with a view to conserve the address space and stem the explosive growth of routing tables in default-route-free routers run by transit routing domain providers.</t>
</abstract>
</front>

<seriesInfo value="1338" name="RFC" />
</reference>


<reference target2="reference.RFC.1339.xml" anchor="RFC1339">
<front>
<title>Remote Mail Checking Protocol</title>
<author fullname="Steve Dorner" initials="S." surname="Dorner">
<organization>University of Illinois at Urbana-Champaign, Digital Computer Laboratory</organization>

<address>
<postal>
<street>1304 West Springfield Avenue</street>
<city>Urbana</city>
<region>IL</region>
<code>61801</code>
<country>US</country>
</postal>

<phone>+1 217 244 1765</phone>
<email>s-dorner@uiuc.edu</email>
</address>
</author>

<author fullname="Pete Resnick" initials="P." surname="Resnick">
<organization>University of Illinois at Urbana-Champaign, The Beckman Institute</organization>

<address>
<postal>
<street>405 North Mathews Avenue</street>
<city>Urbana</city>
<region>IL</region>
<code>61801</code>
<country>US</country>
</postal>

<phone>+1 217 244 1265</phone>
<email>resnick@cogsci.uiuc.edu</email>
</address>
</author>

<date year="1992" month="June" />

<abstract>
<t>This RFC defines a protocol to provide a mail checking service to be used between a client and server pair. Typically, a small program on a client workstation would use the protocol to query a server in order to find out whether new mail has arrived for a specified user.</t>
</abstract>
</front>

<seriesInfo value="1339" name="RFC" />
</reference>


<reference target2="reference.RFC.1340.xml" anchor="RFC1340">
<front>
<title abbrev="Assigned Numbers">Assigned Numbers</title>
<author fullname="Joyce K. Reynolds" initials="J." surname="Reynolds">
<organization>University of Southern California (USC), Information Sciences Institute</organization>

<address>
<postal>
<street>4676 Admiralty Way</street>
<city>Marina del Rey</city>
<region>CA</region>
<code>90292</code>
<country>US</country>
</postal>

<phone>+1 310 822 1511</phone>
<email>JKREY@ISI.EDU</email>
</address>
</author>

<author fullname="Jon Postel" initials="J." surname="Postel">
<organization>University of Southern California (USC), Information Sciences Institute</organization>

<address>
<postal>
<street>4676 Admiralty Way</street>
<city>Marina del Rey</city>
<region>CA</region>
<code>90292</code>
<country>US</country>
</postal>

<phone>+1 310 822 1511</phone>
<email>POSTEL@ISI.EDU</email>
</address>
</author>

<date year="1992" month="July" />
</front>

<seriesInfo value="1340" name="RFC" />
</reference>


<reference target2="reference.RFC.1341.xml" anchor="RFC1341">
<front>
<title abbrev="MIME: Multipurpose Internet Mail Extensions">MIME (Multipurpose Internet Mail Extensions): Mechanisms for Specifying and Describing the Format of Internet Message Bodies</title>
<author fullname="Nathaniel S. Borenstein" initials="N." surname="Borenstein">
<organization>Bellcore</organization>

<address>
<postal>
<street>445 South St.</street>
<street>MRE 2D-296</street>
<city>Morristown</city>
<region>NJ</region>
<code>07962-1910</code>
<country>US</country>
</postal>

<phone>+1 201 829 4270</phone>
<facsimile>+1 201 829 7019</facsimile>
<email>nsb@bellcore.com</email>
</address>
</author>

<author fullname="Ned Freed" initials="N." surname="Freed">
<organization>Innosoft International, Inc.</organization>

<address>
<postal>
<street>250 West First Street</street>
<street>Suite 240</street>
<city>Claremont</city>
<region>CA</region>
<code>91711</code>
<country>US</country>
</postal>

<phone>+1 714 624 7907</phone>
<facsimile>+1 714 621 5319</facsimile>
<email>ned@innosoft.com</email>
</address>
</author>

<date year="1992" month="June" />

<abstract>
<t>RFC 822 defines  a  message  representation  protocol  which specifies  considerable  detail  about  message headers, but which leaves the message content, or message body,  as  flat ASCII  text.   This document redefines the format of message bodies to allow multi-part textual and  non-textual  message bodies  to  be  represented  and  exchanged  without loss of information.   This is based on earlier work  documented  in RFC  934  and  RFC  1049, but extends and revises that work. Because RFC 822 said so little about  message  bodies,  this document  is  largely  orthogonal to (rather than a revision of) RFC 822.</t>

<t>In  particular,  this  document  is  designed to provide facilities  to include multiple objects in a single message, to represent body text in  character  sets  other  than  US- ASCII,  to  represent formatted multi-font text messages, to represent non-textual material  such  as  images  and  audio fragments,  and  generally  to  facilitate  later extensions defining new types of Internet mail for use  by  cooperating mail agents.</t>

<t>This document does NOT extend Internet mail header fields to permit  anything  other  than  US-ASCII  text  data.   It is recognized that such extensions are necessary, and they  are the subject of a companion document.</t>

<t>A table of contents appears at the end of this document.</t>
</abstract>
</front>

<seriesInfo value="1341" name="RFC" />
</reference>


<reference target2="reference.RFC.1342.xml" anchor="RFC1342">
<front>
<title abbrev="Non-ASCII Mail Headers">Representation of Non-ASCII Text in Internet Message Headers</title>
<author fullname="Keith Moore" initials="K." surname="Moore">
<organization>University of Tennessee</organization>

<address>
<postal>
<street>107 Ayres Hall</street>
<city>Knoxville</city>
<region>TN</region>
<code>37996-1301</code>
<country>US</country>
</postal>

<email>moore@cs.utk.edu</email>
</address>
</author>

<date year="1992" month="June" />

<abstract>
<t>This memo describes an extension to the message format defined in(known to the IETF Mail Extensions Working Group as "RFC 1341"), to allow the representation of character sets other than ASCII in RFC 822 message headers.  The extensions described were designed to be highly compatible with existing Internet mail handling software, and to be easily implemented in mail readers that support RFC 1341.</t>
</abstract>
</front>

<seriesInfo value="1342" name="RFC" />
</reference>


<reference target2="reference.RFC.1343.xml" anchor="RFC1343">
<front>
<title abbrev="Multimedia Mail Configuration">A User Agent Configuration Mechanism for Multimedia Mail Format Information</title>
<author fullname="Nathaniel S. Borenstein" initials="N." surname="Borenstein">
<organization>Bellcore</organization>

<address>
<postal>
<street>445 South St.</street>
<street>MRE 2D-296</street>
<city>Morristown</city>
<region>NJ</region>
<code>07962-1910</code>
<country>US</country>
</postal>

<phone>+1 201 829 4270</phone>
<facsimile>+1 201 829 7019</facsimile>
<email>nsb@bellcore.com</email>
</address>
</author>

<date year="1992" month="June" />

<abstract>
<t>This memo suggests a  file  format  to  be used to inform multiple  mail  reading user agent programs  about the locally-installed facilities for handling mail in various formats.  The mechanism is explicitly designed to work with mail systems based Internet mail as defined  by RFC's 821, 822, 934, 1049, 1113,  and the Multipurpose Internet Mail Extensions, known as MIME. However, with some extensions it probably be made to work for X.400-based mail systems as well. he format and mechanism are proposed in a  manner tat  is  generally  operating-system independent.  However, certain  implementation  details  will  inevitably   reflect operating  system differences, some of which will have to be handled in a uniform manner for each operating system. This memo  makes  such  situations explicit, and, in an appendix, suggests  a  standard  behavior  under  the  UNIX  operating system.</t>
</abstract>
</front>

<seriesInfo value="1343" name="RFC" />
</reference>


<reference target2="reference.RFC.1344.xml" anchor="RFC1344">
<front>
<title abbrev="MIME and Mail Gateways">Implications of MIME for Internet Mail Gateways</title>
<author fullname="Nathaniel S. Borenstein" initials="N." surname="Borenstein">
<organization>Bellcore</organization>

<address>
<postal>
<street>445 South St.</street>
<street>MRE 2D-296</street>
<city>Morristown</city>
<region>NJ</region>
<code>07962-1910</code>
<country>US</country>
</postal>

<phone>+1 201 829 4270</phone>
<facsimile>+1 201 829 7019</facsimile>
<email>nsb@bellcore.com</email>
</address>
</author>

<date year="1992" month="June" />

<abstract>
<t>The recent development of MIME (Multipurpose  Internet Mail Extensions)  offers  a  wide  range of new opportunities for electronic mail system systems.  Most of these  opportunites are relevant only to user agents, the programs that interact with human users when they send and receive mail.   However, some  opportunities  are  also  opened up for mail transport systems.  While MIME was carefully designed so that it  does not  require  any  changes  to  Internet  electronic message transport  facilities,  there  are  several  ways  in  which message  transport  systems  may  want  to take advantage of MIME.  These opportunities are the subject of this memo.</t>
</abstract>
</front>

<seriesInfo value="1344" name="RFC" />
</reference>


<reference target2="reference.RFC.1345.xml" anchor="RFC1345">
<front>
<title>Character Mnemonics and Character Sets</title>
<author fullname="Keld Simonsen" initials="K." surname="Simonsen">
<organization>Rationel Almen Planlaegning</organization>

<address>
<postal>
<street>Sankt Joergens Alle 8</street>
<city>Koebenhavn V</city>
<region />
<code>DK-1615</code>
<country>DK</country>
</postal>

<phone>+45 31 226543</phone>
<facsimile>+45 33 158516</facsimile>
<email>Keld.Simonsen@dkuug.dk</email>
</address>
</author>

<date year="1992" month="June" />
</front>

<seriesInfo value="1345" name="RFC" />
</reference>


<reference target2="reference.RFC.1346.xml" anchor="RFC1346">
<front>
<title abbrev="Resource Allocation, Control, and Accounting">Resource Allocation, Control, and Accounting for the Use of Network Resources</title>
<author fullname="Phil Jones" initials="P." surname="Jones">
<organization>Joint Network Team (JNT)</organization>

<address>
<postal>
<street>RAL</street>
<street>Chilton</street>
<city>Didcot, Oxfordshire</city>
<region>England</region>
<code>OX11 0QX</code>
<country>UK</country>
</postal>

<phone>+44 235 446618</phone>
<facsimile>+44 235 446251</facsimile>
<email>p.jones@jnt.ac.uk</email>
</address>
</author>

<date year="1992" month="June" />
</front>

<seriesInfo value="1346" name="RFC" />
</reference>


<reference target2="reference.RFC.1347.xml" anchor="RFC1347">
<front>
<title abbrev="TUBA: A Proposal for Addressing and Routing">TCP and UDP with Bigger Addresses (TUBA), A Simple Proposal for Internet Addressing and Routing</title>
<author fullname="Ross Callon" initials="R." surname="Callon">
<organization>Digital Equipment Corporation (DEC)</organization>

<address>
<postal>
<street>550 King Street</street>
<street>LKG 1-2/A19</street>
<city>Littleton</city>
<region>MA</region>
<code>01460-1289</code>
<country>US</country>
</postal>

<phone>+1 508 486 5009</phone>
<email>Callon@bigfut.lkg.dec.com</email>
</address>
</author>

<date year="1992" month="June" />
</front>

<seriesInfo value="1347" name="RFC" />
</reference>


<reference target2="reference.RFC.1348.xml" anchor="RFC1348">
<front>
<title>DNS NSAP RRs</title>
<author fullname="Bill Manning" initials="B." surname="Manning">
<organization>Rice University - ONCS</organization>

<address>
<postal>
<street>6100 South Main</street>
<city>PO Box 1892</city>
<city>Houston</city>
<region>TX</region>
<code>77251-1892</code>
<country>US</country>
</postal>

<phone>+1 713 285 5415</phone>
<email>bmanning@rice.edu</email>
</address>
</author>

<date year="1992" month="July" />
</front>

<seriesInfo value="1348" name="RFC" />
</reference>


<reference target2="reference.RFC.1349.xml" anchor="RFC1349">
<front>
<title abbrev="Type of Service">Type of Service in the Internet Protocol Suite</title>
<author fullname="Philip Almquist" initials="P." surname="Almquist">
<organization />

<address>
<postal>
<street>214 Cole Street</street>
<street>Suite 2</street>
<city>San Francisco</city>
<region>CA</region>
<code>94117-1916</code>
<country>US</country>
</postal>

<phone>+1 415 752 2427</phone>
<email>almquist@Jessica.Stanford.EDU</email>
</address>
</author>

<date year="1992" month="July" />
</front>

<seriesInfo value="1349" name="RFC" />
</reference>


<reference target2="reference.RFC.1350.xml" anchor="RFC1350">
<front>
<title abbrev="TFTP Revision 2">The TFTP Protocol (Revision 2)</title>
<author fullname="Karen R. Sollins" initials="K." surname="Sollins">
<organization>Massachusetts Institute of Technology, Laboratory for Computer Science</organization>

<address>
<postal>
<street>545 Technology Square</street>
<city>Cambridge</city>
<region>MA</region>
<code>02139-1986</code>
<country>US</country>
</postal>

<phone>+1 617 253 6006</phone>
<email>SOLLINS@LCS.MIT.EDU</email>
</address>
</author>

<date year="1992" month="July" />
</front>

<seriesInfo value="33" name="STD" />
<seriesInfo value="1350" name="RFC" />
</reference>


<reference target2="reference.RFC.1351.xml" anchor="RFC1351">
<front>
<title>SNMP Administrative Model</title>
<author fullname="James R. Davin" initials="J." surname="Davin">
<organization>MIT, Laboratory for Computer Science</organization>

<address>
<postal>
<street>545 Technology Square</street>
<city>Cambridge</city>
<region>MA</region>
<code>02139</code>
<country>US</country>
</postal>

<phone>+1 617 253 6020</phone>
<email>jrd@ptt.lcs.mit.edu</email>
</address>
</author>

<author fullname="James M. Galvin" initials="J." surname="Galvin">
<organization>Trusted Information Systems, Inc.</organization>

<address>
<postal>
<street>3060 Washington Road</street>
<street>Route 97</street>
<city>Glenwood</city>
<region>MD</region>
<code>21738</code>
<country>US</country>
</postal>

<phone>+1 301 854 6889</phone>
<email>galvin@tis.com</email>
</address>
</author>

<author fullname="Keith McCloghrie" initials="K." surname="McCloghrie">
<organization>Hughes, LAN Systems, Inc.</organization>

<address>
<postal>
<street>1225 Charleston Road</street>
<city>Mountain View</city>
<region>CA</region>
<code>94043</code>
<country>US</country>
</postal>

<phone>+1 415 966 7934</phone>
<email>kzm@hls.com</email>
</address>
</author>

<date year="1992" month="July" />

<abstract>
<t>This memo presents an elaboration of the SNMP administrative model set forth in. This model provides a unified conceptual basis for administering SNMP protocol entities to support</t>

<t>o authentication and integrity,</t>

<t>o privacy,</t>

<t>o access control, and</t>

<t>o the cooperation of multiple protocol entities.</t>

<t>Please send comments to the SNMP Security Developers mailing list (snmp-sec-dev@tis.com).</t>
</abstract>
</front>

<seriesInfo value="1351" name="RFC" />
</reference>


<reference target2="reference.RFC.1352.xml" anchor="RFC1352">
<front>
<title>SNMP Security Protocols</title>
<author fullname="James M. Galvin" initials="J." surname="Galvin">
<organization>Trusted Information Systems, Inc.</organization>

<address>
<postal>
<street>3060 Washington Road</street>
<street>Route 97</street>
<city>Glenwood</city>
<region>MD</region>
<code>21738</code>
<country>US</country>
</postal>

<phone>+1 301 854 6889</phone>
<email>galvin@tis.com</email>
</address>
</author>

<author fullname="Keith McCloghrie" initials="K." surname="McCloghrie">
<organization>Hughes, LAN Systems, Inc.</organization>

<address>
<postal>
<street>1225 Charleston Road</street>
<city>Mountain View</city>
<region>CA</region>
<code>94043</code>
<country>US</country>
</postal>

<phone>+1 415 966 7934</phone>
<email>kzm@hls.com</email>
</address>
</author>

<author fullname="James R. Davin" initials="J." surname="Davin">
<organization>MIT, Laboratory for Computer Science</organization>

<address>
<postal>
<street>545 Technology Square</street>
<city>Cambridge</city>
<region>MA</region>
<code>02139</code>
<country>US</country>
</postal>

<phone>+1 617 253 6020</phone>
<email>jrd@ptt.lcs.mit.edu</email>
</address>
</author>

<date year="1992" month="July" />

<abstract>
<t>The Simple Network Management Protocol (SNMP) specificationallows for the protection of network management operations by a variety of security protocols.  The SNMP administrative model described inprovides a framework for securing SNMP network management. In the context of that framework, this memo defines protocols to support the following three security services:</t>

<t>o data integrity,</t>

<t>o data origin authentication, and</t>

<t>o data confidentiality.</t>

<t>Please send comments to the SNMP Security Developers mailing list (snmp-sec-dev@tis.com).</t>
</abstract>
</front>

<seriesInfo value="1352" name="RFC" />
</reference>


<reference target2="reference.RFC.1353.xml" anchor="RFC1353">
<front>
<title abbrev="SNMP Party MIB">Definitions of Managed Objects for Administration of SNMP Parties</title>
<author fullname="Keith McCloghrie" initials="K." surname="McCloghrie">
<organization>Hughes, LAN Systems, Inc.</organization>

<address>
<postal>
<street>1225 Charleston Road</street>
<city>Mountain View</city>
<region>CA</region>
<code>94043</code>
<country>US</country>
</postal>

<phone>+1 415 966 7934</phone>
<email>kzm@hls.com</email>
</address>
</author>

<author fullname="James R. Davin" initials="J." surname="Davin">
<organization>MIT, Laboratory for Computer Science</organization>

<address>
<postal>
<street>545 Technology Square</street>
<city>Cambridge</city>
<region>MA</region>
<code>02139</code>
<country>US</country>
</postal>

<phone>+1 617 253 6020</phone>
<email>jrd@ptt.lcs.mit.edu</email>
</address>
</author>

<author fullname="James M. Galvin" initials="J." surname="Galvin">
<organization>Trusted Information Systems, Inc.</organization>

<address>
<postal>
<street>3060 Washington Road</street>
<street>Route 97</street>
<city>Glenwood</city>
<region>MD</region>
<code>21738</code>
<country>US</country>
</postal>

<phone>+1 301 854 6889</phone>
<email>galvin@tis.com</email>
</address>
</author>

<date year="1992" month="July" />

<abstract>
<t>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 describes a representation of the SNMP parties defined inas objects defined according to the Internet Standard SMI. These definitions are consistent with the SNMP Security protocols set forth in.</t>
</abstract>
</front>

<seriesInfo value="1353" name="RFC" />
</reference>


<reference target2="reference.RFC.1354.xml" anchor="RFC1354">
<front>
<title>IP Forwarding Table MIB</title>
<author fullname="Fred Baker" initials="F." surname="Baker">
<organization>Advanced Computer Communications</organization>

<address>
<postal>
<street>315 Bollay Drive</street>
<city>Santa Barbara</city>
<region>CA</region>
<code>93117-6014</code>
<country>US</country>
</postal>

<phone>+1 805 685 4455</phone>
<email>fbaker@acc.com</email>
</address>
</author>

<date year="1992" month="July" />

<abstract>
<t>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 routes in the IP Internet.</t>

<t>It is proposed that the ipRouteTable defined by MIB-II (RFC 1213) be deprecated and replaced with this table.  This adds the ability to set or display multi-path routes, and varying routes by network management policy.</t>
</abstract>
</front>

<seriesInfo value="1354" name="RFC" />
</reference>


<reference target2="reference.RFC.1355.xml" anchor="RFC1355">
<front>
<title abbrev="Privacy and Accuracy in NIC Databases">Privacy and Accuracy Issues in Network Information Center Databases</title>
<author fullname="John Curran" initials="J." surname="Curran">
<organization>NSF Network Service Center (NNSC)</organization>

<address>
<postal>
<street>10 Moulton Street</street>
<city>Cambridge</city>
<region>MA</region>
<code>02138</code>
<country>US</country>
</postal>

<phone>+1 617 873 3400</phone>
<email>jcurran@nnsc.nsf.net</email>
</address>
</author>

<author fullname="April N. Marine" initials="A." surname="Marine">
<organization>SRI International, Network Information Systems Center</organization>

<address>
<postal>
<street>333 Ravenswood Avenue</street>
<street>EJ294</street>
<city>Menlo Park</city>
<region>CA</region>
<code>94025-3493</code>
<country>US</country>
</postal>

<phone>+1 415 859 5318</phone>
<email>april@nisc.sri.com</email>
</address>
</author>

<date year="1992" month="August" />

<abstract>
<t>This document provides a set of guidelines for the administration and operation of public Network Information Center (NIC) databases.  The purpose is to formalize procedures for the responsible handling of the personal and organizational information maintained by NICs in publically accessible databases, and to improve the accuracy and accessibility of such data where appropriate.</t>
</abstract>
</front>

<seriesInfo value="1355" name="RFC" />
</reference>


<reference target2="reference.RFC.1356.xml" anchor="RFC1356">
<front>
<title abbrev="Multiprotocol Interconnect on X.25">Multiprotocol Interconnect on X.25 and ISDN in the Packet Mode</title>
<author fullname="Andrew G. Malis" initials="A." surname="Malis">
<organization>BBN Communications</organization>

<address>
<postal>
<street>150 CambridgePark Drive</street>
<city>Cambridge</city>
<region>MA</region>
<code>02140</code>
<country>US</country>
</postal>

<phone>+1 617 873 3419</phone>
<email>malis@bbn.com</email>
</address>
</author>

<author fullname="David Robinson" initials="D." surname="Robinson">
<organization>Computervision Systems Integration</organization>

<address>
<postal>
<street>201 Burlington Road</street>
<city>Bedford</city>
<region>MA</region>
<code>01730</code>
<country>US</country>
</postal>

<phone>+1 617 275 1800 x2774</phone>
<email>drb@relay.prime.com</email>
</address>
</author>

<author fullname="Robert L. Ullmann" initials="R." surname="Ullmann">
<organization>Process Software Corporation</organization>

<address>
<postal>
<street>959 Concord Street</street>
<city>Framingham</city>
<region>MA</region>
<code>01701</code>
<country>US</country>
</postal>

<phone>+1 508 879 6994</phone>
<email>ariel@process.com</email>
</address>
</author>

<date year="1992" month="August" />

<abstract>
<t>This document specifies the encapsulation of IP and other network layer protocols over X.25 networks, in accordance and alignment with ISO/IEC and CCITT standards.  It is a replacement for RFC 877, "A Standard for the Transmission of IP Datagrams Over Public Data Networks".</t>

<t>It was written to correct several ambiguities in the Internet Standard for IP/X.25 (RFC 877), to align it with ISO/IEC standards that have been written following RFC 877, to allow interoperable multiprotocol operation between routers and bridges over X.25, and to add some additional remarks based upon practical experience with the specification over the 8 years since that RFC.</t>

<t>The substantive change to the IP encapsulation is an increase in the allowed IP datagram Maximum Transmission Unit from 576 to 1600, to reflect existing practice.</t>

<t>This document also specifies the Internet encapsulation for protocols, including IP, on the packet mode of the ISDN.  It applies to the use of Internet protocols on the ISDN in the circuit mode only when the circuit is established as an end-to-end X.25 connection.</t>
</abstract>
</front>

<seriesInfo value="1356" name="RFC" />
</reference>


<reference target2="reference.RFC.1357.xml" anchor="RFC1357">
<front>
<title abbrev="Format for E-mailing Bibliographic Records">A Format for E-mailing Bibliographic Records</title>
<author fullname="Danny Cohen" initials="D." surname="Cohen">
<organization>USC/Information Sciences Institute</organization>

<address>
<postal>
<street>4676 Admiralty Way</street>
<city>Marina del Rey</city>
<region>CA</region>
<code>90292-6695</code>
<country>US</country>
</postal>

<phone>+1 310 822 1511</phone>
<facsimile>+1 310 823 6714</facsimile>
<email>Cohen@ISI.EDU</email>
</address>
</author>

<date year="1992" month="July" />

<abstract>
<t>This memo defines a format for E-mailing bibliographic records of technical reports.  It is intended to accelerate the dissemination of information about new Computer Science Technical Reports (CS-TR).</t>
</abstract>
</front>

<seriesInfo value="1357" name="RFC" />
</reference>


<reference target2="reference.RFC.1358.xml" anchor="RFC1358">
<front>
<title abbrev="Charter of the IAB">Charter of the Internet Architecture Board (IAB)</title>
<author fullname="A. Lyman Chapin" initials="A.L." surname="Chapin">
<organization>Bolt, Beranek &amp; Newman, Internet Architecture Board (IAB)</organization>

<address>
<postal>
<street>150 Cambridge Park Drive</street>
<street>Mail Stop 20/5b</street>
<city>Cambridge</city>
<region>MA</region>
<code>02140</code>
<country>US</country>
</postal>

<phone>+1 617 873 3133</phone>
<email>lyman@BBN.COM</email>
</address>
</author>

<date year="1992" month="August" />
</front>

<seriesInfo value="1358" name="RFC" />
</reference>


<reference target2="reference.RFC.1359.xml" anchor="RFC1359">
<front>
<title abbrev="Connecting to the Internet">Connecting to the Internet - What Connecting Institutions Should Anticipate</title>
<author fullname="Martyne M. Hallgren" initials="M." surname="Hallgren">
<organization>Cornell University</organization>

<address>
<postal>
<street>143 Caldwell Hall</street>
<city>Ithaca</city>
<region>NY</region>
<code>14850</code>
<country>US</country>
</postal>

<phone>+1 607 255 5510</phone>
<email>martyne@nr-tech.cit.cornell.edu</email>
</address>
</author>

<author fullname="Jack Pope" initials="J." surname="Pope">
<organization>University of San Diego</organization>

<address>
<postal>
<street>9500 Gilman Drive</street>
<city>La Jolla</city>
<region>CA</region>
<code>92093</code>
<country>US</country>
</postal>

</address>
</author>

<author fullname="Pat Smith" initials="P." surname="Smith">
<organization>MERIT, Inc.</organization>

<address>
<postal>
<street />
<city>Ann Arbor</city>
<region>MI</region>
<code>48105</code>
<country>US</country>
</postal>

</address>
</author>

<author fullname="John Cordani" initials="J." surname="Cordani">
<organization>Eastern Michigan University</organization>

<address>
<postal>
<street />
<city>Ypsilanti</city>
<region>MI</region>
<code>48197</code>
<country>US</country>
</postal>

</address>
</author>

<author fullname="Steven Sather" initials="S." surname="Sather">
<organization>University of California, Los Angeles</organization>

<address>
<postal>
<street>405 Hilgard Avenue</street>
<street>POB 951361</street>
<city>Los Angeles</city>
<region>CA</region>
<code>90095</code>
<country>US</country>
</postal>

</address>
</author>

<author fullname="Joyce McGowan" initials="J." surname="McGowan">
<organization>University of Arkansas</organization>

<address>
<postal>
<street />
<city>Fayetteville</city>
<region>AK</region>
<code>72701</code>
<country>US</country>
</postal>

</address>
</author>

<date year="1992" month="August" />

<abstract>
<t>This FYI RFC outlines the major issues an institution should consider in the decision and implementation of a campus connection to the Internet.</t>

<t>In order to provide clarity to the reader, some specific information has been detailed.  In doing so, the document has been directed toward U.S. academic institutions that have not yet connected to the Internet.</t>

<t>However, the issues for which specific information has been provided can be generalized for any organization that wishes to participate in the world-wide Internet community.  It will be necessary for those organizations to obtain the correct and detailed information from their local or national IP service providers.  In addition, this document may be used as an evaluation checklist for organizations that are currently connected.  Readers are expected to have general familiarity with networking concepts and terminology.</t>
</abstract>
</front>

<seriesInfo value="1359" name="RFC" />
</reference>


<reference target2="reference.RFC.1360.xml" anchor="RFC1360">
<front>
<title abbrev="IAB Standards">IAB Official Protocol Standards</title>
<author fullname="Jon Postel" initials="J." surname="Postel">
<organization>USC/Information Sciences Institute</organization>

<address>
<postal>
<street>4676 Admiralty Way</street>
<city>Marina del Rey</city>
<region>CA</region>
<code>90292</code>
<country>US</country>
</postal>

<phone>+1 310 822 1511</phone>
<facsimile>+1 310 823 6714</facsimile>
<email>Postel@ISI.EDU</email>
</address>
</author>

<date year="1992" month="September" />
</front>

<seriesInfo value="1360" name="RFC" />
</reference>


<reference target2="reference.RFC.1361.xml" anchor="RFC1361">
<front>
<title abbrev="SNTP">Simple Network Time Protocol (SNTP)</title>
<author fullname="David L. Mills" initials="D.L." surname="Mills">
<organization>University of Delaware, Electrical Engineering Department</organization>

<address>
<postal>
<street />
<city>Newark</city>
<region>DE</region>
<code>19716</code>
<country>US</country>
</postal>

<phone>+1 302 831 8247</phone>
<email>mills@udel.edu</email>
</address>
</author>

<date year="1992" month="August" />

<abstract>
<t>This memorandum describes the Simple Network Time Protocol (SNTP),  which is an adaptation of the Network Time Protocol (NTP) used to synchronize computer clocks in the Internet. SNTP can be used when the ultimate performance of the full NTP implementation described in RFC-1305 is not needed or justified. It involves no change to the current or previous NTP specification versions or known implementations, but rather a clarification of certain design features of NTP which allow operation in a simple, stateless RPC mode with accuracy and reliability expectations similar to the UDP/TIME protocol described in RFC-868.</t>

<t>This memorandum does not obsolete or update any RFC. A working knowledge of RFC-1305 is not required for an implementation of SNTP.</t>
</abstract>
</front>

<seriesInfo value="1361" name="RFC" />
</reference>


<reference target2="reference.RFC.1362.xml" anchor="RFC1362">
<front>
<title abbrev="IPXWAN">Novell IPX over Various WAN Media (IPXWAN)</title>
<author fullname="Michael Allen" initials="M." surname="Allen">
<organization>Novell, Inc.</organization>

<address>
<postal>
<street>2180 Fortune Drive</street>
<city>San Jose</city>
<region>CA</region>
<code>95131</code>
<country>US</country>
</postal>

<email>MALLEN@NOVELL.COM</email>
</address>
</author>

<date year="1992" month="September" />

<abstract>
<t>This document describes how Novell IPX operates over various WAN media.  Specifically, it describes the common "IPX WAN" protocol Novell uses to exchange necessary router to router information prior to exchanging standard IPX routing information and traffic over WAN datalinks.</t>
</abstract>
</front>

<seriesInfo value="1362" name="RFC" />
</reference>


<reference target2="reference.RFC.1363.xml" anchor="RFC1363">
<front>
<title>A Proposed Flow Specification</title>
<author fullname="Craig Partridge" initials="C." surname="Partridge">
<organization>BBN</organization>

<address>
<postal>
<street>824 Kipling St</street>
<city>Palo Alto</city>
<region>CA</region>
<code>94301</code>
<country>US</country>
</postal>

<phone>+1 415 325 4541</phone>
<email>craig@aland.bbn.com</email>
</address>
</author>

<date year="1992" month="September" />

<abstract>
<t>A flow specification (or "flow spec") is a data structure used by internetwork hosts to request special services of the internetwork, often guarantees about how the internetwork will handle some of the hosts' traffic.  In the future, hosts are expected to have to request such services on behalf of distributed applications such as multimedia conferencing.</t>

<t>The flow specification defined in this memo is intended for information and possible experimentation (i.e., experimental use by consenting routers and applications only).  This RFC is a product of the Internet Research Task Force (IRTF).</t>
</abstract>
</front>

<seriesInfo value="1363" name="RFC" />
</reference>


<reference target2="reference.RFC.1364.xml" anchor="RFC1364">
<front>
<title>BGP OSPF Interaction</title>
<author fullname="Kannan Varadhan" initials="K." surname="Varadhan">
<organization>OARnet</organization>

<address>
<postal>
<street>1224 Kinnear Road</street>
<city>Columbus</city>
<region>OH</region>
<code>43212-1136</code>
<country>US</country>
</postal>

<email>kannan@oar.net</email>
</address>
</author>

<date year="1992" month="September" />

<abstract>
<t>This memo defines the various criteria to be used when designing Autonomous System Border Routers (ASBR) that will run BGP with other ASBRs external to the AS and OSPF as its IGP.</t>
</abstract>
</front>

<seriesInfo value="1364" name="RFC" />
</reference>


<reference target2="reference.RFC.1365.xml" anchor="RFC1365">
<front>
<title abbrev="An IP Address Proposal">An IP Address Extension Proposal</title>
<author fullname="Karanjit Siyan" initials="K." surname="Siyan">
<organization>Siyan Consulting Services</organization>

<address>
<postal>
<street>49 Taurus Road, Box 960</street>
<street>North Glastonbury</street>
<city>Emigrant</city>
<region>MT</region>
<code>59027</code>
<country>US</country>
</postal>

<phone>+1 406 333 4491</phone>
<email>72550.1634@compuserve.com</email>
</address>
</author>

<date year="1992" month="September" />

<abstract>
<t>This RFC suggests an extension to the IP protocol to solve the shortage of IP address problem, and requests discussion and suggestions for improvements.</t>
</abstract>
</front>

<seriesInfo value="1365" name="RFC" />
</reference>


<reference target2="reference.RFC.1366.xml" anchor="RFC1366">
<front>
<title>Guidelines for Management of IP Address Space</title>
<author fullname="Elise Gerich" initials="E." surname="Gerich">
<organization>Merit Computer Network</organization>

<address>
<postal>
<street>1075 Beal Avenue</street>
<city>Ann Arbor</city>
<region>MI</region>
<code>48109-2112</code>
<country>US</country>
</postal>

<phone>+1 313 936 3000</phone>
<email>epg@MERIT.EDU</email>
</address>
</author>

<date year="1992" month="October" />

<abstract>
<t>This document has been reviewed by the Federal Engineering Task Force (FEPG) on behalf of the Federal Networking Council (FNC), the co-chairs of the International Engineering Planning Group (IEPG), and the Reseaux IP Europeens (RIPE).  There was general consensus by those groups to support the recommendations proposed in this document for management of the IP address space.</t>
</abstract>
</front>

<seriesInfo value="1366" name="RFC" />
</reference>


<reference target2="reference.RFC.1367.xml" anchor="RFC1367">
<front>
<title abbrev="Schedule for IP Address Space Guidelines">Schedule for IP Address Space Management Guidelines</title>
<author fullname="Claudio Topolcic" initials="C." surname="Topolcic">
<organization>Corporation for National Research Initiatives</organization>

<address>
<postal>
<street>895 Preston White Drive</street>
<street>Suite 100</street>
<city>Reston</city>
<region>VA</region>
<code>22091</code>
<country>US</country>
</postal>

<phone>+1 703 620 8990</phone>
<email>topolcic@NRI.Reston.VA.US</email>
</address>
</author>

<date year="1992" month="October" />
</front>

<seriesInfo value="1367" name="RFC" />
</reference>


<reference target2="reference.RFC.1368.xml" anchor="RFC1368">
<front>
<title abbrev="802.3 Repeater MIB">Definition of Managed Objects for IEEE 802.3 Repeater Devices</title>
<author fullname="Donna McMaster" initials="D." surname="McMaster">
<organization>SynOptics Communications, Inc.</organization>

<address>
<postal>
<street>4401 Great America Parkway</street>
<street>P.O. Box 58185</street>
<city>Santa Clara</city>
<region>CA</region>
<code>95052-8185</code>
<country>US</country>
</postal>

<email>mcmaster@synoptics.com</email>
</address>
</author>

<author fullname="Keith McCloghrie" initials="K." surname="McCloghrie">
<organization>Hughes LAN Systems, Inc.</organization>

<address>
<postal>
<street>1225 Charleston Road</street>
<city>Mountain View</city>
<region>CA</region>
<code>94043</code>
<country>US</country>
</postal>

<phone>+1 415 966 7934</phone>
<email>kzm@hls.com</email>
</address>
</author>

<date year="1992" month="October" />

<abstract>
<t>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 IEEE 802.3 10 Mb/second baseband repeaters, sometimes referred to as "hubs."</t>
</abstract>
</front>

<seriesInfo value="1368" name="RFC" />
</reference>


<reference target2="reference.RFC.1369.xml" anchor="RFC1369">
<front>
<title abbrev="Ethernet MIB Implementations">Implementation Notes and Experience for the Internet Ethernet MIB</title>
<author fullname="Frank J. Kastenholz" initials="F." surname="Kastenholz">
<organization>FTP Software</organization>

<address>
<postal>
<street>2 High Street</street>
<city>North Andover</city>
<region>MA</region>
<code>01845</code>
<country>US</country>
</postal>

<phone>+1 508 685 4000</phone>
<email>kasten@ftp.com</email>
</address>
</author>

<date year="1992" month="October" />
</front>

<seriesInfo value="1369" name="RFC" />
</reference>


<reference target2="reference.RFC.1370.xml" anchor="RFC1370">
<front>
<title abbrev="Applicability Statement: OSPF">Applicability Statement for OSPF</title>
<author fullname="A. Lyman Chapin" initials="A.L." surname="Chapin">
<organization>BBN Communications Corporation</organization>

<address>
<postal>
<street>150 Cambridge Park Drive</street>
<city>Cambridge</city>
<region>MA</region>
<code>02140</code>
<country>US</country>
</postal>

<phone>+1 617 873 3133</phone>
<facsimile>+1 617 873 4086</facsimile>
<email>Lyman@BBN.COM</email>
</address>
</author>

<date year="1992" month="October" />
</front>

<seriesInfo value="1370" name="RFC" />
</reference>


<reference target2="reference.RFC.1371.xml" anchor="RFC1371">
<front>
<title abbrev="Choosing a &quot;Common IGP&quot;">Choosing a Common IGP for the IP Internet</title>
<author fullname="Phillip Gross" initials="P." surname="Gross">
<organization>Advanced Network &amp; Services</organization>

<address>
<postal>
<street>100 Clearbrook Road</street>
<city>Elmsford</city>
<region>NY</region>
<code>10523</code>
<country>US</country>
</postal>

<phone>+1 914 789 5300</phone>
<email>pgross@ans.net</email>
</address>
</author>

<date year="1992" month="October" />

<abstract>
<t>This memo presents motivation, rationale and other surrounding background information leading to the IESG's recommendation to the IAB for a single "common IGP" for the IP portions of the Internet.</t>

<t>In this memo, the term "common IGP" is defined, the need for a common IGP is explained, the relation of this issue to other ongoing Internet Engineering Task Force (IETF) routing protocol development is provided, and the relation of this issue to the goal for multi-protocol integration in the Internet is explored.</t>

<t>Finally, a specific IGP is recommended as the "common IGP" for IP portions of the Internet -- the Open Shortest Path First (OSPF) routing protocol.</t>

<t>The goal of this recommendation is for all vendors of Internet IP routers to make OSPF available as one of the IGP's provided with their routers.</t>
</abstract>
</front>

<seriesInfo value="1371" name="RFC" />
</reference>


<reference target2="reference.RFC.1372.xml" anchor="RFC1372">
<front>
<title>Telnet Remote Flow Control Option</title>
<author fullname="Charles Hedrick" initials="C." surname="Hedrick">
<organization>Rutgers University</organization>

<address>
<postal>
<street>227 CORE Building</street>
<street>P.O. Box 879</street>
<city>Piscataway</city>
<region>NJ</region>
<code>08855-0879</code>
<country>US</country>
</postal>

<phone>+1 908 932 3088</phone>
<email>hedrick@cs.rutgers.edu</email>
</address>
</author>

<author fullname="David Borman" initials="D." surname="Borman">
<organization>Cray Research, Inc.</organization>

<address>
<postal>
<street>655F Lone Oak Drive</street>
<city>Eagan</city>
<region>MN</region>
<code>55121</code>
<country>US</country>
</postal>

<phone>+1 612 452 6650</phone>
<email>dab@CRAY.COM</email>
</address>
</author>

<date year="1992" month="October" />
</front>

<seriesInfo value="1372" name="RFC" />
</reference>


<reference target2="reference.RFC.1373.xml" anchor="RFC1373">
<front>
<title abbrev="DSA Support for Portable DUAs">Portable DUAs</title>
<author fullname="Tom Tignor" initials="T." surname="Tignor">
<organization>University of Southern California, Information Sciences Institute</organization>

<address>
<postal>
<street>4676 Admiralty Way</street>
<city>Marina del Rey</city>
<region>CA</region>
<code>90292</code>
<country>US</country>
</postal>

<phone>+1 310 822 1511</phone>
<email>tpt2@isi.edu</email>
</address>
</author>

<date year="1992" month="October" />
</front>

<seriesInfo value="1373" name="RFC" />
</reference>


<reference target2="reference.RFC.1374.xml" anchor="RFC1374">
<front>
<title>IP and ARP on HIPPI</title>
<author fullname="John K. Renwick" initials="J." surname="Renwick">
<organization>Cray Research, Inc.</organization>

<address>
<postal>
<street>655F Lone Oak Drive</street>
<city>Eagan</city>
<region>MN</region>
<code>55121</code>
<country>US</country>
</postal>

<phone>+1 612 683 5573</phone>
<email>jkr@CRAY.COM</email>
</address>
</author>

<author fullname="Andy Nicholson" initials="A." surname="Nicholson">
<organization>Cray Research, Inc.</organization>

<address>
<postal>
<street>655F Lone Oak Drive</street>
<city>Eagan</city>
<region>MN</region>
<code>55121</code>
<country>US</country>
</postal>

<phone>+1 612 683 5473</phone>
<email>droid@CRAY.COM</email>
</address>
</author>

<date year="1992" month="October" />

<abstract>
<t>The ANSI X3T9.3 committee has drafted a proposal for the encapsulation of IEEE 802.2 LLC PDUs and, by implication, IP on HIPPI.  Another X3T9.3 draft describes the operation of HIPPI physical switches.  X3T9.3 chose to leave HIPPI networking issues largely outside the scope of their standards; this document discusses methods of using of ANSI standard HIPPI hardware and protocols in the context of the Internet, including the use of HIPPI switches as LANs and interoperation with other networks.</t>
</abstract>
</front>

<seriesInfo value="1374" name="RFC" />
</reference>


<reference target2="reference.RFC.1375.xml" anchor="RFC1375">
<front>
<title abbrev="New Classes of IP Addresses">Suggestion for New Classes of IP Addresses</title>
<author fullname="Paul Robinson" initials="P." surname="Robinson">
<organization>Tansin A. Darcos &amp; Company</organization>

<address>
<postal>
<street>8604 Second Avenue #104</street>
<city>Silver Spring</city>
<region>MD</region>
<code>20910</code>
<country>US</country>
</postal>

<phone>+1 202 310 1011</phone>
<email>TDARCOS@MCIMAIL.COM</email>
</address>
</author>

<date year="1992" month="October" />

<abstract>
<t>This RFC suggests a change in the method of specifying the IP address to add new classes of networks to be called F, G, H, and K, to reduce the amount of wasted address space, and to increase the available IP address number space, especially for smaller organizations or classes of connectors that do not need or do not want a full Class C IP address.</t>
</abstract>
</front>

<seriesInfo value="1375" name="RFC" />
</reference>


<reference target2="reference.RFC.1376.xml" anchor="RFC1376">
<front>
<title abbrev="PPP DNCP">The PPP DECnet Phase IV Control Protocol (DNCP)</title>
<author fullname="Steven J. Senum" initials="S.J." surname="Senum">
<organization>Network Systems Corporation</organization>

<address>
<postal>
<street>7600 Boone Avenue North</street>
<city>Minneapolis</city>
<region>MN</region>
<code>55428</code>
<country>US</country>
</postal>

<phone>+1 612 424 4888</phone>
<email>sjs@network.com</email>
</address>
</author>

<date year="1992" month="November" />

<abstract>
<t>The Point-to-Point Protocol (PPP)provides a standard method of encapsulating Network Layer protocol information over point-to-point links.  PPP also defines an extensible Link Control Protocol, and proposes a family of Network Control Protocols (NCPs) for establishing and configuring different network-layer protocols.</t>

<t>This document defines the NCP for establishing and configuring Digital's DNA Phase IV Routing protocol (DECnet Phase IV) over PPP. This document applies only to DNA Phase IV Routing messages (both data and control), and not to other DNA Phase IV protocols (MOP, LAT, etc.).</t>
</abstract>
</front>

<seriesInfo value="1376" name="RFC" />
</reference>


<reference target2="reference.RFC.1377.xml" anchor="RFC1377">
<front>
<title abbrev="PPP OSINLCP">The PPP OSI Network Layer Control Protocol (OSINLCP)</title>
<author fullname="Dave Katz" initials="D." surname="Katz">
<organization>cisco Systems, Inc.</organization>

<address>
<postal>
<street>1525 O'Brien Dr.</street>
<city>Menlo Park</city>
<region>CA</region>
<code>94025</code>
<country>US</country>
</postal>

<phone>+1 415 688 8284</phone>
<email>dkatz@cisco.com</email>
</address>
</author>

<date year="1992" month="November" />

<abstract>
<t>The Point-to-Point Protocol (PPP)provides a standard method of encapsulating Network Layer protocol information over point-to-point links.  PPP also defines an extensible Link Control Protocol, and proposes a family of Network Control Protocols (NCPs) for establishing and configuring different network-layer protocols.</t>

<t>This document defines the NCP for establishing and configuring OSI Network Layer Protocols.</t>

<t>This memo is the product of the Point-to-Point Protocol Working Group of the Internet Engineering Task Force (IETF).  Comments on this memo should be submitted to the ietf-ppp@ucdavis.edu mailing list.</t>
</abstract>
</front>

<seriesInfo value="1377" name="RFC" />
</reference>


<reference target2="reference.RFC.1378.xml" anchor="RFC1378">
<front>
<title abbrev="PPP ATCP">The PPP AppleTalk Control Protocol (ATCP)</title>
<author fullname="Brad Parker" initials="B." surname="Parker">
<organization>Cayman Systems, Inc.</organization>

<address>
<postal>
<street>26 Landsdowne Street</street>
<city>Cambridge</city>
<region>MA</region>
<code>02139</code>
<country>US</country>
</postal>

<email>brad@cayman.com</email>
</address>
</author>

<date year="1992" month="November" />

<abstract>
<t>The Point-to-Point Protocol (PPP)provides a standard method of encapsulating Network Layer protocol information over point-to-point links.  PPP also defines an extensible Link Control Protocol, and proposes a family of Network Control Protocols (NCPs) for establishing and configuring different network-layer protocols.</t>

<t>This document defines the NCP for establishing and configuring the AppleTalk Protocolover PPP.</t>

<t>This memo is a joint effort of the AppleTalk-IP Working Group and the Point-to-Point Protocol Working Group of the Internet Engineering Task Force (IETF).  Comments on this memo should be submitted to the ietf-ppp@ucdavis.edu mailing list.</t>
</abstract>
</front>

<seriesInfo value="1378" name="RFC" />
</reference>


<reference target2="reference.RFC.1379.xml" anchor="RFC1379">
<front>
<title abbrev="Transaction TCP - Concepts">Extending TCP for Transactions -- Concepts</title>
<author fullname="Bob Braden" initials="B." surname="Braden">
<organization>University of Southern California,  Information Sciences Institute</organization>

<address>
<postal>
<street>4676 Admiralty Way</street>
<city>Marina del Rey</city>
<region>CA</region>
<code>90292</code>
<country>US</country>
</postal>

<phone>+1 310 822 1511</phone>
<email>Braden@ISI.EDU</email>
</address>
</author>

<date year="1992" month="November" />

<abstract>
<t>This memo discusses extension of TCP to provide transaction-oriented service, without altering its virtual-circuit operation.  This extension would fill the large gap between connection-oriented TCP and datagram-based UDP, allowing TCP to efficiently perform many applications for which UDP is currently used.  A separate memo contains a detailed functional specification for this proposed extension.</t>

<t>This work was supported in part by the National Science Foundation under Grant Number NCR-8922231.</t>
</abstract>
</front>

<seriesInfo value="1379" name="RFC" />
</reference>


<reference target2="reference.RFC.1380.xml" anchor="RFC1380">
<front>
<title abbrev="ROAD">IESG Deliberations on Routing and Addressing</title>
<author fullname="Phillip Gross" initials="P." surname="Gross">
<organization>Advanced Network &amp; Services</organization>

<address>
<postal>
<street>100 Clearbrook Road</street>
<city>Elmsford</city>
<region>NY</region>
<code>10523</code>
<country>US</country>
</postal>

<phone>+1 914 789 5300</phone>
<email>pgross@ans.net</email>
</address>
</author>

<author fullname="Philip Almquist" initials="P." surname="Almquist">
<organization>Stanford University, Networking Systems</organization>

<address>
<postal>
<street>Pine Hall 147</street>
<city>Stanford</city>
<region>CA</region>
<code>94305</code>
<country>US</country>
</postal>

<phone>+1 415 723 2229</phone>
<email>Almquist@JESSICA.STANFORD.EDU</email>
</address>
</author>

<date year="1992" month="November" />

<abstract>
<t>This memo summarizes issues surrounding the routing and addressing scaling problems in the IP architecture, and it provides a brief background of the ROAD group and related activities in the Internet   Engineering Task Force (IETF).</t>

<t>It also provides a preliminary report of the Internet Engineering Steering Group (IESG) deliberations on how these routing and addressing issues should be pursued in the Internet Architecture Board (IAB)/IETF.</t>
</abstract>
</front>

<seriesInfo value="1380" name="RFC" />
</reference>


<reference target2="reference.RFC.1381.xml" anchor="RFC1381">
<front>
<title abbrev="X.25 LAPB MIB">SNMP MIB Extension for X.25 LAPB</title>
<author fullname="Dean D. Throop" initials="D." surname="Throop">
<organization>Data General Corporation</organization>

<address>
<postal>
<street>62 Alexander Dr.</street>
<city>Research Triangle Park</city>
<region>NC</region>
<code>27709</code>
<country>US</country>
</postal>

<phone>+1 919 248 8421</phone>
<email>throop@dg-rtp.dg.com</email>
</address>
</author>

<author fullname="Fred Baker" initials="F." surname="Baker">
<organization>Advanced Computer Communications</organization>

<address>
<postal>
<street>315 Bollay Drive</street>
<city>Santa Barbara</city>
<region>CA</region>
<code>93101</code>
<country>US</country>
</postal>

<phone>+1 805 685 4455</phone>
<email>fbaker@acc.com</email>
</address>
</author>

<date year="1992" month="November" />

<abstract>
<t>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 Link Layer of X.25, LAPB.  The objects defined here, along with the objects in the "SNMP MIB Extension for the Packet Layer of X.25"and the "Definitions of Managed Objects for RS-232-like Hardware Devices", combine to allow management of an X.25 protocol stack.</t>
</abstract>
</front>

<seriesInfo value="1381" name="RFC" />
</reference>


<reference target2="reference.RFC.1382.xml" anchor="RFC1382">
<front>
<title abbrev="X.25 Packet Layer MIB">SNMP MIB Extension for the X.25 Packet Layer</title>
<author fullname="Dean D. Throop" initials="D." surname="Throop">
<organization>Data General Corporation</organization>

<address>
<postal>
<street>62 Alexander Dr.</street>
<city>Research Triangle Park</city>
<region>NC</region>
<code>27709</code>
<country>US</country>
</postal>

<phone>+1 919 248 8421</phone>
<email>throop@dg-rtp.dg.com</email>
</address>
</author>

<date year="1992" month="November" />

<abstract>
<t>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 Packet Layer of  X.25.  The objects defined here, along with the objects in the "SNMP MIB Extension for LAPB"and the "Definitions of Managed Objects for RS-232-like Hardware Devices", combine to allow management of an X.25 protocol stack.</t>
</abstract>
</front>

<seriesInfo value="1382" name="RFC" />
</reference>


<reference target2="reference.RFC.1383.xml" anchor="RFC1383">
<front>
<title abbrev="DNS based IP routing">An Experiment in DNS Based IP Routing</title>
<author fullname="Christian Huitema" initials="C." surname="Huitema">
<organization>INRIA, Sophia-Antipolis</organization>

<address>
<postal>
<street>2004 Route des Lucioles</street>
<street>BP 109</street>
<city>Valbonne Cedex</city>
<region />
<code>F-06561</code>
<country>FR</country>
</postal>

<phone>+33 93 657715</phone>
<email>Christian.Huitema@MIRSA.INRIA.FR</email>
</address>
</author>

<date year="1992" month="December" />
</front>

<seriesInfo value="1383" name="RFC" />
</reference>


<reference target2="reference.RFC.1384.xml" anchor="RFC1384">
<front>
<title abbrev="Naming Guidelines">Naming Guidelines for Directory Pilots</title>
<author fullname="Paul Barker" initials="P." surname="Barker">
<organization>University College London, Department of Computer Science</organization>

<address>
<postal>
<street>Gower Street</street>
<city>London</city>
<region>England</region>
<code>WC1E 6BT</code>
<country>UK</country>
</postal>

<phone>+44 71 3807366</phone>
<email>P.Barker@CS.UCL.AC.UK</email>
</address>
</author>

<author fullname="Steve Hardcastle-Kille" initials="S." surname="Hardcastle-Kille">
<organization>ISODE Consortium</organization>

<address>
<postal>
<street>POB 505</street>
<city>London</city>
<region>England</region>
<code>SW11 1DX</code>
<country>UK</country>
</postal>

<phone>+44 71 2234062</phone>
<email>S.Kille@ISODE.COM</email>
</address>
</author>

<date year="1993" month="January" />
</front>

<seriesInfo value="1384" name="RFC" />
</reference>


<reference target2="reference.RFC.1385.xml" anchor="RFC1385">
<front>
<title abbrev="EIP">EIP: The Extended Internet Protocol</title>
<author fullname="Zheng Wang" initials="Z." surname="Wang">
<organization>University College London, Dept of Computer Science</organization>

<address>
<postal>
<street>Gower Street</street>
<city>London</city>
<region>England</region>
<code>WC1E 6BT</code>
<country>UK</country>
</postal>

<email>z.wang@cs.ucl.ac.uk</email>
</address>
</author>

<date year="1992" month="November" />
</front>

<seriesInfo value="1385" name="RFC" />
</reference>


<reference target2="reference.RFC.1386.xml" anchor="RFC1386">
<front>
<title>The US Domain</title>
<author fullname="Ann Cooper" initials="A." surname="Cooper">
<organization>USC/Information Sciences Institute</organization>

<address>
<postal>
<street>4676 Admiralty Way</street>
<city>Marina del Rey</city>
<region>CA</region>
<code>90292</code>
<country>US</country>
</postal>

<phone>+1 310 822 1511</phone>
<email>cooper@isi.edu</email>
</address>
</author>

<author fullname="Jon Postel" initials="J." surname="Postel">
<organization>USC/Information Sciences Institute</organization>

<address>
<postal>
<street>4676 Admiralty Way</street>
<city>Marina del Rey</city>
<region>CA</region>
<code>90292</code>
<country>US</country>
</postal>

<phone>+1 310 822 1511</phone>
<email>postel@isi.edu</email>
</address>
</author>

<date year="1992" month="December" />
</front>

<seriesInfo value="1386" name="RFC" />
</reference>


<reference target2="reference.RFC.1387.xml" anchor="RFC1387">
<front>
<title abbrev="RIP-2 Analysis">RIP Version 2 Protocol Analysis</title>
<author fullname="Gary Scott Malkin" initials="G.S." surname="Malkin">
<organization>Xylogics, Inc.</organization>

<address>
<postal>
<street>53 Third Avenue</street>
<city>Burlington</city>
<region>MA</region>
<code>01803</code>
<country>US</country>
</postal>

<phone>+1 617 272 8140</phone>
<email>gmalkin@Xylogics.COM</email>
</address>
</author>

<date year="1993" month="January" />

<abstract>
<t>As required by Routing Protocol Criteria (RFC 1264), this report documents the key features of the RIP-2 protocol and the current implementation experience.</t>
</abstract>
</front>

<seriesInfo value="1387" name="RFC" />
</reference>


<reference target2="reference.RFC.1388.xml" anchor="RFC1388">
<front>
<title abbrev="RIP Version 2">RIP Version 2 Carrying Additional Information</title>
<author fullname="Gary Scott Malkin" initials="G." surname="Malkin">
<organization>Xylogics, Inc.</organization>

<address>
<postal>
<street>53 Third Avenue</street>
<city>Burlington</city>
<region>MA</region>
<code>01803</code>
<country>US</country>
</postal>

<phone>+1 617 272 8140</phone>
<email>gmalkin@Xylogics.COM</email>
</address>
</author>

<date year="1993" month="January" />

<abstract>
<t>This document specifies an extension of the Routing Information Protocol (RIP), as defined in, to expand the amount of useful information carried in RIP packets and to add a measure of security. A companion document will define the SNMP MIB objects for RIP-2.</t>
</abstract>
</front>

<seriesInfo value="1388" name="RFC" />
</reference>


<reference target2="reference.RFC.1389.xml" anchor="RFC1389">
<front>
<title abbrev="RIP-2 MIB Extension">RIP Version 2 MIB Extensions</title>
<author fullname="Gary Malkin" initials="G." surname="Malkin">
<organization>Xylogics, Inc.</organization>

<address>
<postal>
<street>53 Third Avenue</street>
<city>Burlington</city>
<region>MA</region>
<code>01803</code>
<country>US</country>
</postal>

<phone>+1 617 272 8140</phone>
<email>gmalkin@Xylogics.COM</email>
</address>
</author>

<author fullname="Fred Baker" initials="F." surname="Baker">
<organization>Advanced Computer Communications</organization>

<address>
<postal>
<street>315 Bollay Drive</street>
<city>Santa Barbara</city>
<region>CA</region>
<code>93117-6014</code>
<country>US</country>
</postal>

<phone>+1 805 685 4455</phone>
<email>fbaker@acc.com</email>
</address>
</author>

<date year="1993" month="January" />

<abstract>
<t>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 RIP Version 2.</t>
</abstract>
</front>

<seriesInfo value="1389" name="RFC" />
</reference>


<reference target2="reference.RFC.1390.xml" anchor="RFC1390">
<front>
<title abbrev="IP Over FDDI">Transmission of IP and ARP over FDDI Networks</title>
<author fullname="Dave Katz" initials="D." surname="Katz">
<organization>cisco Systems, Inc.</organization>

<address>
<postal>
<street>1525 O'Brien Dr.</street>
<city>Menlo Park</city>
<region>CA</region>
<code>94025</code>
<country>US</country>
</postal>

<phone>+1 415 688 8284</phone>
<email>dkatz@cisco.com</email>
</address>
</author>

<date year="1993" month="January" />

<abstract>
<t>This memo defines a method of encapsulating the Internet Protocol (IP) datagrams and Address Resolution Protocol (ARP) requests and replies on Fiber Distributed Data Interface (FDDI) Networks.</t>

<t>This RFC is the product of the IP over FDDI Working Group of the Internet Engineering Task Force (IETF).</t>
</abstract>
</front>

<seriesInfo value="36" name="STD" />
<seriesInfo value="1390" name="RFC" />
</reference>


<reference target2="reference.RFC.1391.xml" anchor="RFC1391">
<front>
<title abbrev="The Tao of IETF">The Tao of the IETF: A Guide for New Attendees of the Internet Engineering Task Force</title>
<author fullname="Gary Scott Malkin" initials="G.S." surname="Malkin">
<organization>Xylogics, Inc.</organization>

<address>
<postal>
<street>53 Third Avenue</street>
<city>Burlington</city>
<region>MA</region>
<code>01803</code>
<country>US</country>
</postal>

<phone>+1 617 272 8140</phone>
<email>gmalkin@Xylogics.COM</email>
</address>
</author>

<date year="1993" month="January" />

<abstract>
<t>Over the last two years, the attendance at Internet Engineering Task Force (IETF) Plenary meetings has grown phenomenally.  Approximately 38% of the attendees are new to the IETF at each meeting.  About 33% of those go on to become regular attendees.  When the meetings were smaller, it wasn't very difficult for a newcomer to get to know people and get into the swing of things.  Today, however, a newcomer meets many more new people, some previously known only as the authors of Request For Comments (RFC) documents or thought provoking email messages.</t>

<t>The purpose of this For Your Information (FYI) RFC is to explain to the newcomers how the IETF works.  This will give them a warm, fuzzy feeling and enable them to make the meeting more productive for everyone.  This FYI will also provide the mundane bits of information which everyone who attends an IETF meeting should know.</t>
</abstract>
</front>

<seriesInfo value="1391" name="RFC" />
</reference>


<reference target2="reference.RFC.1392.xml" anchor="RFC1392">
<front>
<title abbrev="Internet Glossary">Internet Users' Glossary</title>
<author fullname="Gary Scott Malkin" initials="G." surname="Malkin">
<organization>Xylogics, Inc.</organization>

<address>
<postal>
<street>53 Third Avenue</street>
<city>Burlington</city>
<region>MA</region>
<code>01803</code>
<country>US</country>
</postal>

<phone>+1 617 272 8140</phone>
<email>gmalkin@Xylogics.COM</email>
</address>
</author>

<author fullname="Tracy LaQuey Parker" initials="T." surname="Parker">
<organization>University of Texas at Austin, Computation Center</organization>

<address>
<postal>
<street />
<city>Austin</city>
<region>TX</region>
<code>78712</code>
<country>US</country>
</postal>

<phone>+1 512 471 2444</phone>
<email>tracy@utexas.edu</email>
</address>
</author>

<date year="1993" month="January" />

<abstract>
<t>There are many networking glossaries in existence.  This glossary concentrates on terms which are specific to the Internet.  Naturally, there are entries for some basic terms and acronyms because other entries refer to them.</t>
</abstract>
</front>

<seriesInfo value="1392" name="RFC" />
</reference>


<reference target2="reference.RFC.1393.xml" anchor="RFC1393">
<front>
<title abbrev="Traceroute">Traceroute Using an IP Option</title>
<author fullname="Gary Scott Malkin" initials="G." surname="Malkin">
<organization>Xylogics, Inc.</organization>

<address>
<postal>
<street>53 Third Avenue</street>
<city>Burlington</city>
<region>MA</region>
<code>01803</code>
<country>US</country>
</postal>

<phone>+1 617 272 8140</phone>
<email>gmalkin@Xylogics.COM</email>
</address>
</author>

<date year="1993" month="January" />

<abstract>
<t>Traceroute serves as a valuable network debugging tool.  The way in which it is currently implemented has the advantage of being automatically supported by all of the routers.  It's two problems are the number of packets it generates and the amount of time it takes to run.</t>

<t>This document specifies a new IP option and ICMP message type which duplicates the functionality of the existing traceroute method while generating fewer packets and completing in a shorter time.</t>
</abstract>
</front>

<seriesInfo value="1393" name="RFC" />
</reference>


<reference target2="reference.RFC.1394.xml" anchor="RFC1394">
<front>
<title abbrev="Telex Answerback Codes &amp; Domains">Relationship of Telex Answerback Codes to Internet Domains</title>
<author fullname="Paul Robinson" initials="P." surname="Robinson">
<organization>Tansin A. Darcos &amp; Company</organization>

<address>
<postal>
<street>8604 Second Avenue #104</street>
<city>Silver Spring</city>
<region>MD</region>
<code>20910</code>
<country>US</country>
</postal>

<phone>+1 202 310 1011</phone>
<email>TDARCOS@MCIMAIL.COM</email>
</address>
</author>

<date year="1993" month="January" />

<abstract>
<t>This RFC gives the list, as best known, of all common Internet domains and the conversion between specific country telex answerback codes and Internet country domain identifiers.  It also lists the telex code and international dialing code, wherever it is available. It will also list major Internet "Public" E-Mail addresses.</t>

<t>This list is designed to show the corresponding codes for Fax and voice messages, telex country codes, telex answerbacks and Internet domains.  It is an attempt to place all of the information into one list and all the connections for each country.</t>
</abstract>
</front>

<seriesInfo value="1394" name="RFC" />
</reference>


<reference target2="reference.RFC.1395.xml" anchor="RFC1395">
<front>
<title abbrev="BOOTP Extensions">BOOTP Vendor Information Extensions</title>
<author fullname="Joyce K. Reynolds" initials="J." surname="Reynolds">
<organization>University of Southern California,  Information Sciences Institute</organization>

<address>
<postal>
<street>4676 Admiralty Way</street>
<city>Marina del Rey</city>
<region>CA</region>
<code>90292</code>
<country>US</country>
</postal>

<phone>+1 310 822 1511</phone>
<email>jkrey@isi.edu</email>
</address>
</author>

<date year="1993" month="January" />
</front>

<seriesInfo value="1395" name="RFC" />
</reference>


<reference target2="reference.RFC.1396.xml" anchor="RFC1396">
<front>
<title abbrev="Poised Report">The Process for Organization of Internet Standards Working Group (POISED)</title>
<author fullname="Stephen D. Crocker" initials="S.D." surname="Crocker">
<organization>Trusted Information Systems, Inc.</organization>

<address>
<postal>
<street>3060 Washington Road</street>
<city>Glenwood</city>
<region>MD</region>
<code>21738</code>
<country>US</country>
</postal>

<phone>+1 301 854 6889</phone>
<email>crocker@TIS.COM</email>
</address>
</author>

<date year="1993" month="January" />

<abstract>
<t>This report provides a summary of the POISED Working Group (WG), starting from the events leading to the formation of the WG to the end of 1992.  Necessarily, this synopsis represents my own perception, particularly for the "prehistory" period.  Quite a few people hold strong views about both the overall sequence and specific events.  My intent here is to convey as neutral a point of view as possible.</t>
</abstract>
</front>

<seriesInfo value="1396" name="RFC" />
</reference>


<reference target2="reference.RFC.1397.xml" anchor="RFC1397">
<front>
<title abbrev="Default Routes in Old BGPs">Default Route Advertisement In BGP2 and BGP3 Version of The Border Gateway Protocol</title>
<author fullname="Dimitry Haskin" initials="D." surname="Haskin">
<organization>Bolt, Beranek &amp; Newman</organization>

<address>
<postal>
<street>150 Cambridge Park Drive</street>
<city>Cambridge</city>
<region>MA</region>
<code>02140</code>
<country>US</country>
</postal>

<phone>+1 617 873 8609</phone>
<email>dhaskin@bbn.com</email>
</address>
</author>

<date year="1993" month="January" />

<abstract>
<t>This document specifies the recommendation of the BGP Working Group on default route advertisement support in BGP2and BGP3versions of the Border Gateway Protocol.</t>

<t>This recommendation only applies to BGP2 and BGP3 versions of the Border Gateway Protocol since starting with the BGP4version a default route advertisement capability is built in the protocol.</t>
</abstract>
</front>

<seriesInfo value="1397" name="RFC" />
</reference>


<reference target2="reference.RFC.1398.xml" anchor="RFC1398">
<front>
<title abbrev="Ethernet-Like MIB">Definitions of Managed Objects for the Ethernet-Like Interface Types</title>
<author fullname="Frank Kastenholz" initials="F." surname="Kastenholz">
<organization>FTP Software, Inc.</organization>

<address>
<postal>
<street>2 High Street</street>
<city>North Andover</city>
<region>MA</region>
<code>01845-2620</code>
<country>US</country>
</postal>

<phone>+1 508 685 4000</phone>
<email>kasten@ftp.com</email>
</address>
</author>

<date year="1993" month="January" />

<abstract>
<t>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 ethernet-like objects.</t>
</abstract>
</front>

<seriesInfo value="1398" name="RFC" />
</reference>


<reference target2="reference.RFC.1399.xml" anchor="RFC1399">
<front>
<title abbrev="Summary of 1300-1399">Summary of 1300-1399</title>
<author fullname="Josh Elliott" initials="J." surname="Elliott">
<organization>University of Southern California, Information Sciences Institute</organization>

<address>
<postal>
<street>4676 Admiralty Way</street>
<city>Marina del Rey</city>
<region>CA</region>
<code>90292</code>
<country>US</country>
</postal>

<phone>+1 310 822 1511</phone>
<email>elliott@isi.edu</email>
</address>
</author>

<date year="1997" month="January" />
</front>

<seriesInfo value="1399" name="RFC" />
</reference>


<reference target2="reference.RFC.1400.xml" anchor="RFC1400">
<front>
<title abbrev="Transition of Registration Services">Transition and Modernization of the Internet Registration Service</title>
<author fullname="Scott Williamson" initials="S." surname="Williamson">
<organization>Network Solutions, Inc.</organization>

<address>
<postal>
<street>505 Huntmar Park Drive</street>
<city>Herndon</city>
<region>VA</region>
<code>22070</code>
<country>US</country>
</postal>

<phone>+1 703 742 4820</phone>
<email>scottw@internic.net</email>
</address>
</author>

<date year="1993" month="March" />
</front>

<seriesInfo value="1400" name="RFC" />
</reference>


<reference target2="reference.RFC.1401.xml" anchor="RFC1401">
<front>
<title abbrev="IAB &amp; DISA Correspondence on DNS">Correspondence between the IAB and DISA on the use of DNS</title>
<author fullname="A. Lyman Chapin" initials="A.L." surname="Chapin">
<organization>BBN Communications Corporation</organization>

<address>
<postal>
<street>150 Cambridge Park Drive</street>
<city>Cambridge</city>
<region>MA</region>
<code>02140</code>
<country>US</country>
</postal>

<phone>+1 617 873 3133</phone>
<facsimile>+1 617 873 4086</facsimile>
<email>Lyman@BBN.COM</email>
</address>
</author>

<date year="1993" month="January" />

<abstract>
<t>This memo reproduces three letters exchanged between the Internet Activities Board (IAB) and the Defense Information Systems Agency (DISA) regarding the importance of using the Domain Name System (DNS) throughout the Internet, and phasing out the use of older host name to address tables, such as "hosts.txt".</t>
</abstract>
</front>

<seriesInfo value="1401" name="RFC" />
</reference>


<reference target2="reference.RFC.1402.xml" anchor="RFC1402">
<front>
<title abbrev="Searching for Treasure">There's Gold in them thar Networks! or Searching for Treasure in all the Wrong Places</title>
<author fullname="Jerry Martin" initials="J." surname="Martin">
<organization>Ohio State University, Network Information Center, Academic Computing Services</organization>

<address>
<postal>
<street>1971 Neil Ave.</street>
<city>Columbus</city>
<region>OH</region>
<code>43210-1210</code>
<country>US</country>
</postal>

<phone>+1 614 292 4843</phone>
<email>nic@osu.edu</email>
</address>
</author>

<date year="1993" month="January" />

<abstract>
<t>A wealth of information exists on the network.  In fact, there is so much information that you could spend your entire life browsing. This paper will present some of the "gold nuggets" of information and file repositories on the network that could be useful.</t>

<t>The ultimate goal is to make the route to these sources of information invisible to you.  At present, this is not easy to do.  I will explain some of the techniques that can be used to make these nuggets easier to pick up so that we all can be richer.</t>
</abstract>
</front>

<seriesInfo value="1402" name="RFC" />
</reference>


<reference target2="reference.RFC.1403.xml" anchor="RFC1403">
<front>
<title>BGP OSPF Interaction</title>
<author fullname="Kannan Varadhan" initials="K." surname="Varadhan">
<organization>OARnet</organization>

<address>
<postal>
<street>1224 Kinnear Road</street>
<city>Columbus</city>
<region>OH</region>
<code>43212-1136</code>
<country>US</country>
</postal>

<phone>+1 614 292 4137</phone>
<email>kannan@oar.net</email>
</address>
</author>

<date year="1993" month="January" />

<abstract>
<t>This memo defines the various criteria to be used when designing an Autonomous System Border Routers (ASBR) that will run BGP with other ASBRs external to the AS and OSPF as its IGP.  This is a republication of RFC 1364 to correct some editorial problems.</t>
</abstract>
</front>

<seriesInfo value="1403" name="RFC" />
</reference>


<reference target2="reference.RFC.1404.xml" anchor="RFC1404">
<front>
<title>A Model for Common Operational Statistics</title>
<author fullname="Bernhard Stockman" initials="B." surname="Stockman">
<organization>NORDUnet/SUNET NOC, Royal Institute of Technology</organization>

<address>
<postal>
<street>Drottning Kristinas Vag 37B</street>
<city>Stockholm</city>
<region />
<code>S-100 44</code>
<country>SE</country>
</postal>

<phone>+46 8 7906519</phone>
<facsimile>+46 8 241179</facsimile>
<email>boss@sunet.se</email>
</address>
</author>

<date year="1993" month="January" />

<abstract>
<t>This memo describes a model for operational statistics in the Internet.  It gives recommendations for metrics, measurements, polling periods, storage formats and presentation formats.</t>
</abstract>
</front>

<seriesInfo value="1404" name="RFC" />
</reference>


<reference target2="reference.RFC.1405.xml" anchor="RFC1405">
<front>
<title abbrev="Mail-11 Mapping">Mapping between X.400(1984/1988) and Mail-11 (DECnet mail)</title>
<author fullname="Claudio Allocchio" initials="C." surname="Allocchio">
<organization>Italian National Institute for Nuclear Physics (INFN), Sincrotrone Trieste, Cosine S2.2</organization>

<address>
<postal>
<street>Area di Ricerca</street>
<street>Padriciano 99</street>
<city>Trieste</city>
<region />
<code>I 34012</code>
<country>IT</country>
</postal>

<phone>+39 40 3758523</phone>
<facsimile>+39 40 226338</facsimile>
<email>Claudio.Allocchio@elettra.Trieste.it</email>
</address>
</author>

<date year="1993" month="January" />

<abstract>
<t>This document describes a set of mappings which will enable inter working between systems operating the CCITT X.400 ( 1984 / 1988 ). Recommendations on Message Handling Systems, and systems running the Mail-11 (also known as DECnet mail) protocol. The specifications are valid within DECnet Phase IV addressing and routing scheme.</t>

<t>The complete scenario of X.400 / RFC822 / Mail-11 is also considered, in order to cover the possible complex cases arising in multiple gateway translations.</t>

<t>This document covers mainly the O/R address to DECnet from/to address mapping (and vice versa); other mappings are based on RFC 1327 and its eventual future updates.</t>

<t>This is a combined effort of COSINE S2.2, the RARE MSG Working Group, and the IETF X.400 Ops Working Group.</t>
</abstract>
</front>

<seriesInfo value="1405" name="RFC" />
</reference>


<reference target2="reference.RFC.1406.xml" anchor="RFC1406">
<front>
<title abbrev="DS1/E1 MIB">Definitions of Managed Objects for the DS1 and E1 Interface Types</title>
<author fullname="Fred Baker" initials="F." surname="Baker">
<organization>Advanced Computer Communications</organization>

<address>
<postal>
<street>315 Bollay Drive</street>
<city>Santa Barbara</city>
<region>CA</region>
<code>93117</code>
<country>US</country>
</postal>

<phone>+1 805 685 4455</phone>
<email>fbaker@acc.com</email>
</address>
</author>

<author fullname="James Watt" initials="J." surname="Watt">
<organization>Newbridge Networks Corporation</organization>

<address>
<postal>
<street>600 March Road</street>
<city>Kanata</city>
<region>Ontario</region>
<code>K2K 2E6</code>
<country>CA</country>
</postal>

<phone>+1 613 591 3600</phone>
<email>james@newbridge.com</email>
</address>
</author>

<date year="1993" month="January" />

<abstract>
<t>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 DS1 Interfaces -- including both T1 and E1 (a.k.a., CEPT 2 Mbit/s) links.</t>

<t>This document entirely replaces RFC 1232, which contains a fundamental error: many objects are encoded as Counters that must be encoded as INTEGERs or Gauges.  The magnitude of the change required is sufficient that virtually every object changed.  Therefore, the MIB documented in RFC 1232 should not be implemented.</t>
</abstract>
</front>

<seriesInfo value="1406" name="RFC" />
</reference>


<reference target2="reference.RFC.1407.xml" anchor="RFC1407">
<front>
<title abbrev="DS3/E3 MIB">Definitions of Managed Objects for the DS3/E3 Interface Type</title>
<author fullname="Tracy A. Cox" initials="T." surname="Cox">
<organization>Bell Communications Research</organization>

<address>
<postal>
<street>331 Newman Springs Road</street>
<street>P.O. Box 7020</street>
<city>Red Bank</city>
<region>NJ</region>
<code>07701-7020</code>
<country>US</country>
</postal>

<phone>+1 908 758 2107</phone>
<email>tacox@mail.bellcore.com</email>
</address>
</author>

<author fullname="Kaj Tesink" initials="K." surname="Tesink">
<organization>Bell Communications Research</organization>

<address>
<postal>
<street>331 Newman Springs Road</street>
<street>P.O. Box 7020</street>
<city>Red Bank</city>
<region>NJ</region>
<code>07701-7020</code>
<country>US</country>
</postal>

<phone>+1 908 758 5254</phone>
<email>kaj@cc.bellcore.com</email>
</address>
</author>

<date year="1993" month="January" />

<abstract>
<t>This memo defines an extension to the Management Information Base (MIB) for use with network management protocols in TCP/IP-based internets.  In particular, it defines objects for managing DS3 and E3 Interfaces.  This document is a companion document with Definitions of Managed Objects for the DS1 Interface Type.</t>

<t>This document entirely replaces RFC 1233, which contains a fundamental error: many objects are encoded as Counters that must be encoded as INTEGERs or Gauges.  The magnitude of the change required is sufficient that virtually every object changed.  Therefore, the MIB documented in RFC 1233 should not be implemented.</t>
</abstract>
</front>

<seriesInfo value="1407" name="RFC" />
</reference>


<reference target2="reference.RFC.1408.xml" anchor="RFC1408">
<front>
<title>Telnet Environment Option</title>
<author fullname="David A. Borman" initials="D." surname="Borman">
<organization>Cray Research, Inc.</organization>

<address>
<postal>
<street>655F Lone Oak Drive</street>
<city>Eagan</city>
<region>MN</region>
<code>55123</code>
<country>US</country>
</postal>

<phone>+1 612 452 6650</phone>
<email>dab@CRAY.COM</email>
</address>
</author>

<date year="1993" month="January" />

<abstract>
<t>This document specifies a mechanism for passing environment information between a telnet client and server.  Use of this mechanism enables a telnet user to propagate configuration information to a remote host when connecting.</t>
</abstract>
</front>

<seriesInfo value="1408" name="RFC" />
</reference>


<reference target2="reference.RFC.1409.xml" anchor="RFC1409">
<front>
<title>Telnet Authentication Option</title>
<author fullname="David A. Borman" initials="D." surname="Borman">
<organization>Cray Research, Inc.</organization>

<address>
<postal>
<street>655F Lone Oak Drive</street>
<city>Eagan</city>
<region>MN</region>
<code>55123</code>
<country>US</country>
</postal>

<phone>+1 612 452 6650</phone>
<email>dab@CRAY.COM</email>
</address>
</author>

<date year="1993" month="January" />
</front>

<seriesInfo value="1409" name="RFC" />
</reference>


<reference target2="reference.RFC.1410.xml" anchor="RFC1410">
<front>
<title abbrev="IAB Standards">IAB Official Protocol Standards</title>
<author fullname="Jon Postel" initials="J." surname="Postel">
<organization>USC/Information Sciences Institute</organization>

<address>
<postal>
<street>4676 Admiralty Way</street>
<city>Marina del Rey</city>
<region>CA</region>
<code>90292</code>
<country>US</country>
</postal>

<phone>+1 310 822 1511</phone>
<facsimile>+1 310 823 6714</facsimile>
<email>Postel@ISI.EDU</email>
</address>
</author>

<date year="1993" month="March" />
</front>

<seriesInfo value="1410" name="RFC" />
</reference>


<reference target2="reference.RFC.1411.xml" anchor="RFC1411">
<front>
<title abbrev="Kerberos Version 4 for Telnet">Telnet Authentication: Kerberos Version 4</title>
<author fullname="David A. Borman" initials="D.A." surname="Borman">
<organization>Cray Research, Inc.</organization>

<address>
<postal>
<street>655F Lone Oak Drive</street>
<city>Eagan</city>
<region>MN</region>
<code>55123</code>
<country>US</country>
</postal>

<phone>+1 612 452 6650</phone>
<email>dab@CRAY.COM</email>
</address>
</author>

<date year="1993" month="January" />
</front>

<seriesInfo value="1411" name="RFC" />
</reference>


<reference target2="reference.RFC.1412.xml" anchor="RFC1412">
<front>
<title abbrev="SPX for Telnet">Telnet Authentication: SPX</title>
<author fullname="Kannan Alagappan" initials="K." surname="Alagappan">
<organization>Digital Equipment Corporation (DEC)</organization>

<address>
<postal>
<street>550 King Street</street>
<street>LKG1-2/A19</street>
<city>Littleton</city>
<region>MA</region>
<code>01460</code>
<country>US</country>
</postal>

<email>kannan@sejour.lkg.dec.com</email>
</address>
</author>

<date year="1993" month="January" />
</front>

<seriesInfo value="1412" name="RFC" />
</reference>


<reference target2="reference.RFC.1413.xml" anchor="RFC1413">
<front>
<title>Identification Protocol</title>
<author fullname="Michael C. St. Johns" initials="M.C." surname="St. Johns">
<organization>DARPA/CSTO</organization>

<address>
<postal>
<street>3701 N. Fairfax Dr</street>
<city>Arlington</city>
<region>VA</region>
<code>22203</code>
<country>US</country>
</postal>

<phone>+1 703 696 2271</phone>
<email>stjohns@DARPA.MIL</email>
</address>
</author>

<date year="1993" month="February" />
</front>

<seriesInfo value="1413" name="RFC" />
</reference>


<reference target2="reference.RFC.1414.xml" anchor="RFC1414">
<front>
<title>Identification MIB</title>
<author fullname="Michael C. St. Johns" initials="M." surname="St. Johns">
<organization>U.S. Department of Defense</organization>

<address>
<postal>
<street>3701 N. Fairfax Dr</street>
<street>DARPA/CSTO</street>
<city>Arlington</city>
<region>VA</region>
<code>22203</code>
<country>US</country>
</postal>

<phone>+1 703 696 2271</phone>
<email>stjohns@DARPA.MIL</email>
</address>
</author>

<author fullname="Marshall T. Rose" initials="M." surname="Rose">
<organization>Dover Beach Consulting, Inc.</organization>

<address>
<postal>
<street>420 Whisman Court</street>
<city>Mountain View</city>
<region>CA</region>
<code>94043-2186</code>
<country>US</country>
</postal>

<phone>+1 415 968 1052</phone>
<email>mrose@dbc.mtview.ca.us</email>
</address>
</author>

<date year="1993" month="February" />

<abstract>
<t>This memo defines a MIB for use with identifying the users associated with TCP connections.  It provides functionality approximately equivalent to that provided by the protocol defined in RFC 1413.  This document is a product of the TCP Client Identity Protocol  Working Group of the Internet Engineering Task Force (IETF).</t>
</abstract>
</front>

<seriesInfo value="1414" name="RFC" />
</reference>


<reference target2="reference.RFC.1415.xml" anchor="RFC1415">
<front>
<title>FTP-FTAM Gateway Specification</title>
<author fullname="Joshua L. Mindel" initials="J." surname="Mindel">
<organization>Open Networks, Inc.</organization>

<address>
<postal>
<street>11490 Commerce Park Dr.</street>
<street>Suite 205</street>
<city>Reston</city>
<region>VA</region>
<code>22091</code>
<country>US</country>
</postal>

<phone>+1 703 648 0013</phone>
<email>mindel@netwrx1.nw1.com</email>
</address>
</author>

<author fullname="Robert L. Slaski" initials="R." surname="Slaski">
<organization>Open Networks, Inc.</organization>

<address>
<postal>
<street>11490 Commerce Park Dr.</street>
<street>Suite 205</street>
<city>Reston</city>
<region>VA</region>
<code>22091</code>
<country>US</country>
</postal>

<phone>+1 703 648 0013</phone>
<email>slaski@netwrx1.nw1.com</email>
</address>
</author>

<date year="1993" month="January" />

<abstract>
<t>This memo describes a dual protocol stack application layer gateway that performs protocol translation, in an interactive environment, between the FTP and FTAM file transfer protocols.</t>

<t>Two key assumptions are made: 1) POSIX file naming conventions and hierarchical organization, rather than proprietary conventions are in use; and 2) X.500 Directory Services are available.</t>
</abstract>
</front>

<seriesInfo value="1415" name="RFC" />
</reference>


<reference target2="reference.RFC.1416.xml" anchor="RFC1416">
<front>
<title>Telnet Authentication Option</title>
<author fullname="David A. Borman" initials="D.A." surname="Borman">
<organization>Cray Research, Inc.</organization>

<address>
<postal>
<street>655F Lone Oak Drive</street>
<city>Eagan</city>
<region>MN</region>
<code>55123</code>
<country>US</country>
</postal>

<phone>+1 612 452 6650</phone>
<email>dab@CRAY.COM</email>
</address>
</author>

<date year="1993" month="February" />
</front>

<seriesInfo value="1416" name="RFC" />
</reference>


<reference target2="reference.RFC.1417.xml" anchor="RFC1417">
<front>
<title abbrev="NADF Standing Documents">NADF Standing Documents: A Brief Overview</title>
<author fullname="Theodore H. Myer" initials="T." surname="Myer">
<organization>North American Directory Forum</organization>

<address>
<postal>
<street>3055 Q Street NW</street>
<city>Washington</city>
<region>DC</region>
<code>20007</code>
<country>US</country>
</postal>

<phone>+1 202 342 2727</phone>
<email>0004454742@mcimail.com</email>
</address>
</author>

<date year="1993" month="February" />
</front>

<seriesInfo value="1417" name="RFC" />
</reference>


<reference target2="reference.RFC.1418.xml" anchor="RFC1418">
<front>
<title>SNMP over OSI</title>
<author fullname="Marshall T. Rose" initials="M." surname="Rose">
<organization>Dover Beach Consulting, Inc.</organization>

<address>
<postal>
<street>420 Whisman Court</street>
<city>Mountain View</city>
<region>CA</region>
<code>94043-2112</code>
<country>US</country>
</postal>

<phone>+1 415 968 1052</phone>
<email>mrose@dbc.mtview.ca.us</email>
</address>
</author>

<date year="1993" month="March" />
</front>

<seriesInfo value="1418" name="RFC" />
</reference>


<reference target2="reference.RFC.1419.xml" anchor="RFC1419">
<front>
<title>SNMP over AppleTalk</title>
<author fullname="Greg Minshall" initials="G." surname="Minshall">
<organization>Novell, Inc.</organization>

<address>
<postal>
<street>1340 Treat Blvd</street>
<street>ste. 500</street>
<city>Walnut Creek</city>
<region>CA</region>
<code>94596</code>
<country>US</country>
</postal>

<phone>+1 510 947 0998</phone>
<facsimile>+1 510 947 1238</facsimile>
<email>minshall@wc.novell.com</email>
</address>
</author>

<author fullname="Mike Ritter" initials="M." surname="Ritter">
<organization>Apple Computer, Inc.</organization>

<address>
<postal>
<street>10500 North De Anza Boulevard</street>
<street>MS: 35-K</street>
<city>Cupertino</city>
<region>CA</region>
<code>95014</code>
<country>US</country>
</postal>

<phone>+1 408 862 8088</phone>
<facsimile>+1 408 862 1159</facsimile>
<email>MWRITTER@applelink.apple.com</email>
</address>
</author>

<date year="1993" month="March" />
</front>

<seriesInfo value="1419" name="RFC" />
</reference>


<reference target2="reference.RFC.1420.xml" anchor="RFC1420">
<front>
<title>SNMP over IPX</title>
<author fullname="Steve Bostock" initials="S." surname="Bostock">
<organization>Novell, Inc.</organization>

<address>
<postal>
<street>2180 Fortune Drive</street>
<city>San Jose</city>
<region>CA</region>
<code>95131</code>
<country>US</country>
</postal>

<phone>+1 408 473 8203</phone>
<facsimile>+1 408 435 1706</facsimile>
<email>steveb@novell.com</email>
</address>
</author>

<date year="1993" month="March" />

<abstract>
<t>This document defines a convention for encapsulating Simple Network Management Protocol (SNMP)packets over the transport mechanism provided via the Internetwork Packet Exchange (IPX) protocol.</t>
</abstract>
</front>

<seriesInfo value="1420" name="RFC" />
</reference>


<reference target2="reference.RFC.1421.xml" anchor="RFC1421">
<front>
<title abbrev="Privacy Enhancement for Electronic Mail">Privacy Enhancement for Internet Electronic Mail: Part I: Message Encryption and Authentication Procedures</title>
<author fullname="John Linn" initials="J." surname="Linn">
<organization>Internet Architecture Board (IAB)
			Internet Research Task Force (IRTF),
			MIT's Programming Systems Research Group (PSRG),
			Internet Engineering Task Force (IETF),
			Privacy Enhanced Mail Work Group (PEM WG)</organization>

<address>
<email>104-8456@mcimail.com</email>
</address>
</author>

<date year="1993" month="February" />
</front>

<seriesInfo value="1421" name="RFC" />
</reference>


<reference target2="reference.RFC.1422.xml" anchor="RFC1422">
<front>
<title abbrev="Certificate-Based Key Management">Privacy Enhancement for Internet Electronic Mail: Part II: Certificate-Based Key Management</title>
<author fullname="Steve Kent" initials="S." surname="Kent">
<organization>BBN Communications</organization>

<address>
<postal>
<street>50 Moulton Street</street>
<city>Cambridge</city>
<region>MA</region>
<code>02138</code>
<country>US</country>
</postal>

<phone>+1 617 873 3988</phone>
<email>kent@BBN.COM</email>
</address>
</author>

<date year="1993" month="February" />
</front>

<seriesInfo value="1422" name="RFC" />
</reference>


<reference target2="reference.RFC.1423.xml" anchor="RFC1423">
<front>
<title abbrev="PEM: Algorithms, Modes and Identifiers">Privacy Enhancement for Internet Electronic Mail: Part III: Algorithms, Modes, and Identifiers</title>
<author fullname="David Balenson" initials="D." surname="Balenson">
<organization>Trusted Information Systems</organization>

<address>
<postal>
<street>3060 Washington Road</street>
<city>Glenwood</city>
<region>MD</region>
<code>21738</code>
<country>US</country>
</postal>

<phone>+1 301 854 6889</phone>
<email>balenson@tis.com</email>
</address>
</author>

<date year="1993" month="February" />

<abstract>
<t>This document provides definitions, formats, references, and citations for cryptographic algorithms, usage modes, and associated identifiers and parameters used in support of Privacy Enhanced Mail (PEM) in the Internet community.  It is intended to become one member of the set of related PEM RFCs.  This document is organized into four primary sections, dealing with message encryption algorithms, message integrity check algorithms, symmetric key management algorithms, and asymmetric key management algorithms (including both asymmetric encryption and asymmetric signature algorithms).</t>

<t>Some parts of this material are cited by other documents and it is anticipated that some of the material herein may be changed, added, or replaced without affecting the citing documents.  Therefore, algorithm-specific material has been placed into this separate document.</t>

<t>Use of other algorithms and/or modes will require case-by-case study to determine applicability and constraints.  The use of additional algorithms may be documented first in Prototype or Experimental RFCs. As experience is gained, these protocols may be considered for incorporation into the standard.  Additional algorithms and modes approved for use in PEM in this context will be specified in successors to this document.</t>
</abstract>
</front>

<seriesInfo value="1423" name="RFC" />
</reference>


<reference target2="reference.RFC.1424.xml" anchor="RFC1424">
<front>
<title abbrev="Key Certification and Related Services">Privacy Enhancement for Internet Electronic Mail: Part IV: Key Certification and Related Services</title>
<author fullname="Burton S. Kaliski, Jr." initials="B." surname="Kaliski">
<organization>RSA Laboratories (a division of RSA Data Security, Inc.)</organization>

<address>
<postal>
<street>10 Twin Dolphin Drive</street>
<city>Redwood City</city>
<region>CA</region>
<code>94065</code>
<country>US</country>
</postal>

<phone>+1 415 595 7703</phone>
<facsimile>+1 415 595 4126</facsimile>
<email>burt@rsa.com</email>
</address>
</author>

<date year="1993" month="February" />
</front>

<seriesInfo value="1424" name="RFC" />
</reference>


<reference target2="reference.RFC.1425.xml" anchor="RFC1425">
<front>
<title>SMTP Service Extensions</title>
<author fullname="John Klensin" initials="J." surname="Klensin">
<organization>United Nations University</organization>

<address>
<postal>
<street>Charles Street Station</street>
<street>PO Box 500</street>
<city>Boston</city>
<region>MA</region>
<code>02114-0500</code>
<country>US</country>
</postal>

<phone>+1 617 227 8747</phone>
<facsimile>+1 617 491 6266</facsimile>
<email>klensin@infoods.unu.edu</email>
</address>
</author>

<author fullname="Ned Freed" initials="N." surname="Freed">
<organization>Innosoft International, Inc.</organization>

<address>
<postal>
<street>250 West First Street</street>
<street>Suite 240</street>
<city>Claremont</city>
<region>CA</region>
<code>91711</code>
<country>US</country>
</postal>

<phone>+1 909 624 7907</phone>
<facsimile>+1 909 621 5319</facsimile>
<email>ned@innosoft.com</email>
</address>
</author>

<author fullname="Marshall T. Rose" initials="M.T." surname="Rose">
<organization>Dover Beach Consulting, Inc.</organization>

<address>
<postal>
<street>420 Whisman Court</street>
<city>Mountain View</city>
<region>CA</region>
<code>94043-2186</code>
<country>US</country>
</postal>

<phone>+1 415 968 1052</phone>
<facsimile>+1 415 968 2510</facsimile>
<email>mrose@dbc.mtview.ca.us</email>
</address>
</author>

<author fullname="Einar A. Stefferud" initials="E." surname="Stefferud">
<organization>Network Management Associates, Inc.</organization>

<address>
<postal>
<street>17301 Drey Lane</street>
<city>Huntington Beach</city>
<region>CA</region>
<code>92647-5615</code>
<country>US</country>
</postal>

<phone>+1 714 842 3711</phone>
<facsimile>+1 714 848 2091</facsimile>
<email>stef@nma.com</email>
</address>
</author>

<author fullname="David H. Crocker" initials="D.H." surname="Crocker">
<organization>The Branch Office</organization>

<address>
<postal>
<street>675 Spruce Drive</street>
<city>Sunnyvale</city>
<region>CA</region>
<code>94086</code>
<country>US</country>
</postal>

<email>dcrocker@mordor.stanford.edu</email>
</address>
</author>

<date year="1993" month="February" />

<abstract>
<t>This memo defines a framework for extending the SMTP service by defining a means whereby a server SMTP can inform a client SMTP as to the service extensions it supports. Standard extensions to the SMTP service are registered with the Internet Assigned Numbers Authority (IANA).  This framework does not require modification of existing SMTP clients or servers unless the features of the service extensions are to be requested or provided.</t>
</abstract>
</front>

<seriesInfo value="1425" name="RFC" />
</reference>


<reference target2="reference.RFC.1426.xml" anchor="RFC1426">
<front>
<title abbrev="SMTP 8bit-MIMEtransport">SMTP Service Extension for 8bit-MIMEtransport</title>
<author fullname="John Klensin" initials="J." surname="Klensin">
<organization>United Nations University</organization>

<address>
<postal>
<street>Charles Street Station</street>
<street>PO Box 500</street>
<city>Boston</city>
<region>MA</region>
<code>02114-0500</code>
<country>US</country>
</postal>

<phone>+1 617 227 8747</phone>
<facsimile>+1 617 491 6266</facsimile>
<email>klensin@infoods.unu.edu</email>
</address>
</author>

<author fullname="Ned Freed" initials="N." surname="Freed">
<organization>Innosoft International, Inc.</organization>

<address>
<postal>
<street>250 West First Street</street>
<street>Suite 240</street>
<city>Claremont</city>
<region>CA</region>
<code>91711</code>
<country>US</country>
</postal>

<phone>+1 909 624 7907</phone>
<facsimile>+1 909 621 5319</facsimile>
<email>ned@innosoft.com</email>
</address>
</author>

<author fullname="Marshall T. Rose" initials="M." surname="Rose">
<organization>Dover Beach Consulting, Inc.</organization>

<address>
<postal>
<street>420 Whisman Court</street>
<city>Mountain View</city>
<region>CA</region>
<code>94043-2186</code>
<country>US</country>
</postal>

<phone>+1 415 968 1052</phone>
<facsimile>+1 415 968 2510</facsimile>
<email>mrose@dbc.mtview.ca.us</email>
</address>
</author>

<author fullname="Einar A. Stefferud" initials="E." surname="Stefferud">
<organization>Network Management Associates, Inc.</organization>

<address>
<postal>
<street>17301 Drey Lane</street>
<city>Huntington Beach</city>
<region>CA</region>
<code>92647-5615</code>
<country>US</country>
</postal>

<phone>+1 714 842 3711</phone>
<facsimile>+1 714 848 2091</facsimile>
<email>stef@nma.com</email>
</address>
</author>

<author fullname="David H. Crocker" initials="D.H." surname="Crocker">
<organization>The Branch Office</organization>

<address>
<postal>
<street>675 Spruce Drive</street>
<city>Sunnyvale</city>
<region>CA</region>
<code>94086</code>
<country>US</country>
</postal>

<email>dcrocker@mordor.stanford.edu</email>
</address>
</author>

<date year="1993" month="February" />

<abstract>
<t>This memo defines an extension to the SMTP service whereby an SMTP content body containing octets outside of the US ASCII octet range (hex 00-7F) may be relayed using SMTP.</t>
</abstract>
</front>

<seriesInfo value="1426" name="RFC" />
</reference>


<reference target2="reference.RFC.1427.xml" anchor="RFC1427">
<front>
<title abbrev="SMTP Size Declaration">SMTP Service Extension for Message Size Declaration</title>
<author fullname="John Klensin" initials="J." surname="Klensin">
<organization>United Nations University</organization>

<address>
<postal>
<street>PO Box 500</street>
<street>Charles Street Station</street>
<city>Boston</city>
<region>MA</region>
<code>02114-0500</code>
<country>US</country>
</postal>

<phone>+1 617 227 8747</phone>
<facsimile>+1 617 491 6266</facsimile>
<email>klensin@infoods.unu.edu</email>
</address>
</author>

<author fullname="Ned Freed" initials="N." surname="Freed">
<organization>Innosoft International, Inc.</organization>

<address>
<postal>
<street>250 West First Street</street>
<street>Suite 240</street>
<city>Claremont</city>
<region>CA</region>
<code>91711</code>
<country>US</country>
</postal>

<phone>+1 909 624 7907</phone>
<facsimile>+1 909 621 5319</facsimile>
<email>ned@innosoft.com</email>
</address>
</author>

<author fullname="Keith Moore" initials="K." surname="Moore">
<organization>University of Tennessee, Computer Science Dept.</organization>

<address>
<postal>
<street>107 Ayres Hall</street>
<city>Knoxville</city>
<region>TN</region>
<code>37996-1301</code>
<country>US</country>
</postal>

<email>moore@cs.utk.edu</email>
</address>
</author>

<date year="1993" month="February" />

<abstract>
<t>This memo defines an extension to the SMTP service whereby an SMTP client and server may interact to give the server an opportunity to decline to accept a message (perhaps temporarily) based on the client's estimate of the message size.</t>
</abstract>
</front>

<seriesInfo value="1427" name="RFC" />
</reference>


<reference target2="reference.RFC.1428.xml" anchor="RFC1428">
<front>
<title abbrev="Transition to 8bit-SMTP/MIME">Transition of Internet Mail from Just-Send-8 to 8bit-SMTP/MIME</title>
<author fullname="Greg Vaudreuil" initials="G." surname="Vaudreuil">
<organization>Corporation for National Research Initiatives</organization>

<address>
<postal>
<street>1895 Preston White Drive</street>
<street>Suite 100</street>
<city>Reston</city>
<region>VA</region>
<code>22091</code>
<country>US</country>
</postal>

<phone>+1 703 620 8990</phone>
<email>GVaudre@CNRI.Reston.VA.US</email>
</address>
</author>

<date year="1993" month="February" />

<abstract>
<t>Protocols for extending SMTP to pass 8bit characters have been defined,. These protocols require that messages transported by the extended SMTP are to be encoded in MIME,.  Before work began on these protocols, several SMTP implementations adopted ad-hoc mechanisms for sending 8bit data. It is desirable for the extended SMTP environment and these ad hoc mechanisms interoperate.  This document outlines the problems in this environment and an approach to minimizing the cost of transition from current usage of non-MIME 8bit messages to MIME.</t>
</abstract>
</front>

<seriesInfo value="1428" name="RFC" />
</reference>


<reference target2="reference.RFC.1429.xml" anchor="RFC1429">
<front>
<title>Listserv Distribute Protocol</title>
<author fullname="Eric Thomas" initials="E." surname="Thomas">
<organization>Swedish University Network</organization>

<address>
<postal>
<street>vaeg 37B</street>
<city>Stockholm</city>
<region />
<code>100 44</code>
<country>SE</country>
</postal>

<email>ERIC@SEARN.SUNET.SE</email>
</address>
</author>

<date year="1993" month="February" />

<abstract>
<t>This memo specifies a subset of the distribution protocol used by the BITNET LISTSERV to deliver mail messages to large amounts of recipients.  This protocol, known as DISTRIBUTE, optimizes the distribution by sending a single copy of the message over heavily loaded links, insofar as topological information is available to guide such decisions, and reduces the average turnaround time for large mailing lists to 5-15 minutes on the average. This memo describes a simple interface allowing non-BITNET mailing list exploders (or other bulk-delivery scripts) to take advantage of this service by letting the BITNET distribution network take care of the delivery.</t>
</abstract>
</front>

<seriesInfo value="1429" name="RFC" />
</reference>


<reference target2="reference.RFC.1430.xml" anchor="RFC1430">
<front>
<title abbrev="X.500 Strategy">A Strategic Plan for Deploying an Internet X.500 Directory Service</title>
<author fullname="Steve Hardcastle-Kille" initials="S." surname="Hardcastle-Kille">
<organization>ISODE Consortium</organization>

<address>
<postal>
<street>POB 505</street>
<city>London</city>
<region>England</region>
<code>SW11 1DX</code>
<country>UK</country>
</postal>

<phone>+44 71 2234062</phone>
<email>S.Kille@isode.com</email>
</address>
</author>

<author fullname="Erik Huizer" initials="E." surname="Huizer">
<organization>SURFnet bv</organization>

<address>
<postal>
<street>PO box 19035</street>
<city>Utrecht</city>
<region />
<code>3501 DA</code>
<country>NL</country>
</postal>

<phone>+31 30 310290</phone>
<email>Erik.Huizer@SURFnet.nl</email>
</address>
</author>

<author fullname="Vinton Cerf" initials="V." surname="Cerf">
<organization>Corporation for National Research Initiatives</organization>

<address>
<postal>
<street>1895 Preston White Drive</street>
<street>Suite 100</street>
<city>Reston</city>
<region>VA</region>
<code>22091</code>
<country>US</country>
</postal>

<phone>+1 703 620 8990</phone>
<email>vcerf@cnri.reston.va.us</email>
</address>
</author>

<author fullname="Russ Hobby" initials="R." surname="Hobby">
<organization>University of California, Davis, Computing Services</organization>

<address>
<postal>
<street>Surge II Room 1400</street>
<city>Davis</city>
<region>CA</region>
<code>95616</code>
<country>US</country>
</postal>

<phone>+1 916 752 0236</phone>
<email>rdhobby@ucdavis.edu</email>
</address>
</author>

<author fullname="Steve Kent" initials="S." surname="Kent">
<organization>Bolt, Beranek, and Newman</organization>

<address>
<postal>
<street>50 Moulton Street</street>
<city>Cambridge</city>
<region>MA</region>
<code>02138</code>
<country>US</country>
</postal>

<phone>+1 617 873 3988</phone>
<email>skent@bbn.com</email>
</address>
</author>

<date year="1993" month="February" />

<abstract>
<t>There are a number of reasons why a new Internet Directory Service is required.  This document describes an overall strategy for deploying a Directory Service on the Internet, based on the OSI X.500 Directory Service.  It then describes in more detail the initial steps which need to be taken in order to achieve these goals, and how work already undertaken by Internet Engineering Task Force Working Groups (IETF WGs) is working towards these goals.</t>
</abstract>
</front>

<seriesInfo value="1430" name="RFC" />
</reference>


<reference target2="reference.RFC.1431.xml" anchor="RFC1431">
<front>
<title>DUA Metrics (OSI-DS 33 (v2))</title>
<author fullname="Paul Barker" initials="P." surname="Barker">
<organization>University College London, Department of Computer Science</organization>

<address>
<postal>
<street>Gower Street</street>
<city>London</city>
<region>England</region>
<code>WC1E 6BT</code>
<country>UK</country>
</postal>

<phone>+44 71 3807366</phone>
<facsimile>+44 71 3871397</facsimile>
<email>P.Barker@cs.ucl.ac.uk</email>
</address>
</author>

<date year="1993" month="February" />

<abstract>
<t>This RFC is being distributed to members of the Internet community in order to solicit their reactions to the proposals contained in it. While the issues discussed may not be directly relevant to the research problems of the Internet, they may be interesting to a number of researchers and implementers.</t>

<t>This document defines a set of criteria by which a DUA implementation, or more precisely a Directory user interface, may be judged.  Particular issues covered include terminal requirements; style of interface; target user; default object classes and attribute types; use of DAP; error handling.  The focus of the note is on "white pages" DUAs: this is a reflection of the current information base.  Nevertheless much of the document will be applicable to DUAs developed for other types of Directory usage.</t>

<t>Please send comments to the author or to the discussion group osi-ds@CS.UCL.AC.UK.</t>
</abstract>
</front>

<seriesInfo value="1431" name="RFC" />
</reference>


<reference target2="reference.RFC.1432.xml" anchor="RFC1432">
<front>
<title>Recent Internet Books</title>
<author fullname="John S. Quarterman" initials="J." surname="Quarterman">
<organization>Matrix Information and Directory Services, Inc. (MIDS)</organization>

<address>
<postal>
<street>1106 Clayton Lane</street>
<street>Suite 500W</street>
<city>Austin</city>
<region>TX</region>
<code>78723</code>
<country>US</country>
</postal>

<phone>+1 512 451 7602</phone>
<facsimile>+1 512 450 1436</facsimile>
<email>mids@tic.com</email>
</address>
</author>

<date year="1993" month="March" />

<abstract>
<t>This article originally appeared in Volume 2 Number 12, (December 1992) of Matrix News, the monthly newsletter of Matrix Information and Directory Services, Inc. (MIDS).</t>
</abstract>
</front>

<seriesInfo value="1432" name="RFC" />
</reference>


<reference target2="reference.RFC.1433.xml" anchor="RFC1433">
<front>
<title>Directed ARP</title>
<author fullname="John Garrett" initials="J." surname="Garrett">
<organization>AT&amp;T Bell Laboratories</organization>

<address>
<postal>
<street>184 Liberty Corner Road</street>
<city>Warren</city>
<region>NJ</region>
<code>07060-0906</code>
<country>US</country>
</postal>

<phone>+1 908 580 4719</phone>
<email>jwg@garage.att.com</email>
</address>
</author>

<author fullname="John Dotts Hagan" initials="J." surname="Hagan">
<organization>University of Pennsylvania</organization>

<address>
<postal>
<street>3401 Walnut Street</street>
<street>Suite 221A</street>
<city>Philadelphia</city>
<region>PA</region>
<code>19104-6228</code>
<country>US</country>
</postal>

<phone>+1 215 898 9192</phone>
<email>Hagan@UPENN.EDU</email>
</address>
</author>

<author fullname="Jeffrey A. Wong" initials="J." surname="Wong">
<organization>AT&amp;T Bell Laboratories</organization>

<address>
<postal>
<street>184 Liberty Corner Road</street>
<city>Warren</city>
<region>NJ</region>
<code>07060-0906</code>
<country>US</country>
</postal>

<phone>+1 908 580 5361</phone>
<email>jwong@garage.att.com</email>
</address>
</author>

<date year="1993" month="March" />

<abstract>
<t>A router with an interface to two IP networks via the same link level interface could observe that the two IP networks share the same link level network, and could advertise that information to hosts (via ICMP Redirects) and routers (via dynamic routing protocols). However, a host or router on only one of the IP networks could not use that information to communicate directly with hosts and routers on the other IP network unless it could resolve IP addresses on the "foreign" IP network to their corresponding link level addresses. Directed ARP is a dynamic address resolution procedure that enables hosts and routers to resolve advertised potential next-hop IP addresses on foreign IP networks to their associated link level addresses.</t>
</abstract>
</front>

<seriesInfo value="1433" name="RFC" />
</reference>


<reference target2="reference.RFC.1434.xml" anchor="RFC1434">
<front>
<title abbrev="DLS: Switch-to-Switch Protocol">Data Link Switching: Switch-to-Switch Protocol</title>
<author fullname="Roy C. Dixon" initials="R." surname="Dixon">
<organization>IBM Networking Systems</organization>

<address>
<postal>
<street>P.O. Box 12195, Department B57</street>
<street>Building 060</street>
<city>Research Triangle Park</city>
<region>NC</region>
<code>27709</code>
<country>US</country>
</postal>

<phone>+1 919 543 3380</phone>
<email>rcdixon@ralvmg.vnet.ibm.com</email>
</address>
</author>

<author fullname="David M. Kushi" initials="D." surname="Kushi">
<organization>IBM Research Division, T. J. Watson Research Center</organization>

<address>
<postal>
<street>30 Saw Mill River Road</street>
<street>Room H0-C07</street>
<city>Hawthorne</city>
<region>NY</region>
<code>10532</code>
<country>US</country>
</postal>

<phone>+1 914 784 7815</phone>
<email>kushi@watson.ibm.com</email>
</address>
</author>

<date year="1993" month="March" />

<abstract>
<t>This RFC describes IBM's support of Data Link Switching over TCP/IP. The RFC is being distributed to members of the Internet community in order to solicit their reactions to the proposals contained in it. While the issues discussed may not be directly relevant to the research problems of the Internet, they may be interesting to a number of researchers and implementors.</t>

<t>Any questions or comments relative to the contents of this RFC should be sent to the following Internet address: dlsw@ralvma.vnet.ibm.com.</t>
</abstract>
</front>

<seriesInfo value="1434" name="RFC" />
</reference>


<reference target2="reference.RFC.1435.xml" anchor="RFC1435">
<front>
<title>IESG Advice from Experience with Path MTU Discovery</title>
<author fullname="Stev Knowles" initials="S." surname="Knowles">
<organization>ftp Software</organization>

<address>
<postal>
<street>2 High Street</street>
<city>North Andover</city>
<region>MA</region>
<code>01845</code>
<country>US</country>
</postal>

<email>stev@ftp.com</email>
</address>
</author>

<date year="1993" month="March" />

<abstract>
<t>In the course of reviewing the MTU Discovery protocol for possible elevation to Draft Standard, a specific operational problem was uncovered.  The problem results from the optional suppression of ICMP messages implemented in some routers.  This memo outlines a modification to this practice to allow the correct functioning of MTU Discovery.</t>
</abstract>
</front>

<seriesInfo value="1435" name="RFC" />
</reference>


<reference target2="reference.RFC.1436.xml" anchor="RFC1436">
<front>
<title abbrev="Gopher">The Internet Gopher Protocol (a distributed document search and retrieval protocol)</title>
<author fullname="Farhad Anklesaria" initials="F." surname="Anklesaria">
<organization>University of Minnesota, Computer and Information Services</organization>

<address>
<postal>
<street>100 Union Street SE</street>
<street>Room 152 Shepherd Labs</street>
<city>Minneapolis</city>
<region>MN</region>
<code>55455</code>
<country>US</country>
</postal>

<phone>+1 612 625 1300</phone>
<email>fxa@boombox.micro.umn.edu</email>
</address>
</author>

<author fullname="Mark McCahill" initials="M." surname="McCahill">
<organization>University of Minnesota, Computer and Information Services</organization>

<address>
<postal>
<street>100 Union Street SE</street>
<street>Room 152 Shepherd Labs</street>
<city>Minneapolis</city>
<region>MN</region>
<code>55455</code>
<country>US</country>
</postal>

<phone>+1 612 625 1300</phone>
<email>mpm@boombox.micro.umn.edu</email>
</address>
</author>

<author fullname="Paul Lindner" initials="P." surname="Lindner">
<organization>University of Minnesota, Computer and Information Services</organization>

<address>
<postal>
<street>100 Union Street SE</street>
<street>Room 152 Shepherd Labs</street>
<city>Minneapolis</city>
<region>MN</region>
<code>55455</code>
<country>US</country>
</postal>

<phone>+1 612 625 1300</phone>
<email>lindner@boombox.micro.umn.edu</email>
</address>
</author>

<author fullname="David Johnson" initials="D." surname="Johnson">
<organization>University of Minnesota, Computer and Information Services</organization>

<address>
<postal>
<street>100 Union Street SE</street>
<street>Room 152 Shepherd Labs</street>
<city>Minneapolis</city>
<region>MN</region>
<code>55455</code>
<country>US</country>
</postal>

<phone>+1 612 625 1300</phone>
<email>dmj@boombox.micro.umn.edu</email>
</address>
</author>

<author fullname="Daniel Torrey" initials="D." surname="Torrey">
<organization>University of Minnesota, Computer and Information Services</organization>

<address>
<postal>
<street>100 Union Street SE</street>
<street>Room 152 Shepherd Labs</street>
<city>Minneapolis</city>
<region>MN</region>
<code>55455</code>
<country>US</country>
</postal>

<phone>+1 612 625 1300</phone>
<email>daniel@boombox.micro.umn.edu</email>
</address>
</author>

<author fullname="Bob Alberti" initials="B." surname="Alberti">
<organization>University of Minnesota, Computer and Information Services</organization>

<address>
<postal>
<street>100 Union Street SE</street>
<street>Room 152 Shepherd Labs</street>
<city>Minneapolis</city>
<region>MN</region>
<code>55455</code>
<country>US</country>
</postal>

<phone>+1 612 625 1300</phone>
<email>alberti@boombox.micro.umn.edu</email>
</address>
</author>

<date year="1993" month="March" />

<abstract>
<t>The Internet Gopher protocol is designed for distributed document search and retrieval.  This document describes the protocol, lists some of the implementations currently available, and has an overview of how to implement new client and server applications.  This document is adapted from the basic Internet Gopher protocol document first issued by the Microcomputer Center at the University of Minnesota in 1991.</t>
</abstract>
</front>

<seriesInfo value="1436" name="RFC" />
</reference>


<reference target2="reference.RFC.1437.xml" anchor="RFC1437">
<front>
<title abbrev="MIME Content-Types for a New Medium">The Extension of MIME Content-Types to a New Medium</title>
<author fullname="Nathaniel Borenstein" initials="N." surname="Borenstein">
<organization>Bellcore</organization>

<address>
<postal>
<street>445 South Street</street>
<street>Bellcore Room MRE 2D-296</street>
<city>Morristown</city>
<region>NJ</region>
<code>07962-1910</code>
<country>US</country>
</postal>

<phone>+1 201 829 4270</phone>
<email>nsb@bellcore.com</email>
</address>
</author>

<author fullname="Mark Linimon" initials="M." surname="Linimon">
<organization>Lonesome Dove Computing Services</organization>

<address>
<postal>
<street>P.O. Box 20291</street>
<city>Roanoke</city>
<region>VA</region>
<code>24018</code>
<country>US</country>
</postal>

<phone>+1 703 776 1004</phone>
<email>linimon@LONESOME.COM</email>
</address>
</author>

<date year="1993" day="1" month="April" />

<abstract>
<t>A previous document, RFC 1341, defines a format and general framework for the representation of a wide variety of data types in Internet mail.  This document defines one particular type of MIME data, the matter-transport/sentient-life-form type.  The matter- transport/sentient-life-form MIME type is intended to facilitate the wider interoperation of electronic mail messages that include entire sentient life forms, such as human beings.</t>

<t>Other informally proposed subtypes, such as "non-sentient-life-form", "non-sentient-non-life-form", and the orthogonally necessary but nevertheless puzzling "sentient-non-life-form", are not described in this memo.</t>
</abstract>
</front>

<seriesInfo value="1437" name="RFC" />
</reference>


<reference target2="reference.RFC.1438.xml" anchor="RFC1438">
<front>
<title abbrev="IETF SOBs">Internet Engineering Task Force Statements Of Boredom (SOBs)</title>
<author fullname="A. Lyman Chapin" initials="A.L." surname="Chapin">
<organization>Bolt, Beranek &amp; Newman</organization>

<address>
<postal>
<street>150 Cambridge Park Drive</street>
<street>Mail Stop 20/5b</street>
<city>Cambridge</city>
<region>MA</region>
<code>02140</code>
<country>US</country>
</postal>

<phone>+1 617 873 3133</phone>
<email>Lyman@BBN.COM</email>
</address>
</author>

<author fullname="Christian Huitema" initials="C." surname="Huitema">
<organization>INRIA, Sophia-Antipolis</organization>

<address>
<postal>
<street>2004 Route des Lucioles</street>
<street>BP 109</street>
<city>Valbonne Cedex</city>
<code>F-06561</code>
<country>FR</country>
</postal>

<phone>+33 93 657715</phone>
<email>Christian.Huitema@MIRSA.INRIA.FR</email>
</address>
</author>

<date year="1993" day="1" month="April" />
</front>

<seriesInfo value="1438" name="RFC" />
</reference>


<reference target2="reference.RFC.1439.xml" anchor="RFC1439">
<front>
<title abbrev="Uniqueness of Unique Identifiers">The Uniqueness of Unique Identifiers</title>
<author fullname="Craig A. Finseth" initials="C.A." surname="Finseth">
<organization>University of Minnesota, Computer and Information Services, Networking Services</organization>

<address>
<postal>
<street>130 Lind Hall</street>
<street>207 Church St. SE</street>
<city>Minneapolis</city>
<region>MN</region>
<code>55455-0134</code>
<country>US</country>
</postal>

<phone>+1 612 624 3375</phone>
<facsimile>+1 612 626 1002</facsimile>
<email>Craig.A.Finseth-1@umn.edu</email>
</address>
</author>

<date year="1993" month="March" />

<abstract>
<t>This RFC provides information that may be useful when selecting a method to use for assigning unique identifiers to people.</t>
</abstract>
</front>

<seriesInfo value="1439" name="RFC" />
</reference>


<reference target2="reference.RFC.1440.xml" anchor="RFC1440">
<front>
<title abbrev="SIFT/UFT">SIFT/UFT: Sender-Initiated/Unsolicited File Transfer</title>
<author fullname="Rick Troth" initials="R." surname="Troth">
<organization>Rice University, Information Systems</organization>

<address>
<postal>
<street />
<city>Houston</city>
<region>TX</region>
<code>77251</code>
<country>US</country>
</postal>

<phone>+1 713 285 5148</phone>
<facsimile>+1 713 527 6099</facsimile>
<email>troth@rice.edu</email>
</address>
</author>

<date year="1993" month="July" />
</front>

<seriesInfo value="1440" name="RFC" />
</reference>


<reference target2="reference.RFC.1441.xml" anchor="RFC1441">
<front>
<title abbrev="Introduction to SNMPv2">Introduction to version 2 of the Internet-standard Network Management Framework</title>
<author fullname="Jeffrey D. Case" initials="J.D." surname="Case">
<organization>SNMP Research, Inc.</organization>

<address>
<postal>
<street>3001 Kimberlin Heights Rd.</street>
<city>Knoxville</city>
<region>TN</region>
<code>37920-9716</code>
<country>US</country>
</postal>

<phone>+1 615 573 1434</phone>
<email>case@snmp.com</email>
</address>
</author>

<author fullname="Keith McCloghrie" initials="K." surname="McCloghrie">
<organization>Hughes, LAN Systems</organization>

<address>
<postal>
<street>1225 Charleston Road</street>
<city>Mountain View</city>
<region>CA</region>
<code>94043</code>
<country>US</country>
</postal>

<phone>+1 415 966 7934</phone>
<email>kzm@hls.com</email>
</address>
</author>

<author fullname="Marshall T. Rose" initials="M." surname="Rose">
<organization>Dover Beach Consulting, Inc.</organization>

<address>
<postal>
<street>420 Whisman Court</street>
<city>Mountain View</city>
<region>CA</region>
<code>94043-2186</code>
<country>US</country>
</postal>

<phone>+1 415 968 1052</phone>
<email>mrose@dbc.mtview.ca.us</email>
</address>
</author>

<author fullname="Steven Waldbusser" initials="S." surname="Waldbusser">
<organization>Carnegie Mellon University</organization>

<address>
<postal>
<street>4910 Forbes Ave</street>
<city>Pittsburgh</city>
<region>PA</region>
<code>15213</code>
<country>US</country>
</postal>

<phone>+1 412 268 6628</phone>
<email>waldbusser@cmu.edu</email>
</address>
</author>

<date year="1993" month="April" />
</front>

<seriesInfo value="1441" name="RFC" />
</reference>


<reference target2="reference.RFC.1442.xml" anchor="RFC1442">
<front>
<title abbrev="SMI for SNMPv2">Structure of Management Information for version 2 of the Simple Network Management Protocol (SNMPv2)</title>
<author fullname="Jeffrey D. Case" initials="J.D." surname="Case">
<organization>SNMP Research, Inc.</organization>

<address>
<postal>
<street>3001 Kimberlin Heights Rd.</street>
<city>Knoxville</city>
<region>TN</region>
<code>37920-9716</code>
<country>US</country>
</postal>

<phone>+1 615 573 1434</phone>
<email>case@snmp.com</email>
</address>
</author>

<author fullname="Keith McCloghrie" initials="K." surname="McCloghrie">
<organization>Hughes, LAN Systems</organization>

<address>
<postal>
<street>1225 Charleston Road</street>
<city>Mountain View</city>
<region>CA</region>
<code>94043</code>
<country>US</country>
</postal>

<phone>+1 415 966 7934</phone>
<email>kzm@hls.com</email>
</address>
</author>

<author fullname="Marshall T. Rose" initials="M.T." surname="Rose">
<organization>Dover Beach Consulting, Inc.</organization>

<address>
<postal>
<street>420 Whisman Court</street>
<city>Mountain View</city>
<region>CA</region>
<code>94043-2186</code>
<country>US</country>
</postal>

<phone>+1 415 968 1052</phone>
<email>mrose@dbc.mtview.ca.us</email>
</address>
</author>

<author fullname="Steven Waldbusser" initials="S." surname="Waldbusser">
<organization>Carnegie Mellon University</organization>

<address>
<postal>
<street>4910 Forbes Ave</street>
<city>Pittsburgh</city>
<region>PA</region>
<code>15213</code>
<country>US</country>
</postal>

<phone>+1 412 268 6628</phone>
<email>waldbusser@cmu.edu</email>
</address>
</author>

<date year="1993" month="April" />
</front>

<seriesInfo value="1442" name="RFC" />
</reference>


<reference target2="reference.RFC.1443.xml" anchor="RFC1443">
<front>
<title abbrev="Textual Conventions for SNMPv2">Textual Conventions for version 2 of the Simple Network Management Protocol (SNMPv2)</title>
<author fullname="Jeffrey D. Case" initials="J.D." surname="Case">
<organization>SNMP Research, Inc.</organization>

<address>
<postal>
<street>3001 Kimberlin Heights Rd.</street>
<city>Knoxville</city>
<region>TN</region>
<code>37920-9716</code>
<country>US</country>
</postal>

<phone>+1 615 573 1434</phone>
<email>case@snmp.com</email>
</address>
</author>

<author fullname="Keith McCloghrie" initials="K." surname="McCloghrie">
<organization>Hughes, LAN Systems</organization>

<address>
<postal>
<street>1225 Charleston Road</street>
<city>Mountain View</city>
<region>CA</region>
<code>94043</code>
<country>US</country>
</postal>

<phone>+1 415 966 7934</phone>
<email>kzm@hls.com</email>
</address>
</author>

<author fullname="Marshall T. Rose" initials="M.T." surname="Rose">
<organization>Dover Beach Consulting, Inc.</organization>

<address>
<postal>
<street>420 Whisman Court</street>
<city>Mountain View</city>
<region>CA</region>
<code>94043-2186</code>
<country>US</country>
</postal>

<phone>+1 415 968 1052</phone>
<email>mrose@dbc.mtview.ca.us</email>
</address>
</author>

<author fullname="Steven Waldbusser" initials="S." surname="Waldbusser">
<organization>Carnegie Mellon University</organization>

<address>
<postal>
<street>4910 Forbes Ave</street>
<city>Pittsburgh</city>
<region>PA</region>
<code>15213</code>
<country>US</country>
</postal>

<phone>+1 412 268 6628</phone>
<email>waldbusser@cmu.edu</email>
</address>
</author>

<date year="1993" month="April" />
</front>

<seriesInfo value="1443" name="RFC" />
</reference>


<reference target2="reference.RFC.1444.xml" anchor="RFC1444">
<front>
<title abbrev="Conformance Statements for SNMPv2">Conformance Statements for version 2 of the Simple Network Management Protocol (SNMPv2)</title>
<author fullname="Jeffrey D. Case" initials="J.D." surname="Case">
<organization>SNMP Research, Inc.</organization>

<address>
<postal>
<street>3001 Kimberlin Heights Rd.</street>
<city>Knoxville</city>
<region>TN</region>
<code>37920-9716</code>
<country>US</country>
</postal>

<phone>+1 615 573 1434</phone>
<email>case@snmp.com</email>
</address>
</author>

<author fullname="Keith McCloghrie" initials="K." surname="McCloghrie">
<organization>Hughes, LAN Systems</organization>

<address>
<postal>
<street>1225 Charleston Road</street>
<city>Mountain View</city>
<region>CA</region>
<code>94043</code>
<country>US</country>
</postal>

<phone>+1 415 966 7934</phone>
<email>kzm@hls.com</email>
</address>
</author>

<author fullname="Marshall T. Rose" initials="M.T." surname="Rose">
<organization>Dover Beach Consulting, Inc.</organization>

<address>
<postal>
<street>420 Whisman Court</street>
<city>Mountain View</city>
<region>CA</region>
<code>94043-2186</code>
<country>US</country>
</postal>

<phone>+1 415 968 1052</phone>
<email>mrose@dbc.mtview.ca.us</email>
</address>
</author>

<author fullname="Steven Waldbusser" initials="S." surname="Waldbusser">
<organization>Carnegie Mellon University</organization>

<address>
<postal>
<street>4910 Forbes Ave</street>
<city>Pittsburgh</city>
<region>PA</region>
<code>15213</code>
<country>US</country>
</postal>

<phone>+1 412 268 6628</phone>
<email>waldbusser@cmu.edu</email>
</address>
</author>

<date year="1993" month="April" />
</front>

<seriesInfo value="1444" name="RFC" />
</reference>


<reference target2="reference.RFC.1445.xml" anchor="RFC1445">
<front>
<title abbrev="Administrative Model for SNMPv2">Administrative Model for version 2 of the Simple Network Management Protocol (SNMPv2)</title>
<author fullname="James M. Galvin" initials="J.M." surname="Galvin">
<organization>Trusted Information Systems, Inc.</organization>

<address>
<postal>
<street>3060 Washington Road</street>
<street>Route 97</street>
<city>Glenwood</city>
<region>MD</region>
<code>21738</code>
<country>US</country>
</postal>

<phone>+1 301 854 6889</phone>
<email>galvin@tis.com</email>
</address>
</author>

<author fullname="Keith McCloghrie" initials="K." surname="McCloghrie">
<organization>Hughes LAN Systems</organization>

<address>
<postal>
<street>1225 Charleston Road</street>
<city>Mountain View</city>
<region>CA</region>
<code>94043</code>
<country>US</country>
</postal>

<phone>+1 415 966 7934</phone>
<email>kzm@hls.com</email>
</address>
</author>

<date year="1993" month="April" />
</front>

<seriesInfo value="1445" name="RFC" />
</reference>


<reference target2="reference.RFC.1446.xml" anchor="RFC1446">
<front>
<title abbrev="Security Protocols for SNMPv2">Security Protocols for version 2 of the Simple Network Management Protocol (SNMPv2)</title>
<author fullname="James M. Galvin" initials="J.M." surname="Galvin">
<organization>Trusted Information Systems, Inc.</organization>

<address>
<postal>
<street>3060 Washington Road</street>
<street>Route 97</street>
<city>Glenwood</city>
<region>MD</region>
<code>21738</code>
<country>US</country>
</postal>

<phone>+1 301 854 6889</phone>
<email>galvin@tis.com</email>
</address>
</author>

<author fullname="Keith McCloghrie" initials="K." surname="McCloghrie">
<organization>Hughes, LAN Systems</organization>

<address>
<postal>
<street>1225 Charleston Road</street>
<city>Mountain View</city>
<region>CA</region>
<code>94043</code>
<country>US</country>
</postal>

<phone>+1 415 966 7934</phone>
<email>kzm@hls.com</email>
</address>
</author>

<date year="1993" month="April" />
</front>

<seriesInfo value="1446" name="RFC" />
</reference>


<reference target2="reference.RFC.1447.xml" anchor="RFC1447">
<front>
<title abbrev="Party MIB for SNMPv2">Party MIB for version 2 of the Simple Network Management Protocol (SNMPv2)</title>
<author fullname="Keith McCloghrie" initials="K." surname="McCloghrie">
<organization>Hughes, LAN Systems</organization>

<address>
<postal>
<street>1225 Charleston Road</street>
<city>Mountain View</city>
<region>CA</region>
<code>94043</code>
<country>US</country>
</postal>

<phone>+1 415 966 7934</phone>
<email>kzm@hls.com</email>
</address>
</author>

<author fullname="James M. Galvin" initials="J.M." surname="Galvin">
<organization>Trusted Information Systems, Inc.</organization>

<address>
<postal>
<street>3060 Washington Road</street>
<street>Route 97</street>
<city>Glenwood</city>
<region>MD</region>
<code>21738</code>
<country>US</country>
</postal>

<phone>+1 301 854 6889</phone>
<email>galvin@tis.com</email>
</address>
</author>

<date year="1993" month="April" />
</front>

<seriesInfo value="1447" name="RFC" />
</reference>


<reference target2="reference.RFC.1448.xml" anchor="RFC1448">
<front>
<title abbrev="Protocol Operations for SNMPv2">Protocol Operations for version 2 of the Simple Network Management Protocol (SNMPv2)</title>
<author fullname="Jeffrey D. Case" initials="J." surname="Case">
<organization>SNMP Research, Inc.</organization>

<address>
<postal>
<street>3001 Kimberlin Heights Rd.</street>
<city>Knoxville</city>
<region>TN</region>
<code>37920-9716</code>
<country>US</country>
</postal>

<phone>+1 615 573 1434</phone>
<email>case@snmp.com</email>
</address>
</author>

<author fullname="Keith McCloghrie" initials="K." surname="McCloghrie">
<organization>Hughes, LAN Systems</organization>

<address>
<postal>
<street>1225 Charleston Road</street>
<city>Mountain View</city>
<region>CA</region>
<code>94043</code>
<country>US</country>
</postal>

<phone>+1 415 966 7934</phone>
<email>kzm@hls.com</email>
</address>
</author>

<author fullname="Marshall T. Rose" initials="M." surname="Rose">
<organization>Dover Beach Consulting, Inc.</organization>

<address>
<postal>
<street>420 Whisman Court</street>
<city>Mountain View</city>
<region>CA</region>
<code>94043-2186</code>
<country>US</country>
</postal>

<phone>+1 415 968 1052</phone>
<email>mrose@dbc.mtview.ca.us</email>
</address>
</author>

<author fullname="Steven Waldbusser" initials="S." surname="Waldbusser">
<organization>Carnegie Mellon University</organization>

<address>
<postal>
<street>4910 Forbes Ave</street>
<city>Pittsburgh</city>
<region>PA</region>
<code>15213</code>
<country>US</country>
</postal>

<phone>+1 412 268 6628</phone>
<email>waldbusser@cmu.edu</email>
</address>
</author>

<date year="1993" month="April" />
</front>

<seriesInfo value="1448" name="RFC" />
</reference>


<reference target2="reference.RFC.1449.xml" anchor="RFC1449">
<front>
<title abbrev="Transport Mappings for SNMPv2">Transport Mappings for version 2 of the Simple Network Management Protocol (SNMPv2)</title>
<author fullname="Jeffrey D. Case" initials="J.D." surname="Case">
<organization>SNMP Research, Inc.</organization>

<address>
<postal>
<street>3001 Kimberlin Heights Rd.</street>
<city>Knoxville</city>
<region>TN</region>
<code>37920-9716</code>
<country>US</country>
</postal>

<phone>+1 615 573 1434</phone>
<email>case@snmp.com</email>
</address>
</author>

<author fullname="Keith McCloghrie" initials="K." surname="McCloghrie">
<organization>Hughes, LAN Systems</organization>

<address>
<postal>
<street>1225 Charleston Road</street>
<city>Mountain View</city>
<region>CA</region>
<code>94043</code>
<country>US</country>
</postal>

<phone>+1 415 966 7934</phone>
<email>kzm@hls.com</email>
</address>
</author>

<author fullname="Marshall T. Rose" initials="M." surname="Rose">
<organization>Dover Beach Consulting, Inc.</organization>

<address>
<postal>
<street>420 Whisman Court</street>
<city>Mountain View</city>
<region>CA</region>
<code>94043-2186</code>
<country>US</country>
</postal>

<phone>+1 415 968 1052</phone>
<email>mrose@dbc.mtview.ca.us</email>
</address>
</author>

<author fullname="Steven Waldbusser" initials="S." surname="Waldbusser">
<organization>Carnegie Mellon University</organization>

<address>
<postal>
<street>4910 Forbes Ave</street>
<city>Pittsburgh</city>
<region>PA</region>
<code>15213</code>
<country>US</country>
</postal>

<phone>+1 412 268 6628</phone>
<email>waldbusser@cmu.edu</email>
</address>
</author>

<date year="1993" month="April" />
</front>

<seriesInfo value="1449" name="RFC" />
</reference>


<reference target2="reference.RFC.1450.xml" anchor="RFC1450">
<front>
<title abbrev="Management Information Base for SNMPv2">Management Information Base for version 2 of the Simple Network Management Protocol (SNMPv2)</title>
<author fullname="Jeffrey D. Case" initials="J.D." surname="Case">
<organization>SNMP Research, Inc.</organization>

<address>
<postal>
<street>3001 Kimberlin Heights Rd.</street>
<city>Knoxville</city>
<region>TN</region>
<code>37920-9716</code>
<country>US</country>
</postal>

<phone>+1 615 573 1434</phone>
<email>case@snmp.com</email>
</address>
</author>

<author fullname="Keith McCloghrie" initials="K." surname="McCloghrie">
<organization>Hughes, LAN Systems</organization>

<address>
<postal>
<street>1225 Charleston Road</street>
<city>Mountain View</city>
<region>CA</region>
<code>94043</code>
<country>US</country>
</postal>

<phone>+1 415 966 7934</phone>
<email>kzm@hls.com</email>
</address>
</author>

<author fullname="Marshall T. Rose" initials="M.T." surname="Rose">
<organization>Dover Beach Consulting, Inc.</organization>

<address>
<postal>
<street>420 Whisman Court</street>
<city>Mountain View</city>
<region>CA</region>
<code>94043-2186</code>
<country>US</country>
</postal>

<phone>+1 415 968 1052</phone>
<email>mrose@dbc.mtview.ca.us</email>
</address>
</author>

<author fullname="Steven Waldbusser" initials="S." surname="Waldbusser">
<organization>Carnegie Mellon University</organization>

<address>
<postal>
<street>4910 Forbes Ave</street>
<city>Pittsburgh</city>
<region>PA</region>
<code>15213</code>
<country>US</country>
</postal>

<phone>+1 412 268 6628</phone>
<email>waldbusser@cmu.edu</email>
</address>
</author>

<date year="1993" month="April" />
</front>

<seriesInfo value="1450" name="RFC" />
</reference>


<reference target2="reference.RFC.1451.xml" anchor="RFC1451">
<front>
<title abbrev="Manager-to-Manager MIB">Manager-to-Manager Management Information Base</title>
<author fullname="Jeffrey D. Case" initials="J.D." surname="Case">
<organization>SNMP Research, Inc.</organization>

<address>
<postal>
<street>3001 Kimberlin Heights Rd.</street>
<city>Knoxville</city>
<region>TN</region>
<code>37920-9716</code>
<country>US</country>
</postal>

<phone>+1 615 573 1434</phone>
<email>case@snmp.com</email>
</address>
</author>

<author fullname="Keith McCloghrie" initials="K." surname="McCloghrie">
<organization>Hughes, LAN Systems</organization>

<address>
<postal>
<street>1225 Charleston Road</street>
<city>Mountain View</city>
<region>CA</region>
<code>94043</code>
<country>US</country>
</postal>

<phone>+1 415 966 7934</phone>
<email>kzm@hls.com</email>
</address>
</author>

<author fullname="Marshall T. Rose" initials="M.T." surname="Rose">
<organization>Dover Beach Consulting, Inc.</organization>

<address>
<postal>
<street>420 Whisman Court</street>
<city>Mountain View</city>
<region>CA</region>
<code>94043-2186</code>
<country>US</country>
</postal>

<phone>+1 415 968 1052</phone>
<email>mrose@dbc.mtview.ca.us</email>
</address>
</author>

<author fullname="Steven Waldbusser" initials="S." surname="Waldbusser">
<organization>Carnegie Mellon University</organization>

<address>
<postal>
<street>4910 Forbes Ave</street>
<city>Pittsburgh</city>
<region>PA</region>
<code>15213</code>
<country>US</country>
</postal>

<phone>+1 412 268 6628</phone>
<email>waldbusser@cmu.edu</email>
</address>
</author>

<date year="1993" month="April" />
</front>

<seriesInfo value="1451" name="RFC" />
</reference>


<reference target2="reference.RFC.1452.xml" anchor="RFC1452">
<front>
<title abbrev="Coexistence between SNMPv1 and SNMPv2">Coexistence between version 1 and version 2 of the Internet-standard Network Management Framework</title>
<author fullname="Jeffrey D. Case" initials="J.D." surname="Case">
<organization>SNMP Research, Inc.</organization>

<address>
<postal>
<street>3001 Kimberlin Heights Rd.</street>
<city>Knoxville</city>
<region>TN</region>
<code>37920-9716</code>
<country>US</country>
</postal>

<phone>+1 615 573 1434</phone>
<email>case@snmp.com</email>
</address>
</author>

<author fullname="Keith McCloghrie" initials="K." surname="McCloghrie">
<organization>Hughes, LAN Systems</organization>

<address>
<postal>
<street>1225 Charleston Road</street>
<city>Mountain View</city>
<region>CA</region>
<code>94043</code>
<country>US</country>
</postal>

<phone>+1 415 966 7934</phone>
<email>kzm@hls.com</email>
</address>
</author>

<author fullname="Marshall T. Rose" initials="M.T." surname="Rose">
<organization>Dover Beach Consulting, Inc.</organization>

<address>
<postal>
<street>420 Whisman Court</street>
<city>Mountain View</city>
<region>CA</region>
<code>94043-2186</code>
<country>US</country>
</postal>

<phone>+1 415 968 1052</phone>
<email>mrose@dbc.mtview.ca.us</email>
</address>
</author>

<author fullname="Steven Waldbusser" initials="S." surname="Waldbusser">
<organization>Carnegie Mellon University</organization>

<address>
<postal>
<street>4910 Forbes Ave</street>
<city>Pittsburgh</city>
<region>PA</region>
<code>15213</code>
<country>US</country>
</postal>

<phone>+1 412 268 6628</phone>
<email>waldbusser@cmu.edu</email>
</address>
</author>

<date year="1993" month="April" />
</front>

<seriesInfo value="1452" name="RFC" />
</reference>


<reference target2="reference.RFC.1453.xml" anchor="RFC1453">
<front>
<title abbrev="Comments on Video Conferencing">A Comment on Packet Video Remote Conferencing and the Transport/Network Layers</title>
<author fullname="William J. Chimiak" initials="W.J." surname="Chimiak">
<organization>Bowman Gray School of Medicine, Department of Radiology</organization>

<address>
<postal>
<street>Medical Center Boulevard</street>
<city>Winston-Salem</city>
<region>NC</region>
<code>27157-1022</code>
<country>US</country>
</postal>

<phone>+1 919 716 2815</phone>
<email>chim@relito.medeng.wfu.edu</email>
</address>
</author>

<date year="1993" month="April" />

<abstract>
<t>The new generation of multimedia applications demands new features and new mechanisms for proper performance.  ATM technology has moved from concept to reality, delivering very high bandwidths and new capabilities to the data link layer user.  In an effort to anticipate the high bandwidth-delay data link layer, Delta-t, NETBLT, and VMTPwere developed.  The excellent insights and mechanisms pioneered by the creators of these experimental Internet protocols were used in the design of Xpress Transfer Protocol (XTP)with the goal of eventually delivering ATM bandwidths to a user process.  This RFC is a vehicle to inform the Internet community about XTP as it benefits from past Internet activity and targets general-purpose applications and multimedia applications with the emerging ATM networks in mind.</t>
</abstract>
</front>

<seriesInfo value="1453" name="RFC" />
</reference>


<reference target2="reference.RFC.1454.xml" anchor="RFC1454">
<front>
<title abbrev="Comparison of Next Version IP Proposals">Comparison of Proposals for Next Version of IP</title>
<author fullname="Tim Dixon" initials="T." surname="Dixon">
<organization>RARE</organization>

<address>
<postal>
<street>Singel 466-468</street>
<city>Amsterdam</city>
<region />
<code>NL-1017AW</code>
<country>NL</country>
</postal>

<phone>+31 20 6391131</phone>
<email>dixon@rare.nl</email>
</address>
</author>

<date year="1993" month="May" />

<abstract>
<t>This is a slightly edited reprint of RARE Technical Report (RTC(93)004).</t>

<t>The following is a brief summary of the characteristics of the three main proposals for replacing the current Internet Protocol. It is not intended to be exhaustive or definitive (a brief bibliography at the end points to sources of more information), but to serve as input to the European discussions on these proposals, to be co-ordinated by RARE and RIPE. It should be recognised that the proposals are themselves "moving targets", and in so far as this paper is accurate at all, it reflects the position at the 25th IETF meeting in Washington, DC. Comments from Ross Callon and Paul Tsuchiya on the original draft have been incorporated.  Note that for a time the term "IPv7" was use to mean the eventual next version of IP, but that the same term was closely associated with a particilar proposal, so the term "IPng" is now used to identify the eventual next generation of IP.</t>

<t>The paper begins with a "generic" discussion of the mechanisms for solving problems and achieving particular goals, before discussing the proposals invidually.</t>
</abstract>
</front>

<seriesInfo value="1454" name="RFC" />
</reference>


<reference target2="reference.RFC.1455.xml" anchor="RFC1455">
<front>
<title abbrev="Link Security TOS">Physical Link Security Type of Service</title>
<author fullname="Donald E. Eastlake, III" initials="D.E." surname="Eastlake">
<organization>Digital Equipment Corporation (DEC)</organization>

<address>
<postal>
<street>30 Porter Road</street>
<street>MS: LJO2/I4</street>
<city>Littleton</city>
<region>MA</region>
<code>01460</code>
<country>US</country>
</postal>

<phone>+1 508 486 2358</phone>
<email>dee@ranger.enet.dec.com</email>
</address>
</author>

<date year="1993" month="May" />

<abstract>
<t>This RFC documents an experimental protocol providing a Type of Service (TOS) to request maximum physical link security.  This is an addition to the types of service enumerated in RFC 1349: Type of Service in the Internet Protocol Suite.  The new TOS requests the network to provide what protection it can against surreptitious observation by outside agents of traffic so labeled.  The purpose is protection against traffic analysis and as an additional possible level of data confidentiality.  This TOS is consistent with all other defined types of service for IP version 4 in that it is based on link level characteristics and will not provide any particular guaranteed level of service.</t>
</abstract>
</front>

<seriesInfo value="1455" name="RFC" />
</reference>


<reference target2="reference.RFC.1456.xml" anchor="RFC1456">
<front>
<title abbrev="Conventions for Encoding Vietnamese">Conventions for Encoding the Vietnamese Language VISCII: VIetnamese Standard Code for Information Interchange VIQR: VIetnamese Quoted-Readable Specification</title>
<author fullname="Cuong T. Nguyen" initials="C.T." surname="Nguyen">
<organization>Center for Integrated Systems</organization>

<address>
<postal>
<street>CIS 062--MC 4070</street>
<city>Stanford</city>
<region>CA</region>
<code>94305-4070</code>
<country>US</country>
</postal>

<phone>+1 415 725 3721</phone>
<email>cuong@haydn.Stanford.EDU</email>
</address>
</author>

<author fullname="Hoc D. Ngo" initials="H.D." surname="Ngo">
<organization>Vista Research, Inc.</organization>

<address>
<postal>
<street>100 View St</street>
<street>Suite 200</street>
<street>P.O. Box 998</street>
<city>Mountain View</city>
<region>CA</region>
<code>94042</code>
<country>US</country>
</postal>

<phone>+1 415 966 1171</phone>
<email>uunet!vri280!hoc</email>
</address>
</author>

<author fullname="Cuong M. Bui" initials="C.M." surname="Bui">
<organization>National Semiconductor Corp.</organization>

<address>
<postal>
<street>3388 Burgundy Dr.</street>
<city>San Jose</city>
<region>CA</region>
<code>95132</code>
<country>US</country>
</postal>

<phone>+1 408 721 6873</phone>
<email>bui@berlioz.nsc.com</email>
</address>
</author>

<author fullname="Thanh van Nguyen" initials="T." surname="van Nguyen">
<organization>Roche Image Analysis Systems</organization>

<address>
<postal>
<street>95 First Str Suite 110</street>
<city>Los Altos</city>
<region>CA</region>
<code>94022</code>
<country>US</country>
</postal>

<phone>+1 415 917 2022</phone>
<facsimile>+1 415 917 2025</facsimile>
<email>thanh@rias.com</email>
</address>
</author>

<date year="1993" month="May" />

<abstract>
<t>This document provides information to the Internet community on the currently used conventions for encoding Vietnamese characters into 7-bit US ASCII and in an 8-bit form.  These conventions are widely used by the overseas Vietnamese who are on the Internet and are active in USENET.  This document only provides information and specifies no level of standard.</t>
</abstract>
</front>

<seriesInfo value="1456" name="RFC" />
</reference>


<reference target2="reference.RFC.1457.xml" anchor="RFC1457">
<front>
<title>Security Label Framework for the Internet</title>
<author fullname="Russell Housley" initials="R." surname="Housley">
<organization>Xerox, Special Information Systems</organization>

<address>
<postal>
<street>7900 Westpark Drive</street>
<city>McLean</city>
<region>VA</region>
<code>22102</code>
<country>US</country>
</postal>

<phone>+1 703 790 3767</phone>
<email>Housley.McLean_CSD@Xerox.COM</email>
</address>
</author>

<date year="1993" month="May" />
</front>

<seriesInfo value="1457" name="RFC" />
</reference>


<reference target2="reference.RFC.1458.xml" anchor="RFC1458">
<front>
<title>Requirements for Multicast Protocols</title>
<author fullname="Bob Braudes" initials="B." surname="Braudes">
<organization>TASC</organization>

<address>
<postal>
<street>55 Walkers Brook Drive</street>
<city>Reading</city>
<region>MA</region>
<code>01867</code>
<country>US</country>
</postal>

<phone>+1 617 942 2000</phone>
<email>rebraudes@tasc.com</email>
</address>
</author>

<author fullname="Steve Zabele" initials="S." surname="Zabele">
<organization>TASC</organization>

<address>
<postal>
<street>55 Walkers Brook Drive</street>
<city>Reading</city>
<region>MA</region>
<code>01867</code>
<country>US</country>
</postal>

<phone>+1 617 942 2000</phone>
<email>gszabele@tasc.com</email>
</address>
</author>

<date year="1993" month="May" />
</front>

<seriesInfo value="1458" name="RFC" />
</reference>


<reference target2="reference.RFC.1459.xml" anchor="RFC1459">
<front>
<title>Internet Relay Chat Protocol</title>
<author fullname="Jarkko Oikarinen" initials="J." surname="Oikarinen">
<organization />

<address>
<postal>
<street>Tuirantie 17 as 9</street>
<city>Oulu</city>
<region />
<code>90500</code>
<country>FI</country>
</postal>

<email>jto@tolsun.oulu.fi</email>
</address>
</author>

<author fullname="Darren Reed" initials="D." surname="Reed">
<organization />

<address>
<postal>
<street>4 Pateman Street</street>
<city>Watsonia</city>
<region>Victoria</region>
<code>3087</code>
<country>AU</country>
</postal>

<email>avalon@coombs.anu.edu.au</email>
</address>
</author>

<date year="1993" month="May" />

<abstract>
<t>The IRC protocol was developed over the last 4 years since it was first implemented as a means for users on a BBS to chat amongst themselves.  Now it supports a world-wide network of servers and clients, and is stringing to cope with growth. Over the past 2 years, the average number of users connected to the main IRC network has grown by a factor of 10.</t>

<t>The IRC protocol is a text-based protocol, with the simplest client being any socket program capable of connecting to the server.</t>
</abstract>
</front>

<seriesInfo value="1459" name="RFC" />
</reference>


<reference target2="reference.RFC.1460.xml" anchor="RFC1460">
<front>
<title abbrev="POP3">Post Office Protocol - Version 3</title>
<author fullname="Marshall T. Rose" initials="M." surname="Rose">
<organization>Dover Beach Consulting, Inc.</organization>

<address>
<postal>
<street>420 Whisman Court</street>
<city>Mountain View</city>
<region>CA</region>
<code>94043-2186</code>
<country>US</country>
</postal>

<phone>+1 415 968 1052</phone>
<facsimile>+1 415 968 2510</facsimile>
<email>mrose@dbc.mtview.ca.us</email>
</address>
</author>

<date year="1993" month="June" />
</front>

<seriesInfo value="1460" name="RFC" />
</reference>


<reference target2="reference.RFC.1461.xml" anchor="RFC1461">
<front>
<title abbrev="Multiprotocol Interconnect on X.25 MIB">SNMP MIB extension for Multiprotocol Interconnect over X.25</title>
<author fullname="Dean D. Throop" initials="D.D." surname="Throop">
<organization>Data General Corporation</organization>

<address>
<postal>
<street>62 Alexander Dr.</street>
<city>Research Triangle Park</city>
<region>NC</region>
<code>27709</code>
<country>US</country>
</postal>

<phone>+1 919 248 6081</phone>
<email>throop@dg-rtp.dg.com</email>
</address>
</author>

<date year="1993" month="May" />

<abstract>
<t>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 Multiprotocol Interconnect (including IP) traffic carried over X.25.  The objects defined here, along with the objects in the "SNMP MIB extension for the Packet Layer of X.25", "SNMP MIB extension for LAPB", and the "Definitions of Managed Objects for RS-232-like Hardware Devices", combine to allow management of the traffic over an X.25 protocol stack.</t>
</abstract>
</front>

<seriesInfo value="1461" name="RFC" />
</reference>


<reference target2="reference.RFC.1462.xml" anchor="RFC1462">
<front>
<title abbrev="What is the Internet?">FYI on "What is the Internet?"</title>
<author fullname="Ed Krol" initials="E." surname="Krol">
<organization>University of IllinoisComputing and Communications Service Office, Urbana Champaign (UIUC)</organization>

<address>
<postal>
<street>1304 W Springfield</street>
<city>Urbana</city>
<region>IL</region>
<code>61801</code>
<country>US</country>
</postal>

<phone>+1 217 333 7886</phone>
<email>e-krol@uiuc.edu</email>
</address>
</author>

<author fullname="Ellen Hoffman" initials="E." surname="Hoffman">
<organization>Merit Network, Inc.</organization>

<address>
<postal>
<street>2901 Hubbard</street>
<street>Pod-G</street>
<city>Ann Arbor</city>
<region>MI</region>
<code>48105</code>
<country>US</country>
</postal>

<phone>+1 313 936 3000</phone>
<email>ellen@merit.edu</email>
</address>
</author>

<date year="1993" month="May" />

<abstract>
<t>This FYI RFC answers the question, "What is the Internet?" and is produced by the User Services Working Group of the Internet Engineering Task Force (IETF). Containing a modified chapter from Ed Krol's 1992 book, "The Whole Internet User's Guide and Catalog," the paper covers the Internet's definition, history, administration, protocols, financing, and current issues such as growth, commercialization, and privatization.</t>
</abstract>
</front>

<seriesInfo value="1462" name="RFC" />
</reference>


<reference target2="reference.RFC.1463.xml" anchor="RFC1463">
<front>
<title abbrev="FYI--Short Bibliography">FYI on Introducing the Internet-- A Short Bibliography of Introductory Internetworking Readings</title>
<author fullname="Ellen S. Hoffman" initials="E.S." surname="Hoffman">
<organization>Merit Network, Inc.</organization>

<address>
<postal>
<street>2901 Hubbard</street>
<street>Pod G</street>
<city>Ann Arbor</city>
<region>MI</region>
<code>48109</code>
<country>US</country>
</postal>

<phone>+1 313 936 3000</phone>
<email>ellen@merit.edu</email>
</address>
</author>

<author fullname="Lenore Jackson" initials="L." surname="Jackson">
<organization>NASA Ames Research Center</organization>

<address>
<postal>
<street>m/s 233-8 T-1191</street>
<city>Moffett Field</city>
<region>CA</region>
<code>94035</code>
<country>US</country>
</postal>

<phone>+1 415 604 0455</phone>
<email>jackson@nsipo.arc.nasa.gov</email>
</address>
</author>

<date year="1993" month="May" />

<abstract>
<t>This bibliography offers a short list of recent information resources that will help the network novice become familiar with the Internet, including its associated networks, resources, protocols, and history. This FYI RFC includes references to free sources of information available on-line as well as traditional publications.  A short section at the end includes information for accessing the on-line files.  This FYI is intentionally brief so it can be easily used as a handout by user services personnel.</t>
</abstract>
</front>

<seriesInfo value="1463" name="RFC" />
</reference>


<reference target2="reference.RFC.1464.xml" anchor="RFC1464">
<front>
<title abbrev="Storing Arbitrary Attributes in DNS">Using the Domain Name System To Store Arbitrary String Attributes</title>
<author fullname="Rich Rosenbaum" initials="R." surname="Rosenbaum">
<organization>Digital Equipment Corporation</organization>

<address>
<postal>
<street>550 King Street</street>
<street>LKG2-2/Z7</street>
<city>Littleton</city>
<region>MA</region>
<code>01460-1289</code>
<country>US</country>
</postal>

<phone>+1 508 486 5922</phone>
<email>rosenbaum@lkg.dec.com</email>
</address>
</author>

<date year="1993" month="May" />

<abstract>
<t>While the Domain Name System (DNS),is generally used to store predefined types of information (e.g., addresses of hosts), it is possible to use it to store information that has not been previously classified.</t>

<t>This paper describes a simple means to associate arbitrary string information (ASCII text) with attributes that have not been defined by the DNS.  It uses DNS TXT resource records to store the information.  It requires no change to current DNS implementations.</t>
</abstract>
</front>

<seriesInfo value="1464" name="RFC" />
</reference>


<reference target2="reference.RFC.1465.xml" anchor="RFC1465">
<front>
<title abbrev="Routing Coordination for X.400 Services">Routing Coordination for X.400 MHS Services Within a Multi Protocol / Multi Network Environment Table Format V3 for Static Routing</title>
<author fullname="Urs Eppenberger" initials="U." surname="Eppenberger">
<organization>SWITCH</organization>

<address>
<postal>
<street>Limmatquai 138</street>
<city>Zurich</city>
<region />
<code>CH-8001</code>
<country>CH</country>
</postal>

<phone>+41 1 2618112</phone>
<facsimile>+41 1 2618133</facsimile>
<email>Eppenberger@switch.ch</email>
</address>
</author>

<date year="1993" month="May" />
</front>

<seriesInfo value="1465" name="RFC" />
</reference>


<reference target2="reference.RFC.1466.xml" anchor="RFC1466">
<front>
<title>Guidelines for Management of IP Address Space</title>
<author fullname="Elise Gerich" initials="E." surname="Gerich">
<organization>Merit Network, Inc.</organization>

<address>
<postal>
<street>1071 Beal Avenue</street>
<city>Ann Arbor</city>
<region>MI</region>
<code>48109-2112</code>
<country>US</country>
</postal>

<phone>+1 313 936 3335</phone>
<email>epg@MERIT.EDU</email>
</address>
</author>

<date year="1993" month="May" />

<abstract>
<t>This document has been reviewed by the Federal Engineering Planning Group (FEPG) on behalf of the Federal Networking Council (FNC), the co-chairs of the Intercontinental Engineering Planning Group (IEPG), and the Reseaux IP Europeens (RIPE).  There was general consensus by those groups to support the recommendations proposed in this document for management of the IP address space.</t>
</abstract>
</front>

<seriesInfo value="1466" name="RFC" />
</reference>


<reference target2="reference.RFC.1467.xml" anchor="RFC1467">
<front>
<title>Status of CIDR Deployment in the Internet</title>
<author fullname="Claudio Topolcic" initials="C." surname="Topolcic">
<organization>Corporation for National Research Initiatives</organization>

<address>
<postal>
<street>895 Preston White Drive</street>
<street>Suite 100</street>
<city>Reston</city>
<region>VA</region>
<code>22091</code>
<country>US</country>
</postal>

<phone>+1 703 620 8990</phone>
<email>topolcic@CNRI.Reston.VA.US</email>
</address>
</author>

<date year="1993" month="August" />

<abstract>
<t>This document describes the current status of the development and deployment of CIDR technology into the Internet. This document replaces RFC 1367, which was a schedule for the deployment of IP address space management procedures to support route aggregation. Since all the milestones proposed in RFC 1367 except for the delivery and installation of CIDR software were met, it does not seem appropriate to issue an updated schedule. Rather, this document is intended to provide information about how this effort is proceeding, which may be of interest to the community.</t>
</abstract>
</front>

<seriesInfo value="1467" name="RFC" />
</reference>


<reference target2="reference.RFC.1468.xml" anchor="RFC1468">
<front>
<title>Japanese Character Encoding for Internet Messages</title>
<author fullname="Jun Murai" initials="J." surname="Murai">
<organization>Keio University, Fujisawa</organization>

<address>
<postal>
<street>5322 Endo</street>
<city>Kanagawa</city>
<region />
<code>252</code>
<country>JP</country>
</postal>

<phone>+81 466 491101</phone>
<email>jun@wide.ad.jp</email>
</address>
</author>

<author fullname="Mark Crispin" initials="M." surname="Crispin">
<organization>Panda Programming</organization>

<address>
<postal>
<street>6158 Lariat Loop NE</street>
<city>Bainbridge Island</city>
<region>WA</region>
<code>98110-2098</code>
<country>US</country>
</postal>

<phone>+1 206 842 2385</phone>
<email>MRC@PANDA.COM</email>
</address>
</author>

<author fullname="Erik M. van der Poel" initials="E.M." surname="van der Poel">
<organization>Kisarazu</organization>

<address>
<postal>
<street>A-105 Park Avenue</street>
<city>4-4-10 Ohta</city>
<region>Chiba</region>
<code>292</code>
<country>JP</country>
</postal>

<phone>+81 438 225836</phone>
<facsimile>+81 438 225837</facsimile>
<email>erik@poel.juice.or.jp</email>
</address>
</author>

<date year="1993" month="June" />
</front>

<seriesInfo value="1468" name="RFC" />
</reference>


<reference target2="reference.RFC.1469.xml" anchor="RFC1469">
<front>
<title abbrev="IP Multicast over Token-Ring LANs">IP Multicast over Token-Ring Local Area Networks</title>
<author fullname="Thomas J. Pusateri" initials="T.J." surname="Pusateri">
<organization />

<address>
<postal>
<street>11820 Edgewater Ct.</street>
<city>Raleigh</city>
<region>NC</region>
<code>27614</code>
<country>US</country>
</postal>

<email>pusateri@cs.duke.edu</email>
</address>
</author>

<date year="1993" month="June" />

<abstract>
<t>This document specifies a method for the transmission of IP multicast datagrams over Token-Ring Local Area Networks.  Although an interim solution has emerged and is currently being used, it is the intention of this document to specify a more efficient means of transmission using an assigned Token-Ring functional address.</t>
</abstract>
</front>

<seriesInfo value="1469" name="RFC" />
</reference>


<reference target2="reference.RFC.1470.xml" anchor="RFC1470">
<front>
<title abbrev="FYI: Network Management Tool Catalog">FYI on a Network Management Tool Catalog: Tools for Monitoring and Debugging TCP/IP Internets and Interconnected Devices</title>
<author fullname="Robert M. Enger" initials="R." surname="Enger">
<organization>Advanced Network and Services</organization>

<address>
<postal>
<street>1875 Campus Commons Drive</street>
<street>Suite 220</street>
<city>Reston</city>
<region>VA</region>
<code>22091-1552</code>
<country>US</country>
</postal>

<phone>+1 703 758 7722</phone>
<email>enger@reston.ans.net</email>
</address>
</author>

<author fullname="Joyce K. Reynolds" initials="J." surname="Reynolds">
<organization>University of Southern California, Information Sciences Institute</organization>

<address>
<postal>
<street>4676 Admiralty Way</street>
<city>Marina del Rey</city>
<region>CA</region>
<code>90292</code>
<country>US</country>
</postal>

<phone>+1 310 822 1511</phone>
<email>JKREY@ISI.EDU</email>
</address>
</author>

<date year="1993" month="June" />

<abstract>
<t>The goal of this FYI memo is to provide an update to FYI 2, RFC 1147, which provided practical information to site administrators and network managers.  New and/or updated tools are listed in this RFC. Additonal descriptions are welcome, and should be sent to: noctools- entries@merit.edu.</t>
</abstract>
</front>

<seriesInfo value="1470" name="RFC" />
</reference>


<reference target2="reference.RFC.1471.xml" anchor="RFC1471">
<front>
<title abbrev="PPP/LCP MIB">The Definitions of Managed Objects for the Link Control Protocol of the Point-to-Point Protocol</title>
<author fullname="Frank Kastenholz" initials="F." surname="Kastenholz">
<organization>FTP Software, Inc.</organization>

<address>
<postal>
<street>2 High Street</street>
<city>North Andover</city>
<region>MA</region>
<code>01845</code>
<country>US</country>
</postal>

<phone>+1 508 685 4000</phone>
<email>kasten@ftp.com</email>
</address>
</author>

<date year="1993" month="June" />

<abstract>
<t>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 describes managed objects used for managing the Link Control Protocol and Link Quality Monitoring on subnetwork interfaces that use the family of Point-to-Point Protocols,,,, &amp;.</t>
</abstract>
</front>

<seriesInfo value="1471" name="RFC" />
</reference>


<reference target2="reference.RFC.1472.xml" anchor="RFC1472">
<front>
<title abbrev="PPP/Security MIB">The Definitions of Managed Objects for the Security Protocols of the Point-to-Point Protocol</title>
<author fullname="Frank Kastenholz" initials="F." surname="Kastenholz">
<organization>FTP Software, Inc.</organization>

<address>
<postal>
<street>2 High Street</street>
<city>North Andover</city>
<region>MA</region>
<code>01845</code>
<country>US</country>
</postal>

<phone>+1 508 685 4000</phone>
<email>kasten@ftp.com</email>
</address>
</author>

<date year="1993" month="June" />

<abstract>
<t>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 describes managed objects used for managing the Security Protocols on subnetwork interfaces using the family of Point-to-Point Protocols,,,, &amp;.</t>
</abstract>
</front>

<seriesInfo value="1472" name="RFC" />
</reference>


<reference target2="reference.RFC.1473.xml" anchor="RFC1473">
<front>
<title abbrev="PPP/IP MIB">The Definitions of Managed Objects for the IP Network Control Protocol of the Point-to-Point Protocol</title>
<author fullname="Frank Kastenholz" initials="F." surname="Kastenholz">
<organization>FTP Software, Inc.</organization>

<address>
<postal>
<street>2 High Street</street>
<city>North Andover</city>
<region>MA</region>
<code>01845</code>
<country>US</country>
</postal>

<phone>+1 508 685 4000</phone>
<email>kasten@ftp.com</email>
</address>
</author>

<date year="1993" month="June" />

<abstract>
<t>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 describes managed objects used for managing the IP Network Control Protocol on subnetwork interfaces using the family of Point-to-Point Protocols,,,, &amp;.</t>
</abstract>
</front>

<seriesInfo value="1473" name="RFC" />
</reference>


<reference target2="reference.RFC.1474.xml" anchor="RFC1474">
<front>
<title abbrev="PPP/Bridge MIB">The Definitions of Managed Objects for the Bridge Network Control Protocol of the Point-to-Point Protocol</title>
<author fullname="Frank Kastenholz" initials="F." surname="Kastenholz">
<organization>FTP Software, Inc.</organization>

<address>
<postal>
<street>2 High Street</street>
<city>North Andover</city>
<region>MA</region>
<code>01845</code>
<country>US</country>
</postal>

<phone>+1 508 685 4000</phone>
<email>kasten@ftp.com</email>
</address>
</author>

<date year="1993" month="June" />

<abstract>
<t>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 describes managed objects used for managing the bridge Network Control Protocolon subnetwork interfaces using the family of Point-to-Point Protocols.</t>
</abstract>
</front>

<seriesInfo value="1474" name="RFC" />
</reference>


<reference target2="reference.RFC.1475.xml" anchor="RFC1475">
<front>
<title abbrev="TP/IX">TP/IX: The Next Internet</title>
<author fullname="Robert Ullmann" initials="R." surname="Ullmann">
<organization>Process Software Corporation</organization>

<address>
<postal>
<street>959 Concord Street</street>
<city>Framingham</city>
<region>MA</region>
<code>01701</code>
<country>US</country>
</postal>

<phone>+1 508 879 6994 x226</phone>
<email>Ariel@Process.COM</email>
</address>
</author>

<date year="1993" month="June" />

<abstract>
<t>The first version of this memo, describing a possible next generation of Internet protocols, was written by the present author in the summer and fall of 1989, and circulated informally, including to the IESG, in December 1989.  A further informal note on the addressing, called "Toasternet Part II", was circulated on the IETF mail list during March of 1992.</t>
</abstract>
</front>

<seriesInfo value="1475" name="RFC" />
</reference>


<reference target2="reference.RFC.1476.xml" anchor="RFC1476">
<front>
<title abbrev="RAP">RAP: Internet Route Access Protocol</title>
<author fullname="Robert Ullmann" initials="R." surname="Ullmann">
<organization>Process Software Corporation</organization>

<address>
<postal>
<street>959 Concord Street</street>
<city>Framingham</city>
<region>MA</region>
<code>01701</code>
<country>US</country>
</postal>

<phone>+1 508 879 6994 x226</phone>
<email>Ariel@Process.COM</email>
</address>
</author>

<date year="1993" month="June" />

<abstract>
<t>This RFC describes an open distance vector routing protocol for use at all levels of the internet, from isolated LANs to the major routers of an international commercial network provider.</t>
</abstract>
</front>

<seriesInfo value="1476" name="RFC" />
</reference>


<reference target2="reference.RFC.1477.xml" anchor="RFC1477">
<front>
<title abbrev="IDPR">IDPR as a Proposed Standard</title>
<author fullname="Martha Steenstrup" initials="M." surname="Steenstrup">
<organization>BBN Systems and Technologies</organization>

<address>
<postal>
<street>10 Moulton Street</street>
<city>Cambridge</city>
<region>MA</region>
<code>02138</code>
<country>US</country>
</postal>

<phone>+1 617 873 3192</phone>
<email>msteenst@bbn.com</email>
</address>
</author>

<date year="1993" month="July" />
</front>

<seriesInfo value="1477" name="RFC" />
</reference>


<reference target2="reference.RFC.1478.xml" anchor="RFC1478">
<front>
<title abbrev="IDPR Architecture">An Architecture for Inter-Domain Policy Routing</title>
<author fullname="Martha Steenstrup" initials="M." surname="Steenstrup">
<organization>BBN Systems and Technologies</organization>

<address>
<postal>
<street>10 Moulton Street</street>
<city>Cambridge</city>
<region>MA</region>
<code>02138</code>
<country>US</country>
</postal>

<phone>+1 617 873 3192</phone>
<email>msteenst@bbn.com</email>
</address>
</author>

<date year="1993" month="June" />

<abstract>
<t>We present an architecture for inter-domain policy routing (IDPR). The objective of IDPR is to construct and maintain routes, between source and destination administrative domains, that provide user traffic with the requested services within the constraints stipulated for the domains transited.  The IDPR architecture is designed to accommodate an internetwork containing tens of thousands of administrative domains with heterogeneous service requirements and restrictions.</t>
</abstract>
</front>

<seriesInfo value="1478" name="RFC" />
</reference>


<reference target2="reference.RFC.1479.xml" anchor="RFC1479">
<front>
<title abbrev="IDPR Protocol">Inter-Domain Policy Routing Protocol Specification: Version 1</title>
<author fullname="Martha Steenstrup" initials="M." surname="Steenstrup">
<organization>BBN Systems and Technologies</organization>

<address>
<postal>
<street>10 Moulton Street</street>
<city>Cambridge</city>
<region>MA</region>
<code>02138</code>
<country>US</country>
</postal>

<phone>+1 617 873 3192</phone>
<email>msteenst@bbn.com</email>
</address>
</author>

<date year="1993" month="July" />

<abstract>
<t>We present the set of protocols and procedures that constitute Inter-Domain Policy Routing (IDPR).  IDPR includes the virtual gateway protocol, the flooding protocol, the route server query protocol, the route generation procedure, the path control protocol, and the data message forwarding procedure.</t>
</abstract>
</front>

<seriesInfo value="1479" name="RFC" />
</reference>


<reference target2="reference.RFC.1480.xml" anchor="RFC1480">
<front>
<title>The US Domain</title>
<author fullname="Ann Cooper" initials="A." surname="Cooper">
<organization>USC/Information Sciences Institute</organization>

<address>
<postal>
<street>4676 Admiralty Way</street>
<city>Marina del Rey</city>
<region>CA</region>
<code>90292</code>
<country>US</country>
</postal>

<phone>+1 310 822 1511</phone>
<email>cooper@isi.edu</email>
</address>
</author>

<author fullname="Jon Postel" initials="J." surname="Postel">
<organization>USC/Information Sciences Institute</organization>

<address>
<postal>
<street>4676 Admiralty Way</street>
<city>Marina del Rey</city>
<region>CA</region>
<code>90292</code>
<country>US</country>
</postal>

<phone>+1 310 822 1511</phone>
<email>postel@isi.edu</email>
</address>
</author>

<date year="1993" month="June" />
</front>

<seriesInfo value="1480" name="RFC" />
</reference>


<reference target2="reference.RFC.1481.xml" anchor="RFC1481">
<front>
<title abbrev="IAB on CIDR">IAB Recommendation for an Intermediate Strategy to Address the Issue of Scaling</title>
<author fullname="Christian Huitema" initials="C." surname="Huitema">
<organization>INRIA, Sophia-Antipolis</organization>

<address>
<postal>
<street>2004 Route des Lucioles</street>
<street>BP 109</street>
<city>Valbonne Cedex</city>
<region />
<code>F-06561</code>
<country>FR</country>
</postal>

<phone>+33 93 657715</phone>
<email>Christian.Huitema@MIRSA.INRIA.FR</email>
</address>
</author>

<date year="1993" month="July" />
</front>

<seriesInfo value="1481" name="RFC" />
</reference>


<reference target2="reference.RFC.1482.xml" anchor="RFC1482">
<front>
<title abbrev="Routing Aggregation Support">Aggregation Support in the NSFNET Policy-Based Routing Database</title>
<author fullname="Mark A. Knopper" initials="M.A." surname="Knopper">
<organization>Merit Network, Inc.</organization>

<address>
<postal>
<street>1071 Beal Ave.</street>
<city>Ann Arbor</city>
<region>MI</region>
<code>48109-2103</code>
<country>US</country>
</postal>

<phone>+1 313 763 6061</phone>
<facsimile>+1 313 747 3745</facsimile>
<email>mak@merit.edu</email>
</address>
</author>

<author fullname="Steven J.Richardson" initials="S.J." surname="Richardson">
<organization>Merit Network, Inc.</organization>

<address>
<postal>
<street>1071 Beal Ave.</street>
<city>Ann Arbor</city>
<region>MI</region>
<code>48109-2103</code>
<country>US</country>
</postal>

<phone>+1 313 747 4813</phone>
<facsimile>+1 313 747 3745</facsimile>
<email>sjr@merit.edu</email>
</address>
</author>

<date year="1993" month="June" />

<abstract>
<t>This document describes plans for support of route aggregation, as specified in the descriptions of Classless Inter-Domain Routing (CIDR)and the BGP-4 protocol, by the NSFNET Backbone Network Service.  Mechanisms for exchange of route aggregates between the backbone service and regional/midlevel networks are specified. Additionally, the memo proposes the implementation of an Aggregate Registry which can be used by network service providers to share
   information about the use of aggregation.  Finally, the operational impact of incorporating CIDR and aggregation is considered, including an analysis of how routing table size will be affected.  This impact analysis will be used to modify the deployment plan, if necessary, to maximize operational stability.</t>
</abstract>
</front>

<seriesInfo value="1482" name="RFC" />
</reference>


<reference target2="reference.RFC.1483.xml" anchor="RFC1483">
<front>
<title abbrev="Multiprotocol over AAL5">Multiprotocol Encapsulation over ATM Adaptation Layer 5</title>
<author fullname="Juha Heinanen" initials="J." surname="Heinanen">
<organization>Telecom Finland</organization>

<address>
<postal>
<street>PO Box 228</street>
<city>Tampere</city>
<region />
<code>SF-33101</code>
<country>FI</country>
</postal>

<phone>+358 3 49500958</phone>
<email>Juha.Heinanen@datanet.tele.fi</email>
</address>
</author>

<date year="1993" month="July" />

<abstract>
<t>This memo describes two encapsulations methods for carrying network interconnect traffic over ATM AAL5.  The first method allows multiplexing of multiple protocols over a single ATM virtual circuit whereas the second method assumes that each protocol is carried over a separate ATM virtual circuit.</t>
</abstract>
</front>

<seriesInfo value="1483" name="RFC" />
</reference>


<reference target2="reference.RFC.1484.xml" anchor="RFC1484">
<front>
<title abbrev="User Friendly Naming">Using the OSI Directory to achieve User Friendly Naming (OSI-DS 24 (v1.2))</title>
<author fullname="Steve Hardcastle-Kille" initials="S." surname="Hardcastle-Kille">
<organization>ISODE Consortium</organization>

<address>
<postal>
<street>POB 505</street>
<city>London</city>
<region>England</region>
<code>SW11 1DX</code>
<country>UK</country>
</postal>

<phone>+44 71 2234062</phone>
<email>S.Kille@ISODE.COM</email>
</address>
</author>

<date year="1993" month="July" />

<abstract>
<t>The OSI Directory has user friendly naming as a goal.  A simple minded usage of the directory does not achieve this.  Two aspects not achieved are:</t>

<t>o A user oriented notation</t>

<t>o Guessability</t>

<t>This proposal sets out some conventions for representing names in a friendly manner, and shows how this can be used to achieve really friendly naming.  This then leads to a specification of a format for representing names, and to procedures to resolve them.  This leads to a specification which allows directory names to be communicated between humans.  The format in this specification is identical to that defined in [HK93], and it is intended that these specifications are compatible.  Please send comments to the author or to the discussion group: osi-ds@CS.UCL.AC.UK.</t>
</abstract>
</front>

<seriesInfo value="1484" name="RFC" />
</reference>


<reference target2="reference.RFC.1485.xml" anchor="RFC1485">
<front>
<title abbrev="Distinguished Names">A String Representation of Distinguished Names (OSI-DS 23 (v5))</title>
<author fullname="Steve Hardcastle-Kille" initials="S." surname="Hardcastle-Kille">
<organization>ISODE Consortium</organization>

<address>
<postal>
<street>POB 505</street>
<city>London</city>
<region>England</region>
<code>SW11 1DX</code>
<country>UK</country>
</postal>

<phone>+44 71 2234062</phone>
<email>S.Kille@ISODE.COM</email>
</address>
</author>

<date year="1993" month="July" />

<abstract>
<t>The OSI Directory uses distinguished names as the primary keys to entries in the directory.  Distinguished Names are encoded in ASN.1. When a distinguished name is communicated between to users not using a directory protocol (e.g., in a mail message), there is a need to have a user-oriented string representation of distinguished name.  This specification defines a string format for representing names, which is designed to give a clean representation of commonly used names, whilst being able to represent any distinguished name.  Please send comments to the author or to the discussion group &lt;osi-ds@CS.UCL.AC.UK.&gt;</t>
</abstract>
</front>

<seriesInfo value="1485" name="RFC" />
</reference>


<reference target2="reference.RFC.1486.xml" anchor="RFC1486">
<front>
<title>An Experiment in Remote Printing</title>
<author fullname="Marshall T. Rose" initials="M." surname="Rose">
<organization>Dover Beach Consulting, Inc.</organization>

<address>
<postal>
<street>420 Whisman Court</street>
<city>Mountain View</city>
<region>CA</region>
<code>94043-2186</code>
<country>US</country>
</postal>

<phone>+1 415 968 1052</phone>
<facsimile>+1 415 968 2510</facsimile>
<email>mrose@dbc.mtview.ca.us</email>
</address>
</author>

<author fullname="Carl Malamud" initials="C." surname="Malamud">
<organization>Internet Multicasting Service</organization>

<address>
<postal>
<street>The National Press Building</street>
<street>Suite 1155</street>
<city>Washington</city>
<region>DC</region>
<code>20045</code>
<country>US</country>
</postal>

<phone>+1 202 628 2044</phone>
<facsimile>+1 202 628 2042</facsimile>
<email>carl@malamud.com</email>
</address>
</author>

<date year="1993" month="July" />
</front>

<seriesInfo value="1486" name="RFC" />
</reference>


<reference target2="reference.RFC.1487.xml" anchor="RFC1487">
<front>
<title abbrev="X.500 LDAP">X.500 Lightweight Directory Access Protocol</title>
<author fullname="Wengyik Yeong" initials="W." surname="Yeong">
<organization>PSI, Inc.</organization>

<address>
<postal>
<street>510 Huntmar Park Drive</street>
<city>Herndon</city>
<region>VA</region>
<code>22070</code>
<country>US</country>
</postal>

<phone>+1 703 450 8001</phone>
<email>yeongw@psilink.com</email>
</address>
</author>

<author fullname="Tim Howes" initials="T." surname="Howes">
<organization>University of Michigan, ITD Research Systems</organization>

<address>
<postal>
<street>535 W William St.</street>
<city>Ann Arbor</city>
<region>MI</region>
<code>48103-4943</code>
<country>US</country>
</postal>

<phone>+1 313 747 4454</phone>
<email>tim@umich.edu</email>
</address>
</author>

<author fullname="Steve Kille" initials="S." surname="Kille">
<organization>ISODE Consortium</organization>

<address>
<postal>
<street>POB 505</street>
<city>London</city>
<region>England</region>
<code>SW11 1DX</code>
<country>UK</country>
</postal>

<phone>+44 71 2234062</phone>
<email>S.Kille@isode.com</email>
</address>
</author>

<date year="1993" month="July" />

<abstract>
<t>The protocol described in this document is designed to provide access to the Directory while not incurring the resource requirements of the Directory Access Protocol (DAP). This protocol is specifically targeted at simple management applications and browser applications that provide simple read/write interactive access to the Directory, and is intended to be a complement to the DAP itself.</t>

<t>Key aspects of LDAP are:</t>

<t>- Protocol elements are carried directly over TCP or other transport, bypassing much of the session/presentation overhead.</t>

<t>- Many protocol data elements are encoding as ordinary strings (e.g., Distinguished Names).</t>

<t>- A lightweight BER encoding is used to encode all protocol elements.</t>
</abstract>
</front>

<seriesInfo value="1487" name="RFC" />
</reference>


<reference target2="reference.RFC.1488.xml" anchor="RFC1488">
<front>
<title abbrev="X.500 Syntax Encoding">The X.500 String Representation of Standard Attribute Syntaxes</title>
<author fullname="Tim Howes" initials="T." surname="Howes">
<organization>University of Michigan, ITD Research Systems</organization>

<address>
<postal>
<street>535 W William St.</street>
<city>Ann Arbor</city>
<region>MI</region>
<code>48103-4943</code>
<country>US</country>
</postal>

<phone>+1 313 747 4454</phone>
<email>tim@umich.edu</email>
</address>
</author>

<author fullname="Steve Kille" initials="S." surname="Kille">
<organization>ISODE Consortium</organization>

<address>
<postal>
<street>POB 505</street>
<city>London</city>
<region>England</region>
<code>SW11 1DX</code>
<country>UK</country>
</postal>

<phone>+44 71 2234062</phone>
<email>S.Kille@isode.com</email>
</address>
</author>

<author fullname="Wengyik Yeong" initials="W." surname="Yeong">
<organization>PSI, Inc.</organization>

<address>
<postal>
<street>510 Huntmar Park Drive</street>
<city>Herndon</city>
<region>VA</region>
<code>22070</code>
<country>US</country>
</postal>

<phone>+1 703 450 8001</phone>
<email>yeongw@psilink.com</email>
</address>
</author>

<author fullname="Colin Robbins" initials="C." surname="Robbins">
<organization>NeXor Ltd</organization>

<address>
<postal>
<street>University Park</street>
<city>Nottingham</city>
<region>England</region>
<code>NG7 2RD</code>
<country>UK</country>
</postal>

</address>
</author>

<date year="1993" month="July" />

<abstract>
<t>The Lightweight Directory Access Protocol (LDAP)requires that the contents of AttributeValue fields in protocol elements be octet strings.  This document defines the requirements that must be satisfied by encoding rules used to render Directory attribute syntaxes into a form suitable for use in the LDAP, then goes on to
   define the encoding rules for the standard set of attribute syntaxes defined in,and.</t>
</abstract>
</front>

<seriesInfo value="1488" name="RFC" />
</reference>


<reference target2="reference.RFC.1489.xml" anchor="RFC1489">
<front>
<title>Registration of a Cyrillic Character Set</title>
<author fullname="Andrew A. Chernov" initials="A.A." surname="Chernov">
<organization>RELCOM Development Team</organization>

<address>
<postal>
<street />
<city>Moscow</city>
<region />
<code />
<country>RU</country>
</postal>

<email>ache@astral.msk.su</email>
</address>
</author>

<date year="1993" month="July" />
</front>

<seriesInfo value="1489" name="RFC" />
</reference>


<reference target2="reference.RFC.1490.xml" anchor="RFC1490">
<front>
<title abbrev="Multiprotocol over Frame Relay">Multiprotocol Interconnect over Frame Relay</title>
<author fullname="Terry Bradley" initials="T." surname="Bradley">
<organization>Wellfleet Communications, Inc.</organization>

<address>
<postal>
<street>15 Crosby Drive</street>
<city>Bedford</city>
<region>MA</region>
<code>01730</code>
<country>US</country>
</postal>

<phone>+1 617 280 2401</phone>
<email>tbradley@wellfleet.com</email>
</address>
</author>

<author fullname="Caralyn Brown" initials="C." surname="Brown">
<organization>Wellfleet Communications, Inc.</organization>

<address>
<postal>
<street>15 Crosby Drive</street>
<city>Bedford</city>
<region>MA</region>
<code>01730</code>
<country>US</country>
</postal>

<phone>+1 617 280 2335</phone>
<email>cbrown@wellfleet.com</email>
</address>
</author>

<author fullname="Andrew G. Malis" initials="A." surname="Malis">
<organization>Ascom Timeplex, Inc., Advanced Products Business Unit</organization>

<address>
<postal>
<street>289 Great Road</street>
<street>Suite 205</street>
<city>Acton</city>
<region>MA</region>
<code>01720</code>
<country>US</country>
</postal>

<phone>+1 508 266 4500</phone>
<email>malis_a@timeplex.com</email>
</address>
</author>

<date year="1993" month="July" />

<abstract>
<t>This memo describes an encapsulation method for carrying network interconnect traffic over a Frame Relay backbone.  It covers aspects of both Bridging and Routing.  Additionally, it describes a simple fragmentation procedure for carrying large frames over a frame relay network with a smaller MTU.</t>

<t>Systems with the ability to transfer both the encapsulation method described in this document, and others must have a priori knowledge of which virtual circuits will carry which encapsulation method and this encapsulation must only be used over virtual circuits that have been explicitly configured for its use.</t>
</abstract>
</front>

<seriesInfo value="1490" name="RFC" />
</reference>


<reference target2="reference.RFC.1491.xml" anchor="RFC1491">
<front>
<title abbrev="X.500 Advanced Usages">A Survey of Advanced Usages of X.500</title>
<author fullname="Chris Weider" initials="C." surname="Weider">
<organization />

<address>
<postal>
<street>2901 Hubbard</street>
<street>Pod G</street>
<city>Ann Arbor</city>
<region>MI</region>
<code>48105</code>
<country>US</country>
</postal>

<phone>+1 313 747 2730</phone>
<email>clw@merit.edu</email>
</address>
</author>

<author fullname="Russ Wright" initials="R." surname="Wright">
<organization>Lawrence Berkeley Laboratory</organization>

<address>
<postal>
<street>1 Cyclotron Road</street>
<city>Berkeley</city>
<region>CA</region>
<code>94720</code>
<country>US</country>
</postal>

<phone>+1 415 486 6965</phone>
<email>wright@lbl.gov</email>
</address>
</author>

<date year="1993" month="July" />

<abstract>
<t>This document is the result of a survey asking people to detail their advanced usages of X.500. It is intended to show how various organizations are using X.500 in ways which extend the view of X.500 as a "White Pages" service.  This RFC is a product of the Integrated Directory Services Working Group of the Application and User Services Areas of the IETF.</t>
</abstract>
</front>

<seriesInfo value="1491" name="RFC" />
</reference>


<reference target2="reference.RFC.1492.xml" anchor="RFC1492">
<front>
<title abbrev="TACACS">An Access Control Protocol, Sometimes Called TACACS</title>
<author fullname="Craig A. Finseth" initials="C.A." surname="Finseth">
<organization>University of Minnesota, Networking Services, Computer and Information Services</organization>

<address>
<postal>
<street>130 Lind Hall</street>
<street>207 Church St SE</street>
<city>Minneapolis</city>
<region>MN</region>
<code>55455-0134</code>
<country>US</country>
</postal>

<phone>+1 612 624 3375</phone>
<facsimile>+1 612 626 1002</facsimile>
<email>Craig.A.Finseth-1@umn.edu</email>
</address>
</author>

<date year="1993" month="July" />
</front>

<seriesInfo value="1492" name="RFC" />
</reference>


<reference target2="reference.RFC.1493.xml" anchor="RFC1493">
<front>
<title abbrev="Bridge MIB">Definitions of Managed Objects for Bridges</title>
<author fullname="Eric B. Decker" initials="E.B." surname="Decker">
<organization>cisco Systems, Inc.</organization>

<address>
<postal>
<street>1525 O'Brien Dr.</street>
<city>Menlo Park</city>
<region>CA</region>
<code>94025</code>
<country>US</country>
</postal>

<phone>+1 415 326 1941</phone>
<email>cire@cisco.com</email>
</address>
</author>

<author fullname="Paul Langille" initials="P." surname="Langille">
<organization>Digital Equipment Corporation (DEC)</organization>

<address>
<postal>
<street>Digital Drive</street>
<street>MK02-2/K03</street>
<city>Merrimack</city>
<region>NH</region>
<code>03054</code>
<country>US</country>
</postal>

<phone>+1 603 884 4045</phone>
<email>langille@edwin.enet.dec.com</email>
</address>
</author>

<author fullname="Anil Rijsinghani" initials="A." surname="Rijsinghani">
<organization>Digital Equipment Corporation (DEC)</organization>

<address>
<postal>
<street>550 King Street</street>
<city>Littleton</city>
<region>MA</region>
<code>01460</code>
<country>US</country>
</postal>

<phone>+1 508 486 6786</phone>
<email>anil@levers.enet.dec.com</email>
</address>
</author>

<author fullname="Keith McCloghrie" initials="K." surname="McCloghrie">
<organization>Hughes LAN Systems, Inc.</organization>

<address>
<postal>
<street>1225 Charleston Road</street>
<city>Mountain View</city>
<region>CA</region>
<code>94043</code>
<country>US</country>
</postal>

<phone>+1 415 966 7934</phone>
<email>kzm@hls.com</email>
</address>
</author>

<date year="1993" month="July" />

<abstract>
<t>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-1990 standard 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.</t>
</abstract>
</front>

<seriesInfo value="1493" name="RFC" />
</reference>


<reference target2="reference.RFC.1494.xml" anchor="RFC1494">
<front>
<title abbrev="X.400/MIME Body Equivalences">Equivalences between 1988 X.400 and RFC-822 Message Bodies</title>
<author fullname="Harald Tveit Alvestrand" initials="H.T." surname="Alvestrand">
<organization>SINTEF DELAB</organization>

<address>
<postal>
<street />
<city>Trondheim</city>
<region />
<code>N-7034</code>
<country>NO</country>
</postal>

<email>Harald.Alvestrand@delab.sintef.no</email>
</address>
</author>

<author fullname="Steven J. Thompson" initials="S.J." surname="Thompson">
<organization>Soft*Switch, Inc.</organization>

<address>
<postal>
<street>640 Lee Road</street>
<city>Wayne</city>
<region>PA</region>
<code>19087</code>
<country>US</country>
</postal>

<phone>+1 215 640 7556</phone>
<email>sjt@gateway.ssw.com</email>
</address>
</author>

<date year="1993" month="August" />
</front>

<seriesInfo value="1494" name="RFC" />
</reference>


<reference target2="reference.RFC.1495.xml" anchor="RFC1495">
<front>
<title abbrev="MHS/RFC-822 Message Body Mapping">Mapping between X.400 and RFC-822 Message Bodies</title>
<author fullname="Harald Tveit Alvestrand" initials="H.T." surname="Alvestrand">
<organization>SINTEF DELAB</organization>

<address>
<postal>
<street />
<city>Trondheim</city>
<region />
<code>N-7034</code>
<country>NO</country>
</postal>

<email>Harald.Alvestrand@delab.sintef.no</email>
</address>
</author>

<author fullname="Steve Kille" initials="S." surname="Kille">
<organization>ISODE Consortium</organization>

<address>
<postal>
<street>POB 505</street>
<city>London</city>
<region>England</region>
<code>SW11 1DX</code>
<country>UK</country>
</postal>

<phone>+44 71 2234062</phone>
<email>S.Kille@ISODE.COM</email>
</address>
</author>

<author fullname="Robert S. Miles" initials="R.S." surname="Miles">
<organization>Soft*Switch, Inc.</organization>

<address>
<postal>
<street>640 Lee Road</street>
<city>Wayne</city>
<region>PA</region>
<code>19087</code>
<country>US</country>
</postal>

<phone>+1 215 640 7556</phone>
<email>rsm@spyder.ssw.com</email>
</address>
</author>

<author fullname="Marshall T. Rose" initials="M.T." surname="Rose">
<organization>Dover Beach Consulting, Inc.</organization>

<address>
<postal>
<street>420 Whisman Court</street>
<city>Mountain View</city>
<region>CA</region>
<code>94043-2186</code>
<country>US</country>
</postal>

<phone>+1 415 968 1052</phone>
<facsimile>+1 415 968 2510</facsimile>
<email>mrose@dbc.mtview.ca.us</email>
</address>
</author>

<author fullname="Steven J. Thompson" initials="S.J." surname="Thompson">
<organization>Soft*Switch, Inc.</organization>

<address>
<postal>
<street>640 Lee Road</street>
<city>Wayne</city>
<region>PA</region>
<code>19087</code>
<country>US</country>
</postal>

<phone>+1 215 640 7556</phone>
<email>sjt@gateway.ssw.com</email>
</address>
</author>

<date year="1993" month="August" />
</front>

<seriesInfo value="1495" name="RFC" />
</reference>


<reference target2="reference.RFC.1496.xml" anchor="RFC1496">
<front>
<title abbrev="HARPOON">Rules for downgrading messages from X.400/88 to X.400/84 when MIME content-types are present in the messages</title>
<author fullname="Harald Tveit Alvestrand" initials="H.T." surname="Alvestrand">
<organization>SINTEF DELAB</organization>

<address>
<postal>
<street />
<city>Trondheim</city>
<region />
<code>N-7034</code>
<country>NO</country>
</postal>

<email>Harald.T.Alvestrand@delab.sintef.no</email>
</address>
</author>

<author fullname="Kevin E. Jordan" initials="K.E." surname="Jordan">
<organization>Control Data Systems, Inc.</organization>

<address>
<postal>
<street>4201 Lexington Avenue N</street>
<city>Arden Hills</city>
<region>MN</region>
<code>55126</code>
<country>US</country>
</postal>

<email>Kevin.E.Jordan@mercury.oss.arh.cpg.cdc.com</email>
</address>
</author>

<author fullname="James A. Romaguera" initials="J.A." surname="Romaguera">
<organization>NetConsult AG</organization>

<address>
<postal>
<street>Mettlendwaldweg 20a</street>
<city>Herrenschwanden</city>
<region />
<code>3037</code>
<country>CH</country>
</postal>

<email>Romaguera@netconsult.ch</email>
</address>
</author>

<date year="1993" month="August" />
</front>

<seriesInfo value="1496" name="RFC" />
</reference>


<reference target2="reference.RFC.1497.xml" anchor="RFC1497">
<front>
<title abbrev="BOOTP Extensions">BOOTP Vendor Information Extensions</title>
<author fullname="Joyce K. Reynolds" initials="J." surname="Reynolds">
<organization>University of Southern California, Information Sciences Institute</organization>

<address>
<postal>
<street>4676 Admiralty Way</street>
<city>Marina del Rey</city>
<region>CA</region>
<code>90292</code>
<country>US</country>
</postal>

<phone>+1 310 822 1511</phone>
<email>jkrey@isi.edu</email>
</address>
</author>

<date year="1993" month="August" />
</front>

<seriesInfo value="1497" name="RFC" />
</reference>


<reference target2="reference.RFC.1498.xml" anchor="RFC1498">
<front>
<title>On the Naming and Binding of Network Destinations</title>
<author fullname="Jerome H. Saltzer" initials="J.H." surname="Saltzer">
<organization>MIT, Laboratory for Computer Science</organization>

<address>
<postal>
<street>545 Technology Square</street>
<city>Cambridge</city>
<region>MA</region>
<code>02139</code>
<country>US</country>
</postal>

<phone>+1 617 253 6016</phone>
<email>Saltzer@MIT.EDU</email>
</address>
</author>

<date year="1993" month="August" />

<abstract>
<t>This brief paper offers a perspective on the subject of names of destinations in data communication networks. It suggests two ideas: First, it is helpful to distinguish among four different kinds of objects that may be named as the destination of a packet in a network.  Second, the operating system concept of binding is a useful way to describe the relations among the four kinds of objects. To illustrate the usefulness of this approach, the paper interprets some more subtle and confusing properties of two real-world network systems for naming destinations.</t>
</abstract>
</front>

<seriesInfo value="1498" name="RFC" />
</reference>


<reference target2="reference.RFC.1499.xml" anchor="RFC1499">
<front>
<title abbrev="Summary of 1400-1499">Summary of 1400-1499</title>
<author fullname="Josh Elliott" initials="J." surname="Elliott">
<organization>University of Southern California, Information Sciences Institute</organization>

<address>
<postal>
<street>4676 Admiralty Way</street>
<city>Marina del Rey</city>
<region>CA</region>
<code>90292</code>
<country>US</country>
</postal>

<phone>+1 310 822 1511</phone>
<email>elliott@isi.edu</email>
</address>
</author>

<date year="1997" month="January" />
</front>

<seriesInfo value="1499" name="RFC" />
</reference>


<reference target2="reference.RFC.1500.xml" anchor="RFC1500">
<front>
<title abbrev="Internet Standards">Internet Official Protocol Standards</title>
<author fullname="Jon Postel" initials="J." surname="Postel">
<organization>USC/Information Sciences Institute</organization>

<address>
<postal>
<street>4676 Admiralty Way</street>
<city>Marina del Rey</city>
<region>CA</region>
<code>90292</code>
<country>US</country>
</postal>

<phone>+1 310 822 1511</phone>
<facsimile>+1 310 823 6714</facsimile>
<email>Postel@ISI.EDU</email>
</address>
</author>

<date year="1993" month="August" />

<abstract>
<t></t>
</abstract>
</front>

<seriesInfo value="1500" name="RFC" />
</reference>


<reference target2="reference.RFC.1501.xml" anchor="RFC1501">
<front>
<title>OS/2 User Group</title>
<author fullname="Eric Brunsen" initials="E." surname="Brunsen">
<organization>Eastern New Mexico University</organization>

<address>
<postal>
<street>Station 15</street>
<city>Portales</city>
<region>NM</region>
<code>88130</code>
<country>US</country>
</postal>

<phone>+1 505 562 2694</phone>
<facsimile>+1 505 562 2349</facsimile>
<email>BRUNSENE@EMAIL.ENMU.EDU</email>
</address>
</author>

<date year="1993" month="August" />

<abstract>
<t></t>
</abstract>
</front>

<seriesInfo value="1501" name="RFC" />
</reference>


<reference target2="reference.RFC.1502.xml" anchor="RFC1502">
<front>
<title>X.400 Use of Extended Character Sets</title>
<author fullname="Harald Tveit Alvestrand" initials="H." surname="Alvestrand">
<organization>SINTEF DELAB</organization>

<address>
<postal>
<street />
<city>Trondheim</city>
<region />
<code>N-7034</code>
<country>NO</country>
</postal>

<email>Harald.Alvestrand@delab.sintef.no</email>
</address>
</author>

<date year="1993" month="August" />

<abstract>
<t></t>
</abstract>
</front>

<seriesInfo value="1502" name="RFC" />
</reference>


<reference target2="reference.RFC.1503.xml" anchor="RFC1503">
<front>
<title abbrev="Automating Administration in SNMPv2 Manager">Algorithms for Automating Administration in SNMPv2 Managers</title>
<author fullname="Keith McCloghrie" initials="K." surname="McCloghrie">
<organization>Hughes LAN Systems</organization>

<address>
<postal>
<street>1225 Charleston Road</street>
<city>Mountain View</city>
<region>CA</region>
<code>94043</code>
<country>US</country>
</postal>

<phone>+1 415 966 7934</phone>
<email>kzm@hls.com</email>
</address>
</author>

<author fullname="Marshall T. Rose" initials="M." surname="Rose">
<organization>Dover Beach Consulting, Inc.</organization>

<address>
<postal>
<street>420 Whisman Court</street>
<city>Mountain View</city>
<region>CA</region>
<code>94043-2186</code>
<country>US</country>
</postal>

<phone>+1 415 968 1052</phone>
<email>mrose@dbc.mtview.ca.us</email>
</address>
</author>

<date year="1993" month="August" />

<abstract>
<t></t>
</abstract>
</front>

<seriesInfo value="1503" name="RFC" />
</reference>


<reference target2="reference.RFC.1504.xml" anchor="RFC1504">
<front>
<title abbrev="Appletalk Update-Based Routing Protocol">Appletalk Update-Based Routing Protocol: Enhanced Appletalk Routing</title>
<author fullname="Alan B. Oppenheimer" initials="A." surname="Oppenheimer">
<organization>Apple Computer</organization>

<address>
<postal>
<street>20525 Mariani Avenue</street>
<street>M/S 35-K</street>
<city>Cupertino</city>
<region>CA</region>
<code>95014</code>
<country>US</country>
</postal>

<phone>+1 408 974 4744</phone>
<email>Oppenheime1@applelink.apple.com</email>
</address>
</author>

<date year="1993" month="August" />

<abstract>
<t></t>
</abstract>
</front>

<seriesInfo value="1504" name="RFC" />
</reference>


<reference target2="reference.RFC.1505.xml" anchor="RFC1505">
<front>
<title abbrev="Encoding Header Field">Encoding Header Field for Internet Messages</title>
<author fullname="Albert K. Costanzo" initials="A." surname="Costanzo">
<organization>AKC Consulting Inc.</organization>

<address>
<postal>
<street>P.O. Box 4031</street>
<city>Roselle Park</city>
<region>NJ</region>
<code>07204-0531</code>
<country>US</country>
</postal>

<phone>+1 908 298 9000</phone>
<email>AL@AKC.COM</email>
</address>
</author>

<author fullname="David Robinson" initials="D." surname="Robinson">
<organization>Computervision Corporation</organization>

<address>
<postal>
<street>100 Crosby Drive</street>
<city>Bedford</city>
<region>MA</region>
<code>01730</code>
<country>US</country>
</postal>

<phone>+1 617 275 1800 x2774</phone>
<email>DRB@Relay.CV.COM</email>
</address>
</author>

<author fullname="Robert Ullmann" initials="R." surname="Ullmann">
<organization />

<address>
<phone>+1 617 247 7959</phone>
<email>ariel@world.std.com</email>
</address>
</author>

<date year="1993" month="August" />

<abstract>
<t>This document expands upon the elective experimental Encoding header field which permits the mailing of multi-part, multi-structured messages.  It replaces RFC 1154.</t>
</abstract>
</front>

<seriesInfo value="1505" name="RFC" />
</reference>


<reference target2="reference.RFC.1506.xml" anchor="RFC1506">
<front>
<title abbrev="X.400-Internet Mail Gatewaying Tutorial">A Tutorial on Gatewaying between X.400 and Internet Mail</title>
<author fullname="Jeroen Houttuin" initials="J." surname="Houttuin">
<organization>RARE Secretariat</organization>

<address>
<postal>
<street>Singel 466-468</street>
<city>Amsterdam</city>
<region />
<code>NL-1017 AW</code>
<country>NL</country>
</postal>

<phone>+31 20 6391131</phone>
<facsimile>+31 20 6393289</facsimile>
<email>houttuin@rare.nl</email>
</address>
</author>

<date year="1993" month="August" />

<abstract>
<t></t>
</abstract>
</front>

<seriesInfo value="1506" name="RFC" />
</reference>


<reference target2="reference.RFC.1507.xml" anchor="RFC1507">
<front>
<title abbrev="DASS">DASS - Distributed Authentication Security Service</title>
<author fullname="Charles Kaufman" initials="C." surname="Kaufman">
<organization>Digital Equipment Corporation (DEC)</organization>

<address>
<postal>
<street>110 Spit Brook Road</street>
<street>ZKO3-3/U14</street>
<city>Nashua</city>
<region>NH</region>
<code>03062</code>
<country>US</country>
</postal>

<phone>+1 603 881 1495</phone>
<email>kaufman@zk3.dec.com</email>
</address>
</author>

<date year="1993" month="September" />

<abstract>
<t></t>
</abstract>
</front>

<seriesInfo value="1507" name="RFC" />
</reference>


<reference target2="reference.RFC.1508.xml" anchor="RFC1508">
<front>
<title abbrev="Generic Security Interface">Generic Security Service Application Program Interface</title>
<author fullname="John Linn" initials="J." surname="Linn">
<organization>Geer Zolot Associates</organization>

<address>
<postal>
<street>One Main St.</street>
<city>Cambridge</city>
<region>MA</region>
<code>02142</code>
<country>US</country>
</postal>

<phone>+1 617 374 3700</phone>
<email>Linn@gza.com</email>
</address>
</author>

<date year="1993" month="September" />

<abstract>
<t>This Generic Security Service Application Program Interface (GSS-API) definition 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:</t>

<t>documents defining specific parameter bindings for particular language environments</t>

<t>documents defining token formats, protocols, and procedures to be implemented in order to realize GSS-API services atop particular security mechanisms</t>
</abstract>
</front>

<seriesInfo value="1508" name="RFC" />
</reference>


<reference target2="reference.RFC.1509.xml" anchor="RFC1509">
<front>
<title abbrev="GSSAPI - Overview and C bindings">Generic Security Service API : C-bindings</title>
<author fullname="John Wray" initials="J." surname="Wray">
<organization>Digital Equipment Corporation (DEC)</organization>

<address>
<postal>
<street>550 King Street</street>
<street>LKG2-2/AA6</street>
<city>Littleton</city>
<region>MA</region>
<code>01460</code>
<country>US</country>
</postal>

<phone>+1 508 486 5210</phone>
<email>Wray@tuxedo.enet.dec.com</email>
</address>
</author>

<date year="1993" month="September" />

<abstract>
<t>This document specifies C language bindings for the Generic Security Service Application Program Interface (GSS-API), which is described at a language-independent conceptual level in other documents.</t>

<t>The Generic Security Service Application Programming Interface (GSS-API) provides security services to its callers, and is intended for implementation atop alternative 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.</t>
</abstract>
</front>

<seriesInfo value="1509" name="RFC" />
</reference>


<reference target2="reference.RFC.1510.xml" anchor="RFC1510">
<front>
<title abbrev="Kerberos">The Kerberos Network Authentication Service (V5)</title>
<author fullname="John Kohl" initials="J." surname="Kohl">
<organization>Digital Equipment Corporation (DEC)</organization>

<address>
<postal>
<street>110 Spit Brook Road</street>
<street>M/S ZKO3-3/U14</street>
<city>Nashua</city>
<region>NH</region>
<code>03062</code>
<country>US</country>
</postal>

<phone>+1 603 881 2481</phone>
<email>jtkohl@zk3.dec.com</email>
</address>
</author>

<author fullname="B. Clifford Neuman" initials="B." surname="Neuman">
<organization>USC/Information Sciences Institute</organization>

<address>
<postal>
<street>4676 Admiralty Way #1001</street>
<city>Marina del Rey</city>
<region>CA</region>
<code>90292-6695</code>
<country>US</country>
</postal>

<phone>+1 310 822 1511</phone>
<email>bcn@isi.edu</email>
</address>
</author>

<date year="1993" month="September" />

<abstract>
<t>This document gives an overview and specification of Version 5 of the protocol for the Kerberos network authentication system. Version 4, described elsewhere,is presently in production use at MIT's Project Athena, and at other Internet sites.</t>
</abstract>
</front>

<seriesInfo value="1510" name="RFC" />
</reference>


<reference target2="reference.RFC.1511.xml" anchor="RFC1511">
<front>
<title abbrev="CAT Overview">Common Authentication Technology Overview</title>
<author fullname="John Linn" initials="J." surname="Linn">
<organization>Geer Zolot Associates</organization>

<address>
<postal>
<street>One Main St.</street>
<city>Cambridge</city>
<region>MA</region>
<code>02142</code>
<country>US</country>
</postal>

<phone>+1 617 374 3700</phone>
<email>Linn@gza.com</email>
</address>
</author>

<date year="1993" month="September" />

<abstract>
<t></t>
</abstract>
</front>

<seriesInfo value="1511" name="RFC" />
</reference>


<reference target2="reference.RFC.1512.xml" anchor="RFC1512">
<front>
<title abbrev="FDDI MIB">FDDI Management Information Base</title>
<author fullname="Jeffrey D. Case" initials="J." surname="Case">
<organization>University of Tennessee, Department of Computer Science</organization>

<address>
<postal>
<street>107 Ayres Hall</street>
<city>Knoxville</city>
<region>TN</region>
<code>37996</code>
<country>US</country>
</postal>

</address>
</author>

<author fullname="Jeffrey D. Case" initials="J." surname="Case">
<organization>SNMP Research, Incorporated</organization>

<address>
<postal>
<street>3001 Kimberlin Heights Road</street>
<city>Knoxville</city>
<region>TN</region>
<code>37920</code>
<country>US</country>
</postal>

<phone>+1 615 974 5067</phone>
<email>case@CS.UTK.EDU</email>
</address>
</author>

<author fullname="Anil Rijsinghani" initials="A." surname="Rijsinghani">
<organization>Digital Equipment Corporation</organization>

<address>
<postal>
<street>295 Foster Street</street>
<city>Littleton</city>
<region>MA</region>
<code>01460-1123</code>
<country>US</country>
</postal>

<phone>+1 508 952 3520</phone>
<email>anil@levers.enet.dec.com</email>
</address>
</author>

<date year="1993" month="September" />

<abstract>
<t>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 devices which implement the FDDI based on the ANSI FDDI SMT 7.3 draft standard, which has been forwarded for publication by the X3T9.5 committee.</t>
</abstract>
</front>

<seriesInfo value="1512" name="RFC" />
</reference>


<reference target2="reference.RFC.1513.xml" anchor="RFC1513">
<front>
<title abbrev="Token Ring Extensions to RMON MIB">Token Ring Extensions to the Remote Network Monitoring MIB</title>
<author fullname="Steven Waldbusser" initials="S." surname="Waldbusser">
<organization>Carnegie Mellon University</organization>

<address>
<postal>
<street>4910 Forbes Ave.</street>
<city>Pittsburgh</city>
<region>PA</region>
<code>15213</code>
<country>US</country>
</postal>

<phone>+1 412 268 6628</phone>
<email>waldbusser@cmu.edu</email>
</address>
</author>

<date year="1993" month="September" />

<abstract>
<t>This memo defines extensions to the Remote Network Monitoring MIB for managing 802.5 Token Ring networks.</t>

<t>The Remote Network Monitoring MIB, RFC 1271, defines a framework for remote monitoring functions implemented on a network probe.  That MIB defines objects broken down into nine functional groups.  Some of those functional groups, the statistics and the history groups, have a view of the data-link layer that is specific to the media type and require specific objects to be defined for each media type.  RFC 1271 defined those specific objects necessary for Ethernet.  This companion memo defines those specific objects necessary for Token
 Ring LANs.</t>

<t>In addition, this memo defines some additional monitoring functions specifically for Token Ring.  These are defined in the Ring Station Group, the Ring Station Order Group, the Ring Station Configuration Group, and the Source Routing Statistics Group.</t>
</abstract>
</front>

<seriesInfo value="1513" name="RFC" />
</reference>


<reference target2="reference.RFC.1514.xml" anchor="RFC1514">
<front>
<title>Host Resources MIB</title>
<author fullname="Pete Grillo" initials="P." surname="Grillo">
<organization>Intel Corporation, Network Innovations</organization>

<address>
<postal>
<street>10915 NW Lost Park Drive</street>
<city>Portland</city>
<region>OR</region>
<code>97229</code>
<country>US</country>
</postal>

<phone>+1 503 526 9766</phone>
<email>pl0143@mail.psi.net</email>
</address>
</author>

<author fullname="Steven Waldbusser" initials="S." surname="Waldbusser">
<organization>Carnegie Mellon University</organization>

<address>
<postal>
<street>4910 Forbes Ave.</street>
<city>Pittsburgh</city>
<region>PA</region>
<code>15213</code>
<country>US</country>
</postal>

<phone>+1 412 268 6628</phone>
<facsimile>+1 412 268 4987</facsimile>
<email>waldbusser@cmu.edu</email>
</address>
</author>

<date year="1993" month="September" />

<abstract>
<t>This memo defines a MIB for use with managing host systems.  The term host" is construed to mean any computer that communicates with other similar computers attached to the internet and that is directly used by one or more human beings. Although this MIB does not necessarily apply to devices whose primary function is communications services (e.g., terminal servers, routers, bridges, monitoring equipment), such relevance is not explicitly precluded.  This MIB instruments attributes common to all internet hosts including, for example, both personal computers and systems that run variants of Unix.</t>
</abstract>
</front>

<seriesInfo value="1514" name="RFC" />
</reference>


<reference target2="reference.RFC.1515.xml" anchor="RFC1515">
<front>
<title abbrev="802.3 MAU MIB">Definitions of Managed Objects for IEEE 802.3 Medium Attachment Units (MAUs)</title>
<author fullname="Donna McMaster" initials="D." surname="McMaster">
<organization>SynOptics Communications, Inc.</organization>

<address>
<postal>
<street>4401 Great America Parkway</street>
<street>P.O. Box 58185</street>
<city>Santa Clara</city>
<region>CA</region>
<code>95052-8185</code>
<country>US</country>
</postal>

<phone>+1 408 764 1206</phone>
<email>mcmaster@synoptics.com</email>
</address>
</author>

<author fullname="Keith McCloghrie" initials="K." surname="McCloghrie">
<organization>Hughes LAN Systems, Inc.</organization>

<address>
<postal>
<street>1225 Charleston Road</street>
<city>Mountain View</city>
<region>CA</region>
<code>94043</code>
<country>US</country>
</postal>

<phone>+1 415 966 7934</phone>
<email>kzm@hls.com</email>
</address>
</author>

<author fullname="Sam Roberts" initials="S." surname="Roberts">
<organization>Farallon Computing, Inc.</organization>

<address>
<postal>
<street>2470 Mariner Square Loop</street>
<city>Alameda</city>
<region>CA</region>
<code>94501-1010</code>
<country>US</country>
</postal>

<phone>+1 510 814 5215</phone>
<email>sroberts@farallon.com</email>
</address>
</author>

<date year="1993" month="September" />

<abstract>
<t>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 managing IEEE 802.3 Medium Attachment Units (MAUs).</t>
</abstract>
</front>

<seriesInfo value="1515" name="RFC" />
</reference>


<reference target2="reference.RFC.1516.xml" anchor="RFC1516">
<front>
<title abbrev="802.3 Repeater MIB">Definitions of Managed Objects for IEEE 802.3 Repeater Devices</title>
<author fullname="Donna McMaster" initials="D." surname="McMaster">
<organization>SynOptics Communications, Inc.</organization>

<address>
<postal>
<street>4401 Great America Parkway</street>
<street>P.O. Box 58185</street>
<city>Santa Clara</city>
<region>CA</region>
<code>95052-8185</code>
<country>US</country>
</postal>

<phone>+1 408 764 1206</phone>
<email>mcmaster@synoptics.com</email>
</address>
</author>

<author fullname="Keith McCloghrie" initials="K." surname="McCloghrie">
<organization>Hughes LAN Systems, Inc.</organization>

<address>
<postal>
<street>1225 Charleston Road</street>
<city>Mountain View</city>
<region>CA</region>
<code>94043</code>
<country>US</country>
</postal>

<phone>+1 415 966 7934</phone>
<email>kzm@hls.com</email>
</address>
</author>

<date year="1993" month="September" />

<abstract>
<t>This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it defines objects for managing IEEE 802.3 10 Mb/second baseband repeaters, sometimes referred to as "hubs."</t>
</abstract>
</front>

<seriesInfo value="1516" name="RFC" />
</reference>


<reference target2="reference.RFC.1517.xml" anchor="RFC1517">
<front>
<title abbrev="CIDR Applicability Statement">Applicability Statement for the Implementation of Classless Inter-Domain Routing (CIDR)</title>
<author fullname="Robert M. Hinden" initials="R." surname="Hinden">
<organization>Sun Microsystems</organization>

<address>
<postal>
<street>2550 Garcia Ave</street>
<street>MS MTV5-44</street>
<city>Mountain View</city>
<region>CA</region>
<code>94043</code>
<country>US</country>
</postal>

<phone>+1 415 336 2082</phone>
<facsimile>+1 415 336 6015</facsimile>
<email>hinden@eng.sun.com</email>
</address>
</author>

<date year="1993" month="September" />

<abstract>
<t></t>
</abstract>
</front>

<seriesInfo value="1517" name="RFC" />
</reference>


<reference target2="reference.RFC.1518.xml" anchor="RFC1518">
<front>
<title abbrev="CIDR Address Allocation Architecture">An Architecture for IP Address Allocation with CIDR</title>
<author fullname="Yakov Rekhter" initials="Y." surname="Rekhter">
<organization>IBM Corporation, T.J. Watson Research Center</organization>

<address>
<postal>
<street>P.O. Box 218</street>
<city>Yorktown Heights</city>
<region>NY</region>
<code>10598</code>
<country>US</country>
</postal>

<phone>+1 914 945 3896</phone>
<email>yakov@watson.ibm.com</email>
</address>
</author>

<author fullname="Tony Li" initials="T." surname="Li">
<organization>cisco Systems, Inc.</organization>

<address>
<postal>
<street>1525 O'Brien Drive</street>
<city>Menlo Park</city>
<region>CA</region>
<code>94025</code>
<country>US</country>
</postal>

<email>tli@cisco.com</email>
</address>
</author>

<date year="1993" month="September" />

<abstract>
<t></t>
</abstract>
</front>

<seriesInfo value="1518" name="RFC" />
</reference>


<reference target2="reference.RFC.1519.xml" anchor="RFC1519">
<front>
<title abbrev="CIDR Address Strategy">Classless Inter-Domain Routing (CIDR): an Address Assignment and Aggregation Strategy</title>
<author fullname="Vince Fuller" initials="V." surname="Fuller">
<organization>BARRNet</organization>

<address>
<postal>
<street>115 Pine Hall</street>
<city>Stanford</city>
<region>CA</region>
<code>94305-4122</code>
<country>US</country>
</postal>

<email>vaf@Stanford.EDU</email>
</address>
</author>

<author fullname="Tony Li" initials="T." surname="Li">
<organization>cisco Systems, Inc.</organization>

<address>
<postal>
<street>1525 O'Brien Drive</street>
<city>Menlo Park</city>
<region>CA</region>
<code>94025</code>
<country>US</country>
</postal>

<email>tli@cisco.com</email>
</address>
</author>

<author fullname="Jessica (Jie Yun) Yu" initials="J." surname="Yu">
<organization>Merit Network, Inc.</organization>

<address>
<postal>
<street>1071 Beal Ave.</street>
<city>Ann Arbor</city>
<region>MI</region>
<code>48109</code>
<country>US</country>
</postal>

<email>jyy@merit.edu</email>
</address>
</author>

<author fullname="Kannan Varadhan" initials="K." surname="Varadhan">
<organization>OARnet</organization>

<address>
<postal>
<street>1224 Kinnear Road</street>
<city>Columbus</city>
<region>OH</region>
<code>43212</code>
<country>US</country>
</postal>

<email>kannan@oar.net</email>
</address>
</author>

<date year="1993" month="September" />

<abstract>
<t>This memo discusses strategies for address assignment of the existing IP address space with a view to conserve the address space and stem the explosive growth of routing tables in default-route-free routers.</t>
</abstract>
</front>

<seriesInfo value="1519" name="RFC" />
</reference>


<reference target2="reference.RFC.1520.xml" anchor="RFC1520">
<front>
<title abbrev="CIDR Provider Information Exchange">Exchanging Routing Information Across Provider Boundaries in the CIDR Environment</title>
<author fullname="Yakov Rekhter" initials="Y." surname="Rekhter">
<organization>IBM Corporation, T.J. Watson Research Center</organization>

<address>
<postal>
<street>P.O. Box 218</street>
<city>Yorktown Heights</city>
<region>NY</region>
<code>10598</code>
<country>US</country>
</postal>

<phone>+1 914 945 3896</phone>
<email>yakov@watson.ibm.com</email>
</address>
</author>

<author fullname="Claudio Topolcic" initials="C." surname="Topolcic">
<organization>Corporation for National Research Initiatives</organization>

<address>
<postal>
<street>1895 Preston White Drive</street>
<street>Suite 100</street>
<city>Reston</city>
<region>VA</region>
<code>22091</code>
<country>US</country>
</postal>

<phone>+1 703 620 8990</phone>
<email>topolcic@CNRI.Reston.VA.US</email>
</address>
</author>

<date year="1993" month="September" />
</front>

<seriesInfo value="1520" name="RFC" />
</reference>


<reference target2="reference.RFC.1521.xml" anchor="RFC1521">
<front>
<title abbrev="MIME">MIME (Multipurpose Internet Mail Extensions) Part One: Mechanisms for Specifying and Describing the Format of Internet Message Bodies</title>
<author fullname="Nathaniel S. Borenstein" initials="N.S." surname="Borenstein">
<organization>Bellcore</organization>

<address>
<postal>
<street>445 South St.</street>
<street>MRE 2D-296</street>
<city>Morristown</city>
<region>NJ</region>
<code>07962-1910</code>
<country>US</country>
</postal>

<phone>+1 201 829 4270</phone>
<facsimile>+1 201 829 7019</facsimile>
<email>nsb@bellcore.com</email>
</address>
</author>

<author fullname="Ned Freed" initials="N." surname="Freed">
<organization>Innosoft International, Inc.</organization>

<address>
<postal>
<street>250 West First Street</street>
<street>Suite 240</street>
<city>Claremont</city>
<region>CA</region>
<code>91711</code>
<country>US</country>
</postal>

<phone>+1 909 624 7907</phone>
<facsimile>+1 909 621 5319</facsimile>
<email></email>
</address>
</author>

<date year="1993" month="September" />

<abstract>
<t>STD 11, RFC 822 defines a message representation protocol which specifies considerable detail about message headers, but which leaves the message content, or message body, as flat ASCII text.  This document redefines the format of message bodies to allow multi-part textual and non-textual message bodies to be represented and exchanged without loss of information.  This is based on earlier work documented in RFC 934 and STD 11, RFC 1049, but extends and revises that work.  Because RFC 822 said so little about message bodies, this document is largely orthogonal to (rather than a revision of) RFC 822.</t>

<t>In particular, this document is designed to provide facilities to include multiple objects in a single message, to represent body text in character sets other than US-ASCII, to represent formatted multi- font text messages, to represent non-textual material such as images and audio fragments, and generally to facilitate later extensions defining new types of Internet mail for use by cooperating mail agents.</t>

<t>This document does NOT extend Internet mail header fields to permit anything other than US-ASCII text data.  Such extensions are the subject of a companion document.</t>

<t>This document is a revision of RFC 1341.  Significant differences from RFC 1341 are summarized in Appendix H.</t>
</abstract>
</front>

<seriesInfo value="1521" name="RFC" />
</reference>


<reference target2="reference.RFC.1522.xml" anchor="RFC1522">
<front>
<title abbrev="MIME Part Two">MIME (Multipurpose Internet Mail Extensions) Part Two: Message Header Extensions for Non-ASCII Text</title>
<author fullname="Keith Moore" initials="K." surname="Moore">
<organization>University of Tennessee</organization>

<address>
<postal>
<street>107 Ayres Hall</street>
<city>Knoxville</city>
<region>TN</region>
<code>37996-1301</code>
<country>US</country>
</postal>

<email>moore@cs.utk.edu</email>
</address>
</author>

<date year="1993" month="September" />

<abstract>
<t>This memo describes an extension to the message format defined in RFC 1521, to allow the representation of character sets other than ASCII in RFC 822 (STD 11) message headers.  The extensions described were designed to be highly compatible with existing Internet mail handling software, and to be easily implemented in mail readers that support RFC 1521.</t>
</abstract>
</front>

<seriesInfo value="1522" name="RFC" />
</reference>


<reference target2="reference.RFC.1523.xml" anchor="RFC1523">
<front>
<title abbrev="A text/enriched MIME Content-type">The text/enriched MIME Content-type</title>
<author fullname="Nathaniel S. Borenstein" initials="N." surname="Borenstein">
<organization>Bellcore</organization>

<address>
<postal>
<street>445 South St.</street>
<street>MRE 2D-296</street>
<city>Morristown</city>
<region>NJ</region>
<code>07962-1910</code>
<country>US</country>
</postal>

<phone>+1 201 829 4270</phone>
<facsimile>+1 201 829 5963</facsimile>
<email>nsb@bellcore.com</email>
</address>
</author>

<date year="1993" month="September" />

<abstract>
<t>MIME,defines a format and general framework for the representation of a wide variety of data types in Internet mail. This document defines one particular type of MIME data, the text/enriched type, a refinement of the "text/richtext" type defined in RFC 1341. The text/enriched MIME type is intended to facilitate the wider interoperation of simple enriched text across a wide variety of hardware and software platforms.</t>
</abstract>
</front>

<seriesInfo value="1523" name="RFC" />
</reference>


<reference target2="reference.RFC.1524.xml" anchor="RFC1524">
<front>
<title abbrev="Multimedia Mail Configuration">A User Agent Configuration Mechanism For Multimedia Mail Format Information</title>
<author fullname="Nathaniel S. Borenstein" initials="N.S." surname="Borenstein">
<organization>Bellcore</organization>

<address>
<postal>
<street>445 South St.</street>
<street>MRE 2D-296</street>
<city>Morristown</city>
<region>NJ</region>
<code>07962-1910</code>
<country>US</country>
</postal>

<phone>+1 201 829 4270</phone>
<facsimile>+1 201 829 7019</facsimile>
<email>nsb@bellcore.com</email>
</address>
</author>

<date year="1993" month="September" />

<abstract>
<t>This memo suggests a file format to be used to inform multiple mail reading user agent programs about the locally-installed facilities for handling mail in various formats.  The mechanism is explicitly designed to work with mail systems based Internet mail as defined by RFC's 821 (STD 10), 822 (STD 11), 934, 1049 (STD 11), 1113, and the Multipurpose Internet Mail Extensions, known as MIME.  However, with some extensions it could probably be made to work for X.400-based mail systems as well.  The format and mechanism are proposed in a manner that is generally operating-system independent.  However, certain implementation details will inevitably reflect operating system differences, some of which will have to be handled in a uniform manner for each operating system.  This memo makes such situations explicit, and, in an appendix, suggests a standard behavior under the UNIX operating system.</t>
</abstract>
</front>

<seriesInfo value="1524" name="RFC" />
</reference>


<reference target2="reference.RFC.1525.xml" anchor="RFC1525">
<front>
<title abbrev="Source Routing Bridge MIB">Definitions of Managed Objects for Source Routing Bridges</title>
<author fullname="Eric B. Decker" initials="E.B." surname="Decker">
<organization>cisco Systems, Inc.</organization>

<address>
<postal>
<street>1525 O'Brien Dr.</street>
<city>Menlo Park</city>
<region>CA</region>
<code>94025</code>
<country>US</country>
</postal>

<phone>+1 415 326 1941</phone>
<email>cire@cisco.com</email>
</address>
</author>

<author fullname="Keith McCloghrie" initials="K." surname="McCloghrie">
<organization>Hughes LAN Systems, Inc.</organization>

<address>
<postal>
<street>1225 Charleston Road</street>
<city>Mountain View</city>
<region>CA</region>
<code>94043</code>
<country>US</country>
</postal>

<phone>+1 415 966 7934</phone>
<email>kzm@hls.com</email>
</address>
</author>

<author fullname="Paul Langille" initials="P." surname="Langille">
<organization>Digital Equipment Corporation (DEC)</organization>

<address>
<postal>
<street>Digital Drive</street>
<street>MK02-2/K03</street>
<city>Merrimack</city>
<region>NH</region>
<code>03054</code>
<country>US</country>
</postal>

<phone>+1 603 884 4045</phone>
<email>langille@edwin.enet.dec.com</email>
</address>
</author>

<author fullname="Anil Rijsinghani" initials="A." surname="Rijsinghani">
<organization>Digital Equipment Corporation (DEC)</organization>

<address>
<postal>
<street>550 King Street</street>
<city>Littleton</city>
<region>MA</region>
<code>01460</code>
<country>US</country>
</postal>

<phone>+1 508 486 6786</phone>
<email>anil@levers.enet.dec.com</email>
</address>
</author>

<date year="1993" month="September" />
</front>

<seriesInfo value="1525" name="RFC" />
</reference>


<reference target2="reference.RFC.1526.xml" anchor="RFC1526">
<front>
<title abbrev="System Identifiers for TUBA">Assignment of System Identifiers for TUBA/CLNP Hosts</title>
<author fullname="David M. Piscitello" initials="D.M." surname="Piscitello">
<organization>Bell Communications Research</organization>

<address>
<postal>
<street>331 Newman Springs Road</street>
<street>NVC 1C322</street>
<city>Red Bank</city>
<region>NJ</region>
<code>07701</code>
<country>US</country>
</postal>

<email>dave@mail.bellcore.com</email>
</address>
</author>

<date year="1993" month="September" />

<abstract>
<t>This document describes conventions whereby the system identifier portion of an RFC 1237 style NSAP address may be guaranteed uniqueness within a routing domain for the purpose of autoconfiguration in TUBA/CLNP internets. The mechanism is extensible and can provide a basis for assigning system identifiers in a globally unique fashion.</t>
</abstract>
</front>

<seriesInfo value="1526" name="RFC" />
</reference>


<reference target2="reference.RFC.1527.xml" anchor="RFC1527">
<front>
<title abbrev="Cook Report on Internet">What Should We Plan Given the Dilemma of the Network?</title>
<author fullname="Gordon Cook" initials="G." surname="Cook">
<organization>COOK Report on Internet</organization>

<address>
<postal>
<street>431 Greenway Ave</street>
<city>Ewing</city>
<region>NJ</region>
<code>08618</code>
<country>US</country>
</postal>

<phone>+1 609 882 2572</phone>
<email>cook@path.net</email>
</address>
</author>

<date year="1993" month="September" />

<abstract>
<t>Early last year, as the concluding effort of an 18 month appointment at the US Congress Office of Technology Assessment (OTA), I drafted a potential policy framework for Congressional action on the National Research and Education Network (NREN).</t>

<t>The Internet community needs to be asking what the most important policy issues facing the network are.  And given agreement on any particular set of policy issues, the next thing we should be asking is, what would be some of the political choices that would follow for Congress to make?</t>

<t>It is unfortunate that this was never officially done for or by the Congress by OTA.  What we have as a result is network policy making being carried out now by the Science Subcommittee on the House side in consultation with a relatively small group of interested parties. The debate seems to be more focused on preserving turf than on any sweeping understanding of what the legislation is doing.  That is unfortunate.</t>

<t>In the hope that it may contain some useful ideas, I offer a shortened version of the suggested policy draft as information for the Internet community.</t>
</abstract>
</front>

<seriesInfo value="1527" name="RFC" />
</reference>


<reference target2="reference.RFC.1528.xml" anchor="RFC1528">
<front>
<title abbrev="Remote Printing -- Technical Procedures">Principles of Operation for the TPC.INT Subdomain: Remote Printing -- Technical Procedures</title>
<author fullname="Carl Malamud" initials="C." surname="Malamud">
<organization>Internet Multicasting Service</organization>

<address>
<postal>
<street>The National Press Building</street>
<street>Suite 1155</street>
<city>Washington</city>
<region>DC</region>
<code>20045</code>
<country>US</country>
</postal>

<phone>+1 202 628 2044</phone>
<facsimile>+1 202 628 2042</facsimile>
<email>carl@malamud.com</email>
</address>
</author>

<author fullname="Marshall T. Rose" initials="M.T." surname="Rose">
<organization>Dover Beach Consulting, Inc.</organization>

<address>
<postal>
<street>420 Whisman Court</street>
<city>Mountain View</city>
<region>CA</region>
<code>94043-2186</code>
<country>US</country>
</postal>

<phone>+1 415 968 1052</phone>
<facsimile>+1 415 968 2510</facsimile>
<email>mrose@dbc.mtview.ca.us</email>
</address>
</author>

<date year="1993" month="October" />
</front>

<seriesInfo value="1528" name="RFC" />
</reference>


<reference target2="reference.RFC.1529.xml" anchor="RFC1529">
<front>
<title abbrev="Remote Printing -- Administrative Policies">Principles of Operation for the TPC.INT Subdomain: Remote Printing -- Administrative Policies</title>
<author fullname="Carl Malamud" initials="C." surname="Malamud">
<organization>Internet Multicasting Service</organization>

<address>
<postal>
<street>The National Press Building</street>
<street>Suite 1155</street>
<city>Washington</city>
<region>DC</region>
<code>20045</code>
<country>US</country>
</postal>

<phone>+1 202 628 2044</phone>
<facsimile>+1 202 628 2042</facsimile>
<email>carl@malamud.com</email>
</address>
</author>

<author fullname="Marshall T. Rose" initials="M.T." surname="Rose">
<organization>Dover Beach Consulting, Inc.</organization>

<address>
<postal>
<street>420 Whisman Court</street>
<city>Mountain View</city>
<region>CA</region>
<code>94043-2186</code>
<country>US</country>
</postal>

<phone>+1 415 968 1052</phone>
<facsimile>+1 415 968 2510</facsimile>
<email>mrose@dbc.mtview.ca.us</email>
</address>
</author>

<date year="1993" month="October" />
</front>

<seriesInfo value="1529" name="RFC" />
</reference>


<reference target2="reference.RFC.1530.xml" anchor="RFC1530">
<front>
<title abbrev="General Principles and Policy">Principles of Operation for the TPC.INT Subdomain: General Principles and Policy</title>
<author fullname="Carl Malamud" initials="C." surname="Malamud">
<organization>Internet Multicasting Service</organization>

<address>
<postal>
<street>The National Press Building</street>
<street>Suite 1155</street>
<city>Washington</city>
<region>DC</region>
<code>20045</code>
<country>US</country>
</postal>

<phone>+1 202 628 2044</phone>
<facsimile>+1 202 628 2042</facsimile>
<email>carl@malamud.com</email>
</address>
</author>

<author fullname="Marshall T. Rose" initials="M." surname="Rose">
<organization>Dover Beach Consulting, Inc.</organization>

<address>
<postal>
<street>420 Whisman Court</street>
<city>Mountain View</city>
<region>CA</region>
<code>94043-2186</code>
<country>US</country>
</postal>

<phone>+1 415 968 1052</phone>
<facsimile>+1 415 968 2510</facsimile>
<email>mrose@dbc.mtview.ca.us</email>
</address>
</author>

<date year="1993" month="October" />

<abstract>
<t>This document defines the initial principles of operation for the tpc.int subdomain, a collection of service listings accessible over the Internet infrastructure through an administered namespace contained within the Domain Name System,.</t>

<t>This document is informational and applies only to those Internet sites that choose to register themselves within the tpc.int subdomain.  The tpc.int subdomain is organized as a cooperative of the sites that provide access within the context of the subdomain. Policy for the subdomain is set by a board responsible to the cooperative.</t>

<t>The primary purpose of the tpc.int subdomain is to provide transparent mapping between general-purpose computers on the Internet and special-purpose devices directly connected to the telephone network.  Initially, a remote printing service is defined,which ties together G3-compatible facsimile devices on the telephone network with users of electronic mail in the Internet and associated message-handling domains connected to the Internet by application-layer gateways.</t>

<t>It should be noted that remote printer gateways have long been technically feasible and have become an integral part of many individual networks.  The tpc.int subdomain integrates individual sites into a common namespace, transforming remote printing from a single-site, value-added service into an integral transparent service in the global Internet.</t>
</abstract>
</front>

<seriesInfo value="1530" name="RFC" />
</reference>


<reference target2="reference.RFC.1531.xml" anchor="RFC1531">
<front>
<title>Dynamic Host Configuration Protocol</title>
<author fullname="Ralph Droms" initials="R." surname="Droms">
<organization>Bucknell University, Computer Science Department</organization>

<address>
<postal>
<street>323 Dana Engineering</street>
<city>Lewisburg</city>
<region>PA</region>
<code>17837</code>
<country>US</country>
</postal>

<phone>+1 717 524 1145</phone>
<email>droms@bucknell.edu</email>
</address>
</author>

<date year="1993" month="October" />

<abstract>
<t>The Dynamic Host Configuration Protocol (DHCP) provides a framework for passing configuration information to hosts on a TCP/IP network. DHCP is based on the Bootstrap Protocol (BOOTP), adding the capability of automatic allocation of reusable network addresses and additional configuration options.  DHCP captures the behavior of BOOTP relay agents, [23] and DHCP participants can interoperate with BOOTP participants.</t>
</abstract>
</front>

<seriesInfo value="1531" name="RFC" />
</reference>


<reference target2="reference.RFC.1532.xml" anchor="RFC1532">
<front>
<title abbrev="Clarifications and Extensions for BOOTP">Clarifications and Extensions for the Bootstrap Protocol</title>
<author fullname="Walt Wimer" initials="W." surname="Wimer">
<organization>Carnegie Mellon University, Network Development</organization>

<address>
<postal>
<street>5000 Forbes Avenue</street>
<city>Pittsburgh</city>
<region>PA</region>
<code>15213-3890</code>
<country>US</country>
</postal>

<phone>+1 412 268 6252</phone>
<email>Walter.Wimer@CMU.EDU</email>
</address>
</author>

<date year="1993" month="October" />

<abstract>
<t>Some aspects of the BOOTP protocol were rather loosely defined in its original specification.  In particular, only a general description was provided for the behavior of "BOOTP relay agents" (originally called BOOTP forwarding agents").  The client behavior description also suffered in certain ways.  This memo attempts to clarify and strengthen the specification in these areas.</t>

<t>In addition, new issues have arisen since the original specification was written.  This memo also attempts to address some of these.</t>
</abstract>
</front>

<seriesInfo value="1532" name="RFC" />
</reference>


<reference target2="reference.RFC.1533.xml" anchor="RFC1533">
<front>
<title>DHCP Options and BOOTP Vendor Extensions</title>
<author fullname="Steve Alexander" initials="S." surname="Alexander">
<organization>Lachman Technology, Inc.</organization>

<address>
<postal>
<street>1901 North Naper Boulevard</street>
<city>Naperville</city>
<region>IL</region>
<code>60563-8895</code>
<country>US</country>
</postal>

<phone>+1 708 505 9555 x256</phone>
<email>stevea@lachman.com</email>
</address>
</author>

<author fullname="Ralph Droms" initials="R." surname="Droms">
<organization>Bucknell University, Computer Science Department</organization>

<address>
<postal>
<street>323 Dana Engineering</street>
<city>Lewisburg</city>
<region>PA</region>
<code>17837</code>
<country>US</country>
</postal>

<phone>+1 717 524 1145</phone>
<email>droms@bucknell.edu</email>
</address>
</author>

<date year="1993" month="October" />

<abstract>
<t>The Dynamic Host Configuration Protocol (DHCP)provides a framework for passing configuration information to hosts on a TCP/IP network.  Configuration parameters and other control information are carried in tagged data items that are stored in the "options" field of the DHCP message.  The data items themselves are also called "options."</t>

<t>This document specifies the current set of DHCP options.  This document will be periodically updated as new options are defined. Each superseding document will include the entire current list of valid options.</t>

<t>All of the vendor information extensions defined in RFC 1497may be used as DHCP options.  The definitions given in RFC 1497 are included in this document, which supersedes RFC 1497.  All of the DHCP options defined in this document, except for those specific to DHCP as defined in section 9, may be used as BOOTP vendor information extensions.</t>
</abstract>
</front>

<seriesInfo value="1533" name="RFC" />
</reference>


<reference target2="reference.RFC.1534.xml" anchor="RFC1534">
<front>
<title>Interoperation Between DHCP and BOOTP</title>
<author fullname="Ralph Droms" initials="R." surname="Droms">
<organization>Bucknell University, Computer Science Department</organization>

<address>
<postal>
<street>323 Dana Engineering</street>
<city>Lewisburg</city>
<region>PA</region>
<code>17837</code>
<country>US</country>
</postal>

<phone>+1 717 524 1145</phone>
<email>droms@bucknell.edu</email>
</address>
</author>

<date year="1993" month="October" />

<abstract>
<t>DHCP provides a superset of the functions provided by BOOTP. This document describes the interactions between DHCP and BOOTP network participants.</t>
</abstract>
</front>

<seriesInfo value="1534" name="RFC" />
</reference>


<reference target2="reference.RFC.1535.xml" anchor="RFC1535">
<front>
<title abbrev="DNS Software Enhancements">A Security Problem and Proposed Correction With Widely Deployed DNS Software</title>
<author fullname="Ehud Gavron" initials="E." surname="Gavron">
<organization>ACES Research Inc.</organization>

<address>
<postal>
<street>PO Box 14546</street>
<city>Tucson</city>
<region>AZ</region>
<code>85711</code>
<country>US</country>
</postal>

<phone>+1 602 743 9841</phone>
<email>gavron@aces.com</email>
</address>
</author>

<date year="1993" month="October" />

<abstract>
<t>This document discusses a flaw in some of the currently distributed name resolver clients.  The flaw exposes a security weakness related to the search heuristic invoked by these same resolvers when users provide a partial domain name, and which is easy to exploit (although not by the masses).  This document points out the flaw, a case in point, and a solution.</t>
</abstract>
</front>

<seriesInfo value="1535" name="RFC" />
</reference>


<reference target2="reference.RFC.1536.xml" anchor="RFC1536">
<front>
<title abbrev="Common DNS Implementation Errors">Common DNS Implementation Errors and Suggested Fixes</title>
<author fullname="Anant Kumar" initials="A." surname="Kumar">
<organization>USC Information Sciences Institute</organization>

<address>
<postal>
<street>4676 Admiralty Way</street>
<city>Marina del Rey</city>
<region>CA</region>
<code>90292-6695</code>
<country>US</country>
</postal>

<phone>+1 310 822 1511</phone>
<facsimile>+1 310 823 6741</facsimile>
<email>anant@isi.edu</email>
</address>
</author>

<author fullname="Jon Postel" initials="J." surname="Postel">
<organization>USC Information Sciences Institute</organization>

<address>
<postal>
<street>4676 Admiralty Way</street>
<city>Marina del Rey</city>
<region>CA</region>
<code>90292-6695</code>
<country>US</country>
</postal>

<phone>+1 310 822 1511</phone>
<facsimile>+1 310 823 6714</facsimile>
<email>postel@isi.edu</email>
</address>
</author>

<author fullname="Cliff Neuman" initials="C." surname="Neuman">
<organization>USC Information Sciences Institute</organization>

<address>
<postal>
<street>4676 Admiralty Way</street>
<city>Marina del Rey</city>
<region>CA</region>
<code>90292-6695</code>
<country>US</country>
</postal>

<phone>+1 310 822 1511</phone>
<facsimile>+1 310 823 6714</facsimile>
<email>bcn@isi.edu</email>
</address>
</author>

<author fullname="Peter Danzig" initials="P." surname="Danzig">
<organization>University of Southern California, Computer Science Department</organization>

<address>
<postal>
<street>University Park</street>
<city>Los Angeles</city>
<region>CA</region>
<code>90089</code>
<country>US</country>
</postal>

<email>danzig@caldera.usc.edu</email>
</address>
</author>

<author fullname="Steve Miller" initials="S." surname="Miller">
<organization>University of Southern California, Computer Science Department</organization>

<address>
<postal>
<street>University Park</street>
<city>Los Angeles</city>
<region>CA</region>
<code>90089</code>
<country>US</country>
</postal>

<email>smiller@caldera.usc.edu</email>
</address>
</author>

<date year="1993" month="October" />

<abstract>
<t>This memo describes common errors seen in DNS implementations and suggests some fixes. Where applicable, violations of recommendations from STD 13, RFC 1034 and STD 13, RFC 1035 are mentioned. The memo also describes, where relevant, the algorithms followed in BIND (versions 4.8.3 and 4.9 which the authors referred to) to serve as an example.</t>
</abstract>
</front>

<seriesInfo value="1536" name="RFC" />
</reference>


<reference target2="reference.RFC.1537.xml" anchor="RFC1537">
<front>
<title>Common DNS Data File Configuration Errors</title>
<author fullname="Piet Beertema" initials="P." surname="Beertema">
<organization>CWI</organization>

<address>
<postal>
<street>Kruislaan 413</street>
<city>Amsterdam</city>
<region />
<code>NL-1098 SJ</code>
<country>NL</country>
</postal>

<phone>+31 20 5924112</phone>
<facsimile>+31 20 5924199</facsimile>
<email>Piet.Beertema@cwi.nl</email>
</address>
</author>

<date year="1993" month="October" />

<abstract>
<t>This memo describes errors often found in DNS data files. It points out common mistakes system administrators tend to make and why they often go unnoticed for long periods of time.</t>
</abstract>
</front>

<seriesInfo value="1537" name="RFC" />
</reference>


<reference target2="reference.RFC.1538.xml" anchor="RFC1538">
<front>
<title abbrev="Advanced SNA/IP">Advanced SNA/IP : A Simple SNA Transport Protocol</title>
<author fullname="Wilfred Behl" initials="W." surname="Behl">
<organization>McDATA Corporation</organization>

<address>
<postal>
<street>310 Interlocken Parkway</street>
<city>Broomfield</city>
<region>CO</region>
<code>80021</code>
<country>US</country>
</postal>

<phone>+1 303 460 4142</phone>
<email>wil@mcdata.com</email>
</address>
</author>

<author fullname="Barbara Sterling" initials="B." surname="Sterling">
<organization>McDATA Corporation</organization>

<address>
<postal>
<street>310 Interlocken Parkway</street>
<city>Broomfield</city>
<region>CO</region>
<code>80021</code>
<country>US</country>
</postal>

<phone>+1 303 460 4211</phone>
<email>bjs@mcdata.com</email>
</address>
</author>

<author fullname="William Teskey" initials="W." surname="Teskey">
<organization>I/O Concepts</organization>

<address>
<postal>
<street>2125 112th Ave. North East</street>
<street>Suite 303</street>
<city>Bellevue</city>
<region>WA</region>
<code>98004</code>
<country>US</country>
</postal>

<phone>+1 206 450 0650</phone>
<email>wct@ioc-sea.com</email>
</address>
</author>

<date year="1993" month="October" />

<abstract>
<t>This RFC provides information for the Internet community about a method for establishing and maintaining SNA sessions over an IP internet.  While the issues discussed may not be directly relevant to the research problems of the Internet, they may be interesting to a number of researchers and implementors.  Any questions or comments relative to the contents of this RFC may be sent to the following Internet address: snaip@mcdata.com.</t>
</abstract>
</front>

<seriesInfo value="1538" name="RFC" />
</reference>


<reference target2="reference.RFC.1539.xml" anchor="RFC1539">
<front>
<title abbrev="The Tao of IETF">The Tao of IETF - A Guide for New Attendees of the Internet Engineering Task Force</title>
<author fullname="Gary Scott Malkin" initials="G.S." surname="Malkin">
<organization>Xylogics, Inc.</organization>

<address>
<postal>
<street>53 Third Avenue</street>
<city>Burlington</city>
<region>MA</region>
<code>01803</code>
<country>US</country>
</postal>

<phone>+1 617 272 8140</phone>
<email>gmalkin@Xylogics.COM</email>
</address>
</author>

<date year="1993" month="October" />

<abstract>
<t>Over the last two years, the attendance at Internet Engineering Task Force (IETF) Plenary meetings has grown phenomenally.  Approximately 38% of the attendees are new to the IETF at each meeting.  About 33% of those go on to become regular attendees.  When the meetings were smaller, it wasn't very difficult for a newcomer to get to know people and get into the swing of things.  Today, however, a newcomer meets many more new people, some previously known only as the authors of Request For Comments (RFC) documents or thought provoking email messages.</t>

<t>The purpose of this For Your Information (FYI) RFC is to explain to the newcomers how the IETF works.  This will give them a warm, fuzzy feeling and enable them to make the meeting more productive for everyone.  This FYI will also provide the mundane bits of information which everyone who attends an IETF meeting should know.</t>
</abstract>
</front>

<seriesInfo value="1539" name="RFC" />
</reference>


<reference target2="reference.RFC.1540.xml" anchor="RFC1540">
<front>
<title abbrev="Internet Standards">Internet Official Protocol Standards</title>
<author fullname="Jon Postel" initials="J." surname="Postel">
<organization>USC/Information Sciences Institute</organization>

<address>
<postal>
<street>4676 Admiralty Way</street>
<city>Marina del Rey</city>
<region>CA</region>
<code>90292</code>
<country>US</country>
</postal>

<phone>+1 310 822 1511</phone>
<facsimile>+1 310 823 6714</facsimile>
<email>Postel@ISI.EDU</email>
</address>
</author>

<date year="1993" month="October" />

<abstract>
<t></t>
</abstract>
</front>

<seriesInfo value="1540" name="RFC" />
</reference>


<reference target2="reference.RFC.1541.xml" anchor="RFC1541">
<front>
<title>Dynamic Host Configuration Protocol</title>
<author fullname="Ralph Droms" initials="R." surname="Droms">
<organization>Bucknell University, Computer Science Department</organization>

<address>
<postal>
<street>323 Dana Engineering</street>
<city>Lewisburg</city>
<region>PA</region>
<code>17837</code>
<country>US</country>
</postal>

<phone>+1 717 524 1145</phone>
<email>droms@bucknell.edu</email>
</address>
</author>

<date year="1993" month="October" />

<abstract>
<t>The Dynamic Host Configuration Protocol (DHCP) provides a framework for passing configuration information to hosts on a TCP/IP network. DHCP is based on the Bootstrap Protocol (BOOTP), adding the capability of automatic allocation of reusable network addresses and additional configuration options.  DHCP captures the behavior of BOOTP relay agents, [23], and DHCP participants can interoperate with BOOTP participants.  Due to some errors introduced into RFC 1531 in the editorial process, this memo is reissued as RFC 1541.</t>
</abstract>
</front>

<seriesInfo value="1541" name="RFC" />
</reference>


<reference target2="reference.RFC.1542.xml" anchor="RFC1542">
<front>
<title abbrev="Clarifications and Extensions for BOOTP">Clarifications and Extensions for the Bootstrap Protocol</title>
<author fullname="Walt Wimer" initials="W." surname="Wimer">
<organization>Carnegie Mellon University, Network Development</organization>

<address>
<postal>
<street>5000 Forbes Avenue</street>
<city>Pittsburgh</city>
<region>PA</region>
<code>15213-3890</code>
<country>US</country>
</postal>

<phone>+1 412 268 6252</phone>
<email>Walter.Wimer@CMU.EDU</email>
</address>
</author>

<date year="1993" month="October" />

<abstract>
<t>Some aspects of the BOOTP protocol were rather loosely defined in its original specification.  In particular, only a general description was provided for the behavior of "BOOTP relay agents" (originally called BOOTP forwarding agents").  The client behavior description also suffered in certain ways.  This memo attempts to clarify and strengthen the specification in these areas.  Due to some errors introduced into RFC 1532 in the editorial process, this memo is reissued as RFC 1542.</t>

<t>In addition, new issues have arisen since the original specification was written.  This memo also attempts to address some of these.</t>
</abstract>
</front>

<seriesInfo value="1542" name="RFC" />
</reference>


<reference target2="reference.RFC.1543.xml" anchor="RFC1543">
<front>
<title>Instructions to RFC Authors</title>
<author fullname="Jon Postel" initials="J." surname="Postel">
<organization>USC/Information Sciences Institute</organization>

<address>
<postal>
<street>4676 Admiralty Way</street>
<city>Marina del Rey</city>
<region>CA</region>
<code>90292</code>
<country>US</country>
</postal>

<phone>+1 310 822 1511</phone>
<facsimile>+1 310 823 6714</facsimile>
<email>Postel@ISI.EDU</email>
</address>
</author>

<date year="1993" month="October" />

<abstract>
<t></t>
</abstract>
</front>

<seriesInfo value="1543" name="RFC" />
</reference>


<reference target2="reference.RFC.1544.xml" anchor="RFC1544">
<front>
<title abbrev="Content-MD5 Header Field">The Content-MD5 Header Field</title>
<author fullname="Marshall T. Rose" initials="M." surname="Rose">
<organization>Dover Beach Consulting, Inc.</organization>

<address>
<postal>
<street>420 Whisman Court</street>
<city>Mountain View</city>
<region>CA</region>
<code>94043-2112</code>
<country>US</country>
</postal>

<phone>+1 415 968 1052</phone>
<email>mrose@dbc.mtview.ca.us</email>
</address>
</author>

<date year="1993" month="November" />

<abstract>
<t>This memo specifies an optional header field, Content-MD5, for use with MIME-conformant messages.</t>
</abstract>
</front>

<seriesInfo value="1544" name="RFC" />
</reference>


<reference target2="reference.RFC.1545.xml" anchor="RFC1545">
<front>
<title abbrev="FTP Over Big Address">FTP Operation Over Big Address Records (FOOBAR)</title>
<author fullname="David M. Piscitello" initials="D." surname="Piscitello">
<organization>Bell Communications Research</organization>

<address>
<postal>
<street>331 Newman Springs Road</street>
<street>NVC 1C322</street>
<city>Red Bank</city>
<region>NJ</region>
<code>07701</code>
<country>US</country>
</postal>

<email>dave@mail.bellcore.com</email>
</address>
</author>

<date year="1993" month="November" />

<abstract>
<t>This paper describes a convention for specifying longer addresses in the PORT command.</t>
</abstract>
</front>

<seriesInfo value="1545" name="RFC" />
</reference>


<reference target2="reference.RFC.1546.xml" anchor="RFC1546">
<front>
<title>Host Anycasting Service</title>
<author fullname="Craig Partridge" initials="C." surname="Partridge">
<organization>Bolt Beranek and Newman</organization>

<address>
<postal>
<street>10 Moulton St</street>
<city>Cambridge</city>
<region>MA</region>
<code>02138</code>
<country>US</country>
</postal>

<email>craig@bbn.com</email>
</address>
</author>

<author fullname="Trevor Mendez" initials="T." surname="Mendez">
<organization>Bolt Beranek and Newman</organization>

<address>
<postal>
<street>10 Moulton St</street>
<city>Cambridge</city>
<region>MA</region>
<code>02138</code>
<country>US</country>
</postal>

<email>tmendez@bbn.com</email>
</address>
</author>

<author fullname="Walter Milliken" initials="W." surname="Milliken">
<organization>Bolt Beranek and Newman</organization>

<address>
<postal>
<street>10 Moulton St</street>
<city>Cambridge</city>
<region>MA</region>
<code>02138</code>
<country>US</country>
</postal>

<email>milliken@bbn.com</email>
</address>
</author>

<date year="1993" month="November" />

<abstract>
<t>This RFC describes an internet anycasting service for IP.  The primary purpose of this memo is to establish the semantics of an anycasting service within an IP internet.  Insofar as is possible, this memo tries to be agnostic about how the service is actually provided by the internetwork.  This memo describes an experimental service and does not propose a protocol.  This memo is produced by the Internet Research Task Force (IRTF).</t>
</abstract>
</front>

<seriesInfo value="1546" name="RFC" />
</reference>


<reference target2="reference.RFC.1547.xml" anchor="RFC1547">
<front>
<title abbrev="Point-to-Point Protocol Requirements">Requirements for an Internet Standard Point-to-Point Protocol</title>
<author fullname="Drew Perkins" initials="D." surname="Perkins">
<organization>Carnegie Mellon University</organization>

<address>
<postal>
<street>4015 Holiday Park Drive</street>
<city>Murrysville</city>
<region>PA</region>
<code>15668</code>
<country>US</country>
</postal>

<email>perkins+@cmu.edu</email>
</address>
</author>

<date year="1993" month="December" />

<abstract>
<t>This document discusses the evaluation criteria for an Internet Standard Data Link Layer protocol to be used with point-to-point links.  Although many industry standard protocols and ad hoc protocols already exist for the data link layer, none are both complete and sufficiently versatile to be accepted as an Internet Standard.  In preparation to designing such a protocol, the features necessary to qualify a point-to-point protocol as an Internet Standard are discussed in detail.  An analysis of the strengths and weaknesses of several existing protocols on the basis of these requirements demonstrates the failure of each to address key issues.</t>

<t>Historical Note: This was the design requirements document dated June 1989, which was followed for RFC-1134 through the present. It is now published for completeness and future guidance.</t>
</abstract>
</front>

<seriesInfo value="1547" name="RFC" />
</reference>


<reference target2="reference.RFC.1548.xml" anchor="RFC1548">
<front>
<title abbrev="The Point-to-Point Protocol">The Point-to-Point Protocol (PPP)</title>
<author fullname="William Allen Simpson" initials="W." surname="Simpson">
<organization>Daydreamer, Computer Systems Consulting Services</organization>

<address>
<postal>
<street>1384 Fontaine</street>
<city>Madison Heights</city>
<region>MI</region>
<code>48071</code>
<country>US</country>
</postal>

<email>Bill.Simpson@um.cc.umich.edu</email>
</address>
</author>

<date year="1993" month="December" />

<abstract>
<t>The Point-to-Point Protocol (PPP) provides a standard method for transporting multi-protocol datagrams over point-to-point links.  PPP is comprised of three main components:</t>

<t>1. A method for encapsulating multi-protocol datagrams.</t>

<t>2. A Link Control Protocol (LCP) for establishing, configuring, and testing the data-link connection.</t>

<t>3. A family of Network Control Protocols (NCPs) for establishing and configuring different network-layer protocols.</t>

<t>This document defines the PPP organization and methodology, and the PPP encapsulation, together with an extensible option negotiation mechanism which is able to negotiate a rich assortment of configuration parameters and provides additional management functions.  The PPP Link Control Protocol (LCP) is described in terms of this mechanism.</t>

<t>This document is the product of the Point-to-Point Protocol Working Group of the Internet Engineering Task Force (IETF).  Comments should be submitted to the ietf-ppp@ucdavis.edu mailing list.</t>
</abstract>
</front>

<seriesInfo value="1548" name="RFC" />
</reference>


<reference target2="reference.RFC.1549.xml" anchor="RFC1549">
<front>
<title abbrev="HDLC Framing">PPP in HDLC Framing</title>
<author fullname="William Allen Simpson" initials="W." surname="Simpson">
<organization>Daydreamer, Computer Systems Consulting Services</organization>

<address>
<postal>
<street>1384 Fontaine</street>
<city>Madison Heights</city>
<region>MI</region>
<code>48071</code>
<country>US</country>
</postal>

<email>Bill.Simpson@um.cc.umich.edu</email>
</address>
</author>

<date year="1993" month="December" />

<abstract>
<t>The Point-to-Point Protocol (PPP)provides a standard method for transporting multi-protocol datagrams over point-to-point links.</t>

<t>This document describes the use of HDLC for framing PPP encapsulated packets. This document is the product of the Point-to-Point Protocol Working Group of the Internet Engineering Task Force (IETF). Comments should be submitted to the ietf-ppp@ucdavis.edu mailing
   list.</t>
</abstract>
</front>

<seriesInfo value="1549" name="RFC" />
</reference>


<reference target2="reference.RFC.1550.xml" anchor="RFC1550">
<front>
<title abbrev="IPng White Paper Solicitation">IP: Next Generation (IPng) White Paper Solicitation</title>
<author fullname="Scott Bradner" initials="S." surname="Bradner">
<organization>Harvard University</organization>

<address>
<postal>
<street>10 Ware St.</street>
<city>Cambridge</city>
<region>MA</region>
<code>02138</code>
<country>US</country>
</postal>

<phone>+1 617 495 3864</phone>
<email>sob@harvard.edu</email>
</address>
</author>

<author fullname="Allison Mankin" initials="A." surname="Mankin">
<organization>Naval Research Laboratory</organization>

<address>
<postal>
<street>Code 5591</street>
<city>Washington</city>
<region>DC</region>
<code>20375-5000</code>
<country>US</country>
</postal>

<phone>+1 202 404 7030</phone>
<email>mankin@cmf.nrl.navy.mil</email>
</address>
</author>

<date year="1993" month="December" />

<abstract>
<t></t>
</abstract>
</front>

<seriesInfo value="1550" name="RFC" />
</reference>


<reference target2="reference.RFC.1551.xml" anchor="RFC1551">
<front>
<title abbrev="IPXWAN">Novell IPX Over Various WAN Media (IPXWAN)</title>
<author fullname="Michael Allen" initials="M." surname="Allen">
<organization>Novell, Inc.</organization>

<address>
<postal>
<street>2180 Fortune Drive</street>
<city>San Jose</city>
<region>CA</region>
<code>95131</code>
<country>US</country>
</postal>

<email>mallen@novell.com</email>
</address>
</author>

<date year="1993" month="December" />

<abstract>
<t>This document describes how Novell IPX operates over various WAN media.  Specifically, it describes the common "IPX WAN" protocol Novell uses to exchange necessary router to router information prior to exchanging standard IPX routing information and traffic over WAN datalinks. This document supercedes RFC 1362 and adds capability for Unnumbered RIP links, On-demand statically routed links and client to router connectivity.</t>
</abstract>
</front>

<seriesInfo value="1551" name="RFC" />
</reference>


<reference target2="reference.RFC.1552.xml" anchor="RFC1552">
<front>
<title abbrev="PPP IPXCP">The PPP Internetworking Packet Exchange Control Protocol (IPXCP)</title>
<author fullname="William Allen Simpson" initials="W." surname="Simpson">
<organization>Daydreamer, Computer Systems Consulting Services</organization>

<address>
<postal>
<street>P O Box 6205</street>
<city>East Lansing</city>
<region>MI</region>
<code>48826-6205</code>
<country>US</country>
</postal>

<email>Bill.Simpson@um.cc.umich.edu</email>
</address>
</author>

<date year="1993" month="December" />

<abstract>
<t>The Point-to-Point Protocol (PPP)provides a method for transmitting multi-protocol datagrams over point-to-point links.  PPP defines an extensible Link Control Protocol, and proposes a family of Network Control Protocols for establishing and configuring different network-layer protocols.</t>

<t>The IPX protocol was originally used in Novell's NetWare products, and is now supported by numerous other vendors.  This document defines the Network Control Protocol for establishing and configuring the IPX protocol over PPP.</t>

<t>This memo is the product of the Point-to-Point Protocol Working Group of the IETF.  Comments should be submitted to the ietf-ppp@ucdavis.edu mailing list.</t>
</abstract>
</front>

<seriesInfo value="1552" name="RFC" />
</reference>


<reference target2="reference.RFC.1553.xml" anchor="RFC1553">
<front>
<title abbrev="CIPX">Compressing IPX Headers Over WAN Media (CIPX)</title>
<author fullname="Saroop Mathur" initials="S." surname="Mathur">
<organization>Telebit Corp.</organization>

<address>
<postal>
<street>1315 Chesapeake Terrace</street>
<city>Sunnyvale</city>
<region>CA</region>
<code>94089-1100</code>
<country>US</country>
</postal>

<email>mathur@telebit.com</email>
</address>
</author>

<author fullname="Mark S. Lewis" initials="M." surname="Lewis">
<organization>Telebit Corp.</organization>

<address>
<postal>
<street>1315 Chesapeake Terrace</street>
<city>Sunnyvale</city>
<region>CA</region>
<code>94089-1100</code>
<country>US</country>
</postal>

<email>Mark.S.Lewis@telebit.com</email>
</address>
</author>

<date year="1993" month="December" />

<abstract>
<t>This document describes a method for compressing the headers of IPX datagrams (CIPX).  With this method, it is possible to significantly improve performance over lower speed wide area network (WAN) media.  For normal IPX packet traffic, CIPX can provide a compression ratio of approximately 2:1 including both IPX header and data.  This method can be used on various type of WAN media, including those supporting PPP and X.25.</t>

<t>This memo ia a product of the Point-to-Point Protocol Extensions (PPPEXT) Working Group of the IETF.  Comments should be sent to the authors and the ietf-ppp@ucdavis.edu mailing list.</t>
</abstract>
</front>

<seriesInfo value="1553" name="RFC" />
</reference>


<reference target2="reference.RFC.1554.xml" anchor="RFC1554">
<front>
<title abbrev="Multilingual Extension of ISO-2022-JP">ISO-2022-JP-2: Multilingual Extension of ISO-2022-JP</title>
<author fullname="Masataka Ohta" initials="M." surname="Ohta">
<organization>Tokyo Institute of Technology</organization>

<address>
<postal>
<street>2-12-1, O-okayama</street>
<street>Meguro-ku</street>
<city>Tokyo</city>
<region />
<code>152</code>
<country>JP</country>
</postal>

<phone>+81 3 54997084</phone>
<facsimile>+81 3 37291940</facsimile>
<email>mohta@cc.titech.ac.jp</email>
</address>
</author>

<author fullname="Ken&apos;ichi Handa" initials="K." surname="Handa">
<organization>Electrotechnical Laboratory (ETL)</organization>

<address>
<postal>
<street>Umezono 1-1-4</street>
<street>Ibaraki</street>
<city>Tsukuba</city>
<region />
<code>305</code>
<country>JP</country>
</postal>

<phone>+81 298 585916</phone>
<facsimile>+81 298 585918</facsimile>
<email>handa@etl.go.jp</email>
</address>
</author>

<date year="1993" month="December" />

<abstract>
<t></t>
</abstract>
</front>

<seriesInfo value="1554" name="RFC" />
</reference>


<reference target2="reference.RFC.1555.xml" anchor="RFC1555">
<front>
<title abbrev="Hebrew Character Encoding">Hebrew Character Encoding for Internet Messages</title>
<author fullname="Hank Nussbacher" initials="H." surname="Nussbacher">
<organization>Tel Aviv University</organization>

<address>
<postal>
<street />
<city>Ramat Aviv</city>
<region />
<code />
<country>IL</country>
</postal>

<phone>+972 3 6408309</phone>
<facsimile>+972 3 6409118</facsimile>
<email>hank@vm.tau.ac.il</email>
</address>
</author>

<author fullname="Yehavi Bourvine" initials="Y." surname="Bourvine">
<organization>Hebrew University, Computer Center</organization>

<address>
<postal>
<street />
<city>Jerusalem</city>
<region />
<code />
<country>IL</country>
</postal>

<phone>+972 2 585684</phone>
<facsimile>+972 2 527349</facsimile>
<email>yehavi@vms.huji.ac.il</email>
</address>
</author>

<date year="1993" month="December" />

<abstract>
<t>This document describes the encoding used in electronic mailfor transferring Hebrew.  The standard devised makes use of MIMEand ISO-8859-8.</t>
</abstract>
</front>

<seriesInfo value="1555" name="RFC" />
</reference>


<reference target2="reference.RFC.1556.xml" anchor="RFC1556">
<front>
<title abbrev="Bi-directional Texts">Handling of Bi-directional Texts in MIME</title>
<author fullname="Hank Nussbacher" initials="H." surname="Nussbacher">
<organization>Tel Aviv University, Israeli Inter-University, Computer Center</organization>

<address>
<postal>
<street />
<city>Ramat Aviv</city>
<region />
<code />
<country>IL</country>
</postal>

<phone>+972 3 6408309</phone>
<facsimile>+972 3 6409118</facsimile>
<email>hank@vm.tau.ac.il</email>
</address>
</author>

<date year="1993" month="December" />

<abstract>
<t>This document describes the format and syntax of the "direction" keyword to be used with bi-directional texts in MIME.</t>
</abstract>
</front>

<seriesInfo value="1556" name="RFC" />
</reference>


<reference target2="reference.RFC.1557.xml" anchor="RFC1557">
<front>
<title abbrev="Korean Character Encoding">Korean Character Encoding for Internet Messages</title>
<author fullname="Uhhyung Choi" initials="U." surname="Choi">
<organization>Korea Advanced Institute of Science and Technology (KAIST), Department of Computer Science</organization>

<address>
<postal>
<street />
<city>Taejon</city>
<region />
<code>305-701</code>
<country>KR</country>
</postal>

<phone>+82 42 8698718</phone>
<facsimile>+82 42 8693510</facsimile>
<email>uhhyung@kaist.ac.kr</email>
</address>
</author>

<author fullname="Kilnam Chon" initials="K." surname="Chon">
<organization>Korea Advanced Institute of Science and Technology (KAIST), Department of Computer Science</organization>

<address>
<postal>
<street />
<city>Taejon</city>
<region />
<code>305-701</code>
<country>KR</country>
</postal>

<phone>+82 42 8693514</phone>
<facsimile>+82 42 8693510</facsimile>
<email>chon@cosmos.kaist.ac.kr</email>
</address>
</author>

<author fullname="Hyunje Park" initials="H." surname="Park">
<organization>Solvit Chosun Media, Inc.</organization>

<address>
<postal>
<street>748-16 Yeoksam-Dong</street>
<street>Kangnam-Gu</street>
<city>Seoul</city>
<region />
<code>135-080</code>
<country>KR</country>
</postal>

<phone>+82 2 5610361</phone>
<facsimile>+82 2 5694847</facsimile>
<email>hjpark@dino.media.co.kr</email>
</address>
</author>

<date year="1993" month="December" />

<abstract>
<t></t>
</abstract>
</front>

<seriesInfo value="1557" name="RFC" />
</reference>


<reference target2="reference.RFC.1558.xml" anchor="RFC1558">
<front>
<title abbrev="Representation of LDAP Filters">A String Representation of LDAP Search Filters</title>
<author fullname="Tim Howes" initials="T." surname="Howes">
<organization>University of Michigan, ITD Research Systems</organization>

<address>
<postal>
<street>535 W William St.</street>
<city>Ann Arbor</city>
<region>MI</region>
<code>48103-4943</code>
<country>US</country>
</postal>

<phone>+1 313 747 4454</phone>
<email>tim@umich.edu</email>
</address>
</author>

<date year="1993" month="December" />

<abstract>
<t>The Lightweight Directory Access Protocol (LDAP)defines a network representation of a search filter transmitted to an LDAP server.  Some applications may find it useful to have a common way of representing these search filters in a human-readable form.  This document defines a human-readable string format for representing LDAP search filters.</t>
</abstract>
</front>

<seriesInfo value="1558" name="RFC" />
</reference>


<reference target2="reference.RFC.1559.xml" anchor="RFC1559">
<front>
<title abbrev="DECnet Phase IV MIB">DECnet Phase IV MIB Extensions</title>
<author fullname="Jon Saperia" initials="J." surname="Saperia">
<organization>Digital Equipment Corporation (DEC)</organization>

<address>
<postal>
<street>153 Taylor Street</street>
<street>M/S TAY2-2/B5</street>
<city>Littleton</city>
<region>MA</region>
<code>01460</code>
<country>US</country>
</postal>

<phone>+1 508 952 3171</phone>
<email>saperia@tay.dec.com</email>
</address>
</author>

<date year="1993" month="December" />

<abstract>
<t></t>
</abstract>
</front>

<seriesInfo value="1559" name="RFC" />
</reference>


<reference target2="reference.RFC.1560.xml" anchor="RFC1560">
<front>
<title>The MultiProtocol Internet</title>
<author fullname="Barry M. Leiner" initials="D." surname="Leiner">
<organization>Universities Space Research Association</organization>

<address>
<postal>
<street>625 Ellis Street</street>
<street>Suite 205</street>
<city>Mountain View</city>
<region>CA</region>
<code>94043</code>
<country>US</country>
</postal>

<phone>+1 415 390 0317</phone>
<facsimile>+1 415 390 0318</facsimile>
<email>leiner@nsipo.nasa.gov</email>
</address>
</author>

<author fullname="Yakov Rekhter" initials="Y." surname="Rekhter">
<organization>IBM Corp., T.J. Watson Research Center</organization>

<address>
<postal>
<street>P.O. Box 218</street>
<city>Yorktown Heights</city>
<region>NY</region>
<code>10598</code>
<country>US</country>
</postal>

<phone>+1 914 945 3896</phone>
<email>yakov@watson.ibm.com</email>
</address>
</author>

<date year="1993" month="December" />

<abstract>
<t>This document was prepared by the authors on behalf of the Internet Architecture Board (IAB).  It is offered by the IAB to stimulate discussion.</t>

<t>There has recently been considerable discussion on two topics: MultiProtocol approaches in the Internet and the selection of a next generation Internet Protocol. This document suggests a strawman position for goals and approaches for the IETF/IESG/IAB in these areas. It takes the view that these two topics are related, and proposes directions for the IETF/IESG/IAB to pursue.</t>

<t>In particular, it recommends that the IETF/IESG/IAB should continue to be a force for consensus on a single protocol suite and internet layer protocol. The IETF/IESG/IAB should:</t>

<t>- maintain its focus on the TCP/IP protocol suite,</t>

<t>- work to select a single next-generation internet protocol and develop mechanisms to aid in transition from the current IPv4, and</t>

<t>- continue to explore mechanisms to interoperate and share resources with other protocol suites within the Internet.</t>
</abstract>
</front>

<seriesInfo value="1560" name="RFC" />
</reference>


<reference target2="reference.RFC.1561.xml" anchor="RFC1561">
<front>
<title abbrev="CLNP in TUBA Environments">Use of ISO CLNP in TUBA Environments</title>
<author fullname="David M. Piscitello" initials="D." surname="Piscitello">
<organization>Core Competence</organization>

<address>
<postal>
<street>1620 Tuckerstown Road</street>
<city>Dresher</city>
<region>PA</region>
<code>19025</code>
<country>US</country>
</postal>

<phone>+1 215 830 0692</phone>
<email>wk04464@worldlink.com</email>
</address>
</author>

<date year="1993" month="December" />

<abstract>
<t>This memo specifies a profile of the ISO/IEC 8473 Connectionless-mode Network Layer Protocol (CLNP,) for use in conjunction with RFC 1347, TCP/UDP over Bigger Addresses (TUBA,).  It describes the use of CLNP to provide the lower-level service expected by Transmission Control Protocol (TCP,) and User Datagram Protocol (UDP,).  CLNP provides essentially the same datagram service as Internet Protocol (IP,), but offers a means of conveying bigger network addresses (with additional structure, to aid routing).</t>

<t>While the protocols offer nearly the same services, IP and CLNP are not identical. This document describes a means of preserving the semantics of IP information that is absent from CLNP while preserving consistency between the use of CLNP in Internet and OSI environments. This maximizes the use of already-deployed CLNP implementations.</t>
</abstract>
</front>

<seriesInfo value="1561" name="RFC" />
</reference>


<reference target2="reference.RFC.1562.xml" anchor="RFC1562">
<front>
<title abbrev="Naming Guidelines for the AARNet X.500">Naming Guidelines for the AARNet X.500 Directory Service</title>
<author fullname="George G. Michaelson" initials="G." surname="Michaelson">
<organization>The University of Queensland, The Prentice Centre</organization>

<address>
<postal>
<street />
<city>St Lucia</city>
<region>Queensland</region>
<code>Q 4072</code>
<country>AU</country>
</postal>

<phone>+61 7 3654079</phone>
<facsimile>+61 7 3654477</facsimile>
<email>G.Michaelson@cc.uq.oz.au</email>
</address>
</author>

<author fullname="Mark R. Prior" initials="M." surname="Prior">
<organization>The University of Adelaide, Information Technology Division</organization>

<address>
<postal>
<street />
<city>Adelaide</city>
<region>SA</region>
<code>5005</code>
<country>AU</country>
</postal>

<phone>+61 8 3035680</phone>
<facsimile>+61 8 3034400</facsimile>
<email>mrp@itd.adelaide.edu.au</email>
</address>
</author>

<date year="1993" month="December" />

<abstract>
<t>AARNet is a member network of the global Internet and participates in the global Internet X.500 based Directory Service. A number of RFC's have been issued that make recommendations that alter or supplement the OSI/ETU standards for X.500. In general, these RFCs will be followed by the AARNet Directory Service.  However, in certain cases we wish to align ourselves with our national ISO body (Standards Australia) rather than the Internet where they conflict.  In naming, we have chosen to align ourselves with Standards Australia and this document notes the difference in our approach to the Internet guidelines suggested in RFC 1384.</t>
</abstract>
</front>

<seriesInfo value="1562" name="RFC" />
</reference>


<reference target2="reference.RFC.1563.xml" anchor="RFC1563">
<front>
<title abbrev="A text/enriched type for MIME">The text/enriched MIME Content-type</title>
<author fullname="Nathaniel S. Borenstein" initials="N." surname="Borenstein">
<organization>Bellcore, MRE 2D-296</organization>

<address>
<postal>
<street>445 South St.</street>
<city>Morristown</city>
<region>NJ</region>
<code>07962-1910</code>
<country>US</country>
</postal>

<phone>+1 201 829 4270</phone>
<facsimile>+1 201 829 5963</facsimile>
<email>nsb@bellcore.com</email>
</address>
</author>

<date year="1994" month="January" />

<abstract>
<t>MIME,defines a format and general framework for the representation of a wide variety of data types in Internet mail. This document defines one particular type of MIME data, the text/enriched type, a refinement of the "text/richtext" type defined in RFC 1341.  The text/enriched MIME type is intended to facilitate the wider interoperation of simple enriched text across a wide variety of hardware and software platforms.</t>
</abstract>
</front>

<seriesInfo value="1563" name="RFC" />
</reference>


<reference target2="reference.RFC.1564.xml" anchor="RFC1564">
<front>
<title abbrev="DSA Metrics">DSA Metrics (OSI-DS 34 (v3))</title>
<author fullname="Paul Barker" initials="P." surname="Barker">
<organization>University College London, Department of Computer Science</organization>

<address>
<postal>
<street>Gower Street</street>
<city>London</city>
<region>England</region>
<code>WC1E 6BT</code>
<country>UK</country>
</postal>

<phone>+44 71 3807366</phone>
<facsimile>+44 71 3871397</facsimile>
<email>P.Barker@cs.ucl.ac.uk</email>
</address>
</author>

<author fullname="Roland Hedberg" initials="R." surname="Hedberg">
<organization>Delft Technical University, Rekencentrum</organization>

<address>
<postal>
<street>Michiel de Ruyterweg 10-12</street>
<street>Postbus 354</street>
<city>Delft</city>
<region />
<code>2600 AJ</code>
<country>NL</country>
</postal>

<phone>+31 15 785210</phone>
<email>Roland.Hedberg@rc.tudelft.nl</email>
</address>
</author>

<author fullname="Roland Hedberg" initials="R." surname="Hedberg">
<organization>University of Umea, Umdac</organization>

<address>
<postal>
<street />
<city>Umea</city>
<region />
<code>s-901 87</code>
<country>SE</country>
</postal>

<phone>+46 90 165204</phone>
<email>Roland.Hedberg@umdac.umu.se</email>
</address>
</author>

<date year="1994" month="January" />

<abstract>
<t>This document defines a set of criteria by which a DSA implementation may be judged.  Particular issues covered include conformance to standards; performance; demonstrated interoperability.  The intention is that the replies to the questions posed provide a fairly full description of a DSA. Some of the questions will yield answers which are purely descriptive; others, however, are intended to elicit answers which give some measure of the utility of the DSA. The marks awarded for a DSA in each particular area should give a good indication of the DSA's capabilities, and its suitability for particular uses.</t>

<t>Please send comments to the authors or to the discussion group osi-ds@CS.UCL.AC.UK.;</t>
</abstract>
</front>

<seriesInfo value="1564" name="RFC" />
</reference>


<reference target2="reference.RFC.1565.xml" anchor="RFC1565">
<front>
<title>Network Services Monitoring MIB</title>
<author fullname="Steve Kille" initials="S." surname="Kille">
<organization>ISODE Consortium</organization>

<address>
<postal>
<street>The Dome, The Square</street>
<city>Richmond</city>
<region>England</region>
<code>TW9 1DT</code>
<country>UK</country>
</postal>

<phone>+44 81 3329091</phone>
<email>S.Kille@isode.com</email>
</address>
</author>

<author fullname="Ned Freed" initials="N." surname="Freed">
<organization>Innosoft International, Inc.</organization>

<address>
<postal>
<street>250 West First Street</street>
<street>Suite 240</street>
<city>Claremont</city>
<region>CA</region>
<code>91711</code>
<country>US</country>
</postal>

<phone>+1 909 624 7907</phone>
<facsimile>+1 909 621 5319</facsimile>
<email>ned@innosoft.com</email>
</address>
</author>

<date year="1994" month="January" />
</front>

<seriesInfo value="1565" name="RFC" />
</reference>


<reference target2="reference.RFC.1566.xml" anchor="RFC1566">
<front>
<title>Mail Monitoring MIB</title>
<author fullname="Steve Kille" initials="S." surname="Kille">
<organization>ISODE Consortium</organization>

<address>
<postal>
<street>The Dome, The Square</street>
<city>Richmond</city>
<region>England</region>
<code>TW9 1DT</code>
<country>UK</country>
</postal>

<phone>+44 81 3329091</phone>
<email>S.Kille@isode.com</email>
</address>
</author>

<author fullname="Ned Freed" initials="N." surname="Freed">
<organization>Innosoft International, Inc.</organization>

<address>
<postal>
<street>250 West First Street</street>
<street>Suite 240</street>
<city>Claremont</city>
<region>CA</region>
<code>91711</code>
<country>US</country>
</postal>

<phone>+1 909 624 7907</phone>
<facsimile>+1 909 621 5319</facsimile>
<email>ned@innosoft.com</email>
</address>
</author>

<date year="1994" month="January" />
</front>

<seriesInfo value="1566" name="RFC" />
</reference>


<reference target2="reference.RFC.1567.xml" anchor="RFC1567">
<front>
<title>X.500 Directory Monitoring MIB</title>
<author fullname="Glenn Mansfield" initials="G." surname="Mansfield">
<organization>AIC Systems Laboratories</organization>

<address>
<postal>
<street>6-6-3 Minami Yoshinari</street>
<city>Aoba-ku</city>
<region>Sendai</region>
<code>989-32</code>
<country>JP</country>
</postal>

<phone>+81 22 2793310</phone>
<email>glenn@aic.co.jp</email>
</address>
</author>

<author fullname="Steve E. Kille" initials="S." surname="Kille">
<organization>ISODE Consortium</organization>

<address>
<postal>
<street>The Dome, The Square</street>
<city>Richmond</city>
<region>England</region>
<code>TW9 1DT</code>
<country>UK</country>
</postal>

<phone>+44 81 3329091</phone>
<email>S.Kille@isode.com</email>
</address>
</author>

<date year="1994" month="January" />

<abstract>
<t>This document defines a portion of the Management Information Base (MIB).  It defines the MIB for monitoring Directory System Agents (DSA), a component of the OSI Directory. This MIB will be used in conjunction with the APPLICATION-MIB for monitoring DSAs.</t>
</abstract>
</front>

<seriesInfo value="1567" name="RFC" />
</reference>


<reference target2="reference.RFC.1568.xml" anchor="RFC1568">
<front>
<title abbrev="SNPP - Version 1(b)">Simple Network Paging Protocol - Version 1(b)</title>
<author fullname="R. Allen Gwinn, Jr." initials="R.A." surname="Gwinn">
<organization>Southern Methodist University, Business Information Center</organization>

<address>
<postal>
<street />
<city>Dallas</city>
<region>TX</region>
<code>75275</code>
<country>US</country>
</postal>

<phone>+1 214 768 3186</phone>
<email>allen@mail.cox.smu.edu</email>
</address>
</author>

<date year="1994" month="January" />

<abstract>
<t>This RFC suggests a simple way for delivering both alphanumeric and numeric pages (one-way) to radio paging terminals.  Gateways supporting this protocol, as well as SMTP, have been in use for several months in one nationwide paging firm.  One other paging firm is in the process of adopting it.</t>

<t>Earlier versions of this specification were reviewed by IESG members and the IETF's "822 Extensions" Working Group.  They preferred an alternate strategy, as discussed under "Relationship to Other IETF Work", below.</t>
</abstract>
</front>

<seriesInfo value="1568" name="RFC" />
</reference>


<reference target2="reference.RFC.1569.xml" anchor="RFC1569">
<front>
<title abbrev="Radio Paging -- Technical Procedures">Principles of Operation for the TPC.INT Subdomain: Radio Paging -- Technical Procedures</title>
<author fullname="Marshall T. Rose" initials="M." surname="Rose">
<organization>Dover Beach Consulting, Inc.</organization>

<address>
<postal>
<street>420 Whisman Court</street>
<city>Mountain View</city>
<region>CA</region>
<code>94043-2186</code>
<country>US</country>
</postal>

<phone>+1 415 968 1052</phone>
<facsimile>+1 415 968 2510</facsimile>
<email>mrose@dbc.mtview.ca.us</email>
</address>
</author>

<date year="1994" month="January" />
</front>

<seriesInfo value="1569" name="RFC" />
</reference>


<reference target2="reference.RFC.1570.xml" anchor="RFC1570">
<front>
<title abbrev="PPP LCP extensions">PPP LCP Extensions</title>
<author fullname="William Allen Simpson" initials="W." surname="Simpson">
<organization>Daydreamer, Computer Systems Consulting Services</organization>

<address>
<postal>
<street>1384 Fontaine</street>
<city>Madison Heights</city>
<region>MI</region>
<code>48071</code>
<country>US</country>
</postal>

<email>Bill.Simpson@um.cc.umich.edu</email>
</address>
</author>

<date year="1994" month="January" />

<abstract>
<t>The Point-to-Point Protocol (PPP)provides a standard method for transporting multi-protocol datagrams over point-to-point links.  PPP defines an extensible Link Control Protocol (LCP) for establishing, configuring, and testing the data-link connection.  This document defines several additional LCP features which have been suggested over the past few years.</t>

<t>This document is the product of the Point-to-Point Protocol Working Group of the Internet Engineering Task Force (IETF).  Comments should be submitted to the ietf-ppp@ucdavis.edu mailing list.</t>
</abstract>
</front>

<seriesInfo value="1570" name="RFC" />
</reference>


<reference target2="reference.RFC.1571.xml" anchor="RFC1571">
<front>
<title abbrev="Environment Option Interoperability">Telnet Environment Option Interoperability Issues</title>
<author fullname="David A. Borman" initials="D." surname="Borman">
<organization>Cray Research, Inc.</organization>

<address>
<postal>
<street>655F Lone Oak Drive</street>
<city>Eagan</city>
<region>MN</region>
<code>55123</code>
<country>US</country>
</postal>

<phone>+1 612 452 6650</phone>
<email>dab@CRAY.COM</email>
</address>
</author>

<date year="1994" month="January" />
</front>

<seriesInfo value="1571" name="RFC" />
</reference>


<reference target2="reference.RFC.1572.xml" anchor="RFC1572">
<front>
<title>Telnet Environment Option</title>
<author fullname="Steve Alexander" initials="S." surname="Alexander">
<organization>Lachman Technology, Inc.</organization>

<address>
<postal>
<street>1901 North Naper Boulevard</street>
<city>Naperville</city>
<region>IL</region>
<code>60563-8895</code>
<country>US</country>
</postal>

<phone>+1 708 505 9555 x256</phone>
<email>stevea@lachman.com</email>
</address>
</author>

<date year="1994" month="January" />

<abstract>
<t>This document specifies a mechanism for passing environment information between a telnet client and server.  Use of this mechanism enables a telnet user to propagate configuration information to a remote host when connecting.</t>

<t>This document corrects some errors in.</t>
</abstract>
</front>

<seriesInfo value="1572" name="RFC" />
</reference>


<reference target2="reference.RFC.1573.xml" anchor="RFC1573">
<front>
<title abbrev="Interfaces Group Evolution">Evolution of the Interfaces Group of MIB-II</title>
<author fullname="Keith McCloghrie" initials="K." surname="McCloghrie">
<organization>Hughes LAN Systems</organization>

<address>
<postal>
<street>1225 Charleston Rd</street>
<city>Mountain View</city>
<region>CA</region>
<code>94043</code>
<country>US</country>
</postal>

<phone>+1 415 966 7934</phone>
<email>kzm@hls.com</email>
</address>
</author>

<author fullname="Frank Kastenholz" initials="F." surname="Kastenholz">
<organization>FTP Software</organization>

<address>
<postal>
<street>2 High Street</street>
<city>North Andover</city>
<region>MA</region>
<code>01845</code>
<country>US</country>
</postal>

<phone>+1 508 685 4000</phone>
<email>kasten@ftp.com</email>
</address>
</author>

<date year="1994" month="January" />
</front>

<seriesInfo value="1573" name="RFC" />
</reference>


<reference target2="reference.RFC.1574.xml" anchor="RFC1574">
<front>
<title>Essential Tools for the OSI Internet</title>
<author fullname="Susan K. Hares" initials="S." surname="Hares">
<organization>MERIT/NSFNET, Internet Engineering</organization>

<address>
<postal>
<street>1075 Beal Avenue</street>
<city>Ann Arbor</city>
<region>MI</region>
<code>48109-2112</code>
<country>US</country>
</postal>

<phone>+1 313 936 3000</phone>
<email>skh@merit.edu</email>
</address>
</author>

<author fullname="Cathy J. Wittbrodt" initials="C." surname="Wittbrodt">
<organization>Stanford University/BARRNet, Networking Systems</organization>

<address>
<postal>
<street>Pine Hall 115</street>
<city>Stanford</city>
<region>CA</region>
<code>94305</code>
<country>US</country>
</postal>

<phone>+1 415 725 5481</phone>
<email>cjw@magnolia.Stanford.EDU</email>
</address>
</author>

<date year="1994" month="February" />

<abstract>
<t>This document specifies the following three necessary tools to debug problems in the deployment and maintenance of networks using ISO 8473 (CLNP):</t>

<t>- ping or OSI Echo function
      - traceroute function which uses the OSI Echo function
      - routing table dump function</t>

<t>These CLNS tools are the basics required for hosts and routers for CLNS network support. It is intended that this document specify the most basic support level required for CLNS hosts and routers.</t>

<t>To support some of the needed tools (ping and traceroute) this memo specifies the mechanism specified in RFC 1575.</t>
</abstract>
</front>

<seriesInfo value="1574" name="RFC" />
</reference>


<reference target2="reference.RFC.1575.xml" anchor="RFC1575">
<front>
<title>An Echo Function for CLNP (ISO 8473)</title>
<author fullname="Susan K. Hares" initials="S." surname="Hares">
<organization>MERIT/NSFNET, Internet Engineering,</organization>

<address>
<postal>
<street>1075 Beal Avenue</street>
<city>Ann Arbor</city>
<region>MI</region>
<code>48109-2112</code>
<country>US</country>
</postal>

<phone>+1 313 936 3000</phone>
<email>skh@merit.edu</email>
</address>
</author>

<author fullname="Cathy J. Wittbrodt" initials="C." surname="Wittbrodt">
<organization>Stanford University/BARRNet, Networking Systems</organization>

<address>
<postal>
<street>Pine Hall 115</street>
<city>Stanford</city>
<region>CA</region>
<code>94305</code>
<country>US</country>
</postal>

<phone>+1 415 725 5481</phone>
<email>cjw@magnolia.Stanford.EDU</email>
</address>
</author>

<date year="1994" month="February" />

<abstract>
<t>This memo defines an echo function for the connection-less network layer protocol.  The mechanism that is mandated here is in the final process of being standardized by ISO as "Amendment X: Addition of an Echo function to ISO 8473" an integral part of Version 2 of ISO 8473.</t>
</abstract>
</front>

<seriesInfo value="1575" name="RFC" />
</reference>


<reference target2="reference.RFC.1576.xml" anchor="RFC1576">
<front>
<title>TN3270 Current Practices</title>
<author fullname="Jon Penner" initials="J." surname="Penner">
<organization>DCA, Inc.</organization>

<address>
<postal>
<street>2800 Oakmont Drive</street>
<city>Austin</city>
<region>TX</region>
<code>78664</code>
<country>US</country>
</postal>

<facsimile>+1 512 388 7090</facsimile>
<email>jjp@bscs.com</email>
</address>
</author>

<date year="1994" month="January" />

<abstract>
<t>This document describes the existing implementation of transferring 3270 display terminal data using currently available telnet capabilities.  The name traditionally associated with this
 implementation is TN3270.</t>

<t>Information is provided to aid in the implementation of TN3270 servers as well as client terminal emulators.</t>

<t>The following areas pertaining to TN3270 implementations are covered in this document:</t>

<t>1. the telnet options negotiated to transition from a NVT ASCII state to a TN3270 state ready to process incoming 3270 data
         stream commands</t>

<t>2. the method for sending and receiving 3270 data</t>

<t>3. the method of handling some special keys known as SYSREQ and ATTN using current available telnet commands</t>

<t>4. the events that will transition a TN3270 session back to an NVT session</t>
</abstract>
</front>

<seriesInfo value="1576" name="RFC" />
</reference>


<reference target2="reference.RFC.1577.xml" anchor="RFC1577">
<front>
<title>Classical IP and ARP over ATM</title>
<author fullname="Mark Laubach" initials="M." surname="Laubach">
<organization>Hewlett-Packard Laboratories</organization>

<address>
<postal>
<street>1501 Page Mill Road</street>
<city>Palo Alto</city>
<region>CA</region>
<code>94304</code>
<country>US</country>
</postal>

<phone>+1 415 857 3513</phone>
<facsimile>+1 415 857 8526</facsimile>
<email>laubach@hpl.hp.com</email>
</address>
</author>

<date year="1994" month="January" />

<abstract>
<t>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 3.  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 "wires" and local LAN segments connecting IP end-stations ("members") and routers operating in the "classical" LAN-based paradigm. Issues raised by MAC level bridging and LAN emulation are beyond the scope of this paper.</t>

<t>This memo introduces general ATM technology and nomenclature. Readers are encouraged to review the ATM Forum and ITU-TS (formerly CCITT) references for more detailed information about ATM implementation agreements and standards.</t>
</abstract>
</front>

<seriesInfo value="1577" name="RFC" />
</reference>


<reference target2="reference.RFC.1578.xml" anchor="RFC1578">
<front>
<title abbrev="FYI Q/A - for Schools">FYI on Questions and Answers - Answers to Commonly Asked "Primary and Secondary School Internet User" Questions</title>
<author fullname="Jennifer Sellers" initials="J." surname="Sellers">
<organization>NASA NREN/Sterling Software</organization>

<address>
<postal>
<street>700 13th Street NW</street>
<street>Suite 950</street>
<city>Washington</city>
<region>DC</region>
<code>20005</code>
<country>US</country>
</postal>

<phone>+1 202 434 8954</phone>
<email>sellers@quest.arc.nasa.gov</email>
</address>
</author>

<date year="1994" month="February" />

<abstract>
<t>The goal of this FYI RFC, produced by the Internet School Networking (ISN) group in the User Services Area of the Internet Engineering Task Force (IETF), is to document the questions most commonly asked about the Internet by those in the primary and secondary school community, and to provide pointers to sources which answer those questions.  It is directed at educators, school media specialists, and school administrators who are recently connected to the Internet, who are accessing the Internet via dial-up or another means which is not a direct connection, or who are considering an Internet connection as a resource for their schools.</t>
</abstract>
</front>

<seriesInfo value="1578" name="RFC" />
</reference>


<reference target2="reference.RFC.1579.xml" anchor="RFC1579">
<front>
<title>Firewall-Friendly FTP</title>
<author fullname="Steven M. Bellovin" initials="S." surname="Bellovin">
<organization>AT&amp;T Bell Laboratories</organization>

<address>
<postal>
<street>600 Mountain Avenue</street>
<city>Murray Hill</city>
<region>NJ</region>
<code>07974</code>
<country>US</country>
</postal>

<phone>+1 908 582 5886</phone>
<email>smb@research.att.com</email>
</address>
</author>

<date year="1994" month="February" />

<abstract>
<t>This memo describes a suggested change to the behavior of FTP client programs.  No protocol modifications are required, though we outline some that might be useful.</t>
</abstract>
</front>

<seriesInfo value="1579" name="RFC" />
</reference>


<reference target2="reference.RFC.1580.xml" anchor="RFC1580">
<front>
<title>Guide to Network Resource Tools</title>
<author fullname="Daniele Bovio" initials="D." surname="Bovio">
<organization>EARN Association</organization>

<address>
<postal>
<street>PSI - Batiment 211</street>
<city>Orsay CEDEX</city>
<region />
<code>91405</code>
<country>FR</country>
</postal>

<phone>+33 1 69412426</phone>
<facsimile>+33 1 69416683</facsimile>
<email>earndoc@earncc.earn.net</email>
</address>
</author>

<author fullname="Ulrich Giese" initials="U." surname="Giese">
<organization>EARN Association</organization>

<address>
<postal>
<street>PSI - Batiment 211</street>
<city>Orsay CEDEX</city>
<region />
<code>91405</code>
<country>FR</country>
</postal>

<phone>+33 1 69412426</phone>
<facsimile>+33 1 69416683</facsimile>
<email>earndoc@earncc.earn.net</email>
</address>
</author>

<author fullname="Nadine Grange" initials="N." surname="Grange">
<organization>EARN Association</organization>

<address>
<postal>
<street>PSI - Batiment 211</street>
<city>Orsay CEDEX</city>
<region />
<code>91405</code>
<country>FR</country>
</postal>

<phone>+33 1 69412426</phone>
<facsimile>+33 1 69416683</facsimile>
<email>earndoc@earncc.earn.net</email>
</address>
</author>

<author fullname="Turgut Kalfaoglu" initials="T." surname="Kalfaoglu">
<organization>EARN Association</organization>

<address>
<postal>
<street>PSI - Batiment 211</street>
<city>Orsay CEDEX</city>
<region />
<code>91405</code>
<country>FR</country>
</postal>

<phone>+33 1 69412426</phone>
<facsimile>+33 1 69416683</facsimile>
<email>earndoc@earncc.earn.net</email>
</address>
</author>

<author fullname="Greg Lloyd" initials="G." surname="Lloyd">
<organization>EARN Association</organization>

<address>
<postal>
<street>PSI - Batiment 211</street>
<city>Orsay CEDEX</city>
<region />
<code>91405</code>
<country>FR</country>
</postal>

<phone>+33 1 69412426</phone>
<facsimile>+33 1 69416683</facsimile>
<email>earndoc@earncc.earn.net</email>
</address>
</author>

<author fullname="David Sitman" initials="D." surname="Sitman">
<organization>EARN Association</organization>

<address>
<postal>
<street>PSI - Batiment 211</street>
<city>Orsay CEDEX</city>
<region />
<code>91405</code>
<country>FR</country>
</postal>

<phone>+33 1 69412426</phone>
<facsimile>+33 1 69416683</facsimile>
<email>earndoc@earncc.earn.net</email>
</address>
</author>

<date year="1994" month="March" />
</front>

<seriesInfo value="1580" name="RFC" />
</reference>


<reference target2="reference.RFC.1581.xml" anchor="RFC1581">
<front>
<title abbrev="Demand RIP">Protocol Analysis for Extensions to RIP to Support Demand Circuits</title>
<author fullname="Gerry Meyer" initials="G." surname="Meyer">
<organization>Spider Systems</organization>

<address>
<postal>
<street>Stanwell Street</street>
<city>Edinburgh</city>
<region>Scotland</region>
<code>EH6 5NG</code>
<country>UK</country>
</postal>

<phone>+44 31 5549424</phone>
<facsimile>+44 31 5540649</facsimile>
<email>gerry@spider.co.uk</email>
</address>
</author>

<date year="1994" month="February" />

<abstract>
<t>As required by Routing Protocol Criteria, this report documents the key features of Routing over Demand Circuits on Wide Area Networks - RIPand the current implementation experience.</t>
</abstract>
</front>

<seriesInfo value="1581" name="RFC" />
</reference>


<reference target2="reference.RFC.1582.xml" anchor="RFC1582">
<front>
<title abbrev="Demand RIP">Extensions to RIP to Support Demand Circuits</title>
<author fullname="Gerry Meyer" initials="G." surname="Meyer">
<organization>Spider Systems</organization>

<address>
<postal>
<street>Stanwell Street</street>
<city>Edinburgh</city>
<region>Scotland</region>
<code>EH6 5NG</code>
<country>UK</country>
</postal>

<phone>+44 31 5549424</phone>
<facsimile>+44 31 5540649</facsimile>
<email>gerry@spider.co.uk</email>
</address>
</author>

<date year="1994" month="February" />

<abstract>
<t>Running routing protocols on connection oriented Public Data Networks, for example X.25 packet switched networks or ISDN, can be expensive if the standard form of periodic broadcasting of routing information is adhered to.  The high cost arises because a connection has to all practical intents and purposes be kept open to every destination to which routing information is to be sent, whether or not it is being used to carry user data.</t>

<t>Routing information may also fail to be propagated if the number of destinations to which the routing information is to be sent exceeds the number of channels available to the router on the Wide Area Network (WAN).</t>

<t>This memo defines a generalized modification which can be applied to Bellman-Ford (or distance vector) algorithm information broadcasting protocols, for example IP RIP, Netware RIP or Netware SAP, which overcomes the limitations of the traditional methods described above.</t>

<t>The routing protocols support a purely triggered update mechanism on demand circuits on WANs.  The protocols run UNMODIFIED on LANs or fixed point-to-point links.</t>

<t>Routing information is sent on the WAN when the routing database is modified by new routing information received from another interface. When this happens a (triggered) update is sent to a list of destinations on other WAN interfaces.  Because routing protocols are datagram based they are not guaranteed to be received by the peer router on the WAN.  An acknowledgement and retransmission mechanism is provided to ensure that routing updates are received.</t>

<t>The WAN circuit manager advises the routing applications on the reachability and non-reachability of destinations on the WAN.</t>
</abstract>
</front>

<seriesInfo value="1582" name="RFC" />
</reference>


<reference target2="reference.RFC.1583.xml" anchor="RFC1583">
<front>
<title>OSPF Version 2</title>
<author fullname="John Moy" initials="J." surname="Moy">
<organization>Proteon, Inc.</organization>

<address>
<postal>
<street>9 Technology Drive</street>
<city>Westborough</city>
<region>MA</region>
<code>01581</code>
<country>US</country>
</postal>

<phone>+1 508 898 2800</phone>
<facsimile>+1 508 898 3176</facsimile>
<email>jmoy@proteon.com</email>
</address>
</author>

<date year="1994" month="March" />

<abstract>
<t>This memo documents version 2 of the OSPF protocol.  OSPF is a link-state routing protocol.  It is designed to be run internal to a single Autonomous System.  Each OSPF router maintains an identical database describing the Autonomous System's topology.  From this database, a routing table is calculated by constructing a shortest- path tree.</t>

<t>OSPF recalculates routes quickly in the face of topological changes, utilizing a minimum of routing protocol traffic.  OSPF provides support for equal-cost multipath.  Separate routes can be calculated for each IP Type of Service.  An area routing capability is provided, enabling an additional level of routing protection and a reduction in routing protocol traffic.  In addition, all OSPF routing protocol exchanges are authenticated.</t>

<t>OSPF Version 2 was originally documented in RFC 1247. The differences between RFC 1247 and this memo are explained in Appendix E. The differences consist of bug fixes and clarifications, and are backward-compatible in nature. Implementations of RFC 1247 and of this memo will interoperate.</t>

<t>Please send comments to ospf@gated.cornell.edu.</t>
</abstract>
</front>

<seriesInfo value="1583" name="RFC" />
</reference>


<reference target2="reference.RFC.1584.xml" anchor="RFC1584">
<front>
<title>Multicast Extensions to OSPF</title>
<author fullname="John Moy" initials="J." surname="Moy">
<organization>Proteon, Inc.</organization>

<address>
<postal>
<street>9 Technology Drive</street>
<city>Westborough</city>
<region>MA</region>
<code>01581</code>
<country>US</country>
</postal>

<phone>+1 508 898 2800</phone>
<email>jmoy@proteon.com</email>
</address>
</author>

<date year="1994" month="March" />

<abstract>
<t>This memo documents enhancements to the OSPF protocol enabling the routing of IP multicast datagrams. In this proposal, an IP multicast packet is routed based both on the packet's source and its multicast destination (commonly referred to as source/destination routing). As it is routed, the multicast packet follows a shortest path to each multicast destination. During packet forwarding, any commonality of paths is exploited; when multiple hosts belong to a single multicast group, a multicast packet will be replicated only when the paths to the separate hosts diverge.</t>

<t>OSPF, a link-state routing protocol, provides a database describing the Autonomous System's topology. A new OSPF link state advertisement is added describing the location of multicast destinations. A multicast packet's path is then calculated by building a pruned shortest-path tree rooted at the packet's IP source. These trees are built on demand, and the results of the calculation are cached for use by subsequent packets.</t>

<t>The multicast extensions are built on top of OSPF Version 2. The extensions have been implemented so that a multicast routing capability can be introduced piecemeal into an OSPF Version 2 routing domain. Some of the OSPF Version 2 routers may run the multicast extensions, while others may continue to be restricted to the forwarding of regular IP traffic (unicasts).</t>

<t>Please send comments to mospf@gated.cornell.edu.</t>
</abstract>
</front>

<seriesInfo value="1584" name="RFC" />
</reference>


<reference target2="reference.RFC.1585.xml" anchor="RFC1585">
<front>
<title>MOSPF: Analysis and Experience</title>
<author fullname="John Moy" initials="J." surname="Moy">
<organization>Proteon, Inc.</organization>

<address>
<postal>
<street>9 Technology Drive</street>
<city>Westborough</city>
<region>MA</region>
<code>01581</code>
<country>US</country>
</postal>

<phone>+1 508 898 2800</phone>
<email>jmoy@proteon.com</email>
</address>
</author>

<date year="1994" month="March" />

<abstract>
<t>This memo documents how the MOSPF protocol satisfies the requirements imposed on Internet routing protocols by "Internet Engineering Task Force internet routing protocol standardization criteria" ().</t>

<t>Please send comments to mospf@gated.cornell.edu.</t>
</abstract>
</front>

<seriesInfo value="1585" name="RFC" />
</reference>


<reference target2="reference.RFC.1586.xml" anchor="RFC1586">
<front>
<title abbrev="OSPF over Frame Relay">Guidelines for Running OSPF Over Frame Relay Networks</title>
<author fullname="Osmund S. deSouza" initials="O.S." surname="deSouza">
<organization>AT&amp;T, Bell Laboratories</organization>

<address>
<postal>
<street>101 Crawfords Corner Road</street>
<street>Room 1K-606</street>
<city>Holmdel</city>
<region>NJ</region>
<code>07733</code>
<country>US</country>
</postal>

<phone>+1 908 949 1393</phone>
<email>osmund.desouza@att.com</email>
</address>
</author>

<author fullname="Manoel A. Rodrigues" initials="M.A." surname="Rodrigues">
<organization>AT&amp;T, Bell Laboratories</organization>

<address>
<postal>
<street>101 Crawfords Corner Road</street>
<street>Room 1K-608</street>
<city>Holmdel</city>
<region>NJ</region>
<code>07733</code>
<country>US</country>
</postal>

<phone>+1 908 949 4655</phone>
<email>manoel.rodrigues@att.com</email>
</address>
</author>

<date year="1994" month="March" />

<abstract>
<t>This memo specifies guidelines for implementors and users of the Open Shortest Path First (OSPF) routing protocol to bring about improvements in how the protocol runs over frame relay networks.  We show how to configure frame relay interfaces in a way that obviates the "full-mesh" connectivity required by current OSPF implementations. This allows for simpler, more economic network designs.  These guidelines do not require any protocol changes; they only provide recommendations for how OSPF should be implemented and configured to use frame relay networks efficiently.</t>
</abstract>
</front>

<seriesInfo value="1586" name="RFC" />
</reference>


<reference target2="reference.RFC.1587.xml" anchor="RFC1587">
<front>
<title abbrev="OSPF NSSA Option">The OSPF NSSA Option</title>
<author fullname="Rob Coltun" initials="R." surname="Coltun">
<organization>RainbowBridge Communications</organization>

<address>
<phone>+1 301 340 9416</phone>
<email>rcoltun@rainbow-bridge.com</email>
</address>
</author>

<author fullname="Vince Fuller" initials="V." surname="Fuller">
<organization>Stanford University, BARRNet</organization>

<address>
<postal>
<street>Pine Hall 115</street>
<city>Stanford</city>
<region>CA</region>
<code>94305-4122</code>
<country>US</country>
</postal>

<phone>+1 415 723 6860</phone>
<email>vaf@Valinor.Stanford.EDU</email>
</address>
</author>

<date year="1994" month="March" />

<abstract>
<t>This document describes a new optional type of OSPF area, somewhat humorously referred to as a "not-so-stubby" area (or NSSA).  NSSAs are similar to the existing OSPF stub area configuration option but have the additional capability of importing AS external routes in a limited fashion.</t>
</abstract>
</front>

<seriesInfo value="1587" name="RFC" />
</reference>


<reference target2="reference.RFC.1588.xml" anchor="RFC1588">
<front>
<title abbrev="White Pages Report">White Pages Meeting Report</title>
<author fullname="Jon Postel" initials="J." surname="Postel">
<organization>USC/Information Sciences Institute</organization>

<address>
<postal>
<street>4676 Admiralty Way</street>
<city>Marina del Rey</city>
<region>CA</region>
<code>90292</code>
<country>US</country>
</postal>

<phone>+1 310 822 1511</phone>
<facsimile>+1 310 823 6714</facsimile>
<email>Postel@ISI.EDU</email>
</address>
</author>

<author fullname="Celeste Anderson" initials="C." surname="Anderson">
<organization>USC/Information Sciences Institute</organization>

<address>
<postal>
<street>4676 Admiralty Way</street>
<city>Marina del Rey</city>
<region>CA</region>
<code>90292</code>
<country>US</country>
</postal>

<phone>+1 310 822 1511</phone>
<facsimile>+1 310 823 6714</facsimile>
<email>Celeste@ISI.EDU</email>
</address>
</author>

<date year="1994" month="February" />
</front>

<seriesInfo value="1588" name="RFC" />
</reference>


<reference target2="reference.RFC.1589.xml" anchor="RFC1589">
<front>
<title abbrev="Kernel Model for Precision Timekeeping">A Kernel Model for Precision Timekeeping</title>
<author fullname="David L. Mills" initials="D." surname="Mills">
<organization>University of Delaware, Electrical Engineering Department</organization>

<address>
<postal>
<street />
<city>Newark</city>
<region>DE</region>
<code>19716</code>
<country>US</country>
</postal>

<phone>+1 302 831 8247</phone>
<email>mills@udel.edu</email>
</address>
</author>

<date year="1994" month="March" />
</front>

<seriesInfo value="1589" name="RFC" />
</reference>


<reference target2="reference.RFC.1590.xml" anchor="RFC1590">
<front>
<title>Media Type Registration Procedure</title>
<author fullname="Jon Postel" initials="J." surname="Postel">
<organization>USC/Information Sciences Institute</organization>

<address>
<postal>
<street>4676 Admiralty Way</street>
<city>Marina del Rey</city>
<region>CA</region>
<code>90292</code>
<country>US</country>
</postal>

<phone>+1 310 822 1511</phone>
<facsimile>+1 310 823 6714</facsimile>
<email>Postel@ISI.EDU</email>
</address>
</author>

<date year="1994" month="March" />

<abstract>
<t>Several protocols allow the use of data representing different "media" such as text, images, audio, and video, and within such media different encoding styles, such as (in video) jpeg, gif, ief, and tiff.  The Multimedia Internet Message Extensions (MIME) protocoldefined several initial types of multimedia data objects, and a procedure for registering additional types with the Internet Assigned Numbers Authority (IANA).  Several questions have been raised about the requirements and administrative procedure for registering MIME content-type and subtypes, and the use of these Media Types for other applications.  This document addresses these issues and specifies a procedure for the registration of new Media Types (content- type/subtypes).  It also generalizes the scope of use of these Media Types to make it appropriate to use the same registrations and specifications with other applications.</t>
</abstract>
</front>

<seriesInfo value="1590" name="RFC" />
</reference>


<reference target2="reference.RFC.1591.xml" anchor="RFC1591">
<front>
<title>Domain Name System Structure and Delegation</title>
<author fullname="Jon Postel" initials="J." surname="Postel">
<organization>USC/Information Sciences Institute</organization>

<address>
<postal>
<street>4676 Admiralty Way</street>
<city>Marina del Rey</city>
<region>CA</region>
<code>90292</code>
<country>US</country>
</postal>

<phone>+1 310 822 1511</phone>
<facsimile>+1 310 823 6714</facsimile>
<email>Postel@ISI.EDU</email>
</address>
</author>

<date year="1994" month="March" />
</front>

<seriesInfo value="1591" name="RFC" />
</reference>


<reference target2="reference.RFC.1592.xml" anchor="RFC1592">
<front>
<title abbrev="SNMP-DPI">Simple Network Management Protocol Distributed Protocol Interface Version 2.0</title>
<author fullname="Bert Wijnen" initials="B." surname="Wijnen">
<organization>IBM International Operations</organization>

<address>
<postal>
<street>Watsonweg 2</street>
<city>Uithoorn</city>
<region />
<code>1423 ND</code>
<country>NL</country>
</postal>

<phone>+31 29 7553316</phone>
<facsimile>+31 29 7562468</facsimile>
<email>wijnen@vnet.ibm.com</email>
</address>
</author>

<author fullname="Geoffrey C. Carpenter" initials="G." surname="Carpenter">
<organization>IBM, T.J. Watson Research Center</organization>

<address>
<postal>
<street>P.O. Box 218</street>
<city>Yorktown Heights</city>
<region>NY</region>
<code>10598</code>
<country>US</country>
</postal>

<phone>+1 914 945 1970</phone>
<email>gcc@watson.ibm.com</email>
</address>
</author>

<author fullname="Kim Curran" initials="K." surname="Curran">
<organization>Bell Northern Research Ltd.</organization>

<address>
<postal>
<street>P.O. Box 3511 Station C</street>
<city>Ottawa</city>
<region>Ontario</region>
<code>K1Y 4HY</code>
<country>CA</country>
</postal>

<phone>+1 613 763 5283</phone>
<email>kcurran@bnr.ca</email>
</address>
</author>

<author fullname="Aditya Sehgal" initials="A." surname="Sehgal">
<organization>Bell Northern Research Ltd.</organization>

<address>
<postal>
<street>P. O. Box 3511 Station C</street>
<city>Ottawa</city>
<region>Ontario</region>
<code>K1Y 4HY</code>
<country>CA</country>
</postal>

<phone>+1 613 763 8821</phone>
<email>asehgal@bnr.ca</email>
</address>
</author>

<author fullname="Glen Waters" initials="G." surname="Waters">
<organization>Bell Northern Research Ltd.</organization>

<address>
<postal>
<street>P.O. Box 3511 Station C</street>
<city>Ottawa</city>
<region>Ontario</region>
<code>K1Y 4HY</code>
<country>CA</country>
</postal>

<phone>+1 613 763 3933</phone>
<email>gwaters@bnr.ca</email>
</address>
</author>

<date year="1994" month="March" />
</front>

<seriesInfo value="1592" name="RFC" />
</reference>


<reference target2="reference.RFC.1593.xml" anchor="RFC1593">
<front>
<title>SNA APPN Node MIB</title>
<author fullname="William F. McKenzie" initials="W." surname="McKenzie">
<organization>IBM Networking Systems</organization>

<address>
<postal>
<street>P. O. Box 12195</street>
<city>Research Triangle Park</city>
<region>NC</region>
<code>27709</code>
<country>US</country>
</postal>

<phone>+1 919 254 5705</phone>
<email>mckenzie@ralvma.vnet.ibm.com</email>
</address>
</author>

<author fullname="Jia-bing R. Cheng" initials="J." surname="Cheng">
<organization>IBM Networking Systems</organization>

<address>
<postal>
<street>P. O. Box 12195</street>
<city>Research Triangle Park</city>
<region>NC</region>
<code>27709</code>
<country>US</country>
</postal>

<phone>+1 919 254 4434</phone>
<email>cheng@ralvm6.vnet.ibm.com</email>
</address>
</author>

<date year="1994" month="March" />

<abstract>
<t>This RFC describes IBM's SNMP support for SNA Advanced Peer-to-Peer Networking (APPN) nodes.</t>
</abstract>
</front>

<seriesInfo value="1593" name="RFC" />
</reference>


<reference target2="reference.RFC.1594.xml" anchor="RFC1594">
<front>
<title abbrev="FYI Q/A - for New Internet Users">FYI on Questions and Answers - Answers to Commonly asked "New Internet User" Questions</title>
<author fullname="April N. Marine" initials="A." surname="Marine">
<organization>NASA Ames Research Center, Network Applications and Information Center</organization>

<address>
<postal>
<street>M/S 204-14</street>
<city>Moffett Field</city>
<region>CA</region>
<code>94035-1000</code>
<country>US</country>
</postal>

<phone>+1 415 604 0762</phone>
<email>amarine@atlas.arc.nasa.gov</email>
</address>
</author>

<author fullname="Joyce K. Reynolds" initials="J." surname="Reynolds">
<organization>USC/Information Sciences Institute</organization>

<address>
<postal>
<street>4676 Admiralty Way</street>
<street>Suite 1001</street>
<city>Marina del Rey</city>
<region>CA</region>
<code>90292-6695</code>
<country>US</country>
</postal>

<phone>+1 310 822 1511</phone>
<email>jkrey@isi.edu</email>
</address>
</author>

<author fullname="Gary Scott Malkin" initials="G." surname="Malkin">
<organization>Xylogics, Inc.</organization>

<address>
<postal>
<street>53 Third Avenue</street>
<city>Burlington</city>
<region>MA</region>
<code>01803</code>
<country>US</country>
</postal>

<phone>+1 617 272 8140</phone>
<email>gmalkin@Xylogics.COM</email>
</address>
</author>

<date year="1994" month="March" />

<abstract>
<t>This FYI RFC is one of two FYI's called, "Questions and Answers" (Q/A), produced by the User Services Working Group of the Internet Engineering Task Force (IETF).  The goal is to document the most commonly asked questions and answers in the Internet.</t>
</abstract>
</front>

<seriesInfo value="1594" name="RFC" />
</reference>


<reference target2="reference.RFC.1595.xml" anchor="RFC1595">
<front>
<title abbrev="SONET/SDH Objects">Definitions of Managed Objects for the SONET/SDH Interface Type</title>
<author fullname="Tracy A. Brown" initials="T." surname="Brown">
<organization>Bell Communications Research</organization>

<address>
<postal>
<street>331 Newman Springs Road</street>
<street>P.O. Box 7020</street>
<city>Red Bank</city>
<region>NJ</region>
<code>07701-7020</code>
<country>US</country>
</postal>

<phone>+1 908 758 2107</phone>
<email>tacox@mail.bellcore.com</email>
</address>
</author>

<author fullname="Kaj Tesink" initials="K." surname="Tesink">
<organization>Bell Communications Research</organization>

<address>
<postal>
<street>331 Newman Springs Road</street>
<street>P.O. Box 7020</street>
<city>Red Bank</city>
<region>NJ</region>
<code>07701-7020</code>
<country>US</country>
</postal>

<phone>+1 908 758 5254</phone>
<email>kaj@cc.bellcore.com</email>
</address>
</author>

<date year="1994" month="March" />

<abstract>
<t>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) objects.  This document is a companion document with Definitions of Managed Objects for the DS1/E1 and DS3/E3 Interface Types, RFC1406and RFC1407.</t>

<t>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.</t>
</abstract>
</front>

<seriesInfo value="1595" name="RFC" />
</reference>


<reference target2="reference.RFC.1596.xml" anchor="RFC1596">
<front>
<title abbrev="Frame Relay Service MIB">Definitions of Managed Objects for Frame Relay Service</title>
<author fullname="Tracy A. Brown" initials="T.A." surname="Brown">
<organization>Bell Communications Research</organization>

<address>
<postal>
<street>331 Newman Springs Road</street>
<street>P.O. Box 7020</street>
<city>Red Bank</city>
<region>NJ</region>
<code>07701-7020</code>
<country>US</country>
</postal>

<phone>+1 908 758 2107</phone>
<email>tacox@mail.bellcore.com</email>
</address>
</author>

<date year="1994" month="March" />

<abstract>
<t>This memo defines an extension to the Management Information Base (MIB) for use with network management protocols in TCP/IP-based internets.  In particular, it defines objects for managing the Frame Relay Service.</t>
</abstract>
</front>

<seriesInfo value="1596" name="RFC" />
</reference>


<reference target2="reference.RFC.1597.xml" anchor="RFC1597">
<front>
<title>Address Allocation for Private Internets</title>
<author fullname="Yakov Rekhter" initials="Y." surname="Rekhter">
<organization>IBM Corp, T.J. Watson Research Center</organization>

<address>
<postal>
<street>P.O. Box 218</street>
<city>Yorktown Heights</city>
<region>NY</region>
<code>10598</code>
<country>US</country>
</postal>

<phone>+1 914 945 3896</phone>
<facsimile>+1 914 945 2141</facsimile>
<email>yakov@watson.ibm.com</email>
</address>
</author>

<author fullname="Robert G Moskowitz" initials="R.G." surname="Moskowitz">
<organization>Chrysler Corporation</organization>

<address>
<postal>
<street>25999 Lawrence Ave</street>
<street>CIMS: 424-73-00</street>
<city>Center Line</city>
<region>MI</region>
<code>48015</code>
<country>US</country>
</postal>

<phone>+1 810 758 8212</phone>
<facsimile>+1 810 758 8173</facsimile>
<email>3858921@mcimail.com</email>
</address>
</author>

<author fullname="Daniel Karrenberg" initials="D." surname="Karrenberg">
<organization>RIPE Network Coordination Centre</organization>

<address>
<postal>
<street>Kruislaan 409</street>
<city>Amsterdam</city>
<region />
<code>1098 SJ</code>
<country>NL</country>
</postal>

<phone>+31 20 5925065</phone>
<facsimile>+31 20 5925090</facsimile>
<email>Daniel.Karrenberg@ripe.net</email>
</address>
</author>

<author fullname="Geert Jan de Groot" initials="G.J." surname="de Groot">
<organization>RIPE Network Coordination Centre</organization>

<address>
<postal>
<street>Kruislaan 409</street>
<city>Amsterdam</city>
<region />
<code>1098 SJ</code>
<country>NL</country>
</postal>

<phone>+31 20 5925065</phone>
<facsimile>+31 20 5925090</facsimile>
<email>GeertJan.deGroot@ripe.net</email>
</address>
</author>

<date year="1994" month="March" />
</front>

<seriesInfo value="1597" name="RFC" />
</reference>


<reference target2="reference.RFC.1598.xml" anchor="RFC1598">
<front>
<title>PPP in X.25</title>
<author fullname="William Allen Simpson" initials="W." surname="Simpson">
<organization>Daydreamer, Computer Systems Consulting Services</organization>

<address>
<postal>
<street>1384 Fontaine</street>
<city>Madison Heights</city>
<region>MI</region>
<code>48071</code>
<country>US</country>
</postal>

<email>Bill.Simpson@um.cc.umich.edu</email>
</address>
</author>

<date year="1994" month="March" />

<abstract>
<t>The Point-to-Point Protocol (PPP)provides a standard method for transporting multi-protocol datagrams over point-to-point links. This document describes the use of X.25 for framing PPP encapsulated packets.</t>

<t>This document is the product of the Point-to-Point Protocol Working Group of the Internet Engineering Task Force (IETF).  Comments should be submitted to the ietf-ppp@merit.edu mailing list.</t>
</abstract>
</front>

<seriesInfo value="1598" name="RFC" />
</reference>


<reference target2="reference.RFC.1599.xml" anchor="RFC1599">
<front>
<title abbrev="Summary of 1500-1599">Summary of 1500-1599</title>
<author fullname="Mary Kennedy" initials="M." surname="Kennedy">
<organization>University of Southern California (USC), Information Sciences Institute</organization>

<address>
<postal>
<street>4676 Admiralty Way</street>
<city>Marina del Rey</city>
<region>CA</region>
<code>90292</code>
<country>US</country>
</postal>

<phone>+1 310 822 1511</phone>
<email>MKENNEDY@ISI.EDU</email>
</address>
</author>

<date year="1997" month="January" />
</front>

<seriesInfo value="1599" name="RFC" />
</reference>


<reference target2="reference.RFC.1600.xml" anchor="RFC1600">
<front>
<title abbrev="Internet Standards">Internet Official Protocol Standards</title>
<author fullname="Jon Postel" initials="J." surname="Postel">
<organization>USC/Information Sciences Institute</organization>

<address>
<postal>
<street>4676 Admiralty Way</street>
<city>Marina del Rey</city>
<region>CA</region>
<code>90292</code>
<country>US</country>
</postal>

<phone>+1 310 822 1511</phone>
<facsimile>+1 310 823 6714</facsimile>
<email>Postel@ISI.EDU</email>
</address>
</author>

<date year="1994" month="March" />

<abstract>
<t></t>
</abstract>
</front>

<seriesInfo value="1600" name="RFC" />
</reference>


<reference target2="reference.RFC.1601.xml" anchor="RFC1601">
<front>
<title abbrev="IAB Charter">Charter of the Internet Architecture Board (IAB)</title>
<author fullname="Christian Huitema" initials="C." surname="Huitema">
<organization>INRIA</organization>

<address>
<postal>
<street>2004 Route des Lucioles</street>
<street>BP 93</street>
<city>SOPHIA-ANTIPOLIS Cedex</city>
<region />
<code>06092</code>
<country>FR</country>
</postal>

<email>Christian.Huitema@sophia.inria.fr</email>
</address>
</author>

<date year="1994" month="March" />

<abstract>
<t>This memo documents the composition, selection, roles, and organization of the Internet Architecture Board and its subsidiary organizations.</t>
</abstract>
</front>

<seriesInfo value="1601" name="RFC" />
</reference>


<reference target2="reference.RFC.1602.xml" anchor="RFC1602">
<front>
<title abbrev="Internet Standards Process">The Internet Standards Process -- Revision 2</title>
<author fullname="Christian Huitema" initials="C." surname="Huitema">
<organization>INRIA, Sophia-Antipolis</organization>

<address>
<postal>
<street>2004 Route des Lucioles</street>
<street>BP 109</street>
<city>Valbonne Cedex</city>
<region />
<code>F-06561</code>
<country>FR</country>
</postal>

<phone>+33 93 657715</phone>
<email>Christian.Huitema@MIRSA.INRIA.FR</email>
</address>
</author>

<author fullname="Phill Gross" initials="P." surname="Gross">
<organization>MCI Data Services Division</organization>

<address>
<postal>
<street>2100 Reston Parkway</street>
<street>Room 6001</street>
<city>Reston</city>
<region>VA</region>
<code>22091</code>
<country>US</country>
</postal>

<phone>+1 703 715 7432</phone>
<facsimile>+1 703 715 7436</facsimile>
<email>0006423401@mcimail.com</email>
</address>
</author>

<date year="1994" month="March" />

<abstract>
<t>This document is a revision of RFC 1310, which defined the official procedures for creating and documenting Internet Standards.</t>

<t>This revision (revision 2) includes the following major changes:</t>

<t>(a)  The new management structure arising from the POISED Working Group is reflected.  These changes were agreed to by the IETF plenary and by the IAB and IESG in November 1992 and accepted by the ISOC Board of Trustees at their December 1992 meeting.</t>

<t>(b)  Prototype status is added to the non-standards track maturity levels (Section 2.4.1).</t>

<t>(c)  The Intellectual Property Rights section is completely revised, in accordance with legal advice.  Section 5 of this document replaces Sections 5 and 6 of RFC-1310.  The new section 5 has been reviewed by legal counsel to the Internet Society.</t>

<t>(d)  An appeals procedure is added (Section 3.6).</t>

<t>(e)  The wording of sections 1 and 1.2 has been changed to clarify the relationships that exist between the Internet Society and the IAB, the IESG, the IETF, and the Internet Standards process.</t>

<t>(f)  An Appendix B has been added, listing the contact points for the RFC editor, the IANA, the IESG, the IAB and the ISOC. The "future issues" are now listed in Appendix C.</t>
</abstract>
</front>

<seriesInfo value="1602" name="RFC" />
</reference>


<reference target2="reference.RFC.1603.xml" anchor="RFC1603">
<front>
<title abbrev="IETF Working Group Guidelines">IETF Working Group Guidelines and Procedures</title>
<author fullname="Erik Huizer" initials="E." surname="Huizer">
<organization>SURFnet bv</organization>

<address>
<postal>
<street>P.O. Box 19035</street>
<city>Utrecht</city>
<region />
<code>3501 DA</code>
<country>NL</country>
</postal>

<phone>+31 30 310290</phone>
<facsimile>+31 30 340903</facsimile>
<email>Erik.Huizer@SURFnet.nl</email>
</address>
</author>

<author fullname="Dave Crocker" initials="D." surname="Crocker">
<organization>Silicon Graphics, Inc.</organization>

<address>
<postal>
<street>2011 N. Shoreline Blvd.</street>
<street>P.O. Box 7311</street>
<city>Mountain View</city>
<region>CA</region>
<code>94039</code>
<country>US</country>
</postal>

<phone>+1 415 390 1804</phone>
<facsimile>+1 415 962 8404</facsimile>
<email>dcrocker@sgi.com</email>
</address>
</author>

<date year="1994" month="March" />

<abstract>
<t>The Internet Engineering Task Force (IETF) has responsibility for developing and reviewing specifications intended as Internet Standards. IETF activities are organized into working groups (WGs). This document describes the guidelines and procedures for formation and operation of IETF working groups. It describes the formal relationship between IETF participants WG and the Internet Engineering Steering Group (IESG). The basic duties of IETF participants, including WG Chair and IESG Area Directors are defined.</t>
</abstract>
</front>

<seriesInfo value="1603" name="RFC" />
</reference>


<reference target2="reference.RFC.1604.xml" anchor="RFC1604">
<front>
<title abbrev="Frame Relay Service MIB">Definitions of Managed Objects for Frame Relay Service</title>
<author fullname="Tracy A. Brown" initials="T." surname="Brown">
<organization>Bell Communications Research</organization>

<address>
<postal>
<street>331 Newman Springs Road</street>
<street>P.O. Box 7020</street>
<city>Red Bank</city>
<region>NJ</region>
<code>07701-7020</code>
<country>US</country>
</postal>

<phone>+1 908 758 2107</phone>
<email>tacox@mail.bellcore.com</email>
</address>
</author>

<date year="1994" month="March" />

<abstract>
<t>This memo defines an extension to the Management Information Base (MIB) for use with network management protocols in TCP/IP-based internets.  In particular, it defines objects for managing the Frame Relay Service.</t>
</abstract>
</front>

<seriesInfo value="1604" name="RFC" />
</reference>


<reference target2="reference.RFC.1605.xml" anchor="RFC1605">
<front>
<title>SONET to Sonnet Translation</title>
<author fullname="William Shakespeare" initials="W." surname="Shakespeare">
<organization>Globe Communications</organization>

<address>
<postal>
<street />
<city>Stratford upon Avon</city>
<region>England</region>
<code>CV37 6YR</code>
<country>UK</country>
</postal>

</address>
</author>

<date year="1994" day="1" month="April" />

<abstract>
<t>Because Synchronous Optical Network (SONET) transmits data in frames of bytes, it is fairly easy to envision ways to compress SONET frames to yield higher bandwidth over a given fiber optic link.  This memo describes a particular method, SONET Over Novel English Translation (SONNET).</t>
</abstract>
</front>

<seriesInfo value="1605" name="RFC" />
</reference>


<reference target2="reference.RFC.1606.xml" anchor="RFC1606">
<front>
<title abbrev="Historical Perspective Usage of IP V9">A Historical Perspective On The Usage Of IP Version 9</title>
<author fullname="Julian Onions" initials="J." surname="Onions">
<organization>Nexor Ltd.</organization>

<address>
<postal>
<street>PO Box 132</street>
<city>Nottingham</city>
<region>ENGLAND</region>
<code>NG7 2UU</code>
<country>UK</country>
</postal>

<phone>+44 602 520580</phone>
<email>j.onions@nexor.co.uk</email>
</address>
</author>

<date year="1994" day="1" month="April" />

<abstract>
<t>This paper reviews the usages of the old IP version protocol. It considers some of its successes and its failures.</t>
</abstract>
</front>

<seriesInfo value="1606" name="RFC" />
</reference>


<reference target2="reference.RFC.1607.xml" anchor="RFC1607">
<front>
<title abbrev="A View from the 21st Century">A VIEW FROM THE 21ST CENTURY</title>
<author fullname="Vinton Cerf" initials="V." surname="Cerf">
<organization>Internet Society</organization>

<address>
<postal>
<street>12020 Sunrise Valley Drive</street>
<street>Suite 270</street>
<city>Reston</city>
<region>VA</region>
<code>22091</code>
<country>US</country>
</postal>

<phone>+1 703 648 9888</phone>
<facsimile>+1 703 648 9887</facsimile>
<email>vcerf@isoc.org</email>
</address>
</author>

<author fullname="Vinton Cerf" initials="V." surname="Cerf">
<organization>MCI Data Services Division,  Sr. VP Data Architecture</organization>

<address>
<postal>
<street>2100 Reston Parkway</street>
<street>Room 6001</street>
<city>Reston</city>
<region>VA</region>
<code>22091</code>
<country>US</country>
</postal>

<phone>+1 703 715 7432</phone>
<facsimile>+1 703 715 7436</facsimile>
<email>vinton_cerf@mcimail.com</email>
</address>
</author>

<date year="1994" day="1" month="April" />
</front>

<seriesInfo value="1607" name="RFC" />
</reference>


<reference target2="reference.RFC.1608.xml" anchor="RFC1608">
<front>
<title abbrev="IP Information in the X.500 Directory">Representing IP Information in the X.500 Directory</title>
<author fullname="Thomas Johannsen" initials="T." surname="Johannsen">
<organization>Dresden University of Technology, Institute of Communication Technology</organization>

<address>
<postal>
<street />
<city>Dresden</city>
<region />
<code>D-01062</code>
<country>DE</country>
</postal>

<phone>+49 351 4634621</phone>
<email>Thomas.Johannsen@ifn.et.tu-dresden.de</email>
</address>
</author>

<author fullname="Glenn Mansfield" initials="G." surname="Mansfield">
<organization>AIC Systems Laboratory</organization>

<address>
<postal>
<street>6-6-3 Minami Yoshinari</street>
<city>Aoba-ku</city>
<region>Sendai</region>
<code>989-32</code>
<country>JP</country>
</postal>

<phone>+81 22 2793310</phone>
<email>glenn@aic.co.jp</email>
</address>
</author>

<author fullname="Mark Kosters" initials="M." surname="Kosters">
<organization>Network Solutions, Inc.</organization>

<address>
<postal>
<street>505 Huntmar Park Dr.</street>
<city>Herndon</city>
<region>VA</region>
<code>22070</code>
<country>US</country>
</postal>

<phone>+1 703 742 4795</phone>
<email>markk@internic.net</email>
</address>
</author>

<author fullname="Srinivas R. Sataluri" initials="S." surname="Sataluri">
<organization>AT&amp;T Bell Laboratories</organization>

<address>
<postal>
<street>101 Crawfords Corner Road</street>
<street>Room 1C-429</street>
<city>Holmdel</city>
<region>NJ</region>
<code>07733-3030</code>
<country>US</country>
</postal>

<phone>+1 908 949 7782</phone>
<email>sri@qsun.att.com</email>
</address>
</author>

<date year="1994" month="March" />

<abstract>
<t>This document describes the objects necessary to include information about IP networks and IP numbers in the X.500 Directory. It extends the work "Charting networks in the X.500 Directory"where a general framework is presented for representing networks in the Directory by applying it to IP networks.  This application of the
 Directory is intended to support the work of IP network assigning authorities, NICs, as well as other applications looking for a mapping of IP numbers to data of related networks. Furthermore, Autonomous Systems and related routing policy information can be represented in the Directory along with their relationship to networks and organizations.</t>
</abstract>
</front>

<seriesInfo value="1608" name="RFC" />
</reference>


<reference target2="reference.RFC.1609.xml" anchor="RFC1609">
<front>
<title>Charting Networks in the X.500 Directory</title>
<author fullname="Glenn Mansfield" initials="G." surname="Mansfield">
<organization>AIC Systems Laboratory</organization>

<address>
<postal>
<street>6-6-3 Minami Yoshinari</street>
<city>Aoba-ku</city>
<region>Sendai</region>
<code>989-32</code>
<country>JP</country>
</postal>

<phone>+81 22 2793310</phone>
<email>glenn@aic.co.jp</email>
</address>
</author>

<author fullname="Thomas Johannsen" initials="T." surname="Johannsen">
<organization>Dresden University of Technology, Institute of Communication Technology</organization>

<address>
<postal>
<street />
<city>Dresden</city>
<region />
<code>D-01062</code>
<country>DE</country>
</postal>

<phone>+49 351 4634621</phone>
<email>Thomas.Johannsen@ifn.et.tu-dresden.de</email>
</address>
</author>

<author fullname="Mark Knopper" initials="M." surname="Knopper">
<organization>Merit Network, Inc.</organization>

<address>
<postal>
<street>1071 Beal Avenue</street>
<city>Ann Arbor</city>
<region>MI</region>
<code>48109</code>
<country>US</country>
</postal>

<email>mak@merit.edu</email>
</address>
</author>

<date year="1994" month="March" />

<abstract>
<t>There is a need for a framework wherein the infrastructural and service related information about communication networks can be made accessible from all places and at all times in a reasonably efficient manner and with reasonable accuracy.  This document presents a model in which a communication network with all its related details and descriptions can be represented in the X.500 Directory. Schemas of objects and their attributes which may be used for this purpose are presented.  The model envisages physical objects and several logical abstractions of the physical objects.</t>
</abstract>
</front>

<seriesInfo value="1609" name="RFC" />
</reference>


<reference target2="reference.RFC.1610.xml" anchor="RFC1610">
<front>
<title abbrev="Internet Standards">Internet Official Protocol Standards</title>
<author fullname="Jon Postel" initials="J." surname="Postel">
<organization>USC/Information Sciences Institute</organization>

<address>
<postal>
<street>4676 Admiralty Way</street>
<city>Marina del Rey</city>
<region>CA</region>
<code>90292</code>
<country>US</country>
</postal>

<phone>+1 310 822 1511</phone>
<facsimile>+1 310 823 6714</facsimile>
<email>Postel@ISI.EDU</email>
</address>
</author>

<date year="1994" month="July" />
</front>

<seriesInfo value="1610" name="RFC" />
</reference>


<reference target2="reference.RFC.1611.xml" anchor="RFC1611">
<front>
<title>DNS Server MIB Extensions</title>
<author fullname="Rob Austein" initials="R." surname="Austein">
<organization>Epilogue Technology Corporation</organization>

<address>
<postal>
<street>268 Main Street</street>
<street>Suite 283</street>
<city>North Reading</city>
<region>MA</region>
<code>01864</code>
<country>US</country>
</postal>

<phone>+1 617 245 0804</phone>
<facsimile>+1 617 245 8122</facsimile>
<email>sra@epilogue.com</email>
</address>
</author>

<author fullname="Jon Saperia" initials="J." surname="Saperia">
<organization>Digital Equipment Corporation</organization>

<address>
<postal>
<street>110 Spit Brook Road</street>
<street>ZKO1-3/H18</street>
<city>Nashua</city>
<region>NH</region>
<code>03062-2698</code>
<country>US</country>
</postal>

<phone>+1 603 881 0480</phone>
<facsimile>+1 603 881 0120</facsimile>
<email>saperia@zko.dec.com</email>
</address>
</author>

<date year="1994" month="May" />
</front>

<seriesInfo value="1611" name="RFC" />
</reference>


<reference target2="reference.RFC.1612.xml" anchor="RFC1612">
<front>
<title abbrev="DNS Resolver MIB">DNS Resolver MIB Extensions</title>
<author fullname="Rob Austein" initials="R." surname="Austein">
<organization>Epilogue Technology Corporation</organization>

<address>
<postal>
<street>268 Main Street</street>
<street>Suite 283</street>
<city>North Reading</city>
<region>MA</region>
<code>01864</code>
<country>US</country>
</postal>

<phone>+1 617 245 0804</phone>
<facsimile>+1 617 245 8122</facsimile>
<email>sra@epilogue.com</email>
</address>
</author>

<author fullname="Jon Saperia" initials="J." surname="Saperia">
<organization>Digital Equipment Corporation</organization>

<address>
<postal>
<street>110 Spit Brook Road</street>
<street>ZKO1-3/H18</street>
<city>Nashua</city>
<region>NH</region>
<code>03062-2698</code>
<country>US</country>
</postal>

<phone>+1 603 881 0480</phone>
<facsimile>+1 603 881 0120</facsimile>
<email>saperia@zko.dec.com</email>
</address>
</author>

<date year="1994" month="May" />

<abstract>
<t></t>
</abstract>
</front>

<seriesInfo value="1612" name="RFC" />
</reference>


<reference target2="reference.RFC.1613.xml" anchor="RFC1613">
<front>
<title abbrev="X.25 Over TCP (XOT)">cisco Systems X.25 over TCP (XOT)</title>
<author fullname="James R. Forster" initials="J." surname="Forster">
<organization>cisco Systems, Engineering Dept.</organization>

<address>
<postal>
<street>1525 O'Brien Dr.</street>
<city>Menlo Park</city>
<region>CA</region>
<code>94025</code>
<country>US</country>
</postal>

<phone>+1 415 688 8245</phone>
<facsimile>+1 415 688 8282</facsimile>
<email>forster@cisco.com</email>
</address>
</author>

<author fullname="Greg Satz" initials="G." surname="Satz">
<organization>cisco Systems, Engineering Dept.</organization>

<address>
<postal>
<street>1525 O'Brien Dr.</street>
<city>Menlo Park</city>
<region>CA</region>
<code>94025</code>
<country>US</country>
</postal>

<phone>+1 415 688 8245</phone>
<facsimile>+1 415 688 8282</facsimile>
<email>satz@cisco.com</email>
</address>
</author>

<author fullname="Gilbert Glick" initials="G." surname="Glick">
<organization>cisco Systems, Engineering Dept.</organization>

<address>
<postal>
<street>1525 O'Brien Dr.</street>
<city>Menlo Park</city>
<region>CA</region>
<code>94025</code>
<country>US</country>
</postal>

<phone>+1 415 688 8245</phone>
<facsimile>+1 415 688 8282</facsimile>
<email>gglick@cisco.com</email>
</address>
</author>

<author fullname="Bob Day" initials="B." surname="Day">
<organization>Joint Network Team c/o Rutherford Appleton Laboratory</organization>

<address>
<postal>
<street>Chilton</street>
<city>Didcot, Oxfordshire</city>
<region>England</region>
<code>OX11 0QX</code>
<country>UK</country>
</postal>

<phone>+44 235 445163</phone>
<facsimile>+44 235 446251</facsimile>
<email>R.Day@jnt.ac.uk</email>
</address>
</author>

<date year="1994" month="May" />

<abstract>
<t></t>
</abstract>
</front>

<seriesInfo value="1613" name="RFC" />
</reference>


<reference target2="reference.RFC.1614.xml" anchor="RFC1614">
<front>
<title>Network Access to Multimedia Information</title>
<author fullname="Chris Adie" initials="C." surname="Adie">
<organization>University of Edinburgh, University Library</organization>

<address>
<postal>
<street>George Square</street>
<city>Edinburgh</city>
<region>Scotland</region>
<code>EH8 9LJ</code>
<country>UK</country>
</postal>

<phone>+44 31 6503363</phone>
<facsimile>+44 31 6624809</facsimile>
<email>C.J.Adie@edinburgh.ac.uk</email>
</address>
</author>

<date year="1994" month="May" />

<abstract>
<t>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 currentlydeployed systems and the user requirements, and proposes further work centred on the World-Wide Web system to rectify this.</t>

<t>The report is in some places very detailed, so it is preceded by an extended summary, which outlines the findings of the report.</t>
</abstract>
</front>

<seriesInfo value="1614" name="RFC" />
</reference>


<reference target2="reference.RFC.1615.xml" anchor="RFC1615">
<front>
<title>Migrating from X.400(84) to X.400(88)</title>
<author fullname="Jeroen Houttuin" initials="J." surname="Houttuin">
<organization>RARE Secretariat</organization>

<address>
<postal>
<street>Singel 466-468</street>
<city>Amsterdam</city>
<region />
<code>NL-1017 AW</code>
<country>NL</country>
</postal>

<phone>+31 20 6391131</phone>
<email>houttuin@rare.nl</email>
</address>
</author>

<author fullname="Jim Craigie" initials="J." surname="Craigie">
<organization>Rutherford Appleton Laboratory, Joint Network Team</organization>

<address>
<postal>
<street>Chilton</street>
<city>Didcot</city>
<region>Oxfordshire</region>
<code>OX11 OQX</code>
<country>UK</country>
</postal>

<phone>+44 235 445539</phone>
<email>J.Craigie@jnt.ac.uk</email>
</address>
</author>

<date year="1994" month="May" />

<abstract>
<t>This document compares X.400(88) to X.400(84) and describes what problems can be anticipated in the migration, especially considering the migration from the existing X.400(84) infrastructure created by the COSINE MHS project to an X.400(88) infrastructure. It not only describes the technical complications, but also the effect the transition will have on the end users, especially concerning interworking between end users of the 84 and the 88 services.</t>
</abstract>
</front>

<seriesInfo value="1615" name="RFC" />
</reference>


<reference target2="reference.RFC.1616.xml" anchor="RFC1616">
<front>
<title abbrev="X.400(88) for European Academics and Research">X.400(1988) for the Academic and Research Community in Europe</title>
<author fullname="Erik Huizer" initials="E." surname="Huizer">
<organization>SURFnet bv</organization>

<address>
<postal>
<street>P.O. Box 19035</street>
<city>Utrecht</city>
<region />
<code>NL-3501</code>
<country>NL</country>
</postal>

<phone>+31 30 310290</phone>
<email>huizer@surfnet.nl</email>
</address>
</author>

<author fullname="James A. (Jim) Romaguera" initials="J." surname="Romaguera">
<organization>NetConsult AG</organization>

<address>
<postal>
<street>Morgenstrasse 129</street>
<street>Berner Technopark</street>
<city>Bern</city>
<region />
<code>CH-3018</code>
<country>CH</country>
</postal>

<phone>+41 31 9984141</phone>
<email>romaguera@netconsult.ch</email>
</address>
</author>

<date year="1994" month="May" />

<abstract>
<t>The European research and development community, as represented by the member research networks of RARE, has lead the deployment within the global R&amp;D community of X.400 electronic messaging services, as specified in the international recommendations CCITT X.400(1984), for more than five years. As a result of providing such services to the European R&amp;amp;D users it has become clear that there is an existing and ever increasing demand from these users for new and enhanced electronic messaging services and product to be used to communicate within the R&amp;amp;D community but within commercial service providers and organisations as well.</t>

<t>It is also clear that new services, such as Multimedia messaging and Secure messaging, and the resulting products promise dramatic benefits and opportunities, for not only the R&amp;amp;D community but also for the wider commercial, industrial and public communities, in terms of facilitating innovative ways of working and living which can only enhance the missions and goals of the respective communities. Not least the establishment of globally pervasive messaging services between all users, R&amp;amp;D and commercial, is facilitated by the early adoption of such advanced new services. An indication of the importance of such a messaging service can be appreciated if one considers that in many organizations (especially commercially based) messaging may be the only method to communicate between independent organizations due to security considerations and lower layer network differences.</t>

<t>The Commission of European Communities (CEC) VALUE subprogram II has been established to support initiatives relating to the development and adaptation of R&amp;amp;D networks in member states.  Amongst other initiatives the VALUE program supports X.400 initiatives in certain countries. VALUE support has so far been limited to X.400(1984) initiatives, as X.400(1984) has up until now been the dominating OSI services. However as X.400(1988) implementations have started to appear a VALUE funded study of the X.400(1988) aspects of messaging and their impact on the R&amp;amp;D community was felt necessary. This report is one of the results of that study.</t>

<t>The report documents the results of a task force on X.400(1988) deployment of the RARE Mails and Messaging Work Group during the period from November 1992 until October 1993. Open reviews of the report have occurred in the RARE Mail and Messaging Work Group and within the IETF X.400ops Working Group.</t>

<t>The scope of the report is limited to deployment of X.400(1988) services, and as such the report does not contain any recommendations on development and deployment of Internet RFC 822 / MIME/ PEM related (pilot) services. However, since the report shows that both X.400(1988) and RFC 822 / MIME / PEM will be developed and used within the European R&amp;amp;D community, such a pilot should also considered.  Note: RFC 822 is also known as Internet STD 11.</t>

<t>Circulation of this report is unlimited. Comments on this report may be sent to the e-mail distribution list:</t>

<t>RFC 822: wg-msg@rare.nl
    X.400:   	S=wg-msg;O=rare;P=surf;A=400net;C=nl</t>
</abstract>
</front>

<seriesInfo value="1616" name="RFC" />
</reference>


<reference target2="reference.RFC.1617.xml" anchor="RFC1617">
<front>
<title abbrev="Naming and Structuring Guidelines for X.500">Naming and Structuring Guidelines for X.500 Directory Pilots</title>
<author fullname="Paul Barker" initials="P." surname="Barker">
<organization>University College London, Department of Computer Science</organization>

<address>
<postal>
<street>Gower Street</street>
<city>London</city>
<region>England</region>
<code>WC1E 6BT</code>
<country>UK</country>
</postal>

<phone>+44 71 3807366</phone>
<email>p.barker@cs.ucl.ac.uk</email>
</address>
</author>

<author fullname="Steve Kille" initials="S." surname="Kille">
<organization>ISODE Consortium</organization>

<address>
<postal>
<street>The Dome, The Square</street>
<city>Richmond</city>
<region>England</region>
<code>TW9 1DT</code>
<country>UK</country>
</postal>

<phone>+44 81 3329091</phone>
<email>s.kille@isode.com</email>
</address>
</author>

<author fullname="Thomas Lenggenhager" initials="T." surname="Lenggenhager">
<organization>SWITCH</organization>

<address>
<postal>
<street>Limmatquai 138</street>
<city>Zurich</city>
<region />
<code>CH-8001</code>
<country>CH</country>
</postal>

<phone>+41 1 2681540</phone>
<email>lenggenhager@switch.ch</email>
</address>
</author>

<date year="1994" month="May" />

<abstract>
<t>Deployment of a Directory will benefit from following certain guidelines. This document defines a number of naming and structuring guidelines focused on White Pages usage. Alignment to these guidelines is recommended for directory pilots. The final version of this document will replace RFC 1384.</t>
</abstract>
</front>

<seriesInfo value="1617" name="RFC" />
</reference>


<reference target2="reference.RFC.1618.xml" anchor="RFC1618">
<front>
<title>PPP over ISDN</title>
<author fullname="William Allen Simpson" initials="W." surname="Simpson">
<organization>Daydreamer, Computer Systems Consulting Services</organization>

<address>
<postal>
<street>1384 Fontaine</street>
<city>Madison Heights</city>
<region>MI</region>
<code>48071</code>
<country>US</country>
</postal>

<email>Bill.Simpson@um.cc.umich.edu</email>
</address>
</author>

<date year="1994" month="May" />

<abstract>
<t>The Point-to-Point Protocol (PPP)provides a standard method for transporting multi-protocol datagrams over point-to-point links. This document describes the use of PPP over Integrated Services Digital Network (ISDN) switched circuits.</t>

<t>This document is the product of the Point-to-Point Protocol Working Group of the Internet Engineering Task Force (IETF).  Comments should be submitted to the ietf-ppp@merit.edu mailing list.</t>
</abstract>
</front>

<seriesInfo value="1618" name="RFC" />
</reference>


<reference target2="reference.RFC.1619.xml" anchor="RFC1619">
<front>
<title>PPP over SONET/SDH</title>
<author fullname="William Allen Simpson" initials="W." surname="Simpson">
<organization>Daydreamer, Computer Systems Consulting Services</organization>

<address>
<postal>
<street>1384 Fontaine</street>
<city>Madison Heights</city>
<region>MI</region>
<code>48071</code>
<country>US</country>
</postal>

<email>Bill.Simpson@um.cc.umich.edu</email>
</address>
</author>

<date year="1994" month="May" />

<abstract>
<t>The Point-to-Point Protocol (PPP)provides a standard method for transporting multi-protocol datagrams over point-to-point links. This document describes the use of PPP over Synchronous Optical Network (SONET) and  Synchronous Digital Heirarchy (SDH) circuits.</t>

<t>This document is the product of the Point-to-Point Protocol Working Group of the Internet Engineering Task Force (IETF).  Comments should be submitted to the ietf-ppp@merit.edu mailing list.</t>
</abstract>
</front>

<seriesInfo value="1619" name="RFC" />
</reference>


<reference target2="reference.RFC.1620.xml" anchor="RFC1620">
<front>
<title abbrev="Shared Media IP Architecture">Internet Architecture Extensions for Shared Media</title>
<author fullname="Bob Braden" initials="B." surname="Braden">
<organization>University of Southern California, Information Sciences Institute</organization>

<address>
<postal>
<street>4676 Admiralty Way</street>
<city>Marina del Rey</city>
<region>CA</region>
<code>90292</code>
<country>US</country>
</postal>

<phone>+1 310 822 1511</phone>
<email>Braden@ISI.EDU</email>
</address>
</author>

<author fullname="Jon Postel" initials="J." surname="Postel">
<organization>University of Southern California, Information Sciences Institute</organization>

<address>
<postal>
<street>4676 Admiralty Way</street>
<city>Marina del Rey</city>
<region>CA</region>
<code>90292</code>
<country>US</country>
</postal>

<phone>+1 310 822 1511</phone>
<email>Postel@ISI.EDU</email>
</address>
</author>

<author fullname="Yakov Rekhter" initials="Y." surname="Rekhter">
<organization>IBM Corp., T.J. Watson Research Center</organization>

<address>
<postal>
<street>P.O. Box 218</street>
<street>Office 32-017</street>
<city>Yorktown Heights</city>
<region>NY</region>
<code>10598</code>
<country>US</country>
</postal>

<phone>+1 914 945 3896</phone>
<email>Yakov@WATSON.IBM.COM</email>
</address>
</author>

<date year="1994" month="May" />

<abstract>
<t>The original Internet architecture assumed that each network is labeled with a single IP network number.  This assumption may be violated for shared media, including "large public data networks" (LPDNs).  The architecture still works if this assumption is violated, but it does not have a means to prevent multiple host- router and router-router hops through the shared medium.  This memo discusses alternative approaches to extending the Internet architecture to eliminate some or all unnecessary hops.</t>
</abstract>
</front>

<seriesInfo value="1620" name="RFC" />
</reference>


<reference target2="reference.RFC.1621.xml" anchor="RFC1621">
<front>
<title>Pip Near-term Architecture</title>
<author fullname="Paul Francis" initials="P." surname="Francis">
<organization>NTT Software Lab</organization>

<address>
<postal>
<street>3-9-11 Midori-cho Musashino-shi</street>
<city>Tokyo</city>
<region />
<code>180</code>
<country>JP</country>
</postal>

<phone>+81 422 593843</phone>
<facsimile>+81 422 593765</facsimile>
<email>francis@cactus.ntt.jp</email>
</address>
</author>

<date year="1994" month="May" />

<abstract>
<t>Pip is an internet protocol intended as the replacement for IP version 4.  Pip is a general purpose internet protocol, designed to evolve to all forseeable internet protocol requirements.  This specification describes the routing and addressing architecture for near-term Pip deployment.  We say near-term only because Pip is designed with evolution in mind, so other architectures are expected in the future.  This document, however, makes no reference to such future architectures.</t>
</abstract>
</front>

<seriesInfo value="1621" name="RFC" />
</reference>


<reference target2="reference.RFC.1622.xml" anchor="RFC1622">
<front>
<title>Pip Header Processing</title>
<author fullname="Paul Francis" initials="P." surname="Francis">
<organization>NTT Software Lab</organization>

<address>
<postal>
<street>3-9-11 Midori-cho Musashino-shi</street>
<city>Tokyo</city>
<region />
<code>180</code>
<country>JP</country>
</postal>

<phone>+81 422 593843</phone>
<facsimile>+81 422 593765</facsimile>
<email>francis@cactus.ntt.jp</email>
</address>
</author>

<date year="1994" month="May" />

<abstract>
<t>Pip is an internet protocol intended as the replacement for IP version 4.  Pip is a general purpose internet protocol, designed to handle all forseeable internet protocol requirements.  This specification defines the Pip header processing for Routers and Hosts.</t>
</abstract>
</front>

<seriesInfo value="1622" name="RFC" />
</reference>


<reference target2="reference.RFC.1623.xml" anchor="RFC1623">
<front>
<title abbrev="Ethernet-Like MIB">Definitions of Managed Objects for the Ethernet-like Interface Types</title>
<author fullname="Frank Kastenholz" initials="F." surname="Kastenholz">
<organization>FTP Software, Inc.</organization>

<address>
<postal>
<street>2 High Street</street>
<city>North Andover</city>
<region>MA</region>
<code>01845</code>
<country>US</country>
</postal>

<phone>+1 508 685 4000</phone>
<email>kasten@ftp.com</email>
</address>
</author>

<date year="1994" month="May" />

<abstract>
<t></t>
</abstract>
</front>

<seriesInfo value="1623" name="RFC" />
</reference>


<reference target2="reference.RFC.1624.xml" anchor="RFC1624">
<front>
<title abbrev="Incremental Internet Checksum">Computation of the Internet Checksum via Incremental Update</title>
<author fullname="Anil Rijsinghani" initials="A." surname="Rijsinghani">
<organization>Digital Equipment Corporation</organization>

<address>
<postal>
<street>550 King St</street>
<city>Littleton</city>
<region>MA</region>
<code>01460</code>
<country>US</country>
</postal>

<phone>+1 508 486 6786</phone>
<email>anil@levers.enet.dec.com</email>
</address>
</author>

<date year="1994" month="May" />

<abstract>
<t>This memo describes an updated technique for incremental computation of the standard Internet checksum.  It updates the method described in RFC 1141.</t>
</abstract>
</front>

<seriesInfo value="1624" name="RFC" />
</reference>


<reference target2="reference.RFC.1625.xml" anchor="RFC1625">
<front>
<title>WAIS over Z39.50-1988</title>
<author fullname="Margaret St. Pierre" initials="M." surname="St. Pierre">
<organization>WAIS Incorporated</organization>

<address>
<postal>
<street>1040 Noel Drive</street>
<city>Menlo Park</city>
<region>CA</region>
<code>94025</code>
<country>US</country>
</postal>

<phone>+1 415 327 9247</phone>
<facsimile>+1 415 327 6513</facsimile>
<email>saint@wais.com</email>
</address>
</author>

<author fullname="Jim Fullton" initials="J." surname="Fullton">
<organization>Clearinghouse for Networked Information, Discovery &amp; Retrieval</organization>

<address>
<postal>
<street>3021 Cornwallis Road</street>
<city>Research Triangle Park</city>
<region>NC</region>
<code>27709-2889</code>
<country>US</country>
</postal>

<phone>+1 919 248 9247</phone>
<facsimile>+1 919 248 1101</facsimile>
<email>jim.fullton@cnidr.org</email>
</address>
</author>

<author fullname="Kevin Gamiel" initials="K." surname="Gamiel">
<organization>Clearinghouse for Networked Information, Discovery &amp; Retrieval</organization>

<address>
<postal>
<street>3021 Cornwallis Road</street>
<city>Research Triangle Park</city>
<region>NC</region>
<code>27709-2889</code>
<country>US</country>
</postal>

<phone>+1 919 248 9247</phone>
<facsimile>+1 919 248 1101</facsimile>
<email>kevin.gamiel@cnidr.org</email>
</address>
</author>

<author fullname="Jonathan Goldman" initials="J." surname="Goldman">
<organization>Thinking Machines Corporation</organization>

<address>
<postal>
<street>1010 El Camino Real</street>
<street>Suite 310</street>
<city>Menlo Park</city>
<region>CA</region>
<code>94025</code>
<country>US</country>
</postal>

<phone>+1 415 329 9300 x229</phone>
<facsimile>+1 415 329 9329</facsimile>
<email>jonathan@think.com</email>
</address>
</author>

<author fullname="Brewster Kahle" initials="B." surname="Kahle">
<organization>WAIS Incorporated</organization>

<address>
<postal>
<street>1040 Noel Drive</street>
<city>Menlo Park</city>
<region>CA</region>
<code>94025</code>
<country>US</country>
</postal>

<phone>+1 415 327 9247</phone>
<facsimile>+1 415 327 6513</facsimile>
<email>brewster@wais.com</email>
</address>
</author>

<author fullname="John A. Kunze" initials="J." surname="Kunze">
<organization>UC Berkeley</organization>

<address>
<postal>
<street>289 Evans Hall</street>
<city>Berkeley</city>
<region>CA</region>
<code>94720</code>
<country>US</country>
</postal>

<phone>+1 510 642 1530</phone>
<facsimile>+1 510 643 5385</facsimile>
<email>jak@violet.berkeley.edu</email>
</address>
</author>

<author fullname="Harry Morris" initials="H." surname="Morris">
<organization>WAIS Incorporated</organization>

<address>
<postal>
<street>1040 Noel Drive</street>
<city>Menlo Park</city>
<region>CA</region>
<code>94025</code>
<country>US</country>
</postal>

<phone>+1 415 327 9247</phone>
<facsimile>+1 415 327 6513</facsimile>
<email>morris@wais.com</email>
</address>
</author>

<author fullname="Francois Schiettecatte" initials="F." surname="Schiettecatte">
<organization>FS Consulting</organization>

<address>
<postal>
<street>435 Highland Avenue</street>
<city>Rochester</city>
<region>NY</region>
<code>14620</code>
<country>US</country>
</postal>

<phone>+1 716 256 2850</phone>
<email>francois@wais.com</email>
</address>
</author>

<date year="1994" month="June" />
</front>

<seriesInfo value="1625" name="RFC" />
</reference>


<reference target2="reference.RFC.1626.xml" anchor="RFC1626">
<front>
<title>Default IP MTU for use over ATM AAL5</title>
<author fullname="Randall J. Atkinson" initials="R." surname="Atkinson">
<organization>Naval Research Laboratory, Information Technology Division</organization>

<address>
<postal>
<street />
<city>Washington</city>
<region>DC</region>
<code>20375-5320</code>
<country>US</country>
</postal>

<email>atkinson@itd.nrl.navy.mil</email>
</address>
</author>

<date year="1994" month="May" />
</front>

<seriesInfo value="1626" name="RFC" />
</reference>


<reference target2="reference.RFC.1627.xml" anchor="RFC1627">
<front>
<title abbrev="Network 10 Considered Harmful">Network 10 Considered Harmful (Some Practices Shouldn't be Codified)</title>
<author fullname="Eliot Lear" initials="E." surname="Lear">
<organization>Silicon Graphics, Inc.</organization>

<address>
<postal>
<street>2011 N. Shoreline Blvd.</street>
<city>Mountain View</city>
<region>CA</region>
<code>94043-1389</code>
<country>US</country>
</postal>

<phone>+1 415 390 2414</phone>
<email>lear@sgi.com</email>
</address>
</author>

<author fullname="Erik Fair" initials="E." surname="Fair">
<organization>Apple Computer, Inc.</organization>

<address>
<postal>
<street>1 Infinite Loop</street>
<city>Cupertino</city>
<region>CA</region>
<code>95014</code>
<country>US</country>
</postal>

<phone>+1 408 974 1779</phone>
<email>fair@apple.com</email>
</address>
</author>

<author fullname="Dave Crocker" initials="D." surname="Crocker">
<organization>Silicon Graphics, Inc.</organization>

<address>
<postal>
<street>2011 N. Shoreline Blvd.</street>
<city>Mountain View</city>
<region>CA</region>
<code>94043-1389</code>
<country>US</country>
</postal>

<phone>+1 415 390 1804</phone>
<email>dcrocker@sgi.com</email>
</address>
</author>

<author fullname="Thomas Kessler" initials="T." surname="Kessler">
<organization>Sun Microsystems Inc.</organization>

<address>
<postal>
<street>2550 Garcia Ave.</street>
<street>Mail Stop MTV05-44</street>
<city>Mountain View</city>
<region>CA</region>
<code>94043</code>
<country>US</country>
</postal>

<phone>+1 415 336 3145</phone>
<email>kessler@eng.sun.com</email>
</address>
</author>

<date year="1994" month="July" />
</front>

<seriesInfo value="1627" name="RFC" />
</reference>


<reference target2="reference.RFC.1628.xml" anchor="RFC1628">
<front>
<title abbrev="UPS MIB">UPS Management Information Base</title>
<author fullname="Jeffrey D. Case." initials="J." surname="Case">
<organization>SNMP Research, Incorporated</organization>

<address>
<postal>
<street>3001 Kimberlin Heights Road</street>
<city>Knoxville</city>
<region>TN</region>
<code>37920</code>
<country>US</country>
</postal>

<phone>+1 615 573 1434</phone>
<email>case@SNMP.COM</email>
</address>
</author>

<date year="1994" month="May" />

<abstract>
<t></t>
</abstract>
</front>

<seriesInfo value="1628" name="RFC" />
</reference>


<reference target2="reference.RFC.1629.xml" anchor="RFC1629">
<front>
<title abbrev="NSAP Guidelines">Guidelines for OSI NSAP Allocation in the Internet</title>
<author fullname="Richard P. Colella" initials="R." surname="Colella">
<organization>National Institute of Standards &amp; Technology</organization>

<address>
<postal>
<street>Building 225/Room B217</street>
<city>Gaithersburg</city>
<region>MD</region>
<code>20899</code>
<country>US</country>
</postal>

<phone>+1 301 975 3627</phone>
<email>colella@nist.gov</email>
</address>
</author>

<author fullname="Ross Callon" initials="R." surname="Callon">
<organization>Wellfleet Communications, Inc</organization>

<address>
<postal>
<street>2 Federal Street</street>
<city>Billerica</city>
<region>MA</region>
<code>01821</code>
<country>US</country>
</postal>

<phone>+1 508 436 3936</phone>
<email>callon@wellfleet.com</email>
</address>
</author>

<author fullname="Ella P. Gardner" initials="E." surname="Gardner">
<organization>The MITRE Corporation</organization>

<address>
<postal>
<street>7525 Colshire Drive</street>
<city>McLean</city>
<region>VA</region>
<code>22102-3481</code>
<country>US</country>
</postal>

<phone>+1 703 883 5826</phone>
<email>epg@gateway.mitre.org</email>
</address>
</author>

<author fullname="Yakov Rekhter" initials="Y." surname="Rekhter">
<organization>IBM Corporation, T.J. Watson Research Center</organization>

<address>
<postal>
<street>P.O. Box 218</street>
<city>Yorktown Heights</city>
<region>NY</region>
<code>10598</code>
<country>US</country>
</postal>

<phone>+1 914 945 3896</phone>
<email>yakov@watson.ibm.com</email>
</address>
</author>

<date year="1994" month="May" />

<abstract>
<t>CLNP is currently being deployed in the Internet.  This is useful to support OSI and DECnet(tm) traffic.  In addition, CLNP has been proposed as a possible IPng candidate, to provide a long-term solution to IP address exhaustion.  Required as part of the CLNP infrastructure are guidelines for network service access point (NSAP) address assignment.  This paper provides guidelines for allocating NSAP addresses in the Internet.</t>

<t>The guidelines provided in this paper have been the basis for initial deployment of CLNP in the Internet, and have proven very valuable both as an aid to scaling of CLNP routing, and for address administration.</t>
</abstract>
</front>

<seriesInfo value="1629" name="RFC" />
</reference>


<reference target2="reference.RFC.1630.xml" anchor="RFC1630">
<front>
<title abbrev="URIs in WWW">Universal Resource Identifiers in WWW: A Unifying Syntax for the Expression of Names and Addresses of Objects on the Network as used in the World-Wide Web</title>
<author fullname="Tim Berners-Lee" initials="T." surname="Berners-Lee">
<organization>CERN, World-Wide Web project</organization>

<address>
<postal>
<street>1211 Geneva 23</street>
<city />
<region />
<code />
<country>CH</country>
</postal>

<phone>+41 22 7673755</phone>
<facsimile>+41 22 7677155</facsimile>
<email>timbl@info.cern.ch</email>
</address>
</author>

<date year="1994" month="June" />
</front>

<seriesInfo value="1630" name="RFC" />
</reference>


<reference target2="reference.RFC.1631.xml" anchor="RFC1631">
<front>
<title abbrev="Network Address Translator">The IP Network Address Translator (NAT)</title>
<author fullname="Kjeld Borch Egevang" initials="K.B." surname="Egevang">
<organization>Cray Communications</organization>

<address>
<postal>
<street>Smedeholm 12-14</street>
<city>Herlev</city>
<region />
<code>DK-2730</code>
<country>DK</country>
</postal>

<phone>+45 44 530100</phone>
<email>kbe@craycom.dk</email>
</address>
</author>

<author fullname="Paul Francis" initials="P." surname="Francis">
<organization>NTT Software Lab</organization>

<address>
<postal>
<street>3-9-11 Midori-cho Musashino-shi</street>
<city>Tokyo</city>
<region />
<code>180</code>
<country>JP</country>
</postal>

<phone>+81 422 593843</phone>
<facsimile>+81 422 593765</facsimile>
<email>francis@cactus.ntt.jp</email>
</address>
</author>

<date year="1994" month="May" />

<abstract>
<t>The two most compelling problems facing the IP Internet are IP address depletion and scaling in routing. Long-term and short-term solutions to these problems are being developed. The short-term solution is CIDR (Classless InterDomain Routing). The long-term solutions consist of various proposals for new internet protocols with larger addresses.</t>

<t>It is possible that CIDR will not be adequate to maintain the IP Internet until the long-term solutions are in place. This memo proposes another short-term solution, address reuse, that complements CIDR or even makes it unnecessary. The address reuse solution is to place Network Address Translators (NAT) at the borders of stub domains. Each NAT box has a table consisting of pairs of local IP addresses and globally unique addresses. The IP addresses inside the stub domain are not globally unique. They are reused in other domains, thus solving the address depletion problem. The globally unique IP addresses are assigned according to current CIDR address allocation schemes. CIDR solves the scaling problem. The main advantage of NAT is that it can be installed without changes to routers or hosts. This memo presents a preliminary design for NAT, and discusses its pros and cons.</t>
</abstract>
</front>

<seriesInfo value="1631" name="RFC" />
</reference>


<reference target2="reference.RFC.1632.xml" anchor="RFC1632">
<front>
<title abbrev="X.500 Catalog">A Revised Catalog of Available X.500 Implementations</title>
<author fullname="Arlene F. Getchell" initials="A." surname="Getchell">
<organization>Lawrence Livermore National Laboratory, National Energy Research Supercomputer Center</organization>

<address>
<postal>
<street>P.O. Box 5509</street>
<street>L-561</street>
<city>Livermore</city>
<region>CA</region>
<code>94551</code>
<country>US</country>
</postal>

<phone>+1 510 423 6349</phone>
<email>getchell@es.net</email>
</address>
</author>

<author fullname="Srinivas R. Sataluri" initials="S.R." surname="Sataluri">
<organization>AT&amp;T Bell Laboratories</organization>

<address>
<postal>
<street>101 Crawfords Corner Road</street>
<street>Room 1C-429</street>
<street>P.O. Box 3030</street>
<city>Holmdel</city>
<region>NJ</region>
<code>07733-3030</code>
<country>US</country>
</postal>

<phone>+1 908 949 7782</phone>
<email>sri@qsun.att.com</email>
</address>
</author>

<date year="1994" month="May" />

<abstract>
<t>This document is the result of a survey that gathered new or updated descriptions of currently available implementations of X.500, including commercial products and openly available offerings. This document is a revision of RFC 1292. We contacted each contributor in RFC 1292 and requested an update and published the survey template in several mailing lists and obtained new product descriptions.</t>

<t>This document contains detailed description of twenty six (26) X.500 implementations - DSAs, DUAs, and DUA interfaces.</t>
</abstract>
</front>

<seriesInfo value="1632" name="RFC" />
</reference>


<reference target2="reference.RFC.1633.xml" anchor="RFC1633">
<front>
<title abbrev="Integrated Services Architecture">Integrated Services in the Internet Architecture: an Overview</title>
<author fullname="Bob Braden" initials="B." surname="Braden">
<organization>University of Southern California (USC), Information Sciences Institute (ISI)</organization>

<address>
<postal>
<street>4676 Admiralty Way</street>
<city>Marina del Rey</city>
<region>CA</region>
<code>90292</code>
<country>US</country>
</postal>

<phone>+1 310 822 1511</phone>
<email>Braden@ISI.EDU</email>
</address>
</author>

<author fullname="David Clark" initials="D." surname="Clark">
<organization>MIT Laboratory for Computer Science</organization>

<address>
<postal>
<street>545 Technology Square</street>
<city>Cambridge</city>
<region>MA</region>
<code>02139-1986</code>
<country>US</country>
</postal>

<phone>+1 617 253 6003</phone>
<email>ddc@LCS.MIT.EDU</email>
</address>
</author>

<author fullname="Scott Shenker" initials="S." surname="Shenker">
<organization>Xerox Palo Alto Research Center</organization>

<address>
<postal>
<street>3333 Coyote Hill Road</street>
<city>Palo Alto</city>
<region>CA</region>
<code>94304</code>
<country>US</country>
</postal>

<phone>+1 415 812 4840</phone>
<email>Shenker@PARC.XEROX.COM</email>
</address>
</author>

<date year="1994" month="June" />

<abstract>
<t>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 a variety of new applications, including teleconferencing, remote seminars, telescience, and distributed simulation.</t>

<t>This memo represents the direct product of recent work by Dave Clark, Scott Shenker, Lixia Zhang, Deborah Estrin, Sugih Jamin, John Wroclawski, Shai Herzog, and Bob Braden, and indirectly draws upon the work of many others.</t>
</abstract>
</front>

<seriesInfo value="1633" name="RFC" />
</reference>


<reference target2="reference.RFC.1634.xml" anchor="RFC1634">
<front>
<title abbrev="IPXWAN">Novell IPX Over Various WAN Media (IPXWAN)</title>
<author fullname="Michael Allen" initials="M." surname="Allen">
<organization>Novell, Inc.</organization>

<address>
<postal>
<street>2180 Fortune Drive</street>
<city>San Jose</city>
<region>CA</region>
<code>95131</code>
<country>US</country>
</postal>

<email>mallen@novell.com</email>
</address>
</author>

<author fullname="Fred Baker" initials="F." surname="Baker">
<organization>Advanced Computer Communications</organization>

<address>
<postal>
<street>315 Bollay Drive</street>
<city>Santa Barbara</city>
<region>CA</region>
<code>93111</code>
<country>US</country>
</postal>

<email>fbaker@acc.com</email>
</address>
</author>

<date year="1994" month="May" />

<abstract>
<t>This document describes how Novell IPX operates over various WAN media.  Specifically, it describes the common "IPX WAN" protocol Novell uses to exchange necessary router to router information prior to exchanging standard IPX routing information and traffic over WAN datalinks. This document supercedes RFC 1362 and RFC 1551. The changes from RFC 1551 are to correct a problem in the wording when an RFC 1362 router talks to an RFC 1551 router and to allow numbers to be specified in a Router Name.</t>
</abstract>
</front>

<seriesInfo value="1634" name="RFC" />
</reference>


<reference target2="reference.RFC.1635.xml" anchor="RFC1635">
<front>
<title abbrev="How To FTP">How to Use Anonymous FTP</title>
<author fullname="Peter Deutsch" initials="P." surname="Deutsch">
<organization>Bunyip Information Systems</organization>

<address>
<postal>
<street>266 Blvd. Neptune</street>
<city>Dorval</city>
<region>Quebec</region>
<code>H9S 2L4</code>
<country>CA</country>
</postal>

<phone>+1 514 398 3709</phone>
<email>peterd@bunyip.com</email>
</address>
</author>

<author fullname="Alan Emtage" initials="A." surname="Emtage">
<organization>Bunyip Information Systems</organization>

<address>
<postal>
<street>266 Blvd. Neptune</street>
<city>Dorval</city>
<region>Quebec</region>
<code>H9S 2L4</code>
<country>CA</country>
</postal>

<phone>+1 514 398 3709</phone>
<email>bajan@bunyip.com</email>
</address>
</author>

<author fullname="April N. Marine" initials="A." surname="Marine">
<organization>NASA NAIC,  Ames Research Center</organization>

<address>
<postal>
<street>M/S 204-14</street>
<city>Moffett Field</city>
<region>CA</region>
<code>94035-1000</code>
<country>US</country>
</postal>

<phone>+1 415 604 0762</phone>
<email>amarine@atlas.arc.nasa.gov</email>
</address>
</author>

<date year="1994" month="May" />

<abstract>
<t>This document provides information for the novice Internet user about using the File Transfer Protocol (FTP).  It explains what FTP is, what anonymous FTP is, and what an anonymous FTP archive site is.  It shows a sample anonymous FTP session.  It also discusses common ways files are packaged for efficient storage and transmission.</t>
</abstract>
</front>

<seriesInfo value="1635" name="RFC" />
</reference>


<reference target2="reference.RFC.1636.xml" anchor="RFC1636">
<front>
<title abbrev="IAB Workshop Report">Report of IAB Workshop on Security in the Internet Architecture - February 8-10, 1994</title>
<author fullname="Bob Braden" initials="B." surname="Braden">
<organization>University of Southern California (USC), Information Sciences Institute (ISI)</organization>

<address>
<postal>
<street>4676 Admiralty Way</street>
<city>Marina del Rey</city>
<region>CA</region>
<code>90292-6695</code>
<country>US</country>
</postal>

<phone>+1 310 822 1511</phone>
<email>Braden@ISI.EDU</email>
</address>
</author>

<author fullname="David Clark" initials="D." surname="Clark">
<organization>MIT Laboratory for Computer Science</organization>

<address>
<postal>
<street>545 Technology Square</street>
<city>Cambridge</city>
<region>MA</region>
<code>02139-1986</code>
<country>US</country>
</postal>

<phone>+1 617 253 6003</phone>
<email>ddc@lcs.mit.edu</email>
</address>
</author>

<author fullname="Steve Crocker" initials="S." surname="Crocker">
<organization>Trusted Information Systems, Inc.</organization>

<address>
<postal>
<street>3060 Washington Road (Rte 97)</street>
<city>Glenwood</city>
<region>MD</region>
<code>21738</code>
<country>US</country>
</postal>

<phone>+1 301 854 6889</phone>
<email>crocker@tis.com</email>
</address>
</author>

<author fullname="Christian Huitema" initials="C." surname="Huitema">
<organization>INRIA, Sophia-Antipolis</organization>

<address>
<postal>
<street>2004 Route des Lucioles</street>
<street>BP 109</street>
<city>Valbonne Cedex</city>
<region />
<code>F-06561</code>
<country>FR</country>
</postal>

<phone>+33 93 657715</phone>
<email>Christian.Huitema@MIRSA.INRIA.FR</email>
</address>
</author>

<date year="1994" month="June" />

<abstract>
<t>This document is a report on an Internet architecture workshop, initiated by the IAB and held at USC Information Sciences Institute on February 8-10, 1994.  This workshop generally focused on security issues in the Internet architecture.</t>

<t>This document should be regarded as a set of working notes containing ideas about security that were developed by Internet experts in a broad spectrum of areas, including routing, mobility, realtime service, and provider requirements, as well as security.  It contains some significant diversity of opinions on some important issues. This memo is offered as one input in the process of developing viable security mechanisms and procedures for the Internet.</t>
</abstract>
</front>

<seriesInfo value="1636" name="RFC" />
</reference>


<reference target2="reference.RFC.1637.xml" anchor="RFC1637">
<front>
<title abbrev="DNS NSAP RRs">DNS NSAP Resource Records</title>
<author fullname="Bill Manning" initials="B." surname="Manning">
<organization>Rice University -- ONCS</organization>

<address>
<postal>
<street>P.O. Box 1892</street>
<street>6100 South Main</street>
<city>Houston</city>
<region>TX</region>
<code>77251-1892</code>
<country>US</country>
</postal>

<phone>+1 713 285 5415</phone>
<email>bmanning@rice.edu</email>
</address>
</author>

<author fullname="Richard Colella" initials="R." surname="Colella">
<organization>National Institute of Standards and Technology (NIST)/B217</organization>

<address>
<postal>
<street />
<city>Gaithersburg</city>
<region>MD</region>
<code>20899</code>
<country>US</country>
</postal>

<phone>+1 301 975 3627</phone>
<facsimile>+1 301 590 0932</facsimile>
<email>colella@nist.gov</email>
</address>
</author>

<date year="1994" month="June" />

<abstract>
<t>The Internet is moving towards the deployment of an OSI lower layers infrastructure. This infrastructure comprises the connectionless network protocol (CLNP) and supporting routing protocols. Also required as part of this infrastructure is support in the Domain Name System (DNS) for mapping between names and NSAP addresses.</t>

<t>This document defines the format of one new Resource Record (RR) for the DNS for domain name-to-NSAP mapping. The RR may be used with any NSAP address format. This document supercedes RFC 1348.</t>

<t>NSAP-to-name translation is accomplished through use of the PTR RR (see STD 13, RFC 1035 for a description of the PTR RR). This paper describes how PTR RRs are used to support this translation.</t>
</abstract>
</front>

<seriesInfo value="1637" name="RFC" />
</reference>


<reference target2="reference.RFC.1638.xml" anchor="RFC1638">
<front>
<title abbrev="PPP Bridging">PPP Bridging Control Protocol (BCP)</title>
<author fullname="Fred Baker" initials="F." surname="Baker">
<organization>Advanced Computer Communications</organization>

<address>
<postal>
<street>315 Bollay Drive</street>
<city>Santa Barbara</city>
<region>CA</region>
<code>93117</code>
<country>US</country>
</postal>

<email>fbaker@acc.com</email>
</address>
</author>

<author fullname="Rich Bowen" initials="R." surname="Bowen">
<organization>International Business Machines Corporation</organization>

<address>
<postal>
<street>P. O. Box 12195</street>
<city>Research Triangle Park</city>
<region>NC</region>
<code>27709</code>
<country>US</country>
</postal>

<phone>+1 919 543 9851</phone>
<email>Rich_Bowen@vnet.ibm.com</email>
</address>
</author>

<date year="1994" month="June" />

<abstract>
<t>The Point-to-Point Protocol (PPP)provides a standard method for transporting multi-protocol datagrams over point-to-point links.  PPP defines an extensible Link Control Protocol, and proposes a family of Network Control Protocols for establishing and configuring different network-layer protocols.</t>

<t>This document defines the Network Control Protocol for establishing and configuring Remote Bridging for PPP links.</t>
</abstract>
</front>

<seriesInfo value="1638" name="RFC" />
</reference>


<reference target2="reference.RFC.1639.xml" anchor="RFC1639">
<front>
<title abbrev="FTP Over Big Address">FTP Operation Over Big Address Records (FOOBAR)</title>
<author fullname="David M. Piscitello" initials="D." surname="Piscitello">
<organization>Core Competence, Inc.</organization>

<address>
<postal>
<street>1620 Tuckerstown Road</street>
<city>Dresher</city>
<region>PA</region>
<code>19025</code>
<country>US</country>
</postal>

<email>dave@corecom.com</email>
</address>
</author>

<date year="1994" month="June" />

<abstract>
<t>This paper describes a convention for specifying address families other than the default Internet address family in FTP commands and replies.</t>
</abstract>
</front>

<seriesInfo value="1639" name="RFC" />
</reference>


<reference target2="reference.RFC.1640.xml" anchor="RFC1640">
<front>
<title abbrev="POISED WG Report">The Process for Organization of Internet Standards Working Group (POISED)</title>
<author fullname="Steve Crocker" initials="S." surname="Crocker">
<organization>Trusted Inforamtion Systems, Inc.</organization>

<address>
<postal>
<street>3060 Washington Road</street>
<city>Glenwood</city>
<region>MD</region>
<code>21738</code>
<country>US</country>
</postal>

<phone>+1 301 854 6889</phone>
<email>crocker@TIS.COM</email>
</address>
</author>

<date year="1994" month="June" />

<abstract>
<t>This report, originally prepared in January 1993 provides a summary of the POISED WG, starting from the events leading to the formation of the WG to the end of 1992.  Necessarily, this synopsis represents my own perception, particularly for the "prehistory" period.  Quite a few people hold strong views about both the overall sequence and specific events.  My intent here is to convey as neutral a point of view as possible.</t>
</abstract>
</front>

<seriesInfo value="1640" name="RFC" />
</reference>


<reference target2="reference.RFC.1641.xml" anchor="RFC1641">
<front>
<title>Using Unicode with MIME</title>
<author fullname="David Goldsmith" initials="D." surname="Goldsmith">
<organization>Taligent, Inc.</organization>

<address>
<postal>
<street>10201 N. DeAnza Blvd.</street>
<city>Cupertino</city>
<region>CA</region>
<code>95014-2233</code>
<country>US</country>
</postal>

<phone>+1 408 777 5225</phone>
<facsimile>+1 408 777 5081</facsimile>
<email>david_goldsmith@taligent.com</email>
</address>
</author>

<author fullname="Mark Davis" initials="M." surname="Davis">
<organization>Taligent, Inc.</organization>

<address>
<postal>
<street>10201 N. DeAnza Blvd.</street>
<city>Cupertino</city>
<region>CA</region>
<code>95014-2233</code>
<country>US</country>
</postal>

<phone>+1 408 777 5116</phone>
<facsimile>+1 408 777 5081</facsimile>
<email>mark_davis@taligent.com</email>
</address>
</author>

<date year="1994" month="July" />

<abstract>
<t>The Unicode Standard, version 1.1, and ISO/IEC 10646-1:1993(E) jointly define a 16 bit character set (hereafter referred to as Unicode) which encompasses most of the world's writing systems. However, Internet mail (STD 11, RFC 822) currently supports only 7-bit US ASCII as a character set. MIME (RFC 1521 and RFC 1522) extends Internet mail to support different media types and character sets, and thus could support Unicode in mail messages. MIME neither defines Unicode as a permitted character set nor specifies how it would be
 encoded, although it does provide for the registration of additional character sets over time.</t>

<t>This document specifies the usage of Unicode within MIME.</t>
</abstract>
</front>

<seriesInfo value="1641" name="RFC" />
</reference>


<reference target2="reference.RFC.1642.xml" anchor="RFC1642">
<front>
<title abbrev="UTF-7">UTF-7 - A Mail-Safe Transformation Format of Unicode</title>
<author fullname="David Goldsmith" initials="D." surname="Goldsmith">
<organization>Taligent, Inc.</organization>

<address>
<postal>
<street>10201 N. DeAnza Blvd.</street>
<city>Cupertino</city>
<region>CA</region>
<code>95014-2233</code>
<country>US</country>
</postal>

<phone>+1 408 777 5225</phone>
<facsimile>+1 408 777 5081</facsimile>
<email>david_goldsmith@taligent.com</email>
</address>
</author>

<author fullname="Mark Davis" initials="M." surname="Davis">
<organization>Taligent, Inc.</organization>

<address>
<postal>
<street>10201 N. DeAnza Blvd.</street>
<city>Cupertino</city>
<region>CA</region>
<code>95014-2233</code>
<country>US</country>
</postal>

<phone>+1 408 777 5116</phone>
<facsimile>+1 408 777 5081</facsimile>
<email>mark_davis@taligent.com</email>
</address>
</author>

<date year="1994" month="July" />

<abstract>
<t>The Unicode Standard, version 1.1, and ISO/IEC 10646-1:1993(E) jointly define a 16 bit character set (hereafter referred to as Unicode) which encompasses most of the world's writing systems. However, Internet mail (STD 11, RFC 822) currently supports only 7-bit US ASCII as a character set. MIME (RFC 1521 and RFC 1522) extends Internet mail to support different media types and character sets, and thus could support Unicode in mail messages. MIME neither defines Unicode as a permitted character set nor specifies how it would be
 encoded, although it does provide for the registration of additional character sets over time.</t>

<t>This document describes a new transformation format of Unicode that contains only 7-bit ASCII characters and is intended to be readable by humans in the limiting case that the document consists of characters from the US-ASCII repertoire. It also specifies how this transformation format is used in the context of RFC 1521, RFC 1522, and the document "Using Unicode with MIME".</t>
</abstract>
</front>

<seriesInfo value="1642" name="RFC" />
</reference>


<reference target2="reference.RFC.1643.xml" anchor="RFC1643">
<front>
<title abbrev="Ethernet-Like MIB">Definitions of Managed Objects for the Ethernet-like Interface Types</title>
<author fullname="Frank Kastenholz" initials="F." surname="Kastenholz">
<organization>FTP Software, Inc.</organization>

<address>
<postal>
<street>2 High Street</street>
<city>North Andover</city>
<region>MA</region>
<code>01845</code>
<country>US</country>
</postal>

<phone>+1 508 685 4000</phone>
<email>kasten@ftp.com</email>
</address>
</author>

<date year="1994" month="July" />
</front>

<seriesInfo value="50" name="STD" />
<seriesInfo value="1643" name="RFC" />
</reference>


<reference target2="reference.RFC.1644.xml" anchor="RFC1644">
<front>
<title abbrev="Transaction/TCP">T/TCP -- TCP Extensions for Transactions Functional Specification</title>
<author fullname="Bob Braden" initials="B." surname="Braden">
<organization>University of Southern California,  Information Sciences Institute</organization>

<address>
<postal>
<street>4676 Admiralty Way</street>
<city>Marina del Rey</city>
<region>CA</region>
<code>90292</code>
<country>US</country>
</postal>

<phone>+1 310 822 1511</phone>
<email>Braden@ISI.EDU</email>
</address>
</author>

<date year="1994" month="July" />

<abstract>
<t>This memo specifies T/TCP, an experimental TCP extension for efficient transaction-oriented (request/response) service.  This backwards-compatible extension could fill the gap between the current connection-oriented TCP and the datagram-based UDP.</t>

<t>This work was supported in part by the National Science Foundation under Grant Number NCR-8922231.</t>
</abstract>
</front>

<seriesInfo value="1644" name="RFC" />
</reference>


<reference target2="reference.RFC.1645.xml" anchor="RFC1645">
<front>
<title abbrev="SNPP - Version 2">Simple Network Paging Protocol - Version 2</title>
<author fullname="R. Allen Gwinn, Jr." initials="R.A." surname="Gwinn">
<organization>Southern Methodist University, Business Information Center</organization>

<address>
<postal>
<street />
<city>Dallas</city>
<region>TX</region>
<code>75275</code>
<country>US</country>
</postal>

<phone>+1 214 768 3186</phone>
<email>allen@mail.cox.smu.edu</email>
</address>
</author>

<date year="1994" month="July" />

<abstract>
<t>This RFC suggests a simple way for delivering both alphanumeric and numeric pages (one-way) to radio paging terminals.  Gateways supporting this protocol, as well as SMTP, have been in use for several months for nationwide paging and messaging.  In addition, email filters and SNPP client software for Unix and Windows are available at no cost.  Please contact the author for more information.</t>

<t>Earlier versions of this specification were reviewed by IESG members and the "822 Extensions" Working Group.  They preferred an alternate strategy, as discussed under "Relationship to Other IETF Work", below.</t>
</abstract>
</front>

<seriesInfo value="1645" name="RFC" />
</reference>


<reference target2="reference.RFC.1646.xml" anchor="RFC1646">
<front>
<title abbrev="TN3270 Extensions">TN3270 Extensions for LUname and Printer Selection</title>
<author fullname="Cleve Graves" initials="C." surname="Graves">
<organization />

<address>
<postal>
<street>2711 LBJ Freeway</street>
<city>Dallas</city>
<region>TX</region>
<code>75234</code>
<country>US</country>
</postal>

<phone>+1 214 484 5200</phone>
<email>cvg@oc.com</email>
</address>
</author>

<author fullname="Thomas Butts" initials="T." surname="Butts">
<organization />

<address>
<postal>
<street>2711 LBJ Freeway</street>
<city>Dallas</city>
<region>TX</region>
<code>75234</code>
<country>US</country>
</postal>

<phone>+1 214 484 5200</phone>
<email>tom@oc.com</email>
</address>
</author>

<author fullname="Michelle Angel" initials="M." surname="Angel">
<organization />

<address>
<postal>
<street>2711 LBJ Freeway</street>
<city>Dallas</city>
<region>TX</region>
<code>75234</code>
<country>US</country>
</postal>

<phone>+1 214 484 5200</phone>
<email>angel@oc.com</email>
</address>
</author>

<date year="1994" month="July" />

<abstract>
<t>This document describes protocol extensions to TN3270. There are two extensions outlined in this document. The first defines a way by which a TN3270 client can request a specific device (LUname) from a TN3270 server. The second extension specifies how a TN3270 printer device can be requested by a TN3270 client and the manner in which the 3270 printer status information can be sent to the TN3270 server. Discussions and suggestions for improvements to these enhancements should be sent to the TN3270E Working Group mailing list TN3270E@list.nih.gov. These extensions will be called TN3287 in this document. This information is being provided to members of the Internet community that want to support the 3287 data stream within the TELNET protocol.</t>
</abstract>
</front>

<seriesInfo value="1646" name="RFC" />
</reference>


<reference target2="reference.RFC.1647.xml" anchor="RFC1647">
<front>
<title>TN3270 Enhancements</title>
<author fullname="Bill Kelly" initials="B." surname="Kelly">
<organization>Auburn University, Division of University Computing</organization>

<address>
<postal>
<street>144 Parker Hall</street>
<city>Auburn</city>
<region>AL</region>
<code>36849</code>
<country>US</country>
</postal>

<phone>+1 205 844 4512</phone>
<email>kellywh@mail.auburn.edu</email>
</address>
</author>

<date year="1994" month="July" />

<abstract>
<t>This document describes a protocol that more fully supports 3270 devices than do the existing tn3270 practices.  Specifically, it defines a method of emulating both the terminal and printer members of the 3270 family of devices via Telnet; it provides for the ability of a Telnet client to request that it be assigned a specific device-name (also referred to as "LU name" or "network name"); finally, it adds support for a variety of functions such as the ATTN key, the SYSREQ key, and SNA response handling.</t>

<t>This protocol would be negotiated and implemented under a new Telnet Option and would be unrelated to the Telnet 3270 Regime Option as defined in RFC 1041.</t>
</abstract>
</front>

<seriesInfo value="1647" name="RFC" />
</reference>


<reference target2="reference.RFC.1648.xml" anchor="RFC1648">
<front>
<title abbrev="X.400 Postmaster Convention">Postmaster Convention for X.400 Operations</title>
<author fullname="Allan Cargille" initials="A." surname="Cargille">
<organization>University of Wisconsin-Madison, Computer Sciences Department</organization>

<address>
<postal>
<street>1210 West Dayton Street</street>
<city>Madison</city>
<region>WI</region>
<code>53706</code>
<country>US</country>
</postal>

<phone>+1 608 262 5084</phone>
<facsimile>+1 608 262 9777</facsimile>
<email>cargille@cs.wisc.edu</email>
</address>
</author>

<date year="1994" month="July" />

<abstract>
<t>Both STD 11, RFC 822and STD 3, RFC 1123(Host Requirements) require that the email address "postmaster" be supported at all hosts.  This paper extends this concept to X.400 mail domains which   have registered RFC 1327 mapping rules, and which therefore appear to have normal RFC822-style addresses.</t>
</abstract>
</front>

<seriesInfo value="1648" name="RFC" />
</reference>


<reference target2="reference.RFC.1649.xml" anchor="RFC1649">
<front>
<title abbrev="X.400 Management in GO-MHS">Operational Requirements for X.400 Management Domains in the GO-MHS Community</title>
<author fullname="Robert Hagens" initials="R." surname="Hagens">
<organization>Advanced Network &amp; Services, Inc.</organization>

<address>
<postal>
<street>1875 Campus Commons Drive</street>
<street>Suite 220</street>
<city>Reston</city>
<region>VA</region>
<code>22091</code>
<country>US</country>
</postal>

<phone>+1 703 758 7700</phone>
<facsimile>+1 703 758 7717</facsimile>
<email>hagens@ans.net</email>
</address>
</author>

<author fullname="Alf Hansen" initials="A." surname="Hansen">
<organization>UNINETT</organization>

<address>
<postal>
<street>Elgesetergt. 10</street>
<street>Postbox 6883</street>
<street>Elgeseter</street>
<city>Trondheim</city>
<region />
<code>N-7002</code>
<country>NO</country>
</postal>

<phone>+47 73 592982</phone>
<facsimile>+47 73 596450</facsimile>
<email>Alf.Hansen@uninett.no</email>
</address>
</author>

<date year="1994" month="July" />
</front>

<seriesInfo value="1649" name="RFC" />
</reference>


<reference target2="reference.RFC.1650.xml" anchor="RFC1650">
<front>
<title abbrev="Ethernet-Like MIB">Definitions of Managed Objects for the Ethernet-like Interface Types using SMIv2</title>
<author fullname="Frank Kastenholz" initials="F." surname="Kastenholz">
<organization>FTP Software, Inc.</organization>

<address>
<postal>
<street>2 High Street</street>
<city>North Andover</city>
<region>MA</region>
<code>01845</code>
<country>US</country>
</postal>

<phone>+1 508 685 4000</phone>
<email>kasten@ftp.com</email>
</address>
</author>

<date year="1994" month="August" />
</front>

<seriesInfo value="1650" name="RFC" />
</reference>


<reference target2="reference.RFC.1651.xml" anchor="RFC1651">
<front>
<title>SMTP Service Extensions</title>
<author fullname="John Klensin," initials="J." surname="Klensin">
<organization>MCI Data Services Division</organization>

<address>
<postal>
<street>2100 Reston Parkway</street>
<street>6th floor</street>
<city>Reston</city>
<region>VA</region>
<code>22091</code>
<country>US</country>
</postal>

<phone>+1 703 715 7361</phone>
<facsimile>+1 703 715 7435</facsimile>
<email>klensin@mci.net</email>
</address>
</author>

<author fullname="Ned Freed" initials="N." surname="Freed">
<organization>Innosoft International, Inc.</organization>

<address>
<postal>
<street>1050 East Garvey Avenue South</street>
<city>West Covina</city>
<region>CA</region>
<code>91790</code>
<country>US</country>
</postal>

<phone>+1 818 919 3600</phone>
<facsimile>+1 818 919 3614</facsimile>
<email>ned@innosoft.com</email>
</address>
</author>

<author fullname="Marshall T. Rose" initials="M." surname="Rose">
<organization>Dover Beach Consulting, Inc.</organization>

<address>
<postal>
<street>420 Whisman Court</street>
<city>Mountain View</city>
<region>CA</region>
<code>94043-2186</code>
<country>US</country>
</postal>

<phone>+1 415 968 1052</phone>
<facsimile>+1 415 968 2510</facsimile>
<email>mrose@dbc.mtview.ca.us</email>
</address>
</author>

<author fullname="Einar A. Stefferud" initials="E." surname="Stefferud">
<organization>Network Management Associates, Inc.</organization>

<address>
<postal>
<street>17301 Drey Lane</street>
<city>Huntington Beach</city>
<region>CA</region>
<code>92647-5615</code>
<country>US</country>
</postal>

<phone>+1 714 842 3711</phone>
<facsimile>+1 714 848 2091</facsimile>
<email>stef@nma.com</email>
</address>
</author>

<author fullname="Dave Crocker" initials="D." surname="Crocker">
<organization>Silicon Graphics, Inc.</organization>

<address>
<postal>
<street>2011 N. Shoreline Blvd.</street>
<street>P.O. Box 7311</street>
<city>Mountain View</city>
<region>CA</region>
<code>94039</code>
<country>US</country>
</postal>

<phone>+1 415 390 1804</phone>
<facsimile>+1 415 962 8404</facsimile>
<email>dcrocker@sgi.com</email>
</address>
</author>

<date year="1994" month="July" />

<abstract>
<t>This memo defines a framework for extending the SMTP service by defining a means whereby a server SMTP can inform a client SMTP as to the service extensions it supports. Standard extensions to the SMTP service are registered with the IANA.  This framework does not require modification of existing SMTP clients or servers unless the features of the service extensions are to be requested or provided.</t>
</abstract>
</front>

<seriesInfo value="1651" name="RFC" />
</reference>


<reference target2="reference.RFC.1652.xml" anchor="RFC1652">
<front>
<title abbrev="SMTP 8bit-MIMEtransport">SMTP Service Extension for 8bit-MIMEtransport</title>
<author fullname="John Klensin" initials="J." surname="Klensin">
<organization>MCI Data Services Division</organization>

<address>
<postal>
<street>2100 Reston Parkway</street>
<street>6th floor</street>
<city>Reston</city>
<region>VA</region>
<code>22091</code>
<country>US</country>
</postal>

<phone>+1 703 715 7361</phone>
<facsimile>+1 703 715 7435</facsimile>
<email>klensin@mci.net</email>
</address>
</author>

<author fullname="Ned Freed" initials="N." surname="Freed">
<organization>Innosoft International, Inc.</organization>

<address>
<postal>
<street>1050 East Garvey Avenue South</street>
<city>West Covina</city>
<region>CA</region>
<code>91790</code>
<country>US</country>
</postal>

<phone>+1 818 919 3600</phone>
<facsimile>+1 818 919 3614</facsimile>
<email>ned@innosoft.com</email>
</address>
</author>

<author fullname="Marshall T. Rose" initials="M.T." surname="Rose">
<organization>Dover Beach Consulting, Inc.</organization>

<address>
<postal>
<street>420 Whisman Court</street>
<city>Mountain View</city>
<region>CA</region>
<code>94043-2186</code>
<country>US</country>
</postal>

<phone>+1 415 968 1052</phone>
<facsimile>+1 415 968 2510</facsimile>
<email>mrose@dbc.mtview.ca.us</email>
</address>
</author>

<author fullname="Einar A. Stefferud" initials="E." surname="Stefferud">
<organization>Network Management Associates, Inc.</organization>

<address>
<postal>
<street>17301 Drey Lane</street>
<city>Huntington Beach</city>
<region>CA</region>
<code>92647-5615</code>
<country>US</country>
</postal>

<phone>+1 714 842 3711</phone>
<facsimile>+1 714 848 2091</facsimile>
<email>stef@nma.com</email>
</address>
</author>

<author fullname="Dave Crocker" initials="D." surname="Crocker">
<organization>Silicon Graphics, Inc.</organization>

<address>
<postal>
<street>2011 N. Shoreline Blvd.</street>
<street>P.O. Box 7311</street>
<city>Mountain View</city>
<region>CA</region>
<code>94039</code>
<country>US</country>
</postal>

<phone>+1 415 390 1804</phone>
<facsimile>+1 415 962 8404</facsimile>
<email>dcrocker@sgi.com</email>
</address>
</author>

<date year="1994" month="July" />

<abstract>
<t>This memo defines an extension to the SMTP service whereby an SMTP content body consisting of text containing octets outside of the US-ASCII octet range (hex 00-7F) may be relayed using SMTP.</t>
</abstract>
</front>

<seriesInfo value="1652" name="RFC" />
</reference>


<reference target2="reference.RFC.1653.xml" anchor="RFC1653">
<front>
<title abbrev="SMTP Size Declaration">SMTP Service Extension for Message Size Declaration</title>
<author fullname="John Klensin" initials="J." surname="Klensin">
<organization>MCI Data Services Division</organization>

<address>
<postal>
<street>2100 Reston Parkway</street>
<street>6th floor</street>
<city>Reston</city>
<region>VA</region>
<code>22091</code>
<country>US</country>
</postal>

<phone>+1 703 715 7361</phone>
<facsimile>+1 703 715 7435</facsimile>
<email>klensin@mci.net</email>
</address>
</author>

<author fullname="Ned Freed" initials="N." surname="Freed">
<organization>Innosoft International, Inc.</organization>

<address>
<postal>
<street>1050 East Garvey Avenue South</street>
<city>West Covina</city>
<region>CA</region>
<code>91790</code>
<country>US</country>
</postal>

<phone>+1 818 919 3600</phone>
<facsimile>+1 818 919 3614</facsimile>
<email>ned@innosoft.com</email>
</address>
</author>

<author fullname="Keith Moore" initials="K." surname="Moore">
<organization>University of Tennessee, Computer Science Dept</organization>

<address>
<postal>
<street>107 Ayres Hall</street>
<city>Knoxville</city>
<region>TN</region>
<code>37996-1301</code>
<country>US</country>
</postal>

<email>moore@cs.utk.edu</email>
</address>
</author>

<date year="1994" month="July" />

<abstract>
<t>This memo defines an extension to the SMTP service whereby an SMTP client and server may interact to give the server an opportunity to decline to accept a message (perhaps temporarily) based on the client's estimate of the message size.</t>
</abstract>
</front>

<seriesInfo value="1653" name="RFC" />
</reference>


<reference target2="reference.RFC.1654.xml" anchor="RFC1654">
<front>
<title abbrev="BGP-4">A Border Gateway Protocol 4 (BGP-4)</title>
<author fullname="Yakov Rekhter" initials="Y." surname="Rekhter">
<organization>IBM Corporation, T.J. Watson Research Center</organization>

<address>
<postal>
<street>P.O. Box 218</street>
<city>Yorktown Heights</city>
<region>NY</region>
<code>10598</code>
<country>US</country>
</postal>

<phone>+1 914 945 3896</phone>
<email>yakov@watson.ibm.com</email>
</address>
</author>

<author fullname="Tony Li" initials="T." surname="Li">
<organization>cisco Systems, Inc.</organization>

<address>
<postal>
<street>1525 O'Brien Drive</street>
<city>Menlo Park</city>
<region>CA</region>
<code>94025</code>
<country>US</country>
</postal>

<email>tli@cisco.com</email>
</address>
</author>

<date year="1994" month="July" />
</front>

<seriesInfo value="1654" name="RFC" />
</reference>


<reference target2="reference.RFC.1655.xml" anchor="RFC1655">
<front>
<title abbrev="BGP-4 Application">Application of the Border Gateway Protocol in the Internet</title>
<author fullname="Yakov Rekhter" initials="Y." surname="Rekhter">
<organization>IBM Corporation, T.J. Watson Research Center</organization>

<address>
<postal>
<street>P.O. Box 218</street>
<city>Yorktown Heights</city>
<region>NY</region>
<code>10598</code>
<country>US</country>
</postal>

<phone>+1 914 945 3896</phone>
<email>yakov@watson.ibm.com</email>
</address>
</author>

<author fullname="Phill Gross" initials="P." surname="Gross">
<organization>MCI Data Services Division</organization>

<address>
<postal>
<street>2100 Reston Parkway</street>
<street>Room 6001</street>
<city>Reston</city>
<region>VA</region>
<code>22091</code>
<country>US</country>
</postal>

<phone>+1 703 715 7432</phone>
<facsimile>+1 703 715 7436</facsimile>
<email>0006423401@mcimail.com</email>
</address>
</author>

<date year="1994" month="July" />

<abstract>
<t>This document, together with its companion document, "A Border Gateway Protocol 4 (BGP-4)", define an inter-autonomous system routing protocol for the Internet.  "A Border Gateway Protocol 4 (BGP-4)" defines the BGP protocol specification, and this document describes the usage of the BGP in the Internet.</t>

<t>Information about the progress of BGP can be monitored and/or reported on the BGP mailing list (bgp@ans.net).</t>
</abstract>
</front>

<seriesInfo value="1655" name="RFC" />
</reference>


<reference target2="reference.RFC.1656.xml" anchor="RFC1656">
<front>
<title abbrev="BGP-4 Implementation">BGP-4 Protocol Document Roadmap and Implementation Experience</title>
<author fullname="Paul Traina" initials="P." surname="Traina">
<organization>cisco Systems, Inc.</organization>

<address>
<postal>
<street>1525 O'Brien Drive</street>
<city>Menlo Park</city>
<region>CA</region>
<code>94025</code>
<country>US</country>
</postal>

<email>pst@cisco.com</email>
</address>
</author>

<date year="1994" month="July" />
</front>

<seriesInfo value="1656" name="RFC" />
</reference>


<reference target2="reference.RFC.1657.xml" anchor="RFC1657">
<front>
<title abbrev="BGP-4 MIB">Definitions of Managed Objects for the Fourth Version of the Border Gateway Protocol (BGP-4) using SMIv2</title>
<author fullname="Steven Willis" initials="S." surname="Willis">
<organization>Wellfleet Communications Inc.</organization>

<address>
<postal>
<street>15 Crosby Drive</street>
<city>Bedford</city>
<region>MA</region>
<code>01730</code>
<country>US</country>
</postal>

<phone>+1 617 275 2400</phone>
<email>swillis@wellfleet.com</email>
</address>
</author>

<author fullname="John Burruss" initials="J." surname="Burruss">
<organization>Wellfleet Communications Inc.</organization>

<address>
<postal>
<street>15 Crosby Drive</street>
<city>Bedford</city>
<region>MA</region>
<code>01730</code>
<country>US</country>
</postal>

<phone>+1 617 275 2400</phone>
<email>jburruss@wellfleet.com</email>
</address>
</author>

<author fullname="John Chu" initials="J." surname="Chu">
<organization>IBM Corp.</organization>

<address>
<postal>
<street>P.O.Box 218</street>
<city>Yorktown Heights</city>
<region>NY</region>
<code>10598</code>
<country>US</country>
</postal>

<phone>+1 914 945 3156</phone>
<email>jychu@watson.ibm.com</email>
</address>
</author>

<date year="1994" month="July" />
</front>

<seriesInfo value="1657" name="RFC" />
</reference>


<reference target2="reference.RFC.1658.xml" anchor="RFC1658">
<front>
<title abbrev="Character MIB">Definitions of Managed Objects for Character Stream Devices using SMIv2</title>
<author fullname="Bob Stewart" initials="B." surname="Stewart">
<organization>Xyplex, Inc.</organization>

<address>
<postal>
<street>295 Foster Street</street>
<city>Littleton</city>
<region>MA</region>
<code>01460</code>
<country>US</country>
</postal>

<phone>+1 508 952 4816</phone>
<facsimile>+1 508 952 4887</facsimile>
<email>rlstewart@eng.xyplex.com</email>
</address>
</author>

<date year="1994" month="July" />
</front>

<seriesInfo value="1658" name="RFC" />
</reference>


<reference target2="reference.RFC.1659.xml" anchor="RFC1659">
<front>
<title abbrev="RS-232-like MIB">Definitions of Managed Objects for RS-232-like Hardware Devices using SMIv2</title>
<author fullname="Bob Stewart" initials="B." surname="Stewart">
<organization>Xyplex, Inc.</organization>

<address>
<postal>
<street>295 Foster Street</street>
<city>Littleton</city>
<region>MA</region>
<code>01460</code>
<country>US</country>
</postal>

<phone>+1 508 952 4816</phone>
<facsimile>+1 508 952 4887</facsimile>
<email>rlstewart@eng.xyplex.com</email>
</address>
</author>

<date year="1994" month="July" />
</front>

<seriesInfo value="1659" name="RFC" />
</reference>


<reference target2="reference.RFC.1660.xml" anchor="RFC1660">
<front>
<title abbrev="Parallel-printer-like MIB">Definitions of Managed Objects for Parallel-printer-like Hardware Devices using SMIv2</title>
<author fullname="Bob Stewart" initials="B." surname="Stewart">
<organization>Xyplex, Inc.</organization>

<address>
<postal>
<street>295 Foster Street</street>
<city>Littleton</city>
<region>MA</region>
<code>01460</code>
<country>US</country>
</postal>

<phone>+1 508 952 4816</phone>
<facsimile>+1 508 952 4887</facsimile>
<email>rlstewart@eng.xyplex.com</email>
</address>
</author>

<date year="1994" month="July" />
</front>

<seriesInfo value="1660" name="RFC" />
</reference>


<reference target2="reference.RFC.1661.xml" anchor="RFC1661">
<front>
<title abbrev="Point-to-Point Protocol">The Point-to-Point Protocol (PPP)</title>
<author fullname="William Allen Simpson" initials="W." surname="Simpson">
<organization>Daydreamer, Computer Systems Consulting Services</organization>

<address>
<postal>
<street>1384 Fontaine</street>
<city>Madison Heights</city>
<region>MI</region>
<code>48071</code>
<country>US</country>
</postal>

<email>Bill.Simpson@um.cc.umich.edu</email>
</address>
</author>

<date year="1994" month="July" />

<abstract>
<t>The Point-to-Point Protocol (PPP) provides a standard method for transporting multi-protocol datagrams over point-to-point links.  PPP is comprised of three main components:</t>

<t>1. A method for encapsulating multi-protocol datagrams.</t>

<t>2. A Link Control Protocol (LCP) for establishing, configuring, and testing the data-link connection.</t>

<t>3. A family of Network Control Protocols (NCPs) for establishing and configuring different network-layer protocols.</t>

<t>This document defines the PPP organization and methodology, and the PPP encapsulation, together with an extensible option negotiation mechanism which is able to negotiate a rich assortment of configuration parameters and provides additional management functions.  The PPP Link Control Protocol (LCP) is described in terms of this mechanism.</t>
</abstract>
</front>

<seriesInfo value="51" name="STD" />
<seriesInfo value="1661" name="RFC" />
</reference>


<reference target2="reference.RFC.1662.xml" anchor="RFC1662">
<front>
<title abbrev="HDLC-like Framing">PPP in HDLC-like Framing</title>
<author fullname="William Allen Simpson" initials="W." surname="Simpson">
<organization>Daydreamer, Computer Systems Consulting Services</organization>

<address>
<postal>
<street>1384 Fontaine</street>
<city>Madison Heights</city>
<region>MI</region>
<code>48071</code>
<country>US</country>
</postal>

<email>Bill.Simpson@um.cc.umich.edu</email>
</address>
</author>

<date year="1994" month="July" />

<abstract>
<t>The Point-to-Point Protocol (PPP)provides a standard method for transporting multi-protocol datagrams over point-to-point links.</t>

<t>This document describes the use of HDLC-like framing for PPP encapsulated packets.</t>
</abstract>
</front>

<seriesInfo value="51" name="STD" />
<seriesInfo value="1662" name="RFC" />
</reference>


<reference target2="reference.RFC.1663.xml" anchor="RFC1663">
<front>
<title>PPP Reliable Transmission</title>
<author fullname="Dave Rand" initials="D." surname="Rand">
<organization>Novell</organization>

<address>
<postal>
<street>2180 Fortune Drive</street>
<city>San Jose</city>
<region>CA</region>
<code>95131</code>
<country>US</country>
</postal>

<phone>+1 408 321 1259</phone>
<email>dave_rand@novell.com</email>
</address>
</author>

<date year="1994" month="July" />

<abstract>
<t>The Point-to-Point Protocol (PPP)provides a standard method for transporting multi-protocol datagrams over point-to-point links.</t>

<t>This document defines a method for negotiating and using Numbered-Mode, as defined by ISO 7776, to provide a reliable serial link.</t>

<t>This document is the product of the Point-to-Point Protocol Working Group of the Internet Engineering Task Force (IETF).  Comments should be submitted to the ietf-ppp@ucdavis.edu mailing list.</t>
</abstract>
</front>

<seriesInfo value="1663" name="RFC" />
</reference>


<reference target2="reference.RFC.1664.xml" anchor="RFC1664">
<front>
<title abbrev="Internet DNS for Mail Mapping Tables">Using the Internet DNS to Distribute RFC1327 Mail Address Mapping Tables</title>
<author fullname="Claudio Allocchio" initials="C." surname="Allocchio">
<organization>Sincrotrone Trieste</organization>

<address>
<postal>
<street>Padriciano 99</street>
<city>Trieste</city>
<region />
<code>I 34012</code>
<country>IT</country>
</postal>

<phone>+39 40 3758523</phone>
<facsimile>+39 40 226338</facsimile>
<email>Claudio.Allocchio@elettra.trieste.it</email>
</address>
</author>

<author fullname="Antonio Blasco Bonito" initials="A." surname="Bonito">
<organization>CNUCE - CNR</organization>

<address>
<postal>
<street>Reparto infr. reti</street>
<street>Viale S. Maria 36</street>
<city>Pisa</city>
<region />
<code>I 56126</code>
<country>IT</country>
</postal>

<phone>+39 50 593246</phone>
<facsimile>+39 50 589354</facsimile>
<email>bonito@cnuce.cnr.it</email>
</address>
</author>

<author fullname="Bruce Cole" initials="B." surname="Cole">
<organization>Cisco Systems Inc.</organization>

<address>
<postal>
<street>P.O. Box 3075</street>
<street>1525 O'Brien Drive</street>
<city>Menlo Park</city>
<region>CA</region>
<code>94026</code>
<country>US</country>
</postal>

<phone>+1 415 688 8245</phone>
<facsimile>+1 415 688 4575</facsimile>
<email>bcole@cisco.com</email>
</address>
</author>

<author fullname="Silvia Giordano" initials="S." surname="Giordano">
<organization>Centro Svizzero di Calcolo Scientifico</organization>

<address>
<postal>
<street>Via Cantonale</street>
<city>Manno</city>
<region />
<code>CH 6928</code>
<country>CH</country>
</postal>

<phone>+41 91 508213</phone>
<facsimile>+41 91 506711</facsimile>
<email>giordano@cscs.ch</email>
</address>
</author>

<author fullname="Robert Hagens" initials="R." surname="Hagens">
<organization>Advanced Network and Services</organization>

<address>
<postal>
<street>1875 Campus Commons Drive</street>
<city>Reston</city>
<region>VA</region>
<code>22091</code>
<country>US</country>
</postal>

<phone>+1 703 758 7700</phone>
<email>hagens@ans.net</email>
</address>
</author>

<date year="1994" month="August" />

<abstract>
<t>This memo defines how to store in the Internet Domain Name System the mapping information needed by e-mail gateways and other tools to map RFC822 domain names into X.400 O/R names and vice versa.  Mapping information can be managed in a distributed rather than a centralised way. Gateways located on Internet hosts can retrieve the mapping information querying the DNS instead of having fixed tables which need to be centrally updated and distributed.  This memo is a joint effort of X400 operation working group (x400ops) and RARE Mail and Messaging working group (WG-MSG).</t>
</abstract>
</front>

<seriesInfo value="1664" name="RFC" />
</reference>


<reference target2="reference.RFC.1665.xml" anchor="RFC1665">
<front>
<title abbrev="SNANAU MIB">Definitions of Managed Objects for SNA NAUs using SMIv2</title>
<author fullname="Zbigniew Kielczewski" initials="Z." surname="Kielczewski">
<organization>Eicon Technology Corporation</organization>

<address>
<postal>
<street>2196 32nd Avenue</street>
<city>Montreal</city>
<region>Quebec</region>
<code>H8T 3H7</code>
<country>CA</country>
</postal>

<phone>+1 514 631 2592</phone>
<email>zbig@eicon.qc.ca</email>
</address>
</author>

<author fullname="Deirdre Kostick" initials="D." surname="Kostick">
<organization>Bell Communications Research</organization>

<address>
<postal>
<street />
<city>Red Bank</city>
<region>NJ</region>
<code>07701</code>
<country>US</country>
</postal>

<phone>+1 908 758 2642</phone>
<email>dck2@mail.bellcore.com</email>
</address>
</author>

<author fullname="Kitty Shih" initials="K." surname="Shih">
<organization>Novell</organization>

<address>
<postal>
<street>890 Ross Drive</street>
<city>Sunnyvale</city>
<region>CA</region>
<code>94089</code>
<country>US</country>
</postal>

<phone>+1 408 747 4305</phone>
<email>kmshih@novell.com</email>
</address>
</author>

<date year="1994" month="July" />
</front>

<seriesInfo value="1665" name="RFC" />
</reference>


<reference target2="reference.RFC.1666.xml" anchor="RFC1666">
<front>
<title>Definitions of Managed Objects for SNA NAUs using SMIv2</title>
<author fullname="Z. Kielczewski" initials="Z." surname="Kielczewski">
<organization />
</author>

<author fullname="D. Kostick" initials="D." surname="Kostick">
<organization />
</author>

<author fullname="K. Shih" initials="K." surname="Shih">
<organization />
</author>

<date year="1994" month="August" />
</front>

<seriesInfo value="1666" name="RFC" />
<format octets="134385" type="TXT" target="ftp://ftp.isi.edu/in-notes/rfc1666.txt" />
</reference>


<reference target2="reference.RFC.1667.xml" anchor="RFC1667">
<front>
<title>Modeling and Simulation Requirements for IPng</title>
<author fullname="Susan Symington" initials="S." surname="Symington">
<organization>MITRE Corporation</organization>

<address>
<postal>
<street>7525 Colshire Drive</street>
<city>McLean</city>
<region>VA</region>
<code>22101-3481</code>
<country>US</country>
</postal>

<phone>+1 703 883 7209</phone>
<email>susan@gateway.mitre.org</email>
</address>
</author>

<author fullname="David Wood" initials="D." surname="Wood">
<organization>MITRE Corporation</organization>

<address>
<postal>
<street>7525 Colshire Drive</street>
<city>McLean</city>
<region>VA</region>
<code>22101-3481</code>
<country>US</country>
</postal>

<phone>+1 703 883 6394</phone>
<email>wood@mitre.org</email>
</address>
</author>

<author fullname="J. Mark Pullen" initials="J." surname="Pullen">
<organization>George Mason University, Computer Science</organization>

<address>
<postal>
<street />
<city>Fairfax</city>
<region>VA</region>
<code>22030</code>
<country>US</country>
</postal>

<phone>+1 703 993 1538</phone>
<email>mpullen@cs.gmu.edu</email>
</address>
</author>

<date year="1994" month="August" />

<abstract>
<t>This document was submitted to the IETF IPng area in response to RFC 1550.  Publication of this document does not imply acceptance by the IPng area of any ideas expressed within.  Comments should be submitted to the big-internet@munnari.oz.au mailing list.</t>
</abstract>
</front>

<seriesInfo value="1667" name="RFC" />
</reference>


<reference target2="reference.RFC.1668.xml" anchor="RFC1668">
<front>
<title>Unified Routing Requirements for IPng</title>
<author fullname="Deborah Estrin" initials="D." surname="Estrin">
<organization>University of Southern California, Computer Science Department</organization>

<address>
<postal>
<street>MC 0782</street>
<city>Los Angeles</city>
<region>CA</region>
<code>90089-0782</code>
<country>US</country>
</postal>

<phone>+1 310 740 4524</phone>
<email>estrin@usc.edu</email>
</address>
</author>

<author fullname="Tony Li" initials="T." surname="Li">
<organization>cisco Systems, Inc.</organization>

<address>
<postal>
<street>1525 O'Brien Drive</street>
<city>Menlo Park</city>
<region>CA</region>
<code>94025</code>
<country>US</country>
</postal>

<email>tli@cisco.com</email>
</address>
</author>

<author fullname="Yakov Rekhter" initials="Y." surname="Rekhter">
<organization>IBM Corporation, T.J. Watson Research Center</organization>

<address>
<postal>
<street>P.O. Box 218</street>
<city>Yorktown Heights</city>
<region>NY</region>
<code>10598</code>
<country>US</country>
</postal>

<phone>+1 914 945 3896</phone>
<email>yakov@watson.ibm.com</email>
</address>
</author>

<date year="1994" month="August" />

<abstract>
<t>This document was submitted to the IETF IPng area in response to RFC 1550.  Publication of this document does not imply acceptance by the IPng area of any ideas expressed within.  Comments should be submitted to the big-internet@munnari.oz.au mailing list.</t>
</abstract>
</front>

<seriesInfo value="1668" name="RFC" />
</reference>


<reference target2="reference.RFC.1669.xml" anchor="RFC1669">
<front>
<title abbrev="IPng White Paper on Market Viability">Market Viability as a IPng Criteria</title>
<author fullname="John Curran" initials="J." surname="Curran">
<organization>BBN Technology Services, Inc.</organization>

<address>
<postal>
<street>10 Moulton Street</street>
<city>Cambridge</city>
<region>MA</region>
<code>02138</code>
<country>US</country>
</postal>

<email>jcurran@near.net</email>
</address>
</author>

<date year="1994" month="August" />

<abstract>
<t>This document was submitted to the IETF IPng area in response to RFC 1550. Publication of this document does not imply acceptance by the IPng area of any ideas expressed within.  Comments should be submitted to the big-internet@munnari.oz.au mailing list.</t>
</abstract>
</front>

<seriesInfo value="1669" name="RFC" />
</reference>


<reference target2="reference.RFC.1670.xml" anchor="RFC1670">
<front>
<title>Input to IPng Engineering Considerations</title>
<author fullname="Denise Heagerty" initials="D." surname="Heagerty">
<organization>CERN, Communications Systems, Computing and Networks Division</organization>

<address>
<postal>
<street>1211 Geneva 23</street>
<city />
<region />
<code />
<country>CH</country>
</postal>

<phone>+41 22 7674975</phone>
<facsimile>+41 22 7677155</facsimile>
<email>denise@dxcoms.cern.ch</email>
</address>
</author>

<date year="1994" month="August" />

<abstract>
<t>This document was submitted to the IETF IPng area in response to RFC 1550.  Publication of this document does not imply acceptance by the IPng area of any ideas expressed within.  Comments should be submitted to the big-internet@munnari.oz.au mailing list.</t>
</abstract>
</front>

<seriesInfo value="1670" name="RFC" />
</reference>


<reference target2="reference.RFC.1671.xml" anchor="RFC1671">
<front>
<title abbrev="IPng White Paper on Transition, etc.">IPng White Paper on Transition and Other Considerations</title>
<author fullname="Brian E. Carpenter" initials="B." surname="Carpenter">
<organization>CERN, Communications Systems, Computing and Networks Division</organization>

<address>
<postal>
<street>1211 Geneva 23</street>
<city />
<region />
<code />
<country>CH</country>
</postal>

<phone>+41 22 7674967</phone>
<facsimile>+41 22 7677155</facsimile>
<email>brian@dxcoms.cern.ch</email>
</address>
</author>

<date year="1994" month="August" />

<abstract>
<t>This document was submitted to the IETF IPng area in response to RFC 1550.  Publication of this document does not imply acceptance by the IPng area of any ideas expressed within.  Comments should be submitted to the big-internet@munnari.oz.au mailing list.</t>
</abstract>
</front>

<seriesInfo value="1671" name="RFC" />
</reference>


<reference target2="reference.RFC.1672.xml" anchor="RFC1672">
<front>
<title>Accounting Requirements for IPng</title>
<author fullname="Nevil Brownlee" initials="N." surname="Brownlee">
<organization>The University of Auckland, Computer Centre</organization>

<address>
<postal>
<street>Private Bag 92019</street>
<city>Auckland</city>
<region />
<code />
<country>NZ</country>
</postal>

<phone>+64 9 3737599</phone>
<facsimile>+64 9 3737425</facsimile>
<email>n.brownlee@auckland.ac.nz</email>
</address>
</author>

<date year="1994" month="August" />

<abstract>
<t>This document was submitted to the IETF IPng area in response to RFC 1550.  Publication of this document does not imply acceptance by the IPng area of any ideas expressed within.  Comments should be submitted to the big-internet@munnari.oz.au mailing list.</t>
</abstract>
</front>

<seriesInfo value="1672" name="RFC" />
</reference>


<reference target2="reference.RFC.1673.xml" anchor="RFC1673">
<front>
<title abbrev="EPRI Comments on IPng">Electric Power Research Institute Comments on IPng</title>
<author fullname="Ron Skelton" initials="R." surname="Skelton">
<organization>Electric Power Research Institute, Advanced IT Group</organization>

<address>
<postal>
<street />
<city>Palo Alto</city>
<region>CA</region>
<code>94303</code>
<country>US</country>
</postal>

<email>RSKELTON@msm.epri.com</email>
</address>
</author>

<date year="1994" month="August" />

<abstract>
<t>This document was submitted to the IETF IPng area in response to RFC 1550.  Publication of this document does not imply acceptance by the IPng area of any ideas expressed within.  Comments should be submitted to the big-internet@munnari.oz.au mailing list.</t>
</abstract>
</front>

<seriesInfo value="1673" name="RFC" />
</reference>


<reference target2="reference.RFC.1674.xml" anchor="RFC1674">
<front>
<title>A Cellular Industry View of IPng</title>
<author fullname="Mark S. Taylor" initials="M." surname="Taylor">
<organization>McCaw Cellular Communications, Inc., Wireless Data Division</organization>

<address>
<postal>
<street>10230 NE Points Drive</street>
<city>Kirkland</city>
<region>WA</region>
<code>98033-7869</code>
<country>US</country>
</postal>

<email>mark.s.taylor@airdata.com</email>
</address>
</author>

<date year="1994" month="August" />

<abstract>
<t>This memo is a response to RFC 1550, "IP: Next Generation (IPng) White Paper Solicitation".  The statements in this paper are intended as input to the technical discussions within IETF, and do not represent any endorsement or commitment on the part of the cellular industry, the Cellular Digital Packet Data (CDPD) consortium of service providers or any of its constituent companies.</t>
</abstract>
</front>

<seriesInfo value="1674" name="RFC" />
</reference>


<reference target2="reference.RFC.1675.xml" anchor="RFC1675">
<front>
<title>Security Concerns for IPng</title>
<author fullname="Steven M. Bellovin" initials="S." surname="Bellovin">
<organization>AT&amp;T Bell Laboratories, Software Engineering Research Department</organization>

<address>
<postal>
<street>600 Mountain Avenue</street>
<city>Murray Hill</city>
<region>NJ</region>
<code>07974</code>
<country>US</country>
</postal>

<phone>+1 908 582 5886</phone>
<facsimile>+1 908 582 3063</facsimile>
<email>smb@research.att.com</email>
</address>
</author>

<date year="1994" month="August" />

<abstract>
<t>This document was submitted to the IETF IPng area in response to RFC 1550.  Publication of this document does not imply acceptance by the IPng area of any ideas expressed within.  Comments should be submitted to the big-internet@munnari.oz.au mailing list.</t>
</abstract>
</front>

<seriesInfo value="1675" name="RFC" />
</reference>


<reference target2="reference.RFC.1676.xml" anchor="RFC1676">
<front>
<title>INFN Requirements for an IPng</title>
<author fullname="Antonia Ghiselli" initials="A." surname="Ghiselli">
<organization>National Institute of Nuclear Physics - National Networking Center,  INFN-CNAF</organization>

<address>
<postal>
<street>8 V.le Ercolani</street>
<city>Bologna</city>
<region />
<code>40138</code>
<country>IT</country>
</postal>

<phone>+39 51 6098267</phone>
<facsimile>+39 51 6098135</facsimile>
<email>Ghiselli@infn.it</email>
</address>
</author>

<author fullname="Davide Salomoni" initials="D." surname="Salomoni">
<organization>National Institute of Nuclear Physics - National Networking Center,  INFN-CNAF</organization>

<address>
<postal>
<street>8 V.le Ercolani</street>
<city>Bologna</city>
<region />
<code>40138</code>
<country>IT</country>
</postal>

<phone>+39 51 6098260</phone>
<facsimile>+39 51 6098135</facsimile>
<email>Salomoni@infn.it</email>
</address>
</author>

<author fullname="Cristina Vistoli" initials="C." surname="Vistoli">
<organization>National Institute of Nuclear Physics - National Networking Center,  INFN-CNAF</organization>

<address>
<postal>
<street>8 V.le Ercolani</street>
<city>Bologna</city>
<region />
<code>40138</code>
<country>IT</country>
</postal>

<phone>+39 51 6098260</phone>
<facsimile>+39 51 6098135</facsimile>
<email>Vistoli@infn.it</email>
</address>
</author>

<date year="1994" month="August" />

<abstract>
<t>This white paper is sent by INFN network team, the Italian National Institute for nuclear physics, whose network, named INFNet, is a nationwide network founded to provide the access to existing national and international HEP laboratory and to facilitate communications between the researchers.  With this paper we would like to emphasize the key points that we would to consider if charged with IPng plan.  We do not really expect to add original items to the selection, but we think that it could be useful to submit the opinions and ideas that come from our network experience.</t>
</abstract>
</front>

<seriesInfo value="1676" name="RFC" />
</reference>


<reference target2="reference.RFC.1677.xml" anchor="RFC1677">
<front>
<title abbrev="IPng Tactical RF Requirements">Tactical Radio Frequency Communication Requirements for IPng</title>
<author fullname="R. Brian Adamson" initials="R." surname="Adamson">
<organization>Naval Research Laboratory, Communication Systems Branch, Information Technology Division</organization>

<address>
<postal>
<street>NRL Code 5523</street>
<city>Washington</city>
<region>DC</region>
<code>20375</code>
<country>US</country>
</postal>

<email>adamson@itd.nrl.navy.mil</email>
</address>
</author>

<date year="1994" month="August" />

<abstract>
<t>This document was submitted to the IETF IPng area in response to RFC 1550.  Publication of this document does not imply acceptance by the IPng area of any ideas expressed within.  Comments should be submitted to the big-internet@munnari.oz.au mailing list.</t>
</abstract>
</front>

<seriesInfo value="1677" name="RFC" />
</reference>


<reference target2="reference.RFC.1678.xml" anchor="RFC1678">
<front>
<title>IPng Requirements of Large Corporate Networks</title>
<author fullname="Edward Britton" initials="E." surname="Britton">
<organization>IBM Corp.</organization>

<address>
<postal>
<street>P.O.Box 12195</street>
<street>E69/503</street>
<city>Research Triangle Park</city>
<region>NC</region>
<code>27709</code>
<country>US</country>
</postal>

<phone>+1 919 254 6037</phone>
<email>brittone@vnet.ibm.com</email>
</address>
</author>

<author fullname="John Tavs" initials="J." surname="Tavs">
<organization>IBM Corp.</organization>

<address>
<postal>
<street>P.O.Box 12195</street>
<street>E69/503</street>
<city>Research Triangle Park</city>
<region>NC</region>
<code>27709</code>
<country>US</country>
</postal>

<phone>+1 919 245 7610</phone>
<email>tavs@vnet.ibm.com</email>
</address>
</author>

<date year="1994" month="August" />

<abstract>
<t>This document was submitted to the IETF IPng area in response to RFC 1550.  Publication of this document does not imply acceptance by the IPng area of any ideas expressed within.  Comments should be submitted to the big-internet@munnari.oz.au mailing list.  This draft summarizes some of the requirements of large corporate networks for the next generation of the Internet protcol suite.</t>
</abstract>
</front>

<seriesInfo value="1678" name="RFC" />
</reference>


<reference target2="reference.RFC.1679.xml" anchor="RFC1679">
<front>
<title abbrev="HPN IPng Requirements">HPN Working Group Input to the IPng Requirements Solicitation</title>
<author fullname="Dan Green" initials="D." surname="Green">
<organization>NSWC-DD</organization>

<address>
<postal>
<street>Code B35 NSWCDD</street>
<city>Dahlgren</city>
<region>VA</region>
<code>22448</code>
<country>US</country>
</postal>

<phone>+1 703 663 1571</phone>
<email>dtgreen@relay.nswc.navy.mil</email>
</address>
</author>

<author fullname="Phil Irey" initials="P." surname="Irey">
<organization>NSWC-DD</organization>

<address>
<postal>
<street>Code B35 NSWCDD</street>
<city>Dahlgren</city>
<region>VA</region>
<code>22448</code>
<country>US</country>
</postal>

<phone>+1 703 663 1571</phone>
<email>pirey@relay.nswc.navy.mil</email>
</address>
</author>

<author fullname="Dave Marlow" initials="D." surname="Marlow">
<organization>NSWC-DD</organization>

<address>
<postal>
<street>Code B35 NSWCDD</street>
<city>Dahlgren</city>
<region>VA</region>
<code>22448</code>
<country>US</country>
</postal>

<phone>+1 703 663 1571</phone>
<email>dmarlow@relay.nswc.navy.mil</email>
</address>
</author>

<author fullname="Karen O&apos;Donoghue" initials="K." surname="O&apos;Donoghue">
<organization>NSWC-DD</organization>

<address>
<postal>
<street>Code B35 NSWCDD</street>
<city>Dahlgren</city>
<region>VA</region>
<code>22448</code>
<country>US</country>
</postal>

<phone>+1 703 663 1571</phone>
<email>kodonog@relay.nswc.navy.mil</email>
</address>
</author>

<date year="1994" month="August" />

<abstract>
<t>This document was submitted to the IETF IPng area in response to RFC 1550.  Publication of this document does not imply acceptance by the IPng area of any ideas expressed within.  Comments should be submitted to the big-internet@munnari.oz.au mailing list.</t>
</abstract>
</front>

<seriesInfo value="1679" name="RFC" />
</reference>


<reference target2="reference.RFC.1680.xml" anchor="RFC1680">
<front>
<title>IPng Support for ATM Services</title>
<author fullname="Christina Brazdziunas" initials="C." surname="Brazdziunas">
<organization>Bellcore</organization>

<address>
<postal>
<street>445 South Street</street>
<city>Morristown</city>
<region>NJ</region>
<code>07960</code>
<country>US</country>
</postal>

<phone>+1 201 829 4173</phone>
<email>crb@faline.bellcore.com</email>
</address>
</author>

<date year="1994" month="August" />

<abstract>
<t>This document was submitted to the IETF IPng area in response to RFC 1550.  Publication of this document does not imply acceptance by the IPng area of any ideas expressed within.  Comments should be submitted to the big-internet@munnari.oz.au mailing list.</t>
</abstract>
</front>

<seriesInfo value="1680" name="RFC" />
</reference>


<reference target2="reference.RFC.1681.xml" anchor="RFC1681">
<front>
<title>On Many Addresses per Host</title>
<author fullname="Steven M. Bellovin" initials="S." surname="Bellovin">
<organization>AT &amp; T Bell Laboratories, Software Engineering Research Department</organization>

<address>
<postal>
<street>600 Mountain Avenue</street>
<city>Murray Hill</city>
<region>NJ</region>
<code>07974</code>
<country>US</country>
</postal>

<phone>+1 908 582 5886</phone>
<facsimile>+1 908 582 3063</facsimile>
<email>smb@research.att.com</email>
</address>
</author>

<date year="1994" month="August" />

<abstract>
<t>This document was submitted to the IETF IPng area in response to RFC 1550.  Publication of this document does not imply acceptance by the IPng area of any ideas expressed within.  Comments should be submitted to the big-internet@munnari.oz.au mailing list.</t>
</abstract>
</front>

<seriesInfo value="1681" name="RFC" />
</reference>


<reference target2="reference.RFC.1682.xml" anchor="RFC1682">
<front>
<title>IPng BSD Host Implementation Analysis</title>
<author fullname="Jim Bound" initials="J." surname="Bound">
<organization>Digital Equipment Corporation</organization>

<address>
<postal>
<street>110 Spitbrook Road</street>
<street>ZK3-3/U14</street>
<city>Nashua</city>
<region>NH</region>
<code>03062-2698</code>
<country>US</country>
</postal>

<phone>+1 603 881 0400</phone>
<email>bound@zk3.dec.com</email>
</address>
</author>

<date year="1994" month="August" />

<abstract>
<t>This document was submitted to the IETF IPng area in response to RFC 1550.  Publication of this document does not imply acceptance by the IPng area of any ideas expressed within.  Comments should be submitted to the big-internet@munnari.oz.au mailing list.</t>
</abstract>
</front>

<seriesInfo value="1682" name="RFC" />
</reference>


<reference target2="reference.RFC.1683.xml" anchor="RFC1683">
<front>
<title>Multiprotocol Interoperability In IPng</title>
<author fullname="Russell J. Clark" initials="R." surname="Clark">
<organization>Georgia Institute of Technology, College of Computing</organization>

<address>
<postal>
<street />
<city>Atlanta</city>
<region>GA</region>
<code>30332-0280</code>
<country>US</country>
</postal>

<email>rjc@cc.gatech.edu</email>
</address>
</author>

<author fullname="Mostafa H. Ammar" initials="M." surname="Ammar">
<organization>Georgia Institute of Technology, College of Computing</organization>

<address>
<postal>
<street />
<city>Atlanta</city>
<region>GA</region>
<code>30332-0280</code>
<country>US</country>
</postal>

<email>ammar@cc.gatech.edu</email>
</address>
</author>

<author fullname="Kenneth L. Calvert" initials="K." surname="Calvert">
<organization>Georgia Institute of Technology,  College of Computing</organization>

<address>
<postal>
<street />
<city>Atlanta</city>
<region>GA</region>
<code>30332-0280</code>
<country>US</country>
</postal>

<email>calvert@cc.gatech.edu</email>
</address>
</author>

<date year="1994" month="August" />

<abstract>
<t>This document was submitted to the IETF IPng area in response to RFC 1550.  Publication of this document does not imply acceptance by the IPng area of any ideas expressed within.  Comments should be submitted to the big-internet@munnari.oz.au mailing list.</t>
</abstract>
</front>

<seriesInfo value="1683" name="RFC" />
</reference>


<reference target2="reference.RFC.1684.xml" anchor="RFC1684">
<front>
<title abbrev="Introduction to X.500 White Pages Services">Introduction to White Pages Services based on X.500</title>
<author fullname="Peter Jurg" initials="P." surname="Jurg">
<organization>SURFnet bv</organization>

<address>
<postal>
<street>Postbus 19035</street>
<city>Utrecht</city>
<region />
<code>NL-3501 DA</code>
<country>NL</country>
</postal>

<phone>+31 30 310290</phone>
<facsimile>+31 20 340903</facsimile>
<email>Peter.Jurg@surfnet.nl</email>
</address>
</author>

<date year="1994" month="August" />

<abstract>
<t>This document aims at organisations who are using local and global electronic communication on a day to day basis and for whom using an electronic White Pages Service is therefore indispensable.</t>

<t>The document provides an introduction to the international ITU-T (formerly CCITT) X.500 and ISO 9594 standard, which is particularly suited for providing an integrated local and global electronic White Pages Service.</t>

<t>In addition a short overview of the experience gained from the Paradise X.500 pilot is given. References to more detailed information are included.</t>

<t>The document should be useful for managers of the above mentioned organisations who need to get the necessary executive commitment for making the address information of their organisation available by means of X.500.</t>
</abstract>
</front>

<seriesInfo value="1684" name="RFC" />
</reference>


<reference target2="reference.RFC.1685.xml" anchor="RFC1685">
<front>
<title>Writing X.400 O/R Names</title>
<author fullname="Harald Tveit Alvestrand" initials="H." surname="Alvestrand">
<organization>UNINETT A/S</organization>

<address>
<postal>
<street>P.O.Box 6883</street>
<street>ELGESETER</street>
<city>Trondheim</city>
<region />
<code>N-7002</code>
<country>NO</country>
</postal>

<email>Harald.Alvestrand@uninett.no</email>
</address>
</author>

<date year="1994" month="August" />

<abstract>
<t></t>
</abstract>
</front>

<seriesInfo value="1685" name="RFC" />
</reference>


<reference target2="reference.RFC.1686.xml" anchor="RFC1686">
<front>
<title abbrev="A Cable Television Industry Viewpoint on IPng">IPng Requirements: A Cable Television Industry Viewpoint</title>
<author fullname="Mario P. Vecchi" initials="M." surname="Vecchi">
<organization>Time Warner Cable</organization>

<address>
<postal>
<street>160 Inverness Drive West</street>
<city>Englewood</city>
<region>CO</region>
<code>80112</code>
<country>US</country>
</postal>

<phone>+1 303 799 5540</phone>
<facsimile>+1 303 799 5651</facsimile>
<email>mpvecchi@twcable.com</email>
</address>
</author>

<date year="1994" month="August" />

<abstract>
<t>This document was submitted to the IETF IPng area in response to RFC 1550.  Publication of this document does not imply acceptance by the IPng area of any ideas expressed within.  The statements in this paper are intended as input to the technical discussions within IETF, and do not represent any endorsement or commitment on the part of the cable television industry or any of its companies.  Comments should be submitted to the big-internet@munnari.oz.au mailing list.</t>
</abstract>
</front>

<seriesInfo value="1686" name="RFC" />
</reference>


<reference target2="reference.RFC.1687.xml" anchor="RFC1687">
<front>
<title>A Large Corporate User's View of IPng</title>
<author fullname="Eric Fleischman" initials="E." surname="Fleischman">
<organization>Boeing Computer Services</organization>

<address>
<postal>
<street>P.O. Box 24346</street>
<street>MS 7M-HA</street>
<city>Seattle</city>
<region>WA</region>
<code>98124-0346</code>
<country>US</country>
</postal>

<email>ericf@atc.boeing.com</email>
</address>
</author>

<date year="1994" month="August" />

<abstract>
<t>This document was submitted to the IETF IPng area in response to RFC 1550.  Publication of this document does not imply acceptance by the IPng area of any ideas expressed within.  Comments should be submitted to the big-internet@munnari.oz.au mailing list.</t>
</abstract>
</front>

<seriesInfo value="1687" name="RFC" />
</reference>


<reference target2="reference.RFC.1688.xml" anchor="RFC1688">
<front>
<title abbrev="IPng Mobility">IPng Mobility Considerations</title>
<author fullname="William Allen Simpson" initials="W." surname="Simpson">
<organization>Daydreamer, Computer Systems Consulting Services</organization>

<address>
<postal>
<street>1384 Fontaine</street>
<city>Madison Heights</city>
<region>MI</region>
<code>48071</code>
<country>US</country>
</postal>

<email>Bill.Simpson@um.cc.umich.edu or</email>
</address>
</author>

<date year="1994" month="August" />

<abstract>
<t>This document was submitted to the IPng Area in response to RFC 1550. Publication of this document does not imply acceptance by the IPng Area of any ideas expressed within.  Comments should be submitted to the big-internet@munnari.oz.au mailing list.  This RFC specifies criteria related to mobility for consideration in design and selection of the Next Generation of IP.</t>
</abstract>
</front>

<seriesInfo value="1688" name="RFC" />
</reference>


<reference target2="reference.RFC.1689.xml" anchor="RFC1689">
<front>
<title abbrev="Networked Information Retrieval: Tools and Groups">A Status Report on Networked Information Retrieval: Tools and Groups</title>
<author fullname="Jill Foster" initials="J." surname="Foster">
<organization>University of Newcastle upon Tyne, Computing Service</organization>

<address>
<postal>
<street>Claremont Road</street>
<city>Newcastle upon Tyne</city>
<region>England</region>
<code>NE1 7RU</code>
<country>UK</country>
</postal>

<phone>+44 91 2228250</phone>
<facsimile>+44 91 2228765</facsimile>
<email>Jill.Foster@newcastle.ac.uk</email>
</address>
</author>

<date year="1994" month="August" />

<abstract>
<t>The purpose of this report is to increase the awareness of Networked Information Retrieval by bringing together in one place information about the various networked information retrieval tools, their developers, interested organisations, and other activities that relate to the production, dissemination, and support of NIR tools. NIR Tools covered include Archie, WAIS, gopher and World Wide Web.</t>
</abstract>
</front>

<seriesInfo value="1689" name="RFC" />
</reference>


<reference target2="reference.RFC.1690.xml" anchor="RFC1690">
<front>
<title abbrev="The Internet Engineering and Planning Group">Introducing the Internet Engineering and Planning Group (IEPG)</title>
<author fullname="Geoff Huston" initials="G." surname="Huston">
<organization>Australian Academic and Research Network</organization>

<address>
<postal>
<street>GPO Box 1142</street>
<city>Canberra</city>
<region>ACT</region>
<code>2601</code>
<country>AU</country>
</postal>

<phone>+61 6 2493385</phone>
<facsimile>+61 6 2491369</facsimile>
<email>Geoff.Huston@aarnet.edu.au</email>
</address>
</author>

<date year="1994" month="August" />

<abstract>
<t>This memo introduces the IEPG to the Internet Community.  The IEPG is an Internet Service Operators' forum, intended to assist Service Operators to coordinate in operational aspects of managing Internet services.</t>
</abstract>
</front>

<seriesInfo value="1690" name="RFC" />
</reference>


<reference target2="reference.RFC.1691.xml" anchor="RFC1691">
<front>
<title abbrev="CDL Document Architecture">The Document Architecture for the Cornell Digital Library</title>
<author fullname="William Turner" initials="W." surname="Turner">
<organization>Cornell University, Library Technology</organization>

<address>
<postal>
<street>502 Olin Library</street>
<city>Ithaca</city>
<region>NY</region>
<code>14853</code>
<country>US</country>
</postal>

<phone>+1 607 255 9098</phone>
<facsimile>+1 607 255 9346</facsimile>
<email>wrt1@cornell.edu</email>
</address>
</author>

<date year="1994" month="August" />

<abstract>
<t>This memo defines an architecture for the storage and retrieval of the digital representations for books, journals, photographic images, etc., which are collected in a large organized digital library.</t>

<t>Two unique features of this architecture are the ability to generate reference documents and the ability to create multiple views of a document.</t>
</abstract>
</front>

<seriesInfo value="1691" name="RFC" />
</reference>


<reference target2="reference.RFC.1692.xml" anchor="RFC1692">
<front>
<title abbrev="TMux">Transport Multiplexing Protocol (TMux)</title>
<author fullname="Peter Cameron" initials="P." surname="Cameron">
<organization>Xylogics International, Ltd.</organization>

<address>
<postal>
<street>Featherstone Rd.</street>
<street>Wolverton Mill</street>
<city>Milton Keynes</city>
<region>England</region>
<code>MK12 5RD</code>
<country>UK</country>
</postal>

<phone>+44 908 222112</phone>
<facsimile>+44 908 222115</facsimile>
<email>cameron@xylint.co.uk</email>
</address>
</author>

<author fullname="David Crocker" initials="D." surname="Crocker">
<organization>Silicon Graphics, Inc.</organization>

<address>
<postal>
<street>2011 N. Shoreline Blvd.</street>
<street>P.O. Box 7311</street>
<city>Mountain View</city>
<region>CA</region>
<code>94039-7311</code>
<country>US</country>
</postal>

<phone>+1 415 390 1804</phone>
<facsimile>+1 415 962 8404</facsimile>
<email>dcrocker@sgi.com</email>
</address>
</author>

<author fullname="Danny Cohen" initials="D." surname="Cohen">
<organization>Myricom</organization>

<address>
<postal>
<street>325 N. Santa Anita Ave.</street>
<city>Arcadia</city>
<region>CA</region>
<code>91006</code>
<country>US</country>
</postal>

<phone>+1 818 821 5555</phone>
<email>Cohen@myricom.com</email>
</address>
</author>

<author fullname="Jon Postel" initials="J." surname="Postel">
<organization>USC/Information Sciences Institute</organization>

<address>
<postal>
<street>4676 Admiralty Way</street>
<city>Marina del Rey</city>
<region>CA</region>
<code>90292-6695</code>
<country>US</country>
</postal>

<phone>+1 310 822 1511</phone>
<facsimile>+1 310 823 6714</facsimile>
<email>EMail: Postel@ISI.EDU</email>
</address>
</author>

<date year="1994" month="August" />

<abstract>
<t>One of the problems with the use of terminal servers is the large number of small packets they can generate. Frequently, most of these packets are destined for only one or two hosts.  TMux is a protocol which allows multiple short transport segments, independent of application type, to be combined between a server and host pair.</t>
</abstract>
</front>

<seriesInfo value="1692" name="RFC" />
</reference>


<reference target2="reference.RFC.1693.xml" anchor="RFC1693">
<front>
<title>An Extension to TCP : Partial Order Service</title>
<author fullname="Tom Connolly" initials="T." surname="Connolly">
<organization>University of Delaware, Department of Computer &amp; Information</organization>

<address>
<postal>
<street>101C Smith Hall</street>
<city>Newark</city>
<region>DE</region>
<code>19716-2586</code>
<country>US</country>
</postal>

<email>connolly@udel.edu</email>
</address>
</author>

<author fullname="Paul D. Amer" initials="P." surname="Amer">
<organization>University of Delaware, Department of Computer &amp; Information</organization>

<address>
<postal>
<street>101C Smith Hall</street>
<city>Newark</city>
<region>DE</region>
<code>19716-2586</code>
<country>US</country>
</postal>

<email>amer@udel.edu</email>
</address>
</author>

<author fullname="Phill Conrad" initials="P." surname="Conrad">
<organization>University of Delaware, Department of Computer &amp; Information</organization>

<address>
<postal>
<street>101C Smith Hall</street>
<city>Newark</city>
<region>DE</region>
<code>19716-2586</code>
<country>US</country>
</postal>

<email>pconrad@udel.edu</email>
</address>
</author>

<date year="1994" month="November" />

<abstract>
<t>This RFC introduces a new transport mechanism for TCP based upon partial ordering.  The aim is to present the concepts of partial ordering and promote discussions on its usefulness in network communications.  Distribution of this memo is unlimited.</t>
</abstract>
</front>

<seriesInfo value="1693" name="RFC" />
</reference>


<reference target2="reference.RFC.1694.xml" anchor="RFC1694">
<front>
<title abbrev="SMDS Interface Objects">Definitions of Managed Objects for SMDS Interfaces using SMIv2</title>
<author fullname="Tracy A. Brown" initials="T." surname="Brown">
<organization>Bell Communications Research</organization>

<address>
<postal>
<street>331 Newman Springs Road</street>
<street>P.O. Box 7020</street>
<city>Red Bank</city>
<region>NJ</region>
<code>07701-7020</code>
<country>US</country>
</postal>

<phone>+1 908 758 2107</phone>
<email>tacox@mail.bellcore.com</email>
</address>
</author>

<author fullname="Kaj Tesink" initials="K." surname="Tesink">
<organization>Bell Communications Research</organization>

<address>
<postal>
<street>331 Newman Springs Road</street>
<street>P.O. Box 7020</street>
<city>Red Bank</city>
<region>NJ</region>
<code>07701-7020</code>
<country>US</country>
</postal>

<phone>+1 908 758 5254</phone>
<email>kaj@cc.bellcore.com</email>
</address>
</author>

<date year="1994" month="August" />

<abstract>
<t>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 objects for SMDS access interfaces. This includes the following access protocols:</t>

<t>SIPSIP/DXIandSIP/FRSIP/ATM</t>

<t>This memo replaces RFC 1304, and defines a MIB module which is both compliant to the SNMPv2 SMI and semantically-identical to the existing RFC 1304-based definitions.</t>

<t>This memo also assumes application of the MIB II Interfaces group as defined in.</t>
</abstract>
</front>

<seriesInfo value="1694" name="RFC" />
</reference>


<reference target2="reference.RFC.1695.xml" anchor="RFC1695">
<front>
<title abbrev="ATM Management Objects">Definitions of Managed Objects for ATM Management Version 8.0 using SMIv2</title>
<author fullname="Masuma Ahmed" initials="M." surname="Ahmed">
<organization>Bell Communications Research</organization>

<address>
<postal>
<street>331 Newman Springs Road</street>
<street>Room 1F-217</street>
<street>P.O. Box 7020</street>
<city>Red Bank</city>
<region>NJ</region>
<code>07701-7020</code>
<country>US</country>
</postal>

<phone>+1 908 758 2515</phone>
<email>mxa@mail.bellcore.com</email>
</address>
</author>

<author fullname="Kaj Tesink" initials="K." surname="Tesink">
<organization>Bell Communications Research</organization>

<address>
<postal>
<street>331 Newman Springs Road</street>
<street>Room 1A-427</street>
<street>P.O. Box 7020</street>
<city>Red Bank</city>
<region>NJ</region>
<code>07701-7020</code>
<country>US</country>
</postal>

<phone>+1 908 758 5254</phone>
<email>kaj@cc.bellcore.com</email>
</address>
</author>

<date year="1994" month="August" />

<abstract>
<t></t>
</abstract>
</front>

<seriesInfo value="1695" name="RFC" />
</reference>


<reference target2="reference.RFC.1696.xml" anchor="RFC1696">
<front>
<title abbrev="Modem MIB">Modem Management Information Base (MIB) using SMIv2</title>
<author fullname="Jim Barnes" initials="J." surname="Barnes">
<organization>Xylogics, Inc.</organization>

<address>
<postal>
<street>53 Third Avenue</street>
<city>Burlington</city>
<region>MA</region>
<code>01803</code>
<country>US</country>
</postal>

<phone>+1 617 272 8140</phone>
<facsimile>+1 617 272 2618</facsimile>
<email>barnes@xylogics.com</email>
</address>
</author>

<author fullname="Les Brown" initials="L." surname="Brown">
<organization>Motorola</organization>

<address>
<phone>+1 416 507 7200</phone>
<email>brown_l@msm.cdx.mot.com</email>
</address>
</author>

<author fullname="Rick Royston" initials="R." surname="Royston">
<organization>US Robotics, Inc.</organization>

<address>
<postal>
<street>8100 N. McCormick Boulevard</street>
<city>Skokie</city>
<region>IL</region>
<code>60076-2999</code>
<country>US</country>
</postal>

<phone>+1 708 933 5430</phone>
<facsimile>+1 708 982 1348</facsimile>
<email>rroyston@usr.com</email>
</address>
</author>

<author fullname="Steven Waldbusser" initials="S." surname="Waldbusser">
<organization>Carnegie Mellon University, Computing and Communications</organization>

<address>
<postal>
<street>5000 Forbes Avenue</street>
<street>Cyert Hall 130</street>
<city>Pittsburgh</city>
<region>PA</region>
<code>15213-3890</code>
<country>US</country>
</postal>

<phone>+1 412 268 6628</phone>
<facsimile>+1 412 268 4987</facsimile>
<email>swol@andrew.cmu.edu</email>
</address>
</author>

<date year="1994" month="August" />

<abstract>
<t></t>
</abstract>
</front>

<seriesInfo value="1696" name="RFC" />
</reference>


<reference target2="reference.RFC.1697.xml" anchor="RFC1697">
<front>
<title abbrev="RDBMS-MIB">Relational Database Management System (RDBMS) Management Information Base (MIB) using SMIv2</title>
<author fullname="David Brower" initials="D." surname="Brower">
<organization>The ASK Group, INGRES DBMS Development</organization>

<address>
<postal>
<street>1080 Marina Village Parkway</street>
<city>Alameda</city>
<region>CA</region>
<code>94501</code>
<country>US</country>
</postal>

<phone>+1 510 748 3418</phone>
<email>daveb@ingres.com</email>
</address>
</author>

<author fullname="Bob Purvy" initials="B." surname="Purvy">
<organization>Oracle Corporation</organization>

<address>
<postal>
<street>500 Oracle Parkway</street>
<city>Redwood City</city>
<region>CA</region>
<code>94065</code>
<country>US</country>
</postal>

<phone>+1 415 506 2972</phone>
<email>bpurvy@us.oracle.com</email>
</address>
</author>

<author fullname="Anthony Daniel" initials="A." surname="Daniel">
<organization>Informix Software, Inc.</organization>

<address>
<postal>
<street>921 S.W. Washington Street</street>
<city>Portland</city>
<region>OR</region>
<code>97205</code>
<country>US</country>
</postal>

<phone>+1 503 221 2638</phone>
<email>anthony@informix.com</email>
</address>
</author>

<author fullname="Marc Sinykin" initials="M." surname="Sinykin">
<organization>Oracle Corporation</organization>

<address>
<postal>
<street>400 Oracle Parkway</street>
<city>Redwood City</city>
<region>CA</region>
<code>94065</code>
<country>US</country>
</postal>

<phone>+1 415 506 2477</phone>
<email>msinykin@us.oracle.com</email>
</address>
</author>

<author fullname="Jay Smith" initials="J." surname="Smith">
<organization>Oracle Corporation</organization>

<address>
<postal>
<street>400 Oracle Parkway</street>
<city>Redwood City</city>
<region>CA</region>
<code>94065</code>
<country>US</country>
</postal>

<phone>+1 415 506 6239</phone>
<email>jaysmith@us.oracle.com</email>
</address>
</author>

<date year="1994" month="August" />

<abstract>
<t></t>
</abstract>
</front>

<seriesInfo value="1697" name="RFC" />
</reference>


<reference target2="reference.RFC.1698.xml" anchor="RFC1698">
<front>
<title abbrev="ThinOSI Upper-Layers Cookbook">Octet Sequences for Upper-Layer OSI to Support Basic Communications Applications</title>
<author fullname="Peter Furniss" initials="P." surname="Furniss">
<organization>Peter Furniss Consultants</organization>

<address>
<postal>
<street>58 Alexandra Crescent</street>
<city>Bromley, Kent</city>
<region>England</region>
<code>BR1 4EX</code>
<country>UK</country>
</postal>

<phone>+44 81 3131833</phone>
<facsimile>+44 81 3131833</facsimile>
<email>P.Furniss@ulcc.ac.uk</email>
</address>
</author>

<date year="1994" month="October" />

<abstract>
<t>This document states particular octet sequences that comprise the OSI upper-layer protocols (Session, Presentation and ACSE) when used to support applications with "basic communications requirements". These include OSI application protocols such as X.400 P7 and Directory Access Protocol, and "migrant" protocols, originally defined for use over other transports.</t>

<t>As well as the octet sequences which are the supporting layer headers (and trailers) around the application data, this document includes some tutorial material on the OSI upper layers.</t>

<t>An implementation that sends the octet sequences given here, and interprets the equivalent protocol received, will be able to interwork with an implementation based on the base standard, when both are being used to support an appropriate application protocol.</t>
</abstract>
</front>

<seriesInfo value="1698" name="RFC" />
</reference>


<reference target2="reference.RFC.1699.xml" anchor="RFC1699">
<front>
<title abbrev="Summary of 1600-1699">Summary of 1600-1699</title>
<author fullname="Josh Elliott" initials="J." surname="Elliott">
<organization>University of Southern California, Information Sciences Institute</organization>

<address>
<postal>
<street>4676 Admiralty Way</street>
<city>Marina del Rey</city>
<region>CA</region>
<code>90292</code>
<country>US</country>
</postal>

<phone>+1 310 822 1511</phone>
<email>elliott@isi.edu</email>
</address>
</author>

<date year="1997" month="January" />

<abstract>
<t></t>
</abstract>
</front>

<seriesInfo value="1699" name="RFC" />
</reference>


<reference target2="reference.RFC.1700.xml" anchor="RFC1700">
<front>
<title abbrev="Assigned Numbers">Assigned Numbers</title>
<author fullname="Joyce K. Reynolds" initials="J." surname="Reynolds">
<organization>USC/Information Sciences Institute</organization>

<address>
<postal>
<street>4676 Admiralty Way</street>
<city>Marina del Rey</city>
<region>CA</region>
<code>90292-6695</code>
<country>US</country>
</postal>

<phone>+1 310 822 1511</phone>
<email>jkrey@isi.edu</email>
</address>
</author>

<author fullname="Jon Postel" initials="J." surname="Postel">
<organization>USC/Information Sciences Institute</organization>

<address>
<postal>
<street>4676 Admiralty Way</street>
<city>Marina del Rey</city>
<region>CA</region>
<code>90292-6695</code>
<country>US</country>
</postal>

<phone>+1 310 822 1511</phone>
<email>postel@isi.edu</email>
</address>
</author>

<date year="1994" month="October" />

<abstract>
<t></t>
</abstract>
</front>

<seriesInfo value="1700" name="RFC" />
</reference>


<reference target2="reference.RFC.1701.xml" anchor="RFC1701">
<front>
<title>Generic Routing Encapsulation (GRE)</title>
<author fullname="Stan Hanks" initials="S." surname="Hanks">
<organization>NetSmiths, Ltd.</organization>

<address>
<postal>
<street>2025 Lincoln Highway</street>
<city>Edison</city>
<region>NJ</region>
<code>08817</code>
<country>US</country>
</postal>

<email>stan@netsmiths.com</email>
</address>
</author>

<author fullname="Tony Li" initials="T." surname="Li">
<organization>cisco Systems, Inc.</organization>

<address>
<postal>
<street>1525 O'Brien Drive</street>
<city>Menlo Park</city>
<region>CA</region>
<code>94025</code>
<country>US</country>
</postal>

<email>tli@cisco.com</email>
</address>
</author>

<author fullname="Dino Farinacci" initials="D." surname="Farinacci">
<organization>cisco Systems, Inc.</organization>

<address>
<postal>
<street>1525 O'Brien Drive</street>
<city>Menlo Park</city>
<region>CA</region>
<code>94025</code>
<country>US</country>
</postal>

<email>dino@cisco.com</email>
</address>
</author>

<author fullname="Paul Traina" initials="P." surname="Traina">
<organization>cisco Systems, Inc.</organization>

<address>
<postal>
<street>1525 O'Brien Drive</street>
<city>Menlo Park</city>
<region>CA</region>
<code>94025</code>
<country>US</country>
</postal>

<email>pst@cisco.com</email>
</address>
</author>

<date year="1994" month="October" />

<abstract>
<t>This document specifies a protocol for performing encapsulation of an arbitrary network layer protocol over another arbitrary network layer  protocol.</t>
</abstract>
</front>

<seriesInfo value="1701" name="RFC" />
</reference>


<reference target2="reference.RFC.1702.xml" anchor="RFC1702">
<front>
<title abbrev="GRE over IPv4 networks">Generic Routing Encapsulation over IPv4 networks</title>
<author fullname="Stan Hanks" initials="S." surname="Hanks">
<organization>NetSmiths, Ltd.</organization>

<address>
<postal>
<street>2025 Lincoln Highway</street>
<city>Edison</city>
<region>NJ</region>
<code>08817</code>
<country>US</country>
</postal>

<email>stan@netsmiths.com</email>
</address>
</author>

<author fullname="Tony Li" initials="T." surname="Li">
<organization>cisco Systems, Inc.</organization>

<address>
<postal>
<street>1525 O'Brien Drive</street>
<city>Menlo Park</city>
<region>CA</region>
<code>94025</code>
<country>US</country>
</postal>

<email>tli@cisco.com</email>
</address>
</author>

<author fullname="Dino Farinacci" initials="D." surname="Farinacci">
<organization>cisco Systems, Inc.</organization>

<address>
<postal>
<street>1525 O'Brien Drive</street>
<city>Menlo Park</city>
<region>CA</region>
<code>94025</code>
<country>US</country>
</postal>

<email>dino@cisco.com</email>
</address>
</author>

<author fullname="Paul Traina" initials="P." surname="Traina">
<organization>cisco Systems, Inc.</organization>

<address>
<postal>
<street>1525 O'Brien Drive</street>
<city>Menlo Park</city>
<region>CA</region>
<code>94025</code>
<country>US</country>
</postal>

<email>pst@cisco.com</email>
</address>
</author>

<date year="1994" month="October" />

<abstract>
<t></t>
</abstract>
</front>

<seriesInfo value="1702" name="RFC" />
</reference>


<reference target2="reference.RFC.1703.xml" anchor="RFC1703">
<front>
<title abbrev="Radio Paging -- Technical Procedures">Principles of Operation for the TPC.INT Subdomain: Radio Paging -- Technical Procedures</title>
<author fullname="Marshall T. Rose" initials="M." surname="Rose">
<organization>Dover Beach Consulting, Inc.</organization>

<address>
<postal>
<street>420 Whisman Court</street>
<city>Mountain View</city>
<region>CA</region>
<code>94043-2186</code>
<country>US</country>
</postal>

<phone>+1 415 968 1052</phone>
<facsimile>+1 415 968 2510</facsimile>
<email>mrose@dbc.mtview.ca.us</email>
</address>
</author>

<date year="1994" month="October" />

<abstract>
<t></t>
</abstract>
</front>

<seriesInfo value="1703" name="RFC" />
</reference>


<reference target2="reference.RFC.1704.xml" anchor="RFC1704">
<front>
<title>On Internet Authentication</title>
<author fullname="Neil Haller" initials="N." surname="Haller">
<organization>Bell Communications Research</organization>

<address>
<postal>
<street>445 South Street</street>
<street>MRE 2Q-280</street>
<city>Morristown</city>
<region>NJ</region>
<code>07962-1910</code>
<country>US</country>
</postal>

<phone>+1 201 829 4478</phone>
<email>nmh@thumper.bellcore.com</email>
</address>
</author>

<author fullname="Randall Atkinson" initials="R." surname="Atkinson">
<organization>Naval Research Laboratory, Information Technology Division</organization>

<address>
<postal>
<street />
<city>Washington</city>
<region>DC</region>
<code>20375-5320</code>
<country>US</country>
</postal>

<phone>(DSN) 354 8590</phone>
<email>atkinson@itd.nrl.navy.mil</email>
</address>
</author>

<date year="1994" month="October" />

<abstract>
<t></t>
</abstract>
</front>

<seriesInfo value="1704" name="RFC" />
</reference>


<reference target2="reference.RFC.1705.xml" anchor="RFC1705">
<front>
<title abbrev="Six Virtual Inches to the Left: IPng Problems">Six Virtual Inches to the Left: The Problem with IPng</title>
<author fullname="Richard Carlson" initials="R." surname="Carlson">
<organization>Argonne National Laboratory, Electronics and Computing Technologies</organization>

<address>
<postal>
<street />
<city>Argonne</city>
<region>IL</region>
<code>60439</code>
<country>US</country>
</postal>

<phone>+1 708 252 7289</phone>
<email>RACarlson@anl.gov</email>
</address>
</author>

<author fullname="Domenic Ficarella" initials="D." surname="Ficarella">
<organization>Motorola</organization>

<address>
<phone>+1 708 632 4029</phone>
<email>ficarell@cpdmfg.cig.mot.com</email>
</address>
</author>

<date year="1994" month="October" />

<abstract>
<t>This document was submitted to the IETF IPng area in response to RFC 1550.  Publication of this document does not imply acceptance by the IPng area of any ideas expressed within.  Comments should be submitted to the big-internet@munnari.oz.au mailing list.</t>
</abstract>
</front>

<seriesInfo value="1705" name="RFC" />
</reference>


<reference target2="reference.RFC.1706.xml" anchor="RFC1706">
<front>
<title abbrev="DNS NSAP RRs">DNS NSAP Resource Records</title>
<author fullname="Bill Manning" initials="B." surname="Manning">
<organization>USC/Information Sciences Institute</organization>

<address>
<postal>
<street>4676 Admiralty Way</street>
<city>Marina del Rey</city>
<region>CA</region>
<code>90292</code>
<country>US</country>
</postal>

<phone>+1 310 822 1511</phone>
<email>bmanning@isi.edu</email>
</address>
</author>

<author fullname="Richard Colella" initials="R." surname="Colella">
<organization>National Institute of Standards and Technology, Technology/B217</organization>

<address>
<postal>
<street />
<city>Gaithersburg</city>
<region>MD</region>
<code>20899</code>
<country>US</country>
</postal>

<phone>+1 301 975 3627</phone>
<facsimile>+1 301 590 0932</facsimile>
<email>colella@nist.gov</email>
</address>
</author>

<date year="1994" month="October" />

<abstract>
<t>OSI lower layer protocols, comprising the connectionless network protocol (CLNP) and supporting routing protocols, are deployed in some parts of the global Internet.  Maintenance and debugging of CLNP connectivity is greatly aided by support in the Domain Name System (DNS) for mapping between names and NSAP addresses.</t>

<t>This document defines the format of one new Resource Record (RR) for the DNS for domain name-to-NSAP mapping. The RR may be used with any NSAP address format.</t>

<t>NSAP-to-name translation is accomplished through use of the PTR RR (see STD 13, RFC 1035 for a description of the PTR RR). This paper describes how PTR RRs are used to support this translation.</t>

<t>This document obsoletes RFC 1348 and RFC 1637.</t>
</abstract>
</front>

<seriesInfo value="1706" name="RFC" />
</reference>


<reference target2="reference.RFC.1707.xml" anchor="RFC1707">
<front>
<title abbrev="CATNIP">CATNIP: Common Architecture for the Internet</title>
<author fullname="Michael McGovern" initials="M." surname="McGovern">
<organization>Sunspot Graphics</organization>

<address>
<email>scrivner@world.std.com</email>
</address>
</author>

<author fullname="Robert Ullmann" initials="R." surname="Ullmann">
<organization>Lotus Development Corporation</organization>

<address>
<postal>
<street>1 Rogers Street</street>
<city>Cambridge</city>
<region>MA</region>
<code>02142</code>
<country>US</country>
</postal>

<phone>+1 617 693 1315</phone>
<email>rullmann@crd.lotus.com</email>
</address>
</author>

<date year="1994" month="October" />

<abstract>
<t>This document was submitted to the IETF IPng area in response to RFC 1550  Publication of this document does not imply acceptance by the IPng area of any ideas expressed within.  Comments should be submitted to the big-internet@munnari.oz.au mailing list.</t>
</abstract>
</front>

<seriesInfo value="1707" name="RFC" />
</reference>


<reference target2="reference.RFC.1708.xml" anchor="RFC1708">
<front>
<title abbrev="NTP PICS Proforma">NTP PICS PROFORMA - For the Network Time Protocol Version 3</title>
<author fullname="Dan R. Gowin" initials="D." surname="Gowin">
<organization>Vitro a Tracor Company</organization>

<address>
<postal>
<street>5001 N. St. Rd. 37</street>
<city>Bloomington</city>
<region>IN</region>
<code>47404-1626</code>
<country>US</country>
</postal>

<phone>+1 812 336 2299 x379</phone>
<facsimile>+1 812 333 0415</facsimile>
<email>drg508@crane-ns.nwscc.sea06.navy.MIL</email>
</address>
</author>

<date year="1994" month="October" />

<abstract>
<t>This RFC describes a PICS Proforma translated into an Internet acceptable form.  The Original document was developed according to ISO 9646 for conformance test purposes.  This document is intended for both developers and users of the NTP (Network Time Protocol). This document contains specific information and performance characteristics for the use of NTP within the context of Internet usage.  It is suggested, that users wishing to use the synchronization capabilities of the Internet abide by the characteristics set within this document.</t>

<t>For more information please contact Dr. David Mills at Mills@udel.edu or review RFC 1305 for more information.</t>
</abstract>
</front>

<seriesInfo value="1708" name="RFC" />
</reference>


<reference target2="reference.RFC.1709.xml" anchor="RFC1709">
<front>
<title>K-12 Internetworking Guidelines</title>
<author fullname="Joan C. Gargano" initials="J." surname="Gargano">
<organization>University of California, Davis, Information Technology, Distributed Computing Analysis and Support</organization>

<address>
<postal>
<street />
<city>Davis</city>
<region>CA</region>
<code>95616</code>
<country>US</country>
</postal>

<email>jcgargano@ucdavis.edu</email>
</address>
</author>

<author fullname="David L. Wasley" initials="D." surname="Wasley">
<organization>University of California, Berkeley, Data Communication &amp; Network Services, Information Systems and Technology</organization>

<address>
<postal>
<street />
<city>Berkeley</city>
<region>CA</region>
<code>94720</code>
<country>US</country>
</postal>

<email>dlw@berkeley.edu</email>
</address>
</author>

<date year="1994" month="November" />

<abstract>
<t></t>
</abstract>
</front>

<seriesInfo value="1709" name="RFC" />
</reference>


<reference target2="reference.RFC.1710.xml" anchor="RFC1710">
<front>
<title abbrev="SIPP IPng White Paper">Simple Internet Protocol Plus White Paper</title>
<author fullname="Robert M. Hinden" initials="R." surname="Hinden">
<organization>Sun Microsystems, Inc.</organization>

<address>
<postal>
<street>2550 Garcia Ave.</street>
<street>MS MTV5-44</street>
<city>Mountain View</city>
<region>CA</region>
<code>94043</code>
<country>US</country>
</postal>

<phone>+1 415 336 2082</phone>
<facsimile>+1 415 336 6016</facsimile>
<email>hinden@eng.sun.com</email>
</address>
</author>

<date year="1994" month="October" />

<abstract>
<t>This document was submitted to the IETF IPng area in response to RFC 1550.  Publication of this document does not imply acceptance by the IPng area of any ideas expressed within.  Comments should be submitted to the author and/or the sipp@sunroof.eng.sun.com mailing list.</t>
</abstract>
</front>

<seriesInfo value="1710" name="RFC" />
</reference>


<reference target2="reference.RFC.1711.xml" anchor="RFC1711">
<front>
<title>Classifications in E-mail Routing</title>
<author fullname="Jeroen Houttuin" initials="J." surname="Houttuin">
<organization>RARE Secretariat</organization>

<address>
<postal>
<street>Singel 466-468</street>
<city>Amsterdam</city>
<region />
<code>NL-1017 AW</code>
<country>NL</country>
</postal>

<phone>+31 20 6391131</phone>
<facsimile>+31 20 6393289</facsimile>
<email>houttuin@rare.nl</email>
</address>
</author>

<date year="1994" month="October" />

<abstract>
<t>This paper presents a classification for e-mail routing issues. It clearly defines commonly used terminology such as static routing, store-and-forward routing, source routing and others. Real life examples show which routing options are used in existing projects.</t>

<t>The goal is to define all terminology in one reference paper. This will also help relatively new mail system managers to understand the issues and make the right choices. The reader is expected to already have a solid understanding of general networking terminology.</t>

<t>In this paper, the word Message Transfer Agent (MTA) is used to describe a routing entity, which can be an X.400 MTA, a UNIX mailer, or any other piece of software performing mail routing functions. An MTA processes the so called envelope information of a message. The term User Agent (UA) is used to describe a piece of software performing user related mail functions. It processes the contents of a message's envelope, i.e., the header fields and body parts.</t>
</abstract>
</front>

<seriesInfo value="1711" name="RFC" />
</reference>


<reference target2="reference.RFC.1712.xml" anchor="RFC1712">
<front>
<title>DNS Encoding of Geographical Location</title>
<author fullname="Craig Farrell" initials="C." surname="Farrell">
<organization>Curtin University of technology, Department of Computer Science</organization>

<address>
<postal>
<street>GPO Box U1987</street>
<city>Perth</city>
<region>Western Australia</region>
<code />
<country>AU</country>
</postal>

<email>craig@cs.curtin.edu.au</email>
</address>
</author>

<author fullname="Mike Schulze" initials="M." surname="Schulze">
<organization>Curtin University of technology, Department of Computer Science</organization>

<address>
<postal>
<street>GPO Box U1987</street>
<city>Perth</city>
<region>Western Australia</region>
<code />
<country>AU</country>
</postal>

<email>mike@cs.curtin.edu.au</email>
</address>
</author>

<author fullname="Scott Pleitner" initials="S." surname="Pleitner">
<organization>Curtin University of technology, Department of Computer Science</organization>

<address>
<postal>
<street>GPO Box U1987</street>
<city>Perth</city>
<region>Western Australia</region>
<code />
<country>AU</country>
</postal>

<email>pleitner@cs.curtin.edu.au</email>
</address>
</author>

<author fullname="Daniel Baldoni" initials="D." surname="Baldoni">
<organization>Curtin University of technology, Department of Computer Science</organization>

<address>
<postal>
<street>GPO Box U1987</street>
<city>Perth</city>
<region>Western Australia</region>
<code />
<country>AU</country>
</postal>

<email>flint@cs.curtin.edu.au</email>
</address>
</author>

<date year="1994" month="November" />

<abstract>
<t>This document defines the format of a new Resource Record (RR) for the Domain Naming System (DNS), and reserves a corresponding DNS type mnemonic and numerical code.  This definition deals with associating geographical host location mappings to host names within a domain. The data shown in this document is fictitious and does not necessarily reflect the real Internet.</t>
</abstract>
</front>

<seriesInfo value="1712" name="RFC" />
</reference>


<reference target2="reference.RFC.1713.xml" anchor="RFC1713">
<front>
<title>Tools for DNS debugging</title>
<author fullname="Artur Romao" initials="A." surname="Romao">
<organization>Universidade Nova de Lisboa, DI - Faculdade de Ciencias e Tecnologia</organization>

<address>
<postal>
<street>Quinta da Torre</street>
<city>Monte de Caparica</city>
<region />
<code>P-2825</code>
<country>PT</country>
</postal>

<phone>+351 1 2942844</phone>
<facsimile>+351 1 2957786</facsimile>
<email>artur@fct.unl.pt</email>
</address>
</author>

<date year="1994" month="November" />

<abstract>
<t>Although widely used (and most of the times unnoticed), DNS (Domain Name System) is too much overlooked, in the sense that people, especially administrators, tend to ignore possible anomalies as long as applications that need name-to-address mapping continue to work. This document presents some tools available for domain administrators to detect and correct those anomalies.</t>
</abstract>
</front>

<seriesInfo value="1713" name="RFC" />
</reference>


<reference target2="reference.RFC.1714.xml" anchor="RFC1714">
<front>
<title>Referral Whois Protocol (RWhois)</title>
<author fullname="Scott Williamson" initials="S." surname="Williamson">
<organization />

<address>
<postal>
<street>505 Huntmar Park Dr.</street>
<city>Herndon</city>
<region>VA</region>
<code>22070</code>
<country>US</country>
</postal>

<phone>+1 703 742 4820</phone>
<email>scottw@internic.net</email>
</address>
</author>

<author fullname="Mark Kosters" initials="M." surname="Kosters">
<organization />

<address>
<postal>
<street>505 Huntmar Park Dr.</street>
<city>Herndon</city>
<region>VA</region>
<code>22070</code>
<country>US</country>
</postal>

<phone>+1 703 742 4795</phone>
<email>markk@internic.net</email>
</address>
</author>

<date year="1994" month="November" />

<abstract>
<t>This memo describes version 1.0 of the client/server interaction of RWhois.  RWhois provides a distributed system for the display of hierarchical information.  This system is hierarchical by design, allowing for the reduction of a query, and the referral of the user closer to the maintainer of the information.</t>
</abstract>
</front>

<seriesInfo value="1714" name="RFC" />
</reference>


<reference target2="reference.RFC.1715.xml" anchor="RFC1715">
<front>
<title abbrev="H Ratio">The H Ratio for Address Assignment Efficiency</title>
<author fullname="Christian Huitema" initials="C." surname="Huitema">
<organization>INRIA, Sophia-Antipolis</organization>

<address>
<postal>
<street>2004 Route des Lucioles</street>
<street>BP 109</street>
<city>Valbonne Cedex</city>
<region />
<code>F-06561</code>
<country>FR</country>
</postal>

<phone>+33 93 657715</phone>
<email>Christian.Huitema@MIRSA.INRIA.FR</email>
</address>
</author>

<date year="1994" month="November" />

<abstract>
<t>This document was submitted to the IETF IPng area in response to RFC 1550.  Publication of this document does not imply acceptance by the IPng area of any ideas expressed within.  Comments should be submitted to the author and/or the sipp@sunroof.eng.sun.com mailing list.</t>
</abstract>
</front>

<seriesInfo value="1715" name="RFC" />
</reference>


<reference target2="reference.RFC.1716.xml" anchor="RFC1716">
<front>
<title>Towards Requirements for IP Routers</title>
<author fullname="Philip Almquist" initials="P." surname="Almquist">
<organization />
</author>

<author fullname="Frank J. Kastenholz" initials="F." surname="Kastenholz">
<organization>FTP Software</organization>

<address>
<postal>
<street>2 High Street</street>
<city>North Andover</city>
<region>MA</region>
<code>01845-2620</code>
<country>US</country>
</postal>

<phone>+1 508 685 4000</phone>
<email>kasten@ftp.com</email>
</address>
</author>

<date year="1994" month="November" />
</front>

<seriesInfo value="1716" name="RFC" />
</reference>


<reference target2="reference.RFC.1717.xml" anchor="RFC1717">
<front>
<title abbrev="PPP Multilink">The PPP Multilink Protocol (MP)</title>
<author fullname="Keith Sklower" initials="K." surname="Sklower">
<organization>University of California, Berkeley, Computer Science Department</organization>

<address>
<postal>
<street>384 Soda Hall</street>
<street>Mail Stop 1776</street>
<city>Berkeley</city>
<region>CA</region>
<code>94720-1776</code>
<country>US</country>
</postal>

<phone>+1 510 642 9587</phone>
<email>sklower@CS.Berkeley.EDU</email>
</address>
</author>

<author fullname="Brian Lloyd" initials="B." surname="Lloyd">
<organization>Lloyd Internetworking</organization>

<address>
<postal>
<street>3031 Alhambra Drive</street>
<city>Cameron Park</city>
<region>CA</region>
<code>95682</code>
<country>US</country>
</postal>

<phone>+1 916 676 1147</phone>
<email>brian@lloyd.com</email>
</address>
</author>

<author fullname="Glenn McGregor" initials="G." surname="McGregor">
<organization>Lloyd Internetworking</organization>

<address>
<postal>
<street>3031 Alhambra Drive</street>
<city>Cameron Park</city>
<region>CA</region>
<code>95682</code>
<country>US</country>
</postal>

<phone>+1 916 676 1147</phone>
<email>glenn@lloyd.com</email>
</address>
</author>

<author fullname="Dave Carr" initials="D." surname="Carr">
<organization>Newbridge Networks Corporation</organization>

<address>
<postal>
<street>600 March Road</street>
<street>P.O. Box 13600</street>
<city>Kanata</city>
<region>Ontario</region>
<code>K2K 2E6</code>
<country>CA</country>
</postal>

<phone>+1 613 591 3600</phone>
<email>dcarr@Newbridge.COM</email>
</address>
</author>

<date year="1994" month="November" />

<abstract>
<t>This document proposes a method for splitting, recombining and sequencing datagrams across multiple logical data links.  This work was originally motivated by the desire to exploit multiple bearer channels in ISDN, but is equally applicable to any situation in which multiple PPP links connect two systems, including async links.  This  is accomplished by means of new PPPoptions and protocols.</t>
</abstract>
</front>

<seriesInfo value="1717" name="RFC" />
</reference>


<reference target2="reference.RFC.1718.xml" anchor="RFC1718">
<front>
<title abbrev="The Tao of IETF">The Tao of IETF - A Guide for New Attendees of the Internet Engineering Task Force</title>
<author>
<organization>Corporation for National Research Initiatives</organization>

<address>
<postal>
<street>1895 Preston White Drive</street>
<street>Suite 100</street>
<city>Reston</city>
<region>VA</region>
<code>22091</code>
<country>US</country>
</postal>

<phone>+1 703 620 8990</phone>
<facsimile>+1 703 620 0913</facsimile>
<email>ietf-info@cnri.reston.va.us</email>
</address>
</author>

<author fullname="Gary Scott Malkin" initials="G.S." surname="Malkin">
<organization>Xylogics, Inc.</organization>

<address>
<postal>
<street>53 Third Avenue</street>
<city>Burlington</city>
<region>MA</region>
<code>01803</code>
<country>US</country>
</postal>

<phone>+1 617 272 8140</phone>
<email>gmalkin@Xylogics.COM</email>
</address>
</author>

<date year="1994" month="November" />

<abstract>
<t>Over the last two years, the attendance at Internet Engineering Task Force (IETF) plenary meetings has grown phenomenally.  Approximately one third of the attendees are new to the IETF at each meeting, and many of those go on to become regular attendees.  When the meetings were smaller, it wasn't very difficult for a newcomer to get into the swing of things.  Today, however, a newcomer meets many more new people, some previously known only as the authors of documents or thought provoking e-mail messages.</t>

<t>The purpose of this For Your Information (FYI) RFC is to explain to the newcomers how the IETF works.  This will give them a warm, fuzzy feeling and enable them to make the meeting more productive for everyone.  This FYI will also provide the mundane bits of information which everyone who attends an IETF meeting should know.</t>
</abstract>
</front>

<seriesInfo value="1718" name="RFC" />
</reference>


<reference target2="reference.RFC.1719.xml" anchor="RFC1719">
<front>
<title>A Direction for IPng</title>
<author fullname="Phill Gross" initials="P." surname="Gross">
<organization>MCI Data Services Division</organization>

<address>
<postal>
<street>2100 Reston Parkway</street>
<street>FL 6</street>
<city>Reston</city>
<region>VA</region>
<code>22091</code>
<country>US</country>
</postal>

<phone>+1 703 715 7431</phone>
<email>phill_gross@mcimail.com</email>
</address>
</author>

<date year="1994" month="December" />

<abstract>
<t>This document was submitted to the IPng Area in response to RFC 1550.  Publication of this document does not imply acceptance by the IPng Area of any ideas expressed within.  Comments should be submitted to the big-internet@munnari.oz.au mailing list.  This RFC specifies criteria related to mobility for consideration in design and selection of the Next Generation of IP.</t>
</abstract>
</front>

<seriesInfo value="1719" name="RFC" />
</reference>


<reference target2="reference.RFC.1720.xml" anchor="RFC1720">
<front>
<title abbrev="Internet Standards">Internet Official Protocol Standards</title>
<author fullname="Jon Postel" initials="J." surname="Postel">
<organization>USC/Information Sciences Institute</organization>

<address>
<postal>
<street>4676 Admiralty Way</street>
<city>Marina del Rey</city>
<region>CA</region>
<code>90292</code>
<country>US</country>
</postal>

<phone>+1 310 822 1511</phone>
<facsimile>+1 310 823 6714</facsimile>
<email>Postel@ISI.EDU</email>
</address>
</author>

<date year="1994" month="November" />
</front>

<seriesInfo value="1720" name="RFC" />
</reference>


<reference target2="reference.RFC.1721.xml" anchor="RFC1721">
<front>
<title abbrev="RIP-2 Analysis">RIP Version 2 Protocol Analysis</title>
<author fullname="Gary Scott Malkin" initials="G." surname="Malkin">
<organization>Xylogics, Inc.</organization>

<address>
<postal>
<street>53 Third Avenue</street>
<city>Burlington</city>
<region>MA</region>
<code>01803</code>
<country>US</country>
</postal>

<phone>+1 617 272 8140</phone>
<email>gmalkin@Xylogics.COM</email>
</address>
</author>

<date year="1994" month="November" />

<abstract>
<t>As required by Routing Protocol Criteria (RFC 1264), this report documents the key features of the RIP-2 protocol and the current implementation experience.  This report is a prerequisite to advancing RIP-2 on the standards track.</t>
</abstract>
</front>

<seriesInfo value="1721" name="RFC" />
</reference>


<reference target2="reference.RFC.1722.xml" anchor="RFC1722">
<front>
<title abbrev="RIP-2 Applicability">RIP Version 2 Protocol Applicability Statement</title>
<author fullname="Gary Scott Malkin" initials="G." surname="Malkin">
<organization>Xylogics, Inc.</organization>

<address>
<postal>
<street>53 Third Avenue</street>
<city>Burlington</city>
<region>MA</region>
<code>01803</code>
<country>US</country>
</postal>

<phone>+1 617 272 8140</phone>
<email>gmalkin@Xylogics.COM</email>
</address>
</author>

<date year="1994" month="November" />

<abstract>
<t>As required by Routing Protocol Criteria (RFC 1264), this report defines the applicability of the RIP-2 protocol within the Internet. This report is a prerequisite to advancing RIP-2 on the standards track.</t>
</abstract>
</front>

<seriesInfo value="57" name="STD" />
<seriesInfo value="1722" name="RFC" />
</reference>


<reference target2="reference.RFC.1723.xml" anchor="RFC1723">
<front>
<title abbrev="RIP Version 2">RIP Version 2 - Carrying Additional Information</title>
<author fullname="Gary Scott Malkin" initials="G." surname="Malkin">
<organization>Xylogics, Inc.</organization>

<address>
<postal>
<street>53 Third Avenue</street>
<city>Burlington</city>
<region>MA</region>
<code>01803</code>
<country>US</country>
</postal>

<phone>+1 617 272 8140</phone>
<email>gmalkin@Xylogics.COM</email>
</address>
</author>

<date year="1994" month="November" />

<abstract>
<t>This document specifies an extension of the Routing Information Protocol (RIP), as defined in,, to expand the amount of useful
 information carried in RIP messages and to add a measure of security.  This memo obsoletes RFC 1388, which specifies an update to the "Routing Information Protocol" STD 34, RFC 1058.</t>

<t>The RIP-2 protocol analysis is documented in RFC 1721.</t>

<t>The RIP-2 applicability statement is document in RFC 1722.</t>

<t>The RIP-2 MIB description is defined in RFC 1724. This memo obsoletes RFC 1389.</t>
</abstract>
</front>

<seriesInfo value="56" name="STD" />
<seriesInfo value="1723" name="RFC" />
</reference>


<reference target2="reference.RFC.1724.xml" anchor="RFC1724">
<front>
<title abbrev="RIP-2 MIB Extension">RIP Version 2 MIB Extension</title>
<author fullname="Gary Malkin" initials="G." surname="Malkin">
<organization>Xylogics, Inc.</organization>

<address>
<postal>
<street>53 Third Avenue</street>
<city>Burlington</city>
<region>MA</region>
<code>01803</code>
<country>US</country>
</postal>

<phone>+1 617 272 8140</phone>
<email>gmalkin@Xylogics.COM</email>
</address>
</author>

<author fullname="Fred Baker" initials="F." surname="Baker">
<organization>Cisco Systems</organization>

<address>
<postal>
<street>519 Lado Drive</street>
<city>Santa Barbara</city>
<region>CA</region>
<code>93111</code>
<country>US</country>
</postal>

<phone>+1 805 681 0115</phone>
<email>fred@cisco.com</email>
</address>
</author>

<date year="1994" month="November" />

<abstract>
<t>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 RIP Version 2.</t>
</abstract>
</front>

<seriesInfo value="1724" name="RFC" />
</reference>


<reference target2="reference.RFC.1725.xml" anchor="RFC1725">
<front>
<title abbrev="POP3">Post Office Protocol - Version 3</title>
<author fullname="John G. Myers" initials="J." surname="Myers">
<organization>Carnegie-Mellon University</organization>

<address>
<postal>
<street>5000 Forbes Ave</street>
<city>Pittsburgh</city>
<region>PA</region>
<code>15213</code>
<country>US</country>
</postal>

<email>jgm+@cmu.edu</email>
</address>
</author>

<author fullname="Marshall T. Rose" initials="M." surname="Rose">
<organization>Dover Beach Consulting, Inc.</organization>

<address>
<postal>
<street>420 Whisman Court</street>
<city>Mountain View</city>
<region>CA</region>
<code>94043-2186</code>
<country>US</country>
</postal>

<email>mrose@dbc.mtview.ca.us</email>
</address>
</author>

<date year="1994" month="November" />
</front>

<seriesInfo value="53" name="STD" />
<seriesInfo value="1725" name="RFC" />
</reference>


<reference target2="reference.RFC.1726.xml" anchor="RFC1726">
<front>
<title abbrev="IPng Technical Criteria">Technical Criteria for Choosing IP The Next Generation (IPng)</title>
<author fullname="Craig Partridge" initials="C." surname="Partridge">
<organization>BBN Systems and Technologies</organization>

<address>
<postal>
<street>10 Moulton St.</street>
<city>Cambridge</city>
<region>MA</region>
<code>02138</code>
<country>US</country>
</postal>

<email>craig@aland.bbn.com</email>
</address>
</author>

<author fullname="Frank Kastenholz" initials="F." surname="Kastenholz">
<organization>FTP Software, Inc.</organization>

<address>
<postal>
<street>2 High St.</street>
<city>North Andover</city>
<region>MA</region>
<code>01845-2620</code>
<country>US</country>
</postal>

<email>kasten@ftp.com</email>
</address>
</author>

<date year="1994" month="December" />

<abstract>
<t>This document was submitted to the IPng Area in response to RFC 1550. Publication of this document does not imply acceptance by the IPng.  Area of any ideas expressed within.  Comments should be submitted to the big-internet@munnari.oz.au mailing list.  This RFC specifies criteria related to mobility for consideration in design and selection of the Next Generation of IP.</t>
</abstract>
</front>

<seriesInfo value="1726" name="RFC" />
</reference>


<reference target2="reference.RFC.1727.xml" anchor="RFC1727">
<front>
<title abbrev="Resource Transponders">A Vision of an Integrated Internet Information Service</title>
<author fullname="Chris Weider" initials="C." surname="Weider">
<organization>Bunyip Information Systems, Inc.</organization>

<address>
<postal>
<street>2001 S. Huron Parkway #12</street>
<city>Ann Arbor</city>
<region>MI</region>
<code>48104</code>
<country>US</country>
</postal>

<phone>+1 313 971 2223</phone>
<email>clw@bunyip.com</email>
</address>
</author>

<author fullname="Peter Deutsch" initials="P." surname="Deutsch">
<organization>Bunyip Information Systems, Inc.</organization>

<address>
<postal>
<street>310 Ste. Catherine St. West</street>
<street>Suite 202</street>
<city>Montreal</city>
<region>Quebec</region>
<code />
<country>CA</country>
</postal>

<phone>+1 514 875 8611</phone>
<email>peterd@bunyip.com</email>
</address>
</author>

<date year="1994" month="December" />

<abstract>
<t>This paper lays out a vision of how Internet information services might be integrated over the next few years, and discusses in some detail what steps will be needed to achieve this integration.</t>
</abstract>
</front>

<seriesInfo value="1727" name="RFC" />
</reference>


<reference target2="reference.RFC.1728.xml" anchor="RFC1728">
<front>
<title>Resource Transponders</title>
<author fullname="Chris Weider" initials="C." surname="Weider">
<organization>Bunyip Information Systems, Inc</organization>

<address>
<postal>
<street>2001 S. Huron Parkway</street>
<street>#12</street>
<city>Ann Arbor</city>
<region>MI</region>
<code>48104</code>
<country>US</country>
</postal>

<phone>+1 313 971 2223</phone>
<facsimile>+1 313 971 2223</facsimile>
<email>clw@bunyip.com</email>
</address>
</author>

<date year="1994" month="December" />

<abstract>
<t>Although a number of systems have been created in the last several years to provide resource location and navigation on the Internet, the information contained in these systems must be maintained and updated by hand.  This paper describes an automatic mechanism, the resource transponder, for maintaining resource location information.</t>
</abstract>
</front>

<seriesInfo value="1728" name="RFC" />
</reference>


<reference target2="reference.RFC.1729.xml" anchor="RFC1729">
<front>
<title>Using the Z39.50 Information Retrieval Protocol</title>
<author fullname="Clifford A. Lynch" initials="C." surname="Lynch">
<organization>University of California</organization>

<address>
<postal>
<street>300 Lakeside Drive</street>
<street>8th Floor</street>
<city>Oakland</city>
<region>CA</region>
<code>94612-3550</code>
<country>US</country>
</postal>

<phone>+1 510 987 0522</phone>
<email>clifford.lynch@ucop.edu</email>
</address>
</author>

<date year="1994" month="December" />
</front>

<seriesInfo value="1729" name="RFC" />
</reference>


<reference target2="reference.RFC.1730.xml" anchor="RFC1730">
<front>
<title abbrev="IMAP4">Internet Message Access Protocol - Version 4</title>
<author fullname="Mark R. Crispin" initials="M." surname="Crispin">
<organization>University of Washington, Networks and Distributed Computing</organization>

<address>
<postal>
<street>JE-30</street>
<city>Seattle</city>
<region>WA</region>
<code>98195</code>
<country>US</country>
</postal>

<phone>+1 206 543 5762</phone>
<email>MRC@CAC.Washington.EDU</email>
</address>
</author>

<date year="1994" month="December" />

<abstract>
<t>The Internet Message Access Protocol, Version 4 (IMAP4) allows a client to access and manipulate electronic mail messages on a server. IMAP4 permits manipulation of remote message folders, called "mailboxes", in a way that is functionally equivalent to local mailboxes.  IMAP4 also provides the capability for an offline client to resynchronize with the server (see also).</t>

<t>IMAP4 includes operations for creating, deleting, and renaming mailboxes; checking for new messages; permanently removing messages; setting and clearing flags; RFC 822 and MIME parsing; searching; and selective fetching of message attributes, texts, and portions thereof.  Messages in IMAP4 are accessed by the use of numbers. These numbers are either message sequence numbers (relative position from 1 to the number of messages in the mailbox) or unique identifiers (immutable, strictly ascending values assigned to each message, but which are not necessarily contiguous).</t>

<t>IMAP4 supports a single server.  A mechanism for supporting multiple IMAP4 servers is discussed in.</t>

<t>IMAP4 does not specify a means of posting mail; this function is handled by a mail transfer protocol such as.</t>

<t>IMAP4 is designed to be upwards compatible from theprotocol.  Compatibility issues are discussed in.</t>
</abstract>
</front>

<seriesInfo value="1730" name="RFC" />
</reference>


<reference target2="reference.RFC.1731.xml" anchor="RFC1731">
<front>
<title>IMAP4 Authentication Mechanisms</title>
<author fullname="John G. Myers" initials="J.G." surname="Myers">
<organization>Carnegie-Mellon University</organization>

<address>
<postal>
<street>5000 Forbes Ave.</street>
<city>Pittsburgh</city>
<region>PA</region>
<code>15213-3890</code>
<country>US</country>
</postal>

<email>jgm+@cmu.edu</email>
</address>
</author>

<date year="1994" month="December" />
</front>

<seriesInfo value="1731" name="RFC" />
</reference>


<reference target2="reference.RFC.1732.xml" anchor="RFC1732">
<front>
<title abbrev="IMAP4 - Compatibility">IMAP4 Compatibility with IMAP2 and IMAP2bis</title>
<author fullname="Mark R. Crispin" initials="M." surname="Crispin">
<organization>University of Washington, Networks and Distributed Computing</organization>

<address>
<postal>
<street>JE-30</street>
<city>Seattle</city>
<region>WA</region>
<code>98195</code>
<country>US</country>
</postal>

<phone>+1 206 543 5762</phone>
<email>MRC@CAC.Washington.EDU</email>
</address>
</author>

<date year="1994" month="December" />
</front>

<seriesInfo value="1732" name="RFC" />
</reference>


<reference target2="reference.RFC.1733.xml" anchor="RFC1733">
<front>
<title abbrev="IMAP4 - Model">Distributed Electronic Mail Models in IMAP4</title>
<author fullname="Mark R. Crispin" initials="M." surname="Crispin">
<organization>University of Washington, Networks and Distributed Computing</organization>

<address>
<postal>
<street>JE-30</street>
<city>Seattle</city>
<region>WA</region>
<code>98195</code>
<country>US</country>
</postal>

<phone>+1 206 543 5762</phone>
<email>MRC@CAC.Washington.EDU</email>
</address>
</author>

<date year="1994" month="December" />
</front>

<seriesInfo value="1733" name="RFC" />
</reference>


<reference target2="reference.RFC.1734.xml" anchor="RFC1734">
<front>
<title abbrev="POP3 AUTH">POP3 AUTHentication command</title>
<author fullname="John G. Myers" initials="J." surname="Myers">
<organization>Carnegie-Mellon University</organization>

<address>
<postal>
<street>5000 Forbes Ave</street>
<city>Pittsburgh</city>
<region>PA</region>
<code>15213</code>
<country>US</country>
</postal>

<email>jgm+@cmu.edu</email>
</address>
</author>

<date year="1994" month="December" />
</front>

<seriesInfo value="1734" name="RFC" />
</reference>


<reference target2="reference.RFC.1735.xml" anchor="RFC1735">
<front>
<title abbrev="NBMA ARP (NARP)">NBMA Address Resolution Protocol (NARP)</title>
<author fullname="Juha Heinanen" initials="J." surname="Heinanen">
<organization>Telecom Finland</organization>

<address>
<postal>
<street>PO Box 228</street>
<city>Tampere</city>
<region />
<code>SF-33101</code>
<country>FI</country>
</postal>

<phone>+358 3 49500958</phone>
<email>Juha.Heinanen@datanet.tele.fi</email>
</address>
</author>

<author fullname="Ramesh Govindan" initials="R." surname="Govindan">
<organization>USC/Information Sciences Institute</organization>

<address>
<postal>
<street>4676 Admiralty Way</street>
<city>Marina del Rey</city>
<region>CA</region>
<code>90292</code>
<country>US</country>
</postal>

<phone>+1 310 822 1511</phone>
<email>govindan@isi.edu</email>
</address>
</author>

<date year="1994" month="December" />

<abstract>
<t>This document describes the NBMA Address Resolution Protocol (NARP). NARP can be used by a source terminal (host or router) connected to a Non-Broadcast, Multi-Access link layer (NBMA) network to find out the NBMA addresses of the a destination terminal provided that the destination terminal is connected to the same NBMA network.  Although this document focuses on NARP in the context of IP, the technique is applicable to other network layer protocols as well.  This RFC is a product of the Routing over Large Clouds Working Group of the IETF.</t>
</abstract>
</front>

<seriesInfo value="1735" name="RFC" />
</reference>


<reference target2="reference.RFC.1736.xml" anchor="RFC1736">
<front>
<title abbrev="Recommendations for IRLs">Functional Recommendations for Internet Resource Locators</title>
<author fullname="John A. Kunze" initials="J." surname="Kunze">
<organization>Information Systems and Technology</organization>

<address>
<postal>
<street>293 Evans Hall</street>
<city>Berkeley</city>
<region>CA</region>
<code>94720</code>
<country>US</country>
</postal>

<phone>+1 510 642 1530</phone>
<facsimile>+1 510 643 5385</facsimile>
<email>jak@violet.berkeley.edu</email>
</address>
</author>

<date year="1995" month="February" />
</front>

<seriesInfo value="1736" name="RFC" />
</reference>


<reference target2="reference.RFC.1737.xml" anchor="RFC1737">
<front>
<title abbrev="Requirements for Uniform Resource Names">Functional Requirements for Uniform Resource Names</title>
<author fullname="Karen Sollins" initials="K." surname="Sollins">
<organization>MIT Laboratory for Computer Science</organization>

<address>
<postal>
<street>545 Technology Square</street>
<city>Cambridge</city>
<region>MA</region>
<code>02139</code>
<country>US</country>
</postal>

<phone>+1 617 253 2673</phone>
<email>sollins@lcs.mit.edu</email>
</address>
</author>

<author fullname="Larry Masinter" initials="L." surname="Masinter">
<organization>Xerox Palo Alto Research Center</organization>

<address>
<postal>
<street>3333 Coyote Hill Road</street>
<city>Palo Alto</city>
<region>CA</region>
<code>94304</code>
<country>US</country>
</postal>

<phone>+1 415 812 4365</phone>
<facsimile>+1 415 812 4333</facsimile>
<email>masinter@parc.xerox.com</email>
</address>
</author>

<date year="1994" month="December" />
</front>

<seriesInfo value="1737" name="RFC" />
</reference>


<reference target2="reference.RFC.1738.xml" anchor="RFC1738">
<front>
<title>Uniform Resource Locators (URL)</title>
<author fullname="Tim Berners-Lee" initials="T." surname="Berners-Lee">
<organization>CERN, World-Wide Web project</organization>

<address>
<postal>
<street>1211 Geneva 23</street>
<city />
<region />
<code />
<country>CH</country>
</postal>

<phone>+41 22 7673755</phone>
<facsimile>+41 22 7677155</facsimile>
<email>timbl@info.cern.ch</email>
</address>
</author>

<author fullname="Larry Masinter" initials="L." surname="Masinter">
<organization>Xerox PARC</organization>

<address>
<postal>
<street>3333 Coyote Hill Road</street>
<city>Palo Alto</city>
<region>CA</region>
<code>94034</code>
<country>US</country>
</postal>

<phone>+1 415 812 4365</phone>
<facsimile>+1 415 812 4333</facsimile>
<email>masinter@parc.xerox.com</email>
</address>
</author>

<author fullname="Mark McCahill" initials="M." surname="McCahill">
<organization>University of Minnesota, Computer and Information Services</organization>

<address>
<postal>
<street>100 Union Street SE, Shepherd Labs</street>
<street>Room 152</street>
<city>Minneapolis</city>
<region>MN</region>
<code>55455</code>
<country>US</country>
</postal>

<phone>+1 612 625 1300</phone>
<email>mpm@boombox.micro.umn.edu</email>
</address>
</author>

<date year="1994" month="December" />

<abstract>
<t>This document specifies a Uniform Resource Locator (URL), the syntax and semantics of formalized information for location and access of resources via the Internet.</t>
</abstract>
</front>

<seriesInfo value="1738" name="RFC" />
</reference>


<reference target2="reference.RFC.1739.xml" anchor="RFC1739">
<front>
<title abbrev="Primer on Internet &amp; TCP/IP Tools">A Primer On Internet and TCP/IP Tools</title>
<author fullname="Gary C. Kessler" initials="G." surname="Kessler">
<organization>Hill Associates</organization>

<address>
<postal>
<street>17 Roosevelt Highway</street>
<city>Colchester</city>
<region>VT</region>
<code>05446</code>
<country>US</country>
</postal>

<phone>+1 802 655 8633</phone>
<facsimile>+1 802 655 7974</facsimile>
<email>kumquat@hill.com</email>
</address>
</author>

<author fullname="Steven D. Shepard" initials="S." surname="Shepard">
<organization>Hill Associates</organization>

<address>
<postal>
<street>17 Roosevelt Highway</street>
<city>Colchester</city>
<region>VT</region>
<code>05446</code>
<country>US</country>
</postal>

<phone>+1 802 655 8646</phone>
<facsimile>+1 802 655 7974</facsimile>
<email>sds@hill.com</email>
</address>
</author>

<date year="1994" month="December" />

<abstract>
<t></t>
</abstract>
</front>

<seriesInfo value="1739" name="RFC" />
</reference>


<reference target2="reference.RFC.1740.xml" anchor="RFC1740">
<front>
<title abbrev="MIME-based Mac files">MIME Encapsulation of Macintosh Files - MacMIME</title>
<author fullname="Patrik Faltstrom" initials="P." surname="Faltstrom">
<organization>Royal Institute of Technology, Department of Numerical Analysis and Computing Science</organization>

<address>
<postal>
<street />
<city>Stockholm</city>
<region />
<code>S-100 44</code>
<country>SE</country>
</postal>

<email>paf@nada.kth.se</email>
</address>
</author>

<author fullname="Dave Crocker" initials="D." surname="Crocker">
<organization>Brandenburg Consulting</organization>

<address>
<postal>
<street>675 Spruce Dr.</street>
<city>Sunnyvale</city>
<region>CA</region>
<code>94086</code>
<country>US</country>
</postal>

<email>dcrocker@mordor.stanford.edu</email>
</address>
</author>

<author fullname="Erik E. Fair" initials="E." surname="Fair">
<organization>Apple Computer Inc., Engineering Computer Operations</organization>

<address>
<email>fair@apple.com</email>
</address>
</author>

<date year="1994" month="December" />

<abstract>
<t>This memo describes the format to use when sending Apple Macintosh files via MIME. The format is compatible with existing mechanisms for distributing Macintosh files, while allowing non-Macintosh systems access to data in standardized formats.</t>
</abstract>
</front>

<seriesInfo value="1740" name="RFC" />
</reference>


<reference target2="reference.RFC.1741.xml" anchor="RFC1741">
<front>
<title abbrev="Content Type for BinHex Files">MIME Content Type for BinHex Encoded Files</title>
<author fullname="Patrik Faltstrom" initials="P." surname="Faltstrom">
<organization>Royal Institute of Technology, Department of Numerical Analysis and Computing Science</organization>

<address>
<postal>
<street />
<city>Stockholm</city>
<region />
<code>S-100 44</code>
<country>SE</country>
</postal>

<email>paf@nada.kth.se</email>
</address>
</author>

<author fullname="Dave Crocker" initials="D." surname="Crocker">
<organization>Brandenburg Consulting</organization>

<address>
<postal>
<street>675 Spruce Dr.</street>
<city>Sunnyvale</city>
<region>CA</region>
<code>94086</code>
<country>US</country>
</postal>

<email>dcrocker@mordor.stanford.edu</email>
</address>
</author>

<author fullname="Erik E. Fair" initials="E.E." surname="Fair">
<organization>Apple Computer Inc., Engineering Computer Operations</organization>

<address>
<email>fair@apple.com</email>
</address>
</author>

<date year="1994" month="December" />

<abstract>
<t>This memo describes the format to use when sending BinHex4.0 files via MIME.  The format is compatible with existing mechanisms for distributing Macintosh files.  Only when available software and/or user practice dictates, should this method be employed.  It is recommended to use application/applefilefor maximum interoperability.</t>
</abstract>
</front>

<seriesInfo value="1741" name="RFC" />
</reference>


<reference target2="reference.RFC.1742.xml" anchor="RFC1742">
<front>
<title abbrev="AppleTalk MIB II">AppleTalk Management Information Base II</title>
<author fullname="Steven Waldbusser" initials="S." surname="Waldbusser">
<organization>Carnegie Mellon University</organization>

<address>
<postal>
<street>5000 Forbes Ave.</street>
<city>Pittsburgh</city>
<region>PA</region>
<code>15213</code>
<country>US</country>
</postal>

<phone>+1 412 268 6628</phone>
<email>waldbusser@cmu.edu</email>
</address>
</author>

<author fullname="Karen Frisa" initials="K." surname="Frisa">
<organization>FORE Systems, Inc.</organization>

<address>
<postal>
<street>174 Thorn Hill Road</street>
<city>Warrendale</city>
<region>PA</region>
<code>15086-7535</code>
<country>US</country>
</postal>

<phone>+1 412 772 6541</phone>
<email>kfrisa@fore.com</email>
</address>
</author>

<date year="1995" month="January" />

<abstract>
<t>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 AppleTalk networks.</t>

<t>RFC 1243 defines a set of MIB objects for managing the lower layers of the AppleTalk protocol stack, up to the Network layer.  This memo defines additional objects that exist in the AppleTalk portion of the MIB.  These objects provide for the management of the transport and session layers of the AppleTalk protocol stack, as well as extensions to the lower layers.  This is achieved in an upwardly-compatable fashion.</t>
</abstract>
</front>

<seriesInfo value="1742" name="RFC" />
</reference>


<reference target2="reference.RFC.1743.xml" anchor="RFC1743">
<front>
<title>IEEE 802.5 MIB using SMIv2</title>
<author fullname="Keith McCloghrie" initials="K." surname="McCloghrie">
<organization>cisco Systems, Inc.</organization>

<address>
<postal>
<street>170 West Tasman Drive</street>
<city>San Jose</city>
<region>CA</region>
<code>95134-1706</code>
<country>US</country>
</postal>

<phone>+1 408 526 5260</phone>
<email>kzm@cisco.com</email>
</address>
</author>

<author fullname="Eric B. Decker" initials="E." surname="Decker">
<organization>cisco Systems, Inc.</organization>

<address>
<postal>
<street>1525 O'Brien Dr.</street>
<city>Menlo Park</city>
<region>CA</region>
<code>94025</code>
<country>US</country>
</postal>

<phone>+1 415 688 8241</phone>
<email>cire@cisco.com</email>
</address>
</author>

<date year="1994" month="December" />
</front>

<seriesInfo value="1743" name="RFC" />
</reference>


<reference target2="reference.RFC.1744.xml" anchor="RFC1744">
<front>
<title abbrev="Management of Internet Address Space">Observations on the Management of the Internet Address Space</title>
<author fullname="Geoff Huston" initials="G." surname="Huston">
<organization>Australian Academic and Research Network</organization>

<address>
<postal>
<street>GPO Box 1142</street>
<city>Canberra</city>
<region>ACT</region>
<code>2601</code>
<country>AU</country>
</postal>

<phone>+61 6 2493385</phone>
<facsimile>+61 6 2491369</facsimile>
<email>Geoff.Huston@aarnet.edu.au</email>
</address>
</author>

<date year="1994" month="December" />

<abstract>
<t>This memo examines some of the issues associated with the current management practices of the Internet IPv4 address space, and examines the potential outcomes of these practices as the unallocated address pool shrinks in size.  Possible modifications to the management practices are examined, and potential outcomes considered.  Some general conclusions are drawn, and the relevance of these conclusions to the matter of formulation of address management policies for IPv6 are noted.</t>
</abstract>
</front>

<seriesInfo value="1744" name="RFC" />
</reference>


<reference target2="reference.RFC.1745.xml" anchor="RFC1745">
<front>
<title>BGP4/IDRP for IP---OSPF Interaction</title>
<author fullname="Kannan Varadhan" initials="K." surname="Varadhan">
<organization>USC/Information Sciences Institute</organization>

<address>
<postal>
<street>4676 Admiralty Way</street>
<city>Marina del Rey</city>
<region>CA</region>
<code>90292-6695</code>
<country>US</country>
</postal>

<phone>+1 310 822 1511 x402</phone>
<email>kannan@isi.edu</email>
</address>
</author>

<author fullname="Susan Hares" initials="S." surname="Hares">
<organization>Merit, Inc.</organization>

<address>
<postal>
<street>1071 Beal Avenue</street>
<city>Ann Arbor</city>
<region>MI</region>
<code>48109</code>
<country>US</country>
</postal>

<phone>+1 313 936 2095</phone>
<email>skh@merit.edu</email>
</address>
</author>

<author fullname="Yakov Rekhter" initials="Y." surname="Rekhter">
<organization>IBM Corporation, T.J. Watson Research Center</organization>

<address>
<postal>
<street>P.O. Box 704</street>
<city>Yorktown Heights</city>
<region>NY</region>
<code>10598</code>
<country>US</country>
</postal>

<phone>+1 914 784 7361</phone>
<email>yakov@watson.ibm.com</email>
</address>
</author>

<date year="1994" month="December" />

<abstract>
<t>This memo defines the various criteria to be used when designing an Autonomous System Border Router (ASBR) that will run either BGP4 or IDRP for IP with other ASBRs external to the AS and OSPF as its IGP.</t>
</abstract>
</front>

<seriesInfo value="1745" name="RFC" />
</reference>


<reference target2="reference.RFC.1746.xml" anchor="RFC1746">
<front>
<title>Ways to Define User Expectations</title>
<author fullname="Bill Manning" initials="B." surname="Manning">
<organization>USC/Information Sciences Institute</organization>

<address>
<postal>
<street>4676 Admiralty Way</street>
<city>Marina del Rey</city>
<region>CA</region>
<code>90292</code>
<country>US</country>
</postal>

<phone>+1 310 822 1511</phone>
<email>bmanning@isi.edu</email>
</address>
</author>

<author fullname="Don Perkins" initials="D." surname="Perkins">
<organization>Houston Independent School District, Instructional Media Services</organization>

<address>
<postal>
<street>3830 Richmond</street>
<city>Houston</city>
<region>TX</region>
<code>77027</code>
<country>US</country>
</postal>

<email>dperkins@tenet.edu</email>
</address>
</author>

<date year="1994" month="December" />

<abstract>
<t>This paper covers basic fundamentals that must be understood when one defines, interprets, or implements methods to control user expectations on or over the Internet.</t>
</abstract>
</front>

<seriesInfo value="1746" name="RFC" />
</reference>


<reference target2="reference.RFC.1747.xml" anchor="RFC1747">
<front>
<title abbrev="SNADLC SDLC MIB using SMIv2">Definitions of Managed Objects for SNA Data Link Control (SDLC) using SMIv2</title>
<author fullname="Jeff Hilgeman" initials="J." surname="Hilgeman">
<organization>Apertus Technologies, Inc.</organization>

<address>
<postal>
<street>7275 Flying Cloud Dr.</street>
<city>Eden Prairie</city>
<region>MN</region>
<code>55344</code>
<country>US</country>
</postal>

<phone>+1 612 828 0668</phone>
<email>jeffh@apertus.com</email>
</address>
</author>

<author fullname="Shannon D. Nix" initials="S." surname="Nix">
<organization>Metaplex, Inc.</organization>

<address>
<postal>
<street>7412 Wingfoot Dr.</street>
<city>Raleigh</city>
<region>NC</region>
<code>27615</code>
<country>US</country>
</postal>

<phone>+1 919 878 0811</phone>
<email>snix@metaplex.com</email>
</address>
</author>

<author fullname="Alan Bartky" initials="A." surname="Bartky">
<organization>Sync Research, Inc.</organization>

<address>
<postal>
<street>7 Studebaker</street>
<city>Irvine</city>
<region>CA</region>
<code>92718</code>
<country>US</country>
</postal>

<phone>+1 714 588 2070</phone>
<email>alan@sync.com</email>
</address>
</author>

<author fullname="Wayne Clark" initials="W." surname="Clark">
<organization>cisco Systems, Inc.</organization>

<address>
<postal>
<street>3100 Smoketree Ct.</street>
<street>Suite 1000</street>
<city>Raleigh</city>
<region>NC</region>
<code>27604</code>
<country>US</country>
</postal>

<phone>+1 919 878 6958</phone>
<email>wclark@cisco.com</email>
</address>
</author>

<date year="1995" month="January" />

<abstract>
<t>This specification defines an extension to the Management Information Base (MIB) for use with SNMP-based network management.  In particular, it defines objects for managing the configuration, monitoring and control of data link controls in an SNA environment. This draft identifies managed objects for SNA Synchronous Data Link Control (SDLC) links only.</t>
</abstract>
</front>

<seriesInfo value="1747" name="RFC" />
</reference>


<reference target2="reference.RFC.1748.xml" anchor="RFC1748">
<front>
<title>IEEE 802.5 MIB using SMIv2</title>
<author fullname="Keith McCloghrie" initials="K." surname="McCloghrie">
<organization>cisco Systems, Inc.</organization>

<address>
<postal>
<street>170 West Tasman Drive</street>
<city>San Jose</city>
<region>CA</region>
<code>95134-1706</code>
<country>US</country>
</postal>

<phone>+1 408 526 5260</phone>
<email>kzm@cisco.com</email>
</address>
</author>

<author fullname="Eric B. Decker" initials="E." surname="Decker">
<organization>cisco Systems, Inc.</organization>

<address>
<postal>
<street>1525 O'Brien Dr.</street>
<city>Menlo Park</city>
<region>CA</region>
<code>94025</code>
<country>US</country>
</postal>

<phone>+1 415 688 8241</phone>
<email>cire@cisco.com</email>
</address>
</author>

<date year="1994" month="December" />
</front>

<seriesInfo value="1748" name="RFC" />
</reference>


<reference target2="reference.RFC.1749.xml" anchor="RFC1749">
<front>
<title>IEEE 802.5 Station Source Routing MIB using SMIv2</title>
<author fullname="Keith McCloghrie" initials="K." surname="McCloghrie">
<organization>cisco Systems, Inc.</organization>

<address>
<postal>
<street>170 West Tasman Drive</street>
<city>San Jose</city>
<region>CA</region>
<code>95134-1706</code>
<country>US</country>
</postal>

<phone>+1 408 526 5260</phone>
<email>kzm@cisco.com</email>
</address>
</author>

<author fullname="Fred Baker" initials="F." surname="Baker">
<organization>cisco Systems, Inc.</organization>

<address>
<postal>
<street>519 Lado Drive</street>
<city>Santa Barbara</city>
<region>CA</region>
<code>93111</code>
<country>US</country>
</postal>

<phone>+1 805 681 0115</phone>
<email>fred@cisco.com</email>
</address>
</author>

<author fullname="Eric B. Decker" initials="E." surname="Decker">
<organization>cisco Systems, Inc.</organization>

<address>
<postal>
<street>1525 O'Brien Dr.</street>
<city>Menlo Park</city>
<region>CA</region>
<code>94025</code>
<country>US</country>
</postal>

<phone>+1 415 688 8241</phone>
<email>cire@cisco.com</email>
</address>
</author>

<date year="1994" month="December" />
</front>

<seriesInfo value="1749" name="RFC" />
</reference>


<reference target2="reference.RFC.1750.xml" anchor="RFC1750">
<front>
<title>Randomness Recommendations for Security</title>
<author fullname="Donald E. Eastlake 3rd" initials="D.E." surname="Eastlake">
<organization>Digital Equipment Corporation</organization>

<address>
<postal>
<street>550 King Street</street>
<street>LKG2-1/BB3</street>
<city>Littleton</city>
<region>MA</region>
<code>01460</code>
<country>US</country>
</postal>

<phone>+1 508 486 6577</phone>
<email>dee@lkg.dec.com</email>
</address>
</author>

<author fullname="Stephen D. Crocker" initials="S." surname="Crocker">
<organization>CyberCash Inc.</organization>

<address>
<postal>
<street>2086 Hunters Crest Way</street>
<city>Vienna</city>
<region>VA</region>
<code>22181</code>
<country>US</country>
</postal>

<phone>+1 703 620 1222</phone>
<facsimile>+1 703 391 2651</facsimile>
<email>crocker@cybercash.com</email>
</address>
</author>

<author fullname="Jeffrey I. Schiller" initials="J.I." surname="Schiller">
<organization>Massachusetts Institute of Technology</organization>

<address>
<postal>
<street>77 Massachusetts Avenue</street>
<city>Cambridge</city>
<region>MA</region>
<code>02139</code>
<country>US</country>
</postal>

<phone>+1 617 253 0161</phone>
<email>jis@mit.edu</email>
</address>
</author>

<date year="1994" month="December" />

<abstract>
<t>Security systems today are built on increasingly strong cryptographic algorithms that foil pattern analysis attempts. However, the security of these systems is dependent on generating secret quantities for passwords, cryptographic keys, and similar quantities.  The use of pseudo-random processes to generate secret quantities can result in pseudo-security.  The sophisticated attacker of these security systems may find it easier to reproduce the environment that produced the secret quantities, searching the resulting small set of possibilities, than to locate the quantities in the whole of the number space.</t>

<t>Choosing random quantities to foil a resourceful and motivated adversary is surprisingly difficult.  This paper points out many pitfalls in using traditional pseudo-random number generation techniques for choosing such quantities.  It recommends the use of truly random hardware techniques and shows that the existing hardware on many systems can be used for this purpose.  It provides suggestions to ameliorate the problem when a hardware solution is not available.  And it gives examples of how large such quantities need to be for some particular applications.</t>
</abstract>
</front>

<seriesInfo value="1750" name="RFC" />
</reference>


<reference target2="reference.RFC.1751.xml" anchor="RFC1751">
<front>
<title abbrev="Human-Readable 128-bit Keys">A Convention for Human-Readable 128-bit Keys</title>
<author fullname="Daniel L. McDonald" initials="D.L." surname="McDonald">
<organization>United States Naval Research Laboratory, Code 5544</organization>

<address>
<postal>
<street>4555 Overlook Ave. SW</street>
<city>Washington</city>
<region>DC</region>
<code>20375</code>
<country>US</country>
</postal>

<phone>+1 202 404 7122</phone>
<email>danmcd@itd.nrl.navy.mil</email>
</address>
</author>

<date year="1994" month="December" />
</front>

<seriesInfo value="1751" name="RFC" />
</reference>


<reference target2="reference.RFC.1752.xml" anchor="RFC1752">
<front>
<title abbrev="Recommendation for IPng">The Recommendation for the IP Next Generation Protocol</title>
<author fullname="Scott Bradner" initials="S." surname="Bradner">
<organization>Harvard University</organization>

<address>
<postal>
<street>10 Ware St.</street>
<city>Cambridge</city>
<region>MA</region>
<code>02138</code>
<country>US</country>
</postal>

<phone>+1 617 495 3864</phone>
<email>sob@harvard.edu</email>
</address>
</author>

<author fullname="Allison Mankin" initials="A." surname="Mankin">
<organization>USC/Information Sciences Institute</organization>

<address>
<postal>
<street>4350 North Fairfax Drive</street>
<street>Suite 400</street>
<city>Arlington</city>
<region>VA</region>
<code>22303</code>
<country>US</country>
</postal>

<phone>+1 703 807 0132</phone>
<email>mankin@isi.edu</email>
</address>
</author>

<date year="1995" month="January" />

<abstract>
<t>This document presents the recommendation of the IPng Area Directors on what should be used to replace the current version of the Internet Protocol.  This recommendation was accepted by the Internet Engineering Steering Group (IESG).</t>
</abstract>
</front>

<seriesInfo value="1752" name="RFC" />
</reference>


<reference target2="reference.RFC.1753.xml" anchor="RFC1753">
<front>
<title abbrev="Nimrod Technical Requirements for IPng">IPng Technical Requirements Of the Nimrod Routing and Addressing Architecture</title>
<author fullname="J. Noel Chiappa" initials="J." surname="Chiappa">
<organization />

<address>
<phone>+1 804 898 8183</phone>
<email>jnc@lcs.mit.edu</email>
</address>
</author>

<date year="1994" month="December" />

<abstract>
<t>This document was submitted to the IETF IPng area in response to RFC 1550.  Publication of this document does not imply acceptance by the IPng area of any ideas expressed within.  Comments should be submitted to the big-internet@munnari.oz.au mailing list.</t>

<t>This document presents the requirements that the Nimrod routing and addressing architecture has upon the internetwork layer protocol. To be most useful to Nimrod, any protocol selected as the IPng should satisfy these requirements. Also presented is some background information, consisting of i) information about architectural and design principles which might apply to the design of a new internetworking layer, and ii) some details of the logic and reasoning behind particular requirements.</t>
</abstract>
</front>

<seriesInfo value="1753" name="RFC" />
</reference>


<reference target2="reference.RFC.1754.xml" anchor="RFC1754">
<front>
<title abbrev="IPATM WG ATM Forum Recommendations V1">IP over ATM Working Group's Recommendations for the ATM Forum's Multiprotocol BOF Version 1</title>
<author fullname="Mark Laubach" initials="M." surname="Laubach">
<organization>Com21, Inc.</organization>

<address>
<postal>
<street>2113 Landings Drive</street>
<city>Mountain View</city>
<region>CA</region>
<code>94043</code>
<country>US</country>
</postal>

<phone>+1 415 254 5882</phone>
<facsimile>+1 415 254 5883</facsimile>
<email>laubach@com21.com</email>
</address>
</author>

<author fullname="Drew Perkins" initials="D." surname="Perkins">
<organization>FORE Systems, Inc.</organization>

<address>
<postal>
<street>174 Thornhill Road</street>
<city>Warrendale</city>
<region>PA</region>
<code>15086</code>
<country>US</country>
</postal>

<phone>+1 412 772 6527</phone>
<facsimile>+1 412 772 6500</facsimile>
<email>ddp@fore.com</email>
</address>
</author>

<date year="1995" month="January" />

<abstract>
<t>This document represents an initial list of requirements submitted to the ATM Forum's Multiprotocol BOF for the operation of IP over ATM networks as determined by the IETF IP over ATM Working Group and other working groups. This RFC is issued for the benefit of community members.  The information contained in this document is accurate as of the date of publication, but is subject to change.  Subsequent RFCs will reflect such changes.</t>

<t>The content of this memo was submitted by the IETF Liaison to the ATM Forum as contribution number 94-0954 in the ATM Forum's documentation process on 14 September 1994.</t>
</abstract>
</front>

<seriesInfo value="1754" name="RFC" />
</reference>


<reference target2="reference.RFC.1755.xml" anchor="RFC1755">
<front>
<title>ATM Signaling Support for IP over ATM</title>
<author fullname="Maryann Perez Maher" initials="M." surname="Maher">
<organization>USC/Information Sciences Institute</organization>

<address>
<postal>
<street>4350 N. Fairfax Drive</street>
<street>Suite 400</street>
<city>Arlington</city>
<region>VA</region>
<code>22203</code>
<country>US</country>
</postal>

<phone>+1 703 807 0132</phone>
<email>perez@isi.edu</email>
</address>
</author>

<author fullname="Fong-Ching Liaw" initials="F." surname="Liaw">
<organization>FORE Systems, Inc.</organization>

<address>
<postal>
<street>174 Thorn Hill Road</street>
<city>Warrendale</city>
<region>PA</region>
<code>15086-7535</code>
<country>US</country>
</postal>

<phone>+1 412 772 8668</phone>
<email>fong@fore.com</email>
</address>
</author>

<author fullname="Allison Mankin" initials="A." surname="Mankin">
<organization>USC/Information Sciences Institute</organization>

<address>
<postal>
<street>4350 N. Fairfax Drive</street>
<street>Suite 400</street>
<city>Arlington</city>
<region>VA</region>
<code>22203</code>
<country>US</country>
</postal>

<phone>+1 703 807 0132</phone>
<email>mankin@isi.edu</email>
</address>
</author>

<author fullname="Eric Hoffman" initials="E." surname="Hoffman">
<organization>USC/Information Sciences Institute</organization>

<address>
<postal>
<street>4350 N. Fairfax Drive</street>
<street>Suite 400</street>
<city>Arlington</city>
<region>VA</region>
<code>22203</code>
<country>US</country>
</postal>

<phone>+1 703 807 0132</phone>
<email>hoffman@isi.edu</email>
</address>
</author>

<author fullname="Dan Grossman" initials="D." surname="Grossman">
<organization>Motorola Codex</organization>

<address>
<phone>+1 617 821 7333</phone>
<email>dan@merlin.dev.cdx.mot.com</email>
</address>
</author>

<author fullname="Andrew G. Malis" initials="A." surname="Malis">
<organization>Ascom Timeplex, Inc., Advanced Products Business Unit</organization>

<address>
<postal>
<street>289 Great Road</street>
<street>Suite 205</street>
<city>Acton</city>
<region>MA</region>
<code>01720</code>
<country>US</country>
</postal>

<phone>+1 508 266 4522</phone>
<email>malis@maelstrom.timeplex.com</email>
</address>
</author>

<date year="1995" month="February" />

<abstract>
<t>This memo describes the ATM call control signaling exchanges needed to support Classical IP over ATM implementations as described in RFC 1577. ATM endpoints will incorporate ATM signaling services as specified in the ATM Forum User-Network Interface (UNI) Specification Version 3.1. IP over ATM implementations utilize the services of local ATM signaling entities to establish and release ATM connections. This memo should be used to define the support required by IP over ATM implementations from their local ATM signaling entities.</t>

<t>This document is an implementors guide intended to foster interoperability among RFC 1577, RFC 1483, and UNI ATM signaling.  It applies to IP hosts and routers which are also ATM endsystems and assumes ATM networks that completely implement the ATM Forum UNI Specification Version 3.1. Unless explicitly stated, no distinction is made between the Private and Public UNI.</t>

<t>UNI 3.1 is considered an erratum to the UNI 3.0 specification. It has been produced by the ATM Forum, largely for reasons of alignment with Recommendation Q.2931. Although UNI 3.1 is based on UNI 3.0 there are several changes that make the two versions incompatible. A description of how to support IP over ATM using UNI 3.0 is found in Appendix B.</t>
</abstract>
</front>

<seriesInfo value="1755" name="RFC" />
</reference>


<reference target2="reference.RFC.1756.xml" anchor="RFC1756">
<front>
<title abbrev="Remote Write Protocol">Remote Write Protocol - Version 1.0</title>
<author fullname="Timo J. Rinne" initials="T." surname="Rinne">
<organization>Helsinki University of Technology,  Cirion oy</organization>

<address>
<postal>
<street>PO-BOX 250</street>
<city>Helsinki</city>
<region />
<code>FIN-00121</code>
<country>FI</country>
</postal>

<email>Timo.Rinne@hut.fi</email>
</address>
</author>

<date year="1995" month="January" />
</front>

<seriesInfo value="1756" name="RFC" />
</reference>


<reference target2="reference.RFC.1757.xml" anchor="RFC1757">
<front>
<title abbrev="Remote Network Monitoring MIB">Remote Network Monitoring Management Information Base</title>
<author fullname="Steven Waldbusser" initials="S." surname="Waldbusser">
<organization>Carnegie Mellon University</organization>

<address>
<postal>
<street>5000 Forbes Ave.</street>
<city>Pittsburgh</city>
<region>PA</region>
<code>15213</code>
<country>US</country>
</postal>

<email>waldbusser@cmu.edu</email>
</address>
</author>

<date year="1995" month="February" />

<abstract>
<t>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 remote network monitoring devices.</t>
</abstract>
</front>

<seriesInfo value="1757" name="RFC" />
</reference>


<reference target2="reference.RFC.1758.xml" anchor="RFC1758">
<front>
<title abbrev="NADF Standing Documents">NADF Standing Documents: A Brief Overview</title>
<author fullname="Theodore H. Myer" initials="T.H." surname="Myer">
<organization>North American Directory Forum</organization>

<address>
<postal>
<street>2721 N Street NW</street>
<city>Washington</city>
<region>DC</region>
<code>20007</code>
<country>US</country>
</postal>

<phone>+1 202 342 2727</phone>
<email>0004454742@mcimail.com</email>
</address>
</author>

<date year="1995" month="February" />
</front>

<seriesInfo value="1758" name="RFC" />
</reference>


<reference target2="reference.RFC.1759.xml" anchor="RFC1759">
<front>
<title>Printer MIB</title>
<author fullname="Ronald L. Smith" initials="R." surname="Smith">
<organization>Texas Instruments</organization>

<address>
<phone>+1 817 774 6151</phone>
<email>rlsmith@nb.ppd.ti.com</email>
</address>
</author>

<author fullname="F. D. Wright" initials="F." surname="Wright">
<organization>Lexmark International</organization>

<address>
<phone>+1 606 232 4808</phone>
<email>don@lexmark.com</email>
</address>
</author>

<author fullname="Thomas N. Hastings" initials="T." surname="Hastings">
<organization>Xerox Corporation</organization>

<address>
<phone>+1 310 333 6413</phone>
<email>hastings@cp10.es.xerox.com</email>
</address>
</author>

<author fullname="Stephen N. Zilles" initials="S." surname="Zilles">
<organization>Adobe Systems, Inc.</organization>

<address>
<phone>+1 415 962 4766</phone>
<email>szilles@mv.us.adobe.com</email>
</address>
</author>

<author fullname="Joel Gyllenskog" initials="J." surname="Gyllenskog">
<organization>Hewlett-Packard Company</organization>

<address>
<phone>+1 208 396 4515</phone>
<email>jgyllens@hpdmd48.boi.hp.com</email>
</address>
</author>

<date year="1995" month="March" />
</front>

<seriesInfo value="1759" name="RFC" />
</reference>


<reference target2="reference.RFC.1760.xml" anchor="RFC1760">
<front>
<title>The S/KEY One-Time Password System</title>
<author fullname="Neil Haller" initials="N." surname="Haller">
<organization>Bellcore</organization>

<address>
<postal>
<street>445 South Street</street>
<street>MRE 2Q-280</street>
<city>Morristown</city>
<region>NJ</region>
<code>07960-6438</code>
<country>US</country>
</postal>

<phone>+1 201 829 4478</phone>
<facsimile>+1 201 829 2504</facsimile>
<email>nmh@bellcore.com</email>
</address>
</author>

<date year="1995" month="February" />

<abstract>
<t>This document describes the S/KEY* One-Time Password system as released for public use by Bellcore and as described in reference.  A reference implementation and documentation are available by anonymous ftp from ftp.bellcore.com in the directories pub/nmh/...</t>
</abstract>
</front>

<seriesInfo value="1760" name="RFC" />
</reference>


<reference target2="reference.RFC.1761.xml" anchor="RFC1761">
<front>
<title abbrev="Snoop Packet Capture File Format">Snoop Version 2 Packet Capture File Format</title>
<author fullname="Brent Callaghan" initials="B." surname="Callaghan">
<organization>Sun Microsystems, Inc.</organization>

<address>
<postal>
<street>2550 Garcia Avenue</street>
<street>Mailstop UMTV05-44</street>
<city>Mountain View</city>
<region>CA</region>
<code>94043-1100</code>
<country>US</country>
</postal>

<phone>+1 415 336 1051</phone>
<email>brent.callaghan@eng.sun.com</email>
</address>
</author>

<author fullname="Robert E. Gilligan" initials="R.E." surname="Gilligan">
<organization>Sun Microsystems, Inc.</organization>

<address>
<postal>
<street>2550 Garcia Avenue</street>
<street>Mailstop UMTV05-44</street>
<city>Mountain View</city>
<region>CA</region>
<code>94043-1100</code>
<country>US</country>
</postal>

<phone>+1 415 336 1012</phone>
<email>bob.gilligan@eng.sun.com</email>
</address>
</author>

<date year="1995" month="February" />

<abstract>
<t>This paper describes the file format used by "snoop", a packet monitoring and capture program developed by Sun.  This paper is provided so that people can write compatible programs to generate and interpret snoop packet capture files.</t>
</abstract>
</front>

<seriesInfo value="1761" name="RFC" />
</reference>


<reference target2="reference.RFC.1762.xml" anchor="RFC1762">
<front>
<title abbrev="PPP DNCP">The PPP DECnet Phase IV Control Protocol (DNCP)</title>
<author fullname="Steven J. Senum" initials="S." surname="Senum">
<organization>DigiBoard</organization>

<address>
<postal>
<street>6400 Flying Cloud Drive</street>
<city>Eden Prairie</city>
<region>MN</region>
<code>55344</code>
<country>US</country>
</postal>

<phone>+1 612 943 9020</phone>
<email>sjs@digibd.com</email>
</address>
</author>

<date year="1995" month="March" />

<abstract>
<t>The Point-to-Point Protocol (PPP)provides a standard method of encapsulating Network Layer protocol information over point-to-point links.  PPP also defines an extensible Link Control Protocol, and proposes a family of Network Control Protocols (NCPs) for establishing and configuring different network-layer protocols.</t>

<t>This document defines the NCP for establishing and configuring Digital's DNA Phase IV Routing protocol (DECnet Phase IV) over PPP. This document applies only to DNA Phase IV Routing messages (both data and control), and not to other DNA Phase IV protocols (MOP, LAT, etc).</t>
</abstract>
</front>

<seriesInfo value="1762" name="RFC" />
</reference>


<reference target2="reference.RFC.1763.xml" anchor="RFC1763">
<front>
<title abbrev="PPP BVCP">The PPP Banyan Vines Control Protocol (BVCP)</title>
<author fullname="Steven J. Senum" initials="S." surname="Senum">
<organization>DigiBoard</organization>

<address>
<postal>
<street>6400 Flying Cloud Drive</street>
<city>Eden Prairie</city>
<region>MN</region>
<code>55344</code>
<country>US</country>
</postal>

<phone>+1 612 943 9020</phone>
<email>sjs@digibd.com</email>
</address>
</author>

<date year="1995" month="March" />

<abstract>
<t>The Point-to-Point Protocol (PPP)provides a standard method for transporting multi-protocol datagrams over point-to-point links.  PPP defines an extensible Link Control Protocol, and proposes a family of Network Control Protocols for establishing and configuring different network-layer protocols.</t>

<t>This document defines the Network Control Protocol for establishing and configuring the Banyan VINES protocol over PPP.</t>
</abstract>
</front>

<seriesInfo value="1763" name="RFC" />
</reference>


<reference target2="reference.RFC.1764.xml" anchor="RFC1764">
<front>
<title abbrev="PPP XNSCP">The PPP XNS IDP Control Protocol (XNSCP)</title>
<author fullname="Steven J. Senum" initials="S." surname="Senum">
<organization>DigiBoard</organization>

<address>
<postal>
<street>6400 Flying Cloud Drive</street>
<city>Eden Prairie</city>
<region>MN</region>
<code>55344</code>
<country>US</country>
</postal>

<phone>+1 612 943 9020</phone>
<email>sjs@digibd.com</email>
</address>
</author>

<date year="1995" month="March" />

<abstract>
<t>The Point-to-Point Protocol (PPP)provides a standard method for transporting multi-protocol datagrams over point-to-point links.  PPP defines an extensible Link Control Protocol, and proposes a family of Network Control Protocols for establishing and configuring different network-layer protocols.</t>

<t>This document defines the Network Control Protocol for establishing and configuring the Xerox Network Systems (XNS) Internet Datagram Protocol (IDP) over PPP.</t>
</abstract>
</front>

<seriesInfo value="1764" name="RFC" />
</reference>


<reference target2="reference.RFC.1765.xml" anchor="RFC1765">
<front>
<title>OSPF Database Overflow</title>
<author fullname="John Moy" initials="J." surname="Moy">
<organization>Cascade Communications Corp.</organization>

<address>
<postal>
<street>5 Carlisle Road</street>
<city>Westford</city>
<region>MA</region>
<code>01886</code>
<country>US</country>
</postal>

<phone>+1 508 692 2600 x394</phone>
<facsimile>+1 508 692 9214</facsimile>
<email>jmoy@casc.com</email>
</address>
</author>

<date year="1995" month="March" />

<abstract>
<t>Proper operation of the OSPF protocol requires that all OSPF routers maintain an identical copy of the OSPF link-state database.  However, when the size of the link-state database becomes very large, some routers may be unable to keep the entire database due to resource shortages; we term this "database overflow". When database overflow is anticipated, the routers with limited resources can be accommodated by configuring OSPF stub areas and NSSAs. This memo details a way of gracefully handling unanticipated database overflows.</t>

<t>This memo is a product of the OSPF Working Group. Please send comments to ospf@gated.cornell.edu.</t>
</abstract>
</front>

<seriesInfo value="1765" name="RFC" />
</reference>


<reference target2="reference.RFC.1766.xml" anchor="RFC1766">
<front>
<title abbrev="Language Tag">Tags for the Identification of Languages</title>
<author fullname="Harald Tveit Alvestrand" initials="H." surname="Alvestrand">
<organization>UNINETT</organization>

<address>
<postal>
<street>Pb. 6883 Elgeseter</street>
<city>Trondheim</city>
<region />
<code>N-7002</code>
<country>NO</country>
</postal>

<phone>+47 73 597094</phone>
<email>Harald.T.Alvestrand@uninett.no</email>
</address>
</author>

<date year="1995" month="March" />

<abstract>
<t>This document describes a language tag for use in cases where it is desired to indicate the language used in an information object.</t>

<t>It also defines a Content-language: header, for use in the case where one desires to indicate the language of something that has RFC-822-like headers, like MIME body parts or Web documents, and a new parameter to the Multipart/Alternative type, to aid in the usage of the Content-Language: header.</t>
</abstract>
</front>

<seriesInfo value="1766" name="RFC" />
</reference>


<reference target2="reference.RFC.1767.xml" anchor="RFC1767">
<front>
<title abbrev="EDI in MIME">MIME Encapsulation of EDI Objects</title>
<author fullname="David H. Crocker" initials="D." surname="Crocker">
<organization>Brandenburg Consulting</organization>

<address>
<postal>
<street>675 Spruce Dr.</street>
<city>Sunnyvale</city>
<region>CA</region>
<code>94086</code>
<country>US</country>
</postal>

<phone>+1 408 246 8253</phone>
<facsimile>+1 408 249 6205</facsimile>
<email>dcrocker@mordor.stanford.edu</email>
</address>
</author>

<date year="1995" month="March" />
</front>

<seriesInfo value="1767" name="RFC" />
</reference>


<reference target2="reference.RFC.1768.xml" anchor="RFC1768">
<front>
<title abbrev="CLNP Multicasting">Host Group Extensions for CLNP Multicasting</title>
<author fullname="Dave Marlow" initials="D." surname="Marlow">
<organization>NSWC-DD</organization>

<address>
<postal>
<street>Code B35</street>
<city>Dahlgren</city>
<region>VA</region>
<code>22448</code>
<country>US</country>
</postal>

<phone>+1 703 663 1675</phone>
<email>dmarlow@relay.nswc.navy.mil</email>
</address>
</author>

<date year="1995" month="March" />

<abstract>
<t>This memo documents work performed in the TUBA (TCP/UDP over Bigger Addresses) working group of IPng area prior to the July 1994 decision to utilize SIPP-16 as the basis for IPng.  The TUBA group worked on extending the Internet Protocol suite by the use of ISO 8473 (CLNP) and its related routing protocols.  This memo describes multicast extensions to CLNP and its related routing protocols for Internet multicast use.  Publication of this memo does not imply acceptance by any IETF Working Group for the ideas expressed within.</t>

<t>This memo provides a specification for multicast extensions to the CLNP protocol similar to those provided to IP by RFC1112.  These extensions are intended to provide the mechanisms needed by a host for multicasting in a CLNP based Internet.  This memo covers addressing extensions to the CLNP addressing structure, extensions to the CLNP protocol and extensions to the ES-IS protocol.  An appendix discusses the differences between IP multicast and the CLNP multicast approach provided in this memo.</t>
</abstract>
</front>

<seriesInfo value="1768" name="RFC" />
</reference>


<reference target2="reference.RFC.1769.xml" anchor="RFC1769">
<front>
<title abbrev="SNTP">Simple Network Time Protocol (SNTP)</title>
<author fullname="David L. Mills" initials="D." surname="Mills">
<organization>University of Delaware, Electrical Engineering Department</organization>

<address>
<postal>
<street />
<city>Newark</city>
<region>DE</region>
<code>19716</code>
<country>US</country>
</postal>

<phone>+1 302 831 8247</phone>
<email>mills@udel.edu</email>
</address>
</author>

<date year="1995" month="March" />

<abstract>
<t>This memorandum describes the Simple Network Time Protocol (SNTP), which is an adaptation of the Network Time Protocol (NTP) used to synchronize computer clocks in the Internet. SNTP can be used when the ultimate performance of the full NTP implementation described in RFC-1305 is not needed or justified. It can operate in both unicast modes (point to point) and broadcast modes (point to multipoint). It can also operate in IP multicast mode where this service is available. SNTP involves no change to the current or previous NTP specification versions or known implementations, but rather a clarification of certain design features of NTP which allow operation in a simple, stateless remote-procedure call (RPC) mode with accuracy and reliability expectations similar to the UDP/TIME protocol described in RFC-868.</t>

<t>This memorandum obsoletes RFC-1361 of the same title. Its purpose is to explain the protocol model for operation in broadcast mode, to provide additional clarification in some places and to correct a few typographical errors. A working knowledge of the NTP Version 3 specification RFC-1305 is not required for an implementation of SNTP. Distribution of this memorandum is unlimited.</t>
</abstract>
</front>

<seriesInfo value="1769" name="RFC" />
</reference>


<reference target2="reference.RFC.1770.xml" anchor="RFC1770">
<front>
<title abbrev="Selective Directed Broadcast Protocol">IPv4 Option for Sender Directed Multi-Destination Delivery</title>
<author fullname="Charles Graff" initials="C." surname="Graff">
<organization>US Army Communications Electronics Command (CECOM)</organization>

<address>
<postal>
<street>AMSEL-RD-ST-LA-L</street>
<city>Fort Monmouth</city>
<region>NJ</region>
<code>07703</code>
<country>US</country>
</postal>

<phone>+1 908 544 3264</phone>
<facsimile>+1 908 544 2150</facsimile>
<email>bud@fotlan5.fotlan.army.mil</email>
</address>
</author>

<date year="1995" month="March" />

<abstract>
<t>This memo defines an IPv4 option to provide a sender directed multi-destination delivery mechanism called Selective Directed Broadcast Mode (SDBM).  The SDBM provides unreliable UDP delivery to a set of IP addresses included in the option field of an IPv4 datagram.  Data reliability if required will be provided by the application layer. This approach was developed to support sender directed multi-destination delivery to sparsely populated groups with no additional control traffic.  This approach will find application in the extremely bandwidth constrained tactical military environment, as well as in some commercial applications requiring sender control of data delivery.</t>
</abstract>
</front>

<seriesInfo value="1770" name="RFC" />
</reference>


<reference target2="reference.RFC.1771.xml" anchor="RFC1771">
<front>
<title abbrev="BGP-4">A Border Gateway Protocol 4 (BGP-4)</title>
<author fullname="Yakov Rekhter" initials="Y." surname="Rekhter">
<organization>IBM Corporation, T.J. Watson Research Center</organization>

<address>
<postal>
<street>P.O. Box 704</street>
<street>Office H3-D40</street>
<city>Yorktown Heights</city>
<region>NY</region>
<code>10598</code>
<country>US</country>
</postal>

<phone>+1 914 784 7361</phone>
<email>yakov@watson.ibm.com</email>
</address>
</author>

<author fullname="Tony Li" initials="T." surname="Li">
<organization>cisco Systems, Inc.</organization>

<address>
<postal>
<street>170 W. Tasman Dr.</street>
<city>San Jose</city>
<region>CA</region>
<code>95134</code>
<country>US</country>
</postal>

<email>tli@cisco.com</email>
</address>
</author>

<date year="1995" month="March" />

<abstract>
<t>This document, together with its companion document, "Application of the Border Gateway Protocol in the Internet", define an inter-autonomous system routing protocol for the Internet.</t>
</abstract>
</front>

<seriesInfo value="1771" name="RFC" />
</reference>


<reference target2="reference.RFC.1772.xml" anchor="RFC1772">
<front>
<title abbrev="BGP-4 Application">Application of the Border Gateway Protocol in the Internet</title>
<author fullname="Yakov Rekhter" initials="Y." surname="Rekhter">
<organization>IBM Corporation, T.J. Watson Research Center</organization>

<address>
<postal>
<street>P.O. Box 704</street>
<street>Office H3-D40</street>
<city>Yorktown Heights</city>
<region>NY</region>
<code>10598</code>
<country>US</country>
</postal>

<phone>+1 914 784 7361</phone>
<email>yakov@watson.ibm.com</email>
</address>
</author>

<author fullname="Phill Gross" initials="P." surname="Gross">
<organization>MCI Data Services Division</organization>

<address>
<postal>
<street>2100 Reston Parkway</street>
<street>Room 6001</street>
<city>Reston</city>
<region>VA</region>
<code>22091</code>
<country>US</country>
</postal>

<phone>+1 703 715 7432</phone>
<email>0006423401@mcimail.com</email>
</address>
</author>

<date year="1995" month="March" />

<abstract>
<t>This document, together with its companion document, "A Border Gateway Protocol 4 (BGP-4)", define an inter-autonomous system routing protocol for the Internet.  "A Border Gateway Protocol 4 (BGP-4)" defines the BGP protocol specification, and this document describes the usage of the BGP in the Internet.</t>

<t>Information about the progress of BGP can be monitored and/or reported on the BGP mailing list (bgp@ans.net).</t>
</abstract>
</front>

<seriesInfo value="1772" name="RFC" />
</reference>


<reference target2="reference.RFC.1773.xml" anchor="RFC1773">
<front>
<title>Experience with the BGP-4 protocol</title>
<author fullname="Paul Traina" initials="P." surname="Traina">
<organization>cisco Systems, Inc.</organization>

<address>
<postal>
<street>170 W. Tasman Dr.</street>
<city>San Jose</city>
<region>CA</region>
<code>95134</code>
<country>US</country>
</postal>

<email>pst@cisco.com</email>
</address>
</author>

<date year="1995" month="March" />

<abstract>
<t></t>
</abstract>
</front>

<seriesInfo value="1773" name="RFC" />
</reference>


<reference target2="reference.RFC.1774.xml" anchor="RFC1774">
<front>
<title>BGP-4 Protocol Analysis</title>
<author fullname="Paul Traina" initials="P." surname="Traina">
<organization>cisco Systems, Inc.</organization>

<address>
<postal>
<street>170 W. Tasman Dr.</street>
<city>San Jose</city>
<region>CA</region>
<code>95134</code>
<country>US</country>
</postal>

<email>pst@cisco.com</email>
</address>
</author>

<date year="1995" month="March" />

<abstract>
<t></t>
</abstract>
</front>

<seriesInfo value="1774" name="RFC" />
</reference>


<reference target2="reference.RFC.1775.xml" anchor="RFC1775">
<front>
<title>To Be "On" the Internet</title>
<author fullname="David H. Crocker" initials="D." surname="Crocker">
<organization>Brandenburg Consulting</organization>

<address>
<postal>
<street>675 Spruce Dr.</street>
<city>Sunnyvale</city>
<region>CA</region>
<code>94086</code>
<country>US</country>
</postal>

<phone>+1 408 246 8253</phone>
<facsimile>+1 408 249 6205</facsimile>
<email>dcrocker@mordor.stanford.edu</email>
</address>
</author>

<date year="1995" month="March" />

<abstract>
<t>The Internet permits different levels of access for consumers and providers of service.  The nature of those differences is quite important in the capabilities They afford.  Hence, it is appropriate to provide terminology that distinguishes among the range, so that the Internet community can gain some clarity when distinguishing whether a user (or an organization) is "on" the Internet.  This document suggests four terms, for distinguishing the major classes of access.</t>
</abstract>
</front>

<seriesInfo value="1775" name="RFC" />
</reference>


<reference target2="reference.RFC.1776.xml" anchor="RFC1776">
<front>
<title>The Address is the Message</title>
<author fullname="Steve Crocker" initials="S." surname="Crocker">
<organization>CyberCash, Inc.</organization>

<address>
<postal>
<street>2086 Hunters Crest Way</street>
<city>Vienna</city>
<region>VA</region>
<code>22181</code>
<country>US</country>
</postal>

<phone>+1 703 620 1222</phone>
<email>crocker@cybercash.com</email>
</address>
</author>

<date year="1995" day="1" month="April" />

<abstract>
<t></t>
</abstract>
</front>

<seriesInfo value="1776" name="RFC" />
</reference>


<reference target2="reference.RFC.1777.xml" anchor="RFC1777">
<front>
<title abbrev="LDAP">Lightweight Directory Access Protocol</title>
<author fullname="Wengyik Yeong" initials="W." surname="Yeong">
<organization>PSI Inc.</organization>

<address>
<postal>
<street>510 Huntmar Park Drive</street>
<city>Herndon</city>
<region>VA</region>
<code>22070</code>
<country>US</country>
</postal>

<phone>+1 703 450 8001</phone>
<email>yeongw@psilink.com</email>
</address>
</author>

<author fullname="Tim Howes" initials="T." surname="Howes">
<organization>University of Michigan, ITD Research Systems</organization>

<address>
<postal>
<street>535 W William St.</street>
<city>Ann Arbor</city>
<region>MI</region>
<code>48103-4943</code>
<country>US</country>
</postal>

<phone>+1 313 747 4454</phone>
<email>tim@umich.edu</email>
</address>
</author>

<author fullname="Steve Kille" initials="S." surname="Kille">
<organization>ISODE Consortium</organization>

<address>
<postal>
<street>POB 505</street>
<city>London</city>
<region>England</region>
<code>SW11 1DX</code>
<country>UK</country>
</postal>

<phone>+44 71 2234062</phone>
<email>S.Kille@isode.com</email>
</address>
</author>

<date year="1995" month="March" />

<abstract>
<t>The protocol described in this document is designed to provide access to the X.500 Directory while not incurring the resource requirements of the Directory Access Protocol (DAP). This protocol is specifically targeted at simple management applications and browser applications that provide simple read/write interactive access to the X.500 Directory, and is intended to be a complement to the DAP itself.</t>

<t>Key aspects of LDAP are:</t>

<t>- Protocol elements are carried directly over TCP or other transport, bypassing much of the session/presentation overhead.</t>

<t>- Many protocol data elements are encoding as ordinary strings (e.g., Distinguished Names).</t>

<t>- A lightweight BER encoding is used to encode all protocol elements.</t>
</abstract>
</front>

<seriesInfo value="1777" name="RFC" />
</reference>


<reference target2="reference.RFC.1778.xml" anchor="RFC1778">
<front>
<title abbrev="Syntax Encoding">The String Representation of Standard Attribute Syntaxes</title>
<author fullname="Tim Howes" initials="T." surname="Howes">
<organization>University of Michigan, ITD Research Systems</organization>

<address>
<postal>
<street>535 W William St.</street>
<city>Ann Arbor</city>
<region>MI</region>
<code>48103-4943</code>
<country>US</country>
</postal>

<phone>+1 313 747 4454</phone>
<email>tim@umich.edu</email>
</address>
</author>

<author fullname="Steve Kille" initials="S." surname="Kille">
<organization>ISODE Consortium</organization>

<address>
<postal>
<street>POB 505</street>
<city>London</city>
<region>England</region>
<code>SW11 1DX</code>
<country>UK</country>
</postal>

<phone>+44 71 2234062</phone>
<email>S.Kille@isode.com</email>
</address>
</author>

<author fullname="Wengyik Yeong" initials="W." surname="Yeong">
<organization>PSI Inc.</organization>

<address>
<postal>
<street>510 Huntmar Park Drive</street>
<city>Herndon</city>
<region>VA</region>
<code>22070</code>
<country>US</country>
</postal>

<phone>+1 703 450 8001</phone>
<email>yeongw@psilink.com</email>
</address>
</author>

<author fullname="Colin Robbins" initials="C." surname="Robbins">
<organization>NeXor Ltd</organization>

<address>
<postal>
<street>University Park</street>
<city>Nottingham</city>
<region>England</region>
<code>NG7 2RD</code>
<country>UK</country>
</postal>

</address>
</author>

<date year="1995" month="March" />

<abstract>
<t>The Lightweight Directory Access Protocol (LDAP)requires that the contents of AttributeValue fields in protocol elements be octet strings.  This document defines the requirements that must be satisfied by encoding rules used to render X.500 Directory attribute syntaxes into a form suitable for use in the LDAP, then goes on to define the encoding rules for the standard set of attribute syntaxes defined in,and.</t>
</abstract>
</front>

<seriesInfo value="1778" name="RFC" />
</reference>


<reference target2="reference.RFC.1779.xml" anchor="RFC1779">
<front>
<title abbrev="DN Representation">A String Representation of Distinguished Names</title>
<author fullname="Steve Kille" initials="S." surname="Kille">
<organization>ISODE Consortium</organization>

<address>
<postal>
<street>The Dome, The Square</street>
<city>Richmond</city>
<region>England</region>
<code>TW9 1DT</code>
<country>UK</country>
</postal>

<phone>+44 181 3329091</phone>
<email>S.Kille@ISODE.COM</email>
</address>
</author>

<date year="1995" month="March" />

<abstract>
<t>The OSI Directory uses distinguished names as the primary keys to entries in the directory.  Distinguished Names are encoded in ASN.1. When a distinguished name is communicated between to users not using a directory protocol (e.g., in a mail message), there is a need to have a user-oriented string representation of distinguished name. This specification defines a string format for representing names, which is designed to give a clean representation of commonly used names, whilst being able to represent any distinguished name.</t>
</abstract>
</front>

<seriesInfo value="1779" name="RFC" />
</reference>


<reference target2="reference.RFC.1780.xml" anchor="RFC1780">
<front>
<title abbrev="Internet Standards">Internet Official Protocol Standards</title>
<author fullname="Jon Postel" initials="J." surname="Postel">
<organization>USC/Information Sciences Institute</organization>

<address>
<postal>
<street>4676 Admiralty Way</street>
<city>Marina del Rey</city>
<region>CA</region>
<code>90292</code>
<country>US</country>
</postal>

<phone>+1 310 822 1511</phone>
<facsimile>+1 310 823 6714</facsimile>
<email>Postel@ISI.EDU</email>
</address>
</author>

<date year="1995" month="March" />
</front>

<seriesInfo value="1780" name="RFC" />
</reference>


<reference target2="reference.RFC.1781.xml" anchor="RFC1781">
<front>
<title abbrev="User Friendly Naming">Using the OSI Directory to Achieve User Friendly Naming</title>
<author fullname="Steve Kille" initials="S." surname="Kille">
<organization>ISODE Consortium</organization>

<address>
<postal>
<street>The Dome, The Square</street>
<city>Richmond</city>
<region>England</region>
<code>TW9 1DT</code>
<country>UK</country>
</postal>

<phone>+44 181 3329091</phone>
<email>S.Kille@ISODE.COM</email>
</address>
</author>

<date year="1995" month="March" />

<abstract>
<t>The OSI Directory has user friendly naming as a goal.  A simple minded usage of the directory does not achieve this.  Two aspects not achieved are:</t>

<t>o  A user oriented notation</t>

<t>o  Guessability</t>

<t>This proposal sets out some conventions for representing names in a friendly manner, and shows how this can be used to achieve really friendly naming.  This then leads to a specification of a standard format for representing names, and to procedures to resolve them. This leads to a specification which allows directory names to be communicated between humans.  The format in this specification is identical to that defined in, and it is intended that these specifications are compatible.</t>
</abstract>
</front>

<seriesInfo value="1781" name="RFC" />
</reference>


<reference target2="reference.RFC.1782.xml" anchor="RFC1782">
<front>
<title>TFTP Option Extension</title>
<author fullname="Gary Scott Malkin" initials="G." surname="Malkin">
<organization>Xylogics, Inc.</organization>

<address>
<postal>
<street>53 Third Avenue</street>
<city>Burlington</city>
<region>MA</region>
<code>01803</code>
<country>US</country>
</postal>

<phone>+1 617 272 8140</phone>
<email>gmalkin@xylogics.com</email>
</address>
</author>

<author fullname="Art Harkin" initials="A." surname="Harkin">
<organization>Internet Services Project, Information Networks Division</organization>

<address>
<postal>
<street>19420 Homestead Road</street>
<street>MS 43LN</street>
<city>Cupertino</city>
<region>CA</region>
<code>95014</code>
<country>US</country>
</postal>

<phone>+1 408 447 3755</phone>
<email>ash@cup.hp.com</email>
</address>
</author>

<date year="1995" month="March" />

<abstract>
<t>The Trivial File Transfer Protocolis a simple, lock-step, file transfer protocol which allows a client to get or put a file onto a remote host.  This document describes a simple extension to TFTP to allow option negotiation prior to the file transfer.</t>
</abstract>
</front>

<seriesInfo value="1782" name="RFC" />
</reference>


<reference target2="reference.RFC.1783.xml" anchor="RFC1783">
<front>
<title>TFTP Blocksize Option</title>
<author fullname="Gary Scott Malkin" initials="G.S." surname="Malkin">
<organization>Xylogics, Inc.</organization>

<address>
<postal>
<street>53 Third Avenue</street>
<city>Burlington</city>
<region>MA</region>
<code>01803</code>
<country>US</country>
</postal>

<phone>+1 617 272 8140</phone>
<email>gmalkin@xylogics.com</email>
</address>
</author>

<author fullname="Art Harkin" initials="A." surname="Harkin">
<organization>Internet Services Project, Information Networks Division</organization>

<address>
<postal>
<street>19420 Homestead Road</street>
<street>MS 43LN</street>
<city>Cupertino</city>
<region>CA</region>
<code>95014</code>
<country>US</country>
</postal>

<phone>+1 408 447 3755</phone>
<email>ash@cup.hp.com</email>
</address>
</author>

<date year="1995" month="March" />

<abstract>
<t>The Trivial File Transfer Protocolis a simple, lock-step, file transfer protocol which allows a client to get or put a file onto a remote host.  One of its primary uses is the booting of diskless nodes on a Local Area Network.  TFTP is used because it is very simple to implement in a small node's limited ROM space.  However, the choice of a 512-byte blocksize is not the most efficient for use on a LAN whose MTU may 1500 bytes or greater.</t>

<t>This document describes a TFTP option which allows the client and server to negotiate a blocksize more applicable to the network medium.  The TFTP Option Extension mechanism is described in.</t>
</abstract>
</front>

<seriesInfo value="1783" name="RFC" />
</reference>


<reference target2="reference.RFC.1784.xml" anchor="RFC1784">
<front>
<title abbrev="TFTP Options">TFTP Timeout Interval and Transfer Size Options</title>
<author fullname="Gary Scott Malkin" initials="G." surname="Malkin">
<organization>Xylogics, Inc.</organization>

<address>
<postal>
<street>53 Third Avenue</street>
<city>Burlington</city>
<region>MA</region>
<code>01803</code>
<country>US</country>
</postal>

<phone>+1 617 272 8140</phone>
<email>gmalkin@xylogics.com</email>
</address>
</author>

<author fullname="Art Harkin" initials="A." surname="Harkin">
<organization>Internet Services Project, Information Networks Division</organization>

<address>
<postal>
<street>19420 Homestead Road</street>
<street>MS 43LN</street>
<city>Cupertino</city>
<region>CA</region>
<code>95014</code>
<country>US</country>
</postal>

<phone>+1 408 447 3755</phone>
<email>ash@cup.hp.com</email>
</address>
</author>

<date year="1995" month="March" />

<abstract>
<t>The Trivial File Transfer Protocolis a simple, lock-step, file transfer protocol which allows a client to get or put a file onto a remote host.</t>

<t>This document describes two TFTP options. The first allows the client and server to negotiate the Timeout Interval.  The second allows the side receiving the file to determine the ultimate size of the transfer before it begins.  The TFTP Option Extension mechanism is described in.</t>

<t>This document assumes that the reader is familiar with the terminology and notation of bothand.</t>
</abstract>
</front>

<seriesInfo value="1784" name="RFC" />
</reference>


<reference target2="reference.RFC.1785.xml" anchor="RFC1785">
<front>
<title>TFTP Option Negotiation Analysis</title>
<author fullname="Gary Scott Malkin" initials="G." surname="Malkin">
<organization>Xylogics, Inc.</organization>

<address>
<postal>
<street>53 Third Avenue</street>
<city>Burlington</city>
<region>MA</region>
<code>01803</code>
<country>US</country>
</postal>

<phone>+1 617 272 8140</phone>
<email>gmalkin@xylogics.com</email>
</address>
</author>

<author fullname="Art Harkin" initials="A." surname="Harkin">
<organization>Internet Services Project, Information Networks Division</organization>

<address>
<postal>
<street>19420 Homestead Road</street>
<street>MS 43LN</street>
<city>Cupertino</city>
<region>CA</region>
<code>95014</code>
<country>US</country>
</postal>

<phone>+1 408 447 3755</phone>
<email>ash@cup.hp.com</email>
</address>
</author>

<date year="1995" month="March" />

<abstract>
<t>The TFTP option negotiation mechanism, proposed in, is a backward-compatible extension to the TFTP protocol, defined in. It allows file transfer options to be negotiated prior to the transfer using a mechanism which is consistent with TFTP's Request Packet format.  The mechanism is kept simple by enforcing a request-
 respond-acknowledge sequence, similar to the lock-step approach taken by TFTP itself.</t>

<t>This document was written to allay concerns that the presence of options in a TFTP Request packet might cause pathological behavior on servers which do not support TFTP option negotiation.</t>
</abstract>
</front>

<seriesInfo value="1785" name="RFC" />
</reference>


<reference target2="reference.RFC.1786.xml" anchor="RFC1786">
<front>
<title abbrev="Representing IP Routing Policies in a RR">Representation of IP Routing Policies in a Routing Registry (ripe-81++)</title>
<author fullname="Tony Bates" initials="T." surname="Bates">
<organization>MCI Telecommunications Corporation</organization>

<address>
<postal>
<street>2100 Reston Parkway</street>
<city>Reston</city>
<region>VA</region>
<code>22094</code>
<country>US</country>
</postal>

<phone>+1 703 715 7521</phone>
<email>Tony.Bates@mci.net</email>
</address>
</author>

<author fullname="Elise Gerich" initials="E." surname="Gerich">
<organization>The University of Michigan, Merit Computer Network</organization>

<address>
<postal>
<street>1075 Beal Avenue</street>
<city>Ann Arbor</city>
<region>MI</region>
<code>48109</code>
<country>US</country>
</postal>

<phone>+1 313 936 2120</phone>
<email>epg@merit.edu</email>
</address>
</author>

<author fullname="Laurent Joncheray" initials="L." surname="Joncheray">
<organization>The University of Michigan, Merit Computer Network</organization>

<address>
<postal>
<street>1075 Beal Avenue</street>
<city>Ann Arbor</city>
<region>MI</region>
<code>48109</code>
<country>US</country>
</postal>

<phone>+1 313 936 2065</phone>
<email>lpj@merit.edu</email>
</address>
</author>

<author fullname="Jean-Michel Jouanigot" initials="J." surname="Jouanigot">
<organization>CERN, European Laboratory for Particle Physics</organization>

<address>
<postal>
<street>CH-1211 Geneva 23</street>
<city />
<region />
<code />
<country>CH</country>
</postal>

<phone>+41 22 7674417</phone>
<email>Jean-Michel.Jouanigot@cern.ch</email>
</address>
</author>

<author fullname="Daniel Karrenberg" initials="D." surname="Karrenberg">
<organization>RIPE Network Coordination Centre</organization>

<address>
<postal>
<street>Kruislaan 409</street>
<city>Amsterdam</city>
<region />
<code>NL-1098 SJ</code>
<country>NL</country>
</postal>

<phone>+31 20 5925065</phone>
<email>D.Karrenberg@ripe.net</email>
</address>
</author>

<author fullname="Marten Terpstra" initials="M." surname="Terpstra">
<organization>Bay Networks, Inc.</organization>

<address>
<postal>
<street>2 Federal St</street>
<city>Billerica</city>
<region>MA</region>
<code>01821</code>
<country>US</country>
</postal>

<phone>+1 508 436 8036</phone>
<email>marten@BayNetworks.com</email>
</address>
</author>

<author fullname="Jessica Yu" initials="J." surname="Yu">
<organization>The University of Michigan, Merit Computer Network</organization>

<address>
<postal>
<street>1075 Beal Avenue</street>
<city>Ann Arbor</city>
<region>MI</region>
<code>48109</code>
<country>US</country>
</postal>

<phone>+1 313 936 2655</phone>
<email>jyy@merit.edu</email>
</address>
</author>

<date year="1995" month="March" />

<abstract>
<t>This document was originally published as a RIPE document known as ripe-181 but is also being published as an Informational RFC to reach a larger audience than its original scope. It has received community wide interest and acknowledgment throughout the Internet service provider community and will be used as the basic starting point for future work on Internet Routing Registries and routing policy representation.  It can also be referred to as ripe-81++.  This document is an update to the original `ripe-81'proposal for representing and storing routing polices within the RIPE database. It incorporates several extensions proposed by Merit Inc.and gives details of a generalized IP routing policy representation to be used by all Internet routing registries. It acts as both tutorial and provides details of database objects and attributes that use and make up a routing registry.</t>
</abstract>
</front>

<seriesInfo value="1786" name="RFC" />
</reference>


<reference target2="reference.RFC.1787.xml" anchor="RFC1787">
<front>
<title abbrev="Routing in a multi-provider Internet">Routing in a Multi-provider Internet</title>
<author fullname="Yakov Rekhter" initials="Y." surname="Rekhter">
<organization>IBM Corporation, T.J. Watson Research Center</organization>

<address>
<postal>
<street>P.O. Box 704</street>
<street>Office H3-D40</street>
<city>Yorktown Heights</city>
<region>NY</region>
<code>10598</code>
<country>US</country>
</postal>

<phone>+1 914 784 7361</phone>
<email>yakov@watson.ibm.com</email>
</address>
</author>

<date year="1995" month="April" />

<abstract>
<t>This document was prepared by the author on behalf of the Internet Architecture Board (IAB). It is offered by the IAB to stimulate discussion.</t>

<t>Over the past few years the Internet has undergone significant changes.  Among them is the emergence of multiple Network Service Providers, where resources that provide Internet-wide IP connectivity (routers, links) are controlled by different organizations.  This document presents some of the issues related to network layer routing in a multi-provider Internet, and specifically to the unicast routing.</t>
</abstract>
</front>

<seriesInfo value="1787" name="RFC" />
</reference>


<reference target2="reference.RFC.1788.xml" anchor="RFC1788">
<front>
<title abbrev="ICMP Domain Name">ICMP Domain Name Messages</title>
<author fullname="William Allen Simpson" initials="W." surname="Simpson">
<organization>Daydreamer, Computer Systems Consulting Services</organization>

<address>
<postal>
<street>1384 Fontaine</street>
<city>Madison Heights</city>
<region>MI</region>
<code>48071</code>
<country>US</country>
</postal>

<email>Bill.Simpson@um.cc.umich.edu</email>
</address>
</author>

<date year="1995" month="April" />

<abstract>
<t>This document specifies ICMP messages for learning the Fully Qualified Domain Name associated with an IP address.</t>
</abstract>
</front>

<seriesInfo value="1788" name="RFC" />
</reference>


<reference target2="reference.RFC.1789.xml" anchor="RFC1789">
<front>
<title abbrev="Telephone Service and Servers on Internet">INETPhone: Telephone Services and Servers on Internet</title>
<author fullname="Cui-Qing Yang" initials="C." surname="Yang">
<organization>University of North Texas, Dept. of Computer Science</organization>

<address>
<postal>
<street>P.O. Box 13886</street>
<city>Denton</city>
<region>TX</region>
<code>76203</code>
<country>US</country>
</postal>

<phone>+1 817 565 2822</phone>
<facsimile>+1 817 565 2799</facsimile>
<email>cqyang@cs.unt.edu</email>
</address>
</author>

<date year="1995" month="April" />

<abstract>
<t>INETPhone is a true telephone service through the Internet. It integrates the local telephone networks and the Internet using INETPhone servers. Thus a long distance call can be split into two local calls and an Internet connection, which is transparent to end users. Such a phone service through Internet will be a major step towards integrated services on Internet. In order to support the INETPhone and lay down the ground rules of the service, a scheme of "open partnership" is proposed, so that the entire Internet community can have the equal opportunity and benefits from the INETPhone service.</t>
</abstract>
</front>

<seriesInfo value="1789" name="RFC" />
</reference>


<reference target2="reference.RFC.1790.xml" anchor="RFC1790">
<front>
<title abbrev="ISOC - SUN Agreement: ONC RPC and XDR Protocols">An Agreement between the Internet Society and Sun Microsystems, Inc</title>
<author fullname="Vinton G. Cerf" initials="V." surname="Cerf">
<organization>Internet Society</organization>

<address>
<postal>
<street>12020 Sunrise Valley Dr</street>
<street>suite 270</street>
<city>Reston</city>
<region>VA</region>
<code>22091</code>
<country>US</country>
</postal>

<phone>+1 703 648 9888</phone>
<email>vcerf@isoc.org</email>
</address>
</author>

<date year="1995" month="April" />

<abstract>
<t></t>
</abstract>
</front>

<seriesInfo value="1790" name="RFC" />
</reference>


<reference target2="reference.RFC.1791.xml" anchor="RFC1791">
<front>
<title abbrev="TCP And UDP Over IPX">TCP And UDP Over IPX Networks With Fixed Path MTU</title>
<author fullname="Tae Sung" initials="T." surname="Sung">
<organization>Novell, Inc.</organization>

<address>
<postal>
<street>2180 Fortune Drive</street>
<city>San Jose</city>
<region>CA</region>
<code>95131</code>
<country>US</country>
</postal>

<phone>+1 408 577 8439</phone>
<email>tae@novell.Com</email>
</address>
</author>

<date year="1995" month="April" />
</front>

<seriesInfo value="1791" name="RFC" />
</reference>


<reference target2="reference.RFC.1792.xml" anchor="RFC1792">
<front>
<title abbrev="TCP/IPX MIB">TCP/IPX Connection Mib Specification</title>
<author fullname="Tae Sung" initials="T." surname="Sung">
<organization>Novell, Inc.</organization>

<address>
<postal>
<street>2180 Fortune Drive</street>
<city>San Jose</city>
<region>CA</region>
<code>95131</code>
<country>US</country>
</postal>

<phone>+1 408 577 8439</phone>
<email>tae@novell.Com</email>
</address>
</author>

<date year="1995" month="April" />
</front>

<seriesInfo value="1792" name="RFC" />
</reference>


<reference target2="reference.RFC.1793.xml" anchor="RFC1793">
<front>
<title abbrev="OSPF over Demand Circuits">Extending OSPF to Support Demand Circuits</title>
<author fullname="John Moy" initials="J." surname="Moy">
<organization>Cascade Communications Corp.</organization>

<address>
<postal>
<street>5 Carlisle Road</street>
<city>Westford</city>
<region>MA</region>
<code>01886</code>
<country>US</country>
</postal>

<phone>+1 508 692 2600 x394</phone>
<facsimile>+1 508 692 9214</facsimile>
<email>jmoy@casc.com</email>
</address>
</author>

<date year="1995" month="April" />

<abstract>
<t>This memo defines enhancements to the OSPF protocol that allow efficient operation over "demand circuits". Demand circuits are network segments whose costs vary with usage; charges can be based both on connect time and on bytes/packets transmitted. Examples of demand circuits include ISDN circuits, X.25 SVCs, and dial-up lines. The periodic nature of OSPF routing traffic has until now required a demand circuit's underlying data-link connection to be constantly open, resulting in unwanted usage charges. With the modifications described herein, OSPF Hellos and the refresh of OSPF routing information are suppressed on demand circuits, allowing the underlying data-link connections to be closed when not carrying application traffic.</t>

<t>Demand circuits and regular network segments (e.g., leased lines) are allowed to be combined in any manner. In other words, there are no topological restrictions on the demand circuit support. However,  while any OSPF network segment can be defined as a demand circuit, only point-to-point networks receive the full benefit. When broadcast and NBMA networks are declared demand circuits, routing update traffic is reduced but the periodic sending of Hellos is not, which in effect still requires that the data-link connections remain constantly open.</t>

<t>While mainly intended for use with cost-conscious network links such as ISDN, X.25 and dial-up, the modifications in this memo may also prove useful over bandwidth-limited network links such as slow-speed leased lines and packet radio.</t>

<t>The enhancements defined in this memo are backward-compatible with the OSPF specification defined in, and with the OSPF extensions defined in(OSPF NSSA areas),(MOSPF) and(OSPF Point-to-MultiPoint Interface).</t>

<t>This memo provides functionality similar to that specified for RIP in, with the main difference being the way the two proposals handle oversubscription (see Sections 4.3 and 7 below).  However, because OSPF employs link-state routing technology as opposed to RIP's  Distance Vector base, the mechanisms used to achieve the demand circuit functionality are quite different.</t>

<t>Please send comments to ospf@gated.cornell.edu.</t>
</abstract>
</front>

<seriesInfo value="1793" name="RFC" />
</reference>


<reference target2="reference.RFC.1794.xml" anchor="RFC1794">
<front>
<title>DNS Support for Load Balancing</title>
<author fullname="Thomas P. Brisco" initials="T." surname="Brisco">
<organization>Rutgers University, Computing Services, Telecommunications Division, Hill Center for the Mathematical Sciences</organization>

<address>
<postal>
<street>Busch Campus</street>
<city>Piscataway</city>
<region>NJ</region>
<code>08855-0879</code>
<country>US</country>
</postal>

<phone>+1 908 445 2351</phone>
<email>brisco@rutgers.edu</email>
</address>
</author>

<date year="1995" month="April" />
</front>

<seriesInfo value="1794" name="RFC" />
</reference>


<reference target2="reference.RFC.1795.xml" anchor="RFC1795">
<front>
<title abbrev="Data Link Switching">Data Link Switching: Switch-to-Switch Protocol AIW DLSw RIG: DLSw Closed Pages, DLSw Standard Version 1</title>
<author fullname="Louise Wells" initials="L." surname="Wells">
<organization>Internetwork Technology Institute</organization>

<address>
<postal>
<street>2021 Stratford Dr.</street>
<city>Milpitas</city>
<region>CA</region>
<code>95035</code>
<country>US</country>
</postal>

<email>lhwells@cup.portal.com</email>
</address>
</author>

<author fullname="Alan K. Bartky" initials="A." surname="Bartky">
<organization>Sync Research Inc.</organization>

<address>
<postal>
<street>7 Studebaker</street>
<city>Irvine</city>
<region>CA</region>
<code>91728-2013</code>
<country>US</country>
</postal>

<phone>+1 714 588 2070</phone>
<email>alan@sync.com</email>
</address>
</author>

<date year="1995" month="April" />

<abstract>
<t>This RFC describes use of Data Link Switching over TCP/IP. The RFC is being distributed to members of the Internet community in order to solicit their reactions to the proposals contained in it.  While the issues discussed may not be directly relevant to the research problems of the Internet, they may be interesting to a number of researchers and Implementers.</t>

<t>This RFC was created as a joint effort of the Advanced Peer-to-Peer Networking (APPN) Implementers Workshop (AIW) Data Link Switching (DLSw) Related Interest Group (RIG).  The APPN Implementers Workshop is a group sponsored by IBM and consists of representatives of member companies implementing current and future IBM Networking interoperable products. The DLSw Related Interest Group was formed in this forum in order to produce a single version of the Switch to Switch Protocol (SSP) which could be implemented by all vendors, which would fix documentation problems with the existing RFC 1434, and which would enhance and evolve the protocol to add new functions and features.</t>

<t>This document is based on RFC 1434.  This document contains significant changes to RFC 1434 and therefore obsoletes that document.</t>

<t>Any questions or comments relative to the contents of this RFC should be sent to the following Internet address: aiw-dlsw@networking.raleigh.ibm.com.</t>

<t>NOTE 1: This is a widely subscribed mailing list and messages sent to this address will be sent to all members of the DLSw mailing list. For specific questions relating to subscribing to the AIW and any of it's working groups send email to: appn@vnet.ibm.com</t>

<t>Information regarding all of the AIW working groups and the work they are producing can be obtained by copying, via anonymous ftp, the file aiwinfo.psbin or aiwinfo.txt from the Internet host networking.raleigh.ibm.com, located in directory aiw.</t>

<t>NOTE 2:  These mailing lists and addresses are subject to change.</t>
</abstract>
</front>

<seriesInfo value="1795" name="RFC" />
</reference>


<reference target2="reference.RFC.1796.xml" anchor="RFC1796">
<front>
<title>Not All RFCs are Standards</title>
<author fullname="Christian Huitema" initials="C." surname="Huitema">
<organization>INRIA, Sophia-Antipolis</organization>

<address>
<postal>
<street>2004 Route des Lucioles</street>
<street>BP 109</street>
<city>Valbonne Cedex</city>
<region />
<code>F-06561</code>
<country>FR</country>
</postal>

<phone>+33 93 657715</phone>
<email>Christian.Huitema@MIRSA.INRIA.FR</email>
</address>
</author>

<author fullname="Jon Postel" initials="J." surname="Postel">
<organization>USC/Information Sciences Institute</organization>

<address>
<postal>
<street>4676 Admiralty Way</street>
<city>Marina del Rey</city>
<region>CA</region>
<code>90292</code>
<country>US</country>
</postal>

<phone>+1 310 822 1511</phone>
<email>Postel@ISI.EDU</email>
</address>
</author>

<author fullname="Steve Crocker" initials="S." surname="Crocker">
<organization>CyberCash, Inc.</organization>

<address>
<postal>
<street>2086 Hunters Crest Way</street>
<city>Vienna</city>
<region>VA</region>
<code>22181</code>
<country>US</country>
</postal>

<phone>+1 703 620 1222</phone>
<email>crocker@cybercash.com</email>
</address>
</author>

<date year="1995" month="April" />

<abstract>
<t>This document discusses the relationship of the Request for Comments (RFCs) notes to Internet Standards.</t>
</abstract>
</front>

<seriesInfo value="1796" name="RFC" />
</reference>


<reference target2="reference.RFC.1797.xml" anchor="RFC1797">
<front>
<title>Class A Subnet Experiment</title>
<author>
<organization>Internet Assigned Numbers Authority (IANA)</organization>

<address>
<postal>
<street>4676 Admiralty Way</street>
<street>Suite 1001</street>
<city>Marina del Rey</city>
<region>CA</region>
<code>90292-6695</code>
<country>US</country>
</postal>

<phone>+1 310 822 1511</phone>
<email>iana@isi.edu</email>
</address>
</author>

<date year="1995" month="April" />
</front>

<seriesInfo value="1797" name="RFC" />
</reference>


<reference target2="reference.RFC.1798.xml" anchor="RFC1798">
<front>
<title abbrev="CLDAP">Connection-less Lightweight X.500 Directory Access Protocol</title>
<author fullname="Alan Young" initials="A." surname="Young">
<organization>ISODE Consortium</organization>

<address>
<postal>
<street>The Dome, The Square</street>
<city>Richmond</city>
<region>England</region>
<code>TW9 1DT</code>
<country>UK</country>
</postal>

<phone>+44 81 3329091</phone>
<email>A.Young@isode.com</email>
</address>
</author>

<date year="1995" month="June" />
</front>

<seriesInfo value="1798" name="RFC" />
</reference>


<reference target2="reference.RFC.1799.xml" anchor="RFC1799">
<front>
<title abbrev="Summary of 1700-1799">Request for Comments Summary RFC Numbers 1700-1799</title>
<author fullname="Mary Kennedy" initials="M." surname="Kennedy">
<organization>University of Southern California, Information Sciences Institute</organization>

<address>
<postal>
<street>4676 Admiralty Way</street>
<city>Marina del Rey</city>
<region>CA</region>
<code>90292</code>
<country>US</country>
</postal>

<phone>+1 310 822 1511</phone>
<email>MKENNEDY@ISI.EDU</email>
</address>
</author>

<date year="1997" month="January" />
</front>

<seriesInfo value="1799" name="RFC" />
</reference>


<reference target2="reference.RFC.1800.xml" anchor="RFC1800">
<front>
<title abbrev="Internet Standards">Internet Official Protocol Standards</title>
<author fullname="Jon Postel" initials="J." surname="Postel">
<organization>USC/Information Sciences Institute</organization>

<address>
<postal>
<street>4676 Admiralty Way</street>
<city>Marina del Rey</city>
<region>CA</region>
<code>90292</code>
<country>US</country>
</postal>

<phone>+1 310 822 1511</phone>
<facsimile>+1 310 823 6714</facsimile>
<email>Postel@ISI.EDU</email>
</address>
</author>

<date year="1995" month="July" />
</front>

<seriesInfo value="1800" name="RFC" />
</reference>


<reference target2="reference.RFC.1801.xml" anchor="RFC1801">
<front>
<title abbrev="X.400-MHS Routing using X.500 Directory">MHS use of the X.500 Directory to support MHS Routing</title>
<author fullname="Steve Kille" initials="S." surname="Kille">
<organization>ISODE Consortium</organization>

<address>
<postal>
<street>The Dome, The Square</street>
<city>Richmond</city>
<region>England</region>
<code>TW9 1DT</code>
<country>UK</country>
</postal>

<phone>+44 81 3329091</phone>
<email>S.Kille@ISODE.COM</email>
</address>
</author>

<date year="1995" month="June" />
</front>

<seriesInfo value="1801" name="RFC" />
</reference>


<reference target2="reference.RFC.1802.xml" anchor="RFC1802">
<front>
<title abbrev="Introducing Project Long Bud">Introducing Project Long Bud: Internet Pilot Project for the Deployment of X.500 Directory Information in Support of X.400 Routing</title>
<author fullname="Harald T. Alvestrand" initials="H." surname="Alvestrand">
<organization>UNINETT</organization>

<address>
<postal>
<street>P.O. box 6883 Elgeseter</street>
<city>Trondheim</city>
<region />
<code>N-7002</code>
<country>NO</country>
</postal>

<phone>+47 73 597094</phone>
<email>Harald.T.Alvestrand@uninett.no</email>
</address>
</author>

<author fullname="Kevin E. Jordan" initials="K." surname="Jordan">
<organization>Control Data Systems, Inc.</organization>

<address>
<postal>
<street>4201 Lexington Avenue North</street>
<city>Arden Hills</city>
<region>MN</region>
<code>55126</code>
<country>US</country>
</postal>

<phone>+1 612 482 6835</phone>
<email>Kevin.E.Jordan@cdc.com</email>
</address>
</author>

<author fullname="Sylvain Langlois" initials="S." surname="Langlois">
<organization>Direction des Etudes et Recherches/Electricite de France</organization>

<address>
<postal>
<street>1 avenue du General de Gaulle</street>
<street>92141 Clamart Cedex</street>
<city />
<region />
<code />
<country>FR</country>
</postal>

<phone>+33 1 47654402</phone>
<email>Sylvain.Langlois@der.edf.fr</email>
</address>
</author>

<author fullname="James A. Romaguera" initials="J." surname="Romaguera">
<organization>NetConsult AG</organization>

<address>
<postal>
<street>Morgenstrasse 129 3018</street>
<city>Bern</city>
<region />
<code />
<country>CH</country>
</postal>

<phone>+41 31 9984141</phone>
<email>Romaguera@NetConsult.ch</email>
</address>
</author>

<date year="1995" month="June" />

<abstract>
<t>The Internet X.400 community (i.e., GO-MHS) currently lacks a distributed  mechanism providing dynamic updating and management of message routing information.  The IETF MHS-DS Working Group has specified an approach for X.400 Message Handling Systems to perform message routing using OSI Directory Services.  The MHS-DS approach has been successfully tested in a number of local environments.</t>

<t>This memo describes a proposed Internet Pilot Project that seeks to prove the MHS-DS approach on a larger scale.  The results of this pilot will then be used to draw up recommendations for a global deployment.</t>
</abstract>
</front>

<seriesInfo value="1802" name="RFC" />
</reference>


<reference target2="reference.RFC.1803.xml" anchor="RFC1803">
<front>
<title abbrev="X.500 Production Directory Service">Recommendations for an X.500 Production Directory Service</title>
<author fullname="Russ Wright" initials="R." surname="Wright">
<organization>Lawrence Berkeley Laboratory</organization>

<address>
<postal>
<street>1 Cyclotron Road</street>
<street>Mail-Stop 50B-2258</street>
<city>Berkeley</city>
<region>CA</region>
<code>94720</code>
<country>US</country>
</postal>

<phone>+1 510 486 6965</phone>
<email>wright@LBL.Gov</email>
</address>
</author>

<author fullname="Arlene F. Getchell" initials="A." surname="Getchell">
<organization>Lawrence Livermore National Laboratory, National Energy Research Supercomputer Center</organization>

<address>
<postal>
<street>P.O. Box 5509</street>
<street>L-561</street>
<city>Livermore</city>
<region>CA</region>
<code>94551</code>
<country>US</country>
</postal>

<phone>+1 510 423 6349</phone>
<email>getchell@es.net</email>
</address>
</author>

<author fullname="Tim Howes" initials="T." surname="Howes">
<organization>University of Michigan, ITD Research Systems</organization>

<address>
<postal>
<street>535 W William St.</street>
<city>Ann Arbor</city>
<region>MI</region>
<code>48103-4943</code>
<country>US</country>
</postal>

<phone>+1 313 747 4454</phone>
<email>tim@umich.edu</email>
</address>
</author>

<author fullname="Srinivas R. Sataluri" initials="S." surname="Sataluri">
<organization>AT&amp;T Bell Laboratories</organization>

<address>
<postal>
<street>101 Crawfords Corner Road</street>
<street>Room 1C-429</street>
<street>P.O. Box 3030</street>
<city>Holmdel</city>
<region>NJ</region>
<code>07733-3030</code>
<country>US</country>
</postal>

<phone>+1 908 949 7782</phone>
<email>sri@qsun.att.com</email>
</address>
</author>

<author fullname="Peter Yee" initials="P." surname="Yee">
<organization>NASA  Ames Research Center</organization>

<address>
<postal>
<street>MS 233-18</street>
<city>Moffett Field</city>
<region>CA</region>
<code>94035-1000</code>
<country>US</country>
</postal>

<email>yee@atlas.arc.nasa.gov</email>
</address>
</author>

<author fullname="Wengyik Yeong" initials="W." surname="Yeong">
<organization>Performance Systems International, Inc.</organization>

<address>
<postal>
<street>510 Huntmar Park Drive</street>
<city>Herndon</city>
<region>VA</region>
<code>22070</code>
<country>US</country>
</postal>

<email>yeongw@psi.com</email>
</address>
</author>

<date year="1995" month="June" />

<abstract>
<t>This document contains a set of basic recommendations for a country-level X.500 DSA.  These recommendations can only be considered a starting point in the quest to create a global production quality X.500 infrastructure.  For there to be a true "production quality" X.500 infrastructure more work must be done, including a transition from the 1988 X.500 (plus some Internet extensions) to the 1993 X.500 standard (including the '93 replication and knowledge model).  This document does not discuss this transition.</t>
</abstract>
</front>

<seriesInfo value="1803" name="RFC" />
</reference>


<reference target2="reference.RFC.1804.xml" anchor="RFC1804">
<front>
<title>Schema Publishing in X.500 Directory</title>
<author fullname="Glenn Mansfield" initials="G." surname="Mansfield">
<organization>AIC Systems Laboratories</organization>

<address>
<postal>
<street>6-6-3 Minami Yoshinari</street>
<city>Aoba-ku</city>
<region>Sendai</region>
<code>989-3204</code>
<country>JP</country>
</postal>

<phone>+81 22 2793310</phone>
<facsimile>+81 22 2793640</facsimile>
<email>glenn@aic.co.jp</email>
</address>
</author>

<author fullname="P. V. Rajeev" initials="P." surname="Rajeev">
<organization>Hughes Software Systems</organization>

<address>
<postal>
<street>International Trade Tower, Nehru Place</street>
<street>2nd Floor</street>
<city>New Delhi</city>
<region />
<code />
<country>IN</country>
</postal>

<email>rajeev%hss@lando.hns.com</email>
</address>
</author>

<author fullname="S. V. Raghavan" initials="S." surname="Raghavan">
<organization>Indian Institute of Technology, Madras, Department of Computer Science and Engineering</organization>

<address>
<postal>
<street />
<city>Madras</city>
<region />
<code>600 036</code>
<country>IN</country>
</postal>

<email>svr@iitm.ernet.in</email>
</address>
</author>

<author fullname="Tim Howes" initials="T." surname="Howes">
<organization>University of Michigan, ITD Research Systems</organization>

<address>
<postal>
<street>535 W William St.</street>
<city>Ann Arbor</city>
<region>MI</region>
<code>48103-4943</code>
<country>US</country>
</postal>

<phone>+1 313 747 4454</phone>
<email>tim@umich.edu</email>
</address>
</author>

<date year="1995" month="June" />

<abstract>
<t>The X.500 directory provides a powerful mechanism for storing and retrieving information about objects of interest.  To interpret the information stored in the directory, the schema must be known to all the components of the directory. Presently, there are no means other than ftp to distribute schema information across the Internet.  This is proving to be a severe constraint as the Directory is growing. This document presents a solution to the schema distribution problem using the existing mechanisms of the directory. A naming scheme for naming schema objects and a meta-schema for storing schema objects is presented. The procedures for fetching unknown schema from the directory at runtime are described.</t>
</abstract>
</front>

<seriesInfo value="1804" name="RFC" />
</reference>


<reference target2="reference.RFC.1805.xml" anchor="RFC1805">
<front>
<title>Location-Independent Data/Software Integrity Protocol</title>
<author fullname="Aviel D. Rubin" initials="A." surname="Rubin">
<organization>Bellcore</organization>

<address>
<postal>
<street />
<city>Morristown</city>
<region>NJ</region>
<code>07960</code>
<country>US</country>
</postal>

<phone>+1 201 829 5922</phone>
<facsimile>+1 201 829 2645</facsimile>
<email>rubin@bellcore.com</email>
</address>
</author>

<date year="1995" month="June" />

<abstract>
<t>This memo describes a protocol for adding integrity assurance to files that are distributed across the Internet.  This protocol is intended for the distribution of software, data, documents, and any other file that is subject to malicious modification.  The protocol described here is intended to provide assurances of integrity and time.  A trusted third party is required.</t>
</abstract>
</front>

<seriesInfo value="1805" name="RFC" />
</reference>


<reference target2="reference.RFC.1806.xml" anchor="RFC1806">
<front>
<title abbrev="Content-Disposition">Communicating Presentation Information in Internet Messages: The Content-Disposition Header</title>
<author fullname="Rens Troost" initials="R." surname="Troost">
<organization>New Century Systems</organization>

<address>
<postal>
<street>324 East 41st Street #804</street>
<city>New York</city>
<region>NY</region>
<code>10017</code>
<country>US</country>
</postal>

<phone>+1 212 557 2050</phone>
<facsimile>+1 212 557 2049</facsimile>
<email>rens@century.com</email>
</address>
</author>

<author fullname="Steve Dorner" initials="S." surname="Dorner">
<organization>QUALCOMM Incorporated</organization>

<address>
<postal>
<street>6455 Lusk Boulevard</street>
<city>San Diego</city>
<region>CA</region>
<code>92121</code>
<country>US</country>
</postal>

<email>sdorner@qualcomm.com</email>
</address>
</author>

<date year="1995" month="June" />

<abstract>
<t>This memo provides a mechanism whereby messages conforming to the("MIME") specification can convey presentational information.  It specifies a new "Content-Disposition" header, optional and valid for anyentity ("message" or "body part"). Two values for this header are described in this memo; one for the ordinary linear presentation of the body part, and another to facilitate the use of mail to transfer files. It is expected that more values will be defined in the future, and procedures are defined for extending this set of values.</t>

<t>This document is intended as an extension to. As such, the reader is assumed to be familiar with, and. The information presented herein supplements but does not replace that found in those documents.</t>
</abstract>
</front>

<seriesInfo value="1806" name="RFC" />
</reference>


<reference target2="reference.RFC.1807.xml" anchor="RFC1807">
<front>
<title>A Format for Bibliographic Records</title>
<author fullname="Rebecca Lasher" initials="R." surname="Lasher">
<organization>Stanford University, Mathematical and Computer Sciences Library</organization>

<address>
<postal>
<street>M.S. 2125</street>
<city>Stanford</city>
<region>CA</region>
<code>94305</code>
<country>US</country>
</postal>

<phone>+1 415 723 0864</phone>
<email>rlasher@forsythe.stanford.edu</email>
</address>
</author>

<author fullname="Danny Cohen" initials="D." surname="Cohen">
<organization>Myricom</organization>

<address>
<postal>
<street>325 N. Santa Anita Ave.</street>
<city>Arcadia</city>
<region>CA</region>
<code>91006</code>
<country>US</country>
</postal>

<phone>+1 818 821 5555</phone>
<email>Cohen@myri.com</email>
</address>
</author>

<date year="1995" month="June" />

<abstract>
<t>This RFC defines a format for bibliographic records describing technical reports.  This format is used by the Cornell University Dienst protocol and the Stanford University SIFT system.  The original RFC (RFC 1357) was written by D. Cohen, ISI, July 1992. This is a revision of RFC 1357.  New fields include handle, other_access, keyword, and withdraw.</t>
</abstract>
</front>

<seriesInfo value="1807" name="RFC" />
</reference>


<reference target2="reference.RFC.1808.xml" anchor="RFC1808">
<front>
<title>Relative Uniform Resource Locators</title>
<author fullname="Roy T. Fielding" initials="R." surname="Fielding">
<organization>University of California Irvine, Department of Information and Computer Science</organization>

<address>
<postal>
<street />
<city>Irvine</city>
<region>CA</region>
<code>92717-3425</code>
<country>US</country>
</postal>

<phone>+1 714 824 4049</phone>
<facsimile>+1 714 824 4056</facsimile>
<email>fielding@ics.uci.edu</email>
</address>
</author>

<date year="1995" month="June" />

<abstract>
<t>A Uniform Resource Locator (URL) is a compact representation of the location and access method for a resource available via the Internet. When embedded within a base document, a URL in its absolute form may contain a great deal of information which is already known from the context of that base document's retrieval, including the scheme, network location, and parts of the url-path.  In situations where the base URL is well-defined and known to the parser (human or machine), it is useful to be able to embed URL references which inherit that context rather than re-specifying it in every instance.  This document defines the syntax and semantics for such Relative Uniform Resource Locators.</t>
</abstract>
</front>

<seriesInfo value="1808" name="RFC" />
</reference>


<reference target2="reference.RFC.1809.xml" anchor="RFC1809">
<front>
<title>Using the Flow Label Field in IPv6</title>
<author fullname="Craig Partridge" initials="C." surname="Partridge">
<organization>BBN Systems and Technologies</organization>

<address>
<postal>
<street>10 Moulton St.</street>
<city>Cambridge</city>
<region>MA</region>
<code>02138</code>
<country>US</country>
</postal>

<email>craig@aland.bbn.com</email>
</address>
</author>

<date year="1995" month="June" />

<abstract>
<t>The purpose of this memo is to distill various opinions and suggestions of the End-to-End Research Group regarding the handling of Flow Labels into a set of suggestions for IPv6.  This memo is for information purposes only and is not one of the IPv6 specifications. Distribution of this memo is unlimited.</t>
</abstract>
</front>

<seriesInfo value="1809" name="RFC" />
</reference>


<reference target2="reference.RFC.1810.xml" anchor="RFC1810">
<front>
<title>Report on MD5 Performance</title>
<author fullname="Joe Touch" initials="J." surname="Touch">
<organization>University of Southern California, Information Sciences Institute</organization>

<address>
<postal>
<street>4676 Admiralty Way</street>
<city>Marina del Rey</city>
<region>CA</region>
<code>90292-6695</code>
<country>US</country>
</postal>

<phone>+1 310 822 1511 x151</phone>
<facsimile>+1 310 823 6714</facsimile>
<email>touch@isi.edu</email>
<uri>ftp://ftp.isi.edu/pub/hpcc-papers/touch/</uri>
</address>
</author>

<date year="1995" month="June" />

<abstract>
<t>MD5 is an authentication algorithm, which has been proposed as the default authentication option in IPv6.  When enabled, the MD5 algorithm operates over the entire data packet, including header. This RFC addresses how fast MD5 can be implemented in software and hardware, and whether it supports currently available IP bandwidth. MD5 can be implemented in existing hardware technology at 256 Mbps, and in software at 87 Mbps.  These rates cannot support current IP rates, e.g., 100 Mbps TCP and 130 Mbps UDP over ATM.  If MD5 cannot
   support existing network bandwidth using existing technology, it will not scale as network speeds increase in the future.  This RFC is intended to alert the IP community about the performance limitations of MD5, and to suggest that alternatives be considered for use in high speed IP implementations.</t>
</abstract>
</front>

<seriesInfo value="1810" name="RFC" />
</reference>


<reference target2="reference.RFC.1811.xml" anchor="RFC1811">
<front>
<title>U.S</title>
<author>
<organization>Federal Networking Council</organization>

<address>
<postal>
<street>4001 N. Fairfax Drive</street>
<city>Arlington</city>
<region>VA</region>
<code>22203</code>
<country>US</country>
</postal>

<phone>+1 703 522 6410</phone>
<email>execdir@fnc.gov</email>
<uri>http://www.fnc.gov/</uri>
</address>
</author>

<date year="1995" month="June" />

<abstract>
<t>This document describes the registration policies for the top-level domain ".GOV". Thus far, Federal Agencies and their subsidiaries have registered without any guidance. This has resulted in multiple registrations for Federal Agencies and naming schemes that do not facilitate responsiveness to the public.  This document fixes this by restricting registrations to coincide with the approved structure of the US government.  The document cited, FIPS 95-1, provides a standard recognized structure into which domain registrations for top-level domains. The IANA requires that an organization/country apply for and get a 2 letter code from ISO/ITU (e.g., US for United States) for additional top-level registration.</t>

<t>As a side effect, this reduces the number of .GOV level registrations and reduces the workload on the Internic.</t>
</abstract>
</front>

<seriesInfo value="1811" name="RFC" />
</reference>


<reference target2="reference.RFC.1812.xml" anchor="RFC1812">
<front>
<title>Requirements for IP Version 4 Routers</title>
<author fullname="Fred Baker" initials="F." surname="Baker">
<organization>Cisco Systems</organization>

<address>
<postal>
<street>519 Lado Drive</street>
<city>Santa Barbara</city>
<region>CA</region>
<code>93111</code>
<country>US</country>
</postal>

<phone>+1 805 681 0115</phone>
<email>fred@cisco.com</email>
</address>
</author>

<date year="1995" month="June" />
</front>

<seriesInfo value="1812" name="RFC" />
</reference>


<reference target2="reference.RFC.1813.xml" anchor="RFC1813">
<front>
<title abbrev="NFS Version 3 Protocol">NFS Version 3 Protocol Specification</title>
<author fullname="Brent Callaghan" initials="B." surname="Callaghan">
<organization>Sun Microsystems, Inc.</organization>

<address>
<postal>
<street>2550 Garcia Avenue</street>
<street>Mailstop UMTV05-44</street>
<city>Mountain View</city>
<region>CA</region>
<code>94043-1100</code>
<country>US</country>
</postal>

<phone>+1 415 336 1051</phone>
<facsimile>+1 415 336 6015</facsimile>
<email>brent.callaghan@eng.sun.com</email>
</address>
</author>

<author fullname="Brian Pawlowski" initials="B." surname="Pawlowski">
<organization>Network Appliance Corp.</organization>

<address>
<postal>
<street>319 North Bernardo Ave.</street>
<city>Mountain View</city>
<region>CA</region>
<code>94043</code>
<country>US</country>
</postal>

<phone>+1 415 428 5136</phone>
<facsimile>+1 415 428 5151</facsimile>
<email>beepy@netapp.com</email>
</address>
</author>

<author fullname="Peter Staubach" initials="P." surname="Staubach">
<organization>Sun Microsystems, Inc.</organization>

<address>
<postal>
<street>2550 Garcia Avenue</street>
<street>Mailstop UMTV05-44</street>
<city>Mountain View</city>
<region>CA</region>
<code>94043-1100</code>
<country>US</country>
</postal>

<phone>+1 415 336 5615</phone>
<facsimile>+1 415 336 6015</facsimile>
<email>peter.staubach@eng.sun.com</email>
</address>
</author>

<date year="1995" month="June" />

<abstract>
<t>This paper describes the NFS version 3 protocol.  This paper is provided so that people can write compatible implementations.</t>
</abstract>
</front>

<seriesInfo value="1813" name="RFC" />
</reference>


<reference target2="reference.RFC.1814.xml" anchor="RFC1814">
<front>
<title>Unique Addresses are Good</title>
<author fullname="Elise Gerich" initials="E." surname="Gerich">
<organization>Merit Network Inc.</organization>

<address>
<postal>
<street>4251 Plymouth Road</street>
<city>Ann Arbor</city>
<region>MI</region>
<code>48105</code>
<country>US</country>
</postal>

<phone>+1 313 764 9430</phone>
<facsimile>+1 313 747 3745</facsimile>
<email>epg@merit.edu</email>
</address>
</author>

<date year="1995" month="June" />

<abstract>
<t>The IAB suggests that while RFC 1597 establishes reserved IP address space for the use of private networks which are isolated and will remain isolated from the Internet, any enterprise which anticipates external connectivity to the Internet should apply for a globally unique address from an Internet registry or service provider.</t>
</abstract>
</front>

<seriesInfo value="1814" name="RFC" />
</reference>


<reference target2="reference.RFC.1815.xml" anchor="RFC1815">
<front>
<title>Character Sets ISO-10646 and ISO-10646-J-1</title>
<author fullname="Masataka Ohta" initials="M." surname="Ohta">
<organization>Tokyo Institute of Technology</organization>

<address>
<postal>
<street>2-12-1, O-okayama</street>
<street>Meguro-ku</street>
<city>Tokyo</city>
<region />
<code>152</code>
<country>JP</country>
</postal>

<phone>+81 3 54997084</phone>
<facsimile>+81 3 37291940</facsimile>
<email>mohta@cc.titech.ac.jp</email>
</address>
</author>

<date year="1995" month="July" />

<abstract>
<t>Though the ISO character set standard of ISO 10646 is specified reasonably well about European characters, it is not so useful in an fully internationalized environment.</t>

<t>For the practical use of ISO 10646, a lot of external profiling such as restriction of characters, restriction of combination of characters and addition of language information is necessary.</t>

<t>This memo provides information on such profiling, along with charset names to each profiled instance.</t>

<t>Though all the effort is done to make the resulting charset as useful 10646 based charset as possible, the result is not so good.  So, the charsets defined in this memo are only for reference purpose and its use for practical purpose is strongly discouraged.</t>
</abstract>
</front>

<seriesInfo value="1815" name="RFC" />
</reference>


<reference target2="reference.RFC.1816.xml" anchor="RFC1816">
<front>
<title>U.S</title>
<author>
<organization>Federal Networking Council</organization>

<address>
<postal>
<street>4001 N. Fairfax Drive</street>
<city>Arlington</city>
<region>VA</region>
<code>22203</code>
<country>US</country>
</postal>

<phone>+1 703 522 6410</phone>
<email>execdir@fnc.gov</email>
<uri>http://www.fnc.gov/</uri>
</address>
</author>

<date year="1995" month="August" />

<abstract>
<t>This memo provides an update and clarification to RFC 1811.  This document describes the registration policies for the top-level domain ".GOV".  Thus far, Federal Agencies and their subsidiaries have registered without any guidance.  This has resulted in multiple registrations for Federal Agencies and naming schemes that do not facilitate responsiveness to the public.  This document fixes this by restricting registrations to coincide with the approved structure of the US government.  The document cited, FIPS 95-1, provides a standard recognized structure into which domain registrations for .GOV can be fit.  This policy is exactly comparable to that for the top-level domains.  The IANA requires that an organization/country
   apply for and get a 2 letter code from ISO/ITU (e.g., US for United States) for additional top-level registration.</t>

<t>As a side effect, this reduces the number of .GOV level registrations and reduces the workload on the Internic.</t>
</abstract>
</front>

<seriesInfo value="1816" name="RFC" />
</reference>


<reference target2="reference.RFC.1817.xml" anchor="RFC1817">
<front>
<title>CIDR and Classful Routing</title>
<author fullname="Yakov Rekhter" initials="Y." surname="Rekhter">
<organization>cisco Systems</organization>

<address>
<postal>
<street>170 West Tasman Drive</street>
<city>San Jose</city>
<region>CA</region>
<code>95134</code>
<country>US</country>
</postal>

<phone>+1 914 528 0090</phone>
<email>yakov@cisco.com</email>
</address>
</author>

<date year="1995" month="August" />

<abstract>
<t>Classless Inter-Domain Routing (CIDR) is used in the Internet as the primary mechanism to improve scalability of the Internet routing system. This document represents the IAB's (Internet Architecture Board) evaluation of the current and near term implications of CIDR on organizations that use Classful routing technology.</t>
</abstract>
</front>

<seriesInfo value="1817" name="RFC" />
</reference>


<reference target2="reference.RFC.1818.xml" anchor="RFC1818">
<front>
<title>Best Current Practices</title>
<author fullname="Jon Postel" initials="J." surname="Postel">
<organization>USC - ISI</organization>

<address>
<postal>
<street>4676 Admiralty Way</street>
<street>Suite 1001</street>
<city>Marina del Rey</city>
<region>CA</region>
<code>90292-6695</code>
<country>US</country>
</postal>

<phone>+1 310 822 1511</phone>
<email>postel@isi.edu</email>
</address>
</author>

<author fullname="Yakov Rekhter" initials="Y." surname="Rekhter">
<organization>cisco Systems, Inc.</organization>

<address>
<postal>
<street>170 West Tasman Drive</street>
<city>San Jose</city>
<region>CA</region>
<code>95134</code>
<country>US</country>
</postal>

<phone>+1 914 528 0090</phone>
<email>yakov@cisco.com</email>
</address>
</author>

<author fullname="Tony Li" initials="T." surname="Li">
<organization>cisco Systems, Inc.</organization>

<address>
<postal>
<street>1525 O'Brien Drive</street>
<city>Menlo Park</city>
<region>CA</region>
<code>94025</code>
<country>US</country>
</postal>

<email>tli@cisco.com</email>
</address>
</author>

<date year="1995" month="August" />

<abstract>
<t>This document describes a new series of documents which describe best current practices for the Internet community.  Documents in this series carry the endorsement of the Internet Engineering Steering Group (IESG).</t>
</abstract>
</front>

<seriesInfo value="1" name="BCP" />
<seriesInfo value="1818" name="RFC" />
</reference>


<reference target2="reference.RFC.1819.xml" anchor="RFC1819">
<front>
<title abbrev="ST2+ Protocol Specification">Internet Stream Protocol Version 2 (ST2) Protocol Specification - Version ST2+</title>
<author fullname="Luca Delgrossi" initials="L." surname="Delgrossi">
<organization>Andersen Consulting Technology Park</organization>

<address>
<postal>
<street>449 Route des Cretes</street>
<city>Sophia Antipolis</city>
<region />
<code>06902</code>
<country>FR</country>
</postal>

<phone>+33 92 948092</phone>
<email>luca@andersen.fr</email>
</address>
</author>

<author fullname="Louis Berger" initials="L." surname="Berger">
<organization>BBN Systems and Technologies</organization>

<address>
<postal>
<street>1300 North 17th Street</street>
<street>Suite 1200</street>
<city>Arlington</city>
<region>VA</region>
<code>22209</code>
<country>US</country>
</postal>

<phone>+1 703 284 4651</phone>
<email>lberger@bbn.com</email>
</address>
</author>

<author fullname="Dat Duong" initials="D." surname="Duong">
<organization>BBN Systems and Technologies</organization>

<address>
<postal>
<street>1300 North 17th Street</street>
<street>Suite 1200</street>
<city>Arlington</city>
<region>VA</region>
<code>22209</code>
<country>US</country>
</postal>

<phone>+1 703 284 4760</phone>
<email>dat@bbn.com</email>
</address>
</author>

<author fullname="Steve Jackowski" initials="S." surname="Jackowski">
<organization>Syzygy Communications Incorporated</organization>

<address>
<postal>
<street>269 Mt. Hermon Road</street>
<city>Scotts Valley</city>
<region>CA</region>
<code>95066</code>
<country>US</country>
</postal>

<phone>+1 408 439 6834</phone>
<email>stevej@syzygycomm.com</email>
</address>
</author>

<author fullname="Sibylle Schaller" initials="S." surname="Schaller">
<organization>IBM ENC, Broadband Multimedia Communications</organization>

<address>
<postal>
<street>Vangerowstr. 18</street>
<city>Heidelberg</city>
<region />
<code>D69020</code>
<country>DE</country>
</postal>

<phone>+49 6221 5944553</phone>
<email>schaller@heidelbg.ibm.com</email>
</address>
</author>

<date year="1995" month="August" />

<abstract>
<t>This memo contains a revised specification of the Internet STream Protocol Version 2 (ST2). ST2 is an experimental resource reservation protocol intended to provide end-to-end real-time guarantees over an internet. It allows applications to build multi-destination simplex data streams with a desired quality of service. The revised version of ST2 specified in this memo is called ST2+.</t>

<t>This specification is a product of the STream Protocol Working Group of the Internet Engineering Task Force.</t>
</abstract>
</front>

<seriesInfo value="1819" name="RFC" />
</reference>


<reference target2="reference.RFC.1820.xml" anchor="RFC1820">
<front>
<title abbrev="MIME User Agent Checklist">Multimedia E-mail (MIME) User Agent Checklist</title>
<author fullname="Erik Huizer" initials="E." surname="Huizer">
<organization>SURFnet bv</organization>

<address>
<postal>
<street>P.O. Box 19035</street>
<city>Utrecht</city>
<code>3501 DA</code>
<country>NL</country>
</postal>

<phone>+31 30 305305</phone>
<facsimile>+31 30 305329</facsimile>
<email>Erik.Huizer@SURFnet.nl</email>
</address>
</author>

<date year="1995" month="August" />

<abstract>
<t>This document presents a checklist to facilitate evaluation of MIME capable User Agents. Access to a MIME test-responder, that generates test-messages is described.</t>
</abstract>
</front>

<seriesInfo value="1820" name="RFC" />
</reference>


<reference target2="reference.RFC.1821.xml" anchor="RFC1821">
<front>
<title abbrev="Real-time Service in IP-ATM Networks">Integration of Real-time Services in an IP-ATM Network Architecture</title>
<author fullname="Marty Borden" initials="M." surname="Borden">
<organization>Bay Networks</organization>

<address>
<postal>
<street>3 Federal Street</street>
<city>Billerica</city>
<region>MA</region>
<code>01821</code>
<country>US</country>
</postal>

<phone>+1 508 670 8888</phone>
<email>mborden@baynetworks.com</email>
</address>
</author>

<author fullname="Eric S. Crawley" initials="E.S." surname="Crawley">
<organization>Bay Networks</organization>

<address>
<postal>
<street>3 Federal Street</street>
<city>Billerica</city>
<region>MA</region>
<code>01821</code>
<country>US</country>
</postal>

<phone>+1 508 670 8888</phone>
<email>esc@baynetworks.com</email>
</address>
</author>

<author fullname="Bruce S. Davie" initials="B." surname="Davie">
<organization>Bellcore</organization>

<address>
<postal>
<street>445 South Street</street>
<city>Morristown</city>
<region>NJ</region>
<code>07960-6438</code>
<country>US</country>
</postal>

<phone>+1 201 829 4838</phone>
<email>bsd@bellcore.com</email>
</address>
</author>

<author fullname="Stephen G. Batsell" initials="S.G." surname="Batsell">
<organization>Naval Research Laboratory</organization>

<address>
<postal>
<street>Code 5521</street>
<city>Washington</city>
<region>DC</region>
<code>20375-5337</code>
<country>US</country>
</postal>

<phone>+1 202 767 3834</phone>
<email>sgb@saturn.nrl.navy.mil</email>
</address>
</author>

<date year="1995" month="August" />

<abstract>
<t>The IETF is currently developing an integrated service model which is designed to support real-time services on the Internet. Concurrently, the ATM Forum is developing Asynchronous Transfer Mode networking which similarly provides real-time networking support. The use of ATM in the Internet as a link layer protocol is already occurring, and both the IETF and the ATM Forum are producing specifications for IP over ATM. The purpose of this paper is to provide a clear statement of what issues need to be addressed in interfacing the IP integrated services environment with an ATM service environment so as to create a seamless interface between the two in support of end users desiring real-time networking services.</t>
</abstract>
</front>

<seriesInfo value="1821" name="RFC" />
</reference>


<reference target2="reference.RFC.1822.xml" anchor="RFC1822">
<front>
<title abbrev="IKMP Patent Use">A Grant of Rights to Use a Specific IBM patent with Photuris</title>
<author fullname="John W. Lowe" initials="J." surname="Lowe">
<organization>IBM Corporation</organization>

<address>
<postal>
<street>500 Columbus Avenue</street>
<city>Thornwood</city>
<region>NY</region>
<code>10594</code>
<country>US</country>
</postal>

</address>
</author>

<date year="1995" month="August" />
</front>

<seriesInfo value="1822" name="RFC" />
</reference>


<reference target2="reference.RFC.1823.xml" anchor="RFC1823">
<front>
<title abbrev="LDAP API">The LDAP Application Program Interface</title>
<author fullname="Tim Howes" initials="T." surname="Howes">
<organization>University of Michigan, ITD Research Systems</organization>

<address>
<postal>
<street>535 W William St.</street>
<city>Ann Arbor</city>
<region>MI</region>
<code>48103-4943</code>
<country>US</country>
</postal>

<phone>+1 313 747 4454</phone>
<email>tim@umich.edu</email>
</address>
</author>

<author fullname="Mark Smith" initials="M." surname="Smith">
<organization>University of Michigan, ITD Research Systems</organization>

<address>
<postal>
<street>535 W William St.</street>
<city>Ann Arbor</city>
<region>MI</region>
<code>48103-4943</code>
<country>US</country>
</postal>

<phone>+1 313 764 2277</phone>
<email>mcs@umich.edu</email>
</address>
</author>

<date year="1995" month="August" />
</front>

<seriesInfo value="1823" name="RFC" />
</reference>


<reference target2="reference.RFC.1824.xml" anchor="RFC1824">
<front>
<title abbrev="TESS">The Exponential Security System TESS: An Identity-Based Cryptographic Protocol for Authenticated Key-Exchange (E.I.S.S.-Report 1995/4)</title>
<author fullname="Hadmut Danisch" initials="H." surname="Danisch">
<organization>University of Karlsruhe, European Institute for System Security (E.I.S.S.), Institut fuer Algorithmen und Kognitive Systeme (IAKS)</organization>

<address>
<postal>
<street />
<city>Karlsruhe</city>
<region />
<code>D-76128</code>
<country>DE</country>
</postal>

<phone>+49 721 9640018</phone>
<facsimile>+49 721 696893</facsimile>
<email>danisch@ira.uka.de</email>
<uri>http://avalon.ira.uka.de/personal/danisch.html</uri>
</address>
</author>

<date year="1995" month="August" />

<abstract>
<t>This informational RFC describes the basic mechanisms  and  functions of  an identity based system for the secure authenticated exchange of cryptographic keys, the generation of signatures, and  the  authentic distribution of public keys.</t>
</abstract>
</front>

<seriesInfo value="1824" name="RFC" />
</reference>


<reference target2="reference.RFC.1825.xml" anchor="RFC1825">
<front>
<title abbrev="Security Architecture for IP">Security Architecture for the Internet Protocol</title>
<author fullname="Randall Atkinson" initials="R." surname="Atkinson">
<organization>Naval Research Laboratory, Information Technology Division</organization>

<address>
<postal>
<street />
<city>Washington</city>
<region>DC</region>
<code>20375-5320</code>
<country>US</country>
</postal>

<phone>+1 202 767 2389</phone>
<facsimile>+1 202 404 8590</facsimile>
<email>atkinson@itd.nrl.navy.mil</email>
</address>
</author>

<date year="1995" month="August" />

<abstract>
<t></t>
</abstract>
</front>

<seriesInfo value="1825" name="RFC" />
</reference>


<reference target2="reference.RFC.1826.xml" anchor="RFC1826">
<front>
<title>IP Authentication Header</title>
<author fullname="Randall Atkinson" initials="R." surname="Atkinson">
<organization>Naval Research Laboratory, Information Technology Division</organization>

<address>
<postal>
<street />
<city>Washington</city>
<region>DC</region>
<code>20375-5320</code>
<country>US</country>
</postal>

<phone>+1 202 767 2389</phone>
<facsimile>+1 202 404 8590</facsimile>
<email>atkinson@itd.nrl.navy.mil</email>
</address>
</author>

<date year="1995" month="August" />

<abstract>
<t>This document describes a mechanism for providing cryptographic authentication for IPv4 and IPv6 datagrams.  An Authentication Header (AH) is normally inserted after an IP header and before the other information being authenticated.</t>
</abstract>
</front>

<seriesInfo value="1826" name="RFC" />
</reference>


<reference target2="reference.RFC.1827.xml" anchor="RFC1827">
<front>
<title abbrev="Encapsulating Security Payload">IP Encapsulating Security Payload (ESP)</title>
<author fullname="Randall Atkinson" initials="R." surname="Atkinson">
<organization>Naval Research Laboratory, Information Technology Division</organization>

<address>
<postal>
<street />
<city>Washington</city>
<region>DC</region>
<code>20375-5320</code>
<country>US</country>
</postal>

<phone>+1 202 404 7090</phone>
<facsimile>+1 202 404 7942</facsimile>
<email>atkinson@itd.nrl.navy.mil</email>
</address>
</author>

<date year="1995" month="August" />

<abstract>
<t>This document describes the IP Encapsulating Security Payload (ESP). ESP is a mechanism for providing integrity and confidentiality to IP datagrams.  In some circumstances it can also provide authentication to IP datagrams.  The mechanism works with both IPv4 and IPv6.</t>
</abstract>
</front>

<seriesInfo value="1827" name="RFC" />
</reference>


<reference target2="reference.RFC.1828.xml" anchor="RFC1828">
<front>
<title abbrev="AH MD5">IP Authentication using Keyed MD5</title>
<author fullname="Perry Metzger" initials="P." surname="Metzger">
<organization>Piermont Information Systems Inc.</organization>

<address>
<postal>
<street>160 Cabrini Blvd.</street>
<street>Suite #2</street>
<city>New York</city>
<region>NY</region>
<code>10033</code>
<country>US</country>
</postal>

<email>perry@piermont.com</email>
</address>
</author>

<author fullname="William Allen Simpson" initials="W." surname="Simpson">
<organization>Daydreamer, Computer Systems Consulting Services</organization>

<address>
<postal>
<street>1384 Fontaine</street>
<city>Madison Heights</city>
<region>MI</region>
<code>48071</code>
<country>US</country>
</postal>

<email>Bill.Simpson@um.cc.umich.edu</email>
</address>
</author>

<date year="1995" month="August" />

<abstract>
<t>This document describes the use of keyed MD5 with the IP Authentication Header.</t>
</abstract>
</front>

<seriesInfo value="1828" name="RFC" />
</reference>


<reference target2="reference.RFC.1829.xml" anchor="RFC1829">
<front>
<title abbrev="ESP DES-CBC">The ESP DES-CBC Transform</title>
<author fullname="Phil Karn" initials="P." surname="Karn">
<organization>Qualcomm, Inc.</organization>

<address>
<postal>
<street>6455 Lusk Blvd</street>
<city>San Diego</city>
<region>CA</region>
<code>92121-2779</code>
<country>US</country>
</postal>

<email>karn@unix.ka9q.ampr.org</email>
</address>
</author>

<author fullname="Perry Metzger" initials="P." surname="Metzger">
<organization>Piermont Information Systems Inc.</organization>

<address>
<postal>
<street>160 Cabrini Blvd.</street>
<street>Suite #2</street>
<city>New York</city>
<region>NY</region>
<code>10033</code>
<country>US</country>
</postal>

<email>perry@piermont.com</email>
</address>
</author>

<author fullname="William Allen Simpson" initials="W." surname="Simpson">
<organization>Daydreamer,  Computer Systems Consulting Services</organization>

<address>
<postal>
<street>1384 Fontaine</street>
<city>Madison Heights</city>
<region>MI</region>
<code>48071</code>
<country>US</country>
</postal>

<email>bsimpson@MorningStar.com</email>
</address>
</author>

<date year="1995" month="August" />

<abstract>
<t>This document describes the DES-CBC security transform for the IP Encapsulating Security Payload (ESP).</t>
</abstract>
</front>

<seriesInfo value="1829" name="RFC" />
</reference>


<reference target2="reference.RFC.1830.xml" anchor="RFC1830">
<front>
<title abbrev="Binary and Large Message Transport">SMTP Service Extensions for Transmission of Large and Binary MIME Messages</title>
<author fullname="Gregory M. Vaudreuil" initials="G." surname="Vaudreuil">
<organization>Octel Network Services</organization>

<address>
<postal>
<street>17060 Dallas Parkway</street>
<street>Suite 214</street>
<city>Dallas</city>
<region>TX</region>
<code>75248-1905</code>
<country>US</country>
</postal>

<phone>+1 214 733 2722</phone>
<facsimile>+1 214 733 2722</facsimile>
<email>Greg.Vaudreuil@Octel.com</email>
</address>
</author>

<date year="1995" month="August" />

<abstract>
<t>This memo defines two extensions to the SMTP service.  The first service enables a SMTP client and server to negotiate the use of an alternate DATA command "BDAT" for efficiently sending large MIME messages.  The second extension takes advantage of the BDAT command to permit the negotiated sending of unencoded binary data.</t>
</abstract>
</front>

<seriesInfo value="1830" name="RFC" />
</reference>


<reference target2="reference.RFC.1831.xml" anchor="RFC1831">
<front>
<title abbrev="Remote Procedure Call Protocol Version 2">RPC: Remote Procedure Call Protocol Specification Version 2</title>
<author fullname="Raj Srinivasan" initials="R." surname="Srinivasan">
<organization>Sun Microsystems, Inc., ONC Technologies</organization>

<address>
<postal>
<street>2550 Garcia Avenue</street>
<street>M/S MTV-5-40</street>
<city>Mountain View</city>
<region>CA</region>
<code>94043</code>
<country>US</country>
</postal>

<phone>+1 415 336 2478</phone>
<facsimile>+1 415 336 6015</facsimile>
<email>raj@eng.sun.com</email>
</address>
</author>

<date year="1995" month="August" />

<abstract>
<t>This document describes the ONC Remote Procedure Call (ONC RPC Version 2) protocol as it is currently deployed and accepted.  "ONC" stands for "Open Network Computing".</t>
</abstract>
</front>

<seriesInfo value="1831" name="RFC" />
</reference>


<reference target2="reference.RFC.1832.xml" anchor="RFC1832">
<front>
<title>XDR: External Data Representation Standard</title>
<author fullname="Raj Srinivasan" initials="R." surname="Srinivasan">
<organization>Sun Microsystems, Inc., ONC Technologies</organization>

<address>
<postal>
<street>2550 Garcia Avenue</street>
<street>M/S MTV-5-40</street>
<city>Mountain View</city>
<region>CA</region>
<code>94043</code>
<country>US</country>
</postal>

<phone>+1 415 336 2478</phone>
<facsimile>+1 415 336 6015</facsimile>
<email>raj@eng.sun.com</email>
</address>
</author>

<date year="1995" month="August" />

<abstract>
<t>This document describes the External Data Representation Standard (XDR) protocol as it is currently deployed and accepted.</t>
</abstract>
</front>

<seriesInfo value="1832" name="RFC" />
</reference>


<reference target2="reference.RFC.1833.xml" anchor="RFC1833">
<front>
<title>Binding Protocols for ONC RPC Version 2</title>
<author fullname="Raj Srinivasan" initials="R." surname="Srinivasan">
<organization>Sun Microsystems, Inc., ONC Technologies</organization>

<address>
<postal>
<street>2550 Garcia Avenue</street>
<street>M/S MTV-5-40</street>
<city>Mountain View</city>
<region>CA</region>
<code>94043</code>
<country>US</country>
</postal>

<phone>+1 415 336 2478</phone>
<facsimile>+1 415 336 6015</facsimile>
<email>raj@eng.sun.com</email>
</address>
</author>

<date year="1995" month="August" />

<abstract>
<t>This document describes the binding protocols used in conjunction with the ONC Remote Procedure Call (ONC RPC Version 2) protocols.</t>
</abstract>
</front>

<seriesInfo value="1833" name="RFC" />
</reference>


<reference target2="reference.RFC.1834.xml" anchor="RFC1834">
<front>
<title abbrev="Whois++ Lookup Service">Whois and Network Information Lookup Service, Whois++</title>
<author fullname="Joan Gargano" initials="J." surname="Gargano">
<organization>University of California, Davis,  Information Technology, Distributed Computing Analysis and Support</organization>

<address>
<postal>
<street />
<city>Davis</city>
<region>CA</region>
<code>95616</code>
<country>US</country>
</postal>

<email>jcgargano@ucdavis.edu</email>
</address>
</author>

<author fullname="Ken Weiss" initials="K." surname="Weiss">
<organization>University of California, Davis,  Information Technology, Distributed Computing Analysis and Support</organization>

<address>
<postal>
<street />
<city>Davis</city>
<region>CA</region>
<code>95616</code>
<country>US</country>
</postal>

<email>krweiss@ucdavis.edu</email>
</address>
</author>

<date year="1995" month="August" />

<abstract>
<t></t>
</abstract>
</front>

<seriesInfo value="1834" name="RFC" />
</reference>


<reference target2="reference.RFC.1835.xml" anchor="RFC1835">
<front>
<title>Architecture of the WHOIS++ service</title>
<author fullname="Peter Deutsch" initials="P." surname="Deutsch">
<organization>BUNYIP INFORMATION SYSTEMS, Inc.</organization>

<address>
<postal>
<street>310 St-Catherine St West,</street>
<street>Suite 202</street>
<city>Montreal</city>
<region>Quebec</region>
<code>H2X 2A1</code>
<country>CA</country>
</postal>

<email>peterd@bunyip.com</email>
</address>
</author>

<author fullname="Rickard Schoultz" initials="R." surname="Schoultz">
<organization>KTHNOC, SUNET/NORDUnet/Ebone Operations Centre</organization>

<address>
<postal>
<street>100 44 STOCKHOLM</street>
<country>SE</country>
</postal>

<email>schoultz@sunet.se</email>
</address>
</author>

<author fullname="Patrik Faltstrom" initials="P." surname="Faltstrom">
<organization>BUNYIP INFORMATION SYSTEMS, Inc.</organization>

<address>
<postal>
<street>310 St-Catherine St West</street>
<street>Suite 202</street>
<city>Montreal</city>
<region>Quebec</region>
<code>H2X 2A1</code>
<country>CA</country>
</postal>

<email>paf@bunyip.com</email>
</address>
</author>

<author fullname="Chris Weider" initials="C." surname="Weider">
<organization>BUNYIP INFORMATION SYSTEMS, Inc.</organization>

<address>
<postal>
<street>2001 S. Huron Parkway</street>
<street>#12</street>
<city>Ann Arbor</city>
<region>MI</region>
<code>48104</code>
<country>US</country>
</postal>

<email>clw@bunyip.com</email>
</address>
</author>

<date year="1995" month="August" />

<abstract>
<t>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.</t>
</abstract>
</front>

<seriesInfo value="1835" name="RFC" />
</reference>


<reference target2="reference.RFC.1836.xml" anchor="RFC1836">
<front>
<title abbrev="O/R Addresses in the X.500 DIT">Representing the O/R Address hierarchy in the X.500 Directory Information Tree</title>
<author fullname="Steve Kille" initials="S." surname="Kille">
<organization>ISODE Consortium</organization>

<address>
<postal>
<street>The Dome, The Square</street>
<city>Richmond</city>
<region>England</region>
<code>TW9 1DT</code>
<country>UK</country>
</postal>

<email>S.Kille@ISODE.COM</email>
</address>
</author>

<date year="1995" month="August" />

<abstract>
<t>This document defines a representation of the O/R Address hierarchy in the Directory Information Tree.  This is useful for a range of purposes, including:</t>

<t>o  Support for MHS Routing.</t>

<t>o  Support for X.400/RFC 822 address mappings,.</t>

<t><figure><artwork>Object Class               	Mandatory
--------------------               	----------------
mHSCountry					M
aDMD						M
pRMD						O
mHSX121					O
mHSNumericUserIdentifier	O
mHSOrganization			O
mHSOrganizationalUnit		O
mHSPerson					O
mHSNamedObject 			O
mHSTerminalID				O
mHSDomainDefinedAttribute	O</artwork>
</figure>
</t>
</abstract>
</front>

<seriesInfo value="1836" name="RFC" />
</reference>


<reference target2="reference.RFC.1837.xml" anchor="RFC1837">
<front>
<title abbrev="Representing Subtrees">Representing Tables and Subtrees in the X.500 Directory</title>
<author fullname="Steve Kille" initials="S." surname="Kille">
<organization>ISODE Consortium</organization>

<address>
<postal>
<street>The Dome, The Square</street>
<city>Richmond</city>
<region>England</region>
<code>TW9 1DT</code>
<country>UK</country>
</postal>

<phone>+44 81 3329091</phone>
<email>S.Kille@ISODE.COM</email>
</address>
</author>

<date year="1995" month="August" />

<abstract>
<t>This document defines techniques for representing two types of information mapping in the OSI Directory.</t>

<t>1.  Mapping from a key to a value (or set of values), as might be done in a table lookup.</t>

<t>2.  Mapping from a distinguished name to an associated value (or values), where the values are not defined by the owner of the entry.  This is achieved by use of a directory subtree.</t>

<t>These techniques were developed for supporting MHS use of Directory, but are specified separately as they have more general applicability.</t>
</abstract>
</front>

<seriesInfo value="1837" name="RFC" />
</reference>


<reference target2="reference.RFC.1838.xml" anchor="RFC1838">
<front>
<title abbrev="RFC 822/X.400 Mapping by X.500">Use of the X.500 Directory to support mapping between X.400 and RFC 822 Addresses</title>
<author fullname="Steve Kille" initials="S." surname="Kille">
<organization>ISODE Consortium</organization>

<address>
<postal>
<street>The Dome, The Square</street>
<city>Richmond</city>
<region>England</region>
<code>TW9 1DT</code>
<country>UK</country>
</postal>

<phone>+44 81 3329091</phone>
<email>S.Kille@ISODE.COM</email>
</address>
</author>

<date year="1995" month="August" />

<abstract>
<t>This document defines how to use directory to support the mapping between X.400 O/R Addresses and mailboxes defined in RFC 1327.</t>
</abstract>
</front>

<seriesInfo value="1838" name="RFC" />
</reference>


<reference target2="reference.RFC.1841.xml" anchor="RFC1841">
<front>
<title>PPP Network Control Protocol for LAN Extension</title>
<author fullname="Joelle Bafile Chapman" initials="J." surname="Chapman">
<organization>Cisco Systems, Inc.</organization>

<address>
<postal>
<street>170 West Tasman Drive</street>
<city>San Jose</city>
<region>CA</region>
<code>95134-1706</code>
<country>US</country>
</postal>

<email>joelle@cisco.com</email>
</address>
</author>

<author fullname="Dave Coli" initials="D." surname="Coli">
<organization>Cisco Systems, Inc.</organization>

<address>
<postal>
<street>170 West Tasman Drive</street>
<city>San Jose</city>
<region>CA</region>
<code>95134-1706</code>
<country>US</country>
</postal>

<email>dcoli@cisco.com</email>
</address>
</author>

<author fullname="Andy Harvey" initials="A." surname="Harvey">
<organization>Cisco Systems, Inc.</organization>

<address>
<postal>
<street>170 West Tasman Drive</street>
<city>San Jose</city>
<region>CA</region>
<code>95134-1706</code>
<country>US</country>
</postal>

<email>agh@cisco.com</email>
</address>
</author>

<author fullname="Bent Jensen" initials="B." surname="Jensen">
<organization>Cisco Systems, Inc.</organization>

<address>
<postal>
<street>170 West Tasman Drive</street>
<city>San Jose</city>
<region>CA</region>
<code>95134-1706</code>
<country>US</country>
</postal>

<email>bent@cisco.com</email>
</address>
</author>

<author fullname="Kevin Rowett" initials="K." surname="Rowett">
<organization>Cisco Systems, Inc.</organization>

<address>
<postal>
<street>170 West Tasman Drive</street>
<city>San Jose</city>
<region>CA</region>
<code>95134-1706</code>
<country>US</country>
</postal>

<email>krowett@cisco.com</email>
</address>
</author>

<date year="1995" month="September" />

<abstract>
<t>Telecommunications infrastructure is improving to offer higher bandwidth connections at lower cost. Access to the network is changing from modems to more intelligent devices. This informational RFC discusses a PPP Network Control Protocol for one such intelligent device. The protocol is the LAN extension interface protocol.</t>
</abstract>
</front>

<seriesInfo value="1841" name="RFC" />
</reference>


<reference target2="reference.RFC.1842.xml" anchor="RFC1842">
<front>
<title abbrev="ASCII/Chinese Character Encoding">ASCII Printable Characters-Based Chinese Character Encoding for Internet Messages</title>
<author fullname="Ya-Gui Wei" initials="Y." surname="Wei">
<organization>AsiaInfo Services Inc.</organization>

<address>
<postal>
<street>One Galleria Tower</street>
<street>13355 Noel Rd. Suite 1340</street>
<city>Dallas</city>
<region>TX</region>
<code>75240</code>
<country>US</country>
</postal>

<phone>+1 214 788 4141</phone>
<facsimile>+1 214 788 0729</facsimile>
<email>HZRFC@usai.asiainfo.com</email>
</address>
</author>

<author fullname="Yun Fei Zhang" initials="Y." surname="Zhang">
<organization>Harvard University, CfA</organization>

<address>
<postal>
<street>60 Garden St.</street>
<street>MS 66</street>
<city>Cambridge</city>
<region>MA</region>
<code>02138</code>
<country>US</country>
</postal>

<phone>+1 617 860 9444</phone>
<email>zhang@orion.harvard.edu</email>
</address>
</author>

<author fullname="Jian Q. Li" initials="J." surname="Li">
<organization>Rice University</organization>

<address>
<postal>
<street>P.O. Box 1892</street>
<street>ONS - MS 119</street>
<city>Houston</city>
<region>TX</region>
<code>77251-1892</code>
<country>US</country>
</postal>

<phone>+1 713 285 5328</phone>
<email>jian@is.rice.edu</email>
</address>
</author>

<author fullname="Jian Ding" initials="J." surname="Ding">
<organization>AsiaInfo Services Inc.</organization>

<address>
<postal>
<street>15 Fuxing Road,  ISTIC Bldg</street>
<street>Room 431</street>
<city>Beijing</city>
<region />
<code>100038</code>
<country>CN</country>
</postal>

<phone>+86 10 8537120</phone>
<facsimile>+86 10 8537123</facsimile>
<email>ding@Beijing.AsiaInfo.com</email>
</address>
</author>

<author fullname="Yuan Jiang" initials="Y." surname="Jiang">
<organization>University of Maryland, Electrical Engineering Department</organization>

<address>
<postal>
<street />
<city>College Park</city>
<region>MD</region>
<code>200742</code>
<country>US</country>
</postal>

<phone>+1 301 405 3729</phone>
<email>yjj@eng.umd.edu</email>
</address>
</author>

<date year="1995" month="August" />

<abstract>
<t>This document describes the encoding used in electronic mailand network newsmessages over the Internet. The 7-bit representation of GB 2312 Chinese text was specified by Fung Fung Lee of Stanford Universityand implemented in various software packages under different platforms (see appendix for a partial list of the available software packages that support this encoding method). It is further tested and used in the usenet newsgroups alt.chinese.text and chinese.* as well as various other network forums with considerable success. Future extensions of this encoding method can accommodate additional GB character sets and other east    asian language character sets.</t>

<t>The name given to this encoding is "HZ-GB-2312", which is intended to be used in the "charset" parameter field of MIME headers (seeand).</t>
</abstract>
</front>

<seriesInfo value="1842" name="RFC" />
</reference>


<reference target2="reference.RFC.1843.xml" anchor="RFC1843">
<front>
<title abbrev="HZ - A Data Format for Exchanging Files">HZ - A Data Format for Exchanging Files of Arbitrarily Mixed Chinese and ASCII characters</title>
<author fullname="Fung Fung Lee" initials="F." surname="Lee">
<organization>Stanford University, Computer Systems Laboratory</organization>

<address>
<postal>
<street />
<city>Stanford</city>
<region>CA</region>
<code>94309</code>
<country>US</country>
</postal>

<phone>+1 415 723 1450</phone>
<email>lee@csl.stanford.edu</email>
</address>
</author>

<date year="1995" month="August" />

<abstract>
<t>The content of this memo is identical to an article of the same title written by the author on September 4, 1989.  In this memo, GB stands for GB2312-80.  Note that the title is kept only for historical reasons.  HZ has been widely used for purposes other than "file exchange".</t>
</abstract>
</front>

<seriesInfo value="1843" name="RFC" />
</reference>


<reference target2="reference.RFC.1844.xml" anchor="RFC1844">
<front>
<title abbrev="MIME User Agent Checklist">Multimedia E-mail (MIME) User Agent Checklist</title>
<author fullname="Erik Huizer" initials="E." surname="Huizer">
<organization>SURFnet bv</organization>

<address>
<postal>
<street>P.O. Box 19035</street>
<city>Utrecht</city>
<region />
<code>3501 DA</code>
<country>NL</country>
</postal>

<phone>+31 30 305305</phone>
<facsimile>+31 30 305329</facsimile>
<email>Erik.Huizer@SURFnet.nl</email>
</address>
</author>

<date year="1995" month="August" />

<abstract>
<t>This document presents a checklist to facilitate evaluation of MIME capable User Agents. Access to a MIME test-responder, that generates test-messages is described.</t>
</abstract>
</front>

<seriesInfo value="1844" name="RFC" />
</reference>


<reference target2="reference.RFC.1845.xml" anchor="RFC1845">
<front>
<title abbrev="SMTP Checkpoint/Restart">SMTP Service Extension for Checkpoint/Restart</title>
<author fullname="Dave Crocker" initials="D." surname="Crocker">
<organization>Brandenburg Consulting</organization>

<address>
<postal>
<street>675 Spruce Dr.</street>
<city>Sunnyvale</city>
<region>CA</region>
<code>94086</code>
<country>US</country>
</postal>

<phone>+1 408 246 8253</phone>
<facsimile>+1 408 249 6205</facsimile>
<email>dcrocker@mordor.stanford.edu</email>
</address>
</author>

<author fullname="Ned Freed" initials="N." surname="Freed">
<organization>Innosoft International, Inc.</organization>

<address>
<postal>
<street>1050 East Garvey Avenue South</street>
<city>West Covina</city>
<region>CA</region>
<code>91790</code>
<country>US</country>
</postal>

<phone>+1 818 919 3600</phone>
<facsimile>+1 818 919 3614</facsimile>
<email>ned@innosoft.com</email>
</address>
</author>

<date year="1995" month="September" />

<abstract>
<t>This memo defines an extension to the SMTP service whereby an interrupted SMTP transaction can be restarted at a later time without having to repeat all of the commands and message content sent prior to the interruption.</t>
</abstract>
</front>

<seriesInfo value="1845" name="RFC" />
</reference>


<reference target2="reference.RFC.1846.xml" anchor="RFC1846">
<front>
<title>SMTP 521 Reply Code</title>
<author fullname="Alain Durand" initials="A." surname="Durand">
<organization>Institut de Mathematiques Appliquees de Grenoble (IMAG)</organization>

<address>
<postal>
<street>BP 53 38041 Grenoble</street>
<street>CEDEX 9</street>
<region />
<code />
<country>FR</country>
</postal>

<phone>+33 76 635703</phone>
<facsimile>+33 76 446675</facsimile>
<email>Alain.Durand@imag.fr</email>
</address>
</author>

<author fullname="Francis Dupont" initials="F." surname="Dupont">
<organization>Institut National de Recherche en Informatique et en Automatique</organization>

<address>
<postal>
<street>B.P. 105 / 78153 Le Chesnay</street>
<street>CEDEX</street>
<region />
<code />
<country>FR</country>
</postal>

<phone>+33 1 39635213</phone>
<facsimile>+33 1 39635330</facsimile>
<email>Francis.Dupont@inria.fr</email>
</address>
</author>

<date year="1995" month="September" />

<abstract>
<t>This memo defines a new Simple Mail Transfer Protocol (SMTP)reply code, 521, which one may use to indicate that an Internet host does not accept incoming mail.</t>
</abstract>
</front>

<seriesInfo value="1846" name="RFC" />
</reference>


<reference target2="reference.RFC.1847.xml" anchor="RFC1847">
<front>
<title abbrev="Security Multiparts">Security Multiparts for MIME: Multipart/Signed and Multipart/Encrypted</title>
<author fullname="Jim Galvin" initials="J." surname="Galvin">
<organization>Trusted Information Systems</organization>

<address>
<postal>
<street>3060 Washington Road</street>
<city>Glenwood</city>
<region>MD</region>
<code>21738</code>
<country>US</country>
</postal>

<phone>+1 301 854 6889</phone>
<facsimile>+1 301 854 5363</facsimile>
<email>galvin@tis.com</email>
</address>
</author>

<author fullname="Sandy Murphy" initials="S." surname="Murphy">
<organization>Trusted Information Systems</organization>

<address>
<postal>
<street>3060 Washington Road</street>
<city>Glenwood</city>
<region>MD</region>
<code>21738</code>
<country>US</country>
</postal>

<phone>+1 301 854 6889</phone>
<facsimile>+1 301 854 5363</facsimile>
<email>sandy@tis.com</email>
</address>
</author>

<author fullname="Steve Crocker" initials="S." surname="Crocker">
<organization>CyberCash, Inc.</organization>

<address>
<postal>
<street>2086 Hunters Crest Way</street>
<city>Vienna</city>
<region>VA</region>
<code>22181</code>
<country>US</country>
</postal>

<phone>+1 703 620 1222</phone>
<facsimile>+1 703 391 2651</facsimile>
<email>crocker@cybercash.com</email>
</address>
</author>

<author fullname="Ned Freed" initials="N." surname="Freed">
<organization>Innosoft International, Inc.</organization>

<address>
<postal>
<street>1050 East Garvey Avenue South</street>
<city>West Covina</city>
<region>CA</region>
<code>91790</code>
<country>US</country>
</postal>

<phone>+1 818 919 3600</phone>
<facsimile>+1 818 919 3614</facsimile>
<email>ned@innosoft.com</email>
</address>
</author>

<date year="1995" month="October" />

<abstract>
<t>This document defines a framework within which security services may be applied to MIME body parts.  MIME, an acronym for "Multipurpose Internet Mail Extensions", defines the format of the contents of Internet mail messages and provides for multi-part textual and non-textual message bodies.  The new content types are subtypes of multipart: signed and encrypted.  Each will contain two body parts: one for the protected data and one for the control information necessary to remove the protection.  The type and contents of the control information body parts are determined by the value of the protocol parameter of the enclosing multipart/signed or multipart/encrypted content type, which is required to be present.</t>
</abstract>
</front>

<seriesInfo value="1847" name="RFC" />
</reference>


<reference target2="reference.RFC.1848.xml" anchor="RFC1848">
<front>
<title>MIME Object Security Services</title>
<author fullname="Steve Crocker" initials="S." surname="Crocker">
<organization>CyberCash, Inc.</organization>

<address>
<postal>
<street>2086 Hunters Crest Way</street>
<city>Vienna</city>
<region>VA</region>
<code>22181</code>
<country>US</country>
</postal>

<phone>+1 703 620 1222</phone>
<facsimile>+1 703 391 2651</facsimile>
<email>crocker@cybercash.com</email>
</address>
</author>

<author fullname="James M. Galvin" initials="J." surname="Galvin">
<organization>Trusted Information Systems</organization>

<address>
<postal>
<street>3060 Washington Road</street>
<city>Glenwood</city>
<region>MD</region>
<code>21738</code>
<country>US</country>
</postal>

<phone>+1 301 854 6889</phone>
<facsimile>+1 301 854 5363</facsimile>
<email>galvin@tis.com</email>
</address>
</author>

<author fullname="Sandra Murphy" initials="S." surname="Murphy">
<organization>Trusted Information Systems</organization>

<address>
<postal>
<street>3060 Washington Road</street>
<city>Glenwood</city>
<region>MD</region>
<code>21738</code>
<country>US</country>
</postal>

<phone>+1 301 854 6889</phone>
<facsimile>+1 301 854 5363</facsimile>
<email>murphy@tis.com</email>
</address>
</author>

<author fullname="Ned Freed" initials="N." surname="Freed">
<organization>Innosoft International, Inc.</organization>

<address>
<postal>
<street>1050 East Garvey Avenue South</street>
<city>West Covina</city>
<region>CA</region>
<code>91790</code>
<country>US</country>
</postal>

<phone>+1 818 919 3600</phone>
<facsimile>+1 818 919 3614</facsimile>
<email>ned@innosoft.com</email>
</address>
</author>

<date year="1995" month="October" />

<abstract>
<t>This document defines MIME Object Security Services (MOSS), a protocol that uses the multipart/signed and multipart/encrypted frameworkto apply digital signature and encryption services to MIME objects.  The services are offered through the use of end-to-end cryptography between an originator and a recipient at the application layer.  Asymmetric (public key) cryptography is used in support of the digital signature service and encryption key management. Symmetric (secret key) cryptography is used in support of the encryption service.  The procedures are intended to be compatible with a wide range of public key management approaches, including both ad hoc and certificate-based schemes.  Mechanisms are provided to support many public key management approaches.</t>
</abstract>
</front>

<seriesInfo value="1848" name="RFC" />
</reference>


<reference target2="reference.RFC.1850.xml" anchor="RFC1850">
<front>
<title abbrev="OSPF MIB">OSPF Version 2 Management Information Base</title>
<author fullname="Fred Baker" initials="F." surname="Baker">
<organization>cisco Systems, Inc.</organization>

<address>
<postal>
<street>519 Lado Drive</street>
<city>Santa Barbara</city>
<region>CA</region>
<code>93111</code>
<country>US</country>
</postal>

<phone>+1 805 681 0115</phone>
<email>fred@cisco.com</email>
</address>
</author>

<author fullname="Rob Coltun" initials="R." surname="Coltun">
<organization>RainbowBridge Communications</organization>

<address>
<phone>+1 301 340 9416</phone>
<email>rcoltun@rainbow-bridge.com</email>
</address>
</author>

<date year="1995" month="November" />

<abstract>
<t>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 Open Shortest Path First Routing Protocol.</t>
</abstract>
</front>

<seriesInfo value="1850" name="RFC" />
</reference>


<reference target2="reference.RFC.1851.xml" anchor="RFC1851">
<front>
<title abbrev="ESP 3DES">The ESP Triple DES Transform</title>
<author fullname="Phil Karn" initials="P." surname="Karn">
<organization>Qualcomm, Inc.</organization>

<address>
<postal>
<street>6455 Lusk Blvd.</street>
<city>San Diego</city>
<region>CA</region>
<code>92121-2779</code>
<country>US</country>
</postal>

<email>karn@unix.ka9q.ampr.org</email>
</address>
</author>

<author fullname="Perry Metzger" initials="P." surname="Metzger">
<organization>Piermont Information Systems Inc.</organization>

<address>
<postal>
<street>160 Cabrini Blvd.</street>
<street>Suite #2</street>
<city>New York</city>
<region>NY</region>
<code>10033</code>
<country>US</country>
</postal>

<email>perry@piermont.com</email>
</address>
</author>

<author fullname="William Allen Simpson" initials="W." surname="Simpson">
<organization>Daydreamer, Computer Systems Consulting Services</organization>

<address>
<postal>
<street>1384 Fontaine</street>
<city>Madison Heights</city>
<region>MI</region>
<code>48071</code>
<country>US</country>
</postal>

<email>Bill.Simpson@um.cc.umich.edu</email>
</address>
</author>

<date year="1995" month="September" />

<abstract>
<t>This document describes the Triple DES-CBC security transform for the IP Encapsulating Security Payload (ESP).</t>
</abstract>
</front>

<seriesInfo value="1851" name="RFC" />
</reference>


<reference target2="reference.RFC.1852.xml" anchor="RFC1852">
<front>
<title abbrev="AH SHA">IP Authentication using Keyed SHA</title>
<author fullname="Perry Metzger" initials="P." surname="Metzger">
<organization>Piermont Information Systems Inc.</organization>

<address>
<postal>
<street>160 Cabrini Blvd.</street>
<street>Suite #2</street>
<city>New York</city>
<region>NY</region>
<code>10033</code>
<country>US</country>
</postal>

<email>perry@piermont.com</email>
</address>
</author>

<author fullname="William Allen Simpson" initials="W." surname="Simpson">
<organization>Daydreamer, Computer Systems Consulting Services</organization>

<address>
<postal>
<street>1384 Fontaine</street>
<city>Madison Heights</city>
<region>MI</region>
<code>48071</code>
<country>US</country>
</postal>

<email>Bill.Simpson@um.cc.umich.edu</email>
</address>
</author>

<date year="1995" month="September" />

<abstract>
<t>This document describes the use of keyed SHA with the IP Authentication Header.</t>
</abstract>
</front>

<seriesInfo value="1852" name="RFC" />
</reference>


<reference target2="reference.RFC.1853.xml" anchor="RFC1853">
<front>
<title abbrev="IP Tunnelling">IP in IP Tunneling</title>
<author fullname="William Allen Simpson" initials="W." surname="Simpson">
<organization>Daydreamer, Computer Systems Consulting Services</organization>

<address>
<postal>
<street>1384 Fontaine</street>
<city>Madison Heights</city>
<region>MI</region>
<code>48071</code>
<country>US</country>
</postal>

<email>Bill.Simpson@um.cc.umich.edu</email>
</address>
</author>

<date year="1995" month="October" />

<abstract>
<t>This document discusses implementation techniques for using IP Protocol/Payload number 4 Encapsulation for tunneling with IP Security and other protocols.</t>
</abstract>
</front>

<seriesInfo value="1853" name="RFC" />
</reference>


<reference target2="reference.RFC.1854.xml" anchor="RFC1854">
<front>
<title abbrev="SMTP Pipelining">SMTP Service Extension for Command Pipelining</title>
<author fullname="Ned Freed" initials="N." surname="Freed">
<organization>Innosoft International, Inc.</organization>

<address>
<postal>
<street>1050 East Garvey Avenue South</street>
<city>West Covina</city>
<region>CA</region>
<code>91790</code>
<country>US</country>
</postal>

<phone>+1 818 919 3600</phone>
<facsimile>+1 818 919 3614</facsimile>
<email>ned@innosoft.com</email>
</address>
</author>

<date year="1995" month="October" />

<abstract>
<t>This memo defines an extension to the SMTP service whereby a server can indicate the extent of its ability to accept multiple commands in a single TCP send operation. Using a single TCP send operation for multiple commands can improve SMTP performance significantly.</t>
</abstract>
</front>

<seriesInfo value="1854" name="RFC" />
</reference>


<reference target2="reference.RFC.1855.xml" anchor="RFC1855">
<front>
<title>Netiquette Guidelines</title>
<author fullname="Sally Hambridge" initials="S." surname="Hambridge">
<organization>Intel Corporation</organization>

<address>
<postal>
<street>2880 Northwestern Parkway</street>
<street>SC3-15</street>
<city>Santa Clara</city>
<region>CA</region>
<code>95052</code>
<country>US</country>
</postal>

<phone>+1 408 765 2931</phone>
<facsimile>+1 408 765 3679</facsimile>
<email>sallyh@ludwig.sc.intel.com</email>
</address>
</author>

<date year="1995" month="October" />

<abstract>
<t>This document provides a minimum set of guidelines for Network Etiquette (Netiquette) which organizations may take and adapt for their own use.  As such, it is deliberately written in a bulleted format to make adaptation easier and to make any particular item easy (or easier) to find.  It also functions as a minimum set of guidelines for individuals, both users and administrators.  This memo is the product of the Responsible Use of the Network (RUN) Working Group of the IETF.</t>
</abstract>
</front>

<seriesInfo value="1855" name="RFC" />
</reference>


<reference target2="reference.RFC.1856.xml" anchor="RFC1856">
<front>
<title abbrev="Opstat Client-Server Model">The Opstat Client-Server Model for Statistics Retrieval</title>
<author fullname="Henry Clark" initials="H." surname="Clark">
<organization>BBN Planet Corp.</organization>

<address>
<postal>
<street>150 Cambridge Park Dr.</street>
<city>Cambridge</city>
<region>MA</region>
<code>02140</code>
<country>US</country>
</postal>

<phone>+1 617 873 4622</phone>
<email>henryc@bbnplanet.com</email>
</address>
</author>

<date year="1995" month="September" />

<abstract>
<t>Network administrators gather data related to the performance, utilization, usability and growth of their data network.  The amount of raw data gathered is usually quite large, typically ranging somewhere between several megabytes to several gigabytes of data each month.  Few (if any) tools exist today for the sharing of that raw data among network operators or between a network service provider (NSP) and its customers.  This document defines a model and protocol for a set of tools which could be used by NSPs and Network Operation Centers (NOCs) to share data among themselves and with customers.</t>
</abstract>
</front>

<seriesInfo value="1856" name="RFC" />
</reference>


<reference target2="reference.RFC.1857.xml" anchor="RFC1857">
<front>
<title abbrev="Operational Statistics">A Model for Common Operational Statistics</title>
<author fullname="Michael H. Lambert" initials="M." surname="Lambert">
<organization>Pittsburgh Supercomputing Center</organization>

<address>
<postal>
<street>4400 Fifth Avenue</street>
<city>Pittsburgh</city>
<region>PA</region>
<code>15213</code>
<country>US</country>
</postal>

<phone>+1 412 268 4960</phone>
<facsimile>+1 412 268 8200</facsimile>
<email>lambert@psc.edu</email>
</address>
</author>

<date year="1995" month="October" />

<abstract>
<t>This memo describes a model for operational statistics in the Internet.  It gives recommendations for metrics, measurements, polling periods and presentation formats and defines a format for the exchange of operational statistics.</t>
</abstract>
</front>

<seriesInfo value="1857" name="RFC" />
</reference>


<reference target2="reference.RFC.1858.xml" anchor="RFC1858">
<front>
<title>Security Considerations for IP Fragment Filtering</title>
<author fullname="G. Paul Ziemba" initials="G." surname="Ziemba">
<organization>Alantec</organization>

<address>
<postal>
<street>2115 O'Nel Drive</street>
<city>San Jose</city>
<region>CA</region>
<code>95131</code>
<country>US</country>
</postal>

<email>paul@alantec.com</email>
</address>
</author>

<author fullname="Darren Reed" initials="D." surname="Reed">
<organization>Cybersource</organization>

<address>
<postal>
<street>1275A Malvern Rd</street>
<city>Melbourne</city>
<region>Victoria</region>
<code>3144</code>
<country>AU</country>
</postal>

<email>darrenr@cyber.com.au</email>
</address>
</author>

<author fullname="Paul Traina" initials="P." surname="Traina">
<organization>cisco Systems, Inc.</organization>

<address>
<postal>
<street>170 W. Tasman Dr.</street>
<city>San Jose</city>
<region>CA</region>
<code>95028</code>
<country>US</country>
</postal>

<email>pst@cisco.com</email>
</address>
</author>

<date year="1995" month="October" />

<abstract>
<t>IP fragmentation can be used to disguise TCP packets from IP filters used in routers and hosts. This document describes two methods of attack as well as remedies to prevent them.</t>
</abstract>
</front>

<seriesInfo value="1858" name="RFC" />
</reference>


<reference target2="reference.RFC.1859.xml" anchor="RFC1859">
<front>
<title abbrev="ISO Transport and Flow Control">ISO Transport Class 2 Non-use of Explicit Flow Control over TCP RFC1006 extension</title>
<author fullname="Yanick Pouffary" initials="Y." surname="Pouffary">
<organization>Digital Equipment Corporation, End Systems Networking,  Centre Technique (Europe)</organization>

<address>
<postal>
<street>950 Routes des colles</street>
<street>B.P. 027</street>
<city>Sophia antipolis</city>
<region />
<code>06901</code>
<country>FR</country>
</postal>

<phone>+33 92 956285</phone>
<facsimile>+33 92 956232</facsimile>
<email>pouffary@taec.enet.dec.com</email>
</address>
</author>

<date year="1995" month="October" />
</front>

<seriesInfo value="1859" name="RFC" />
</reference>


<reference target2="reference.RFC.1860.xml" anchor="RFC1860">
<front>
<title abbrev="Subnet Table">Variable Length Subnet Table For IPv4</title>
<author fullname="Troy Pummill" initials="T." surname="Pummill">
<organization />

<address>
<email>trop@alantec.com</email>
</address>
</author>

<author fullname="Bill Manning" initials="B." surname="Manning">
<organization>University of Southern California, Information Sciences Institute</organization>

<address>
<postal>
<street>4676 Admiralty Way</street>
<city>Marina del Rey</city>
<region>CA</region>
<code>90292-6695</code>
<country>US</country>
</postal>

<phone>+1 310 822 1511 x387</phone>
<facsimile>+1 310 823 6714</facsimile>
<email>bmanning@isi.edu</email>
</address>
</author>

<date year="1995" month="October" />

<abstract>
<t>This document itemizes the potential values for IPv4 subnets.  Additional information is provided for Hex and Decmial values, classfull equivalents, and number of addresses available within the indicated block. We appreciate inputs from Bruce Pinsky (cisco) and Daniel Karrenberg (RIPE).</t>
</abstract>
</front>

<seriesInfo value="1860" name="RFC" />
</reference>


<reference target2="reference.RFC.1861.xml" anchor="RFC1861">
<front>
<title abbrev="SNPP - Version 3">Simple Network Paging Protocol - Version 3 -Two-Way Enhanced</title>
<author fullname="R. Allen Gwinn, Jr." initials="R." surname="Gwinn">
<organization>Southern Methodist University, Computing Services, Business Information Center</organization>

<address>
<postal>
<street />
<city>Dallas</city>
<region>TX</region>
<code>75275</code>
<country>US</country>
</postal>

<phone>+1 214 768 3186</phone>
<email>allen@mail.cox.smu.edu</email>
</address>
</author>

<date year="1995" month="October" />

<abstract>
<t>This RFC suggests a simple way for delivering wireless messages, both one and two-way, to appropriate receiving devices.  In its simplest form, SNPP provides a simple way to implement a "shim" between the Internet and a TAP/IXO paging terminal. In its level 3 form, it provides an easy-to-use (and build) method for communicating and receiving end-to-end acknowledgments and replies from two-way messaging devices (such as ReFLEX units).</t>

<t>Gateways supporting this protocol, as well as SMTP, have been in use for well over a year at several commercial paging companies, and private businesses.  Client software supporting this protocol has become widespread, and is being integrated into many of the new paging and messaging products being built.  In addition to commercial software, email filters and SNPP client software for Unix and Windows (WikiPage) are available at no cost.  Please contact the author for more information.</t>

<t>Earlier versions of this specification were reviewed by IESG members and the "822 Extensions" Working Group.  They preferred an alternate strategy, as discussed under "Relationship to Other IETF Work",
   below.</t>
</abstract>
</front>

<seriesInfo value="1861" name="RFC" />
</reference>


<reference target2="reference.RFC.1862.xml" anchor="RFC1862">
<front>
<title abbrev="IAB Workshop Report">Report of the IAB Workshop on Internet Information Infrastructure, October 12-14, 1994</title>
<author fullname="Mark McCahill" initials="M." surname="McCahill">
<organization>University of Minnesota, Shepherd Labs</organization>

<address>
<postal>
<street>100 Union Street SE</street>
<street>room 190</street>
<city>Minneapolis</city>
<region>MN</region>
<code>55455</code>
<country>US</country>
</postal>

<email>mpm@boombox.micro.umn.edu</email>
</address>
</author>

<author fullname="John Romkey" initials="J." surname="Romkey">
<organization />

<address>
<postal>
<street>1770 Massachusetts Ave. #331</street>
<city>Cambridge</city>
<region>MA</region>
<code>02140</code>
<country>US</country>
</postal>

<email>romkey@apocalypse.org</email>
</address>
</author>

<author fullname="Michael F.  Schwartz" initials="M." surname="Schwartz">
<organization>University of Colorado, Department of Computer Science</organization>

<address>
<postal>
<street />
<city>Boulder</city>
<region>CO</region>
<code>80309-0430</code>
<country>US</country>
</postal>

<email>schwartz@cs.colorado.edu</email>
</address>
</author>

<author fullname="Karen Sollins" initials="K." surname="Sollins">
<organization>MIT Laboratory for Computer Science</organization>

<address>
<postal>
<street>545 Technology Square</street>
<city>Cambridge</city>
<region>MA</region>
<code>02139-1986</code>
<country>US</country>
</postal>

<email>sollins@lcs.mit.edu</email>
</address>
</author>

<author fullname="Ton Verschuren" initials="T." surname="Verschuren">
<organization>SURFNet</organization>

<address>
<postal>
<street>P.O. Box 19035</street>
<street>3501 DA Utrecht</street>
<country>NL</country>
</postal>

<email>Ton.Verschuren@surfnet.nl</email>
</address>
</author>

<author fullname="Chris Weider" initials="C." surname="Weider">
<organization>Bunyip Information Systems</organization>

<address>
<postal>
<street>310 St. Catherine St. West</street>
<street>Suite 300</street>
<city>Montreal</city>
<region>Quebec</region>
<code>H2A 2X1</code>
<country>CA</country>
</postal>

<email>clw@bunyip.com</email>
</address>
</author>

<date year="1995" month="November" />

<abstract>
<t>This document is a report on an Internet architecture workshop, initiated by the IAB and held at MCI on October 12-14, 1994.  This workshop generally focused on aspects of the information infrastructure on the Internet.</t>
</abstract>
</front>

<seriesInfo value="1862" name="RFC" />
</reference>


<reference target2="reference.RFC.1863.xml" anchor="RFC1863">
<front>
<title abbrev="A BGP/IDRP Route Server">A BGP/IDRP Route Server alternative to a full mesh routing</title>
<author fullname="Dimitry Haskin" initials="D." surname="Haskin">
<organization>Bay Networks, Inc.</organization>

<address>
<postal>
<street>2 Federal Street</street>
<city>Billerica</city>
<region>MA</region>
<code>01821</code>
<country>US</country>
</postal>

<email>dhaskin@baynetworks.com</email>
</address>
</author>

<date year="1995" month="October" />

<abstract>
<t>This document describes the use and detailed design of Route Servers for dissemination of routing information among BGP/IDRP speaking routers.</t>

<t>The intention of the proposed technique is to reduce overhead and management complexity of maintaining numerous direct BGP/IDRP sessions which otherwise might be required or desired among routers within a single routing domain as well as among routers in different domains that are connected to a common switched fabric (e.g. an ATM cloud).</t>
</abstract>
</front>

<seriesInfo value="1863" name="RFC" />
</reference>


<reference target2="reference.RFC.1864.xml" anchor="RFC1864">
<front>
<title abbrev="Content-MD5 Header Field">The Content-MD5 Header Field</title>
<author fullname="John G. Myers" initials="J." surname="Myers">
<organization>Carnegie Mellon University</organization>

<address>
<email>jgm+@cmu.edu</email>
</address>
</author>

<author fullname="Marshall T. Rose" initials="M." surname="Rose">
<organization>Dover Beach Consulting, Inc.</organization>

<address>
<email>mrose@dbc.mtview.ca.us</email>
</address>
</author>

<date year="1995" month="October" />

<abstract>
<t>This memo specifies an optional header field, Content-MD5, for use with MIME-conformant messages.</t>
</abstract>
</front>

<seriesInfo value="1864" name="RFC" />
</reference>


<reference target2="reference.RFC.1865.xml" anchor="RFC1865">
<front>
<title abbrev="EDI Meets the Internet">EDI Meets the Internet Frequently Asked Questions about Electronic Data Interchange (EDI) on the Internet</title>
<author fullname="Walter Houser" initials="W." surname="Houser">
<organization>Department of Veterans Affairs</organization>

<address>
<postal>
<street>810 Vermont Avenue</street>
<city>Washington</city>
<region>DC</region>
<code>20240</code>
<country>US</country>
</postal>

<phone>+1 202 786 9572</phone>
<email>houser.walt@forum.va.gov</email>
<uri>http://www.va.gov/</uri>
</address>
</author>

<author fullname="James A. (Artch) Griffin" initials="J.A." surname="Griffin">
<organization>Athena Associates</organization>

<address>
<postal>
<street>18924 High Point Drive</street>
<city>Gaithersburg</city>
<region>MD</region>
<code>20879</code>
<country>US</country>
</postal>

<phone>+1 301 972 2502</phone>
<email>agriffin@cpcug.org</email>
</address>
</author>

<author fullname="Carl Hage" initials="C." surname="Hage">
<organization>C. Hage Associates</organization>

<address>
<postal>
<street>1180 Reed Ave</street>
<street>#51</street>
<city>Sunnyvale</city>
<region>CA</region>
<code>94086</code>
<country>US</country>
</postal>

<email>carl@chage.com</email>
<uri>http://www.chage.com/chage/</uri>
</address>
</author>

<date year="1996" month="January" />

<abstract>
<t>This memo is targeted towards the EDI community that is unfamiliar with the Internet, including EDI software developers, users, and service providers.  The memo introduces the Internet and assumes a basic knowledge of EDI.</t>
</abstract>
</front>

<seriesInfo value="1865" name="RFC" />
</reference>


<reference target2="reference.RFC.1866.xml" anchor="RFC1866">
<front>
<title>Hypertext Markup Language - 2.0</title>
<author fullname="Tim Berners-Lee" initials="T." surname="Berners-Lee">
<organization>MIT Laboratory for Computer Science</organization>

<address>
<postal>
<street>545 Technology Square</street>
<city>Cambridge</city>
<region>MA</region>
<code>02139</code>
<country>US</country>
</postal>

<phone>+1 617 253 9670</phone>
<facsimile>+1 617 258 8682</facsimile>
<email>timbl@w3.org</email>
</address>
</author>

<author fullname="Daniel W. Connolly" initials="D.W." surname="Connolly">
<organization>MIT Laboratory for Computer Science, W3 Consortium</organization>

<address>
<postal>
<street>545 Technology Square</street>
<city>Cambridge</city>
<region>MA</region>
<code>02139</code>
<country>US</country>
</postal>

<phone>+1 617 258 8682</phone>
<email>connolly@w3.org</email>
<uri>http://www.w3.org/hypertext/WWW/People/Connolly/</uri>
</address>
</author>

<date year="1995" month="November" />

<abstract>
<t>The Hypertext Markup Language (HTML) is a simple markup language used to create hypertext documents that are platform independent. HTML documents are SGML documents with generic semantics that are appropriate for representing information from a wide range of domains. HTML markup can represent hypertext news, mail, documentation, and hypermedia; menus of options; database query results; simple structured documents with in-lined graphics; and hypertext views of existing bodies of information.</t>

<t>HTML has been in use by the World Wide Web (WWW) global information initiative since 1990. This specification roughly corresponds to the capabilities of HTML in common use prior to June 1994. HTML is an application of ISO Standard 8879:1986 Information Processing Text and Office Systems; Standard Generalized Markup Language (SGML).</t>

<t>The "text/html" Internet Media Type (RFC 1590) and MIME Content Type (RFC 1521) is defined by this specification.</t>
</abstract>
</front>

<seriesInfo value="1866" name="RFC" />
</reference>


<reference target2="reference.RFC.1867.xml" anchor="RFC1867">
<front>
<title>Form-based File Upload in HTML</title>
<author fullname="Ernesto Nebel" initials="E." surname="Nebel">
<organization>XSoft, Xerox Corporation</organization>

<address>
<postal>
<street>10875 Rancho Bernardo Road</street>
<street>Suite 200</street>
<city>San Diego</city>
<region>CA</region>
<code>92127-2116</code>
<country>US</country>
</postal>

<phone>+1 619 676 7817</phone>
<facsimile>+1 619 676 7865</facsimile>
<email>nebel@xsoft.sd.xerox.com</email>
</address>
</author>

<author fullname="Larry Masinter" initials="L." surname="Masinter">
<organization>Xerox Palo Alto Research Center</organization>

<address>
<postal>
<street>3333 Coyote Hill Road</street>
<city>Palo Alto</city>
<region>CA</region>
<code>94304</code>
<country>US</country>
</postal>

<phone>+1 415 812 4365</phone>
<facsimile>+1 415 812 4333</facsimile>
<email>masinter@parc.xerox.com</email>
</address>
</author>

<date year="1995" month="November" />

<abstract>
<t>Currently, HTML forms allow the producer of the form to request information from the user reading the form.  These forms have proven useful in a wide variety of applications in which input from the user is necessary.  However, this capability is limited because HTML forms don't provide a way to ask the user to submit files of data.  Service providers who need to get files from the user have had to implement custom user applications.  (Examples of these custom browsers have appeared on the www-talk mailing list.)  Since file-upload is a feature that will benefit many applications, this proposes an extension to HTML to allow information providers to express file upload requests uniformly, and a MIME compatible representation for
   file upload responses.  This also includes a description of a backward compatibility strategy that allows new servers to interact with the current HTML user agents.</t>

<t>The proposal is independent of which version of HTML it becomes a part.</t>
</abstract>
</front>

<seriesInfo value="1867" name="RFC" />
</reference>


<reference target2="reference.RFC.1868.xml" anchor="RFC1868">
<front>
<title abbrev="UNARP">ARP Extension - UNARP</title>
<author fullname="Gary Scott Malkin" initials="G." surname="Malkin">
<organization>Xylogics, Inc.</organization>

<address>
<postal>
<street>53 Third Avenue</street>
<city>Burlington</city>
<region>MA</region>
<code>01803</code>
<country>US</country>
</postal>

<phone>+1 617 272 8140</phone>
<email>gmalkin@xylogics.com</email>
</address>
</author>

<date year="1995" month="November" />

<abstract>
<t>The Address Resolution Protocol allows an IP node to determine the hardware (datalink) address of a neighboring node on a broadcast network.  The protocol depends on timers to age away old ARP entries. This document specifies a trivial modification to the ARP mechanism, not the packet format, which allows a node to announce that it is leaving the network and that all other nodes should modify their ARP tables accordingly.</t>
</abstract>
</front>

<seriesInfo value="1868" name="RFC" />
</reference>


<reference target2="reference.RFC.1869.xml" anchor="RFC1869">
<front>
<title>SMTP Service Extensions</title>
<author fullname="John Klensin" initials="J." surname="Klensin">
<organization>MCI</organization>

<address>
<postal>
<street>2100 Reston Parkway</street>
<city>Reston</city>
<region>VA</region>
<code>22091</code>
<country>US</country>
</postal>

<phone>+1 703 715 7361</phone>
<facsimile>+1 703 715 7436</facsimile>
<email>klensin@mci.net</email>
</address>
</author>

<author fullname="Ned Freed" initials="N." surname="Freed">
<organization>Innosoft International, Inc.</organization>

<address>
<postal>
<street>1050 East Garvey Avenue South</street>
<city>West Covina</city>
<region>CA</region>
<code>91790</code>
<country>US</country>
</postal>

<phone>+1 818 919 3600</phone>
<facsimile>+1 818 919 3614</facsimile>
<email>ned@innosoft.com</email>
</address>
</author>

<author fullname="Marshall T. Rose" initials="M." surname="Rose">
<organization>Dover Beach Consulting, Inc.</organization>

<address>
<postal>
<street>420 Whisman Court</street>
<city>Mountain View</city>
<region>CA</region>
<code>94043-2186</code>
<country>US</country>
</postal>

<phone>+1 415 968 1052</phone>
<facsimile>+1 415 968 2510</facsimile>
<email>mrose@dbc.mtview.ca.us</email>
</address>
</author>

<author fullname="Einar A. Stefferud" initials="E." surname="Stefferud">
<organization>Network Management Associates, Inc.</organization>

<address>
<postal>
<street>17301 Drey Lane</street>
<city>Huntington Beach</city>
<region>CA</region>
<code>92647-5615</code>
<country>US</country>
</postal>

<phone>+1 714 842 3711</phone>
<facsimile>+1 714 848 2091</facsimile>
<email>stef@nma.com</email>
</address>
</author>

<author fullname="Dave Crocker" initials="D." surname="Crocker">
<organization>Brandenburg Consulting</organization>

<address>
<postal>
<street>675 Spruce Dr.</street>
<city>Sunnyvale</city>
<region>CA</region>
<code>94086</code>
<country>US</country>
</postal>

<phone>+1 408 246 8253</phone>
<facsimile>+1 408 249 6205</facsimile>
<email>dcrocker@mordor.stanford.edu</email>
</address>
</author>

<date year="1995" month="November" />

<abstract>
<t>This memo defines a framework for extending the SMTP service by defining a means whereby a server SMTP can inform a client SMTP as to the service extensions it supports.  Extensions to the SMTP service are registered with the IANA. This framework does not require modification of existing SMTP clients or servers unless the features of the service extensions are to be requested or provided.</t>
</abstract>
</front>

<seriesInfo value="10" name="STD" />
<seriesInfo value="1869" name="RFC" />
</reference>


<reference target2="reference.RFC.1870.xml" anchor="RFC1870">
<front>
<title abbrev="SMTP Size Declaration">SMTP Service Extension for Message Size Declaration</title>
<author fullname="John Klensin" initials="J." surname="Klensin">
<organization>MCI</organization>

<address>
<postal>
<street>2100 Reston Parkway</street>
<city>Reston</city>
<region>VA</region>
<code>22091</code>
<country>US</country>
</postal>

<phone>+1 703 715 7361</phone>
<facsimile>+1 703 715 7436</facsimile>
<email>klensin@mci.net</email>
</address>
</author>

<author fullname="Ned Freed" initials="N." surname="Freed">
<organization>Innosoft International, Inc.</organization>

<address>
<postal>
<street>1050 East Garvey Avenue South</street>
<city>West Covina</city>
<region>CA</region>
<code>91790</code>
<country>US</country>
</postal>

<phone>+1 818 919 3600</phone>
<facsimile>+1 818 919 3614</facsimile>
<email>ned@innosoft.com</email>
</address>
</author>

<author fullname="Keith Moore" initials="K." surname="Moore">
<organization>University of Tennessee, Computer Science Dept.</organization>

<address>
<postal>
<street>107 Ayres Hall</street>
<city>Knoxville</city>
<region>TN</region>
<code>37996-1301</code>
<country>US</country>
</postal>

<email>moore@cs.utk.edu</email>
</address>
</author>

<date year="1995" month="November" />

<abstract>
<t>This memo defines an extension to the SMTP service whereby an SMTP client and server may interact to give the server an opportunity to decline to accept a message (perhaps temporarily) based on the client's estimate of the message size.</t>
</abstract>
</front>

<seriesInfo value="10" name="STD" />
<seriesInfo value="1870" name="RFC" />
</reference>


<reference target2="reference.RFC.1871.xml" anchor="RFC1871">
<front>
<title abbrev="Variance Procedure">Addendum to RFC 1602 -- Variance Procedure</title>
<author fullname="Jon Postel" initials="J." surname="Postel">
<organization>University of Southern California, Information Sciences Institute</organization>

<address>
<postal>
<street>4676 Admiralty Way</street>
<street>Suite 1001</street>
<city>Marina del Rey</city>
<region>CA</region>
<code>90292-6695</code>
<country>US</country>
</postal>

<phone>+1 310 822 1511</phone>
<email>postel@isi.edu</email>
</address>
</author>

<date year="1995" month="November" />

<abstract>
<t>This document describes a modification to the IETF procedures to allow an escape from a situation where the existing procedures are not working or do not seem to apply.  This is a modification to the procedures of RFC 1602 and 1603.</t>
</abstract>
</front>

<seriesInfo value="2" name="BCP" />
<seriesInfo value="1871" name="RFC" />
</reference>


<reference target2="reference.RFC.1872.xml" anchor="RFC1872">
<front>
<title abbrev="Multipart/Related">The MIME Multipart/Related Content-type</title>
<author fullname="Edward Levinson" initials="E." surname="Levinson">
<organization>Accurate Information Systems, Inc.</organization>

<address>
<postal>
<street>2 Industrial Way</street>
<city>Eatontown</city>
<region>NJ</region>
<code>07724-2265</code>
<country>US</country>
</postal>

<phone>+1 908 389 5550</phone>
<email>ELevinson@Accurate.com</email>
</address>
</author>

<date year="1995" month="December" />

<abstract>
<t>The Multipart/Related content-type provides a common mechanism for representing objects that are aggregates of related MIME body parts. This document defines the Multipart/Related content-type and provides examples of its use.</t>
</abstract>
</front>

<seriesInfo value="1872" name="RFC" />
</reference>


<reference target2="reference.RFC.1873.xml" anchor="RFC1873">
<front>
<title abbrev="Access Type Content-ID">Message/External-Body Content-ID Access Type</title>
<author fullname="Edward Levinson" initials="E." surname="Levinson">
<organization>Accurate Information Systems, Inc.</organization>

<address>
<postal>
<street>2 Industrial Way</street>
<city>Eatontown</city>
<region>NJ</region>
<code>07724-2265</code>
<country>US</country>
</postal>

<phone>+1 908 389 5550</phone>
<email>ELevinson@Accurate.com</email>
</address>
</author>

<author fullname="James Clark" initials="J." surname="Clark">
<organization />

<address>
<postal>
<street>90 Clarendon Road</street>
<city>London</city>
<region>England</region>
<code>W11 2HR</code>
<country>UK</country>
</postal>

<email>jjc@jclark.com</email>
</address>
</author>

<date year="1995" month="December" />

<abstract>
<t>When using MIMEto encapsulate a structured object that consist of many elements, for example an SGMLdocument, a single element may occur several times.  An encapsulation normally maps each of the structured objects elements to a MIME entity.  It is useful to include elements that occur multiple time exactly once.  To accomplish that and to preserve the object structure it is desirable to unambiguously refer to another body part of the same message.</t>

<t>The existing MIME Content-Type Message/External-Body access-types allow a MIME entity (body-part) to refer to an object that is not in the message by specifying how to access that object.  The Content-ID access method described in this document provides the capability to refer to an object within the message.</t>
</abstract>
</front>

<seriesInfo value="1873" name="RFC" />
</reference>


<reference target2="reference.RFC.1874.xml" anchor="RFC1874">
<front>
<title>SGML Media Types</title>
<author fullname="Ed Levinson" initials="E." surname="Levinson">
<organization>Accurate Information Systems, Inc.</organization>

<address>
<postal>
<street>2 Industrial Way</street>
<city>Eatontown</city>
<region>NJ</region>
<code>07724</code>
<country>US</country>
</postal>

<email>ELevinson@Accurate.com</email>
</address>
</author>

<date year="1995" month="December" />

<abstract>
<t>This document proposes new media sub-types of Text/SGML and Application/SGML.  These media types can be used in the exchange of SGML documents and their entities.  Specific details for the exchange or encapsulation of groups of related SGML entities using MIME are currently being considered by the mimesgml Working Group sgml-internet@ebt.com.</t>
</abstract>
</front>

<seriesInfo value="1874" name="RFC" />
</reference>


<reference target2="reference.RFC.1875.xml" anchor="RFC1875">
<front>
<title>UNINETT PCA Policy Statements</title>
<author fullname="Nils Harald Berge" initials="N." surname="Berge">
<organization>Norwegian Computing Center</organization>

<address>
<postal>
<street>Gaustadallien 23</street>
<street>P.O.Box 114 Blindern</street>
<city>Oslo</city>
<region />
<code>N-0314</code>
<country>NO</country>
</postal>

<phone>+47 22 852500</phone>
<facsimile>+47 22 697660</facsimile>
<email>Nils.Harald.Berge@nr.no</email>
</address>
</author>

<date year="1995" month="December" />
</front>

<seriesInfo value="1875" name="RFC" />
</reference>


<reference target2="reference.RFC.1876.xml" anchor="RFC1876">
<front>
<title abbrev="Location Information in the DNS">A Means for Expressing Location Information in the Domain Name System</title>
<author fullname="Christopher Davis" initials="C." surname="Davis">
<organization>Kapor Enterprises, Inc.</organization>

<address>
<postal>
<street>238 Main Street</street>
<street>Suite 400</street>
<city>Cambridge</city>
<region>MA</region>
<code>02142</code>
<country>US</country>
</postal>

<phone>+1 617 576 4532</phone>
<email>ckd@kei.com</email>
</address>
</author>

<author fullname="Paul Vixie" initials="P." surname="Vixie">
<organization>Vixie Enterprises</organization>

<address>
<postal>
<street>Star Route Box 159A</street>
<city>Woodside</city>
<region>CA</region>
<code>94062</code>
<country>US</country>
</postal>

<phone>+1 415 747 0204</phone>
<email>paul@vix.com</email>
</address>
</author>

<author fullname="Tim Goodwin" initials="T." surname="Goodwin">
<organization>Public IP Exchange Ltd (PIPEX)</organization>

<address>
<postal>
<street>216 The Science Park</street>
<city>Cambridge</city>
<region>England</region>
<code>CB4 4WA</code>
<country>UK</country>
</postal>

<phone>+44 1223 250250</phone>
<email>tim@pipex.net</email>
</address>
</author>

<author fullname="Ian Dickinson" initials="I." surname="Dickinson">
<organization>FORE Systems</organization>

<address>
<postal>
<street>2475 The Crescent</street>
<street>Solihull Parkway</street>
<city>Birmingham Business Park</city>
<region>England</region>
<code>B37 7YE</code>
<country>UK</country>
</postal>

<phone>+44 121 7174444</phone>
<email>idickins@fore.co.uk</email>
</address>
</author>

<date year="1996" month="January" />

<abstract>
<t>This memo defines a new DNS RR type for experimental purposes.  This RFC describes a mechanism to allow the DNS to carry location information about hosts, networks, and subnets.  Such information for a small subset of hosts is currently contained in the flat-file UUCP maps.  However, just as the DNS replaced the use of HOSTS.TXT to carry host and network address information, it is possible to replace the UUCP maps as carriers of location information.</t>

<t>This RFC defines the format of a new Resource Record (RR) for the Domain Name System (DNS), and reserves a corresponding DNS type mnemonic (LOC) and numerical code (29).</t>

<t>This RFC assumes that the reader is familiar with the DNS,.  The data shown in our examples is for pedagogical use and does not necessarily reflect the real Internet.</t>
</abstract>
</front>

<seriesInfo value="1876" name="RFC" />
</reference>


<reference target2="reference.RFC.1877.xml" anchor="RFC1877">
<front>
<title abbrev="PPP IPCP Extensions">PPP Internet Protocol Control Protocol Extensions for Name Server Addresses</title>
<author fullname="Steve Cobb" initials="S." surname="Cobb">
<organization>Microsoft Corporation</organization>

<address>
<postal>
<street>One Microsoft Way</street>
<city>Redmond</city>
<region>WA</region>
<code>98052-6399</code>
<country>US</country>
</postal>

<phone>+1 206 882 8080</phone>
<email>stevec@microsoft.com</email>
</address>
</author>

<author fullname="Fred Baker" initials="F." surname="Baker">
<organization>Cisco Systems</organization>

<address>
<postal>
<street>519 Lado Drive</street>
<city>Santa Barbara</city>
<region>CA</region>
<code>93111</code>
<country>US</country>
</postal>

<email>fred@cisco.com</email>
</address>
</author>

<date year="1995" month="December" />

<abstract>
<t>The Point-to-Point Protocol (PPP)provides a standard method for transporting multi-protocol datagrams over point-to-point links.  PPP defines an extensible Link Control Protocol and a family of Network Control Protocols (NCPs) for establishing and configuring different network-layer protocols.</t>

<t>This document extends the NCP for establishing and configuring the Internet Protocol over PPP, defining the negotiation of primary and secondary Domain Name System (DNS)and NetBIOS Name Server (NBNS)addresses.</t>
</abstract>
</front>

<seriesInfo value="1877" name="RFC" />
</reference>


<reference target2="reference.RFC.1878.xml" anchor="RFC1878">
<front>
<title abbrev="Subnet Table">Variable Length Subnet Table For IPv4</title>
<author fullname="Troy T. Pummill" initials="T." surname="Pummill">
<organization>Alantec</organization>

<address>
<postal>
<street>2115 O'Nel Drive</street>
<city>San Jose</city>
<region>CA</region>
<code>95131</code>
<country>US</country>
</postal>

<phone>+1 408 467 4871</phone>
<facsimile>+1 408 441 0272</facsimile>
<email>trop@alantec.com</email>
</address>
</author>

<author fullname="Bill Manning" initials="B." surname="Manning">
<organization>University of Southern California, Information Sciences Institute</organization>

<address>
<postal>
<street>4676 Admiralty Way</street>
<city>Marina del Rey</city>
<region>CA</region>
<code>90292-6695</code>
<country>US</country>
</postal>

<phone>+1 310 822 1511 x387</phone>
<facsimile>+1 310 823 6714</facsimile>
<email>bmanning@isi.edu</email>
</address>
</author>

<date year="1995" month="December" />

<abstract>
<t>This memo clarifies issues surrounding subnetting IP networks by providing a standard subnet table.  This table includes subnetting for Class A, B, and C networks, as well as Network IDs, host ranges and IP broadcast addresses with emphasis on Class C subnets.</t>

<t>This memo is intended as an informational companion to Subneting RFCand the Hosts Requirements RFC.</t>
</abstract>
</front>

<seriesInfo value="1878" name="RFC" />
</reference>


<reference target2="reference.RFC.1879.xml" anchor="RFC1879">
<front>
<title abbrev="Class A Subnet Experiment">Class A Subnet Experiment Results and Recommendations</title>
<author fullname="Bill Manning" initials="B." surname="Manning">
<organization>University of Southern California, Information Sciences Institute</organization>

<address>
<postal>
<street>4676 Admiralty Way</street>
<city>Marina del Rey</city>
<region>CA</region>
<code>90292-6695</code>
<country>US</country>
</postal>

<phone>+1 310 822 1511 x387</phone>
<facsimile>+1 310 823 6714</facsimile>
<email>bmanning@isi.edu</email>
</address>
</author>

<date year="1996" month="January" />
</front>

<seriesInfo value="1879" name="RFC" />
</reference>


<reference target2="reference.RFC.1880.xml" anchor="RFC1880">
<front>
<title abbrev="Internet Standards">Internet Official Protocol Standards</title>
<author fullname="Jon Postel" initials="J." surname="Postel">
<organization>University of Southern California,  Information Sciences Institute</organization>

<address>
<postal>
<street>4676 Admiralty Way</street>
<city>Marina del Rey</city>
<region>CA</region>
<code>90292</code>
<country>US</country>
</postal>

<phone>+1 310 822 1511</phone>
<facsimile>+1 310 823 6714</facsimile>
<email>Postel@ISI.EDU</email>
</address>
</author>

<date year="1995" month="November" />
</front>

<seriesInfo value="1880" name="RFC" />
</reference>


<reference target2="reference.RFC.1881.xml" anchor="RFC1881">
<front>
<title>IPv6 Address Allocation Management</title>
<author>
<organization abbrev="IAB">Internet Architecture Board</organization>

<address>
<email>iab@isi.edu</email>
</address>
</author>

<author>
<organization abbrev="IESG">Internet Engineering Steering Group</organization>

<address>
<email>iesg@cnri.reston.va.us</email>
</address>
</author>

<date year="1995" month="December" />

<abstract>
<t>The IPv6 address space will be managed by the IANA for the good of the Internet community, with advice from the IAB and the IESG, by delegation to the regional registries.</t>
</abstract>
</front>

<seriesInfo value="1881" name="RFC" />
</reference>


<reference target2="reference.RFC.1882.xml" anchor="RFC1882">
<front>
<title abbrev="12-Days of Technology Before Christmas">The 12-Days of Technology Before Christmas</title>
<author fullname="Bill Hancock" initials="B." surname="Hancock">
<organization>Network-1 Software &amp; Technology, Inc., DFW Research Center</organization>

<address>
<postal>
<street>878 Greenview Dr.</street>
<city>Grand Prairie</city>
<region>TX</region>
<code>75050</code>
<country>US</country>
</postal>

<phone>+1 214 606 8200</phone>
<facsimile>+1 214 606 8220</facsimile>
<email>hancock@network-1.com</email>
</address>
</author>

<date year="1995" month="December" />
</front>

<seriesInfo value="1882" name="RFC" />
</reference>


<reference target2="reference.RFC.1883.xml" anchor="RFC1883">
<front>
<title abbrev="IPv6 Specification">Internet Protocol, Version 6 (IPv6) Specification</title>
<author fullname="Stephen E. Deering" initials="S.E." surname="Deering">
<organization>Xerox Palo Alto Research Center</organization>

<address>
<postal>
<street>3333 Coyote Hill Road</street>
<city>Palo Alto</city>
<region>CA</region>
<code>94304</code>
<country>US</country>
</postal>

<phone>+1 415 812 4839</phone>
<facsimile>+1 415 812 4471</facsimile>
<email>deering@parc.xerox.com</email>
</address>
</author>

<author fullname="Robert M. Hinden" initials="R.M." surname="Hinden">
<organization>Ipsilon Networks, Inc.</organization>

<address>
<postal>
<street>2191 E. Bayshore Road</street>
<street>Suite 100</street>
<city>Palo Alto</city>
<region>CA</region>
<code>94303</code>
<country>US</country>
</postal>

<phone>+1 415 846 4604</phone>
<facsimile>+1 415 855 1414</facsimile>
<email>hinden@ipsilon.com</email>
</address>
</author>

<date year="1995" month="December" />

<abstract>
<t>This document specifies version 6 of the Internet Protocol (IPv6), also sometimes referred to as IP Next Generation or IPng.</t>
</abstract>
</front>

<seriesInfo value="1883" name="RFC" />
</reference>


<reference target2="reference.RFC.1884.xml" anchor="RFC1884">
<front>
<title abbrev="IPv6 Addressing Architecture">IP Version 6 Addressing Architecture</title>
<author fullname="Robert M. Hinden" initials="R.M." surname="Hinden">
<organization>Ipsilon Networks, Inc.</organization>

<address>
<postal>
<street>2191 E. Bayshore Road</street>
<street>Suite 100</street>
<city>Palo Alto</city>
<region>CA</region>
<code>94303</code>
<country>US</country>
</postal>

<phone>+1 415 846 4604</phone>
<facsimile>+1 415 855 1414</facsimile>
<email>hinden@ipsilon.com</email>
</address>
</author>

<author fullname="Stephen E. Deering" initials="S.E." surname="Deering">
<organization>Xerox Palo Alto Research Center</organization>

<address>
<postal>
<street>3333 Coyote Hill Road</street>
<city>Palo Alto</city>
<region>CA</region>
<code>94304</code>
<country>US</country>
</postal>

<phone>+1 415 812 4839</phone>
<facsimile>+1 415 812 4471</facsimile>
<email>deering@parc.xerox.com</email>
</address>
</author>

<date year="1995" month="December" />

<abstract>
<t>This specification defines the addressing architecture of the IP Version 6 protocol.  The document includes the IPv6 addressing model, text representations of IPv6 addresses, definition of IPv6 unicast addresses, anycast addresses, and multicast addresses, and an IPv6 nodes required addresses.</t>
</abstract>
</front>

<seriesInfo value="1884" name="RFC" />
</reference>


<reference target2="reference.RFC.1885.xml" anchor="RFC1885">
<front>
<title abbrev="ICMPv6 (ICMP for IPv6)">Internet Control Message Protocol (ICMPv6) for the Internet Protocol Version 6 (IPv6)</title>
<author fullname="Alex Conta" initials="A." surname="Conta">
<organization>Digital Equipment Corporation</organization>

<address>
<postal>
<street>110 Spitbrook Rd</street>
<city>Nashua</city>
<region>NH</region>
<code>03062</code>
<country>US</country>
</postal>

<phone>+1 603 881 0744</phone>
<email>conta@zk3.dec.com</email>
</address>
</author>

<author fullname="Stephen Deering" initials="S." surname="Deering">
<organization>Xerox Palo Alto Research Center</organization>

<address>
<postal>
<street>3333 Coyote Hill Road</street>
<city>Palo Alto</city>
<region>CA</region>
<code>94304</code>
<country>US</country>
</postal>

<phone>+1 415 812 4839</phone>
<email>deering@parc.xerox.com</email>
</address>
</author>

<date year="1995" month="December" />

<abstract>
<t>This document specifies a set of Internet Control Message Protocol (ICMP) messages for use with version 6 of the Internet Protocol (IPv6).  The Internet Group Management Protocol (IGMP) messages specified in STD 5, RFC 1112 have been merged into ICMP, for IPv6, and are included in this document.</t>
</abstract>
</front>

<seriesInfo value="1885" name="RFC" />
</reference>


<reference target2="reference.RFC.1886.xml" anchor="RFC1886">
<front>
<title abbrev="IPv6 DNS Extensions">DNS Extensions to support IP version 6</title>
<author fullname="Susan Thomson" initials="S." surname="Thomson">
<organization>Bellcore</organization>

<address>
<postal>
<street>445 South Street</street>
<street>MRE 2P343</street>
<city>Morristown</city>
<region>NJ</region>
<code>07960</code>
<country>US</country>
</postal>

<phone>+1 201 829 4514</phone>
<email>set@thumper.bellcore.com</email>
</address>
</author>

<author fullname="Christian Huitema" initials="C." surname="Huitema">
<organization>INRIA, Sophia-Antipolis</organization>

<address>
<postal>
<street>2004 Route des Lucioles</street>
<street>BP 109</street>
<city>Valbonne Cedex</city>
<code>F-06561</code>
<country>FR</country>
</postal>

<phone>+33 93 657715</phone>
<email>Christian.Huitema@MIRSA.INRIA.FR</email>
</address>
</author>

<date year="1995" month="December" />

<abstract>
<t>This document defines the changes that need to be made to the Domain Name System to support hosts running IP version 6 (IPv6).  The changes include a new resource record type to store an IPv6 address, a new domain to support lookups based on an IPv6 address, and updated definitions of existing query types that return Internet addresses as part of additional section processing.  The extensions are designed to be compatible with existing applications and, in particular, DNS implementations themselves.</t>
</abstract>
</front>

<seriesInfo value="1886" name="RFC" />
</reference>


<reference target2="reference.RFC.1887.xml" anchor="RFC1887">
<front>
<title abbrev="IPv6 Unicast Address Allocation Architecture">An Architecture for IPv6 Unicast Address Allocation</title>
<author fullname="Yakov Rekhter" initials="Y." surname="Rekhter">
<organization>cisco Systems, Inc.</organization>

<address>
<postal>
<street>470 Tasman Dr.</street>
<city>San Jose</city>
<region>CA</region>
<code>95134</code>
<country>US</country>
</postal>

<phone>+1 914 528 0090</phone>
<email>yakov@cisco.com</email>
</address>
</author>

<author fullname="Tony Li" initials="T." surname="Li">
<organization>cisco Systems, Inc.</organization>

<address>
<postal>
<street>470 Tasman Dr.</street>
<city>San Jose</city>
<region>CA</region>
<code>95134</code>
<country>US</country>
</postal>

<phone>+1 408 526 8186</phone>
<email>tli@cisco.com</email>
</address>
</author>

<date year="1995" month="December" />

<abstract>
<t>This document provides an architecture for allocating IPv6unicast addresses in the Internet. The overall IPv6 addressing architecture is defined in.  This document does not go into the details of an addressing plan.</t>
</abstract>
</front>

<seriesInfo value="1887" name="RFC" />
</reference>


<reference target2="reference.RFC.1888.xml" anchor="RFC1888">
<front>
<title>OSI NSAPs and IPv6</title>
<author fullname="Jim Bound" initials="J." surname="Bound">
<organization>Digital Equipment Corporation, Network Operating Systems</organization>

<address>
<postal>
<street>110 Spitbrook Road</street>
<street>ZKO3-3/U14</street>
<city>Nashua</city>
<region>NH</region>
<code>03062</code>
<country>US</country>
</postal>

<phone>+1 603 881 0400</phone>
<facsimile>+1 603 881 0120</facsimile>
<email>bound@zk3.dec.com</email>
</address>
</author>

<author fullname="Brian E. Carpenter" initials="B." surname="Carpenter">
<organization>CERN, European Laboratory for Particle Physics, Computing and Networks Division, Communications Systems</organization>

<address>
<postal>
<street>1211 Geneva</street>
<city />
<region />
<code>23</code>
<country>CH</country>
</postal>

<phone>+41 22 7674967</phone>
<facsimile>+41 22 7677155</facsimile>
<email>brian@dxcoms.cern.ch</email>
</address>
</author>

<author fullname="Dan Harrington" initials="D." surname="Harrington">
<organization>Digital Equipment Corp.</organization>

<address>
<postal>
<street>King Street (LKG2-2/Q9)</street>
<city>Littleton</city>
<region>MA</region>
<code>01460</code>
<country>US</country>
</postal>

<phone>+1 508 486 7643</phone>
<email>dan@netrix.lkg.dec.com</email>
</address>
</author>

<author fullname="Jack Houldsworth" initials="J." surname="Houldsworth">
<organization>ICL Network Systems</organization>

<address>
<postal>
<street>Cavendish Road</street>
<city>Stevenage</city>
<region>Hertfordshire</region>
<code>SG1 4BQ</code>
<country>UK</country>
</postal>

<phone>+44 438 786112</phone>
<facsimile>+44 438 786150</facsimile>
<email>j.houldsworth@ste0906.wins.icl.co.uk</email>
</address>
</author>

<author fullname="Alan Lloyd" initials="A." surname="Lloyd">
<organization>Datacraft Technologies</organization>

<address>
<postal>
<street>252 Maroondah Highway</street>
<city>Mooroolbark</city>
<region>Victoria</region>
<code>3138</code>
<country>AU</country>
</postal>

<phone>+61 3 7279222</phone>
<facsimile>+61 3 7271557</facsimile>
<email>alan.lloyd@datacraft.com.au</email>
</address>
</author>

<date year="1996" month="August" />

<abstract>
<t>This document recommends that network implementors who have planned or deployed an OSI NSAP addressing plan, and who wish to deploy or transition to IPv6, should redesign a native IPv6 addressing plan to meet their needs.  However, it also defines a set of mechanisms for the support of OSI NSAP addressing in an IPv6 network.  These mechanisms are the ones that MUST be used if such support is required.  This document also defines a mapping of IPv6 addresses within the OSI address format, should this be required.</t>
</abstract>
</front>

<seriesInfo value="1888" name="RFC" />
</reference>


<reference target2="reference.RFC.1889.xml" anchor="RFC1889">
<front>
<title abbrev="RTP">RTP: A Transport Protocol for Real-Time Applications</title>
<author fullname="Henning Schulzrinne" initials="H." surname="Schulzrinne">
<organization>GMD Fokus</organization>

<address>
<postal>
<street>Hardenbergplatz 2</street>
<city>Berlin</city>
<region />
<code>D-10623</code>
<country>DE</country>
</postal>

<email>schulzrinne@fokus.gmd.de</email>
</address>
</author>

<author fullname="Stephen L. Casner" initials="S." surname="Casner">
<organization>Precept Software, Inc.</organization>

<address>
<postal>
<street>21580 Stevens Creek Boulevard</street>
<street>Suite 207</street>
<city>Cupertino</city>
<region>CA</region>
<code>95014</code>
<country>US</country>
</postal>

<email>casner@precept.com</email>
</address>
</author>

<author fullname="Ron Frederick" initials="R." surname="Frederick">
<organization>Xerox Palo Alto Research Center</organization>

<address>
<postal>
<street>3333 Coyote Hill Road</street>
<city>Palo Alto</city>
<region>CA</region>
<code>94304</code>
<country>US</country>
</postal>

<email>frederic@parc.xerox.com</email>
</address>
</author>

<author fullname="Van Jacobson" initials="V." surname="Jacobson">
<organization>Lawrence Berkeley National Laboratory</organization>

<address>
<postal>
<street>MS 46a-1121</street>
<city>Berkeley</city>
<region>CA</region>
<code>94720</code>
<country>US</country>
</postal>

<email>van@ee.lbl.gov</email>
</address>
</author>

<date year="1996" month="January" />

<abstract>
<t>This memorandum describes RTP, the real-time transport protocol. RTP provides end-to-end network transport functions suitable for applications transmitting real-time data, such as audio, video or simulation data, over multicast or unicast network services. RTP does not address resource reservation and does not guarantee quality-of- service for real-time services. The data transport is augmented by a control protocol (RTCP) to allow monitoring of the data delivery in a manner scalable to large multicast networks, and to provide minimal control and identification functionality. RTP and RTCP are designed to be independent of the underlying transport and network layers. The protocol supports the use of RTP-level translators and mixers.</t>
</abstract>
</front>

<seriesInfo value="1889" name="RFC" />
</reference>


<reference target2="reference.RFC.1890.xml" anchor="RFC1890">
<front>
<title abbrev="AV Profile">RTP Profile for Audio and Video Conferences with Minimal Control</title>
<author fullname="Henning Schulzrinne" initials="H." surname="Schulzrinne">
<organization>GMD Fokus</organization>

<address>
<postal>
<street>Hardenbergplatz 2</street>
<city>Berlin</city>
<region />
<code>D-10623</code>
<country>DE</country>
</postal>

<email>schulzrinne@fokus.gmd.de</email>
</address>
</author>

<date year="1996" month="January" />

<abstract>
<t>This memo describes a profile for the use of the real-time transport protocol (RTP), version 2, and the associated control protocol, RTCP, within audio and video multiparticipant conferences with minimal control. It provides interpretations of generic fields within the RTP specification suitable for audio and video conferences.  In particular, this document defines a set of default mappings from payload type numbers to encodings.</t>

<t>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 encoding 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.</t>
</abstract>
</front>

<seriesInfo value="1890" name="RFC" />
</reference>


<reference target2="reference.RFC.1891.xml" anchor="RFC1891">
<front>
<title abbrev="SMTP Delivery Status Notifications">SMTP Service Extension for Delivery Status Notifications</title>
<author fullname="Keith Moore" initials="K." surname="Moore">
<organization>University of Tennessee</organization>

<address>
<postal>
<street>107 Ayres Hall</street>
<city>Knoxville</city>
<region>TN</region>
<code>37996-1301</code>
<country>US</country>
</postal>

<email>moore@cs.utk.edu</email>
</address>
</author>

<date year="1996" month="January" />

<abstract>
<t>This memo defines an extension to the SMTP service, which allows an SMTP client to specify (a) that delivery status notifications (DSNs) should be generated under certain conditions, (b) whether such notifications should return the contents of the message, and (c) additional information, to be returned with a DSN, that allows the sender to identify both the recipient(s) for which the DSN was issued, and the transaction in which the original message was sent.</t>

<t>Any questions, comments, and reports of defects or ambiguities in this specification may be sent to the mailing list for the NOTARY working group of the IETF, using the address &lt;notifications@cs.utk.edu&gt;.  Requests to subscribe to the mailing list should be addressed to &lt;notifications-request@cs.utk.edu&gt;. Implementors of this specification are encouraged to subscribe to the mailing list, so that they will quickly be informed of any problems which might hinder interoperability.</t>

<t>NOTE: This document is a Proposed Standard.  If and when this protocol is submitted for Draft Standard status, any normative text (phrases containing SHOULD, SHOULD NOT, MUST, MUST NOT, or MAY) in this document will be re-evaluated in light of implementation experience, and are thus subject to change.</t>
</abstract>
</front>

<seriesInfo value="1891" name="RFC" />
</reference>


<reference target2="reference.RFC.1892.xml" anchor="RFC1892">
<front>
<title abbrev="Multipart/Report">The Multipart/Report Content Type for the Reporting of Mail System Administrative Messages</title>
<author fullname="Gregory M. Vaudreuil" initials="G." surname="Vaudreuil">
<organization>Octel Network Services</organization>

<address>
<postal>
<street>17060 Dallas Parkway</street>
<city>Dallas</city>
<region>TX</region>
<code>75248-1905</code>
<country>US</country>
</postal>

<phone>+1 214 733 2722</phone>
<email>Greg.Vaudreuil@Octel.com</email>
</address>
</author>

<date year="1996" month="January" />

<abstract>
<t></t>
</abstract>
</front>

<seriesInfo value="1892" name="RFC" />
</reference>


<reference target2="reference.RFC.1893.xml" anchor="RFC1893">
<front>
<title abbrev="Mail System Status Codes">Enhanced Mail System Status Codes</title>
<author fullname="Gregory M. Vaudreuil" initials="G." surname="Vaudreuil">
<organization>Octel Network Services</organization>

<address>
<postal>
<street>17060 Dallas Parkway</street>
<street>Suite 214</street>
<city>Dallas</city>
<region>TX</region>
<code>75248-1905</code>
<country>US</country>
</postal>

<phone>+1 214 733 2722</phone>
<facsimile>+1 214 733 2722</facsimile>
<email>Greg.Vaudreuil@Octel.com</email>
</address>
</author>

<date year="1996" month="January" />

<abstract>
<t></t>
</abstract>
</front>

<seriesInfo value="1893" name="RFC" />
</reference>


<reference target2="reference.RFC.1894.xml" anchor="RFC1894">
<front>
<title abbrev="Delivery Status Notifications">An Extensible Message Format for Delivery Status Notifications</title>
<author fullname="Keith Moore" initials="K." surname="Moore">
<organization>University of Tennessee</organization>

<address>
<postal>
<street>107 Ayres Hall</street>
<city>Knoxville</city>
<region>TN</region>
<code>37996-1301</code>
<country>US</country>
</postal>

<phone>+1 615 974 3126</phone>
<facsimile>+1 615 974 8296</facsimile>
<email>moore@cs.utk.edu</email>
</address>
</author>

<author fullname="Gregory M. Vaudreuil" initials="G." surname="Vaudreuil">
<organization>Octel Network Services</organization>

<address>
<postal>
<street>17080 Dallas Parkway</street>
<city>Dallas</city>
<region>TX</region>
<code>75248-1905</code>
<country>US</country>
</postal>

<email>Greg.Vaudreuil@Octel.Com</email>
</address>
</author>

<date year="1996" month="January" />

<abstract>
<t>This memo defines a MIME content-type that may be used by a message transfer agent (MTA) or electronic mail gateway to report the result of an attempt to deliver a message to one or more recipients.  This content-type is intended as a machine-processable replacement for the various types of delivery status notifications currently used in Internet electronic mail.</t>

<t>Because many messages are sent between the Internet and other messaging systems (such as X.400 or the so-called "LAN-based" systems), the DSN protocol is designed to be useful in a multi-protocol messaging environment.  To this end, the protocol described in this memo provides for the carriage of "foreign" addresses and error codes, in addition to those normally used in Internet mail.  Additional attributes may also be defined to support "tunneling" of foreign notifications through Internet mail.</t>

<t>Any questions, comments, and reports of defects or ambiguities in this specification may be sent to the mailing list for the NOTARY working group of the IETF, using the address &lt;notifications@cs.utk.edu&gt;.  Requests to subscribe to the mailing list should be addressed to &lt;notifications-request@cs.utk.edu&gt;. Implementors of this specification are encouraged to subscribe to the mailing list, so that they will quickly be informed of any problems which might hinder interoperability.</t>

<t>NOTE: This document is a Proposed Standard.  If and when this protocol is submitted for Draft Standard status, any normative text (phrases containing SHOULD, SHOULD NOT, MUST, MUST NOT, or MAY) in this document will be re-evaluated in light of implementation experience, and are thus subject to change.</t>
</abstract>
</front>

<seriesInfo value="1894" name="RFC" />
</reference>


<reference target2="reference.RFC.1895.xml" anchor="RFC1895">
<front>
<title abbrev="CALS-1840">The Application/CALS-1840 Content-type</title>
<author fullname="Edward Levinson" initials="E." surname="Levinson">
<organization>Accurate Information Systems, Inc.</organization>

<address>
<postal>
<street>2 Industrial Way</street>
<city>Eatontown</city>
<region>NJ</region>
<code>07724-2265</code>
<country>US</country>
</postal>

<phone>+1 908 389 5550</phone>
<email>ELevinson@Accurate.com</email>
</address>
</author>

<date year="1996" month="February" />

<abstract>
<t>This memorandum provides guidelines for using the United States Department of Defense Military Standard MIL-STD-1840, "Automated Interchange of Technical Information," with the Internet electronic mail standards, RFC 822 and RFC 1521.  Electronic mail provides a more convenient mechanism that delivery via physical media for certain types and quantities of data.  Software already exists to support data exchanges based on MIL-STD-1840 and it can continue to be used in conjunction with electronic mail exchanges defined in this document.  This document defines a new media type and a MIME message structure for exchanging data in conformance with MIL-STD-1840.</t>
</abstract>
</front>

<seriesInfo value="1895" name="RFC" />
</reference>


<reference target2="reference.RFC.1896.xml" anchor="RFC1896">
<front>
<title abbrev="text/enriched MIME Content-type">The text/enriched MIME Content-type</title>
<author fullname="Peter W. Resnick" initials="P." surname="Resnick">
<organization>QUALCOMM Incorporated</organization>

<address>
<postal>
<street>6455 Lusk Boulevard</street>
<city>San Diego</city>
<region>CA</region>
<code>92121-2779</code>
<country>US</country>
</postal>

<phone>+1 619 587 1121</phone>
<facsimile>+1 619 658 2230</facsimile>
<email>presnick@qualcomm.com</email>
</address>
</author>

<author fullname="Amanda Walker" initials="A." surname="Walker">
<organization>InterCon Systems Corporation</organization>

<address>
<postal>
<street>950 Herndon Parkway</street>
<city>Herndon</city>
<region>VA</region>
<code>22070</code>
<country>US</country>
</postal>

<phone>+1 703 709 5500</phone>
<facsimile>+1 703 709 5555</facsimile>
<email>amanda@intercon.com</email>
</address>
</author>

<date year="1996" month="February" />

<abstract>
<t>MIMEdefines a format and general framework for the representation of a wide variety of data types in Internet mail. This document defines one particular type of MIME data, the text/enriched MIME type. The text/enriched MIME type is intended to facilitate the wider interoperation of simple enriched text across a wide variety of hardware and software platforms. This document is only a minor revision to the text/enriched MIME type that was first described inandand is only intended to be used in the short term until other MIME types for text formatting in Internet mail are developed and deployed.</t>
</abstract>
</front>

<seriesInfo value="1896" name="RFC" />
</reference>


<reference target2="reference.RFC.1897.xml" anchor="RFC1897">
<front>
<title>IPv6 Testing Address Allocation</title>
<author fullname="Robert M. Hinden" initials="R." surname="Hinden">
<organization>Ipsilon Networks, Inc.</organization>

<address>
<postal>
<street>2191 E. Bayshore Road</street>
<street>Suite 100</street>
<city>Palo Alto</city>
<region>CA</region>
<code>94303</code>
<country>US</country>
</postal>

<phone>+1 415 846 4604</phone>
<facsimile>+1 415 855 1414</facsimile>
<email>hinden@ipsilon.com</email>
</address>
</author>

<author fullname="Jon Postel" initials="J." surname="Postel">
<organization>University of Southern California,  Information Sciences Institute</organization>

<address>
<postal>
<street>4676 Admiralty Way</street>
<city>Marina del Rey</city>
<region>CA</region>
<code>90292-6695</code>
<country>US</country>
</postal>

<phone>+1 310 822 1511</phone>
<facsimile>+1 310 823 6714</facsimile>
<email>postel@isi.edu</email>
</address>
</author>

<date year="1996" month="January" />

<abstract>
<t></t>
</abstract>
</front>

<seriesInfo value="1897" name="RFC" />
</reference>


<reference target2="reference.RFC.1898.xml" anchor="RFC1898">
<front>
<title abbrev="CyberCash Version 0.8">CyberCash Credit Card Protocol Version 0.8</title>
<author fullname="Donald E. Eastlake 3rd" initials="D." surname="Eastlake">
<organization>CyberCash, Inc.</organization>

<address>
<postal>
<street>318 Acton Street</street>
<city>Carlisle</city>
<region>MA</region>
<code>01741</code>
<country>US</country>
</postal>

<phone>+1 508 287 4877</phone>
<email>dee@cybercash.com</email>
</address>
</author>

<author fullname="Brian Boesch" initials="B." surname="Boesch">
<organization>CyberCash, Inc.</organization>

<address>
<postal>
<street>2100 Reston Parkway</street>
<street>Suite 430</street>
<city>Reston</city>
<region>VA</region>
<code>22091</code>
<country>US</country>
</postal>

<phone>+1 703 620 4200</phone>
<email>boesch@cybercash.com</email>
</address>
</author>

<author fullname="Steve Crocker" initials="S." surname="Crocker">
<organization>CyberCash, Inc.</organization>

<address>
<postal>
<street>2100 Reston Parkway</street>
<street>Suite 430</street>
<city>Reston</city>
<region>VA</region>
<code>22091</code>
<country>US</country>
</postal>

<phone>+1 703 620 4200</phone>
<email>crocker@cybercash.com</email>
</address>
</author>

<author fullname="Magdalena Yesil" initials="M." surname="Yesil">
<organization>CyberCash, Inc.</organization>

<address>
<postal>
<street>555 Twin Dolphin Drive</street>
<street>Suite 570</street>
<city>Redwood City</city>
<region>CA</region>
<code>94065</code>
<country>US</country>
</postal>

<phone>+1 415 594 0800</phone>
<email>magdalen@cybercash.com</email>
</address>
</author>

<date year="1996" month="February" />

<abstract>
<t>CyberCash is developing a general payments system for use over the Internet.  The structure and communications protocols of version 0.8 are described.  This version includes credit card payments only.  Additional capabilities are planned for future versions.</t>

<t>This document covers only the current CyberCash system which is one of the few operational systems in the rapidly evolving area of Internet payments. CyberCash is committed to the further development of its system and to cooperation with the Internet Engineering Task Force and other standards organizations.</t>
</abstract>
</front>

<seriesInfo value="1898" name="RFC" />
</reference>


<reference target2="reference.RFC.1899.xml" anchor="RFC1899">
<front>
<title abbrev="Summary of 1800-1899">Request for Comments Summary RFC Numbers 1800-1899</title>
<author fullname="Josh Elliott" initials="J." surname="Elliott">
<organization>University of Southern California,  Information Sciences Institute</organization>

<address>
<postal>
<street>4676 Admiralty Way</street>
<city>Marina del Rey</city>
<region>CA</region>
<code>90292</code>
<country>US</country>
</postal>

<phone>+1 310 822 1511</phone>
<email>elliott@isi.edu</email>
</address>
</author>

<date year="1997" month="January" />

<abstract>
<t></t>
</abstract>
</front>

<seriesInfo value="1899" name="RFC" />
</reference>


<reference target2="reference.RFC.1900.xml" anchor="RFC1900">
<front>
<title>Renumbering Needs Work</title>
<author fullname="Brian E. Carpenter" initials="B." surname="Carpenter">
<organization>CERN, Computing and Networks Division</organization>

<address>
<postal>
<street>1211 Geneva 23</street>
<country>CH</country>
</postal>

<phone>+41 22 7674967</phone>
<facsimile>+41 22 7677155</facsimile>
<email>brian@dxcoms.cern.ch</email>
</address>
</author>

<author fullname="Yakov Rekhter" initials="Y." surname="Rekhter">
<organization>cisco Systems</organization>

<address>
<postal>
<street>170 West Tasman Drive</street>
<city>San Jose</city>
<region>CA</region>
<code>95134</code>
<country>US</country>
</postal>

<phone>+1 914 528 0090</phone>
<email>yakov@cisco.com</email>
</address>
</author>

<date year="1996" month="February" />

<abstract>
<t>Renumbering, i.e., changes in the IP addressing information of various network components, is likely to become more and more widespread and common. The Internet Architecture Board (IAB) would like to stress the need to develop and deploy solutions that would facilitate such changes.</t>
</abstract>
</front>

<seriesInfo value="1900" name="RFC" />
</reference>


<reference target2="reference.RFC.1901.xml" anchor="RFC1901">
<front>
<title>Introduction to Community-based SNMPv2</title>
<author fullname="Jeffrey D. Case" initials="J.D." surname="Case">
<organization>SNMP Research</organization>

<address>
<email>case@snmp.com</email>
</address>
</author>

<author fullname="Keith McCloghrie" initials="K." surname="McCloghrie">
<organization>Cisco Systems, Inc.</organization>

<address>
<postal>
<street>170 West Tasman Drive</street>
<city>San Jose</city>
<region>CA</region>
<code>95134-1706</code>
<country>US</country>
</postal>

<phone>+1 408 526 5260</phone>
<email>kzm@cisco.com</email>
</address>
</author>

<author fullname="Keith McCloghrie" initials="K." surname="McCloghrie">
<organization>Cisco Systems</organization>

<address>
<email>kzm@cisco.com</email>
</address>
</author>

<author fullname="Marshall T. Rose" initials="M.T." surname="Rose">
<organization>Dover Beach Consulting</organization>

<address>
<email>mrose@dbc.mtview.ca.us</email>
</address>
</author>

<author fullname="Steve  Waldbusser" initials="S." surname="Waldbusser">
<organization>International Network Services,</organization>

<address>
<email>stevew@uni.ins.com</email>
</address>
</author>

<date year="1996" month="January" />

<abstract>
<t></t>
</abstract>
</front>

<seriesInfo value="1901" name="RFC" />
</reference>


<reference target2="reference.RFC.1902.xml" anchor="RFC1902">
<front>
<title abbrev="SMI for SNMPv2">Structure of Management Information for Version 2 of the Simple Network Management Protocol (SNMPv2)</title>
<author fullname="Jeffrey D. Case" initials="J.D." surname="Case">
<organization>SNMP Research</organization>

<address>
<email>case@snmp.com</email>
</address>
</author>

<author fullname="Keith McCloghrie" initials="K." surname="McCloghrie">
<organization>Cisco Systems, Inc.</organization>

<address>
<postal>
<street>170 West Tasman Drive</street>
<city>San Jose</city>
<region>CA</region>
<code>95134-1706</code>
<country>US</country>
</postal>

<phone>+1 408 526 5260</phone>
<email>kzm@cisco.com</email>
</address>
</author>

<author fullname="Marshall T. Rose" initials="M.T." surname="Rose">
<organization>Dover Beach Consulting</organization>

<address>
<email>mrose@dbc.mtview.ca.us</email>
</address>
</author>

<author fullname="Steve  Waldbusser" initials="S." surname="Waldbusser">
<organization>International Network Services,</organization>

<address>
<email>stevew@uni.ins.com</email>
</address>
</author>

<date year="1996" month="January" />

<abstract>
<t></t>
</abstract>
</front>

<seriesInfo value="1902" name="RFC" />
</reference>


<reference target2="reference.RFC.1903.xml" anchor="RFC1903">
<front>
<title abbrev="Textual Conventions for SNMPv2">Textual Conventions for Version 2 of the Simple Network Management Protocol (SNMPv2)</title>
<author fullname="Keith McCloghrie" initials="K." surname="McCloghrie">
<organization>Cisco Systems, Inc.</organization>

<address>
<postal>
<street>170 West Tasman Drive</street>
<city>San Jose</city>
<region>CA</region>
<code>95134-1706</code>
<country>US</country>
</postal>

<phone>+1 408 526 5260</phone>
<email>kzm@cisco.com</email>
</address>
</author>

<author fullname="Jeffrey D. Case" initials="J.D." surname="Case">
<organization>SNMP Research</organization>

<address>
<email>case@snmp.com</email>
</address>
</author>

<author fullname="Marshall T. Rose" initials="M.T." surname="Rose">
<organization>Dover Beach Consulting</organization>

<address>
<email>mrose@dbc.mtview.ca.us</email>
</address>
</author>

<author fullname="Steve  Waldbusser" initials="S." surname="Waldbusser">
<organization>International Network Services,</organization>

<address>
<email>stevew@uni.ins.com</email>
</address>
</author>

<date year="1996" month="January" />

<abstract>
<t></t>
</abstract>
</front>

<seriesInfo value="1903" name="RFC" />
</reference>


<reference target2="reference.RFC.1904.xml" anchor="RFC1904">
<front>
<title abbrev="Conformance Statements for SNMPv2">Conformance Statements for Version 2 of the Simple Network Management Protocol (SNMPv2)</title>
<author fullname="Jeffrey D. Case" initials="J.D." surname="Case">
<organization>SNMP Research</organization>

<address>
<email>case@snmp.com</email>
</address>
</author>

<author fullname="Keith McCloghrie" initials="K." surname="McCloghrie">
<organization>Cisco Systems, Inc.</organization>

<address>
<postal>
<street>170 West Tasman Drive</street>
<city>San Jose</city>
<region>CA</region>
<code>95134-1706</code>
<country>US</country>
</postal>

<phone>+1 408 526 5260</phone>
<email>kzm@cisco.com</email>
</address>
</author>

<author fullname="Marshall T. Rose" initials="M.T." surname="Rose">
<organization>Dover Beach Consulting</organization>

<address>
<email>mrose@dbc.mtview.ca.us</email>
</address>
</author>

<author fullname="Steve  Waldbusser" initials="S." surname="Waldbusser">
<organization>International Network Services,</organization>

<address>
<email>stevew@uni.ins.com</email>
</address>
</author>

<date year="1996" month="January" />

<abstract>
<t></t>
</abstract>
</front>

<seriesInfo value="1904" name="RFC" />
</reference>


<reference target2="reference.RFC.1905.xml" anchor="RFC1905">
<front>
<title abbrev="Protocol Operations for SNMPv2">Protocol Operations for Version 2 of the Simple Network Management Protocol (SNMPv2)</title>
<author fullname="Jeffrey D. Case" initials="J.D." surname="Case">
<organization>SNMP Research</organization>

<address>
<email>case@snmp.com</email>
</address>
</author>

<author fullname="Keith McCloghrie" initials="K." surname="McCloghrie">
<organization>Cisco Systems, Inc.</organization>

<address>
<postal>
<street>170 West Tasman Drive</street>
<city>San Jose</city>
<region>CA</region>
<code>95134-1706</code>
<country>US</country>
</postal>

<phone>+1 408 526 5260</phone>
<email>kzm@cisco.com</email>
</address>
</author>

<author fullname="Marshall T. Rose" initials="M.T." surname="Rose">
<organization>Dover Beach Consulting</organization>

<address>
<email>mrose@dbc.mtview.ca.us</email>
</address>
</author>

<author fullname="Steve  Waldbusser" initials="S." surname="Waldbusser">
<organization>International Network Services,</organization>

<address>
<email>stevew@uni.ins.com</email>
</address>
</author>

<date year="1996" month="January" />

<abstract>
<t></t>
</abstract>
</front>

<seriesInfo value="1905" name="RFC" />
</reference>


<reference target2="reference.RFC.1906.xml" anchor="RFC1906">
<front>
<title abbrev="Transport Mappings for SNMPv2">Transport Mappings for Version 2 of the Simple Network Management Protocol (SNMPv2)</title>
<author fullname="Jeffrey D. Case" initials="J.D." surname="Case">
<organization>SNMP Research</organization>

<address>
<email>case@snmp.com</email>
</address>
</author>

<author fullname="Keith McCloghrie" initials="K." surname="McCloghrie">
<organization>Cisco Systems, Inc.</organization>

<address>
<postal>
<street>170 West Tasman Drive</street>
<city>San Jose</city>
<region>CA</region>
<code>95134-1706</code>
<country>US</country>
</postal>

<phone>+1 408 526 5260</phone>
<email>kzm@cisco.com</email>
</address>
</author>

<author fullname="Marshall T. Rose" initials="M.T." surname="Rose">
<organization>Dover Beach Consulting</organization>

<address>
<email>mrose@dbc.mtview.ca.us</email>
</address>
</author>

<author fullname="Steve  Waldbusser" initials="S." surname="Waldbusser">
<organization>International Network Services,</organization>

<address>
<email>stevew@uni.ins.com</email>
</address>
</author>

<date year="1996" month="January" />

<abstract>
<t></t>
</abstract>
</front>

<seriesInfo value="1906" name="RFC" />
</reference>


<reference target2="reference.RFC.1907.xml" anchor="RFC1907">
<front>
<title abbrev="Management Information Base for SNMPv2">Management Information Base for Version 2 of the Simple Network Management Protocol (SNMPv2)</title>
<author fullname="Jeffery D. Case" initials="J." surname="Case">
<organization>SNMP Research</organization>

<address>
<email>case@snmp.com</email>
</address>
</author>

<author fullname="Keith McCloghrie" initials="K." surname="McCloghrie">
<organization>Cisco Systems, Inc.</organization>

<address>
<postal>
<street>170 West Tasman Drive</street>
<city>San Jose</city>
<region>CA</region>
<code>95134-1706</code>
<country>US</country>
</postal>

<phone>+1 408 526 5260</phone>
<email>kzm@cisco.com</email>
</address>
</author>

<author fullname="Marshall T. Rose" initials="M." surname="Rose">
<organization>Dover Beach Consulting</organization>

<address>
<email>mrose@dbc.mtview.ca.us</email>
</address>
</author>

<author fullname="Steven Waldbusser" initials="S." surname="Waldbusser">
<organization>International Network Services</organization>

<address>
<email>stevew@uni.ins.com</email>
</address>
</author>

<date year="1996" month="January" />
</front>

<seriesInfo value="1907" name="RFC" />
</reference>


<reference target2="reference.RFC.1908.xml" anchor="RFC1908">
<front>
<title abbrev="Coexistence between SNMPv1 and SNMPv2">Coexistence between Version 1 and Version 2 of the Internet-standard Network Management Framework</title>
<author fullname="Jeffery D. Case" initials="J." surname="Case">
<organization>SNMP Research</organization>

<address>
<email>case@snmp.com</email>
</address>
</author>

<author fullname="Keith McCloghrie" initials="K." surname="McCloghrie">
<organization>Cisco Systems, Inc.</organization>

<address>
<postal>
<street>170 West Tasman Drive</street>
<city>San Jose</city>
<region>CA</region>
<code>95134-1706</code>
<country>US</country>
</postal>

<phone>+1 408 526 5260</phone>
<email>kzm@cisco.com</email>
</address>
</author>

<author fullname="Marshall T. Rose" initials="M." surname="Rose">
<organization>Dover Beach Consulting</organization>

<address>
<email>mrose@dbc.mtview.ca.us</email>
</address>
</author>

<author fullname="Steven Waldbusser" initials="S." surname="Waldbusser">
<organization>International Network Services</organization>

<address>
<email>stevew@uni.ins.com</email>
</address>
</author>

<date year="1996" month="January" />
</front>

<seriesInfo value="1908" name="RFC" />
</reference>


<reference target2="reference.RFC.1909.xml" anchor="RFC1909">
<front>
<title abbrev="An SNMPv2 Administrative Infrastructure">An Administrative Infrastructure for SNMPv2</title>
<author fullname="Keith McCloghrie" initials="K." surname="McCloghrie">
<organization>Cisco Systems, Inc.</organization>

<address>
<postal>
<street>170 West Tasman Drive</street>
<city>San Jose</city>
<region>CA</region>
<code>95134-1706</code>
<country>US</country>
</postal>

<phone>+1 408 526 5260</phone>
<email>kzm@cisco.com</email>
</address>
</author>

<author fullname="Marshall T. Rose" initials="M." surname="Rose">
<organization>Dover Beach Consulting</organization>

<address>
<email>mrose@dbc.mtview.ca.us</email>
</address>
</author>

<author fullname="Glenn W. Waters" initials="G." surname="Waters">
<organization>Bell-Northern Research Ltd.</organization>

<address>
<email>gwaters@bnr.ca</email>
</address>
</author>

<date year="1996" month="February" />
</front>

<seriesInfo value="1909" name="RFC" />
</reference>


<reference target2="reference.RFC.1910.xml" anchor="RFC1910">
<front>
<title>User-based Security Model for SNMPv2</title>
<author fullname="Glenn W. Waters" initials="G." surname="Waters">
<organization>Bell-Northern Research Ltd.</organization>

<address>
<postal>
<street>P.O. Box 3511</street>
<street>Station C</street>
<city>Ottawa</city>
<region>Ontario</region>
<code>K1Y 4H7</code>
<country>CA</country>
</postal>

<phone>+1 613 763 3933</phone>
<email>gwaters@bnr.ca</email>
</address>
</author>

<author fullname="Keith McCloghrie" initials="K." surname="McCloghrie">
<organization>Cisco Systems, Inc.</organization>

<address>
<email>kzm@cisco.com</email>
</address>
</author>

<author fullname="Marshall T. Rose" initials="M." surname="Rose">
<organization>Dover Beach Consulting</organization>

<address>
<email>mrose@dbc.mtview.ca.us</email>
</address>
</author>

<date year="1996" month="February" />
</front>

<seriesInfo value="1910" name="RFC" />
</reference>


<reference target2="reference.RFC.1911.xml" anchor="RFC1911">
<front>
<title abbrev="MIME Voice Profile">Voice Profile for Internet Mail</title>
<author fullname="Gregory M. Vaudreuil" initials="G." surname="Vaudreuil">
<organization>Octel Network Services</organization>

<address>
<postal>
<street>17080 Dallas Parkway</street>
<city>Dallas</city>
<region>TX</region>
<code>75248-1905</code>
<country>US</country>
</postal>

<phone>+1 214 733 2722</phone>
<facsimile>+1 214 733 2722</facsimile>
<email>Greg.Vaudreuil@Octel.Com</email>
</address>
</author>

<date year="1996" month="February" />

<abstract>
<t>A class of special-purpose computers has evolved to provide voice messaging services.  These machines generally interface to a telephone switch and provide call answering and voice messaging services.  Traditionally, messages sent to a non-local machine are transported using analog networking protocols based on DTMF signaling and analog voice playback.  As the demand for networking increases, there is a need for a standard high-quality digital protocol to connect these machines.  The following document is a profile of the
   Internet standard MIME and ESMTP protocols for use as a digital voice networking protocol.</t>

<t>This profile is based on an earlier effort in the Audio Message Interchange Specification (AMIS) group to define a voice messaging protocol based on X.400 technology.  This protocol is intended to satisfy the user requirements statement from that earlier work with the industry standard ESMTP/MIME mail protocol infrastructures already used within corporate internets.  This profile will be called the voice profile in this document.</t>
</abstract>
</front>

<seriesInfo value="1911" name="RFC" />
</reference>


<reference target2="reference.RFC.1912.xml" anchor="RFC1912">
<front>
<title abbrev="Common DNS Errors">Common DNS Operational and Configuration Errors</title>
<author fullname="David Barr" initials="D." surname="Barr">
<organization>The Pennsylvania State University, Department of Mathematics</organization>

<address>
<postal>
<street>334 Whitmore Building</street>
<city>University Park</city>
<region>PA</region>
<code>16802</code>
<country>US</country>
</postal>

<phone>+1 814 863 7374</phone>
<facsimile>+1 814 863 8311</facsimile>
<email>barr@math.psu.edu</email>
</address>
</author>

<date year="1996" month="February" />

<abstract>
<t>This memo describes errors often found in both the operation of Domain Name System (DNS) servers, and in the data that these DNS servers contain.  This memo tries to summarize current Internet requirements as well as common practice in the operation and configuration of the DNS.  This memo also tries to summarize or expand upon issues raised in.</t>
</abstract>
</front>

<seriesInfo value="1912" name="RFC" />
</reference>


<reference target2="reference.RFC.1913.xml" anchor="RFC1913">
<front>
<title>Architecture of the Whois++ Index Service</title>
<author fullname="Chris Weider" initials="C." surname="Weider">
<organization>Bunyip Information Systems, Inc.</organization>

<address>
<postal>
<street>310 St. Catherine St. West</street>
<city>Montreal</city>
<region>Quebec</region>
<code>H2X 2A1</code>
<country>CA</country>
</postal>

<phone>+1 514 875 8611</phone>
<facsimile>+1 514 875 6134</facsimile>
<email>clw@bunyip.com</email>
</address>
</author>

<author fullname="Jim Fullton" initials="J." surname="Fullton">
<organization>MCNC Center for Communications</organization>

<address>
<postal>
<street>3021 Cornwallis Road</street>
<street>Post Office Box 12889</street>
<city>Research Triangle Park</city>
<region>NC</region>
<code>27709-2889</code>
<country>US</country>
</postal>

<phone>+1 410 795 5422</phone>
<facsimile>+1 410 795 5422</facsimile>
<email>fullton@cnidr.org</email>
</address>
</author>

<author fullname="Simon Spero" initials="S." surname="Spero">
<organization />

<address>
<email>ses@eit.com</email>
</address>
</author>

<date year="1996" month="February" />

<abstract>
<t>The authors describe an architecture for indexing in distributed databases, and apply this to the WHOIS++ protocol.</t>
</abstract>
</front>

<seriesInfo value="1913" name="RFC" />
</reference>


<reference target2="reference.RFC.1914.xml" anchor="RFC1914">
<front>
<title>How to Interact with a Whois++ Mesh</title>
<author fullname="Patrik Faltstrom" initials="P." surname="Faltstrom">
<organization>Bunyip Information Systems, Inc.</organization>

<address>
<postal>
<street>310 St. Catherine St. West</street>
<street>Suite 300</street>
<city>Montreal</city>
<region>Quebec</region>
<code>H2X 2A1</code>
<country>CA</country>
</postal>

<phone>+1 514 875 8611</phone>
<email>paf@bunyip.com</email>
</address>
</author>

<author fullname="Rickard Schoultz" initials="R." surname="Schoultz">
<organization>KTHNOC, SUNET/NORDUnet/Ebone Operations Centre</organization>

<address>
<postal>
<street />
<city>Stockholm</city>
<region />
<code>S-100 44</code>
<country>SE</country>
</postal>

<email>schoultz@sunet.se</email>
</address>
</author>

<author fullname="Chris Weider" initials="C." surname="Weider">
<organization>Bunyip Information Systems, Inc.</organization>

<address>
<postal>
<street>310 St. Catherine St. West</street>
<street>Suite 300</street>
<city>Montreal</city>
<region>Quebec</region>
<code>H2X 2A1</code>
<country>CA</country>
</postal>

<email>clw@bunyip.com</email>
</address>
</author>

<date year="1996" month="February" />
</front>

<seriesInfo value="1914" name="RFC" />
</reference>


<reference target2="reference.RFC.1915.xml" anchor="RFC1915">
<front>
<title abbrev="PPP ECP and CCP Variance">Variance for The PPP Connection Control Protocol and The PPP Encryption Control Protocol</title>
<author fullname="Frank Kastenholz" initials="F." surname="Kastenholz">
<organization>FTP Software, Inc</organization>

<address>
<postal>
<street>2 High Street</street>
<city>North Andover</city>
<region>MA</region>
<code>01845-2620</code>
<country>US</country>
</postal>

<email>kasten@ftp.com</email>
</address>
</author>

<date year="1996" month="February" />
</front>

<seriesInfo value="3" name="BCP" />
<seriesInfo value="1915" name="RFC" />
</reference>


<reference target2="reference.RFC.1916.xml" anchor="RFC1916">
<front>
<title abbrev="Enterprise Renumbering Solicitation">Enterprise Renumbering: Experience and Information Solicitation</title>
<author fullname="Howard C. Berkowitz" initials="H." surname="Berkowitz">
<organization>PSC International</organization>

<address>
<postal>
<street>8260 Greensboro Drive</street>
<street>Suite 330</street>
<city>McLean</city>
<region>VA</region>
<code>22102</code>
<country>US</country>
</postal>

<phone>+1 703 998 5819</phone>
<facsimile>+1 703 998 5058</facsimile>
<email>hcb@clark.net</email>
</address>
</author>

<author fullname="Paul Ferguson" initials="P." surname="Ferguson">
<organization>cisco Systems, Inc.</organization>

<address>
<postal>
<street>1835 Alexander Bell Drive</street>
<street>Suite 100</street>
<city>Reston</city>
<region>VA</region>
<code>22091</code>
<country>US</country>
</postal>

<phone>+1 703 716 9538</phone>
<facsimile>+1 703 716 9538</facsimile>
<email>pferguso@cisco.com</email>
</address>
</author>

<author fullname="Will E. Leland" initials="W." surname="Leland">
<organization>Bellcore</organization>

<address>
<postal>
<street>445 South Street</street>
<street>Room 1A-228B</street>
<city>Morristown</city>
<region>NJ</region>
<code>07960-6438</code>
<country>US</country>
</postal>

<phone>+1 201 829 4376</phone>
<facsimile>+1 201 829 2504</facsimile>
<email>wel@bellcore.com</email>
</address>
</author>

<author fullname="Philip J. Nesser II" initials="P." surname="Nesser">
<organization>Nesser and Nesser Consulting</organization>

<address>
<postal>
<street>16015 84th Ave. NE</street>
<city>Bothell</city>
<region>WA</region>
<code>98011</code>
<country>US</country>
</postal>

<phone>+1 206 488 6268</phone>
<email>pjnesser@rocket.com</email>
</address>
</author>

<date year="1996" month="February" />

<abstract>
<t>Because of the urgent need for, and substantial difficulty in, renumbering IP networks, the PIER working group is compiling a series of documents to assist sites in their renumbering efforts.  The intent of these documents is to provide both educational and practical information to the Internet community. To this end the working group is soliciting information from organizations that already have gone through, or are in the process of going through, renumbering efforts. Case studies, tools, and lists of applications that require special attention are sought.</t>
</abstract>
</front>

<seriesInfo value="1916" name="RFC" />
</reference>


<reference target2="reference.RFC.1917.xml" anchor="RFC1917">
<front>
<title abbrev="Appeal to Return Unused IP Networks to IANA">An Appeal to the Internet Community to Return Unused IP Networks (Prefixes) to the IANA</title>
<author fullname="Philip J. Nesser II" initials="P." surname="Nesser">
<organization>Nesser and Nesser Consulting</organization>

<address>
<postal>
<street>16015 84th Ave. NE</street>
<city>Bothell</city>
<region>WA</region>
<code>98011</code>
<country>US</country>
</postal>

<phone>+1 206 488 6268</phone>
<facsimile>+1 206 488 6268</facsimile>
<email>pjnesser@martigny.ai.mit.edu</email>
</address>
</author>

<date year="1996" month="February" />

<abstract>
<t>This document is an appeal to the Internet community to return unused address space, i.e. any block of consecutive IP prefixes, to the Internet Assigned Numbers Authority (IANA) or any of the delegated registries, for reapportionment.  Similarly an appeal is issued to providers to return unused prefixes which fall outside their customary address blocks to the IANA for reapportionment.</t>
</abstract>
</front>

<seriesInfo value="4" name="BCP" />
<seriesInfo value="1917" name="RFC" />
</reference>


<reference target2="reference.RFC.1918.xml" anchor="RFC1918">
<front>
<title>Address Allocation for Private Internets</title>
<author fullname="Yakov Rekhter" initials="Y." surname="Rekhter">
<organization>Cisco systems</organization>

<address>
<postal>
<street>170 West Tasman Drive</street>
<city>San Jose</city>
<region>CA</region>
<code>95134-1706</code>
<country>US</country>
</postal>

<phone>+1 914 528 0090</phone>
<facsimile>+1 408 526 4952</facsimile>
<email>yakov@cisco.com</email>
</address>
</author>

<author fullname="Robert G. Moskowitz" initials="R." surname="Moskowitz">
<organization>Chrysler Corporation</organization>

<address>
<postal>
<street>25999 Lawrence Ave</street>
<city>Center Line</city>
<region>MI</region>
<code>48015</code>
<country>US</country>
</postal>

<phone>+1 810 758 8212</phone>
<facsimile>+1 810 758 8173</facsimile>
<email>rgm3@is.chrysler.com</email>
</address>
</author>

<author fullname="Daniel Karrenberg" initials="D." surname="Karrenberg">
<organization>RIPE Network Coordination Centre</organization>

<address>
<postal>
<street>Kruislaan 409</street>
<city>Amsterdam</city>
<region />
<code>1098 SJ</code>
<country>NL</country>
</postal>

<phone>+31 20 5925065</phone>
<facsimile>+31 20 5925090</facsimile>
<email>Daniel.Karrenberg@ripe.net</email>
</address>
</author>

<author fullname="Geert Jan de Groot" initials="G." surname="Groot">
<organization>RIPE Network Coordination Centre</organization>

<address>
<postal>
<street>Kruislaan 409</street>
<city>Amsterdam</city>
<region />
<code>1098 SJ</code>
<country>NL</country>
</postal>

<phone>+31 20 5925065</phone>
<facsimile>+31 20 5925090</facsimile>
<email>GeertJan.deGroot@ripe.net</email>
</address>
</author>

<author fullname="Eliot Lear" initials="E." surname="Lear">
<organization>Silicon Graphics, Inc.</organization>

<address>
<postal>
<street>2011 N. Shoreline Blvd.</street>
<street>Mail Stop 15-730</street>
<city>Mountain View</city>
<region>CA</region>
<code>94043-1389</code>
<country>US</country>
</postal>

<phone>+1 415 960 1980</phone>
<facsimile>+1 415 961 9584</facsimile>
<email>lear@sgi.com</email>
</address>
</author>

<date year="1996" month="February" />
</front>

<seriesInfo value="5" name="BCP" />
<seriesInfo value="1918" name="RFC" />
</reference>


<reference target2="reference.RFC.1919.xml" anchor="RFC1919">
<front>
<title>Classical versus Transparent IP Proxies</title>
<author fullname="Marc Chatel" initials="M." surname="Chatel">
<organization />

<address>
<postal>
<street>9 avenue Jean Monnet</street>
<city>Annecy-Le-Vieux</city>
<region />
<code>74940</code>
<country>FR</country>
</postal>

<email>mchatel@pax.eunet.ch</email>
</address>
</author>

<date year="1996" month="March" />

<abstract>
<t>Many modern IP security systems (also called "firewalls" in the trade) make use of proxy technology to achieve access control.  This document explains "classical" and "transparent" proxy techniques and attempts to provide rules to help determine when each proxy system may be used without causing problems.</t>
</abstract>
</front>

<seriesInfo value="1919" name="RFC" />
</reference>


<reference target2="reference.RFC.1920.xml" anchor="RFC1920">
<front>
<title abbrev="Internet Standards">Internet Official Protocol Standards</title>
<author fullname="Jon Postel" initials="J." surname="Postel">
<organization>USC/Information Sciences Institute</organization>

<address>
<postal>
<street>4676 Admiralty Way</street>
<city>Marina del Rey</city>
<region>CA</region>
<code>90292</code>
<country>US</country>
</postal>

<phone>+1 310 822 1511</phone>
<facsimile>+1 310 823 6714</facsimile>
<email>Postel@ISI.EDU</email>
</address>
</author>

<date year="1996" month="March" />
</front>

<seriesInfo value="1920" name="RFC" />
</reference>


<reference target2="reference.RFC.1921.xml" anchor="RFC1921">
<front>
<title>TNVIP Protocol</title>
<author fullname="Jean-Yves Dujonc" initials="J." surname="Dujonc">
<organization>BULL S.A.</organization>

<address>
<postal>
<street>rue Jean Jaures</street>
<city>Les Clayes-sous-Bois</city>
<region />
<code>78340</code>
<country>FR</country>
</postal>

<phone>+33 1 30806295</phone>
<facsimile>+33 1 30806540</facsimile>
<email>J.Y.Dujonc@frcl.bull.fr</email>
</address>
</author>

<date year="1996" month="March" />

<abstract>
<t>The goal of this document specifies a Telnet profile to support VIP terminal emulation allowing the access to the BULL hosts applications through a TCP/IP network.</t>
</abstract>
</front>

<seriesInfo value="1921" name="RFC" />
</reference>


<reference target2="reference.RFC.1922.xml" anchor="RFC1922">
<front>
<title abbrev="Chinese Character Encoding">Chinese Character Encoding for Internet Messages</title>
<author fullname="Zhu Haifeng" initials="Z." surname="Haifeng">
<organization>Tsinghua University</organization>

<address>
<postal>
<street>216 Central Main Building</street>
<city>Beijing</city>
<region />
<code>100084</code>
<country>CN</country>
</postal>

<phone>+86 10 2561144x3492</phone>
<facsimile>+86 10 2564173</facsimile>
<email>zhf@net.tsinghua.edu.cn</email>
</address>
</author>

<author fullname="Hu Daoyuan" initials="H." surname="Daoyuan">
<organization>Tsinghua University, Tsinghua Networking Center</organization>

<address>
<postal>
<street />
<city>Beijing</city>
<region />
<code>100084</code>
<country>CN</country>
</postal>

<phone>+86 10 2594016</phone>
<facsimile>+86 10 2564173</facsimile>
<email>hdy@tsinghua.edu.cn</email>
</address>
</author>

<author fullname="Wang Zhiguan" initials="W." surname="Zhiguan">
<organization>China Information Technology Standardization Technical Committee (CITS)</organization>

<address>
<postal>
<street />
<city>Beijing</city>
<region />
<code>10007</code>
<country>CN</country>
</postal>

<phone>+86 10 4012392</phone>
<facsimile>+86 10 4010601</facsimile>
</address>
</author>

<author fullname="Kao Tien-cheu" initials="K." surname="Tien-cheu">
<organization>Institute for Information Industry (III), I.T. Promotion Division</organization>

<address>
<postal>
<street />
<city>Taipei</city>
<region />
<code />
<country>TW</country>
</postal>

<phone>+886 2 5631688</phone>
<facsimile>+886 2 5634209</facsimile>
<email>tckao@iiidns.iii.org.tw</email>
</address>
</author>

<author fullname="Chang Wen-chung" initials="C." surname="Wen-chung">
<organization>Institute for Information Industry (III)</organization>

<address>
<postal>
<street />
<city>Taipei</city>
<region />
<code />
<country>TW</country>
</postal>

<phone>+886 2 7327771</phone>
<facsimile>+886 2 7370188</facsimile>
<email>chung@iiidns.iii.org.tw</email>
</address>
</author>

<author fullname="Mark R. Crispin" initials="M." surname="Crispin">
<organization>University of Washington, Networks and Distributed Computing-</organization>

<address>
<postal>
<street>4545 15th Avenue NE</street>
<city>Seattle</city>
<region>WA</region>
<code>98105-4527</code>
<country>US</country>
</postal>

<phone>+1 206 543 5762</phone>
<facsimile>+1 206 685 4045</facsimile>
<email>MRC@CAC.Washington.EDU</email>
</address>
</author>

<date year="1996" month="March" />

<abstract>
<t>This memo describes methods of transporting Chinese characters in Internet services which transport text, such as electronic mail,  network news, telnetand the World  Wide Web.</t>
</abstract>
</front>

<seriesInfo value="1922" name="RFC" />
</reference>


<reference target2="reference.RFC.1923.xml" anchor="RFC1923">
<front>
<title>RIPv1 Applicability Statement for Historic Status</title>
<author fullname="Joel M. Halpern" initials="J." surname="Halpern">
<organization>Newbridge Networks Inc.</organization>

<address>
<postal>
<street>593 Herndon Parkway</street>
<city>Herndon</city>
<region>VA</region>
<code>22070-5241</code>
<country>US</country>
</postal>

<phone>+1 703 708 5954</phone>
<email>jhalpern@newbridge.com</email>
</address>
</author>

<author fullname="Scott Bradner" initials="S." surname="Bradner">
<organization>Harvard University</organization>

<address>
<postal>
<street>1350 Mass Ave</street>
<street>Room 813</street>
<city>Cambridge</city>
<region>MA</region>
<code>02138</code>
<country>US</country>
</postal>

<phone>+1 617 495 3864</phone>
<email>sob@harvard.edu</email>
</address>
</author>

<date year="1996" month="March" />

<abstract>
<t>RIP Version 1has been declared an historic document. This Applicability statement provides the supporting motivation for that declaration.  The primary reason, as described below, is the Classful nature of RIPv1.</t>
</abstract>
</front>

<seriesInfo value="1923" name="RFC" />
</reference>


<reference target2="reference.RFC.1924.xml" anchor="RFC1924">
<front>
<title>A Compact Representation of IPv6 Addresses</title>
<author fullname="Robert Elz" initials="R." surname="Elz">
<organization>University of Melbourne, Computer Science</organization>

<address>
<postal>
<street />
<city>Parkville</city>
<region>Victoria</region>
<code>3052</code>
<country>AU</country>
</postal>

<email>kre@munnari.OZ.AU</email>
</address>
</author>

<date year="1996" month="April" day="1" />

<abstract>
<t>IPv6 addresses, being 128 bits long, need 32 characters to write in the general case, if standard hex representation, is used, plus more for any punctuation inserted (typically about another 7 characters, or 39 characters total).  This document specifies a more compact representation of IPv6 addresses, which permits encoding in a mere 20 bytes.</t>
</abstract>
</front>

<seriesInfo value="1924" name="RFC" />
</reference>


<reference target2="reference.RFC.1925.xml" anchor="RFC1925">
<front>
<title abbrev="Fundamental Truths of Networking">The Twelve Networking Truths</title>
<author fullname="Ross Callon" initials="R." surname="Callon">
<organization>Internet Order of Old Farts</organization>

<address>
<postal>
<street>3 Federal Street</street>
<city>Billerica</city>
<region>MA</region>
<code>01821</code>
<country>US</country>
</postal>

<phone>+1 508 436 3936</phone>
<email>rcallon@baynetworks.com</email>
</address>
</author>

<date year="1996" month="April" day="1" />

<abstract>
<t>This memo documents the fundamental truths of networking for the Internet community. This memo does not specify a standard, except in the sense that all standards must implicitly follow the fundamental truths.</t>
</abstract>
</front>

<seriesInfo value="1925" name="RFC" />
</reference>


<reference target2="reference.RFC.1926.xml" anchor="RFC1926">
<front>
<title abbrev="IP over ATM">An Experimental Encapsulation of IP Datagrams on Top of ATM</title>
<author fullname="Johnny Eriksson" initials="J." surname="Eriksson">
<organization>KTH NOC</organization>

<address>
<email>bygg@sunet.se</email>
</address>
</author>

<date year="1996" month="April" day="1" />

<abstract>
<t>This RFC describes a method of encapsulating IP datagrams on top of Acoustical Transmission Media (ATM).  This is a non-recommended standard.  Distribution of this memo is unnecessary.</t>
</abstract>
</front>

<seriesInfo value="1926" name="RFC" />
</reference>


<reference target2="reference.RFC.1927.xml" anchor="RFC1927">
<front>
<title abbrev="MIME Types: Associating Documents">Suggested Additional MIME Types for Associating Documents</title>
<author fullname="Craig Milo Rogers" initials="C." surname="Rogers">
<organization>USC/Information Sciences Institute</organization>

<address>
<postal>
<street>4676 Admiralty Way</street>
<city>Marina del Rey</city>
<region>CA</region>
<code>90292</code>
<country>US</country>
</postal>

<phone>+1 310 822 1511</phone>
<email>rogers@isi.edu</email>
</address>
</author>

<date year="1996" month="April" day="1" />
</front>

<seriesInfo value="1927" name="RFC" />
</reference>


<reference target2="reference.RFC.1928.xml" anchor="RFC1928">
<front>
<title>SOCKS Protocol Version 5</title>
<author fullname="Marcus Leech" initials="M." surname="Leech">
<organization>Bell-Northern Research Ltd</organization>

<address>
<postal>
<street>P.O. Box 3511</street>
<street>Stn. C</street>
<city>Ottawa</city>
<region>Ontario</region>
<code>K1Y 4H7</code>
<country>CA</country>
</postal>

<phone>+1 613 763 9145</phone>
<email>mleech@bnr.ca</email>
</address>
</author>

<author fullname="M. Ganis" initials="M." surname="Ganis">
<organization>International Business Machines</organization>
</author>

<author fullname="Y. Lee" initials="Y." surname="Lee">
<organization>NEC Systems Laboratory</organization>
</author>

<author fullname="R. Kuris" initials="R." surname="Kuris">
<organization>Unify Corporation</organization>
</author>

<author fullname="D. Koblas" initials="D." surname="Koblas">
<organization>Independent Consultant</organization>
</author>

<author fullname="L. Jones" initials="L." surname="Jones">
<organization>Hewlett-Packard Company</organization>
</author>

<date year="1996" month="March" />
</front>

<seriesInfo value="1928" name="RFC" />
</reference>


<reference target2="reference.RFC.1929.xml" anchor="RFC1929">
<front>
<title abbrev="Username Authentication for SOCKS V5">Username/Password Authentication for SOCKS V5</title>
<author fullname="Marcus Leech" initials="M." surname="Leech">
<organization>Bell-Northern Research Ltd</organization>

<address>
<postal>
<street>P.O. Box 3511</street>
<street>Station C</street>
<city>Ottawa</city>
<region>Ontario</region>
<code>K1Y 4H7</code>
<country>CA</country>
</postal>

<phone>+1 613 763 9145</phone>
<email>mleech@bnr.ca</email>
</address>
</author>

<date year="1996" month="March" />
</front>

<seriesInfo value="1929" name="RFC" />
</reference>


<reference target2="reference.RFC.1930.xml" anchor="RFC1930">
<front>
<title abbrev="Guidelines for creation of an AS">Guidelines for creation, selection, and registration of an Autonomous System (AS)</title>
<author fullname="John Hawkinson" initials="J." surname="Hawkinson">
<organization>BBN Planet Corporation</organization>

<address>
<postal>
<street>150 CambridgePark Drive</street>
<city>Cambridge</city>
<region>MA</region>
<code>02139</code>
<country>US</country>
</postal>

<phone>+1 617 873 3180</phone>
<email>jhawk@bbnplanet.com</email>
</address>
</author>

<author fullname="Tony Bates" initials="T." surname="Bates">
<organization>MCI</organization>

<address>
<postal>
<street>2100 Reston Parkway</street>
<city>Reston</city>
<region>VA</region>
<code>22094</code>
<country>US</country>
</postal>

<phone>+1 703 715 7521</phone>
<email>Tony.Bates@mci.net</email>
</address>
</author>

<date year="1996" month="March" />

<abstract>
<t>This memo discusses when it is appropriate to register and utilize an Autonomous System (AS), and lists criteria for such.  ASes are the unit of routing policy in the modern world of exterior routing, and are specifically applicable to protocols like EGP (Exterior Gateway Protocol, now at historical status; see, BGP (Border Gateway Protocol, the current de facto standard for inter-AS routing; see, and IDRP (The OSI Inter-Domain Routing Protocol, which the Internet is expected to adopt when BGP becomes obsolete; see. It should be noted that the IDRP equivalent of an AS is the RDI, or Routing Domain Identifier.</t>
</abstract>
</front>

<seriesInfo value="6" name="BCP" />
<seriesInfo value="1930" name="RFC" />
</reference>


<reference target2="reference.RFC.1931.xml" anchor="RFC1931">
<front>
<title abbrev="Dynamic RARP">Dynamic RARP Extensions for Automatic Network Address Acquisition</title>
<author fullname="David Brownell" initials="D." surname="Brownell">
<organization>SunSoft, Inc</organization>

<address>
<postal>
<street>2550 Garcia Way</street>
<street>MS 19-215</street>
<city>Mountain View</city>
<region>CA</region>
<code>94043</code>
<country>US</country>
</postal>

<phone>+1 415 336 1615</phone>
<email>dbrownell@sun.com</email>
</address>
</author>

<date year="1996" month="April" />
</front>

<seriesInfo value="1931" name="RFC" />
</reference>


<reference target2="reference.RFC.1932.xml" anchor="RFC1932">
<front>
<title>IP over ATM: A Framework Document</title>
<author fullname="Robert G. Cole" initials="R." surname="Cole">
<organization>AT&amp;T Bell Laboratories</organization>

<address>
<postal>
<street>101 Crawfords Corner Road</street>
<street>Rm. 3L-533</street>
<city>Holmdel</city>
<region>NJ</region>
<code>07733</code>
<country>US</country>
</postal>

<phone>+1 908 949 1950</phone>
<facsimile>+1 908 949 8887</facsimile>
<email>rgc@qsun.att.com</email>
</address>
</author>

<author fullname="David H. Shur" initials="D." surname="Shur">
<organization>AT&amp;T Bell Laboratories</organization>

<address>
<postal>
<street>101 Crawfords Corner Road</street>
<street>Rm. 1F-338</street>
<city>Holmdel</city>
<region>NJ</region>
<code>07733</code>
<country>US</country>
</postal>

<phone>+1 908 949 6719</phone>
<facsimile>+1 908 949 5775</facsimile>
<email>d.shur@att.com</email>
</address>
</author>

<author fullname="Curtis Villamizar" initials="C." surname="Villamizar">
<organization>ANS</organization>

<address>
<postal>
<street>100 Clearbrook Road</street>
<city>Elmsford</city>
<region>NY</region>
<code>10523</code>
<country>US</country>
</postal>

<email>curtis@ans.net</email>
</address>
</author>

<date year="1996" month="April" />

<abstract>
<t>The discussions of the IP over ATM working group over the last several years have produced a diverse set of proposals, some of which are no longer under active consideration.  A categorization is provided for the purpose of focusing discussion on the various proposals for IP over ATM deemed of primary interest by the IP over ATM working group.  The intent of this framework is to help clarify the differences between proposals and identify common features in order to promote convergence to a smaller and more mutually compatible set of standards.  In summary, it is hoped that this document, in classifying ATM approaches and issues will help to focus the IP over ATM working group's direction.</t>
</abstract>
</front>

<seriesInfo value="1932" name="RFC" />
</reference>


<reference target2="reference.RFC.1933.xml" anchor="RFC1933">
<front>
<title abbrev="IPv6 Transition Mechanisms">Transition Mechanisms for IPv6 Hosts and Routers</title>
<author fullname="Robert E. Gilligan" initials="R." surname="Gilligan">
<organization>Sun Microsystems, Inc.</organization>

<address>
<postal>
<street>2550 Garcia Ave.</street>
<street>Mailstop UMTV 05-44</street>
<city>Mountain View</city>
<region>CA</region>
<code>94043</code>
<country>US</country>
</postal>

<phone>+1 415 336 1012</phone>
<facsimile>+1 415 336 6015</facsimile>
<email>Bob.Gilligan@Eng.Sun.COM</email>
</address>
</author>

<author fullname="Erik Nordmark" initials="E." surname="Nordmark">
<organization>Sun Microsystems, Inc.</organization>

<address>
<postal>
<street>2550 Garcia Ave.</street>
<street>Mailstop UMTV 05-44</street>
<city>Mountain View</city>
<region>CA</region>
<code>94043</code>
<country>US</country>
</postal>

<phone>+1 415 336 2788</phone>
<facsimile>+1 415 336 6015</facsimile>
<email>Erik.Nordmark@Eng.Sun.COM</email>
</address>
</author>

<date year="1996" month="April" />

<abstract>
<t>This document specifies IPv4 compatibility mechanisms that can be implemented by IPv6 hosts and routers. These mechanisms include providing complete implementations of both versions of the Internet Protocol (IPv4 and IPv6), and tunneling IPv6 packets over IPv4 routing infrastructures. They are designed to allow IPv6 nodes to maintain complete compatibility with IPv4, which should greatly simplify the deployment of IPv6 in the Internet, and facilitate the eventual transition of the entire Internet to IPv6.</t>
</abstract>
</front>

<seriesInfo value="1933" name="RFC" />
</reference>


<reference target2="reference.RFC.1934.xml" anchor="RFC1934">
<front>
<title abbrev="Multilink Protocol Plus">Ascend's Multilink Protocol Plus (MP+)</title>
<author fullname="Kevin Smith" initials="K." surname="Smith">
<organization>Ascend Communications</organization>

<address>
<postal>
<street>1275 Harbor Bay Parkway</street>
<city>Alameda</city>
<region>CA</region>
<code>94502</code>
<country>US</country>
</postal>

<phone>+1 510 769 6001</phone>
<facsimile>+1 510 814 2300</facsimile>
<email>ksmith@ascend.com</email>
</address>
</author>

<date year="1996" month="April" />

<abstract>
<t>This document proposes an extension to the PPP Multilink Protocol (MP). Multilink Protocol Plus (MP+) is a new control protocol for managing multiple data links that are bundled by MP.</t>
</abstract>
</front>

<seriesInfo value="1934" name="RFC" />
</reference>


<reference target2="reference.RFC.1935.xml" anchor="RFC1935">
<front>
<title>What is the Internet, Anyway?</title>
<author fullname="John S. Quarterman" initials="J." surname="Quarterman">
<organization>TIC</organization>

<address>
<email>tic@tic.com</email>
</address>
</author>

<author fullname="Smoot Carl-Mitchell" initials="S." surname="Carl-Mitchell">
<organization>TIC</organization>

<address>
<email>tic@tic.com</email>
</address>
</author>

<date year="1996" month="April" />
</front>

<seriesInfo value="1935" name="RFC" />
</reference>


<reference target2="reference.RFC.1936.xml" anchor="RFC1936">
<front>
<title>Implementing the Internet Checksum in Hardware</title>
<author fullname="Joe Touch" initials="J." surname="Touch">
<organization>University of Southern California, Information Sciences Institute</organization>

<address>
<postal>
<street>4676 Admiralty Way</street>
<city>Marina del Rey</city>
<region>CA</region>
<code>90292-6695</code>
<country>US</country>
</postal>

<phone>+1 310 822 1511 x151</phone>
<facsimile>+1 310 823 6714</facsimile>
<email>touch@isi.edu</email>
<uri>http://www.isi.edu/~touch</uri>
</address>
</author>

<author fullname="Bruce Parham" initials="B." surname="Parham">
<organization>University of Southern California, Information Sciences Institute</organization>

<address>
<postal>
<street>4676 Admiralty Way</street>
<city>Marina del Rey</city>
<region>CA</region>
<code>90292-6695</code>
<country>US</country>
</postal>

<phone>+1 310 822 1511 x101</phone>
<facsimile>+1 310 823 6714</facsimile>
<email>bparham@isi.edu</email>
</address>
</author>

<date year="1996" month="April" />

<abstract>
<t>This memo presents a techniques for efficiently implementing the Internet checksum in hardware. It includes PLD code for programming a single, low cost part to perform checksumming at 1.26 Gbps.</t>
</abstract>
</front>

<seriesInfo value="1936" name="RFC" />
</reference>


<reference target2="reference.RFC.1937.xml" anchor="RFC1937">
<front>
<title abbrev="Forwarding in Switched Data Link Subnets">"Local/Remote" Forwarding Decision in Switched Data Link Subnetworks</title>
<author fullname="Yakov Rekhter" initials="Y." surname="Rekhter">
<organization>Cisco Systems</organization>

<address>
<postal>
<street>170 West Tasman Drive</street>
<city>San Jose</city>
<region>CA</region>
<code>95134-1706</code>
<country>US</country>
</postal>

<phone>+1 914 528 0090</phone>
<email>yakov@cisco.com</email>
</address>
</author>

<author fullname="Dilip Kandlur" initials="D." surname="Kandlur">
<organization>IBM Corporation, T.J. Watson Research Center</organization>

<address>
<postal>
<street>P.O. Box 704</street>
<city>Yorktown Heights</city>
<region>NY</region>
<code>10598</code>
<country>US</country>
</postal>

<phone>+1 914 784 7722</phone>
<email>kandlur@watson.ibm.com</email>
</address>
</author>

<date year="1996" month="May" />

<abstract>
<t>The IP architecture assumes that each Data Link subnetwork is labeled with a single IP subnet number. A pair of hosts with the same subnet number communicate directly  (with no routers); a pair of hosts with different subnet numbers always communicate through one or more routers. As indicated in RFC1620, these assumptions may be too restrictive for large data networks, and specifically for networks based on switched virtual circuit (SVC) based technologies (e.g. ATM, Frame Relay, X.25), as these assumptions impose constraints on communication among hosts and routers through a network.  The restrictions may preclude full utilization of the capabilities provided by the underlying SVC-based Data Link subnetwork.  This document describes extensions to the IP architecture that relaxes these constraints, thus enabling the full utilization of the services provided by SVC-based Data Link subnetworks.</t>
</abstract>
</front>

<seriesInfo value="1937" name="RFC" />
</reference>


<reference target2="reference.RFC.1938.xml" anchor="RFC1938">
<front>
<title>A One-Time Password System</title>
<author fullname="Neil Haller" initials="N." surname="Haller">
<organization>Bellcore</organization>

<address>
<postal>
<street>445 South Street</street>
<street>MCC 1C-265B</street>
<city>Morristown</city>
<region>NJ</region>
<code>07960-6438</code>
<country>US</country>
</postal>

<phone>+1 201 829 4478</phone>
<facsimile>+1 201 829 2504</facsimile>
<email>nmh@bellcore.com</email>
</address>
</author>

<author fullname="Craig Metz" initials="C." surname="Metz">
<organization>Kaman Sciences Corporation</organization>

<address>
<postal>
<street>4555 Overlook Avenue, S.W.</street>
<street>NRL Code 5544</street>
<city>Washington</city>
<region>DC</region>
<code>20375-5337</code>
<country>US</country>
</postal>

<phone>+1 202 404 7122</phone>
<facsimile>+1 202 404 7942</facsimile>
<email>cmetz@cs.nrl.navy.mil</email>
</address>
</author>

<date year="1996" month="May" />

<abstract>
<t>This document describes a one-time password authentication system (OTP). The system provides authentication for system access (login) and other applications requiring authentication that is secure against passive attacks based on replaying captured reusable passwords. OTP evolved from the S/KEY (S/KEY is a trademark of Bellcore) One-Time Password System that was released by Bellcore and is described in referencesand.</t>
</abstract>
</front>

<seriesInfo value="1938" name="RFC" />
</reference>


<reference target2="reference.RFC.1939.xml" anchor="RFC1939">
<front>
<title abbrev="POP3">Post Office Protocol - Version 3</title>
<author fullname="John G. Myers" initials="J.G." surname="Myers">
<organization>Carnegie-Mellon University</organization>

<address>
<postal>
<street>5000 Forbes Ave</street>
<city>Pittsburgh</city>
<region>PA</region>
<code>15213</code>
<country>US</country>
</postal>

<email>jgm+@cmu.edu</email>
</address>
</author>

<author fullname="Marshall T. Rose" initials="M.T." surname="Rose">
<organization>Dover Beach Consulting, Inc.</organization>

<address>
<postal>
<street>420 Whisman Court</street>
<city>Mountain View</city>
<region>CA</region>
<code>94043-2186</code>
<country>US</country>
</postal>

<email>mrose@dbc.mtview.ca.us</email>
</address>
</author>

<date year="1996" month="May" />
</front>

<seriesInfo value="53" name="STD" />
<seriesInfo value="1939" name="RFC" />
</reference>


<reference target2="reference.RFC.1940.xml" anchor="RFC1940">
<front>
<title abbrev="SDRv1">Source Demand Routing: Packet Format and Forwarding Specification (Version 1)</title>
<author fullname="Deborah Estrin" initials="D." surname="Estrin">
<organization>USC/Information Sciences Institute</organization>

<address>
<postal>
<street>4676 Admiralty Way</street>
<city>Marina del Rey</city>
<region>CA</region>
<code>90292-6695</code>
<country>US</country>
</postal>

<phone>+1 310 822 1511 x253</phone>
<email>estrin@isi.edu</email>
</address>
</author>

<author fullname="Tony Li" initials="T." surname="Li">
<organization>cisco Systems, Inc.</organization>

<address>
<postal>
<street>1525 O'Brien Drive</street>
<city>Menlo Park</city>
<region>CA</region>
<code>94025</code>
<country>US</country>
</postal>

<phone>+1 415 526 8186</phone>
<email>tli@cisco.com</email>
</address>
</author>

<author fullname="Yakov Rekhter" initials="Y." surname="Rekhter">
<organization>Cisco systems</organization>

<address>
<postal>
<street>170 West Tasman Drive</street>
<city>San Jose</city>
<region>CA</region>
<code>95134-1706</code>
<country>US</country>
</postal>

<phone>+1 914 528 0090</phone>
<facsimile>+1 408 526 4952</facsimile>
<email>yakov@cisco.com</email>
</address>
</author>

<author fullname="Kannan Varadhan" initials="K." surname="Varadhan">
<organization>USC/Information Sciences Institute</organization>

<address>
<postal>
<street>4676 Admiralty Way</street>
<city>Marina del Rey</city>
<region>CA</region>
<code>90292-6695</code>
<country>US</country>
</postal>

<phone>+1 310 822 1511 x402</phone>
<email>kannan@isi.edu</email>
</address>
</author>

<author fullname="Daniel Zappala" initials="D." surname="Zappala">
<organization>USC/Information Sciences Institute</organization>

<address>
<postal>
<street>4676 Admiralty Way</street>
<city>Marina del Rey</city>
<region>CA</region>
<code>90292-6695</code>
<country>US</country>
</postal>

<phone>+1 310 822 1511 x352</phone>
<email>daniel@isi.edu</email>
</address>
</author>

<date year="1996" month="May" />
</front>

<seriesInfo value="1940" name="RFC" />
</reference>


<reference target2="reference.RFC.1941.xml" anchor="RFC1941">
<front>
<title>Frequently Asked Questions for Schools</title>
<author fullname="Jennifer Sellers" initials="J." surname="Sellers">
<organization>Sterling Software/NASA IITA</organization>

<address>
<postal>
<street>700 13th Street NW</street>
<street>Suite 950</street>
<city>Washington</city>
<region>DC</region>
<code>20005</code>
<country>US</country>
</postal>

<phone>+1 202 434 8954</phone>
<email>sellers@quest.arc.nasa.gov</email>
</address>
</author>

<author fullname="Julie Robichaux" initials="J." surname="Robichaux">
<organization>InterNIC</organization>

<address>
<postal>
<street>505 Huntmar Park Dr.</street>
<city>Herndon</city>
<region>VA</region>
<code>22070</code>
<country>US</country>
</postal>

<phone>+1 703 742 4839</phone>
<email>julier@internic.net</email>
</address>
</author>

<date year="1996" month="May" />

<abstract>
<t>The goal of this FYI document, produced by the Internet School Networking (ISN) group in the User Services Area of the Internet Engineering Task Force (IETF), is to act as an introduction to the Internet for faculty, administration, and other school personnel in primary and secondary schools. The intended audience is educators who are recently connected to the Internet, who are accessing the Internet by some means other than a direct connection, or who are just beginning to consider Internet access as a resource for their schools.  Although the Internet Engineering Task Force is an international organization and this paper will be valuable to educators in many countries, it is limited in focus to internetworking in the United States.</t>
</abstract>
</front>

<seriesInfo value="1941" name="RFC" />
</reference>


<reference target2="reference.RFC.1942.xml" anchor="RFC1942">
<front>
<title>HTML Tables</title>
<author fullname="Dave Raggett" initials="D." surname="Raggett">
<organization abbrev="W3C">The World Wide Web Consortium</organization>

<address>
<email>dsr@w3.org</email>
<uri>http://www.w3.org/</uri>
</address>
</author>

<date year="1996" month="May" />

<abstract>
<t>The HyperText Markup Language (HTML) is a simple markup language used to create hypertext documents that are portable from one platform to another. HTML documents are SGML documents with generic semantics that are appropriate for representing information from a wide range of applications. This specification xtends HTML to support a wide variety of tables. The model is designed to work well with associated style sheets, but does not require them. It also supports rendering to braille, or speech, and exchange of tabular data with databases and spreadsheets. The HTML table model embodies certain aspects of the CALS table model, e.g. the ability to group table rows into thead, tbody and tfoot sections, plus the ability to specify cell alignment compactly for sets of cells according to the context.</t>
</abstract>
</front>

<seriesInfo value="1942" name="RFC" />
</reference>


<reference target2="reference.RFC.1943.xml" anchor="RFC1943">
<front>
<title>Building an X.500 Directory Service in the US</title>
<author fullname="Barbara Jennings" initials="B." surname="Jennings">
<organization>Sandia National Laboratories, Scientific Computing Systems</organization>

<address>
<postal>
<street>P.O. Box 5800</street>
<street>M/S 0807</street>
<city>Albuquerque</city>
<region>NM</region>
<code>87106</code>
<country>US</country>
</postal>

<phone>+1 505 845 8554</phone>
<facsimile>+1 505 844 2067</facsimile>
<email>jennings@sandia.gov</email>
</address>
</author>

<date year="1996" month="May" />

<abstract>
<t>This document provides definition and recommends considerations that must be undertaken to operate a X.500 Directory Service in the United States.  This project is the work performed for the Integrated Directory Services Working Group within the Internet Engineering Task Force, for establishing an electronic White Pages Directory Service within an organization in the US and for connecting it to a wide-area Directory infrastructure.</t>

<t>Establishing a successful White Pages Directory Service within an organization requires a collaborative effort between the technical, legal and data management components of an organization. It also helps if there is a strong commitment from the higher management to participate in a wide-area Directory Service.</t>

<t>The recommendations presented in the document are the result of experience from participating in the Internet White Pages project.</t>
</abstract>
</front>

<seriesInfo value="1943" name="RFC" />
</reference>


<reference target2="reference.RFC.1944.xml" anchor="RFC1944">
<front>
<title abbrev="Benchmarking Methodology">Benchmarking Methodology for Network Interconnect Devices</title>
<author fullname="Scott Bradner" initials="S." surname="Bradner">
<organization>Harvard University</organization>

<address>
<postal>
<street>1350 Mass. Ave</street>
<street>room 813</street>
<city>Cambridge</city>
<region>MA</region>
<code>02138</code>
<country>US</country>
</postal>

<phone>+1 617 495 3864</phone>
<facsimile>+1 617 496 8500</facsimile>
<email>sob@harvard.edu</email>
</address>
</author>

<author fullname="Jim McQuaid" initials="J." surname="McQuaid">
<organization>Bay Networks</organization>

<address>
<postal>
<street>3 Federal Street</street>
<city>Billerica</city>
<region>MA</region>
<code>01821</code>
<country>US</country>
</postal>

<phone>+1 508 436 3915</phone>
<facsimile>+1 508 670 8145</facsimile>
<email>jmcquaid@baynetworks.com</email>
</address>
</author>

<date year="1996" month="May" />

<abstract>
<t>This document discusses and defines a number of tests that may be used to describe the performance characteristics of a network interconnecting  device.  In addition to defining the tests this document also describes specific formats for reporting the results of the tests.  Appendix A lists the tests and conditions that we believe should be included for specific cases and gives additional information about testing practices.  Appendix B is a reference listing of maximum frame rates to be used with specific frame sizes on various media and Appendix C gives some examples of frame formats to be used in testing.</t>
</abstract>
</front>

<seriesInfo value="1944" name="RFC" />
</reference>


<reference target2="reference.RFC.1945.xml" anchor="RFC1945">
<front>
<title abbrev="HTTP/1.0">Hypertext Transfer Protocol -- HTTP/1.0</title>
<author fullname="Tim Berners-Lee" initials="T." surname="Berners-Lee">
<organization>MIT, Laboratory for Computer Science</organization>

<address>
<postal>
<street>545 Technology Square</street>
<city>Cambridge</city>
<region>MA</region>
<code>02139</code>
<country>US</country>
</postal>

<facsimile>+1 617 258 8682</facsimile>
<email>timbl@w3.org</email>
</address>
</author>

<author fullname="Roy T. Fielding" initials="R.T." surname="Fielding">
<organization>University of California, Irvine, Department of Information and Computer Science</organization>

<address>
<postal>
<street />
<city>Irvine</city>
<region>CA</region>
<code>92717-3425</code>
<country>US</country>
</postal>

<facsimile>+1 714 824 4056</facsimile>
<email>fielding@ics.uci.edu</email>
</address>
</author>

<author fullname="Henrik Frystyk Nielsen" initials="H.F." surname="Nielsen">
<organization>W3 Consortium, MIT Laboratory for Computer Science</organization>

<address>
<postal>
<street>545 Technology Square</street>
<city>Cambridge</city>
<region>MA</region>
<code>02139</code>
<country>US</country>
</postal>

<facsimile>+1 617 258 8682</facsimile>
<email>frystyk@w3.org</email>
</address>
</author>

<date year="1996" month="May" />

<abstract>
<t>The Hypertext Transfer Protocol (HTTP) is an application-level protocol with the lightness and speed necessary for distributed, collaborative, hypermedia information systems. It is a generic, stateless, object-oriented protocol which can be used for many tasks, such as name servers and distributed object management systems, through extension of its request methods (commands). A feature of HTTP is the typing of data representation, allowing systems to be built independently of the data being transferred.</t>

<t>HTTP has been in use by the World-Wide Web global information initiative since 1990. This specification reflects common usage of the protocol referred to as "HTTP/1.0".</t>
</abstract>
</front>

<seriesInfo value="1945" name="RFC" />
</reference>


<reference target2="reference.RFC.1946.xml" anchor="RFC1946">
<front>
<title>Native ATM Support for ST2+</title>
<author fullname="Steve Jackowski" initials="S." surname="Jackowski">
<organization>NetManage Incorporated</organization>

<address>
<postal>
<street>269 Mt. Hermon Road</street>
<street>Suite 201</street>
<city>Scotts Valley</city>
<region>CA</region>
<code>95066</code>
<country>US</country>
</postal>

<phone>+1 408 439 6834</phone>
<facsimile>+1 408 438 5115</facsimile>
<email>Stevej@NetManage.com</email>
</address>
</author>

<date year="1996" month="May" />

<abstract>
<t>As the demand for networked realtime services grows, so does the need for shared networks to provide deterministic delivery services. Such deterministic delivery services demand that both the source application and the network infrastructure have capabilities to request, setup, and enforce the delivery of the data. Collectively these services are referred to as bandwidth reservation and Quality of Service (QoS).</t>

<t>The IETF is currently working on an integrated services model to support realtime services on the Internet  The IETF has not yet focused on the integration of ATM and its inherent QoS and bandwidth allocation mechanisms for delivery of realtime traffic over shared wires. (ATM hardware and interfaces provide the network infrastructure for the determinitic data delivery, however the host resident protocol stacks and applications need more attention.)</t>

<t>Current IETF efforts underway in the IP over ATM (ipatm) working group rely on intserv, rsvp and ST2 to address QoS issues for ATM. As such, RFC 1577 and the ATM Forum's Lan Emulation do not provide direct QoS and bandwidth allocation capabilities to  network applications. Without providing a mapping of reservations-style QoS to ATM signalling, ATM will remain a 'wire' rather than a shared media infrastructure component.</t>

<t>This memo describes a working implementation which enables applications to directly invoke ATM services in the following environments:</t>

<t>- ATM to internet,
        - internet to ATM, and
        - internet to internet across ATM.</t>
</abstract>
</front>

<seriesInfo value="1946" name="RFC" />
</reference>


<reference target2="reference.RFC.1947.xml" anchor="RFC1947">
<front>
<title abbrev="Greek Encoding for E-mail Messages">Greek Character Encoding for Electronic Mail Messages</title>
<author fullname="Diomidis Spinellis" initials="D." surname="Spinellis">
<organization>SENA S.A.</organization>

<address>
<postal>
<street>Kyprou 27</street>
<city>Filothei</city>
<region />
<code>152 47</code>
<country>GR</country>
</postal>

<phone>+30 1 6854535</phone>
<facsimile>+30 1 6840631</facsimile>
<email>D.Spinellis@senanet.com</email>
</address>
</author>

<date year="1996" month="May" />
</front>

<seriesInfo value="1947" name="RFC" />
</reference>


<reference target2="reference.RFC.1948.xml" anchor="RFC1948">
<front>
<title abbrev="Sequence Number Attacks">Defending Against Sequence Number Attacks</title>
<author fullname="Steven M. Bellovin" initials="S." surname="Bellovin">
<organization>AT&amp;T Research</organization>

<address>
<postal>
<street>600 Mountain Avenue</street>
<city>Murray Hill</city>
<region>NJ</region>
<code>07974</code>
<country>US</country>
</postal>

<phone>+1 908 582 5886</phone>
<email>smb@research.att.com</email>
</address>
</author>

<date year="1996" month="May" />

<abstract>
<t>IP spoofing attacks based on sequence number spoofing have become a serious threat on the Internet (CERT Advisory CA-95:01).  While ubiquitous crypgraphic authentication is the right answer, we propose a simple modification to TCP implementations that should be a very substantial block to the current wave of attacks.</t>
</abstract>
</front>

<seriesInfo value="1948" name="RFC" />
</reference>


<reference target2="reference.RFC.1949.xml" anchor="RFC1949">
<front>
<title>Scalable Multicast Key Distribution</title>
<author fullname="Tony Ballardie," initials="T." surname="Ballardie">
<organization>University College London, Department of Computer Science</organization>

<address>
<postal>
<street>Gower Street</street>
<city>London</city>
<region>England</region>
<code>WC1E 6BT</code>
<country>UK</country>
</postal>

<phone>+44 71 4193462</phone>
<email>A.Ballardie@cs.ucl.ac.uk</email>
</address>
</author>

<date year="1996" month="May" />

<abstract>
<t>The benefits of multicasting are becoming ever-more apparent, and its use much more widespread. This is evident from the growth of the MBONE. Providing security services for multicast, such as traffic integrity, authentication, and confidentiality, is particularly problematic since it requires securely distributing a group (session) key to each of a group's receivers.  Traditionally, the key distribution function has been assigned to a central network entity, or Key Distribution Centre (KDC), but this method does not scale for wide-area multicasting, where group members may be widely-distributed across the internetwork, and a wide-area group may be densely populated.</t>

<t>Even more problematic is the scalable distribution of sender-specific keys. Sender-specific keys are required if data traffic is to be authenticated on a per-sender basis.</t>

<t>This memo provides a scalable solution to the multicast key distribution problem.</t>

<t>NOTE: this proposal requires some simple support mechanisms, which, it is recommended here, be integrated into version 3 of IGMP. This support is described in Appendix B.</t>
</abstract>
</front>

<seriesInfo value="1949" name="RFC" />
</reference>


<reference target2="reference.RFC.1950.xml" anchor="RFC1950">
<front>
<title>ZLIB Compressed Data Format Specification version 3.3</title>
<author fullname="L. Peter Deutsch" initials="L.P." surname="Deutsch">
<organization>Aladdin Enterprises</organization>

<address>
<postal>
<street>203 Santa Margarita Ave.</street>
<city>Menlo Park</city>
<region>CA</region>
<code>94025</code>
<country>US</country>
</postal>

<phone>+1 415 322 0103</phone>
<facsimile>+1 415 322 1734</facsimile>
<email>ghost@aladdin.com</email>
</address>
</author>

<author fullname="Jean-Loup Gailly" initials="J-L." surname="Gailly">
<organization />
</author>

<date year="1996" month="May" />

<abstract>
<t>This specification defines a lossless compressed data format.  The data can be produced or consumed, even for an arbitrarily long sequentially presented input data stream, using only an a priori bounded amount of intermediate storage.  The format presently uses the DEFLATE compression method but can be easily extended to use
   other compression methods.  It can be implemented readily in a manner not covered by patents.  This specification also defines the ADLER-32 checksum (an extension and improvement of the Fletcher checksum), used for detection of data corruption, and provides an algorithm for computing it.</t>
</abstract>
</front>

<seriesInfo value="1950" name="RFC" />
</reference>


<reference target2="reference.RFC.1951.xml" anchor="RFC1951">
<front>
<title>DEFLATE Compressed Data Format Specification version 1.3</title>
<author fullname="L. Peter Deutsch" initials="P." surname="Deutsch">
<organization>Aladdin Enterprises</organization>

<address>
<postal>
<street>203 Santa Margarita Ave.</street>
<city>Menlo Park</city>
<region>CA</region>
<code>94025</code>
<country>US</country>
</postal>

<phone>+1 415 322 0103</phone>
<facsimile>+1 415 322 1734</facsimile>
<email>ghost@aladdin.com</email>
</address>
</author>

<date year="1996" month="May" />

<abstract>
<t>This specification defines a lossless compressed data format that compresses data using a combination of the LZ77 algorithm and Huffman coding, with efficiency comparable to the best currently available general-purpose compression methods.  The data can be produced or consumed, even for an arbitrarily long sequentially presented input data stream, using only an a priori bounded amount of intermediate storage.  The format can be implemented readily in a manner not covered by patents.</t>
</abstract>
</front>

<seriesInfo value="1951" name="RFC" />
</reference>


<reference target2="reference.RFC.1952.xml" anchor="RFC1952">
<front>
<title>GZIP file format specification version 4.3</title>
<author fullname="L. Peter Deutsch" initials="P." surname="Deutsch">
<organization>Aladdin Enterprises</organization>

<address>
<postal>
<street>203 Santa Margarita Ave.</street>
<city>Menlo Park</city>
<region>CA</region>
<code>94025</code>
<country>US</country>
</postal>

<phone>+1 415 322 0103</phone>
<facsimile>+1 415 322 1734</facsimile>
<email>ghost@aladdin.com</email>
</address>
</author>

<author fullname="Jean-Loup Gailly" initials="J-L." surname="Gailly">
<organization />

<address>
<email>gzip@prep.ai.mit.edu</email>
</address>
</author>

<author fullname="Mark Adler" initials="M." surname="Adler">
<organization />

<address>
<email>madler@alumni.caltech.edu</email>
</address>
</author>

<author fullname="L. Peter Deutsch" initials="L.P." surname="Deutsch">
<organization />

<address>
<email>ghost@aladdin.com</email>
</address>
</author>

<author fullname="Glenn Randers-Pehrson" initials="G." surname="Randers-Pehrson">
<organization />

<address>
<email>randeg@alumni.rpi.edu</email>
</address>
</author>

<date year="1996" month="May" />

<abstract>
<t>This specification defines a lossless compressed data format that is compatible with the widely used GZIP utility.  The format includes a cyclic redundancy check value for detecting data corruption.  The format presently uses the DEFLATE method of compression but can be easily extended to use other compression methods.  The format can be implemented readily in a manner not covered by patents.</t>
</abstract>
</front>

<seriesInfo value="1952" name="RFC" />
</reference>


<reference target2="reference.RFC.1953.xml" anchor="RFC1953">
<front>
<title>Ipsilon Flow Management Protocol Specification for IPv4 Version 1.0</title>
<author fullname="Peter Newman" initials="P." surname="Newman">
<organization>Ipsilon Networks, Inc.</organization>

<address>
<postal>
<street>2191 East Bayshore Road</street>
<street>Suite 100</street>
<city>Palo Alto</city>
<region>CA</region>
<code>94303</code>
<country>US</country>
</postal>

<phone>+1 415 846 4603</phone>
<email>pn@ipsilon.com</email>
</address>
</author>

<author fullname="W. L. Edwards" initials="W." surname="Edwards">
<organization>Sprint Technology Services - Long Distance Division</organization>

<address>
<postal>
<street>9300 Metcalf Avenue</street>
<street>Mailstop KSOPKB0802</street>
<city>Overland Park</city>
<region>KS</region>
<code>66212-6333</code>
<country>US</country>
</postal>

<phone>+1 913 534 5334</phone>
<email>texas@sprintcorp.com</email>
</address>
</author>

<author fullname="Robert M. Hinden" initials="R." surname="Hinden">
<organization>Ipsilon Networks, Inc.</organization>

<address>
<postal>
<street>2191 East Bayshore Road</street>
<street>Suite 100</street>
<city>Palo Alto</city>
<region>CA</region>
<code>94303</code>
<country>US</country>
</postal>

<phone>+1 415 846 4604</phone>
<email>hinden@ipsilon.com</email>
</address>
</author>

<author fullname="Eric Hoffman" initials="E." surname="Hoffman">
<organization>Ipsilon Networks, Inc.</organization>

<address>
<postal>
<street>2191 East Bayshore Road</street>
<street>Suite 100</street>
<city>Palo Alto</city>
<region>CA</region>
<code>94303</code>
<country>US</country>
</postal>

<phone>+1 415 846 4610</phone>
<email>hoffman@ipsilon.com</email>
</address>
</author>

<author fullname="Fong Ching Liaw" initials="F." surname="Ching Liaw">
<organization>Ipsilon Networks, Inc.</organization>

<address>
<postal>
<street>2191 East Bayshore Road</street>
<street>Suite 100</street>
<city>Palo Alto</city>
<region>CA</region>
<code>94303</code>
<country>US</country>
</postal>

<phone>+1 415 846 4607</phone>
<email>fong@ipsilon.com</email>
</address>
</author>

<author fullname="Tom Lyon" initials="T." surname="Lyon">
<organization>Ipsilon Networks, Inc.</organization>

<address>
<postal>
<street>2191 East Bayshore Road</street>
<street>Suite 100</street>
<city>Palo Alto</city>
<region>CA</region>
<code>94303</code>
<country>US</country>
</postal>

<phone>+1 415 846 4601</phone>
<email>pugs@ipsilon.com</email>
</address>
</author>

<author fullname="Greg Minshall" initials="G." surname="Minshall">
<organization>Ipsilon Networks, Inc.</organization>

<address>
<postal>
<street>2191 East Bayshore Road</street>
<street>Suite 100</street>
<city>Palo Alto</city>
<region>CA</region>
<code>94303</code>
<country>US</country>
</postal>

<phone>+1 415 846 4605</phone>
<email>minshall@ipsilon.com</email>
</address>
</author>

<date year="1996" month="May" />

<abstract>
<t>The Ipsilon Flow Management Protocol (IFMP), is a protocol for allowing a node to instruct an adjacent node to attach a layer 2 label to a specified IP flow.  The label allows more efficient access to cached routing information for that flow.  The label can also enable a node to switch further packets belonging to the specified flow at layer 2 rather than forwarding them at layer 3.</t>
</abstract>
</front>

<seriesInfo value="1953" name="RFC" />
</reference>


<reference target2="reference.RFC.1954.xml" anchor="RFC1954">
<front>
<title>Transmission of Flow Labelled IPv4 on ATM Data Links Ipsilon Version 1.0</title>
<author fullname="Peter Newman" initials="P." surname="Newman">
<organization>Ipsilon Networks, Inc.</organization>

<address>
<postal>
<street>2191 East Bayshore Road</street>
<street>Suite 100</street>
<city>Palo Alto</city>
<region>CA</region>
<code>94303</code>
<country>US</country>
</postal>

<phone>+1 415 846 4603</phone>
<email>pn@ipsilon.com</email>
</address>
</author>

<author fullname="W. L. Edwards" initials="W.L." surname="Edwards">
<organization>Sprint Technology Services - Long Distance Division</organization>

<address>
<postal>
<street>9300 Metcalf Avenue</street>
<street>Mailstop KSOPKB0802</street>
<city>Overland Park</city>
<region>KS</region>
<code>66212-6333</code>
<country>US</country>
</postal>

<phone>+1 913 534 5334</phone>
<email>texas@sprintcorp.com</email>
</address>
</author>

<author fullname="Robert M. Hinden" initials="R." surname="Hinden">
<organization>Ipsilon Networks, Inc.</organization>

<address>
<postal>
<street>2191 East Bayshore Road</street>
<street>Suite 100</street>
<city>Palo Alto</city>
<region>CA</region>
<code>94303</code>
<country>US</country>
</postal>

<phone>+1 415 846 4604</phone>
<email>hinden@ipsilon.com</email>
</address>
</author>

<author fullname="Eric Hoffman" initials="E." surname="Hoffman">
<organization>Ipsilon Networks, Inc.</organization>

<address>
<postal>
<street>2191 East Bayshore Road</street>
<street>Suite 100</street>
<city>Palo Alto</city>
<region>CA</region>
<code>94303</code>
<country>US</country>
</postal>

<phone>+1 415 846 4610</phone>
<email>hoffman@ipsilon.com</email>
</address>
</author>

<author fullname="Fong Ching Liaw" initials="F." surname="Ching Liaw">
<organization>Ipsilon Networks, Inc.</organization>

<address>
<postal>
<street>2191 East Bayshore Road</street>
<street>Suite 100</street>
<city>Palo Alto</city>
<region>CA</region>
<code>94303</code>
<country>US</country>
</postal>

<phone>+1 415 846 4607</phone>
<email>fong@ipsilon.com</email>
</address>
</author>

<author fullname="Tom Lyon" initials="T." surname="Lyon">
<organization>Ipsilon Networks, Inc.</organization>

<address>
<postal>
<street>2191 East Bayshore Road</street>
<street>Suite 100</street>
<city>Palo Alto</city>
<region>CA</region>
<code>94303</code>
<country>US</country>
</postal>

<phone>+1 415 846 4601</phone>
<email>pugs@ipsilon.com</email>
</address>
</author>

<author fullname="Greg Minshall" initials="G." surname="Minshall">
<organization>Ipsilon Networks, Inc.</organization>

<address>
<postal>
<street>2191 East Bayshore Road</street>
<street>Suite 100</street>
<city>Palo Alto</city>
<region>CA</region>
<code>94303</code>
<country>US</country>
</postal>

<phone>+1 415 846 4605</phone>
<email>minshall@ipsilon.com</email>
</address>
</author>

<date year="1996" month="May" />

<abstract>
<t>This document specifies the manner for transmitting IPv4 datagrams over an ATM data link, both in a default manner and in the presence of flow labelling via Ipsilon Flow Management Protocol.</t>
</abstract>
</front>

<seriesInfo value="1954" name="RFC" />
</reference>


<reference target2="reference.RFC.1955.xml" anchor="RFC1955">
<front>
<title>New Scheme for Internet Routing and Addressing (ENCAPS) for IPNG</title>
<author fullname="Robert M. Hinden" initials="R." surname="Hinden">
<organization>Ipsilon Networks, Inc.</organization>

<address>
<postal>
<street>2191 East Bayshore Road</street>
<street>Suite 100</street>
<city>Palo Alto</city>
<region>CA</region>
<code>94303</code>
<country>US</country>
</postal>

<phone>+1 415 846 4604</phone>
<email>hinden@ipsilon.com</email>
</address>
</author>

<date year="1996" month="June" />

<abstract>
<t>This document was submitted to the IETF IPng area in response to RFC 1550.  Publication of this document does not imply acceptance by the IPng area of any ideas expressed within.  Comments should be submitted to the big-internet@munnari.oz.au mailing list.</t>

<t>This memo describes a proposal made to to the Routing and Addressing group [ROAD] January 1992 by Robert Hinden.  It was originally sent as an email message.  It proposes a medium term solution to the Internet's routing and addressing problems.</t>
</abstract>
</front>

<seriesInfo value="1955" name="RFC" />
</reference>


<reference target2="reference.RFC.1956.xml" anchor="RFC1956">
<front>
<title>Registration in the MIL Domain</title>
<author fullname="D.W. Engebretson" initials="D.W." surname="Engebretson">
<organization>DISA/D343</organization>

<address>
<postal>
<street>11440 Isaac Newton Square</street>
<city>Reston</city>
<region>VA</region>
<code>22090</code>
<country>US</country>
</postal>

<phone>+1 703 735 8065</phone>
<email>engebred@ncr.disa.mil</email>
</address>
</author>

<author fullname="Raymond Plzak" initials="R." surname="Plzak">
<organization>Department of Defense Network Information Center</organization>

<address>
<postal>
<street>14200 Parkridge Drive</street>
<street>Suite 200</street>
<city>Chantilly</city>
<region>VA</region>
<code>22021</code>
<country>US</country>
</postal>

<phone>+1 800 365 3642</phone>
<email>plzak@nic.ddn.mil</email>
</address>
</author>

<date year="1996" month="June" />
</front>

<seriesInfo value="1956" name="RFC" />
</reference>


<reference target2="reference.RFC.1957.xml" anchor="RFC1957">
<front>
<title>Some Observations on Implementations of the Post Office Protocol (POP3)</title>
<author fullname="Russell Nelson" initials="R." surname="Nelson">
<organization>Crynwr Software</organization>

<address>
<postal>
<street>521 Pleasant Valley Rd.</street>
<city>Potsdam</city>
<region>NY</region>
<code>13676</code>
<country>US</country>
</postal>

<phone>+1 315 268 1925</phone>
<facsimile>+1 315 268 9201</facsimile>
<email>nelson@crynwr.com</email>
</address>
</author>

<date year="1996" month="June" />
</front>

<seriesInfo value="1957" name="RFC" />
</reference>


<reference target2="reference.RFC.1958.xml" anchor="RFC1958">
<front>
<title>Architectural Principles of the Internet</title>
<author fullname="Brian E. Carpenter" initials="B." surname="Carpenter">
<organization>CERN, European Laboratory for Particle Physics</organization>

<address>
<postal>
<street>1211 Geneva 23</street>
<country>CH</country>
</postal>

<phone>+41 22 7674967</phone>
<facsimile>+41 22 7677155</facsimile>
<email>brian@dxcoms.cern.ch</email>
</address>
</author>

<date year="1996" month="June" />

<abstract>
<t>The Internet and its architecture have grown in evolutionary fashion from modest beginnings, rather than from a Grand Plan. While this process of evolution is one of the main reasons for the technology's success, it nevertheless seems useful to record a snapshot of the current principles of the Internet architecture. This is intended for general guidance and general interest, and is in no way intended to be a formal or invariant reference model.</t>
</abstract>
</front>

<seriesInfo value="1958" name="RFC" />
</reference>


<reference target2="reference.RFC.1959.xml" anchor="RFC1959">
<front>
<title>An LDAP URL Format</title>
<author fullname="Tim Howes" initials="T." surname="Howes">
<organization>University of Michigan, ITD Research Systems</organization>

<address>
<postal>
<street>535 W William St.</street>
<city>Ann Arbor</city>
<region>MI</region>
<code>48103-4943</code>
<country>US</country>
</postal>

<phone>+1 313 747 4454</phone>
<email>tim@umich.edu</email>
</address>
</author>

<author fullname="Mark Smith" initials="M." surname="Smith">
<organization>University of Michigan, ITD Research Systems</organization>

<address>
<postal>
<street>535 W William St.</street>
<city>Ann Arbor</city>
<region>MI</region>
<code>48103-4943</code>
<country>US</country>
</postal>

<phone>+1 313 764 2277</phone>
<email>mcs@umich.edu</email>
</address>
</author>

<date year="1996" month="June" />

<abstract>
<t>LDAP is the Lightweight Directory Access Protocol,
defined in  and . This document describes a format for an LDAP Uniform Resource Locator which will allow Internet clients to have direct access to the LDAP protocol.  While LDAP currently is used only as a front end to the X.500 directory, the URL format described here is general enough to handle the case of stand-alone LDAP servers (i.e., LDAP servers not back-ended by X.500).</t>
</abstract>
</front>

<seriesInfo value="1959" name="RFC" />
</reference>


<reference target2="reference.RFC.1960.xml" anchor="RFC1960">
<front>
<title>A String Representation of LDAP Search Filters</title>
<author fullname="Tim Howes" initials="T." surname="Howes">
<organization>University of Michigan, ITD Research Systems</organization>

<address>
<postal>
<street>535 W William St.</street>
<city>Ann Arbor</city>
<region>MI</region>
<code>48103-4943</code>
<country>US</country>
</postal>

<phone>+1 313 747 4454</phone>
<email>tim@umich.edu</email>
</address>
</author>

<date year="1996" month="June" />

<abstract>
<t>The Lightweight Directory Access Protocol (LDAP)defines a network representation of a search filter transmitted to an LDAP server.  Some applications may find it useful to have a common way of representing these search filters in a human-readable form.  This document defines a human-readable string format for representing LDAP search filters.</t>
</abstract>
</front>

<seriesInfo value="1960" name="RFC" />
</reference>


<reference target2="reference.RFC.1961.xml" anchor="RFC1961">
<front>
<title>GSS-API Authentication Method for SOCKS Version 5</title>
<author fullname="P. V. McMahon" initials="P.V." surname="McMahon">
<organization>ICL Enterprises</organization>

<address>
<postal>
<street>Kings House</street>
<street>33 Kings Road</street>
<city>Reading</city>
<region>England</region>
<code>RG1 3PX</code>
<country>UK</country>
</postal>

<phone>+44 1734 634882</phone>
<facsimile>+44 1734 855106</facsimile>
<email>p.v.mcmahon@rea0803.wins.icl.co.uk</email>
</address>
</author>

<date year="1996" month="June" />
</front>

<seriesInfo value="1961" name="RFC" />
</reference>


<reference target2="reference.RFC.1962.xml" anchor="RFC1962">
<front>
<title>The PPP Compression Control Protocol (CCP)</title>
<author fullname="Dave Rand" initials="D." surname="Rand">
<organization>Novell, Inc.</organization>

<address>
<postal>
<street>2180 Fortune Drive</street>
<city>San Jose</city>
<region>CA</region>
<code>95131</code>
<country>US</country>
</postal>

<phone>+1 408 321 1259</phone>
<email>dlr@daver.bungi.com</email>
</address>
</author>

<author fullname="Karl Fox" initials="K." surname="Fox">
<organization>Ascend Communications</organization>

<address>
<postal>
<street>3518 Riverside Drive</street>
<street>Suite 101</street>
<city>Columbus</city>
<region>OH</region>
<code>43221</code>
<country>US</country>
</postal>

<email>karl@ascend.com</email>
</address>
</author>

<date year="1996" month="June" />

<abstract>
<t>The Point-to-Point Protocol (PPP)provides a standard method for transporting multi-protocol datagrams over point-to-point links.  PPP also defines an extensible Link Control Protocol.</t>

<t>This document defines a method for negotiating data compression over PPP links.</t>
</abstract>
</front>

<seriesInfo value="1962" name="RFC" />
</reference>


<reference target2="reference.RFC.1963.xml" anchor="RFC1963">
<front>
<title>PPP Serial Data Transport Protocol (SDTP)</title>
<author fullname="Kevin Schneider" initials="K." surname="Schneider">
<organization>Adtran, Inc.</organization>

<address>
<postal>
<street>901 Explorer Blvd.</street>
<city>Huntsville</city>
<region>AL</region>
<code>35806-2807</code>
<country>US</country>
</postal>

<phone>+1 205 971 8000</phone>
<email>kevin@adtran.com</email>
</address>
</author>

<author fullname="Stuart Venters" initials="S." surname="Venters">
<organization>Adtran, Inc.</organization>

<address>
<postal>
<street>901 Explorer Blvd.</street>
<city>Huntsville</city>
<region>AL</region>
<code>35806-2807</code>
<country>US</country>
</postal>

<phone>+1 205 971 8000</phone>
<email>sventers@adtran.com</email>
</address>
</author>

<author fullname="Karl Fox" initials="K." surname="Fox">
<organization>Ascend Communications</organization>

<address>
<postal>
<street>3518 Riverside Drive</street>
<street>Suite 101</street>
<city>Columbus</city>
<region>OH</region>
<code>43221</code>
<country>US</country>
</postal>

<email>karl@ascend.com</email>
</address>
</author>

<date year="1996" month="August" />

<abstract>
<t>The Point-to-Point Protocol (PPP)provides a standard method for transporting multi-protocol datagrams over point-to-point links.  PPP
   defines an extensible Link Control Protocol, and proposes a family of Network Control Protocols for establishing and configuring different network-layer protocols.</t>

<t>This document describes a new Network level protocol (from the PPP point of view), PPP Serial Data Transport Protocol, that provides encapsulation and an associated control protocol for transporting serial data streams over a PPP link.  This protocol was developed for the purpose of using PPP's many features to provide a standard method for synchronous data compression. The encapsulation uses a header structure based on that of the ITU-T Recommendation V.120</t>
</abstract>
</front>

<seriesInfo value="1963" name="RFC" />
</reference>


<reference target2="reference.RFC.1964.xml" anchor="RFC1964">
<front>
<title>The Kerberos Version 5 GSS-API Mechanism</title>
<author fullname="John Linn" initials="J." surname="Linn">
<organization>OpenVision Technologies</organization>

<address>
<postal>
<street>One Main St.</street>
<city>Cambridge</city>
<region>MA</region>
<code>02142</code>
<country>US</country>
</postal>

<phone>+1 617 374 2245</phone>
<email>John.Linn@ov.com</email>
</address>
</author>

<date year="1996" month="June" />

<abstract>
<t>This specification defines protocols, procedures, and conventions to be employed by peers implementing the Generic Security Service Application Program Interface (as specified in RFCs 1508 and 1509) when using Kerberos Version 5 technology (as specified in RFC 1510).</t>
</abstract>
</front>

<seriesInfo value="1964" name="RFC" />
</reference>


<reference target2="reference.RFC.1965.xml" anchor="RFC1965">
<front>
<title>Autonomous System Confederations for BGP</title>
<author fullname="Paul Traina" initials="P." surname="Traina">
<organization>cisco Systems, Inc.</organization>

<address>
<postal>
<street>170 W. Tasman Dr.</street>
<city>San Jose</city>
<region>CA</region>
<code>95134</code>
<country>US</country>
</postal>

<email>pst@cisco.com</email>
</address>
</author>

<date year="1996" month="June" />

<abstract>
<t>Border Gateway Protocolis an inter-autonomous system routing protocol designed for TCP/IP networks.</t>

<t>This document describes an extension to BGP which may be used to create a confederation of autonomous systems which is represented as one single autonomous system to BGP peers external to the confederation.</t>

<t>The intention of this extension is to aid in policy administration and reduce the management complexity of maintaining a large autonomous system.</t>

<t>The extension this document describes is widely deployed in the Internet today.</t>
</abstract>
</front>

<seriesInfo value="1965" name="RFC" />
</reference>


<reference target2="reference.RFC.1966.xml" anchor="RFC1966">
<front>
<title>BGP Route Reflection An alternative to full mesh IBGP</title>
<author fullname="Tony Bates" initials="T." surname="Bates">
<organization>cisco Systems</organization>

<address>
<postal>
<street>170 West Tasman Drive</street>
<city>San Jose</city>
<region>CA</region>
<code>95134</code>
<country>US</country>
</postal>

<phone>+1 408 527 2470</phone>
<email>tbates@cisco.com</email>
</address>
</author>

<author fullname="Ravishanker Chandrasekeran" initials="R." surname="Chandrasekeran">
<organization>cisco Systems</organization>

<address>
<postal>
<street>170 West Tasman Drive</street>
<city>San Jose</city>
<region>CA</region>
<code>95134</code>
<country>US</country>
</postal>

<email>rchandra@cisco.com</email>
</address>
</author>

<date year="1996" month="June" />

<abstract>
<t>The Border Gateway Protocolis an inter-autonomous system routing protocol designed for TCP/IP internets. BGP deployments are configured such that that all BGP speakers within a single AS must be fully meshed so that any external routing information must be re-distributed to all other routers within that AS. This represents a serious scaling problem that has been well documented with several alternatives proposed,</t>

<t>This document describes the use and design of a method known as "Route Reflection" to alleviate the the need for "full mesh" IBGP.</t>
</abstract>
</front>

<seriesInfo value="1966" name="RFC" />
</reference>


<reference target2="reference.RFC.1967.xml" anchor="RFC1967">
<front>
<title>PPP LZS-DCP Compression Protocol (LZS-DCP)</title>
<author fullname="Kevin Schneider" initials="K." surname="Schneider">
<organization>Adtran, Inc.</organization>

<address>
<postal>
<street>901 Explorer Blvd.</street>
<city>Huntsville</city>
<region>AL</region>
<code>25806</code>
<country>US</country>
</postal>

<phone>+1 205 971 8024</phone>
<email>kschneider@adtran.com</email>
</address>
</author>

<author fullname="Robert Friend" initials="R." surname="Friend">
<organization>Stac Technology</organization>

<address>
<postal>
<street>12636 High Bluff Drive</street>
<city>San Diego</city>
<region>CA</region>
<code>92130-2093</code>
<country>US</country>
</postal>

<phone>+1 619 794 4542</phone>
<email>rfriend@stac.com</email>
</address>
</author>

<author fullname="Karl Fox" initials="K." surname="Fox">
<organization>Ascend Communications</organization>

<address>
<postal>
<street>3518 Riverside Drive</street>
<street>Suite 101</street>
<city>Columbus</city>
<region>OH</region>
<code>43221</code>
<country>US</country>
</postal>

<email>karl@ascend.com</email>
</address>
</author>

<date year="1996" month="August" />

<abstract>
<t>The Point-to-Point Protocol (PPP)provides a standard method for transporting multi-protocol datagrams over point-to-point links.
   The PPP Compression Control Protocolprovides a method to negotiate and utilize compression protocols over PPP encapsulated links. This document describes the use of the Stac LZS data compression algorithm for compressing PPP encapsulated packets, using a DCP header. This protocol is an enhanced version of the non-DCP (Option 17) PPP Stac LZS compression protocol, and will be referred to as the LZS-DCP Compression Protocol.</t>
</abstract>
</front>

<seriesInfo value="1967" name="RFC" />
</reference>


<reference target2="reference.RFC.1968.xml" anchor="RFC1968">
<front>
<title>The PPP Encryption Control Protocol (ECP)</title>
<author fullname="Gerry Meyer" initials="G." surname="Meyer">
<organization>Spider Systems</organization>

<address>
<postal>
<street>Stanwell Street</street>
<city>Edinburgh</city>
<region>Scotland</region>
<code>EH6 5NG</code>
<country>UK</country>
</postal>

<phone>+44 131 5549424</phone>
<facsimile>+44 131 5540649</facsimile>
<email>gerry@spider.co.uk</email>
</address>
</author>

<author fullname="Karl Fox" initials="K." surname="Fox">
<organization>Ascend Communications</organization>

<address>
<postal>
<street>3518 Riverside Drive</street>
<street>Suite 101</street>
<city>Columbus</city>
<region>OH</region>
<code>43221</code>
<country>US</country>
</postal>

<email>karl@ascend.com</email>
</address>
</author>

<date year="1996" month="June" />

<abstract>
<t>The Point-to-Point Protocol (PPP)
provides a standard method for transporting multi-protocol datagrams over point-to-point links.  PPP also defines an extensible Link Control Protocol.</t>

<t>This document defines a method for negotiating data encryption over PPP links.</t>
</abstract>
</front>

<seriesInfo value="1968" name="RFC" />
</reference>


<reference target2="reference.RFC.1969.xml" anchor="RFC1969">
<front>
<title>The PPP DES Encryption Protocol (DESE)</title>
<author fullname="Keith Sklower" initials="K." surname="Sklower">
<organization>University of California, Berkeley, Computer Science Department</organization>

<address>
<postal>
<street>384 Soda Hall</street>
<street>Mail Stop 1776</street>
<city>Berkeley</city>
<region>CA</region>
<code>94720-1776</code>
<country>US</country>
</postal>

<phone>+1 510 642 9587</phone>
<email>sklower@CS.Berkeley.EDU</email>
</address>
</author>

<author fullname="Gerry M. Meyer" initials="G." surname="Meyer">
<organization>Spider Systems</organization>

<address>
<postal>
<street>Stanwell Street</street>
<city>Edinburgh</city>
<region>Scotland</region>
<code>EH6 5NG</code>
<country>UK</country>
</postal>

<phone>+44 131 5549424</phone>
<facsimile>+44 131 5540649</facsimile>
<email>gerry@spider.co.uk</email>
</address>
</author>

<date year="1996" month="June" />

<abstract>
<t>The Point-to-Point Protocol (PPP)provides a standard method for transporting multi-protocol datagrams over point-to-point links.</t>

<t>The PPP Encryption Control Protocol (ECP)provides a method to negotiate and utilize encryption protocols over PPP encapsulated links.</t>

<t>This document provides specific details for the use of the DES standard,for encrypting PPP encapsulated packets.</t>
</abstract>
</front>

<seriesInfo value="1969" name="RFC" />
</reference>


<reference target2="reference.RFC.1970.xml" anchor="RFC1970">
<front>
<title>Neighbor Discovery for IP Version 6 (IPv6)</title>
<author fullname="Thomas Narten" initials="T." surname="Narten">
<organization>IBM Corporation</organization>

<address>
<postal>
<street>P.O. Box 12195</street>
<city>Research Triangle Park</city>
<region>NC</region>
<code>27709-2195</code>
<country>US</country>
</postal>

<phone>+1 919 254 7798</phone>
<facsimile>+1 919 254 4027</facsimile>
<email>narten@vnet.ibm.com</email>
</address>
</author>

<author fullname="Erik Nordmark" initials="E." surname="Nordmark">
<organization>Sun Microsystems, Inc.</organization>

<address>
<postal>
<street>2550 Garcia Ave</street>
<city>Mountain View</city>
<region>CA</region>
<code>94041</code>
<country>US</country>
</postal>

<phone>+1 415 786 5166</phone>
<facsimile>+1 415 786 5896</facsimile>
<email>nordmark@sun.com</email>
</address>
</author>

<author fullname="William Allen Simpson" initials="W." surname="Simpson">
<organization>Daydreamer,  Computer Systems Consulting Services</organization>

<address>
<postal>
<street>1384 Fontaine</street>
<city>Madison Heights</city>
<region>MI</region>
<code>48071</code>
<country>US</country>
</postal>

<email>Bill.Simpson@um.cc.umich.edu</email>
</address>
</author>

<date year="1996" month="August" />

<abstract>
<t>This document specifies the Neighbor Discovery protocol for IP  Version 6.  IPv6 nodes on the same link use Neighbor Discovery to discover each other's presence, to determine each other's link-layer addresses, to find routers and to maintain reachability information about the paths to active neighbors.</t>
</abstract>
</front>

<seriesInfo value="1970" name="RFC" />
</reference>


<reference target2="reference.RFC.1971.xml" anchor="RFC1971">
<front>
<title>IPv6 Stateless Address Autoconfiguration</title>
<author fullname="Susan Thomson" initials="S." surname="Thomson">
<organization>Bellcore</organization>

<address>
<postal>
<street>445 South Street</street>
<city>Morristown</city>
<region>NJ</region>
<code>07960</code>
<country>US</country>
</postal>

<phone>+1 201 829 4514</phone>
<email>set@thumper.bellcore.com</email>
</address>
</author>

<author fullname="Thomas Narten" initials="T." surname="Narten">
<organization>IBM Corporation</organization>

<address>
<postal>
<street>P.O. Box 12195</street>
<city>Research Triangle Park</city>
<region>NC</region>
<code>27709-2195</code>
<country>US</country>
</postal>

<phone>+1 919 254 7798</phone>
<email>narten@vnet.ibm.com</email>
</address>
</author>

<date year="1996" month="August" />

<abstract>
<t>This document specifies the steps a host takes in deciding how to autoconfigure its interfaces in IP version 6. The autoconfiguration process includes creating a link-local address and verifying its uniqueness on a link, determining what information should be autoconfigured (addresses, other information, or both), and in the case of addresses, whether they should be obtained through the stateless mechanism, the stateful mechanism, or both.  This document defines the process for generating a link-local address, the process for generating site-local and global addresses via stateless address autoconfiguration, and the Duplicate Address Detection procedure. The details of autoconfiguration using the stateful protocol are specified elsewhere.</t>
</abstract>
</front>

<seriesInfo value="1971" name="RFC" />
</reference>


<reference target2="reference.RFC.1972.xml" anchor="RFC1972">
<front>
<title>A Method for the Transmission of IPv6 Packets over Ethernet Networks</title>
<author fullname="Matt Crawford" initials="M." surname="Crawford">
<organization>Fermilab</organization>

<address>
<postal>
<street>MS 368</street>
<street>PO Box 500</street>
<city>Batavia</city>
<region>IL</region>
<code>60510</code>
<country>US</country>
</postal>

<phone>+1 708 840 3461</phone>
<email>crawdad@fnal.gov</email>
</address>
</author>

<date year="1996" month="August" />
</front>

<seriesInfo value="1972" name="RFC" />
</reference>


<reference target2="reference.RFC.1973.xml" anchor="RFC1973">
<front>
<title>PPP in Frame Relay</title>
<author fullname="William Allen Simpson" initials="W." surname="Simpson">
<organization>Daydreamer, Computer Systems Consulting Services</organization>

<address>
<postal>
<street>1384 Fontaine</street>
<city>Madison Heights</city>
<region>MI</region>
<code>48071</code>
<country>US</country>
</postal>

<email>wsimpson@GreenDragon.com</email>
</address>
</author>

<author fullname="Karl Fox" initials="K." surname="Fox">
<organization>Ascend Communications</organization>

<address>
<postal>
<street>3518 Riverside Drive</street>
<street>Suite 101</street>
<city>Columbus</city>
<region>OH</region>
<code>43221</code>
<country>US</country>
</postal>

<email>karl@ascend.com</email>
</address>
</author>

<date year="1996" month="June" />

<abstract>
<t>The Point-to-Point Protocol (PPP)provides a standard method for transporting multi-protocol datagrams over point-to-point links.</t>

<t>This document describes the use of Frame Relay for framing PPP encapsulated packets.</t>
</abstract>
</front>

<seriesInfo value="1973" name="RFC" />
</reference>


<reference target2="reference.RFC.1974.xml" anchor="RFC1974">
<front>
<title>PPP Stac LZS Compression Protocol</title>
<author fullname="Robert Friend" initials="R." surname="Friend">
<organization>Stac Technology</organization>

<address>
<postal>
<street>12636 High Bluff Drive</street>
<city>San Diego</city>
<region>CA</region>
<code>92130</code>
<country>US</country>
</postal>

<phone>+1 619 794 4542</phone>
<email>rfriend@stac.com</email>
</address>
</author>

<author fullname="William Allen Simpson" initials="W." surname="Simpson">
<organization>Daydreamer,  Computer Systems Consulting Services</organization>

<address>
<postal>
<street>1384 Fontaine</street>
<city>Madison Heights</city>
<region>MI</region>
<code>48071</code>
<country>US</country>
</postal>

<email>bsimpson@MorningStar.com</email>
</address>
</author>

<author fullname="Karl F. Fox" initials="K.F." surname="Fox">
<organization>Ascend Communications</organization>

<address>
<postal>
<street>3518 Riverside Dr.</street>
<street>Suite 101</street>
<city>Columbus</city>
<region>OH</region>
<code>43221</code>
<country>US</country>
</postal>

<phone>+1 614 451 1883</phone>
<email>karl@ascend.Com</email>
</address>
</author>

<date year="1996" month="August" />

<abstract>
<t>The Point-to-Point Protocol (PPP)provides a standard method for transporting multi-protocol datagrams over point-to-point links.
   The PPP Compression Control Protocolprovides a method to negotiate and utilize compression protocols over PPP encapsulated links.
   This document describes the use of the Stac LZS data compression algorithm, with single or multiple compression histories, for compressing PPP encapsulated packets.</t>
</abstract>
</front>

<seriesInfo value="1974" name="RFC" />
</reference>


<reference target2="reference.RFC.1975.xml" anchor="RFC1975">
<front>
<title>PPP Magnalink Variable Resource Compression</title>
<author fullname="Doug Schremp" initials="D." surname="Schremp">
<organization>Telco Systems, Inc., Magnalink Communications Division</organization>

<address>
<postal>
<street>63 Nahatan Street</street>
<city>Norwood</city>
<region>MA</region>
<code>02062</code>
<country>US</country>
</postal>

<phone>+1 617 255 9400</phone>
<email>dhs@magna.telco.com</email>
</address>
</author>

<author fullname="Jeffrey Black" initials="J." surname="Black">
<organization>Telco Systems, Inc., Magnalink Communications Division</organization>

<address>
<postal>
<street>63 Nahatan Street</street>
<city>Norwood</city>
<region>MA</region>
<code>02062</code>
<country>US</country>
</postal>

<phone>+1 617 255 9400</phone>
<email>jtb@magna.telco.com</email>
</address>
</author>

<author fullname="Jeffrey Weiss" initials="J." surname="Weiss">
<organization>Telco Systems, Inc.,  Magnalink Communications Division</organization>

<address>
<postal>
<street>63 Nahatan Street</street>
<city>Norwood</city>
<region>MA</region>
<code>02062</code>
<country>US</country>
</postal>

<phone>+1 617 255 9400</phone>
<email>jaw@magna.telco.com</email>
</address>
</author>

<author fullname="Karl Fox" initials="K." surname="Fox">
<organization>Ascend Communications</organization>

<address>
<postal>
<street>3518 Riverside Drive</street>
<street>Suite 101</street>
<city>Columbus</city>
<region>OH</region>
<code>43221</code>
<country>US</country>
</postal>

<email>karl@ascend.com</email>
</address>
</author>

<date year="1996" month="August" />

<abstract>
<t>The Point-to-Point Protocol (PPP)provides a standard method of encapsulating multiple protocol datagrams over point-to-point links. The PPP Compression Control Protocolprovides a method for negotiating data compression over PPP links.</t>

<t>The Magnalink Variable Resource Compression Algorithm (MVRCA) allows a wide range of interoperable compression implementations whose performance characteristics are a function of available CPU and memory resources.</t>
</abstract>
</front>

<seriesInfo value="1975" name="RFC" />
</reference>


<reference target2="reference.RFC.1976.xml" anchor="RFC1976">
<front>
<title>PPP for Data Compression in Data Circuit-Terminating Equipment (DCE)</title>
<author fullname="Kevin Schneider" initials="K." surname="Schneider">
<organization>Adtran, Inc.</organization>

<address>
<postal>
<street>901 Explorer Blvd.</street>
<city>Huntsville</city>
<region>AL</region>
<code>35806-2807</code>
<country>US</country>
</postal>

<phone>+1 205 971 8000</phone>
<email>kevin@adtran.com</email>
</address>
</author>

<author fullname="Stuart Venters" initials="S." surname="Venters">
<organization>Adtran, Inc.</organization>

<address>
<postal>
<street>901 Explorer Blvd.</street>
<city>Huntsville</city>
<region>AL</region>
<code>35806-2807</code>
<country>US</country>
</postal>

<phone>+1 205 971 8000</phone>
<email>sventers@adtran.com</email>
</address>
</author>

<author fullname="Karl Fox" initials="K." surname="Fox">
<organization>Ascend Communications</organization>

<address>
<postal>
<street>3518 Riverside Drive</street>
<street>Suite 101</street>
<city>Columbus</city>
<region>OH</region>
<code>43221</code>
<country>US</country>
</postal>

<email>karl@ascend.com</email>
</address>
</author>

<date year="1996" month="August" />

<abstract>
<t>The Point-to-Point Protocol (PPP)provides a standard method for transporting multi-protocol datagrams over point-to-point links.  PPP
   defines an extensible Link Control Protocol, and proposes a family of Network Control Protocols for establishing and configuring different network-layer protocols.</t>

<t>The PPP Serial Data Transport Protocol (PPP-SDTP)provides a standard method for encapsulating and transporting serial data over a PPP link.  The PPP Compression Control Protocolprovides a standard method for selecting and using a compression protocol to provide for data compression on a PPP link.</t>

<t>This document defines a specific set of parameters for these protocols and an LCP extension to define a standard way of using PPP for data compression of serial data in Data Circuit-Terminating Equipment (DCE).</t>
</abstract>
</front>

<seriesInfo value="1976" name="RFC" />
</reference>


<reference target2="reference.RFC.1977.xml" anchor="RFC1977">
<front>
<title>PPP BSD Compression Protocol</title>
<author fullname="Vernon Schryver" initials="V." surname="Schryver">
<organization />

<address>
<postal>
<street>2482 Lee Hill Drive</street>
<city>Boulder</city>
<region>CO</region>
<code>80302</code>
<country>US</country>
</postal>

<email>vjs@rhyolite.com</email>
</address>
</author>

<date year="1996" month="August" />

<abstract>
<t>The Point-to-Point Protocol (PPP)provides a standard method for transporting multi-protocol datagrams over point-to-point links. The PPP Compression Control Protocolprovides a method to negotiate and utilize compression protocols over PPP encapsulated links. This document describes the use of the Unix Compress compression protocol for compressing PPP encapsulated packets.</t>
</abstract>
</front>

<seriesInfo value="1977" name="RFC" />
</reference>


<reference target2="reference.RFC.1978.xml" anchor="RFC1978">
<front>
<title>PPP Predictor Compression Protocol</title>
<author fullname="Dave Rand" initials="D." surname="Rand">
<organization>Novell, Inc.</organization>

<address>
<postal>
<street>2180 Fortune Drive</street>
<city>San Jose</city>
<region>CA</region>
<code>95131</code>
<country>US</country>
</postal>

<phone>+1 408 321 1259</phone>
<email>dave_rand@novell.com</email>
</address>
</author>

<date year="1996" month="August" />

<abstract>
<t>The Point-to-Point Protocol (PPP)provides a standard method of encapsulating multiple protocol datagrams over point-to-point links. The PPP Compression Control Protocolprovides a method for transporting multi-protocol datagrams over PPP encapsulated links. This document describes the use of the Predictor data compression algorithm for compressing PPP encapsulated packets.</t>
</abstract>
</front>

<seriesInfo value="1978" name="RFC" />
</reference>


<reference target2="reference.RFC.1979.xml" anchor="RFC1979">
<front>
<title>PPP Deflate Protocol</title>
<author fullname="John Woods" initials="J." surname="Woods">
<organization>Proteon, Inc.</organization>

<address>
<postal>
<street>9 Technology Drive</street>
<city>Westborough</city>
<region>MA</region>
<code>01581-1799</code>
<country>US</country>
</postal>

<phone>+1 508 898 2800 x2651</phone>
<email>jfw@funhouse.com</email>
</address>
</author>

<date year="1996" month="August" />

<abstract>
<t>The Point-to-Point Protocol (PPP)provides a standard method for transporting multi-protocol datagrams over point-to-point links.</t>

<t>The PPP Compression Control Protocolprovides a method to negotiate and utilize compression protocols over PPP encapsulated links.</t>

<t>This document describes the use of the PPP Deflate compression protocol for compressing PPP encapsulated packets.</t>
</abstract>
</front>

<seriesInfo value="1979" name="RFC" />
</reference>


<reference target2="reference.RFC.1980.xml" anchor="RFC1980">
<front>
<title>A Proposed Extension to HTML : Client-Side Image Maps</title>
<author fullname="James L. Seidman" initials="J.L." surname="Seidman">
<organization>Spyglass, Inc.</organization>

<address>
<postal>
<street>1230 East Diehl Road</street>
<city>Naperville</city>
<region>IL</region>
<code>60563</code>
<country>US</country>
</postal>

<email>jim@spyglass.com</email>
</address>
</author>

<date year="1996" month="August" />

<abstract>
<t>The markup language known as "HTML/2.0" provides for image maps. Image maps are document elements which allow clicking different areas of an image to reference different network resources, as specified by Uniform Identifier (URIs).  The image map capability in HTML/2.0 is limited in several ways, such as the restriction that it only works with documents served via the "HTTP" protocol, and the lack of a viable fallback for users of text-only browsers.  This document specifies an extension to the HTML language, referred to as "Client- Side Image Maps," which resolves these limitations.</t>
</abstract>
</front>

<seriesInfo value="1980" name="RFC" />
</reference>


<reference target2="reference.RFC.1981.xml" anchor="RFC1981">
<front>
<title>Path MTU Discovery for IP version 6</title>
<author fullname="Jack McCann" initials="J." surname="McCann">
<organization>Digital Equipment Corporation</organization>

<address>
<postal>
<street>110 Spitbrook Road</street>
<street>ZKO3-3/U14</street>
<city>Nashua</city>
<region>NH</region>
<code>03062</code>
<country>US</country>
</postal>

<phone>+1 603 881 2608</phone>
<facsimile>+1 603 881 0120</facsimile>
<email>mccann@zk3.dec.com</email>
</address>
</author>

<author fullname="Stephen E. Deering" initials="S." surname="Deering">
<organization>Xerox Palo Alto Research Center</organization>

<address>
<postal>
<street>3333 Coyote Hill Road</street>
<city>Palo Alto</city>
<region>CA</region>
<code>94304</code>
<country>US</country>
</postal>

<phone>+1 415 812 4839</phone>
<facsimile>+1 415 812 4471</facsimile>
<email>deering@parc.xerox.com</email>
</address>
</author>

<author fullname="Jeffrey Mogul" initials="J." surname="Mogul">
<organization>Digital Equipment Corporation, Western Research Laboratory</organization>

<address>
<postal>
<street>250 University Avenue</street>
<city>Palo Alto</city>
<region>CA</region>
<code>94301</code>
<country>US</country>
</postal>

<phone>+1 415 617 3304</phone>
<email>mogul@pa.dec.com</email>
</address>
</author>

<date year="1996" month="August" />

<abstract>
<t>This document describes Path MTU Discovery for IP version 6.  It is largely derived from RFC 1191, which describes Path MTU Discovery for IP version 4.</t>
</abstract>
</front>

<seriesInfo value="1981" name="RFC" />
</reference>


<reference target2="reference.RFC.1982.xml" anchor="RFC1982">
<front>
<title>Serial Number Arithmetic</title>
<author fullname="Robert Elz" initials="R." surname="Elz">
<organization>University of Melbourne, Computer Science</organization>

<address>
<postal>
<street />
<city>Parkville</city>
<region>Victoria</region>
<code>3052</code>
<country>AU</country>
</postal>

<email>kre@munnari.OZ.AU</email>
</address>
</author>

<author fullname="Randy Bush" initials="R." surname="Bush">
<organization>RGnet, Inc.</organization>

<address>
<postal>
<street>10361 NE Sasquatch Lane</street>
<city>Bainbridge Island</city>
<region>WA</region>
<code>98110</code>
<country>US</country>
</postal>

<email>randy@psg.com</email>
</address>
</author>

<date year="1996" month="August" />

<abstract>
<t>This memo defines serial number arithmetic, as used in the Domain Name System.  The DNS has long relied upon serial number arithmetic, a concept which has never really been defined, certainly not in an IETF document, though which has been widely understood.  This memo supplies the missing definition.  It is intended to update RFC1034 and RFC1035.</t>
</abstract>
</front>

<seriesInfo value="1982" name="RFC" />
</reference>


<reference target2="reference.RFC.1983.xml" anchor="RFC1983">
<front>
<title>Internet Users' Glossary</title>
<author fullname="Gary Scott Malkin" initials="G." surname="Malkin">
<organization>Xylogics/Bay Networks</organization>

<address>
<postal>
<street>53 Third Avenue</street>
<city>Burlington</city>
<region>MA</region>
<code>01803</code>
<country>US</country>
</postal>

<phone>+1 617 238 6237</phone>
<email>gmalkin@Xylogics.COM</email>
</address>
</author>

<date year="1996" month="August" />

<abstract>
<t>There are many networking glossaries in existence.  This glossary concentrates on terms which are specific to the Internet.  Naturally, there are entries for some basic terms and acronyms because other entries refer to them.</t>
</abstract>
</front>

<seriesInfo value="1983" name="RFC" />
</reference>


<reference target2="reference.RFC.1984.xml" anchor="RFC1984">
<front>
<title>IAB and IESG Statement on Cryptographic Technology and the Internet</title>
<author>
<organization>IAB</organization>
</author>

<author>
<organization>IESG</organization>
</author>

<author fullname="Brian E. Carpenter" initials="B.E." surname="Carpenter">
<organization>CERN, European Laboratory for Particle Physics</organization>

<address>
<postal>
<street>1211 Geneva 23</street>
<city />
<region />
<code />
<country>CH</country>
</postal>

<phone>+41 22 7674967</phone>
<email>brian@dxcoms.cern.ch</email>
</address>
</author>

<author fullname="Fred Baker" initials="F." surname="Baker">
<organization>cisco Systems, Inc.</organization>

<address>
<postal>
<street>519 Lado Drive</street>
<city>Santa Barbara</city>
<region>CA</region>
<code>93111</code>
<country>US</country>
</postal>

<phone>+1 805 681 0115</phone>
<email>fred@cisco.com</email>
</address>
</author>

<date year="1996" month="August" />
</front>

<seriesInfo value="1984" name="RFC" />
</reference>


<reference target2="reference.RFC.1985.xml" anchor="RFC1985">
<front>
<title>SMTP Service Extension for Remote Message Queue Starting</title>
<author fullname="Jack De Winter" initials="J." surname="De Winter">
<organization>Wildbear Consulting, Inc.</organization>

<address>
<postal>
<street>17 Brock Street</street>
<city>Kitchener</city>
<region>Ontario</region>
<code>N2M 1X2</code>
<country>CA</country>
</postal>

<phone>+1 519 576 3873</phone>
<email>jack@wildbear.on.ca</email>
</address>
</author>

<date year="1996" month="August" />

<abstract>
<t>This memo defines an extension to the SMTP service whereby an SMTP client and server may interact to give the server an opportunity to start the processing of its queues for messages to go to a given host.  This extension is meant to be used in startup conditions as well as for mail nodes that have transient connections to their service providers.</t>
</abstract>
</front>

<seriesInfo value="1985" name="RFC" />
</reference>


<reference target2="reference.RFC.1986.xml" anchor="RFC1986">
<front>
<title>Experiments with a Simple File Transfer Protocol for Radio Links using Enhanced Trivial File Transfer Protocol (ETFTP)</title>
<author fullname="William J. Polites" initials="W.J." surname="Polites">
<organization>The Mitre Corporation</organization>

<address>
<postal>
<street>145 Wyckoff Rd.</street>
<city>Eatontown</city>
<region>NJ</region>
<code>07724</code>
<country>US</country>
</postal>

<phone>+1 908 544 1414</phone>
<email>wpolites@mitre.org</email>
</address>
</author>

<author fullname="William Wollman" initials="W." surname="Wollman">
<organization>The Mitre Corporation</organization>

<address>
<postal>
<street>145 Wyckoff Rd.</street>
<city>Eatontown</city>
<region>NJ</region>
<code>07724</code>
<country>US</country>
</postal>

<phone>+1 908 544 1414</phone>
<email>wwollman@mitre.org</email>
</address>
</author>

<author fullname="David Woo" initials="D." surname="Woo">
<organization>The Mitre Corporation</organization>

<address>
<postal>
<street>145 Wyckoff Rd.</street>
<city>Eatontown</city>
<region>NJ</region>
<code>07724</code>
<country>US</country>
</postal>

<phone>+1 908 544 1414</phone>
<email>dwoo@mitre.org</email>
</address>
</author>

<author fullname="Russ Langan" initials="R." surname="Langan">
<organization>U.S. Army Communications Electronics Command (CECOM)</organization>

<address>
<postal>
<street>AMSEL-RD-ST-SP</street>
<street>ATTN: Russell Langan</street>
<city>Fort Monmouth</city>
<region>NJ</region>
<code>07703</code>
<country>US</country>
</postal>

<phone>+1 908 427 2064</phone>
<facsimile>+1 908 427 2822</facsimile>
<email>langanr@doim6.monmouth.army.mil</email>
</address>
</author>

<date year="1996" month="August" />
</front>

<seriesInfo value="1986" name="RFC" />
</reference>


<reference target2="reference.RFC.1987.xml" anchor="RFC1987">
<front>
<title>Ipsilon's General Switch Management Protocol Specification Version 1.1</title>
<author fullname="Peter Newman" initials="P." surname="Newman">
<organization>Ipsilon Networks, Inc.</organization>

<address>
<postal>
<street>2191 East Bayshore Road</street>
<street>Suite 100</street>
<city>Palo Alto</city>
<region>CA</region>
<code>94303</code>
<country>US</country>
</postal>

<phone>+1 415 846 4603</phone>
<email>pn@ipsilon.com</email>
</address>
</author>

<author fullname="W. L. Edwards" initials="W.L." surname="Edwards">
<organization>Sprint Technology Services - Long Distance Division</organization>

<address>
<postal>
<street>9300 Metcalf Avenue</street>
<street>Mailstop KSOPKB0802</street>
<city>Overland Park</city>
<region>KS</region>
<code>66212-6333</code>
<country>US</country>
</postal>

<phone>+1 913 534 5334</phone>
<email>texas@sprintcorp.com</email>
</address>
</author>

<author fullname="Robert M. Hinden" initials="R.M." surname="Hinden">
<organization>Ipsilon Networks, Inc.</organization>

<address>
<postal>
<street>2191 East Bayshore Road</street>
<street>Suite 100</street>
<city>Palo Alto</city>
<region>CA</region>
<code>94303</code>
<country>US</country>
</postal>

<phone>+1 415 846 4604</phone>
<email>hinden@ipsilon.com</email>
</address>
</author>

<author fullname="Eric Hoffman" initials="E." surname="Hoffman">
<organization>Ipsilon Networks, Inc.</organization>

<address>
<postal>
<street>2191 East Bayshore Road</street>
<street>Suite 100</street>
<city>Palo Alto</city>
<region>CA</region>
<code>94303</code>
<country>US</country>
</postal>

<phone>+1 415 846 4610</phone>
<email>hoffman@ipsilon.com</email>
</address>
</author>

<author fullname="Fong Ching Liaw" initials="F." surname="Ching Liaw">
<organization>Ipsilon Networks, Inc.</organization>

<address>
<postal>
<street>2191 East Bayshore Road</street>
<street>Suite 100</street>
<city>Palo Alto</city>
<region>CA</region>
<code>94303</code>
<country>US</country>
</postal>

<phone>+1 415 846 4607</phone>
<email>fong@ipsilon.com</email>
</address>
</author>

<author fullname="Tom Lyon" initials="T." surname="Lyon">
<organization>Ipsilon Networks, Inc.</organization>

<address>
<postal>
<street>2191 East Bayshore Road</street>
<street>Suite 100</street>
<city>Palo Alto</city>
<region>CA</region>
<code>94303</code>
<country>US</country>
</postal>

<phone>+1 415 846 4601</phone>
<email>pugs@ipsilon.com</email>
</address>
</author>

<author fullname="Greg Minshall" initials="G." surname="Minshall">
<organization>Ipsilon Networks, Inc.</organization>

<address>
<postal>
<street>2191 East Bayshore Road</street>
<street>Suite 100</street>
<city>Palo Alto</city>
<region>CA</region>
<code>94303</code>
<country>US</country>
</postal>

<phone>+1 415 846 4605</phone>
<email>minshall@ipsilon.com</email>
</address>
</author>

<date year="1996" month="August" />

<abstract>
<t>The General Switch Management Protocol (GSMP), is a general purpose protocol to control an ATM switch. GSMP allows a controller to establish and release connections across the switch; add and delete leaves on a point-to-multipoint connection; manage switch ports; request configuration information; and request statistics.</t>
</abstract>
</front>

<seriesInfo value="1987" name="RFC" />
</reference>


<reference target2="reference.RFC.1988.xml" anchor="RFC1988">
<front>
<title>Conditional Grant of Rights to Specific Hewlett-Packard Patents In Conjunction With the Internet Engineering Task Force's Internet-Standard Network Management Framework</title>
<author fullname="Gary McAnally" initials="G." surname="McAnally">
<organization>Hewlett-Packard Company</organization>

<address>
<postal>
<street>8000 Foothills Blvd.</street>
<city>Roseville</city>
<region>CA</region>
<code>95747</code>
<country>US</country>
</postal>

</address>
</author>

<author fullname="Douglas Gilbert" initials="D." surname="Gilbert">
<organization>Hewlett-Packard Company</organization>

<address>
<postal>
<street>3000 Hanover Street</street>
<city>Palo Alto</city>
<region>CA</region>
<code>94304</code>
<country>US</country>
</postal>

</address>
</author>

<author fullname="John Flick" initials="J." surname="Flick">
<organization>Hewlett-Packard Company</organization>

<address>
<postal>
<street>8000 Foothills Blvd. M.S. 5556</street>
<city>Roseville</city>
<region>CA</region>
<code>95747-5556</code>
<country>US</country>
</postal>

<phone>+1 916 785 4018</phone>
<email>johnf@hprnd.rose.hp.com</email>
</address>
</author>

<date year="1996" month="August" />
</front>

<seriesInfo value="1988" name="RFC" />
</reference>


<reference target2="reference.RFC.1989.xml" anchor="RFC1989">
<front>
<title>PPP Link Quality Monitoring</title>
<author fullname="William Allen Simpson" initials="W." surname="Simpson">
<organization>Daydreamer Computer Systems Consulting Services</organization>

<address>
<postal>
<street>1384 Fontaine</street>
<city>Madison Heights</city>
<region>MI</region>
<code>48071</code>
<country>US</country>
</postal>

<email>bsimpson@MorningStar.com</email>
</address>
</author>

<date year="1996" month="August" />

<abstract>
<t>The Point-to-Point Protocol (PPP)provides a standard method for transporting multi-protocol datagrams over point-to-point links.</t>

<t>PPP also defines an extensible Link Control Protocol, which allows negotiation of a Quality Protocol for continuous monitoring of the viability of the link.</t>

<t>This document defines a protocol for generating Link-Quality-Reports.</t>
</abstract>
</front>

<seriesInfo value="1989" name="RFC" />
</reference>


<reference target2="reference.RFC.1990.xml" anchor="RFC1990">
<front>
<title>The PPP Multilink Protocol (MP)</title>
<author fullname="Keith Sklower" initials="K." surname="Sklower">
<organization>University of California,  Berkeley, Computer Science Department</organization>

<address>
<postal>
<street>384 Soda Hall</street>
<street>Mail Stop 1776</street>
<city>Berkeley</city>
<region>CA</region>
<code>94720-1776</code>
<country>US</country>
</postal>

<phone>+1 510 642 9587</phone>
<email>sklower@CS.Berkeley.EDU</email>
</address>
</author>

<author fullname="Brian Lloyd" initials="B." surname="Lloyd">
<organization>Lloyd Internetworking</organization>

<address>
<postal>
<street>3031 Alhambra Drive</street>
<city>Cameron Park</city>
<region>CA</region>
<code>95682</code>
<country>US</country>
</postal>

<phone>+1 916 676 1147</phone>
<email>brian@lloyd.com</email>
</address>
</author>

<author fullname="Glenn McGregor" initials="G." surname="McGregor">
<organization>Lloyd Internetworking</organization>

<address>
<postal>
<street>3031 Alhambra Drive</street>
<city>Cameron Park</city>
<region>CA</region>
<code>95682</code>
<country>US</country>
</postal>

<phone>+1 916 676 1147</phone>
<email>glenn@lloyd.com</email>
</address>
</author>

<author fullname="Dave Carr" initials="D." surname="Carr">
<organization>Newbridge Networks Corporation</organization>

<address>
<postal>
<street>600 March Road</street>
<street>P.O. Box 13600</street>
<city>Kanata</city>
<region>Ontario</region>
<code>K2K 2E6</code>
<country>CA</country>
</postal>

<phone>+1 613 591 3600</phone>
<email>dcarr@Newbridge.COM</email>
</address>
</author>

<author fullname="Tom Coradetti" initials="T." surname="Coradetti">
<organization>Sidewalk Software</organization>

<address>
<postal>
<street>1190 Josephine Road</street>
<city>Roseville</city>
<region>MN</region>
<code>55113</code>
<country>US</country>
</postal>

<phone>+1 612 490 7856</phone>
<email>70761.1664@compuserve.com</email>
</address>
</author>

<date year="1996" month="August" />

<abstract>
<t>This document proposes a method for splitting, recombining and sequencing datagrams across multiple logical data links.  This work was originally motivated by the desire to exploit multiple bearer channels in ISDN, but is equally applicable to any situation in which multiple PPP links connect two systems, including async links.  This is accomplished by means of new PPP  options and protocols.</t>

<t>The differences between the current PPP Multilink specification (RFC1717) and this memo are explained in Section 11.  Any system implementing the additional restrictions required by this memo will be backwards compatible with conforming RFC 1717 implementations.</t>
</abstract>
</front>

<seriesInfo value="1990" name="RFC" />
</reference>


<reference target2="reference.RFC.1991.xml" anchor="RFC1991">
<front>
<title>PGP Message Exchange Formats</title>
<author fullname="Derek Atkins" initials="D." surname="Atkins">
<organization>MIT</organization>

<address>
<postal>
<street>12 Rindge Ave. #1R</street>
<city>Cambridge</city>
<region>MA</region>
<code>02140</code>
<country>US</country>
</postal>

<phone>+1 617 868 4469</phone>
<email>warlord@MIT.EDU</email>
</address>
</author>

<author fullname="William Stallings" initials="W." surname="Stallings">
<organization>Comp-Comm Consulting</organization>

<address>
<postal>
<street>P. O. Box 2405</street>
<city>Brewster</city>
<region>MA</region>
<code>02631</code>
<country>US</country>
</postal>

<email>stallings@ACM.org</email>
</address>
</author>

<author fullname="Philip Zimmermann" initials="P." surname="Zimmermann">
<organization>Boulder Software Engineering</organization>

<address>
<postal>
<street>3021 Eleventh Street</street>
<city>Boulder</city>
<region>CO</region>
<code>80304</code>
<country>US</country>
</postal>

<phone>+1 303 541 0140</phone>
<email>prz@acm.org</email>
</address>
</author>

<date year="1996" month="August" />
</front>

<seriesInfo value="1991" name="RFC" />
</reference>


<reference target2="reference.RFC.1992.xml" anchor="RFC1992">
<front>
<title>The Nimrod Routing Architecture</title>
<author fullname="Isidro Castineyra" initials="I." surname="Castineyra">
<organization>BBN Systems and Technologies</organization>

<address>
<postal>
<street>10 Moulton Street</street>
<city>Cambridge</city>
<region>MA</region>
<code>02138</code>
<country>US</country>
</postal>

<phone>+1 617 873 6233</phone>
<email>isidro@bbn.com</email>
</address>
</author>

<author fullname="Noel Chiappa" initials="N." surname="Chiappa">
<organization />

<address>
<email>gnc@ginger.lcs.mit.edu</email>
</address>
</author>

<author fullname="Martha Steenstrup" initials="M." surname="Steenstrup">
<organization>BBN Systems and Technologies</organization>

<address>
<postal>
<street>10 Moulton Street</street>
<city>Cambridge</city>
<region>MA</region>
<code>02138</code>
<country>US</country>
</postal>

<phone>+1 617 873 3192</phone>
<email>msteenst@bbn.com</email>
</address>
</author>

<date year="1996" month="August" />

<abstract>
<t>We present a scalable internetwork routing architecture, called Nimrod.  The Nimrod architecture is designed to accommodate a dynamic internetwork of arbitrary size with heterogeneous service requirements and restrictions and to admit incremental deployment throughout an internetwork.  The key to Nimrod's scalability is its ability to represent and manipulate routing-related information at multiple levels of abstraction.</t>
</abstract>
</front>

<seriesInfo value="1992" name="RFC" />
</reference>


<reference target2="reference.RFC.1993.xml" anchor="RFC1993">
<front>
<title>PPP Gandalf FZA Compression Protocol</title>
<author fullname="A. Barbir" initials="A." surname="Barbir">
<organization>Gandalf Data Limited</organization>

<address>
<postal>
<street>130 Colonnade Road South</street>
<city>Napean</city>
<region>Ontario</region>
<code>K2E 7M4</code>
<country>CA</country>
</postal>

<phone>+1 613 274 6500 x8550</phone>
<email>abarbir@gandalf.ca</email>
</address>
</author>

<author fullname="D. Carr" initials="D." surname="Carr">
<organization>Newbridge Networks Corporation</organization>

<address>
<postal>
<street>600 March Road</street>
<street>P.O. Box 13600</street>
<city>Kanata</city>
<region>Ontario</region>
<code>K2K 2E6</code>
<country>CA</country>
</postal>

<email>dcarr@newbridge.com</email>
</address>
</author>

<author fullname="William Allen Simpson" initials="W." surname="Simpson">
<organization>Computer Systems Consulting Service</organization>

<address>
<postal>
<street>1384 Fontaine</street>
<city>Madison Heights</city>
<region>MI</region>
<code>48071</code>
<country>US</country>
</postal>

<email>wsimpson@GreenDragon.com</email>
</address>
</author>

<date year="1996" month="August" />

<abstract>
<t>The Point-to-Point Protocol (PPP) [provides a standard method for transporting multi-protocol datagrams over point-to-point links. The PPP Compression Control Protocolprovides a method to negotiate and utilize compression protocols over PPP encapsulated links.</t>

<t>This document describes the use of the Gandalf FZA data compression algorithmfor compressing PPP encapsulated packets.</t>
</abstract>
</front>

<seriesInfo value="1993" name="RFC" />
</reference>


<reference target2="reference.RFC.1994.xml" anchor="RFC1994">
<front>
<title>PPP Challenge Handshake Authentication Protocol (CHAP)</title>
<author fullname="William Allen Simpson" initials="W." surname="Simpson">
<organization>DayDreamer Computer Systems Consulting Services</organization>

<address>
<postal>
<street>1384 Fontaine</street>
<city>Madison Heights</city>
<region>MI</region>
<code>48071</code>
<country>US</country>
</postal>

<email>wsimpson@GreenDragon.com</email>
</address>
</author>

<date year="1996" month="August" />

<abstract>
<t>The Point-to-Point Protocol (PPP)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 authenticating its peer before allowing Network Layer protocols to transmit over the link.</t>

<t>This document defines a method for Authentication using PPP, which uses a random Challenge, with a cryptographically hashed Response which depends upon the Challenge and a secret key.</t>
</abstract>
</front>

<seriesInfo value="1994" name="RFC" />
</reference>


<reference target2="reference.RFC.1995.xml" anchor="RFC1995">
<front>
<title>Incremental Zone Transfer in DNS</title>
<author fullname="Masataka Ohta" initials="M." surname="Ohta">
<organization>Computer Center Tokyo Institute of Technology</organization>

<address>
<postal>
<street>2-12-1, O-okayama</street>
<street>Meguro-ku</street>
<city>Tokyo</city>
<code>152</code>
<country>JP</country>
</postal>

<phone>+81 3 57343299</phone>
<facsimile>+81 3 57343415</facsimile>
<email>mohta@necom830.hpcl.titech.ac.jp</email>
</address>
</author>

<date year="1996" month="August" />

<abstract>
<t>This document proposes extensions to the DNS protocols to provide an incremental zone transfer (IXFR) mechanism.</t>
</abstract>
</front>

<seriesInfo value="1995" name="RFC" />
</reference>


<reference target2="reference.RFC.1996.xml" anchor="RFC1996">
<front>
<title>A Mechanism for Prompt Notification of Zone Changes (DNS NOTIFY)</title>
<author fullname="Paul Vixie" initials="P." surname="Vixie">
<organization>Internet Software Consortium</organization>

<address>
<postal>
<street>Star Route Box 159A</street>
<city>Woodside</city>
<region>CA</region>
<code>94062</code>
<country>US</country>
</postal>

<phone>+1 415 747 0204</phone>
<email>paul@vix.com</email>
</address>
</author>

<date year="1996" month="August" />

<abstract>
<t>This memo describes the NOTIFY opcode for DNS, by which a master server advises a set of slave servers that the master's data has been changed and that a query should be initiated to discover the new data.</t>
</abstract>
</front>

<seriesInfo value="1996" name="RFC" />
</reference>


<reference target2="reference.RFC.1997.xml" anchor="RFC1997">
<front>
<title>BGP Communities Attribute</title>
<author fullname="Ravishanker Chandrasekeran" initials="R." surname="Chandrasekeran">
<organization>cisco Systems, Inc.</organization>

<address>
<postal>
<street>170 W. Tasman Dr.</street>
<city>San Jose</city>
<region>CA</region>
<code>95134</code>
<country>US</country>
</postal>

<email>rchandra@cisco.com</email>
</address>
</author>

<author fullname="Paul Traina" initials="P." surname="Traina">
<organization>cisco Systems, Inc.</organization>

<address>
<postal>
<street>170 W. Tasman Dr.</street>
<city>San Jose</city>
<region>CA</region>
<code>95134</code>
<country>US</country>
</postal>

<email>pst@cisco.com</email>
</address>
</author>

<author fullname="Tony Li" initials="T." surname="Li">
<organization />

<address>
<email>tli@skat.usc.edu</email>
</address>
</author>

<date year="1996" month="August" />

<abstract>
<t>Border Gateway Protocolis an inter-autonomous system routing protocol designed for TCP/IP internets. This document describes an extension to BGP which may be used to pass additional information to both neighboring and remote BGP peers. The intention of the proposed technique is to aid in policy administration and reduce the management complexity of maintaining the Internet.</t>
</abstract>
</front>

<seriesInfo value="1997" name="RFC" />
</reference>


<reference target2="reference.RFC.1998.xml" anchor="RFC1998">
<front>
<title>An Application of the BGP Community Attribute in Multi-home Routing</title>
<author fullname="Enke Chen" initials="E." surname="Chen">
<organization>MCI</organization>

<address>
<postal>
<street>2100 Reston Parkway</street>
<city>Reston</city>
<region>VA</region>
<code>22091</code>
<country>US</country>
</postal>

<phone>+1 703 715 7087</phone>
<email>enke@mci.net</email>
</address>
</author>

<author fullname="Tony Bates" initials="T." surname="Bates">
<organization>cisco Systems</organization>

<address>
<postal>
<street>170 West Tasman Drive</street>
<city>San Jose</city>
<region>CA</region>
<code>95134</code>
<country>US</country>
</postal>

<phone>+1 408 527 2470</phone>
<email>tbates@cisco.com</email>
</address>
</author>

<date year="1996" month="August" />

<abstract>
<t>This document presents an application of the BGP community attributein simplifying the implementation and configuration of routing policies in the multi-provider Internet. It shows how the community based configuration can be used to replace the AS-based customization of the BGP "LOCAL_PREF" attribute, a common method used today.  Not only does the technique presented simplifies configuration and management at the provider level, it also represents a paradigm shift in that it gives the potential for the customer to control its own routing policy with respect to its service provider, as well as providing the ability for policy configuration to be done at a prefix based granularity rather than the more common AS based granularity.</t>
</abstract>
</front>

<seriesInfo value="1998" name="RFC" />
</reference>


<reference target2="reference.RFC.1999.xml" anchor="RFC1999">
<front>
<title>Request for Comments Summary RFC Numbers 1900-1999</title>
<author fullname="J. Elliott" initials="J." surname="Elliott">
<organization>University of Southern California, Information Sciences Institute</organization>

<address>
<postal>
<street>4676 Admiralty Way</street>
<city>Marina del Rey</city>
<region>CA</region>
<code>90292</code>
<country>US</country>
</postal>

<phone>+1 310 822 1511</phone>
<email>elliott@isi.edu</email>
</address>
</author>

<date year="1997" month="January" />
</front>

<seriesInfo value="1999" name="RFC" />
</reference>


<reference target2="reference.RFC.2000.xml" anchor="RFC2000">
<front>
<title abbrev="Internet Standards">Internet Official Protocol Standards</title>
<author fullname="Jon Postel" initials="J." surname="Postel">
<organization>USC/Information Sciences Institute</organization>

<address>
<postal>
<street>4676 Admiralty Way</street>
<city>Marina del Rey</city>
<region>CA</region>
<code>90292</code>
<country>US</country>
</postal>

<phone>+1 310 822 1511</phone>
<facsimile>+1 310 823 6714</facsimile>
<email>Postel@ISI.EDU</email>
</address>
</author>

<date year="1997" month="February" />

<abstract>
<t></t>
</abstract>
</front>

<seriesInfo value="2000" name="RFC" />
</reference>


<reference target2="reference.RFC.2001.xml" anchor="RFC2001">
<front>
<title abbrev="TCP">TCP Slow Start, Congestion Avoidance, Fast Retransmit, and Fast Recovery Algorithms</title>
<author fullname="W. Richard Stevens" initials="W.R." surname="Stevens">
<organization />

<address>
<postal>
<street>1202 E. Paseo del Zorro</street>
<street>Tucson</street>
<street>AZ  85718</street>
</postal>

<phone>520-297-9416</phone>
<email>rstevens@noao.edu</email>
<uri>http://www.noao.edu/~rstevens</uri>
</address>
</author>

<date year="1997" month="January" />
<area>Transport</area>
<keyword>slow start</keyword>
<keyword>congestion</keyword>
<keyword>transmission control protocol</keyword>

<abstract>
<t>
   Modern implementations of TCP contain four intertwined algorithms
   that have never been fully documented as Internet standards:  slow
   start, congestion avoidance, fast retransmit, and fast recovery.  
   and  provide some details on these algorithms,  provides
   examples of the algorithms in action, and  provides the source
   code for the 4.4BSD implementation.  RFC 1122 requires that a TCP
   must implement slow start and congestion avoidance (Section 4.2.2.15
   of ), citing  as the reference, but fast retransmit and fast
   recovery were implemented after RFC 1122.  The purpose of this
   document is to document these four algorithms for the Internet.
</t>
</abstract>
</front>

<seriesInfo value="2001" name="RFC" />
<format octets="25964" type="HTML" target="http://xml.resource.org/public/rfc/html/rfc2001.html" />
<format octets="14271" type="XML" target="http://xml.resource.org/public/rfc/xml/rfc2001.xml" />
</reference>


<reference target2="reference.RFC.2002.xml" anchor="RFC2002">
<front>
<title>IP Mobility Support</title>
<author fullname="Charles Perkins" initials="C." surname="Perkins">
<organization>IBM Corporation, T. J. Watson Research Center</organization>

<address>
<postal>
<street>30 Saw Mill River Rd.</street>
<city>Hawthorne</city>
<region>NY</region>
<code>10532</code>
<country>US</country>
</postal>

<phone>+1 914 784 7350</phone>
<facsimile>+1 914 784 6205</facsimile>
<email>perk@watson.ibm.com</email>
</address>
</author>

<date year="1996" month="October" />

<abstract>
<t>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.</t>
</abstract>
</front>

<seriesInfo value="2002" name="RFC" />
</reference>


<reference target2="reference.RFC.2003.xml" anchor="RFC2003">
<front>
<title abbrev="IP-within-IP">IP Encapsulation within IP</title>
<author fullname="Charles Perkins" initials="C." surname="Perkins">
<organization>Room H3-D34</organization>

<address>
<postal>
<street>T. J. Watson Research Center</street>
<street>IBM Corporation</street>
<street>30 Saw Mill River Rd.</street>
<street>Hawthorne</street>
<street>NY  10532</street>
</postal>

<facsimile>+1-914-784-6205</facsimile>
<email>perk@watson.ibm.com</email>
</address>
</author>

<date year="1996" month="October" />
<area>Internet</area>
<keyword>encapsulate</keyword>
<keyword>mobile ip</keyword>
<keyword>routing</keyword>
<keyword>wireless</keyword>

<abstract>
<t>
   This document specifies a method by which an IP datagram may be
   encapsulated (carried as payload) within an IP datagram.
   Encapsulation is suggested as a means to alter the normal IP routing
   for datagrams, by delivering them to an intermediate destination that
   would otherwise not be selected by the (network part of the) IP
   Destination Address field in the original IP header.  Encapsulation
   may serve a variety of purposes, such as delivery of a datagram to a
   mobile node using Mobile IP.
</t>
</abstract>
</front>

<seriesInfo value="2003" name="RFC" />
<format octets="46253" type="HTML" target="http://xml.resource.org/public/rfc/html/rfc2003.html" />
<format octets="33466" type="XML" target="http://xml.resource.org/public/rfc/xml/rfc2003.xml" />
</reference>


<reference target2="reference.RFC.2004.xml" anchor="RFC2004">
<front>
<title abbrev="Minimal Encapsulation for IP">Minimal Encapsulation within IP</title>
<author fullname="Charles Perkins" initials="C." surname="Perkins">
<organization>Room H3-D34</organization>

<address>
<postal>
<street>T. J. Watson Research Center</street>
<street>IBM Corporation</street>
<street>30 Saw Mill River Rd.</street>
<street>Hawthorne</street>
<street>NY  10532</street>
</postal>

<facsimile>+1-914-784-6205</facsimile>
<email>perk@watson.ibm.com</email>
</address>
</author>

<date year="1996" month="October" />
<area>Internet</area>
<keyword>encapsulate</keyword>
<keyword>mobile ip</keyword>
<keyword>routing</keyword>
<keyword>wireless</keyword>

<abstract>
<t>
   This document specifies a method by which an IP datagram may be
   encapsulated (carried as payload) within an IP datagram, with less
   overhead than &quot;conventional&quot; IP encapsulation that adds a second IP
   header to each encapsulated datagram.  Encapsulation is suggested as
   a means to alter the normal IP routing for datagrams, by delivering
   them to an intermediate destination that would otherwise not be
   selected by the (network part of the) IP Destination Address field in
   the original IP header.  Encapsulation may be serve a variety of
   purposes, such as delivery of a datagram to a mobile node using
   Mobile IP.
</t>
</abstract>
</front>

<seriesInfo value="2004" name="RFC" />
<format octets="25587" type="HTML" target="http://xml.resource.org/public/rfc/html/rfc2004.html" />
<format octets="13915" type="XML" target="http://xml.resource.org/public/rfc/xml/rfc2004.xml" />
</reference>


<reference target2="reference.RFC.2005.xml" anchor="RFC2005">
<front>
<title abbrev="Mobile IP Applicability Statement">Applicability Statement for IP Mobility Support</title>
<author fullname="Jim Solomon" initials="J." surname="Solomon">
<organization>Motorola Inc.</organization>

<address>
<postal>
<street>1301 E. Algonquin Rd. - Rm 2240</street>
<street>Schaumburg</street>
<street>IL  60196</street>
</postal>

<facsimile>+1-847-576-3240</facsimile>
<email>solomon@comm.mot.com</email>
</address>
</author>

<date year="1996" month="October" />
<area>Internet</area>
<keyword>mobile ip</keyword>
<keyword>routing</keyword>
<keyword>wireless</keyword>

<abstract>
<t>
   As required by [RFC 1264], this report discusses the applicability of
   Mobile IP to provide host mobility in the Internet.  In particular,
   this document describes the key features of Mobile IP and shows how
   the requirements for advancement to Proposed Standard RFC have been
   satisfied.
</t>
</abstract>
</front>

<seriesInfo value="2005" name="RFC" />
<format octets="24602" type="HTML" target="http://xml.resource.org/public/rfc/html/rfc2005.html" />
<format octets="13012" type="XML" target="http://xml.resource.org/public/rfc/xml/rfc2005.xml" />
</reference>


<reference target2="reference.RFC.2006.xml" anchor="RFC2006">
<front>
<title abbrev="Mobile IP MIB Definition using SMIv2">The Definitions of Managed Objects for IP Mobility Support using SMIv2</title>
<author fullname="David Cong" initials="D." surname="Cong">
<organization>Motorola</organization>

<address>
<postal>
<street>1301 East Algonquin Rd.</street>
<street>Room 3149</street>
<city>Schaumburg</city>
<region>IL</region>
<code>60196</code>
<country>US</country>
</postal>

<phone>+1 847 576 1357</phone>
<facsimile>+1 847 538 3472</facsimile>
<email>cong@comm.mot.com</email>
</address>
</author>

<author fullname="Mark Hamlen" initials="M." surname="Hamlen">
<organization>Motorola</organization>

<address>
<postal>
<street>1301 East Algonquin Rd.</street>
<street>Room 4413</street>
<city>Schaumburg</city>
<region>IL</region>
<code>60196</code>
<country>US</country>
</postal>

<phone>+1 847 576 0346</phone>
<facsimile>+1 847 538 6150</facsimile>
<email>hamlen@comm.mot.com</email>
</address>
</author>

<author fullname="Charles Perkins" initials="C." surname="Perkins">
<organization>IBM Corporation, T. J. Watson Research Center</organization>

<address>
<postal>
<street>30 Saw Mill River Rd.</street>
<street>Room J1-A25</street>
<city>Hawthorne</city>
<region>NY</region>
<code>10532</code>
<country>US</country>
</postal>

<phone>+1 914 784 7350</phone>
<facsimile>+1 914 784 7007</facsimile>
<email>perk@watson.ibm.com</email>
</address>
</author>

<date year="1996" month="October" />

<abstract>
<t>This memo defines the Management Information Base (MIB) for use with network management protocols in TCP/IP-based internets.  In particular, it describes managed objects used for managing the Mobile Node, Foreign Agent and Home Agent of the Mobile IP Protocol.</t>
</abstract>
</front>

<seriesInfo value="2006" name="RFC" />
</reference>


<reference target2="reference.RFC.2007.xml" anchor="RFC2007">
<front>
<title>Catalogue of Network Training Materials</title>
<author fullname="Jill Foster" initials="J." surname="Foster">
<organization>University of Newcastle,  University Computing Service</organization>

<address>
<postal>
<street>Claremont Road</street>
<city>Newcastle upon Tyne</city>
<region>England</region>
<code>NE1 7RU</code>
<country>UK</country>
</postal>

<phone>+44 191 2228250</phone>
<facsimile>+44 191 2225001</facsimile>
<email>Jill.Foster@newcastle.ac.uk</email>
</address>
</author>

<author fullname="Margaret Isaacs" initials="M." surname="Isaacs">
<organization>University of Glasgow, Department of Computing Science</organization>

<address>
<postal>
<street />
<city>Glasgow</city>
<region>Scotland</region>
<code>G12 8QQ</code>
<country>UK</country>
</postal>

<phone>+44 141 3305314</phone>
<facsimile>+44 141 3304913</facsimile>
<email>mmi@dcs.gla.ac.uk</email>
</address>
</author>

<author fullname="Mark Prior" initials="M." surname="Prior">
<organization>AAP Telecommunications</organization>

<address>
<postal>
<street>45 Pirie Street (Level 1)</street>
<city>Adelaide</city>
<region>SA</region>
<code>5000</code>
<country>AU</country>
</postal>

<phone>+61 8 82032088</phone>
<email>mrp@connect.com.au</email>
</address>
</author>

<date year="1996" month="October" />

<abstract>
<t>The purpose of this document is to provide a catalogue of quality Network Training Materials for use by Internet trainers in training their users. By providing such a collection of pointers to useful resources, it is hoped that trainers will be relieved of much of the load of producing current training materials.</t>
</abstract>
</front>

<seriesInfo value="2007" name="RFC" />
</reference>


<reference target2="reference.RFC.2008.xml" anchor="RFC2008">
<front>
<title abbrev="Address Allocation">Implications of Various Address Allocation Policies for Internet Routing</title>
<author fullname="Yakov Rekhter" initials="Y." surname="Rekhter">
<organization>cisco Systems, Inc.</organization>

<address>
<postal>
<street>170 Tasman Dr.</street>
<street>San Jose</street>
<street>CA 95134</street>
</postal>

<phone>(914) 528-0090</phone>
<email>yakov@cisco.com</email>
</address>
</author>

<author fullname="Tony Li" initials="T." surname="Li">
<organization>cisco Systems, Inc.</organization>

<address>
<postal>
<street>170 Tasman Dr.</street>
<street>San Jose</street>
<street>CA 95134</street>
</postal>

<phone>(408) 526-8186</phone>
<email>tli@cisco.com</email>
</address>
</author>

<date year="1996" month="October" />
<area>Internet</area>
<keyword>IP address</keyword>
<keyword>classless inter-domain routing</keyword>
<keyword>routing</keyword>

<note title="IESG Note">
<t>
   The addressing constraints described in this document are largely the
   result of the interaction of existing router technology, address
   assignment, and architectural history.  After extensive review and
   discussion, the authors of this document, the IETF working group that
   reviewed it, and the IESG have concluded that there are no other
   currently deployable technologies available to overcome these
   limitations.  In the event that routing or router technology develops
   to the point that adequate routing aggregation can be achieved by
   other means or that routers can deal with larger routing and more
   dynamic tables, it may be appropriate to review these constraints.
</t>
</note>
</front>

<seriesInfo value="7" name="BCP" />
<seriesInfo value="2008" name="RFC" />
<format octets="48825" type="HTML" target="http://xml.resource.org/public/rfc/html/rfc2008.html" />
<format octets="37768" type="XML" target="http://xml.resource.org/public/rfc/xml/rfc2008.xml" />
</reference>


<reference target2="reference.RFC.2009.xml" anchor="RFC2009">
<front>
<title>GPS-Based Addressing and Routing</title>
<author fullname="Tomasz Imielinski" initials="T." surname="Imielinski">
<organization>Rutgers State University, Computer Science Department, Busch Campus</organization>

<address>
<postal>
<street />
<city>Piscataway</city>
<region>NJ</region>
<code>08855</code>
<country>US</country>
</postal>

<phone>+1 908 445 3551</phone>
<email>imielins@cs.rutgers.edu</email>
</address>
</author>

<author fullname="Julio C. Navas" initials="J.C." surname="Navas">
<organization>Rutgers State University, Computer Science Department, Busch Campus</organization>

<address>
<postal>
<street />
<city>Piscataway</city>
<region>NJ</region>
<code>08855</code>
<country>US</country>
</postal>

<phone>+1 908 445 3551</phone>
<email>navas@cs.rutgers.edu</email>
</address>
</author>

<date year="1996" month="November" />

<abstract>
<t></t>
</abstract>
</front>

<seriesInfo value="2009" name="RFC" />
</reference>


<reference target2="reference.RFC.2010.xml" anchor="RFC2010">
<front>
<title abbrev="DNSSVR Criteria">Operational Criteria for Root Name Servers</title>
<author fullname="Bill Manning" initials="B." surname="Manning">
<organization>USC/ISI</organization>

<address>
<postal>
<street>4676 Admiralty Way</street>
<street>Marina del Rey</street>
<street>CA 90292</street>
</postal>

<phone>+1 310 822 1511</phone>
<email>bmanning@isi.edu</email>
</address>
</author>

<author fullname="Paul Vixie" initials="P." surname="Vixie">
<organization>Internet Software Consortium</organization>

<address>
<postal>
<street>Star Route Box 159A</street>
<street>Woodside</street>
<street>CA 94062</street>
</postal>

<phone>+1 415 747 0204</phone>
<email>paul@vix.com</email>
</address>
</author>

<date year="1996" month="October" />
<area>Applications</area>
<keyword>DNS</keyword>
<keyword>domain name system</keyword>

<abstract>
<t>
   This document specifies the operational requirements of root name
   servers, including host hardware capacities, name server software
   revisions, network connectivity, and physical environment.
</t>
</abstract>
</front>

<seriesInfo value="2010" name="RFC" />
<format octets="23596" type="HTML" target="http://xml.resource.org/public/rfc/html/rfc2010.html" />
<format octets="15776" type="XML" target="http://xml.resource.org/public/rfc/xml/rfc2010.xml" />
</reference>


<reference target2="reference.RFC.2011.xml" anchor="RFC2011">
<front>
<title abbrev="IP MIB">SNMPv2 Management Information Base for the Internet Protocol using SMIv2</title>
<author fullname="Keith McCloghrie" initials="K." surname="McCloghrie">
<organization>Cisco Systems, Inc.</organization>

<address>
<postal>
<street>170 West Tasman Drive</street>
<street>San Jose</street>
<street>CA  95134-1706</street>
<country>US</country>
</postal>

<phone>+1 408 526 5260</phone>
<email>kzm@cisco.com</email>
</address>
</author>

<date year="1996" month="November" />
<area>Management</area>
<area>Internet</area>
<keyword>Management Information Base</keyword>
<keyword>internet control message protocol</keyword>
<keyword>simple network management protocol version 2</keyword>
<keyword>structure of management information version 2</keyword>

<note title="IESG Note">
<t>
   The IP, UDP, and TCP MIB modules currently support only IPv4.  These
   three modules use the IpAddress type defined as an OCTET STRING of
   length 4 to represent the IPv4 32-bit internet addresses.  (See RFC
   1902, SMI for SNMPv2.)  They do not support the new 128-bit IPv6
   internet addresses.
</t>
</note>
</front>

<seriesInfo value="2011" name="RFC" />
<format octets="42108" type="HTML" target="http://xml.resource.org/public/rfc/html/rfc2011.html" />
<format octets="31101" type="XML" target="http://xml.resource.org/public/rfc/xml/rfc2011.xml" />
</reference>


<reference target2="reference.RFC.2012.xml" anchor="RFC2012">
<front>
<title abbrev="TCP MIB">SNMPv2 Management Information Base for the Transmission Control Protocol using SMIv2</title>
<author fullname="Keith McCloghrie" initials="K." surname="McCloghrie">
<organization>Cisco Systems, Inc.</organization>

<address>
<postal>
<street>170 West Tasman Drive</street>
<street>San Jose</street>
<street>CA  95134-1706</street>
<country>US</country>
</postal>

<phone>+1 408 526 5260</phone>
<email>kzm@cisco.com</email>
</address>
</author>

<date year="1996" month="November" />
<area>Transport</area>
<area>Management</area>
<keyword>TCP</keyword>
<keyword>Management Information Base</keyword>
<keyword>control protocol</keyword>
<keyword>simple network management protocol version 2</keyword>
<keyword>structure of management information version 2</keyword>
<keyword>transmission control protocol</keyword>

<note title="IESG Note">
<t>
   The IP, UDP, and TCP MIB modules currently support only IPv4.  These
   three modules use the IpAddress type defined as an OCTET STRING of
   length 4 to represent the IPv4 32-bit internet addresses.  (See RFC
   1902, SMI for SNMPv2.)  They do not support the new 128-bit IPv6
   internet addresses.
</t>
</note>
</front>

<seriesInfo value="2012" name="RFC" />
<format octets="28456" type="HTML" target="http://xml.resource.org/public/rfc/html/rfc2012.html" />
<format octets="17610" type="XML" target="http://xml.resource.org/public/rfc/xml/rfc2012.xml" />
</reference>


<reference target2="reference.RFC.2013.xml" anchor="RFC2013">
<front>
<title abbrev="UDP MIB">SNMPv2 Management Information Base for the User Datagram Protocol using SMIv2</title>
<author fullname="Keith McCloghrie" initials="K." surname="McCloghrie">
<organization>Cisco Systems, Inc.</organization>

<address>
<postal>
<street>170 West Tasman Drive</street>
<street>San Jose</street>
<street>CA  95134-1706</street>
<country>US</country>
</postal>

<phone>+1 408 526 5260</phone>
<email>kzm@cisco.com</email>
</address>
</author>

<date year="1996" month="November" />
<area>Transport</area>
<area>Management</area>
<keyword>Management Information Base</keyword>
<keyword>datagram</keyword>
<keyword>simple network management protocol version 2</keyword>
<keyword>structure of management information version 2</keyword>
<keyword>user datagram protocol</keyword>

<note title="IESG Note">
<t>
   The IP, UDP, and TCP MIB modules currently support only IPv4.  These
   three modules use the IpAddress type defined as an OCTET STRING of
   length 4 to represent the IPv4 32-bit internet addresses.  (See RFC
   1902, SMI for SNMPv2.)  They do not support the new 128-bit IPv6
   internet addresses.
</t>
</note>
</front>

<seriesInfo value="2013" name="RFC" />
<format octets="21225" type="HTML" target="http://xml.resource.org/public/rfc/html/rfc2013.html" />
<format octets="10278" type="XML" target="http://xml.resource.org/public/rfc/xml/rfc2013.xml" />
</reference>


<reference target2="reference.RFC.2014.xml" anchor="RFC2014">
<front>
<title abbrev="IRTF Research Group Guidelines">IRTF Research Group Guidelines and Procedures</title>
<author fullname="Abel Weinrib" initials="A." surname="Weinrib">
<organization>Intel Corporation, MS JF2-74</organization>

<address>
<postal>
<street>2111 NE 25th Ave.</street>
<street>Hillsboro</street>
<street>OR 97124</street>
</postal>

<phone>503-264-8972</phone>
<email>weinrib@intel.com</email>
</address>
</author>

<author fullname="Jon Postel" initials="J." surname="Postel">
<organization>USC - ISI, Suite 1001</organization>

<address>
<postal>
<street>4676 Admiralty Way</street>
<street>Marina del Rey</street>
<street>CA  90292-6695</street>
</postal>

<phone>310-822-1511</phone>
<email>postel@isi.edu</email>
</address>
</author>

<date year="1996" month="October" />
<area>General</area>
<keyword>Internet Architecture Board</keyword>
<keyword>Internet Research Task Force</keyword>

<abstract>
<t>
   The Internet Research Task Force (IRTF) has responsibility for
   organizing groups to investigate research topics related to the
   Internet protocols, applications, and technology. IRTF activities are
   organized into Research Groups.  This document describes the
   guidelines and procedures for formation and operation of IRTF
   Research Groups.  It describes the relationship between IRTF
   participants, Research Groups, the Internet Research Steering Group
   (IRSG) and the Internet Architecture Board (IAB).  The basic duties
   of IRTF participants, including the IRTF Chair, Research Group Chairs
   and IRSG members are defined.
</t>
</abstract>
</front>

<seriesInfo value="8" name="BCP" />
<seriesInfo value="2014" name="RFC" />
<format octets="42269" type="HTML" target="http://xml.resource.org/public/rfc/html/rfc2014.html" />
<format octets="29665" type="XML" target="http://xml.resource.org/public/rfc/xml/rfc2014.xml" />
</reference>


<reference target2="reference.RFC.2015.xml" anchor="RFC2015">
<front>
<title abbrev="MIME Security with PGP">MIME Security with Pretty Good Privacy (PGP)</title>
<author fullname="Michael Elkins" initials="M." surname="Elkins">
<organization>P.O. Box 92957 - M1/102</organization>

<address>
<postal>
<street>Los Angeles</street>
<street>CA 90009-2957</street>
</postal>

<phone>+1 310 336 8040</phone>
<facsimile>+1 310 336 4402</facsimile>
</address>
</author>

<date year="1996" month="October" />
<area>Security</area>
<area>Applications</area>
<keyword>authentication</keyword>
<keyword>content-type</keyword>
<keyword>multipurpose internet mail extensions</keyword>
<keyword>pretty good privacy</keyword>
<keyword>security</keyword>

<abstract>
<t>
   This document describes how Pretty Good Privacy (PGP) can be used to
   provide privacy and authentication using the Multipurpose Internet
   Mail Extensions (MIME) security content types described in RFC1847.
</t>
</abstract>
</front>

<seriesInfo value="2015" name="RFC" />
<format octets="28665" type="HTML" target="http://xml.resource.org/public/rfc/html/rfc2015.html" />
<format octets="16854" type="XML" target="http://xml.resource.org/public/rfc/xml/rfc2015.xml" />
</reference>


<reference target2="reference.RFC.2016.xml" anchor="RFC2016">
<front>
<title abbrev="Uniform Resource Agents">Uniform Resource Agents (URAs)</title>
<author fullname="Leslie Daigle" initials="L." surname="Daigle">
<organization>Peter Deutsch</organization>

<address>
<postal>
<street>Bill Heelan</street>
<street>Chris Alpaugh</street>
<street>Mary Maclachlan</street>
</postal>

<phone>(514) 875-8611</phone>
<email>ura-bunyip@bunyip.com</email>
</address>
</author>

<date year="1996" month="October" />
<area>Applications</area>
<keyword>agent</keyword>
<keyword>encapsulate</keyword>
<keyword>uniform resource</keyword>
<keyword>uniform resource agent</keyword>

<abstract>
<t>
   This paper presents an experimental architecture for an agent system
   that provides sophisticated Internet information access and
   management.  Not a generalized architecture for active objects that
   roam the Internet, these agents are modeled as extensions of existing
   pieces of the Internet information infrastructure.  This experimental
   agent technology focuses on the necessary information structures to
   encapsulate Internet activities into objects that can be activated,
   transformed, and combined into larger structured activities.
</t>
</abstract>
</front>

<seriesInfo value="2016" name="RFC" />
<format octets="50627" type="HTML" target="http://xml.resource.org/public/rfc/html/rfc2016.html" />
<format octets="39667" type="XML" target="http://xml.resource.org/public/rfc/xml/rfc2016.xml" />
</reference>


<reference target2="reference.RFC.2017.xml" anchor="RFC2017">
<front>
<title abbrev="URL Access-Type">Definition of the URL MIME External-Body Access-Type</title>
<author fullname="Ned Freed" initials="N." surname="Freed">
<organization>Innosoft International, Inc.</organization>

<address>
<postal>
<street>1050 East Garvey Avenue South</street>
<street>West Covina</street>
<street>CA 91790</street>
<country>USA</country>
</postal>

<phone>+1 818 919 3600</phone>
<facsimile>+1 818 919 3614</facsimile>
<email>ned@innosoft.com</email>
</address>
</author>

<author fullname="Keith Moore" initials="K." surname="Moore">
<organization>Computer Science Dept.</organization>

<address>
<postal>
<street>University of Tennessee</street>
<street>107 Ayres Hall</street>
<street>Knoxville</street>
<street>TN 37996-1301</street>
<country>USA</country>
</postal>

<email>moore@cs.utk.edu</email>
</address>
</author>

<date year="1996" month="October" />
<area>Applications</area>
<keyword>multipurpose internet mail extensions</keyword>
<keyword>MIME</keyword>
<keyword>uniform resource</keyword>
</front>

<seriesInfo value="2017" name="RFC" />
<format octets="20691" type="HTML" target="http://xml.resource.org/public/rfc/html/rfc2017.html" />
<format octets="9177" type="XML" target="http://xml.resource.org/public/rfc/xml/rfc2017.xml" />
</reference>


<reference target2="reference.RFC.2018.xml" anchor="RFC2018">
<front>
<title abbrev="TCP Selective Acknowledgement Options">TCP Selective Acknowledgment Options</title>
<author fullname="Matt Mathis" initials="M." surname="Mathis">
<organization>Pittsburgh Supercomputing Center</organization>

<address>
<postal>
<street>4400 Fifth Ave</street>
<street>Pittsburgh</street>
<street>PA 15213</street>
</postal>

<email>mathis@psc.edu</email>
</address>
</author>

<author fullname="Jamshid Mahdavi" initials="J." surname="Mahdavi">
<organization>Pittsburgh Supercomputing Center</organization>

<address>
<postal>
<street>4400 Fifth Ave</street>
<street>Pittsburgh</street>
<street>PA 15213</street>
</postal>

<email>mahdavi@psc.edu</email>
</address>
</author>

<author fullname="Sally Floyd" initials="S." surname="Floyd">
<organization>Lawrence Berkeley National Laboratory</organization>

<address>
<postal>
<street>One Cyclotron Road</street>
<street>Berkeley</street>
<street>CA 94720</street>
</postal>

<email>floyd@ee.lbl.gov</email>
</address>
</author>

<author fullname="Allyn Romanow" initials="A." surname="Romanow">
<organization>Sun Microsystems, Inc.</organization>

<address>
<postal>
<street>2550 Garcia Ave.</street>
<street>MPK17-202</street>
<street>Mountain View</street>
<street>CA 94043</street>
</postal>

<email>allyn@eng.sun.com</email>
</address>
</author>

<date year="1996" month="October" />
<area>Transport</area>
<keyword>TCP</keyword>
<keyword>acknowledgement</keyword>
<keyword>transmission control protocol</keyword>

<abstract>
<t>
   TCP may experience poor performance when multiple packets are lost
   from one window of data.   With the limited information available
   from cumulative acknowledgments, a TCP sender can only learn about a
   single lost packet per round trip time.  An aggressive sender could
   choose to retransmit packets early, but such retransmitted segments
   may have already been successfully received.
</t>

<t>
   A Selective Acknowledgment (SACK) mechanism, combined with a
   selective repeat retransmission policy, can help to overcome these
   limitations.  The receiving TCP sends back SACK packets to the sender
   informing the sender of data that has been received. The sender can
   then retransmit only the missing data segments.
</t>

<t>
   This memo proposes an implementation of SACK and discusses its
   performance and related issues.
</t>
</abstract>
</front>

<seriesInfo value="2018" name="RFC" />
<format octets="43791" type="HTML" target="http://xml.resource.org/public/rfc/html/rfc2018.html" />
<format octets="30132" type="XML" target="http://xml.resource.org/public/rfc/xml/rfc2018.xml" />
</reference>


<reference target2="reference.RFC.2019.xml" anchor="RFC2019">
<front>
<title abbrev="Transmission of IPv6 Packets Over FDDI">A Method for the Transmission of IPv6 Packets over FDDI Networks</title>
<author fullname="Matt Crawford" initials="M." surname="Crawford">
<organization>Fermilab MS 368</organization>

<address>
<postal>
<street>PO Box 500</street>
<street>Batavia</street>
<street>IL 60510</street>
<country>USA</country>
</postal>

<phone>+1 708 840-3461</phone>
<email>crawdad@fnal.gov</email>
</address>
</author>

<date year="1996" month="October" />
<area>Internet</area>
<keyword>FDDI</keyword>
<keyword>Fiber Distributed Data Interface</keyword>
<keyword>internet protocol version 6</keyword>
</front>

<seriesInfo value="2019" name="RFC" />
<format octets="24626" type="HTML" target="http://xml.resource.org/public/rfc/html/rfc2019.html" />
<format octets="13310" type="XML" target="http://xml.resource.org/public/rfc/xml/rfc2019.xml" />
</reference>


<reference target2="reference.RFC.2020.xml" anchor="RFC2020">
<front>
<title abbrev="IEEE 802.12 Interface MIB">IEEE 802.12 Interface MIB</title>
<author fullname="John Flick" initials="J." surname="Flick">
<organization>Hewlett Packard Company</organization>

<address>
<postal>
<street>8000 Foothills Blvd. M/S 5556</street>
<city>Roseville</city>
<region>CA</region>
<code>95747-5556</code>
<country>US</country>
</postal>

<phone>+1 916 785 4018</phone>
<email>johnf@hprnd.rose.hp.com</email>
</address>
</author>

<date year="1996" month="October" />

<abstract>
<t></t>
</abstract>
</front>

<seriesInfo value="2020" name="RFC" />
</reference>


<reference target2="reference.RFC.2021.xml" anchor="RFC2021">
<front>
<title abbrev="Remote Network Monitoring MIB">Remote Network Monitoring Management Information Base Version 2 using SMIv2</title>
<author fullname="Steven Waldbusser" initials="S." surname="Waldbusser">
<organization>International Network Services</organization>

<address>
<phone>+1 415 254 4251</phone>
<email>waldbusser@ins.com</email>
</address>
</author>

<date year="1997" month="January" />

<abstract>
<t>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 remote network monitoring devices.</t>
</abstract>
</front>

<seriesInfo value="2021" name="RFC" />
</reference>


<reference target2="reference.RFC.2022.xml" anchor="RFC2022">
<front>
<title abbrev="Multicast over UNI 3.0/3.1 based ATM">Support for Multicast over UNI 3.0/3.1 based ATM Networks</title>
<author fullname="Grenville Armitage" initials="G." surname="Armitage">
<organization>Bellcore</organization>

<address>
<postal>
<street>445 South Street</street>
<city>Morristown</city>
<region>NJ</region>
<code>07960</code>
<country>US</country>
</postal>

<phone>+1 201 829 2635</phone>
<email>gja@thumper.bellcore.com</email>
</address>
</author>

<date year="1996" month="November" />

<abstract>
<t>Mapping the connectionless IP multicast service over the connection oriented ATM services provided by UNI 3.0/3.1 is a non-trivial task. This memo describes a mechanism to support the multicast needs of Layer 3 protocols in general, and describes its application to IP multicasting in particular.</t>

<t>ATM based IP hosts and routers use a Multicast Address Resolution Server (MARS) to support RFC 1112 style Level 2 IP multicast over the ATM Forum's UNI 3.0/3.1 point to multipoint connection service.  Clusters of endpoints share a MARS and use it to track and disseminate information identifying the nodes listed as receivers for given multicast groups. This allows endpoints to establish and manage point to multipoint VCs when transmitting to the group.</t>

<t>The MARS behaviour allows Layer 3 multicasting to be supported using either meshes of VCs or ATM level multicast servers. This choice may be made on a per-group basis, and is transparent to the endpoints.</t>
</abstract>
</front>

<seriesInfo value="2022" name="RFC" />
</reference>


<reference target2="reference.RFC.2023.xml" anchor="RFC2023">
<front>
<title>IP Version 6 over PPP</title>
<author fullname="Dimitry Haskin" initials="D." surname="Haskin">
<organization>Bay Networks, Inc.</organization>

<address>
<postal>
<street>2 Federal Street</street>
<city>Billerica</city>
<region>MA</region>
<code>01821</code>
<country>US</country>
</postal>

<email>dhaskin@baynetworks.com</email>
</address>
</author>

<author fullname="Ed Allen" initials="E." surname="Allen">
<organization>Bay Networks, Inc.</organization>

<address>
<postal>
<street>2 Federal Street</street>
<city>Billerica</city>
<region>MA</region>
<code>01821</code>
<country>US</country>
</postal>

<email>eallen@baynetworks.com</email>
</address>
</author>

<date year="1996" month="October" />

<abstract>
<t>The Point-to-Point Protocol (PPP)provides a standard method of encapsulating Network Layer protocol information over point-to-point links.  PPP also defines an extensible Link Control Protocol, and proposes a family of Network Control Protocols (NCPs) for establishing and configuring different network-layer protocols.</t>

<t>This document defines the method for transmission of IP Version 6packets over PPP links as well as the Network Control Protocol (NCP) for establishing and configuring the IPv6 over PPP. It also specifies the method of forming IPv6 link-local addresses on PPP links.</t>
</abstract>
</front>

<seriesInfo value="2023" name="RFC" />
</reference>


<reference target2="reference.RFC.2024.xml" anchor="RFC2024">
<front>
<title abbrev="DLSw MIB using SMIv2">Definitions of Managed Objects for Data Link Switching using SMIv2</title>
<author fullname="David D. Chen" initials="D.D." surname="Chen">
<organization>IBM Networking Systems</organization>

<address>
<postal>
<street>P. O. Box 12195</street>
<city>Research Triangle Park</city>
<region>NC</region>
<code>27709</code>
<country>US</country>
</postal>

<phone>+1 919 254 6182</phone>
<email>dchen@vnet.ibm.com</email>
</address>
</author>

<author fullname="Peter W. Gayek" initials="P.W." surname="Gayek">
<organization>IBM Networking Systems</organization>

<address>
<postal>
<street>P. O. Box 12195</street>
<city>Research Triangle Park</city>
<region>NC</region>
<code>27709</code>
<country>US</country>
</postal>

<phone>+1 919 254 1808</phone>
<email>gayek@vnet.ibm.com</email>
</address>
</author>

<author fullname="Shannon Nix" initials="S." surname="Nix">
<organization>Metaplex, Inc.</organization>

<address>
<postal>
<street>7025 Kit Creek Road</street>
<street>P. O. Box 14987</street>
<city>Research Triangle Park</city>
<region>NC</region>
<code>27709</code>
<country>US</country>
</postal>

<phone>+1 919 472 2388</phone>
<email>snix@metaplex.com</email>
</address>
</author>

<date year="1996" month="October" />

<abstract>
<t>This specification defines an extension to the Management Information Base (MIB) for use with SNMP-based network management.  In particular, it defines objects for configuring, monitoring, and controlling Data Link Switches (DLSw).</t>

<t>This memo specifies a MIB module in a manner that is both compliant to the SNMPv2 SMI, and semantically identical to the SNMPv1 definitions.</t>
</abstract>
</front>

<seriesInfo value="2024" name="RFC" />
</reference>


<reference target2="reference.RFC.2025.xml" anchor="RFC2025">
<front>
<title abbrev="SPKM">The Simple Public-Key GSS-API Mechanism (SPKM)</title>
<author fullname="Carlisle Adams" initials="C." surname="Adams">
<organization>Bell-Northern Research</organization>

<address>
<postal>
<street>P.O.Box 3511</street>
<street>Station C</street>
<city>Ottawa</city>
<region>Ontario</region>
<code>K1Y 4H7</code>
<country>CA</country>
</postal>

<phone>+1 613 763 9008</phone>
<email>cadams@bnr.ca</email>
</address>
</author>

<date year="1996" month="October" />

<abstract>
<t>This specification defines protocols, procedures, and conventions to be employed by peers implementing the Generic Security Service  Application Program Interface (as specified in RFCs 1508 and 1509) when using the Simple Public-Key Mechanism.</t>
</abstract>
</front>

<seriesInfo value="2025" name="RFC" />
</reference>


<reference target2="reference.RFC.2026.xml" anchor="RFC2026">
<front>
<title abbrev="Internet Standards Process">The Internet Standards Process -- Revision 3</title>
<author fullname="Scott O. Bradner" initials="S." surname="Bradner">
<organization>Harvard University</organization>

<address>
<postal>
<street>1350 Mass. Ave.</street>
<city>Cambridge</city>
<region>MA</region>
<code>02138</code>
<country>US</country>
</postal>

<phone>+1 617 495 3864</phone>
<email>sob@harvard.edu</email>
</address>
</author>

<date year="1996" month="October" />

<abstract>
<t>This memo documents the process used by the Internet community for the standardization of protocols and procedures.  It defines the stages in the standardization process, the requirements for moving a document between stages and the types of documents used during this process.  It also addresses the intellectual property rights and copyright issues associated with the standards process.</t>
</abstract>
</front>

<seriesInfo value="9" name="BCP" />
<seriesInfo value="2026" name="RFC" />
</reference>


<reference target2="reference.RFC.2027.xml" anchor="RFC2027">
<front>
<title abbrev="IAB and IESG Selection">IAB and IESG Selection, Confirmation, and Recall Process: Operation of the Nominating and Recall Committees</title>
<author fullname="James M. Galvin" initials="J.M." surname="Galvin">
<organization>CommerceNet</organization>

<address>
<postal>
<street>P.O. Box 220</street>
<street>Glenwood</street>
<street>MD 21738</street>
</postal>

<phone>+1 410.795.6882</phone>
<email>galvin@commerce.net</email>
</address>
</author>

<date year="1996" month="October" />
<area>General</area>
<keyword>Internet Architecture Board</keyword>
<keyword>Internet Engineering Steering Group</keyword>

<abstract>
<t>
   The process by which the members of the IAB and IESG are selected,
   confirmed, and recalled has been exercised four times since its
   formal creation.  The evolution of the process has relied principally
   on oral tradition as a means by which the lessons learned could be
   passed on to successive committees.  This document is a self-
   consistent, organized compilation of the process as it is known
   today.
</t>
</abstract>
</front>

<seriesInfo value="10" name="BCP" />
<seriesInfo value="2027" name="RFC" />
<format octets="33846" type="HTML" target="http://xml.resource.org/public/rfc/html/rfc2027.html" />
<format octets="24437" type="XML" target="http://xml.resource.org/public/rfc/xml/rfc2027.xml" />
</reference>


<reference target2="reference.RFC.2028.xml" anchor="RFC2028">
<front>
<title abbrev="IETF Organizations">The Organizations Involved in the IETF Standards Process</title>
<author fullname="Richard Hovey" initials="R." surname="Hovey">
<organization>Digital Equipment Corporation</organization>

<address>
<postal>
<street>1401 H Street NW</street>
<street>Washington DC 20005</street>
</postal>

<phone>+1 202 383 5615</phone>
<email>hovey@wnpv01.enet.dec.com</email>
</address>
</author>

<author fullname="Scott Bradner" initials="S." surname="Bradner">
<organization>Harvard University</organization>

<address>
<postal>
<street>1350 Mass Ave. Rm 813</street>
<street>Cambridge MA 02138</street>
</postal>

<phone>+1 617 495 3864</phone>
<email>sob@harvard.edu</email>
</address>
</author>

<date year="1996" month="October" />
<area>General</area>
<keyword>Internet Engineering Task Force</keyword>
<keyword>standards process</keyword>

<abstract>
<t>
   This document describes the individuals and organizations involved in
   the IETF.  This includes descriptions of the IESG, the IETF Working
   Groups and the relationship between the IETF and the Internet
   Society.
</t>
</abstract>
</front>

<seriesInfo value="11" name="BCP" />
<seriesInfo value="2028" name="RFC" />
<format octets="29364" type="HTML" target="http://xml.resource.org/public/rfc/html/rfc2028.html" />
<format octets="17066" type="XML" target="http://xml.resource.org/public/rfc/xml/rfc2028.xml" />
</reference>


<reference target2="reference.RFC.2029.xml" anchor="RFC2029">
<front>
<title abbrev="RTP Payload Format">RTP Payload Format of Sun&apos;s CellB Video Encoding</title>
<author fullname="Michael F. Speer" initials="M.F." surname="Speer">
<organization>Sun Microsystems Computer Corporation</organization>

<address>
<postal>
<street>2550 Garcia Ave MailStop UMPK14-305</street>
<street>Mountain View</street>
<street>CA 94043</street>
</postal>

<facsimile>+1 415 786 6445</facsimile>
<email>michael.speer@eng.sun.com</email>
</address>
</author>

<author fullname="Don Hoffman" initials="D." surname="Hoffman">
<organization>Sun Microsystems Computer Corporation</organization>

<address>
<postal>
<street>2550 Garcia Ave MailStop UMPK14-305</street>
<street>Mountain View</street>
<street>CA 94043</street>
</postal>

<facsimile>+1 415 786 6445</facsimile>
<email>don.hoffman@eng.sun.com</email>
</address>
</author>

<date year="1996" month="October" />
<area>Transport</area>
<keyword>RTP</keyword>
<keyword>multimedia</keyword>
<keyword>real-time transport protocol</keyword>
<keyword>video</keyword>

<abstract>
<t>
   This memo describes a packetization scheme for the CellB video
   encoding. The scheme proposed allows applications to transport CellB
   video flows over protocols used by RTP.  This document is meant for
   implementors of video applications that want to use RTP and CellB.
</t>
</abstract>
</front>

<seriesInfo value="2029" name="RFC" />
<format octets="24598" type="HTML" target="http://xml.resource.org/public/rfc/html/rfc2029.html" />
<format octets="13819" type="XML" target="http://xml.resource.org/public/rfc/xml/rfc2029.xml" />
</reference>


<reference target2="reference.RFC.2030.xml" anchor="RFC2030">
<front>
<title abbrev="SNTPv4 for IPv4, IPv6 and OSI">Simple Network Time Protocol (SNTP) Version 4 for IPv4, IPv6 and OSI</title>
<author fullname="David L. Mills" initials="D." surname="Mills">
<organization>University of Delaware, Electrical Engineering Department</organization>

<address>
<postal>
<street />
<city>Newark</city>
<region>DE</region>
<code>19716</code>
<country>US</country>
</postal>

<phone>+1 302 831 8247</phone>
</address>
</author>

<date year="1996" month="October" />

<abstract>
<t>This memorandum describes the Simple Network Time Protocol (SNTP) Version 4, which is an adaptation of the Network Time Protocol (NTP) used to synchronize computer clocks in the Internet. SNTP can be used when the ultimate performance of the full NTP implementation described in RFC-1305 is not needed or justified. When operating with current and previous NTP and SNTP versions, SNTP Version 4 involves no changes to the NTP specification or known implementations, but rather a clarification of certain design features of NTP which allow operation in a simple, stateless remote-procedure call (RPC) mode with accuracy and reliability expectations similar to the UDP/TIME protocol described in RFC-868.</t>

<t>The only significant protocol change in SNTP Version 4 over previous versions of NTP and SNTP is a modified header interpretation to accommodate Internet Protocol Version 6 (IPv6)and OSIaddressing. However, SNTP Version 4 includes certain optional extensions to the basic Version 3 model, including an anycast mode and an authentication scheme designed specifically for multicast and anycast modes. While the anycast mode extension is described in this document, the authentication scheme extension will be described in another document to be published later. Until such time that a definitive specification is published, these extensions should be considered provisional.</t>

<t>This memorandum obsoletes RFC-1769, which describes SNTP Version 3. Its purpose is to correct certain inconsistencies in the previous document and to clarify header formats and protocol operations for current NTP Version 3 (IPv4) and proposed NTP Version 4 (IPv6 and OSI), which are also used for SNTP. A working knowledge of the NTP Version 3  specification RFC-1305 is not required for an implementation of SNTP.</t>
</abstract>
</front>

<seriesInfo value="2030" name="RFC" />
</reference>


<reference target2="reference.RFC.2031.xml" anchor="RFC2031">
<front>
<title abbrev="IETF-ISOC Relationship">IETF-ISOC relationship</title>
<author fullname="Erik Huizer" initials="E." surname="Huizer">
<organization>SURFnet ExpertiseCentrum bv</organization>

<address>
<postal>
<street>P.O. Box 19115</street>
<street>3501 DC  Utrecht</street>
<street>The</street>
<country>Netherlands</country>
</postal>

<phone>+31 302 305 305</phone>
<facsimile>+31 302 305 329</facsimile>
<email>Erik.Huizer@sec.nl</email>
</address>
</author>

<date year="1996" month="October" />
<area>General</area>
<keyword>Internet Engineering Task Force</keyword>
<keyword>Internet Society</keyword>

<abstract>
<t>
   This memo summarises the issues on IETF - ISOC relationships as the
   have been discussed by the Poised Working Group. The purpose of the
   document is to gauge consensus on these issues. And to allow further
   discussions where necessary.
</t>
</abstract>
</front>

<seriesInfo value="2031" name="RFC" />
<format octets="14131" type="HTML" target="http://xml.resource.org/public/rfc/html/rfc2031.html" />
<format octets="6214" type="XML" target="http://xml.resource.org/public/rfc/xml/rfc2031.xml" />
</reference>


<reference target2="reference.RFC.2032.xml" anchor="RFC2032">
<front>
<title abbrev="RTP Payload Format for H.261 Video">RTP Payload Format for H.261 Video Streams</title>
<author fullname="Thierry Turletti" initials="T." surname="Turletti">
<organization>INRIA - RODEO Project</organization>

<address>
<postal>
<street>2004 route des Lucioles</street>
<street>BP 93</street>
<street>06902 Sophia Antipolis</street>
<country>FRANCE</country>
</postal>

<email>huitema@bellcore.com</email>
<uri>etti@sophia.inria.fr</uri>
</address>
</author>

<date year="1996" month="October" />
<area>Transport</area>
<keyword>RTP</keyword>
<keyword>multimedia</keyword>
<keyword>real-time transport protocol</keyword>
<keyword>video</keyword>
</front>

<seriesInfo value="2032" name="RFC" />
<format octets="42473" type="HTML" target="http://xml.resource.org/public/rfc/html/rfc2032.html" />
<format octets="28699" type="XML" target="http://xml.resource.org/public/rfc/xml/rfc2032.xml" />
</reference>


<reference target2="reference.RFC.2033.xml" anchor="RFC2033">
<front>
<title abbrev="Local Mail">Local Mail Transfer Protocol</title>
<author fullname="John G. Myers" initials="J.G." surname="Myers">
<organization>Carnegie-Mellon University</organization>

<address>
<postal>
<street>5000 Forbes Ave.</street>
<street>Pittsburgh</street>
<street>15213-3890</street>
<country>PA</country>
</postal>

<email>jgm+@cmu.edu</email>
</address>
</author>

<date year="1996" month="October" />
<area>Applications</area>
<keyword>mail</keyword>
</front>

<seriesInfo value="2033" name="RFC" />
<format octets="27748" type="HTML" target="http://xml.resource.org/public/rfc/html/rfc2033.html" />
<format octets="17426" type="XML" target="http://xml.resource.org/public/rfc/xml/rfc2033.xml" />
</reference>


<reference target2="reference.RFC.2034.xml" anchor="RFC2034">
<front>
<title abbrev="SMTP Enhanced Error Codes">SMTP Service Extension for Returning Enhanced Error Codes</title>
<author fullname="Ned Freed" initials="N." surname="Freed">
<organization>Innosoft International, Inc.</organization>

<address>
<postal>
<street>1050 East Garvey Avenue South</street>
<street>West Covina</street>
<street>CA 91790</street>
<country>USA</country>
</postal>

<phone>+1 818 919 3600           fax: +1 818 919 3614</phone>
<email>ned@innosoft.com</email>
</address>
</author>

<date year="1996" month="October" />
<area>Applications</area>
<keyword>SMTP</keyword>
<keyword>point-to-point protocol</keyword>
<keyword>simple mail transfer protocol</keyword>
</front>

<seriesInfo value="2034" name="RFC" />
<format octets="21966" type="HTML" target="http://xml.resource.org/public/rfc/html/rfc2034.html" />
<format octets="10728" type="XML" target="http://xml.resource.org/public/rfc/xml/rfc2034.xml" />
</reference>


<reference target2="reference.RFC.2035.xml" anchor="RFC2035">
<front>
<title abbrev="RTP Payload Format for JPEG Video">RTP Payload Format for JPEG-compressed Video</title>
<author fullname="Lance M. Berc" initials="L.M." surname="Berc">
<organization>Systems Research Center</organization>

<address>
<postal>
<street>Digital Equipment Corporation</street>
<street>130 Lytton Ave</street>
<street>Palo Alto CA 94301</street>
</postal>

<phone>+1 415 853 2100</phone>
<email>berc@pa.dec.com</email>
</address>
</author>

<author fullname="William C. Fenner" initials="W.C." surname="Fenner">
<organization>Xerox PARC</organization>

<address>
<postal>
<street>3333 Coyote Hill Road</street>
<street>Palo Alto</street>
<street>CA 94304</street>
</postal>

<phone>+1 415 812 4816</phone>
<email>fenner@cmf.nrl.navy.mil</email>
</address>
</author>

<author fullname="Ron Frederick" initials="R." surname="Frederick">
<organization>Xerox PARC</organization>

<address>
<postal>
<street>3333 Coyote Hill Road</street>
<street>Palo Alto</street>
<street>CA 94304</street>
</postal>

<phone>+1 415 812 4459</phone>
<email>frederick@parc.xerox.com</email>
</address>
</author>

<author fullname="Steven McCanne" initials="S." surname="McCanne">
<organization>Lawrence Berkeley Laboratory</organization>

<address>
<postal>
<street>M/S 46A-1123</street>
<street>One Cyclotron Road</street>
<street>Berkeley</street>
<street>CA 94720</street>
</postal>

<phone>+1 510 486 7520</phone>
<email>mccanne@ee.lbl.gov</email>
</address>
</author>

<date year="1996" month="October" />
<area>Transport</area>
<keyword>compress</keyword>
<keyword>joint photographic experts group</keyword>
<keyword>multimedia</keyword>
<keyword>real-time transport protocol</keyword>
<keyword>video</keyword>

<abstract>
<t>
   This memo describes the RTP payload format for JPEG video streams.
   The packet format is optimized for real-time video streams where
   codec parameters change rarely from frame to frame.
</t>

<t>
   This document is a product of the Audio-Video Transport working group
   within the Internet Engineering Task Force.  Comments are solicited
   and should be addressed to the working group&apos;s mailing list at rem-
   conf@es.net and/or the author(s).
</t>
</abstract>
</front>

<seriesInfo value="2035" name="RFC" />
<format octets="46886" type="HTML" target="http://xml.resource.org/public/rfc/html/rfc2035.html" />
<format octets="32114" type="XML" target="http://xml.resource.org/public/rfc/xml/rfc2035.xml" />
</reference>


<reference target2="reference.RFC.2036.xml" anchor="RFC2036">
<front>
<title abbrev="Components of the Class A Address Space">Observations on the use of Components of the Class A Address Space within the Internet</title>
<author fullname="Geoff Huston" initials="G." surname="Huston">
<organization />

<address>
<postal>
<street>Locked Bag 5744</street>
<street>Canberra  ACT  2601</street>
<country>Australia</country>
</postal>

<phone>+61 6 208 1908</phone>
<email>gih@telstra.net</email>
</address>
</author>

<date year="1996" month="October" />
<area>Internet</area>
<keyword>IP address</keyword>
<keyword>classless inter-domain routing</keyword>

<abstract>
<t>
   This document is a commentary on the recommendation that IANA
   commence allocation of the presently unallocated components of the
   Class A address space to registries, for deployment within the
   Internet as class-less address blocks.
</t>

<t>
   The document examines the implications for service providers and end
   clients within this environment. The document notes the major
   conclusion that widespread adoption of class-less routing protocols
   is required, within a relatively rapid timeframe for this
   recommendation to be effective.
</t>
</abstract>
</front>

<seriesInfo value="2036" name="RFC" />
<format octets="28374" type="HTML" target="http://xml.resource.org/public/rfc/html/rfc2036.html" />
<format octets="18897" type="XML" target="http://xml.resource.org/public/rfc/xml/rfc2036.xml" />
</reference>


<reference target2="reference.RFC.2037.xml" anchor="RFC2037">
<front>
<title>Entity MIB using SMIv2</title>
<author fullname="Keith McCloghrie" initials="K." surname="McCloghrie">
<organization>Cisco Systems, Inc.</organization>

<address>
<postal>
<street>170 West Tasman Drive</street>
<street>San Jose</street>
<street>CA 95134</street>
</postal>

<phone>408-526-5260</phone>
<email>kzm@cisco.com</email>
</address>
</author>

<author fullname="Andy Bierman" initials="A." surname="Bierman">
<organization>Cisco Systems, Inc.</organization>

<address>
<postal>
<street>170 West Tasman Drive</street>
<street>San Jose</street>
<street>CA 95134</street>
</postal>

<phone>408-527-3711</phone>
<email>abierman@cisco.com</email>
</address>
</author>

<date year="1996" month="October" />
<area>Management</area>
<keyword>Management Information Base</keyword>
<keyword>structure of management information version 2</keyword>
</front>

<seriesInfo value="2037" name="RFC" />
<format octets="89223" type="HTML" target="http://xml.resource.org/public/rfc/html/rfc2037.html" />
<format octets="74689" type="XML" target="http://xml.resource.org/public/rfc/xml/rfc2037.xml" />
</reference>


<reference target2="reference.RFC.2038.xml" anchor="RFC2038">
<front>
<title abbrev="MPEG RTP Payload">RTP Payload Format for MPEG1/MPEG2 Video</title>
<author fullname="Don Hoffman" initials="D." surname="Hoffman">
<organization>Sun Microsystems, Inc.</organization>

<address>
<postal>
<street>Mail-stop UMPK14-305</street>
<street>2550 Garcia Avenue</street>
<street>Mountain View</street>
<street>California 94043-1100</street>
<country>USA</country>
</postal>

<phone>+1 503-297-1580</phone>
<email>don.hoffman@eng.sun.com</email>
</address>
</author>

<author fullname="Gerard Fernando" initials="G." surname="Fernando">
<organization>Sun Microsystems, Inc.</organization>

<address>
<postal>
<street>Mail-stop UMPK14-305</street>
<street>2550 Garcia Avenue</street>
<street>Mountain View</street>
<street>California 94043-1100</street>
<country>USA</country>
</postal>

<phone>+1 415-786-6373</phone>
<email>gerard.fernando@eng.sun.com</email>
</address>
</author>

<author fullname="Vivek Goyal" initials="V." surname="Goyal">
<organization>Precept Software, Inc.</organization>

<address>
<postal>
<street>1072 Arastradero Rd</street>
<street>Palo Alto</street>
<street>CA 94304</street>
<country>USA</country>
</postal>

<phone>+1 415-845-5200</phone>
<email>goyal@precept.com</email>
</address>
</author>

<date year="1996" month="October" />
<area>Transport</area>
<keyword>encapsulate</keyword>
<keyword>motion picture experts group</keyword>
<keyword>multimedia</keyword>
<keyword>real-time transport protocol</keyword>
<keyword>video</keyword>

<abstract>
<t>
   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.
</t>
</abstract>
</front>

<seriesInfo value="2038" name="RFC" />
<format octets="37122" type="HTML" target="http://xml.resource.org/public/rfc/html/rfc2038.html" />
<format octets="24993" type="XML" target="http://xml.resource.org/public/rfc/xml/rfc2038.xml" />
</reference>


<reference target2="reference.RFC.2039.xml" anchor="RFC2039">
<front>
<title abbrev="WWW MIB Applicability">Applicablity of Standards Track MIBs to Management of World Wide Web Servers</title>
<author fullname="Carl W. Kalbfleisch" initials="C.W." surname="Kalbfleisch">
<organization>OnRamp Technologies, Inc.</organization>

<address>
<postal>
<street>1950 Stemmons Frwy</street>
<street>2026 INFOMART</street>
<street>Dallas</street>
<street>TX 75207</street>
<country>USA</country>
</postal>

<phone>(214) 672-7246</phone>
<email>cwk@onramp.net</email>
</address>
</author>

<date year="1996" month="November" />
<area>Management</area>
<area>Applications</area>
<keyword>Management Information Base</keyword>
<keyword>world wide web</keyword>
</front>

<seriesInfo value="2039" name="RFC" />
<format octets="46518" type="HTML" target="http://xml.resource.org/public/rfc/html/rfc2039.html" />
<format octets="34292" type="XML" target="http://xml.resource.org/public/rfc/xml/rfc2039.xml" />
</reference>


<reference target2="reference.RFC.2040.xml" anchor="RFC2040">
<front>
<title abbrev="RC5, RC5-CBC, RC5-CBC-Pad, and RC5-CTS">The RC5, RC5-CBC, RC5-CBC-Pad, and RC5-CTS Algorithms</title>
<author fullname="Robert W. Baldwin" initials="R." surname="Baldwin">
<organization>RSA Data Security, Inc.</organization>

<address>
<postal>
<street>100 Marine Parkway</street>
<city>Redwood City</city>
<region>CA</region>
<code>94065</code>
<country>US</country>
</postal>

<phone>+1 415 595 8782</phone>
<facsimile>+1 415 595 1873</facsimile>
<email>baldwin@rsa.com, or baldwin@lcs.mit.edu</email>
</address>
</author>

<author fullname="Ronald L. Rivest" initials="R." surname="Rivest">
<organization>Massachusetts Institute of Technology, Laboratory for Computer Science</organization>

<address>
<postal>
<street>545 Technology Square</street>
<street>NE43-324</street>
<city>Cambridge</city>
<region>MA</region>
<code>02139-1986</code>
<country>US</country>
</postal>

<phone>+1 617 253 5880</phone>
<email>rivest@theory.lcs.mit.edu</email>
</address>
</author>

<date year="1996" month="October" />

<abstract>
<t></t>
</abstract>
</front>

<seriesInfo value="2040" name="RFC" />
</reference>


<reference target2="reference.RFC.2041.xml" anchor="RFC2041">
<front>
<title>Mobile Network Tracing</title>
<author fullname="Brian D. Noble" initials="B." surname="Noble">
<organization>Carnegie Mellon University, Computer Science Department</organization>

<address>
<postal>
<street>5000 Forbes Avenue</street>
<city>Pittsburgh</city>
<region>PA</region>
<code>15213-3891</code>
<country>US</country>
</postal>

<phone>+1 412 268 7399</phone>
<facsimile>+1 412 268 5576</facsimile>
<email>bnoble@cs.cmu.edu</email>
</address>
</author>

<author fullname="Giao T. Nguyen" initials="G." surname="Nguyen">
<organization>University of California, Berkeley</organization>

<address>
<postal>
<street />
<city>Berkeley</city>
<region>CA</region>
<code>94720-1776</code>
<country>US</country>
</postal>

<phone>+1 510 642 8919</phone>
<facsimile>+1 510 642 5775</facsimile>
<email>gnguyen@cs.berkeley.edu</email>
</address>
</author>

<author fullname="Mahadev Satyanarayanan" initials="M." surname="Satyanarayanan">
<organization>Carnegie Mellon University, Computer Science Department</organization>

<address>
<postal>
<street>5000 Forbes Avenue</street>
<city>Pittsburgh</city>
<region>PA</region>
<code>15213-3891</code>
<country>US</country>
</postal>

<phone>+1 412 268 3743</phone>
<facsimile>+1 412 268 5576</facsimile>
<email>satya@cs.cmu.edu</email>
</address>
</author>

<author fullname="Randy H. Katz" initials="R." surname="Katz">
<organization>University of California, Berkeley</organization>

<address>
<postal>
<street />
<city>Berkeley</city>
<region>CA</region>
<code>94720-1776</code>
<country>US</country>
</postal>

<phone>+1 510 642 0253</phone>
<facsimile>+1 510 642 2845</facsimile>
<email>randy@cs.berkeley.edu</email>
</address>
</author>

<date year="1996" month="October" />

<abstract>
<t>Mobile networks are both poorly understood and difficult to experiment with.  This RFC argues that mobile network tracing provides both tools to improve our understanding of wireless channels, as well as to build realistic, repeatable testbeds for mobile software and systems.  The RFC is a status report on our work tracing mobile networks.  Our goal is to begin discussion on a standard format for mobile network tracing as well as a testbed for mobile systems research.  We present our format for collecting mobile network traces, and tools to produce from such traces analytical models of mobile network behavior.</t>

<t>We also describe a set of tools to provide network modulation based on collected traces.  Modulation allows the emulation of wireless channel latency, bandwidth, loss, and error rates on private, wired networks.  This allows system designers to test systems in a realistic yet repeatable manner.</t>
</abstract>
</front>

<seriesInfo value="2041" name="RFC" />
</reference>


<reference target2="reference.RFC.2042.xml" anchor="RFC2042">
<front>
<title abbrev="BGP Atrribute Types">Registering New BGP Attribute Types</title>
<author fullname="Bill Manning" initials="B." surname="Manning">
<organization>USC/ISI</organization>

<address>
<postal>
<street>4676 Admiralty Way</street>
<street>Marina del Rey</street>
<street>CA. 90292</street>
</postal>

<phone>01.310.822.1511</phone>
<email>bmanning@isi.edu</email>
</address>
</author>

<date year="1997" month="January" />
<keyword>border gateway protocol</keyword>
</front>

<seriesInfo value="2042" name="RFC" />
<format octets="13313" type="HTML" target="http://xml.resource.org/public/rfc/html/rfc2042.html" />
<format octets="5751" type="XML" target="http://xml.resource.org/public/rfc/xml/rfc2042.xml" />
</reference>


<reference target2="reference.RFC.2043.xml" anchor="RFC2043">
<front>
<title abbrev="SNACP">The PPP SNA Control Protocol (SNACP)</title>
<author fullname="Andrew M. Fuqua" initials="A.M." surname="Fuqua">
<organization>International Business Machines Corporation</organization>

<address>
<postal>
<street>P. O. Box 12195</street>
<street>Research Triangle Park</street>
<street>NC  27709</street>
</postal>

<email>fuqua@vnet.ibm.com</email>
</address>
</author>

<date year="1996" month="October" />
<area>Internet</area>
<keyword>IBM Systems Network Architecture</keyword>
<keyword>control protocol</keyword>
<keyword>point-to-point protocol</keyword>

<abstract>
<t>
   The Point-to-Point Protocol (PPP)  provides a standard method for
   transporting multi-protocol datagrams over point-to-point links.  PPP
   defines an extensible Link Control Protocol, and proposes a family of
   Network Control Protocols for establishing and configuring different
   network-layer protocols.
</t>

<t>
   This document defines the Network Control Protocols for establishing
   and configuring Systems Network Architecture (SNA) over PPP and SNA
   over LLC 802.2 over PPP.
</t>
</abstract>
</front>

<seriesInfo value="2043" name="RFC" />
<format octets="25581" type="HTML" target="http://xml.resource.org/public/rfc/html/rfc2043.html" />
<format octets="14545" type="XML" target="http://xml.resource.org/public/rfc/xml/rfc2043.xml" />
</reference>


<reference target2="reference.RFC.2044.xml" anchor="RFC2044">
<front>
<title abbrev="UTF-8">UTF-8, a transformation format of Unicode and ISO 10646</title>
<author fullname="Francois Yergeau" initials="F." surname="Yergeau">
<organization>Alis Technologies</organization>

<address>
<postal>
<street>100, boul. Alexis-Nihon</street>
<street>Suite 600</street>
<city>Montreal</city>
<region>Quebec</region>
<code>H4M 2P2</code>
<country>CA</country>
</postal>

<phone>+1 514 747 2547</phone>
<facsimile>+1 514 747 2561</facsimile>
<email>fyergeau@alis.com</email>
</address>
</author>

<date year="1996" month="October" />

<abstract>
<t>The Unicode Standard, version 1.1, and ISO/IEC 10646-1:1993 jointly define a 16 bit character set which encompasses most of the world's writing systems. 16-bit 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-8, the object of this memo, has the characteristic of preserving the full US-ASCII range: US-ASCII characters are encoded in one octet having the usual US-ASCII value, and any octet with such a value can only be an US-ASCII character. This provides compatibility with file systems, parsers and other software that rely on US-ASCII values but are transparent to other values.</t>
</abstract>
</front>

<seriesInfo value="2044" name="RFC" />
</reference>


<reference target2="reference.RFC.2045.xml" anchor="RFC2045">
<front>
<title abbrev="Internet Message Bodies">Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies</title>
<author fullname="Ned Freed" initials="N." surname="Freed">
<organization>Innosoft International, Inc.</organization>

<address>
<postal>
<street>1050 East Garvey Avenue South</street>
<city>West Covina</city>
<region>CA</region>
<code>91790</code>
<country>US</country>
</postal>

<phone>+1 818 919 3600</phone>
<facsimile>+1 818 919 3614</facsimile>
<email>ned@innosoft.com</email>
</address>
</author>

<author fullname="Nathaniel S. Borenstein" initials="N.S." surname="Borenstein">
<organization>First Virtual Holdings</organization>

<address>
<postal>
<street>25 Washington Avenue</street>
<city>Morristown</city>
<region>NJ</region>
<code>07960</code>
<country>US</country>
</postal>

<phone>+1 201 540 8967</phone>
<facsimile>+1 201 993 3032</facsimile>
<email>nsb@nsb.fv.com</email>
</address>
</author>

<date year="1996" month="November" />

<abstract>
<t>STD 11, RFC 822, defines a message representation protocol specifying considerable detail about US-ASCII message headers, and leaves the message content, or message body, as flat US-ASCII text.  This set of documents, collectively called the Multipurpose Internet Mail Extensions, or MIME, redefines the format of messages to allow for</t>

<t>(1)   textual message bodies in character sets other than US-ASCII,</t>

<t>(2)   an extensible set of different formats for non-textual message bodies,</t>

<t>(3)   multi-part message bodies, and</t>

<t>(4)   textual header information in character sets other than US-ASCII.</t>

<t>These documents are based on earlier work documented in RFC 934, STD 11, and RFC 1049, but extends and revises them.  Because RFC 822 said so little about message bodies, these documents are largely orthogonal to (rather than a revision of) RFC 822.</t>

<t>This initial document specifies the various headers used to describe the structure of MIME messages. The second document, RFC 2046, defines the general structure of the MIME media typing system and defines an initial set of media types. The third document, RFC 2047, describes extensions to RFC 822 to allow non-US-ASCII text data in Internet mail header fields. The fourth document, RFC 2048, specifies various IANA registration procedures for MIME-related facilities. The fifth and final document, RFC 2049, describes MIME conformance
  criteria as well as providing some illustrative examples of MIME message formats, acknowledgements, and the bibliography.</t>

<t>These documents are revisions of RFCs 1521, 1522, and 1590, which themselves were revisions of RFCs 1341 and 1342.  An appendix in RFC 2049 describes differences and changes from previous versions.</t>
</abstract>
</front>

<seriesInfo value="2045" name="RFC" />
</reference>


<reference target2="reference.RFC.2046.xml" anchor="RFC2046">
<front>
<title abbrev="Media Types">Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types</title>
<author fullname="Ned Freed" initials="N." surname="Freed">
<organization>Innosoft International, Inc.</organization>

<address>
<postal>
<street>1050 East Garvey Avenue South</street>
<city>West Covina</city>
<region>CA</region>
<code>91790</code>
<country>US</country>
</postal>

<phone>+1 818 919 3600</phone>
<facsimile>+1 818 919 3614</facsimile>
<email>ned@innosoft.com</email>
</address>
</author>

<author fullname="Nathaniel S. Borenstein" initials="N." surname="Borenstein">
<organization>First Virtual Holdings</organization>

<address>
<postal>
<street>25 Washington Avenue</street>
<city>Morristown</city>
<region>NJ</region>
<code>07960</code>
<country>US</country>
</postal>

<phone>+1 201 540 8967</phone>
<facsimile>+1 201 993 3032</facsimile>
<email>nsb@nsb.fv.com</email>
</address>
</author>

<date year="1996" month="November" />

<abstract>
<t>STD 11, RFC 822 defines a message representation protocol specifying considerable detail about US-ASCII message headers, but which leaves the message content, or message body, as flat US-ASCII text.  This set of documents, collectively called the Multipurpose Internet Mail Extensions, or MIME, redefines the format of messages to allow for</t>

<t>(1)   textual message bodies in character sets other than US-ASCII,</t>

<t>(2)   an extensible set of different formats for non-textual message bodies,</t>

<t>(3)   multi-part message bodies, and</t>

<t>(4)   textual header information in character sets other than US-ASCII.</t>

<t>These documents are based on earlier work documented in RFC 934, STD 11 and RFC 1049, but extends and revises them.  Because RFC 822 said so little about message bodies, these documents are largely orthogonal to (rather than a revision of) RFC 822.</t>

<t>The initial document in this set, RFC 2045, specifies the various headers used to describe the structure of MIME messages. This second document defines the general structure of the MIME media typing sytem and defines an initial set of media types. The third document, RFC 2047, describes extensions to RFC 822 to allow non-US-ASCII text data in Internet mail header fields. The fourth document, RFC 2048, specifies various IANA registration procedures for MIME-related facilities.  The fifth and final document, RFC 2049, describes MIME
   conformance criteria as well as providing some illustrative examples of MIME message formats, acknowledgements, and the bibliography.</t>

<t>These documents are revisions of RFCs 1521 and 1522, which themselves were revisions of RFCs 1341 and 1342.  An appendix in RFC 2049 describes differences and changes from previous versions.</t>
</abstract>
</front>

<seriesInfo value="2046" name="RFC" />
</reference>


<reference target2="reference.RFC.2047.xml" anchor="RFC2047">
<front>
<title abbrev="Message Header Extensions">MIME (Multipurpose Internet Mail Extensions) Part Three: Message Header Extensions for Non-ASCII Text</title>
<author fullname="Keith Moore" initials="K." surname="Moore">
<organization>University of Tennessee</organization>

<address>
<postal>
<street>107 Ayres Hall</street>
<street>Knoxville TN 37996-1301</street>
</postal>

<email>moore@cs.utk.edu</email>
</address>
</author>

<date year="1996" month="November" />
<area>Applications</area>
<keyword>Amercian Standard Code for Information Interchange</keyword>
<keyword>mail</keyword>
<keyword>multipurpose internet mail extensions</keyword>

<abstract>
<t>
   STD 11, RFC 822, defines a message representation protocol specifying
   considerable detail about US-ASCII message headers, and leaves the
   message content, or message body, as flat US-ASCII text.  This set of
   documents, collectively called the Multipurpose Internet Mail
   Extensions, or MIME, redefines the format of messages to allow for

<list>
<t>
   (1) textual message bodies in character sets other than US-ASCII,
</t>

<t>
   (2) an extensible set of different formats for non-textual message
       bodies,
</t>

<t>
   (3) multi-part message bodies, and
</t>

<t>
   (4) textual header information in character sets other than US-ASCII.
</t>
</list>
</t>

<t>
   These documents are based on earlier work documented in RFC 934, STD
   11, and RFC 1049, but extends and revises them.  Because RFC 822 said
   so little about message bodies, these documents are largely
   orthogonal to (rather than a revision of) RFC 822.
</t>

<t>
   This particular document is the third document in the series.  It
   describes extensions to RFC 822 to allow non-US-ASCII text data in
   Internet mail header fields.
   Other documents in this series include:

<list>
<t>
   + RFC 2045, which specifies the various headers used to describe
     the structure of MIME messages.
</t>

<t>
   + RFC 2046, which defines the general structure of the MIME media
     typing system and defines an initial set of media types,
</t>

<t>
   + RFC 2048, which specifies various IANA registration procedures
     for MIME-related facilities, and
</t>

<t>
   + RFC 2049, which describes MIME conformance criteria and
     provides some illustrative examples of MIME message formats,
     acknowledgements, and the bibliography.
</t>
</list>
</t>

<t>
   These documents are revisions of RFCs 1521, 1522, and 1590, which
   themselves were revisions of RFCs 1341 and 1342.  An appendix in RFC
   2049 describes differences and changes from previous versions.
</t>
</abstract>
</front>

<seriesInfo value="2047" name="RFC" />
<format octets="52141" type="HTML" target="http://xml.resource.org/public/rfc/html/rfc2047.html" />
<format octets="39194" type="XML" target="http://xml.resource.org/public/rfc/xml/rfc2047.xml" />
</reference>


<reference target2="reference.RFC.2048.xml" anchor="RFC2048">
<front>
<title abbrev="MIME Registration Procedures">Multipurpose Internet Mail Extensions (MIME) Part Four: Registration Procedures</title>
<author fullname="Ned Freed" initials="N." surname="Freed">
<organization>Innosoft International, Inc.</organization>

<address>
<postal>
<street>1050 East Garvey Avenue South</street>
<street>West Covina</street>
<street>CA 91790</street>
<country>USA</country>
</postal>

<phone>+1 818 919 3600</phone>
<facsimile>+1 818 919 3614</facsimile>
<email>ned@innosoft.com</email>
</address>
</author>

<author fullname="John Klensin" initials="J." surname="Klensin">
<organization>MCI</organization>

<address>
<postal>
<street>2100 Reston Parkway</street>
<street>Reston</street>
<street>VA 22091</street>
</postal>

<phone>+1 703 715-7361</phone>
<facsimile>+1 703 715-7436</facsimile>
<email>klensin@mci.net</email>
</address>
</author>

<author fullname="Jon Postel" initials="J." surname="Postel">
<organization>USC/Information Sciences Institute</organization>

<address>
<postal>
<street>4676 Admiralty Way</street>
<street>Marina del Rey</street>
<street>CA  90292</street>
<country>USA</country>
</postal>

<phone>+1 310 822 1511</phone>
<facsimile>+1 310 823 6714</facsimile>
<email>Postel@ISI.EDU</email>
</address>
</author>

<date year="1996" month="November" />
<area>Applications</area>
<keyword>mail</keyword>
<keyword>media type</keyword>
<keyword>multipurpose internet mail extensions</keyword>

<abstract>
<t>
   STD 11, RFC 822, defines a message representation protocol specifying
   considerable detail about US-ASCII message headers, and leaves the
   message content, or message body, as flat US-ASCII text.  This set of
   documents, collectively called the Multipurpose Internet Mail
   Extensions, or MIME, redefines the format of messages to allow for

<list>
<t>
    (1)   textual message bodies in character sets other than
          US-ASCII,
</t>

<t>
    (2)   an extensible set of different formats for non-textual
          message bodies,
</t>

<t>
    (3)   multi-part message bodies, and
</t>

<t>
    (4)   textual header information in character sets other than
          US-ASCII.
</t>
</list>
</t>

<t>
   These documents are based on earlier work documented in RFC 934, STD
   11, and RFC 1049, but extends and revises them.  Because RFC 822 said
   so little about message bodies, these documents are largely
   orthogonal to (rather than a revision of) RFC 822.
   This fourth document, RFC 2048, specifies various IANA registration
   procedures for the following MIME facilities:

<list>
<t>
    (1)   media types,
</t>

<t>
    (2)   external body access types,
</t>

<t>
    (3)   content-transfer-encodings.
</t>
</list>
</t>

<t>
   Registration of character sets for use in MIME is covered elsewhere
   and is no longer addressed by this document.
</t>

<t>
   These documents are revisions of RFCs 1521 and 1522, which themselves
   were revisions of RFCs 1341 and 1342.  An appendix in RFC 2049
   describes differences and changes from previous versions.
</t>
</abstract>
</front>

<seriesInfo value="13" name="BCP" />
<seriesInfo value="2048" name="RFC" />
<format octets="54732" type="HTML" target="http://xml.resource.org/public/rfc/html/rfc2048.html" />
<format octets="43342" type="XML" target="http://xml.resource.org/public/rfc/xml/rfc2048.xml" />
</reference>


<reference target2="reference.RFC.2049.xml" anchor="RFC2049">
<front>
<title abbrev="MIME Conformance">Multipurpose Internet Mail Extensions (MIME) Part Five: Conformance Criteria and Examples</title>
<author fullname="Ned Freed" initials="N." surname="Freed">
<organization>Innosoft International, Inc.</organization>

<address>
<postal>
<street>1050 East Garvey Avenue South</street>
<street>West Covina</street>
<street>CA 91790</street>
<country>USA</country>
</postal>

<phone>+1 818 919 3600</phone>
<facsimile>+1 818 919 3614</facsimile>
<email>ned@innosoft.com</email>
</address>
</author>

<author fullname="Nathaniel S. Borenstein" initials="N.S." surname="Borenstein">
<organization>First Virtual Holdings</organization>

<address>
<postal>
<street>25 Washington Avenue</street>
<street>Morristown</street>
<street>NJ 07960</street>
<country>USA</country>
</postal>

<phone>+1 201 540 8967</phone>
<facsimile>+1 201 993 3032</facsimile>
<email>nsb@nsb.fv.com</email>
</address>
</author>

<date year="1996" month="November" />
<area>Applications</area>
<keyword>mail</keyword>
<keyword>multipurpose internet mail extensions</keyword>

<abstract>
<t>
   STD 11, RFC 822, defines a message representation protocol specifying
   considerable detail about US-ASCII message headers, and leaves the
   message content, or message body, as flat US-ASCII text.  This set of
   documents, collectively called the Multipurpose Internet Mail
   Extensions, or MIME, redefines the format of messages to allow for

<list>
<t>
    (1)   textual message bodies in character sets other than
          US-ASCII,
</t>

<t>
    (2)   an extensible set of different formats for non-textual
          message bodies,
</t>

<t>
    (3)   multi-part message bodies, and
</t>

<t>
    (4)   textual header information in character sets other than
          US-ASCII.
</t>
</list>
</t>

<t>
   These documents are based on earlier work documented in RFC 934, STD
   11, and RFC 1049, but extends and revises them.  Because RFC 822 said
   so little about message bodies, these documents are largely
   orthogonal to (rather than a revision of) RFC 822.
</t>

<t>
   The initial document in this set, RFC 2045, specifies the various
   headers used to describe the structure of MIME messages. The second
   document defines the general structure of the MIME media typing
   system and defines an initial set of media types.  The third
   document, RFC 2047, describes extensions to RFC 822 to allow non-US-
   ASCII text data in Internet mail header fields. The fourth document,
   RFC 2048, specifies various IANA registration procedures for MIME-
   related facilities. This fifth and final document describes MIME
   conformance criteria as well as providing some illustrative examples
   of MIME message formats, acknowledgements, and the bibliography.
</t>

<t>
   These documents are revisions of RFCs 1521, 1522, and 1590, which
   themselves were revisions of RFCs 1341 and 1342.  Appendix B of this
   document describes differences and changes from previous versions.
</t>
</abstract>
</front>

<seriesInfo value="2049" name="RFC" />
<format octets="55000" type="HTML" target="http://xml.resource.org/public/rfc/html/rfc2049.html" />
<format octets="41896" type="XML" target="http://xml.resource.org/public/rfc/xml/rfc2049.xml" />
</reference>


<reference target2="reference.RFC.2050.xml" anchor="RFC2050">
<front>
<title abbrev="Internet Registry IP Allocation Guidelines">INTERNET REGISTRY IP ALLOCATION GUIDELINES</title>
<author fullname="Kim Hubbard" initials="K." surname="Hubbard">
<organization>InterNIC Registration Services</organization>

<address>
<postal>
<street>c/o Network Solutions</street>
<street>505 Huntmar Park Drive</street>
<street>Herndon</street>
<street>VA 22070</street>
</postal>

<phone>(703) 742-4870</phone>
<email>kimh@internic.net</email>
</address>
</author>

<author fullname="Mark Kosters" initials="M." surname="Kosters">
<organization>InterNIC Registration Services</organization>

<address>
<postal>
<street>c/o Network Solutions</street>
<street>505 Huntmar Park Drive</street>
<street>Herndon</street>
<street>VA 22070</street>
</postal>

<phone>(703) 742-4795</phone>
<email>markk@internic.net</email>
</address>
</author>

<author fullname="David Conrad" initials="D." surname="Conrad">
<organization>Asia Pacific Network Information Center</organization>

<address>
<postal>
<street>c/o United Nations University</street>
<street>53-70 Jingumae 5-chome</street>
<street>Shibuya-ku</street>
<street>Tokyo 150</street>
<country>JP</country>
</postal>

<phone>+81-3-5467-7014</phone>
<email>davidc@APNIC.NET</email>
</address>
</author>

<author fullname="Daniel Karrenberg" initials="D." surname="Karrenberg">
<organization>RIPE NCC</organization>

<address>
<postal>
<street>Kruislaan 409</street>
<street>SJ Amsterdam NL-1098</street>
<country>NL</country>
</postal>

<phone>+31 20 592 5065</phone>
<email>dfk@RIPE.NET</email>
</address>
</author>

<author fullname="Jon Postel" initials="J." surname="Postel">
<organization>USC/Information Sciences Institute</organization>

<address>
<postal>
<street>4676 Admiralty Way</street>
<street>Marina del Rey</street>
<street>CA  90292</street>
</postal>

<phone>310-822-1511</phone>
<email>Postel@ISI.EDU</email>
</address>
</author>

<date year="1996" month="November" />
<area>Routing</area>
<keyword>CIDR</keyword>
<keyword>classless inter-domain routing</keyword>

<abstract>
<t>
   By approving this document as a Best Current Practice,the IESG
   asserts its belief that this policy described herein is an accurate
   representation of the current practice of the IP address registries
   with respect to address assignment.  This does not constitute
   endorsement or recommendation of this policy by the IESG. The IESG
   will reevaluate its approval of this document in December 1997 taking
   into consideration the results of the discussions that will be take
   place in the IRE Working Group between now and then.
</t>

<t>
   This document describes the registry system for the distribution of
   globally unique Internet address space and registry operations.
   Particularly this document describes the rules and guidelines
   governing the distribution of this address space.
</t>

<t>
   This document describes the IP assignment policies currently used by
   the Regional Registries to implement the guidelines developed by the
   IANA. The guidelines and these policies are subject to revision at
   the direction of the IANA. The registry working group (IRE WG) will
   be discussing these issues and may provide advice to the IANA about
   possible revisions.
</t>

<t>
   This document replaces RFC 1466, with all the guidelines and
   procedures updated and modified in the light of experience.
   This document does not describe private Internet address space and
   multicast address space.  It also does not describe regional and
   local refinements of the global rules and guidelines.
</t>

<t>
   This document can be considered the base set of operational
   guidelines in use by all registries.  Additional guidelines may be
   imposed by a particular registry as appropriate.
</t>
</abstract>

<note title="IESG Note">
<t>
   By approving this document as a Best Current Practice,the IESG
   asserts its belief that this policy described herein is an accurate
   representation of the current practice of the IP address registries
   with respect to address assignment.  This does not constitute
   endorsement or recommendation of this policy by the IESG. The IESG
   will reevaluate its approval of this document in December 1997 taking
   into consideration the results of the discussions that will be take
   place in the IRE Working Group between now and then.
</t>
</note>
</front>

<seriesInfo value="12" name="BCP" />
<seriesInfo value="2050" name="RFC" />
<format octets="43775" type="HTML" target="http://xml.resource.org/public/rfc/html/rfc2050.html" />
<format octets="31155" type="XML" target="http://xml.resource.org/public/rfc/xml/rfc2050.xml" />
</reference>


<reference target2="reference.RFC.2051.xml" anchor="RFC2051">
<front>
<title abbrev="SNANAU APPC MIB using SMIv2">Definitions of Managed Objects for APPC using SMIv2</title>
<author fullname="Michael Allen" initials="M." surname="Allen">
<organization>Wall Data Inc.</organization>

<address>
<postal>
<street>POB 1120</street>
<city>Kirkland</city>
<region>WA</region>
<code>98019</code>
<country>US</country>
</postal>

<phone>+1 206 844 3505</phone>
<email>mallen@hq.walldata.com</email>
</address>
</author>

<author fullname="Bob Clouston" initials="B." surname="Clouston">
<organization>Cisco Systems</organization>

<address>
<postal>
<street>7025 Kit Creek Road</street>
<street>PO Box 14987</street>
<city>Research Triangle Park</city>
<region>NC</region>
<code>27709</code>
<country>US</country>
</postal>

<phone>+1 919 472 2333</phone>
<email>clouston@cisco.com</email>
</address>
</author>

<author fullname="Zbigniew Kielczewski" initials="Z." surname="Kielczewski">
<organization>Cisco Systems</organization>

<address>
<postal>
<street>7025 Kit Creek Road</street>
<street>PO Box 14987</street>
<city>Research Triangle Park</city>
<region>NC</region>
<code>27709</code>
<country>US</country>
</postal>

<phone>+1 919 472 2326</phone>
<email>zbig@cisco.com</email>
</address>
</author>

<author fullname="William Kwan" initials="W." surname="Kwan">
<organization>Jupiter Technology Inc.</organization>

<address>
<postal>
<street>200 Prospect St.</street>
<city>Waltham</city>
<region>MA</region>
<code>02254</code>
<country>US</country>
</postal>

<phone>+1 617 894 9300 x423</phone>
<email>billk@jti.com</email>
</address>
</author>

<author fullname="Bob Moore" initials="B." surname="Moore">
<organization>IBM Corporation</organization>

<address>
<postal>
<street>800 Park Offices Drive</street>
<street>E87/664</street>
<street>P.O. Box 12195</street>
<city>Research Triangle Park</city>
<region>NC</region>
<code>27709</code>
<country>US</country>
</postal>

<phone>+1 919 254 4436</phone>
<email>remoore@ralvm6.vnet.ibm.com</email>
</address>
</author>

<date year="1996" month="October" />

<abstract>
<t></t>
</abstract>
</front>

<seriesInfo value="2051" name="RFC" />
</reference>


<reference target2="reference.RFC.2052.xml" anchor="RFC2052">
<front>
<title abbrev="DNS SRV RR">A DNS RR for specifying the location of services (DNS SRV)</title>
<author fullname="Arnt Gulbrandsen" initials="A." surname="Gulbrandsen">
<organization>Troll Tech</organization>

<address>
<postal>
<street>Postboks 6133 Etterstad</street>
<city>Oslo</city>
<code>N-0602</code>
<country>NO</country>
</postal>

<phone>+47 22 646966</phone>
<email>agulbra@troll.no</email>
</address>
</author>

<author fullname="Paul Vixie" initials="P." surname="Vixie">
<organization>Vixie Enterprises</organization>

<address>
<postal>
<street>Star Route 159A</street>
<city>Woodside</city>
<region>CA</region>
<code>94062</code>
<country>US</country>
</postal>

<phone>+1 415 747 0204</phone>
<email>paul@vix.com</email>
</address>
</author>

<date year="1996" month="October" />

<abstract>
<t>This document describes a DNS RR which specifies the location of the server(s) for a specific protocol and domain (like a more general form of MX).</t>
</abstract>
</front>

<seriesInfo value="2052" name="RFC" />
</reference>


<reference target2="reference.RFC.2053.xml" anchor="RFC2053">
<front>
<title>The AM (Armenia) Domain</title>
<author fullname="Edgar Der-Danieliantz" initials="E." surname="Der-Danieliantz">
<organization>AM Network Information Center</organization>

<address>
<postal>
<street>Mashtotz Avenue 51</street>
<street>Yerevan</street>
<country>AM</country>
</postal>

<phone>+374 2 281425</phone>
<facsimile>+374 2 285082</facsimile>
<email>edd@acm.org</email>
</address>
</author>

<date year="1996" month="October" />

<abstract>
<t></t>
</abstract>
</front>

<seriesInfo value="2053" name="RFC" />
</reference>


<reference target2="reference.RFC.2054.xml" anchor="RFC2054">
<front>
<title>WebNFS Client Specification</title>
<author fullname="Brent Callaghan" initials="B." surname="Callaghan">
<organization>Sun Microsystems, Inc.</organization>

<address>
<postal>
<street>2550 Garcia Avenue</street>
<street>Mailstop Mpk17-201</street>
<city>Mountain View</city>
<region>CA</region>
<code>94043-1100</code>
<country>US</country>
</postal>

<phone>+1 415 786 5067</phone>
<facsimile>+1 415 786 5896</facsimile>
<email>brent.callaghan@eng.sun.com</email>
</address>
</author>

<date year="1996" month="October" />

<abstract>
<t>This document describes a lightweight binding mechanism that allows NFS clients to obtain service from WebNFS-enabled servers with a minimum of protocol overhead.  In removing this overhead, WebNFS clients see benefits in faster response to requests, easy transit of packet filter firewalls and TCP-based proxies, and better server scalability.</t>
</abstract>
</front>

<seriesInfo value="2054" name="RFC" />
</reference>


<reference target2="reference.RFC.2055.xml" anchor="RFC2055">
<front>
<title>WebNFS Server Specification</title>
<author fullname="Brent Callaghan" initials="B." surname="Callaghan">
<organization>Sun Microsystems, Inc.</organization>

<address>
<postal>
<street>2550 Garcia Avenue</street>
<street>Mailstop Mpk17-201</street>
<city>Mountain View</city>
<region>CA</region>
<code>94043-1100</code>
<country>US</country>
</postal>

<phone>+1 415 786 5067</phone>
<facsimile>+1 415 786 5896</facsimile>
<email>brent.callaghan@eng.sun.com</email>
</address>
</author>

<date year="1996" month="October" />

<abstract>
<t>This document describes the specifications for a server of WebNFS clients.  WebNFS extends the semantics of versions 2 and 3 of the NFS protocols to allow clients to obtain filehandles more easily, without recourse to the portmap or MOUNT protocols.  In removing the need for these protocols, WebNFS clients see benefits in faster response to requests, easy transit of firewalls and better server scalability This description is provided to facilitate compatible implementations of WebNFS servers.</t>
</abstract>
</front>

<seriesInfo value="2055" name="RFC" />
</reference>


<reference target2="reference.RFC.2056.xml" anchor="RFC2056">
<front>
<title abbrev="URLs for Z39.50">Uniform Resource Locators for Z39.50</title>
<author fullname="Ray Denenberg" initials="R." surname="Denenberg">
<organization>Library of Congress, Collections Services, Network Development/MSO</organization>

<address>
<postal>
<street />
<city>Washington</city>
<region>DC</region>
<code>20540</code>
<country>US</country>
</postal>

<phone>+1 202 707 5795</phone>
<facsimile>+1 202 707 0115</facsimile>
<email>ray@rden.loc.gov</email>
</address>
</author>

<author fullname="John A. Kunze" initials="J." surname="Kunze">
<organization>University of California, San Francisco, Center for Knowledge Management</organization>

<address>
<postal>
<street>530 Parnassus Ave</street>
<street>Box 0840</street>
<city>San Francisco</city>
<region>CA</region>
<code>94143-0840</code>
<country>US</country>
</postal>

<phone>+1 415 502 6660</phone>
<facsimile>+1 415 476 4653</facsimile>
<email>jak@ckm.ucsf.edu</email>
</address>
</author>

<author fullname="Denis Lynch" initials="D." surname="Lynch">
<organization>SilverPlatter Information Ltd.</organization>

<address>
<postal>
<street>10 Barely Mow Passage</street>
<city>Chiswick, London</city>
<region>England</region>
<code>W4 4PH</code>
<country>UK</country>
</postal>

<phone>+44 181 9958242</phone>
<facsimile>+44 181 9955159</facsimile>
<email>DenisL@SilverPlatter.com</email>
</address>
</author>

<date year="1996" month="November" />

<abstract>
<t></t>
</abstract>
</front>

<seriesInfo value="2056" name="RFC" />
</reference>


<reference target2="reference.RFC.2057.xml" anchor="RFC2057">
<front>
<title abbrev="Source Directed Access Control">Source Directed Access Control on the Internet</title>
<author fullname="Scott Bradner" initials="S." surname="Bradner">
<organization>Harvard University</organization>

<address>
<postal>
<street>1350 Mass Ave.</street>
<city>Cambridge</city>
<region>MA</region>
<code>02138</code>
<country>US</country>
</postal>

<phone>+1 617 495 3864</phone>
<email>sob@harvard.edu</email>
</address>
</author>

<date year="1996" month="November" />

<abstract>
<t>This memo was developed from a deposition that I submitted as part of a challenge to the Communications Decency Act of 1996, part of the Telecommunications Reform Act of 1996.  The Telecommunications Reform Act is a U.S. federal law substantially changing the regulatory structure in the United States in the telecommunications arena.  The Communications Decency Act (CDA) part of this law has as its aim the desire to protect minors from some of the material carried over telecommunications networks.  In particular the law requires that the sender of potentially offensive material take "effective action" to ensure that it is not presented to minors.  A number of people have requested that I publish the deposition as an informational RFC since some of the information in it may be useful where descriptions of the way the Internet and its applications work could help clear up confusion in the technical feasibility of proposed content control regulations.</t>
</abstract>
</front>

<seriesInfo value="2057" name="RFC" />
</reference>


<reference target2="reference.RFC.2058.xml" anchor="RFC2058">
<front>
<title abbrev="RADIUS">Remote Authentication Dial In User Service (RADIUS)</title>
<author fullname="Carl Rigney" initials="C." surname="Rigney">
<organization>Livingston Enterprises</organization>

<address>
<postal>
<street>6920 Koll Center Parkway</street>
<street>Suite 220</street>
<city>Pleasanton</city>
<region>CA</region>
<code>94566</code>
<country>US</country>
</postal>

<phone>+1 510 426 0770</phone>
<email>cdr@livingston.com</email>
</address>
</author>

<author fullname="Allan C. Rubens" initials="A.C." surname="Rubens">
<organization>Merit Network, Inc.</organization>

<address>
<postal>
<street>4251 Plymouth Road</street>
<city>Ann Arbor</city>
<region>MI</region>
<code>48105-2785</code>
<country>US</country>
</postal>

<email>acr@merit.edu</email>
</address>
</author>

<author fullname="William Allen Simpson" initials="W.A." surname="Simpson">
<organization>Daydreamer, Computer Systems Consulting Services</organization>

<address>
<postal>
<street>1384 Fontaine</street>
<city>Madison Heights</city>
<region>MI</region>
<code>48071</code>
<country>US</country>
</postal>

<email>wsimpson@greendragon.com</email>
</address>
</author>

<author fullname="Steve Willens" initials="S." surname="Willens">
<organization>Livingston Enterprises</organization>

<address>
<postal>
<street>6920 Koll Center Parkway</street>
<street>Suite 220</street>
<city>Pleasanton</city>
<region>CA</region>
<code>94566</code>
<country>US</country>
</postal>

<email>steve@livingston.com</email>
</address>
</author>

<date year="1997" month="January" />

<abstract>
<t>This document describes a protocol for carrying authentication, authorization, and configuration information between a Network Access Server which desires to authenticate its links and a shared Authentication Server.</t>
</abstract>
</front>

<seriesInfo value="2058" name="RFC" />
</reference>


<reference target2="reference.RFC.2059.xml" anchor="RFC2059">
<front>
<title>RADIUS Accounting</title>
<author fullname="Carl Rigney" initials="C." surname="Rigney">
<organization>Livingston Enterprises</organization>

<address>
<postal>
<street>6920 Koll Center Parkway</street>
<street>Suite 220</street>
<city>Pleasanton</city>
<region>CA</region>
<code>94566</code>
<country>US</country>
</postal>

<email>cdr@livingston.com</email>
</address>
</author>

<date year="1997" month="January" />

<abstract>
<t>This document describes a protocol for carrying accounting information between a Network Access Server and a shared Accounting Server.</t>
</abstract>
</front>

<seriesInfo value="2059" name="RFC" />
</reference>


<reference target2="reference.RFC.2060.xml" anchor="RFC2060">
<front>
<title abbrev="IMAP4rev1">Internet Message Access Protocol - Version 4rev1</title>
<author fullname="Mark R. Crispin" initials="M." surname="Crispin">
<organization>University of Washington, Networks and Distributed Computing</organization>

<address>
<postal>
<street>4545 15th Aveneue NE</street>
<city>Seattle</city>
<region>WA</region>
<code>98105-4527</code>
<country>US</country>
</postal>

<phone>+1 206 543 5762</phone>
<email>MRC@CAC.Washington.EDU</email>
</address>
</author>

<date year="1996" month="December" />

<abstract>
<t>The Internet Message Access Protocol, Version 4rev1 (IMAP4rev1) allows a client to access and manipulate electronic mail messages on a server.  IMAP4rev1 permits manipulation of remote message folders, called "mailboxes", in a way that is functionally equivalent to local mailboxes.  IMAP4rev1 also provides the capability for an offline client to resynchronize with the server (see also.</t>

<t>IMAP4rev1 includes operations for creating, deleting, and renaming mailboxes; checking for new messages; permanently removing messages; setting and clearing flags;andparsing; searching; and selective fetching of message attributes, texts, and portions thereof.  Messages in IMAP4rev1 are accessed by the use of numbers.  These numbers are either message sequence numbers or unique identifiers.</t>

<t>IMAP4rev1 supports a single server.  A mechanism for accessing configuration information to support multiple IMAP4rev1 servers is discussed in.</t>

<t>IMAP4rev1 does not specify a means of posting mail; this function is handled by a mail transfer protocol such as.</t>

<t>IMAP4rev1 is designed to be upwards compatible from theand unpublished IMAP2bis protocols.  In the course of the evolution of IMAP4rev1, some aspects in the earlier protocol have become obsolete. Obsolete commands, responses, and data formats which an IMAP4rev1 implementation may encounter when used with an earlier implementation are described in.</t>

<t>Other compatibility issues with IMAP2bis, the most common variant of the earlier protocol, are discussed in.  A full discussion of compatibility issues with rare (and presumed extinct) variants ofis in; this document is primarily of historical interest.</t>
</abstract>
</front>

<seriesInfo value="2060" name="RFC" />
</reference>


<reference target2="reference.RFC.2061.xml" anchor="RFC2061">
<front>
<title abbrev="IMAP4 Compatibility">IMAP4 Compatibility with IMAP2bis</title>
<author fullname="Mark R. Crispin" initials="M." surname="Crispin">
<organization>University of Washington, Networks and Distributed Computing</organization>

<address>
<postal>
<street>4545 15th Aveneue NE</street>
<city>Seattle</city>
<region>WA</region>
<code>98105-4527</code>
<country>US</country>
</postal>

<phone>+1 206 543 5762</phone>
<email>MRC@CAC.Washington.EDU</email>
</address>
</author>

<date year="1996" month="December" />

<abstract>
<t></t>
</abstract>
</front>

<seriesInfo value="2061" name="RFC" />
</reference>


<reference target2="reference.RFC.2062.xml" anchor="RFC2062">
<front>
<title abbrev="IMAP4 Obsolete">Internet Message Access Protocol - Obsolete Syntax</title>
<author fullname="Mark R. Crispin" initials="M." surname="Crispin">
<organization>University of Washington, Networks and Distributed Computing</organization>

<address>
<postal>
<street>4545 15th Aveneue NE</street>
<city>Seattle</city>
<region>WA</region>
<code>98105-4527</code>
<country>US</country>
</postal>

<phone>+1 206 543 5762</phone>
<email>MRC@CAC.Washington.EDU</email>
</address>
</author>

<date year="1996" month="December" />

<abstract>
<t>This document describes obsolete syntax which may be encountered by IMAP4 implementations which deal with older versions of the Internet Mail Access Protocol.  IMAP4 implementations MAY implement this syntax in order to maximize interoperability with older implementations.</t>

<t>This document repeats information from earlier documents, most notably RFC 1176 and RFC 1730.</t>
</abstract>
</front>

<seriesInfo value="2062" name="RFC" />
</reference>


<reference target2="reference.RFC.2063.xml" anchor="RFC2063">
<front>
<title>Traffic Flow Measurement: Architecture</title>
<author fullname="Nevil Brownlee" initials="N." surname="Brownlee">
<organization>The University of Auckland, Information Technology Systems &amp; Services</organization>

<address>
<postal>
<street>Private Bag 92-019</street>
<city>Auckland</city>
<region />
<code />
<country>NZ</country>
</postal>

<phone>+64 9 3737599x8941</phone>
<email>n.brownlee @auckland.ac.nz</email>
</address>
</author>

<author fullname="Cyndi Mills" initials="C." surname="Mills">
<organization>BBN Systems and Technologies</organization>

<address>
<phone>+1 617 873 4143</phone>
<email>cmills@bbn.com</email>
</address>
</author>

<author fullname="Greg Ruth" initials="G." surname="Ruth">
<organization>GTE Laboratories, Inc</organization>

<address>
<phone>+1 617 466 2448</phone>
<email>gruth@gte.com</email>
</address>
</author>

<date year="1997" month="January" />

<abstract>
<t>This document describes an architecture for the measurement and reporting of network traffic flows, discusses how this relates to an overall network traffic flow architecture, and describes how it can be used within the Internet.  It is intended to provide a starting point for the Realtime Traffic Flow Measurement Working Group.</t>
</abstract>
</front>

<seriesInfo value="2063" name="RFC" />
</reference>


<reference target2="reference.RFC.2064.xml" anchor="RFC2064">
<front>
<title abbrev="Meter MIB">Traffic Flow Measurement: Meter MIB</title>
<author fullname="Nevil Brownlee" initials="N." surname="Brownlee">
<organization>The University of Auckland, Information Technology Systems &amp; Services</organization>

<address>
<postal>
<street>Private Bag 92-019</street>
<city>Auckland</city>
<region />
<code />
<country>NZ</country>
</postal>

<phone>+64 9 3737599x8941</phone>
<email>n.brownlee @auckland.ac.nz</email>
</address>
</author>

<date year="1997" month="January" />

<abstract>
<t>This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in TCP/IP-based internets. In particular, this memo defines managed objects used for obtaining traffic flow information from network traffic meters.</t>
</abstract>
</front>

<seriesInfo value="2064" name="RFC" />
</reference>


<reference target2="reference.RFC.2065.xml" anchor="RFC2065">
<front>
<title abbrev="DNS Security Extensions">Domain Name System Security Extensions</title>
<author fullname="Donald E. Eastlake 3rd" initials="D.E." surname="Eastlake">
<organization>CyberCash, Inc.</organization>

<address>
<postal>
<street>318 Acton Street</street>
<city>Carlisle</city>
<region>MA</region>
<code>01741</code>
<country>US</country>
</postal>

<phone>+1 508 287 4877</phone>
<facsimile>+1 508 371 7148</facsimile>
<email>dee@cybercash.com</email>
</address>
</author>

<author fullname="Charles W. Kaufman" initials="C." surname="Kaufman">
<organization>Iris Associates</organization>

<address>
<postal>
<street>1 Technology Park Drive</street>
<city>Westford</city>
<region>MA</region>
<code>01886</code>
<country>US</country>
</postal>

<phone>+1 508 392 5276</phone>
<email>charlie_kaufman@iris.com</email>
</address>
</author>

<date year="1997" month="January" />

<abstract>
<t>The Domain Name System (DNS) has become a critical operational part of the Internet infrastructure yet it has no strong security mechanisms to assure data integrity or authentication.  Extensions to the DNS are described that provide these services to security aware resolvers or applications through the use of cryptographic digital signatures.  These digital signatures are included in secured zones as resource records.  Security can still be provided even through non-security aware DNS servers in many cases.</t>

<t>The extensions also provide for the storage of authenticated public keys in the DNS.  This storage of keys can support general public key distribution service as well as DNS security.  The stored keys enable security aware resolvers to learn the authenticating key of zones in addition to those for which they are initially configured.  Keys associated with DNS names can be retrieved to support other protocols.  Provision is made for a variety of key types and algorithms.</t>

<t>In addition, the security extensions provide for the optional authentication of DNS protocol transactions.</t>
</abstract>
</front>

<seriesInfo value="2065" name="RFC" />
</reference>


<reference target2="reference.RFC.2066.xml" anchor="RFC2066">
<front>
<title>TELNET CHARSET Option</title>
<author fullname="Randall Gellens" initials="R." surname="Gellens">
<organization>Unisys Corporation</organization>

<address>
<postal>
<street>25725 Jeronimo Road</street>
<street>Mail Stop 237</street>
<city>Mission Viejo</city>
<region>CA</region>
<code>92691</code>
<country>US</country>
</postal>

<phone>+1 714 380 6350</phone>
<facsimile>+1 714 380 5912</facsimile>
<email>Randy@MV.Unisys.Com</email>
</address>
</author>

<date year="1997" month="January" />

<abstract>
<t>This document specifies a mechanism for passing character set and translation information between a TELNET client and server.  Use of this mechanism enables an application used by a TELNET user to send and receive data in the correct character set.</t>

<t>Either side can (subject to option negotiation) at any time request that a (new) character set be used.</t>
</abstract>
</front>

<seriesInfo value="2066" name="RFC" />
</reference>


<reference target2="reference.RFC.2067.xml" anchor="RFC2067">
<front>
<title>IP over HIPPI</title>
<author fullname="John K. Renwick" initials="J." surname="Renwick">
<organization>NetStar, Inc.</organization>

<address>
<postal>
<street>10250 Valley View Road</street>
<city>Eden Prairie</city>
<region>MN</region>
<code>55344</code>
<country>US</country>
</postal>

<phone>+1 612 996 6847</phone>
<email>jkr@NetStar.com</email>
</address>
</author>

<date year="1997" month="January" />

<abstract>
<t>ANSI Standard X3.218-1993 (HIPPI-LEdefines the encapsulation of IEEE 802.2 LLC PDUs and, by implication, IP on HIPPI.  ANSI X3.222-
   1993 (HIPPI-SCdescribes the operation of HIPPI physical switches.  The ANSI committee responsible for these standards chose to leave HIPPI networking issues largely outside the scope of their standards; this document describes the use of HIPPI switches as IP local area networks.</t>

<t>This memo is a revision of RFC 1374, "IP and ARP on HIPPI", and is intended to replace it in the Standards Track.  RFC 1374 has been a Proposed Standard since November, 1992, with at least 10 implementations of IP encapsulation and HIPPI switch discipline.  No major changes to it are required.  However, the ARP part of RFC 1374 has not had sufficient implementation experience to be advanced to Draft Standard.  The present document contains all of RFC 1374 except for the description ARP, which has been moved into a separate document.</t>
</abstract>
</front>

<seriesInfo value="2067" name="RFC" />
</reference>


<reference target2="reference.RFC.2068.xml" anchor="RFC2068">
<front>
<title abbrev="HTTP/1.1">Hypertext Transfer Protocol -- HTTP/1.1</title>
<author fullname="Roy T. Fielding" initials="R." surname="Fielding">
<organization>University of California, Irvine, Department of Information and Computer Science</organization>

<address>
<postal>
<street />
<city>Irvine</city>
<region>CA</region>
<code>92717-3425</code>
<country>US</country>
</postal>

<facsimile>+1 714 824 4056</facsimile>
<email>fielding@ics.uci.edu</email>
</address>
</author>

<author fullname="Jim Gettys" initials="J." surname="Gettys">
<organization>MIT Laboratory for Computer Science</organization>

<address>
<postal>
<street>545 Technology Square</street>
<city>Cambridge</city>
<region>MA</region>
<code>02139</code>
<country>US</country>
</postal>

<facsimile>+1 617 258 8682</facsimile>
<email>jg@w3.org</email>
</address>
</author>

<author fullname="Jeffrey C. Mogul" initials="J." surname="Mogul">
<organization>Digital Equipment Corporation, Western Research Laboratory</organization>

<address>
<postal>
<street>250 University Avenue</street>
<city>Palo Alto</city>
<region>CA</region>
<code>94301</code>
<country>US</country>
</postal>

<email>mogul@wrl.dec.com</email>
</address>
</author>

<author fullname="Henrik Frystyk Nielsen" initials="H." surname="Nielsen">
<organization>MIT Laboratory for Computer Science</organization>

<address>
<postal>
<street>545 Technology Square</street>
<city>Cambridge</city>
<region>MA</region>
<code>02139</code>
<country>US</country>
</postal>

<facsimile>+1 617 258 8682</facsimile>
<email>frystyk@w3.org</email>
</address>
</author>

<author fullname="Tim Berners-Lee" initials="T." surname="Berners-Lee">
<organization>MIT Laboratory for Computer Science</organization>

<address>
<postal>
<street>545 Technology Square</street>
<city>Cambridge</city>
<region>MA</region>
<code>02139</code>
<country>US</country>
</postal>

<facsimile>+1 617 258 8682</facsimile>
<email>timbl@w3.org</email>
</address>
</author>

<date year="1997" month="January" />

<abstract>
<t>The Hypertext Transfer Protocol (HTTP) is an application-level protocol for distributed, collaborative, hypermedia information systems. It is a generic, stateless, object-oriented protocol which can be used for many tasks, such as name servers and distributed object management systems, through extension of its request methods. A feature of HTTP is the typing and negotiation of data representation, allowing systems to be built independently of the data being transferred.</t>

<t>HTTP has been in use by the World-Wide Web global information initiative since 1990. This specification defines the protocol referred to as "HTTP/1.1".</t>
</abstract>
</front>

<seriesInfo value="2068" name="RFC" />
</reference>


<reference target2="reference.RFC.2069.xml" anchor="RFC2069">
<front>
<title abbrev="Digest Access Authentication">An Extension to HTTP : Digest Access Authentication</title>
<author fullname="John Franks" initials="J." surname="Franks">
<organization>Northwestern University,  Department of Mathematics</organization>

<address>
<postal>
<street />
<city>Evanston</city>
<region>IL</region>
<code>60208-2730</code>
<country>US</country>
</postal>

<email>john@math.nwu.edu</email>
</address>
</author>

<author fullname="Phillip M. Hallam-Baker" initials="P." surname="Hallam-Baker">
<organization>CERN</organization>

<address>
<postal>
<street />
<city>Geneva</city>
<country>CH</country>
</postal>

<email>hallam@w3.org</email>
</address>
</author>

<author fullname="Jeffery L. Hostetler" initials="J." surname="Hostetler">
<organization>Spyglass, Inc.</organization>

<address>
<postal>
<street>3200 Farber Drive</street>
<city>Champaign</city>
<region>IL</region>
<code>61821</code>
<country>US</country>
</postal>

<email>jeff@spyglass.com</email>
</address>
</author>

<author fullname="Paul J. Leach" initials="P." surname="Leach">
<organization>Microsoft Corporation</organization>

<address>
<postal>
<street>1 Microsoft Way</street>
<city>Redmond</city>
<region>WA</region>
<code>98052</code>
<country>US</country>
</postal>

<email>paulle@microsoft.com</email>
</address>
</author>

<author fullname="Ari Luotonen" initials="A." surname="Luotonen">
<organization>Netscape Communications Corporation</organization>

<address>
<postal>
<street>501 East Middlefield Road</street>
<city>Mountain View</city>
<region>CA</region>
<code>94043</code>
<country>US</country>
</postal>

<email>luotonen@netscape.com</email>
</address>
</author>

<author fullname="Eric W. Sink" initials="E." surname="Sink">
<organization>Spyglass, Inc.</organization>

<address>
<postal>
<street>3200 Farber Drive</street>
<city>Champaign</city>
<region>IL</region>
<code>61821</code>
<country>US</country>
</postal>

<email>eric@spyglass.com</email>
</address>
</author>

<author fullname="Lawrence C. Stewart" initials="L." surname="Stewart">
<organization>Open Market, Inc.</organization>

<address>
<postal>
<street>215 First Street</street>
<city>Cambridge</city>
<region>MA</region>
<code>02142</code>
<country>US</country>
</postal>

<email>stewart@OpenMarket.com</email>
</address>
</author>

<date year="1997" month="January" />

<abstract>
<t>The protocol referred to as "HTTP/1.0" includes the specification for a Basic Access Authentication scheme.  This scheme is not considered to be a secure method of user authentication, as the user name and password are passed over the network as clear text.  A specification for a different authentication scheme is needed to address this severe limitation.  This document provides specification for such a scheme, referred to as "Digest Access Authentication".  Like Basic, Digest access authentication verifies that both parties to a communication know a shared secret (a password); unlike Basic, this verification can be done without sending the password in the clear, which is Basic's biggest weakness. As with most other authentication protocols, the greatest sources of risks are usually found not in the core protocol itself but in policies and procedures surrounding its use.</t>
</abstract>
</front>

<seriesInfo value="2069" name="RFC" />
</reference>


<reference target2="reference.RFC.2070.xml" anchor="RFC2070">
<front>
<title abbrev="HTML Internationalization">Internationalization of the Hypertext Markup Language</title>
<author fullname="Frangois Yergeau" initials="F." surname="Yergeau">
<organization>Alis Technologies</organization>

<address>
<postal>
<street>100, boul. Alexis-Nihon</street>
<street>bureau 600</street>
<city>Montreal</city>
<region>Quebec</region>
<code>H4M 2P2</code>
<country>CA</country>
</postal>

<phone>+1 514 747 2547</phone>
<facsimile>+1 514 747 2561</facsimile>
<email>fyergeau@alis.com</email>
</address>
</author>

<author fullname="Gavin Thomas Nicol" initials="G." surname="Nicol">
<organization>Electronic Book Technologies, Japan</organization>

<address>
<postal>
<street>1-29-9 Tsurumaki</street>
<city>Tokyo</city>
<region>Setagaya-ku</region>
<code />
<country>JP</country>
</postal>

<phone>+81 3 32308161</phone>
<facsimile>+81 3 32308163</facsimile>
<email>gtn@ebt.com</email>
</address>
</author>

<author fullname="Glenn Adams" initials="G." surname="Adams">
<organization>Spyglass</organization>

<address>
<postal>
<street>118 Magazine Street</street>
<city>Cambridge</city>
<region>MA</region>
<code>02139</code>
<country>US</country>
</postal>

<phone>+1 617 864 5524</phone>
<facsimile>+1 617 864 4965</facsimile>
<email>glenn@spyglass.com</email>
</address>
</author>

<author fullname="Martin J. Duerst" initials="M." surname="Duerst">
<organization>University of Zurich, Department of Computer Science, Multimedia-Laboratory</organization>

<address>
<postal>
<street>Winterthurerstrasse 190</street>
<city>Zurich</city>
<region />
<code>CH-8057</code>
<country>CH</country>
</postal>

<phone>+41 1 2574316</phone>
<facsimile>+41 1 3630035</facsimile>
<email>mduerst@ifi.unizh.ch</email>
</address>
</author>

<date year="1997" month="January" />

<abstract>
<t>The Hypertext Markup Language (HTML) is a markup language used to create hypertext documents that are platform independent.  Initially, the application of HTML on the World Wide Web was seriously restricted by its reliance on the ISO-8859-1 coded character set, which is appropriate only for Western European languages.  Despite this restriction, HTML has been widely used with other languages, using other coded character sets or character encodings, at the expense of interoperability.</t>

<t>This document is meant to address the issue of the internationalization (i18n, i followed by 18 letters followed by n) of HTML by extending the specification of HTML and giving additional recommendations for proper internationalization support.  A foremost consideration is to make sure that HTML remains a valid application of SGML, while enabling its use with all languages of the world.</t>
</abstract>
</front>

<seriesInfo value="2070" name="RFC" />
</reference>


<reference target2="reference.RFC.2071.xml" anchor="RFC2071">
<front>
<title abbrev="Network Renumbering Overview">Network Renumbering Overview: Why would I want it and what is it anyway?</title>
<author fullname="Paul Ferguson" initials="P." surname="Ferguson">
<organization>cisco Systems, Inc.</organization>

<address>
<postal>
<street>1875 Campus Commons Road</street>
<street>Suite 210</street>
<city>Reston</city>
<region>VA</region>
<code>22091</code>
<country>US</country>
</postal>

<phone>+1 703 716 9538</phone>
<facsimile>+1 703 716 9599</facsimile>
<email>pferguso@cisco.com</email>
</address>
</author>

<author fullname="Howard C. Berkowitz" initials="H." surname="Berkowitz">
<organization>PSC International</organization>

<address>
<postal>
<street>1600 Spring Hill Road</street>
<city>Vienna</city>
<region>VA</region>
<code>22182</code>
<country>US</country>
</postal>

<phone>+1 703 998 5819</phone>
<facsimile>+1 703 998 5058</facsimile>
<email>hcb@clark.net</email>
</address>
</author>

<date year="1997" month="January" />

<abstract>
<t>The PIER [Procedures for Internet/Enterprise Renumbering] working group is compiling a series of documents to assist and instruct organizations in their efforts to renumber.  However, it is becoming apparent that, with the increasing number of new Internet Service Providers (ISP's) and organizations getting connected to the Internet for the first time, the concept of network renumbering needs to be further defined.  This document attempts to clearly define the concept of network renumbering and discuss some of the more pertinent reasons why an organization would have a need to do so.</t>
</abstract>
</front>

<seriesInfo value="2071" name="RFC" />
</reference>


<reference target2="reference.RFC.2072.xml" anchor="RFC2072">
<front>
<title>Router Renumbering Guide</title>
<author fullname="Howard C. Berkowitz" initials="H." surname="Berkowitz">
<organization>PSC International</organization>

<address>
<postal>
<street>1600 Spring Hill Road</street>
<street>Suite 310</street>
<city>Vienna</city>
<region>VA</region>
<code>22182</code>
<country>US</country>
</postal>

<phone>+1 703 998 5819</phone>
<email>hcb@clark.net</email>
</address>
</author>

<date year="1997" month="January" />

<abstract>
<t>IP addresses currently used by organizations are likely to undergo changes in the near to moderate term.  Change can become necessary for a variety of reasons, including enterprise reorganization, physical moves of equipment, new strategic relationships, changes in Internet Service Providers (ISP), new applications, and the needs of global Internet connectivity.  Good IP address management may in general simplify continuing system administration; a good renumbering plan is also a good numbering plan.    Most actions taken to ease future renumbering will ease routine network administration.</t>

<t>Routers are the components that interconnect parts of the IP address space identified by unique prefixes.  Obviously, they will be impacted by renumbering.  Other interconnection devices, such as bridges, layer 2 switches (i.e., specialized bridges), and ATM switches may be affected by renumbering.  The interactions of these lower-layer interconnection devices with routers must be considered as part of a renumbering effort.</t>

<t>Routers interact with numerous network infrastructure servers, including DNS and SNMP.  These interactions, not just the pure addressing and routing structure, must be considered as part of router renumbering.</t>
</abstract>
</front>

<seriesInfo value="2072" name="RFC" />
</reference>


<reference target2="reference.RFC.2073.xml" anchor="RFC2073">
<front>
<title abbrev="IPv6 Provider-Based Unicast Address Format">An IPv6 Provider-Based Unicast Address Format</title>
<author fullname="Yakov Rekhter" initials="Y." surname="Rekhter">
<organization>Cisco Systems, Inc.</organization>

<address>
<postal>
<street>170 West Tasman Drive</street>
<city>San Jose</city>
<region>CA</region>
<code>95134-1706</code>
<country>US</country>
</postal>

<phone>+1 914 528 0090</phone>
<email>yakov@cisco.com</email>
</address>
</author>

<author fullname="Peter Lothberg" initials="P." surname="Lothberg">
<organization>STUPI.AB</organization>

<address>
<postal>
<street>Box 9129</street>
<city>Stockholm</city>
<region />
<code>S-102 72</code>
<country>SE</country>
</postal>

<phone>+46 8 6699720</phone>
<email>roll@Stupi.SE</email>
</address>
</author>

<author fullname="Robert M. Hinden" initials="R." surname="Hinden">
<organization>Ipsilon Networks, Inc.</organization>

<address>
<postal>
<street>2191 E. Bayshore Road</street>
<city>Palo Alto</city>
<region>CA</region>
<code>94303</code>
<country>US</country>
</postal>

<phone>+1 415 846 4604</phone>
<email>hinden@ipsilon.com</email>
</address>
</author>

<author fullname="Stephen E. Deering" initials="S." surname="Deering">
<organization>Xerox Palo Alto Research Center</organization>

<address>
<postal>
<street>3333 Coyote Hill Road</street>
<city>Palo Alto</city>
<region>CA</region>
<code>94304</code>
<country>US</country>
</postal>

<phone>+1 415 812 4839</phone>
<facsimile>+1 415 812 4471</facsimile>
<email>deering@parc.xerox.com</email>
</address>
</author>

<author fullname="Jon Postel" initials="J." surname="Postel">
<organization>USC, Information Sciences Institute</organization>

<address>
<postal>
<street>4676 Admiralty Way</street>
<city>Marina del Rey</city>
<region>CA</region>
<code>90292-6695</code>
<country>US</country>
</postal>

<phone>+1 310 822 1511</phone>
<facsimile>+1 310 823 6714</facsimile>
<email>postel@isi.edu</email>
</address>
</author>

<date year="1997" month="January" />

<abstract>
<t></t>
</abstract>
</front>

<seriesInfo value="2073" name="RFC" />
</reference>


<reference target2="reference.RFC.2074.xml" anchor="RFC2074">
<front>
<title abbrev="RMON Protocol Identifiers">Remote Network Monitoring MIB Protocol Identifiers</title>
<author fullname="Andy Bierman" initials="A." surname="Bierman">
<organization>Cisco Systems, Inc.</organization>

<address>
<postal>
<street>170 West Tasman Drive</street>
<city>San Jose</city>
<region>CA</region>
<code>95134</code>
<country>US</country>
</postal>

<phone>+1 408 527 3711</phone>
<email>abierman@cisco.com</email>
</address>
</author>

<author fullname="Robin Iddon" initials="R." surname="Iddon">
<organization>3Com/AXON</organization>

<address>
<postal>
<street>40/50 Blackfrias Street</street>
<city>Edinburgh</city>
<region>Scotland</region>
<code>EH1 1NE</code>
<country>UK</country>
</postal>

<phone>+44 131 5583888</phone>
<email>robin_iddon@3mail.3com.com</email>
</address>
</author>

<date year="1997" month="January" />

<abstract>
<t></t>
</abstract>
</front>

<seriesInfo value="2074" name="RFC" />
</reference>


<reference target2="reference.RFC.2075.xml" anchor="RFC2075">
<front>
<title>IP Echo Host Service</title>
<author fullname="Craig Partridge" initials="C." surname="Partridge">
<organization>BBN Corporation</organization>

<address>
<postal>
<street>10 Moulton St</street>
<city>Cambridge</city>
<region>MA</region>
<code>02138</code>
<country>US</country>
</postal>

<email>craig@bbn.com</email>
</address>
</author>

<date year="1997" month="January" />

<abstract>
<t>This memo describes how to implement an IP echo host.  IP echo hosts send back IP datagrams after exchanging the source and destination IP addresses.  The effect is that datagrams sent to the echo host are sent back to the source, as if they originated at the echo host.</t>
</abstract>
</front>

<seriesInfo value="2075" name="RFC" />
</reference>


<reference target2="reference.RFC.2076.xml" anchor="RFC2076">
<front>
<title abbrev="Internet Message Headers">Common Internet Message Headers</title>
<author fullname="Jacob Palme" initials="J." surname="Palme">
<organization>Stockholm University/KTH</organization>

<address>
<postal>
<street>Electrum 230</street>
<street>S-164 40 Kista</street>
<country>SE</country>
</postal>

<phone>+46 8 161667</phone>
<facsimile>+46 8 7830829</facsimile>
<email>jpalme@dsv.su.se</email>
</address>
</author>

<date year="1997" month="February" />

<abstract>
<t>This memo contains a table of commonly occurring headers in headings of e-mail messages. The document compiles information from other RFCs such as RFC 822, RFC 1036, RFC 1123, RFC 1327, RFC 1496, RFC 1521, RFC 1766, RFC 1806, RFC 1864 and RFC 1911. A few commonly occurring headers which are not defined in RFCs are also included. For each header, the memo gives a short description and a reference to the RFC in which the header is defined.</t>
</abstract>
</front>

<seriesInfo value="2076" name="RFC" />
</reference>


<reference target2="reference.RFC.2077.xml" anchor="RFC2077">
<front>
<title abbrev="Model Primary MIME Types">The Model Primary Content Type for Multipurpose Internet Mail Extensions</title>
<author fullname="S. D. Nelson" initials="S." surname="Nelson">
<organization>University of California, Lawrence Livermore National Laboratory</organization>

<address>
<postal>
<street>7000 East Ave.</street>
<street>L-153</street>
<city>Livermore</city>
<region>CA</region>
<code>94550</code>
<country>US</country>
</postal>

<email>nelson18@llnl.gov</email>
</address>
</author>

<author fullname="C. Parks" initials="C." surname="Parks">
<organization>National Institute of Standards &amp; Technology</organization>

<address>
<postal>
<street>Bldg 220</street>
<street>Room B-344</street>
<city>Gaithersburg</city>
<region>MD</region>
<code>20899</code>
<country>US</country>
</postal>

<email>parks@eeel.nist.gov</email>
</address>
</author>

<author fullname="Mitra" initials="" surname="Mitra">
<organization>WorldMaker</organization>

<address>
<postal>
<street>1056 Noe</street>
<city>San Francisco</city>
<region>CA</region>
<code>94114</code>
<country>US</country>
</postal>

<email>mitra@earth.path.net</email>
</address>
</author>

<date year="1997" month="January" />

<abstract>
<t></t>
</abstract>
</front>

<seriesInfo value="2077" name="RFC" />
</reference>


<reference target2="reference.RFC.2078.xml" anchor="RFC2078">
<front>
<title abbrev="GSS-API">Generic Security Service Application Program Interface, Version 2</title>
<author fullname="John Linn" initials="J." surname="Linn">
<organization>OpenVision Technologies</organization>

<address>
<postal>
<street>One Main St.</street>
<city>Cambridge</city>
<region>MA</region>
<code>02142</code>
<country>US</country>
</postal>

<phone>+1 617 374 2245</phone>
<email>John.Linn@ov.com</email>
</address>
</author>

<date year="1997" month="January" />

<abstract>
<t>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. 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:</t>

<t>documents defining specific parameter bindings for particular language environments</t>

<t>documents defining token formats, protocols, and procedures to be implemented in order to realize GSS-API services atop particular security mechanisms</t>

<t>This memo revises RFC-1508, making specific, incremental changes in response to implementation experience and liaison requests. It is intended, therefore, that this memo or a successor version thereto will become the basis for subsequent progression of the GSS-API specification on the standards track.</t>
</abstract>
</front>

<seriesInfo value="2078" name="RFC" />
</reference>


<reference target2="reference.RFC.2079.xml" anchor="RFC2079">
<front>
<title abbrev="URI Attribute Type and Object Class">Definition of an X.500 Attribute Type and an Object Class to Hold Uniform Resource Identifiers (URIs)</title>
<author fullname="Mark Smith" initials="M." surname="Smith">
<organization>Netscape Communications Corp.</organization>

<address>
<postal>
<street>501 E. Middlefield Rd.</street>
<city>Mountain View</city>
<region>CA</region>
<code>94043</code>
<country>US</country>
</postal>

<phone>+1 415 937 3477</phone>
<email>mcs@netscape.com</email>
</address>
</author>

<date year="1997" month="January" />

<abstract>
<t>Uniform Resource Locators (URLs) are being widely used to specify the location of Internet resources.  There is an urgent need to be able to include URLs in directories that conform to the LDAP and X.500 information models, and a desire to include other types of Uniform Resource Identifiers (URIs) as they are defined.  A number of independent groups are already experimenting with the inclusion of URLs in LDAP and X.500 directories.  This document builds on the experimentation to date and defines a new attribute type and an auxiliary object class to allow URIs, including URLs, to be stored in directory entries in a standard way.</t>
</abstract>
</front>

<seriesInfo value="2079" name="RFC" />
</reference>


<reference target2="reference.RFC.2080.xml" anchor="RFC2080">
<front>
<title>RIPng for IPv6</title>
<author fullname="Gary Scott Malkin" initials="G." surname="Malkin">
<organization>Xylogics, Inc.</organization>

<address>
<postal>
<street>53 Third Avenue</street>
<city>Burlington</city>
<region>MA</region>
<code>01803</code>
<country>US</country>
</postal>

<phone>+1 617 272 8140</phone>
<email>gmalkin@Xylogics.COM</email>
</address>
</author>

<author fullname="Robert E. Minnear" initials="R." surname="Minnear">
<organization>Ipsilon Networks, Inc.</organization>

<address>
<postal>
<street>2191 E. Bayshore Road</street>
<street>Suite 100</street>
<city>Palo Alto</city>
<region>CA</region>
<code>94303</code>
<country>US</country>
</postal>

<phone>+1 415 846 4614</phone>
<email>minnear@ipsilon.com</email>
</address>
</author>

<date year="1997" month="January" />

<abstract>
<t>This document specifies a routing protocol for an IPv6 internet.  It is based on protocols and algorithms currently in wide use in the IPv4 Internet.</t>

<t>This specification represents the minimum change to the Routing Information Protocol (RIP), as specified in RFC 1058and RFC 1723, necessary for operation over IPv6.</t>
</abstract>
</front>

<seriesInfo value="2080" name="RFC" />
</reference>


<reference target2="reference.RFC.2081.xml" anchor="RFC2081">
<front>
<title abbrev="RIP-2 Applicability">RIPng Protocol Applicability Statement</title>
<author fullname="Gary Scott Malkin" initials="G." surname="Malkin">
<organization>Xylogics/Bay Networks</organization>

<address>
<postal>
<street>53 Third Avenue</street>
<city>Burlington</city>
<region>MA</region>
<code>01803</code>
<country>US</country>
</postal>

<phone>+1 617 238 6237</phone>
<email>gmalkin@xylogics.com</email>
</address>
</author>

<date year="1997" month="January" />

<abstract>
<t>As required by Routing Protocol Criteria (RFC 1264), this report defines the applicability of the RIPng protocol within the Internet. This report is a prerequisite to advancing RIPng on the standards track.</t>
</abstract>
</front>

<seriesInfo value="2081" name="RFC" />
</reference>


<reference target2="reference.RFC.2082.xml" anchor="RFC2082">
<front>
<title>RIP-2 MD5 Authentication</title>
<author fullname="Fred Baker" initials="F." surname="Baker">
<organization>cisco Systems</organization>

<address>
<postal>
<street>519 Lado Drive</street>
<city>Santa Barbara</city>
<region>CA</region>
<code>93111</code>
<country>US</country>
</postal>

<phone>+1 805 681 0115</phone>
<email>fred@cisco.com</email>
</address>
</author>

<author fullname="Randall Atkinson" initials="R." surname="Atkinson">
<organization>cisco Systems</organization>

<address>
<postal>
<street>170 West Tasman Drive</street>
<city>San Jose</city>
<region>CA</region>
<code>95134-1706</code>
<country>US</country>
</postal>

<phone>+1 408 526 6566</phone>
<email>rja@cisco.com</email>
</address>
</author>

<author fullname="Gary Scott Malkin" initials="G.S." surname="Malkin">
<organization>Xylogics, Inc.</organization>

<address>
<postal>
<street>53 Third Avenue</street>
<city>Burlington</city>
<region>MA</region>
<code>01803</code>
<country>US</country>
</postal>

<phone>+1 617 272 8140</phone>
<email>gmalkin@Xylogics.COM</email>
</address>
</author>

<date year="1997" month="January" />
</front>

<seriesInfo value="2082" name="RFC" />
</reference>


<reference target2="reference.RFC.2083.xml" anchor="RFC2083">
<front>
<title abbrev="PNG: Portable Network Graphics">PNG (Portable Network Graphics) Specification Version 1.0</title>
<author fullname="Thomas Boutell" initials="T." surname="Boutell">
<organization>Boutell.Com, Inc.</organization>

<address>
<postal>
<street>PO Box 20837</street>
<city>Seattle</city>
<region>WA</region>
<code>98102</code>
<country>US</country>
</postal>

<phone>+1 206 329 4969</phone>
<email>boutell@boutell.com</email>
</address>
</author>

<date year="1997" month="March" />

<abstract>
<t>This document describes PNG (Portable Network Graphics), an extensible file format for the lossless, portable, well-compressed storage of raster images.  PNG provides a patent-free replacement for GIF and can also replace many common uses of TIFF.  Indexed-color, grayscale, and truecolor images are supported, plus an optional alpha channel.  Sample depths range from 1 to 16 bits.</t>

<t>PNG is designed to work well in online viewing applications, such as the World Wide Web, so it is fully streamable with a progressive display option.  PNG is robust, providing both full file integrity checking and simple detection of common transmission errors.  Also, PNG can store gamma and chromaticity data for improved color matching on heterogeneous platforms.</t>

<t>This specification defines the Internet Media Type image/png.</t>
</abstract>
</front>

<seriesInfo value="2083" name="RFC" />
</reference>


<reference target2="reference.RFC.2084.xml" anchor="RFC2084">
<front>
<title>Considerations for Web Transaction Security</title>
<author fullname="Greg Bossert" initials="G." surname="Bossert">
<organization>Silicon Graphics, Inc.</organization>

<address>
<postal>
<street>2011 North Shoreline Blvd.</street>
<street>MS 15-7</street>
<city>Mountain View</city>
<region>CA</region>
<code>94043-1389</code>
<country>US</country>
</postal>

<email>bossert@corp.sgi.com</email>
</address>
</author>

<author fullname="Simon Cooper" initials="S." surname="Cooper">
<organization>Silicon Graphics, Inc.</organization>

<address>
<postal>
<street>2011 North Shoreline Blvd.</street>
<street>MS 15-7</street>
<city>Mountain View</city>
<region>CA</region>
<code>94043-1389</code>
<country>US</country>
</postal>

<email>sc@corp.sgi.com</email>
</address>
</author>

<author fullname="Walt Drummond" initials="W." surname="Drummond">
<organization>Institute of Electrical and Electronics Engineers, Inc.</organization>

<address>
<postal>
<street>445 Hoes Lane</street>
<city>Piscataway</city>
<region>NJ</region>
<code>08855-1331</code>
<country>US</country>
</postal>

<phone>+1 908 562 6545</phone>
<facsimile>+1 908 562 1727</facsimile>
<email>drummond@ieee.org</email>
</address>
</author>

<date year="1997" month="January" />

<abstract>
<t>This document specifies the requirements for the provision of security services to the HyperText Transport Protocol.  These services include confidentiality, integrity, user authentication, and authentication of servers/services, including proxied or gatewayed services.  Such services may be provided as extensions to HTTP, or as    an encapsulating security protocol.  Secondary requirements include ease of integration and support of multiple mechanisms for providing these services.</t>
</abstract>
</front>

<seriesInfo value="2084" name="RFC" />
</reference>


<reference target2="reference.RFC.2085.xml" anchor="RFC2085">
<front>
<title abbrev="HMAC-MD5">HMAC-MD5 IP Authentication with Replay Prevention</title>
<author fullname="Michael J. Oehler" initials="M." surname="Oehler">
<organization>National Security Agency, INFOSEC Research and Development</organization>

<address>
<postal>
<street>9800 Savage Road</street>
<street>R23</street>
<city>Fort Meade</city>
<region>MD</region>
<code>20755</code>
<country>US</country>
</postal>

<email>mjo@tycho.ncsc.mil</email>
</address>
</author>

<author fullname="Robert Glenn" initials="R." surname="Glenn">
<organization>NIST</organization>

<address>
<postal>
<street>Building 820</street>
<street>Room 455</street>
<city>Gaithersburg</city>
<region>MD</region>
<code>20899</code>
<country>US</country>
</postal>

<email>rob.glenn@nist.gov</email>
</address>
</author>

<date year="1997" month="February" />

<abstract>
<t>This document describes a keyed-MD5 transform to be used in conjunction with the IP Authentication Header. The particular transform is based on.  An option is also specified to guard against replay attacks.</t>
</abstract>
</front>

<seriesInfo value="2085" name="RFC" />
</reference>


<reference target2="reference.RFC.2086.xml" anchor="RFC2086">
<front>
<title abbrev="ACL extension">IMAP4 ACL extension</title>
<author fullname="John G. Myers" initials="J." surname="Myers">
<organization>Carnegie-Mellon University</organization>

<address>
<postal>
<street>5000 Forbes Ave.</street>
<city>Pittsburgh</city>
<region>PA</region>
<code>15213-3890</code>
<country>US</country>
</postal>

<email>jgm+@cmu.edu</email>
</address>
</author>

<date year="1997" month="January" />

<abstract>
<t>The ACL extension of the Internet Message Access Protocolpermits access control lists to be manipulated through the IMAP protocol.</t>
</abstract>
</front>

<seriesInfo value="2086" name="RFC" />
</reference>


<reference target2="reference.RFC.2087.xml" anchor="RFC2087">
<front>
<title abbrev="QUOTA">IMAP4 QUOTA extension</title>
<author fullname="John G. Myers" initials="J." surname="Myers">
<organization>Carnegie-Mellon University</organization>

<address>
<postal>
<street>5000 Forbes Ave.</street>
<city>Pittsburgh</city>
<region>PA</region>
<code>15213-3890</code>
<country>US</country>
</postal>

<email>jgm+@cmu.edu</email>
</address>
</author>

<date year="1997" month="January" />

<abstract>
<t>The QUOTA extension of the Internet Message Access Protocolpermits administrative limits on resource usage (quotas) to be manipulated through the IMAP protocol.</t>
</abstract>
</front>

<seriesInfo value="2087" name="RFC" />
</reference>


<reference target2="reference.RFC.2088.xml" anchor="RFC2088">
<front>
<title abbrev="LITERAL">IMAP4 non-synchronizing literals</title>
<author fullname="John G. Myers" initials="J.G." surname="Myers">
<organization>Carnegie-Mellon University</organization>

<address>
<postal>
<street>5000 Forbes Ave.</street>
<city>Pittsburgh</city>
<region>PA</region>
<code>15213-3890</code>
<country>US</country>
</postal>

<email>jgm+@cmu.edu</email>
</address>
</author>

<date year="1997" month="January" />

<abstract>
<t>The Internet Message Access Protocolcontains the "literal" syntactic construct for communicating strings.  When sending a literal from client to server, IMAP4 requires the client to wait for the server to send a command continuation request between sending the octet count and the string data.  This document specifies an alternate form of literal which does not require this network round trip.</t>
</abstract>
</front>

<seriesInfo value="2088" name="RFC" />
</reference>


<reference target2="reference.RFC.2089.xml" anchor="RFC2089">
<front>
<title abbrev="V2toV1">V2ToV1 Mapping SNMPv2 onto SNMPv1 within a bi-lingual SNMP agent</title>
<author fullname="Bert Wijnen" initials="B." surname="Wijnen">
<organization>IBM International Operations</organization>

<address>
<postal>
<street>Watsonweg 2</street>
<street>1423 ND Uithoorn</street>
<country>NL</country>
</postal>

<phone>+31 79 3228316</phone>
<email>wijnen@vnet.ibm.com</email>
</address>
</author>

<author fullname="David Levi" initials="D." surname="Levi">
<organization>SNMP Research, Inc</organization>

<address>
<postal>
<street>3001 Kimberlin Heights Rd.</street>
<city>Knoxville</city>
<region>TN</region>
<code>37920-9716</code>
<country>US</country>
</postal>

<phone>+1 615 573 1434</phone>
<email>levi@snmp.com</email>
</address>
</author>

<date year="1997" month="January" />

<abstract>
<t>The goal of this memo is to document a common way of mapping an SNMPv2 response into an SNMPv1 response within a bi-lingual SNMP agent (one that supports both SNMPv1 and SNMPv2).</t>
</abstract>
</front>

<seriesInfo value="2089" name="RFC" />
</reference>


<reference target2="reference.RFC.2090.xml" anchor="RFC2090">
<front>
<title>TFTP Multicast Option</title>
<author fullname="A. Thomas Emberson" initials="A." surname="Emberson">
<organization>Lanworks Technologies, Inc.</organization>

<address>
<postal>
<street>2425 Skymark Avenue</street>
<city>Mississauga</city>
<region>Ontario</region>
<code>L4W 4Y6</code>
<country>CA</country>
</postal>

<phone>+1 905 238 5528</phone>
<email>tom@lanworks.com</email>
</address>
</author>

<date year="1997" month="February" />

<abstract>
<t>The Trivial File Transfer Protocolis a simple, lock-step, file transfer protocol which allows a client to get or put a file onto a remote host.</t>

<t>This document describes a new TFTP option. This new option will allow the multiple clients to receive the same file concurrently through the use of Multicast packets. The TFTP Option Extension mechanism is described in.</t>

<t>Often when similar computers are booting remotely they will each download the same image file. By adding multicast into the TFTP option  set,  two  or  more  computers  can  download  a  file concurrently, thus increasing network efficiency.</t>

<t>This document assumes that the reader is familiar with the terminology and notation of bothand.</t>
</abstract>
</front>

<seriesInfo value="2090" name="RFC" />
</reference>


<reference target2="reference.RFC.2091.xml" anchor="RFC2091">
<front>
<title abbrev="Trigger RIP">Triggered Extensions to RIP to Support Demand Circuits</title>
<author fullname="Gerry Meyer" initials="G." surname="Meyer">
<organization>Shiva</organization>

<address>
<postal>
<street>Stanwell Street</street>
<city>Edinburgh</city>
<region>Scotland</region>
<code>EH6 5NG</code>
<country>UK</country>
</postal>

<phone>+44 131 5549424</phone>
<facsimile>+44 131 4677749</facsimile>
<email>gerry@europe.shiva.com</email>
</address>
</author>

<author fullname="Steve Sherry" initials="S." surname="Sherry">
<organization>Xyplex</organization>

<address>
<postal>
<street>295 Foster St.</street>
<city>Littleton</city>
<region>MA</region>
<code>01460</code>
<country>US</country>
</postal>

<phone>+1 508 952 4745</phone>
<facsimile>+1 508 952 4887</facsimile>
<email>shs@xyplex.com</email>
</address>
</author>

<date year="1997" month="January" />

<abstract>
<t>This document defines a modification which can be applied to Bellman-Ford (distance vector) algorithm information broadcasting protocols - for example IP RIP, Netware RIP or Netware SAP - which makes it feasible to run them on connection oriented Public Data Networks.</t>

<t>This proposal has a number of efficiency advantages over the Demand RIP proposal (RFC 1582).</t>
</abstract>
</front>

<seriesInfo value="2091" name="RFC" />
</reference>


<reference target2="reference.RFC.2092.xml" anchor="RFC2092">
<front>
<title abbrev="Triggered RIP Protocol Analysis">Protocol Analysis for Triggered RIP</title>
<author fullname="Steve Sherry" initials="S." surname="Sherry">
<organization>Xyplex</organization>

<address>
<postal>
<street>295 Foster St.</street>
<city>Littleton</city>
<region>MA</region>
<code>01460</code>
<country>US</country>
</postal>

<phone>+1 508 952 4745</phone>
<facsimile>+1 508 952 4887</facsimile>
<email>shs@xyplex.com</email>
</address>
</author>

<author fullname="Gerry Meyer" initials="G." surname="Meyer">
<organization>Shiva Europe Ltd</organization>

<address>
<postal>
<street>Stanwell Street</street>
<city>Edinburgh</city>
<region>Scotland</region>
<code>EH6 5NG</code>
<country>UK</country>
</postal>

<phone>+44 131 5614223</phone>
<facsimile>+44 131 5614083</facsimile>
<email>gerry@europe.shiva.com</email>
</address>
</author>

<date year="1997" month="January" />

<abstract>
<t>As required by Routing Protocol Criteria, this report documents the key features of Triggered Extensions to RIP to Support Demand Circuitsand the current implementation experience.</t>

<t>As a result of the improved characteristics of Triggered RIP, it is proposed that Demand RIPbe obsoleted.</t>
</abstract>
</front>

<seriesInfo value="2092" name="RFC" />
</reference>


<reference target2="reference.RFC.2093.xml" anchor="RFC2093">
<front>
<title abbrev="GKMP Specification">Group Key Management Protocol (GKMP) Specification</title>
<author fullname="Hugh Harney" initials="H." surname="Harney">
<organization>SPARTA, Inc., Secure Systems Engineering Division</organization>

<address>
<postal>
<street>9861 Broken Land Parkway</street>
<street>Suite 300</street>
<city>Columbia</city>
<region>MD</region>
<code>21046-1170</code>
<country>US</country>
</postal>

<phone>+1 410 381 9400 x203</phone>
<email>hh@columbia.sparta.com</email>
</address>
</author>

<author fullname="Carl Muckenhirn" initials="C." surname="Muckenhirn">
<organization>SPARTA, Inc., Secure Systems Engineering Division</organization>

<address>
<postal>
<street>9861 Broken Land Parkway</street>
<street>Suite 300</street>
<city>Columbia</city>
<region>MD</region>
<code>21046-1170</code>
<country>US</country>
</postal>

<phone>+1 410 381 9400 x208</phone>
<email>cfm@columbia.sparta.com</email>
</address>
</author>

<date year="1997" month="July" />

<abstract>
<t>This specification proposes a protocol to create grouped symmetric keys and distribute them amongst communicating peers. This protocolhas the following advantages: 1) virtually invisible to operator, 2) no central key distribution site is needed, 3) only group members have the key, 4) sender or receiver oriented operation, 5) can make use of multicast communications protocols.</t>
</abstract>
</front>

<seriesInfo value="2093" name="RFC" />
</reference>


<reference target2="reference.RFC.2094.xml" anchor="RFC2094">
<front>
<title abbrev="GKMP Architecture">Group Key Management Protocol (GKMP) Architecture</title>
<author fullname="Hugh Harney" initials="H." surname="Harney">
<organization>SPARTA, Inc., Secure Systems Engineering Division</organization>

<address>
<postal>
<street>9861 Broken Land Parkway</street>
<street>Suite 300</street>
<city>Columbia</city>
<region>MD</region>
<code>21046-1170</code>
<country>US</country>
</postal>

<phone>+1 410 381 9400 x203</phone>
<email>hh@columbia.sparta.com</email>
</address>
</author>

<author fullname="Carl Muckenhirn" initials="C." surname="Muckenhirn">
<organization>SPARTA, Inc., Secure Systems Engineering Division</organization>

<address>
<postal>
<street>9861 Broken Land Parkway</street>
<street>Suite 300</street>
<city>Columbia</city>
<region>MD</region>
<code>21046-1170</code>
<country>US</country>
</postal>

<phone>+1 410 381 9400 x208</phone>
<email>cfm@columbia.sparta.com</email>
</address>
</author>

<date year="1997" month="July" />

<abstract>
<t>This specification proposes a protocol to create grouped symmetric keys and distribute them amongst communicating peers. This protocol has the following advantages: 
1) virtually invisible to operator, 
2) no central key distribution site is needed, 
3) only group members have the key, 
4) sender or receiver oriented operation, 
5) can make use of multicast communications protocols.</t>
</abstract>
</front>

<seriesInfo value="2094" name="RFC" />
</reference>


<reference target2="reference.RFC.2095.xml" anchor="RFC2095">
<front>
<title abbrev="IMAP/POP AUTHorize Extension">IMAP/POP AUTHorize Extension for Simple Challenge/Response</title>
<author fullname="John C. Klensin" initials="J." surname="Klensin">
<organization>MCI Telecommunications</organization>

<address>
<postal>
<street>800 Boylston St</street>
<street>7th floor</street>
<city>Boston</city>
<region>MA</region>
<code>02199</code>
<country>US</country>
</postal>

<phone>+1 617 960 1011</phone>
<email>klensin@mci.net</email>
</address>
</author>

<author fullname="Randy Catoe" initials="R." surname="Catoe">
<organization>MCI Telecommunications</organization>

<address>
<postal>
<street>2100 Reston Parkway</street>
<city>Reston</city>
<region>VA</region>
<code>22091</code>
<country>US</country>
</postal>

<phone>+1 703 715 7366</phone>
<email>randy@mci.net</email>
</address>
</author>

<author fullname="Paul Krumviede" initials="P." surname="Krumviede">
<organization>MCI Telecommunications</organization>

<address>
<postal>
<street>2100 Reston Parkway</street>
<city>Reston</city>
<region>VA</region>
<code>22091</code>
<country>US</country>
</postal>

<phone>+1 703 715 7251</phone>
<email>paul@mci.net</email>
</address>
</author>

<date year="1997" month="January" />

<abstract>
<t>While IMAP4 supports a number of strong authentication mechanisms as described in RFC 1731, it lacks any mechanism that neither passes cleartext, reusable passwords across the network nor requires either a significant security infrastructure or that the mail server update a mail-system-wide user authentication file on each mail access. This specification provides a simple challenge-response authentication protocol that is suitable for use with IMAP4.  Since it utilizes Keyed-MD5 digests and does not require that the secret be stored in the clear on the server, it may also constitute an improvement on APOP for POP3 use as specified in RFC 1734.</t>
</abstract>
</front>

<seriesInfo value="2095" name="RFC" />
</reference>


<reference target2="reference.RFC.2096.xml" anchor="RFC2096">
<front>
<title>IP Forwarding Table MIB</title>
<author fullname="Fred Baker" initials="F." surname="Baker">
<organization>Cisco Systems</organization>

<address>
<postal>
<street>519 Lado Drive</street>
<city>Santa Barbara</city>
<region>CA</region>
<code>93111</code>
<country>US</country>
</postal>

<phone>+1 805 681 0115</phone>
<email>fred@cisco.com</email>
</address>
</author>

<date year="1997" month="January" />
</front>

<seriesInfo value="2096" name="RFC" />
</reference>


<reference target2="reference.RFC.2097.xml" anchor="RFC2097">
<front>
<title abbrev="NBFCP">The PPP NetBIOS Frames Control Protocol (NBFCP)</title>
<author fullname="Gurdeep Singh Pall" initials="G." surname="Pall">
<organization>Microsoft Corporation</organization>

<address>
<postal>
<street>1 Microsoft Way</street>
<city>Redmond</city>
<region>WA</region>
<code>98052-6399</code>
<country>US</country>
</postal>

<email>gurdeep@microsoft.com</email>
</address>
</author>

<date year="1997" month="January" />

<abstract>
<t>The Point-to-Point Protocol (PPP)provides a standard method for transporting multi-protocol datagrams over point-to-point links.  PPP defines an extensible Link Control Protocol, and proposes a family of Network Control Protocols for establishing and configuring different network-layer protocols.</t>

<t>The NBF protocolwas originally called the NetBEUI protocol. This document defines the Network Control Protocol for establishing and configuring the NBF protocol over PPP.</t>

<t>The NBFCP protocol is only applicable for an end system to connect to a peer system or the LAN that peer system is connected to.  It is not applicable for connecting two LANs together due to NetBIOS name limitations and NetBIOS name defense mechanisms.</t>
</abstract>
</front>

<seriesInfo value="2097" name="RFC" />
</reference>


<reference target2="reference.RFC.2098.xml" anchor="RFC2098">
<front>
<title abbrev="Toshiba&apos;s Router Extension for ATM">Toshiba's Router Architecture Extensions for ATM : Overview</title>
<author fullname="Yasuhiro Katsube" initials="Y." surname="Katsube">
<organization>R&amp;D Center, Toshiba</organization>

<address>
<postal>
<street>1 Komukai Toshiba-cho</street>
<street>Saiwai-ku</street>
<street>Kawasaki</street>
<code>210</code>
<country>JP</country>
</postal>

<phone>+81 44 5492238</phone>
<email>katsube@isl.rdc.toshiba.co.jp</email>
</address>
</author>

<author fullname="Ken-ichi Nagami" initials="K." surname="Nagami">
<organization>R&amp;D Center, Toshiba</organization>

<address>
<postal>
<street>1 Komukai Toshiba-cho</street>
<street>Saiwai-ku</street>
<street>Kawasaki</street>
<code>210</code>
<country>JP</country>
</postal>

<phone>+81 44 5492238</phone>
<email>nagami@isl.rdc.toshiba.co.jp</email>
</address>
</author>

<author fullname="Hiroshi Esaki" initials="H." surname="Esaki">
<organization>R&amp;D Center, Toshiba</organization>

<address>
<postal>
<street>1 Komukai Toshiba-cho</street>
<street>Saiwai-ku</street>
<street>Kawasaki</street>
<code>210</code>
<country>JP</country>
</postal>

<phone>+81 44 5492238</phone>
<email>hiroshi@isl.rdc.toshiba.co.jp</email>
</address>
</author>

<date year="1997" month="February" />

<abstract>
<t>This memo describes a new internetworking architecture which makes better use of the property of ATM.  IP datagrams are transferred along hop-by-hop path via routers, but datagram assembly/disassembly and IP header processing are not necessarily carried out at individual routers in the proposed architecture.  A concept of "Cell Switch Router (CSR)" is introduced as a new internetworking equipment, which has ATM cell switching capabilities in addition to conventional IP datagram forwarding.  Proposed architecture can provide applications with high-throughput and low-latency ATM pipes while retaining current router-based internetworking concept.  It also provides applications with specific QoS/bandwidth by cooperating with internetworking level resource reservation protocols such as RSVP.</t>
</abstract>
</front>

<seriesInfo value="2098" name="RFC" />
</reference>


<reference target2="reference.RFC.2099.xml" anchor="RFC2099">
<front>
<title abbrev="Summary of 2000-2099">Request for Comments Summary RFC Numbers 2000-2099</title>
<author fullname="Josh Elliott" initials="J." surname="Elliott">
<organization>University of Southern California, Information Sciences Institute</organization>

<address>
<postal>
<street>4676 Admiralty Way</street>
<city>Marina del Rey</city>
<region>CA</region>
<code>90292</code>
<country>US</country>
</postal>

<phone>+1 310 822 1511</phone>
<email>elliott@isi.edu</email>
</address>
</author>

<date year="1997" month="March" />
</front>

<seriesInfo value="2099" name="RFC" />
</reference>


<reference target2="reference.RFC.2100.xml" anchor="RFC2100">
<front>
<title>The Naming of Hosts</title>
<author fullname="J. Ashworth" initials="J." surname="Ashworth">
<organization />
</author>

<date year="1997" day="1" month="April" />
</front>

<seriesInfo value="2100" name="RFC" />
<format octets="4077" type="TXT" target="ftp://ftp.isi.edu/in-notes/rfc2100.txt" />
</reference>


<reference target2="reference.RFC.2101.xml" anchor="RFC2101">
<front>
<title>IPv4 Address Behaviour Today</title>
<author fullname="Brian E. Carpenter" initials="B.E." surname="Carpenter">
<organization>Computing and Networks Division</organization>

<address>
<postal>
<street>CERN</street>
<street>European Laboratory for Particle Physics</street>
<street>1211 Geneva 23</street>
<country>Switzerland</country>
</postal>

<email>brian@dxcoms.cern.ch</email>
</address>
</author>

<author fullname="Jon Crowcroft" initials="J." surname="Crowcroft">
<organization>Dept. of Computer Science</organization>

<address>
<postal>
<street>University College London</street>
<street>London WC1E 6BT</street>
<country>UK</country>
</postal>

<email>j.crowcroft@cs.ucl.ac.uk</email>
</address>
</author>

<author fullname="Yakov Rekhter" initials="Y." surname="Rekhter">
<organization>Cisco systems</organization>

<address>
<postal>
<street>170 West Tasman Drive</street>
<street>San Jose</street>
<country>USA</country>
</postal>

<phone>+1 914 528 0090</phone>
<facsimile>+1 408 526-4952</facsimile>
<email>yakov@cisco.com</email>
</address>
</author>

<date year="1997" month="February" />
<area>Internet</area>
<keyword>internet protocol version 4</keyword>

<abstract>
<t>
   The main purpose of this note is to clarify the current
   interpretation of the 32-bit IP version 4 address space, whose
   significance has changed substantially since it was originally
   defined.  A short section on IPv6 addresses mentions the main points
   of similarity with, and difference from, IPv4.
</t>
</abstract>
</front>

<seriesInfo value="2101" name="RFC" />
<format octets="48254" type="HTML" target="http://xml.resource.org/public/rfc/html/rfc2101.html" />
<format octets="36172" type="XML" target="http://xml.resource.org/public/rfc/xml/rfc2101.xml" />
</reference>


<reference target2="reference.RFC.2102.xml" anchor="RFC2102">
<front>
<title abbrev="Nimrod Multicast">Multicast Support for Nimrod :  Requirements and Solution Approaches</title>
<author fullname="Ram Ramanathan" initials="R." surname="Ramanathan">
<organization>BBN Systems and Technologies</organization>

<address>
<postal>
<street>10 Moulton Street</street>
<street>Cambridge</street>
<street>MA 02138</street>
</postal>

<phone>(617) 873-2736</phone>
<email>ramanath@bbn.com</email>
</address>
</author>

<date year="1997" month="February" />
<area>Routing</area>
<keyword>Nimrod</keyword>
<keyword>multicast</keyword>
<keyword>routing</keyword>

<abstract>
<t>
   Nimrod does not specify a particular solution for multicasting.
   Rather, Nimrod may use any of a number of emerging multicast
   techniques.  We identify the requirements that Nimrod has of a
   solution for multicast support.  We compare existing approaches for
   multicasting within an internetwork and discuss their advantages and
   disadvantages.  Finally, as an example, we outline the mechanisms to
   support multicast in Nimrod using the scheme currently being
   developed within the IETF - namely, the Protocol Indpendent Multicast
   (PIM) protocol.
</t>
</abstract>
</front>

<seriesInfo value="2102" name="RFC" />
<format octets="65446" type="HTML" target="http://xml.resource.org/public/rfc/html/rfc2102.html" />
<format octets="53070" type="XML" target="http://xml.resource.org/public/rfc/xml/rfc2102.xml" />
</reference>


<reference target2="reference.RFC.2103.xml" anchor="RFC2103">
<front>
<title abbrev="Nimrod Mobility">Mobility Support for Nimrod: Challenges and Solution Approaches</title>
<author fullname="Ram Ramanathan" initials="R." surname="Ramanathan">
<organization>BBN Systems and Technologies</organization>

<address>
<postal>
<street>10 Moulton Street</street>
<street>Cambridge</street>
<street>MA 02138</street>
</postal>

<phone>(617) 873-2736</phone>
<email>ramanath@bbn.com</email>
</address>
</author>

<date year="1997" month="February" />
<area>Routing</area>
<keyword>Nimrod</keyword>
<keyword>routing</keyword>

<abstract>
<t>
   We discuss the issue of mobility in Nimrod.  While a mobility
   solution is not part of the Nimrod architecture, Nimrod does require
   that the solution have certain characteristics.  We identify the
   requirements that Nimrod has of any solution for mobility support.
   We also classify and compare existing approaches for supporting
   mobility within an internetwork and discuss their advantages and
   disadvantages.  Finally, as an example, we outline the mechanisms to
   support mobility in Nimrod using the scheme currently being developed
   within the IETF - namely, the Mobile-IP protocol.
</t>
</abstract>
</front>

<seriesInfo value="2103" name="RFC" />
<format octets="54313" type="HTML" target="http://xml.resource.org/public/rfc/html/rfc2103.html" />
<format octets="42343" type="XML" target="http://xml.resource.org/public/rfc/xml/rfc2103.xml" />
</reference>


<reference target2="reference.RFC.2104.xml" anchor="RFC2104">
<front>
<title abbrev="HMAC">HMAC: Keyed-Hashing for Message Authentication</title>
<author fullname="Hugo Krawczyk" initials="H." surname="Krawczyk">
<organization>IBM, T.J. Watson Research Center</organization>

<address>
<postal>
<street>P.O.Box 704</street>
<city>Yorktown Heights</city>
<region>NY</region>
<code>10598</code>
<country>US</country>
</postal>

<email>hugo@watson.ibm.com</email>
</address>
</author>

<author fullname="Mihir Bellare" initials="M." surname="Bellare">
<organization>University of California at San Diego, Dept of Computer Science and Engineering</organization>

<address>
<postal>
<street>9500 Gilman Drive</street>
<street>Mail Code 0114</street>
<city>La Jolla</city>
<region>CA</region>
<code>92093</code>
<country>US</country>
</postal>

<email>mihir@cs.ucsd.edu</email>
</address>
</author>

<author fullname="Ran Canetti" initials="R." surname="Canetti">
<organization>IBM T.J. Watson Research Center</organization>

<address>
<postal>
<street>P.O.Box 704</street>
<city>Yorktown Heights</city>
<region>NY</region>
<code>10598</code>
<country>US</country>
</postal>

<email>canetti@watson.ibm.com</email>
</address>
</author>

<date year="1997" month="February" />

<abstract>
<t>This document describes HMAC, a mechanism for message authentication using cryptographic hash functions. HMAC can be used with any iterative cryptographic hash function, e.g., MD5, SHA-1, in combination with a secret shared key.  The cryptographic strength of HMAC depends on the properties of the underlying hash function.</t>
</abstract>
</front>

<seriesInfo value="2104" name="RFC" />
</reference>


<reference target2="reference.RFC.2105.xml" anchor="RFC2105">
<front>
<title abbrev="Cisco Tag Switching">Cisco Systems&apos; Tag Switching Architecture Overview</title>
<author fullname="Yakov Rekhter" initials="Y." surname="Rekhter">
<organization>Cisco Systems, Inc.</organization>

<address>
<postal>
<street>170 Tasman Drive</street>
<street>San Jose</street>
<street>95134</street>
<country>CA</country>
</postal>

<email>yakov@cisco.com</email>
</address>
</author>

<author fullname="Bruce Davie" initials="B." surname="Davie">
<organization>Cisco Systems, Inc.</organization>

<address>
<postal>
<street>250 Apollo Drive</street>
<street>Chelmsford</street>
<street>01824</street>
<country>MA</country>
</postal>

<email>bsd@cisco.com</email>
</address>
</author>

<author fullname="Dave Katz" initials="D." surname="Katz">
<organization>Cisco Systems, Inc.</organization>

<address>
<postal>
<street>170 Tasman Drive</street>
<street>San Jose</street>
<street>95134</street>
<country>CA</country>
</postal>

<email>dkatz@cisco.com</email>
</address>
</author>

<author fullname="Eric Rosen" initials="E." surname="Rosen">
<organization>Cisco Systems, Inc.</organization>

<address>
<postal>
<street>250 Apollo Drive</street>
<street>Chelmsford</street>
<street>01824</street>
<country>MA</country>
</postal>

<email>erosen@cisco.com</email>
</address>
</author>

<author fullname="George Swallow" initials="G." surname="Swallow">
<organization>Cisco Systems, Inc.</organization>

<address>
<postal>
<street>250 Apollo Drive</street>
<street>Chelmsford</street>
<street>01824</street>
<country>MA</country>
</postal>

<email>swallow@cisco.com</email>
</address>
</author>

<date year="1997" month="February" />
<area>Routing</area>
<keyword>tag switching</keyword>

<abstract>
<t>
   This protocol is NOT the product of an IETF working group nor is it a
   standards track document.  It has not necessarily benefited from the
   widespread and in depth community review that standards track
   documents receive.
</t>

<t>
   This document provides an overview of a novel approach to network
   layer packet forwarding, called tag switching. The two main
   components of  the tag switching architecture - forwarding and
   control - are described.  Forwarding is accomplished using simple
   label-swapping techniques, while the existing network layer routing
   protocols plus mechanisms for binding and distributing tags are used
   for control. Tag switching can retain the scaling properties of IP,
   and can help improve the scalability of IP networks. While tag
   switching does not rely on ATM, it can straightforwardly be applied
   to ATM switches. A range of tag switching applications and deployment
   scenarios are described.
</t>
</abstract>

<note title="IESG Note">
<t>
   This protocol is NOT the product of an IETF working group nor is it a
   standards track document.  It has not necessarily benefited from the
   widespread and in depth community review that standards track
   documents receive.
</t>
</note>
</front>

<seriesInfo value="2105" name="RFC" />
<format octets="41786" type="HTML" target="http://xml.resource.org/public/rfc/html/rfc2105.html" />
<format octets="32767" type="XML" target="http://xml.resource.org/public/rfc/xml/rfc2105.xml" />
</reference>


<reference target2="reference.RFC.2106.xml" anchor="RFC2106">
<front>
<title abbrev="DLSRAP">Data Link Switching Remote Access Protocol</title>
<author fullname="Steve T. Chiang" initials="S.T." surname="Chiang">
<organization>InterWorks Business Unit</organization>

<address>
<postal>
<street>Cisco Systems</street>
<street>Inc.</street>
<street>170 Tasman Drive</street>
<street>San Jose</street>
<street>CA 95134</street>
</postal>

<phone>(408) 526-5189</phone>
<email>schiang@cisco.com</email>
</address>
</author>

<author fullname="Joseph S. Lee" initials="J.S." surname="Lee">
<organization>InterWorks Business Unit</organization>

<address>
<postal>
<street>Cisco Systems</street>
<street>Inc.</street>
<street>170 Tasman Drive</street>
<street>San Jose</street>
<street>CA 95134</street>
</postal>

<phone>(408) 526-5232</phone>
<email>jolee@cisco.com</email>
</address>
</author>

<author fullname="Hideaki Yasuda" initials="H." surname="Yasuda">
<organization>System Product Center</organization>

<address>
<postal>
<street>Network Products Department</street>
<street>Network Software Products Section B</street>
<street>Mitsubishi Electric Corp.</street>
<street>Information Systems Engineering Center</street>
<street>325</street>
<street>Kamimachiya Kamakura Kanagawa 247</street>
<country>Japan</country>
</postal>

<phone>+81-467-47-2120</phone>
<email>yasuda@eme068.cow.melco.co.jp</email>
</address>
</author>

<date year="1997" month="February" />
<area>Routing</area>
<keyword>DLSRAP</keyword>
<keyword>SNA/NetBIOS</keyword>
<keyword>data link</keyword>

<abstract>
<t>
   This memo describes the Data Link Switching Remote Access Protocol
   that is used between workstations and routers to transport SNA/
   NetBIOS traffic over TCP sessions. Any questions or comments should
   be sent to drap@cisco.com.
</t>
</abstract>
</front>

<seriesInfo value="2106" name="RFC" />
<format octets="52791" type="HTML" target="http://xml.resource.org/public/rfc/html/rfc2106.html" />
<format octets="41665" type="XML" target="http://xml.resource.org/public/rfc/xml/rfc2106.xml" />
</reference>


<reference target2="reference.RFC.2107.xml" anchor="RFC2107">
<front>
<title abbrev="ATMP">Ascend Tunnel Management Protocol - ATMP</title>
<author fullname="Kory Hamzeh" initials="K." surname="Hamzeh">
<organization>Ascend Communications</organization>

<address>
<postal>
<street>1275 Harbor Bay Parkway</street>
<street>Alameda</street>
<street>CA 94502</street>
</postal>

<email>kory@ascend.com</email>
</address>
</author>

<date year="1997" month="February" />
<area>Routing</area>
<keyword>tunnel</keyword>
<keyword>dial-in</keyword>

<abstract>
<t>
   This note documents a private protocol for tunnel management.  This
   protocol is NOT the product of an IETF working group nor is it a
   standards track document. There is ongoing effort in an IETF working
   group which could result in a standards track document which
   specifies a protocol which provides similar functionality.
</t>

<t>
   This document specifies a generic tunnel management protocol that
   allows remote dial-in users to access their home network as if they
   were directly attached to the home network.  The user&apos;s client
   software uses an address contained in the home network address space
   for the remote access.  Packets to and from the home network are
   tunneled by the Network Access Server (NAS) to which the user
   connects and a Home Agent (HA) on the user&apos;s home network.  This
   allows for the support of access to Virtual Private Networks and also
   allows for the use of protocols other than IP to be carried over the
   tunnel.  An example of how the RADIUS (Remote Authentication Dial In
   User Service) can be used to provide the necessary configuration
   information to support this service is also provided.
</t>
</abstract>

<note title="IESG Note">
<t>
   This note documents a private protocol for tunnel management.  This
   protocol is NOT the product of an IETF working group nor is it a
   standards track document. There is ongoing effort in an IETF working
   group which could result in a standards track document which
   specifies a protocol which provides similar functionality.
</t>
</note>
</front>

<seriesInfo value="2107" name="RFC" />
<format octets="57690" type="HTML" target="http://xml.resource.org/public/rfc/html/rfc2107.html" />
<format octets="47648" type="XML" target="http://xml.resource.org/public/rfc/xml/rfc2107.xml" />
</reference>


<reference target2="reference.RFC.2108.xml" anchor="RFC2108">
<front>
<title abbrev="802.3 MIB">Definitions of Managed Objects for IEEE 802.3 Repeater Devices using SMIv2</title>
<author fullname="Kathryn de Graaf" initials="K." surname="de Graaf">
<organization>3Com Corporation</organization>

<address>
<postal>
<street>Southborough</street>
<street>MA 01772</street>
<country>USA</country>
</postal>

<phone>(508)229-1627</phone>
<facsimile>(508)490-5882</facsimile>
<email>kdegraaf@isd.3com.com</email>
<uri>pike</uri>
</address>
</author>

<author fullname="Dan Romascanu" initials="D." surname="Romascanu">
<organization>Madge Networks (Israel) Ltd.</organization>

<address>
<postal>
<street>Atidim Technology Park</street>
<street>Bldg. 3</street>
</postal>

<phone>972-3-6458414, 6458458</phone>
<facsimile>972-3-6487146</facsimile>
<email>dromasca@madge.com</email>
</address>
</author>

<author fullname="Donna McMaster" initials="D." surname="McMaster">
<organization>Cisco Systems Inc.</organization>

<address>
<postal>
<street>170 West Tasman Drive</street>
<street>San Jose</street>
<street>CA 95134</street>
</postal>

<phone>(408) 526-5260</phone>
<email>mcmaster@cisco.com</email>
</address>
</author>

<author fullname="Keith McCloghrie" initials="K." surname="McCloghrie">
<organization>Cisco Systems Inc.</organization>

<address>
<postal>
<street>170 West Tasman Drive</street>
<street>San Jose</street>
<street>CA 95134</street>
</postal>

<phone>(408) 526-5260</phone>
<email>kzm@cisco.com</email>
</address>
</author>

<date year="1997" month="February" />
<area>Management</area>
<keyword>IEEE 802.3</keyword>
<keyword>Institute of Electrical and Electronics Engineers</keyword>
<keyword>Management Information Base</keyword>
<keyword>ethernet</keyword>
<keyword>managed object</keyword>
<keyword>structure of management information version 2</keyword>

<abstract>
<t>
   This memo defines a portion of the Management Information Base (MIB)
   for use with network management protocols in the Internet community.
   In particular, it defines objects for managing IEEE 802.3 10 and 100
   Mb/second baseband repeaters based on IEEE Std 802.3 Section 30, &quot;10
   &amp; 100 Mb/s Management,&quot; October 26, 1995.
</t>
</abstract>
</front>

<seriesInfo value="2108" name="RFC" />
<format octets="176918" type="HTML" target="http://xml.resource.org/public/rfc/html/rfc2108.html" />
<format octets="161587" type="XML" target="http://xml.resource.org/public/rfc/xml/rfc2108.xml" />
</reference>


<reference target2="reference.RFC.2109.xml" anchor="RFC2109">
<front>
<title>HTTP State Management Mechanism</title>
<author fullname="David M. Kristol" initials="D.M." surname="Kristol">
<organization>Bell Laboratories, Lucent Technologies</organization>

<address>
<postal>
<street>600 Mountain Ave.  Room 2A-227</street>
<street>Murray Hill</street>
<street>NJ  07974</street>
</postal>

<phone>(908) 582-2250</phone>
<facsimile>(908) 582-5809</facsimile>
<email>dmk@bell-labs.com</email>
</address>
</author>

<author fullname="Lou Montulli" initials="L." surname="Montulli">
<organization>Netscape Communications Corp.</organization>

<address>
<postal>
<street>501 E. Middlefield Rd.</street>
<street>Mountain View</street>
<street>CA  94043</street>
</postal>

<phone>(415) 528-2600</phone>
<email>montulli@netscape.com</email>
</address>
</author>

<date year="1997" month="February" />
<keyword>cookie</keyword>
<keyword>hypertext transfer protocol</keyword>
</front>

<seriesInfo value="2109" name="RFC" />
<format octets="60359" type="HTML" target="http://xml.resource.org/public/rfc/html/rfc2109.html" />
<format octets="47217" type="XML" target="http://xml.resource.org/public/rfc/xml/rfc2109.xml" />
</reference>


<reference target2="reference.RFC.2110.xml" anchor="RFC2110">
<front>
<title abbrev="MHTML">MIME E-mail Encapsulation of Aggregate Documents, such as HTML (MHTML)</title>
<author fullname="Jacob Palme" initials="J." surname="Palme">
<organization>Stockholm University and KTH</organization>

<address>
<postal>
<street>Electrum 230</street>
<street>S-164 40 Kista</street>
<country>Sweden</country>
</postal>

<phone>+46-8-16 16 67</phone>
<facsimile>+46-8-783 08 29</facsimile>
<email>jpalme@dsv.su.se</email>
</address>
</author>

<author fullname="Alex Hopmann" initials="A." surname="Hopmann">
<organization>Microsoft Corporation</organization>

<address>
<postal>
<street>3590 North First Street</street>
<street>Suite 300</street>
<street>San Jose</street>
<street>CA 95134</street>
<street>Working group chairman:</street>
</postal>

<email>alexhop@microsoft.com</email>
</address>
</author>

<date year="1997" month="March" />
<area>Applications</area>
<keyword>encapsulate</keyword>
<keyword>hypertext markup language</keyword>
<keyword>mail</keyword>
<keyword>multipurpose internet mail extensions</keyword>

<abstract>
<t>
   Although HTML [RFC 1866] was designed within the context of MIME,
   more than the specification of HTML as defined in RFC 1866 is needed
   for two electronic mail user agents to be able to interoperate using
   HTML as a document format. These issues include the naming of objects
   that are normally referred to by URIs, and the means of aggregating
   objects that go together. This document describes a set of guidelines
   that will allow conforming mail user agents to be able to send,
   deliver and display these objects, such as HTML objects, that can
   contain links represented by URIs. In order to be able to handle
   inter-linked objects, the document uses the MIME type
   multipart/related and specifies the MIME content-headers &quot;Content-
   Location&quot; and &quot;Content-Base&quot;.
</t>
</abstract>
</front>

<seriesInfo value="2110" name="RFC" />
<format octets="64532" type="HTML" target="http://xml.resource.org/public/rfc/html/rfc2110.html" />
<format octets="45426" type="XML" target="http://xml.resource.org/public/rfc/xml/rfc2110.xml" />
</reference>


<reference target2="reference.RFC.2111.xml" anchor="RFC2111">
<front>
<title abbrev="CID and MID URLs">Content-ID and Message-ID Uniform Resource Locators</title>
<author fullname="Edward Levinson" initials="E." surname="Levinson">
<organization />

<address>
<postal>
<street>47 Clive Street</street>
<street>Metuchen</street>
<street>NJ  08840-1060</street>
<country>USA</country>
</postal>

<phone>+1 908 549 3716</phone>
<email>XIson@cnj.digex.net</email>
</address>
</author>

<date year="1997" month="March" />
<area>Applications</area>
<keyword>content-type</keyword>
<keyword>encapsulate</keyword>
<keyword>hypertext markup language</keyword>
<keyword>multipurpose internet mail extensions</keyword>
<keyword>uniform resource</keyword>

<abstract>
<t>
   The Uniform Resource Locator (URL) schemes, &quot;cid:&quot; and &quot;mid:&quot; allow
   references to messages and the body parts of messages.  For example,
   within a single multipart message, one HTML body part might include
   embedded references to other parts of the same message.
</t>
</abstract>
</front>

<seriesInfo value="2111" name="RFC" />
<format octets="22894" type="HTML" target="http://xml.resource.org/public/rfc/html/rfc2111.html" />
<format octets="11466" type="XML" target="http://xml.resource.org/public/rfc/xml/rfc2111.xml" />
</reference>


<reference target2="reference.RFC.2112.xml" anchor="RFC2112">
<front>
<title abbrev="MIME Multipart/Related Content-type">The MIME Multipart/Related Content-type</title>
<author fullname="Edward Levinson" initials="E." surname="Levinson">
<organization>XIson, Inc.</organization>

<address>
<postal>
<street>47 Clive Street</street>
<street>Metuchen</street>
<street>NJ  08840-1060</street>
<country>USA</country>
</postal>

<phone>+1 908 549 3716</phone>
<email>XIson@cnj.digex.com</email>
</address>
</author>

<date year="1997" month="March" />
<keyword>MIME</keyword>
<keyword>content-type</keyword>
<keyword>multipurpose internet mail extensions</keyword>

<abstract>
<t>
   The Multipart/Related content-type provides a common mechanism for
   representing objects that are aggregates of related MIME body parts.
   This document defines the Multipart/Related content-type and provides
   examples of its use.
</t>
</abstract>
</front>

<seriesInfo value="2112" name="RFC" />
<format octets="32722" type="HTML" target="http://xml.resource.org/public/rfc/html/rfc2112.html" />
<format octets="20044" type="XML" target="http://xml.resource.org/public/rfc/xml/rfc2112.xml" />
</reference>


<reference target2="reference.RFC.2113.xml" anchor="RFC2113">
<front>
<title abbrev="Router Alert Option">IP Router Alert Option</title>
<author fullname="Dave Katz" initials="D." surname="Katz">
<organization>cisco Systems</organization>

<address>
<postal>
<street>170 W. Tasman Dr.</street>
<street>San Jose</street>
<street>CA  95134-1706</street>
<country>USA</country>
</postal>

<phone>+1 408 526 8284</phone>
<email>dkatz@cisco.com</email>
</address>
</author>

<date year="1997" month="February" />
<area>Routing</area>
<keyword>alert</keyword>
<keyword>router</keyword>
<keyword>routing</keyword>

<abstract>
<t>
   This memo describes a new IP Option type that alerts transit routers
   to more closely examine the contents of an IP packet.  This is useful
   for, but not limited to, new protocols that are addressed to a
   destination but require relatively complex processing in routers
   along the path.
</t>
</abstract>
</front>

<seriesInfo value="2113" name="RFC" />
<format octets="19673" type="HTML" target="http://xml.resource.org/public/rfc/html/rfc2113.html" />
<format octets="8939" type="XML" target="http://xml.resource.org/public/rfc/xml/rfc2113.xml" />
</reference>


<reference target2="reference.RFC.2114.xml" anchor="RFC2114">
<front>
<title abbrev="Data Link Switching Client">Data Link Switching Client Access Protocol</title>
<author fullname="Steve T. Chiang" initials="S.T." surname="Chiang">
<organization>InterWorks Business Unit</organization>

<address>
<postal>
<street>Cisco Systems</street>
<street>Inc.</street>
<street>170 Tasman Drive</street>
<street>San Jose</street>
<street>CA 95134</street>
</postal>

<phone>(408) 526-5189</phone>
<email>schiang@cisco.com</email>
</address>
</author>

<author fullname="Joseph S. Lee" initials="J.S." surname="Lee">
<organization>InterWorks Business Unit</organization>

<address>
<postal>
<street>Cisco Systems</street>
<street>Inc.</street>
<street>170 Tasman Drive</street>
<street>San Jose</street>
<street>CA 95134</street>
</postal>

<phone>(408) 526-5232</phone>
<email>jolee@cisco.com</email>
</address>
</author>

<author fullname="Hideaki Yasuda" initials="H." surname="Yasuda">
<organization>System Product Center</organization>

<address>
<postal>
<street>Network Products Department</street>
<street>Network Software Products Section B</street>
<street>Mitsubishi Electric Corp.</street>
<street>Information Systems Engineering Center</street>
<street>325</street>
<street>Kamimachiya Kamakura Kanagawa 247</street>
<country>Japan</country>
</postal>

<phone>+81-467-47-2120</phone>
<email>yasuda@eme068.cow.melco.co.jp</email>
</address>
</author>

<date year="1997" month="February" />
<area>Routing</area>
<keyword>data link</keyword>

<abstract>
<t>
   This memo describes the Data Link Switching Client Access Protocol
   that is used between workstations and routers to transport SNA/
   NetBIOS traffic over TCP sessions. Any questions or comments should
   be sent to dcap@cisco.com.
</t>
</abstract>
</front>

<seriesInfo value="2114" name="RFC" />
<format octets="62012" type="HTML" target="http://xml.resource.org/public/rfc/html/rfc2114.html" />
<format octets="50432" type="XML" target="http://xml.resource.org/public/rfc/xml/rfc2114.xml" />
</reference>


<reference target2="reference.RFC.2115.xml" anchor="RFC2115">
<front>
<title abbrev="Frame Relay DTE MIB">Management Information Base for Frame Relay DTEs Using SMIv2</title>
<author fullname="Caralyn Brown" initials="C." surname="Brown">
<organization>Cadia Networks, Inc.</organization>

<address>
<postal>
<street>1 Corporate Dirve</street>
<street>Andover</street>
<street>Massachusetts  01810</street>
</postal>

<phone>ephone:  +1 508 689 2400 x133</phone>
<email>cbrown@cadia.com</email>
</address>
</author>

<author fullname="Fred Baker" initials="F." surname="Baker">
<organization>Cisco Systems</organization>

<address>
<postal>
<street>519 Lado Drive</street>
<street>Santa Barbara</street>
<street>California 93111</street>
</postal>

<phone>ephone  +1 408 526 4257</phone>
<email>fred@cisco.com</email>
</address>
</author>

<date year="1997" month="September" />
<area>Management</area>
<keyword>Management Information Base</keyword>
<keyword>frame relay</keyword>
<keyword>structure of management information version 2</keyword>
</front>

<seriesInfo value="2115" name="RFC" />
<format octets="72106" type="HTML" target="http://xml.resource.org/public/rfc/html/rfc2115.html" />
<format octets="59658" type="XML" target="http://xml.resource.org/public/rfc/xml/rfc2115.xml" />
</reference>


<reference target2="reference.RFC.2116.xml" anchor="RFC2116">
<front>
<title>X.500 Implementations Catalog-96</title>
<author fullname="Chris Apple" initials="C." surname="Apple">
<organization>AT &amp; T Laboratories</organization>

<address>
<postal>
<street>600 Mountain Ave.</street>
<street>Room 2D-104</street>
<city>Murray Hill</city>
<region>NJ</region>
<code>07974</code>
<country>US</country>
</postal>

<phone>+1 908 582 2409</phone>
<facsimile>+1 908 582 6113</facsimile>
<email>capple@master.control.att.com</email>
</address>
</author>

<author fullname="Ken Rossen" initials="K." surname="Rossen">
<organization>MCI Systemhouse, Inc</organization>

<address>
<postal>
<street>10 Williamsville Road</street>
<city>Hubbardston Center</city>
<region>MA</region>
<code>01452-1311</code>
<country>US</country>
</postal>

<phone>+1 508 928 5368</phone>
<facsimile>+1 508 928 5399</facsimile>
<email>kenr@shl.com</email>
</address>
</author>

<date year="1997" month="April" />

<abstract>
<t>This document is a revision to: A Revised Catalog of Available X.500 Implementations and is based on the results of data collection via a WWW home page that enabled implementors to submit new or updated descriptions of currently available implementations of  X.500, including commercial products and openly available offerings.
   [RFC 1632] is a revision of. We contacted each contributor to [RFC 1632] to request an update and published the URL of the WWW home page survey template in several mailing lists to encourage the submission of new product descriptions.</t>

<t>This document contains detailed description of 31 X.500 implementations - DSAs, DUAs, and DUA interfaces.</t>
</abstract>
</front>

<seriesInfo value="2116" name="RFC" />
</reference>


<reference target2="reference.RFC.2117.xml" anchor="RFC2117">
<front>
<title abbrev="PIM-SM">Protocol Independent Multicast-Sparse Mode (PIM-SM): Protocol Specification</title>
<author fullname="Deborah Estrin" initials="D." surname="Estrin">
<organization>University of Southern Calif., Los Angeles, Computer Science Dept/ISI</organization>

<address>
<postal>
<street />
<city>Los Angeles</city>
<region>CA</region>
<code>90089</code>
<country>US</country>
</postal>

<email>estrin@usc.edu</email>
</address>
</author>

<author fullname="Dino Farinacci" initials="D." surname="Farinacci">
<organization>Cisco Systems Inc.</organization>

<address>
<postal>
<street>170 West Tasman Drive</street>
<city>San Jose</city>
<region>CA</region>
<code>95134</code>
<country>US</country>
</postal>

<email>dino@cisco.com</email>
</address>
</author>

<author fullname="Ahmed Helmy" initials="A." surname="Helmy">
<organization>University of Southern Calif., Los Angeles, CA , Computer Science Dept.</organization>

<address>
<postal>
<street />
<city>Los Angeles</city>
<region>CA</region>
<code>90089</code>
<country>US</country>
</postal>

<email>ahelmy@catarina.usc.edu</email>
</address>
</author>

<author fullname="David Thaler" initials="D." surname="Thaler">
<organization>University of Michigan,  EECS Department</organization>

<address>
<postal>
<street />
<city>Ann Arbor</city>
<region>MI</region>
<code>48109</code>
<country>US</country>
</postal>

<email>thalerd@eecs.umich.edu</email>
</address>
</author>

<author fullname="Stephen Deering" initials="S." surname="Deering">
<organization>Xerox PARC</organization>

<address>
<postal>
<street>3333 Coyote Hill Road</street>
<city>Palo Alto</city>
<region>CA</region>
<code>94304</code>
<country>US</country>
</postal>

<email>deering@parc.xerox.com</email>
</address>
</author>

<author fullname="Mark Handley" initials="M." surname="Handley">
<organization>University College London,  Department of Computer Science</organization>

<address>
<postal>
<street>Gower Street</street>
<city>London</city>
<region>England</region>
<code>WC1E 6BT</code>
<country>UK</country>
</postal>

<email>m.handley@cs.ucl.ac.uk</email>
</address>
</author>

<author fullname="Van Jacobson" initials="V." surname="Jacobson">
<organization>Lawrence Berkeley Laboratory</organization>

<address>
<postal>
<street>1 Cyclotron Road</street>
<city>Berkeley</city>
<region>CA</region>
<code>94720</code>
<country>US</country>
</postal>

<email>van@ee.lbl.gov</email>
</address>
</author>

<author fullname="Ching-gung  Liu" initials="C." surname="Liu">
<organization>University of Southern Calif., Los Angeles, Computer Science Dept.</organization>

<address>
<postal>
<street />
<city>Los Angeles</city>
<region>CA</region>
<code>90089</code>
<country>US</country>
</postal>

<email>charley@catarina.usc.edu</email>
</address>
</author>

<author fullname="Puneet Sharma" initials="P." surname="Sharma">
<organization>University of Southern Calif., Los Angeles, Computer Science Dept.</organization>

<address>
<postal>
<street />
<city>Los Angeles</city>
<region>CA</region>
<code>90089</code>
<country>US</country>
</postal>

<email>puneet@catarina.usc.edu</email>
</address>
</author>

<author fullname="Liming Wei" initials="L." surname="Wei">
<organization>Cisco Systems Inc.</organization>

<address>
<postal>
<street>170 West Tasman Drive</street>
<city>San Jose</city>
<region>CA</region>
<code>95134</code>
<country>US</country>
</postal>

<email>lwei@cisco.com</email>
</address>
</author>

<date year="1997" month="June" />

<abstract>
<t></t>
</abstract>
</front>

<seriesInfo value="2117" name="RFC" />
</reference>


<reference target2="reference.RFC.2118.xml" anchor="RFC2118">
<front>
<title abbrev="MPPC">Microsoft Point-To-Point Compression (MPPC) Protocol</title>
<author fullname="Gurdeep Singh Pall" initials="G.S." surname="Pall">
<organization>1, Microsoft Way,</organization>

<address>
<postal>
<street>Redmond</street>
<street>WA 98052</street>
</postal>

<email>gurdeep@microsoft.com</email>
</address>
</author>

<date year="1997" month="March" />
<area>Internet</area>
<keyword>compress</keyword>
<keyword>encapsulate</keyword>
<keyword>point-to-point protocol</keyword>

<abstract>
<t>
   The Point-to-Point Protocol (PPP)  provides a standard method for
   transporting multi-protocol datagrams over point-to-point links.
</t>

<t>
   The PPP Compression Control Protocol  provides a method to
   negotiate and utilize compression protocols over PPP encapsulated
   links.
</t>

<t>
   This document describes the use of the Microsoft Point to Point
   Compression protocol (also referred to as MPPC in this document) for
   compressing PPP encapsulated packets.
</t>
</abstract>
</front>

<seriesInfo value="2118" name="RFC" />
<format octets="27532" type="HTML" target="http://xml.resource.org/public/rfc/html/rfc2118.html" />
<format octets="17720" type="XML" target="http://xml.resource.org/public/rfc/xml/rfc2118.xml" />
</reference>


<reference target2="reference.RFC.2119.xml" anchor="RFC2119">
<front>
<title abbrev="RFC Key Words">Key words for use in RFCs to Indicate Requirement Levels</title>
<author fullname="Scott Bradner" initials="S." surname="Bradner">
<organization>Harvard University</organization>

<address>
<postal>
<street>1350 Mass. Ave.</street>
<street>Cambridge</street>
<street>MA 02138</street>
</postal>

<phone>- +1 617 495 3864</phone>
<email>sob@harvard.edu</email>
</address>
</author>

<date year="1997" month="March" />
<area>General</area>
<keyword>keyword</keyword>

<abstract>
<t>
   In many standards track documents several words are used to signify
   the requirements in the specification.  These words are often
   capitalized.  This document defines these words as they should be
   interpreted in IETF documents.  Authors who follow these guidelines
   should incorporate this phrase near the beginning of their document:

<list>
<t>
      The key words &quot;MUST&quot;, &quot;MUST NOT&quot;, &quot;REQUIRED&quot;, &quot;SHALL&quot;, &quot;SHALL
      NOT&quot;, &quot;SHOULD&quot;, &quot;SHOULD NOT&quot;, &quot;RECOMMENDED&quot;,  &quot;MAY&quot;, and
      &quot;OPTIONAL&quot; in this document are to be interpreted as described in
      RFC 2119.
</t>
</list>
</t>

<t>
   Note that the force of these words is modified by the requirement
   level of the document in which they are used.
</t>
</abstract>
</front>

<seriesInfo value="14" name="BCP" />
<seriesInfo value="2119" name="RFC" />
<format octets="14486" type="HTML" target="http://xml.resource.org/public/rfc/html/rfc2119.html" />
<format octets="5661" type="XML" target="http://xml.resource.org/public/rfc/xml/rfc2119.xml" />
</reference>


<reference target2="reference.RFC.2120.xml" anchor="RFC2120">
<front>
<title abbrev="X.500 Root Naming">Managing the X.500 Root Naming Context</title>
<author fullname="D W Chadwick" initials="D.W." surname="Chadwick">
<organization>IT Institute</organization>

<address>
<postal>
<street>University of Salford</street>
<street>Salford</street>
<street>M5 4WT</street>
<street>England</street>
</postal>

<phone>+44 161 745 5351</phone>
<facsimile>+44 161 745 8169</facsimile>
<email>D.W.Chadwick@iti.salford.ac.uk</email>
</address>
</author>

<date year="1997" month="March" />
<area>Applications</area>
<keyword>X.500</keyword>
<keyword>ITU abstract syntax notation one</keyword>
<keyword>ITU directory service protocol</keyword>

<abstract>
<t>
   The X.500 Standard  has the concept of first level DSAs,
   whose administrators must collectively manage the root naming context
   through bi-lateral agreements or other private means which are
   outside the scope of the X.500 Standard.
</t>

<t>
   The NameFLOW-Paradise X.500 service has an established procedure for
   managing the root naming context, which currently uses Quipu
   proprietary replication mechanisms and a root DSA. The benefits that
   derive from this are twofold:

<list>
<t>
      - firstly it is much easier to co-ordinate the management of the
      root context information, when there is a central point of
      administration,
</t>

<t>
      - secondly the performance of one-level Search operations is
      greatly improved because the Quipu distribution and replication
      mechanism does not have a restriction that exists in the 1988 and
      1993 X.500 Standard.
</t>
</list>
</t>

<t>
   The NameFLOW-Paradise project is moving towards 1993 ISO X.500
   Standard replication protocols and wants to standardise the protocol
   and procedure for managing the root naming context which will be
   based on 1993 X.500 Standard protocols. Such a protocol and procedure
   will be useful to private X.500 domains as well as to the Internet
   X.500 public domain. It is imperative that overall system performance
   is not degraded by this transition.
</t>

<t>
   This document describes the use of 1993 ISO X.500 Standard protocols
   for managing the root context. Whilst the ASN.1 is compatible with
   that of the X.500 Standard, the actual settings of the parameters are
   supplementary to that of the X.500 Standard.
</t>
</abstract>
</front>

<seriesInfo value="2120" name="RFC" />
<format octets="36000" type="HTML" target="http://xml.resource.org/public/rfc/html/rfc2120.html" />
<format octets="23829" type="XML" target="http://xml.resource.org/public/rfc/xml/rfc2120.xml" />
</reference>


<reference target2="reference.RFC.2121.xml" anchor="RFC2121">
<front>
<title abbrev="MARS Cluster Size">Issues affecting MARS Cluster Size</title>
<author fullname="Grenville Armitage" initials="G." surname="Armitage">
<organization>Bellcore, 445 South Street</organization>

<address>
<postal>
<street>Morristown</street>
<street>NJ</street>
<street>07960</street>
<country>USA</country>
</postal>

<phone>+1 201 829 2635</phone>
<email>gja@thumper.bellcore.com</email>
</address>
</author>

<date year="1997" month="March" />
<area>Internet</area>
<keyword>MARS</keyword>
<keyword>multicast</keyword>
<keyword>non-broadcast multiple access</keyword>

<abstract>
<t>
   IP multicast over ATM currently uses the MARS model  to manage the
   use of ATM pt-mpt SVCs for IP multicast packet forwarding. The scope
   of any given MARS services is the MARS Cluster - typically the same
   as an IPv4 Logical IP Subnet (LIS). Current IP/ATM networks are
   usually architected with unicast routing and forwarding issues
   dictating the sizes of individual LISes. However, as IP multicast is
   deployed as a service, the size of a LIS will only be as big as a
   MARS Cluster can be. This document provides a qualitative look at the
   issues constraining a MARS Cluster&apos;s size, including the impact of VC
   limits in switches and NICs, geographical distribution of cluster
   members, and the use of VC Mesh or MCS modes to support multicast
   groups.
</t>
</abstract>
</front>

<seriesInfo value="2121" name="RFC" />
<format octets="38854" type="HTML" target="http://xml.resource.org/public/rfc/html/rfc2121.html" />
<format octets="27815" type="XML" target="http://xml.resource.org/public/rfc/xml/rfc2121.xml" />
</reference>


<reference target2="reference.RFC.2122.xml" anchor="RFC2122">
<front>
<title abbrev="VEMMI">VEMMI URL Specification</title>
<author fullname="Daniel Mavrakis" initials="D." surname="Mavrakis">
<organization>Monaco</organization>

<address>
<postal>
<street>P.O. Box 225</street>
<street>MC 98004 Monte-Carlo Cedex</street>
<street>PRINCIPALITY OF</street>
<country>MONACO</country>
</postal>

<phone>(+377) 9216 8860</phone>
<facsimile>(+377) 9330 4545</facsimile>
<email>Mavrakis@mctel.fr</email>
</address>
</author>

<author fullname="Mr. Herve Layec" initials="M.H." surname="Layec">
<organization>ETSI STC TE1</organization>

<address>
<postal>
<street>06921 SOPHIA ANTIPOLIS Cedex</street>
<country>FRANCE</country>
</postal>

<phone>(+33) 2 99 12 73 01</phone>
<facsimile>(+33) 2 99 38 49 61</facsimile>
<email>herve.layec@dri.france-telecom.fr</email>
</address>
</author>

<author fullname="Mr. Kurt Kartmann" initials="M.K." surname="Kartmann">
<organization>Consulting</organization>

<address>
<postal>
<street>Gabelsbergerstr. 2</street>
<street>D-64807 DIEBURG</street>
<country>GERMANY</country>
</postal>

<phone>. (+49)6151 834965, Fax (+49) 6151 834284</phone>
<email>k.kartmann@t-online.de</email>
</address>
</author>

<date year="1997" month="March" />
<keyword>VEMMI</keyword>
<keyword>multimedia</keyword>
<keyword>uniform resource</keyword>
</front>

<seriesInfo value="2122" name="RFC" />
<format octets="36335" type="HTML" target="http://xml.resource.org/public/rfc/html/rfc2122.html" />
<format octets="25657" type="XML" target="http://xml.resource.org/public/rfc/xml/rfc2122.xml" />
</reference>


<reference target2="reference.RFC.2123.xml" anchor="RFC2123">
<front>
<title abbrev="NeTraMet">Traffic Flow Measurement:  Experiences with NeTraMet</title>
<author fullname="Nevil Brownlee" initials="N." surname="Brownlee">
<organization>The University of Auckland</organization>

<address>
<phone>+64 9 373 7599 x8941</phone>
<email>n.brownlee@auckland.ac.nz</email>
</address>
</author>

<date year="1997" month="March" />
<area>Operations</area>
<keyword>flow measurement</keyword>

<abstract>
<t>
   This memo records experiences in implementing and using the Traffic
   Flow Measurement Architecture and Meter MIB. It discusses the
   implementation of NeTraMet (a traffic meter) and NeMaC (a combined
   manager and meter reader), considers the writing of meter rule sets
   and gives some guidance on setting up a traffic flow measurement
   system using NeTraMet.
</t>
</abstract>
</front>

<seriesInfo value="2123" name="RFC" />
<format octets="97237" type="HTML" target="http://xml.resource.org/public/rfc/html/rfc2123.html" />
<format octets="82226" type="XML" target="http://xml.resource.org/public/rfc/xml/rfc2123.xml" />
</reference>


<reference target2="reference.RFC.2124.xml" anchor="RFC2124">
<front>
<title abbrev="Cabletron Flow Admission">Cabletron&apos;s Light-weight Flow Admission Protocol Specification Version 1.0</title>
<author fullname="Paul Amsden" initials="P." surname="Amsden">
<organization />

<address>
<phone>+1 (603) 337-7408</phone>
<email>amsden@ctron.com</email>
</address>
</author>

<author fullname="Jim Amweg" initials="J." surname="Amweg">
<organization />

<address>
<phone>+1 (603) 337-5247</phone>
<email>amsden@ctron.com</email>
</address>
</author>

<author fullname="Paul Calato" initials="P." surname="Calato">
<organization />

<address>
<phone>+1 (603) 337-7625</phone>
<email>amsden@ctron.com</email>
</address>
</author>

<author fullname="Stephen Bensley" initials="S." surname="Bensley">
<organization />

<address>
<phone>+1 (603) 337-7061</phone>
<email>amsden@ctron.com</email>
</address>
</author>

<author fullname="Gregory Lyons" initials="G." surname="Lyons">
<organization />

<address>
<phone>+1 (603) 337-5318</phone>
<email>amsden@ctron.com</email>
</address>
</author>

<date year="1997" month="March" />
<area>Routing</area>
<keyword>Flow Admission Protocol</keyword>

<abstract>
<t>
   Light-weight Flow Admission Protocol, LFAP, allows an external Flow
   Admission Service (FAS) to manage flow admission at the switch,
   allowing flexible Flow Admission Services to be deployed by a vendor
   or customer without changes to, or undue burden on, the switch.
</t>

<t>
   Specifically, this document specifies the protocol between the switch
   Connection Control Entity (CCE) and the external FAS. Using LFAP, a
   Flow Admission Service can: allow or disallow flows, define the
   parameters under which a given flow is to operate (operating policy)
   or, redirect the flow to an alternate destination. The FAS may also
   maintain details of current or historical flows for billing, capacity
   planning and other purposes.
</t>
</abstract>
</front>

<seriesInfo value="2124" name="RFC" />
<format octets="60773" type="HTML" target="http://xml.resource.org/public/rfc/html/rfc2124.html" />
<format octets="48901" type="XML" target="http://xml.resource.org/public/rfc/xml/rfc2124.xml" />
</reference>


<reference target2="reference.RFC.2125.xml" anchor="RFC2125">
<front>
<title abbrev="PPP BAP">The PPP Bandwidth Allocation Protocol (BAP) The PPP Bandwidth Allocation Control Protocol (BACP)</title>
<author fullname="Craig Richards" initials="C." surname="Richards">
<organization>Shiva Corporation</organization>

<address>
<postal>
<street>28 Crosby Drive</street>
<street>Bedford</street>
<street>MA  01730</street>
<street>VOICE   +1 617 270 8419</street>
</postal>

<facsimile>+1 617 270 8599</facsimile>
<email>crich@us.shiva.com</email>
</address>
</author>

<author fullname="Kevin Smith" initials="K." surname="Smith">
<organization>Ascend Communications, Inc.</organization>

<address>
<postal>
<street>1275 Harbor Bay Parkway</street>
<street>Alameda</street>
<street>CA  94501</street>
<country>CA</country>
</postal>

<email>kevin@ascend.com</email>
</address>
</author>

<date year="1997" month="March" />
<area>Internet</area>
<keyword>PPP</keyword>
<keyword>control protocol</keyword>
<keyword>point-to-point protocol</keyword>

<abstract>
<t>
   This document proposes a method to manage the dynamic bandwidth
   allocation of implementations supporting the PPP multilink protocol
   .  This is done by defining the Bandwidth Allocation Protocol
   (BAP), as well as its associated control protocol, the Bandwidth
   Allocation Control Protocol (BACP).  BAP can be used to manage the
   number of links in a multilink bundle.  BAP defines datagrams to co-
   ordinate adding and removing individual links in a multilink bundle,
   as well as specifying which peer is responsible for which decisions
   regarding managing bandwidth during a multilink connection.
</t>
</abstract>
</front>

<seriesInfo value="2125" name="RFC" />
<format octets="64293" type="HTML" target="http://xml.resource.org/public/rfc/html/rfc2125.html" />
<format octets="48702" type="XML" target="http://xml.resource.org/public/rfc/xml/rfc2125.xml" />
</reference>


<reference target2="reference.RFC.2126.xml" anchor="RFC2126">
<front>
<title abbrev="ITOT">ISO Transport Service on top of TCP (ITOT)</title>
<author fullname="Yanick Pouffary" initials="Y." surname="Pouffary">
<organization>End Systems Networking</organization>

<address>
<postal>
<street>Digital Equipment Corporation</street>
<street>Centre Technique (Europe)</street>
<street>B.P. 027</street>
<street>950 Routes des colles</street>
<street>06901 Sophia antipolis</street>
<country>France</country>
</postal>

<phone>+33 92-95-62-85</phone>
<facsimile>+33 92-95-62-35</facsimile>
<email>pouffary@taec.enet.dec.com</email>
</address>
</author>

<author fullname="Alan Young" initials="A." surname="Young">
<organization>ISODE Consortium</organization>

<address>
<postal>
<street>The Dome</street>
<street>The Square</street>
<street>Richmond</street>
<country>UK</country>
</postal>

<phone>+44 181 332 9091</phone>
<facsimile>+44 181 332 9019</facsimile>
<email>A.Young@isode.com</email>
</address>
</author>

<date year="1997" month="March" />
<area>Transport</area>
<keyword>ISO Transport Service on top of TCP</keyword>
<keyword>International Organization for Standardization</keyword>
<keyword>transmission control protocol</keyword>

<abstract>
<t>
   This document is a revision to STD35, RFC1006 written by Marshall T.
   Rose and Dwight E. Cass. Since the release of RFC1006 in May 1987,
   much experience has been gained in using ISO transport services on
   top of TCP. This document refines the protocol and will eventually
   supersede RFC1006.
</t>

<t>
   This document describes the mechanism to allow ISO Transport Services
   to run over TCP over IPv4 or IPv6. It also defines a number of new
   features, which are not provided in RFC1006.
</t>

<t>
   The goal of this version is to minimise the number of changes to
   RFC1006 and ISO 8073 transport protocol definitions, while maximising
   performance, extending its applicability and protecting the installed
   base of RFC1006 users.
</t>
</abstract>
</front>

<seriesInfo value="2126" name="RFC" />
<format octets="69770" type="HTML" target="http://xml.resource.org/public/rfc/html/rfc2126.html" />
<format octets="53152" type="XML" target="http://xml.resource.org/public/rfc/xml/rfc2126.xml" />
</reference>


<reference target2="reference.RFC.2127.xml" anchor="RFC2127">
<front>
<title abbrev="ISDN MIB">ISDN Management Information Base using SMIv2</title>
<author fullname="Guenter Roeck" initials="G." surname="Roeck">
<organization>cisco Systems</organization>

<address>
<postal>
<street>170 West Tasman Drive</street>
<street>San Jose</street>
<street>CA 95134</street>
<street>U.S.A.</street>
</postal>

<phone>+1 408 527 3143</phone>
<email>groeck@cisco.com</email>
</address>
</author>

<date year="1997" month="March" />
<keyword>Management Information Base</keyword>
<keyword>integrated services digital network</keyword>
<keyword>structure of management information version 2</keyword>

<abstract>
<t>
   This memo defines a portion of the Management Information Base (MIB)
   for use with network management protocols in the Internet community.
   In particular, it defines a minimal set of managed objects for SNMP-
   based management of ISDN terminal interfaces.  ISDN interfaces are
   supported on a variety of equipment (for data and voice) including
   terminal adapters, bridges, hosts, and routers.
</t>

<t>
   This document specifies a MIB module in a manner that is compliant to
   the SNMPv2 SMI.  The set of objects is consistent with the SNMP
   framework and existing SNMP standards.
</t>

<t>
   This document is a product of the ISDN MIB working group within the
   Internet Engineering Task Force.  Comments are solicited and should
   be addressed to the working group&apos;s mailing list at isdn-
   mib@cisco.com and/or the author.
</t>

<t>
   The current version of this document reflects changes made during the
   last call period and the IESG review.
</t>
</abstract>
</front>

<seriesInfo value="2127" name="RFC" />
<format octets="109516" type="HTML" target="http://xml.resource.org/public/rfc/html/rfc2127.html" />
<format octets="95175" type="XML" target="http://xml.resource.org/public/rfc/xml/rfc2127.xml" />
</reference>


<reference target2="reference.RFC.2128.xml" anchor="RFC2128">
<front>
<title abbrev="Dial Control MIB">Dial Control Management Information Base using SMIv2</title>
<author fullname="Guenter Roeck" initials="G." surname="Roeck">
<organization>cisco Systems</organization>

<address>
<postal>
<street>170 West Tasman Drive</street>
<street>San Jose</street>
<street>CA 95134</street>
<street>U.S.A.</street>
</postal>

<phone>+1 408 527 3143</phone>
<email>groeck@cisco.com</email>
</address>
</author>

<date year="1997" month="March" />
<area>Management</area>
<keyword>Management Information Base</keyword>
<keyword>structure of management information version 2</keyword>

<abstract>
<t>
   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 demand
   access circuits, including ISDN.
</t>

<t>
   This document specifies a MIB module in a manner that is compliant to
   the SNMPv2 SMI.  The set of objects is consistent with the SNMP
   framework and existing SNMP standards.
</t>

<t>
   This document is a product of the ISDN MIB working group within the
   Internet Engineering Task Force.  Comments are solicited and should
   be addressed to the working group&apos;s mailing list at isdn-
   mib@cisco.com and/or the author.
</t>
</abstract>
</front>

<seriesInfo value="2128" name="RFC" />
<format octets="77305" type="HTML" target="http://xml.resource.org/public/rfc/html/rfc2128.html" />
<format octets="65230" type="XML" target="http://xml.resource.org/public/rfc/xml/rfc2128.xml" />
</reference>


<reference target2="reference.RFC.2129.xml" anchor="RFC2129">
<front>
<title abbrev="FANP Specification">Toshiba&apos;s Flow Attribute Notification Protocol (FANP) Specification</title>
<author fullname="Ken-ichi Nagami" initials="K." surname="Nagami">
<organization>R&amp;D Center, Toshiba</organization>

<address>
<postal>
<street>1 Komukai Toshiba-cho</street>
<street>Saiwai-ku</street>
<street>Kawasaki 210</street>
<country>Japan</country>
</postal>

<phone>+81-44-549-2238</phone>
<email>nagami@isl.rdc.toshiba.co.jp</email>
</address>
</author>

<author fullname="Yasuhiro Katsube" initials="Y." surname="Katsube">
<organization>R&amp;D Center, Toshiba</organization>

<address>
<postal>
<street>1 Komukai Toshiba-cho</street>
<street>Saiwai-ku</street>
<street>Kawasaki 210</street>
<country>Japan</country>
</postal>

<phone>+81-44-549-2238</phone>
<email>katsube@isl.rdc.toshiba.co.jp</email>
</address>
</author>

<author fullname="Yasuro Shobatake" initials="Y." surname="Shobatake">
<organization>R&amp;D Center, Toshiba</organization>

<address>
<postal>
<street>1 Komukai Toshiba-cho</street>
<street>Saiwai-ku</street>
<street>Kawasaki 210</street>
<country>Japan</country>
</postal>

<phone>+81-44-549-2238</phone>
<email>masahata@csl.rdc.toshiba.co.jp</email>
</address>
</author>

<author fullname="Akiyoshi Mogi" initials="A." surname="Mogi">
<organization>R&amp;D Center, Toshiba</organization>

<address>
<postal>
<street>1 Komukai Toshiba-cho</street>
<street>Saiwai-ku</street>
<street>Kawasaki 210</street>
<country>Japan</country>
</postal>

<phone>+81-44-549-2238</phone>
<email>mogi@isl.rdc.toshiba.co.jp</email>
</address>
</author>

<author fullname="Shigeo Matsuzawa" initials="S." surname="Matsuzawa">
<organization>R&amp;D Center, Toshiba</organization>

<address>
<postal>
<street>1 Komukai Toshiba-cho</street>
<street>Saiwai-ku</street>
<street>Kawasaki 210</street>
<country>Japan</country>
</postal>

<phone>+81-44-549-2238</phone>
<email>shigeom@isl.rdc.toshiba.co.jp</email>
</address>
</author>

<author fullname="Tatsuya Jinmei" initials="T." surname="Jinmei">
<organization>R&amp;D Center, Toshiba</organization>

<address>
<postal>
<street>1 Komukai Toshiba-cho</street>
<street>Saiwai-ku</street>
<street>Kawasaki 210</street>
<country>Japan</country>
</postal>

<phone>+81-44-549-2238</phone>
<email>jinmei@isl.rdc.toshiba.co.jp</email>
</address>
</author>

<author fullname="Hiroshi Esaki" initials="H." surname="Esaki">
<organization>R&amp;D Center, Toshiba</organization>

<address>
<postal>
<street>1 Komukai Toshiba-cho</street>
<street>Saiwai-ku</street>
<street>Kawasaki 210</street>
<country>Japan</country>
</postal>

<phone>+81-44-549-2238</phone>
<email>hiroshi@isl.rdc.toshiba.co.jp</email>
</address>
</author>

<date year="1997" month="April" />
<area>Routing</area>
<keyword>FANP</keyword>
<keyword>flow attribute</keyword>

<abstract>
<t>
   This memo discusses Flow Attribute Notification Protocol (FANP),
   which is a protocol between neighbor nodes for the management of
   cut-through packet forwarding functionalities. In cut-through packet
   forwarding, a router doesn&apos;t have to perform conventional IP packet
   processing for received packets.  FANP indicates mapping information
   between a datalink connection and a packet flow to the neighbor node
   and helps a pair of nodes manage the mapping information.  By using
   FANP, routers (e.g., CSR; Cell Switch Router) can forward incoming
   packets based on their datalink-level connection identifiers,
   bypassing usual IP packet processing.  The design policy of the FANP
   is;

<list>
<t>
       (1)  soft-state cut-through path (Dedicated-VC) management
</t>

<t>
       (2)  protocol between neighbor nodes instead of end-to-end
</t>

<t>
       (3)  applicable to any connection oriented datalink platform
</t>
</list>
</t>
</abstract>
</front>

<seriesInfo value="2129" name="RFC" />
<format octets="59414" type="HTML" target="http://xml.resource.org/public/rfc/html/rfc2129.html" />
<format octets="44201" type="XML" target="http://xml.resource.org/public/rfc/xml/rfc2129.xml" />
</reference>


<reference target2="reference.RFC.2130.xml" anchor="RFC2130">
<front>
<title abbrev="Character Set Workshop Report">The Report of the IAB Character Set Workshop held 29 February - 1 March, 1996</title>
<author fullname="Chris Weider" initials="C." surname="Weider">
<organization>Microsoft Corp.</organization>

<address>
<postal>
<street>1 Microsoft Way</street>
<street>Redmond</street>
<street>WA 98052</street>
<country>USA</country>
</postal>

<email>cweider@microsoft.com</email>
</address>
</author>

<author fullname="Cecilia Preston" initials="C." surname="Preston">
<organization>Preston &amp; Lynch</organization>

<address>
<postal>
<street>PO Box 8310</street>
<street>Emeryville</street>
<street>CA 94662</street>
<country>USA</country>
</postal>

<email>cecilia@well.com</email>
</address>
</author>

<author fullname="Keld Simonsen" initials="K." surname="Simonsen">
<organization>DKUUG</organization>

<address>
<postal>
<street>Freubjergvey 3</street>
<street>DK-2100 Kxbenhavn X</street>
<street>Danmark</street>
</postal>

<email>Keld@dkuug.dk</email>
</address>
</author>

<author fullname="Harald T. Alvestrand" initials="H.T." surname="Alvestrand">
<organization>UNINETT</organization>

<address>
<postal>
<street>P.O.Box 6883 Elgeseter</street>
<street>N-7002 TRONDHEIM</street>
<country>NORWAY</country>
</postal>

<email>Harald.T.Alvestrand@uninett.no</email>
</address>
</author>

<author fullname="Randall Atkinson" initials="R." surname="Atkinson">
<organization>cisco Systems</organization>

<address>
<postal>
<street>170 West Tasman Drive</street>
<street>San Jose</street>
<street>CA 95134-1706</street>
<country>USA</country>
</postal>

<email>rja@cisco.com</email>
</address>
</author>

<author fullname="Mark Crispin" initials="M." surname="Crispin">
<organization>Networks &amp; Distributed Computing</organization>

<address>
<postal>
<street>University of Washington</street>
<street>4545 15th Avenue</street>
<street>Seattle</street>
<street>WA  98105-4527</street>
<country>USA</country>
</postal>

<email>mrc@cac.washington.edu</email>
</address>
</author>

<author fullname="Peter Svanberg" initials="P." surname="Svanberg">
<organization>Dept. of Numberical Analysis and Computing Science (Nada)</organization>

<address>
<postal>
<street>Royal Institute of Technology</street>
<street>SE-100 44 STOCKHOLM</street>
<country>SWEDEN</country>
</postal>

<email>psv@nada.kth.se</email>
</address>
</author>

<date year="1997" month="April" />
<area>Applications</area>
<keyword>Internet Architecture Board</keyword>
<keyword>character encoding</keyword>
<keyword>multipurpose internet mail extensions</keyword>
<keyword>workshop</keyword>

<abstract>
<t>
   This report details the conclusions of an IAB-sponsored invitational
   workshop held 29 February  - 1 March, 1996, to discuss the use of
   character sets on the Internet.  It motivates the need to have
   character set handling in Internet protocols which transmit text,
   provides a conceptual framework for specifying character sets,
   recommends the use of MIME tagging for transmitted text, recommends a
   default character set *without* stating that there is no need for
   other character sets, and makes a series of recommendations to the
   IAB, IANA, and the IESG for furthering the integration of the
   character set framework into text transmission protocols.
</t>
</abstract>

<note title="Executive summary">
<t>
   The term &apos;Character Set&apos; means many things to many people. Even the
   MIME registry of character sets registers items that have great
   differences in semantics and applicability. This workshop provides
   guidance to the IAB and IETF about the use of character sets on the
   Internet and provides a common framework for interoperability between
   the many characters in use there.
</t>

<t>
   The framework consists of four components: an architecture model,
   which specifies components necessary for on-the-wire transmission of
   text; recommendations for tagging transmitted (and stored) text;
   recommended defaults for each level of the model; and a set of
   recommendations to the IAB, IANA, and the IESG for furthering the
   integration of  this framework into text transmission protocols.
</t>

<t>
   The architectural model specifies 7 layers, of which only three are
   required for on-the-wire transmission. The Coded Character Set is a
   mapping from a set of abstract characters to a set of integers. The
   Character Encoding Scheme is a mapping from a Coded Character Set (or
   several) to a set of octets. The Transfer Encoding Syntax is a
   transformation applied to data which has been encoded using a
   Character Encoding Scheme to allow it to be transmitted. These layers
   should be specified in a transmitted text stream by using the MIME
   encoding mechanisms.
</t>

<t>
   This report recommends the use of ISO 10646 as the default Coded
   Character Set, and UTF-8 as the default Character Encoding Scheme in
   the creation of new protocols or new version of old protocols which
   transmit text. These defaults do not deprecate the use of other
   character sets when and where they are needed; they are simply
   intended to provide guidance and a specification for
   interoperability.
</t>
</note>
</front>

<seriesInfo value="2130" name="RFC" />
<format octets="76248" type="HTML" target="http://xml.resource.org/public/rfc/html/rfc2130.html" />
<format octets="58392" type="XML" target="http://xml.resource.org/public/rfc/xml/rfc2130.xml" />
</reference>


<reference target2="reference.RFC.2131.xml" anchor="RFC2131">
<front>
<title abbrev="DHCP">Dynamic Host Configuration Protocol</title>
<author fullname="Ralph Droms" initials="R." surname="Droms">
<organization>Computer Science Department</organization>

<address>
<postal>
<street>323 Dana Engineering</street>
<street>Bucknell University</street>
<street>Lewisburg</street>
<street>PA 17837</street>
</postal>

<phone>(717) 524-1145</phone>
<email>droms@bucknell.edu</email>
</address>
</author>

<date year="1997" month="March" />
<area>Internet</area>
<keyword>DHCP</keyword>
<keyword>configuration</keyword>
<keyword>dynamic host configuration protocol</keyword>
<keyword>host</keyword>

<abstract>
<t>
   The Dynamic Host Configuration Protocol (DHCP) provides a framework
   for passing configuration information to hosts on a TCPIP network.
   DHCP is based on the Bootstrap Protocol (BOOTP) , adding the
   capability of automatic allocation of reusable network addresses and
   additional configuration options .  DHCP captures the behavior of
   BOOTP relay agents [7, 21], and DHCP participants can interoperate
   with BOOTP participants .
</t>
</abstract>
</front>

<seriesInfo value="2131" name="RFC" />
<format octets="134047" type="HTML" target="http://xml.resource.org/public/rfc/html/rfc2131.html" />
<format octets="117914" type="XML" target="http://xml.resource.org/public/rfc/xml/rfc2131.xml" />
</reference>


<reference target2="reference.RFC.2132.xml" anchor="RFC2132">
<front>
<title abbrev="DHCP Options">DHCP Options and BOOTP Vendor Extensions</title>
<author fullname="Steve Alexander" initials="S." surname="Alexander">
<organization>Silicon Graphics, Inc.</organization>

<address>
<postal>
<street>2011 N. Shoreline Boulevard</street>
<street>Mailstop 510</street>
<street>Mountain View</street>
<street>CA 94043-1389</street>
</postal>

<phone>(415) 933-6172</phone>
<email>sca@engr.sgi.com</email>
</address>
</author>

<author fullname="Ralph Droms" initials="R." surname="Droms">
<organization>Bucknell University</organization>

<address>
<postal>
<street>Lewisburg</street>
<street>PA 17837</street>
</postal>

<phone>(717) 524-1145</phone>
<email>droms@bucknell.edu</email>
</address>
</author>

<date year="1997" month="March" />
<keyword>bootstrap protocol</keyword>
<keyword>dynamic host configuration protocol</keyword>

<abstract>
<t>
   The Dynamic Host Configuration Protocol (DHCP)  provides a
   framework for passing configuration information to hosts on a TCP/IP
   network.  Configuration parameters and other control information are
   carried in tagged data items that are stored in the &apos;options&apos; field
   of the DHCP message.  The data items themselves are also called
   &quot;options.&quot;
</t>

<t>
   This document specifies the current set of DHCP options.  Future
   options will be specified in separate RFCs.  The current list of
   valid options is also available in ftp://ftp.isi.edu/in-
   notes/iana/assignments .
</t>

<t>
   All of the vendor information extensions defined in RFC 1497  may
   be used as DHCP options.  The definitions given in RFC 1497 are
   included in this document, which supersedes RFC 1497.  All of the
   DHCP options defined in this document, except for those specific to
   DHCP as defined in section 9, may be used as BOOTP vendor information
   extensions.
</t>
</abstract>
</front>

<seriesInfo value="2132" name="RFC" />
<format octets="94976" type="HTML" target="http://xml.resource.org/public/rfc/html/rfc2132.html" />
<format octets="74682" type="XML" target="http://xml.resource.org/public/rfc/xml/rfc2132.xml" />
</reference>


<reference target2="reference.RFC.2133.xml" anchor="RFC2133">
<front>
<title abbrev="IPv6 Socket Interface">Basic Socket Interface Extensions for IPv6</title>
<author fullname="Robert E. Gilligan" initials="R.E." surname="Gilligan">
<organization>Freegate Corporation</organization>

<address>
<postal>
<street>710 Lakeway Dr.  STE 230</street>
<street>Sunnyvale</street>
<street>CA 94086</street>
</postal>

<phone>+1 408 524 4804</phone>
<email>gilligan@freegate.net</email>
</address>
</author>

<author fullname="Susan Thomson" initials="S." surname="Thomson">
<organization>Bell Communications Research</organization>

<address>
<postal>
<street>MRE 2P-343</street>
<street>445 South Street</street>
<street>Morristown</street>
<street>NJ 07960</street>
</postal>

<phone>+1 201 829 4514</phone>
<email>set@thumper.bellcore.com</email>
</address>
</author>

<author fullname="Jim Bound" initials="J." surname="Bound">
<organization>Digital Equipment Corporation</organization>

<address>
<postal>
<street>110 Spitbrook Road ZK3-3/U14</street>
<street>Nashua</street>
<street>NH 03062-2698</street>
</postal>

<phone>+1 603 881 0400</phone>
<email>bound@zk3.dec.com</email>
</address>
</author>

<author fullname="W. Richard Stevens" initials="W.R." surname="Stevens">
<organization />

<address>
<postal>
<street>1202 E. Paseo del Zorro</street>
<street>Tucson</street>
<street>AZ 85718-2826</street>
</postal>

<phone>+1 520 297 9416</phone>
<email>rstevens@kohala.com</email>
</address>
</author>

<date year="1997" month="April" />
<area>Internet</area>
<keyword>IPv6</keyword>
<keyword>internet protocol version 6</keyword>
<keyword>socket</keyword>

<abstract>
<t>
   The de facto standard application program interface (API) for TCP/IP
   applications is the &quot;sockets&quot; interface.  Although this API was
   developed for Unix in the early 1980s it has also been implemented on
   a wide variety of non-Unix systems.  TCP/IP applications written
   using the sockets API have in the past enjoyed a high degree of
   portability and we would like the same portability with IPv6
   applications.  But changes are required to the sockets API to support
   IPv6 and this memo describes these changes.  These include a new
   socket address structure to carry IPv6 addresses, new address
   conversion functions, and some new socket options.  These extensions
   are designed to provide access to the basic IPv6 features required by
   TCP and UDP applications, including multicasting, while introducing a
   minimum of change into the system and providing complete
   compatibility for existing IPv4 applications.  Additional extensions
   for advanced IPv6 features (raw sockets and access to the IPv6
   extension headers) are defined in another document .
</t>
</abstract>
</front>

<seriesInfo value="2133" name="RFC" />
<format octets="85149" type="HTML" target="http://xml.resource.org/public/rfc/html/rfc2133.html" />
<format octets="71245" type="XML" target="http://xml.resource.org/public/rfc/xml/rfc2133.xml" />
</reference>


<reference target2="reference.RFC.2134.xml" anchor="RFC2134">
<front>
<title abbrev="ISOC Articles of Incorporation">ARTICLES OF INCORPORATION OF INTERNET SOCIETY</title>
<author>
<organization>ISOC Board of Trustees</organization>

<address>
<postal>
<street>12020 Sunrise Vally Drive - Suite 210</street>
<street>Reston</street>
<country>USA</country>
</postal>

<phone>+1 703 648 9888</phone>
<facsimile>+1 703 638 9887</facsimile>
<email>isoc-trustees@isoc.org</email>
</address>
</author>

<date year="1997" month="April" />
<area>General</area>
<keyword>Internet Society</keyword>

<abstract>
<t>
   These are the articles of incorporation of the Internet Society.
   They are published for the information of the IETF community at the
   request of the poisson working group.
</t>
</abstract>
</front>

<seriesInfo value="2134" name="RFC" />
<format octets="16743" type="HTML" target="http://xml.resource.org/public/rfc/html/rfc2134.html" />
<format octets="9415" type="XML" target="http://xml.resource.org/public/rfc/xml/rfc2134.xml" />
</reference>


<reference target2="reference.RFC.2135.xml" anchor="RFC2135">
<front>
<title abbrev="ISOC By-Laws">Internet Society By-Laws</title>
<author>
<organization>ISOC Board of Trustees</organization>

<address>
<postal>
<street>12020 Sunrise Vally Drive - Suite 210</street>
<street>Reston</street>
<country>USA</country>
</postal>

<phone>+1 703 648 9888</phone>
<facsimile>+1 703 638 9887</facsimile>
<email>isoc-trustees@isoc.org</email>
</address>
</author>

<date year="1997" month="April" />
<area>General</area>
<keyword>Internet Society</keyword>

<abstract>
<t>
   These are the by-laws of the Internet Society, as amended, as of June
   1996.  They are published for the information of the IETF community
   at the request of the poisson working group. Please refer to the ISOC
   web page (www.isoc.org) for the current version of the by-laws.
</t>
</abstract>
</front>

<seriesInfo value="2135" name="RFC" />
<format octets="30283" type="HTML" target="http://xml.resource.org/public/rfc/html/rfc2135.html" />
<format octets="21529" type="XML" target="http://xml.resource.org/public/rfc/xml/rfc2135.xml" />
</reference>


<reference target2="reference.RFC.2136.xml" anchor="RFC2136">
<front>
<title abbrev="DNS Update">Dynamic Updates in the Domain Name System (DNS UPDATE)</title>
<author fullname="Paul Vixie" initials="P." surname="Vixie">
<organization>Internet Software Consortium</organization>

<address>
<postal>
<street>Star Route Box 159A</street>
<street>Woodside</street>
<street>CA 94062</street>
</postal>

<phone>+1 415 747 0204</phone>
<email>paul@vix.com</email>
</address>
</author>

<author fullname="Susan Thomson" initials="S." surname="Thomson">
<organization>Bellcore</organization>

<address>
<postal>
<street>445 South Street</street>
<street>Morristown</street>
<street>NJ 07960</street>
</postal>

<phone>+1 201 829 4514</phone>
<email>set@thumper.bellcore.com</email>
</address>
</author>

<author fullname="Yakov Rekhter" initials="Y." surname="Rekhter">
<organization>Cisco Systems</organization>

<address>
<postal>
<street>170 West Tasman Drive</street>
<street>San Jose</street>
<street>CA 95134-1706</street>
</postal>

<phone>+1 914 528 0090</phone>
<email>yakov@cisco.com</email>
</address>
</author>

<author fullname="Jim Bound" initials="J." surname="Bound">
<organization>Digital Equipment Corp.</organization>

<address>
<postal>
<street>110 Spitbrook Rd ZK3-3/U14</street>
<street>Nashua</street>
<street>NH 03062-2698</street>
</postal>

<phone>+1 603 881 0400</phone>
<email>bound@zk3.dec.com</email>
</address>
</author>

<date year="1997" month="April" />
<area>Applications</area>
<keyword>domain name</keyword>
<keyword>domain name system</keyword>

<abstract>
<t>
   The Domain Name System was originally designed to support queries of
   a statically configured database.  While the data was expected to
   change, the frequency of those changes was expected to be fairly low,
   and all updates were made as external edits to a zone&apos;s Master File.
</t>

<t>
   Using this specification of the UPDATE opcode, it is possible to add
   or delete RRs or RRsets from a specified zone.  Prerequisites are
   specified separately from update operations, and can specify a
   dependency upon either the previous existence or nonexistence of an
   RRset, or the existence of a single RR.
</t>

<t>
   UPDATE is atomic, i.e., all prerequisites must be satisfied or else
   no update operations will take place.  There are no data dependent
   error conditions defined after the prerequisites have been met.
</t>
</abstract>
</front>

<seriesInfo value="2136" name="RFC" />
<format octets="67722" type="HTML" target="http://xml.resource.org/public/rfc/html/rfc2136.html" />
<format octets="54818" type="XML" target="http://xml.resource.org/public/rfc/xml/rfc2136.xml" />
</reference>


<reference target2="reference.RFC.2137.xml" anchor="RFC2137">
<front>
<title abbrev="SDNSDU">Secure Domain Name System Dynamic Update</title>
<author fullname="Donald E. Eastlake, 3rd" initials="D.E." surname="Eastlake">
<organization>CyberCash, Inc.</organization>

<address>
<postal>
<street>318 Acton Street</street>
<street>Carlisle</street>
<street>MA 01741</street>
<country>USA</country>
</postal>

<phone>+1 508-287-4877</phone>
<email>dee@cybercash.com</email>
</address>
</author>

<date year="1997" month="April" />
<area>Security</area>
<keyword>DNSSEC</keyword>
<keyword>cryptographic</keyword>
<keyword>digital signature</keyword>
<keyword>domain name</keyword>
<keyword>domain name system</keyword>
<keyword>security</keyword>

<abstract>
<t>
   Domain Name System (DNS) protocol extensions have been defined to
   authenticate the data in DNS and provide key distribution services
   .  DNS Dynamic Update operations have also been defined
   , but without a detailed description of security for the
   update operation.  This memo describes how to use DNSSEC digital
   signatures covering requests and data to secure updates and restrict
   updates to those authorized to perform them as indicated by the
   updater&apos;s possession of cryptographic keys.
</t>
</abstract>
</front>

<seriesInfo value="2137" name="RFC" />
<format octets="35693" type="HTML" target="http://xml.resource.org/public/rfc/html/rfc2137.html" />
<format octets="24677" type="XML" target="http://xml.resource.org/public/rfc/xml/rfc2137.xml" />
</reference>


<reference target2="reference.RFC.2138.xml" anchor="RFC2138">
<front>
<title abbrev="RADIUS">Remote Authentication Dial In User Service (RADIUS)</title>
<author fullname="Carl Rigney" initials="C." surname="Rigney">
<organization>Livingston Enterprises</organization>

<address>
<postal>
<street>4464 Willow Road</street>
<street>Pleasanton</street>
<street>California  94588</street>
</postal>

<phone>+1 510 426 0770</phone>
<email>cdr@livingston.com</email>
</address>
</author>

<author fullname="Carl Rigney" initials="C." surname="Rigney">
<organization>Livingston Enterprises</organization>

<address>
<postal>
<street>4464 Willow Road</street>
<street>Pleasanton</street>
<street>California  94588</street>
</postal>

<phone>+1 510 426 0770</phone>
<email>cdr@livingston.com</email>
</address>
</author>

<author fullname="Allan C. Rubens" initials="A.C." surname="Rubens">
<organization>Merit Network, Inc.</organization>

<address>
<postal>
<street>4251 Plymouth Road</street>
<street>Ann Arbor</street>
<street>Michigan  48105-2785</street>
</postal>

<email>acr@merit.edu</email>
</address>
</author>

<author fullname="William Allen Simpson" initials="W.A." surname="Simpson">
<organization>Daydreamer</organization>

<address>
<postal>
<street>Computer Systems Consulting Services</street>
<street>1384 Fontaine</street>
<street>Madison Heights</street>
<street>Michigan  48071</street>
</postal>

<email>wsimpson@greendragon.com</email>
</address>
</author>

<author fullname="Steve Willens" initials="S." surname="Willens">
<organization>Livingston Enterprises</organization>

<address>
<postal>
<street>4464 Willow Road</street>
<street>Pleasanton</street>
<street>California  94588</street>
</postal>

<email>steve@livingston.com</email>
</address>
</author>

<date year="1997" month="April" />
<area>Security</area>
<keyword>authentication</keyword>
<keyword>remote authentication dial in user service</keyword>

<abstract>
<t>
   This document describes a protocol for carrying authentication,
   authorization, and configuration information between a Network Access
   Server which desires to authenticate its links and a shared
   Authentication Server.
</t>
</abstract>
</front>

<seriesInfo value="2138" name="RFC" />
<format octets="144966" type="HTML" target="http://xml.resource.org/public/rfc/html/rfc2138.html" />
<format octets="122331" type="XML" target="http://xml.resource.org/public/rfc/xml/rfc2138.xml" />
</reference>


<reference target2="reference.RFC.2139.xml" anchor="RFC2139">
<front>
<title>RADIUS Accounting</title>
<author fullname="Carl Rigney" initials="C." surname="Rigney">
<organization>Livingston Enterprises</organization>

<address>
<postal>
<street>4464 Willow Road</street>
<street>Pleasanton</street>
<street>California  94588</street>
</postal>

<phone>+1 510 426 0770</phone>
<email>cdr@livingston.com</email>
</address>
</author>

<author fullname="Carl Rigney" initials="C." surname="Rigney">
<organization>Livingston Enterprises</organization>

<address>
<postal>
<street>4464 Willow Road</street>
<street>Pleasanton</street>
<street>California  94588</street>
</postal>

<email>cdr@livingston.com</email>
</address>
</author>

<date year="1997" month="April" />
<area>Security</area>
<keyword>Radius</keyword>
<keyword>accounting</keyword>
<keyword>authentication</keyword>
<keyword>remote authentication dial in user service</keyword>

<abstract>
<t>
   This document describes a protocol for carrying accounting
   information between a Network Access Server and a shared Accounting
   Server.
</t>
</abstract>
</front>

<seriesInfo value="2139" name="RFC" />
<format octets="58750" type="HTML" target="http://xml.resource.org/public/rfc/html/rfc2139.html" />
<format octets="45798" type="XML" target="http://xml.resource.org/public/rfc/xml/rfc2139.xml" />
</reference>


<reference target2="reference.RFC.2140.xml" anchor="RFC2140">
<front>
<title abbrev="TCP Control Block">TCP Control Block Interdependence</title>
<author fullname="Joe Touch" initials="J." surname="Touch">
<organization>University of Southern California/Information Sciences Institute</organization>

<address>
<postal>
<street>4676 Admiralty Way</street>
<street>Marina del Rey</street>
<street>CA 90292-6695</street>
<country>USA</country>
</postal>

<phone>+1 310-822-1511 x151</phone>
<facsimile>+1 310-823-6714</facsimile>
<email>touch@isi.edu</email>
<uri>http://www.isi.edu/~touch</uri>
</address>
</author>

<date year="1997" month="April" />
<area>Transport</area>
<keyword>TCP</keyword>
<keyword>congestion</keyword>
<keyword>transmission control protocol</keyword>

<abstract>
<t>
   This memo makes the case for interdependent TCP control blocks, where
   part of the TCP state is shared among similar concurrent connections,
   or across similar connection instances. TCP state includes a
   combination of parameters, such as connection state, current round-
   trip time estimates, congestion control information, and process
   information.  This state is currently maintained on a per-connection
   basis in the TCP control block, but should be shared across
   connections to the same host. The goal is to improve transient
   transport performance, while maintaining backward-compatibility with
   existing implementations.
</t>

<t>
   This document is a product of the LSAM project at ISI.
</t>
</abstract>
</front>

<seriesInfo value="2140" name="RFC" />
<format octets="34441" type="HTML" target="http://xml.resource.org/public/rfc/html/rfc2140.html" />
<format octets="23245" type="XML" target="http://xml.resource.org/public/rfc/xml/rfc2140.xml" />
</reference>


<reference target2="reference.RFC.2141.xml" anchor="RFC2141">
<front>
<title>URN Syntax</title>
<author fullname="Ryan Moats" initials="R." surname="Moats">
<organization>AT&amp;T</organization>

<address>
<postal>
<street>15621 Drexel Circle</street>
<street>Omaha</street>
<street>NE 68135-2358</street>
<country>USA</country>
</postal>

<phone>+1 402 894-9456</phone>
<email>jayhawk@ds.internic.net</email>
</address>
</author>

<date year="1997" month="May" />
<area>Applications</area>
<keyword>URN</keyword>
<keyword>uniform resource</keyword>

<abstract>
<t>
   Uniform Resource Names (URNs) are intended to serve as persistent,
   location-independent, resource identifiers. This document sets
   forward the canonical syntax for URNs.  A discussion of both existing
   legacy and new namespaces and requirements for URN presentation and
   transmission are presented.  Finally, there is a discussion of URN
   equivalence and how to determine it.
</t>
</abstract>
</front>

<seriesInfo value="2141" name="RFC" />
<format octets="30670" type="HTML" target="http://xml.resource.org/public/rfc/html/rfc2141.html" />
<format octets="17551" type="XML" target="http://xml.resource.org/public/rfc/xml/rfc2141.xml" />
</reference>


<reference target2="reference.RFC.2142.xml" anchor="RFC2142">
<front>
<title abbrev="Mailbox Names">MAILBOX NAMES FOR COMMON SERVICES, ROLES AND FUNCTIONS</title>
<author fullname="Dave Crocker" initials="D." surname="Crocker">
<organization>Internet Mail Consortium</organization>

<address>
<postal>
<street>127 Segre Ave.</street>
<street>Santa Cruz</street>
<country>CA</country>
</postal>

<phone>+1 408 246 8253</phone>
<email>dcrocker@imc.org</email>
</address>
</author>

<date year="1997" month="May" />
<area>Applications</area>
<keyword>mail</keyword>

<abstract>
<t>
   This specification enumerates and describes Internet mail addresses
   (mailbox name @ host reference) to be used when contacting personnel
   at an organization.  Mailbox names are provided for both operations
   and business functions.  Additional mailbox names and aliases are not
   prohibited, but organizations which support email exchanges with the
   Internet are encouraged to support AT LEAST each mailbox name for
   which the associated function exists within the organization.
</t>
</abstract>
</front>

<seriesInfo value="2142" name="RFC" />
<format octets="29012" type="HTML" target="http://xml.resource.org/public/rfc/html/rfc2142.html" />
<format octets="16576" type="XML" target="http://xml.resource.org/public/rfc/xml/rfc2142.xml" />
</reference>


<reference target2="reference.RFC.2143.xml" anchor="RFC2143">
<front>
<title abbrev="Encapulating IP with SCSI">Encapsulating IP with the Small Computer System Interface</title>
<author fullname="Ben Elliston" initials="B." surname="Elliston">
<organization>Compucat Research Pty Limited</organization>

<address>
<postal>
<street>Box 7305 Canberra Mail Centre</street>
<street>Canberra ACT 2610</street>
<country>Australia</country>
</postal>

<phone>+61 6 295 1331</phone>
<facsimile>+61 6 295 1855</facsimile>
<email>ben.elliston@compucat.com.au</email>
</address>
</author>

<date year="1997" month="May" />
<area>Internet</area>
<keyword>SCSI</keyword>
<keyword>encapsulate</keyword>
</front>

<seriesInfo value="2143" name="RFC" />
<format octets="21613" type="HTML" target="http://xml.resource.org/public/rfc/html/rfc2143.html" />
<format octets="11366" type="XML" target="http://xml.resource.org/public/rfc/xml/rfc2143.xml" />
</reference>


<reference target2="reference.RFC.2144.xml" anchor="RFC2144">
<front>
<title>The CAST-128 Encryption Algorithm</title>
<author fullname="Carlisle Adams" initials="C." surname="Adams">
<organization>Entrust Technologies</organization>

<address>
<postal>
<street>750 Heron Road</street>
<city>Ottawa</city>
<region>Ontario</region>
<code>K1V 1A7</code>
<country>CA</country>
</postal>

<phone>+1 613 763 9008</phone>
<email>cadams@entrust.com</email>
</address>
</author>

<date year="1997" month="May" />

<abstract>
<t>There is a need in the Internet community for an unencumbered encryption algorithm with a range of key sizes that can provide security for a variety of cryptographic applications and protocols.</t>

<t>This document describes an existing algorithm that can be used to satisfy this requirement.  Included are a description of the cipher and the key scheduling algorithm (Section 2), the s-boxes (Appendix A), and a set of test vectors (Appendix B).</t>
</abstract>
</front>

<seriesInfo value="2144" name="RFC" />
</reference>


<reference target2="reference.RFC.2145.xml" anchor="RFC2145">
<front>
<title abbrev="HTTP Version Numbers">Use and Interpretation of HTTP Version Numbers</title>
<author fullname="Jeffrey C. Mogul" initials="J.C." surname="Mogul">
<organization>Western Research Laboratory</organization>

<address>
<postal>
<street>Digital Equipment Corporation</street>
<street>250 University Avenue</street>
<street>Palo Alto</street>
<street>California</street>
<street>94305</street>
<country>USA</country>
</postal>

<email>mogul@wrl.dec.com</email>
</address>
</author>

<author fullname="Roy T. Fielding" initials="R.T." surname="Fielding">
<organization>Department of Information and Computer Science</organization>

<address>
<postal>
<street>University of California</street>
<street>Irvine</street>
<street>CA 92717-3425</street>
<country>USA</country>
</postal>

<facsimile>+1 (714) 824-4056</facsimile>
<email>fielding@ics.uci.edu</email>
</address>
</author>

<author fullname="Jim Gettys" initials="J." surname="Gettys">
<organization>MIT Laboratory for Computer Science</organization>

<address>
<postal>
<street>545 Technology Square</street>
<street>Cambridge</street>
<street>MA 02139</street>
<country>USA</country>
</postal>

<facsimile>+1 (617) 258 8682</facsimile>
<email>jg@w3.org</email>
</address>
</author>

<author fullname="Henrik Frystyk Nielsen" initials="H.F." surname="Nielsen">
<organization>W3 Consortium</organization>

<address>
<postal>
<street>MIT Laboratory for Computer Science</street>
<street>545 Technology Square</street>
<street>Cambridge</street>
<street>MA 02139</street>
<country>USA</country>
</postal>

<facsimile>+1 (617) 258 8682</facsimile>
<email>frystyk@w3.org</email>
</address>
</author>

<date year="1997" month="May" />
<area>Applications</area>
<keyword>HTTP</keyword>
<keyword>hypertext transfer protocol</keyword>

<abstract>
<t>
   HTTP request and response messages include an HTTP protocol version
   number.  Some confusion exists concerning the proper use and
   interpretation of HTTP version numbers, and concerning
   interoperability of HTTP implementations of different protocol
   versions.  This document is an attempt to clarify the situation.  It
   is not a modification of the intended meaning of the existing
   HTTP/1.0 and HTTP/1.1 documents, but it does describe the intention
   of the authors of those documents, and can be considered definitive
   when there is any ambiguity in those documents concerning HTTP
   version numbers, for all versions of HTTP.
</t>
</abstract>
</front>

<seriesInfo value="2145" name="RFC" />
<format octets="25554" type="HTML" target="http://xml.resource.org/public/rfc/html/rfc2145.html" />
<format octets="14130" type="XML" target="http://xml.resource.org/public/rfc/xml/rfc2145.xml" />
</reference>


<reference target2="reference.RFC.2146.xml" anchor="RFC2146">
<front>
<title abbrev=".gov">U.S. Government Internet Domain Names</title>
<author>
<organization>Federal Networking Council</organization>

<address>
<postal>
<street>4001 N. Fairfax Drive</street>
<street>Arlington</street>
<street>VA 22203</street>
</postal>

<phone>(703) 522-6410</phone>
<email>execdir@fnc.gov</email>
<uri>http://www.fnc.gov</uri>
</address>
</author>

<date year="1997" month="May" />
<keyword>domain name</keyword>

<abstract>
<t>
   This memo provides an update and clarification to RFC 1816.  This
   document describes the registration policies for the top-level domain
   &quot;.GOV&quot;.  The purpose of the domain is to provide naming conventions
   that identify US Federal government agencies in order to facilitate
   access to their electronic resources.  This memo provides guidance
   for registrations by Federal Agencies that avoids name duplication
   and facilitates responsiveness to the public.  It restricts
   registrations to coincide with the approved structure of the US
   government and the advice of its Chief Information Officers.  Two
   documents are recognized as constituting documentation on the US
   government structure: FIPS 95-1 provides a standard recognized
   structure into which domain registrations for .GOV and FED.US can
   fit; and, the US Government Manual , a special publication of the
   Federal Register, provides official documentation of the government
   structure. The latter document may be subject to more timely updates
   than the former.  Either document is suitable for determining which
   entities qualify for second-level domain registration within .GOV and
   FED.US.
</t>

<t>
   As a side effect, this RFC reduces the number of .GOV and FED.US
   level registrations and reduces the workload on the registration
   authority.  Previous versions of this document did not address the
   FED.US domain.  This document anticipates the migration of the .GOV
   domain into the FED.US domain, in keeping with common practice on the
   Internet today.
</t>
</abstract>
</front>

<seriesInfo value="2146" name="RFC" />
<format octets="29916" type="HTML" target="http://xml.resource.org/public/rfc/html/rfc2146.html" />
<format octets="20799" type="XML" target="http://xml.resource.org/public/rfc/xml/rfc2146.xml" />
</reference>


<reference target2="reference.RFC.2147.xml" anchor="RFC2147">
<front>
<title abbrev="TCP/UDP IPv6 Jumbograms">TCP and UDP over IPv6 Jumbograms</title>
<author fullname="David A. Borman" initials="D.A." surname="Borman">
<organization>Berkeley Software Design, Inc.</organization>

<address>
<postal>
<street>4719 Weston Hills Drive</street>
<street>Eagan</street>
<street>MN 55123</street>
</postal>

<phone>(612) 405-8194</phone>
<email>dab@bsdi.com</email>
</address>
</author>

<date year="1997" month="May" />
<area>Transport</area>
<keyword>jumbograms</keyword>
<keyword>internet protocol version 6</keyword>
<keyword>transmission control protocol</keyword>
<keyword>user datagram protocol</keyword>
</front>

<seriesInfo value="2147" name="RFC" />
<format octets="18387" type="HTML" target="http://xml.resource.org/public/rfc/html/rfc2147.html" />
<format octets="7607" type="XML" target="http://xml.resource.org/public/rfc/xml/rfc2147.xml" />
</reference>


<reference target2="reference.RFC.2148.xml" anchor="RFC2148">
<front>
<title abbrev="Internet White Pages Service">Deployment of the Internet White Pages Service</title>
<author fullname="Harald Tveit Alvestrand" initials="H.T." surname="Alvestrand">
<organization>UNINETT</organization>

<address>
<postal>
<street>P.O.Box 6883 Elgeseter</street>
<street>N-7002 TRONDHEIM</street>
<country>NORWAY</country>
</postal>

<phone>+47 73 59 70 94</phone>
<email>Harald.T.Alvestrand@uninett.no</email>
</address>
</author>

<author fullname="Peter Jurg" initials="P." surname="Jurg">
<organization>SURFnet</organization>

<address>
<postal>
<street>P.O.Box 19035</street>
<street>NL-3501 DA UTRECHT</street>
<street>THE</street>
<country>NETHERLANDS</country>
</postal>

<phone>+31 30 2305305</phone>
<email>Peter.Jurg@surfnet.nl</email>
</address>
</author>

<date year="1997" month="September" />
<area>Applications</area>
<keyword>white pages</keyword>
</front>

<seriesInfo value="15" name="BCP" />
<seriesInfo value="2148" name="RFC" />
<format octets="52397" type="HTML" target="http://xml.resource.org/public/rfc/html/rfc2148.html" />
<format octets="37003" type="XML" target="http://xml.resource.org/public/rfc/xml/rfc2148.xml" />
</reference>


<reference target2="reference.RFC.2149.xml" anchor="RFC2149">
<front>
<title abbrev="Multicast Server Architectures">Multicast Server Architectures for MARS-based ATM multicasting</title>
<author fullname="Rajesh Talpade" initials="R." surname="Talpade">
<organization>College of Computing</organization>

<address>
<postal>
<street>Georgia Institute of Technology</street>
<street>Atlanta</street>
<street>GA 30332-0280</street>
</postal>

<phone>(404)-894-6737</phone>
<email>taddy@cc.gatech.edu</email>
</address>
</author>

<author fullname="Mostafa H. Ammar" initials="M.H." surname="Ammar">
<organization>College of Computing</organization>

<address>
<postal>
<street>Georgia Institute of Technology</street>
<street>Atlanta</street>
<street>GA 30332-0280</street>
</postal>

<phone>(404)-894-3292</phone>
<email>ammar@cc.gatech.edu</email>
</address>
</author>

<date year="1997" month="May" />
<area>Internet</area>
<keyword>asynchronous transfer mode</keyword>
<keyword>multicast</keyword>
<keyword>non-broadcast multiple access</keyword>

<abstract>
<t>
   A mechanism to support the multicast needs of layer 3 protocols in
   general, and IP in particular, over UNI 3.0/3.1 based ATM networks
   has been described in RFC 2022.  Two basic approaches exist for the
   intra-subnet (intra-cluster) multicasting of IP packets.  One makes
   use of a mesh of point to multipoint VCs (the &apos;VC Mesh&apos; approach),
   while the other uses a shared point to multipoint tree rooted on a
   Multicast Server (MCS). This memo provides details on the design and
   implementation of an MCS, building on the core mechanisms defined in
   RFC 2022.  It also provides a mechanism for using multiple MCSs per
   group for providing fault tolerance.  This approach can be used with
   RFC 2022 based MARS server and clients, without needing any change in
   their functionality.
</t>
</abstract>
</front>

<seriesInfo value="2149" name="RFC" />
<format octets="59967" type="HTML" target="http://xml.resource.org/public/rfc/html/rfc2149.html" />
<format octets="45605" type="XML" target="http://xml.resource.org/public/rfc/xml/rfc2149.xml" />
</reference>


<reference target2="reference.RFC.2150.xml" anchor="RFC2150">
<front>
<title abbrev="Humanities and Arts on the Internet">Humanities and Arts: Sharing Center Stage on the Internet</title>
<author fullname="Janet Max" initials="J." surname="Max">
<organization>Rainfarm</organization>

<address>
<email>jlm@rainfarm.com</email>
</address>
</author>

<author fullname="Walter Stickle" initials="W." surname="Stickle">
<organization>Rainfarm</organization>

<address>
<email>wls@rainfarm.com</email>
</address>
</author>

<date year="1997" month="October" />

<abstract>
<t>This document is designed primarily for individuals who have limited knowledge of, or experience with, the Internet.</t>

<t>The purpose of this document is to provide members of the Arts and Humanities communities with an introduction to the Internet as a valuable tool, resource, and medium for the creation, presentation, and preservation of Arts and Humanities-based content.</t>

<t>The intended audience is practicing artists, scholars, related professionals, and others whose knowledge, expertise and support is important to ensuring that the Arts and Humanities are well-placed in the global information infrastructure.</t>
</abstract>
</front>

<seriesInfo value="2150" name="RFC" />
</reference>


<reference target2="reference.RFC.2151.xml" anchor="RFC2151">
<front>
<title abbrev="Internet &amp; TCP/IP Tools &amp; Utilities">A Primer On Internet and TCP/IP Tools and Utilities</title>
<author fullname="Gary C. Kessler" initials="G.C." surname="Kessler">
<organization>Hill Associates</organization>

<address>
<postal>
<street>17 Roosevelt Highway</street>
<city>Colchester</city>
<region>VT</region>
<code>05446</code>
<country>US</country>
</postal>

<phone>+1 802 655 8659</phone>
<facsimile>+1 802 655 7974</facsimile>
<email>kumquat@hill.com</email>
</address>
</author>

<author fullname="Steven D. Shepard" initials="S.D." surname="Shepard">
<organization>Hill Associates</organization>

<address>
<postal>
<street>17 Roosevelt Highway</street>
<city>Colchester</city>
<region>VT</region>
<code>05446</code>
<country>US</country>
</postal>

<phone>+1 802 655 8646</phone>
<facsimile>+1 802 655 7974</facsimile>
<email>s.shepard@hill.com</email>
</address>
</author>

<date year="1997" month="June" />

<abstract>
<t>This memo is an introductory guide to many of the most commonly-available TCP/IP and Internet tools and utilities. It also describes discussion lists accessible from the Internet, ways to obtain Internet and TCP/IP documents, and some resources that help users weave their way through the Internet.</t>
</abstract>
</front>

<seriesInfo value="2151" name="RFC" />
</reference>


<reference target2="reference.RFC.2152.xml" anchor="RFC2152">
<front>
<title abbrev="UTF-7">UTF-7 A Mail-Safe Transformation Format of Unicode</title>
<author fullname="David Goldsmith" initials="D." surname="Goldsmith">
<organization>Apple Computer, Inc.</organization>

<address>
<postal>
<street>2 Infinite Loop</street>
<street>MS: 302-2IS</street>
<street>Cupertino</street>
<street>CA 95014</street>
</postal>

<phone>408-974-1957</phone>
<facsimile>408-862-4566</facsimile>
<email>goldsmith@apple.com</email>
</address>
</author>

<author fullname="Mark Davis" initials="M." surname="Davis">
<organization>Taligent, Inc.</organization>

<address>
<postal>
<street>10201 N. DeAnza Blvd.</street>
<street>Cupertino</street>
<street>CA 95014-2233</street>
</postal>

<phone>408-777-5116</phone>
<facsimile>408-777-5081</facsimile>
<email>mark_davis@taligent.com</email>
</address>
</author>

<date year="1997" month="May" />
<area>Applications</area>
<keyword>Unicode</keyword>
<keyword>Amercian Standard Code for Information Interchange</keyword>
<keyword>UCS transformation format</keyword>
<keyword>mail</keyword>
<keyword>multipurpose internet mail extensions</keyword>
<keyword>universal multilingual character set</keyword>

<abstract>
<t>
   The Unicode Standard, version 2.0, and ISO/IEC 10646-1:1993(E) (as
   amended) jointly define a character set (hereafter referred to as
   Unicode) which encompasses most of the world&apos;s writing systems.
   However, Internet mail (STD 11, RFC 822) currently supports only 7-
   bit US ASCII as a character set. MIME (RFC 2045 through 2049) extends
   Internet mail to support different media types and character sets,
   and thus could support Unicode in mail messages. MIME neither defines
   Unicode as a permitted character set nor specifies how it would be
   encoded, although it does provide for the registration of additional
   character sets over time.
</t>

<t>
   This document describes a transformation format of Unicode that
   contains only 7-bit ASCII octets and is intended to be readable by
   humans in the limiting case that the document consists of characters
   from the US-ASCII repertoire. It also specifies how this
   transformation format is used in the context of MIME and RFC 1641,
   &quot;Using Unicode with MIME&quot;.
</t>
</abstract>
</front>

<seriesInfo value="2152" name="RFC" />
<format octets="39269" type="HTML" target="http://xml.resource.org/public/rfc/html/rfc2152.html" />
<format octets="28985" type="XML" target="http://xml.resource.org/public/rfc/xml/rfc2152.xml" />
</reference>


<reference target2="reference.RFC.2153.xml" anchor="RFC2153">
<front>
<title>PPP Vendor Extensions</title>
<author fullname="William Allen Simpson" initials="W." surname="Simpson">
<organization>DayDreamer, Computer Systems Consulting Services</organization>

<address>
<postal>
<street>1384 Fontaine</street>
<city>Madison Heights</city>
<region>MI</region>
<code>48071</code>
<country>US</country>
</postal>

<email>wsimpson@GreenDragon.com</email>
</address>
</author>

<author fullname="Karl Fox" initials="K." surname="Fox">
<organization>Ascend Communications</organization>

<address>
<postal>
<street>655 Metro Place South</street>
<street>Suite 379</street>
<city>Dublin</city>
<region>OH</region>
<code>43017</code>
<country>US</country>
</postal>

<email>karl@Ascend.com</email>
</address>
</author>

<date year="1997" month="May" />

<abstract>
<t>The Point-to-Point Protocol (PPP)provides a standard method for transporting multi-protocol datagrams over point-to-point links.  PPP defines an extensible Link Control Protocol (LCP) for establishing, configuring, and testing the data-link connection; and a family of Network Control Protocols (NCPs) for establishing and configuring different network-layer protocols.</t>

<t>This document defines a general mechanism for proprietary vendor extensions.</t>
</abstract>
</front>

<seriesInfo value="2153" name="RFC" />
</reference>


<reference target2="reference.RFC.2154.xml" anchor="RFC2154">
<front>
<title>OSPF with Digital Signatures</title>
<author fullname="Sandra Murphy" initials="S." surname="Murphy">
<organization>Trusted Information Systems</organization>

<address>
<postal>
<street>3060 Washington Road</street>
<city>Glenwood</city>
<region>MD</region>
<code>21738</code>
<country>US</country>
</postal>

<email>murphy@tis.com</email>
</address>
</author>

<author fullname="Madelyn Badger" initials="M." surname="Badger">
<organization>Trusted Information Systems</organization>

<address>
<postal>
<street>3060 Washington Road</street>
<city>Glenwood</city>
<region>MD</region>
<code>21738</code>
<country>US</country>
</postal>

<email>mrb@tis.com</email>
</address>
</author>

<author fullname="Brian Wellington" initials="B." surname="Wellington">
<organization>Trusted Information Systems</organization>

<address>
<postal>
<street>3060 Washington Road</street>
<city>Glenwood</city>
<region>MD</region>
<code>21738</code>
<country>US</country>
</postal>

<email>bwelling@tis.com</email>
</address>
</author>

<date year="1997" month="June" />

<abstract>
<t>This memo describes the extensions to OSPF required to add digital signature authentication to Link State data, and to provide a certification mechanism for router data.  Added LSA processing and key management is detailed.  A method for migration from, or co-existence with, standard OSPF V2 is described.</t>
</abstract>
</front>

<seriesInfo value="2154" name="RFC" />
</reference>


<reference target2="reference.RFC.2155.xml" anchor="RFC2155">
<front>
<title abbrev="Definitions of Managed Objects for APPN">Definitions of Managed Objects for APPN using SMIv2</title>
<author fullname="Bob Clouston" initials="B." surname="Clouston">
<organization>Cisco Systems</organization>

<address>
<postal>
<street>7025 Kit Creek Road</street>
<street>P.O. Box 14987</street>
<city>Research Triangle Park</city>
<region>NC</region>
<code>27709</code>
<country>US</country>
</postal>

<phone>+1 919 472 2333</phone>
<email>clouston@cisco.com</email>
</address>
</author>

<author fullname="Bob Moore" initials="B." surname="Moore">
<organization>IBM Corporation</organization>

<address>
<postal>
<street>800 Park Offices Drive, CNMA/664</street>
<street>P.O. Box 12195</street>
<city>Research Triangle Park</city>
<region>NC</region>
<code>27709</code>
<country>US</country>
</postal>

<phone>+1 919 254 4436</phone>
<email>remoore@ralvm6.vnet.ibm.com</email>
</address>
</author>

<date year="1997" month="June" />
</front>

<seriesInfo value="2155" name="RFC" />
</reference>


<reference target2="reference.RFC.2156.xml" anchor="RFC2156">
<front>
<title abbrev="MIXER">MIXER (Mime Internet X.400 Enhanced Relay): Mapping between X.400 and RFC 822/MIME</title>
<author fullname="Steve Kille" initials="S." surname="Kille">
<organization>Isode Ltd</organization>

<address>
<postal>
<street>The Dome, The Square</street>
<city>Richmond</city>
<region>England</region>
<code>TW9 1DT</code>
<country>UK</country>
</postal>

<phone>+44 181 3329091</phone>
<email>S.Kille@ISODE.COM</email>
</address>
</author>

<date year="1998" month="January" />
</front>

<seriesInfo value="2156" name="RFC" />
</reference>


<reference target2="reference.RFC.2157.xml" anchor="RFC2157">
<front>
<title abbrev="X.400/MIME Body Mapping">Mapping between X.400 and RFC-822/MIME Message Bodies</title>
<author fullname="Harald Tveit Alvestrand" initials="H." surname="Alvestrand">
<organization>UNINETT</organization>

<address>
<postal>
<street>P.O.box 6883 Elgeseter</street>
<city>Trondheim</city>
<region />
<code>N-7002</code>
<country>NO</country>
</postal>

<email>Harald.T.Alvestrand@uninett.no</email>
</address>
</author>

<date year="1998" month="January" />
</front>

<seriesInfo value="2157" name="RFC" />
</reference>


<reference target2="reference.RFC.2158.xml" anchor="RFC2158">
<front>
<title>X.400 Image Body Parts</title>
<author fullname="Harald Tveit Alvestrand" initials="H.T." surname="Alvestrand">
<organization>UNINETT</organization>

<address>
<postal>
<street>Postboks 6883 Elgeseter</street>
<street>N-7002 TRONDHEIM</street>
</postal>

<phone>+47 73 59 70 94</phone>
<email>Harald.T.Alvestrand@uninett.no</email>
</address>
</author>

<date year="1998" month="January" />
<area>Applications</area>
<keyword>X.400</keyword>
<keyword>ITU message handling service protocol</keyword>
<keyword>multipurpose internet mail extensions</keyword>
</front>

<seriesInfo value="2158" name="RFC" />
<format octets="15957" type="HTML" target="http://xml.resource.org/public/rfc/html/rfc2158.html" />
<format octets="5077" type="XML" target="http://xml.resource.org/public/rfc/xml/rfc2158.xml" />
</reference>


<reference target2="reference.RFC.2159.xml" anchor="RFC2159">
<front>
<title abbrev="MIME Body Part for FAX">A MIME Body Part for FAX</title>
<author fullname="Harald Tveit Alvestrand" initials="H.T." surname="Alvestrand">
<organization>UNINETT</organization>

<address>
<postal>
<street>P.O.box 6883 Elgeseter</street>
<street>N-7002 Trondheim</street>
<country>NORWAY</country>
</postal>

<email>Harald.T.Alvestrand@uninett.no</email>
</address>
</author>

<date year="1998" month="January" />
<area>Applications</area>
<keyword>ITU message handling service protocol</keyword>
<keyword>facsimile</keyword>
<keyword>multipurpose internet mail extensions</keyword>
</front>

<seriesInfo value="2159" name="RFC" />
<format octets="21518" type="HTML" target="http://xml.resource.org/public/rfc/html/rfc2159.html" />
<format octets="10475" type="XML" target="http://xml.resource.org/public/rfc/xml/rfc2159.xml" />
</reference>


<reference target2="reference.RFC.2160.xml" anchor="RFC2160">
<front>
<title abbrev="PostScript in MIME">Carrying PostScript in X.400 and MIME</title>
<author fullname="Harald Tveit Alvestrand" initials="H.T." surname="Alvestrand">
<organization>UNINETT</organization>

<address>
<postal>
<street>Postboks 6883 Elgeseter</street>
<street>N-7002 TRONDHEIM</street>
</postal>

<phone>+47 73 59 70 94</phone>
<email>Harald.T.Alvestrand@uninett.no</email>
</address>
</author>

<date year="1998" month="January" />
<area>Applications</area>
<keyword>MIME</keyword>
<keyword>PostScript</keyword>
<keyword>ITU message handling service protocol</keyword>
<keyword>multipurpose internet mail extensions</keyword>
</front>

<seriesInfo value="2160" name="RFC" />
<format octets="17322" type="HTML" target="http://xml.resource.org/public/rfc/html/rfc2160.html" />
<format octets="5563" type="XML" target="http://xml.resource.org/public/rfc/xml/rfc2160.xml" />
</reference>


<reference target2="reference.RFC.2161.xml" anchor="RFC2161">
<front>
<title abbrev="ODA MIME">A MIME Body Part for ODA</title>
<author fullname="Harald Tveit Alvestrand" initials="H.T." surname="Alvestrand">
<organization>UNINETT</organization>

<address>
<postal>
<street>Postboks 6883 Elgeseter</street>
<street>N-7002 TRONDHEIM</street>
</postal>

<phone>+47 73 59 70 94</phone>
<email>Harald.T.Alvestrand@uninett.no</email>
</address>
</author>

<date year="1998" month="January" />
<area>Applications</area>
<keyword>ODA</keyword>
<keyword>ITU message handling service protocol</keyword>
<keyword>multipurpose internet mail extensions</keyword>
</front>

<seriesInfo value="2161" name="RFC" />
<format octets="15455" type="HTML" target="http://xml.resource.org/public/rfc/html/rfc2161.html" />
<format octets="6662" type="XML" target="http://xml.resource.org/public/rfc/xml/rfc2161.xml" />
</reference>


<reference target2="reference.RFC.2162.xml" anchor="RFC2162">
<front>
<title abbrev="MaXIM-11">MaXIM-11 - Mapping between X.400 / Internet mail and Mail-11 mail</title>
<author fullname="Claudio Allocchio" initials="C." surname="Allocchio">
<organization>Sincrotrone Trieste</organization>

<address>
<postal>
<street>SS 14 Km 163.5 Basovizza</street>
<city>Trieste</city>
<region />
<code>I 34012</code>
<country>IT</country>
</postal>

<phone>+39 40 3758523</phone>
<facsimile>+39 40 3758565</facsimile>
<email>Claudio.Allocchio@elettra.Trieste.it</email>
</address>
</author>

<date year="1998" month="January" />

<abstract>
<t>This document describes a set of mappings which will enable inter working between systems operating the ISO/IEC 10021 - CCITT (now ITU)  X.400 Recommendations on Message Handling Systems, and systems running the Mail-11 (also known as DECnet mail or VMSmail) protocol. The specifications are valid both within DECnet Phase IV and DECnet/OSI addressing and routing scheme.</t>

<t>The complete scenario of X.400 / MIME / Mail-11 is also considered, in order to cover the possible complex cases arising in multiple gateway translations.</t>

<t>This document covers mainly the X.400 O/R address to/from Mail-11 address mapping and the RFC822 to/from Mail-11 ones; other mappings are based on MIXER specifications. Bodypart mappings are not specified in this document: MIXER and MIME-MHS specifications can be applied to map bodyparts between X.400, MIME and Mail-11, too. In fact MIME encoding can be used without modifications within Mail-11 text bodyparts.</t>

<t>This document obsoletes RFC 1405, which was a combined effort of TERENA Working Group on Messaging, and the IETF X.400 Ops Working Group. This update was prepared by IETF MIXER working group.</t>
</abstract>
</front>

<seriesInfo value="2162" name="RFC" />
</reference>


<reference target2="reference.RFC.2163.xml" anchor="RFC2163">
<front>
<title abbrev="MIXER MCGAM">Using the Internet DNS to Distribute MIXER Conformant Global Address Mapping (MCGAM)</title>
<author fullname="Claudio Allocchio" initials="C." surname="Allocchio">
<organization>Sincrotrone Trieste</organization>

<address>
<postal>
<street>SS 14 Km 163.5 Basovizza</street>
<city>Trieste</city>
<region />
<code>I 34012</code>
<country>IT</country>
</postal>

<phone>+39 40 3758523</phone>
<facsimile>+39 40 3758565</facsimile>
<email>Claudio.Allocchio@elettra.trieste.it</email>
</address>
</author>

<date year="1998" month="January" />

<abstract>
<t>This memo is the complete technical specification to store in the Internet Domain Name System (DNS) the mapping information (MCGAM) needed by MIXER conformant e-mail gateways and other tools to map RFC822 domain names into X.400 O/R names and vice versa.  Mapping information can be managed in a distributed rather than a centralised way. Organizations can publish their MIXER mapping or preferred gateway routing information using just local resources (their local DNS server), avoiding the need for a strong coordination with any centralised organization. MIXER conformant gateways and tools located on Internet hosts can retrieve the mapping information querying the DNS instead of having fixed tables which need to be centrally updated and distributed.</t>

<t>This memo obsoletes RFC1664. It includes the changes introduced by MIXER specification with respect to RFC1327: the new 'gate1' (O/R addresses to domain) table is fully supported. Full backward compatibility with RFC1664 specification is mantained, too.</t>

<t>RFC1664 was a joint effort of IETF X400 operation working group (x400ops) and TERENA (formely named "RARE") Mail and Messaging working group (WG-MSG). This update was performed by the IETF MIXER working group.</t>
</abstract>
</front>

<seriesInfo value="2163" name="RFC" />
</reference>


<reference target2="reference.RFC.2164.xml" anchor="RFC2164">
<front>
<title abbrev="X.500/LDAP Directory to Support MIXER">Use of an X.500/LDAP directory to support MIXER address mapping</title>
<author fullname="Steve Kille" initials="S." surname="Kille">
<organization>Isode Ltd.</organization>

<address>
<postal>
<street>The Dome</street>
<street>The Square</street>
<street>Richmond</street>
<street>TW9 1DT</street>
<street>England</street>
</postal>

<phone>+44-181-332-9091</phone>
<email>S.Kille@ISODE.COM</email>
</address>
</author>

<date year="1998" month="January" />
<area>Applications</area>
<keyword>ITU directory service protocol</keyword>
<keyword>directory</keyword>
<keyword>lightweight directory access protocol</keyword>
</front>

<seriesInfo value="2164" name="RFC" />
<format octets="28531" type="HTML" target="http://xml.resource.org/public/rfc/html/rfc2164.html" />
<format octets="16990" type="XML" target="http://xml.resource.org/public/rfc/xml/rfc2164.xml" />
</reference>


<reference target2="reference.RFC.2165.xml" anchor="RFC2165">
<front>
<title>Service Location Protocol</title>
<author fullname="John Veizades" initials="J." surname="Veizades">
<organization>@Home Network</organization>

<address>
<postal>
<street>385 Ravendale Dr.</street>
<city>Mountain View</city>
<region>CA</region>
<code>94043</code>
<country>US</country>
</postal>

<phone>+1 415 944 7332</phone>
<facsimile>+1 415 944 8500</facsimile>
<email>veizades@home.com</email>
</address>
</author>

<author fullname="Erik Guttman" initials="E." surname="Guttman">
<organization>Sun Microsystems</organization>

<address>
<postal>
<street>Gaisbergstr. 6</street>
<city>Heidelberg</city>
<region />
<code>69115</code>
<country>DE</country>
</postal>

<phone>+1 415 336 6697</phone>
<email>Erik.Guttman@eng.sun.com</email>
</address>
</author>

<author fullname="Charles E. Perkins" initials="C.E." surname="Perkins">
<organization>Sun Microsystems</organization>

<address>
<postal>
<street>2550 Garcia Avenue</street>
<city>Mountain View</city>
<region>CA</region>
<code>94043</code>
<country>US</country>
</postal>

<phone>+1 415 336 7153</phone>
<facsimile>+1 415 336 0670</facsimile>
<email>cperkins@Corp.sun.com</email>
</address>
</author>

<author fullname="Scott Kaplan" initials="S." surname="Kaplan">
<organization />

<address>
<postal>
<street>346 Fair Oaks St.</street>
<city>San Francisco</city>
<region>CA</region>
<code>94110</code>
<country>US</country>
</postal>

<phone>+1 415 285 4526</phone>
<email>scott@catch22.com</email>
</address>
</author>

<date year="1997" month="June" />

<abstract>
<t>The Service Location Protocol provides a scalable framework for the discovery and selection of network services.  Using this protocol, computers using the Internet no longer need so much static configuration of network services for network based applications. This is especially important as computers become more portable, and users less tolerant or able to fulfill the demands of network system administration.</t>
</abstract>
</front>

<seriesInfo value="2165" name="RFC" />
</reference>


<reference target2="reference.RFC.2166.xml" anchor="RFC2166">
<front>
<title abbrev="APPN Implementer&apos;s Workshop">APPN Implementer's Workshop Closed Pages Document DLSw v2.0 Enhancements</title>
<author fullname="David Bryant" initials="D." surname="Bryant">
<organization>3Com Corporation</organization>

<address>
<postal>
<street>5400 Bayfront Plaza</street>
<street>MS 2418</street>
<city>Santa Clara</city>
<region>CA</region>
<code>95052</code>
<country>US</country>
</postal>

<phone>+1 408 764 5272</phone>
<email>David_Bryant@3mail.3com.com</email>
</address>
</author>

<author fullname="Paul Brittain" initials="P." surname="Brittain">
<organization>Data Connection Ltd</organization>

<address>
<postal>
<street>Windsor House</street>
<street>Pepper Street</street>
<city>Chester</city>
<region>England</region>
<code>CH1 1DF</code>
<country>UK</country>
</postal>

<phone>+44 1244 313440</phone>
<email>pjb@datcon.co.uk</email>
</address>
</author>

<date year="1997" month="June" />

<abstract>
<t>This document specifies</t>

<t>- a set of extensions to RFC 1795 designed to improve the scalability of DLSw</t>

<t>- clarifications to RFC 1795 in the light of the implementation experience to-date.</t>

<t>It is assumed that the reader is familiar with DLSw and RFC 1795.  No effort has been made to explain these existing protocols or associated terminology.</t>

<t>This document was developed in the DLSw Related Interest Group (RIG) of the APPN Implementers Workshop (AIW). If you would like to participate in future DLSw discussions, please subscribe to the DLSw RIG mailing lists by sending a mail to majordomo@raleigh.ibm.com specifying 'subscribe aiw-dlsw' as the body of the message.</t>
</abstract>
</front>

<seriesInfo value="2166" name="RFC" />
</reference>


<reference target2="reference.RFC.2167.xml" anchor="RFC2167">
<front>
<title abbrev="RWhois Protocol">Referral Whois (RWhois) Protocol V1.5</title>
<author fullname="Scott Williamson" initials="S." surname="Williamson">
<organization>Network Solutions, Inc.</organization>

<address>
<postal>
<street>505 Huntmar Park Drive</street>
<city>Herndon</city>
<region>VA</region>
<code>22070-5100</code>
<country>US</country>
</postal>

<phone>+1 703 742 0400</phone>
<email>scottw@rwhois.net</email>
</address>
</author>

<author fullname="Mark Kosters" initials="M." surname="Kosters">
<organization>Network Solutions, Inc.</organization>

<address>
<postal>
<street>505 Huntmar Park Drive</street>
<city>Herndon</city>
<region>VA</region>
<code>22070-5100</code>
<country>US</country>
</postal>

<phone>+1 703 742 0400</phone>
<email>markk@internic.net</email>
</address>
</author>

<author fullname="David Blacka" initials="D." surname="Blacka">
<organization>Network Solutions, Inc.</organization>

<address>
<postal>
<street>505 Huntmar Park Drive</street>
<city>Herndon</city>
<region>VA</region>
<code>22070-5100</code>
<country>US</country>
</postal>

<phone>+1 703 742 0400</phone>
<email>davidb@rwhois.net</email>
</address>
</author>

<author fullname="Jasdip Singh" initials="J." surname="Singh">
<organization>Network Solutions, Inc.</organization>

<address>
<postal>
<street>505 Huntmar Park Drive</street>
<city>Herndon</city>
<region>VA</region>
<code>22070-5100</code>
<country>US</country>
</postal>

<phone>+1 703 742 0400</phone>
<email>jasdips@rwhois.net</email>
</address>
</author>

<author fullname="Koert Zeilstra" initials="K." surname="Zeilstra">
<organization>Network Solutions, Inc.</organization>

<address>
<postal>
<street>505 Huntmar Park Drive</street>
<city>Herndon</city>
<region>VA</region>
<code>22070-5100</code>
<country>US</country>
</postal>

<phone>+1 703 742 0400</phone>
<email>kzeil@rwhois.net</email>
</address>
</author>

<date year="1997" month="June" />

<abstract>
<t>This memo describes Version 1.5 of the client/server interaction of RWhois.  RWhois provides a distributed system for the discovery, retrieval, and maintenance of directory information. This system is primarily hierarchical by design. It allows for the deterministic routing of a query based on hierarchical tags, referring the user closer to the maintainer of the information. While RWhois can be considered a generic directory services protocol, it distinguishes itself from other protocols by providing an integrated, hierarchical architecture and query routing mechanism.</t>
</abstract>
</front>

<seriesInfo value="2167" name="RFC" />
</reference>


<reference target2="reference.RFC.2168.xml" anchor="RFC2168">
<front>
<title abbrev="Resolution of URIs Using the DNS">Resolution of Uniform Resource Identifiers using the Domain Name System</title>
<author fullname="Ron Daniel" initials="R." surname="Daniel">
<organization>Los Alamos National Laboratory</organization>

<address>
<postal>
<street>MS B287</street>
<city>Los Alamos</city>
<region>NM</region>
<code>87545</code>
<country>US</country>
</postal>

<phone>+1 505 665 0597</phone>
<facsimile>+1 505 665 4939</facsimile>
<email>rdaniel@lanl.gov</email>
</address>
</author>

<author fullname="Michael Mealling" initials="M." surname="Mealling">
<organization>Network Solutions</organization>

<address>
<postal>
<street>505 Huntmar Park Drive</street>
<city>Herndon</city>
<region>VA</region>
<code>22070</code>
<country>US</country>
</postal>

<phone>+1 703 742 0400</phone>
<facsimile>+1 703 742 9552</facsimile>
<email>michaelm@internic.net</email>
<uri>http://www.netsol.com/</uri>
</address>
</author>

<date year="1997" month="June" />

<abstract>
<t>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 an 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).</t>

<t>The requirements document for URN resolution systemsdefines the concept of a "resolver discovery service". This document describes the first, experimental, RDS. It is implemented by 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.</t>

<t>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, the NAPTR record allows those services to be replicated for the purposes of fault tolerance and load balancing.</t>
</abstract>
</front>

<seriesInfo value="2168" name="RFC" />
</reference>


<reference target2="reference.RFC.2169.xml" anchor="RFC2169">
<front>
<title abbrev="HTTP in URN Resolution">A Trivial Convention for using HTTP in URN Resolution</title>
<author fullname="R. Daniel" initials="R." surname="Daniel">
<organization>Los Alamos National Laboratory, Advanced Computing Lab</organization>

<address>
<postal>
<street>MS B287</street>
<city>Los Alamos</city>
<region>NM</region>
<code>87545</code>
<country>US</country>
</postal>

<phone>+1 505 665 0597</phone>
<facsimile>+1 505 665 4939</facsimile>
<email>rdaniel@lanl.gov</email>
</address>
</author>

<date year="1997" month="June" />

<abstract>
<t>The Uniform Resource Names Working Group (URN-WG) was formed to specify persistent, location-independent names for network accessible resources, as well as resolution mechanisms to retrieve the resources given such a name. At this time the URN-WG is considering one particular resolution mechanism, the NAPTR proposal. That proposal specifies how a client may find a "resolver" for a URN. A resolver is a database that can provide information about the resource identified by a URN, such as the resource's location, a bibliographic description, or even the resource itself. The protocol used for the client to communicate with the resolver is not specified in the NAPTR proposal.  Instead, the NAPTR resource record provides a field that indicates the "resolution protocol" and "resolution service requests" offered by the resolver.</t>

<t>This document specifies the "THTTP" resolution protocol - a trivial convention for encoding resolution service requests and responses as HTTP 1.0 or 1.1 requests and responses.  The primary goal of THTTP is to be simple to implement so that existing HTTP servers may easily add support for URN resolution. We expect that the databases used by early resolvers will be useful when more sophisticated resolution protocols are developed later.</t>
</abstract>
</front>

<seriesInfo value="2169" name="RFC" />
</reference>


<reference target2="reference.RFC.2170.xml" anchor="RFC2170">
<front>
<title abbrev="AREQUIPA">Application REQuested IP over ATM (AREQUIPA)</title>
<author fullname="Werner Almesberger" initials="W." surname="Almesberger">
<organization>Jean-Yves Le Boudec,</organization>

<address>
<postal>
<street>Philippe Oechslin (contact author)</street>
</postal>

<email>{almesber,</email>
</address>
</author>

<date year="1997" month="July" />
<area>Internet</area>
<keyword>asynchronous transfer mode</keyword>

<abstract>
<t>
   This RFC has not had the benefit of the rigorous peer review that is
   part of the process in an IETF working group.  The technology it
   describes has been implemented and is now undergoing testing. It
   would be wise to analyze the results of this testing as well as to
   understand alternatives before committing to this approach for IP
   over ATM with QoS guarantees.
</t>

<t>
   This document specifies a method for allowing ATM-attached hosts that
   have direct ATM connectivity to set up end-to-end IP over ATM
   connections within the reachable ATM cloud, on request from
   applications, and for the exclusive use by the requesting
   applications. This allows the requesting applications to benefit in a
   straightforward way from ATM&apos;s inherent ability to guarantee the
   quality of service (QoS).
</t>

<t>
   Given a mapping from service classes, as defined by INTSERV, to
   ATM traffic descriptors, Arequipa can be used to implement integrated
   services over ATM link layers. Usage of Arequipa to provide
   integrated services even if ATM is only available for intermediate
   links is not discussed in this document but should be straight-
   forward.
</t>

<t>
   The major advantage of using an approach like Arequipa is that it
   needs to be implemented only on the hosts using it. It requires no
   extra service (eg. NHRP or RSVP) to be deployed on the switches or
   routers of the ATM cloud.
   We discuss the implementation of Arequipa for hosts running IPv4 and
   IPv6. As an illustration, we also discuss how World-Wide-Web
   applications can use Arequipa to deliver documents with a guaranteed
   quality of service.
</t>

<t>
   In particular we show how

<list>
<t>
     - Arequipa can be implemented in IPv4 by slightly modifying the
</t>

<t>
     - Arequipa can be implemented in IPv6 by the appropriate use of
       flow labels and the extension of the neighbour cache,
</t>

<t>
     - Arequipa can be used in the Web by adding extra information in
       the headers of HTTP requests and responses.
</t>
</list>
</t>

<t>
   Finally, we address safety and security implications.
</t>
</abstract>

<note title="IESG Note">
<t>
   This RFC has not had the benefit of the rigorous peer review that is
   part of the process in an IETF working group.  The technology it
   describes has been implemented and is now undergoing testing. It
   would be wise to analyze the results of this testing as well as to
   understand alternatives before committing to this approach for IP
   over ATM with QoS guarantees.
</t>
</note>
</front>

<seriesInfo value="2170" name="RFC" />
<format octets="35445" type="HTML" target="http://xml.resource.org/public/rfc/html/rfc2170.html" />
<format octets="25331" type="XML" target="http://xml.resource.org/public/rfc/xml/rfc2170.xml" />
</reference>


<reference target2="reference.RFC.2171.xml" anchor="RFC2171">
<front>
<title abbrev="MAPOS">MAPOS - Multiple Access Protocol over SONET/SDH  Version 1</title>
<author fullname="Ken Murakami" initials="K." surname="Murakami">
<organization>NTT Software Laboratories</organization>

<address>
<postal>
<street>3-9-11</street>
<street>Midori-cho</street>
<street>Musashino-shi</street>
<street>Tokyo-180</street>
<country>Japan</country>
</postal>

<email>murakami@ntt-20.ecl.net</email>
</address>
</author>

<author fullname="Mitsuru Maruyama" initials="M." surname="Maruyama">
<organization>NTT Software Laboratories</organization>

<address>
<postal>
<street>3-9-11</street>
<street>Midori-cho</street>
<street>Musashino-shi</street>
<street>Tokyo-180</street>
<country>Japan</country>
</postal>

<email>mitsuru@ntt-20.ecl.net</email>
</address>
</author>

<date year="1997" month="June" />
<area>Internet</area>
<keyword>SONET</keyword>
<keyword>synchronous data hierarchy</keyword>
<keyword>synchronous optical network</keyword>
</front>

<seriesInfo value="2171" name="RFC" />
<format octets="31333" type="HTML" target="http://xml.resource.org/public/rfc/html/rfc2171.html" />
<format octets="19746" type="XML" target="http://xml.resource.org/public/rfc/xml/rfc2171.xml" />
</reference>


<reference target2="reference.RFC.2172.xml" anchor="RFC2172">
<front>
<title abbrev="MAPOS">MAPOS Version 1 Assigned Numbers</title>
<author fullname="Mitsuru Maruyama" initials="M." surname="Maruyama">
<organization>NTT Software Laboratories</organization>

<address>
<postal>
<street>3-9-11</street>
<street>Midori-cho</street>
<street>Musashino-shi</street>
<street>Tokyo-180</street>
<country>Japan</country>
</postal>

<email>mitsuru@ntt-20.ecl.net</email>
</address>
</author>

<author fullname="Ken Murakami" initials="K." surname="Murakami">
<organization>NTT Software Laboratories</organization>

<address>
<postal>
<street>3-9-11</street>
<street>Midori-cho</street>
<street>Musashino-shi</street>
<street>Tokyo-180</street>
<country>Japan</country>
</postal>

<email>murakami@ntt-20.ecl.net</email>
</address>
</author>

<date year="1997" month="June" />
<area>Internet</area>
<keyword>SONET</keyword>
<keyword>assigned numbers</keyword>
<keyword>synchronous optical network</keyword>
</front>

<seriesInfo value="2172" name="RFC" />
<format octets="17524" type="HTML" target="http://xml.resource.org/public/rfc/html/rfc2172.html" />
<format octets="7048" type="XML" target="http://xml.resource.org/public/rfc/xml/rfc2172.xml" />
</reference>


<reference target2="reference.RFC.2173.xml" anchor="RFC2173">
<front>
<title abbrev="MAPOS">A MAPOS version 1 Extension - Node Switch Protocol</title>
<author fullname="Ken Murakami" initials="K." surname="Murakami">
<organization>NTT Software Laboratories</organization>

<address>
<postal>
<street>3-9-11</street>
<street>Midori-cho</street>
<street>Musashino-shi</street>
<street>Tokyo 180</street>
<country>Japan</country>
</postal>

<email>murakami@ntt-20.ecl.net</email>
</address>
</author>

<author fullname="Mitsuru Maruyama" initials="M." surname="Maruyama">
<organization>NTT Software Laboratories</organization>

<address>
<postal>
<street>3-9-11</street>
<street>Midori-cho</street>
<street>Musashino-shi</street>
<street>Tokyo 180</street>
<country>Japan</country>
</postal>

<email>mitsuru@ntt-20.ecl.net</email>
</address>
</author>

<date year="1997" month="June" />
<area>Internet</area>
<keyword>encapsulate</keyword>
<keyword>synchronous optical network</keyword>

<abstract>
<t>
   This document describes a MAPOS extension, Node Switch Protocol, for
   automatic node address assignment. MAPOS is a multiple access
   protocol for transmission of network-protocol datagrams, encapsulated
   in High-Level Data Link Control (HDLC) frames, over SONET/SDH. NSP
   automates the HDLC address configuration of each node. Using NSP, a
   node retrieves its HDLC address from the switch to which it is
   connected.
</t>
</abstract>
</front>

<seriesInfo value="2173" name="RFC" />
<format octets="24610" type="HTML" target="http://xml.resource.org/public/rfc/html/rfc2173.html" />
<format octets="14405" type="XML" target="http://xml.resource.org/public/rfc/xml/rfc2173.xml" />
</reference>


<reference target2="reference.RFC.2174.xml" anchor="RFC2174">
<front>
<title abbrev="MAPOS">A MAPOS version 1 Extension - Switch-Switch Protocol</title>
<author fullname="Ken Murakami" initials="K." surname="Murakami">
<organization>NTT Software Laboratories</organization>

<address>
<postal>
<street>3-9-11</street>
<street>Midori-cho</street>
<street>Musashino-shi</street>
<city>Tokyo</city>
<region />
<code>180</code>
<country>JP</country>
</postal>

<email>murakami@ntt-20.ecl.net</email>
</address>
</author>

<author fullname="Mitsuru Maruyama" initials="M." surname="Maruyama">
<organization>NTT Software Laboratories</organization>

<address>
<postal>
<street>3-9-11</street>
<street>Midori-cho</street>
<street>Musashino-shi</street>
<city>Tokyo</city>
<region />
<code>180</code>
<country>JP</country>
</postal>

<email>mitsuru@ntt-20.ecl.net</email>
</address>
</author>

<date year="1997" month="June" />

<abstract>
<t>This document describes a MAPOS version 1 extension, SSP (Switch Switch Protocol).  MAPOS is a multiple access protocol for transmission of network-protocol packets, encapsulated in High-Level Data Link Control (HDLC) frames, over SONET/SDH. In MAPOS network, a SONET switch provides the multiple access capability to end nodes. SSP is a protocol of Distance Vector family and provides unicast and broadcast/multicast routing for multiple SONET switch environment.</t>
</abstract>
</front>

<seriesInfo value="2174" name="RFC" />
</reference>


<reference target2="reference.RFC.2175.xml" anchor="RFC2175">
<front>
<title abbrev="MAPOS 16">MAPOS 16 - Multiple Access Protocol over SONET/SDH with 16 Bit Addressing</title>
<author fullname="Ken Murakami" initials="K." surname="Murakami">
<organization>NTT Software Laboratories</organization>

<address>
<postal>
<street>3-9-11</street>
<street>Midori-cho</street>
<street>Musashino-shi</street>
<street>Tokyo-180</street>
<country>Japan</country>
</postal>

<email>murakami@ntt-20.ecl.net</email>
</address>
</author>

<author fullname="Mitsuru Maruyama" initials="M." surname="Maruyama">
<organization>NTT Software Laboratories</organization>

<address>
<postal>
<street>3-9-11</street>
<street>Midori-cho</street>
<street>Musashino-shi</street>
<street>Tokyo-180</street>
<country>Japan</country>
</postal>

<email>mitsuru@ntt-20.ecl.net</email>
</address>
</author>

<date year="1997" month="June" />
<area>Internet</area>
<keyword>MAPOS</keyword>
<keyword>encapsulate</keyword>
<keyword>synchronous data hierarchy</keyword>
<keyword>synchronous optical network</keyword>
</front>

<seriesInfo value="2175" name="RFC" />
<format octets="25501" type="HTML" target="http://xml.resource.org/public/rfc/html/rfc2175.html" />
<format octets="14014" type="XML" target="http://xml.resource.org/public/rfc/xml/rfc2175.xml" />
</reference>


<reference target2="reference.RFC.2176.xml" anchor="RFC2176">
<front>
<title abbrev="MAPOS">IPv4 over MAPOS Version 1</title>
<author fullname="Ken Murakami" initials="K." surname="Murakami">
<organization>NTT Software Laboratories</organization>

<address>
<postal>
<street>3-9-11</street>
<street>Midori-cho</street>
<street>Musashino-shi</street>
<street>Tokyo-180</street>
<country>Japan</country>
</postal>

<email>murakami@ntt-20.ecl.net</email>
</address>
</author>

<author fullname="Mitsuru Maruyama" initials="M." surname="Maruyama">
<organization>NTT Software Laboratories</organization>

<address>
<postal>
<street>3-9-11</street>
<street>Midori-cho</street>
<street>Musashino-shi</street>
<street>Tokyo-180</street>
<country>Japan</country>
</postal>

<email>mitsuru@ntt-20.ecl.net</email>
</address>
</author>

<date year="1997" month="June" />
<area>Internet</area>
<keyword>MAPOS</keyword>
<keyword>encapsulate</keyword>
<keyword>internet protocol version 4</keyword>
<keyword>synchronous optical network</keyword>
</front>

<seriesInfo value="2176" name="RFC" />
<format octets="26426" type="HTML" target="http://xml.resource.org/public/rfc/html/rfc2176.html" />
<format octets="14866" type="XML" target="http://xml.resource.org/public/rfc/xml/rfc2176.xml" />
</reference>


<reference target2="reference.RFC.2177.xml" anchor="RFC2177">
<front>
<title>IMAP4 IDLE command</title>
<author fullname="Barry Leiba" initials="B." surname="Leiba">
<organization>IBM T.J. Watson Research Center</organization>

<address>
<postal>
<street>30 Saw Mill River Road</street>
<street>Hawthorne</street>
<street>NY  10532</street>
</postal>

<email>leiba@watson.ibm.com</email>
</address>
</author>

<date year="1997" month="June" />
<area>Applications</area>
<keyword>IMAP</keyword>
<keyword>internet message access protocol</keyword>
</front>

<seriesInfo value="2177" name="RFC" />
<format octets="19043" type="HTML" target="http://xml.resource.org/public/rfc/html/rfc2177.html" />
<format octets="8005" type="XML" target="http://xml.resource.org/public/rfc/xml/rfc2177.xml" />
</reference>


<reference target2="reference.RFC.2178.xml" anchor="RFC2178">
<front>
<title>OSPF Version 2</title>
<author fullname="John Moy" initials="J." surname="Moy">
<organization>Cascade Communications Corp.</organization>

<address>
<postal>
<street>5 Carlisle Road</street>
<city>Westford</city>
<region>MA</region>
<code>01886</code>
<country>US</country>
</postal>

<phone>+1 508 952 1367</phone>
<facsimile>+1 508 692 9214</facsimile>
<email>jmoy@casc.com</email>
</address>
</author>

<date year="1997" month="July" />

<abstract>
<t>This memo documents version 2 of the OSPF protocol. OSPF is a link-state routing protocol.  It is designed to be run internal to a single Autonomous System.  Each OSPF router maintains an identical database describing the Autonomous System's topology.  From this database, a routing table is calculated by constructing a shortest-path tree.</t>

<t>OSPF recalculates routes quickly in the face of topological changes, utilizing a minimum of routing protocol traffic.  OSPF provides support for equal-cost multipath.  An area routing capability is provided, enabling an additional level of routing protection and a reduction in routing protocol traffic.  In addition, all OSPF routing protocol exchanges are authenticated.</t>

<t>The differences between this memo and RFC 1583 are explained in Appendix G. All differences are backward-compatible in nature. Implementations of this memo and of RFC 1583 will interoperate.</t>

<t>Please send comments to ospf@gated.cornell.edu.</t>
</abstract>
</front>

<seriesInfo value="2178" name="RFC" />
</reference>


<reference target2="reference.RFC.2179.xml" anchor="RFC2179">
<front>
<title abbrev="Trade Show Security">Network Security For Trade Shows</title>
<author fullname="R. Allen Gwinn, Jr." initials="R.A." surname="Gwinn">
<organization>Associate Director, Computing</organization>

<address>
<postal>
<street>Business Information Center</street>
<street>Southern Methodist University</street>
<street>Dallas</street>
<street>TX  75275</street>
</postal>

<phone>214/768-3186</phone>
<email>allen@mail.cox.smu.edu</email>
</address>
</author>

<date year="1997" month="July" />
<area>Operations</area>
<area>Security</area>
<keyword>attack</keyword>
<keyword>security</keyword>

<abstract>
<t>
   This document is designed to assist vendors and other participants in
   trade shows, such as Networld+Interop, in designing effective
   protection against network and system attacks by unauthorized
   individuals.  Generally, it has been observed that many system
   administrators and trade show coordinators tend to overlook the
   importance of system security at trade shows. In fact, systems at
   trade shows are at least as prone to attack as office-based
   platforms. Trade show systems should be treated as seriously as an
   office computer. A breach of security of a trade show system can
   render -- and has rendered -- an exhibitor&apos;s demonstrations
   inoperable -- sometimes for the entire event!
</t>

<t>
   This document is not intended to replace the multitudes of
   comprehensive books on the subject of Internet security.  Rather, its
   purpose is to provide a checklist-style collection of frequently
   overlooked, simple ways to minimize the chance of a costly attack.
   We encourage exhibitors to pay special attention to this document and
   share it with all associated representatives.
</t>
</abstract>
</front>

<seriesInfo value="2179" name="RFC" />
<format octets="32727" type="HTML" target="http://xml.resource.org/public/rfc/html/rfc2179.html" />
<format octets="20909" type="XML" target="http://xml.resource.org/public/rfc/xml/rfc2179.xml" />
</reference>


<reference target2="reference.RFC.2180.xml" anchor="RFC2180">
<front>
<title abbrev="IMAP4">IMAP4 Multi-Accessed Mailbox Practice</title>
<author fullname="Mike Gahrns" initials="M." surname="Gahrns">
<organization>Microsoft</organization>

<address>
<postal>
<street>One Microsoft Way</street>
<street>Redmond</street>
<street>WA</street>
<street>98072</street>
</postal>

<phone>(206) 936-9833</phone>
<email>mikega@microsoft.com</email>
</address>
</author>

<date year="1997" month="July" />
<area>Applications</area>
<keyword>IMAP</keyword>
<keyword>internet message access protocol</keyword>
<keyword>mail</keyword>
</front>

<seriesInfo value="2180" name="RFC" />
<format octets="38112" type="HTML" target="http://xml.resource.org/public/rfc/html/rfc2180.html" />
<format octets="27167" type="XML" target="http://xml.resource.org/public/rfc/xml/rfc2180.xml" />
</reference>


<reference target2="reference.RFC.2181.xml" anchor="RFC2181">
<front>
<title abbrev="DNS Clarifications">Clarifications to the DNS Specification</title>
<author fullname="Robert Elz" initials="R." surname="Elz">
<organization>Computer Science</organization>

<address>
<postal>
<street>Parkville</street>
<street>Victoria</street>
<street>3052</street>
<street>Australia.</street>
</postal>

<email>kre@munnari.OZ.AU</email>
<uri>e</uri>
</address>
</author>

<author fullname="Randy Bush" initials="R." surname="Bush">
<organization>RGnet, Inc.</organization>

<address>
<postal>
<street>5147 Crystal Springs Drive</street>
<street>Bainbridge Island</street>
<street>Washington</street>
<street>98110</street>
<street>United States.</street>
<country>NE</country>
</postal>

<email>randy@psg.com</email>
</address>
</author>

<date year="1997" month="July" />
<area>Applications</area>
<keyword>DNS</keyword>
<keyword>domain name system</keyword>
</front>

<seriesInfo value="2181" name="RFC" />
<format octets="54106" type="HTML" target="http://xml.resource.org/public/rfc/html/rfc2181.html" />
<format octets="38795" type="XML" target="http://xml.resource.org/public/rfc/xml/rfc2181.xml" />
</reference>


<reference target2="reference.RFC.2182.xml" anchor="RFC2182">
<front>
<title abbrev="DNS Secondary Services">Selection and Operation of Secondary DNS Servers</title>
<author fullname="Robert Elz" initials="R." surname="Elz">
<organization>Computer Science</organization>

<address>
<postal>
<street>Parkville</street>
<street>Vic</street>
<street>3052</street>
<street>Australia.</street>
</postal>

<email>kre@munnari.OZ.AU</email>
<uri>e</uri>
</address>
</author>

<author fullname="Randy Bush" initials="R." surname="Bush">
<organization>RGnet, Inc.</organization>

<address>
<postal>
<street>5147 Crystal Springs Drive</street>
<street>Bainbridge Island</street>
<street>Washington</street>
<street>98110</street>
<street>United States.</street>
<country>NE</country>
</postal>

<email>randy@psg.com</email>
</address>
</author>

<author fullname="Scott Bradner" initials="S." surname="Bradner">
<organization>Harvard University</organization>

<address>
<postal>
<street>1350 Mass Ave</street>
<street>Cambridge</street>
<street>02138</street>
<street>United States.</street>
<country>MA</country>
</postal>

<email>sob@harvard.edu</email>
</address>
</author>

<author fullname="Michael A. Patton" initials="M.A." surname="Patton">
<organization />

<address>
<postal>
<street>33 Blanchard Road</street>
<street>Cambridge</street>
<street>02138</street>
<street>United States.</street>
<country>MA</country>
</postal>

<email>MAP@POBOX.COM</email>
</address>
</author>

<date year="1997" month="July" />
<area>Applications</area>
<area>Operations</area>
<keyword>secondary</keyword>
<keyword>domain name system</keyword>

<abstract>
<t>
   The Domain Name System requires that multiple servers exist for every
   delegated domain (zone).  This document discusses the selection of
   secondary servers for DNS zones.  Both the physical and topological
   location of each server are material considerations when selecting
   secondary servers.  The number of servers appropriate for a zone is
   also discussed, and some general secondary server maintenance issues
   considered.
</t>
</abstract>
</front>

<seriesInfo value="16" name="BCP" />
<seriesInfo value="2182" name="RFC" />
<format octets="40734" type="HTML" target="http://xml.resource.org/public/rfc/html/rfc2182.html" />
<format octets="28302" type="XML" target="http://xml.resource.org/public/rfc/xml/rfc2182.xml" />
</reference>


<reference target2="reference.RFC.2183.xml" anchor="RFC2183">
<front>
<title abbrev="Content-Disposition">Communicating Presentation Information in Internet Messages: The Content-Disposition Header Field</title>
<author fullname="Rens Troost" initials="R." surname="Troost">
<organization>New Century Systems</organization>

<address>
<postal>
<street>324 East 41st Street #804</street>
<street>New York</street>
<street>NY</street>
<street>10017</street>
<country>USA</country>
</postal>

<phone>+1 (212) 557-2050</phone>
<facsimile>+1 (212) 557-2049</facsimile>
<email>rens@century.com</email>
</address>
</author>

<author fullname="Steve Dorner" initials="S." surname="Dorner">
<organization>QUALCOMM Incorporated</organization>

<address>
<postal>
<street>6455 Lusk Boulevard</street>
<street>San Diego</street>
<street>CA 92121</street>
<country>USA</country>
</postal>

<email>sdorner@qualcomm.com</email>
</address>
</author>

<author fullname="Keith Moore" initials="K." surname="Moore">
<organization>Department of Computer Science</organization>

<address>
<postal>
<street>University of Tennessee</street>
<street>Knoxville</street>
<street>107 Ayres Hall</street>
<street>Knoxville TN  37996-1301</street>
<country>USA</country>
</postal>

<phone>+1 (423) 974-5067</phone>
<facsimile>+1 (423) 974-8296</facsimile>
<email>moore@cs.utk.edu</email>
</address>
</author>

<date year="1997" month="August" />
<area>Applications</area>
<keyword>MIME</keyword>
<keyword>internet message</keyword>
<keyword>multipurpose internet mail extensions</keyword>

<abstract>
<t>
   This memo provides a mechanism whereby messages conforming to the
   MIME specifications [RFC 2045, RFC 2046, RFC 2047, RFC 2048, RFC
   2049] can convey presentational information.  It specifies the
   &quot;Content-Disposition&quot; header field, which is optional and valid for
   any MIME entity (&quot;message&quot; or &quot;body part&quot;).  Two values for this
   header field are described in this memo; one for the ordinary linear
   presentation of the body part, and another to facilitate the use of
   mail to transfer files.  It is expected that more values will be
   defined in the future, and procedures are defined for extending this
    set of values.
</t>

<t>
   This document is intended as an extension to MIME.  As such, the
   reader is assumed to be familiar with the MIME specifications, and
   [RFC 822].  The information presented herein supplements but does not
   replace that found in those documents.
</t>

<t>
   This document is a revision to the Experimental protocol defined in
   RFC 1806.  As compared to RFC 1806, this document contains minor
   editorial updates, adds new parameters needed to support the File
   Transfer Body Part, and references a separate specification for the
   handling of non-ASCII and/or very long parameter values.
</t>
</abstract>
</front>

<seriesInfo value="2183" name="RFC" />
<format octets="38526" type="HTML" target="http://xml.resource.org/public/rfc/html/rfc2183.html" />
<format octets="24153" type="XML" target="http://xml.resource.org/public/rfc/xml/rfc2183.xml" />
</reference>


<reference target2="reference.RFC.2184.xml" anchor="RFC2184">
<front>
<title abbrev="MIME Parameter Value and Encoded Word Extensions">MIME Parameter Value and Encoded Word Extensions: Character Sets, Languages, and Continuations</title>
<author fullname="Ned Freed" initials="N." surname="Freed">
<organization>Innosoft International, Inc.</organization>

<address>
<postal>
<street>1050 East Garvey Avenue South</street>
<street>West Covina</street>
<street>CA 91790</street>
<country>USA</country>
</postal>

<phone>+1 818 919 3600           fax: +1 818 919 3614</phone>
<email>ned@innosoft.com</email>
</address>
</author>

<author fullname="Keith Moore" initials="K." surname="Moore">
<organization>Computer Science Dept.</organization>

<address>
<postal>
<street>University of Tennessee</street>
<street>107 Ayres Hall</street>
<street>Knoxville</street>
<street>TN 37996-1301</street>
<country>USA</country>
</postal>

<email>moore@cs.utk.edu</email>
</address>
</author>

<date year="1997" month="August" />
<area>Applications</area>
<keyword>MIME</keyword>
<keyword>character encoding</keyword>
<keyword>media type</keyword>
<keyword>multipurpose internet mail extensions</keyword>
</front>

<seriesInfo value="2184" name="RFC" />
<format octets="30080" type="HTML" target="http://xml.resource.org/public/rfc/html/rfc2184.html" />
<format octets="17240" type="XML" target="http://xml.resource.org/public/rfc/xml/rfc2184.xml" />
</reference>


<reference target2="reference.RFC.2185.xml" anchor="RFC2185">
<front>
<title abbrev="IPv6 Routing">Routing Aspects Of IPv6 Transition</title>
<author fullname="Ross Callon" initials="R." surname="Callon">
<organization>Cascade Communications Co.</organization>

<address>
<postal>
<street>5 Carlisle Road</street>
<street>Westford</street>
<street>MA 01886</street>
</postal>

<email>rcallon@casc.com</email>
</address>
</author>

<author fullname="Dimitry Haskin" initials="D." surname="Haskin">
<organization>Bay Networks, Inc.</organization>

<address>
<postal>
<street>2 Federal Street</street>
<street>Billerica</street>
<street>MA 01821</street>
</postal>

<email>dhaskin@baynetworks.com</email>
</address>
</author>

<date year="1997" month="September" />
<area>Operations</area>
<area>Routing</area>
<keyword>internet protocol version 6</keyword>
<keyword>routing</keyword>

<abstract>
<t>
   This document gives an overview of the routing aspects of the IPv6
   transition.  It is based on the protocols defined in the document
   &quot;Transition Mechanisms for IPv6 Hosts and Routers&quot; .  Readers
   should be familiar with the transition mechanisms before reading this
   document.
</t>

<t>
   The proposals contained in this document are based on the work of the
   Ngtrans working group.
</t>
</abstract>
</front>

<seriesInfo value="2185" name="RFC" />
<format octets="43379" type="HTML" target="http://xml.resource.org/public/rfc/html/rfc2185.html" />
<format octets="32252" type="XML" target="http://xml.resource.org/public/rfc/xml/rfc2185.xml" />
</reference>


<reference target2="reference.RFC.2186.xml" anchor="RFC2186">
<front>
<title abbrev="ICP">Internet Cache Protocol (ICP), version 2</title>
<author fullname="Duane Wessels" initials="D." surname="Wessels">
<organization>National Laboratory for Applied Network Research</organization>

<address>
<postal>
<street>10100 Hopkins Drive</street>
<street>La Jolla</street>
<street>CA 92093</street>
</postal>

<email>wessels@nlanr.net</email>
</address>
</author>

<author fullname="K. Claffy" initials="K." surname="Claffy">
<organization>National Laboratory for Applied Network Research</organization>

<address>
<postal>
<street>10100 Hopkins Drive</street>
<street>La Jolla</street>
<street>CA 92093</street>
</postal>

<email>kc@nlanr.net</email>
</address>
</author>

<date year="1997" month="September" />
<area>Applications</area>
<keyword>proxy</keyword>
<keyword>world wide web</keyword>

<abstract>
<t>
   This document describes version 2 of the Internet Cache Protocol
   (ICPv2) as currently implemented in two World-Wide Web proxy cache
   packages[3,5].  ICP is a lightweight message format used for
   communicating among Web caches.  ICP is used to exchange hints about
   the existence of URLs in neighbor caches.  Caches exchange ICP
   queries and replies to gather information to use in selecting the
   most appropriate location from which to retrieve an object.
</t>

<t>
   This document describes only the format and fields of ICP messages.
   A companion document (RFC2187) describes the application of ICP to
   Web caches.  Several independent caching implementations now use ICP,
   and we consider it important to codify the existing practical uses of
   ICP for those trying to implement, deploy, and extend its use for
   their own purposes.
</t>
</abstract>
</front>

<seriesInfo value="2186" name="RFC" />
<format octets="31890" type="HTML" target="http://xml.resource.org/public/rfc/html/rfc2186.html" />
<format octets="21027" type="XML" target="http://xml.resource.org/public/rfc/xml/rfc2186.xml" />
</reference>


<reference target2="reference.RFC.2187.xml" anchor="RFC2187">
<front>
<title abbrev="ICP Application">Application of Internet Cache Protocol (ICP), version 2</title>
<author fullname="Duane Wessels" initials="D." surname="Wessels">
<organization>National Laboratory for Applied Network Research</organization>

<address>
<postal>
<street>10100 Hopkins Drive</street>
<street>La Jolla</street>
<street>CA 92093</street>
</postal>

<email>wessels@nlanr.net</email>
</address>
</author>

<author fullname="K. Claffy" initials="K." surname="Claffy">
<organization>National Laboratory for Applied Network Research</organization>

<address>
<postal>
<street>10100 Hopkins Drive</street>
<street>La Jolla</street>
<street>CA 92093</street>
</postal>

<email>kc@nlanr.net</email>
</address>
</author>

<date year="1997" month="September" />
<area>Applications</area>
<keyword>cache</keyword>
<keyword>world wide web</keyword>

<abstract>
<t>
   This document describes the application of ICPv2 (Internet Cache
   Protocol version 2, RFC2186) to Web caching.  ICPv2 is a lightweight
   message format used for communication among Web caches.  Several
   independent caching implementations now use ICP[3,5], making it
   important to codify the existing practical uses of ICP for those
   trying to implement, deploy, and extend its use.
</t>

<t>
   ICP queries and replies refer to the existence of URLs (or objects)
   in neighbor caches.  Caches exchange ICP messages and use the
   gathered information to select the most appropriate location from
   which to retrieve an object.  A companion document (RFC2186)
   describes the format and syntax of the protocol itself.  In this
   document we focus on issues of ICP deployment, efficiency, security,
   and interaction with other aspects of Web traffic behavior.
</t>
</abstract>
</front>

<seriesInfo value="2187" name="RFC" />
<format octets="69171" type="HTML" target="http://xml.resource.org/public/rfc/html/rfc2187.html" />
<format octets="54271" type="XML" target="http://xml.resource.org/public/rfc/xml/rfc2187.xml" />
</reference>


<reference target2="reference.RFC.2188.xml" anchor="RFC2188">
<front>
<title abbrev="ESRO">AT&amp;T/Neda's Efficient Short Remote Operations (ESRO) Protocol Specification Version 1.2</title>
<author fullname="Mohsen Banan" initials="M." surname="Banan">
<organization>Neda Communications, Inc.</organization>

<address>
<postal>
<street>17005 SE 31st Place</street>
<city>Bellevue</city>
<region>WA</region>
<code>98008</code>
<country>US</country>
</postal>

<email>mohsen@neda.com</email>
</address>
</author>

<author fullname="Mark S. Taylor" initials="M." surname="Taylor">
<organization>AT&amp;T Wireless Services, Wireless Data Division</organization>

<address>
<postal>
<street>10230 NE Points Drive</street>
<city>Kirkland</city>
<region>WA</region>
<code>98033-7869</code>
<country>US</country>
</postal>

<email>mark.taylor@airdata.com</email>
</address>
</author>

<author fullname="Jia-bing Cheng" initials="J." surname="Cheng">
<organization>AT&amp;T Wireless Services, Wireless Data Division</organization>

<address>
<postal>
<street>10230 NE Points Drive</street>
<city>Kirkland</city>
<region>WA</region>
<code>98033-7869</code>
<country>US</country>
</postal>

<email>jcheng@airdata.com</email>
</address>
</author>

<date year="1997" month="September" />

<abstract>
<t>This document specifies the service model, the notation and protocol for Efficient Short Remote Operations (ESRO). The ESRO service is similar to and is consistent with other Remote Procedure Call services.  The emphasis of ESRO service definition and the ESRO protocol is on efficiency.  ESRO is designed specifically with wireless network (e.g., CDPD) usage in mind.</t>

<t>ESRO protocol provides reliable connectionless remote operation services on top of UDP (or any other non-reliable connectionless transport service) with minimum overhead.  ESRO protocol supports segmentation and reassembly, concatenation and separation as well as multiplexing for service users (applications).</t>

<t>ESRO allows for trade-offs between efficiency and reliability by specifying both 2-way hand-shake and 3-way hand-shake based protocols.</t>

<t>Encoding mechanisms for presentation of the parameters of remote operations are outside the scope of this document.  But, identification (tagging) of the encoding mechanism in use (e.g., XDR, BER, PER) is supported by ESRO protocol</t>

<t>A variety of applications can use the ESRO protocol.  Some early applications using ESRO include efficient short message submission and delivery, credit card authorization and white pages lookup.</t>
</abstract>
</front>

<seriesInfo value="2188" name="RFC" />
</reference>


<reference target2="reference.RFC.2189.xml" anchor="RFC2189">
<front>
<title abbrev="CBTv2 Protocl Specification">Core Based Trees (CBT version 2) Multicast Routing -- Protocol Specification --</title>
<author fullname="Tony Ballardie" initials="T." surname="Ballardie">
<organization>Research Consultant</organization>

<address>
<email>ABallardie@acm.org</email>
</address>
</author>

<date year="1997" month="September" />
<area>Routing</area>
<keyword>Core Based Tree</keyword>
<keyword>multicast</keyword>
<keyword>routing</keyword>

<abstract>
<t>
   This document describes the Core Based Tree (CBT version 2) network
   layer multicast routing protocol. CBT builds a shared multicast
   distribution tree per group, and is suited to inter- and intra-domain
   multicast routing.
</t>

<t>
   CBT may use a separate multicast routing table, or it may use that of
   underlying unicast routing, to establish paths between senders and
   receivers. The CBT architecture is described in .
</t>

<t>
   This document is progressing through the IDMR working group of the
   IETF.  CBT related documents include [1, 5, 6]. For all IDMR-related
   documents, see http://www.cs.ucl.ac.uk/ietf/idmr.
</t>

<t>
   This version of the CBT protocol specification differs significantly
   from the previous version. Consequently, this version represents
   version 2 of the CBT protocol.  CBT version 2 is not, and was not,
   intended to be backwards compatible with version 1; we do not expect
   this to cause extensive compatibility problems because we do not
   believe CBT is at all widely deployed at this stage. However, any
   future versions of CBT can be expected to be backwards compatible
   with this version.
   The most significant changes to version 2 compared to version 1
   include:

<list>
<t>
   o new LAN mechanisms, including the incorporation of an HELLO
     protocol.
</t>

<t>
   o new simplified packet formats, with the definition of a common CBT
     control packet header.
</t>

<t>
   o each group shared tree has only one active core router.
</t>
</list>
</t>

<t>
     This specification revision is a complete re-write of the previous
     revision.
</t>
</abstract>
</front>

<seriesInfo value="2189" name="RFC" />
<format octets="67613" type="HTML" target="http://xml.resource.org/public/rfc/html/rfc2189.html" />
<format octets="53294" type="XML" target="http://xml.resource.org/public/rfc/xml/rfc2189.xml" />
</reference>


<reference target2="reference.RFC.2190.xml" anchor="RFC2190">
<front>
<title abbrev="H.263 RPT Payload">RTP Payload Format for H.263 Video Streams</title>
<author fullname="C. &quot;Chad&quot; Zhu" initials="C.&quot;." surname="Zhu">
<organization>Mail Stop: JF3-202</organization>

<address>
<postal>
<street>Intel Corporation</street>
<street>2111 N.E. 25th Avenue</street>
<street>Hillsboro</street>
<street>OR 97124</street>
<country>USA</country>
</postal>

<phone>(503) 264-6008</phone>
<facsimile>(503) 264-1805</facsimile>
<email>czhu@ibeam.intel.com</email>
</address>
</author>

<date year="1997" month="September" />
<area>Transport</area>
<keyword>RTP</keyword>
<keyword>H.263</keyword>
<keyword>encapsulate</keyword>
<keyword>real-time transport protocol</keyword>
<keyword>video</keyword>

<abstract>
<t>
   This document specifies the payload format for encapsulating an H.263
   bitstream in the Real-Time Transport Protocol (RTP). Three modes are
   defined for the H.263 payload header. An RTP packet can use one of
   the three modes for H.263 video streams depending on the desired
   network packet size and H.263 encoding options employed. The shortest
   H.263 payload header (mode A) supports fragmentation at Group of
   Block (GOB) boundaries. The long H.263 payload headers (mode B and C)
   support fragmentation at Macroblock (MB) boundaries.
</t>
</abstract>
</front>

<seriesInfo value="2190" name="RFC" />
<format octets="44391" type="HTML" target="http://xml.resource.org/public/rfc/html/rfc2190.html" />
<format octets="29270" type="XML" target="http://xml.resource.org/public/rfc/xml/rfc2190.xml" />
</reference>


<reference target2="reference.RFC.2191.xml" anchor="RFC2191">
<front>
<title abbrev="VENUS">VENUS - Very Extensive Non-Unicast Service</title>
<author fullname="Grenville Armitage" initials="G." surname="Armitage">
<organization>Bell Labs, Lucent Technologies.</organization>

<address>
<postal>
<street>101 Crawfords Corner Rd</street>
<street>Holmdel</street>
<street>NJ</street>
<street>07733</street>
<country>USA</country>
</postal>

<email>gja@dnrc.bell-labs.com</email>
</address>
</author>

<date year="1997" month="September" />
<area>Internet</area>
<keyword>ATM</keyword>
<keyword>MARS</keyword>

<abstract>
<t>
   The MARS model (RFC2022) provides a solution to intra-LIS IP
   multicasting over ATM, establishing and managing the use of ATM pt-
   mpt SVCs for IP multicast packet forwarding. Inter-LIS multicast
   forwarding is achieved using Mrouters, in a similar manner to which
   the &quot;Classical IP over ATM&quot; model uses Routers to inter-connect LISes
   for unicast traffic. The development of unicast IP shortcut
   mechanisms (e.g.  NHRP) has led some people to request the
   development of a Multicast equivalent. There are a number of
   different approaches. This document focuses exclusively on the
   problems associated with extending the MARS model to cover multiple
   clusters or clusters spanning more than one subnet. It describes a
   hypothetical solution, dubbed &quot;Very Extensive NonUnicast Service&quot;
   (VENUS), and shows how complex such a service would be. It is also
   noted that VENUS ultimately has the look and feel of a single, large
   cluster using a distributed MARS.  This document is being issued to
   help focus ION efforts towards alternative solutions for establishing
   ATM level multicast connections between LISes.
</t>
</abstract>
</front>

<seriesInfo value="2191" name="RFC" />
<format octets="44610" type="HTML" target="http://xml.resource.org/public/rfc/html/rfc2191.html" />
<format octets="33722" type="XML" target="http://xml.resource.org/public/rfc/xml/rfc2191.xml" />
</reference>


<reference target2="reference.RFC.2192.xml" anchor="RFC2192">
<front>
<title>IMAP URL Scheme</title>
<author fullname="Chris Newman" initials="C." surname="Newman">
<organization>Innosoft International, Inc.</organization>

<address>
<postal>
<street>1050 Lakes Drive</street>
<street>West Covina</street>
<street>CA 91790</street>
<country>USA</country>
</postal>

<email>chris.newman@innosoft.com</email>
</address>
</author>

<date year="1997" month="September" />
<area>Applications</area>
<keyword>IMAP</keyword>
<keyword>internet message access protocol</keyword>
<keyword>uniform resource</keyword>

<abstract>
<t>
     IMAP  is a rich protocol for accessing remote message
     stores.  It provides an ideal mechanism for accessing public
     mailing list archives as well as private and shared message stores.
     This document defines a URL scheme for referencing objects on an
     IMAP server.
</t>
</abstract>
</front>

<seriesInfo value="2192" name="RFC" />
<format octets="52707" type="HTML" target="http://xml.resource.org/public/rfc/html/rfc2192.html" />
<format octets="36231" type="XML" target="http://xml.resource.org/public/rfc/xml/rfc2192.xml" />
</reference>


<reference target2="reference.RFC.2193.xml" anchor="RFC2193">
<front>
<title>IMAP4 Mailbox Referrals</title>
<author fullname="Mike Gahrns" initials="M." surname="Gahrns">
<organization>Microsoft</organization>

<address>
<postal>
<street>One Microsoft Way</street>
<street>Redmond</street>
<street>WA</street>
<street>98072</street>
</postal>

<phone>(206) 936-9833</phone>
<email>mikega@microsoft.com</email>
</address>
</author>

<date year="1997" month="September" />
<area>Applications</area>
<keyword>IMAP</keyword>
<keyword>internet message access protocol</keyword>
<keyword>mail</keyword>
</front>

<seriesInfo value="2193" name="RFC" />
<format octets="29666" type="HTML" target="http://xml.resource.org/public/rfc/html/rfc2193.html" />
<format octets="18792" type="XML" target="http://xml.resource.org/public/rfc/xml/rfc2193.xml" />
</reference>


<reference target2="reference.RFC.2194.xml" anchor="RFC2194">
<front>
<title>Review of Roaming Implementations</title>
<author fullname="Bernard Aboba" initials="B." surname="Aboba">
<organization>Microsoft Corporation</organization>

<address>
<postal>
<street>One Microsoft Way</street>
<city>Redmond</city>
<region>WA</region>
<code>98052</code>
<country>US</country>
</postal>

<phone>+1 206 936 6605</phone>
<email>bernarda@microsoft.com</email>
</address>
</author>

<author fullname="Juan Lu" initials="J." surname="Lu">
<organization>AimQuest Corporation</organization>

<address>
<postal>
<street>1381 McCarthy Boulevard</street>
<city>Milpitas</city>
<region>CA</region>
<code>95035</code>
<country>US</country>
</postal>

<phone>+1 408 273 2730 x2762</phone>
<email>juanlu@aimnet.net</email>
</address>
</author>

<author fullname="John Alsop" initials="J." surname="Alsop">
<organization>i-Pass Alliance Inc.</organization>

<address>
<postal>
<street>650 Castro Street</street>
<street>Suite 280</street>
<city>Mountain View</city>
<region>CA</region>
<code>94041</code>
<country>US</country>
</postal>

<phone>+1 415 968 2200</phone>
<facsimile>+1 415 968 2266</facsimile>
<email>jalsop@ipass.com</email>
</address>
</author>

<author fullname="James Ding" initials="J." surname="Ding">
<organization>Asiainfo</organization>

<address>
<postal>
<street>13355 Noel Road</street>
<street>#1340</street>
<city>Dallas</city>
<region>TX</region>
<code>75240</code>
<country>US</country>
</postal>

<phone>+1 214 788 4141</phone>
<facsimile>+1 214 788 0729</facsimile>
<email>ding@bjai.asiainfo.com</email>
</address>
</author>

<author fullname="Wei Wang" initials="W." surname="Wang">
<organization>Merit Network, Inc.</organization>

<address>
<postal>
<street>4251 Plymouth Road</street>
<street>Suite C</street>
<city>Ann Arbor</city>
<region>MI</region>
<code>48105-2785</code>
<country>US</country>
</postal>

<phone>+1 313 764 2874</phone>
<email>weiwang@merit.edu</email>
</address>
</author>

<date year="1997" month="September" />

<abstract>
<t>This document reviews the design and functionality of existing roaming implementations. "Roaming capability" may be loosely defined as the ability to use any one of multiple Internet service providers (ISPs), while maintaining a formal, customer-vendor relationship with only one. Examples of cases where roaming capability might be required include ISP "confederations" and ISP-provided corporate network access support.</t>
</abstract>
</front>

<seriesInfo value="2194" name="RFC" />
</reference>


<reference target2="reference.RFC.2195.xml" anchor="RFC2195">
<front>
<title abbrev="IMAP/POP AUTHorize Extension">IMAP/POP AUTHorize Extension for Simple Challenge/Response</title>
<author fullname="John C. Klensin" initials="J.C." surname="Klensin">
<organization>MCI</organization>

<address>
<postal>
<street>800 Boylston</street>
<street>7th floor</street>
<street>Boston</street>
<street>MA 02199</street>
<country>USA</country>
</postal>

<phone>+1 617 960 1011</phone>
<email>klensin@mci.net</email>
</address>
</author>

<author fullname="Randy Catoe" initials="R." surname="Catoe">
<organization>MCI</organization>

<address>
<postal>
<street>2100 Reston Parkway</street>
<street>Reston</street>
<street>VA 22091</street>
<country>USA</country>
</postal>

<phone>+1 703 715 7366</phone>
<email>randy@mci.net</email>
</address>
</author>

<author fullname="Paul Krumviede" initials="P." surname="Krumviede">
<organization>MCI</organization>

<address>
<postal>
<street>2100 Reston Parkway</street>
<street>Reston</street>
<street>VA 22091</street>
<country>USA</country>
</postal>

<phone>+1 703 715 7251</phone>
<email>paul@mci.net</email>
</address>
</author>

<date year="1997" month="September" />
<area>Applications</area>
<keyword>IMAP</keyword>
<keyword>authentication</keyword>
<keyword>internet message access protocol</keyword>
<keyword>post office protocol</keyword>
<keyword>security</keyword>

<abstract>
<t>
   While IMAP4 supports a number of strong authentication mechanisms as
   described in RFC 1731, it lacks any mechanism that neither passes
   cleartext, reusable passwords across the network nor requires either
   a significant security infrastructure or that the mail server update
   a mail-system-wide user authentication file on each mail access.
   This specification provides a simple challenge-response
   authentication protocol that is suitable for use with IMAP4.  Since
   it utilizes Keyed-MD5 digests and does not require that the secret be
   stored in the clear on the server, it may also constitute an
   improvement on APOP for POP3 use as specified in RFC 1734.
</t>
</abstract>
</front>

<seriesInfo value="2195" name="RFC" />
<format octets="28493" type="HTML" target="http://xml.resource.org/public/rfc/html/rfc2195.html" />
<format octets="15436" type="XML" target="http://xml.resource.org/public/rfc/xml/rfc2195.xml" />
</reference>


<reference target2="reference.RFC.2196.xml" anchor="RFC2196">
<front>
<title>Site Security Handbook</title>
<author fullname="Barbara Y. Fraser" initials="B.Y." surname="Fraser">
<organization>Software Engineering Institute</organization>

<address>
<postal>
<street>Carnegie Mellon University</street>
<street>5000 Forbes Avenue</street>
<city>Pittsburgh</city>
<region>PA</region>
<code>15213</code>
<country>US</country>
</postal>

<phone>+1 412 268 5010</phone>
<facsimile>+1 412 268 6989</facsimile>
<email>byf@cert.org</email>
</address>
</author>

<date year="1997" month="September" />

<abstract>
<t>This handbook is a guide to developing computer security policies and procedures for sites that have systems on the Internet.The purpose of this handbook is to provide practical guidance to administrators trying to secure their information and services.The subjects covered include policy content and formation, a broad range of technical system and network security topics, and security incident response.</t>
</abstract>
</front>

<seriesInfo value="2196" name="RFC" />
</reference>


<reference target2="reference.RFC.2197.xml" anchor="RFC2197">
<front>
<title abbrev="SMTP Service Extension">SMTP Service Extension for Command Pipelining</title>
<author fullname="Ned Freed" initials="N." surname="Freed">
<organization>Innosoft International, Inc.</organization>

<address>
<postal>
<street>1050 Lakes Drive</street>
<street>West Covina</street>
<street>CA 91790</street>
<country>USA</country>
</postal>

<phone>+1 626 919 3600</phone>
<facsimile>+1 626 919 3614</facsimile>
<email>ned.freed@innosoft.com</email>
</address>
</author>

<date year="1997" month="September" />
<area>Applications</area>
<keyword>SMTP</keyword>
<keyword>simple mail transfer protocol</keyword>
</front>

<seriesInfo value="2197" name="RFC" />
<format octets="29012" type="HTML" target="http://xml.resource.org/public/rfc/html/rfc2197.html" />
<format octets="17167" type="XML" target="http://xml.resource.org/public/rfc/xml/rfc2197.xml" />
</reference>


<reference target2="reference.RFC.2198.xml" anchor="RFC2198">
<front>
<title abbrev="RTP Audio Payload">RTP Payload for Redundant Audio Data</title>
<author fullname="Colin Perkins" initials="C." surname="Perkins">
<organization>Department of Computer Science</organization>

<address>
<postal>
<street>Department of Computer Science</street>
<city>London</city>
<code>WC1E 6BT</code>
<country>UK</country>
</postal>

<email>c.perkins@cs.ucl.ac.uk</email>
</address>
</author>

<author fullname="Isidor Kouvelas" initials="I." surname="Kouvelas">
<organization>Department of Computer Science</organization>

<address>
<postal>
<street>Department of Computer Science</street>
<city>London</city>
<code>WC1E 6BT</code>
<country>UK</country>
</postal>

<email>i.kouvelas@cs.ucl.ac.uk</email>
</address>
</author>

<author fullname="Orion Hodson" initials="O." surname="Hodson">
<organization>Department of Computer Science</organization>

<address>
<postal>
<street>Department of Computer Science</street>
<city>London</city>
<code>WC1E 6BT</code>
<country>UK</country>
</postal>

<email>o.hodson@cs.ucl.ac.uk</email>
</address>
</author>

<author fullname="Vicky Hardman" initials="V." surname="Hardman">
<organization>Department of Computer Science</organization>

<address>
<postal>
<street>Department of Computer Science</street>
<city>London</city>
<code>WC1E 6BT</code>
<country>UK</country>
</postal>

<email>v.hardman@cs.ucl.ac.uk</email>
</address>
</author>

<author fullname="Mark Handley" initials="M." surname="Handley">
<organization>USC Information Sciences Institute</organization>

<address>
<postal>
<street>c/o MIT Laboratory for Computer Science</street>
<street>545 Technology Square</street>
<city>Cambridge</city>
<region>MA</region>
<code>02139</code>
<country>US</country>
</postal>

<email>mjh@isi.edu</email>
</address>
</author>

<author fullname="Jean-Chrysostome Bolot" initials="J." surname="Bolot">
<organization>INRIA Sophia Antipolis</organization>

<address>
<postal>
<street>2004 Route des Lucioles</street>
<street>BP 93</street>
<city>Sophia Antipolis</city>
<code>06902</code>
<country>FR</country>
</postal>

<email>bolot@sophia.inria.fr</email>
</address>
</author>

<author fullname="Andres Vega-Garcia" initials="A." surname="Vega-Garcia">
<organization>INRIA Sophia Antipolis</organization>

<address>
<postal>
<street>2004 Route des Lucioles</street>
<street>BP 93</street>
<city>Sophia Antipolis</city>
<code>06902</code>
<country>FR</country>
</postal>

<email>avega@sophia.inria.fr</email>
</address>
</author>

<author fullname="Sacha Fosse-Parisis" initials="S." surname="Fosse-Parisis">
<organization>INRIA Sophia Antipolis</organization>

<address>
<postal>
<street>2004 Route des Lucioles</street>
<street>BP 93</street>
<city>Sophia Antipolis</city>
<code>06902</code>
<country>FR</country>
</postal>

<email>sfosse@sophia.inria.fr</email>
</address>
</author>

<date year="1997" month="September" />
<area>Transport</area>
<keyword>RTP</keyword>
<keyword>audio</keyword>
<keyword>real-time transport protocol</keyword>

<abstract>
<t>
   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.
</t>
</abstract>
</front>

<seriesInfo value="2198" name="RFC" />
<format octets="43782" type="HTML" target="http://xml.resource.org/public/rfc/html/rfc2198.html" />
<format octets="28753" type="XML" target="http://xml.resource.org/public/rfc/xml/rfc2198.xml" />
</reference>


<reference target2="reference.RFC.2199.xml" anchor="RFC2199">
<front>
<title abbrev="Summary of 2100-2199">Request for Comments Summary RFC Numbers 2100-2199</title>
<author fullname="Alegre Ramos" initials="A." surname="Ramos">
<organization>University of Southern California,  Information Sciences Institute</organization>

<address>
<postal>
<street>4676 Admiralty Way</street>
<city>Marina del Rey</city>
<region>CA</region>
<code>90292</code>
<country>US</country>
</postal>

<phone>+1 310 822 1511</phone>
<email>ramos@isi.edu</email>
</address>
</author>

<date year="1998" month="January" />
</front>

<seriesInfo value="2199" name="RFC" />
</reference>


<reference target2="reference.RFC.2200.xml" anchor="RFC2200">
<front>
<title>INTERNET OFFICIAL PROTOCOL STANDARDS</title>
<author fullname="Jon Postel" initials="J." surname="Postel">
<organization>USC/Information Sciences Institute</organization>

<address>
<postal>
<street>4676 Admiralty Way</street>
<street>Marina del Rey</street>
<street>CA 90292</street>
</postal>

<phone>310-822-1511</phone>
<facsimile>310-823-6714</facsimile>
<email>Postel@ISI.EDU</email>
</address>
</author>

<date year="1997" month="June" />
<keyword>Internet Architecture Board</keyword>
<keyword>official internet protocol</keyword>
</front>

<seriesInfo value="1" name="STD" />
<seriesInfo value="2200" name="RFC" />
<format octets="105320" type="HTML" target="http://xml.resource.org/public/rfc/html/rfc2200.html" />
<format octets="91001" type="XML" target="http://xml.resource.org/public/rfc/xml/rfc2200.xml" />
</reference>


<reference target2="reference.RFC.2201.xml" anchor="RFC2201">
<front>
<title abbrev="Core Based Trees">Core Based Trees (CBT) Multicast Routing Architecture</title>
<author fullname="Tony Ballardie" initials="T." surname="Ballardie">
<organization>Research Consultant</organization>

<address>
<email>ABallardie@acm.org</email>
</address>
</author>

<date year="1997" month="September" />
<area>Routing</area>
<keyword>multicast</keyword>
<keyword>routing</keyword>

<abstract>
<t>
   CBT is a multicast routing architecture that builds a single delivery
   tree per group which is shared by all of the group&apos;s senders and
   receivers.  Most multicast algorithms build one multicast tree per
   sender (subnetwork), the tree being rooted at the sender&apos;s
   subnetwork.  The primary advantage of the shared tree approach is
   that it typically offers more favourable scaling characteristics than
   all other multicast algorithms.
</t>

<t>
   The CBT protocol  is a network layer multicast routing protocol
   that builds and maintains a shared delivery tree for a multicast
   group.  The sending and receiving of multicast data by hosts on a
   subnetwork conforms to the traditional IP multicast service model
   .
</t>

<t>
   CBT is progressing through the IDMR working group of the IETF.  The
   CBT protocol is described in an accompanying document . For this,
   and all IDMR-related documents, see http://www.cs.ucl.ac.uk/ietf/idmr
</t>
</abstract>
</front>

<seriesInfo value="2201" name="RFC" />
<format octets="52096" type="HTML" target="http://xml.resource.org/public/rfc/html/rfc2201.html" />
<format octets="41299" type="XML" target="http://xml.resource.org/public/rfc/xml/rfc2201.xml" />
</reference>


<reference target2="reference.RFC.2202.xml" anchor="RFC2202">
<front>
<title>Test Cases for HMAC-MD5 and HMAC-SHA-1</title>
<author fullname="Pau-Chen Cheng" initials="P." surname="Cheng">
<organization>IBM T.J. Watson Research Center</organization>

<address>
<postal>
<street>P.O.Box 704</street>
<street>Yorktown Heights</street>
<street>NY 10598</street>
</postal>

<email>pau@watson.ibm.com</email>
</address>
</author>

<author fullname="Robert Glenn" initials="R." surname="Glenn">
<organization>NIST</organization>

<address>
<postal>
<street>Building 820</street>
<street>Room 455</street>
<street>Gaithersburg</street>
<street>MD 20899</street>
</postal>

<email>rob.glenn@nist.gov</email>
</address>
</author>

<date year="1997" month="September" />
<area>Security</area>
<keyword>MD5</keyword>
<keyword>IP security protocol</keyword>
<keyword>authentication</keyword>
<keyword>cryptographic hash message authentication codes</keyword>
<keyword>message digest</keyword>
<keyword>secure hash algorithm</keyword>

<abstract>
<t>
   This document provides two sets of test cases for HMAC-MD5 and HMAC-
   SHA-1, respectively. HMAC-MD5 and HMAC-SHA-1 are two constructs of
   the HMAC  message authentication function using the MD5 
   hash function and the SHA-1  hash function. Both constructs are
   used by IPSEC [OG,CG] and other protocols to authenticate messages.
   The test cases and results provided in this document are meant to be
   used as a conformance test for HMAC-MD5 and HMAC-SHA-1
   implementations.
</t>
</abstract>
</front>

<seriesInfo value="2202" name="RFC" />
<format octets="22696" type="HTML" target="http://xml.resource.org/public/rfc/html/rfc2202.html" />
<format octets="13057" type="XML" target="http://xml.resource.org/public/rfc/xml/rfc2202.xml" />
</reference>


<reference target2="reference.RFC.2203.xml" anchor="RFC2203">
<front>
<title>RPCSEC_GSS Protocol Specification</title>
<author fullname="Michael Eisler" initials="M." surname="Eisler">
<organization>Sun Microsystems, Inc.</organization>

<address>
<postal>
<street>M/S UCOS03</street>
<street>2550 Garcia Avenue</street>
<street>Mountain View</street>
<street>CA 94043</street>
</postal>

<phone>+1 (719) 599-9026</phone>
<email>mre@eng.sun.com</email>
</address>
</author>

<author fullname="Alex Chiu" initials="A." surname="Chiu">
<organization>Sun Microsystems, Inc.</organization>

<address>
<postal>
<street>M/S UMPK17-203</street>
<street>2550 Garcia Avenue</street>
<street>Mountain View</street>
<street>CA 94043</street>
</postal>

<phone>+1 (415) 786-6465</phone>
<email>hacker@eng.sun.com</email>
</address>
</author>

<author fullname="Lin Ling" initials="L." surname="Ling">
<organization>Sun Microsystems, Inc.</organization>

<address>
<postal>
<street>M/S UMPK17-201</street>
<street>2550 Garcia Avenue</street>
<street>Mountain View</street>
<street>CA 94043</street>
</postal>

<phone>+1 (415) 786-5084</phone>
<email>lling@eng.sun.com</email>
</address>
</author>

<date year="1997" month="September" />
<area>Security</area>
<keyword>generic security service</keyword>
<keyword>remote procedure call</keyword>
<keyword>security</keyword>

<abstract>
<t>
   This memo describes an ONC/RPC security flavor that allows RPC
   protocols to access the Generic Security Services Application
   Programming Interface (referred to henceforth as GSS-API).
</t>
</abstract>
</front>

<seriesInfo value="2203" name="RFC" />
<format octets="64234" type="HTML" target="http://xml.resource.org/public/rfc/html/rfc2203.html" />
<format octets="50069" type="XML" target="http://xml.resource.org/public/rfc/xml/rfc2203.xml" />
</reference>


<reference target2="reference.RFC.2204.xml" anchor="RFC2204">
<front>
<title>ODETTE File Transfer Protocol</title>
<author fullname="David Nash" initials="D." surname="Nash">
<organization>Ford Motor Company Limited</organization>

<address>
<postal>
<street>Room 1/148</street>
<street>Central Office</street>
<street>Eagle Way</street>
<street>Warley</street>
<street>Brentwood</street>
<street>Essex</street>
<street>CM13 3BW</street>
<country>United Kingdom</country>
</postal>

<phone>+44 (0)1277 253043</phone>
<email>dnash@ford.com</email>
</address>
</author>

<date year="1997" month="September" />
<area>Applications</area>
<keyword>electronic data interchange</keyword>
<keyword>file transfer</keyword>
<keyword>file transfer protocol</keyword>

<abstract>
<t>
   This memo describes a file transfer protocol to facilitate electronic
   data interchange between trading partners.
</t>

<t>
   The protocol, denoted the ODETTE File Transfer Protocol, supports
   both direct communication between installations and indirect
   communication via a third party clearing centre.  It was developed by
   the Organisation for Data Exchange by Tele Transmission in Europe to
   facilitate communication within the European motor industry and is
   presented here to allow for wider use within the Internet community.
</t>
</abstract>
</front>

<seriesInfo value="2204" name="RFC" />
<format octets="171700" type="HTML" target="http://xml.resource.org/public/rfc/html/rfc2204.html" />
<format octets="153710" type="XML" target="http://xml.resource.org/public/rfc/xml/rfc2204.xml" />
</reference>


<reference target2="reference.RFC.2205.xml" anchor="RFC2205">
<front>
<title abbrev="RSVP">Resource ReSerVation Protocol (RSVP) -- Version 1 Functional Specification</title>
<author fullname="Bob Braden" initials="B." surname="Braden">
<organization>USC Information Sciences Institute</organization>

<address>
<postal>
<street>4676 Admiralty Way</street>
<street>Marina del Rey</street>
<street>CA 90292</street>
</postal>

<phone>(310) 822-1511</phone>
<email>Braden@ISI.EDU</email>
</address>
</author>

<author fullname="Lixia Zhang" initials="L." surname="Zhang">
<organization>UCLA Computer Science Department</organization>

<address>
<postal>
<street>4531G Boelter Hall</street>
<street>Los Angeles</street>
<street>CA 90095-1596</street>
<country>USA</country>
</postal>

<phone>310-825-2695</phone>
<email>lixia@cs.ucla.edu</email>
</address>
</author>

<author fullname="Steve Berson" initials="S." surname="Berson">
<organization>USC Information Sciences Institute</organization>

<address>
<postal>
<street>4676 Admiralty Way</street>
<street>Marina del Rey</street>
<street>CA 90292</street>
</postal>

<phone>(310) 822-1511</phone>
<email>Berson@ISI.EDU</email>
</address>
</author>

<author fullname="Shai Herzog" initials="S." surname="Herzog">
<organization>IBM T. J. Watson Research Center</organization>

<address>
<postal>
<street>P.O Box 704</street>
<street>Yorktown Heights</street>
<street>NY 10598</street>
</postal>

<phone>(914) 784-6059</phone>
<email>Herzog@WATSON.IBM.COM</email>
</address>
</author>

<author fullname="Sugih Jamin" initials="S." surname="Jamin">
<organization>University of Michigan</organization>

<address>
<postal>
<street>CSE/EECS</street>
<street>1301 Beal Ave.</street>
<street>Ann Arbor</street>
<street>MI 48109-2122</street>
</postal>

<phone>(313) 763-1583</phone>
<email>jamin@EECS.UMICH.EDU</email>
</address>
</author>

<date year="1997" month="September" />
<area>Transport</area>
<keyword>multicast</keyword>
<keyword>resource reservation protocol</keyword>
<keyword>RSVP</keyword>

<abstract>
<t>
   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.
   What&apos;s Changed
</t>

<t>
   This revision contains the following very minor changes from the ID14
   version.

<list>
<t>
      o    For clarity, each message type is now defined separately in
           Section 3.1.
</t>

<t>
      o    We added more precise and complete rules for accepting Path
           messages for unicast and multicast destinations (Section
           3.1.3).
</t>

<t>
      o    We added more precise and complete rules for processing and
           forwarding PathTear messages (Section 3.1.5).
</t>

<t>
      o    A note was added that a SCOPE object will be ignored if it
           appears in a ResvTear message (Section 3.1.6).
</t>

<t>
      o    A note was added that a SENDER_TSPEC or ADSPEC object will be
           ignored if it appears in a PathTear message (Section 3.1.5).
</t>

<t>
      o    The obsolete error code Ambiguous Filter Spec (09) was
           removed, and a new (and more consistent) name was given to
           error code 08 (Appendix B).
</t>

<t>
      o    In the generic interface to traffic control, the Adspec was
           added as a parameter to the AddFlow and ModFlow calls
           (3.11.2).  This is needed to accommodate a node that updates
           the slack term (S) of Guaranteed service.
</t>

<t>
      o    An error subtype was added for an Adspec error (Appendix B).
</t>

<t>
      o    Additional explanation was added for handling a CONFIRM
           object (Section 3.1.4).
</t>

<t>
      o    The rules for forwarding objects with unknown class type were
           clarified.
</t>

<t>
      o    Additional discussion was added to the Introduction and to
           Section 3.11.2 about the relationship of RSVP to the link
           layer.  (Section 3.10).
</t>

<t>
      o    Section 2.7 on Policy and Security was split into two
           sections, and some additional discussion of security was
           included.
</t>

<t>
      o    There were some minor editorial improvements.
</t>
</list>
</t>
</abstract>
</front>

<seriesInfo value="2205" name="RFC" />
<format octets="254360" type="HTML" target="http://xml.resource.org/public/rfc/html/rfc2205.html" />
<format octets="225819" type="XML" target="http://xml.resource.org/public/rfc/xml/rfc2205.xml" />
</reference>


<reference target2="reference.RFC.2206.xml" anchor="RFC2206">
<front>
<title abbrev="RSVP MIB">RSVP Management Information Base using SMIv2</title>
<author fullname="Fred Baker" initials="F." surname="Baker">
<organization>Postal: Cisco Systems</organization>

<address>
<postal>
<street>519 Lado Drive</street>
<street>Santa Barbara</street>
<street>California 93111</street>
</postal>

<phone>+1 805 681 0115</phone>
<email>fred@cisco.com</email>
</address>
</author>

<author fullname="John Krawczyk" initials="J." surname="Krawczyk">
<organization>Postal: ArrowPoint Communications</organization>

<address>
<postal>
<street>235 Littleton Road</street>
<street>Westford</street>
<street>Massachusetts 01886</street>
</postal>

<phone>+1 508 692 5875</phone>
<email>jjk@tiac.net</email>
</address>
</author>

<author fullname="Arun Sastry" initials="A." surname="Sastry">
<organization>Postal: Cisco Systems</organization>

<address>
<postal>
<street>210 W. Tasman Drive</street>
<street>San Jose</street>
<street>California 95134</street>
</postal>

<phone>+1 408 526 7685</phone>
<email>arun@cisco.com</email>
</address>
</author>

<date year="1997" month="September" />
<area>Management</area>
<area>Transport</area>
<keyword>Management Information Base</keyword>
<keyword>resource reservation protocol</keyword>
<keyword>structure of management information version 2</keyword>

<abstract>
<t>
   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@isi.edu.
</t>
</abstract>
</front>

<seriesInfo value="2206" name="RFC" />
<format octets="120162" type="HTML" target="http://xml.resource.org/public/rfc/html/rfc2206.html" />
<format octets="107772" type="XML" target="http://xml.resource.org/public/rfc/xml/rfc2206.xml" />
</reference>


<reference target2="reference.RFC.2207.xml" anchor="RFC2207">
<front>
<title abbrev="RSVP Extensions for IPSEC">RSVP Extensions for IPSEC Data Flows</title>
<author fullname="Lou Berger" initials="L." surname="Berger">
<organization>FORE Systems</organization>

<address>
<postal>
<street>6905 Rockledge Drive</street>
<street>Suite 800</street>
<city>Bethesda</city>
<region>MD</region>
<code>20817</code>
</postal>

<phone>+1 301 571 2534</phone>
<email>lberger@fore.com</email>
</address>
</author>

<author fullname="Tim O&apos;Malley" initials="T." surname="O&apos;Malley">
<organization>BBN Corporation</organization>

<address>
<postal>
<street>10 Moulton Street</street>
<city>Cambridge</city>
<region>MA</region>
<code>02138</code>
</postal>

<phone>+1 617 873 3076</phone>
<email>timo@bbn.com</email>
</address>
</author>

<date year="1997" month="September" />
<area>Security</area>
<area>Internet</area>
<keyword>IPSEC</keyword>
<keyword>IP security protocol</keyword>
<keyword>authentication</keyword>
<keyword>encapsulate</keyword>
<keyword>resource reservation protocol</keyword>
<keyword>security</keyword>

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

<seriesInfo value="2207" name="RFC" />
<format octets="44423" type="HTML" target="http://xml.resource.org/public/rfc/html/rfc2207.html" />
<format octets="30967" type="XML" target="http://xml.resource.org/public/rfc/xml/rfc2207.xml" />
</reference>


<reference target2="reference.RFC.2208.xml" anchor="RFC2208">
<front>
<title abbrev="RSVP Applicability and Deployment">Resource ReSerVation Protocol (RSVP) Version 1 Applicability Statement Some Guidelines on Deployment</title>
<author fullname="Allison Mankin" initials="A." surname="Mankin">
<organization>USC/Information Sciences Institute</organization>

<address>
<email>mankin@isi.edu</email>
</address>
</author>

<author fullname="Fred Baker" initials="F." surname="Baker">
<organization>Cisco Systems</organization>

<address>
<phone>+1 408 526 4257</phone>
<email>fred@cisco.com</email>
</address>
</author>

<author fullname="Bob Braden" initials="B." surname="Braden">
<organization>USC/ISI</organization>

<address>
<postal>
<street>4676 Admiralty Way</street>
<street>Marina del Rey</street>
<street>CA 90292</street>
</postal>

<phone>+1 310 822 1511</phone>
<email>braden@isi.edu</email>
</address>
</author>

<author fullname="Scott Bradner" initials="S." surname="Bradner">
<organization>Harvard University</organization>

<address>
<phone>+1 617 495 3864</phone>
<email>sob@harvard.edu</email>
</address>
</author>

<author fullname="Michael D. O&apos;Dell" initials="M.D." surname="O&apos;Dell">
<organization>UUNET Technologies</organization>

<address>
<phone>+1 703 206 5890</phone>
<email>mo@uu.net</email>
</address>
</author>

<author fullname="Allyn Romanow" initials="A." surname="Romanow">
<organization>Sun Microsystems</organization>

<address>
<phone>+1 415 786 5179</phone>
<email>allyn@eng.sun.com</email>
</address>
</author>

<author fullname="Abel Weinrib" initials="A." surname="Weinrib">
<organization>Intel Corporation</organization>

<address>
<phone>+1 503 264 8972</phone>
<email>weinrib@ibeam.intel.com</email>
</address>
</author>

<author fullname="Lixia Zhang" initials="L." surname="Zhang">
<organization>UCLA Computer Science Department</organization>

<address>
<postal>
<street>4531G Boelter Hall</street>
<street>Los Angeles</street>
<street>CA 90095-1596</street>
<country>US</country>
</postal>

<phone>+1 310 825 2695</phone>
<email>lixia@cs.ucla.edu</email>
</address>
</author>

<date year="1997" month="September" />
<area>Transport</area>
<keyword>resource reservation protocol</keyword>
<keyword>RSVP</keyword>

<abstract>
<t>
   This document describes the applicability of RSVP along with the
   Integrated Services protocols and other components of resource
   reservation and offers guidelines for deployment of resource
   reservation at this time.  This document accompanies the first
   submission of RSVP and integrated services specifications onto the
   Internet standards track.
</t>
</abstract>
</front>

<seriesInfo value="2208" name="RFC" />
<format octets="29110" type="HTML" target="http://xml.resource.org/public/rfc/html/rfc2208.html" />
<format octets="16068" type="XML" target="http://xml.resource.org/public/rfc/xml/rfc2208.xml" />
</reference>


<reference target2="reference.RFC.2209.xml" anchor="RFC2209">
<front>
<title abbrev="RSVP-Message Processing">Resource ReSerVation Protocol (RSVP) -- Version 1 Message Processing Rules</title>
<author fullname="Bob Braden" initials="B." surname="Braden">
<organization>USC Information Sciences Institute</organization>

<address>
<postal>
<street>4676 Admiralty Way</street>
<street>Marina del Rey</street>
<street>CA 90292</street>
</postal>

<phone>(310) 822-1511</phone>
<email>Braden@ISI.EDU</email>
</address>
</author>

<author fullname="Lixia Zhang" initials="L." surname="Zhang">
<organization>UCLA Computer Science Department</organization>

<address>
<postal>
<street>4531G Boelter Hall</street>
<street>Los Angeles</street>
<street>CA 90095-1596</street>
<country>USA</country>
</postal>

<phone>310-825-2695</phone>
<email>lixia@cs.ucla.edu</email>
</address>
</author>

<date year="1997" month="September" />
<area>Transport</area>
<keyword>RSVP</keyword>
<keyword>resource reservation protocol</keyword>

<abstract>
<t>
   This memo contains an algorithmic description of the rules used by an
   RSVP implementation for processing messages.  It is intended to
   clarify the version 1 RSVP protocol specification.
</t>

<t>
   This memo provides a generic description of the rules for the
   operation of Version 1 of RSVP .  It is intended to outline
   a set of algorithms that will accomplish the needed function,
   omitting many details.
</t>
</abstract>
</front>

<seriesInfo value="2209" name="RFC" />
<format octets="65293" type="HTML" target="http://xml.resource.org/public/rfc/html/rfc2209.html" />
<format octets="53266" type="XML" target="http://xml.resource.org/public/rfc/xml/rfc2209.xml" />
</reference>


<reference target2="reference.RFC.2210.xml" anchor="RFC2210">
<front>
<title abbrev="RSVP with INTSERV">The Use of RSVP with IETF Integrated Services</title>
<author fullname="John Wroclawski" initials="J." surname="Wroclawski">
<organization>MIT Laboratory for Computer Science</organization>

<address>
<postal>
<street>545 Technology Sq.</street>
<street>Cambridge</street>
<street>MA  02139</street>
</postal>

<phone>617-253-7885</phone>
<facsimile>617-253-2673 (FAX)</facsimile>
<email>jtw@lcs.mit.edu</email>
</address>
</author>

<date year="1997" month="September" />
<area>Transport</area>
<keyword>Internet Engineering Task Force</keyword>
<keyword>integrated services</keyword>
<keyword>resource reservation protocol</keyword>

<abstract>
<t>
   This note describes the use of the RSVP resource reservation protocol
   with the Controlled-Load and Guaranteed QoS control services.  The
   RSVP protocol defines several data objects which carry resource
   reservation information but are opaque to RSVP itself.  The usage and
   data format of those objects is given here.
</t>
</abstract>
</front>

<seriesInfo value="2210" name="RFC" />
<format octets="92807" type="HTML" target="http://xml.resource.org/public/rfc/html/rfc2210.html" />
<format octets="78400" type="XML" target="http://xml.resource.org/public/rfc/xml/rfc2210.xml" />
</reference>


<reference target2="reference.RFC.2211.xml" anchor="RFC2211">
<front>
<title abbrev="Controlled-Load Network">Specification of the Controlled-Load Network Element Service</title>
<author fullname="John Wroclawski" initials="J." surname="Wroclawski">
<organization>MIT Laboratory for Computer Science</organization>

<address>
<postal>
<street>545 Technology Sq.</street>
<street>Cambridge</street>
<street>MA  02139</street>
</postal>

<phone>617-253-7885</phone>
<facsimile>617-253-2673 (FAX)</facsimile>
<email>jtw@lcs.mit.edu</email>
</address>
</author>

<date year="1997" month="September" />
<area>Internet</area>
<keyword>quality of service</keyword>

<abstract>
<t>
   This memo specifies the network element behavior required to deliver
   Controlled-Load service in the Internet.  Controlled-load service
   provides the client data flow with a quality of service closely
   approximating the QoS that same flow would receive from an unloaded
   network element, but uses capacity (admission) control to assure that
   this service is received even when the network element is overloaded.
</t>
</abstract>
</front>

<seriesInfo value="2211" name="RFC" />
<format octets="61805" type="HTML" target="http://xml.resource.org/public/rfc/html/rfc2211.html" />
<format octets="48062" type="XML" target="http://xml.resource.org/public/rfc/xml/rfc2211.xml" />
</reference>


<reference target2="reference.RFC.2212.xml" anchor="RFC2212">
<front>
<title abbrev="Guaranteed Quality of Service">Specification of Guaranteed Quality of Service</title>
<author fullname="Scott Shenker" initials="S." surname="Shenker">
<organization>Xerox PARC</organization>

<address>
<postal>
<street>3333 Coyote Hill Road</street>
<street>Palo Alto</street>
<street>CA  94304-1314</street>
</postal>

<phone>415-812-4840</phone>
<facsimile>415-812-4471</facsimile>
<email>shenker@parc.xerox.com</email>
</address>
</author>

<author fullname="Craig Partridge" initials="C." surname="Partridge">
<organization>BBN</organization>

<address>
<postal>
<street>2370 Amherst</street>
<street>Palo Alto CA 94306</street>
<country>St</country>
</postal>

<email>craig@bbn.com</email>
</address>
</author>

<author fullname="Roch Guerin" initials="R." surname="Guerin">
<organization>IBM T.J. Watson Research Center</organization>

<address>
<postal>
<street>Yorktown Heights</street>
<street>NY 10598</street>
</postal>

<phone>914-784-7038</phone>
<facsimile>914-784-6318</facsimile>
<email>guerin@watson.ibm.com</email>
</address>
</author>

<date year="1997" month="September" />
<area>Transport</area>
<keyword>quality of service</keyword>

<abstract>
<t>
   This memo describes the network element behavior required to deliver
   a guaranteed service (guaranteed delay and bandwidth) in the
   Internet.  Guaranteed service provides firm (mathematically provable)
   bounds on end-to-end datagram queueing delays.  This service makes it
   possible to provide a service that guarantees both delay and
   bandwidth.  This specification follows the service specification
   template described in .
</t>
</abstract>
</front>

<seriesInfo value="2212" name="RFC" />
<format octets="64740" type="HTML" target="http://xml.resource.org/public/rfc/html/rfc2212.html" />
<format octets="50157" type="XML" target="http://xml.resource.org/public/rfc/xml/rfc2212.xml" />
</reference>


<reference target2="reference.RFC.2213.xml" anchor="RFC2213">
<front>
<title abbrev="Integrated Services MIB">Integrated Services Management Information Base using SMIv2</title>
<author fullname="Fred Baker" initials="F." surname="Baker">
<organization>Postal: Cisco Systems</organization>

<address>
<postal>
<street>519 Lado Drive</street>
<street>Santa Barbara</street>
<street>California 93111</street>
</postal>

<phone>+1 805 681 0115</phone>
<email>fred@cisco.com</email>
</address>
</author>

<author fullname="John Krawczyk" initials="J." surname="Krawczyk">
<organization>Postal: ArrowPoint Communications</organization>

<address>
<postal>
<street>235 Littleton Road</street>
<street>Westford</street>
<street>Massachusetts 01886</street>
</postal>

<phone>+1 508 692 5875</phone>
<email>jjk@tiac.net</email>
</address>
</author>

<author fullname="Arun Sastry" initials="A." surname="Sastry">
<organization>Postal: Cisco Systems</organization>

<address>
<postal>
<street>210 W. Tasman Drive</street>
<street>San Jose</street>
<street>California 95314</street>
</postal>

<phone>+1 408 526 7685</phone>
<email>arun@cisco.com</email>
</address>
</author>

<date year="1997" month="September" />
<area>Management</area>
<keyword>Management Information Base</keyword>
<keyword>integrated services</keyword>
<keyword>structure of management information version 2</keyword>

<abstract>
<t>
   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@isi.edu.
</t>
</abstract>
</front>

<seriesInfo value="2213" name="RFC" />
<format octets="47597" type="HTML" target="http://xml.resource.org/public/rfc/html/rfc2213.html" />
<format octets="35463" type="XML" target="http://xml.resource.org/public/rfc/xml/rfc2213.xml" />
</reference>


<reference target2="reference.RFC.2214.xml" anchor="RFC2214">
<front>
<title abbrev="Integrated Services MIB">Integrated Services Management Information Base Guaranteed Service Extensions using SMIv2</title>
<author fullname="Fred Baker" initials="F." surname="Baker">
<organization>Postal: Cisco Systems</organization>

<address>
<postal>
<street>519 Lado Drive</street>
<street>Santa Barbara</street>
<street>California 93111</street>
</postal>

<phone>+1 805 681 0115</phone>
<email>fred@cisco.com</email>
</address>
</author>

<author fullname="John Krawczyk" initials="J." surname="Krawczyk">
<organization>Postal: ArrowPoint Communications</organization>

<address>
<postal>
<street>235 Littleton Road</street>
<street>Westford</street>
<street>Massachusetts 01886</street>
</postal>

<phone>+1 508 692 5875</phone>
<email>jjk@tiac.net</email>
</address>
</author>

<author fullname="Arun Sastry" initials="A." surname="Sastry">
<organization>Postal: Cisco Systems</organization>

<address>
<postal>
<street>210 W. Tasman Drive</street>
<street>San Jose</street>
<street>California 95314</street>
</postal>

<phone>+1 408 526 7685</phone>
<email>arun@cisco.com</email>
</address>
</author>

<date year="1997" month="September" />
<area>Management</area>
<keyword>Management Information Base</keyword>
<keyword>integrated services</keyword>
<keyword>structure of management information version 2</keyword>

<abstract>
<t>
   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, intserv@isi.edu.
</t>
</abstract>
</front>

<seriesInfo value="2214" name="RFC" />
<format octets="28271" type="HTML" target="http://xml.resource.org/public/rfc/html/rfc2214.html" />
<format octets="16221" type="XML" target="http://xml.resource.org/public/rfc/xml/rfc2214.xml" />
</reference>


<reference target2="reference.RFC.2215.xml" anchor="RFC2215">
<front>
<title abbrev="General Characterization Parameters">General Characterization Parameters for Integrated Service Network Elements</title>
<author fullname="Scott Shenker" initials="S." surname="Shenker">
<organization>Xerox PARC</organization>

<address>
<postal>
<street>3333 Coyote Hill Road</street>
<street>Palo Alto</street>
<street>CA 94304-1314</street>
</postal>

<phone>415-812-4840</phone>
<facsimile>415-812-4471</facsimile>
<email>shenker@parc.xerox.com</email>
</address>
</author>

<author fullname="John Wroclawski" initials="J." surname="Wroclawski">
<organization>MIT Laboratory for Computer Science</organization>

<address>
<postal>
<street>545 Technology Sq.</street>
<street>Cambridge</street>
<street>MA  02139</street>
</postal>

<phone>617-253-7885</phone>
<email>jtw@lcs.mit.edu</email>
</address>
</author>

<date year="1997" month="September" />
<area>Internet</area>
<keyword>quality of service</keyword>
<keyword>QoS</keyword>

<abstract>
<t>
   This memo defines a set of general control and characterization
   parameters for network elements supporting the IETF integrated
   services QoS control framework. General parameters are those with
   common, shared definitions across all QoS control services.
</t>
</abstract>
</front>

<seriesInfo value="2215" name="RFC" />
<format octets="53594" type="HTML" target="http://xml.resource.org/public/rfc/html/rfc2215.html" />
<format octets="41100" type="XML" target="http://xml.resource.org/public/rfc/xml/rfc2215.xml" />
</reference>


<reference target2="reference.RFC.2216.xml" anchor="RFC2216">
<front>
<title abbrev="Network Element Service Template">Network Element Service Specification Template</title>
<author fullname="Scott Shenker" initials="S." surname="Shenker">
<organization>Xerox PARC</organization>

<address>
<postal>
<street>3333 Coyote Hill Road</street>
<street>Palo Alto</street>
<street>CA  94304-1314</street>
</postal>

<phone>415-812-4840</phone>
<facsimile>415-812-4471</facsimile>
<email>shenker@parc.xerox.com</email>
</address>
</author>

<author fullname="John Wroclawski" initials="J." surname="Wroclawski">
<organization>MIT Laboratory for Computer Science</organization>

<address>
<postal>
<street>545 Technology Sq.</street>
<street>Cambridge</street>
<street>MA  02139</street>
</postal>

<phone>617-253-7885</phone>
<facsimile>617-253-2673</facsimile>
<email>jtw@lcs.mit.edu</email>
</address>
</author>

<date year="1997" month="September" />
<area>Internet</area>
<keyword>Quality of Service</keyword>

<abstract>
<t>
   This document defines a framework for specifying services provided by
   network elements, and available to applications, in an internetwork
   which offers multiple qualities of service. The document first
   provides some necessary context -- including relevant definitions and
   suggested data formats -- and then specifies a &quot;template&quot; which
   service specification documents should follow. The specification
   template includes per-element requirements such as the service&apos;s
   packet handling behavior, parameters required and made available by
   the service, traffic specification and policing requirements, and
   traffic ordering relationships.  It also includes evaluation criteria
   for elements providing the service, and examples of how the service
   might be implemented (by network elements) and used (by
   applications).
</t>
</abstract>
</front>

<seriesInfo value="2216" name="RFC" />
<format octets="64460" type="HTML" target="http://xml.resource.org/public/rfc/html/rfc2216.html" />
<format octets="52765" type="XML" target="http://xml.resource.org/public/rfc/xml/rfc2216.xml" />
</reference>


<reference target2="reference.RFC.2217.xml" anchor="RFC2217">
<front>
<title>Telnet Com Port Control Option</title>
<author fullname="Glen Clark, Software Architect" initials="G." surname="Clark">
<organization>Cisco Systems, Inc.</organization>

<address>
<postal>
<street>170 West Tasman Drive</street>
<street>San Jose</street>
<street>CA  96134</street>
<country>USA</country>
</postal>

<email>glenc@cisco.com</email>
<uri>www.cisco.com</uri>
</address>
</author>

<date year="1997" month="October" />
<area>Applications</area>
<keyword>telnet</keyword>
</front>

<seriesInfo value="2217" name="RFC" />
<format octets="41531" type="HTML" target="http://xml.resource.org/public/rfc/html/rfc2217.html" />
<format octets="31426" type="XML" target="http://xml.resource.org/public/rfc/xml/rfc2217.xml" />
</reference>


<reference target2="reference.RFC.2218.xml" anchor="RFC2218">
<front>
<title abbrev="Common Schema for IWPS">A Common Schema for the Internet White Pages Service</title>
<author fullname="Tony Genovese" initials="T." surname="Genovese">
<organization>The Microsoft Corporation</organization>

<address>
<postal>
<street>One Microsoft Way</street>
<street>Redmond</street>
<street>Washington 98007</street>
<country>USA</country>
</postal>

<phone>(206) 703-0852</phone>
<email>TonyG@Microsoft.com</email>
</address>
</author>

<author fullname="Barbara Jennings" initials="B." surname="Jennings">
<organization>Sandia National Laboratories</organization>

<address>
<postal>
<street>Albuquerque</street>
<street>New Mexico 87106</street>
<country>USA</country>
</postal>

<phone>(505) 845-8554</phone>
<email>jennings@sandia.gov</email>
</address>
</author>

<date year="1997" month="October" />
<area>Applications</area>
<keyword>white pages</keyword>

<abstract>
<t>
   This work is the result of the IETF Integrated Directory Services
   (IDS) Working Group.  The IDS Working Group proposes a standard
   specification for a simple Internet White Pages service by defining a
   common schema for use by the various White Pages servers.  This
   schema is independent of specific implementations of the White Pages
   service.
</t>

<t>
   This document specifies the minimum set of core attributes of a White
   Pages entry for an individual and describes how new objects with
   those attributes can be defined and published.  It does not describe
   how to represent other objects in the White Pages service.  Further,
   it does not address the search sort expectations within a particular
   service.
</t>
</abstract>
</front>

<seriesInfo value="2218" name="RFC" />
<format octets="32660" type="HTML" target="http://xml.resource.org/public/rfc/html/rfc2218.html" />
<format octets="19412" type="XML" target="http://xml.resource.org/public/rfc/xml/rfc2218.xml" />
</reference>


<reference target2="reference.RFC.2219.xml" anchor="RFC2219">
<front>
<title abbrev="DNS Aliases">Use of DNS Aliases for Network Services</title>
<author fullname="Martin Hamilton" initials="M." surname="Hamilton">
<organization>Loughborough University of Technology, Department of Computer Studies</organization>

<address>
<postal>
<street />
<city>Leicestershire</city>
<region>England</region>
<code>LE11 3TU</code>
<country>UK</country>
</postal>

<email>m.t.hamilton@lut.ac.uk</email>
</address>
</author>

<author fullname="Russ Wright" initials="R." surname="Wright">
<organization>Lawrence Berkeley National Laboratory, Information &amp; Computing Sciences Division</organization>

<address>
<postal>
<street>1 Cyclotron Road</street>
<street>Mail-Stop: 50A-3111</street>
<city>Berkeley</city>
<region>CA</region>
<code>94720</code>
<country>US</country>
</postal>

<email>wright@lbl.gov</email>
</address>
</author>

<date year="1997" month="October" />

<abstract>
<t>It has become a common practice to use symbolic names (usually CNAMEs) in the Domain Name Service (DNS -,) to refer to network services such as anonymous FTPservers, Gopherservers, and most notably World-Wide Web HTTPservers.  This is desirable for a number of reasons.  It provides a way of moving services from one machine to another transparently, and a mechanism by which people or agents may programmatically discover that an organization runs, say, a World-Wide Web server.</t>

<t>Although this approach has been almost universally adopted, there is no standards document or similar specification for these commonly used names.  This document seeks to rectify this situation by gathering together the extant 'folklore' on naming conventions, and proposes a mechanism for accommodating new protocols.</t>

<t>It is important to note that these naming conventions do not provide a complete long term solution to the problem of finding a particular network service for a site.  There are efforts in other IETF working groups to address the long term solution to this problem, such as the Server Location Resource Records (DNS SRV)work.</t>
</abstract>
</front>

<seriesInfo value="17" name="BCP" />
<seriesInfo value="2219" name="RFC" />
</reference>


<reference target2="reference.RFC.2220.xml" anchor="RFC2220">
<front>
<title abbrev="MARC Content-type">The Application/MARC Content-type</title>
<author fullname="Rebecca Guenther" initials="R." surname="Guenther">
<organization>Network Development &amp; MARC Standards Office</organization>

<address>
<postal>
<street>Library of Congress</street>
<street>101 Independence Ave.</street>
<street>Washington</street>
<street>DC 20540-4102 U.S.A.</street>
<country>SE</country>
</postal>

<phone>+1 (202) 707-5092</phone>
<facsimile>+1 (202) 707-0115</facsimile>
<email>rgue@loc.gov</email>
</address>
</author>

<date year="1997" month="October" />
<area>Applications</area>
<keyword>MARC</keyword>
<keyword>content-type</keyword>

<abstract>
<t>
   This memorandum provides a mechanism for representing objects which
   are files of Machine-Readable Cataloging records (MARC).  The MARC
   formats are standards for the representation and communication of
   bibliographic and related information.  A MARC record contains
   metadata for an information resource following MARC format
   specifications.
</t>
</abstract>
</front>

<seriesInfo value="2220" name="RFC" />
<format octets="16342" type="HTML" target="http://xml.resource.org/public/rfc/html/rfc2220.html" />
<format octets="6369" type="XML" target="http://xml.resource.org/public/rfc/xml/rfc2220.xml" />
</reference>


<reference target2="reference.RFC.2221.xml" anchor="RFC2221">
<front>
<title>IMAP4 Login Referrals</title>
<author fullname="Mike Gahrns" initials="M." surname="Gahrns">
<organization>Microsoft</organization>

<address>
<postal>
<street>One Microsoft Way</street>
<street>Redmond</street>
<street>WA</street>
<street>98072</street>
</postal>

<phone>(206) 936-9833</phone>
<email>mikega@microsoft.com</email>
</address>
</author>

<date year="1997" month="October" />
<area>Applications</area>
<keyword>IMAP</keyword>
<keyword>internet message access protocol</keyword>
</front>

<seriesInfo value="2221" name="RFC" />
<format octets="19992" type="HTML" target="http://xml.resource.org/public/rfc/html/rfc2221.html" />
<format octets="8419" type="XML" target="http://xml.resource.org/public/rfc/xml/rfc2221.xml" />
</reference>


<reference target2="reference.RFC.2222.xml" anchor="RFC2222">
<front>
<title abbrev="SASL">Simple Authentication and Security Layer (SASL)</title>
<author fullname="John G. Myers" initials="J.G." surname="Myers">
<organization>Netscape Communications</organization>

<address>
<postal>
<street>501 E. Middlefield Road</street>
<street>Mail Stop MV-029</street>
<street>Mountain View</street>
<street>CA 94043-4042</street>
</postal>

<email>jgmyers@netscape.com</email>
</address>
</author>

<date year="1997" month="October" />
<area>Security</area>
<keyword>authentication</keyword>
<keyword>security</keyword>
</front>

<seriesInfo value="2222" name="RFC" />
<format octets="47275" type="HTML" target="http://xml.resource.org/public/rfc/html/rfc2222.html" />
<format octets="33815" type="XML" target="http://xml.resource.org/public/rfc/xml/rfc2222.xml" />
</reference>


<reference target2="reference.RFC.2223.xml" anchor="RFC2223">
<front>
<title>Instructions to RFC Authors</title>
<author fullname="Jon Postel" initials="J." surname="Postel">
<organization>USC/Information Sciences Institute</organization>

<address>
<postal>
<street>4676 Admiralty Way</street>
<street>Marina del Rey</street>
<street>CA  90292</street>
</postal>

<phone>+1 310-822-1511</phone>
<facsimile>+1 310-823-6714</facsimile>
<email>Postel@ISI.EDU</email>
</address>
</author>

<author fullname="Joyce K. Reynolds" initials="J.K." surname="Reynolds">
<organization>USC/Information Sciences Institute</organization>

<address>
<postal>
<street>4676 Admiralty Way</street>
<street>Marina del Rey</street>
<street>CA  90292</street>
</postal>

<phone>+1 310-822-1511</phone>
<facsimile>+1 310-823-6714</facsimile>
<email>jkrey@isi.edu</email>
</address>
</author>

<date year="1997" month="October" />
<area>General</area>
<keyword>RFC authors</keyword>
</front>

<seriesInfo value="2223" name="RFC" />
<format octets="52847" type="HTML" target="http://xml.resource.org/public/rfc/html/rfc2223.html" />
<format octets="37425" type="XML" target="http://xml.resource.org/public/rfc/xml/rfc2223.xml" />
</reference>


<reference target2="reference.RFC.2224.xml" anchor="RFC2224">
<front>
<title>NFS URL Scheme</title>
<author fullname="Brent Callaghan" initials="B." surname="Callaghan">
<organization>Sun Microsystems, Inc.</organization>

<address>
<postal>
<street>Mailstop Mpk17-201</street>
<street>901 San Antonio Road</street>
<street>Palo Alto</street>
<street>California 94303</street>
</postal>

<phone>1-415-786-5067</phone>
<facsimile>1-415-786-5896</facsimile>
<email>brent.callaghan@eng.sun.com</email>
</address>
</author>

<date year="1997" month="October" />
<area>Applications</area>
<keyword>NFS</keyword>
<keyword>network file system</keyword>
<keyword>uniform resource</keyword>

<abstract>
<t>
   A new URL scheme, &apos;nfs&apos; is defined.  It is used to refer to files and
   directories on NFS servers using the general URL syntax defined in
   RFC 1738, &quot;Uniform Resource Locators (URL)&quot;.
</t>

<t>
   This scheme uses the public filehandle and multi-component lookup
   [RFC2054, RFC2055] to access server data with a minimum of protocol
   overhead.
</t>

<t>
   The NFS protocol provides access to shared filesystems across
   networks.  It is designed to be machine, operating system, network
   architecture, and transport protocol independent.  The protocol
   currently exists in two versions: version 2  and version 3
   , both built on ONC RPC  at its associated eXternal
   Data Representation (XDR)  and Binding Protocol .
</t>
</abstract>
</front>

<seriesInfo value="2224" name="RFC" />
<format octets="35259" type="HTML" target="http://xml.resource.org/public/rfc/html/rfc2224.html" />
<format octets="24805" type="XML" target="http://xml.resource.org/public/rfc/xml/rfc2224.xml" />
</reference>


<reference target2="reference.RFC.2225.xml" anchor="RFC2225">
<front>
<title>Classical IP and ARP over ATM</title>
<author fullname="Mark Laubach" initials="M." surname="Laubach">
<organization>Com21, Inc.</organization>

<address>
<postal>
<street>750 Tasman Drive</street>
<street>Milpitas</street>
<street>CA 95035</street>
</postal>

<phone>408.953.9175</phone>
<facsimile>408.953.9299</facsimile>
<email>laubach@com21.com</email>
</address>
</author>

<author fullname="Joel Halpern" initials="J." surname="Halpern">
<organization>Newbridge Networks, Inc.</organization>

<address>
<postal>
<street>593 Herndon Parkway</street>
<street>Herndon</street>
<street>VA  22070-5241</street>
</postal>

<phone>703.736.5954</phone>
<facsimile>703.736.5959</facsimile>
<email>jhalpern@Newbridge.com</email>
</address>
</author>

<date year="1998" month="April" />
<area>Internet</area>
<keyword>address resolution protocol</keyword>
<keyword>asynchronous transfer mode</keyword>
</front>

<seriesInfo value="2225" name="RFC" />
<format octets="85159" type="HTML" target="http://xml.resource.org/public/rfc/html/rfc2225.html" />
<format octets="67323" type="XML" target="http://xml.resource.org/public/rfc/xml/rfc2225.xml" />
</reference>


<reference target2="reference.RFC.2226.xml" anchor="RFC2226">
<front>
<title>IP Broadcast over ATM Networks</title>
<author fullname="Timothy J. Smith" initials="T.J." surname="Smith">
<organization>Network Routing Systems,</organization>

<address>
<postal>
<street>International Business Machines Corporation.</street>
<street>N21/664</street>
<street>P.O.Box 12195</street>
<street>Research Triangle Park</street>
<street>NC 27709</street>
</postal>

<phone>(919) 254-4723</phone>
<email>tjsmith@vnet.ibm.com</email>
</address>
</author>

<author fullname="Grenville Armitage" initials="G." surname="Armitage">
<organization>Bell Labs, Lucent Technologies.</organization>

<address>
<postal>
<street>101 Crawfords Corner Rd</street>
<street>Holmdel</street>
<street>NJ</street>
<street>07733</street>
</postal>

<email>gja@lucent.com</email>
</address>
</author>

<date year="1997" month="October" />
<area>Internet</area>
<keyword>asynchronous transfer mode</keyword>
<keyword>broadcast</keyword>
<keyword>multicast</keyword>

<abstract>
<t>
   This memo describes how the IP multicast service being developed by
   the IP over ATM working group may be used to support IP broadcast
   transmission. The solution revolves around treating the broadcast
   problem as a special case of multicast, where every host in the
   subnet or cluster is a member of the group.
</t>

<t>
   An understanding of the services provided by RFC 2022 is assumed.
</t>
</abstract>
</front>

<seriesInfo value="2226" name="RFC" />
<format octets="44222" type="HTML" target="http://xml.resource.org/public/rfc/html/rfc2226.html" />
<format octets="30634" type="XML" target="http://xml.resource.org/public/rfc/xml/rfc2226.xml" />
</reference>


<reference target2="reference.RFC.2227.xml" anchor="RFC2227">
<front>
<title abbrev="Hit-Metering and Usage-Limiting">Simple Hit-Metering and Usage-Limiting for HTTP</title>
<author fullname="Jeffrey C. Mogul" initials="J." surname="Mogul">
<organization>Western Research Laboratory, Digital Equipment Corporation</organization>

<address>
<postal>
<street>250 University Avenue</street>
<city>Palo Alto</city>
<region>CA</region>
<code>94301</code>
<country>US</country>
</postal>

<phone>+1 415 617 3304</phone>
<email>mogul@wrl.dec.com</email>
</address>
</author>

<author fullname="Paul J. Leach" initials="P.J." surname="Leach">
<organization>Microsoft</organization>

<address>
<postal>
<street>1 Microsoft Way</street>
<city>Redmond</city>
<region>WA</region>
<code>98052</code>
<country>US</country>
</postal>

<email>paulle@microsoft.com</email>
</address>
</author>

<date year="1997" month="October" />

<abstract>
<t>This document proposes a simple extension to HTTP, using a new "Meter" header, which permits a limited form of demographic information (colloquially called "hit-counts") to be reported by caches to origin servers, in a more efficient manner than the "cache-busting" techniques currently used.  It also permits an origin server to control the number of times a cache uses a cached response, and outlines a technique that origin servers can use to capture referral information without "cache-busting."</t>
</abstract>
</front>

<seriesInfo value="2227" name="RFC" />
</reference>


<reference target2="reference.RFC.2228.xml" anchor="RFC2228">
<front>
<title>FTP Security Extensions</title>
<author fullname="Marc Horowitz" initials="M." surname="Horowitz">
<organization>Cygnus Solutions</organization>

<address>
<postal>
<street>955 Massachusetts Avenue</street>
<street>Cambridge</street>
<street>MA 02139</street>
</postal>

<phone>+1 617 354 7688</phone>
<email>marc@cygnus.com</email>
</address>
</author>

<date year="1997" month="October" />
<area>Applications</area>
<keyword>authentication</keyword>
<keyword>file transfer</keyword>
<keyword>file transfer protocol</keyword>
<keyword>security</keyword>

<abstract>
<t>
   This document defines extensions to the FTP specification STD 9, RFC
   959, &quot;FILE TRANSFER PROTOCOL (FTP)&quot; (October 1985).  These extensions
   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.
</t>

<t>
   The following new optional commands are introduced in this
   specification:

<list>
<t>
      AUTH (Authentication/Security Mechanism),
</t>

<t>
      ADAT (Authentication/Security Data),
</t>

<t>
      PROT (Data Channel Protection Level),
</t>

<t>
      PBSZ (Protection Buffer Size),
</t>

<t>
      CCC (Clear Command Channel),
</t>

<t>
      MIC (Integrity Protected Command),
</t>

<t>
      CONF (Confidentiality Protected Command), and
</t>

<t>
      ENC (Privacy Protected Command).
</t>
</list>
</t>

<t>
   A new class of reply types (6yz) is also introduced for protected
   replies.
</t>

<t>
   None of the above commands are required to be implemented, but
   interdependencies exist.  These dependencies are documented with the
   commands.
</t>

<t>
   Note that this specification is compatible with STD 9, RFC 959.
</t>
</abstract>
</front>

<seriesInfo value="2228" name="RFC" />
<format octets="72070" type="HTML" target="http://xml.resource.org/public/rfc/html/rfc2228.html" />
<format octets="57937" type="XML" target="http://xml.resource.org/public/rfc/xml/rfc2228.xml" />
</reference>


<reference target2="reference.RFC.2229.xml" anchor="RFC2229">
<front>
<title>A Dictionary Server Protocol</title>
<author fullname="Rickard E. Faith" initials="R.E." surname="Faith">
<organization />

<address>
<email>faith@cs.unc.edu</email>
</address>
</author>

<author fullname="Bret Martin" initials="B." surname="Martin">
<organization />

<address>
<email>bamartin@miranda.org</email>
</address>
</author>

<date year="1997" month="October" />
<area>Applications</area>
<keyword>dictionary</keyword>

<abstract>
<t>
   The Dictionary Server Protocol (DICT) is a TCP transaction based
   query/response protocol that allows a client to access dictionary
   definitions from a set of natural language dictionary databases.
</t>
</abstract>
</front>

<seriesInfo value="2229" name="RFC" />
<format octets="77125" type="HTML" target="http://xml.resource.org/public/rfc/html/rfc2229.html" />
<format octets="64242" type="XML" target="http://xml.resource.org/public/rfc/xml/rfc2229.xml" />
</reference>


<reference target2="reference.RFC.2230.xml" anchor="RFC2230">
<front>
<title abbrev="DNS Key Exchange Delegation Record">Key Exchange Delegation Record for the DNS</title>
<author fullname="Randall Atkinson" initials="R." surname="Atkinson">
<organization>Code 5544</organization>

<address>
<postal>
<street>Naval Research Laboratory</street>
<street>4555 Overlook Avenue</street>
<street>SW</street>
<street>Washington</street>
<street>DC 20375-5337</street>
</postal>

<phone>(DSN) 354-8590</phone>
<email>atkinson@itd.nrl.navy.mil</email>
</address>
</author>

<date year="1997" month="November" />
<area>Security</area>
<keyword>domain name system</keyword>
<keyword>key exchange</keyword>
<keyword>security</keyword>

<abstract>
<t>
   This note describes a mechanism whereby authorisation for one node to
   act as key exchanger for a second node is delegated and made
   available via the Secure DNS.  This mechanism is intended to be used
   only with the Secure DNS.  It can be used with several security
   services.  For example, a system seeking to use IP Security [RFC-
   1825, RFC-1826, RFC-1827] to protect IP packets for a given
   destination can use this mechanism to determine the set of authorised
   remote key exchanger systems for that destination.
</t>
</abstract>
</front>

<seriesInfo value="2230" name="RFC" />
<format octets="35933" type="HTML" target="http://xml.resource.org/public/rfc/html/rfc2230.html" />
<format octets="26370" type="XML" target="http://xml.resource.org/public/rfc/xml/rfc2230.xml" />
</reference>


<reference target2="reference.RFC.2231.xml" anchor="RFC2231">
<front>
<title abbrev="MIME Value and Encoded Word Extensions">MIME Parameter Value and Encoded Word Extensions: Character Sets, Languages, and Continuations</title>
<author fullname="Ned Freed" initials="N." surname="Freed">
<organization>Innosoft International, Inc.</organization>

<address>
<postal>
<street>1050 Lakes Drive</street>
<street>West Covina</street>
<street>CA 91790</street>
<country>USA</country>
</postal>

<phone>+1 626 919 3600</phone>
<facsimile>+1 626 919 3614</facsimile>
<email>ned.freed@innosoft.com</email>
</address>
</author>

<author fullname="Keith Moore" initials="K." surname="Moore">
<organization>Computer Science Dept.</organization>

<address>
<postal>
<street>University of Tennessee</street>
<street>107 Ayres Hall</street>
<street>Knoxville</street>
<street>TN 37996-1301</street>
<country>USA</country>
</postal>

<email>moore@cs.utk.edu</email>
</address>
</author>

<date year="1997" month="November" />
<area>Applications</area>
<keyword>MIME</keyword>
<keyword>character encoding</keyword>
<keyword>media type</keyword>
<keyword>multipurpose internet mail extensions</keyword>
</front>

<seriesInfo value="2231" name="RFC" />
<format octets="30810" type="HTML" target="http://xml.resource.org/public/rfc/html/rfc2231.html" />
<format octets="17657" type="XML" target="http://xml.resource.org/public/rfc/xml/rfc2231.xml" />
</reference>


<reference target2="reference.RFC.2232.xml" anchor="RFC2232">
<front>
<title abbrev="DLUR MIB">Definitions of Managed Objects for DLUR using SMIv2</title>
<author fullname="Bob Clouston" initials="B." surname="Clouston">
<organization>Cisco Systems</organization>

<address>
<postal>
<street>7025 Kit Creek Road</street>
<street>P.O. Box 14987</street>
<street>Research Triangle Park</street>
<street>NC 27709</street>
<country>USA</country>
</postal>

<phone>+1 919 472 2333</phone>
<email>clouston@cisco.com</email>
</address>
</author>

<author fullname="Bob Moore" initials="B." surname="Moore">
<organization>IBM Corporation</organization>

<address>
<postal>
<street>800 Park Offices Drive</street>
<street>CNMA/664</street>
<street>P.O. Box 12195</street>
<street>Research Triangle Park</street>
<street>NC 27709</street>
<country>USA</country>
</postal>

<phone>+1 919 254 4436</phone>
<email>remoore@ralvm6.vnet.ibm.com</email>
</address>
</author>

<date year="1997" month="November" />
<area>Management</area>
<keyword>Management Information Base</keyword>
<keyword>managed object</keyword>
<keyword>structure of management information version 2</keyword>
</front>

<seriesInfo value="2232" name="RFC" />
<format octets="49338" type="HTML" target="http://xml.resource.org/public/rfc/html/rfc2232.html" />
<format octets="36396" type="XML" target="http://xml.resource.org/public/rfc/xml/rfc2232.xml" />
</reference>


<reference target2="reference.RFC.2233.xml" anchor="RFC2233">
<front>
<title abbrev="Interfaces MIB">The Interfaces Group MIB using SMIv2</title>
<author fullname="Keith McCloghrie" initials="K." surname="McCloghrie">
<organization>Cisco Systems, Inc.</organization>

<address>
<postal>
<street>170 West Tasman Drive</street>
<street>San Jose</street>
<street>CA  95134-1706</street>
</postal>

<phone>408-526-5260</phone>
<email>kzm@cisco.com</email>
</address>
</author>

<author fullname="Frank Kastenholz" initials="F." surname="Kastenholz">
<organization>FTP Software</organization>

<address>
<postal>
<street>2 High Street</street>
<street>North Andover</street>
<street>Mass. USA 01845</street>
</postal>

<phone>508-685-4000</phone>
<email>kasten@ftp.com</email>
</address>
</author>

<date year="1997" month="November" />
<area>Management</area>
<keyword>Management Information Base</keyword>
<keyword>structure of management information version 2</keyword>
</front>

<seriesInfo value="2233" name="RFC" />
<format octets="158838" type="HTML" target="http://xml.resource.org/public/rfc/html/rfc2233.html" />
<format octets="143771" type="XML" target="http://xml.resource.org/public/rfc/xml/rfc2233.xml" />
</reference>


<reference target2="reference.RFC.2234.xml" anchor="RFC2234">
<front>
<title abbrev="ABNF for Syntax Specifications">Augmented BNF for Syntax Specifications: ABNF</title>
<author fullname="David H. Crocker" initials="D.H." surname="Crocker">
<organization>Internet Mail Consortium</organization>

<address>
<postal>
<street>675 Spruce Dr.</street>
<city>Sunnyvale</city>
<region>CA</region>
<code>94086</code>
<country>US</country>
</postal>

<phone>+1 408 246 8253</phone>
<facsimile>+1 408 249 6205</facsimile>
<email>dcrocker@imc.org</email>
</address>
</author>

<author fullname="Paul Overell" initials="P." surname="Overell">
<organization>Demon Internet Ltd</organization>

<address>
<postal>
<street>Dorking Business Park</street>
<street>Dorking</street>
<city>Surrey</city>
<region>England</region>
<code>RH4 1HN</code>
<country>UK</country>
</postal>

<email>paulo@turnpike.com</email>
</address>
</author>

<date year="1997" month="November" />
</front>

<seriesInfo value="2234" name="RFC" />
</reference>


<reference target2="reference.RFC.2235.xml" anchor="RFC2235">
<front>
<title abbrev="Hobbes&apos; Internet Timeline">Hobbes&apos; Internet Timeline</title>
<author fullname="Robert H. Zakon" initials="R.H." surname="Zakon">
<organization>Internet Evangelist</organization>

<address>
<postal>
<street>The MITRE Corporation</street>
<street>1820 Dolley Madison Blvd</street>
<street>McLean</street>
<street>Virginia</street>
<street>USA 22102</street>
</postal>

<phone>(703) 883-7790</phone>
<email>zakon@info.isoc.org</email>
</address>
</author>

<date year="1997" month="November" />
<area>General</area>
<keyword>Hobbe&apos;s Internet Timeline</keyword>
</front>

<seriesInfo value="2235" name="RFC" />
<format octets="54084" type="HTML" target="http://xml.resource.org/public/rfc/html/rfc2235.html" />
<format octets="43252" type="XML" target="http://xml.resource.org/public/rfc/xml/rfc2235.xml" />
</reference>


<reference target2="reference.RFC.2236.xml" anchor="RFC2236">
<front>
<title abbrev="Internet Group Management Protocol">Internet Group Management Protocol, Version 2</title>
<author fullname="William C. Fenner" initials="W.C." surname="Fenner">
<organization>Xerox PARC</organization>

<address>
<postal>
<street>3333 Coyote Hill Road</street>
<street>Palo Alto</street>
<street>CA 94304</street>
</postal>

<phone>+1 650 812 4816</phone>
<email>fenner@parc.xerox.com</email>
</address>
</author>

<date year="1997" month="November" />
<area>Internet</area>
<keyword>internet group multicast protocol</keyword>
<keyword>multicast</keyword>
<keyword>routing</keyword>

<abstract>
<t>
   This memo documents IGMPv2, used by IP hosts to report their
   multicast group memberships to routers.  It updates STD 5, RFC 1112.
</t>

<t>
   IGMPv2 allows group membership termination to be quickly reported to
   the routing protocol, which is important for high-bandwidth multicast
   groups and/or subnets with highly volatile group membership.
</t>

<t>
   This document is a product of the Inter-Domain Multicast Routing
   working group within the Internet Engineering Task Force.  Comments
   are solicited and should be addressed to the working group&apos;s mailing
   list at idmr@cs.ucl.ac.uk and/or the author(s).
</t>
</abstract>
</front>

<seriesInfo value="2236" name="RFC" />
<format octets="65437" type="HTML" target="http://xml.resource.org/public/rfc/html/rfc2236.html" />
<format octets="50863" type="XML" target="http://xml.resource.org/public/rfc/xml/rfc2236.xml" />
</reference>


<reference target2="reference.RFC.2237.xml" anchor="RFC2237">
<front>
<title abbrev="Japanese Character Encoding">Japanese Character Encoding for Internet Messages</title>
<author fullname="Kenzaburo Tamaru" initials="K." surname="Tamaru">
<organization>Microsoft Corporation</organization>

<address>
<postal>
<street>One Microsoft Way</street>
<street>Redmond</street>
<street>WA 98052-6399</street>
</postal>

<email>kenzat@microsoft.com</email>
</address>
</author>

<date year="1997" month="November" />
<area>Applications</area>
<keyword>Japanese</keyword>
<keyword>character encoding</keyword>
<keyword>internet message</keyword>
</front>

<seriesInfo value="2237" name="RFC" />
<format octets="18840" type="HTML" target="http://xml.resource.org/public/rfc/html/rfc2237.html" />
<format octets="9200" type="XML" target="http://xml.resource.org/public/rfc/xml/rfc2237.xml" />
</reference>


<reference target2="reference.RFC.2238.xml" anchor="RFC2238">
<front>
<title abbrev="HPR MIB">Definitions of Managed Objects for HPR using SMIv2</title>
<author fullname="Bob Clouston" initials="B." surname="Clouston">
<organization>Cisco Systems</organization>

<address>
<postal>
<street>7025 Kit Creek Road</street>
<street>P.O. Box 14987</street>
<street>Research Triangle Park</street>
<street>NC 27709</street>
<country>USA</country>
</postal>

<phone>+1 919 472 2333</phone>
<email>clouston@cisco.com</email>
</address>
</author>

<author fullname="Bob Moore" initials="B." surname="Moore">
<organization>IBM Corporation</organization>

<address>
<postal>
<street>800 Park Offices Drive</street>
<street>CNMA/664</street>
<street>P.O. Box 12195</street>
<street>Research Triangle Park</street>
<street>NC 27709</street>
<country>USA</country>
</postal>

<phone>+1 919 254 4436</phone>
<email>remoore@ralvm6.vnet.ibm.com</email>
</address>
</author>

<date year="1997" month="November" />
<area>Management</area>
<area>Routing</area>
<keyword>Management Information Base</keyword>
<keyword>managed object</keyword>
<keyword>routing</keyword>
<keyword>structure of management information version 2</keyword>
</front>

<seriesInfo value="2238" name="RFC" />
<format octets="75326" type="HTML" target="http://xml.resource.org/public/rfc/html/rfc2238.html" />
<format octets="62621" type="XML" target="http://xml.resource.org/public/rfc/xml/rfc2238.xml" />
</reference>


<reference target2="reference.RFC.2239.xml" anchor="RFC2239">
<front>
<title abbrev="IEEE 802.3 MIB">Definitions of Managed Objects for IEEE 802.3 Medium Attachment Units (MAUs) using SMIv2</title>
<author fullname="Kathryn de Graaf" initials="K." surname="de Graaf">
<organization>3Com Corporation</organization>

<address>
<postal>
<street>Southborough</street>
<street>MA 01772</street>
<country>USA</country>
</postal>

<phone>(508)229-1627</phone>
<facsimile>(508)490-5882</facsimile>
<email>kdegraaf@isd.3com.com</email>
<uri>pike</uri>
</address>
</author>

<author fullname="Dan Romascanu" initials="D." surname="Romascanu">
<organization>Madge Networks (Israel) Ltd.</organization>

<address>
<postal>
<street>Atidim Technology Park</street>
<street>Bldg. 3</street>
</postal>

<phone>972-3-6458414, 6458458</phone>
<facsimile>972-3-6487146</facsimile>
<email>dromasca@madge.com</email>
</address>
</author>

<author fullname="Donna McMaster" initials="D." surname="McMaster">
<organization>Cisco Systems Inc.</organization>

<address>
<postal>
<street>170 West Tasman Drive</street>
<street>San Jose</street>
<street>CA 95134</street>
</postal>

<phone>: (408) 526-5260</phone>
<email>mcmaster@cisco.com</email>
</address>
</author>

<author fullname="Keith McCloghrie" initials="K." surname="McCloghrie">
<organization>Cisco Systems Inc.</organization>

<address>
<postal>
<street>170 West Tasman Drive</street>
<street>San Jose</street>
<street>CA 95134</street>
</postal>

<phone>(408) 526-5260</phone>
<email>kzm@cisco.com</email>
</address>
</author>

<author fullname="Sam Roberts" initials="S." surname="Roberts">
<organization>Farallon Computing, Inc.</organization>

<address>
<postal>
<street>2470 Mariner Square Loop</street>
<street>Alameda</street>
<street>CA 94501-1010</street>
</postal>

<phone>: (510) 814-5215</phone>
<email>sroberts@farallon.com</email>
</address>
</author>

<date year="1997" month="November" />
<area>Management</area>
<area>Internet</area>
<keyword>MIB</keyword>
<keyword>Institute of Electrical and Electronics Engineers</keyword>
<keyword>Management Information Base</keyword>
<keyword>ethernet</keyword>
<keyword>managed object</keyword>
<keyword>structure of management information version 2</keyword>

<abstract>
<t>
   This memo defines an portion of the Management Information Base (MIB)
   for use with network management protocols in the Internet community.
   In particular, it defines objects for managing 10 and 100 Mb/second
   Medium Attachment Units (MAUs) based on IEEE Std 802.3 Section 30,
   &quot;10 &amp; 100 Mb/s Management,&quot; October 26, 1995.
</t>
</abstract>
</front>

<seriesInfo value="2239" name="RFC" />
<format octets="92642" type="HTML" target="http://xml.resource.org/public/rfc/html/rfc2239.html" />
<format octets="78004" type="XML" target="http://xml.resource.org/public/rfc/xml/rfc2239.xml" />
</reference>


<reference target2="reference.RFC.2240.xml" anchor="RFC2240">
<front>
<title abbrev="Legal DNS">A Legal Basis for Domain Name Allocation</title>
<author fullname="Owain Vaughan" initials="O." surname="Vaughan">
<organization>Vaughan Enterprises</organization>

<address>
<postal>
<street>PO Box 155</street>
<street>Newport NP9 6YX</street>
<country>UK</country>
</postal>

<phone>+44 1633 677849/822164</phone>
<facsimile>+44 1633 663706</facsimile>
<email>owain@vaughan.com</email>
</address>
</author>

<date year="1997" month="November" />
<area>Applications</area>
<keyword>domain name</keyword>
</front>

<seriesInfo value="2240" name="RFC" />
<format octets="22823" type="HTML" target="http://xml.resource.org/public/rfc/html/rfc2240.html" />
<format octets="12688" type="XML" target="http://xml.resource.org/public/rfc/xml/rfc2240.xml" />
</reference>


<reference target2="reference.RFC.2241.xml" anchor="RFC2241">
<front>
<title abbrev="DHCP Options">DHCP Options for Novell Directory Services</title>
<author fullname="Don Provan" initials="D." surname="Provan">
<organization>Novell, Inc.</organization>

<address>
<postal>
<street>2180 Fortune Drive</street>
<street>San Jose</street>
<street>California</street>
<street>95131</street>
</postal>

<phone>+1 408 577 8440</phone>
<email>donp@Novell.Com</email>
</address>
</author>

<date year="1997" month="November" />
<area>Internet</area>
<keyword>directory</keyword>
<keyword>dynamic host configuration protocol</keyword>

<abstract>
<t>
   This document defines three new DHCP options for delivering
   configuration information to clients of the Novell Directory
   Services. The first option carries a list of NDS servers. The second
   option carries the name of the client&apos;s NDS tree. The third carries
   the initial NDS context. These three options provide an NDS client
   with enough information to connect to an NDS tree without manual
   configuration of the client.
</t>
</abstract>
</front>

<seriesInfo value="2241" name="RFC" />
<format octets="19716" type="HTML" target="http://xml.resource.org/public/rfc/html/rfc2241.html" />
<format octets="8466" type="XML" target="http://xml.resource.org/public/rfc/xml/rfc2241.xml" />
</reference>


<reference target2="reference.RFC.2242.xml" anchor="RFC2242">
<front>
<title abbrev="NetWare/IP">NetWare/IP Domain Name and Information</title>
<author fullname="Ralph Droms" initials="R." surname="Droms">
<organization>Computer Science Department</organization>

<address>
<postal>
<street>323 Dana Engineering</street>
<street>Bucknell University</street>
<street>Lewisburg</street>
<street>PA 17837</street>
</postal>

<phone>(717) 524-1145</phone>
<email>droms@bucknell.edu</email>
</address>
</author>

<author fullname="Kester Fong" initials="K." surname="Fong">
<organization>Information Access Division</organization>

<address>
<postal>
<street>Novell Inc.</street>
<street>SJF-8-265</street>
<street>2010 Fortune Dr</street>
<street>San Jose</street>
<street>CA95131</street>
</postal>

<phone>(408)-577-8959</phone>
<email>kfong@novell.com</email>
</address>
</author>

<date year="1997" month="November" />
<area>Internet</area>
<keyword>Novell internetwork packet exchange</keyword>
<keyword>domain name</keyword>
<keyword>dynamic host configuration protocol</keyword>
</front>

<seriesInfo value="2242" name="RFC" />
<format octets="23873" type="HTML" target="http://xml.resource.org/public/rfc/html/rfc2242.html" />
<format octets="11379" type="XML" target="http://xml.resource.org/public/rfc/xml/rfc2242.xml" />
</reference>


<reference target2="reference.RFC.2243.xml" anchor="RFC2243">
<front>
<title abbrev="OTP">OTP Extended Responses</title>
<author fullname="Craig Metz" initials="C." surname="Metz">
<organization>The Inner Net</organization>

<address>
<postal>
<street>Box 10314-1936</street>
<street>Blacksburg</street>
<street>VA 24062-0314</street>
<street>(DSN) 354-8590</street>
</postal>

<email>cmetz@inner.net</email>
</address>
</author>

<date year="1997" month="November" />
<keyword>one-time password</keyword>

<abstract>
<t>
   This document provides a specification for a type of response to an
   OTP  challenge that carries explicit indication of the
   response&apos;s encoding. Codings for the two mandatory OTP data formats
   using this new type of response are presented.
</t>

<t>
   This document also provides a specification for a response that
   allows an OTP generator to request that a server re-initialize a
   sequence and change parameters such as the secret pass phrase.
</t>
</abstract>
</front>

<seriesInfo value="2243" name="RFC" />
<format octets="31927" type="HTML" target="http://xml.resource.org/public/rfc/html/rfc2243.html" />
<format octets="20705" type="XML" target="http://xml.resource.org/public/rfc/xml/rfc2243.xml" />
</reference>


<reference target2="reference.RFC.2244.xml" anchor="RFC2244">
<front>
<title abbrev="ACAP">ACAP -- Application Configuration Access Protocol</title>
<author fullname="Chris Newman" initials="C." surname="Newman">
<organization>Innosoft International, Inc.</organization>

<address>
<postal>
<street>1050 Lakes Drive</street>
<city>West Covina</city>
<region>CA</region>
<code>91790</code>
<country>US</country>
</postal>

<email>chris.newman@innosoft.com</email>
</address>
</author>

<author fullname="John Gardiner Myers" initials="J.G." surname="Myers">
<organization>Netscape Communications</organization>

<address>
<postal>
<street>501 East Middlefield Road</street>
<street>Mail Stop MV-029</street>
<city>Mountain View</city>
<region>CA</region>
<code>94043</code>
<country>US</country>
</postal>

<email>jgmyers@netscape.com</email>
</address>
</author>

<date year="1997" month="November" />

<abstract>
<t>The Application Configuration Access Protocol (ACAP) is designed to support remote storage and access of program option, configuration and preference information.  The data store model is designed to allow a client relatively simple access to interesting data, to allow new information to be easily added without server re-configuration, and to promote the use of both standardized data and custom or proprietary data.  Key features include "inheritance" which can be used to manage default values for configuration settings and access control lists which allow interesting personal information to be shared and group information to be restricted.</t>
</abstract>
</front>

<seriesInfo value="2244" name="RFC" />
</reference>


<reference target2="reference.RFC.2245.xml" anchor="RFC2245">
<front>
<title abbrev="Anonymous SASL">Anonymous SASL Mechanism</title>
<author fullname="Chris Newman" initials="C." surname="Newman">
<organization>Innosoft International, Inc.</organization>

<address>
<postal>
<street>1050 Lakes Drive</street>
<street>West Covina</street>
<street>CA 91790</street>
<country>USA</country>
</postal>

<email>chris.newman@innosoft.com</email>
</address>
</author>

<date year="1997" month="November" />
<area>Security</area>
<area>Applications</area>
<keyword>anonymous</keyword>

<abstract>
<t>
   It is common practice on the Internet to permit anonymous access to
   various services.  Traditionally, this has been done with a plain
   text password mechanism using &quot;anonymous&quot; as the user name and
   optional trace information, such as an email address, as the
   password.  As plaintext login commands are not permitted in new IETF
   protocols, a new way to provide anonymous login is needed within the
   context of the SASL  framework.
</t>
</abstract>
</front>

<seriesInfo value="2245" name="RFC" />
<format octets="21425" type="HTML" target="http://xml.resource.org/public/rfc/html/rfc2245.html" />
<format octets="10533" type="XML" target="http://xml.resource.org/public/rfc/xml/rfc2245.xml" />
</reference>


<reference target2="reference.RFC.2246.xml" anchor="RFC2246">
<front>
<title>The TLS Protocol Version 1.0</title>
<author fullname="Tim Dierks" initials="T." surname="Dierks">
<organization>Certicom</organization>

<address>
<email>tdierks@certicom.com</email>
</address>
</author>

<author fullname="Christopher Allen" initials="C." surname="Allen">
<organization>Certicom</organization>

<address>
<email>callen@certicom.com</email>
</address>
</author>

<date year="1999" month="January" />

<abstract>
<t>This document specifies Version 1.0 of the Transport Layer Security (TLS) protocol. The TLS protocol provides communications privacy over the Internet. The protocol allows client/server applications to communicate in a way that is designed to prevent eavesdropping, tampering, or message forgery.</t>
</abstract>
</front>

<seriesInfo value="2246" name="RFC" />
<format octets="170401" type="TXT" target="ftp://ftp.isi.edu/in-notes/rfc2246.txt" />
</reference>


<reference target2="reference.RFC.2247.xml" anchor="RFC2247">
<front>
<title abbrev="Using Domains in LDAP/X.500">Using Domains in LDAP/X.500 Distinguished Names</title>
<author fullname="Steve Kille" initials="S." surname="Kille">
<organization>Isode Ltd.</organization>

<address>
<postal>
<street>The Dome</street>
<street>The Square</street>
<street>Richmond</street>
<street>Surrey</street>
<street>TW9 1DT</street>
<street>England</street>
</postal>

<phone>+44-181-332-9091</phone>
<email>S.Kille@ISODE.COM</email>
</address>
</author>

<author fullname="Mark Wahl" initials="M." surname="Wahl">
<organization>Critical Angle Inc.</organization>

<address>
<postal>
<street>4815 W. Braker Lane #502-385</street>
<street>Austin</street>
<street>TX 78759</street>
<country>USA</country>
</postal>

<phone>(1) 512 372 3160</phone>
<email>M.Wahl@critical-angle.com</email>
</address>
</author>

<author fullname="Al Grimstad" initials="A." surname="Grimstad">
<organization>AT&amp;T</organization>

<address>
<postal>
<street>Room 1C-429</street>
<street>101 Crawfords Corner Road</street>
<street>Holmdel</street>
<street>NJ 07733-3030</street>
<country>USA</country>
</postal>

<email>alg@att.com</email>
</address>
</author>

<author fullname="Rick Huber" initials="R." surname="Huber">
<organization>AT&amp;T</organization>

<address>
<postal>
<street>Room 1B-433</street>
<street>101 Crawfords Corner Road</street>
<street>Holmdel</street>
<street>NJ 07733-3030</street>
<country>USA</country>
</postal>

<email>rvh@att.com</email>
</address>
</author>

<author fullname="Sri Sataluri" initials="S." surname="Sataluri">
<organization>AT&amp;T</organization>

<address>
<postal>
<street>Room 4G-202</street>
<street>101 Crawfords Corner Road</street>
<street>Holmdel</street>
<street>NJ 07733-3030</street>
<country>USA</country>
</postal>

<email>sri@att.com</email>
</address>
</author>

<date year="1998" month="January" />
<area>Applications</area>
<keyword>ITU directory service protocol</keyword>
<keyword>lightweight directory access protocol</keyword>
</front>

<seriesInfo value="2247" name="RFC" />
<format octets="27320" type="HTML" target="http://xml.resource.org/public/rfc/html/rfc2247.html" />
<format octets="13157" type="XML" target="http://xml.resource.org/public/rfc/xml/rfc2247.xml" />
</reference>


<reference target2="reference.RFC.2248.xml" anchor="RFC2248">
<front>
<title abbrev="Network Services MIB">Network Services Monitoring MIB</title>
<author fullname="Ned Freed" initials="N." surname="Freed">
<organization>Innosoft International, Inc.</organization>

<address>
<postal>
<street>1050 Lakes Drive</street>
<street>West Covina</street>
<street>CA 91790</street>
<country>USA</country>
</postal>

<phone>+1 626 919 3600</phone>
<facsimile>+1 626 919 3614</facsimile>
<email>ned.freed@innosoft.com</email>
</address>
</author>

<author fullname="Steve Kille, MADMAN WG Chair" initials="S." surname="Kille">
<organization>ISODE Consortium</organization>

<address>
<postal>
<street>The Dome</street>
<street>The Square</street>
<street>Richmond TW9 1DT</street>
<country>UK</country>
</postal>

<phone>+44 181 332 9091</phone>
<email>S.Kille@isode.com</email>
</address>
</author>

<date year="1998" month="January" />
<area>Management</area>
<keyword>Management Information Base</keyword>
<keyword>monitor</keyword>
</front>

<seriesInfo value="2248" name="RFC" />
<format octets="47301" type="HTML" target="http://xml.resource.org/public/rfc/html/rfc2248.html" />
<format octets="33531" type="XML" target="http://xml.resource.org/public/rfc/xml/rfc2248.xml" />
</reference>


<reference target2="reference.RFC.2249.xml" anchor="RFC2249">
<front>
<title>Mail Monitoring MIB</title>
<author fullname="Ned Freed" initials="N." surname="Freed">
<organization>Innosoft International, Inc.</organization>

<address>
<postal>
<street>1050 Lakes Drive</street>
<street>West Covina</street>
<street>CA 91790</street>
<country>USA</country>
</postal>

<phone>+1 626 919 3600</phone>
<facsimile>+1 626 919 3614</facsimile>
<email>ned.freed@innosoft.com</email>
</address>
</author>

<author fullname="Steve Kille, MADMAN WG Chair" initials="S." surname="Kille">
<organization>ISODE Consortium</organization>

<address>
<postal>
<street>The Dome</street>
<street>The Square</street>
<street>Richmond TW9 1DT</street>
<country>UK</country>
</postal>

<phone>+44 181 332 9091</phone>
<email>S.Kille@isode.com</email>
</address>
</author>

<date year="1998" month="January" />
<area>Management</area>
<area>Applications</area>
<keyword>Management Information Base</keyword>
<keyword>mail</keyword>
<keyword>monitor</keyword>
</front>

<seriesInfo value="2249" name="RFC" />
<format octets="64882" type="HTML" target="http://xml.resource.org/public/rfc/html/rfc2249.html" />
<format octets="51466" type="XML" target="http://xml.resource.org/public/rfc/xml/rfc2249.xml" />
</reference>


<reference target2="reference.RFC.2250.xml" anchor="RFC2250">
<front>
<title abbrev="RTP Format MPEG1/MPEG2">RTP Payload Format for MPEG1/MPEG2 Video</title>
<author fullname="Don Hoffman" initials="D." surname="Hoffman">
<organization>Sun Microsystems, Inc.</organization>

<address>
<postal>
<street>Mail-stop UMPK14-305</street>
<street>2550 Garcia Avenue</street>
<street>Mountain View</street>
<street>California 94043-1100</street>
<country>USA</country>
</postal>

<phone>+1 503-297-1580</phone>
<email>don.hoffman@eng.sun.com</email>
</address>
</author>

<author fullname="Gerard Fernando" initials="G." surname="Fernando">
<organization>Sun Microsystems, Inc.</organization>

<address>
<postal>
<street>Mail-stop UMPK14-305</street>
<street>2550 Garcia Avenue</street>
<street>Mountain View</street>
<street>California 94043-1100</street>
<country>USA</country>
</postal>

<phone>+1 415-786-6373</phone>
<email>gerard.fernando@eng.sun.com</email>
</address>
</author>

<author fullname="Vivek Goyal" initials="V." surname="Goyal">
<organization>Precept Software, Inc.</organization>

<address>
<postal>
<street>1072 Arastradero Rd</street>
<street>Palo Alto</street>
<street>CA 94304</street>
<country>USA</country>
</postal>

<phone>+1 415-845-5200</phone>
<email>goyal@precept.com</email>
</address>
</author>

<author fullname="M. Reha Civanlar" initials="M.R." surname="Civanlar">
<organization>AT&amp;T Labs - Research</organization>

<address>
<postal>
<street>100 Schutlz Drive</street>
<street>3-213</street>
<street>Red Bank</street>
<street>NJ 07701-7033</street>
<country>USA</country>
</postal>

<phone>+1 732-345-3305</phone>
<email>civanlar@research.att.com</email>
</address>
</author>

<date year="1998" month="January" />
<area>Transport</area>
<keyword>encapsulate</keyword>
<keyword>motion picture experts group</keyword>
<keyword>multimedia</keyword>
<keyword>real-time transport protocol</keyword>
<keyword>video</keyword>

<abstract>
<t>
   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.
</t>

<t>
   This memo is a revision of RFC 2038, an Internet standards track
   protocol.  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.
</t>
</abstract>
</front>

<seriesInfo value="2250" name="RFC" />
<format octets="47987" type="HTML" target="http://xml.resource.org/public/rfc/html/rfc2250.html" />
<format octets="34057" type="XML" target="http://xml.resource.org/public/rfc/xml/rfc2250.xml" />
</reference>


<reference target2="reference.RFC.2251.xml" anchor="RFC2251">
<front>
<title abbrev="LDAPv3">Lightweight Directory Access Protocol (v3)</title>
<author fullname="Mark Wahl" initials="M." surname="Wahl">
<organization>Critical Angle Inc.</organization>

<address>
<postal>
<street>4815 W Braker Lane #502-385</street>
<street>Austin</street>
<street>TX 78759</street>
<country>USA</country>
</postal>

<phone>+1 512 372-3160</phone>
<email>M.Wahl@critical-angle.com</email>
</address>
</author>

<author fullname="Tim Howes" initials="T." surname="Howes">
<organization>Netscape Communications Corp.</organization>

<address>
<postal>
<street>501 E. Middlefield Rd.</street>
<street>MS MV068</street>
<street>Mountain View</street>
<street>CA 94043</street>
<country>USA</country>
</postal>

<phone>+1 650 937-3419</phone>
<email>howes@netscape.com</email>
</address>
</author>

<author fullname="Steve Kille" initials="S." surname="Kille">
<organization>Isode Limited</organization>

<address>
<postal>
<street>The Dome</street>
<street>The Square</street>
<street>Richmond</street>
<street>TW9 1DT</street>
<country>UK</country>
</postal>

<phone>+44-181-332-9091</phone>
<email>S.Kille@isode.com</email>
</address>
</author>

<date year="1997" month="December" />
<area>Applications</area>
<keyword>LDAP</keyword>
<keyword>ITU directory service protocol</keyword>
<keyword>directory</keyword>
<keyword>lightweight directory access protocol</keyword>

<note title="IESG Note">
<t>
This RFC contained boilerplate in this section which has been moved
to the RFC2223-compliant unnumbered section &quot;Status of this Memo.&quot;

<list>
<t>
   This document describes a directory access protocol that provides
   both read and update access.  Update access requires secure
   authentication, but this document does not mandate implementation of
   any satisfactory authentication mechanisms.
</t>

<t>
   In accordance with RFC 2026, section 4.4.1, this specification is
   being approved by IESG as a Proposed Standard despite this
   limitation, for the following reasons:

<list>
<t>
   a. to encourage implementation and interoperability testing of
      these protocols (with or without update access) before they
      are deployed, and
</t>

<t>
   b. to encourage deployment and use of these protocols in read-only
      applications.  (e.g. applications where LDAPv3 is used as
      a query language for directories which are updated by some
      secure mechanism other than LDAP), and
</t>

<t>
   c. to avoid delaying the advancement and deployment of other Internet
      standards-track protocols which require the ability to query, but
      not update, LDAPv3 directory servers.
</t>
</list>
</t>

<t>
   Readers are hereby warned that until mandatory authentication
   mechanisms are standardized, clients and servers written according to
   this specification which make use of update functionality are
   UNLIKELY TO INTEROPERATE, or MAY INTEROPERATE ONLY IF AUTHENTICATION
   IS REDUCED TO AN UNACCEPTABLY WEAK LEVEL.
</t>

<t>
   Implementors are hereby discouraged from deploying LDAPv3 clients or
   servers which implement the update functionality, until a Proposed
   Standard for mandatory authentication in LDAPv3 has been approved and
   published as an RFC.
</t>
</list>
</t>
</note>
</front>

<seriesInfo value="2251" name="RFC" />
<format octets="133146" type="HTML" target="http://xml.resource.org/public/rfc/html/rfc2251.html" />
<format octets="114375" type="XML" target="http://xml.resource.org/public/rfc/xml/rfc2251.xml" />
</reference>


<reference target2="reference.RFC.2252.xml" anchor="RFC2252">
<front>
<title abbrev="LADPv3 Attributes">Lightweight Directory Access Protocol (v3): Attribute Syntax Definitions</title>
<author fullname="Mark Wahl" initials="M." surname="Wahl">
<organization>Critical Angle Inc.</organization>

<address>
<postal>
<street>4815 West Braker Lane #502-385</street>
<street>Austin</street>
<street>TX 78759</street>
<country>USA</country>
</postal>

<phone>+1 512 372-3160</phone>
<email>M.Wahl@critical-angle.com</email>
</address>
</author>

<author fullname="Andy Coulbeck" initials="A." surname="Coulbeck">
<organization>Isode Inc.</organization>

<address>
<postal>
<street>9390 Research Blvd Suite 305</street>
<street>Austin</street>
<street>TX 78759</street>
<country>USA</country>
</postal>

<phone>+1 512 231-8993</phone>
<email>A.Coulbeck@isode.com</email>
</address>
</author>

<author fullname="Tim Howes" initials="T." surname="Howes">
<organization>Netscape Communications Corp.</organization>

<address>
<postal>
<street>501 E. Middlefield Rd</street>
<street>MS MV068</street>
<street>Mountain View</street>
<street>CA 94043</street>
<country>USA</country>
</postal>

<phone>+1 650 937-3419</phone>
<email>howes@netscape.com</email>
</address>
</author>

<author fullname="Steve Kille" initials="S." surname="Kille">
<organization>Isode Limited</organization>

<address>
<postal>
<street>The Dome</street>
<street>The Square</street>
<street>Richmond</street>
<street>TW9 1DT</street>
<country>UK</country>
</postal>

<phone>+44-181-332-9091</phone>
<email>S.Kille@isode.com</email>
</address>
</author>

<date year="1997" month="December" />
<area>Applications</area>
<keyword>LDAP</keyword>
<keyword>ITU directory service protocol</keyword>
<keyword>directory</keyword>
<keyword>lightweight directory access protocol</keyword>

<note title="IESG Note">
<t>
This RFC contained boilerplate in this section which has been moved
to the RFC2223-compliant unnumbered section &quot;Status of this Memo.&quot;
</t>

<t>
   This document describes a directory access protocol that provides
   both read and update access.  Update access requires secure
   authentication, but this document does not mandate implementation of
   any satisfactory authentication mechanisms.
</t>

<t>
   In accordance with RFC 2026, section 4.4.1, this specification is
   being approved by IESG as a Proposed Standard despite this
   limitation, for the following reasons:

<list>
<t>
   a. to encourage implementation and interoperability testing of
      these protocols (with or without update access) before they
      are deployed, and
</t>

<t>
   b. to encourage deployment and use of these protocols in read-only
      applications.  (e.g. applications where LDAPv3 is used as
      a query language for directories which are updated by some
      secure mechanism other than LDAP), and
</t>

<t>
   c. to avoid delaying the advancement and deployment of other Internet
      standards-track protocols which require the ability to query, but
      not update, LDAPv3 directory servers.
</t>
</list>
</t>

<t>
   Readers are hereby warned that until mandatory authentication
   mechanisms are standardized, clients and servers written according to
   this specification which make use of update functionality are
   UNLIKELY TO INTEROPERATE, or MAY INTEROPERATE ONLY IF AUTHENTICATION
   IS REDUCED TO AN UNACCEPTABLY WEAK LEVEL.
</t>

<t>
   Implementors are hereby discouraged from deploying LDAPv3 clients or
   servers which implement the update functionality, until a Proposed
   Standard for mandatory authentication in LDAPv3 has been approved and
   published as an RFC.
</t>
</note>
</front>

<seriesInfo value="2252" name="RFC" />
<format octets="89418" type="HTML" target="http://xml.resource.org/public/rfc/html/rfc2252.html" />
<format octets="71850" type="XML" target="http://xml.resource.org/public/rfc/xml/rfc2252.xml" />
</reference>


<reference target2="reference.RFC.2253.xml" anchor="RFC2253">
<front>
<title abbrev="LADPv3 Distinguished Names">Lightweight Directory Access Protocol (v3): UTF-8 String Representation of Distinguished Names</title>
<author fullname="Mark Wahl" initials="M." surname="Wahl">
<organization>Critical Angle Inc.</organization>

<address>
<postal>
<street>4815 W. Braker Lane #502-385</street>
<street>Austin</street>
<street>TX 78759</street>
<country>USA</country>
</postal>

<email>M.Wahl@critical-angle.com</email>
</address>
</author>

<author fullname="Steve Kille" initials="S." surname="Kille">
<organization>Isode Ltd.</organization>

<address>
<postal>
<street>The Dome</street>
<street>The Square</street>
<street>Richmond</street>
<street>Surrey</street>
<street>TW9 1DT</street>
<street>England</street>
</postal>

<phone>+44-181-332-9091</phone>
<email>S.Kille@ISODE.COM</email>
</address>
</author>

<author fullname="Tim Howes" initials="T." surname="Howes">
<organization>Netscape Communications Corp.</organization>

<address>
<postal>
<street>501 E. Middlefield Rd</street>
<street>MS MV068</street>
<street>Mountain View</street>
<street>CA 94043</street>
<country>USA</country>
</postal>

<phone>+1 650 937-3419</phone>
<email>howes@netscape.com</email>
</address>
</author>

<date year="1997" month="December" />
<area>Applications</area>
<keyword>LDAP</keyword>
<keyword>ITU abstract syntax notation one</keyword>
<keyword>ITU directory service protocol</keyword>
<keyword>UCS transformation format</keyword>
<keyword>directory</keyword>
<keyword>lightweight directory access protocol</keyword>

<abstract>
<t>
   This document describes a directory access protocol that provides
   both read and update access.  Update access requires secure
   authentication, but this document does not mandate implementation of
   any satisfactory authentication mechanisms.
</t>

<t>
   In accordance with RFC 2026, section 4.4.1, this specification is
   being approved by IESG as a Proposed Standard despite this
   limitation, for the following reasons:

<list>
<t>
   a. to encourage implementation and interoperability testing of
      these protocols (with or without update access) before they
      are deployed, and
</t>

<t>
   b. to encourage deployment and use of these protocols in read-only
      applications.  (e.g. applications where LDAPv3 is used as
      a query language for directories which are updated by some
      secure mechanism other than LDAP), and
</t>

<t>
   c. to avoid delaying the advancement and deployment of other Internet
      standards-track protocols which require the ability to query, but
      not update, LDAPv3 directory servers.
</t>
</list>
</t>

<t>
   Readers are hereby warned that until mandatory authentication
   mechanisms are standardized, clients and servers written according to
   this specification which make use of update functionality are
   UNLIKELY TO INTEROPERATE, or MAY INTEROPERATE ONLY IF AUTHENTICATION
   IS REDUCED TO AN UNACCEPTABLY WEAK LEVEL.
</t>

<t>
   Implementors are hereby discouraged from deploying LDAPv3 clients or
   servers which implement the update functionality, until a Proposed
   Standard for mandatory authentication in LDAPv3 has been approved and
   published as an RFC.
</t>

<t>
   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.
</t>

<t>
   The key words &quot;MUST&quot;, &quot;MUST NOT&quot;, &quot;REQUIRED&quot;, &quot;SHALL&quot;, &quot;SHALL NOT&quot;,
   &quot;SHOULD&quot;, &quot;SHOULD NOT&quot;, &quot;RECOMMENDED&quot;,  &quot;MAY&quot;, and &quot;OPTIONAL&quot; in this
   document are to be interpreted as described in RFC 2119 .
</t>
</abstract>

<note title="IESG Note">
<t>
   This document describes a directory access protocol that provides
   both read and update access.  Update access requires secure
   authentication, but this document does not mandate implementation of
   any satisfactory authentication mechanisms.
</t>

<t>
   In accordance with RFC 2026, section 4.4.1, this specification is
   being approved by IESG as a Proposed Standard despite this
   limitation, for the following reasons:
</t>

<t>
   a. to encourage implementation and interoperability testing of
      these protocols (with or without update access) before they
      are deployed, and

<list>
<t>
   b. to encourage deployment and use of these protocols in read-only
      applications.  (e.g. applications where LDAPv3 is used as
      a query language for directories which are updated by some
      secure mechanism other than LDAP), and
</t>

<t>
   c. to avoid delaying the advancement and deployment of other Internet
      standards-track protocols which require the ability to query, but
      not update, LDAPv3 directory servers.
</t>
</list>
</t>

<t>
   Readers are hereby warned that until mandatory authentication
   mechanisms are standardized, clients and servers written according to
   this specification which make use of update functionality are
   UNLIKELY TO INTEROPERATE, or MAY INTEROPERATE ONLY IF AUTHENTICATION
   IS REDUCED TO AN UNACCEPTABLY WEAK LEVEL.
</t>

<t>
   Implementors are hereby discouraged from deploying LDAPv3 clients or
   servers which implement the update functionality, until a Proposed
   Standard for mandatory authentication in LDAPv3 has been approved and
   published as an RFC.
</t>
</note>
</front>

<seriesInfo value="2253" name="RFC" />
<format octets="35492" type="HTML" target="http://xml.resource.org/public/rfc/html/rfc2253.html" />
<format octets="21696" type="XML" target="http://xml.resource.org/public/rfc/xml/rfc2253.xml" />
</reference>


<reference target2="reference.RFC.2254.xml" anchor="RFC2254">
<front>
<title abbrev="String Representation of LDAP">The String Representation of LDAP Search Filters</title>
<author fullname="Tim Howes" initials="T." surname="Howes">
<organization>Netscape Communications Corp.</organization>

<address>
<postal>
<street>501 E. Middlefield Road</street>
<street>Mountain View</street>
<street>CA 94043</street>
<country>USA</country>
</postal>

<phone>+1 415 937-3419</phone>
<email>howes@netscape.com</email>
</address>
</author>

<date year="1997" month="December" />
<area>Applications</area>
<keyword>LDAP</keyword>
<keyword>lightweight directory access protocol</keyword>

<note title="IESG Note">
<t>
This RFC contained boilerplate in this section which has been moved
to the RFC2223-compliant unnumbered section &quot;Status of this Memo.&quot;
</t>

<t>
   This document describes a directory access protocol that provides
   both read and update access.  Update access requires secure
   authentication, but this document does not mandate implementation of
   any satisfactory authentication mechanisms.
</t>

<t>
   In accordance with RFC 2026, section 4.4.1, this specification is
   being approved by IESG as a Proposed Standard despite this
   limitation, for the following reasons:

<list>
<t>
   a. to encourage implementation and interoperability testing of
      these protocols (with or without update access) before they
      are deployed, and
</t>

<t>
   b. to encourage deployment and use of these protocols in read-only
      applications.  (e.g. applications where LDAPv3 is used as
      a query language for directories which are updated by some
      secure mechanism other than LDAP), and
</t>

<t>
   c. to avoid delaying the advancement and deployment of other Internet
      standards-track protocols which require the ability to query, but
      not update, LDAPv3 directory servers.
</t>
</list>
</t>

<t>
   Readers are hereby warned that until mandatory authentication
   mechanisms are standardized, clients and servers written according to
   this specification which make use of update functionality are
   UNLIKELY TO INTEROPERATE, or MAY INTEROPERATE ONLY IF AUTHENTICATION
   IS REDUCED TO AN UNACCEPTABLY WEAK LEVEL.
</t>

<t>
   Implementors are hereby discouraged from deploying LDAPv3 clients or
   servers which implement the update functionality, until a Proposed
   Standard for mandatory authentication in LDAPv3 has been approved and
   published as an RFC.
</t>
</note>
</front>

<seriesInfo value="2254" name="RFC" />
<format octets="26297" type="HTML" target="http://xml.resource.org/public/rfc/html/rfc2254.html" />
<format octets="14524" type="XML" target="http://xml.resource.org/public/rfc/xml/rfc2254.xml" />
</reference>


<reference target2="reference.RFC.2255.xml" anchor="RFC2255">
<front>
<title abbrev="LDAP URL Format">The LDAP URL Format</title>
<author fullname="Tim Howes" initials="T." surname="Howes">
<organization>Netscape Communications Corp.</organization>

<address>
<postal>
<street>501 E. Middlefield Rd.</street>
<street>Mountain View</street>
<street>CA 94043</street>
<country>USA</country>
</postal>

<phone>+1 415 937-3419</phone>
<email>howes@netscape.com</email>
</address>
</author>

<author fullname="Mark Smith" initials="M." surname="Smith">
<organization>Netscape Communications Corp.</organization>

<address>
<postal>
<street>501 E. Middlefield Rd.</street>
<street>Mountain View</street>
<street>CA 94043</street>
<country>USA</country>
</postal>

<phone>+1 415 937-3477</phone>
<email>mcs@netscape.com</email>
</address>
</author>

<date year="1997" month="December" />
<area>Applications</area>
<keyword>LDAP</keyword>
<keyword>lightweight directory access protocol</keyword>
<keyword>uniform resource</keyword>

<note title="IESG Note">
<t>
This RFC contained boilerplate in this section which has been moved
to the RFC2223-compliant unnumbered section &quot;Status of this Memo.&quot;
</t>

<t>
   This document describes a directory access protocol that provides
   both read and update access.  Update access requires secure
   authentication, but this document does not mandate implementation of
   any satisfactory authentication mechanisms.
</t>

<t>
   In accordance with RFC 2026, section 4.4.1, this specification is
   being approved by IESG as a Proposed Standard despite this
   limitation, for the following reasons:

<list>
<t>
   a. to encourage implementation and interoperability testing of
      these protocols (with or without update access) before they
      are deployed, and
</t>

<t>
   b. to encourage deployment and use of these protocols in read-only
      applications.  (e.g. applications where LDAPv3 is used as
      a query language for directories which are updated by some
      secure mechanism other than LDAP), and
</t>

<t>
   c. to avoid delaying the advancement and deployment of other Internet
      standards-track protocols which require the ability to query, but
      not update, LDAPv3 directory servers.
</t>
</list>
</t>

<t>
   Readers are hereby warned that until mandatory authentication
   mechanisms are standardized, clients and servers written according to
   this specification which make use of update functionality are
   UNLIKELY TO INTEROPERATE, or MAY INTEROPERATE ONLY IF AUTHENTICATION
   IS REDUCED TO AN UNACCEPTABLY WEAK LEVEL.
</t>

<t>
   Implementors are hereby discouraged from deploying LDAPv3 clients or
   servers which implement the update functionality, until a Proposed
   Standard for mandatory authentication in LDAPv3 has been approved and
   published as an RFC.
</t>
</note>
</front>

<seriesInfo value="2255" name="RFC" />
<format octets="34641" type="HTML" target="http://xml.resource.org/public/rfc/html/rfc2255.html" />
<format octets="21789" type="XML" target="http://xml.resource.org/public/rfc/xml/rfc2255.xml" />
</reference>


<reference target2="reference.RFC.2256.xml" anchor="RFC2256">
<front>
<title abbrev="LDAPv3 Schema">A Summary of the X.500(96) User Schema for use with LDAPv3</title>
<author fullname="Mark Wahl" initials="M." surname="Wahl">
<organization>Critical Angle Inc.</organization>

<address>
<postal>
<street>4815 West Braker Lane #502-385</street>
<street>Austin</street>
<street>TX 78759</street>
<country>USA</country>
</postal>

<phone>+1 512 372 3160</phone>
<email>M.Wahl@critical-angle.com</email>
</address>
</author>

<date year="1997" month="December" />
<area>Applications</area>
<keyword>ITU directory service protocol</keyword>
<keyword>lightweight directory access protocol</keyword>
<keyword>summary</keyword>

<note title="IESG Note">
<t>
This RFC contained boilerplate in this section which has been moved
to the RFC2223-compliant unnumbered section &quot;Status of this Memo.&quot;
</t>

<t>
   This document describes a directory access protocol that provides
   both read and update access.  Update access requires secure
   authentication, but this document does not mandate implementation of
   any satisfactory authentication mechanisms.
</t>

<t>
   In accordance with RFC 2026, section 4.4.1, this specification is
   being approved by IESG as a Proposed Standard despite this
   limitation, for the following reasons:

<list>
<t>
   a. to encourage implementation and interoperability testing of
      these protocols (with or without update access) before they
      are deployed, and
</t>

<t>
   b. to encourage deployment and use of these protocols in read-only
      applications.  (e.g. applications where LDAPv3 is used as
      a query language for directories which are updated by some
      secure mechanism other than LDAP), and
</t>

<t>
   c. to avoid delaying the advancement and deployment of other Internet
      standards-track protocols which require the ability to query, but
      not update, LDAPv3 directory servers.
</t>
</list>
</t>

<t>
   Readers are hereby warned that until mandatory authentication
   mechanisms are standardized, clients and servers written according to
   this specification which make use of update functionality are
   UNLIKELY TO INTEROPERATE, or MAY INTEROPERATE ONLY IF AUTHENTICATION
   IS REDUCED TO AN UNACCEPTABLY WEAK LEVEL.
</t>

<t>
   Implementors are hereby discouraged from deploying LDAPv3 clients or
   servers which implement the update functionality, until a Proposed
   Standard for mandatory authentication in LDAPv3 has been approved and
   published as an RFC.
</t>
</note>
</front>

<seriesInfo value="2256" name="RFC" />
<format octets="57655" type="HTML" target="http://xml.resource.org/public/rfc/html/rfc2256.html" />
<format octets="42028" type="XML" target="http://xml.resource.org/public/rfc/xml/rfc2256.xml" />
</reference>


<reference target2="reference.RFC.2257.xml" anchor="RFC2257">
<front>
<title abbrev="AgentX">Agent Extensibility (AgentX) Protocol Version 1</title>
<author fullname="Mike Daniele" initials="M." surname="Daniele">
<organization>Digital Equipment Corporation</organization>

<address>
<postal>
<street>110 Spit Brook Rd</street>
<street>Nashua</street>
<street>NH 03062</street>
</postal>

<phone>+1-603-881-1423</phone>
<email>daniele@zk3.dec.com</email>
</address>
</author>

<author fullname="Bert Wijnen" initials="B." surname="Wijnen">
<organization>IBM Professional Services</organization>

<address>
<postal>
<street>Watsonweg 2</street>
<street>1423 ND Uithoorn</street>
<street>The</street>
<country>Netherlands</country>
</postal>

<phone>+31-79-322-8316</phone>
<email>wijnen@vnet.ibm.com</email>
</address>
</author>

<date year="1998" month="January" />
<area>Management</area>
<keyword>agent</keyword>
<keyword>simple network management protocol</keyword>
</front>

<seriesInfo value="2257" name="RFC" />
<format octets="197868" type="HTML" target="http://xml.resource.org/public/rfc/html/rfc2257.html" />
<format octets="175215" type="XML" target="http://xml.resource.org/public/rfc/xml/rfc2257.xml" />
</reference>


<reference target2="reference.RFC.2258.xml" anchor="RFC2258">
<front>
<title>Internet Nomenclator Project</title>
<author fullname="Joann J. Ordille" initials="J.J." surname="Ordille">
<organization>Bell Labs, Lucent Technologies</organization>

<address>
<postal>
<street>Computing Sciences Research Center</street>
<street>700 Mountain Avenue</street>
<street>Rm 2C-301</street>
<street>Murray Hill</street>
<street>NJ 07974</street>
<country>USA</country>
</postal>

<email>joann@bell-labs.com</email>
</address>
</author>

<date year="1998" month="January" />
<area>Applications</area>
<keyword>CCSO</keyword>

<abstract>
<t>
   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.
</t>

<t>
   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.
</t>
</abstract>
</front>

<seriesInfo value="2258" name="RFC" />
<format octets="46511" type="HTML" target="http://xml.resource.org/public/rfc/html/rfc2258.html" />
<format octets="35813" type="XML" target="http://xml.resource.org/public/rfc/xml/rfc2258.xml" />
</reference>


<reference target2="reference.RFC.2259.xml" anchor="RFC2259">
<front>
<title abbrev="SNQP">Simple Nomenclator Query Protocol (SNQP)</title>
<author fullname="Jim Elliott" initials="J." surname="Elliott">
<organization>Epic Systems Corporation</organization>

<address>
<postal>
<street>5301 Tokay Boulevard</street>
<street>Madison</street>
<street>WI 53711</street>
<country>USA</country>
</postal>

<email>jim@apocalypse.org</email>
</address>
</author>

<author fullname="Joann J. Ordille" initials="J.J." surname="Ordille">
<organization>Bell Labs, Lucent Technologies</organization>

<address>
<postal>
<street>Computing Sciences Research Center</street>
<street>700 Mountain Avenue</street>
<street>Rm 2C-301</street>
<street>Murray Hill</street>
<street>NJ 07974</street>
<country>USA</country>
</postal>

<email>joann@bell-labs.com</email>
</address>
</author>

<date year="1998" month="January" />
<area>Applications</area>
<keyword>SNQP</keyword>

<abstract>
<t>
   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.
</t>

<t>
   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.
</t>
</abstract>
</front>

<seriesInfo value="2259" name="RFC" />
<format octets="70079" type="HTML" target="http://xml.resource.org/public/rfc/html/rfc2259.html" />
<format octets="59849" type="XML" target="http://xml.resource.org/public/rfc/xml/rfc2259.xml" />
</reference>


<reference target2="reference.RFC.2260.xml" anchor="RFC2260">
<front>
<title abbrev="Multihoming">Scalable Support for Multi-homed Multi-provider Connectivity</title>
<author fullname="Tony Bates" initials="T." surname="Bates">
<organization>Cisco Systems, Inc.</organization>

<address>
<postal>
<street>170 West Tasman Drive</street>
<street>San Jose</street>
<street>CA 95134</street>
</postal>

<email>tbates@cisco.com</email>
</address>
</author>

<author fullname="Yakov Rekhter" initials="Y." surname="Rekhter">
<organization>Cisco Systems, Inc.</organization>

<address>
<postal>
<street>170 West Tasman Drive</street>
<street>San Jose</street>
<street>CA 95134</street>
</postal>

<email>yakov@cisco.com</email>
</address>
</author>

<date year="1998" month="January" />
<area>Operations</area>
<keyword>multihome</keyword>
<keyword>routing</keyword>
</front>

<seriesInfo value="2260" name="RFC" />
<format octets="37933" type="HTML" target="http://xml.resource.org/public/rfc/html/rfc2260.html" />
<format octets="26550" type="XML" target="http://xml.resource.org/public/rfc/xml/rfc2260.xml" />
</reference>


<reference target2="reference.RFC.2261.xml" anchor="RFC2261">
<front>
<title abbrev="SNMP Frameworks">An Architecture for Describing SNMP Management Frameworks</title>
<author fullname="Dave Harrington" initials="D." surname="Harrington">
<organization>Cabletron Systems, Inc</organization>

<address>
<postal>
<street>Post Office Box 5005</street>
<street>Mail Stop: Durham</street>
<street>35 Industrial Way</street>
<street>Rochester</street>
<street>NH 03867-5005</street>
<country>USA</country>
</postal>

<phone>+1 603-337-7357</phone>
<email>dbh@ctron.com</email>
</address>
</author>

<author fullname="Randy Presuhn" initials="R." surname="Presuhn">
<organization>BMC Software, Inc.</organization>

<address>
<postal>
<street>1190 Saratoga Avenue</street>
<street>Suite 130</street>
<street>San Jose</street>
<street>CA 95129</street>
<country>USA</country>
</postal>

<phone>+1 408-556-0720</phone>
<email>rpresuhn@bmc.com</email>
</address>
</author>

<author fullname="Bert Wijnen" initials="B." surname="Wijnen">
<organization>IBM T.J. Watson Research</organization>

<address>
<postal>
<street>Schagen 33</street>
<street>3461 GL Linschoten</street>
<country>Netherlands</country>
</postal>

<phone>+31 348-432-794</phone>
<email>wijnen@vnet.ibm.com</email>
</address>
</author>

<date year="1998" month="January" />
<area>Management</area>
<keyword>SNMP</keyword>
<keyword>security</keyword>
<keyword>simple network management protocol</keyword>

<abstract>
<t>
   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.
</t>
</abstract>
</front>

<seriesInfo value="2261" name="RFC" />
<format octets="143652" type="HTML" target="http://xml.resource.org/public/rfc/html/rfc2261.html" />
<format octets="125401" type="XML" target="http://xml.resource.org/public/rfc/xml/rfc2261.xml" />
</reference>


<reference target2="reference.RFC.2262.xml" anchor="RFC2262">
<front>
<title abbrev="SNMP Message Processing">Message Processing and Dispatching for the Simple Network Management Protocol (SNMP)</title>
<author fullname="Jeffrey Case" initials="J." surname="Case">
<organization>SNMP Research, Inc.</organization>

<address>
<postal>
<street>3001 Kimberlin Heights Road</street>
<street>Knoxville</street>
<street>TN 37920-9716</street>
<country>USA</country>
</postal>

<phone>+1 423-573-1434</phone>
<email>case@snmp.com</email>
</address>
</author>

<author fullname="Dave Harrington" initials="D." surname="Harrington">
<organization>Cabletron Systems, Inc</organization>

<address>
<postal>
<street>Post Office Box 5005</street>
<street>Mail Stop: Durham</street>
<street>35 Industrial Way</street>
<street>Rochester</street>
<street>NH 03867-5005</street>
<country>USA</country>
</postal>

<phone>+1 603-337-7357</phone>
<email>dbh@ctron.com</email>
</address>
</author>

<author fullname="Randy Presuhn" initials="R." surname="Presuhn">
<organization>BMC Software, Inc.</organization>

<address>
<postal>
<street>1190 Saratoga Avenue</street>
<street>Suite 130</street>
<street>San Jose</street>
<street>CA 95129</street>
<country>USA</country>
</postal>

<phone>+1 408-556-0720</phone>
<email>rpresuhn@bmc.com</email>
</address>
</author>

<author fullname="Bert Wijnen" initials="B." surname="Wijnen">
<organization>IBM T. J. Watson Research</organization>

<address>
<postal>
<street>Schagen 33</street>
<street>3461 GL Linschoten</street>
<country>Netherlands</country>
</postal>

<phone>+31 348-432-794</phone>
<email>wijnen@vnet.ibm.com</email>
</address>
</author>

<date year="1998" month="January" />
<area>Management</area>
<keyword>network management</keyword>
<keyword>simple network management protocol</keyword>
<keyword>simple network management protocol version 3</keyword>

<abstract>
<t>
   This document describes the Message Processing and Dispatching for
   SNMP messages within the SNMP architecture .  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.
</t>
</abstract>
</front>

<seriesInfo value="2262" name="RFC" />
<format octets="107867" type="HTML" target="http://xml.resource.org/public/rfc/html/rfc2262.html" />
<format octets="88640" type="XML" target="http://xml.resource.org/public/rfc/xml/rfc2262.xml" />
</reference>


<reference target2="reference.RFC.2263.xml" anchor="RFC2263">
<front>
<title>SNMPv3 Applications</title>
<author fullname="David B. Levi" initials="D.B." surname="Levi">
<organization>SNMP Research, Inc.</organization>

<address>
<postal>
<street>3001 Kimberlin Heights Road</street>
<street>Knoxville</street>
<street>TN 37920-9716</street>
<street>U.S.A.</street>
</postal>

<phone>+1 423 573 1434</phone>
<email>levi@snmp.com</email>
</address>
</author>

<author fullname="Paul Meyer" initials="P." surname="Meyer">
<organization>Secure Computing Corporation</organization>

<address>
<postal>
<street>2675 Long Lake Road</street>
<street>Roseville</street>
<street>MN 55113</street>
<street>U.S.A.</street>
</postal>

<phone>+1 612 628 1592</phone>
<email>paul_meyer@securecomputing.com</email>
</address>
</author>

<author fullname="Bob Stewart" initials="B." surname="Stewart">
<organization>Cisco Systems, Inc.</organization>

<address>
<postal>
<street>170 West Tasman Drive</street>
<street>San Jose</street>
<street>CA 95134-1706</street>
<street>U.S.A.</street>
</postal>

<phone>+1 603 654 6923</phone>
<email>bstewart@cisco.com</email>
</address>
</author>

<date year="1998" month="January" />
<area>Management</area>
<keyword>SNMPv3</keyword>
<keyword>proxy</keyword>
<keyword>simple network management protocol</keyword>
<keyword>simple network management protocol version 3</keyword>

<abstract>
<t>
   This memo describes five types of SNMP applications which make use of
   an SNMP engine as described in [RFC2261].  The types of application
   described are Command Generators, Command Responders, Notification
   Originators, Notification Receivers, and Proxy Forwarders.
</t>

<t>
   This memo also defines MIB modules for specifying targets of
   management operations, for notification filtering, and for proxy
   forwarding.
</t>
</abstract>
</front>

<seriesInfo value="2263" name="RFC" />
<format octets="146508" type="HTML" target="http://xml.resource.org/public/rfc/html/rfc2263.html" />
<format octets="130593" type="XML" target="http://xml.resource.org/public/rfc/xml/rfc2263.xml" />
</reference>


<reference target2="reference.RFC.2264.xml" anchor="RFC2264">
<front>
<title abbrev="USM for SNMPv3">User-based Security Model (USM) for version 3 of the Simple Network Management Protocol (SNMPv3)</title>
<author fullname="Uri Blumenthal" initials="U." surname="Blumenthal">
<organization>IBM T. J. Watson Research</organization>

<address>
<postal>
<street>30 Saw Mill River Pkwy</street>
<city>Hawthorne</city>
<region>NY</region>
<code>10532</code>
<country>US</country>
</postal>

<phone>+1 914 784 7064</phone>
<email>uri@watson.ibm.com</email>
</address>
</author>

<author fullname="Bert Wijnen" initials="B." surname="Wijnen">
<organization>IBM T. J. Watson Research</organization>

<address>
<postal>
<street>Schagen 33</street>
<street>3461 GL Linschoten</street>
<country>NL</country>
</postal>

<phone>+31 34 8432794</phone>
<email>wijnen@vnet.ibm.com</email>
</address>
</author>

<date year="1998" month="January" />

<abstract>
<t>This document describes the User-based Security Model (USM) for SNMP version 3 for use in the SNMP architecture. 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.</t>
</abstract>
</front>

<seriesInfo value="2264" name="RFC" />
</reference>


<reference target2="reference.RFC.2265.xml" anchor="RFC2265">
<front>
<title abbrev="VACM for SNMPv3">View-based Access Control Model (VACM) for the Simple Network Management Protocol (SNMP)</title>
<author fullname="Bert Wijnen" initials="B." surname="Wijnen">
<organization>IBM, T. J. Watson Research</organization>

<address>
<postal>
<street>Schagen 33</street>
<street>3461 GL Linschoten</street>
<country>NL</country>
</postal>

<phone>+31 34 8432794</phone>
<email>wijnen@vnet.ibm.com</email>
</address>
</author>

<author fullname="Randy Presuhn" initials="R." surname="Presuhn">
<organization>BMC Software, Inc</organization>

<address>
<postal>
<street>1190 Saratoga Avenue</street>
<street>Suite 130</street>
<city>San Jose</city>
<region>CA</region>
<code>95129-3433</code>
<country>US</country>
</postal>

<phone>+1 408 556 0720</phone>
<email>rpresuhn@bmc.com</email>
</address>
</author>

<author fullname="Keith McCloghrie" initials="K." surname="McCloghrie">
<organization>Cisco Systems, Inc.</organization>

<address>
<postal>
<street>170 West Tasman Drive</street>
<city>San Jose</city>
<region>CA</region>
<code>95134-1706</code>
<country>US</country>
</postal>

<phone>+1 408 526 5260</phone>
<email>kzm@cisco.com</email>
</address>
</author>

<date year="1998" month="January" />

<abstract>
<t>This document describes the View-based Access Control Model for use in the SNMP architecture. 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.</t>
</abstract>
</front>

<seriesInfo value="2265" name="RFC" />
</reference>


<reference target2="reference.RFC.2266.xml" anchor="RFC2266">
<front>
<title abbrev="Repeater MIB">Definitions of Managed Objects for IEEE 802.12 Repeater Devices</title>
<author fullname="John Flick" initials="J." surname="Flick">
<organization>Hewlett Packard Company</organization>

<address>
<postal>
<street>8000 Foothills Blvd. M/S 5556</street>
<street>Roseville</street>
<street>CA 95747-5556</street>
</postal>

<phone>+1 916 785 4018</phone>
<email>johnf@hprnd.rose.hp.com</email>
</address>
</author>

<date year="1998" month="January" />
<area>Management</area>
<keyword>802.12</keyword>
<keyword>Institute of Electrical and Electronics Engineers</keyword>
<keyword>Management Information Base</keyword>
<keyword>managed object</keyword>

<abstract>
<t>
   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 network repeaters
   based on IEEE 802.12.
</t>
</abstract>
</front>

<seriesInfo value="2266" name="RFC" />
<format octets="141289" type="HTML" target="http://xml.resource.org/public/rfc/html/rfc2266.html" />
<format octets="129018" type="XML" target="http://xml.resource.org/public/rfc/xml/rfc2266.xml" />
</reference>


<reference target2="reference.RFC.2267.xml" anchor="RFC2267">
<front>
<title abbrev="Network Ingress Filtering">Network Ingress Filtering: Defeating Denial of Service Attacks which employ IP Source Address Spoofing</title>
<author fullname="Paul Ferguson" initials="P." surname="Ferguson">
<organization>cisco Systems, Inc.</organization>

<address>
<postal>
<street>400 Herndon Parkway</street>
<street>Herndon</street>
<street>VA  USA 20170</street>
</postal>

<email>ferguson@cisco.com</email>
</address>
</author>

<author fullname="Daniel Senie" initials="D." surname="Senie">
<organization>BlazeNet, Inc.</organization>

<address>
<postal>
<street>4 Mechanic Street</street>
<street>Natick</street>
<street>MA  USA 01760</street>
</postal>

<email>dts@senie.com</email>
</address>
</author>

<date year="1998" month="January" />
<area>Security</area>
<keyword>attack</keyword>

<abstract>
<t>
   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 &apos;behind&apos; an Internet Service Provider&apos;s (ISP) aggregation point.
</t>
</abstract>
</front>

<seriesInfo value="2267" name="RFC" />
<format octets="32307" type="HTML" target="http://xml.resource.org/public/rfc/html/rfc2267.html" />
<format octets="21087" type="XML" target="http://xml.resource.org/public/rfc/xml/rfc2267.xml" />
</reference>


<reference target2="reference.RFC.2268.xml" anchor="RFC2268">
<front>
<title abbrev="RC2(r) Encryption Algorithm">A Description of the RC2(r) Encryption Algorithm</title>
<author fullname="Ron Rivest" initials="R." surname="Rivest">
<organization>RSA Laboratories</organization>

<address>
<postal>
<street>100 Marine Parkway</street>
<street>#500</street>
<street>Redwood City</street>
<street>CA  94065</street>
<country>USA</country>
</postal>

<phone>(650) 595-7703</phone>
<email>rsa-labs@rsa.com</email>
</address>
</author>

<date year="1998" month="March" />
<area>Security</area>
<keyword>Rivest variable key-size block cipher</keyword>
<keyword>encryption</keyword>
</front>

<seriesInfo value="2268" name="RFC" />
<format octets="28815" type="HTML" target="http://xml.resource.org/public/rfc/html/rfc2268.html" />
<format octets="18979" type="XML" target="http://xml.resource.org/public/rfc/xml/rfc2268.xml" />
</reference>


<reference target2="reference.RFC.2269.xml" anchor="RFC2269">
<front>
<title abbrev="MARS Model in non-ATM NBMA Networks">Using the MARS Model in non-ATM NBMA Networks</title>
<author fullname="Grenville Armitage" initials="G." surname="Armitage">
<organization>Bell Laboratories, Lucent Technologies.</organization>

<address>
<postal>
<street>101 Crawfords Corner Rd</street>
<street>Holmdel</street>
<street>NJ</street>
<street>07733</street>
<country>USA</country>
</postal>

<email>gja@lucent.com</email>
</address>
</author>

<date year="1998" month="January" />
<area>Internet</area>
<keyword>asynchronous transfer mode</keyword>
<keyword>non-broadcast multiple access</keyword>

<abstract>
<t>
   Initially developed for IP over ATM, the RFC 2022 (MARS) model is
   also applicable to other NBMA networks that provide the equivalent of
   switched, point to multipoint connections. This short document is
   intended to state the obvious equivalences, and explain the less
   obvious implications. No changes to the MARS model per se are
   suggested or required. RFC 2022 is not required over NBMA networks
   that offer Ethernet-like group addressing functionality.
</t>
</abstract>
</front>

<seriesInfo value="2269" name="RFC" />
<format octets="22171" type="HTML" target="http://xml.resource.org/public/rfc/html/rfc2269.html" />
<format octets="12393" type="XML" target="http://xml.resource.org/public/rfc/xml/rfc2269.xml" />
</reference>


<reference target2="reference.RFC.2270.xml" anchor="RFC2270">
<front>
<title abbrev="Dedicated AS">Using a Dedicated AS for Sites  Homed to a Single Provider</title>
<author fullname="John Stewart" initials="J." surname="Stewart">
<organization>USC/ISI</organization>

<address>
<postal>
<street>4350 North Fairfax Drive</street>
<street>Suite 620</street>
<street>Arlington</street>
<street>VA  22203</street>
</postal>

<email>jstewart@isi.edu</email>
</address>
</author>

<author fullname="Tony Bates" initials="T." surname="Bates">
<organization>Cisco Systems, Inc.</organization>

<address>
<postal>
<street>170 West Tasman Drive</street>
<street>San Jose</street>
<street>CA 95134</street>
</postal>

<email>tbates@cisco.com</email>
</address>
</author>

<author fullname="Ravi Chandra" initials="R." surname="Chandra">
<organization>Cisco Systems, Inc.</organization>

<address>
<postal>
<street>170 West Tasman Drive</street>
<street>San Jose</street>
<street>CA 95134</street>
</postal>

<email>rchandra@cisco.com</email>
</address>
</author>

<author fullname="Enke Chen" initials="E." surname="Chen">
<organization>Cisco Systems, Inc.</organization>

<address>
<postal>
<street>170 West Tasman Drive</street>
<street>San Jose</street>
<street>CA 95134</street>
</postal>

<email>enkechen@cisco.com</email>
</address>
</author>

<date year="1998" month="January" />
<area>Operations</area>
<keyword>Autonomous System</keyword>
<keyword>BGP4</keyword>

<abstract>
<t>
   With the increased growth of the Internet, the number of customers
   using BGP4 has grown significantly. RFC1930 outlines a set of
   guidelines for when one needs and should use an AS. However, the
   customer and service provider (ISP) are left with a problem as a
   result of this in that while there is no need for an allocated AS
   under the guidelines, certain conditions make the use of BGP4 a very
   pragmatic and perhaps only way to connect a customer homed to a
   single ISP.  This paper proposes a solution to this problem in line
   with recommendations set forth in RFC1930.
</t>
</abstract>
</front>

<seriesInfo value="2270" name="RFC" />
<format octets="25375" type="HTML" target="http://xml.resource.org/public/rfc/html/rfc2270.html" />
<format octets="13272" type="XML" target="http://xml.resource.org/public/rfc/xml/rfc2270.xml" />
</reference>


<reference target2="reference.RFC.2271.xml" anchor="RFC2271">
<front>
<title abbrev="SNMPv3 Architecture">An Architecture for Describing SNMP Management Frameworks</title>
<author fullname="Dave Harrington" initials="D." surname="Harrington">
<organization>Cabletron Systems, Inc</organization>

<address>
<postal>
<street>Post Office Box 5005</street>
<street>Mail Stop: Durham</street>
<street>35 Industrial Way</street>
<street>Rochester</street>
<street>NH 03867-5005</street>
<country>USA</country>
</postal>

<phone>+1 603-337-7357</phone>
<email>dbh@ctron.com</email>
</address>
</author>

<author fullname="Randy Presuhn" initials="R." surname="Presuhn">
<organization>BMC Software, Inc.</organization>

<address>
<postal>
<street>1190 Saratoga Avenue</street>
<street>Suite 130</street>
<street>San Jose</street>
<street>CA 95129</street>
<country>USA</country>
</postal>

<phone>+1 408-556-0720</phone>
<email>rpresuhn@bmc.com</email>
</address>
</author>

<author fullname="Bert Wijnen" initials="B." surname="Wijnen">
<organization>IBM T.J. Watson Research</organization>

<address>
<postal>
<street>Schagen 33</street>
<street>3461 GL Linschoten</street>
<country>Netherlands</country>
</postal>

<phone>+31 348-432-794</phone>
<email>wijnen@vnet.ibm.com</email>
</address>
</author>

<date year="1998" month="January" />
<area>Management</area>
<keyword>security</keyword>
<keyword>simple network management protocol</keyword>

<abstract>
<t>
   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.
</t>
</abstract>
</front>

<seriesInfo value="2271" name="RFC" />
<format octets="143566" type="HTML" target="http://xml.resource.org/public/rfc/html/rfc2271.html" />
<format octets="125230" type="XML" target="http://xml.resource.org/public/rfc/xml/rfc2271.xml" />
</reference>


<reference target2="reference.RFC.2272.xml" anchor="RFC2272">
<front>
<title abbrev="SNMPv3 Management Protocol">Message Processing and Dispatching for the Simple Network Management Protocol (SNMP)</title>
<author fullname="Jeffrey Case" initials="J." surname="Case">
<organization>SNMP Research, Inc.</organization>

<address>
<postal>
<street>3001 Kimberlin Heights Road</street>
<street>Knoxville</street>
<street>TN 37920-9716</street>
<country>USA</country>
</postal>

<phone>+1 423-573-1434</phone>
<email>case@snmp.com</email>
</address>
</author>

<author fullname="Dave Harrington" initials="D." surname="Harrington">
<organization>Cabletron Systems, Inc</organization>

<address>
<postal>
<street>Post Office Box 5005</street>
<street>Mail Stop: Durham</street>
<street>35 Industrial Way</street>
<street>Rochester</street>
<street>NH 03867-5005</street>
<country>USA</country>
</postal>

<phone>+1 603-337-7357</phone>
<email>dbh@ctron.com</email>
</address>
</author>

<author fullname="Randy Presuhn" initials="R." surname="Presuhn">
<organization>BMC Software, Inc.</organization>

<address>
<postal>
<street>1190 Saratoga Avenue</street>
<street>Suite 130</street>
<street>San Jose</street>
<street>CA 95129</street>
<country>USA</country>
</postal>

<phone>+1 408-556-0720</phone>
<email>rpresuhn@bmc.com</email>
</address>
</author>

<author fullname="Bert Wijnen" initials="B." surname="Wijnen">
<organization>IBM T. J. Watson Research</organization>

<address>
<postal>
<street>Schagen 33</street>
<street>3461 GL Linschoten</street>
<country>Netherlands</country>
</postal>

<phone>+31 348-432-794</phone>
<email>wijnen@vnet.ibm.com</email>
</address>
</author>

<date year="1998" month="January" />
<area>Management</area>
<keyword>network management</keyword>
<keyword>simple network management protocol</keyword>
<keyword>simple network management protocol version 3</keyword>

<abstract>
<t>
   This document describes the Message Processing and Dispatching for
   SNMP messages within the SNMP architecture .  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.
</t>
</abstract>
</front>

<seriesInfo value="2272" name="RFC" />
<format octets="107908" type="HTML" target="http://xml.resource.org/public/rfc/html/rfc2272.html" />
<format octets="88696" type="XML" target="http://xml.resource.org/public/rfc/xml/rfc2272.xml" />
</reference>


<reference target2="reference.RFC.2273.xml" anchor="RFC2273">
<front>
<title>SNMPv3 Applications</title>
<author fullname="David B. Levi" initials="D.B." surname="Levi">
<organization>SNMP Research, Inc.</organization>

<address>
<postal>
<street>3001 Kimberlin Heights Road</street>
<street>Knoxville</street>
<street>TN 37920-9716</street>
<street>U.S.A.</street>
</postal>

<phone>+1 423 573 1434</phone>
<email>levi@snmp.com</email>
</address>
</author>

<author fullname="Paul Meyer" initials="P." surname="Meyer">
<organization>Secure Computing Corporation</organization>

<address>
<postal>
<street>2675 Long Lake Road</street>
<street>Roseville</street>
<street>MN 55113</street>
<street>U.S.A.</street>
</postal>

<phone>+1 612 628 1592</phone>
<email>paul_meyer@securecomputing.com</email>
</address>
</author>

<author fullname="Bob Stewart" initials="B." surname="Stewart">
<organization>Cisco Systems, Inc.</organization>

<address>
<postal>
<street>170 West Tasman Drive</street>
<street>San Jose</street>
<street>CA 95134-1706</street>
<street>U.S.A.</street>
</postal>

<phone>+1 603 654 6923</phone>
<email>bstewart@cisco.com</email>
</address>
</author>

<date year="1998" month="January" />
<area>Management</area>
<keyword>proxy</keyword>
<keyword>simple network management protocol</keyword>
<keyword>simple network management protocol version 3</keyword>

<abstract>
<t>
   This memo describes five types of SNMP applications which make use of
   an SNMP engine as described in [RFC2271].  The types of application
   described are Command Generators, Command Responders, Notification
   Originators, Notification Receivers, and Proxy Forwarders.
</t>

<t>
   This memo also defines MIB modules for specifying targets of
   management operations, for notification filtering, and for proxy
   forwarding.
</t>
</abstract>
</front>

<seriesInfo value="2273" name="RFC" />
<format octets="151826" type="HTML" target="http://xml.resource.org/public/rfc/html/rfc2273.html" />
<format octets="135414" type="XML" target="http://xml.resource.org/public/rfc/xml/rfc2273.xml" />
</reference>


<reference target2="reference.RFC.2274.xml" anchor="RFC2274">
<front>
<title abbrev="USM for SNMPv3">User-based Security Model (USM) for version 3 of the Simple Network Management Protocol (SNMPv3)</title>
<author fullname="Uri Blumenthal" initials="U." surname="Blumenthal">
<organization>IBM T. J. Watson Research</organization>

<address>
<postal>
<street>30 Saw Mill River Pkwy</street>
<street>Hawthorne</street>
<street>NY 10532</street>
<country>USA</country>
</postal>

<phone>+31-348-432-794</phone>
<email>wijnen@vnet.ibm.com</email>
<uri>@watson.ibm.com</uri>
</address>
</author>

<date year="1998" month="January" />
<area>Management</area>
<keyword>network management</keyword>
<keyword>security</keyword>
<keyword>simple network management protocol</keyword>
<keyword>simple network management protocol version 3</keyword>

<abstract>
<t>
   This document describes the User-based Security Model (USM) for SNMP
   version 3 for use in the SNMP architecture .  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.
</t>
</abstract>
</front>

<seriesInfo value="2274" name="RFC" />
<format octets="189915" type="HTML" target="http://xml.resource.org/public/rfc/html/rfc2274.html" />
<format octets="168030" type="XML" target="http://xml.resource.org/public/rfc/xml/rfc2274.xml" />
</reference>


<reference target2="reference.RFC.2275.xml" anchor="RFC2275">
<front>
<title abbrev="VACM for SNMPv3">View-based Access Control Model (VACM) for the Simple Network Management Protocol (SNMP)</title>
<author fullname="Bert Wijnen" initials="B." surname="Wijnen">
<organization>IBM T. J. Watson Research</organization>

<address>
<postal>
<street>Schagen 33</street>
<street>3461 GL Linschoten</street>
<country>Netherlands</country>
</postal>

<phone>+31-348-432-794</phone>
<email>wijnen@vnet.ibm.com</email>
</address>
</author>

<author fullname="Randy Presuhn" initials="R." surname="Presuhn">
<organization>BMC Software, Inc</organization>

<address>
<postal>
<street>1190 Saratoga Avenue</street>
<street>Suite 130</street>
<street>San Jose</street>
<street>CA  95129-3433</street>
<country>USA</country>
</postal>

<phone>+1-408-556-0720</phone>
<email>rpresuhn@bmc.com</email>
</address>
</author>

<author fullname="Keith McCloghrie" initials="K." surname="McCloghrie">
<organization>Cisco Systems, Inc.</organization>

<address>
<postal>
<street>170 West Tasman Drive</street>
<street>San Jose</street>
<street>CA  95134-1706</street>
<country>USA</country>
</postal>

<phone>+1-408-526-5260</phone>
<email>kzm@cisco.com</email>
</address>
</author>

<date year="1998" month="January" />
<area>Management</area>
<keyword>access control</keyword>
<keyword>network management</keyword>
<keyword>simple network management protocol</keyword>

<abstract>
<t>
   This document describes the View-based Access Control Model for use
   in the SNMP architecture .  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.
</t>
</abstract>
</front>

<seriesInfo value="2275" name="RFC" />
<format octets="91540" type="HTML" target="http://xml.resource.org/public/rfc/html/rfc2275.html" />
<format octets="76835" type="XML" target="http://xml.resource.org/public/rfc/xml/rfc2275.xml" />
</reference>


<reference target2="reference.RFC.2276.xml" anchor="RFC2276">
<front>
<title abbrev="URN Resolution">Architectural Principles of Uniform Resource Name Resolution</title>
<author fullname="Karen Sollins" initials="K." surname="Sollins">
<organization>MIT Laboratory for Computer Science</organization>

<address>
<postal>
<street>545 Technology Sq.</street>
<street>Cambridge</street>
<street>MA 02139</street>
</postal>

<phone>+1 617 253 6006</phone>
<email>sollins@lcs.mit.edu</email>
</address>
</author>

<date year="1998" month="January" />
<area>Applications</area>
<keyword>security</keyword>
<keyword>uniform resource</keyword>

<abstract>
<t>
   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.
</t>
</abstract>
</front>

<seriesInfo value="2276" name="RFC" />
<format octets="74216" type="HTML" target="http://xml.resource.org/public/rfc/html/rfc2276.html" />
<format octets="63520" type="XML" target="http://xml.resource.org/public/rfc/xml/rfc2276.xml" />
</reference>


<reference target2="reference.RFC.2277.xml" anchor="RFC2277">
<front>
<title abbrev="Charset Policy">IETF Policy on Character Sets and Languages</title>
<author fullname="Harald Tveit Alvestrand" initials="H.T." surname="Alvestrand">
<organization>UNINETT</organization>

<address>
<postal>
<street>P.O.Box 6883 Elgeseter</street>
<street>N-7002 TRONDHEIM</street>
<country>NORWAY</country>
</postal>

<phone>+47 73 59 70 94</phone>
<email>Harald.T.Alvestrand@uninett.no</email>
</address>
</author>

<date year="1998" month="January" />
<area>Applications</area>
<keyword>Internet Engineering Task Force</keyword>
<keyword>character encoding</keyword>
</front>

<seriesInfo value="18" name="BCP" />
<seriesInfo value="2277" name="RFC" />
<format octets="26556" type="HTML" target="http://xml.resource.org/public/rfc/html/rfc2277.html" />
<format octets="15544" type="XML" target="http://xml.resource.org/public/rfc/xml/rfc2277.xml" />
</reference>


<reference target2="reference.RFC.2278.xml" anchor="RFC2278">
<front>
<title abbrev="Charset Registration">IANA Charset Registration Procedures</title>
<author fullname="Ned Freed" initials="N." surname="Freed">
<organization>Innosoft International, Inc.</organization>

<address>
<postal>
<street>1050 Lakes Drive</street>
<street>West Covina</street>
<street>CA 91790</street>
<country>USA</country>
</postal>

<phone>+1 626 919 3600</phone>
<facsimile>+1 626 919 3614</facsimile>
<email>ned.freed@innosoft.com</email>
</address>
</author>

<author fullname="Jon Postel" initials="J." surname="Postel">
<organization>USC/Information Sciences Institute</organization>

<address>
<postal>
<street>4676 Admiralty Way</street>
<street>Marina del Rey</street>
<street>CA  90292</street>
<country>USA</country>
</postal>

<phone>+1 310 822 1511</phone>
<facsimile>+1 310 823 6714</facsimile>
<email>Postel@ISI.EDU</email>
</address>
</author>

<date year="1998" month="January" />
<area>Applications</area>
<keyword>Internet Assigned Numbers Authority</keyword>
<keyword>multipurpose internet mail extensions</keyword>
<keyword>character set</keyword>
</front>

<seriesInfo value="19" name="BCP" />
<seriesInfo value="2278" name="RFC" />
<format octets="27664" type="HTML" target="http://xml.resource.org/public/rfc/html/rfc2278.html" />
<format octets="15985" type="XML" target="http://xml.resource.org/public/rfc/xml/rfc2278.xml" />
</reference>


<reference target2="reference.RFC.2279.xml" anchor="RFC2279">
<front>
<title abbrev="UTF-8">UTF-8, a transformation format of ISO 10646</title>
<author fullname="Francois Yergeau" initials="F." surname="Yergeau">
<organization>Alis Technologies</organization>

<address>
<postal>
<street>100, boul. Alexis-Nihon</street>
<street>Suite 600</street>
<city>Montreal</city>
<region>Quebec</region>
<code>H4M 2P2</code>
<country>CA</country>
</postal>

<phone>+1 514 747 2547</phone>
<facsimile>+1 514 747 2561</facsimile>
<email>fyergeau@alis.com</email>
</address>
</author>

<date year="1998" month="January" />

<abstract>
<t>ISO/IEC 10646-1 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-8, the object of this memo, has the characteristic of preserving the full US-ASCII range, providing compatibility with file systems, parsers and other software that rely on US-ASCII values but are transparent to other values. This memo updates and replaces RFC 2044, in particular addressing the question of versions of the relevant standards.</t>
</abstract>
</front>

<seriesInfo value="2279" name="RFC" />
</reference>


<reference target2="reference.RFC.2280.xml" anchor="RFC2280">
<front>
<title abbrev="Routing Policy">Routing Policy Specification Language (RPSL)</title>
<author fullname="Cengiz Alaettinoglu" initials="C." surname="Alaettinoglu">
<organization>USC Information Sciences Institute</organization>

<address>
<postal>
<street>4676 Admiralty Way</street>
<street>Suite 1001</street>
<street>Marina del Rey</street>
<street>CA  90292</street>
</postal>

<email>cengiz@isi.edu</email>
</address>
</author>

<author fullname="Tony Bates" initials="T." surname="Bates">
<organization>Cisco Systems, Inc.</organization>

<address>
<postal>
<street>170 West Tasman Drive</street>
<street>San Jose</street>
<street>CA 95134</street>
</postal>

<email>tbates@cisco.com</email>
</address>
</author>

<author fullname="Elise Gerich" initials="E." surname="Gerich">
<organization>At Home Network</organization>

<address>
<postal>
<street>385 Ravendale Drive</street>
<street>Mountain View</street>
<street>CA 94043</street>
</postal>

<email>epg@home.net</email>
</address>
</author>

<author fullname="Daniel Karrenberg" initials="D." surname="Karrenberg">
<organization>RIPE Network Coordination Centre (NCC)</organization>

<address>
<postal>
<street>Kruislaan 409</street>
<street>NL-1098 SJ Amsterdam</street>
<country>Netherlands</country>
</postal>

<email>dfk@ripe.net</email>
</address>
</author>

<author fullname="David Meyer" initials="D." surname="Meyer">
<organization>University of Oregon</organization>

<address>
<postal>
<street>Eugene</street>
<street>OR 97403</street>
</postal>

<email>meyer@antc.uoregon.edu</email>
</address>
</author>

<author fullname="Marten Terpstra" initials="M." surname="Terpstra">
<organization>c/o Bay Networks, Inc.</organization>

<address>
<postal>
<street>2 Federal</street>
<street>Billerica MA 01821</street>
<country>St</country>
</postal>

<email>marten@BayNetworks.com</email>
</address>
</author>

<author fullname="Curtis Villamizar" initials="C." surname="Villamizar">
<organization>ANS</organization>

<address>
<email>curtis@ans.net</email>
</address>
</author>

<date year="1998" month="January" />
<area>Routing</area>
<keyword>RPSL</keyword>
<keyword>routing</keyword>
</front>

<seriesInfo value="2280" name="RFC" />
<format octets="131570" type="HTML" target="http://xml.resource.org/public/rfc/html/rfc2280.html" />
<format octets="117959" type="XML" target="http://xml.resource.org/public/rfc/xml/rfc2280.xml" />
</reference>


<reference target2="reference.RFC.2281.xml" anchor="RFC2281">
<front>
<title abbrev="Cisco HSRP">Cisco Hot Standby Router Protocol (HSRP)</title>
<author fullname="Tony Li" initials="T." surname="Li">
<organization>Juniper Networks, Inc.</organization>

<address>
<postal>
<street>3260 Jay St.</street>
<street>Santa Clara</street>
<street>CA 95054</street>
</postal>

<phone>(408) 327-1900</phone>
<email>tli@juniper.net</email>
</address>
</author>

<author fullname="Bruce Cole" initials="B." surname="Cole">
<organization>Juniper Networks, Inc.</organization>

<address>
<postal>
<street>3260 Jay St.</street>
<street>Santa Clara</street>
<street>CA 95054</street>
</postal>

<phone>(408) 327-1900</phone>
<email>cole@juniper.net</email>
</address>
</author>

<author fullname="Phil Morton" initials="P." surname="Morton">
<organization>Cisco Systems</organization>

<address>
<postal>
<street>170 Tasman Dr.</street>
<street>San Jose</street>
<street>CA 95143</street>
</postal>

<phone>(408) 526-7632</phone>
<email>pmorton@cisco.com</email>
</address>
</author>

<author fullname="Dawn Li" initials="D." surname="Li">
<organization>Cisco Systems</organization>

<address>
<postal>
<street>170 Tasman Dr.</street>
<street>San Jose</street>
<street>CA 95143</street>
</postal>

<phone>(408) 527-2014</phone>
<email>dawnli@cisco.com</email>
</address>
</author>

<date year="1998" month="March" />
<area>Routing</area>
<keyword>router</keyword>
<keyword>routing</keyword>

<abstract>
<t>
   This document reflects an existing deployed protocol.  The IETF does
   have a working group which is in the process of producing a standards
   track protocol to address the same issues.
</t>

<t>
   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.
</t>

<t>
   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&apos;s connectivity.  This memo also
   discusses the ARP, MAC address, and security issues with this
   protocol.
</t>
</abstract>

<note title="IESG Note">
<t>
   This document reflects an existing deployed protocol.  The IETF does
   have a working group which is in the process of producing a standards
   track protocol to address the same issues.
</t>
</note>
</front>

<seriesInfo value="2281" name="RFC" />
<format octets="48068" type="HTML" target="http://xml.resource.org/public/rfc/html/rfc2281.html" />
<format octets="34558" type="XML" target="http://xml.resource.org/public/rfc/xml/rfc2281.xml" />
</reference>


<reference target2="reference.RFC.2282.xml" anchor="RFC2282">
<front>
<title abbrev="IAB and IESG Confirmation">IAB and IESG Selection, Confirmation, and Recall Process: Operation of the Nominating and Recall Committees</title>
<author fullname="James M. Galvin" initials="J.M." surname="Galvin">
<organization>eList eXpress LLC</organization>

<address>
<postal>
<street>PO Box 220</street>
<street>Glenwood</street>
<street>21738</street>
<country>MD</country>
</postal>

<email>galvin@elistx.com</email>
</address>
</author>

<date year="1998" month="February" />
<area>General</area>
<keyword>Internet Architecture Board</keyword>
<keyword>Internet Engineering Steering Group</keyword>

<abstract>
<t>
   The process by which the members of the IAB and IESG are selected,
   confirmed, and recalled is specified.  The evolution of the process
   has relied principally on oral tradition as a means by which the
   lessons learned could be passed on to successive committees.  This
   document is a self-consistent, organized compilation of the process
   as it is known today.
</t>
</abstract>
</front>

<seriesInfo value="10" name="BCP" />
<seriesInfo value="2282" name="RFC" />
<format octets="38812" type="HTML" target="http://xml.resource.org/public/rfc/html/rfc2282.html" />
<format octets="28543" type="XML" target="http://xml.resource.org/public/rfc/xml/rfc2282.xml" />
</reference>


<reference target2="reference.RFC.2283.xml" anchor="RFC2283">
<front>
<title>Multiprotocol Extensions for BGP-4</title>
<author fullname="Tony Bates" initials="T." surname="Bates">
<organization>Cisco Systems, Inc.</organization>

<address>
<postal>
<street>170 West Tasman Drive</street>
<street>San Jose</street>
<street>CA 95134</street>
</postal>

<email>tbates@cisco.com</email>
</address>
</author>

<author fullname="Ravi Chandra" initials="R." surname="Chandra">
<organization>Cisco Systems, Inc.</organization>

<address>
<postal>
<street>170 West Tasman Drive</street>
<street>San Jose</street>
<street>CA 95134</street>
</postal>

<email>rchandra@cisco.com</email>
</address>
</author>

<author fullname="Dave Katz" initials="D." surname="Katz">
<organization>Juniper Networks, Inc.</organization>

<address>
<postal>
<street>3260 Jay St.</street>
<street>Santa Clara</street>
<street>CA 95054</street>
</postal>

<email>dkatz@jnx.com</email>
</address>
</author>

<author fullname="Yakov Rekhter" initials="Y." surname="Rekhter">
<organization>Cisco Systems, Inc.</organization>

<address>
<postal>
<street>170 West Tasman Drive</street>
<street>San Jose</street>
<street>CA 95134</street>
</postal>

<email>yakov@cisco.com</email>
</address>
</author>

<date year="1998" month="February" />
<area>Routing</area>
<keyword>BGP4</keyword>
<keyword>border gateway protocol version 4</keyword>
<keyword>routing</keyword>

<abstract>
<t>
   Currently BGP-4  is capable of carrying routing information
   only for IPv4 . This document defines extensions to BGP-4 to
   enable it to carry routing information for multiple Network Layer
   protocols (e.g., IPv6, IPX, etc...). The extensions are backward
   compatible - a router that supports the extensions can interoperate
   with a router that doesn&apos;t support the extensions.
</t>
</abstract>
</front>

<seriesInfo value="2283" name="RFC" />
<format octets="33445" type="HTML" target="http://xml.resource.org/public/rfc/html/rfc2283.html" />
<format octets="19276" type="XML" target="http://xml.resource.org/public/rfc/xml/rfc2283.xml" />
</reference>


<reference target2="reference.RFC.2284.xml" anchor="RFC2284">
<front>
<title abbrev="PPP EAP">PPP Extensible Authentication Protocol (EAP)</title>
<author fullname="Larry J. Blunk" initials="L.J." surname="Blunk">
<organization>Merit Network, Inc.</organization>

<address>
<postal>
<street>4251 Plymouth Rd.</street>
<street>Suite C</street>
<street>Ann Arbor</street>
<street>MI  48105</street>
</postal>

<phone>734-763-6056</phone>
<facsimile>734-647-3185</facsimile>
<email>ljb@merit.edu</email>
</address>
</author>

<author fullname="John R. Vollbrecht" initials="J.R." surname="Vollbrecht">
<organization>Merit Network, Inc.</organization>

<address>
<postal>
<street>4251 Plymouth Rd.</street>
<street>Suite C</street>
<street>Ann Arbor</street>
<street>MI  48105</street>
</postal>

<phone>+1-313-763-1206</phone>
<facsimile>+1-734-647-3185</facsimile>
<email>jrv@merit.edu</email>
</address>
</author>

<date year="1998" month="March" />
<area>Internet</area>
<keyword>EAP</keyword>
<keyword>authentication</keyword>
<keyword>point-to-point protocol</keyword>

<abstract>
<t>
   The Point-to-Point Protocol (PPP)  provides a standard method for
   transporting multi-protocol datagrams over point-to-point links.
</t>

<t>
   PPP also defines an extensible Link Control Protocol, which allows
   negotiation of an Authentication Protocol for authenticating its peer
   before allowing Network Layer protocols to transmit over the link.
</t>

<t>
   This document defines the PPP Extensible Authentication Protocol.
</t>
</abstract>
</front>

<seriesInfo value="2284" name="RFC" />
<format octets="41669" type="HTML" target="http://xml.resource.org/public/rfc/html/rfc2284.html" />
<format octets="28348" type="XML" target="http://xml.resource.org/public/rfc/xml/rfc2284.xml" />
</reference>


<reference target2="reference.RFC.2285.xml" anchor="RFC2285">
<front>
<title abbrev="Benchmarking Terminology">Benchmarking Terminology for LAN Switching Devices</title>
<author fullname="Robert Mandeville" initials="R." surname="Mandeville">
<organization>European Network Laboratories (ENL)</organization>

<address>
<postal>
<street>2</street>
<street>rue Helene Boucher</street>
<street>78286 Guyancourt Cedex</street>
<country>France</country>
</postal>

<phone>+ 33 1 39 44 12 05</phone>
<facsimile>+ 33 1 39 44 12 06</facsimile>
<email>bob.mandeville@eunet.fr</email>
</address>
</author>

<date year="1998" month="February" />
<area>Operations</area>
<keyword>local area network</keyword>
<keyword>Benchmarking</keyword>
</front>

<seriesInfo value="2285" name="RFC" />
<format octets="58104" type="HTML" target="http://xml.resource.org/public/rfc/html/rfc2285.html" />
<format octets="42730" type="XML" target="http://xml.resource.org/public/rfc/xml/rfc2285.xml" />
</reference>


<reference target2="reference.RFC.2286.xml" anchor="RFC2286">
<front>
<title abbrev="Test Cases: HMAC-RIPEMD160, HMAC-RIPEMD128">Test Cases for HMAC-RIPEMD160 and HMAC-RIPEMD128</title>
<author fullname="Justin S. Kapp" initials="J.S." surname="Kapp">
<organization>Reaper Technologies</organization>

<address>
<postal>
<street>The Post Office</street>
<street>Dunsop Bridge</street>
<street>Clitheroe</street>
<street>Lancashire.</street>
<street>BB7 3BB.</street>
<country>United Kingdom</country>
</postal>

<email>skapp@reapertech.com</email>
</address>
</author>

<date year="1998" month="February" />
<area>Security</area>
<keyword>authentication</keyword>
<keyword>cryptographic hash message authentication codes</keyword>

<abstract>
<t>
   This document provides two sets of test cases for HMAC-RIPEMD160 and
   HMAC-RIPEMD128, respectively. HMAC-RIPEMD160 and HMAC-RIPEMD128 are
   two constructs of the HMAC  message authentication function
   using the RIPEMD-160 and RIPEMD-128  hash functions. The test
   cases and results provided in this document are meant to be used as a
   conformance test for HMAC-RIPEMD160 and HMAC-RIPEMD128
   implementations.
</t>
</abstract>
</front>

<seriesInfo value="2286" name="RFC" />
<format octets="20583" type="HTML" target="http://xml.resource.org/public/rfc/html/rfc2286.html" />
<format octets="11419" type="XML" target="http://xml.resource.org/public/rfc/xml/rfc2286.xml" />
</reference>


<reference target2="reference.RFC.2287.xml" anchor="RFC2287">
<front>
<title abbrev="System-Level Managed Objects">Definitions of System-Level Managed Objects for Applications</title>
<author fullname="Cheryl Krupczak" initials="C." surname="Krupczak">
<organization>Empire Technologies, Inc.</organization>

<address>
<postal>
<street>541 Tenth Street</street>
<street>NW Suite 169</street>
<street>Atlanta</street>
<street>GA 30318</street>
</postal>

<phone>770.384.0184</phone>
<email>cheryl@empiretech.com</email>
</address>
</author>

<author fullname="Jonathan Saperia" initials="J." surname="Saperia">
<organization>BGS Systems Inc.</organization>

<address>
<email>saperia@networks.bgs.com</email>
</address>
</author>

<date year="1998" month="February" />
<area>Management</area>
<keyword>Management Information Base</keyword>
<keyword>managed object</keyword>

<abstract>
<t>
   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.
</t>

<t>
   This memo does not specify a standard for the Internet community.
</t>
</abstract>
</front>

<seriesInfo value="2287" name="RFC" />
<format octets="107810" type="HTML" target="http://xml.resource.org/public/rfc/html/rfc2287.html" />
<format octets="94651" type="XML" target="http://xml.resource.org/public/rfc/xml/rfc2287.xml" />
</reference>


<reference target2="reference.RFC.2288.xml" anchor="RFC2288">
<front>
<title abbrev="Bibligraphic Identifiers">Using Existing Bibliographic Identifiers as Uniform Resource Names</title>
<author fullname="Clifford Lynch" initials="C." surname="Lynch">
<organization>Executive Director</organization>

<address>
<postal>
<street>Coalition for Networked Information</street>
<street>21 Dupont Circle</street>
<street>Washington</street>
<street>DC 20036</street>
</postal>

<email>cliff@cni.org</email>
</address>
</author>

<author fullname="Cecilia Preston" initials="C." surname="Preston">
<organization>Preston &amp; Lynch</organization>

<address>
<postal>
<street>PO Box 8310</street>
<street>Emeryville</street>
<street>CA 94662</street>
</postal>

<email>cecilia@well.com</email>
</address>
</author>

<author fullname="Ron Daniel Jr." initials="R.D." surname="Jr">
<organization>Advanced Computing Lab, MS B287</organization>

<address>
<postal>
<street>Los Alamos National Laboratory</street>
<street>Los Alamos</street>
<street>NM</street>
<street>87545</street>
</postal>

<email>rdaniel@acl.lanl.gov</email>
</address>
</author>

<date year="1998" month="February" />
<area>Applications</area>
<keyword>uniform resource</keyword>

<abstract>
<t>
   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.
</t>
</abstract>
</front>

<seriesInfo value="2288" name="RFC" />
<format octets="32813" type="HTML" target="http://xml.resource.org/public/rfc/html/rfc2288.html" />
<format octets="20736" type="XML" target="http://xml.resource.org/public/rfc/xml/rfc2288.xml" />
</reference>


<reference target2="reference.RFC.2289.xml" anchor="RFC2289">
<front>
<title abbrev="OTP">A One-Time Password System</title>
<author fullname="Neil Haller" initials="N." surname="Haller">
<organization>Bellcore</organization>

<address>
<postal>
<street>MCC 1C-265B</street>
<street>445 South Street</street>
<street>Morristown</street>
<street>NJ</street>
<street>07960-6438</street>
<country>USA</country>
</postal>

<phone>+1 201 829-4478</phone>
<facsimile>+1 201 829-2504</facsimile>
<email>nmh@bellcore.com</email>
</address>
</author>

<author fullname="Craig Metz" initials="C." surname="Metz">
<organization>Kaman Sciences Corporation</organization>

<address>
<postal>
<street>For NRL Code 5544</street>
<street>4555 Overlook Avenue</street>
<street>S.W.</street>
<street>Washington</street>
<street>DC</street>
<street>20375-5337</street>
<country>USA</country>
</postal>

<phone>+1 202 404-7122</phone>
<facsimile>+1 202 404-7942</facsimile>
<email>cmetz@cs.nrl.navy.mil</email>
</address>
</author>

<author fullname="Philip J. Nesser II" initials="P.J." surname="Nesser">
<organization>Nesser &amp; Nesser Consulting</organization>

<address>
<postal>
<street>13501 100th Ave</street>
<street>Suite 5202</street>
<street>Kirkland</street>
<street>WA 98034</street>
<country>USA</country>
</postal>

<phone>+1 206 481 4303</phone>
<email>pjnesser@martigny.ai.mit.edu</email>
</address>
</author>

<author fullname="Mike Straw" initials="M." surname="Straw">
<organization>Bellcore</organization>

<address>
<postal>
<street>RRC 1A-225</street>
<street>445 Hoes Lane</street>
<street>Piscataway</street>
<street>NJ 08854-4182</street>
</postal>

<phone>+1 908 699-5212</phone>
<email>mess@bellcore.com</email>
</address>
</author>

<date year="1998" month="February" />
<area>Security</area>
<keyword>attack</keyword>
<keyword>authentication</keyword>
<keyword>one-time password</keyword>
<keyword>password</keyword>
</front>

<seriesInfo value="2289" name="RFC" />
<format octets="91927" type="HTML" target="http://xml.resource.org/public/rfc/html/rfc2289.html" />
<format octets="73197" type="XML" target="http://xml.resource.org/public/rfc/xml/rfc2289.xml" />
</reference>


<reference target2="reference.RFC.2290.xml" anchor="RFC2290">
<front>
<title abbrev="Mobile-IPv4">Mobile-IPv4 Configuration Option for PPP IPCP</title>
<author fullname="Jim Solomon" initials="J." surname="Solomon">
<organization>Motorola, Inc.</organization>

<address>
<postal>
<street>1301 E. Algonquin Rd. - Rm 2240</street>
<street>Schaumburg</street>
<street>IL  60196</street>
</postal>

<phone>+1-847-576-2753</phone>
<facsimile>+1-847-576-3240</facsimile>
<email>solomon@comm.mot.com</email>
</address>
</author>

<author fullname="Steven Glass" initials="S." surname="Glass">
<organization>FTP Software, Inc.</organization>

<address>
<postal>
<street>2 High Street</street>
<street>North Andover</street>
<street>MA  01845</street>
</postal>

<phone>+1-508-685-4000</phone>
<facsimile>+1-508-684-6105</facsimile>
<email>glass@ftp.com</email>
</address>
</author>

<date year="1998" month="February" />
<area>Internet</area>
<keyword>configuration</keyword>
<keyword>internet procotol control protocol</keyword>
<keyword>internet protocol version 4</keyword>
<keyword>mobile ip</keyword>
<keyword>point-to-point protocol</keyword>

<abstract>
<t>
   Mobile IP  defines media-independent procedures by which a
   Mobile Node can maintain existing transport and application-layer
   connections despite changing its point-of-attachment to the Internet
   and without changing its IP address.  PPP  provides a
   standard method for transporting multi-protocol packets over point-
   to-point links.  As currently specified, Mobile IP Foreign Agents
   which support Mobile Node connections via PPP can do so only by first
   assigning unique addresses to those Mobile Nodes, defeating one of
   the primary advantages of Foreign Agents.  This documents corrects
   this problem by defining the Mobile-IPv4 Configuration Option to the
   Internet Protocol Control Protocol (IPCP) .  Using this
   option, two peers can communicate their support for Mobile IP during
   the IPCP phase of PPP.  Familiarity with Mobile IP , IPCP
   , and PPP  is assumed.
</t>
</abstract>
</front>

<seriesInfo value="2290" name="RFC" />
<format octets="56444" type="HTML" target="http://xml.resource.org/public/rfc/html/rfc2290.html" />
<format octets="40804" type="XML" target="http://xml.resource.org/public/rfc/xml/rfc2290.xml" />
</reference>


<reference target2="reference.RFC.2291.xml" anchor="RFC2291">
<front>
<title abbrev="Distributed Authoring and Versioning">Requirements for a Distributed Authoring and Versioning Protocol for the World Wide Web</title>
<author fullname="J. Slein" initials="J." surname="Slein">
<organization abbrev="Xerox">Xerox Corporation</organization>

<address>
<postal>
<street>800 Phillips Road 128-29E</street>
<city>Webster</city>
<region>NY</region>
<code>14580</code>
</postal>

<email>slein@wrc.xerox.com</email>
</address>
</author>

<author fullname="Fabio Vitali" initials="F." surname="Vitali">
<organization abbrev="University of Bologna">Department of Computer Science, University of Bologna</organization>

<address>
<email>fabio@cs.unibo.it</email>
</address>
</author>

<author fullname="E. J. Whitehead, Jr." initials="E." surname="Whitehead">
<organization abbrev="U.C. Irvine">Dept. Of Information and Computer Science,
    University of California, Irvine</organization>

<address>
<postal>
<street />
<city>Irvine</city>
<region>CA</region>
<code>92697-3425</code>
</postal>

<facsimile>714-824-4056</facsimile>
<email>ejw@ics.uci.edu</email>
</address>
</author>

<author fullname="David G. Durand" initials="D." surname="Durand">
<organization abbrev="Boston University">Department of Computer Science,
   Boston University</organization>

<address>
<postal>
<street />
<city>Boston</city>
<region>MA</region>
</postal>

<email>dgd@cs.bu.edu</email>
</address>
</author>

<date year="1998" month="February"></date>
<area>Applications</area>

<abstract>
<t>
   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.
  </t>
</abstract>
</front>

<seriesInfo value="2291" name="RFC" />
<format octets="63542" type="HTML" target="http://xml.resource.org/public/rfc/html/rfc2291.html" />
<format octets="49027" type="XML" target="http://xml.resource.org/public/rfc/xml/rfc2291.xml" />
</reference>


<reference target2="reference.RFC.2292.xml" anchor="RFC2292">
<front>
<title abbrev="IPv6 Sockets">Advanced Sockets API for IPv6</title>
<author fullname="W. Richard Stevens" initials="W.R." surname="Stevens">
<organization />

<address>
<postal>
<street>1202 E. Paseo del Zorro</street>
<street>Tucson</street>
<street>AZ  85718</street>
</postal>

<email>rstevens@kohala.com</email>
</address>
</author>

<author fullname="Matt Thomas" initials="M." surname="Thomas">
<organization>AltaVista Internet Software</organization>

<address>
<postal>
<street>LJO2-1/J8</street>
<street>30 Porter Rd</street>
<street>Littleton</street>
<street>MA  01460</street>
</postal>

<email>matt.thomas@altavista-software.com</email>
</address>
</author>

<date year="1998" month="February" />
<area>Internet</area>
<keyword>IPv6</keyword>
<keyword>application program interface</keyword>
<keyword>internet protocol version 6</keyword>
<keyword>socket</keyword>

<abstract>
<t>
   Specifications are in progress for changes to the sockets API to
   support IP version 6 .  These changes are for TCP and UDP-
   based applications and will support most end-user applications in use
   today: Telnet and FTP clients and servers, HTTP clients and servers,
   and the like.
</t>

<t>
   But another class of applications exists that will also be run under
   IPv6.  We call these &quot;advanced&quot; applications and today this includes
   programs such as Ping, Traceroute, routing daemons, multicast routing
   daemons, router discovery daemons, and the like.  The API feature
   typically used by these programs that make them &quot;advanced&quot; is a raw
   socket to access ICMPv4, IGMPv4, or IPv4, along with some knowledge
   of the packet header formats used by these protocols.  To provide
   portability for applications that use raw sockets under IPv6, some
   standardization is needed for the advanced API features.
</t>

<t>
   There are other features of IPv6 that some applications will need to
   access: interface identification (specifying the outgoing interface
   and determining the incoming interface) and IPv6 extension headers
   that are not addressed in : Hop-by-Hop options, Destination
   options, and the Routing header (source routing).  This document
   provides API access to these features too.
</t>
</abstract>
</front>

<seriesInfo value="2292" name="RFC" />
<format octets="167783" type="HTML" target="http://xml.resource.org/public/rfc/html/rfc2292.html" />
<format octets="150202" type="XML" target="http://xml.resource.org/public/rfc/xml/rfc2292.xml" />
</reference>


<reference target2="reference.RFC.2293.xml" anchor="RFC2293">
<front>
<title abbrev="Table and Subtrees in the X.500">Representing Tables and Subtrees in the X.500 Directory</title>
<author fullname="Steve Kille" initials="S." surname="Kille">
<organization>Isode Ltd</organization>

<address>
<postal>
<street>The Dome</street>
<street>The Square</street>
<street>Richmond</street>
<street>TW9 1DT</street>
<street>England</street>
</postal>

<phone>+44-181-332-9091</phone>
<email>S.Kille@ISODE.COM</email>
</address>
</author>

<date year="1998" month="March" />
<area>Applications</area>
<keyword>ITU directory service protocol</keyword>
<keyword>directory</keyword>

<abstract>
<t>
   This document defines techniques for representing two types of
   information mapping in the OSI Directory .

<list>
<t>
   1.  Mapping from a key to a value (or set of values), as might
       be done in a table lookup.
</t>

<t>
   2.  Mapping from a distinguished name to an associated
       value (or values), where the values are not defined by the owner
       of the entry.  This is achieved by use of a directory subtree.
</t>
</list>
</t>

<t>
   These techniques were developed for supporting MHS use of Directory
   , but are specified separately as they have more general
   applicability.
</t>
</abstract>
</front>

<seriesInfo value="2293" name="RFC" />
<format octets="23082" type="HTML" target="http://xml.resource.org/public/rfc/html/rfc2293.html" />
<format octets="12101" type="XML" target="http://xml.resource.org/public/rfc/xml/rfc2293.xml" />
</reference>


<reference target2="reference.RFC.2294.xml" anchor="RFC2294">
<front>
<title abbrev="Directory Information Tree">Representing the O/R Address hierarchy in the X.500 Directory Information Tree</title>
<author fullname="Steve Kille" initials="S." surname="Kille">
<organization>Isode Ltd.</organization>

<address>
<postal>
<street>The Dome</street>
<street>The Square</street>
<street>Richmond</street>
<street>TW9 1DT</street>
<street>England</street>
</postal>

<phone>+44-181-332-9091</phone>
<email>S.Kille@ISODE.COM</email>
</address>
</author>

<date year="1998" month="March" />
<area>Applications</area>
<keyword>ITU directory service protocol</keyword>
<keyword>ITU message handling service protocol</keyword>
<keyword>directory</keyword>
<keyword>routing</keyword>

<abstract>
<t>
   This document defines a representation of the O/R Address hierarchy
   in the Directory Information Tree [6, 1].  This is useful for a range
   of purposes, including:
</t>

<t>
    o  Support for MHS Routing .
</t>

<t>
    o  Support for X.400/RFC 822 address mappings [2, 5].
</t>

<t>
   Please send comments to the author or to the discussion group &lt;mhs-
   ds@mercury.udev.cdc.com&gt;.
</t>
</abstract>
</front>

<seriesInfo value="2294" name="RFC" />
<format octets="33218" type="HTML" target="http://xml.resource.org/public/rfc/html/rfc2294.html" />
<format octets="21667" type="XML" target="http://xml.resource.org/public/rfc/xml/rfc2294.xml" />
</reference>


<reference target2="reference.RFC.2295.xml" anchor="RFC2295">
<front>
<title abbrev="HTTP Content Negotiation">Transparent Content Negotiation in HTTP</title>
<author fullname="Koen Holtman" initials="K." surname="Holtman">
<organization>Technische Universiteit Eindhoven</organization>

<address>
<postal>
<street>Postbus 513</street>
<street>Kamer HG 6.57</street>
<street>5600 MB Eindhoven (The Netherlands)</street>
</postal>

<email>koen@win.tue.nl</email>
</address>
</author>

<author fullname="Andrew H. Mutz" initials="A.H." surname="Mutz">
<organization>Hewlett-Packard Company</organization>

<address>
<postal>
<street>1501 Page Mill Road 3U-3</street>
<street>Palo Alto CA 94304</street>
<country>USA</country>
</postal>

<facsimile>+1 415 857 4691</facsimile>
<email>mutz@hpl.hp.com</email>
</address>
</author>

<date year="1998" month="March" />
<area>Applications</area>
<keyword>HTTP</keyword>
<keyword>hypertext transfer protocol</keyword>

<abstract>
<t>
   HTTP allows web site authors to put multiple versions of the same
   information under a single URL.  Transparent content negotiation is
   an extensible negotiation 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.
</t>
</abstract>
</front>

<seriesInfo value="2295" name="RFC" />
<format octets="149229" type="HTML" target="http://xml.resource.org/public/rfc/html/rfc2295.html" />
<format octets="126920" type="XML" target="http://xml.resource.org/public/rfc/xml/rfc2295.xml" />
</reference>


<reference target2="reference.RFC.2296.xml" anchor="RFC2296">
<front>
<title abbrev="HTTP RVSA/1.0">HTTP Remote Variant Selection Algorithm -- RVSA/1.0</title>
<author fullname="Koen Holtman" initials="K." surname="Holtman">
<organization>Technische Universiteit Eindhoven</organization>

<address>
<postal>
<street>Postbus 513</street>
<street>Kamer HG 6.57</street>
<street>5600 MB Eindhoven (The Netherlands)</street>
</postal>

<email>koen@win.tue.nl</email>
</address>
</author>

<author fullname="Andrew H. Mutz" initials="A.H." surname="Mutz">
<organization>Hewlett-Packard Company</organization>

<address>
<postal>
<street>1501 Page Mill Road 3U-3</street>
<street>Palo Alto CA 94304</street>
<country>USA</country>
</postal>

<facsimile>+1 415 857 4691</facsimile>
<email>mutz@hpl.hp.com</email>
</address>
</author>

<date year="1998" month="March" />
<area>Applications</area>
<keyword>hypertext transfer protocol</keyword>

<abstract>
<t>
   HTTP allows web site authors to put multiple versions of the same
   information under a single URL.  Transparent content negotiation is a
   mechanism for automatically selecting the best version when the URL
   is accessed.  A remote variant selection algorithm can be used to
   speed up the transparent negotiation process. This document defines
   the remote variant selection algorithm with the version number 1.0.
</t>
</abstract>
</front>

<seriesInfo value="2296" name="RFC" />
<format octets="37851" type="HTML" target="http://xml.resource.org/public/rfc/html/rfc2296.html" />
<format octets="25700" type="XML" target="http://xml.resource.org/public/rfc/xml/rfc2296.xml" />
</reference>


<reference target2="reference.RFC.2297.xml" anchor="RFC2297">
<front>
<title abbrev="Ipsilon&apos;s General Switch Management">Ipsilon's General Switch Management Protocol Specification Version 2.0</title>
<author fullname="Peter Newman" initials="P." surname="Newman">
<organization>Nokia</organization>

<address>
<postal>
<street>232 Java Drive</street>
<city>Sunnyvale</city>
<region>CA</region>
<code>94089</code>
<country>US</country>
</postal>

<phone>+1 408 990 2003</phone>
<email>pn@ipsilon.com</email>
</address>
</author>

<author fullname="W. L. Edwards" initials="W.L." surname="Edwards">
<organization>Sprint Technology Services - Long Distance Division</organization>

<address>
<postal>
<street>9300 Metcalf Avenue</street>
<street>Mailstop KSOPKB0802</street>
<city>Overland Park</city>
<region>KS</region>
<code>66212-6333</code>
<country>US</country>
</postal>

<phone>+1 913 534 5334</phone>
<email>texas@sprintcorp.com</email>
</address>
</author>

<author fullname="Robert M. Hinden" initials="R.M." surname="Hinden">
<organization>Nokia</organization>

<address>
<postal>
<street>232 Java Drive</street>
<city>Sunnyvale</city>
<region>CA</region>
<code>94089</code>
<country>US</country>
</postal>

<phone>+1 408 990 2004</phone>
<email>hinden@ipsilon.com</email>
</address>
</author>

<author fullname="Eric Hoffman" initials="E." surname="Hoffman">
<organization>Nokia</organization>

<address>
<postal>
<street>232 Java Drive</street>
<city>Sunnyvale</city>
<region>CA</region>
<code>94089</code>
<country>US</country>
</postal>

<phone>+1 408 990 2010</phone>
<email>hoffman@ipsilon.com</email>
</address>
</author>

<author fullname="Fong Ching Liaw" initials="F.C." surname="Liaw">
<organization>Coppercom</organization>

<address>
<postal>
<street />
</postal>

<phone>+1 408 873 2688</phone>
<email>fong@coppercom.com</email>
</address>
</author>

<author fullname="Tom Lyon" initials="T." surname="Lyon">
<organization>Nokia</organization>

<address>
<postal>
<street>232 Java Drive</street>
<city>Sunnyvale</city>
<region>CA</region>
<code>94089</code>
<country>US</country>
</postal>

<phone>+1 408 990 2001</phone>
<email>pugs@ipsilon.com</email>
</address>
</author>

<author fullname="Greg Minshall" initials="G." surname="Minshall">
<organization>Fiberlane Communications</organization>

<address>
<postal>
<street>1399 Charleston Road</street>
<city>Mountain View</city>
<region>CA</region>
<code>94043</code>
<country>US</country>
</postal>

<phone>+1 650 237 3164</phone>
<email>minshall@fiberlane.com</email>
</address>
</author>

<date year="1998" month="March" />

<abstract>
<t>This memo specifies enhancements to the  General Switch Management Protocol (GSMP). The major enhancement is the addition of Quality of Service (QoS) messages. Other improvements have been made to the protocol resulting from operational experience. GSMP is a general purpose protocol to control an ATM switch. It allows a controller to establish and release connections across the switch; add and delete leaves on a multicast connection; manage switch ports; request configuration information; and request statistics.</t>
</abstract>
</front>

<seriesInfo value="2297" name="RFC" />
</reference>


<reference target2="reference.RFC.2298.xml" anchor="RFC2298">
<front>
<title abbrev="Message Disposition Notifications">An Extensible Message Format for Message Disposition Notifications</title>
<author fullname="Roger Fajman" initials="R." surname="Fajman">
<organization>National Institutes of Health</organization>

<address>
<postal>
<street>Building 12A</street>
<street>Room 3063</street>
<street>12 South Drive MSC 5659</street>
<street>Bethesda</street>
<street>Maryland 20892-5659</street>
<country>USA</country>
</postal>

<phone>+1 301 402 4265</phone>
<facsimile>+1 301 480 6241</facsimile>
<email>raf@cu.nih.gov</email>
</address>
</author>

<date year="1998" month="March" />
<area>Applications</area>
<keyword>ITU message handling service protocol</keyword>
<keyword>content-type</keyword>
<keyword>multipurpose internet mail extensions</keyword>

<abstract>
<t>
   This memo defines a MIME content-type that may be used by a mail user
   agent (UA) or electronic mail gateway to report the disposition of a
   message after it has been sucessfully delivered to a recipient.  This
   content-type is intended to be machine-processable.  Additional
   message headers are also defined to permit Message Disposition
   Notifications (MDNs) to be requested by the sender of a message.  The
   purpose is to extend Internet Mail to support functionality often
   found in other messaging systems, such as X.400 and the proprietary
   &quot;LAN-based&quot; systems, and often referred to as &quot;read receipts,&quot;
   &quot;acknowledgements,&quot; or &quot;receipt notifications.&quot;  The intention is to
   do this while respecting the privacy concerns that have often been
   expressed when such functions have been discussed in the past.
</t>

<t>
   Because many messages are sent between the Internet and other
   messaging systems (such as X.400 or the proprietary &quot;LAN-based&quot;
   systems), the MDN protocol is designed to be useful in a multi-
   protocol messaging environment.  To this end, the protocol described
   in this memo provides for the carriage of &quot;foreign&quot; addresses, in
   addition to those normally used in Internet Mail.  Additional
   attributes may also be defined to support &quot;tunneling&quot; of foreign
   notifications through Internet Mail.
</t>
</abstract>
</front>

<seriesInfo value="2298" name="RFC" />
<format octets="83766" type="HTML" target="http://xml.resource.org/public/rfc/html/rfc2298.html" />
<format octets="66170" type="XML" target="http://xml.resource.org/public/rfc/xml/rfc2298.xml" />
</reference>


<reference target2="reference.RFC.2299.xml" anchor="RFC2299">
<front>
<title abbrev="Summary of 2200-2299">Request for Comments Summary</title>
<author fullname="Alegre Ramos" initials="A." surname="Ramos">
<organization>University of Southern California, Information Sciences Institute</organization>

<address>
<postal>
<street>4676 Admiralty Way</street>
<city>Marina del Rey</city>
<region>CA</region>
<code>90292</code>
<country>US</country>
</postal>

<phone>+1 310 822 1511</phone>
<email>ramos@isi.edu</email>
</address>
</author>

<date year="1999" month="January" />
</front>

<seriesInfo value="2299" name="RFC" />
</reference>


<reference target2="reference.RFC.2300.xml" anchor="RFC2300">
<front>
<title abbrev="Internet Standards">INTERNET OFFICIAL PROTOCOL STANDARDS</title>
<author fullname="Jon Postel" initials="J." surname="Postel">
<organization>USC/Information Sciences Institute</organization>

<address>
<postal>
<street>4676 Admiralty Way</street>
<city>Marina del Rey</city>
<region>CA</region>
<code>90292</code>
</postal>

<phone>310-822-1511</phone>
<facsimile>310-823-6714</facsimile>
<email>Postel@ISI.EDU</email>
</address>
</author>

<date year="1998" month="May" />
<area>General</area>
<keyword>Internet Architecture Board</keyword>
<keyword>official internet protocol</keyword>

<abstract>
<t>
 A discussion of the standardization process and the RFC document
   series is presented first, followed by an explanation of the terms.
   Sections 6.2 - 6.10 contain the lists of protocols in each stage of
   standardization.  Finally are pointers to references and contacts for
   further information.
</t>

<t>

   This memo is intended to be issued every one hundred RFCs; please be
   sure the copy you are reading is current.  Current copies may be
   obtained from the Requests for Comments Editor (RFC-EDITOR) or from
   the Internet Assigned Numbers Authority (IANA) (see the contact
   information at the end of this memo).

</t>

<t>

   See Section 6.1 for a description of recent changes.  In the official
   lists in sections 6.2 - 6.10, an asterisk (*) next to a protocol
   denotes that it is new to this document or has been moved from one
   protocol level to another, or differs from the previous edition of
   this document.

</t>
</abstract>
</front>

<seriesInfo value="1" name="STD" />
<seriesInfo value="2300" name="RFC" />
<format octets="134348" type="HTML" target="http://xml.resource.org/public/rfc/html/rfc2300.html" />
<format octets="119040" type="XML" target="http://xml.resource.org/public/rfc/xml/rfc2300.xml" />
</reference>


<reference target2="reference.RFC.2301.xml" anchor="RFC2301">
<front>
<title>File Format for Internet Fax</title>
<author fullname="L. McIntyre" initials="L." surname="McIntyre">
<organization>Xerox Corporation</organization>
</author>

<author fullname="S. Zilles" initials="S." surname="Zilles">
<organization>Adobe Systems, Inc.</organization>
</author>

<author fullname="R. Buckley" initials="R." surname="Buckley">
<organization>Xerox Corporation</organization>
</author>

<author fullname="D. Venable" initials="D." surname="Venable">
<organization>Xerox Corporation</organization>
</author>

<author fullname="G. Parsons" initials="G." surname="Parsons">
<organization>Northern Telecom</organization>
</author>

<author fullname="J. Rafferty" initials="J." surname="Rafferty">
<organization>Human Communications</organization>
</author>

<date year="1998" month="March" />
<area>Applications</area>
<keyword>content-type</keyword>
<keyword>facsimile</keyword>
<keyword>multipurpose internet mail extensions</keyword>

<abstract>
<t>

   This document describes the TIFF (Tag Image File Format)

   representation of image data specified by the ITU-T Recommendations

   for black-and-white and color facsimile. This file format

   specification is commonly known as TIFF-FX. It formally defines

   minimal, extended and lossless JBIG modes (Profiles S, F, J) for

   black-and-white fax, and base JPEG, lossless JBIG and Mixed Raster

   Content modes (Profiles C, L, M) for color and grayscale fax. These

   modes or profiles correspond to the content of the applicable ITU-T

   Recommendations. Files formatted according to this specification use

   the image/tiff MIME Content Type.
</t>
</abstract>
</front>

<seriesInfo value="2301" name="RFC" />
<format octets="217344" type="HTML" target="http://xml.resource.org/public/rfc/html/rfc2301.html" />
<format octets="196648" type="XML" target="http://xml.resource.org/public/rfc/xml/rfc2301.xml" />
</reference>


<reference target2="reference.RFC.2302.xml" anchor="RFC2302">
<front>
<title abbrev="TIFF">Tag Image File Format (TIFF) - image/tiff MIME Sub-type Registration</title>
<author fullname="Glenn W. Parsons" initials="G.W." surname="Parsons">
<organization>Northern Telecom</organization>

<address>
<postal>
<street>P.O. Box 3511, Station C</street>
<street>Ottawa, ON  K1Y 4H7</street>
<country>Canada</country>
</postal>

<facsimile>+1-613-763-2697</facsimile>
<email>Glenn.Parsons@Nortel.ca</email>
</address>
</author>

<author fullname="James Rafferty" initials="J." surname="Rafferty">
<organization>Human Communications</organization>

<address>
<postal>
<street>12 Kevin Drive</street>
<city>Danbury</city>
<region>CT</region>
<code>06811-2901</code>
<country>USA</country>
</postal>

<facsimile>+1-203-746-4367</facsimile>
<email>Jrafferty@worldnet.att.net</email>
</address>
</author>

<author fullname="Stephen Zilles" initials="S." surname="Zilles">
<organization>Adobe Systems Inc.</organization>

<address>
<postal>
<street>Mailstop W14</street>
<street>345 Park Avenue</street>
<street>Voice:  +1-408-536-4766</street>
<city>San Jose</city>
<region>CA</region>
<code>95110-2704</code>
<country>USA</country>
</postal>

<email>szilles@adobe.com</email>
</address>
</author>

<date year="1998" month="March" />
<area>Applications</area>
<keyword>TIFF</keyword>
<keyword>multipurpose internet mail extensions</keyword>

<abstract>
<t>

   This document describes the registration of the MIME sub-type

   image/tiff.  The baseline encoding is defined by [TIFF].  This

   document refines an earlier sub-type registration in RFC 1528

   [TPC.INT].
</t>
</abstract>
</front>

<seriesInfo value="2302" name="RFC" />
<format octets="26037" type="HTML" target="http://xml.resource.org/public/rfc/html/rfc2302.html" />
<format octets="14956" type="XML" target="http://xml.resource.org/public/rfc/xml/rfc2302.xml" />
</reference>


<reference target2="reference.RFC.2303.xml" anchor="RFC2303">
<front>
<title abbrev="Minimal PSTN in Internet Mail">Minimal PSTN address format in Internet Mail</title>
<author fullname="C. Allocchio" initials="C." surname="Allocchio">
<organization>GARR-Italy</organization>

<address>
<postal>
<street>Sincrotrone Trieste</street>
<street>SS 14 Km 163.5 Basovizza</street>
<city>Trieste</city>
<code>I 34012</code>
<country>Italy</country>
</postal>

<phone>+39 40 3758523</phone>
<facsimile>+39 40 3758565</facsimile>
<email>Claudio.Allocchio@elettra.trieste.it</email>
</address>
</author>

<date year="1998" month="March" />
<area>Applications</area>
<keyword>mail</keyword>

<note title="IESG Note">
<t>
   This memo describes a simple method of encoding PSTN addresses in the

   local-part of Internet email addresses, along with an extension

   mechanism to allow encoding of additional standard attributes needed

   for email gateways to PSTN-based services.
</t>

<t>


   As with all Internet mail addresses, the left-hand-side (local- part)

   of an address generated according to this specification, is not to be

   interpreted except by the MTA that is named on the right-hand-side

   (domain).
</t>
</note>
</front>

<seriesInfo value="2303" name="RFC" />
<format octets="23676" type="HTML" target="http://xml.resource.org/public/rfc/html/rfc2303.html" />
<format octets="16200" type="XML" target="http://xml.resource.org/public/rfc/xml/rfc2303.xml" />
</reference>


<reference target2="reference.RFC.2304.xml" anchor="RFC2304">
<front>
<title abbrev="Minimal FAX address format">Minimal FAX address format in Internet Mail</title>
<author fullname="C. Allocchio" initials="C." surname="Allocchio">
<organization>GARR-Italy</organization>

<address>
<postal>
<street>Sincrotrone Trieste</street>
<street>SS 14 Km 163.5 Basovizza</street>
<city>Trieste</city>
<code>I 34012</code>
<country>Italy</country>
</postal>

<phone>+39 40 3758523</phone>
<facsimile>+39 40 3758565</facsimile>
<email>Claudio.Allocchio@elettra.trieste.it</email>
</address>
</author>

<date year="1998" month="March" />
<area>Applications</area>
<keyword>facsimile</keyword>
<keyword>mail</keyword>

<note title="IESG Note">
<t>
   This memo describes a simple method of encoding PSTN addresses of

   facsimile devices in the local-part of Internet email addresses.

</t>

<t>

   As with all Internet mail addresses, the left-hand-side (local- part)

   of an address generated according to this specification, is not to be

   interpreted except by the MTA that is named on the right-hand-side

   (domain).

</t>
</note>
</front>

<seriesInfo value="2304" name="RFC" />
<format octets="22309" type="HTML" target="http://xml.resource.org/public/rfc/html/rfc2304.html" />
<format octets="14696" type="XML" target="http://xml.resource.org/public/rfc/xml/rfc2304.xml" />
</reference>


<reference target2="reference.RFC.2305.xml" anchor="RFC2305">
<front>
<title abbrev="Simple Mode of Facsimile">A Simple Mode of Facsimile Using Internet Mail</title>
<author fullname="Kiyoshi Toyoda" initials="K." surname="Toyoda">
<organization>Matsushita Graphic Communication Systems, Inc.</organization>

<address>
<postal>
<street>2-3-8 Shimomeguro, Meguro-ku</street>
<street>Tokyo 153 Japan</street>
</postal>

<email>ktoyoda@rdmg.mgcs.mei.co.jp</email>
</address>
</author>

<author fullname="Hiroyuki Ohno" initials="H." surname="Ohno">
<organization>Tokyo Institute of Technology</organization>

<address>
<postal>
<street>2-12-1 O-okayama, Meguro-ku</street>
<street>Tokyo 152 Japan</street>
</postal>

<email>hohno@is.titech.ac.jp</email>
</address>
</author>

<author fullname="Jun Murai" initials="J." surname="Murai">
<organization>Keio University</organization>

<address>
<postal>
<street>5322 Endo, Fujisawa</street>
<street>Kanagawa 252 Japan</street>
</postal>

<email>jun@wide.ad.jp</email>
</address>
</author>

<author fullname="Dan Wing" initials="D." surname="Wing">
<organization>Cisco Systems, Inc.</organization>

<address>
<postal>
<street>101 Cooper Street</street>
<city>Santa Cruz</city>
<region>CA</region>
<code>95060</code>
</postal>

<facsimile>+1 408 457 5208</facsimile>
<email>dwing@cisco.com</email>
</address>
</author>

<date year="1998" month="March" />
<area>Applications</area>
<keyword>facsimile</keyword>
<keyword>mail</keyword>
<keyword>multipurpose internet mail extensions</keyword>

<abstract>
<t>

   This specification provides for "simple mode" carriage of facsimile

   data over the Internet.  Extensions to this document will follow.

   The current specification employs standard protocols and file formats

   such as TCP/IP, Internet mail protocols [1, 2, 3], MIME [4, 16, 17],

   and TIFF for Facsimile [5,6,19].  It can send images not only to

   other Internet-aware facsimile devices but also to Internet-native

   systems, such as PCs with common email readers which can handle MIME

   mail and TIFF for Facsimile data.  The specification facilitates

   communication among existing facsimile devices, Internet mail agents,

   and the gateways which connect them.
</t>

<t>



   The key words "MUST", "SHOULD", "SHOULD NOT", and "MAY" in this

   document are to be interpreted as described in [7].
</t>
</abstract>
</front>

<seriesInfo value="2305" name="RFC" />
<format octets="36040" type="HTML" target="http://xml.resource.org/public/rfc/html/rfc2305.html" />
<format octets="28135" type="XML" target="http://xml.resource.org/public/rfc/xml/rfc2305.xml" />
</reference>


<reference target2="reference.RFC.2306.xml" anchor="RFC2306">
<front>
<title abbrev="TIFF-F Profile">Tag Image File Format (TIFF) - F Profile for Facsimile</title>
<author fullname="Glenn W. Parsons" initials="G.W." surname="Parsons">
<organization>Northern Telecom</organization>

<address>
<postal>
<street>P.O. Box 3511, Station C</street>
<street>Ottawa, ON  K1Y 4H7</street>
<country>Canada</country>
</postal>

<facsimile>+1-613-763-2697</facsimile>
<email>Glenn.Parsons@Nortel.ca</email>
</address>
</author>

<author fullname="James Rafferty" initials="J." surname="Rafferty">
<organization>Human Communications</organization>

<address>
<postal>
<street>12 Kevin Drive</street>
<city>Danbury</city>
<region>CT</region>
<code>06811-2901</code>
<country>USA</country>
</postal>

<facsimile>+1-203-746-4367</facsimile>
<email>Jrafferty@worldnet.att.net</email>
</address>
</author>

<date year="1998" month="March" />
<area>Applications</area>
<keyword>facsimile</keyword>
<keyword>TIFF</keyword>

<abstract>
<t>

   This document references the Tag Image File Format (TIFF) to define

   the F profile of TIFF for facsimile (TIFF-F) as a file format that

   may be used for the storage and interchange of facsimile images.
</t>
</abstract>
</front>

<seriesInfo value="2306" name="RFC" />
<format octets="67324" type="HTML" target="http://xml.resource.org/public/rfc/html/rfc2306.html" />
<format octets="60856" type="XML" target="http://xml.resource.org/public/rfc/xml/rfc2306.xml" />
</reference>


<reference target2="reference.RFC.2307.xml" anchor="RFC2307">
<front>
<title abbrev="Using LDAP as a Network Information Service">An Approach for Using LDAP as a Network Information Service</title>
<author fullname="Luke Howard" initials="L." surname="Howard">
<organization>PO Box 59</organization>

<address>
<postal>
<street>Central Park Vic 3145</street>
<country>Australia</country>
</postal>

<email>lukeh@xedoc.com</email>
</address>
</author>

<date year="1998" month="March" />
<area>Applications</area>
<keyword>ITU directory service protocol</keyword>
<keyword>lightweight directory access protocol</keyword>

<abstract>
<t>

   This document describes an experimental mechanism for mapping

   entities related to TCP/IP and the UNIX system into X.500 [X500]

   entries so that they may be resolved with the Lightweight Directory

   Access Protocol [RFC2251]. A set of attribute types and object

   classes are proposed, along with specific guidelines for interpreting

   them.
</t>

<t>


   The intention is to assist the deployment of LDAP as an

   organizational nameservice. No proposed solutions 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. The

   proposed mechanism has already been implemented with some success.
</t>
</abstract>
</front>

<seriesInfo value="2307" name="RFC" />
<format octets="47890" type="HTML" target="http://xml.resource.org/public/rfc/html/rfc2307.html" />
<format octets="42519" type="XML" target="http://xml.resource.org/public/rfc/xml/rfc2307.xml" />
</reference>


<reference target2="reference.RFC.2308.xml" anchor="RFC2308">
<front>
<title abbrev="DNS NCACHE">Negative Caching of DNS Queries (DNS NCACHE)</title>
<author fullname="Mark Andrews" initials="M." surname="Andrews">
<organization>CSIRO - Mathematical and Information Sciences</organization>

<address>
<postal>
<street>Locked Bag 17</street>
<street>North Ryde NSW 2113</street>
<country>AUSTRALIA</country>
</postal>

<phone>+61 2 9325 3148</phone>
<email>Mark.Andrews@cmis.csiro.au</email>
</address>
</author>

<date year="1998" month="March" />
<area>Applications</area>
<keyword>domain name system</keyword>
<keyword>DNS</keyword>

<abstract>
<t>

   [RFC1034] provided a description of how to cache negative responses.

   It however had a fundamental flaw in that it did not allow a name

   server to hand out those cached responses to other resolvers, thereby

   greatly reducing the effect of the caching.  This document addresses

   issues raise in the light of experience and replaces [RFC1034 Section

   4.3.4].
</t>

<t>



   Negative caching was an optional part of the DNS specification and

   deals with the caching of the non-existence of an RRset [RFC2181] or

   domain name.

</t>

<t>


   Negative caching is useful as it reduces the response time for

   negative answers.  It also reduces the number of messages that have

   to be sent between resolvers and name servers hence overall network

   traffic.  A large proportion of DNS traffic on the Internet could be

   eliminated if all resolvers implemented negative caching.  With this

   in mind negative caching should no longer be seen as an optional part

   of a DNS resolver.
</t>
</abstract>
</front>

<seriesInfo value="2308" name="RFC" />
<format octets="50045" type="HTML" target="http://xml.resource.org/public/rfc/html/rfc2308.html" />
<format octets="41355" type="XML" target="http://xml.resource.org/public/rfc/xml/rfc2308.xml" />
</reference>


<reference target2="reference.RFC.2309.xml" anchor="RFC2309">
<front>
<title abbrev="Internet Performance Recommendations">Recommendations on Queue Management and Congestion Avoidance in the Internet</title>
<author fullname="Bob Braden" initials="B." surname="Braden">
<organization>USC Information Sciences Institute</organization>

<address>
<postal>
<street>4676 Admiralty Way</street>
<city>Marina del Rey</city>
<region>CA</region>
<code>90292</code>
</postal>

<phone>310-822-1511</phone>
<email>Braden@ISI.EDU</email>
</address>
</author>

<author fullname="David D. Clark" initials="D.D." surname="Clark">
<organization>MIT Laboratory for Computer Science</organization>

<address>
<postal>
<street>545 Technology Sq.</street>
<city>Cambridge</city>
<region>MA</region>
<code>02139</code>
</postal>

<phone>617-253-6003</phone>
<email>DDC@lcs.mit.edu</email>
</address>
</author>

<author fullname="Jon Crowcroft" initials="J." surname="Crowcroft">
<organization>University College London</organization>

<address>
<postal>
<street>Department of Computer Science</street>
<street>Gower Street</street>
<street>London, WC1E 6BT</street>
<street>ENGLAND</street>
</postal>

<phone>+44 171 380 7296</phone>
<email>Jon.Crowcroft@cs.ucl.ac.uk</email>
</address>
</author>

<author fullname="Bruce Davie" initials="B." surname="Davie">
<organization>Cisco Systems, Inc.</organization>

<address>
<postal>
<street>250 Apollo Drive</street>
<city>Chelmsford</city>
<region>MA</region>
<code>01824</code>
</postal>

<email>bdavie@cisco.com</email>
</address>
</author>

<author fullname="Steve Deering" initials="S." surname="Deering">
<organization>Cisco Systems, Inc.</organization>

<address>
<postal>
<street>170 West Tasman Drive</street>
<city>San Jose</city>
<region>CA</region>
<code>95134-1706</code>
</postal>

<phone>408-527-8213</phone>
<email>deering@cisco.com</email>
</address>
</author>

<author fullname="Deborah Estrin" initials="D." surname="Estrin">
<organization>USC Information Sciences Institute</organization>

<address>
<postal>
<street>4676 Admiralty Way</street>
<city>Marina del Rey</city>
<region>CA</region>
<code>90292</code>
</postal>

<phone>310-822-1511</phone>
<email>Estrin@usc.edu</email>
</address>
</author>

<author fullname="Sally Floyd" initials="S." surname="Floyd">
<organization>Lawrence Berkeley National Laboratory, MS 50B-2239, One Cyclotron Road, Berkeley CA 94720</organization>

<address>
<phone>510-486-7518</phone>
<email>Floyd@ee.lbl.gov</email>
</address>
</author>

<author fullname="Van Jacobson" initials="V." surname="Jacobson">
<organization>Lawrence Berkeley National Laboratory, MS 46A, One Cyclotron Road, Berkeley CA 94720</organization>

<address>
<phone>510-486-7519</phone>
<email>Van@ee.lbl.gov</email>
</address>
</author>

<author fullname="Greg Minshall" initials="G." surname="Minshall">
<organization>Fiberlane Communications</organization>

<address>
<postal>
<street>1399 Charleston Road</street>
<city>Mountain View</city>
<region>CA</region>
<code>94043</code>
</postal>

<phone>+1 650 237 3164</phone>
<email>Minshall@fiberlane.com</email>
</address>
</author>

<author fullname="Craig Partridge" initials="C." surname="Partridge">
<organization>BBN Technologies</organization>

<address>
<postal>
<street>10 Moulton St.</street>
<street>Cambridge MA 02138</street>
</postal>

<phone>510-558-8675</phone>
<email>craig@bbn.com</email>
</address>
</author>

<author fullname="Larry Peterson" initials="L." surname="Peterson">
<organization>Department of Computer Science</organization>

<address>
<postal>
<street>University of Arizona</street>
<city>Tucson</city>
<region>AZ</region>
<code>85721</code>
</postal>

<phone>520-621-4231</phone>
<email>LLP@cs.arizona.edu</email>
</address>
</author>

<author fullname="K.K. Ramakrishnan" initials="K.K." surname="Ramakrishnan">
<organization>AT&amp;T Labs. Research</organization>

<address>
<postal>
<street>Rm. A155</street>
<street>180 Park Avenue</street>
<street>Florham Park, N.J. 07932</street>
</postal>

<phone>973-360-8766</phone>
<email>KKRama@research.att.com</email>
</address>
</author>

<author fullname="Scott Shenker" initials="S." surname="Shenker">
<organization>Xerox PARC</organization>

<address>
<postal>
<street>3333 Coyote Hill Road</street>
<city>Palo Alto</city>
<region>CA</region>
<code>94304</code>
</postal>

<phone>415-812-4840</phone>
<email>Shenker@parc.xerox.com</email>
</address>
</author>

<author fullname="John Wroclawski" initials="J." surname="Wroclawski">
<organization>MIT Laboratory for Computer Science</organization>

<address>
<postal>
<street>545 Technology Sq.</street>
<city>Cambridge</city>
<region>MA</region>
<code>02139</code>
</postal>

<phone>617-253-7885</phone>
<email>JTW@lcs.mit.edu</email>
</address>
</author>

<author fullname="Lixia Zhang" initials="L." surname="Zhang">
<organization>UCLA</organization>

<address>
<postal>
<street>4531G Boelter Hall</street>
<city>Los Angeles</city>
<region>CA</region>
<code>90024</code>
</postal>

<phone>310-825-2695</phone>
<email>Lixia@cs.ucla.edu</email>
</address>
</author>

<date year="1998" month="April" />
<area>Routing</area>
<keyword>congestion</keyword>

<abstract>
<t>

      This memo presents two recommendations to the Internet community

      concerning measures to improve and preserve Internet performance.

      It presents a strong recommendation for testing, standardization,

      and widespread deployment of active queue management in routers,

      to improve the performance of today's Internet.  It also urges a

      concerted effort of research, measurement, and ultimate deployment

      of router mechanisms to protect the Internet from flows that are

      not sufficiently responsive to congestion notification.
</t>
</abstract>
</front>

<seriesInfo value="2309" name="RFC" />
<format octets="54015" type="HTML" target="http://xml.resource.org/public/rfc/html/rfc2309.html" />
<format octets="42381" type="XML" target="http://xml.resource.org/public/rfc/xml/rfc2309.xml" />
</reference>


<reference target2="reference.RFC.2310.xml" anchor="RFC2310">
<front>
<title>The Safe Response Header Field</title>
<author fullname="Koen Holtman" initials="K." surname="Holtman">
<organization>Technische Universiteit Eindhoven</organization>

<address>
<postal>
<street>Postbus 513</street>
<street>Kamer HG 6.57</street>
<street>5600 MB Eindhoven (The Netherlands)</street>
</postal>

<email>koen@win.tue.nl</email>
</address>
</author>

<date year="1998" month="April" />
<area>Applications</area>
<keyword>hypertext transfer protocol</keyword>
<keyword>HTTP</keyword>

<abstract>
<t>

   This document defines a HTTP response header field called Safe, which

   can be used to indicate that repeating a HTTP request is safe.  Such

   an indication will allow user agents to handle retries of some safe

   requests, in particular safe POST requests, in a more user-friendly

   way.
</t>
</abstract>
</front>

<seriesInfo value="2310" name="RFC" />
<format octets="14227" type="HTML" target="http://xml.resource.org/public/rfc/html/rfc2310.html" />
<format octets="7812" type="XML" target="http://xml.resource.org/public/rfc/xml/rfc2310.xml" />
</reference>


<reference target2="reference.RFC.2311.xml" anchor="RFC2311">
<front>
<title>S/MIME Version 2 Message Specification</title>
<author fullname="Steve Dusse" initials="S." surname="Dusse">
<organization>RSA Data Security, Inc.</organization>

<address>
<postal>
<street>100 Marine Parkway, #500</street>
<city>Redwood City</city>
<region>CA</region>
<code>94065</code>
</postal>

<phone>(415) 595-8782</phone>
<email>spock@rsa.com</email>
</address>
</author>

<author fullname="Paul Hoffman" initials="P." surname="Hoffman">
<organization>Internet Mail Consortium</organization>

<address>
<postal>
<street>127 Segre Place</street>
<city>Santa Cruz</city>
<region>CA</region>
<code>95060</code>
</postal>

<phone>(408) 426-9827</phone>
<email>phoffman@imc.org</email>
</address>
</author>

<author fullname="Blake Ramsdell" initials="B." surname="Ramsdell">
<organization>Worldtalk</organization>

<address>
<postal>
<street>13122 NE 20th St., Suite C</street>
<city>Bellevue</city>
<region>WA</region>
<code>98005</code>
</postal>

<phone>(425) 882-8861</phone>
<email>blaker@deming.com</email>
</address>
</author>

<author fullname="Laurence Lundblade" initials="L." surname="Lundblade">
<organization>QUALCOMM Incorporated</organization>

<address>
<postal>
<street>Eudora Division</street>
<street>6455 Lusk Boulevard</street>
<city>San Diego</city>
<region>California</region>
<code>92121-2779</code>
</postal>

<phone>(800) 238-3672</phone>
<email>lgl@qualcomm.com</email>
</address>
</author>

<author fullname="Lisa Repka" initials="L." surname="Repka">
<organization>Netscape Communications Corporation</organization>

<address>
<postal>
<street>501 East Middlefield Road</street>
<city>Mountain View</city>
<region>CA</region>
<code>94043</code>
</postal>

<phone>(415) 254-1900</phone>
<email>repka@netscape.com</email>
</address>
</author>

<date year="1998" month="March" />
<area>Security</area>
<area>Applications</area>
<keyword>authentication</keyword>
<keyword>cryptographic</keyword>
<keyword>digital signature</keyword>
<keyword>encryption</keyword>
<keyword>multipurpose internet mail extensions</keyword>
<keyword>security</keyword>
</front>

<seriesInfo value="2311" name="RFC" />
<format octets="80984" type="HTML" target="http://xml.resource.org/public/rfc/html/rfc2311.html" />
<format octets="71356" type="XML" target="http://xml.resource.org/public/rfc/xml/rfc2311.xml" />
</reference>


<reference target2="reference.RFC.2312.xml" anchor="RFC2312">
<front>
<title>S/MIME Version 2 Certificate Handling</title>
<author fullname="Steve Dusse" initials="S." surname="Dusse">
<organization>RSA Data Security, Inc.</organization>

<address>
<postal>
<street>100 Marine Parkway, #500</street>
<city>Redwood City</city>
<region>CA</region>
<code>94065</code>
</postal>

<phone>(415) 595-8782</phone>
<email>spock@rsa.com</email>
</address>
</author>

<author fullname="Paul Hoffman" initials="P." surname="Hoffman">
<organization>Internet Mail Consortium</organization>

<address>
<postal>
<street>127 Segre Place</street>
<city>Santa Cruz</city>
<region>CA</region>
<code>95060</code>
</postal>

<phone>(408) 426-9827</phone>
<email>phoffman@imc.org</email>
</address>
</author>

<author fullname="Blake Ramsdell" initials="B." surname="Ramsdell">
<organization>Worldtalk</organization>

<address>
<postal>
<street>13122 NE 20th St., Suite C</street>
<city>Bellevue</city>
<region>WA</region>
<code>98005</code>
</postal>

<phone>(425) 882-8861</phone>
<email>blaker@deming.com</email>
</address>
</author>

<author fullname="Jeff Weinstein" initials="J." surname="Weinstein">
<organization>Netscape Communications Corporation</organization>

<address>
<postal>
<street>501 East Middlefield Road</street>
<city>Mountain View</city>
<region>CA</region>
<code>94043</code>
</postal>

<phone>(415) 254-1900</phone>
<email>jsw@netscape.com</email>
</address>
</author>

<date year="1998" month="March" />
<area>Applications</area>
<keyword>multipurpose internet mail extensions</keyword>
<keyword>MIME</keyword>
</front>

<seriesInfo value="2312" name="RFC" />
<format octets="48239" type="HTML" target="http://xml.resource.org/public/rfc/html/rfc2312.html" />
<format octets="39204" type="XML" target="http://xml.resource.org/public/rfc/xml/rfc2312.xml" />
</reference>


<reference target2="reference.RFC.2313.xml" anchor="RFC2313">
<front>
<title abbrev="PKCS #1: RSA Encryption">PKCS #1: RSA Encryption Version 1.5</title>
<author fullname="Burt Kaliski" initials="B." surname="Kaliski">
<organization>RSA Laboratories East</organization>

<address>
<postal>
<street>20 Crosby Drive</street>
<city>Bedford</city>
<region>MA</region>
<code>01730</code>
</postal>

<phone>(617) 687-7000</phone>
<email>burt@rsa.com</email>
</address>
</author>

<date year="1998" month="March" />
<area>Security</area>
<keyword>encryption</keyword>
<keyword>public key cryptography standards</keyword>
<keyword>public key encryption</keyword>
</front>

<seriesInfo value="2313" name="RFC" />
<format octets="44529" type="HTML" target="http://xml.resource.org/public/rfc/html/rfc2313.html" />
<format octets="35985" type="XML" target="http://xml.resource.org/public/rfc/xml/rfc2313.xml" />
</reference>


<reference target2="reference.RFC.2314.xml" anchor="RFC2314">
<front>
<title abbrev="PKCS #10: Certification Request Syntax">PKCS #10: Certification Request Syntax Version 1.5</title>
<author fullname="Burt Kaliski" initials="B." surname="Kaliski">
<organization>RSA Laboratories East</organization>

<address>
<postal>
<street>20 Crosby Drive</street>
<city>Bedford</city>
<region>MA</region>
<code>01730</code>
</postal>

<phone>(617) 687-7000</phone>
<email>burt@rsa.com</email>
</address>
</author>

<date year="1998" month="March" />
<area>Security</area>
<keyword>public key cryptography standards</keyword>
</front>

<seriesInfo value="2314" name="RFC" />
<format octets="9111" type="HTML" target="http://xml.resource.org/public/rfc/html/rfc2314.html" />
<format octets="2254" type="XML" target="http://xml.resource.org/public/rfc/xml/rfc2314.xml" />
</reference>


<reference target2="reference.RFC.2315.xml" anchor="RFC2315">
<front>
<title abbrev="PKCS #7: Crytographic Message Syntax">PKCS #7: Cryptographic Message Syntax Version 1.5</title>
<author fullname="Burt Kaliski" initials="B." surname="Kaliski">
<organization>RSA Laboratories East</organization>

<address>
<postal>
<street>20 Crosby Drive</street>
<city>Bedford</city>
<region>MA</region>
<code>01730</code>
</postal>

<phone>(617) 687-7000</phone>
<email>burt@rsa.com</email>
</address>
</author>

<date year="1998" month="March" />
<area>Security</area>
<keyword>authentication</keyword>
<keyword>cryptographic</keyword>
<keyword>digital signature</keyword>
<keyword>public key cryptography standards</keyword>
</front>

<seriesInfo value="2315" name="RFC" />
<format octets="75615" type="HTML" target="http://xml.resource.org/public/rfc/html/rfc2315.html" />
<format octets="67065" type="XML" target="http://xml.resource.org/public/rfc/xml/rfc2315.xml" />
</reference>


<reference target2="reference.RFC.2316.xml" anchor="RFC2316">
<front>
<title abbrev="Report of the IAB">Report of the IAB Security Architecture Workshop</title>
<author fullname="Steven M. Bellovin" initials="S.M." surname="Bellovin">
<organization>AT&amp;T Labs Research</organization>

<address>
<postal>
<street>180 Park Avenue</street>
<city>Florham Park</city>
<region>NJ</region>
<code>07932</code>
<country>USA</country>
</postal>

<phone>(973) 360-8656</phone>
<email>bellovin@acm.org</email>
</address>
</author>

<date year="1998" month="April" />
<area>Security</area>
<keyword>Internet Architecture Board</keyword>
<keyword>security</keyword>
<keyword>workshop</keyword>

<abstract>
<t>
   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.
</t>
</abstract>
</front>

<seriesInfo value="2316" name="RFC" />
<format octets="28398" type="HTML" target="http://xml.resource.org/public/rfc/html/rfc2316.html" />
<format octets="21959" type="XML" target="http://xml.resource.org/public/rfc/xml/rfc2316.xml" />
</reference>


<reference target2="reference.RFC.2317.xml" anchor="RFC2317">
<front>
<title>Classless IN-ADDR.ARPA delegation</title>
<author fullname="Havard Eidnes" initials="H." surname="Eidnes">
<organization>SINTEF RUNIT</organization>

<address>
<postal>
<street>N-7034 Trondheim</street>
<country>Norway</country>
</postal>

<phone>+47 73 59 44 68</phone>
<facsimile>+47 73 59 17 00</facsimile>
<email>Havard.Eidnes@runit.sintef.no</email>
</address>
</author>

<author fullname="G. de Groot" initials="G." surname="de Groot">
<organization>Software Design, Inc.</organization>
</author>

<author fullname="Paul Vixie" initials="P." surname="Vixie">
<organization>Internet Software Consortium</organization>
</author>

<date year="1998" month="March" />
<area>Internet</area>
<keyword>IN-ADDR.ARPA</keyword>
<keyword>Advanced Research Projects Agency</keyword>
<keyword>Defense Advanced Research Projects Agency</keyword>
</front>

<seriesInfo value="20" name="BCP" />
<seriesInfo value="2317" name="RFC" />
<format octets="24130" type="HTML" target="http://xml.resource.org/public/rfc/html/rfc2317.html" />
<format octets="16950" type="XML" target="http://xml.resource.org/public/rfc/xml/rfc2317.xml" />
</reference>


<reference target2="reference.RFC.2318.xml" anchor="RFC2318">
<front>
<title abbrev="text/css Media Type">The text/css Media Type</title>
<author fullname="Hakon Lie" initials="H." surname="Lie">
<organization>W3C/INRIA</organization>

<address>
<postal>
<street>2004, route des Lucioles - B.P. 93</street>
<street>06902 Sophia Antipolis Cedex</street>
<country>FRANCE</country>
</postal>

<phone>+33 (0)492387771</phone>
<facsimile>+33 (0)493657765</facsimile>
<email>howcome@w3.org</email>
</address>
</author>

<author fullname="Bert Bos" initials="B." surname="Bos">
<organization />

<address>
<postal>
<street>2004, route des Lucioles - B.P. 93</street>
<street>06902 Sophia Antipolis Cedex</street>
<country>FRANCE</country>
</postal>

<phone>+33 (0)492387692</phone>
<facsimile>+33 (0)493657765</facsimile>
<email>bert@w3.org</email>
</address>
</author>

<author fullname="Chris Lilley" initials="C." surname="Lilley">
<organization />

<address>
<postal>
<street>2004, route des Lucioles - B.P. 93</street>
<street>06902 Sophia Antipolis Cedex</street>
<country>FRANCE</country>
</postal>

<phone>+33 (0)492387987</phone>
<facsimile>+33 (0)493657765</facsimile>
<email>chris@w3.org</email>
</address>
</author>

<date year="1998" month="March" />
<area>Applications</area>
<keyword>CSS</keyword>
<keyword>media type</keyword>
<keyword>world wide web</keyword>

<abstract>
<t>

   Cascading Style Sheets (CSS) is a style sheet language for the World

   Wide Web. CSS style sheets have been in use since October 1995 using

   the Media Type text/css without registration; this memo seeks to

   regularize that position.
</t>
</abstract>
</front>

<seriesInfo value="2318" name="RFC" />
<format octets="15253" type="HTML" target="http://xml.resource.org/public/rfc/html/rfc2318.html" />
<format octets="7750" type="XML" target="http://xml.resource.org/public/rfc/xml/rfc2318.xml" />
</reference>


<reference target2="reference.RFC.2319.xml" anchor="RFC2319">
<front>
<title>Ukrainian Character Set KOI8-U</title>
<author>
<organization>
KOI8-U Working Group
</organization>
</author>

<date year="1998" month="April" />
<area>Applications</area>
<keyword>character encoding</keyword>
<keyword>KOI8</keyword>
<keyword>Ukranian</keyword>

<abstract>
<t>
   This document provides information about character encoding KOI8-U

   (KOI8 Ukrainian) wich is a de-facto standard in Ukrainian Internet

   community.  KOI8-U is compatible with KOI8-R (RFC 1489) in all

   Russian letters and extends it with four Ukrainian letters which

   locations are compliant with ISO-IR-111.  The official site of KOI8-U

   Working Group is http://www.net.ua.

</t>
</abstract>
</front>

<seriesInfo value="2319" name="RFC" />
<format octets="23256" type="HTML" target="http://xml.resource.org/public/rfc/html/rfc2319.html" />
<format octets="16670" type="XML" target="http://xml.resource.org/public/rfc/xml/rfc2319.xml" />
</reference>


<reference target2="reference.RFC.2320.xml" anchor="RFC2320">
<front>
<title abbrev="IP and ARP over ATM (IPOA) MIB">Definitions of Managed Objects for Classical IP and ARP Over ATM Using SMIv2 (IPOA-MIB)</title>
<author fullname="Maria N. Greene" initials="M.N." surname="Greene">
<organization>Xedia Corp.</organization>

<address>
<postal>
<street>119 Russell Dr.</street>
<street>James Luciani</street>
<street>Bay Networks, Inc.</street>
<street>3 Federal St., BL3-04</street>
<city>Billerica</city>
<region>MA</region>
<code>01821</code>
</postal>

<email>luciani@baynetworks.com</email>
</address>
</author>

<author fullname="Kenneth D. White" initials="K.D." surname="White">
<organization>Dept. G80/Bldg 503</organization>

<address>
<postal>
<street>IBM Corporation</street>
<street>Ted T.I. Kuo</street>
<street>Bay Networks, Inc.</street>
<street>4401 Great America Parkway</street>
<city>Santa Clara</city>
<region>CA</region>
<code>95052-8185</code>
</postal>

<facsimile>+1-408-495-1905</facsimile>
<email>ted_kuo@Baynetworks.com</email>
</address>
</author>

<date year="1998" month="April" />
<area>Internet</area>
<area>Management</area>
<keyword>Management Information Base</keyword>
<keyword>address resolution protocol</keyword>
<keyword>asynchronous transfer mode</keyword>
<keyword>managed object</keyword>
<keyword>structure of management information version 2</keyword>

<abstract>
<t>

  The purpose of this memo is to define the Management Information Base

  (MIB) for supporting Classical IP and ARP over ATM as specified in

  Classical IP and ARP over ATM, refer to reference [3].  Support of an

  ATM interface by an IP layer will require implementation of objects

  from several Management Information Bases (MIBs) as well as their

  enhancement in order to enable usage of ATM transports.  It is the

  intent of this MIB to fully adhere to all prerequisite MIBs unless

  explicitly stated.  Deviations will be documented in corresponding

  conformance statements.  The specification of this MIB will utilize

  the Structure of Management Information (SMI) for Version 2 of the

  Simple Network Management Protocol Version (refer to RFC 1902,

  reference [1]).

</t>
</abstract>
</front>

<seriesInfo value="2320" name="RFC" />
<format octets="112528" type="HTML" target="http://xml.resource.org/public/rfc/html/rfc2320.html" />
<format octets="100961" type="XML" target="http://xml.resource.org/public/rfc/xml/rfc2320.xml" />
</reference>


<reference target2="reference.RFC.2321.xml" anchor="RFC2321">
<front>
<title abbrev="RITA                      1">RITA -- The Reliable Internetwork Troubleshooting Agent</title>
<author fullname="Andrew K. Bressen" initials="A.K." surname="Bressen">
<organization />

<address>
<postal>
<street>72 Endicott Street</street>
<city>Somerville</city>
<region>MA</region>
</postal>

<phone>617-776-2373</phone>
<email>bressen@leftbank.com,</email>
</address>
</author>

<date year="1998" day="1" month="April" />
<area>Operations</area>
<keyword>agent</keyword>

<abstract>
<t>

   A Description of the usage of Nondeterministic Troubleshooting and

   Diagnostic Methodologies as applied to today's complex

   nondeterministic networks and environments.
</t>
</abstract>
</front>

<seriesInfo value="2321" name="RFC" />
<format octets="18189" type="HTML" target="http://xml.resource.org/public/rfc/html/rfc2321.html" />
<format octets="11655" type="XML" target="http://xml.resource.org/public/rfc/xml/rfc2321.xml" />
</reference>


<reference target2="reference.RFC.2322.xml" anchor="RFC2322">
<front>
<title abbrev="Management of IP numbers by peg-dhcp">Management of IP numbers by peg-dhcp</title>
<author fullname="K. van den Hout" initials="K." surname="van den Hout">
<organization>HvU/HIP-networkteam</organization>

<address>
<postal>
<street>3508 AA Utrecht</street>
<street>The Netherlands</street>
</postal>

<phone>+31-30-2586287</phone>
<facsimile>+31-30-2586292</facsimile>
<email>koos@cetis.hvu.nl</email>
</address>
</author>

<author fullname="Andre Koopal" initials="A." surname="Koopal">
<organization>UUnet Netherlands</organization>

<address>
<postal>
<street>P.O. box 12954</street>
<street>1100 AZ  AMSTERDAM</street>
<street>The Netherlands</street>
</postal>

<phone>+31-20-4952727</phone>
<facsimile>+31-20-4952737</facsimile>
<email>andre@NL.net</email>
</address>
</author>

<author fullname="Remco van Mook" initials="R.v." surname="Mook">
<organization>Van Mook Consulting</organization>

<address>
<postal>
<street>Calslaan 10-31</street>
<street>7522 MA Enschede</street>
<street>The Netherlands</street>
</postal>

<phone>+31-53-4895267</phone>
<email>remco@sateh.com</email>
</address>
</author>

<date year="1998" day="1" month="April" />
<area>Internet</area>
<keyword>dynamic host configuration protocol</keyword>
<keyword>DHCP</keyword>
<keyword>proxy</keyword>

<abstract>
<t>
This RFC describes a protocol to dynamically hand out ip-numbers on
   field networks and small events that don't necessarily have a clear
   organisational body.
</t>

<t>
   It can also provide some fixed additional fields global for all
   clients like netmask and even autoproxyconfigs. It does not depend on
   a particular ip-stack.
</t>
</abstract>
</front>

<seriesInfo value="2322" name="RFC" />
<format octets="19772" type="HTML" target="http://xml.resource.org/public/rfc/html/rfc2322.html" />
<format octets="11036" type="XML" target="http://xml.resource.org/public/rfc/xml/rfc2322.xml" />
</reference>


<reference target2="reference.RFC.2323.xml" anchor="RFC2323">
<front>
<title abbrev="Identification/Security Guidelines">IETF Identification and Security Guidelines</title>
<author fullname="Alegre Ramos" initials="A." surname="Ramos">
<organization>USC/ISI</organization>

<address>
<postal>
<street>4676 Admiralty Way #1001</street>
<city>Marina del Rey</city>
<region>CA</region>
<code>90292</code>
</postal>

<phone>310-822-1511 x153</phone>
<email>ramos@isi.edu</email>
</address>
</author>

<date year="1998" day="1" month="April" />
<area>General</area>
<area>Security</area>
<keyword>Internet Engineering Task Force</keyword>
<keyword>identification</keyword>
<keyword>security</keyword>

<abstract>
<t>

   This RFC is meant to represent a guideline by which the IETF

   conferences may run more effeciently with regards to identification

   and security protocols, with specific attention paid to a particular

   sub-group within the IETF: "facial hairius extremis".
</t>

<t>


   This document will shed further illumination on these problems and

   provide some possible solutions.

</t>

<t>

   This memo provides entertainment for the Internet community.  It does

   not specify an Internet standard of any kind, but is rather

   unstandard, actually.  Please laugh loud and hard.
</t>
</abstract>
</front>

<seriesInfo value="2323" name="RFC" />
<format octets="14721" type="HTML" target="http://xml.resource.org/public/rfc/html/rfc2323.html" />
<format octets="7809" type="XML" target="http://xml.resource.org/public/rfc/xml/rfc2323.xml" />
</reference>


<reference target2="reference.RFC.2324.xml" anchor="RFC2324">
<front>
<title abbrev="HTCPCP/1.0">Hyper Text Coffee Pot Control Protocol (HTCPCP/1.0)</title>
<author fullname="Larry Masinter" initials="L." surname="Masinter">
<organization>Xerox Palo Alto Research Center</organization>

<address>
<postal>
<street>3333 Coyote Hill Road</street>
<city>Palo Alto</city>
<region>CA</region>
<code>94304</code>
</postal>

<email>masinter@parc.xerox.com</email>
</address>
</author>

<date year="1998" day="1" month="April" />
<area>General</area>
<keyword>control protocol</keyword>
<keyword>coffee</keyword>

<abstract>
<t>

   This document describes HTCPCP, a protocol for controlling,

   monitoring, and diagnosing coffee pots.
</t>
</abstract>
</front>

<seriesInfo value="2324" name="RFC" />
<format octets="28160" type="HTML" target="http://xml.resource.org/public/rfc/html/rfc2324.html" />
<format octets="22434" type="XML" target="http://xml.resource.org/public/rfc/xml/rfc2324.xml" />
</reference>


<reference target2="reference.RFC.2325.xml" anchor="RFC2325">
<front>
<title abbrev="Coffee MIB">
Definitions of Managed Objects for Drip-Type Heated Beverage Hardware Devices 
using SMIv2</title>
<author fullname="Michael Slavitch" initials="M." surname="Slavitch">
<organization>Loran Technologies</organization>

<address>
<postal>
<street>955 Green Valley Crescent</street>
<street>Ottawa, Ontario Canada K2C 3V4</street>
</postal>

<phone>613 723 7505</phone>
<email>slavitch@loran.com</email>
</address>
</author>

<date year="1998" day="1" month="April" />
<area>General</area>
<area>Management</area>
<keyword>coffee</keyword>
<keyword>Management Information Base</keyword>
<keyword>managed object</keyword>
<keyword>structure of management information version 2</keyword>
</front>

<seriesInfo value="2325" name="RFC" />
<format octets="21425" type="HTML" target="http://xml.resource.org/public/rfc/html/rfc2325.html" />
<format octets="12345" type="XML" target="http://xml.resource.org/public/rfc/xml/rfc2325.xml" />
</reference>


<reference target2="reference.RFC.2326.xml" anchor="RFC2326">
<front>
<title abbrev="Real Time Streaming Protocol">Real Time Streaming Protocol (RTSP)</title>
<author fullname="Henning Schulzrinne" initials="H." surname="Schulzrinne">
<organization>Columbia University, Dept. of Computer Science</organization>

<address>
<postal>
<street>1214 Amsterdam Avenue</street>
<city>New York</city>
<region>NY</region>
<code>10027</code>
<country>US</country>
</postal>

<email>schulzrinne@cs.columbia.edu</email>
</address>
</author>

<author fullname="Anup Rao" initials="A." surname="Rao">
<organization>Netscape Communications Corp.</organization>

<address>
<postal>
<street>501 E. Middlefield Road</street>
<city>Mountain View</city>
<region>CA</region>
<code>94043</code>
<country>US</country>
</postal>

<email>anup@netscape.com</email>
</address>
</author>

<author fullname="Robert Lanphier" initials="R." surname="Lanphier">
<organization>RealNetworks</organization>

<address>
<postal>
<street>1111 Third Avenue</street>
<street>Suite 2900</street>
<city>Seattle</city>
<region>WA</region>
<code>98101</code>
<country>US</country>
</postal>

<email>robla@real.com</email>
</address>
</author>

<date year="1998" month="April" />

<abstract>
<t>The Real Time Streaming Protocol, or RTSP, is an application-level protocol for control over the delivery of data with real-time properties. RTSP provides an extensible framework to enable controlled, on-demand delivery of real-time data, such as audio and video. Sources of data can include both live data feeds and stored clips. This protocol is intended to control multiple data delivery sessions, provide a means for choosing delivery channels such as UDP, multicast UDP and TCP, and provide a means for choosing delivery mechanisms based upon RTP (RFC 1889).</t>
</abstract>
</front>

<seriesInfo value="2326" name="RFC" />
</reference>


<reference target2="reference.RFC.2327.xml" anchor="RFC2327">
<front>
<title abbrev="SDP">SDP: Session Description Protocol</title>
<author fullname="Mark Handley" initials="M." surname="Handley">
<organization>
   Information Sciences Institute
</organization>

<address>
<postal>
<street>
   c/o MIT Laboratory for Computer Science
</street>
<street>
   545 Technology Square
</street>
<city>Cambridge</city>
<region>MA</region>
<code>02139</code>
<country>US</country>
</postal>

<email>mjh@isi.edu</email>
</address>
</author>

<author fullname="Van Jacobson" initials="V." surname="Jacobson">
<organization>
   Lawrence Berkeley Laboratory
</organization>

<address>
<postal>
<street>
   MS 46a-1121
</street>
<city>Berkeley</city>
<region>CA</region>
<code>94720</code>
<country>US</country>
</postal>

<email>van@ee.lbl.gov</email>
</address>
</author>

<date year="1998" month="April" />
<area>Applications</area>
<keyword>multimedia</keyword>
<keyword>SDP</keyword>

<abstract>
<t>

   This document defines the Session Description Protocol, SDP.  SDP is

   intended for describing multimedia sessions for the purposes of

   session announcement, session invitation, and other forms of

   multimedia session initiation.
</t>

<t>


   This document is a product of the Multiparty Multimedia Session

   Control (MMUSIC) working group of the Internet Engineering Task

   Force. Comments are solicited and should be addressed to the working

   group's mailing list at confctrl@isi.edu and/or the authors.
</t>
</abstract>
</front>

<seriesInfo value="2327" name="RFC" />
<format octets="105361" type="HTML" target="http://xml.resource.org/public/rfc/html/rfc2327.html" />
<format octets="96873" type="XML" target="http://xml.resource.org/public/rfc/xml/rfc2327.xml" />
</reference>


<reference target2="reference.RFC.2328.xml" anchor="RFC2328">
<front>
<title>OSPF Version 2</title>
<author fullname="John Moy" initials="J." surname="Moy">
<organization>Ascend Communications, Inc.</organization>

<address>
<postal>
<street>1 Robbins Road</street>
<city>Westford</city>
<region>MA</region>
<code>01886</code>
</postal>

<phone>978-952-1367</phone>
<facsimile>978-392-2075</facsimile>
<email>jmoy@casc.com</email>
</address>
</author>

<date year="1998" month="April" />
<area>Routing</area>
<keyword>open shortest-path first protocol</keyword>
<keyword>routing</keyword>
<keyword>OSPF</keyword>

<abstract>
<t>

    This memo documents	version	2 of the OSPF protocol.	 OSPF is a

    link-state routing protocol.  It is	designed to be run internal to a

    single Autonomous System.  Each OSPF router	maintains an identical

    database describing	the Autonomous System's	topology.  From	this

    database, a	routing	table is calculated by constructing a shortest-

    path tree.
</t>

<t>


    OSPF recalculates routes quickly in	the face of topological	changes,

    utilizing a	minimum	of routing protocol traffic.  OSPF provides

    support for	equal-cost multipath.  An area routing capability is

    provided, enabling an additional level of routing protection and a

    reduction in routing protocol traffic.  In addition, all OSPF

    routing protocol exchanges are authenticated.

</t>

<t>

    The	differences between this memo and RFC 2178 are explained in

    Appendix G.	All differences	are backward-compatible	in nature.

    Implementations of this memo and of	RFCs 2178, 1583, and 1247 will

    interoperate.

</t>

<t>

    Please send	comments to ospf@gated.cornell.edu.
</t>
</abstract>
</front>

<seriesInfo value="54" name="STD" />
<seriesInfo value="2328" name="RFC" />
<format octets="466915" type="HTML" target="http://xml.resource.org/public/rfc/html/rfc2328.html" />
<format octets="446625" type="XML" target="http://xml.resource.org/public/rfc/xml/rfc2328.xml" />
</reference>


<reference target2="reference.RFC.2329.xml" anchor="RFC2329">
<front>
<title>OSPF Standardization Report</title>
<author fullname="John Moy" initials="J." surname="Moy">
<organization>Ascend Communications, Inc.</organization>

<address>
<postal>
<street>1 Robbins Road</street>
<city>Westford</city>
<region>MA</region>
<code>01886</code>
<country>US</country>
</postal>

<phone>+1 978 952 1367</phone>
<facsimile>+1 978 392 2075</facsimile>
<email>jmoy@casc.com</email>
</address>
</author>

<date year="1998" month="April" />

<abstract>
<t>This memo documents how the requirements for advancing a routing protocol to Full Standard, set out in, have been met for OSPFv2.</t>

<t>Please send comments to ospf@gated.cornell.edu.</t>
</abstract>
</front>

<seriesInfo value="2329" name="RFC" />
</reference>


<reference target2="reference.RFC.2330.xml" anchor="RFC2330">
<front>
<title>Framework for IP Performance Metrics</title>
<author fullname="Vern Paxson" initials="V." surname="Paxson">
<organization>MS 50B/2239</organization>

<address>
<postal>
<street>Lawrence Berkeley National Laboratory</street>
<street>University of California</street>
<city>Berkeley</city>
<region>CA</region>
<code>94720</code>
<country>USA</country>
</postal>

<phone>+1 510/486-7504</phone>
<email>vern@ee.lbl.gov</email>
</address>
</author>

<author fullname="Guy Almes" initials="G." surname="Almes">
<organization>Advanced Network &amp; Services, Inc.</organization>

<address>
<postal>
<street>200 Business Park Drive</street>
<city>Armonk</city>
<region>NY</region>
<code>10504</code>
<country>USA</country>
</postal>

<phone>+1 914/765-1120</phone>
<email>almes@advanced.org</email>
</address>
</author>

<author fullname="Jamshid Mahdavi" initials="J." surname="Mahdavi">
<organization>Pittsburgh Supercomputing Center</organization>

<address>
<postal>
<street>4400 5th Avenue</street>
<city>Pittsburgh</city>
<region>PA</region>
<code>15213</code>
<country>USA</country>
</postal>

<phone>+1 412/268-6282</phone>
<email>mahdavi@psc.edu</email>
</address>
</author>

<author fullname="Matt Mathis" initials="M." surname="Mathis">
<organization>Pittsburgh Supercomputing Center</organization>

<address>
<postal>
<street>4400 5th Avenue</street>
<city>Pittsburgh</city>
<region>PA</region>
<code>15213</code>
<country>USA</country>
</postal>

<phone>+1 412/268-3319</phone>
<email>mathis@psc.edu</email>
</address>
</author>

<date year="1998" month="May" />
<area>Internet</area>
<area>Operations</area>
<keyword>IP</keyword>
<keyword>metrics</keyword>
</front>

<seriesInfo value="2330" name="RFC" />
<format octets="108716" type="HTML" target="http://xml.resource.org/public/rfc/html/rfc2330.html" />
<format octets="92593" type="XML" target="http://xml.resource.org/public/rfc/xml/rfc2330.xml" />
</reference>


<reference target2="reference.RFC.2331.xml" anchor="RFC2331">
<front>
<title abbrev="IP over ATM Signalling - SIG 4.0 Update">ATM Signalling Support for IP over ATM - UNI Signalling 4.0 Update</title>
<author fullname="M. Maher" initials="M." surname="Maher">
<organization>UCS/ISI</organization>

<address>
<email>maher@isi.edu</email>
</address>
</author>

<date year="1998" month="April" />
<area>Internet</area>
<keyword>asynchronous transfer mode</keyword>
<keyword>ATM</keyword>

<abstract>
<t>
   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 2225 [LAUB98]

   and in RFC 2332 [LUC98].  Among the new features found in UNI

   Signalling 4.0 are Available Bit Rate signalling and traffic

   parameter negotiation.  This memo 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.
</t>

<t>


   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.

</t>

<t>

   This specification is a 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.
</t>
</abstract>
</front>

<seriesInfo value="2331" name="RFC" />
<format octets="73713" type="HTML" target="http://xml.resource.org/public/rfc/html/rfc2331.html" />
<format octets="61433" type="XML" target="http://xml.resource.org/public/rfc/xml/rfc2331.xml" />
</reference>


<reference target2="reference.RFC.2332.xml" anchor="RFC2332">
<front>
<title abbrev="NBMA NHRP">NBMA Next Hop Resolution Protocol (NHRP)</title>
<author fullname="J. Luciani" initials="J." surname="Luciani">
<organization>Bay Networks</organization>
</author>

<author fullname="D. Katz" initials="D." surname="Katz">
<organization>cisco Systems</organization>
</author>

<author fullname="D. Piscitello" initials="D." surname="Piscitello">
<organization>Core Competence, Inc.</organization>
</author>

<author fullname="B. Cole" initials="B." surname="Cole">
<organization>Juniper Networks</organization>
</author>

<author fullname="Naganand Doraswamy" initials="N." surname="Doraswamy">
<organization>Bay Networks, Inc.</organization>

<address>
<postal>
<street>3 Federal Street</street>
<street>Mail Stop: Bl3-03</street>
<city>Billerica</city>
<region>MA</region>
<code>01801</code>
</postal>

<email>naganand@baynetworks.com</email>
</address>
</author>

<date year="1998" month="April" />
<area>Routing</area>
<keyword>non-broadcast multiple access</keyword>

<abstract>
<t>

   This document describes the NBMA Next Hop Resolution Protocol (NHRP).

   NHRP can be used by a source station (host or router) connected to a

   Non-Broadcast, Multi-Access (NBMA) subnetwork to determine the

   internetworking layer address and NBMA subnetwork addresses of the

   "NBMA next hop" towards a destination station.  If the destination is

   connected to the NBMA subnetwork, then the NBMA next hop is the

   destination station itself.  Otherwise, the NBMA next hop is the

   egress router from the NBMA subnetwork that is "nearest" to the

   destination station.  NHRP is intended for use in a multiprotocol

   internetworking layer environment over NBMA subnetworks.
</t>

<t>


   Note that while this protocol was developed for use with NBMA

   subnetworks, it is possible, if not likely, that it will be applied

   to BMA subnetworks as well.  However, this usage of NHRP is for

   further study.

</t>

<t>

   This document is intended to be a functional superset of the NBMA

   Address Resolution Protocol (NARP) documented in [1].

   Operation of NHRP as a means of establishing a transit path across an

   NBMA subnetwork between two routers will be addressed in a separate

   document (see [13]).
</t>
</abstract>
</front>

<seriesInfo value="2332" name="RFC" />
<format octets="136009" type="HTML" target="http://xml.resource.org/public/rfc/html/rfc2332.html" />
<format octets="128501" type="XML" target="http://xml.resource.org/public/rfc/xml/rfc2332.xml" />
</reference>


<reference target2="reference.RFC.2333.xml" anchor="RFC2333">
<front>
<title abbrev="NHRP Protocol Applicability">NHRP Protocol Applicability Statement</title>
<author fullname="Derya H. Cansever" initials="D.H." surname="Cansever">
<organization>GTE Laboratories Inc.</organization>

<address>
<postal>
<street>40 Sylvan Rd. MS 51</street>
<street>Waltham MA 02254</street>
</postal>

<phone>+1 617 466 4086</phone>
<email>dcansever@gte.com</email>
</address>
</author>

<date year="1998" month="April" />
<area>Routing</area>
<keyword>non-broadcast multiple access</keyword>
<keyword>routing</keyword>

<abstract>
<t>
   As required by the Routing Protocol Criteria [RFC 1264], this memo

   discusses the applicability of the Next Hop Resolution Protocol

   (NHRP) in routing of IP datagrams over Non-Broadcast Multiple Access

   (NBMA) networks, such as ATM, SMDS and X.25.
</t>
</abstract>
</front>

<seriesInfo value="2333" name="RFC" />
<format octets="28455" type="HTML" target="http://xml.resource.org/public/rfc/html/rfc2333.html" />
<format octets="21034" type="XML" target="http://xml.resource.org/public/rfc/xml/rfc2333.xml" />
</reference>


<reference target2="reference.RFC.2334.xml" anchor="RFC2334">
<front>
<title abbrev="SCSP">Server Cache Synchronization Protocol (SCSP)</title>
<author fullname="James V. Luciani" initials="J.V." surname="Luciani">
<organization>Bay Networks, Inc.</organization>

<address>
<postal>
<street>3 Federal Street, BL3-03</street>
<city>Billerica</city>
<region>MA</region>
<code>01821</code>
</postal>

<phone>+1-978-916-4734</phone>
<email>luciani@baynetworks.com</email>
</address>
</author>

<author fullname="Grenville Armitage" initials="G." surname="Armitage">
<organization>Bell Labs Lucent Technologies</organization>

<address>
<postal>
<street>101 Crawfords Corner Road</street>
<city>Holmdel</city>
<region>NJ</region>
<code>07733</code>
</postal>

<phone>+1 201 829 2635</phone>
<email>gja@lucent.com</email>
</address>
</author>

<author fullname="Joel M. Halpern" initials="J.M." surname="Halpern">
<organization>Newbridge Networks Corp.</organization>

<address>
<postal>
<street>593 Herndon Parkway</street>
<city>Herndon</city>
<region>VA</region>
<code>22070-5241</code>
</postal>

<phone>+1-703-708-5954</phone>
<email>jhalpern@Newbridge.COM</email>
</address>
</author>

<author fullname="Naganand Doraswamy" initials="N." surname="Doraswamy">
<organization>Bay Networks, Inc.</organization>

<address>
<postal>
<street>3 Federal St, BL3-03</street>
<city>Billerice</city>
<region>MA</region>
<code>01821</code>
</postal>

<phone>+1-978-916-1323</phone>
<email>naganand@baynetworks.com</email>
</address>
</author>

<date year="1998" month="April" />
<area>Internet</area>
<keyword>non-broadcast multiple access</keyword>
<keyword>cache</keyword>

<abstract>
<t>
   This document describes the Server Cache Synchronization Protocol

   (SCSP) and is written in terms of SCSP's use within Non Broadcast

   Multiple Access (NBMA) networks; although, a somewhat straight

   forward usage is applicable to BMA networks.  SCSP attempts to solve

   the generalized cache synchronization/cache-replication problem for

   distributed protocol entities.  However, in this document, SCSP is

   couched in terms of the client/server paradigm in which distributed

   server entities, which are bound to a Server Group (SG) through some

   means, wish to synchronize the contents (or a portion thereof) of

   their caches which contain information about the state of clients

   being served.
</t>
</abstract>
</front>

<seriesInfo value="2334" name="RFC" />
<format octets="108734" type="HTML" target="http://xml.resource.org/public/rfc/html/rfc2334.html" />
<format octets="99303" type="XML" target="http://xml.resource.org/public/rfc/xml/rfc2334.xml" />
</reference>


<reference target2="reference.RFC.2335.xml" anchor="RFC2335">
<front>
<title abbrev="NHRP Using SCSP">A Distributed NHRP Service Using SCSP</title>
<author fullname="James V. Luciani" initials="J.V." surname="Luciani">
<organization>Bay Networks, Inc.</organization>

<address>
<postal>
<street>3 Federal Street, BL3-03</street>
<city>Billerica</city>
<region>MA</region>
<code>01821</code>
</postal>

<phone>+1-978-916-4734</phone>
<email>luciani@baynetworks.com</email>
</address>
</author>

<date year="1998" month="April" />
<area>Internet</area>
<keyword>cache</keyword>

<abstract>
<t>

   This document describes a method for distributing an NHRP service

   within a LIS [1].  This method uses the Server Cache Synchronization

   Protocol (SCSP) [2]  to synchronize the client information databases

   held by NHRP Servers (NHSs) within a LIS.
</t>
</abstract>
</front>

<seriesInfo value="2335" name="RFC" />
<format octets="22534" type="HTML" target="http://xml.resource.org/public/rfc/html/rfc2335.html" />
<format octets="14190" type="XML" target="http://xml.resource.org/public/rfc/xml/rfc2335.xml" />
</reference>


<reference target2="reference.RFC.2336.xml" anchor="RFC2336">
<front>
<title abbrev="IP and ARP over ATM to NHRP">Classical IP and ARP over ATM to NHRP Transition</title>
<author fullname="James V. Luciani" initials="J.V." surname="Luciani">
<organization>Bay Networks</organization>

<address>
<postal>
<street>3 Federal Street</street>
<street>Mail Stop: BL3-03</street>
<city>Billerica</city>
<region>MA</region>
<code>01821</code>
</postal>

<email>luciani@baynetworks.com</email>
</address>
</author>

<date year="1998" month="July" />
<area>Internet</area>
<keyword>ATM</keyword>
<keyword>NHRP</keyword>

<abstract>
<t>
   This document describes methods and procedures for the graceful

   transition from an ATMARP LIS[1] to an NHRP LIS[2] network model over

   ATM.
</t>
</abstract>
</front>

<seriesInfo value="2336" name="RFC" />
<format octets="16948" type="HTML" target="http://xml.resource.org/public/rfc/html/rfc2336.html" />
<format octets="10888" type="XML" target="http://xml.resource.org/public/rfc/xml/rfc2336.xml" />
</reference>


<reference target2="reference.RFC.2337.xml" anchor="RFC2337">
<front>
<title abbrev="IP multicast over ATM using PIM">Intra-LIS IP multicast among routers over ATM using Sparse Mode PIM</title>
<author fullname="Dino Farinacci" initials="D." surname="Farinacci">
<organization>Cisco Systems</organization>

<address>
<postal>
<street>170 Tasman Dr.</street>
<city>San Jose</city>
<region>CA</region>
<code>95134</code>
</postal>

<phone>(408) 526-4696</phone>
<email>dino@cisco.com</email>
</address>
</author>

<author fullname="David Meyer" initials="D." surname="Meyer">
<organization>Cisco Systems</organization>

<address>
<postal>
<street>170 Tasman Dr.</street>
<city>San Jose</city>
<region>CA</region>
<code>95134</code>
</postal>

<phone>(541) 687-2581</phone>
<email>dmm@cisco.com</email>
</address>
</author>

<author fullname="Yakov Rekhter" initials="Y." surname="Rekhter">
<organization>cisco Systems, Inc.</organization>

<address>
<postal>
<street>170 Tasman Dr.</street>
<city>San Jose</city>
<region>CA</region>
<code>95134</code>
</postal>

<phone>(914) 528-0090</phone>
<email>yakov@cisco.com</email>
</address>
</author>

<date year="1998" month="April" />
<area>Internet</area>
<keyword>asynchronous transfer mode</keyword>
<keyword>MARS</keyword>
<keyword>multicast</keyword>
<keyword>router</keyword>
<keyword>routing</keyword>

<abstract>
<t>
   This document describes how intra-LIS IP multicast can be efficiently

   supported among routers over ATM without using the Multicast Address

   Resolution Server (MARS). The method described here is specific to

   Sparse Mode PIM [PIM-SM], and relies on the explicit join mechanism

   inherent in PIM-SM to notify routers when they should create group

   specific point-to-multipoint VCs.
</t>
</abstract>
</front>

<seriesInfo value="2337" name="RFC" />
<format octets="25069" type="HTML" target="http://xml.resource.org/public/rfc/html/rfc2337.html" />
<format octets="18529" type="XML" target="http://xml.resource.org/public/rfc/xml/rfc2337.xml" />
</reference>


<reference target2="reference.RFC.2338.xml" anchor="RFC2338">
<front>
<title abbrev="VRRP">Virtual Router Redundancy Protocol</title>
<author fullname="S. Knight" initials="S." surname="Knight">
<organization>Ascend Communications, Inc.</organization>
</author>

<author fullname="D. Weaver" initials="D." surname="Weaver">
<organization>Ascend Communications, Inc.</organization>
</author>

<author fullname="D. Whipple" initials="D." surname="Whipple">
<organization>Microsoft, Inc.</organization>
</author>

<author fullname="R. Hinden" initials="R." surname="Hinden">
<organization>Nokia</organization>
</author>

<author fullname="D. Mitzel" initials="D." surname="Mitzel">
<organization>Nokia</organization>
</author>

<author fullname="P. Hunt" initials="P." surname="Hunt">
<organization>Nokia</organization>
</author>

<author fullname="P. Higginson" initials="P." surname="Higginson">
<organization>Digital Equipment Corp.</organization>
</author>

<author fullname="M. Shand" initials="M." surname="Shand">
<organization>Digital Equipment Corp.</organization>
</author>

<author fullname="A. Lindem" initials="A." surname="Lindem">
<organization>IBM Corporation</organization>
</author>

<date year="1998" month="April" />
<area>Routing</area>
<keyword>router</keyword>
<keyword>VRRP</keyword>
<keyword>routing</keyword>

<abstract>
<t>
   This memo defines the Virtual Router Redundancy Protocol (VRRP).

   VRRP specifies an election protocol that dynamically assigns

   responsibility for a virtual router to one of the VRRP routers on a

   LAN.  The VRRP router controlling the IP address(es) associated with

   a virtual router is called the Master, and forwards packets sent to

   these IP addresses.  The election process provides dynamic fail over

   in the forwarding responsibility should the Master become

   unavailable.  This allows any of the virtual router IP addresses on

   the LAN to be used as the default first hop router by end-hosts.  The

   advantage gained from using VRRP is a higher availability default

   path without requiring configuration of dynamic routing or router

   discovery protocols on every end-host.
</t>
</abstract>
</front>

<seriesInfo value="2338" name="RFC" />
<format octets="76964" type="HTML" target="http://xml.resource.org/public/rfc/html/rfc2338.html" />
<format octets="60230" type="XML" target="http://xml.resource.org/public/rfc/xml/rfc2338.xml" />
</reference>


<reference target2="reference.RFC.2339.xml" anchor="RFC2339">
<front>
<title abbrev="ISOC / Sun agreement on NFS">An Agreement Between the Internet Society, the IETF, and Sun Microsystems, Inc. in the matter of NFS V.4 Protocols</title>
<author>
<organization>The Internet Society</organization>
</author>

<author>
<organization>Sun Microsystems</organization>
</author>

<author fullname="Scott Bradner" initials="S." surname="Bradner">
<organization>Harvard University</organization>

<address>
<postal>
<street>1350 Mass Ave. Rm 876</street>
<city>Cambridge</city>
<region>MA</region>
<code>02138</code>
</postal>

<phone>+1 617 495 3864</phone>
<email>sob@harvard.edu</email>
</address>
</author>

<date year="1998" month="May" />
<area>Transport</area>
<keyword>Internet Engineering Task Force</keyword>
<keyword>Internet Society</keyword>
<keyword>network file system</keyword>
<keyword>NFS</keyword>

<abstract>
<t>
   This Request for Comments records an agreement between Sun

   Microsystems, Inc. and the Internet Society to permit the flow of

   Sun's Network File System specifications into the Internet Standards

   process conducted by the Internet Engineering Task Force.
</t>
</abstract>
</front>

<seriesInfo value="2339" name="RFC" />
<format octets="16496" type="HTML" target="http://xml.resource.org/public/rfc/html/rfc2339.html" />
<format octets="9106" type="XML" target="http://xml.resource.org/public/rfc/xml/rfc2339.xml" />
</reference>


<reference target2="reference.RFC.2340.xml" anchor="RFC2340">
<front>
<title abbrev="Nortel&apos;s VNS">Nortel's Virtual Network Switching (VNS) Overview</title>
<author fullname="Bilel Jamoussi" initials="B." surname="Jamoussi">
<organization>Nortel (Northern Telecom), Ltd.</organization>

<address>
<postal>
<street>PO Box 3511 Station C</street>
<street>Ottawa ON K1Y 4H7</street>
<country>Canada</country>
</postal>

<email>jamoussi@Nortel.ca</email>
</address>
</author>

<author fullname="Dwight Jamieson" initials="D." surname="Jamieson">
<organization>Nortel (Northern Telecom), Ltd.</organization>

<address>
<postal>
<street>PO Box 3511 Station C</street>
<street>Ottawa ON K1Y 4H7</street>
<country>Canada</country>
</postal>

<email>djamies@Nortel.ca</email>
</address>
</author>

<author fullname="Dan Williston" initials="D." surname="Williston">
<organization>Nortel (Northern Telecom), Ltd.</organization>

<address>
<postal>
<street>PO Box 3511 Station C</street>
<street>Ottawa ON K1Y 4H7</street>
<country>Canada</country>
</postal>

<email>danwil@Nortel.ca</email>
</address>
</author>

<author fullname="Stephen Gabe" initials="S." surname="Gabe">
<organization>Nortel (Northern Telecom), Ltd.</organization>

<address>
<postal>
<street>PO Box 3511 Station C</street>
<street>Ottawa ON K1Y 4H7</street>
<country>Canada</country>
</postal>

<email>spgabe@Nortel.ca</email>
</address>
</author>

<date year="1998" month="May" />
<area>Internet</area>
<keyword>frame relay</keyword>
<keyword>multicast</keyword>
<keyword>routing</keyword>
<keyword>security</keyword>

<abstract>
<t>
This document provides an overview of Virtual Network Switching
   (VNS).
</t>

<t>
   VNS is a multi-protocol switching architecture that provides COS-
   sensitive packet switching, reduces the complexity of operating
   protocols like PPP and frame relay, provides logical networks and
   traffic segregation for Virtual Private Networks (VPNs), security and
   traffic engineering, enables efficient WAN broadcasting and
   multicasting, and reduces address space requirements. VNS reduces the
   number of routing hops over the WAN by switching packets based on
   labels.
</t>

<t>
   VNS has been proven in production networks for several years.
</t>
</abstract>
</front>

<seriesInfo value="2340" name="RFC" />
<format octets="38938" type="HTML" target="http://xml.resource.org/public/rfc/html/rfc2340.html" />
<format octets="26782" type="XML" target="http://xml.resource.org/public/rfc/xml/rfc2340.xml" />
</reference>


<reference target2="reference.RFC.2341.xml" anchor="RFC2341">
<front>
<title abbrev="Cisco L2F">Cisco Layer Two Forwarding (Protocol) "L2F"</title>
<author fullname="Andy Valencia" initials="A." surname="Valencia">
<organization>Cisco Systems</organization>

<address>
<postal>
<street>170 West Tasman Drive</street>
<street>San Jose CA 95134-1706</street>
</postal>

<email>valencia@cisco.com</email>
</address>
</author>

<author fullname="Morgan Littlewood" initials="M." surname="Littlewood">
<organization>Cisco Systems</organization>

<address>
<postal>
<street>170 West Tasman Drive</street>
<street>San Jose CA 95134-1706</street>
</postal>

<email>littlewo@cisco.com</email>
</address>
</author>

<author fullname="Tim Kolar" initials="T." surname="Kolar">
<organization>Cisco Systems</organization>

<address>
<postal>
<street>170 West Tasman Drive</street>
<street>San Jose CA 95134-1706</street>
</postal>

<email>tkolar@cisco.com</email>
</address>
</author>

<date year="1998" month="May" />
<area>Internet</area>
<keyword>tunnel</keyword>

<abstract>
<t>

   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.

</t>
</abstract>
</front>

<seriesInfo value="2341" name="RFC" />
<format octets="77652" type="HTML" target="http://xml.resource.org/public/rfc/html/rfc2341.html" />
<format octets="65058" type="XML" target="http://xml.resource.org/public/rfc/xml/rfc2341.xml" />
</reference>


<reference target2="reference.RFC.2342.xml" anchor="RFC2342">
<front>
<title>IMAP4 Namespace</title>
<author fullname="Mike Gahrns" initials="M." surname="Gahrns">
<organization>Microsoft</organization>

<address>
<postal>
<street>One Microsoft Way</street>
<city>Redmond</city>
<region>WA</region>
<code>98072</code>
</postal>

<phone>(425) 936-9833</phone>
<email>mikega@microsoft.com</email>
</address>
</author>

<author fullname="Chris Newman" initials="C." surname="Newman">
<organization>Innosoft International, Inc.</organization>

<address>
<postal>
<street>1050 East Garvey Ave. South</street>
<city>West Covina</city>
<region>CA</region>
<code>91790</code>
</postal>

<email>chris.newman@innosoft.com</email>
</address>
</author>

<date year="1998" month="May" />
<area>Applications</area>
<keyword>internet message access protocol</keyword>

<abstract>
<t>

   IMAP4 [RFC-2060] does not define a default server namespace. As a

   result, two common namespace models have evolved:


<list>
<t>

   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.

</t>

<t>

   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.
</t>
</list>
</t>

<t>


   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.
</t>
</abstract>
</front>

<seriesInfo value="2342" name="RFC" />
<format octets="26723" type="HTML" target="http://xml.resource.org/public/rfc/html/rfc2342.html" />
<format octets="17754" type="XML" target="http://xml.resource.org/public/rfc/xml/rfc2342.xml" />
</reference>


<reference target2="reference.RFC.2343.xml" anchor="RFC2343">
<front>
<title>RTP Payload Format for Bundled MPEG</title>
<author fullname="M. Reha Civanlar" initials="M.R." surname="Civanlar">
<organization>AT&amp;T Labs-Research</organization>

<address>
<postal>
<street>100 Schultz Drive</street>
<city>Red Bank</city>
<region>NJ</region>
<code>07701</code>
<country>USA</country>
</postal>

<email>civanlar@research.att.com</email>
</address>
</author>

<author fullname="Glenn L. Cash" initials="G.L." surname="Cash">
<organization>AT&amp;T Labs-Research</organization>

<address>
<postal>
<street>100 Schultz Drive</street>
<city>Red Bank</city>
<region>NJ</region>
<code>07701</code>
<country>USA</country>
</postal>

<email>glenn@research.att.com</email>
</address>
</author>

<author fullname="Barry G. Haskell" initials="B.G." surname="Haskell">
<organization>AT&amp;T Labs-Research</organization>

<address>
<postal>
<street>100 Schultz Drive</street>
<city>Red Bank</city>
<region>NJ</region>
<code>07701</code>
<country>USA</country>
</postal>

<email>bgh@research.att.com</email>
</address>
</author>

<date year="1998" month="May" />
<area>Transport</area>
<keyword>audio</keyword>
<keyword>motion picture experts group</keyword>
<keyword>real-time transport protocol</keyword>
<keyword>RTP</keyword>
<keyword>video</keyword>

<abstract>
<t>
   This document describes a payload type for bundled, MPEG-2 encoded

   video and audio data that may be used with RTP, version 2. Bundling

   has some advantages for this payload type particularly when it is

   used for video-on-demand applications. This payload type may be used

   when its advantages are important enough to sacrifice the modularity

   of having separate audio and video streams.
</t>
</abstract>
</front>

<seriesInfo value="2343" name="RFC" />
<format octets="23965" type="HTML" target="http://xml.resource.org/public/rfc/html/rfc2343.html" />
<format octets="16617" type="XML" target="http://xml.resource.org/public/rfc/xml/rfc2343.xml" />
</reference>


<reference target2="reference.RFC.2344.xml" anchor="RFC2344">
<front>
<title>Reverse Tunneling for Mobile IP</title>
<author fullname="Gabriel E. Montenegro" initials="G.E." surname="Montenegro">
<organization>Sun Microsystems, Inc.</organization>

<address>
<postal>
<street>901 San Antonio Road</street>
<street>Mailstop UMPK 15-214</street>
<street>Voice:  +1-415-786-6288</street>
<city>Mountain View</city>
<region>California</region>
<code>94303</code>
</postal>

<email>gabriel.montenegro@eng.sun.com</email>
</address>
</author>

<author>
<organization />
</author>

<date year="1998" month="May" />
<area>Internet</area>
<keyword>firewall</keyword>
<keyword>mobile ip</keyword>
<keyword>tunnel</keyword>

<abstract>
<t>
   Mobile IP uses tunneling from the home agent to the mobile node's

   care-of address, but rarely in the reverse direction.  Usually, a

   mobile node sends its packets through a router on the foreign

   network, and assumes that routing is independent of source address.

   When this assumption is not true, it is convenient to establish a

   topologically correct reverse tunnel from the care-of address to the

   home agent.
</t>

<t>


   This document proposes backwards-compatible extensions to Mobile IP

   in order to support topologically correct reverse tunnels.  This

   document does not attempt to solve the problems posed by firewalls

   located between the home agent and the mobile node's care-of address.
</t>
</abstract>
</front>

<seriesInfo value="2344" name="RFC" />
<format octets="52358" type="HTML" target="http://xml.resource.org/public/rfc/html/rfc2344.html" />
<format octets="38506" type="XML" target="http://xml.resource.org/public/rfc/xml/rfc2344.xml" />
</reference>


<reference target2="reference.RFC.2345.xml" anchor="RFC2345">
<front>
<title>Domain Names and Company Name Retrieval</title>
<author fullname="John C. Klensin" initials="J.C." surname="Klensin">
<organization>MCI Internet Architecture</organization>

<address>
<postal>
<street>800 Boylston St, 7th floor</street>
<city>Boston</city>
<region>MA</region>
<code>02199</code>
<country>USA</country>
</postal>

<phone>+1 617 960 1011</phone>
<email>klensin@mci.net</email>
</address>
</author>

<author fullname="Ted Wolf, Jr." initials="T.W." surname="Jr">
<organization>Electronic Commerce</organization>

<address>
<postal>
<street>Dun &amp; Bradstreet Information Services</street>
<street>3 Sylvan Way</street>
<city>Parsippany</city>
<region>NJ</region>
<code>07054</code>
<country>USA</country>
</postal>

<phone>+1 201 605 6308</phone>
<email>ted@usa.net</email>
</address>
</author>

<author fullname="Gary W. Oglesby" initials="G.W." surname="Oglesby">
<organization>MCI Internet Architecture</organization>

<address>
<postal>
<street>842 N. Ahoy Dr.</street>
<city>Gilbert</city>
<region>AZ</region>
<code>85234</code>
<country>USA</country>
</postal>

<phone>+1 415 538 1100</phone>
<email>gary@mci.net</email>
</address>
</author>

<date year="1998" month="May" />
<area>Applications</area>
<keyword>domain name</keyword>
<keyword>URL</keyword>

<abstract>
<t>

   Location of web information for particular companies based on their

   names has become an increasingly difficult problem as the Internet

   and the web grow.   The use of a naming convention and the domain

   name system (DNS) for that purpose has caused complications for the

   latter while not solving the problem.  While there have been several

   proposals to use contemporary, high-capability, directory service and

   search protocols to reduce the dependencies on DNS conventions, none

   of them have been significantly deployed.


</t>

<t>
   This document proposes a company name to URL mapping service based on

   the oldest and least complex of Internet directory protocols, whois,

   in order to explore whether an extremely simple and widely-deployed

   protocol can succeed where more complex and powerful options have

   failed or been excessively delayed.
</t>
</abstract>
</front>

<seriesInfo value="2345" name="RFC" />
<format octets="37404" type="HTML" target="http://xml.resource.org/public/rfc/html/rfc2345.html" />
<format octets="31173" type="XML" target="http://xml.resource.org/public/rfc/xml/rfc2345.xml" />
</reference>


<reference target2="reference.RFC.2346.xml" anchor="RFC2346">
<front>
<title>Making Postscript and PDF International</title>
<author fullname="Jacob Palme" initials="J." surname="Palme">
<organization>Stockholm University and KTH</organization>

<address>
<postal>
<street>Electrum 230</street>
<street>S-164 40 Kista, Sweden</street>
</postal>

<phone>+46-8-16 16 67</phone>
<facsimile>+46-8-783 08 29</facsimile>
<email>jpalme@dsv.su.se</email>
</address>
</author>

<date year="1998" month="May" />
<area>Applications</area>
<keyword>multipurpose internet mail extensions</keyword>
<keyword>MIME</keyword>
<keyword>PDF</keyword>
<keyword>PostScript</keyword>

<abstract>
<t>
   Certain text formats, for example Postscript (MIME-Type:

   application/postscript; file extension .ps) and Portable Document

   Format (MIME-Type: application/pdf; file extension .pdf) specify

   exactly the page layout of the printed document. The commonly used

   paper format is different in North America and the rest of the world.

   North America uses the 'Letter' format, while the rest of the world

   mostly uses the ISO-standard 'A4' format. This means that documents

   formatted on one continent may not be easily printable on another

   continent. This memo gives advice on how to produce documents which

   are equally well printable with the Letter and the A4 formats. By

   using the advice in this document, you can put up a document on the

   Internet, which recipients can print without problem both in and

   outside North America.

</t>

<t>

   A very short summary of the advice in this document: If you are using

   U.S. Letter paper format, ensure that both the left and right margins

   are at least 21 mm (0.8 in). If you are using A4 paper format, ensure

   that both the top and bottom margins are at least 33 mm (1.3 in).
</t>
</abstract>
</front>

<seriesInfo value="2346" name="RFC" />
<format octets="19513" type="HTML" target="http://xml.resource.org/public/rfc/html/rfc2346.html" />
<format octets="10186" type="XML" target="http://xml.resource.org/public/rfc/xml/rfc2346.xml" />
</reference>


<reference target2="reference.RFC.2347.xml" anchor="RFC2347">
<front>
<title>TFTP Option Extension</title>
<author fullname="Gary Scott Malkin" initials="G.S." surname="Malkin">
<organization>Bay Networks</organization>

<address>
<postal>
<street>8 Federal Street</street>
<city>Billerica</city>
<region>MA</region>
<code>01821</code>
</postal>

<phone>(978) 916-4237</phone>
<email>gmalkin@baynetworks.com</email>
</address>
</author>

<author fullname="Art Harkin" initials="A." surname="Harkin">
<organization>Internet Services Project</organization>

<address>
<postal>
<street>Information Networks Division</street>
<street>19420 Homestead Road MS 43LN</street>
<city>Cupertino</city>
<region>CA</region>
<code>95014</code>
</postal>

<phone>(408) 447-3755</phone>
<email>ash@cup.hp.com</email>
</address>
</author>

<date year="1998" month="May" />
<area>Applications</area>
<keyword>file transfer</keyword>
<keyword>TFTP</keyword>
<keyword>trivial file transfer protocol</keyword>

<abstract>
<t>

   The Trivial File Transfer Protocol [1] is a simple, lock-step, file

   transfer protocol which allows a client to get or put a file onto a

   remote host.  This document describes a simple extension to TFTP to

   allow option negotiation prior to the file transfer.
</t>
</abstract>
</front>

<seriesInfo value="2347" name="RFC" />
<format octets="20801" type="HTML" target="http://xml.resource.org/public/rfc/html/rfc2347.html" />
<format octets="12138" type="XML" target="http://xml.resource.org/public/rfc/xml/rfc2347.xml" />
</reference>


<reference target2="reference.RFC.2348.xml" anchor="RFC2348">
<front>
<title>TFTP Blocksize Option</title>
<author fullname="Gary Scott Malkin" initials="G.S." surname="Malkin">
<organization>Bay Networks</organization>

<address>
<postal>
<street>8 Federal Street</street>
<city>Billerica</city>
<region>MA</region>
<code>10821</code>
</postal>

<phone>(978) 916-4237</phone>
<email>gmalkin@baynetworks.com</email>
</address>
</author>

<author fullname="Art Harkin" initials="A." surname="Harkin">
<organization>Networked Computing Division</organization>

<address>
<postal>
<street>Hewlett-Packard Company</street>
<street>19420 Homestead Road MS 43LN</street>
<city>Cupertino</city>
<region>CA</region>
<code>95014</code>
</postal>

<phone>(408) 447-3755</phone>
<email>ash@cup.hp.com</email>
</address>
</author>

<date year="1998" month="May" />
<area>Applications</area>
<keyword>trivial file transfer protocol</keyword>
<keyword>TFTP</keyword>

<abstract>
<t>

   The Trivial File Transfer Protocol [1] is a simple, lock-step, file

   transfer protocol which allows a client to get or put a file onto a

   remote host.  One of its primary uses is the booting of diskless

   nodes on a Local Area Network.  TFTP is used because it is very

   simple to implement in a small node's limited ROM space.  However,

   the choice of a 512-octet blocksize is not the most efficient for use

   on a LAN whose MTU may 1500 octets or greater.

</t>

<t>

   This document describes a TFTP option which allows the client and

   server to negotiate a blocksize more applicable to the network

   medium.  The TFTP Option Extension mechanism is described in [2].

</t>
</abstract>
</front>

<seriesInfo value="2348" name="RFC" />
<format octets="16962" type="HTML" target="http://xml.resource.org/public/rfc/html/rfc2348.html" />
<format octets="8219" type="XML" target="http://xml.resource.org/public/rfc/xml/rfc2348.xml" />
</reference>


<reference target2="reference.RFC.2349.xml" anchor="RFC2349">
<front>
<title abbrev="TFTP Timeout">TFTP Timeout Interval and Transfer Size Options</title>
<author fullname="Gary Scott Malkin" initials="G.S." surname="Malkin">
<organization>Bay Networks</organization>

<address>
<postal>
<street>8 Federal Street</street>
<city>Billerica</city>
<region>MA</region>
<code>01821</code>
</postal>

<phone>(978) 916-4237</phone>
<email>gmalkin@baynetworks.com</email>
</address>
</author>

<author fullname="Art Harkin" initials="A." surname="Harkin">
<organization>Internet Services Project</organization>

<address>
<postal>
<street>Information Networks Division</street>
<street>19420 Homestead Road MS 43LN</street>
<city>Cupertino</city>
<region>CA</region>
<code>95014</code>
</postal>

<phone>(408) 447-3755</phone>
<email>ash@cup.hp.com</email>
</address>
</author>

<date year="1998" month="May" />
<area>Applications</area>
<keyword>trivial file transfer protocol</keyword>
<keyword>TFTP</keyword>
<keyword>timeout</keyword>

<abstract>
<t>

   The Trivial File Transfer Protocol [1] is a simple, lock-step, file

   transfer protocol which allows a client to get or put a file onto a

   remote host.
</t>

<t>


   This document describes two TFTP options. The first allows the client

   and server to negotiate the Timeout Interval.  The second allows the

   side receiving the file to determine the ultimate size of the

   transfer before it begins.  The TFTP Option Extension mechanism is

   described in [2].
</t>
</abstract>
</front>

<seriesInfo value="2349" name="RFC" />
<format octets="15300" type="HTML" target="http://xml.resource.org/public/rfc/html/rfc2349.html" />
<format octets="6588" type="XML" target="http://xml.resource.org/public/rfc/xml/rfc2349.xml" />
</reference>


<reference target2="reference.RFC.2350.xml" anchor="RFC2350">
<front>
<title abbrev="Security Response">Expectations for Computer Security Incident Response</title>
<author fullname="Nevil Brownlee" initials="N." surname="Brownlee">
<organization>ITSS Technology Development</organization>

<address>
<postal>
<street>The University of Auckland</street>
</postal>

<phone>+64 9 373 7599 x8941</phone>
<email>n.brownlee@auckland.ac.nz</email>
</address>
</author>

<author fullname="Erik Guttman" initials="E." surname="Guttman">
<organization>Sun Microsystems, Inc.</organization>

<address>
<postal>
<street>Bahnstr. 2</street>
<street>74915 Waibstadt Germany</street>
</postal>

<phone>+49 7263 911484</phone>
<email>Erik.Guttman@sun.com</email>
</address>
</author>

<date year="1998" month="June" />
<area>Security</area>
<area>Operations</area>
<keyword>security</keyword>

<abstract>
<t>

   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.
</t>

<t>


   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.
</t>
</abstract>
</front>

<seriesInfo value="21" name="BCP" />
<seriesInfo value="2350" name="RFC" />
<format octets="99062" type="HTML" target="http://xml.resource.org/public/rfc/html/rfc2350.html" />
<format octets="83490" type="XML" target="http://xml.resource.org/public/rfc/xml/rfc2350.xml" />
</reference>


<reference target2="reference.RFC.2351.xml" anchor="RFC2351">
<front>
<title abbrev="MATIP">Mapping of Airline Reservation, Ticketing, and Messaging Traffic over IP</title>
<author fullname="Alain Robert" initials="A." surname="Robert">
<organization>S.I.T.A.</organization>

<address>
<postal>
<street>18, rue Paul Lafargue</street>
<street>92904 PARIS LA DEFENSE 10</street>
<country>FRANCE</country>
</postal>

<phone>33 1 46411491</phone>
<facsimile>33 1 46411277</facsimile>
<email>arobert@par1.par.sita.int</email>
</address>
</author>

<date year="1998" month="May" />
<area>Internet</area>
<keyword>encapsulate</keyword>

<abstract>
<t>

   This memo specifies a protocol for the encapsulation of the airline

   specific protocol over IP.
</t>
</abstract>
</front>

<seriesInfo value="2351" name="RFC" />
<format octets="52866" type="HTML" target="http://xml.resource.org/public/rfc/html/rfc2351.html" />
<format octets="43634" type="XML" target="http://xml.resource.org/public/rfc/xml/rfc2351.xml" />
</reference>


<reference target2="reference.RFC.2352.xml" anchor="RFC2352">
<front>
<title abbrev="Legal Names">A Convention For Using Legal Names as Domain Names</title>
<author fullname="Owain Vaughan" initials="O." surname="Vaughan">
<organization>Vaughan Enterprises</organization>

<address>
<postal>
<street>PO Box 155</street>
<street>Newport NP9 6YX</street>
<country>UK</country>
</postal>

<phone>+44 1633 677849/822164</phone>
<facsimile>+44 1633 663706</facsimile>
<email>owain@vaughan.com</email>
</address>
</author>

<date year="1998" month="May" />
<area>General</area>
<area>Applications</area>
<keyword>legal name</keyword>
<keyword>domain name</keyword>

<note title="IESG Note">
<t>
   This RFC is an independent submission that discusses a possible
   convention for allocating domain names based on corporate and other
   names as registered by law.
</t>

<t>
   It appears to depend on corporations changing their domain names from
   their present form to more cumbersome handles, such as changing
   cisco.com to cisco-systems.co.ca.us or ibm.com to international-
   business-machines.co.ny.us, without giving them an incentive to do
   so, such as deprecating the .com and .net gTLDs.  It also appears to
   legislate the structure each national registry applies to its name
   space, something which the document itself asserts is within national
   purview and not for global standardization.
</t>

<t>
   It may not be politically feasible to implement as described.
</t>
</note>
</front>

<seriesInfo value="2352" name="RFC" />
<format octets="26027" type="HTML" target="http://xml.resource.org/public/rfc/html/rfc2352.html" />
<format octets="15800" type="XML" target="http://xml.resource.org/public/rfc/xml/rfc2352.xml" />
</reference>


<reference target2="reference.RFC.2353.xml" anchor="RFC2353">
<front>
<title abbrev="APPN/HPR">APPN/HPR in IP Networks APPN Implementers&apos; Workshop Closed Pages Document</title>
<author fullname="Gary Dudley" initials="G." surname="Dudley">
<organization>C3BA/501</organization>

<address>
<postal>
<street>IBM Corporation</street>
<street>P.O. Box 12195</street>
<street>Research Triangle Park</street>
<street>NC 27709</street>
<country>USA</country>
</postal>

<phone>+1 919-254-4358</phone>
<facsimile>+1 919-254-6243</facsimile>
<email>dudleyg@us.ibm.com</email>
</address>
</author>

<date year="1998" month="May" />
<area>Internet</area>
<keyword>APPN</keyword>
<keyword>IBM SNA advanced peer-to-peer networking</keyword>
<keyword>workshop</keyword>
</front>

<seriesInfo value="2353" name="RFC" />
<format octets="130908" type="HTML" target="http://xml.resource.org/public/rfc/html/rfc2353.html" />
<format octets="116997" type="XML" target="http://xml.resource.org/public/rfc/xml/rfc2353.xml" />
</reference>


<reference target2="reference.RFC.2354.xml" anchor="RFC2354">
<front>
<title>Options for Repair of Streaming Media</title>
<author fullname="Colin Perkins" initials="C." surname="Perkins">
<organization>Department of Computer Science</organization>

<address>
<postal>
<street>University College London</street>
<street>Gower Street</street>
<street>London WC1E 6BT</street>
<country>United Kingdom</country>
</postal>

<email>c.perkins@cs.ucl.ac.uk</email>
</address>
</author>

<author fullname="Orion Hodson" initials="O." surname="Hodson">
<organization>Department of Computer Science</organization>

<address>
<postal>
<street>University College London</street>
<street>Gower Street</street>
<street>London WC1E 6BT</street>
<country>United Kingdom</country>
</postal>

<email>o.hodson@cs.ucl.ac.uk</email>
</address>
</author>

<date year="1998" month="June" />
<area>Transport</area>
<keyword>audio</keyword>
<keyword>multimedia</keyword>
<keyword>video</keyword>

<abstract>
<t>
   This document summarizes a range of possible techniques for the
   repair of continuous media streams subject to packet loss.  The
   techniques discussed include redundant transmission, retransmission,
   interleaving and forward error correction.  The range of
   applicability of these techniques is noted, together with the
   protocol requirements and dependencies.
</t>
</abstract>
</front>

<seriesInfo value="2354" name="RFC" />
<format octets="38747" type="HTML" target="http://xml.resource.org/public/rfc/html/rfc2354.html" />
<format octets="28167" type="XML" target="http://xml.resource.org/public/rfc/xml/rfc2354.xml" />
</reference>


<reference target2="reference.RFC.2355.xml" anchor="RFC2355">
<front>
<title>TN3270 Enhancements</title>
<author fullname="Bill Kelly" initials="B." surname="Kelly">
<organization>Division of University Computing</organization>

<address>
<postal>
<street>144 Parker Hall</street>
<street>Auburn University</street>
<street>AL  36849</street>
</postal>

<phone>(334) 844-4512</phone>
<uri>.edu</uri>
</address>
</author>

<date year="1998" month="June" />
<area>Applications</area>
<keyword>IBM 3270 display</keyword>
<keyword>TN3270</keyword>

<abstract>
<t>
   This document describes a protocol that more fully supports 3270
   devices than do traditional tn3270 practices.  Specifically, it
   defines a method of emulating both the terminal and printer members
   of the 3270 family of devices via Telnet; it provides for the ability
   of a Telnet client to request that it be assigned a specific device-
   name (also referred to as &quot;LU name&quot; or &quot;network name&quot;); finally, it
   adds support for a variety of functions such as the ATTN key, the
   SYSREQ key, and SNA response handling.
</t>

<t>
   This protocol is negotiated under the TN3270E Telnet Option, and is
   unrelated to the Telnet 3270 Regime Option as defined in RFC 1041
   .
</t>
</abstract>
</front>

<seriesInfo value="2355" name="RFC" />
<format octets="106214" type="HTML" target="http://xml.resource.org/public/rfc/html/rfc2355.html" />
<format octets="88903" type="XML" target="http://xml.resource.org/public/rfc/xml/rfc2355.xml" />
</reference>


<reference target2="reference.RFC.2356.xml" anchor="RFC2356">
<front>
<title abbrev="SKIP for Mobile IP">Sun&apos;s SKIP Firewall Traversal for Mobile IP</title>
<author fullname="Gabriel E. Montenegro" initials="G.E." surname="Montenegro">
<organization>Sun Microsystems, Inc.</organization>

<address>
<postal>
<street>901 San Antonio Road</street>
<street>Mailstop UMPK 15-214</street>
<street>Mountain View</street>
<street>California 94303</street>
</postal>

<phone>(415)786-6288</phone>
<facsimile>(415)786-6445</facsimile>
<email>gabriel.montenegro@Eng.Sun.COM</email>
</address>
</author>

<author fullname="Vipul Gupta" initials="V." surname="Gupta">
<organization>Sun Microsystems, Inc.</organization>

<address>
<postal>
<street>901 San Antonio Road</street>
<street>Mailstop UMPK 15-214</street>
<street>Mountain View</street>
<street>California 94303</street>
</postal>

<phone>(415)786-3614</phone>
<facsimile>(415)786-6445</facsimile>
<email>vipul.gupta@Eng.Sun.COM</email>
</address>
</author>

<date year="1998" month="June" />
<area>Security</area>
<area>Internet</area>
<keyword>firewall</keyword>
<keyword>SKIP</keyword>
<keyword>mobile ip</keyword>
<keyword>routing</keyword>
<keyword>security</keyword>
<keyword>simple key management for internet protocols</keyword>
<keyword>wireless</keyword>

<abstract>
<t>
   The Mobile IP specification establishes the mechanisms that enable a
   mobile host to maintain and use the same IP address as it changes its
   point of attachment to the network. Mobility implies higher security
   risks than static operation, because the traffic may at times take
   unforeseen network paths with unknown or unpredictable security
   characteristics. The Mobile IP specification makes no provisions for
   securing data traffic.  The mechanisms described in this document
   allow a mobile node out on a public sector of the internet to
   negotiate access past a SKIP firewall, and construct a secure channel
   into its home network.
</t>

<t>
   In addition to securing traffic, our mechanisms allow a mobile node
   to roam into regions that (1) impose ingress filtering, and (2) use a
   different address space.
</t>
</abstract>
</front>

<seriesInfo value="2356" name="RFC" />
<format octets="66740" type="HTML" target="http://xml.resource.org/public/rfc/html/rfc2356.html" />
<format octets="53252" type="XML" target="http://xml.resource.org/public/rfc/xml/rfc2356.xml" />
</reference>


<reference target2="reference.RFC.2357.xml" anchor="RFC2357">
<front>
<title abbrev="Evaluating Reliable Multicast">IETF Criteria for Evaluating Reliable Multicast Transport and Application Protocols</title>
<author fullname="Allison Mankin" initials="A." surname="Mankin">
<organization>USC/ISI East</organization>

<address>
<postal>
<street>4350 N. Fairfax Drive</street>
<street>Suite 620</street>
<city>Arlington</city>
<region>VA</region>
<code>22203</code>
<country>US</country>
</postal>

<phone>+1 703 812 3706</phone>
<email>mankin@isi.edu</email>
</address>
</author>

<author fullname="Allyn Romanov" initials="A." surname="Romanov">
<organization>MCI Corporation</organization>

<address>
<postal>
<street>2560 North First Street</street>
<street>San Jose</street>
<region>CA</region>
<code>9531</code>
<country>USA</country>
</postal>

<email>allyn@mci.net</email>
</address>
</author>

<author fullname="Scott Bradner" initials="S." surname="Bradner">
<organization>Harvard University</organization>

<address>
<postal>
<street>1350 Mass. Ave.</street>
<street>Rm. 876</street>
<street>Cambridge MA 02138</street>
<country>USA</country>
</postal>

<phone>617 495 3864</phone>
<email>sob@harvard.edu</email>
</address>
</author>

<author fullname="Vern Paxson" initials="V." surname="Paxson">
<organization>MS 50B/2239</organization>

<address>
<postal>
<street>Lawrence Berkeley National Laboratory</street>
<street>University of California</street>
<street>Berkeley</street>
<street>CA 94720</street>
<country>USA</country>
</postal>

<phone>510-486-7504</phone>
<email>vern@ee.lbl.gov</email>
</address>
</author>

<date year="1998" month="June" />
<area>Transport</area>
<keyword>Internet Engineering Task Force</keyword>
<keyword>multicast</keyword>

<abstract>
<t>
   This memo describes the procedures and criteria for reviewing
   reliable multicast protocols within the Transport Area (TSV) of the
   IETF.  Within today&apos;s Internet, important applications exist for a
   reliable multicast service.  Some examples that are driving reliable
   multicast technology are collaborative workspaces (such as
   whiteboard), data and software distribution, and (more speculatively)
   web caching protocols.  Due to the nature of the technical issues, a
   single commonly accepted technical solution that solves all the
   demands for reliable multicast is likely to be infeasible [RMMinutes
   1997].
</t>

<t>
   A number of reliable multicast protocols have already been developed
   to solve a variety of problems for various types of applications.
    describes one widely deployed example.  How should these
   protocols be treated within the IETF and how should the IETF guide
   the development of reliable multicast in a direction beneficial for
   the general Internet?
</t>

<t>
   The TSV Area Directors and their Directorate have outlined a set of
   review procedures that address these questions and set criteria and
   processes for the publication as RFCs of Internet-Drafts on reliable
   multicast transport protocols.
</t>
</abstract>
</front>

<seriesInfo value="2357" name="RFC" />
<format octets="38288" type="HTML" target="http://xml.resource.org/public/rfc/html/rfc2357.html" />
<format octets="26016" type="XML" target="http://xml.resource.org/public/rfc/xml/rfc2357.xml" />
</reference>


<reference target2="reference.RFC.2358.xml" anchor="RFC2358">
<front>
<title abbrev="MIB for Ethernet-like Interface Types">Definitions of Managed Objects for the Ethernet-like Interface Types</title>
<author fullname="John Flick" initials="J." surname="Flick">
<organization>Hewlett-Packard Company</organization>

<address>
<postal>
<street>8000 Foothills Blvd. M/S 5556</street>
<street>Roseville</street>
<street>CA 95747-5556</street>
</postal>

<phone>+1 916 785 4018</phone>
<email>johnf@hprnd.rose.hp.com</email>
</address>
</author>

<author fullname="Jeffrey Johnson" initials="J." surname="Johnson">
<organization>RedBack Networks</organization>

<address>
<postal>
<street>2570 North First Street</street>
<street>Suite 410</street>
<street>San Jose</street>
<street>95131</street>
<country>USA</country>
</postal>

<phone>+1 408 571 2699</phone>
<email>jeff@redbacknetworks.com</email>
</address>
</author>

<date year="1998" month="June" />
<area>Internet</area>
<area>Management</area>
<keyword>Management Information Base</keyword>
<keyword>ethernet</keyword>
<keyword>managed object</keyword>

<abstract>
<t>
   This memo defines a portion of the Management Information Base (MIB)
   for use with network management protocols in the Internet community.
   This memo obsoletes RFC 1650 &quot;Definitions of Managed Objects for the
   Ethernet-like Interface Types using SMIv2&quot;.  This memo extends that
   specification by including management information useful for the
   management of 100 Mb/s Ethernet interfaces.
</t>

<t>
   Ethernet technology, as defined by the 802.3 Working Group of the
   IEEE, continues to evolve, with scalable increases in speed, new
   types of cabling and interfaces, and new features.  This evolution
   may require changes in the managed objects in order to reflect this
   new functionality.  This document, as with other documents issued by
   this working group, reflect a certain stage in the evolution of
   Ethernet technology.  In the future, this document might be revised,
   or new documents might be issued by the Ethernet Interfaces and Hub
   MIB Working Group, in order to reflect the evolution of Ethernet
   technology.
</t>
</abstract>
</front>

<seriesInfo value="2358" name="RFC" />
<format octets="97511" type="HTML" target="http://xml.resource.org/public/rfc/html/rfc2358.html" />
<format octets="83716" type="XML" target="http://xml.resource.org/public/rfc/xml/rfc2358.xml" />
</reference>


<reference target2="reference.RFC.2359.xml" anchor="RFC2359">
<front>
<title>IMAP4 UIDPLUS extension</title>
<author fullname="John Gardiner Myers" initials="J.G." surname="Myers">
<organization>Netscape Communications</organization>

<address>
<postal>
<street>501 East Middlefield Road</street>
<street>Mail Stop MV-029</street>
<street>Mountain View</street>
<street>CA  94043</street>
</postal>

<email>jgmyers@netscape.com</email>
</address>
</author>

<date year="1998" month="June" />
<area>Applications</area>
<keyword>IMAP</keyword>
<keyword>internet message access protocol</keyword>

<note title="IESG Note">
<t>
   The IMAP extension described here assumes a particular means of using
   IMAP to support disconnected operation.  However, this means of
   supporting disconnected operation is not yet documented.  Also, there
   are multiple theories about how best to do disconnected operation in
   IMAP, and as yet, there is no consensus on which one should be
   adopted as a standard.
</t>

<t>
   This document is being approved as a Proposed Standard because it
   does not appear to have technical flaws in itelf.  However, approval
   of this document as a Proposed Standard should not be considered an
   IETF endorsement of any particular means of doing disconnected
   operation in IMAP.
</t>
</note>
</front>

<seriesInfo value="2359" name="RFC" />
<format octets="22101" type="HTML" target="http://xml.resource.org/public/rfc/html/rfc2359.html" />
<format octets="10512" type="XML" target="http://xml.resource.org/public/rfc/xml/rfc2359.xml" />
</reference>


<reference target2="reference.RFC.2360.xml" anchor="RFC2360">
<front>
<title>Guide for Internet Standards Writers</title>
<author fullname="Gregor D. Scott" initials="G.D." surname="Scott">
<organization>Director, Defense Information Systems Agency</organization>

<address>
<postal>
<street>ATTN: JIEO-JEBBC</street>
<street>Ft. Monmouth</street>
<street>NJ  07703-5613</street>
<country>USA</country>
</postal>

<phone>(732) 427-6856</phone>
<facsimile>(732) 532-0853</facsimile>
<email>scottg@ftm.disa.mil</email>
</address>
</author>

<date year="1998" month="June" />
<area>General</area>
<keyword>Guidelines</keyword>

<abstract>
<t>
   This document is a guide for Internet standard writers.  It defines
   those characteristics that make standards coherent, unambiguous, and
   easy to interpret.  In addition, it singles out usage believed to
   have led to unclear specifications, resulting in non-interoperable
   interpretations in the past.  These guidelines are to be used with
   RFC 2223, &quot;Instructions to RFC Authors&quot;.
</t>
</abstract>
</front>

<seriesInfo value="22" name="BCP" />
<seriesInfo value="2360" name="RFC" />
<format octets="59823" type="HTML" target="http://xml.resource.org/public/rfc/html/rfc2360.html" />
<format octets="49239" type="XML" target="http://xml.resource.org/public/rfc/xml/rfc2360.xml" />
</reference>


<reference target2="reference.RFC.2361.xml" anchor="RFC2361">
<front>
<title>WAVE and AVI Codec Registries</title>
<author fullname="Eric Fleischman" initials="E." surname="Fleischman">
<organization>Microsoft Corporation</organization>

<address>
<postal>
<street>One Microsoft Way</street>
<street>Redmond</street>
<street>WA 98052-6399</street>
<country>USA</country>
</postal>

<email>ericfl@microsoft.com</email>
<uri>http://www.microsoft.com/asf/</uri>
</address>
</author>

<date year="1998" month="June" />
<area>Applications</area>
<keyword>audio</keyword>
<keyword>video</keyword>

<abstract>
<t>
   Internet applications may reference specific codecs within the WAVE
   and AVI registries as follows:

<list>
<t>
   * video/vnd.avi; codec=XXX identifies a specific video codec (i.e.,
     XXX) within the AVI Registry.
</t>

<t>
   * audio/vnd.wave; codec=YYY identifies a specific audio codec
     (i.e., YYY) within the WAVE Registry.
</t>
</list>
</t>

<t>
   Appendix A and Appendix B provides an authoritative reference for the
   interpretation of the required &quot;codec&quot; parameter. That is, the
   current set of audio codecs that are registered within the WAVE
   Registry are enumerated in Appendix A. Appendix B enumerates the
   current set of video codecs that have been registered to date within
   the AVI Registry.
</t>
</abstract>
</front>

<seriesInfo value="2361" name="RFC" />
<format octets="98619" type="HTML" target="http://xml.resource.org/public/rfc/html/rfc2361.html" />
<format octets="88933" type="XML" target="http://xml.resource.org/public/rfc/xml/rfc2361.xml" />
</reference>


<reference target2="reference.RFC.2362.xml" anchor="RFC2362">
<front>
<title abbrev="PIM-SM">Protocol Independent Multicast-Sparse Mode (PIM-SM): Protocol Specification</title>
<author fullname="Deborah Estrin" initials="D." surname="Estrin">
<organization>Computer Science Dept/ISI</organization>

<address>
<postal>
<street>University of Southern Calif.</street>
<city>Los Angeles</city>
<region>CA</region>
<code>90089</code>
</postal>

<email>estrin@usc.edu</email>
</address>
</author>

<author fullname="Dino Farinacci" initials="D." surname="Farinacci">
<organization>Cisco Systems Inc.</organization>

<address>
<postal>
<street>170 West Tasman Drive,</street>
<city>San Jose</city>
<region>CA</region>
<code>95134</code>
</postal>

<email>dino@cisco.com</email>
</address>
</author>

<author fullname="Ahmed Helmy" initials="A." surname="Helmy">
<organization>Computer Science Dept.</organization>

<address>
<postal>
<street>University of Southern Calif.</street>
<city>Los Angeles</city>
<region>CA</region>
<code>90089</code>
</postal>

<email>ahelmy@catarina.usc.edu</email>
</address>
</author>

<author fullname="David Thaler" initials="D." surname="Thaler">
<organization>EECS Department</organization>

<address>
<postal>
<street>University of Michigan</street>
<city>Ann Arbor</city>
<region>MI</region>
<code>48109</code>
</postal>

<email>thalerd@eecs.umich.edu</email>
</address>
</author>

<author fullname="Stephen Deering" initials="S." surname="Deering">
<organization>Xerox PARC</organization>

<address>
<postal>
<street>3333 Coyote Hill Road</street>
<city>Palo Alto</city>
<region>CA</region>
<code>94304</code>
</postal>

<email>deering@parc.xerox.com</email>
</address>
</author>

<author fullname="Mark Handley" initials="M." surname="Handley">
<organization>Department of Computer Science</organization>

<address>
<postal>
<street>University College London</street>
<street>Gower Street</street>
<street>London, WC1E 6BT</street>
<country>UK</country>
</postal>

<email>m.handley@cs.ucl.ac.uk</email>
</address>
</author>

<author fullname="Van Jacobson" initials="V." surname="Jacobson">
<organization>Lawrence Berkeley Laboratory</organization>

<address>
<postal>
<street>1 Cyclotron Road</street>
<city>Berkeley</city>
<region>CA</region>
<code>94720</code>
</postal>

<email>van@ee.lbl.gov</email>
</address>
</author>

<date year="1998" month="June" />
<area>Internet</area>
<keyword>multicast</keyword>
<keyword>PIM</keyword>
<keyword>routing</keyword>
</front>

<seriesInfo value="2362" name="RFC" />
<format octets="172449" type="HTML" target="http://xml.resource.org/public/rfc/html/rfc2362.html" />
<format octets="159154" type="XML" target="http://xml.resource.org/public/rfc/xml/rfc2362.xml" />
</reference>


<reference target2="reference.RFC.2363.xml" anchor="RFC2363">
<front>
<title>PPP Over FUNI</title>
<author fullname="George Gross" initials="G." surname="Gross">
<organization>Lucent Technologies, Inc</organization>

<address>
<postal>
<street>184 Liberty Corner Road</street>
<street>Warren</street>
<street>NJ 07059</street>
</postal>

<phone>+1.908.580.4589</phone>
<email>gmgross@lucent.com</email>
</address>
</author>

<author fullname="Manu Kaycee" initials="M." surname="Kaycee">
<organization>Paradyne Corporation</organization>

<address>
<postal>
<street>21 Bear Meadow Road</street>
<street>Londonderry</street>
<street>NH 03053-2168</street>
</postal>

<phone>+1.603.434.6088</phone>
<email>mjk@nj.paradyne.com</email>
</address>
</author>

<author fullname="Arthur Lin" initials="A." surname="Lin">
<organization>Shasta Networks Inc.</organization>

<address>
<postal>
<street>249 Humboldt Court</street>
<street>Sunnyvale</street>
<street>CA 94089-1300</street>
</postal>

<phone>+1.408.747.5051</phone>
<email>alin@shastanets.com</email>
</address>
</author>

<author fullname="Andrew Malis" initials="A." surname="Malis">
<organization>Ascend Communications, Inc.</organization>

<address>
<postal>
<street>1 Robbins Road</street>
<street>Westford</street>
<street>MA 01886</street>
</postal>

<phone>+1.978.952.7414</phone>
<email>malis@ascend.com</email>
</address>
</author>

<author fullname="John Stephens" initials="J." surname="Stephens">
<organization>Cayman Systems, Inc.</organization>

<address>
<postal>
<street>100 Maple Street</street>
<street>Stoneham</street>
<street>MA 02180</street>
</postal>

<phone>+1.617.279.1101</phone>
<email>john@cayman.com</email>
</address>
</author>

<date year="1998" month="July" />
<area>Internet</area>
<keyword>asynchronous transfer mode</keyword>
<keyword>encapsulate</keyword>
<keyword>point-to-point protocol</keyword>
<keyword>PPP</keyword>

<abstract>
<t>
   The Point-to-Point Protocol (PPP)  provides a standard method for
   transporting multi-protocol datagrams over point-to-point links.
</t>

<t>
   This document describes the use of ATM Frame User Network Interface
   (FUNI)  for framing PPP encapsulated packets.
</t>
</abstract>
</front>

<seriesInfo value="2363" name="RFC" />
<format octets="38988" type="HTML" target="http://xml.resource.org/public/rfc/html/rfc2363.html" />
<format octets="23136" type="XML" target="http://xml.resource.org/public/rfc/xml/rfc2363.xml" />
</reference>


<reference target2="reference.RFC.2364.xml" anchor="RFC2364">
<front>
<title>PPP Over AAL5</title>
<author fullname="George Gross" initials="G." surname="Gross">
<organization>Lucent Technologies, Inc</organization>

<address>
<postal>
<street>184 Liberty Corner Road</street>
<street>Warren</street>
<street>NJ 07059</street>
</postal>

<phone>+1.908.580.4589</phone>
<email>gmgross@lucent.com</email>
</address>
</author>

<author fullname="Manu Kaycee" initials="M." surname="Kaycee">
<organization>Paradyne Corporation</organization>

<address>
<postal>
<street>21 Bear Meadow Road</street>
<street>Londonderry</street>
<street>NH 03053-2168</street>
</postal>

<phone>+1.603.434.6088</phone>
<email>mjk@nj.paradyne.com</email>
</address>
</author>

<author fullname="Arthur Lin" initials="A." surname="Lin">
<organization>Shasta Networks Inc.</organization>

<address>
<postal>
<street>249 Humboldt Court</street>
<street>Sunnyvale</street>
<street>CA 94089-1300</street>
</postal>

<phone>+1.408.747.5051</phone>
<email>alin@shastanets.com</email>
</address>
</author>

<author fullname="Andrew Malis" initials="A." surname="Malis">
<organization>Ascend Communications, Inc.</organization>

<address>
<postal>
<street>1 Robbins Road</street>
<street>Westford</street>
<street>MA 01886</street>
</postal>

<phone>+1.978.952.7414</phone>
<email>malis@ascend.com</email>
</address>
</author>

<author fullname="John Stephens" initials="J." surname="Stephens">
<organization>Cayman Systems, Inc.</organization>

<address>
<postal>
<street>100 Maple Street</street>
<street>Stoneham</street>
<street>MA 02180</street>
</postal>

<phone>+1.617.279.1101</phone>
<email>john@cayman.com</email>
</address>
</author>

<date year="1998" month="July" />
<area>Internet</area>
<keyword>ATM adaptation layer type 5</keyword>
<keyword>encapsulate</keyword>
<keyword>point-to-point protocol</keyword>
<keyword>PPP</keyword>

<abstract>
<t>
   The Point-to-Point Protocol (PPP)  provides a standard method for
   transporting multi-protocol datagrams over point-to-point links.
</t>

<t>
   This document describes the use of ATM Adaptation Layer 5 (AAL5) for
   framing PPP encapsulated packets.
</t>
</abstract>
</front>

<seriesInfo value="2364" name="RFC" />
<format octets="39835" type="HTML" target="http://xml.resource.org/public/rfc/html/rfc2364.html" />
<format octets="24100" type="XML" target="http://xml.resource.org/public/rfc/xml/rfc2364.xml" />
</reference>


<reference target2="reference.RFC.2365.xml" anchor="RFC2365">
<front>
<title>Administratively Scoped IP Multicast</title>
<author fullname="David Meyer" initials="D." surname="Meyer">
<organization>Cisco Systems</organization>

<address>
<postal>
<street>San Jose</street>
<country>CA</country>
</postal>

<email>dmm@cisco.com</email>
</address>
</author>

<date year="1998" month="July" />
<area>Internet</area>
<keyword>multicast</keyword>
</front>

<seriesInfo value="23" name="BCP" />
<seriesInfo value="2365" name="RFC" />
<format octets="30863" type="HTML" target="http://xml.resource.org/public/rfc/html/rfc2365.html" />
<format octets="19908" type="XML" target="http://xml.resource.org/public/rfc/xml/rfc2365.xml" />
</reference>


<reference target2="reference.RFC.2366.xml" anchor="RFC2366">
<front>
<title abbrev="ATM Multicast MIB">Definitions of Managed Objects for Multicast over UNI 3.0/3.1 based ATM Networks</title>
<author fullname="Chris Chung" initials="C." surname="Chung">
<organization>Science Applications International Corp. (SAIC)</organization>

<address>
<postal>
<street>1710 Goodridge Drive</street>
<street>Mail Stop 1-4-7</street>
<street>McLean</street>
<street>VA 22102</street>
</postal>

<phone>(703) 448-6485</phone>
<email>cchung@tieo.saic.com</email>
</address>
</author>

<author fullname="Maria Greene" initials="M." surname="Greene">
<organization>Independent Contractor</organization>

<address>
<email>maria@xedia.com</email>
</address>
</author>

<date year="1998" month="July" />
<area>Internet</area>
<area>Management</area>
<keyword>Management Information Base</keyword>
<keyword>asynchronous transfer mode</keyword>
<keyword>managed object</keyword>
<keyword>multicast</keyword>
<keyword>simple network management protocol</keyword>

<abstract>
<t>
   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 for IP hosts and routers
   that use a Multicast Address Resolution Server (MARS) to support IP
   multicast over ATM, as described in &apos;Support for Multicast over UNI
   3.0/3.1 based ATM Networks&apos; .
</t>

<t>
   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.
</t>

<t>
   This memo does not specify a standard for the Internet community.
</t>
</abstract>
</front>

<seriesInfo value="2366" name="RFC" />
<format octets="142195" type="HTML" target="http://xml.resource.org/public/rfc/html/rfc2366.html" />
<format octets="128851" type="XML" target="http://xml.resource.org/public/rfc/xml/rfc2366.xml" />
</reference>


<reference target2="reference.RFC.2367.xml" anchor="RFC2367">
<front>
<title abbrev="PF_KEY">PF_KEY Key Management API, Version 2</title>
<author fullname="Daniel L. McDonald" initials="D.L." surname="McDonald">
<organization>Sun Microsystems, Inc.</organization>

<address>
<postal>
<street>901 San Antonio Road</street>
<street>MS UMPK17-202</street>
<street>Palo Alto</street>
<street>CA 94303</street>
</postal>

<phone>+1 650 786 6815</phone>
<email>danmcd@eng.sun.com</email>
</address>
</author>

<author fullname="Craig Metz" initials="C." surname="Metz">
<organization>(for Code 5544)</organization>

<address>
<postal>
<street>U.S. Naval Research Laboratory</street>
<street>4555 Overlook Ave. SW</street>
<street>Washington</street>
<street>DC 20375</street>
</postal>

<phone>(DSN) 754-8590</phone>
<email>cmetz@inner.net</email>
</address>
</author>

<author fullname="Bao G. Phan" initials="B.G." surname="Phan">
<organization>U. S. Naval Research Laboratory</organization>

<address>
<email>phan@itd.nrl.navy.mil</email>
</address>
</author>

<date year="1998" month="July" />
<area>Internet</area>
<area>Security</area>
<keyword>IP security protocol</keyword>
<keyword>application program interface</keyword>
<keyword>internet security association and key management protocol</keyword>
<keyword>key management</keyword>
<keyword>security</keyword>

<abstract>
<t>
   A generic key management API that can be used not only for IP
   Security  but also for other network
   security services is presented in this document.  Version 1 of this
   API was implemented inside 4.4-Lite BSD as part of the U. S. Naval
   Research Laboratory&apos;s freely distributable and usable IPv6 and IPsec
   implementation.  It is documented here for the benefit of
   others who might also adopt and use the API, thus providing increased
   portability of key management applications (e.g. a manual keying
   application, an ISAKMP daemon, a GKMP daemon , a
   Photuris daemon, or a SKIP certificate discovery protocol daemon).
</t>
</abstract>
</front>

<seriesInfo value="2367" name="RFC" />
<format octets="142924" type="HTML" target="http://xml.resource.org/public/rfc/html/rfc2367.html" />
<format octets="129001" type="XML" target="http://xml.resource.org/public/rfc/xml/rfc2367.xml" />
</reference>


<reference target2="reference.RFC.2368.xml" anchor="RFC2368">
<front>
<title>The mailto URL scheme</title>
<author fullname="Paul E. Hoffman" initials="P.E." surname="Hoffman">
<organization>Internet Mail Consortium</organization>

<address>
<postal>
<street>127 Segre Place</street>
<street>Santa Cruz</street>
<street>CA  95060</street>
<country>USA</country>
</postal>

<email>phoffman@imc.org</email>
</address>
</author>

<author fullname="Larry Masinter" initials="L." surname="Masinter">
<organization>Xerox Corporation</organization>

<address>
<postal>
<street>3333 Coyote Hill Road</street>
<street>Palo Alto</street>
<street>CA 94304</street>
<country>USA</country>
</postal>

<email>masinter@parc.xerox.com</email>
</address>
</author>

<author fullname="Jamie Zawinski" initials="J." surname="Zawinski">
<organization>Netscape Communications Corp.</organization>

<address>
<postal>
<street>501 East Middlefield Road</street>
<street>Mountain View</street>
<street>CA 94043</street>
<country>USA</country>
</postal>

<email>jwz@netscape.com</email>
</address>
</author>

<date year="1998" month="July" />
<area>Applications</area>
<keyword>mailto</keyword>
<keyword>mail</keyword>
<keyword>uniform resource locator</keyword>
<keyword>URL</keyword>

<abstract>
<t>
   This document defines the format of Uniform Resource Locators (URL)
   for designating electronic mail addresses. It is one of a suite of
   documents which replace RFC 1738, &apos;Uniform Resource Locators&apos;, and
   RFC 1808, &apos;Relative Uniform Resource Locators&apos;. The syntax of
   &apos;mailto&apos; URLs from RFC 1738 is extended to allow creation of more RFC
   822 messages by allowing the URL to express additional header and
   body fields.
</t>
</abstract>
</front>

<seriesInfo value="2368" name="RFC" />
<format octets="30859" type="HTML" target="http://xml.resource.org/public/rfc/html/rfc2368.html" />
<format octets="17329" type="XML" target="http://xml.resource.org/public/rfc/xml/rfc2368.xml" />
</reference>


<reference target2="reference.RFC.2369.xml" anchor="RFC2369">
<front>
<title abbrev="URLs as Meta-Syntax">The Use of URLs as Meta-Syntax for Core Mail List Commands and their Transport through Message Header Fields</title>
<author fullname="Grant Neufeld" initials="G." surname="Neufeld">
<organization>Calgary, Alberta</organization>

<address>
<email>grant@acm.org</email>
<uri>http://www.nisto.com/</uri>
</address>
</author>

<author fullname="Joshua D. Baer" initials="J.D." surname="Baer">
<organization>Box 273</organization>

<address>
<postal>
<street>4902 Forbes Avenue</street>
<street>Pittsburgh</street>
<street>PA 15213-3799</street>
<country>USA</country>
</postal>

<email>josh@skyweyr.com</email>
</address>
</author>

<date year="1998" month="July" />
<area>Applications</area>
<keyword>mail</keyword>
<keyword>uniform resource locator</keyword>
<keyword>URL</keyword>

<abstract>
<t>
   The mailing list command specification header fields are a set of
   structured fields to be added to email messages sent by email
   distribution lists. Each field typically contains a URL (usually
   mailto ) locating the relevant information or performing the
   command directly. The three core header fields described in this
   document are List-Help, List-Subscribe, and List-Unsubscribe.
</t>

<t>
   There are three other header fields described here which, although
   not as widely applicable, will have utility for a sufficient number
   of mailing lists to justify their formalization here. These are
   List-Post, List-Owner and List-Archive.
</t>

<t>
   By including these header fields, list servers can make it possible
   for mail clients to provide automated tools for users to perform list
   functions. This could take the form of a menu item, push button, or
   other user interface element. The intent is to simplify the user
   experience, providing a common interface to the often cryptic and
   varied mailing list manager commands.
</t>

<t>
   The key words &quot;MUST&quot;, &quot;MUST NOT&quot;, &quot;REQUIRED&quot;, &quot;SHALL&quot;, &quot;SHALL NOT&quot;,
   &quot;SHOULD&quot;, &quot;SHOULD NOT&quot;, &quot;RECOMMENDED&quot;,  &quot;MAY&quot;, and &quot;OPTIONAL&quot; in this
   document are to be interpreted as described in RFC 2119.
</t>
</abstract>
</front>

<seriesInfo value="2369" name="RFC" />
<format octets="45836" type="HTML" target="http://xml.resource.org/public/rfc/html/rfc2369.html" />
<format octets="31893" type="XML" target="http://xml.resource.org/public/rfc/xml/rfc2369.xml" />
</reference>


<reference target2="reference.RFC.2370.xml" anchor="RFC2370">
<front>
<title>The OSPF Opaque LSA Option</title>
<author fullname="Rob Coltun" initials="R." surname="Coltun">
<organization>FORE Systems</organization>

<address>
<phone>(703) 245-4543</phone>
<email>rcoltun@fore.com</email>
</address>
</author>

<date year="1998" month="July" />
<area>Routing</area>
<keyword>open shortest-path first protocol</keyword>
<keyword>OSPF</keyword>
</front>

<seriesInfo value="2370" name="RFC" />
<format octets="47298" type="HTML" target="http://xml.resource.org/public/rfc/html/rfc2370.html" />
<format octets="34205" type="XML" target="http://xml.resource.org/public/rfc/xml/rfc2370.xml" />
</reference>


<reference target2="reference.RFC.2371.xml" anchor="RFC2371">
<front>
<title>Transaction Internet Protocol Version 3.0</title>
<author fullname="Jim Lyon" initials="J." surname="Lyon">
<organization>Microsoft Corporation</organization>

<address>
<postal>
<street>One Microsoft Way</street>
<street>Redmond</street>
<street>WA  98052-6399</street>
<country>USA</country>
</postal>

<phone>+1 (206) 936 0867</phone>
<facsimile>+1 (206) 936 7329</facsimile>
<email>JimLyon@Microsoft.Com</email>
</address>
</author>

<author fullname="Keith Evans" initials="K." surname="Evans">
<organization>Tandem Computers, Inc.</organization>

<address>
<postal>
<street>5425 Stevens Creek Blvd</street>
<street>Santa Clara</street>
<street>CA 95051-7200</street>
<country>USA</country>
</postal>

<phone>+1 (408) 285 5314</phone>
<facsimile>+1 (408) 285 5245</facsimile>
<email>Keith.Evans@Tandem.Com</email>
</address>
</author>

<author fullname="Johannes Klein" initials="J." surname="Klein">
<organization>Tandem Computers Inc.</organization>

<address>
<postal>
<street>10555 Ridgeview Court</street>
<street>Cupertino</street>
<street>CA 95014-0789</street>
<country>USA</country>
</postal>

<phone>+1 (408) 285 0453</phone>
<facsimile>+1 (408) 285 9818</facsimile>
<email>Johannes.Klein@Tandem.Com</email>
</address>
</author>

<date year="1998" month="July" />
<area>Applications</area>
<keyword>transaction</keyword>

<abstract>
<t>
   In many applications where different nodes cooperate on some work,
   there is a need to guarantee that the work happens atomically. That
   is, each node must reach the same conclusion as to whether the work
   is to be completed, even in the face of failures.  This document
   proposes a simple, easily-implemented protocol for achieving this
   end.
</t>
</abstract>
</front>

<seriesInfo value="2371" name="RFC" />
<format octets="91513" type="HTML" target="http://xml.resource.org/public/rfc/html/rfc2371.html" />
<format octets="72707" type="XML" target="http://xml.resource.org/public/rfc/xml/rfc2371.xml" />
</reference>


<reference target2="reference.RFC.2372.xml" anchor="RFC2372">
<front>
<title abbrev="TIP">Transaction Internet Protocol - Requirements and Supplemental Information</title>
<author fullname="Keith Evans" initials="K." surname="Evans">
<organization>Tandem Computers Inc, LOC 252-30</organization>

<address>
<postal>
<street>5425 Stevens Creek Blvd</street>
<street>Santa Clara</street>
<street>CA 95051-7200</street>
<country>USA</country>
</postal>

<phone>+1 (408) 285 5314</phone>
<facsimile>+1 (408) 285 5245</facsimile>
<email>Keith.Evans@Tandem.Com</email>
</address>
</author>

<author fullname="Johannes Klein" initials="J." surname="Klein">
<organization>Tandem Computers Inc.</organization>

<address>
<postal>
<street>10555 Ridgeview Court</street>
<street>Cupertino</street>
<street>CA 95014-0789</street>
<country>USA</country>
</postal>

<phone>+1 (408) 285 0453</phone>
<facsimile>+1 (408) 285 9818</facsimile>
<email>Johannes.Klein@Tandem.Com</email>
</address>
</author>

<author fullname="Jim Lyon" initials="J." surname="Lyon">
<organization>Microsoft Corporation</organization>

<address>
<postal>
<street>One Microsoft Way</street>
<street>Redmond</street>
<street>WA  98052-6399</street>
<country>USA</country>
</postal>

<phone>+1 (206) 936 0867</phone>
<facsimile>+1 (206) 936 7329</facsimile>
<email>JimLyon@Microsoft.Com</email>
</address>
</author>

<date year="1998" month="July" />
<area>Applications</area>
<keyword>transaction</keyword>

<abstract>
<t>
   This document describes the purpose (usage scenarios), and
   requirements for the Transaction Internet Protocol . It is
   intended to help qualify the necessary features and functions of the
   protocol. It also provides supplemental information to aid
   understanding and facilitate implementation of the TIP protocol.
</t>
</abstract>
</front>

<seriesInfo value="2372" name="RFC" />
<format octets="65802" type="HTML" target="http://xml.resource.org/public/rfc/html/rfc2372.html" />
<format octets="51790" type="XML" target="http://xml.resource.org/public/rfc/xml/rfc2372.xml" />
</reference>


<reference target2="reference.RFC.2373.xml" anchor="RFC2373">
<front>
<title abbrev="IPv6 Addressing">IP Version 6 Addressing Architecture</title>
<author fullname="Robert M. Hinden" initials="R.M." surname="Hinden">
<organization>Nokia</organization>

<address>
<postal>
<street>232 Java Drive</street>
<street>Sunnyvale</street>
<street>CA 94089</street>
<country>USA</country>
</postal>

<phone>+1 408 990-2004</phone>
<facsimile>+1 408 743-5677</facsimile>
<email>hinden@iprg.nokia.com</email>
</address>
</author>

<author fullname="Stephen E. Deering" initials="S.E." surname="Deering">
<organization>Cisco Systems, Inc.</organization>

<address>
<postal>
<street>170 West Tasman Drive</street>
<street>San Jose</street>
<street>CA 95134-1706</street>
<country>USA</country>
</postal>

<phone>+1 408 527-8213</phone>
<facsimile>+1 408 527-8254</facsimile>
<email>deering@cisco.com</email>
</address>
</author>

<date year="1998" month="July" />
<area>Internet</area>
<keyword>internet protocol version 6</keyword>
<keyword>IPv6</keyword>
<keyword>addressing</keyword>
<keyword>multicast</keyword>

<abstract>
<t>
   This specification defines the addressing architecture of the IP
   Version 6 protocol .  The document includes the IPv6 addressing
   model, text representations of IPv6 addresses, definition of IPv6
   unicast addresses, anycast addresses, and multicast addresses, and an
   IPv6 node&apos;s required addresses.
</t>
</abstract>
</front>

<seriesInfo value="2373" name="RFC" />
<format octets="67709" type="HTML" target="http://xml.resource.org/public/rfc/html/rfc2373.html" />
<format octets="54927" type="XML" target="http://xml.resource.org/public/rfc/xml/rfc2373.xml" />
</reference>


<reference target2="reference.RFC.2374.xml" anchor="RFC2374">
<front>
<title abbrev="IPv6 Global Unicast Address Format">An IPv6 Aggregatable Global Unicast Address Format</title>
<author fullname="Robert M. Hinden" initials="R.M." surname="Hinden">
<organization>Nokia</organization>

<address>
<postal>
<street>232 Java Drive</street>
<street>Sunnyvale</street>
<street>CA 94089</street>
<country>USA</country>
</postal>

<phone>1 408 990-2004</phone>
<email>hinden@iprg.nokia.com</email>
</address>
</author>

<author fullname="Stephen E. Deering" initials="S.E." surname="Deering">
<organization>Cisco Systems, Inc.</organization>

<address>
<postal>
<street>170 West Tasman Drive</street>
<street>San Jose</street>
<street>CA 95134-1706</street>
<country>USA</country>
</postal>

<phone>1 408 527-8213</phone>
<email>deering@cisco.com</email>
</address>
</author>

<date year="1998" month="July" />
<area>Internet</area>
<keyword>address</keyword>
<keyword>internet protocol version 6</keyword>
<keyword>routing</keyword>
</front>

<seriesInfo value="2374" name="RFC" />
<format octets="38996" type="HTML" target="http://xml.resource.org/public/rfc/html/rfc2374.html" />
<format octets="26703" type="XML" target="http://xml.resource.org/public/rfc/xml/rfc2374.xml" />
</reference>


<reference target2="reference.RFC.2375.xml" anchor="RFC2375">
<front>
<title abbrev="IPv6 Multicast Address">IPv6 Multicast Address Assignments</title>
<author fullname="Robert M. Hinden" initials="R.M." surname="Hinden">
<organization>Ipsilon Networks, Inc.</organization>

<address>
<postal>
<street>232 Java Drive</street>
<street>Sunnyvale</street>
<street>CA 94089</street>
<country>USA</country>
</postal>

<phone>+1 415 990 2004</phone>
<email>hinden@ipsilon.com</email>
</address>
</author>

<author fullname="Stephen E. Deering" initials="S.E." surname="Deering">
<organization>Cisco Systems, Inc.</organization>

<address>
<postal>
<street>170 West Tasman Drive</street>
<street>San Jose</street>
<street>CA 95134-1706</street>
<country>USA</country>
</postal>

<phone>+1 408 527-8213</phone>
<email>deering@cisco.com</email>
</address>
</author>

<date year="1998" month="July" />
<area>Internet</area>
<keyword>IP address</keyword>
<keyword>internet protocol version 6</keyword>
<keyword>multicast</keyword>
<keyword>address</keyword>
</front>

<seriesInfo value="2375" name="RFC" />
<format octets="25446" type="HTML" target="http://xml.resource.org/public/rfc/html/rfc2375.html" />
<format octets="16725" type="XML" target="http://xml.resource.org/public/rfc/xml/rfc2375.xml" />
</reference>


<reference target2="reference.RFC.2376.xml" anchor="RFC2376">
<front>
<title>XML Media Types</title>
<author fullname="E. James Whitehead, Jr." initials="E.J." surname="Whitehead">
<organization>Dept. of Information and Computer Science</organization>

<address>
<postal>
<street>University of California</street>
<street>Irvine</street>
<street>Irvine</street>
<street>CA 92697-3425</street>
</postal>

<email>ejw@ics.uci.edu</email>
</address>
</author>

<author fullname="Murata Makoto" initials="M." surname="Makoto">
<organization>Fuji Xerox Information Systems,</organization>

<address>
<postal>
<street>KSP 9A7</street>
<street>2-1</street>
<street>Sakado 3-chome</street>
<street>Takatsu-ku</street>
<street>Kawasaki-shi</street>
<street>Kanagawa-ken</street>
<street>213</street>
<country>Japan</country>
</postal>

<email>murata@fxis.fujixerox.co.jp</email>
</address>
</author>

<date year="1998" month="July" />
<area>Applications</area>
<keyword>XML</keyword>
<keyword>HTML</keyword>
<keyword>hypertext transfer protocol</keyword>
<keyword>media type</keyword>
<keyword>world wide web</keyword>

<abstract>
<t>
   This document proposes two new media subtypes, text/xml and
   application/xml, for use in exchanging network entities which are
   conforming Extensible Markup Language (XML). XML entities are
   currently exchanged via the HyperText Transfer Protocol on the World
   Wide Web, are an integral part of the WebDAV protocol for remote web
   authoring, and are expected to have utility in many domains.
</t>
</abstract>
</front>

<seriesInfo value="2376" name="RFC" />
<format octets="50314" type="HTML" target="http://xml.resource.org/public/rfc/html/rfc2376.html" />
<format octets="34546" type="XML" target="http://xml.resource.org/public/rfc/xml/rfc2376.xml" />
</reference>


<reference target2="reference.RFC.2377.xml" anchor="RFC2377">
<front>
<title abbrev="A Directory Naming Plan">Naming Plan for Internet Directory-Enabled Applications</title>
<author fullname="Al Grimstad" initials="A." surname="Grimstad">
<organization>AT&amp;T</organization>

<address>
<postal>
<street>Room 1C-429</street>
<street>101 Crawfords Corner Road</street>
<street>Holmdel</street>
<street>NJ 07733-3030</street>
<country>USA</country>
</postal>

<email>alg@att.com</email>
</address>
</author>

<author fullname="Rick Huber" initials="R." surname="Huber">
<organization>AT&amp;T</organization>

<address>
<postal>
<street>Room 1B-433</street>
<street>101 Crawfords Corner Road</street>
<street>Holmdel</street>
<street>NJ 07733-3030</street>
<country>USA</country>
</postal>

<email>rvh@att.com</email>
</address>
</author>

<author fullname="Sri Sataluri" initials="S." surname="Sataluri">
<organization>Lucent Technologies</organization>

<address>
<postal>
<street>Room 4D-335</street>
<street>101 Crawfords Corner Road</street>
<street>Holmdel</street>
<street>NJ 07733-3030</street>
<country>USA</country>
</postal>

<email>srs@lucent.com</email>
</address>
</author>

<author fullname="Mark Wahl" initials="M." surname="Wahl">
<organization>Critical Angle Inc.</organization>

<address>
<postal>
<street>4815 W Braker Lane #502-385</street>
<street>Austin</street>
<street>TX 78759</street>
<country>USA</country>
</postal>

<email>M.Wahl@critical-angle.com</email>
</address>
</author>

<date year="1998" month="September" />
<area>Applications</area>
<keyword>ITU directory service protocol</keyword>
<keyword>X.500</keyword>
<keyword>directory</keyword>

<abstract>
<t>
   Application of the conventional X.500 approach to naming has
   heretofore, in the experience of the authors, proven to be an
   obstacle to the wide deployment of directory-enabled applications on
   the Internet.  We propose a new directory naming plan that leverages
   the strengths of the most popular and successful Internet naming
   schemes for naming objects in a hierarchical directory.  This plan
   can, we believe, by extending the X.500 approach to naming,
   facilitate the creation of an Internet White Pages Service (IWPS) and
   other directory-enabled applications by overcoming the problems
   encountered by those using the conventional X.500 approach.
</t>
</abstract>
</front>

<seriesInfo value="2377" name="RFC" />
<format octets="57487" type="HTML" target="http://xml.resource.org/public/rfc/html/rfc2377.html" />
<format octets="43430" type="XML" target="http://xml.resource.org/public/rfc/xml/rfc2377.xml" />
</reference>


<reference target2="reference.RFC.2378.xml" anchor="RFC2378">
<front>
<title abbrev="CCSO">The CCSO Nameserver (Ph) Architecture</title>
<author fullname="Roland Hedberg" initials="R." surname="Hedberg">
<organization>Umdac</organization>

<address>
<postal>
<street>Umea University</street>
<street>901 87 Umea</street>
<country>Sweden</country>
</postal>

<email>Roland.Hedberg@umdac.umu.se</email>
</address>
</author>

<author fullname="Paul Pomes" initials="P." surname="Pomes">
<organization>Qualcomm Inc</organization>

<address>
<postal>
<street>6455 Lusk Blvd</street>
<street>San Diego</street>
<country>USA</country>
</postal>

<email>ppomes@qualcomm.com</email>
</address>
</author>

<date year="1998" month="September" />
<area>Applications</area>
<keyword>Ph nameserver</keyword>

<abstract>
<t>
   The Ph Nameserver from the Computing and Communications Services
   Office (CCSO), University of Illinois at Urbana-Champaign has for
   some time now been used by several organizations as their choice of
   publicly available database for information about people as well as
   other things.  This document provides a formal definition of the
   client-server protocol.  The Ph service as specified in this document
   is built around an information model, a client command language and
   the server responses.
</t>
</abstract>
</front>

<seriesInfo value="2378" name="RFC" />
<format octets="53563" type="HTML" target="http://xml.resource.org/public/rfc/html/rfc2378.html" />
<format octets="42241" type="XML" target="http://xml.resource.org/public/rfc/xml/rfc2378.xml" />
</reference>


<reference target2="reference.RFC.2379.xml" anchor="RFC2379">
<front>
<title abbrev="RSVP over ATM">RSVP over ATM Implementation Guidelines</title>
<author fullname="Lou Berger" initials="L." surname="Berger">
<organization>FORE Systems</organization>

<address>
<postal>
<street>1595 Spring Hill Road</street>
<street>5th Floor</street>
<street>Vienna</street>
<street>VA 22182</street>
</postal>

<phone>+1 703-245-4527</phone>
<email>lberger@fore.com</email>
</address>
</author>

<date year="1998" month="August" />
<area>Transport</area>
<keyword>ATM</keyword>
<keyword>RSVP</keyword>
<keyword>asynchronous transfer mode</keyword>
<keyword>resource reservation protocol</keyword>
<keyword>switched virtual circuit</keyword>

<abstract>
<t>
   This memo presents specific implementation guidelines for running
   RSVP over ATM switched virtual circuits (SVCs).  The general problem
   is discussed in .  Implementation requirements are discussed in
   .  Integrated Services to ATM service mappings are covered in .
   The full set of documents present the background and information
   needed to implement Integrated Services and RSVP over ATM.
</t>
</abstract>
</front>

<seriesInfo value="24" name="BCP" />
<seriesInfo value="2379" name="RFC" />
<format octets="27415" type="HTML" target="http://xml.resource.org/public/rfc/html/rfc2379.html" />
<format octets="17485" type="XML" target="http://xml.resource.org/public/rfc/xml/rfc2379.xml" />
</reference>


<reference target2="reference.RFC.2380.xml" anchor="RFC2380">
<front>
<title abbrev="RSVP over ATM">RSVP over ATM Implementation Requirements</title>
<author fullname="Lou Berger" initials="L." surname="Berger">
<organization>FORE Systems</organization>

<address>
<postal>
<street>1595 Spring Hill Road</street>
<street>5th Floor</street>
<street>Vienna</street>
<street>VA 22182</street>
</postal>

<phone>+1 703-245-4527</phone>
<email>lberger@fore.com</email>
</address>
</author>

<date year="1998" month="August" />
<area>Transport</area>
<keyword>asynchronous transfer mode</keyword>
<keyword>resource reservation protocol</keyword>
<keyword>switched virtual circuit</keyword>

<abstract>
<t>
   This memo presents specific implementation requirements for running
   RSVP over ATM switched virtual circuits (SVCs).  It presents
   requirements that ensure interoperability between multiple
   implementations and conformance to the RSVP and Integrated Services
   specifications.  A separate document  provides specific guidelines
   for running over today&apos;s ATM networks.  The general problem is
   discussed in .   Integrated Services to ATM service mappings are
   covered in .  The full set of documents present the background and
   information needed to implement Integrated Services and RSVP over
   ATM.
</t>
</abstract>
</front>

<seriesInfo value="2380" name="RFC" />
<format octets="46046" type="HTML" target="http://xml.resource.org/public/rfc/html/rfc2380.html" />
<format octets="32693" type="XML" target="http://xml.resource.org/public/rfc/xml/rfc2380.xml" />
</reference>


<reference target2="reference.RFC.2381.xml" anchor="RFC2381">
<front>
<title abbrev="Interoperation of CLS and GS with ATM">Interoperation of Controlled-Load Service and Guaranteed Service with ATM</title>
<author fullname="Mark W. Garrett" initials="M.W." surname="Garrett">
<organization>Bellcore</organization>

<address>
<postal>
<street>445 South Street</street>
<street>Morristown</street>
<street>NJ 07960</street>
<country>USA</country>
</postal>

<phone>+1 201 829-4439</phone>
<email>mwg@bellcore.com</email>
</address>
</author>

<author fullname="Marty Borden" initials="M." surname="Borden">
<organization>Bay Networks</organization>

<address>
<postal>
<street>42 Nagog Park</street>
<street>Acton</street>
<street>01720</street>
<country>USA</country>
</postal>

<phone>+1 508 266-1011</phone>
<email>mborden@baynetworks.com</email>
</address>
</author>

<date year="1998" month="August" />
<area>Internet</area>
<keyword>asynchronous transfer mode</keyword>
<keyword>quality of service</keyword>

<abstract>
<t>
   This document provides guidelines for mapping service classes, and
   traffic management features and parameters between Internet and ATM
   technologies.  The service mappings are useful for providing
   effective interoperation and end-to-end Quality of Service for IP
   Integrated Services networks containing ATM subnetworks.
</t>

<t>
   The discussion and specifications given here support the IP
   integrated services protocols for Guaranteed Service (GS),
   Controlled-Load Service (CLS) and the ATM Forum UNI specification,
   versions 3.0, 3.1 and 4.0.  Some discussion of IP best effort service
   over ATM is also included.
</t>

<t>
   The key words &quot;MUST&quot;, &quot;MUST NOT&quot;, &quot;REQUIRED&quot;, &quot;SHALL&quot;, &quot;SHALL NOT&quot;,
   &quot;SHOULD&quot;, &quot;SHOULD NOT&quot;, &quot;RECOMMENDED&quot;, &quot;MAY&quot;, and &quot;OPTIONAL&quot; in this
   document are to be interpreted as described in RFC 2119 .  (Note,
   in many cases the use of &quot;MUST&quot; or &quot;REQUIRED&quot; reflects our
   interpretation of the requirements of a related standard, e.g., ATM
   Forum UNI 4.0, rsvp, etc.)
</t>
</abstract>
</front>

<seriesInfo value="2381" name="RFC" />
<format octets="127523" type="HTML" target="http://xml.resource.org/public/rfc/html/rfc2381.html" />
<format octets="109844" type="XML" target="http://xml.resource.org/public/rfc/xml/rfc2381.xml" />
</reference>


<reference target2="reference.RFC.2382.xml" anchor="RFC2382">
<front>
<title abbrev="Integrated Services and RSVP over ATM">A Framework for Integrated Services and RSVP over ATM</title>
<author fullname="Eric S. Crawley" initials="E.S." surname="Crawley">
<organization>Argon Networks</organization>

<address>
<postal>
<street>25 Porter Road</street>
<street>Littleton</street>
<street>Ma 01460</street>
</postal>

<phone>+1 978 486-0665</phone>
<email>esc@argon.com</email>
</address>
</author>

<author fullname="Lou Berger" initials="L." surname="Berger">
<organization>FORE Systems</organization>

<address>
<postal>
<street>6905 Rockledge Drive</street>
<street>Suite 800</street>
<street>Bethesda</street>
<street>MD 20817</street>
</postal>

<phone>+1 301 571-2534</phone>
<email>lberger@fore.com</email>
</address>
</author>

<author fullname="Steven Berson" initials="S." surname="Berson">
<organization>USC Information Sciences Institute</organization>

<address>
<postal>
<street>4676 Admiralty Way</street>
<street>Marina del Rey</street>
<street>CA 90292</street>
</postal>

<phone>+1 310 822-1511</phone>
<email>berson@isi.edu</email>
</address>
</author>

<author fullname="Fred Baker" initials="F." surname="Baker">
<organization>Cisco Systems</organization>

<address>
<postal>
<street>519 Lado Drive</street>
<street>Santa Barbara</street>
<street>California 93111</street>
</postal>

<phone>+1 805 681-0115</phone>
<email>fred@cisco.com</email>
</address>
</author>

<author fullname="Marty Borden" initials="M." surname="Borden">
<organization>Bay Networks</organization>

<address>
<postal>
<street>125 Nagog Park</street>
<street>Acton</street>
<street>MA 01720</street>
</postal>

<phone>+1 978 266-1011</phone>
<email>mborden@baynetworks.com</email>
</address>
</author>

<author fullname="John J. Krawczyk" initials="J.J." surname="Krawczyk">
<organization>ArrowPoint Communications</organization>

<address>
<postal>
<street>235 Littleton Road</street>
<street>Westford</street>
<street>Massachusetts 01886</street>
</postal>

<phone>+1 978 692-5875</phone>
<email>jj@arrowpoint.com</email>
</address>
</author>

<date year="1998" month="August" />
<area>Transport</area>
<keyword>RSVP</keyword>
<keyword>asynchronous transfer mode</keyword>
<keyword>integrated services</keyword>
<keyword>resource reservation protocol</keyword>

<abstract>
<t>
   This document outlines the issues and framework related to providing
   IP Integrated Services with RSVP over ATM. It provides an overall
   approach to the problem(s) and related issues.  These issues and
   problems are to be addressed in further documents from the ISATM
   subgroup of the ISSLL working group.
</t>
</abstract>
</front>

<seriesInfo value="2382" name="RFC" />
<format octets="97259" type="HTML" target="http://xml.resource.org/public/rfc/html/rfc2382.html" />
<format octets="81104" type="XML" target="http://xml.resource.org/public/rfc/xml/rfc2382.xml" />
</reference>


<reference target2="reference.RFC.2383.xml" anchor="RFC2383">
<front>
<title abbrev="ST2+ over ATM">ST2+ over ATM Protocol Specification - UNI 3.1 Version</title>
<author fullname="Muneyoshi Suzuki" initials="M." surname="Suzuki">
<organization>NTT Multimedia Networks Laboratories</organization>

<address>
<postal>
<street>3-9-11</street>
<street>Midori-cho</street>
<street>Musashino-shi</street>
<street>Tokyo 180-8585</street>
<country>Japan</country>
</postal>

<phone>+81-422-59-2119</phone>
<facsimile>+81-422-59-2829</facsimile>
<email>suzuki@nal.ecl.net</email>
</address>
</author>

<date year="1998" month="August" />
<area>Internet</area>
<keyword>ATM</keyword>
<keyword>asynchronous transfer mode</keyword>
<keyword>internet stream protocol</keyword>

<abstract>
<t>
   This document specifies an ATM-based protocol for communication
   between ST2+ agents. The ST2+ over ATM protocol supports the matching
   of one hop in an ST2+ tree-structure stream with one ATM connection.
   In this document, ATM is a subnet technology for the ST2+ stream.
</t>

<t>
   The ST2+ over ATM protocol is designed to achieve resource-
   reservation communications across ATM and non-ATM networks, to extend
   the UNI 3.1/4.0 signaling functions, and to reduce the UNI 4.0 LIJ
   signaling limitations.
</t>

<t>
   The specifications of the ST2+ over ATM protocol consist of a
   revision of RFC 1819 ST2+ and specifications of protocol interaction
   between ST2+ and ATM on the user plane, management plane, and control
   plane which correspond to the three planes of the B-ISDN protocol
   reference model.
</t>
</abstract>
</front>

<seriesInfo value="2383" name="RFC" />
<format octets="124510" type="HTML" target="http://xml.resource.org/public/rfc/html/rfc2383.html" />
<format octets="106698" type="XML" target="http://xml.resource.org/public/rfc/xml/rfc2383.xml" />
</reference>


<reference target2="reference.RFC.2384.xml" anchor="RFC2384">
<front>
<title>POP URL Scheme</title>
<author fullname="Randall Gellens" initials="R." surname="Gellens">
<organization>QUALCOMM, Incorporated</organization>

<address>
<postal>
<street>6455 Lusk Blvd.</street>
<street>San Diego</street>
<street>CA  92121-2779</street>
<street>U.S.A.</street>
</postal>

<phone>+1 619 651 5115</phone>
<facsimile>+1 619 651 5334</facsimile>
<email>Randy@Qualcomm.Com</email>
</address>
</author>

<date year="1998" month="August" />
<area>Applications</area>
<keyword>POP</keyword>
<keyword>post office protocol</keyword>
<keyword>uniform resource</keyword>
</front>

<seriesInfo value="2384" name="RFC" />
<format octets="29313" type="HTML" target="http://xml.resource.org/public/rfc/html/rfc2384.html" />
<format octets="16367" type="XML" target="http://xml.resource.org/public/rfc/xml/rfc2384.xml" />
</reference>


<reference target2="reference.RFC.2385.xml" anchor="RFC2385">
<front>
<title abbrev="TCP MD5 Signature Option">Protection of BGP Sessions via the TCP MD5 Signature Option</title>
<author fullname="Andy Heffernan" initials="A." surname="Heffernan">
<organization>cisco Systems</organization>

<address>
<postal>
<street>170 West Tasman Drive</street>
<street>San Jose</street>
<street>CA  95134</street>
<country>USA</country>
</postal>

<phone>+1 408 526-8115</phone>
<email>ahh@cisco.com</email>
</address>
</author>

<date year="1998" month="August" />
<area>Security</area>
<area>Routing</area>
<keyword>attack</keyword>
<keyword>border gateway protocol</keyword>
<keyword>BGP</keyword>
<keyword>message digest</keyword>
<keyword>security</keyword>
<keyword>transmission control protocol</keyword>

<abstract>
<t>
   This document describes currrent existing practice for securing BGP
   against certain simple attacks.  It is understood to have security
   weaknesses against concerted attacks.
</t>

<t>
   This memo describes a TCP extension to enhance security for BGP.  It
   defines a new TCP option for carrying an MD5  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.
</t>
</abstract>

<note title="IESG Note">
<t>
   This document describes currrent existing practice for securing BGP
   against certain simple attacks.  It is understood to have security
   weaknesses against concerted attacks.
</t>
</note>
</front>

<seriesInfo value="2385" name="RFC" />
<format octets="23602" type="HTML" target="http://xml.resource.org/public/rfc/html/rfc2385.html" />
<format octets="12652" type="XML" target="http://xml.resource.org/public/rfc/xml/rfc2385.xml" />
</reference>


<reference target2="reference.RFC.2386.xml" anchor="RFC2386">
<front>
<title abbrev="A Framework for QoS-based Routing">A Framework for QoS-based Routing in the Internet</title>
<author fullname="Eric S. Crawley" initials="E.S." surname="Crawley">
<organization>Argon Networks, Inc.</organization>

<address>
<postal>
<street>25 Porter Rd.</street>
<street>U.S.A</street>
<city>Littelton</city>
<region>MA</region>
<code>01460</code>
</postal>

<phone>+1-508-486-0665</phone>
<email>esc@argon.com</email>
</address>
</author>

<author fullname="Raj Nair" initials="R." surname="Nair">
<organization>Arrowpoint</organization>

<address>
<postal>
<street>235 Littleton Rd.</street>
<street>U.S.A</street>
<city>Westford</city>
<region>MA</region>
<code>01886</code>
</postal>

<phone>+1-508-692-5875, x29</phone>
<email>nair@arrowpoint.com</email>
</address>
</author>

<author fullname="Bala Rajagopalan" initials="B." surname="Rajagopalan">
<organization>NEC USA, C&amp;C Research Labs</organization>

<address>
<postal>
<street>4 Independence Way</street>
<street>U.S.A</street>
<city>Princeton</city>
<region>NJ</region>
<code>08540</code>
</postal>

<phone>+1-609-951-2969</phone>
<email>braja@ccrl.nj.nec.com</email>
</address>
</author>

<author fullname="Hal Sandick" initials="H." surname="Sandick">
<organization>Bay Networks, Inc.</organization>

<address>
<postal>
<street>1009 Slater Rd., Suite 220</street>
<street>U.S.A</street>
<city>Durham</city>
<region>NC</region>
<code>27703</code>
</postal>

<phone>+1-919-941-1739</phone>
<email>Hsandick@baynetworks.com</email>
</address>
</author>

<date year="1998" month="August" />
<area>Routing</area>
<keyword>quality of service</keyword>
<keyword>routing</keyword>

<abstract>
<t>
   QoS-based routing has been recognized as a missing piece in the

   evolution of QoS-based service offerings in the Internet. This

   document describes some of the QoS-based routing issues and

   requirements, and proposes a framework for QoS-based routing in the

   Internet. This framework is based on extending the current Internet

   routing model of intra and interdomain routing to support QoS.
</t>
</abstract>
</front>

<seriesInfo value="2386" name="RFC" />
<format octets="105976" type="HTML" target="http://xml.resource.org/public/rfc/html/rfc2386.html" />
<format octets="104554" type="XML" target="http://xml.resource.org/public/rfc/xml/rfc2386.xml" />
</reference>


<reference target2="reference.RFC.2387.xml" anchor="RFC2387">
<front>
<title abbrev="Multipart/Related">The MIME Multipart/Related Content-type</title>
<author fullname="Edward Levinson" initials="E." surname="Levinson">
<organization />

<address>
<postal>
<street>47 Clive Street</street>
<street>Metuchen</street>
<street>NJ  08840-1060</street>
<country>USA</country>
</postal>

<phone>+1 908 494 1606</phone>
<email>XIson@cnj.digex.com</email>
</address>
</author>

<date year="1998" month="August" />
<area>Applications</area>
<keyword>content-type</keyword>
<keyword>multipurpose internet mail extensions</keyword>

<abstract>
<t>
   The Multipart/Related content-type provides a common mechanism for
   representing objects that are aggregates of related MIME body parts.
   This document defines the Multipart/Related content-type and provides
   examples of its use.
</t>
</abstract>
</front>

<seriesInfo value="2387" name="RFC" />
<format octets="33486" type="HTML" target="http://xml.resource.org/public/rfc/html/rfc2387.html" />
<format octets="20549" type="XML" target="http://xml.resource.org/public/rfc/xml/rfc2387.xml" />
</reference>


<reference target2="reference.RFC.2388.xml" anchor="RFC2388">
<front>
<title abbrev="multipart/form-data">Returning Values from Forms:  multipart/form-data</title>
<author fullname="Larry Masinter" initials="L." surname="Masinter">
<organization>Xerox Palo Alto Research Center</organization>

<address>
<postal>
<street>3333 Coyote Hill Road</street>
<street>Palo Alto</street>
<street>CA 94304</street>
</postal>

<facsimile>+1 650 812 4333</facsimile>
<email>masinter@parc.xerox.com</email>
</address>
</author>

<date year="1998" month="August" />
<area>Applications</area>
<keyword>media type</keyword>
</front>

<seriesInfo value="2388" name="RFC" />
<format octets="30032" type="HTML" target="http://xml.resource.org/public/rfc/html/rfc2388.html" />
<format octets="18370" type="XML" target="http://xml.resource.org/public/rfc/xml/rfc2388.xml" />
</reference>


<reference target2="reference.RFC.2389.xml" anchor="RFC2389">
<front>
<title abbrev="Feature negotiation mechanism">Feature negotiation mechanism for the File Transfer Protocol</title>
<author fullname="Paul Hethmon" initials="P." surname="Hethmon">
<organization>Hethmon Brothers</organization>

<address>
<postal>
<street>2305 Chukar Road</street>
<street>Knoxville</street>
<street>TN 37923</street>
<country>USA</country>
</postal>

<phone>+1 423 690 8990</phone>
<email>phethmon@hethmon.com</email>
</address>
</author>

<author fullname="Robert Elz" initials="R." surname="Elz">
<organization>University of Melbourne</organization>

<address>
<postal>
<street>Department of Computer Science</street>
<street>Parkville</street>
<street>Vic   3052</street>
<country>Australia</country>
</postal>

<email>kre@munnari.OZ.AU</email>
</address>
</author>

<date year="1998" month="August" />
<area>Applications</area>
<keyword>FTP</keyword>
<keyword>file transfer</keyword>
<keyword>file transfer protocol</keyword>

<abstract>
<t>
   The File Transfer Protocol is, from time to time, extended with new
   commands, or facilities.  Implementations of the FTP protocol cannot
   be assumed to all immediately implement all newly defined mechanisms.
   This document provides a mechanism by which clients of the FTP
   protocol can discover which new features are supported by a
   particular FTP server.
</t>
</abstract>
</front>

<seriesInfo value="2389" name="RFC" />
<format octets="30084" type="HTML" target="http://xml.resource.org/public/rfc/html/rfc2389.html" />
<format octets="17755" type="XML" target="http://xml.resource.org/public/rfc/xml/rfc2389.xml" />
</reference>


<reference target2="reference.RFC.2390.xml" anchor="RFC2390">
<front>
<title>Inverse Address Resolution Protocol</title>
<author fullname="Terry Bradley" initials="T." surname="Bradley">
<organization>Avici Systems, Inc.</organization>

<address>
<postal>
<street>12 Elizabeth Drive</street>
<street>Chelmsford</street>
<street>MA  01824</street>
</postal>

<phone>(978) 250-3344</phone>
<email>tbradley@avici.com</email>
</address>
</author>

<author fullname="Caralyn Brown" initials="C." surname="Brown">
<organization>Consultant</organization>

<address>
<email>cbrown@juno.com</email>
</address>
</author>

<author fullname="Andrew Malis" initials="A." surname="Malis">
<organization>Ascend Communications, Inc.</organization>

<address>
<postal>
<street>1 Robbins Road</street>
<street>Westford</street>
<street>MA  01886</street>
</postal>

<phone>(978) 952-7414</phone>
<email>malis@ascend.com</email>
</address>
</author>

<date year="1998" month="September" />
<area>Internet</area>
<keyword>ARP</keyword>
<keyword>address resolution protocol</keyword>
<keyword>frame relay</keyword>
<keyword>inverse address resolution protocol</keyword>
<keyword>switched virtual circuit</keyword>
</front>

<seriesInfo value="2390" name="RFC" />
<format octets="34729" type="HTML" target="http://xml.resource.org/public/rfc/html/rfc2390.html" />
<format octets="22236" type="XML" target="http://xml.resource.org/public/rfc/xml/rfc2390.xml" />
</reference>


<reference target2="reference.RFC.2391.xml" anchor="RFC2391">
<front>
<title abbrev="LSNAT">Load Sharing using IP Network Address Translation (LSNAT)</title>
<author fullname="Pyda Srisuresh" initials="P." surname="Srisuresh">
<organization>Lucent Technologies</organization>

<address>
<postal>
<street>4464 Willow Road</street>
<street>Pleasanton</street>
<street>CA 94588-8519</street>
<street>U.S.A.</street>
</postal>

<facsimile>(925) 737-2110</facsimile>
<email>suresh@ra.lucent.com</email>
</address>
</author>

<author fullname="Der-hwa Gan" initials="D." surname="Gan">
<organization>Juniper Networks, Inc.</organization>

<address>
<postal>
<street>385 Ravensdale Drive.</street>
<street>Mountain View</street>
<street>CA 94043</street>
<street>U.S.A.</street>
</postal>

<facsimile>(650) 526-8001</facsimile>
<email>dhg@juniper.net</email>
</address>
</author>

<date year="1998" month="August" />
<area>Internet</area>
<keyword>NAT</keyword>
<keyword>network address translation</keyword>
<keyword>routing</keyword>

<abstract>
<t>
   This document combines the idea of address translation described in
   RFC 1631 with real-time load share algorithms to introduce Load Share
   Network Address Translators(or, simply LSNATs). LSNATs would
   transparently offload network load on a single server and distribute
   the load across a pool of servers.
</t>

<t>
   Network Address Translators (NATs) translate IP addresses in a
   datagram, transparent to end nodes, while routing the datagram. NATs
   have traditionally been been used to allow private network domains to
   connect to Global networks using as few as one globally unique IP
   address.  In this document, we extend the use of NATs to offer Load
   share feature, where session load can be distributed across a pool of
   servers, instead of directing to a single server.  Load sharing is
   beneficial to service providers and system administrators alike in
   grappling with scalability of servers with increasing session load.
</t>
</abstract>

<note title="IESG Note">
<t>
   This document combines the idea of address translation described in
   RFC 1631 with real-time load share algorithms to introduce Load Share
   Network Address Translators(or, simply LSNATs). LSNATs would
   transparently offload network load on a single server and distribute
   the load across a pool of servers.
</t>
</note>
</front>

<seriesInfo value="2391" name="RFC" />
<format octets="57852" type="HTML" target="http://xml.resource.org/public/rfc/html/rfc2391.html" />
<format octets="46681" type="XML" target="http://xml.resource.org/public/rfc/xml/rfc2391.xml" />
</reference>


<reference target2="reference.RFC.2392.xml" anchor="RFC2392">
<front>
<title abbrev="Message- &amp; Content-ID URLs">Content-ID and Message-ID Uniform Resource Locators</title>
<author fullname="Edward Levinson" initials="E." surname="Levinson">
<organization />

<address>
<postal>
<street>47 Clive Street</street>
<street>Metuchen</street>
<street>NJ  08840-1060</street>
<country>USA</country>
</postal>

<phone>+1 908 549 3716</phone>
<email>XIson@cnj.digex.net</email>
</address>
</author>

<date year="1998" month="August" />
<area>Applications</area>
<keyword>content-type</keyword>
<keyword>encapsulate</keyword>
<keyword>hypertext markup language</keyword>
<keyword>multipurpose internet mail extensions</keyword>
<keyword>uniform resource</keyword>

<abstract>
<t>
   The Uniform Resource Locator (URL) schemes, &quot;cid:&quot; and &quot;mid:&quot; allow
   references to messages and the body parts of messages.  For example,
   within a single multipart message, one HTML body part might include
   embedded references to other parts of the same message.
</t>
</abstract>
</front>

<seriesInfo value="2392" name="RFC" />
<format octets="23113" type="HTML" target="http://xml.resource.org/public/rfc/html/rfc2392.html" />
<format octets="11888" type="XML" target="http://xml.resource.org/public/rfc/xml/rfc2392.xml" />
</reference>


<reference target2="reference.RFC.2393.xml" anchor="RFC2393">
<front>
<title abbrev="IPComp">IP Payload Compression Protocol (IPComp)</title>
<author fullname="Abraham Shacham" initials="A." surname="Shacham">
<organization>Cisco Systems</organization>

<address>
<postal>
<street>170 West Tasman Drive</street>
<street>San Jose</street>
<street>California 95134</street>
<country>United States of America</country>
</postal>

<email>shacham@cisco.com</email>
</address>
</author>

<author fullname="Robert Monsour" initials="R." surname="Monsour">
<organization>Hi/fn Inc.</organization>

<address>
<postal>
<street>2105 Hamilton Avenue</street>
<street>Suite 230</street>
<street>San Jose</street>
<street>California 95125</street>
<country>United States of America</country>
</postal>

<email>rmonsour@hifn.com</email>
</address>
</author>

<author fullname="Roy Pereira" initials="R." surname="Pereira">
<organization>TimeStep Corporation</organization>

<address>
<postal>
<street>362 Terry Fox Drive</street>
<street>Kanata</street>
<street>Ontario K2K 2P5</street>
<country>Canada</country>
</postal>

<email>rpereira@timestep.com</email>
</address>
</author>

<author fullname="Matt Thomas" initials="M." surname="Thomas">
<organization>AltaVista Internet Software</organization>

<address>
<postal>
<street>30 Porter Road</street>
<street>Littleton</street>
<street>Massachusetts 01460</street>
<country>United States of America</country>
</postal>

<email>matt.thomas@altavista-software.com</email>
</address>
</author>

<date year="1998" month="December" />
<area>Internet</area>
<keyword>IP</keyword>
<keyword>compress</keyword>

<abstract>
<t>
   This document describes a protocol intended to provide lossless
   compression for Internet Protocol datagrams in an Internet
   environment.
</t>
</abstract>
</front>

<seriesInfo value="2393" name="RFC" />
<format octets="36067" type="HTML" target="http://xml.resource.org/public/rfc/html/rfc2393.html" />
<format octets="22472" type="XML" target="http://xml.resource.org/public/rfc/xml/rfc2393.xml" />
</reference>


<reference target2="reference.RFC.2394.xml" anchor="RFC2394">
<front>
<title>IP Payload Compression Using DEFLATE</title>
<author fullname="Roy Pereira" initials="R." surname="Pereira">
<organization>TimeStep Corporation</organization>

<address>
<phone>+1 (613) 599-3610 x 4808</phone>
<email>rpereira@timestep.com</email>
</address>
</author>

<date year="1998" month="December" />
<area>Internet</area>
<keyword>IP</keyword>
<keyword>compress</keyword>

<abstract>
<t>
   This document describes a compression method based on the DEFLATE
   compression algorithm.  This document defines the application of the
   DEFLATE algorithm to the IP Payload Compression Protocol.
</t>
</abstract>
</front>

<seriesInfo value="2394" name="RFC" />
<format octets="22391" type="HTML" target="http://xml.resource.org/public/rfc/html/rfc2394.html" />
<format octets="11088" type="XML" target="http://xml.resource.org/public/rfc/xml/rfc2394.xml" />
</reference>


<reference target2="reference.RFC.2395.xml" anchor="RFC2395">
<front>
<title>IP Payload Compression Using LZS</title>
<author fullname="Robert Friend" initials="R." surname="Friend">
<organization>Hi/fn Inc.</organization>

<address>
<postal>
<street>5973 Avenida Encinas</street>
<street>Suite 110</street>
<street>Carlsbad</street>
<street>CA  92008</street>
</postal>

<email>rfriend@hifn.com</email>
</address>
</author>

<author fullname="Robert Monsour" initials="R." surname="Monsour">
<organization>Hi/fn Inc.</organization>

<address>
<postal>
<street>2105 Hamilton Avenue</street>
<street>Suite 230</street>
<street>San Jose</street>
<street>CA 95125</street>
</postal>

<email>rmonsour@hifn.com</email>
</address>
</author>

<date year="1998" month="December" />
<area>Internet</area>
<keyword>IP</keyword>
<keyword>compress</keyword>

<abstract>
<t>
   This document describes a compression method based on the LZS
   compression algorithm. This document defines the application of the
   LZS algorithm to the IP Payload Compression Protocol .
    defines a method for applying lossless compression to the
   payloads of Internet Protocol datagrams.
</t>
</abstract>
</front>

<seriesInfo value="2395" name="RFC" />
<format octets="28342" type="HTML" target="http://xml.resource.org/public/rfc/html/rfc2395.html" />
<format octets="15962" type="XML" target="http://xml.resource.org/public/rfc/xml/rfc2395.xml" />
</reference>


<reference target2="reference.RFC.2396.xml" anchor="RFC2396">
<front>
<title abbrev="URI Generic Syntax">Uniform Resource Identifiers (URI): Generic Syntax</title>
<author fullname="Tim Berners-Lee" initials="T." surname="Berners-Lee">
<organization abbrev="MIT/LCS">World Wide Web Consortium</organization>

<address>
<postal>
<street>MIT Laboratory for Computer Science, NE43-356</street>
<street>545 Technology Square</street>
<city>Cambridge</city>
<region>MA</region>
<code>02139</code>
</postal>

<facsimile>+1(617)258-8682</facsimile>
<email>timbl@w3.org</email>
</address>
</author>

<author fullname="Roy T. Fielding" initials="R.T." surname="Fielding">
<organization abbrev="U.C. Irvine">Department of Information and Computer Science</organization>

<address>
<postal>
<street>University of California, Irvine</street>
<city>Irvine</city>
<region>CA</region>
<code>92697-3425</code>
</postal>

<facsimile>+1(949)824-1715</facsimile>
<email>fielding@ics.uci.edu</email>
</address>
</author>

<author fullname="Larry Masinter" initials="L." surname="Masinter">
<organization abbrev="Xerox Corporation">Xerox PARC</organization>

<address>
<postal>
<street>3333 Coyote Hill Road</street>
<city>Palo Alto</city>
<region>CA</region>
<code>94034</code>
</postal>

<facsimile>+1(415)812-4333</facsimile>
<email>masinter@parc.xerox.com</email>
</address>
</author>

<date year="1998" month="August" />
<area>Applications</area>
<keyword>uniform resource</keyword>
<keyword>URI</keyword>

<abstract>
<t>
   A Uniform Resource Identifier (URI) is a compact string of characters
   for identifying an abstract or physical resource.  This document
   defines the generic syntax of URI, including both absolute and
   relative forms, and guidelines for their use; it revises and replaces
   the generic definitions in RFC 1738 and RFC 1808.
</t>

<t>
   This document defines a grammar that is a superset of all valid URI,
   such that an implementation can parse the common components of a URI
   reference without knowing the scheme-specific requirements of every
   possible identifier type.  This document does not define a generative
   grammar for URI; that task will be performed by the individual
   specifications of each URI scheme.
</t>
</abstract>

<note title="IESG Note">
<t>
   This paper describes a "superset" of operations that can be applied
   to URI.  It consists of both a grammar and a description of basic
   functionality for URI.  To understand what is a valid URI, both the
   grammar and the associated description have to be studied.  Some of
   the functionality described is not applicable to all URI schemes, and
   some operations are only possible when certain media types are
   retrieved using the URI, regardless of the scheme used.
</t>
</note>
</front>

<seriesInfo value="2396" name="RFC" />
<format octets="114242" type="HTML" target="http://xml.resource.org/public/rfc/html/rfc2396.html" />
<format octets="95582" type="XML" target="http://xml.resource.org/public/rfc/xml/rfc2396.xml" />
</reference>


<reference target2="reference.RFC.2397.xml" anchor="RFC2397">
<front>
<title abbrev="The &quot;data&quot; URL scheme">The &quot;data&quot; URL scheme</title>
<author fullname="Larry Masinter" initials="L." surname="Masinter">
<organization>Xerox Palo Alto Research Center</organization>

<address>
<postal>
<street>3333 Coyote Hill Road</street>
<street>Palo Alto</street>
<street>CA 94304</street>
</postal>

<email>masinter@parc.xerox.com</email>
</address>
</author>

<date year="1998" month="August" />
<area>Applications</area>
<keyword>URL</keyword>
<keyword>uniform resource</keyword>
</front>

<seriesInfo value="2397" name="RFC" />
<format octets="20874" type="HTML" target="http://xml.resource.org/public/rfc/html/rfc2397.html" />
<format octets="9795" type="XML" target="http://xml.resource.org/public/rfc/xml/rfc2397.xml" />
</reference>


<reference target2="reference.RFC.2398.xml" anchor="RFC2398">
<front>
<title>Some Testing Tools for TCP Implementors</title>
<author fullname="Steve Parker" initials="S." surname="Parker">
<organization>Sun Microsystems, Inc.</organization>

<address>
<postal>
<street>901 San Antonio Road</street>
<street>UMPK17-202</street>
<street>Palo Alto</street>
<street>CA 94043</street>
<country>USA</country>
</postal>

<phone>(650) 786-5176</phone>
<email>sparker@eng.sun.com</email>
</address>
</author>

<author fullname="Chris Schmechel" initials="C." surname="Schmechel">
<organization>Sun Microsystems, Inc.</organization>

<address>
<postal>
<street>901 San Antonio Road</street>
<street>UMPK17-202</street>
<street>Palo Alto</street>
<street>94043</street>
<country>USA</country>
</postal>

<phone>(650) 786-4053</phone>
<email>cschmec@eng.sun.com</email>
</address>
</author>

<date year="1998" month="August" />
<area>Transport</area>
<keyword>tool</keyword>
<keyword>transmission control protocol</keyword>
</front>

<seriesInfo value="2398" name="RFC" />
<format octets="40534" type="HTML" target="http://xml.resource.org/public/rfc/html/rfc2398.html" />
<format octets="26791" type="XML" target="http://xml.resource.org/public/rfc/xml/rfc2398.xml" />
</reference>


<reference target2="reference.RFC.2399.xml" anchor="RFC2399">
<front>
<title abbrev="Summary of 2300-2399">Request for Comments Summary</title>
<author fullname="Alegre Ramos" initials="A." surname="Ramos">
<organization>University of Southern California,  Information Sciences Institute</organization>

<address>
<postal>
<street>4676 Admiralty Way</street>
<city>Marina del Rey</city>
<region>CA</region>
<code>90292</code>
<country>US</country>
</postal>

<phone>+1 310 822 1511</phone>
<email>ramos@isi.edu</email>
</address>
</author>

<date year="1999" month="January" />
</front>

<seriesInfo value="2399" name="RFC" />
</reference>


<reference target2="reference.RFC.2400.xml" anchor="RFC2400">
<front>
<title>INTERNET OFFICIAL PROTOCOL STANDARDS</title>
<author fullname="Jon Postel" initials="J." surname="Postel">
<organization>USC/Information Sciences Institute</organization>

<address>
<postal>
<street>4676 Admiralty Way</street>
<street>Marina del Rey</street>
<street>CA 90292</street>
</postal>

<phone>310-822-1511</phone>
<facsimile>310-823-6714</facsimile>
<email>Postel@ISI.EDU</email>
</address>
</author>

<author fullname="Joyce K. Reynolds" initials="J.K." surname="Reynolds">
<organization>USC/Information Sciences Institute</organization>

<address>
<postal>
<street>4676 Admiralty Way</street>
<street>Marina del Rey</street>
<street>CA 90292</street>
</postal>

<phone>310-822-1511</phone>
<facsimile>310-823-6714</facsimile>
<email>JKRey@ISI.EDU</email>
</address>
</author>

<date year="1998" month="September" />
<area>General</area>
<keyword>Internet Architecture Board</keyword>
<keyword>official internet protocol</keyword>

<abstract>
<t>
   A discussion of the standardization process and the RFC document
   series is presented first, followed by an explanation of the terms.
   Sections 6.2 - 6.10 contain the lists of protocols in each stage of
   standardization.  Finally, there are pointers to references and
   contacts for further information.
</t>

<t>
   This memo is intended to be issued every one hundred RFCs; please be
   sure the copy you are reading is current.  Current copies may be
   obtained from the Requests for Comments Editor (RFC-EDITOR) or from
   the Internet Assigned Numbers Authority (IANA) (see the contact
   information at the end of this memo).
</t>

<t>
   See Section 6.1 for a description of recent changes.  In the official
   lists in sections 6.2 - 6.10, an asterisk (*) next to a protocol
   denotes that it is new to this document or has been moved from one
   protocol level to another, or differs from the previous edition of
   this document.
</t>
</abstract>
</front>

<seriesInfo value="1" name="STD" />
<seriesInfo value="2400" name="RFC" />
<format octets="122324" type="HTML" target="http://xml.resource.org/public/rfc/html/rfc2400.html" />
<format octets="106368" type="XML" target="http://xml.resource.org/public/rfc/xml/rfc2400.xml" />
</reference>


<reference target2="reference.RFC.2401.xml" anchor="RFC2401">
<front>
<title abbrev="Security Architecture">Security Architecture for the Internet Protocol</title>
<author fullname="Stephen Kent" initials="S." surname="Kent">
<organization>BBN Corporation</organization>

<address>
<postal>
<street>70 Fawcett Street</street>
<street>Cambridge</street>
<street>MA  02140</street>
<country>USA</country>
</postal>

<phone>+1 (617) 873-3988</phone>
<email>kent@bbn.com</email>
</address>
</author>

<author fullname="Randall Atkinson" initials="R." surname="Atkinson">
<organization>@Home Network</organization>

<address>
<postal>
<street>425 Broadway</street>
<street>Redwood City</street>
<street>CA 94063</street>
<country>USA</country>
</postal>

<phone>+1 (415) 569-5000</phone>
<email>rja@corp.home.net</email>
</address>
</author>

<date year="1998" month="November" />
<area>Security</area>
<keyword>IP security protocol</keyword>
<keyword>IPSEC</keyword>
<keyword>internet protocol version 6</keyword>
<keyword>security</keyword>
</front>

<seriesInfo value="2401" name="RFC" />
<format octets="186006" type="HTML" target="http://xml.resource.org/public/rfc/html/rfc2401.html" />
<format octets="166999" type="XML" target="http://xml.resource.org/public/rfc/xml/rfc2401.xml" />
</reference>


<reference target2="reference.RFC.2402.xml" anchor="RFC2402">
<front>
<title>IP Authentication Header</title>
<author fullname="Stephen Kent" initials="S." surname="Kent">
<organization>BBN Corporation</organization>

<address>
<postal>
<street>70 Fawcett Street</street>
<street>Cambridge</street>
<street>MA  02140</street>
<country>USA</country>
</postal>

<phone>+1 (617) 873-3988</phone>
<email>kent@bbn.com</email>
</address>
</author>

<author fullname="Randall Atkinson" initials="R." surname="Atkinson">
<organization>@Home Network</organization>

<address>
<postal>
<street>425 Broadway</street>
<street>Redwood City</street>
<street>CA  94063</street>
<country>USA</country>
</postal>

<phone>+1 (415) 569-5000</phone>
<email>rja@corp.home.net</email>
</address>
</author>

<date year="1998" month="November" />
<area>Internet</area>
<area>Security</area>
<keyword>IP security protocol</keyword>
<keyword>authentication</keyword>
<keyword>internet protocol version 6</keyword>
</front>

<seriesInfo value="2402" name="RFC" />
<format octets="66311" type="HTML" target="http://xml.resource.org/public/rfc/html/rfc2402.html" />
<format octets="52029" type="XML" target="http://xml.resource.org/public/rfc/xml/rfc2402.xml" />
</reference>


<reference target2="reference.RFC.2403.xml" anchor="RFC2403">
<front>
<title>The Use of HMAC-MD5-96 within ESP and AH</title>
<author fullname="Cheryl Madson" initials="C." surname="Madson">
<organization>Cisco Systems, Inc.</organization>

<address>
<email>cmadson@cisco.com</email>
</address>
</author>

<author fullname="Rob Glenn" initials="R." surname="Glenn">
<organization>NIST</organization>

<address>
<email>rob.glenn@nist.gov</email>
</address>
</author>

<date year="1998" month="November" />
<area>Security</area>
<area>Internet</area>
<keyword>IP security protocol</keyword>
<keyword>authentication</keyword>
<keyword>cryptographic hash message authentication codes</keyword>
<keyword>encapsulate</keyword>
<keyword>encapsulating security payload</keyword>
<keyword>message digest</keyword>
<keyword>security</keyword>

<abstract>
<t>
   This memo describes the use of the HMAC algorithm  in
   conjunction with the MD5 algorithm  as an authentication
   mechanism within the revised IPSEC Encapsulating Security Payload
    and the revised IPSEC Authentication Header . HMAC with MD5
   provides data origin authentication and integrity protection.
</t>

<t>
   Further information on the other components necessary for ESP and AH
   implementations is provided by .
</t>
</abstract>
</front>

<seriesInfo value="2403" name="RFC" />
<format octets="29345" type="HTML" target="http://xml.resource.org/public/rfc/html/rfc2403.html" />
<format octets="16007" type="XML" target="http://xml.resource.org/public/rfc/xml/rfc2403.xml" />
</reference>


<reference target2="reference.RFC.2404.xml" anchor="RFC2404">
<front>
<title>The Use of HMAC-SHA-1-96 within ESP and AH</title>
<author fullname="Cheryl Madson" initials="C." surname="Madson">
<organization>Cisco Systems, Inc.</organization>

<address>
<email>cmadson@cisco.com</email>
</address>
</author>

<author fullname="Rob Glenn" initials="R." surname="Glenn">
<organization>NIST</organization>

<address>
<email>rob.glenn@nist.gov</email>
</address>
</author>

<date year="1998" month="November" />
<area>Security</area>
<area>Internet</area>
<keyword>IP security protocol</keyword>
<keyword>authentication</keyword>
<keyword>cryptographic hash message authentication codes</keyword>
<keyword>encapsulate</keyword>
<keyword>encapsulating security payload</keyword>
<keyword>secure hash algorithm</keyword>
<keyword>security</keyword>

<abstract>
<t>
   This memo describes the use of the HMAC algorithm  in
   conjunction with the SHA-1 algorithm  as an
   authentication mechanism within the revised IPSEC Encapsulating
   Security Payload  and the revised IPSEC Authentication Header
   . HMAC with SHA-1 provides data origin authentication and
   integrity protection.
</t>

<t>
   Further information on the other components necessary for ESP and AH
   implementations is provided by .
</t>
</abstract>
</front>

<seriesInfo value="2404" name="RFC" />
<format octets="28906" type="HTML" target="http://xml.resource.org/public/rfc/html/rfc2404.html" />
<format octets="15262" type="XML" target="http://xml.resource.org/public/rfc/xml/rfc2404.xml" />
</reference>


<reference target2="reference.RFC.2405.xml" anchor="RFC2405">
<front>
<title abbrev="The ESP DES-CBC Cipher Algorithm">The ESP DES-CBC Cipher Algorithm With Explicit IV</title>
<author fullname="Cheryl Madson" initials="C." surname="Madson">
<organization>Cisco Systems, Inc.</organization>

<address>
<email>cmadson@cisco.com</email>
</address>
</author>

<author fullname="Naganand Doraswamy" initials="N." surname="Doraswamy">
<organization>Bay Networks, Inc.</organization>

<address>
<email>naganand@baynetworks.com</email>
</address>
</author>

<date year="1998" month="November" />
<area>Security</area>
<keyword>Digital Encryption Standard</keyword>
<keyword>IP security protocol</keyword>
<keyword>cipher block chaining</keyword>
<keyword>encapsulate</keyword>
<keyword>encapsulating security payload</keyword>
<keyword>encryption</keyword>
<keyword>security</keyword>

<abstract>
<t>
   This document describes the use of the DES Cipher algorithm in Cipher
   Block Chaining Mode, with an explicit IV, as a confidentiality
   mechanism within the context of the IPSec Encapsulating Security
   Payload (ESP).
</t>
</abstract>
</front>

<seriesInfo value="2405" name="RFC" />
<format octets="38833" type="HTML" target="http://xml.resource.org/public/rfc/html/rfc2405.html" />
<format octets="24595" type="XML" target="http://xml.resource.org/public/rfc/xml/rfc2405.xml" />
</reference>


<reference target2="reference.RFC.2406.xml" anchor="RFC2406">
<front>
<title>IP Encapsulating Security Payload (ESP)</title>
<author fullname="Stephen Kent" initials="S." surname="Kent">
<organization>BBN Corporation</organization>

<address>
<postal>
<street>70 Fawcett Street</street>
<street>Cambridge</street>
<street>MA  02140</street>
<country>USA</country>
</postal>

<phone>+1 (617) 873-3988</phone>
<email>kent@bbn.com</email>
</address>
</author>

<author fullname="Randall Atkinson" initials="R." surname="Atkinson">
<organization>@Home Network</organization>

<address>
<postal>
<street>425 Broadway</street>
<street>Redwood City</street>
<street>CA  94063</street>
<country>USA</country>
</postal>

<phone>+1 (415) 569-5000</phone>
<email>rja@corp.home.net</email>
</address>
</author>

<date year="1998" month="November" />
<area>Security</area>
<area>Internet</area>
<keyword>IP security protocol</keyword>
<keyword>encapsulate</keyword>
<keyword>encapsulating security payload</keyword>
<keyword>internet protocol version 6</keyword>
<keyword>security</keyword>
</front>

<seriesInfo value="2406" name="RFC" />
<format octets="67818" type="HTML" target="http://xml.resource.org/public/rfc/html/rfc2406.html" />
<format octets="53887" type="XML" target="http://xml.resource.org/public/rfc/xml/rfc2406.xml" />
</reference>


<reference target2="reference.RFC.2407.xml" anchor="RFC2407">
<front>
<title abbrev="IP Security Domain of Interpretation">The Internet IP Security Domain of Interpretation for ISAKMP</title>
<author fullname="Derrell Piper" initials="D." surname="Piper">
<organization>Network Alchemy</organization>

<address>
<postal>
<street>1521.5 Pacific Ave</street>
<street>Santa Cruz</street>
<street>California</street>
<street>95060</street>
<country>United States of America</country>
</postal>

<phone>+1 408 460-3822</phone>
<email>ddp@network-alchemy.com</email>
</address>
</author>

<date year="1998" month="November" />
<area>Security</area>
<area>Internet</area>
<keyword>IP security protocol</keyword>
<keyword>cryptographic</keyword>
<keyword>internet security association and key management protocol</keyword>
<keyword>key management</keyword>
<keyword>security</keyword>

<note title="IESG Note">
<t>
   Section 4.4.4.2 states, &quot;All implememtations within the IPSEC DOI
   MUST support ESP_DES...&quot;.  Recent work in the area of cryptanalysis
   suggests that DES may not be sufficiently strong for many
   applications.  Therefore, it is very likely that the IETF will
   deprecate the use of ESP_DES as a mandatory cipher suite in the near
   future.  It will remain as an optional use protocol.  Although the
   IPsec working group and the IETF in general have not settled on an
   alternative algorithm (taking into account concerns of security and
   performance), implementers may want to heed the recommendations of
   section 4.4.4.3 on the use of ESP_3DES.
</t>
</note>
</front>

<seriesInfo value="2407" name="RFC" />
<format octets="92673" type="HTML" target="http://xml.resource.org/public/rfc/html/rfc2407.html" />
<format octets="75422" type="XML" target="http://xml.resource.org/public/rfc/xml/rfc2407.xml" />
</reference>


<reference target2="reference.RFC.2408.xml" anchor="RFC2408">
<front>
<title abbrev="ISAKMP">Internet Security Association and Key Management Protocol (ISAKMP)</title>
<author fullname="Douglas Maughan" initials="D." surname="Maughan">
<organization>National Security Agency</organization>

<address>
<postal>
<street>ATTN: R23</street>
<street>9800 Savage Road</street>
<street>Ft.  Meade</street>
<street>MD. 20755-6000</street>
</postal>

<phone>301-688-0847</phone>
<email>wdm@tycho.ncsc.mil</email>
</address>
</author>

<author fullname="Mark Schneider" initials="M." surname="Schneider">
<organization>National Security Agency</organization>

<address>
<postal>
<street>ATTN: R23</street>
<street>9800 Savage Road</street>
<street>Ft.  Meade</street>
<street>MD. 20755-6000</street>
</postal>

<phone>301-688-0851</phone>
<email>mss@tycho.ncsc.mil</email>
</address>
</author>

<author fullname="Mark Schertler" initials="M." surname="Schertler">
<organization>Securify, Inc.</organization>

<address>
<postal>
<street>2415-B Charleston Road</street>
<street>Mountain View</street>
<street>CA 94043</street>
</postal>

<phone>410-715-9399</phone>
<uri>er@raba.com</uri>
</address>
</author>

<date year="1998" month="November" />
<area>Security</area>
<keyword>cryptographic</keyword>
<keyword>internet security association and key management protocol</keyword>
<keyword>key management</keyword>
<keyword>security</keyword>

<abstract>
<t>
   This memo describes a protocol utilizing security concepts necessary
   for establishing Security Associations (SA) and cryptographic keys in
   an Internet environment.  A Security Association protocol that
   negotiates, establishes, modifies and deletes Security Associations
   and their attributes is required for an evolving Internet, where
   there will be numerous security mechanisms and several options for
   each security mechanism.  The key management protocol must be robust
   in order to handle public key generation for the Internet community
   at large and private key requirements for those private networks with
   that requirement.  The Internet Security Association and Key
   Management Protocol (ISAKMP) defines the procedures for
   authenticating a communicating peer, creation and management of
   Security Associations, key generation techniques, and threat
   mitigation (e.g.  denial of service and replay attacks).  All of
   these are necessary to establish and maintain secure communications
   (via IP Security Service or any other security protocol) in an
   Internet environment.
</t>
</abstract>
</front>

<seriesInfo value="2408" name="RFC" />
<format octets="226419" type="HTML" target="http://xml.resource.org/public/rfc/html/rfc2408.html" />
<format octets="201947" type="XML" target="http://xml.resource.org/public/rfc/xml/rfc2408.xml" />
</reference>


<reference target2="reference.RFC.2409.xml" anchor="RFC2409">
<front>
<title>The Internet Key Exchange (IKE)</title>
<author fullname="Dan Harkins" initials="D." surname="Harkins">
<organization>cisco Systems</organization>

<address>
<postal>
<street>170 W. Tasman Dr.</street>
<street>San Jose</street>
<street>California</street>
<street>95134-1706</street>
<country>United States of America</country>
</postal>

<phone>+1 408 526 4000</phone>
<email>dharkins@cisco.com</email>
</address>
</author>

<author fullname="Dave Carrel" initials="D." surname="Carrel">
<organization />

<address>
<postal>
<street>76 Lippard Ave.</street>
<street>San Francisco</street>
<street>CA 94131-2947</street>
<country>United States of America</country>
</postal>

<phone>+1 415 337 8469</phone>
<email>carrel@ipsec.org</email>
</address>
</author>

<date year="1998" month="November" />
<area>Security</area>
<area>Internet</area>
<keyword>IP security protocol</keyword>
<keyword>authentication</keyword>
<keyword>internet security association and key management protocol</keyword>
<keyword>key exchange</keyword>
<keyword>security</keyword>
</front>

<seriesInfo value="2409" name="RFC" />
<format octets="110062" type="HTML" target="http://xml.resource.org/public/rfc/html/rfc2409.html" />
<format octets="95451" type="XML" target="http://xml.resource.org/public/rfc/xml/rfc2409.xml" />
</reference>


<reference target2="reference.RFC.2410.xml" anchor="RFC2410">
<front>
<title abbrev="NULL and IPsec">The NULL Encryption Algorithm and Its Use With IPsec</title>
<author fullname="Rob Glenn" initials="R." surname="Glenn">
<organization>NIST</organization>

<address>
<email>rob.glenn@nist.gov</email>
</address>
</author>

<author fullname="Stephen Kent" initials="S." surname="Kent">
<organization>BBN Corporation</organization>

<address>
<email>kent@bbn.com</email>
</address>
</author>

<date year="1998" month="November" />
<area>Internet</area>
<area>Security</area>
<keyword>IP security protocol</keyword>
<keyword>authentication</keyword>
<keyword>encapsulate</keyword>
<keyword>encryption</keyword>
<keyword>security</keyword>

<abstract>
<t>
   This memo defines the NULL encryption algorithm and its use with the
   IPsec Encapsulating Security Payload (ESP).  NULL does nothing to
   alter plaintext data.  In fact, NULL, by itself, does nothing.  NULL
   provides the means for ESP to provide authentication and integrity
   without confidentiality.
</t>

<t>
   Further information on the other components necessary for ESP
   implementations is provided by  and .
</t>
</abstract>
</front>

<seriesInfo value="2410" name="RFC" />
<format octets="24609" type="HTML" target="http://xml.resource.org/public/rfc/html/rfc2410.html" />
<format octets="12781" type="XML" target="http://xml.resource.org/public/rfc/xml/rfc2410.xml" />
</reference>


<reference target2="reference.RFC.2411.xml" anchor="RFC2411">
<front>
<title>IP Security Document Roadmap</title>
<author fullname="Rodney Thayer" initials="R." surname="Thayer">
<organization>Sable Technology Corporation</organization>

<address>
<postal>
<street>246 Walnut Street</street>
<city>Newton</city>
<region>MA</region>
<code>02160</code>
<country>USA</country>
</postal>

<email>mailto:rodney@sabletech.com</email>
</address>
</author>

<author fullname="Naganand Doraswamy" initials="N." surname="Doraswamy">
<organization>Bay Networks</organization>

<address>
<email>naganand@baynetworks.com</email>
</address>
</author>

<author fullname="Rob Glenn" initials="R." surname="Glenn">
<organization>NIST</organization>

<address>
<email>rob.glenn@nist.gov</email>
</address>
</author>

<date year="1998" month="November" />
<area>Internet</area>
<area>Security</area>
<keyword>IP security protocol</keyword>
<keyword>authentication</keyword>
<keyword>encryption</keyword>
<keyword>security</keyword>

<abstract>
<t>
   The IPsec protocol suite is used to provide privacy and
   authentication services at the IP layer.  Several documents are used
   to describe this protocol suite.  The interrelationship and
   organization of the various documents covering the IPsec protocol are
   discussed here.  An explanation of what to find in which document,
   and what to include in new Encryption Algorithm and Authentication
   Algorithm documents are described.
</t>
</abstract>
</front>

<seriesInfo value="2411" name="RFC" />
<format octets="38020" type="HTML" target="http://xml.resource.org/public/rfc/html/rfc2411.html" />
<format octets="39028" type="XML" target="http://xml.resource.org/public/rfc/xml/rfc2411.xml" />
</reference>


<reference target2="reference.RFC.2412.xml" anchor="RFC2412">
<front>
<title>The OAKLEY Key Determination Protocol</title>
<author fullname="Hilarie K. Orman" initials="H.K." surname="Orman">
<organization>University of Arizona, Department of Computer Science</organization>

<address>
<email>ho@darpa.mil</email>
</address>
</author>

<date year="1998" month="November" />
<area>Security</area>
<keyword>authentication</keyword>

<abstract>
<t>
   This document describes a protocol, named OAKLEY, by which two
   authenticated parties can agree on secure and secret keying material.
   The basic mechanism is the Diffie-Hellman key exchange algorithm.
</t>

<t>
   The OAKLEY protocol supports Perfect Forward Secrecy, compatibility
   with the ISAKMP protocol for managing security associations, user-
   defined abstract group structures for use with the Diffie-Hellman
   algorithm, key updates, and incorporation of keys distributed via
   out-of-band mechanisms.
</t>
</abstract>
</front>

<seriesInfo value="2412" name="RFC" />
<format octets="135507" type="HTML" target="http://xml.resource.org/public/rfc/html/rfc2412.html" />
<format octets="128620" type="XML" target="http://xml.resource.org/public/rfc/xml/rfc2412.xml" />
</reference>


<reference target2="reference.RFC.2413.xml" anchor="RFC2413">
<front>
<title abbrev="DC Metadata for Resource Discovery">
Dublin Core Metadata for Resource Discovery</title>
<author fullname="Stuart L. Weibel" initials="S.L." surname="Weibel">
<organization>OCLC Online Computer Library Center, Inc., Office of Research</organization>

<address>
<postal>
<street>6565 Frantz Rd.</street>
<city>Dublin</city>
<region>OH</region>
<code>43017</code>
<country>USA</country>
</postal>

<phone>+1 614 764 6081</phone>
<facsimile>+1 614 764 2344</facsimile>
<email>weibel@oclc.org</email>
</address>
</author>

<author fullname="John A. Kunze" initials="J.A." surname="Kunze">
<organization>University of California, San Francisco, Center for Knowledge Management</organization>

<address>
<postal>
<street>530 Parnassus Ave, Box 0840</street>
<city>San Francisco</city>
<region>CA</region>
<code>94143-0840</code>
<country>USA</country>
</postal>

<phone>+1 510 525 8575</phone>
<facsimile>+1 415 476 4653</facsimile>
<email>jak@ckm.ucsf.edu</email>
</address>
</author>

<author fullname="Carl Lagoze" initials="C." surname="Lagoze">
<organization>Cornell University, University Library and Department of Computer Science</organization>

<address>
<postal>
<street />
<city>Ithaca</city>
<region>NY</region>
<code>14853</code>
<country>USA</country>
</postal>

<phone>+1 607 255 6046</phone>
<facsimile>+1 607 255 4428</facsimile>
<email>lagoze@cs.cornell.edu</email>
</address>
</author>

<author fullname="Misha Wolf" initials="M." surname="Wolf">
<organization>Reuters Limited</organization>

<address>
<postal>
<street>85 Fleet Street</street>
<city>London</city>
<code>EC4P 4AJ</code>
<country>UK</country>
</postal>

<phone>+44 171 542 6722</phone>
<facsimile>+44 171 542 8314</facsimile>
<email>misha.wolf@reuters.com</email>
</address>
</author>

<date year="1998" month="September" />
<area>Applications</area>
<keyword>discovery</keyword>
<keyword>Dublin Core</keyword>
<keyword>metadata</keyword>
</front>

<seriesInfo value="2413" name="RFC" />
<format octets="30518" type="HTML" target="http://xml.resource.org/public/rfc/html/rfc2413.html" />
<format octets="17800" type="XML" target="http://xml.resource.org/public/rfc/xml/rfc2413.xml" />
</reference>


<reference target2="reference.RFC.2414.xml" anchor="RFC2414">
<front>
<title abbrev="Increasing TCP&apos;s Initial Window">Increasing TCP&apos;s Initial Window</title>
<author fullname="Mark Allman" initials="M." surname="Allman">
<organization>NASA Lewis Research Center/Sterling Software</organization>

<address>
<postal>
<street>21000 Brookpark Road</street>
<street>MS 54-2</street>
<region>OH</region>
<code>44135</code>
<country>USA</country>
</postal>

<email>mallman@lerc.nasa.gov</email>
<uri>http://gigahertz.lerc.nasa.gov/~mallman/</uri>
</address>
</author>

<author fullname="Sally Floyd" initials="S." surname="Floyd">
<organization>Lawrence Berkeley National Laboratory</organization>

<address>
<postal>
<street>One Cyclotron Road</street>
<city>Berkeley</city>
<region>CA</region>
<code>94720</code>
<country>USA</country>
</postal>

<email>floyd@ee.lbl.gov</email>
</address>
</author>

<author fullname="Craig Partridge" initials="C." surname="Partridge">
<organization>BBN Technologies</organization>

<address>
<postal>
<street>10 Moulton Street</street>
<city>Cambridge</city>
<region>MA</region>
<code>02138</code>
<country>USA</country>
</postal>

<email>craig@bbn.com</email>
</address>
</author>

<date year="1998" month="September" />
<area>Transport</area>
<keyword>transmission control protocol</keyword>
<keyword>TCP</keyword>

<abstract>
<t>
   This document specifies an increase in the permitted initial window
   for TCP from one segment to roughly 4K bytes.  This document
   discusses the advantages and disadvantages of such a change,
   outlining experimental results that indicate the costs and benefits
   of such a change to TCP.
</t>
</abstract>
</front>

<seriesInfo value="2414" name="RFC" />
<format octets="49663" type="HTML" target="http://xml.resource.org/public/rfc/html/rfc2414.html" />
<format octets="56564" type="XML" target="http://xml.resource.org/public/rfc/xml/rfc2414.xml" />
</reference>


<reference target2="reference.RFC.2415.xml" anchor="RFC2415">
<front>
<title abbrev="TCP Window Size">Simulation Studies of Increased Initial TCP Window Size</title>
<author fullname="Kedarnath Poduri" initials="K." surname="Poduri">
<organization>Bay Networks</organization>

<address>
<postal>
<street>4401 Great America Parkway</street>
<street>SC01-04</street>
<street>Santa Clara</street>
<street>CA 95052-8185</street>
</postal>

<phone>+1-408-495-2463</phone>
<facsimile>+1-408-495-1299</facsimile>
<email>knichols@baynetworks.com</email>
<uri>@Baynetworks.com</uri>
</address>
</author>

<date year="1998" month="September" />
<area>Transport</area>
<keyword>file transfer</keyword>
<keyword>transmission control protocol</keyword>
<keyword>TCP</keyword>

<abstract>
<t>
   An increase in the permissible initial window size of a TCP
   connection, from one segment to three or four segments, has been
   under discussion in the tcp-impl working group. This document covers
   some simulation studies of the effects of increasing the initial
   window size of TCP. Both long-lived TCP connections (file transfers)
   and short-lived web-browsing style connections were modeled. The
   simulations were performed using the publicly available ns-2
   simulator and our custom models and files are also available.
</t>
</abstract>
</front>

<seriesInfo value="2415" name="RFC" />
<format octets="33645" type="HTML" target="http://xml.resource.org/public/rfc/html/rfc2415.html" />
<format octets="23946" type="XML" target="http://xml.resource.org/public/rfc/xml/rfc2415.xml" />
</reference>


<reference target2="reference.RFC.2416.xml" anchor="RFC2416">
<front>
<title abbrev="TCP with Four Packets into Three Buffers">When TCP Starts Up With Four Packets Into Only Three Buffers</title>
<author fullname="Tim Shepard" initials="T." surname="Shepard">
<organization>BBN Technologies</organization>

<address>
<postal>
<street>10 Moulton Street</street>
<city>Cambridge</city>
<region>MA</region>
<code> 02138</code>
<country>USA</country>
</postal>

<email>shep@alum.mit.edu</email>
</address>
</author>

<author fullname="Craig Partridge" initials="C." surname="Partridge">
<organization>BBN Technologies</organization>

<address>
<postal>
<street>10 Moulton Street</street>
<city>Cambridge</city>
<region>MA</region>
<code>02138</code>
<country>USA</country>
</postal>

<email>craig@bbn.com</email>
</address>
</author>

<date year="1998" month="September" />
<area>Transport</area>
<keyword>TCP</keyword>
<keyword>transmission control protocol</keyword>

<abstract>
<t>
   This memo is to document a simple experiment.  The experiment showed
   that in the case of a TCP receiver behind a 9600 bps modem link at
   the edge of a fast Internet where there are only 3 buffers before the
   modem (and the fourth packet of a four-packet start will surely be
   dropped), no significant degradation in performance is experienced by
   a TCP sending with a four-packet start when compared with a normal
   slow start (which starts with just one packet).
</t>
</abstract>
</front>

<seriesInfo value="2416" name="RFC" />
<format octets="22397" type="HTML" target="http://xml.resource.org/public/rfc/html/rfc2416.html" />
<format octets="13794" type="XML" target="http://xml.resource.org/public/rfc/xml/rfc2416.xml" />
</reference>


<reference target2="reference.RFC.2417.xml" anchor="RFC2417">
<front>
<title abbrev="Multicast MIB">Definitions of Managed Objects for Multicast over UNI 3.0/3.1 based ATM Networks</title>
<author fullname="Chris Chung" initials="C." surname="Chung">
<organization>Independent Consultant</organization>

<address>
<email>chihschung@aol.com</email>
</address>
</author>

<author fullname="Maria Greene" initials="M." surname="Greene">
<organization>Independent Contractor</organization>

<address>
<email>maria@xedia.com</email>
</address>
</author>

<date year="1998" month="September" />
<area>Internet</area>
<area>Management</area>
<keyword>Management Information Base</keyword>
<keyword>asynchronous transfer mode</keyword>
<keyword>managed object</keyword>
<keyword>multicast</keyword>
<keyword>simple network management protocol</keyword>

<abstract>
<t>
   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 for IP hosts and routers
   that use a Multicast Address Resolution Server (MARS) to support IP
   multicast over ATM, as described in &apos;Support for Multicast over UNI
   3.0/3.1 based ATM Networks&apos; .
</t>

<t>
   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
</t>
</abstract>

<note title="IANA Note">
<t>
   Due to a clerical error in the assignment of the snmpModules in this
   memo, this RFC provides the corrected number assignment for this
   protocol.  This memo obsoletes RFC 2366.
</t>
</note>
</front>

<seriesInfo value="2417" name="RFC" />
<format octets="142406" type="HTML" target="http://xml.resource.org/public/rfc/html/rfc2417.html" />
<format octets="129246" type="XML" target="http://xml.resource.org/public/rfc/xml/rfc2417.xml" />
</reference>


<reference target2="reference.RFC.2418.xml" anchor="RFC2418">
<front>
<title abbrev="IETF Guidelines">IETF Working Group Guidelines and Procedures</title>
<author fullname="Scott Bradner" initials="S." surname="Bradner">
<organization>Harvard University</organization>

<address>
<postal>
<street>1350 Mass Ave.</street>
<street>Cambridge</street>
<country>MA</country>
</postal>

<phone>+1 617 495 3864</phone>
<email>sob@harvard.edu</email>
</address>
</author>

<date year="1998" month="September" />
<area>General</area>
<keyword>Internet Engineering Task Force</keyword>

<abstract>
<t>
   The Internet Engineering Task Force (IETF) has responsibility for
   developing and reviewing specifications intended as Internet
   Standards. IETF activities are organized into working groups (WGs).
   This document describes the guidelines and procedures for formation
   and operation of IETF working groups. It also describes the formal
   relationship between IETF participants WG and the Internet
   Engineering Steering Group (IESG) and the basic duties of IETF
   participants, including WG Chairs, WG participants, and IETF Area
   Directors.
</t>
</abstract>
</front>

<seriesInfo value="25" name="BCP" />
<seriesInfo value="2418" name="RFC" />
<format octets="77010" type="HTML" target="http://xml.resource.org/public/rfc/html/rfc2418.html" />
<format octets="62286" type="XML" target="http://xml.resource.org/public/rfc/xml/rfc2418.xml" />
</reference>


<reference target2="reference.RFC.2419.xml" anchor="RFC2419">
<front>
<title abbrev="PPP DES Encryption v2">The PPP DES Encryption Protocol, Version 2 (DESE-bis)</title>
<author fullname="Keith Sklower" initials="K." surname="Sklower">
<organization>Computer Science Department</organization>

<address>
<postal>
<street>339 Soda Hall</street>
<street>Mail Stop 1776</street>
<street>University of California</street>
<street>Berkeley</street>
<street>CA 94720-1776</street>
</postal>

<phone>(510) 642-9587</phone>
<email>sklower@CS.Berkeley.EDU</email>
</address>
</author>

<author fullname="Gerry M. Meyer" initials="G.M." surname="Meyer">
<organization>Cisco Systems Ltd.</organization>

<address>
<postal>
<street>Bothwell House</street>
<street>Pochard Way</street>
<street>Strathclyde Business Park</street>
<street>Bellshill</street>
<street>ML4 3HB</street>
<street>Scotland</street>
<country>UK</country>
</postal>

<phone>(UK) (pending)</phone>
<facsimile>(UK) (pending)</facsimile>
<email>gemeyer@cisco.com</email>
</address>
</author>

<date year="1998" month="September" />
<area>Security</area>
<area>Internet</area>
<keyword>Digital Encryption Standard</keyword>
<keyword>encapsulate</keyword>
<keyword>encryption</keyword>
<keyword>point-to-point protocol</keyword>
<keyword>PPP</keyword>

<abstract>
<t>
   The Point-to-Point Protocol (PPP)  provides a standard method for
   transporting multi-protocol datagrams over point-to-point links.
</t>

<t>
   The PPP Encryption Control Protocol (ECP)  provides a method to
   negotiate and utilize encryption protocols over PPP encapsulated
   links.
</t>

<t>
   This document provides specific details for the use of the DES
   standard [5, 6] for encrypting PPP encapsulated packets.
</t>
</abstract>
</front>

<seriesInfo value="2419" name="RFC" />
<format octets="38827" type="HTML" target="http://xml.resource.org/public/rfc/html/rfc2419.html" />
<format octets="24766" type="XML" target="http://xml.resource.org/public/rfc/xml/rfc2419.xml" />
</reference>


<reference target2="reference.RFC.2420.xml" anchor="RFC2420">
<front>
<title abbrev="3DESE">The PPP Triple-DES Encryption Protocol (3DESE)</title>
<author fullname="Holger Kummert" initials="H." surname="Kummert">
<organization>Nentec Gesellschaft fuer Netzwerktechnologie</organization>

<address>
<postal>
<street>76227 Karlsruhe</street>
<street>Killisfeldstr. 64</street>
<country>Germany</country>
</postal>

<phone>+49 721 9495 0</phone>
<email>kummert@nentec.de</email>
</address>
</author>

<date year="1998" month="September" />
<area>Internet</area>
<area>Security</area>
<keyword>Digital Encryption Standard</keyword>
<keyword>encapsulate</keyword>
<keyword>encryption</keyword>
<keyword>point-to-point protocol</keyword>

<abstract>
<t>
   The Point-to-Point Protocol (PPP)  provides a standard method for
   transporting multi-protocol datagrams over point-to-point links.
</t>

<t>
   The PPP Encryption Control Protocol (ECP)  provides a method to
   negotiate and utilize encryption protocols over PPP encapsulated
   links.
</t>

<t>
   This document provides specific details for the use of the Triple-DES
   standard (3DES)  for encrypting PPP encapsulated packets.
</t>
</abstract>
</front>

<seriesInfo value="2420" name="RFC" />
<format octets="29423" type="HTML" target="http://xml.resource.org/public/rfc/html/rfc2420.html" />
<format octets="17338" type="XML" target="http://xml.resource.org/public/rfc/xml/rfc2420.xml" />
</reference>


<reference target2="reference.RFC.2421.xml" anchor="RFC2421">
<front>
<title abbrev="VPIM v2">Voice Profile for Internet Mail - version 2</title>
<author fullname="Gregory M. Vaudreuil" initials="G.M." surname="Vaudreuil">
<organization>Lucent Technologies, Octel Messaging Division</organization>

<address>
<postal>
<street>17080 Dallas Parkway</street>
<city>Dallas</city>
<region>TX</region>
<code>75248-1905</code>
<country>USA</country>
</postal>

<phone>+1 972 733 2722</phone>
<email>GregV@Lucent.Com</email>
</address>
</author>

<author fullname="Glenn W. Parsons" initials="G.W." surname="Parsons">
<organization>Northern Telecom</organization>

<address>
<postal>
<street>P.O. Box 3511</street>
<street>Station C</street>
<city>Ottawa</city>
<region>ON</region>
<code>K1Y 4H7</code>
<country>Canada</country>
</postal>

<phone>+1 613 763 7582</phone>
<facsimile>+1 613 763 4461</facsimile>
<email>Glenn.Parsons@Nortel.ca</email>
</address>
</author>

<date year="1998" month="September" />
<area>Applications</area>
<keyword>audio</keyword>
<keyword>mail</keyword>

<abstract>
<t>
   A class of special-purpose computers has evolved to provide voice
   messaging services.  These machines generally interface to a
   telephone switch and provide call answering and voice messaging
   services.  Traditionally, messages sent to a non-local machine are
   transported using analog networking protocols based on DTMF signaling
   and analog voice playback.  As the demand for networking increases,
   there is a need for a standard high-quality digital protocol to
   connect these machines.  The following document is a profile of the
   Internet standard MIME and ESMTP protocols for use as a digital voice
   messaging networking protocol. The profile is referred to as VPIM
   (Voice Profile for Internet Mail) in this document.
</t>

<t>
   This profile is based on earlier work in the Audio Message
   Interchange Specification (AMIS) group that defined a voice messaging
   protocol based on X.400 technology.  This profile is intended to
   satisfy the user requirements statement from that earlier work with
   the industry standard ESMTP/MIME mail protocol infrastructures
   already used within corporate intranets. This second version of VPIM
   is based on implementation experience and obsoletes RFC 1911 which
   describes version 1 of the profile.
</t>
</abstract>

<note title="Working Group Summary">
<t>
   This profile is not the product of an IETF working group, though
   several have reviewed the document.  It is instead the product of the
   VPIM Work Group of the Electronic Messaging Association (EMA).  This
   work group, which has representatives from most major voice mail
   vendors and several email vendors, has held several interoperability
   demonstrations between voice messaging vendors and is currently
   promoting VPIM trials and deployment.
</t>
</note>
</front>

<seriesInfo value="2421" name="RFC" />
<format octets="162050" type="HTML" target="http://xml.resource.org/public/rfc/html/rfc2421.html" />
<format octets="180600" type="XML" target="http://xml.resource.org/public/rfc/xml/rfc2421.xml" />
</reference>


<reference target2="reference.RFC.2422.xml" anchor="RFC2422">
<front>
<title abbrev="32 kbit/s ADPCM">Toll Quality Voice - 32 kbit/s ADPCM MIME Sub-type Registration</title>
<author fullname="Gregory M. Vaudreuil" initials="G.M." surname="Vaudreuil">
<organization>Lucent Technologies</organization>

<address>
<postal>
<street>17080 Dallas Parkway</street>
<city>Dallas</city>
<region>TX</region>
<code>75248-1905</code>
<country>USA</country>
</postal>

<phone>+1 972 733 2722</phone>
<email>GregV@Lucent.Com</email>
</address>
</author>

<author fullname="Glenn W. Parsons" initials="G.W." surname="Parsons">
<organization>Northern Telecom</organization>

<address>
<postal>
<street>P.O. Box 3511</street>
<street>Station C</street>
<city>Ottawa</city>
<region>ON</region>
<code>K1Y 4H7</code>
<country>Canada</country>
</postal>

<phone>+1613 763 7582</phone>
<facsimile>+1 613 763 4461</facsimile>
<email>Glenn.Parsons@Nortel.ca</email>
</address>
</author>

<date year="1998" month="September" />
<area>Applications</area>
<keyword>audio</keyword>
<keyword>multipurpose internet mail extensions</keyword>
</front>

<seriesInfo value="2422" name="RFC" />
<format octets="24209" type="HTML" target="http://xml.resource.org/public/rfc/html/rfc2422.html" />
<format octets="20307" type="XML" target="http://xml.resource.org/public/rfc/xml/rfc2422.xml" />
</reference>


<reference target2="reference.RFC.2423.xml" anchor="RFC2423">
<front>
<title>VPIM Voice Message MIME Sub-type Registration</title>
<author fullname="G. Vaudreuil" initials="G." surname="Vaudreuil">
<organization />
</author>

<author fullname="G. Parsons" initials="G." surname="Parsons">
<organization />
</author>

<date year="1998" month="September" />
</front>

<seriesInfo value="2423" name="RFC" />
<format octets="10729" type="TXT" target="ftp://ftp.isi.edu/in-notes/rfc2423.txt" />
<format octets="19184" type="HTML" target="http://xml.resource.org/public/rfc/html/rfc2423.html" />
</reference>


<reference target2="reference.RFC.2424.xml" anchor="RFC2424">
<front>
<title abbrev="Content-Duration">Content Duration MIME Header Definition</title>
<author fullname="Gregory M. Vaudreuil" initials="G.M." surname="Vaudreuil">
<organization>Lucent Technologies</organization>

<address>
<postal>
<street>17080 Dallas Parkway</street>
<city>Dallas</city>
<region>TX</region>
<code>75248-1905</code>
<country>USA</country>
</postal>

<phone>+1 972 733 2722</phone>
<email>GregV@Lucent.Com</email>
</address>
</author>

<author fullname="Glenn W. Parsons" initials="G.W." surname="Parsons">
<organization>Northern Telecom</organization>

<address>
<postal>
<street>P.O. Box 3511</street>
<street>Station C</street>
<city>Ottawa</city>
<region>ON</region>
<code>K1Y 4H7</code>
<country>Canada</country>
</postal>

<phone>+1 613 763 7582</phone>
<facsimile>+1 613 763 4461</facsimile>
<email>Glenn.Parsons@Nortel.ca</email>
</address>
</author>

<date year="1998" month="September" />
<area>Applications</area>
<keyword>audio</keyword>
<keyword>multipurpose internet mail extensions</keyword>
<keyword>video</keyword>
<keyword>MIME</keyword>
</front>

<seriesInfo value="2424" name="RFC" />
<format octets="19630" type="HTML" target="http://xml.resource.org/public/rfc/html/rfc2424.html" />
<format octets="14354" type="XML" target="http://xml.resource.org/public/rfc/xml/rfc2424.xml" />
</reference>


<reference target2="reference.RFC.2425.xml" anchor="RFC2425">
<front>
<title abbrev="MIME Content-Type for Directory Information">A MIME Content-Type for Directory Information</title>
<author fullname="Tim Howes" initials="T." surname="Howes">
<organization>Netscape Communications Corp.</organization>

<address>
<postal>
<street>501 East Middlefield Rd.</street>
<street>Mountain View</street>
<street>CA 94041</street>
<country>USA</country>
</postal>

<phone>+1.415.937.3419</phone>
<email>howes@netscape.com</email>
</address>
</author>

<author fullname="Mark Smith" initials="M." surname="Smith">
<organization>Netscape Communications Corp.</organization>

<address>
<postal>
<street>501 East Middlefield Rd.</street>
<street>Mountain View</street>
<street>CA 94041</street>
<country>USA</country>
</postal>

<phone>+1.415.937.3477</phone>
<email>mcs@netscape.com</email>
</address>
</author>

<author fullname="Frank Dawson" initials="F." surname="Dawson">
<organization>Lotus Development Corporation</organization>

<address>
<postal>
<street>6544 Battleford Drive</street>
<street>Raleigh</street>
<street>NC 27613</street>
<country>USA</country>
</postal>

<phone>+1-919-676-9515</phone>
<email>frank_dawson@lotus.com</email>
</address>
</author>

<date year="1998" month="September" />
<area>Applications</area>
<keyword>MIME</keyword>
<keyword>content-type</keyword>
<keyword>directory</keyword>
<keyword>multipurpose internet mail extensions</keyword>
</front>

<seriesInfo value="2425" name="RFC" />
<format octets="84664" type="HTML" target="http://xml.resource.org/public/rfc/html/rfc2425.html" />
<format octets="67161" type="XML" target="http://xml.resource.org/public/rfc/xml/rfc2425.xml" />
</reference>


<reference target2="reference.RFC.2426.xml" anchor="RFC2426">
<front>
<title>vCard MIME Directory Profile</title>
<author fullname="Frank Dawson" initials="F." surname="Dawson">
<organization>Lotus Development Corporation</organization>

<address>
<postal>
<street>6544 Battleford Drive</street>
<street>Raleigh</street>
<street>NC 27613</street>
<country>USA</country>
</postal>

<phone>+1-919-676-9515</phone>
<email>frank_dawson@lotus.com</email>
</address>
</author>

<author fullname="Tim Howes" initials="T." surname="Howes">
<organization>Netscape Communications Corp.</organization>

<address>
<postal>
<street>501 East Middlefield Rd.</street>
<street>Mountain View</street>
<street>CA 94041</street>
<country>USA</country>
</postal>

<phone>+1.415.937.3419</phone>
<email>howes@netscape.com</email>
</address>
</author>

<date year="1998" month="September" />
<area>Applications</area>
<keyword>MIME</keyword>
<keyword>audio</keyword>
<keyword>content-type</keyword>
<keyword>directory</keyword>
<keyword>multipurpose internet mail extensions</keyword>

<abstract>
<t>
   This memo defines the profile of the MIME Content-Type  for
   directory information for a white-pages person object, based on a
   vCard electronic business card. The profile definition is independent
   of any particular directory service or protocol. The profile is
   defined for representing and exchanging a variety of information
   about an individual (e.g., formatted and structured name and delivery
   addresses, email address, multiple telephone numbers, photograph,
   logo, audio clips, etc.). The directory information used by this
   profile is based on the attributes for the person object defined in
   the X.520 and X.521 directory services recommendations. The profile
   also provides the method for including a  representation of a
   white-pages directory entry within the MIME Content-Type defined by
   the  document.
</t>

<t>
   The key words &quot;MUST&quot;, &quot;MUST NOT&quot;, &quot;REQUIRED&quot;, &quot;SHALL&quot;, &quot;SHALL NOT&quot;,
   &quot;SHOULD&quot;, &quot;SHOULD NOT&quot;, &quot;RECOMMENDED&quot;, &quot;MAY&quot; and &quot;OPTIONAL&quot; in this
   document are to be interpreted as described in .
</t>
</abstract>
</front>

<seriesInfo value="2426" name="RFC" />
<format octets="96516" type="HTML" target="http://xml.resource.org/public/rfc/html/rfc2426.html" />
<format octets="77828" type="XML" target="http://xml.resource.org/public/rfc/xml/rfc2426.xml" />
</reference>


<reference target2="reference.RFC.2427.xml" anchor="RFC2427">
<front>
<title abbrev="Multiprotocol over Frame Relay">Multiprotocol Interconnect over Frame Relay</title>
<author fullname="Caralyn Brown" initials="C." surname="Brown">
<organization>Consultant</organization>

<address>
<email>cbrown@juno.com</email>
</address>
</author>

<author fullname="Andrew Malis" initials="A." surname="Malis">
<organization>Ascend Communications, Inc.</organization>

<address>
<postal>
<street>1 Robbins Road</street>
<street>Westford</street>
<street>MA  01886</street>
</postal>

<phone>(978) 952-7414</phone>
<email>malis@ascend.com</email>
</address>
</author>

<date year="1998" month="September" />
<area>Internet</area>
<keyword>encapsulate</keyword>
<keyword>frame relay</keyword>
<keyword>routing</keyword>

<abstract>
<t>
   This memo describes an encapsulation method for carrying network
   interconnect traffic over a Frame Relay backbone.  It covers aspects
   of both Bridging and Routing.
</t>

<t>
   Systems with the ability to transfer both the encapsulation method
   described in this document, and others must have a priori knowledge
   of which virtual circuits will carry which encapsulation method and
   this encapsulation must only be used over virtual circuits that have
   been explicitly configured for its use.
</t>
</abstract>
</front>

<seriesInfo value="55" name="STD" />
<seriesInfo value="2427" name="RFC" />
<format octets="89884" type="HTML" target="http://xml.resource.org/public/rfc/html/rfc2427.html" />
<format octets="75783" type="XML" target="http://xml.resource.org/public/rfc/xml/rfc2427.xml" />
</reference>


<reference target2="reference.RFC.2428.xml" anchor="RFC2428">
<front>
<title>FTP Extensions for IPv6 and NATs</title>
<author fullname="Mark Allman" initials="M." surname="Allman">
<organization>NASA Lewis Research Center/Sterling Software</organization>

<address>
<postal>
<street>21000 Brookpark Rd.  MS 54-2</street>
<street>Cleveland</street>
<street>OH  44135</street>
</postal>

<phone>(216) 433-6586</phone>
<email>mallman@lerc.nasa.gov</email>
<uri>http://gigahertz.lerc.nasa.gov/~mallman/</uri>
</address>
</author>

<author fullname="Shawn Ostermann" initials="S." surname="Ostermann">
<organization>School of Electrical Engineering and Computer Science</organization>

<address>
<postal>
<street>Ohio University</street>
<street>416 Morton Hall</street>
<street>Athens</street>
<street>OH  45701</street>
</postal>

<phone>(740) 593-1234</phone>
<email>ostermann@cs.ohiou.edu</email>
</address>
</author>

<author fullname="Craig Metz" initials="C." surname="Metz">
<organization>The Inner Net</organization>

<address>
<postal>
<street>Box 10314-1954</street>
<street>Blacksburg</street>
<street>VA  24062-0314</street>
</postal>

<phone>(DSN) 754-8590</phone>
<email>cmetz@inner.net</email>
</address>
</author>

<date year="1998" month="September" />
<area>Applications</area>
<keyword>FTP</keyword>
<keyword>IPv6</keyword>
<keyword>file transfer</keyword>
<keyword>file transfer protocol</keyword>
<keyword>internet protocol version 6</keyword>
<keyword>network address translation</keyword>
<keyword>network address translator</keyword>

<abstract>
<t>
   The specification for the File Transfer Protocol assumes that the
   underlying network protocol uses a 32-bit network address
   (specifically IP version 4).  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 IPv4 and IPv6.  In addition, the framework defined can
   support additional network protocols in the future.
</t>
</abstract>
</front>

<seriesInfo value="2428" name="RFC" />
<format octets="29451" type="HTML" target="http://xml.resource.org/public/rfc/html/rfc2428.html" />
<format octets="17774" type="XML" target="http://xml.resource.org/public/rfc/xml/rfc2428.xml" />
</reference>


<reference target2="reference.RFC.2429.xml" anchor="RFC2429">
<front>
<title abbrev="H.263+">RTP Payload Format for the 1998 Version of ITU-T Rec. H.263 Video (H.263+)</title>
<author fullname="Carsten Bormann" initials="C." surname="Bormann">
<organization>Universitaet Bremen FB3 TZI</organization>

<address>
<postal>
<street>Postfach 330440</street>
<street>D-28334 Bremen</street>
<country>GERMANY</country>
</postal>

<phone>+49.421.218-7024</phone>
<facsimile>+49.421.218-7000</facsimile>
<email>cabo@tzi.org</email>
</address>
</author>

<author fullname="Linda Cline" initials="L." surname="Cline">
<organization>Intel Corp. M/S JF3-206</organization>

<address>
<postal>
<street>2111 NE 25th Avenue</street>
<street>Hillsboro</street>
<street>OR 97124</street>
<country>USA</country>
</postal>

<phone>+1 503 264 3501</phone>
<facsimile>+1 503 264 3483</facsimile>
<email>lscline@jf.intel.com</email>
</address>
</author>

<author fullname="Gim Deisher" initials="G." surname="Deisher">
<organization>Intel Corp. M/S JF2-78</organization>

<address>
<postal>
<street>2111 NE 25th Avenue</street>
<street>Hillsboro</street>
<street>OR 97124</street>
<country>USA</country>
</postal>

<phone>+1 503 264 3758</phone>
<facsimile>+1 503 264 9372</facsimile>
<email>gim.l.deisher@intel.com</email>
</address>
</author>

<author fullname="Tom Gardos" initials="T." surname="Gardos">
<organization>Intel Corp. M/S JF2-78</organization>

<address>
<postal>
<street>2111 NE 25th Avenue</street>
<street>Hillsboro</street>
<street>OR 97124</street>
<country>USA</country>
</postal>

<phone>+1 503 264 6459</phone>
<facsimile>+1 503 264 9372</facsimile>
<email>thomas.r.gardos@intel.com</email>
</address>
</author>

<author fullname="Christian Maciocco" initials="C." surname="Maciocco">
<organization>Intel Corp. M/S JF3-206</organization>

<address>
<postal>
<street>2111 NE 25th Avenue</street>
<street>Hillsboro</street>
<street>OR 97124</street>
<country>USA</country>
</postal>

<phone>+1 503 264 1770</phone>
<facsimile>+1 503 264 9428</facsimile>
<email>christian.maciocco@intel.com</email>
</address>
</author>

<author fullname="Donald Newell" initials="D." surname="Newell">
<organization>Intel Corp. M/S JF3-206</organization>

<address>
<postal>
<street>2111 NE 25th Avenue</street>
<street>Hillsboro</street>
<street>OR 97124</street>
<country>USA</country>
</postal>

<phone>+1 503 264 9234</phone>
<facsimile>+1 503 264 9428</facsimile>
<email>donald.newell@intel.com</email>
</address>
</author>

<author fullname="Joerg Ott" initials="J." surname="Ott">
<organization>Universitaet Bremen FB3 TZI</organization>

<address>
<postal>
<street>Postfach 330440</street>
<street>D-28334 Bremen</street>
<country>GERMANY</country>
</postal>

<phone>+49.421.218-7024</phone>
<facsimile>+49.421.218-7000</facsimile>
<email>jo@tzi.org</email>
</address>
</author>

<author fullname="Gary Sullivan" initials="G." surname="Sullivan">
<organization>PictureTel Corp. M/S 635</organization>

<address>
<postal>
<street>100 Minuteman Road</street>
<street>Andover</street>
<street>MA 01810</street>
<country>USA</country>
</postal>

<phone>+1 978 623 4324</phone>
<facsimile>+1 978 749 2804</facsimile>
<email>garys@pictel.com</email>
</address>
</author>

<author fullname="Stephan Wenger" initials="S." surname="Wenger">
<organization>Technische Universitaet Berlin FB13</organization>

<address>
<postal>
<street>Sekr. FR 6-3</street>
<street>Franklinstr. 28/29</street>
<street>D-10587 Berlin</street>
<country>GERMANY</country>
</postal>

<phone>+49.30.314-73160</phone>
<facsimile>+49.30.314-25156</facsimile>
<email>stewe@cs.tu-berlin.de</email>
</address>
</author>

<author fullname="Chad Zhu" initials="C." surname="Zhu">
<organization>Intel Corp. M/S JF3-202</organization>

<address>
<postal>
<street>2111 NE 25th Avenue</street>
<street>Hillsboro</street>
<street>OR 97124</street>
<country>USA</country>
</postal>

<phone>+1 503 264 6004</phone>
<facsimile>+1 503 264 1805</facsimile>
<email>czhu@ix.netcom.com</email>
</address>
</author>

<date year="1998" month="October" />
<area>Transport</area>
<area>Applications</area>
<keyword>International Telecommunications Union</keyword>
<keyword>International Telecommunications Union:Telecommunication Standardization Bureau</keyword>
<keyword>real-time transport protocol</keyword>
<keyword>RTP</keyword>
<keyword>video</keyword>
</front>

<seriesInfo value="2429" name="RFC" />
<format octets="64585" type="HTML" target="http://xml.resource.org/public/rfc/html/rfc2429.html" />
<format octets="44900" type="XML" target="http://xml.resource.org/public/rfc/xml/rfc2429.xml" />
</reference>


<reference target2="reference.RFC.2430.xml" anchor="RFC2430">
<front>
<title abbrev="PASTE">A Provider Architecture for Differentiated Services and Traffic Engineering (PASTE)</title>
<author fullname="Tony Li" initials="T." surname="Li">
<organization>Juniper Networks, Inc.</organization>

<address>
<postal>
<street>385 Ravendale Dr.</street>
<street>Mountain View</street>
<street>CA 94043</street>
</postal>

<phone>+1 650 526 8006</phone>
<facsimile>+1 650 526 8001</facsimile>
<email>tli@juniper.net</email>
</address>
</author>

<author fullname="Yakov Rekhter" initials="Y." surname="Rekhter">
<organization>cisco Systems, Inc.</organization>

<address>
<postal>
<street>170 W. Tasman Dr.</street>
<street>San Jose</street>
<street>CA 95134</street>
</postal>

<email>yakov@cisco.com</email>
</address>
</author>

<date year="1998" month="October" />
<area>Internet</area>
<keyword>differentiated service</keyword>
<keyword>RSVP</keyword>
</front>

<seriesInfo value="2430" name="RFC" />
<format octets="53079" type="HTML" target="http://xml.resource.org/public/rfc/html/rfc2430.html" />
<format octets="42122" type="XML" target="http://xml.resource.org/public/rfc/xml/rfc2430.xml" />
</reference>


<reference target2="reference.RFC.2431.xml" anchor="RFC2431">
<front>
<title abbrev="RTP Payload Format for BT.656">RTP Payload Format for BT.656 Video Encoding</title>
<author fullname="Dermot Tynan" initials="D." surname="Tynan">
<organization>Claddagh Films Limited</organization>

<address>
<postal>
<street>3 White Oaks</street>
<street>Clybaun Road</street>
<street>Galway</street>
<country>Ireland</country>
</postal>

<phone>+353 91 529944</phone>
<email>dtynan@claddagh.ie</email>
</address>
</author>

<date year="1998" month="October" />
<area>Transport</area>
<keyword>encapsulate</keyword>
<keyword>real-time transport protocol</keyword>
<keyword>RTP</keyword>
<keyword>video</keyword>

<abstract>
<t>
   This document specifies the RTP payload format for encapsulating ITU
   Recommendation BT.656-3 video streams in the Real-Time Transport
   Protocol (RTP).  Each RTP packet contains all or a portion of one
   scan line as defined by ITU Recommendation BT.601-5, and includes
   fragmentation, decoding and positioning information.
</t>
</abstract>
</front>

<seriesInfo value="2431" name="RFC" />
<format octets="35872" type="HTML" target="http://xml.resource.org/public/rfc/html/rfc2431.html" />
<format octets="23433" type="XML" target="http://xml.resource.org/public/rfc/xml/rfc2431.xml" />
</reference>


<reference target2="reference.RFC.2432.xml" anchor="RFC2432">
<front>
<title>Terminology for IP Multicast Benchmarking</title>
<author fullname="Kevin Dubray" initials="K." surname="Dubray">
<organization>IronBridge Networks</organization>

<address>
<postal>
<street>55 Hayden Avenue</street>
<street>Lexington</street>
<street>MA 02421</street>
<country>USA</country>
</postal>

<phone>781 372 8118</phone>
<email>kdubray@ironbridgenetworks.com</email>
</address>
</author>

<date year="1998" month="October" />
<area>Internet</area>
<keyword>multicast</keyword>

<abstract>
<t>
   The purpose of this document is to define terminology specific to the
   benchmarking of multicast IP forwarding devices. It builds upon the
   tenets set forth in RFC 1242, RFC 2285, and other IETF Benchmarking
   Methodology Working Group (BMWG) efforts.  This document seeks to
   extend these efforts to the multicast paradigm.
</t>

<t>
   The BMWG produces two major classes of documents: Benchmarking
   Terminology documents and Benchmarking Methodology documents. The
   Terminology documents present the benchmarks and other related terms.
   The Methodology documents define the procedures required to collect
   the benchmarks cited in the corresponding Terminology documents.
</t>
</abstract>
</front>

<seriesInfo value="2432" name="RFC" />
<format octets="46401" type="HTML" target="http://xml.resource.org/public/rfc/html/rfc2432.html" />
<format octets="32970" type="XML" target="http://xml.resource.org/public/rfc/xml/rfc2432.xml" />
</reference>


<reference target2="reference.RFC.2433.xml" anchor="RFC2433">
<front>
<title>Microsoft PPP CHAP Extensions</title>
<author fullname="Glen Zorn" initials="G." surname="Zorn">
<organization>Microsoft Corporation</organization>

<address>
<postal>
<street>One Microsoft Way</street>
<street>Redmond</street>
<street>Washington 98052</street>
</postal>

<phone>+1 425 703 1559</phone>
<facsimile>+1 425 936 7329</facsimile>
<email>glennz@microsoft.com</email>
</address>
</author>

<author fullname="Steve Cobb" initials="S." surname="Cobb">
<organization>Microsoft Corporation</organization>

<address>
<postal>
<street>One Microsoft Way</street>
<street>Redmond</street>
<street>Washington 98052</street>
</postal>

<email>stevec@microsoft.com</email>
</address>
</author>

<date year="1998" month="October" />
<area>Internet</area>
<keyword>authentication</keyword>
<keyword>challenge handshake authentication protocol</keyword>
<keyword>point-to-point protocol</keyword>
<keyword>PPP</keyword>

<note title="IESG Note">
<t>
   The protocol described here has significant vulnerabilities.  People
   planning on implementing or using this protocol should read section
   12, &quot;Security Considerations&quot;.
</t>
</note>
</front>

<seriesInfo value="2433" name="RFC" />
<format octets="48880" type="HTML" target="http://xml.resource.org/public/rfc/html/rfc2433.html" />
<format octets="35244" type="XML" target="http://xml.resource.org/public/rfc/xml/rfc2433.xml" />
</reference>


<reference target2="reference.RFC.2434.xml" anchor="RFC2434">
<front>
<title abbrev="Guidelines for IANA Considerations">Guidelines for Writing an IANA Considerations Section in RFCs</title>
<author fullname="Thomas Narten" initials="T." surname="Narten">
<organization>IBM Corporation</organization>

<address>
<postal>
<street>3039 Cornwallis Ave.</street>
<street>PO Box 12195 - BRQA/502</street>
<street>Research Triangle Park</street>
<street>NC 27709-2195</street>
</postal>

<phone>919-254-7798</phone>
<email>narten@raleigh.ibm.com</email>
</address>
</author>

<author fullname="Harald Tveit Alvestrand" initials="H.T." surname="Alvestrand">
<organization>Maxware</organization>

<address>
<postal>
<street>Pirsenteret</street>
<street>N-7005 Trondheim</street>
<country>Norway</country>
</postal>

<phone>+47 73 54 57 97</phone>
<email>Harald@Alvestrand.no</email>
</address>
</author>

<date year="1998" month="October" />
<area>General</area>
<keyword>Internet Assigned Numbers Authority</keyword>
<keyword>IANA</keyword>

<abstract>
<t>
   Many protocols make use of identifiers consisting of constants and
   other well-known values. Even after a protocol has been defined and
   deployment has begun, new values may need to be assigned (e.g., for a
   new option type in DHCP, or a new encryption or authentication
   algorithm for IPSec).  To insure that such quantities have consistent
   values and interpretations in different implementations, their
   assignment must be administered by a central authority. For IETF
   protocols, that role is provided by the Internet Assigned Numbers
   Authority (IANA).
</t>

<t>
   In order for the IANA to manage a given name space prudently, it
   needs guidelines describing the conditions under which new values can
   be assigned. If the IANA is expected to play a role in the management
   of a name space, the IANA must be given clear and concise
   instructions describing that role.  This document discusses issues
   that should be considered in formulating a policy for assigning
   values to a name space and provides guidelines to document authors on
   the specific text that must be included in documents that place
   demands on the IANA.
</t>
</abstract>
</front>

<seriesInfo value="26" name="BCP" />
<seriesInfo value="2434" name="RFC" />
<format octets="37803" type="HTML" target="http://xml.resource.org/public/rfc/html/rfc2434.html" />
<format octets="26924" type="XML" target="http://xml.resource.org/public/rfc/xml/rfc2434.xml" />
</reference>


<reference target2="reference.RFC.2435.xml" anchor="RFC2435">
<front>
<title abbrev="RTP Payload Format for JPEG">RTP Payload Format for JPEG-compressed Video</title>
<author fullname="Lance M. Berc" initials="L.M." surname="Berc">
<organization>Systems Research Center</organization>

<address>
<postal>
<street>Digital Equipment Corporation</street>
<street>130 Lytton Ave</street>
<street>Palo Alto CA 94301</street>
</postal>

<phone>+1 650 853 2100</phone>
<email>berc@pa.dec.com</email>
</address>
</author>

<author fullname="William C. Fenner" initials="W.C." surname="Fenner">
<organization>Xerox PARC</organization>

<address>
<postal>
<street>3333 Coyote Hill Road</street>
<street>Palo Alto</street>
<street>CA 94304</street>
</postal>

<phone>+1 650 812 4816</phone>
<email>fenner@parc.xerox.com</email>
</address>
</author>

<author fullname="Ron Frederick" initials="R." surname="Frederick">
<organization>Xerox PARC</organization>

<address>
<postal>
<street>3333 Coyote Hill Road</street>
<street>Palo Alto</street>
<street>CA 94304</street>
</postal>

<phone>+1 650 812 4459</phone>
<email>frederick@parc.xerox.com</email>
</address>
</author>

<author fullname="Steven McCanne" initials="S." surname="McCanne">
<organization>University of California at Berkeley</organization>

<address>
<postal>
<street>Electrical Engineering and Computer Science</street>
<street>633 Soda Hall</street>
<street>Berkeley</street>
<street>CA 94720</street>
</postal>

<phone>+1 510 642 0865</phone>
<email>mccanne@cs.berkeley.edu</email>
</address>
</author>

<author fullname="Paul Stewart" initials="P." surname="Stewart">
<organization>Xerox PARC</organization>

<address>
<postal>
<street>3333 Coyote Hill Road</street>
<street>Palo Alto</street>
<street>CA 94304</street>
</postal>

<phone>+1 650 812 4821</phone>
<email>stewart@parc.xerox.com</email>
</address>
</author>

<date year="1998" month="October" />
<area>Applications</area>
<keyword>compress</keyword>
<keyword>joint photographic experts group</keyword>
<keyword>JPEG</keyword>
<keyword>multimedia</keyword>
<keyword>real-time transport protocol</keyword>
<keyword>RTP</keyword>
<keyword>video</keyword>

<abstract>
<t>
   This memo describes the RTP payload format for JPEG video streams.
   The packet format is optimized for real-time video streams where
   codec parameters change rarely from frame to frame.
</t>

<t>
   This document is a product of the Audio-Video Transport working group
   within the Internet Engineering Task Force.  Comments are solicited
   and should be addressed to the working group&apos;s mailing list at rem-
   conf@es.net and/or the author(s).
</t>
</abstract>
</front>

<seriesInfo value="2435" name="RFC" />
<format octets="64365" type="HTML" target="http://xml.resource.org/public/rfc/html/rfc2435.html" />
<format octets="49478" type="XML" target="http://xml.resource.org/public/rfc/xml/rfc2435.xml" />
</reference>


<reference target2="reference.RFC.2436.xml" anchor="RFC2436">
<front>
<title abbrev="ISOC/IETF - ITU-T Collaboration">Collaboration between ISOC/IETF and ITU-T</title>
<author fullname="R. F. Brett" initials="R.F." surname="Brett">
<organization>Nortel Networks</organization>

<address>
<postal>
<street>P.O. Box 3511</street>
<street>Station C</street>
<street>Ottawa</street>
<street>ON  K1Y 4H7</street>
<country>Canada</country>
</postal>

<phone>+1-613-828-0902</phone>
<facsimile>+1-613-828-9408</facsimile>
<email>rfbrett@nortel.ca</email>
</address>
</author>

<author fullname="Scott O. Bradner" initials="S.O." surname="Bradner">
<organization>Harvard University</organization>

<address>
<postal>
<street>Holyoke Center</street>
<street>Room 876</street>
<street>1350 Mass. Ave.</street>
<street>Cambridge</street>
<street>MA  02138</street>
<country>USA</country>
</postal>

<phone>+1 617 495 3864</phone>
<email>sob@harvard.edu</email>
</address>
</author>

<author fullname="Glenn W. Parsons" initials="G.W." surname="Parsons">
<organization>Nortel Networks</organization>

<address>
<postal>
<street>P.O. Box 3511</street>
<street>Station C</street>
<street>Ottawa</street>
<street>ON  K1Y 4H7</street>
<country>Canada</country>
</postal>

<phone>+1-613-763-7582</phone>
<facsimile>+1-613-763-4461</facsimile>
<email>Glenn.Parsons@Nortel.ca</email>
</address>
</author>

<date year="1998" month="October" />
<area>General</area>
<keyword>International Telecommunications Union</keyword>
<keyword>International Telecommunications Union:Telecommunication Standardization Bureau</keyword>
<keyword>Internet Engineering Task Force</keyword>
<keyword>Internet Society</keyword>
</front>

<seriesInfo value="2436" name="RFC" />
<format octets="44843" type="HTML" target="http://xml.resource.org/public/rfc/html/rfc2436.html" />
<format octets="31639" type="XML" target="http://xml.resource.org/public/rfc/xml/rfc2436.xml" />
</reference>


<reference target2="reference.RFC.2437.xml" anchor="RFC2437">
<front>
<title abbrev="PKCS #1">PKCS #1: RSA Cryptography Specifications Version 2.0</title>
<author fullname="Burt Kaliski" initials="B." surname="Kaliski">
<organization>RSA Laboratories East</organization>

<address>
<postal>
<street>20 Crosby Drive</street>
<street>Bedford</street>
<street>MA  01730</street>
</postal>

<phone>(617) 687-7000</phone>
<email>burt@rsa.com</email>
</address>
</author>

<author fullname="Jessica Staddon" initials="J." surname="Staddon">
<organization>RSA Laboratories West</organization>

<address>
<postal>
<street>2955 Campus Drive</street>
<street>Suite 400</street>
<street>San Mateo</street>
<street>CA 94403</street>
</postal>

<phone>(650) 295-7600</phone>
<email>jstaddon@rsa.com</email>
</address>
</author>

<date year="1998" month="October" />
<area>Security</area>
<keyword>cryptographic</keyword>
<keyword>public key cryptography standards</keyword>
<keyword>public key encryption</keyword>
</front>

<seriesInfo value="2437" name="RFC" />
<format octets="93905" type="HTML" target="http://xml.resource.org/public/rfc/html/rfc2437.html" />
<format octets="76587" type="XML" target="http://xml.resource.org/public/rfc/xml/rfc2437.xml" />
</reference>


<reference target2="reference.RFC.2438.xml" anchor="RFC2438">
<front>
<title abbrev="Advancement of MIB specifications">Advancement of MIB specifications on the IETF Standards Track</title>
<author fullname="Michael D. O&apos;Dell" initials="M.D." surname="O&apos;Dell">
<organization>UUNET</organization>

<address>
<postal>
<street>3060 Williams Drive</street>
<city>Fairfax</city>
<region>VA</region>
<code>22031</code>
<country>US</country>
</postal>

<phone>+1 703 206 5890</phone>
<email>mo@uu.net</email>
</address>
</author>

<author fullname="Harald T. Alvestrand" initials="H.T." surname="Alvestrand">
<organization>Maxware</organization>

<address>
<postal>
<street>Pirsenteret</street>
<street>N-7005 Trondheim</street>
<country>Norway</country>
</postal>

<phone>+47-73-54-57-94</phone>
<email>Harald.Alvestrand@maxware.no</email>
</address>
</author>

<author fullname="Bert Wijnen" initials="B." surname="Wijnen">
<organization>IBM T. J. Watson Research</organization>

<address>
<postal>
<street>Schagen 33</street>
<street>3461 GL Linschoten</street>
<country>Netherlands</country>
</postal>

<phone>+31-348-432-794</phone>
<email>wijnen@vnet.ibm.com</email>
</address>
</author>

<author fullname="Scott Bradner" initials="S." surname="Bradner">
<organization>Harvard University</organization>

<address>
<postal>
<street>1350 Mass. Ave.</street>
<street>Cambridge MA 02138</street>
</postal>

<phone>+1-617-495-3864</phone>
<email>sob@harvard.edu</email>
</address>
</author>

<date year="1998" month="October" />
<area>Management</area>
<keyword>Internet Engineering Task Force</keyword>
<keyword>Management Information Base</keyword>
<keyword>MIB</keyword>

<abstract>
<t>
   The Internet Standards Process [1] requires that all IETF Standards
   Track specifications must have &quot;multiple, independent, and
   interoperable implementations&quot; before they can be advanced beyond
   Proposed Standard status.  This document specifies the process which
   the IESG will use to determine if a MIB specification document meets
   these requirements.  It also discusses the rationale for this
   process.
</t>
</abstract>
</front>

<seriesInfo value="27" name="BCP" />
<seriesInfo value="2438" name="RFC" />
<format octets="25287" type="HTML" target="http://xml.resource.org/public/rfc/html/rfc2438.html" />
<format octets="13501" type="XML" target="http://xml.resource.org/public/rfc/xml/rfc2438.xml" />
</reference>


<reference target2="reference.RFC.2439.xml" anchor="RFC2439">
<front>
<title>BGP Route Flap Damping</title>
<author fullname="Curtis Villamizar" initials="C." surname="Villamizar">
<organization>ANS</organization>

<address>
<email>curtis@ans.net</email>
</address>
</author>

<author fullname="Ravi Chandra" initials="R." surname="Chandra">
<organization>Cisco Systems</organization>

<address>
<email>rchandra@cisco.com</email>
</address>
</author>

<author fullname="Ramesh Govindan" initials="R." surname="Govindan">
<organization>ISI</organization>

<address>
<email>govindan@isi.edu</email>
</address>
</author>

<date year="1998" month="November" />
<area>Routing</area>
<keyword>border gateway protocol</keyword>
<keyword>BGP</keyword>
<keyword>routing</keyword>

<abstract>
<t>
   A usage of the BGP routing protocol is described which is capable of
   reducing the routing traffic passed on to routing peers and therefore
   the load on these peers without adversely affecting route convergence
   time for relatively stable routes.  This technique has been
   implemented in commercial products supporting BGP. The technique is
   also applicable to IDRP.
</t>

<t>
   The overall goals are:

<list>
<t>
   o  to provide a mechanism capable of reducing router processing load
      caused by instability
</t>

<t>
   o  in doing so prevent sustained routing oscillations
</t>

<t>
   o  to do so without sacrificing route convergence time for generally
      well behaved routes.
</t>
</list>
</t>

<t>
   This must be accomplished keeping other goals of BGP in mind:

<list>
<t>
   o  pack changes into a small number of updates
</t>

<t>
   o  preserve consistent routing
</t>

<t>
   o  minimal addition space and computational overhead
</t>
</list>
</t>

<t>
   An excessive rate of update to the advertised reachability of a
   subset of Internet prefixes has been widespread in the Internet.
   This observation was made in the early 1990s by many people involved
   in Internet operations and remains the case.  These excessive updates
   are not necessarily periodic so route oscillation would be a
   misleading term.  The informal term used to describe this effect is
   &quot;route flap&quot;.  The techniques described here are now widely deployed
   and are commonly referred to as &quot;route flap damping&quot;.
</t>
</abstract>
</front>

<seriesInfo value="2439" name="RFC" />
<format octets="101394" type="HTML" target="http://xml.resource.org/public/rfc/html/rfc2439.html" />
<format octets="86783" type="XML" target="http://xml.resource.org/public/rfc/xml/rfc2439.xml" />
</reference>


<reference target2="reference.RFC.2440.xml" anchor="RFC2440">
<front>
<title>OpenPGP Message Format</title>
<author fullname="Jon Callas" initials="J." surname="Callas">
<organization>Network Associates, Inc.</organization>

<address>
<postal>
<street>3965 Freedom Circle</street>
<street>Santa Clara</street>
<street>CA 95054</street>
<country>USA</country>
</postal>

<phone>+1 408-346-5860</phone>
<email>jon@pgp.com</email>
</address>
</author>

<author fullname="Lutz Donnerhacke" initials="L." surname="Donnerhacke">
<organization>IKS GmbH</organization>

<address>
<postal>
<street>Wildenbruchstr. 15</street>
<street>07745 Jena</street>
<country>Germany</country>
</postal>

<phone>+49-3641-675642</phone>
<email>lutz@iks-jena.de</email>
</address>
</author>

<author fullname="Hal Finney" initials="H." surname="Finney">
<organization>Network Associates, Inc.</organization>

<address>
<postal>
<street>3965 Freedom Circle</street>
<street>Santa Clara</street>
<street>CA 95054</street>
<country>USA</country>
</postal>

<email>hal@pgp.com</email>
</address>
</author>

<author fullname="Rodney Thayer" initials="R." surname="Thayer">
<organization>EIS Corporation</organization>

<address>
<postal>
<street>Clearwater</street>
<street>FL 33767</street>
<country>USA</country>
</postal>

<email>rodney@unitran.com</email>
</address>
</author>

<date year="1998" month="November" />
<area>Security</area>
<keyword>pretty good privacy</keyword>
<keyword>PGP</keyword>
<keyword>security</keyword>

<abstract>
<t>
   This document defines many tag values, yet it doesn&apos;t describe a
   mechanism for adding new tags (for new features).  Traditionally the
   Internet Assigned Numbers Authority (IANA) handles the allocation of
   new values for future expansion and RFCs usually define the procedure
   to be used by the IANA.  However, there are subtle (and not so
   subtle) interactions that may occur in this protocol between new
   features and existing features which result in a significant
   reduction in over all security.  Therefore, this document does not
   define an extension procedure.  Instead requests to define new tag
   values (say for new encryption algorithms for example) should be
   forwarded to the IESG Security Area Directors for consideration or
   forwarding to the appropriate IETF Working Group for consideration.
</t>

<t>
   This document is maintained in order to publish all necessary
   information needed to develop interoperable applications based on the
   OpenPGP format. It is not a step-by-step cookbook for writing an
   application. It describes only the format and methods needed to read,
   check, generate, and write conforming packets crossing any network.
   It does not deal with storage and implementation questions.  It does,
   however, discuss implementation issues necessary to avoid security
   flaws.
</t>

<t>
   Open-PGP software uses a combination of strong public-key and
   symmetric cryptography to provide security services for electronic
   communications and data storage.  These services include
   confidentiality, key management, authentication, and digital
   signatures. This document specifies the message formats used in
   OpenPGP.
</t>
</abstract>

<note title="IESG Note">
<t>
   This document defines many tag values, yet it doesn&apos;t describe a
   mechanism for adding new tags (for new features).  Traditionally the
   Internet Assigned Numbers Authority (IANA) handles the allocation of
   new values for future expansion and RFCs usually define the procedure
   to be used by the IANA.  However, there are subtle (and not so
   subtle) interactions that may occur in this protocol between new
   features and existing features which result in a significant
   reduction in over all security.  Therefore, this document does not
   define an extension procedure.  Instead requests to define new tag
   values (say for new encryption algorithms for example) should be
   forwarded to the IESG Security Area Directors for consideration or
   forwarding to the appropriate IETF Working Group for consideration.
</t>
</note>
</front>

<seriesInfo value="2440" name="RFC" />
<format octets="157503" type="HTML" target="http://xml.resource.org/public/rfc/html/rfc2440.html" />
<format octets="137186" type="XML" target="http://xml.resource.org/public/rfc/xml/rfc2440.xml" />
</reference>


<reference target2="reference.RFC.2441.xml" anchor="RFC2441">
<front>
<title abbrev="Working with Jon">Working with Jon Tribute delivered at UCLA, October 30, 1998</title>
<author fullname="Danny Cohen" initials="D." surname="Cohen">
<organization>Myricom</organization>

<address>
<email>cohen@myri.com</email>
</address>
</author>

<date year="1998" month="November" />
<area>General</area>
<keyword>Jon Postel</keyword>
</front>

<seriesInfo value="2441" name="RFC" />
<format octets="8999" type="HTML" target="http://xml.resource.org/public/rfc/html/rfc2441.html" />
<format octets="1726" type="XML" target="http://xml.resource.org/public/rfc/xml/rfc2441.xml" />
</reference>


<reference target2="reference.RFC.2442.xml" anchor="RFC2442">
<front>
<title abbrev="Batch SMTP Media Type">The Batch SMTP Media Type</title>
<author fullname="Ned Freed" initials="N." surname="Freed">
<organization>Innosoft International, Inc.</organization>

<address>
<postal>
<street>1050 Lakes Drive</street>
<street>West Covina</street>
<street>CA 91790</street>
<country>USA</country>
</postal>

<phone>+1 626 919 3600</phone>
<facsimile>+1 626 919 3614</facsimile>
<email>ned.freed@innosoft.com</email>
</address>
</author>

<author fullname="Dan Newman" initials="D." surname="Newman">
<organization>Innosoft International, Inc.</organization>

<address>
<postal>
<street>1050 Lakes Drive</street>
<street>West Covina</street>
<street>CA 91790</street>
<country>USA</country>
</postal>

<phone>+1 626 919 3600</phone>
<facsimile>+1 626 919 3614</facsimile>
<email>dan.newman@innosoft.com</email>
</address>
</author>

<author fullname="Mark Hoy" initials="M." surname="Hoy">
<organization>Mainbrace Corporation</organization>

<address>
<postal>
<street>1136 West Evelyn Avenue</street>
<street>Sunnyvale</street>
<street>CA 94086</street>
</postal>

<phone>+1 408 774 5265</phone>
<facsimile>+1 408 774 5290</facsimile>
<email>mark.hoy@mainbrace.com</email>
</address>
</author>

<author>
<organization />

<address>
<email>jacques.belissent@eng.sun.com</email>
</address>
</author>

<date year="1998" month="November" />
<area>Applications</area>
<keyword>content-type</keyword>
<keyword>media type</keyword>
<keyword>multipurpose internet mail extensions</keyword>
<keyword>security</keyword>
<keyword>simple mail transfer protocol</keyword>
<keyword>tunnel</keyword>

<abstract>
<t>
   This document defines a MIME content type suitable for tunneling an
   ESMTP [RFC-821, RFC-1869] transaction through any MIME-capable
   transport.  This type can be used for a variety of purposes,
   including:  Extending end-to-end MIME-based security services (e.g.,
   ) to cover message envelope information as well as message
   content.  Making it possible to use specific SMTP extensions such as
   NOTARY [RFC-1891] over unextended SMTP transport infrastructure.
   Enabling the transfer of multiple separate messages in a single
   transactional unit.
</t>
</abstract>
</front>

<seriesInfo value="2442" name="RFC" />
<format octets="28880" type="HTML" target="http://xml.resource.org/public/rfc/html/rfc2442.html" />
<format octets="18615" type="XML" target="http://xml.resource.org/public/rfc/xml/rfc2442.xml" />
</reference>


<reference target2="reference.RFC.2443.xml" anchor="RFC2443">
<front>
<title abbrev="MARS Service Using SCSP">A Distributed MARS Service Using SCSP</title>
<author fullname="James V. Luciani" initials="J.V." surname="Luciani">
<organization>Bay Networks, Inc.</organization>

<address>
<postal>
<street>3 Federal Street</street>
<street>BL3-04</street>
<street>Billerica</street>
<street>MA  01821</street>
</postal>

<phone>+1-508-916-4734</phone>
<email>luciani@baynetworks.com</email>
</address>
</author>

<author fullname="Anthony M. Gallo" initials="A.M." surname="Gallo">
<organization>IBM, Networking Hardware Division</organization>

<address>
<postal>
<street>Dept. M6LA/B664</street>
<street>P.O. Box 12195</street>
<street>Research Triangle Park</street>
<street>NC 27709</street>
</postal>

<phone>+1-919-254-9889</phone>
<email>gallo@raleigh.ibm.com</email>
</address>
</author>

<date year="1998" month="November" />
<area>Internet</area>
<keyword>MARS</keyword>
<keyword>cache</keyword>

<abstract>
<t>
   This document describes a method for distributing a MARS service
   within a LIS.  This method uses the Server Cache Synchronization
   Protocol (SCSP) to synchronize the MARS Server databases within a
   LIS.  When SCSP is used to synchronize the caches of MARS Servers in
   a LIS, the LIS defines the boundary of an SCSP Server Group (SG).
</t>
</abstract>
</front>

<seriesInfo value="2443" name="RFC" />
<format octets="60129" type="HTML" target="http://xml.resource.org/public/rfc/html/rfc2443.html" />
<format octets="43501" type="XML" target="http://xml.resource.org/public/rfc/xml/rfc2443.xml" />
</reference>


<reference target2="reference.RFC.2444.xml" anchor="RFC2444">
<front>
<title abbrev="OTP SASL Mechanism">The One-Time-Password SASL Mechanism</title>
<author fullname="Chris Newman" initials="C." surname="Newman">
<organization>Innosoft International, Inc.</organization>

<address>
<postal>
<street>1050 Lakes Drive</street>
<street>West Covina</street>
<street>CA 91790</street>
<country>USA</country>
</postal>

<email>chris.newman@innosoft.com</email>
</address>
</author>

<date year="1998" month="October" />
<area>Security</area>
<keyword>OTP</keyword>
<keyword>authentication</keyword>
<keyword>one-time password</keyword>
<keyword>password</keyword>

<abstract>
<t>
   OTP  provides a useful authentication mechanism for situations
   where there is limited client or server trust.  Currently, OTP is
   added to protocols in an ad-hoc fashion with heuristic parsing.  This
   specification defines an OTP SASL  mechanism so it can be
   easily and formally integrated into many application protocols.
</t>
</abstract>
</front>

<seriesInfo value="2444" name="RFC" />
<format octets="29780" type="HTML" target="http://xml.resource.org/public/rfc/html/rfc2444.html" />
<format octets="16837" type="XML" target="http://xml.resource.org/public/rfc/xml/rfc2444.xml" />
</reference>


<reference target2="reference.RFC.2445.xml" anchor="RFC2445">
<front>
<title abbrev="iCalendar">Internet Calendaring and Scheduling Core Object Specification (iCalendar)</title>
<author fullname="Frank Dawson" initials="F." surname="Dawson">
<organization>Lotus Development Corporation</organization>

<address>
<postal>
<street>6544 Battleford Drive</street>
<city>Raleigh</city>
<region>NC</region>
<code>27613-3502</code>
<country>USA</country>
</postal>

<phone>+1-919-676-9515</phone>
<facsimile>+1-919-676-9564</facsimile>
<email>Frank_Dawson@Lotus.com</email>
<uri>http://home.earthlink.net/~fdawson</uri>
</address>
</author>

<author fullname="Derik Stenerson" initials="D." surname="Stenerson">
<organization>Microsoft Corporation</organization>

<address>
<postal>
<street>One Microsoft Way</street>
<city>Redmond</city>
<region>WA</region>
<code>98052-6399</code>
<country>USA</country>
</postal>

<phone>+1-425-936-5522</phone>
<facsimile>+1-425-936-7329</facsimile>
<email>deriks@Microsoft.com</email>
</address>
</author>

<author>
<organization />
</author>

<author>
<organization />
</author>

<date year="1998" month="November" />
<area>Applications</area>
<keyword>calendaring</keyword>
<keyword>scheduling</keyword>
<keyword>PIM</keyword>

<abstract>
<t>
   There is a clear need to provide and deploy interoperable calendaring
   and scheduling services for the Internet. Current group scheduling
   and Personal Information Management (PIM) products are being extended
   for use across the Internet, today, in proprietary ways. This memo
   has been defined to provide the definition of a common format for
   openly exchanging calendaring and scheduling information across the
   Internet.
</t>

<t>
   This memo is formatted as a registration for a MIME media type per
   . However, the format in this memo is equally applicable
   for use outside of a MIME message content type.
</t>

<t>
   The proposed media type value is &apos;text/calendar&apos;. This string would
   label a media type containing calendaring and scheduling information
   encoded as text characters formatted in a manner outlined below.
</t>

<t>
   This MIME media type provides a standard content type for capturing
   calendar event, to-do and journal entry information. It also can be
   used to convey free/busy time information. The content type is
   suitable as a MIME message entity that can be transferred over MIME
   based email systems, using HTTP or some other Internet transport. In
   addition, the content type is useful as an object for interactions
   between desktop applications using the operating system clipboard,
   drag/drop or file systems capabilities.
</t>

<t>
   This memo is based on the earlier work of the vCalendar specification
   for the exchange of personal calendaring and scheduling information.
   In order to avoid confusion with this referenced work, this memo is
   to be known as the iCalendar specification.
</t>

<t>
   This memo defines the format for specifying iCalendar object methods.
   An iCalendar object method is a set of usage constraints for the
   iCalendar object. For example, these methods might define scheduling
   messages that request an event be scheduled, reply to an event
   request, send a cancellation notice for an event, modify or replace
   the definition of an event, provide a counter proposal for an
   original event request, delegate an event request to another
   individual, request free or busy time, reply to a free or busy time
   request, or provide similar scheduling messages for a to-do or
   journal entry calendar component. The iCalendar Transport-indendent
   Interoperability Protocol (iTIP) defined in  is one such
   scheduling protocol.
</t>
</abstract>
</front>

<seriesInfo value="2445" name="RFC" />
<format octets="323537" type="HTML" target="http://xml.resource.org/public/rfc/html/rfc2445.html" />
<format octets="305481" type="XML" target="http://xml.resource.org/public/rfc/xml/rfc2445.xml" />
</reference>


<reference target2="reference.RFC.2446.xml" anchor="RFC2446">
<front>
<title abbrev="iTIP">iCalendar Transport-Independent Interoperability Protocol (iTIP) Scheduling Events, BusyTime, To-dos and Journal Entries</title>
<author fullname="Steve Silverberg" initials="S." surname="Silverberg">
<organization>Microsoft Corporation</organization>

<address>
<postal>
<street>One Microsoft Way</street>
<city>Redmond</city>
<region>WA</region>
<code>98052-6399</code>
<country>USA</country>
</postal>

<phone>+1-425-936-9277</phone>
<facsimile>+1-425-936-8019</facsimile>
<email>stevesil@Microsoft.com</email>
</address>
</author>

<author fullname="Steve Mansour" initials="S." surname="Mansour">
<organization>Netscape Communications Corporation</organization>

<address>
<postal>
<street>501 East Middlefield Road</street>
<city>MountainView</city>
<region>CA</region>
<code>94043</code>
<country>USA</country>
</postal>

<phone>+1-650-937-2378</phone>
<facsimile>+1-650-937-2103</facsimile>
<email>sman@netscape.com</email>
</address>
</author>

<author fullname="Frank Dawson" initials="F." surname="Dawson">
<organization>Lotus Development Corporation</organization>

<address>
<postal>
<street>6544 Battleford Drive</street>
<city>Raleigh</city>
<region>NC</region>
<code>27613-3502</code>
<country>USA</country>
</postal>

<phone>+1-919-676-9515</phone>
<facsimile>+1-919-676-9564</facsimile>
<email>Frank_Dawson@Lotus.com</email>
<uri>http://home.earthlink.net/~fdawson</uri>
</address>
</author>

<author fullname="Ross Hopson" initials="R." surname="Hopson">
<organization>On Technology, Inc.</organization>

<address>
<postal>
<street>434 Fayetteville St.Mall, Two Hannover Square</street>
<street>Suite 1600</street>
<city>Raleigh</city>
<region>NC</region>
<code>27601</code>
</postal>

<phone>+1-919-890-4036</phone>
<facsimile>+1-919-890-4100</facsimile>
<email>rhopson@on.com</email>
</address>
</author>

<date year="1998" month="November" />
<area>Applications</area>
<keyword>calendaring</keyword>
<keyword>scheduling</keyword>

<abstract>
<t>
   This document specifies how calendaring systems use iCalendar objects
   to interoperate with other calendar systems. It does so in a general
   way so as to allow multiple methods of communication between systems.
   Subsequent documents specify interoperable methods of communications
   between systems that use this protocol.
</t>

<t>
   The document outlines a model for calendar exchange that defines both
   static and dynamic event, to-do, journal and free/busy objects.
   Static objects are used to transmit information from one entity to
   another without the expectation of continuity or referential
   integrity with the original item. Dynamic objects are a superset of
   static objects and will gracefully degrade to their static
   counterparts for clients that only support static objects.
</t>

<t>
   This document specifies an Internet protocol based on the iCalendar
   object specification that provides scheduling interoperability
   between different calendar systems. The Internet protocol is called
   the &quot;iCalendar Transport-Independent Interoperability Protocol
   (iTIP)&quot;.
   iTIP complements the iCalendar object specification by adding
   semantics for group scheduling methods commonly available in current
   calendar systems. These scheduling methods permit two or more
   calendar systems to perform transactions such as publish, schedule,
   reschedule, respond to scheduling requests, negotiation of changes or
   cancel iCalendar-based calendar components.
</t>

<t>
   iTIP is defined independent of the particular transport used to
   transmit the scheduling information. Companion memos to iTIP provide
   bindings of the interoperability protocol to a number of Internet
   protocols.
</t>
</abstract>
</front>

<seriesInfo value="2446" name="RFC" />
<format octets="249838" type="HTML" target="http://xml.resource.org/public/rfc/html/rfc2446.html" />
<format octets="229099" type="XML" target="http://xml.resource.org/public/rfc/xml/rfc2446.xml" />
</reference>


<reference target2="reference.RFC.2447.xml" anchor="RFC2447">
<front>
<title abbrev="iMIP">iCalendar Message-Based Interoperability Protocol (iMIP)</title>
<author fullname="Frank Dawson" initials="F." surname="Dawson">
<organization>Lotus Development Corporation</organization>

<address>
<postal>
<street>6544 BattlefordDrive</street>
<city>Raleigh</city>
<region>NC</region>
<code>27613-3502</code>
<country>USA</country>
</postal>

<phone>+1-919-676-9515</phone>
<facsimile>+1-919-676-9564</facsimile>
<email>fdawson@earthlink.net</email>
<uri>http://home.earthlink.net/~fdawson</uri>
</address>
</author>

<author fullname="Steve Mansour" initials="S." surname="Mansour">
<organization>Netscape Communications Corporation</organization>

<address>
<postal>
<street>501 East Middlefield Road</street>
<city>MountainView</city>
<region>CA</region>
<code>94043</code>
<country>USA</country>
</postal>

<phone>+1-650-937-2378</phone>
<facsimile>+1-650-937-2103</facsimile>
<email>sman@netscape.com</email>
</address>
</author>

<author fullname="Steve Silverberg" initials="S." surname="Silverberg">
<organization>Microsoft Corporation</organization>

<address>
<postal>
<street>One Microsoft Way</street>
<city>Redmond</city>
<region>WA</region>
<code>98052-6399</code>
<country>USA</country>
</postal>

<phone>+1-425-936-9277</phone>
<facsimile>+1-425-936-8019</facsimile>
<email>stevesil@Microsoft.com</email>
</address>
</author>

<date year="1998" month="November" />
<area>Applications</area>
<keyword>calendaring</keyword>
<keyword>iMIP</keyword>

<abstract>
<t>
   This document, [iMIP], specifies a binding from the iCalendar
   Transport-independent Interoperability Protocol (iTIP) to Internet
   email-based transports. Calendaring entries defined by the iCalendar
   Object Model  are composed using constructs from ,
   , , ,  and [RFC-2049].
</t>

<t>
   This document is based on discussions within the Internet Engineering
   Task Force (IETF) Calendaring and Scheduling (CALSCH) working group.
   More information about the IETF CALSCH working group activities can
   be found on the IMC web site at http://www.imc.org, the IETF web site
   at http://www.ietf.org/html.charters/calsch-charter.html. Refer to
   the references within this document for further information on how to
   access these various documents.
</t>
</abstract>
</front>

<seriesInfo value="2447" name="RFC" />
<format octets="53600" type="HTML" target="http://xml.resource.org/public/rfc/html/rfc2447.html" />
<format octets="34719" type="XML" target="http://xml.resource.org/public/rfc/xml/rfc2447.xml" />
</reference>


<reference target2="reference.RFC.2448.xml" anchor="RFC2448">
<front>
<title abbrev="AT&amp;T&apos;s Error Resilient">AT&amp;T&apos;s Error Resilient Video Transmission Technique</title>
<author fullname="M. Reha Civanlar" initials="M.R." surname="Civanlar">
<organization>AT&amp;T Labs-Research</organization>

<address>
<postal>
<street>100 Schultz Drive</street>
<street>Red Bank</street>
<street>NJ 07701</street>
<country>USA</country>
</postal>

<email>civanlar@research.att.com</email>
</address>
</author>

<author fullname="Glenn L. Cash" initials="G.L." surname="Cash">
<organization>AT&amp;T Labs-Research</organization>

<address>
<postal>
<street>100 Schultz Drive</street>
<street>Red Bank</street>
<street>NJ 07701</street>
<country>USA</country>
</postal>

<email>glenn@research.att.com</email>
</address>
</author>

<author fullname="Barry G. Haskell" initials="B.G." surname="Haskell">
<organization>AT&amp;T Labs-Research</organization>

<address>
<postal>
<street>100 Schultz Drive</street>
<street>Red Bank</street>
<street>NJ 07701</street>
<country>USA</country>
</postal>

<email>bgh@research.att.com</email>
</address>
</author>

<date year="1998" month="November" />
<area>Applications</area>
<keyword>compress</keyword>
<keyword>video</keyword>

<abstract>
<t>
   This document describes a set of techniques for packet loss resilient
   transmission of compressed video bitstreams based on reliable
   delivery of their vital information-carrying segments. The described
   techniques can be used over packet networks without packet
   prioritization. These techniques are related to AT&amp;T/Lucent patents
   [1, 2].
</t>
</abstract>
</front>

<seriesInfo value="2448" name="RFC" />
<format octets="25680" type="HTML" target="http://xml.resource.org/public/rfc/html/rfc2448.html" />
<format octets="16008" type="XML" target="http://xml.resource.org/public/rfc/xml/rfc2448.xml" />
</reference>


<reference target2="reference.RFC.2449.xml" anchor="RFC2449">
<front>
<title>POP3 Extension Mechanism</title>
<author fullname="Randall Gellens" initials="R." surname="Gellens">
<organization>QUALCOMM Incorporated</organization>

<address>
<postal>
<street>6455 Lusk Blvd.</street>
<street>San Diego</street>
<street>CA  92121-2779</street>
<country>USA</country>
</postal>

<phone>+1 619 651 5115</phone>
<facsimile>+1 619 845 7268</facsimile>
<email>randy@qualcomm.com</email>
</address>
</author>

<author fullname="Chris Newman" initials="C." surname="Newman">
<organization>Innosoft International, Inc.</organization>

<address>
<postal>
<street>1050 Lakes Drive</street>
<street>West Covina</street>
<street>CA 91790</street>
<country>USA</country>
</postal>

<email>chris.newman@innosoft.com</email>
</address>
</author>

<author fullname="Laurence Lundblade" initials="L." surname="Lundblade">
<organization>QUALCOMM Incorporated</organization>

<address>
<postal>
<street>6455 Lusk Blvd.</street>
<street>San Diego</street>
<street>92121-2779</street>
<country>USA</country>
</postal>

<phone>+1 619 658 3584</phone>
<facsimile>+1 619 845 7268</facsimile>
<email>lgl@qualcomm.com</email>
</address>
</author>

<date year="1998" month="November" />
<area>Applications</area>
<keyword>post office protocol</keyword>
<keyword>POP</keyword>

<note title="IESG Note">
<t>
   This extension to the POP3 protocol is to be used by a server to
   express policy descisions taken by the server administrator.  It is
   not an endorsement of implementations of further POP3 extensions
   generally.  It is the general view that the POP3 protocol should stay
   simple, and for the simple purpose of downloading email from a mail
   server.  If more complicated operations are needed, the IMAP protocol
   [RFC 2060] should be used.  The first paragraph of section 7 should
   be read very carefully.
</t>
</note>
</front>

<seriesInfo value="2449" name="RFC" />
<format octets="55767" type="HTML" target="http://xml.resource.org/public/rfc/html/rfc2449.html" />
<format octets="37933" type="XML" target="http://xml.resource.org/public/rfc/xml/rfc2449.xml" />
</reference>


<reference target2="reference.RFC.2450.xml" anchor="RFC2450">
<front>
<title>Proposed TLA and NLA Assignment Rules</title>
<author fullname="Robert M. Hinden" initials="R.M." surname="Hinden">
<organization>Nokia</organization>

<address>
<postal>
<street>232 Java Drive</street>
<street>Sunnyvale</street>
<street>CA 94089</street>
<country>USA</country>
</postal>

<phone>+1 408 990-2004</phone>
<email>hinden@iprg.nokia.com</email>
</address>
</author>

<date year="1998" month="December" />
<area>Internet</area>
<keyword>Top-Level Aggregation identifiers</keyword>
<keyword>TLA</keyword>
</front>

<seriesInfo value="2450" name="RFC" />
<format octets="37589" type="HTML" target="http://xml.resource.org/public/rfc/html/rfc2450.html" />
<format octets="26644" type="XML" target="http://xml.resource.org/public/rfc/xml/rfc2450.xml" />
</reference>


<reference target2="reference.RFC.2451.xml" anchor="RFC2451">
<front>
<title>The ESP CBC-Mode Cipher Algorithms</title>
<author fullname="Roy Pereira" initials="R." surname="Pereira">
<organization>TimeStep Corporation</organization>

<address>
<phone>+1 613 599 3610 x 4808</phone>
<email>rpereira@timestep.com</email>
</address>
</author>

<author fullname="Rob Adams" initials="R." surname="Adams">
<organization>Cisco Systems Inc.</organization>

<address>
<phone>+1 408 457 5397</phone>
<email>adams@cisco.com</email>
</address>
</author>

<date year="1998" month="November" />
<area>Internet</area>
<area>Security</area>
<keyword>IP security protocol</keyword>
<keyword>cipher block chaining</keyword>
<keyword>encapsulate</keyword>
<keyword>encapsulating security payload</keyword>
<keyword>encryption</keyword>
<keyword>security</keyword>

<abstract>
<t>
   This document describes how to use CBC-mode cipher algorithms with
   the IPSec ESP (Encapsulating Security Payload) Protocol.  It not only
   clearly states how to use certain cipher algorithms, but also how to
   use all CBC-mode cipher algorithms.
</t>
</abstract>
</front>

<seriesInfo value="2451" name="RFC" />
<format octets="41501" type="HTML" target="http://xml.resource.org/public/rfc/html/rfc2451.html" />
<format octets="35857" type="XML" target="http://xml.resource.org/public/rfc/xml/rfc2451.xml" />
</reference>


<reference target2="reference.RFC.2452.xml" anchor="RFC2452">
<front>
<title abbrev="TCP MIB for IPv6">IP Version 6 Management Information Base for the Transmission Control Protocol</title>
<author fullname="Mike Daniele" initials="M." surname="Daniele">
<organization>Compaq Computer Corporation</organization>

<address>
<postal>
<street>110 Spit Brook Rd</street>
<street>Nashua</street>
<region>NH</region>
<code>03062</code>
<country>USA</country>
</postal>

<phone>+1 603 884 1423</phone>
<email>daniele@zk3.dec.com</email>
</address>
</author>

<date year="1998" month="December" />
<area>Transport</area>
<area>Management</area>
<keyword>Management Information Base</keyword>
<keyword>control protocol</keyword>
<keyword>internet protocol version 6</keyword>
<keyword>transmission control protocol</keyword>

<abstract>
<t>
   This document is one in the series of documents that define various
   MIB objects for IPv6.  Specifically, this document is the MIB module
   which defines managed objects for implementations of the Transmission
   Control Protocol (TCP) over IP Version 6 (IPv6).
</t>

<t>
   This document also recommends a specific policy with respect to the
   applicability of RFC 2012 for implementations of IPv6.  Namely, that
   most of managed objects defined in RFC 2012 are independent of which
   IP versions underlie TCP, and only the TCP connection information is
   IP version-specific.
</t>

<t>
   This memo defines an experimental portion of the Management
   Information Base (MIB) for use with network management protocols in
   IPv6-based internets.
</t>
</abstract>
</front>

<seriesInfo value="2452" name="RFC" />
<format octets="33833" type="HTML" target="http://xml.resource.org/public/rfc/html/rfc2452.html" />
<format octets="27576" type="XML" target="http://xml.resource.org/public/rfc/xml/rfc2452.xml" />
</reference>


<reference target2="reference.RFC.2453.xml" anchor="RFC2453">
<front>
<title>RIP Version 2</title>
<author fullname="Gary Scott Malkin" initials="G.S." surname="Malkin">
<organization>Bay Networks</organization>

<address>
<postal>
<street>8 Federal Street</street>
<street>Billerica</street>
<street>MA 01821</street>
</postal>

<phone>(978) 916-4237</phone>
<email>gmalkin@baynetworks.com</email>
</address>
</author>

<date year="1998" month="November" />
<area>Routing</area>
<keyword>routing</keyword>
<keyword>routing information protocol</keyword>
<keyword>security</keyword>

<abstract>
<t>
   This document specifies an extension of the Routing Information
   Protocol (RIP), as defined in , to expand the amount of useful
   information carried in RIP messages and to add a measure of security.
</t>

<t>
   A companion document will define the SNMP MIB objects for RIP-2 .
   An additional document will define cryptographic security
   improvements for RIP-2 .
</t>
</abstract>
</front>

<seriesInfo value="56" name="STD" />
<seriesInfo value="2453" name="RFC" />
<format octets="109500" type="HTML" target="http://xml.resource.org/public/rfc/html/rfc2453.html" />
<format octets="99388" type="XML" target="http://xml.resource.org/public/rfc/xml/rfc2453.xml" />
</reference>


<reference target2="reference.RFC.2454.xml" anchor="RFC2454">
<front>
<title abbrev="UDP MIB for IPv6">IP Version 6 Management Information Base for the User Datagram Protocol</title>
<author fullname="Mike Daniele" initials="M." surname="Daniele">
<organization>Compaq Computer Corporation</organization>

<address>
<postal>
<street>110 Spit Brook Rd</street>
<street>Nashua</street>
<region>NH</region>
<code>03062</code>
<country>USA</country>
</postal>

<phone>+1 603 884 1423</phone>
<email>daniele@zk3.dec.com</email>
</address>
</author>

<date year="1998" month="December" />
<area>Transport</area>
<keyword>UDP</keyword>
<keyword>Management Information Base</keyword>
<keyword>datagram</keyword>
<keyword>internet protocol version 6</keyword>
<keyword>user datagram protocol</keyword>

<abstract>
<t>
   This document is one in the series of documents that define various
   MIB objects for IPv6.  Specifically, this document is the MIB module
   which defines managed objects for implementations of the User
   Datagram Protocol (UDP) over IP Version 6 (IPv6).
</t>

<t>
   This document also recommends a specific policy with respect to the
   applicability of RFC 2013 for implementations of IPv6.  Namely, that
   most of managed objects defined in RFC 2013 are independent of which
   IP versions underlie UDP, and only the UDP listener information is IP
   version-specific.
</t>

<t>
   This memo defines an experimental portion of the Management
   Information Base (MIB) for use with network management protocols in
   IPv6-based internets.
</t>
</abstract>
</front>

<seriesInfo value="2454" name="RFC" />
<format octets="30473" type="HTML" target="http://xml.resource.org/public/rfc/html/rfc2454.html" />
<format octets="24340" type="XML" target="http://xml.resource.org/public/rfc/xml/rfc2454.xml" />
</reference>


<reference target2="reference.RFC.2455.xml" anchor="RFC2455">
<front>
<title abbrev="APPN MIB">Definitions of Managed Objects for APPN</title>
<author fullname="Bob Clouston" initials="B." surname="Clouston">
<organization>Cisco Systems</organization>

<address>
<postal>
<street>7025 Kit Creek Road</street>
<street>P.O. Box 14987</street>
<street>Research Triangle Park</street>
<region>NC</region>
<code>27709</code>
<country>USA</country>
</postal>

<phone>+1 919 472 2333</phone>
<email>clouston@cisco.com</email>
</address>
</author>

<author fullname="Robert Moore" initials="R." surname="Moore">
<organization>IBM Corporation</organization>

<address>
<postal>
<street>3039 Cornwallis</street>
<street>Dept. BRQA/Bldg. 501/G114</street>
<street>P.O.Box 12195</street>
<street>Research Triangle Park</street>
<region>NC</region>
<code>27709</code>
<country>USA</country>
</postal>

<phone>+1 919 254 4436</phone>
<email>remoore@us.ibm.com</email>
</address>
</author>

<date year="1998" month="November" />
<area>Management</area>
<keyword>IBM SNA advanced peer-to-peer networking</keyword>
<keyword>Management Information Base</keyword>
<keyword>managed object</keyword>

<abstract>
<t>
   This memo defines a portion of the Management Information Base (MIB)
   for use with network management protocols in the Internet community.
   In particular, it defines objects for monitoring and controlling
   network devices with APPN (Advanced Peer-to-Peer Networking)
   capabilities.  This memo identifies managed objects for the APPN
   protocol.
</t>
</abstract>
</front>

<seriesInfo value="2455" name="RFC" />
<format octets="264557" type="HTML" target="http://xml.resource.org/public/rfc/html/rfc2455.html" />
<format octets="274672" type="XML" target="http://xml.resource.org/public/rfc/xml/rfc2455.xml" />
</reference>


<reference target2="reference.RFC.2456.xml" anchor="RFC2456">
<front>
<title abbrev="APPN TRAPS MIB">Definitions of Managed Objects for APPN TRAPS</title>
<author fullname="Bob Clouston" initials="B." surname="Clouston">
<organization>Cisco Systems</organization>

<address>
<postal>
<street>7025 Kit Creek Road</street>
<street>P.O. Box 14987</street>
<street>Research Triangle Park</street>
<region>NC</region>
<code>27709</code>
<country>USA</country>
</postal>

<phone>+1 919 472 2333</phone>
<email>clouston@cisco.com</email>
</address>
</author>

<author fullname="Robert Moore" initials="R." surname="Moore">
<organization>IBM Corporation</organization>

<address>
<postal>
<street>3039 Cornwallis</street>
<street>Dept. BRQA/Bldg. 501/G114</street>
<street>P.O.Box 12195</street>
<street>Research Triangle Park</street>
<region>NC</region>
<code>27709</code>
<country>USA</country>
</postal>

<phone>+1 919 254 4436</phone>
<email>remoore@us.ibm.com</email>
</address>
</author>

<date year="1998" month="November" />
<area>Management</area>
<keyword>IBM SNA advanced peer-to-peer networking</keyword>
<keyword>Management Information Base</keyword>
<keyword>managed object</keyword>

<abstract>
<t>
   This memo defines a portion of the Management Information Base (MIB)
   for use with network management protocols in the Internet community.
   In particular, it defines objects for receiving notifications from
   network devices with APPN (Advanced Peer-to-Peer Network) and DLUR
   (Dependent LU Requester) capabilities.  This memo identifies
   notifications for the APPN and DLUR architecture.
</t>
</abstract>
</front>

<seriesInfo value="2456" name="RFC" />
<format octets="64410" type="HTML" target="http://xml.resource.org/public/rfc/html/rfc2456.html" />
<format octets="70100" type="XML" target="http://xml.resource.org/public/rfc/xml/rfc2456.xml" />
</reference>


<reference target2="reference.RFC.2457.xml" anchor="RFC2457">
<front>
<title abbrev="Extended Border Node MIB">Definitions of Managed Objects for Extended Border Node</title>
<author fullname="Bob Clouston" initials="B." surname="Clouston">
<organization>Cisco Systems</organization>

<address>
<postal>
<street>7025 Kit Creek Road</street>
<street>P.O. Box 14987</street>
<street>Research Triangle Park</street>
<region>NC</region>
<code>27709</code>
<country>USA</country>
</postal>

<phone>+1 919 472 2333 </phone>
<email>clouston@cisco.com</email>
</address>
</author>

<author fullname="Robert Moore" initials="R." surname="Moore">
<organization>IBM Corporation</organization>

<address>
<postal>
<street>3039 Cornwallis</street>
<street>Dept. BRQA/Bldg. 501/G114</street>
<street>P.O.Box 12195</street>
<city>Research Triangle Park</city>
<region>NC</region>
<code>27709</code>
<country>USA</country>
</postal>

<phone>+1 919 254 4436 </phone>
<email>remoore@us.ibm.com</email>
</address>
</author>

<date year="1998" month="November" />
<area>Management</area>
<keyword>Management Information Base</keyword>
<keyword>managed object</keyword>

<abstract>
<t>
   This memo defines a portion of the Management Information Base (MIB)
   for use with network management protocols in the Internet community.
   In particular, it defines objects for monitoring and controlling
   network devices with APPN (Advanced Peer-to-Peer Network) EBN
   (Extended Border Node) capabilities.  This memo identifies managed
   objects for the EBN architecture.
</t>
</abstract>
</front>

<seriesInfo value="2457" name="RFC" />
<format octets="72015" type="HTML" target="http://xml.resource.org/public/rfc/html/rfc2457.html" />
<format octets="74908" type="XML" target="http://xml.resource.org/public/rfc/xml/rfc2457.xml" />
</reference>


<reference target2="reference.RFC.2458.xml" anchor="RFC2458">
<front>
<title abbrev="Pre-PINT Implementations">Toward the PSTN/Internet Inter-Networking --Pre-PINT Implementations</title>
<author fullname="Hui-Lan Lu" initials="H." surname="Lu">
<organization>Bell Laboratories, Lucent Technologies</organization>

<address>
<postal>
<street>Room 4K-309</street>
<street>101 Crawfords Corner Road</street>
<city>Holmdel</city>
<region>NJ</region>
<code>07733-3030</code>
<country>USA</country>
</postal>

<phone>+1 732 949 0321</phone>
<facsimile>+1 732 949 1196</facsimile>
<email>hui-lan.lu@bell-labs.com</email>
</address>
</author>

<author fullname="Murali Krishnaswamy" initials="M." surname="Krishnaswamy">
<organization>Lucent Technologies, Bell Laboratories</organization>

<address>
<postal>
<street>Room 2G-527a</street>
<street>101 Crawfords Corner Road</street>
<city>Holmdel</city>
<region>NJ</region>
<code>07733-3030</code>
<country>USA</country>
</postal>

<phone>+1 732 949 3611</phone>
<facsimile>+1 732 949 3210</facsimile>
<email>murali@bell-labs.com</email>
</address>
</author>

<author fullname="Lawrence Conroy" initials="L." surname="Conroy">
<organization>Roke Manor Research Limited, IT&amp;N-INIA Group</organization>

<address>
<postal>
<street>Roke Manor, Old Salisbury Lane,</street>
<city>Romsey</city>
<region>Hampshire</region>
<code>SO51 0ZN</code>
<country>U.K.</country>
</postal>

<phone>+44 1794 833666</phone>
<facsimile>+44 1794 833434</facsimile>
<email>lwc@roke.co.uk</email>
</address>
</author>

<author fullname="Steve Bellovin" initials="S." surname="Bellovin">
<organization>AT&amp;T Labs</organization>

<address>
<postal>
<street>180 Park Ave., Bldg. 103, Room B135</street>
<city>Florham Park</city>
<region>NJ</region>
<code>07932-0000</code>
<country>USA</country>
</postal>

<phone>+1 973 360 8656</phone>
<facsimile>+1 973 360 8077</facsimile>
<email>smb@research.att.com</email>
</address>
</author>

<author fullname="Fred M. Burg" initials="F.M." surname="Burg">
<organization>AT&amp;T Labs</organization>

<address>
<postal>
<street>Room 1N-117</street>
<street>307 Middletown Lincroft Road</street>
<region>NJ</region>
<code>07738</code>
<country>USA</country>
</postal>

<phone>+1 732 576 4322</phone>
<facsimile>+1 732 576 4317</facsimile>
<email>fburg@hogpb.att.com</email>
</address>
</author>

<author fullname="A. DeSimone" initials="A." surname="DeSimone">
<organization>Lucent Technologies</organization>

<address>
<postal>
<street>Room 6H510</street>
<street>600-700 Mountain Avenue</street>
<street>Murray Hill</street>
<street>NJ  07974-0636</street>
<country>USA</country>
</postal>

<phone>+1 908 582 2382</phone>
<facsimile>+1 908 582 1086</facsimile>
<email>tds@lucent.com</email>
</address>
</author>

<author fullname="Kamlesh T. Tewani" initials="K.T." surname="Tewani">
<organization>AT&amp;T Labs</organization>

<address>
<postal>
<street>Room 1K-334</street>
<street>101, Crawfords Corner Rd.</street>
<street>Holmdel</street>
<street>NJ 07733</street>
<country>USA</country>
</postal>

<phone>+1 732 949 5369</phone>
<facsimile>+1 732 949 8569</facsimile>
<email>tewani@att.com</email>
</address>
</author>

<author fullname="Paul Davidson" initials="P." surname="Davidson">
<organization>Nortel</organization>

<address>
<postal>
<street>P.O.Box 3511 Station &quot;C&quot;</street>
<street>Mail Stop 242</street>
<city>Ottawa</city>
<region>Ontario</region>
<code>K1Y 4H7</code>
<country>Canada</country>
</postal>

<phone>+1 613 763 4234</phone>
<email>pauldav@nortel.ca</email>
</address>
</author>

<author fullname="Henning Schulzrinne" initials="H." surname="Schulzrinne">
<organization>Columbia University, Dept. of Computer Science</organization>

<address>
<postal>
<street />
<street>New York</street>
<street>NY 10027</street>
<country>USA</country>
</postal>

<phone>+1 212 939 7042</phone>
<facsimile>+1 212 666 0140</facsimile>
<email>schulzrinne@cs.columbia.edu</email>
</address>
</author>

<author fullname="Kumar Vishwanathan" initials="K." surname="Vishwanathan">
<organization>Isochrone</organization>

<address>
<email>kumar@isochrone.com</email>
</address>
</author>

<date year="1998" month="November" />
<area>Internet</area>
<keyword>public switched telephone network</keyword>
<keyword>PSTN</keyword>
<keyword>PINT</keyword>

<abstract>
<t>
   This document contains the information relevant to the development of
   the inter-networking interfaces underway in the Public Switched
   Telephone Network (PSTN)/Internet Inter-Networking (PINT) Working
   Group. It addresses technologies, architectures, and several (but by
   no means all) existing pre-PINT implementations of the arrangements
   through which Internet applications can request and enrich PSTN
   telecommunications services. The common denominator of the enriched
   services (a.k.a. PINT services) is that they combine the Internet and
   PSTN services in such a way that the Internet is used for non-voice
   interactions, while the voice (and fax) are carried entirely over the
   PSTN. One key observation is that the pre-PINT implementations, being
   developed independently, do not inter-operate. It is a task of the
   PINT Working Group to define the inter-networking interfaces that
   will support inter-operation of the future implementations of PINT
   services.
</t>
</abstract>
</front>

<seriesInfo value="2458" name="RFC" />
<format octets="155815" type="HTML" target="http://xml.resource.org/public/rfc/html/rfc2458.html" />
<format octets="139820" type="XML" target="http://xml.resource.org/public/rfc/xml/rfc2458.xml" />
</reference>


<reference target2="reference.RFC.2459.xml" anchor="RFC2459">
<front>
<title abbrev="Internet X.509 Public Key Infrastructure">Internet X.509 Public Key Infrastructure Certificate and CRL Profile</title>
<author fullname="Russell Housley" initials="R." surname="Housley">
<organization>SPYRUS</organization>

<address>
<postal>
<street>381 Elden Street</street>
<street>Suite 1120</street>
<city>Herndon</city>
<region>VA</region>
<code>20170</code>
<country>US</country>
</postal>

<email>housley@spyrus.com</email>
</address>
</author>

<author fullname="Warwick Ford" initials="W." surname="Ford">
<organization>VeriSign, Inc.</organization>

<address>
<postal>
<street>One Alewife Center</street>
<city>Cambridge</city>
<region>MA</region>
<code>02140</code>
<country>US</country>
</postal>

<email>wford@verisign.com</email>
</address>
</author>

<author fullname="Tim Polk" initials="T." surname="Polk">
<organization>NIST</organization>

<address>
<postal>
<street />
<city>Gaithersburg</city>
<region>MD</region>
<code>20899</code>
<country>US</country>
</postal>

<email>wpolk@nist.gov</email>
</address>
</author>

<author fullname="David Solo" initials="D." surname="Solo">
<organization>Citicorp</organization>

<address>
<postal>
<street>666 Fifth Ave</street>
<street>3rd Floor</street>
<city>New York</city>
<region>NY</region>
<code>10103</code>
<country>US</country>
</postal>

<email>david.solo@citicorp.com</email>
</address>
</author>

<date year="1999" month="January" />

<abstract>
<t>This memo profiles the X.509 v3 certificate and  X.509 v2 CRL for use in the Internet.  An overview of the approach and model are provided  as an introduction.  The .509 v3 certificate format is described in detail, with additional information regarding the format and semantics of Internet name forms (e.g., IP addresses).  Standard certificate extensions are described and one new Internet-specific extension is defined.  A required set of certificate extensions is specified.  The X.509 v2 CRL format is described and a required extension set is defined as well.  An algorithm for X.509 certificate path validation is described. Supplemental information is provided describing the format of public keys and digital signatures in X.509 certificates for common Internet public key encryption algorithms (i.e., RSA, DSA, and Diffie-Hellman).  ASN.1 modules and examples are provided in the appendices.</t>

<t>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.</t>

<t>Please send comments on this document to the ietf-pkix@imc.org mail list.</t>
</abstract>
</front>

<seriesInfo value="2459" name="RFC" />
</reference>


<reference target2="reference.RFC.2460.xml" anchor="RFC2460">
<front>
<title abbrev="IPv6 Specification">Internet Protocol, Version 6 (IPv6) Specification</title>
<author fullname="Stephen E. Deering" initials="S.E." surname="Deering">
<organization>Cisco Systems, Inc.</organization>

<address>
<postal>
<street>170 West Tasman Drive</street>
<street>San Jose</street>
<region>CA</region>
<code>95134-1706</code>
<country>USA</country>
</postal>

<phone>+1 408 527 8213</phone>
<facsimile>+1 408 527 8254</facsimile>
<email>deering@cisco.com</email>
</address>
</author>

<author fullname="Robert M. Hinden" initials="R.M." surname="Hinden">
<organization>Nokia</organization>

<address>
<postal>
<street>232 Java Drive</street>
<street>Sunnyvale</street>
<region>CA</region>
<code>94089</code>
<country>USA</country>
</postal>

<phone>+1 408 990 2004</phone>
<facsimile>+1 408 743 5677</facsimile>
<email>hinden@iprg.nokia.com</email>
</address>
</author>

<date year="1998" month="December" />
<area>Internet</area>
<keyword>internet protocol version 6</keyword>
<keyword>IPv6</keyword>

<abstract>
<t>
   This document specifies version 6 of the Internet Protocol (IPv6),
   also sometimes referred to as IP Next Generation or IPng.
</t>
</abstract>
</front>

<seriesInfo value="2460" name="RFC" />
<format octets="99496" type="HTML" target="http://xml.resource.org/public/rfc/html/rfc2460.html" />
<format octets="93343" type="XML" target="http://xml.resource.org/public/rfc/xml/rfc2460.xml" />
</reference>


<reference target2="reference.RFC.2461.xml" anchor="RFC2461">
<front>
<title abbrev="Neighbor Discovery for IPv6">Neighbor Discovery for IP Version 6 (IPv6)</title>
<author fullname="Thomas Narten" initials="T." surname="Narten">
<organization>IBM Corporation</organization>

<address>
<postal>
<street>P.O. Box 12195</street>
<street>Research Triangle Park</street>
<region>NC</region>
<code>27709-2195</code>
<country>USA</country>
</postal>

<phone>+1 919 254 7798</phone>
<email>narten@raleigh.ibm.com</email>
</address>
</author>

<author fullname="Erik Nordmark" initials="E." surname="Nordmark">
<organization>Sun Microsystems, Inc.</organization>

<address>
<postal>
<street>901 San Antonio Road</street>
<street>Palo Alto</street>
<region>CA</region>
<code>94303</code>
<country>USA</country>
</postal>

<phone>+1 650 786 5166</phone>
<facsimile>+1 650 786 5896</facsimile>
<email>nordmark@sun.com</email>
</address>
</author>

<author fullname="William Allen Simpson" initials="W.A." surname="Simpson">
<organization>Daydreamer, Computer Systems Consulting Services</organization>

<address>
<postal>
<street>1384 Fontaine</street>
<street>Madison Heights</street>
<region>Michigan</region>
<code>48071</code>
<country>USA</country>
</postal>

<email>bsimpson@MorningStar.com</email>
</address>
</author>

<date year="1998" month="December" />
<area>Routing</area>
<keyword>discovery</keyword>
<keyword>internet protocol version 6</keyword>
<keyword>IPv6</keyword>

<abstract>
<t>
   This document specifies the Neighbor Discovery protocol for IP
   Version 6.  IPv6 nodes on the same link use Neighbor Discovery to
   discover each other&apos;s presence, to determine each other&apos;s link-layer
   addresses, to find routers and to maintain reachability information
   about the paths to active neighbors.
</t>
</abstract>
</front>

<seriesInfo value="2461" name="RFC" />
<format octets="252162" type="HTML" target="http://xml.resource.org/public/rfc/html/rfc2461.html" />
<format octets="239316" type="XML" target="http://xml.resource.org/public/rfc/xml/rfc2461.xml" />
</reference>


<reference target2="reference.RFC.2462.xml" anchor="RFC2462">
<front>
<title>IPv6 Stateless Address Autoconfiguration</title>
<author fullname="Susan Thomson" initials="S." surname="Thomson">
<organization>Bellcore</organization>

<address>
<postal>
<street>445 South Street</street>
<street>Morristown</street>
<region>NJ</region>
<code>07960</code>
<country>USA</country>
</postal>

<phone>+1 201 829 4514</phone>
<email>set@thumper.bellcore.com</email>
</address>
</author>

<author fullname="Thomas Narten" initials="T." surname="Narten">
<organization>IBM Corporation</organization>

<address>
<postal>
<street>P.O. Box 12195</street>
<street>Research Triangle Park</street>
<region>NC</region>
<code>27709-2195</code>
<country>USA</country>
</postal>

<phone>+1 919 254 7798</phone>
<email>narten@raleigh.ibm.com</email>
</address>
</author>

<date year="1998" month="December" />
<area>Internet</area>
<keyword>configuration</keyword>
<keyword>internet protocol version 6</keyword>

<abstract>
<t>
   This document specifies the steps a host takes in deciding how to
   autoconfigure its interfaces in IP version 6. The autoconfiguration
   process includes creating a link-local address and verifying its
   uniqueness on a link, determining what information should be
   autoconfigured (addresses, other information, or both), and in the
   case of addresses, whether they should be obtained through the
   stateless mechanism, the stateful mechanism, or both.  This document
   defines the process for generating a link-local address, the process
   for generating site-local and global addresses via stateless address
   autoconfiguration, and the Duplicate Address Detection procedure. The
   details of autoconfiguration using the stateful protocol are
   specified elsewhere.
</t>
</abstract>
</front>

<seriesInfo value="2462" name="RFC" />
<format octets="76182" type="HTML" target="http://xml.resource.org/public/rfc/html/rfc2462.html" />
<format octets="65932" type="XML" target="http://xml.resource.org/public/rfc/xml/rfc2462.xml" />
</reference>


<reference target2="reference.RFC.2463.xml" anchor="RFC2463">
<front>
<title abbrev="ICMPv6 (ICMP for IPv6)">Internet Control Message Protocol (ICMPv6) for the Internet Protocol Version 6 (IPv6) Specification</title>
<author fullname="Alex Conta" initials="A." surname="Conta">
<organization>Lucent Technologies Inc.</organization>

<address>
<postal>
<street>300 Baker Ave</street>
<street>Suite 100</street>
<city>Concord</city>
<region>MA</region>
<code>01742</code>
<country>USA</country>
</postal>

<phone>+1 978 287 2842</phone>
<email>aconta@lucent.com</email>
</address>
</author>

<author fullname="Stephen Deering" initials="S." surname="Deering">
<organization>Cisco Systems, Inc.</organization>

<address>
<postal>
<street>170 West Tasman Drive</street>
<city>San Jose</city>
<region>CA</region>
<code>95134-1706</code>
<country>USA</country>
</postal>

<phone>+1 408 527 8213</phone>
<email>deering@cisco.com</email>
</address>
</author>

<date year="1998" month="December" />
<area>Internet</area>
<keyword>internet control message protocol</keyword>
<keyword>internet protocol version 6</keyword>
<keyword>ICMP</keyword>
<keyword>IPv6</keyword>

<abstract>
<t>
   This document specifies a set of Internet Control Message Protocol
   (ICMP) messages for use with version 6 of the Internet Protocol
   (IPv6).
</t>
</abstract>
</front>

<seriesInfo value="2463" name="RFC" />
<format octets="48498" type="HTML" target="http://xml.resource.org/public/rfc/html/rfc2463.html" />
<format octets="44229" type="XML" target="http://xml.resource.org/public/rfc/xml/rfc2463.xml" />
</reference>


<reference target2="reference.RFC.2464.xml" anchor="RFC2464">
<front>
<title abbrev="IPv6 Packets over Ethernet">Transmission of IPv6 Packets over Ethernet Networks</title>
<author fullname="Matt Crawford" initials="M." surname="Crawford">
<organization>Fermilab</organization>

<address>
<postal>
<street>PO Box 500, MS 368</street>
<city>Batavia</city>
<region>IL</region>
<code>60510</code>
<country>USA</country>
</postal>

<phone>+1 630 840 3461</phone>
<email>crawdad@fnal.gov</email>
</address>
</author>

<date year="1998" month="December" />
<area>Internet</area>
<keyword>ethernet</keyword>
<keyword>internet protocol version 6</keyword>
<keyword>IPv6</keyword>
</front>

<seriesInfo value="2464" name="RFC" />
<format octets="27842" type="HTML" target="http://xml.resource.org/public/rfc/html/rfc2464.html" />
<format octets="21572" type="XML" target="http://xml.resource.org/public/rfc/xml/rfc2464.xml" />
</reference>


<reference target2="reference.RFC.2465.xml" anchor="RFC2465">
<front>
<title abbrev="IPv6 MIB">Management Information Base for IP Version 6: Textual Conventions and General Group</title>
<author fullname="Dimitry Haskin" initials="D." surname="Haskin">
<organization>Bay Networks, Inc.</organization>

<address>
<postal>
<street>600 Technology Park Drive</street>
<street>Billerica</street>
<street>MA 01821</street>
</postal>

<email>dhaskin@baynetworks.com</email>
</address>
</author>

<author fullname="Steve Onishi" initials="S." surname="Onishi">
<organization>Bay Networks, Inc.</organization>

<address>
<postal>
<street>3 Federal Street</street>
<street>Billerica</street>
<street>MA 01821</street>
</postal>

<email>sonishi@baynetworks.com</email>
</address>
</author>

<date year="1998" month="December" />
<area>Internet</area>
<area>Management</area>
<keyword>Management Information Base</keyword>
<keyword>internet protocol version 6</keyword>

<abstract>
<t>
   This document is one in the series of documents that provide MIB
   definitions for for IP Version 6.  Specifically, the IPv6 MIB textual
   conventions as well as the IPv6 MIB General group is defined in this
   document.
</t>

<t>
   This memo defines a portion of the Management Information Base (MIB)
   for use with network management protocols in the IPv6-based
   internets.
</t>

<t>
   This document specifies a MIB module in a manner that is both
   compliant to the SNMPv2 SMI, and semantically identical to the peer
   SNMPv1 definitions.
</t>
</abstract>
</front>

<seriesInfo value="2465" name="RFC" />
<format octets="88969" type="HTML" target="http://xml.resource.org/public/rfc/html/rfc2465.html" />
<format octets="86013" type="XML" target="http://xml.resource.org/public/rfc/xml/rfc2465.xml" />
</reference>


<reference target2="reference.RFC.2466.xml" anchor="RFC2466">
<front>
<title abbrev="IPv6 MIB: ICMPv6 Group">Management Information Base for IP Version 6: ICMPv6 Group</title>
<author fullname="Dimitry Haskin" initials="D." surname="Haskin">
<organization>Bay Networks, Inc.</organization>

<address>
<postal>
<street>600 Technology Park Drive</street>
<city>Billerica</city>
<region>MA</region>
<code>01821</code>
<country>USA</country>
</postal>

<email>dhaskin@baynetworks.com</email>
</address>
</author>

<author fullname="Steve Onishi" initials="S." surname="Onishi">
<organization>Bay Networks, Inc.</organization>

<address>
<postal>
<street>3 Federal Street</street>
<city>Billerica</city>
<region>MA</region>
<code>01821</code>
<country>USA</country>
</postal>

<email>sonishi@baynetworks.com</email>
</address>
</author>

<date year="1998" month="December" />
<area>Management</area>
<area>Internet</area>
<keyword>Management Information Base</keyword>
<keyword>internet protocol version 6</keyword>
<keyword>ICMPv6</keyword>

<abstract>
<t>
   This document is one in the series of documents that define various
   MIB object groups for IPv6.  Specifically, the ICMPv6 group is
   defined in this document.
</t>

<t>
   This memo defines a portion of the Management Information Base (MIB)
   for use with network management protocols in the IPv6-based
   internets.
</t>

<t>
   This document specifies a MIB module in a manner that is both
   compliant to the SNMPv2 SMI, and semantically identical to the peer
   SNMPv1 definitions.
</t>
</abstract>
</front>

<seriesInfo value="2466" name="RFC" />
<format octets="40578" type="HTML" target="http://xml.resource.org/public/rfc/html/rfc2466.html" />
<format octets="37868" type="XML" target="http://xml.resource.org/public/rfc/xml/rfc2466.xml" />
</reference>


<reference target2="reference.RFC.2467.xml" anchor="RFC2467">
<front>
<title abbrev="IPv6 over FDDI">Transmission of IPv6 Packets over FDDI Networks</title>
<author fullname="Matt Crawford" initials="M." surname="Crawford">
<organization>Fermilab</organization>

<address>
<postal>
<street>PO Box 500,  MS 368</street>
<city>Batavia</city>
<region>IL</region>
<code>60510</code>
<country>USA</country>
</postal>

<phone>+1 630 840 3461</phone>
<email>crawdad@fnal.gov</email>
</address>
</author>

<date year="1998" month="December" />
<area>Internet</area>
<keyword>Fiber Distributed Data Interface</keyword>
<keyword>FDDI</keyword>
<keyword>internet protocol version 6</keyword>
</front>

<seriesInfo value="2467" name="RFC" />
<format octets="32872" type="HTML" target="http://xml.resource.org/public/rfc/html/rfc2467.html" />
<format octets="30653" type="XML" target="http://xml.resource.org/public/rfc/xml/rfc2467.xml" />
</reference>


<reference target2="reference.RFC.2468.xml" anchor="RFC2468">
<front>
<title abbrev="I REMEMBER IANA">I REMEMBER IANA October 17, 1998</title>
<author fullname="Vinton G. Cerf" initials="V.G." surname="Cerf">
<organization>MCI</organization>

<address>
<email>vcerf@mci.net</email>
</address>
</author>

<date year="1998" month="October" />
<area>General</area>
<keyword>Internet Assigned Numbers Authority</keyword>
</front>

<seriesInfo value="2468" name="RFC" />
<format octets="14077" type="HTML" target="http://xml.resource.org/public/rfc/html/rfc2468.html" />
<format octets="6887" type="XML" target="http://xml.resource.org/public/rfc/xml/rfc2468.xml" />
</reference>


<reference target2="reference.RFC.2469.xml" anchor="RFC2469">
<front>
<title abbrev="Canonical Ordering Of Link-Layer Addresses">A Caution On The Canonical Ordering Of Link-Layer Addresses</title>
<author fullname="Thomas Narten" initials="T." surname="Narten">
<organization>IBM Corporation</organization>

<address>
<postal>
<street>3039 Cornwallis Ave.</street>
<street>PO Box 12195</street>
<city>Research Triangle Park</city>
<region>NC</region>
<code>27709-2195</code>
<country>USA</country>
</postal>

<phone>+1 919 254 7798</phone>
<email>narten@raleigh.ibm.com</email>
</address>
</author>

<author fullname="Charles F. Burton, III" initials="C.F." surname="Burton">
<organization>IBM Corporation</organization>

<address>
<postal>
<street>3039 Cornwallis Ave.</street>
<street>PO Box 12195</street>
<city>Research Triangle Park</city>
<region>NC</region>
<code>27709-2195</code>
<country>USA</country>
</postal>

<phone>+1 919 254 4355</phone>
<email>burton@rtp.vnet.ibm.com</email>
</address>
</author>

<date year="1998" month="December" />
<area>Internet</area>
<keyword>ARP</keyword>
<keyword>Neighbor Discovery</keyword>

<abstract>
<t>
   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 &quot;canonical form&quot;.  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.
</t>
</abstract>
</front>

<seriesInfo value="2469" name="RFC" />
<format octets="21646" type="HTML" target="http://xml.resource.org/public/rfc/html/rfc2469.html" />
<format octets="16672" type="XML" target="http://xml.resource.org/public/rfc/xml/rfc2469.xml" />
</reference>


<reference target2="reference.RFC.2470.xml" anchor="RFC2470">
<front>
<title abbrev="IPv6 over Token Ring">Transmission of IPv6 Packets over Token Ring Networks</title>
<author fullname="Matt Crawford" initials="M." surname="Crawford">
<organization>Fermilab</organization>

<address>
<postal>
<street>PO Box 500, MS 368</street>
<city>Batavia</city>
<region>IL</region>
<code>60510</code>
<country>USA</country>
</postal>

<phone>+1 630 840 3461</phone>
<email>crawdad@fnal.gov</email>
</address>
</author>

<author fullname="Thomas Narten" initials="T." surname="Narten">
<organization>IBM Corporation</organization>

<address>
<postal>
<street>P.O. Box 12195</street>
<city>Research Triangle Park</city>
<region>NC</region>
<code>27709-2195</code>
<country>USA</country>
</postal>

<phone>+1 919 254 7798</phone>
<email>narten@raleigh.ibm.com</email>
</address>
</author>

<author fullname="Stephen Thomas" initials="S." surname="Thomas">
<organization>TransNexus</organization>

<address>
<postal>
<street>430 Tenth Street NW Suite N204</street>
<city>Atlanta</city>
<region>GA</region>
<code>30318</code>
<country>USA</country>
</postal>

<phone>+1 404 872 4745</phone>
<email>stephen.thomas@transnexus.com</email>
</address>
</author>

<date year="1998" month="December" />
<area>Internet</area>
<keyword>internet protocol version 6</keyword>
<keyword>IPv6</keyword>
<keyword>token ring</keyword>
</front>

<seriesInfo value="2470" name="RFC" />
<format octets="38100" type="HTML" target="http://xml.resource.org/public/rfc/html/rfc2470.html" />
<format octets="34359" type="XML" target="http://xml.resource.org/public/rfc/xml/rfc2470.xml" />
</reference>


<reference target2="reference.RFC.2471.xml" anchor="RFC2471">
<front>
<title>IPv6 Testing Address Allocation</title>
<author fullname="Robert M. Hinden" initials="R.M." surname="Hinden">
<organization>Nokia</organization>

<address>
<postal>
<street>232 Java Drive</street>
<city>Sunnyvale</city>
<region>CA</region>
<code>94089</code>
<country>USA</country>
</postal>

<phone>+1 408 990-2004</phone>
<email>hinden@iprg.nokia.com</email>
</address>
</author>

<author fullname="Robert Fink" initials="R." surname="Fink">
<organization>Lawrence Berkeley National Laboratory</organization>

<address>
<postal>
<street>MS 50A-3111</street>
<city>Berkeley</city>
<region>CA</region>
<code>94720</code>
<country>USA</country>
</postal>

<phone>+1 510 486-5692</phone>
<email>rlfink@lbl.gov</email>
</address>
</author>

<author fullname="Jon Postel" initials="J." surname="Postel">
<organization>Information Sciences Institute</organization>

<address>
<postal>
<street>4676 Admiralty Way</street>
<city>Marina del Rey</city>
<region>CA</region>
<code>90292-6695</code>
<country>USA</country>
</postal>

</address>
</author>

<date year="1998" month="December" />
<area>Internet</area>
<keyword>IP address</keyword>
<keyword>internet protocol version 6</keyword>
<keyword>IPv6</keyword>
</front>

<seriesInfo value="2471" name="RFC" />
<format octets="21428" type="HTML" target="http://xml.resource.org/public/rfc/html/rfc2471.html" />
<format octets="16337" type="XML" target="http://xml.resource.org/public/rfc/xml/rfc2471.xml" />
</reference>


<reference target2="reference.RFC.2472.xml" anchor="RFC2472">
<front>
<title abbrev="IPv6 over PPP">IP Version 6 over PPP</title>
<author fullname="Dimitry Haskin" initials="D." surname="Haskin">
<organization>Bay Networks, Inc.</organization>

<address>
<postal>
<street>600 Technology Park</street>
<city>Billerica</city>
<region>MA</region>
<code>01821</code>
<country>USA</country>
</postal>

<email>dhaskin@baynetworks.com</email>
</address>
</author>

<author fullname="Ed Allen" initials="E." surname="Allen">
<organization>Bay Networks, Inc.</organization>

<address>
<postal>
<street>600 Technology Park</street>
<city>Billerica</city>
<region>MA</region>
<code>01821</code>
<country>USA</country>
</postal>

<email>eallen@baynetworks.com</email>
</address>
</author>

<date year="1998" month="December" />
<area>Internet</area>
<keyword>internet protocol version 6</keyword>
<keyword>IPv6</keyword>
<keyword>PPP</keyword>
<keyword>point-to-point protocol</keyword>

<abstract>
<t>
   The Point-to-Point Protocol (PPP)  provides a standard method of
   encapsulating Network Layer protocol information over point-to-point
   links.  PPP also defines an extensible Link Control Protocol, and
   proposes a family of Network Control Protocols (NCPs) for
   establishing and configuring different network-layer protocols.
</t>

<t>
   This document defines the method for transmission of IP Version 6 
   packets over PPP links as well as the Network Control Protocol (NCP)
   for establishing and configuring the IPv6 over PPP. It also specifies
   the method of forming IPv6 link-local addresses on PPP links.
</t>
</abstract>
</front>

<seriesInfo value="2472" name="RFC" />
<format octets="46102" type="HTML" target="http://xml.resource.org/public/rfc/html/rfc2472.html" />
<format octets="40559" type="XML" target="http://xml.resource.org/public/rfc/xml/rfc2472.xml" />
</reference>


<reference target2="reference.RFC.2473.xml" anchor="RFC2473">
<front>
<title abbrev="Generic Packet Tunneling in IPv6">Generic Packet Tunneling in IPv6 Specification</title>
<author fullname="Alex Conta" initials="A." surname="Conta">
<organization>Lucent Technologies Inc.</organization>

<address>
<postal>
<street>300 Baker Ave</street>
<city>Concord</city>
<region>MA</region>
<code>01742-2168</code>
<country>USA</country>
</postal>

<phone>+1 978 287 2842</phone>
<email>aconta@lucent.com</email>
</address>
</author>

<author fullname="Stephen Deering" initials="S." surname="Deering">
<organization>Cisco Systems</organization>

<address>
<postal>
<street>170 West Tasman Dr</street>
<city>San Jose</city>
<region>CA</region>
<code>95132-1706</code>
<country>USA</country>
</postal>

<phone>+1-408-527-8213</phone>
<email>deering@cisco.com</email>
</address>
</author>

<date year="1998" month="December" />
<area>Internet</area>
<keyword>encapsulate</keyword>
<keyword>internet protocol version 6</keyword>
<keyword>IPv6</keyword>
<keyword>tunnel</keyword>

<abstract>
<t>
   This document defines the model and generic mechanisms for IPv6
   encapsulation of Internet packets, such as IPv6 and IPv4.  The model
   and mechanisms can be applied to other protocol packets as well, such
   as AppleTalk, IPX, CLNP, or others.
</t>
</abstract>
</front>

<seriesInfo value="2473" name="RFC" />
<format octets="93015" type="HTML" target="http://xml.resource.org/public/rfc/html/rfc2473.html" />
<format octets="84253" type="XML" target="http://xml.resource.org/public/rfc/xml/rfc2473.xml" />
</reference>


<reference target2="reference.RFC.2474.xml" anchor="RFC2474">
<front>
<title abbrev="Differentiated Services Field">Definition of the Differentiated Services Field (DS Field) in the IPv4 and IPv6 Headers</title>
<author fullname="Kathleen Nichols" initials="K." surname="Nichols">
<organization>Cisco Systems</organization>

<address>
<postal>
<street>170 West Tasman Drive</street>
<city>San Jose</city>
<region>CA</region>
<code>95134-1706</code>
<country>USA</country>
</postal>

<phone>+1 408 525 4857</phone>
<email>kmn@cisco.com</email>
</address>
</author>

<author fullname="Steven Blake" initials="S." surname="Blake">
<organization>Torrent Networking Technologies</organization>

<address>
<postal>
<street>3000 Aerial Center</street>
<city>Morrisville</city>
<region>NC</region>
<code>27560</code>
<country>USA</country>
</postal>

<phone>+1 919 468 8466 x232</phone>
<email>slblake@torrentnet.com</email>
</address>
</author>

<author fullname="Fred Baker" initials="F." surname="Baker">
<organization>Cisco Systems</organization>

<address>
<postal>
<street>519 Lado Drive</street>
<city> Santa Barbara</city>
<region>CA</region>
<code>93111</code>
<country>USA</country>
</postal>

<phone>+1 408 526 4257</phone>
<email>fred@cisco.com</email>
</address>
</author>

<author fullname="David L. Black" initials="D.L." surname="Black">
<organization>EMC Corporation</organization>

<address>
<postal>
<street>35 Parkwood Drive</street>
<city>Hopkinton</city>
<region>MA</region>
<code>01748</code>
<country>USA</country>
</postal>

<phone>+1 508 435 1000 x76140</phone>
<email>black_david@emc.com</email>
</address>
</author>

<date year="1998" month="December" />
<area>Internet</area>
<keyword>internet protocol version 4</keyword>
<keyword>IPv6</keyword>
<keyword>IPv4</keyword>
<keyword>internet protocol version 6</keyword>
<keyword>type of service</keyword>

<abstract>
<t>
   Differentiated services enhancements to the Internet protocol are
   intended to enable scalable service discrimination in the Internet
   without the need for per-flow state and signaling at every hop.  A
   variety of services may be built from a small, well-defined set of
   building blocks which are deployed in network nodes.  The services
   may be either end-to-end or intra-domain; they include both those
   that can satisfy quantitative performance requirements (e.g., peak
   bandwidth) and those based on relative performance (e.g., &quot;class&quot;
   differentiation).  Services can be constructed by a combination of:

<list>
<t>
   - setting bits in an IP header field at network boundaries
     (autonomous system boundaries, internal administrative boundaries,
     or hosts),
</t>

<t>
   - using those bits to determine how packets are forwarded by the
     nodes inside the network, and
</t>

<t>
   - conditioning the marked packets at network boundaries in accordance
     with the requirements or rules of each service.
</t>
</list>
</t>

<t>
   The requirements or rules of each service must be set through
   administrative policy mechanisms which are outside the scope of this
   document.  A differentiated services-compliant network node includes
   a classifier that selects packets based on the value of the DS field,
   along with buffer management and packet scheduling mechanisms capable
   of delivering the specific packet forwarding treatment indicated by
   the DS field value.  Setting of the DS field and conditioning of the
   temporal behavior of marked packets need only be performed at network
   boundaries and may vary in complexity.
</t>

<t>
   This document defines the IP header field, called the DS (for
   differentiated services) field.  In IPv4, it defines the layout of
   the TOS octet; in IPv6, the Traffic Class octet.  In addition, a base
   set of packet forwarding treatments, or per-hop behaviors, is
   defined.
</t>

<t>
   For a more complete understanding of differentiated services, see
   also the differentiated services architecture .
</t>
</abstract>
</front>

<seriesInfo value="2474" name="RFC" />
<format octets="67719" type="HTML" target="http://xml.resource.org/public/rfc/html/rfc2474.html" />
<format octets="62259" type="XML" target="http://xml.resource.org/public/rfc/xml/rfc2474.xml" />
</reference>


<reference target2="reference.RFC.2475.xml" anchor="RFC2475">
<front>
<title abbrev="Architecture for Differentiated Services">An Architecture for Differentiated Services</title>
<author fullname="Steven Blake" initials="S." surname="Blake">
<organization>Torrent Networking Technologies</organization>

<address>
<postal>
<street>3000 Aerial Center, Suite 140</street>
<city>Morrisville</city>
<region>NC</region>
<code>27560</code>
<country>USA</country>
</postal>

<phone>+1 919 468 8466 x232 </phone>
<email>slblake@torrentnet.com</email>
</address>
</author>

<author fullname="David L. Black" initials="D.L." surname="Black">
<organization>EMC Corporation</organization>

<address>
<postal>
<street>35 Parkwood Drive</street>
<city>Hopkinton</city>
<region>MA</region>
<code>01748</code>
<country>USA</country>
</postal>

<phone>+1 508 435 1000 x76140 </phone>
<email>black_david@emc.com</email>
</address>
</author>

<author fullname="Mark A. Carlson" initials="M.A." surname="Carlson">
<organization>Sun Microsystems, Inc.</organization>

<address>
<postal>
<street>2990 Center Green Court South</street>
<city>Boulder</city>
<region>CO</region>
<code>80301</code>
<country>USA</country>
</postal>

<phone>+1 303 448 0048 x115</phone>
<email>mark.carlson@sun.com</email>
</address>
</author>

<author fullname="Elwyn Davies" initials="E." surname="Davies">
<organization>Nortel UK</organization>

<address>
<postal>
<street>London Road</street>
<street>Harlow, Essex  CM17 9NA</street>
<country>UK</country>
</postal>

<phone>+44 1279 405498</phone>
<email>elwynd@nortel.co.uk</email>
</address>
</author>

<author fullname="Zheng Wang" initials="Z." surname="Wang">
<organization>Bell Labs Lucent Technologies</organization>

<address>
<postal>
<street>101 Crawfords Corner Road</street>
<city>Holmdel</city>
<region>NJ</region>
<code>07733</code>
<country>USA</country>
</postal>

<email>zhwang@bell-labs.com</email>
</address>
</author>

<author fullname="Walter Weiss" initials="W." surname="Weiss">
<organization>Lucent Technologies</organization>

<address>
<postal>
<street>300 Baker Avenue, Suite 100</street>
<city>Concord</city>
<region>MA</region>
<code>01742-2168</code>
<country>USA</country>
</postal>

<email>wweiss@lucent.com</email>
</address>
</author>

<date year="1998" month="December" />
<area>Internet</area>
<keyword>type of service</keyword>

<abstract>
<t>
   This document defines an architecture for implementing scalable
   service differentiation in the Internet.  This architecture achieves
   scalability by aggregating traffic classification state which is
   conveyed by means of IP-layer packet marking using the DS field
   .  Packets are classified and marked to receive a particular
   per-hop forwarding behavior on nodes along their path.  Sophisticated
   classification, marking, policing, and shaping operations need only
   be implemented at network boundaries or hosts.  Network resources are
   allocated to traffic streams by service provisioning policies which
   govern how traffic is marked and conditioned upon entry to a
   differentiated services-capable network, and how that traffic is
   forwarded within that network.  A wide variety of services can be
   implemented on top of these building blocks.
</t>
</abstract>
</front>

<seriesInfo value="2475" name="RFC" />
<format octets="111685" type="HTML" target="http://xml.resource.org/public/rfc/html/rfc2475.html" />
<format octets="107423" type="XML" target="http://xml.resource.org/public/rfc/xml/rfc2475.xml" />
</reference>


<reference target2="reference.RFC.2476.xml" anchor="RFC2476">
<front>
<title>Message Submission</title>
<author fullname="Randall Gellens" initials="R." surname="Gellens">
<organization>QUALCOMM Incorporated</organization>

<address>
<postal>
<street>6455 Lusk Blvd.</street>
<city>San Diego</city>
<region>CA</region>
<code>92121-2779</code>
<country>USA</country>
</postal>

<phone>+1 619 651 5115</phone>
<facsimile>+1 619 651 5334</facsimile>
<email>Randy@Qualcomm.Com</email>
</address>
</author>

<author fullname="John C. Klensin" initials="J.C." surname="Klensin">
<organization>MCI Telecommunications</organization>

<address>
<postal>
<street>800 Boylston St, 7th floor</street>
<city>Boston</city>
<region>MA</region>
<code>02199</code>
<country>USA</country>
</postal>

<phone>+1 617 960 1011</phone>
<email>klensin@mci.net</email>
</address>
</author>

<date year="1998" month="December" />
<area>Applications</area>
<keyword>SMTP</keyword>
</front>

<seriesInfo value="2476" name="RFC" />
<format octets="47918" type="HTML" target="http://xml.resource.org/public/rfc/html/rfc2476.html" />
<format octets="50997" type="XML" target="http://xml.resource.org/public/rfc/xml/rfc2476.xml" />
</reference>


<reference target2="reference.RFC.2477.xml" anchor="RFC2477">
<front>
<title abbrev="Evaluating Roaming Protocols">Criteria for Evaluating Roaming Protocols</title>
<author fullname="Bernard Aboba" initials="B." surname="Aboba">
<organization>Microsoft Corporation</organization>

<address>
<postal>
<street>One Microsoft Way</street>
<city>Redmond</city>
<region>WA</region>
<code>98052</code>
<country>US</country>
</postal>

<phone>+1 425 936 6605</phone>
<email>bernarda@microsoft.com</email>
</address>
</author>

<author fullname="Glen Zorn" initials="G." surname="Zorn">
<organization>Microsoft Corporation</organization>

<address>
<postal>
<street>One Microsoft Way</street>
<city>Redmond</city>
<region>WA</region>
<code>98052</code>
<country>US</country>
</postal>

<phone>+1 425 703 1559</phone>
<email>glennz@microsoft.com</email>
</address>
</author>

<date year="1999" month="January" />

<abstract>
<t>This document describes requirements for the provisioning of "roaming capability" for dialup Internet users.  "Roaming  capability" is defined as the ability to use multiple Internet service providers (ISPs), while maintaining a formal, customer-vendor relationship  with only one.</t>
</abstract>
</front>

<seriesInfo value="2477" name="RFC" />
</reference>


<reference target2="reference.RFC.2478.xml" anchor="RFC2478">
<front>
<title abbrev="GSS-API Negotiation Mechanism">The Simple and Protected GSS-API Negotiation Mechanism</title>
<author fullname="Eric Baize" initials="E." surname="Baize">
<organization>Bull - 300 Concord Road</organization>

<address>
<phone>+1 978 294 61 37</phone>
<facsimile>+1 978 294 61 09</facsimile>
<email>Eric.Baize@bull.com</email>
</address>
</author>

<author fullname="Denis Pinkas" initials="D." surname="Pinkas">
<organization>Bull</organization>

<address>
<postal>
<street>Rue Jean-Jaures</street>
<street>BP 68</street>
<street>78340 Les Clayes-sous-Bois - FRANCE</street>
</postal>

<phone>+33 1 30 80 34 87</phone>
<facsimile>+33 1 30 80 33 21</facsimile>
<email>Denis.Pinkas@bull.net</email>
</address>
</author>

<date year="1998" month="December" />
<keyword>application program interface</keyword>
<keyword>generic security service</keyword>
<keyword>security</keyword>
</front>

<seriesInfo value="2478" name="RFC" />
<format octets="43124" type="HTML" target="http://xml.resource.org/public/rfc/html/rfc2478.html" />
<format octets="32707" type="XML" target="http://xml.resource.org/public/rfc/xml/rfc2478.xml" />
</reference>


<reference target2="reference.RFC.2479.xml" anchor="RFC2479">
<front>
<title abbrev="IDUP-GSS-API">Independent Data Unit Protection Generic Security Service Application Program Interface (IDUP-GSS-API)</title>
<author fullname="Carlisle Adams" initials="C." surname="Adams">
<organization>Entrust Technologies</organization>

<address>
<postal>
<street>750 Heron Road</street>
<street>Suite E08</street>
<city>Ottawa</city>
<region>Ontario</region>
<code>K1V 1A7</code>
<country>CANADA</country>
</postal>

<phone>+1 613 247 3180</phone>
<email>cadams@entrust.com</email>
</address>
</author>

<date year="1998" month="December" />
<area>Security</area>
<keyword>application program interface</keyword>
<keyword>generic security service</keyword>
<keyword>independent data unit protection</keyword>
<keyword>security</keyword>

<abstract>
<t>
   The IDUP-GSS-API extends the GSS-API  for applications
   requiring protection of a generic data unit (such as a file or
   message) in a way which is independent of the protection of any other
   data unit and independent of any concurrent contact with designated
   &quot;receivers&quot; of the data unit.  Thus, it is suitable for applications
   such as secure electronic mail where data needs to be protected
   without any on-line connection with the intended recipient(s) of that
   data.  The protection offered by IDUP includes services such as data
   origin authentication with data integrity, data confidentiality with
   data integrity, and support for non-repudiation services.  Subsequent
   to being protected, the data unit can be transferred to the
   recipient(s) - or to an archive - perhaps to be processed
   (&quot;unprotected&quot;) only days or years later.
</t>

<t>
   Throughout the remainder of this document, the &quot;unit&quot; of data
   described in the above paragraph will be referred to as an IDU
   (Independent Data Unit).  The IDU can be of any size (the application
   may, if it wishes, split the IDU into pieces and have the protection
   computed a piece at a time, but the resulting protection token
   applies to the entire IDU).  However, the primary characteristic of
   an IDU is that it represents a stand-alone unit of data whose
   protection is entirely independent of any other unit of data.  If an
   application protects several IDUs and sends them all to a single
   receiver, the IDUs may be unprotected by that receiver in any order
   over any time span; no logical connection of any kind is implied by
   the protection process itself.
</t>

<t>
   As with RFC-2078, this IDUP-GSS-API definition 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 IDUP-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:

<list>
<t>
      - documents defining specific parameter bindings for particular
        language environments;
      - documents defining token formats, protocols, and procedures to
        be implemented in order to realize IDUP-GSS-API services atop
        particular security mechanisms.
</t>
</list>
</t>
</abstract>
</front>

<seriesInfo value="2479" name="RFC" />
<format octets="168591" type="HTML" target="http://xml.resource.org/public/rfc/html/rfc2479.html" />
<format octets="156830" type="XML" target="http://xml.resource.org/public/rfc/xml/rfc2479.xml" />
</reference>


<reference target2="reference.RFC.2480.xml" anchor="RFC2480">
<front>
<title>Gateways and MIME Security Multiparts</title>
<author fullname="Ned Freed" initials="N." surname="Freed">
<organization>Innosoft International, Inc.</organization>

<address>
<postal>
<street>1050 Lakes Drive</street>
<city>West Covina</city>
<region>CA</region>
<code>91790</code>
<country>USA</country>
</postal>

<phone>+1 626 919 3600</phone>
<facsimile>+1 626 919 3614</facsimile>
<email>ned.freed@innosoft.com</email>
</address>
</author>

<date year="1999" month="January" />
<area>Applications</area>
<keyword>MIME</keyword>
<keyword>mail gateway</keyword>
<keyword>multipurpose internet mail extensions</keyword>
<keyword>security</keyword>
</front>

<seriesInfo value="2480" name="RFC" />
<format octets="23923" type="HTML" target="http://xml.resource.org/public/rfc/html/rfc2480.html" />
<format octets="23761" type="XML" target="http://xml.resource.org/public/rfc/xml/rfc2480.xml" />
</reference>


<reference target2="reference.RFC.2481.xml" anchor="RFC2481">
<front>
<title abbrev="ECN to IP">A Proposal to add Explicit Congestion Notification (ECN) to IP</title>
<author fullname="K. K. Ramakrishnan" initials="K.K." surname="Ramakrishnan">
<organization>AT&amp;T Labs. Research</organization>

<address>
<phone>+1 973 360 8766 </phone>
<email>kkrama@research.att.com</email>
<uri>http://www.research.att.com/info/kkrama</uri>
</address>
</author>

<author fullname="Sally Floyd" initials="S." surname="Floyd">
<organization>Lawrence Berkeley National Laboratory</organization>

<address>
<phone>+1 510 486 7518</phone>
<email>floyd@ee.lbl.gov</email>
<uri>http://www-nrg.ee.lbl.gov/floyd/</uri>
</address>
</author>

<date year="1999" month="January" />
<area>Internet</area>
<keyword>congestion</keyword>
<keyword>multicast</keyword>

<abstract>
<t>
   This note describes a proposed addition of ECN (Explicit Congestion
   Notification) to IP.  TCP is currently the dominant transport
   protocol used in the Internet. We begin by describing TCP&apos;s use of
   packet drops as an indication of congestion.  Next we argue that with
   the addition of active queue management (e.g., RED) to the Internet
   infrastructure, where routers detect congestion before the queue
   overflows, routers are no longer limited to packet drops as an
   indication of congestion.  Routers could instead set a Congestion
   Experienced (CE) bit in the packet header of packets from ECN-capable
   transport protocols.  We describe when the CE bit would be set in the
   routers, and describe what modifications would be needed to TCP to
   make it ECN-capable.  Modifications to other transport protocols
   (e.g., unreliable unicast or multicast, reliable multicast, other
   reliable unicast transport protocols) could be considered as those
   protocols are developed and advance through the standards process.
</t>
</abstract>
</front>

<seriesInfo value="2481" name="RFC" />
<format octets="93408" type="HTML" target="http://xml.resource.org/public/rfc/html/rfc2481.html" />
<format octets="94938" type="XML" target="http://xml.resource.org/public/rfc/xml/rfc2481.xml" />
</reference>


<reference target2="reference.RFC.2482.xml" anchor="RFC2482">
<front>
<title>Language Tagging in Unicode Plain Text</title>
<author fullname="Ken Whistler" initials="K." surname="Whistler">
<organization>Sybase, Inc.</organization>

<address>
<postal>
<street>6475 Christie Ave</street>
<city>Emeryville</city>
<region>CA</region>
<code>94608-1050</code>
<country>US</country>
</postal>

<phone>+1 510 922 3611</phone>
<email>kenw@sybase.com</email>
</address>
</author>

<author fullname="Glenn Adams" initials="G." surname="Adams">
<organization>Spyglass, Inc.</organization>

<address>
<postal>
<street>One Cambridge Center</street>
<city>Cambridge</city>
<region>MA</region>
<code>02142</code>
<country>US</country>
</postal>

<phone>+1 617 679 4652</phone>
<email>glenn@spyglass.com</email>
</address>
</author>

<date year="1999" month="January" />

<abstract>
<t>This document proposed a mechanism for language tagging inplain text. A set of special-use tag characters on Plane 14 of(accessible through UTF-8, UTF-16, and UCS-4 encoding forms) are proposed for encoding to enable the spelling out of ASCII-based string tags using characters which can be strictly separated from ordinary text content characters in ISO10646 (or UNICODE).</t>

<t>One tag identification character and one cancel tag character are also proposed. In particular, a language tag identification character is proposed to identify a language tag string specifically; the language tag itself makes use oflanguage tag strings spelled out using the Plane 14 tag characters. Provision of a specific, low-overhead mechanism for embedding language tags in plain text is aimed at meeting the need of Internet Protocols such as ACAP,  which require a standard mechanism for marking language in UTF-8 strings.</t>

<t>The tagging mechanism as well the characters proposed in this document have been approved by the Unicode Consortium for inclusion in The Unicode Standard.  However, implementation of this decision awaits formal acceptance by ISO JTC1/SC2/WG2, the working group responsible for ISO10646. Potential implementers should be aware that until this formal acceptance occurs, any usage of the characters proposed herein is strictly experimental and not sanctioned for standardized character data interchange.</t>
</abstract>
</front>

<seriesInfo value="2482" name="RFC" />
</reference>


<reference target2="reference.RFC.2483.xml" anchor="RFC2483">
<front>
<title abbrev="URI Resolution Services">URI Resolution Services Necessary for URN Resolution</title>
<author fullname="Michael Mealling" initials="M." surname="Mealling">
<organization>Network Solutions</organization>

<address>
<postal>
<street>505 Huntmar Park Drive</street>
<city>Herndon</city>
<region>VA</region>
<code>22070</code>
<country>USA</country>
</postal>

<phone>+1 703 742 0400</phone>
<facsimile>+1 703 742 9552</facsimile>
<email>michaelm@rwhois.net</email>
</address>
</author>

<author fullname="Ron Daniel" initials="R." surname="Daniel">
<organization>Los Alamos National Laboratory, ,Advanced Computing Lab</organization>

<address>
<postal>
<street>MS B287</street>
<city>Los Alamos</city>
<region>NM</region>
<code>87545</code>
<country>USA</country>
</postal>

<phone>+1 505 665 0597</phone>
<facsimile>+1 505 665 4939</facsimile>
<email>rdaniel@lanl.gov</email>
</address>
</author>

<date year="1999" month="January" />
<area>Applications</area>
<keyword>uniform resource identifier</keyword>
<keyword>URI</keyword>

<abstract>
<t>
   Retrieving the resource identified by a Uniform Resource Identifier
   (URI)  is only one of the operations that can be performed on a
   URI.  One might also ask for and get a list of other identifiers that
   are aliases for the original URI or a bibliographic description of
   the resource the URI denotes, for example. This applies to both
   Uniform Resource Names (URNs) and Uniform Resource Locators (URLs).
   Uniform Resource Characteristics (URCs) are discussed in this
   document but only as descriptions of resources rather than
   identifiers.
</t>

<t>
   A service in the network providing access to a resource may provide
   one or some of these options, but it need not provide all of them.
   This memo specifies an initial set of these operations that can be
   used to describe the interactions provided by a given access service.
   It also suggests guidelines that should be adhered to when those
   operations are encoded in a protocol.
</t>
</abstract>
</front>

<seriesInfo value="2483" name="RFC" />
<format octets="47663" type="HTML" target="http://xml.resource.org/public/rfc/html/rfc2483.html" />
<format octets="43323" type="XML" target="http://xml.resource.org/public/rfc/xml/rfc2483.xml" />
</reference>


<reference target2="reference.RFC.2484.xml" anchor="RFC2484">
<front>
<title abbrev="LCP Internationalization Option">PPP LCP Internationalization Configuration Option</title>
<author fullname="Glen Zorn" initials="G." surname="Zorn">
<organization>Microsoft Corporation</organization>

<address>
<postal>
<street>One Microsoft Way</street>
<city>Redmond</city>
<region>WA</region>
<code>98052</code>
<country>US</country>
</postal>

<phone>+1 425 703 1559</phone>
<facsimile>+1 425 936 7329</facsimile>
<email>glennz@microsoft.com</email>
</address>
</author>

<date year="1999" month="January" />

<abstract>
<t>The Point-to-Point Protocol (PPP)provides a standard method for transporting multi-protocol datagrams over point-to-point links.   PPP also defines an extensible Link Control Protocol (LCP), which allows negotiation of an Authentication Protocol for authenticating its peer before allowing Network Layer protocols to transmit over the link.</t>

<t>Both LCP and Authentication Protocol packets may contain text which is intended to be human-readable,,.  This document defines an LCP configuration option for the negotiation of character set and language usage, as required by RFC 2277.</t>
</abstract>
</front>

<seriesInfo value="2484" name="RFC" />
</reference>


<reference target2="reference.RFC.2485.xml" anchor="RFC2485">
<front>
<title abbrev="DCHP Option for the Open Group&apos;s UAP">DHCP Option for The Open Group&apos;s User Authentication Protocol</title>
<author fullname="Steve Drach" initials="S." surname="Drach">
<organization>Sun Microsystems, Inc.</organization>

<address>
<postal>
<street>901 San Antonio Road</street>
<city>Palo Alto</city>
<region>CA</region>
<code>94303</code>
<country>USA</country>
</postal>

<phone>+1 650 960 1300</phone>
<email>drach@sun.com</email>
</address>
</author>

<date year="1999" month="January" />
<area>Security</area>
<keyword>DHCP</keyword>
<keyword>authentication</keyword>
<keyword>dynamic host configuration protocol</keyword>

<abstract>
<t>
   This document defines a DHCP  option that contains a list of
   pointers to User Authentication Protocol servers that provide user
   authentication services for clients that conform to The Open Group
   Network Computing Client Technical Standard .
</t>
</abstract>
</front>

<seriesInfo value="2485" name="RFC" />
<format octets="15804" type="HTML" target="http://xml.resource.org/public/rfc/html/rfc2485.html" />
<format octets="12934" type="XML" target="http://xml.resource.org/public/rfc/xml/rfc2485.xml" />
</reference>


<reference target2="reference.RFC.2486.xml" anchor="RFC2486">
<front>
<title>The Network Access Identifier</title>
<author fullname="Bernard Aboba" initials="B." surname="Aboba">
<organization>Microsoft Corporation</organization>

<address>
<postal>
<street>One Microsoft Way</street>
<city>Redmond</city>
<region>WA</region>
<code>98052</code>
<country>USA</country>
</postal>

<phone>+1 425 936 6605</phone>
<email>bernarda@microsoft.com</email>
</address>
</author>

<author fullname="Mark A. Beadles" initials="M." surname="Beadles">
<organization>WorldCom Advanced Networks</organization>

<address>
<postal>
<street>5000 Britton Rd.</street>
<city>Hilliard</city>
<region>OH</region>
<code>43026</code>
<country>USA</country>
</postal>

<phone>+1 614 723 1941</phone>
<email>mbeadles@wcom.net</email>
</address>
</author>

<date year="1999" month="January" />

<abstract>
<t>
   In order to enhance the interoperability of roaming and tunneling
   services, it is desirable to have a standardized method for
   identifying users.  This document proposes syntax for the Network
   Access Identifier (NAI), the userID submitted by the client during
   PPP authentication. It is expected that this will be of interest for
   support of roaming as well as tunneling.  "Roaming capability" may be
   loosely defined as the ability to use any one of multiple Internet
   service providers (ISPs), while maintaining a formal, customer-vendor
   relationship with only one.  Examples of where roaming capabilities
   might be required include ISP "confederations" and ISP-provided
   corporate network access support.
</t>
</abstract>
</front>

<seriesInfo value="2486" name="RFC" />
<format octets="14738" type="HTML" target="http://xml.resource.org/public/rfc/html/rfc2486.html" />
<format octets="15432" type="XML" target="http://xml.resource.org/public/rfc/xml/rfc2486.xml" />
</reference>


<reference target2="reference.RFC.2487.xml" anchor="RFC2487">
<front>
<title abbrev="SMTP Service Extension">SMTP Service Extension for Secure SMTP over TLS</title>
<author fullname="Paul Hoffman" initials="P." surname="Hoffman">
<organization>Internet Mail Consortium</organization>

<address>
<postal>
<street>127 Segre Place</street>
<city>Santa Cruz</city>
<region>CA</region>
<code>95060</code>
<country>USA</country>
</postal>

<phone>+1 408 426 9827</phone>
<email>phoffman@imc.org</email>
</address>
</author>

<date year="1999" month="January" />
<area>Applications</area>
<keyword>SMTP</keyword>
<keyword>attack</keyword>
<keyword>authentication</keyword>
<keyword>security</keyword>
<keyword>simple mail transfer protocol</keyword>
<keyword>transport layer security</keyword>
</front>

<seriesInfo value="2487" name="RFC" />
<format octets="27126" type="HTML" target="http://xml.resource.org/public/rfc/html/rfc2487.html" />
<format octets="22468" type="XML" target="http://xml.resource.org/public/rfc/xml/rfc2487.xml" />
</reference>


<reference target2="reference.RFC.2488.xml" anchor="RFC2488">
<front>
<title abbrev="Enhancing TCP Over Satellite Channels">Enhancing TCP Over Satellite Channels using Standard Mechanisms</title>
<author fullname="Mark Allman" initials="M." surname="Allman">
<organization>NASA Lewis Research Center/Sterling Software</organization>

<address>
<postal>
<street>21000 Brookpark Rd., MS 54-2</street>
<city>Cleveland</city>
<region>OH</region>
<code>44135</code>
<country>USA</country>
</postal>

<phone>+1 216 433 6586</phone>
<email>mallman@lerc.nasa.gov</email>
<uri>http://roland.lerc.nasa.gov/~mallman</uri>
</address>
</author>

<author fullname="Daniel R. Glover" initials="D.R." surname="Glover">
<organization>NASA Lewis Research Center</organization>

<address>
<postal>
<street />
<city>Cleveland</city>
<region>OH</region>
<code>44135</code>
<country>USA</country>
</postal>

<phone>+1 216 433 2847</phone>
<email>Daniel.R.Glover@lerc.nasa.gov</email>
</address>
</author>

<author fullname="Luis A. Sanchez" initials="L.A." surname="Sanchez">
<organization>BBN Technologies, GTE Internetworking</organization>

<address>
<postal>
<street>10 Moulton Street</street>
<city>Cambridge</city>
<region>MA</region>
<code>02140</code>
<country>USA</country>
</postal>

<phone>+1 617 873 3351</phone>
<email>lsanchez@ir.bbn.com</email>
</address>
</author>

<date year="1999" month="January" />
<area>Transport</area>
<keyword>transmission control protocol</keyword>
<keyword>satellite</keyword>
<keyword>TCP</keyword>

<abstract>
<t>
   The Transmission Control Protocol (TCP) provides reliable delivery of
   data across any network path, including network paths containing
   satellite channels.  While TCP works over satellite channels there
   are several IETF standardized mechanisms that enable TCP to more
   effectively utilize the available capacity of the network path.  This
   document outlines some of these TCP mitigations.  At this time, all
   mitigations discussed in this document are IETF standards track
   mechanisms (or are compliant with IETF standards).
</t>
</abstract>
</front>

<seriesInfo value="28" name="BCP" />
<seriesInfo value="2488" name="RFC" />
<format octets="66011" type="HTML" target="http://xml.resource.org/public/rfc/html/rfc2488.html" />
<format octets="63640" type="XML" target="http://xml.resource.org/public/rfc/xml/rfc2488.xml" />
</reference>


<reference target2="reference.RFC.2489.xml" anchor="RFC2489">
<front>
<title abbrev="Defining New DCHP Options">Procedure for Defining New DHCP Options</title>
<author fullname="Ralph Droms" initials="R." surname="Droms">
<organization>Bucknell University, Computer Science Department</organization>

<address>
<postal>
<street>323 Dana Engineering</street>
<city>Lewisburg</city>
<region>PA</region>
<code>17837</code>
<country>USA</country>
</postal>

<phone>+1 717 524 1145</phone>
<email>droms@bucknell.edu</email>
</address>
</author>

<date year="1999" month="January" />
<area>Internet</area>
<keyword>dynamic host configuration protocol</keyword>
<keyword>DHCP</keyword>

<abstract>
<t>
   The Dynamic Host Configuration Protocol (DHCP) provides a framework
   for passing configuration information to hosts on a TCP/IP network.
   Configuration parameters and other control information are carried in
   tagged data items that are stored in the &apos;options&apos; field of the DHCP
   message.  The data items themselves are also called &quot;options.&quot;
</t>

<t>
   New DHCP options may be defined after the publication of the DHCP
   specification to accommodate requirements for conveyance of new
   configuration parameters.  This document describes the procedure for
   defining new DHCP options.
</t>
</abstract>
</front>

<seriesInfo value="29" name="BCP" />
<seriesInfo value="2489" name="RFC" />
<format octets="23666" type="HTML" target="http://xml.resource.org/public/rfc/html/rfc2489.html" />
<format octets="18605" type="XML" target="http://xml.resource.org/public/rfc/xml/rfc2489.xml" />
</reference>


<reference target2="reference.RFC.2490.xml" anchor="RFC2490">
<front>
<title abbrev="RSVP Simulation">A Simulation Model for IP Multicast with RSVP</title>
<author fullname="J. Mark Pullen" initials="J.M." surname="Pullen">
<organization>C3I Center/Computer Science</organization>

<address>
<postal>
<street>Mail Stop 4A5</street>
<street>George Mason University</street>
<street>Fairfax</street>
<street>VA 22032</street>
</postal>

<email>mpullen@gmu.edu</email>
</address>
</author>

<author fullname="Ravi Malghan" initials="R." surname="Malghan">
<organization />

<address>
<postal>
<street>3141 Fairview Park Drive</street>
<street>Suite 700</street>
<street>Falls Church VA 22042</street>
</postal>

<email>rmalghan@bacon.gmu.edu</email>
</address>
</author>

<author fullname="Lava K. Lavu" initials="L.K." surname="Lavu">
<organization>Bay Networks</organization>

<address>
<postal>
<street>600 Technology Park Dr.</street>
<street>Billerica</street>
<street>MA 01821</street>
</postal>

<email>llavu@bacon.gmu.edu</email>
</address>
</author>

<author fullname="Gang Duan" initials="G." surname="Duan">
<organization>Oracle Co.</organization>

<address>
<postal>
<street>Redwood Shores</street>
<street>CA 94065</street>
</postal>

<email>gduan@us.oracle.com</email>
</address>
</author>

<author fullname="Jiemei Ma" initials="J." surname="Ma">
<organization>Newbridge Networks Inc.</organization>

<address>
<postal>
<street>593 Herndon Parkway</street>
<street>Herndon</street>
<street>VA 20170</street>
</postal>

<email>jma@newbridge.com</email>
</address>
</author>

<author fullname="Hoon Nah" initials="H." surname="Nah">
<organization>C3I Center</organization>

<address>
<postal>
<street>Mail Stop 4B5</street>
<street>George Mason University</street>
<street>Fairfax</street>
<street>VA 22030</street>
</postal>

<email>hnah@bacon.gmu.edu</email>
</address>
</author>

<date year="1999" month="January" />
<area>Transport</area>
<keyword>RSVP</keyword>
<keyword>multicast</keyword>
<keyword>resource reservation protocol</keyword>
<keyword>routing</keyword>

<abstract>
<t>
   This document describes a detailed model of IPv4 multicast with RSVP
   that has been developed using the OPNET simulation package , with
   protocol procedures defined in the C language.  The model was
   developed to allow investigation of performance constraints on
   routing but should have wide applicability in the Internet
   multicast/resource reservation community.  We are making this model
   publicly available with the intention that it can be used to provide
   expanded studies of resource-reserved multicasting.
</t>
</abstract>
</front>

<seriesInfo value="2490" name="RFC" />
<format octets="92262" type="HTML" target="http://xml.resource.org/public/rfc/html/rfc2490.html" />
<format octets="75033" type="XML" target="http://xml.resource.org/public/rfc/xml/rfc2490.xml" />
</reference>


<reference target2="reference.RFC.2491.xml" anchor="RFC2491">
<front>
<title abbrev="IPv6 over NBMA networks">IPv6 over Non-Broadcast Multiple Access (NBMA) networks</title>
<author fullname="Grenville Armitage" initials="G." surname="Armitage">
<organization>Bell Laboratories, Lucent Technologies</organization>

<address>
<postal>
<street>101 Crawfords Corner Road</street>
<street>Holmdel</street>
<street>NJ 07733</street>
<country>USA</country>
</postal>

<email>gja@lucent.com</email>
</address>
</author>

<author fullname="Peter Schulter" initials="P." surname="Schulter">
<organization>Bright Tiger Technologies</organization>

<address>
<postal>
<street>125 Nagog Park</street>
<street>Acton</street>
<street>MA 01720</street>
</postal>

<email>paschulter@acm.org</email>
</address>
</author>

<author fullname="Markus Jork" initials="M." surname="Jork">
<organization>European Applied Research Center</organization>

<address>
<postal>
<street>Digital Equipment GmbH</street>
<street>CEC Karlsruhe</street>
<street>Vincenz-Priessnitz-Str. 1</street>
<street>D-76131 Karlsruhe</street>
<country>Germany</country>
</postal>

<email>jork@kar.dec.com</email>
</address>
</author>

<author fullname="Geraldine Harter" initials="G." surname="Harter">
<organization>Digital UNIX Networking</organization>

<address>
<postal>
<street>Compaq Computer Corporation</street>
<street>110 Spit Brook Road</street>
<street>Nashua</street>
<street>NH 03062</street>
</postal>

<email>harter@zk3.dec.com</email>
</address>
</author>

<date year="1999" month="January" />
<area>Internet</area>
<keyword>broadcast</keyword>
<keyword>frame relay</keyword>
<keyword>internet protocol version 6</keyword>
<keyword>non-broadcast multiple access</keyword>
<keyword>point-to-point protocol</keyword>

<abstract>
<t>
   This document describes a general architecture for IPv6 over NBMA
   networks. It forms the basis for subsidiary companion documents that
   describe details for various specific NBMA technologies (such as ATM
   or Frame Relay). The IPv6 over NBMA architecture allows conventional
   host-side operation of the IPv6 Neighbor Discovery protocol, while
   also supporting the establishment of &apos;shortcut&apos; NBMA forwarding paths
   when dynamically signaled NBMA links are available. Operations over
   administratively configured Point to Point NBMA links are also
   described.
</t>

<t>
   Dynamic NBMA shortcuts are achieved through the use of IPv6 Neighbor
   Discovery protocol operation within Logical Links, and inter-router
   NHRP for the discovery of off-Link NBMA destinations. Both flow-
   triggered and explicitly source-triggered shortcuts are supported.
</t>
</abstract>
</front>

<seriesInfo value="2491" name="RFC" />
<format octets="128005" type="HTML" target="http://xml.resource.org/public/rfc/html/rfc2491.html" />
<format octets="107082" type="XML" target="http://xml.resource.org/public/rfc/xml/rfc2491.xml" />
</reference>


<reference target2="reference.RFC.2492.xml" anchor="RFC2492">
<front>
<title>IPv6 over ATM Networks</title>
<author fullname="Grenville Armitage" initials="G." surname="Armitage">
<organization>Bell Laboratories, Lucent Technologies</organization>

<address>
<postal>
<street>101 Crawfords Corner Road</street>
<street>Holmdel</street>
<street>NJ 07733</street>
<country>USA</country>
</postal>

<email>gja@lucent.com</email>
</address>
</author>

<author fullname="Peter Schulter" initials="P." surname="Schulter">
<organization>BrightTiger Technologies</organization>

<address>
<postal>
<street>125 Nagog Park</street>
<street>Acton</street>
<street>MA 01720</street>
</postal>

<email>paschulter@acm.org</email>
</address>
</author>

<author fullname="Markus Jork" initials="M." surname="Jork">
<organization>European Applied Research Center</organization>

<address>
<postal>
<street>Digital Equipment GmbH</street>
<street>CEC Karlsruhe</street>
<street>Vincenz-Priessnitz-Str. 1</street>
<street>D-76131 Karlsruhe</street>
<country>Germany</country>
</postal>

<email>jork@kar.dec.com</email>
</address>
</author>

<date year="1999" month="January" />
<area>Internet</area>
<keyword>asynchronous transfer mode</keyword>
<keyword>internet protocol version 6</keyword>
<keyword>non-broadcast multiple access</keyword>
<keyword>point-to-point protocol</keyword>
<keyword>ATM</keyword>

<abstract>
<t>
   This document is a companion to the ION working group&apos;s architecture
   document, &quot;IPv6 over Non Broadcast Multiple Access (NBMA) networks&quot;.
   It provides specific details on how to apply the IPv6 over NBMA
   architecture to ATM networks. This architecture allows conventional
   host-side operation of the IPv6 Neighbor Discovery protocol, while
   also supporting the establishment of &apos;shortcut&apos; ATM forwarding paths
   (when using SVCs).  Operation over administratively configured Point
   to Point PVCs is also supported.
</t>
</abstract>
</front>

<seriesInfo value="2492" name="RFC" />
<format octets="40409" type="HTML" target="http://xml.resource.org/public/rfc/html/rfc2492.html" />
<format octets="25204" type="XML" target="http://xml.resource.org/public/rfc/xml/rfc2492.xml" />
</reference>


<reference target2="reference.RFC.2493.xml" anchor="RFC2493">
<front>
<title abbrev="Performance History">Textual Conventions for MIB Modules Using Performance History Based on 15 Minute Intervals</title>
<author fullname="Kaj Tesink" initials="K." surname="Tesink">
<organization>Bellcore</organization>

<address>
<postal>
<street>331 Newman Springs Road</street>
<street>P.O. Box 7020</street>
<street>Red Bank</street>
<street>NJ  07701-7020</street>
</postal>

<phone>(732) 758-5254</phone>
<email>kaj@bellcore.com</email>
</address>
</author>

<date year="1999" month="January" />
<area>Management</area>
<keyword>Management Information Base</keyword>
<keyword>SNMP</keyword>

<abstract>
<t>
   This document defines a set of Textual Conventions for MIB modules
   which make use of performance history data based on 15 minute
   intervals.
</t>
</abstract>
</front>

<seriesInfo value="2493" name="RFC" />
<format octets="31593" type="HTML" target="http://xml.resource.org/public/rfc/html/rfc2493.html" />
<format octets="18988" type="XML" target="http://xml.resource.org/public/rfc/xml/rfc2493.xml" />
</reference>


<reference target2="reference.RFC.2494.xml" anchor="RFC2494">
<front>
<title abbrev="DSO Managed Objects">Definitions of Managed Objects for the DS0 and DS0 Bundle Interface Type</title>
<author fullname="David Fowler" initials="D." surname="Fowler">
<organization>Newbridge Networks</organization>

<address>
<postal>
<street>600 March Road</street>
<street>Kanata</street>
<street>Ontario</street>
<street>Canada K2K 2E6</street>
</postal>

<phone>(613) 599-3600, ext 6559</phone>
<email>davef@newbridge.com</email>
</address>
</author>

<date year="1999" month="January" />
<keyword>Management Information Base</keyword>
<keyword>managed object</keyword>
<keyword>synchronous optical network</keyword>

<abstract>
<t>
   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 DS0 and DS0
   Bundle interfaces.  This document is a companion document with
   Definitions of Managed Objects for the DS1/E1/DS2/E2 (RFC 2495 ),
   DS3/E3 (RFC 2496 ), and the work in progress, SONET/SDH Interface
   Types.
</t>

<t>
   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.
</t>
</abstract>
</front>

<seriesInfo value="2494" name="RFC" />
<format octets="62201" type="HTML" target="http://xml.resource.org/public/rfc/html/rfc2494.html" />
<format octets="50759" type="XML" target="http://xml.resource.org/public/rfc/xml/rfc2494.xml" />
</reference>


<reference target2="reference.RFC.2495.xml" anchor="RFC2495">
<front>
<title abbrev="DS1 and E1 MIB">Definitions of Managed Objects for the DS1, E1, DS2 and E2 Interface Types</title>
<author fullname="David Fowler" initials="D." surname="Fowler">
<organization>Newbridge Networks</organization>

<address>
<postal>
<street>600 March Road</street>
<street>Kanata</street>
<street>Ontario</street>
<street>Canada K2K 2E6</street>
</postal>

<phone>(613) 599-3600, ext 6559</phone>
<email>davef@newbridge.com</email>
</address>
</author>

<date year="1999" month="January" />
<area>Management</area>
<keyword>Management Information Base</keyword>
<keyword>T-1 1.544 megabits/sec synchronous lines</keyword>
<keyword>managed object</keyword>
<keyword>synchronous optical network</keyword>

<abstract>
<t>
   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 DS1, E1, DS2
   and E2 interfaces.  This document is a companion document with
   Definitions of Managed Objects for the DS0 (RFC 2494 ), DS3/E3
   (RFC 2496 ), and the work in progress, SONET/SDH Interface Types.
</t>

<t>
   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.
</t>
</abstract>
</front>

<seriesInfo value="2495" name="RFC" />
<format octets="170473" type="HTML" target="http://xml.resource.org/public/rfc/html/rfc2495.html" />
<format octets="157238" type="XML" target="http://xml.resource.org/public/rfc/xml/rfc2495.xml" />
</reference>


<reference target2="reference.RFC.2496.xml" anchor="RFC2496">
<front>
<title abbrev="DS3/E3 MIB">Definitions of Managed Objects for the DS3/E3 Interface Type</title>
<author fullname="David Fowler" initials="D." surname="Fowler">
<organization>Newbridge Networks</organization>

<address>
<postal>
<street>600 March Road</street>
<street>Kanata</street>
<street>Ontario</street>
<street>Canada K2K 2E6</street>
</postal>

<phone>(613) 599-3600, ext 6559</phone>
<email>davef@newbridge.com</email>
</address>
</author>

<date year="1999" month="January" />
<area>Management</area>
<area>Internet</area>
<keyword>Management Information Base</keyword>
<keyword>T-3 44.746 megabits/sec synchronous lines</keyword>
<keyword>managed object</keyword>
<keyword>synchronous optical network</keyword>
<keyword>DS3</keyword>
<keyword>E3</keyword>

<abstract>
<t>
   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 DS3 and E3
   interfaces.  This document is a companion document with Definitions
   of Managed Objects for the DS0 (RFC 2494 ), DS1/E1/DS2/E2 (RFC
   2495 ), and the work in progress SONET/SDH Interface Types.
</t>

<t>
   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.
</t>
</abstract>
</front>

<seriesInfo value="2496" name="RFC" />
<format octets="137580" type="HTML" target="http://xml.resource.org/public/rfc/html/rfc2496.html" />
<format octets="125266" type="XML" target="http://xml.resource.org/public/rfc/xml/rfc2496.xml" />
</reference>


<reference target2="reference.RFC.2497.xml" anchor="RFC2497">
<front>
<title abbrev="IPv6 Datagrams on ARCnet">Transmission of IPv6 Packets over ARCnet Networks</title>
<author fullname="Ignatios Souvatzis" initials="I." surname="Souvatzis">
<organization>The NetBSD Project</organization>

<address>
<postal>
<street>Stationenweg 29</street>
<city>Bornheim</city>
<region />
<code>D-53332</code>
<country>DE</country>
</postal>

<phone>+49 228 734316</phone>
<email>is@netbsd.org</email>
</address>
</author>

<date year="1999" month="January" />
</front>

<seriesInfo value="2497" name="RFC" />
</reference>


<reference target2="reference.RFC.2498.xml" anchor="RFC2498">
<front>
<title abbrev="IPPM Metrics">IPPM Metrics for Measuring Connectivity</title>
<author fullname="Jamshid Mahdavi" initials="J." surname="Mahdavi">
<organization>Pittsburgh Supercomputing Center</organization>

<address>
<postal>
<street>4400 5th Avenue</street>
<street>Pittsburgh</street>
<street>PA  15213</street>
<country>USA</country>
</postal>

<email>mahdavi@psc.edu</email>
</address>
</author>

<author fullname="Vern Paxson" initials="V." surname="Paxson">
<organization>MS 50A-3111</organization>

<address>
<postal>
<street>Lawrence Berkeley National Laboratory</street>
<street>University of California</street>
<street>Berkeley</street>
<street>CA  94720</street>
<country>USA</country>
</postal>

<phone>+1 510/486-7504</phone>
<email>vern@ee.lbl.gov</email>
</address>
</author>

<date year="1999" month="January" />
<area>Internet</area>
<keyword>reachability</keyword>
<keyword>connectivity</keyword>
</front>

<seriesInfo value="2498" name="RFC" />
<format octets="32998" type="HTML" target="http://xml.resource.org/public/rfc/html/rfc2498.html" />
<format octets="20207" type="XML" target="http://xml.resource.org/public/rfc/xml/rfc2498.xml" />
</reference>


<reference target2="reference.RFC.2499.xml" anchor="RFC2499">
<front>
<title abbrev="Summary of 2400-2499">Request for Comments Summary</title>
<author fullname="Alegre Ramos" initials="A." surname="Ramos">
<organization>University of Southern California, Information Sciences Institute</organization>

<address>
<postal>
<street>4676 Admiralty Way</street>
<city>Marina del Rey</city>
<region>CA</region>
<code>90292</code>
<country>US</country>
</postal>

<phone>+1 310 822 1511</phone>
<email>ramos@isi.edu</email>
</address>
</author>

<date year="1999" month="July" />

<abstract>
<t></t>
</abstract>
</front>

<seriesInfo value="2499" name="RFC" />
</reference>


<reference target2="reference.RFC.2500.xml" anchor="RFC2500">
<front>
<title abbrev="Internet Standards">Internet Official Protocol Standards</title>
<author fullname="Joyce K. Reynolds" initials="J.K." surname="Reynolds">
<organization>USC/Information Sciences Institute</organization>

<address>
<postal>
<street>4676 Admiralty Way</street>
<city>Marina del Rey</city>
<region>CA</region>
<code>90292</code>
<country>US</country>
</postal>

<phone>+1 310 822 1511</phone>
<facsimile>+1 310 823 6714</facsimile>
<email>JKRey@ISI.EDU</email>
</address>
</author>

<author fullname="Robert Braden" initials="R." surname="Braden">
<organization>USC/Information Sciences Institute</organization>

<address>
<postal>
<street>4676 Admiralty Way</street>
<city>Marina del Rey</city>
<region>CA</region>
<code>90292</code>
<country>US</country>
</postal>

<phone>+1 310 822 1511</phone>
<facsimile>+1 310 823 6714</facsimile>
<email>Braden@ISI.EDU</email>
</address>
</author>

<date year="1999" month="June" />
</front>

<seriesInfo value="2500" name="RFC" />
</reference>


<reference target2="reference.RFC.2501.xml" anchor="RFC2501">
<front>
<title abbrev="MANET Performance Issues">Mobile Ad hoc Networking (MANET): Routing Protocol Performance Issues and Evaluation Considerations</title>
<author fullname="M. Scott Corson" initials="M.S." surname="Corson">
<organization>Institute for Systems Research</organization>

<address>
<postal>
<street>University of Maryland</street>
<street>College Park</street>
<street>MD 20742</street>
</postal>

<phone>(301) 405-6630</phone>
<email>corson@isr.umd.edu</email>
</address>
</author>

<author fullname="Joseph Macker" initials="J." surname="Macker">
<organization>Information Technology Division</organization>

<address>
<postal>
<street>Naval Research Laboratory</street>
<street>Washington</street>
<street>DC 20375</street>
</postal>

<phone>(202) 767-2001</phone>
<email>macker@itd.nrl.navy.mil</email>
</address>
</author>

<date year="1999" month="January" />
<area>Routing</area>
<keyword>mobile IP</keyword>
<keyword>Mobile Ad hoc Networks</keyword>

<abstract>
<t>
   This memo first describes the characteristics of Mobile Ad hoc
   Networks (MANETs), and their idiosyncrasies with respect to
   traditional, hardwired packet networks.  It then discusses the effect
   these differences have on the design and evaluation of network
   control protocols with an emphasis on routing performance evaluation
   considerations.
</t>
</abstract>
</front>

<seriesInfo value="2501" name="RFC" />
<format octets="38334" type="HTML" target="http://xml.resource.org/public/rfc/html/rfc2501.html" />
<format octets="27446" type="XML" target="http://xml.resource.org/public/rfc/xml/rfc2501.xml" />
</reference>


<reference target2="reference.RFC.2502.xml" anchor="RFC2502">
<front>
<title abbrev="Limitations of Internet Protocol Suite">Limitations of Internet Protocol Suite for Distributed Simulation the Large Multicast Environment</title>
<author fullname="J. Mark Pullen" initials="J.M." surname="Pullen">
<organization>Computer Science/C3I Center</organization>

<address>
<postal>
<street>MS 4A5</street>
<street>George Mason University</street>
<street>Fairfax</street>
<street>VA 22032</street>
</postal>

<email>mpullen@gmu.edu</email>
</address>
</author>

<author fullname="Michael Myjak" initials="M." surname="Myjak">
<organization>The Virtual Workshop</organization>

<address>
<postal>
<street>P.O. Box 98</street>
<street>Titusville</street>
<street>FL 32781</street>
</postal>

<email>mmyjak@virtualworkshop.com</email>
</address>
</author>

<author fullname="Christina Bouwens" initials="C." surname="Bouwens">
<organization>ASSET Group, SAIC Inc.</organization>

<address>
<postal>
<street>Orlando</street>
<street>FL</street>
</postal>

<email>christina.bouwens@cpmx.mail.saic.com</email>
</address>
</author>

<date year="1999" month="February" />
<area>Internet</area>
<keyword>multicast</keyword>

<abstract>
<t>
   The Large-Scale Multicast Applications (LSMA) working group was
   chartered to produce documents aimed at a consensus based development
   of the Internet protocols to support large scale multicast
   applications including real-time distributed simulation.  This memo
   defines services that LSMA has found to be required, and aspects of
   the Internet protocols that LSMA has found to need further
   development in order to meet these requirements.
</t>
</abstract>
</front>

<seriesInfo value="2502" name="RFC" />
<format octets="41146" type="HTML" target="http://xml.resource.org/public/rfc/html/rfc2502.html" />
<format octets="30856" type="XML" target="http://xml.resource.org/public/rfc/xml/rfc2502.xml" />
</reference>


<reference target2="reference.RFC.2503.xml" anchor="RFC2503">
<front>
<title abbrev="ISO ILL Protocol MIME Types">MIME Types for Use with the ISO ILL Protocol</title>
<author fullname="Ruth Moulton" initials="R." surname="Moulton">
<organization />

<address>
<postal>
<street>65 Tetherdown</street>
<city>London</city>
<region>England</region>
<code>N10 1NH</code>
<country>UK</country>
</postal>

<phone>+44 181 8835823</phone>
<email>ruth@muswell.demon.co.uk</email>
</address>
</author>

<author fullname="Mark H. Needleman" initials="M." surname="Needleman">
<organization>Data Research Associates, Inc.</organization>

<address>
<postal>
<street>1276 North Warson Road</street>
<street>POB 8495</street>
<city>Saint Louis</city>
<region>MO</region>
<code>63132-1806</code>
<country>US</country>
</postal>

<phone>+1 314 432 1100 x318</phone>
<email>mneedleman@dra.com</email>
</address>
</author>

<date year="1999" month="February" />

<abstract>
<t>This memorandum describes a set of MIME types for use with the ISO Interlibrary Loan Protocol (,).Two MIME types are specified below.</t>

<t>The first is a media type to carry objects which areBERencoded ISO ILL Protocol Data Units (PDU's).BER are the basic Encoding Rules used to encode  PDU's which have been described usingASN.1(Abstract Syntax Notation 1).</t>

<t>The second is for use with the associated document delivery instructions. Document Delivery Instructions (DDI) is an emerging protocol which enables automatic electronic delivery of items. It allows a request management system (which might have received a request for an item via the ISO Interlibrary Loan Protocol (,) to pass details of the request, item, and delivery, to a delivery module, and to receive back reports on the delivery process or arrival of an item. It is currently being submitted to the ISO TC46/SC4/WG4 committee for approval as an ISO standard.</t>
</abstract>
</front>

<seriesInfo value="2503" name="RFC" />
</reference>


<reference target2="reference.RFC.2504.xml" anchor="RFC2504">
<front>
<title>Users&#039; Security Handbook</title>
<author fullname="Erik Guttman" initials="E." surname="Guttman">
<organization>Sun Microsystems</organization>

<address>
<postal>
<street>Bahnstr. 2</street>
<street>74915 Waibstadt</street>
<country>Germany</country>
</postal>

<phone>+49 7263 911701</phone>
<email>erik.guttman@sun.com</email>
</address>
</author>

<author fullname="Lorna Leong" initials="L." surname="Leong">
<organization>COLT Internet</organization>

<address>
<postal>
<street>250 City Road</street>
<street>City Forum</street>
<street>London</street>
<street>England</street>
</postal>

<phone>+44 171 390 3900</phone>
<email>lorna@colt.net</email>
</address>
</author>

<author fullname="Gary Malkin" initials="G." surname="Malkin">
<organization>Bay Networks</organization>

<address>
<postal>
<street>8 Federal Street</street>
<street>Billerca</street>
<street>MA 01821</street>
<country>USA</country>
</postal>

<phone>+1 508 916 4237</phone>
<email>gmalkin@baynetworks.com</email>
</address>
</author>

<date year="1999" month="February" />
<area>Security</area>

<abstract>
<t>
   The Users&#039; Security Handbook is the companion to the Site Security
   Handbook (SSH).  It is intended to provide users with the information
   they need to help keep their networks and systems secure.
</t>
</abstract>
</front>

<seriesInfo value="2504" name="RFC" />
<format octets="88718" type="HTML" target="http://xml.resource.org/public/rfc/html/rfc2504.html" />
<format octets="72134" type="XML" target="http://xml.resource.org/public/rfc/xml/rfc2504.xml" />
</reference>


<reference target2="reference.RFC.2505.xml" anchor="RFC2505">
<front>
<title abbrev="Anti-Spam Recommendations">Anti-Spam Recommendations for SMTP MTAs</title>
<author fullname="Gunnar Lindberg" initials="G." surname="Lindberg">
<organization>Chalmers University of Technology, Computer Communications Group</organization>

<address>
<postal>
<street />
<city>Gothenburg</city>
<code>SE-412 96</code>
<country>SE</country>
</postal>

<phone>+46 31 7725913</phone>
<email>lindberg@cdg.chalmers.se</email>
</address>
</author>

<date year="1999" month="February" />

<abstract>
<t>This memo gives a number of implementation recommendations for SMTP,, MTAs (Mail Transfer Agents, e.g.sendmail) to make them more capable of reducing the impact of spam(*).</t>

<t>The intent is that these recommendations will help clean up the spam situation, if applied on enough SMTP MTAs on the Internet, and that they should be used as guidelines for the various MTA vendors. We are fully aware that this is not the final solution, but if these recommendations were included, and used, on all Internet SMTP MTAs, things would improve considerably and give time to design a more long term solution. The Future Work section suggests some ideas that may be part of such a long term solution. It might, though, very well be the case that the ultimate solution is social, political, or legal, rather than technical in nature.</t>

<t>The implementor should be aware of the increased risk of denial of service attacks that several of the proposed methods might lead to. For example, increased number of queries to DNS servers and increased size of logfiles might both lead to overloaded systems and system crashes during an attack.</t>

<t>A brief summary of this memo is:
<list style="symbols">
<t>Stop unauthorized mail relaying.</t>

<t>Spammers then have to operate in the open; deal with them.</t>

<t>Design a mail system that can handle spam.</t>
</list>
</t>
</abstract>
</front>

<seriesInfo value="30" name="BCP" />
<seriesInfo value="2505" name="RFC" />
</reference>


<reference target2="reference.RFC.2506.xml" anchor="RFC2506">
<front>
<title>Media Feature Tag Registration Procedure</title>
<author fullname="Koen Holtman" initials="K." surname="Holtman">
<organization>Technische Universiteit Eindhoven</organization>

<address>
<postal>
<street>Postbus 513</street>
<street>Kamer HG 6.57</street>
<city>Eindhoven</city>
<code>5600 MB</code>
<country>NL</country>
</postal>

<email>koen@win.tue.nl</email>
</address>
</author>

<author fullname="Andrew H. Mutz" initials="A." surname="Mutz">
<organization>Hewlett-Packard Company</organization>

<address>
<postal>
<street>11000 Wolfe Road</street>
<street>42UO</street>
<city>Cupertino</city>
<region>CA</region>
<code>95014</code>
<country>US</country>
</postal>

<email>andy_mutz@hp.com</email>
</address>
</author>

<author fullname="Ted Hardie" initials="T." surname="Hardie">
<organization>Equinix</organization>

<address>
<postal>
<street>901 Marshall Street</street>
<city>Redwood City</city>
<region>CA</region>
<code>94063</code>
<country>US</country>
</postal>

<email>hardie@equinix.com</email>
</address>
</author>

<date year="1999" month="March" />

<abstract>
<t>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.</t>

<t>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.</t>

<t>This document defines a registration procedure which uses the Internet Assigned Numbers Authority (IANA) as a central registry for the media feature vocabulary.</t>

<t>Please send comments to the CONNEG working group at&lt;ietf-medfree@imc.org&gt;.Discussions of the working group are archived at&lt;URL: http://www.imc.org/ietf-medfree/&gt;.</t>
</abstract>
</front>

<seriesInfo value="31" name="BCP" />
<seriesInfo value="2506" name="RFC" />
</reference>


<reference target2="reference.RFC.2507.xml" anchor="RFC2507">
<front>
<title>IP Header Compression</title>
<author fullname="Mikael Degermark" initials="M." surname="Degermark">
<organization>Department of Computer Science and Electrical Engineering</organization>

<address>
<postal>
<street>Lulea University of Technology</street>
<city>Lulea</city>
<code>SE-971 87</code>
<country>SE</country>
</postal>

<phone>+46 92 091188</phone>
<email>micke@sm.luth.se</email>
</address>
</author>

<author fullname="Bjorn Nordgren" initials="B." surname="Nordgren">
<organization>CDT/Telia Research AB</organization>

<address>
<postal>
<street>Aurorum 6</street>
<city>Lulea</city>
<code>S-977 75</code>
<country>SE</country>
</postal>

<phone>+46 92 075400</phone>
<email>bcn@lulea.trab.se</email>
<email>bcn@cdt.luth.se</email>
</address>
</author>

<author fullname="Stephen Pink" initials="S." surname="Pink">
<organization>Department of Computer Science and Electrical Engineering</organization>

<address>
<postal>
<street>Lulea University of Technology</street>
<city>Lulea</city>
<code>SE-971 87</code>
<country>SE</country>
</postal>

<phone>+46 92 075229</phone>
<email>steve@sm.luth.se</email>
</address>
</author>

<date year="1999" month="February" />

<abstract>
<t>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.</t>

<t>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.</t>

<t>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.</t>
</abstract>
</front>

<seriesInfo value="2507" name="RFC" />
</reference>


<reference target2="reference.RFC.2508.xml" anchor="RFC2508">
<front>
<title abbrev="Compressing IP/UDP/RTP Headers">Compressing IP/UDP/RTP Headers for Low-Speed Serial Links</title>
<author fullname="Stephen L. Casner" initials="S.L." surname="Casner">
<organization>Cisco Systems, Inc.</organization>

<address>
<postal>
<street>170 West Tasman Drive</street>
<city>San Jose</city>
<region>CA</region>
<code>95134-1706</code>
<country>US</country>
</postal>

<email>casner@cisco.com</email>
</address>
</author>

<author fullname="Van Jacobson" initials="V." surname="Jacobson">
<organization>Cisco Systems, Inc.</organization>

<address>
<postal>
<street>170 West Tasman Drive</street>
<city>San Jose</city>
<region>CA</region>
<code>95134-1706</code>
<country>US</country>
</postal>

<email>van@cisco.com</email>
</address>
</author>

<date year="1999" month="February" />

<abstract>
<t>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.</t>

<t>Comments are solicited and should be addressed to the working group
mailing list rem-conf@es.net and/or the author(s).</t>

<t>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.</t>
</abstract>
</front>

<seriesInfo value="2508" name="RFC" />
</reference>


<reference target2="reference.RFC.2509.xml" anchor="RFC2509">
<front>
<title>IP Header Compression over PPP</title>
<author fullname="Mathias Engan" initials="M." surname="Engan">
<organization>Effnet</organization>

<address>
<postal>
<street>Aurorum 2</street>
<city>Lulea</city>
<code>SE-977 75</code>
<country>SE</country>
</postal>

<phone>+46 92 075600</phone>
<facsimile>+46 92 075610</facsimile>
<email>engan@effnet.com</email>
</address>
</author>

<author fullname="Stephen L. Casner" initials="S." surname="Casner">
<organization>Cisco Systems, Inc.</organization>

<address>
<postal>
<street>170 West Tasman Drive</street>
<city>San Jose</city>
<region>CA</region>
<code>95134-1706</code>
<country>US</country>
</postal>

<email>casner@cisco.com</email>
</address>
</author>

<author fullname="Carsten Bormann" initials="C." surname="Bormann">
<organization>Universitaet Bremen FB3 TZI</organization>

<address>
<postal>
<street>Postfach 330440</street>
<city>Bremen</city>
<code>D-28334</code>
<country>DE</country>
</postal>

<phone>+49 421 2187024</phone>
<facsimile>+49 421 2187000</facsimile>
<email>cabo@tzi.org</email>
</address>
</author>

<date year="1999" month="February" />

<abstract>
<t>This document describes an option for negotiating the use of header compression on IP datagrams transmitted over the. It defines extensions to the PPP Control Protocols for IPv4 and IPv6,. Header compression may be applied to IPv4 and IPv6 datagrams in combination with TCP, UDP and RTP transport protocols as specified inand.</t>
</abstract>
</front>

<seriesInfo value="2509" name="RFC" />
</reference>


<reference target2="reference.RFC.2510.xml" anchor="RFC2510">
<front>
<title abbrev="PKI Certificate Management Protocols">Internet X.509 Public Key Infrastructure Certificate Management Protocols</title>
<author fullname="Carlisle Adams" initials="C." surname="Adams">
<organization>Entrust Technologies</organization>

<address>
<postal>
<street>750 Heron Road</street>
<street>Suite E08</street>
<city>Ottawa</city>
<region>Ontario</region>
<code>K1V 1A7</code>
<country>CA</country>
</postal>

<email>cadams@entrust.com</email>
</address>
</author>

<author fullname="Stephen Farrell" initials="S." surname="Farrell">
<organization>Software and Systems Engineering Ltd.</organization>

<address>
<postal>
<street>Fitzwilliam Court</street>
<street>Leeson Close</street>
<city>Dublin</city>
<region />
<code>2</code>
<country>IE</country>
</postal>

<email>stephen.farrell@sse.ie</email>
</address>
</author>

<date year="1999" month="March" />

<abstract>
<t>This document describes the Internet X.509 Public Key Infrastructure (PKI) Certificate Management Protocols. Protocol messages are defined for all relevant aspects of certificate creation and management. Note that "certificate" in this document refers to an X.509v3 Certificate as defined in,</t>

<t>The key words "MUST", "MUST NOT", "REQUIRED", "SHOULD", "SHOULD NOT",  "RECOMMENDED", "MAY", and "OPTIONAL" in this document (in uppercase, as shown) are to be interpreted as described in.</t>
</abstract>
</front>

<seriesInfo value="2510" name="RFC" />
</reference>


<reference target2="reference.RFC.2511.xml" anchor="RFC2511">
<front>
<title abbrev="Internet X.509 CRMF">Internet X.509 Certificate Request Message Format</title>
<author fullname="Michael Myers" initials="M." surname="Myers">
<organization>VeriSign, Inc.</organization>

<address>
<postal>
<street>1390 Shorebird Way</street>
<city>Mountain View</city>
<region>CA</region>
<code>94019</code>
<country>US</country>
</postal>

<email>mmyers@verisign.com</email>
</address>
</author>

<author fullname="Carlisle Adams" initials="C." surname="Adams">
<organization>Entrust Technologies</organization>

<address>
<postal>
<street>750 Heron Road</street>
<street>Suite E08</street>
<city>Ottawa</city>
<region>Ontario</region>
<code>K1V 1A7</code>
<country>CA</country>
</postal>

<email>cadams@entrust.com</email>
</address>
</author>

<author fullname="Dave Solo" initials="D." surname="Solo">
<organization>Citicorp</organization>

<address>
<postal>
<street>666 Fifth Ave</street>
<street>3rd Floor</street>
<city>New York</city>
<region>NY</region>
<code>10103</code>
<country>US</country>
</postal>

<email>david.solo@citicorp.com</email>
</address>
</author>

<author fullname="David Kemp" initials="D." surname="Kemp">
<organization>National Security Agency</organization>

<address>
<postal>
<street>Suite 6734</street>
<street>9800 Savage Road</street>
<city>Fort Meade</city>
<region>MD</region>
<code>20755</code>
<country>US</country>
</postal>

<email>dpkemp@missi.ncsc.mil</email>
</address>
</author>

<date year="1999" month="March" />

<abstract>
<t>This document describes the Certificate Request Message Format
(CRMF).
This syntax is used to convey a request for a certificate to
a Certification Authority (CA) (possibly via a Registration Authority
(RA)) for the purposes of X.509 certificate production.
The request
will typically include a public key and associated registration
information.</t>

<t>The key words "MUST", "REQUIRED", "SHOULD", "RECOMMENDED", and "MAY"
in this document (in uppercase, as shown) are to be interpreted as
described in RFC 2119.</t>
</abstract>
</front>

<seriesInfo value="2511" name="RFC" />
</reference>


<reference target2="reference.RFC.2512.xml" anchor="RFC2512">
<front>
<title>Accounting Information for ATM Networks</title>
<author fullname="Keith McCloghrie" initials="K." surname="McCloghrie">
<organization>Cisco Systems, Inc.</organization>

<address>
<postal>
<street>170 West Tasman Drive</street>
<city>San Jose</city>
<region>CA</region>
<code>95134</code>
<country>US</country>
</postal>

<phone>+1 408 526 5260</phone>
<email>kzm@cisco.com</email>
</address>
</author>

<author fullname="Juha Heinanen" initials="J." surname="Heinanen">
<organization>Telia Finland, Inc</organization>

<address>
<postal>
<street>Myyrmaentie 2</street>
<city>Vantaa</city>
<code>01600</code>
<country>FI</country>
</postal>

<phone>+358 3 03944808</phone>
<email>jh@telia.fi</email>
</address>
</author>

<author fullname="Wedge Greene" initials="W." surname="Greene">
<organization>MCI Telecommunications Corporation</organization>

<address>
<postal>
<street>901 International Parkway</street>
<city>Richardson</city>
<region>TX</region>
<code>75081</code>
<country>US</country>
</postal>

<phone>+1 214 498 1232</phone>
<email>wedge.greene@mci.com</email>
</address>
</author>

<author fullname="Anil Prasad" initials="A." surname="Prasad">
<organization>Cisco Systems, Inc.</organization>

<address>
<postal>
<street>170 West Tasman Drive</street>
<city>San Jose</city>
<region>CA</region>
<code>95134</code>
<country>US</country>
</postal>

<phone>+1 408 525 7209</phone>
<email>aprasad@cisco.com</email>
</address>
</author>

<date year="1999" month="February" />
</front>

<seriesInfo value="2512" name="RFC" />
</reference>


<reference target2="reference.RFC.2513.xml" anchor="RFC2513">
<front>
<title abbrev="Connection-Oriented Accounting MIB">Managed Objects for Controlling the Collection and Storage of Accounting Information for Connection-Oriented Networks</title>
<author fullname="Keith McCloghrie" initials="K." surname="McCloghrie">
<organization>Cisco Systems, Inc.</organization>

<address>
<postal>
<street>170 West Tasman Drive</street>
<city>San Jose</city>
<region>CA</region>
<code>95134</code>
<country>US</country>
</postal>

<phone>+1 408 526 5260</phone>
<email>kzm@cisco.com</email>
</address>
</author>

<author fullname="Juha Heinanen" initials="J." surname="Heinanen">
<organization>Telia Finland, Inc</organization>

<address>
<postal>
<street>Myyrmaentie 2</street>
<city>Vantaa</city>
<code>01600</code>
<country>FI</country>
</postal>

<phone>+358 3 03944808</phone>
<email>jh@telia.fi</email>
</address>
</author>

<author fullname="Wedge Greene" initials="W." surname="Greene">
<organization>MCI Telecommunications Corporation</organization>

<address>
<postal>
<street>901 International Parkway</street>
<city>Richardson</city>
<region>TX</region>
<code>75081</code>
<country>US</country>
</postal>

<phone>+1 214 498 1232</phone>
<email>wedge.greene@mci.com</email>
</address>
</author>

<author fullname="Anil Prasad" initials="A." surname="Prasad">
<organization>Cisco Systems, Inc.</organization>

<address>
<postal>
<street>170 West Tasman Drive</street>
<city>San Jose</city>
<region>CA</region>
<code>95134</code>
<country>US</country>
</postal>

<phone>+1 408 525 7209</phone>
<email>aprasad@cisco.com</email>
</address>
</author>

<date year="1999" month="February" />
</front>

<seriesInfo value="2513" name="RFC" />
</reference>


<reference target2="reference.RFC.2514.xml" anchor="RFC2514">
<front>
<title abbrev="ATM TCs and OBJECT-IDENTITIES">Definitions of Textual Conventions and OBJECT-IDENTITIES for ATM Management</title>
<author fullname="Michael Noto" initials="M." surname="Noto">
<organization>3Com Corporation</organization>

<address>
<postal>
<street>5400 Bayfront Plaza</street>
<street>M/S 3109</street>
<city>Santa Clara</city>
<region>CA</region>
<code>95052</code>
<country>US</country>
</postal>

<phone>+1 408 326 2218</phone>
<email>mike_noto@3com.com</email>
</address>
</author>

<author fullname="Ethan Mickey Spiegel" initials="E.M." surname="Spiegel">
<organization>Cisco Systems</organization>

<address>
<postal>
<street>170 West Tasman Drive</street>
<city>San Jose</city>
<region>CA</region>
<code>95134</code>
<country>US</country>
</postal>

<phone>+1 408 526 6408</phone>
<email>mspiegel@cisco.com</email>
</address>
</author>

<author fullname="Kaj Tesink" initials="K." surname="Tesink">
<organization>Bellcore</organization>

<address>
<postal>
<street>331 Newman Springs Road</street>
<street>POB 7020</street>
<city>Red Bank</city>
<region>NJ</region>
<code>07701-7020</code>
<country>US</country>
</postal>

<phone>+1 732 758 5254</phone>
<email>kaj@bellcore.com</email>
</address>
</author>

<date year="1999" month="February" />

<abstract>
<t>This memo describes Textual Conventions and
OBJECT-IDENTITIES used 
for managing ATM-based interfaces, devices, networks and
services.</t>
</abstract>
</front>

<seriesInfo value="2514" name="RFC" />
</reference>


<reference target2="reference.RFC.2515.xml" anchor="RFC2515">
<front>
<title abbrev="ATM Management Objects">Definitions of Managed Objects for ATM Management</title>
<author fullname="Kaj Tesink" initials="K." surname="Tesink">
<organization>Bellcore</organization>

<address>
<postal>
<street>331 Newman Springs Road</street>
<street>POB 7020</street>
<city>Red Bank</city>
<region>NJ</region>
<code>07701-7020</code>
<country>US</country>
</postal>

<phone>+1 732 758 5254</phone>
<email>kaj@bellcore.com</email>
</address>
</author>

<date year="1999" month="February" />

<abstract>
<t>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.</t>

<t>This memo replacesRFC 1695.
Changes relative to RFC 1695 are
summarized in the MIB module's REVISION clause.</t>

<t>Textual Conventions used in this MIB are defined inand.</t>
</abstract>
</front>

<seriesInfo value="2515" name="RFC" />
</reference>


<reference target2="reference.RFC.2516.xml" anchor="RFC2516">
<front>
<title abbrev="Transmitting PPP Over Ethernet">A Method for Transmitting PPP Over Ethernet (PPPoE)</title>
<author fullname="Louis Mamakos" initials="L." surname="Mamakos">
<organization>UUNET Technologies, Inc.</organization>

<address>
<postal>
<street>3060 Williams Drive</street>
<city>Fairfax</city>
<region>VA</region>
<code>22031-4648</code>
<country>US</country>
</postal>

<email>louie@uu.net</email>
</address>
</author>

<author fullname="Kurt Lidl" initials="K." surname="Lidl">
<organization>UUNET Technologies, Inc.</organization>

<address>
<postal>
<street>3060 Williams Drive</street>
<city>Fairfax</city>
<region>VA</region>
<code>22031-4648</code>
<country>US</country>
</postal>

<email>lidl@uu.net</email>
</address>
</author>

<author fullname="Jeff Evarts" initials="J." surname="Evarts">
<organization>UUNET Technologies, Inc.</organization>

<address>
<postal>
<street>3060 Williams Drive</street>
<city>Fairfax</city>
<region>VA</region>
<code>22031-4648</code>
<country>US</country>
</postal>

<email>jde@uu.net</email>
</address>
</author>

<author fullname="David Carrel" initials="D." surname="Carrel">
<organization>RedBack Networks, Inc.</organization>

<address>
<postal>
<street>1389 Moffett Park Drive</street>
<city>Sunnyvale</city>
<region>CA</region>
<code>94089-1134</code>
<country>US</country>
</postal>

<email>carrel@RedBack.net</email>
</address>
</author>

<author fullname="Dan Simone" initials="D." surname="Simone">
<organization>RedBack Networks, Inc.</organization>

<address>
<postal>
<street>1389 Moffett Park Drive</street>
<city>Sunnyvale</city>
<region>CA</region>
<code>94089-1134</code>
<country>US</country>
</postal>

<email>dan@RedBack.net</email>
</address>
</author>

<author fullname="Ross Wheeler" initials="R." surname="Wheeler">
<organization>RouterWare, Inc.</organization>

<address>
<postal>
<street>3961 MacArthur Boulevard</street>
<street>Suite 212</street>
<city>Newport Beach</city>
<region>CA</region>
<code>92660</code>
<country>US</country>
</postal>

<email>ross@routerware.com</email>
</address>
</author>

<date year="1999" month="February" />

<abstract>
<t>ThePoint-to-Point Protocol (PPP)provides a
standard method for 
transporting multi-protocol datagrams over point-to-point links.</t>

<t>This document describes how to build PPP sessions and encapsulate PPP
packets over Ethernet.</t>
</abstract>
</front>

<seriesInfo value="2516" name="RFC" />
</reference>


<reference target2="reference.RFC.2517.xml" anchor="RFC2517">
<front>
<title abbrev="Building Directories from DNS">Building Directories from DNS: Experiences from WWWSeeker</title>
<author fullname="Ryan Moats" initials="R." surname="Moats">
<organization>AT&amp;T</organization>

<address>
<postal>
<street>15621 Drexel Circle</street>
<city>Omaha</city>
<region>NE</region>
<code>68135-2358</code>
<country>US</country>
</postal>

<email>jayhawk@att.com</email>
</address>
</author>

<author fullname="Rick Huber" initials="R." surname="Huber">
<organization>AT&amp;T</organization>

<address>
<postal>
<street>200 Laurel Avenue South</street>
<street>Room C3-3B30</street>
<city>Middletown</city>
<region>NJ</region>
<code>07748</code>
<country>US</country>
</postal>

<email>rvh@att.c</email>
</address>
</author>

<date year="1999" month="February" />

<abstract>
<t>There has been much discussion and several documents written about
the need for an Internet Directory.
Recently, this discussion has
focused on ways to discover an organization's domain name without
relying on use of DNS as a directory service.
This memo discusses
lessons that were learned during InterNIC Directory and Database
Services' development and operation of WWWSeeker, an application that
finds a web site given information about the name and location of an
organization.
The back end database that drives this application was
built from information obtained from domain registries via WHOIS and
other protocols.
We present this information to help future
implementors avoid some of the blind alleys that we have already
explored.
This work builds on the Netfind system that was created by
Mike Schwartz and his team at the University of Colorado at Boulder.</t>
</abstract>
</front>

<seriesInfo value="2517" name="RFC" />
</reference>


<reference target2="reference.RFC.2518.xml" anchor="RFC2518">
<front>
<title abbrev="WEBDAV">HTTP Extensions for Distributed Authoring -- WEBDAV</title>
<author fullname="Y. Y. Goland" initials="Y." surname="Goland">
<organization abbrev="Microsoft">Microsoft Corporation</organization>

<address>
<postal>
<street>One Microsoft Way</street>
<city>Redmond</city>
<region>WA</region>
<code>98052-6399</code>
</postal>

<email>yarong@microsoft.com</email>
</address>
</author>

<author fullname="E. J. Whitehead, Jr." initials="E." surname="Whitehead">
<organization abbrev="UC Irvine">Dept. Of Information and Computer Science,
	   University of California, Irvine</organization>

<address>
<postal>
<street />
<city>Irvine</city>
<region>CA</region>
<code>92697-3425</code>
</postal>

<email>ejw@ics.uci.edu</email>
</address>
</author>

<author fullname="A. Faizi" initials="A." surname="Faizi">
<organization abbrev="Netscape">Netscape</organization>

<address>
<postal>
<street>685 East Middlefield Road</street>
<city>Mountain View</city>
<region>CA</region>
<code>94043</code>
</postal>

<email>asad@netscape.com</email>
</address>
</author>

<author fullname="S. R. Carter" initials="S.R." surname="Carter">
<organization abbrev="Novell">Novell</organization>

<address>
<postal>
<street>1555 N. Technology Way</street>
<street>M/S ORM F111</street>
<city>Orem</city>
<region>UT</region>
<code>84097-2399</code>
</postal>

<email>srcarter@novell.com</email>
</address>
</author>

<author fullname="D. Jensen" initials="D." surname="Jensen">
<organization abbrev="Novell">Novell</organization>

<address>
<postal>
<street>1555 N. Technology Way</street>
<street>M/S ORM F111</street>
<city>Orem</city>
<region>UT</region>
<code>84097-2399</code>
</postal>

<email>dcjensen@novell.com</email>
</address>
</author>

<date year="1999" month="February" />

<abstract>
<t>This document specifies a set of methods, headers, and content-types
   ancillary to HTTP/1.1 for the management of resource properties,
   creation and management of resource collections, namespace
   manipulation, and resource locking (collision avoidance).</t>
</abstract>
</front>

<seriesInfo value="2518" name="RFC" />
<format octets="248688" type="HTML" target="http://xml.resource.org/public/rfc/html/rfc2518.html" />
<format octets="214987" type="XML" target="http://xml.resource.org/public/rfc/xml/rfc2518.xml" />
</reference>


<reference target2="reference.RFC.2519.xml" anchor="RFC2519">
<front>
<title abbrev="Inter-Domain Route Aggregation">A Framework for Inter-Domain Route Aggregation</title>
<author fullname="Enke Chen" initials="E." surname="Chen">
<organization>Cisco Systems</organization>

<address>
<postal>
<street>170 West Tasman Drive</street>
<city>San Jose</city>
<region>CA</region>
<code>95134-1706</code>
<country>US</country>
</postal>

<phone>+1 408 527 4652</phone>
<email>enkechen@cisco.com</email>
</address>
</author>

<author fullname="John W. Stewart, III" initials="J." surname="Stewart">
<organization>Juniper Networks, Inc.</organization>

<address>
<postal>
<street>385 Ravendale Drive</street>
<city>Mountain View</city>
<region>CA</region>
<code>94043</code>
<country>US</country>
</postal>

<phone>+1 650 526 8000</phone>
<email>jstewart@juniper.net</email>
</address>
</author>

<date year="1999" month="February" />

<abstract>
<t>This document presents a framework for inter-domain route
aggregation
and shows an example router configuration which 'implements' this
framework.
This framework is flexible and scales well as it
emphasizes the philosophy of aggregation by the source, both within
routing domains as well as towards upstream providers, and it also
strongly encourages the use of the 'no-export' BGP community to
balance the provider-subscriber need for more granular routing
information with the Internet's need for scalable inter-domain
routing.</t>
</abstract>
</front>

<seriesInfo value="2519" name="RFC" />
</reference>


<reference target2="reference.RFC.2520.xml" anchor="RFC2520">
<front>
<title>NHRP with Mobile NHCs</title>
<author fullname="James V. Luciani" initials="J.V." surname="Luciani">
<organization>Nortel Networks</organization>

<address>
<postal>
<street>3 Federal Street</street>
<street>Mail Stop: BL3-03</street>
<city>Billerica</city>
<region>MA</region>
<code>01821</code>
<country>US</country>
</postal>

<phone>+1 978 916 4734</phone>
<email>luciani@baynetworks.com</email>
</address>
</author>

<author fullname="Hiroshi Suzuki" initials="H." surname="Suzuki">
<organization>Cisco Systems</organization>

<address>
<postal>
<street>170 West Tasman Dr.</street>
<city>San Jose</city>
<region>CA</region>
<code>96134</code>
<country>US</country>
</postal>

<phone>+1 408 525 6006</phone>
<email>hsuzuki@cisco.com</email>
</address>
</author>

<author fullname="Naganand Doraswamy" initials="N." surname="Doraswamy">
<organization>Nortel Networks</organization>

<address>
<postal>
<street>3 Federal Street</street>
<street>Mail Stop: BL3-03</street>
<city>Billerica</city>
<region>MA</region>
<code>01821</code>
<country>US</country>
</postal>

<phone>+1 978 916 4734</phone>
<email>naganand@baynetworks.com</email>
</address>
</author>

<author fullname="David Horton" initials="D." surname="Horton">
<organization>CiTR PTY Ltd</organization>

<address>
<postal>
<street>Level 2 North Tower</street>
<street>339 Coronation Drive</street>
<city>Milton</city>
<region></region>
<code>4064</code>
<country>AU</country>
</postal>

<phone>+61 7 32592222</phone>
<email>d.horton@citr.com.au</email>
</address>
</author>

<date year="1999" month="February" />

<abstract>
<t>This document describes an extension to NHRPwhich would allow Mobile NHCs to perform a registration with and attach to an NHS in their home LIS in an authenticated manner.</t>

<t>As described in this document, Mobile NHCs are NHCs which are not configured with enough information to find a specific serving NHS in their home LIS, but which have a mechanism to find an NHS (which may or may not be a serving NHS) to which they will attach.  As described in, an NHC may attach to a 'surrogate' NHS by using a mechanism such as an anycast address.  In this case, the NHC may use the surrogate NHS to send a NHRP Registration Request toward the NHC's home LIS where a serving NHS resides.  However, as defined in, packet authentication is performed on a hop by hop basis.  In the mobile NHC case, it is not practical for the mobile NHC be in a security relationship with every surrogate NHS, thus it is presumably desirable to have some form of end to end only authentication for the case of a mobile NHC's registration.  This document describes an authentication extension for NHRP which has such end to end only semantics.</t>
</abstract>
</front>

<seriesInfo value="2520" name="RFC" />
</reference>


<reference target2="reference.RFC.2521.xml" anchor="RFC2521">
<front>
<title abbrev="ICMP Security Failures">ICMP Security Failures Messages</title>
<author fullname="Phil Karn" initials="P." surname="Karn">
<organization>Qualcomm, Inc.</organization>

<address>
<postal>
<street>6455 Lusk Boulevard</street>
<city>San Diego</city>
<region>CA</region>
<code>92121-2779</code>
<country>US</country>
</postal>

<email>karn@unix.ka9q.ampr.org</email>
</address>
</author>

<author fullname="William Allen Simpson" initials="W." surname="Simpson">
<organization>DayDreamer</organization>

<address>
<postal>
<street>Computer Systems Consulting Services</street>
<street>1384 Fontaine</street>
<city>Madison Heights</city>
<region>MI</region>
<code>48071</code>
<country>US</country>
</postal>

<email>wsimpson@GreenDragon.com</email>
</address>
</author>

<date year="1999" month="March" />

<abstract>
<t>This document specifies ICMP messages for indicating
failures when using IP Security Protocols (AH and ESP).</t>
</abstract>
</front>

<seriesInfo value="2521" name="RFC" />
</reference>


<reference target2="reference.RFC.2522.xml" anchor="RFC2522">
<front>
<title abbrev="Photuris Protocol">Photuris: Session-Key Management Protocol</title>
<author fullname="Phil Karn" initials="P." surname="Karn">
<organization>Qualcomm, Inc.</organization>

<address>
<postal>
<street>6455 Lusk Boulevard</street>
<city>San Diego</city>
<region>CA</region>
<code>92121-2779</code>
<country>US</country>
</postal>

<email>karn@unix.ka9q.ampr.org</email>
</address>
</author>

<author fullname="William Allen Simpson" initials="W.A." surname="Simpson">
<organization>DayDreamer</organization>

<address>
<postal>
<street>Computer Systems Consulting Services</street>
<street>1384 Fontaine</street>
<city>Madison Heights</city>
<region>MI</region>
<code>48071</code>
<country>US</country>
</postal>

<email>wsimpson@GreenDragon.com</email>
</address>
</author>

<date year="1999" month="March" />

<abstract>
<t>Photuris is a session-key management protocol intended for use with the IP Security Protocols (AH and ESP). This document defines the basic protocol mechanisms.</t>
</abstract>
</front>

<seriesInfo value="2522" name="RFC" />
</reference>


<reference target2="reference.RFC.2523.xml" anchor="RFC2523">
<front>
<title abbrev="Schemes and Attributes">Photuris: Extended Schemes and Attributes</title>
<author fullname="Phil Karn" initials="P." surname="Karn">
<organization>Qualcomm, Inc.</organization>

<address>
<postal>
<street>6455 Lusk Boulevard.</street>
<city>San Diego</city>
<region>CA</region>
<code>92121-2779</code>
<country>US</country>
</postal>

<email>karn@unix.ka9q.ampr.org</email>
</address>
</author>

<author fullname="William Allen Simpson" initials="W." surname="Simpson">
<organization>DayDreamer</organization>

<address>
<postal>
<street>Computer Systems Consulting Services</street>
<street>1384 Fontaine</street>
<city>Madison Heights</city>
<region>MI</region>
<code>48071</code>
<country>US</country>
</postal>

<email>wsimpson@GreenDragon.com</email>
</address>
</author>

<date year="1999" month="March" />

<abstract>
<t>Photuris is a session-key management protocol.
Extensible Exchange-Schemes are provided to enable future
implementation changes without
affecting the basic protocol.</t>

<t>Additional authentication attributes are included for use with the IP
Authentication Header (AH) or the IP Encapsulating Security Protocol
(ESP).</t>

<t>Additional confidentiality attributes are included for use with
ESP.</t>
</abstract>
</front>

<seriesInfo value="2523" name="RFC" />
</reference>


<reference target2="reference.RFC.2524.xml" anchor="RFC2524">
<front>
<title abbrev="EMSD">Neda's Efficient Mail Submission and Delivery (EMSD) Protocol Specification Version 1.3</title>
<author fullname="Mohsen Banan" initials="M." surname="Banan">
<organization>Neda Communications, Inc.</organization>

<address>
<postal>
<street>17005 SE 31st Place</street>
<city>Bellevue</city>
<region>WA</region>
<code>98008</code>
<country>US</country>
</postal>

<email>mohsen@neda.com</email>
</address>
</author>

<date year="1999" month="February" />

<abstract>
<t>This document specifies the protocol and format encodings for Efficient Mail Submission and Delivery (EMSD). EMSD is a messaging protocol that is highly optimized for submission and delivery of short Internet mail messages. EMSD is designed to be a companion to existing Internet mail protocols.</t>

<t>This specification narrowly focuses on submission and delivery of short mail messages with a clear emphasis on efficiency. EMSD is designed specifically with wireless network (e.g., CDPD, Wireless-IP, Mobile-IP) usage in mind. EMSD is designed to be a natural enhancement to the mainstream of Internet mail protocols when efficiency in mail submission and mail delivery are important. As such, EMSD is anticipated to become an initial basis for convergence of Internet Mail and IP-based Two-Way Paging.</t>

<t>The reliability requirement for message submission and message delivery in EMSD are the same as existing email protocols. EMSD protocol accomplishes reliable connectionless mail submission and delivery services on top of Efficient Short Remote Operations (ESRO) protocols as specified in.</t>

<t>Most existing Internet mail protocols are not efficient.  Most existing Internet mail protocols are designed with simplicity and continuity with SMTP traditions as two primary requirements.  EMSD is designed with efficiency as a primary requirement.</t>

<t>The early use of EMSD in the wireless environment is manifested as IP-based Two-Way Paging services.  The efficiency of this protocol also presents significant benefits for large centrally operated Internet mail service providers.</t>
</abstract>
</front>

<seriesInfo value="2524" name="RFC" />
</reference>


<reference target2="reference.RFC.2525.xml" anchor="RFC2525">
<front>
<title abbrev="TCP Implementation Problems">Known TCP Implementation Problems</title>
<author fullname="Vern Paxson" initials="V." surname="Paxson">
<organization>ACIRI / ICSI</organization>

<address>
<postal>
<street>1947 Center Street</street>
<street>Suite 600</street>
<city>Berkeley</city>
<region>CA</region>
<code>94704-1198</code>
<country>US</country>
</postal>

<phone>+1 510 642 4274 x302</phone>
<email>vern@aciri.org</email>
</address>
</author>

<author fullname="Scott Dawson" initials="S." surname="Dawson">
<organization>University of Michigan</organization>

<address>
<postal>
<street>Real-Time Computing Laboratory</street>
<street>EECS Building</street>
<city>Ann Arbor</city>
<region>MI</region>
<code>48109-2122</code>
<country>US</country>
</postal>

<phone>+1 313 763 5363</phone>
<email>sdawson@eecs.umich.edu</email>
</address>
</author>

<author fullname="William C. Fenner" initials="W." surname="Fenner">
<organization>Xerox PARC</organization>

<address>
<postal>
<street>3333 Coyote Hill Road</street>
<city>Palo Alto</city>
<region>CA</region>
<code>94304</code>
<country>US</country>
</postal>

<phone>+1 650 812 4816</phone>
<email>fenner@parc.xerox.com</email>
</address>
</author>

<author fullname="Jim Griner" initials="J." surname="Griner">
<organization>NASA Glenn Research Center</organization>

<address>
<postal>
<street>Lewis Field</street>
<street>21000 Brookpark Road</street>
<street>MS 54-2</street>
<city>Cleveland</city>
<region>OH</region>
<code>44135</code>
<country>US</country>
</postal>

<phone>+1 216 433 5787</phone>
<email>jgriner@grc.nasa.gov</email>
</address>
</author>

<author fullname="Ian Heavens" initials="I." surname="Heavens">
<organization>Spider Software Ltd.</organization>

<address>
<postal>
<street>8 John's Place</street>
<street>Leith</street>
<city>Edinburgh</city>
<region>Scotland</region>
<code>EH6 7EL</code>
<country>UK</country>
</postal>

<phone>+44 131 4757015</phone>
<email>ian@spider.com</email>
</address>
</author>

<author fullname="Kevin Lahey" initials="K." surname="Lahey">
<organization>NASA Ames Research Center/MRJ</organization>

<address>
<postal>
<street>MS 258-6</street>
<city>Moffett Field</city>
<region>CA</region>
<code>94035</code>
<country>US</country>
</postal>

<phone>+1 650 604 4334</phone>
<email>kml@nas.nasa.gov</email>
</address>
</author>

<author fullname="Jeff Semke" initials="J." surname="Semke">
<organization>Pittsburgh Supercomputing Center</organization>

<address>
<postal>
<street>4400 Fifth Ave</street>
<city>Pittsburgh</city>
<region>PA</region>
<code>15213</code>
<country>US</country>
</postal>

<phone>+1 412 268 4960</phone>
<email>semke@psc.edu</email>
</address>
</author>

<author fullname="Bernie Volz" initials="B." surname="Volz">
<organization>Process Software Corporation</organization>

<address>
<postal>
<street>959 Concord Street</street>
<city>Framingham</city>
<region>MA</region>
<code>01701</code>
<country>US</country>
</postal>

<phone>+1 508 879 6994</phone>
<email>volz@process.com</email>
</address>
</author>

<date year="1999" month="March" />
</front>

<seriesInfo value="2525" name="RFC" />
</reference>


<reference target2="reference.RFC.2526.xml" anchor="RFC2526">
<front>
<title>Reserved IPv6 Subnet Anycast Addresses</title>
<author fullname="David B. Johnson" initials="D." surname="Johnson">
<organization>Carnegie Mellon University</organization>

<address>
<postal>
<street>Computer Science Department</street>
<street>5000 Forbes Avenue</street>
<city>Pittsburgh</city>
<region>PA</region>
<code>15213-3891</code>
<country>US</country>
</postal>

<phone>+1 412 268 7399</phone>
<facsimile>+1 412 268 5576</facsimile>
<email>dbj@cs.cmu.edu</email>
</address>
</author>

<author fullname="Stephen E. Deering" initials="S." surname="Deering">
<organization>Cisco Systems, Inc.</organization>

<address>
<postal>
<street>170 West Tasman Drive</street>
<city>San Jose</city>
<region>CA</region>
<code>95134-1706</code>
<country>US</country>
</postal>

<phone>+1 408 527 8213</phone>
<facsimile>+1 408 527 8254</facsimile>
<email>deering@cisco.com</email>
</address>
</author>

<date year="1999" month="March" />

<abstract>
<t>The IP Version 6 addressing architecture defines an 'anycast' address as an IPv6 address that is assigned to one or more network interfaces (typically belonging to different nodes), with the property that a packet sent to an anycast address is routed to the 'nearest' interface having that address, according to the routing protocols' measure of distance. This document defines a set of reserved anycast addresses within each subnet prefix, and lists the initial allocation of these reserved subnet anycast addresses.</t>
</abstract>
</front>

<seriesInfo value="2526" name="RFC" />
</reference>


<reference target2="reference.RFC.2527.xml" anchor="RFC2527">
<front>
<title abbrev="PKIX">Internet X.509 Public Key Infrastructure Certificate Policy and Certification Practices Framework</title>
<author fullname="Santosh  Chokhani" initials="S." surname="Chokhani">
<organization>CygnaCom Solutions, Inc.</organization>

<address>
<postal>
<street>Suite 100 West</street>
<street>7927 Jones Branch Drive</street>
<city>McLean</city>
<region>VA</region>
<code>22102</code>
<country>US</country>
</postal>

<phone>+1 703 848 0883</phone>
<facsimile>+1 703 848 0960</facsimile>
<email>chokhani@cygnacom.com</email>
</address>
</author>

<author fullname="Warwick  Ford" initials="W." surname="Ford">
<organization>VeriSign, Inc.</organization>

<address>
<postal>
<street>301 Edgewater Place</street>
<street>Suite 210</street>
<city>Wakefield</city>
<region>MA</region>
<code>01880</code>
<country>US</country>
</postal>

<phone>+1 781 245 6996 x225</phone>
<facsimile>+1 781 245 6006</facsimile>
<email>wford@verisign.com</email>
</address>
</author>

<date year="1999" month="March" />

<abstract>
<t>This document presents a framework to assist the writers of
certificate policies or certification practice statements for
certification authorities and public key infrastructures.
In particular, the framework provides a comprehensive list of topics
that potentially (at the writer's discretion) need to be covered in a
certificate policy definition or a certification practice
statement.</t>
</abstract>
</front>

<seriesInfo value="2527" name="RFC" />
</reference>


<reference target2="reference.RFC.2528.xml" anchor="RFC2528">
<front>
<title abbrev="PKIX KEA">Internet X.509 Public Key Infrastructure Representation of Key Exchange Algorithm (KEA) Keys in Internet X.509 Public Key Infrastructure Certificates</title>
<author fullname="Russell Housley" initials="R." surname="Housley">
<organization>SPYRUS</organization>

<address>
<postal>
<street>381 Elden Street</street>
<street>Suite 1120</street>
<city>Herndon</city>
<region>VA</region>
<code>20170</code>
<country>US</country>
</postal>

<email>housley@spyrus.com</email>
</address>
</author>

<author fullname="Tim Polk" initials="T." surname="Polk">
<organization>NIST</organization>

<address>
<postal>
<street>Building 820</street>
<street>Room 426</street>
<city>Gaithersburg</city>
<region>MD</region>
<code>20899</code>
<country>US</country>
</postal>

<email>wpolk@nist.gov</email>
</address>
</author>

<date year="1999" month="March" />

<abstract>
<t>The Key Exchange Algorithm (KEA) is a classified algorithm for exchanging keys.  This specification profiles the format and semantics of fields in X.509 V3 certificates containing KEA keys. The specification addresses the subjectPublicKeyInfo field and the keyUsage extension.</t>
</abstract>
</front>

<seriesInfo value="2528" name="RFC" />
</reference>


<reference target2="reference.RFC.2529.xml" anchor="RFC2529">
<front>
<title abbrev="Transmission of IPv6 Packets over IPv4">Transmission of IPv6 over IPv4 Domains without Explicit Tunnels</title>
<author fullname="Brian E. Carpenter" initials="B." surname="Carpenter">
<organization>IBM United Kingdom Laboratories</organization>

<address>
<postal>
<street>Internet Division</street>
<street>MP 185</street>
<street>Hursley Park</street>
<city>Winchester</city>
<region>England</region>
<code>S021 2JN</code>
<country>UK</country>
</postal>

<email>brian@hursley.ibm.com</email>
</address>
</author>

<author fullname="Cyndi Jung" initials="C." surname="Jung">
<organization>3Com Corporation</organization>

<address>
<postal>
<street>5400 Bayfront Plaza</street>
<street>Mailstop 3219</street>
<city>Santa Clara</city>
<region>CA</region>
<code>95052-8145</code>
<country>US</country>
</postal>

<email>cmj@3Com.com</email>
</address>
</author>

<date year="1999" month="March" />

<abstract>
<t>This memo specifies the frame format for transmission ofIPv6packets 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
multicast network.</t>

<t>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'.</t>
</abstract>
</front>

<seriesInfo value="2529" name="RFC" />
</reference>


<reference target2="reference.RFC.2530.xml" anchor="RFC2530">
<front>
<title abbrev="Media Features using DSN and MDN">Indicating Supported Media Features Using Extensions to DSN and MDN</title>
<author fullname="Dan Wing" initials="D." surname="Wing">
<organization>Cisco Systems, Inc.</organization>

<address>
<postal>
<street>101 Cooper Street</street>
<city>Santa Cruz</city>
<region>CA</region>
<code>95060</code>
<country>US</country>
</postal>

<phone>+1 831 457 5200</phone>
<facsimile>+1 831 457 5208</facsimile>
<email>dwing@cisco.com</email>
</address>
</author>

<date year="1999" month="March" />

<abstract>
<t>There is a need in Internet mail and Internet fax for a recipient to indicate the media features it supports so that messages can be generated by senders without exceeding the recipient's abilities.</t>

<t>This memo describes a format for generating Message Disposition Notificationsand Delivery Status Notificationswhich contain such information.  This information can be used by senders to avoid exceeding the recipient's capabilities when sending subsequent messages.</t>
</abstract>
</front>

<seriesInfo value="2530" name="RFC" />
</reference>


<reference target2="reference.RFC.2531.xml" anchor="RFC2531">
<front>
<title>Content Feature Schema for Internet Fax</title>
<author fullname="Graham Klyne" initials="G." surname="Klyne">
<organization>5th Generation Messaging Ltd. Content Technologies Ltd.</organization>

<address>
<postal>
<street>5 Watlington Street</street>
<street>Nettlebed</street>
<street>Henley-on-Thames</street>
<region>England</region>
<code>RG9 5AB</code>
<country>UK</country>
</postal>

<phone>+44 1491 641641</phone>
<facsimile>+44 1491 641611</facsimile>
<email>GK@ACM.ORG</email>
</address>
</author>

<author fullname="Lloyd McIntyre" initials="L." surname="McIntyre">
<organization>Xerox Corporation</organization>

<address>
<postal>
<street>3400 Hillview Ave.</street>
<street>Mailstop PAHV-12</street>
<city>Palo Alto</city>
<region>CA</region>
<code>94304</code>
<country>US</country>
</postal>

<phone>+1 650 813 6762</phone>
<facsimile>+1 650 845 2340</facsimile>
<email>Lloyd.McIntyre@pahv.xerox.com</email>
</address>
</author>

<date year="1999" month="March" />

<abstract>
<t>This document defines a content feature schema that is a profile of the media feature registration mechanisms,,for use in performing capability identification between extended Internet fax systems.</t>

<t>This document does not describe any specific mechanisms for communicating capability information, but does presume that any such mechanisms will transfer textual values.  It specifies a textual format to be used for describing Internet fax capability information.</t>
</abstract>
</front>

<seriesInfo value="2531" name="RFC" />
</reference>


<reference target2="reference.RFC.2532.xml" anchor="RFC2532">
<front>
<title abbrev="Extended Internet Fax">Extended Facsimile Using Internet Mail</title>
<author fullname="Larry Masinter" initials="L." surname="Masinter">
<organization>Xerox Palo Alto Research Center</organization>

<address>
<postal>
<street>3333 Coyote Hill Road</street>
<city>Palo Alto</city>
<region>CA</region>
<code>94304</code>
<country>US</country>
</postal>

<facsimile>+1 650 812 4333</facsimile>
<email>masinter@parc.xerox.com</email>
</address>
</author>

<author fullname="Dan Wing" initials="D." surname="Wing">
<organization>Cisco Systems, Inc.</organization>

<address>
<postal>
<street>101 Cooper Street</street>
<city>Santa Cruz</city>
<region>CA</region>
<code>95060</code>
<country>US</country>
</postal>

<phone>+1 831 457 5200</phone>
<facsimile>+1 831 457 5208</facsimile>
<email>dwing@cisco.com</email>
</address>
</author>

<date year="1999" month="March" />

<abstract>
<t>This document describes extensions to "Simple Mode of Facsimile Using Internet Mail"and describes additional features, including transmission of enhanced document characteristics (higher resolution, color) and confirmation of delivery and processing.</t>

<t>These additional features are designed to provide the highest level of interoperability with the existing and future standards-compliant email infrastructure and mail user agents, while providing a level of service that approximates the level currently enjoyed by fax users.</t>

<t>The IETF has been notified of intellectual property rights claimed in regard to some or all of the specification contained in this document.  For more information consult the online list of claimed rights in http://www.ietf.org/ipr.html.</t>
</abstract>
</front>

<seriesInfo value="2532" name="RFC" />
</reference>


<reference target2="reference.RFC.2533.xml" anchor="RFC2533">
<front>
<title>A Syntax for Describing Media Feature Sets</title>
<author fullname="Graham Klyne" initials="G." surname="Klyne">
<organization>Content Technologies Ltd.</organization>

<address>
<postal>
<street>Forum 1</street>
<street>Station Road</street>
<city>Theale</city>
<region>Reading</region>
<code>RG7 4RA</code>
<country>UK</country>
</postal>

<phone>+44 118 9301300</phone>
<facsimile>+44 118 9301301</facsimile>
<email>GK@ACM.ORG</email>
</address>
</author>

<date year="1999" month="March" />

<abstract>
<t>A number of Internet application protocols have a need to provide content negotiation for the resources with which they interact. A framework for such negotiation is described in, part of which 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 feature registration are presented in.</t>

<t>This document introduces and describes a 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.</t>
</abstract>
</front>

<seriesInfo value="2533" name="RFC" />
</reference>


<reference target2="reference.RFC.2534.xml" anchor="RFC2534">
<front>
<title>Media Features for Display, Print, and Fax</title>
<author fullname="Larry Masinter" initials="L." surname="Masinter">
<organization>Xerox Corporation, Palo Alto Research Center</organization>

<address>
<postal>
<street>3333 Coyote Hill Road</street>
<city>Palo Alto</city>
<region>CA</region>
<code>94304</code>
<country>US</country>
</postal>

<facsimile>+1 650 812 4333</facsimile>
<email>masinter@parc.xerox.com</email>
</address>
</author>

<author fullname="Dan Wing" initials="D." surname="Wing">
<organization>Cisco Systems, Inc.</organization>

<address>
<postal>
<street>101 Cooper Street</street>
<city>Santa Cruz</city>
<region>CA</region>
<code>95060</code>
<country>US</country>
</postal>

<phone>+1 831 457 5200</phone>
<facsimile>+1 831 457 5208</facsimile>
<email>dwing@cisco.com</email>
</address>
</author>

<author fullname="Andrew H. Mutz" initials="A." surname="Mutz">
<organization>Jutvision Corporation</organization>

<address>
<postal>
<street>124 University Avenue</street>
<street>Suite 202</street>
<city>Palo Alto</city>
<region>CA</region>
<code>94301</code>
<country>US</country>
</postal>

<phone>+1 650 325 6787</phone>
<facsimile>+1 650 325 9337</facsimile>
<email>mutz@alum.mit.edu</email>
</address>
</author>

<author fullname="Koen Holtman" initials="K." surname="Holtman">
<organization>Technische Universiteit Eindhoven</organization>

<address>
<postal>
<street>Postbus 513</street>
<street>Kamer HG 6.57</street>
<street>5600 MB Eindhoven</street>
<country>NL</country>
</postal>

<email>koen@win.tue.nl</email>
</address>
</author>

<date year="1999" month="March" />

<abstract>
<t>This specification defines some common media features for describing image resolution, size, color, and image representation methods that are common to web browsing, printing, and facsimile applications. These features are registered for use within the framework of.</t>
</abstract>
</front>

<seriesInfo value="2534" name="RFC" />
</reference>


<reference target2="reference.RFC.2535.xml" anchor="RFC2535">
<front>
<title abbrev="DNS Security Extensions">Domain Name System Security Extensions</title>
<author fullname="Donald E. Eastlake 3rd" initials="D." surname="Eastlake">
<organization>IBM</organization>

<address>
<postal>
<street>65 Shindegan Hill Road</street>
<street>RR #1</street>
<city>Carmel</city>
<region>NY</region>
<code>10512</code>
<country>US</country>
</postal>

<phone>+1 914 784 7913</phone>
<facsimile>+1 914 784 3833</facsimile>
<email>dee3@us.ibm.com</email>
</address>
</author>

<date year="1999" month="March" />

<abstract>
<t>Extensions to the Domain Name System (DNS) are described that provide data integrity and authentication to security aware resolvers and applications through the use of cryptographic digital signatures. These digital signatures are included in secured zones as resource records.  Security can also be provided through non-security aware DNS servers in some cases.</t>

<t>The extensions provide for the storage of authenticated public keys in the DNS.  This storage of keys can support general public key distribution services as well as DNS security.  The stored keys enable security aware resolvers to learn the authenticating key of zones in addition to those for which they are initially configured. Keys associated with DNS names can be retrieved to support other protocols.  Provision is made for a variety of key types and algorithms.</t>

<t>In addition, the security extensions provide for the optional authentication of DNS protocol transactions and requests.</t>

<t>This document incorporates feedback on RFC 2065 from early implementers and potential users.</t>
</abstract>
</front>

<seriesInfo value="2535" name="RFC" />
</reference>


<reference target2="reference.RFC.2536.xml" anchor="RFC2536">
<front>
<title abbrev="DSA in the DNS">DSA KEYs and SIGs in the Domain Name System (DNS)</title>
<author fullname="Donald E. Eastlake 3rd" initials="D.E." surname="Eastlake">
<organization>IBM</organization>

<address>
<postal>
<street>65 Shindegan Hill Road</street>
<street>RR #1</street>
<city>Carmel</city>
<region>NY</region>
<code>10512</code>
<country>US</country>
</postal>

<phone>+1 914 276 2668</phone>
<facsimile>+1 914 784 3833</facsimile>
<email>dee3@us.ibm.com</email>
</address>
</author>

<date year="1999" month="March" />

<abstract>
<t>A standard method for storing US Government Digital Signature Algorithm keys and signatures in the Domain Name System is described which utilizes DNS KEY and SIG resource records.</t>
</abstract>
</front>

<seriesInfo value="2536" name="RFC" />
</reference>


<reference target2="reference.RFC.2537.xml" anchor="RFC2537">
<front>
<title abbrev="RSA/MD5 KEYs and SIGs in the DNS">RSA/MD5 KEYs and SIGs in the Domain Name System (DNS)</title>
<author fullname="Donald E. Eastlake 3rd" initials="D.E." surname="Eastlake">
<organization>IBM</organization>

<address>
<postal>
<street>65 Shindegan Hill Road</street>
<street>RR #1</street>
<city>Carmel</city>
<region>NY</region>
<code>10512</code>
<country>US</country>
</postal>

<phone>+1 914 276 2668</phone>
<facsimile>+1 914 784 3833</facsimile>
<email>dee3@us.ibm.com</email>
</address>
</author>

<date year="1999" month="March" />

<abstract>
<t>A standard method for storing RSA keys and and RSA/MD5 based signatures in the Domain Name System is described which utilizes DNS KEY and SIG resource records.</t>
</abstract>
</front>

<seriesInfo value="2537" name="RFC" />
</reference>


<reference target2="reference.RFC.2538.xml" anchor="RFC2538">
<front>
<title abbrev="Storing Certificates in the DNS">Storing Certificates in the Domain Name System (DNS)</title>
<author fullname="Donald E. Eastlake 3rd" initials="D.E." surname="Eastlake">
<organization>IBM</organization>

<address>
<postal>
<street>65 Shindegan Hill Road</street>
<street>RR#1</street>
<city>Carmel</city>
<region>NY</region>
<code>10512</code>
<country>US</country>
</postal>

<phone>+1 914 784 7913</phone>
<facsimile>+1 914 784 3833</facsimile>
<email>dee3@us.ibm.com</email>
</address>
</author>

<author fullname="Olafur Gudmundsson" initials="O." surname="Gudmundsson">
<organization>TIS Labs at Network Associates</organization>

<address>
<postal>
<street>3060 Washington Rd</street>
<street>Route 97</street>
<city>Glenwood</city>
<region>MD</region>
<code>21738</code>
<country>US</country>
</postal>

<phone>+1 443 259 2389</phone>
<email>ogud@tislabs.com</email>
</address>
</author>

<date year="1999" month="March" />

<abstract>
<t>Cryptographic public key are frequently published and their authenticity demonstrated by certificates.  A CERT resource record (RR) is defined so that such certificates and related certificate revocation lists can be stored in the Domain Name System (DNS).</t>
</abstract>
</front>

<seriesInfo value="2538" name="RFC" />
</reference>


<reference target2="reference.RFC.2539.xml" anchor="RFC2539">
<front>
<title abbrev="Diffie-Hellman Keys in the DNS">Storage of Diffie-Hellman Keys in the Domain Name System (DNS)</title>
<author fullname="Donald E. Eastlake 3rd" initials="D.E." surname="Eastlake">
<organization>IBM</organization>

<address>
<postal>
<street>65 Shindegan Hill Road</street>
<street>RR #1</street>
<city>Carmel</city>
<region>NY</region>
<code>10512</code>
<country>US</country>
</postal>

<phone>+1 914 276 2668</phone>
<facsimile>+1 914 784 3833</facsimile>
<email>dee3@us.ibm.com</email>
</address>
</author>

<date year="1999" month="March" />

<abstract>
<t>A standard method for storing Diffie-Hellman keys in the Domain Name System is described which utilizes DNS KEY resource records.</t>
</abstract>
</front>

<seriesInfo value="2539" name="RFC" />
</reference>


<reference target2="reference.RFC.2540.xml" anchor="RFC2540">
<front>
<title abbrev="Detached DNS Information">Detached Domain Name System (DNS) Information</title>
<author fullname="Donald E. Eastlake 3rd" initials="D.E." surname="Eastlake">
<organization>IBM</organization>

<address>
<postal>
<street>65 Shindegan Hill Road</street>
<street>RR #1</street>
<city>Carmel</city>
<region>NY</region>
<code>10512</code>
<country>US</country>
</postal>

<phone>+1 914 276 2668</phone>
<facsimile>+1 914 784 3833</facsimile>
<email>dee3@us.ibm.com</email>
</address>
</author>

<date year="1999" month="March" />

<abstract>
<t>A standard format is defined for representing detached DNS information.  This is anticipated to be of use for storing information retrieved from the Domain Name System (DNS), including security information, in archival contexts or contexts not connected to the Internet.</t>
</abstract>
</front>

<seriesInfo value="2540" name="RFC" />
</reference>


<reference target2="reference.RFC.2541.xml" anchor="RFC2541">
<front>
<title>DNS Security Operational Considerations</title>
<author fullname="Donald E. Eastlake 3rd" initials="D.E." surname="Eastlake">
<organization>IBM</organization>

<address>
<postal>
<street>65 Shindegan Hill Road</street>
<street>RR #1</street>
<city>Carmel</city>
<region>NY</region>
<code>10512</code>
<country>US</country>
</postal>

<phone>+1 914 276 2668</phone>
<facsimile>+1 914 784 3833</facsimile>
<email>dee3@us.ibm.com</email>
</address>
</author>

<date year="1999" month="March" />

<abstract>
<t>Secure DNS is based on cryptographic techniques.  A necessary part of the strength of these techniques is careful attention to the operational aspects of key and signature generation, lifetime, size, and storage.  In addition, special attention must be paid to the security of the high level zones, particularly the root zone.  This document discusses these operational aspects for keys and signatures used in connection with the KEY and SIG DNS resource records.</t>
</abstract>
</front>

<seriesInfo value="2541" name="RFC" />
</reference>


<reference target2="reference.RFC.2542.xml" anchor="RFC2542">
<front>
<title>Terminology and Goals for Internet Fax</title>
<author fullname="Larry Masinter" initials="L." surname="Masinter">
<organization>Xerox Corporation</organization>

<address>
<postal>
<street>3333 Coyote Hill Road</street>
<city>Palo Alto</city>
<region>CA</region>
<code>94304</code>
<country>US</country>
</postal>

<facsimile>+1 650 812 4333</facsimile>
<email>masinter@parc.xerox.com</email>
<uri>http://www.parc.xerox.com/masinter/</uri>
</address>
</author>

<date year="1999" month="March" />

<abstract>
<t>This document defines a number of terms useful for the discussion of Internet Fax. In addition, it describes the goals of the Internet Fax working group and establishes a baseline of desired functionality against which protocols for Internet Fax can be judged. It encompasses the goals for all modes of facsimile delivery, including 'real-time', 'session', and 'store and forward'.  Different levels of desirability are indicated throughout the document.</t>
</abstract>
</front>

<seriesInfo value="2542" name="RFC" />
</reference>


<reference target2="reference.RFC.2543.xml" anchor="RFC2543">
<front>
<title>SIP: Session Initiation Protocol</title>
<author fullname="Mark Handley" initials="M." surname="Handley">
<organization>AT&amp;T Center for Internet Research at ISCI (ACIRI)</organization>

<address>
<postal>
<street>1947 Center St.</street>
<street>Suite 600</street>
<city>Berkeley</city>
<region>CA</region>
<code>94704-119</code>
<country>US</country>
</postal>

<email>mjh@aciri.org</email>
</address>
</author>

<author fullname="Henning Schulzrinne" initials="H." surname="Schulzrinne">
<organization>Dept. of Computer Science, Columbia University</organization>

<address>
<postal>
<street>1214 Amsterdam Avenue</street>
<city>New York</city>
<region>NY</region>
<code>10027</code>
<country>US</country>
</postal>

<email>schulzrinne@cs.columbia.edu</email>
</address>
</author>

<author fullname="Eve Schooler" initials="E." surname="Schooler">
<organization>California Institute of Technology</organization>

<address>
<postal>
<street>Computer Science Department 256-80</street>
<city>Pasadena</city>
<region>CA</region>
<code>91125</code>
<country>US</country>
</postal>

<email>schooler@cs.caltech.edu</email>
</address>
</author>

<author fullname="Jonathan Rosenberg" initials="J." surname="Rosenberg">
<organization>Lucent Technologies, Bell Laboratories</organization>

<address>
<postal>
<street>101 Crawfords Corner Road</street>
<street>Rm. 4C-526</street>
<city>Holmdel</city>
<region>NJ</region>
<code>07733</code>
<country>US</country>
</postal>

<email>jdrosen@bell-labs.com</email>
</address>
</author>

<date year="1999" month="March" />

<abstract>
<t>The Session Initiation Protocol (SIP) is an application-layer control (signaling) protocol for creating, modifying and terminating sessions with one or more participants. These sessions include Internet multimedia conferences, Internet telephone calls and multimedia distribution. Members in a session can communicate via multicast or via a mesh of unicast relations, or a combination of these.</t>

<t>SIP invitations used to create sessions carry session descriptions which allow participants to agree on a set of compatible media types. SIP supports user mobility by proxying and redirecting requests to the user's current location. Users can register their current location.  SIP is not tied to any particular conference control protocol. SIP is designed to be independent of the lower-layer transport protocol and can be extended with additional capabilities.</t>
</abstract>
</front>

<seriesInfo value="2543" name="RFC" />
</reference>


<reference target2="reference.RFC.2544.xml" anchor="RFC2544">
<front>
<title abbrev="Benchmarking Methodology">Benchmarking Methodology for Network Interconnect Devices</title>
<author fullname="Scott Bradner" initials="S." surname="Bradner">
<organization>Harvard University</organization>

<address>
<postal>
<street>1350 Mass. Ave</street>
<street>Room 813</street>
<city>Cambridge</city>
<region>MA</region>
<code>02138</code>
<country>US</country>
</postal>

<phone>+1 617 495 3864</phone>
<facsimile>+1 617 496 8500</facsimile>
<email>sob@harvard.edu</email>
</address>
</author>

<author fullname="Jim McQuaid" initials="J." surname="McQuaid">
<organization>NetScout Systems</organization>

<address>
<postal>
<street>4 Westford Tech Park Drive</street>
<city>Westford</city>
<region>MA</region>
<code>01886</code>
<country>US</country>
</postal>

<phone>+1 978 614 4116</phone>
<facsimile>+1 978 614 4004</facsimile>
<email>mcquaidj@netscout.com</email>
</address>
</author>

<date year="1999" month="March" />

<abstract>
<t>This document discusses and defines a number of tests that may be used to describe the performance characteristics of a network interconnecting  device.  In addition to defining the tests this document also describes specific formats for reporting the results of the tests.  Appendix A lists the tests and conditions that we believe should be included for specific cases and gives additional information about testing practices.  Appendix B is a reference listing of maximum frame rates to be used with specific frame sizes on various media and Appendix C gives some examples of frame formats to be used in testing.</t>
</abstract>
</front>

<seriesInfo value="2544" name="RFC" />
</reference>


<reference target2="reference.RFC.2545.xml" anchor="RFC2545">
<front>
<title abbrev="BGP-4 Multiprotocol Extensions for IPv6 IDR">Use of BGP-4 Multiprotocol Extensions for IPv6 Inter-Domain Routing</title>
<author fullname="Pedro R. Marques" initials="P." surname="Marques">
<organization>cisco Systems, Inc.</organization>

<address>
<postal>
<street>170 W. Tasman Dr.</street>
<city>San Jose</city>
<region>CA</region>
<code>95134</code>
<country>US</country>
</postal>

<phone>+1 408 527 5202</phone>
<facsimile>+1 408 526 4952</facsimile>
<email>roque@cisco.com</email>
</address>
</author>

<author fullname="Francis Dupont" initials="F." surname="Dupont">
<organization>GIE DYADE</organization>

<address>
<postal>
<street>INRIA Rocquencourt</street>
<street>Domaine de Voluceau</street>
<street>BP 105</street>
<street>78153 Le Chesnay CEDEX</street>
<country>FR</country>
</postal>

<phone>+33 1 39635213</phone>
<facsimile>+33 1 39635866</facsimile>
<email>Francis.Dupont@inria.fr</email>
</address>
</author>

<date year="1999" month="March" />

<abstract>
<t>BGP-4 Multiprotocol Extensionsdefines the format of two BGP attributes (MP_REACH_NLRI and MP_UNREACH_NLRI) that can be used to announce and withdraw the announcement of reachability information. This document defines how compliant systems should make use of those attributes for the purpose of conveying IPv6 routing information.</t>
</abstract>
</front>

<seriesInfo value="2545" name="RFC" />
</reference>


<reference target2="reference.RFC.2546.xml" anchor="RFC2546">
<front>
<title>6Bone Routing Practice</title>
<author fullname="Alain Durand" initials="A." surname="Durand">
<organization>Institut d'Informatique et de Mathematiques Appliquees de Grenoble</organization>

<address>
<postal>
<street>IMAG BP 53</street>
<street>38041 Grenoble CEDEX 9</street>
<country>FR</country>
</postal>

<phone>+33 4 76635703</phone>
<facsimile>+33 4 76514964</facsimile>
<email>Alain.Durand@imag.fr</email>
</address>
</author>

<author fullname="Bertrand Buclin" initials="B." surname="Buclin">
<organization>AT&amp;T International S.A.</organization>

<address>
<postal>
<street>Route de l'aeroport 31</street>
<street>CP 72</street>
<street>CH-1215 Geneve 15</street>
<country>CH</country>
</postal>

<phone>+41 22 9293740</phone>
<facsimile>+41 22 9293984</facsimile>
<email>Bertrand.Buclin@ch.att.com</email>
</address>
</author>

<date year="1999" month="March" />
</front>

<seriesInfo value="2546" name="RFC" />
</reference>


<reference target2="reference.RFC.2547.xml" anchor="RFC2547">
<front>
<title>BGP/MPLS VPNs</title>
<author fullname="Eric C. Rosen" initials="E." surname="Rosen">
<organization>Cisco Systems, Inc.</organization>

<address>
<postal>
<street>250 Apollo Drive</street>
<city>Chelmsford</city>
<region>MA</region>
<code>01824</code>
<country>US</country>
</postal>

<email>erosen@cisco.com</email>
</address>
</author>

<author fullname="Yakov Rekhter" initials="Y." surname="Rekhter">
<organization>Cisco Systems, Inc.</organization>

<address>
<postal>
<street>170 Tasman Drive</street>
<city>San Jose</city>
<region>CA</region>
<code>95134</code>
<country>US</country>
</postal>

<email>yakov@cisco.com</email>
</address>
</author>

<date year="1999" month="March" />

<abstract>
<t>This document describes a method by which a Service Provider with an IP backbone may provide VPNs (Virtual Private Networks) for its customers.  MPLS (Multiprotocol Label Switching) is used for forwarding packets over the backbone, and BGP (Border Gateway Protocol) is used for distributing routes over the backbone.  The primary goal of this method is to support the outsourcing of IP backbone services for enterprise networks. It does so in a manner which is simple for the enterprise, while still scalable and flexible for the Service Provider, and while allowing the Service Provider to add value. These techniques can also be used to provide a VPN which itself provides IP service to customers.</t>
</abstract>
</front>

<seriesInfo value="2547" name="RFC" />
</reference>


<reference target2="reference.RFC.2548.xml" anchor="RFC2548">
<front>
<title>Microsoft Vendor-specific RADIUS Attributes</title>
<author fullname="Glen Zorn" initials="G." surname="Zorn">
<organization>Microsoft Corporation</organization>

<address>
<postal>
<street>One Microsoft Way</street>
<city>Redmond</city>
<region>WA</region>
<code>98052</code>
<country>US</country>
</postal>

<phone>+1 425 703 1559</phone>
<facsimile>+1 425 936 7329</facsimile>
<email>glennz@microsoft.com</email>
</address>
</author>

<date year="1999" month="March" />

<abstract>
<t>This document describes the set of Microsoft vendor-specific RADIUS attributes.  These attributes are designed to support Microsoft proprietary dial-up protocols and/or provide support for features which is not provided by the standard RADIUS attribute set.  It is expected that this memo will be updated whenever Microsoft defines a new vendor-specific attribute, since its primary purpose is to provide an open, easily accessible reference for third-parties wishing to interoperate with Microsoft products.</t>
</abstract>
</front>

<seriesInfo value="2548" name="RFC" />
</reference>


<reference target2="reference.RFC.2549.xml" anchor="RFC2549">
<front>
<title abbrev="IP over Avian Carriers with QoS">IP over Avian Carriers with Quality of Service</title>
<author fullname="David Waitzman" initials="D." surname="Waitzman">
<organization>IronBridge Networks</organization>

<address>
<postal>
<street>55 Hayden Ave</street>
<city>Lexington</city>
<region>MA</region>
<code>02421</code>
<country>US</country>
</postal>

<phone>+1 781 372 8161</phone>
<email>djw@vineyard.net</email>
</address>
</author>

<date year="1999" month="April" day="1" />

<abstract>
<t>This memo amends RFC 1149, "A Standard for the Transmission of IP Datagrams on Avian Carriers", with Quality of Service information. This is an experimental, not recommended standard.</t>
</abstract>
</front>

<seriesInfo value="2549" name="RFC" />
</reference>


<reference target2="reference.RFC.2550.xml" anchor="RFC2550">
<front>
<title>Y10K and Beyond</title>
<author fullname="Steve Glassman" initials="S." surname="Glassman">
<organization>Compaq Systems Research Center</organization>

<address>
<postal>
<street>130 Lytton Avenue</street>
<city>Palo Alto</city>
<region>CA</region>
<code>94301</code>
<country>US</country>
</postal>

<phone>+1 650 853 2166</phone>
<email>steveg@pa.dec.com</email>
</address>
</author>

<author fullname="Mark Manasse" initials="M." surname="Manasse">
<organization>Compaq Systems Research Center</organization>

<address>
<postal>
<street>130 Lytton Avenue</street>
<city>Palo Alto</city>
<region>CA</region>
<code>94301</code>
<country>US</country>
</postal>

<phone>+1 650 853 2221</phone>
<email>msm@pa.dec.com</email>
</address>
</author>

<author fullname="Jeff Mogul" initials="J." surname="Mogul">
<organization>Compaq Western Resarch Lab</organization>

<address>
<postal>
<street>250 University Avenue</street>
<city>Palo Alto</city>
<region>CA</region>
<code>94301</code>
<country>US</country>
</postal>

<phone>+1 650 617 3300</phone>
<email>mogul@pa.dec.com</email>
</address>
</author>

<date year="1999" month="April" day="1" />

<abstract>
<t>As we approach the end of the millennium, much attention has been paid to the so-called "Y2K" problem.  Nearly everyone now regrets the short-sightedness of the programmers of yore who wrote programs designed to fail in the year 2000.  Unfortunately, the current fixes for Y2K lead inevitably to a crisis in the year 10,000 when the programs are again designed to fail.</t>

<t>This specification provides a solution to the "Y10K" problem which has also been called the "YAK" problem (hex) and the "YXK" problem (Roman numerals).</t>
</abstract>
</front>

<seriesInfo value="2550" name="RFC" />
</reference>


<reference target2="reference.RFC.2551.xml" anchor="RFC2551">
<front>
<title>The Roman Standards Process -- Revision III</title>
<author fullname="S. Bradner" initials="S." surname="Bradner">
<organization>Harvard University</organization>

<address>
<postal>
<street>Holyoke Center</street>
<street>Room DCCCXIII</street>
<street>MCCCL Mass. Ave.</street>
<city>Cambridge</city>
<region>MA</region>
<code>MMCXXXVIII</code>
<country>US</country>
</postal>

<phone>+I DCXVII CDXCVXXXVIIILXIV</phone>
<email>sob@harvard.edu</email>
</address>
</author>

<date year="1999" day="1" month="April" />

<abstract>
<t>This memo documents the process used by the Roman community for
 the standardization of protocols and procedures.  It defines the
 stages in the standardization process, the requirements for moving a
 document between stages and the types of documents used during this
 process.  It also addresses the intellectual property rights and
 copyright issues associated with the standards process.</t>
</abstract>
</front>

<seriesInfo value="2551" name="RFC" />
</reference>


<reference target2="reference.RFC.2552.xml" anchor="RFC2552">
<front>
<title abbrev="GAIA">Architecture for the Information Brokerage in the ACTS Project GAIA</title>
<author fullname="Mikhail Blinov" initials="M." surname="Blinov">
<organization>University College Dublin, Computer Science Department</organization>

<address>
<postal>
<street>Belfield</street>
<street>Dublin 4</street>
<country>IE</country>
</postal>

<phone>+353 1 7062488</phone>
<facsimile>+353 1 2697262</facsimile>
<email>mch@net-cs.ucd.ie</email>
</address>
</author>

<author fullname="Mikhail Bessonov" initials="M." surname="Bessonov">
<organization>University College Dublin, Computer Science Department</organization>

<address>
<postal>
<street>Belfield</street>
<street>Dublin 4</street>
<country>IE</country>
</postal>

<phone>+353 1 7062488</phone>
<facsimile>+353 1 2697262</facsimile>
<email>mikeb@net-cs.ucd.ie</email>
</address>
</author>

<author fullname="Ciaran Clissmann" initials="C." surname="Clissmann">
<organization>University College Dublin, Computer Science Department</organization>

<address>
<postal>
<street>Belfield</street>
<street>Dublin 4</street>
<country>IE</country>
</postal>

<phone>+353 1 7062488</phone>
<facsimile>+353 1 2697262</facsimile>
<email>ciaranc@net-cs.ucd.ie</email>
</address>
</author>

<date year="1999" month="April" />

<abstract>
<t>This memo introduces a domain and supplier independent generic architecture for information brokerage, designed as part of the ACTS project GAIA (Generic Architecture for Information Availability).</t>
</abstract>
</front>

<seriesInfo value="2552" name="RFC" />
</reference>


<reference target2="reference.RFC.2553.xml" anchor="RFC2553">
<front>
<title>Basic Socket Interface Extensions for IPv6</title>
<author fullname="Robert E. Gilligan" initials="R." surname="Gilligan">
<organization>FreeGate Corporation</organization>

<address>
<postal>
<street>1208 E. Arques Ave.</street>
<city>Sunnyvale</city>
<region>CA</region>
<code>94086</code>
<country>US</country>
</postal>

<phone>+1 408 617 1004</phone>
<email>gilligan@freegate.com</email>
</address>
</author>

<author fullname="Susan Thomson" initials="S." surname="Thomson">
<organization>Bell Communications Research</organization>

<address>
<postal>
<street>445 South Street</street>
<street>MRE 2P-343</street>
<city>Morristown</city>
<region>NJ</region>
<code>07960</code>
<country>US</country>
</postal>

<phone>+1 201 829 4514</phone>
<email>set@thumper.bellcore.com</email>
</address>
</author>

<author fullname="Jim Bound" initials="J." surname="Bound">
<organization>Compaq Computer Corporation</organization>

<address>
<postal>
<street>110 Spitbrook Road</street>
<street>ZK3-3/U14</street>
<city>Nashua</city>
<region>NH</region>
<code>03062-2698</code>
<country>US</country>
</postal>

<phone>+1 603 884 0400</phone>
<email>bound@zk3.dec.com</email>
</address>
</author>

<author fullname="W. Richard Stevens" initials="W." surname="Stevens">
<organization />

<address>
<postal>
<street>1202 E. Paseo del Zorro</street>
<city>Tucson</city>
<region>AZ</region>
<code>85718-2826</code>
<country>US</country>
</postal>

<phone>+1 520 297 9416</phone>
<email>rstevens@kohala.com</email>
</address>
</author>

<date year="1999" month="March" />

<abstract>
<t>The de facto standard application program interface (API) for TCP/IP applications is the "sockets" interface.  Although this API was developed for Unix in the early 1980s it has also been implemented on a wide variety of non-Unix systems.  TCP/IP applications written using the sockets API have in the past enjoyed a high degree of portability and we would like the same portability with IPv6 applications.  But changes are required to the sockets API to support IPv6 and this memo describes these changes.  These include a new socket address structure to carry IPv6 addresses, new address conversion functions, and some new socket options.  These extensions are designed to provide access to the basic IPv6 features required by TCP and UDP applications, including multicasting, while introducing a minimum of change into the system and providing complete compatibility for existing IPv4 applications.  Additional extensions for advanced IPv6 features (raw sockets and access to the IPv6 extension headers) are defined in another document.</t>
</abstract>
</front>

<seriesInfo value="2553" name="RFC" />
</reference>


<reference target2="reference.RFC.2554.xml" anchor="RFC2554">
<front>
<title abbrev="SMTP Authentication">SMTP Service Extension for Authentication</title>
<author fullname="John Gardiner Myers" initials="J.G." surname="Myers">
<organization>Netscape Communications</organization>

<address>
<postal>
<street>501 East Middlefield Road</street>
<street>Mail Stop MV-029</street>
<city>Mountain View</city>
<region>CA</region>
<code>94043</code>
<country>US</country>
</postal>

<email>jgmyers@netscape.com</email>
</address>
</author>

<date year="1999" month="March" />
</front>

<seriesInfo value="2554" name="RFC" />
</reference>


<reference target2="reference.RFC.2555.xml" anchor="RFC2555">
<front>
<title>30 Years of RFCs</title>
<author fullname="Robert Braden" initials="R." surname="Braden">
<organization>USC/Information Sciences Institute</organization>

<address>
<postal>
<street>4676 Admiralty Way #1001</street>
<city>Marina del Rey</city>
<region>CA</region>
<code>90292</code>
<country>US</country>
</postal>

<phone>+1 310 822 1511</phone>
<facsimile>+1 310 823 6714</facsimile>
<email>braden@isi.edu</email>
</address>
</author>

<author fullname="Joyce K. Reynolds" initials="J.K." surname="Reynolds">
<organization>USC/Information Sciences Institute</organization>

<address>
<postal>
<street>4676 Admiralty Way #1001</street>
<city>Marina del Rey</city>
<region>CA</region>
<code>90292</code>
<country>US</country>
</postal>

<phone>+1 310 822 1511</phone>
<facsimile>+1 310 823 6714</facsimile>
<email>jkrey@isi.edu</email>
</address>
</author>

<author fullname="Steve Crocker" initials="S." surname="Crocker">
<organization>Steve Crocker Associates, LLC</organization>

<address>
<postal>
<street>5110 Edgemoor Lane</street>
<city>Bethesda</city>
<region>MD</region>
<code>20814</code>
<country>US</country>
</postal>

<phone>+1 301 654 4569</phone>
<facsimile>+1 202 478 0458</facsimile>
<email>crocker@mbl.edu</email>
</address>
</author>

<author fullname="Vint Cerf" initials="V." surname="Cerf">
<organization>MCI</organization>

<address>
<email>vcerf@mci.net</email>
</address>
</author>

<author fullname="Jake Feinler" initials="J." surname="Feinler">
<organization>SRI Network Information Center</organization>

<address>
<email>feinler@juno.com</email>
</address>
</author>

<author fullname="Celeste Anderson" initials="C." surname="Anderson">
<organization>USC/Information Sciences Institute</organization>

<address>
<postal>
<street>4676 Admiralty Way #1001</street>
<city>Marina del Rey</city>
<region>CA</region>
<code>90292</code>
<country>US</country>
</postal>

<phone>+1 310 822 1511</phone>
<facsimile>+1 310 823 6714</facsimile>
<email>celeste@isi.edu</email>
</address>
</author>

<date year="1999" month="April" day="7" />
</front>

<seriesInfo value="2555" name="RFC" />
</reference>


<reference target2="reference.RFC.2556.xml" anchor="RFC2556">
<front>
<title abbrev="RFC 1240 to Historic">OSI connectionless transport services on top of UDP Applicability Statement for Historic Status</title>
<author fullname="Scott Bradner" initials="S." surname="Bradner">
<organization>Harvard University</organization>

<address>
<postal>
<street>1350 Mass Ave</street>
<street>rm 876</street>
<city>Cambridge</city>
<region>MA</region>
<code>02138</code>
<country>US</country>
</postal>

<phone>+1 617 495 3864</phone>
<email>sob@harvard.edu</email>
</address>
</author>

<date year="1999" month="March" />

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

<seriesInfo value="2556" name="RFC" />
</reference>


<reference target2="reference.RFC.2557.xml" anchor="RFC2557">
<front>
<title abbrev="MIME Encapsulation of Aggregate Documents">MIME Encapsulation of Aggregate Documents, such as HTML (MHTML)</title>
<author fullname="Jacob Palme" initials="F." surname="Palme">
<organization>Stockholm University and KTH</organization>

<address>
<postal>
<street>Electrum 230</street>
<street>S-164 40 Kista</street>
<country>SE</country>
</postal>

<phone>+46 8 161667</phone>
<facsimile>+46 8 7830829</facsimile>
<email>jpalme@dsv.su.se</email>
</address>
</author>

<author fullname="Alex Hopmann" initials="A." surname="Hopmann">
<organization>Microsoft Corporation</organization>

<address>
<postal>
<street>One Microsoft Way</street>
<city>Redmond</city>
<region>WA</region>
<code>98052</code>
<country>US</country>
</postal>

<phone>+1 425 703 8238</phone>
<email>alexhop@microsoft.com</email>
</address>
</author>

<author fullname="Nick Shelness" initials="N." surname="Shelness">
<organization>Lotus Development Corporation</organization>

<address>
<postal>
<street>55 Cambridge Parkway</street>
<city>Cambridge</city>
<region>MA</region>
<code>02142-1295</code>
<country>US</country>
</postal>

<email>Shelness@lotus.com</email>
</address>
</author>

<author fullname="Einar Stefferud" initials="E." surname="Stefferud">
<organization />

<address>
<email>stef@nma.com</email>
</address>
</author>

<date year="1999" month="March" />

<abstract>
<t>HTMLdefines a powerful means of specifying multimedia documents. These multimedia documents consist of a text/html root resource (object) and other subsidiary resources (image, video clip, applet, etc. objects) referenced by Uniform Resource Identifiers (URIs) within the text/html root resource. When an HTML multimedia document is retrieved by a browser, each of these component resources is individually retrieved in real time from a location, and using a protocol, specified by each URI.</t>

<t>In order to transfer a complete HTML multimedia document in a single e-mail message, it is necessary to: a) aggregate a text/html root resource and all of the subsidiary resources it references into a single composite message structure, and b) define a means by which URIs in the text/html root can reference subsidiary resources within that composite message structure.</t>

<t>This document a) defines the use of a MIME multipart/related structure to aggregate a text/html root resource and the subsidiary resources it references, and b) specifies a MIME content-header (Content-Location) that allow URIs in a multipart/related text/html root body part to reference subsidiary resources in other body parts of the same multipart/related structure.</t>

<t>While initially designed to support e-mail transfer of complete multi-resource HTML multimedia documents, these conventions can also be employed to resources retrieved by other transfer protocols such as HTTP and FTP to retrieve a complete multi-resource HTML multimedia document in a single transfer or for storage and archiving of complete HTML-documents.</t>

<t>Differences between this and a previous version of this standard, which was published as RFC 2110, are summarized in chapter 12.</t>
</abstract>
</front>

<seriesInfo value="2557" name="RFC" />
</reference>


<reference target2="reference.RFC.2558.xml" anchor="RFC2558">
<front>
<title abbrev="SONET/SDH Objects">Definitions of Managed Objects for the SONET/SDH Interface Type</title>
<author fullname="Kaj Tesink" initials="K." surname="Tesink">
<organization>Telcordia Technologies</organization>

<address>
<postal>
<street>331 Newman Springs Road</street>
<street>P.O. Box 7020</street>
<city>Red Bank</city>
<region>NJ</region>
<code>07701-7020</code>
<country>US</country>
</postal>

<phone>+1 732 758 5254</phone>
<email>kaj@research.telcordia.com</email>
</address>
</author>

<date year="1999" month="March" />

<abstract>
<t>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 \\,.</t>
</abstract>
</front>

<seriesInfo value="2558" name="RFC" />
</reference>


<reference target2="reference.RFC.2559.xml" anchor="RFC2559">
<front>
<title abbrev="PKIX Operational Protocols - LDAPv2">Internet X.509 Public Key Infrastructure Operational Protocols - LDAPv2</title>
<author fullname="Sharon Boeyen" initials="S." surname="Boeyen">
<organization>Entrust Technologies Limited</organization>

<address>
<postal>
<street>750 Heron Road</street>
<city>Ottawa</city>
<region>Ontario</region>
<code>K1V 1A7</code>
<country>CA</country>
</postal>

<email>sharon.boeyen@entrust.com</email>
</address>
</author>

<author fullname="Tim Howes" initials="T." surname="Howes">
<organization>Netscape Communications Corp.</organization>

<address>
<postal>
<street>501 E. Middlefield Rd.</street>
<city>Mountain View</city>
<region>CA</region>
<code>94043</code>
<country>US</country>
</postal>

<email>howes@netscape.com</email>
</address>
</author>

<author fullname="Patrick Richard" initials="P." surname="Richard">
<organization>Xcert Software Inc.</organization>

<address>
<postal>
<street>701 W. Georgia Street</street>
<street>Suite 1001</street>
<street>P.O. Box 10145</street>
<street>Pacific Centre</street>
<city>Vancouver</city>
<region>British Columbia</region>
<code>V7Y 1C6</code>
<country>CA</country>
</postal>

<email>patr@xcert.com</email>
</address>
</author>

<date year="1999" month="April" />

<abstract>
<t>The protocol described in this document is designed to satisfy some
   of the operational requirements within the Internet X.509 Public Key
   Infrastructure (IPKI).  Specifically, this document addresses
   requirements to provide access to Public Key Infrastructure (PKI)
   repositories for the purposes of retrieving PKI information and
   managing that same information.  The mechanism described in this
   document is based on the Lightweight Directory Access Protocol (LDAP)
   v2, defined in RFC 1777, defining a profile of that protocol for use
   within the IPKI and updates encodings for certificates and revocation
   lists from RFC 1778. Additional mechanisms addressing PKIX
   operational requirements are specified in separate documents.</t>

<t>The key words 'MUST', 'REQUIRED', 'SHOULD', 'RECOMMENDED', and 'MAY'
   in this document are to be interpreted as described in RFC 2119.</t>
</abstract>
</front>

<seriesInfo value="2559" name="RFC" />
</reference>


<reference target2="reference.RFC.2560.xml" anchor="RFC2560">
<front>
<title abbrev="PKIX OCSP">X.509 Internet Public Key Infrastructure Online Certificate Status Protocol - OCSP</title>
<author fullname="Michael Myers" initials="M." surname="Myers">
<organization>VeriSign, Inc.</organization>

<address>
<postal>
<street>1350 Charleston Road</street>
<city>Mountain View</city>
<region>CA</region>
<code>94043</code>
<country>US</country>
</postal>

<email>mmyers@verisign.com</email>
</address>
</author>

<author fullname="Rich Ankney" initials="R." surname="Ankney">
<organization>CertCo, LLC</organization>

<address>
<postal>
<street>13506 King Charles Dr.</street>
<city>Chantilly</city>
<region>VA</region>
<code>20151</code>
<country>US</country>
</postal>

<email>rankney@erols.com</email>
</address>
</author>

<author fullname="Ambarish Malpani" initials="A." surname="Malpani">
<organization>ValiCert, Inc.</organization>

<address>
<postal>
<street>1215 Terra Bella Avenue</street>
<city>Mountain View</city>
<region>CA</region>
<code>94043</code>
<country>US</country>
</postal>

<phone>+1 650 567 5457</phone>
<email>ambarish@valicert.com</email>
</address>
</author>

<author fullname="Slava Galperin" initials="S." surname="Galperin">
<organization>My CFO, Inc.</organization>

<address>
<postal>
<street>1945 Charleston Road</street>
<city>Mountain View</city>
<region>CA</region>
<code>94043</code>
<country>US</country>
</postal>

<email>galperin@mycfo.com</email>
</address>
</author>

<author fullname="Carlisle Adams" initials="C." surname="Adams">
<organization>Entrust Technologies</organization>

<address>
<postal>
<street>750 Heron Road</street>
<street>Suite E08</street>
<city>Ottawa</city>
<region>Ontario</region>
<code>K1V 1A7</code>
<country>CA</country>
</postal>

<email>cadams@entrust.com</email>
</address>
</author>

<date year="1999" month="June" />

<abstract>
<t>This document specifies a protocol useful in determining the current
   status of a digital certificate without requiring CRLs. Additional
   mechanisms addressing PKIX operational requirements are specified in
   separate documents.</t>

<t>An overview of the protocol is provided in section 2. Functional
   requirements are specified in section 4. Details of the protocol are
   in section 5. We cover security issues with the protocol in section
   6. Appendix A defines OCSP over HTTP, appendix B accumulates ASN.1
   syntactic elements and appendix C specifies the mime types for the
   messages.</t>

<t>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document (in uppercase, as shown) are to be interpreted as described
   in.</t>
</abstract>
</front>

<seriesInfo value="2560" name="RFC" />
</reference>


<reference target2="reference.RFC.2561.xml" anchor="RFC2561">
<front>
<title abbrev="TN3270E Using SMIv2 MIB">Base Definitions of Managed Objects for TN3270E Using SMIv2</title>
<author fullname="Kenneth D. White" initials="K." surname="White">
<organization>IBM Corporation</organization>

<address>
<postal>
<street>3039 Cornwallis</street>
<street>Dept. BRQA/Bldg. 501/G114</street>
<street>P.O.Box 12195</street>
<city>Research Triangle Park</city>
<region>NC</region>
<code>27709</code>
<country>US</country>
</postal>

<email>kennethw@vnet.ibm.com</email>
</address>
</author>

<author fullname="Robert Moore" initials="R." surname="Moore">
<organization>IBM Corporation</organization>

<address>
<postal>
<street>3039 Cornwallis</street>
<street>Dept. BRQA/Bldg. 501/G114</street>
<street>P.O.Box 12195</street>
<city>Research Triangle Park</city>
<region>NC</region>
<code>27709</code>
<country>US</country>
</postal>

<phone>+1 919 254 4436</phone>
<email>remoore@us.ibm.com</email>
</address>
</author>

<date year="1999" month="April" />

<abstract>
<t>This memo defines a Management Information Base (MIB) for configuring and managing TN3270E servers.  TN3270E, defined by RFC 2355refers to the enhancements made to the Telnet 3270terminal emulation practices.  Refer to RFC 1041, STD 8, RFC 854and STD 31, RFC 860for a sample of what is meant by TN3270 practices.</t>

<t>The MIB defined by this memo provides generic support for both host and gateway TN3270E server implementations.  A TN3270E server connects a Telnet client performing 3270 emulation to a target SNA host over both a client-side network (client to TN3270E server) and an SNA Network (TN3270E server to target SNA host).  The client-side network is typically TCP/IP, but it need not be.</t>

<t>A host TN3270E server refers to an implementation where the TN3270E server is collocated with the Systems Network Architecture (SNA) System Services Control Point (SSCP) for the dependent Secondary Logical Units (SLUs) that the server makes available to its clients for connecting into a SNA network.  A gateway TN3270E server resides on an SNA node other than an SSCP, either an SNA type 2.0 node, a boundary-function-attached type 2.1 node, or an APPN node acting in the role of a Dependent LU Requester (DLUR).  Host and gateway TN3270E server implementations typically differ greatly as to their internal implementation and system definition (SYSDEF) methods.</t>

<t>It is the intent that the MIB defined herein be extended by subsequent memos.  For example, one such extension enables collection of TN3270E response time data.</t>
</abstract>
</front>

<seriesInfo value="2561" name="RFC" />
</reference>


<reference target2="reference.RFC.2562.xml" anchor="RFC2562">
<front>
<title abbrev="TN3270E-RT-MIB">Definitions of Protocol and Managed Objects for TN3270E Response Time Collection Using SMIv2 (TN3270E-RT-MIB)</title>
<author fullname="Kenneth D. White" initials="K." surname="White">
<organization>IBM Corporation</organization>

<address>
<postal>
<street>3039 Cornwallis</street>
<street>Dept. BRQA/Bldg. 501/G114</street>
<street>P.O.Box 12195</street>
<city>Research Triangle Park</city>
<region>NC</region>
<code>27709</code>
<country>US</country>
</postal>

<email>kennethw@vnet.ibm.com</email>
</address>
</author>

<author fullname="Robert Moore" initials="R." surname="Moore">
<organization>IBM Corporation</organization>

<address>
<postal>
<street>3039 Cornwallis</street>
<street>Dept. BRQA/Bldg. 501/G114</street>
<street>P.O.Box 12195</street>
<city>Research Triangle Park</city>
<region>NC</region>
<code>27709</code>
<country>US</country>
</postal>

<phone>+1 919 254 7507</phone>
<email>remoore@us.ibm.com</email>
</address>
</author>

<date year="1999" month="April" />

<abstract>
<t>This memo defines the protocol and the Management Information Base (MIB) for performing response time data collection on TN3270 and TN3270E sessions by a TN3270E server.  The response time data collected by a TN3270E server is structured to support both validation of service level agreements and performance monitoring of TN3270 and TN3270E Sessions.  This MIB has as a prerequisite the TN3270E-MIB, reference.</t>

<t>TN3270E, defined by RFC 2355, refers to the enhancements made to  the Telnet 3270 (TN3270) terminal emulation practices.  Refer to RFC 1041 [, STD 8, RFC 854, and STD 31, RFC 860for a sample of what is meant by TN3270 practices.</t>
</abstract>
</front>

<seriesInfo value="2562" name="RFC" />
</reference>


<reference target2="reference.RFC.2563.xml" anchor="RFC2563">
<front>
<title abbrev="DHCP Auto-Configuration Option">DHCP Option to Disable Stateless Auto-Configuration in IPv4 Clients</title>
<author fullname="Ryan Troll" initials="R." surname="Troll">
<organization>@Home Network</organization>

<address>
<postal>
<street>425 Broadway</street>
<city>Redwood City</city>
<region>CA</region>
<code>94063</code>
<country>US</country>
</postal>

<phone>+1 650 556 6031</phone>
<email>rtroll@corp.home.net</email>
</address>
</author>

<date year="1999" month="May" />

<abstract>
<t>Operating Systems are now attempting to support ad-hoc networks of
   two or more systems, while keeping user configuration at a minimum.
   To accommodate this, in the absence of a central configuration
   mechanism (DHCP), some OS's are automatically choosing a link-local
   IP address which will allow them to communicate only with other hosts
   on the same link.  This address will not allow the OS to communicate
   with anything beyond a router.  However, some sites depend on the
   fact that a host with no DHCP response will have no IP address.  This
   document describes a mechanism by which DHCP servers are able to tell
   clients that they do not have an IP address to offer, and that the
   client should not generate an IP address it's own.</t>
</abstract>
</front>

<seriesInfo value="2563" name="RFC" />
</reference>


<reference target2="reference.RFC.2564.xml" anchor="RFC2564">
<front>
<title>Application Management MIB</title>
<author fullname="Carl Kalbfleisch" initials="C." surname="Kalbfleisch">
<organization>Verio, Inc.</organization>

<address>
<postal>
<street>1950 Stemmons Freeway</street>
<street>2004 INFOMART</street>
<city>Dallas</city>
<region>TX</region>
<code>75207</code>
<country>US</country>
</postal>

<phone>+1 972 238 8303</phone>
<facsimile>+1 972 238 0268</facsimile>
<email>cwk@verio.net</email>
</address>
</author>

<author fullname="Cheryl Krupczak" initials="C." surname="Krupczak">
<organization>Empire Technologies, Inc.</organization>

<address>
<postal>
<street>541 Tenth Street NW</street>
<street>Suite 169</street>
<city>Atlanta</city>
<region>GA</region>
<code>30318</code>
<country>US</country>
</postal>

<phone>+1 770 384 0184</phone>
<email>cheryl@empiretech.com</email>
</address>
</author>

<author fullname="Randy Presuhn" initials="R." surname="Presuhn">
<organization>BMC Software, Inc.</organization>

<address>
<postal>
<street>965 Stewart Drive</street>
<city>Sunnyvale</city>
<region>CA</region>
<code>94086</code>
<country>US</country>
</postal>

<phone>+1 408 616 3100</phone>
<facsimile>+1 408 616 3101</facsimile>
<email>randy_presuhn@bmc.com</email>
</address>
</author>

<author fullname="Jon Saperia" initials="J." surname="Saperia">
<organization>IronBridge Networks</organization>

<address>
<postal>
<street>55 Hayden Avenue</street>
<city>Lexington</city>
<region>MA</region>
<code>02173</code>
<country>US</country>
</postal>

<phone>+1 781 402 8029</phone>
<facsimile>+1 781 402 8090</facsimile>
<email>saperia@mediaone.net</email>
</address>
</author>

<date year="1999" month="May" />

<abstract>
<t>This memo defines a standards track 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.</t>
</abstract>
</front>

<seriesInfo value="2564" name="RFC" />
</reference>


<reference target2="reference.RFC.2565.xml" anchor="RFC2565">
<front>
<title abbrev="IPP/1.0: Encoding and Transport">Internet Printing Protocol/1.0: Encoding and Transport</title>
<author fullname="Robert Herriot" initials="R." surname="Herriot">
<organization>Xerox Corporation</organization>

<address>
<postal>
<street>3400 Hillview Ave.</street>
<street>Bldg #1</street>
<city>Palo Alto</city>
<region>CA</region>
<code>94304</code>
<country>US</country>
</postal>

<phone>+1 650 813 7696</phone>
<facsimile>+1 650 813 6860</facsimile>
<email>rherriot@pahv.xerox.com</email>
</address>
</author>

<author fullname="Sylvan Butler" initials="S." surname="Butler">
<organization>Hewlett-Packard</organization>

<address>
<postal>
<street>11311 Chinden Blvd.</street>
<city>Boise</city>
<region>ID</region>
<code>83714</code>
<country>US</country>
</postal>

<phone>+1 208 396 6000</phone>
<facsimile>+1 208 396 3457</facsimile>
<email>sbutler@boi.hp.com</email>
</address>
</author>

<author fullname="Paul Moore" initials="P." surname="Moore">
<organization>Microsoft</organization>

<address>
<postal>
<street>One Microsoft Way</street>
<city>Redmond</city>
<region>WA</region>
<code>98053</code>
<country>US</country>
</postal>

<phone>+1 425 936 0908</phone>
<facsimile>+1 425 936 7329</facsimile>
<email>paulmo@microsoft.com</email>
</address>
</author>

<author fullname="Randy Turner" initials="R." surname="Turner">
<organization>Sharp Laboratories</organization>

<address>
<postal>
<street>5750 NW Pacific Rim Blvd</street>
<city>Camas</city>
<region>WA</region>
<code>98607</code>
<country>US</country>
</postal>

<phone>+1 360 817 8456</phone>
<facsimile>+1 360 817 8436</facsimile>
<email>rturner@sharplabs.com</email>
</address>
</author>

<date year="1999" month="April" />

<abstract>
<t>This document is one of a set of documents, which together describe
   all aspects of a new Internet Printing Protocol (IPP). IPP is an
   application level protocol that can be used for distributed printing
   using Internet tools and technologies. This document defines the
   rules for encoding IPP operations and IPP attributes into a new
   Internet mime media type called "application/ipp".  This document
   also defines the rules for transporting over HTTP a message body
   whose Content-Type is "application/ipp".</t>
</abstract>
</front>

<seriesInfo value="2565" name="RFC" />
</reference>


<reference target2="reference.RFC.2566.xml" anchor="RFC2566">
<front>
<title abbrev="IPP/1.0: Model and Semantics">Internet Printing Protocol/1.0: Model and Semantics</title>
<author fullname="Roger deBry" initials="R." surname="deBry">
<organization>Utah Valley State College</organization>

<address>
<postal>
<street />
<city>Orem</city>
<region>UT</region>
<code>84058</code>
<country>US</country>
</postal>

<phone>+1 801 222 8000</phone>
<email>debryro@uvsc.edu</email>
</address>
</author>

<author fullname="Tom Hastings" initials="T." surname="Hastings">
<organization>Xerox Corporation</organization>

<address>
<postal>
<street>737 Hawaii St.</street>
<city>El Segundo</city>
<region>CA</region>
<code>90245</code>
<country>US</country>
</postal>

<phone>+1 310 333 6413</phone>
<facsimile>+1 310 333 5514</facsimile>
<email>hastings@cp10.es.xerox.com</email>
</address>
</author>

<author fullname="Robert Herriot" initials="R." surname="Herriot">
<organization>Xerox Corporation</organization>

<address>
<postal>
<street>3400 Hillview Ave.</street>
<street>Bldg #1</street>
<city>Palo Alto</city>
<region>CA</region>
<code>94304</code>
<country>US</country>
</postal>

<phone>+1 650 813 7696</phone>
<facsimile>+1 650 813 6860</facsimile>
<email>robert.herriot@pahv.xerox.com</email>
</address>
</author>

<author fullname="Scott A. Isaacson" initials="S.A." surname="Isaacson">
<organization>Novell, Inc.</organization>

<address>
<postal>
<street>122 E 1700 S</street>
<city>Provo</city>
<region>UT</region>
<code>84606</code>
<country>US</country>
</postal>

<phone>+1 801 861 7366</phone>
<facsimile>+1 801 861 2517</facsimile>
<email>sisaacson@novell.com</email>
</address>
</author>

<author fullname="Patrick Powell" initials="P." surname="Powell">
<organization>Astart Technologies</organization>

<address>
<postal>
<street>9475 Chesapeake Dr.</street>
<street>Suite D</street>
<city>San Diego</city>
<region>CA</region>
<code>92123</code>
<country>US</country>
</postal>

<phone>+1 619 874 6543</phone>
<facsimile>+1 619 279 8424</facsimile>
<email>papowell@astart.com</email>
</address>
</author>

<date year="1999" month="April" />

<abstract>
<t>This document is one of a set of documents, which together describe
   all aspects of a new Internet Printing Protocol (IPP).  IPP is an
   application level protocol that can be used for distributed printing
   using Internet tools and technologies.  This document describes a
   simplified model consisting of abstract objects, their attributes,
   and their operations that is independent of encoding and transport.
   The model consists of a Printer and a Job object.  A Job optionally
   supports multiple documents.  IPP 1.0 semantics allow end-users and
   operators to query printer capabilities, submit print jobs, inquire
   about the status of print jobs and printers, and cancel print jobs.
   This document also addresses security, internationalization, and
   directory issues.</t>
</abstract>
</front>

<seriesInfo value="2566" name="RFC" />
</reference>


<reference target2="reference.RFC.2567.xml" anchor="RFC2567">
<front>
<title abbrev="Internet Printing Design Goals">Design Goals for an Internet Printing Protocol</title>
<author fullname="F.D. (Don) Wright" initials="F." surname="Wright">
<organization>Lexmark International</organization>

<address>
<postal>
<street>740 New Circle Rd</street>
<street>C14/035-3</street>
<city>Lexington</city>
<region>KY</region>
<code>40550</code>
<country>US</country>
</postal>

<phone>+1 606 232 4808</phone>
<facsimile>+1 606 232 6740</facsimile>
<email>don@lexmark.com</email>
</address>
</author>

<date year="1999" month="April" />

<abstract>
<t>This document is one of a set of documents, which together describe
   all aspects of a new Internet Printing Protocol (IPP).  IPP is an
   application level protocol that can be used for distributed printing
   using Internet tools and technologies.  This document takes a broad
   look at distributed printing functionality, and it enumerates real-
   life scenarios that help to clarify the features that need to be
   included in a printing protocol for the Internet.  It identifies
   requirements for three types of users: end users, operators, and</t>

<t>administrators.  The design goals document calls out a subset of end
   user requirements that are satisfied in IPP/1.0. Operator and
   administrator requirements are out of scope for version 1.0.</t>
</abstract>
</front>

<seriesInfo value="2567" name="RFC" />
</reference>


<reference target2="reference.RFC.2568.xml" anchor="RFC2568">
<front>
<title abbrev="Rationale for IPP">Rationale for the Structure of the Model and Protocol for the Internet Printing Protocol</title>
<author fullname="Stephen Zilles" initials="S." surname="Zilles">
<organization>Adobe Systems Incorporated</organization>

<address>
<postal>
<street>345 Park Avenue</street>
<street>MailStop W14</street>
<city>San Jose</city>
<region>CA</region>
<code>95110-2704</code>
<country>US</country>
</postal>

<phone>+1 408 536 4766</phone>
<facsimile>+1 408 537 4042</facsimile>
<email>szilles@adobe.com</email>
</address>
</author>

<date year="1999" month="April" />

<abstract>
<t>This document is one of a set of documents, which together describe
   all aspects of a new Internet Printing Protocol (IPP).  IPP is an
   application level protocol that can be used for distributed printing
   using Internet tools and technologies. This document describes IPP
   from a high level view, defines a roadmap for the various documents
   that form the suite of IPP specifications, and gives background and
   rationale for the IETF working group's major decisions.</t>
</abstract>
</front>

<seriesInfo value="2568" name="RFC" />
</reference>


<reference target2="reference.RFC.2569.xml" anchor="RFC2569">
<front>
<title>Mapping between LPD and IPP Protocols</title>
<author fullname="Robert Herriot" initials="R." surname="Herriot">
<organization>Xerox Corporation</organization>

<address>
<postal>
<street>3400 Hillview Ave.</street>
<street>Bldg #1</street>
<city>Palo Alto</city>
<region>CA</region>
<code>94304</code>
<country>US</country>
</postal>

<phone>+1 650 813 7696</phone>
<facsimile>+1 650 813 6860</facsimile>
<email>rherriot@pahv.xerox.com</email>
</address>
</author>

<author fullname="Norm Jacobs" initials="N." surname="Jacobs">
<organization>Sun Microsystems Inc.</organization>

<address>
<postal>
<street>1430 Owl Ridge Rd.</street>
<city>Colorado Springs</city>
<region>CO</region>
<code>80919</code>
<country>US</country>
</postal>

<phone>+1 719 532 9927</phone>
<facsimile>+1 719 535 0956</facsimile>
<email>Norm.Jacobs@Central.sun.com</email>
</address>
</author>

<author fullname="Thomas N. Hastings" initials="T." surname="Hastings">
<organization>Xerox Corporation</organization>

<address>
<postal>
<street>701 S. Aviation Blvd.</street>
<street>ESAE-231</street>
<city>El Segundo</city>
<region>CA</region>
<code>90245</code>
<country>US</country>
</postal>

<phone>+1 310 333 6413</phone>
<facsimile>+1 310 333 5514</facsimile>
<email>hastings@cp10.es.xerox.com</email>
</address>
</author>

<author fullname="Jay Martin" initials="J." surname="Martin">
<organization>Underscore, Inc.</organization>

<address>
<postal>
<street>41-C Sagamore Park Road</street>
<city>Hudson</city>
<region>NH</region>
<code>03051-4915</code>
<country>US</country>
</postal>

<phone>+1 603 889 7000</phone>
<facsimile>+1 603 889 2699</facsimile>
<email>jkm@underscore.com</email>
</address>
</author>

<date year="1999" month="April" />

<abstract>
<t>This document is one of a set of documents, which together describe
   all aspects of a new Internet Printing Protocol (IPP). IPP is an
   application level protocol that can be used for distributed printing
   using Internet tools and technologies. This document gives some
   advice to implementers of gateways between IPP and LPD (Line Printer
   Daemon). This document describes the mapping between (1) the commands
   and operands of the 'Line Printer Daemon (LPD) Protocol' specified in
   RFC 1179 and (2) the operations, operation attributes and job
   template attributes of the Internet Printing Protocol/1.0 (IPP).  One
   of the purposes of this document is to compare the functionality of
   the two protocols.  Another purpose is to facilitate implementation
   of gateways between LPD and IPP.</t>

<t>WARNING: RFC 1179 was not on the IETF standards track.  While RFC
   1179 was intended to record existing practice, it fell short in some
   areas.  However, this specification maps between (1) the actual
   current practice of RFC 1179 and (2) IPP.  This document does not
   attempt to map the numerous divergent extensions to the LPD protocol
   that have been made by many implementers.</t>
</abstract>
</front>

<seriesInfo value="2569" name="RFC" />
</reference>


<reference target2="reference.RFC.2570.xml" anchor="RFC2570">
<front>
<title abbrev="Introduction to SNMPv3">Introduction to Version 3 of the Internet-standard Network Management Framework</title>
<author fullname="Jeffrey Case" initials="J." surname="Case">
<organization>SNMP Research, Inc.</organization>

<address>
<postal>
<street>3001 Kimberlin Heights Road</street>
<city>Knoxville</city>
<region>TN</region>
<code>37920-9716</code>
<country>US</country>
</postal>

<phone>+1 423 573 1434</phone>
<email>case@snmp.com</email>
</address>
</author>

<author fullname="Russ Mundy" initials="R." surname="Mundy">
<organization>TIS Labs at Network Associates</organization>

<address>
<postal>
<street>3060 Washington Rd</street>
<city>Glenwood</city>
<region>MD</region>
<code>21738</code>
<country>US</country>
</postal>

<phone>+1 301 854 6889</phone>
<email>mundy@tislabs.com</email>
</address>
</author>

<author fullname="David Partain" initials="D." surname="Partain">
<organization>Ericsson Radio Systems, Research and Innovation</organization>

<address>
<postal>
<street>P.O. Box 1248</street>
<street>SE-581 12 Linkoping</street>
<country>SE</country>
</postal>

<phone>+46 13 284144</phone>
<email>David.Partain@ericsson.com</email>
</address>
</author>

<author fullname="Bob Stewart" initials="B." surname="Stewart">
<organization>Cisco Systems, Inc.</organization>

<address>
<postal>
<street>170 West Tasman Drive</street>
<city>San Jose</city>
<region>CA</region>
<code>95134-1706</code>
<country>US</country>
</postal>

<phone>+1 603 654 6923</phone>
<email>bstewart@cisco.com</email>
</address>
</author>

<date year="1999" month="April" />

<abstract>
<t>The purpose of this document is to provide an overview of the third
   version of the Internet-standard Management Framework, termed the
   SNMP version 3 Framework (SNMPv3).  This Framework is derived from
   and builds upon both the original Internet-standard Management
   Framework (SNMPv1) and the second Internet-standard Management
   Framework (SNMPv2).</t>

<t>The architecture is designed to be modular to allow the evolution of
   the Framework over time.</t>
</abstract>
</front>

<seriesInfo value="2570" name="RFC" />
</reference>


<reference target2="reference.RFC.2571.xml" anchor="RFC2571">
<front>
<title abbrev="Architecture for SNMP Frameworks">An Architecture for Describing SNMP Management Frameworks</title>
<author fullname="Bert Wijnen" initials="B." surname="Wijnen">
<organization>IBM T.J. Watson Research</organization>

<address>
<postal>
<street>Schagen 33</street>
<street>3461 GL Linschoten</street>
<country>NL</country>
</postal>

<phone>+31 34 8432794</phone>
<email>wijnen@vnet.ibm.com</email>
</address>
</author>

<author fullname="Dave Harrington" initials="D." surname="Harrington">
<organization>Cabletron Systems, Inc</organization>

<address>
<postal>
<street>Post Office Box 5005</street>
<street>35 Industrial Way</street>
<street>Mail Stop: Durham</street>
<city>Rochester</city>
<region>NH</region>
<code>03867-5005</code>
<country>US</country>
</postal>

<phone>+1 603 337 7357</phone>
<email>dbh@ctron.com</email>
</address>
</author>

<author fullname="Randy Presuhn" initials="R." surname="Presuhn">
<organization>BMC Software, Inc.</organization>

<address>
<postal>
<street>965 Stewart Drive</street>
<city>Sunnyvale</city>
<region>CA</region>
<code>94086</code>
<country>US</country>
</postal>

<phone>+1 408 616 3100</phone>
<facsimile>+1 408 616 3101</facsimile>
<email>randy_presuhn@bmc.com</email>
</address>
</author>

<date year="1999" month="April" />

<abstract>
<t>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.</t>
</abstract>
</front>

<seriesInfo value="2571" name="RFC" />
</reference>


<reference target2="reference.RFC.2572.xml" anchor="RFC2572">
<front>
<title abbrev="Message Processing and Dispatching">Message Processing and Dispatching for the Simple Network Management Protocol (SNMP)</title>
<author fullname="Jeffrey Case" initials="J." surname="Case">
<organization>SNMP Research, Inc.</organization>

<address>
<postal>
<street>3001 Kimberlin Heights Road</street>
<city>Knoxville</city>
<region>TN</region>
<code>37920-9716</code>
<country>US</country>
</postal>

<phone>+1 423 573 1434</phone>
<email>case@snmp.com</email>
</address>
</author>

<author fullname="Dave Harrington" initials="D." surname="Harrington">
<organization>Cabletron Systems, Inc</organization>

<address>
<postal>
<street>35 Industrial Way</street>
<street>Mail Stop: Durham</street>
<street>Post Office Box 5005</street>
<city>Rochester</city>
<region>NH</region>
<code>03867-5005</code>
<country>US</country>
</postal>

<phone>+1 603 337 7357</phone>
<email>dbh@ctron.com</email>
</address>
</author>

<author fullname="Randy Presuhn" initials="R." surname="Presuhn">
<organization>BMC Software, Inc.</organization>

<address>
<postal>
<street>965 Stewart Drive</street>
<city>Sunnyvale</city>
<region>CA</region>
<code>94086</code>
<country>US</country>
</postal>

<phone>+1 408 616 3100</phone>
<email>randy_presuhn@bmc.com</email>
</address>
</author>

<author fullname="Bert Wijnen" initials="B." surname="Wijnen">
<organization>IBM T. J. Watson Research</organization>

<address>
<postal>
<street>Schagen 33</street>
<street>3461 GL Linschoten</street>
<country>NL</country>
</postal>

<phone>+31 34 8432794</phone>
<email>wijnen@vnet.ibm.com</email>
</address>
</author>

<date year="1999" month="April" />

<abstract>
<t>This document describes the Message Processing and Dispatching for
   SNMP messages within the SNMP architecture.
.  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.</t>
</abstract>
</front>

<seriesInfo value="2572" name="RFC" />
</reference>


<reference target2="reference.RFC.2573.xml" anchor="RFC2573">
<front>
<title>SNMP Applications</title>
<author fullname="David B. Levi" initials="D.B." surname="Levi">
<organization>SNMP Research, Inc.</organization>

<address>
<postal>
<street>3001 Kimberlin Heights Road</street>
<city>Knoxville</city>
<region>TN</region>
<code>37920-9716</code>
<country>US</country>
</postal>

<phone>+1 423 573 1434</phone>
<email>levi@snmp.com</email>
</address>
</author>

<author fullname="Paul Meyer" initials="P." surname="Meyer">
<organization>Secure Computing Corporation</organization>

<address>
<postal>
<street>2675 Long Lake Road</street>
<city>Roseville</city>
<region>MN</region>
<code>55113</code>
<country>US</country>
</postal>

<phone>+1 651 628 1592</phone>
<email>paul_meyer@securecomputing.com</email>
</address>
</author>

<author fullname="Bob Stewart" initials="B." surname="Stewart">
<organization>Cisco Systems, Inc.</organization>

<address>
<postal>
<street>170 West Tasman Drive</street>
<city>San Jose</city>
<region>CA</region>
<code>95134-1706</code>
<country>US</country>
</postal>

<phone>+1 603 654 2686</phone>
<email>bstewart@cisco.com</email>
</address>
</author>

<date year="1999" month="April" />

<abstract>
<t>This memo describes five types of SNMP applications which make use of
   an SNMP engine as described in.  The types of application
   described are Command Generators, Command Responders, Notification
   Originators, Notification Receivers, and Proxy Forwarders.</t>

<t>This memo also defines MIB modules for specifying targets of
   management operations, for notification filtering, and for proxy
   forwarding.</t>
</abstract>
</front>

<seriesInfo value="2573" name="RFC" />
</reference>


<reference target2="reference.RFC.2574.xml" anchor="RFC2574">
<front>
<title abbrev="USM for SNMPv3">User-based Security Model (USM) for version 3 of the Simple Network Management Protocol (SNMPv3)</title>
<author fullname="Uri Blumenthal" initials="U." surname="Blumenthal">
<organization>IBM T. J. Watson Research</organization>

<address>
<postal>
<street>30 Saw Mill River Pkwy</street>
<city>Hawthorne</city>
<region>NY</region>
<code>10532</code>
<country>US</country>
</postal>

<phone>+1 914 784 7064</phone>
<email>uri@watson.ibm.com</email>
</address>
</author>

<author fullname="Bert Wijnen" initials="B." surname="Wijnen">
<organization>IBM T. J. Watson Research</organization>

<address>
<postal>
<street>Schagen 33</street>
<street>3461 GL Linschoten</street>
<country>NL</country>
</postal>

<phone>+31 34 8432794</phone>
<email>wijnen@vnet.ibm.com</email>
</address>
</author>

<date year="1999" month="April" />

<abstract>
<t>This document describes the User-based Security Model (USM) for SNMP
   version 3 for use in the SNMP architecture.  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.</t>
</abstract>
</front>

<seriesInfo value="2574" name="RFC" />
</reference>


<reference target2="reference.RFC.2575.xml" anchor="RFC2575">
<front>
<title abbrev="VACM for SNMP">View-based Access Control Model (VACM) for the Simple Network Management Protocol (SNMP)</title>
<author fullname="Bert Wijnen" initials="B." surname="Wijnen">
<organization>IBM T. J. Watson Research</organization>

<address>
<postal>
<street>Schagen 33</street>
<street>3461 GL Linschoten</street>
<country>NL</country>
</postal>

<phone>+31 34 8432794</phone>
<email>wijnen@vnet.ibm.com</email>
</address>
</author>

<author fullname="Randy Presuhn" initials="R." surname="Presuhn">
<organization>BMC Software, Inc</organization>

<address>
<postal>
<street>965 Stewart Drive</street>
<city>Sunnyvale</city>
<region>CA</region>
<code>94086</code>
<country>US</country>
</postal>

<phone>+1 408 616 3100</phone>
<email>randy_presuhn@bmc.com</email>
</address>
</author>

<author fullname="Keith McCloghrie" initials="K." surname="McCloghrie">
<organization>Cisco Systems, Inc.</organization>

<address>
<postal>
<street>170 West Tasman Drive</street>
<city>San Jose</city>
<region>CA</region>
<code>95134-1706</code>
<country>US</country>
</postal>

<phone>+1 408 526 5260</phone>
<email>kzm@cisco.com</email>
</address>
</author>

<date year="1999" month="April" />

<abstract>
<t>This document describes the View-based Access Control Model for use
   in the SNMP architecture.  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.</t>
</abstract>
</front>

<seriesInfo value="2575" name="RFC" />
</reference>


<reference target2="reference.RFC.2576.xml" anchor="RFC2576">
<front>
<title abbrev="Coexistence between SNMP versions">Coexistence between Version 1, Version 2, and Version 3 of the Internet-standard Network Management Framework</title>
<author fullname="Rob Frye" initials="R." surname="Frye">
<organization>CoSine Communications</organization>

<address>
<postal>
<street>1200 Bridge Parkway</street>
<city>Redwood City</city>
<region>CA</region>
<code>94065</code>
<country>US</country>
</postal>

<phone>+1 703 725 1130</phone>
<email>rfrye@cosinecom.com</email>
</address>
</author>

<author fullname="David B. Levi" initials="D." surname="Levi">
<organization>Nortel Networks</organization>

<address>
<postal>
<street>3505 Kesterwood Drive</street>
<city>Knoxville</city>
<region>TN</region>
<code>37918</code>
<country>US</country>
</postal>

<phone>+1 423 686 0432</phone>
<email>dlevi@nortelnetworks.com</email>
</address>
</author>

<author fullname="Shawn A. Routhier" initials="S." surname="Routhier">
<organization>Integrated Systems Inc.</organization>

<address>
<postal>
<street>333 North Ave</street>
<street>4th Floor</street>
<city>Wakefield</city>
<region>MA</region>
<code>01880</code>
<country>US</country>
</postal>

<phone>+1 781 245 0804</phone>
<email>sar@epilogue.com</email>
</address>
</author>

<author fullname="Bert Wijnen" initials="B." surname="Wijnen">
<organization>Lucent Technologies</organization>

<address>
<postal>
<street>Schagen 33</street>
<street>3461 GL Linschoten</street>
<country>NL</country>
</postal>

<phone>+31 34 8407775</phone>
<email>wijnen@lucent.com</email>
</address>
</author>

<date year="2000" month="March" />

<abstract>
<t>The purpose of this document is to describe coexistence between
   version 3 of the Internet-standard Network Management Framework,
   (SNMPv3), version 2 of the Internet-standard Network Management
   Framework (SNMPv2), and the original Internet-standard Network
   Management Framework (SNMPv1).  This document obsoletes 
RFC 1908and RFC2089.</t>
</abstract>
</front>

<seriesInfo value="2576" name="RFC" />
</reference>


<reference target2="reference.RFC.2577.xml" anchor="RFC2577">
<front>
<title>FTP Security Considerations</title>
<author fullname="Mark Allman" initials="M." surname="Allman">
<organization>NASA Glenn Research Center/Sterling Software</organization>

<address>
<postal>
<street>21000 Brookpark Rd.</street>
<street>MS 54-2</street>
<city>Cleveland</city>
<region>OH</region>
<code>44135</code>
<country>US</country>
</postal>

<email>mallman@grc.nasa.gov</email>
</address>
</author>

<author fullname="Shawn Ostermann" initials="S." surname="Ostermann">
<organization>Ohio University, School of Electrical Engineering and Computer Science</organization>

<address>
<postal>
<street>416 Morton Hall</street>
<city>Athens</city>
<region>OH</region>
<code>45701</code>
<country>US</country>
</postal>

<email>ostermann@cs.ohiou.edu</email>
</address>
</author>

<date year="1999" month="May" />

<abstract>
<t>The specification for the File Transfer Protocol (FTP) 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.</t>
</abstract>
</front>

<seriesInfo value="2577" name="RFC" />
</reference>


<reference target2="reference.RFC.2578.xml" anchor="RFC2578">
<front>
<title abbrev="SMIv2">Structure of Management Information Version 2 (SMIv2)</title>
<author fullname="Keith McCloghrie" initials="K." surname="McCloghrie">
<organization>Cisco Systems, Inc.</organization>

<address>
<postal>
<street>170 West Tasman Drive</street>
<city>San Jose</city>
<region>CA</region>
<code>95134-1706</code>
<country>US</country>
</postal>

<phone>+1 408 526 5260</phone>
<email>kzm@cisco.com</email>
</address>
</author>

<author fullname="David Perkins" initials="D." surname="Perkins">
<organization>SNMPinfo</organization>

<address>
<postal>
<street>3763 Benton Street</street>
<city>Santa Clara</city>
<region>CA</region>
<code>95051</code>
<country>US</country>
</postal>

<phone>+1 408 221 8702</phone>
<email>dperkins@snmpinfo.com</email>
</address>
</author>

<author fullname="Juergen Schoenwaelder" initials="J." surname="Schoenwaelder">
<organization>TU Braunschweig</organization>

<address>
<postal>
<street>Bueltenweg 74/75</street>
<street>38106 Braunschweig</street>
<country>DE</country>
</postal>

<phone>+49 531 3913283</phone>
<email>schoenw@ibr.cs.tu-bs.de</email>
</address>
</author>

<author fullname="J. Case" initials="J." surname="Case">
<organization>SNMP Research</organization>
</author>

<author fullname="K. McCloghrie" initials="K." surname="McCloghrie">
<organization>Cisco Systems</organization>
</author>

<author fullname="M. Rose" initials="M." surname="Rose">
<organization>First Virtual Holdings</organization>
</author>

<author fullname="S. Waldbusser" initials="S." surname="Waldbusser">
<organization>International Network Services</organization>
</author>

<date year="1999" month="April" />
</front>

<seriesInfo value="58" name="STD" />
<seriesInfo value="2578" name="RFC" />
</reference>


<reference target2="reference.RFC.2579.xml" anchor="RFC2579">
<front>
<title>Textual Conventions for SMIv2</title>
<author fullname="Keith McCloghrie" initials="K." surname="McCloghrie">
<organization>Cisco Systems, Inc.</organization>

<address>
<postal>
<street>170 West Tasman Drive</street>
<city>San Jose</city>
<region>CA</region>
<code>95134-1706</code>
<country>US</country>
</postal>

<phone>+1 408 526 5260</phone>
<email>kzm@cisco.com</email>
</address>
</author>

<author fullname="David Perkins" initials="D." surname="Perkins">
<organization>SNMPinfo</organization>

<address>
<postal>
<street>3763 Benton Street</street>
<city>Santa Clara</city>
<region>CA</region>
<code>95051</code>
<country>US</country>
</postal>

<phone>+1 408 221 8702</phone>
<email>dperkins@snmpinfo.com</email>
</address>
</author>

<author fullname="Juergen Schoenwaelder" initials="J." surname="Schoenwaelder">
<organization>TU Braunschweig</organization>

<address>
<postal>
<street>Bueltenweg 74/75</street>
<street>38106 Braunschweig</street>
<country>DE</country>
</postal>

<phone>+49 531 3913283</phone>
<email>schoenw@ibr.cs.tu-bs.de</email>
</address>
</author>

<author fullname="J. Case" initials="J." surname="Case">
<organization>SNMP Research</organization>
</author>

<author fullname="K. McCloghrie" initials="K." surname="McCloghrie">
<organization>Cisco Systems</organization>
</author>

<author fullname="M. Rose" initials="M." surname="Rose">
<organization>First Virtual Holdings</organization>
</author>

<author fullname="S. Waldbusser" initials="S." surname="Waldbusser">
<organization>International Network Services</organization>
</author>

<date year="1999" month="April" />
</front>

<seriesInfo value="58" name="STD" />
<seriesInfo value="2579" name="RFC" />
</reference>


<reference target2="reference.RFC.2580.xml" anchor="RFC2580">
<front>
<title>Conformance Statements for SMIv2</title>
<author fullname="Keith McCloghrie" initials="K." surname="McCloghrie">
<organization>Cisco Systems, Inc.</organization>

<address>
<postal>
<street>170 West Tasman Drive</street>
<city>San Jose</city>
<region>CA</region>
<code>95134-1706</code>
<country>US</country>
</postal>

<phone>+1 408 526 5260</phone>
<email>kzm@cisco.com</email>
</address>
</author>

<author fullname="David Perkins" initials="D." surname="Perkins">
<organization>SNMPinfo</organization>

<address>
<postal>
<street>3763 Benton Street</street>
<city>Santa Clara</city>
<region>CA</region>
<code>95051</code>
<country>US</country>
</postal>

<phone>+1 408 221 8702</phone>
<email>dperkins@snmpinfo.com</email>
</address>
</author>

<author fullname="Juergen Schoenwaelder" initials="J." surname="Schoenwaelder">
<organization>TU Braunschweig</organization>

<address>
<postal>
<street>Bueltenweg 74/75</street>
<city>Braunschweig</city>
<code>38106</code>
<country>DE</country>
</postal>

<phone>+49 531 3913283</phone>
<email>schoenw@ibr.cs.tu-bs.de</email>
</address>
</author>

<date year="1999" month="April" />
</front>

<seriesInfo value="58" name="STD" />
<seriesInfo value="2580" name="RFC" />
</reference>


<reference target2="reference.RFC.2581.xml" anchor="RFC2581">
<front>
<title>TCP Congestion Control</title>
<author fullname="Mark Allman" initials="M." surname="Allman">
<organization>NASA Glenn Research Center/Sterling Software</organization>

<address>
<postal>
<street>21000 Brookpark Road</street>
<street>MS 54-2</street>
<city>Cleveland</city>
<region>OH</region>
<code>44135</code>
<country>US</country>
</postal>

<phone>+1 216 433 6586</phone>
<email>mallman@grc.nasa.gov</email>
</address>
</author>

<author fullname="Vern Paxson" initials="V." surname="Paxson">
<organization>ACIRI / ICSI</organization>

<address>
<postal>
<street>1947 Center Street</street>
<street>Suite 600</street>
<city>Berkeley</city>
<region>CA</region>
<code>94704-1198</code>
<country>US</country>
</postal>

<phone>+1 510 642 4274 x302</phone>
<email>vern@aciri.org</email>
</address>
</author>

<author fullname="W. Richard Stevens" initials="W." surname="Stevens">
<organization />

<address>
<postal>
<street>1202 East Paseo del Zorro</street>
<city>Tucson</city>
<region>AZ</region>
<code>85718</code>
<country>US</country>
</postal>

<phone>+1 520 297 9416</phone>
<email>rstevens@kohala.com</email>
</address>
</author>

<date year="1999" month="April" />

<abstract>
<t>This document defines TCP's four intertwined congestion
control algorithms: slow start, congestion avoidance, fast retransmit,
and fast recovery.
In addition, the document specifies how TCP should begin transmission
after a relatively long idle period, as well as discussing various
acknowledgment generation methods.</t>
</abstract>
</front>

<seriesInfo value="2581" name="RFC" />
</reference>


<reference target2="reference.RFC.2582.xml" anchor="RFC2582">
<front>
<title abbrev="NewReno Modification to TCP&apos;s Fast Recovery">The NewReno Modification to TCP's Fast Recovery Algorithm</title>
<author fullname="Sally Floyd" initials="S." surname="Floyd">
<organization>AT&amp;T Center for Internet Research at ICSI (ACIRI)</organization>

<address>
<phone>+1 510 642 4274 x189</phone>
<email>floyd@acm.org</email>
</address>
</author>

<author fullname="Tom Henderson" initials="T." surname="Henderson">
<organization>University of California at Berkeley</organization>

<address>
<phone>+1 510 642 8919</phone>
<email>tomh@cs.berkeley.edu</email>
</address>
</author>

<date year="1999" month="April" />

<abstract>
<t>documents the following four intertwined TCP
congestion control algorithms:
Slow Start,
Congestion Avoidance,
Fast Retransmit,
and Fast Recovery.explicitly allows certain modifications of
these algorithms,
including modifications that use theTCP Selective Acknowledgement (SACK) optionand modifications that respond to "partial acknowledgments"
(ACKs which cover new data,
but not all the data outstanding when loss was detected)
in the absence of SACK.
This document describes a specific algorithm for responding to partial
acknowledgments,
referred to as NewReno.
This response to partial acknowledgments was first proposed by Janey
Hoe in.</t>
</abstract>
</front>

<seriesInfo value="2582" name="RFC" />
</reference>


<reference target2="reference.RFC.2583.xml" anchor="RFC2583">
<front>
<title abbrev="Guidelines for NHC Developers">Guidelines for Next Hop Client (NHC) Developers</title>
<author fullname="Richard Carlson" initials="R." surname="Carlson">
<organization>Argonne National Laboratory</organization>

<address>
<email>RACarlson@anl.gov</email>
</address>
</author>

<author fullname="Linda Winkler" initials="L." surname="Winkler">
<organization>Argonne National Laboratory</organization>

<address>
<email>lwinkler@anl.gov</email>
</address>
</author>

<date year="1999" month="May" />

<abstract>
<t>This document provides guidelines for developers of the Next Hop
Resolution Protocol Clients (NHC).
It assumes that the clients are
directly connected to an ATM based NBMA network.
The same principles
will apply to clients connected to other types of NBMA networks.
The
intent is to define the interaction between the NHC code and the
TCP/IP protocol stack of the local host operating system.
The NHC is
capable of sending NHRP requests to a Next Hop Resolution Protocol
Server (NHS) to resolve both inter and intra LIS addresses.
The NHS
reply may be positive (ACK) indicating a short-cut path is available
or negative (NAK) indicating that a shortcut is not available and the
routed path must be used.
The NHC must cache (maintain state) for
both the ACK and NAK replies in order to use the correct shortcut or
routed path.
The NAK reply must be cached to avoid making repeated
requests to the NHS when the routed path is being used.</t>
</abstract>
</front>

<seriesInfo value="2583" name="RFC" />
</reference>


<reference target2="reference.RFC.2584.xml" anchor="RFC2584">
<front>
<title abbrev="APPN/HPR in IP Networks MIB">Definitions of Managed Objects for APPN/HPR in IP Networks</title>
<author fullname="Bob Clouston" initials="B." surname="Clouston">
<organization>Cisco Systems</organization>

<address>
<postal>
<street>7025 Kit Creek Road</street>
<street>POB 14987</street>
<city>Research Triangle Park</city>
<region>NC</region>
<code>27709</code>
<country>US</country>
</postal>

<phone>+1 919 472 2333</phone>
<email>clouston@cisco.com</email>
</address>
</author>

<author fullname="Bob Moore" initials="B." surname="Moore">
<organization>IBM Corporation</organization>

<address>
<postal>
<street>POB 12195</street>
<city>Research Triangle Park</city>
<region>NC</region>
<code>27709</code>
<country>US</country>
</postal>

<phone>+1 919 254 4436</phone>
<email>remoore@us.ibm.com</email>
</address>
</author>

<date year="1999" month="May" />

<abstract>
<t>This memo defines a portion of the Management Information
Base (MIB)
for use with network management protocols in the Internet community.
In particular, it defines objects for monitoring and controlling HPR
(High Performance Routing) network devices which have the capability
to communicate in IP (Internet Protocol) networks.
This memo
identifies managed objects for the HPR in IP network
communications.</t>
</abstract>
</front>

<seriesInfo value="2584" name="RFC" />
</reference>


<reference target2="reference.RFC.2585.xml" anchor="RFC2585">
<front>
<title abbrev="PKIX Operational Protocols: FTP and HTTP">Internet X.509 Public Key Infrastructure Operational Protocols: FTP and HTTP</title>
<author fullname="Russell Housley" initials="R." surname="Housley">
<organization>SPYRUS</organization>

<address>
<postal>
<street>381 Elden Street</street>
<street>Suite 1120</street>
<street>Suite 1120</street>
<city>Herndon</city>
<region>VA</region>
<code>20170</code>
<country>US</country>
</postal>

<email>housley@spyrus.com</email>
</address>
</author>

<author fullname="Paul Hoffman" initials="P." surname="Hoffman">
<organization>Internet Mail Consortium</organization>

<address>
<postal>
<street>127 Segre Place</street>
<city>Santa Cruz</city>
<region>CA</region>
<code>95060</code>
<country>US</country>
</postal>

<email>phoffman@imc.org</email>
</address>
</author>

<date year="1999" month="May" />

<abstract>
<t>The protocol conventions described in this document
satisfy some of
the operational requirements of the Internet Public Key
Infrastructure (PKI).
This document specifies the conventions for
using the File Transfer Protocol (FTP) and the Hypertext Transfer
Protocol (HTTP) to obtain certificates and certificate revocation
lists (CRLs) from PKI repositories.
Additional mechanisms addressing
PKIX operational requirements are specified in separate
documents.</t>
</abstract>
</front>

<seriesInfo value="2585" name="RFC" />
</reference>


<reference target2="reference.RFC.2586.xml" anchor="RFC2586">
<front>
<title>The Audio/L16 MIME content type</title>
<author fullname="James Salsman" initials="J." surname="Salsman">
<organization />

<address>
<postal>
<street>575 South Rengstorff Avenue</street>
<city>Mountain View</city>
<region>CA</region>
<code>94040-1982</code>
<country>US</country>
</postal>

<email>James@bovik.org</email>
</address>
</author>

<author fullname="Harald Alvestrand" initials="H." surname="Alvestrand">
<organization>UNINETT</organization>

<address>
<postal>
<street />
<city>Trondheim</city>
<code>N-7034</code>
<country>NO</country>
</postal>

<phone>+47 73 597094</phone>
<email>Harald.T.Alvestrand@uninett.no</email>
</address>
</author>

<date year="1999" month="May" />
</front>

<seriesInfo value="2586" name="RFC" />
</reference>


<reference target2="reference.RFC.2587.xml" anchor="RFC2587">
<front>
<title abbrev="PKIX LDAPv2 Schema">Internet X.509 Public Key Infrastructure LDAPv2 Schema</title>
<author fullname="Sharon Boeyen" initials="S." surname="Boeyen">
<organization>Entrust Technologies Limited</organization>

<address>
<postal>
<street>750 Heron Road</street>
<city>Ottawa</city>
<region>Ontario</region>
<code>K1V 1A7</code>
<country>CA</country>
</postal>

<email>sharon.boeyen@entrust.com</email>
</address>
</author>

<author fullname="Tim Howes" initials="T." surname="Howes">
<organization>Netscape Communications Corp</organization>

<address>
<postal>
<street>501 East Middlefield Road</street>
<city>Mountain View</city>
<region>CA</region>
<code>94043</code>
<country>US</country>
</postal>

<email>howes@netscape.com</email>
</address>
</author>

<author fullname="Patrick Richard" initials="P." surname="Richard">
<organization>Xcert Software Inc.</organization>

<address>
<postal>
<street>701 West Georgia Street</street>
<street>Suite 1001</street>
<street>POB 10145</street>
<city>Vancouver</city>
<region>British Columbia</region>
<code>V7Y 1C6</code>
<country>CA</country>
</postal>

<email>patr@xcert.com</email>
</address>
</author>

<date year="1999" month="June" />

<abstract>
<t>The schema defined in this document is a minimal schema to support
PKIX in an LDAPv2 environment, as defined in RFC 2559.
Only PKIX-specific components are specified here.
LDAP servers, acting as PKIX
repositories should support the auxiliary object classes defined in
this specification and integrate this schema specification with the
generic and other application-specific schemas as appropriate,
depending on the services to be supplied by that server.</t>

<t>The key words 'MUST', 'SHALL', 'REQUIRED', 'SHOULD', 'RECOMMENDED',
and 'MAY' in this document are to be interpreted as described in RFC
2119.</t>
</abstract>
</front>

<seriesInfo value="2587" name="RFC" />
</reference>


<reference target2="reference.RFC.2588.xml" anchor="RFC2588">
<front>
<title>IP Multicast and Firewalls</title>
<author fullname="Ross Finlayson" initials="R." surname="Finlayson">
<organization>Live Networks, Inc. (LIVE.COM)</organization>

<address>
<email>finlayson@live.com</email>
<uri>http://www.live.com/</uri>
</address>
</author>

<date year="1999" month="May" />

<abstract>
<t>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.</t>
</abstract>
</front>

<seriesInfo value="2588" name="RFC" />
</reference>


<reference target2="reference.RFC.2589.xml" anchor="RFC2589">
<front>
<title abbrev="LDAPv3 Extensions for Dynamic Directory Services">Lightweight Directory Access Protocol (v3): Extensions for Dynamic Directory Services</title>
<author fullname="Yoram Yaacovi" initials="Y." surname="Yaacovi">
<organization>Microsoft</organization>

<address>
<postal>
<street>One Microsoft way</street>
<city>Redmond</city>
<region>WA</region>
<code>98052</code>
<country>US</country>
</postal>

<phone>+1 206 936 9629</phone>
<email>yoramy@microsoft.com</email>
</address>
</author>

<author fullname="Mark Wahl" initials="M." surname="Wahl">
<organization>Innosoft International, Inc.</organization>

<address>
<postal>
<street>8911 Capital of Texas Highway</street>
<street>Suite 4140</street>
<city>Austin</city>
<region>TX</region>
<code>78759</code>
<country>US</country>
</postal>

<email>M.Wahl@innosoft.com</email>
</address>
</author>

<author fullname="Tony Genovese" initials="T." surname="Genovese">
<organization>Microsoft</organization>

<address>
<postal>
<street>One Microsoft way</street>
<city>Redmond</city>
<region>WA</region>
<code>98052</code>
<country>US</country>
</postal>

<phone>+1 206 703 0852</phone>
<email>tonyg@microsoft.com</email>
</address>
</author>

<date year="1999" month="May" />

<abstract>
<t>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.</t>

<t>TheLightweight Directory Access Protocol (LDAP)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.</t>

<t>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.</t>

<t>A flow control mechanism from the server is also described that
allows a server to inform clients how often they should refresh their
presence.</t>
</abstract>
</front>

<seriesInfo value="2589" name="RFC" />
</reference>


<reference target2="reference.RFC.2590.xml" anchor="RFC2590">
<front>
<title abbrev="IPv6 over Frame Relay Networks">Transmission of IPv6 Packets over Frame Relay Networks Specification</title>
<author fullname="Alex Conta" initials="A." surname="Conta">
<organization>Lucent Technologies Inc.</organization>

<address>
<postal>
<street>300 Baker Avenue</street>
<street>Suite 100</street>
<city>Concord</city>
<region>MA</region>
<code>01742</code>
<country>US</country>
</postal>

<phone>+1 978 287 2842</phone>
<email>aconta@lucent.com</email>
</address>
</author>

<author fullname="Andrew Malis" initials="A." surname="Malis">
<organization>Ascend Communications</organization>

<address>
<postal>
<street>1 Robbins Road</street>
<city>Westford</city>
<region>MA</region>
<code>01886</code>
<country>US</country>
</postal>

<phone>+1 978 952 7414</phone>
<email>malis@ascend.com</email>
</address>
</author>

<author fullname="Martin Mueller" initials="M." surname="Mueller">
<organization>Lucent Technologies Inc.</organization>

<address>
<postal>
<street>300 Baker Avenue</street>
<street>Suite 100</street>
<city>Concord</city>
<region>MA</region>
<code>01742</code>
<country>US</country>
</postal>

<phone>+1 978 287 2833</phone>
<email>memueller@lucent.com</email>
</address>
</author>

<date year="1999" month="May" />

<abstract>
<t>This memo describes mechanisms for the transmission of
IPv6 packets
over Frame Relay networks.</t>
</abstract>
</front>

<seriesInfo value="2590" name="RFC" />
</reference>


<reference target2="reference.RFC.2591.xml" anchor="RFC2591">
<front>
<title abbrev="Scheduling MIB">Definitions of Managed Objects for Scheduling Management Operations</title>
<author fullname="David B. Levi" initials="D." surname="Levi">
<organization>Nortel Networks</organization>

<address>
<postal>
<street>4401 Great America Parkway</street>
<city>Santa Clara</city>
<region>CA</region>
<code>95052-8185</code>
<country>US</country>
</postal>

<phone>+1 423 686 0432</phone>
<email>dlevi@nortelnetworks.com</email>
</address>
</author>

<author fullname="Juergen Schoenwaelder" initials="J." surname="Schoenwaelder">
<organization>TU Braunschweig</organization>

<address>
<postal>
<street>Bueltenweg 74/75</street>
<city>Braunschweig</city>
<code>38106</code>
<country>DE</country>
</postal>

<phone>+49 531 3913283</phone>
<email>schoenw@ibr.cs.tu-bs.de</email>
</address>
</author>

<date year="1999" month="May" />

<abstract>
<t>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 set of managed objects that are used to
schedule management operations periodically or at specified dates and
times.</t>
</abstract>
</front>

<seriesInfo value="2591" name="RFC" />
</reference>


<reference target2="reference.RFC.2592.xml" anchor="RFC2592">
<front>
<title abbrev="Script MIB">Definitions of Managed Objects for the Delegation of Management Script</title>
<author fullname="David B. Levi" initials="D." surname="Levi">
<organization>Nortel Networks</organization>

<address>
<postal>
<street>4401 Great America Parkway</street>
<city>Santa Clara</city>
<region>CA</region>
<code>95052-8185</code>
<country>US</country>
</postal>

<phone>+1 423 686 0432</phone>
<email>dlevi@nortelnetworks.com</email>
</address>
</author>

<author fullname="Juergen Schoenwaelder" initials="J." surname="Schoenwaelder">
<organization>TU Braunschweig</organization>

<address>
<postal>
<street>Bueltenweg 74/75</street>
<city>Braunschweig</city>
<code>38106</code>
<country>DE</country>
</postal>

<phone>+49 531 3913283</phone>
<email>schoenw@ibr.cs.tu-bs.de</email>
</address>
</author>

<date year="1999" month="May" />

<abstract>
<t>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 set of managed objects that allow the
delegation of management scripts to distributed managers.</t>
</abstract>
</front>

<seriesInfo value="2592" name="RFC" />
</reference>


<reference target2="reference.RFC.2593.xml" anchor="RFC2593">
<front>
<title abbrev="SMX Protocol 1.0">Script MIB Extensibility Protocol Version 1.0</title>
<author fullname="Juergen Schoenwaelder" initials="J." surname="Schoenwaelder">
<organization>TU Braunschweig</organization>

<address>
<postal>
<street>Bueltenweg 74/75</street>
<city>Braunschweig</city>
<code>38106</code>
<country>DE</country>
</postal>

<phone>+49 531 3913283</phone>
<email>schoenw@ibr.cs.tu-bs.de</email>
</address>
</author>

<author fullname="Juergen Quittek" initials="J." surname="Quittek">
<organization>NEC Europe Ltd.</organization>

<address>
<postal>
<street>C&amp;C Research Laboratories</street>
<street>Hardenbergplatz 2</street>
<city>Berlin</city>
<code>10623</code>
<country>DE</country>
</postal>

<phone>+49 30 25423019</phone>
<email>quittek@ccrle.nec.de</email>
</address>
</author>

<date year="1999" month="May" />

<abstract>
<t>The IETF Script MIB defines an interface for the delegation of management functions based on the Internet management framework. A management script is a set of instructions that are executed by a language specific runtime system. The Script MIB extensibility protocol (SMX) defined in this memo separates  language specific runtime systems from language independent Script MIB implementations.</t>
</abstract>
</front>

<seriesInfo value="2593" name="RFC" />
</reference>


<reference target2="reference.RFC.2594.xml" anchor="RFC2594">
<front>
<title abbrev="WWW Service MIB">Definitions of Managed Objects for WWW Services</title>
<author fullname="Harrie Hazewinkel" initials="H." surname="Hazewinkel">
<organization>Joint Research Centre of the E.C.</organization>

<address>
<postal>
<street>via Fermi</street>
<city>Ispra</city>
<code>21020</code>
<country>IT</country>
</postal>

<phone>+39 332 786322</phone>
<email>harrie.hazewinkel@jrc.it</email>
</address>
</author>

<author fullname="Carl W. Kalbfleisch" initials="C." surname="Kalbfleisch">
<organization>Verio, Inc.</organization>

<address>
<postal>
<street>1950 Stemmons Freeway</street>
<street>Suite 2006</street>
<city>Dallas</city>
<region>TX</region>
<code>75207</code>
<country>US</country>
</postal>

<phone>+1 214 290 8653</phone>
<email>cwk@verio.net</email>
</address>
</author>

<author fullname="Juergen Schoenwaelder" initials="J." surname="Schoenwaelder">
<organization>TU Braunschweig</organization>

<address>
<postal>
<street>Bueltenweg 74/75</street>
<city>Braunschweig</city>
<code>38106</code>
<country>DE</country>
</postal>

<phone>+49 531 3913683</phone>
<email>schoenw@ibr.cs.tu-bs.de</email>
</address>
</author>

<date year="1999" month="May" />

<abstract>
<t>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 set of objects for managing World Wide
Web (WWW) services.</t>
</abstract>
</front>

<seriesInfo value="2594" name="RFC" />
</reference>


<reference target2="reference.RFC.2595.xml" anchor="RFC2595">
<front>
<title>Using TLS with IMAP, POP3 and ACAP</title>
<author fullname="Chris Newman" initials="C." surname="Newman">
<organization>Innosoft International, Inc.</organization>

<address>
<postal>
<street>1050 Lakes Drive</street>
<city>West Covina</city>
<region>CA</region>
<code>91790</code>
<country>US</country>
</postal>

<email>chris.newman@innosoft.com</email>
</address>
</author>

<date year="1999" month="June" />
</front>

<seriesInfo value="2595" name="RFC" />
</reference>


<reference target2="reference.RFC.2596.xml" anchor="RFC2596">
<front>
<title>Use of Language Codes in LDAP</title>
<author fullname="Mark Wahl" initials="M." surname="Wahl">
<organization>Innosoft International, Inc.</organization>

<address>
<postal>
<street>8911 Capital of Texas Highway</street>
<street>Suite 4140</street>
<city>Austin</city>
<region>TX</region>
<code>78759</code>
<country>US</country>
</postal>

<email>M.Wahl@innosoft.com</email>
</address>
</author>

<author fullname="Tim Howes" initials="T." surname="Howes">
<organization>Netscape Communications Corp.</organization>

<address>
<postal>
<street>501 East Middlefield Road</street>
<city>Mountain View</city>
<region>CA</region>
<code>94043</code>
<country>US</country>
</postal>

<phone>+1 650 937 3419</phone>
<email>howes@netscape.com</email>
</address>
</author>

<date year="1999" month="May" />

<abstract>
<t>TheLightweight Directory Access Protocolprovides a
means for
clients to interrogate and modify information stored in a distributed
directory system.
The information in the directory is maintained asattributesof entries.
Most of these attributes have syntaxes
which are human-readable strings, and it is desirable to be able to
indicate the natural language associated with attribute values.</t>

<t>This document describes howlanguage codesare carried in LDAP
and are to be interpreted by LDAP servers.
All implementations MUST
be prepared to accept language codes in the LDAP protocols.
Servers
may or may not be capable of storing attributes with language codes
in the directory.
This document does not specify how to determine
whether particular attributes can or cannot have language codes.</t>

<t>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 inRFC 2119.</t>
</abstract>
</front>

<seriesInfo value="2596" name="RFC" />
</reference>


<reference target2="reference.RFC.2597.xml" anchor="RFC2597">
<front>
<title>Assured Forwarding PHB Group</title>
<author fullname="Juha Heinanen" initials="J." surname="Heinanen">
<organization>Telia Finland</organization>

<address>
<postal>
<street>Myyrmaentie 2</street>
<city>Vantaa</city>
<code>01600</code>
<country>FI</country>
</postal>

<email>jh@telia.fi</email>
</address>
</author>

<author fullname="Fred Baker" initials="F." surname="Baker">
<organization>Cisco Systems</organization>

<address>
<postal>
<street>519 Lado Drive</street>
<city>Santa Barbara</city>
<region>CA</region>
<code>93111</code>
<country>US</country>
</postal>

<email>fred@cisco.com</email>
</address>
</author>

<author fullname="Walter Weiss" initials="W." surname="Weiss">
<organization>Lucent Technologies</organization>

<address>
<postal>
<street>300 Baker Avenue</street>
<street>Suite 100</street>
<city>Concord</city>
<region>MA</region>
<code>01742-2168</code>
<country>US</country>
</postal>

<email>wweiss@lucent.com</email>
</address>
</author>

<author fullname="J. Wroclawski" initials="J." surname="Wroclawski">
<organization>MIT Laboratory for Computer Science</organization>

<address>
<postal>
<street>545 Technology Square</street>
<city>Cambridge</city>
<region>MA</region>
<code>02139</code>
<country>US</country>
</postal>

<email>jtw@lcs.mit.edu</email>
</address>
</author>

<date year="1999" month="June" />

<abstract>
<t>This document defines a general useDifferentiated Services (DS)Per-Hop-Behavior (PHB) Group called Assured Forwarding (AF).
The AF PHB group provides delivery of IP packets in four
independently forwarded AF classes.
Within each AF class, an IP
packet can be assigned one of three different levels of drop
precedence.
A DS node does not reorder IP packets of the same
microflow if they belong to the same AF class.</t>
</abstract>
</front>

<seriesInfo value="2597" name="RFC" />
</reference>


<reference target2="reference.RFC.2598.xml" anchor="RFC2598">
<front>
<title>An Expedited Forwarding PHB</title>
<author fullname="Van Jacobson" initials="V." surname="Jacobson">
<organization>Cisco Systems, Inc</organization>

<address>
<postal>
<street>170 West Tasman Drive</street>
<city>San Jose</city>
<region>CA</region>
<code>95134-1706</code>
<country>US</country>
</postal>

<email>van@cisco.com</email>
</address>
</author>

<author fullname="Kathleen Nichols" initials="K." surname="Nichols">
<organization>Cisco Systems, Inc</organization>

<address>
<postal>
<street>170 West Tasman Drive</street>
<city>San Jose</city>
<region>CA</region>
<code>95134-1706</code>
<country>US</country>
</postal>

<email>kmn@cisco.com</email>
</address>
</author>

<author fullname="Kedarnath Poduri" initials="K." surname="Poduri">
<organization>Bay Networks, Inc.</organization>

<address>
<postal>
<street>4401 Great America Parkway</street>
<city>Santa Clara</city>
<region>CA</region>
<code>95052-8185</code>
<country>US</country>
</postal>

<email>kpoduri@baynetworks.com</email>
</address>
</author>

<date year="1999" month="June" />

<abstract>
<t>The definition of PHBs (per-hop forwarding behaviors) is
a critical
part of the work of the Diffserv Working Group.
This document
describes a PHB called Expedited Forwarding.
We show the generality
of this PHB by noting that it can be produced by more than one
mechanism and give an example of its use to produce at least one
service, a Virtual Leased Line.
A recommended codepoint for this PHB
is given.</t>

<t>A pdf version of this document is available at.</t>
</abstract>
</front>

<seriesInfo value="2598" name="RFC" />
</reference>


<reference target2="reference.RFC.2599.xml" anchor="RFC2599">
<front>
<title abbrev="Summary of 2500-2599">Request for Comments Summary RFC Numbers 2500-2599</title>
<author fullname="Alison De La Cruz" initials="A." surname="De La Cruz">
<organization>University of Southern California, Information Sciences Institute</organization>

<address>
<postal>
<street>4676 Admiralty Way</street>
<city>Marina del Rey</city>
<region>CA</region>
<code>90292</code>
<country>US</country>
</postal>

<phone>+1 310 822 1511</phone>
<email>delacruz@isi.edu</email>
</address>
</author>

<date year="2000" month="March" />

<abstract>
<t></t>
</abstract>
</front>

<seriesInfo value="2599" name="RFC" />
</reference>


<reference target2="reference.RFC.2600.xml" anchor="RFC2600">
<front>
<title abbrev="Internet Standards">Internet Official Protocol Standards</title>
<author fullname="Joyce K. Reynolds" initials="J.K." surname="Reynolds">
<organization>USC/Information Sciences Institute</organization>

<address>
<postal>
<street>4676 Admiralty Way</street>
<city>Marina del Rey</city>
<region>CA</region>
<code>90292</code>
<country>US</country>
</postal>

<phone>+1 310 822 1511</phone>
<facsimile>+1 310 823 6714</facsimile>
<email>JKRey@ISI.EDU</email>
</address>
</author>

<author fullname="Robert Braden" initials="R." surname="Braden">
<organization>USC/Information Sciences Institute</organization>

<address>
<postal>
<street>4676 Admiralty Way</street>
<city>Marina del Rey</city>
<region>CA</region>
<code>90292</code>
<country>US</country>
</postal>

<phone>+1 310 822 1511</phone>
<facsimile>+1 310 823 6714</facsimile>
<email>Braden@ISI.EDU</email>
</address>
</author>

<date year="2000" month="March" />
</front>

<seriesInfo value="2600" name="RFC" />
</reference>


<reference target2="reference.RFC.2601.xml" anchor="RFC2601">
<front>
<title>ILMI-Based Server Discovery for ATMARP</title>
<author fullname="Mike Davison" initials="M." surname="Davison">
<organization>Cisco Systems</organization>

<address>
<postal>
<street>170 West Tasman Drive</street>
<city>San Jose</city>
<region>CA</region>
<code>95134</code>
<country>US</country>
</postal>

<phone>+1 408 526 4000</phone>
<email>mike.davison@cisco.com</email>
</address>
</author>

<date year="1999" month="June" />

<abstract>
<t>This memo defines how ILMI-based Server Discovery, which provides a method for ATM-attached hosts and routers to dynamically determine
 the ATM addresses of servers, shall be used to locate ATMARP servers.</t>
</abstract>
</front>

<seriesInfo value="2601" name="RFC" />
</reference>


<reference target2="reference.RFC.2602.xml" anchor="RFC2602">
<front>
<title>ILMI-Based Server Discovery for MARS</title>
<author fullname="Mike Davison" initials="M." surname="Davison">
<organization>Cisco Systems</organization>

<address>
<postal>
<street>170 West Tasman Drive</street>
<city>San Jose</city>
<region>CA</region>
<code>95134</code>
<country>US</country>
</postal>

<phone>+1 408 526 4000</phone>
<email>mike.davison@cisco.com</email>
</address>
</author>

<date year="1999" month="June" />

<abstract>
<t>This memo defines how ILMI-based Server Discovery, which provides a method for ATM-attached hosts and routers to dynamically determine the ATM addresses of servers, shall be used to locate MARS servers.</t>
</abstract>
</front>

<seriesInfo value="2602" name="RFC" />
</reference>


<reference target2="reference.RFC.2603.xml" anchor="RFC2603">
<front>
<title>ILMI-Based Server Discovery for NHRP</title>
<author fullname="Mike Davison" initials="M." surname="Davison">
<organization>Cisco Systems</organization>

<address>
<postal>
<street>170 West Tasman Drive</street>
<city>San Jose</city>
<region>CA</region>
<code>95134</code>
<country>US</country>
</postal>

<phone>+1 408 526 4000</phone>
<email>mike.davison@cisco.com</email>
</address>
</author>

<date year="1999" month="June" />

<abstract>
<t>This memo defines how ILMI-based Server Discovery, which provides a method for ATM-attached hosts and routers to dynamically determine the ATM addresses of servers, shall be used to locate NHRP servers.</t>
</abstract>
</front>

<seriesInfo value="2603" name="RFC" />
</reference>


<reference target2="reference.RFC.2604.xml" anchor="RFC2604">
<front>
<title abbrev="OTASP/OTAPA via ACAP">Wireless Device Configuration (OTASP/OTAPA) via ACAP</title>
<author fullname="Randall Gellens" initials="R." surname="Gellens">
<organization>QUALCOMM Incorporated</organization>

<address>
<postal>
<street>6455 Lusk Boulevard</street>
<city>San Diego</city>
<region>CA</region>
<code>92121-2779</code>
<country>US</country>
</postal>

<phone>+1 619 651 5115</phone>
<email>randy@qualcomm.com</email>
</address>
</author>

<date year="1999" month="June" />

<abstract>
<t>Wireless carriers today are faced with creating more efficient distribution channels, increasing customer satisfaction, while also improving margin and profitability.  Industry trends are pushing the sale of handsets further into the retail channel.  The cost and effort of provisioning handsets, activating users, and updating handset parameters can be greatly reduced by using over-the-air activation mechanisms.  A comprehensive and extensible means for over-the-air provisioning and handset parameter updating is required.</t>

<t>One approach is to purchase EIA/TIA/IS-683A (Over-the-air Service Provisioning of Mobile Stations in Spread Spectrum Systems) equipment.  The cost of this has led carriers to seek alternative solutions.  A very viable means for providing over-the-air (OTA) provisioning is to leverage the rollout of IS-707 data services equipment, which most carriers are in the process of deploying.  This paper presents an approach to OTA provisioning that utilizes the deployment of IS-707 to deliver OTA provisioning and parameter upgrading.</t>

<t>IS-707 data services makes available several methods of providing over-the-air provisioning and parameter updating.  A well thought-out approach utilizing Internet-based open standard mechanisms can provide an extensible platform for further carrier service offerings, enhanced interoperability among back-end services, and vendor independence.</t>

<t>This paper describes a viable and attractive means to provide OTASP/OTAPA via IS-707, using the ACAPprotocol.</t>
</abstract>
</front>

<seriesInfo value="2604" name="RFC" />
</reference>


<reference target2="reference.RFC.2605.xml" anchor="RFC2605">
<front>
<title>Directory Server Monitoring MIB</title>
<author fullname="Glenn Mansfield" initials="G." surname="Mansfield">
<organization>Cyber Solutions Inc.</organization>

<address>
<postal>
<street>6-6-3 Minami Yoshinari</street>
<city>Aoba-ku</city>
<region>Sendai</region>
<code>989-3204</code>
<country>JP</country>
</postal>

<phone>+81 22 3034012</phone>
<email>glenn@cysols.com</email>
</address>
</author>

<author fullname="Steve E. Kille" initials="S." surname="Kille">
<organization>MessagingDirect Ltd.</organization>

<address>
<postal>
<street>The Dome, The Square</street>
<city>Richmond</city>
<region>England</region>
<code>TW9 1DT</code>
<country>UK</country>
</postal>

<phone>+44 181 3329091</phone>
<email>Steve.Kille@MessagingDirect.com</email>
</address>
</author>

<date year="1999" month="June" />

<abstract>
<t>This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. This memo obsoletes RFC 1567, "X.500 Directory Monitoring MIB". This memo extends that specification to a more generic MIB for monitoring one or more directory servers each of which may support multiple access protocols. The MIB defined in this memo will be used in conjunction with the NETWORK-SERVICES-MIBfor monitoring Directory Servers.</t>
</abstract>
</front>

<seriesInfo value="2605" name="RFC" />
</reference>


<reference target2="reference.RFC.2606.xml" anchor="RFC2606">
<front>
<title>Reserved Top Level DNS Names</title>
<author fullname="Donald E. Eastlake 3rd" initials="D.E." surname="Eastlake">
<organization>IBM</organization>

<address>
<postal>
<street>65 Shindegan Hill Road</street>
<street>RR #1</street>
<city>Carmel</city>
<region>NY</region>
<code>10512</code>
<country>US</country>
</postal>

<phone>+1 914 276 1668</phone>
<facsimile>+1 914 784 3833</facsimile>
<email>dee3@us.ibm.com</email>
</address>
</author>

<author fullname="Aliza R. Panitz" initials="A." surname="Panitz">
<organization />

<address>
<postal>
<street>500 Stamford Dr. No. 310</street>
<city>Newark</city>
<region>DE</region>
<code>19711</code>
<country>US</country>
</postal>

<phone>+1 302 738 1554</phone>
<email>buglady@fuschia.net</email>
</address>
</author>

<date year="1999" month="June" />

<abstract>
<t>To reduce the likelihood of conflict and confusion, a few top level domain names are reserved for use in private testing, as examples in documentation, and the like.  In addition, a few second level domain names reserved for use as examples are documented.</t>
</abstract>
</front>

<seriesInfo value="32" name="BCP" />
<seriesInfo value="2606" name="RFC" />
</reference>


<reference target2="reference.RFC.2607.xml" anchor="RFC2607">
<front>
<title abbrev="Proxy Chaining and Policy in Roaming">Proxy Chaining and Policy Implementation in Roaming</title>
<author fullname="Bernard Aboba" initials="B." surname="Aboba">
<organization>Microsoft Corporation</organization>

<address>
<postal>
<street>One Microsoft Way</street>
<city>Redmond</city>
<region>WA</region>
<code>98052</code>
<country>US</country>
</postal>

<phone>+1 425 936 6605</phone>
<email>bernarda@microsoft.com</email>
</address>
</author>

<author fullname="John R. Vollbrecht" initials="J." surname="Vollbrecht">
<organization>Merit Network, Inc.</organization>

<address>
<postal>
<street>4251 Plymouth Rd.</street>
<city>Ann Arbor</city>
<region>MI</region>
<code>48105-2785</code>
<country>US</country>
</postal>

<phone>+1 313 763 1206</phone>
<email>jrv@merit.edu</email>
</address>
</author>

<date year="1999" month="June" />

<abstract>
<t>This document describes how proxy chaining and policy implementation can be supported in roaming systems. The mechanisms described in this document are in current use.</t>

<t>However, as noted in the security considerations section, the techniques outlined in this document are vulnerable to attack from external parties as well as susceptible to fraud perpetrated by the roaming partners themselves. As a result, such methods are not suitable for wide-scale deployment on the Internet.</t>
</abstract>
</front>

<seriesInfo value="2607" name="RFC" />
</reference>


<reference target2="reference.RFC.2608.xml" anchor="RFC2608">
<front>
<title>Service Location Protocol, Version 2</title>
<author fullname="Erik Guttman" initials="E." surname="Guttman">
<organization>Sun Microsystems</organization>

<address>
<postal>
<street>Bahnstr. 2</street>
<city>Waibstadt</city>
<region />
<code>74915</code>
<country>DE</country>
</postal>

<phone>+49 7263 911701</phone>
<email>Erik.Guttman@sun.com</email>
</address>
</author>

<author fullname="Charles Perkins" initials="C." surname="Perkins">
<organization>Sun Microsystems</organization>

<address>
<postal>
<street>901 San Antonio Road</street>
<city>Mountain View</city>
<region>CA</region>
<code>94040</code>
<country>US</country>
</postal>

<phone>+1 650 786 6464</phone>
<email>cperkins@sun.com</email>
</address>
</author>

<author fullname="John Veizades" initials="J." surname="Veizades">
<organization>@Home Network</organization>

<address>
<postal>
<street>425 Broadway Street</street>
<city>Redwood City</city>
<region>CA</region>
<code>94063</code>
<country>US</country>
</postal>

<phone>+1 650 569 5243</phone>
<email>veizades@home.net</email>
</address>
</author>

<author fullname="Michael Day" initials="M." surname="Day">
<organization>Vinca Corporation.</organization>

<address>
<postal>
<street>1201 North 800 East</street>
<city>Orem</city>
<region>UT</region>
<code>84097</code>
<country>US</country>
</postal>

<phone>+1 801 376 5083</phone>
<email>mday@vinca.com</email>
</address>
</author>

<date year="1999" month="June" />

<abstract>
<t>The Service Location Protocol provides a scalable framework for the discovery and selection of network services.  Using this protocol, computers using the Internet need little or no static configuration of network services for network based applications.  This is especially important as computers become more portable, and users
 less tolerant or able to fulfill the demands of network system administration.</t>
</abstract>
</front>

<seriesInfo value="2608" name="RFC" />
</reference>


<reference target2="reference.RFC.2609.xml" anchor="RFC2609">
<front>
<title abbrev="Service Templates and URLs">Service Templates and Service: Schemes</title>
<author fullname="Erik Guttman" initials="E." surname="Guttman">
<organization>Sun Microsystems</organization>

<address>
<postal>
<street>Bahnstr.  2</street>
<city>Waibstadt</city>
<region />
<code>74915</code>
<country>DE</country>
</postal>

<phone>+49 7263 911484</phone>
<facsimile>+1 650 786 5992</facsimile>
<email>erik.guttman@sun.com</email>
</address>
</author>

<author fullname="Charles E. Perkins" initials="C." surname="Perkins">
<organization>Sun Microsystems</organization>

<address>
<postal>
<street>15 Network Circle</street>
<city>Menlo Park</city>
<region>CA</region>
<code>94025</code>
<country>US</country>
</postal>

<phone>+1 650 786 6464</phone>
<facsimile>+1 650 786 6445</facsimile>
<email>cperkins@sun.com</email>
</address>
</author>

<author fullname="James Kempf" initials="J." surname="Kempf">
<organization>Sun Microsystems</organization>

<address>
<postal>
<street>15 Network Circle</street>
<city>Menlo Park</city>
<region>CA</region>
<code>94025</code>
<country>US</country>
</postal>

<phone>+1 650 786 5890</phone>
<facsimile>+1 650 786 6445</facsimile>
<email>james.kempf@sun.com</email>
</address>
</author>

<date year="1999" month="June" />

<abstract>
<t>The "service:" URL scheme name is used to define URLs (called "service: URLs" in this document) that are primarily intended to be used by the Service Location Protocol in order to distribute service access information.  These schemes provide an extensible framework for client-based network software to obtain configuration information required to make use of network services.  When registering a service: URL, the URL is accompanied by a set of well-defined attributes which define the service.  These attributes convey configuration information to client software, or service characteristics meaningful to end users.</t>

<t>This document describes a formal procedure for defining and standardizing new service types and attributes for use with the service:" scheme.  The formal descriptions of service types and attributes are templates that are human and machine understandable. They SHOULD be used by administrative tools to parse service
   registration information and by client applications to provide localized translations of service attribute strings.</t>
</abstract>
</front>

<seriesInfo value="2609" name="RFC" />
</reference>


<reference target2="reference.RFC.2610.xml" anchor="RFC2610">
<front>
<title>DHCP Options for Service Location Protocol</title>
<author fullname="Charles E. Perkins" initials="C." surname="Perkins">
<organization>Sun Microsystems, Inc., Technology Development Group</organization>

<address>
<postal>
<street>15 Network Circle</street>
<street>Mail Stop MPK15-214</street>
<city>Menlo Park</city>
<region>CA</region>
<code>94025</code>
<country>US</country>
</postal>

<phone>+1 650 786 6464</phone>
<facsimile>+1 650 786 6445</facsimile>
<email>Charles.Perkins@Sun.Com</email>
<uri>http://www.svrloc.org/~charliep</uri>
</address>
</author>

<author fullname="Erik Guttman" initials="E." surname="Guttman">
<organization>Sun Microsystems, Inc., Technology Development Group</organization>

<address>
<postal>
<street>Bahnstr. 2</street>
<street>Mail Stop UFRA02</street>
<city>Waibstadt</city>
<region />
<code>74915</code>
<country>DE</country>
</postal>

<phone>+49 7263 911701</phone>
<facsimile>+1 650 786 5992</facsimile>
<email>Erik.Guttman@Sun.Com</email>
</address>
</author>

<date year="1999" month="June" />

<abstract>
<t>The Dynamic Host Configuration Protocol provides a framework for passing configuration information to hosts on a TCP/IP network. Entities using the Service Location Protocol need to find out the address of Directory Agents in order to transact messages.  Another option provides an assignment of scope for configuration of SLP User and Service Agents.</t>
</abstract>
</front>

<seriesInfo value="2610" name="RFC" />
</reference>


<reference target2="reference.RFC.2611.xml" anchor="RFC2611">
<front>
<title>URN Namespace Definition Mechanisms</title>
<author fullname="Leslie L. Daigle" initials="L." surname="Daigle">
<organization>Thinking Cat Enterprises</organization>

<address>
<email>leslie@thinkingcat.com</email>
</address>
</author>

<author fullname="Dirk-Willem van Gulik" initials="D." surname="van Gulik">
<organization>ISIS/STA/CEO - TP 270, Joint Research Centre Ispra</organization>

<address>
<postal>
<street />
<city>Ispra</city>
<region />
<code>21020</code>
<country>IT</country>
</postal>

<phone>+39 332 789549</phone>
<facsimile>+39 332 789185</facsimile>
<email>Dirk.vanGulik@jrc.it</email>
</address>
</author>

<author fullname="Renato Iannella" initials="R." surname="Iannella">
<organization>DSTC Pty Ltd</organization>

<address>
<postal>
<street>The Uni of Queensland</street>
<street>Gehrmann Labs</street>
<city />
<region />
<code>4072</code>
<country>AU</country>
</postal>

<phone>+61 7 33654310</phone>
<facsimile>+61 7 33654311</facsimile>
<email>renato@dstc.edu.au</email>
</address>
</author>

<author fullname="Patrik Faltstrom" initials="P." surname="Faltstrom">
<organization>Tele2/Swipnet</organization>

<address>
<postal>
<street>Borgarfjordsgatan 16</street>
<street>P.O. Box 62</street>
<city>Kista</city>
<region />
<code>S-164 94</code>
<country>SE</country>
</postal>

<phone>+46 56 264000</phone>
<facsimile>+46 56 264200</facsimile>
<email>paf@swip.net</email>
</address>
</author>

<date year="1999" month="June" />

<abstract>
<t>The URN WG has defined a syntax for Uniform Resource Names (URNs), as well as some proposed mechanisms for their resolution and use in Internet applications,. The whole rests on the concept of individual "namespaces" within the URN structure.  Apart from  proof-of-concept namespaces, the use of existing identifiers in URNs has been discussed, and this document lays out general definitions of and mechanisms for establishing URN "namespaces".</t>
</abstract>
</front>

<seriesInfo value="33" name="BCP" />
<seriesInfo value="2611" name="RFC" />
</reference>


<reference target2="reference.RFC.2612.xml" anchor="RFC2612">
<front>
<title>The CAST-256 Encryption Algorithm</title>
<author fullname="Carlisle Adams" initials="C." surname="Adams">
<organization>Entrust Technologies</organization>

<address>
<postal>
<street>750 Heron Road</street>
<street>Suite E08</street>
<city>Ottawa</city>
<region>Ontario</region>
<code>K1V 1A7</code>
<country>CA</country>
</postal>

<phone>+1 613 247 3180</phone>
<facsimile>+1 613 247 3690</facsimile>
<email>carlisle.adams@entrust.com</email>
</address>
</author>

<author fullname="Jeff Gilchrist" initials="J." surname="Gilchrist">
<organization>Entrust Technologies</organization>

<address>
<postal>
<street>750 Heron Road</street>
<street>Suite E08 *</street>
<city>Ottawa</city>
<region>Ontario</region>
<code>K1V 1A7</code>
<country>CA</country>
</postal>

<phone>+1 613 248 3074</phone>
<facsimile>+1 613 247 3450</facsimile>
<email>jeff.gilchrist@entrust.com</email>
</address>
</author>

<date year="1999" month="June" />

<abstract>
<t>There is always a desire in the Internet community for unencumbered encryption algorithms with a range of key sizes that can provide security for a variety of cryptographic applications and protocols.</t>

<t>This document describes an existing algorithm that can be used to satisfy this requirement.  Included are a description of the cipher and the key scheduling algorithm, the s-boxes, and a set of test vectors (Appendix A).</t>
</abstract>
</front>

<seriesInfo value="2612" name="RFC" />
</reference>


<reference target2="reference.RFC.2613.xml" anchor="RFC2613">
<front>
<title abbrev="SMON MIB">Remote Network Monitoring MIB Extensions for Switched Networks Version 1.0</title>
<author fullname="Richard Waterman" initials="R." surname="Waterman">
<organization>Allot Communications</organization>

<address>
<postal>
<street>292 E. Main St.</street>
<city>Los Gatos</city>
<region>CA</region>
<code>95030</code>
<country>US</country>
</postal>

<phone>+1 408 399 3154</phone>
<email>rich@allot.com</email>
</address>
</author>

<author fullname="Bill Lahaye" initials="B." surname="Lahaye">
<organization>Xylan Corporation</organization>

<address>
<postal>
<street>26707 W. Agoura Rd.</street>
<city>Calabasas</city>
<region>CA</region>
<code>91302</code>
<country>US</country>
</postal>

<phone>+1 800 995 2612</phone>
<email>bill.lahaye@xylan.com</email>
</address>
</author>

<author fullname="Dan Romascanu" initials="D." surname="Romascanu">
<organization>Lucent Technologies</organization>

<address>
<postal>
<street>Atidim Technology Park</street>
<street>Bldg. #3</street>
<city>Tel Aviv</city>
<region />
<code>61131</code>
<country>IL</country>
</postal>

<phone>+972 3 6458414</phone>
<email>dromasca@lucent.com</email>
</address>
</author>

<author fullname="Steven Waldbusser" initials="S." surname="Waldbusser">
<organization>International Network Services (INS)</organization>

<address>
<postal>
<street>1213 Innsbruck Dr.</street>
<city>Sunnyvale</city>
<region>CA</region>
<code>94089</code>
<country>US</country>
</postal>

<phone>+1 650 318 1251</phone>
<email>waldbusser@ins.com</email>
</address>
</author>

<date year="1999" month="June" />

<abstract>
<t>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 remote network monitoring devices in switched networks environments.</t>
</abstract>
</front>

<seriesInfo value="2613" name="RFC" />
</reference>


<reference target2="reference.RFC.2614.xml" anchor="RFC2614">
<front>
<title abbrev="Service Location API">An API for Service Location</title>
<author fullname="James Kempf" initials="J." surname="Kempf">
<organization>Sun Microsystems</organization>

<address>
<postal>
<street>901 San Antonio Rd.</street>
<city>Palo Alto</city>
<region>CA</region>
<code>94303</code>
<country>US</country>
</postal>

<phone>+1 650 786 5890</phone>
<facsimile>+1 650 786 6445</facsimile>
<email>james.kempf@sun.com</email>
</address>
</author>

<author fullname="Erik Guttman" initials="E." surname="Guttman">
<organization>Sun Microsystems</organization>

<address>
<postal>
<street>Bahnstr. 2</street>
<city>Waibstadt</city>
<region />
<code>74915</code>
<country>DE</country>
</postal>

<phone>+49 7263 911701</phone>
<email>erik.guttman@sun.com</email>
</address>
</author>

<date year="1999" month="June" />

<abstract>
<t>The Service Location Protocol (SLP) provides a new way for clients to dynamically discovery network services.  With SLP, it is simple to offer highly available services that require no user configuration or assistance from network administrators prior to use.  This document describes standardized APIs for SLP in C and Java.  The APIs are modular and are designed to allow implementations to offer just the feature set needed.  In addition, standardized file formats for configuration and serialized registrations are defined, allowing SLP agents to set network and other parameters in a portable way.  The serialized file format allows legacy services to be registered with SLP directory agents in cases where modifying the legacy service program code is difficult or impossible, and to portably exchange a registration database.</t>
</abstract>
</front>

<seriesInfo value="2614" name="RFC" />
</reference>


<reference target2="reference.RFC.2615.xml" anchor="RFC2615">
<front>
<title>PPP over SONET/SDH</title>
<author fullname="Andrew G. Malis" initials="A." surname="Malis">
<organization>Ascend Communications, Inc.</organization>

<address>
<postal>
<street>1 Robbins Road</street>
<city>Andover</city>
<region>MA</region>
<code>01810</code>
<country>US</country>
</postal>

<phone>+1 978 952 7414</phone>
<email>malis@ascend.com</email>
</address>
</author>

<author fullname="William Allen Simpson" initials="W." surname="Simpson">
<organization>DayDreamer, Computer Systems Consulting Services</organization>

<address>
<postal>
<street>1384 Fontaine</street>
<city>Madison Heights</city>
<region>MI</region>
<code>48071</code>
<country>US</country>
</postal>

<email>wsimpson@GreenDragon.com</email>
</address>
</author>

<date year="1999" month="June" />

<abstract>
<t>The Point-to-Point Protocol (PPP)provides a standard method for transporting multi-protocol datagrams over point-to-point links. This document describes the use of PPP over Synchronous Optical Network (SONET) and Synchronous Digital Hierarchy (SDH) circuits.</t>

<t>This document replaces and obsoletes RFC 1619.  See section 7 for a summary of the changes from RFC 1619.</t>
</abstract>
</front>

<seriesInfo value="2615" name="RFC" />
</reference>


<reference target2="reference.RFC.2616.xml" anchor="RFC2616">
<front>
<title abbrev="HTTP/1.1">Hypertext Transfer Protocol -- HTTP/1.1</title>
<author fullname="Roy T. Fielding" initials="R." surname="Fielding">
<organization abbrev="UC Irvine">Department of Information and Computer Science</organization>

<address>
<postal>
<street>University of California, Irvine</street>
<city>Irvine</city>
<region>CA</region>
<code>92697-3425</code>
</postal>

<facsimile>+1(949)824-1715</facsimile>
<email>fielding@ics.uci.edu</email>
</address>
</author>

<author fullname="James Gettys" initials="J." surname="Gettys">
<organization abbrev="Compaq/W3C">World Wide Web Consortium</organization>

<address>
<postal>
<street>MIT Laboratory for Computer Science, NE43-356</street>
<street>545 Technology Square</street>
<city>Cambridge</city>
<region>MA</region>
<code>02139</code>
</postal>

<facsimile>+1(617)258-8682</facsimile>
<email>jg@w3.org</email>
</address>
</author>

<author fullname="Jeffrey C. Mogul" initials="J." surname="Mogul">
<organization abbrev="Compaq">Compaq Computer Corporation</organization>

<address>
<postal>
<street>Western Research Laboratory</street>
<street>250 University Avenue</street>
<city>Palo Alto</city>
<region>CA</region>
<code>94305</code>
</postal>

<email>mogul@wrl.dec.com</email>
</address>
</author>

<author fullname="Henrik Frystyk Nielsen" initials="H." surname="Frystyk">
<organization abbrev="MIT/LCS">World Wide Web Consortium</organization>

<address>
<postal>
<street>MIT Laboratory for Computer Science, NE43-356</street>
<street>545 Technology Square</street>
<city>Cambridge</city>
<region>MA</region>
<code>02139</code>
</postal>

<facsimile>+1(617)258-8682</facsimile>
<email>frystyk@w3.org</email>
</address>
</author>

<author fullname="Larry Masinter" initials="L." surname="Masinter">
<organization abbrev="Xerox">Xerox Corporation</organization>

<address>
<postal>
<street>MIT Laboratory for Computer Science, NE43-356</street>
<street>3333 Coyote Hill Road</street>
<city>Palo Alto</city>
<region>CA</region>
<code>94034</code>
</postal>

<email>masinter@parc.xerox.com</email>
</address>
</author>

<author fullname="Paul J. Leach" initials="P." surname="Leach">
<organization abbrev="Microsoft">Microsoft Corporation</organization>

<address>
<postal>
<street>1 Microsoft Way</street>
<city>Redmond</city>
<region>WA</region>
<code>98052</code>
</postal>

<email>paulle@microsoft.com</email>
</address>
</author>

<author fullname="Tim Berners-Lee" initials="T." surname="Berners-Lee">
<organization abbrev="MIT/LCS">World Wide Web Consortium</organization>

<address>
<postal>
<street>MIT Laboratory for Computer Science, NE43-356</street>
<street>545 Technology Square</street>
<city>Cambridge</city>
<region>MA</region>
<code>02139</code>
</postal>

<facsimile>+1(617)258-8682</facsimile>
<email>timbl@w3.org</email>
</address>
</author>

<date year="1999" month="June" />

<abstract>
<t>
   The Hypertext Transfer Protocol (HTTP) is an application-level
   protocol for distributed, collaborative, hypermedia information
   systems. It is a generic, stateless, protocol which can be used for
   many tasks beyond its use for hypertext, such as name servers and
   distributed object management systems, through extension of its
   request methods, error codes and headers . A feature of HTTP is
   the typing and negotiation of data representation, allowing systems
   to be built independently of the data being transferred.
</t>

<t>
   HTTP has been in use by the World-Wide Web global information
   initiative since 1990. This specification defines the protocol
   referred to as "HTTP/1.1", and is an update to RFC 2068 .
</t>
</abstract>
</front>

<seriesInfo value="2616" name="RFC" />
<format octets="498891" type="HTML" target="http://xml.resource.org/public/rfc/html/rfc2616.html" />
<format octets="471630" type="XML" target="http://xml.resource.org/public/rfc/xml/rfc2616.xml" />
</reference>


<reference target2="reference.RFC.2617.xml" anchor="RFC2617">
<front>
<title abbrev="HTTP Authentication">HTTP Authentication: Basic and Digest Access Authentication</title>
<author fullname="John Franks" initials="J." surname="Franks">
<organization>Northwestern University, Department of Mathematics</organization>

<address>
<postal>
<street />
<city>Evanston</city>
<region>IL</region>
<code>60208-2730</code>
<country>US</country>
</postal>

<email>john@math.nwu.edu</email>
</address>
</author>

<author fullname="Phillip M. Hallam-Baker" initials="P.M." surname="Hallam-Baker">
<organization>Verisign Inc.</organization>

<address>
<postal>
<street>301 Edgewater Place</street>
<street>Suite 210</street>
<city>Wakefield</city>
<region>MA</region>
<code>01880</code>
<country>US</country>
</postal>

<email>pbaker@verisign.com</email>
</address>
</author>

<author fullname="Jeffery L. Hostetler" initials="J.L." surname="Hostetler">
<organization>AbiSource, Inc.</organization>

<address>
<postal>
<street>6 Dunlap Court</street>
<city>Savoy</city>
<region>IL</region>
<code>61874</code>
<country>US</country>
</postal>

<email>jeff@AbiSource.com</email>
</address>
</author>

<author fullname="Scott D. Lawrence" initials="S.D." surname="Lawrence">
<organization>Agranat Systems, Inc.</organization>

<address>
<postal>
<street>5 Clocktower Place</street>
<street>Suite 400</street>
<city>Maynard</city>
<region>MA</region>
<code>01754</code>
<country>US</country>
</postal>

<email>lawrence@agranat.com</email>
</address>
</author>

<author fullname="Paul J. Leach" initials="P.J." surname="Leach">
<organization>Microsoft Corporation</organization>

<address>
<postal>
<street>1 Microsoft Way</street>
<city>Redmond</city>
<region>WA</region>
<code>98052</code>
<country>US</country>
</postal>

<email>paulle@microsoft.com</email>
</address>
</author>

<author fullname="Ari Luotonen" initials="A." surname="Luotonen">
<organization>Netscape Communications Corporation</organization>

<address>
<postal>
<street>501 East Middlefield Road</street>
<city>Mountain View</city>
<region>CA</region>
<code>94043</code>
<country>US</country>
</postal>

</address>
</author>

<author fullname="Lawrence C. Stewart" initials="L." surname="Stewart">
<organization>Open Market, Inc.</organization>

<address>
<postal>
<street>215 First Street</street>
<city>Cambridge</city>
<region>MA</region>
<code>02142</code>
<country>US</country>
</postal>

<email>stewart@OpenMarket.com</email>
</address>
</author>

<date year="1999" month="June" />

<abstract>
<t>"HTTP/1.0", includes the specification for a Basic Access  Authentication scheme. This scheme is not considered to be a secure method of user authentication (unless used in conjunction with some external secure system such as SSL, as the user name and password are passed over the network as cleartext.</t>

<t>This document also provides the specification for HTTP's authentication framework, the original Basic authentication scheme and a scheme based on cryptographic hashes, referred to as "Digest Access Authentication".  It is therefore also intended to serve as a replacemen for RFC 2069.  Some optional elements specified by  RFC 2069 have been removed from this specification due to problems found since its publication; other new elements have been added for
   compatibility, those new elements have been made optional, but are strongly recommended.</t>

<t>Like Basic, Digest access authentication verifies that both parties to a communication know a shared secret (a password); unlike Basic,  this verification can be done without sending the password in the clear, which is Basic's biggest weakness. As with most other authentication protocols, the greatest sources of risks are usually  found not in the core protocol itself but in policies and procedures surrounding its use.</t>
</abstract>
</front>

<seriesInfo value="2617" name="RFC" />
</reference>


<reference target2="reference.RFC.2618.xml" anchor="RFC2618">
<front>
<title>RADIUS Authentication Client MIB</title>
<author fullname="Bernard Aboba" initials="B." surname="Aboba">
<organization>Microsoft Corporation</organization>

<address>
<postal>
<street>One Microsoft Way</street>
<city>Redmond</city>
<region>WA</region>
<code>98052</code>
<country>US</country>
</postal>

<phone>+1 425 936 6605</phone>
<email>bernarda@microsoft.com</email>
</address>
</author>

<author fullname="Glen Zorn" initials="G." surname="Zorn">
<organization>Microsoft Corporation</organization>

<address>
<postal>
<street>One Microsoft Way</street>
<city>Redmond</city>
<region>WA</region>
<code>98052</code>
<country>US</country>
</postal>

<phone>+1 425 703 1559</phone>
<email>glennz@microsoft.com</email>
</address>
</author>

<date year="1999" month="June" />

<abstract>
<t>This memo defines a set of extensions which instrument RADIUS authentication client functions. These extensions represent a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community.  Using these extensions IP-based management stations can manage RADIUS authentication clients.</t>
</abstract>
</front>

<seriesInfo value="2618" name="RFC" />
</reference>


<reference target2="reference.RFC.2619.xml" anchor="RFC2619">
<front>
<title>RADIUS Authentication Server MIB</title>
<author fullname="Glen Zorn" initials="G." surname="Zorn">
<organization>Microsoft Corporation</organization>

<address>
<postal>
<street>One Microsoft Way</street>
<city>Redmond</city>
<region>WA</region>
<code>98052</code>
<country>US</country>
</postal>

<phone>+1 425 703 1559</phone>
<email>glennz@microsoft.com</email>
</address>
</author>

<author fullname="Bernard Aboba" initials="B." surname="Aboba">
<organization>Microsoft Corporation</organization>

<address>
<postal>
<street>One Microsoft Way</street>
<city>Redmond</city>
<region>WA</region>
<code>98052</code>
<country>US</country>
</postal>

<phone>+1 425 936 6605</phone>
<email>bernarda@microsoft.com</email>
</address>
</author>

<date year="1999" month="June" />

<abstract>
<t>This memo defines a set of extensions which instrument RADIUS authentication server functions. These extensions represent a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community.  Using these extensions IP-based management stations can manage RADIUS authentication servers.</t>
</abstract>
</front>

<seriesInfo value="2619" name="RFC" />
</reference>


<reference target2="reference.RFC.2620.xml" anchor="RFC2620">
<front>
<title>RADIUS Accounting Client MIB</title>
<author fullname="Bernard Aboba" initials="B." surname="Aboba">
<organization>Microsoft Corporation</organization>

<address>
<postal>
<street>One Microsoft Way</street>
<city>Redmond</city>
<region>WA</region>
<code>98052</code>
<country>US</country>
</postal>

<phone>+1 425 936 6605</phone>
<email>bernarda@microsoft.com</email>
</address>
</author>

<author fullname="Glen Zorn" initials="G." surname="Zorn">
<organization>Microsoft Corporation</organization>

<address>
<postal>
<street>One Microsoft Way</street>
<city>Redmond</city>
<region>WA</region>
<code>98052</code>
<country>US</country>
</postal>

<phone>+1 425 703 1559</phone>
<email>glennz@microsoft.com</email>
</address>
</author>

<date year="1999" month="June" />

<abstract>
<t>This memo defines a set of extensions which instrument RADIUS accounting client functions. These extensions represent a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community.  Using these extensions IP-based management stations can manage RADIUS accounting clients.</t>
</abstract>
</front>

<seriesInfo value="2620" name="RFC" />
</reference>


<reference target2="reference.RFC.2621.xml" anchor="RFC2621">
<front>
<title>RADIUS Accounting Server MIB</title>
<author fullname="Glen Zorn" initials="G." surname="Zorn">
<organization>Microsoft Corporation</organization>

<address>
<postal>
<street>One Microsoft Way</street>
<city>Redmond</city>
<region>WA</region>
<code>98052</code>
<country>US</country>
</postal>

<phone>+1 425 703 1559</phone>
<email>glennz@microsoft.com</email>
</address>
</author>

<author fullname="Bernard Aboba" initials="B." surname="Aboba">
<organization>Microsoft Corporation</organization>

<address>
<postal>
<street>One Microsoft Way</street>
<city>Redmond</city>
<region>WA</region>
<code>98052</code>
<country>US</country>
</postal>

<phone>+1 425 936 6605</phone>
<email>bernarda@microsoft.com</email>
</address>
</author>

<date year="1999" month="June" />

<abstract>
<t>This memo defines a set of extensions which instrument RADIUS accounting server functions. These extensions represent a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community.  Using these extensions IP-based management stations can manage RADIUS accounting servers.</t>
</abstract>
</front>

<seriesInfo value="2621" name="RFC" />
</reference>


<reference target2="reference.RFC.2622.xml" anchor="RFC2622">
<front>
<title abbrev="RPSL">Routing Policy Specification Language (RPSL)</title>
<author fullname="Cengiz Alaettinoglu" initials="C." surname="Alaettinoglu">
<organization>USC/Information Sciences Institute</organization>

<address>
<postal>
<street>4676 Admiralty Way</street>
<city>Marina del Rey</city>
<region>CA</region>
<code>90291</code>
<country>US</country>
</postal>

<phone>+1 213 822 1511</phone>
<email>cengiz@isi.edu</email>
</address>
</author>

<author fullname="Curtis Villamizar" initials="C." surname="Villamizar">
<organization>Avici Systems</organization>

<address>
<email>curtis@avici.com</email>
</address>
</author>

<author fullname="Elise Gerich" initials="E." surname="Gerich">
<organization>At Home Network</organization>

<address>
<email>epg@home.net</email>
</address>
</author>

<author fullname="David Kessens" initials="D." surname="Kessens">
<organization>Qwest Communications</organization>

<address>
<email>David.Kessens@qwest.net</email>
</address>
</author>

<author fullname="David Meyer" initials="D." surname="Meyer">
<organization>University of Oregon</organization>

<address>
<email>meyer@antc.uoregon.edu</email>
</address>
</author>

<author fullname="Tony Bates" initials="T." surname="Bates">
<organization>Cisco Systems, Inc.</organization>

<address>
<email>tbates@cisco.com</email>
</address>
</author>

<author fullname="Daniel Karrenberg" initials="D." surname="Karrenberg">
<organization>RIPE NCC</organization>

<address>
<email>dfk@ripe.net</email>
</address>
</author>

<author fullname="Marten Terpstra" initials="M." surname="Terpstra">
<organization>Bay Networks, Inc.</organization>

<address>
<email>marten@BayNetworks.com</email>
</address>
</author>

<date year="1999" month="June" />

<abstract>
<t>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.</t>
</abstract>
</front>

<seriesInfo value="2622" name="RFC" />
</reference>


<reference target2="reference.RFC.2623.xml" anchor="RFC2623">
<front>
<title abbrev="NFS Security, RPCSEC_GSS, and Kerberos V5">NFS Version 2 and Version 3 Security Issues and the NFS Protocol's Use of RPCSEC_GSS and Kerberos V5</title>
<author fullname="Mike Eisler" initials="M." surname="Eisler">
<organization>Sun Microsystems, Inc.</organization>

<address>
<postal>
<street>5565 Wilson Road</street>
<city>Colorado Springs</city>
<region>CO</region>
<code>80919</code>
<country>US</country>
</postal>

<phone>+1 719 599 9026</phone>
<email>mre@eng.sun.com</email>
</address>
</author>

<date year="1999" month="June" />

<abstract>
<t>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.</t>

<t>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.</t>
</abstract>
</front>

<seriesInfo value="2623" name="RFC" />
</reference>


<reference target2="reference.RFC.2624.xml" anchor="RFC2624">
<front>
<title abbrev="NFSv4 Design Considerations">NFS Version 4 Design Considerations</title>
<author fullname="Spencer Shepler" initials="S." surname="Shepler">
<organization>Sun Microsystems, Inc.</organization>

<address>
<postal>
<street>7808 Moonflower Drive</street>
<city>Austin</city>
<region>TX</region>
<code>78750</code>
<country>US</country>
</postal>

<phone>+1 512 349 9376</phone>
<email>spencer.shepler@eng.sun.com</email>
</address>
</author>

<date year="1999" month="June" />

<abstract>
<t>The main task of the NFS version 4 working group is to create a protocol definition for a distributed file system that focuses on the following items: improved access and good performance on the Internet, strong security with negotiation built into the protocol, better cross-platform interoperability, and designed for protocol extensions.  NFS version 4 will owe its general design to the previous versions of NFS.  It is expected, however, that many features will be quite different in NFS version 4 than previous versions to facilitate the goals of the working group and to address areas that NFS version 2 and 3 have not.</t>

<t>This design considerations document is meant to present more detail than the working group charter.  Specifically, it presents the areas that the working group will investigate and consider while developing a protocol specification for NFS version 4.  Based on this investigation the working group will decide the features of the new protocol based on the cost and benefits within the specific feature areas.</t>
</abstract>

<note title="Key Words">
<t>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.</t>
</note>
</front>

<seriesInfo value="2624" name="RFC" />
</reference>


<reference target2="reference.RFC.2625.xml" anchor="RFC2625">
<front>
<title>IP and ARP over Fibre Channel</title>
<author fullname="M. Rajagopal" initials="M." surname="Rajagopal">
<organization>Gadzoox Networks, Inc.</organization>

<address>
<postal>
<street>711 Kimberly Avenue</street>
<street>Suite 100</street>
<city>Placentia</city>
<region>CA</region>
<code>92870</code>
<country>US</country>
</postal>

<phone>+1 714 577 6805</phone>
<email>murali@gadzoox.com</email>
</address>
</author>

<author fullname="R. Bhagwat" initials="R." surname="Bhagwat">
<organization>Gadzoox Networks, Inc.</organization>

<address>
<postal>
<street>711 Kimberly Avenue</street>
<street>Suite 100</street>
<city>Placentia</city>
<region>CA</region>
<code>92870</code>
<country>US</country>
</postal>

<phone>+1 714 577 6806</phone>
<email>raj@gadzoox.com</email>
</address>
</author>

<author fullname="W. Rickard" initials="W." surname="Rickard">
<organization>Gadzoox Networks, Inc.</organization>

<address>
<postal>
<street>711 Kimberly Avenue</street>
<street>Suite 100</street>
<city>Placentia</city>
<region>CA</region>
<code>92870</code>
<country>US</country>
</postal>

<phone>+1 714 577 6803</phone>
<email>wayne@gadzoox.com</email>
</address>
</author>

<date year="1999" month="June" />

<abstract>
<t>Fibre Channel (FC) is a high speed serial interface technology that  supports several higher layer protocols including Small Computer System Interface (SCSI) and Internet Protocol(IP). Until now, SCSI has been the only widely used protocol over FC.Existing FC standardsdo not adequately specify how IP packets may be transported over  FC and how IP addresses are resolved to FC addresses. The purpose of this document is to specify a way of encapsulating IP and Address Resolution Protocol(ARP) over Fibre Channel and also to describe a mechanism(s) for IP address resolution.</t>
</abstract>
</front>

<seriesInfo value="2625" name="RFC" />
</reference>


<reference target2="reference.RFC.2626.xml" anchor="RFC2626">
<front>
<title abbrev="The Internet and the Millennium Problem">The Internet and the Millennium Problem (Year 2000)</title>
<author fullname="Philip Nesser II" initials="P." surname="Nesser">
<organization>Nesser &amp; Nesser Consulting</organization>
&amp;


<address>
<postal>
<street>13501 100th Ave N.E.</street>
<street>Suite 5202</street>
<city>Redmond</city>
<region>WA</region>
<code>98052</code>
<country>US</country>
</postal>

<phone>+1 425 481 4303</phone>
<email>pjnesser@nesser.com</email>
</address>
</author>

<date year="1999" month="June" />

<abstract>
<t>The Year 2000 Working Group (WG) has conducted an investigation into the millennium problem as it regards Internet related protocols. This investigation only targeted the protocols as documented in the Request For Comments Series (RFCs). This investigation discovered little reason for concern with regards to the functionality of the protocols. A few minor cases of older implementations still using two digit years (ala RFC 850) were discovered, but almost all
Internet protocols were given a clean bill of health. Several cases of "period" problems were discovered, where a time field would "roll over" as the size of field was reached. In particular, there are several protocols, which have 32 bit, signed integer representations of the number of seconds since January 1, 1970 which will turn negative at Tue Jan 19 03:14:07 GMT 2038. Areas whose protocols will be effected by such problems have been notified so that new revisions
will remove this limitation.</t>
</abstract>
</front>

<seriesInfo value="2626" name="RFC" />
</reference>


<reference target2="reference.RFC.2627.xml" anchor="RFC2627">
<front>
<title abbrev="Key Management for Multicast">Key Management for Multicast: Issues and Architectures</title>
<author fullname="Debby M. Wallner" initials="D." surname="Wallner">
<organization>National Security Agency</organization>

<address>
<postal>
<street>9800 Savage Road</street>
<street>Suite 6451</street>
<street>Attn: R2</street>
<city>Fort Meade</city>
<region>MD</region>
<code>20755-6451</code>
<country>US</country>
</postal>

<phone>+1 301 688 0331</phone>
<email>dmwalln@orion.ncsc.mil</email>
</address>
</author>

<author fullname="Eric J. Harder" initials="E." surname="Harder">
<organization>National Security Agency</organization>

<address>
<postal>
<street>9800 Savage Road</street>
<street>Suite 6451</street>
<street>Attn: R2</street>
<city>Fort Meade</city>
<region>MD</region>
<code>20755-6451</code>
<country>US</country>
</postal>

<phone>+1 301 688 0850</phone>
<email>ejh@tycho.ncsc.mil</email>
</address>
</author>

<author fullname="Ryan C. Agee" initials="R." surname="Agee">
<organization>National Security Agency</organization>

<address>
<postal>
<street>9800 Savage Road</street>
<street>Suite 6451</street>
<street>Attn: R2</street>
<city>Fort Meade</city>
<region>MD</region>
<code>20755-6451</code>
<country>US</country>
</postal>

</address>
</author>

<date year="1999" month="June" />

<abstract>
<t>This report contains a discussion of the difficult problem of key management for multicast  communication sessions.  It focuses on two main areas of concern with respect to key management, which are, initializing the multicast group with a common net key and rekeying the multicast group. A rekey may be necessary upon the compromise of a user or for other reasons (e.g., periodic rekey). In particular, this report identifies a technique which allows for secure  compromise recovery, while also being robust against collusion of excluded users. This is one important feature of multicast key management which has not been addressed in detail by most other multicast key management proposals 
,
,
.
The benefits of this proposed technique are that it minimizes the number of transmissions required to rekey the multicast group and it imposes minimal storage requirements on the multicast group.</t>
</abstract>
</front>

<seriesInfo value="2627" name="RFC" />
</reference>


<reference target2="reference.RFC.2628.xml" anchor="RFC2628">
<front>
<title abbrev="Crypto API">Simple Cryptographic Program Interface (Crypto API)</title>
<author fullname="Valery Smyslov" initials="V." surname="Smyslov">
<organization>TWS</organization>

<address>
<postal>
<street>11 Centralny prospekt</street>
<city>Moscow</city>
<country>RU</country>
</postal>

<phone>+7 095 5314633</phone>
<email>svan@trustworks.com</email>
</address>
</author>

<date year="1999" month="June" />

<abstract>
<t>This document describes a simple Application Program Interface to cryptographic functions. The main purpose of such an interface is to separate cryptographic libraries from internet applications, thus allowing an independent development of both. It can be used in various internet applications such as,,,.</t>
</abstract>
</front>

<seriesInfo value="2628" name="RFC" />
</reference>


<reference target2="reference.RFC.2629.xml" anchor="RFC2629">
<front>
<title>Writing I-Ds and RFCs using XML</title>
<author fullname="Marshall T. Rose" initials="M.T." surname="Rose">
<organization>Invisible Worlds, Inc.</organization>

<address>
<postal>
<street>660 York Street</street>
<city>San Francisco</city>
<region>CA</region>
<code>94110</code>
<country>US</country>
</postal>

<phone>+1 415 695 3975</phone>
<email>mrose@not.invisible.net</email>
<uri>http://invisible.net/</uri>
</address>
</author>

<date year="1999" month="June" />
<area>General</area>
<keyword>RFC</keyword>
<keyword>Request for Comments</keyword>
<keyword>I-D</keyword>
<keyword>Internet-Draft</keyword>
<keyword>XML</keyword>
<keyword>Extensible Markup Language</keyword>

<abstract>
<t>This memo presents a technique for using XML
(Extensible Markup Language)
as a source format for documents in the Internet-Drafts (I-Ds) and
Request for Comments (RFC) series.</t>
</abstract>
</front>

<seriesInfo value="2629" name="RFC" />
<format octets="56453" type="HTML" target="http://xml.resource.org/public/rfc/html/rfc2629.html" />
<format octets="47068" type="XML" target="http://xml.resource.org/public/rfc/xml/rfc2629.xml" />
</reference>


<reference target2="reference.RFC.2630.xml" anchor="RFC2630">
<front>
<title>Cryptographic Message Syntax</title>
<author fullname="Russell Housley" initials="R." surname="Housley">
<organization>SPYRUS</organization>

<address>
<postal>
<street>381 Elden Street</street>
<street>Suite 1120</street>
<city>Herndon</city>
<region>VA</region>
<code>20170</code>
<country>US</country>
</postal>

<email>housley@spyrus.com</email>
</address>
</author>

<date year="1999" month="June" />

<abstract>
<t>This document describes the Cryptographic Message Syntax. This syntax is used to digitally sign, digest, authenticate, or encrypt arbitrary messages.</t>

<t>The Cryptographic Message Syntax is derived from PKCS #7 version 1.5 as specified in . Wherever possible, backward compatibility is preserved; however, changes were necessary to accommodate attribute certificate transfer and key agreement techniques for key management.</t>
</abstract>
</front>

<seriesInfo value="2630" name="RFC" />
</reference>


<reference target2="reference.RFC.2631.xml" anchor="RFC2631">
<front>
<title>Diffie-Hellman Key Agreement Method</title>
<author fullname="Eric Rescorla" initials="E." surname="Rescorla">
<organization>RTFM Inc.</organization>

<address>
<postal>
<street>30 Newell Road</street>
<street>#16</street>
<city>Palo Alto</city>
<region>CA</region>
<code>94303</code>
<country>US</country>
</postal>

<email>ekr@rtfm.com</email>
</address>
</author>

<date year="1999" month="June" />

<abstract>
<t>This document standardizes one particular Diffie-Hellman variant,  based on the ANSI X9.42 draft, developed by the ANSI X9F1 working group. Diffie-Hellman is a key agreement algorithm used by two parties to agree on a shared secret. An algorithm for converting the shared secret into an arbitrary amount of keying material is provided. The resulting keying material is used as a symmetric encryption key.  The Diffie-Hellman variant described requires the recipient to have a certificate, but the originator may have a static key pair (with the public key placed in a certificate) or an ephemeral key pair.</t>
</abstract>
</front>

<seriesInfo value="2631" name="RFC" />
</reference>


<reference target2="reference.RFC.2632.xml" anchor="RFC2632">
<front>
<title>S/MIME Version 3 Certificate Handling</title>
<author fullname="Blake Ramsdell" initials="B." surname="Ramsdell">
<organization>Worldtalk</organization>

<address>
<postal>
<street>17720 NE 65th Street</street>
<street>Suite 201</street>
<city>Redmond</city>
<region>WA</region>
<code>98052</code>
<country>US</country>
</postal>

<phone>+1 425 376 0225</phone>
<email>blaker@deming.com</email>
</address>
</author>

<date year="1999" month="June" />
</front>

<seriesInfo value="2632" name="RFC" />
</reference>


<reference target2="reference.RFC.2633.xml" anchor="RFC2633">
<front>
<title>S/MIME Version 3 Message Specification</title>
<author fullname="Blake Ramsdell" initials="B." surname="Ramsdell">
<organization>Worldtalk</organization>

<address>
<postal>
<street>17720 NE 65th Street</street>
<street>Suite 201</street>
<city>Redmond</city>
<region>WA</region>
<code>98052</code>
<country>US</country>
</postal>

<phone>+1 425 376 0225</phone>
<email>blaker@deming.com</email>
</address>
</author>

<date year="1999" month="June" />
</front>

<seriesInfo value="2633" name="RFC" />
</reference>


<reference target2="reference.RFC.2634.xml" anchor="RFC2634">
<front>
<title>Enhanced Security Services for S/MIME</title>
<author fullname="Paul Hoffman" initials="P." surname="Hoffman">
<organization>Internet Mail Consortium</organization>

<address>
<postal>
<street>127 Segre Place</street>
<city>Santa Cruz</city>
<region>CA</region>
<code>95060</code>
<country>US</country>
</postal>

<email>phoffman@imc.org</email>
</address>
</author>

<date year="1999" month="June" />
</front>

<seriesInfo value="2634" name="RFC" />
</reference>


<reference target2="reference.RFC.2635.xml" anchor="RFC2635">
<front>
<title abbrev="DON&apos;T SPEW">DON'T SPEW A Set of Guidelines for Mass Unsolicited Mailings and Postings (spam*)</title>
<author fullname="Sally Hambridge" initials="S." surname="Hambridge">
<organization>Intel Corp</organization>

<address>
<postal>
<street>2200 Mission College blvd</street>
<street>SC11-321</street>
<city>Santa Clara</city>
<region>CA</region>
<code>95052</code>
<country>US</country>
</postal>

<email>sallyh@ludwig.sc.intel.com</email>
</address>
</author>

<author fullname="Albert Lunde" initials="A." surname="Lunde">
<organization>Northwestern University</organization>

<address>
<postal>
<street>1603 Orrington Avenue</street>
<street>Suite 1400</street>
<city>Evanston</city>
<region>IL</region>
<code>60201</code>
<country>US</country>
</postal>

<email>Albert-Lunde@nwu.edu</email>
</address>
</author>

<date year="1999" month="June" />

<abstract>
<t>This document explains why mass unsolicited electronic mail messages are harmful in the Internetworking community. It gives a set of
guidelines for dealing with unsolicited mail for users, for system administrators, news administrators, and mailing list managers. It also makes suggestions Internet Service Providers might follow.</t>
</abstract>
</front>

<seriesInfo value="2635" name="RFC" />
</reference>


<reference target2="reference.RFC.2636.xml" anchor="RFC2636">
<front>
<title abbrev="OTASP/OTAPA via ACAP">Wireless Device Configuration (OTASP/OTAPA) via ACAP</title>
<author fullname="Randall Gellens" initials="R." surname="Gellens">
<organization>QUALCOMM Incorporated</organization>

<address>
<postal>
<street>6455 Lusk Boulevard</street>
<city>San Diego</city>
<region>CA</region>
<code>92121-2779</code>
<country>US</country>
</postal>

<phone>+1 619 651 5115</phone>
<email>randy@qualcomm.com</email>
</address>
</author>

<date year="1999" month="July" />

<abstract>
<t>Wireless carriers today are faced with creating more efficient distribution channels, increasing customer satisfaction, while also improving margin and profitability. Industry trends are pushing the sale of handsets further into the retail channel. The cost and effort of provisioning handsets, activating users, and updating handset parameters can be greatly reduced by using over-the-air activation mechanisms. A comprehensive and extensible means for over-the-air provisioning and handset parameter updating is required.</t>

<t>One approach is to purchase EIA/TIA/IS-683A (Over-the-air Service Provisioning of Mobile Stations in Spread Spectrum Systems) equipment. The cost of this has led carriers to seek alternative solutions. A very viable means for providing over-the-air (OTA) provisioning is to leverage the rollout of IS-707 data services equipment, which most carriers are in the process of deploying. This paper presents an approach to OTA provisioning that utilizes the deployment of IS-707 to deliver OTA provisioning and parameter upgrading.</t>

<t>IS-707 data services makes available several methods of providing over-the-air provisioning and parameter updating. A well thought-out approach utilizing Internet-based open standard mechanisms can provide an extensible platform for further carrier service offerings, enhanced interoperability among back-end services, and vendor independence.</t>

<t>This paper describes a viable and attractive means to provide OTASP/OTAPA via IS-707, using theACAP protocol.</t>
</abstract>
</front>

<seriesInfo value="2636" name="RFC" />
</reference>


<reference target2="reference.RFC.2637.xml" anchor="RFC2637">
<front>
<title>Point-to-Point Tunneling Protocol</title>
<author fullname="Kory Hamzeh" initials="K." surname="Hamzeh">
<organization>Ascend Communications</organization>

<address>
<postal>
<street>1275 Harbor Bay Parkway</street>
<city>Alameda</city>
<region>CA</region>
<code>94502</code>
<country>US</country>
</postal>

<email>kory@ascend.com</email>
</address>
</author>

<author fullname="Gall Pall" initials="G." surname="Pall">
<organization>Microsoft Corporation</organization>

<address>
<postal>
<street>One Microsoft Way</street>
<city>Redmond</city>
<region>WA</region>
<code>98052-6399</code>
<country>US</country>
</postal>

<email>gurdeep@microsoft.com</email>
</address>
</author>

<author fullname="William Verthein" initials="W." surname="Verthein">
<organization>U.S. Robotics/3Com</organization>
</author>

<author fullname="Jeff Taarud" initials="J." surname="Taarud">
<organization>Copper Mountain Networks</organization>
</author>

<author fullname="W.  Andrew Little" initials="W." surname="Little">
<organization>ECI Telematics</organization>
</author>

<author fullname="Glen Zorn" initials="G." surname="Zorn">
<organization>Microsoft Corporation</organization>

<address>
<postal>
<street>One Microsoft Way</street>
<city>Redmond</city>
<region>WA</region>
<code>98052-6399</code>
<country>US</country>
</postal>

<email>glennz@microsoft.com</email>
</address>
</author>

<date year="1999" month="July" />

<abstract>
<t>This document specifies a protocol which allows the Point to Point Protocol (PPP) to be tunneled through an IP network. PPTP does not specify any changes to the PPP  protocol but rather describes a new vehicle for carrying PPP. A client-server architecture is defined in order to decouple functions which exist in current Network Access Servers (NAS) and support Virtual Private Networks (VPNs). The PPTP Network Server (PNS) is envisioned to run on a general purpose operating system while the client, referred to as a PPTP Access Concentrator (PAC) operates on a dial access platform. PPTP specifies a call-control and management protocol which allows the server to control access for dial-in circuit switched calls
originating from a PSTN or ISDN or to initiate outbound circuit-switched connections. PPTP uses an enhanced GRE (Generic Routing Encapsulation) mechanism to provide a flow- and congestion-controlled encapsulated datagram service for carrying PPP packets.</t>
</abstract>

<note title="IESG Note">
<t>The PPTP protocol was developed by a vendor consortium. The documentation of PPTP is provided as information to the Internet community. The PPP WG is currently defining a Standards Track protocol (L2TP) for tunneling PPP across packet-switched networks.</t>
</note>

<note title="Specification of Requirements">
<t>In this document, the key words "MAY", "MUST, "MUST NOT", "optional", "recommended", "SHOULD", and "SHOULD NOT" are to be interpreted as described in.</t>

<t>The words "silently discard", when used in reference to the behavior of an implementation upon receipt of an incoming packet, are to be interpreted as follows: the  implementation discards the datagram without further processing, and without indicating an error to the sender. The implementation SHOULD provide the capability of logging the error, including the contents of the discarded datagram, and SHOULD record the event in a statistics counter.</t>
</note>
</front>

<seriesInfo value="2637" name="RFC" />
</reference>


<reference target2="reference.RFC.2638.xml" anchor="RFC2638">
<front>
<title abbrev="Two-bit Differentiated Services Architecture">A Two-bit Differentiated Services Architecture for the Internet</title>
<author fullname="Kathleen Nichols" initials="K." surname="Nichols">
<organization>Cisco Systems, Inc.</organization>

<address>
<postal>
<street>170 West Tasman Drive</street>
<city>San Jose</city>
<region>CA</region>
<code>95134-1706</code>
<country>US</country>
</postal>

<phone>+1 408 525 4857</phone>
<email>kmn@cisco.com</email>
</address>
</author>

<author fullname="Van Jacobson" initials="V." surname="Jacobson">
<organization>Cisco Systems, Inc.</organization>

<address>
<postal>
<street>170 West Tasman Drive</street>
<city>San Jose</city>
<region>CA</region>
<code>95134-1706</code>
<country>US</country>
</postal>

<email>van@cisco.com</email>
</address>
</author>

<author fullname="Lixia Zhang" initials="L." surname="Zhang">
<organization>UCLA</organization>

<address>
<postal>
<street>4531G Boelter Hall</street>
<city>Los Angeles</city>
<region>CA</region>
<code>90095</code>
<country>US</country>
</postal>

<phone>+1 310 825 2695</phone>
<email>lixia@cs.ucla.edu</email>
</address>
</author>

<date year="1999" month="July" />

<abstract>
<t>This document was originally submitted as an internet draft in November of 1997. As one of the documents predating the formation of the IETF's Differentiated Services Working Group, many of the ideas presented here, in concert with Dave Clark's subsequent presentation to the December 1997 meeting of the IETF Integrated Services Working Group, were key to the work which led to RFCs 2474 and 2475 and the section on allocation remains a timely  roposal.
For this reason, and to provide a reference, it is being submitted in its original form. The forwarding path portion of this document is intended as a record of where we were at in late 1997 and not as an indication of future direction.</t>

<t>The postscript version of this document includes Clark's slides as an appendix. The postscript version of this document also includes many figures that aid greatly in its readability.</t>
</abstract>
</front>

<seriesInfo value="2638" name="RFC" />
</reference>


<reference target2="reference.RFC.2639.xml" anchor="RFC2639">
<front>
<title abbrev="IPP/1.0: Implementer&apos;s Guide">Internet Printing Protocol/1.0: Implementer's Guide</title>
<author fullname="Thomas Hastings" initials="T." surname="Hastings">
<organization>Xerox Corporation</organization>

<address>
<postal>
<street>701 Aviation Boulevard</street>
<city>El Segundo</city>
<region>CA</region>
<code>90245</code>
<country>US</country>
</postal>

<email>hastings@cp10.es.xerox.com</email>
</address>
</author>

<author fullname="Carl-Uno Manros" initials="C." surname="Manros">
<organization>Xerox Corporation</organization>

<address>
<postal>
<street>701 Aviation Boulevard</street>
<city>El Segundo</city>
<region>CA</region>
<code>90245</code>
<country>US</country>
</postal>

<email>manros@cp10.es.xerox.com</email>
</address>
</author>

<date year="1999" month="July" />

<abstract>
<t>This document is one of a set of documents, which together describe all aspects of a new Internet Printing Protocol (IPP). IPP is an application level protocol that can be used for distributed printing using Internet tools and technologies. This document contains information that supplements the IPP Model and Semantics [RFC2566] and the IPP Transport and Encoding [RFC2565] documents. It is intended to help implementers understand IPP/1.0 and some of the considerations that may assist them in the design of their client and/or IPP object implementations. For example, a typical order of processing requests is given, including error checking. Motivation for some of the specification decisions is also included.</t>

<t>The full set of IPP documents includes:
<list style="symbols">
<t>Design Goals for an Internet Printing Protocol</t>

<t>Rationale for the Structure and Model and Protocol for the Internet Printing Protocol</t>

<t>Internet Printing Protocol/1.0: Model and Semantics</t>

<t>Internet Printing Protocol/1.0: Encoding and Transport</t>

<t>Mapping between LPD and IPP Protocols</t>
</list>
</t>

<t>The document, "Design Goals for an Internet Printing Protocol", takes a broad look at distributed printing functionality, and it enumerates real-life scenarios that help to clarify the features that need to be included in a printing protocol for the Internet. It identifies requirements for three types of users: end users, operators, and administrators. The design goals document calls out a subset of end user requirements that are satisfied in IPP/1.0. Operator and administrator requirements are out of scope for version 1.0.</t>

<t>The document, "Rationale for the Structure and Model and Protocol for the Internet Printing Protocol", describes IPP from a high level view, defines a roadmap for the various documents that form the suite of IPP specifications, and gives background and rationale for the IETF working group's major decisions.</t>

<t>The document, "Internet Printing Protocol/1.0: Model and Semantics", describes a simplified model with abstract objects, their attributes, and their operations. The model introduces a Printer and a Job. The Job supports multiple documents per Job. The model document also addresses how security, internationalization, and directory issues are addressed.</t>

<t>The document, "Internet Printing Protocol/1.0: Encoding and Transport", is a formal mapping of the abstract operations and attributes defined in the model document onto HTTP/1.1.  It also defines the encoding rules for a new Internet media type called "application/ipp".</t>

<t>The document, "Mapping between LPD and IPP Protocols", gives some advice to implementers of gateways between IPP and LPD (Line Printer Daemon) implementations.</t>
</abstract>
</front>

<seriesInfo value="2639" name="RFC" />
</reference>


<reference target2="reference.RFC.2640.xml" anchor="RFC2640">
<front>
<title abbrev="FTP Internalization">Internationalization of the File Transfer Protocol</title>
<author fullname="Bill Curtin" initials="B." surname="Curtin">
<organization>JIEO</organization>

<address>
<postal>
<street />
<city>Fort Monmouth</city>
<region>NJ</region>
<code>07703-5613</code>
<country>US</country>
</postal>

<email>curtinw@ftm.disa.mil</email>
</address>
</author>

<date year="1999" month="July" />

<abstract>
<t>The File Transfer Protocol, as defined inand's Section 4, is one of the oldest and widely used protocols on the Internet. The protocol's primary character set, 7 bit ASCII, has served the protocol well through the early growth years of the Internet. However, as the Internet becomes more global, there is a need to support character sets beyond 7 bit ASCII.</t>

<t>This document addresses the internationalization (I18n) of FTP, which includes supporting the multiple character sets and languages found throughout the Internet community. This is achieved by extending the FTP specification and giving recommendations for proper internationalization support.</t>
</abstract>
</front>

<seriesInfo value="2640" name="RFC" />
</reference>


<reference target2="reference.RFC.2641.xml" anchor="RFC2641">
<front>
<title abbrev="Cabletron&apos;s VlanHello Protocol Version 4">Cabletron's VlanHello Protocol Specification Version 4</title>
<author fullname="Dave Hamilton" initials="D." surname="Hamilton">
<organization>Cabletron Systems, Inc.</organization>

<address>
<postal>
<street>POB 5005</street>
<city>Rochester</city>
<region>NH</region>
<code>03866-5005</code>
<country>US</country>
</postal>

<phone>+1 603 332 9400</phone>
<email>daveh@ctron.com</email>
</address>
</author>

<author fullname="Dave Ruffen" initials="D." surname="Ruffen">
<organization />

<address>
<postal>
<street>POB 5005</street>
<city>Rochester</city>
<region>NH</region>
<code>03866-5005</code>
<country>US</country>
</postal>

<phone>+1 603 332 9400</phone>
<email>ruffen@ctron.com</email>
</address>
</author>

<date year="1999" month="August" />

<abstract>
<t>The VlanHello protocol is part of the InterSwitch Message Protocol (ISMP) which provides interswitch communication between switches running Cabletron's SecureFast VLAN (SFVLAN) product.  Switches use the VlanHello protocol to discover their neighboring switches and establish the topology of the switch fabric.</t>
</abstract>
</front>

<seriesInfo value="2641" name="RFC" />
</reference>


<reference target2="reference.RFC.2642.xml" anchor="RFC2642">
<front>
<title>Cabletron's VLS Protocol Specification</title>
<author fullname="Laura Kane" initials="L." surname="Kane">
<organization>Cabletron Systems, Inc.</organization>

<address>
<postal>
<street>POB 5005</street>
<city>Rochester</city>
<region>NH</region>
<code>03866-5005</code>
<country>US</country>
</postal>

<phone>+1 603 332 9400</phone>
<email>lkane@ctron.com</email>
</address>
</author>

<date year="1999" month="August" />

<abstract>
<t>The Virtual LAN Link State Protocol (VLSP) is part of the InterSwitch Message Protocol (ISMP) which  provides interswitch communication between switches running Cabletron's SecureFast VLAN (SFVLAN) product. VLSP is used to determine and maintain a fully connected mesh topology graph of the switch fabric. Each switch maintains an identical database describing the topology. Call-originating switches use the topology database to  determine the path over which to route a call connection.</t>

<t>VLSP provides support for equal-cost multipath routing, and recalculates routes quickly in the face of topological changes, utilizing a minimum of routing protocol traffic.</t>
</abstract>
</front>

<seriesInfo value="2642" name="RFC" />
</reference>


<reference target2="reference.RFC.2643.xml" anchor="RFC2643">
<front>
<title abbrev="SecureFast VLAN Operational Model">Cabletron's SecureFast VLAN Operational Model</title>
<author fullname="Dave Ruffen" initials="D." surname="Ruffen">
<organization>Cabletron Systems, Inc.</organization>

<address>
<postal>
<street>POB 5005</street>
<city>Rochester</city>
<region>NH</region>
<code>03866-5005</code>
<country>US</country>
</postal>

<phone>+1 603 332 9400</phone>
<email>ruffen@ctron.com</email>
</address>
</author>

<author fullname="Ted Len" initials="T." surname="Len">
<organization />

<address>
<postal>
<street>POB 5005</street>
<city>Rochester</city>
<region>NH</region>
<code>03866-5005</code>
<country>US</country>
</postal>

<phone>+1 603 332 9400</phone>
<email>len@ctron.com</email>
</address>
</author>

<author fullname="J. Yanacek" initials="J." surname="Yanacek">
<organization />

<address>
<postal>
<street>POB 5005</street>
<city>Rochester</city>
<region>NH</region>
<code>03866-5005</code>
<country>US</country>
</postal>

<phone>+1 603 332 9400</phone>
<email>jyanacek@ctron.com</email>
</address>
</author>

<date year="1999" month="August" />

<abstract>
<t>Cabletron's SecureFast VLAN (SFVLAN) product implements a distributed connection-oriented  witching protocol that provides fast forwarding of data packets at the MAC layer. The product uses the concept of virtual LANs (VLANs) to determine the validity of call connection requests and to scope the broadcast of certain flooded messages.</t>
</abstract>
</front>

<seriesInfo value="2643" name="RFC" />
</reference>


<reference target2="reference.RFC.2644.xml" anchor="RFC2644">
<front>
<title abbrev="Default Change for Directed Broadcast">Changing the Default for Directed Broadcasts in Routers</title>
<author fullname="Daniel Senie" initials="D." surname="Senie">
<organization>Amaranth Networks Inc.</organization>

<address>
<postal>
<street>324 Still River Road</street>
<city>Bolton</city>
<region>MA</region>
<code>01740</code>
<country>US</country>
</postal>

<phone>+1 978 779 6813</phone>
<email>dts@senie.com</email>
</address>
</author>

<date year="1999" month="August" />
</front>

<seriesInfo value="34" name="BCP" />
<seriesInfo value="2644" name="RFC" />
</reference>


<reference target2="reference.RFC.2645.xml" anchor="RFC2645">
<front>
<title abbrev="On-Demand Mail Relay">ON-DEMAND MAIL RELAY (ODMR) SMTP with Dynamic IP Addresses</title>
<author fullname="Randall Gellens" initials="R." surname="Gellens">
<organization>QUALCOMM Incorporated</organization>

<address>
<postal>
<street>5775 Morehouse Drive</street>
<city>San Diego</city>
<region>CA</region>
<code>92121-2779</code>
<country>US</country>
</postal>

<phone>+1 619 651 5115</phone>
<email>randy@qualcomm.com</email>
</address>
</author>

<date year="1999" month="August" />

<abstract>
<t>With the spread of low-cost computer systems and Internet connectivity, the demand for local mail servers has been rising. Many people now want to operate a mail server on a system which has only an intermittent connection to a service provider. If the system has a static IP address, theESMTP ETRN commandcan be used.However, systems with dynamic IP addresses (which are very common with low-cost connections) have no widely-deployed solution.</t>

<t>This memo proposes a new service, On-Demand Mail Relay (ODMR), which is a profile of SMTP, providing for a secure, extensible, easy to implement approach to the problem.</t>
</abstract>
</front>

<seriesInfo value="2645" name="RFC" />
</reference>


<reference target2="reference.RFC.2646.xml" anchor="RFC2646">
<front>
<title>The Text/Plain Format Parameter</title>
<author fullname="Randall Gellens" initials="R." surname="Gellens">
<organization>QUALCOMM Incorporated</organization>

<address>
<postal>
<street>5775 Morehouse Drive</street>
<city>San Diego</city>
<region>CA</region>
<code>92121-2779</code>
<country>US</country>
</postal>

<phone>+1 619 651 5115</phone>
<email>randy@qualcomm.com</email>
</address>
</author>

<date year="1999" month="August" />

<abstract>
<t>Interoperability problems have been observed with erroneous labelling of paragraph text as Text/Plain, and with various forms of "embarrassing line wrap." (See section 3.)</t>

<t>Attempts to deploy new media types, such asText/EnrichedandText/HTMLhave suffered from a lack of backwards compatibility and an often hostile user reaction at the receiving end.</t>

<t>What is required is a format which is in all significant ways Text/Plain, and therefore is quite suitable for display as Text/Plain, and yet allows the sender to express to the receiver
which lines can be considered a logical paragraph, and thus flowed (wrapped and joined) as appropriate.</t>

<t>This memo proposes a new parameter to be used with Text/Plain, and, in the presence of this parameter, the use of trailing whitespace to indicate flowed lines. This results in an encoding which appears as normal Text/Plain in older implementations, since it is in fact normal Text/Plain.</t>
</abstract>
</front>

<seriesInfo value="2646" name="RFC" />
</reference>


<reference target2="reference.RFC.2647.xml" anchor="RFC2647">
<front>
<title abbrev="Firewall Performance Terminology">Benchmarking Terminology for Firewall Performance</title>
<author fullname="David Newman" initials="D." surname="Newman">
<organization>Data Communications magazine</organization>

<address>
<postal>
<street>3 Park Avenue</street>
<street>31st Floor</street>
<city>New York</city>
<region>NY</region>
<code>10016</code>
<country>US</country>
</postal>

<phone>+1 212 592 8256</phone>
<email>dnewman@data.com</email>
</address>
</author>

<date year="1999" month="August" />
</front>

<seriesInfo value="2647" name="RFC" />
</reference>


<reference target2="reference.RFC.2648.xml" anchor="RFC2648">
<front>
<title>A URN Namespace for IETF Documents</title>
<author fullname="Ryan Moats" initials="R." surname="Moats">
<organization>AT&amp;T</organization>

<address>
<postal>
<street>15621 Drexel Circle</street>
<city>Omaha</city>
<region>NE</region>
<code>68135-2358</code>
<country>US</country>
</postal>

<email>jayhawk@att.com</email>
</address>
</author>

<date year="1999" month="August" />

<abstract>
<t>A system for Uniform Resource Names (URNs) must be capable of supporting new naming systems. As an example of proposing a new namespace, this document proposes the "ietf" namespace. This namespace consists of the RFC family of documents (RFCs, STDs, FYIs, and BCPs) developed by the IETF and published by the RFC Editor, the minutes of working groups (WG) and birds of a feather (BOF) meetings that occur during IETF conferences, and the Internet Drafts published by the Internet Drafts Editor. Both the current URN framework and URN syntax support this namespace.</t>
</abstract>
</front>

<seriesInfo value="2648" name="RFC" />
</reference>


<reference target2="reference.RFC.2649.xml" anchor="RFC2649">
<front>
<title abbrev="LDAP Control and Schema">An LDAP Control and Schema for Holding Operation Signatures</title>
<author fullname="Bruce Greenblatt" initials="B." surname="Greenblatt">
<organization />

<address>
<postal>
<street />
<city>San Jose</city>
<region>CA</region>
<code>95119</code>
<country>US</country>
</postal>

<phone>+1 408 224 5349</phone>
<email>bgreenblatt@directory-applications.com</email>
</address>
</author>

<author fullname="Pat Richard" initials="P." surname="Richard">
<organization>Xcert Software, Inc.</organization>

<address>
<postal>
<street>701 West Georgia</street>
<street>Suite 1001</street>
<city>Vancouver</city>
<region>British Columbia</region>
<code>V6G 1C9</code>
<country>CA</country>
</postal>

<email>patr@xcert.com</email>
</address>
</author>

<date year="1999" month="August" />

<abstract>
<t>In many environments clients require the ability to validiate the source and integrity of information provided by the directory. This document describes an LDAP message control which allows for the retrieval of digitally signed information. This document defines an LDAP v3 based mechanism for signing directory operations in order to create a secure journal of changes that have been made to each directory entry. Both client and server based signatures are supported. An object class for subsequent retrieval are "journal entries" is also defined. This document specifies LDAP v3 controls that enable this functionality. It also defines an LDAP v3 schema that allows for subsequent browsing of the journal information.</t>
</abstract>
</front>

<seriesInfo value="2649" name="RFC" />
</reference>


<reference target2="reference.RFC.2650.xml" anchor="RFC2650">
<front>
<title>Using RPSL in Practice</title>
<author fullname="David Meyer" initials="D." surname="Meyer">
<organization>Cisco Systems</organization>

<address>
<email>dmm@cisco.com</email>
</address>
</author>

<author fullname="Joachim Schmitz" initials="J." surname="Schmitz">
<organization>America On-Line</organization>

<address>
<email>SchmitzJo@aol.com</email>
</address>
</author>

<author fullname="Carol Orange" initials="C." surname="Orange">
<organization>RIPE NCC</organization>

<address>
<email>orange@spiritone.com</email>
</address>
</author>

<author fullname="Mark Prior" initials="M." surname="Prior">
<organization>connect.com.au pty ltd</organization>

<address>
<email>mrp@connect.com.au</email>
</address>
</author>

<author fullname="Cengiz Alaettinoglu" initials="C." surname="Alaettinoglu">
<organization>USC/Information Sciences Institute</organization>

<address>
<postal>
<street>4676 Admiralty Way</street>
<city>Marina del Rey</city>
<region>CA</region>
<code>90291</code>
<country>US</country>
</postal>

<phone>+1 213 822 1511</phone>
<email>cengiz@isi.edu</email>
</address>
</author>

<date year="1999" month="August" />

<abstract>
<t>This document is a tutorial on using the Routing Policy Specification Language (RPSL) to describe routing policies in the Internet Routing Registry (IRR). We explain how to specify various routing policies and configurations using RPSL, how to register these policies in the IRR, and how to analyze them using the routing policy analysis tools, for example to generate vendor specific router configurations.</t>
</abstract>
</front>

<seriesInfo value="2650" name="RFC" />
</reference>


<reference target2="reference.RFC.2651.xml" anchor="RFC2651">
<front>
<title abbrev="The CIP Architecture">The Architecture of the Common Indexing Protocol (CIP)</title>
<author fullname="Jeff Allen" initials="J." surname="Allen">
<organization />

<address>
<postal>
<street>246 Hawthorne Street</street>
<city>Palo Alto</city>
<region>CA</region>
<code>94301</code>
<country>US</country>
</postal>

<email>jeff.allen@acm.org</email>
</address>
</author>

<author fullname="Michael Mealling" initials="M." surname="Mealling">
<organization>Network Solutions, Inc.</organization>

<address>
<postal>
<street>505 Huntmar Park Drive</street>
<city>Herndon</city>
<region>VA</region>
<code>22070</code>
<country>US</country>
</postal>

<phone>+1 703 742 0400</phone>
<email>michael.mealling@RWhois.net</email>
</address>
</author>

<date year="1999" month="August" />

<abstract>
<t>The Common Indexing Protocol (CIP) is used to pass indexing information from server to server in order to facilitate query routing. Query routing is the process of redirecting and replicating queries through a distributed database system towards servers holding the desired results. This document describes the CIP framework, including its architecture and the protocol specifics of exchanging indices.</t>
</abstract>
</front>

<seriesInfo value="2651" name="RFC" />
</reference>


<reference target2="reference.RFC.2652.xml" anchor="RFC2652">
<front>
<title abbrev="MIME Definitions for CIP">MIME Object Definitions for the Common Indexing Protocol (CIP)</title>
<author fullname="Jeff Allen" initials="J." surname="Allen">
<organization />

<address>
<postal>
<street>246 Hawthorne Street</street>
<city>Palo Alto</city>
<region>CA</region>
<code>94301</code>
<country>US</country>
</postal>

<email>jeff.allen@acm.org</email>
</address>
</author>

<author fullname="Michael Mealling" initials="M." surname="Mealling">
<organization>Network Solutions, Inc.</organization>

<address>
<postal>
<street>505 Huntmar Park Drive</street>
<city>Herndon</city>
<region>VA</region>
<code>22070</code>
<country>US</country>
</postal>

<phone>+1 703 742 0400</phone>
<email>michael.mealling@RWhois.net</email>
</address>
</author>

<date year="1999" month="August" />

<abstract>
<t>The Common Indexing Protocol (CIP) is used to pass indexing information from server to server in order to facilitate query routing. The protocol is comprised of several MIME objects being passed from server to server. This document describes the definitions of those objects as well as the methods and requirements needed to define a new index type.</t>
</abstract>
</front>

<seriesInfo value="2652" name="RFC" />
</reference>


<reference target2="reference.RFC.2653.xml" anchor="RFC2653">
<front>
<title>CIP Transport Protocols</title>
<author fullname="Jeff Allen" initials="J." surname="Allen">
<organization />

<address>
<postal>
<street>246 Hawthorne Street</street>
<city>Palo Alto</city>
<region>CA</region>
<code>94301</code>
<country>US</country>
</postal>

<email>jeff.allen@acm.org</email>
</address>
</author>

<author fullname="Paul Leach" initials="P." surname="Leach">
<organization>Microsoft</organization>

<address>
<postal>
<street>1 Microsoft Way</street>
<city>Redmond</city>
<region>WA</region>
<code>98052</code>
<country>US</country>
</postal>

<email>paulle@microsoft.com</email>
</address>
</author>

<author fullname="Roland Hedberg" initials="R." surname="Hedberg">
<organization>Catalogix</organization>

<address>
<postal>
<street>Dalsveien 53</street>
<city>Oslo</city>
<code>0775</code>
<country>NO</country>
</postal>

<email>roland@catalogix.ac.se</email>
</address>
</author>

<date year="1999" month="August" />

<abstract>
<t>This document specifies three protocols for transporting CIP requests, responses and index objects, utilizing TCP, mail, and HTTP. The objects themselves are defined inand the overall CIP architecture is defined in.</t>
</abstract>
</front>

<seriesInfo value="2653" name="RFC" />
</reference>


<reference target2="reference.RFC.2654.xml" anchor="RFC2654">
<front>
<title abbrev="Tagged Index Object for use in CIP">A Tagged Index Object for use in the Common Indexing Protocol</title>
<author fullname="Roldan Hedberg" initials="R." surname="Hedberg">
<organization>Catalogix</organization>

<address>
<postal>
<street>Dalsveien 53</street>
<city>Oslo</city>
<code>0387</code>
<country>NO</country>
</postal>

<email>roland@catalogix.ac.se</email>
</address>
</author>

<author fullname="Bruce Greenblatt" initials="B." surname="Greenblatt">
<organization>Directory Tools and Application Services, Inc.</organization>

<address>
<postal>
<street>6841 Heaton Moor Drive</street>
<city>San Jose</city>
<region>CA</region>
<code>95119</code>
<country>US</country>
</postal>

<phone>+1 408 224 5349</phone>
<email>bgreenblatt@directory-applications.com</email>
</address>
</author>

<author fullname="Ryan Moats" initials="R." surname="Moats">
<organization>AT&amp;T</organization>

<address>
<postal>
<street>15621 Drexel Circle</street>
<city>Omaha</city>
<region>NE</region>
<code>68135-2358</code>
<country>US</country>
</postal>

<phone>+1 402 894 9456</phone>
<email>jayhawk@att.com</email>
</address>
</author>

<author fullname="Mark Wahl" initials="M." surname="Wahl">
<organization>Innosoft International, Inc.</organization>

<address>
<postal>
<street>8911 Capital of Texas Highway</street>
<street>Suite 4140</street>
<city>Austin</city>
<region>TX</region>
<code>78759</code>
<country>US</country>
</postal>

<phone>+1 626 919 3600</phone>
<email>Mark.Wahl@innosoft.com</email>
</address>
</author>

<date year="1999" month="August" />

<abstract>
<t>This document defines a mechanism by which information servers can exchange indices of information from their databases by making use of the Common Indexing Protocol (CIP). This document defines the structure of the index information being exchanged, as well as the appropriate meanings for the headers that are defined in the Common Indexing Protocol.
It is assumed that the structures defined here can be used by X.500 DSAs, LDAP servers, Whois++ servers, CSO Ph servers and many others.</t>
</abstract>
</front>

<seriesInfo value="2654" name="RFC" />
</reference>


<reference target2="reference.RFC.2655.xml" anchor="RFC2655">
<front>
<title>CIP Index Object Format for SOIF Objects</title>
<author fullname="Ted Hardie" initials="T." surname="Hardie">
<organization>Equinix</organization>

<address>
<postal>
<street>901 Marshall Street</street>
<city>Redwood City</city>
<region>CA</region>
<code>94063</code>
<country>US</country>
</postal>

<email>hardie@equinix.com</email>
</address>
</author>

<author fullname="Mic Bowman" initials="M." surname="Bowman">
<organization>Transarc Corporation</organization>

<address>
<postal>
<street>The Gulf Tower</street>
<street>707 Grant Street</street>
<city>Pittsburgh</city>
<region>PA</region>
<code>15219</code>
<country>US</country>
</postal>

<phone>+1 412 338 4400</phone>
<email>mic@transarc.com</email>
</address>
</author>

<author fullname="Darren Hardy" initials="D." surname="Hardy">
<organization>Netscape Communications Corp.</organization>

<address>
<postal>
<street>685 Eeast Middlefield Road</street>
<city>Mountain View</city>
<region>CA</region>
<code>94043</code>
<country>US</country>
</postal>

<phone>+1 415 937 2555</phone>
<email>dhardy@netscape.com</email>
</address>
</author>

<author fullname="Mike Schwartz" initials="M." surname="Schwartz">
<organization>Affinia, Inc.</organization>

<address>
<postal>
<street>621 17th Street</street>
<street>Suite 1700</street>
<city>Denver</city>
<region>CO</region>
<code>80293</code>
<country>US</country>
</postal>

<phone>+1 303 292 4818</phone>
<email>mfs@affinia.net</email>
</address>
</author>

<author fullname="Duane Wessels" initials="D." surname="Wessels">
<organization>National Laboratory for Applied Network Research</organization>

<address>
<phone>+1 303 497 1822</phone>
<email>wessels@nlanr.net</email>
</address>
</author>

<date year="1999" month="August" />

<abstract>
<t>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, 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.</t>

<t>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.</t>
</abstract>
</front>

<seriesInfo value="2655" name="RFC" />
</reference>


<reference target2="reference.RFC.2656.xml" anchor="RFC2656">
<front>
<title abbrev="Registration Procedures for SOIF">Registration Procedures for SOIF Template Types</title>
<author fullname="Tex Hardie" initials="T." surname="Hardie">
<organization>Equinox</organization>

<address>
<postal>
<street>901 Marshall Street</street>
<city>Redwood City</city>
<region>CA</region>
<code>94063</code>
<country>US</country>
</postal>

<email>hardie@equinix.com</email>
</address>
</author>

<date year="1999" month="August" />

<abstract>
<t>TheSummary Object Interchange Formatwas first defined by theHarvest Projectin January 1994. SOIF was derived from a combination of theInternet Anonymous FTP Archives IETF Working Group (IAFA) templatesand theBibTeX bibliography format. The combination was originally noted for its advantages of providing a convenient and intuitive way for delimiting objects within a stream, and setting apart the URL for easy object access or invocation, while still preserving compatibility with IAFA templates.</t>

<t>SOIF uses named template types to indicate the attributes which may be contained within a particular summary object. Within the context of a single application, private agreement on the definition of template types has been adequate. As SOIF objects are moved among applications, however, the need for standard, well-specified, and easily identifiable template types increases.This need is particularly intense in the context of query referral, where knowledge of an attribute's definition and the allowed data types for specific values is crucial. For a discussion of this in the context of the Common Indexing Protocol, see
RFC2655
.</t>

<t>The registration procedure described in this document is specific to SOIF template types. There is ongoing work within the IETF to specify amore generic schema registration facility. It is not yet clear whether the results of that work will encompass the ability to register entities like SOIF template types. If it does so, the registration of SOIF template types may be shifted to that method and registry. Should that occur, appropriate pointers will be created in cooperation with the Registrar to ensure that no registrations are lost.</t>
</abstract>
</front>

<seriesInfo value="2656" name="RFC" />
</reference>


<reference target2="reference.RFC.2657.xml" anchor="RFC2657">
<front>
<title abbrev="LDAPv2 vs. Index Mesh">LDAPv2 Client vs</title>
<author fullname="Roland Hedberg" initials="R." surname="Hedberg">
<organization>Catalogix</organization>

<address>
<postal>
<street>Dalsveien 53</street>
<city>Oslo</city>
<code>0387</code>
<country>NO</country>
</postal>

<phone>+47 23 082996</phone>
<email>roland@catalogix.ac.se</email>
</address>
</author>

<date year="1999" month="August" />

<abstract>
<t>LDAPv2 clients as implemented according tohave no notion on referral. The integration between such a client and an Index Mesh, as defined by theCommon Indexing Protocol, heavily depends on referrals and therefore needs to be handled in a special way. This document defines one possible way of doing this.</t>
</abstract>
</front>

<seriesInfo value="2657" name="RFC" />
</reference>


<reference target2="reference.RFC.2658.xml" anchor="RFC2658">
<front>
<title>RTP Payload Format for PureVoice(tm) Audio</title>
<author fullname="Kyle McKay" initials="K." surname="McKay">
<organization>QUALCOMM Incorporated</organization>

<address>
<postal>
<street>5775 Morehouse Drive</street>
<city>San Diego</city>
<region>CA</region>
<code>92121-1714</code>
<country>US</country>
</postal>

<phone>+1 858 587 1121</phone>
<email>kylem@qualcomm.com</email>
</address>
</author>

<date year="1999" month="August" />

<abstract>
<t>This document describes the RTP payload format for PureVoice(tm) Audio. The packet format supports variable interleaving to reduce the effect of packet loss on audio quality.</t>
</abstract>
</front>

<seriesInfo value="2658" name="RFC" />
</reference>


<reference target2="reference.RFC.2659.xml" anchor="RFC2659">
<front>
<title>Security Extensions For HTML</title>
<author fullname="Eric Rescorla" initials="E." surname="Rescorla">
<organization>RTFM, Inc.</organization>

<address>
<postal>
<street>30 Newell Road</street>
<street>#16</street>
<city>Palo Alto</city>
<region>CA</region>
<code>94303</code>
<country>US</country>
</postal>

<phone>+1 650 328 8631</phone>
<email>ekr@rtfm.com</email>
</address>
</author>

<author fullname="Allan Schiffman" initials="A." surname="Schiffman">
<organization>SPYRUS/Terisa</organization>

<address>
<postal>
<street>5303 Betsy Ross Drive</street>
<city>Santa Clara</city>
<region>CA</region>
<code>95054</code>
<country>US</country>
</postal>

<phone>+1 408 327 1901</phone>
<email>ams@terisa.com</email>
</address>
</author>

<date year="1999" month="August" />

<abstract>
<t>This memo describes a syntax for embedding S-HTTP negotiation parameters in HTML documents. S-HTTP, as described by RFC 2660, contains the concept of negotiation headers which reflect the potential receiver of a message's preferences as to which cryptographic enhancements should be applied to the message. This document describes a syntax for binding these negotiation parameters to HTML anchors.</t>
</abstract>
</front>

<seriesInfo value="2659" name="RFC" />
</reference>


<reference target2="reference.RFC.2660.xml" anchor="RFC2660">
<front>
<title>The Secure HyperText Transfer Protocol</title>
<author fullname="Eric Rescorla" initials="E." surname="Rescorla">
<organization>RTFM, Inc.</organization>

<address>
<postal>
<street>30 Newell Road</street>
<street>#16</street>
<city>Palo Alto</city>
<region>CA</region>
<code>94303</code>
<country>US</country>
</postal>

<phone>+1 650 328 8631</phone>
<email>ekr@rtfm.com</email>
</address>
</author>

<author fullname="A. Schiffman" initials="A." surname="Schiffman">
<organization>SPYRUS/Terisa</organization>

<address>
<postal>
<street>5303 Betsy Ross Drive</street>
<city>Santa Clara</city>
<region>CA</region>
<code>95054</code>
<country>US</country>
</postal>

<phone>+1 408 327 1901</phone>
<email>ams@terisa.com</email>
</address>
</author>

<date year="1999" month="August" />

<abstract>
<t>This memo describes a syntax for securing messages sent using the Hypertext Transfer Protocol (HTTP), which forms the basis for the World Wide Web. Secure HTTP (S-HTTP) provides independently applicable security services for transaction confidentiality, authenticity/integrity and non-repudiability of origin.</t>

<t>The protocol emphasizes maximum flexibility in choice of key management mechanisms, security policies and cryptographic algorithms by supporting option negotiation between parties for each transaction.</t>
</abstract>
</front>

<seriesInfo value="2660" name="RFC" />
</reference>


<reference target2="reference.RFC.2661.xml" anchor="RFC2661">
<front>
<title abbrev="L2TP">Layer Two Tunneling Protocol "L2TP"</title>
<author fullname="W. Mark Townsley" initials="W." surname="Townsley">
<organization>Cisco Systems</organization>

<address>
<postal>
<street>7025 Kit Creek Road</street>
<city>Research Triangle Park</city>
<region>NC</region>
<code>27709</code>
<country>US</country>
</postal>

<email>townsley@cisco.com</email>
</address>
</author>

<author fullname="A. Valencia" initials="A." surname="Valencia">
<organization>cisco Systems</organization>

<address>
<postal>
<street>170 West Tasman Drive</street>
<city>San Jose</city>
<region>CA</region>
<code>95134-1706</code>
<country>US</country>
</postal>

<email>vandys@cisco.com</email>
</address>
</author>

<author fullname="A. Rubens" initials="A." surname="Rubens">
<organization>Ascend Communications</organization>

<address>
<postal>
<street>1701 Harbor Bay Parkway</street>
<city>Alameda</city>
<region>CA</region>
<code>94502</code>
<country>US</country>
</postal>

<email>acr@del.com</email>
</address>
</author>

<author fullname="Gurdeep Pall" initials="G." surname="Pall">
<organization>Microsoft Corporation</organization>

<address>
<postal>
<street>One Microsoft Way</street>
<city>Redmond</city>
<region>WA</region>
<code>98052</code>
<country>US</country>
</postal>

<email>gurdeep@microsoft.com</email>
</address>
</author>

<author fullname="Glen Zorn" initials="G." surname="Zorn">
<organization>Microsoft Corporation</organization>

<address>
<postal>
<street>One Microsoft Way</street>
<city>Redmond</city>
<region>WA</region>
<code>98052</code>
<country>US</country>
</postal>

<email>gwz@acm.org</email>
</address>
</author>

<author fullname="Bill Palter" initials="B." surname="Palter">
<organization>RedBack Networks, Inc</organization>

<address>
<postal>
<street>1389 Moffett Park Drive</street>
<city>Sunnyvale</city>
<region>CA</region>
<code>94089</code>
<country>US</country>
</postal>

<email>palter@zev.net</email>
</address>
</author>

<date year="1999" month="August" />

<abstract>
<t>This document describes the Layer Two Tunneling Protocol (L2TP). STD 51, RFC 1661 specifies multi-protocol access viaPPP. L2TP facilitates the tunneling of PPP packets across an intervening network in a way that is as transparent as possible to both end-users and applications.</t>
</abstract>
</front>

<seriesInfo value="2661" name="RFC" />
</reference>


<reference target2="reference.RFC.2662.xml" anchor="RFC2662">
<front>
<title abbrev="ADSL Line MIBvv">Definitions of Managed Objects for the ADSL Lines</title>
<author fullname="Gregory Bathrick" initials="G." surname="Bathrick">
<organization>AG Communication Systems
   [A Subsidiary of Lucent Technologies]</organization>

<address>
<postal>
<street>2500 West Utopia Road</street>
<city>Phoenix</city>
<region>AZ</region>
<code>85027</code>
<country>US</country>
</postal>

<phone>+1 602 582 7679</phone>
<email>bathricg@agcs.com</email>
</address>
</author>

<author fullname="Faye Ly" initials="F." surname="Ly">
<organization>Copper Mountain Networks Norcal Office</organization>

<address>
<postal>
<street>2470 Embarcadero Way</street>
<city>Palo Alto</city>
<region>CA</region>
<code>94303</code>
<country>US</country>
</postal>

<phone>+1 650 858 8500</phone>
<email>faye@coppermountain.com</email>
</address>
</author>

<date year="1999" month="August" />

<abstract>
<t>This document defines a standard SNMP MIB for ADSL lines based on theADSL Forum standard data model. The ADSL standard describes ATU-C and ATU-R as two sides of the ADSL line. This MIB covers both
ATU-C and ATU-R agent's perspectives. Each instance defined in the MIB represents a single ADSL line.</t>

<t>It should be noted that the ADSL Forum Network Management Working Group provided input towards the content of this document. See the Acknowledgement Section for a list of individuals who made this document possible.</t>
</abstract>
</front>

<seriesInfo value="2662" name="RFC" />
</reference>


<reference target2="reference.RFC.2663.xml" anchor="RFC2663">
<front>
<title abbrev="NAT Terminology and Considerations">IP Network Address Translator (NAT) Terminology and Considerations</title>
<author fullname="Pyda Srisuresh" initials="P." surname="Srisuresh">
<organization>Lucent Technologies</organization>

<address>
<postal>
<street>4464 Willow Road</street>
<city>Pleasanton</city>
<region>CA</region>
<code>94588-8519</code>
<country>US</country>
</postal>

<phone>+1 925 737 2153</phone>
<email>srisuresh@lucent.com</email>
</address>
</author>

<author fullname="Matt Holdrege" initials="M." surname="Holdrege">
<organization>Lucent Technologiesv</organization>

<address>
<postal>
<street>1701 Harbor Bay Parkway</street>
<city>Alameda</city>
<region>CA</region>
<code>94502</code>
<country>US</country>
</postal>

<phone>+1 510 769 6001</phone>
<email>holdrege@lucent.com</email>
</address>
</author>

<date year="1999" month="August" />

<abstract>
<t>Network Address Translation is a method by which IP addresses are mapped from one realm to another, in an attempt to provide transparent routing to hosts. Traditionally, NAT devices are used to connect an isolated address realm with private unregistered addresses to an external realm with globally unique registered addresses. This document attempts to describe the operation of NAT devices and the associated considerations in general, and to define the terminology used to identify various flavors of NAT.</t>
</abstract>
</front>

<seriesInfo value="2663" name="RFC" />
</reference>


<reference target2="reference.RFC.2664.xml" anchor="RFC2664">
<front>
<title abbrev="FYI Q/A - for New Internet Users">FYI on Questions and Answers - Answers to Commonly Asked "New Internet User" Questions</title>
<author fullname="Raymond. Plzak" initials="R." surname="Plzak">
<organization>SAIC</organization>

<address>
<postal>
<street>1710 Goodridge Drive</street>
<city>McLean</city>
<region>VA</region>
<code>22102</code>
<country>US</country>
</postal>

<phone>+1 703 821 6535</phone>
<email>plzakr@saic.com</email>
</address>
</author>

<author fullname="Amy Tracy Wells" initials="A." surname="Wells">
<organization>Internet Scout Project, University of Wisconsin-Madison</organization>

<address>
<postal>
<street>1210 West Dayton Street</street>
<city>Madison</city>
<region>WI</region>
<code>53706</code>
<country>US</country>
</postal>

<phone>+1 608 263 2611</phone>
<email>awel@cs.wisc.edu</email>
</address>
</author>

<author fullname="Ed Krol" initials="E." surname="Krol">
<organization>University of Illinois</organization>

<address>
<postal>
<street>1120 DCL</street>
<street>1304 Springfield</street>
<city>Urbana</city>
<region>IL</region>
<code>61801</code>
<country>US</country>
</postal>

<phone>+1 217 333 7886</phone>
<email>krol@uiuc.edu</email>
</address>
</author>

<date year="1999" month="August" />

<abstract>
<t>This memo provides an overview to the new Internet User.The intended audience is the common Internet user of today, thus it attempts to provide a more consumer oriented approach to the Internet rather than going into any depth about a topic.
Unlike its predecessors, this edition seeks to answer the general questions that an unsophisticated consumer would ask as opposed to the more pointed questions of a more technically sophisticated Internet user. Those desiring a more in-depth discussion are directed to FYI 7 that deals with intermediate and advanced Q/A topics. A conscious effort has been made to keep this memo brief but at the same time provide the new user with enough information to generally understand the
Internet.</t>
</abstract>
</front>

<seriesInfo value="2664" name="RFC" />
</reference>


<reference target2="reference.RFC.2665.xml" anchor="RFC2665">
<front>
<title abbrev="Ethernet-Like MIB">Definitions of Managed Objects for the Ethernet-like Interface Types</title>
<author fullname="John. Flick" initials="J." surname="Flick">
<organization>Hewlett-Packard Company</organization>

<address>
<postal>
<street>8000 Foothills Boulevard</street>
<street>M/S 5557</street>
<city>Roseville</city>
<region>CA</region>
<code>95747-5557</code>
<country>US</country>
</postal>

<phone>+1 916 785 4018</phone>
<email>johnf@rose.hp.com</email>
</address>
</author>

<author fullname="Jeffrey Johnson" initials="J." surname="Johnson">
<organization>RedBack Networks</organization>

<address>
<postal>
<street>2570 North First Street</street>
<street>Suite 410</street>
<city>San Jose</city>
<region>CA</region>
<code>95131</code>
<country>US</country>
</postal>

<phone>+1 408 571 2699</phone>
<email>jeff@redbacknetworks.com</email>
</address>
</author>

<date year="1999" month="August" />

<abstract>
<t>This memo defines a portion of the Management Information Base (MIB)for use with network management protocols in the Internet community. This memo obsoletes RFC 2358, "Definitions of Managed Objects for the Ethernet-like Interface Types".
This memo extends that specification by including management information useful for the management of 1000 Mb/s and full-duplex Ethernet interfaces.</t>

<t>Ethernet technology, as defined by the 802.3 Working Group of the IEEE, continues to evolve, with scalable increases in speed, new types of cabling and interfaces, and new features. This evolution may require changes in the managed objects in order to reflect this new functionality. This document, as with other documents issued by this working group, reflects a certain stage in the evolution of Ethernet technology. In the future, this document might be revised, or new documents might be issued by the Ethernet Interfaces and Hub MIB Working Group, in order to reflect the evolution of Ethernet
technology.</t>
</abstract>
</front>

<seriesInfo value="2665" name="RFC" />
</reference>


<reference target2="reference.RFC.2666.xml" anchor="RFC2666">
<front>
<title abbrev="Ethernet Chipset MIB">Definitions of Object Identifiers for Identifying Ethernet Chip Sets</title>
<author fullname="J. Flick" initials="J." surname="Flick">
<organization>Hewlett-Packard Company</organization>

<address>
<postal>
<street>8000 Foothills Blvd</street>
<street>M/S 5557</street>
<city>Roseville</city>
<region>CA</region>
<code>95747-5557</code>
<country>US</country>
</postal>

<phone>+1 916 785 4018</phone>
<email>johnf@rose.hp.com</email>
</address>
</author>

<date year="1999" month="August" />

<abstract>
<t>This memo defines OBJECT IDENTIFIER values for use with network management protocols in the Internet community. In particular, it contains registered OID values for use with the dot3StatsEtherChipSet object in theEtherLike-MIB. These registrations have been split frominto a separate document for maintenance purposes.</t>
</abstract>
</front>

<seriesInfo value="2666" name="RFC" />
</reference>


<reference target2="reference.RFC.2667.xml" anchor="RFC2667">
<front>
<title>IP Tunnel MIB</title>
<author fullname="Dave Thaler" initials="D." surname="Thaler">
<organization>Microsoft Corporation</organization>

<address>
<postal>
<street>One Microsoft Way</street>
<city>Redmond</city>
<region>WA</region>
<code>98052</code>
<country>US</country>
</postal>

<phone>+1 425 703 8835</phone>
<email>dthaler@microsoft.com</email>
</address>
</author>

<date year="1999" month="August" />

<abstract>
<t>This memo defines a Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes managed objects used for managing tunnels of any type over IPv4 networks. Extension MIBs may be designed for managing protocol-specific objects. Likewise, extension MIBs may be designed for managing security-specific objects. This MIB does not support tunnels over non-IPv4 networks (including IPv6 networks). Management of such tunnels may be supported by other MIBs.</t>
</abstract>
</front>

<seriesInfo value="2667" name="RFC" />
</reference>


<reference target2="reference.RFC.2668.xml" anchor="RFC2668">
<front>
<title abbrev="802.3 MAU MIB">Definitions of Managed Objects for IEEE 802.3 Medium Attachment Units (MAUs)</title>
<author fullname="Andrew Smith" initials="A." surname="Smith">
<organization>Extreme Networks, Inc.</organization>

<address>
<postal>
<street>3585 Monroe Street</street>
<city>Santa Clara</city>
<region>CA</region>
<code>95051</code>
<country>US</country>
</postal>

<phone>+1 408 579 2821</phone>
<email>andrew@extremenetworks.com</email>
</address>
</author>

<author fullname="John Flick" initials="J." surname="Flick">
<organization>Hewlett-Packard Company</organization>

<address>
<postal>
<street>8000 Foothills Blvd. M/S 5557</street>
<city>Roseville</city>
<region>CA</region>
<code>95747-5557</code>
<country>US</country>
</postal>

<phone>+1 916 785 4018</phone>
<email>johnf@rose.hp.com</email>
</address>
</author>

<author fullname="Kathryn de Graaf" initials="K." surname="de Graaf">
<organization>Argon Networks</organization>

<address>
<postal>
<street>25 Porter Road</street>
<city>Littleton</city>
<region>MA</region>
<code>01460</code>
<country>US</country>
</postal>

<phone>+1 978 486 0665 x163</phone>
<email>kdegraaf@argon.com</email>
</address>
</author>

<author fullname="Dan Romascanu" initials="D." surname="Romascanu">
<organization>Lucent Technologies</organization>

<address>
<postal>
<street>Atidim Technology Park</street>
<street>Building 3</street>
<city>Tel Aviv</city>
<region />
<code>61131</code>
<country>IL</country>
</postal>

<phone>+972 3 6458414</phone>
<email>dromasca@lucent.com</email>
</address>
</author>

<author fullname="Donna McMaster" initials="D." surname="McMaster">
<organization>Cisco Systems Inc.</organization>

<address>
<postal>
<street>170 West Tasman Drive</street>
<city>San Jose</city>
<region>CA</region>
<code>95134</code>
<country>US</country>
</postal>

<phone>+1 408 526 5260</phone>
<email>mcmaster@cisco.com</email>
</address>
</author>

<author fullname="Keith McCloghrie" initials="K." surname="McCloghrie">
<organization />

<address>
<postal>
<street>170 West Tasman Drive</street>
<city>San Jose</city>
<region>CA</region>
<code>95134</code>
<country>US</country>
</postal>

<phone>+1 408 526 5260</phone>
<email>kzm@cisco.com</email>
</address>
</author>

<author fullname="Sam Roberts" initials="S." surname="Roberts">
<organization>Farallon Computing, Inc.</organization>

<address>
<postal>
<street>2470 Mariner Square Loop</street>
<city>Alameda</city>
<region>CA</region>
<code>94501-1010</code>
<country>US</country>
</postal>

<phone>+1 510 814 5215</phone>
<email>sroberts@farallon.com</email>
</address>
</author>

<date year="1999" month="August" />

<abstract>
<t>This memo defines a portion of the Management Information Base (MIB)for use with network management protocols in the Internet community. This memo obsoletes RFC 2239, "Definitions of Managed Objects for IEEE 802.3 Medium Attachment Units (MAUs) using SMIv2". This memo extends that specification by including management information useful for the management of 1000 Mb/s MAUs.</t>

<t>Ethernet technology, as defined by the 802.3 Working Group of the IEEE, continues to evolve, with scalable increases in speed, new types of cabling and interfaces, and new features. This evolution may require changes in the managed objects in order to reflect this new functionality. This document, as with other documents issued by this working group, reflects a certain stage in the evolution of Ethernet technology. In the future, this document might be revised, or new documents might be issued by the Ethernet Interfaces and Hub MIB Working Group, in order to reflect the evolution of Ethernet
technology.</t>
</abstract>
</front>

<seriesInfo value="2668" name="RFC" />
</reference>


<reference target2="reference.RFC.2669.xml" anchor="RFC2669">
<front>
<title abbrev="DOCSIS Cable Device MIB">DOCSIS Cable Device MIB Cable Device Management Information Base for DOCSIS compliant Cable Modems and Cable Modem Termination Systems</title>
<author fullname="Michael St. Johns" initials="M." surname="St. Johns">
<organization>@Home Network</organization>

<address>
<postal>
<street>425 Broadway</street>
<city>Redwood City</city>
<region>CA</region>
<code>94063</code>
<country>US</country>
</postal>

<phone>+1 650 569 5368</phone>
<email>stjohns@corp.home.net</email>
</address>
</author>

<date year="1999" month="August" />

<abstract>
<t>This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it defines a basic set of managed objects for SNMP- based management of DOCSIS 1.0 compliant Cable Modems and Cable Modem Termination Systems.</t>

<t>This memo specifies a MIB module in a manner that is compliant to the SNMP SMIv2. The set of objects is consistent with the SNMP framework and existing SNMP standards.</t>

<t>This memo is a product of the IPCDN working group within the Internet Engineering Task Force. Comments are solicited and should be addressed to the working group's mailing list at ipcdn@terayon.com and/or the author.</t>
</abstract>
</front>

<seriesInfo value="2669" name="RFC" />
</reference>


<reference target2="reference.RFC.2670.xml" anchor="RFC2670">
<front>
<title abbrev="DOCSIS RF Interface MIB">Radio Frequency (RF) Interface Management Information Base for MCNS/DOCSIS compliant RF interfaces</title>
<author fullname="Michael St.Johns" initials="M." surname="St. Johns">
<organization>@Home Network</organization>

<address>
<postal>
<street>425 Broadway</street>
<city>Redwood City</city>
<region>CA</region>
<code>94063</code>
<country>US</country>
</postal>

<phone>+1 650 569 5368</phone>
<email>stjohns@corp.home.net</email>
</address>
</author>

<date year="1999" month="August" />

<abstract>
<t>This memo defines a portion of the Management Information Base (MIB)for use with network management protocols in the Internet community.In particular, it defines a basic set of managed objects for SNMP-based management of MCNS/DOCSIS compliant Radio Frequency (RF)interfaces.</t>

<t>This memo specifies a MIB module in a manner that is compliant to the SNMP SMIv2. The set of objects are consistent with the SNMP framework and existing SNMP standards.</t>

<t>This memo is a product of the IPCDN working group within the Internet Engineering Task Force. Comments are solicited and should be addressed to the working group's mailing list at ipcdn@terayon.com and/or the author.</t>
</abstract>
</front>

<seriesInfo value="2670" name="RFC" />
</reference>


<reference target2="reference.RFC.2671.xml" anchor="RFC2671">
<front>
<title>Extension Mechanisms for DNS (EDNS0)</title>
<author fullname="Paul Vixie" initials="P." surname="Vixie">
<organization>Internet Software Consortium</organization>

<address>
<postal>
<street>950 Charter Street</street>
<city>Redwood City</city>
<region>CA</region>
<code>94063</code>
<country>US</country>
</postal>

<phone>+1 650 779 7001</phone>
<email>vixie@isc.org</email>
</address>
</author>

<date year="1999" month="August" />

<abstract>
<t>The Domain Name System's wire protocol includes a number of fixed fields whose range has been or soon will be exhausted and does not allow clients to advertise their capabilities to servers. This document describes backward compatible mechanisms for allowing the protocol to grow.</t>
</abstract>
</front>

<seriesInfo value="2671" name="RFC" />
</reference>


<reference target2="reference.RFC.2672.xml" anchor="RFC2672">
<front>
<title>Non-Terminal DNS Name Redirection</title>
<author fullname="Matt Crawford" initials="M." surname="Crawford">
<organization>Fermilab MS 368</organization>

<address>
<postal>
<street>PO Box 500</street>
<city>Batavia</city>
<region>IL</region>
<code>60510</code>
<country>US</country>
</postal>

<phone>+1 630 840 3461</phone>
<email>crawdad@fnal.gov</email>
</address>
</author>

<date year="1999" month="August" />
</front>

<seriesInfo value="2672" name="RFC" />
</reference>


<reference target2="reference.RFC.2673.xml" anchor="RFC2673">
<front>
<title>Binary Labels in the Domain Name System</title>
<author fullname="Matt Crawford" initials="M." surname="Crawford">
<organization>Fermilab MS 368</organization>

<address>
<postal>
<street>PO Box 500</street>
<city>Batavia</city>
<region>IL</region>
<code>60510</code>
<country>US</country>
</postal>

<phone>+1 630 840 3461</phone>
<email>crawdad@fnal.gov</email>
</address>
</author>

<date year="1999" month="August" />
</front>

<seriesInfo value="2673" name="RFC" />
</reference>


<reference target2="reference.RFC.2674.xml" anchor="RFC2674">
<front>
<title abbrev="Bridge MIB Extensions">Definitions of Managed Objects for Bridges with Traffic Classes, Multicast Filtering and Virtual LAN Extensions</title>
<author fullname="Les Bell" initials="L." surname="Bell">
<organization>3Com Europe Limited</organization>

<address>
<postal>
<street>3Com Centre</street>
<street>Boundary Way</street>
<street>Hemel Hempstead</street>
<city>Herts</city>
<region>England</region>
<code>HP2 7YU</code>
<country>UK</country>
</postal>

<phone>+44 1442 438025</phone>
<email>Les_Bell@3Com.com</email>
</address>
</author>

<author fullname="Andrew Smith" initials="A." surname="Smith">
<organization>Extreme Networks</organization>

<address>
<postal>
<street>3585 Monroe St.</street>
<city>Santa Clara</city>
<region>CA</region>
<code>95051</code>
<country>US</country>
</postal>

<phone>+1 408 579 2821</phone>
<email>andrew@extremenetworks.com</email>
</address>
</author>

<author fullname="Paul Langille" initials="P." surname="Langille">
<organization>Newbridge Networks</organization>

<address>
<postal>
<street>5 Corporate Drive</street>
<city>Andover</city>
<region>MA</region>
<code>01810</code>
<country>US</country>
</postal>

<phone>+1 978 691 4665</phone>
<email>langille@newbridge.com</email>
</address>
</author>

<author fullname="Anil Rijhsinghani" initials="A." surname="Rijhsinghani">
<organization>Cabletron Systems</organization>

<address>
<postal>
<street>50 Minuteman Road</street>
<city>Andover</city>
<region>MA</region>
<code>01810</code>
<country>US</country>
</postal>

<phone>+1 978 684 1295</phone>
<email>anil@cabletron.com</email>
</address>
</author>

<author fullname="Keith McCloghrie" initials="K." surname="McCloghrie">
<organization>cisco Systems, Inc.</organization>

<address>
<postal>
<street>170 West Tasman Drive</street>
<city>San Jose</city>
<region>CA</region>
<code>95134-1706</code>
<country>US</country>
</postal>

<phone>+1 408 526 5260</phone>
<email>kzm@cisco.com</email>
</address>
</author>

<date year="1999" month="August" />

<abstract>
<t>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 two MIB modules for managing the new capabilities of MAC bridges defined by the IEEE 802.1D-1998 MAC Bridges and the IEEE 802.1Q-1998 Virtual LAN (VLAN) standards for bridging between Local Area Network (LAN) segments. One MIB module defines objects for managing the 'Traffic Classes' and 'Enhanced Multicast Filtering' components of IEEE 802.1D-1998. The other MIB module defines objects for managing IEEE 802.1Q VLANs.</t>

<t>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 theSMIv2.</t>

<t>This memo supplementsRFC 1493and (to a lesser extent)RFC 1525.</t>
</abstract>
</front>

<seriesInfo value="2674" name="RFC" />
</reference>


<reference target2="reference.RFC.2675.xml" anchor="RFC2675">
<front>
<title>IPv6 Jumbograms</title>
<author fullname="David Borman" initials="D." surname="Borman">
<organization>Berkeley Software Design, Inc.</organization>

<address>
<postal>
<street>4719 Weston Hills Drive</street>
<city>Eagan</city>
<region>MN</region>
<code>55123</code>
<country>US</country>
</postal>

<phone>+1 612 405 8194</phone>
<email>dab@bsdi.com</email>
</address>
</author>

<author fullname="Stephen Deering" initials="S." surname="Deering">
<organization>Cisco Systems, Inc.</organization>

<address>
<postal>
<street>170 West Tasman Drive</street>
<city>San Jose</city>
<region>CA</region>
<code>95134-1706</code>
<country>US</country>
</postal>

<phone>+1 408 527 8213</phone>
<email>deering@cisco.com</email>
</address>
</author>

<author fullname="Robert Hinden" initials="R." surname="Hinden">
<organization>Nokia</organization>

<address>
<postal>
<street>313 Fairchild Drive</street>
<city>Mountain View</city>
<region>CA</region>
<code>94043</code>
<country>US</country>
</postal>

<phone>+1 650 625 2004</phone>
<email>hinden@iprg.nokia.com</email>
</address>
</author>

<date year="1999" month="August" />

<abstract>
<t>A "jumbogram" is an IPv6 packet containing a payload longer than
65,535 octets. This document describes the IPv6 Jumbo Payload option, which provides the means of specifying such large payload lengths. It also describes the changes needed to TCP and UDP to make use of jumbograms.</t>

<t>Jumbograms are relevant only to IPv6 nodes that may be attached to links with a link MTU greater than 65,575 octets, and need not be implemented or understood by IPv6 nodes that do not support attachment to links with such large MTUs.</t>
</abstract>
</front>

<seriesInfo value="2675" name="RFC" />
</reference>


<reference target2="reference.RFC.2676.xml" anchor="RFC2676">
<front>
<title>QoS Routing Mechanisms and OSPF Extensions</title>
<author fullname="George Apostolopoulos" initials="G." surname="Apostolopoulos">
<organization>IBM T.J. Watson Research Center</organization>

<address>
<postal>
<street>PO Box 704</street>
<city>Yorktown Heights</city>
<region>NY</region>
<code>10598</code>
<country>US</country>
</postal>

<phone>+1 914 784 6204</phone>
<email>georgeap@watson.ibm.com</email>
</address>
</author>

<author fullname="Sanjay Kamat" initials="S." surname="Kamat">
<organization>Bell Laboratories</organization>

<address>
<postal>
<street>101 Crawfords Corner Road</street>
<city>Holmdel</city>
<region>NJ</region>
<code>07733</code>
<country>US</country>
</postal>

<phone>+1 732 949 5936</phone>
<email>sanjayk@dnrc.bell-labs.com</email>
</address>
</author>

<author fullname="Doug Williams" initials="D." surname="Williams">
<organization>IBM T.J. Watson Research Center</organization>

<address>
<postal>
<street>PO Box 704</street>
<city>Yorktown Heights</city>
<region>NY</region>
<code>10598</code>
<country>US</country>
</postal>

<phone>+1 914 784 5047</phone>
<email>dougw@watson.ibm.com</email>
</address>
</author>

<author fullname="Roch Guerin" initials="R." surname="Guerin">
<organization>University Of Pennsylvania
Department of Electrical Engineering</organization>

<address>
<postal>
<street>200 South 33rd Street</street>
<city>Philadelphia</city>
<region>PA</region>
<code>19104-6390</code>
<country>US</country>
</postal>

<phone>+1 215 898 9351</phone>
<email>guerin@ee.upenn.edu</email>
</address>
</author>

<author fullname="Ariel Orda" initials="A." surname="Orda">
<organization>Dept. Electrical Engineering Technion - I.I.T</organization>

<address>
<postal>
<street />
<city>Haifa</city>
<code>32000</code>
<country>IL</country>
</postal>

<phone>+972 4 8294646</phone>
<facsimile>+972 4 8323041</facsimile>
<email>ariel@ee.technion.ac.il</email>
</address>
</author>

<author fullname="Tony Przygienda" initials="T." surname="Przygienda">
<organization>Siara Systems</organization>

<address>
<postal>
<street>300 Ferguson Drive</street>
<city>Mountain View</city>
<region>CA</region>
<code>94043</code>
<country>US</country>
</postal>

<phone>+1 732 949 5936</phone>
<email>prz@siara.com</email>
</address>
</author>

<date year="1999" month="August" />

<abstract>
<t>This memo describes extensions to theOSPFprotocol to support QoS routes.
The focus of this document is on the algorithms used to compute QoS routes and on the necessary modifications to OSPF
to support this function, e.g., the information needed, its format, how it is distributed, and how it is used by the QoS path selection process. Aspects related to how QoS routes are established and managed are also briefly discussed.
The goal of this document is to identify a framework and possible approaches to allow deployment of
QoS routing capabilities with the minimum possible impact to the existing routing infrastructure.</t>

<t>In addition, experience from an implementation of the proposed extensions in theGateD environment, along with performance measurements is presented.</t>
</abstract>
</front>

<seriesInfo value="2676" name="RFC" />
</reference>


<reference target2="reference.RFC.2677.xml" anchor="RFC2677">
<front>
<title abbrev="NHRP MIB">Definitions of Managed Objects for the NBMA Next Hop Resolution Protocol (NHRP)</title>
<author fullname="Maria Greene" initials="M." surname="Greene">
<organization>Xedia, Corp.</organization>

<address>
<postal>
<street>119 Russell Drive</street>
<city>Littleton</city>
<region>MA</region>
<code>01460</code>
<country>US</country>
</postal>

<email>maria@xedia.com</email>
</address>
</author>

<author fullname="Joan Cucchiara" initials="J." surname="Cucchiara">
<organization>IronBridge Networks</organization>

<address>
<postal>
<street>55 Hayden Avenue</street>
<city>Lexington</city>
<region>MA</region>
<code>02421</code>
<country>US</country>
</postal>

<phone>+1 781 372 8236</phone>
<email>joan@ironbridgenetworks.com</email>
</address>
</author>

<author fullname="James Luciani" initials="J." surname="Luciani">
<organization>Bay Networks</organization>

<address>
<postal>
<street>3 Federal Street</street>
<city>Billerica</city>
<region>MA</region>
<code>01821</code>
<country>US</country>
</postal>

<phone>+1 978 288 4734</phone>
<email>luciani@baynetworks.com</email>
</address>
</author>

<date year="1999" month="August" />

<abstract>
<t>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 for the Next Hop Resolution Protocol (NHRP) as defined in RFC 2332.</t>
</abstract>
</front>

<seriesInfo value="2677" name="RFC" />
</reference>


<reference target2="reference.RFC.2678.xml" anchor="RFC2678">
<front>
<title>IPPM Metrics for Measuring Connectivity</title>
<author fullname="Jamshid Mahdavi" initials="J." surname="Mahdavi">
<organization>Pittsburgh Supercomputing Center</organization>

<address>
<postal>
<street>4400 5th Avenue</street>
<city>Pittsburgh</city>
<region>PA</region>
<code>15213</code>
<country>US</country>
</postal>

<email>mahdavi@psc.edu</email>
</address>
</author>

<author fullname="Vern Paxson" initials="V." surname="Paxson">
<organization>Lawrence Berkeley National Laboratory</organization>

<address>
<postal>
<street>University of California</street>
<city>Berkeley</city>
<region>CA</region>
<code>94720</code>
<country>US</country>
</postal>

<phone>+1 510 486 7504</phone>
<email>vern@ee.lbl.gov</email>
</address>
</author>

<date year="1999" month="September" />
</front>

<seriesInfo value="2678" name="RFC" />
</reference>


<reference target2="reference.RFC.2679.xml" anchor="RFC2679">
<front>
<title>A One-way Delay Metric for IPPM</title>
<author fullname="Guy Almes" initials="G." surname="Almes">
<organization>Advanced Network &amp; Services, Inc.</organization>

<address>
<postal>
<street>200 Business Park Drive</street>
<city>Armonk</city>
<region>NY</region>
<code>10504</code>
<country>US</country>
</postal>

<phone>+1 914 765 1120</phone>
<email>almes@advanced.org</email>
</address>
</author>

<author fullname="Sunil Kalidindi" initials="S." surname="Kalidindi">
<organization>Advanced Network &amp; Services, Inc.</organization>

<address>
<postal>
<street>200 Business Park Drive</street>
<city>Armonk</city>
<region>NY</region>
<code>10504</code>
<country>US</country>
</postal>

<phone>+1 914 765 1128</phone>
<email>kalidindi@advanced.org</email>
</address>
</author>

<author fullname="Matthew J. Zekauskas" initials="M." surname="Zekauskas">
<organization>Advanced Network &amp; Services, Inc.</organization>

<address>
<postal>
<street>200 Business Park Drive</street>
<city>Armonk</city>
<region>NY</region>
<code>10504</code>
<country>US</country>
</postal>

<phone>+1 914 765 1112</phone>
<email>matt@advanced.org</email>
</address>
</author>

<date year="1999" month="September" />
</front>

<seriesInfo value="2679" name="RFC" />
</reference>


<reference target2="reference.RFC.2680.xml" anchor="RFC2680">
<front>
<title>A One-way Packet Loss Metric for IPPM</title>
<author fullname="Guy Almes" initials="G." surname="Almes">
<organization>Advanced Network &amp; Services, Inc.</organization>

<address>
<postal>
<street>200 Business Park Drive</street>
<city>Armonk</city>
<region>NY</region>
<code>10504</code>
<country>US</country>
</postal>

<phone>+1 914 765 1120</phone>
<email>almes@advanced.org</email>
</address>
</author>

<author fullname="S. Kalidindi" initials="S." surname="Kalidindi">
<organization>Advanced Network &amp; Services, Inc.</organization>

<address>
<postal>
<street>200 Business Park Drive</street>
<city>Armonk</city>
<region>NY</region>
<code>10504</code>
<country>US</country>
</postal>

<phone>+1 914 765 1128</phone>
<email>kalidindi@advanced.org</email>
</address>
</author>

<author fullname="M. Zekauskas" initials="M." surname="Zekauskas">
<organization>Advanced Network &amp; Services, Inc.</organization>

<address>
<postal>
<street>200 Business Park Drive</street>
<city>Armonk</city>
<region>NY</region>
<code>10504</code>
<country>US</country>
</postal>

<phone>+1 914 765 1112</phone>
<email>matt@advanced.org</email>
</address>
</author>

<date year="1999" month="September" />
</front>

<seriesInfo value="2680" name="RFC" />
</reference>


<reference target2="reference.RFC.2681.xml" anchor="RFC2681">
<front>
<title>A Round-trip Delay Metric for IPPM</title>
<author fullname="Guy Almes" initials="G." surname="Almes">
<organization>Advanced Network &amp; Services, Inc.</organization>

<address>
<postal>
<street>200 Business Park Drive</street>
<city>Armonk</city>
<region>NY</region>
<code>10504</code>
<country>US</country>
</postal>

<phone>+1 914 765 1120</phone>
<email>almes@advanced.org</email>
</address>
</author>

<author fullname="Sunil Kalidindi" initials="S." surname="Kalidindi">
<organization>Advanced Network &amp; Services, Inc.</organization>

<address>
<postal>
<street>200 Business Park Drive</street>
<city>Armonk</city>
<region>NY</region>
<code>10504</code>
<country>US</country>
</postal>

<phone>+1 914 765 1128</phone>
<email>kalidindi@advanced.org</email>
</address>
</author>

<author fullname="Matthew J. Zekauskas" initials="M." surname="Zekauskas">
<organization>Advanced Network &amp; Services, Inc.</organization>

<address>
<postal>
<street>200 Business Park Drive</street>
<city>Armonk</city>
<region>NY</region>
<code>10504</code>
<country>US</country>
</postal>

<phone>+1 914 765 1112</phone>
<email>matt@advanced.org</email>
</address>
</author>

<date year="1999" month="September" />
</front>

<seriesInfo value="2681" name="RFC" />
</reference>


<reference target2="reference.RFC.2682.xml" anchor="RFC2682">
<front>
<title abbrev="Issues in VC Merge Capable ATM LSRs">Performance Issues in VC-Merge Capable ATM LSRs</title>
<author fullname="Indra Widjaja" initials="I." surname="Widjaja">
<organization>Fujitsu Network Communications</organization>

<address>
<postal>
<street>Two Blue Hill Plaza</street>
<city>Pearl River</city>
<region>NY</region>
<code>10965</code>
<country>US</country>
</postal>

<phone>+1 914 731 2244</phone>
<email>indra.widjaja@fnc.fujitsu.com</email>
</address>
</author>

<author fullname="Anwar Elwalid" initials="A." surname="Elwalid">
<organization>Bell Labs, Lucent Technologies</organization>

<address>
<postal>
<street>600 Mountain Avnue</street>
<street>Room 2C-324</street>
<city>Murray Hill</city>
<region>NJ</region>
<code>07974</code>
<country>US</country>
</postal>

<phone>+1 908 582 7589</phone>
<email>anwar@lucent.com</email>
</address>
</author>

<date year="1999" month="September" />

<abstract>
<t>VC merging allows many routes to be mapped to the same VC label,
thereby providing a scalable mapping method that can support
thousands of edge routers.
VC merging requires reassembly buffers so
that cells belonging to different packets intended for the same
destination do not interleave with each other.
This document
investigates the impact of VC merging on the additional buffer
required for the reassembly buffers and other buffers.
The main
result indicates that VC merging incurs a minimal overhead compared
to non-VC merging in terms of additional buffering.
Moreover, the
overhead decreases as utilization increases, or as the traffic
becomes more bursty.</t>
</abstract>
</front>

<seriesInfo value="2682" name="RFC" />
</reference>


<reference target2="reference.RFC.2683.xml" anchor="RFC2683">
<front>
<title>IMAP4 Implementation Recommendations</title>
<author fullname="Barry Leiba" initials="B." surname="Leiba">
<organization>IBM T.J. Watson Research Center</organization>

<address>
<postal>
<street>30 Saw Mill River Road</street>
<city>Hawthorne</city>
<region>NY</region>
<code>10532</code>
<country>US</country>
</postal>

<phone>+1 914 784 7941</phone>
<email>leiba@watson.ibm.com</email>
</address>
</author>

<date year="1999" month="September" />

<abstract>
<t>TheIMAP4 specificationdescribes a rich protocol for use in building clients nd servers for storage, retrieval, and manipulation of electronic mail. Because the protocol is so rich and has so many implementation choices, there are often trade-offs that must be made and issues that must be considered when designing such clients and servers. This document attempts to outline these issues and to make recommendations in order to make the end products as interoperable as possible.</t>
</abstract>
</front>

<seriesInfo value="2683" name="RFC" />
</reference>


<reference target2="reference.RFC.2684.xml" anchor="RFC2684">
<front>
<title abbrev="Multiprotocol Over AALS">Multiprotocol Encapsulation over ATM Adaptation Layer 5</title>
<author fullname="Dan Grossman" initials="D." surname="Grossman">
<organization>Motorola, Inc.</organization>

<address>
<postal>
<street>20 Cabot Boulevard</street>
<city>Mansfield</city>
<region>MA</region>
<code>02048</code>
<country>US</country>
</postal>

<email>dan@dma.isg.mot.com</email>
</address>
</author>

<author fullname="Juha Heinanen" initials="J." surname="Heinanen">
<organization>Telia Finland</organization>

<address>
<postal>
<street>Myyrmaentie 2</street>
<city>Vantaa</city>
<code>01600</code>
<country>FI</country>
</postal>

<email>jh@telia.fi</email>
</address>
</author>

<date year="1999" month="September" />
</front>

<seriesInfo value="2684" name="RFC" />
</reference>


<reference target2="reference.RFC.2685.xml" anchor="RFC2685">
<front>
<title>Virtual Private Networks Identifier</title>
<author fullname="Barbara A. Fox" initials="B." surname="Fox">
<organization>Lucent Technologies</organization>

<address>
<postal>
<street>300 Baker Avenue</street>
<street>Suite 100</street>
<city>Concord</city>
<region>MA</region>
<code>01742-2168</code>
<country>US</country>
</postal>

<phone>+1 978 287 2843</phone>
<email>barbarafox@lucent.com</email>
</address>
</author>

<author fullname="Bryan Gleeson" initials="B." surname="Gleeson">
<organization>Nortel Networks</organization>

<address>
<postal>
<street>4500 Great America Parkway</street>
<city>Santa Clara</city>
<region>CA</region>
<code>95054</code>
<country>US</country>
</postal>

<phone>+1 408 855 3711</phone>
<email>bgleeson@shastanets.com</email>
</address>
</author>

<date year="1999" month="September" />

<abstract>
<t>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). This document proposes a format for a globally unique VPN identifier.</t>
</abstract>
</front>

<seriesInfo value="2685" name="RFC" />
</reference>


<reference target2="reference.RFC.2686.xml" anchor="RFC2686">
<front>
<title abbrev="Multi-Class Extension to Multi-Link PPP">The Multi-Class Extension to Multi-Link PPP</title>
<author fullname="Carsten Bormann" initials="C." surname="Bormann">
<organization>Universitaet Bremen FB3 TZI</organization>

<address>
<postal>
<street>Postfach 330440</street>
<city>Bremen</city>
<code>D-28334</code>
<country>DE</country>
</postal>

<phone>+49 421 2187024</phone>
<email>cabo@tzi.org</email>
</address>
</author>

<date year="1999" month="September" />

<abstract>
<t>A companion document describes an architecture for providing
integrated services over low-bitrate links, such as modem lines, ISDN
B-channels, and sub-T1 links. The main components of the architecture are: a real-time encapsulation format for asynchronous
and synchronous low-bitrate links, a header compression architecture
optimized for real-time flows, elements of negotiation protocols used
between routers (or between hosts and routers), and announcement
protocols used by applications to allow this negotiation to take
place.</t>

<t>This document proposes the fragment-oriented solution for the real-time encapsulation format part of the architecture. The general approach is to start from the PPP Multilink fragmentation protocoland provide a small number of extensions to add functionality and reduce the overhead.</t>
</abstract>
</front>

<seriesInfo value="2686" name="RFC" />
</reference>


<reference target2="reference.RFC.2687.xml" anchor="RFC2687">
<front>
<title abbrev="PPP in Real-time Oriented HDLC Framing">PPP in a Real-time Oriented HDLC-like Framing</title>
<author fullname="Carsten Bormann" initials="C." surname="Bormann">
<organization>Universitaet Bremen FB3 TZI</organization>

<address>
<postal>
<street>Postfach 330440</street>
<city>Bremen</city>
<code>D-28334</code>
<country>DE</country>
</postal>

<phone>+49 421 2187024</phone>
<email>cabo@tzi.org</email>
</address>
</author>

<date year="1999" month="September" />

<abstract>
<t>A companion document describes an architecture for providing
integrated services over low-bitrate links, such as modem lines, ISDN
B-channels, and sub-T1 links. The main components of the architecture are: a real-time encapsulation format for asynchronous
and synchronous low-bitrate links, a header compression architecture
optimized for real-time flows, elements of negotiation protocols used
between routers (or between hosts and routers), and announcement
protocols used by applications to allow this negotiation to take
place.</t>

<t>This document proposes the suspend/resume-oriented solution for the real-time encapsulation format part of the architecture. The general
approach is to start from the PPP Multilink fragmentation protocoland its multi-class extensionand add suspend/resume in a way that is as compatible to existing hard- and firmware as possible.</t>
</abstract>
</front>

<seriesInfo value="2687" name="RFC" />
</reference>


<reference target2="reference.RFC.2688.xml" anchor="RFC2688">
<front>
<title abbrev="Integrated Services Mappings">Integrated Services Mappings for Low Speed Networks</title>
<author fullname="Steve Jackowski" initials="S." surname="Jackowski">
<organization>Deterministic Networks, Inc.</organization>

<address>
<postal>
<street>245M Mount Hermon Road</street>
<street>#140</street>
<city>Scotts Valley</city>
<region>CA</region>
<code>95066</code>
<country>US</country>
</postal>

<phone>+1 408 813 6294</phone>
<email>stevej@DeterministicNetworks.com</email>
</address>
</author>

<author fullname="David Putzolu" initials="D." surname="Putzolu">
<organization>Intel Architecture Labs (IAL)</organization>

<address>
<postal>
<street>2111 NE 25th Avenue</street>
<street>JF3-206-H10</street>
<city>Hillsboro</city>
<region>OR</region>
<code>97124-5961</code>
<country>US</country>
</postal>

<phone>+1 503 264 4510</phone>
<email>David.Putzolu@intel.com</email>
</address>
</author>

<author fullname="Eric S. Crawley" initials="E." surname="Crawley">
<organization>Argon Networks, Inc.</organization>

<address>
<postal>
<street>25 Porter Road</street>
<city>Littleton</city>
<region>MA</region>
<code>01460</code>
<country>US</country>
</postal>

<phone>+1 978 486 0665</phone>
<email>esc@argon.com</email>
</address>
</author>

<author fullname="Bruce Davie" initials="B." surname="Davie">
<organization>Cisco Systems, Inc.</organization>

<address>
<postal>
<street>250 Apollo Drive</street>
<city>Chelmsford</city>
<region>MA</region>
<code>01824</code>
<country>US</country>
</postal>

<phone>+1 978 244 8921</phone>
<email>bdavie@cisco.com</email>
</address>
</author>

<date year="1999" month="September" />

<abstract>
<t>A set of companion documents describe an architecture for providing integrated services over low-bitrate links, such as modem lines, ISDN
B-channels, and sub-T1 links,,,. The main components of the architecture are: a set of real-time encapsulation formats for asynchronous and synchronous low-bitrate links, a header compression architecture optimized for real-time flows, elements of negotiation protocols used between routers (or between hosts and routers), and
announcement protocols used by applications to allow this negotiation
to take place.</t>

<t>This document defines the service mappings of the IETF Integrated Services for low-bitrate links, specifically the controlled loadand guaranteedservices.
The approach takes the form of a set of guidelines and considerations for implementing these services, along with evaluation criteria for elements providing these services.</t>
</abstract>
</front>

<seriesInfo value="2688" name="RFC" />
</reference>


<reference target2="reference.RFC.2689.xml" anchor="RFC2689">
<front>
<title>Providing Integrated Services over Low-bitrate Links</title>
<author fullname="C. Bormann" initials="C." surname="Bormann">
<organization />
</author>

<date year="1999" month="September" />

<abstract>
<t>This document describes an architecture for providing integrated services over low-bitrate links, such as modem lines, ISDN B-channels, and sub-T1 links.  It covers only the lower parts of the Internet Multimedia Conferencing Architecture; additional components required for application services such as Internet Telephony (e.g., a session initiation protocol) are outside the scope of this document.  The main components of the architecture are: a real-time encapsulation format for asynchronous and synchronous low- bitrate links, a header compression architecture optimized for real-time flows, elements of negotiation protocols used between routers (or between hosts and routers), and announcement protocols used by applications to allow this negotiation to take place.</t>
</abstract>
</front>

<seriesInfo value="2689" name="RFC" />
</reference>


<reference target2="reference.RFC.2690.xml" anchor="RFC2690">
<front>
<title abbrev="Informational ICANN PSO Proposal">A Proposal for an MOU-Based ICANN Protocol Support Organization</title>
<author fullname="Scott Bradner" initials="S." surname="Bradner">
<organization>Harvard University</organization>

<address>
<postal>
<street>1350 Mass Avenue</street>
<street>Room 876</street>
<city>Cambridge</city>
<region>MA</region>
<code>02138</code>
<country>US</country>
</postal>

<phone>+1 617 495 3864</phone>
<email>sob@harvard.edu</email>
</address>
</author>

<date year="1999" month="September" />

<abstract>
<t>This is a copy of the proposal for an MOU-based Protocol
Supporting 
Organization that was submitted to ICANN on April 23, 1999.</t>
</abstract>
</front>

<seriesInfo value="2690" name="RFC" />
</reference>


<reference target2="reference.RFC.2691.xml" anchor="RFC2691">
<front>
<title abbrev="MoU for an ICANN PSO">A Memorandum of Understanding for an ICANN Protocol Support Organization</title>
<author fullname="Scott Bradner" initials="S." surname="Bradner">
<organization>Harvard University</organization>

<address>
<postal>
<street>1350 Mass Avenue</street>
<street>Room 876</street>
<city>Cambridge</city>
<region>MA</region>
<code>02138</code>
<country>US</country>
</postal>

<phone>+1 617 495 3864</phone>
<email>sob@harvard.edu</email>
</address>
</author>

<date year="1999" month="September" />

<abstract>
<t>This is the text of the Memorandum of Understanding (MoU) that was
signed by ICANN, the IETF, the ITU-T, W3C and ETSI on July 14, 1999 in
Oslo.
This MoU creates the Protocol Support Organization (PSO) within the
Internet Corporation for Assigned Names and Numbers (ICANN).
This MoU was developed by representatives of the IETF, ITU, W3C, ETSI, and
ICANN with the help of Jorge Contreras of Hale and Dorr.</t>
</abstract>
</front>

<seriesInfo value="2691" name="RFC" />
</reference>


<reference target2="reference.RFC.2692.xml" anchor="RFC2692">
<front>
<title>SPKI Requirements</title>
<author fullname="Carl M. Ellison" initials="C." surname="Ellison">
<organization>Intel Corporation</organization>

<address>
<postal>
<street>2111 NE 25th Avenue</street>
<street>M/S JF3-212</street>
<city>Hillsboro</city>
<region>OR</region>
<code>97124-5961</code>
<country>US</country>
</postal>

<phone>+1 503 264 2900</phone>
<facsimile>+1 503 264 6225</facsimile>
<email>carl.m.ellison@intel.com</email>
<uri>http://www.pobox.com/~cme</uri>
</address>
</author>

<date year="1999" month="September" />

<abstract>
<t>The IETF Simple Public Key Infrastructure (SPKI) Working Group is
tasked with producing a certificate structure and operating procedure
to meet the needs of the Internet community for trust management in as
easy, simple and extensible a way as possible.</t>

<t>The SPKI Working Group first established a list of things one might
want to do with certificates (attached at the end of this document),
and then summarized that list of desires into requirements.
This document presents that summary of requirements.</t>
</abstract>
</front>

<seriesInfo value="2692" name="RFC" />
</reference>


<reference target2="reference.RFC.2693.xml" anchor="RFC2693">
<front>
<title>SPKI Certificate Theory</title>
<author fullname="Carl M. Ellison" initials="C." surname="Ellison">
<organization>Intel Corporation</organization>

<address>
<postal>
<street>2111 NE 25th Avenue</street>
<street>M/S JF3-212</street>
<city>Hillsboro</city>
<region>OR</region>
<code>97124-5961</code>
<country>US</country>
</postal>

<phone>+1 503 264 2900</phone>
<facsimile>+1 503 264 6225</facsimile>
<email>carl.m.ellison@intel.com</email>
<uri>http://www.pobox.com/~cme</uri>
</address>
</author>

<author fullname="Bill Frantz" initials="B." surname="Frantz">
<organization>Electric Communities</organization>

<address>
<postal>
<street>10101 De Anza Boulevard</street>
<city>Cupertino</city>
<region>CA</region>
<code>95014</code>
<country>US</country>
</postal>

<phone>+1 408 342 9576</phone>
<email>frantz@netcom.com</email>
</address>
</author>

<author fullname="Butler Lampson" initials="B." surname="Lampson">
<organization>Microsoft</organization>

<address>
<postal>
<street>180 Lake View Avenue</street>
<city>Cambridge</city>
<region>MA</region>
<code>02138</code>
<country>US</country>
</postal>

<phone>+1 617 547 9580</phone>
<email>blampson@microsoft.com</email>
</address>
</author>

<author fullname="Ron Rivest" initials="R." surname="Rivest">
<organization>Massachusetts Institute of Technology</organization>

<address>
<postal>
<street>Room 324</street>
<street>MIT Laboratory for Computer Science</street>
<street>545 Technology Square</street>
<city>Cambridge</city>
<region>MA</region>
<code>02139</code>
<country>US</country>
</postal>

<phone>+1 617 253 5880</phone>
<facsimile>+1 617 258 9738</facsimile>
<email>rivest@theory.lcs.mit.edu</email>
<uri>http://theory.lcs.mit.edu/~rivest</uri>
</address>
</author>

<author fullname="Brian Thomas" initials="B." surname="Thomas">
<organization>Southwestern Bell</organization>

<address>
<postal>
<street>One Bell Center</street>
<street>Room 34G3</street>
<city>Saint Louis</city>
<region>MO</region>
<code>63101</code>
<country>US</country>
</postal>

<phone>+1 314 235 3141</phone>
<facsimile>+1 314 235 0162</facsimile>
<email>bt0008@sbc.com</email>
</address>
</author>

<author fullname="Tatu Ylonen" initials="T." surname="Ylonen">
<organization>SSH Communications Security Ltd.</organization>

<address>
<postal>
<street>Tekniikantie 12</street>
<region>ESPOO</region>
<code>FIN-02150</code>
<country>FI</country>
</postal>

<email>ylo@ssh.fi</email>
</address>
</author>

<date year="1999" month="September" />

<abstract>
<t>The SPKI Working Group has developed a standard form for digital
certificates whose main purpose is authorization rather than
authentication.
These structures bind either names or explicit authorizations to keys
or other objects.
The binding to a key can be directly to an explicit key, or indirectly
through the hash of the key or a name for it.
The name and authorization structures can be used separately or together.
We use S-expressions as the standard format for these certificates and
define a canonical form for those S-expressions.
As part of this development, a mechanism for deriving authorization
decisions from a mixture of certificate types was developed and is
presented in this document.</t>

<t>This document gives the theory behind SPKI certificates and ACLs
without going into technical detail about those structures or their
uses.</t>
</abstract>
</front>

<seriesInfo value="2693" name="RFC" />
</reference>


<reference target2="reference.RFC.2694.xml" anchor="RFC2694">
<front>
<title abbrev="DNS extensions to NAT">DNS extensions to Network Address Translators (DNS_ALG)</title>
<author fullname="Pyda Srisuresh" initials="P." surname="Srisuresh">
<organization />

<address>
<postal>
<street>849 Erie Circle</street>
<city>Milpitas</city>
<region>CA</region>
<code>95035</code>
<country>US</country>
</postal>

<phone>+1 408 263 7527</phone>
<email>srisuresh@yahoo.com</email>
</address>
</author>

<author fullname="George Tsirtsis" initials="G." surname="Tsirtsis">
<organization>BT Laboratories</organization>

<address>
<postal>
<street>Internet Transport Group</street>
<street>B29 Room 129</street>
<street>Martlesham Heath</street>
<city>Ipswich</city>
<region>England</region>
<code>IP5 3RE</code>
<country>UK</country>
</postal>

<phone>+44 1473 640756</phone>
<facsimile>+44 1473 640709</facsimile>
<email>george@gideon.bt.co.uk</email>
</address>
</author>

<author fullname="Praveen Akkiraju" initials="P." surname="Akkiraju">
<organization>Cisco Systems</organization>

<address>
<postal>
<street>170 West Tasman Drive</street>
<city>San Jose</city>
<region>CA</region>
<code>95134</code>
<country>US</country>
</postal>

<phone>+1 408 526 5066</phone>
<email>spa@cisco.com</email>
</address>
</author>

<author fullname="Andy Heffernan" initials="A." surname="Heffernan">
<organization>Juniper Networks</organization>

<address>
<postal>
<street>385 Ravensdale Drive</street>
<city>Mountain View</city>
<region>CA</region>
<code>94043</code>
<country>US</country>
</postal>

<phone>+1 650 526 8037</phone>
<facsimile>+1 650 526 8001</facsimile>
<email>ahh@juniper.net</email>
</address>
</author>

<date year="1999" month="September" />

<abstract>
<t>Domain Name Service (DNS) provides name to address
mapping within a
routing class (ex: IP).
Network Address Translators (NATs) attempt to provide transparent
routing between hosts in disparate address realms of the same routing
class.
Typically, NATs exist at the border of a stub domain, hiding private
addresses from external addresses.
This document identifies the need for DNS extensions to NATs and
outlines how a DNS Application Level Gateway (DNS_ALG) can meet the
need.
DNS_ALG modifies payload transparently to alter address mapping of
hosts as DNS packets cross one address realm into another.
The document also illustrates the operation of DNS_ALG with specific
examples.</t>
</abstract>
</front>

<seriesInfo value="2694" name="RFC" />
</reference>


<reference target2="reference.RFC.2695.xml" anchor="RFC2695">
<front>
<title abbrev="Authentication Mechanisms for ONC RPC">Authentication Mechanisms for ONC RPC</title>
<author fullname="Alex Chiu" initials="A." surname="Chiu">
<organization>Sun Microsystems, Inc.</organization>

<address>
<postal>
<street>901 San Antonio Road</street>
<city>Palo Alto</city>
<region>CA</region>
<code>94303</code>
<country>US</country>
</postal>

<phone>+1 650 786 6465</phone>
<email>alex.chiu@Eng.sun.com</email>
</address>
</author>

<date year="1999" month="September" />

<abstract>
<t>This document describes two authentication mechanisms created by
Sun Microsystems that are commonly used in conjunction with the ONC
Remote Procedure Call (ONC RPC Version 2) protocol.</t>
</abstract>

<note title="WARNING">
<t>The DH authentication as defined in Section 2
in this document refers
to the authentication mechanism with flavor AUTH_DH currently
implemented in ONC RPC.
It uses the underlying Diffie-Hellman
algorithm for key exchange.
The DH authentication defined in this
document is flawed due to the selection of a small prime for the BASE
field (Section 2.5).
To avoid the flaw a new DH authentication
mechanism could be defined with a larger prime.
However, the new DH
authentication would not be interoperable with the existing DH
authentication.</t>

<t>As illustrated in, a large number of attacks
are possible on ONC
RPC system services that use non-secure authentication mechanisms.
Other secure authentication mechanisms need to be developed for ONC
RPC.
RFC 2203 describes the RPCSEC_GSS ONC RPC security flavor, a
secure authentication mechanism that enables RPC protocols to use
Generic Security Service Application Program Interface (RFC 2078) to
provide security services, integrity and privacy, that are
independent of the underlying security mechanisms.</t>
</note>
</front>

<seriesInfo value="2695" name="RFC" />
</reference>


<reference target2="reference.RFC.2696.xml" anchor="RFC2696">
<front>
<title abbrev="LDAP Control Ext. for Simple Paged Results">LDAP Control Extension for Simple Paged Results Manipulation</title>
<author fullname="Chris Weider" initials="C." surname="Weider">
<organization>Microsoft Corporation</organization>

<address>
<postal>
<street>1 Microsoft Way</street>
<city>Redmond</city>
<region>WA</region>
<code>98052</code>
<country>US</country>
</postal>

<phone>+1 425 882 8080</phone>
<email>cweider@microsoft.com</email>
</address>
</author>

<author fullname="Andy Herron" initials="A." surname="Herron">
<organization>Microsoft Corporation</organization>

<address>
<postal>
<street>1 Microsoft Way</street>
<city>Redmond</city>
<region>WA</region>
<code>98052</code>
<country>US</country>
</postal>

<phone>+1 425 882 8080</phone>
<email>andyhe@microsoft.com</email>
</address>
</author>

<author fullname="A. Anantha" initials="A." surname="Anantha">
<organization>Microsoft Corporation</organization>

<address>
<postal>
<street>1 Microsoft Way</street>
<city>Redmond</city>
<region>WA</region>
<code>98052</code>
<country>US</country>
</postal>

<phone>+1 425 882 8080</phone>
<email>anoopa@microsoft.com</email>
</address>
</author>

<author fullname="T. Howes" initials="T." surname="Howes">
<organization>Netscape Communications Corporation</organization>

<address>
<postal>
<street>501 East Middlefield Road</street>
<city>Mountain View</city>
<region>CA</region>
<code>94043</code>
<country>US</country>
</postal>

<phone>+1 415 937 2600</phone>
<email>howes@netscape.com</email>
</address>
</author>

<date year="1999" month="September" />

<abstract>
<t>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.</t>

<t>The key words "MUST", "SHOULD", and "MAY" used in this document are
to be interpreted as described in.</t>
</abstract>
</front>

<seriesInfo value="2696" name="RFC" />
</reference>


<reference target2="reference.RFC.2697.xml" anchor="RFC2697">
<front>
<title abbrev="A Single Rate Three Color Marker">A Single Rate Three Color Marker</title>
<author fullname="Juha Heinanen" initials="J." surname="Heinanen">
<organization>Telia Finland, Inc.</organization>

<address>
<postal>
<street>Myyrmaentie 2</street>
<city>Vantaa</city>
<code>01600</code>
<country>FI</country>
</postal>

<email>jh@telia.fi</email>
</address>
</author>

<author fullname="Roch Guerin" initials="R." surname="Guerin">
<organization>University of Pennsylvania</organization>

<address>
<postal>
<street>Department of Electrical Engineering</street>
<street>Room 367 GRW</street>
<street>200 South 33rd Street</street>
<city>Philadelphia</city>
<region>PA</region>
<code>19104</code>
<country>US</country>
</postal>

<email>guerin@ee.upenn.edu</email>
</address>
</author>

<date year="1999" month="September" />

<abstract>
<t>This document defines a Single Rate Three Color Marker (srTCM),
which can be used as component in a Diffserv traffic conditionerand.
The srTCM meters a traffic stream and marks its packets according to
three traffic parameters, Committed Information Rate (CIR), Committed
Burst Size (CBS), and Excess Burst Size (EBS), to be either green,
yellow, or red.
A packet is marked green if it doesn't exceed the CBS, yellow if it
does exceed the CBS, but not the EBS, and red otherwise.</t>
</abstract>
</front>

<seriesInfo value="2697" name="RFC" />
</reference>


<reference target2="reference.RFC.2698.xml" anchor="RFC2698">
<front>
<title abbrev="A Two Rate Three Color Marker">A Two Rate Three Color Marker</title>
<author fullname="Juha Heinanen" initials="J." surname="Heinanen">
<organization>Telia Finland, Inc.</organization>

<address>
<postal>
<street>Myyrmaentie 2</street>
<city>Vantaa</city>
<code>01600</code>
<country>FI</country>
</postal>

<email>jh@telia.fi</email>
</address>
</author>

<author fullname="Roch Guerin" initials="R." surname="Guerin">
<organization>University of Pennsylvania</organization>

<address>
<postal>
<street>Department of Electrical Engineering</street>
<street>Room 367 GRW</street>
<street>200 South 33rd Street</street>
<city>Philadelphia</city>
<region>PA</region>
<code>19104</code>
<country>US</country>
</postal>

<email>guerin@ee.upenn.edu</email>
</address>
</author>

<date year="1999" month="September" />

<abstract>
<t>This document defines a Two Rate Three Color Marker (trTCM), which can be used as a component in a Diffserv traffic conditioner [RFC2475, RFC2474]. 
The trTCM meters an IP packet stream and marks its packets based on
two rates, Peak Information Rate (PIR) and Committed Information Rate
(CIR), and their associated burst sizes to be either green, yellow, or
red. A packet is marked red if it exceeds the PIR.
Otherwise it is marked either yellow or green depending on whether it
exceeds or doesn't exceed the CIR.</t>
</abstract>
</front>

<seriesInfo value="2698" name="RFC" />
</reference>


<reference target2="reference.RFC.2699.xml" anchor="RFC2699">
<front>
<title abbrev="Summary of 2600-2699">Request for Comments Summary RFC Numbers 2600-2699</title>
<author fullname="Sandy Ginoza" initials="S." surname="Ginoza">
<organization>University of Southern California, Information Sciences Institute</organization>

<address>
<postal>
<street>4676 Admiralty Way</street>
<city>Marina del Rey</city>
<region>CA</region>
<code>90292</code>
<country>US</country>
</postal>

<phone>+1 310 822 1511</phone>
<email>ginoza@isi.edu</email>
</address>
</author>

<date year="2000" month="May" />

<abstract>
<t></t>
</abstract>
</front>

<seriesInfo value="2699" name="RFC" />
</reference>


<reference target2="reference.RFC.2700.xml" anchor="RFC2700">
<front>
<title>Internet Official Protocol Standards</title>
<author fullname="J. Reynolds" initials="J." surname="Reynolds">
<organization />
</author>

<author fullname="R. Braden" initials="R." surname="Braden">
<organization />
</author>

<date year="2000" month="August" />
</front>

<seriesInfo value="2700" name="RFC" />
<format octets="90213" type="TXT" target="ftp://ftp.isi.edu/in-notes/rfc2700.txt" />
</reference>


<reference target2="reference.RFC.2701.xml" anchor="RFC2701">
<front>
<title abbrev="MMP">Nortel Networks Multi-link Multi-node PPP Bundle Discovery Protocol</title>
<author fullname="Gary Scott Malkin" initials="G.S." surname="Malkin">
<organization>Nortel Networks</organization>

<address>
<postal>
<street>11 Elizabeth Drive</street>
<city>Chelmsford</city>
<region>MA</region>
<code>01824-4111</code>
<country>US</country>
</postal>

<phone>+1 978 250 3635</phone>
<email>gmalkin@nortelnetworks.com</email>
</address>
</author>

<date year="1999" month="September" />

<abstract>
<t>This document specifies a standard way for Multi-link PPP to operate across multiple nodes.  Both the mechanism by which the Bundle Head is discovered and the PPP fragment encapsulation are specified.</t>
</abstract>
</front>

<seriesInfo value="2701" name="RFC" />
</reference>


<reference target2="reference.RFC.2702.xml" anchor="RFC2702">
<front>
<title abbrev="MPLS Traffic Engineering">Requirements for Traffic Engineering Over MPLS</title>
<author fullname="Daniel O. Awduche" initials="D." surname="Awduche">
<organization>UUNET  (MCI Worldcom)</organization>

<address>
<postal>
<street>3060 Williams Drive</street>
<city>Fairfax</city>
<region>VA</region>
<code>22031</code>
<country>US</country>
</postal>

<phone>+1 703 208 5277</phone>
<email>awduche@uu.net</email>
</address>
</author>

<author fullname="Joe Malcolm" initials="J." surname="Malcolm">
<organization>UUNET  (MCI Worldcom)</organization>

<address>
<postal>
<street>3060 Williams Drive</street>
<city>Fairfax</city>
<region>VA</region>
<code>22031</code>
<country>US</country>
</postal>

<phone>+1 703 206 5895</phone>
<email>jmalcolm@uu.net</email>
</address>
</author>

<author fullname="Johnson Agogbua" initials="J." surname="Agogbua">
<organization>UUNET  (MCI Worldcom)</organization>

<address>
<postal>
<street>3060 Williams Drive</street>
<city>Fairfax</city>
<region>VA</region>
<code>22031</code>
<country>US</country>
</postal>

<phone>+1 703 206 5794</phone>
<email>ja@uu.net</email>
</address>
</author>

<author fullname="Mike O&apos;Dell" initials="M." surname="O&apos;Dell">
<organization>UUNET  (MCI Worldcom)</organization>

<address>
<postal>
<street>3060 Williams Drive</street>
<city>Fairfax</city>
<region>VA</region>
<code>22031</code>
<country>US</country>
</postal>

<phone>+1 703 206 5890</phone>
<email>mo@uu.net</email>
</address>
</author>

<author fullname="Jim McManus" initials="J." surname="McManus">
<organization>UUNET  (MCI Worldcom)</organization>

<address>
<postal>
<street>3060 Williams Drive</street>
<city>Fairfax</city>
<region>VA</region>
<code>22031</code>
<country>US</country>
</postal>

<phone>+1 703 206 5607</phone>
<email>jmcmanus@uu.net</email>
</address>
</author>

<date year="1999" month="September" />

<abstract>
<t>This document 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 to enhance traffic oriented performance characteristics.</t>
</abstract>
</front>

<seriesInfo value="2702" name="RFC" />
</reference>


<reference target2="reference.RFC.2703.xml" anchor="RFC2703">
<front>
<title abbrev="Protocol-independent Content Negotiation">Protocol-independent Content Negotiation Framework</title>
<author fullname="Graham Klyne" initials="G." surname="Klyne">
<organization>Content Technologies Ltd.</organization>

<address>
<postal>
<street>1220 Parkview</street>
<street>Arlington Business Park</street>
<city>Theale</city>
<region>Reading</region>
<code>RG7 4SA</code>
<country>UK</country>
</postal>

<phone>+44 118 9301300</phone>
<email>+44 118 9301301</email>
</address>
</author>

<date year="1999" month="September" />

<abstract>
<t>A number of Internet application protocols have a need to provide content negotiation for the resources with which they interact.  MIME media types,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.</t>

<t>This memo sets out terminology, an abstract framework and goals for protocol-independent content negotiation, and identifies some technical issues which may need to be addressed.</t>

<t>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 goals set out the desired properties of a content negotiation mechanism.</t>
</abstract>
</front>

<seriesInfo value="2703" name="RFC" />
</reference>


<reference target2="reference.RFC.2704.xml" anchor="RFC2704">
<front>
<title abbrev="The KeyNote Trust-Management System">The KeyNote Trust-Management System Version 2</title>
<author fullname="Matt Blaze" initials="M." surname="Blaze">
<organization>AT&amp;T Labs - Research</organization>

<address>
<postal>
<street>180 Park Avenue</street>
<city>Florham Park</city>
<region>NJ</region>
<code>07932-0971</code>
<country>US</country>
</postal>

<email>mab@research.att.com</email>
</address>
</author>

<author fullname="Joan Feigenbaum" initials="J." surname="Feigenbaum">
<organization>AT&amp;T Labs - Research</organization>

<address>
<postal>
<street>180 Park Avenue</street>
<city>Florham Park</city>
<region>NJ</region>
<code>07932-0971</code>
<country>US</country>
</postal>

<email>jf@research.att.com</email>
</address>
</author>

<author fullname="John Ioannidis" initials="J." surname="Ioannidis">
<organization>AT&amp;T Labs - Research</organization>

<address>
<postal>
<street>180 Park Avenue</street>
<city>Florham Park</city>
<region>NJ</region>
<code>07932-0971</code>
<country>US</country>
</postal>

<email>ji@research.att.com</email>
</address>
</author>

<author fullname="Angelos D. Keromytis" initials="A." surname="Keromytis">
<organization>University of Pennsylvania,  CIS Department,  Distributed Systems Lab</organization>

<address>
<postal>
<street>200 S. 33rd Street</street>
<city>Philadelphia</city>
<region>PA</region>
<code>19104-6389</code>
<country>US</country>
</postal>

<email>angelos@dsl.cis.upenn.edu</email>
</address>
</author>

<date year="1999" month="September" />

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

<seriesInfo value="2704" name="RFC" />
</reference>


<reference target2="reference.RFC.2705.xml" anchor="RFC2705">
<front>
<title abbrev="Media Gateway Control Protocol (MGCP)">Media Gateway Control Protocol (MGCP) Version 1.0</title>
<author fullname="Mauricio Arango" initials="M." surname="Arango">
<organization>RSL COM Latin America</organization>

<address>
<postal>
<street>6300 N.W. 5th Way</street>
<street>Suite 100</street>
<city>Fort Lauderdale</city>
<region>FL</region>
<code>33309</code>
<country>US</country>
</postal>

<phone>+1 954 492 0913</phone>
<email>marango@rslcom.com</email>
</address>
</author>

<author fullname="Andrew Dugan" initials="A." surname="Dugan">
<organization>Level3 Communications</organization>

<address>
<postal>
<street>1450 Infinite Drive</street>
<city>Louisville</city>
<region>CO</region>
<code>80027</code>
<country>US</country>
</postal>

<phone>+1 303 926 3123</phone>
<email>andrew.dugan@l3.com</email>
</address>
</author>

<author fullname="Isaac Elliott" initials="I." surname="Elliott">
<organization>Level3 Communications</organization>

<address>
<postal>
<street>1450 Infinite Drive</street>
<city>Louisville</city>
<region>CO</region>
<code>80027</code>
<country>US</country>
</postal>

<phone>+1 303 926 3123</phone>
<email>ike.elliott@l3.com</email>
</address>
</author>

<author fullname="Christian Huitema" initials="C." surname="Huitema">
<organization>Telcordia Technologies, MCC 1J236B</organization>

<address>
<postal>
<street>445 South Street</street>
<city>Morristown</city>
<region>NJ</region>
<code>07960</code>
<country>US</country>
</postal>

<phone>+1 973 829 4266</phone>
<email>huitema@research.telcordia.com</email>
</address>
</author>

<author fullname="Scott Pickett" initials="S." surname="Pickett">
<organization>Vertical Networks</organization>

<address>
<postal>
<street>1148 East Arques Ave</street>
<city>Sunnyvale</city>
<region>CA</region>
<code>94086</code>
<country>US</country>
</postal>

<phone>+1 408 523 9700 x200</phone>
<email>ScottP@vertical.com</email>
</address>
</author>

<date year="1999" month="October" />

<abstract>
<t>This document describes an application programming interface and a corresponding protocol (MGCP) for controlling Voice over IP (VoIP) Gateways from external call control elements. MGCP assumes a call control architecture where the call control "intelligence" is outside the gateways and handled by external call control elements.</t>
</abstract>
</front>

<seriesInfo value="2705" name="RFC" />
</reference>


<reference target2="reference.RFC.2706.xml" anchor="RFC2706">
<front>
<title abbrev="ECom Field Names">ECML v1: Field Names for E-Commerce</title>
<author fullname="Donald E. Eastlake, 3rd" initials="D." surname="Eastlake">
<organization>IBM, J1-N63</organization>

<address>
<postal>
<street>17 Skyline Drive</street>
<city>Hawthorne</city>
<region>NY</region>
<code>10532</code>
<country>US</country>
</postal>

<phone>+1 914 784 7913</phone>
<facsimile>+1 914 784 3833</facsimile>
<email>dee3@us.ibm.com</email>
</address>
</author>

<author fullname="Ted Goldstein" initials="T." surname="Goldstein">
<organization>Brodia Networks, Inc.</organization>

<address>
<postal>
<street>221 Main Street</street>
<street>Suite 1530</street>
<city>San Francisco</city>
<region>CA</region>
<code>94105</code>
<country>US</country>
</postal>

<phone>+1 415 495 3100 x222</phone>
<facsimile>+1 415 495 3177</facsimile>
<email>tgoldstein@brodia.com</email>
</address>
</author>

<date year="1999" month="October" />

<abstract>
<t>Customers are frequently required to enter substantial amounts of information at an Internet merchant site in order to complete a purchase or other transaction, especially the first time they go there. A standard set of information fields is defined as the first version of an Electronic Commerce Modeling Language (ECML) so that this task can be more easily automated, for example by wallet software that could fill in fields.  Even for the manual data entry case, customers will be less confused by varying merchant sites if a substantial number adopt these standard fields.</t>
</abstract>
</front>

<seriesInfo value="2706" name="RFC" />
</reference>


<reference target2="reference.RFC.2707.xml" anchor="RFC2707">
<front>
<title>Job Monitoring MIB - V1.0</title>
<author fullname="Ron Bergman" initials="R." surname="Bergman">
<organization>Dataproducts Corp.</organization>

<address>
<postal>
<street>1757 Tapo Canyon Road</street>
<city>Simi Valley</city>
<region>CA</region>
<code>93063-3394</code>
<country>US</country>
</postal>

<phone>+1 805 578 4421</phone>
<facsimile>+1 805 578 4001</facsimile>
<email>rbergman@dpc.com</email>
</address>
</author>

<author fullname="Tom Hastings" initials="T." surname="Hastings">
<organization>Xerox Corporation, ESAE-231</organization>

<address>
<postal>
<street>737 Hawaii St.</street>
<city>El Segundo</city>
<region>CA</region>
<code>90245</code>
<country>US</country>
</postal>

<phone>+1 310 333 6413</phone>
<facsimile>+1 310 333 5514</facsimile>
<email>hastings@cp10.es.xerox.com</email>
</address>
</author>

<author fullname="Scott A. Isaacson" initials="S." surname="Isaacson">
<organization>Novell, Inc.</organization>

<address>
<postal>
<street>122 E 1700 S</street>
<city>Provo</city>
<region>UT</region>
<code>84606</code>
<country>US</country>
</postal>

<phone>+1 801 861 7366</phone>
<facsimile>+1 801 861 4025</facsimile>
<email>scott_isaacson@novell.com</email>
</address>
</author>

<author fullname="Harry Lewis" initials="H." surname="Lewis">
<organization>IBM Corporation</organization>

<address>
<postal>
<street>6300 Diagonal Hwy</street>
<city>Boulder</city>
<region>CO</region>
<code>80301</code>
<country>US</country>
</postal>

<phone>+1 303 924 5337</phone>
<email>harryl@us.ibm.com</email>
</address>
</author>

<date year="1999" month="November" />

<abstract>
<t>This document provides a printer industry standard SNMP MIB formonitoring the status and progress of print jobsobtaining resource requirements before a job is processed,monitoring resource consumption while a job is being processed andcollecting resource accounting data after the completion of a job. This MIB is intended to be implementedin a printer orin a server that supports one or more printers.  Use of the object set is not limited to printing.  However, support for services other than printing is outside the scope of this Job Monitoring MIB.  Future extensions to this MIB may include, but are not limited to, fax machines and scanners.</t>
</abstract>
</front>

<seriesInfo value="2707" name="RFC" />
</reference>


<reference target2="reference.RFC.2708.xml" anchor="RFC2708">
<front>
<title abbrev="Job Submission Protocol Mapping">Job Submission Protocol Mapping Recommendations for the Job Monitoring MIB</title>
<author fullname="Ron Bergman" initials="R." surname="Bergman">
<organization>Dataproducts Corp.</organization>

<address>
<postal>
<street>1757 Tapo Canyon Road</street>
<city>Simi Valley</city>
<region>CA</region>
<code>93063-3394</code>
<country>US</country>
</postal>

<phone>+1 805 578 4421</phone>
<facsimile>+1 805 578 4001</facsimile>
<email>rbergman@dpc.com</email>
</address>
</author>

<author fullname="Tom Hastings" initials="T." surname="Hastings">
<organization>Xerox Corporation, ESAE-231</organization>

<address>
<postal>
<street>701 S. Aviation Blvd.</street>
<city>El Segundo</city>
<region>CA</region>
<code>90245</code>
<country>US</country>
</postal>

<phone>+1 310 333 6413</phone>
<facsimile>+1 310 333 5514</facsimile>
<email>hastings@cp10.es.xerox.com</email>
</address>
</author>

<author fullname="Scott A. Isaacson" initials="S." surname="Isaacson">
<organization>Novell, Inc.</organization>

<address>
<postal>
<street>122 E 1700 S</street>
<city>Provo</city>
<region>UT</region>
<code>84606</code>
<country>US</country>
</postal>

<phone>+1 801 861 7366</phone>
<facsimile>+1 801 861 4025</facsimile>
<email>scott_isaacson@novell.com</email>
</address>
</author>

<author fullname="Harry Lewis" initials="H." surname="Lewis">
<organization>IBM Corporation</organization>

<address>
<postal>
<street>6300 Diagonal Hwy</street>
<city>Boulder</city>
<region>CO</region>
<code>80301</code>
<country>US</country>
</postal>

<phone>+1 303 924 5337</phone>
<facsimile>+1 303 924-4662</facsimile>
<email>harryl@us.ibm.com</email>
</address>
</author>

<author fullname="Bob Pentecost" initials="B." surname="Pentecost">
<organization>Hewlett-Packard Corporation</organization>

<address>
<postal>
<street>11311 Chinden Boulevard</street>
<city>Boise</city>
<region>ID</region>
<code>83714</code>
<country>US</country>
</postal>

<phone>+1 208 396 3312</phone>
<facsimile>+1 208 396 4122</facsimile>
<email>bpenteco@boi.hp.com</email>
</address>
</author>

<date year="1999" month="November" />

<abstract>
<t>This document defines the recommended mapping for many currently popular Job submission protocols to objects and attributes in the Job Monitoring MIB.</t>
</abstract>
</front>

<seriesInfo value="2708" name="RFC" />
</reference>


<reference target2="reference.RFC.2709.xml" anchor="RFC2709">
<front>
<title abbrev="Security for NAT Domains">Security Model with Tunnel-mode IPsec for NAT Domains</title>
<author fullname="Pyda Srisuresh" initials="P." surname="Srisuresh">
<organization>Lucent technologies</organization>

<address>
<postal>
<street>4464 Willow Road</street>
<city>Pleasanton</city>
<region>CA</region>
<code>94588-8519</code>
<country>US</country>
</postal>

<phone>+1 925 737 2153</phone>
<facsimile>+1 925 737 2110</facsimile>
<email>srisuresh@lucent.com</email>
</address>
</author>

<date year="1999" month="October" />

<abstract>
<t>There are a variety of NAT flavors, as described in. Of the domains supported by NATs, only Realm-Specific IP clients are able to pursue end-to-end IPsec secure sessions. However, all flavors of NAT are capable of offering tunnel-mode IPsec security to private domain hosts peering with nodes in external realm. This document describes a security model by which tunnel-mode IPsec security can be architected on NAT devices. A section is devoted to describing how security policies may be transparently communicated to IKE (for automated KEY exchange) during Quick Mode. Also outlined are applications that can benefit from the Security Model described.</t>
</abstract>
</front>

<seriesInfo value="2709" name="RFC" />
</reference>


<reference target2="reference.RFC.2710.xml" anchor="RFC2710">
<front>
<title abbrev="Multicast Listener Discovery for IPv6">Multicast Listener Discovery (MLD) for IPv6</title>
<author fullname="Stephen E. Deering" initials="S." surname="Deering">
<organization>Cisco Systems, Inc.</organization>

<address>
<postal>
<street>170 West Tasman Drive</street>
<city>San Jose</city>
<region>CA</region>
<code>95134-1706</code>
<country>US</country>
</postal>

<phone>+1 408 527 8213</phone>
<email>deering@cisco.com</email>
</address>
</author>

<author fullname="William C. Fenner" initials="W." surname="Fenner">
<organization>AT &amp; T Research</organization>

<address>
<postal>
<street>75 Willow Road</street>
<city>Menlo Park</city>
<region>CA</region>
<code>94025</code>
<country>US</country>
</postal>

<phone>+1 650 867 6073</phone>
<email>fenner@research.att.com</email>
</address>
</author>

<author fullname="Brian Haberman" initials="B." surname="Haberman">
<organization>IBM Corporation</organization>

<address>
<postal>
<street>800 Park Office Drive</street>
<city>Research Triangle Park</city>
<region>NC</region>
<code>27709</code>
<country>US</country>
</postal>

<phone>+1 919 254 2673</phone>
<email>haberman@raleigh.ibm.com</email>
</address>
</author>

<date year="1999" month="October" />

<abstract>
<t>This document specifies the protocol used by an IPv6 router to discover the presence of multicast listeners (that is, nodes wishing to receive multicast packets) on its directly attached links, and to discover specifically which multicast addresses are of interest to those neighboring nodes.  This protocol is referred to as Multicast Listener Discovery or MLD.  MLD is derived from version 2 of IPv4's Internet Group Management Protocol, IGMPv2.  One important difference to note is that MLD uses ICMPv6 (IP Protocol 58)  essage types, rather than IGMP (IP Protocol 2) message types.</t>
</abstract>
</front>

<seriesInfo value="2710" name="RFC" />
</reference>


<reference target2="reference.RFC.2711.xml" anchor="RFC2711">
<front>
<title>IPv6 Router Alert Option</title>
<author fullname="Craig Partridge" initials="C." surname="Partridge">
<organization>BBN Technologies</organization>

<address>
<postal>
<street>10 Moulton Street</street>
<city>Cambridge</city>
<region>MA</region>
<code>02138</code>
<country>US</country>
</postal>

<phone>+1 617 873 3000</phone>
<email>craig@bbn.com</email>
</address>
</author>

<author fullname="Alden Jackson" initials="A." surname="Jackson">
<organization>BBN Technologies</organization>

<address>
<postal>
<street>10 Moulton Street</street>
<city>Cambridge</city>
<region>MA</region>
<code>02138</code>
<country>US</country>
</postal>

<phone>+1 617 873 3000</phone>
<email>awjacks@bbn.com</email>
</address>
</author>

<date year="1999" month="October" />

<abstract>
<t>This memo describes a new IPv6 Hop-by-Hop Option type that alerts transit routers to more closely examine the contents of an IP datagram.  This option is useful for situations where a datagram  addressed to a particular destination contains information that may require special processing by routers along the path.</t>
</abstract>
</front>

<seriesInfo value="2711" name="RFC" />
</reference>


<reference target2="reference.RFC.2712.xml" anchor="RFC2712">
<front>
<title abbrev="Addition of Kerberos Cipher Suites to TLS">Addition of Kerberos Cipher Suites to Transport Layer Security (TLS)</title>
<author fullname="Ari Medvinsky" initials="A." surname="Medvinsky">
<organization>Excite</organization>

<address>
<postal>
<street>555 Broadway</street>
<city>Redwood City</city>
<region>CA</region>
<code>94063</code>
<country>US</country>
</postal>

<phone>+1 650 569 2119</phone>
<email>amedvins@excitecorp.com</email>
</address>
</author>

<author fullname="Matthew Hur" initials="M." surname="Hur">
<organization>CyberSafe Corporation</organization>

<address>
<postal>
<street>1605 NW Sammamish Road</street>
<city>Issaquah</city>
<region>WA</region>
<code>98027-5378</code>
<country>US</country>
</postal>

<phone>+1 425 391 6000</phone>
<email>matt.hur@cybersafe.com</email>
</address>
</author>

<date year="1999" month="October" />

<abstract>
<t>This document proposes the addition of new cipher suites to the TLS protocolto support Kerberos-based authentication.  Kerberos credentials are used to achieve mutual authentication and to establish a master secret which is subsequently used to secure client-server communication.</t>
</abstract>
</front>

<seriesInfo value="2712" name="RFC" />
</reference>


<reference target2="reference.RFC.2713.xml" anchor="RFC2713">
<front>
<title abbrev="Schema for Java Objects">Schema for Representing Java(tm) Objects in an LDAP Directory</title>
<author fullname="Vincent Ryan" initials="V." surname="Ryan">
<organization>Sun Microsystems, Inc.</organization>

<address>
<postal>
<street>901 San Antonio Road</street>
<city>Palo Alto</city>
<region>CA</region>
<code>94303</code>
<country>US</country>
</postal>

<phone>+353 1 8199151</phone>
<email>vincent.ryan@ireland.sun.com</email>
</address>
</author>

<author fullname="Rosanna Lee" initials="R." surname="Lee">
<organization>Sun Microsystems, Inc.</organization>

<address>
<postal>
<street>901 San Antonio Road</street>
<city>Palo Alto</city>
<region>CA</region>
<code>94303</code>
<country>US</country>
</postal>

<phone>+1 408 863 3221</phone>
<email>rosanna.lee@eng.sun.com</email>
</address>
</author>

<author fullname="Scott Seligman" initials="S." surname="Seligman">
<organization>Sun Microsystems, Inc.</organization>

<address>
<postal>
<street>901 San Antonio Road</street>
<city>Palo Alto</city>
<region>CA</region>
<code>94303</code>
<country>US</country>
</postal>

<phone>+1 408 863 3222</phone>
<email>scott.seligman@eng.sun.com</email>
</address>
</author>

<date year="1999" month="October" />

<abstract>
<t>This document defines the schema for representing Java(tm) objects in an LDAP directory.  It defines schema elements to represent a Java serialized object, a Java marshalled object, a  Java remote object, and a JNDI reference.</t>
</abstract>
</front>

<seriesInfo value="2713" name="RFC" />
</reference>


<reference target2="reference.RFC.2714.xml" anchor="RFC2714">
<front>
<title abbrev="Schema for CORBA Object References">Schema for Representing CORBA Object References in an LDAP Directory</title>
<author fullname="Vincent Ryan" initials="V." surname="Ryan">
<organization>Sun Microsystems, Inc.</organization>

<address>
<postal>
<street>901 San Antonio Road</street>
<city>Palo Alto</city>
<region>CA</region>
<code>94303</code>
<country>US</country>
</postal>

<phone>+353 1 8199151</phone>
<email>vincent.ryan@ireland.sun.com</email>
</address>
</author>

<author fullname="Rosanna Lee" initials="R." surname="Lee">
<organization>Sun Microsystems, Inc.</organization>

<address>
<postal>
<street>901 San Antonio Road</street>
<city>Palo Alto</city>
<region>CA</region>
<code>94303</code>
<country>US</country>
</postal>

<phone>+1 408 863 3221</phone>
<email>rosanna.lee@eng.sun.com</email>
</address>
</author>

<author fullname="Scott Seligman" initials="S." surname="Seligman">
<organization>Sun Microsystems, Inc.</organization>

<address>
<postal>
<street>901 San Antonio Road</street>
<city>Palo Alto</city>
<region>CA</region>
<code>94303</code>
<country>US</country>
</postal>

<phone>+1 408 863 3222</phone>
<email>scott.seligman@eng.sun.com</email>
</address>
</author>

<date year="1999" month="October" />

<abstract>
<t>CORBA [CORBA] is the Common Object Request Broker Architecture defined by the Object Management Group. This document defines the schema for representing CORBA object references in an LDAP directory [LDAPv3].</t>
</abstract>
</front>

<seriesInfo value="2714" name="RFC" />
</reference>


<reference target2="reference.RFC.2715.xml" anchor="RFC2715">
<front>
<title abbrev="Interop Rules">Interoperability Rules for Multicast Routing Protocols</title>
<author fullname="Dave Thaler" initials="D." surname="Thaler">
<organization>Microsoft</organization>

<address>
<postal>
<street>One Microsoft Way</street>
<city>Redmond</city>
<region>WA</region>
<code>98052</code>
<country>US</country>
</postal>

<phone>+1 425 703 8835</phone>
<email>dthaler@microsoft.com</email>
</address>
</author>

<date year="1999" month="October" />

<abstract>
<t>The rules described in this document will allow efficient interoperation among multiple independent multicast routing domains. Specific instantiations of these rules are given for the DVMRP, MOSPF, PIM-DM, PIM-SM, and CBT multicast routing protocols, as well as for IGMP-only links.  Future versions of these protocols, and any other multicast routing protocols, may describe their interoperability procedure by stating how the rules described herein apply to them.</t>
</abstract>
</front>

<seriesInfo value="2715" name="RFC" />
</reference>


<reference target2="reference.RFC.2716.xml" anchor="RFC2716">
<front>
<title>PPP EAP TLS Authentication Protocol</title>
<author fullname="Bernard Aboba" initials="B." surname="Aboba">
<organization>Microsoft Corporation</organization>

<address>
<postal>
<street>One Microsoft Way</street>
<city>Redmond</city>
<region>WA</region>
<code>98052</code>
<country>US</country>
</postal>

<phone>+1 425 936 6605</phone>
<email>bernarda@microsoft.com</email>
</address>
</author>

<author fullname="Dan Simon" initials="D." surname="Simon">
<organization>Microsoft Corporation</organization>

<address>
<postal>
<street>One Microsoft Way</street>
<city>Redmond</city>
<region>WA</region>
<code>98052</code>
<country>US</country>
</postal>

<phone>+1 425 936 6711</phone>
<email>dansimon@microsoft.com</email>
</address>
</author>

<date year="1999" month="October" />

<abstract>
<t>The Point-to-Point Protocol (PPP) 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), used to negotiate data encryption over PPP links, and a Compression Control Protocol (CCP), used to negotiate compression methods.  The Extensible Authentication Protocol (EAP) is a PPP extension that provides support for additional authentication methods within PPP.</t>

<t>Transport Level Security (TLS) provides for mutual authentication, integrity-protected ciphersuite negotiation and key exchange between two endpoints.  This document describes how EAP-TLS, which includes support for fragmentation and reassembly, provides for these TLS mechanisms within EAP.</t>
</abstract>
</front>

<seriesInfo value="2716" name="RFC" />
</reference>


<reference target2="reference.RFC.2717.xml" anchor="RFC2717">
<front>
<title>Registration Procedures for URL Scheme Names</title>
<author fullname="Rich Petke" initials="R." surname="Petke">
<organization>UUNET Technologies</organization>

<address>
<postal>
<street>5000 Britton Road</street>
<street>P. O. Box 5000</street>
<city>Hilliard</city>
<region>OH</region>
<code>43026-5000</code>
<country>US</country>
</postal>

<phone>+1 614 723 4157</phone>
<facsimile>+1 614 723 8407</facsimile>
<email>rpetke@wcom.net</email>
</address>
</author>

<author fullname="Ian King" initials="I." surname="King">
<organization>Microsoft Corporation</organization>

<address>
<postal>
<street>One Microsoft Way</street>
<city>Redmond</city>
<region>WA</region>
<code>98052-6399</code>
<country>US</country>
</postal>

<phone>+1 425 703 2293</phone>
<facsimile>+1 425 936 7329</facsimile>
<email>iking@microsoft.com</email>
</address>
</author>

<date year="1999" month="November" />

<abstract>
<t>This document defines the process by which new URL scheme names are registered.</t>
</abstract>
</front>

<seriesInfo value="35" name="BCP" />
<seriesInfo value="2717" name="RFC" />
</reference>


<reference target2="reference.RFC.2718.xml" anchor="RFC2718">
<front>
<title>Guidelines for new URL Schemes</title>
<author fullname="Larry Masinter" initials="L." surname="Masinter">
<organization>Xerox Corporation, Palo Alto Research Center</organization>

<address>
<postal>
<street>3333 Coyote Hill Road</street>
<city>Palo Alto</city>
<region>CA</region>
<code>94304</code>
<country>US</country>
</postal>

<email>masinter@parc.xerox.com</email>
</address>
</author>

<author fullname="Harald Tveit Alvestrand" initials="H." surname="Alvestrand">
<organization>Maxware</organization>

<address>
<postal>
<street>N-7005 Trondheim</street>
<city>Pirsenteret</city>
<region />
<code />
<country>NO</country>
</postal>

<phone>+47 73 545700</phone>
<email>harald.alvestrand@maxware.no</email>
</address>
</author>

<author fullname="Dan Zigmond" initials="D." surname="Zigmond">
<organization>WebTV Networks, Inc.</organization>

<address>
<postal>
<street>305 Lytton Avenue</street>
<city>Palo Alto</city>
<region>CA</region>
<code>94301</code>
<country>US</country>
</postal>

<phone>+1 650 614 6071</phone>
<email>djz@corp.webtv.net</email>
</address>
</author>

<author fullname="Rich Petke" initials="R." surname="Petke">
<organization>UUNET Technologies</organization>

<address>
<postal>
<street>5000 Britton Road</street>
<street>P. O. Box 5000</street>
<city>Hilliard</city>
<region>OH</region>
<code>43026-5000</code>
<country>US</country>
</postal>

<phone>+1 614 723 4157</phone>
<facsimile>+1 614 723 8407</facsimile>
<email>rpetke@wcom.net</email>
</address>
</author>

<date year="1999" month="November" />

<abstract>
<t>A Uniform Resource Locator (URL) is a compact string representation of the location for a resource that is available via the Internet. This document provides guidelines for the definition of new URL schemes.</t>
</abstract>
</front>

<seriesInfo value="2718" name="RFC" />
</reference>


<reference target2="reference.RFC.2719.xml" anchor="RFC2719">
<front>
<title>Framework Architecture for Signaling Transport</title>
<author fullname="Lyndon Ong" initials="L." surname="Ong">
<organization>Nortel Networks</organization>

<address>
<postal>
<street>4401 Great America Parkway</street>
<city>Santa Clara</city>
<region>CA</region>
<code>95054</code>
<country>US</country>
</postal>

<email>long@nortelnetworks.com</email>
</address>
</author>

<author fullname="Ian Rytina" initials="I." surname="Rytina">
<organization>Ericsson Australia</organization>

<address>
<postal>
<street>37/360 Elizabeth Street</street>
<city>Melbourne</city>
<region>Victoria</region>
<code>3000</code>
<country>AU</country>
</postal>

<email>ian.rytina@ericsson.com</email>
</address>
</author>

<author fullname="Miguel-Angel Garcia" initials="M." surname="Garcia">
<organization>Ericsson Espana</organization>

<address>
<postal>
<street>Retama 7</street>
<city>Madrid</city>
<region />
<code>28005</code>
<country>ES</country>
</postal>

<email>Miguel.A.Garcia@ericsson.com</email>
</address>
</author>

<author fullname="HannsJuergen Schwarzbauer" initials="H." surname="Schwarzbauer">
<organization>SIEMENS AG</organization>

<address>
<postal>
<street>Hofmannstr. 51</street>
<city>Munich</city>
<region />
<code>81359</code>
<country>DE</country>
</postal>

<email>HannsJuergen.Schwarzbauer@icn.siemens.de</email>
</address>
</author>

<author fullname="Lode Coene" initials="L." surname="Coene">
<organization>Siemens Atea</organization>

<address>
<postal>
<street>Atealaan 34</street>
<city>Herentals</city>
<region />
<code />
<country>BE</country>
</postal>

<email>lode.coene@siemens.atea.be</email>
</address>
</author>

<author fullname="Haui-an Paul Lin" initials="H." surname="Lin">
<organization>Telcordia Technologies</organization>

<address>
<postal>
<street />
<city>Piscataway</city>
<region>NJ</region>
<code>08854-4157</code>
<country>US</country>
</postal>

<email>hlin@research.telcordia.com</email>
</address>
</author>

<author fullname="Imre Juhasz" initials="I." surname="Juhasz">
<organization>Telia</organization>

<address>
<postal>
<street />
<city />
<region />
<code />
<country>SE</country>
</postal>

<email>imre.i.juhasz@telia.se</email>
</address>
</author>

<author fullname="Matt Holdrege" initials="M." surname="Holdrege">
<organization>Lucent Technologies</organization>

<address>
<postal>
<street>1701 Harbor Bay Parkway</street>
<city>Alameda</city>
<region>CA</region>
<code>94502</code>
<country>US</country>
</postal>

<email>holdrege@lucent.com</email>
</address>
</author>

<author fullname="Chip Sharp" initials="C." surname="Sharp">
<organization>Cisco Systems</organization>

<address>
<postal>
<street>7025 Kit Creek Road</street>
<city>Research Triangle Park</city>
<region>NC</region>
<code>27709</code>
<country>US</country>
</postal>

<email>chsharp@cisco.com</email>
</address>
</author>

<date year="1999" month="October" />

<abstract>
<t>This document defines an architecture framework and functional requirements for transport of signaling information over IP.  The framework describes relationships between functional and physical entities exchanging signaling information, such as Signaling Gateways and Media Gateway Controllers.  It identifies interfaces where signaling transport may be used and the functional and performance requirements that apply from existing Switched Circuit Network (SCN) signaling protocols.</t>
</abstract>
</front>

<seriesInfo value="2719" name="RFC" />
</reference>


<reference target2="reference.RFC.2720.xml" anchor="RFC2720">
<front>
<title>Traffic Flow Measurement: Meter MIB</title>
<author fullname="Nevil Brownlee" initials="N." surname="Brownlee">
<organization>The University of Auckland,  Information Technology Systems &amp; Services</organization>

<address>
<postal>
<street>Private Bag 92-019</street>
<city>Auckland</city>
<region />
<code />
<country>NZ</country>
</postal>

<phone>+64 9 3737599x8941</phone>
<email>n.brownlee@auckland.ac.nz</email>
</address>
</author>

<date year="1999" month="October" />

<abstract>
<t>The RTFM Traffic Measurement Architecture provides a general framework for describing and measuring network traffic flows.  Flows are defined in terms of their Address attribute values and measured by a 'Traffic Meter'.</t>

<t>This document defines a Management Information Base (MIB) for use in controlling an RTFM Traffic Meter, in particular for specifying the flows to be measured.  It also provides an efficient mechanism for retrieving flow data from the meter using SNMP. Security issues concerning the operation of traffic meters are summarised.</t>
</abstract>
</front>

<seriesInfo value="2720" name="RFC" />
</reference>


<reference target2="reference.RFC.2721.xml" anchor="RFC2721">
<front>
<title>RTFM: Applicability Statement</title>
<author fullname="Nevil Brownlee" initials="N." surname="Brownlee">
<organization>The University of Auckland,  Information Technology Systems &amp; Services</organization>

<address>
<postal>
<street>Private Bag 92-019</street>
<city>Auckland</city>
<region />
<code />
<country>NZ</country>
</postal>

<phone>+64 9 3737599x8941</phone>
<email>n.brownlee@auckland.ac.nz</email>
</address>
</author>

<date year="1999" month="October" />

<abstract>
<t>This document provides an overview covering all aspects of Realtime Traffic Flow Measurement, including its area of applicability and its limitations.</t>
</abstract>
</front>

<seriesInfo value="2721" name="RFC" />
</reference>


<reference target2="reference.RFC.2722.xml" anchor="RFC2722">
<front>
<title>Traffic Flow Measurement: Architecture</title>
<author fullname="Nevil Brownlee" initials="N." surname="Brownlee">
<organization>The University of Auckland,  Information Technology Systems &amp; Services</organization>

<address>
<postal>
<street>Private Bag 92-019</street>
<city>Auckland</city>
<region />
<code />
<country>NZ</country>
</postal>

<phone>+64 9 3737599x8941</phone>
<email>n.brownlee@auckland.ac.nz</email>
</address>
</author>

<author fullname="Cyndi Mills" initials="C." surname="Mills">
<organization>GTE Laboratories, Inc</organization>

<address>
<postal>
<street>40 Sylvan Rd.</street>
<city>Waltham</city>
<region>MA</region>
<code>02451</code>
<country>US</country>
</postal>

<phone>+1 781 466 4278</phone>
<email>cmills@gte.com</email>
</address>
</author>

<author fullname="Greg Ruth" initials="G." surname="Ruth">
<organization>GTE Internetworking</organization>

<address>
<postal>
<street>3 Van de Graaff Drive</street>
<street>P.O. Box 3073</street>
<city>Burlington</city>
<region>MA</region>
<code>01803</code>
<country>US</country>
</postal>

<phone>+1 781 262 4831</phone>
<email>gruth@bbn.com</email>
</address>
</author>

<date year="1999" month="October" />

<abstract>
<t>This document provides a general framework for describing network traffic flows, presents an architecture for traffic flow measurement and reporting, discusses how this relates to an overall network traffic flow architecture and indicates how it can be used within the Internet.</t>
</abstract>
</front>

<seriesInfo value="2722" name="RFC" />
</reference>


<reference target2="reference.RFC.2723.xml" anchor="RFC2723">
<front>
<title abbrev="SRL: A Traffic Flow Language">SRL: A Language for Describing Traffic Flows and Specifying Actions for Flow Groups</title>
<author fullname="Nevil Brownlee" initials="N." surname="Brownlee">
<organization>The University of Auckland,  Information Technology Systems &amp; Services</organization>

<address>
<postal>
<street>Private Bag 92-019</street>
<city>Auckland</city>
<region />
<code />
<country>NZ</country>
</postal>

<phone>+64 9 3737599x8941</phone>
<email>n.brownlee@auckland.ac.nz</email>
</address>
</author>

<date year="1999" month="October" />

<abstract>
<t>This document describes a language for specifying rulesets, i.e. configuration files which may be loaded into a traffic flow meter so as to specify which traffic flows are measured by the meter, and the information it will store for each flow.</t>
</abstract>
</front>

<seriesInfo value="2723" name="RFC" />
</reference>


<reference target2="reference.RFC.2724.xml" anchor="RFC2724">
<front>
<title abbrev="RTFM: New Attributes">RTFM: New Attributes for Traffic Flow Measurement</title>
<author fullname="Sig Handelman" initials="S." surname="Handelman">
<organization>IBM Research Division, T.J. Watson Research Center</organization>

<address>
<postal>
<street>P.O. Box 704</street>
<city>Yorktown Heights</city>
<region>NY</region>
<code>10598</code>
<country>US</country>
</postal>

<phone>+1 914 784 7626</phone>
<email>swhandel@us.ibm.com</email>
</address>
</author>

<author fullname="Stephen Stibler" initials="S." surname="Stibler">
<organization>IBM Research Division, T.J. Watson Research Center</organization>

<address>
<postal>
<street>P.O. Box 704</street>
<city>Yorktown Heights</city>
<region>NY</region>
<code>10598</code>
<country>US</country>
</postal>

<phone>+1 914 784 7191</phone>
<email>stibler@us.ibm.com</email>
</address>
</author>

<author fullname="Nevil Brownlee" initials="N." surname="Brownlee">
<organization>The University of Auckland,  Information Technology Systems &amp; Services</organization>

<address>
<postal>
<street>Private Bag 92-019</street>
<city>Auckland</city>
<region />
<code />
<country>NZ</country>
</postal>

<phone>+64 9 3737599x8941</phone>
<email>n.brownlee@auckland.ac.nz</email>
</address>
</author>

<author fullname="Greg Ruth" initials="G." surname="Ruth">
<organization>GTE Internetworking</organization>

<address>
<postal>
<street>3 Van de Graaff Drive</street>
<street>P.O. Box 3073</street>
<city>Burlington</city>
<region>MA</region>
<code>01803</code>
<country>US</country>
</postal>

<phone>+1 781 262 4831</phone>
<email>gruth@bbn.com</email>
</address>
</author>

<date year="1999" month="October" />

<abstract>
<t>The RTFM Traffic Measurement Architecture provides a general framework for describing and measuring network traffic flows.  Flows are defined in terms of their Address Attribute values and measured by a 'Traffic Meter'.  This document discusses RTFM flows and the attributes which they can have, so as to provide a logical framework for extending the architecture by adding new attributes.</t>

<t>Extensions described include Address Attributes such as DSCodePoint, SourceASN and DestASN, and Group Attributes such as short-term bit rates and turnaround times.  Quality of Service parameters for Integrated Services are also discussed.</t>
</abstract>
</front>

<seriesInfo value="2724" name="RFC" />
</reference>


<reference target2="reference.RFC.2725.xml" anchor="RFC2725">
<front>
<title>Routing Policy System Security</title>
<author fullname="Curtis Villamizar" initials="C." surname="Villamizar">
<organization>Avici Systems</organization>

<address>
<email>curtis@avici.com</email>
</address>
</author>

<author fullname="Cengiz Alaettinoglu" initials="C." surname="Alaettinoglu">
<organization>ISI</organization>

<address>
<email>cengiz@ISI.EDU</email>
</address>
</author>

<author fullname="David M. Meyer" initials="D." surname="Meyer">
<organization>Cisco</organization>

<address>
<email>dmm@cisco.com</email>
</address>
</author>

<author fullname="Sandy Murphy" initials="S." surname="Murphy">
<organization>Trusted Information Systems</organization>

<address>
<email>sandy@tis.com</email>
</address>
</author>

<date year="1999" month="December" />

<abstract>
<t>The RIPE database specifications and RPSL language define languages used as the basis for representing information in a routing policy system.  A repository for routing policy system information is known as a routing registry.  A routing registry provides a means of exchanging information needed to address many issues of importance to the operation of the Internet.  The implementation and deployment of a routing policy system must maintain some degree of integrity to be of any operational use.  This document addresses the need to assure integrity of the data by providing an authentication and 
authorization model.</t>
</abstract>
</front>

<seriesInfo value="2725" name="RFC" />
</reference>


<reference target2="reference.RFC.2726.xml" anchor="RFC2726">
<front>
<title>PGP Authentication for RIPE Database Updates</title>
<author fullname="Janos Zsako" initials="J." surname="Zsako">
<organization>BankNet</organization>

<address>
<postal>
<street>1121 Budapest</street>
<city>Konkoly-Thege ut</city>
<region>*</region>
<code>29-33</code>
<country>HU</country>
</postal>

<phone>+36 1 3959028</phone>
<facsimile>+36 1 3959032</facsimile>
<email>zsako@banknet.net</email>
</address>
</author>

<date year="1999" month="December" />

<abstract>
<t>This document presents the proposal for a stronger authentication method of the updates of the RIPE database based on digital signatures. The proposal tries to be as general as possible as far as digital signing methods are concerned, however, it concentrates mainly on PGP, as the first method to be implemented.  The proposal is the result of the discussions within the RIPE DBSEC Task Force.</t>
</abstract>
</front>

<seriesInfo value="2726" name="RFC" />
</reference>


<reference target2="reference.RFC.2727.xml" anchor="RFC2727">
<front>
<title abbrev="IAB and IESG Selection">IAB and IESG Selection, Confirmation, and Recall Process: Operation of the Nominating and Recall Committees</title>
<author fullname="James M. Galvin" initials="J." surname="Galvin">
<organization>eList eXpress LLC</organization>

<address>
<postal>
<street>607 Trixsam Road</street>
<city>Sykesville</city>
<region>MD</region>
<code>21784</code>
<country>US</country>
</postal>

<email>galvin@elistx.com</email>
</address>
</author>

<date year="2000" month="February" />

<abstract>
<t>The process by which the members of the IAB and IESG are selected, confirmed, and recalled is specified.  This document is a self-consistent, organized compilation of the process as it was known at the time of publication.</t>
</abstract>
</front>

<seriesInfo value="10" name="BCP" />
<seriesInfo value="2727" name="RFC" />
</reference>


<reference target2="reference.RFC.2728.xml" anchor="RFC2728">
<front>
<title abbrev="IPVBI">The Transmission of IP Over the Vertical Blanking Interval of a Television Signal</title>
<author fullname="Ruston Panabaker" initials="R." surname="Panabaker">
<organization>Microsoft</organization>

<address>
<postal>
<street>One Microsoft Way</street>
<city>Redmond</city>
<region>WA</region>
<code>98052</code>
<country>US</country>
</postal>

<email>rustonp@microsoft.com</email>
</address>
</author>

<author fullname="Simon Wegerif" initials="S." surname="Wegerif">
<organization>Philips Semiconductors</organization>

<address>
<postal>
<street>811 E. Arques Avenue, M/S 52</street>
<street>P.O. Box 3409</street>
<city>Sunnyvale</city>
<region>CA</region>
<code>94088-3409</code>
<country>US</country>
</postal>

<email>Simon.Wegerif@sv.sc.philips.com</email>
</address>
</author>

<author fullname="Dan Zigmond" initials="D." surname="Zigmond">
<organization>WebTV Networks</organization>

<address>
<postal>
<street>One Microsoft Way</street>
<city>Redmond</city>
<region>WA</region>
<code>98052</code>
<country>US</country>
</postal>

<email>djz@corp.webtv.net</email>
</address>
</author>

<date year="1999" month="November" />

<abstract>
<t>This document describes a method for broadcasting IP data in a unidirectional manner using the vertical blanking interval of television signals.  It includes a description for compressing IP headers on unidirectional networks, a framing protocol identical to SLIP, a forward error correction scheme, and the NABTS byte structures.</t>
</abstract>
</front>

<seriesInfo value="2728" name="RFC" />
</reference>


<reference target2="reference.RFC.2729.xml" anchor="RFC2729">
<front>
<title abbrev="Taxonomy of Communication Requirements">Taxonomy of Communication Requirements for Large-scale Multicast Applications</title>
<author fullname="Peter Bagnall" initials="P." surname="Bagnall">
<organization>BT Labs</organization>

<address>
<postal>
<street>B54/77 Martlesham Heath</street>
<city>Ipswich</city>
<region>England</region>
<code>IP5 3RE</code>
<country>UK</country>
</postal>

<email>pete@surfaceeffect.com</email>
</address>
</author>

<author fullname="Bob Briscoe" initials="B." surname="Briscoe">
<organization>BT Labs</organization>

<address>
<postal>
<street>B54/77 Martlesham Heath</street>
<city>Ipswich</city>
<region>England</region>
<code>IP5 3RE</code>
<country>UK</country>
</postal>

<phone>+44 1473 645196</phone>
<facsimile>+44 1473 640929</facsimile>
<email>bob.briscoe@bt.com</email>
</address>
</author>

<author fullname="Alan Poppitt" initials="A." surname="Poppitt">
<organization>BT Labs</organization>

<address>
<postal>
<street>B54/77 Martlesham Heath</street>
<city>Ipswich</city>
<region>England</region>
<code>IP5 3RE</code>
<country>UK</country>
</postal>

<phone>+44 1473 640889</phone>
<facsimile>+44 1473 640929</facsimile>
<email>apoppitt@jungle.bt.co.uk</email>
</address>
</author>

<date year="1999" month="December" />

<abstract>
<t>The intention of this memo is to define a classification system for the communication requirements of any large-scale multicast application (LSMA). It is very unlikely one protocol can achieve a compromise between the diverse requirements of all the parties involved in any LSMA. It is therefore necessary to understand the worst-case scenarios in order to minimize the range of protocols needed. Dynamic protocol adaptation is likely to be necessary which will require logic to map particular combinations of requirements to particular mechanisms.  Standardizing the way that applications define their requirements is a necessary step towards this. Classification is a first step towards standardization.</t>
</abstract>
</front>

<seriesInfo value="2729" name="RFC" />
</reference>


<reference target2="reference.RFC.2730.xml" anchor="RFC2730">
<front>
<title abbrev="MADCAP">Multicast Address Dynamic Client Allocation Protocol (MADCAP)</title>
<author fullname="Stephen R. Hanna" initials="S.R." surname="Hanna">
<organization>Sun Microsystems, Inc.</organization>

<address>
<postal>
<street>One Network Drive</street>
<city>Burlington</city>
<region>MA</region>
<code>01803</code>
<country>US</country>
</postal>

<phone>+1 781 442 0166</phone>
<email>steve.hanna@sun.com</email>
</address>
</author>

<author fullname="Baiju V. Patel" initials="B.V." surname="Patel">
<organization>Intel Corp.</organization>

<address>
<postal>
<street>5200 NE Elam Young Parkway</street>
<street>Mail Stop: AG2-201</street>
<city>Hillsboro</city>
<region>OR</region>
<code>97124</code>
<country>US</country>
</postal>

<phone>+1 503 696 8192</phone>
<email>baiju.v.patel@intel.com</email>
</address>
</author>

<author fullname="Munil Shah" initials="M." surname="Shah">
<organization>Microsoft Corporation</organization>

<address>
<postal>
<street>One Microsoft Way</street>
<city>Redmond</city>
<region>WA</region>
<code>98052</code>
<country>US</country>
</postal>

<phone>+1 425 703 3924</phone>
<email>munils@microsoft.com</email>
</address>
</author>

<date year="1999" month="December" />

<abstract>
<t>This document defines a protocol, Multicast Address Dynamic Client  Allocation Protocol (MADCAP), that allows hosts to request multicast addresses from multicast address allocation servers.</t>
</abstract>
</front>

<seriesInfo value="2730" name="RFC" />
</reference>


<reference target2="reference.RFC.2731.xml" anchor="RFC2731">
<front>
<title>Encoding Dublin Core Metadata in HTML</title>
<author fullname="John A. Kunze" initials="J." surname="Kunze">
<organization abbrev="UC San Francisco">Center for Knowledge Management, University of California</organization>

<address>
<postal>
<street>530 Parnassus Ave, Box 0840</street>
<city>San Francisco</city>
<region>CA</region>
<code>94143-0840</code>
<country>USA</country>
</postal>

<facsimile>+1 415-476-4653</facsimile>
<email>jak@ckm.ucsf.edu</email>
</address>
</author>

<date year="1999" month="December"></date>

<abstract>
<t>
   The Dublin Core  is a small set of metadata elements for
   describing information resources.  This document explains how these
   elements are expressed using the META and LINK tags of HTML
   .  A sequence of metadata elements embedded in an HTML file
   is taken to be a description of that file.  Examples illustrate
   conventions allowing interoperation with current software that
   indexes, displays, and manipulates metadata, such as ,
   , , , , etc., and the Perl
    scripts in the appendix.
  </t>
</abstract>
</front>

<seriesInfo value="2731" name="RFC" />
<format octets="42450" type="TXT" target="ftp://ftp.isi.edu/in-notes/rfc2731.txt" />
<format octets="52574" type="HTML" target="http://xml.resource.org/public/rfc/html/rfc2731.html" />
<format octets="44001" type="XML" target="http://xml.resource.org/public/rfc/xml/rfc2731.xml" />
</reference>


<reference target2="reference.RFC.2732.xml" anchor="RFC2732">
<front>
<title abbrev="IPv6 Literal Addresses in URL&apos;s">Format for Literal IPv6 Addresses in URL's</title>
<author fullname="Robert M. Hinden" initials="R.M." surname="Hinden">
<organization>Nokia</organization>

<address>
<postal>
<street>313 Fairchild Drive</street>
<city>Mountain View</city>
<region>CA</region>
<code>94043</code>
<country>US</country>
</postal>

<phone>+1 650 625 2004</phone>
<email>hinden@iprg.nokia.com</email>
</address>
</author>

<author fullname="Brian E. Carpenter" initials="B.E." surname="Carpenter">
<organization>IBM, iCAIR</organization>

<address>
<postal>
<street>1890 Maple Avenue</street>
<street>Suite 150</street>
<city>Evanston</city>
<region>IL</region>
<code>60201</code>
<country>US</country>
</postal>

<email>brian@icair.org</email>
</address>
</author>

<author fullname="Larry Masinter" initials="L." surname="Masinter">
<organization>AT&amp;T Labs</organization>

<address>
<postal>
<street>75 Willow Road</street>
<city>Menlo Park</city>
<region>CA</region>
<code>94025</code>
<country>US</country>
</postal>

<email>LMM@acm.org</email>
</address>
</author>

<date year="1999" month="December" />

<abstract>
<t>This document defines the format for literal IPv6 Addresses in URL's for implementation in World Wide Web browsers.  This format has been implemented in the IPv6 versions of several widely deployed browsers including Microsoft Internet Explorer, Mozilla, and Lynx.  It is also intended to be used in the IPv6 version of the service location protocol.</t>

<t>This document incudes an update to the generic syntax for Uniform Resource Identifiers defined in RFC 2396It defines a syntax for IPv6 addresses and allows the use of "[" and "]" within a URI explicitly for this reserved purpose.</t>
</abstract>
</front>

<seriesInfo value="2732" name="RFC" />
</reference>


<reference target2="reference.RFC.2733.xml" anchor="RFC2733">
<front>
<title abbrev="Generic FEC">An RTP Payload Format for Generic Forward Error Correction</title>
<author fullname="Jonathan Rosenberg" initials="J." surname="Rosenberg">
<organization>dynamicsoft</organization>

<address>
<postal>
<street>200 Executive Drive</street>
<street>Suite 120</street>
<city>West Orange</city>
<region>NJ</region>
<code>07046</code>
<country>US</country>
</postal>

<email>jdrosen@dynamicsoft.com</email>
</address>
</author>

<author fullname="Henning Schulzrinne" initials="H." surname="Schulzrinne">
<organization>Columbia University, M/S 0401</organization>

<address>
<postal>
<street>1214 Amsterdam Ave.</street>
<city>New York</city>
<region>NY</region>
<code>10027-7003</code>
<country>US</country>
</postal>

<email>schulzrinne@cs.columbia.edu</email>
</address>
</author>

<date year="1999" month="December" />

<abstract>
<t>This document specifies a payload format for generic forward error correction of media encapsulated in RTP. It is engineered for FEC algorithms based on the exclusive-or (parity) operation. The payload format allows end systems to transmit using arbitrary block lengths and parity schemes. 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.</t>
</abstract>
</front>

<seriesInfo value="2733" name="RFC" />
</reference>


<reference target2="reference.RFC.2734.xml" anchor="RFC2734">
<front>
<title>IPv4 over IEEE 1394</title>
<author fullname="Peter Johansson" initials="P." surname="Johansson">
<organization>Congruent Software, Inc.</organization>

<address>
<postal>
<street>98 Colorado Avenue</street>
<city>Berkeley</city>
<region>CA</region>
<code>94602</code>
<country>US</country>
</postal>

<phone>+1 510 527 3926</phone>
<facsimile>+1 510 527 3856</facsimile>
<email>pjohansson@aol.com</email>
</address>
</author>

<date year="1999" month="December" />

<abstract>
<t>This document specifies how to use IEEE Std 1394-1995, Standard for a High Performance Serial Bus (and its supplements), for the transport of Internet Protocol Version 4 (IPv4) datagrams; it defines the necessary methods, data structures and codes for that purpose. These include not only packet formats and encapsulation methods for datagrams, but also an address resolution protocol (1394 ARP) and a multicast channel allocation protocol (MCAP). Both 1394 ARP and MCAP are specific to Serial Bus; the latter permits management of Serial Bus resources when used by IP multicast groups.</t>
</abstract>
</front>

<seriesInfo value="2734" name="RFC" />
</reference>


<reference target2="reference.RFC.2735.xml" anchor="RFC2735">
<front>
<title>NHRP Support for Virtual Private Networks</title>
<author fullname="Barbara A. Fox" initials="B.A." surname="Fox">
<organization>Equipe Communications</organization>

<address>
<postal>
<street>100 Nagog Park</street>
<city>Acton</city>
<region>MA</region>
<code>01720</code>
<country>US</country>
</postal>

<phone>+1 978 795 2009</phone>
<email>bfox@equipecom.com</email>
</address>
</author>

<author fullname="Bernhard Petri" initials="B." surname="Petri">
<organization>Siemens AG</organization>

<address>
<postal>
<street>Hofmannstr. 51</street>
<city>Munich</city>
<region />
<code>D-81359</code>
<country>DE</country>
</postal>

<phone>+49 89 72234578</phone>
<email>bernhard.petri@icn.siemens.de</email>
</address>
</author>

<date year="1999" month="December" />

<abstract>
<t>The NBMA Next Hop Resolution Protocol (NHRP) is used to determine the NBMA subnetwork addresses of the "NBMA next hop" towards a public internetworking layer address (see].  This document describes the enhancements necessary to enable NHRP to perform the same function for private internetworking layer addresses available within the framework of a Virtual Private Network (VPN) service on a shared NBMA network.</t>
</abstract>
</front>

<seriesInfo value="2735" name="RFC" />
</reference>


<reference target2="reference.RFC.2736.xml" anchor="RFC2736">
<front>
<title>Guidelines for Writers of RTP Payload Format Specifications</title>
<author fullname="Mark Handley" initials="M." surname="Handley">
<organization>AT&amp;T Center for Internet Research at ICSI, International Computer Science Institute</organization>

<address>
<postal>
<street>1947 Center Street</street>
<street>Suite 600</street>
<city>Berkeley</city>
<region>CA</region>
<code>94704</code>
<country>US</country>
</postal>

<email>mjh@aciri.org</email>
</address>
</author>

<author fullname="Colin Perkins" initials="C." surname="Perkins">
<organization>University College London, Dept of Computer Science</organization>

<address>
<postal>
<street>Gower Street</street>
<city>London</city>
<region>England</region>
<code>WC1E 6BT</code>
<country>UK</country>
</postal>

<email>C.Perkins@cs.ucl.ac.uk</email>
</address>
</author>

<date year="1999" month="December" />

<abstract>
<t>This document provides general guidelines aimed at assisting the authors of RTP Payload Format specifications in deciding on good formats.  These guidelines attempt to capture some of the experience gained with RTP as it evolved during its development.</t>
</abstract>
</front>

<seriesInfo value="36" name="BCP" />
<seriesInfo value="2736" name="RFC" />
</reference>


<reference target2="reference.RFC.2737.xml" anchor="RFC2737">
<front>
<title>Entity MIB (Version 2)</title>
<author fullname="Keith McCloghrie" initials="K." surname="McCloghrie">
<organization>Cisco Systems, Inc.</organization>

<address>
<postal>
<street>170 West Tasman Drive</street>
<city>San Jose</city>
<region>CA</region>
<code>95134</code>
<country>US</country>
</postal>

<phone>+1 408 526 5260</phone>
<email>kzm@cisco.com</email>
</address>
</author>

<author fullname="Andy Bierman" initials="A." surname="Bierman">
<organization>Cisco Systems, Inc.</organization>

<address>
<postal>
<street>170 West Tasman Drive</street>
<city>San Jose</city>
<region>CA</region>
<code>95134</code>
<country>US</country>
</postal>

<phone>+1 408 527 3711</phone>
<email>abierman@cisco.com</email>
</address>
</author>

<date year="1999" month="December" />

<abstract>
<t>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 multiple logical and physical entities managed by a single SNMP agent.</t>
</abstract>
</front>

<seriesInfo value="2737" name="RFC" />
</reference>


<reference target2="reference.RFC.2738.xml" anchor="RFC2738">
<front>
<title abbrev="Corrections to Syntax for Media Features">Corrections to "A Syntax for Describing Media Feature Sets"</title>
<author fullname="Graham Klyne" initials="G." surname="Klyne">
<organization>Content Technologies Ltd.</organization>

<address>
<postal>
<street>1220 Parkview</street>
<street>Arlington Business Park</street>
<city>Theale</city>
<region>Reading</region>
<code>RG7 4SA</code>
<country>UK</country>
</postal>

<phone>+44 118 9301300</phone>
<facsimile>+44 118 9301301</facsimile>
<email>GK@ACM.ORG</email>
</address>
</author>

<date year="1999" month="December" />

<abstract>
<t>In RFC 2533, "A Syntax for Describing Media Feature Sets", an expression format is presented for describing media feature capabilities using simple media feature tags.</t>

<t>This memo contains two corrections to that specification:  one fixes an error in the formal syntax specification, and the other fixes an error in the rules for reducing feature comparison predicates.</t>
</abstract>
</front>

<seriesInfo value="2738" name="RFC" />
</reference>


<reference target2="reference.RFC.2739.xml" anchor="RFC2739">
<front>
<title abbrev="Locating a Calendar User">Calendar Attributes for vCard and LDAP</title>
<author fullname="T. Small" initials="T." surname="Small">
<organization>XpertSite.Com</organization>
</author>

<author fullname="D. Hennessy" initials="D." surname="Hennessy">
<organization>ISOCOR</organization>
</author>

<author fullname="F. Dawson" initials="F." surname="Dawson">
<organization>Lotus</organization>
</author>

<date year="2000" month="January" />

<abstract>
<t>When scheduling a calendar entity, such as 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.</t>

<t>In order to meet these challenges, a calendar user agent (CUA) needs a mechanism to locate (URI) individual user's calendar and free/busy time.</t>

<t>This memo defines three mechanisms for obtaining a URI 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.</t>
</abstract>
</front>

<seriesInfo value="2739" name="RFC" />
</reference>


<reference target2="reference.RFC.2740.xml" anchor="RFC2740">
<front>
<title>OSPF for IPv6</title>
<author fullname="Rob Coltun" initials="R." surname="Coltun">
<organization>Siara Systems</organization>

<address>
<postal>
<street>300 Ferguson Drive</street>
<city>Mountain View</city>
<region>CA</region>
<code>94043</code>
<country>US</country>
</postal>

<phone>+1 650 390 9030</phone>
<email>rcoltun@siara.com</email>
</address>
</author>

<author fullname="Dennis Ferguson" initials="D." surname="Ferguson">
<organization>Juniper Networks</organization>

<address>
<postal>
<street>385 Ravendale Drive</street>
<city>Mountain View</city>
<region>CA</region>
<code>94043</code>
<country>US</country>
</postal>

<phone>+1 650 526 8004</phone>
<email>dennis@juniper.com</email>
</address>
</author>

<author fullname="John Moy" initials="J." surname="Moy">
<organization>Sycamore Networks, Inc.</organization>

<address>
<postal>
<street>10 Elizabeth Drive</street>
<city>Chelmsford</city>
<region>MA</region>
<code>01824</code>
<country>US</country>
</postal>

<phone>+1 978 367 2161</phone>
<facsimile>+1 978 250 3350</facsimile>
<email>jmoy@sycamorenet.com</email>
</address>
</author>

<date year="1999" month="December" />

<abstract>
<t>This document describes the modifications to OSPF to support version 6 of the Internet Protocol (IPv6).  The fundamental mechanisms of OSPF (flooding, DR election, area support, SPF calculations, etc.) remain unchanged. However, some changes have been necessary, either due to changes in protocol semantics between IPv4 and IPv6, or simply to handle the increased address size of IPv6.</t>

<t>Changes between OSPF for IPv4 and this document include the following. Addressing semantics have been removed from OSPF packets and the basic LSAs. New LSAs have been created to carry IPv6 addresses and prefixes. OSPF now runs on a per-link basis, instead of on a per-IP-subnet basis. Flooding scope for LSAs has been generalized. Authentication has been removed from the OSPF protocol itself, instead relying on IPv6's Authentication Header and Encapsulating Security Payload.</t>

<t>Most packets in OSPF for IPv6 are almost as compact as those in OSPF for IPv4, even with the larger IPv6 addresses. Most field-XSand packet-size limitations present in OSPF for IPv4 have been relaxed. In addition, option handling has been made more flexible.</t>

<t>All of OSPF for IPv4's optional capabilities, including on-demand circuit support, NSSA areas, and the multicast extensions to OSPF (MOSPF) are also supported in OSPF for IPv6.</t>
</abstract>
</front>

<seriesInfo value="2740" name="RFC" />
</reference>


<reference target2="reference.RFC.2741.xml" anchor="RFC2741">
<front>
<title abbrev="AgentX">Agent Extensibility (AgentX) Protocol Version 1</title>
<author fullname="Mike Daniele" initials="M." surname="Daniele">
<organization>Compaq Computer Corporation</organization>

<address>
<postal>
<street>110 Spit Brook Rd</street>
<city>Nashua</city>
<region>NH</region>
<code>03062</code>
<country>US</country>
</postal>

<phone>+1 603 881 1423</phone>
<email>daniele@zk3.dec.com</email>
</address>
</author>

<author fullname="Bert Wijnen" initials="B." surname="Wijnen">
<organization>IBM T.J.Watson Research</organization>

<address>
<postal>
<street>Schagen 33</street>
<region>GL Linschoten</region>
<code>3461</code>
<country>NL</country>
</postal>

<phone>+31 34 8432794</phone>
<email>wijnen@vnet.ibm.com</email>
</address>
</author>

<author fullname="Mark Ellison" initials="M." surname="Ellison">
<organization>Ellison Software Consulting, Inc.</organization>

<address>
<postal>
<street>38 Salem Road</street>
<city>Atkinson</city>
<region>NH</region>
<code>03811</code>
<country>US</country>
</postal>

<phone>+1 603 362 9270</phone>
<email>ellison@world.std.com</email>
</address>
</author>

<author fullname="Dale Francisco" initials="D." surname="Francisco">
<organization>Cisco Systems</organization>

<address>
<postal>
<street>150 Castilian Dr</street>
<city>Santa Barbara</city>
<region>CA</region>
<code>93117</code>
<country>US</country>
</postal>

<phone>+1 805 961 3642</phone>
<facsimile>+1 805 961 3600</facsimile>
<email>dfrancis@cisco.com</email>
</address>
</author>

<date year="2000" month="January" />

<abstract>
<t>This memo defines a standardized framework for extensible SNMP agents.  It defines processing entities called master agents and subagents, a protocol (AgentX) used to  communicate between them, and the elements of procedure by which the extensible agent processes SNMP protocol messages. This memo obsoletes RFC 2257.</t>
</abstract>
</front>

<seriesInfo value="2741" name="RFC" />
</reference>


<reference target2="reference.RFC.2742.xml" anchor="RFC2742">
<front>
<title abbrev="Agent X MIB">Definitions of Managed Objects for Extensible SNMP Agents</title>
<author fullname="Lauren Heintz" initials="L." surname="Heintz">
<organization>Cisco Systems</organization>

<address>
<postal>
<street>1450 North McDowell Blvd.</street>
<city>Petaluma</city>
<region>CA</region>
<code>94954-6515</code>
<country>US</country>
</postal>

<phone>+1 707 793 1714</phone>
<email>lheintz@cisco.com</email>
</address>
</author>

<author fullname="Smitha Gudur" initials="S." surname="Gudur">
<organization>Independent Consultant</organization>

<address>
<email>sgudur@hotmail.com</email>
</address>
</author>

<author fullname="Mark Ellison" initials="M." surname="Ellison">
<organization>Ellison Software Consulting, Inc.</organization>

<address>
<postal>
<street>38 Salem Road</street>
<city>Atkinson</city>
<region>NH</region>
<code>03811</code>
<country>US</country>
</postal>

<phone>+1 603 362 9270</phone>
<email>ellison@world.std.com</email>
</address>
</author>

<date year="2000" month="January" />

<abstract>
<t>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 managing SNMP agents that use the  Agent Extensibility (AgentX) Protocol.</t>

<t>This memo specifies a MIB module in a manner that is both compliant to the SMIv2, and semantically identical to the peer SMIv1 definitions.</t>
</abstract>
</front>

<seriesInfo value="2742" name="RFC" />
</reference>


<reference target2="reference.RFC.2743.xml" anchor="RFC2743">
<front>
<title abbrev="GSS-API">Generic Security Service Application Program Interface Version 2, Update 1</title>
<author fullname="John Linn" initials="J." surname="Linn">
<organization>RSA Laboratories</organization>

<address>
<postal>
<street>20 Crosby Drive</street>
<city>Bedford</city>
<region>MA</region>
<code>01730</code>
<country>US</country>
</postal>

<phone>+1 781 687 7817</phone>
<email>jlinn@rsasecurity.com</email>
</address>
</author>

<date year="2000" month="January" />

<abstract>
<t>The Generic Security Service Application Program Interface (GSS-API), Version 2, as defined in, 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:</t>

<t>documents defining specific parameter bindings for particular language environments</t>

<t>documents defining token formats, protocols, and procedures to be implemented in order to realize GSS-API services atop particular security mechanisms</t>

<t>This memo obsoletesmaking specific, incremental changes in response to implementation experience and liaison requests. It is intended, therefore, that this memo or a successor version thereto will become the basis for subsequent progression of the GSS-API specification on the standards track.</t>
</abstract>
</front>

<seriesInfo value="2743" name="RFC" />
</reference>


<reference target2="reference.RFC.2744.xml" anchor="RFC2744">
<front>
<title abbrev="GSS-API V2: C-bindings">Generic Security Service API Version 2 : C-bindings</title>
<author fullname="John Wray" initials="J." surname="Wray">
<organization>Iris Associates</organization>

<address>
<postal>
<street>5 Technology Park Drive</street>
<city>Westford</city>
<region>MA</region>
<code>01886</code>
<country>US</country>
</postal>

<phone>+1 978 392 6689</phone>
<email>John_Wray@Iris.com</email>
</address>
</author>

<date year="2000" month="January" />

<abstract>
<t>This document specifies C language bindings for Version 2, Update 1 of the Generic Security Service Application Program Interface (GSS- API), which is described at a language-independent conceptual level in RFC-2743.  It obsoletes RFC-1509, making specific incremental changes in response to implementation experience and liaison requests.  It is intended, therefore, that this memo or a successor version thereof will become the basis for subsequent progression of the GSS-API specification on the standards track.</t>

<t>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.</t>
</abstract>
</front>

<seriesInfo value="2744" name="RFC" />
</reference>


<reference target2="reference.RFC.2745.xml" anchor="RFC2745">
<front>
<title>RSVP Diagnostic Messages</title>
<author fullname="Andreas Terzis" initials="A." surname="Terzis">
<organization>UCLA</organization>

<address>
<postal>
<street>4677 Boelter Hall</street>
<city>Los Angeles</city>
<region>CA</region>
<code>90095</code>
<country>US</country>
</postal>

<phone>+1 310 267 2190</phone>
<email>terzis@cs.ucla.edu</email>
</address>
</author>

<author fullname="Bob Braden" initials="B." surname="Braden">
<organization>USC Information Sciences Institute</organization>

<address>
<postal>
<street>4676 Admiralty Way</street>
<city>Marina del Rey</city>
<region>CA</region>
<code>90292</code>
<country>US</country>
</postal>

<phone>+1 310 822 1511</phone>
<email>braden@isi.edu</email>
</address>
</author>

<author fullname="Subramaniam Vincent" initials="S." surname="Vincent">
<organization>Cisco Systems</organization>

<address>
<postal>
<street>275, E Tasman Drive</street>
<street>MS SJC04/2/1</street>
<city>San Jose</city>
<region>CA</region>
<code>95134</code>
<country>US</country>
</postal>

<phone>+1 408 525 3474</phone>
<email>svincent@cisco.com</email>
</address>
</author>

<author fullname="Lixia Zhang" initials="L." surname="Zhang">
<organization>UCLA</organization>

<address>
<postal>
<street>4531G Boelter Hall</street>
<city>Los Angeles</city>
<region>CA</region>
<code>90095</code>
<country>US</country>
</postal>

<phone>+1 310 825 2695</phone>
<email>lixia@cs.ucla.edu</email>
</address>
</author>

<date year="2000" month="January" />

<abstract>
<t>This document specifies the RSVP diagnostic facility, which allows a user to collect information about the RSVP state along a path.  This specification describes the functionality, diagnostic message formats, and processing rules.</t>
</abstract>
</front>

<seriesInfo value="2745" name="RFC" />
</reference>


<reference target2="reference.RFC.2746.xml" anchor="RFC2746">
<front>
<title>RSVP Operation Over IP Tunnels</title>
<author fullname="Andreas Terzis" initials="A." surname="Terzis">
<organization>UCLA</organization>

<address>
<postal>
<street>4677 Boelter Hall</street>
<city>Los Angeles</city>
<region>CA</region>
<code>90095</code>
<country>US</country>
</postal>

<phone>+1 310 267 2190</phone>
<email>terzis@cs.ucla.edu</email>
</address>
</author>

<author fullname="John Krawczyk" initials="J." surname="Krawczyk">
<organization>ArrowPoint Communications</organization>

<address>
<postal>
<street>50 Nagog Park</street>
<city>Acton</city>
<region>MA</region>
<code>01720</code>
<country>US</country>
</postal>

<phone>+1 978 206 3027</phone>
<email>jj@arrowpoint.com</email>
</address>
</author>

<author fullname="John Wroclawski" initials="J." surname="Wroclawski">
<organization>MIT Laboratory for Computer Sciencce</organization>

<address>
<postal>
<street>545 Technology Sq.</street>
<city>Cambridge</city>
<region>MA</region>
<code>02139</code>
<country>US</country>
</postal>

<phone>+1 617 253 7885</phone>
<facsimile>+1 617 253 2673</facsimile>
<email>jtw@lcs.mit.edu</email>
</address>
</author>

<author fullname="Lixia Zhang" initials="L." surname="Zhang">
<organization>UCLA</organization>

<address>
<postal>
<street>4531G Boelter Hall</street>
<city>Los Angeles</city>
<region>CA</region>
<code>90095</code>
<country>US</country>
</postal>

<phone>+1 310 825 2695</phone>
<email>lixia@cs.ucla.edu</email>
</address>
</author>

<date year="2000" month="January" />

<abstract>
<t>This document describes an approach for providing RSVP protocol services over IP tunnels. We briefly describe the problem, the characteristics of possible solutions, and the design goals of our approach. We then present the details of an implementation which meets our design goals.</t>
</abstract>
</front>

<seriesInfo value="2746" name="RFC" />
</reference>


<reference target2="reference.RFC.2747.xml" anchor="RFC2747">
<front>
<title>RSVP Cryptographic Authentication</title>
<author fullname="Fred Baker" initials="F." surname="Baker">
<organization>Cisco Systems</organization>

<address>
<postal>
<street>519 Lado Drive</street>
<city>Santa Barbara</city>
<region>CA</region>
<code>93111</code>
<country>US</country>
</postal>

<phone>+1 408 526 4257</phone>
<email>fred@cisco.com</email>
</address>
</author>

<author fullname="Bob Lindell" initials="B." surname="Lindell">
<organization>USC Information Sciences Institute</organization>

<address>
<postal>
<street>4676 Admiralty Way</street>
<city>Marina del Rey</city>
<region>CA</region>
<code>90292</code>
<country>US</country>
</postal>

<phone>+1 310 822 1511</phone>
<email>lindell@ISI.EDU</email>
</address>
</author>

<author fullname="Mohit Talwar" initials="M." surname="Talwar">
<organization>Microsoft Corporation</organization>

<address>
<postal>
<street>One Microsoft Way</street>
<city>Redmond</city>
<region>WA</region>
<code>98052</code>
<country>US</country>
</postal>

<phone>+1 425 705 3131</phone>
<email>mohitt@microsoft.com</email>
</address>
</author>

<date year="2000" month="January" />

<abstract>
<t>This document describes the format and use of RSVP's INTEGRITY object to provide hop-by-hop integrity and authentication of RSVP messages.</t>
</abstract>
</front>

<seriesInfo value="2747" name="RFC" />
</reference>


<reference target2="reference.RFC.2748.xml" anchor="RFC2748">
<front>
<title abbrev="COPS">The COPS (Common Open Policy Service) Protocol</title>
<author fullname="David Durham" initials="D." surname="Durham">
<organization>Intel</organization>

<address>
<postal>
<street>2111 NE 25th Avenue</street>
<city>Hillsboro</city>
<region>OR</region>
<code>97124</code>
<country>US</country>
</postal>

<phone>+1 503 264 6232</phone>
<email>David.Durham@intel.com</email>
</address>
</author>

<author fullname="Jim Boyle" initials="J." surname="Boyle">
<organization>Level 3 Communications</organization>

<address>
<postal>
<street>1025 Eldorado Boulevard</street>
<city>Broomfield</city>
<region>CO</region>
<code>80021</code>
<country>US</country>
</postal>

<phone>+1 720 888 1192</phone>
<email>jboyle@Level3.net</email>
</address>
</author>

<author fullname="Ron Cohen" initials="R." surname="Cohen">
<organization>CISCO Systems</organization>

<address>
<postal>
<street>4 Maskit St.</street>
<region>Herzeliya Pituach</region>
<code>46766</code>
<country>IL</country>
</postal>

<phone>+972 9 9700064</phone>
<email>ronc@cisco.com</email>
</address>
</author>

<author fullname="Shai Herzog" initials="S." surname="Herzog">
<organization>IPHighway, Inc.</organization>

<address>
<postal>
<street>55 New York Avenue</street>
<city>Framingham</city>
<region>MA</region>
<code>01701</code>
<country>US</country>
</postal>

<phone>+1 508 620 1141</phone>
<email>herzog@iphighway.com</email>
</address>
</author>

<author fullname="Raju Rajan" initials="R." surname="Rajan">
<organization>AT&amp;T Shannon Laboratory</organization>

<address>
<postal>
<street>180 Park Avenue</street>
<street>P.O. Box 971</street>
<city>Florham Park</city>
<region>NJ</region>
<code>07932-0971</code>
<country>US</country>
</postal>

<email>rajan@research.att.com</email>
</address>
</author>

<author fullname="Arun Sastry" initials="A." surname="Sastry">
<organization>Cisco Systems</organization>

<address>
<postal>
<street>4 The Square, Stockley Park</street>
<city>Uxbridge</city>
<region>Middlesex</region>
<code>UB11 1BN</code>
<country>UK</country>
</postal>

<phone>+44 20 87568693</phone>
<email>asastry@cisco.com</email>
</address>
</author>

<date year="2000" month="January" />

<abstract>
<t>This document describes a simple client/server model for supporting policy control over QoS signaling protocols. The model does not make any assumptions about the methods of the policy server, but is based on the server returning decisions to policy requests. The model is designed to be extensible so that other kinds of policy clients may be supported in the future. However, this document makes no claims that it is the only or the preferred approach for enforcing future types of policies.</t>
</abstract>
</front>

<seriesInfo value="2748" name="RFC" />
</reference>


<reference target2="reference.RFC.2749.xml" anchor="RFC2749">
<front>
<title>COPS usage for RSVP</title>
<author fullname="Shai Herzog" initials="S." surname="Herzog">
<organization>IPHighway, Inc.</organization>

<address>
<postal>
<street>55 New York Avenue</street>
<city>Framingham</city>
<region>MA</region>
<code>01701</code>
<country>US</country>
</postal>

<phone>+1 508 620 1141</phone>
<email>herzog@iphighway.com</email>
</address>
</author>

<author fullname="Jim Boyle" initials="J." surname="Boyle">
<organization>Level 3 Communications</organization>

<address>
<postal>
<street>1025 Eldorado Boulevard</street>
<city>Broomfield</city>
<region>CO</region>
<code>80021</code>
<country>US</country>
</postal>

<phone>+1 720 888 1192</phone>
<email>jboyle@Level3.net</email>
</address>
</author>

<author fullname="Ron Cohen" initials="R." surname="Cohen">
<organization>CISCO Systems</organization>

<address>
<postal>
<street>4 Maskit St.</street>
<region>Herzeliya Pituach</region>
<code>46766</code>
<country>IL</country>
</postal>

<phone>+972 9 9700064</phone>
<email>ronc@cisco.com</email>
</address>
</author>

<author fullname="David Durham" initials="D." surname="Durham">
<organization>Intel</organization>

<address>
<postal>
<street>2111 NE 25th Avenue</street>
<city>Hillsboro</city>
<region>OR</region>
<code>97124</code>
<country>US</country>
</postal>

<phone>+1 503 264 6232</phone>
<email>David.Durham@intel.com</email>
</address>
</author>

<author fullname="Raju Rajan" initials="R." surname="Rajan">
<organization>AT&amp;T Shannon Laboratory</organization>

<address>
<postal>
<street>180 Park Avenue</street>
<street>P.O. Box 971</street>
<city>Florham Park</city>
<region>NJ</region>
<code>07932-0971</code>
<country>US</country>
</postal>

<phone>+1 973 360 7229</phone>
<email>rajan@research.att.com</email>
</address>
</author>

<author fullname="Arun Sastry" initials="A." surname="Sastry">
<organization>Cisco Systems</organization>

<address>
<postal>
<street>4 The Square, Stockley Park</street>
<city>Uxbridge</city>
<region>Middlesex</region>
<code>UB11 1BN</code>
<country>UK</country>
</postal>

<phone>+44 20 87568693</phone>
<email>asastry@cisco.com</email>
</address>
</author>

<date year="2000" month="January" />

<abstract>
<t>This document describes usage directives for supporting COPS policy services in RSVP environments.</t>
</abstract>
</front>

<seriesInfo value="2749" name="RFC" />
</reference>


<reference target2="reference.RFC.2750.xml" anchor="RFC2750">
<front>
<title>RSVP Extensions for Policy Control</title>
<author fullname="Shai Herzog" initials="S." surname="Herzog">
<organization>IPHighway, Inc.</organization>

<address>
<postal>
<street>55 New York Avenue</street>
<city>Framingham</city>
<region>MA</region>
<code>01701</code>
<country>US</country>
</postal>

<phone>+1 508 620 1141</phone>
<email>herzog@iphighway.com</email>
</address>
</author>

<date year="2000" month="January" />

<abstract>
<t>This memo presents a set of extensions for supporting generic policy based admission control in RSVP. It should be perceived as an extension to the RSVP functional  specifications.</t>

<t>These extensions include the standard format of POLICY_DATA objects, and a description of RSVP's handling of policy events.</t>

<t>This document does not advocate particular policy control mechanisms; however, a Router/Server Policy Protocol description for these extensions can be found in,,.</t>
</abstract>
</front>

<seriesInfo value="2750" name="RFC" />
</reference>


<reference target2="reference.RFC.2751.xml" anchor="RFC2751">
<front>
<title>Signaled Preemption Priority Policy Element</title>
<author fullname="Shai Herzog" initials="S." surname="Herzog">
<organization>IPHighway, Inc.</organization>

<address>
<postal>
<street>55 New York Avenue</street>
<city>Framingham</city>
<region>MA</region>
<code>01701</code>
<country>US</country>
</postal>

<phone>+1 508 620 1141</phone>
<email>herzog@iphighway.com</email>
</address>
</author>

<date year="2000" month="January" />

<abstract>
<t>This document describes a preemption priority policy element for use by signaled policy based admission protocols (such asand.</t>

<t>Preemption priority defines a relative importance (rank) within the set of flows competing to be admitted into the network. Rather than admitting flows by order of arrival (First Come First Admitted) network nodes may consider priorities to preempt some previously admitted low priority flows in order to make room for a newer, high- priority flow.</t>
</abstract>
</front>

<seriesInfo value="2751" name="RFC" />
</reference>


<reference target2="reference.RFC.2752.xml" anchor="RFC2752">
<front>
<title>Identity Representation for RSVP</title>
<author fullname="Satyendra Yadav" initials="S." surname="Yadav">
<organization>Intel, JF3-206</organization>

<address>
<postal>
<street>2111 NE 25th Avenue</street>
<city>Hillsboro</city>
<region>OR</region>
<code>97124</code>
<country>US</country>
</postal>

<email>Satyendra.Yadav@intel.c</email>
</address>
</author>

<author fullname="Raj Yavatkar" initials="R." surname="Yavatkar">
<organization>Intel, JF3-206</organization>

<address>
<postal>
<street>2111 NE 25th Avenue</street>
<city>Hillsboro</city>
<region>OR</region>
<code>97124</code>
<country>US</country>
</postal>

<email>Raj.Yavatkar@intel.com</email>
</address>
</author>

<author fullname="Ramesh Pabbati" initials="R." surname="Pabbati">
<organization>Microsoft</organization>

<address>
<postal>
<street>1 Microsoft Way</street>
<city>Redmond</city>
<region>WA</region>
<code>98054</code>
<country>US</country>
</postal>

<email>rameshpa@microsoft.com</email>
</address>
</author>

<author fullname="Peter Ford" initials="P." surname="Ford">
<organization>Microsoft</organization>

<address>
<postal>
<street>1 Microsoft Way</street>
<city>Redmond</city>
<region>WA</region>
<code>98054</code>
<country>US</country>
</postal>

<email>peterf@microsoft.com</email>
</address>
</author>

<author fullname="Tim Moore" initials="T." surname="Moore">
<organization>Microsoft</organization>

<address>
<postal>
<street>1 Microsoft Way</street>
<city>Redmond</city>
<region>WA</region>
<code>98054</code>
<country>US</country>
</postal>

<email>timmoore@microsoft.com</email>
</address>
</author>

<author fullname="Shai Herzog" initials="S." surname="Herzog">
<organization>IPHighway, Inc.</organization>

<address>
<postal>
<street>55 New York Avenue</street>
<city>Framingham</city>
<region>MA</region>
<code>01701</code>
<country>US</country>
</postal>

<phone>+1 508 620 1141</phone>
<email>herzog@iphighway.com</email>
</address>
</author>

<date year="2000" month="January" />

<abstract>
<t>This document describes the representation of identity information in POLICY_DATA objectfor supporting policy based admission control in RSVP. The goal of identity representation is to allow a process on a system to securely identify the owner and the application of the communicating process (e.g. user id) and convey
this information in RSVP messages  (PATH or RESV) in a secure manner. We describe the encoding of identities as RSVP policy element. We describe the processing rules to generate identity policy elements for multicast merged flows. Subsequently, we describe representations of user identities for Kerberos and Public Key based user authentication mechanisms. In summary we describe the use of this identity information in an operational setting.</t>
</abstract>
</front>

<seriesInfo value="2752" name="RFC" />
</reference>


<reference target2="reference.RFC.2753.xml" anchor="RFC2753">
<front>
<title abbrev="Framework for Policy-based Admission Control">A Framework for Policy-based Admission Control</title>
<author fullname="Raj Yavatkar" initials="R." surname="Yavatkar">
<organization>Intel Corporation</organization>

<address>
<postal>
<street>2111 N.E. 25th Avenue</street>
<city>Hillsboro</city>
<region>OR</region>
<code>97124</code>
<country>US</country>
</postal>

<phone>+1 503 264 9077</phone>
<email>raj.yavatkar@intel.com</email>
</address>
</author>

<author fullname="Dimitrios Pendarakis" initials="D." surname="Pendarakis">
<organization>IBM T.J. Watson Research Center</organization>

<address>
<postal>
<street>P.O. Box 704</street>
<city>Yorktown Heights</city>
<region>NY</region>
<code>10598</code>
<country>US</country>
</postal>

<phone>+1 914 784 7536</phone>
<email>dimitris@watson.ibm.com</email>
</address>
</author>

<author fullname="Roch Guerin" initials="R." surname="Guerin">
<organization>University of Pennsylvania, Dept. of Electrical Engineering</organization>

<address>
<postal>
<street>200 South 33rd Street</street>
<city>Philadelphia</city>
<region>PA</region>
<code>19104</code>
<country>US</country>
</postal>

<phone>+1 215 898 9351</phone>
<email>guerin@ee.upenn.edu</email>
</address>
</author>

<date year="2000" month="January" />

<abstract>
<t></t>
</abstract>
</front>

<seriesInfo value="2753" name="RFC" />
</reference>


<reference target2="reference.RFC.2754.xml" anchor="RFC2754">
<front>
<title>RPS IANA Issues</title>
<author fullname="Cengiz Alaettinoglu" initials="C." surname="Alaettinoglu">
<organization>USC Information Sciences Institute</organization>

<address>
<postal>
<street>4676 Admiralty Way</street>
<city>Marina del Rey</city>
<region>CA</region>
<code>90291</code>
<country>US</country>
</postal>

<phone>+1 213 822 1511</phone>
<email>cengiz@isi.edu</email>
</address>
</author>

<author fullname="Curtis Villamizar" initials="C." surname="Villamizar">
<organization>Avici Systems</organization>

<address>
<email>curtis@avici.com</email>
</address>
</author>

<author fullname="Ramesh Govindan" initials="R." surname="Govindan">
<organization>USC Information Sciences Institute</organization>

<address>
<postal>
<street>4676 Admiralty Way</street>
<city>Marina del Rey</city>
<region>CA</region>
<code>90291</code>
<country>US</country>
</postal>

<phone>+1 213 822 1511</phone>
<email>govindan@isi.edu</email>
</address>
</author>

<date year="2000" month="January" />

<abstract>
<t>RPS Securityrequires certain RPSLobjects in the IRR to be hierarchically delegated.  The set of objects that are at the root of this hierarchy needs to be created and digitally signed by IANA. This paper presents these seed objects and lists operations required from IANA.</t>

<t>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.</t>
</abstract>
</front>

<seriesInfo value="2754" name="RFC" />
</reference>


<reference target2="reference.RFC.2755.xml" anchor="RFC2755">
<front>
<title>Security Negotiation for WebNFS</title>
<author fullname="Alex Chiu" initials="A." surname="Chiu">
<organization>Sun Microsystems, Inc.</organization>

<address>
<postal>
<street>901 San Antonio Road</street>
<city>Palo Alto</city>
<region>CA</region>
<code>94303</code>
<country>US</country>
</postal>

<phone>+1 650 786 6465</phone>
<email>alex.chiu@Eng.sun.com</email>
</address>
</author>

<author fullname="Mike Eisler" initials="M." surname="Eisler">
<organization>Sun Microsystems, Inc.</organization>

<address>
<postal>
<street>901 San Antonio Road</street>
<city>Palo Alto</city>
<region>CA</region>
<code>94303</code>
<country>US</country>
</postal>

<phone>+1 719 599 9026</phone>
<email>michael.eisler@Eng.sun.com</email>
</address>
</author>

<author fullname="Brent Callaghan" initials="B." surname="Callaghan">
<organization>Sun Microsystems, Inc.</organization>

<address>
<postal>
<street>901 San Antonio Road</street>
<city>Palo Alto</city>
<region>CA</region>
<code>94303</code>
<country>US</country>
</postal>

<phone>+1 650 786 5067</phone>
<email>brent.callaghan@Eng.sun.com</email>
</address>
</author>

<date year="2000" month="January" />

<abstract>
<t>This document describes a protocol for a WebNFS clientto negotiate the desired security mechanism with a WebNFS serverbefore the WebNFS client falls back to the MOUNT v3 protocol. This document is provided so that people can write compatible implementations.</t>
</abstract>
</front>

<seriesInfo value="2755" name="RFC" />
</reference>


<reference target2="reference.RFC.2756.xml" anchor="RFC2756">
<front>
<title>Hyper Text Caching Protocol (HTCP/0.0)</title>
<author fullname="Paul Vixie" initials="P." surname="Vixie">
<organization>Internet Software Consortium</organization>

<address>
<postal>
<street>950 Charter Street</street>
<city>Redwood City</city>
<region>CA</region>
<code>94063</code>
<country>US</country>
</postal>

<phone>+1 650 779 7001</phone>
<email>vixie@isc.org</email>
</address>
</author>

<author fullname="Duane Wessels" initials="D." surname="Wessels">
<organization>USCD, National Lab for Applied Network Research</organization>

<address>
<postal>
<street>9500 Gilman Drive</street>
<city>La Jolla</city>
<region>CA</region>
<code>92093</code>
<country>US</country>
</postal>

<phone>+1 303 497 1822</phone>
<email>wessels@nlanr.net</email>
</address>
</author>

<date year="2000" month="January" />

<abstract>
<t>This document describes HTCP, a protocol for discovering HTTP caches and cached data, managing sets of HTTP caches, and monitoring cache activity.  This is an experimental protocol, one among several proposals to perform these functions.</t>
</abstract>
</front>

<seriesInfo value="2756" name="RFC" />
</reference>


<reference target2="reference.RFC.2757.xml" anchor="RFC2757">
<front>
<title>Long Thin Networks</title>
<author fullname="Gabriel E. Montenegro" initials="G.E." surname="Montenegro">
<organization>Sun Microsystems, Inc., Sun Labs Networking and Security Group</organization>

<address>
<postal>
<street>901 San Antonio Road</street>
<street>Mailstop UMPK 15-214</street>
<city>Palo Alto</city>
<region>CA</region>
<code>94303</code>
<country>US</country>
</postal>

<phone>+1 650 786 6288</phone>
<facsimile>+1 650 786 6445</facsimile>
<email>gab@sun.com</email>
</address>
</author>

<author fullname="Spencer Dawkins" initials="S." surname="Dawkins">
<organization>Nortel Networks</organization>

<address>
<postal>
<street>P.O. Box 833805</street>
<city>Richardson</city>
<region>TX</region>
<code>75083-3805</code>
<country>US</country>
</postal>

<phone>+1 972 684 4827</phone>
<facsimile>+1 972 685 3292</facsimile>
<email>sdawkins@nortel.com</email>
</address>
</author>

<author fullname="Markku Kojo" initials="M." surname="Kojo">
<organization>University of Helsinki, Department of Computer Science</organization>

<address>
<postal>
<street>P.O. Box 26 (Teollisuuskatu 23)</street>
<city>Helsinki</city>
<region />
<code>FIN-00014</code>
<country>FI</country>
</postal>

<phone>+358 9 19144179</phone>
<facsimile>+358 9 19144441</facsimile>
<email>kojo@cs.helsinki.fi</email>
</address>
</author>

<author fullname="Vincent Magret" initials="V." surname="Magret">
<organization>Alcatel Network Systems, Inc,  Corporate Research Center</organization>

<address>
<postal>
<street>1201 Campbell</street>
<street>M/S 446-310</street>
<city>Richardson</city>
<region>TX</region>
<code>75081</code>
<country>US</country>
</postal>

<phone>+1 972 996 2625</phone>
<facsimile>+1 972 996 5902</facsimile>
<email>vincent.magret@aud.alcatel.com</email>
</address>
</author>

<author fullname="Nitin Vaidya" initials="N." surname="Vaidya">
<organization>Texas A&amp;M University, Dept. of Computer Science</organization>

<address>
<postal>
<street />
<city>College Station</city>
<region>TX</region>
<code>77843-3112</code>
<country>US</country>
</postal>

<phone>+1 979 845 0512</phone>
<facsimile>+1 979 847 8578</facsimile>
<email>vaidya@cs.tamu.edu</email>
</address>
</author>

<date year="2000" month="January" />

<abstract>
<t>In view of the unpredictable and problematic nature of long thin networks (for example, wireless WANs), arriving at an optimized transport is a daunting task.  We have  reviewed the existing proposals along with future research items. Based on this overview, we also recommend mechanisms for implementation in long thin networks.</t>

<t>Our goal is to identify a TCP that works for all users, including users of long thin networks. We started from the working recommendations of the IETF TCP Over Satellite Links (tcpsat) working group with this end in mind.</t>

<t>We recognize that not every tcpsat recommendation will be required for long thin networks as well, and work toward a set of TCP recommendations that are 'benign' in environments that do not require them.</t>
</abstract>
</front>

<seriesInfo value="2757" name="RFC" />
</reference>


<reference target2="reference.RFC.2758.xml" anchor="RFC2758">
<front>
<title abbrev="SLAPM-MIB">Definitions of Managed Objects for Service Level Agreements Performance Monitoring</title>
<author fullname="Kenneth D. White" initials="K.D." surname="White">
<organization>IBM Corporation,  Dept. BRQA/Bldg. 501/G114</organization>

<address>
<postal>
<street>P.O.Box 12195</street>
<street>3039 Cornwallis</street>
<city>Research Triangle Park</city>
<region>NC</region>
<code>27709</code>
<country>US</country>
</postal>

<email>wkenneth@us.ibm.com</email>
</address>
</author>

<date year="2000" month="February" />

<abstract>
<t>This memo defines a Management Information Base (MIB) for performance monitoring of Service Level Agreements (SLAs) defined via policy definitions.  The MIB defined herein focuses on defining a set of objects for monitoring SLAs and not on replication of the content of the policy definitions being monitored.  The goal of the MIB defined within this document is to defined statistics related to a policy rule definition for reporting on the effect that a policy rule has on a system and to defined a method of monitoring this data.</t>
</abstract>
</front>

<seriesInfo value="2758" name="RFC" />
</reference>


<reference target2="reference.RFC.2759.xml" anchor="RFC2759">
<front>
<title abbrev="Microsoft MS-CHAP-V2">Microsoft PPP CHAP Extensions, Version 2</title>
<author fullname="Glen Zorn" initials="G." surname="Zorn">
<organization>Microsoft Corporation</organization>

<address>
<postal>
<street>One Microsoft Way</street>
<city>Redmond</city>
<region>WA</region>
<code>98052</code>
<country>US</country>
</postal>

<phone>+1 425 703 1559</phone>
<facsimile>+1 425 936 7329</facsimile>
<email>gwz@acm.org</email>
</address>
</author>

<date year="2000" month="January" />

<abstract>
<t>The Point-to-Point Protocol (PPP)provides a standard method for transporting multi-protocol datagrams over point-to-point links.  PPP defines an extensible Link Control Protocol and a family of Network Control Protocols (NCPs) for establishing and configuring different network-layer protocols.</t>

<t>This document describes version two of Microsoft's PPP CHAP dialect (MS-CHAP-V2).  MS-CHAP-V2 is similar to, but incompatible with, MS-CHAP version one (MS-CHAP-V1, described in. In particular, certain protocol fields have been deleted or reused but with different semantics.  In addition, MS-CHAP-V2 features mutual authentication.</t>

<t>The algorithms used in the generation of various MS-CHAP-V2 protocol fields are described in section 8.  Negotiation and hash generation examples are provided in section 9.</t>
</abstract>
</front>

<seriesInfo value="2759" name="RFC" />
</reference>


<reference target2="reference.RFC.2760.xml" anchor="RFC2760">
<front>
<title>Ongoing TCP Research Related to Satellites</title>
<author fullname="Mark Allman" initials="M." surname="Allman">
<organization>NASA Glenn Research Center/BBN Technologies, Lewis Field</organization>

<address>
<postal>
<street>21000 Brookpark Rd.</street>
<street>MS 54-2</street>
<city>Cleveland</city>
<region>OH</region>
<code>44135</code>
<country>US</country>
</postal>

<email>mallman@grc.nasa.gov</email>
</address>
</author>

<author fullname="Spencer Dawkins" initials="S." surname="Dawkins">
<organization>Nortel</organization>

<address>
<postal>
<street>P.O.Box 833805</street>
<city>Richardson</city>
<region>TX</region>
<code>75083-3805</code>
<country>US</country>
</postal>

<email>Spencer.Dawkins.sdawkins@nt.com</email>
</address>
</author>

<author fullname="Dan Glover" initials="D." surname="Glover">
<organization>NASA Glenn Research Center, Lewis Field</organization>

<address>
<postal>
<street>21000 Brookpark Rd.</street>
<street>MS 3-6</street>
<city>Cleveland</city>
<region>OH</region>
<code>44135</code>
<country>US</country>
</postal>

<email>Daniel.R.Glover@grc.nasa.gov</email>
</address>
</author>

<author fullname="Jim Griner" initials="J." surname="Griner">
<organization>NASA Glenn Research Center, Lewis Field</organization>

<address>
<postal>
<street>21000 Brookpark Rd.</street>
<street>MS 54-2</street>
<city>Cleveland</city>
<region>OH</region>
<code>44135</code>
<country>US</country>
</postal>

<email>jgriner@grc.nasa.gov</email>
</address>
</author>

<author fullname="Diepchi Tran" initials="D." surname="Tran">
<organization>NASA Glenn Research Center, Lewis Field</organization>

<address>
<postal>
<street>21000 Brookpark Rd.</street>
<street>MS 54-2</street>
<city>Cleveland</city>
<region>OH</region>
<code>44135</code>
<country>US</country>
</postal>

<email>dtran@grc.nasa.gov</email>
</address>
</author>

<author fullname="Tom Henderson" initials="T." surname="Henderson">
<organization>University of California at Berkeley</organization>

<address>
<postal>
<street />
<city>Berkeley</city>
<region>CA</region>
<code>94720</code>
<country>US</country>
</postal>

<phone>+1 510 642 8919</phone>
<email>tomh@cs.berkeley.edu</email>
</address>
</author>

<author fullname="John Heidemann" initials="J." surname="Heidemann">
<organization>University of Southern California/Information Sciences Institute</organization>

<address>
<postal>
<street>4676 Admiralty Way</street>
<city>Marina del Rey</city>
<region>CA</region>
<code>90292-6695</code>
<country>US</country>
</postal>

<email>johnh@isi.edu</email>
</address>
</author>

<author fullname="Joe Touch" initials="J." surname="Touch">
<organization>University of Southern California/Information Sciences Institute</organization>

<address>
<postal>
<street>4676 Admiralty Way</street>
<city>Marina del Rey</city>
<region>CA</region>
<code>90292-6601</code>
<country>US</country>
</postal>

<phone>+1 310 448 9151</phone>
<facsimile>+1 310 823 6714</facsimile>
<email>touch@isi.edu</email>
</address>
</author>

<author fullname="Hans Kruse" initials="H." surname="Kruse">
<organization>Ohio University,  J. Warren McClure School of Communication Systems Management</organization>

<address>
<postal>
<street>9 S. College Street</street>
<city>Athens</city>
<region>OH</region>
<code>45701</code>
<country>US</country>
</postal>

<phone>+1 740 593 4891</phone>
<facsimile>+1 740 593 4889</facsimile>
<email>hkruse1@ohiou.edu</email>
</address>
</author>

<author fullname="Shawn Ostermann" initials="S." surname="Ostermann">
<organization>Ohio University, School of Electrical Engineering and Computer Science</organization>

<address>
<postal>
<street>416 Morton Hall</street>
<city>Athens</city>
<region>OH</region>
<code>45701</code>
<country>US</country>
</postal>

<phone>+1 740 593 1234</phone>
<email>ostermann@cs.ohiou.edu</email>
</address>
</author>

<author fullname="Keith Scott" initials="K." surname="Scott">
<organization>The MITRE Corporation</organization>

<address>
<postal>
<street>1820 Dolley Madison Blvd.</street>
<street>M/S W650</street>
<city>McLean</city>
<region>VA</region>
<code>22102-3481</code>
<country>US</country>
</postal>

<email>kscott@mitre.org</email>
</address>
</author>

<author fullname="Jeffrey Semke" initials="J." surname="Semke">
<organization>Pittsburgh Supercomputing Center</organization>

<address>
<postal>
<street>4400 Fifth Ave.</street>
<city>Pittsburgh</city>
<region>PA</region>
<code>15213</code>
<country>US</country>
</postal>

<email>semke@psc.edu</email>
</address>
</author>

<date year="2000" month="February" />

<abstract>
<t>This document outlines possible TCP enhancements that may allow TCP to better utilize the available bandwidth provided by networks containing satellite links.  The algorithms and mechanisms outlined have not been judged to be mature enough to be recommended by the IETF.  The goal of this document is to educate researchers as to the
 current work and progress being done in TCP research related to satellite networks.</t>
</abstract>
</front>

<seriesInfo value="2760" name="RFC" />
</reference>


<reference target2="reference.RFC.2761.xml" anchor="RFC2761">
<front>
<title>Terminology for ATM Benchmarking</title>
<author fullname="Jeffrey Dunn" initials="J." surname="Dunn">
<organization>Advanced Network Consultants, Inc</organization>

<address>
<postal>
<street>4214 Crest Place</street>
<city>Ellicott City</city>
<region>MD</region>
<code>21043</code>
<country>US</country>
</postal>

<phone>+1 410 750 1700</phone>
<email>Jeffrey.Dunn@worldnet.att.net</email>
</address>
</author>

<author fullname="Cynthia Martin" initials="C." surname="Martin">
<organization>Advanced Network Consultants, Inc.</organization>

<address>
<postal>
<street>11241-B Skilift Court</street>
<city>Columbia</city>
<region>MD</region>
<code>21044</code>
<country>US</country>
</postal>

<phone>+1 410 730 6300</phone>
<email>Cynthia.E.Martin@worldnet.att.net</email>
</address>
</author>

<date year="2000" month="February" />

<abstract>
<t>This memo discusses and defines terms associated with performance benchmarking tests and the results of these tests in the context of Asynchronous Transfer Mode (ATM) based switching devices. The terms defined in this memo will be used in addition to terms defined in RFCs 1242, 2285, and 2544. This memo is a product of the Benchmarking
Methodology Working Group (BMWG) of the Internet Engineering Task Force (IETF).</t>
</abstract>
</front>

<seriesInfo value="2761" name="RFC" />
</reference>


<reference target2="reference.RFC.2762.xml" anchor="RFC2762">
<front>
<title abbrev="RTP Sampling">Sampling of the Group Membership in RTP</title>
<author fullname="Jonathan Rosenberg" initials="J." surname="Rosenberg">
<organization>dynamicsoft</organization>

<address>
<postal>
<street>200 Executive Drive</street>
<city>West Orange</city>
<region>NJ</region>
<code>07052</code>
<country>US</country>
</postal>

<email>jdrosen@dynamicsoft.com</email>
</address>
</author>

<author fullname="Henning Schulzrinne" initials="H." surname="Schulzrinne">
<organization>Columbia University</organization>

<address>
<postal>
<street>1214 Amsterdam Ave.</street>
<street>M/S 0401</street>
<city>New York</city>
<region>NY</region>
<code>10027-7003</code>
<country>US</country>
</postal>

<email>schulzrinne@cs.columbia.edu</email>
</address>
</author>

<date year="2000" month="February" />

<abstract>
<t>In large multicast groups, the size of the group membership table maintained by RTP (Real Time Transport Protocol) participants may become unwieldy, particularly for embedded devices with limited memory and processing power. This document discusses mechanisms for sampling of this group membership table in order to reduce the memory
 requirements. Several mechanisms are proposed, and the performance of each is considered.</t>
</abstract>
</front>

<seriesInfo value="2762" name="RFC" />
</reference>


<reference target2="reference.RFC.2763.xml" anchor="RFC2763">
<front>
<title abbrev="Dynamic Hostname">Dynamic Hostname Exchange Mechanism for IS-IS</title>
<author fullname="Naiming Shen" initials="N." surname="Shen">
<organization>Siara Systems, Inc.</organization>

<address>
<postal>
<street>1195 Borregas Avenue</street>
<city>Sunnyvale</city>
<region>CA</region>
<code>94089</code>
<country>US</country>
</postal>

<email>naiming@siara.com</email>
</address>
</author>

<author fullname="Henk Smit" initials="H." surname="Smit">
<organization>Cisco Systems, Inc.</organization>

<address>
<postal>
<street>170 Tasman Drive</street>
<city>San Jose</city>
<region>CA</region>
<code>95134</code>
<country>US</country>
</postal>

<email>hsmit@cisco.com</email>
</address>
</author>

<date year="2000" month="February" />

<abstract>
<t>Currently, there does not exist a simple and dynamic mechanism for routers running IS-IS to learn about symbolic hostnames. This document defines a new TLV which allows the IS-IS routers to flood their name to system ID mapping information across the IS-IS network.</t>
</abstract>
</front>

<seriesInfo value="2763" name="RFC" />
</reference>


<reference target2="reference.RFC.2764.xml" anchor="RFC2764">
<front>
<title abbrev="IP Based Virtual Private Networks">A Framework for IP Based Virtual Private Networks</title>
<author fullname="Bryan Gleeson" initials="B." surname="Gleeson">
<organization>Nortel Networks</organization>

<address>
<postal>
<street>4500 Great America Parkway</street>
<city>Santa Clara</city>
<region>CA</region>
<code>95054</code>
<country>US</country>
</postal>

<phone>+1 408 548 3711</phone>
<email>bgleeson@shastanets.com</email>
</address>
</author>

<author fullname="Juha Heinanen" initials="J." surname="Heinanen">
<organization>Telia Finland, Inc.</organization>

<address>
<postal>
<street>Myyrmaentie 2</street>
<city>Vantaa</city>
<code>01600</code>
<country>FI</country>
</postal>

<phone>+358 3 03944808</phone>
<email>jh@telia.fi</email>
</address>
</author>

<author fullname="Arthur Lin" initials="A." surname="Lin">
<organization>Nortel Networks</organization>

<address>
<postal>
<street>4500 Great America Parkway</street>
<city>Santa Clara</city>
<region>CA</region>
<code>95054</code>
<country>US</country>
</postal>

<phone>+1 408 548 3788</phone>
<email>alin@shastanets.com</email>
</address>
</author>

<author fullname="Grenville Armitage" initials="G." surname="Armitage">
<organization>Bell Labs Research Silicon Valley, Lucent Technologies</organization>

<address>
<postal>
<street>3180 Porter Drive</street>
<city>Palo Alto</city>
<region>CA</region>
<code>94304</code>
<country>US</country>
</postal>

<email>gja@lucent.com</email>
</address>
</author>

<author fullname="Andrew G. Malis" initials="A.G." surname="Malis">
<organization>Lucent Technologies</organization>

<address>
<postal>
<street>1 Robbins Road</street>
<city>Westford</city>
<region>MA</region>
<code>01886</code>
<country>US</country>
</postal>

<phone>+1 978 952 7414</phone>
<email>amalis@lucent.com</email>
</address>
</author>

<date year="2000" month="February" />

<abstract>
<t>This document describes a framework for Virtual Private Networks (VPNs) running across IP backbones.  It discusses the various different types of VPNs, their respective requirements, and proposes specific mechanisms that could be used to implement each type of VPN using existing or proposed specifications.  The objective of this document is to serve as a framework for related protocol development in order to develop the full set of specifications required for widespread deployment of interoperable VPN solutions.</t>
</abstract>
</front>

<seriesInfo value="2764" name="RFC" />
</reference>


<reference target2="reference.RFC.2765.xml" anchor="RFC2765">
<front>
<title abbrev="SIIT">Stateless IP/ICMP Translation Algorithm (SIIT)</title>
<author fullname="Erik Nordmark" initials="E." surname="Nordmark">
<organization>Sun Microsystems, Inc.</organization>

<address>
<postal>
<street>901 San Antonio Road</street>
<city>Palo Alto</city>
<region>CA</region>
<code>94303</code>
<country>US</country>
</postal>

<phone>+1 650 786 5166</phone>
<facsimile>+1 650 786 5896</facsimile>
<email>nordmark@sun.com</email>
</address>
</author>

<date year="2000" month="February" />

<abstract>
<t>This document specifies a transition mechanism algorithm in addition to the mechanisms already specified in. The algorithm translates between IPv4 and IPv6 packet headers (including ICMP headers) in separate translator "boxes" in the network without requiring any per-connection state in those "boxes".  This new
   algorithm can be used as part of a solution that allows IPv6 hosts, which do not have a permanently assigned IPv4 addresses, to communicate with IPv4-only hosts.  The document neither specifies address assignment nor routing to and from the IPv6 hosts when they communicate with the IPv4-only hosts.</t>
</abstract>
</front>

<seriesInfo value="2765" name="RFC" />
</reference>


<reference target2="reference.RFC.2766.xml" anchor="RFC2766">
<front>
<title abbrev="NAT-PT">Network Address Translation - Protocol Translation (NAT-PT)</title>
<author fullname="George Tsirtsis" initials="G." surname="Tsirtsis">
<organization>Internet Futures</organization>

<address>
<postal>
<street>BT Adastral Park</street>
<street>B29 Room 129</street>
<city>Ipswich</city>
<region>England</region>
<code>IP5 3RE</code>
<country>UK</country>
</postal>

<phone>+44 181 8260073</phone>
<facsimile>+44 181 8260073</facsimile>
<email>george.tsirtsis@bt.com</email>
</address>
</author>

<author fullname="Pyda Srisuresh" initials="P." surname="Srisuresh">
<organization>Campio Communications</organization>

<address>
<postal>
<street>630 Alder Drive</street>
<city>Milpitas</city>
<region>CA</region>
<code>95035</code>
<country>US</country>
</postal>

<phone>+1 408 519 3849</phone>
<email>srisuresh@yahoo.com</email>
</address>
</author>

<date year="2000" month="February" />

<abstract>
<t>This document specifies an IPv4-to-IPv6 transition mechanism, in addition to those already specified in. This solution attempts to provide transparent routing, as defined in, to end-nodes in V6 realm trying to communicate with end-nodes in V4 realm and vice versa. This is achieved using a combination of Network Address Translation and Protocol Translation. The scheme described does not mandate dual-stacks (i.e., IPv4 as well as V6 protocol support) or special purpose routing requirements (such as requiring tunneling support) on end nodes. This scheme is based on a combination of address translation theme as described inand V6/V4 protocol translation theme as described in.</t>
</abstract>
</front>

<seriesInfo value="2766" name="RFC" />
</reference>


<reference target2="reference.RFC.2767.xml" anchor="RFC2767">
<front>
<title abbrev="Dual Stack Hosts using BIS">Dual Stack Hosts using the "Bump-In-the-Stack" Technique (BIS)</title>
<author fullname="Kazuaki Tsuchiya" initials="K." surname="Tsuchiya">
<organization>Hitachi, Ltd.,  Enterprise Server Division</organization>

<address>
<postal>
<street>810 Shimoimaizumi</street>
<city>Ebina-shi</city>
<region>Kanagawa-ken</region>
<code>243-0435</code>
<country>JP</country>
</postal>

<phone>+81 462 322121</phone>
<facsimile>+81 462 358324</facsimile>
<email>tsuchi@ebina.hitachi.co.jp</email>
</address>
</author>

<author fullname="Hidemitsu HIGUCHI" initials="H." surname="HIGUCHI">
<organization>Hitachi, Ltd.,  Enterprise Server Division</organization>

<address>
<postal>
<street>810 Shimoimaizumi</street>
<city>Ebina-shi</city>
<region>Kanagawa-ken</region>
<code>243-0435</code>
<country>JP</country>
</postal>

<phone>+81 462 322121</phone>
<facsimile>+81 462 358324</facsimile>
<email>h-higuti@ebina.hitachi.co.jp</email>
</address>
</author>

<author fullname="Yoshifumi Atarashi" initials="Y." surname="Atarashi">
<organization>Hitachi, Ltd.,  Enterprise Server Division</organization>

<address>
<postal>
<street>810 Shimoimaizumi</street>
<city>Ebina-shi</city>
<region>Kanagawa-ken</region>
<code>243-0435</code>
<country>JP</country>
</postal>

<phone>+81 462 322121</phone>
<facsimile>+81 462 358324</facsimile>
<email>atarashi@ebina.hitachi.co.jp</email>
</address>
</author>

<date year="2000" month="February" />

<abstract>
<t>In the especially initial stage of the transition from IPv4 to IPv6, it is hard to provide a complete set of IPv6 applications.  This memo proposes a mechanism of dual stack hosts using the technique called "Bump-in-the-Stack" in the IP security area. The mechanism allows the hosts to communicate with other IPv6 hosts using existing IPv4 applications.</t>
</abstract>
</front>

<seriesInfo value="2767" name="RFC" />
</reference>


<reference target2="reference.RFC.2768.xml" anchor="RFC2768">
<front>
<title abbrev="A Report of a Workshop on Middleware">Network Policy and Services: A Report of a Workshop on Middleware</title>
<author fullname="Bob Aiken" initials="B." surname="Aiken">
<organization>Cisco Systems, Inc.</organization>

<address>
<postal>
<street>6519 Debold Rd.</street>
<city>Sabillasville</city>
<region>MD</region>
<code>21780</code>
<country>US</country>
</postal>

<phone>+1 301 271 2919</phone>
<email>raiken@cisco.com</email>
</address>
</author>

<author fullname="John Strassner" initials="J." surname="Strassner">
<organization>Cisco Systems, Inc.</organization>

<address>
<postal>
<street>170 West Tasman Drive</street>
<city>San Jose</city>
<region>CA</region>
<code>95134</code>
<country>US</country>
</postal>

<phone>+1 408 527 1069</phone>
<email>johns@cisco.com</email>
</address>
</author>

<author fullname="Brian E. Carpenter" initials="B.E." surname="Carpenter">
<organization>IBM United Kingdom Laboratories</organization>

<address>
<postal>
<street>MP 185</street>
<street>Hursley Park</street>
<city>Winchester</city>
<region>Hampshire</region>
<code>SO21 2JN</code>
<country>UK</country>
</postal>

<email>brian@hursley.ibm.com</email>
</address>
</author>

<author fullname="Ian Foster" initials="I." surname="Foster">
<organization>The University of Chicago,  Argonne National Laboratory</organization>

<address>
<postal>
<street />
<city>Argonne</city>
<region>IL</region>
<code>60439</code>
<country>US</country>
</postal>

<phone>+1 630 252 4619</phone>
<email>foster@mcs.anl.gov</email>
</address>
</author>

<author fullname="Clifford Lynch" initials="C." surname="Lynch">
<organization>Coalition for Networked Information</organization>

<address>
<postal>
<street>21 Dupont Circle</street>
<city>Washington</city>
<region>DC</region>
<code>20036</code>
<country>US</country>
</postal>

<phone>+1 202 296 5098</phone>
<email>cliff@cni.org</email>
</address>
</author>

<author fullname="Joe Mambretti" initials="J." surname="Mambretti">
<organization>Northwestern University, International Center for Advanced Internet Research</organization>

<address>
<postal>
<street>1890 Maple</street>
<street>Suite 150</street>
<city>Evanston</city>
<region>IL</region>
<code>60201</code>
<country>US</country>
</postal>

<phone>+1 847 467 3911</phone>
<email>j-mambretti@nwu.edu</email>
</address>
</author>

<author fullname="Reagan Moore" initials="R." surname="Moore">
<organization>University of California, San Diego</organization>

<address>
<postal>
<street>9500 Gilman Drive, NPACI/SDSC</street>
<street>MC 0505</street>
<city>La Jolla</city>
<region>CA</region>
<code>92093-0505</code>
<country>US</country>
</postal>

<email>moore@sdsc.edu</email>
</address>
</author>

<author fullname="Benjamin Teitelbaum" initials="B." surname="Teitelbaum">
<organization>Advanced Networks &amp; Services, Inc.</organization>

<address>
<email>ben@internet2.edu</email>
</address>
</author>

<date year="2000" month="February" />

<abstract>
<t>An ad hoc middleware workshop was held at the International Center for Advanced Internet Research in December 1998.  The Workshop was organized and sponsored by Cisco, Northwestern University's International Center for Advanced Internet Research (iCAIR), IBM, and the National Science Foundation (NSF). The goal of the workshop was
   to identify existing middleware services that could be leveraged for new capabilities as well as identifying additional middleware services requiring research and development.  The workshop participants discussed the definition of middleware in general, examined the applications perspective, detailed underlying network transport capabilities relevant to middleware services, and then covered various specific examples of middleware components. These included APIs, authentication, authorization, and accounting (AAA)  issues, policy framework, directories, resource management, networked information discovery and retrieval services, quality of service, security, and operational tools.  The need for a more organized framework for middleware R&amp;D was recognized, and a list of specific topics needing further work was identified.</t>
</abstract>
</front>

<seriesInfo value="2768" name="RFC" />
</reference>


<reference target2="reference.RFC.2769.xml" anchor="RFC2769">
<front>
<title>Routing Policy System Replication</title>
<author fullname="Curtis Villamizar" initials="C." surname="Villamizar">
<organization>Avici Systems</organization>

<address>
<email>curtis@avici.com</email>
</address>
</author>

<author fullname="Cengiz Alaettinoglu" initials="C." surname="Alaettinoglu">
<organization>ISI</organization>

<address>
<email>cengiz@ISI.EDU</email>
</address>
</author>

<author fullname="Ramesh Govindan" initials="R." surname="Govindan">
<organization>ISI</organization>

<address>
<email>govindan@ISI.EDU</email>
</address>
</author>

<author fullname="David M. Meyer" initials="D.M." surname="Meyer">
<organization>Cisco</organization>

<address>
<email>dmm@cisco.com</email>
</address>
</author>

<date year="2000" month="February" />

<abstract>
<t>The RIPE database specifications and RPSL define languages used as the basis for representing information in a routing policy system.  A repository for routing policy system information is known as a routing registry.  A routing registry provides a means of exchanging information needed to address many issues of importance to the operation of the Internet.  The implementation and deployment of a routing policy system must maintain some degree of integrity to be of any use.  The Routing Policy System Security RFCaddresses the need to assure integrity of the data by proposing an authentication and authorization model.  This document addresses the need to distribute data over multiple repositories and delegate authority for data subsets to other repositories without compromising the authorization model established in Routing Policy System Security RFC.</t>
</abstract>
</front>

<seriesInfo value="2769" name="RFC" />
</reference>


<reference target2="reference.RFC.2770.xml" anchor="RFC2770">
<front>
<title>GLOP Addressing in 233/8</title>
<author fullname="David Meyer" initials="D." surname="Meyer">
<organization>Cisco Systems, Inc.</organization>

<address>
<postal>
<street>170 W. Tasman Drive</street>
<city>San Jose</city>
<region>CA</region>
<code>95134-1706</code>
<country>US</country>
</postal>

<email>dmm@cisco.com</email>
</address>
</author>

<author fullname="Peter Lothberg" initials="P." surname="Lothberg">
<organization>Sprint</organization>

<address>
<postal>
<street>12502 Sunrise Valley Drive</street>
<street>VARESA0104</street>
<city>Reston</city>
<region>VA</region>
<code>20196</code>
<country>US</country>
</postal>

<email>roll@sprint.net</email>
</address>
</author>

<date year="2000" month="February" />

<abstract>
<t>This describes an experimental policy for use of the class D address space using 233/8 as the experimental statically assigned subset of the class D address space. This new experimental allocation is in addition to those described on [IANA] (e.g.).</t>

<t>This memo is a product of the Multicast Deployment Working Group (MBONED) in the Operations and Management Area of the Internet Engineering Task Force. Submit comments to mboned@ns.uoregon.edu or the authors.</t>
</abstract>
</front>

<seriesInfo value="2770" name="RFC" />
</reference>


<reference target2="reference.RFC.2771.xml" anchor="RFC2771">
<front>
<title>An Abstract API for Multicast Address Allocation</title>
<author fullname="Ross Finlayson" initials="R." surname="Finlayson">
<organization>Live Networks, Inc. (LIVE.COM)</organization>

<address>
<email>finlayson@live.com</email>
<uri>http://www.live.com/</uri>
</address>
</author>

<date year="2000" month="February" />

<abstract>
<t>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.</t>

<t>Additional documents (not necessarily products of the IETF) would describe concrete APIs for this service.</t>
</abstract>
</front>

<seriesInfo value="2771" name="RFC" />
</reference>


<reference target2="reference.RFC.2772.xml" anchor="RFC2772">
<front>
<title>6Bone Backbone Routing Guidelines</title>
<author fullname="Rob Rockell" initials="R." surname="Rockell">
<organization>Sprint</organization>

<address>
<email>rrockell@sprint.net</email>
</address>
</author>

<author fullname="Bob Fink" initials="B." surname="Fink">
<organization>ESnet</organization>

<address>
<email>fink@es.net</email>
</address>
</author>

<date year="2000" month="February" />

<abstract>
<t>The 6Bone is an Ipv6 testbed to assist in the evolution and deployment of IPv6. Because of this, it is important that the core backbone of the IPv6 network maintain stability, and that all operators have a common set of rules and guidelines by which to deploy IPv6 routing equipment.</t>

<t>This document provides a set of guidelines for all 6bone routing equipment operators to use as a reference for efficient and stable deployment of 6bone routing systems. As the complexity of the 6Bone grows,the adherence to a common set of rules becomes increasingly important in order for an efficient, scalable backbone to exist.</t>
</abstract>
</front>

<seriesInfo value="2772" name="RFC" />
</reference>


<reference target2="reference.RFC.2773.xml" anchor="RFC2773">
<front>
<title>Encryption using KEA and SKIPJACK</title>
<author fullname="Russell Housley" initials="R." surname="Housley">
<organization>SPYRUS</organization>

<address>
<postal>
<street>381 Elden Street</street>
<street>Suite 1120</street>
<city>Herndon</city>
<region>VA</region>
<code>20170</code>
<country>US</country>
</postal>

<phone>+1 703 707 0696</phone>
<email>housley@spyrus.com</email>
</address>
</author>

<author fullname="Peter Yee" initials="P." surname="Yee">
<organization>SPYRUS</organization>

<address>
<postal>
<street>5303 Betsy Ross Drive</street>
<city>Santa Clara</city>
<region>CA</region>
<code>95054</code>
<country>US</country>
</postal>

<phone>+1 408 327 1901</phone>
<email>yee@spyrus.com</email>
</address>
</author>

<date year="2000" month="February" />

<abstract>
<t>This document defines a method to encrypt a file transfer using the FTP specification STD 9, RFC 959, "File Transfer Protocol (FTP)", (October 1985)and RFC 2228, "FTP Security Extensions" (October 1997). This method will use the Key Exchange Algorithm (KEA) to give mutual authentication and establish the data encryption keys.  SKIPJACK is used to encrypt file data and the FTP command channel.</t>
</abstract>
</front>

<seriesInfo value="2773" name="RFC" />
</reference>


<reference target2="reference.RFC.2774.xml" anchor="RFC2774">
<front>
<title>An HTTP Extension Framework</title>
<author fullname="Henrik Frystyk Nielsen" initials="H." surname="Nielsen">
<organization abbrev="Microsoft">Microsoft Corporation</organization>

<address>
<postal>
<street>1 Microsoft Way</street>
<city>Redmond</city>
<region>WA</region>
<code>98052</code>
<country>USA</country>
</postal>

<email>frystyk@microsoft.com</email>
</address>
</author>

<author fullname="Paul J. Leach" initials="P." surname="Leach">
<organization abbrev="Microsoft">Microsoft Corporation</organization>

<address>
<postal>
<street>1 Microsoft Way</street>
<city>Redmond</city>
<region>WA</region>
<code>98052</code>
<country>USA</country>
</postal>

<email>paulle@microsoft.com</email>
</address>
</author>

<author fullname="Scott Lawrence" initials="S." surname="Lawrence">
<organization abbrev="Agranat Systems">Agranat Systems, Inc.</organization>

<address>
<postal>
<street>5 Clocktower Place, Suite 400</street>
<city>Maynard</city>
<region>MA</region>
<code>01754</code>
<country>USA</country>
</postal>

<email>lawrence@agranat.com</email>
</address>
</author>

<date year="2000" month="February" />

<abstract>
<t>
   A wide range of applications have proposed various extensions of the
   HTTP protocol. Current efforts span an enormous range, including
   distributed authoring, collaboration, printing, and remote procedure
   call mechanisms. These HTTP extensions are not coordinated, since
   there has been no standard framework for defining extensions and
   thus, separation of concerns. This document describes a generic
   extension mechanism for HTTP, which is designed to address the
   tension between private agreement and public specification and to
   accommodate extension of applications using HTTP clients, servers,
   and proxies.  The proposal associates each extension with a globally
   unique identifier, and uses HTTP header fields to carry the extension
   identifier and related information between the parties involved in
   the extended communication.
  </t>
</abstract>

<note title="IESG Note">
<t>
   This document was originally requested for Proposed Standard status.
   However, due to mixed reviews during Last Call and within the HTTP
   working group, it is being published as an Experimental document.
   This is not necessarily an indication of technical flaws in the
   document; rather, there is a more general concern about whether this
   document actually represents community consensus regarding the
   evolution of HTTP.  Additional study and discussion are needed before
   this can be determined.
</t>

<t>
   Note also that when HTTP is used as a substrate for other protocols,
   it may be necessary or appropriate to use other extension mechanisms
   in addition to, or instead of, those defined here.  This document
   should therefore not be taken as a blueprint for adding extensions to
   HTTP, but it defines mechanisms that might be useful in such
   circumstances.
  </t>
</note>
</front>

<seriesInfo value="2774" name="RFC" />
<format octets="46531" type="HTML" target="http://xml.resource.org/public/rfc/html/rfc2774.html" />
<format octets="54284" type="XML" target="http://xml.resource.org/public/rfc/xml/rfc2774.xml" />
</reference>


<reference target2="reference.RFC.2775.xml" anchor="RFC2775">
<front>
<title>Internet Transparency</title>
<author fullname="Brian E. Carpenter" initials="B.E." surname="Carpenter">
<organization>IBM c/o iCAIR</organization>

<address>
<postal>
<street>1890 Maple Avenue</street>
<street>Suite 150</street>
<city>Evanston</city>
<region>IL</region>
<code>60201</code>
<country>US</country>
</postal>

<email>brian@icair.org</email>
</address>
</author>

<date year="2000" month="February" />

<abstract>
<t>This document describes the current state of the Internet from the architectural viewpoint, concentrating on issues of end-to-end connectivity and transparency. It concludes with a summary of some major architectural alternatives facing the Internet network layer.</t>

<t>This document was used as input to the IAB workshop on the future of the network layer held in July 1999. For this reason, it does not claim to be complete and definitive, and it refrains from making recommendations.</t>
</abstract>
</front>

<seriesInfo value="2775" name="RFC" />
</reference>


<reference target2="reference.RFC.2776.xml" anchor="RFC2776">
<front>
<title abbrev="MZAP">Multicast-Scope Zone Announcement Protocol (MZAP)</title>
<author fullname="Mark Handley" initials="M." surname="Handley">
<organization>AT&amp;T Center for Internet Research at ICSI</organization>

<address>
<postal>
<street>1947 Center St</street>
<street>Suite 600</street>
<city>Berkeley</city>
<region>CA</region>
<code>94704</code>
<country>US</country>
</postal>

<email>mjh@aciri.org</email>
</address>
</author>

<author fullname="David Thaler" initials="D." surname="Thaler">
<organization>Microsoft</organization>

<address>
<postal>
<street>One Microsoft Way</street>
<city>Redmond</city>
<region>WA</region>
<code>98052</code>
<country>US</country>
</postal>

<email>dthaler@microsoft.com</email>
</address>
</author>

<author fullname="Roger Kermode" initials="R." surname="Kermode">
<organization>Motorola Australian Research Centre</organization>

<address>
<postal>
<street>12 Lord St</street>
<city>Botany</city>
<region>NSW</region>
<code>2019</code>
<country>AU</country>
</postal>

<email>Roger.Kermode@motorola.com</email>
</address>
</author>

<date year="2000" month="February" />

<abstract>
<t>This document defines a protocol, the Multicast-Scope Zone Announcement Protocol (MZAP), for discovering the multicast administrative scope zones that are relevant at a particular location.  MZAP also provides mechanisms whereby common misconfigurations of administrative scope zones can be discovered.</t>
</abstract>
</front>

<seriesInfo value="2776" name="RFC" />
</reference>


<reference target2="reference.RFC.2777.xml" anchor="RFC2777">
<front>
<title abbrev="Verifiable Random Selection">Publicly Verifiable Nomcom Random Selection</title>
<author fullname="Donald E. Eastlake, 3rd" initials="D." surname="Eastlake">
<organization>Motorola</organization>

<address>
<postal>
<street>65 Shindegan Hill Road</street>
<street>RR #1</street>
<city>Carmel</city>
<region>NY</region>
<code>10512</code>
<country>US</country>
</postal>

<phone>+1 914 276 2668</phone>
<facsimile>+1 508 261 4447</facsimile>
<email>Donald.Eastlake@motorola.com</email>
</address>
</author>

<date year="2000" month="February" />

<abstract>
<t>This document describes a method for making random selections in such a way that the unbiased nature of the choice is publicly verifiable. As an example, the selection of the voting members of the IETF Nominations Committee from the pool of eligible volunteers is used. Similar techniques would be applicable to other cases.</t>
</abstract>
</front>

<seriesInfo value="2777" name="RFC" />
</reference>


<reference target2="reference.RFC.2778.xml" anchor="RFC2778">
<front>
<title>A Model for Presence and Instant Messaging</title>
<author fullname="Mark Day" initials="M." surname="Day">
<organization>SightPath, Inc.</organization>

<address>
<postal>
<street>135 Beaver Street</street>
<city>Waltham</city>
<region>MA</region>
<code>02452</code>
<country>US</country>
</postal>

<email>mday@alum.mit.edu</email>
</address>
</author>

<author fullname="Jonathan Rosenberg" initials="J." surname="Rosenberg">
<organization>dynamicsoft</organization>

<address>
<postal>
<street>200 Executive Drive</street>
<street>Suite 120</street>
<city>West Orange</city>
<region>NJ</region>
<code>07046</code>
<country>US</country>
</postal>

<email>jdrosen@dynamicsoft.com</email>
</address>
</author>

<author fullname="Hiroyasu Sugano" initials="H." surname="Sugano">
<organization>Fujitsu Laboratories Ltd.</organization>

<address>
<postal>
<street>64 Nishiwaki</street>
<street>Ohkubo-cho</street>
<city>Akashi</city>
<region />
<code>674-8555</code>
<country>JP</country>
</postal>

<email>suga@flab.fujitsu.co.jp</email>
</address>
</author>

<date year="2000" month="February" />

<abstract>
<t>This document defines an abstract model for a presence and instant messaging system. It defines the various entities involved, defines terminology, and outlines the services provided by the system. The goal is to provide a common vocabulary for further work on requirements for protocols and markup for presence and instant messaging.</t>
</abstract>
</front>

<seriesInfo value="2778" name="RFC" />
</reference>


<reference target2="reference.RFC.2779.xml" anchor="RFC2779">
<front>
<title abbrev="Instant Messaging/Presence Protocol">Instant Messaging / Presence Protocol Requirements</title>
<author fullname="Mark Day" initials="M." surname="Day">
<organization>SightPath, Inc.</organization>

<address>
<postal>
<street>135 Beaver Street</street>
<city>Waltham</city>
<region>MA</region>
<code>02452</code>
<country>US</country>
</postal>

<email>mday@alum.mit.edu</email>
</address>
</author>

<author fullname="Sonu Aggarwal" initials="S." surname="Aggarwal">
<organization>Microsoft Corporation</organization>

<address>
<postal>
<street>One Microsoft Way</street>
<city>Redmond</city>
<region>WA</region>
<code>98052</code>
<country>US</country>
</postal>

<email>sonuag@microsoft.com</email>
</address>
</author>

<author fullname="Gordon Mohr" initials="G." surname="Mohr">
<organization />

<address>
<email>gojomo@usa.net</email>
</address>
</author>

<author fullname="Jesse Vincent" initials="J." surname="Vincent">
<organization>Into Networks, Inc.</organization>

<address>
<postal>
<street>150 Cambridgepark Drive</street>
<city>Cambridge</city>
<region>MA</region>
<code>02140</code>
<country>US</country>
</postal>

<email>jesse@intonet.com</email>
</address>
</author>

<date year="2000" month="February" />

<abstract>
<t>Presence and Instant Messaging have recently emerged as a new medium of communications over the Internet.  Presence is a means for finding, retrieving, and subscribing to changes in the presence information (e.g. "online" or "offline") of other users. Instant messaging is a means for sending small, simple messages that are delivered immediately to online users.</t>

<t>Applications of presence and instant messaging currently use independent, non-standard and non-interoperable protocols developed by various vendors.  The goal of the Instant Messaging and Presence Protocol (IMPP) Working Group is to define a standard protocol so that independently developed applications of instant messaging and/or   presence can interoperate across the Internet. This document defines a minimal set of requirements that IMPP must meet.</t>
</abstract>
</front>

<seriesInfo value="2779" name="RFC" />
<format octets="47420" type="TXT" target="ftp://ftp.isi.edu/in-notes/rfc2779.txt" />
</reference>


<reference target2="reference.RFC.2780.xml" anchor="RFC2780">
<front>
<title abbrev="IANA Assignments">IANA Allocation Guidelines For Values In the Internet Protocol and Related Headers</title>
<author fullname="Scott Bradner" initials="S." surname="Bradner">
<organization>Harvard University</organization>

<address>
<postal>
<street />
<city>Cambridge</city>
<region>MA</region>
<code>02138</code>
<country>US</country>
</postal>

<phone>+1 617 495 3864</phone>
<email>sob@harvard.edu</email>
</address>
</author>

<author fullname="Vern Paxson" initials="V." surname="Paxson">
<organization>ACIRI / ICSI</organization>

<address>
<postal>
<street>1947 Center Street</street>
<street>Suite 600</street>
<city>Berkeley</city>
<region>CA</region>
<code>94704-1198</code>
<country>US</country>
</postal>

<phone>+1 510 666 2882</phone>
<email>vern@aciri.org</email>
</address>
</author>

<date year="2000" month="March" />

<abstract>
<t>This memo provides guidance for the IANA to use in assigning parameters for fields in the IPv4, IPv6, ICMP, UDP and TCP protocol headers.</t>
</abstract>
</front>

<seriesInfo value="37" name="BCP" />
<seriesInfo value="2780" name="RFC" />
</reference>


<reference target2="reference.RFC.2781.xml" anchor="RFC2781">
<front>
<title>UTF-16, an encoding of ISO 10646</title>
<author fullname="Paul Hoffman" initials="P." surname="Hoffman">
<organization>Internet Mail Consortium</organization>

<address>
<postal>
<street>127 Segre Place</street>
<city>Santa Cruz</city>
<region>CA</region>
<code>95060</code>
<country>US</country>
</postal>

<email>phoffman@imc.org</email>
</address>
</author>

<author fullname="Francois Yergeau" initials="F." surname="Yergeau">
<organization>Alis Technologies</organization>

<address>
<postal>
<street>100, boul. Alexis-Nihon</street>
<street>Suite 600</street>
<city>Montreal</city>
<region>Quebec</region>
<code>H4M 2P2</code>
<country>CA</country>
</postal>

<email>fyergeau@alis.com</email>
</address>
</author>

<date year="2000" month="February" />

<abstract>
<t>This document describes the UTF-16 encoding of Unicode/ISO-10646, addresses the issues of serializing UTF-16 as an octet stream for transmission over the Internet, discusses MIME charset naming as described in [CHARSET-REG], and contains the registration for three MIME charset parameter values: UTF-16BE (big-endian), UTF-16LE (little-endian), and UTF-16.</t>
</abstract>
</front>

<seriesInfo value="2781" name="RFC" />
</reference>


<reference target2="reference.RFC.2782.xml" anchor="RFC2782">
<front>
<title abbrev="DNS SRV RR">A DNS RR for specifying the location of services (DNS SRV)</title>
<author fullname="Arnt Gulbrandsen" initials="A." surname="Gulbrandsen">
<organization>Troll Tech</organization>

<address>
<postal>
<street>Waldemar Thranes gate 98B</street>
<city>Oslo</city>
<region />
<code>N-0175</code>
<country>NO</country>
</postal>

<phone>+47 22 806390</phone>
<facsimile>+47 22 806380</facsimile>
<email>arnt@troll.no</email>
</address>
</author>

<author fullname="Paul Vixie" initials="P." surname="Vixie">
<organization>Internet Software Consortium</organization>

<address>
<postal>
<street>950 Charter Street</street>
<city>Redwood City</city>
<region>CA</region>
<code>94063</code>
<country>US</country>
</postal>

<phone>+1 650 779 7001</phone>
</address>
</author>

<author fullname="Levon Esibov" initials="L." surname="Esibov">
<organization>Microsoft Corporation</organization>

<address>
<postal>
<street>One Microsoft Way</street>
<city>Redmond</city>
<region>WA</region>
<code>98052</code>
<country>US</country>
</postal>

<email>levone@microsoft.com</email>
</address>
</author>

<date year="2000" month="February" />

<abstract>
<t>This document describes a DNS RR which specifies the location of the
   server(s) for a specific protocol and domain.</t>
</abstract>
</front>

<seriesInfo value="2782" name="RFC" />
</reference>


<reference target2="reference.RFC.2783.xml" anchor="RFC2783">
<front>
<title abbrev="Pulse-Per-Second API">Pulse-Per-Second API for UNIX-like Operating Systems, Version 1.0</title>
<author fullname="Jeffrey C. Mogul" initials="J." surname="Mogul">
<organization>Compaq Computer Corporation, Western Research Laboratory</organization>

<address>
<postal>
<street>250 University Avenue</street>
<city>Palo Alto</city>
<region>CA</region>
<code>94301</code>
<country>US</country>
</postal>

<phone>+1 650 617 3304</phone>
<email>mogul@wrl.dec.com</email>
</address>
</author>

<author fullname="David L. Mills" initials="D." surname="Mills">
<organization>University of Delaware, Electrical and Computer Engineering Department</organization>

<address>
<postal>
<street />
<city>Newark</city>
<region>DE</region>
<code>19716</code>
<country>US</country>
</postal>

<phone>+1 302 831 8247</phone>
<email>mills@udel.edu</email>
</address>
</author>

<author fullname="Jan Brittenson" initials="J." surname="Brittenson">
<organization>Sun Microsystems, Inc.</organization>

<address>
<postal>
<street>901 San Antonio Rd  M/S MPK17-202</street>
<city>Palo Alto</city>
<region>CA</region>
<code>94303</code>
<country>US</country>
</postal>

<email>Jan.Brittenson@Eng.Sun.COM</email>
</address>
</author>

<author fullname="Jonathan Stone" initials="J." surname="Stone">
<organization>Stanford Distributed Systems Group</organization>

<address>
<postal>
<street />
<city>Stanford</city>
<region>CA</region>
<code>94305</code>
<country>US</country>
</postal>

<phone>+1 650 723 2513</phone>
<email>jonathan@dsg.stanford.edu</email>
</address>
</author>

<author fullname="Ulrich Windl" initials="U." surname="Windl">
<organization>Universitaet Regensburg, Klinikum</organization>

<address>
<postal>
<street />
<city />
<region />
<code />
<country>DE</country>
</postal>

<email>ulrich.windl@rz.uni-regensburg.de</email>
</address>
</author>

<date year="2000" month="March" />

<abstract>
<t>RFC 1589 describes a UNIX kernel implementation model for high-precision time-keeping.  This model is meant for use in conjunction with the Network Time Protocol (NTP, RFC 1305), or similar time synchronization protocols.  One aspect of this model is an accurate interface to the high-accuracy, one pulse-per-second (PPS) output typically available from precise time sources (such as a GPS or GOES receiver).  RFC 1589 did not define an API for managing the PPS facility, leaving implementors without a portable means for using PPS sources.  This document specifies such an API.</t>
</abstract>
</front>

<seriesInfo value="2783" name="RFC" />
</reference>


<reference target2="reference.RFC.2784.xml" anchor="RFC2784">
<front>
<title abbrev="Generic Routing Encapsulation">Generic Routing Encapsulation (GRE)</title>
<author fullname="Dino Farinacci" initials="D." surname="Farinacci">
<organization>Procket Networks</organization>

<address>
<postal>
<street>3850 No. First St.</street>
<street>Ste. C</street>
<city>San Jose</city>
<region>CA</region>
<code>95134</code>
<country>US</country>
</postal>

<email>dino@procket.com</email>
</address>
</author>

<author fullname="Tony Li" initials="T." surname="Li">
<organization>Procket Networks</organization>

<address>
<postal>
<street>3850 No. First St.</street>
<street>Ste. C</street>
<city>San Jose</city>
<region>CA</region>
<code>95134</code>
<country>US</country>
</postal>

<phone>+1 408 954 7903</phone>
<facsimile>+1 408 987 6166</facsimile>
<email>tony1@home.net</email>
</address>
</author>

<author fullname="Stan Hanks" initials="S." surname="Hanks">
<organization>Enron Communications</organization>

<address>
<email>stan_hanks@enron.net</email>
</address>
</author>

<author fullname="David Meyer" initials="D." surname="Meyer">
<organization>Cisco Systems, Inc.</organization>

<address>
<postal>
<street>170 Tasman Drive</street>
<city>San Jose</city>
<region>CA</region>
<code>95134</code>
<country>US</country>
</postal>

<email>dmm@cisco.com</email>
</address>
</author>

<author fullname="Paul Traina" initials="P." surname="Traina">
<organization>Juniper Networks</organization>

<address>
<email>pst@juniper.net</email>
</address>
</author>

<date year="2000" month="March" />

<abstract>
<t>This document specifies a protocol for encapsulation of an arbitrary network layer protocol over another arbitrary network layer protocol.</t>
</abstract>
</front>

<seriesInfo value="2784" name="RFC" />
</reference>


<reference target2="reference.RFC.2785.xml" anchor="RFC2785">
<front>
<title abbrev="Methods for Avoiding Small-Subgroup  Attacks">Methods for Avoiding the "Small-Subgroup" Attacks on the Diffie-Hellman Key Agreement Method for S/MIME</title>
<author fullname="Robert Zuccherato" initials="R." surname="Zuccherato">
<organization>Entrust Technologies</organization>

<address>
<postal>
<street>750 Heron Road</street>
<city>Ottawa</city>
<region>Ontario</region>
<code>K1V 1A7</code>
<country>CA</country>
</postal>

<email>robert.zuccherato@entrust.com</email>
</address>
</author>

<date year="2000" month="March" />

<abstract>
<t>In some circumstances the use of the Diffie-Hellman key agreement scheme in a prime order subgroup of a large prime p is vulnerable to certain attacks known as "small-subgroup" attacks.  Methods exist, however, to prevent these attacks.  This document will describe the situations relevant to implementations of S/MIME version 3 in which protection is necessary and the methods that can be used to prevent these attacks.</t>
</abstract>
</front>

<seriesInfo value="2785" name="RFC" />
</reference>


<reference target2="reference.RFC.2786.xml" anchor="RFC2786">
<front>
<title abbrev="Diffie-Helman USM Key">Diffie-Helman USM Key Management Information Base and Textual Convention</title>
<author fullname="Michael C. St.Johns" initials="M." surname="St.Johns">
<organization>Excite@Home</organization>

<address>
<postal>
<street>450 Broadway</street>
<city>Redwood City</city>
<region>CA</region>
<code>94063</code>
<country>US</country>
</postal>

<phone>+1 650 556 5368</phone>
<email>stjohns@corp.home.net</email>
</address>
</author>

<date year="2000" month="March" />

<abstract>
<t>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 a textual convention for doing Diffie-Helman key agreement key exchanges and a set of objects which extend the usmUserTable to permit the use of a DH key exchange in addition to the key change method described in. In otherwords, this MIB adds the possibility of forward secrecy to the USM model.  It also defines a set of objects that can be used to kick start security on an SNMPv3 agent when the out of band path is authenticated, but not necessarily private or confidential.</t>

<t>The KeyChange textual convention described inpermits secure key changes, but has the property that if a third-party has knowledge of the original key (e.g. if the agent was manufactured with a standard default key) and could capture all SNMP exchanges, the third-party would know the new key.  The Diffie-Helman key change described here</t>

<t>limits knowledge of the new key to the agent and the manager making the change.  In otherwords, this process adds forward secrecy to the key change process.</t>

<t>The recommendation inis that the usmUserTable be populated out of band - e.g. not via SNMP.  If the number of agents to be configured is small, this can be done via a console port and manually.  If the number of agents is large, as is the case for a cable modem system, the manual approach doesn't scale well.  The    combination of the two mechanisms specified here - the DH key change mechanism, and the DH key ignition mechanism - allows managable use of SNMPv3 USM in a system of millions of devices.</t>

<t>This memo specifies a MIB module in a manner that is compliant to the SNMP SMIv2,,.  The set of objects is consistent with the SNMP framework and existing SNMP standards and is intended for use with the SNMPv3 User Security Model MIB and other security related MIBs.</t>

<t>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.</t>

<t>This memo is a private submission by the author, but is applicable to the SNMPv3 working group within the Internet Engineering Task Force. Comments are solicited and should be addressed to the the author.</t>
</abstract>
</front>

<seriesInfo value="2786" name="RFC" />
</reference>


<reference target2="reference.RFC.2787.xml" anchor="RFC2787">
<front>
<title abbrev="VRRP MIB Management Objects">Definitions of Managed Objects for the Virtual Router Redundancy Protocol</title>
<author fullname="Brian R. Jewell" initials="B." surname="Jewell">
<organization>Copper Mountain Networks, Inc.</organization>

<address>
<postal>
<street>2470 Embarcadero Way</street>
<city>Palo Alto</city>
<region>CA</region>
<code>94303</code>
<country>US</country>
</postal>

<phone>+1 650 687 3367</phone>
<email>bjewell@coppermountain.com</email>
</address>
</author>

<author fullname="David Chuang" initials="D." surname="Chuang">
<organization>CoSine Communications</organization>

<address>
<postal>
<street>1200 Bridge Parkway</street>
<city>Redwood City</city>
<region>CA</region>
<code>94065</code>
<country>US</country>
</postal>

<phone>+1 650 628 4850</phone>
<email>david_chuang@cosinecom.com</email>
</address>
</author>

<date year="2000" month="March" />

<abstract>
<t>This specification defines an extension to the Management Information Base (MIB) for use with SNMP-based network management.  In particular, it defines objects for configuring, monitoring, and controlling routers that employ the Virtual Router Redundancy Protocol (VRRP).</t>

<t>This memo specifies a MIB module in a manner that is compliant with SMIv2, and semantically identical to the SMIv1 definitions.</t>
</abstract>
</front>

<seriesInfo value="2787" name="RFC" />
</reference>


<reference target2="reference.RFC.2788.xml" anchor="RFC2788">
<front>
<title>Network Services Monitoring MIB</title>
<author fullname="Ned Freed" initials="N." surname="Freed">
<organization>Innosoft International, Inc.</organization>

<address>
<postal>
<street>1050 Lakes Drive</street>
<city>West Covina</city>
<region>CA</region>
<code>91790</code>
<country>US</country>
</postal>

<phone>+1 626 919 3600</phone>
<facsimile>+1 626 919 3614</facsimile>
<email>ned.freed@innosoft.com</email>
</address>
</author>

<author fullname="Steve Kille" initials="S." surname="Kille">
<organization>MessagingDirect Ltd.</organization>

<address>
<postal>
<street>The Dome, The Square</street>
<city>Richmond</city>
<region>England</region>
<code>TW9 1DT</code>
<country>UK</country>
</postal>

<phone>+44 20 83329091</phone>
<email>Steve.Kille@MessagingDirect.com</email>
</address>
</author>

<date year="2000" month="March" />
</front>

<seriesInfo value="2788" name="RFC" />
</reference>


<reference target2="reference.RFC.2789.xml" anchor="RFC2789">
<front>
<title>Mail Monitoring MIB</title>
<author fullname="Ned Freed" initials="N." surname="Freed">
<organization>Innosoft International, Inc.</organization>

<address>
<postal>
<street>1050 Lakes Drive</street>
<city>West Covina</city>
<region>CA</region>
<code>91790</code>
<country>US</country>
</postal>

<phone>+1 626 919 3600</phone>
<facsimile>+1 626 919 3614</facsimile>
<email>ned.freed@innosoft.com</email>
</address>
</author>

<author fullname="Steve Kille" initials="S." surname="Kille">
<organization>MessagingDirect Ltd.</organization>

<address>
<postal>
<street>The Dome, The Square</street>
<city>Richmond</city>
<region>England</region>
<code>TW9 1DT</code>
<country>UK</country>
</postal>

<phone>+44 20 83329091</phone>
<email>Steve.Kille@MessagingDirect.com</email>
</address>
</author>

<date year="2000" month="March" />

<abstract>
<t></t>
</abstract>
</front>

<seriesInfo value="2789" name="RFC" />
</reference>


<reference target2="reference.RFC.2790.xml" anchor="RFC2790">
<front>
<title>Host Resources MIB</title>
<author fullname="Steven Waldbusser" initials="S." surname="Waldbusser">
<organization>Lucent Technologies, Inc.</organization>

<address>
<postal>
<street>1213 Innsbruck Dr.</street>
<city>Sunnyvale</city>
<region>CA</region>
<code>94089</code>
<country>US</country>
</postal>

<phone>+1 650 318 1251</phone>
<email>waldbusser@ins.com</email>
</address>
</author>

<author fullname="Pete Grillo" initials="P." surname="Grillo">
<organization>WeSync.com</organization>

<address>
<postal>
<street>1001 SW Fifth Ave</street>
<street>Fifth Floor</street>
<city>Portland</city>
<region>OR</region>
<code>97204</code>
<country>US</country>
</postal>

<phone>+1 503 425 5051</phone>
<facsimile>+1 503 827 6718</facsimile>
<email>pete@wesync.com</email>
</address>
</author>

<date year="2000" month="March" />

<abstract>
<t>This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. This memo obsoletes RFC 1514, the "Host Resources MIB". This memo extends that specification by clarifying changes based on implementation and deployment experience and documenting the Host Resources MIB in SMIv2 format while remaining semantically identical to the existing SMIv1-based MIB.</t>

<t>This memo defines a MIB for use with managing host systems.  The term "host" is construed to mean any computer that communicates with other similar computers attached to the internet and that is directly used by one or more human beings. Although this MIB does not necessarily apply to devices whose primary function is communications services    (e.g., terminal servers, routers, bridges, monitoring equipment), such relevance is not explicitly precluded.  This MIB instruments attributes common to all internet hosts including, for example, both personal computers and systems that run variants of Unix.</t>
</abstract>
</front>

<seriesInfo value="2790" name="RFC" />
</reference>


<reference target2="reference.RFC.2791.xml" anchor="RFC2791">
<front>
<title>Scalable Routing Design Principles</title>
<author fullname="Jieyun (Jessica) Yu" initials="J." surname="Yu">
<organization>CoSine Communications</organization>

<address>
<postal>
<street>1200 Bridge Parkway</street>
<city>Redwood City</city>
<region>CA</region>
<code>94065</code>
<country>US</country>
</postal>

<email>jyy@cosinecom.com</email>
</address>
</author>

<date year="2000" month="July" />

<abstract>
<t>Routing is essential to a network. Routing scalability is essential to a large network. When routing does not scale, there is a direct impact on the stability and performance of a network. Therefore, routing scalability is an important issue, especially for a large network. This document identifies major factors affecting routing scalability as well as basic principles of designing scalable routing for large networks.</t>
</abstract>
</front>

<seriesInfo value="2791" name="RFC" />
</reference>


<reference target2="reference.RFC.2792.xml" anchor="RFC2792">
<front>
<title abbrev="Key and Signature Encoding for KeyNote">DSA and RSA Key and Signature Encoding for the KeyNote Trust Management System</title>
<author fullname="Matt Blaze" initials="M." surname="Blaze">
<organization>AT&amp;T Labs - Research</organization>

<address>
<postal>
<street>180 Park Avenue</street>
<city>Florham Park</city>
<region>NJ</region>
<code>07932-0971</code>
<country>US</country>
</postal>

<email>mab@research.att.com</email>
</address>
</author>

<author fullname="John Ioannidis" initials="J." surname="Ioannidis">
<organization>AT&amp;T Labs - Research</organization>

<address>
<postal>
<street>180 Park Avenue</street>
<city>Florham Park</city>
<region>NJ</region>
<code>07932-0971</code>
<country>US</country>
</postal>

<email>ji@research.att.com</email>
</address>
</author>

<author fullname="Angelos D. Keromytis" initials="A." surname="Keromytis">
<organization>University of Pennsylvania,  CIS Department,  Distributed Systems Lab</organization>

<address>
<postal>
<street>200 S. 33rd Street</street>
<city>Philadelphia</city>
<region>PA</region>
<code>19104-6389</code>
<country>US</country>
</postal>

<email>angelos@dsl.cis.upenn.edu</email>
</address>
</author>

<date year="2000" month="March" />

<abstract>
<t>This memo describes RSA and DSA key and signature encoding, and binary key encoding for version 2 of the KeyNote trust-management system.</t>
</abstract>
</front>

<seriesInfo value="2792" name="RFC" />
</reference>


<reference target2="reference.RFC.2793.xml" anchor="RFC2793">
<front>
<title>RTP Payload for Text Conversation</title>
<author fullname="Gunnar Hellstrom" initials="G." surname="Hellstrom">
<organization>Omnitor AB</organization>

<address>
<postal>
<street>Alsnogatan 7</street>
<street>4 tr</street>
<city>Stockholm</city>
<region />
<code>SE-116 41</code>
<country>SE</country>
</postal>

<phone>+46 708 204288</phone>
<facsimile>+46 8 55600206</facsimile>
<email>gunnar.hellstrom@omnitor.se</email>
</address>
</author>

<date year="2000" month="May" />

<abstract>
<t>This memo describes how to carry text conversation session contents in RTP packets. Text conversation session contents are specified in ITU-T Recommendation T.140.</t>

<t>Text conversation is used alone or in connection to other conversational facilities such as video and voice, to form multimedia conversation services.</t>

<t>This RTP payload description contains an optional possibility to include redundant text from already transmitted packets in order to reduce the risk of text loss caused by packet loss. The redundancy coding follows RFC 2198.</t>
</abstract>
</front>

<seriesInfo value="2793" name="RFC" />
</reference>


<reference target2="reference.RFC.2794.xml" anchor="RFC2794">
<front>
<title abbrev="Mobile Node NAI">Mobile IP Network Access Identifier Extension for IPv4</title>
<author fullname="Pat R. Calhoun" initials="P." surname="Calhoun">
<organization>Sun Microsystems Laboratories</organization>

<address>
<postal>
<street>15 Network Circle</street>
<city>Menlo Park</city>
<region>CA</region>
<code>94025</code>
<country>US</country>
</postal>

<phone>+1 650 786 7733</phone>
<email>pcalhoun@eng.sun.com</email>
</address>
</author>

<author fullname="Charles E. Perkins" initials="C." surname="Perkins">
<organization>Nokia Research Center</organization>

<address>
<postal>
<street>313 Fairchild Drive</street>
<city>Mountain View</city>
<region>CA</region>
<code>94043</code>
<country>US</country>
</postal>

<phone>+1 650 625 2986</phone>
<email>charliep@iprg.nokia.com</email>
</address>
</author>

<date year="2000" month="March" />

<abstract>
<t>AAA servers are in use within the Internet today to provide authentication and authorization services for dial-up computers. Such services are likely to be equally valuable for mobile nodes using Mobile IP when the nodes are attempting to connect to foreign domains with AAA servers.  AAA servers today identify clients by using the Network Access Identifier (NAI). Our proposal defines a way for the mobile node to identify itself, by including the NAI along with the Mobile IP Registration Request.This memo also updates RFC2290 which specifies the Mobile-IPv4 Configuration option for IPCP, by allowing the Mobile Node's Home Address field of this option to be zero.</t>
</abstract>
</front>

<seriesInfo value="2794" name="RFC" />
</reference>


<reference target2="reference.RFC.2795.xml" anchor="RFC2795">
<front>
<title>The Infinite Monkey Protocol Suite (IMPS)</title>
<author fullname="SteQven M. Christey" initials="S." surname="Christey">
<organization />

<address>
<email>steqve@shore.net</email>
</address>
</author>

<date year="2000" month="April" day="1" />

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

<seriesInfo value="2795" name="RFC" />
</reference>


<reference target2="reference.RFC.2796.xml" anchor="RFC2796">
<front>
<title abbrev="BGP Route Reflection">BGP Route Reflection - An Alternative to Full Mesh IBGP</title>
<author fullname="Tony Bates" initials="T." surname="Bates">
<organization>Cisco Systems, Inc.</organization>

<address>
<postal>
<street>170 West Tasman Drive</street>
<city>San Jose</city>
<region>CA</region>
<code>95134</code>
<country>US</country>
</postal>

<email>tbates@cisco.com</email>
</address>
</author>

<author fullname="Ravi Chandra" initials="R." surname="Chandra">
<organization>Redback Networks Inc.</organization>

<address>
<postal>
<street>350 Holger Way</street>
<city>San Jose</city>
<region>CA</region>
<code>95134</code>
<country>US</country>
</postal>

<email>rchandra@redback.com</email>
</address>
</author>

<author fullname="Enke Chen" initials="E." surname="Chen">
<organization>Redback Networks Inc.</organization>

<address>
<postal>
<street>350 Holger Way</street>
<city>San Jose</city>
<region>CA</region>
<code>95134</code>
<country>US</country>
</postal>

<email>enke@redback.com</email>
</address>
</author>

<date year="2000" month="April" />

<abstract>
<t>The Border Gateway Protocolis an inter-autonomous system routing protocol designed for TCP/IP internets. Currently in the Internet BGP deployments are configured such that that all BGP speakers within a single AS must be fully meshed so that any external routing information must be re-distributed to all other routers within that   AS. This represents a serious scaling problem that has been  well documented with several alternatives proposed,.</t>

<t>This document describes the use and design of a method known as
   "Route Reflection" to alleviate the the need for "full mesh" IBGP.</t>
</abstract>
</front>

<seriesInfo value="2796" name="RFC" />
</reference>


<reference target2="reference.RFC.2797.xml" anchor="RFC2797">
<front>
<title>Certificate Management Messages over CMS</title>
<author fullname="Michael Myers" initials="M." surname="Myers">
<organization>VeriSign Inc.</organization>

<address>
<postal>
<street>1350 Charleston Road</street>
<city>Mountain View</city>
<region>CA</region>
<code>94043</code>
<country>US</country>
</postal>

<phone>+1 650 429 3402</phone>
<email>mmyers@verisign.com</email>
</address>
</author>

<author fullname="Xiaoyi Liu" initials="X." surname="Liu">
<organization>cisco Systems</organization>

<address>
<postal>
<street>170 West Tasman Drive</street>
<city>San Jose</city>
<region>CA</region>
<code>95134</code>
<country>US</country>
</postal>

<phone>+1 480 526 7430</phone>
<email>xliu@cisco.com</email>
</address>
</author>

<author fullname="Jim Schaad" initials="J." surname="Schaad">
<organization />

<address>
<email>jimsch@nwlink.com</email>
</address>
</author>

<author fullname="Jeff Weinstein" initials="J." surname="Weinstein">
<organization />

<address>
<email>jsw@meer.net</email>
</address>
</author>

<date year="2000" month="April" />

<abstract>
<t>This document defines a Certificate Management protocol using CMS. This protocol addresses two immediate needs within the Internet PKI community:</t>

<t>1. The need for an interface to public key certification products and services based onand, and 
2. The need infor a certificate enrollment protocol for DSA-signed certificates with Diffie-Hellman public keys.</t>

<t>A small number of additional services are defined to supplement the core certificate request service.</t>

<t>Throughout this specification the term CMS is used to refer to bothand.  For both signedData and envelopedData, CMS is a superset of the PKCS7. In general, the use of PKCS7 in this document is aligned to the Cryptographic Message Syntaxthat provides a superset of the PKCS7 syntax. The term CMC refers to this specification.</t>

<t>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].</t>
</abstract>
</front>

<seriesInfo value="2797" name="RFC" />
</reference>


<reference target2="reference.RFC.2798.xml" anchor="RFC2798">
<front>
<title abbrev="The LDAP inetOrgPerson Object Class">Definition of the inetOrgPerson LDAP Object Class</title>
<author fullname="Mark Smith" initials="M." surname="Smith">
<organization>Netscape Communications Corp</organization>

<address>
<postal>
<street>501 E. Middlefield Rd.</street>
<street>Mailstop MV068</street>
<city>Mountain View</city>
<region>CA</region>
<code>94043</code>
<country>US</country>
</postal>

<phone>+1 650 937 3477</phone>
<email>mcs@netscape.com</email>
</address>
</author>

<date year="2000" month="April" />

<abstract>
<t>While the X.500 standards define many useful attribute typesand 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 for use in LDAP and X.500 directory services that extends the X.521 standard organizationalPerson class to meet these needs.</t>
</abstract>
</front>

<seriesInfo value="2798" name="RFC" />
</reference>


<reference target2="reference.RFC.2799.xml" anchor="RFC2799">
<front>
<title>Request for Comments Summary RFC Numbers 2700-2799</title>
<author fullname="S. Ginoza" initials="S." surname="Ginoza">
<organization />
</author>

<date year="2000" month="September" />
</front>

<seriesInfo value="2799" name="RFC" />
<format octets="42622" type="TXT" target="ftp://ftp.isi.edu/in-notes/rfc2799.txt" />
</reference>


<reference target2="reference.RFC.2800.xml" anchor="RFC2800">
<front>
<title>Internet Official Protocol Standards</title>
<author fullname="J. Reynolds" initials="J." surname="Reynolds">
<organization />
</author>

<author fullname="R. Braden" initials="R." surname="Braden">
<organization />
</author>

<author fullname="S. Ginoza" initials="S." surname="Ginoza">
<organization />
</author>

<date year="2001" month="May" />
</front>

<seriesInfo value="2800" name="RFC" />
<format octets="101648" type="TXT" target="ftp://ftp.isi.edu/in-notes/rfc2800.txt" />
</reference>


<reference target2="reference.RFC.2801.xml" anchor="RFC2801">
<front>
<title>Internet Open Trading Protocol - IOTP Version 1.0</title>
<author fullname="D. Burdett" initials="D." surname="Burdett">
<organization />
</author>

<date year="2000" month="April" />
</front>

<seriesInfo value="2801" name="RFC" />
<format octets="598794" type="TXT" target="ftp://ftp.isi.edu/in-notes/rfc2801.txt" />
</reference>


<reference target2="reference.RFC.2802.xml" anchor="RFC2802">
<front>
<title>Digital Signatures for the v1.0 Internet Open Trading Protocol (IOTP)</title>
<author fullname="K. Davidson" initials="K." surname="Davidson">
<organization />
</author>

<author fullname="Y. Kawatsura" initials="Y." surname="Kawatsura">
<organization />
</author>

<date year="2000" month="April" />
</front>

<seriesInfo value="2802" name="RFC" />
<format octets="52756" type="TXT" target="ftp://ftp.isi.edu/in-notes/rfc2802.txt" />
</reference>


<reference target2="reference.RFC.2803.xml" anchor="RFC2803">
<front>
<title>Digest Values for DOM (DOMHASH)</title>
<author fullname="H. Maruyama" initials="H." surname="Maruyama">
<organization />
</author>

<author fullname="K. Tamura" initials="K." surname="Tamura">
<organization />
</author>

<author fullname="N. Uramoto" initials="N." surname="Uramoto">
<organization />
</author>

<date year="2000" month="April" />
</front>

<seriesInfo value="2803" name="RFC" />
<format octets="22552" type="TXT" target="ftp://ftp.isi.edu/in-notes/rfc2803.txt" />
</reference>


<reference target2="reference.RFC.2804.xml" anchor="RFC2804">
<front>
<title>IETF Policy on Wiretapping</title>
<author>
<organization>IAB</organization>
</author>

<author>
<organization>IESG</organization>
</author>

<date year="2000" month="May" />
</front>

<seriesInfo value="2804" name="RFC" />
<format octets="18934" type="TXT" target="ftp://ftp.isi.edu/in-notes/rfc2804.txt" />
</reference>


<reference target2="reference.RFC.2805.xml" anchor="RFC2805">
<front>
<title>Media Gateway Control Protocol Architecture and Requirements</title>
<author fullname="Nancy Greene" initials="N." surname="Greene">
<organization>Nortel Networks</organization>

<address>
<postal>
<street>P.O. Box 3511 Stn C</street>
<city>Ottawa</city>
<region>Ontario</region>
<code />
<country>CA</country>
</postal>

<phone>+1 514 271 7221</phone>
<email>ngreene@nortelnetworks.com</email>
</address>
</author>

<author fullname="Michael Ramalho" initials="M." surname="Ramalho">
<organization>Cisco Systems</organization>

<address>
<postal>
<street>1802 Rue de la Port</street>
<city>Belmar</city>
<region>NJ</region>
<code>07719</code>
<country>US</country>
</postal>

<phone>+1 732 449 5762</phone>
<email>mramalho@cisco.com</email>
</address>
</author>

<author fullname="B. Rosen" initials="B." surname="Rosen">
<organization>Marconi</organization>

<address>
<postal>
<street>1000 ORE Drive</street>
<city>Warrendale</city>
<region>PA</region>
<code>15086</code>
<country>US</country>
</postal>

<phone>+1 724 742 6826</phone>
<email>brosen@eng.fore.com</email>
</address>
</author>

<date year="2000" month="April" />

<abstract>
<t>This document describes protocol requirements for the Media Gateway Control Protocol between a Media Gateway Controller and a Media Gateway.</t>
</abstract>
</front>

<seriesInfo value="2805" name="RFC" />
</reference>


<reference target2="reference.RFC.2806.xml" anchor="RFC2806">
<front>
<title>URLs for Telephone Calls</title>
<author fullname="A. Vaha-Sipila" initials="A." surname="Vaha-Sipila">
<organization />
</author>

<date year="2000" month="April" />
</front>

<seriesInfo value="2806" name="RFC" />
<format octets="50647" type="TXT" target="ftp://ftp.isi.edu/in-notes/rfc2806.txt" />
</reference>


<reference target2="reference.RFC.2807.xml" anchor="RFC2807">
<front>
<title>XML Signature Requirements</title>
<author fullname="J. Reagle" initials="J." surname="Reagle">
<organization />
</author>

<date year="2000" month="July" />
</front>

<seriesInfo value="2807" name="RFC" />
<format octets="21973" type="TXT" target="ftp://ftp.isi.edu/in-notes/rfc2807.txt" />
</reference>


<reference target2="reference.RFC.2808.xml" anchor="RFC2808">
<front>
<title>The SecurID(r) SASL Mechanism</title>
<author fullname="M. Nystrom" initials="M." surname="Nystrom">
<organization />
</author>

<date year="2000" month="April" />
</front>

<seriesInfo value="2808" name="RFC" />
<format octets="20342" type="TXT" target="ftp://ftp.isi.edu/in-notes/rfc2808.txt" />
</reference>


<reference target2="reference.RFC.2809.xml" anchor="RFC2809">
<front>
<title>Implementation of L2TP Compulsory Tunneling via RADIUS</title>
<author fullname="B. Aboba" initials="B." surname="Aboba">
<organization />
</author>

<author fullname="G. Zorn" initials="G." surname="Zorn">
<organization />
</author>

<date year="2000" month="April" />
</front>

<seriesInfo value="2809" name="RFC" />
<format octets="47259" type="TXT" target="ftp://ftp.isi.edu/in-notes/rfc2809.txt" />
</reference>


<reference target2="reference.RFC.2810.xml" anchor="RFC2810">
<front>
<title>Internet Relay Chat: Architecture</title>
<author fullname="C. Kalt" initials="C." surname="Kalt">
<organization />
</author>

<date year="2000" month="April" />
</front>

<seriesInfo value="2810" name="RFC" />
<format octets="19087" type="TXT" target="ftp://ftp.isi.edu/in-notes/rfc2810.txt" />
</reference>


<reference target2="reference.RFC.2811.xml" anchor="RFC2811">
<front>
<title>Internet Relay Chat: Channel Management</title>
<author fullname="C. Kalt" initials="C." surname="Kalt">
<organization />
</author>

<date year="2000" month="April" />
</front>

<seriesInfo value="2811" name="RFC" />
<format octets="40788" type="TXT" target="ftp://ftp.isi.edu/in-notes/rfc2811.txt" />
</reference>


<reference target2="reference.RFC.2812.xml" anchor="RFC2812">
<front>
<title>Internet Relay Chat: Client Protocol</title>
<author fullname="C. Kalt" initials="C." surname="Kalt">
<organization />
</author>

<date year="2000" month="April" />
</front>

<seriesInfo value="2812" name="RFC" />
<format octets="122637" type="TXT" target="ftp://ftp.isi.edu/in-notes/rfc2812.txt" />
</reference>


<reference target2="reference.RFC.2813.xml" anchor="RFC2813">
<front>
<title>Internet Relay Chat: Server Protocol</title>
<author fullname="C. Kalt" initials="C." surname="Kalt">
<organization />
</author>

<date year="2000" month="April" />
</front>

<seriesInfo value="2813" name="RFC" />
<format octets="56681" type="TXT" target="ftp://ftp.isi.edu/in-notes/rfc2813.txt" />
</reference>


<reference target2="reference.RFC.2814.xml" anchor="RFC2814">
<front>
<title>SBM (Subnet Bandwidth Manager): A Protocol for RSVP-based Admission Control over IEEE 802-style networks</title>
<author fullname="R. Yavatkar" initials="R." surname="Yavatkar">
<organization />
</author>

<author fullname="D. Hoffman" initials="D." surname="Hoffman">
<organization />
</author>

<author fullname="Y. Bernet" initials="Y." surname="Bernet">
<organization />
</author>

<author fullname="F. Baker" initials="F." surname="Baker">
<organization />
</author>

<author fullname="M. Speer" initials="M." surname="Speer">
<organization />
</author>

<date year="2000" month="May" />
</front>

<seriesInfo value="2814" name="RFC" />
<format octets="141886" type="TXT" target="ftp://ftp.isi.edu/in-notes/rfc2814.txt" />
</reference>


<reference target2="reference.RFC.2815.xml" anchor="RFC2815">
<front>
<title>Integrated Service Mappings on IEEE 802 Networks</title>
<author fullname="M. Seaman" initials="M." surname="Seaman">
<organization />
</author>

<author fullname="A. Smith" initials="A." surname="Smith">
<organization />
</author>

<author fullname="E. Crawley" initials="E." surname="Crawley">
<organization />
</author>

<author fullname="J. Wroclawski" initials="J." surname="Wroclawski">
<organization />
</author>

<date year="2000" month="May" />
</front>

<seriesInfo value="2815" name="RFC" />
<format octets="42403" type="TXT" target="ftp://ftp.isi.edu/in-notes/rfc2815.txt" />
</reference>


<reference target2="reference.RFC.2816.xml" anchor="RFC2816">
<front>
<title>A Framework for Integrated Services Over Shared and Switched IEEE 802 LAN Technologies</title>
<author fullname="A. Ghanwani" initials="A." surname="Ghanwani">
<organization />
</author>

<author fullname="J. Pace" initials="J." surname="Pace">
<organization />
</author>

<author fullname="V. Srinivasan" initials="V." surname="Srinivasan">
<organization />
</author>

<author fullname="A. Smith" initials="A." surname="Smith">
<organization />
</author>

<author fullname="M. Seaman" initials="M." surname="Seaman">
<organization />
</author>

<date year="2000" month="May" />
</front>

<seriesInfo value="2816" name="RFC" />
<format octets="119043" type="TXT" target="ftp://ftp.isi.edu/in-notes/rfc2816.txt" />
</reference>


<reference target2="reference.RFC.2817.xml" anchor="RFC2817">
<front>
<title>Upgrading to TLS Within HTTP/1.1</title>
<author fullname="R. Khare" initials="R." surname="Khare">
<organization />
</author>

<author fullname="S. Lawrence" initials="S." surname="Lawrence">
<organization />
</author>

<date year="2000" month="May" />
</front>

<seriesInfo value="2817" name="RFC" />
<format octets="27598" type="TXT" target="ftp://ftp.isi.edu/in-notes/rfc2817.txt" />
</reference>


<reference target2="reference.RFC.2818.xml" anchor="RFC2818">
<front>
<title>HTTP Over TLS</title>
<author fullname="E. Rescorla" initials="E." surname="Rescorla">
<organization />
</author>

<date year="2000" month="May" />
</front>

<seriesInfo value="2818" name="RFC" />
<format octets="15170" type="TXT" target="ftp://ftp.isi.edu/in-notes/rfc2818.txt" />
</reference>


<reference target2="reference.RFC.2819.xml" anchor="RFC2819">
<front>
<title>Remote Network Monitoring Management Information Base</title>
<author fullname="S. Waldbusser" initials="S." surname="Waldbusser">
<organization />
</author>

<date year="2000" month="May" />
</front>

<seriesInfo value="59" name="STD" />
<seriesInfo value="2819" name="RFC" />
<format octets="198676" type="TXT" target="ftp://ftp.isi.edu/in-notes/rfc2819.txt" />
</reference>


<reference target2="reference.RFC.2820.xml" anchor="RFC2820">
<front>
<title>Access Control Requirements for LDAP</title>
<author fullname="E. Stokes" initials="E." surname="Stokes">
<organization />
</author>

<author fullname="D. Byrne" initials="D." surname="Byrne">
<organization />
</author>

<author fullname="B. Blakley" initials="B." surname="Blakley">
<organization />
</author>

<author fullname="P. Behera" initials="P." surname="Behera">
<organization />
</author>

<date year="2000" month="May" />
</front>

<seriesInfo value="2820" name="RFC" />
<format octets="18172" type="TXT" target="ftp://ftp.isi.edu/in-notes/rfc2820.txt" />
</reference>


<reference target2="reference.RFC.2821.xml" anchor="RFC2821">
<front>
<title>Simple Mail Transfer Protocol</title>
<author fullname="J. Klensin" initials="J." surname="Klensin">
<organization />
</author>

<date year="2001" month="April" />
</front>

<seriesInfo value="2821" name="RFC" />
<format octets="192504" type="TXT" target="ftp://ftp.isi.edu/in-notes/rfc2821.txt" />
</reference>


<reference target2="reference.RFC.2822.xml" anchor="RFC2822">
<front>
<title>Internet Message Format</title>
<author fullname="P. Resnick" initials="P." surname="Resnick">
<organization />
</author>

<date year="2001" month="April" />
</front>

<seriesInfo value="2822" name="RFC" />
<format octets="110695" type="TXT" target="ftp://ftp.isi.edu/in-notes/rfc2822.txt" />
</reference>


<reference target2="reference.RFC.2823.xml" anchor="RFC2823">
<front>
<title>PPP over Simple Data Link (SDL) using SONET/SDH with ATM-like framing</title>
<author fullname="J. Carlson" initials="J." surname="Carlson">
<organization />
</author>

<author fullname="P. Langner" initials="P." surname="Langner">
<organization />
</author>

<author fullname="E. Hernandez-Valencia" initials="E." surname="Hernandez-Valencia">
<organization />
</author>

<author fullname="J. Manchester" initials="J." surname="Manchester">
<organization />
</author>

<date year="2000" month="May" />
</front>

<seriesInfo value="2823" name="RFC" />
<format octets="60049" type="TXT" target="ftp://ftp.isi.edu/in-notes/rfc2823.txt" />
</reference>


<reference target2="reference.RFC.2824.xml" anchor="RFC2824">
<front>
<title>Call Processing Language Framework and Requirements</title>
<author fullname="J. Lennox" initials="J." surname="Lennox">
<organization />
</author>

<author fullname="H. Schulzrinne" initials="H." surname="Schulzrinne">
<organization />
</author>

<date year="2000" month="May" />
</front>

<seriesInfo value="2824" name="RFC" />
<format octets="58711" type="TXT" target="ftp://ftp.isi.edu/in-notes/rfc2824.txt" />
</reference>


<reference target2="reference.RFC.2825.xml" anchor="RFC2825">
<front>
<title>A Tangled Web: Issues of I18N, Domain Names, and the Other Internet protocols</title>
<author>
<organization>IAB</organization>
</author>

<author fullname="L. Daigle" initials="L." surname="Daigle">
<organization />
</author>

<date year="2000" month="May" />
</front>

<seriesInfo value="2825" name="RFC" />
<format octets="15612" type="TXT" target="ftp://ftp.isi.edu/in-notes/rfc2825.txt" />
</reference>


<reference target2="reference.RFC.2826.xml" anchor="RFC2826">
<front>
<title>IAB Technical Comment on the Unique DNS Root</title>
<author>
<organization>Internet Architecture Board</organization>
</author>

<date year="2000" month="May" />
</front>

<seriesInfo value="2826" name="RFC" />
<format octets="13400" type="TXT" target="ftp://ftp.isi.edu/in-notes/rfc2826.txt" />
</reference>


<reference target2="reference.RFC.2827.xml" anchor="RFC2827">
<front>
<title>Network Ingress Filtering: Defeating Denial of Service Attacks which employ IP Source Address Spoofing</title>
<author fullname="P. Ferguson" initials="P." surname="Ferguson">
<organization />
</author>

<author fullname="D. Senie" initials="D." surname="Senie">
<organization />
</author>

<date year="2000" month="May" />
</front>

<seriesInfo value="38" name="BCP" />
<seriesInfo value="2827" name="RFC" />
<format octets="21258" type="TXT" target="ftp://ftp.isi.edu/in-notes/rfc2827.txt" />
</reference>


<reference target2="reference.RFC.2828.xml" anchor="RFC2828">
<front>
<title>Internet Security Glossary</title>
<author fullname="R. Shirey" initials="R." surname="Shirey">
<organization />
</author>

<date year="2000" month="May" />
</front>

<seriesInfo value="2828" name="RFC" />
<format octets="489292" type="TXT" target="ftp://ftp.isi.edu/in-notes/rfc2828.txt" />
</reference>


<reference target2="reference.RFC.2829.xml" anchor="RFC2829">
<front>
<title>Authentication Methods for LDAP</title>
<author fullname="M. Wahl" initials="M." surname="Wahl">
<organization />
</author>

<author fullname="H. Alvestrand" initials="H." surname="Alvestrand">
<organization />
</author>

<author fullname="J. Hodges" initials="J." surname="Hodges">
<organization />
</author>

<author fullname="R. Morgan" initials="R." surname="Morgan">
<organization />
</author>

<date year="2000" month="May" />
</front>

<seriesInfo value="2829" name="RFC" />
<format octets="33471" type="TXT" target="ftp://ftp.isi.edu/in-notes/rfc2829.txt" />
</reference>


<reference target2="reference.RFC.2830.xml" anchor="RFC2830">
<front>
<title>Lightweight Directory Access Protocol (v3): Extension for Transport Layer Security</title>
<author fullname="J. Hodges" initials="J." surname="Hodges">
<organization />
</author>

<author fullname="R. Morgan" initials="R." surname="Morgan">
<organization />
</author>

<author fullname="M. Wahl" initials="M." surname="Wahl">
<organization />
</author>

<date year="2000" month="May" />
</front>

<seriesInfo value="2830" name="RFC" />
<format octets="24469" type="TXT" target="ftp://ftp.isi.edu/in-notes/rfc2830.txt" />
</reference>


<reference target2="reference.RFC.2831.xml" anchor="RFC2831">
<front>
<title>Using Digest Authentication as a SASL Mechanism</title>
<author fullname="P. Leach" initials="P." surname="Leach">
<organization />
</author>

<author fullname="C. Newman" initials="C." surname="Newman">
<organization />
</author>

<date year="2000" month="May" />
</front>

<seriesInfo value="2831" name="RFC" />
<format octets="58124" type="TXT" target="ftp://ftp.isi.edu/in-notes/rfc2831.txt" />
</reference>


<reference target2="reference.RFC.2832.xml" anchor="RFC2832">
<front>
<title>NSI Registry Registrar Protocol (RRP) Version 1.1.0</title>
<author fullname="S. Hollenbeck" initials="S." surname="Hollenbeck">
<organization />
</author>

<author fullname="M. Srivastava" initials="M." surname="Srivastava">
<organization />
</author>

<date year="2000" month="May" />
</front>

<seriesInfo value="2832" name="RFC" />
<format octets="77057" type="TXT" target="ftp://ftp.isi.edu/in-notes/rfc2832.txt" />
</reference>


<reference target2="reference.RFC.2833.xml" anchor="RFC2833">
<front>
<title>RTP Payload for DTMF Digits, Telephony Tones and Telephony Signals</title>
<author fullname="H. Schulzrinne" initials="H." surname="Schulzrinne">
<organization />
</author>

<author fullname="S. Petrack" initials="S." surname="Petrack">
<organization />
</author>

<date year="2000" month="May" />
</front>

<seriesInfo value="2833" name="RFC" />
<format octets="68786" type="TXT" target="ftp://ftp.isi.edu/in-notes/rfc2833.txt" />
</reference>


<reference target2="reference.RFC.2834.xml" anchor="RFC2834">
<front>
<title>ARP and IP Broadcast over HIPPI-800</title>
<author fullname="J.-M. Pittet" initials="J.-M." surname="Pittet">
<organization />
</author>

<date year="2000" month="May" />
</front>

<seriesInfo value="2834" name="RFC" />
<format octets="76243" type="TXT" target="ftp://ftp.isi.edu/in-notes/rfc2834.txt" />
</reference>


<reference target2="reference.RFC.2835.xml" anchor="RFC2835">
<front>
<title>IP and ARP over HIPPI-6400 (GSN)</title>
<author fullname="J.-M. Pittet" initials="J.-M." surname="Pittet">
<organization />
</author>

<date year="2000" month="May" />
</front>

<seriesInfo value="2835" name="RFC" />
<format octets="74178" type="TXT" target="ftp://ftp.isi.edu/in-notes/rfc2835.txt" />
</reference>


<reference target2="reference.RFC.2836.xml" anchor="RFC2836">
<front>
<title>Per Hop Behavior Identification Codes</title>
<author fullname="S. Brim" initials="S." surname="Brim">
<organization />
</author>

<author fullname="B. Carpenter" initials="B." surname="Carpenter">
<organization />
</author>

<author fullname="F. Le Faucheur" initials="F." surname="Le Faucheur">
<organization />
</author>

<date year="2000" month="May" />
</front>

<seriesInfo value="2836" name="RFC" />
<format octets="13399" type="TXT" target="ftp://ftp.isi.edu/in-notes/rfc2836.txt" />
</reference>


<reference target2="reference.RFC.2837.xml" anchor="RFC2837">
<front>
<title>Definitions of Managed Objects for the Fabric Element in Fibre Channel Standard</title>
<author fullname="K. Teow" initials="K." surname="Teow">
<organization />
</author>

<date year="2000" month="May" />
</front>

<seriesInfo value="2837" name="RFC" />
<format octets="87860" type="TXT" target="ftp://ftp.isi.edu/in-notes/rfc2837.txt" />
</reference>


<reference target2="reference.RFC.2838.xml" anchor="RFC2838">
<front>
<title>Uniform Resource Identifiers for Television Broadcasts</title>
<author fullname="D. Zigmond" initials="D." surname="Zigmond">
<organization />
</author>

<author fullname="M. Vickers" initials="M." surname="Vickers">
<organization />
</author>

<date year="2000" month="May" />
</front>

<seriesInfo value="2838" name="RFC" />
<format octets="11405" type="TXT" target="ftp://ftp.isi.edu/in-notes/rfc2838.txt" />
</reference>


<reference target2="reference.RFC.2839.xml" anchor="RFC2839">
<front>
<title>Internet Kermit Service</title>
<author fullname="F. da Cruz" initials="F." surname="da Cruz">
<organization />
</author>

<author fullname="J. Altman" initials="J." surname="Altman">
<organization />
</author>

<date year="2000" month="May" />
</front>

<seriesInfo value="2839" name="RFC" />
<format octets="42726" type="TXT" target="ftp://ftp.isi.edu/in-notes/rfc2839.txt" />
</reference>


<reference target2="reference.RFC.2840.xml" anchor="RFC2840">
<front>
<title>TELNET KERMIT OPTION</title>
<author fullname="J. Altman" initials="J." surname="Altman">
<organization />
</author>

<author fullname="F. da Cruz" initials="F." surname="da Cruz">
<organization />
</author>

<date year="2000" month="May" />
</front>

<seriesInfo value="2840" name="RFC" />
<format octets="22519" type="TXT" target="ftp://ftp.isi.edu/in-notes/rfc2840.txt" />
</reference>


<reference target2="reference.RFC.2841.xml" anchor="RFC2841">
<front>
<title>IP Authentication using Keyed SHA1 with Interleaved Padding (IP-MAC)</title>
<author fullname="P. Metzger" initials="P." surname="Metzger">
<organization />
</author>

<author fullname="W. Simpson" initials="W." surname="Simpson">
<organization />
</author>

<date year="2000" month="November" />
</front>

<seriesInfo value="2841" name="RFC" />
<format octets="14139" type="TXT" target="ftp://ftp.isi.edu/in-notes/rfc2841.txt" />
</reference>


<reference target2="reference.RFC.2842.xml" anchor="RFC2842">
<front>
<title>Capabilities Advertisement with BGP-4</title>
<author fullname="R. Chandra" initials="R." surname="Chandra">
<organization />
</author>

<author fullname="J. Scudder" initials="J." surname="Scudder">
<organization />
</author>

<date year="2000" month="May" />
</front>

<seriesInfo value="2842" name="RFC" />
<format octets="8366" type="TXT" target="ftp://ftp.isi.edu/in-notes/rfc2842.txt" />
</reference>


<reference target2="reference.RFC.2843.xml" anchor="RFC2843">
<front>
<title>Proxy-PAR</title>
<author fullname="P. Droz" initials="P." surname="Droz">
<organization />
</author>

<author fullname="T. Przygienda" initials="T." surname="Przygienda">
<organization />
</author>

<date year="2000" month="May" />
</front>

<seriesInfo value="2843" name="RFC" />
<format octets="27891" type="TXT" target="ftp://ftp.isi.edu/in-notes/rfc2843.txt" />
</reference>


<reference target2="reference.RFC.2844.xml" anchor="RFC2844">
<front>
<title>OSPF over ATM and Proxy-PAR</title>
<author fullname="T. Przygienda" initials="T." surname="Przygienda">
<organization />
</author>

<author fullname="P. Droz" initials="P." surname="Droz">
<organization />
</author>

<author fullname="R. Haas" initials="R." surname="Haas">
<organization />
</author>

<date year="2000" month="May" />
</front>

<seriesInfo value="2844" name="RFC" />
<format octets="32146" type="TXT" target="ftp://ftp.isi.edu/in-notes/rfc2844.txt" />
</reference>


<reference target2="reference.RFC.2845.xml" anchor="RFC2845">
<front>
<title>Secret Key Transaction Authentication for DNS (TSIG)</title>
<author fullname="P. Vixie" initials="P." surname="Vixie">
<organization />
</author>

<author fullname="O. Gudmundsson" initials="O." surname="Gudmundsson">
<organization />
</author>

<author fullname="D. Eastlake" initials="D." surname="Eastlake">
<organization />
</author>

<author fullname="B. Wellington" initials="B." surname="Wellington">
<organization />
</author>

<date year="2000" month="May" />
</front>

<seriesInfo value="2845" name="RFC" />
<format octets="32272" type="TXT" target="ftp://ftp.isi.edu/in-notes/rfc2845.txt" />
</reference>


<reference target2="reference.RFC.2846.xml" anchor="RFC2846">
<front>
<title>GSTN Address Element Extensions in E-mail Services</title>
<author fullname="C. Allocchio" initials="C." surname="Allocchio">
<organization />
</author>

<date year="2000" month="June" />
</front>

<seriesInfo value="2846" name="RFC" />
<format octets="54316" type="TXT" target="ftp://ftp.isi.edu/in-notes/rfc2846.txt" />
</reference>


<reference target2="reference.RFC.2847.xml" anchor="RFC2847">
<front>
<title>LIPKEY - A Low Infrastructure Public Key Mechanism Using SPKM</title>
<author fullname="M. Eisler" initials="M." surname="Eisler">
<organization />
</author>

<date year="2000" month="June" />
</front>

<seriesInfo value="2847" name="RFC" />
<format octets="50045" type="TXT" target="ftp://ftp.isi.edu/in-notes/rfc2847.txt" />
</reference>


<reference target2="reference.RFC.2848.xml" anchor="RFC2848">
<front>
<title>The PINT Service Protocol: Extensions to SIP and SDP for IP Access to Telephone Call Services</title>
<author fullname="S. Petrack" initials="S." surname="Petrack">
<organization />
</author>

<author fullname="L. Conroy" initials="L." surname="Conroy">
<organization />
</author>

<date year="2000" month="June" />
</front>

<seriesInfo value="2848" name="RFC" />
<format octets="168851" type="TXT" target="ftp://ftp.isi.edu/in-notes/rfc2848.txt" />
</reference>


<reference target2="reference.RFC.2849.xml" anchor="RFC2849">
<front>
<title>The LDAP Data Interchange Format (LDIF) - Technical Specification</title>
<author fullname="G. Good" initials="G." surname="Good">
<organization />
</author>

<date year="2000" month="June" />
</front>

<seriesInfo value="2849" name="RFC" />
<format octets="26017" type="TXT" target="ftp://ftp.isi.edu/in-notes/rfc2849.txt" />
</reference>


<reference target2="reference.RFC.2850.xml" anchor="RFC2850">
<front>
<title>Charter of the Internet Architecture Board (IAB)</title>
<author>
<organization>Internet Architecture Board</organization>
</author>

<author fullname="B. Carpenter" initials="B." surname="Carpenter">
<organization />
</author>

<date year="2000" month="May" />
</front>

<seriesInfo value="39" name="BCP" />
<seriesInfo value="2850" name="RFC" />
<format octets="15984" type="TXT" target="ftp://ftp.isi.edu/in-notes/rfc2850.txt" />
</reference>


<reference target2="reference.RFC.2851.xml" anchor="RFC2851">
<front>
<title>Textual Conventions for Internet Network Addresses</title>
<author fullname="M. Daniele" initials="M." surname="Daniele">
<organization />
</author>

<author fullname="B. Haberman" initials="B." surname="Haberman">
<organization />
</author>

<author fullname="S. Routhier" initials="S." surname="Routhier">
<organization />
</author>

<author fullname="J. Schoenwaelder" initials="J." surname="Schoenwaelder">
<organization />
</author>

<date year="2000" month="June" />
</front>

<seriesInfo value="2851" name="RFC" />
<format octets="32587" type="TXT" target="ftp://ftp.isi.edu/in-notes/rfc2851.txt" />
</reference>


<reference target2="reference.RFC.2852.xml" anchor="RFC2852">
<front>
<title>Deliver By SMTP Service Extension</title>
<author fullname="D. Newman" initials="D." surname="Newman">
<organization />
</author>

<date year="2000" month="June" />
</front>

<seriesInfo value="2852" name="RFC" />
<format octets="29285" type="TXT" target="ftp://ftp.isi.edu/in-notes/rfc2852.txt" />
</reference>


<reference target2="reference.RFC.2853.xml" anchor="RFC2853">
<front>
<title>Generic Security Service API Version 2 : Java Bindings</title>
<author fullname="J. Kabat" initials="J." surname="Kabat">
<organization />
</author>

<author fullname="M. Upadhyay" initials="M." surname="Upadhyay">
<organization />
</author>

<date year="2000" month="June" />
</front>

<seriesInfo value="2853" name="RFC" />
<format octets="199512" type="TXT" target="ftp://ftp.isi.edu/in-notes/rfc2853.txt" />
</reference>


<reference target2="reference.RFC.2854.xml" anchor="RFC2854">
<front>
<title>The 'text/html' Media Type</title>
<author fullname="D. Connolly" initials="D." surname="Connolly">
<organization />
</author>

<author fullname="L. Masinter" initials="L." surname="Masinter">
<organization />
</author>

<date year="2000" month="June" />
</front>

<seriesInfo value="2854" name="RFC" />
<format octets="16135" type="TXT" target="ftp://ftp.isi.edu/in-notes/rfc2854.txt" />
</reference>


<reference target2="reference.RFC.2855.xml" anchor="RFC2855">
<front>
<title>DHCP for IEEE 1394</title>
<author fullname="K. Fujisawa" initials="K." surname="Fujisawa">
<organization />
</author>

<date year="2000" month="June" />
</front>

<seriesInfo value="2855" name="RFC" />
<format octets="8070" type="TXT" target="ftp://ftp.isi.edu/in-notes/rfc2855.txt" />
</reference>


<reference target2="reference.RFC.2856.xml" anchor="RFC2856">
<front>
<title>Textual Conventions for Additional High Capacity Data Types</title>
<author fullname="A. Bierman" initials="A." surname="Bierman">
<organization />
</author>

<author fullname="K. McCloghrie" initials="K." surname="McCloghrie">
<organization />
</author>

<author fullname="R. Presuhn" initials="R." surname="Presuhn">
<organization />
</author>

<date year="2000" month="June" />
</front>

<seriesInfo value="2856" name="RFC" />
<format octets="20954" type="TXT" target="ftp://ftp.isi.edu/in-notes/rfc2856.txt" />
</reference>


<reference target2="reference.RFC.2857.xml" anchor="RFC2857">
<front>
<title>The Use of HMAC-RIPEMD-160-96 within ESP and AH</title>
<author fullname="A. Keromytis" initials="A." surname="Keromytis">
<organization />
</author>

<author fullname="N. Provos" initials="N." surname="Provos">
<organization />
</author>

<date year="2000" month="June" />
</front>

<seriesInfo value="2857" name="RFC" />
<format octets="13544" type="TXT" target="ftp://ftp.isi.edu/in-notes/rfc2857.txt" />
</reference>


<reference target2="reference.RFC.2858.xml" anchor="RFC2858">
<front>
<title>Multiprotocol Extensions for BGP-4</title>
<author fullname="T. Bates" initials="T." surname="Bates">
<organization />
</author>

<author fullname="Y. Rekhter" initials="Y." surname="Rekhter">
<organization />
</author>

<author fullname="R. Chandra" initials="R." surname="Chandra">
<organization />
</author>

<author fullname="D. Katz" initials="D." surname="Katz">
<organization />
</author>

<date year="2000" month="June" />
</front>

<seriesInfo value="2858" name="RFC" />
<format octets="23305" type="TXT" target="ftp://ftp.isi.edu/in-notes/rfc2858.txt" />
</reference>


<reference target2="reference.RFC.2859.xml" anchor="RFC2859">
<front>
<title>A Time Sliding Window Three Colour Marker (TSWTCM)</title>
<author fullname="W. Fang" initials="W." surname="Fang">
<organization />
</author>

<author fullname="N. Seddigh" initials="N." surname="Seddigh">
<organization />
</author>

<author fullname="B. Nandy" initials="B." surname="Nandy">
<organization />
</author>

<date year="2000" month="June" />
</front>

<seriesInfo value="2859" name="RFC" />
<format octets="19203" type="TXT" target="ftp://ftp.isi.edu/in-notes/rfc2859.txt" />
</reference>


<reference target2="reference.RFC.2860.xml" anchor="RFC2860">
<front>
<title>Memorandum of Understanding Concerning the Technical Work of the Internet Assigned Numbers Authority</title>
<author fullname="B. Carpenter" initials="B." surname="Carpenter">
<organization />
</author>

<author fullname="F. Baker" initials="F." surname="Baker">
<organization />
</author>

<author fullname="M. Roberts" initials="M." surname="Roberts">
<organization />
</author>

<date year="2000" month="June" />
</front>

<seriesInfo value="2860" name="RFC" />
<format octets="12361" type="TXT" target="ftp://ftp.isi.edu/in-notes/rfc2860.txt" />
</reference>


<reference target2="reference.RFC.2861.xml" anchor="RFC2861">
<front>
<title>TCP Congestion Window Validation</title>
<author fullname="M. Handley" initials="M." surname="Handley">
<organization />
</author>

<author fullname="J. Padhye" initials="J." surname="Padhye">
<organization />
</author>

<author fullname="S. Floyd" initials="S." surname="Floyd">
<organization />
</author>

<date year="2000" month="June" />
</front>

<seriesInfo value="2861" name="RFC" />
<format octets="26993" type="TXT" target="ftp://ftp.isi.edu/in-notes/rfc2861.txt" />
</reference>


<reference target2="reference.RFC.2862.xml" anchor="RFC2862">
<front>
<title>RTP Payload Format for Real-Time Pointers</title>
<author fullname="M. Civanlar" initials="M." surname="Civanlar">
<organization />
</author>

<author fullname="G. Cash" initials="G." surname="Cash">
<organization />
</author>

<date year="2000" month="June" />
</front>

<seriesInfo value="2862" name="RFC" />
<format octets="12031" type="TXT" target="ftp://ftp.isi.edu/in-notes/rfc2862.txt" />
</reference>


<reference target2="reference.RFC.2863.xml" anchor="RFC2863">
<front>
<title>The Interfaces Group MIB</title>
<author fullname="K. McCloghrie" initials="K." surname="McCloghrie">
<organization />
</author>

<author fullname="F. Kastenholz" initials="F." surname="Kastenholz">
<organization />
</author>

<date year="2000" month="June" />
</front>

<seriesInfo value="2863" name="RFC" />
<format octets="155014" type="TXT" target="ftp://ftp.isi.edu/in-notes/rfc2863.txt" />
</reference>


<reference target2="reference.RFC.2864.xml" anchor="RFC2864">
<front>
<title>The Inverted Stack Table Extension to the Interfaces Group MIB</title>
<author fullname="K. McCloghrie" initials="K." surname="McCloghrie">
<organization />
</author>

<author fullname="G. Hanson" initials="G." surname="Hanson">
<organization />
</author>

<date year="2000" month="June" />
</front>

<seriesInfo value="2864" name="RFC" />
<format octets="21445" type="TXT" target="ftp://ftp.isi.edu/in-notes/rfc2864.txt" />
</reference>


<reference target2="reference.RFC.2865.xml" anchor="RFC2865">
<front>
<title>Remote Authentication Dial In User Service (RADIUS)</title>
<author fullname="C. Rigney" initials="C." surname="Rigney">
<organization />
</author>

<author fullname="S. Willens" initials="S." surname="Willens">
<organization />
</author>

<author fullname="A. Rubens" initials="A." surname="Rubens">
<organization />
</author>

<author fullname="W. Simpson" initials="W." surname="Simpson">
<organization />
</author>

<date year="2000" month="June" />
</front>

<seriesInfo value="2865" name="RFC" />
<format octets="146456" type="TXT" target="ftp://ftp.isi.edu/in-notes/rfc2865.txt" />
</reference>


<reference target2="reference.RFC.2866.xml" anchor="RFC2866">
<front>
<title>RADIUS Accounting</title>
<author fullname="C. Rigney" initials="C." surname="Rigney">
<organization />
</author>

<date year="2000" month="June" />
</front>

<seriesInfo value="2866" name="RFC" />
<format octets="51135" type="TXT" target="ftp://ftp.isi.edu/in-notes/rfc2866.txt" />
</reference>


<reference target2="reference.RFC.2867.xml" anchor="RFC2867">
<front>
<title>RADIUS Accounting Modifications for Tunnel Protocol Support</title>
<author fullname="G. Zorn" initials="G." surname="Zorn">
<organization />
</author>

<author fullname="B. Aboba" initials="B." surname="Aboba">
<organization />
</author>

<author fullname="D. Mitton" initials="D." surname="Mitton">
<organization />
</author>

<date year="2000" month="June" />
</front>

<seriesInfo value="2867" name="RFC" />
<format octets="51135" type="TXT" target="ftp://ftp.isi.edu/in-notes/rfc2867.txt" />
</reference>


<reference target2="reference.RFC.2868.xml" anchor="RFC2868">
<front>
<title>RADIUS Attributes for Tunnel Protocol Support</title>
<author fullname="G. Zorn" initials="G." surname="Zorn">
<organization />
</author>

<author fullname="D. Leifer" initials="D." surname="Leifer">
<organization />
</author>

<author fullname="A. Rubens" initials="A." surname="Rubens">
<organization />
</author>

<author fullname="J. Shriver" initials="J." surname="Shriver">
<organization />
</author>

<author fullname="M. Holdrege" initials="M." surname="Holdrege">
<organization />
</author>

<author fullname="I. Goyret" initials="I." surname="Goyret">
<organization />
</author>

<date year="2000" month="June" />
</front>

<seriesInfo value="2868" name="RFC" />
<format octets="42609" type="TXT" target="ftp://ftp.isi.edu/in-notes/rfc2868.txt" />
</reference>


<reference target2="reference.RFC.2869.xml" anchor="RFC2869">
<front>
<title>RADIUS Extensions</title>
<author fullname="C. Rigney" initials="C." surname="Rigney">
<organization />
</author>

<author fullname="W. Willats" initials="W." surname="Willats">
<organization />
</author>

<author fullname="P. Calhoun" initials="P." surname="Calhoun">
<organization />
</author>

<date year="2000" month="June" />
</front>

<seriesInfo value="2869" name="RFC" />
<format octets="96854" type="TXT" target="ftp://ftp.isi.edu/in-notes/rfc2869.txt" />
</reference>


<reference target2="reference.RFC.2870.xml" anchor="RFC2870">
<front>
<title>Root Name Server Operational Requirements</title>
<author fullname="R. Bush" initials="R." surname="Bush">
<organization />
</author>

<author fullname="D. Karrenberg" initials="D." surname="Karrenberg">
<organization />
</author>

<author fullname="M. Kosters" initials="M." surname="Kosters">
<organization />
</author>

<author fullname="R. Plzak" initials="R." surname="Plzak">
<organization />
</author>

<date year="2000" month="June" />
</front>

<seriesInfo value="40" name="BCP" />
<seriesInfo value="2870" name="RFC" />
<format octets="21133" type="TXT" target="ftp://ftp.isi.edu/in-notes/rfc2870.txt" />
</reference>


<reference target2="reference.RFC.2871.xml" anchor="RFC2871">
<front>
<title>A Framework for Telephony Routing over IP</title>
<author fullname="J. Rosenberg" initials="J." surname="Rosenberg">
<organization />
</author>

<author fullname="H. Schulzrinne" initials="H." surname="Schulzrinne">
<organization />
</author>

<date year="2000" month="June" />
</front>

<seriesInfo value="2871" name="RFC" />
<format octets="60664" type="TXT" target="ftp://ftp.isi.edu/in-notes/rfc2871.txt" />
</reference>


<reference target2="reference.RFC.2872.xml" anchor="RFC2872">
<front>
<title>Application and Sub Application Identity Policy Element for Use with RSVP</title>
<author fullname="Y. Bernet" initials="Y." surname="Bernet">
<organization />
</author>

<author fullname="R. Pabbati" initials="R." surname="Pabbati">
<organization />
</author>

<date year="2000" month="June" />
</front>

<seriesInfo value="2872" name="RFC" />
<format octets="10933" type="TXT" target="ftp://ftp.isi.edu/in-notes/rfc2872.txt" />
</reference>


<reference target2="reference.RFC.2873.xml" anchor="RFC2873">
<front>
<title>TCP Processing of the IPv4 Precedence Field</title>
<author fullname="X. Xiao" initials="X." surname="Xiao">
<organization />
</author>

<author fullname="A. Hannan" initials="A." surname="Hannan">
<organization />
</author>

<author fullname="V. Paxson" initials="V." surname="Paxson">
<organization />
</author>

<author fullname="E. Crabbe" initials="E." surname="Crabbe">
<organization />
</author>

<date year="2000" month="June" />
</front>

<seriesInfo value="2873" name="RFC" />
<format octets="15565" type="TXT" target="ftp://ftp.isi.edu/in-notes/rfc2873.txt" />
</reference>


<reference target2="reference.RFC.2874.xml" anchor="RFC2874">
<front>
<title>DNS Extensions to Support IPv6 Address Aggregation and Renumbering</title>
<author fullname="M. Crawford" initials="M." surname="Crawford">
<organization />
</author>

<author fullname="C. Huitema" initials="C." surname="Huitema">
<organization />
</author>

<date year="2000" month="July" />
</front>

<seriesInfo value="2874" name="RFC" />
<format octets="44204" type="TXT" target="ftp://ftp.isi.edu/in-notes/rfc2874.txt" />
</reference>


<reference target2="reference.RFC.2875.xml" anchor="RFC2875">
<front>
<title>Diffie-Hellman Proof-of-Possession Algorithms</title>
<author fullname="H. Prafullchandra" initials="H." surname="Prafullchandra">
<organization />
</author>

<author fullname="J. Schaad" initials="J." surname="Schaad">
<organization />
</author>

<date year="2000" month="July" />
</front>

<seriesInfo value="2875" name="RFC" />
<format octets="45231" type="TXT" target="ftp://ftp.isi.edu/in-notes/rfc2875.txt" />
</reference>


<reference target2="reference.RFC.2876.xml" anchor="RFC2876">
<front>
<title>Use of the KEA and SKIPJACK Algorithms in CMS</title>
<author fullname="J. Pawling" initials="J." surname="Pawling">
<organization />
</author>

<date year="2000" month="July" />
</front>

<seriesInfo value="2876" name="RFC" />
<format octets="29265" type="TXT" target="ftp://ftp.isi.edu/in-notes/rfc2876.txt" />
</reference>


<reference target2="reference.RFC.2877.xml" anchor="RFC2877">
<front>
<title>5250 Telnet Enhancements</title>
<author fullname="T. Murphy" initials="T." surname="Murphy">
<organization />
</author>

<author fullname="P. Rieth" initials="P." surname="Rieth">
<organization />
</author>

<author fullname="J. Stevens" initials="J." surname="Stevens">
<organization />
</author>

<date year="2000" month="July" />
</front>

<seriesInfo value="2877" name="RFC" />
<format octets="83369" type="TXT" target="ftp://ftp.isi.edu/in-notes/rfc2877.txt" />
</reference>


<reference target2="reference.RFC.2878.xml" anchor="RFC2878">
<front>
<title>PPP Bridging Control Protocol (BCP)</title>
<author fullname="M. Higashiyama" initials="M." surname="Higashiyama">
<organization />
</author>

<author fullname="F. Baker" initials="F." surname="Baker">
<organization />
</author>

<date year="2000" month="July" />
</front>

<seriesInfo value="2878" name="RFC" />
<format octets="79527" type="TXT" target="ftp://ftp.isi.edu/in-notes/rfc2878.txt" />
</reference>


<reference target2="reference.RFC.2879.xml" anchor="RFC2879">
<front>
<title>Content Feature Schema for Internet Fax (V2)</title>
<author fullname="G. Klyne" initials="G." surname="Klyne">
<organization />
</author>

<author fullname="L. McIntyre" initials="L." surname="McIntyre">
<organization />
</author>

<date year="2000" month="August" />
</front>

<seriesInfo value="2879" name="RFC" />
<format octets="104032" type="TXT" target="ftp://ftp.isi.edu/in-notes/rfc2879.txt" />
</reference>


<reference target2="reference.RFC.2880.xml" anchor="RFC2880">
<front>
<title>Internet Fax T.30 Feature Mapping</title>
<author fullname="L. McIntyre" initials="L." surname="McIntyre">
<organization />
</author>

<author fullname="G. Klyne" initials="G." surname="Klyne">
<organization />
</author>

<date year="2000" month="August" />
</front>

<seriesInfo value="2880" name="RFC" />
<format octets="75973" type="TXT" target="ftp://ftp.isi.edu/in-notes/rfc2880.txt" />
</reference>


<reference target2="reference.RFC.2881.xml" anchor="RFC2881">
<front>
<title>Network Access Server Requirements Next Generation (NASREQNG) NAS Model</title>
<author fullname="D. Mitton" initials="D." surname="Mitton">
<organization />
</author>

<author fullname="M. Beadles" initials="M." surname="Beadles">
<organization />
</author>

<date year="2000" month="July" />
</front>

<seriesInfo value="2881" name="RFC" />
<format octets="45029" type="TXT" target="ftp://ftp.isi.edu/in-notes/rfc2881.txt" />
</reference>


<reference target2="reference.RFC.2882.xml" anchor="RFC2882">
<front>
<title>Network Access Servers Requirements: Extended RADIUS Practices</title>
<author fullname="D. Mitton" initials="D." surname="Mitton">
<organization />
</author>

<date year="2000" month="July" />
</front>

<seriesInfo value="2882" name="RFC" />
<format octets="31426" type="TXT" target="ftp://ftp.isi.edu/in-notes/rfc2882.txt" />
</reference>


<reference target2="reference.RFC.2883.xml" anchor="RFC2883">
<front>
<title>An Extension to the Selective Acknowledgement (SACK) Option for TCP</title>
<author fullname="S. Floyd" initials="S." surname="Floyd">
<organization />
</author>

<author fullname="J. Mahdavi" initials="J." surname="Mahdavi">
<organization />
</author>

<author fullname="M. Mathis" initials="M." surname="Mathis">
<organization />
</author>

<author fullname="M. Podolsky" initials="M." surname="Podolsky">
<organization />
</author>

<date year="2000" month="July" />
</front>

<seriesInfo value="2883" name="RFC" />
<format octets="35794" type="TXT" target="ftp://ftp.isi.edu/in-notes/rfc2883.txt" />
</reference>


<reference target2="reference.RFC.2884.xml" anchor="RFC2884">
<front>
<title>Performance Evaluation of Explicit Congestion Notification (ECN) in IP Networks</title>
<author fullname="J. Hadi Salim" initials="J." surname="Hadi Salim">
<organization />
</author>

<author fullname="U. Ahmed" initials="U." surname="Ahmed">
<organization />
</author>

<date year="2000" month="July" />
</front>

<seriesInfo value="2884" name="RFC" />
<format octets="44647" type="TXT" target="ftp://ftp.isi.edu/in-notes/rfc2884.txt" />
</reference>


<reference target2="reference.RFC.2885.xml" anchor="RFC2885">
<front>
<title>Megaco Protocol version 0.8</title>
<author fullname="F. Cuervo" initials="F." surname="Cuervo">
<organization />
</author>

<author fullname="N. Greene" initials="N." surname="Greene">
<organization />
</author>

<author fullname="C. Huitema" initials="C." surname="Huitema">
<organization />
</author>

<author fullname="A. Rayhan" initials="A." surname="Rayhan">
<organization />
</author>

<author fullname="B. Rosen" initials="B." surname="Rosen">
<organization />
</author>

<author fullname="J. Segers" initials="J." surname="Segers">
<organization />
</author>

<date year="2000" month="August" />
</front>

<seriesInfo value="2885" name="RFC" />
<format octets="344871" type="TXT" target="ftp://ftp.isi.edu/in-notes/rfc2885.txt" />
</reference>


<reference target2="reference.RFC.2886.xml" anchor="RFC2886">
<front>
<title>Megaco Errata</title>
<author fullname="T. Taylor" initials="T." surname="Taylor">
<organization />
</author>

<date year="2000" month="August" />
</front>

<seriesInfo value="2886" name="RFC" />
<format octets="41311" type="TXT" target="ftp://ftp.isi.edu/in-notes/rfc2886.txt" />
</reference>


<reference target2="reference.RFC.2887.xml" anchor="RFC2887">
<front>
<title>The Reliable Multicast Design Space for Bulk Data Transfer</title>
<author fullname="M. Handley" initials="M." surname="Handley">
<organization />
</author>

<author fullname="S. Floyd" initials="S." surname="Floyd">
<organization />
</author>

<author fullname="B. Whetten" initials="B." surname="Whetten">
<organization />
</author>

<author fullname="R. Kermode" initials="R." surname="Kermode">
<organization />
</author>

<author fullname="L. Vicisano" initials="L." surname="Vicisano">
<organization />
</author>

<author fullname="M. Luby" initials="M." surname="Luby">
<organization />
</author>

<date year="2000" month="August" />
</front>

<seriesInfo value="2887" name="RFC" />
<format octets="51135" type="TXT" target="ftp://ftp.isi.edu/in-notes/rfc2887.txt" />
</reference>


<reference target2="reference.RFC.2888.xml" anchor="RFC2888">
<front>
<title>Secure Remote Access with L2TP</title>
<author fullname="P. Srisuresh" initials="P." surname="Srisuresh">
<organization />
</author>

<date year="2000" month="August" />
</front>

<seriesInfo value="2888" name="RFC" />
<format octets="41255" type="TXT" target="ftp://ftp.isi.edu/in-notes/rfc2888.txt" />
</reference>


<reference target2="reference.RFC.2889.xml" anchor="RFC2889">
<front>
<title>Benchmarking Methodology for LAN Switching Devices</title>
<author fullname="R. Mandeville" initials="R." surname="Mandeville">
<organization />
</author>

<author fullname="J. Perser" initials="J." surname="Perser">
<organization />
</author>

<date year="2000" month="August" />
</front>

<seriesInfo value="2889" name="RFC" />
<format octets="73251" type="TXT" target="ftp://ftp.isi.edu/in-notes/rfc2889.txt" />
</reference>


<reference target2="reference.RFC.2890.xml" anchor="RFC2890">
<front>
<title>Key and Sequence Number Extensions to GRE</title>
<author fullname="G. Dommety" initials="G." surname="Dommety">
<organization />
</author>

<date year="2000" month="September" />
</front>

<seriesInfo value="2890" name="RFC" />
<format octets="14503" type="TXT" target="ftp://ftp.isi.edu/in-notes/rfc2890.txt" />
</reference>


<reference target2="reference.RFC.2891.xml" anchor="RFC2891">
<front>
<title>LDAP Control Extension for Server Side Sorting of Search Results</title>
<author fullname="T. Howes" initials="T." surname="Howes">
<organization />
</author>

<author fullname="M. Wahl" initials="M." surname="Wahl">
<organization />
</author>

<author fullname="A. Anantha" initials="A." surname="Anantha">
<organization />
</author>

<date year="2000" month="August" />
</front>

<seriesInfo value="2891" name="RFC" />
<format octets="15833" type="TXT" target="ftp://ftp.isi.edu/in-notes/rfc2891.txt" />
</reference>


<reference target2="reference.RFC.2892.xml" anchor="RFC2892">
<front>
<title>The Cisco SRP MAC Layer Protocol</title>
<author fullname="D. Tsiang" initials="D." surname="Tsiang">
<organization />
</author>

<author fullname="G. Suwala" initials="G." surname="Suwala">
<organization />
</author>

<date year="2000" month="August" />
</front>

<seriesInfo value="2892" name="RFC" />
<format octets="107645" type="TXT" target="ftp://ftp.isi.edu/in-notes/rfc2892.txt" />
</reference>


<reference target2="reference.RFC.2893.xml" anchor="RFC2893">
<front>
<title>Transition Mechanisms for IPv6 Hosts and Routers</title>
<author fullname="R. Gilligan" initials="R." surname="Gilligan">
<organization />
</author>

<author fullname="E. Nordmark" initials="E." surname="Nordmark">
<organization />
</author>

<date year="2000" month="August" />
</front>

<seriesInfo value="2893" name="RFC" />
<format octets="62731" type="TXT" target="ftp://ftp.isi.edu/in-notes/rfc2893.txt" />
</reference>


<reference target2="reference.RFC.2894.xml" anchor="RFC2894">
<front>
<title>Router Renumbering for IPv6</title>
<author fullname="M. Crawford" initials="M." surname="Crawford">
<organization />
</author>

<date year="2000" month="August" />
</front>

<seriesInfo value="2894" name="RFC" />
<format octets="69135" type="TXT" target="ftp://ftp.isi.edu/in-notes/rfc2894.txt" />
</reference>


<reference target2="reference.RFC.2895.xml" anchor="RFC2895">
<front>
<title>Remote Network Monitoring MIB Protocol Identifier Reference</title>
<author fullname="A. Bierman" initials="A." surname="Bierman">
<organization />
</author>

<author fullname="C. Bucci" initials="C." surname="Bucci">
<organization />
</author>

<author fullname="R. Iddon" initials="R." surname="Iddon">
<organization />
</author>

<date year="2000" month="August" />
</front>

<seriesInfo value="2895" name="RFC" />
<format octets="88094" type="TXT" target="ftp://ftp.isi.edu/in-notes/rfc2895.txt" />
</reference>


<reference target2="reference.RFC.2896.xml" anchor="RFC2896">
<front>
<title>Remote Network Monitoring MIB Protocol Identifier Macros</title>
<author fullname="A. Bierman" initials="A." surname="Bierman">
<organization />
</author>

<author fullname="C. Bucci" initials="C." surname="Bucci">
<organization />
</author>

<author fullname="R. Iddon" initials="R." surname="Iddon">
<organization />
</author>

<date year="2000" month="August" />
</front>

<seriesInfo value="2896" name="RFC" />
<format octets="135768" type="TXT" target="ftp://ftp.isi.edu/in-notes/rfc2896.txt" />
</reference>


<reference target2="reference.RFC.2897.xml" anchor="RFC2897">
<front>
<title>Proposal for an MGCP Advanced Audio Package</title>
<author fullname="D. Cromwell" initials="D." surname="Cromwell">
<organization />
</author>

<date year="2000" month="August" />
</front>

<seriesInfo value="2897" name="RFC" />
<format octets="67459" type="TXT" target="ftp://ftp.isi.edu/in-notes/rfc2897.txt" />
</reference>


<reference target2="reference.RFC.2898.xml" anchor="RFC2898">
<front>
<title>PKCS #5: Password-Based Cryptography Specification Version 2.0</title>
<author fullname="B. Kaliski" initials="B." surname="Kaliski">
<organization />
</author>

<date year="2000" month="September" />
</front>

<seriesInfo value="2898" name="RFC" />
<format octets="68692" type="TXT" target="ftp://ftp.isi.edu/in-notes/rfc2898.txt" />
</reference>


<reference target2="reference.RFC.2899.xml" anchor="RFC2899">
<front>
<title>Request for Comments Summary RFC Numbers 2800-2899</title>
<author fullname="S. Ginoza" initials="S." surname="Ginoza">
<organization />
</author>

<date year="2001" month="May" />
</front>

<seriesInfo value="2899" name="RFC" />
<format octets="43805" type="TXT" target="ftp://ftp.isi.edu/in-notes/rfc2899.txt" />
</reference>


<reference target2="reference.RFC.2900.xml" anchor="RFC2900">
<front>
<title>Internet Official Protocol Standards</title>
<author fullname="J. Reynolds" initials="J." surname="Reynolds">
<organization />
</author>

<author fullname="R. Braden" initials="R." surname="Braden">
<organization />
</author>

<author fullname="S. Ginoza" initials="S." surname="Ginoza">
<organization />
</author>

<date year="2001" month="August" />
</front>

<seriesInfo value="2900" name="RFC" />
<format octets="112809" type="TXT" target="ftp://ftp.isi.edu/in-notes/rfc2900.txt" />
</reference>


<reference target2="reference.RFC.2901.xml" anchor="RFC2901">
<front>
<title>Guide to Administrative Procedures of the Internet Infrastructure</title>
<author fullname="Z. Wenzel" initials="Z." surname="Wenzel">
<organization />
</author>

<author fullname="J. Klensin" initials="J." surname="Klensin">
<organization />
</author>

<author fullname="R. Bush" initials="R." surname="Bush">
<organization />
</author>

<author fullname="S. Huter" initials="S." surname="Huter">
<organization />
</author>

<date year="2000" month="August" />
</front>

<seriesInfo value="2901" name="RFC" />
<format octets="63680" type="TXT" target="ftp://ftp.isi.edu/in-notes/rfc2901.txt" />
</reference>


<reference target2="reference.RFC.2902.xml" anchor="RFC2902">
<front>
<title>Overview of the 1998 IAB Routing Workshop</title>
<author fullname="S. Deering" initials="S." surname="Deering">
<organization />
</author>

<author fullname="S. Hares" initials="S." surname="Hares">
<organization />
</author>

<author fullname="C. Perkins" initials="C." surname="Perkins">
<organization />
</author>

<author fullname="R. Perlman" initials="R." surname="Perlman">
<organization />
</author>

<date year="2000" month="August" />
</front>

<seriesInfo value="2902" name="RFC" />
<format octets="32773" type="TXT" target="ftp://ftp.isi.edu/in-notes/rfc2902.txt" />
</reference>


<reference target2="reference.RFC.2903.xml" anchor="RFC2903">
<front>
<title>Generic AAA Architecture</title>
<author fullname="C. de Laat" initials="C." surname="de Laat">
<organization />
</author>

<author fullname="G. Gross" initials="G." surname="Gross">
<organization />
</author>

<author fullname="L. Gommans" initials="L." surname="Gommans">
<organization />
</author>

<author fullname="J. Vollbrecht" initials="J." surname="Vollbrecht">
<organization />
</author>

<author fullname="D. Spence" initials="D." surname="Spence">
<organization />
</author>

<date year="2000" month="August" />
</front>

<seriesInfo value="2903" name="RFC" />
<format octets="60627" type="TXT" target="ftp://ftp.isi.edu/in-notes/rfc2903.txt" />
</reference>


<reference target2="reference.RFC.2904.xml" anchor="RFC2904">
<front>
<title>AAA Authorization Framework</title>
<author fullname="J. Vollbrecht" initials="J." surname="Vollbrecht">
<organization />
</author>

<author fullname="P. Calhoun" initials="P." surname="Calhoun">
<organization />
</author>

<author fullname="S. Farrell" initials="S." surname="Farrell">
<organization />
</author>

<author fullname="L. Gommans" initials="L." surname="Gommans">
<organization />
</author>

<author fullname="G. Gross" initials="G." surname="Gross">
<organization />
</author>

<author fullname="B. de Bruijn" initials="B." surname="de Bruijn">
<organization />
</author>

<author fullname="C. de Laat" initials="C." surname="de Laat">
<organization />
</author>

<author fullname="M. Holdrege" initials="M." surname="Holdrege">
<organization />
</author>

<author fullname="D. Spence" initials="D." surname="Spence">
<organization />
</author>

<date year="2000" month="August" />
</front>

<seriesInfo value="2904" name="RFC" />
<format octets="78098" type="TXT" target="ftp://ftp.isi.edu/in-notes/rfc2904.txt" />
</reference>


<reference target2="reference.RFC.2905.xml" anchor="RFC2905">
<front>
<title>AAA Authorization Application Examples</title>
<author fullname="J. Vollbrecht" initials="J." surname="Vollbrecht">
<organization />
</author>

<author fullname="P. Calhoun" initials="P." surname="Calhoun">
<organization />
</author>

<author fullname="S. Farrell" initials="S." surname="Farrell">
<organization />
</author>

<author fullname="L. Gommans" initials="L." surname="Gommans">
<organization />
</author>

<author fullname="G. Gross" initials="G." surname="Gross">
<organization />
</author>

<author fullname="B. de Bruijn" initials="B." surname="de Bruijn">
<organization />
</author>

<author fullname="C. de Laat" initials="C." surname="de Laat">
<organization />
</author>

<author fullname="M. Holdrege" initials="M." surname="Holdrege">
<organization />
</author>

<author fullname="D. Spence" initials="D." surname="Spence">
<organization />
</author>

<date year="2000" month="August" />
</front>

<seriesInfo value="2905" name="RFC" />
<format octets="118645" type="TXT" target="ftp://ftp.isi.edu/in-notes/rfc2905.txt" />
</reference>


<reference target2="reference.RFC.2906.xml" anchor="RFC2906">
<front>
<title>AAA Authorization Requirements</title>
<author fullname="S. Farrell" initials="S." surname="Farrell">
<organization />
</author>

<author fullname="J. Vollbrecht" initials="J." surname="Vollbrecht">
<organization />
</author>

<author fullname="P. Calhoun" initials="P." surname="Calhoun">
<organization />
</author>

<author fullname="L. Gommans" initials="L." surname="Gommans">
<organization />
</author>

<author fullname="G. Gross" initials="G." surname="Gross">
<organization />
</author>

<author fullname="B. de Bruijn" initials="B." surname="de Bruijn">
<organization />
</author>

<author fullname="C. de Laat" initials="C." surname="de Laat">
<organization />
</author>

<author fullname="M. Holdrege" initials="M." surname="Holdrege">
<organization />
</author>

<author fullname="D. Spence" initials="D." surname="Spence">
<organization />
</author>

<date year="2000" month="August" />
</front>

<seriesInfo value="2906" name="RFC" />
<format octets="48618" type="TXT" target="ftp://ftp.isi.edu/in-notes/rfc2906.txt" />
</reference>


<reference target2="reference.RFC.2907.xml" anchor="RFC2907">
<front>
<title>MADCAP Multicast Scope Nesting State Option</title>
<author fullname="R. Kermode" initials="R." surname="Kermode">
<organization />
</author>

<date year="2000" month="September" />
</front>

<seriesInfo value="2907" name="RFC" />
<format octets="27572" type="TXT" target="ftp://ftp.isi.edu/in-notes/rfc2907.txt" />
</reference>


<reference target2="reference.RFC.2908.xml" anchor="RFC2908">
<front>
<title>The Internet Multicast Address Allocation Architecture</title>
<author fullname="D. Thaler" initials="D." surname="Thaler">
<organization />
</author>

<author fullname="M. Handley" initials="M." surname="Handley">
<organization />
</author>

<author fullname="D. Estrin" initials="D." surname="Estrin">
<organization />
</author>

<date year="2000" month="September" />
</front>

<seriesInfo value="2908" name="RFC" />
<format octets="30515" type="TXT" target="ftp://ftp.isi.edu/in-notes/rfc2908.txt" />
</reference>


<reference target2="reference.RFC.2909.xml" anchor="RFC2909">
<front>
<title>The Multicast Address-Set Claim (MASC) Protocol</title>
<author fullname="P. Radoslavov" initials="P." surname="Radoslavov">
<organization />
</author>

<author fullname="D. Estrin" initials="D." surname="Estrin">
<organization />
</author>

<author fullname="R. Govindan" initials="R." surname="Govindan">
<organization />
</author>

<author fullname="M. Handley" initials="M." surname="Handley">
<organization />
</author>

<author fullname="S. Kumar" initials="S." surname="Kumar">
<organization />
</author>

<author fullname="D. Thaler" initials="D." surname="Thaler">
<organization />
</author>

<date year="2000" month="September" />
</front>

<seriesInfo value="2909" name="RFC" />
<format octets="127278" type="TXT" target="ftp://ftp.isi.edu/in-notes/rfc2909.txt" />
</reference>


<reference target2="reference.RFC.2910.xml" anchor="RFC2910">
<front>
<title>Internet Printing Protocol/1.1: Encoding and Transport</title>
<author fullname="R. Herriot" initials="R." surname="Herriot">
<organization />
</author>

<author fullname="S. Butler" initials="S." surname="Butler">
<organization />
</author>

<author fullname="P. Moore" initials="P." surname="Moore">
<organization />
</author>

<author fullname="R. Turner" initials="R." surname="Turner">
<organization />
</author>

<author fullname="J. Wenn" initials="J." surname="Wenn">
<organization />
</author>

<date year="2000" month="September" />
</front>

<seriesInfo value="2910" name="RFC" />
<format octets="100599" type="TXT" target="ftp://ftp.isi.edu/in-notes/rfc2910.txt" />
</reference>


<reference target2="reference.RFC.2911.xml" anchor="RFC2911">
<front>
<title>Internet Printing Protocol/1.1: Model and Semantics</title>
<author fullname="T. Hastings" initials="T." surname="Hastings">
<organization />
</author>

<author fullname="R. Herriot" initials="R." surname="Herriot">
<organization />
</author>

<author fullname="R. deBry" initials="R." surname="deBry">
<organization />
</author>

<author fullname="S. Isaacson" initials="S." surname="Isaacson">
<organization />
</author>

<author fullname="P. Powell" initials="P." surname="Powell">
<organization />
</author>

<date year="2000" month="September" />
</front>

<seriesInfo value="2911" name="RFC" />
<format octets="575805" type="TXT" target="ftp://ftp.isi.edu/in-notes/rfc2911.txt" />
</reference>


<reference target2="reference.RFC.2912.xml" anchor="RFC2912">
<front>
<title>Indicating Media Features for MIME Content</title>
<author fullname="G. Klyne" initials="G." surname="Klyne">
<organization />
</author>

<date year="2000" month="September" />
</front>

<seriesInfo value="2912" name="RFC" />
<format octets="20618" type="TXT" target="ftp://ftp.isi.edu/in-notes/rfc2912.txt" />
</reference>


<reference target2="reference.RFC.2913.xml" anchor="RFC2913">
<front>
<title>MIME Content Types in Media Feature Expressions</title>
<author fullname="G. Klyne" initials="G." surname="Klyne">
<organization />
</author>

<date year="2000" month="September" />
</front>

<seriesInfo value="2913" name="RFC" />
<format octets="16095" type="TXT" target="ftp://ftp.isi.edu/in-notes/rfc2913.txt" />
</reference>


<reference target2="reference.RFC.2914.xml" anchor="RFC2914">
<front>
<title>Congestion Control Principles</title>
<author fullname="S. Floyd" initials="S." surname="Floyd">
<organization />
</author>

<date year="2000" month="September" />
</front>

<seriesInfo value="41" name="BCP" />
<seriesInfo value="2914" name="RFC" />
<format octets="43823" type="TXT" target="ftp://ftp.isi.edu/in-notes/rfc2914.txt" />
</reference>


<reference target2="reference.RFC.2915.xml" anchor="RFC2915">
<front>
<title>The Naming Authority Pointer (NAPTR) DNS Resource Record</title>
<author fullname="M. Mealling" initials="M." surname="Mealling">
<organization />
</author>

<author fullname="R. Daniel" initials="R." surname="Daniel">
<organization />
</author>

<date year="2000" month="September" />
</front>

<seriesInfo value="2915" name="RFC" />
<format octets="41521" type="TXT" target="ftp://ftp.isi.edu/in-notes/rfc2915.txt" />
</reference>


<reference target2="reference.RFC.2916.xml" anchor="RFC2916">
<front>
<title>E.164 number and DNS</title>
<author fullname="P. Faltstrom" initials="P." surname="Faltstrom">
<organization />
</author>

<date year="2000" month="September" />
</front>

<seriesInfo value="2916" name="RFC" />
<format octets="18159" type="TXT" target="ftp://ftp.isi.edu/in-notes/rfc2916.txt" />
</reference>


<reference target2="reference.RFC.2917.xml" anchor="RFC2917">
<front>
<title>A Core MPLS IP VPN Architecture</title>
<author fullname="K. Muthukrishnan" initials="K." surname="Muthukrishnan">
<organization />
</author>

<author fullname="A. Malis" initials="A." surname="Malis">
<organization />
</author>

<date year="2000" month="September" />
</front>

<seriesInfo value="2917" name="RFC" />
<format octets="35352" type="TXT" target="ftp://ftp.isi.edu/in-notes/rfc2917.txt" />
</reference>


<reference target2="reference.RFC.2918.xml" anchor="RFC2918">
<front>
<title>Route Refresh Capability for BGP-4</title>
<author fullname="E. Chen" initials="E." surname="Chen">
<organization />
</author>

<date year="2000" month="September" />
</front>

<seriesInfo value="2918" name="RFC" />
<format octets="7354" type="TXT" target="ftp://ftp.isi.edu/in-notes/rfc2918.txt" />
</reference>


<reference target2="reference.RFC.2919.xml" anchor="RFC2919">
<front>
<title>List-Id: A Structured Field and Namespace for the Identification of Mailing Lists</title>
<author fullname="R. Chandhok" initials="R." surname="Chandhok">
<organization />
</author>

<author fullname="G. Wenger" initials="G." surname="Wenger">
<organization />
</author>

<date year="2001" month="March" />
</front>

<seriesInfo value="2919" name="RFC" />
<format octets="18480" type="TXT" target="ftp://ftp.isi.edu/in-notes/rfc2919.txt" />
</reference>


<reference target2="reference.RFC.2920.xml" anchor="RFC2920">
<front>
<title>SMTP Service Extension for Command Pipelining</title>
<author fullname="N. Freed" initials="N." surname="Freed">
<organization />
</author>

<date year="2000" month="September" />
</front>

<seriesInfo value="60" name="STD" />
<seriesInfo value="2920" name="RFC" />
<format octets="17065" type="TXT" target="ftp://ftp.isi.edu/in-notes/rfc2920.txt" />
</reference>


<reference target2="reference.RFC.2921.xml" anchor="RFC2921">
<front>
<title>6BONE pTLA and pNLA Formats (pTLA)</title>
<author fullname="B. Fink" initials="B." surname="Fink">
<organization />
</author>

<date year="2000" month="September" />
</front>

<seriesInfo value="2921" name="RFC" />
<format octets="14218" type="TXT" target="ftp://ftp.isi.edu/in-notes/rfc2921.txt" />
</reference>


<reference target2="reference.RFC.2922.xml" anchor="RFC2922">
<front>
<title>Physical Topology MIB</title>
<author fullname="A. Bierman" initials="A." surname="Bierman">
<organization />
</author>

<author fullname="K. Jones" initials="K." surname="Jones">
<organization />
</author>

<date year="2000" month="September" />
</front>

<seriesInfo value="2922" name="RFC" />
<format octets="66830" type="TXT" target="ftp://ftp.isi.edu/in-notes/rfc2922.txt" />
</reference>


<reference target2="reference.RFC.2923.xml" anchor="RFC2923">
<front>
<title>TCP Problems with Path MTU Discovery</title>
<author fullname="K. Lahey" initials="K." surname="Lahey">
<organization />
</author>

<date year="2000" month="September" />
</front>

<seriesInfo value="2923" name="RFC" />
<format octets="30976" type="TXT" target="ftp://ftp.isi.edu/in-notes/rfc2923.txt" />
</reference>


<reference target2="reference.RFC.2924.xml" anchor="RFC2924">
<front>
<title>Accounting Attributes and Record Formats</title>
<author fullname="N. Brownlee" initials="N." surname="Brownlee">
<organization />
</author>

<author fullname="A. Blount" initials="A." surname="Blount">
<organization />
</author>

<date year="2000" month="September" />
</front>

<seriesInfo value="2924" name="RFC" />
<format octets="75561" type="TXT" target="ftp://ftp.isi.edu/in-notes/rfc2924.txt" />
</reference>


<reference target2="reference.RFC.2925.xml" anchor="RFC2925">
<front>
<title>Definitions of Managed Objects for Remote Ping, Traceroute, and Lookup Operations</title>
<author fullname="K. White" initials="K." surname="White">
<organization />
</author>

<date year="2000" month="September" />
</front>

<seriesInfo value="2925" name="RFC" />
<format octets="150691" type="TXT" target="ftp://ftp.isi.edu/in-notes/rfc2925.txt" />
</reference>


<reference target2="reference.RFC.2926.xml" anchor="RFC2926">
<front>
<title>Conversion of LDAP Schemas to and from SLP Templates</title>
<author fullname="J. Kempf" initials="J." surname="Kempf">
<organization />
</author>

<author fullname="R. Moats" initials="R." surname="Moats">
<organization />
</author>

<author fullname="P. St. Pierre" initials="P." surname="St. Pierre">
<organization />
</author>

<date year="2000" month="September" />
</front>

<seriesInfo value="2926" name="RFC" />
<format octets="55365" type="TXT" target="ftp://ftp.isi.edu/in-notes/rfc2926.txt" />
</reference>


<reference target2="reference.RFC.2927.xml" anchor="RFC2927">
<front>
<title>MIME Directory Profile for LDAP Schema</title>
<author fullname="M. Wahl" initials="M." surname="Wahl">
<organization />
</author>

<date year="2000" month="September" />
</front>

<seriesInfo value="2927" name="RFC" />
<format octets="16122" type="TXT" target="ftp://ftp.isi.edu/in-notes/rfc2927.txt" />
</reference>


<reference target2="reference.RFC.2928.xml" anchor="RFC2928">
<front>
<title>Initial IPv6 Sub-TLA ID Assignments</title>
<author fullname="R. Hinden" initials="R." surname="Hinden">
<organization />
</author>

<author fullname="S. Deering" initials="S." surname="Deering">
<organization />
</author>

<author fullname="R. Fink" initials="R." surname="Fink">
<organization />
</author>

<author fullname="T. Hain" initials="T." surname="Hain">
<organization />
</author>

<date year="2000" month="September" />
</front>

<seriesInfo value="2928" name="RFC" />
<format octets="11882" type="TXT" target="ftp://ftp.isi.edu/in-notes/rfc2928.txt" />
</reference>


<reference target2="reference.RFC.2929.xml" anchor="RFC2929">
<front>
<title>Domain Name System (DNS) IANA Considerations</title>
<author fullname="D. Eastlake" initials="D." surname="Eastlake">
<organization />
</author>

<author fullname="E. Brunner-Williams" initials="E." surname="Brunner-Williams">
<organization />
</author>

<author fullname="B. Manning" initials="B." surname="Manning">
<organization />
</author>

<date year="2000" month="September" />
</front>

<seriesInfo value="42" name="BCP" />
<seriesInfo value="2929" name="RFC" />
<format octets="22454" type="TXT" target="ftp://ftp.isi.edu/in-notes/rfc2929.txt" />
</reference>


<reference target2="reference.RFC.2930.xml" anchor="RFC2930">
<front>
<title>Secret Key Establishment for DNS (TKEY RR)</title>
<author fullname="D. Eastlake" initials="D." surname="Eastlake">
<organization />
</author>

<date year="2000" month="September" />
</front>

<seriesInfo value="2930" name="RFC" />
<format octets="34894" type="TXT" target="ftp://ftp.isi.edu/in-notes/rfc2930.txt" />
</reference>


<reference target2="reference.RFC.2931.xml" anchor="RFC2931">
<front>
<title>DNS Request and Transaction Signatures ( SIG(0)s)</title>
<author fullname="D. Eastlake" initials="D." surname="Eastlake">
<organization />
</author>

<date year="2000" month="September" />
</front>

<seriesInfo value="2931" name="RFC" />
<format octets="19073" type="TXT" target="ftp://ftp.isi.edu/in-notes/rfc2931.txt" />
</reference>


<reference target2="reference.RFC.2932.xml" anchor="RFC2932">
<front>
<title>IPv4 Multicast Routing MIB</title>
<author fullname="K. McCloghrie" initials="K." surname="McCloghrie">
<organization />
</author>

<author fullname="D. Farinacci" initials="D." surname="Farinacci">
<organization />
</author>

<author fullname="D. Thaler" initials="D." surname="Thaler">
<organization />
</author>

<date year="2000" month="October" />
</front>

<seriesInfo value="2932" name="RFC" />
<format octets="50430" type="TXT" target="ftp://ftp.isi.edu/in-notes/rfc2932.txt" />
</reference>


<reference target2="reference.RFC.2933.xml" anchor="RFC2933">
<front>
<title>Internet Group Management Protocol MIB</title>
<author fullname="K. McCloghrie" initials="K." surname="McCloghrie">
<organization />
</author>

<author fullname="D. Farinacci" initials="D." surname="Farinacci">
<organization />
</author>

<author fullname="D. Thaler" initials="D." surname="Thaler">
<organization />
</author>

<date year="2000" month="October" />
</front>

<seriesInfo value="2933" name="RFC" />
<format octets="33406" type="TXT" target="ftp://ftp.isi.edu/in-notes/rfc2933.txt" />
</reference>


<reference target2="reference.RFC.2934.xml" anchor="RFC2934">
<front>
<title>Protocol Independent Multicast MIB for IPv4</title>
<author fullname="K. McCloghrie" initials="K." surname="McCloghrie">
<organization />
</author>

<author fullname="D. Farinacci" initials="D." surname="Farinacci">
<organization />
</author>

<author fullname="D. Thaler" initials="D." surname="Thaler">
<organization />
</author>

<author fullname="B. Fenner" initials="B." surname="Fenner">
<organization />
</author>

<date year="2000" month="October" />
</front>

<seriesInfo value="2934" name="RFC" />
<format octets="48379" type="TXT" target="ftp://ftp.isi.edu/in-notes/rfc2934.txt" />
</reference>


<reference target2="reference.RFC.2935.xml" anchor="RFC2935">
<front>
<title>Internet Open Trading Protocol (IOTP) HTTP Supplement</title>
<author fullname="D. Eastlake" initials="D." surname="Eastlake">
<organization />
</author>

<author fullname="C. Smith" initials="C." surname="Smith">
<organization />
</author>

<date year="2000" month="September" />
</front>

<seriesInfo value="2935" name="RFC" />
<format octets="16168" type="TXT" target="ftp://ftp.isi.edu/in-notes/rfc2935.txt" />
</reference>


<reference target2="reference.RFC.2936.xml" anchor="RFC2936">
<front>
<title>HTTP MIME Type Handler Detection</title>
<author fullname="D. Eastlake" initials="D." surname="Eastlake">
<organization />
</author>

<author fullname="C. Smith" initials="C." surname="Smith">
<organization />
</author>

<author fullname="D. Soroka" initials="D." surname="Soroka">
<organization />
</author>

<date year="2000" month="September" />
</front>

<seriesInfo value="2936" name="RFC" />
<format octets="25238" type="TXT" target="ftp://ftp.isi.edu/in-notes/rfc2936.txt" />
</reference>


<reference target2="reference.RFC.2937.xml" anchor="RFC2937">
<front>
<title>The Name Service Search Option for DHCP</title>
<author fullname="C. Smith" initials="C." surname="Smith">
<organization />
</author>

<date year="2000" month="September" />
</front>

<seriesInfo value="2937" name="RFC" />
<format octets="8368" type="TXT" target="ftp://ftp.isi.edu/in-notes/rfc2937.txt" />
</reference>


<reference target2="reference.RFC.2938.xml" anchor="RFC2938">
<front>
<title>Identifying Composite Media Features</title>
<author fullname="G. Klyne" initials="G." surname="Klyne">
<organization />
</author>

<author fullname="L. Masinter" initials="L." surname="Masinter">
<organization />
</author>

<date year="2000" month="September" />
</front>

<seriesInfo value="2938" name="RFC" />
<format octets="34451" type="TXT" target="ftp://ftp.isi.edu/in-notes/rfc2938.txt" />
</reference>


<reference target2="reference.RFC.2939.xml" anchor="RFC2939">
<front>
<title>Procedures and IANA Guidelines for Definition of New DHCP Options and Message Types</title>
<author fullname="R. Droms" initials="R." surname="Droms">
<organization />
</author>

<date year="2000" month="September" />
</front>

<seriesInfo value="43" name="BCP" />
<seriesInfo value="2939" name="RFC" />
<format octets="13631" type="TXT" target="ftp://ftp.isi.edu/in-notes/rfc2939.txt" />
</reference>


<reference target2="reference.RFC.2940.xml" anchor="RFC2940">
<front>
<title>Definitions of Managed Objects for Common Open Policy Service (COPS) Protocol Clients</title>
<author fullname="A. Smith" initials="A." surname="Smith">
<organization />
</author>

<author fullname="D. Partain" initials="D." surname="Partain">
<organization />
</author>

<author fullname="J. Seligson" initials="J." surname="Seligson">
<organization />
</author>

<date year="2000" month="October" />
</front>

<seriesInfo value="2940" name="RFC" />
<format octets="52427" type="TXT" target="ftp://ftp.isi.edu/in-notes/rfc2940.txt" />
</reference>


<reference target2="reference.RFC.2941.xml" anchor="RFC2941">
<front>
<title>Telnet Authentication Option</title>
<author fullname="T. Ts&apos;o" initials="T." surname="Ts&apos;o">
<organization />
</author>

<author fullname="J. Altman" initials="J." surname="Altman">
<organization />
</author>

<date year="2000" month="September" />
</front>

<seriesInfo value="2941" name="RFC" />
<format octets="52427" type="TXT" target="ftp://ftp.isi.edu/in-notes/rfc2941.txt" />
</reference>


<reference target2="reference.RFC.2942.xml" anchor="RFC2942">
<front>
<title>Telnet Authentication: Kerberos Version 5</title>
<author fullname="T. Ts&apos;o" initials="T." surname="Ts&apos;o">
<organization />
</author>

<date year="2000" month="September" />
</front>

<seriesInfo value="2942" name="RFC" />
<format octets="14562" type="TXT" target="ftp://ftp.isi.edu/in-notes/rfc2942.txt" />
</reference>


<reference target2="reference.RFC.2943.xml" anchor="RFC2943">
<front>
<title>TELNET Authentication Using DSA</title>
<author fullname="R. Housley" initials="R." surname="Housley">
<organization />
</author>

<author fullname="T. Horting" initials="T." surname="Horting">
<organization />
</author>

<author fullname="P. Yee" initials="P." surname="Yee">
<organization />
</author>

<date year="2000" month="September" />
</front>

<seriesInfo value="2943" name="RFC" />
<format octets="21694" type="TXT" target="ftp://ftp.isi.edu/in-notes/rfc2943.txt" />
</reference>


<reference target2="reference.RFC.2944.xml" anchor="RFC2944">
<front>
<title>Telnet Authentication: SRP</title>
<author fullname="T. Wu" initials="T." surname="Wu">
<organization />
</author>

<date year="2000" month="September" />
</front>

<seriesInfo value="2944" name="RFC" />
<format octets="13933" type="TXT" target="ftp://ftp.isi.edu/in-notes/rfc2944.txt" />
</reference>


<reference target2="reference.RFC.2945.xml" anchor="RFC2945">
<front>
<title>The SRP Authentication and Key Exchange System</title>
<author fullname="T. Wu" initials="T." surname="Wu">
<organization />
</author>

<date year="2000" month="September" />
</front>

<seriesInfo value="2945" name="RFC" />
<format octets="17843" type="TXT" target="ftp://ftp.isi.edu/in-notes/rfc2945.txt" />
</reference>


<reference target2="reference.RFC.2946.xml" anchor="RFC2946">
<front>
<title>Telnet Data Encryption Option</title>
<author fullname="T. Ts&apos;o" initials="T." surname="Ts&apos;o">
<organization />
</author>

<date year="2000" month="September" />
</front>

<seriesInfo value="2946" name="RFC" />
<format octets="16527" type="TXT" target="ftp://ftp.isi.edu/in-notes/rfc2946.txt" />
</reference>


<reference target2="reference.RFC.2947.xml" anchor="RFC2947">
<front>
<title>Telnet Encryption: DES3 64 bit Cipher Feedback</title>
<author fullname="J. Altman" initials="J." surname="Altman">
<organization />
</author>

<date year="2000" month="September" />
</front>

<seriesInfo value="2947" name="RFC" />
<format octets="11064" type="TXT" target="ftp://ftp.isi.edu/in-notes/rfc2947.txt" />
</reference>


<reference target2="reference.RFC.2948.xml" anchor="RFC2948">
<front>
<title>Telnet Encryption: DES3 64 bit Output Feedback</title>
<author fullname="J. Altman" initials="J." surname="Altman">
<organization />
</author>

<date year="2000" month="September" />
</front>

<seriesInfo value="2948" name="RFC" />
<format octets="11064" type="TXT" target="ftp://ftp.isi.edu/in-notes/rfc2948.txt" />
</reference>


<reference target2="reference.RFC.2949.xml" anchor="RFC2949">
<front>
<title>Telnet Encryption: CAST-128 64 bit Output Feedback</title>
<author fullname="J. Altman" initials="J." surname="Altman">
<organization />
</author>

<date year="2000" month="September" />
</front>

<seriesInfo value="2949" name="RFC" />
<format octets="9240" type="TXT" target="ftp://ftp.isi.edu/in-notes/rfc2949.txt" />
</reference>


<reference target2="reference.RFC.2950.xml" anchor="RFC2950">
<front>
<title>Telnet Encryption: CAST-128 64 bit Cipher Feedback</title>
<author fullname="J. Altman" initials="J." surname="Altman">
<organization />
</author>

<date year="2000" month="September" />
</front>

<seriesInfo value="2950" name="RFC" />
<format octets="9267" type="TXT" target="ftp://ftp.isi.edu/in-notes/rfc2950.txt" />
</reference>


<reference target2="reference.RFC.2951.xml" anchor="RFC2951">
<front>
<title>TELNET Authentication Using KEA and SKIPJACK</title>
<author fullname="R. Housley" initials="R." surname="Housley">
<organization />
</author>

<author fullname="T. Horting" initials="T." surname="Horting">
<organization />
</author>

<author fullname="P. Yee" initials="P." surname="Yee">
<organization />
</author>

<date year="2000" month="September" />
</front>

<seriesInfo value="2951" name="RFC" />
<format octets="20757" type="TXT" target="ftp://ftp.isi.edu/in-notes/rfc2951.txt" />
</reference>


<reference target2="reference.RFC.2952.xml" anchor="RFC2952">
<front>
<title>Telnet Encryption: DES 64 bit Cipher Feedback</title>
<author fullname="T. Ts&apos;o" initials="T." surname="Ts&apos;o">
<organization />
</author>

<date year="2000" month="September" />
</front>

<seriesInfo value="2952" name="RFC" />
<format octets="9064" type="TXT" target="ftp://ftp.isi.edu/in-notes/rfc2952.txt" />
</reference>


<reference target2="reference.RFC.2953.xml" anchor="RFC2953">
<front>
<title>Telnet Encryption: DES 64 bit Output Feedback</title>
<author fullname="T. Ts&apos;o" initials="T." surname="Ts&apos;o">
<organization />
</author>

<date year="2000" month="September" />
</front>

<seriesInfo value="2953" name="RFC" />
<format octets="8995" type="TXT" target="ftp://ftp.isi.edu/in-notes/rfc2953.txt" />
</reference>


<reference target2="reference.RFC.2954.xml" anchor="RFC2954">
<front>
<title>Definitions of Managed Objects for Frame Relay Service</title>
<author fullname="K. Rehbehn" initials="K." surname="Rehbehn">
<organization />
</author>

<author fullname="D. Fowler" initials="D." surname="Fowler">
<organization />
</author>

<date year="2000" month="October" />
</front>

<seriesInfo value="2954" name="RFC" />
<format octets="164217" type="TXT" target="ftp://ftp.isi.edu/in-notes/rfc2954.txt" />
</reference>


<reference target2="reference.RFC.2955.xml" anchor="RFC2955">
<front>
<title>Definitions of Managed Objects for Monitoring and Controlling the Frame Relay/ATM PVC Service Interworking Function</title>
<author fullname="K. Rehbehn" initials="K." surname="Rehbehn">
<organization />
</author>

<author fullname="O. Nicklass" initials="O." surname="Nicklass">
<organization />
</author>

<author fullname="G. Mouradian" initials="G." surname="Mouradian">
<organization />
</author>

<date year="2000" month="October" />
</front>

<seriesInfo value="2955" name="RFC" />
<format octets="83281" type="TXT" target="ftp://ftp.isi.edu/in-notes/rfc2955.txt" />
</reference>


<reference target2="reference.RFC.2956.xml" anchor="RFC2956">
<front>
<title>Overview of 1999 IAB Network Layer Workshop</title>
<author fullname="M. Kaat" initials="M." surname="Kaat">
<organization />
</author>

<date year="2000" month="October" />
</front>

<seriesInfo value="2956" name="RFC" />
<format octets="36830" type="TXT" target="ftp://ftp.isi.edu/in-notes/rfc2956.txt" />
</reference>


<reference target2="reference.RFC.2957.xml" anchor="RFC2957">
<front>
<title>The application/whoispp-query Content-Type</title>
<author fullname="L. Daigle" initials="L." surname="Daigle">
<organization />
</author>

<author fullname="P. Faltstrom" initials="P." surname="Faltstrom">
<organization />
</author>

<date year="2000" month="October" />
</front>

<seriesInfo value="2957" name="RFC" />
<format octets="10262" type="TXT" target="ftp://ftp.isi.edu/in-notes/rfc2957.txt" />
</reference>


<reference target2="reference.RFC.2958.xml" anchor="RFC2958">
<front>
<title>The application/whoispp-response Content-type</title>
<author fullname="L. Daigle" initials="L." surname="Daigle">
<organization />
</author>

<author fullname="P. Faltstrom" initials="P." surname="Faltstrom">
<organization />
</author>

<date year="2000" month="October" />
</front>

<seriesInfo value="2958" name="RFC" />
<format octets="9995" type="TXT" target="ftp://ftp.isi.edu/in-notes/rfc2958.txt" />
</reference>


<reference target2="reference.RFC.2959.xml" anchor="RFC2959">
<front>
<title>Real-Time Transport Protocol Management Information Base</title>
<author fullname="M. Baugher" initials="M." surname="Baugher">
<organization />
</author>

<author fullname="B. Strahm" initials="B." surname="Strahm">
<organization />
</author>

<author fullname="I. Suconick" initials="I." surname="Suconick">
<organization />
</author>

<date year="2000" month="October" />
</front>

<seriesInfo value="2959" name="RFC" />
<format octets="62063" type="TXT" target="ftp://ftp.isi.edu/in-notes/rfc2959.txt" />
</reference>


<reference target2="reference.RFC.2960.xml" anchor="RFC2960">
<front>
<title>Stream Control Transmission Protocol</title>
<author fullname="R. Stewart" initials="R." surname="Stewart">
<organization />
</author>

<author fullname="Q. Xie" initials="Q." surname="Xie">
<organization />
</author>

<author fullname="K. Morneault" initials="K." surname="Morneault">
<organization />
</author>

<author fullname="C. Sharp" initials="C." surname="Sharp">
<organization />
</author>

<author fullname="H. Schwarzbauer" initials="H." surname="Schwarzbauer">
<organization />
</author>

<author fullname="T. Taylor" initials="T." surname="Taylor">
<organization />
</author>

<author fullname="I. Rytina" initials="I." surname="Rytina">
<organization />
</author>

<author fullname="M. Kalla" initials="M." surname="Kalla">
<organization />
</author>

<author fullname="L. Zhang" initials="L." surname="Zhang">
<organization />
</author>

<author fullname="V. Paxson" initials="V." surname="Paxson">
<organization />
</author>

<date year="2000" month="October" />
</front>

<seriesInfo value="2960" name="RFC" />
<format octets="297757" type="TXT" target="ftp://ftp.isi.edu/in-notes/rfc2960.txt" />
</reference>


<reference target2="reference.RFC.2961.xml" anchor="RFC2961">
<front>
<title>RSVP Refresh Overhead Reduction Extensions</title>
<author fullname="L. Berger" initials="L." surname="Berger">
<organization />
</author>

<author fullname="D. Gan" initials="D." surname="Gan">
<organization />
</author>

<author fullname="G. Swallow" initials="G." surname="Swallow">
<organization />
</author>

<author fullname="P. Pan" initials="P." surname="Pan">
<organization />
</author>

<author fullname="F. Tommasi" initials="F." surname="Tommasi">
<organization />
</author>

<author fullname="S. Molendini" initials="S." surname="Molendini">
<organization />
</author>

<date year="2001" month="April" />
</front>

<seriesInfo value="2961" name="RFC" />
<format octets="81675" type="TXT" target="ftp://ftp.isi.edu/in-notes/rfc2961.txt" />
</reference>


<reference target2="reference.RFC.2962.xml" anchor="RFC2962">
<front>
<title>An SNMP Application Level Gateway for Payload Address Translation</title>
<author fullname="D. Raz" initials="D." surname="Raz">
<organization />
</author>

<author fullname="J. Schoenwaelder" initials="J." surname="Schoenwaelder">
<organization />
</author>

<author fullname="B. Sugla" initials="B." surname="Sugla">
<organization />
</author>

<date year="2000" month="October" />
</front>

<seriesInfo value="2962" name="RFC" />
<format octets="46803" type="TXT" target="ftp://ftp.isi.edu/in-notes/rfc2962.txt" />
</reference>


<reference target2="reference.RFC.2963.xml" anchor="RFC2963">
<front>
<title>A Rate Adaptive Shaper for Differentiated Services</title>
<author fullname="O. Bonaventure" initials="O." surname="Bonaventure">
<organization />
</author>

<author fullname="S. De Cnodder" initials="S." surname="De Cnodder">
<organization />
</author>

<date year="2000" month="October" />
</front>

<seriesInfo value="2963" name="RFC" />
<format octets="39895" type="TXT" target="ftp://ftp.isi.edu/in-notes/rfc2963.txt" />
</reference>


<reference target2="reference.RFC.2964.xml" anchor="RFC2964">
<front>
<title>Use of HTTP State Management</title>
<author fullname="K. Moore" initials="K." surname="Moore">
<organization />
</author>

<author fullname="N. Freed" initials="N." surname="Freed">
<organization />
</author>

<date year="2000" month="October" />
</front>

<seriesInfo value="44" name="BCP" />
<seriesInfo value="2964" name="RFC" />
<format octets="18899" type="TXT" target="ftp://ftp.isi.edu/in-notes/rfc2964.txt" />
</reference>


<reference target2="reference.RFC.2965.xml" anchor="RFC2965">
<front>
<title>HTTP State Management Mechanism</title>
<author fullname="D. Kristol" initials="D." surname="Kristol">
<organization />
</author>

<author fullname="L. Montulli" initials="L." surname="Montulli">
<organization />
</author>

<date year="2000" month="October" />
</front>

<seriesInfo value="2965" name="RFC" />
<format octets="56176" type="TXT" target="ftp://ftp.isi.edu/in-notes/rfc2965.txt" />
</reference>


<reference target2="reference.RFC.2966.xml" anchor="RFC2966">
<front>
<title>Domain-wide Prefix Distribution with Two-Level IS-IS</title>
<author fullname="T. Li" initials="T." surname="Li">
<organization />
</author>

<author fullname="T. Przygienda" initials="T." surname="Przygienda">
<organization />
</author>

<author fullname="H. Smit" initials="H." surname="Smit">
<organization />
</author>

<date year="2000" month="October" />
</front>

<seriesInfo value="2966" name="RFC" />
<format octets="32465" type="TXT" target="ftp://ftp.isi.edu/in-notes/rfc2966.txt" />
</reference>


<reference target2="reference.RFC.2967.xml" anchor="RFC2967">
<front>
<title>TISDAG - Technical Infrastructure for Swedish Directory Access Gateways</title>
<author fullname="L. Daigle" initials="L." surname="Daigle">
<organization />
</author>

<author fullname="R. Hedberg" initials="R." surname="Hedberg">
<organization />
</author>

<date year="2000" month="October" />
</front>

<seriesInfo value="2967" name="RFC" />
<format octets="209845" type="TXT" target="ftp://ftp.isi.edu/in-notes/rfc2967.txt" />
</reference>


<reference target2="reference.RFC.2968.xml" anchor="RFC2968">
<front>
<title>Mesh of Multiple DAG servers - Results from TISDAG</title>
<author fullname="L. Daigle" initials="L." surname="Daigle">
<organization />
</author>

<author fullname="T. Eklof" initials="T." surname="Eklof">
<organization />
</author>

<date year="2000" month="October" />
</front>

<seriesInfo value="2968" name="RFC" />
<format octets="19306" type="TXT" target="ftp://ftp.isi.edu/in-notes/rfc2968.txt" />
</reference>


<reference target2="reference.RFC.2969.xml" anchor="RFC2969">
<front>
<title>Wide Area Directory Deployment - Experiences from TISDAG</title>
<author fullname="T. Eklof" initials="T." surname="Eklof">
<organization />
</author>

<author fullname="L. Daigle" initials="L." surname="Daigle">
<organization />
</author>

<date year="2000" month="October" />
</front>

<seriesInfo value="2969" name="RFC" />
<format octets="43002" type="TXT" target="ftp://ftp.isi.edu/in-notes/rfc2969.txt" />
</reference>


<reference target2="reference.RFC.2970.xml" anchor="RFC2970">
<front>
<title>Architecture for Integrated Directory Services - Result from TISDAG</title>
<author fullname="L. Daigle" initials="L." surname="Daigle">
<organization />
</author>

<author fullname="T. Eklof" initials="T." surname="Eklof">
<organization />
</author>

<date year="2000" month="October" />
</front>

<seriesInfo value="2970" name="RFC" />
<format octets="40448" type="TXT" target="ftp://ftp.isi.edu/in-notes/rfc2970.txt" />
</reference>


<reference target2="reference.RFC.2971.xml" anchor="RFC2971">
<front>
<title>IMAP4 ID extension</title>
<author fullname="T. Showalter" initials="T." surname="Showalter">
<organization />
</author>

<date year="2000" month="October" />
</front>

<seriesInfo value="2971" name="RFC" />
<format octets="14670" type="TXT" target="ftp://ftp.isi.edu/in-notes/rfc2971.txt" />
</reference>


<reference target2="reference.RFC.2972.xml" anchor="RFC2972">
<front>
<title>Context and Goals for Common Name Resolution</title>
<author fullname="N. Popp" initials="N." surname="Popp">
<organization />
</author>

<author fullname="M. Mealling" initials="M." surname="Mealling">
<organization />
</author>

<author fullname="L. Masinter" initials="L." surname="Masinter">
<organization />
</author>

<author fullname="K. Sollins" initials="K." surname="Sollins">
<organization />
</author>

<date year="2000" month="October" />
</front>

<seriesInfo value="2972" name="RFC" />
<format octets="26252" type="TXT" target="ftp://ftp.isi.edu/in-notes/rfc2972.txt" />
</reference>


<reference target2="reference.RFC.2973.xml" anchor="RFC2973">
<front>
<title>IS-IS Mesh Groups</title>
<author fullname="R. Balay" initials="R." surname="Balay">
<organization />
</author>

<author fullname="D. Katz" initials="D." surname="Katz">
<organization />
</author>

<author fullname="J. Parker" initials="J." surname="Parker">
<organization />
</author>

<date year="2000" month="October" />
</front>

<seriesInfo value="2973" name="RFC" />
<format octets="14846" type="TXT" target="ftp://ftp.isi.edu/in-notes/rfc2973.txt" />
</reference>


<reference target2="reference.RFC.2974.xml" anchor="RFC2974">
<front>
<title>Session Announcement Protocol</title>
<author fullname="M. Handley" initials="M." surname="Handley">
<organization />
</author>

<author fullname="C. Perkins" initials="C." surname="Perkins">
<organization />
</author>

<author fullname="E. Whelan" initials="E." surname="Whelan">
<organization />
</author>

<date year="2000" month="October" />
</front>

<seriesInfo value="2974" name="RFC" />
<format octets="40129" type="TXT" target="ftp://ftp.isi.edu/in-notes/rfc2974.txt" />
</reference>


<reference target2="reference.RFC.2975.xml" anchor="RFC2975">
<front>
<title>Introduction to Accounting Management</title>
<author fullname="B. Aboba" initials="B." surname="Aboba">
<organization />
</author>

<author fullname="J. Arkko" initials="J." surname="Arkko">
<organization />
</author>

<author fullname="D. Harrington" initials="D." surname="Harrington">
<organization />
</author>

<date year="2000" month="October" />
</front>

<seriesInfo value="2975" name="RFC" />
<format octets="129771" type="TXT" target="ftp://ftp.isi.edu/in-notes/rfc2975.txt" />
</reference>


<reference target2="reference.RFC.2976.xml" anchor="RFC2976">
<front>
<title>The SIP INFO Method</title>
<author fullname="S. Donovan" initials="S." surname="Donovan">
<organization />
</author>

<date year="2000" month="October" />
</front>

<seriesInfo value="2976" name="RFC" />
<format octets="17736" type="TXT" target="ftp://ftp.isi.edu/in-notes/rfc2976.txt" />
</reference>


<reference target2="reference.RFC.2977.xml" anchor="RFC2977">
<front>
<title>Mobile IP Authentication, Authorization, and Accounting Requirements</title>
<author fullname="S. Glass" initials="S." surname="Glass">
<organization />
</author>

<author fullname="T. Hiller" initials="T." surname="Hiller">
<organization />
</author>

<author fullname="S. Jacobs" initials="S." surname="Jacobs">
<organization />
</author>

<author fullname="C. Perkins" initials="C." surname="Perkins">
<organization />
</author>

<date year="2000" month="October" />
</front>

<seriesInfo value="2977" name="RFC" />
<format octets="63520" type="TXT" target="ftp://ftp.isi.edu/in-notes/rfc2977.txt" />
</reference>


<reference target2="reference.RFC.2978.xml" anchor="RFC2978">
<front>
<title>IANA Charset Registration Procedures</title>
<author fullname="N. Freed" initials="N." surname="Freed">
<organization />
</author>

<author fullname="J. Postel" initials="J." surname="Postel">
<organization />
</author>

<date year="2000" month="October" />
</front>

<seriesInfo value="19" name="BCP" />
<seriesInfo value="2978" name="RFC" />
<format octets="21615" type="TXT" target="ftp://ftp.isi.edu/in-notes/rfc2978.txt" />
</reference>


<reference target2="reference.RFC.2979.xml" anchor="RFC2979">
<front>
<title>Behavior of and Requirements for Internet Firewalls</title>
<author fullname="N. Freed" initials="N." surname="Freed">
<organization />
</author>

<date year="2000" month="October" />
</front>

<seriesInfo value="2979" name="RFC" />
<format octets="14350" type="TXT" target="ftp://ftp.isi.edu/in-notes/rfc2979.txt" />
</reference>


<reference target2="reference.RFC.2980.xml" anchor="RFC2980">
<front>
<title>Common NNTP Extensions</title>
<author fullname="S. Barber" initials="S." surname="Barber">
<organization />
</author>

<date year="2000" month="October" />
</front>

<seriesInfo value="2980" name="RFC" />
<format octets="57165" type="TXT" target="ftp://ftp.isi.edu/in-notes/rfc2980.txt" />
</reference>


<reference target2="reference.RFC.2981.xml" anchor="RFC2981">
<front>
<title>Event MIB</title>
<author fullname="R. Kavasseri" initials="R." surname="Kavasseri">
<organization />
</author>

<date year="2000" month="October" />
</front>

<seriesInfo value="2981" name="RFC" />
<format octets="98248" type="TXT" target="ftp://ftp.isi.edu/in-notes/rfc2981.txt" />
</reference>


<reference target2="reference.RFC.2982.xml" anchor="RFC2982">
<front>
<title>Distributed Management Expression MIB</title>
<author fullname="R. Kavasseri" initials="R." surname="Kavasseri">
<organization />
</author>

<date year="2000" month="October" />
</front>

<seriesInfo value="2982" name="RFC" />
<format octets="81371" type="TXT" target="ftp://ftp.isi.edu/in-notes/rfc2982.txt" />
</reference>


<reference target2="reference.RFC.2983.xml" anchor="RFC2983">
<front>
<title>Differentiated Services and Tunnels</title>
<author fullname="D. Black" initials="D." surname="Black">
<organization />
</author>

<date year="2000" month="October" />
</front>

<seriesInfo value="2983" name="RFC" />
<format octets="35644" type="TXT" target="ftp://ftp.isi.edu/in-notes/rfc2983.txt" />
</reference>


<reference target2="reference.RFC.2984.xml" anchor="RFC2984">
<front>
<title>Use of the CAST-128 Encryption Algorithm in CMS</title>
<author fullname="C. Adams" initials="C." surname="Adams">
<organization />
</author>

<date year="2000" month="October" />
</front>

<seriesInfo value="2984" name="RFC" />
<format octets="11591" type="TXT" target="ftp://ftp.isi.edu/in-notes/rfc2984.txt" />
</reference>


<reference target2="reference.RFC.2985.xml" anchor="RFC2985">
<front>
<title>PKCS #9: Selected Object Classes and Attribute Types Version 2.0</title>
<author fullname="M. Nystrom" initials="M." surname="Nystrom">
<organization />
</author>

<author fullname="B. Kaliski" initials="B." surname="Kaliski">
<organization />
</author>

<date year="2000" month="November" />
</front>

<seriesInfo value="2985" name="RFC" />
<format octets="70703" type="TXT" target="ftp://ftp.isi.edu/in-notes/rfc2985.txt" />
</reference>


<reference target2="reference.RFC.2986.xml" anchor="RFC2986">
<front>
<title>PKCS #10: Certification Request Syntax Specification Version 1.7</title>
<author fullname="M. Nystrom" initials="M." surname="Nystrom">
<organization />
</author>

<author fullname="B. Kaliski" initials="B." surname="Kaliski">
<organization />
</author>

<date year="2000" month="November" />
</front>

<seriesInfo value="2986" name="RFC" />
<format octets="27794" type="TXT" target="ftp://ftp.isi.edu/in-notes/rfc2986.txt" />
</reference>


<reference target2="reference.RFC.2987.xml" anchor="RFC2987">
<front>
<title>Registration of Charset and Languages Media Features Tags</title>
<author fullname="P. Hoffman" initials="P." surname="Hoffman">
<organization />
</author>

<date year="2000" month="November" />
</front>

<seriesInfo value="2987" name="RFC" />
<format octets="8799" type="TXT" target="ftp://ftp.isi.edu/in-notes/rfc2987.txt" />
</reference>


<reference target2="reference.RFC.2988.xml" anchor="RFC2988">
<front>
<title>Computing TCP's Retransmission Timer</title>
<author fullname="V. Paxson" initials="V." surname="Paxson">
<organization />
</author>

<author fullname="M. Allman" initials="M." surname="Allman">
<organization />
</author>

<date year="2000" month="November" />
</front>

<seriesInfo value="2988" name="RFC" />
<format octets="15280" type="TXT" target="ftp://ftp.isi.edu/in-notes/rfc2988.txt" />
</reference>


<reference target2="reference.RFC.2989.xml" anchor="RFC2989">
<front>
<title>Criteria for Evaluating AAA Protocols for Network Access</title>
<author fullname="B. Aboba" initials="B." surname="Aboba">
<organization />
</author>

<author fullname="P. Calhoun" initials="P." surname="Calhoun">
<organization />
</author>

<author fullname="S. Glass" initials="S." surname="Glass">
<organization />
</author>

<author fullname="T. Hiller" initials="T." surname="Hiller">
<organization />
</author>

<author fullname="P. McCann" initials="P." surname="McCann">
<organization />
</author>

<author fullname="H. Shiino" initials="H." surname="Shiino">
<organization />
</author>

<author fullname="G. Zorn" initials="G." surname="Zorn">
<organization />
</author>

<author fullname="G. Dommety" initials="G." surname="Dommety">
<organization />
</author>

<author fullname="C. Perkins" initials="C." surname="Perkins">
<organization />
</author>

<author fullname="B. Patil" initials="B." surname="Patil">
<organization />
</author>

<author fullname="D. Mitton" initials="D." surname="Mitton">
<organization />
</author>

<author fullname="S. Manning" initials="S." surname="Manning">
<organization />
</author>

<author fullname="M. Beadles" initials="M." surname="Beadles">
<organization />
</author>

<author fullname="P. Walsh" initials="P." surname="Walsh">
<organization />
</author>

<author fullname="X. Chen" initials="X." surname="Chen">
<organization />
</author>

<author fullname="S. Sivalingham" initials="S." surname="Sivalingham">
<organization />
</author>

<author fullname="A. Hameed" initials="A." surname="Hameed">
<organization />
</author>

<author fullname="M. Munson" initials="M." surname="Munson">
<organization />
</author>

<author fullname="S. Jacobs" initials="S." surname="Jacobs">
<organization />
</author>

<author fullname="B. Lim" initials="B." surname="Lim">
<organization />
</author>

<author fullname="B. Hirschman" initials="B." surname="Hirschman">
<organization />
</author>

<author fullname="R. Hsu" initials="R." surname="Hsu">
<organization />
</author>

<author fullname="Y. Xu" initials="Y." surname="Xu">
<organization />
</author>

<author fullname="E. Campbell" initials="E." surname="Campbell">
<organization />
</author>

<author fullname="S. Baba" initials="S." surname="Baba">
<organization />
</author>

<author fullname="E. Jaques" initials="E." surname="Jaques">
<organization />
</author>

<date year="2000" month="November" />
</front>

<seriesInfo value="2989" name="RFC" />
<format octets="53197" type="TXT" target="ftp://ftp.isi.edu/in-notes/rfc2989.txt" />
</reference>


<reference target2="reference.RFC.2990.xml" anchor="RFC2990">
<front>
<title>Next Steps for the IP QoS Architecture</title>
<author fullname="G. Huston" initials="G." surname="Huston">
<organization />
</author>

<date year="2000" month="November" />
</front>

<seriesInfo value="2990" name="RFC" />
<format octets="65450" type="TXT" target="ftp://ftp.isi.edu/in-notes/rfc2990.txt" />
</reference>


<reference target2="reference.RFC.2991.xml" anchor="RFC2991">
<front>
<title>Multipath Issues in Unicast and Multicast Next-Hop Selection</title>
<author fullname="D. Thaler" initials="D." surname="Thaler">
<organization />
</author>

<author fullname="C. Hopps" initials="C." surname="Hopps">
<organization />
</author>

<date year="2000" month="November" />
</front>

<seriesInfo value="2991" name="RFC" />
<format octets="17796" type="TXT" target="ftp://ftp.isi.edu/in-notes/rfc2991.txt" />
</reference>


<reference target2="reference.RFC.2992.xml" anchor="RFC2992">
<front>
<title>Analysis of an Equal-Cost Multi-Path Algorithm</title>
<author fullname="C. Hopps" initials="C." surname="Hopps">
<organization />
</author>

<date year="2000" month="November" />
</front>

<seriesInfo value="2992" name="RFC" />
<format octets="17524" type="TXT" target="ftp://ftp.isi.edu/in-notes/rfc2992.txt" />
</reference>


<reference target2="reference.RFC.2993.xml" anchor="RFC2993">
<front>
<title>Architectural Implications of NAT</title>
<author fullname="T. Hain" initials="T." surname="Hain">
<organization />
</author>

<date year="2000" month="November" />
</front>

<seriesInfo value="2993" name="RFC" />
<format octets="74136" type="TXT" target="ftp://ftp.isi.edu/in-notes/rfc2993.txt" />
</reference>


<reference target2="reference.RFC.2994.xml" anchor="RFC2994">
<front>
<title>A Description of the MISTY1 Encryption Algorithm</title>
<author fullname="H. Ohta" initials="H." surname="Ohta">
<organization />
</author>

<author fullname="M. Matsui" initials="M." surname="Matsui">
<organization />
</author>

<date year="2000" month="November" />
</front>

<seriesInfo value="2994" name="RFC" />
<format octets="17803" type="TXT" target="ftp://ftp.isi.edu/in-notes/rfc2994.txt" />
</reference>


<reference target2="reference.RFC.2995.xml" anchor="RFC2995">
<front>
<title>Pre-Spirits Implementations of PSTN-initiated Services</title>
<author fullname="H. Lu" initials="H." surname="Lu">
<organization />
</author>

<author fullname="I. Faynberg" initials="I." surname="Faynberg">
<organization />
</author>

<author fullname="J. Voelker" initials="J." surname="Voelker">
<organization />
</author>

<author fullname="M. Weissman" initials="M." surname="Weissman">
<organization />
</author>

<author fullname="W. Zhang" initials="W." surname="Zhang">
<organization />
</author>

<author fullname="S. Rhim" initials="S." surname="Rhim">
<organization />
</author>

<author fullname="J. Hwang" initials="J." surname="Hwang">
<organization />
</author>

<author fullname="S. Ago" initials="S." surname="Ago">
<organization />
</author>

<author fullname="S. Moeenuddin" initials="S." surname="Moeenuddin">
<organization />
</author>

<author fullname="S. Hadvani" initials="S." surname="Hadvani">
<organization />
</author>

<author fullname="S. Nyckelgard" initials="S." surname="Nyckelgard">
<organization />
</author>

<author fullname="J. Yoakum" initials="J." surname="Yoakum">
<organization />
</author>

<author fullname="L. Robart" initials="L." surname="Robart">
<organization />
</author>

<date year="2000" month="November" />
</front>

<seriesInfo value="2995" name="RFC" />
<format octets="96427" type="TXT" target="ftp://ftp.isi.edu/in-notes/rfc2995.txt" />
</reference>


<reference target2="reference.RFC.2996.xml" anchor="RFC2996">
<front>
<title>Format of the RSVP DCLASS Object</title>
<author fullname="Y. Bernet" initials="Y." surname="Bernet">
<organization />
</author>

<date year="2000" month="November" />
</front>

<seriesInfo value="2996" name="RFC" />
<format octets="18929" type="TXT" target="ftp://ftp.isi.edu/in-notes/rfc2996.txt" />
</reference>


<reference target2="reference.RFC.2997.xml" anchor="RFC2997">
<front>
<title>Specification of the Null Service Type</title>
<author fullname="Y. Bernet" initials="Y." surname="Bernet">
<organization />
</author>

<author fullname="A. Smith" initials="A." surname="Smith">
<organization />
</author>

<author fullname="B. Davie" initials="B." surname="Davie">
<organization />
</author>

<date year="2000" month="November" />
</front>

<seriesInfo value="2997" name="RFC" />
<format octets="25071" type="TXT" target="ftp://ftp.isi.edu/in-notes/rfc2997.txt" />
</reference>


<reference target2="reference.RFC.2998.xml" anchor="RFC2998">
<front>
<title>A Framework for Integrated Services Operation over Diffserv Networks</title>
<author fullname="Y. Bernet" initials="Y." surname="Bernet">
<organization />
</author>

<author fullname="P. Ford" initials="P." surname="Ford">
<organization />
</author>

<author fullname="R. Yavatkar" initials="R." surname="Yavatkar">
<organization />
</author>

<author fullname="F. Baker" initials="F." surname="Baker">
<organization />
</author>

<author fullname="L. Zhang" initials="L." surname="Zhang">
<organization />
</author>

<author fullname="M. Speer" initials="M." surname="Speer">
<organization />
</author>

<author fullname="R. Braden" initials="R." surname="Braden">
<organization />
</author>

<author fullname="B. Davie" initials="B." surname="Davie">
<organization />
</author>

<author fullname="J. Wroclawski" initials="J." surname="Wroclawski">
<organization />
</author>

<author fullname="E. Felstaine" initials="E." surname="Felstaine">
<organization />
</author>

<date year="2000" month="November" />
</front>

<seriesInfo value="2998" name="RFC" />
<format octets="76378" type="TXT" target="ftp://ftp.isi.edu/in-notes/rfc2998.txt" />
</reference>


<reference target2="reference.RFC.2999.xml" anchor="RFC2999">
<front>
<title>Request for Comments Summary RFC Numbers 2900-2999</title>
<author fullname="S. Ginoza" initials="S." surname="Ginoza">
<organization />
</author>

<date year="2001" month="August" />
</front>

<seriesInfo value="2999" name="RFC" />
<format octets="45307" type="TXT" target="ftp://ftp.isi.edu/in-notes/rfc2999.txt" />
</reference>


<reference target2="reference.RFC.3000.xml" anchor="RFC3000">
<front>
<title>Internet Official Protocol Standards</title>
<author fullname="J. Reynolds" initials="J." surname="Reynolds">
<organization />
</author>

<author fullname="R. Braden" initials="R." surname="Braden">
<organization />
</author>

<author fullname="S. Ginoza" initials="S." surname="Ginoza">
<organization />
</author>

<author fullname="L. Shiota" initials="L." surname="Shiota">
<organization />
</author>

<date year="2001" month="November" />
</front>

<seriesInfo value="3000" name="RFC" />
<format octets="115207" type="TXT" target="ftp://ftp.isi.edu/in-notes/rfc3000.txt" />
</reference>


<reference target2="reference.RFC.3001.xml" anchor="RFC3001">
<front>
<title>A URN Namespace of Object Identifiers</title>
<author fullname="M. Mealling" initials="M." surname="Mealling">
<organization />
</author>

<date year="2000" month="November" />
</front>

<seriesInfo value="3001" name="RFC" />
<format octets="7459" type="TXT" target="ftp://ftp.isi.edu/in-notes/rfc3001.txt" />
</reference>


<reference target2="reference.RFC.3002.xml" anchor="RFC3002">
<front>
<title>Overview of 2000 IAB Wireless Internetworking Workshop</title>
<author fullname="D. Mitzel" initials="D." surname="Mitzel">
<organization />
</author>

<date year="2000" month="December" />
</front>

<seriesInfo value="3002" name="RFC" />
<format octets="101466" type="TXT" target="ftp://ftp.isi.edu/in-notes/rfc3002.txt" />
</reference>


<reference target2="reference.RFC.3003.xml" anchor="RFC3003">
<front>
<title>The audio/mpeg Media Type</title>
<author fullname="M. Nilsson" initials="M." surname="Nilsson">
<organization />
</author>

<date year="2000" month="November" />
</front>

<seriesInfo value="3003" name="RFC" />
<format octets="8381" type="TXT" target="ftp://ftp.isi.edu/in-notes/rfc3003.txt" />
</reference>


<reference target2="reference.RFC.3004.xml" anchor="RFC3004">
<front>
<title>The User Class Option for DHCP</title>
<author fullname="G. Stump" initials="G." surname="Stump">
<organization />
</author>

<author fullname="R. Droms" initials="R." surname="Droms">
<organization />
</author>

<author fullname="Y. Gu" initials="Y." surname="Gu">
<organization />
</author>

<author fullname="R. Vyaghrapuri" initials="R." surname="Vyaghrapuri">
<organization />
</author>

<author fullname="A. Demirtjis" initials="A." surname="Demirtjis">
<organization />
</author>

<author fullname="B. Beser" initials="B." surname="Beser">
<organization />
</author>

<author fullname="J. Privat" initials="J." surname="Privat">
<organization />
</author>

<date year="2000" month="November" />
</front>

<seriesInfo value="3004" name="RFC" />
<format octets="10423" type="TXT" target="ftp://ftp.isi.edu/in-notes/rfc3004.txt" />
</reference>


<reference target2="reference.RFC.3005.xml" anchor="RFC3005">
<front>
<title>IETF Discussion List Charter</title>
<author fullname="S. Harris" initials="S." surname="Harris">
<organization />
</author>

<date year="2000" month="November" />
</front>

<seriesInfo value="45" name="BCP" />
<seriesInfo value="3005" name="RFC" />
<format octets="5682" type="TXT" target="ftp://ftp.isi.edu/in-notes/rfc3005.txt" />
</reference>


<reference target2="reference.RFC.3006.xml" anchor="RFC3006">
<front>
<title>Integrated Services in the Presence of Compressible Flows</title>
<author fullname="B. Davie" initials="B." surname="Davie">
<organization />
</author>

<author fullname="C. Iturralde" initials="C." surname="Iturralde">
<organization />
</author>

<author fullname="D. Oran" initials="D." surname="Oran">
<organization />
</author>

<author fullname="S. Casner" initials="S." surname="Casner">
<organization />
</author>

<author fullname="J. Wroclawski" initials="J." surname="Wroclawski">
<organization />
</author>

<date year="2000" month="November" />
</front>

<seriesInfo value="3006" name="RFC" />
<format octets="31588" type="TXT" target="ftp://ftp.isi.edu/in-notes/rfc3006.txt" />
</reference>


<reference target2="reference.RFC.3007.xml" anchor="RFC3007">
<front>
<title>Secure Domain Name System (DNS) Dynamic Update</title>
<author fullname="B. Wellington" initials="B." surname="Wellington">
<organization />
</author>

<date year="2000" month="November" />
</front>

<seriesInfo value="3007" name="RFC" />
<format octets="18056" type="TXT" target="ftp://ftp.isi.edu/in-notes/rfc3007.txt" />
</reference>


<reference target2="reference.RFC.3008.xml" anchor="RFC3008">
<front>
<title>Domain Name System Security (DNSSEC) Signing Authority</title>
<author fullname="B. Wellington" initials="B." surname="Wellington">
<organization />
</author>

<date year="2000" month="November" />
</front>

<seriesInfo value="3008" name="RFC" />
<format octets="13484" type="TXT" target="ftp://ftp.isi.edu/in-notes/rfc3008.txt" />
</reference>


<reference target2="reference.RFC.3009.xml" anchor="RFC3009">
<front>
<title>Registration of parityfec MIME types</title>
<author fullname="J. Rosenberg" initials="J." surname="Rosenberg">
<organization />
</author>

<author fullname="H. Schulzrinne" initials="H." surname="Schulzrinne">
<organization />
</author>

<date year="2000" month="November" />
</front>

<seriesInfo value="3009" name="RFC" />
<format octets="16022" type="TXT" target="ftp://ftp.isi.edu/in-notes/rfc3009.txt" />
</reference>


<reference target2="reference.RFC.3010.xml" anchor="RFC3010">
<front>
<title>NFS version 4 Protocol</title>
<author fullname="S. Shepler" initials="S." surname="Shepler">
<organization />
</author>

<author fullname="B. Callaghan" initials="B." surname="Callaghan">
<organization />
</author>

<author fullname="D. Robinson" initials="D." surname="Robinson">
<organization />
</author>

<author fullname="R. Thurlow" initials="R." surname="Thurlow">
<organization />
</author>

<author fullname="C. Beame" initials="C." surname="Beame">
<organization />
</author>

<author fullname="M. Eisler" initials="M." surname="Eisler">
<organization />
</author>

<author fullname="D. Noveck" initials="D." surname="Noveck">
<organization />
</author>

<date year="2000" month="December" />
</front>

<seriesInfo value="3010" name="RFC" />
<format octets="450434" type="TXT" target="ftp://ftp.isi.edu/in-notes/rfc3010.txt" />
</reference>


<reference target2="reference.RFC.3011.xml" anchor="RFC3011">
<front>
<title>The IPv4 Subnet Selection Option for DHCP</title>
<author fullname="G. Waters" initials="G." surname="Waters">
<organization />
</author>

<date year="2000" month="November" />
</front>

<seriesInfo value="3011" name="RFC" />
<format octets="13967" type="TXT" target="ftp://ftp.isi.edu/in-notes/rfc3011.txt" />
</reference>


<reference target2="reference.RFC.3012.xml" anchor="RFC3012">
<front>
<title>Mobile IPv4 Challenge/Response Extensions</title>
<author fullname="C. Perkins" initials="C." surname="Perkins">
<organization />
</author>

<author fullname="P. Calhoun" initials="P." surname="Calhoun">
<organization />
</author>

<date year="2000" month="November" />
</front>

<seriesInfo value="3012" name="RFC" />
<format octets="37005" type="TXT" target="ftp://ftp.isi.edu/in-notes/rfc3012.txt" />
</reference>


<reference target2="reference.RFC.3013.xml" anchor="RFC3013">
<front>
<title>Recommended Internet Service Provider Security Services and Procedures</title>
<author fullname="T. Killalea" initials="T." surname="Killalea">
<organization />
</author>

<date year="2000" month="November" />
</front>

<seriesInfo value="46" name="BCP" />
<seriesInfo value="3013" name="RFC" />
<format octets="27905" type="TXT" target="ftp://ftp.isi.edu/in-notes/rfc3013.txt" />
</reference>


<reference target2="reference.RFC.3014.xml" anchor="RFC3014">
<front>
<title>Notification Log MIB</title>
<author fullname="R. Kavasseri" initials="R." surname="Kavasseri">
<organization />
</author>

<date year="2000" month="November" />
</front>

<seriesInfo value="3014" name="RFC" />
<format octets="48287" type="TXT" target="ftp://ftp.isi.edu/in-notes/rfc3014.txt" />
</reference>


<reference target2="reference.RFC.3015.xml" anchor="RFC3015">
<front>
<title>Megaco Protocol Version 1.0</title>
<author fullname="F. Cuervo" initials="F." surname="Cuervo">
<organization />
</author>

<author fullname="N. Greene" initials="N." surname="Greene">
<organization />
</author>

<author fullname="A. Rayhan" initials="A." surname="Rayhan">
<organization />
</author>

<author fullname="C. Huitema" initials="C." surname="Huitema">
<organization />
</author>

<author fullname="B. Rosen" initials="B." surname="Rosen">
<organization />
</author>

<author fullname="J. Segers" initials="J." surname="Segers">
<organization />
</author>

<date year="2000" month="November" />
</front>

<seriesInfo value="3015" name="RFC" />
<format octets="385432" type="TXT" target="ftp://ftp.isi.edu/in-notes/rfc3015.txt" />
</reference>


<reference target2="reference.RFC.3016.xml" anchor="RFC3016">
<front>
<title>RTP Payload Format for MPEG-4 Audio/Visual Streams</title>
<author fullname="Y. Kikuchi" initials="Y." surname="Kikuchi">
<organization />
</author>

<author fullname="T. Nomura" initials="T." surname="Nomura">
<organization />
</author>

<author fullname="S. Fukunaga" initials="S." surname="Fukunaga">
<organization />
</author>

<author fullname="Y. Matsui" initials="Y." surname="Matsui">
<organization />
</author>

<author fullname="H. Kimata" initials="H." surname="Kimata">
<organization />
</author>

<date year="2000" month="November" />
</front>

<seriesInfo value="3016" name="RFC" />
<format octets="47070" type="TXT" target="ftp://ftp.isi.edu/in-notes/rfc3016.txt" />
</reference>


<reference target2="reference.RFC.3017.xml" anchor="RFC3017">
<front>
<title>XML DTD for Roaming Access Phone Book</title>
<author fullname="M. Riegel" initials="M." surname="Riegel">
<organization />
</author>

<author fullname="G. Zorn" initials="G." surname="Zorn">
<organization />
</author>

<date year="2000" month="December" />
</front>

<seriesInfo value="3017" name="RFC" />
<format octets="59762" type="TXT" target="ftp://ftp.isi.edu/in-notes/rfc3017.txt" />
</reference>


<reference target2="reference.RFC.3018.xml" anchor="RFC3018">
<front>
<title>Unified Memory Space Protocol Specification</title>
<author fullname="A. Bogdanov" initials="A." surname="Bogdanov">
<organization />
</author>

<date year="2000" month="December" />
</front>

<seriesInfo value="3018" name="RFC" />
<format octets="177783" type="TXT" target="ftp://ftp.isi.edu/in-notes/rfc3018.txt" />
</reference>


<reference target2="reference.RFC.3019.xml" anchor="RFC3019">
<front>
<title>IP Version 6 Management Information Base for The Multicast Listener Discovery Protocol</title>
<author fullname="B. Haberman" initials="B." surname="Haberman">
<organization />
</author>

<author fullname="R. Worzella" initials="R." surname="Worzella">
<organization />
</author>

<date year="2001" month="January" />
</front>

<seriesInfo value="3019" name="RFC" />
<format octets="28293" type="TXT" target="ftp://ftp.isi.edu/in-notes/rfc3019.txt" />
</reference>


<reference target2="reference.RFC.3020.xml" anchor="RFC3020">
<front>
<title>Definitions of Managed Objects for Monitoring and Controlling the UNI/NNI Multilink Frame Relay Function</title>
<author fullname="P. Pate" initials="P." surname="Pate">
<organization />
</author>

<author fullname="B. Lynch" initials="B." surname="Lynch">
<organization />
</author>

<author fullname="K. Rehbehn" initials="K." surname="Rehbehn">
<organization />
</author>

<date year="2000" month="December" />
</front>

<seriesInfo value="3020" name="RFC" />
<format octets="67736" type="TXT" target="ftp://ftp.isi.edu/in-notes/rfc3020.txt" />
</reference>


<reference target2="reference.RFC.3021.xml" anchor="RFC3021">
<front>
<title>Using 31-Bit Prefixes on IPv4 Point-to-Point Links</title>
<author fullname="A. Retana" initials="A." surname="Retana">
<organization />
</author>

<author fullname="R. White" initials="R." surname="White">
<organization />
</author>

<author fullname="V. Fuller" initials="V." surname="Fuller">
<organization />
</author>

<author fullname="D. McPherson" initials="D." surname="McPherson">
<organization />
</author>

<date year="2000" month="December" />
</front>

<seriesInfo value="3021" name="RFC" />
<format octets="19771" type="TXT" target="ftp://ftp.isi.edu/in-notes/rfc3021.txt" />
</reference>


<reference target2="reference.RFC.3022.xml" anchor="RFC3022">
<front>
<title>Traditional IP Network Address Translator (Traditional NAT)</title>
<author fullname="P. Srisuresh" initials="P." surname="Srisuresh">
<organization />
</author>

<author fullname="K. Egevang" initials="K." surname="Egevang">
<organization />
</author>

<date year="2001" month="January" />
</front>

<seriesInfo value="3022" name="RFC" />
<format octets="37675" type="TXT" target="ftp://ftp.isi.edu/in-notes/rfc3022.txt" />
</reference>


<reference target2="reference.RFC.3023.xml" anchor="RFC3023">
<front>
<title>XML Media Types</title>
<author fullname="M. Murata" initials="M." surname="Murata">
<organization />
</author>

<author fullname="S. St. Laurent" initials="S." surname="St. Laurent">
<organization />
</author>

<author fullname="D. Kohn" initials="D." surname="Kohn">
<organization />
</author>

<date year="2001" month="January" />
</front>

<seriesInfo value="3023" name="RFC" />
<format octets="86011" type="TXT" target="ftp://ftp.isi.edu/in-notes/rfc3023.txt" />
</reference>


<reference target2="reference.RFC.3024.xml" anchor="RFC3024">
<front>
<title>Reverse Tunneling for Mobile IP, revised</title>
<author fullname="G. Montenegro" initials="G." surname="Montenegro">
<organization />
</author>

<date year="2001" month="January" />
</front>

<seriesInfo value="3024" name="RFC" />
<format octets="63929" type="TXT" target="ftp://ftp.isi.edu/in-notes/rfc3024.txt" />
</reference>


<reference target2="reference.RFC.3025.xml" anchor="RFC3025">
<front>
<title>Mobile IP Vendor/Organization-Specific Extensions</title>
<author fullname="G. Dommety" initials="G." surname="Dommety">
<organization />
</author>

<author fullname="K. Leung" initials="K." surname="Leung">
<organization />
</author>

<date year="2001" month="February" />
</front>

<seriesInfo value="3025" name="RFC" />
<format octets="15611" type="TXT" target="ftp://ftp.isi.edu/in-notes/rfc3025.txt" />
</reference>


<reference target2="reference.RFC.3026.xml" anchor="RFC3026">
<front>
<title>Liaison to IETF/ISOC on ENUM</title>
<author fullname="R. Blane" initials="R." surname="Blane">
<organization />
</author>

<date year="2001" month="January" />
</front>

<seriesInfo value="3026" name="RFC" />
<format octets="11460" type="TXT" target="ftp://ftp.isi.edu/in-notes/rfc3026.txt" />
</reference>


<reference target2="reference.RFC.3027.xml" anchor="RFC3027">
<front>
<title>Protocol Complications with the IP Network Address Translator</title>
<author fullname="M. Holdrege" initials="M." surname="Holdrege">
<organization />
</author>

<author fullname="P. Srisuresh" initials="P." surname="Srisuresh">
<organization />
</author>

<date year="2001" month="January" />
</front>

<seriesInfo value="3027" name="RFC" />
<format octets="48662" type="TXT" target="ftp://ftp.isi.edu/in-notes/rfc3027.txt" />
</reference>


<reference target2="reference.RFC.3028.xml" anchor="RFC3028">
<front>
<title>Sieve: A Mail Filtering Language</title>
<author fullname="T. Showalter" initials="T." surname="Showalter">
<organization />
</author>

<date year="2001" month="January" />
</front>

<seriesInfo value="3028" name="RFC" />
<format octets="73582" type="TXT" target="ftp://ftp.isi.edu/in-notes/rfc3028.txt" />
</reference>


<reference target2="reference.RFC.3029.xml" anchor="RFC3029">
<front>
<title>Internet X.509 Public Key Infrastructure Data Validation and Certification Server Protocols</title>
<author fullname="C. Adams" initials="C." surname="Adams">
<organization />
</author>

<author fullname="P. Sylvester" initials="P." surname="Sylvester">
<organization />
</author>

<author fullname="M. Zolotarev" initials="M." surname="Zolotarev">
<organization />
</author>

<author fullname="R. Zuccherato" initials="R." surname="Zuccherato">
<organization />
</author>

<date year="2001" month="February" />
</front>

<seriesInfo value="3029" name="RFC" />
<format octets="107347" type="TXT" target="ftp://ftp.isi.edu/in-notes/rfc3029.txt" />
</reference>


<reference target2="reference.RFC.3030.xml" anchor="RFC3030">
<front>
<title>SMTP Service Extensions for Transmission of Large and Binary MIME Messages</title>
<author fullname="G. Vaudreuil" initials="G." surname="Vaudreuil">
<organization />
</author>

<date year="2000" month="December" />
</front>

<seriesInfo value="3030" name="RFC" />
<format octets="23405" type="TXT" target="ftp://ftp.isi.edu/in-notes/rfc3030.txt" />
</reference>


<reference target2="reference.RFC.3031.xml" anchor="RFC3031">
<front>
<title>Multiprotocol Label Switching Architecture</title>
<author fullname="E. Rosen" initials="E." surname="Rosen">
<organization />
</author>

<author fullname="A. Viswanathan" initials="A." surname="Viswanathan">
<organization />
</author>

<author fullname="R. Callon" initials="R." surname="Callon">
<organization />
</author>

<date year="2001" month="January" />
</front>

<seriesInfo value="3031" name="RFC" />
<format octets="147175" type="TXT" target="ftp://ftp.isi.edu/in-notes/rfc3031.txt" />
</reference>


<reference target2="reference.RFC.3032.xml" anchor="RFC3032">
<front>
<title>MPLS Label Stack Encoding</title>
<author fullname="E. Rosen" initials="E." surname="Rosen">
<organization />
</author>

<author fullname="D. Tappan" initials="D." surname="Tappan">
<organization />
</author>

<author fullname="G. Fedorkow" initials="G." surname="Fedorkow">
<organization />
</author>

<author fullname="Y. Rekhter" initials="Y." surname="Rekhter">
<organization />
</author>

<author fullname="D. Farinacci" initials="D." surname="Farinacci">
<organization />
</author>

<author fullname="T. Li" initials="T." surname="Li">
<organization />
</author>

<author fullname="A. Conta" initials="A." surname="Conta">
<organization />
</author>

<date year="2001" month="January" />
</front>

<seriesInfo value="3032" name="RFC" />
<format octets="48314" type="TXT" target="ftp://ftp.isi.edu/in-notes/rfc3032.txt" />
</reference>


<reference target2="reference.RFC.3033.xml" anchor="RFC3033">
<front>
<title>The Assignment of the Information Field and Protocol Identifier in the Q.2941 Generic Identifier and Q.2957 User-to-user Signaling for the Internet Protocol</title>
<author fullname="M. Suzuki" initials="M." surname="Suzuki">
<organization />
</author>

<date year="2001" month="January" />
</front>

<seriesInfo value="3033" name="RFC" />
<format octets="52188" type="TXT" target="ftp://ftp.isi.edu/in-notes/rfc3033.txt" />
</reference>


<reference target2="reference.RFC.3034.xml" anchor="RFC3034">
<front>
<title>Use of Label Switching on Frame Relay Networks Specification</title>
<author fullname="A. Conta" initials="A." surname="Conta">
<organization />
</author>

<author fullname="P. Doolan" initials="P." surname="Doolan">
<organization />
</author>

<author fullname="A. Malis" initials="A." surname="Malis">
<organization />
</author>

<date year="2001" month="January" />
</front>

<seriesInfo value="3034" name="RFC" />
<format octets="53176" type="TXT" target="ftp://ftp.isi.edu/in-notes/rfc3034.txt" />
</reference>


<reference target2="reference.RFC.3035.xml" anchor="RFC3035">
<front>
<title>MPLS using LDP and ATM VC Switching</title>
<author fullname="B. Davie" initials="B." surname="Davie">
<organization />
</author>

<author fullname="J. Lawrence" initials="J." surname="Lawrence">
<organization />
</author>

<author fullname="K. McCloghrie" initials="K." surname="McCloghrie">
<organization />
</author>

<author fullname="E. Rosen" initials="E." surname="Rosen">
<organization />
</author>

<author fullname="G. Swallow" initials="G." surname="Swallow">
<organization />
</author>

<author fullname="Y. Rekhter" initials="Y." surname="Rekhter">
<organization />
</author>

<author fullname="P. Doolan" initials="P." surname="Doolan">
<organization />
</author>

<date year="2001" month="January" />
</front>

<seriesInfo value="3035" name="RFC" />
<format octets="46463" type="TXT" target="ftp://ftp.isi.edu/in-notes/rfc3035.txt" />
</reference>


<reference target2="reference.RFC.3036.xml" anchor="RFC3036">
<front>
<title>LDP Specification</title>
<author fullname="L. Andersson" initials="L." surname="Andersson">
<organization />
</author>

<author fullname="P. Doolan" initials="P." surname="Doolan">
<organization />
</author>

<author fullname="N. Feldman" initials="N." surname="Feldman">
<organization />
</author>

<author fullname="A. Fredette" initials="A." surname="Fredette">
<organization />
</author>

<author fullname="B. Thomas" initials="B." surname="Thomas">
<organization />
</author>

<date year="2001" month="January" />
</front>

<seriesInfo value="3036" name="RFC" />
<format octets="274855" type="TXT" target="ftp://ftp.isi.edu/in-notes/rfc3036.txt" />
</reference>


<reference target2="reference.RFC.3037.xml" anchor="RFC3037">
<front>
<title>LDP Applicability</title>
<author fullname="B. Thomas" initials="B." surname="Thomas">
<organization />
</author>

<author fullname="E. Gray" initials="E." surname="Gray">
<organization />
</author>

<date year="2001" month="January" />
</front>

<seriesInfo value="3037" name="RFC" />
<format octets="13601" type="TXT" target="ftp://ftp.isi.edu/in-notes/rfc3037.txt" />
</reference>


<reference target2="reference.RFC.3038.xml" anchor="RFC3038">
<front>
<title>VCID Notification over ATM link for LDP</title>
<author fullname="K. Nagami" initials="K." surname="Nagami">
<organization />
</author>

<author fullname="Y. Katsube" initials="Y." surname="Katsube">
<organization />
</author>

<author fullname="N. Demizu" initials="N." surname="Demizu">
<organization />
</author>

<author fullname="H. Esaki" initials="H." surname="Esaki">
<organization />
</author>

<author fullname="P. Doolan" initials="P." surname="Doolan">
<organization />
</author>

<date year="2001" month="January" />
</front>

<seriesInfo value="3038" name="RFC" />
<format octets="39134" type="TXT" target="ftp://ftp.isi.edu/in-notes/rfc3038.txt" />
</reference>


<reference target2="reference.RFC.3039.xml" anchor="RFC3039">
<front>
<title>Internet X.509 Public Key Infrastructure Qualified Certificates Profile</title>
<author fullname="S. Santesson" initials="S." surname="Santesson">
<organization />
</author>

<author fullname="W. Polk" initials="W." surname="Polk">
<organization />
</author>

<author fullname="P. Barzin" initials="P." surname="Barzin">
<organization />
</author>

<author fullname="M. Nystrom" initials="M." surname="Nystrom">
<organization />
</author>

<date year="2001" month="January" />
</front>

<seriesInfo value="3039" name="RFC" />
<format octets="67619" type="TXT" target="ftp://ftp.isi.edu/in-notes/rfc3039.txt" />
</reference>


<reference target2="reference.RFC.3040.xml" anchor="RFC3040">
<front>
<title>Internet Web Replication and Caching Taxonomy</title>
<author fullname="I. Cooper" initials="I." surname="Cooper">
<organization />
</author>

<author fullname="I. Melve" initials="I." surname="Melve">
<organization />
</author>

<author fullname="G. Tomlinson" initials="G." surname="Tomlinson">
<organization />
</author>

<date year="2001" month="January" />
</front>

<seriesInfo value="3040" name="RFC" />
<format octets="63257" type="TXT" target="ftp://ftp.isi.edu/in-notes/rfc3040.txt" />
</reference>


<reference target2="reference.RFC.3041.xml" anchor="RFC3041">
<front>
<title>Privacy Extensions for Stateless Address Autoconfiguration in IPv6</title>
<author fullname="T. Narten" initials="T." surname="Narten">
<organization />
</author>

<author fullname="R. Draves" initials="R." surname="Draves">
<organization />
</author>

<date year="2001" month="January" />
</front>

<seriesInfo value="3041" name="RFC" />
<format octets="44446" type="TXT" target="ftp://ftp.isi.edu/in-notes/rfc3041.txt" />
</reference>


<reference target2="reference.RFC.3042.xml" anchor="RFC3042">
<front>
<title>Enhancing TCP's Loss Recovery Using Limited Transmit</title>
<author fullname="M. Allman" initials="M." surname="Allman">
<organization />
</author>

<author fullname="H. Balakrishnan" initials="H." surname="Balakrishnan">
<organization />
</author>

<author fullname="S. Floyd" initials="S." surname="Floyd">
<organization />
</author>

<date year="2001" month="January" />
</front>

<seriesInfo value="3042" name="RFC" />
<format octets="19885" type="TXT" target="ftp://ftp.isi.edu/in-notes/rfc3042.txt" />
</reference>


<reference target2="reference.RFC.3043.xml" anchor="RFC3043">
<front>
<title>The Network Solutions Personal Internet Name (PIN): A URN Namespace for People and Organizations</title>
<author fullname="M. Mealling" initials="M." surname="Mealling">
<organization />
</author>

<date year="2001" month="January" />
</front>

<seriesInfo value="3043" name="RFC" />
<format octets="8136" type="TXT" target="ftp://ftp.isi.edu/in-notes/rfc3043.txt" />
</reference>


<reference target2="reference.RFC.3044.xml" anchor="RFC3044">
<front>
<title>Using The ISSN (International Serial Standard Number) as URN (Uniform Resource Names) within an ISSN-URN Namespace</title>
<author fullname="S. Rozenfeld" initials="S." surname="Rozenfeld">
<organization />
</author>

<date year="2001" month="January" />
</front>

<seriesInfo value="3044" name="RFC" />
<format octets="28094" type="TXT" target="ftp://ftp.isi.edu/in-notes/rfc3044.txt" />
</reference>


<reference target2="reference.RFC.3045.xml" anchor="RFC3045">
<front>
<title>Storing Vendor Information in the LDAP root DSE</title>
<author fullname="M. Meredith" initials="M." surname="Meredith">
<organization />
</author>

<date year="2001" month="January" />
</front>

<seriesInfo value="3045" name="RFC" />
<format octets="10518" type="TXT" target="ftp://ftp.isi.edu/in-notes/rfc3045.txt" />
</reference>


<reference target2="reference.RFC.3046.xml" anchor="RFC3046">
<front>
<title>DHCP Relay Agent Information Option</title>
<author fullname="M. Patrick" initials="M." surname="Patrick">
<organization />
</author>

<date year="2001" month="January" />
</front>

<seriesInfo value="3046" name="RFC" />
<format octets="30633" type="TXT" target="ftp://ftp.isi.edu/in-notes/rfc3046.txt" />
</reference>


<reference target2="reference.RFC.3047.xml" anchor="RFC3047">
<front>
<title>RTP Payload Format for ITU-T Recommendation G.722.1</title>
<author fullname="P. Luthi" initials="P." surname="Luthi">
<organization />
</author>

<date year="2001" month="January" />
</front>

<seriesInfo value="3047" name="RFC" />
<format octets="16292" type="TXT" target="ftp://ftp.isi.edu/in-notes/rfc3047.txt" />
</reference>


<reference target2="reference.RFC.3048.xml" anchor="RFC3048">
<front>
<title>Reliable Multicast Transport Building Blocks for One-to-Many Bulk-Data Transfer</title>
<author fullname="B. Whetten" initials="B." surname="Whetten">
<organization />
</author>

<author fullname="L. Vicisano" initials="L." surname="Vicisano">
<organization />
</author>

<author fullname="R. Kermode" initials="R." surname="Kermode">
<organization />
</author>

<author fullname="M. Handley" initials="M." surname="Handley">
<organization />
</author>

<author fullname="S. Floyd" initials="S." surname="Floyd">
<organization />
</author>

<author fullname="M. Luby" initials="M." surname="Luby">
<organization />
</author>

<date year="2001" month="January" />
</front>

<seriesInfo value="3048" name="RFC" />
<format octets="48965" type="TXT" target="ftp://ftp.isi.edu/in-notes/rfc3048.txt" />
</reference>


<reference target2="reference.RFC.3049.xml" anchor="RFC3049">
<front>
<title>TN3270E Service Location and Session Balancing</title>
<author fullname="J. Naugle" initials="J." surname="Naugle">
<organization />
</author>

<author fullname="K. Kasthurirangan" initials="K." surname="Kasthurirangan">
<organization />
</author>

<author fullname="G. Ledford" initials="G." surname="Ledford">
<organization />
</author>

<date year="2001" month="January" />
</front>

<seriesInfo value="3049" name="RFC" />
<format octets="40743" type="TXT" target="ftp://ftp.isi.edu/in-notes/rfc3049.txt" />
</reference>


<reference target2="reference.RFC.3050.xml" anchor="RFC3050">
<front>
<title>Common Gateway Interface for SIP</title>
<author fullname="J. Lennox" initials="J." surname="Lennox">
<organization />
</author>

<author fullname="H. Schulzrinne" initials="H." surname="Schulzrinne">
<organization />
</author>

<author fullname="J. Rosenberg" initials="J." surname="Rosenberg">
<organization />
</author>

<date year="2001" month="January" />
</front>

<seriesInfo value="3050" name="RFC" />
<format octets="76652" type="TXT" target="ftp://ftp.isi.edu/in-notes/rfc3050.txt" />
</reference>


<reference target2="reference.RFC.3051.xml" anchor="RFC3051">
<front>
<title>IP Payload Compression Using ITU-T V.44 Packet Method</title>
<author fullname="J. Heath" initials="J." surname="Heath">
<organization />
</author>

<author fullname="J. Border" initials="J." surname="Border">
<organization />
</author>

<date year="2001" month="January" />
</front>

<seriesInfo value="3051" name="RFC" />
<format octets="15845" type="TXT" target="ftp://ftp.isi.edu/in-notes/rfc3051.txt" />
</reference>


<reference target2="reference.RFC.3052.xml" anchor="RFC3052">
<front>
<title>Service Management Architectures Issues and Review</title>
<author fullname="M. Eder" initials="M." surname="Eder">
<organization />
</author>

<author fullname="S. Nag" initials="S." surname="Nag">
<organization />
</author>

<date year="2001" month="January" />
</front>

<seriesInfo value="3052" name="RFC" />
<format octets="31859" type="TXT" target="ftp://ftp.isi.edu/in-notes/rfc3052.txt" />
</reference>


<reference target2="reference.RFC.3053.xml" anchor="RFC3053">
<front>
<title>IPv6 Tunnel Broker</title>
<author fullname="A. Durand" initials="A." surname="Durand">
<organization />
</author>

<author fullname="P. Fasano" initials="P." surname="Fasano">
<organization />
</author>

<author fullname="I. Guardini" initials="I." surname="Guardini">
<organization />
</author>

<author fullname="D. Lento" initials="D." surname="Lento">
<organization />
</author>

<date year="2001" month="January" />
</front>

<seriesInfo value="3053" name="RFC" />
<format octets="27336" type="TXT" target="ftp://ftp.isi.edu/in-notes/rfc3053.txt" />
</reference>


<reference target2="reference.RFC.3054.xml" anchor="RFC3054">
<front>
<title>Megaco IP Phone Media Gateway Application Profile</title>
<author fullname="P. Blatherwick" initials="P." surname="Blatherwick">
<organization />
</author>

<author fullname="R. Bell" initials="R." surname="Bell">
<organization />
</author>

<author fullname="P. Holland" initials="P." surname="Holland">
<organization />
</author>

<date year="2001" month="January" />
</front>

<seriesInfo value="3054" name="RFC" />
<format octets="31971" type="TXT" target="ftp://ftp.isi.edu/in-notes/rfc3054.txt" />
</reference>


<reference target2="reference.RFC.3055.xml" anchor="RFC3055">
<front>
<title>Management Information Base for the PINT Services Architecture</title>
<author fullname="M. Krishnaswamy" initials="M." surname="Krishnaswamy">
<organization />
</author>

<author fullname="D. Romascanu" initials="D." surname="Romascanu">
<organization />
</author>

<date year="2001" month="February" />
</front>

<seriesInfo value="3055" name="RFC" />
<format octets="39315" type="TXT" target="ftp://ftp.isi.edu/in-notes/rfc3055.txt" />
</reference>


<reference target2="reference.RFC.3056.xml" anchor="RFC3056">
<front>
<title>Connection of IPv6 Domains via IPv4 Clouds</title>
<author fullname="B. Carpenter" initials="B." surname="Carpenter">
<organization />
</author>

<author fullname="K. Moore" initials="K." surname="Moore">
<organization />
</author>

<date year="2001" month="February" />
</front>

<seriesInfo value="3056" name="RFC" />
<format octets="54902" type="TXT" target="ftp://ftp.isi.edu/in-notes/rfc3056.txt" />
</reference>


<reference target2="reference.RFC.3057.xml" anchor="RFC3057">
<front>
<title>ISDN Q.921-User Adaptation Layer</title>
<author fullname="K. Morneault" initials="K." surname="Morneault">
<organization />
</author>

<author fullname="S. Rengasami" initials="S." surname="Rengasami">
<organization />
</author>

<author fullname="M. Kalla" initials="M." surname="Kalla">
<organization />
</author>

<author fullname="G. Sidebottom" initials="G." surname="Sidebottom">
<organization />
</author>

<date year="2001" month="February" />
</front>

<seriesInfo value="3057" name="RFC" />
<format octets="13601" type="TXT" target="ftp://ftp.isi.edu/in-notes/rfc3057.txt" />
</reference>


<reference target2="reference.RFC.3058.xml" anchor="RFC3058">
<front>
<title>Use of the IDEA Encryption Algorithm in CMS</title>
<author fullname="S. Teiwes" initials="S." surname="Teiwes">
<organization />
</author>

<author fullname="P. Hartmann" initials="P." surname="Hartmann">
<organization />
</author>

<author fullname="D. Kuenzi" initials="D." surname="Kuenzi">
<organization />
</author>

<date year="2001" month="February" />
</front>

<seriesInfo value="3058" name="RFC" />
<format octets="17257" type="TXT" target="ftp://ftp.isi.edu/in-notes/rfc3058.txt" />
</reference>


<reference target2="reference.RFC.3059.xml" anchor="RFC3059">
<front>
<title>Attribute List Extension for the Service Location Protocol</title>
<author fullname="E. Guttman" initials="E." surname="Guttman">
<organization />
</author>

<date year="2001" month="February" />
</front>

<seriesInfo value="3059" name="RFC" />
<format octets="11208" type="TXT" target="ftp://ftp.isi.edu/in-notes/rfc3059.txt" />
</reference>


<reference target2="reference.RFC.3060.xml" anchor="RFC3060">
<front>
<title>Policy Core Information Model -- Version 1 Specification</title>
<author fullname="B. Moore" initials="B." surname="Moore">
<organization />
</author>

<author fullname="E. Ellesson" initials="E." surname="Ellesson">
<organization />
</author>

<author fullname="J. Strassner" initials="J." surname="Strassner">
<organization />
</author>

<author fullname="A. Westerinen" initials="A." surname="Westerinen">
<organization />
</author>

<date year="2001" month="February" />
</front>

<seriesInfo value="3060" name="RFC" />
<format octets="240309" type="TXT" target="ftp://ftp.isi.edu/in-notes/rfc3060.txt" />
</reference>


<reference target2="reference.RFC.3061.xml" anchor="RFC3061">
<front>
<title>A URN Namespace of Object Identifiers</title>
<author fullname="M. Mealling" initials="M." surname="Mealling">
<organization />
</author>

<date year="2001" month="February" />
</front>

<seriesInfo value="3061" name="RFC" />
<format octets="8387" type="TXT" target="ftp://ftp.isi.edu/in-notes/rfc3061.txt" />
</reference>


<reference target2="reference.RFC.3062.xml" anchor="RFC3062">
<front>
<title>LDAP Password Modify Extended Operation</title>
<author fullname="K. Zeilenga" initials="K." surname="Zeilenga">
<organization />
</author>

<date year="2001" month="February" />
</front>

<seriesInfo value="3062" name="RFC" />
<format octets="11807" type="TXT" target="ftp://ftp.isi.edu/in-notes/rfc3062.txt" />
</reference>


<reference target2="reference.RFC.3063.xml" anchor="RFC3063">
<front>
<title>MPLS Loop Prevention Mechanism</title>
<author fullname="Y. Ohba" initials="Y." surname="Ohba">
<organization />
</author>

<author fullname="Y. Katsube" initials="Y." surname="Katsube">
<organization />
</author>

<author fullname="E. Rosen" initials="E." surname="Rosen">
<organization />
</author>

<author fullname="P. Doolan" initials="P." surname="Doolan">
<organization />
</author>

<date year="2001" month="February" />
</front>

<seriesInfo value="3063" name="RFC" />
<format octets="93523" type="TXT" target="ftp://ftp.isi.edu/in-notes/rfc3063.txt" />
</reference>


<reference target2="reference.RFC.3064.xml" anchor="RFC3064">
<front>
<title>MGCP CAS Packages</title>
<author fullname="B. Foster" initials="B." surname="Foster">
<organization />
</author>

<date year="2001" month="February" />
</front>

<seriesInfo value="3064" name="RFC" />
<format octets="116818" type="TXT" target="ftp://ftp.isi.edu/in-notes/rfc3064.txt" />
</reference>


<reference target2="reference.RFC.3065.xml" anchor="RFC3065">
<front>
<title>Autonomous System Confederations for BGP</title>
<author fullname="P. Traina" initials="P." surname="Traina">
<organization />
</author>

<author fullname="D. McPherson" initials="D." surname="McPherson">
<organization />
</author>

<author fullname="J. Scudder" initials="J." surname="Scudder">
<organization />
</author>

<date year="2001" month="February" />
</front>

<seriesInfo value="3065" name="RFC" />
<format octets="20529" type="TXT" target="ftp://ftp.isi.edu/in-notes/rfc3065.txt" />
</reference>


<reference target2="reference.RFC.3066.xml" anchor="RFC3066">
<front>
<title>Tags for the Identification of Languages</title>
<author fullname="H. Alvestrand" initials="H." surname="Alvestrand">
<organization />
</author>

<date year="2001" month="January" />
</front>

<seriesInfo value="47" name="BCP" />
<seriesInfo value="3066" name="RFC" />
<format octets="26522" type="TXT" target="ftp://ftp.isi.edu/in-notes/rfc3066.txt" />
</reference>


<reference target2="reference.RFC.3067.xml" anchor="RFC3067">
<front>
<title>TERENA'S Incident Object Description and Exchange Format Requirements</title>
<author fullname="J. Arvidsson" initials="J." surname="Arvidsson">
<organization />
</author>

<author fullname="A. Cormack" initials="A." surname="Cormack">
<organization />
</author>

<author fullname="Y. Demchenko" initials="Y." surname="Demchenko">
<organization />
</author>

<author fullname="J. Meijer" initials="J." surname="Meijer">
<organization />
</author>

<date year="2001" month="February" />
</front>

<seriesInfo value="3067" name="RFC" />
<format octets="36836" type="TXT" target="ftp://ftp.isi.edu/in-notes/rfc3067.txt" />
</reference>


<reference target2="reference.RFC.3068.xml" anchor="RFC3068">
<front>
<title>An Anycast Prefix for 6to4 Relay Routers</title>
<author fullname="C. Huitema" initials="C." surname="Huitema">
<organization />
</author>

<date year="2001" month="June" />
</front>

<seriesInfo value="3068" name="RFC" />
<format octets="20120" type="TXT" target="ftp://ftp.isi.edu/in-notes/rfc3068.txt" />
</reference>


<reference target2="reference.RFC.3069.xml" anchor="RFC3069">
<front>
<title>VLAN Aggregation for Efficient IP Address Allocation</title>
<author fullname="D. McPherson" initials="D." surname="McPherson">
<organization />
</author>

<author fullname="B. Dykes" initials="B." surname="Dykes">
<organization />
</author>

<date year="2001" month="February" />
</front>

<seriesInfo value="3069" name="RFC" />
<format octets="14891" type="TXT" target="ftp://ftp.isi.edu/in-notes/rfc3069.txt" />
</reference>


<reference target2="reference.RFC.3070.xml" anchor="RFC3070">
<front>
<title>Layer Two Tunneling Protocol (L2TP) over Frame Relay</title>
<author fullname="V. Rawat" initials="V." surname="Rawat">
<organization />
</author>

<author fullname="R. Tio" initials="R." surname="Tio">
<organization />
</author>

<author fullname="S. Nanji" initials="S." surname="Nanji">
<organization />
</author>

<author fullname="R. Verma" initials="R." surname="Verma">
<organization />
</author>

<date year="2001" month="February" />
</front>

<seriesInfo value="3070" name="RFC" />
<format octets="12940" type="TXT" target="ftp://ftp.isi.edu/in-notes/rfc3070.txt" />
</reference>


<reference target2="reference.RFC.3071.xml" anchor="RFC3071">
<front>
<title>Reflections on the DNS, RFC 1591, and Categories of Domains</title>
<author fullname="J. Klensin" initials="J." surname="Klensin">
<organization />
</author>

<date year="2001" month="February" />
</front>

<seriesInfo value="3071" name="RFC" />
<format octets="24892" type="TXT" target="ftp://ftp.isi.edu/in-notes/rfc3071.txt" />
</reference>


<reference target2="reference.RFC.3072.xml" anchor="RFC3072">
<front>
<title>Structured Data Exchange Format (SDXF)</title>
<author fullname="M. Wildgrube" initials="M." surname="Wildgrube">
<organization />
</author>

<date year="2001" month="March" />
</front>

<seriesInfo value="3072" name="RFC" />
<format octets="48481" type="TXT" target="ftp://ftp.isi.edu/in-notes/rfc3072.txt" />
</reference>


<reference target2="reference.RFC.3073.xml" anchor="RFC3073">
<front>
<title>Portable Font Resource (PFR) - application/font-tdpfr MIME Sub-type Registration</title>
<author fullname="J. Collins" initials="J." surname="Collins">
<organization />
</author>

<date year="2001" month="March" />
</front>

<seriesInfo value="3073" name="RFC" />
<format octets="9076" type="TXT" target="ftp://ftp.isi.edu/in-notes/rfc3073.txt" />
</reference>


<reference target2="reference.RFC.3074.xml" anchor="RFC3074">
<front>
<title>DHC Load Balancing Algorithm</title>
<author fullname="B. Volz" initials="B." surname="Volz">
<organization />
</author>

<author fullname="S. Gonczi" initials="S." surname="Gonczi">
<organization />
</author>

<author fullname="T. Lemon" initials="T." surname="Lemon">
<organization />
</author>

<author fullname="R. Stevens" initials="R." surname="Stevens">
<organization />
</author>

<date year="2001" month="February" />
</front>

<seriesInfo value="3074" name="RFC" />
<format octets="19374" type="TXT" target="ftp://ftp.isi.edu/in-notes/rfc3074.txt" />
</reference>


<reference target2="reference.RFC.3075.xml" anchor="RFC3075">
<front>
<title>XML-Signature Syntax and Processing</title>
<author fullname="D. Eastlake" initials="D." surname="Eastlake">
<organization />
</author>

<author fullname="J. Reagle" initials="J." surname="Reagle">
<organization />
</author>

<author fullname="D. Solo" initials="D." surname="Solo">
<organization />
</author>

<date year="2001" month="March" />
</front>

<seriesInfo value="3075" name="RFC" />
<format octets="145520" type="TXT" target="ftp://ftp.isi.edu/in-notes/rfc3075.txt" />
</reference>


<reference target2="reference.RFC.3076.xml" anchor="RFC3076">
<front>
<title>Canonical XML Version 1.0</title>
<author fullname="J. Boyer" initials="J." surname="Boyer">
<organization />
</author>

<date year="2001" month="March" />
</front>

<seriesInfo value="3076" name="RFC" />
<format octets="63955" type="TXT" target="ftp://ftp.isi.edu/in-notes/rfc3076.txt" />
</reference>


<reference target2="reference.RFC.3077.xml" anchor="RFC3077">
<front>
<title>A Link-Layer Tunneling Mechanism for Unidirectional Links</title>
<author fullname="E. Duros" initials="E." surname="Duros">
<organization />
</author>

<author fullname="W. Dabbous" initials="W." surname="Dabbous">
<organization />
</author>

<author fullname="H. Izumiyama" initials="H." surname="Izumiyama">
<organization />
</author>

<author fullname="N. Fujii" initials="N." surname="Fujii">
<organization />
</author>

<author fullname="Y. Zhang" initials="Y." surname="Zhang">
<organization />
</author>

<date year="2001" month="March" />
</front>

<seriesInfo value="3077" name="RFC" />
<format octets="52410" type="TXT" target="ftp://ftp.isi.edu/in-notes/rfc3077.txt" />
</reference>


<reference target2="reference.RFC.3078.xml" anchor="RFC3078">
<front>
<title>Microsoft Point-To-Point Encryption (MPPE) Protocol</title>
<author fullname="G. Pall" initials="G." surname="Pall">
<organization />
</author>

<author fullname="G. Zorn" initials="G." surname="Zorn">
<organization />
</author>

<date year="2001" month="March" />
</front>

<seriesInfo value="3078" name="RFC" />
<format octets="22952" type="TXT" target="ftp://ftp.isi.edu/in-notes/rfc3078.txt" />
</reference>


<reference target2="reference.RFC.3079.xml" anchor="RFC3079">
<front>
<title>Deriving Keys for use with Microsoft Point-to-Point Encryption (MPPE)</title>
<author fullname="G. Zorn" initials="G." surname="Zorn">
<organization />
</author>

<date year="2001" month="March" />
</front>

<seriesInfo value="3079" name="RFC" />
<format octets="38905" type="TXT" target="ftp://ftp.isi.edu/in-notes/rfc3079.txt" />
</reference>


<reference target2="reference.RFC.3080.xml" anchor="RFC3080">
<front>
<title abbrev="The BEEP Core">The Blocks Extensible Exchange Protocol Core</title>
<author fullname="Marshall T. Rose" initials="M.T." surname="Rose">
<organization>Invisible Worlds, Inc.</organization>

<address>
<postal>
<street>131 Stony Circle</street>
<street>Suite 500</street>
<city>Santa Rosa</city>
<region>CA</region>
<code>95401</code>
<country>US</country>
</postal>

<phone>+1 707 578 2350</phone>
<email>mrose@invisible.net</email>
<uri>http://invisible.net/</uri>
</address>
</author>

<date year="2001" month="March" />
<area>Applications</area>
<keyword>application protocols</keyword>
<keyword>BEEP</keyword>
<keyword>BXXP</keyword>
<keyword>application framework</keyword>

<abstract>
<t>This memo describes a generic application protocol
kernel for connection-oriented,
asynchronous interactions called the BEEP
(Blocks Extensible Exchange Protocol)
core.
BEEP permits simultaneous and independent exchanges
within the context of a single application user-identity,
supporting both textual and binary messages.</t>
</abstract>
</front>

<seriesInfo value="3080" name="RFC" />
<format octets="92254" type="HTML" target="http://xml.resource.org/public/rfc/html/rfc3080.html" />
<format octets="88769" type="XML" target="http://xml.resource.org/public/rfc/xml/rfc3080.xml" />
</reference>


<reference target2="reference.RFC.3081.xml" anchor="RFC3081">
<front>
<title>Mapping the BEEP Core onto TCP</title>
<author fullname="Marshall T. Rose" initials="M.T." surname="Rose">
<organization>Invisible Worlds, Inc.</organization>

<address>
<postal>
<street>131 Stony Circle</street>
<street>Suite 500</street>
<city>Santa Rosa</city>
<region>CA</region>
<code>95401</code>
<country>US</country>
</postal>

<phone>+1 707 578 2350</phone>
<email>mrose@invisible.net</email>
<uri>http://invisible.net/</uri>
</address>
</author>

<date year="2001" month="March" />
<area>Applications</area>
<keyword>application protocols</keyword>
<keyword>BEEP</keyword>
<keyword>BXXP</keyword>
<keyword>transport mapping</keyword>

<abstract>
<t>This memo describes how a BEEP
(Blocks Extensible Exchange Protocol)
session is mapped onto a single TCP
(Transmission Control Protocol)
connection.</t>
</abstract>
</front>

<seriesInfo value="3081" name="RFC" />
<format octets="24447" type="HTML" target="http://xml.resource.org/public/rfc/html/rfc3081.html" />
<format octets="15057" type="XML" target="http://xml.resource.org/public/rfc/xml/rfc3081.xml" />
</reference>


<reference target2="reference.RFC.3082.xml" anchor="RFC3082">
<front>
<title>Notification and Subscription for SLP</title>
<author fullname="J. Kempf" initials="J." surname="Kempf">
<organization />
</author>

<author fullname="J. Goldschmidt" initials="J." surname="Goldschmidt">
<organization />
</author>

<date year="2001" month="March" />
</front>

<seriesInfo value="3082" name="RFC" />
<format octets="33410" type="TXT" target="ftp://ftp.isi.edu/in-notes/rfc3082.txt" />
</reference>


<reference target2="reference.RFC.3083.xml" anchor="RFC3083">
<front>
<title>Baseline Privacy Interface Management Information Base for DOCSIS Compliant Cable Modems and Cable Modem Termination Systems</title>
<author fullname="R. Woundy" initials="R." surname="Woundy">
<organization />
</author>

<date year="2001" month="March" />
</front>

<seriesInfo value="3083" name="RFC" />
<format octets="88318" type="TXT" target="ftp://ftp.isi.edu/in-notes/rfc3083.txt" />
</reference>


<reference target2="reference.RFC.3084.xml" anchor="RFC3084">
<front>
<title>COPS Usage for Policy Provisioning (COPS-PR)</title>
<author fullname="K. Chan" initials="K." surname="Chan">
<organization />
</author>

<author fullname="J. Seligson" initials="J." surname="Seligson">
<organization />
</author>

<author fullname="D. Durham" initials="D." surname="Durham">
<organization />
</author>

<author fullname="S. Gai" initials="S." surname="Gai">
<organization />
</author>

<author fullname="K. McCloghrie" initials="K." surname="McCloghrie">
<organization />
</author>

<author fullname="S. Herzog" initials="S." surname="Herzog">
<organization />
</author>

<author fullname="F. Reichmeyer" initials="F." surname="Reichmeyer">
<organization />
</author>

<author fullname="R. Yavatkar" initials="R." surname="Yavatkar">
<organization />
</author>

<author fullname="A. Smith" initials="A." surname="Smith">
<organization />
</author>

<date year="2001" month="March" />
</front>

<seriesInfo value="3084" name="RFC" />
<format octets="79341" type="TXT" target="ftp://ftp.isi.edu/in-notes/rfc3084.txt" />
</reference>


<reference target2="reference.RFC.3085.xml" anchor="RFC3085">
<front>
<title>URN Namespace for NewsML Resources</title>
<author fullname="A. Coates" initials="A." surname="Coates">
<organization />
</author>

<author fullname="D. Allen" initials="D." surname="Allen">
<organization />
</author>

<author fullname="D. Rivers-Moore" initials="D." surname="Rivers-Moore">
<organization />
</author>

<date year="2001" month="March" />
</front>

<seriesInfo value="3085" name="RFC" />
<format octets="10016" type="TXT" target="ftp://ftp.isi.edu/in-notes/rfc3085.txt" />
</reference>


<reference target2="reference.RFC.3086.xml" anchor="RFC3086">
<front>
<title>Definition of Differentiated Services Per Domain Behaviors and Rules for their Specification</title>
<author fullname="K. Nichols" initials="K." surname="Nichols">
<organization />
</author>

<author fullname="B. Carpenter" initials="B." surname="Carpenter">
<organization />
</author>

<date year="2001" month="April" />
</front>

<seriesInfo value="3086" name="RFC" />
<format octets="63122" type="TXT" target="ftp://ftp.isi.edu/in-notes/rfc3086.txt" />
</reference>


<reference target2="reference.RFC.3087.xml" anchor="RFC3087">
<front>
<title>Control of Service Context using SIP Request-URI</title>
<author fullname="B. Campbell" initials="B." surname="Campbell">
<organization />
</author>

<author fullname="R. Sparks" initials="R." surname="Sparks">
<organization />
</author>

<date year="2001" month="April" />
</front>

<seriesInfo value="3087" name="RFC" />
<format octets="83612" type="TXT" target="ftp://ftp.isi.edu/in-notes/rfc3087.txt" />
</reference>


<reference target2="reference.RFC.3088.xml" anchor="RFC3088">
<front>
<title>OpenLDAP Root Service An experimental LDAP referral service</title>
<author fullname="K. Zeilenga" initials="K." surname="Zeilenga">
<organization />
</author>

<date year="2001" month="April" />
</front>

<seriesInfo value="3088" name="RFC" />
<format octets="19471" type="TXT" target="ftp://ftp.isi.edu/in-notes/rfc3088.txt" />
</reference>


<reference target2="reference.RFC.3089.xml" anchor="RFC3089">
<front>
<title>A SOCKS-based IPv6/IPv4 Gateway Mechanism</title>
<author fullname="H. Kitamura" initials="H." surname="Kitamura">
<organization />
</author>

<date year="2001" month="April" />
</front>

<seriesInfo value="3089" name="RFC" />
<format octets="25193" type="TXT" target="ftp://ftp.isi.edu/in-notes/rfc3089.txt" />
</reference>


<reference target2="reference.RFC.3090.xml" anchor="RFC3090">
<front>
<title>DNS Security Extension Clarification on Zone Status</title>
<author fullname="E. Lewis" initials="E." surname="Lewis">
<organization />
</author>

<date year="2001" month="March" />
</front>

<seriesInfo value="3090" name="RFC" />
<format octets="24166" type="TXT" target="ftp://ftp.isi.edu/in-notes/rfc3090.txt" />
</reference>


<reference target2="reference.RFC.3091.xml" anchor="RFC3091">
<front>
<title>Pi Digit Generation Protocol</title>
<author fullname="H. Kennedy" initials="H." surname="Kennedy">
<organization />
</author>

<date year="2001" day="1" month="April" />
</front>

<seriesInfo value="3091" name="RFC" />
<format octets="10375" type="TXT" target="ftp://ftp.isi.edu/in-notes/rfc3091.txt" />
</reference>


<reference target2="reference.RFC.3092.xml" anchor="RFC3092">
<front>
<title>Etymology of "Foo"</title>
<author fullname="D. Eastlake" initials="D." surname="Eastlake">
<organization />
</author>

<author fullname="C. Manros" initials="C." surname="Manros">
<organization />
</author>

<author fullname="E. Raymond" initials="E." surname="Raymond">
<organization />
</author>

<date year="2001" day="1" month="April" />
</front>

<seriesInfo value="3092" name="RFC" />
<format octets="29235" type="TXT" target="ftp://ftp.isi.edu/in-notes/rfc3092.txt" />
</reference>


<reference target2="reference.RFC.3093.xml" anchor="RFC3093">
<front>
<title>Firewall Enhancement Protocol (FEP)</title>
<author fullname="M. Gaynor" initials="M." surname="Gaynor">
<organization />
</author>

<author fullname="S. Bradner" initials="S." surname="Bradner">
<organization />
</author>

<date year="2001" day="1" month="April" />
</front>

<seriesInfo value="3093" name="RFC" />
<format octets="22405" type="TXT" target="ftp://ftp.isi.edu/in-notes/rfc3093.txt" />
</reference>


<reference target2="reference.RFC.3094.xml" anchor="RFC3094">
<front>
<title>Tekelec's Transport Adapter Layer Interface</title>
<author fullname="D. Sprague" initials="D." surname="Sprague">
<organization />
</author>

<author fullname="R. Benedyk" initials="R." surname="Benedyk">
<organization />
</author>

<author fullname="D. Brendes" initials="D." surname="Brendes">
<organization />
</author>

<author fullname="J. Keller" initials="J." surname="Keller">
<organization />
</author>

<date year="2001" month="April" />
</front>

<seriesInfo value="3094" name="RFC" />
<format octets="265099" type="TXT" target="ftp://ftp.isi.edu/in-notes/rfc3094.txt" />
</reference>


<reference target2="reference.RFC.3095.xml" anchor="RFC3095">
<front>
<title>RObust Header Compression (ROHC): Framework and four profiles: RTP, UDP, ESP, and uncompressed</title>
<author fullname="C. Bormann" initials="C." surname="Bormann">
<organization />
</author>

<author fullname="C. Burmeister" initials="C." surname="Burmeister">
<organization />
</author>

<author fullname="M. Degermark" initials="M." surname="Degermark">
<organization />
</author>

<author fullname="H. Fukushima" initials="H." surname="Fukushima">
<organization />
</author>

<author fullname="H. Hannu" initials="H." surname="Hannu">
<organization />
</author>

<author fullname="L-E. Jonsson" initials="L-E." surname="Jonsson">
<organization />
</author>

<author fullname="R. Hakenberg" initials="R." surname="Hakenberg">
<organization />
</author>

<author fullname="T. Koren" initials="T." surname="Koren">
<organization />
</author>

<author fullname="K. Le" initials="K." surname="Le">
<organization />
</author>

<author fullname="Z. Liu" initials="Z." surname="Liu">
<organization />
</author>

<author fullname="A. Martensson" initials="A." surname="Martensson">
<organization />
</author>

<author fullname="A. Miyazaki" initials="A." surname="Miyazaki">
<organization />
</author>

<author fullname="K. Svanbro" initials="K." surname="Svanbro">
<organization />
</author>

<author fullname="T. Wiebke" initials="T." surname="Wiebke">
<organization />
</author>

<author fullname="T. Yoshimura" initials="T." surname="Yoshimura">
<organization />
</author>

<author fullname="H. Zheng" initials="H." surname="Zheng">
<organization />
</author>

<date year="2001" month="July" />
</front>

<seriesInfo value="3095" name="RFC" />
<format octets="368746" type="TXT" target="ftp://ftp.isi.edu/in-notes/rfc3095.txt" />
</reference>


<reference target2="reference.RFC.3096.xml" anchor="RFC3096">
<front>
<title>Requirements for robust IP/UDP/RTP header compression</title>
<author fullname="M. Degermark" initials="M." surname="Degermark">
<organization />
</author>

<date year="2001" month="July" />
</front>

<seriesInfo value="3096" name="RFC" />
<format octets="15018" type="TXT" target="ftp://ftp.isi.edu/in-notes/rfc3096.txt" />
</reference>


<reference target2="reference.RFC.3097.xml" anchor="RFC3097">
<front>
<title>RSVP Cryptographic Authentication -- Updated Message Type Value</title>
<author fullname="R. Braden" initials="R." surname="Braden">
<organization />
</author>

<author fullname="L. Zhang" initials="L." surname="Zhang">
<organization />
</author>

<date year="2001" month="April" />
</front>

<seriesInfo value="3097" name="RFC" />
<format octets="6320" type="TXT" target="ftp://ftp.isi.edu/in-notes/rfc3097.txt" />
</reference>


<reference target2="reference.RFC.3098.xml" anchor="RFC3098">
<front>
<title>How to Advertise Responsibly Using E-Mail and Newsgroups or - how NOT to $$$$$ MAKE ENEMIES FAST! $$$$$</title>
<author fullname="T. Gavin" initials="T." surname="Gavin">
<organization />
</author>

<author fullname="D. Eastlake" initials="D." surname="Eastlake">
<organization />
</author>

<author fullname="S. Hambridge" initials="S." surname="Hambridge">
<organization />
</author>

<date year="2001" month="April" />
</front>

<seriesInfo value="3098" name="RFC" />
<format octets="64687" type="TXT" target="ftp://ftp.isi.edu/in-notes/rfc3098.txt" />
</reference>


<reference target2="reference.RFC.3099.xml" anchor="RFC3099">
<front>
<title>Request for Comments Summary RFC Numbers 3000-3099</title>
<author fullname="S. Ginoza" initials="S." surname="Ginoza">
<organization />
</author>

<date year="2001" month="November" />
</front>

<seriesInfo value="3099" name="RFC" />
<format octets="48990" type="TXT" target="ftp://ftp.isi.edu/in-notes/rfc3099.txt" />
</reference>


<reference target2="reference.RFC.3101.xml" anchor="RFC3101">
<front>
<title>The OSPF Not-So-Stubby Area (NSSA) Option</title>
<author fullname="P. Murphy" initials="P." surname="Murphy">
<organization />
</author>

<date year="2003" month="January" />
</front>

<seriesInfo value="3101" name="RFC" />
<format octets="76243" type="TXT" target="ftp://ftp.isi.edu/in-notes/rfc3101.txt" />
</reference>


<reference target2="reference.RFC.3102.xml" anchor="RFC3102">
<front>
<title>Realm Specific IP: Framework</title>
<author fullname="M. Borella" initials="M." surname="Borella">
<organization />
</author>

<author fullname="J. Lo" initials="J." surname="Lo">
<organization />
</author>

<author fullname="D. Grabelsky" initials="D." surname="Grabelsky">
<organization />
</author>

<author fullname="G. Montenegro" initials="G." surname="Montenegro">
<organization />
</author>

<date year="2001" month="October" />
</front>

<seriesInfo value="3102" name="RFC" />
<format octets="73856" type="TXT" target="ftp://ftp.isi.edu/in-notes/rfc3102.txt" />
</reference>


<reference target2="reference.RFC.3103.xml" anchor="RFC3103">
<front>
<title>Realm Specific IP: Protocol Specification</title>
<author fullname="M. Borella" initials="M." surname="Borella">
<organization />
</author>

<author fullname="D. Grabelsky" initials="D." surname="Grabelsky">
<organization />
</author>

<author fullname="J. Lo" initials="J." surname="Lo">
<organization />
</author>

<author fullname="K. Taniguchi" initials="K." surname="Taniguchi">
<organization />
</author>

<date year="2001" month="October" />
</front>

<seriesInfo value="3103" name="RFC" />
<format octets="115855" type="TXT" target="ftp://ftp.isi.edu/in-notes/rfc3103.txt" />
</reference>


<reference target2="reference.RFC.3104.xml" anchor="RFC3104">
<front>
<title>RSIP Support for End-to-end IPsec</title>
<author fullname="G. Montenegro" initials="G." surname="Montenegro">
<organization />
</author>

<author fullname="M. Borella" initials="M." surname="Borella">
<organization />
</author>

<date year="2001" month="October" />
</front>

<seriesInfo value="3104" name="RFC" />
<format octets="38719" type="TXT" target="ftp://ftp.isi.edu/in-notes/rfc3104.txt" />
</reference>


<reference target2="reference.RFC.3105.xml" anchor="RFC3105">
<front>
<title>Finding an RSIP Server with SLP</title>
<author fullname="J. Kempf" initials="J." surname="Kempf">
<organization />
</author>

<author fullname="G. Montenegro" initials="G." surname="Montenegro">
<organization />
</author>

<date year="2001" month="October" />
</front>

<seriesInfo value="3105" name="RFC" />
<format octets="21427" type="TXT" target="ftp://ftp.isi.edu/in-notes/rfc3105.txt" />
</reference>


<reference target2="reference.RFC.3106.xml" anchor="RFC3106">
<front>
<title>ECML v1.1: Field Specifications for E-Commerce</title>
<author fullname="D. Eastlake" initials="D." surname="Eastlake">
<organization />
</author>

<author fullname="T. Goldstein" initials="T." surname="Goldstein">
<organization />
</author>

<date year="2001" month="April" />
</front>

<seriesInfo value="3106" name="RFC" />
<format octets="40715" type="TXT" target="ftp://ftp.isi.edu/in-notes/rfc3106.txt" />
</reference>


<reference target2="reference.RFC.3107.xml" anchor="RFC3107">
<front>
<title>Carrying Label Information in BGP-4</title>
<author fullname="Y. Rekhter" initials="Y." surname="Rekhter">
<organization />
</author>

<author fullname="E. Rosen" initials="E." surname="Rosen">
<organization />
</author>

<date year="2001" month="May" />
</front>

<seriesInfo value="3107" name="RFC" />
<format octets="16442" type="TXT" target="ftp://ftp.isi.edu/in-notes/rfc3107.txt" />
</reference>


<reference target2="reference.RFC.3108.xml" anchor="RFC3108">
<front>
<title>Conventions for the use of the Session Description Protocol (SDP) for ATM Bearer Connections</title>
<author fullname="R. Kumar" initials="R." surname="Kumar">
<organization />
</author>

<author fullname="M. Mostafa" initials="M." surname="Mostafa">
<organization />
</author>

<date year="2001" month="May" />
</front>

<seriesInfo value="3108" name="RFC" />
<format octets="248037" type="TXT" target="ftp://ftp.isi.edu/in-notes/rfc3108.txt" />
</reference>


<reference target2="reference.RFC.3109.xml" anchor="RFC3109">
<front>
<title>Request to Move STD 39 to Historic Status</title>
<author fullname="R. Braden" initials="R." surname="Braden">
<organization />
</author>

<author fullname="R. Bush" initials="R." surname="Bush">
<organization />
</author>

<author fullname="J. Klensin" initials="J." surname="Klensin">
<organization />
</author>

<date year="2001" month="May" />
</front>

<seriesInfo value="3109" name="RFC" />
<format octets="5841" type="TXT" target="ftp://ftp.isi.edu/in-notes/rfc3109.txt" />
</reference>


<reference target2="reference.RFC.3110.xml" anchor="RFC3110">
<front>
<title>RSA/SHA-1 SIGs and RSA KEYs in the Domain Name System (DNS)</title>
<author fullname="D. Eastlake" initials="D." surname="Eastlake">
<organization />
</author>

<date year="2001" month="May" />
</front>

<seriesInfo value="3110" name="RFC" />
<format octets="14587" type="TXT" target="ftp://ftp.isi.edu/in-notes/rfc3110.txt" />
</reference>


<reference target2="reference.RFC.3111.xml" anchor="RFC3111">
<front>
<title>Service Location Protocol Modifications for IPv6</title>
<author fullname="E. Guttman" initials="E." surname="Guttman">
<organization />
</author>

<date year="2001" month="May" />
</front>

<seriesInfo value="3111" name="RFC" />
<format octets="25543" type="TXT" target="ftp://ftp.isi.edu/in-notes/rfc3111.txt" />
</reference>


<reference target2="reference.RFC.3112.xml" anchor="RFC3112">
<front>
<title>LDAP Authentication Password Schema</title>
<author fullname="K. Zeilenga" initials="K." surname="Zeilenga">
<organization />
</author>

<date year="2001" month="May" />
</front>

<seriesInfo value="3112" name="RFC" />
<format octets="17116" type="TXT" target="ftp://ftp.isi.edu/in-notes/rfc3112.txt" />
</reference>


<reference target2="reference.RFC.3113.xml" anchor="RFC3113">
<front>
<title>3GPP-IETF Standardization Collaboration</title>
<author fullname="K. Rosenbrock" initials="K." surname="Rosenbrock">
<organization />
</author>

<author fullname="R. Sanmugam" initials="R." surname="Sanmugam">
<organization />
</author>

<author fullname="S. Bradner" initials="S." surname="Bradner">
<organization />
</author>

<author fullname="J. Klensin" initials="J." surname="Klensin">
<organization />
</author>

<date year="2001" month="June" />
</front>

<seriesInfo value="3113" name="RFC" />
<format octets="11405" type="TXT" target="ftp://ftp.isi.edu/in-notes/rfc3113.txt" />
</reference>


<reference target2="reference.RFC.3114.xml" anchor="RFC3114">
<front>
<title>Implementing Company Classification Policy with the S/MIME Security Label</title>
<author fullname="W. Nicolls" initials="W." surname="Nicolls">
<organization />
</author>

<date year="2002" month="May" />
</front>

<seriesInfo value="3114" name="RFC" />
<format octets="27764" type="TXT" target="ftp://ftp.isi.edu/in-notes/rfc3114.txt" />
</reference>


<reference target2="reference.RFC.3115.xml" anchor="RFC3115">
<front>
<title>Mobile IP Vendor/Organization-Specific Extensions</title>
<author fullname="G. Dommety" initials="G." surname="Dommety">
<organization />
</author>

<author fullname="K. Leung" initials="K." surname="Leung">
<organization />
</author>

<date year="2001" month="April" />
</front>

<seriesInfo value="3115" name="RFC" />
<format octets="16363" type="TXT" target="ftp://ftp.isi.edu/in-notes/rfc3115.txt" />
</reference>


<reference target2="reference.RFC.3116.xml" anchor="RFC3116">
<front>
<title>Methodology for ATM Benchmarking</title>
<author fullname="J. Dunn" initials="J." surname="Dunn">
<organization />
</author>

<author fullname="C. Martin" initials="C." surname="Martin">
<organization />
</author>

<date year="2001" month="June" />
</front>

<seriesInfo value="3116" name="RFC" />
<format octets="295052" type="TXT" target="ftp://ftp.isi.edu/in-notes/rfc3116.txt" />
</reference>


<reference target2="reference.RFC.3117.xml" anchor="RFC3117">
<front>
<title>On the Design of Application Protocols</title>
<author fullname="Marshall T. Rose" initials="M.T." surname="Rose">
<organization>Dover Beach Consulting, Inc.</organization>

<address>
<postal>
<street>POB 255268</street>
<city>Sacramento</city>
<region>CA</region>
<code>95865-5268</code>
<country>US</country>
</postal>

<phone>+1 916 483 8878</phone>
<email>mrose@dbc.mtview.ca.us</email>
</address>
</author>

<date year="2001" month="November" />
<area>Applications</area>
<keyword>application protocols</keyword>
<keyword>BEEP</keyword>
<keyword>BXXP</keyword>
<keyword>XML</keyword>

<abstract>
<t>This memo describes the design principles for the Blocks
eXtensible eXchange Protocol (BXXP).
BXXP is a generic application protocol
framework for connection-oriented,
asynchronous interactions.
The framework permits simultaneous and independent exchanges
within the context of a single application user-identity,
supporting both textual and binary messages.</t>
</abstract>
</front>

<seriesInfo value="3117" name="RFC" />
<format octets="75191" type="HTML" target="http://xml.resource.org/public/rfc/html/rfc3117.html" />
<format octets="100282" type="XML" target="http://xml.resource.org/public/rfc/xml/rfc3117.xml" />
</reference>


<reference target2="reference.RFC.3118.xml" anchor="RFC3118">
<front>
<title>Authentication for DHCP Messages</title>
<author fullname="R. Droms" initials="R." surname="Droms">
<organization />
</author>

<author fullname="W. Arbaugh" initials="W." surname="Arbaugh">
<organization />
</author>

<date year="2001" month="June" />
</front>

<seriesInfo value="3118" name="RFC" />
<format octets="35536" type="TXT" target="ftp://ftp.isi.edu/in-notes/rfc3118.txt" />
</reference>


<reference target2="reference.RFC.3119.xml" anchor="RFC3119">
<front>
<title>A More Loss-Tolerant RTP Payload Format for MP3 Audio</title>
<author fullname="R. Finlayson" initials="R." surname="Finlayson">
<organization />
</author>

<date year="2001" month="June" />
</front>

<seriesInfo value="3119" name="RFC" />
<format octets="37796" type="TXT" target="ftp://ftp.isi.edu/in-notes/rfc3119.txt" />
</reference>


<reference target2="reference.RFC.3120.xml" anchor="RFC3120">
<front>
<title>A URN Namespace for XML.org</title>
<author fullname="K. Best" initials="K." surname="Best">
<organization />
</author>

<author fullname="N. Walsh" initials="N." surname="Walsh">
<organization />
</author>

<date year="2001" month="June" />
</front>

<seriesInfo value="3120" name="RFC" />
<format octets="8068" type="TXT" target="ftp://ftp.isi.edu/in-notes/rfc3120.txt" />
</reference>


<reference target2="reference.RFC.3121.xml" anchor="RFC3121">
<front>
<title>A URN Namespace for OASIS</title>
<author fullname="K. Best" initials="K." surname="Best">
<organization />
</author>

<author fullname="N. Walsh" initials="N." surname="Walsh">
<organization />
</author>

<date year="2001" month="June" />
</front>

<seriesInfo value="3121" name="RFC" />
<format octets="11074" type="TXT" target="ftp://ftp.isi.edu/in-notes/rfc3121.txt" />
</reference>


<reference target2="reference.RFC.3122.xml" anchor="RFC3122">
<front>
<title>Extensions to IPv6 Neighbor Discovery for Inverse Discovery Specification</title>
<author fullname="A. Conta" initials="A." surname="Conta">
<organization />
</author>

<date year="2001" month="June" />
</front>

<seriesInfo value="3122" name="RFC" />
<format octets="40416" type="TXT" target="ftp://ftp.isi.edu/in-notes/rfc3122.txt" />
</reference>


<reference target2="reference.RFC.3123.xml" anchor="RFC3123">
<front>
<title>A DNS RR Type for Lists of Address Prefixes (APL RR)</title>
<author fullname="P. Koch" initials="P." surname="Koch">
<organization />
</author>

<date year="2001" month="June" />
</front>

<seriesInfo value="3123" name="RFC" />
<format octets="14648" type="TXT" target="ftp://ftp.isi.edu/in-notes/rfc3123.txt" />
</reference>


<reference target2="reference.RFC.3124.xml" anchor="RFC3124">
<front>
<title>The Congestion Manager</title>
<author fullname="H. Balakrishnan" initials="H." surname="Balakrishnan">
<organization />
</author>

<author fullname="S. Seshan" initials="S." surname="Seshan">
<organization />
</author>

<date year="2001" month="June" />
</front>

<seriesInfo value="3124" name="RFC" />
<format octets="53591" type="TXT" target="ftp://ftp.isi.edu/in-notes/rfc3124.txt" />
</reference>


<reference target2="reference.RFC.3125.xml" anchor="RFC3125">
<front>
<title>Electronic Signature Policies</title>
<author fullname="J. Ross" initials="J." surname="Ross">
<organization />
</author>

<author fullname="D. Pinkas" initials="D." surname="Pinkas">
<organization />
</author>

<author fullname="N. Pope" initials="N." surname="Pope">
<organization />
</author>

<date year="2001" month="September" />
</front>

<seriesInfo value="3125" name="RFC" />
<format octets="95505" type="TXT" target="ftp://ftp.isi.edu/in-notes/rfc3125.txt" />
</reference>


<reference target2="reference.RFC.3126.xml" anchor="RFC3126">
<front>
<title>Electronic Signature Formats for long term electronic signatures</title>
<author fullname="D. Pinkas" initials="D." surname="Pinkas">
<organization />
</author>

<author fullname="J. Ross" initials="J." surname="Ross">
<organization />
</author>

<author fullname="N. Pope" initials="N." surname="Pope">
<organization />
</author>

<date year="2001" month="September" />
</front>

<seriesInfo value="3126" name="RFC" />
<format octets="175886" type="TXT" target="ftp://ftp.isi.edu/in-notes/rfc3126.txt" />
</reference>


<reference target2="reference.RFC.3127.xml" anchor="RFC3127">
<front>
<title>Authentication, Authorization, and Accounting: Protocol Evaluation</title>
<author fullname="D. Mitton" initials="D." surname="Mitton">
<organization />
</author>

<author fullname="M. St. Johns" initials="M." surname="St. Johns">
<organization />
</author>

<author fullname="S. Barkley" initials="S." surname="Barkley">
<organization />
</author>

<author fullname="D. Nelson" initials="D." surname="Nelson">
<organization />
</author>

<author fullname="B. Patil" initials="B." surname="Patil">
<organization />
</author>

<author fullname="M. Stevens" initials="M." surname="Stevens">
<organization />
</author>

<author fullname="B. Wolff" initials="B." surname="Wolff">
<organization />
</author>

<date year="2001" month="June" />
</front>

<seriesInfo value="3127" name="RFC" />
<format octets="170579" type="TXT" target="ftp://ftp.isi.edu/in-notes/rfc3127.txt" />
</reference>


<reference target2="reference.RFC.3128.xml" anchor="RFC3128">
<front>
<title>Protection Against a Variant of the Tiny Fragment Attack (RFC 1858)</title>
<author fullname="I. Miller" initials="I." surname="Miller">
<organization />
</author>

<date year="2001" month="June" />
</front>

<seriesInfo value="3128" name="RFC" />
<format octets="8242" type="TXT" target="ftp://ftp.isi.edu/in-notes/rfc3128.txt" />
</reference>


<reference target2="reference.RFC.3129.xml" anchor="RFC3129">
<front>
<title>Requirements for Kerberized Internet Negotiation of Keys</title>
<author fullname="M. Thomas" initials="M." surname="Thomas">
<organization />
</author>

<date year="2001" month="June" />
</front>

<seriesInfo value="3129" name="RFC" />
<format octets="11401" type="TXT" target="ftp://ftp.isi.edu/in-notes/rfc3129.txt" />
</reference>


<reference target2="reference.RFC.3130.xml" anchor="RFC3130">
<front>
<title>Notes from the State-Of-The-Technology: DNSSEC</title>
<author fullname="E. Lewis" initials="E." surname="Lewis">
<organization />
</author>

<date year="2001" month="June" />
</front>

<seriesInfo value="3130" name="RFC" />
<format octets="22291" type="TXT" target="ftp://ftp.isi.edu/in-notes/rfc3130.txt" />
</reference>


<reference target2="reference.RFC.3131.xml" anchor="RFC3131">
<front>
<title>3GPP2-IETF Standardization Collaboration</title>
<author fullname="S. Bradner" initials="S." surname="Bradner">
<organization />
</author>

<author fullname="P. Calhoun" initials="P." surname="Calhoun">
<organization />
</author>

<author fullname="H. Cuschieri" initials="H." surname="Cuschieri">
<organization />
</author>

<author fullname="S. Dennett" initials="S." surname="Dennett">
<organization />
</author>

<author fullname="G. Flynn" initials="G." surname="Flynn">
<organization />
</author>

<author fullname="M. Lipford" initials="M." surname="Lipford">
<organization />
</author>

<author fullname="M. McPheters" initials="M." surname="McPheters">
<organization />
</author>

<date year="2001" month="June" />
</front>

<seriesInfo value="3131" name="RFC" />
<format octets="13643" type="TXT" target="ftp://ftp.isi.edu/in-notes/rfc3131.txt" />
</reference>


<reference target2="reference.RFC.3132.xml" anchor="RFC3132">
<front>
<title>Dormant Mode Host Alerting ("IP Paging") Problem Statement</title>
<author fullname="J. Kempf" initials="J." surname="Kempf">
<organization />
</author>

<date year="2001" month="June" />
</front>

<seriesInfo value="3132" name="RFC" />
<format octets="34985" type="TXT" target="ftp://ftp.isi.edu/in-notes/rfc3132.txt" />
</reference>


<reference target2="reference.RFC.3133.xml" anchor="RFC3133">
<front>
<title>Terminology for Frame Relay Benchmarking</title>
<author fullname="J. Dunn" initials="J." surname="Dunn">
<organization />
</author>

<author fullname="C. Martin" initials="C." surname="Martin">
<organization />
</author>

<date year="2001" month="June" />
</front>

<seriesInfo value="3133" name="RFC" />
<format octets="44182" type="TXT" target="ftp://ftp.isi.edu/in-notes/rfc3133.txt" />
</reference>


<reference target2="reference.RFC.3134.xml" anchor="RFC3134">
<front>
<title>Terminology for ATM ABR Benchmarking</title>
<author fullname="J. Dunn" initials="J." surname="Dunn">
<organization />
</author>

<author fullname="C. Martin" initials="C." surname="Martin">
<organization />
</author>

<date year="2001" month="June" />
</front>

<seriesInfo value="3134" name="RFC" />
<format octets="29542" type="TXT" target="ftp://ftp.isi.edu/in-notes/rfc3134.txt" />
</reference>


<reference target2="reference.RFC.3135.xml" anchor="RFC3135">
<front>
<title>Performance Enhancing Proxies Intended to Mitigate Link-Related Degradations</title>
<author fullname="J. Border" initials="J." surname="Border">
<organization />
</author>

<author fullname="M. Kojo" initials="M." surname="Kojo">
<organization />
</author>

<author fullname="J. Griner" initials="J." surname="Griner">
<organization />
</author>

<author fullname="G. Montenegro" initials="G." surname="Montenegro">
<organization />
</author>

<author fullname="Z. Shelby" initials="Z." surname="Shelby">
<organization />
</author>

<date year="2001" month="June" />
</front>

<seriesInfo value="3135" name="RFC" />
<format octets="114825" type="TXT" target="ftp://ftp.isi.edu/in-notes/rfc3135.txt" />
</reference>


<reference target2="reference.RFC.3136.xml" anchor="RFC3136">
<front>
<title>The SPIRITS Architecture</title>
<author fullname="L. Slutsman" initials="L." surname="Slutsman">
<organization />
</author>

<author fullname="I. Faynberg" initials="I." surname="Faynberg">
<organization />
</author>

<author fullname="H. Lu" initials="H." surname="Lu">
<organization />
</author>

<author fullname="M. Weissman" initials="M." surname="Weissman">
<organization />
</author>

<date year="2001" month="June" />
</front>

<seriesInfo value="3136" name="RFC" />
<format octets="19241" type="TXT" target="ftp://ftp.isi.edu/in-notes/rfc3136.txt" />
</reference>


<reference target2="reference.RFC.3137.xml" anchor="RFC3137">
<front>
<title>OSPF Stub Router Advertisement</title>
<author fullname="A. Retana" initials="A." surname="Retana">
<organization />
</author>

<author fullname="L. Nguyen" initials="L." surname="Nguyen">
<organization />
</author>

<author fullname="R. White" initials="R." surname="White">
<organization />
</author>

<author fullname="A. Zinin" initials="A." surname="Zinin">
<organization />
</author>

<author fullname="D. McPherson" initials="D." surname="McPherson">
<organization />
</author>

<date year="2001" month="June" />
</front>

<seriesInfo value="3137" name="RFC" />
<format octets="8140" type="TXT" target="ftp://ftp.isi.edu/in-notes/rfc3137.txt" />
</reference>


<reference target2="reference.RFC.3138.xml" anchor="RFC3138">
<front>
<title>Extended Assignments in 233/8</title>
<author fullname="D. Meyer" initials="D." surname="Meyer">
<organization />
</author>

<date year="2001" month="June" />
</front>

<seriesInfo value="3138" name="RFC" />
<format octets="6776" type="TXT" target="ftp://ftp.isi.edu/in-notes/rfc3138.txt" />
</reference>


<reference target2="reference.RFC.3139.xml" anchor="RFC3139">
<front>
<title>Requirements for Configuration Management of IP-based Networks</title>
<author fullname="L. Sanchez" initials="L." surname="Sanchez">
<organization />
</author>

<author fullname="K. McCloghrie" initials="K." surname="McCloghrie">
<organization />
</author>

<author fullname="J. Saperia" initials="J." surname="Saperia">
<organization />
</author>

<date year="2001" month="June" />
</front>

<seriesInfo value="3139" name="RFC" />
<format octets="23624" type="TXT" target="ftp://ftp.isi.edu/in-notes/rfc3139.txt" />
</reference>


<reference target2="reference.RFC.3140.xml" anchor="RFC3140">
<front>
<title>Per Hop Behavior Identification Codes</title>
<author fullname="D. Black" initials="D." surname="Black">
<organization />
</author>

<author fullname="S. Brim" initials="S." surname="Brim">
<organization />
</author>

<author fullname="B. Carpenter" initials="B." surname="Carpenter">
<organization />
</author>

<author fullname="F. Le Faucheur" initials="F." surname="Le Faucheur">
<organization />
</author>

<date year="2001" month="June" />
</front>

<seriesInfo value="3140" name="RFC" />
<format octets="16586" type="TXT" target="ftp://ftp.isi.edu/in-notes/rfc3140.txt" />
</reference>


<reference target2="reference.RFC.3141.xml" anchor="RFC3141">
<front>
<title>CDMA2000 Wireless Data Requirements for AAA</title>
<author fullname="T. Hiller" initials="T." surname="Hiller">
<organization />
</author>

<author fullname="P. Walsh" initials="P." surname="Walsh">
<organization />
</author>

<author fullname="X. Chen" initials="X." surname="Chen">
<organization />
</author>

<author fullname="M. Munson" initials="M." surname="Munson">
<organization />
</author>

<author fullname="G. Dommety" initials="G." surname="Dommety">
<organization />
</author>

<author fullname="S. Sivalingham" initials="S." surname="Sivalingham">
<organization />
</author>

<author fullname="B. Lim" initials="B." surname="Lim">
<organization />
</author>

<author fullname="P. McCann" initials="P." surname="McCann">
<organization />
</author>

<author fullname="H. Shiino" initials="H." surname="Shiino">
<organization />
</author>

<author fullname="B. Hirschman" initials="B." surname="Hirschman">
<organization />
</author>

<author fullname="S. Manning" initials="S." surname="Manning">
<organization />
</author>

<author fullname="R. Hsu" initials="R." surname="Hsu">
<organization />
</author>

<author fullname="H. Koo" initials="H." surname="Koo">
<organization />
</author>

<author fullname="M. Lipford" initials="M." surname="Lipford">
<organization />
</author>

<author fullname="P. Calhoun" initials="P." surname="Calhoun">
<organization />
</author>

<author fullname="C. Lo" initials="C." surname="Lo">
<organization />
</author>

<author fullname="E. Jaques" initials="E." surname="Jaques">
<organization />
</author>

<author fullname="E. Campbell" initials="E." surname="Campbell">
<organization />
</author>

<author fullname="Y. Xu" initials="Y." surname="Xu">
<organization />
</author>

<author fullname="S. Baba" initials="S." surname="Baba">
<organization />
</author>

<author fullname="T. Ayaki" initials="T." surname="Ayaki">
<organization />
</author>

<author fullname="T. Seki" initials="T." surname="Seki">
<organization />
</author>

<author fullname="A. Hameed" initials="A." surname="Hameed">
<organization />
</author>

<date year="2001" month="June" />
</front>

<seriesInfo value="3141" name="RFC" />
<format octets="27998" type="TXT" target="ftp://ftp.isi.edu/in-notes/rfc3141.txt" />
</reference>


<reference target2="reference.RFC.3142.xml" anchor="RFC3142">
<front>
<title>An IPv6-to-IPv4 Transport Relay Translator</title>
<author fullname="J. Hagino" initials="J." surname="Hagino">
<organization />
</author>

<author fullname="K. Yamamoto" initials="K." surname="Yamamoto">
<organization />
</author>

<date year="2001" month="June" />
</front>

<seriesInfo value="3142" name="RFC" />
<format octets="20864" type="TXT" target="ftp://ftp.isi.edu/in-notes/rfc3142.txt" />
</reference>


<reference target2="reference.RFC.3143.xml" anchor="RFC3143">
<front>
<title>Known HTTP Proxy/Caching Problems</title>
<author fullname="I. Cooper" initials="I." surname="Cooper">
<organization />
</author>

<author fullname="J. Dilley" initials="J." surname="Dilley">
<organization />
</author>

<date year="2001" month="June" />
</front>

<seriesInfo value="3143" name="RFC" />
<format octets="57117" type="TXT" target="ftp://ftp.isi.edu/in-notes/rfc3143.txt" />
</reference>


<reference target2="reference.RFC.3144.xml" anchor="RFC3144">
<front>
<title>Remote Monitoring MIB Extensions for Interface Parameters Monitoring</title>
<author fullname="D. Romascanu" initials="D." surname="Romascanu">
<organization />
</author>

<date year="2001" month="August" />
</front>

<seriesInfo value="3144" name="RFC" />
<format octets="62491" type="TXT" target="ftp://ftp.isi.edu/in-notes/rfc3144.txt" />
</reference>


<reference target2="reference.RFC.3145.xml" anchor="RFC3145">
<front>
<title>L2TP Disconnect Cause Information</title>
<author fullname="R. Verma" initials="R." surname="Verma">
<organization />
</author>

<author fullname="M. Verma" initials="M." surname="Verma">
<organization />
</author>

<author fullname="J. Carlson" initials="J." surname="Carlson">
<organization />
</author>

<date year="2001" month="July" />
</front>

<seriesInfo value="3145" name="RFC" />
<format octets="17421" type="TXT" target="ftp://ftp.isi.edu/in-notes/rfc3145.txt" />
</reference>


<reference target2="reference.RFC.3146.xml" anchor="RFC3146">
<front>
<title>Transmission of IPv6 Packets over IEEE 1394 Networks</title>
<author fullname="K. Fujisawa" initials="K." surname="Fujisawa">
<organization />
</author>

<author fullname="A. Onoe" initials="A." surname="Onoe">
<organization />
</author>

<date year="2001" month="October" />
</front>

<seriesInfo value="3146" name="RFC" />
<format octets="16569" type="TXT" target="ftp://ftp.isi.edu/in-notes/rfc3146.txt" />
</reference>


<reference target2="reference.RFC.3147.xml" anchor="RFC3147">
<front>
<title>Generic Routing Encapsulation over CLNS Networks</title>
<author fullname="P. Christian" initials="P." surname="Christian">
<organization />
</author>

<date year="2001" month="July" />
</front>

<seriesInfo value="3147" name="RFC" />
<format octets="14125" type="TXT" target="ftp://ftp.isi.edu/in-notes/rfc3147.txt" />
</reference>


<reference target2="reference.RFC.3148.xml" anchor="RFC3148">
<front>
<title>A Framework for Defining Empirical Bulk Transfer Capacity Metrics</title>
<author fullname="M. Mathis" initials="M." surname="Mathis">
<organization />
</author>

<author fullname="M. Allman" initials="M." surname="Allman">
<organization />
</author>

<date year="2001" month="July" />
</front>

<seriesInfo value="3148" name="RFC" />
<format octets="36041" type="TXT" target="ftp://ftp.isi.edu/in-notes/rfc3148.txt" />
</reference>


<reference target2="reference.RFC.3149.xml" anchor="RFC3149">
<front>
<title>MGCP Business Phone Packages</title>
<author fullname="A. Srinath" initials="A." surname="Srinath">
<organization />
</author>

<author fullname="G. Levendel" initials="G." surname="Levendel">
<organization />
</author>

<author fullname="K. Fritz" initials="K." surname="Fritz">
<organization />
</author>

<author fullname="R. Kalyanaram" initials="R." surname="Kalyanaram">
<organization />
</author>

<date year="2001" month="September" />
</front>

<seriesInfo value="3149" name="RFC" />
<format octets="77304" type="TXT" target="ftp://ftp.isi.edu/in-notes/rfc3149.txt" />
</reference>


<reference target2="reference.RFC.3150.xml" anchor="RFC3150">
<front>
<title>End-to-end Performance Implications of Slow Links</title>
<author fullname="S. Dawkins" initials="S." surname="Dawkins">
<organization />
</author>

<author fullname="G. Montenegro" initials="G." surname="Montenegro">
<organization />
</author>

<author fullname="M. Kojo" initials="M." surname="Kojo">
<organization />
</author>

<author fullname="V. Magret" initials="V." surname="Magret">
<organization />
</author>

<date year="2001" month="July" />
</front>

<seriesInfo value="48" name="BCP" />
<seriesInfo value="3150" name="RFC" />
<format octets="39942" type="TXT" target="ftp://ftp.isi.edu/in-notes/rfc3150.txt" />
</reference>


<reference target2="reference.RFC.3151.xml" anchor="RFC3151">
<front>
<title>A URN Namespace for Public Identifiers</title>
<author fullname="N. Walsh" initials="N." surname="Walsh">
<organization />
</author>

<author fullname="J. Cowan" initials="J." surname="Cowan">
<organization />
</author>

<author fullname="P. Grosso" initials="P." surname="Grosso">
<organization />
</author>

<date year="2001" month="August" />
</front>

<seriesInfo value="3151" name="RFC" />
<format octets="15595" type="TXT" target="ftp://ftp.isi.edu/in-notes/rfc3151.txt" />
</reference>


<reference target2="reference.RFC.3152.xml" anchor="RFC3152">
<front>
<title>Delegation of IP6.ARPA</title>
<author fullname="R. Bush" initials="R." surname="Bush">
<organization />
</author>

<date year="2001" month="August" />
</front>

<seriesInfo value="49" name="BCP" />
<seriesInfo value="3152" name="RFC" />
<format octets="5727" type="TXT" target="ftp://ftp.isi.edu/in-notes/rfc3152.txt" />
</reference>


<reference target2="reference.RFC.3153.xml" anchor="RFC3153">
<front>
<title>PPP Multiplexing</title>
<author fullname="R. Pazhyannur" initials="R." surname="Pazhyannur">
<organization />
</author>

<author fullname="I. Ali" initials="I." surname="Ali">
<organization />
</author>

<author fullname="C. Fox" initials="C." surname="Fox">
<organization />
</author>

<date year="2001" month="August" />
</front>

<seriesInfo value="3153" name="RFC" />
<format octets="19244" type="TXT" target="ftp://ftp.isi.edu/in-notes/rfc3153.txt" />
</reference>


<reference target2="reference.RFC.3154.xml" anchor="RFC3154">
<front>
<title>Requirements and Functional Architecture for an IP Host Alerting Protocol</title>
<author fullname="J. Kempf" initials="J." surname="Kempf">
<organization />
</author>

<author fullname="C. Castelluccia" initials="C." surname="Castelluccia">
<organization />
</author>

<author fullname="P. Mutaf" initials="P." surname="Mutaf">
<organization />
</author>

<author fullname="N. Nakajima" initials="N." surname="Nakajima">
<organization />
</author>

<author fullname="Y. Ohba" initials="Y." surname="Ohba">
<organization />
</author>

<author fullname="R. Ramjee" initials="R." surname="Ramjee">
<organization />
</author>

<author fullname="Y. Saifullah" initials="Y." surname="Saifullah">
<organization />
</author>

<author fullname="B. Sarikaya" initials="B." surname="Sarikaya">
<organization />
</author>

<author fullname="X. Xu" initials="X." surname="Xu">
<organization />
</author>

<date year="2001" month="August" />
</front>

<seriesInfo value="3154" name="RFC" />
<format octets="31534" type="TXT" target="ftp://ftp.isi.edu/in-notes/rfc3154.txt" />
</reference>


<reference target2="reference.RFC.3155.xml" anchor="RFC3155">
<front>
<title>End-to-end Performance Implications of Links with Errors</title>
<author fullname="S. Dawkins" initials="S." surname="Dawkins">
<organization />
</author>

<author fullname="G. Montenegro" initials="G." surname="Montenegro">
<organization />
</author>

<author fullname="M. Kojo" initials="M." surname="Kojo">
<organization />
</author>

<author fullname="V. Magret" initials="V." surname="Magret">
<organization />
</author>

<author fullname="N. Vaidya" initials="N." surname="Vaidya">
<organization />
</author>

<date year="2001" month="August" />
</front>

<seriesInfo value="50" name="BCP" />
<seriesInfo value="3155" name="RFC" />
<format octets="36388" type="TXT" target="ftp://ftp.isi.edu/in-notes/rfc3155.txt" />
</reference>


<reference target2="reference.RFC.3156.xml" anchor="RFC3156">
<front>
<title>MIME Security with OpenPGP</title>
<author fullname="M. Elkins" initials="M." surname="Elkins">
<organization />
</author>

<author fullname="D. Del Torto" initials="D." surname="Del Torto">
<organization />
</author>

<author fullname="R. Levien" initials="R." surname="Levien">
<organization />
</author>

<author fullname="T. Roessler" initials="T." surname="Roessler">
<organization />
</author>

<date year="2001" month="August" />
</front>

<seriesInfo value="3156" name="RFC" />
<format octets="26809" type="TXT" target="ftp://ftp.isi.edu/in-notes/rfc3156.txt" />
</reference>


<reference target2="reference.RFC.3157.xml" anchor="RFC3157">
<front>
<title>Securely Available Credentials - Requirements</title>
<author fullname="A. Arsenault" initials="A." surname="Arsenault">
<organization />
</author>

<author fullname="S. Farrell" initials="S." surname="Farrell">
<organization />
</author>

<date year="2001" month="August" />
</front>

<seriesInfo value="3157" name="RFC" />
<format octets="46169" type="TXT" target="ftp://ftp.isi.edu/in-notes/rfc3157.txt" />
</reference>


<reference target2="reference.RFC.3158.xml" anchor="RFC3158">
<front>
<title>RTP Testing Strategies</title>
<author fullname="C. Perkins" initials="C." surname="Perkins">
<organization />
</author>

<author fullname="J. Rosenberg" initials="J." surname="Rosenberg">
<organization />
</author>

<author fullname="H. Schulzrinne" initials="H." surname="Schulzrinne">
<organization />
</author>

<date year="2001" month="August" />
</front>

<seriesInfo value="3158" name="RFC" />
<format octets="48208" type="TXT" target="ftp://ftp.isi.edu/in-notes/rfc3158.txt" />
</reference>


<reference target2="reference.RFC.3159.xml" anchor="RFC3159">
<front>
<title>Structure of Policy Provisioning Information (SPPI)</title>
<author fullname="K. McCloghrie" initials="K." surname="McCloghrie">
<organization />
</author>

<author fullname="M. Fine" initials="M." surname="Fine">
<organization />
</author>

<author fullname="J. Seligson" initials="J." surname="Seligson">
<organization />
</author>

<author fullname="K. Chan" initials="K." surname="Chan">
<organization />
</author>

<author fullname="S. Hahn" initials="S." surname="Hahn">
<organization />
</author>

<author fullname="R. Sahita" initials="R." surname="Sahita">
<organization />
</author>

<author fullname="A. Smith" initials="A." surname="Smith">
<organization />
</author>

<author fullname="F. Reichmeyer" initials="F." surname="Reichmeyer">
<organization />
</author>

<date year="2001" month="August" />
</front>

<seriesInfo value="3159" name="RFC" />
<format octets="78621" type="TXT" target="ftp://ftp.isi.edu/in-notes/rfc3159.txt" />
</reference>


<reference target2="reference.RFC.3160.xml" anchor="RFC3160">
<front>
<title>The Tao of IETF - A Novice's Guide to the Internet Engineering Task Force</title>
<author fullname="S. Harris" initials="S." surname="Harris">
<organization />
</author>

<date year="2001" month="August" />
</front>

<seriesInfo value="3160" name="RFC" />
<format octets="98411" type="TXT" target="ftp://ftp.isi.edu/in-notes/rfc3160.txt" />
</reference>


<reference target2="reference.RFC.3161.xml" anchor="RFC3161">
<front>
<title>Internet X.509 Public Key Infrastructure Time-Stamp Protocol (TSP)</title>
<author fullname="C. Adams" initials="C." surname="Adams">
<organization />
</author>

<author fullname="P. Cain" initials="P." surname="Cain">
<organization />
</author>

<author fullname="D. Pinkas" initials="D." surname="Pinkas">
<organization />
</author>

<author fullname="R. Zuccherato" initials="R." surname="Zuccherato">
<organization />
</author>

<date year="2001" month="August" />
</front>

<seriesInfo value="3161" name="RFC" />
<format octets="54585" type="TXT" target="ftp://ftp.isi.edu/in-notes/rfc3161.txt" />
</reference>


<reference target2="reference.RFC.3162.xml" anchor="RFC3162">
<front>
<title>RADIUS and IPv6</title>
<author fullname="B. Aboba" initials="B." surname="Aboba">
<organization />
</author>

<author fullname="G. Zorn" initials="G." surname="Zorn">
<organization />
</author>

<author fullname="D. Mitton" initials="D." surname="Mitton">
<organization />
</author>

<date year="2001" month="August" />
</front>

<seriesInfo value="3162" name="RFC" />
<format octets="20492" type="TXT" target="ftp://ftp.isi.edu/in-notes/rfc3162.txt" />
</reference>


<reference target2="reference.RFC.3163.xml" anchor="RFC3163">
<front>
<title>ISO/IEC 9798-3 Authentication SASL Mechanism</title>
<author fullname="R. Zuccherato" initials="R." surname="Zuccherato">
<organization />
</author>

<author fullname="M. Nystrom" initials="M." surname="Nystrom">
<organization />
</author>

<date year="2001" month="August" />
</front>

<seriesInfo value="3163" name="RFC" />
<format octets="32498" type="TXT" target="ftp://ftp.isi.edu/in-notes/rfc3163.txt" />
</reference>


<reference target2="reference.RFC.3164.xml" anchor="RFC3164">
<front>
<title>The BSD Syslog Protocol</title>
<author fullname="C. Lonvick" initials="C." surname="Lonvick">
<organization />
</author>

<date year="2001" month="August" />
</front>

<seriesInfo value="3164" name="RFC" />
<format octets="72951" type="TXT" target="ftp://ftp.isi.edu/in-notes/rfc3164.txt" />
</reference>


<reference target2="reference.RFC.3165.xml" anchor="RFC3165">
<front>
<title>Definitions of Managed Objects for the Delegation of Management Scripts</title>
<author fullname="D. Levi" initials="D." surname="Levi">
<organization />
</author>

<author fullname="J. Schoenwaelder" initials="J." surname="Schoenwaelder">
<organization />
</author>

<date year="2001" month="August" />
</front>

<seriesInfo value="3165" name="RFC" />
<format octets="134479" type="TXT" target="ftp://ftp.isi.edu/in-notes/rfc3165.txt" />
</reference>


<reference target2="reference.RFC.3166.xml" anchor="RFC3166">
<front>
<title>Request to Move RFC 1403 to Historic Status</title>
<author fullname="D. Meyer" initials="D." surname="Meyer">
<organization />
</author>

<author fullname="J. Scudder" initials="J." surname="Scudder">
<organization />
</author>

<date year="2001" month="August" />
</front>

<seriesInfo value="3166" name="RFC" />
<format octets="3740" type="TXT" target="ftp://ftp.isi.edu/in-notes/rfc3166.txt" />
</reference>


<reference target2="reference.RFC.3167.xml" anchor="RFC3167">
<front>
<title>Request to Move RFC 1745 to Historic Status</title>
<author fullname="D. Meyer" initials="D." surname="Meyer">
<organization />
</author>

<author fullname="J. Scudder" initials="J." surname="Scudder">
<organization />
</author>

<date year="2001" month="August" />
</front>

<seriesInfo value="3167" name="RFC" />
<format octets="3825" type="TXT" target="ftp://ftp.isi.edu/in-notes/rfc3167.txt" />
</reference>


<reference target2="reference.RFC.3168.xml" anchor="RFC3168">
<front>
<title>The Addition of Explicit Congestion Notification (ECN) to IP</title>
<author fullname="K. Ramakrishnan" initials="K." surname="Ramakrishnan">
<organization />
</author>

<author fullname="S. Floyd" initials="S." surname="Floyd">
<organization />
</author>

<author fullname="D. Black" initials="D." surname="Black">
<organization />
</author>

<date year="2001" month="September" />
</front>

<seriesInfo value="3168" name="RFC" />
<format octets="170966" type="TXT" target="ftp://ftp.isi.edu/in-notes/rfc3168.txt" />
</reference>


<reference target2="reference.RFC.3169.xml" anchor="RFC3169">
<front>
<title>Criteria for Evaluating Network Access Server Protocols</title>
<author fullname="M. Beadles" initials="M." surname="Beadles">
<organization />
</author>

<author fullname="D. Mitton" initials="D." surname="Mitton">
<organization />
</author>

<date year="2001" month="September" />
</front>

<seriesInfo value="3169" name="RFC" />
<format octets="35303" type="TXT" target="ftp://ftp.isi.edu/in-notes/rfc3169.txt" />
</reference>


<reference target2="reference.RFC.3170.xml" anchor="RFC3170">
<front>
<title>IP Multicast Applications: Challenges and Solutions</title>
<author fullname="B. Quinn" initials="B." surname="Quinn">
<organization />
</author>

<author fullname="K. Almeroth" initials="K." surname="Almeroth">
<organization />
</author>

<date year="2001" month="September" />
</front>

<seriesInfo value="3170" name="RFC" />
<format octets="67207" type="TXT" target="ftp://ftp.isi.edu/in-notes/rfc3170.txt" />
</reference>


<reference target2="reference.RFC.3171.xml" anchor="RFC3171">
<front>
<title>IANA Guidelines for IPv4 Multicast Address Assignments</title>
<author fullname="Z. Albanna" initials="Z." surname="Albanna">
<organization />
</author>

<author fullname="K. Almeroth" initials="K." surname="Almeroth">
<organization />
</author>

<author fullname="D. Meyer" initials="D." surname="Meyer">
<organization />
</author>

<author fullname="M. Schipper" initials="M." surname="Schipper">
<organization />
</author>

<date year="2001" month="August" />
</front>

<seriesInfo value="51" name="BCP" />
<seriesInfo value="3171" name="RFC" />
<format octets="15389" type="TXT" target="ftp://ftp.isi.edu/in-notes/rfc3171.txt" />
</reference>


<reference target2="reference.RFC.3172.xml" anchor="RFC3172">
<front>
<title>Management Guidelines &amp; Operational Requirements for the Address and Routing Parameter Area Domain ("arpa")</title>
<author fullname="G. Huston" initials="G." surname="Huston">
<organization />
</author>

<date year="2001" month="September" />
</front>

<seriesInfo value="52" name="BCP" />
<seriesInfo value="3172" name="RFC" />
<format octets="18097" type="TXT" target="ftp://ftp.isi.edu/in-notes/rfc3172.txt" />
</reference>


<reference target2="reference.RFC.3173.xml" anchor="RFC3173">
<front>
<title>IP Payload Compression Protocol (IPComp)</title>
<author fullname="A. Shacham" initials="A." surname="Shacham">
<organization />
</author>

<author fullname="B. Monsour" initials="B." surname="Monsour">
<organization />
</author>

<author fullname="R. Pereira" initials="R." surname="Pereira">
<organization />
</author>

<author fullname="M. Thomas" initials="M." surname="Thomas">
<organization />
</author>

<date year="2001" month="September" />
</front>

<seriesInfo value="3173" name="RFC" />
<format octets="15389" type="TXT" target="ftp://ftp.isi.edu/in-notes/rfc3173.txt" />
</reference>


<reference target2="reference.RFC.3174.xml" anchor="RFC3174">
<front>
<title>US Secure Hash Algorithm 1 (SHA1)</title>
<author fullname="D. Eastlake" initials="D." surname="Eastlake">
<organization />
</author>

<author fullname="P. Jones" initials="P." surname="Jones">
<organization />
</author>

<date year="2001" month="September" />
</front>

<seriesInfo value="3174" name="RFC" />
<format octets="35525" type="TXT" target="ftp://ftp.isi.edu/in-notes/rfc3174.txt" />
</reference>


<reference target2="reference.RFC.3175.xml" anchor="RFC3175">
<front>
<title>Aggregation of RSVP for IPv4 and IPv6 Reservations</title>
<author fullname="F. Baker" initials="F." surname="Baker">
<organization />
</author>

<author fullname="C. Iturralde" initials="C." surname="Iturralde">
<organization />
</author>

<author fullname="F. Le Faucheur" initials="F." surname="Le Faucheur">
<organization />
</author>

<author fullname="B. Davie" initials="B." surname="Davie">
<organization />
</author>

<date year="2001" month="September" />
</front>

<seriesInfo value="3175" name="RFC" />
<format octets="88681" type="TXT" target="ftp://ftp.isi.edu/in-notes/rfc3175.txt" />
</reference>


<reference target2="reference.RFC.3176.xml" anchor="RFC3176">
<front>
<title>InMon Corporation's sFlow: A Method for Monitoring Traffic in Switched and Routed Networks</title>
<author fullname="P. Phaal" initials="P." surname="Phaal">
<organization />
</author>

<author fullname="S. Panchen" initials="S." surname="Panchen">
<organization />
</author>

<author fullname="N. McKee" initials="N." surname="McKee">
<organization />
</author>

<date year="2001" month="September" />
</front>

<seriesInfo value="3176" name="RFC" />
<format octets="60171" type="TXT" target="ftp://ftp.isi.edu/in-notes/rfc3176.txt" />
</reference>


<reference target2="reference.RFC.3177.xml" anchor="RFC3177">
<front>
<title>IAB/IESG Recommendations on IPv6 Address</title>
<author>
<organization>IAB</organization>
</author>

<author>
<organization>IESG</organization>
</author>

<date year="2001" month="September" />
</front>

<seriesInfo value="3177" name="RFC" />
<format octets="23178" type="TXT" target="ftp://ftp.isi.edu/in-notes/rfc3177.txt" />
</reference>


<reference target2="reference.RFC.3178.xml" anchor="RFC3178">
<front>
<title>IPv6 Multihoming Support at Site Exit Routers</title>
<author fullname="J. Hagino" initials="J." surname="Hagino">
<organization />
</author>

<author fullname="H. Snyder" initials="H." surname="Snyder">
<organization />
</author>

<date year="2001" month="October" />
</front>

<seriesInfo value="3178" name="RFC" />
<format octets="24453" type="TXT" target="ftp://ftp.isi.edu/in-notes/rfc3178.txt" />
</reference>


<reference target2="reference.RFC.3179.xml" anchor="RFC3179">
<front>
<title>Script MIB Extensibility Protocol Version 1.1</title>
<author fullname="J. Schoenwaelder" initials="J." surname="Schoenwaelder">
<organization />
</author>

<author fullname="J. Quittek" initials="J." surname="Quittek">
<organization />
</author>

<date year="2001" month="October" />
</front>

<seriesInfo value="3179" name="RFC" />
<format octets="56311" type="TXT" target="ftp://ftp.isi.edu/in-notes/rfc3179.txt" />
</reference>


<reference target2="reference.RFC.3180.xml" anchor="RFC3180">
<front>
<title>GLOP Addressing in 233/8</title>
<author fullname="D. Meyer" initials="D." surname="Meyer">
<organization />
</author>

<author fullname="P. Lothberg" initials="P." surname="Lothberg">
<organization />
</author>

<date year="2001" month="September" />
</front>

<seriesInfo value="53" name="BCP" />
<seriesInfo value="3180" name="RFC" />
<format octets="8225" type="TXT" target="ftp://ftp.isi.edu/in-notes/rfc3180.txt" />
</reference>


<reference target2="reference.RFC.3181.xml" anchor="RFC3181">
<front>
<title>Signaled Preemption Priority Policy Element</title>
<author fullname="S. Herzog" initials="S." surname="Herzog">
<organization />
</author>

<date year="2001" month="October" />
</front>

<seriesInfo value="3181" name="RFC" />
<format octets="21990" type="TXT" target="ftp://ftp.isi.edu/in-notes/rfc3181.txt" />
</reference>


<reference target2="reference.RFC.3182.xml" anchor="RFC3182">
<front>
<title>Identity Representation for RSVP</title>
<author fullname="S. Yadav" initials="S." surname="Yadav">
<organization />
</author>

<author fullname="R. Yavatkar" initials="R." surname="Yavatkar">
<organization />
</author>

<author fullname="R. Pabbati" initials="R." surname="Pabbati">
<organization />
</author>

<author fullname="P. Ford" initials="P." surname="Ford">
<organization />
</author>

<author fullname="T. Moore" initials="T." surname="Moore">
<organization />
</author>

<author fullname="S. Herzog" initials="S." surname="Herzog">
<organization />
</author>

<author fullname="R. Hess" initials="R." surname="Hess">
<organization />
</author>

<date year="2001" month="October" />
</front>

<seriesInfo value="3182" name="RFC" />
<format octets="36544" type="TXT" target="ftp://ftp.isi.edu/in-notes/rfc3182.txt" />
</reference>


<reference target2="reference.RFC.3183.xml" anchor="RFC3183">
<front>
<title>Domain Security Services using S/MIME</title>
<author fullname="T. Dean" initials="T." surname="Dean">
<organization />
</author>

<author fullname="W. Ottaway" initials="W." surname="Ottaway">
<organization />
</author>

<date year="2001" month="October" />
</front>

<seriesInfo value="3183" name="RFC" />
<format octets="57129" type="TXT" target="ftp://ftp.isi.edu/in-notes/rfc3183.txt" />
</reference>


<reference target2="reference.RFC.3184.xml" anchor="RFC3184">
<front>
<title>IETF Guidelines for Conduct</title>
<author fullname="S. Harris" initials="S." surname="Harris">
<organization />
</author>

<date year="2001" month="October" />
</front>

<seriesInfo value="54" name="BCP" />
<seriesInfo value="3184" name="RFC" />
<format octets="7413" type="TXT" target="ftp://ftp.isi.edu/in-notes/rfc3184.txt" />
</reference>


<reference target2="reference.RFC.3185.xml" anchor="RFC3185">
<front>
<title>Reuse of CMS Content Encryption Keys</title>
<author fullname="S. Farrell" initials="S." surname="Farrell">
<organization />
</author>

<author fullname="S. Turner" initials="S." surname="Turner">
<organization />
</author>

<date year="2001" month="October" />
</front>

<seriesInfo value="3185" name="RFC" />
<format octets="20404" type="TXT" target="ftp://ftp.isi.edu/in-notes/rfc3185.txt" />
</reference>


<reference target2="reference.RFC.3186.xml" anchor="RFC3186">
<front>
<title>MAPOS/PPP Tunneling mode</title>
<author fullname="S. Shimizu" initials="S." surname="Shimizu">
<organization />
</author>

<author fullname="T. Kawano" initials="T." surname="Kawano">
<organization />
</author>

<author fullname="K. Murakami" initials="K." surname="Murakami">
<organization />
</author>

<author fullname="E. Beier" initials="E." surname="Beier">
<organization />
</author>

<date year="2001" month="December" />
</front>

<seriesInfo value="3186" name="RFC" />
<format octets="27109" type="TXT" target="ftp://ftp.isi.edu/in-notes/rfc3186.txt" />
</reference>


<reference target2="reference.RFC.3187.xml" anchor="RFC3187">
<front>
<title>Using International Standard Book Numbers as Uniform Resource Names</title>
<author fullname="J. Hakala" initials="J." surname="Hakala">
<organization />
</author>

<author fullname="H. Walravens" initials="H." surname="Walravens">
<organization />
</author>

<date year="2001" month="October" />
</front>

<seriesInfo value="3187" name="RFC" />
<format octets="22620" type="TXT" target="ftp://ftp.isi.edu/in-notes/rfc3187.txt" />
</reference>


<reference target2="reference.RFC.3188.xml" anchor="RFC3188">
<front>
<title>Using National Bibliography Numbers as Uniform Resource Names</title>
<author fullname="J. Hakala" initials="J." surname="Hakala">
<organization />
</author>

<date year="2001" month="October" />
</front>

<seriesInfo value="3188" name="RFC" />
<format octets="27923" type="TXT" target="ftp://ftp.isi.edu/in-notes/rfc3188.txt" />
</reference>


<reference target2="reference.RFC.3189.xml" anchor="RFC3189">
<front>
<title>RTP Payload Format for DV (IEC 61834) Video</title>
<author fullname="K. Kobayashi" initials="K." surname="Kobayashi">
<organization />
</author>

<author fullname="A. Ogawa" initials="A." surname="Ogawa">
<organization />
</author>

<author fullname="S. Casner" initials="S." surname="Casner">
<organization />
</author>

<author fullname="C. Bormann" initials="C." surname="Bormann">
<organization />
</author>

<date year="2002" month="January" />
</front>

<seriesInfo value="3189" name="RFC" />
<format octets="25991" type="TXT" target="ftp://ftp.isi.edu/in-notes/rfc3189.txt" />
</reference>


<reference target2="reference.RFC.3190.xml" anchor="RFC3190">
<front>
<title>RTP Payload Format for 12-bit DAT Audio and 20- and 24-bit Linear Sampled Audio</title>
<author fullname="K. Kobayashi" initials="K." surname="Kobayashi">
<organization />
</author>

<author fullname="A. Ogawa" initials="A." surname="Ogawa">
<organization />
</author>

<author fullname="S. Casner" initials="S." surname="Casner">
<organization />
</author>

<author fullname="C. Bormann" initials="C." surname="Bormann">
<organization />
</author>

<date year="2002" month="January" />
</front>

<seriesInfo value="3190" name="RFC" />
<format octets="34977" type="TXT" target="ftp://ftp.isi.edu/in-notes/rfc3190.txt" />
</reference>


<reference target2="reference.RFC.3191.xml" anchor="RFC3191">
<front>
<title>Minimal GSTN address format in Internet Mail</title>
<author fullname="C. Allocchio" initials="C." surname="Allocchio">
<organization />
</author>

<date year="2001" month="October" />
</front>

<seriesInfo value="3191" name="RFC" />
<format octets="24235" type="TXT" target="ftp://ftp.isi.edu/in-notes/rfc3191.txt" />
</reference>


<reference target2="reference.RFC.3192.xml" anchor="RFC3192">
<front>
<title>Minimal FAX address format in Internet Mail</title>
<author fullname="C. Allocchio" initials="C." surname="Allocchio">
<organization />
</author>

<date year="2001" month="October" />
</front>

<seriesInfo value="3192" name="RFC" />
<format octets="18813" type="TXT" target="ftp://ftp.isi.edu/in-notes/rfc3192.txt" />
</reference>


<reference target2="reference.RFC.3193.xml" anchor="RFC3193">
<front>
<title>Securing L2TP using IPsec</title>
<author fullname="B. Patel" initials="B." surname="Patel">
<organization />
</author>

<author fullname="B. Aboba" initials="B." surname="Aboba">
<organization />
</author>

<author fullname="W. Dixon" initials="W." surname="Dixon">
<organization />
</author>

<author fullname="G. Zorn" initials="G." surname="Zorn">
<organization />
</author>

<author fullname="S. Booth" initials="S." surname="Booth">
<organization />
</author>

<date year="2001" month="November" />
</front>

<seriesInfo value="3193" name="RFC" />
<format octets="63804" type="TXT" target="ftp://ftp.isi.edu/in-notes/rfc3193.txt" />
</reference>


<reference target2="reference.RFC.3194.xml" anchor="RFC3194">
<front>
<title>The H-Density Ratio for Address Assignment Efficiency An Update on the H ratio</title>
<author fullname="A. Durand" initials="A." surname="Durand">
<organization />
</author>

<author fullname="C. Huitema" initials="C." surname="Huitema">
<organization />
</author>

<date year="2001" month="November" />
</front>

<seriesInfo value="3194" name="RFC" />
<format octets="14539" type="TXT" target="ftp://ftp.isi.edu/in-notes/rfc3194.txt" />
</reference>


<reference target2="reference.RFC.3195.xml" anchor="RFC3195">
<front>
<title>Reliable Delivery for syslog</title>
<author fullname="Darren New" initials="D." surname="New">
<organization />

<address>
<postal>
<street>5390 Caminito Exquisito</street>
<city>San Diego</city>
<region>CA</region>
<code>92130</code>
<country>US</country>
</postal>

<phone>+1 858 350 9733</phone>
<email>dnew@san.rr.com</email>
</address>
</author>

<author fullname="Marshall T. Rose" initials="M.T." surname="Rose">
<organization>Dover Beach Consulting, Inc.</organization>

<address>
<postal>
<street>POB 255268</street>
<city>Sacramento</city>
<region>CA</region>
<code>95865-5268</code>
<country>US</country>
</postal>

<phone>+1 916 483 8878</phone>
<email>mrose@dbc.mtview.ca.us</email>
</address>
</author>

<date year="2001" month="November" />
<area>Applications</area>
<keyword>syslog</keyword>
<keyword>BEEP</keyword>

<abstract>
<t>The BSD Syslog Protocol describes
a number of service options related to propagating event messages.
This memo describes two mappings of the syslog protocol to 
TCP connections, both useful for reliable delivery of event messages.
The first provides a trivial mapping maximizing backward compatibility.
The second provides a more complete mapping. Both provide a degree of 
robustness and security in message delivery that is unavailable to 
the usual UDP-based syslog protocol, by providing encryption and 
authentication over a connection-oriented protocol. 
</t>
</abstract>
</front>

<seriesInfo value="3195" name="RFC" />
<format octets="72009" type="HTML" target="http://xml.resource.org/public/rfc/html/rfc3195.html" />
<format octets="63059" type="XML" target="http://xml.resource.org/public/rfc/xml/rfc3195.xml" />
</reference>


<reference target2="reference.RFC.3196.xml" anchor="RFC3196">
<front>
<title>Internet Printing Protocol/1.1: Implementor's Guide</title>
<author fullname="T. Hastings" initials="T." surname="Hastings">
<organization />
</author>

<author fullname="C. Manros" initials="C." surname="Manros">
<organization />
</author>

<author fullname="P. Zehler" initials="P." surname="Zehler">
<organization />
</author>

<author fullname="C. Kugler" initials="C." surname="Kugler">
<organization />
</author>

<author fullname="H. Holst" initials="H." surname="Holst">
<organization />
</author>

<date year="2001" month="November" />
</front>

<seriesInfo value="3196" name="RFC" />
<format octets="200720" type="TXT" target="ftp://ftp.isi.edu/in-notes/rfc3196.txt" />
</reference>


<reference target2="reference.RFC.3197.xml" anchor="RFC3197">
<front>
<title>Applicability Statement for DNS MIB Extensions</title>
<author fullname="R. Austein" initials="R." surname="Austein">
<organization />
</author>

<date year="2001" month="November" />
</front>

<seriesInfo value="3197" name="RFC" />
<format octets="8610" type="TXT" target="ftp://ftp.isi.edu/in-notes/rfc3197.txt" />
</reference>


<reference target2="reference.RFC.3198.xml" anchor="RFC3198">
<front>
<title>Terminology for Policy-Based Management</title>
<author fullname="A. Westerinen" initials="A." surname="Westerinen">
<organization />
</author>

<author fullname="J. Schnizlein" initials="J." surname="Schnizlein">
<organization />
</author>

<author fullname="J. Strassner" initials="J." surname="Strassner">
<organization />
</author>

<author fullname="M. Scherling" initials="M." surname="Scherling">
<organization />
</author>

<author fullname="B. Quinn" initials="B." surname="Quinn">
<organization />
</author>

<author fullname="S. Herzog" initials="S." surname="Herzog">
<organization />
</author>

<author fullname="A. Huynh" initials="A." surname="Huynh">
<organization />
</author>

<author fullname="M. Carlson" initials="M." surname="Carlson">
<organization />
</author>

<author fullname="J. Perry" initials="J." surname="Perry">
<organization />
</author>

<author fullname="S. Waldbusser" initials="S." surname="Waldbusser">
<organization />
</author>

<date year="2001" month="November" />
</front>

<seriesInfo value="3198" name="RFC" />
<format octets="47806" type="TXT" target="ftp://ftp.isi.edu/in-notes/rfc3198.txt" />
</reference>


<reference target2="reference.RFC.3199.xml" anchor="RFC3199">
<front>
<title>Request for Comments Summary RFC Numbers 3100-3199</title>
<author fullname="S. Ginoza" initials="S." surname="Ginoza">
<organization />
</author>

<date year="2003" month="February" />
</front>

<seriesInfo value="3199" name="RFC" />
<format octets="47287" type="TXT" target="ftp://ftp.isi.edu/in-notes/rfc3199.txt" />
</reference>


<reference target2="reference.RFC.3201.xml" anchor="RFC3201">
<front>
<title>Definitions of Managed Objects for Circuit to Interface Translation</title>
<author fullname="R. Steinberger" initials="R." surname="Steinberger">
<organization />
</author>

<author fullname="O. Nicklass" initials="O." surname="Nicklass">
<organization />
</author>

<date year="2002" month="January" />
</front>

<seriesInfo value="3201" name="RFC" />
<format octets="45583" type="TXT" target="ftp://ftp.isi.edu/in-notes/rfc3201.txt" />
</reference>


<reference target2="reference.RFC.3202.xml" anchor="RFC3202">
<front>
<title>Definitions of Managed Objects for Frame Relay Service Level Definitions</title>
<author fullname="R. Steinberger" initials="R." surname="Steinberger">
<organization />
</author>

<author fullname="O. Nicklass" initials="O." surname="Nicklass">
<organization />
</author>

<date year="2002" month="January" />
</front>

<seriesInfo value="3202" name="RFC" />
<format octets="130816" type="TXT" target="ftp://ftp.isi.edu/in-notes/rfc3202.txt" />
</reference>


<reference target2="reference.RFC.3203.xml" anchor="RFC3203">
<front>
<title>DHCP reconfigure extension</title>
<author fullname="Y. T&apos;Joens" initials="Y." surname="T&apos;Joens">
<organization />
</author>

<author fullname="C. Hublet" initials="C." surname="Hublet">
<organization />
</author>

<author fullname="P. De Schrijver" initials="P." surname="De Schrijver">
<organization />
</author>

<date year="2001" month="December" />
</front>

<seriesInfo value="3203" name="RFC" />
<format octets="11857" type="TXT" target="ftp://ftp.isi.edu/in-notes/rfc3203.txt" />
</reference>


<reference target2="reference.RFC.3204.xml" anchor="RFC3204">
<front>
<title>MIME media types for ISUP and QSIG Objects</title>
<author fullname="E. Zimmerer" initials="E." surname="Zimmerer">
<organization />
</author>

<author fullname="J. Peterson" initials="J." surname="Peterson">
<organization />
</author>

<author fullname="A. Vemuri" initials="A." surname="Vemuri">
<organization />
</author>

<author fullname="L. Ong" initials="L." surname="Ong">
<organization />
</author>

<author fullname="F. Audet" initials="F." surname="Audet">
<organization />
</author>

<author fullname="M. Watson" initials="M." surname="Watson">
<organization />
</author>

<author fullname="M. Zonoun" initials="M." surname="Zonoun">
<organization />
</author>

<date year="2001" month="December" />
</front>

<seriesInfo value="3204" name="RFC" />
<format octets="19712" type="TXT" target="ftp://ftp.isi.edu/in-notes/rfc3204.txt" />
</reference>


<reference target2="reference.RFC.3205.xml" anchor="RFC3205">
<front>
<title>On the use of HTTP as a Substrate</title>
<author fullname="K. Moore" initials="K." surname="Moore">
<organization />
</author>

<date year="2002" month="February" />
</front>

<seriesInfo value="56" name="BCP" />
<seriesInfo value="3205" name="RFC" />
<format octets="34785" type="TXT" target="ftp://ftp.isi.edu/in-notes/rfc3205.txt" />
</reference>


<reference target2="reference.RFC.3206.xml" anchor="RFC3206">
<front>
<title>The SYS and AUTH POP Response Codes</title>
<author fullname="R. Gellens" initials="R." surname="Gellens">
<organization />
</author>

<date year="2002" month="February" />
</front>

<seriesInfo value="3206" name="RFC" />
<format octets="9917" type="TXT" target="ftp://ftp.isi.edu/in-notes/rfc3206.txt" />
</reference>


<reference target2="reference.RFC.3207.xml" anchor="RFC3207">
<front>
<title>SMTP Service Extension for Secure SMTP over Transport Layer Security</title>
<author fullname="P. Hoffman" initials="P." surname="Hoffman">
<organization />
</author>

<date year="2002" month="February" />
</front>

<seriesInfo value="3207" name="RFC" />
<format octets="18679" type="TXT" target="ftp://ftp.isi.edu/in-notes/rfc3207.txt" />
</reference>


<reference target2="reference.RFC.3208.xml" anchor="RFC3208">
<front>
<title>PGM Reliable Transport Protocol Specification</title>
<author fullname="T. Speakman" initials="T." surname="Speakman">
<organization />
</author>

<author fullname="J. Crowcroft" initials="J." surname="Crowcroft">
<organization />
</author>

<author fullname="J. Gemmell" initials="J." surname="Gemmell">
<organization />
</author>

<author fullname="D. Farinacci" initials="D." surname="Farinacci">
<organization />
</author>

<author fullname="S. Lin" initials="S." surname="Lin">
<organization />
</author>

<author fullname="D. Leshchiner" initials="D." surname="Leshchiner">
<organization />
</author>

<author fullname="M. Luby" initials="M." surname="Luby">
<organization />
</author>

<author fullname="T. Montgomery" initials="T." surname="Montgomery">
<organization />
</author>

<author fullname="L. Rizzo" initials="L." surname="Rizzo">
<organization />
</author>

<author fullname="A. Tweedly" initials="A." surname="Tweedly">
<organization />
</author>

<author fullname="N. Bhaskar" initials="N." surname="Bhaskar">
<organization />
</author>

<author fullname="R. Edmonstone" initials="R." surname="Edmonstone">
<organization />
</author>

<author fullname="R. Sumanasekera" initials="R." surname="Sumanasekera">
<organization />
</author>

<author fullname="L. Vicisano" initials="L." surname="Vicisano">
<organization />
</author>

<date year="2001" month="December" />
</front>

<seriesInfo value="3208" name="RFC" />
<format octets="244637" type="TXT" target="ftp://ftp.isi.edu/in-notes/rfc3208.txt" />
</reference>


<reference target2="reference.RFC.3209.xml" anchor="RFC3209">
<front>
<title>RSVP-TE: Extensions to RSVP for LSP Tunnels</title>
<author fullname="D. Awduche" initials="D." surname="Awduche">
<organization />
</author>

<author fullname="L. Berger" initials="L." surname="Berger">
<organization />
</author>

<author fullname="D. Gan" initials="D." surname="Gan">
<organization />
</author>

<author fullname="T. Li" initials="T." surname="Li">
<organization />
</author>

<author fullname="V. Srinivasan" initials="V." surname="Srinivasan">
<organization />
</author>

<author fullname="G. Swallow" initials="G." surname="Swallow">
<organization />
</author>

<date year="2001" month="December" />
</front>

<seriesInfo value="3209" name="RFC" />
<format octets="132264" type="TXT" target="ftp://ftp.isi.edu/in-notes/rfc3209.txt" />
</reference>


<reference target2="reference.RFC.3210.xml" anchor="RFC3210">
<front>
<title>Applicability Statement for Extensions to RSVP for LSP-Tunnels</title>
<author fullname="D. Awduche" initials="D." surname="Awduche">
<organization />
</author>

<author fullname="A. Hannan" initials="A." surname="Hannan">
<organization />
</author>

<author fullname="X. Xiao" initials="X." surname="Xiao">
<organization />
</author>

<date year="2001" month="December" />
</front>

<seriesInfo value="3210" name="RFC" />
<format octets="17691" type="TXT" target="ftp://ftp.isi.edu/in-notes/rfc3210.txt" />
</reference>


<reference target2="reference.RFC.3211.xml" anchor="RFC3211">
<front>
<title>Password-based Encryption for CMS</title>
<author fullname="P. Gutmann" initials="P." surname="Gutmann">
<organization />
</author>

<date year="2001" month="December" />
</front>

<seriesInfo value="3211" name="RFC" />
<format octets="30527" type="TXT" target="ftp://ftp.isi.edu/in-notes/rfc3211.txt" />
</reference>


<reference target2="reference.RFC.3212.xml" anchor="RFC3212">
<front>
<title>Constraint-Based LSP Setup using LDP</title>
<author fullname="B. Jamoussi" initials="B." surname="Jamoussi">
<organization />
</author>

<author fullname="L. Andersson" initials="L." surname="Andersson">
<organization />
</author>

<author fullname="R. Callon" initials="R." surname="Callon">
<organization />
</author>

<author fullname="R. Dantu" initials="R." surname="Dantu">
<organization />
</author>

<author fullname="L. Wu" initials="L." surname="Wu">
<organization />
</author>

<author fullname="P. Doolan" initials="P." surname="Doolan">
<organization />
</author>

<author fullname="T. Worster" initials="T." surname="Worster">
<organization />
</author>

<author fullname="N. Feldman" initials="N." surname="Feldman">
<organization />
</author>

<author fullname="A. Fredette" initials="A." surname="Fredette">
<organization />
</author>

<author fullname="M. Girish" initials="M." surname="Girish">
<organization />
</author>

<author fullname="E. Gray" initials="E." surname="Gray">
<organization />
</author>

<author fullname="J. Heinanen" initials="J." surname="Heinanen">
<organization />
</author>

<author fullname="T. Kilty" initials="T." surname="Kilty">
<organization />
</author>

<author fullname="A. Malis" initials="A." surname="Malis">
<organization />
</author>

<date year="2002" month="January" />
</front>

<seriesInfo value="3212" name="RFC" />
<format octets="87591" type="TXT" target="ftp://ftp.isi.edu/in-notes/rfc3212.txt" />
</reference>


<reference target2="reference.RFC.3213.xml" anchor="RFC3213">
<front>
<title>Applicability Statement for CR-LDP</title>
<author fullname="J. Ash" initials="J." surname="Ash">
<organization />
</author>

<author fullname="M. Girish" initials="M." surname="Girish">
<organization />
</author>

<author fullname="E. Gray" initials="E." surname="Gray">
<organization />
</author>

<author fullname="B. Jamoussi" initials="B." surname="Jamoussi">
<organization />
</author>

<author fullname="G. Wright" initials="G." surname="Wright">
<organization />
</author>

<date year="2002" month="January" />
</front>

<seriesInfo value="3213" name="RFC" />
<format octets="14489" type="TXT" target="ftp://ftp.isi.edu/in-notes/rfc3213.txt" />
</reference>


<reference target2="reference.RFC.3214.xml" anchor="RFC3214">
<front>
<title>LSP Modification Using CR-LDP</title>
<author fullname="J. Ash" initials="J." surname="Ash">
<organization />
</author>

<author fullname="Y. Lee" initials="Y." surname="Lee">
<organization />
</author>

<author fullname="P. Ashwood-Smith" initials="P." surname="Ashwood-Smith">
<organization />
</author>

<author fullname="B. Jamoussi" initials="B." surname="Jamoussi">
<organization />
</author>

<author fullname="D. Fedyk" initials="D." surname="Fedyk">
<organization />
</author>

<author fullname="D. Skalecki" initials="D." surname="Skalecki">
<organization />
</author>

<author fullname="L. Li" initials="L." surname="Li">
<organization />
</author>

<date year="2002" month="January" />
</front>

<seriesInfo value="3214" name="RFC" />
<format octets="25453" type="TXT" target="ftp://ftp.isi.edu/in-notes/rfc3214.txt" />
</reference>


<reference target2="reference.RFC.3215.xml" anchor="RFC3215">
<front>
<title>LDP State Machine</title>
<author fullname="C. Boscher" initials="C." surname="Boscher">
<organization />
</author>

<author fullname="P. Cheval" initials="P." surname="Cheval">
<organization />
</author>

<author fullname="L. Wu" initials="L." surname="Wu">
<organization />
</author>

<author fullname="E. Gray" initials="E." surname="Gray">
<organization />
</author>

<date year="2002" month="January" />
</front>

<seriesInfo value="3215" name="RFC" />
<format octets="117278" type="TXT" target="ftp://ftp.isi.edu/in-notes/rfc3215.txt" />
</reference>


<reference target2="reference.RFC.3216.xml" anchor="RFC3216">
<front>
<title>SMIng Objectives</title>
<author fullname="C. Elliott" initials="C." surname="Elliott">
<organization />
</author>

<author fullname="D. Harrington" initials="D." surname="Harrington">
<organization />
</author>

<author fullname="J. Jason" initials="J." surname="Jason">
<organization />
</author>

<author fullname="J. Schoenwaelder" initials="J." surname="Schoenwaelder">
<organization />
</author>

<author fullname="F. Strauss" initials="F." surname="Strauss">
<organization />
</author>

<author fullname="W. Weiss" initials="W." surname="Weiss">
<organization />
</author>

<date year="2001" month="December" />
</front>

<seriesInfo value="3216" name="RFC" />
<format octets="58551" type="TXT" target="ftp://ftp.isi.edu/in-notes/rfc3216.txt" />
</reference>


<reference target2="reference.RFC.3217.xml" anchor="RFC3217">
<front>
<title>Triple-DES and RC2 Key Wrapping</title>
<author fullname="R. Housley" initials="R." surname="Housley">
<organization />
</author>

<date year="2001" month="December" />
</front>

<seriesInfo value="3217" name="RFC" />
<format octets="19855" type="TXT" target="ftp://ftp.isi.edu/in-notes/rfc3217.txt" />
</reference>


<reference target2="reference.RFC.3218.xml" anchor="RFC3218">
<front>
<title>Preventing the Million Message Attack on Cryptographic Message Syntax</title>
<author fullname="E. Rescorla" initials="E." surname="Rescorla">
<organization />
</author>

<date year="2002" month="January" />
</front>

<seriesInfo value="3218" name="RFC" />
<format octets="16047" type="TXT" target="ftp://ftp.isi.edu/in-notes/rfc3218.txt" />
</reference>


<reference target2="reference.RFC.3219.xml" anchor="RFC3219">
<front>
<title>Telephony Routing over IP (TRIP)</title>
<author fullname="J. Rosenberg" initials="J." surname="Rosenberg">
<organization />
</author>

<author fullname="H. Salama" initials="H." surname="Salama">
<organization />
</author>

<author fullname="M. Squire" initials="M." surname="Squire">
<organization />
</author>

<date year="2002" month="January" />
</front>

<seriesInfo value="3219" name="RFC" />
<format octets="184618" type="TXT" target="ftp://ftp.isi.edu/in-notes/rfc3219.txt" />
</reference>


<reference target2="reference.RFC.3220.xml" anchor="RFC3220">
<front>
<title>IP Mobility Support for IPv4</title>
<author fullname="C. Perkins" initials="C." surname="Perkins">
<organization />
</author>

<date year="2002" month="January" />
</front>

<seriesInfo value="3220" name="RFC" />
<format octets="238343" type="TXT" target="ftp://ftp.isi.edu/in-notes/rfc3220.txt" />
</reference>


<reference target2="reference.RFC.3221.xml" anchor="RFC3221">
<front>
<title>Commentary on Inter-Domain Routing in the Internet</title>
<author fullname="G. Huston" initials="G." surname="Huston">
<organization />
</author>

<date year="2001" month="December" />
</front>

<seriesInfo value="3221" name="RFC" />
<format octets="66580" type="TXT" target="ftp://ftp.isi.edu/in-notes/rfc3221.txt" />
</reference>


<reference target2="reference.RFC.3222.xml" anchor="RFC3222">
<front>
<title>Terminology for Forwarding Information Base (FIB) based Router Performance</title>
<author fullname="G. Trotter" initials="G." surname="Trotter">
<organization />
</author>

<date year="2001" month="December" />
</front>

<seriesInfo value="3222" name="RFC" />
<format octets="25483" type="TXT" target="ftp://ftp.isi.edu/in-notes/rfc3222.txt" />
</reference>


<reference target2="reference.RFC.3224.xml" anchor="RFC3224">
<front>
<title>Vendor Extensions for Service Location Protocol, Version 2</title>
<author fullname="E. Guttman" initials="E." surname="Guttman">
<organization />
</author>

<date year="2002" month="January" />
</front>

<seriesInfo value="3224" name="RFC" />
<format octets="19618" type="TXT" target="ftp://ftp.isi.edu/in-notes/rfc3224.txt" />
</reference>


<reference target2="reference.RFC.3225.xml" anchor="RFC3225">
<front>
<title>Indicating Resolver Support of DNSSEC</title>
<author fullname="D. Conrad" initials="D." surname="Conrad">
<organization />
</author>

<date year="2001" month="December" />
</front>

<seriesInfo value="3225" name="RFC" />
<format octets="11548" type="TXT" target="ftp://ftp.isi.edu/in-notes/rfc3225.txt" />
</reference>


<reference target2="reference.RFC.3226.xml" anchor="RFC3226">
<front>
<title>DNSSEC and IPv6 A6 aware server/resolver message size requirements</title>
<author fullname="O. Gudmundsson" initials="O." surname="Gudmundsson">
<organization />
</author>

<date year="2001" month="December" />
</front>

<seriesInfo value="3226" name="RFC" />
<format octets="12078" type="TXT" target="ftp://ftp.isi.edu/in-notes/rfc3226.txt" />
</reference>


<reference target2="reference.RFC.3227.xml" anchor="RFC3227">
<front>
<title>Guidelines for Evidence Collection and Archiving</title>
<author fullname="D. Brezinski" initials="D." surname="Brezinski">
<organization />
</author>

<author fullname="T. Killalea" initials="T." surname="Killalea">
<organization />
</author>

<date year="2002" month="February" />
</front>

<seriesInfo value="55" name="BCP" />
<seriesInfo value="3227" name="RFC" />
<format octets="18468" type="TXT" target="ftp://ftp.isi.edu/in-notes/rfc3227.txt" />
</reference>


<reference target2="reference.RFC.3228.xml" anchor="RFC3228">
<front>
<title>IANA Considerations for IPv4 Internet Group Management Protocol (IGMP)</title>
<author fullname="B. Fenner" initials="B." surname="Fenner">
<organization />
</author>

<date year="2002" month="February" />
</front>

<seriesInfo value="57" name="BCP" />
<seriesInfo value="3228" name="RFC" />
<format octets="6473" type="TXT" target="ftp://ftp.isi.edu/in-notes/rfc3228.txt" />
</reference>


<reference target2="reference.RFC.3229.xml" anchor="RFC3229">
<front>
<title>Delta encoding in HTTP</title>
<author fullname="J. Mogul" initials="J." surname="Mogul">
<organization />
</author>

<author fullname="B. Krishnamurthy" initials="B." surname="Krishnamurthy">
<organization />
</author>

<author fullname="F. Douglis" initials="F." surname="Douglis">
<organization />
</author>

<author fullname="A. Feldmann" initials="A." surname="Feldmann">
<organization />
</author>

<author fullname="Y. Goland" initials="Y." surname="Goland">
<organization />
</author>

<author fullname="A. van Hoff" initials="A." surname="van Hoff">
<organization />
</author>

<author fullname="D. Hellerstein" initials="D." surname="Hellerstein">
<organization />
</author>

<date year="2002" month="January" />
</front>

<seriesInfo value="3229" name="RFC" />
<format octets="111953" type="TXT" target="ftp://ftp.isi.edu/in-notes/rfc3229.txt" />
</reference>


<reference target2="reference.RFC.3230.xml" anchor="RFC3230">
<front>
<title>Instance Digests in HTTP</title>
<author fullname="J. Mogul" initials="J." surname="Mogul">
<organization />
</author>

<author fullname="A. Van Hoff" initials="A." surname="Van Hoff">
<organization />
</author>

<date year="2002" month="January" />
</front>

<seriesInfo value="3230" name="RFC" />
<format octets="26846" type="TXT" target="ftp://ftp.isi.edu/in-notes/rfc3230.txt" />
</reference>


<reference target2="reference.RFC.3231.xml" anchor="RFC3231">
<front>
<title>Definitions of Managed Objects for Scheduling Management Operations</title>
<author fullname="D. Levi" initials="D." surname="Levi">
<organization />
</author>

<author fullname="J. Schoenwaelder" initials="J." surname="Schoenwaelder">
<organization />
</author>

<date year="2002" month="January" />
</front>

<seriesInfo value="3231" name="RFC" />
<format octets="61308" type="TXT" target="ftp://ftp.isi.edu/in-notes/rfc3231.txt" />
</reference>


<reference target2="reference.RFC.3232.xml" anchor="RFC3232">
<front>
<title>Assigned Numbers: RFC 1700 is Replaced by an On-line Database</title>
<author fullname="J. Reynolds" initials="J." surname="Reynolds">
<organization />
</author>

<date year="2002" month="January" />
</front>

<seriesInfo value="3232" name="RFC" />
<format octets="3849" type="TXT" target="ftp://ftp.isi.edu/in-notes/rfc3232.txt" />
</reference>


<reference target2="reference.RFC.3233.xml" anchor="RFC3233">
<front>
<title>Defining the IETF</title>
<author fullname="P. Hoffman" initials="P." surname="Hoffman">
<organization />
</author>

<author fullname="S. Bradner" initials="S." surname="Bradner">
<organization />
</author>

<date year="2002" month="February" />
</front>

<seriesInfo value="58" name="BCP" />
<seriesInfo value="3233" name="RFC" />
<format octets="6401" type="TXT" target="ftp://ftp.isi.edu/in-notes/rfc3233.txt" />
</reference>


<reference target2="reference.RFC.3234.xml" anchor="RFC3234">
<front>
<title>Middleboxes: Taxonomy and Issues</title>
<author fullname="B. Carpenter" initials="B." surname="Carpenter">
<organization />
</author>

<author fullname="S. Brim" initials="S." surname="Brim">
<organization />
</author>

<date year="2002" month="February" />
</front>

<seriesInfo value="3234" name="RFC" />
<format octets="62329" type="TXT" target="ftp://ftp.isi.edu/in-notes/rfc3234.txt" />
</reference>


<reference target2="reference.RFC.3235.xml" anchor="RFC3235">
<front>
<title>Network Address Translator (NAT)-Friendly Application Design Guidelines</title>
<author fullname="D. Senie" initials="D." surname="Senie">
<organization />
</author>

<date year="2002" month="January" />
</front>

<seriesInfo value="3235" name="RFC" />
<format octets="29588" type="TXT" target="ftp://ftp.isi.edu/in-notes/rfc3235.txt" />
</reference>


<reference target2="reference.RFC.3236.xml" anchor="RFC3236">
<front>
<title>The 'application/xhtml+xml' Media Type</title>
<author fullname="M. Baker" initials="M." surname="Baker">
<organization />
</author>

<author fullname="P. Stark" initials="P." surname="Stark">
<organization />
</author>

<date year="2002" month="January" />
</front>

<seriesInfo value="3236" name="RFC" />
<format octets="16750" type="TXT" target="ftp://ftp.isi.edu/in-notes/rfc3236.txt" />
</reference>


<reference target2="reference.RFC.3237.xml" anchor="RFC3237">
<front>
<title>Requirements for Reliable Server Pooling</title>
<author fullname="M. Tuexen" initials="M." surname="Tuexen">
<organization />
</author>

<author fullname="Q. Xie" initials="Q." surname="Xie">
<organization />
</author>

<author fullname="R. Stewart" initials="R." surname="Stewart">
<organization />
</author>

<author fullname="M. Shore" initials="M." surname="Shore">
<organization />
</author>

<author fullname="L. Ong" initials="L." surname="Ong">
<organization />
</author>

<author fullname="J. Loughney" initials="J." surname="Loughney">
<organization />
</author>

<author fullname="M. Stillman" initials="M." surname="Stillman">
<organization />
</author>

<date year="2002" month="January" />
</front>

<seriesInfo value="3237" name="RFC" />
<format octets="16986" type="TXT" target="ftp://ftp.isi.edu/in-notes/rfc3237.txt" />
</reference>


<reference target2="reference.RFC.3238.xml" anchor="RFC3238">
<front>
<title>IAB Architectural and Policy Considerations for Open Pluggable Edge Services</title>
<author fullname="S. Floyd" initials="S." surname="Floyd">
<organization />
</author>

<author fullname="L. Daigle" initials="L." surname="Daigle">
<organization />
</author>

<date year="2002" month="January" />
</front>

<seriesInfo value="3238" name="RFC" />
<format octets="42336" type="TXT" target="ftp://ftp.isi.edu/in-notes/rfc3238.txt" />
</reference>


<reference target2="reference.RFC.3239.xml" anchor="RFC3239">
<front>
<title>Internet Printing Protocol (IPP): Requirements for Job, Printer, and Device Administrative Operations</title>
<author fullname="C. Kugler" initials="C." surname="Kugler">
<organization />
</author>

<author fullname="H. Lewis" initials="H." surname="Lewis">
<organization />
</author>

<author fullname="T. Hastings" initials="T." surname="Hastings">
<organization />
</author>

<date year="2002" month="February" />
</front>

<seriesInfo value="3239" name="RFC" />
<format octets="29532" type="TXT" target="ftp://ftp.isi.edu/in-notes/rfc3239.txt" />
</reference>


<reference target2="reference.RFC.3240.xml" anchor="RFC3240">
<front>
<title>Digital Imaging and Communications in Medicine (DICOM) - Application/dicom MIME Sub-type Registration</title>
<author fullname="D. Clunie" initials="D." surname="Clunie">
<organization />
</author>

<author fullname="E. Cordonnier" initials="E." surname="Cordonnier">
<organization />
</author>

<date year="2002" month="February" />
</front>

<seriesInfo value="3240" name="RFC" />
<format octets="9102" type="TXT" target="ftp://ftp.isi.edu/in-notes/rfc3240.txt" />
</reference>


<reference target2="reference.RFC.3241.xml" anchor="RFC3241">
<front>
<title>Robust Header Compression (ROHC) over PPP</title>
<author fullname="C. Bormann" initials="C." surname="Bormann">
<organization />
</author>

<date year="2002" month="April" />
</front>

<seriesInfo value="3241" name="RFC" />
<format octets="24424" type="TXT" target="ftp://ftp.isi.edu/in-notes/rfc3241.txt" />
</reference>


<reference target2="reference.RFC.3242.xml" anchor="RFC3242">
<front>
<title>RObust Header Compression (ROHC): A Link-Layer Assisted Profile for IP/UDP/RTP</title>
<author fullname="L-E. Jonsson" initials="L-E." surname="Jonsson">
<organization />
</author>

<author fullname="G. Pelletier" initials="G." surname="Pelletier">
<organization />
</author>

<date year="2002" month="April" />
</front>

<seriesInfo value="3242" name="RFC" />
<format octets="49007" type="TXT" target="ftp://ftp.isi.edu/in-notes/rfc3242.txt" />
</reference>


<reference target2="reference.RFC.3243.xml" anchor="RFC3243">
<front>
<title>RObust Header Compression (ROHC): Requirements and Assumptions for 0-byte IP/UDP/RTP Compression</title>
<author fullname="L-E. Jonsson" initials="L-E." surname="Jonsson">
<organization />
</author>

<date year="2002" month="April" />
</front>

<seriesInfo value="3243" name="RFC" />
<format octets="12451" type="TXT" target="ftp://ftp.isi.edu/in-notes/rfc3243.txt" />
</reference>


<reference target2="reference.RFC.3244.xml" anchor="RFC3244">
<front>
<title>Microsoft Windows 2000 Kerberos Change Password and Set Password Protocols</title>
<author fullname="M. Swift" initials="M." surname="Swift">
<organization />
</author>

<author fullname="J. Trostle" initials="J." surname="Trostle">
<organization />
</author>

<author fullname="J. Brezak" initials="J." surname="Brezak">
<organization />
</author>

<date year="2002" month="February" />
</front>

<seriesInfo value="3244" name="RFC" />
<format octets="13334" type="TXT" target="ftp://ftp.isi.edu/in-notes/rfc3244.txt" />
</reference>


<reference target2="reference.RFC.3245.xml" anchor="RFC3245">
<front>
<title>The History and Context of Telephone Number Mapping (ENUM) Operational Decisions: Informational Documents Contributed to ITU-T Study Group 2 (SG2)</title>
<author fullname="J. Klensin" initials="J." surname="Klensin">
<organization />
</author>

<author>
<organization>IAB</organization>
</author>

<date year="2002" month="March" />
</front>

<seriesInfo value="3245" name="RFC" />
<format octets="23758" type="TXT" target="ftp://ftp.isi.edu/in-notes/rfc3245.txt" />
</reference>


<reference target2="reference.RFC.3246.xml" anchor="RFC3246">
<front>
<title>An Expedited Forwarding PHB (Per-Hop Behavior)</title>
<author fullname="B. Davie" initials="B." surname="Davie">
<organization />
</author>

<author fullname="A. Charny" initials="A." surname="Charny">
<organization />
</author>

<author fullname="J.C.R. Bennet" initials="J.C.R." surname="Bennet">
<organization />
</author>

<author fullname="K. Benson" initials="K." surname="Benson">
<organization />
</author>

<author fullname="J.Y. Le Boudec" initials="J.Y." surname="Le Boudec">
<organization />
</author>

<author fullname="W. Courtney" initials="W." surname="Courtney">
<organization />
</author>

<author fullname="S. Davari" initials="S." surname="Davari">
<organization />
</author>

<author fullname="V. Firoiu" initials="V." surname="Firoiu">
<organization />
</author>

<author fullname="D. Stiliadis" initials="D." surname="Stiliadis">
<organization />
</author>

<date year="2002" month="March" />
</front>

<seriesInfo value="3246" name="RFC" />
<format octets="33896" type="TXT" target="ftp://ftp.isi.edu/in-notes/rfc3246.txt" />
</reference>


<reference target2="reference.RFC.3247.xml" anchor="RFC3247">
<front>
<title>Supplemental Information for the New Definition of the EF PHB (Expedited Forwarding Per-Hop Behavior)</title>
<author fullname="A. Charny" initials="A." surname="Charny">
<organization />
</author>

<author fullname="J. Bennet" initials="J." surname="Bennet">
<organization />
</author>

<author fullname="K. Benson" initials="K." surname="Benson">
<organization />
</author>

<author fullname="J. Boudec" initials="J." surname="Boudec">
<organization />
</author>

<author fullname="A. Chiu" initials="A." surname="Chiu">
<organization />
</author>

<author fullname="W. Courtney" initials="W." surname="Courtney">
<organization />
</author>

<author fullname="S. Davari" initials="S." surname="Davari">
<organization />
</author>

<author fullname="V. Firoiu" initials="V." surname="Firoiu">
<organization />
</author>

<author fullname="C. Kalmanek" initials="C." surname="Kalmanek">
<organization />
</author>

<author fullname="K. Ramakrishnan" initials="K." surname="Ramakrishnan">
<organization />
</author>

<date year="2002" month="March" />
</front>

<seriesInfo value="3247" name="RFC" />
<format octets="53786" type="TXT" target="ftp://ftp.isi.edu/in-notes/rfc3247.txt" />
</reference>


<reference target2="reference.RFC.3248.xml" anchor="RFC3248">
<front>
<title>A Delay Bound alternative revision of RFC 2598</title>
<author fullname="G. Armitage" initials="G." surname="Armitage">
<organization />
</author>

<author fullname="B. Carpenter" initials="B." surname="Carpenter">
<organization />
</author>

<author fullname="A. Casati" initials="A." surname="Casati">
<organization />
</author>

<author fullname="J. Crowcroft" initials="J." surname="Crowcroft">
<organization />
</author>

<author fullname="J. Halpern" initials="J." surname="Halpern">
<organization />
</author>

<author fullname="B. Kumar" initials="B." surname="Kumar">
<organization />
</author>

<author fullname="J. Schnizlein" initials="J." surname="Schnizlein">
<organization />
</author>

<date year="2002" month="March" />
</front>

<seriesInfo value="3248" name="RFC" />
<format octets="21597" type="TXT" target="ftp://ftp.isi.edu/in-notes/rfc3248.txt" />
</reference>


<reference target2="reference.RFC.3249.xml" anchor="RFC3249">
<front>
<title>Implementers Guide for Facsimile Using Internet Mail</title>
<author fullname="V. Cancio" initials="V." surname="Cancio">
<organization />
</author>

<author fullname="M. Moldovan" initials="M." surname="Moldovan">
<organization />
</author>

<author fullname="H. Tamura" initials="H." surname="Tamura">
<organization />
</author>

<author fullname="D. Wing" initials="D." surname="Wing">
<organization />
</author>

<date year="2002" month="September" />
</front>

<seriesInfo value="3249" name="RFC" />
<format octets="40413" type="TXT" target="ftp://ftp.isi.edu/in-notes/rfc3249.txt" />
</reference>


<reference target2="reference.RFC.3250.xml" anchor="RFC3250">
<front>
<title>Tag Image File Format Fax eXtended (TIFF-FX) - image/tiff-fx MIME Sub-type Registration</title>
<author fullname="L. McIntyre" initials="L." surname="McIntyre">
<organization />
</author>

<author fullname="G. Parsons" initials="G." surname="Parsons">
<organization />
</author>

<author fullname="J. Rafferty" initials="J." surname="Rafferty">
<organization />
</author>

<date year="2002" month="September" />
</front>

<seriesInfo value="3250" name="RFC" />
<format octets="17876" type="TXT" target="ftp://ftp.isi.edu/in-notes/rfc3250.txt" />
</reference>


<reference target2="reference.RFC.3251.xml" anchor="RFC3251">
<front>
<title>Electricity over IP</title>
<author fullname="B. Rajagopalan" initials="B." surname="Rajagopalan">
<organization />
</author>

<date year="2002" day="1" month="April" />
</front>

<seriesInfo value="3251" name="RFC" />
<format octets="18994" type="TXT" target="ftp://ftp.isi.edu/in-notes/rfc3251.txt" />
</reference>


<reference target2="reference.RFC.3252.xml" anchor="RFC3252">
<front>
<title>Binary Lexical Octet Ad-hoc Transport</title>
<author fullname="H. Kennedy" initials="H." surname="Kennedy">
<organization />
</author>

<date year="2002" day="1" month="April" />
</front>

<seriesInfo value="3252" name="RFC" />
<format octets="25962" type="TXT" target="ftp://ftp.isi.edu/in-notes/rfc3252.txt" />
</reference>


<reference target2="reference.RFC.3253.xml" anchor="RFC3253">
<front>
<title abbrev="WEBDAV">Versioning Extensions to WebDAV (Web Distributed Authoring and Versioning)</title>
<author fullname="Geoffrey Clemm" initials="G." surname="Clemm">
<organization>Rational Software</organization>

<address>
<postal>
<street>20 Maguire Road</street>
<city>Lexington</city>
<region>MA</region>
<code>02421</code>
<country>US</country>
</postal>

<email>geoffrey.clemm@rational.com</email>
</address>
</author>

<author fullname="Jim Amsden" initials="J." surname="Amsden">
<organization>IBM</organization>

<address>
<postal>
<street>3039 Cornwallis</street>
<street>Research Triangle Park</street>
<region>NC</region>
<code>27709</code>
<country>US</country>
</postal>

<email>jamsden@us.ibm.com</email>
</address>
</author>

<author fullname="Tim Ellison" initials="T." surname="Ellison">
<organization>IBM</organization>

<address>
<postal>
<street>Hursley Park</street>
<city>Winchester</city>
<code>S021 2JN</code>
<country>UK</country>
</postal>

<email>tim_ellison@uk.ibm.com</email>
</address>
</author>

<author fullname="Christopher Kaler" initials="C." surname="Kaler">
<organization>Microsoft</organization>

<address>
<postal>
<street>One Microsoft Way</street>
<city>Redmond</city>
<region>WA</region>
<code>90852</code>
<country>US</country>
</postal>

<email>ckaler@microsoft.com</email>
</address>
</author>

<author fullname="Jim Whitehead" initials="J." surname="Whitehead">
<organization abbrev="U.C. Santa Cruz">UC Santa Cruz, Dept. of Computer Science</organization>

<address>
<postal>
<street>1156 High Street</street>
<city>Santa Cruz</city>
<region>CA</region>
<code>95064</code>
<country>US</country>
</postal>

<email>ejw@cse.ucsc.edu</email>
</address>
</author>

<date year="2002" month="March" />

<abstract>
<t>
   This document specifies a set of methods, headers, and resource types
   that define the WebDAV (Web Distributed Authoring and Versioning)
   versioning extensions to the HTTP/1.1 protocol.  WebDAV versioning
   will minimize the complexity of clients that are capable of
   interoperating with a variety of versioning repository managers, to
   facilitate widespread deployment of applications capable of utilizing
   the WebDAV Versioning services.  WebDAV versioning includes automatic
   versioning for versioning-unaware clients, version history
   management, workspace management, baseline management, activity
   management, and URL namespace versioning.
</t>
</abstract>
</front>

<seriesInfo value="3253" name="RFC" />
<format octets="319610" type="HTML" target="http://xml.resource.org/public/rfc/html/rfc3253.html" />
<format octets="267729" type="XML" target="http://xml.resource.org/public/rfc/xml/rfc3253.xml" />
</reference>


<reference target2="reference.RFC.3254.xml" anchor="RFC3254">
<front>
<title>Definitions for talking about directories</title>
<author fullname="H. Alvestrand" initials="H." surname="Alvestrand">
<organization />
</author>

<date year="2002" month="April" />
</front>

<seriesInfo value="3254" name="RFC" />
<format octets="21541" type="TXT" target="ftp://ftp.isi.edu/in-notes/rfc3254.txt" />
</reference>


<reference target2="reference.RFC.3255.xml" anchor="RFC3255">
<front>
<title>Extending Point-to-Point Protocol (PPP) over Synchronous Optical NETwork/Synchronous Digital Hierarchy (SONET/SDH) with virtual concatenation, high order and low order payloads</title>
<author fullname="N. Jones" initials="N." surname="Jones">
<organization />
</author>

<author fullname="C. Murton" initials="C." surname="Murton">
<organization />
</author>

<date year="2002" month="April" />
</front>

<seriesInfo value="3255" name="RFC" />
<format octets="14192" type="TXT" target="ftp://ftp.isi.edu/in-notes/rfc3255.txt" />
</reference>


<reference target2="reference.RFC.3256.xml" anchor="RFC3256">
<front>
<title>The DOCSIS (Data-Over-Cable Service Interface Specifications) Device Class DHCP (Dynamic Host Configuration Protocol) Relay Agent Information Sub-option</title>
<author fullname="D. Jones" initials="D." surname="Jones">
<organization />
</author>

<author fullname="R. Woundy" initials="R." surname="Woundy">
<organization />
</author>

<date year="2002" month="April" />
</front>

<seriesInfo value="3256" name="RFC" />
<format octets="8551" type="TXT" target="ftp://ftp.isi.edu/in-notes/rfc3256.txt" />
</reference>


<reference target2="reference.RFC.3257.xml" anchor="RFC3257">
<front>
<title>Stream Control Transmission Protocol Applicability Statement</title>
<author fullname="L. Coene" initials="L." surname="Coene">
<organization />
</author>

<date year="2002" month="April" />
</front>

<seriesInfo value="3257" name="RFC" />
<format octets="24198" type="TXT" target="ftp://ftp.isi.edu/in-notes/rfc3257.txt" />
</reference>


<reference target2="reference.RFC.3258.xml" anchor="RFC3258">
<front>
<title>Distributing Authoritative Name Servers via Shared Unicast Addresses</title>
<author fullname="T. Hardie" initials="T." surname="Hardie">
<organization />
</author>

<date year="2002" month="April" />
</front>

<seriesInfo value="3258" name="RFC" />
<format octets="22195" type="TXT" target="ftp://ftp.isi.edu/in-notes/rfc3258.txt" />
</reference>


<reference target2="reference.RFC.3259.xml" anchor="RFC3259">
<front>
<title>A Message Bus for Local Coordination</title>
<author fullname="J. Ott" initials="J." surname="Ott">
<organization />
</author>

<author fullname="C. Perkins" initials="C." surname="Perkins">
<organization />
</author>

<author fullname="D. Kutscher" initials="D." surname="Kutscher">
<organization />
</author>

<date year="2002" month="April" />
</front>

<seriesInfo value="3259" name="RFC" />
<format octets="84125" type="TXT" target="ftp://ftp.isi.edu/in-notes/rfc3259.txt" />
</reference>


<reference target2="reference.RFC.3260.xml" anchor="RFC3260">
<front>
<title>New Terminology and Clarifications for Diffserv</title>
<author fullname="D. Grossman" initials="D." surname="Grossman">
<organization />
</author>

<date year="2002" month="April" />
</front>

<seriesInfo value="3260" name="RFC" />
<format octets="21900" type="TXT" target="ftp://ftp.isi.edu/in-notes/rfc3260.txt" />
</reference>


<reference target2="reference.RFC.3261.xml" anchor="RFC3261">
<front>
<title>SIP: Session Initiation Protocol</title>
<author fullname="J. Rosenberg" initials="J." surname="Rosenberg">
<organization />
</author>

<author fullname="H. Schulzrinne" initials="H." surname="Schulzrinne">
<organization />
</author>

<author fullname="G. Camarillo" initials="G." surname="Camarillo">
<organization />
</author>

<author fullname="A. Johnston" initials="A." surname="Johnston">
<organization />
</author>

<author fullname="J. Peterson" initials="J." surname="Peterson">
<organization />
</author>

<author fullname="R. Sparks" initials="R." surname="Sparks">
<organization />
</author>

<author fullname="M. Handley" initials="M." surname="Handley">
<organization />
</author>

<author fullname="E. Schooler" initials="E." surname="Schooler">
<organization />
</author>

<date year="2002" month="June" />
</front>

<seriesInfo value="3261" name="RFC" />
<format octets="647976" type="TXT" target="ftp://ftp.isi.edu/in-notes/rfc3261.txt" />
</reference>


<reference target2="reference.RFC.3262.xml" anchor="RFC3262">
<front>
<title>Reliability of Provisional Responses in Session Initiation Protocol (SIP)</title>
<author fullname="J. Rosenberg" initials="J." surname="Rosenberg">
<organization />
</author>

<author fullname="H. Schulzrinne" initials="H." surname="Schulzrinne">
<organization />
</author>

<date year="2002" month="June" />
</front>

<seriesInfo value="3262" name="RFC" />
<format octets="29643" type="TXT" target="ftp://ftp.isi.edu/in-notes/rfc3262.txt" />
</reference>


<reference target2="reference.RFC.3263.xml" anchor="RFC3263">
<front>
<title>Session Initiation Protocol (SIP): Locating SIP Servers</title>
<author fullname="J. Rosenberg" initials="J." surname="Rosenberg">
<organization />
</author>

<author fullname="H. Schulzrinne" initials="H." surname="Schulzrinne">
<organization />
</author>

<date year="2002" month="June" />
</front>

<seriesInfo value="3263" name="RFC" />
<format octets="42310" type="TXT" target="ftp://ftp.isi.edu/in-notes/rfc3263.txt" />
</reference>


<reference target2="reference.RFC.3264.xml" anchor="RFC3264">
<front>
<title>An Offer/Answer Model with Session Description Protocol (SDP)</title>
<author fullname="J. Rosenberg" initials="J." surname="Rosenberg">
<organization />
</author>

<author fullname="H. Schulzrinne" initials="H." surname="Schulzrinne">
<organization />
</author>

<date year="2002" month="June" />
</front>

<seriesInfo value="3264" name="RFC" />
<format octets="60854" type="TXT" target="ftp://ftp.isi.edu/in-notes/rfc3264.txt" />
</reference>


<reference target2="reference.RFC.3265.xml" anchor="RFC3265">
<front>
<title>Session Initiation Protocol (SIP)-Specific Event Notification</title>
<author fullname="A.B. Roach" initials="A.B." surname="Roach">
<organization />
</author>

<date year="2002" month="June" />
</front>

<seriesInfo value="3265" name="RFC" />
<format octets="89005" type="TXT" target="ftp://ftp.isi.edu/in-notes/rfc3265.txt" />
</reference>


<reference target2="reference.RFC.3266.xml" anchor="RFC3266">
<front>
<title>Support for IPv6 in Session Description Protocol (SDP)</title>
<author fullname="S. Olson" initials="S." surname="Olson">
<organization />
</author>

<author fullname="G. Camarillo" initials="G." surname="Camarillo">
<organization />
</author>

<author fullname="A.B. Roach" initials="A.B." surname="Roach">
<organization />
</author>

<date year="2002" month="June" />
</front>

<seriesInfo value="3266" name="RFC" />
<format octets="8693" type="TXT" target="ftp://ftp.isi.edu/in-notes/rfc3266.txt" />
</reference>


<reference target2="reference.RFC.3267.xml" anchor="RFC3267">
<front>
<title>Real-Time Transport Protocol (RTP) Payload Format and File Storage Format for the Adaptive Multi-Rate (AMR) and Adaptive Multi-Rate Wideband (AMR-WB) Audio Codecs</title>
<author fullname="J. Sjoberg" initials="J." surname="Sjoberg">
<organization />
</author>

<author fullname="M. Westerlund" initials="M." surname="Westerlund">
<organization />
</author>

<author fullname="A. Lakaniemi" initials="A." surname="Lakaniemi">
<organization />
</author>

<author fullname="Q. Xie" initials="Q." surname="Xie">
<organization />
</author>

<date year="2002" month="June" />
</front>

<seriesInfo value="3267" name="RFC" />
<format octets="110652" type="TXT" target="ftp://ftp.isi.edu/in-notes/rfc3267.txt" />
</reference>


<reference target2="reference.RFC.3268.xml" anchor="RFC3268">
<front>
<title>Advanced Encryption Standard (AES) Ciphersuites for Transport Layer Security (TLS)</title>
<author fullname="P. Chown" initials="P." surname="Chown">
<organization />
</author>

<date year="2002" month="June" />
</front>

<seriesInfo value="3268" name="RFC" />
<format octets="13530" type="TXT" target="ftp://ftp.isi.edu/in-notes/rfc3268.txt" />
</reference>


<reference target2="reference.RFC.3269.xml" anchor="RFC3269">
<front>
<title>Author Guidelines for Reliable Multicast Transport (RMT) Building Blocks and Protocol Instantiation documents</title>
<author fullname="R. Kermode" initials="R." surname="Kermode">
<organization />
</author>

<author fullname="L. Vicisano" initials="L." surname="Vicisano">
<organization />
</author>

<date year="2002" month="April" />
</front>

<seriesInfo value="3269" name="RFC" />
<format octets="25258" type="TXT" target="ftp://ftp.isi.edu/in-notes/rfc3269.txt" />
</reference>


<reference target2="reference.RFC.3270.xml" anchor="RFC3270">
<front>
<title>Multi-Protocol Label Switching (MPLS) Support of Differentiated Services</title>
<author fullname="F. Le Faucheur" initials="F." surname="Le Faucheur">
<organization />
</author>

<author fullname="L. Wu" initials="L." surname="Wu">
<organization />
</author>

<author fullname="B. Davie" initials="B." surname="Davie">
<organization />
</author>

<author fullname="S. Davari" initials="S." surname="Davari">
<organization />
</author>

<author fullname="P. Vaananen" initials="P." surname="Vaananen">
<organization />
</author>

<author fullname="R. Krishnan" initials="R." surname="Krishnan">
<organization />
</author>

<author fullname="P. Cheval" initials="P." surname="Cheval">
<organization />
</author>

<author fullname="J. Heinanen" initials="J." surname="Heinanen">
<organization />
</author>

<date year="2002" month="May" />
</front>

<seriesInfo value="3270" name="RFC" />
<format octets="137960" type="TXT" target="ftp://ftp.isi.edu/in-notes/rfc3270.txt" />
</reference>


<reference target2="reference.RFC.3271.xml" anchor="RFC3271">
<front>
<title>The Internet is for Everyone</title>
<author fullname="V. Cerf" initials="V." surname="Cerf">
<organization />
</author>

<date year="2002" month="April" />
</front>

<seriesInfo value="3271" name="RFC" />
<format octets="12345" type="TXT" target="ftp://ftp.isi.edu/in-notes/rfc3271.txt" />
</reference>


<reference target2="reference.RFC.3272.xml" anchor="RFC3272">
<front>
<title>Overview and Principles of Internet Traffic Engineering</title>
<author fullname="D. Awduche" initials="D." surname="Awduche">
<organization />
</author>

<author fullname="A. Chiu" initials="A." surname="Chiu">
<organization />
</author>

<author fullname="A. Elwalid" initials="A." surname="Elwalid">
<organization />
</author>

<author fullname="I. Widjaja" initials="I." surname="Widjaja">
<organization />
</author>

<author fullname="X. Xiao" initials="X." surname="Xiao">
<organization />
</author>

<date year="2002" month="May" />
</front>

<seriesInfo value="3272" name="RFC" />
<format octets="190384" type="TXT" target="ftp://ftp.isi.edu/in-notes/rfc3272.txt" />
</reference>


<reference target2="reference.RFC.3273.xml" anchor="RFC3273">
<front>
<title>Remote Network Monitoring Management Information Base for High Capacity Networks</title>
<author fullname="S. Waldbusser" initials="S." surname="Waldbusser">
<organization />
</author>

<date year="2002" month="July" />
</front>

<seriesInfo value="3273" name="RFC" />
<format octets="150924" type="TXT" target="ftp://ftp.isi.edu/in-notes/rfc3273.txt" />
</reference>


<reference target2="reference.RFC.3274.xml" anchor="RFC3274">
<front>
<title>Compressed Data Content Type for Cryptographic Message Syntax (CMS)</title>
<author fullname="P. Gutmann" initials="P." surname="Gutmann">
<organization />
</author>

<date year="2002" month="June" />
</front>

<seriesInfo value="3274" name="RFC" />
<format octets="11276" type="TXT" target="ftp://ftp.isi.edu/in-notes/rfc3274.txt" />
</reference>


<reference target2="reference.RFC.3275.xml" anchor="RFC3275">
<front>
<title>(Extensible Markup Language) XML-Signature Syntax and Processing</title>
<author fullname="D. Eastlake" initials="D." surname="Eastlake">
<organization />
</author>

<author fullname="J. Reagle" initials="J." surname="Reagle">
<organization />
</author>

<author fullname="D. Solo" initials="D." surname="Solo">
<organization />
</author>

<date year="2002" month="March" />
</front>

<seriesInfo value="3275" name="RFC" />
<format octets="164198" type="TXT" target="ftp://ftp.isi.edu/in-notes/rfc3275.txt" />
</reference>


<reference target2="reference.RFC.3276.xml" anchor="RFC3276">
<front>
<title>Definitions of Managed Objects for High Bit-Rate DSL - 2nd generation (HDSL2) and Single-Pair High-Speed Digital Subscriber Line (SHDSL) Lines Processing</title>
<author fullname="B. Ray" initials="B." surname="Ray">
<organization />
</author>

<author fullname="R. Abbi" initials="R." surname="Abbi">
<organization />
</author>

<date year="2002" month="May" />
</front>

<seriesInfo value="3276" name="RFC" />
<format octets="122991" type="TXT" target="ftp://ftp.isi.edu/in-notes/rfc3276.txt" />
</reference>


<reference target2="reference.RFC.3277.xml" anchor="RFC3277">
<front>
<title>Intermediate System to Intermediate System (IS-IS) Transient Blackhole Avoidance</title>
<author fullname="D. McPherson" initials="D." surname="McPherson">
<organization />
</author>

<date year="2002" month="April" />
</front>

<seriesInfo value="3277" name="RFC" />
<format octets="13077" type="TXT" target="ftp://ftp.isi.edu/in-notes/rfc3277.txt" />
</reference>


<reference target2="reference.RFC.3278.xml" anchor="RFC3278">
<front>
<title>Use of Elliptic Curve Cryptography (ECC) Algorithms in Cryptographic Message Syntax (CMS)</title>
<author fullname="S. Blake-Wilson" initials="S." surname="Blake-Wilson">
<organization />
</author>

<author fullname="D. Brown" initials="D." surname="Brown">
<organization />
</author>

<author fullname="P. Lambert" initials="P." surname="Lambert">
<organization />
</author>

<date year="2002" month="April" />
</front>

<seriesInfo value="3278" name="RFC" />
<format octets="33779" type="TXT" target="ftp://ftp.isi.edu/in-notes/rfc3278.txt" />
</reference>


<reference target2="reference.RFC.3279.xml" anchor="RFC3279">
<front>
<title>Algorithms and Identifiers for the Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile</title>
<author fullname="L. Bassham" initials="L." surname="Bassham">
<organization />
</author>

<author fullname="W. Polk" initials="W." surname="Polk">
<organization />
</author>

<author fullname="R. Housley" initials="R." surname="Housley">
<organization />
</author>

<date year="2002" month="April" />
</front>

<seriesInfo value="3279" name="RFC" />
<format octets="53833" type="TXT" target="ftp://ftp.isi.edu/in-notes/rfc3279.txt" />
</reference>


<reference target2="reference.RFC.3280.xml" anchor="RFC3280">
<front>
<title>Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile</title>
<author fullname="R. Housley" initials="R." surname="Housley">
<organization />
</author>

<author fullname="W. Polk" initials="W." surname="Polk">
<organization />
</author>

<author fullname="W. Ford" initials="W." surname="Ford">
<organization />
</author>

<author fullname="D. Solo" initials="D." surname="Solo">
<organization />
</author>

<date year="2002" month="April" />
</front>

<seriesInfo value="3280" name="RFC" />
<format octets="295556" type="TXT" target="ftp://ftp.isi.edu/in-notes/rfc3280.txt" />
</reference>


<reference target2="reference.RFC.3281.xml" anchor="RFC3281">
<front>
<title>An Internet Attribute Certificate Profile for Authorization</title>
<author fullname="S. Farrell" initials="S." surname="Farrell">
<organization />
</author>

<author fullname="R. Housley" initials="R." surname="Housley">
<organization />
</author>

<date year="2002" month="April" />
</front>

<seriesInfo value="3281" name="RFC" />
<format octets="90580" type="TXT" target="ftp://ftp.isi.edu/in-notes/rfc3281.txt" />
</reference>


<reference target2="reference.RFC.3282.xml" anchor="RFC3282">
<front>
<title>Content Language Headers</title>
<author fullname="H. Alvestrand" initials="H." surname="Alvestrand">
<organization />
</author>

<date year="2002" month="May" />
</front>

<seriesInfo value="3282" name="RFC" />
<format octets="14022" type="TXT" target="ftp://ftp.isi.edu/in-notes/rfc3282.txt" />
</reference>


<reference target2="reference.RFC.3283.xml" anchor="RFC3283">
<front>
<title>Guide to Internet Calendaring</title>
<author fullname="B. Mahoney" initials="B." surname="Mahoney">
<organization />
</author>

<author fullname="G. Babics" initials="G." surname="Babics">
<organization />
</author>

<author fullname="A. Taler" initials="A." surname="Taler">
<organization />
</author>

<date year="2002" month="June" />
</front>

<seriesInfo value="3283" name="RFC" />
<format octets="31768" type="TXT" target="ftp://ftp.isi.edu/in-notes/rfc3283.txt" />
</reference>


<reference target2="reference.RFC.3284.xml" anchor="RFC3284">
<front>
<title>The VCDIFF Generic Differencing and Compression Data Format</title>
<author fullname="D. Korn" initials="D." surname="Korn">
<organization />
</author>

<author fullname="J. MacDonald" initials="J." surname="MacDonald">
<organization />
</author>

<author fullname="J. Mogul" initials="J." surname="Mogul">
<organization />
</author>

<author fullname="K. Vo" initials="K." surname="Vo">
<organization />
</author>

<date year="2002" month="June" />
</front>

<seriesInfo value="3284" name="RFC" />
<format octets="64035" type="TXT" target="ftp://ftp.isi.edu/in-notes/rfc3284.txt" />
</reference>


<reference target2="reference.RFC.3285.xml" anchor="RFC3285">
<front>
<title>Using Microsoft Word to create Internet Drafts and RFCs</title>
<author fullname="M. Gahrns" initials="M." surname="Gahrns">
<organization />
</author>

<author fullname="T. Hain" initials="T." surname="Hain">
<organization />
</author>

<date year="2002" month="May" />
</front>

<seriesInfo value="3285" name="RFC" />
<format octets="34556" type="TXT" target="ftp://ftp.isi.edu/in-notes/rfc3285.txt" />
</reference>


<reference target2="reference.RFC.3286.xml" anchor="RFC3286">
<front>
<title>An Introduction to the Stream Control Transmission Protocol (SCTP)</title>
<author fullname="L. Ong" initials="L." surname="Ong">
<organization />
</author>

<author fullname="J. Yoakum" initials="J." surname="Yoakum">
<organization />
</author>

<date year="2002" month="May" />
</front>

<seriesInfo value="3286" name="RFC" />
<format octets="22644" type="TXT" target="ftp://ftp.isi.edu/in-notes/rfc3286.txt" />
</reference>


<reference target2="reference.RFC.3287.xml" anchor="RFC3287">
<front>
<title>Remote Monitoring MIB Extensions for Differentiated Services</title>
<author fullname="A. Bierman" initials="A." surname="Bierman">
<organization />
</author>

<date year="2002" month="July" />
</front>

<seriesInfo value="3287" name="RFC" />
<format octets="249622" type="TXT" target="ftp://ftp.isi.edu/in-notes/rfc3287.txt" />
</reference>


<reference target2="reference.RFC.3288.xml" anchor="RFC3288">
<front>
<title abbrev="Using SOAP in BEEP">Using the Simple Object Access Protocol (SOAP)
in Blocks Extensible Exchange Protocol (BEEP)</title>
<author fullname="Eamon O&apos;Tuathail" initials="E." surname="O&apos;Tuathail">
<organization>Clipcode.com</organization>

<address>
<postal>
<street>24 Thomastown Road</street>
<street>Dun Laoghaire</street>
<city></city>
<region>Dublin</region>
<code></code>
<country>IE</country>
</postal>

<phone>+353 1 2350 424</phone>
<email>eamon.otuathail@clipcode.com</email>
<uri>http://www.clipcode.com/</uri>
</address>
</author>

<author fullname="Marshall T. Rose" initials="M.T." surname="Rose">
<organization>Dover Beach Consulting, Inc.</organization>

<address>
<postal>
<street>POB 255268</street>
<city>Sacramento</city>
<region>CA</region>
<code>95865-5268</code>
<country>US</country>
</postal>

<phone>+1 916 483 8878</phone>
<email>mrose@dbc.mtview.ca.us</email>
</address>
</author>

<date year="2002" month="June" />
<area>Applications</area>
<keyword>BEEP</keyword>
<keyword>SOAP</keyword>

<abstract>
<t>This memo specifies a Simple Object Access Protocol (SOAP) binding to
the Blocks Extensible Exchange Protocol core (BEEP).
A SOAP binding describes how SOAP messages are transmitted in the network.</t>

<t>The SOAP is an XML-based (extensible markup language) messaging
protocol used to implement a wide variety of distributed messaging
models.
It defines a message format and describes a variety of
message patterns, including, but not limited to, RPC, asynchronous
event notification, unacknowledged messages, and forwarding via SOAP
intermediaries.</t>
</abstract>
</front>

<seriesInfo value="3288" name="RFC" />
<format octets="45721" type="HTML" target="http://xml.resource.org/public/rfc/html/rfc3288.html" />
<format octets="46681" type="XML" target="http://xml.resource.org/public/rfc/xml/rfc3288.xml" />
</reference>


<reference target2="reference.RFC.3289.xml" anchor="RFC3289">
<front>
<title>Management Information Base for the Differentiated Services Architecture</title>
<author fullname="F. Baker" initials="F." surname="Baker">
<organization />
</author>

<author fullname="K. Chan" initials="K." surname="Chan">
<organization />
</author>

<author fullname="A. Smith" initials="A." surname="Smith">
<organization />
</author>

<date year="2002" month="May" />
</front>

<seriesInfo value="3289" name="RFC" />
<format octets="239041" type="TXT" target="ftp://ftp.isi.edu/in-notes/rfc3289.txt" />
</reference>


<reference target2="reference.RFC.3290.xml" anchor="RFC3290">
<front>
<title>An Informal Management Model for Diffserv Routers</title>
<author fullname="Y. Bernet" initials="Y." surname="Bernet">
<organization />
</author>

<author fullname="S. Blake" initials="S." surname="Blake">
<organization />
</author>

<author fullname="D. Grossman" initials="D." surname="Grossman">
<organization />
</author>

<author fullname="A. Smith" initials="A." surname="Smith">
<organization />
</author>

<date year="2002" month="May" />
</front>

<seriesInfo value="3290" name="RFC" />
<format octets="129443" type="TXT" target="ftp://ftp.isi.edu/in-notes/rfc3290.txt" />
</reference>


<reference target2="reference.RFC.3291.xml" anchor="RFC3291">
<front>
<title>Textual Conventions for Internet Network Addresses</title>
<author fullname="M. Daniele" initials="M." surname="Daniele">
<organization />
</author>

<author fullname="B. Haberman" initials="B." surname="Haberman">
<organization />
</author>

<author fullname="S. Routhier" initials="S." surname="Routhier">
<organization />
</author>

<author fullname="J. Schoenwaelder" initials="J." surname="Schoenwaelder">
<organization />
</author>

<date year="2002" month="May" />
</front>

<seriesInfo value="3291" name="RFC" />
<format octets="43564" type="TXT" target="ftp://ftp.isi.edu/in-notes/rfc3291.txt" />
</reference>


<reference target2="reference.RFC.3292.xml" anchor="RFC3292">
<front>
<title>General Switch Management Protocol (GSMP) V3</title>
<author fullname="A. Doria" initials="A." surname="Doria">
<organization />
</author>

<author fullname="F. Hellstrand" initials="F." surname="Hellstrand">
<organization />
</author>

<author fullname="K. Sundell" initials="K." surname="Sundell">
<organization />
</author>

<author fullname="T. Worster" initials="T." surname="Worster">
<organization />
</author>

<date year="2002" month="June" />
</front>

<seriesInfo value="3292" name="RFC" />
<format octets="318983" type="TXT" target="ftp://ftp.isi.edu/in-notes/rfc3292.txt" />
</reference>


<reference target2="reference.RFC.3293.xml" anchor="RFC3293">
<front>
<title>General Switch Management Protocol (GSMP) Packet Encapsulations for Asynchronous Transfer Mode (ATM), Ethernet and Transmission Control Protocol (TCP)</title>
<author fullname="T. Worster" initials="T." surname="Worster">
<organization />
</author>

<author fullname="A. Doria" initials="A." surname="Doria">
<organization />
</author>

<author fullname="J. Buerkle" initials="J." surname="Buerkle">
<organization />
</author>

<date year="2002" month="June" />
</front>

<seriesInfo value="3293" name="RFC" />
<format octets="18206" type="TXT" target="ftp://ftp.isi.edu/in-notes/rfc3293.txt" />
</reference>


<reference target2="reference.RFC.3294.xml" anchor="RFC3294">
<front>
<title>General Switch Management Protocol (GSMP) Applicability</title>
<author fullname="A. Doria" initials="A." surname="Doria">
<organization />
</author>

<author fullname="K. Sundell" initials="K." surname="Sundell">
<organization />
</author>

<date year="2002" month="June" />
</front>

<seriesInfo value="3294" name="RFC" />
<format octets="18294" type="TXT" target="ftp://ftp.isi.edu/in-notes/rfc3294.txt" />
</reference>


<reference target2="reference.RFC.3295.xml" anchor="RFC3295">
<front>
<title>Definitions of Managed Objects for the General Switch Management Protocol (GSMP)</title>
<author fullname="H. Sjostrand" initials="H." surname="Sjostrand">
<organization />
</author>

<author fullname="J. Buerkle" initials="J." surname="Buerkle">
<organization />
</author>

<author fullname="B. Srinivasan" initials="B." surname="Srinivasan">
<organization />
</author>

<date year="2002" month="June" />
</front>

<seriesInfo value="3295" name="RFC" />
<format octets="95516" type="TXT" target="ftp://ftp.isi.edu/in-notes/rfc3295.txt" />
</reference>


<reference target2="reference.RFC.3296.xml" anchor="RFC3296">
<front>
<title>Named Subordinate References in Lightweight Directory Access Protocol (LDAP) Directories</title>
<author fullname="K. Zeilenga" initials="K." surname="Zeilenga">
<organization />
</author>

<date year="2002" month="July" />
</front>

<seriesInfo value="3296" name="RFC" />
<format octets="27389" type="TXT" target="ftp://ftp.isi.edu/in-notes/rfc3296.txt" />
</reference>


<reference target2="reference.RFC.3297.xml" anchor="RFC3297">
<front>
<title>Content Negotiation for Messaging Services based on Email</title>
<author fullname="G. Klyne" initials="G." surname="Klyne">
<organization />
</author>

<author fullname="R. Iwazaki" initials="R." surname="Iwazaki">
<organization />
</author>

<author fullname="D. Crocker" initials="D." surname="Crocker">
<organization />
</author>

<date year="2002" month="July" />
</front>

<seriesInfo value="3297" name="RFC" />
<format octets="97094" type="TXT" target="ftp://ftp.isi.edu/in-notes/rfc3297.txt" />
</reference>


<reference target2="reference.RFC.3298.xml" anchor="RFC3298">
<front>
<title>Service in the Public Switched Telephone Network/Intelligent Network (PSTN/IN) Requesting InTernet Service (SPIRITS) Protocol Requirements</title>
<author fullname="I. Faynberg" initials="I." surname="Faynberg">
<organization />
</author>

<author fullname="J. Gato" initials="J." surname="Gato">
<organization />
</author>

<author fullname="H. Lu" initials="H." surname="Lu">
<organization />
</author>

<author fullname="L. Slutsman" initials="L." surname="Slutsman">
<organization />
</author>

<date year="2002" month="August" />
</front>

<seriesInfo value="3298" name="RFC" />
<format octets="36560" type="TXT" target="ftp://ftp.isi.edu/in-notes/rfc3298.txt" />
</reference>


<reference target2="reference.RFC.3299.xml" anchor="RFC3299">
<front>
<title>Request for Comments Summary RFC Numbers 3200-3299</title>
<author fullname="S. Ginoza" initials="S." surname="Ginoza">
<organization />
</author>

<date year="2003" month="December" />
</front>

<seriesInfo value="3299" name="RFC" />
<format octets="63813" type="TXT" target="ftp://ftp.isi.edu/in-notes/rfc3299.txt" />
</reference>


<reference target2="reference.RFC.3300.xml" anchor="RFC3300">
<front>
<title>Internet Official Protocol Standards</title>
<author fullname="J. Reynolds" initials="J." surname="Reynolds">
<organization />
</author>

<author fullname="R. Braden" initials="R." surname="Braden">
<organization />
</author>

<author fullname="S. Ginoza" initials="S." surname="Ginoza">
<organization />
</author>

<author fullname="A. De La Cruz" initials="A." surname="De La Cruz">
<organization />
</author>

<date year="2002" month="November" />
</front>

<seriesInfo value="3300" name="RFC" />
<format octets="127805" type="TXT" target="ftp://ftp.isi.edu/in-notes/rfc3300.txt" />
</reference>


<reference target2="reference.RFC.3301.xml" anchor="RFC3301">
<front>
<title>Layer Two Tunnelling Protocol (L2TP): ATM access network extensions</title>
<author fullname="Y. T&apos;Joens" initials="Y." surname="T&apos;Joens">
<organization />
</author>

<author fullname="P. Crivellari" initials="P." surname="Crivellari">
<organization />
</author>

<author fullname="B. Sales" initials="B." surname="Sales">
<organization />
</author>

<date year="2002" month="June" />
</front>

<seriesInfo value="3301" name="RFC" />
<format octets="42756" type="TXT" target="ftp://ftp.isi.edu/in-notes/rfc3301.txt" />
</reference>


<reference target2="reference.RFC.3302.xml" anchor="RFC3302">
<front>
<title>Tag Image File Format (TIFF) - image/tiff MIME Sub-type Registration</title>
<author fullname="G. Parsons" initials="G." surname="Parsons">
<organization />
</author>

<author fullname="J. Rafferty" initials="J." surname="Rafferty">
<organization />
</author>

<date year="2002" month="September" />
</front>

<seriesInfo value="3302" name="RFC" />
<format octets="15183" type="TXT" target="ftp://ftp.isi.edu/in-notes/rfc3302.txt" />
</reference>


<reference target2="reference.RFC.3303.xml" anchor="RFC3303">
<front>
<title>Middlebox communication architecture and framework</title>
<author fullname="P. Srisuresh" initials="P." surname="Srisuresh">
<organization />
</author>

<author fullname="J. Kuthan" initials="J." surname="Kuthan">
<organization />
</author>

<author fullname="J. Rosenberg" initials="J." surname="Rosenberg">
<organization />
</author>

<author fullname="A. Molitor" initials="A." surname="Molitor">
<organization />
</author>

<author fullname="A. Rayhan" initials="A." surname="Rayhan">
<organization />
</author>

<date year="2002" month="August" />
</front>

<seriesInfo value="3303" name="RFC" />
<format octets="91209" type="TXT" target="ftp://ftp.isi.edu/in-notes/rfc3303.txt" />
</reference>


<reference target2="reference.RFC.3304.xml" anchor="RFC3304">
<front>
<title>Middlebox Communications (midcom) Protocol Requirements</title>
<author fullname="R.P. Swale" initials="R.P." surname="Swale">
<organization />
</author>

<author fullname="P.A. Mart" initials="P.A." surname="Mart">
<organization />
</author>

<author fullname="P. Sijben" initials="P." surname="Sijben">
<organization />
</author>

<author fullname="S. Brim" initials="S." surname="Brim">
<organization />
</author>

<author fullname="M. Shore" initials="M." surname="Shore">
<organization />
</author>

<date year="2002" month="August" />
</front>

<seriesInfo value="3304" name="RFC" />
<format octets="16187" type="TXT" target="ftp://ftp.isi.edu/in-notes/rfc3304.txt" />
</reference>


<reference target2="reference.RFC.3305.xml" anchor="RFC3305">
<front>
<title>Report from the Joint W3C/IETF URI Planning Interest Group: Uniform Resource Identifiers (URIs), URLs, and Uniform Resource Names (URNs): Clarifications and Recommendations</title>
<author fullname="M. Mealling" initials="M." surname="Mealling">
<organization />
</author>

<author fullname="R. Denenberg" initials="R." surname="Denenberg">
<organization />
</author>

<date year="2002" month="August" />
</front>

<seriesInfo value="3305" name="RFC" />
<format octets="21793" type="TXT" target="ftp://ftp.isi.edu/in-notes/rfc3305.txt" />
</reference>


<reference target2="reference.RFC.3306.xml" anchor="RFC3306">
<front>
<title>Unicast-Prefix-based IPv6 Multicast Addresses</title>
<author fullname="B. Haberman" initials="B." surname="Haberman">
<organization />
</author>

<author fullname="D. Thaler" initials="D." surname="Thaler">
<organization />
</author>

<date year="2002" month="August" />
</front>

<seriesInfo value="3306" name="RFC" />
<format octets="12713" type="TXT" target="ftp://ftp.isi.edu/in-notes/rfc3306.txt" />
</reference>


<reference target2="reference.RFC.3307.xml" anchor="RFC3307">
<front>
<title>Allocation Guidelines for IPv6 Multicast Addresses</title>
<author fullname="B. Haberman" initials="B." surname="Haberman">
<organization />
</author>

<date year="2002" month="August" />
</front>

<seriesInfo value="3307" name="RFC" />
<format octets="15742" type="TXT" target="ftp://ftp.isi.edu/in-notes/rfc3307.txt" />
</reference>


<reference target2="reference.RFC.3308.xml" anchor="RFC3308">
<front>
<title>Layer Two Tunneling Protocol (L2TP) Differentiated Services Extension</title>
<author fullname="P. Calhoun" initials="P." surname="Calhoun">
<organization />
</author>

<author fullname="W. Luo" initials="W." surname="Luo">
<organization />
</author>

<author fullname="D. McPherson" initials="D." surname="McPherson">
<organization />
</author>

<author fullname="K. Peirce" initials="K." surname="Peirce">
<organization />
</author>

<date year="2002" month="November" />
</front>

<seriesInfo value="3308" name="RFC" />
<format octets="21536" type="TXT" target="ftp://ftp.isi.edu/in-notes/rfc3308.txt" />
</reference>


<reference target2="reference.RFC.3309.xml" anchor="RFC3309">
<front>
<title>Stream Control Transmission Protocol (SCTP) Checksum Change</title>
<author fullname="J. Stone" initials="J." surname="Stone">
<organization />
</author>

<author fullname="R. Stewart" initials="R." surname="Stewart">
<organization />
</author>

<author fullname="D. Otis" initials="D." surname="Otis">
<organization />
</author>

<date year="2002" month="September" />
</front>

<seriesInfo value="3309" name="RFC" />
<format octets="34670" type="TXT" target="ftp://ftp.isi.edu/in-notes/rfc3309.txt" />
</reference>


<reference target2="reference.RFC.3310.xml" anchor="RFC3310">
<front>
<title>Hypertext Transfer Protocol (HTTP) Digest Authentication Using Authentication and Key Agreement (AKA)</title>
<author fullname="A. Niemi" initials="A." surname="Niemi">
<organization />
</author>

<author fullname="J. Arkko" initials="J." surname="Arkko">
<organization />
</author>

<author fullname="V. Torvinen" initials="V." surname="Torvinen">
<organization />
</author>

<date year="2002" month="September" />
</front>

<seriesInfo value="3310" name="RFC" />
<format octets="36985" type="TXT" target="ftp://ftp.isi.edu/in-notes/rfc3310.txt" />
</reference>


<reference target2="reference.RFC.3311.xml" anchor="RFC3311">
<front>
<title>The Session Initiation Protocol (SIP) UPDATE Method</title>
<author fullname="J. Rosenberg" initials="J." surname="Rosenberg">
<organization />
</author>

<date year="2002" month="October" />
</front>

<seriesInfo value="3311" name="RFC" />
<format octets="28125" type="TXT" target="ftp://ftp.isi.edu/in-notes/rfc3311.txt" />
</reference>


<reference target2="reference.RFC.3312.xml" anchor="RFC3312">
<front>
<title>Integration of Resource Management and Session Initiation Protocol (SIP)</title>
<author fullname="G. Camarillo" initials="G." surname="Camarillo">
<organization />
</author>

<author fullname="W. Marshall" initials="W." surname="Marshall">
<organization />
</author>

<author fullname="J. Rosenberg" initials="J." surname="Rosenberg">
<organization />
</author>

<date year="2002" month="October" />
</front>

<seriesInfo value="3312" name="RFC" />
<format octets="65757" type="TXT" target="ftp://ftp.isi.edu/in-notes/rfc3312.txt" />
</reference>


<reference target2="reference.RFC.3313.xml" anchor="RFC3313">
<front>
<title>Private Session Initiation Protocol (SIP) Extensions for Media Authorization</title>
<author fullname="W. Marshall" initials="W." surname="Marshall">
<organization />
</author>

<date year="2003" month="January" />
</front>

<seriesInfo value="3313" name="RFC" />
<format octets="36866" type="TXT" target="ftp://ftp.isi.edu/in-notes/rfc3313.txt" />
</reference>


<reference target2="reference.RFC.3314.xml" anchor="RFC3314">
<front>
<title>Recommendations for IPv6 in Third Generation Partnership Project (3GPP) Standards</title>
<author fullname="M. Wasserman" initials="M." surname="Wasserman">
<organization />
</author>

<date year="2002" month="September" />
</front>

<seriesInfo value="3314" name="RFC" />
<format octets="48168" type="TXT" target="ftp://ftp.isi.edu/in-notes/rfc3314.txt" />
</reference>


<reference target2="reference.RFC.3315.xml" anchor="RFC3315">
<front>
<title>Dynamic Host Configuration Protocol for IPv6 (DHCPv6)</title>
<author fullname="R. Droms" initials="R." surname="Droms">
<organization />
</author>

<author fullname="J. Bound" initials="J." surname="Bound">
<organization />
</author>

<author fullname="B. Volz" initials="B." surname="Volz">
<organization />
</author>

<author fullname="T. Lemon" initials="T." surname="Lemon">
<organization />
</author>

<author fullname="C. Perkins" initials="C." surname="Perkins">
<organization />
</author>

<author fullname="M. Carney" initials="M." surname="Carney">
<organization />
</author>

<date year="2003" month="July" />
</front>

<seriesInfo value="3315" name="RFC" />
<format octets="231402" type="TXT" target="ftp://ftp.isi.edu/in-notes/rfc3315.txt" />
</reference>


<reference target2="reference.RFC.3316.xml" anchor="RFC3316">
<front>
<title>Internet Protocol Version 6 (IPv6) for Some Second and Third Generation Cellular Hosts</title>
<author fullname="J. Arkko" initials="J." surname="Arkko">
<organization />
</author>

<author fullname="G. Kuijpers" initials="G." surname="Kuijpers">
<organization />
</author>

<author fullname="H. Soliman" initials="H." surname="Soliman">
<organization />
</author>

<author fullname="J. Loughney" initials="J." surname="Loughney">
<organization />
</author>

<author fullname="J. Wiljakka" initials="J." surname="Wiljakka">
<organization />
</author>

<date year="2003" month="April" />
</front>

<seriesInfo value="3316" name="RFC" />
<format octets="48741" type="TXT" target="ftp://ftp.isi.edu/in-notes/rfc3316.txt" />
</reference>


<reference target2="reference.RFC.3317.xml" anchor="RFC3317">
<front>
<title>Differentiated Services Quality of Service Policy Information Base</title>
<author fullname="K. Chan" initials="K." surname="Chan">
<organization />
</author>

<author fullname="R. Sahita" initials="R." surname="Sahita">
<organization />
</author>

<author fullname="S. Hahn" initials="S." surname="Hahn">
<organization />
</author>

<author fullname="K. McCloghrie" initials="K." surname="McCloghrie">
<organization />
</author>

<date year="2003" month="March" />
</front>

<seriesInfo value="3317" name="RFC" />
<format octets="188553" type="TXT" target="ftp://ftp.isi.edu/in-notes/rfc3317.txt" />
</reference>


<reference target2="reference.RFC.3318.xml" anchor="RFC3318">
<front>
<title>Framework Policy Information Base</title>
<author fullname="R. Sahita" initials="R." surname="Sahita">
<organization />
</author>

<author fullname="S. Hahn" initials="S." surname="Hahn">
<organization />
</author>

<author fullname="K. Chan" initials="K." surname="Chan">
<organization />
</author>

<author fullname="K. McCloghrie" initials="K." surname="McCloghrie">
<organization />
</author>

<date year="2003" month="March" />
</front>

<seriesInfo value="3318" name="RFC" />
<format octets="144530" type="TXT" target="ftp://ftp.isi.edu/in-notes/rfc3318.txt" />
</reference>


<reference target2="reference.RFC.3319.xml" anchor="RFC3319">
<front>
<title>Dynamic Host Configuration Protocol (DHCPv6) Options for Session Initiation Protocol (SIP) Servers</title>
<author fullname="H. Schulzrinne" initials="H." surname="Schulzrinne">
<organization />
</author>

<author fullname="B. Volz" initials="B." surname="Volz">
<organization />
</author>

<date year="2003" month="July" />
</front>

<seriesInfo value="3319" name="RFC" />
<format octets="14444" type="TXT" target="ftp://ftp.isi.edu/in-notes/rfc3319.txt" />
</reference>


<reference target2="reference.RFC.3320.xml" anchor="RFC3320">
<front>
<title>Signaling Compression (SigComp)</title>
<author fullname="R. Price" initials="R." surname="Price">
<organization />
</author>

<author fullname="C. Bormann" initials="C." surname="Bormann">
<organization />
</author>

<author fullname="J. Christoffersson" initials="J." surname="Christoffersson">
<organization />
</author>

<author fullname="H. Hannu" initials="H." surname="Hannu">
<organization />
</author>

<author fullname="Z. Liu" initials="Z." surname="Liu">
<organization />
</author>

<author fullname="J. Rosenberg" initials="J." surname="Rosenberg">
<organization />
</author>

<date year="2003" month="January" />
</front>

<seriesInfo value="3320" name="RFC" />
<format octets="137035" type="TXT" target="ftp://ftp.isi.edu/in-notes/rfc3320.txt" />
</reference>


<reference target2="reference.RFC.3321.xml" anchor="RFC3321">
<front>
<title>Signaling Compression (SigComp) - Extended Operations</title>
<author fullname="H. Hannu" initials="H." surname="Hannu">
<organization />
</author>

<author fullname="J. Christoffersson" initials="J." surname="Christoffersson">
<organization />
</author>

<author fullname="S. Forsgren" initials="S." surname="Forsgren">
<organization />
</author>

<author fullname="K.-C. Leung" initials="K.-C." surname="Leung">
<organization />
</author>

<author fullname="Z. Liu" initials="Z." surname="Liu">
<organization />
</author>

<author fullname="R. Price" initials="R." surname="Price">
<organization />
</author>

<date year="2003" month="January" />
</front>

<seriesInfo value="3321" name="RFC" />
<format octets="39433" type="TXT" target="ftp://ftp.isi.edu/in-notes/rfc3321.txt" />
</reference>


<reference target2="reference.RFC.3322.xml" anchor="RFC3322">
<front>
<title>Signaling Compression (SigComp) Requirements &amp; Assumptions</title>
<author fullname="H. Hannu" initials="H." surname="Hannu">
<organization />
</author>

<date year="2003" month="January" />
</front>

<seriesInfo value="3322" name="RFC" />
<format octets="27533" type="TXT" target="ftp://ftp.isi.edu/in-notes/rfc3322.txt" />
</reference>


<reference target2="reference.RFC.3323.xml" anchor="RFC3323">
<front>
<title>A Privacy Mechanism for the Session Initiation Protocol (SIP)</title>
<author fullname="J. Peterson" initials="J." surname="Peterson">
<organization />
</author>

<date year="2002" month="November" />
</front>

<seriesInfo value="3323" name="RFC" />
<format octets="54116" type="TXT" target="ftp://ftp.isi.edu/in-notes/rfc3323.txt" />
</reference>


<reference target2="reference.RFC.3324.xml" anchor="RFC3324">
<front>
<title>Short Term Requirements for Network Asserted Identity</title>
<author fullname="M. Watson" initials="M." surname="Watson">
<organization />
</author>

<date year="2002" month="November" />
</front>

<seriesInfo value="3324" name="RFC" />
<format octets="21964" type="TXT" target="ftp://ftp.isi.edu/in-notes/rfc3324.txt" />
</reference>


<reference target2="reference.RFC.3325.xml" anchor="RFC3325">
<front>
<title>Private Extensions to the Session Initiation Protocol (SIP) for Asserted Identity within Trusted Networks</title>
<author fullname="C. Jennings" initials="C." surname="Jennings">
<organization />
</author>

<author fullname="J. Peterson" initials="J." surname="Peterson">
<organization />
</author>

<author fullname="M. Watson" initials="M." surname="Watson">
<organization />
</author>

<date year="2002" month="November" />
</front>

<seriesInfo value="3325" name="RFC" />
<format octets="36170" type="TXT" target="ftp://ftp.isi.edu/in-notes/rfc3325.txt" />
</reference>


<reference target2="reference.RFC.3326.xml" anchor="RFC3326">
<front>
<title>The Reason Header Field for the Session Initiation Protocol (SIP)</title>
<author fullname="H. Schulzrinne" initials="H." surname="Schulzrinne">
<organization />
</author>

<author fullname="D. Oran" initials="D." surname="Oran">
<organization />
</author>

<author fullname="G. Camarillo" initials="G." surname="Camarillo">
<organization />
</author>

<date year="2002" month="December" />
</front>

<seriesInfo value="3326" name="RFC" />
<format octets="15695" type="TXT" target="ftp://ftp.isi.edu/in-notes/rfc3326.txt" />
</reference>


<reference target2="reference.RFC.3327.xml" anchor="RFC3327">
<front>
<title>Session Initiation Protocol (SIP) Extension Header Field for Registering Non-Adjacent Contacts</title>
<author fullname="D. Willis" initials="D." surname="Willis">
<organization />
</author>

<author fullname="B. Hoeneisen" initials="B." surname="Hoeneisen">
<organization />
</author>

<date year="2002" month="December" />
</front>

<seriesInfo value="3327" name="RFC" />
<format octets="36493" type="TXT" target="ftp://ftp.isi.edu/in-notes/rfc3327.txt" />
</reference>


<reference target2="reference.RFC.3329.xml" anchor="RFC3329">
<front>
<title>Security Mechanism Agreement for the Session Initiation Protocol (SIP)</title>
<author fullname="J. Arkko" initials="J." surname="Arkko">
<organization />
</author>

<author fullname="V. Torvinen" initials="V." surname="Torvinen">
<organization />
</author>

<author fullname="G. Camarillo" initials="G." surname="Camarillo">
<organization />
</author>

<author fullname="A. Niemi" initials="A." surname="Niemi">
<organization />
</author>

<author fullname="T. Haukka" initials="T." surname="Haukka">
<organization />
</author>

<date year="2003" month="January" />
</front>

<seriesInfo value="3329" name="RFC" />
<format octets="51503" type="TXT" target="ftp://ftp.isi.edu/in-notes/rfc3329.txt" />
</reference>


<reference target2="reference.RFC.3330.xml" anchor="RFC3330">
<front>
<title>Special-Use IPv4 Addresses</title>
<author>
<organization>IANA</organization>
</author>

<date year="2002" month="September" />
</front>

<seriesInfo value="3330" name="RFC" />
<format octets="16200" type="TXT" target="ftp://ftp.isi.edu/in-notes/rfc3330.txt" />
</reference>


<reference target2="reference.RFC.3331.xml" anchor="RFC3331">
<front>
<title>Signaling System 7 (SS7) Message Transfer Part 2 (MTP2) - User Adaptation Layer</title>
<author fullname="K. Morneault" initials="K." surname="Morneault">
<organization />
</author>

<author fullname="R. Dantu" initials="R." surname="Dantu">
<organization />
</author>

<author fullname="G. Sidebottom" initials="G." surname="Sidebottom">
<organization />
</author>

<author fullname="B. Bidulock" initials="B." surname="Bidulock">
<organization />
</author>

<author fullname="J. Heitz" initials="J." surname="Heitz">
<organization />
</author>

<date year="2002" month="September" />
</front>

<seriesInfo value="3331" name="RFC" />
<format octets="210807" type="TXT" target="ftp://ftp.isi.edu/in-notes/rfc3331.txt" />
</reference>


<reference target2="reference.RFC.3332.xml" anchor="RFC3332">
<front>
<title>Signaling System 7 (SS7) Message Transfer Part 3 (MTP3) - User Adaptation Layer (M3UA)</title>
<author fullname="G. Sidebottom" initials="G." surname="Sidebottom">
<organization />
</author>

<author fullname="K. Morneault" initials="K." surname="Morneault">
<organization />
</author>

<author fullname="J. Pastor-Balbas" initials="J." surname="Pastor-Balbas">
<organization />
</author>

<date year="2002" month="September" />
</front>

<seriesInfo value="3332" name="RFC" />
<format octets="265055" type="TXT" target="ftp://ftp.isi.edu/in-notes/rfc3332.txt" />
</reference>


<reference target2="reference.RFC.3334.xml" anchor="RFC3334">
<front>
<title>Policy-Based Accounting</title>
<author fullname="T. Zseby" initials="T." surname="Zseby">
<organization />
</author>

<author fullname="S. Zander" initials="S." surname="Zander">
<organization />
</author>

<author fullname="C. Carle" initials="C." surname="Carle">
<organization />
</author>

<date year="2002" month="October" />
</front>

<seriesInfo value="3334" name="RFC" />
<format octets="103014" type="TXT" target="ftp://ftp.isi.edu/in-notes/rfc3334.txt" />
</reference>


<reference target2="reference.RFC.3335.xml" anchor="RFC3335">
<front>
<title>MIME-based Secure Peer-to-Peer Business Data Interchange over the Internet</title>
<author fullname="T. Harding" initials="T." surname="Harding">
<organization />
</author>

<author fullname="R. Drummond" initials="R." surname="Drummond">
<organization />
</author>

<author fullname="C. Shih" initials="C." surname="Shih">
<organization />
</author>

<date year="2002" month="September" />
</front>

<seriesInfo value="3335" name="RFC" />
<format octets="59687" type="TXT" target="ftp://ftp.isi.edu/in-notes/rfc3335.txt" />
</reference>


<reference target2="reference.RFC.3336.xml" anchor="RFC3336">
<front>
<title>PPP Over Asynchronous Transfer Mode Adaptation Layer 2 (AAL2)</title>
<author fullname="B. Thompson" initials="B." surname="Thompson">
<organization />
</author>

<author fullname="T. Koren" initials="T." surname="Koren">
<organization />
</author>

<author fullname="B. Buffam" initials="B." surname="Buffam">
<organization />
</author>

<date year="2002" month="December" />
</front>

<seriesInfo value="3336" name="RFC" />
<format octets="33631" type="TXT" target="ftp://ftp.isi.edu/in-notes/rfc3336.txt" />
</reference>


<reference target2="reference.RFC.3337.xml" anchor="RFC3337">
<front>
<title>Class Extensions for PPP over Asynchronous Transfer Mode Adaptation Layer 2</title>
<author fullname="B. Thompson" initials="B." surname="Thompson">
<organization />
</author>

<author fullname="T. Koren" initials="T." surname="Koren">
<organization />
</author>

<author fullname="B. Buffam" initials="B." surname="Buffam">
<organization />
</author>

<date year="2002" month="December" />
</front>

<seriesInfo value="3337" name="RFC" />
<format octets="14911" type="TXT" target="ftp://ftp.isi.edu/in-notes/rfc3337.txt" />
</reference>


<reference target2="reference.RFC.3338.xml" anchor="RFC3338">
<front>
<title>Dual Stack Hosts Using "Bump-in-the-API" (BIA)</title>
<author fullname="S. Lee" initials="S." surname="Lee">
<organization />
</author>

<author fullname="M-K. Shin" initials="M-K." surname="Shin">
<organization />
</author>

<author fullname="Y-J. Kim" initials="Y-J." surname="Kim">
<organization />
</author>

<author fullname="E. Nordmark" initials="E." surname="Nordmark">
<organization />
</author>

<author fullname="A. Durand" initials="A." surname="Durand">
<organization />
</author>

<date year="2002" month="October" />
</front>

<seriesInfo value="3338" name="RFC" />
<format octets="34480" type="TXT" target="ftp://ftp.isi.edu/in-notes/rfc3338.txt" />
</reference>


<reference target2="reference.RFC.3339.xml" anchor="RFC3339">
<front>
<title>Date and Time on the Internet: Timestamps</title>
<author fullname="G. Klyne" initials="G." surname="Klyne">
<organization />
</author>

<author fullname="C. Newman" initials="C." surname="Newman">
<organization />
</author>

<date year="2002" month="July" />
</front>

<seriesInfo value="3339" name="RFC" />
<format octets="35064" type="TXT" target="ftp://ftp.isi.edu/in-notes/rfc3339.txt" />
</reference>


<reference target2="reference.RFC.3340.xml" anchor="RFC3340">
<front>
<title>The Application Exchange Core</title>
<author fullname="Marshall T. Rose" initials="M.T." surname="Rose">
<organization>Dover Beach Consulting, Inc.</organization>

<address>
<postal>
<street>POB 255268</street>
<city>Sacramento</city>
<region>CA</region>
<code>95865-5268</code>
<country>US</country>
</postal>

<phone>+1 916 483 8878</phone>
<email>mrose@dbc.mtview.ca.us</email>
</address>
</author>

<author fullname="Graham Klyne" initials="G." surname="Klyne">
<organization>Clearswift Corporation</organization>

<address>
<postal>
<street>1310 Waterside</street>
<street>Arlington Business Park</street>
<city>Theale</city>
<region>Reading</region>
<code>RG7 4SA</code>
<country>UK</country>
</postal>

<phone>+44 11 8903 8903</phone>
<email>Graham.Klyne@MIMEsweeper.com</email>
</address>
</author>

<author fullname="David H. Crocker" initials="D.H." surname="Crocker">
<organization>Brandenburg InternetWorking</organization>

<address>
<postal>
<street>675 Spruce Drive</street>
<city>Sunnyvale</city>
<region>CA</region>
<code>94086</code>
<country>US</country>
</postal>

<phone>+1 408 246 8253</phone>
<email>dcrocker@brandenburg.com</email>
<uri>http://www.brandenburg.com/</uri>
</address>
</author>

<date year="2002" month="July" />
<area>Applications</area>
<keyword>APEX</keyword>
<keyword>BEEP</keyword>
<keyword>messaging</keyword>

<abstract>
<t>This memo describes Application Exchange (APEX) Core,
an extensible,
asynchronous message relaying service for application layer
programs.</t>
</abstract>
</front>

<seriesInfo value="3340" name="RFC" />
<format octets="90648" type="HTML" target="http://xml.resource.org/public/rfc/html/rfc3340.html" />
<format octets="87808" type="XML" target="http://xml.resource.org/public/rfc/xml/rfc3340.xml" />
</reference>


<reference target2="reference.RFC.3341.xml" anchor="RFC3341">
<front>
<title>The Application Exchange (APEX) Access Service</title>
<author fullname="Marshall T. Rose" initials="M.T." surname="Rose">
<organization>Dover Beach Consulting, Inc.</organization>

<address>
<postal>
<street>POB 255268</street>
<city>Sacramento</city>
<region>CA</region>
<code>95865-5268</code>
<country>US</country>
</postal>

<phone>+1 916 483 8878</phone>
<email>mrose@dbc.mtview.ca.us</email>
</address>
</author>

<author fullname="Graham Klyne" initials="G." surname="Klyne">
<organization>Clearswift Corporation</organization>

<address>
<postal>
<street>1310 Waterside</street>
<street>Arlington Business Park</street>
<city>Theale</city>
<region>Reading</region>
<code>RG7 4SA</code>
<country>UK</country>
</postal>

<phone>+44 11 8903 8903</phone>
<email>Graham.Klyne@MIMEsweeper.com</email>
</address>
</author>

<author fullname="David H. Crocker" initials="D.H." surname="Crocker">
<organization>Brandenburg InternetWorking</organization>

<address>
<postal>
<street>675 Spruce Drive</street>
<city>Sunnyvale</city>
<region>CA</region>
<code>94086</code>
<country>US</country>
</postal>

<phone>+1 408 246 8253</phone>
<email>dcrocker@brandenburg.com</email>
<uri>http://www.brandenburg.com/</uri>
</address>
</author>

<date year="2002" month="July" />
<area>Applications</area>
<keyword>APEX</keyword>
<keyword>BEEP</keyword>
<keyword>messaging</keyword>
<keyword>access information</keyword>

<abstract>
<t>This memo describes the Application Exchange (APEX) access
service,
addressed as the well-known endpoint "apex=access".
The access service is used to control use of both the APEX
"relaying mesh" and other APEX services.</t>
</abstract>
</front>

<seriesInfo value="3341" name="RFC" />
<format octets="56404" type="HTML" target="http://xml.resource.org/public/rfc/html/rfc3341.html" />
<format octets="45214" type="XML" target="http://xml.resource.org/public/rfc/xml/rfc3341.xml" />
</reference>


<reference target2="reference.RFC.3342.xml" anchor="RFC3342">
<front>
<title abbrev="The Application Exchange (APEX) Party Pack">The Application Exchange (APEX) Option Party Pack, Part Deux!</title>
<author fullname="Graham Klyne" initials="G." surname="Klyne">
<organization>Clearswift Corporation</organization>

<address>
<postal>
<street>1310 Waterside</street>
<street>Arlington Business Park</street>
<city>Theale</city>
<region>Reading</region>
<code>RG7 4SA</code>
<country>UK</country>
</postal>

<phone>+44 11 8903 8903</phone>
<email>Graham.Klyne@MIMEsweeper.com</email>
</address>
</author>

<author fullname="Marshall T. Rose" initials="M.T." surname="Rose">
<organization>Dover Beach Consulting, Inc.</organization>

<address>
<postal>
<street>POB 255268</street>
<city>Sacramento</city>
<region>CA</region>
<code>95865-5268</code>
<country>US</country>
</postal>

<phone>+1 916 483 8878</phone>
<email>mrose@dbc.mtview.ca.us</email>
</address>
</author>

<author fullname="Michael F. Schwartz" initials="M.F." surname="Schwartz">
<organization>Code On The Road, LLC</organization>

<address>
<email>schwartz@CodeOnTheRoad.com</email>
<uri>http://www.CodeOnTheRoad.com</uri>
</address>
</author>

<author fullname="Eric Dixon" initials="E." surname="Dixon">
<organization />

<address>
<email>edixon@myrealbox.com</email>
</address>
</author>

<author fullname="Huston Franklin" initials="H." surname="Franklin">
<organization />

<address>
<email>huston@franklin.ro</email>
</address>
</author>

<author fullname="Jay Kint" initials="J." surname="Kint">
<organization />

<address>
<email>d20@icosahedron.org</email>
</address>
</author>

<author fullname="Darren New" initials="D." surname="New">
<organization />

<address>
<postal>
<street>5390 Caminito Exquisito</street>
<city>San Diego</city>
<region>CA</region>
<code>92130</code>
<country>US</country>
</postal>

<phone>+1 858 350 9733</phone>
<email>dnew@san.rr.com</email>
</address>
</author>

<author fullname="Scott Pead" initials="S." surname="Pead">
<organization />

<address>
<email>spead@fiber.net</email>
</address>
</author>

<date year="2002" month="July" />
<area>Applications</area>
<keyword>APEX</keyword>
<keyword>BEEP</keyword>
<keyword>messaging</keyword>

<abstract>
<t>Application Exchange (APEX),
at its core, provides a best-effort application-layer datagram service.
Options are used to alter the semantics of the core service.
This memo defines various options to change the default behavior of
APEX's "relaying mesh".</t>
</abstract>
</front>

<seriesInfo value="3342" name="RFC" />
<format octets="47846" type="HTML" target="http://xml.resource.org/public/rfc/html/rfc3342.html" />
<format octets="34399" type="XML" target="http://xml.resource.org/public/rfc/xml/rfc3342.xml" />
</reference>


<reference target2="reference.RFC.3343.xml" anchor="RFC3343">
<front>
<title>The Application Exchange (APEX) Presence Service</title>
<author fullname="M. Rose" initials="M." surname="Rose">
<organization />
</author>

<author fullname="G. Klyne" initials="G." surname="Klyne">
<organization />
</author>

<author fullname="D. Crocker" initials="D." surname="Crocker">
<organization />
</author>

<date year="2003" month="April" />
</front>

<seriesInfo value="3343" name="RFC" />
<format octets="42043" type="TXT" target="ftp://ftp.isi.edu/in-notes/rfc3343.txt" />
</reference>


<reference target2="reference.RFC.3344.xml" anchor="RFC3344">
<front>
<title>IP Mobility Support for IPv4</title>
<author fullname="C. Perkins" initials="C." surname="Perkins">
<organization />
</author>

<date year="2002" month="August" />
</front>

<seriesInfo value="3344" name="RFC" />
<format octets="241041" type="TXT" target="ftp://ftp.isi.edu/in-notes/rfc3344.txt" />
</reference>


<reference target2="reference.RFC.3345.xml" anchor="RFC3345">
<front>
<title>Border Gateway Protocol (BGP) Persistent Route Oscillation Condition</title>
<author fullname="D. McPherson" initials="D." surname="McPherson">
<organization />
</author>

<author fullname="V. Gill" initials="V." surname="Gill">
<organization />
</author>

<author fullname="D. Walton" initials="D." surname="Walton">
<organization />
</author>

<author fullname="A. Retana" initials="A." surname="Retana">
<organization />
</author>

<date year="2002" month="August" />
</front>

<seriesInfo value="3345" name="RFC" />
<format octets="38137" type="TXT" target="ftp://ftp.isi.edu/in-notes/rfc3345.txt" />
</reference>


<reference target2="reference.RFC.3346.xml" anchor="RFC3346">
<front>
<title>Applicability Statement for Traffic Engineering with MPLS</title>
<author fullname="J. Boyle" initials="J." surname="Boyle">
<organization />
</author>

<author fullname="V. Gill" initials="V." surname="Gill">
<organization />
</author>

<author fullname="A. Hannan" initials="A." surname="Hannan">
<organization />
</author>

<author fullname="D. Cooper" initials="D." surname="Cooper">
<organization />
</author>

<author fullname="D. Awduche" initials="D." surname="Awduche">
<organization />
</author>

<author fullname="B. Christian" initials="B." surname="Christian">
<organization />
</author>

<author fullname="W.S. Lai" initials="W.S." surname="Lai">
<organization />
</author>

<date year="2002" month="August" />
</front>

<seriesInfo value="3346" name="RFC" />
<format octets="33754" type="TXT" target="ftp://ftp.isi.edu/in-notes/rfc3346.txt" />
</reference>


<reference target2="reference.RFC.3347.xml" anchor="RFC3347">
<front>
<title>Small Computer Systems Interface protocol over the Internet (iSCSI) Requirements and Design Considerations</title>
<author fullname="M. Krueger" initials="M." surname="Krueger">
<organization />
</author>

<author fullname="R. Haagens" initials="R." surname="Haagens">
<organization />
</author>

<date year="2002" month="July" />
</front>

<seriesInfo value="3347" name="RFC" />
<format octets="58097" type="TXT" target="ftp://ftp.isi.edu/in-notes/rfc3347.txt" />
</reference>


<reference target2="reference.RFC.3348.xml" anchor="RFC3348">
<front>
<title>The Internet Message Action Protocol (IMAP4) Child Mailbox Extension</title>
<author fullname="M. Gahrns" initials="M." surname="Gahrns">
<organization />
</author>

<author fullname="R. Cheng" initials="R." surname="Cheng">
<organization />
</author>

<date year="2002" month="July" />
</front>

<seriesInfo value="3348" name="RFC" />
<format octets="11868" type="TXT" target="ftp://ftp.isi.edu/in-notes/rfc3348.txt" />
</reference>


<reference target2="reference.RFC.3349.xml" anchor="RFC3349">
<front>
<title abbrev="Transient IDs for BEEP Profiles">A Transient Prefix
for Identifying Profiles under Development by the Working Groups of
the Internet Engineering Task Force</title>
<author fullname="Marshall T. Rose" initials="M.T." surname="Rose">
<organization>Dover Beach Consulting, Inc.</organization>

<address>
<postal>
<street>POB 255268</street>
<city>Sacramento</city>
<region>CA</region>
<code>95865-5268</code>
<country>US</country>
</postal>

<phone>+1 916 483 8878</phone>
<email>mrose@dbc.mtview.ca.us</email>
</address>
</author>

<date year="2002" month="July" />

<abstract>
<t>As a part of their deliverables,
working groups of the IETF may develop BEEP profiles.
During the development process,
it is desirable to assign a transient identifier to each profile.
If the profile is subsequently published as an RFC,
then a permanent identifier is subsequently assigned by the
IANA.</t>
</abstract>
</front>

<seriesInfo value="59" name="BCP" />
<seriesInfo value="3349" name="RFC" />
<format octets="16490" type="HTML" target="http://xml.resource.org/public/rfc/html/rfc3349.html" />
<format octets="10880" type="XML" target="http://xml.resource.org/public/rfc/xml/rfc3349.xml" />
</reference>


<reference target2="reference.RFC.3351.xml" anchor="RFC3351">
<front>
<title>User Requirements for the Session Initiation Protocol (SIP) in Support of Deaf, Hard of Hearing and Speech-impaired Individuals</title>
<author fullname="N. Charlton" initials="N." surname="Charlton">
<organization />
</author>

<author fullname="M. Gasson" initials="M." surname="Gasson">
<organization />
</author>

<author fullname="G. Gybels" initials="G." surname="Gybels">
<organization />
</author>

<author fullname="M. Spanner" initials="M." surname="Spanner">
<organization />
</author>

<author fullname="A. van Wijk" initials="A." surname="van Wijk">
<organization />
</author>

<date year="2002" month="August" />
</front>

<seriesInfo value="3351" name="RFC" />
<format octets="33894" type="TXT" target="ftp://ftp.isi.edu/in-notes/rfc3351.txt" />
</reference>


<reference target2="reference.RFC.3352.xml" anchor="RFC3352">
<front>
<title>Connection-less Lightweight Directory Access Protocol (CLDAP) to Historic Status</title>
<author fullname="K. Zeilenga" initials="K." surname="Zeilenga">
<organization />
</author>

<date year="2003" month="March" />
</front>

<seriesInfo value="3352" name="RFC" />
<format octets="7265" type="TXT" target="ftp://ftp.isi.edu/in-notes/rfc3352.txt" />
</reference>


<reference target2="reference.RFC.3353.xml" anchor="RFC3353">
<front>
<title>Overview of IP Multicast in a Multi-Protocol Label Switching (MPLS) Environment</title>
<author fullname="D. Ooms" initials="D." surname="Ooms">
<organization />
</author>

<author fullname="B. Sales" initials="B." surname="Sales">
<organization />
</author>

<author fullname="W. Livens" initials="W." surname="Livens">
<organization />
</author>

<author fullname="A. Acharya" initials="A." surname="Acharya">
<organization />
</author>

<author fullname="F. Griffoul" initials="F." surname="Griffoul">
<organization />
</author>

<author fullname="F. Ansari" initials="F." surname="Ansari">
<organization />
</author>

<date year="2002" month="August" />
</front>

<seriesInfo value="3353" name="RFC" />
<format octets="65860" type="TXT" target="ftp://ftp.isi.edu/in-notes/rfc3353.txt" />
</reference>


<reference target2="reference.RFC.3354.xml" anchor="RFC3354">
<front>
<title>Internet Open Trading Protocol Version 2 Requirements</title>
<author fullname="D. Eastlake" initials="D." surname="Eastlake">
<organization />
</author>

<date year="2002" month="August" />
</front>

<seriesInfo value="3354" name="RFC" />
<format octets="9671" type="TXT" target="ftp://ftp.isi.edu/in-notes/rfc3354.txt" />
</reference>


<reference target2="reference.RFC.3355.xml" anchor="RFC3355">
<front>
<title>Layer Two Tunnelling Protocol (L2TP) Over ATM Adaptation Layer 5 (AAL5)</title>
<author fullname="A. Singh" initials="A." surname="Singh">
<organization />
</author>

<author fullname="R. Turner" initials="R." surname="Turner">
<organization />
</author>

<author fullname="R. Tio" initials="R." surname="Tio">
<organization />
</author>

<author fullname="S. Nanji" initials="S." surname="Nanji">
<organization />
</author>

<date year="2002" month="August" />
</front>

<seriesInfo value="3355" name="RFC" />
<format octets="25114" type="TXT" target="ftp://ftp.isi.edu/in-notes/rfc3355.txt" />
</reference>


<reference target2="reference.RFC.3356.xml" anchor="RFC3356">
<front>
<title>Internet Engineering Task Force and International Telecommunication Union - Telecommunications Standardization Sector Collaboration Guidelines</title>
<author fullname="G. Fishman" initials="G." surname="Fishman">
<organization />
</author>

<author fullname="S. Bradner" initials="S." surname="Bradner">
<organization />
</author>

<date year="2002" month="August" />
</front>

<seriesInfo value="3356" name="RFC" />
<format octets="27149" type="TXT" target="ftp://ftp.isi.edu/in-notes/rfc3356.txt" />
</reference>


<reference target2="reference.RFC.3357.xml" anchor="RFC3357">
<front>
<title>One-way Loss Pattern Sample Metrics</title>
<author fullname="R. Koodli" initials="R." surname="Koodli">
<organization />
</author>

<author fullname="R. Ravikanth" initials="R." surname="Ravikanth">
<organization />
</author>

<date year="2002" month="August" />
</front>

<seriesInfo value="3357" name="RFC" />
<format octets="30570" type="TXT" target="ftp://ftp.isi.edu/in-notes/rfc3357.txt" />
</reference>


<reference target2="reference.RFC.3358.xml" anchor="RFC3358">
<front>
<title>Optional Checksums in Intermediate System to Intermediate System (ISIS)</title>
<author fullname="R. Koodli" initials="R." surname="Koodli">
<organization />
</author>

<author fullname="R. Ravikanth" initials="R." surname="Ravikanth">
<organization />
</author>

<date year="2002" month="August" />
</front>

<seriesInfo value="3358" name="RFC" />
<format octets="8266" type="TXT" target="ftp://ftp.isi.edu/in-notes/rfc3358.txt" />
</reference>


<reference target2="reference.RFC.3359.xml" anchor="RFC3359">
<front>
<title>Reserved Type, Length and Value (TLV) Codepoints in Intermediate System to Intermediate System</title>
<author fullname="T. Przygienda" initials="T." surname="Przygienda">
<organization />
</author>

<date year="2002" month="August" />
</front>

<seriesInfo value="3359" name="RFC" />
<format octets="7843" type="TXT" target="ftp://ftp.isi.edu/in-notes/rfc3359.txt" />
</reference>


<reference target2="reference.RFC.3360.xml" anchor="RFC3360">
<front>
<title>Inappropriate TCP Resets Considered Harmful</title>
<author fullname="S. Floyd" initials="S." surname="Floyd">
<organization />
</author>

<date year="2002" month="August" />
</front>

<seriesInfo value="60" name="BCP" />
<seriesInfo value="3360" name="RFC" />
<format octets="46748" type="TXT" target="ftp://ftp.isi.edu/in-notes/rfc3360.txt" />
</reference>


<reference target2="reference.RFC.3361.xml" anchor="RFC3361">
<front>
<title>Dynamic Host Configuration Protocol (DHCP-for-IPv4) Option for Session Initiation Protocol (SIP) Servers</title>
<author fullname="H. Schulzrinne" initials="H." surname="Schulzrinne">
<organization />
</author>

<date year="2002" month="August" />
</front>

<seriesInfo value="3361" name="RFC" />
<format octets="12549" type="TXT" target="ftp://ftp.isi.edu/in-notes/rfc3361.txt" />
</reference>


<reference target2="reference.RFC.3362.xml" anchor="RFC3362">
<front>
<title>Real-time Facsimile (T.38) - image/t38 MIME Sub-type Registration</title>
<author fullname="G. Parsons" initials="G." surname="Parsons">
<organization />
</author>

<date year="2002" month="August" />
</front>

<seriesInfo value="3362" name="RFC" />
<format octets="8301" type="TXT" target="ftp://ftp.isi.edu/in-notes/rfc3362.txt" />
</reference>


<reference target2="reference.RFC.3363.xml" anchor="RFC3363">
<front>
<title>Representing Internet Protocol version 6 (IPv6) Addresses in the Domain Name System (DNS)</title>
<author fullname="R. Bush" initials="R." surname="Bush">
<organization />
</author>

<author fullname="A. Durand" initials="A." surname="Durand">
<organization />
</author>

<author fullname="B. Fink" initials="B." surname="Fink">
<organization />
</author>

<author fullname="O. Gudmundsson" initials="O." surname="Gudmundsson">
<organization />
</author>

<author fullname="T. Hain" initials="T." surname="Hain">
<organization />
</author>

<date year="2002" month="August" />
</front>

<seriesInfo value="3363" name="RFC" />
<format octets="11055" type="TXT" target="ftp://ftp.isi.edu/in-notes/rfc3363.txt" />
</reference>


<reference target2="reference.RFC.3364.xml" anchor="RFC3364">
<front>
<title>Tradeoffs in Domain Name System (DNS) Support for Internet Protocol version 6 (IPv6)</title>
<author fullname="R. Austein" initials="R." surname="Austein">
<organization />
</author>

<date year="2002" month="August" />
</front>

<seriesInfo value="3364" name="RFC" />
<format octets="26544" type="TXT" target="ftp://ftp.isi.edu/in-notes/rfc3364.txt" />
</reference>


<reference target2="reference.RFC.3365.xml" anchor="RFC3365">
<front>
<title>Strong Security Requirements for Internet Engineering Task Force Standard Protocols</title>
<author fullname="J. Schiller" initials="J." surname="Schiller">
<organization />
</author>

<date year="2002" month="August" />
</front>

<seriesInfo value="61" name="BCP" />
<seriesInfo value="3365" name="RFC" />
<format octets="16411" type="TXT" target="ftp://ftp.isi.edu/in-notes/rfc3365.txt" />
</reference>


<reference target2="reference.RFC.3366.xml" anchor="RFC3366">
<front>
<title>Advice to link designers on link Automatic Repeat reQuest (ARQ)</title>
<author fullname="G. Fairhurst" initials="G." surname="Fairhurst">
<organization />
</author>

<author fullname="L. Wood" initials="L." surname="Wood">
<organization />
</author>

<date year="2002" month="August" />
</front>

<seriesInfo value="62" name="BCP" />
<seriesInfo value="3366" name="RFC" />
<format octets="66097" type="TXT" target="ftp://ftp.isi.edu/in-notes/rfc3366.txt" />
</reference>


<reference target2="reference.RFC.3367.xml" anchor="RFC3367">
<front>
<title>Common Name Resolution Protocol (CNRP)</title>
<author fullname="N. Popp" initials="N." surname="Popp">
<organization />
</author>

<author fullname="M. Mealling" initials="M." surname="Mealling">
<organization />
</author>

<author fullname="M. Moseley" initials="M." surname="Moseley">
<organization />
</author>

<date year="2002" month="August" />
</front>

<seriesInfo value="3367" name="RFC" />
<format octets="86889" type="TXT" target="ftp://ftp.isi.edu/in-notes/rfc3367.txt" />
</reference>


<reference target2="reference.RFC.3368.xml" anchor="RFC3368">
<front>
<title>The 'go' URI Scheme for the Common Name Resolution Protocol</title>
<author fullname="M. Mealling" initials="M." surname="Mealling">
<organization />
</author>

<date year="2002" month="August" />
</front>

<seriesInfo value="3368" name="RFC" />
<format octets="12726" type="TXT" target="ftp://ftp.isi.edu/in-notes/rfc3368.txt" />
</reference>


<reference target2="reference.RFC.3369.xml" anchor="RFC3369">
<front>
<title>Cryptographic Message Syntax (CMS)</title>
<author fullname="R. Housley" initials="R." surname="Housley">
<organization />
</author>

<date year="2002" month="August" />
</front>

<seriesInfo value="3369" name="RFC" />
<format octets="113975" type="TXT" target="ftp://ftp.isi.edu/in-notes/rfc3369.txt" />
</reference>


<reference target2="reference.RFC.3370.xml" anchor="RFC3370">
<front>
<title>Cryptographic Message Syntax (CMS) Algorithms</title>
<author fullname="R. Housley" initials="R." surname="Housley">
<organization />
</author>

<date year="2002" month="August" />
</front>

<seriesInfo value="3370" name="RFC" />
<format octets="51001" type="TXT" target="ftp://ftp.isi.edu/in-notes/rfc3370.txt" />
</reference>


<reference target2="reference.RFC.3371.xml" anchor="RFC3371">
<front>
<title>Layer Two Tunneling Protocol "L2TP" Management Information Base</title>
<author fullname="E. Caves" initials="E." surname="Caves">
<organization />
</author>

<author fullname="P. Calhoun" initials="P." surname="Calhoun">
<organization />
</author>

<author fullname="R. Wheeler" initials="R." surname="Wheeler">
<organization />
</author>

<date year="2002" month="August" />
</front>

<seriesInfo value="3371" name="RFC" />
<format octets="139974" type="TXT" target="ftp://ftp.isi.edu/in-notes/rfc3371.txt" />
</reference>


<reference target2="reference.RFC.3372.xml" anchor="RFC3372">
<front>
<title>Session Initiation Protocol for Telephones (SIP-T): Context and Architectures</title>
<author fullname="A. Vemuri" initials="A." surname="Vemuri">
<organization />
</author>

<author fullname="J. Peterson" initials="J." surname="Peterson">
<organization />
</author>

<date year="2002" month="September" />
</front>

<seriesInfo value="63" name="BCP" />
<seriesInfo value="3372" name="RFC" />
<format octets="49893" type="TXT" target="ftp://ftp.isi.edu/in-notes/rfc3372.txt" />
</reference>


<reference target2="reference.RFC.3373.xml" anchor="RFC3373">
<front>
<title>Three-Way Handshake for Intermediate System to Intermediate System (IS-IS) Point-to-Point Adjacencies</title>
<author fullname="D. Katz" initials="D." surname="Katz">
<organization />
</author>

<author fullname="R. Saluja" initials="R." surname="Saluja">
<organization />
</author>

<date year="2002" month="September" />
</front>

<seriesInfo value="3373" name="RFC" />
<format octets="19522" type="TXT" target="ftp://ftp.isi.edu/in-notes/rfc3373.txt" />
</reference>


<reference target2="reference.RFC.3374.xml" anchor="RFC3374">
<front>
<title>Problem Description: Reasons For Performing Context Transfers Between Nodes in an IP Access Network</title>
<author fullname="J. Kempf" initials="J." surname="Kempf">
<organization />
</author>

<date year="2002" month="September" />
</front>

<seriesInfo value="3374" name="RFC" />
<format octets="28245" type="TXT" target="ftp://ftp.isi.edu/in-notes/rfc3374.txt" />
</reference>


<reference target2="reference.RFC.3375.xml" anchor="RFC3375">
<front>
<title>Generic Registry-Registrar Protocol Requirements</title>
<author fullname="S. Hollenbeck" initials="S." surname="Hollenbeck">
<organization />
</author>

<date year="2002" month="September" />
</front>

<seriesInfo value="3375" name="RFC" />
<format octets="46022" type="TXT" target="ftp://ftp.isi.edu/in-notes/rfc3375.txt" />
</reference>


<reference target2="reference.RFC.3376.xml" anchor="RFC3376">
<front>
<title>Internet Group Management Protocol, Version 3</title>
<author fullname="B. Cain" initials="B." surname="Cain">
<organization />
</author>

<author fullname="S. Deering" initials="S." surname="Deering">
<organization />
</author>

<author fullname="I. Kouvelas" initials="I." surname="Kouvelas">
<organization />
</author>

<author fullname="B. Fenner" initials="B." surname="Fenner">
<organization />
</author>

<author fullname="A. Thyagarajan" initials="A." surname="Thyagarajan">
<organization />
</author>

<date year="2002" month="October" />
</front>

<seriesInfo value="3376" name="RFC" />
<format octets="119726" type="TXT" target="ftp://ftp.isi.edu/in-notes/rfc3376.txt" />
</reference>


<reference target2="reference.RFC.3377.xml" anchor="RFC3377">
<front>
<title>Lightweight Directory Access Protocol (v3): Technical Specification</title>
<author fullname="J. Hodges" initials="J." surname="Hodges">
<organization />
</author>

<author fullname="R. Morgan" initials="R." surname="Morgan">
<organization />
</author>

<date year="2002" month="September" />
</front>

<seriesInfo value="3377" name="RFC" />
<format octets="9981" type="TXT" target="ftp://ftp.isi.edu/in-notes/rfc3377.txt" />
</reference>


<reference target2="reference.RFC.3378.xml" anchor="RFC3378">
<front>
<title>EtherIP: Tunneling Ethernet Frames in IP Datagrams</title>
<author fullname="R. Housley" initials="R." surname="Housley">
<organization />
</author>

<author fullname="S. Hollenbeck" initials="S." surname="Hollenbeck">
<organization />
</author>

<date year="2002" month="September" />
</front>

<seriesInfo value="3378" name="RFC" />
<format octets="18803" type="TXT" target="ftp://ftp.isi.edu/in-notes/rfc3378.txt" />
</reference>


<reference target2="reference.RFC.3379.xml" anchor="RFC3379">
<front>
<title>Delegated Path Validation and Delegated Path Discovery Protocol Requirements</title>
<author fullname="D. Pinkas" initials="D." surname="Pinkas">
<organization />
</author>

<author fullname="R. Housley" initials="R." surname="Housley">
<organization />
</author>

<date year="2002" month="September" />
</front>

<seriesInfo value="3379" name="RFC" />
<format octets="32455" type="TXT" target="ftp://ftp.isi.edu/in-notes/rfc3379.txt" />
</reference>


<reference target2="reference.RFC.3380.xml" anchor="RFC3380">
<front>
<title>Internet Printing Protocol (IPP): Job and Printer Set Operations</title>
<author fullname="T. Hastings" initials="T." surname="Hastings">
<organization />
</author>

<author fullname="R. Herriot" initials="R." surname="Herriot">
<organization />
</author>

<author fullname="C. Kugler" initials="C." surname="Kugler">
<organization />
</author>

<author fullname="H. Lewis" initials="H." surname="Lewis">
<organization />
</author>

<date year="2002" month="September" />
</front>

<seriesInfo value="3380" name="RFC" />
<format octets="132044" type="TXT" target="ftp://ftp.isi.edu/in-notes/rfc3380.txt" />
</reference>


<reference target2="reference.RFC.3381.xml" anchor="RFC3381">
<front>
<title>Internet Printing Protocol (IPP): Job Progress Attributes</title>
<author fullname="T. Hastings" initials="T." surname="Hastings">
<organization />
</author>

<author fullname="H. Lewis" initials="H." surname="Lewis">
<organization />
</author>

<author fullname="R. Bergman" initials="R." surname="Bergman">
<organization />
</author>

<date year="2002" month="September" />
</front>

<seriesInfo value="3381" name="RFC" />
<format octets="36595" type="TXT" target="ftp://ftp.isi.edu/in-notes/rfc3381.txt" />
</reference>


<reference target2="reference.RFC.3382.xml" anchor="RFC3382">
<front>
<title>Internet Printing Protocol (IPP): The 'collection' attribute syntax</title>
<author fullname="R. deBry" initials="R." surname="deBry">
<organization />
</author>

<author fullname="T. Hastings" initials="T." surname="Hastings">
<organization />
</author>

<author fullname="R. Herriot" initials="R." surname="Herriot">
<organization />
</author>

<author fullname="K. Ocke" initials="K." surname="Ocke">
<organization />
</author>

<author fullname="P. Zehler" initials="P." surname="Zehler">
<organization />
</author>

<date year="2002" month="September" />
</front>

<seriesInfo value="3382" name="RFC" />
<format octets="78173" type="TXT" target="ftp://ftp.isi.edu/in-notes/rfc3382.txt" />
</reference>


<reference target2="reference.RFC.3383.xml" anchor="RFC3383">
<front>
<title>Internet Assigned Numbers Authority (IANA) Considerations for the Lightweight Directory Access Protocol (LDAP)</title>
<author fullname="K. Zeilenga" initials="K." surname="Zeilenga">
<organization />
</author>

<date year="2002" month="September" />
</front>

<seriesInfo value="64" name="BCP" />
<seriesInfo value="3383" name="RFC" />
<format octets="45893" type="TXT" target="ftp://ftp.isi.edu/in-notes/rfc3383.txt" />
</reference>


<reference target2="reference.RFC.3384.xml" anchor="RFC3384">
<front>
<title>Lightweight Directory Access Protocol (version 3) Replication Requirements</title>
<author fullname="E. Stokes" initials="E." surname="Stokes">
<organization />
</author>

<author fullname="R. Weiser" initials="R." surname="Weiser">
<organization />
</author>

<author fullname="R. Moats" initials="R." surname="Moats">
<organization />
</author>

<author fullname="R. Huber" initials="R." surname="Huber">
<organization />
</author>

<date year="2002" month="October" />
</front>

<seriesInfo value="3384" name="RFC" />
<format octets="66871" type="TXT" target="ftp://ftp.isi.edu/in-notes/rfc3384.txt" />
</reference>


<reference target2="reference.RFC.3385.xml" anchor="RFC3385">
<front>
<title>Internet Protocol Small Computer System Interface (iSCSI) Cyclic Redundancy Check (CRC)/Checksum Considerations</title>
<author fullname="D. Sheinwald" initials="D." surname="Sheinwald">
<organization />
</author>

<author fullname="J. Satran" initials="J." surname="Satran">
<organization />
</author>

<author fullname="P. Thaler" initials="P." surname="Thaler">
<organization />
</author>

<author fullname="V. Cavanna" initials="V." surname="Cavanna">
<organization />
</author>

<date year="2002" month="September" />
</front>

<seriesInfo value="3385" name="RFC" />
<format octets="53450" type="TXT" target="ftp://ftp.isi.edu/in-notes/rfc3385.txt" />
</reference>


<reference target2="reference.RFC.3386.xml" anchor="RFC3386">
<front>
<title>Network Hierarchy and Multilayer Survivability</title>
<author fullname="W. Lai" initials="W." surname="Lai">
<organization />
</author>

<author fullname="D. McDysan" initials="D." surname="McDysan">
<organization />
</author>

<date year="2002" month="November" />
</front>

<seriesInfo value="3386" name="RFC" />
<format octets="65345" type="TXT" target="ftp://ftp.isi.edu/in-notes/rfc3386.txt" />
</reference>


<reference target2="reference.RFC.3387.xml" anchor="RFC3387">
<front>
<title>Considerations from the Service Management Research Group (SMRG) on Quality of Service (QoS) in the IP Network</title>
<author fullname="M. Eder" initials="M." surname="Eder">
<organization />
</author>

<author fullname="H. Chaskar" initials="H." surname="Chaskar">
<organization />
</author>

<author fullname="S. Nag" initials="S." surname="Nag">
<organization />
</author>

<date year="2002" month="September" />
</front>

<seriesInfo value="3387" name="RFC" />
<format octets="52693" type="TXT" target="ftp://ftp.isi.edu/in-notes/rfc3387.txt" />
</reference>


<reference target2="reference.RFC.3388.xml" anchor="RFC3388">
<front>
<title>Grouping of Media Lines in the Session Description Protocol (SDP)</title>
<author fullname="G. Camarillo" initials="G." surname="Camarillo">
<organization />
</author>

<author fullname="G. Eriksson" initials="G." surname="Eriksson">
<organization />
</author>

<author fullname="J. Holler" initials="J." surname="Holler">
<organization />
</author>

<author fullname="H. Schulzrinne" initials="H." surname="Schulzrinne">
<organization />
</author>

<date year="2002" month="December" />
</front>

<seriesInfo value="3388" name="RFC" />
<format octets="39365" type="TXT" target="ftp://ftp.isi.edu/in-notes/rfc3388.txt" />
</reference>


<reference target2="reference.RFC.3389.xml" anchor="RFC3389">
<front>
<title>Real-time Transport Protocol (RTP) Payload for Comfort Noise (CN)</title>
<author fullname="R. Zopf" initials="R." surname="Zopf">
<organization />
</author>

<date year="2002" month="September" />
</front>

<seriesInfo value="3389" name="RFC" />
<format octets="17018" type="TXT" target="ftp://ftp.isi.edu/in-notes/rfc3389.txt" />
</reference>


<reference target2="reference.RFC.3390.xml" anchor="RFC3390">
<front>
<title>Increasing TCP's Initial Window</title>
<author fullname="M. Allman" initials="M." surname="Allman">
<organization />
</author>

<author fullname="S. Floyd" initials="S." surname="Floyd">
<organization />
</author>

<author fullname="C. Partridge" initials="C." surname="Partridge">
<organization />
</author>

<date year="2002" month="October" />
</front>

<seriesInfo value="3390" name="RFC" />
<format octets="36177" type="TXT" target="ftp://ftp.isi.edu/in-notes/rfc3390.txt" />
</reference>


<reference target2="reference.RFC.3391.xml" anchor="RFC3391">
<front>
<title>The MIME Application/Vnd.pwg-multiplexed Content-Type</title>
<author fullname="R. Herriot" initials="R." surname="Herriot">
<organization />
</author>

<date year="2002" month="December" />
</front>

<seriesInfo value="3391" name="RFC" />
<format octets="54739" type="TXT" target="ftp://ftp.isi.edu/in-notes/rfc3391.txt" />
</reference>


<reference target2="reference.RFC.3392.xml" anchor="RFC3392">
<front>
<title>Capabilities Advertisement with BGP-4</title>
<author fullname="R. Chandra" initials="R." surname="Chandra">
<organization />
</author>

<author fullname="J. Scudder" initials="J." surname="Scudder">
<organization />
</author>

<date year="2002" month="November" />
</front>

<seriesInfo value="3392" name="RFC" />
<format octets="9885" type="TXT" target="ftp://ftp.isi.edu/in-notes/rfc3392.txt" />
</reference>


<reference target2="reference.RFC.3393.xml" anchor="RFC3393">
<front>
<title>IP Packet Delay Variation Metric for IP Performance Metrics (IPPM)</title>
<author fullname="C. Demichelis" initials="C." surname="Demichelis">
<organization />
</author>

<author fullname="P. Chimento" initials="P." surname="Chimento">
<organization />
</author>

<date year="2002" month="November" />
</front>

<seriesInfo value="3393" name="RFC" />
<format octets="47731" type="TXT" target="ftp://ftp.isi.edu/in-notes/rfc3393.txt" />
</reference>


<reference target2="reference.RFC.3394.xml" anchor="RFC3394">
<front>
<title>Advanced Encryption Standard (AES) Key Wrap Algorithm</title>
<author fullname="J. Schaad" initials="J." surname="Schaad">
<organization />
</author>

<author fullname="R. Housley" initials="R." surname="Housley">
<organization />
</author>

<date year="2002" month="September" />
</front>

<seriesInfo value="3394" name="RFC" />
<format octets="73072" type="TXT" target="ftp://ftp.isi.edu/in-notes/rfc3394.txt" />
</reference>


<reference target2="reference.RFC.3395.xml" anchor="RFC3395">
<front>
<title>Remote Network Monitoring MIB Protocol Identifier Reference Extensions</title>
<author fullname="A. Bierman" initials="A." surname="Bierman">
<organization />
</author>

<author fullname="C. Bucci" initials="C." surname="Bucci">
<organization />
</author>

<author fullname="R. Dietz" initials="R." surname="Dietz">
<organization />
</author>

<author fullname="A. Warth" initials="A." surname="Warth">
<organization />
</author>

<date year="2002" month="September" />
</front>

<seriesInfo value="3395" name="RFC" />
<format octets="43862" type="TXT" target="ftp://ftp.isi.edu/in-notes/rfc3395.txt" />
</reference>


<reference target2="reference.RFC.3396.xml" anchor="RFC3396">
<front>
<title>Encoding Long Options in the Dynamic Host Configuration Protocol (DHCPv4)</title>
<author fullname="T. Lemon" initials="T." surname="Lemon">
<organization />
</author>

<author fullname="S. Cheshire" initials="S." surname="Cheshire">
<organization />
</author>

<date year="2002" month="November" />
</front>

<seriesInfo value="3396" name="RFC" />
<format octets="18779" type="TXT" target="ftp://ftp.isi.edu/in-notes/rfc3396.txt" />
</reference>


<reference target2="reference.RFC.3397.xml" anchor="RFC3397">
<front>
<title>Dynamic Host Configuration Protocol (DHCP) Domain Search Option</title>
<author fullname="B. Aboba" initials="B." surname="Aboba">
<organization />
</author>

<author fullname="S. Cheshire" initials="S." surname="Cheshire">
<organization />
</author>

<date year="2002" month="November" />
</front>

<seriesInfo value="3397" name="RFC" />
<format octets="15446" type="TXT" target="ftp://ftp.isi.edu/in-notes/rfc3397.txt" />
</reference>


<reference target2="reference.RFC.3398.xml" anchor="RFC3398">
<front>
<title>Integrated Services Digital Network (ISDN) User Part (ISUP) to Session Initiation Protocol (SIP) Mapping</title>
<author fullname="G. Camarillo" initials="G." surname="Camarillo">
<organization />
</author>

<author fullname="A.B. Roach" initials="A.B." surname="Roach">
<organization />
</author>

<author fullname="J. Peterson" initials="J." surname="Peterson">
<organization />
</author>

<author fullname="L. Ong" initials="L." surname="Ong">
<organization />
</author>

<date year="2002" month="December" />
</front>

<seriesInfo value="3398" name="RFC" />
<format octets="166197" type="TXT" target="ftp://ftp.isi.edu/in-notes/rfc3398.txt" />
</reference>


<reference target2="reference.RFC.3401.xml" anchor="RFC3401">
<front>
<title>Dynamic Delegation Discovery System (DDDS) Part One: The Comprehensive DDDS</title>
<author fullname="M. Mealling" initials="M." surname="Mealling">
<organization />
</author>

<date year="2002" month="October" />
</front>

<seriesInfo value="3401" name="RFC" />
<format octets="10172" type="TXT" target="ftp://ftp.isi.edu/in-notes/rfc3401.txt" />
</reference>


<reference target2="reference.RFC.3402.xml" anchor="RFC3402">
<front>
<title>Dynamic Delegation Discovery System (DDDS) Part Two: The Algorithm</title>
<author fullname="M. Mealling" initials="M." surname="Mealling">
<organization />
</author>

<date year="2002" month="October" />
</front>

<seriesInfo value="3402" name="RFC" />
<format octets="38925" type="TXT" target="ftp://ftp.isi.edu/in-notes/rfc3402.txt" />
</reference>


<reference target2="reference.RFC.3403.xml" anchor="RFC3403">
<front>
<title>Dynamic Delegation Discovery System (DDDS) Part Three: The Domain Name System (DNS) Database</title>
<author fullname="M. Mealling" initials="M." surname="Mealling">
<organization />
</author>

<date year="2002" month="October" />
</front>

<seriesInfo value="3403" name="RFC" />
<format octets="31058" type="TXT" target="ftp://ftp.isi.edu/in-notes/rfc3403.txt" />
</reference>


<reference target2="reference.RFC.3404.xml" anchor="RFC3404">
<front>
<title>Dynamic Delegation Discovery System (DDDS) Part Four: The Uniform Resource Identifiers (URI)</title>
<author fullname="M. Mealling" initials="M." surname="Mealling">
<organization />
</author>

<date year="2002" month="October" />
</front>

<seriesInfo value="3404" name="RFC" />
<format octets="40124" type="TXT" target="ftp://ftp.isi.edu/in-notes/rfc3404.txt" />
</reference>


<reference target2="reference.RFC.3405.xml" anchor="RFC3405">
<front>
<title>Dynamic Delegation Discovery System (DDDS) Part Five: URI.ARPA Assignment Procedures</title>
<author fullname="M. Mealling" initials="M." surname="Mealling">
<organization />
</author>

<date year="2002" month="October" />
</front>

<seriesInfo value="65" name="BCP" />
<seriesInfo value="3405" name="RFC" />
<format octets="19469" type="TXT" target="ftp://ftp.isi.edu/in-notes/rfc3405.txt" />
</reference>


<reference target2="reference.RFC.3406.xml" anchor="RFC3406">
<front>
<title>Uniform Resource Names (URN) Namespace Definition Mechanisms</title>
<author fullname="L. Daigle" initials="L." surname="Daigle">
<organization />
</author>

<author fullname="D. van Gulik" initials="D." surname="van Gulik">
<organization />
</author>

<author fullname="R. Iannella" initials="R." surname="Iannella">
<organization />
</author>

<author fullname="P. Faltstrom" initials="P." surname="Faltstrom">
<organization />
</author>

<date year="2002" month="October" />
</front>

<seriesInfo value="66" name="BCP" />
<seriesInfo value="3406" name="RFC" />
<format octets="43707" type="TXT" target="ftp://ftp.isi.edu/in-notes/rfc3406.txt" />
</reference>


<reference target2="reference.RFC.3407.xml" anchor="RFC3407">
<front>
<title>Session Description Protocol (SDP) Simple Capability Declaration</title>
<author fullname="F. Andreasen" initials="F." surname="Andreasen">
<organization />
</author>

<date year="2002" month="October" />
</front>

<seriesInfo value="3407" name="RFC" />
<format octets="21133" type="TXT" target="ftp://ftp.isi.edu/in-notes/rfc3407.txt" />
</reference>


<reference target2="reference.RFC.3408.xml" anchor="RFC3408">
<front>
<title>Zero-byte Support for Bidirectional Reliable Mode (R-mode) in Extended Link-Layer Assisted RObust Header Compression (ROHC) Profile</title>
<author fullname="Z. Liu" initials="Z." surname="Liu">
<organization />
</author>

<author fullname="K. Le" initials="K." surname="Le">
<organization />
</author>

<date year="2002" month="December" />
</front>

<seriesInfo value="3408" name="RFC" />
<format octets="14805" type="TXT" target="ftp://ftp.isi.edu/in-notes/rfc3408.txt" />
</reference>


<reference target2="reference.RFC.3409.xml" anchor="RFC3409">
<front>
<title>Lower Layer Guidelines for Robust RTP/UDP/IP Header Compression</title>
<author fullname="K. Svanbro" initials="K." surname="Svanbro">
<organization />
</author>

<date year="2002" month="December" />
</front>

<seriesInfo value="3409" name="RFC" />
<format octets="25815" type="TXT" target="ftp://ftp.isi.edu/in-notes/rfc3409.txt" />
</reference>


<reference target2="reference.RFC.3410.xml" anchor="RFC3410">
<front>
<title>Introduction and Applicability Statements for Internet-Standard Management Framework</title>
<author fullname="J. Case" initials="J." surname="Case">
<organization />
</author>

<author fullname="R. Mundy" initials="R." surname="Mundy">
<organization />
</author>

<author fullname="D. Partain" initials="D." surname="Partain">
<organization />
</author>

<author fullname="B. Stewart" initials="B." surname="Stewart">
<organization />
</author>

<date year="2002" month="December" />
</front>

<seriesInfo value="3410" name="RFC" />
<format octets="61461" type="TXT" target="ftp://ftp.isi.edu/in-notes/rfc3410.txt" />
</reference>


<reference target2="reference.RFC.3411.xml" anchor="RFC3411">
<front>
<title>An Architecture for Describing Simple Network Management Protocol (SNMP) Management Frameworks</title>
<author fullname="D. Harrington" initials="D." surname="Harrington">
<organization />
</author>

<author fullname="R. Presuhn" initials="R." surname="Presuhn">
<organization />
</author>

<author fullname="B. Wijnen" initials="B." surname="Wijnen">
<organization />
</author>

<date year="2002" month="December" />
</front>

<seriesInfo value="62" name="STD" />
<seriesInfo value="3411" name="RFC" />
<format octets="140096" type="TXT" target="ftp://ftp.isi.edu/in-notes/rfc3411.txt" />
</reference>


<reference target2="reference.RFC.3412.xml" anchor="RFC3412">
<front>
<title>Message Processing and Dispatching for the Simple Network Management Protocol (SNMP)</title>
<author fullname="J. Case" initials="J." surname="Case">
<organization />
</author>

<author fullname="D. Harrington" initials="D." surname="Harrington">
<organization />
</author>

<author fullname="R. Presuhn" initials="R." surname="Presuhn">
<organization />
</author>

<author fullname="B. Wijnen" initials="B." surname="Wijnen">
<organization />
</author>

<date year="2002" month="December" />
</front>

<seriesInfo value="62" name="STD" />
<seriesInfo value="3412" name="RFC" />
<format octets="95710" type="TXT" target="ftp://ftp.isi.edu/in-notes/rfc3412.txt" />
</reference>


<reference target2="reference.RFC.3413.xml" anchor="RFC3413">
<front>
<title>Simple Network Management Protocol (SNMP) Applications</title>
<author fullname="D. Levi" initials="D." surname="Levi">
<organization />
</author>

<author fullname="P. Meyer" initials="P." surname="Meyer">
<organization />
</author>

<author fullname="B. Stewart" initials="B." surname="Stewart">
<organization />
</author>

<date year="2002" month="December" />
</front>

<seriesInfo value="62" name="STD" />
<seriesInfo value="3413" name="RFC" />
<format octets="153719" type="TXT" target="ftp://ftp.isi.edu/in-notes/rfc3413.txt" />
</reference>


<reference target2="reference.RFC.3414.xml" anchor="RFC3414">
<front>
<title>User-based Security Model (USM) for version 3 of the Simple Network Management Protocol (SNMPv3)</title>
<author fullname="U. Blumenthal" initials="U." surname="Blumenthal">
<organization />
</author>

<author fullname="B. Wijnen" initials="B." surname="Wijnen">
<organization />
</author>

<date year="2002" month="December" />
</front>

<seriesInfo value="62" name="STD" />
<seriesInfo value="3414" name="RFC" />
<format octets="193558" type="TXT" target="ftp://ftp.isi.edu/in-notes/rfc3414.txt" />
</reference>


<reference target2="reference.RFC.3415.xml" anchor="RFC3415">
<front>
<title>View-based Access Control Model (VACM) for the Simple Network Management Protocol (SNMP)</title>
<author fullname="B. Wijnen" initials="B." surname="Wijnen">
<organization />
</author>

<author fullname="R. Presuhn" initials="R." surname="Presuhn">
<organization />
</author>

<author fullname="K. McCloghrie" initials="K." surname="McCloghrie">
<organization />
</author>

<date year="2002" month="December" />
</front>

<seriesInfo value="62" name="STD" />
<seriesInfo value="3415" name="RFC" />
<format octets="82046" type="TXT" target="ftp://ftp.isi.edu/in-notes/rfc3415.txt" />
</reference>


<reference target2="reference.RFC.3416.xml" anchor="RFC3416">
<front>
<title>Version 2 of the Protocol Operations for the Simple Network Management Protocol (SNMP)</title>
<author fullname="R. Presuhn" initials="R." surname="Presuhn">
<organization />
</author>

<date year="2002" month="December" />
</front>

<seriesInfo value="62" name="STD" />
<seriesInfo value="3416" name="RFC" />
<format octets="70043" type="TXT" target="ftp://ftp.isi.edu/in-notes/rfc3416.txt" />
</reference>


<reference target2="reference.RFC.3417.xml" anchor="RFC3417">
<front>
<title>Transport Mappings for the Simple Network Management Protocol (SNMP)</title>
<author fullname="R. Presuhn" initials="R." surname="Presuhn">
<organization />
</author>

<date year="2002" month="December" />
</front>

<seriesInfo value="62" name="STD" />
<seriesInfo value="3417" name="RFC" />
<format octets="38650" type="TXT" target="ftp://ftp.isi.edu/in-notes/rfc3417.txt" />
</reference>


<reference target2="reference.RFC.3418.xml" anchor="RFC3418">
<front>
<title>Management Information Base (MIB) for the Simple Network Management Protocol (SNMP)</title>
<author fullname="R. Presuhn" initials="R." surname="Presuhn">
<organization />
</author>

<date year="2002" month="December" />
</front>

<seriesInfo value="62" name="STD" />
<seriesInfo value="3418" name="RFC" />
<format octets="49096" type="TXT" target="ftp://ftp.isi.edu/in-notes/rfc3418.txt" />
</reference>


<reference target2="reference.RFC.3419.xml" anchor="RFC3419">
<front>
<title>Textual Conventions for Transport Addresses</title>
<author fullname="M. Daniele" initials="M." surname="Daniele">
<organization />
</author>

<author fullname="J. Schoenwaelder" initials="J." surname="Schoenwaelder">
<organization />
</author>

<date year="2002" month="December" />
</front>

<seriesInfo value="3419" name="RFC" />
<format octets="37466" type="TXT" target="ftp://ftp.isi.edu/in-notes/rfc3419.txt" />
</reference>


<reference target2="reference.RFC.3420.xml" anchor="RFC3420">
<front>
<title>Internet Media Type message/sipfrag</title>
<author fullname="R. Sparks" initials="R." surname="Sparks">
<organization />
</author>

<date year="2002" month="November" />
</front>

<seriesInfo value="3420" name="RFC" />
<format octets="14745" type="TXT" target="ftp://ftp.isi.edu/in-notes/rfc3420.txt" />
</reference>


<reference target2="reference.RFC.3421.xml" anchor="RFC3421">
<front>
<title>Select and Sort Extensions for the Service Location Protocol (SLP)</title>
<author fullname="W. Zhao" initials="W." surname="Zhao">
<organization />
</author>

<author fullname="H. Schulzrinne" initials="H." surname="Schulzrinne">
<organization />
</author>

<author fullname="E. Guttman" initials="E." surname="Guttman">
<organization />
</author>

<author fullname="C. Bisdikian" initials="C." surname="Bisdikian">
<organization />
</author>

<author fullname="W. Jerome" initials="W." surname="Jerome">
<organization />
</author>

<date year="2002" month="November" />
</front>

<seriesInfo value="3421" name="RFC" />
<format octets="15260" type="TXT" target="ftp://ftp.isi.edu/in-notes/rfc3421.txt" />
</reference>


<reference target2="reference.RFC.3422.xml" anchor="RFC3422">
<front>
<title>Forwarding Media Access Control (MAC) Frames over Multiple Access Protocol over Synchronous Optical Network/Synchronous Digital Hierarchy (MAPOS)</title>
<author fullname="O. Okamoto" initials="O." surname="Okamoto">
<organization />
</author>

<author fullname="M. Maruyama" initials="M." surname="Maruyama">
<organization />
</author>

<author fullname="T. Sajima" initials="T." surname="Sajima">
<organization />
</author>

<date year="2002" month="November" />
</front>

<seriesInfo value="3422" name="RFC" />
<format octets="37576" type="TXT" target="ftp://ftp.isi.edu/in-notes/rfc3422.txt" />
</reference>


<reference target2="reference.RFC.3423.xml" anchor="RFC3423">
<front>
<title>XACCT's Common Reliable Accounting for Network Element (CRANE) Protocol Specification Version 1.0</title>
<author fullname="K. Zhang" initials="K." surname="Zhang">
<organization />
</author>

<author fullname="E. Elkin" initials="E." surname="Elkin">
<organization />
</author>

<date year="2002" month="November" />
</front>

<seriesInfo value="3423" name="RFC" />
<format octets="97731" type="TXT" target="ftp://ftp.isi.edu/in-notes/rfc3423.txt" />
</reference>


<reference target2="reference.RFC.3424.xml" anchor="RFC3424">
<front>
<title>IAB Considerations for UNilateral Self-Address Fixing (UNSAF) Across Network Address Translation</title>
<author fullname="L. Daigle" initials="L." surname="Daigle">
<organization />
</author>

<author>
<organization>IAB</organization>
</author>

<date year="2002" month="November" />
</front>

<seriesInfo value="3424" name="RFC" />
<format octets="18165" type="TXT" target="ftp://ftp.isi.edu/in-notes/rfc3424.txt" />
</reference>


<reference target2="reference.RFC.3425.xml" anchor="RFC3425">
<front>
<title>Obsoleting IQUERY</title>
<author fullname="D. Lawrence" initials="D." surname="Lawrence">
<organization />
</author>

<date year="2002" month="November" />
</front>

<seriesInfo value="3425" name="RFC" />
<format octets="8615" type="TXT" target="ftp://ftp.isi.edu/in-notes/rfc3425.txt" />
</reference>


<reference target2="reference.RFC.3426.xml" anchor="RFC3426">
<front>
<title>General Architectural and Policy Considerations</title>
<author fullname="S. Floyd" initials="S." surname="Floyd">
<organization />
</author>

<date year="2002" month="November" />
</front>

<seriesInfo value="3426" name="RFC" />
<format octets="54868" type="TXT" target="ftp://ftp.isi.edu/in-notes/rfc3426.txt" />
</reference>


<reference target2="reference.RFC.3427.xml" anchor="RFC3427">
<front>
<title>Change Process for the Session Initiation Protocol (SIP)</title>
<author fullname="A. Mankin" initials="A." surname="Mankin">
<organization />
</author>

<author fullname="S. Bradner" initials="S." surname="Bradner">
<organization />
</author>

<author fullname="R. Mahy" initials="R." surname="Mahy">
<organization />
</author>

<author fullname="D. Willis" initials="D." surname="Willis">
<organization />
</author>

<author fullname="J. Ott" initials="J." surname="Ott">
<organization />
</author>

<author fullname="B. Rosen" initials="B." surname="Rosen">
<organization />
</author>

<date year="2002" month="December" />
</front>

<seriesInfo value="67" name="BCP" />
<seriesInfo value="3427" name="RFC" />
<format octets="26234" type="TXT" target="ftp://ftp.isi.edu/in-notes/rfc3427.txt" />
</reference>


<reference target2="reference.RFC.3428.xml" anchor="RFC3428">
<front>
<title>Session Initiation Protocol (SIP) Extension for Instant Messaging</title>
<author fullname="B. Campbell" initials="B." surname="Campbell">
<organization />
</author>

<author fullname="J. Rosenberg" initials="J." surname="Rosenberg">
<organization />
</author>

<author fullname="H. Schulzrinne" initials="H." surname="Schulzrinne">
<organization />
</author>

<author fullname="C. Huitema" initials="C." surname="Huitema">
<organization />
</author>

<author fullname="D. Gurle" initials="D." surname="Gurle">
<organization />
</author>

<date year="2002" month="December" />
</front>

<seriesInfo value="3428" name="RFC" />
<format octets="41475" type="TXT" target="ftp://ftp.isi.edu/in-notes/rfc3428.txt" />
</reference>


<reference target2="reference.RFC.3429.xml" anchor="RFC3429">
<front>
<title>Assignment of the 'OAM Alert Label' for Multiprotocol Label Switching Architecture (MPLS) Operation and Maintenance (OAM) Functions</title>
<author fullname="H. Ohta" initials="H." surname="Ohta">
<organization />
</author>

<date year="2002" month="November" />
</front>

<seriesInfo value="3429" name="RFC" />
<format octets="10903" type="TXT" target="ftp://ftp.isi.edu/in-notes/rfc3429.txt" />
</reference>


<reference target2="reference.RFC.3430.xml" anchor="RFC3430">
<front>
<title>Simple Network Management Protocol Over Transmission Control Protocol Transport Mapping</title>
<author fullname="J. Schoenwaelder" initials="J." surname="Schoenwaelder">
<organization />
</author>

<date year="2002" month="December" />
</front>

<seriesInfo value="3430" name="RFC" />
<format octets="21527" type="TXT" target="ftp://ftp.isi.edu/in-notes/rfc3430.txt" />
</reference>


<reference target2="reference.RFC.3431.xml" anchor="RFC3431">
<front>
<title>Sieve Extension: Relational Tests</title>
<author fullname="W. Segmuller" initials="W." surname="Segmuller">
<organization />
</author>

<date year="2002" month="December" />
</front>

<seriesInfo value="3431" name="RFC" />
<format octets="12849" type="TXT" target="ftp://ftp.isi.edu/in-notes/rfc3431.txt" />
</reference>


<reference target2="reference.RFC.3432.xml" anchor="RFC3432">
<front>
<title>Network performance measurement with periodic streams</title>
<author fullname="V. Raisanen" initials="V." surname="Raisanen">
<organization />
</author>

<author fullname="G. Grotefeld" initials="G." surname="Grotefeld">
<organization />
</author>

<author fullname="A. Morton" initials="A." surname="Morton">
<organization />
</author>

<date year="2002" month="November" />
</front>

<seriesInfo value="3432" name="RFC" />
<format octets="52493" type="TXT" target="ftp://ftp.isi.edu/in-notes/rfc3432.txt" />
</reference>


<reference target2="reference.RFC.3433.xml" anchor="RFC3433">
<front>
<title>Entity Sensor Management Information Base</title>
<author fullname="A. Bierman" initials="A." surname="Bierman">
<organization />
</author>

<author fullname="D. Romascanu" initials="D." surname="Romascanu">
<organization />
</author>

<author fullname="K.C. Norseth" initials="K.C." surname="Norseth">
<organization />
</author>

<date year="2002" month="December" />
</front>

<seriesInfo value="3433" name="RFC" />
<format octets="31857" type="TXT" target="ftp://ftp.isi.edu/in-notes/rfc3433.txt" />
</reference>


<reference target2="reference.RFC.3434.xml" anchor="RFC3434">
<front>
<title>Remote Monitoring MIB Extensions for High Capacity Alarms</title>
<author fullname="A. Bierman" initials="A." surname="Bierman">
<organization />
</author>

<author fullname="K. McCloghrie" initials="K." surname="McCloghrie">
<organization />
</author>

<date year="2002" month="December" />
</front>

<seriesInfo value="3434" name="RFC" />
<format octets="51072" type="TXT" target="ftp://ftp.isi.edu/in-notes/rfc3434.txt" />
</reference>


<reference target2="reference.RFC.3435.xml" anchor="RFC3435">
<front>
<title>Media Gateway Control Protocol (MGCP) Version 1.0</title>
<author fullname="F. Andreasen" initials="F." surname="Andreasen">
<organization />
</author>

<author fullname="B. Foster" initials="B." surname="Foster">
<organization />
</author>

<date year="2003" month="January" />
</front>

<seriesInfo value="3435" name="RFC" />
<format octets="467084" type="TXT" target="ftp://ftp.isi.edu/in-notes/rfc3435.txt" />
</reference>


<reference target2="reference.RFC.3436.xml" anchor="RFC3436">
<front>
<title>Transport Layer Security over Stream Control Transmission Protocol</title>
<author fullname="A. Jungmaier" initials="A." surname="Jungmaier">
<organization />
</author>

<author fullname="E. Rescorla" initials="E." surname="Rescorla">
<organization />
</author>

<author fullname="M. Tuexen" initials="M." surname="Tuexen">
<organization />
</author>

<date year="2002" month="December" />
</front>

<seriesInfo value="3436" name="RFC" />
<format octets="16333" type="TXT" target="ftp://ftp.isi.edu/in-notes/rfc3436.txt" />
</reference>


<reference target2="reference.RFC.3437.xml" anchor="RFC3437">
<front>
<title>Layer-Two Tunneling Protocol Extensions for PPP Link Control Protocol Negotiation</title>
<author fullname="W. Palter" initials="W." surname="Palter">
<organization />
</author>

<author fullname="W. Townsley" initials="W." surname="Townsley">
<organization />
</author>

<date year="2002" month="December" />
</front>

<seriesInfo value="3437" name="RFC" />
<format octets="20820" type="TXT" target="ftp://ftp.isi.edu/in-notes/rfc3437.txt" />
</reference>


<reference target2="reference.RFC.3438.xml" anchor="RFC3438">
<front>
<title>Layer Two Tunneling Protocol (L2TP) Internet Assigned Numbers Authority (IANA) Considerations Update</title>
<author fullname="W. Townsley" initials="W." surname="Townsley">
<organization />
</author>

<date year="2002" month="December" />
</front>

<seriesInfo value="68" name="BCP" />
<seriesInfo value="3438" name="RFC" />
<format octets="9135" type="TXT" target="ftp://ftp.isi.edu/in-notes/rfc3438.txt" />
</reference>


<reference target2="reference.RFC.3439.xml" anchor="RFC3439">
<front>
<title>Some Internet Architectural Guidelines and Philosophy</title>
<author fullname="R. Bush" initials="R." surname="Bush">
<organization />
</author>

<author fullname="D. Meyer" initials="D." surname="Meyer">
<organization />
</author>

<date year="2002" month="December" />
</front>

<seriesInfo value="3439" name="RFC" />
<format octets="70333" type="TXT" target="ftp://ftp.isi.edu/in-notes/rfc3439.txt" />
</reference>


<reference target2="reference.RFC.3440.xml" anchor="RFC3440">
<front>
<title>Definitions of Extension Managed Objects for Asymmetric Digital Subscriber Lines</title>
<author fullname="F. Ly" initials="F." surname="Ly">
<organization />
</author>

<author fullname="G. Bathrick" initials="G." surname="Bathrick">
<organization />
</author>

<date year="2002" month="December" />
</front>

<seriesInfo value="3440" name="RFC" />
<format octets="76058" type="TXT" target="ftp://ftp.isi.edu/in-notes/rfc3440.txt" />
</reference>


<reference target2="reference.RFC.3441.xml" anchor="RFC3441">
<front>
<title>Asynchronous Transfer Mode (ATM) Package for the Media Gateway Control Protocol (MGCP)</title>
<author fullname="R. Kumar" initials="R." surname="Kumar">
<organization />
</author>

<date year="2003" month="January" />
</front>

<seriesInfo value="3441" name="RFC" />
<format octets="122455" type="TXT" target="ftp://ftp.isi.edu/in-notes/rfc3441.txt" />
</reference>


<reference target2="reference.RFC.3442.xml" anchor="RFC3442">
<front>
<title>The Classless Static Route Option for Dynamic Host Configuration Protocol (DHCP) version 4</title>
<author fullname="T. Lemon" initials="T." surname="Lemon">
<organization />
</author>

<author fullname="S. Cheshire" initials="S." surname="Cheshire">
<organization />
</author>

<author fullname="B. Volz" initials="B." surname="Volz">
<organization />
</author>

<date year="2002" month="December" />
</front>

<seriesInfo value="3442" name="RFC" />
<format octets="19370" type="TXT" target="ftp://ftp.isi.edu/in-notes/rfc3442.txt" />
</reference>


<reference target2="reference.RFC.3443.xml" anchor="RFC3443">
<front>
<title>Time To Live (TTL) Processing in Multi-Protocol Label Switching (MPLS) Networks</title>
<author fullname="P. Agarwal" initials="P." surname="Agarwal">
<organization />
</author>

<author fullname="B. Akyol" initials="B." surname="Akyol">
<organization />
</author>

<date year="2003" month="January" />
</front>

<seriesInfo value="3443" name="RFC" />
<format octets="18749" type="TXT" target="ftp://ftp.isi.edu/in-notes/rfc3443.txt" />
</reference>


<reference target2="reference.RFC.3444.xml" anchor="RFC3444">
<front>
<title>On the Difference between Information Models and Data Models</title>
<author fullname="A. Pras" initials="A." surname="Pras">
<organization />
</author>

<author fullname="J. Schoenwaelder" initials="J." surname="Schoenwaelder">
<organization />
</author>

<date year="2003" month="January" />
</front>

<seriesInfo value="3444" name="RFC" />
<format octets="18596" type="TXT" target="ftp://ftp.isi.edu/in-notes/rfc3444.txt" />
</reference>


<reference target2="reference.RFC.3445.xml" anchor="RFC3445">
<front>
<title>Limiting the Scope of the KEY Resource Record (RR)</title>
<author fullname="D. Massey" initials="D." surname="Massey">
<organization />
</author>

<author fullname="S. Rose" initials="S." surname="Rose">
<organization />
</author>

<date year="2002" month="December" />
</front>

<seriesInfo value="3445" name="RFC" />
<format octets="20947" type="TXT" target="ftp://ftp.isi.edu/in-notes/rfc3445.txt" />
</reference>


<reference target2="reference.RFC.3446.xml" anchor="RFC3446">
<front>
<title>Anycast Rendevous Point (RP) mechanism using Protocol Independent Multicast (PIM) and Multicast Source Discovery Protocol (MSDP)</title>
<author fullname="D. Kim" initials="D." surname="Kim">
<organization />
</author>

<author fullname="D. Meyer" initials="D." surname="Meyer">
<organization />
</author>

<author fullname="H. Kilmer" initials="H." surname="Kilmer">
<organization />
</author>

<author fullname="D. Farinacci" initials="D." surname="Farinacci">
<organization />
</author>

<date year="2003" month="January" />
</front>

<seriesInfo value="3446" name="RFC" />
<format octets="14792" type="TXT" target="ftp://ftp.isi.edu/in-notes/rfc3446.txt" />
</reference>


<reference target2="reference.RFC.3447.xml" anchor="RFC3447">
<front>
<title>Public-Key Cryptography Standards (PKCS) #1: RSA Cryptography Specifications Version 2.1</title>
<author fullname="J. Jonsson" initials="J." surname="Jonsson">
<organization />
</author>

<author fullname="B. Kaliski" initials="B." surname="Kaliski">
<organization />
</author>

<date year="2003" month="February" />
</front>

<seriesInfo value="3447" name="RFC" />
<format octets="143173" type="TXT" target="ftp://ftp.isi.edu/in-notes/rfc3447.txt" />
</reference>


<reference target2="reference.RFC.3448.xml" anchor="RFC3448">
<front>
<title>TCP Friendly Rate Control (TFRC): Protocol Specification</title>
<author fullname="M. Handley" initials="M." surname="Handley">
<organization />
</author>

<author fullname="S. Floyd" initials="S." surname="Floyd">
<organization />
</author>

<author fullname="J. Padhye" initials="J." surname="Padhye">
<organization />
</author>

<author fullname="J. Widmer" initials="J." surname="Widmer">
<organization />
</author>

<date year="2003" month="January" />
</front>

<seriesInfo value="3448" name="RFC" />
<format octets="52657" type="TXT" target="ftp://ftp.isi.edu/in-notes/rfc3448.txt" />
</reference>


<reference target2="reference.RFC.3449.xml" anchor="RFC3449">
<front>
<title>TCP Performance Implications of Network Path Asymmetry</title>
<author fullname="H. Balakrishnan" initials="H." surname="Balakrishnan">
<organization />
</author>

<author fullname="V. Padmanabhan" initials="V." surname="Padmanabhan">
<organization />
</author>

<author fullname="G. Fairhurst" initials="G." surname="Fairhurst">
<organization />
</author>

<author fullname="M. Sooriyabandara" initials="M." surname="Sooriyabandara">
<organization />
</author>

<date year="2002" month="December" />
</front>

<seriesInfo value="69" name="BCP" />
<seriesInfo value="3449" name="RFC" />
<format octets="108839" type="TXT" target="ftp://ftp.isi.edu/in-notes/rfc3449.txt" />
</reference>


<reference target2="reference.RFC.3450.xml" anchor="RFC3450">
<front>
<title>Asynchronous Layered Coding (ALC) Protocol Instantiation</title>
<author fullname="M. Luby" initials="M." surname="Luby">
<organization />
</author>

<author fullname="J. Gemmell" initials="J." surname="Gemmell">
<organization />
</author>

<author fullname="L. Vicisano" initials="L." surname="Vicisano">
<organization />
</author>

<author fullname="L. Rizzo" initials="L." surname="Rizzo">
<organization />
</author>

<author fullname="J. Crowcroft" initials="J." surname="Crowcroft">
<organization />
</author>

<date year="2002" month="December" />
</front>

<seriesInfo value="3450" name="RFC" />
<format octets="86022" type="TXT" target="ftp://ftp.isi.edu/in-notes/rfc3450.txt" />
</reference>


<reference target2="reference.RFC.3451.xml" anchor="RFC3451">
<front>
<title>Layered Coding Transport (LCT) Building Block</title>
<author fullname="M. Luby" initials="M." surname="Luby">
<organization />
</author>

<author fullname="J. Gemmell" initials="J." surname="Gemmell">
<organization />
</author>

<author fullname="L. Vicisano" initials="L." surname="Vicisano">
<organization />
</author>

<author fullname="L. Rizzo" initials="L." surname="Rizzo">
<organization />
</author>

<author fullname="M. Handley" initials="M." surname="Handley">
<organization />
</author>

<author fullname="J. Crowcroft" initials="J." surname="Crowcroft">
<organization />
</author>

<date year="2002" month="December" />
</front>

<seriesInfo value="3451" name="RFC" />
<format octets="72594" type="TXT" target="ftp://ftp.isi.edu/in-notes/rfc3451.txt" />
</reference>


<reference target2="reference.RFC.3452.xml" anchor="RFC3452">
<front>
<title>Forward Error Correction (FEC) Building Block</title>
<author fullname="M. Luby" initials="M." surname="Luby">
<organization />
</author>

<author fullname="L. Vicisano" initials="L." surname="Vicisano">
<organization />
</author>

<author fullname="J. Gemmell" initials="J." surname="Gemmell">
<organization />
</author>

<author fullname="L. Rizzo" initials="L." surname="Rizzo">
<organization />
</author>

<author fullname="M. Handley" initials="M." surname="Handley">
<organization />
</author>

<author fullname="J. Crowcroft" initials="J." surname="Crowcroft">
<organization />
</author>

<date year="2002" month="December" />
</front>

<seriesInfo value="3452" name="RFC" />
<format octets="38368" type="TXT" target="ftp://ftp.isi.edu/in-notes/rfc3452.txt" />
</reference>


<reference target2="reference.RFC.3453.xml" anchor="RFC3453">
<front>
<title>The Use of Forward Error Correction (FEC) in Reliable Multicast</title>
<author fullname="M. Luby" initials="M." surname="Luby">
<organization />
</author>

<author fullname="L. Vicisano" initials="L." surname="Vicisano">
<organization />
</author>

<author fullname="J. Gemmell" initials="J." surname="Gemmell">
<organization />
</author>

<author fullname="L. Rizzo" initials="L." surname="Rizzo">
<organization />
</author>

<author fullname="M. Handley" initials="M." surname="Handley">
<organization />
</author>

<author fullname="J. Crowcroft" initials="J." surname="Crowcroft">
<organization />
</author>

<date year="2002" month="December" />
</front>

<seriesInfo value="3453" name="RFC" />
<format octets="46853" type="TXT" target="ftp://ftp.isi.edu/in-notes/rfc3453.txt" />
</reference>


<reference target2="reference.RFC.3454.xml" anchor="RFC3454">
<front>
<title>Preparation of Internationalized Strings ("stringprep")</title>
<author fullname="P. Hoffman" initials="P." surname="Hoffman">
<organization />
</author>

<author fullname="M. Blanchet" initials="M." surname="Blanchet">
<organization />
</author>

<date year="2002" month="December" />
</front>

<seriesInfo value="3454" name="RFC" />
<format octets="138684" type="TXT" target="ftp://ftp.isi.edu/in-notes/rfc3454.txt" />
</reference>


<reference target2="reference.RFC.3455.xml" anchor="RFC3455">
<front>
<title>Private Header (P-Header) Extensions to the Session Initiation Protocol (SIP) for the 3rd-Generation Partnership Project (3GPP)</title>
<author fullname="M. Garcia-Martin" initials="M." surname="Garcia-Martin">
<organization />
</author>

<author fullname="E. Henrikson" initials="E." surname="Henrikson">
<organization />
</author>

<author fullname="D. Mills" initials="D." surname="Mills">
<organization />
</author>

<date year="2003" month="January" />
</front>

<seriesInfo value="3455" name="RFC" />
<format octets="79620" type="TXT" target="ftp://ftp.isi.edu/in-notes/rfc3455.txt" />
</reference>


<reference target2="reference.RFC.3456.xml" anchor="RFC3456">
<front>
<title>Dynamic Host Configuration Protocol (DHCPv4) Configuration of IPsec Tunnel Mode</title>
<author fullname="B. Patel" initials="B." surname="Patel">
<organization />
</author>

<author fullname="B. Aboba" initials="B." surname="Aboba">
<organization />
</author>

<author fullname="S. Kelly" initials="S." surname="Kelly">
<organization />
</author>

<author fullname="V. Gupta" initials="V." surname="Gupta">
<organization />
</author>

<date year="2003" month="January" />
</front>

<seriesInfo value="3456" name="RFC" />
<format octets="40340" type="TXT" target="ftp://ftp.isi.edu/in-notes/rfc3456.txt" />
</reference>


<reference target2="reference.RFC.3457.xml" anchor="RFC3457">
<front>
<title>Requirements for IPsec Remote Access Scenarios</title>
<author fullname="S. Kelly" initials="S." surname="Kelly">
<organization />
</author>

<author fullname="S. Ramamoorthi" initials="S." surname="Ramamoorthi">
<organization />
</author>

<date year="2003" month="January" />
</front>

<seriesInfo value="3457" name="RFC" />
<format octets="75167" type="TXT" target="ftp://ftp.isi.edu/in-notes/rfc3457.txt" />
</reference>


<reference target2="reference.RFC.3458.xml" anchor="RFC3458">
<front>
<title>Message Context for Internet Mail</title>
<author fullname="E. Burger" initials="E." surname="Burger">
<organization />
</author>

<author fullname="E. Candell" initials="E." surname="Candell">
<organization />
</author>

<author fullname="C. Eliot" initials="C." surname="Eliot">
<organization />
</author>

<author fullname="G. Klyne" initials="G." surname="Klyne">
<organization />
</author>

<date year="2003" month="January" />
</front>

<seriesInfo value="3458" name="RFC" />
<format octets="34181" type="TXT" target="ftp://ftp.isi.edu/in-notes/rfc3458.txt" />
</reference>


<reference target2="reference.RFC.3459.xml" anchor="RFC3459">
<front>
<title>Critical Content Multi-purpose Internet Mail Extensions (MIME) Parameter</title>
<author fullname="E. Burger" initials="E." surname="Burger">
<organization />
</author>

<date year="2003" month="January" />
</front>

<seriesInfo value="3459" name="RFC" />
<format octets="54282" type="TXT" target="ftp://ftp.isi.edu/in-notes/rfc3459.txt" />
</reference>


<reference target2="reference.RFC.3460.xml" anchor="RFC3460">
<front>
<title>Policy Core Information Model (PCIM) Extensions</title>
<author fullname="B. Moore" initials="B." surname="Moore">
<organization />
</author>

<date year="2003" month="January" />
</front>

<seriesInfo value="3460" name="RFC" />
<format octets="212453" type="TXT" target="ftp://ftp.isi.edu/in-notes/rfc3460.txt" />
</reference>


<reference target2="reference.RFC.3461.xml" anchor="RFC3461">
<front>
<title>Simple Mail Transfer Protocol (SMTP) Service Extension for Delivery Status Notifications (DSNs)</title>
<author fullname="K. Moore" initials="K." surname="Moore">
<organization />
</author>

<date year="2003" month="January" />
</front>

<seriesInfo value="3461" name="RFC" />
<format octets="76076" type="TXT" target="ftp://ftp.isi.edu/in-notes/rfc3461.txt" />
</reference>


<reference target2="reference.RFC.3462.xml" anchor="RFC3462">
<front>
<title>The Multipart/Report Content Type for the Reporting of Mail System Administrative Messages</title>
<author fullname="G. Vaudreuil" initials="G." surname="Vaudreuil">
<organization />
</author>

<date year="2003" month="January" />
</front>

<seriesInfo value="3462" name="RFC" />
<format octets="12186" type="TXT" target="ftp://ftp.isi.edu/in-notes/rfc3462.txt" />
</reference>


<reference target2="reference.RFC.3463.xml" anchor="RFC3463">
<front>
<title>Enhanced Mail System Status Codes</title>
<author fullname="G. Vaudreuil" initials="G." surname="Vaudreuil">
<organization />
</author>

<date year="2003" month="January" />
</front>

<seriesInfo value="3463" name="RFC" />
<format octets="31832" type="TXT" target="ftp://ftp.isi.edu/in-notes/rfc3463.txt" />
</reference>


<reference target2="reference.RFC.3464.xml" anchor="RFC3464">
<front>
<title>An Extensible Message Format for Delivery Status Notifications</title>
<author fullname="K. Moore" initials="K." surname="Moore">
<organization />
</author>

<author fullname="G. Vaudreuil" initials="G." surname="Vaudreuil">
<organization />
</author>

<date year="2003" month="January" />
</front>

<seriesInfo value="3464" name="RFC" />
<format octets="83060" type="TXT" target="ftp://ftp.isi.edu/in-notes/rfc3464.txt" />
</reference>


<reference target2="reference.RFC.3465.xml" anchor="RFC3465">
<front>
<title>TCP Congestion Control with Appropriate Byte Counting (ABC)</title>
<author fullname="M. Allman" initials="M." surname="Allman">
<organization />
</author>

<date year="2003" month="February" />
</front>

<seriesInfo value="3465" name="RFC" />
<format octets="23486" type="TXT" target="ftp://ftp.isi.edu/in-notes/rfc3465.txt" />
</reference>


<reference target2="reference.RFC.3466.xml" anchor="RFC3466">
<front>
<title>A Model for Content Internetworking (CDI)</title>
<author fullname="M. Day" initials="M." surname="Day">
<organization />
</author>

<author fullname="B. Cain" initials="B." surname="Cain">
<organization />
</author>

<author fullname="G. Tomlinson" initials="G." surname="Tomlinson">
<organization />
</author>

<author fullname="P. Rzewski" initials="P." surname="Rzewski">
<organization />
</author>

<date year="2003" month="February" />
</front>

<seriesInfo value="3466" name="RFC" />
<format octets="37684" type="TXT" target="ftp://ftp.isi.edu/in-notes/rfc3466.txt" />
</reference>


<reference target2="reference.RFC.3467.xml" anchor="RFC3467">
<front>
<title>Role of the Domain Name System (DNS)</title>
<author fullname="J. Klensin" initials="J." surname="Klensin">
<organization />
</author>

<date year="2003" month="February" />
</front>

<seriesInfo value="3467" name="RFC" />
<format octets="84570" type="TXT" target="ftp://ftp.isi.edu/in-notes/rfc3467.txt" />
</reference>


<reference target2="reference.RFC.3468.xml" anchor="RFC3468">
<front>
<title>The Multiprotocol Label Switching (MPLS) Working Group decision on MPLS signaling protocols</title>
<author fullname="L. Andersson" initials="L." surname="Andersson">
<organization />
</author>

<author fullname="G. Swallow" initials="G." surname="Swallow">
<organization />
</author>

<date year="2003" month="February" />
</front>

<seriesInfo value="3468" name="RFC" />
<format octets="22072" type="TXT" target="ftp://ftp.isi.edu/in-notes/rfc3468.txt" />
</reference>


<reference target2="reference.RFC.3469.xml" anchor="RFC3469">
<front>
<title>Framework for Multi-Protocol Label Switching (MPLS)-based Recovery</title>
<author fullname="V. Sharma" initials="V." surname="Sharma">
<organization />
</author>

<author fullname="F. Hellstrand" initials="F." surname="Hellstrand">
<organization />
</author>

<date year="2003" month="February" />
</front>

<seriesInfo value="3469" name="RFC" />
<format octets="89331" type="TXT" target="ftp://ftp.isi.edu/in-notes/rfc3469.txt" />
</reference>


<reference target2="reference.RFC.3470.xml" anchor="RFC3470">
<front>
<title abbrev="XML Within IETF Protocols">
     Guidelines for the Use of Extensible Markup Language (XML) within IETF Protocols</title>
<author fullname="Scott Hollenbeck" initials="S." surname="Hollenbeck">
<organization>VeriSign, Inc.</organization>

<address>
<postal>
<street>21345 Ridgetop Circle</street>
<city>Dulles</city>
<region>VA</region>
<code>20166-6503</code>
<country>US</country>
</postal>

<phone>+1 703 948 3257</phone>
<email>shollenbeck@verisign.com</email>
</address>
</author>

<author fullname="Marshall T. Rose" initials="M." surname="Rose">
<organization>Dover Beach Consulting, Inc.</organization>

<address>
<postal>
<street>POB 255268</street>
<city>Sacramento</city>
<region>CA</region>
<code>95865-5268</code>
<country>US</country>
</postal>

<phone>+1 916 483 8878</phone>
<email>mrose@dbc.mtview.ca.us</email>
</address>
</author>

<author fullname="Larry Masinter" initials="L." surname="Masinter">
<organization>Adobe Systems Incorporated</organization>

<address>
<postal>
<street>Mail Stop W14</street>
<street>345 Park Ave.</street>
<city>San Jose</city>
<region>CA</region>
<code>95110</code>
<country>US</country>
</postal>

<phone>+1 408 536 3024</phone>
<email>LMM@acm.org</email>
<uri>http://larry.masinter.net</uri>
</address>
</author>

<date year="2003" day="23" month="January" />
<area>General</area>
<keyword>BCP</keyword>
<keyword>Best Current Practice</keyword>
<keyword>XML</keyword>
<keyword>Extensible Markup Language</keyword>

<abstract>
<t>The Extensible Markup Language (XML) is a framework for structuring
      data. While it evolved from Standard Generalized Markup Language (SGML)
      -- a markup language primarily focused on structuring documents -- XML
      has evolved to be a widely-used mechanism for representing structured
      data.</t>

<t>There are a wide variety of Internet protocols being developed; many
      have need for a representation for structured data relevant to their
      application.  There has been much interest in the use of XML as a
      representation method.  This document describes basic XML concepts,
      analyzes various alternatives in the use of XML, and provides guidelines
      for the use of XML within IETF standards-track protocols.</t>
</abstract>

<note title="Conventions Used In This Document">
<t>This document recommends, as policy, what specifications for Internet
      protocols -- and, in particular, IETF standards track protocol documents
      -- should include as normative language within them.  The capitalized
      keywords "SHOULD", "MUST", "REQUIRED", etc. are used in the sense of how
      they would be used within other documents with the meanings as specified
      in BCP 14, RFC 2119 .</t>
</note>
</front>

<seriesInfo value="70" name="BCP" />
<seriesInfo value="3470" name="RFC" />
<format octets="64252" type="TXT" target="ftp://ftp.isi.edu/in-notes/rfc3470.txt" />
<format octets="95246" type="HTML" target="http://xml.resource.org/public/rfc/html/rfc3470.html" />
<format octets="103046" type="XML" target="http://xml.resource.org/public/rfc/xml/rfc3470.xml" />
</reference>


<reference target2="reference.RFC.3471.xml" anchor="RFC3471">
<front>
<title>Generalized Multi-Protocol Label Switching (GMPLS) Signaling Functional Description</title>
<author fullname="L. Berger" initials="L." surname="Berger">
<organization />
</author>

<date year="2003" month="January" />
</front>

<seriesInfo value="3471" name="RFC" />
<format octets="72105" type="TXT" target="ftp://ftp.isi.edu/in-notes/rfc3471.txt" />
</reference>


<reference target2="reference.RFC.3472.xml" anchor="RFC3472">
<front>
<title>Generalized Multi-Protocol Label Switching (GMPLS) Signaling Constraint-based Routed Label Distribution Protocol (CR-LDP) Extensions</title>
<author fullname="P. Ashwood-Smith" initials="P." surname="Ashwood-Smith">
<organization />
</author>

<author fullname="L. Berger" initials="L." surname="Berger">
<organization />
</author>

<date year="2003" month="January" />
</front>

<seriesInfo value="3472" name="RFC" />
<format octets="49006" type="TXT" target="ftp://ftp.isi.edu/in-notes/rfc3472.txt" />
</reference>


<reference target2="reference.RFC.3473.xml" anchor="RFC3473">
<front>
<title>Generalized Multi-Protocol Label Switching (GMPLS) Signaling Resource ReserVation Protocol-Traffic Engineering (RSVP-TE) Extensions</title>
<author fullname="L. Berger" initials="L." surname="Berger">
<organization />
</author>

<date year="2003" month="January" />
</front>

<seriesInfo value="3473" name="RFC" />
<format octets="91808" type="TXT" target="ftp://ftp.isi.edu/in-notes/rfc3473.txt" />
</reference>


<reference target2="reference.RFC.3474.xml" anchor="RFC3474">
<front>
<title>Documentation of IANA assignments for Generalized MultiProtocol Label Switching (GMPLS) Resource Reservation Protocol - Traffic Engineering (RSVP-TE) Usage and Extensions for Automatically Switched Optical Network (ASON)</title>
<author fullname="Z. Lin" initials="Z." surname="Lin">
<organization />
</author>

<author fullname="D. Pendarakis" initials="D." surname="Pendarakis">
<organization />
</author>

<date year="2003" month="March" />
</front>

<seriesInfo value="3474" name="RFC" />
<format octets="52551" type="TXT" target="ftp://ftp.isi.edu/in-notes/rfc3474.txt" />
</reference>


<reference target2="reference.RFC.3475.xml" anchor="RFC3475">
<front>
<title>Documentation of IANA assignments for Constraint-Based LSP setup using LDP (CR-LDP) Extensions for Automatic Switched Optical Network (ASON)</title>
<author fullname="O. Aboul-Magd" initials="O." surname="Aboul-Magd">
<organization />
</author>

<date year="2003" month="March" />
</front>

<seriesInfo value="3475" name="RFC" />
<format octets="29995" type="TXT" target="ftp://ftp.isi.edu/in-notes/rfc3475.txt" />
</reference>


<reference target2="reference.RFC.3476.xml" anchor="RFC3476">
<front>
<title>Documentation of IANA Assignments for Label Distribution Protocol (LDP), Resource ReSerVation Protocol (RSVP), and Resource ReSerVation Protocol-Traffic Engineering (RSVP-TE) Extensions for Optical UNI Signaling</title>
<author fullname="B. Rajagopalan" initials="B." surname="Rajagopalan">
<organization />
</author>

<date year="2003" month="March" />
</front>

<seriesInfo value="3476" name="RFC" />
<format octets="22009" type="TXT" target="ftp://ftp.isi.edu/in-notes/rfc3476.txt" />
</reference>


<reference target2="reference.RFC.3477.xml" anchor="RFC3477">
<front>
<title>Signalling Unnumbered Links in Resource ReSerVation Protocol - Traffic Engineering (RSVP-TE)</title>
<author fullname="K. Kompella" initials="K." surname="Kompella">
<organization />
</author>

<author fullname="Y. Rekhter" initials="Y." surname="Rekhter">
<organization />
</author>

<date year="2003" month="January" />
</front>

<seriesInfo value="3477" name="RFC" />
<format octets="19899" type="TXT" target="ftp://ftp.isi.edu/in-notes/rfc3477.txt" />
</reference>


<reference target2="reference.RFC.3478.xml" anchor="RFC3478">
<front>
<title>Graceful Restart Mechanism for Label Distribution Protocol</title>
<author fullname="M. Leelanivas" initials="M." surname="Leelanivas">
<organization />
</author>

<author fullname="Y. Rekhter" initials="Y." surname="Rekhter">
<organization />
</author>

<author fullname="R. Aggarwal" initials="R." surname="Aggarwal">
<organization />
</author>

<date year="2003" month="February" />
</front>

<seriesInfo value="3478" name="RFC" />
<format octets="29248" type="TXT" target="ftp://ftp.isi.edu/in-notes/rfc3478.txt" />
</reference>


<reference target2="reference.RFC.3479.xml" anchor="RFC3479">
<front>
<title>Fault Tolerance for the Label Distribution Protocol (LDP)</title>
<author fullname="A. Farrel" initials="A." surname="Farrel">
<organization />
</author>

<date year="2003" month="February" />
</front>

<seriesInfo value="3479" name="RFC" />
<format octets="115778" type="TXT" target="ftp://ftp.isi.edu/in-notes/rfc3479.txt" />
</reference>


<reference target2="reference.RFC.3480.xml" anchor="RFC3480">
<front>
<title>Signalling Unnumbered Links in CR-LDP (Constraint-Routing Label Distribution Protocol)</title>
<author fullname="K. Kompella" initials="K." surname="Kompella">
<organization />
</author>

<author fullname="Y. Rekhter" initials="Y." surname="Rekhter">
<organization />
</author>

<author fullname="A. Kullberg" initials="A." surname="Kullberg">
<organization />
</author>

<date year="2003" month="February" />
</front>

<seriesInfo value="3480" name="RFC" />
<format octets="17076" type="TXT" target="ftp://ftp.isi.edu/in-notes/rfc3480.txt" />
</reference>


<reference target2="reference.RFC.3481.xml" anchor="RFC3481">
<front>
<title>TCP over Second (2.5G) and Third (3G) Generation Wireless Networks</title>
<author fullname="H. Inamura" initials="H." surname="Inamura">
<organization />
</author>

<author fullname="G. Montenegro" initials="G." surname="Montenegro">
<organization />
</author>

<author fullname="R. Ludwig" initials="R." surname="Ludwig">
<organization />
</author>

<author fullname="A. Gurtov" initials="A." surname="Gurtov">
<organization />
</author>

<author fullname="F. Khafizov" initials="F." surname="Khafizov">
<organization />
</author>

<date year="2003" month="February" />
</front>

<seriesInfo value="71" name="BCP" />
<seriesInfo value="3481" name="RFC" />
<format octets="61528" type="TXT" target="ftp://ftp.isi.edu/in-notes/rfc3481.txt" />
</reference>


<reference target2="reference.RFC.3482.xml" anchor="RFC3482">
<front>
<title>Number Portability in the Global Switched Telephone Network (GSTN): An Overview</title>
<author fullname="M. Foster" initials="M." surname="Foster">
<organization />
</author>

<author fullname="T. McGarry" initials="T." surname="McGarry">
<organization />
</author>

<author fullname="J. Yu" initials="J." surname="Yu">
<organization />
</author>

<date year="2003" month="February" />
</front>

<seriesInfo value="3482" name="RFC" />
<format octets="78552" type="TXT" target="ftp://ftp.isi.edu/in-notes/rfc3482.txt" />
</reference>


<reference target2="reference.RFC.3483.xml" anchor="RFC3483">
<front>
<title>Framework for Policy Usage Feedback for Common Open Policy Service with Policy Provisioning (COPS-PR)</title>
<author fullname="D. Rawlins" initials="D." surname="Rawlins">
<organization />
</author>

<author fullname="A. Kulkarni" initials="A." surname="Kulkarni">
<organization />
</author>

<author fullname="M. Bokaemper" initials="M." surname="Bokaemper">
<organization />
</author>

<author fullname="K. Chan" initials="K." surname="Chan">
<organization />
</author>

<date year="2003" month="March" />
</front>

<seriesInfo value="3483" name="RFC" />
<format octets="19869" type="TXT" target="ftp://ftp.isi.edu/in-notes/rfc3483.txt" />
</reference>


<reference target2="reference.RFC.3484.xml" anchor="RFC3484">
<front>
<title>Default Address Selection for Internet Protocol version 6 (IPv6)</title>
<author fullname="R. Draves" initials="R." surname="Draves">
<organization />
</author>

<date year="2003" month="February" />
</front>

<seriesInfo value="3484" name="RFC" />
<format octets="55076" type="TXT" target="ftp://ftp.isi.edu/in-notes/rfc3484.txt" />
</reference>


<reference target2="reference.RFC.3485.xml" anchor="RFC3485">
<front>
<title>The Session Initiation Protocol (SIP) and Session Description Protocol (SDP) Static Dictionary for Signaling Compression (SigComp)</title>
<author fullname="M. Garcia-Martin" initials="M." surname="Garcia-Martin">
<organization />
</author>

<author fullname="C. Bormann" initials="C." surname="Bormann">
<organization />
</author>

<author fullname="J. Ott" initials="J." surname="Ott">
<organization />
</author>

<author fullname="R. Price" initials="R." surname="Price">
<organization />
</author>

<author fullname="A.B. Roach" initials="A.B." surname="Roach">
<organization />
</author>

<date year="2003" month="February" />
</front>

<seriesInfo value="3485" name="RFC" />
<format octets="80195" type="TXT" target="ftp://ftp.isi.edu/in-notes/rfc3485.txt" />
</reference>


<reference target2="reference.RFC.3486.xml" anchor="RFC3486">
<front>
<title>Compressing the Session Initiation Protocol (SIP)</title>
<author fullname="G. Camarillo" initials="G." surname="Camarillo">
<organization />
</author>

<date year="2003" month="February" />
</front>

<seriesInfo value="3486" name="RFC" />
<format octets="24181" type="TXT" target="ftp://ftp.isi.edu/in-notes/rfc3486.txt" />
</reference>


<reference target2="reference.RFC.3487.xml" anchor="RFC3487">
<front>
<title>Requirements for Resource Priority Mechanisms for the Session Initiation Protocol (SIP)</title>
<author fullname="H. Schulzrinne" initials="H." surname="Schulzrinne">
<organization />
</author>

<date year="2003" month="February" />
</front>

<seriesInfo value="3487" name="RFC" />
<format octets="39615" type="TXT" target="ftp://ftp.isi.edu/in-notes/rfc3487.txt" />
</reference>


<reference target2="reference.RFC.3488.xml" anchor="RFC3488">
<front>
<title>Cisco Systems Router-port Group Management Protocol (RGMP)</title>
<author fullname="I. Wu" initials="I." surname="Wu">
<organization />
</author>

<author fullname="T. Eckert" initials="T." surname="Eckert">
<organization />
</author>

<date year="2003" month="February" />
</front>

<seriesInfo value="3488" name="RFC" />
<format octets="37152" type="TXT" target="ftp://ftp.isi.edu/in-notes/rfc3488.txt" />
</reference>


<reference target2="reference.RFC.3489.xml" anchor="RFC3489">
<front>
<title>STUN - Simple Traversal of User Datagram Protocol (UDP) Through Network Address Translators (NATs)</title>
<author fullname="J. Rosenberg" initials="J." surname="Rosenberg">
<organization />
</author>

<author fullname="J. Weinberger" initials="J." surname="Weinberger">
<organization />
</author>

<author fullname="C. Huitema" initials="C." surname="Huitema">
<organization />
</author>

<author fullname="R. Mahy" initials="R." surname="Mahy">
<organization />
</author>

<date year="2003" month="March" />
</front>

<seriesInfo value="3489" name="RFC" />
<format octets="117562" type="TXT" target="ftp://ftp.isi.edu/in-notes/rfc3489.txt" />
</reference>


<reference target2="reference.RFC.3490.xml" anchor="RFC3490">
<front>
<title>Internationalizing Domain Names in Applications (IDNA)</title>
<author fullname="P. Faltstrom" initials="P." surname="Faltstrom">
<organization />
</author>

<author fullname="P. Hoffman" initials="P." surname="Hoffman">
<organization />
</author>

<author fullname="A. Costello" initials="A." surname="Costello">
<organization />
</author>

<date year="2003" month="March" />
</front>

<seriesInfo value="3490" name="RFC" />
<format octets="51943" type="TXT" target="ftp://ftp.isi.edu/in-notes/rfc3490.txt" />
</reference>


<reference target2="reference.RFC.3491.xml" anchor="RFC3491">
<front>
<title>Nameprep: A Stringprep Profile for Internationalized Domain Names (IDN)</title>
<author fullname="P. Hoffman" initials="P." surname="Hoffman">
<organization />
</author>

<author fullname="M. Blanchet" initials="M." surname="Blanchet">
<organization />
</author>

<date year="2003" month="March" />
</front>

<seriesInfo value="3491" name="RFC" />
<format octets="10316" type="TXT" target="ftp://ftp.isi.edu/in-notes/rfc3491.txt" />
</reference>


<reference target2="reference.RFC.3492.xml" anchor="RFC3492">
<front>
<title>Punycode: A Bootstring encoding of Unicode for Internationalized Domain Names in Applications (IDNA)</title>
<author fullname="A. Costello" initials="A." surname="Costello">
<organization />
</author>

<date year="2003" month="March" />
</front>

<seriesInfo value="3492" name="RFC" />
<format octets="67439" type="TXT" target="ftp://ftp.isi.edu/in-notes/rfc3492.txt" />
</reference>


<reference target2="reference.RFC.3493.xml" anchor="RFC3493">
<front>
<title>Basic Socket Interface Extensions for IPv6</title>
<author fullname="R. Gilligan" initials="R." surname="Gilligan">
<organization />
</author>

<author fullname="S. Thomson" initials="S." surname="Thomson">
<organization />
</author>

<author fullname="J. Bound" initials="J." surname="Bound">
<organization />
</author>

<author fullname="J. McCann" initials="J." surname="McCann">
<organization />
</author>

<author fullname="W. Stevens" initials="W." surname="Stevens">
<organization />
</author>

<date year="2003" month="February" />
</front>

<seriesInfo value="3493" name="RFC" />
<format octets="82570" type="TXT" target="ftp://ftp.isi.edu/in-notes/rfc3493.txt" />
</reference>


<reference target2="reference.RFC.3494.xml" anchor="RFC3494">
<front>
<title>Lightweight Directory Access Protocol version 2 (LDAPv2) to Historic Status</title>
<author fullname="K. Zeilenga" initials="K." surname="Zeilenga">
<organization />
</author>

<date year="2003" month="March" />
</front>

<seriesInfo value="3494" name="RFC" />
<format octets="9225" type="TXT" target="ftp://ftp.isi.edu/in-notes/rfc3494.txt" />
</reference>


<reference target2="reference.RFC.3495.xml" anchor="RFC3495">
<front>
<title>Dynamic Host Configuration Protocol (DHCP) Option for CableLabs Client Configuration</title>
<author fullname="B. Beser" initials="B." surname="Beser">
<organization />
</author>

<author fullname="P. Duffy" initials="P." surname="Duffy">
<organization />
</author>

<date year="2003" month="March" />
</front>

<seriesInfo value="3495" name="RFC" />
<format octets="26817" type="TXT" target="ftp://ftp.isi.edu/in-notes/rfc3495.txt" />
</reference>


<reference target2="reference.RFC.3496.xml" anchor="RFC3496">
<front>
<title>Protocol Extension for Support of Asynchronous Transfer Mode (ATM) Service Class-aware Multiprotocol Label Switching (MPLS) Traffic Engineering</title>
<author fullname="A.G. Malis" initials="A.G." surname="Malis">
<organization />
</author>

<author fullname="T. Hsiao" initials="T." surname="Hsiao">
<organization />
</author>

<date year="2003" month="March" />
</front>

<seriesInfo value="3496" name="RFC" />
<format octets="11431" type="TXT" target="ftp://ftp.isi.edu/in-notes/rfc3496.txt" />
</reference>


<reference target2="reference.RFC.3497.xml" anchor="RFC3497">
<front>
<title>RTP Payload Format for Society of Motion Picture and Television Engineers (SMPTE) 292M Video</title>
<author fullname="L. Gharai" initials="L." surname="Gharai">
<organization />
</author>

<author fullname="C. Perkins" initials="C." surname="Perkins">
<organization />
</author>

<author fullname="G. Goncher" initials="G." surname="Goncher">
<organization />
</author>

<author fullname="A. Mankin" initials="A." surname="Mankin">
<organization />
</author>

<date year="2003" month="March" />
</front>

<seriesInfo value="3497" name="RFC" />
<format octets="26094" type="TXT" target="ftp://ftp.isi.edu/in-notes/rfc3497.txt" />
</reference>


<reference target2="reference.RFC.3498.xml" anchor="RFC3498">
<front>
<title>Definitions of Managed Objects for Synchronous Optical Network (SONET) Linear Automatic Protection Switching (APS) Architectures</title>
<author fullname="J. Kuhfeld" initials="J." surname="Kuhfeld">
<organization />
</author>

<author fullname="J. Johnson" initials="J." surname="Johnson">
<organization />
</author>

<author fullname="M. Thatcher" initials="M." surname="Thatcher">
<organization />
</author>

<date year="2003" month="March" />
</front>

<seriesInfo value="3498" name="RFC" />
<format octets="78701" type="TXT" target="ftp://ftp.isi.edu/in-notes/rfc3498.txt" />
</reference>


<reference target2="reference.RFC.3499.xml" anchor="RFC3499">
<front>
<title>Request for Comments Summary RFC Numbers 3400-3499</title>
<author fullname="S. Ginoza" initials="S." surname="Ginoza">
<organization />
</author>

<date year="2003" month="December" />
</front>

<seriesInfo value="3499" name="RFC" />
<format octets="88033" type="TXT" target="ftp://ftp.isi.edu/in-notes/rfc3499.txt" />
</reference>


<reference target2="reference.RFC.3501.xml" anchor="RFC3501">
<front>
<title>INTERNET MESSAGE ACCESS PROTOCOL - VERSION 4rev1</title>
<author fullname="M. Crispin" initials="M." surname="Crispin">
<organization />
</author>

<date year="2003" month="March" />
</front>

<seriesInfo value="3501" name="RFC" />
<format octets="227640" type="TXT" target="ftp://ftp.isi.edu/in-notes/rfc3501.txt" />
</reference>


<reference target2="reference.RFC.3502.xml" anchor="RFC3502">
<front>
<title>Internet Message Access Protocol (IMAP) - MULTIAPPEND Extension</title>
<author fullname="M. Crispin" initials="M." surname="Crispin">
<organization />
</author>

<date year="2003" month="March" />
</front>

<seriesInfo value="3502" name="RFC" />
<format octets="13379" type="TXT" target="ftp://ftp.isi.edu/in-notes/rfc3502.txt" />
</reference>


<reference target2="reference.RFC.3503.xml" anchor="RFC3503">
<front>
<title>Message Disposition Notification (MDN) profile for Internet Message Access Protocol (IMAP)</title>
<author fullname="A. Melnikov" initials="A." surname="Melnikov">
<organization />
</author>

<date year="2003" month="March" />
</front>

<seriesInfo value="3503" name="RFC" />
<format octets="16937" type="TXT" target="ftp://ftp.isi.edu/in-notes/rfc3503.txt" />
</reference>


<reference target2="reference.RFC.3504.xml" anchor="RFC3504">
<front>
<title>Internet Open Trading Protocol (IOTP) Version 1, Errata</title>
<author fullname="D. Eastlake" initials="D." surname="Eastlake">
<organization />
</author>

<date year="2003" month="March" />
</front>

<seriesInfo value="3504" name="RFC" />
<format octets="8655" type="TXT" target="ftp://ftp.isi.edu/in-notes/rfc3504.txt" />
</reference>


<reference target2="reference.RFC.3505.xml" anchor="RFC3505">
<front>
<title>Electronic Commerce Modeling Language (ECML): Version 2 Requirements</title>
<author fullname="D. Eastlake" initials="D." surname="Eastlake">
<organization />
</author>

<date year="2003" month="March" />
</front>

<seriesInfo value="3505" name="RFC" />
<format octets="13915" type="TXT" target="ftp://ftp.isi.edu/in-notes/rfc3505.txt" />
</reference>


<reference target2="reference.RFC.3506.xml" anchor="RFC3506">
<front>
<title>Requirements and Design for Voucher Trading System (VTS)</title>
<author fullname="K. Fujimura" initials="K." surname="Fujimura">
<organization />
</author>

<author fullname="D. Eastlake" initials="D." surname="Eastlake">
<organization />
</author>

<date year="2003" month="March" />
</front>

<seriesInfo value="3506" name="RFC" />
<format octets="30945" type="TXT" target="ftp://ftp.isi.edu/in-notes/rfc3506.txt" />
</reference>


<reference target2="reference.RFC.3507.xml" anchor="RFC3507">
<front>
<title>Internet Content Adaptation Protocol (ICAP)</title>
<author fullname="J. Elson" initials="J." surname="Elson">
<organization />
</author>

<author fullname="A. Cerpa" initials="A." surname="Cerpa">
<organization />
</author>

<date year="2003" month="April" />
</front>

<seriesInfo value="3507" name="RFC" />
<format octets="98772" type="TXT" target="ftp://ftp.isi.edu/in-notes/rfc3507.txt" />
</reference>


<reference target2="reference.RFC.3508.xml" anchor="RFC3508">
<front>
<title>H.323 Uniform Resource Locator (URL) Scheme Registration</title>
<author fullname="O. Levin" initials="O." surname="Levin">
<organization />
</author>

<date year="2003" month="April" />
</front>

<seriesInfo value="3508" name="RFC" />
<format octets="10983" type="TXT" target="ftp://ftp.isi.edu/in-notes/rfc3508.txt" />
</reference>


<reference target2="reference.RFC.3509.xml" anchor="RFC3509">
<front>
<title>Alternative Implementations of OSPF Area Border Routers</title>
<author fullname="A. Zinin" initials="A." surname="Zinin">
<organization />
</author>

<author fullname="A. Lindem" initials="A." surname="Lindem">
<organization />
</author>

<author fullname="D. Yeung" initials="D." surname="Yeung">
<organization />
</author>

<date year="2003" month="April" />
</front>

<seriesInfo value="3509" name="RFC" />
<format octets="24326" type="TXT" target="ftp://ftp.isi.edu/in-notes/rfc3509.txt" />
</reference>


<reference target2="reference.RFC.3510.xml" anchor="RFC3510">
<front>
<title>Internet Printing Protocol/1.1: IPP URL Scheme</title>
<author fullname="R. Herriot" initials="R." surname="Herriot">
<organization />
</author>

<author fullname="I. McDonald" initials="I." surname="McDonald">
<organization />
</author>

<date year="2003" month="April" />
</front>

<seriesInfo value="3510" name="RFC" />
<format octets="22009" type="TXT" target="ftp://ftp.isi.edu/in-notes/rfc3510.txt" />
</reference>


<reference target2="reference.RFC.3511.xml" anchor="RFC3511">
<front>
<title>Benchmarking Methodology for Firewall Performance</title>
<author fullname="B. Hickman" initials="B." surname="Hickman">
<organization />
</author>

<author fullname="D. Newman" initials="D." surname="Newman">
<organization />
</author>

<author fullname="S. Tadjudin" initials="S." surname="Tadjudin">
<organization />
</author>

<author fullname="T. Martin" initials="T." surname="Martin">
<organization />
</author>

<date year="2003" month="April" />
</front>

<seriesInfo value="3511" name="RFC" />
<format octets="67916" type="TXT" target="ftp://ftp.isi.edu/in-notes/rfc3511.txt" />
</reference>


<reference target2="reference.RFC.3512.xml" anchor="RFC3512">
<front>
<title>Configuring Networks and Devices with Simple Network Management Protocol (SNMP)</title>
<author fullname="M. MacFaden" initials="M." surname="MacFaden">
<organization />
</author>

<author fullname="D. Partain" initials="D." surname="Partain">
<organization />
</author>

<author fullname="J. Saperia" initials="J." surname="Saperia">
<organization />
</author>

<author fullname="W. Tackabury" initials="W." surname="Tackabury">
<organization />
</author>

<date year="2003" month="April" />
</front>

<seriesInfo value="3512" name="RFC" />
<format octets="196529" type="TXT" target="ftp://ftp.isi.edu/in-notes/rfc3512.txt" />
</reference>


<reference target2="reference.RFC.3513.xml" anchor="RFC3513">
<front>
<title>Internet Protocol Version 6 (IPv6) Addressing Architecture</title>
<author fullname="R. Hinden" initials="R." surname="Hinden">
<organization />
</author>

<author fullname="S. Deering" initials="S." surname="Deering">
<organization />
</author>

<date year="2003" month="April" />
</front>

<seriesInfo value="3513" name="RFC" />
<format octets="53920" type="TXT" target="ftp://ftp.isi.edu/in-notes/rfc3513.txt" />
</reference>


<reference target2="reference.RFC.3514.xml" anchor="RFC3514">
<front>
<title>The Security Flag in the IPv4 Header</title>
<author fullname="S. Bellovin" initials="S." surname="Bellovin">
<organization />
</author>

<date year="2003" day="1" month="April" />
</front>

<seriesInfo value="3514" name="RFC" />
<format octets="11211" type="TXT" target="ftp://ftp.isi.edu/in-notes/rfc3514.txt" />
</reference>


<reference target2="reference.RFC.3515.xml" anchor="RFC3515">
<front>
<title>The Session Initiation Protocol (SIP) Refer Method</title>
<author fullname="R. Sparks" initials="R." surname="Sparks">
<organization />
</author>

<date year="2003" month="April" />
</front>

<seriesInfo value="3515" name="RFC" />
<format octets="47788" type="TXT" target="ftp://ftp.isi.edu/in-notes/rfc3515.txt" />
</reference>


<reference target2="reference.RFC.3516.xml" anchor="RFC3516">
<front>
<title>IMAP4 Binary Content Extension</title>
<author fullname="L. Nerenberg" initials="L." surname="Nerenberg">
<organization />
</author>

<date year="2003" month="April" />
</front>

<seriesInfo value="3516" name="RFC" />
<format octets="14598" type="TXT" target="ftp://ftp.isi.edu/in-notes/rfc3516.txt" />
</reference>


<reference target2="reference.RFC.3517.xml" anchor="RFC3517">
<front>
<title>A Conservative Selective Acknowledgment (SACK)-based Loss Recovery Algorithm for TCP</title>
<author fullname="E. Blanton" initials="E." surname="Blanton">
<organization />
</author>

<author fullname="M. Allman" initials="M." surname="Allman">
<organization />
</author>

<author fullname="K. Fall" initials="K." surname="Fall">
<organization />
</author>

<author fullname="L. Wang" initials="L." surname="Wang">
<organization />
</author>

<date year="2003" month="April" />
</front>

<seriesInfo value="3517" name="RFC" />
<format octets="27855" type="TXT" target="ftp://ftp.isi.edu/in-notes/rfc3517.txt" />
</reference>


<reference target2="reference.RFC.3518.xml" anchor="RFC3518">
<front>
<title>Point-to-Point Protocol (PPP) Bridging Control Protocol (BCP)</title>
<author fullname="M. Higashiyama" initials="M." surname="Higashiyama">
<organization />
</author>

<author fullname="F. Baker" initials="F." surname="Baker">
<organization />
</author>

<author fullname="T. Liao" initials="T." surname="Liao">
<organization />
</author>

<date year="2003" month="April" />
</front>

<seriesInfo value="3518" name="RFC" />
<format octets="82102" type="TXT" target="ftp://ftp.isi.edu/in-notes/rfc3518.txt" />
</reference>


<reference target2="reference.RFC.3519.xml" anchor="RFC3519">
<front>
<title>Mobile IP Traversal of Network Address Translation (NAT) Devices</title>
<author fullname="H. Levkowetz" initials="H." surname="Levkowetz">
<organization />
</author>

<author fullname="S. Vaarala" initials="S." surname="Vaarala">
<organization />
</author>

<date year="2003" month="May" />
</front>

<seriesInfo value="3519" name="RFC" />
<format octets="80522" type="TXT" target="ftp://ftp.isi.edu/in-notes/rfc3519.txt" />
</reference>


<reference target2="reference.RFC.3520.xml" anchor="RFC3520">
<front>
<title>Session Authorization Policy Element</title>
<author fullname="L-N. Hamer" initials="L-N." surname="Hamer">
<organization />
</author>

<author fullname="B. Gage" initials="B." surname="Gage">
<organization />
</author>

<author fullname="B. Kosinski" initials="B." surname="Kosinski">
<organization />
</author>

<author fullname="H. Shieh" initials="H." surname="Shieh">
<organization />
</author>

<date year="2003" month="April" />
</front>

<seriesInfo value="3520" name="RFC" />
<format octets="63445" type="TXT" target="ftp://ftp.isi.edu/in-notes/rfc3520.txt" />
</reference>


<reference target2="reference.RFC.3521.xml" anchor="RFC3521">
<front>
<title>Framework for Session Set-up with Media Authorization</title>
<author fullname="L-N. Hamer" initials="L-N." surname="Hamer">
<organization />
</author>

<author fullname="B. Gage" initials="B." surname="Gage">
<organization />
</author>

<author fullname="H. Shieh" initials="H." surname="Shieh">
<organization />
</author>

<date year="2003" month="April" />
</front>

<seriesInfo value="3521" name="RFC" />
<format octets="59548" type="TXT" target="ftp://ftp.isi.edu/in-notes/rfc3521.txt" />
</reference>


<reference target2="reference.RFC.3522.xml" anchor="RFC3522">
<front>
<title>The Eifel Detection Algorithm for TCP</title>
<author fullname="R. Ludwig" initials="R." surname="Ludwig">
<organization />
</author>

<author fullname="M. Meyer" initials="M." surname="Meyer">
<organization />
</author>

<date year="2003" month="April" />
</front>

<seriesInfo value="3522" name="RFC" />
<format octets="33731" type="TXT" target="ftp://ftp.isi.edu/in-notes/rfc3522.txt" />
</reference>


<reference target2="reference.RFC.3523.xml" anchor="RFC3523">
<front>
<title>Internet Emergency Preparedness (IEPREP) Telephony Topology Terminology</title>
<author fullname="J. Polk" initials="J." surname="Polk">
<organization />
</author>

<date year="2003" month="April" />
</front>

<seriesInfo value="3523" name="RFC" />
<format octets="10190" type="TXT" target="ftp://ftp.isi.edu/in-notes/rfc3523.txt" />
</reference>


<reference target2="reference.RFC.3524.xml" anchor="RFC3524">
<front>
<title>Mapping of Media Streams to Resource Reservation Flows</title>
<author fullname="G. Camarillo" initials="G." surname="Camarillo">
<organization />
</author>

<author fullname="A. Monrad" initials="A." surname="Monrad">
<organization />
</author>

<date year="2003" month="April" />
</front>

<seriesInfo value="3524" name="RFC" />
<format octets="11249" type="TXT" target="ftp://ftp.isi.edu/in-notes/rfc3524.txt" />
</reference>


<reference target2="reference.RFC.3525.xml" anchor="RFC3525">
<front>
<title>Gateway Control Protocol Version 1</title>
<author fullname="C. Groves" initials="C." surname="Groves">
<organization />
</author>

<author fullname="M. Pantaleo" initials="M." surname="Pantaleo">
<organization />
</author>

<author fullname="T. Anderson" initials="T." surname="Anderson">
<organization />
</author>

<author fullname="T. Taylor" initials="T." surname="Taylor">
<organization />
</author>

<date year="2003" month="June" />
</front>

<seriesInfo value="3525" name="RFC" />
<format octets="439674" type="TXT" target="ftp://ftp.isi.edu/in-notes/rfc3525.txt" />
</reference>


<reference target2="reference.RFC.3526.xml" anchor="RFC3526">
<front>
<title>More Modular Exponential (MODP) Diffie-Hellman groups for Internet Key Exchange (IKE)</title>
<author fullname="T. Kivinen" initials="T." surname="Kivinen">
<organization />
</author>

<author fullname="M. Kojo" initials="M." surname="Kojo">
<organization />
</author>

<date year="2003" month="May" />
</front>

<seriesInfo value="3526" name="RFC" />
<format octets="19166" type="TXT" target="ftp://ftp.isi.edu/in-notes/rfc3526.txt" />
</reference>


<reference target2="reference.RFC.3527.xml" anchor="RFC3527">
<front>
<title>Link Selection sub-option for the Relay Agent Information Option for DHCPv4</title>
<author fullname="K. Kinnear" initials="K." surname="Kinnear">
<organization />
</author>

<author fullname="M. Stapp" initials="M." surname="Stapp">
<organization />
</author>

<author fullname="R. Johnson" initials="R." surname="Johnson">
<organization />
</author>

<author fullname="J. Kumarasamy" initials="J." surname="Kumarasamy">
<organization />
</author>

<date year="2003" month="April" />
</front>

<seriesInfo value="3527" name="RFC" />
<format octets="16831" type="TXT" target="ftp://ftp.isi.edu/in-notes/rfc3527.txt" />
</reference>


<reference target2="reference.RFC.3528.xml" anchor="RFC3528">
<front>
<title>Mesh-enhanced Service Location Protocol (mSLP)</title>
<author fullname="W. Zhao" initials="W." surname="Zhao">
<organization />
</author>

<author fullname="H. Schulzrinne" initials="H." surname="Schulzrinne">
<organization />
</author>

<author fullname="E. Guttman" initials="E." surname="Guttman">
<organization />
</author>

<date year="2003" month="April" />
</front>

<seriesInfo value="3528" name="RFC" />
<format octets="35208" type="TXT" target="ftp://ftp.isi.edu/in-notes/rfc3528.txt" />
</reference>


<reference target2="reference.RFC.3529.xml" anchor="RFC3529">
<front>
<title abbrev="Using XML-RPC in BEEP">Using Extensible Markup Language-Remote Procedure Calling (XML-RPC)
in Blocks Extensible Exchange Protocol (BEEP)</title>
<author fullname="Ward K Harold" initials="W" surname="Harold">
<organization>IBM</organization>

<address>
<postal>
<street>11400 Burnet Road</street>
<city>Austin</city>
<region>Texas</region>
<code>78758</code>
<country>US</country>
</postal>

<phone>+1 512 838 3022</phone>
<email>wharold@us.ibm.com</email>
</address>
</author>

<date year="2003" month="April" />
<area>Applications</area>
<keyword>BEEP</keyword>
<keyword>XML-RPC</keyword>

<abstract>
<t>XML-RPC is an Extensible Markup Language-Remote Procedure Calling
protocol that works over the
Internet. It defines an XML format for messages that are transfered
between clients and servers using HTTP. An XML-RPC message encodes
either a procedure to be invoked by the server, along with the
parameters to use in the invocation, or the result of an
invocation. Procedure parameters and results can be scalars, numbers,
strings, dates, etc.; they can also be complex record and list
structures.</t>

<t>This document specifies a how to use the Blocks Extensible Exchange
Protocol (BEEP) to transfer messages encoded in the XML-RPC format
between clients and servers.</t>
</abstract>
</front>

<seriesInfo value="3529" name="RFC" />
<format octets="38462" type="HTML" target="http://xml.resource.org/public/rfc/html/rfc3529.html" />
<format octets="37483" type="XML" target="http://xml.resource.org/public/rfc/xml/rfc3529.xml" />
</reference>


<reference target2="reference.RFC.3530.xml" anchor="RFC3530">
<front>
<title>Network File System (NFS) version 4 Protocol</title>
<author fullname="S. Shepler" initials="S." surname="Shepler">
<organization />
</author>

<author fullname="B. Callaghan" initials="B." surname="Callaghan">
<organization />
</author>

<author fullname="D. Robinson" initials="D." surname="Robinson">
<organization />
</author>

<author fullname="R. Thurlow" initials="R." surname="Thurlow">
<organization />
</author>

<author fullname="C. Beame" initials="C." surname="Beame">
<organization />
</author>

<author fullname="M. Eisler" initials="M." surname="Eisler">
<organization />
</author>

<author fullname="D. Noveck" initials="D." surname="Noveck">
<organization />
</author>

<date year="2003" month="April" />
</front>

<seriesInfo value="3530" name="RFC" />
<format octets="600988" type="TXT" target="ftp://ftp.isi.edu/in-notes/rfc3530.txt" />
</reference>


<reference target2="reference.RFC.3531.xml" anchor="RFC3531">
<front>
<title>A Flexible Method for Managing the Assignment of Bits of an IPv6 Address Block</title>
<author fullname="M. Blanchet" initials="M." surname="Blanchet">
<organization />
</author>

<date year="2003" month="April" />
</front>

<seriesInfo value="3531" name="RFC" />
<format octets="11314" type="TXT" target="ftp://ftp.isi.edu/in-notes/rfc3531.txt" />
</reference>


<reference target2="reference.RFC.3532.xml" anchor="RFC3532">
<front>
<title>Requirements for the Dynamic Partitioning of Switching Elements</title>
<author fullname="T. Anderson" initials="T." surname="Anderson">
<organization />
</author>

<author fullname="J. Buerkle" initials="J." surname="Buerkle">
<organization />
</author>

<date year="2003" month="May" />
</front>

<seriesInfo value="3532" name="RFC" />
<format octets="25119" type="TXT" target="ftp://ftp.isi.edu/in-notes/rfc3532.txt" />
</reference>


<reference target2="reference.RFC.3533.xml" anchor="RFC3533">
<front>
<title>The Ogg Encapsulation Format Version 0</title>
<author fullname="S. Pfeiffer" initials="S." surname="Pfeiffer">
<organization />
</author>

<date year="2003" month="May" />
</front>

<seriesInfo value="3533" name="RFC" />
<format octets="32045" type="TXT" target="ftp://ftp.isi.edu/in-notes/rfc3533.txt" />
</reference>


<reference target2="reference.RFC.3534.xml" anchor="RFC3534">
<front>
<title>The application/ogg Media Type</title>
<author fullname="L. Walleij" initials="L." surname="Walleij">
<organization />
</author>

<date year="2003" month="May" />
</front>

<seriesInfo value="3534" name="RFC" />
<format octets="10013" type="TXT" target="ftp://ftp.isi.edu/in-notes/rfc3534.txt" />
</reference>


<reference target2="reference.RFC.3535.xml" anchor="RFC3535">
<front>
<title>Overview of the 2002 IAB Network Management Workshop</title>
<author fullname="J. Schoenwaelder" initials="J." surname="Schoenwaelder">
<organization />
</author>

<date year="2003" month="May" />
</front>

<seriesInfo value="3535" name="RFC" />
<format octets="42566" type="TXT" target="ftp://ftp.isi.edu/in-notes/rfc3535.txt" />
</reference>


<reference target2="reference.RFC.3536.xml" anchor="RFC3536">
<front>
<title>Terminology Used in Internationalization in the IETF</title>
<author fullname="P. Hoffman" initials="P." surname="Hoffman">
<organization />
</author>

<date year="2003" month="May" />
</front>

<seriesInfo value="3536" name="RFC" />
<format octets="64284" type="TXT" target="ftp://ftp.isi.edu/in-notes/rfc3536.txt" />
</reference>


<reference target2="reference.RFC.3537.xml" anchor="RFC3537">
<front>
<title>Wrapping a Hashed Message Authentication Code (HMAC) key with a Triple-Data Encryption Standard (DES) Key or an Advanced Encryption Standard (AES) Key</title>
<author fullname="J. Schaad" initials="J." surname="Schaad">
<organization />
</author>

<author fullname="R. Housley" initials="R." surname="Housley">
<organization />
</author>

<date year="2003" month="May" />
</front>

<seriesInfo value="3537" name="RFC" />
<format octets="16885" type="TXT" target="ftp://ftp.isi.edu/in-notes/rfc3537.txt" />
</reference>


<reference target2="reference.RFC.3538.xml" anchor="RFC3538">
<front>
<title>Secure Electronic Transaction (SET) Supplement for the v1.0 Internet Open Trading Protocol (IOTP)</title>
<author fullname="Y. Kawatsura" initials="Y." surname="Kawatsura">
<organization />
</author>

<date year="2003" month="June" />
</front>

<seriesInfo value="3538" name="RFC" />
<format octets="103475" type="TXT" target="ftp://ftp.isi.edu/in-notes/rfc3538.txt" />
</reference>


<reference target2="reference.RFC.3539.xml" anchor="RFC3539">
<front>
<title>Authentication, Authorization and Accounting (AAA) Transport Profile</title>
<author fullname="B. Aboba" initials="B." surname="Aboba">
<organization />
</author>

<author fullname="J. Wood" initials="J." surname="Wood">
<organization />
</author>

<date year="2003" month="June" />
</front>

<seriesInfo value="3539" name="RFC" />
<format octets="93110" type="TXT" target="ftp://ftp.isi.edu/in-notes/rfc3539.txt" />
</reference>


<reference target2="reference.RFC.3540.xml" anchor="RFC3540">
<front>
<title>Robust Explicit Congestion Notification (ECN) Signaling with Nonces</title>
<author fullname="N. Spring" initials="N." surname="Spring">
<organization />
</author>

<author fullname="D. Wetherall" initials="D." surname="Wetherall">
<organization />
</author>

<author fullname="D. Ely" initials="D." surname="Ely">
<organization />
</author>

<date year="2003" month="June" />
</front>

<seriesInfo value="3540" name="RFC" />
<format octets="30081" type="TXT" target="ftp://ftp.isi.edu/in-notes/rfc3540.txt" />
</reference>


<reference target2="reference.RFC.3541.xml" anchor="RFC3541">
<front>
<title>A Uniform Resource Name (URN) Namespace for the Web3D Consortium (Web3D)</title>
<author fullname="A. Walsh" initials="A." surname="Walsh">
<organization />
</author>

<date year="2003" month="May" />
</front>

<seriesInfo value="3541" name="RFC" />
<format octets="11358" type="TXT" target="ftp://ftp.isi.edu/in-notes/rfc3541.txt" />
</reference>


<reference target2="reference.RFC.3542.xml" anchor="RFC3542">
<front>
<title>Advanced Sockets Application Program Interface (API) for IPv6</title>
<author fullname="W. Stevens" initials="W." surname="Stevens">
<organization />
</author>

<author fullname="M. Thomas" initials="M." surname="Thomas">
<organization />
</author>

<author fullname="E. Nordmark" initials="E." surname="Nordmark">
<organization />
</author>

<author fullname="T. Jinmei" initials="T." surname="Jinmei">
<organization />
</author>

<date year="2003" month="May" />
</front>

<seriesInfo value="3542" name="RFC" />
<format octets="173028" type="TXT" target="ftp://ftp.isi.edu/in-notes/rfc3542.txt" />
</reference>


<reference target2="reference.RFC.3543.xml" anchor="RFC3543">
<front>
<title>Registration Revocation in Mobile IPv4</title>
<author fullname="S. Glass" initials="S." surname="Glass">
<organization />
</author>

<author fullname="M. Chandra" initials="M." surname="Chandra">
<organization />
</author>

<date year="2003" month="August" />
</front>

<seriesInfo value="3543" name="RFC" />
<format octets="81805" type="TXT" target="ftp://ftp.isi.edu/in-notes/rfc3543.txt" />
</reference>


<reference target2="reference.RFC.3544.xml" anchor="RFC3544">
<front>
<title>IP Header Compression over PPP</title>
<author fullname="M. Engan" initials="M." surname="Engan">
<organization />
</author>

<author fullname="S. Casner" initials="S." surname="Casner">
<organization />
</author>

<author fullname="C. Bormann" initials="C." surname="Bormann">
<organization />
</author>

<author fullname="T. Koren" initials="T." surname="Koren">
<organization />
</author>

<date year="2003" month="July" />
</front>

<seriesInfo value="3544" name="RFC" />
<format octets="27627" type="TXT" target="ftp://ftp.isi.edu/in-notes/rfc3544.txt" />
</reference>


<reference target2="reference.RFC.3545.xml" anchor="RFC3545">
<front>
<title>Enhanced Compressed RTP (CRTP) for Links with High Delay, Packet Loss and Reordering</title>
<author fullname="T. Koren" initials="T." surname="Koren">
<organization />
</author>

<author fullname="S. Casner" initials="S." surname="Casner">
<organization />
</author>

<author fullname="J. Geevarghese" initials="J." surname="Geevarghese">
<organization />
</author>

<author fullname="B. Thompson" initials="B." surname="Thompson">
<organization />
</author>

<author fullname="P. Ruddy" initials="P." surname="Ruddy">
<organization />
</author>

<date year="2003" month="July" />
</front>

<seriesInfo value="3545" name="RFC" />
<format octets="48278" type="TXT" target="ftp://ftp.isi.edu/in-notes/rfc3545.txt" />
</reference>


<reference target2="reference.RFC.3546.xml" anchor="RFC3546">
<front>
<title>Transport Layer Security (TLS) Extensions</title>
<author fullname="S. Blake-Wilson" initials="S." surname="Blake-Wilson">
<organization />
</author>

<author fullname="M. Nystrom" initials="M." surname="Nystrom">
<organization />
</author>

<author fullname="D. Hopwood" initials="D." surname="Hopwood">
<organization />
</author>

<author fullname="J. Mikkelsen" initials="J." surname="Mikkelsen">
<organization />
</author>

<author fullname="T. Wright" initials="T." surname="Wright">
<organization />
</author>

<date year="2003" month="June" />
</front>

<seriesInfo value="3546" name="RFC" />
<format octets="63437" type="TXT" target="ftp://ftp.isi.edu/in-notes/rfc3546.txt" />
</reference>


<reference target2="reference.RFC.3547.xml" anchor="RFC3547">
<front>
<title>The Group Domain of Interpretation</title>
<author fullname="M. Baugher" initials="M." surname="Baugher">
<organization />
</author>

<author fullname="B. Weis" initials="B." surname="Weis">
<organization />
</author>

<author fullname="T. Hardjono" initials="T." surname="Hardjono">
<organization />
</author>

<author fullname="H. Harney" initials="H." surname="Harney">
<organization />
</author>

<date year="2003" month="July" />
</front>

<seriesInfo value="3547" name="RFC" />
<format octets="108901" type="TXT" target="ftp://ftp.isi.edu/in-notes/rfc3547.txt" />
</reference>


<reference target2="reference.RFC.3548.xml" anchor="RFC3548">
<front>
<title>The Base16, Base32, and Base64 Data Encodings</title>
<author fullname="S. Josefsson" initials="S." surname="Josefsson">
<organization />
</author>

<date year="2003" month="July" />
</front>

<seriesInfo value="3548" name="RFC" />
<format octets="26363" type="TXT" target="ftp://ftp.isi.edu/in-notes/rfc3548.txt" />
</reference>


<reference target2="reference.RFC.3549.xml" anchor="RFC3549">
<front>
<title>Linux Netlink as an IP Services Protocol</title>
<author fullname="J. Salim" initials="J." surname="Salim">
<organization />
</author>

<author fullname="H. Khosravi" initials="H." surname="Khosravi">
<organization />
</author>

<author fullname="A. Kleen" initials="A." surname="Kleen">
<organization />
</author>

<author fullname="A. Kuznetsov" initials="A." surname="Kuznetsov">
<organization />
</author>

<date year="2003" month="July" />
</front>

<seriesInfo value="3549" name="RFC" />
<format octets="72161" type="TXT" target="ftp://ftp.isi.edu/in-notes/rfc3549.txt" />
</reference>


<reference target2="reference.RFC.3550.xml" anchor="RFC3550">
<front>
<title>RTP: A Transport Protocol for Real-Time Applications</title>
<author fullname="H. Schulzrinne" initials="H." surname="Schulzrinne">
<organization />
</author>

<author fullname="S. Casner" initials="S." surname="Casner">
<organization />
</author>

<author fullname="R. Frederick" initials="R." surname="Frederick">
<organization />
</author>

<author fullname="V. Jacobson" initials="V." surname="Jacobson">
<organization />
</author>

<date year="2003" month="July" />
</front>

<seriesInfo value="3550" name="RFC" />
<format octets="259985" type="TXT" target="ftp://ftp.isi.edu/in-notes/rfc3550.txt" />
<format octets="630740" type="PS" target="ftp://ftp.isi.edu/in-notes/rfc3550.ps" />
<format octets="504117" type="PDF" target="ftp://ftp.isi.edu/in-notes/rfc3550.pdf" />
</reference>


<reference target2="reference.RFC.3551.xml" anchor="RFC3551">
<front>
<title>RTP Profile for Audio and Video Conferences with Minimal Control</title>
<author fullname="H. Schulzrinne" initials="H." surname="Schulzrinne">
<organization />
</author>

<author fullname="S. Casner" initials="S." surname="Casner">
<organization />
</author>

<date year="2003" month="July" />
</front>

<seriesInfo value="3551" name="RFC" />
<format octets="106621" type="TXT" target="ftp://ftp.isi.edu/in-notes/rfc3551.txt" />
<format octets="317286" type="PS" target="ftp://ftp.isi.edu/in-notes/rfc3551.ps" />
<format octets="237831" type="PDF" target="ftp://ftp.isi.edu/in-notes/rfc3551.pdf" />
</reference>


<reference target2="reference.RFC.3552.xml" anchor="RFC3552">
<front>
<title>Guidelines for Writing RFC Text on Security Considerations</title>
<author fullname="E. Rescorla" initials="E." surname="Rescorla">
<organization />
</author>

<author fullname="B. Korver" initials="B." surname="Korver">
<organization />
</author>

<date year="2003" month="July" />
</front>

<seriesInfo value="72" name="BCP" />
<seriesInfo value="3552" name="RFC" />
<format octets="110393" type="TXT" target="ftp://ftp.isi.edu/in-notes/rfc3552.txt" />
</reference>


<reference target2="reference.RFC.3553.xml" anchor="RFC3553">
<front>
<title>An IETF URN Sub-namespace for Registered Protocol Parameters</title>
<author fullname="M. Mealling" initials="M." surname="Mealling">
<organization />
</author>

<author fullname="L. Masinter" initials="L." surname="Masinter">
<organization />
</author>

<author fullname="T. Hardie" initials="T." surname="Hardie">
<organization />
</author>

<author fullname="G. Klyne" initials="G." surname="Klyne">
<organization />
</author>

<date year="2003" month="June" />
</front>

<seriesInfo value="73" name="BCP" />
<seriesInfo value="3553" name="RFC" />
<format octets="14815" type="TXT" target="ftp://ftp.isi.edu/in-notes/rfc3553.txt" />
</reference>


<reference target2="reference.RFC.3554.xml" anchor="RFC3554">
<front>
<title>On the Use of Stream Control Transmission Protocol (SCTP) with IPsec</title>
<author fullname="S. Bellovin" initials="S." surname="Bellovin">
<organization />
</author>

<author fullname="J. Ioannidis" initials="J." surname="Ioannidis">
<organization />
</author>

<author fullname="A. Keromytis" initials="A." surname="Keromytis">
<organization />
</author>

<author fullname="R. Stewart" initials="R." surname="Stewart">
<organization />
</author>

<date year="2003" month="July" />
</front>

<seriesInfo value="3554" name="RFC" />
<format octets="20102" type="TXT" target="ftp://ftp.isi.edu/in-notes/rfc3554.txt" />
</reference>


<reference target2="reference.RFC.3555.xml" anchor="RFC3555">
<front>
<title>MIME Type Registration of RTP Payload Formats</title>
<author fullname="S. Casner" initials="S." surname="Casner">
<organization />
</author>

<author fullname="P. Hoschka" initials="P." surname="Hoschka">
<organization />
</author>

<date year="2003" month="July" />
</front>

<seriesInfo value="3555" name="RFC" />
<format octets="56618" type="TXT" target="ftp://ftp.isi.edu/in-notes/rfc3555.txt" />
</reference>


<reference target2="reference.RFC.3556.xml" anchor="RFC3556">
<front>
<title>Session Description Protocol (SDP) Bandwidth Modifiers for RTP Control Protocol (RTCP) Bandwidth</title>
<author fullname="S. Casner" initials="S." surname="Casner">
<organization />
</author>

<date year="2003" month="July" />
</front>

<seriesInfo value="3556" name="RFC" />
<format octets="15310" type="TXT" target="ftp://ftp.isi.edu/in-notes/rfc3556.txt" />
</reference>


<reference target2="reference.RFC.3557.xml" anchor="RFC3557">
<front>
<title>RTP Payload Format for European Telecommunications Standards Institute (ETSI) European Standard ES 201 108 Distributed Speech Recognition Encoding</title>
<author fullname="Q. Xie" initials="Q." surname="Xie">
<organization />
</author>

<date year="2003" month="July" />
</front>

<seriesInfo value="3557" name="RFC" />
<format octets="29692" type="TXT" target="ftp://ftp.isi.edu/in-notes/rfc3557.txt" />
</reference>


<reference target2="reference.RFC.3558.xml" anchor="RFC3558">
<front>
<title>RTP Payload Format for Enhanced Variable Rate Codecs (EVRC) and Selectable Mode Vocoders (SMV)</title>
<author fullname="A. Li" initials="A." surname="Li">
<organization />
</author>

<date year="2003" month="July" />
</front>

<seriesInfo value="3558" name="RFC" />
<format octets="49787" type="TXT" target="ftp://ftp.isi.edu/in-notes/rfc3558.txt" />
</reference>


<reference target2="reference.RFC.3559.xml" anchor="RFC3559">
<front>
<title>Multicast Address Allocation MIB</title>
<author fullname="D. Thaler" initials="D." surname="Thaler">
<organization />
</author>

<date year="2003" month="June" />
</front>

<seriesInfo value="3559" name="RFC" />
<format octets="68239" type="TXT" target="ftp://ftp.isi.edu/in-notes/rfc3559.txt" />
</reference>


<reference target2="reference.RFC.3560.xml" anchor="RFC3560">
<front>
<title>Use of the RSAES-OAEP Key Transport Algorithm in Cryptographic Message Syntax (CMS)</title>
<author fullname="R. Housley" initials="R." surname="Housley">
<organization />
</author>

<date year="2003" month="July" />
</front>

<seriesInfo value="3560" name="RFC" />
<format octets="37381" type="TXT" target="ftp://ftp.isi.edu/in-notes/rfc3560.txt" />
</reference>


<reference target2="reference.RFC.3561.xml" anchor="RFC3561">
<front>
<title>Ad hoc On-Demand Distance Vector (AODV) Routing</title>
<author fullname="C. Perkins" initials="C." surname="Perkins">
<organization />
</author>

<author fullname="E. Belding-Royer" initials="E." surname="Belding-Royer">
<organization />
</author>

<author fullname="S. Das" initials="S." surname="Das">
<organization />
</author>

<date year="2003" month="July" />
</front>

<seriesInfo value="3561" name="RFC" />
<format octets="90356" type="TXT" target="ftp://ftp.isi.edu/in-notes/rfc3561.txt" />
</reference>


<reference target2="reference.RFC.3562.xml" anchor="RFC3562">
<front>
<title>Key Management Considerations for the TCP MD5 Signature Option</title>
<author fullname="M. Leech" initials="M." surname="Leech">
<organization />
</author>

<date year="2003" month="July" />
</front>

<seriesInfo value="3562" name="RFC" />
<format octets="14965" type="TXT" target="ftp://ftp.isi.edu/in-notes/rfc3562.txt" />
</reference>


<reference target2="reference.RFC.3563.xml" anchor="RFC3563">
<front>
<title>Cooperative Agreement Between the ISOC/IETF and ISO/IEC Joint Technical Committee 1/Sub Committee 6 (JTC1/SC6) on IS-IS Routing Protocol Development</title>
<author fullname="A. Zinin" initials="A." surname="Zinin">
<organization />
</author>

<date year="2003" month="July" />
</front>

<seriesInfo value="3563" name="RFC" />
<format octets="14974" type="TXT" target="ftp://ftp.isi.edu/in-notes/rfc3563.txt" />
</reference>


<reference target2="reference.RFC.3564.xml" anchor="RFC3564">
<front>
<title>Requirements for Support of Differentiated Services-aware MPLS Traffic Engineering</title>
<author fullname="F. Le Faucheur" initials="F." surname="Le Faucheur">
<organization />
</author>

<author fullname="W. Lai" initials="W." surname="Lai">
<organization />
</author>

<date year="2003" month="July" />
</front>

<seriesInfo value="3564" name="RFC" />
<format octets="50808" type="TXT" target="ftp://ftp.isi.edu/in-notes/rfc3564.txt" />
</reference>


<reference target2="reference.RFC.3565.xml" anchor="RFC3565">
<front>
<title>Use of the Advanced Encryption Standard (AES) Encryption Algorithm in Cryptographic Message Syntax (CMS)</title>
<author fullname="J. Schaad" initials="J." surname="Schaad">
<organization />
</author>

<date year="2003" month="July" />
</front>

<seriesInfo value="3565" name="RFC" />
<format octets="26773" type="TXT" target="ftp://ftp.isi.edu/in-notes/rfc3565.txt" />
</reference>


<reference target2="reference.RFC.3566.xml" anchor="RFC3566">
<front>
<title>The AES-XCBC-MAC-96 Algorithm and Its Use With IPsec</title>
<author fullname="S. Frankel" initials="S." surname="Frankel">
<organization />
</author>

<author fullname="H. Herbert" initials="H." surname="Herbert">
<organization />
</author>

<date year="2003" month="September" />
</front>

<seriesInfo value="3566" name="RFC" />
<format octets="24645" type="TXT" target="ftp://ftp.isi.edu/in-notes/rfc3566.txt" />
</reference>


<reference target2="reference.RFC.3567.xml" anchor="RFC3567">
<front>
<title>Intermediate System to Intermediate System (IS-IS) Cryptographic Authentication</title>
<author fullname="T. Li" initials="T." surname="Li">
<organization />
</author>

<author fullname="R. Atkinson" initials="R." surname="Atkinson">
<organization />
</author>

<date year="2003" month="July" />
</front>

<seriesInfo value="3567" name="RFC" />
<format octets="13467" type="TXT" target="ftp://ftp.isi.edu/in-notes/rfc3567.txt" />
</reference>


<reference target2="reference.RFC.3568.xml" anchor="RFC3568">
<front>
<title>Known Content Network (CN) Request-Routing Mechanisms</title>
<author fullname="A. Barbir" initials="A." surname="Barbir">
<organization />
</author>

<author fullname="B. Cain" initials="B." surname="Cain">
<organization />
</author>

<author fullname="R. Nair" initials="R." surname="Nair">
<organization />
</author>

<author fullname="O. Spatscheck" initials="O." surname="Spatscheck">
<organization />
</author>

<date year="2003" month="July" />
</front>

<seriesInfo value="3568" name="RFC" />
<format octets="42443" type="TXT" target="ftp://ftp.isi.edu/in-notes/rfc3568.txt" />
</reference>


<reference target2="reference.RFC.3569.xml" anchor="RFC3569">
<front>
<title>An Overview of Source-Specific Multicast (SSM)</title>
<author fullname="S. Bhattacharyya" initials="S." surname="Bhattacharyya">
<organization />
</author>

<date year="2003" month="July" />
</front>

<seriesInfo value="3569" name="RFC" />
<format octets="29387" type="TXT" target="ftp://ftp.isi.edu/in-notes/rfc3569.txt" />
</reference>


<reference target2="reference.RFC.3570.xml" anchor="RFC3570">
<front>
<title>Content Internetworking (CDI) Scenarios</title>
<author fullname="P. Rzewski" initials="P." surname="Rzewski">
<organization />
</author>

<author fullname="M. Day" initials="M." surname="Day">
<organization />
</author>

<author fullname="D. Gilletti" initials="D." surname="Gilletti">
<organization />
</author>

<date year="2003" month="July" />
</front>

<seriesInfo value="3570" name="RFC" />
<format octets="42432" type="TXT" target="ftp://ftp.isi.edu/in-notes/rfc3570.txt" />
</reference>


<reference target2="reference.RFC.3571.xml" anchor="RFC3571">
<front>
<title>Framework Policy Information Base for Usage Feedback</title>
<author fullname="D. Rawlins" initials="D." surname="Rawlins">
<organization />
</author>

<author fullname="A. Kulkarni" initials="A." surname="Kulkarni">
<organization />
</author>

<author fullname="K. Ho Chan" initials="K." surname="Ho Chan">
<organization />
</author>

<author fullname="M. Bokaemper" initials="M." surname="Bokaemper">
<organization />
</author>

<author fullname="D. Dutt" initials="D." surname="Dutt">
<organization />
</author>

<date year="2003" month="August" />
</front>

<seriesInfo value="3571" name="RFC" />
<format octets="70894" type="TXT" target="ftp://ftp.isi.edu/in-notes/rfc3571.txt" />
</reference>


<reference target2="reference.RFC.3572.xml" anchor="RFC3572">
<front>
<title>Internet Protocol Version 6 over MAPOS (Multiple Access Protocol Over SONET/SDH)</title>
<author fullname="T. Ogura" initials="T." surname="Ogura">
<organization />
</author>

<author fullname="M. Maruyama" initials="M." surname="Maruyama">
<organization />
</author>

<author fullname="T. Yoshida" initials="T." surname="Yoshida">
<organization />
</author>

<date year="2003" month="July" />
</front>

<seriesInfo value="3572" name="RFC" />
<format octets="30607" type="TXT" target="ftp://ftp.isi.edu/in-notes/rfc3572.txt" />
</reference>


<reference target2="reference.RFC.3573.xml" anchor="RFC3573">
<front>
<title>Signalling of Modem-On-Hold status in Layer 2 Tunneling Protocol (L2TP)</title>
<author fullname="I. Goyret" initials="I." surname="Goyret">
<organization />
</author>

<date year="2003" month="July" />
</front>

<seriesInfo value="3573" name="RFC" />
<format octets="22758" type="TXT" target="ftp://ftp.isi.edu/in-notes/rfc3573.txt" />
</reference>


<reference target2="reference.RFC.3574.xml" anchor="RFC3574">
<front>
<title>Transition Scenarios for 3GPP Networks</title>
<author fullname="J. Soininen" initials="J." surname="Soininen">
<organization />
</author>

<date year="2003" month="August" />
</front>

<seriesInfo value="3574" name="RFC" />
<format octets="23359" type="TXT" target="ftp://ftp.isi.edu/in-notes/rfc3574.txt" />
</reference>


<reference target2="reference.RFC.3575.xml" anchor="RFC3575">
<front>
<title>IANA Considerations for RADIUS (Remote Authentication Dial In User Service)</title>
<author fullname="B. Aboba" initials="B." surname="Aboba">
<organization />
</author>

<date year="2003" month="July" />
</front>

<seriesInfo value="3575" name="RFC" />
<format octets="15539" type="TXT" target="ftp://ftp.isi.edu/in-notes/rfc3575.txt" />
</reference>


<reference target2="reference.RFC.3576.xml" anchor="RFC3576">
<front>
<title>Dynamic Authorization Extensions to Remote Authentication Dial In User Service (RADIUS)</title>
<author fullname="M. Chiba" initials="M." surname="Chiba">
<organization />
</author>

<author fullname="G. Dommety" initials="G." surname="Dommety">
<organization />
</author>

<author fullname="M. Eklund" initials="M." surname="Eklund">
<organization />
</author>

<author fullname="D. Mitton" initials="D." surname="Mitton">
<organization />
</author>

<author fullname="B. Aboba" initials="B." surname="Aboba">
<organization />
</author>

<date year="2003" month="July" />
</front>

<seriesInfo value="3576" name="RFC" />
<format octets="70027" type="TXT" target="ftp://ftp.isi.edu/in-notes/rfc3576.txt" />
</reference>


<reference target2="reference.RFC.3577.xml" anchor="RFC3577">
<front>
<title>Introduction to the Remote Monitoring (RMON) Family of MIB Modules</title>
<author fullname="S. Waldbusser" initials="S." surname="Waldbusser">
<organization />
</author>

<author fullname="R. Cole" initials="R." surname="Cole">
<organization />
</author>

<author fullname="C. Kalbfleisch" initials="C." surname="Kalbfleisch">
<organization />
</author>

<author fullname="D. Romascanu" initials="D." surname="Romascanu">
<organization />
</author>

<date year="2003" month="August" />
</front>

<seriesInfo value="3577" name="RFC" />
<format octets="68551" type="TXT" target="ftp://ftp.isi.edu/in-notes/rfc3577.txt" />
</reference>


<reference target2="reference.RFC.3578.xml" anchor="RFC3578">
<front>
<title>Mapping of Integrated Services Digital Network (ISDN) User Part (ISUP) Overlap Signalling to the Session Initiation Protocol (SIP)</title>
<author fullname="G. Camarillo" initials="G." surname="Camarillo">
<organization />
</author>

<author fullname="A.B. Roach" initials="A.B." surname="Roach">
<organization />
</author>

<author fullname="J. Peterson" initials="J." surname="Peterson">
<organization />
</author>

<author fullname="L. Ong" initials="L." surname="Ong">
<organization />
</author>

<date year="2003" month="August" />
</front>

<seriesInfo value="3578" name="RFC" />
<format octets="26667" type="TXT" target="ftp://ftp.isi.edu/in-notes/rfc3578.txt" />
</reference>


<reference target2="reference.RFC.3579.xml" anchor="RFC3579">
<front>
<title>RADIUS (Remote Authentication Dial In User Service) Support For Extensible Authentication Protocol (EAP)</title>
<author fullname="B. Aboba" initials="B." surname="Aboba">
<organization />
</author>

<author fullname="P. Calhoun" initials="P." surname="Calhoun">
<organization />
</author>

<date year="2003" month="September" />
</front>

<seriesInfo value="3579" name="RFC" />
<format octets="104469" type="TXT" target="ftp://ftp.isi.edu/in-notes/rfc3579.txt" />
</reference>


<reference target2="reference.RFC.3580.xml" anchor="RFC3580">
<front>
<title>IEEE 802.1X Remote Authentication Dial In User Service (RADIUS) Usage Guidelines</title>
<author fullname="P. Congdon" initials="P." surname="Congdon">
<organization />
</author>

<author fullname="B. Aboba" initials="B." surname="Aboba">
<organization />
</author>

<author fullname="A. Smith" initials="A." surname="Smith">
<organization />
</author>

<author fullname="G. Zorn" initials="G." surname="Zorn">
<organization />
</author>

<author fullname="J. Roese" initials="J." surname="Roese">
<organization />
</author>

<date year="2003" month="September" />
</front>

<seriesInfo value="3580" name="RFC" />
<format octets="66136" type="TXT" target="ftp://ftp.isi.edu/in-notes/rfc3580.txt" />
</reference>


<reference target2="reference.RFC.3581.xml" anchor="RFC3581">
<front>
<title>An Extension to the Session Initiation Protocol (SIP) for Symmetric Response Routing</title>
<author fullname="J. Rosenberg" initials="J." surname="Rosenberg">
<organization />
</author>

<author fullname="H. Schulzrinne" initials="H." surname="Schulzrinne">
<organization />
</author>

<date year="2003" month="August" />
</front>

<seriesInfo value="3581" name="RFC" />
<format octets="66133" type="TXT" target="ftp://ftp.isi.edu/in-notes/rfc3581.txt" />
</reference>


<reference target2="reference.RFC.3582.xml" anchor="RFC3582">
<front>
<title>Goals for IPv6 Site-Multihoming Architectures</title>
<author fullname="J. Abley" initials="J." surname="Abley">
<organization />
</author>

<author fullname="B. Black" initials="B." surname="Black">
<organization />
</author>

<author fullname="V. Gill" initials="V." surname="Gill">
<organization />
</author>

<date year="2003" month="August" />
</front>

<seriesInfo value="3582" name="RFC" />
<format octets="17045" type="TXT" target="ftp://ftp.isi.edu/in-notes/rfc3582.txt" />
</reference>


<reference target2="reference.RFC.3583.xml" anchor="RFC3583">
<front>
<title>Requirements of a Quality of Service (QoS) Solution for Mobile IP</title>
<author fullname="H. Chaskar" initials="H." surname="Chaskar">
<organization />
</author>

<date year="2003" month="September" />
</front>

<seriesInfo value="3583" name="RFC" />
<format octets="22541" type="TXT" target="ftp://ftp.isi.edu/in-notes/rfc3583.txt" />
</reference>


<reference target2="reference.RFC.3584.xml" anchor="RFC3584">
<front>
<title>Coexistence between Version 1, Version 2, and Version 3 of the Internet-standard Network Management Framework</title>
<author fullname="R. Frye" initials="R." surname="Frye">
<organization />
</author>

<author fullname="D. Levi" initials="D." surname="Levi">
<organization />
</author>

<author fullname="S. Routhier" initials="S." surname="Routhier">
<organization />
</author>

<author fullname="B. Wijnen" initials="B." surname="Wijnen">
<organization />
</author>

<date year="2003" month="August" />
</front>

<seriesInfo value="74" name="BCP" />
<seriesInfo value="3584" name="RFC" />
<format octets="115222" type="TXT" target="ftp://ftp.isi.edu/in-notes/rfc3584.txt" />
</reference>


<reference target2="reference.RFC.3585.xml" anchor="RFC3585">
<front>
<title>IPsec Configuration Policy Information Model</title>
<author fullname="J. Jason" initials="J." surname="Jason">
<organization />
</author>

<author fullname="L. Rafalow" initials="L." surname="Rafalow">
<organization />
</author>

<author fullname="E. Vyncke" initials="E." surname="Vyncke">
<organization />
</author>

<date year="2003" month="August" />
</front>

<seriesInfo value="3585" name="RFC" />
<format octets="187308" type="TXT" target="ftp://ftp.isi.edu/in-notes/rfc3585.txt" />
</reference>


<reference target2="reference.RFC.3586.xml" anchor="RFC3586">
<front>
<title>IP Security Policy (IPSP) Requirements</title>
<author fullname="M. Blaze" initials="M." surname="Blaze">
<organization />
</author>

<author fullname="A. Keromytis" initials="A." surname="Keromytis">
<organization />
</author>

<author fullname="M. Richardson" initials="M." surname="Richardson">
<organization />
</author>

<author fullname="L. Sanchez" initials="L." surname="Sanchez">
<organization />
</author>

<date year="2003" month="August" />
</front>

<seriesInfo value="3586" name="RFC" />
<format octets="22068" type="TXT" target="ftp://ftp.isi.edu/in-notes/rfc3586.txt" />
</reference>


<reference target2="reference.RFC.3587.xml" anchor="RFC3587">
<front>
<title>IPv6 Global Unicast Address Format</title>
<author fullname="R. Hinden" initials="R." surname="Hinden">
<organization />
</author>

<author fullname="S. Deering" initials="S." surname="Deering">
<organization />
</author>

<author fullname="E. Nordmark" initials="E." surname="Nordmark">
<organization />
</author>

<date year="2003" month="August" />
</front>

<seriesInfo value="3587" name="RFC" />
<format octets="8783" type="TXT" target="ftp://ftp.isi.edu/in-notes/rfc3587.txt" />
</reference>


<reference target2="reference.RFC.3588.xml" anchor="RFC3588">
<front>
<title>Diameter Base Protocol</title>
<author fullname="P. Calhoun" initials="P." surname="Calhoun">
<organization />
</author>

<author fullname="J. Loughney" initials="J." surname="Loughney">
<organization />
</author>

<author fullname="E. Guttman" initials="E." surname="Guttman">
<organization />
</author>

<author fullname="G. Zorn" initials="G." surname="Zorn">
<organization />
</author>

<author fullname="J. Arkko" initials="J." surname="Arkko">
<organization />
</author>

<date year="2003" month="September" />
</front>

<seriesInfo value="3588" name="RFC" />
<format octets="341261" type="TXT" target="ftp://ftp.isi.edu/in-notes/rfc3588.txt" />
</reference>


<reference target2="reference.RFC.3589.xml" anchor="RFC3589">
<front>
<title>Diameter Command Codes for Third Generation Partnership Project (3GPP) Release 5</title>
<author fullname="J. Loughney" initials="J." surname="Loughney">
<organization />
</author>

<date year="2003" month="September" />
</front>

<seriesInfo value="3589" name="RFC" />
<format octets="8010" type="TXT" target="ftp://ftp.isi.edu/in-notes/rfc3589.txt" />
</reference>


<reference target2="reference.RFC.3590.xml" anchor="RFC3590">
<front>
<title>Source Address Selection for the Multicast Listener Discovery (MLD) Protocol</title>
<author fullname="B. Haberman" initials="B." surname="Haberman">
<organization />
</author>

<date year="2003" month="September" />
</front>

<seriesInfo value="3590" name="RFC" />
<format octets="11554" type="TXT" target="ftp://ftp.isi.edu/in-notes/rfc3590.txt" />
</reference>


<reference target2="reference.RFC.3591.xml" anchor="RFC3591">
<front>
<title>Definitions of Managed Objects for the Optical Interface Type</title>
<author fullname="H-K. Lam" initials="H-K." surname="Lam">
<organization />
</author>

<author fullname="M. Stewart" initials="M." surname="Stewart">
<organization />
</author>

<author fullname="A. Huynh" initials="A." surname="Huynh">
<organization />
</author>

<date year="2003" month="September" />
</front>

<seriesInfo value="3591" name="RFC" />
<format octets="310815" type="TXT" target="ftp://ftp.isi.edu/in-notes/rfc3591.txt" />
</reference>


<reference target2="reference.RFC.3592.xml" anchor="RFC3592">
<front>
<title>Definitions of Managed Objects for the Synchronous Optical Network/Synchronous Digital Hierarchy (SONET/SDH) Interface Type</title>
<author fullname="K. Tesink" initials="K." surname="Tesink">
<organization />
</author>

<date year="2003" month="September" />
</front>

<seriesInfo value="3592" name="RFC" />
<format octets="143588" type="TXT" target="ftp://ftp.isi.edu/in-notes/rfc3592.txt" />
</reference>


<reference target2="reference.RFC.3593.xml" anchor="RFC3593">
<front>
<title>Textual Conventions for MIB Modules Using Performance History Based on 15 Minute Intervals</title>
<author fullname="K. Tesink" initials="K." surname="Tesink">
<organization />
</author>

<date year="2003" month="September" />
</front>

<seriesInfo value="3593" name="RFC" />
<format octets="20363" type="TXT" target="ftp://ftp.isi.edu/in-notes/rfc3593.txt" />
</reference>


<reference target2="reference.RFC.3594.xml" anchor="RFC3594">
<front>
<title>PacketCable Security Ticket Control Sub-Option for the DHCP CableLabs Client Configuration (CCC) Option</title>
<author fullname="P. Duffy" initials="P." surname="Duffy">
<organization />
</author>

<date year="2003" month="September" />
</front>

<seriesInfo value="3594" name="RFC" />
<format octets="12521" type="TXT" target="ftp://ftp.isi.edu/in-notes/rfc3594.txt" />
</reference>


<reference target2="reference.RFC.3595.xml" anchor="RFC3595">
<front>
<title>Textual Conventions for IPv6 Flow Label</title>
<author fullname="B. Wijnen" initials="B." surname="Wijnen">
<organization />
</author>

<date year="2003" month="September" />
</front>

<seriesInfo value="3595" name="RFC" />
<format octets="11746" type="TXT" target="ftp://ftp.isi.edu/in-notes/rfc3595.txt" />
</reference>


<reference target2="reference.RFC.3596.xml" anchor="RFC3596">
<front>
<title>DNS Extensions to Support IP Version 6</title>
<author fullname="S. Thomson" initials="S." surname="Thomson">
<organization />
</author>

<author fullname="C. Huitema" initials="C." surname="Huitema">
<organization />
</author>

<author fullname="V. Ksinant" initials="V." surname="Ksinant">
<organization />
</author>

<author fullname="M. Souissi" initials="M." surname="Souissi">
<organization />
</author>

<date year="2003" month="October" />
</front>

<seriesInfo value="3596" name="RFC" />
<format octets="14093" type="TXT" target="ftp://ftp.isi.edu/in-notes/rfc3596.txt" />
</reference>


<reference target2="reference.RFC.3597.xml" anchor="RFC3597">
<front>
<title>Handling of Unknown DNS Resource Record (RR) Types</title>
<author fullname="A. Gustafsson" initials="A." surname="Gustafsson">
<organization />
</author>

<date year="2003" month="September" />
</front>

<seriesInfo value="3597" name="RFC" />
<format octets="17559" type="TXT" target="ftp://ftp.isi.edu/in-notes/rfc3597.txt" />
</reference>


<reference target2="reference.RFC.3598.xml" anchor="RFC3598">
<front>
<title>Sieve Email Filtering -- Subaddress Extension</title>
<author fullname="K. Murchison" initials="K." surname="Murchison">
<organization />
</author>

<date year="2003" month="September" />
</front>

<seriesInfo value="3598" name="RFC" />
<format octets="11151" type="TXT" target="ftp://ftp.isi.edu/in-notes/rfc3598.txt" />
</reference>


<reference target2="reference.RFC.3599.xml" anchor="RFC3599">
<front>
<title>Request for Comments Summary RFC Numbers 3500-3599</title>
<author fullname="S. Ginoza" initials="S." surname="Ginoza">
<organization />
</author>

<date year="2003" month="December" />
</front>

<seriesInfo value="3599" name="RFC" />
<format octets="76893" type="TXT" target="ftp://ftp.isi.edu/in-notes/rfc3599.txt" />
</reference>


<reference target2="reference.RFC.3600.xml" anchor="RFC3600">
<front>
<title>Internet Official Protocol Standards</title>
<author fullname="J. Reynolds" initials="J." surname="Reynolds">
<organization />
</author>

<author fullname="S. Ginoza" initials="S." surname="Ginoza">
<organization />
</author>

<date year="2003" month="November" />
</front>

<seriesInfo value="1" name="STD" />
<seriesInfo value="3600" name="RFC" />
<format octets="134338" type="TXT" target="ftp://ftp.isi.edu/in-notes/rfc3600.txt" />
</reference>


<reference target2="reference.RFC.3601.xml" anchor="RFC3601">
<front>
<title>Text String Notation for Dial Sequences and Global Switched Telephone Network (GSTN) / E.164 Addresses</title>
<author fullname="C. Allocchio" initials="C." surname="Allocchio">
<organization />
</author>

<date year="2003" month="September" />
</front>

<seriesInfo value="3601" name="RFC" />
<format octets="18572" type="TXT" target="ftp://ftp.isi.edu/in-notes/rfc3601.txt" />
</reference>


<reference target2="reference.RFC.3602.xml" anchor="RFC3602">
<front>
<title>The AES-CBC Cipher Algorithm and Its Use with IPsec</title>
<author fullname="S. Frankel" initials="S." surname="Frankel">
<organization />
</author>

<author fullname="R. Glenn" initials="R." surname="Glenn">
<organization />
</author>

<author fullname="S. Kelly" initials="S." surname="Kelly">
<organization />
</author>

<date year="2003" month="September" />
</front>

<seriesInfo value="3602" name="RFC" />
<format octets="30254" type="TXT" target="ftp://ftp.isi.edu/in-notes/rfc3602.txt" />
</reference>


<reference target2="reference.RFC.3603.xml" anchor="RFC3603">
<front>
<title>Private Session Initiation Protocol (SIP) Proxy-to-Proxy Extensions for Supporting the PacketCable Distributed Call Signaling Architecture</title>
<author fullname="W. Marshall" initials="W." surname="Marshall">
<organization />
</author>

<author fullname="F. Andreasen" initials="F." surname="Andreasen">
<organization />
</author>

<date year="2003" month="October" />
</front>

<seriesInfo value="3603" name="RFC" />
<format octets="67509" type="TXT" target="ftp://ftp.isi.edu/in-notes/rfc3603.txt" />
</reference>


<reference target2="reference.RFC.3604.xml" anchor="RFC3604">
<front>
<title>Requirements for Adding Optical Support to the General Switch Management Protocol version 3 (GSMPv3)</title>
<author fullname="H. Khosravi" initials="H." surname="Khosravi">
<organization />
</author>

<author fullname="G. Kullgren" initials="G." surname="Kullgren">
<organization />
</author>

<author fullname="S. Shew" initials="S." surname="Shew">
<organization />
</author>

<author fullname="J. Sadler" initials="J." surname="Sadler">
<organization />
</author>

<author fullname="A. Watanabe" initials="A." surname="Watanabe">
<organization />
</author>

<date year="2003" month="October" />
</front>

<seriesInfo value="3604" name="RFC" />
<format octets="30805" type="TXT" target="ftp://ftp.isi.edu/in-notes/rfc3604.txt" />
</reference>


<reference target2="reference.RFC.3605.xml" anchor="RFC3605">
<front>
<title>Real Time Control Protocol (RTCP) attribute in Session Description Protocol (SDP)</title>
<author fullname="C. Huitema" initials="C." surname="Huitema">
<organization />
</author>

<date year="2003" month="October" />
</front>

<seriesInfo value="3605" name="RFC" />
<format octets="17270" type="TXT" target="ftp://ftp.isi.edu/in-notes/rfc3605.txt" />
</reference>


<reference target2="reference.RFC.3606.xml" anchor="RFC3606">
<front>
<title>Definitions of Supplemental Managed Objects for ATM Interface</title>
<author fullname="F. Ly" initials="F." surname="Ly">
<organization />
</author>

<author fullname="M. Noto" initials="M." surname="Noto">
<organization />
</author>

<author fullname="A. Smith" initials="A." surname="Smith">
<organization />
</author>

<author fullname="E. Spiegel" initials="E." surname="Spiegel">
<organization />
</author>

<author fullname="K. Tesink" initials="K." surname="Tesink">
<organization />
</author>

<date year="2003" month="November" />
</front>

<seriesInfo value="3606" name="RFC" />
<format octets="183610" type="TXT" target="ftp://ftp.isi.edu/in-notes/rfc3606.txt" />
</reference>


<reference target2="reference.RFC.3607.xml" anchor="RFC3607">
<front>
<title>Chinese Lottery Cryptanalysis Revisited: The Internet as a Codebreaking Tool</title>
<author fullname="M. Leech" initials="M." surname="Leech">
<organization />
</author>

<date year="2003" month="September" />
</front>

<seriesInfo value="3607" name="RFC" />
<format octets="14526" type="TXT" target="ftp://ftp.isi.edu/in-notes/rfc3607.txt" />
</reference>


<reference target2="reference.RFC.3608.xml" anchor="RFC3608">
<front>
<title>Session Initiation Protocol (SIP) Extension Header Field for Service Route Discovery During Registration</title>
<author fullname="D. Willis" initials="D." surname="Willis">
<organization />
</author>

<author fullname="B. Hoeneisen" initials="B." surname="Hoeneisen">
<organization />
</author>

<date year="2003" month="October" />
</front>

<seriesInfo value="3608" name="RFC" />
<format octets="35628" type="TXT" target="ftp://ftp.isi.edu/in-notes/rfc3608.txt" />
</reference>


<reference target2="reference.RFC.3609.xml" anchor="RFC3609">
<front>
<title>Tracing Requirements for Generic Tunnels</title>
<author fullname="R. Bonica" initials="R." surname="Bonica">
<organization />
</author>

<author fullname="K. Kompella" initials="K." surname="Kompella">
<organization />
</author>

<author fullname="D. Meyer" initials="D." surname="Meyer">
<organization />
</author>

<date year="2003" month="September" />
</front>

<seriesInfo value="3609" name="RFC" />
<format octets="17859" type="TXT" target="ftp://ftp.isi.edu/in-notes/rfc3609.txt" />
</reference>


<reference target2="reference.RFC.3610.xml" anchor="RFC3610">
<front>
<title>Counter with CBC-MAC (CCM)</title>
<author fullname="D. Whiting" initials="D." surname="Whiting">
<organization />
</author>

<author fullname="R. Housley" initials="R." surname="Housley">
<organization />
</author>

<author fullname="N. Ferguson" initials="N." surname="Ferguson">
<organization />
</author>

<date year="2003" month="September" />
</front>

<seriesInfo value="3610" name="RFC" />
<format octets="64509" type="TXT" target="ftp://ftp.isi.edu/in-notes/rfc3610.txt" />
</reference>


<reference target2="reference.RFC.3611.xml" anchor="RFC3611">
<front>
<title>RTP Control Protocol Extended Reports (RTCP XR)</title>
<author fullname="T. Friedman" initials="T." surname="Friedman">
<organization />
</author>

<author fullname="R. Caceres" initials="R." surname="Caceres">
<organization />
</author>

<author fullname="A. Clark" initials="A." surname="Clark">
<organization />
</author>

<date year="2003" month="November" />
</front>

<seriesInfo value="3611" name="RFC" />
<format octets="126736" type="TXT" target="ftp://ftp.isi.edu/in-notes/rfc3611.txt" />
</reference>


<reference target2="reference.RFC.3612.xml" anchor="RFC3612">
<front>
<title>Applicability Statement for Restart Mechanisms for the Label Distribution Protocol (LDP)</title>
<author fullname="A. Farrel" initials="A." surname="Farrel">
<organization />
</author>

<date year="2003" month="September" />
</front>

<seriesInfo value="3612" name="RFC" />
<format octets="35677" type="TXT" target="ftp://ftp.isi.edu/in-notes/rfc3612.txt" />
</reference>


<reference target2="reference.RFC.3613.xml" anchor="RFC3613">
<front>
<title>Definition of a Uniform Resource Name (URN) Namespace for the Middleware Architecture Committee for Education (MACE)</title>
<author fullname="R. Morgan" initials="R." surname="Morgan">
<organization />
</author>

<author fullname="K. Hazelton" initials="K." surname="Hazelton">
<organization />
</author>

<date year="2003" month="October" />
</front>

<seriesInfo value="3613" name="RFC" />
<format octets="14296" type="TXT" target="ftp://ftp.isi.edu/in-notes/rfc3613.txt" />
</reference>


<reference target2="reference.RFC.3614.xml" anchor="RFC3614">
<front>
<title>A Uniform Resource Name (URN) Namespace for the Motion Picture Experts Group (MPEG)</title>
<author fullname="J. Smith" initials="J." surname="Smith">
<organization />
</author>

<date year="2003" month="September" />
</front>

<seriesInfo value="3614" name="RFC" />
<format octets="10457" type="TXT" target="ftp://ftp.isi.edu/in-notes/rfc3614.txt" />
</reference>


<reference target2="reference.RFC.3615.xml" anchor="RFC3615">
<front>
<title>A Uniform Resource Name (URN) Namespace for SWIFT Financial Messaging</title>
<author fullname="J. Gustin" initials="J." surname="Gustin">
<organization />
</author>

<author fullname="A. Goyens" initials="A." surname="Goyens">
<organization />
</author>

<date year="2003" month="September" />
</front>

<seriesInfo value="3615" name="RFC" />
<format octets="7352" type="TXT" target="ftp://ftp.isi.edu/in-notes/rfc3615.txt" />
</reference>


<reference target2="reference.RFC.3616.xml" anchor="RFC3616">
<front>
<title>A Uniform Resource Name (URN) Namespace for Foundation for Intelligent Physical Agents (FIPA)</title>
<author fullname="F. Bellifemine" initials="F." surname="Bellifemine">
<organization />
</author>

<author fullname="I. Constantinescu" initials="I." surname="Constantinescu">
<organization />
</author>

<author fullname="S. Willmott" initials="S." surname="Willmott">
<organization />
</author>

<date year="2003" month="September" />
</front>

<seriesInfo value="3616" name="RFC" />
<format octets="13352" type="TXT" target="ftp://ftp.isi.edu/in-notes/rfc3616.txt" />
</reference>


<reference target2="reference.RFC.3617.xml" anchor="RFC3617">
<front>
<title>Uniform Resource Identifier (URI) Scheme and Applicability Statement for the Trivial File Transfer Protocol (TFTP)</title>
<author fullname="E. Lear" initials="E." surname="Lear">
<organization />
</author>

<date year="2003" month="October" />
</front>

<seriesInfo value="3617" name="RFC" />
<format octets="11848" type="TXT" target="ftp://ftp.isi.edu/in-notes/rfc3617.txt" />
</reference>


<reference target2="reference.RFC.3618.xml" anchor="RFC3618">
<front>
<title>Multicast Source Discovery Protocol (MSDP)</title>
<author fullname="B. Fenner" initials="B." surname="Fenner">
<organization />
</author>

<author fullname="D. Meyer" initials="D." surname="Meyer">
<organization />
</author>

<date year="2003" month="October" />
</front>

<seriesInfo value="3618" name="RFC" />
<format octets="42238" type="TXT" target="ftp://ftp.isi.edu/in-notes/rfc3618.txt" />
</reference>


<reference target2="reference.RFC.3619.xml" anchor="RFC3619">
<front>
<title>Extreme Networks' Ethernet Automatic Protection Switching (EAPS) Version 1</title>
<author fullname="S. Shah" initials="S." surname="Shah">
<organization />
</author>

<author fullname="M. Yip" initials="M." surname="Yip">
<organization />
</author>

<date year="2003" month="October" />
</front>

<seriesInfo value="3619" name="RFC" />
<format octets="14440" type="TXT" target="ftp://ftp.isi.edu/in-notes/rfc3619.txt" />
</reference>


<reference target2="reference.RFC.3620.xml" anchor="RFC3620">
<front>
<title abbrev="TUNNEL Profile">The TUNNEL Profile</title>
<author fullname="Darren New" initials="D." surname="New">
<organization />

<address>
<postal>
<street>5390 Caminito Exquisito</street>
<city>San Diego</city>
<region>CA</region>
<code>92130</code>
<country>US</country>
</postal>

<phone>+1 858 350 9733</phone>
<email>dnew@san.rr.com</email>
</address>
</author>

<date year="2003" month="October" />
<area>Security</area>
<keyword>BEEP</keyword>
<keyword>firewall</keyword>
<keyword>proxy</keyword>

<abstract>
<t>This memo describes a BEEP profile that allows a BEEP peer to
serve as an application-layer proxy.  It allows authorized users to access
services through a firewall.</t>
</abstract>
</front>

<seriesInfo value="3620" name="RFC" />
<format octets="35365" type="TXT" target="ftp://ftp.isi.edu/in-notes/rfc3620.txt" />
<format octets="46485" type="HTML" target="http://xml.resource.org/public/rfc/html/rfc3620.html" />
<format octets="41521" type="XML" target="http://xml.resource.org/public/rfc/xml/rfc3620.xml" />
</reference>


<reference target2="reference.RFC.3621.xml" anchor="RFC3621">
<front>
<title>Power Ethernet MIB</title>
<author fullname="A. Berger" initials="A." surname="Berger">
<organization />
</author>

<author fullname="D. Romascanu" initials="D." surname="Romascanu">
<organization />
</author>

<date year="2003" month="December" />
</front>

<seriesInfo value="3621" name="RFC" />
<format octets="37294" type="TXT" target="ftp://ftp.isi.edu/in-notes/rfc3621.txt" />
</reference>


<reference target2="reference.RFC.3623.xml" anchor="RFC3623">
<front>
<title>Graceful OSPF Restart</title>
<author fullname="J. Moy" initials="J." surname="Moy">
<organization />
</author>

<author fullname="P. Pillay-Esnault" initials="P." surname="Pillay-Esnault">
<organization />
</author>

<author fullname="A. Lindem" initials="A." surname="Lindem">
<organization />
</author>

<date year="2003" month="November" />
</front>

<seriesInfo value="3623" name="RFC" />
<format octets="38757" type="TXT" target="ftp://ftp.isi.edu/in-notes/rfc3623.txt" />
</reference>


<reference target2="reference.RFC.3624.xml" anchor="RFC3624">
<front>
<title>The Media Gateway Control Protocol (MGCP) Bulk Audit Package</title>
<author fullname="B. Foster" initials="B." surname="Foster">
<organization />
</author>

<author fullname="D. Auerbach" initials="D." surname="Auerbach">
<organization />
</author>

<author fullname="F. Andreasen" initials="F." surname="Andreasen">
<organization />
</author>

<date year="2003" month="November" />
</front>

<seriesInfo value="3624" name="RFC" />
<format octets="34391" type="TXT" target="ftp://ftp.isi.edu/in-notes/rfc3624.txt" />
</reference>


<reference target2="reference.RFC.3625.xml" anchor="RFC3625">
<front>
<title>The QCP File Format and Media Types for Speech Data</title>
<author fullname="R. Gellens" initials="R." surname="Gellens">
<organization />
</author>

<author fullname="H. Garudadri" initials="H." surname="Garudadri">
<organization />
</author>

<date year="2003" month="September" />
</front>

<seriesInfo value="3625" name="RFC" />
<format octets="28603" type="TXT" target="ftp://ftp.isi.edu/in-notes/rfc3625.txt" />
</reference>


<reference target2="reference.RFC.3626.xml" anchor="RFC3626">
<front>
<title>Optimized Link State Routing Protocol (OLSR)</title>
<author fullname="T. Clausen" initials="T." surname="Clausen">
<organization />
</author>

<author fullname="P. Jacquet" initials="P." surname="Jacquet">
<organization />
</author>

<date year="2003" month="October" />
</front>

<seriesInfo value="3626" name="RFC" />
<format octets="161265" type="TXT" target="ftp://ftp.isi.edu/in-notes/rfc3626.txt" />
</reference>


<reference target2="reference.RFC.3627.xml" anchor="RFC3627">
<front>
<title>Use of /127 Prefix Length Between Routers Considered Harmful</title>
<author fullname="P. Savola" initials="P." surname="Savola">
<organization />
</author>

<date year="2003" month="September" />
</front>

<seriesInfo value="3627" name="RFC" />
<format octets="12436" type="TXT" target="ftp://ftp.isi.edu/in-notes/rfc3627.txt" />
</reference>


<reference target2="reference.RFC.3628.xml" anchor="RFC3628">
<front>
<title>Policy Requirements for Time-Stamping Authorities (TSAs)</title>
<author fullname="D. Pinkas" initials="D." surname="Pinkas">
<organization />
</author>

<author fullname="N. Pope" initials="N." surname="Pope">
<organization />
</author>

<author fullname="J. Ross" initials="J." surname="Ross">
<organization />
</author>

<date year="2003" month="November" />
</front>

<seriesInfo value="3628" name="RFC" />
<format octets="92941" type="TXT" target="ftp://ftp.isi.edu/in-notes/rfc3628.txt" />
</reference>


<reference target2="reference.RFC.3629.xml" anchor="RFC3629">
<front>
<title>UTF-8, a transformation format of ISO 10646</title>
<author fullname="F. Yergeau" initials="F." surname="Yergeau">
<organization />
</author>

<date year="2003" month="November" />
</front>

<seriesInfo value="63" name="STD" />
<seriesInfo value="3629" name="RFC" />
<format octets="33856" type="TXT" target="ftp://ftp.isi.edu/in-notes/rfc3629.txt" />
</reference>


<reference target2="reference.RFC.3630.xml" anchor="RFC3630">
<front>
<title>Traffic Engineering (TE) Extensions to OSPF Version 2</title>
<author fullname="D. Katz" initials="D." surname="Katz">
<organization />
</author>

<author fullname="K. Kompella" initials="K." surname="Kompella">
<organization />
</author>

<author fullname="D. Yeung" initials="D." surname="Yeung">
<organization />
</author>

<date year="2003" month="September" />
</front>

<seriesInfo value="3630" name="RFC" />
<format octets="27717" type="TXT" target="ftp://ftp.isi.edu/in-notes/rfc3630.txt" />
</reference>


<reference target2="reference.RFC.3631.xml" anchor="RFC3631">
<front>
<title>Security Mechanisms for the Internet</title>
<author fullname="S. Bellovin" initials="S." surname="Bellovin">
<organization />
</author>

<author fullname="J. Schiller" initials="J." surname="Schiller">
<organization />
</author>

<author fullname="C. Kaufman" initials="C." surname="Kaufman">
<organization />
</author>

<date year="2003" month="December" />
</front>

<seriesInfo value="3631" name="RFC" />
<format octets="47064" type="TXT" target="ftp://ftp.isi.edu/in-notes/rfc3631.txt" />
</reference>


<reference target2="reference.RFC.3632.xml" anchor="RFC3632">
<front>
<title>VeriSign Registry Registrar Protocol (RRP) Version 2.0.0</title>
<author fullname="S. Hollenbeck" initials="S." surname="Hollenbeck">
<organization />
</author>

<author fullname="S. Veeramachaneni" initials="S." surname="Veeramachaneni">
<organization />
</author>

<author fullname="S. Yalamanchilli" initials="S." surname="Yalamanchilli">
<organization />
</author>

<date year="2003" month="November" />
</front>

<seriesInfo value="3632" name="RFC" />
<format octets="13490" type="TXT" target="ftp://ftp.isi.edu/in-notes/rfc3632.txt" />
</reference>


<reference target2="reference.RFC.3633.xml" anchor="RFC3633">
<front>
<title>IPv6 Prefix Options for Dynamic Host Configuration Protocol (DHCP) version 6</title>
<author fullname="O. Troan" initials="O." surname="Troan">
<organization />
</author>

<author fullname="R. Droms" initials="R." surname="Droms">
<organization />
</author>

<date year="2003" month="December" />
</front>

<seriesInfo value="3633" name="RFC" />
<format octets="45308" type="TXT" target="ftp://ftp.isi.edu/in-notes/rfc3633.txt" />
</reference>


<reference target2="reference.RFC.3634.xml" anchor="RFC3634">
<front>
<title>Key Distribution Center (KDC) Server Address Sub-option for the Dynamic Host Configuration Protocol (DHCP) CableLabs Client Configuration (CCC) Option</title>
<author fullname="K. Luehrs" initials="K." surname="Luehrs">
<organization />
</author>

<author fullname="R. Woundy" initials="R." surname="Woundy">
<organization />
</author>

<author fullname="J. Bevilacqua" initials="J." surname="Bevilacqua">
<organization />
</author>

<author fullname="N. Davoust" initials="N." surname="Davoust">
<organization />
</author>

<date year="2003" month="December" />
</front>

<seriesInfo value="3634" name="RFC" />
<format octets="13163" type="TXT" target="ftp://ftp.isi.edu/in-notes/rfc3634.txt" />
</reference>


<reference target2="reference.RFC.3635.xml" anchor="RFC3635">
<front>
<title>Definitions of Managed Objects for the Ethernet-like Interface Types</title>
<author fullname="J. Flick" initials="J." surname="Flick">
<organization />
</author>

<date year="2003" month="September" />
</front>

<seriesInfo value="3635" name="RFC" />
<format octets="154476" type="TXT" target="ftp://ftp.isi.edu/in-notes/rfc3635.txt" />
</reference>


<reference target2="reference.RFC.3636.xml" anchor="RFC3636">
<front>
<title>Definitions of Managed Objects for IEEE 802.3 Medium Attachment Units (MAUs)</title>
<author fullname="J. Flick" initials="J." surname="Flick">
<organization />
</author>

<date year="2003" month="September" />
</front>

<seriesInfo value="3636" name="RFC" />
<format octets="139990" type="TXT" target="ftp://ftp.isi.edu/in-notes/rfc3636.txt" />
</reference>


<reference target2="reference.RFC.3637.xml" anchor="RFC3637">
<front>
<title>Definitions of Managed Objects for the Ethernet WAN Interface Sublayer</title>
<author fullname="C.M. Heard" initials="C.M." surname="Heard">
<organization />
</author>

<date year="2003" month="September" />
</front>

<seriesInfo value="3637" name="RFC" />
<format octets="78785" type="TXT" target="ftp://ftp.isi.edu/in-notes/rfc3637.txt" />
</reference>


<reference target2="reference.RFC.3638.xml" anchor="RFC3638">
<front>
<title>Applicability Statement for Reclassification of RFC 1643 to Historic Status</title>
<author fullname="J. Flick" initials="J." surname="Flick">
<organization />
</author>

<author fullname="C.M. Heard" initials="C.M." surname="Heard">
<organization />
</author>

<date year="2003" month="September" />
</front>

<seriesInfo value="3638" name="RFC" />
<format octets="8676" type="TXT" target="ftp://ftp.isi.edu/in-notes/rfc3638.txt" />
</reference>


<reference target2="reference.RFC.3639.xml" anchor="RFC3639">
<front>
<title>Considerations on the use of a Service Identifier in Packet Headers</title>
<author fullname="M. St. Johns" initials="M." surname="St. Johns">
<organization />
</author>

<author fullname="G. Huston" initials="G." surname="Huston">
<organization />
</author>

<author>
<organization>IAB</organization>
</author>

<date year="2003" month="October" />
</front>

<seriesInfo value="3639" name="RFC" />
<format octets="15389" type="TXT" target="ftp://ftp.isi.edu/in-notes/rfc3639.txt" />
</reference>


<reference target2="reference.RFC.3640.xml" anchor="RFC3640">
<front>
<title>RTP Payload Format for Transport of MPEG-4 Elementary Streams</title>
<author fullname="J. van der Meer" initials="J." surname="van der Meer">
<organization />
</author>

<author fullname="D. Mackie" initials="D." surname="Mackie">
<organization />
</author>

<author fullname="V. Swaminathan" initials="V." surname="Swaminathan">
<organization />
</author>

<author fullname="D. Singer" initials="D." surname="Singer">
<organization />
</author>

<author fullname="P. Gentric" initials="P." surname="Gentric">
<organization />
</author>

<date year="2003" month="November" />
</front>

<seriesInfo value="3640" name="RFC" />
<format octets="102606" type="TXT" target="ftp://ftp.isi.edu/in-notes/rfc3640.txt" />
</reference>


<reference target2="reference.RFC.3641.xml" anchor="RFC3641">
<front>
<title>Generic String Encoding Rules (GSER) for ASN.1 Types</title>
<author fullname="S. Legg" initials="S." surname="Legg">
<organization />
</author>

<date year="2003" month="October" />
</front>

<seriesInfo value="3641" name="RFC" />
<format octets="34207" type="TXT" target="ftp://ftp.isi.edu/in-notes/rfc3641.txt" />
</reference>


<reference target2="reference.RFC.3642.xml" anchor="RFC3642">
<front>
<title>Common Elements of Generic String Encoding Rules (GSER) Encodings</title>
<author fullname="S. Legg" initials="S." surname="Legg">
<organization />
</author>

<date year="2003" month="October" />
</front>

<seriesInfo value="3642" name="RFC" />
<format octets="27774" type="TXT" target="ftp://ftp.isi.edu/in-notes/rfc3642.txt" />
</reference>


<reference target2="reference.RFC.3643.xml" anchor="RFC3643">
<front>
<title>Fibre Channel (FC) Frame Encapsulation</title>
<author fullname="R. Weber" initials="R." surname="Weber">
<organization />
</author>

<author fullname="M. Rajagopal" initials="M." surname="Rajagopal">
<organization />
</author>

<author fullname="F. Travostino" initials="F." surname="Travostino">
<organization />
</author>

<author fullname="M. O&apos;Donnell" initials="M." surname="O&apos;Donnell">
<organization />
</author>

<author fullname="C. Monia" initials="C." surname="Monia">
<organization />
</author>

<author fullname="M. Merhar" initials="M." surname="Merhar">
<organization />
</author>

<date year="2003" month="December" />
</front>

<seriesInfo value="3643" name="RFC" />
<format octets="39980" type="TXT" target="ftp://ftp.isi.edu/in-notes/rfc3643.txt" />
</reference>


<reference target2="reference.RFC.3644.xml" anchor="RFC3644">
<front>
<title>Policy Quality of Service (QoS) Information Model</title>
<author fullname="Y. Snir" initials="Y." surname="Snir">
<organization />
</author>

<author fullname="Y. Ramberg" initials="Y." surname="Ramberg">
<organization />
</author>

<author fullname="J. Strassner" initials="J." surname="Strassner">
<organization />
</author>

<author fullname="R. Cohen" initials="R." surname="Cohen">
<organization />
</author>

<author fullname="B. Moore" initials="B." surname="Moore">
<organization />
</author>

<date year="2003" month="November" />
</front>

<seriesInfo value="3644" name="RFC" />
<format octets="170150" type="TXT" target="ftp://ftp.isi.edu/in-notes/rfc3644.txt" />
</reference>


<reference target2="reference.RFC.3645.xml" anchor="RFC3645">
<front>
<title>Generic Security Service Algorithm for Secret Key Transaction Authentication for DNS (GSS-TSIG)</title>
<author fullname="S. Kwan" initials="S." surname="Kwan">
<organization />
</author>

<author fullname="P. Garg" initials="P." surname="Garg">
<organization />
</author>

<author fullname="J. Gilroy" initials="J." surname="Gilroy">
<organization />
</author>

<author fullname="L. Esibov" initials="L." surname="Esibov">
<organization />
</author>

<author fullname="J. Westhead" initials="J." surname="Westhead">
<organization />
</author>

<author fullname="R. Hall" initials="R." surname="Hall">
<organization />
</author>

<date year="2003" month="October" />
</front>

<seriesInfo value="3645" name="RFC" />
<format octets="56162" type="TXT" target="ftp://ftp.isi.edu/in-notes/rfc3645.txt" />
</reference>


<reference target2="reference.RFC.3646.xml" anchor="RFC3646">
<front>
<title>DNS Configuration options for Dynamic Host Configuration Protocol for IPv6 (DHCPv6)</title>
<author fullname="R. Droms" initials="R." surname="Droms">
<organization />
</author>

<date year="2003" month="December" />
</front>

<seriesInfo value="3646" name="RFC" />
<format octets="13312" type="TXT" target="ftp://ftp.isi.edu/in-notes/rfc3646.txt" />
</reference>


<reference target2="reference.RFC.3647.xml" anchor="RFC3647">
<front>
<title>Internet X.509 Public Key Infrastructure Certificate Policy and Certification Practices Framework</title>
<author fullname="S. Chokhani" initials="S." surname="Chokhani">
<organization />
</author>

<author fullname="W. Ford" initials="W." surname="Ford">
<organization />
</author>

<author fullname="R. Sabett" initials="R." surname="Sabett">
<organization />
</author>

<author fullname="C. Merrill" initials="C." surname="Merrill">
<organization />
</author>

<author fullname="S. Wu" initials="S." surname="Wu">
<organization />
</author>

<date year="2003" month="November" />
</front>

<seriesInfo value="3647" name="RFC" />
<format octets="228124" type="TXT" target="ftp://ftp.isi.edu/in-notes/rfc3647.txt" />
</reference>


<reference target2="reference.RFC.3648.xml" anchor="RFC3648">
<front>
<title abbrev="WebDAV Ordered Collections Protocol">Web Distributed Authoring and Versioning (WebDAV) Ordered Collections Protocol</title>
<author fullname="Jim Whitehead" initials="J." surname="Whitehead">
<organization abbrev="U.C. Santa Cruz">UC Santa Cruz, Dept. of Computer Science</organization>

<address>
<postal>
<street>1156 High Street</street>
<city>Santa Cruz</city>
<region>CA</region>
<code>95064</code>
<country>US</country>
</postal>

<email>ejw@cse.ucsc.edu</email>
</address>
</author>

<author fullname="Julian F. Reschke" initials="J. F." role="editor" surname="Reschke">
<organization abbrev="greenbytes">greenbytes GmbH</organization>

<address>
<postal>
<street>Salzmannstrasse 152</street>
<city>Muenster</city>
<region>NW</region>
<code>48159</code>
<country>Germany</country>
</postal>

<phone>+49 251 2807760</phone>
<facsimile>+49 251 2807761</facsimile>
<email>julian.reschke@greenbytes.de</email>
<uri>http://greenbytes.de/tech/webdav/</uri>
</address>
</author>

<date year="2003" month="December" />
<workgroup>WEBDAV Working Group</workgroup>
<keyword>WebDAV</keyword>
<keyword>ordering</keyword>
<keyword>ordered collections</keyword>
<keyword>protocol</keyword>
<keyword>ORDERPATCH method</keyword>
<keyword>Position header</keyword>
<keyword>Ordering-Type header</keyword>

<abstract>
<t>
        This specification extends the Web Distributed Authoring and Versioning (WebDAV) Protocol
        to support the server-side ordering of collection members. Of particular 
        interest are orderings that are not based on property values, and so 
        cannot be achieved using a search protocol's ordering option and cannot 
        be maintained automatically by the server.  Protocol elements are 
        defined to let clients specify the position in the ordering of each 
        collection member, as well as the semantics governing the ordering.        
      </t>
</abstract>
</front>

<seriesInfo value="3648" name="RFC" />
<format octets="57147" type="TXT" target="ftp://ftp.isi.edu/in-notes/rfc3648.txt" />
<format octets="78360" type="HTML" target="http://xml.resource.org/public/rfc/html/rfc3648.html" />
<format octets="62178" type="XML" target="http://xml.resource.org/public/rfc/xml/rfc3648.xml" />
</reference>


<reference target2="reference.RFC.3649.xml" anchor="RFC3649">
<front>
<title>HighSpeed TCP for Large Congestion Windows</title>
<author fullname="S. Floyd" initials="S." surname="Floyd">
<organization />
</author>

<date year="2003" month="December" />
</front>

<seriesInfo value="3649" name="RFC" />
<format octets="79801" type="TXT" target="ftp://ftp.isi.edu/in-notes/rfc3649.txt" />
</reference>


<reference target2="reference.RFC.3650.xml" anchor="RFC3650">
<front>
<title>Handle System Overview</title>
<author fullname="S. Sun" initials="S." surname="Sun">
<organization />
</author>

<author fullname="L. Lannom" initials="L." surname="Lannom">
<organization />
</author>

<author fullname="B. Boesch" initials="B." surname="Boesch">
<organization />
</author>

<date year="2003" month="November" />
</front>

<seriesInfo value="3650" name="RFC" />
<format octets="54927" type="TXT" target="ftp://ftp.isi.edu/in-notes/rfc3650.txt" />
</reference>


<reference target2="reference.RFC.3651.xml" anchor="RFC3651">
<front>
<title>Handle System Namespace and Service Definition</title>
<author fullname="S. Sun" initials="S." surname="Sun">
<organization />
</author>

<author fullname="S. Reilly" initials="S." surname="Reilly">
<organization />
</author>

<author fullname="L. Lannom" initials="L." surname="Lannom">
<organization />
</author>

<date year="2003" month="November" />
</front>

<seriesInfo value="3651" name="RFC" />
<format octets="104479" type="TXT" target="ftp://ftp.isi.edu/in-notes/rfc3651.txt" />
</reference>


<reference target2="reference.RFC.3652.xml" anchor="RFC3652">
<front>
<title>Handle System Protocol (ver 2.1) Specification</title>
<author fullname="S. Sun" initials="S." surname="Sun">
<organization />
</author>

<author fullname="S. Reilly" initials="S." surname="Reilly">
<organization />
</author>

<author fullname="L. Lannom" initials="L." surname="Lannom">
<organization />
</author>

<author fullname="J. Petrone" initials="J." surname="Petrone">
<organization />
</author>

<date year="2003" month="November" />
</front>

<seriesInfo value="3652" name="RFC" />
<format octets="124380" type="TXT" target="ftp://ftp.isi.edu/in-notes/rfc3652.txt" />
</reference>


<reference target2="reference.RFC.3653.xml" anchor="RFC3653">
<front>
<title>XML-Signature XPath Filter 2.0</title>
<author fullname="J. Boyer" initials="J." surname="Boyer">
<organization />
</author>

<author fullname="M. Hughes" initials="M." surname="Hughes">
<organization />
</author>

<author fullname="J. Reagle" initials="J." surname="Reagle">
<organization />
</author>

<date year="2003" month="December" />
</front>

<seriesInfo value="3653" name="RFC" />
<format octets="32258" type="TXT" target="ftp://ftp.isi.edu/in-notes/rfc3653.txt" />
</reference>


<reference target2="reference.RFC.3654.xml" anchor="RFC3654">
<front>
<title>Requirements for Separation of IP Control and Forwarding</title>
<author fullname="H. Khosravi" initials="H." surname="Khosravi">
<organization />
</author>

<author fullname="T. Anderson" initials="T." surname="Anderson">
<organization />
</author>

<date year="2003" month="November" />
</front>

<seriesInfo value="3654" name="RFC" />
<format octets="40418" type="TXT" target="ftp://ftp.isi.edu/in-notes/rfc3654.txt" />
</reference>


<reference target2="reference.RFC.3655.xml" anchor="RFC3655">
<front>
<title>Redefinition of DNS Authenticated Data (AD) bit</title>
<author fullname="B. Wellington" initials="B." surname="Wellington">
<organization />
</author>

<author fullname="O. Gudmundsson" initials="O." surname="Gudmundsson">
<organization />
</author>

<date year="2003" month="November" />
</front>

<seriesInfo value="3655" name="RFC" />
<format octets="15646" type="TXT" target="ftp://ftp.isi.edu/in-notes/rfc3655.txt" />
</reference>


<reference target2="reference.RFC.3656.xml" anchor="RFC3656">
<front>
<title>The Mailbox Update (MUPDATE) Distributed Mailbox Database Protocol</title>
<author fullname="R. Siemborski" initials="R." surname="Siemborski">
<organization />
</author>

<date year="2003" month="December" />
</front>

<seriesInfo value="3656" name="RFC" />
<format octets="35509" type="TXT" target="ftp://ftp.isi.edu/in-notes/rfc3656.txt" />
</reference>


<reference target2="reference.RFC.3657.xml" anchor="RFC3657">
<front>
<title>Use of the Camellia Encryption Algorithm in Cryptographic Message Syntax (CMS)</title>
<author fullname="S. Moriai" initials="S." surname="Moriai">
<organization />
</author>

<author fullname="A. Kato" initials="A." surname="Kato">
<organization />
</author>

<date year="2004" month="January" />
</front>

<seriesInfo value="3657" name="RFC" />
<format octets="26282" type="TXT" target="ftp://ftp.isi.edu/in-notes/rfc3657.txt" />
</reference>


<reference target2="reference.RFC.3658.xml" anchor="RFC3658">
<front>
<title>Delegation Signer (DS) Resource Record (RR)</title>
<author fullname="O. Gudmundsson" initials="O." surname="Gudmundsson">
<organization />
</author>

<date year="2003" month="December" />
</front>

<seriesInfo value="3658" name="RFC" />
<format octets="42120" type="TXT" target="ftp://ftp.isi.edu/in-notes/rfc3658.txt" />
</reference>


<reference target2="reference.RFC.3660.xml" anchor="RFC3660">
<front>
<title>Basic Media Gateway Control Protocol (MGCP) Packages</title>
<author fullname="B. Foster" initials="B." surname="Foster">
<organization />
</author>

<author fullname="F. Andreasen" initials="F." surname="Andreasen">
<organization />
</author>

<date year="2003" month="December" />
</front>

<seriesInfo value="3660" name="RFC" />
<format octets="145147" type="TXT" target="ftp://ftp.isi.edu/in-notes/rfc3660.txt" />
</reference>


<reference target2="reference.RFC.3661.xml" anchor="RFC3661">
<front>
<title>Media Gateway Control Protocol (MGCP) Return Code Usage</title>
<author fullname="B. Foster" initials="B." surname="Foster">
<organization />
</author>

<author fullname="C. Sivachelvan" initials="C." surname="Sivachelvan">
<organization />
</author>

<date year="2003" month="December" />
</front>

<seriesInfo value="3661" name="RFC" />
<format octets="49898" type="TXT" target="ftp://ftp.isi.edu/in-notes/rfc3661.txt" />
</reference>


<reference target2="reference.RFC.3662.xml" anchor="RFC3662">
<front>
<title>A Lower Effort Per-Domain Behavior (PDB) for Differentiated Services</title>
<author fullname="R. Bless" initials="R." surname="Bless">
<organization />
</author>

<author fullname="K. Nichols" initials="K." surname="Nichols">
<organization />
</author>

<author fullname="K. Wehrle" initials="K." surname="Wehrle">
<organization />
</author>

<date year="2003" month="December" />
</front>

<seriesInfo value="3662" name="RFC" />
<format octets="39029" type="TXT" target="ftp://ftp.isi.edu/in-notes/rfc3662.txt" />
</reference>


<reference target2="reference.RFC.3663.xml" anchor="RFC3663">
<front>
<title>Domain Administrative Data in Lightweight Directory Access Protocol (LDAP)</title>
<author fullname="A. Newton" initials="A." surname="Newton">
<organization />
</author>

<date year="2003" month="December" />
</front>

<seriesInfo value="3663" name="RFC" />
<format octets="42260" type="TXT" target="ftp://ftp.isi.edu/in-notes/rfc3663.txt" />
</reference>


<reference target2="reference.RFC.3664.xml" anchor="RFC3664">
<front>
<title>The AES-XCBC-PRF-128 Algorithm for the Internet Key Exchange Protocol (IKE)</title>
<author fullname="P. Hoffman" initials="P." surname="Hoffman">
<organization />
</author>

<date year="2004" month="January" />
</front>

<seriesInfo value="3664" name="RFC" />
<format octets="6711" type="TXT" target="ftp://ftp.isi.edu/in-notes/rfc3664.txt" />
</reference>


<reference target2="reference.RFC.3665.xml" anchor="RFC3665">
<front>
<title>Session Initiation Protocol (SIP) Basic Call Flow Examples</title>
<author fullname="A. Johnston" initials="A." surname="Johnston">
<organization />
</author>

<author fullname="S. Donovan" initials="S." surname="Donovan">
<organization />
</author>

<author fullname="R. Sparks" initials="R." surname="Sparks">
<organization />
</author>

<author fullname="C. Cunningham" initials="C." surname="Cunningham">
<organization />
</author>

<author fullname="K. Summers" initials="K." surname="Summers">
<organization />
</author>

<date year="2003" month="December" />
</front>

<seriesInfo value="75" name="BCP" />
<seriesInfo value="3665" name="RFC" />
<format octets="163159" type="TXT" target="ftp://ftp.isi.edu/in-notes/rfc3665.txt" />
</reference>


<reference target2="reference.RFC.3666.xml" anchor="RFC3666">
<front>
<title>Session Initiation Protocol (SIP) Public Switched Telephone Network (PSTN) Call Flows</title>
<author fullname="A. Johnston" initials="A." surname="Johnston">
<organization />
</author>

<author fullname="S. Donovan" initials="S." surname="Donovan">
<organization />
</author>

<author fullname="R. Sparks" initials="R." surname="Sparks">
<organization />
</author>

<author fullname="C. Cunningham" initials="C." surname="Cunningham">
<organization />
</author>

<author fullname="K. Summers" initials="K." surname="Summers">
<organization />
</author>

<date year="2003" month="December" />
</front>

<seriesInfo value="76" name="BCP" />
<seriesInfo value="3666" name="RFC" />
<format octets="200478" type="TXT" target="ftp://ftp.isi.edu/in-notes/rfc3666.txt" />
</reference>


<reference target2="reference.RFC.3670.xml" anchor="RFC3670">
<front>
<title>Information Model for Describing Network Device QoS Datapath Mechanisms</title>
<author fullname="B. Moore" initials="B." surname="Moore">
<organization />
</author>

<author fullname="D. Durham" initials="D." surname="Durham">
<organization />
</author>

<author fullname="J. Strassner" initials="J." surname="Strassner">
<organization />
</author>

<author fullname="A. Westerinen" initials="A." surname="Westerinen">
<organization />
</author>

<author fullname="W. Weiss" initials="W." surname="Weiss">
<organization />
</author>

<date year="2004" month="January" />
</front>

<seriesInfo value="3670" name="RFC" />
<format octets="221687" type="TXT" target="ftp://ftp.isi.edu/in-notes/rfc3670.txt" />
</reference>


<reference target2="reference.RFC.3671.xml" anchor="RFC3671">
<front>
<title>Collective Attributes in the Lightweight Directory Access Protocol (LDAP)</title>
<author fullname="K. Zeilenga" initials="K." surname="Zeilenga">
<organization />
</author>

<date year="2003" month="December" />
</front>

<seriesInfo value="3671" name="RFC" />
<format octets="17912" type="TXT" target="ftp://ftp.isi.edu/in-notes/rfc3671.txt" />
</reference>


<reference target2="reference.RFC.3672.xml" anchor="RFC3672">
<front>
<title>Subentries in the Lightweight Directory Access Protocol (LDAP)</title>
<author fullname="K. Zeilenga" initials="K." surname="Zeilenga">
<organization />
</author>

<date year="2003" month="December" />
</front>

<seriesInfo value="3672" name="RFC" />
<format octets="24447" type="TXT" target="ftp://ftp.isi.edu/in-notes/rfc3672.txt" />
</reference>


<reference target2="reference.RFC.3673.xml" anchor="RFC3673">
<front>
<title>Lightweight Directory Access Protocol version 3 (LDAPv3): All Operational Attributes</title>
<author fullname="K. Zeilenga" initials="K." surname="Zeilenga">
<organization />
</author>

<date year="2003" month="December" />
</front>

<seriesInfo value="3673" name="RFC" />
<format octets="10003" type="TXT" target="ftp://ftp.isi.edu/in-notes/rfc3673.txt" />
</reference>


<reference target2="reference.RFC.3674.xml" anchor="RFC3674">
<front>
<title>Feature Discovery in Lightweight Directory Access Protocol (LDAP)</title>
<author fullname="K. Zeilenga" initials="K." surname="Zeilenga">
<organization />
</author>

<date year="2003" month="December" />
</front>

<seriesInfo value="3674" name="RFC" />
<format octets="10282" type="TXT" target="ftp://ftp.isi.edu/in-notes/rfc3674.txt" />
</reference>


<reference target2="reference.RFC.3677.xml" anchor="RFC3677">
<front>
<title>IETF ISOC Board of Trustee Appointment Procedures</title>
<author fullname="L. Daigle" initials="L." surname="Daigle">
<organization />
</author>

<author>
<organization>Internet Architecture Board</organization>
</author>

<date year="2003" month="December" />
</front>

<seriesInfo value="77" name="BCP" />
<seriesInfo value="3677" name="RFC" />
<format octets="13008" type="TXT" target="ftp://ftp.isi.edu/in-notes/rfc3677.txt" />
</reference>


<reference target2="reference.RFC.3678.xml" anchor="RFC3678">
<front>
<title>Socket Interface Extensions for Multicast Source Filters</title>
<author fullname="D. Thaler" initials="D." surname="Thaler">
<organization />
</author>

<author fullname="B. Fenner" initials="B." surname="Fenner">
<organization />
</author>

<author fullname="B. Quinn" initials="B." surname="Quinn">
<organization />
</author>

<date year="2004" month="January" />
</front>

<seriesInfo value="3678" name="RFC" />
<format octets="36320" type="TXT" target="ftp://ftp.isi.edu/in-notes/rfc3678.txt" />
</reference>


<reference target2="reference.RFC.3679.xml" anchor="RFC3679">
<front>
<title>Unused Dynamic Host Configuration Protocol (DHCP) Option Codes</title>
<author fullname="R. Droms" initials="R." surname="Droms">
<organization />
</author>

<date year="2004" month="January" />
</front>

<seriesInfo value="3679" name="RFC" />
<format octets="13804" type="TXT" target="ftp://ftp.isi.edu/in-notes/rfc3679.txt" />
</reference>


<reference target2="reference.RFC.3681.xml" anchor="RFC3681">
<front>
<title>Delegation of E.F.F.3.IP6.ARPA</title>
<author fullname="R. Bush" initials="R." surname="Bush">
<organization />
</author>

<author fullname="R. Fink" initials="R." surname="Fink">
<organization />
</author>

<date year="2004" month="January" />
</front>

<seriesInfo value="80" name="BCP" />
<seriesInfo value="3681" name="RFC" />
<format octets="7137" type="TXT" target="ftp://ftp.isi.edu/in-notes/rfc3681.txt" />
</reference>

</references>
</back>
</rfc>

